利用PLSQL實現表空間的遷移(五)
在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過程執行完成。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/4227/viewspace-622741/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 利用PLSQL實現表空間的遷移(一)SQL
- 利用PLSQL實現表空間的遷移(二)SQL
- 利用PLSQL實現表空間的遷移(四)SQL
- 利用PLSQL實現表空間的遷移(三)SQL
- 利用RMAN遷移表空間碰到的問題(五)
- 利用CONVERT實現跨平臺表空間遷移
- 表空間遷移
- 遷移表空間
- 【實驗】利用可傳輸表空間技術實現資料的高效遷移
- 利用RMAN遷移表空間碰到的問題(四)
- 利用RMAN遷移表空間碰到的問題(三)
- 利用RMAN遷移表空間碰到的問題(二)
- 利用RMAN遷移表空間碰到的問題(一)
- 【遷移】表空間transport
- RMAN遷移表空間
- 遷移表到新的表空間
- ORACLE表批量遷移表空間Oracle
- 遷移SYSTEM表空間為本地管理表空間
- 基於可傳輸表空間的表空間遷移
- expdp/impdp 遷移表空間
- Oracle10g新特性——利用RMAN遷移表空間Oracle
- 跨平臺表空間遷移(傳輸表空間)
- Oracle中表空間、表、索引的遷移Oracle索引
- table/index/LOBINDEX遷移表空間Index
- lob欄位表空間遷移
- Oracle10g新特性——利用RMAN遷移表空間(二)Oracle
- Oracle10g新特性——利用RMAN遷移表空間(一)Oracle
- Oracle 不同平臺間表空間遷移Oracle
- MySQL 遷移表空間,備份單表MySql
- 表、索引遷移表空間alter table move索引
- 空間遷移
- 利用可傳輸表空間跨平臺遷移 -RMAN CONVERT
- 利用oracle10g_rman_convert_transportable tablespace遷移表空間Oracle
- 分割槽表對應的表空間遷移案例
- 表空間遷移辦法補充
- 使用RMAN簡單遷移表空間
- 資料庫物件遷移表空間資料庫物件
- 【資料遷移】使用傳輸表空間遷移資料