淺談我與Oracle數據庫的愛恨情仇 說明 根據本月學習團“11選1，好課免費學‘’的選課結果來看，選擇《Oracle數據庫從零到精通》這門的占比最高，由此可以看出Oracle數據庫的熱度不減，今天小編就和大家談談對Oracle的一些認識。 無論是開發、測試還是運維過程中，大家都可能會因為誤操作、連錯數據庫、用錯用戶、語句條件有誤等原因，導致錯誤刪除、錯誤更新等問題。當你恨不得剁掉按回車的那個指頭、捶胸頓足、或者嚇得腿軟時，肯定希望有辦法來恢復這些數據。剛好，oracle提供了一些強大的方法或機制，可以讓你找到“后悔藥”。 　　根據oracle數據庫的特點和提供的工具，主要方法有以下幾種方法： 　　利用邏輯備份使用import工具丟失數據的表 　　利用物理備份來通過還原數據文件并進行不完全恢復 　　利用dbms_logmnr包從redolog文件中恢復 　　利用flashback特性恢復數據 　　為了方便使用方法的介紹，上述恢復方法都將基于以下場景進行：系統管理員在前一天晚上11點用export對數據庫做了全庫邏輯備份，然后對所有數據文件進行了熱備份。第二天上午10點，系統管理員在修改表TFUNDASSET的數據時，由于修改語句的條件寫錯了，導致一批記錄(幾千條)的ztm字段被修改成了錯誤的值，而且已經提交。這個表是資產表，相對而言數據變化不頻繁。 1利用邏輯備份使用import工具恢復丟失的數據 export/import是oracle提供的用于對數據庫進行邏輯備份的工具。該工具適用于備份那些數據量不大、業務量不多的數據庫系統。因為如果在前一天晚上11點用export做了邏輯備份，那么當今天上午10點數據庫意外崩潰時，從備份起到數據庫崩潰的這段時間里的數據修改操作(包括DDL和DML)都會丟失。如果丟失數據內的表上的數據是相對比較穩定，也就是說該表上基本沒有DML操作，例如標準代碼表、分區表里的歷史數據，那么采用import來導入該表可以比較完整的恢復數據。如果該表是經常變化的業務表，那么這些丟失的數據只能根據業務情況從紙質記錄恢復，或者其他途徑恢復。 　　

