熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Oracle >> 正文

oracle系統緊急故障處理

2022-06-13   來源: Oracle 

  Oracle物理結構故障的處理方法
  
  Oracle物理結構故障是指構成數據庫的各個物理文件損壞而導致的各種數據庫故障這些故障可能是由於硬件故障造成的也可能是人為誤操作而引起所以我們首先要判斷問題的起因如果是硬件故障則首先要解決硬件問題在無硬件問題的前提下我們才能按照下面的處理方發來進一步處理
  
  控制文件損壞
  
  控制文件記錄了關於oracle的重要配置信息如數據庫名字符集名字各個數據文件日志文件的位置等等信息控制文件的損壞會導致數據庫異常關閉一旦缺少控制文件數據庫也無法啟動這是一種比較嚴重的錯誤
  
  可以通過查詢數據庫的日志文件來定位損壞了的控制文件日志文件位於$ORACLE_BASE/admin/bdump/alert_ORCLora
  
  損壞單個控制文件
  
   確保數據庫已經關閉如果沒有用下面的命令來關閉數據庫
  svrmgrl>shutdown immediate;
  
   查看初始化文件$ORACLE_BASE/admin/pfile/initORCLora確定所有控制文件的路徑
  
   用操作系統命令將其它正確的控制文件覆蓋錯誤的控制文件
  
   用下面的命令重新啟動數據庫
  svrmgrl>startup;
  
   用適當的方法進行數據庫全備份
  
  損壞所有的控制文件
  
   確保數據庫已經關閉如果沒有用下面的命令來關閉數據庫
  svrmgrl>shutdown immediate;
  
   從相應的備份結果集中恢復最近的控制文件對於沒有采用帶庫備份的點可以直接從磁帶上將最近的控制文件備份恢復到相應目錄對於采用帶庫備份的點用相應的rman腳本來恢復最近的控制文件
  
   用下面的命令來創建產生數據庫控制文件的腳本
  svrmgrl>startup mount;
  svrmgrl>alter database backup controlfile to trace noresetlogs;
  
   修改第三步產生的trace文件將其中關於創建控制文件的一部分語句拷貝出來並做些修改使得它能夠體現最新的數據庫結構假設產生的sql文件名字為createcontrolsql
  
  注意
  
  Trace文件的具體路徑可以在執行完第)步操作後查看$ORACLE_BASE/admin/bdump/alert_ORCLora文件來確定
  
   用下面命令重新創建控制文件
  svrmgrl>shutdown abort;
  svrmgrl>startup nomount;
  svrmgrl>@createcontrolsql;
   用適當的方法進行數據庫全備份
  
  重做日志文件損壞
  
  數據庫的所有增改都會記錄入重做日志如果當前激活的重做日志文件損壞會導致數據庫異常關閉非激活的重做日志最終也會因為日志切換變為激活的重做日志所以損壞的非激活的重做日志最終也會導致數據庫的異常終止在ipas/mSwitch中每組重做日志只有一個成員所以在下面的分析中只考慮重做日志組損壞的情況而不考慮單個重做日志成員損壞的情況
  
  確定損壞的重做日志的位置及其狀態
  
   如果數據庫處於可用狀態
  select * from v$logfile;
  svrmgrl>select * from v$log;
  
   如果數據庫處於已經異常終止
  svrmlgr>startup mount;
  svrmgrl>select * from v$logfile;
  svrmgrl>select * from v$log;
  其中logfile的狀態為INVALID表示這組日志文件出現已經損壞log狀態為Inactive表示重做日志文件處於非激活狀態Active 表示重做日志文件處於激活狀態Current表示是重做日志為當前正在使用的日志文件
  
  損壞的日志文件處於非激活狀態
  
   刪除相應的日志組
  svrmgrl>alter database drop logfile group group_number;
  
   重新創建相應的日志組
  svrmgrl>alter database add log file group group_number (log_file_descritpion…) size log_file_size;
  
  損壞的日志文件處於激活狀態且為非當前日志
  
   清除相應的日志組
  svrmgrl>alter database clear unarchived logfile group group_number;
  
  損壞的日志文件為當前活動日志文件
  
  用命令清除相應的日志組
  svrmgrl>alter database clear unarchived logfile group group_number;
  如果清除失敗則只能做基於時間點的不完全恢復
  
  打開數據庫並且用適當的方法進行數據庫全備份
  svrmgrl>alter database open;
  
  部分數據文件損壞
  
  若損壞的數據文件屬於非system表空間則數據庫仍然可以處於打開狀態可以進行操作只是損壞的數據文件不能訪問這時在數據庫打開狀態下可以單獨對損壞的數據文件進行恢復若是system表空間的數據文件損壞則數據庫系統會異常終止這時數據庫只能以Mount方式打開然後再對數據文件進行恢復可以通過查看數據庫日志文件來判斷當前損壞的數據文件到底是否屬於system表空間
  
  非system表空間的數據文件損壞
  
   確定損壞的文件名字
  svrmgrl>select name from v$datafile where status=INVALID;
  
   將損壞的數據文件處於offline狀態
  svrmgrl>alter database datafile datafile_name offline;
  
   從相應的備份結果集中恢復關於這個數據文件的最近的備份對於沒有采用帶庫備份的點可以直接從磁帶上恢復對於用帶庫備份的點用相應的rman腳本來恢復
  
   恢復數據文件
  svrmgrl>alter database recover datafile file_name;
  
   使數據庫文件online
  svrmgrl>alter database datafile datafile_name online;
  
   用適當的方法進行數據庫全備份
  
  system表空間的數據文件損壞
  
   以mount方式啟動數據庫
  svrmgrl>startup mount;
  
   從相應的備份結果集中恢復關於這個數據文件的最近的備份對於沒有采用帶庫備份的點可以直接從磁帶上恢復對於用帶庫備份的點用相應的rman腳本來恢復
  
   恢復system表空間
  svrmgrl>alter database recover datafile datafile_name;
  
   打開數據庫
  svrmgrl>alter database open;
  
   用適當的方法進行數據庫全備份
  
  表空間損壞
  
  若非system表空間已經損壞則數據庫仍然可以處於打開狀態可以進行操作只是損壞的表空間不能訪問這樣在數據庫打開狀態下可以單獨對損壞的表空間進行恢復若是system表空間損壞則數據庫系統會異常終止這時數據庫只能以Mount方式打開然後再對表空間進行恢復可以通過查看數據庫日志文件來判斷當前損壞的表空間是否是system表空間
  
  非system表空間損壞
  
   將損壞的表空間處於offline狀態
  svrmgrl>alter tablespace tablespace_name offline;
  
   從相應的備份結果集中恢復關於這個表空間最近的備份對於沒有采用帶庫備份的點可以直接從磁帶上恢復對於用帶庫備份的點用相應的rman腳本來恢復
  
   恢復表空間
  svrmgrl>alter database recover tablespace tablespace_name;
  
   使表空間online
  svrmgrl>alter tablespace tablespace_name online;
  
   用適當的方法進行數據庫全備份
  
  system表空間損壞
  
   以mount方式啟動數據庫
  svrmgrl>startup mount;
  
   從相應的備份結果集中恢復system表空間最近的備份對於沒有采用帶庫備份的點可以直接從磁帶上恢復對於用帶庫備份的點用相應的rman腳本來恢復
  
   恢復system表空間
  svrmgrl>alter database recover tablespace system;
  
   打開數據庫
  svrmgrl>alter database open;
  
   用適當的方法進行數據庫全備份
  
  整個數據庫的所有文件損壞
  
  整個數據庫所有文件的損壞一般是在共享磁盤陣列發生無法恢復的災難時才發生這種情況下只能對數據庫進行恢復若數據庫的歸檔目錄也已經丟失則數據庫不可能做完全恢復會有用戶數據的丟失
  
  沒采用帶庫備份的現場
  
   將最近的備份從磁帶上把各個文件解包到相應的目錄下
  
   以mount方式打開數據庫
  svrmgrl>startup mount;
  
   恢復數據庫
  svrmgrl>recover database until cancel;
  
   打開數據庫
  svrmgrl>alter database open resetlogs;
  
   用適當的方法進行數據庫全備份
  
  采用帶庫備份的現場
  
   以nomount方式打開數據庫
  svrmgrl>startup nomount;
  
   通過相應的rman腳本進行數據庫軟恢復
  $rman cmdfile=hot_database_restorercv
  
   打開數據庫
  svrmgrl>alter database open resetlogs;
  
   用適當的方法進行數據庫全備份
  
  存在最近的數據庫完整冷備份前提下的一些經典緊急情況的處理
  
  數據文件歸檔重作日志和控制文件同時丟失或損壞
  
  無新增archives 時的狀況
  
  條件和假設自上次鏡像備份以來尚未生成新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的鏡像(冷)拷貝
  
  恢復步驟
  
   將鏡像拷貝的datafile(s) 和control file(s) 抄送回原始地點:
  $ cp /backup/good_onedbf /orig_loc/bad_onedbf
  $ cp /backup/controlctl /disk/controlctl
  
   以mount 選項啟動數據庫
  $ svrmgrl
  svrmgrl> connect internal
  svrmgrl> startup mount
  
   以舊的control file 來恢復數據庫
  svrmgrl> recover database using backup controlfile until cancel;
  *** 介質恢復完成
  (必須馬上cancel )
  
   Reset the logfiles (對啟動而言不可省略)
  svrmgrl> alter database open resetlogs;
  
   關閉數據庫並做一次全庫冷備份
  
  新增archives 時的狀況
  
  條件和假設自上次鏡像備份以來已經生成新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的鏡像(冷)拷貝archive log(s) 可用
  
  恢復步驟
  
   如果數據庫尚未關閉則首先把它關閉
  $ svrmgrl
  svrmgrl> connect internal
  svrmgrl> shutdown abort
  
   將備份文件抄送回原始地點
  所有Database Files
  所有Control Files(沒有archive(s) 或redo(s) 的情況下control files 的更新無任何意義)
  所有OnLine Redo Logs (Not archives)
  initora file(選項)
  
   啟動數據庫
  $ svrmgrl
  svrmgrl> connect internal
  svrmgrl> startup
  
  數據文件 重作日志和控制文件同時丟失或損壞
  
  條件和假設Archivelog Mode; 有同步的所有所失文件的鏡像(冷)拷貝archive log(s) 可用
  
  恢復步驟(必須采用不完全恢復的手法)
  
   如果數據庫尚未關閉則首先把它關閉
  $ svrmgrl
  svrmgrl> connect internal
  svrmgrl> shutdown abort
  
   將備份文件抄送回原始地點
  所有Database Files
  所有Control Files
  所有OnLine Redo Logs(Not archives)
  initora file(選項)
  
   啟動數據庫然而並不打開
  svrmgrl>startup mount
  
   做不完全數據庫恢復應用所有從上次鏡像(冷)備份始積累起來的archives
  svrmgrl> recover database until cancel using backup controlfile;
  
  
  cancel
  
   Reset the logfiles (對啟動而言不可省略)
  svrmgrl> alter database open resetlogs;
  
   關閉數據庫並做一次全庫冷備份
  
  數據文件和控制文件同時丟失或損壞
  
  條件和假設Archivelog Mode; 有同步的datafile(s) 和control file(s) 的冷拷貝archive log(s) 可用
  
  恢復步驟
  
   將冷拷貝的datafiles(s) 和control file(s) 抄送回原始地點:
  $ cp /backup/good_onedbf /orig_loc/bad_onedbf
  $ cp /backup/controlctl /disk/controlctl
  
   以mount 選項啟動數據庫
  $ svrmgrl
  svrmgrl> connect internal
  svrmgrl> startup mount
  
   以舊的control file 來恢復數據庫
  svrmgrl> recover database until cancel using backup controlfile;
  *** 介質恢復完成
  (須在應用完最後一個archive log 後cancel )
  
   Reset the logfiles (對啟動而言不可省略)
  svrmgrl> alter database open resetlogs;
  
  重作日志和控制文件同時丟失或損壞時
  
  條件和假設Control Files 全部丟失或損壞Archivelog Mode; 有Control Files 的鏡像(冷)拷貝
  
  恢復步驟
  
   如果數據庫尚未關閉則首先把它關閉
  $ svrmgrl
  svrmgrl> connect internal
  svrmgrl> shutdown abort
  svrmgrl>exit
  
   以Control File 的鏡像(冷)拷貝覆蓋損壞了的Control File:
  $ cp /backup/controlctl /disk/controlctl
  
   啟動數據庫然而並不打開
  $ svrmgrl
  svrmgrl> connect internal
  svrmgrl> startup mount
  
   Drop 壞掉的redo log (排除硬件故障)
  svrmgrl> alter database drop logfile group ;
  
   重新創建redo log:
  svrmgrl> alter database add logfile group /orig_loc/logdbf size M;
  
   以舊的control file 來恢復數據庫
  svrmgrl> recover database until cancel using backup controlfile;
  (必須馬上cancel )
  
   Reset the logfiles (對啟動而言不可省略)
  svrmgrl> alter database open resetlogs;
  
   關閉數據庫並做一次全庫冷備份
  
  只發生歸檔重作日志丟失或損壞時
  
  根據不同環境和情況選擇下述手段之一
  
  a 馬上backup 全部datafiles (如果系統采用一般熱備份或RMAN 熱備份)
  
  b 馬上正常關閉數據庫並進行冷備份(如果系統采用冷備份)
  
  c 冒險前進!不做備份而讓數據庫接著跑直等到下一個備份周期再做備份這是在賭數據庫在下一個備份周期到來之前不會有需要恢復的錯誤發生
  
  注意:冒險前進的選擇如果發生錯誤而需要數據庫恢復則最多只能恢復到出問題archive log 之前的操作現場從另一個角度講archive log(s) 出現問題時數據庫若不需要恢復則其本身並沒有任何問題
  
  Oracle邏輯結構故障的處理方法
  
  邏輯結構的故障一般指由於人為的誤操作而導致重要數據丟失的情況在這種情況下數據庫物理結構是完整的也是一致的對於這種情況采取對原來數據庫的全恢復是不合適的我們一般采用三種方法來恢復用戶數據
  
  采用exp/imp工具來恢復用戶數據
  
  如果丟失的數據存在一個以前用exp命令的備份則可以才用這種方式
  
   在數據庫內創建一個臨時用戶
  svrmgrl>create user test_user identified by test;
  svrmgrl>grant connectresource to test_user;
  
   從以前exp命令備份的文件中把丟失數據的表按照用戶方式倒入測試用戶
  $imp system/manager file=export_file_name tables=(lost_data_table_name…) fromuser=lost_data_table_owner touser=test_user constraint=n;
  
   用相應的DML語句將丟失的數據從測試用戶恢復到原用戶
  
   將測試用戶刪除
  svrmgrl>drop user test_user cascede;
  
  采用logminer來恢復用戶數據
  
  Logminer是oracle提供的一個日志分析工具它可以根據數據字典對在線聯機日志歸檔日志進行分析從而可以獲得數據庫的各種DML操作的歷史記錄以及各種DML操作的回退信息根據這些用戶就可以將由於誤操作而丟失的數據重新加入數據庫內
  
   確認數據庫的utl_file_dir參數已經設置如果沒有則需要把這個參數加入oracle的初始化參數文件然後重新啟動數據庫下面例子中假設utl_file_dir=/opt/oracle/db
  
   創建logminer所需要的數據字典信息假設生成的數據字典文本文件為dictora
  svrmgrl>execute dbms_logmnr_dbuild(dictionary_filename=>dictora dictionary_location=>/opt/oracle/db);
  
   確定所需要分析的日志或者歸檔日志的范圍這可以根據用戶誤操作的時間來確定大概的日志范圍假設用戶誤操作時可能的日志文件為/opt/oracle/db/oradata/ORCL/redolog和歸檔日志/opt/oracle/arch/orcl/orclarc__ora
  
   創建要分析的日志文件列表按日志文件的先後順序依次加入
  svrmgrl>execute dbms_logmnradd_logfile(logfilename=>/opt/oracle/arch/orcl/orclarc__oraoptions=>dbms_logmnrNEW);
  svrmgrl> execute dbms_logmnradd_logfile(logfilename=> /opt/oracle/db/oradata/ORCL/redologoptions=>dbms_logmnrADDFILE);
  
   開始日志分析假設需要分析的時間在 :: ::之間
  svrmgrl>execute dbms_logmnrstart_logmnr(dictfilename=> /opt/oracle/db/dictorastarttime=>to_date( ::YYYYMMDD HH:MI:SS)endtime=>to_date(to_date( ::YYYYMMDD HH:MI:SS));
  
   獲取分析結果
  svrmgrl>select operationsql_redosql_undo from v$logmnr_contents;
  
   根據分析結果修復數據
  
  結束logmnr:
  svrmgrl>dbms_logmnrend_logmnr;
  
   用適當的方法對原數據庫進行數據庫全備份
  
  利用備份恢復用戶數據
  
  采用這種方法時並不是在原數據庫進行恢復而是利用數據庫備份在新的機器上重新建立一個新的數據庫通過備份恢復在新機器上將數據庫恢復到用戶誤操作前這樣就可以獲得丟失的數據將其恢復到原數據庫
  
   在新的機器上安裝數據庫軟件
  
   對於采用帶庫備份的現場需要在新的數據庫服務器上安裝調試相應的備份管軟件
  
   根據用戶誤操作的時間點進行基於時間點的數據庫恢復操作對於沒有采用帶庫備份的現場可以選取用戶誤操作前最近的備份磁帶進行恢復對於才用帶庫備份的點可以通過基於時間恢復點恢復的rman腳本來進行恢復
  
  重新打開數據庫
  svrmgrl>alter database open resetlogs;
  
   從新的數據庫中獲取丟失的用戶數據通過DML操作將其恢復到原數據庫中
  
   用適當的方法對原數據庫進行數據庫全備份
From:http://tw.wingwit.com/Article/program/Oracle/201311/17117.html
    推薦文章
    Copyright © 2005-2022 電腦知識網 Computer Knowledge   All rights reserved.