oracle崩潰怎么恢復 oracle 恢復

oracle存儲過程失效重啟后恢復正常

根據(jù)oracle數(shù)據(jù)庫的特點和提供的工具，主要方法有以下幾種方法：

創(chuàng)新互聯(lián)服務項目包括杏花嶺網(wǎng)站建設、杏花嶺網(wǎng)站制作、杏花嶺網(wǎng)頁制作以及杏花嶺網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，杏花嶺網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到杏花嶺省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！

利用邏輯備份使用import工具丟失數(shù)據(jù)的表

利用物理備份來通過還原數(shù)據(jù)文件并進行不完全恢復

利用dbms_logmnr包從redo log文件中恢復

利用flashback特性恢復數(shù)據(jù)

前提

為了方便使用方法的介紹，上述恢復方法都將基于以下場景進行：系統(tǒng)管理員在前一天晚上11點用export對數(shù)據(jù)庫做了全庫邏輯備份，然后對所有數(shù)據(jù)文件進行了熱備份。第二天上午10點，系統(tǒng)管理員在修改表TFUNDASSET的數(shù)據(jù)時，由于修改語句的條件寫錯了，導致一批記錄(幾千條)的ztm字段被修改成了錯誤的值，而且已經(jīng)提交。這個表是資產表，相對而言數(shù)據(jù)變化不頻繁。

一、利用邏輯備份使用import工具恢復丟失的數(shù)據(jù)

export/import是oracle提供的用于對數(shù)據(jù)庫進行邏輯備份的工具。該工具適用于備份那些數(shù)據(jù)量不大、業(yè)務量不多的數(shù)據(jù)庫系統(tǒng)。因為如果在前一天晚上11點用export做了邏輯備份，那么當今天上午10點數(shù)據(jù)庫意外崩潰時，從備份起到數(shù)據(jù)庫崩潰的這段時間里的數(shù)據(jù)修改操作(包括DDL和DML)都會丟失。如果丟失數(shù)據(jù)內的表上的數(shù)據(jù)是相對比較穩(wěn)定，也就是說該表上基本沒有DML操作，例如標準代碼表、分區(qū)表里的歷史數(shù)據(jù)，那么采用import來導入該表可以比較完整的恢復數(shù)據(jù)。如果該表是經(jīng)常變化的業(yè)務表，那么這些丟失的數(shù)據(jù)只能根據(jù)業(yè)務情況從紙質記錄恢復，或者其他途徑恢復。

▲示例如下：這個表是一個資產表。相對來說，今天系統(tǒng)運行中修改的數(shù)據(jù)較少，丟失的數(shù)據(jù)量可以承受或者可以從別的途徑恢復。那就可以用import來恢復。

方法一：

1、把這個表的數(shù)據(jù)備份到另一個表：

8bef9890242e5d20d09563896cef1471.png

2、刪除該表的記錄:

625dfa5d5986ca5c37dd5017953407cb.png

3、執(zhí)行下面的命令：

3754d50cc473bd44236d927f00196d24.png

這個命令中在關鍵字tables中指定需要導入的表名字，ignore=y表示忽略表已經(jīng)存在的錯誤。

4、導入結束后，檢查表中的記錄，并用適當?shù)姆椒ɑ謴彤斕斓男薷摹?/p>

方法二：

1、把需要恢復的表導入到另一個用戶下面：

33806d1216df5ae9c45890d3d45930ee.png

2、檢查數(shù)據(jù)以后，把原表記錄刪除：

fe23a8a4602702e951e5ab48a7460e3b.png

3、然后從另一用戶表中插入回去：

729976810ef459046df40b791a6ca773.png

4、數(shù)據(jù)量比較大時可以采用如下方法：

e377d10ff07132f160185cb1ba119cfc.png

二、利用物理備份來通過還原數(shù)據(jù)文件并進行不完全恢復

如果數(shù)據(jù)庫運行在歸檔模式下，那么可以通過使用以前的數(shù)據(jù)文件備份進行還原，然后利用歸檔日志進行前滾，直到回滾到錯誤操作的時間點前，然后重置日志文件打開數(shù)據(jù)庫。

