Skip to Main Content
  • Questions
  • moving tables to a locally managed tablespace

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, Duncan.

Asked: October 24, 2003 - 9:51 am UTC

Last updated: November 22, 2006 - 4:46 pm UTC

Version: 8.1.7.4

Viewed 1000+ times

You Asked

Tom

I have a question regarding the MOVE clause of alter table.
We wanted to move from a dictionary managed tablespace to a locally managed one. To do this I:

1) created the local tablespace using uniform extents of 40K
2) I then used alter table move command to move the table into the new tablespace


So in the DMT it looks like:

11:25:57 OPT1@OP4>exec print_Table('select * from dba_segments where segment_name = ''ATTENDANCE''')
;
OWNER : OPT1
SEGMENT_NAME : ATTENDANCE
PARTITION_NAME :
SEGMENT_TYPE : TABLE
TABLESPACE_NAME : DATA
HEADER_FILE : 14
HEADER_BLOCK : 12482
BYTES : 10035200
BLOCKS : 1225
EXTENTS : 1
INITIAL_EXTENT : 10002432
NEXT_EXTENT : 10002432
MIN_EXTENTS : 1
MAX_EXTENTS : 2147483645
PCT_INCREASE : 0
FREELISTS : 1
FREELIST_GROUPS : 1
RELATIVE_FNO : 14
BUFFER_POOL : KEEP
-----------------

PL/SQL procedure successfully completed.



Then I did:



11:26:59 OPT1@OP4>alter table attendance
11:27:16 2 move tablespace DATA_S;

Table altered.

Elapsed: 00:00:00.05
11:27:26 OPT1@OP4>exec print_Table('select * from dba_segments where segment_name = ''ATTENDANCE''')
;
OWNER : OPT1
SEGMENT_NAME : ATTENDANCE
PARTITION_NAME :
SEGMENT_TYPE : TABLE
TABLESPACE_NAME : DATA_S
HEADER_FILE : 25
HEADER_BLOCK : 1234
BYTES : 10035200
BLOCKS : 1225
EXTENTS : 245
INITIAL_EXTENT : 10002432
NEXT_EXTENT : 40960
MIN_EXTENTS : 1
MAX_EXTENTS : 2147483645
PCT_INCREASE : 0
FREELISTS : 1
FREELIST_GROUPS : 1
RELATIVE_FNO : 25
BUFFER_POOL : KEEP
-----------------

PL/SQL procedure successfully completed.



I was hoping that this command would actually reset the HWM of the table so that the table itself would shrink to its exact size with no
extra storage.


However looking at dba_Segments after the move it seems that it has not shrunk, and the initial extent is ~10M, NEXT = 40K
How can the initial extent not be equal to the NEXT extent if we have uniform extents??

Why did the alter table move command not shrink the table?

Now if instead I do:

11:36:22 OPT1@OP4>create table T1
11:38:10 2 as select *
11:38:13 3 from attendance;

Table created.

Elapsed: 00:00:00.01
11:38:21 OPT1@OP4>drop table attendance;

Table dropped.

Elapsed: 00:00:00.03
11:38:30 OPT1@OP4>create table ATTENDANCE
11:38:39 2 as select * from
11:38:42 3 T1;

Table created.


I now move the table again since the default tablespace of the current user
is not the correct one:


Elapsed: 00:00:00.01
11:38:47 OPT1@OP4>alter table attendance move
11:38:54 2 tablespace DATA_S;

Table altered.

Elapsed: 00:00:00.00
11:39:05 OPT1@OP4>exec print_Table('select * from dba_segments where segment_name = ''ATTENDANCE''')
;
OWNER : OPT1
SEGMENT_NAME : ATTENDANCE
PARTITION_NAME :
SEGMENT_TYPE : TABLE
TABLESPACE_NAME : DATA_S
HEADER_FILE : 25
HEADER_BLOCK : 1234
BYTES : 40960
BLOCKS : 5
EXTENTS : 1
INITIAL_EXTENT : 40960
NEXT_EXTENT : 40960
MIN_EXTENTS : 1
MAX_EXTENTS : 2147483645
PCT_INCREASE : 0
FREELISTS : 1
FREELIST_GROUPS : 1
RELATIVE_FNO : 25
BUFFER_POOL : DEFAULT
-----------------

PL/SQL procedure successfully completed.



So now I get what I want ie 1 extent and INITIAL=NEXT.
Why did I not see that with the first alter table move.... command?
Is it because the HWM of the table was taken into account?


If this is the case how can I deallocate the unused space with one move command?

Thanks for your help.

and Tom said...

