項目一：單節點數據庫轉到oracle rac

?

項目簡介（功能與用途）：

項目發生在04年初，由于當時采用的是基于linux的pc server，隨著網站訪問量的突飛猛漲，單臺linux server已經基本達到了瓶頸，主機端系統load基本在10以上，由于linux server的硬件已經不能擴展，而當時的預算又不夠采用小型機，所以需要有一種可擴展方案來解決。這個時候我們就想到了使用oracle 9i rac來實現數據庫的橫向擴展，同時對應用系統做切分，分成了3個數據庫，每個庫設計容量是2個節點，可以提供一天5000萬次訪問量的方案。

?

項目難點與解決方案：

在確定方案后，我們開始針對機器進行選型測試，對比hp4640和sun880單節點數據庫和dell linux server跑oracle rac的性能，我們的測試團隊設計了測試用例，用app集群直接跑網站真實應用去測試數據庫性能，測試結果在相同訪問量下dell pc server跑2個節點的rac的sql相應時間最短，所以最終選定了dell linux server＋oracle rac的方案。在存儲方面我們最初是用netapp的nas存儲作為數據庫存儲，但是在使用過程中發現netapp的nas存儲在數據塊頻繁變化的環境下多塊讀的效率不是十分理想，所以決定采用emc 的CLARiiON系列存儲。選型完畢后項目進入實施階段,實施初期是搭建san存儲架構，把所有emc存儲通過光纖交換機和主機相連，每2臺pc server拖一臺存儲，一共是6臺pc server加3套存儲。在存儲架構搭建完畢后，我們開始創建oracle rac，采用2個節點的rac， 然后開始進行數據遷移方案，我們使用oracle 的materialized view來同步大表，在切換前幾天基本實現新老系統的大表持續同步，在系統切換當晚我們切斷老系統，刷新materialized view最后一點還沒同步的數據到新系統，同時遠程insert小表到新系統，總共切換時間在30分鐘之內完成。系統切換后重新啟動應用服務器，整個應用系統正常提供服務。

?

項目成功與失敗的經驗歸納：

在新系統上線后，主機端load下降到0.5左右，用戶反映系統相應速度明顯提升，app服務器的等待隊列明顯減少，在很長一段時間里面這套系統都表現出了相當穩定的運行狀態。

這是我們第一次使用集群數據庫，同時也是第一次使用san存儲，整個方案完全由我們的DBA,SA,JAVA構架師，測試團隊制定并實施，在當時的業界我們的做法還是比較領先的，也是oracle rac的早期用戶。在一段時間的穩定期后，由于業務的飛速發展，我們的系統訪問量達到了8000萬次每天，在這個時候rac的一些弊端開始顯示出來，由于應用沒有不是針對RAC系統專門開發的，所以rac cache fusion的代價非常大，在變化頻繁的系統上，rac 的一系列wait event占據了大部分的系統等待時間，系統效率開始下降。同時當一個節點發生問題時而down掉時，另一個節點要恢復壞掉的節點的數據，在這個恢復階段所有應用將hang住直到恢復完畢，通常在這個時間段里面前臺的app服務器由于請求太多不能響應而掛掉，所以基本上在繁忙的系統上rac的平滑切換將很難實現，這也決定了我們后來從RAC退回到單節點數據庫。

?

你在項目中崗位與貢獻：

負責制定產品預算 負責產品選型溝通

參與制定測試用例 參與測試

負責San網絡搭建 負責系統安裝調試

負責存儲規劃 負責數據庫建立

負責數據遷移 負責系統切換

負責后期維護 負責后期應用優化

sql審核，sql培訓

?

?

?

?

項目二：dell linux server向ibm p590系統遷移

項目簡介（功能與用途）：

項目發生在05年初，距離上次系統升級一年時間，在這一年時間里，公司業務飛速發展，日訪問量從2000萬次增長到8000萬次以上，oracle rac在這急速增長的壓力下也暴露出一些問題，由于rac cache fusion的內耗越來越嚴重，再對rac擴展節點的方案基本被否定，同時因為rac的維護成本比單節點數據庫要高很多，所以我們定下來下一步方案要采用基于UNIX小型機的單節點數據庫。系統設計容量要求要能支撐2億次每天的訪問量。

?

項目難點與解決方法：