可以通過下列方法確認是否是運行在歸檔模式：

c8406e42aef7ccc8ef232cfdd535e825.png

如果是如上所示，那么就是運行在歸檔模式了。

▲假定在前一天晚上11點做了全庫物理備份，那么可以考慮如下恢復：

1、關閉數(shù)據(jù)庫：

由于數(shù)據(jù)庫的不完全恢復必須在一個關閉的數(shù)據(jù)庫上實施，利用一個舊的數(shù)據(jù)庫的備份還原，然后用日志根據(jù)需要逐步前滾，而不能還原一個新的備份，再回退到某個時間點。

通知各客戶端數(shù)據(jù)庫將關閉，然后發(fā)出：

401f68e89cbfa03388f5913bf5f1ecfd.png

數(shù)據(jù)庫已經(jīng)關閉。

已經(jīng)卸載數(shù)據(jù)庫。

ORACLE 例程已經(jīng)關閉。

2、確定錯誤操作的時間：

可以根據(jù)操作員的估計來確定不完全恢復需要前滾停止的時間，也可以利用LogMiner來分析日志文件(這個工具將在后面介紹)，找出錯誤操作的準確時間。

3、還原數(shù)據(jù)文件：

先對當前的數(shù)據(jù)庫文件進行備份，然后再用以前的最近一次備份覆蓋現(xiàn)有數(shù)據(jù)文件。注意：不覆蓋現(xiàn)有的控制文件。

4、基于時間點恢復，啟動數(shù)據(jù)庫到裝配狀態(tài)：

8802043c250eb2a060285be160f48c36.png

這樣數(shù)據(jù)庫就恢復到了2015年10月20日的9點58分零秒。

然后再利用業(yè)務資料補充這段時間內的數(shù)據(jù)。

三、利用dbms_logmnr包從log文件中恢復

這個包是由Oracle提供，與dbms_logmnr_d包配合使用可以方便地分析聯(lián)機日志文件和歸檔日志文件，從這些日志文件中提取出所有對數(shù)據(jù)庫的更改操作。

在使用這個包之前，需要先做一些設置和修改：

1、打開initorcl.ora，修改初始化參數(shù)utl_file_dir，設置dbms_logmnr_d包將要使用的數(shù)據(jù)字典文件的放置目錄。

eb6dad504d6f5841641cbd02c5f6dee1.png

然后重啟數(shù)據(jù)庫使參數(shù)生效。

2、以sys用戶連接到數(shù)據(jù)庫執(zhí)行dbmslmd.sql腳本重建dbms_logmnr_d這個包。

應用Logminer分析重做日志文件的操作主要有以下步驟：

● 使用dbms_logmnr_d里的存儲過程build創(chuàng)建一個外部數(shù)據(jù)字典文件；

● 使用dbms_logmnr里的存儲過程add_logfile添加要分析的日志文件；

● 使用dbms_logmnr里的存儲過程start_logmnr啟動分析；

● 查詢與dbms_logmnr相關的幾個視圖來獲取日志文件內容；

● 使用dbms_logmnr里的存儲過程end_logmnr結束分析。

▲下面詳細講述使用的過程

1、使用dbms_logmnr_d里的存儲過程build創(chuàng)建一個外部數(shù)據(jù)字典文件：

a0975e25f5049f1ffdfdd49ad7ae943d.png

2、使用dbms_logmnr里的存儲過程add_logfile添加要分析的日志文件到待分析文件列表：

d16ea343204a3a15b29bc6b94985d48d.png

如果沒有運行在歸檔模式，那么由于重做日志文件的循環(huán)使用可能導致日志文件被覆蓋而無法獲取到所要尋找的恢復條目。如果運行在歸檔模式，則可以通過查看$ORACLE_HOMEadminorclbdump目錄下的alert_orcl.log里日志文件歸檔的時間和錯誤操作的時間來確定加入哪些歸檔日志文件到待分析的文件列表中去。

