Skip to Main Content
  • Questions
  • Missing stats after ALTER TABLE MOVE

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, James .

Asked: September 24, 2001 - 9:23 am UTC

Last updated: September 24, 2001 - 4:25 pm UTC

Version: 8.1.6

Viewed 1000+ times

You Asked

Hi Tom,

I suspect a ALTER TABLE MOVE actually Drops the table at some
point as table statistics go missing. (Test Case results follow)

I have tried SQL_TRACE and LOG_MINER to verify my theory
Is there anyway you know that would tell me what Oracle is actually
running behind the scenes

Well done on a great book it has been VERY helpful.
I recommend it as a must have for anyone working with Oracle.

Regards

Jim

Connected to:
Oracle8i Enterprise Edition Release 8.1.6.0.0 - Production
With the Partitioning option
JServer Release 8.1.6.0.0 - Production

SQL> create table test_move as select * from dual;

Table created.

SQL>
SQL> analyze table test_move compute statistics;

Table analyzed.

SQL>
SQL> select to_char(last_analyzed,'DD-MON-YYYY HH24:MI:SS')
2 from dba_tables
3 where table_name = 'TEST_MOVE';

TO_CHAR(LAST_ANALYZE
--------------------
24-SEP-2001 13:50:52

SQL>
SQL> alter table test_move move tablespace t_various1;

Table altered.

SQL>
SQL> select to_char(last_analyzed,'DD-MON-YYYY HH24:MI:SS')
2 from dba_tables
3 where table_name = 'TEST_MOVE';

TO_CHAR(LAST_ANALYZE
--------------------


SQL>





and Tom said...

It does not drop the object (things would go totally invalid and they do not -- just indexes are marked unusable).

It drops the stats because things like the cluster factor of indexes would change, the rows/block will change, the amount of chaining will change, the number of blocks below the HWM will change, etc etc etc -- most of the stats themselves are rendered invalid.

Rating

  (3 ratings)

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

Comments

What does it do then ?

James, September 24, 2001 - 10:50 am UTC

Thanks...
The reason I thought a drop must be occuring is because
of a comment from Oracle Support found on Metalink

"The alter table move internally does a 'create table as select' which cannot be used with long/long raw columns. "

If the table move actually does do a CREATE table AS SELECT
then surely something must get Dropped else there will be 2
copies of the table. Good point about the invalidation of objects though...

So was Oracle Support mistaken ? ...



Tom Kyte
September 24, 2001 - 12:56 pm UTC

No, support is not mistaken and neither am I. It just isn't really "dropping" the table is all. It creates a new copy into temp extents -- updates the data dictionary to swap the temp extent with the permanent extents -- and then removes the temporary extents (which were the OLD table extents).

It does not do a "drop", that would lose grants and everything else.

What does it do then ?

James, September 24, 2001 - 10:50 am UTC

Thanks...
The reason I thought a drop must be occuring is because
of a comment from Oracle Support found on Metalink

"The alter table move internally does a 'create table as select' which cannot be used with long/long raw columns. "

If the table move actually does do a CREATE table AS SELECT
then surely something must get Dropped else there will be 2
copies of the table. Good point about the invalidation of objects though...

So was Oracle Support mistaken ? ...



That explains it

James, September 24, 2001 - 4:25 pm UTC

Thanks Tom !

I think the action you is being shown in
the output from a log miner session !





More to Explore

VLDB

If you are new to partitioning, check out Connor McDonald's introduction series here.

VLDB

Documentation set on VLDB and Partitioning.