Skip to Main Content

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Mac.

Asked: April 04, 2017 - 4:19 pm UTC

Last updated: April 11, 2017 - 12:34 am UTC

Version: 12c

Viewed 1000+ times

You Asked

Tom, if I create a table with the following characteristics in its partitions:


COMPRESS BASIC
PCTFREE     0
STORAGE   (
    INITIAL     7748954362 --7.2 GB
    NEXT        1048576 --1 MB
    MINEXTENTS  1
    MAXEXTENTS  2147483645
  PCTINCREASE 0),



The INITIAL that calculated gave me 7 GB but with the COMPRESS should I set a lower INITIAL?

I think it allocates 7GB but actually uses less because it is compressed. Is that so?


They are big tables so I want to occupy as little as possible on disk and not generate many extents

and Chris said...

You're on 12c, so by default when you create the table it won't allocate anything:

set feed on

create table t#init128k (
  x int 
) storage ( initial 128K ) ;

create table t#init1M (
  x int 
) storage ( initial 1M ) ;

create table t#init1G (
  x int 
) storage ( initial 1G ) ;

select segment_name , bytes / 1024 size_in_kb 
from   user_segments
where  segment_name like 'T#%';

 0 rows selected 


This is due to deferred segment creation.

As soon as you insert some data, Oracle Database will create the segment. At this point it will allocate the space as you say:

insert into t#init128K values (1);
insert into t#init1M values (1);
insert into t#init1G values (1);

select segment_name , bytes / 1024 size_in_kb 
from   user_segments
where  segment_name like 'T#%';

SEGMENT_NAME  SIZE_IN_KB  
T#INIT128K    128         
T#INIT1G      1,048,576   
T#INIT1M      1,024


So at this point we've got three segments which only have a couple of bytes in. i.e. they're mostly empty. How much Oracle Database uses depends upon how many rows you insert and how big they are. And if you're using compress and how compressible they are.

Unless you're going to load 7Gb immediately after creating the table there's no point allocating that much because the table will be that big "one day".

There's no reason to "not generate many extents". Having lots isn't going to make any performance difference:

https://asktom.oracle.com/pls/asktom/f?p=100:11:::::P11_QUESTION_ID:730289259844

Rating

  (3 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Mac, April 05, 2017 - 12:58 pm UTC

I do not understand

Unless you're going to load 7Gb immediately after creating the table there's no point allocating that much because the table will be that big "one day".

Decis that it does not make sense to assign an initial of 7 GB for a partition that is filled immediately?
Chris Saxon
April 05, 2017 - 1:47 pm UTC

Filled immediately with how much data? 7Kb, 7Mb or 7Gb?

The point is only allocate what you know you need right now. If you're loading 500Mb of data NOW, don't allocate 10Gb NOW because you expect to need that much space in a year.

Mac, April 05, 2017 - 2:35 pm UTC

What I do is partition a table so I have already calculated the number of records for the partitions
Chris Saxon
April 06, 2017 - 9:05 am UTC

I'm not sure what you're getting at.

Mac, April 10, 2017 - 1:14 pm UTC

What I need to do is:
I have a table of 40 GB and I need to pass the data to a new one that is partitioned, but the first partition occupies 7 GB.
It is good that INITIAL of that partition will put 7 GB
Connor McDonald
April 11, 2017 - 12:34 am UTC

Generally - dont worry about initial / next.

Yes, ensure you have enough datafile/tablespace space to hold your data for now, and for your planned sizes.

But the *extent* sizes will take care of themselves.