eff89b61175131d3edda456d8d9bc18e.png

注意：執(zhí)行以上過程時logfilename參數(shù)需要寫日志文件的全路徑，否則會報錯。重復以上操作直到把所有需要分析的文件都加到列表中去。這樣就可以啟動進行分析。

3、使用dbms_logmnr里的存儲過程start_logmnr啟動分析；

3630359ea5afa57b5ea51c89da5b8c41.png

這樣就可以通過下面的查詢來獲取日志文件的內容了。

4、查詢與dbms_logmnr相關的幾個視圖來獲取日志文件內容；

3f8098efdbe50d4b5b4a5311eab6b5d0.png

這樣就可以找出要恢復所需的語句。注意：v$logmnr_contents只對執(zhí)行dbms_logmnr.start_logmnr的會話有效，如果通過其他會話或者使用dbms_logmnr.end_logmnr終止了分析，都將不能訪問v$logmnr_contents的數(shù)據(jù)。如果要使其他會話也能獲取到這些數(shù)據(jù)，可以通過另外建表來實現(xiàn)，如：

create table undo_sql as select * from v$logmnr_contents。

再對undo_sql進行授權，其他用戶就可以訪問v$logmnr_contents的數(shù)據(jù)了。

5、使用dbms_logmnr里的存儲過程end_logmnr結束分析。

使用完成以后用下面的命令來結束分析活動：exec dbms_logmnr.end_logmnr;

這樣就釋放了分配給logminer的資源(內存和數(shù)據(jù)結構)。

從上面的過程可知，如果是更新的數(shù)據(jù)量比較大，而日志文件比較小，就可能會導致日志文件的切換。如果沒有及時去挖掘日志文件(沒有運行在歸檔模式)，那么可能會由于日志文件的循環(huán)使用而導致數(shù)據(jù)不可恢復。如果運行在歸檔模式，也可能由于需要分析的日志文件比較多而時間較長。

四、利用flashback新特性恢復數(shù)據(jù)

Oracle9i 開始提供了閃回查詢(Flashback Query)功能，對于誤刪除或者誤更新并且已經(jīng)commit了的情況提供了簡便快捷的恢復方法；而在Oracle 提供閃回查詢之前，碰到這種情況只能通過備份來進行基于時間點的恢復或者使用logmnr挖掘日志來恢復，無疑這比閃回查詢要麻煩而且費時。

使用這個Flashback Query特性的前提條件：

1. 數(shù)據(jù)庫必須處于Automatic Undo Management 狀態(tài)。

9d9facd0a8d3e8675284d38f601525d1.png

2. 最大可以閃回查詢的時間段由UNDO_RETENTION 初始化參數(shù)(單位為秒)指定

b7a419e2f47bd4d31005ca2d9b4a7c58.png

可以通過ALTER SYSTEM SET UNDO_RETENTION = ;來動態(tài)修改參數(shù)值。

▲如何使用Flashback Query來恢復數(shù)據(jù)呢？

1. 通過SQL

28b1053a806762ec87261e80f0e8751f.png

使用SELECT 語句的AS OF 來進行閃回查詢，語法如下：

使用AS OF 關鍵字來對表，視圖或者物化視圖進行Flashback Query，如果指定了SCN，那么expr 部分必須是一個數(shù)字，如果指定了TIMESTAMP，那么expr 必須是一個timestamp類型的值。查詢結果將返回在指定的SCN 或者時間點上的數(shù)據(jù)。

下面我們使用scott 方案來作一個實驗。

24547dbf2f8f3515319435d98acc0f10.png

如果想在update 的子查詢部分使用AS OF，那么該查詢只能返回一條記錄，否則將會報錯。

可以通過添加一個臨時表作為中轉，然后再作更新，如下：

5605ae591ab357c7148787937df03e17.png

2．通過DBMS_FLASHBACK包來恢復

DBMS_FLASHBACK 包提供了以下幾個函數(shù)：

ENABLE_AT_TIME：設置當前SESSION 的閃回查詢時間

