Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Table Storage Estimates

Re: Table Storage Estimates

From: Yustiono <tekait11_at_bni.co.id>
Date: Wed, 28 Feb 2001 19:17:42 -0800
Message-ID: <F001.002C046A.20010228183043@fatcity.com>

I think you can partition the table. It would not change the logical database design (so, your application will not see the difference).

Based on you numbers, it is very possible that row chaining and migration exist. Follow the steps I passed to you earlier.

My suggestion:
1. Recreate database with larger database block size, if it is possible, or at least

2. Reduce the PCTFREE from its default.
3. Partition table if possible
4. Follows these common practices:

- Separate tables and their indexes on different disks. - Separate online redo log files and archived log files on separate disks to avoid contention between LGWR and ARCn.
- Separate online redo log files and datafiles on separate disks to avoid contention between LGWR and DBWn.
- Locally-managed tablespaces can reduce fragmentation (for other than SYSTEM tablespace)

> Thanks all for the solution. I too thought of having a 1 : 1 relationship
by
> separating the long raw column from the table. But I believe I am not
> permitted to do that (Strange!!!!). Since this is a third party product, I
> am not suppose to change any of the design issues and also the datatype.
>
> I believe row chaining is obvious in this situation. Also the average row
> length is 10M. The size of the database block size is 8.
>
> When I queried the dba_extents to find the number of blocks that have been
> occupied, it showed 16620 and the number of rows are 113.
>
> I am totally confused now. Any help greatly appreciated.
>
> Sanjay
>
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: Wednesday, February 28, 2001 12:46 AM
>
>
> Your estimate comes to around 1 row per block.
> What is the average row lenght once data is in the db
> ? Do you have row chaining ?
>
> What is your block size ? Can you increase it ?
>
> If a lot of queries do not need the long raw column
> you can put it in another table with a 1 to 1
> relationship with the parent table.
>
> If your planning to have 200 rows of 1 block each, I
> do not understand why you are adding datafiles as the
> data should not occupied more than 3200K if you
> blocksize is 16K. Increase the size of the initial
> datafile instead of adding new ones.
>
> --- Sanjay Kumar <ora_user_at_hotmail.com> a écrit : >
> Hi,
> >
> > I have a table which has a structure similar to the
> > following.
> >
> > MID NOT NULL
> > VARCHAR2(24)
> > NAME
> > VARCHAR2(512)
> > PRIORITY
> > NUMBER(38)
> > PERSISTENT
> > CHAR(1)
> > EXP_DATE
> > DATE
> > BODY
> > LONG RAW
> >
> >
> > I estimated the table storage for this table using
> > the formula given in the Oracle documentation. It
> > comes to around 1 rows per block.
> >
> > It is estimated that the number of rows for this
> > table will not exceed 200.
> >
> > My questions are
> >
> > 1. Doesnt this lead to fragmentation.?
> > 2. I have added three datafiles to this tablespace
> > as of now and it seems like this might require more
> > space!!!!!!!!. How do I effectively redesign this
> > table to avoid contention and chaining?
> >
> > 3. Moreover, initially when there were 105 rows
> > inserted, I issued a count(*) and it took about 5
> > minutes? How do I reduce the time taken to execute
> > the query?
> >
> >
> > I would highly appreciate if someone comes forward
> > to help me on this.
> >
> > I am using Oracle 8.1.6 on Solaris
> >
> > Sanjay
> >
> >
> >
>
>
> =====
> Stephane Paquette
> DBA Oracle
> stephane_paquette_at_yahoo.com
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: =?iso-8859-1?q?paquette=20stephane?=
> INET: stephane_paquette_at_yahoo.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Sanjay Kumar
> INET: ora_user_at_hotmail.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Yustiono
  INET: tekait11_at_bni.co.id

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Wed Feb 28 2001 - 21:17:42 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US