基礎架構遷雲（三）

遷雲工作的準備階段當然少不了對現有環境的調查，這是一個很重要的階段，怎麼遷，也是需要這個作為依據，所以這個階段不能馬虎。

1，整體的來說需要根據以往老的資料庫拓撲圖以及自己的瞭解補充畫出新的拓撲圖，這是一個從整體宏觀方面去了解資料庫的整體情況，這裡又有一個細節需要注意：注意dblink的關聯，一般透過ogg，dg、rac以及儲存這些都比較容易理清，dblink這個影藏關聯容易被忽略。

在這次整理dblink的時候，有下面幾種情況出現：1，很多邊緣資料庫與核心生產庫有dblink關聯;2，邊緣庫與核心庫中有許多無效的dblink(一般只對方tnsping不通);3，業務方面已經不再使用但依然可以訪問的dblink;4，存在很多public的dblink;5，dblink的命名不容易區分。

2，資料庫容量，雖然年都會做資料庫容量調查，以便檢視今年相比去年增加多少資料量，遷移前期統計各個資料庫的容量也是很有必要的，資料庫容量小的資料庫可以採用(expdp/impdp、exp/imp)的方式。調查發現邊緣資料庫的容量都是200G以下，核心庫的容量是500G和2.5T左右，所以邊緣資料庫都是採用expdp/impdp、exp/imp的方式從9i、10g、11g遷移到11g的，核心資料庫一開始要做字符集轉換，所以遷移方法還未確定。

3，資料庫的版本，什麼樣的版本也決定了採用什麼樣的遷移方式，邊緣資料庫有9i、10g、11g等版本，核心資料庫都是9i。邊緣資料庫9i到11g小容量的遷移採用是exp/imp，10g、11g到11g採用的是expdp/impdp，其次就是各個版本中安裝了哪些元件，比喻 XDB、XML，XDK等，這些元件遷移到11g相容性的問題，其實版本調查最主要的還是影響遷移方式。

4，資料庫的備份，目前資料庫都有哪些備份方式，rman或者是expdp，備份策略以及備份頻率等等，這次調查之後，發現有一些邊緣資料庫沒有備份，感覺是工作上的一次失誤，雖然是不重要的邊緣資料庫，但是保留7天左右的dmp檔案還是要必要的。

5，資料庫伺服器，資料庫是承載在伺服器上，所以對資料庫伺服器也要考慮在內。核心資料庫作業系統的版本，CPU現有的頻率(數量*頻率*核數)近段時間CPU的平均使用值是多少、CPU的峰值是多少，作業系統的記憶體容量、近段時間記憶體的使用率，有沒有pageout、pagein交換，作業系統各個目錄的使用情況、有沒有做raid保護。目前邊緣資料庫都是windows，有些資料庫的資料直接存放在本地硬碟上，有些做了raid，有些沒有做任何保護，全靠備份，所有上面說的備份很重要，尤其需要有多個地方存放備份。

6，儲存，這裡主要是核心庫儲存，考慮到現有的資料容量，每年的有多少容量的增長，備份需要多少容量(備份存放策略)，日誌需要多少容量(每天產生多少日誌以及存放多久)

7，現有的災備情況，災備大體的情況如這篇http://blog.itpub.net/29609161/viewspace-2677628/ 博文中的拓撲圖，主要還是採用儲存快照、dg、ogg以及備份，日誌有一個單獨的存放點，放在一臺netAPP中，保留60天，個人感覺使用單獨一臺nas存放歸檔日誌是很有必要的，即安全又方便。

------這裡簡單的介紹了一些大的方向