Home » RDBMS Server » Server Administration » alter table table_name MOVE TABLESPACE tbs_name
alter table table_name MOVE TABLESPACE tbs_name [message #60572] Tue, 17 February 2004 00:55 Go to next message
Patrick Tahiri
Messages: 119
Registered: January 2004
Senior Member
Hi,

I'm using Oracle 8i.

I want to move some objects (tables with their data) from Dictionary Managed Tablespaces (DMT) to Locally Managed Tablespaces (LMT).

I'm planing to use the MOVE command:

ALTER TABLE tbl_name

MOVE TABLESPACE tbs_name;

The problem is that these objects (tables) are used all the time by my application server!! Some packages, views are also bounded to some of these tables. I know that after moving tables, I have to rebuild their corresponding indexes.

Can I execute this MOVE operation while the application server is using the objects that I'm moving (how does it eventually affect my application - beside the index use!)?

When MOVing my objects: would it disable/drop (?) the bounded packages, views?... Should I recompile them? Extract the DDL and re-run the DDL?

Thank you a lot in advance for your tips.

Regards,

Patrick.

 
Re: alter table table_name MOVE TABLESPACE tbs_name [message #60573 is a reply to message #60572] Tue, 17 February 2004 03:38 Go to previous messageGo to next message
Frank Naude
Messages: 4580
Registered: April 1998
Senior Member
Hi,

You will most likely run into problems. With 8i and 9i one can only move "nonpartitioned index-organized tables" online (ALTER TABLE MOVE ... ONLINE ...;).

Objects that were valid before the move should remain valid.

Best regards.

Frank
Re: alter table table_name MOVE TABLESPACE tbs_name [message #60581 is a reply to message #60573] Tue, 17 February 2004 15:12 Go to previous messageGo to next message
andrew again
Messages: 2577
Registered: March 2000
Senior Member
If you can afford a small downtime-time window, then you should be able to get it done quite quickly. Rebuild the indexes right after moving the table (and then maybe regenerate stats too after the indexes). As long as you don't try to execute on of the packages/procs/trigs/functs while they won't compile then you should be safe. Broken code will attempt to re-compile once when you try to execute it (directly or indirectly due to dependencies). If it fails to re-compile then you need to do a manual compile. Note that LOB segments won't move to the new tablespace so for those you'll need to export, drop/offline the old TS and then import. You can also use create New as select * from Old and then rename, replace constraints etc. To keep new LOB segments out of your old TS, change the default for the user or build up the verbose DDL yourself.

Search asktom.oracle.com for Moveall.sql
recompile script could be useful too...
-- from DBA account
 SELECT 
 'alter '||decode(object_type,'PACKAGE BODY','PACKAGE',object_type) ||' '||owner||
  '."'||object_name||'" '||decode(object_type,'PACKAGE BODY','COMPILE BODY','COMPILE')||';' 
 FROM all_objects 
 WHERE owner like '%'
 AND owner not in ('SYS', 'SYSTEM')
 AND object_type IN 
 ('PACKAGE','PACKAGE BODY','VIEW','PROCEDURE','TRIGGER','FUNCTION') 
 AND status='INVALID';

Re: alter table table_name MOVE TABLESPACE tbs_name [message #60586 is a reply to message #60581] Tue, 17 February 2004 22:52 Go to previous messageGo to next message
Patrick Tahiri
Messages: 119
Registered: January 2004
Senior Member
Hi,

Thank you for your answers!

So while I'm moving a table (non-partitioned):

1. Grants, constraints won't be dropped and will follow.

2.Triggers, Views, procedures, packages will be valid if note executed during the move. If called/executed/fired during the move they will be set to invalid and I will have to compile them again after moving my table!

3.Have to rebuild the binded indexes after the move!

Is it correct?

Thank you again!

Regards,

Patrick Tahiri.
Re: alter table table_name MOVE TABLESPACE tbs_name [message #60594 is a reply to message #60586] Wed, 18 February 2004 09:23 Go to previous message
andrew again
Messages: 2577
Registered: March 2000
Senior Member
I'm not aware of any limitations with partitioned tables, but there may be issues. There are issues with LOBs and probably CLOBs too. Not sure about nested tables. In my experience, if you try to move something which can't be moved, you won't do any damage - it just fails to move.

Regarding the invalidation of code - I wasn't very clear. Move, rebuild won't break code, not sure what happens if you try to execute code while the move, rebuild are in progress.

Generally if you invalidate code (e.g. by renaming a table), then once you've renamed the table back again, the code will be invalid, but will try to recompile itself when you first try to re-execute it. Sometimes when you break code (it happens with package specs quite often) then code which references that spec won't be able to re-compile by itself.

It's safest to manually recompile any broken code after to re-org to ensure that something isn't still broken. You may need to recompile more than once to get all broken code.

SQL> create table t (col1 number);
Table created.

SQL> create index t_ix1 on t(col1);
Index created.

SQL> CREATE OR REPLACE PROCEDURE t_proc
  2  AS
  3     v1   t.col1%TYPE;
  4  BEGIN
  5     NULL;
  6  END;
  7  /
Procedure created.

SQL> select status from user_objects where object_name = 'T_PROC';

STATUS
-------
VALID

SQL> alter table t move tablespace users;
Table altered.

SQL> alter index t_ix1 rebuild tablespace users;
Index altered.

SQL> select status from user_objects where object_name = 'T_PROC';
STATUS
-------
VALID
Previous Topic: move tables including longs to another tablespace
Next Topic: sys : insufficient privileges
Goto Forum:
  


Current Time: Fri Sep 20 12:46:10 CDT 2024