藍的成長記——追逐DBA（3）：古董上操作，資料匯入匯出成了問題，dba匯入匯出

藍的成長記——追逐DBA（3）：古董上操作，資料匯入匯出成了問題，dba匯入匯出
藍的成長記——追逐DBA（3）：古董上操作，資料匯入匯出成了問題

***************************************聲明***************************************

        個人在oracle路上的成長記錄，其中以藍自喻，分享成長中的情感、眼界與技術的變化與成長。敏感資訊均以英文形式代替，不會泄露任何企業機密，純為技術分享。

        創作靈感源於對自己的自省和記錄。若能對剛剛起步的庫友起到些許的協助或共鳴，欣慰不已。

        歡迎拍磚，如有關技術細節表述有錯誤之處，請您留言或郵件（hyldba@163.com）指明，不勝感激。

***********************************************************************************

生命的意義不是你現在擁有了什麼，而是你選擇追求什麼，

有了目標追逐的時候，人生會變得充滿意義。 

                                                                     ——深藍

***************************************前言***************************************

        這是一部個人記錄的成長雜記，既然步入到oracle的這片藍海，免不了一路的奔波與不斷的考驗。藉由此雜記與庫友們分享藍的成長曆程。

        不知何時起對藍有了一種說不出來的癡迷，癡迷其廣博，癡迷其深邃，癡迷於近在咫尺卻又遙不可及。

        而又說不清從何時起，注視於oracle的紅色耀眼，照亮出眼前的一道光，未知與迷惑在自己的腳下開始初露些許人生的充實與青春的回饋。

        在追逐於DBA夢想的道路上步步前行。

***********************************************************************************

2014年8月4日 威海

        今天聯絡客戶，來到資料中心A部，機房環境相當不錯。只可惜當看到實際的機器後，有點失望，沒有其它的想法，只是對其效能比較失望。09年的機器，5年過去了，按理說是有些年頭，但也不算太久。之前瞭解的一台伺服器工作20年無宕機依然堅挺。而眼前的這幾台，只能說是IT界發展變化太快，不是不夠用了，是跟不上大時代的步伐了。而這次伺服器效能的下降可以很簡單解釋：在搭建初期由於試行階段，這個系統每天的業務量很小，所以相當長的一段時間內都沒暴漏出問題。而隨著系統的大力攤開於這個威海各小分支部門後，隱患還是顯現出來。據瞭解伺服器近一年來小問題層出不窮，而現場的操作員最常用的方法是：重啟伺服器！所以想不出什麼名次代替了，以用“古董”一詞表達此刻的心情。接下來，我們看看這幾台伺服器的真面目：

（機1）：資料庫伺服器

                  Dell的PowerEdge2950/E53201.86GHz 四線程/3.99G記憶體/136G/Windows2003/Oracle10g

（機2）：應用伺服器

                  Dell的PowerEdge2950/E53201.86GHz 八線程/7.99G記憶體/136G/ Windows2003

（機3）：ftp伺服器

                  Dell的PowerEdge2950/E53201.86GHz 四線程/3.99G記憶體/136G/ Windows2003

（機4）：儲存

                  Dell的MD3000/1T/RAID1

       可笑的配置，相比較最高效能的伺服器用給了應用伺服器，資料庫伺服器流落和一台ftp伺服器相同的配置。感覺有些奇怪的是在兩台4G記憶體的機器上貼著沒有撕掉的“Cluster”標識，這好似一套叢集環境。再確認一下，眼前的這兩台機器確實不是叢集環境。跟負責日常管控的工程師瞭解之後得到了答案。這是被撤下來的方案，之前某個第三方服務商有人來過，撘過RAC，配置過儲存。而後來不成功給撤掉了。雖得到瞭解答，但看見眼前儲存上紅色警示燈在不停的閃爍，還是有些鬧不清之前發生了什麼，真心無語了。

        推測出了眼前的這套方案：之前的第三方服務人員可能是計劃兩台機器搭建RAC叢集（機1+機3），使用一台效能稍高的作為應用伺服器，儲存使用陣列儲存，而且處於安全考慮，他做了RAID1。但實際中由於叢集搭建的失敗，調整了方案，變成了單一實例的資料庫，資料檔案儲存在儲存中，而應用伺服器沒有變動，這樣便有一台伺服器被閑置了，最後的選擇是用其搭建了一台ftp伺服器，用於檔案的共用。按此思路下來，眼前的情境形成了。

        不妨想一想，如果是我：Windows下的話，資料庫叢集就不搭了，將效能較好的那台伺服器作為資料庫伺服器（機1），然後將餘下的兩台伺服器搭建一個應用叢集環境（機1+機3），最後當然還是使用儲存，組建個RAID 0 1，來改善備份資料時的效能瓶頸。想歸想，做歸做，還要落地到客戶當今的需求上。

        瞭解了一下，改造平台的原因在於系統很不穩定，效能體現在訪問人數變多時（達到50人時效能差體現的比較明顯），便會出現應用響應延遲嚴重的現象。

        各位領導到場後，討論會議正式開始。經過一番討論後，客戶將穩定性、安全性作為了最重要的考慮，改造方案可由我方自行決定，對於操作員難度問題可暫不考慮。在這裡，我可以預見在伺服器宕機的這一個月來說對於客戶是度過了怎樣的煎熬，只要是穩定，其它一切都可以。

