在9i的時候，表空間的遷移使用EXP/IMP來實現。在10g中，除了使用EXP/IMP之外，還可以使用資料泵EXPDP/IMPDP，以及RMAN的命令TRANSPORT TABLESPACE命令，除此之外，還可以透過PL/SQL包DBMS_STREAMS_TABLESPACE_ADM來實現。

這一篇介紹DETACH_TABLESPACES過程。

利用PLSQL實現表空間的遷移（一）：http://yangtingkun.itpub.net/post/468/484859

利用PLSQL實現表空間的遷移（二）：http://yangtingkun.itpub.net/post/468/485388

利用PLSQL實現表空間的遷移（三）：http://yangtingkun.itpub.net/post/468/491799

利用PLSQL實現表空間的遷移（四）：http://yangtingkun.itpub.net/post/468/491878

在前面幾篇文章中，分別介紹了CLONE, ATTACH以及PULL對應的過程，這裡最後描述一下DETACH過程。DETACH和CLONE、PULL以及EXPDP/EXP的實現上都有所區別，執行DETACH過程後，需要傳輸的資料檔案和對應的dmp檔案都準備完畢，而對應的表空間也將從資料庫中被刪除。

目標資料庫和當前資料庫具有相同的資料庫版本、資料塊大小、以及字符集，這裡就不再重複檢查了。需要檢查的是，被遷移表空間是否是自包含的。

SQL> SELECT DISTINCT OWNER
2 FROM DBA_SEGMENTS
3 WHERE TABLESPACE_NAME = 'ZHEJIANG';

OWNER
------------------------------
ZHEJIANG_OPERATOR
ZHEJIANG
ZHEJIANG_KHD

SQL> SELECT DISTINCT TABLESPACE_NAME
2 FROM DBA_SEGMENTS
3 WHERE OWNER IN ('ZHEJIANG', 'ZHEJIANG_OPERATOR', 'ZHEJIANG_KHD');

TABLESPACE_NAME
------------------------------
ZHEJIANG

SQL> SELECT FILE_NAME
2 FROM DBA_DATA_FILES
3 WHERE TABLESPACE_NAME = 'ZHEJIANG';

FILE_NAME
------------------------------------------------------------------------------------------------------------------------
/dev/vx/rdsk/datadg/tradedb_zhejiang_1_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_2_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_3_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_4_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_5_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_6_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_7_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_8_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_9_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_10_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_11_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_12_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_13_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_14_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_15_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_16_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_17_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_18_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_19_4g
/dev/vx/rdsk/datadg/tradedb_zhejiang_20_4g

已選擇20行。

SQL> EXEC DBMS_TTS.TRANSPORT_SET_CHECK('ZHEJIANG')

PL/SQL 過程已成功完成。

SQL> SELECT * FROM TRANSPORT_SET_VIOLATIONS;

未選定行

表空間已經處於只讀狀態，就不用額外進行設定了：

SQL> SELECT TABLESPACE_NAME, STATUS
2 FROM DBA_TABLESPACES
3 WHERE TABLESPACE_NAME = 'ZHEJIANG';

TABLESPACE_NAME STATUS
------------------------------ ---------
ZHEJIANG READ ONLY

建立DETACH_TABLESPACES過程所需的目錄：

SQL> CREATE OR REPLACE DIRECTORY D_READFILE AS '/dev/vx/rdsk/datadg';

目錄已建立。

SQL> CREATE OR REPLACE DIRECTORY D_WRITEFILE AS '/data/transport_zhejiang';

目錄已建立。

下面就可以執行DETACH_TABLESPACES過程了，需要注意，這個過程的輸入引數包括了索引組織表型別和記錄，因此需要透過建立一個PL/SQL匿名塊來完成呼叫，注意輸入引數變數的宣告需要用DBMS_STREAMS_TABLESPACE_ADM包中的型別進行宣告，否則呼叫會報錯：

SQL> SET SERVEROUT ON SIZE 1000000
SQL> DECLARE
2     V_JOB_NAME VARCHAR2(30) := 'MY_DETACH_TABLESPACES';
3     V_TABLESPACE_NAME DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
4     V_DUMPFILE DBMS_STREAMS_TABLESPACE_ADM.FILE;
5     V_LOGFILE DBMS_STREAMS_TABLESPACE_ADM.FILE;
6     V_DATAFILES DBMS_STREAMS_TABLESPACE_ADM.FILE_SET;
7 BEGIN
8     V_TABLESPACE_NAME(1) := 'ZHEJIANG';
9     V_DUMPFILE.DIRECTORY_OBJECT := 'D_WRITEFILE';
10     V_DUMPFILE.FILE_NAME := 'zhejiang_091217.dp';
11     V_LOGFILE.DIRECTORY_OBJECT := 'D_WRITEFILE';
12     V_LOGFILE.FILE_NAME := 'zhejiang_091217.log';
13     DBMS_STREAMS_TABLESPACE_ADM.DETACH_TABLESPACES(V_JOB_NAME,
14             V_TABLESPACE_NAME,
15             V_DUMPFILE,
16             V_LOGFILE,
17             V_DATAFILES);
18     FOR I IN 1..V_DATAFILES.COUNT LOOP
19             DBMS_OUTPUT.PUT_LINE(V_DATAFILES(I).FILE_NAME);
20     END LOOP;
21 END;
22 /
DECLARE
*
第 1 行出現錯誤:
ORA-02449: 表中的唯一/主鍵被外來鍵引用
ORA-06512: 在 "SYS.DBMS_STREAMS_TABLESPACE_ADM", line 885
ORA-06512: 在 line 13