ENABLE_AT_SYSTEM_CHANGE_NUMBER：設置當前SESSION 的閃回查詢SCN

GET_SYSTEM_CHANGE_NUMBER：取得當前數(shù)據(jù)庫的SCN

DISABLE：關閉當前SESSION 的閃回查詢

當將一個SESSION 設置為閃回查詢模式之后，后續(xù)的查詢都會基于那個時間點或者SCN 的數(shù)據(jù)庫狀態(tài)，如果SESSION 結束，那么即使沒有明確指定DISABLE，閃回查詢也會自動失效。

當SESSION 運行在閃回查詢狀態(tài)時，不允許進行任何DML 和DDL 操作。如果要用DML操作來進行數(shù)據(jù)恢復就必須使用PL/SQL 游標。

▲示例：

fbaf8acfe357d8f21039d588c8b658df.png

通過上面的例子可以看出，只要這個修改的時間不早于sysdate- (UNDO_RETENTION指定的秒數(shù)),就可通過這種方式來恢復數(shù)據(jù)。

e93c4d7b11cf4e7c8ed9a0d27c79ea80.png

對于問題中的批量數(shù)據(jù)，可以寫個過程來完成獲取到更改前的數(shù)據(jù)：

然后再用這個臨時表里的數(shù)據(jù)來更新TFUNDASSET就可以了。

五、總結

比較以上幾種恢復數(shù)據(jù)的方法的使用過程，我們可以看出：

● exp/imp只適合于數(shù)據(jù)變化不大的表的數(shù)據(jù)丟失的情況，即使用這種方法處理后也需要從業(yè)務辦理資料中修正數(shù)據(jù)，否則導致數(shù)據(jù)丟失；

● 采用基于時間點的不完全恢復可以恢復丟失的數(shù)據(jù)，但是需要關關閉數(shù)據(jù)庫，減少系統(tǒng)可用時間，而且也會丟失恢復時間點以后的數(shù)據(jù)；

● 使用LogMiner可以較好的恢復數(shù)據(jù)，但是要求數(shù)據(jù)庫盡可能運行在歸檔模式，否則也可能導致數(shù)據(jù)丟失。好處是不用關閉系統(tǒng)，能夠從日志文件中得到所有的數(shù)據(jù)。

● 使用Flashback最方便和簡潔，可以直接得到修改前的數(shù)據(jù)，但是需要依賴系統(tǒng)設置，并且需要占用大量的回滾表空間。

因此選擇什么樣的方法來恢復數(shù)據(jù)，取決于你的系統(tǒng)環(huán)境和具體情況，不能生搬硬套。采用正確的方法才能最大程度的減少數(shù)據(jù)的丟失。

當然，最好是不需要用到這些恢復的辦法。前提是，你必須做好以下的工作：

1、為不同環(huán)境創(chuàng)建不同的數(shù)據(jù)庫用戶、不同密碼(如果不能用戶不同，一定要密碼不同)；

2、將owner和應用用戶分開，并做適度授權；

3、在做DML前，先用同樣的條件做查詢，看根據(jù)結果集是否符合預期。

系統(tǒng)崩潰，oracle沒做備份，數(shù)據(jù)庫可以恢復嗎

主要軟件版本: 4.4 主要軟件修正版本: 4.4 次要軟件: N/A 解答:MAX數(shù)據(jù)庫崩潰非常罕見，但是當突然斷電或者死機而導致系統(tǒng)非正常關機、重啟時可能會導致這一問題。數(shù)據(jù)庫崩潰可能出現(xiàn)的一個現(xiàn)象就是當點擊MAX中任一文件夾旁邊的擴展按鈕“＋”時，文件夾不但不，“＋”還消失了。如果這一現(xiàn)象是在安裝了新版本的MAX之后才產生的，您需要確認一下安裝之后是否重啟了PC。 MAX會備份數(shù)據(jù)庫文件，這可以被用于恢復數(shù)據(jù)庫崩潰。具體步驟如下：以管理員身份或者有管理員權限的用戶賬號登錄（如果安裝了F-Secure之類的固件，請確保其在下面的過程中保持關閉?。和顺鏊械腘I應用程序。

