alter table table_name MOVE TABLESPACE tbs_name [message #60572] |
Tue, 17 February 2004 00:55 |
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 #60581 is a reply to message #60573] |
Tue, 17 February 2004 15:12 |
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 |
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 |
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
|
|
|