此次我方提出兩個解決方案：

         方案一：資料庫伺服器平台由Windows改造為Linux，應用伺服器依舊保留Windows平台以降低駐地操作人員的使用難度；

         方案二：資料庫伺服器平台、應用伺服器平台均改為Linux平台，以實現穩定性，對於操作難度，會提供指導文檔給具體操作                              員。

在備份方案上，我方提出兩種解決建議：

         建議1：使用計劃任務，完成本地自動備份；

         建議2：進行遠程備份容災，組件最後一道防線，並由我方北京工程師實施備份。

         經過確認後，改造採取方案二，在備份策略上結合兩點建議，實現資料備份容災的兩條防線。遠端我方作為最後一道資料安保防線。就此，轉戰於機房。

        連續使用類似的查看指令，推測出資料的增產量：每年約30G，指令參考如：“

selectcount(1) from t where t.ziduan>=to_date('20090101','yyyymmdd') andt.ziduan<=to_date('20140101','yyyymmdd');”、“select sum(bytes)/1024/1024/1024from v$datafile;”、“select sum(bytes)/1024/1024/1024 from dba_free_space;”

在進一步決定備份方案時，看到紅色警示燈的儲存，真心不太敢用。

        嘗試邏輯備份部分資料，儲存讀寫速度相當之慢，判斷儲存必然存在問題。看了一下資料的增產量、原有的資料量，建議客戶拋棄掉存放裝置陣列，使用本機伺服器。可以至少維持兩年的資料增長。由於機器配置較目前屬於較低端，建議日後升級硬體系統。客戶也予以採納，此次先解決系統不穩定事宜，升級方案已經在考慮籌備之中。得到了“懿召”後，心裡便有些底了。採用方案：資料庫伺服器（機2）、應用伺服器（機1）、ftp組件一個本地備份伺服器（機3）。

        現在擺在眼前的問題就是：將儲存中的資料檔案備份出來，因為在這個存疑的儲存上幹活的話真心心裡不踏實。而且也得到了驗證：最初想直接由儲存中將資料dump出來。11:30開始匯出，14:30回去查看發現匯出了了15G的資料量，查看發現需要匯出80G的資料量。也就意味著全部資料匯出的話可能要消耗15多個小時，這簡直太可怕了。80G的資料並不算大，用這麼久，時間太長了，於是想使用其它的方式。想把資料檔案在系統層面都拷貝到本機伺服器上，再通過類似指令，如：“alter database rename file 'Z:/one.dbf'  to  'D:/one.dbf';”用以重新導向資料檔案，在通過邏輯備份匯出檔案。這正是做了一次冷備，需要在關庫的情況下來完成。

         在將資料檔案拷貝到伺服器的過程中，同樣是一個令人煎熬的過程。從16:00開始做冷備。

         不知多了多久，截下如片：

        回想似乎是到19:00左右，終於完成了，沒有預期的快，但至少比直接由儲存導踏實很多了。現在可以開始做匯出的工作了。

        看看時間，開始邏輯備份，關閉顯示器，離開返回酒店，讓匯出的任務在夜間完成吧。現在能做的，就是休息，願今晚，一切！~安好~！。

***************************************未完待續***************************************

歡迎訪問：深藍的Blog：http://blog.csdn.net/huangyanlong

*****************************************************************************************

網球王子中不二周助詳細資料與圖片?

baike.baidu.com/view/6958.htm自己去百度百科看去。。很詳細。。