超級復雜困難之Oracle數(shù)據(jù)庫大恢復

昨天一個朋友公司的數(shù)據(jù)庫崩潰

這再次印證了我反復提到的一個命題數(shù)據(jù)庫也需要休息

每逢節(jié)假日數(shù)據(jù)庫也經(jīng)常會自我選擇放假

以前我說年終難終進入數(shù)據(jù)庫事故多發(fā)期一年一度今又是記得另外一個圣誕節(jié) 我還和Biti一起在北京的時候同樣遇到一個上海的朋友數(shù)據(jù)庫崩潰我們遠程指導這位朋友恢復了數(shù)據(jù)

這次的事情是這樣的

首先主機宕機磁盤出錯

看到以下這類錯誤一般你的數(shù)據(jù)都很危險了

Dec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit=

數(shù)據(jù)文件大量損壞

當然這次也不例外大量文件損壞 dbv大量如下錯誤

[oracle@stat datafile]$ dbv file=o _mf_system_ mn _ dbf blocksize=

DBVERIFY: Release Production on Thu Dec : :

DBVERIFY Verification starting : FILE = o _mf_system_ mn _ dbfPage is influx most likely media corruptCorrupt block relative dba: x (file block )Fractured block found during dbv: Data in bad block:type: format: rdba: x last change scn: x f e seq: x flg: x spare : x spare : x spare : x consistency value in tail: xbc check value in block header: xc cbputed block checksum: xb

Page is influx most likely media corruptCorrupt block relative dba: x e (file block )Fractured block found during dbv: Data in bad block:type: format: rdba: x e last change scn: x b seq: x flg: x spare : x spare : x spare : x consistency value in tail: x c check value in block header: x d fputed block checksum: x dc

控制文件損壞

啟動數(shù)據(jù)庫出現(xiàn)如下錯誤

Wed Dec : : ALTER DATABASE MOUNed Dec : : Errors in file /opt/oracle/admin/stat/udump/stat_ora_ trc:ORA : internal error code arguments: [kccpb_sanity_check_ ] [ ] [ ] [ x ] [] [] [] []Wed Dec : : ORA signalled during: ALTER DATABASE MOUNT Wed Dec : : Starting ORACLE instance (normal)Wed Dec : : Corrupt block found during reading backup piece file=/opt/oracle/product/db g/dbs/snapcf_stat f corr_type=

經(jīng)過反復確認這個環(huán)境Over了

不完全的備份

以前的備份機制使得我可以從遠程主機找到一系列備份集但是沒有控制文件

通過備份集 dbms_backup_restore等手段首先恢復出來數(shù)據(jù)文件然后嘗試啟動數(shù)據(jù)庫

強制打開

通過強制resetlogs手段打開數(shù)據(jù)庫出現(xiàn)ORA 錯誤

Wed Dec : : Errors in file /opt/oracle/admin/stat/udump/stat_ora_ trc:ORA : internal error code arguments: [ ] [ ] [] [] [] [] [] []Wed Dec : : Errors in file /opt/oracle/admin/stat/udump/stat_ora_ trc:ORA : bootstrap process failureORA : bootstrap process failureORA : internal error code arguments: [ ] [ ] [] [] [] [] [] []

通過BBED解決ORA 錯誤

這個沒說的只能通過BBED搞定了修復有問題的數(shù)據(jù)塊再次嘗試打開數(shù)據(jù)庫

遇到ORA 錯誤

這個錯誤就好解決了通過我網(wǎng)站上的示例就可以解決

Wed Dec : : Errors in file /opt/oracle/admin/stat/udump/stat_ora_ trc:ORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []ORA : ORACLE instance terminated Disconnection forcedORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []Wed Dec : : Errors in file /opt/oracle/admin/stat/udump/stat_ora_ trc:ORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []ORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []ORA : ORACLE instance terminated Disconnection forcedORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []Wed Dec : : Errors in file /opt/oracle/admin/stat/udump/stat_ora_ trc:ORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []ORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []ORA : ORACLE instance terminated Disconnection forcedORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []

