Moving a Table to a new Tablespace                                            Administration TipsMoving a TableMoving a ta...
Moving a Table to a new Tablespace                                             Administration TipsBut the real nasty with ...
Upcoming SlideShare
Loading in...5
×

Movetablespace

231

Published on

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
231
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Movetablespace"

  1. 1. Moving a Table to a new Tablespace Administration TipsMoving a TableMoving a table from one tablespace to another is a piece of cake -provided you haveOracle 8i. The command there is simply:ALTER TABLE BLAH MOVE TABLESPACE XYZ;The tablespace name in this command doesnt have to be a completely new tablespace: itsperfectly permissible to move a table within a tablespace, and hence the name canlegitimately be the name of the tablespace its already housed within.Theres only one slight word of warning with this command: the way it works is that a newversion of the table is created, under a temporary name, in the specified tablespace, andthen populated by selecting from the original table. When the populating exercise hasfinished, the old version is dropped, and the new one simultaneously renamed as the oldone. For a split second, therefore, two versions of the table exist -and hence you needsufficient disk space to accomodate those two versions. If this is 12Gb table you aremoving, that can be expensive!Otherwise, theres not much to report on the move tablespace command. It brings alongall constraints and permissions, so theres none of that to redefine. There is one slightproblem: all indexes on the table have got leaf nodes stuffed full of ROWIDs which point towhere the old table used to be. Now its moved, those indexes are basically stuffed full ofworthless nonsense... hence the need to rebuild all indexes on a table thats been moved.Suppose, however, you dont have the advantages of 8i and its "move tablespace" command.How then do you do the deed?Well, the simplest way would be to do a CTAS. That stands for "create table as select",and refers to the fact that you could issue the following command:CREATE TABLE NEW_EMPTABLESPACE NEWONEASSELECT * FROM OLD_EMP;Only problem with this command is that you probably need to do it twice: assuming youwant the newly re-located table to be the same name as the original, youd follow theabove command with a drop table old_emp; followed by a revamp of the earlier CTAS toread create...old_emp as select * from new_emp.Copyright © Howard Rogers 2001 10/17/2001 Page 1 of 2
  2. 2. Moving a Table to a new Tablespace Administration TipsBut the real nasty with this technique is that the tables you create each time you run theCTAS command are new tables. That means no-one has any rights on them, there are noconstraints defined for them, and no indexes exist for them. Youll need to re-grant allpermissions, re-create all constraints, and re-specify and re-create all indexes, too (nowisnt that upgrade to 8i looking attractive??!).Another possibility presents itself: export the old table, then drop it. Alter the user sothat their quota on the original tablespace is zero, and also alter that user so that theirdefault tablespace is the one you want the new table created in. Import, you see, alwayslikes to create tables in a tablespace of exactly the same name as the one the tableoriginally came from. But if it cant create it there (and the quota of zero prevents that),it will instead choose to create the table in whoever is running imports default tablespace.This technique can get a bit fiddly, but has the advantage of re-creating all indexes,constraints and re-granting all permissions. Youd have to remember to set the quotas anddefault tablespace for the User involved back to what they were earlier, too.At the end of the day, whichever version of Oracle you use, and whichever technique yougo for, moving tables is not a cheap exercise. Best house them correctly in the first place.But if you have to do it, the move tablespace option has the distinct advantages of ease ofimplementation.Copyright © Howard Rogers 2001 10/17/2001 Page 2 of 2

×