基礎架構遷云（三）

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

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存放歸檔日志是很有必要的，即安全又方便。

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