這裡會討論令Oracle停機時間最小化的步驟各種形式的停機計劃的或者是非計劃的總是不斷地發生一個DBA應該有正確的備份策略這樣在數據庫出現問題時就可以更快地恢復
以下是假定的備份策略和數據庫的運作條件
控制文件是鏡像的
數據庫運行在archivelog模式
每個星期都進行冷備份
每日都進行熱備份
每日都進行一次全數據庫導出
事件完整的數據庫重構
在這種情形下你可以使用全數據庫導出或者冷熱備份結合的方式來重構數據庫要注意的是無論你選擇哪種方式在線redo log中的事務都會丟失
事件恢復部分的表空間
可以使用以下的步驟來恢復
以restrict模式啟動數據庫
重新創建表空間
使用最新的全數據庫導出來導入並且使用ignore=y的選項;
關閉並且重新以normal的模式啟動數據庫實例
事件丟失一般的數據文件
丟失一般數據文件的恢復步驟根據所丟失的數據文件包含的表空間類型而定;例如回滾段用戶表空間索引表空間或者是只讀的表空間你可能會遇到以下的錯誤
嘗試啟動數據庫並且碰到錯誤的信息ORA ORA可能還有一個操作系統的錯誤
嘗試以normal或者immediate的模式關閉數據庫可能會碰到ORA ORA的錯誤信息還有一個系統錯誤
以下的步驟可以用作恢復
關閉數據庫
由熱備份中恢復丟失的數據文件
Startup mount數據庫
執行以下的查詢來得到所有你的在線redo log文件和它們相應的次序和首次修改號
SELECT XGROUP# MEMBER SEQUENCE# FIRST_CHANGE#
FROM V$LOG X V$LOGILE Y
WHERE XGROUP# = YGROUP#;
如果得到的CHANGE#比在線redo log最小的FIRST_CHANGE# 還小那麼該文件不能被完全恢復你可以有兩個選擇
如果可以接受丟失最近一次冷備份以來的數據庫修改裝入備份並且繼續恢復
如果不能接受丟失數據庫的修改那麼必須重新創建表空間
通過使用存檔和在線的redo log來恢復數據文件
打開數據庫
事件恢復一個特別的表
可以采用以下的步驟恢復
使用最近的一次全數據庫導出來導入表並且使用owner=和tables=的選項
考慮到性能的原因可能需要重建表索引
事件丟失控制文件
在數據庫起來並且運行時通常都不能檢測到控制文件的問題如果控制文件丟失或者損壞了Oracle將不會了解下次數據庫的啟動時將會導致ORA錯誤(標識控制文件%s的錯誤)還有一個系統級的錯誤
如果只是丟失了其中的一個控制文件可以采用下面的步驟來恢復
如果它正在運行的話先關閉它
查找丟失控制文件的原因是由於硬件的問題嗎(磁盤還是控制器)?
如果不是硬件的問題將控制文件的一個好的拷貝復制到丟失的位置並且跳到步驟
如果是硬件的問題復制一個好的控制文件拷貝到一個可靠的位置
編輯initsidora 或者 configsidora更新CONTROL_FILES以反映最新的控制文件位置
啟動數據庫
事件丟失全部的控制文件
可以采用以下的步驟恢復
關閉數據庫
進行一次全數據庫備份包括全部的數據文件和redo log文件
以NOMOUNT的狀態啟動數據庫
使用CREATE CONTROLFILE重新創建控制文件你也可以備份控制文件到一個trace文件然後執行該文件
在數據庫上進行媒體恢復
打開數據庫
使用shutdown normal關閉數據庫
對數據庫進行一次冷備份
事件丟失一個索引
最簡單的方法就是重新創建丟失的索引
事件丟失一個非活動的redo log
如果丟失redo數據恢復將是不完全的必須重新創建涉及的表空間要重新創建表空間可以使用全的數據庫導出這樣就可以很容易的導入數據並且重新創建該表空間的對象可以使用以下的步驟來恢復
通過Alter system來切換redo log文件
關閉數據庫
startup mount數據庫
離線刪除涉及的數據文件
打開數據庫
刪除用戶的表空間包括其中的內容
通過全數據庫備份重新創建表空間和其中的對象
事件丟失活動的Redo log
如事件討論的一樣如果丟失了redo數據恢復將是不完全的必須重新創建涉及的表空間可以采用以下的步驟恢復
關閉數據庫
startup mount數據庫
離線刪除涉及的數據文件
打開數據庫
刪除用戶的表空間包括其中的內容
通過全數據庫備份重新創建表空間和其中的對象
要注意的是活動的事務將會丟失
事件丟失存檔的Redo log文件
如果存檔的redo log文件丟失應該馬上進行一次冷備份最好也進行一次全數據庫導出沒有丟失的存檔redo log文件的任何恢復都將是不完全的
事件丟失活動的回滾段
這裡指的是丟失一個回滾段的一個數據文件這是一個危急的恢復過程它主要是在於保存活動的事務這裡假定數據庫已經起來而你想保存當前運行的事務要使用以下的恢復過程數據庫必須運行在archivelog模式下
可以使用以下步驟恢復
不要關閉數據庫對於這種事件數據庫啟動比關閉更容易解決問題
令屬於該數據文件中的全部回滾段離線
刪除全部離線的回滾段
在上面的第步中如果回滾段中有活動的事務你將不能令它離線可運行以下的查詢來查看哪些事物是活動的
SELECT SEGMENT_NAME XACTS ACTIVE_TX VSTATUS
FROM V$ROLLSTAT V DBA_ROLLBACK_SEGS
WHERE TABLESPACE_NAME = tablespace_name AND
SEGMENT_ID = USN;
如果上面的查詢沒有結果那麼所有的回滾段都是離線的但是如果上面的查詢返回一行或者多行並且其狀態為PENDING OFFLINE那麼可檢查這些回滾段的ACTIVE_TX列帶有值的回滾段將很快會離線;但是非的值表示上面有活動的事務它們需要被提交或者回滾
處理活動的事務執行以下的查詢來查看哪些用戶的事務被指派到該回滾段
SELECT SSID SSERIAL# SUSERNAME RNAME ROLLBACK
FROM V$SESSION S V$TRANSACTION T V$ROLLNAME R
WHERE RNAME IN (pending_rollbackpending_rollback pending_rollbackN) AND
STADDR = TADDR AND
TXIDUSN = RUSN;
在知道哪些用戶在pending offline的回滾段上有活動的事務後可以要求他們提交或者回滾他們的事務或者可以使用以下的命令殺掉它們的進程
ALTER SYSTEM KILL SESSION sid serial#;
在你處理完所有活動的事務後執行以下的步驟
丟棄表空間及其中的全部內容
重新創建回滾表空間
重新創建回滾段並且令它們在線
事件丟失全部的回滾段
在這種事件下將丟失全部活動的事務並且需要重新創建回滾段這樣大的問題可能是由於一個硬件問題造成的可以采用以下的步驟恢復
關閉數據庫
使用DBVERIFY驗證全部的數據文件
解決其它的硬件問題或者數據文件損壞
以startup mount的方式啟動數據庫實例
在數據庫上執行媒體恢復
打開數據庫
按需要創建新的回滾段
事件導出文件損壞
如果導出文件不能用了那麼應該冷備份數據庫並且進行一個全的數據庫導出這是假定數據庫自身沒有問題如果數據庫也損壞了那麼應該執行以下的步驟
ORA錯誤信息通常都表示一個或者多個的數據文件損壞了查明哪些表受到影響它們應該是錯誤信息中指明的數據文件中的表格
跳過壞的數據塊將數據由表格中選擇到臨時表格中
丟棄損壞的表
將臨時表重命名為丟棄的表
重新建立受影響表上的全部索引
使用VALIDATE STRUCTURE CASCADE的選項來分析全部損壞的表
要注意的是損壞塊中數據將會丟失並且不能恢復
事件在熱備份時關機
如果在熱備份正在進行的時候突然關機其中的一些表空間將可能處在備份模式當你嘗試打開數據庫時它將只能mount並且指示某些表空間處於熱備份模式由於數據庫不能打開你將不能讓表空間脫離熱備份模式你可以使用以下的步驟恢復
startup mount數據庫
查詢v$backup以查看哪些數據文件處於ACTIVE狀態
通過使用命令ALTER DATABASE DATAFILE END BACKUP來將這些數據文件脫離備份模式
打開數據庫
事件恢復到某個特別的時間點
以下的步驟可用來執行pointintime恢復
關閉數據庫實例
以NOMOUNT的狀態啟動數據庫實例
使用UNTIL的選項來恢復數據庫
打開數據庫
Shutdown NORMAL
啟動數據庫實例
事件恢復到一個特別的事件或者活動
可以使用以下的步驟來恢復
關閉數據庫實例
以NOMOUNT狀態啟動數據庫實例;
使用UNTIL CANCEL來恢復數據庫提供存檔的redo log文件請求直到該活動/事件為止
輸入CANCEL來取消恢復
打開數據庫;
使用NORMAL的模式來關閉數據庫
啟動數據庫實例
結論
高可用性對於任何的商業都是很重要的ORACLE DBA可以通過一些計劃以確保停機時間最小化這篇文章討論了不同的策略可以達到這個目的
From:http://tw.wingwit.com/Article/program/Oracle/201311/16850.html