解決ORA 號錯誤

接下來繼續(xù)出現(xiàn)ORA 號錯誤這個也好解決搞定UNDO表空間就Ok了

Wed Dec : : Errors in file /opt/oracle/admin/stat/bdump/stat_j _ trc:ORA : internal error code arguments: [ ] [] [] [] [] [] [] []

解決一些其他小問題

此處省略字終于搞定了用戶數(shù)據(jù)庫！

lishixinzhi/Article/program/Oracle/201311/17213

Oracle重做日志丟失的故障處理

Oracle重做日志

Oracle的重做日志文件(Online redo logfile)循環(huán)記錄了數(shù)據(jù)庫所有的事務它的大小個數(shù)和存儲位置對數(shù)據(jù)庫性能和恢復有重要影響它一般由大小相同的幾組文件構成我們可以查看數(shù)據(jù)庫視圖v$logfile知道redo logfile的個數(shù)和存儲位置對每一個Oracle數(shù)據(jù)庫都要求至少具有兩個聯(lián)機重做日志

每一次新的事務提交時 Oracle將該事務寫入日志文件但并非此時也將修改的數(shù)據(jù)塊寫回原數(shù)據(jù)文件由于內存讀寫和磁盤I/O存在幾個數(shù)量級的效率差別 Oracle通過減少數(shù)據(jù)文件的物理I/O讀寫來大大提高數(shù)據(jù)庫的性能同時又通過優(yōu)先寫日志文件來保證數(shù)據(jù)的正確性和一致性基于這種機制重做日志文件在數(shù)據(jù)庫的實例恢復和介質恢復時至關重要是oracle數(shù)據(jù)庫最重要的物理文件之一

如果數(shù)據(jù)庫在啟動時檢測到重做日志丟失數(shù)據(jù)庫將無法啟動如果數(shù)據(jù)庫在運行時切換日志文件組檢測到下一組或者全部的重做日志丟失數(shù)據(jù)庫將會崩潰由于磁盤介質損壞或者人為的誤刪除文件造成嚴重后果的事件近期時有發(fā)生本文列舉了重做日志丟失的數(shù)據(jù)庫恢復但如果按照冗余原則合理分布日志文件組的成員如果工程師了解日志文件的基本原理和使用原則就完全可以避免出現(xiàn)下列問題

恢復方法

故障現(xiàn)象

SQL startup mount

Oracle Instance Started

Database mounted

ORA : open failed for members of log group of thread

ORA : online log thread : /ORACLE/ORADATA/H /REDO LOG

ORA : unable to open file

OSD : unable to open file

O/S Error: (OS ) The system cannot find the file specified

恢復注意事項

以下所列舉的恢復方法都屬于不完全恢復或者強制恢復會丟失當前重做日志中的事務數(shù)據(jù) 一旦操作不當將帶來數(shù)據(jù)丟失等嚴重后果請遵循以下幾個恢復原則

請勿在生產系統(tǒng)上試用

如果生產系統(tǒng)出現(xiàn)重做日志文件丟失的故障請勿自行操作破壞現(xiàn)場應該立刻聯(lián)系Oracle工程師

恢復成功之后需要馬上做一次數(shù)據(jù)庫的全備份

建議重做日志文件一定要實現(xiàn)鏡象在不同的磁盤上避免這種情況的發(fā)生

恢復方法

首先檢查重做日志文件狀態(tài) 看看報錯的日志文件的狀態(tài)是否為Current

SQL select * from v$log;

SQL select * from v$logfile;

如果重做日志文件狀態(tài)為Inactive 我們可以直接清除該日志文件的內容

SQL alter database clear logfile /ORACLE/ORADATA/H /REDO LOG ;

如果重做日志文件狀態(tài)為Current 恢復工作較為復雜有以下四種情況

）通過下面步驟數(shù)據(jù)庫順利打開