執行過程報錯了，用了幾次的DBMS_STREAMS_TABLESPACE_ADM包，似乎只有第一次執行PULL_SIMPLE_TABLESPACE過程時沒有報錯，剩下的幾次雖然也都成功了，但是多少都會出現一些錯誤。

不過這次的錯誤多少有些奇怪，看錯誤資訊似乎和遷移表空間的關係不大，倒是和前一段時間刪除表空間時碰到的一個bug有些相似。

檢查輸出的LOG檔案資訊：

bash-3.00$ more zhejiang_091217.log
啟動 "SYS"."MY_DETACH_TABLESPACES":
處理物件型別 TRANSPORTABLE_EXPORT/PLUGTS_BLK
處理物件型別 TRANSPORTABLE_EXPORT/TABLE
處理物件型別 TRANSPORTABLE_EXPORT/GRANT/OWNER_GRANT/OBJECT_GRANT
處理物件型別 TRANSPORTABLE_EXPORT/INDEX
處理物件型別 TRANSPORTABLE_EXPORT/CONSTRAINT/CONSTRAINT
處理物件型別 TRANSPORTABLE_EXPORT/INDEX_STATISTICS
處理物件型別 TRANSPORTABLE_EXPORT/COMMENT
處理物件型別 TRANSPORTABLE_EXPORT/CONSTRAINT/REF_CONSTRAINT
處理物件型別 TRANSPORTABLE_EXPORT/TRIGGER
處理物件型別 TRANSPORTABLE_EXPORT/INDEX/FUNCTIONAL_AND_BITMAP/INDEX
處理物件型別 TRANSPORTABLE_EXPORT/INDEX/STATISTICS/FUNCTIONAL_AND_BITMAP/INDEX_STATISTICS
處理物件型別 TRANSPORTABLE_EXPORT/TABLE_STATISTICS
處理物件型別 TRANSPORTABLE_EXPORT/POST_TABLE_ACTION
處理物件型別 TRANSPORTABLE_EXPORT/MATERIALIZED_VIEW_LOG
處理物件型別 TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
已成功載入/解除安裝了主表 "SYS"."MY_DETACH_TABLESPACES"
******************************************************************************
SYS.MY_DETACH_TABLESPACES 的轉儲檔案集為:
/data/transport_zhejiang/zhejiang_091217.dp
作業 "SYS"."MY_DETACH_TABLESPACES" 已於 18:11:02 成功完成

從這裡可以看到，傳輸表空間的匯出工作已經順利完成。

檢查alert檔案：

bash-3.00$ tail -15 $ORACLE_BASE/admin/tradedb/bdump/alert_tradedb1.log
ALTER SYSTEM SET service_names='tradedb.us.oracle.com','SYS$SYS.KUPC$C_1_20091217180920.TRADEDB.US.ORACLE.COM' SCOPE=MEMORY SID='tradedb1';
Thu Dec 17 18:09:23 2009
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$C_1_20091217180920.TRADEDB.US.ORACLE.COM','tradedb.us.oracle.com','SYS$SYS.KUPC$S_1_20091217180920.TRADEDB.US.ORACLE.COM' SCOPE=MEMORY SID='tradedb1';
kupprdp: master process DM00 started with pid=74, OS id=4415
to execute - SYS.KUPM$MCP.MAIN('MY_DETACH_TABLESPACES', 'SYS', 'KUPC$C_1_20091217180920', 'KUPC$S_1_20091217180920', 0);
kupprdp: worker process DW01 started with worker id=1, pid=39, OS id=4477
to execute - SYS.KUPW$WORKER.MAIN('MY_DETACH_TABLESPACES', 'SYS');
Thu Dec 17 18:11:23 2009
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$S_1_20091217180920.TRADEDB.US.ORACLE.COM','tradedb.us.oracle.com' SCOPE=MEMORY SID='tradedb1';
Thu Dec 17 18:11:23 2009
ALTER SYSTEM SET service_names='tradedb.us.oracle.com' SCOPE=MEMORY SID='tradedb1';
Thu Dec 17 18:11:24 2009
DROP TABLESPACE "ZHEJIANG" INCLUDING CONTENTS
Thu Dec 17 18:11:29 2009
ORA-2449 signalled during: DROP TABLESPACE "ZHEJIANG" INCLUDING CONTENTS...

顯然這個錯誤是刪除表空間時碰到的，而傳輸表空間的操作已經完成了。引發這個錯誤的原因在文章http://yangtingkun.itpub.net/post/468/492354中已經進行了描述。

和CLONE_TABLESPACES過程不同，表空間傳輸的源資料生成後，並不會複製一份資料檔案，而是將表空間刪除，資料檔案就保留在當前的位置上。

SQL> DROP TABLESPACE ZHEJIANG INCLUDING CONTENTS CASCADE CONSTRAINTS;

表空間已刪除。

新增CASCADE CONSTRAINTS語句，手工方式刪除表空間後，現在資料庫的狀態和執行DETACH_TABLESPACES操作後保持一致。

至此DETACH_TABLESPACES過程執行完成。

利用PLSQL實現表空間的遷移（五）

相關文章