▲示例如下：這個表是一個資產表。相對來說，今天系統運行中修改的數據較少，丟失的數據量可以承受或者可以從別的途徑恢復。那就可以用import來恢復。 　　方法一： 　　1、把這個表的數據備份到另一個表： 　　2、刪除該表的記錄： 　　3、執行下面的命令： 　　這個命令中在關鍵字tables中指定需要導入的表名字，ignore=y表示忽略表已經存在的錯誤。 　　4、導入結束后，檢查表中的記錄，并用適當的方法恢復當天的修改。 　　方法二： 　　1、把需要恢復的表導入到另一個用戶下面： 　　2、檢查數據以后，把原表記錄刪除： 　　3、然后從另一用戶表中插入回去： 　　4、數據量比較大時可以采用如下方法： 2利用物理備份來通過還原數據文件并進行不完全恢復 如果數據庫運行在歸檔模式下，那么可以通過使用以前的數據文件備份進行還原，然后利用歸檔日志進行前滾，直到回滾到錯誤操作的時間點前，然后重置日志文件打開數據庫。 　　可以通過下列方法確認是否是運行在歸檔模式： 　　如果是如上所示，那么就是運行在歸檔模式了。 　　▲假定在前一天晚上11點做了全庫物理備份，那么可以考慮如下恢復： 　　1、關閉數據庫： 　　由于數據庫的不完全恢復必須在一個關閉的數據庫上實施，利用一個舊的數據庫的備份還原，然后用日志根據需要逐步前滾，而不能還原一個新的備份，再回退到某個時間點。 　　通知各客戶端數據庫將關閉，然后發出： 　　數據庫已經關閉。 　　已經卸載數據庫。 　　ORACLE例程已經關閉。 　　2、確定錯誤操作的時間： 　　可以根據操作員的估計來確定不完全恢復需要前滾停止的時間，也可以利用LogMiner來分析日志文件(這個工具將在后面介紹)，找出錯誤操作的準確時間。 　　3、還原數據文件： 　　先對當前的數據庫文件進行備份，然后再用以前的最近一次備份覆蓋現有數據文件。注意：不覆蓋現有的控制文件。 　　4、基于時間點恢復，啟動數據庫到裝配狀態： 　　這樣數據庫就恢復到了2015年10月20日的9點58分零秒。 　　然后再利用業務資料補充這段時間內的數據。 3利用dbms_logmnr包從log文件中恢復 這個包是由Oracle提供，與dbms_logmnr_d包配合使用可以方便地分析聯機日志文件和歸檔日志文件，從這些日志文件中提取出所有對數據庫的更改操作。 　　在使用這個包之前，需要先做一些設置和修改： 　　1、打開initorcl.ora，修改初始化參數utl_file_dir，設置dbms_logmnr_d包將要使用的數據字典文件的放置目錄。 　　然后重啟數據庫使參數生效。 　　2、以sys用戶連接到數據庫執行dbmslmd.sql腳本重建dbms_logmnr_d這個包。 　　應用Logminer分析重做日志文件的操作主要有以下步驟： 　　使用dbms_logmnr_d里的存儲過程build創建一個外部數據字典文件; 　　使用dbms_logmnr里的存儲過程add_logfile添加要分析的日志文件; 　　使用dbms_logmnr里的存儲過程start_logmnr啟動分析; 　　查詢與dbms_logmnr相關的幾個視圖來獲取日志文件內容; 　　使用dbms_logmnr里的存儲過程end_logmnr結束分析。 　　▲下面詳細講述使用的過程 　　1)使用dbms_logmnr_d里的存儲過程build創建一個外部數據字典文件： 　　2)使用dbms_logmnr里的存儲過程add_logfile添加要分析的日志文件到待分析文件列表： 　　如果沒有運行在歸檔模式，那么由于重做日志文件的循環使用可能導致日志文件被覆蓋而無法獲取到所要尋找的恢復條目。如果運行在歸檔模式，則可以通過查看$ORACLE_HOME\admin\orcl\bdump目錄下的alert_orcl.log里日志文件歸檔的時間和錯誤操作的時間來確定加入哪些歸檔日志文件到待分析的文件列表中去。 　　注意：執行以上過程時logfilename參數需要寫日志文件的全路徑，否則會報錯。重復以上操作直到把所有需要分析的文件都加到列表中去。這樣就可以啟動進行分析。 　　3)使用dbms_logmnr里的存儲過程start_logmnr啟動分析; 　　這樣就可以通過下面的查詢來獲取日志文件的內容了。 　　4)查詢與dbms_logmnr相關的幾個視圖來獲取日志文件內容; 　　這樣就可以找出要恢復所需的語句。注意：v$logmnr_contents只對執行dbms_logmnr.start_logmnr的會話有效，如果通過其他會話或者使用dbms_logmnr.end_logmnr終止了分析，都將不能訪問v$logmnr_contents的數據。如果要使其他會話也能獲取到這些數據，可以通過另外建表來實現，如： 　　createtableundo_sqlasselect*fromv$logmnr_contents。 　　再對undo_sql進行授權，其他用戶就可以訪問v$logmnr_contents的數據了。 　　5)使用dbms_logmnr里的存儲過程end_logmnr結束分析。 　　使用完成以后用下面的命令來結束分析活動：execdbms_logmnr.end_logmnr; 　　這樣就釋放了分配給logminer的資源(內存和數據結構)。 　　從上面的過程可知，如果是更新的數據量比較大，而日志文件比較小，就可能會導致日志文件的切換。如果沒有及時去挖掘日志文件(沒有運行在歸檔模式)，那么可能會由于日志文件的循環使用而導致數據不可恢復。如果運行在歸檔模式，也可能由于需要分析的日志文件比較多而時間較長。 4利用flashback新特性恢復數據 Oracle9i開始提供了閃回查詢(FlashbackQuery)功能，對于誤刪除或者誤更新并且已經commit了的情況提供了簡便快捷的恢復方法;而在Oracle提供閃回查詢之前，碰到這種情況只能通過備份來進行基于時間點的恢復或者使用logmnr挖掘日志來恢復，無疑這比閃回查詢要麻煩而且費時。 　　使用這個FlashbackQuery特性的前提條件： 　　1.數據庫必須處于AutomaticUndoManagement狀態。 　　2.最大可以閃回查詢的時間段由UNDO_RETENTION初始化參數(單位為秒)指定 　　可以通過ALTERSYSTEMSETUNDO_RETENTION=