SQL recover database until cancel;

Type Cancel when prompted

SQLalter database open resetlogs;

）第一種情況的 recover database until cancel 操作遇到ORA ORA ORA 錯誤需要整個數(shù)據(jù)庫的物理備份并根據(jù)歸檔日志恢復到錯誤時間點前提是數(shù)據(jù)庫是歸檔模式

restore old backup

SQL startup mount

SQL recover database until cancel using backup controlfile;

SQL alter database open resetlogs;

）如果數(shù)據(jù)庫是非歸檔模式只能恢復整個物理備份然后直接打開數(shù)據(jù)庫這種情況將丟失物理備份至故障發(fā)生前的全部數(shù)據(jù)

）如果數(shù)據(jù)庫是非歸檔模式且沒有物理備份只能通過特殊的隱含參數(shù) 允許數(shù)據(jù)庫不一致的狀況下打開數(shù)據(jù)庫這種恢復方法是沒有辦法之后的恢復方法將導致數(shù)據(jù)庫不一致一般情況下不要采用如確有需要請在Oracle的技術人員指導下使用該方法

???????? 關閉數(shù)據(jù)庫

SQLshutdown immediate

???????? 在initsid ora中加入如下參數(shù)

_allow_resetlogs_corruption=TRUE

???????? 重新啟動數(shù)據(jù)庫利用until cancel恢復

SQLrecover database until cancel;

Cancel

???????? 打開數(shù)據(jù)庫

SQLalter database open resetlogs;

???????? 數(shù)據(jù)庫被打開后馬上執(zhí)行一個全庫導出

關閉數(shù)據(jù)庫在initsid ora中去掉_all_resetlogs_corrupt參數(shù)

lishixinzhi/Article/program/Oracle/201311/16743

Oracle中為什么會產生回滾與前退

Oracle概念問題假如數(shù)據(jù)沒有提交但是卻被dbwn進程寫入了數(shù)據(jù)文件會怎么樣呢？

案例分析

首先說明的是dbwn寫臟數(shù)據(jù)跟mit提交沒有關系！

在一個transaction發(fā)生的過程中 online redo log首先記錄transaction中修改的數(shù)據(jù)塊相關信息修改的數(shù)據(jù)塊會被緩存在database buffer cache中由于database buffer cache寫滿或者checkpoint等等條件觸發(fā)dbwn進程會導致這些緩存的數(shù)據(jù)塊寫入數(shù)據(jù)文件但此時可能該transaction仍然還沒有提交所以在數(shù)據(jù)文件中可能會有mited 和 unmited 的數(shù)據(jù)塊而原有的數(shù)據(jù)塊鏡像會存放在undo segment

IXDBA NET社區(qū)論壇

然而 dbwn寫臟數(shù)據(jù)時不管這個要寫的transaction是否提交

也沒有必要去管

這樣就發(fā)生了所謂的已經(jīng)提交的數(shù)據(jù) 但是還沒有寫入數(shù)據(jù)文件的現(xiàn)象

還有一種情況數(shù)據(jù)沒有提交但是已經(jīng)被寫入數(shù)據(jù)文件此時發(fā)生回退撤銷沒有提交的數(shù)據(jù)

那么引發(fā)Oracle前滾與回退的根本原因就是什么呢？

根本原因是mit后寫redo buffer和觸發(fā)lgwr寫 redo buffer的區(qū)別

事務在執(zhí)行完畢后隨即會被寫入redo buffer和undo中同時在redo buffer和undo中對該事務都有一個是否提交的標記兩者的默認狀態(tài)都是active的即沒有提交時刻處于激活狀態(tài)

mit操作執(zhí)行時刻把此前的所有事務操作全部寫入redo log file mit成功后 redo buffer信息全部寫入redo file 同時修改兩者中的事務提交標識為inactive 表示此前事務已經(jīng)遞交

oracle的前滾和回退根據(jù)就是依據(jù)事務是否提交而進行的