和上一次升級一樣，我們從硬件測試選型開始，這次我們選型了hp superdome Integrity服務器和IBM P590進行對比測試。和上次系統升級一樣，我們的DBA,測試團隊，JAVA架構師組成了一個特別測試組去hp和ibm的測試中心進行了對比測試，用我們自己的系統跑測試，最后對比下來IBM的P590在高并發情況下機器的響應時間曲線比較平穩，同時由于AIX系統的很多自動化管理功能可以簡化對主機的維護工作，我們最終選定了IBM P590做為新的數據庫服務器。在存儲方面，我們處于成本考慮并沒有更換原先的存儲，繼續使用了EMC CLARiiON系列存儲。由于我們在上一次系統升級后對所有rac數據庫又建立了dataguard做備份數據庫，這次升級我們把dataguard庫的CLARiiON存儲先行接到了P590上，然后在p590上建立oracle數據庫，同上次系統升級一樣，我們采用materialized view來同步數據，力求達到最短停機時間。同時我們調整了我們所有的監控腳本，保證了新系統的預警功能。另外我們建立了dataguard系統，保證了系統的可靠性。最終切換時間我們也控制在了每個數據庫30分鐘以內。

?

項目成功與失敗的經驗歸納：

P590系統上線后，我們的系統load從6下降到1以下，另外我們使用了AIX的LVM來管理磁盤，降低了很多原來使用linux raw device管理上的成本。

這是我們第一次使用基于UNIX的服務器，也是國內最早一批使用P590的用戶，在系統上線相當長的一段時間內都保證了業務的可持續快速發展。在系統升級的實施方面由于有了上一次的經驗，這次升級做到了更加平滑的切換，所有的監控腳本都經過測試運行，保證了新系統的預警。在這套系統跑了一段時間以后，主機端依然提供了非常強勁的功能，但是由于數據庫的不斷擴大，越來越多的i/o等待開始暴露出來，針對這個問題我們升級了主機的內存，加大了data buffer,同時為了保證系統的可擴展性，我們最終選用了sun 9990系列存儲，基本上是系統實現了線性可擴。

?

你在項目中崗位與貢獻：

負責制定產品預算

負責產品選型溝通

參與制定測試用例

參與測試

負責San網絡搭建

負責存儲規劃

負責系統安裝調試

負責數據庫建立

負責數據遷移

負責系統切換

負責監控體系建立

負責后期維護

負責后期應用優化，sql審核，sql培訓

?

?

?

?

項目三：淘寶網遠程容災站點,建立容災數據庫

項目簡介（功能與用途）：

在系統切換到了UNIX平臺后，我們的關注點從性能開始轉換到高可用性上，陸續建立了dataguard，hacmp，提高了系統的高可用性。這個時候我們覺得應該考慮災備，美國的911事件導致了很多公司一夜之間所有數據都消失無蹤，對于我們這種對數據庫依賴性極大的公司來說，數據就是生命，我們一定要做好災難備份。處于成本和實施難度考慮，我們提出了整個災備的過程分3部走的想法，首先建立一個最簡單的容災站點，可以保證數據不丟失，但災備站點不提供對外服務。第二步，實現準實時不同城市間的復制，災備站點不對外提供服務，但是碰到主站點災難可以切換到災備站點進行服務。第三步，準實時的多站點復制，災備站點同時提供服務。

?

?

?

項目難點與解決方法：

由于實施第一步方案受限于預算和災備機房的線路問題，我們把災備站點定在本城市另一端的一個機房，通過裸光纖鏈路和主站點相連，采用了低于主站點的服務器配置，用了一臺IBM P550服務器做為3個主庫的dataguard，連接一臺EMC CLARiiON存儲，dataguard端一直處于恢復狀態，實現在災難時最多發生20分鐘的的數據丟失。

?

?

?

?

?

項目成功與失敗的經驗歸納：

項目上線后數據同步良好，基本實現系統設計目標，以最小的成本構建了一套可用的災備系統。

項目實施成本一直是私營企業最關注的，我們的所有項目都面臨著把每一分錢花在刀刃上，所有的項目方案都由公司內部人員討論得出，顯示了團隊的強大的戰斗力。在我們以后的項目中，我們依然會追求以最小成本獲得最大收益，我相信中國絕大部分公司都是中小企業，都將會面臨到和我們一樣的問題，我們走過的路，做過的項目是對他們最好的指導。

?

?

?

?

你在項目中崗位與貢獻：

負責制定產品預算

負責產品選型溝通

負責San網絡搭建

負責系統安裝調試

負責存儲規劃

負責數據庫建立

負責監控體系建立

負責后期維護

?

?

?

?