Re: db_block_size = 16K inflates tables

Not sure where you're coming from or what you're alluding to, but the smallest locally managed extent using autoallocate (an entirely separate issue from ASSM) is 64K.

So "smallest extents [sic] size is 1m" is just plain wrong.

And "with management auto" is so ambiguous, it's meaningless. Are you talking about extent management for the segment, or for the tablespace?

HJR "vob" <vbuehringer_at_hotmail.com> wrote in message news:aquh32$duk$06$1_at_news.t-online.com...
> hehe,
>
> your problem is with 16k blocksize
> smallest extents size is 1m , so every table starts with 1m
> with management auto
>
>
> "ivan vasquez" <ivan_at_itos.uga.edu> schrieb im Newsbeitrag
> news:aqs1sg$4q3$1_at_cronkite.cc.uga.edu...
> > Hi,
> >
> > I just installed a 9.2.0 instance for GIS applications (ESRI ArcSDE).
The
> > manufacturer suggests using db_block_size = 16K. After a first
> installation
> > using block size 8K, I reinstalled the database using 16K to see if the
> > performance improved. However, a more important problem appeared: Tables
> are
> > growing way too fast.
> >
> > (All tablespaces have been created locally managed, auto segment space
> > mgmt.)
> > In a 8K blocksize tablespace, a table with only 160 rows, 46 bytes per
> row,
> > uses 5 data blocks.
> > In a 16K blocksize tablespace, the exact same table uses 61 data blocks!
> >
> > The tables were created with no storage statements, so defaults should
> > apply. The data was retrieved from user_tables after analyzing them.
> >
> > What could be "wrong"?
> > Thank you,
> > Ivan.
> >
> > Table description:
> >
> > SQL> desc ga_cnt00
> > Name Null? Type
> >
>
> ----------------------------------------- -------- -----------------------
> -
> >
> > OBJECTID NOT NULL NUMBER(10)
> >
> > AREA NUMBER(24,5)
> >
> > COUNTY VARCHAR2(5)
> >
> > NAME VARCHAR2(13)
> >
> > LR_ID NUMBER(16)
> >
> > POP00 NUMBER(16)
> >
> > ID VARCHAR2(5)
> >
> > SHAPE NUMBER(10)
> >
> >
> >
> >
>
>
Received on Wed Nov 13 2002 - 16:00:31 CST