with LMTs initial is just "the initial allocation" -- it is not an initial extent size -- they are all 40k -- you just have a gazillion of them to give you 10m of storage.


you should:

alter table t move new_tablespace storage( initial 1k next 1k pctincrease 0 minextents 1 );


that'll reset the STORAGE parameters -- else they are copied from the existing segment. It has nothing to do with the HWM, it has everything to do with the legacy storage parameters.

Rating

  (5 ratings)

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

Comments

Oracle doesn't seem to like this

Duncan, October 24, 2003 - 11:23 am UTC

Elapsed: 00:00:00.01
16:18:40 OPT1@OP4>alter table ANALYSIS
16:19:10 2 move DATA_S
16:19:10 3 storage( initial 40k
16:19:10 4 next 40k
16:19:10 5 pctincrease 0
16:19:10 6 minextents 1
16:19:10 7 );
move DATA_S
*
ERROR at line 2:
ORA-14133: ALTER TABLE MOVE cannot be combined with other operations

Also when you say we have loads of extents were you saying that we have too many? The reason I ask is that the data may not be archived for about 7 years so if by then we were to have extents numbers eg > 3000, could this be a problem?

Tom Kyte
October 24, 2003 - 11:35 am UTC

<b>you missed the TABLESPACE keyword, sorry -- my psuedo codeish example probably is misleading that way.</b>


ops$tkyte@ORA920> alter table t move users;
alter table t move users
                   *
ERROR at line 1:
ORA-14133: ALTER TABLE MOVE cannot be combined with other operations
 
 
ops$tkyte@ORA920> alter table t move TABLESPACE users;
 
Table altered.
 
ops$tkyte@ORA920> alter table t move tablespace users
  2  storage ( initial 1k next 1k pctincrease 0 minextents 1 );
 
Table altered.



 

thanks

A reader, October 24, 2003 - 11:46 am UTC

please can you comment on my last question regarding the number of extents reaching 3000+. Would this cause performance issues?



Tom Kyte
October 24, 2003 - 12:28 pm UTC

nope. i've "accidently" let a table get into 32,000+ extents and never bothered to fix it (was during a benchmark to boot -- just put the object in the wrong tablespace)

Great job

Roland, February 14, 2005 - 9:40 am UTC

I was having difficulty moving some tables to an LMT where the initial extent kept getting set to the original. Never thought of setting it smaller during the move ....

Thanks!

Genevieve Beaudoin, December 08, 2005 - 10:27 am UTC

Consider this tablespace:

CREATE TABLESPACE TBSP_PROPAF_RECO2 DATAFILE
'tbsp_propaf_reco2_d0101.dbf' SIZE 14400K AUTOEXTEND ON NEXT 1M MAXSIZE 16M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 512K;

When I move a table to this tablespace, I use this command to reset the storage:

alter table DIVISION
move tablespace tbsp_propaf_reco2
storage
(
INITIAL 1
NEXT 1
MINEXTENTS 1
PCTINCREASE 0
)
;

but when I query dba_tables I see that the initial extent is 4k. Why ???

TABLE_NAME INITIAL_EXTENT NEXT_EXTENT
------------------------------ -------------- -----------
DIVISION 4096 524288

There is just one extent:

SEGMENT_NAME BLOCK_ID BYTES BLOCKS
--------------- --------- --------- ---------
DIVISION 5921 524288 256

I know that with LMTs initial is just "the initial allocation" but I think that is not representative.
Is there a way of making him post its real size (512k) ?

Thanks,
I hope that you will understand my question because my english is not excellent !

Tom Kyte
December 08, 2005 - 11:57 am UTC

because 1 byte is not permitted. it rounded up to 2 blocks.


the initial_extent in dba_tables does not correspond to the "first extent" of the segment in the locally managed tablespace. It is merely the "requested size of the initial extent when you create me in something". It does NOT reflect the size of the intial extent of the real segment (that comes from dba_extents).

alter index rebuild tablespace

MS, November 21, 2006 - 6:42 pm UTC

Oracle 9206

Tom,

resetting of the storage clause:
storage( initial 1k next 1k pctincrease 0
minextents 1 )

will this resetting of storage also be needed while moving tablespaces for indices
(alter index rebuild tablespace...storage..)..?

Thanks.



Tom Kyte
November 22, 2006 - 4:46 pm UTC

nothing is "needed"

it is a matter of whether you DESIRE it.


would you like to reset the storage clause for the index in a manner suitable for locally managed tablespaces? If so, sure.

More to Explore

PL/SQL demos

Check out more PL/SQL tutorials on our LiveSQL tool.

PL/SQL docs

PL/SQL reference manual from the Oracle documentation library