在觸發(fā)lgwr進程后 oracle同樣把此前的redo buffer信息寫入redo file 但是與mit觸發(fā)寫日志不同的是 redo file本身對lgwr寫日志操作不記錄任何信息標識 lgwr寫到那里就是那里就算此時掉電也無妨 redo file就記錄到掉電時刻的信息

lgwr是一個Oracle后臺執(zhí)行的進程具體的日志寫操作都有oracle去控制這對于oracle來說是透明的因此不用在redo file中寫入任何標記信息這也是正常的

mit操作是唯一一個可以前臺操作與oracle后臺通信的指令因此當加入這個操作以后 oracle本身必須要了解各個事務的讀寫狀況那么怎么了解整個狀況在redo以及undo中加入是否遞交的標識對于已經(jīng)提交的操作但是還沒有寫入數(shù)據(jù)文件那么就要前滾相反對于沒有提交執(zhí)行回退！

于是 Oracle崩潰恢復步驟如下

首先rolling forward 前滾由于oracle failure sga中的內存信息丟失了但是online redo log中還是存儲了transaction信息包括mited or unmited data 可能這些修改信息并沒有被oracle正確的來處理包含兩種情況已經(jīng)提交的還沒有寫入數(shù)據(jù)文件或者沒有提交的卻被寫入了數(shù)據(jù)文件針對已經(jīng)提交的還沒有寫入數(shù)據(jù)文件就要發(fā)生前滾在前滾過程中 *** on會根據(jù)online redo log中的記錄來完成對datafile的修改保證已經(jīng)提交的數(shù)據(jù)已經(jīng)寫入數(shù)據(jù)文件

接下來前滾結束后數(shù)據(jù)庫正常open 此時用戶可以正常連接可以訪問已經(jīng)recover的mited data 但是對于那些屬于unrecoverable transaction的unmited data 會被oracle 加鎖是不可以訪問的

lishixinzhi/Article/program/Oracle/201311/16619

oracle怎樣恢復刪除的數(shù)據(jù)文件

oracle數(shù)據(jù)庫恢復,主要包括(1)系統(tǒng)崩潰只剩下數(shù)據(jù)文件的情況下的恢復,甚至沒有system表空間而只有數(shù)據(jù)表空間的情況下的恢復.只要提供數(shù)據(jù)文件就可恢復.(2)undosystem表空間損壞數(shù)據(jù)恢復.(3)非歸檔或者歸檔模式下誤delete數(shù)據(jù)的恢復、誤刪除表空間的恢復、droptruncate表的恢復.(4)數(shù)據(jù)庫中有大量CLOBBLOB對象數(shù)據(jù)恢復等情況以及各種ora-錯誤的修復.(5)DMP文件損壞導致文件不能導入數(shù)據(jù)庫的數(shù)據(jù)恢復(6)oracle數(shù)據(jù)庫中數(shù)據(jù)文件出現(xiàn)壞塊情況下的恢復.(7)oracle數(shù)據(jù)庫無數(shù)據(jù)文件但有日志的情況下的恢復.(8)UNIX、WINDOWS下ORACLE數(shù)據(jù)文件被誤刪除情況下的數(shù)據(jù)庫恢復.(9)Oracle10G、Oracle11G的ASM損壞的數(shù)據(jù)庫恢復.(10)Oracle10G、Oracle11GBIFGILETABLESPACE大文件表空間損壞數(shù)據(jù)恢復(11)Oracle9i、Oracle10G、Oracle11G壓縮表壓縮表空間損壞數(shù)據(jù)恢復(12)Oracle10GOracle11GExpdp導出Impdp導入DMP文件錯誤數(shù)據(jù)恢復恢復成功率高達90%以上,在數(shù)據(jù)恢復領域處于國內領先的地位。具體案例見廣州拓飛官方網(wǎng)站

網(wǎng)頁題目：oracle崩潰怎么恢復 oracle 恢復
地址分享：http://muchs.cn/article32/hgihpc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站策劃、動態(tài)網(wǎng)站、網(wǎng)站設計、自適應網(wǎng)站、用戶體驗、ChatGPT

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內容