傳輸表空間TTS操作

遷移或備份資料庫可以采用傳輸表空間技術TTS，優點是操作較簡便，隻需要将中繼資料進行導出導入，資料檔案可以使用FTP方式從源庫拷貝至目标庫；缺點是資料檔案傳輸至目标庫之前，需要将源庫表空間置為隻讀，相當于停業務，是以需要根據業務要求來判斷是否可以采用這種方式，下面就針對TTS做一個簡單的實驗，感性地體會下其操作過程。增強版的XTTS未來有機會再做實驗。

實驗環境：

為了處理簡單，源庫和目标庫均采用了11.2.0.4的版本，且位元組序相同(其實TTS強大的一點就是可以借助RMAN做不同位元組序、平台的轉換，這點可以參考eygle大師的《深入淺出Oracle》一書，專門有一章介紹了這部分内容)。

1.源庫驗證待傳輸表空間(dcsopen_tbs)是否自包含，是否符合使用傳輸表空間的前提條件

如果待傳輸的表空間有對象引用了其他非要傳輸的表空間的對象，例如索引，則需要事先解決這個問題，也就是要傳輸的表空間對象必須是自包含的。執行上述包，若存在違反限制的情況，則下面這條SQL會傳回錯誤資訊：

2.将待傳輸表空間置為隻讀

3.導出中繼資料

4.目标庫導入中繼資料

這其中可能有一些容易犯錯的地方：

錯誤1：若dcsopen_tbs01.dbf還未拷貝FTP至目标庫，此時執行了：

則執行導入會報錯：

因為表空間置為隻讀，是為了保證資料的一緻性，是以需要在拷貝完成後才能将其置為可讀寫狀态。

<a href="https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1424004061629">https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1424004061629</a>

錯誤2：若目标庫沒有和源庫相同的使用者，則報錯：

當然，既然使用資料泵，應該可以使用remap_schema參數做映射替換，感興趣的朋友可以嘗試。

另外，如果不知道目标庫使用了什麼使用者導出的，可以使用sqlfile參數：

他會生成一個ddl.sql檔案，顯示了這份dmp檔案的内容，其中有一部分就會檢查使用者，這樣你就可以知道是什麼使用者了：

錯誤3：如果第二次導入，未删除第一次舊的dump檔案，則會報錯：

這點你不能說不好，還未探究是否有參數可以跳過了。

5.導入完成後，此時檢視目标表的表空間

狀态是隻讀，需要手工打開，

這樣就完成了表空間的遷移過程，當然這實驗省略了很多内容，例如位元組序、跨平台等等，實際情況可能會更複雜。