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

Home -> Community -> Usenet -> c.d.o.server -> Re: decreasing initial extent

Re: decreasing initial extent

From: Howard J. Rogers <howardjr2000_at_yahoo.com.au>
Date: Thu, 16 Jan 2003 10:30:28 +1100
Message-ID: <H0mV9.24997$jM5.65909@newsfeeds.bigpond.com>

"Richard Foote" <richard.foote_at_bigpond.com> wrote in message news:PFcV9.24820$jM5.65253_at_newsfeeds.bigpond.com... [snip]
>
> Might be of interest.
>
> SQL> create tablespace major_tom datafile 'c:\bowie\major_tom01.dbf' size
> 10m un
> iform size 64k;
>
> Tablespace created.
>
> SQL> create table ground_control (x number) tablespace major_tom storage
> (initia
> l 256k);
>
> Table created.
>
> SQL> select initial_extent from user_tables where table_name =
> 'GROUND_CONTROL';
>
>
> INITIAL_EXTENT
> --------------
> 262144
>
> SQL> alter table ground_control deallocate unused keep 64K;
>
> Table altered.
>
> SQL> select initial_extent from user_tables where table_name =
> 'GROUND_CONTROL';
>
>
> INITIAL_EXTENT
> --------------
> 131072
>
> So the initial extent *can* be reduced if you initially made it greater
than
> the uniform size.

Come off it Richard! (And I mean that in a loving way). You queried the wrong view. Here's a rather more telling test:

SQL> create tablespace britten datafile 'd:\oracle\oradata\oemrep\god01.dbf'   2 size 10m uniform size 64k;

Tablespace created.

SQL> create table pgrimes (x number)
  2 tablespace britten
  3 storage (initial 256K);

Table created.

SQL> select initial_extent from user_tables   2 where table_name='PGRIMES';

INITIAL_EXTENT


        262144

[So far, I agree with you test entirely, except that I have better taste in music].

But, and here's the killer:

SQL> select bytes from dba_extents
  2 where segment_name='PGRIMES';

     BYTES


     65536
     65536
     65536
     65536

The initial extent clause has been completely ignored, despite what DBA_TABLES (and, indeed, DBA_SEGMENTS will tell you). I've acquired 4 64K extents, not a single 256K one. As is to be expected when the tablespace simply cannot allocate anything other than 64K.

Right. Now for the final test:

SQL> alter table pgrimes deallocate unused keep 64K;

Table altered.

SQL> select bytes from dba_extents
  2 where segment_name='PGRIMES';

     BYTES


     65536
     65536

So yes, de-allocate unused does do *something*. In this case, it's de-allocated two extents. But has the size of those extents left behind altered in some way? Not a bit of it.

Did DBA_TABLES and DBA_SEGMENTS mysteriously change to record an inital_extent of 128K? Yup, most certainly. Does that mean anything as far as what is physically stored on disk? Nope.

It *might* have an impact if one were to export and import into another database with DMTs, or with differently-uniformly-sized LMTs. But it doesn't do what you'd expect if that had been DMTs.

And you'll note that I very carefully said originally that it wouldn't do what you might have expected, not that it wouldn't have any effect at all.

Regards
HJR
>
> One last trap. When you deallocate, it will by default only deallocate up
to
> the minextent size. To reduce further, you must use the keep option.
>
> Cheers
>
> Richard
>
>
Received on Wed Jan 15 2003 - 17:30:28 CST

Original text of this message

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