數據庫版本頻繁更新不同版本數據庫之間的移植是經常讓數據庫管理員頭疼的問題數據庫移植不僅僅是導出導入的過程由於新舊運行平台操作系統應用設備等的不同其中涉及的問題方方面面本文將為大家介紹Oracle Database g數據庫移植的技巧會遇到的問題和解決方案以及實施移植的步驟等方面內容
在數據庫聲明周期中最常發生的一件事就是不斷地把數據庫從老版本移植到新版本不同版本之間的數據庫移植有時候可能就像把數據從老版本裡導出再導入到新版本中一樣簡單不過其中涉及到的問題往往比你想象中復雜得多而且移植過程還會涉及到其他一些顯著的改變例如操作系統改變模式修改以及相關應用軟件的變化等等每一項變化都存在著固有的風險性不過人們常常認為還是應該把這些變化全部結合起來一起清除來個一勞永逸而且這樣在移植過程中從頭到尾都不去進行檢測這種情況出現了如此頻繁實在讓人非常驚訝
從一個軟件工程師的觀點來看把這麼多重要的改變通通放在一個步驟裡實現是不是很好的解決辦法並且足夠安全呢?此外不僅僅是實施移植而已還要在實際移植之前檢測這些變化是否適用於目標環境
還有其他一些值得注意的地方在依賴關系鏈打斷移植過程之前先把它給打斷了否則受打擊的將是你假設在從Oracleg移植到g的情況下要把基層操作系統從Linux改為Solaris在一個模式裡修改主表並且運行更新的或修改了版本的相關應用軟件那麼應該在哪些步驟打斷依賴關系鏈呢?換句話說哪些步驟更加更安全更熟悉並且被其他很多人應用過了?而哪些步驟其他人都沒有嘗試過而只適用於你的情況呢?
分清楚哪些是已經被實踐過的而哪些又是未知的
如果你是Oracle新版本的邊緣用戶或者是最近才開始使用新版本的用戶那麼在你(和你的公司)准備從老版本的關系數據庫管理系統軟件移植到新版本之前已經有很多前輩為你做過預演了同樣的那些前輩們已經跨越了采用Linux作為基本操作系統所帶來的陰暗面
考慮到關系數據庫管理系統和操作系統的綜合轉換已經被大家所熟知你的數據庫產品所依賴的版本和操作系統是打破依賴關系鏈的理想之所在如果把所有的操作都結合在一起一步到位的實施那麼移植過程是一個要麼成功要麼失敗的過程沒有中間地帶而失敗意味著時間可能都會浪費在這個過程的最簡單部分也就是說數據的移出和移入要花費大把的時間如果失敗這些過程的執行等於做了無用功如果你把整體移植過程至少分成兩個不同的階段你將會把依賴關系鏈分割成若干小的關系鏈這個必須熟習的指導性原則就是通過安全漸進的步驟完成移植過程
對於數據庫模式和應用軟件的處理則要由你自己來決定除非你已經對模式和應用軟件的轉換進行了徹底測試並使其正常運作了否則整體移植過程的這一部分是否成功仍是個未知之數如果讓新應用軟件和數據庫上線然後才發現新軟件和數據庫代碼會導致連鎖觸發(cascading triggers)反應(將會導致實例癱瘓)這樣的情況會讓你沮喪不已實際產品環境中常包含成千上萬條記錄而開發人員和測試人員在測試環境下的測試規模只有一百條記錄很難進行一次徹底的測試
手動操作和設置導出和導入過程
關於導出和導入的實用工具你不一定要接受其默認參數事實上你應該采用大部分的自定義設置這樣能夠使移植過程更容易進行而且在產品環境實際進行操作時能夠節省大量時間
我們首先來看看索引文件的參數設置在導入過程中最好使用indexfile=filename的設置原因至少有四條
第一這樣可以把表和索引等對象信息(全部或部分取決於導出dump文件中包含了什麼內容)存儲在指定的輸出文件中想知道創建模式的源代碼在哪裡嗎?如果你沒有源代碼那這個參數(連同一個返回所有其他信息的簡單查詢)對於這些信息的提供會有很大幫助查詢部分會將全部的或user_source數據字典的內容輸出到文件中包包體存儲過程函數和觸發器等代碼信息都包括在輸出的結果文件裡再稍微加工一下例如執行CREATE OR REPLACE命令清除SQL*Plus工具存儲區域裡無用的結果(如標題行換頁等)剩下的就是一個模式最重要那部分的當前代碼
第二如果你想對表和索引對象進行清洗或重排操作那麼在導入時通過這一設置對索引文件進行編輯並對表空間映射和存儲參數進行更新時機恰到好處
第三如果你想讓邏輯布局維持原樣可以分隔索引和表也就是分離SQL CREATE命令(一部分腳本專門用於創建表另一部分專門用於索引)在進行實際的移植之前要盡可能先設置好目標數據庫其中一部分工作就是創建新的同樣的表空間並運行創建表的腳本提前運行創建表的標本有兩個理由一是使邏輯布局生效二是提高移植導入的速度
第四個原因回到了索引文件中所列的索引當執行數據批量插入時是有索引好呢還是沒有所以更好呢這對於插入效率有多大的影響?由於每插入一個新記錄就必須更新一個或多個索引(假設該記錄至少有一個主鍵)所以對於大型數據庫而言Oracle的建議是等所有的數據都已經插入完畢後再構建索引這樣的建議無疑又重申了indexfile的重要性因為當導出時使用indexes=n(默認設置是y)的設置把索引忽略掉以後想要在數據全部導入完畢後重新構建索引indexfile就是銜接的橋梁
數據庫移植不是簡單的導出導入
Oracle g最早的版本是運行在Linux系統下的也提供安裝了相關的關系數據庫管理系統軟件你所運行的新實例包含了很多意想不到的新特性不過這一切都得在你成功的把源數據庫(或模式)移植新的目標數據庫之後再說你可能正計劃在周五的半夜占用八小時的停工和維護時間來執行移植操作那麼在移植之前你可以做些什麼來盡可能保證整個移植過程順利無痛的進行呢?只要你對以下四個重要方面做好規劃就可以使你的移植過程與眾不同統籌管理導出階段導入階段和交接階段
統籌管理/項目規劃
如果你是數據庫移植計劃的負責人你肯定希望整個移植過程能夠像你所計劃的那樣步步順利
為了使所有的移植步驟能夠順利進行你需要制定一個詳細的計劃流程圖如果沒辦法做到上述要求那麼最低限度你可以制定一條低技術路線拿出一份計劃時間表來即使你只是在心血來潮的時候把想法和問題記錄下來對於讓所有人在移植過程中達到步調一致也能起到一定的作用最好能把以下的方面都認真考慮加以計劃
圖解移植計劃流程召開協調會議
落實每一個團隊成員責任確定他們在移植過程中的角色和應負的責任
制定一份聯系名錄包括如何聯系其他關鍵人員(包括主管系統管理員測試人員開發人員第三方軟件供應商客戶帳戶主管等等)把這份名錄分發給相關成員
確定對某些特殊客戶的移植操作時間
在工作結束後告知相關負責人員約定時間和地點
通知辦公樓保安人員(以及清潔工作人員)關於你們要在辦公室裡加班的事情以免引起不必要的誤會
為文件系統建立一個傳輸點保證有足夠的磁盤空間用來導出數據
要深入認識模式的變化包括修改關鍵表的時間和機理數據轉換過程等)
安排好計劃進度表搞清楚是不是整個移植過程中每個數據庫管理員都需要留下來全程陪護還是可以把每個人的時間錯開
預導出和導出階段
如果你(或導出操作的負責人)時間充裕的話你完全可以事先對導出操作進行多次演練確保移植計劃的這個環節再沒有什麼小問題出來騷擾你導出過程必須是一步式操作嗎?不是的可以根據功能群來分階段實施導出過程可以考慮把導出過程分解成以下幾個功能群支持表主表已修改表歷史/靜態表
通過以這種方式把表分成不同的功能群你可以交替進行導出和導入操作操作一旦某類群的導出操作完成了你就可以著手進行相應的導入操作在分開執行的情況下導出過程可能需要兩個小時而導入過程可能得花四個小時;但並不意味著需要連續運行六個小時才能完成整個過程為什麼導出和導入花費的時間不一樣呢?要知道導出和導入並不是一對一的鏡像關系不要忘記索引是不需要導出的而是在數據都加載到目標數據庫之後才重新構建所以導出過程要比導入過程運行得快一點如果稍微優化一下兩者都可以以更快的速度運行你要怎麼驅動導出過程是用交互模式(interactive mode)還是使用shell 腳本和參數文件的非交互模式?Linux下的Shell腳本具有四個主要的特點
它是一個訪問讀取過程
能夠追蹤反饋信息分析總結系統登錄檔案
檢測管理系統的功能(包括參數文件根據制定路徑存儲dump和日志文件的功能數據庫連接等)
關鍵步驟或操作之後會詢問是否需要繼續執行的退出機制
只要一個腳本就能夠驅動整個導出進程而且退出點可以作為指示信號使用(和echo語句一起廣泛使用可以指示運行到了進程的哪一個步驟)演練和完善腳本過程中一個主要的度量標准就是執行完整個導出操作所花費的時間
如果正在進行的是一個模式移植(schema migration相對於全庫移植)那麼模式之間的依賴性是什麼?找找諸如build_managerprocess_logger等名稱或項目Build_manager可能包含一般或公共函數過程和包Process_logger則可能包含所有模式的進程日志(在一個源文本文件中常常能看到pragma autonomous_transaction這是在執行事務失敗過程發現錯誤的一種方法)除非新模式整合了這些外部的和相關的模式否則必須在目標數據庫中為這些被遺留下來的部分模式進行說明解釋
如果正在執行導出操作那些非導出的模式可能會導致一些問題的出現所以當執行導出操作的時候你可能需要禁用連接修改密碼屏蔽其他進程暫停cron服務網絡程序的連接往往像雜草一樣難以遏制而防止其連接的有效方法之一就是修改密碼假設你的導出計劃獲得了圓滿成功最後要決定的就是如何處理源數據庫
導入階段
演練模式的構建和諸如表空間和數據文件等相關物理/邏輯對象的構建這樣做的最終目的是不管怎樣都不要在這個階段出現錯誤提示並保證所有創建腳本都是可重復運行的關於導入的參數文件需要確保源用戶和目標用戶能夠相互匹配利用indexfile的種種好處在目標數據庫中預先創建表
對於正在接受修改的表我們必須清楚這些過程發生在什麼地方發生的時間和機制這些變化是發生在用戶的模式裡嗎?還是隨著新表式的插入發生在某個臨時或移植的模式裡
必須全面了解主表是如何改變的你可能會想當然地認為定義非空約束(NOT NULL constraints)無關緊要不過應用程序的變化完全依賴於它們換句話說如果由於移植過程中出現一些阻滯你試圖重建某個表的時候僅僅關注主鍵約束(PK)外鍵約束(FK)和唯一約束(FK)是不夠的
那定時任務工具cron和數據庫作業呢?你要如何移植/導出所有的這些東西呢?通常與cron作業密切相關的是電子郵件要注意新服務器是否配置好電子郵件通知系統是否需要創建數據庫連接
在導入過程進行的時候是否需要開啟日志記錄呢?有沒有必要把所有導入的事件都記錄到日志裡呢?記錄觸發器是不是有必要特別是對於行級觸發器(即每行都執行)?在導入過程中需要插入數量達百萬以上的行對於行級觸發器每插入一行就需要執行一次甚至更多的觸發器操作如果依賴源數據庫的某個表的觸發器已經執行某些操作那麼在導入過程中有必要再次執行相同的操作嗎?以上這些問題都是需要認真考慮的
你可能很聰明地禁用了不少自動功能以便加快導入過程不過千萬別聰明過頭而忘記把你禁用的功能重新啟用由於移植過程很可能都是在午夜進行睡意朦胧的你很可能會導致大量人為錯誤的產生如果你實在不是熬夜的料最好讓其他人幫你檢查這些工作和操作步驟特別是當運行的對象對於數據庫或模式來說至關重要重要的時候
導入後需要關注的事項
所有的移植工作都順利完成了?你以為可以松一口氣了不過任務還沒有真正結束你還需要創建基礎備份所以你必須搞清楚以下問題是不是應該在移植完成新數據庫構建完畢後立即著手進行備份?你是不是已經能夠成功地從導出備份冷備份和熱備份轉變到RMAN備份?你之前有沒有練習過RMAN備份和恢復操作?
首選方案當然是在移植順利完成後立即開始進行備份不過前提是移植過程非常順利你的計劃和目標非常明確假設由於某些不定因素導致移植完成後應用軟件無法正常運行又該怎麼辦呢?移植完成後產品環境下的完全測試可以減少這種情況的發生但是如果沒有進行大規模測試呢?要怎樣才能回復到源數據庫狀態?你是不是還有足夠的時間重新再來一遍?只要你對導出過程會發生的問題有充分的認識就不會有二次嘗試的必要了
不要以為每個人都對發生的事情了如指掌客戶支持人員是不是知道如何把桌面工具軟件指向新的數據庫?還是會在抱怨對數據庫的修改無效後幾個星期才知道代開trouble tickets系統查看對於作為數據庫管理員的你來說閉上眼也能顯而易見的東西對於那些不懂數據庫語言的人而言可能相當晦澀
總結
本文所涵蓋的數據庫移植技巧步驟和問題都來源於真實的案例就像上面說的有些客戶服務代表會抱怨數據庫沒有顯示數據的變化很可能是不清楚該如何把桌面客戶關系管理工具指向新數據庫而導致的這應該是數據庫管理員的責任還是客戶代表主管的責任呢?插入變換格式後的數據和工作區到主表中也常常會出現問題這就很可能和非空約束有關了
關於數據庫移植有一個最起碼的常識如果你連事先進行測試並處理好導致失敗的問題的時間都沒有你更不可能有時間來做第二次嘗試?關於移植過程中起到作用的一些外部因素本文所提到的一些技巧和注意事項進行了深入的解析希望大家看過之後在數據庫移植過程中能少走彎路順利完成升級
From:http://tw.wingwit.com/Article/program/Oracle/201311/17107.html
