Control file 專題

標籤：style   blog   http   io   os   使用   ar   strong   for   

control file 中包含以下內容:

• database name
• time stamp of database creation
• Synchronization information(checkpoint and log sequence information) needed for recovery
• Names and locations of datafiles and redo log files
• Archiving mode of the database
• Current log sequence number
• Recovery Manager backup meta data(RMAN)

rman 的資訊是由 oracle 系統自動更新的.

資料庫要想開啟, datafile, redo log, control file 必須同步.

開啟 rman 的前提條件是 資料庫處於 mount 或 open 狀態, 那麼如果control file 損壞, 資料庫將不能 mount 或 open, 所以就無法使用 rman. 所以, control file 損壞, 只能使用以下的手動方法來處理.

Resetlogs

The resetlogs option is always required after incomplete media recovery or recovery using a backup control file.

• Archives the current online redo logs(if they are accessible) and then erases the contents of the online redo logs and resets the log sequence number to 1.
• Creates the online redo log files if they do not currently exist.
• Reinitializes the control file metadata about online redo logs and redo threads.
• Updates all current datafiles and online redo logs and all subsequent archived redo logs with a new resetlogs scn and time stamp.

以下內容, 為轉載+總結, 很好

控制檔案的恢複與重建, 是很困難的.

通常在當前控制檔案丟失，或者當前的控制檔案與需要恢複的控制檔案不一致的情況下，我們需要重新建立一個控制檔案或者使用 unsing
backup controlfile方式來恢複控制檔案。說簡單點，只要是備份的控制檔案與當前的控制檔案不一致進行恢複資料庫，就需要使用到 unsing
backup controlfile方式，而一旦使用了該方式，則需使用resetlgos選項來開啟資料庫

所以控制檔案是很麻煩的, 控制檔案的恢複, 只有兩種辦法:

1. 通過以前備份過的控制檔案來恢複, using backup controlfile

2. 重建控制檔案, alter database backup controlfile to trace as ‘/u01/backup_controlfile/recreate_control.txt’

要注意, 對控制檔案操作之前, 一定要先對資料庫進行一次全備.

1. 恢複控制檔案, using backup controlfile

先將資料庫設定成 mount 狀態.

ls –hltr /u01/oradata/ora10g/ 查詢 control 的時間.

資料庫mount以後, 控制檔案的時間會更新為最新時間.

查看instance狀態, select instance_name, status, database_status from v$instance;

確認當前controlfile狀態: 可以看到, 當前controlfile 狀態是 current, open_resetlogs 為 not allow.

此時, 假如我們control file 丟失了, 我們使用以前的 backup controlfile 來恢複

recover database using backup controlfile; -- 注意這裡並不需要提供 backup controlfile 的路徑.

輸入完上邊命令後, 出現如下提示:

它建議我們使用 /u01/oradata/ora10g/archivelog/arch_1_17_831209795.arc 來進行恢複, 但是, 我們實際去該目錄去查看, 並沒有看到該檔案. 此時我們輸入 cancel, 會顯示 recover…, 然後我們查看 control file 的狀態.

可以看到, 此時 control file 的狀態已經從 current 變成了 backup, open_resetlogs 也從 not allowd 變成了 required.

此時, 我們嘗試著開啟資料庫, alter database open; 注意一定要使用 alter database open resetlogs;

這時, 我們查看上邊 recover 給出的提示:

suggested : 這條不行, 我們查看了該檔案的目錄, 裡邊沒有這個suggest 檔案.

cancel ：也不行, 我們做過實驗, 無法開啟資料庫.

auto : 沒試過, 估計沒戲

filename: 最後一條了, 此時我們可以指定 redo log file, 首先查詢當前是執行的那個 redo log file,

可以看到, 當前是 redo01.log 正在執行, 我們就用這個檔案作為 filename 再次運行 recover database using backup controlfile

注意: 我們直接輸入 /u01/oradata/ora10g/redo01.log -- 沒有引號

系統顯示 log applied, Media recovery complete.

這時候, 我們嘗試 open database. alter database open resetlogs;

此時可以看到, database open 成功了, 並且 controlfile 的狀態也變成了 current了, 此時如果你查看系統上 control file的時間, 也同步到目前時間了.

查看 archivelog list , 看到沒, 所有的號碼變成了1, 這是一個incarnation, 下面有具體的 incarnation的解釋.

總結(轉載)

1、using backup controlfile用於恢複備份的控制檔案與當前的控制檔案不一致的情形
2、一旦使用了using backup controlfile方式，控制檔案的類型將由 current 轉移到 backup 類型，同時open_resetlogs為required
3、一旦使用了using backup controlfile方式，後續再次使用recover database將變得無效
4、必須要使用 resetlogs 方式開啟資料庫，即使我們做的是完全恢複
5、注意理解示範中時間狀態的更新情況。實際上來說是執行個體的啟動過程，即：
nomount: 根據pfile 或 spfile 啟動相關後台進程，分配SGA
mount: 開啟控制檔案，檢查控制檔案狀態一致性，將資料庫與執行個體關聯起來
open: 根據控制檔案中記錄的資料檔案記錄檔對其進行逐一檢查無誤後，整個資料庫置於open狀態

2. 重建控制檔案

有些情況, 你必須重建控制檔案, 例如資料庫的名字變更, 等等.

首先要得到重建控制檔案的指令碼

1. alter database backup controlfile to trace as ‘/u01/user_controlfile/recreate_control.txt; 得到重建controlfile 指令碼

2. 整理這個指令碼

當我們將控制檔案備份到trace 檔案時，可以看到裡麵包含了2部分的重建語句，一個是使用resetlogs，另一個是使用noresetlogs

使用 noresetlogs 僅是當前所有的 online logs 可用時, 也就是說, 如果online redo logs 不可用, 那麼就必須使用 resetlogs.

使用 resetlogs, 將導致 online redo logs 裡的內容丟失, 並且所有的備份失效, 僅當 online redo logs 損壞的情況下, 使用 resetlogs 模式.

另外, 在資料庫開啟時

use RESETLOGS after incomplete recovery (when the entire redo stream was not applied), RESETLOGS will initialize the logs, reset your log sequence number, and start a new “incarnation” of the database. RESETLOGS 會初始化 log sequence 號, 建立一個新的 incarnation.

補充, incarnation:

incarnation: 英文翻譯是化身, 在oracle 中可以叫做資料庫的一個實體, 它指的是一個重設scn後的資料庫的情境. 一個資料庫在剛開始被建立出來, scn 號為1, 隨著運行, scn 不斷單調遞增, oracle 就是根據scn 描述資料庫的整個發展過程, 可以說scn就是資料庫的時間軸, 當資料庫正常運行, 或者執行完全恢複時, scn只會單調遞增直到最新的scn, 這樣資料庫中所有的資料都按照時間的順序改變著, 但如果資料庫出現了人為誤操作, 需要執行不完全恢複, 這時候就的用以前備份的所有資料檔案將資料版本回到以前, 然後從那個起點開始應用日誌, 直到出現人為故障之前的那一刻, 但這時, scn並未達到最新的scn, 而是得到了之前的某個scn, 在這一刻，人為故障還未發生。在完成recover .. until .. 的操作後，所有的資料檔案通過應用日誌到了統一的一點，但資料庫暫時還不能正常開啟，因為控制檔案中記錄的是最新的scn，與應用日誌後的資料檔案並不一致，因此無法直接開啟資料庫回到原始的狀態，必須通過resetlogs的方式強制控制檔案、重做記錄檔以及資料檔案的scn一致，此時新開啟的資料庫中第一個scn等於應用日誌到的最後一條日誌的scn號+1（在警示記錄檔中可以看到RESETLOGS after incomplete recovery UNTIL CHANGE 145936 這樣的資訊，開啟資料庫後的scn則為145937）。資料庫每次resetlogs之後，scn和記錄序號都被重設，因此每次resetlogs都會產生一個新的incarnation，而incarnation的資訊儲存在控制檔案中，在rman中可以通過list incarnation看到實體資訊。

可以通過 rman 將資料庫恢複到某一個 incarnation, 後續再介紹

既然已經直到了 resetlogs 和 noresetlogs 的區別, 那麼就分別進行測試：

1. 測試 noresetlogs :

整理指令碼: (linux 命令)

去除空白行和注釋行: grep –v ^- - /u01/user_controlfile/re_noresetlogs.txt | grep –v ^$ >/u01/user_controlfile/re_noresetlogs.txt

這是整理之後的指令碼, 直接使用這個指令碼就可以了

首先登陸 sqlplus /nolog, conn /as sysdba

@/u01/user_controlfile/no.txt

注意: 因為資料庫中包含了 offline 和 read only tablespace, 這個是要在建立 control file 特殊處理的. 從 dba_tablespaces 和 dba_data_files 視圖, 我們可以看出:

2. 測試 resetlogs :

同樣, 整理指令碼: (linux 命令)

去除空白行和注釋行: grep –v ^- - /u01/user_controlfile/re_noresetlogs.txt | grep –v ^$ >/u01/user_controlfile/re_noresetlogs.txt

這兩份指令碼, 基本相同, 只是上邊的第2行命令變成了 RESETLOGS, 另外有一點, 關鍵的一點要注意

之前的指令碼命令式 recover database

後面的指令碼命令 recover database using backup controlfile

@/u01/user_controlfile/yes.txt

出現了這些內容 :

首先查看了 arch_1_2_842279302.arc 這個檔案是不存在的, 所以不能使用這個suggest 檔案來恢複了.

使用一個 redo log 記錄檔, 就恢複成功了.

首先在指令碼的第一行添加 set echo on, 來確認指令碼每個內容的結果

可以看到 control file created. 到這時, 沒有問題

recover database using backup controlfile 出現了問題. 注意指令碼中後面的操作的基礎, 就是這一步, 這一步不成功直接導致後邊失敗. 但是目前, 我們control file 已經建立完成了.

跟之前一樣, 上邊的 recover database using backup controlfile 時也是使用一個 redo log file 就可以成功.

另外, 如果 controlfile 和 online redo log file 都丟失了, 並且最新的 online redo log file 沒有歸檔, 也沒有多路, 那麼資料庫只能做不完全恢複了.

恢複的辦法是:

首先備份當前所有的資料庫檔案.

然後將原來的一個全備copy 到目前資料庫的目錄,( 這裡假設之前的全備的control file也丟失了)

此時可以使用 create control file 的指令碼重建 controlfile ( 注意這裡是 resetlogs 模式 )

建立完新的 controlfile 之後, recover database using backup controlfile;

此時會提示你, 這個時候你會發現, 如果你儲存了之前的全部archivelog是多麼有用, 按照提示的archivelog 進行恢複. 這樣, 系統就可以恢複到你這個archivelog歸檔的所有內容, 但是至於最新的redo log 的內容, 就丟失了, 需要讓使用者重做.

解決辦法:

1. 你有多工 control file, 這種基本上相當於沒丟

2. create controlfile 命令建立一個新的control file, 這種要求你知道所有的file關於database的細節. (alter database backup controlfile to trace as ‘/u01/user_backup/ctl.txt’, 儲存成這個檔案格式, 便於我們查看.)

3. 使用之前備份的 control file 來恢複, alter database backup controlfile to ‘/u01/user_backup/controlfile_back.bak’;

問題1: 版本不一致

(假如 control01 的版本高於另外兩個, 則參考如下辦法:)

這種只是建立在多工前提下, 控制檔案並沒有丟失, 只是多路之間的控制檔案版本不同, 只要用高版本替換低版本的就可以了, 簡單

辦法: cp /u01/oracle/oradata/ora10g/control01.ctl cp /u01/oracle/oradata/ora10g/control02.ctl

cp /u01/oracle/oradata/ora10g/control01.ctl cp /u01/oracle/oradata/ora10g/control03.ctl

問題2: 部分控制檔案丟失

這種也是建立在多工前提下, 少部分複用的控制檔案丟失, 也只是需要copy 一份其他的控制檔案粘貼到相應路徑, 並改成正確的檔案名稱就可以了. 簡單

將存在的控制檔案複製到目的路徑並更改控制檔案名稱字為正確的控制檔案名稱

問題3: 非歸檔模式下, 所有 control file 丟失, 重建control file

考慮以下因素:

• 搞清各個記錄檔的大小和位置
• 搞清各個資料檔案的位置
• 設定正確的字元集

上邊的轉載, 有具體的重建control file 的詳細內容

control file 真的要小心, 問題很嚴重, 因為control file 是動態變化的, 如果不是自動備份, 那麼當所有的 control file 都丟失了, 那麼就要進行 不完整恢複了, 因為如果你用之前的 control file, 那麼 control file 裡邊的內容, 比如 SCN 等內容必然跟現在不一樣, 所以還是設定自動備份 control file 和進行多工, 一定要保住 control file.

不完整恢複

Reasons for Performing Incomplete Recovery : (不完整恢複的原因)

• Complete recovery fails because an archived log is lost.
• All control files are lost. (哇, 如果所有的控制檔案丟失, 那麼只能不完整恢複)
• All unarchived redo log files and a datafile are lost.
• User error
  • An important table was dropped.
  • Invalid data was committed in a table.

Missing archive: A complete recovery operation fails because of a bad or missing archived log. Recovery can only be completed to a time in the past, prior to applying the archived log.

Loss of control files : You did not mirror your control file and you do not know the structure of your database, but you have a backup of an old binary copy.

Loss of redo logs: Redo logs were not mirrored and you lost a redo log before it was archived, along with a datafile. Recovery cannot continue past the lost redo log.

User error: A user drops the wrong table, commits data updated with an incorrect WHERE clause, and so forth.

3 種類型的 不完整恢複

- Time-based recovery : 故名思議, 恢複到之前的一個時間點.

- Cancel-based recovery : 跟 redo log sequence 有關. 下邊有例子, 參考藍色例子

- Change-based recovery : 恢複到之前一個 SCN.

另外, 如果你需要使用舊的 control file 來進行不完全恢複, 那麼要使用 recovery using a backup control file. ( 這種情況一般用於 all control files are lost, 只剩下之前備份的control file了.

執行不完整恢複的需要注意的內容 :

1. 在進行不完整恢複之前, 先儲存所有的資料庫檔案到其他目錄, 包括 redo log 和 archive log. (防止你在操作的時候對資料庫造成無法復原轉的傷害, 如果實在不能全部備份, 最起碼也要備份 control file 和 archive log file)

2. 在沒有確認所有的恢複成功之前, 不要讓使用者可以訪問資料庫.

3. Back up (and later remove) archived logs from the system to prevent mixing archives from different database incarnations.

例如:

- A database at log seq 144 has archived logs from arch_120.rdo to arch_143.rdo.

- After performing incomplete recovery, a new database incarnation is created, setting the database log seq to 0.

- Archived log arch_120.rdo to arch_143.rdo are now part of the old database incarnation.

- After 120 log switches, the archived log arch_120.rdo will be overwritten, and is backed up with all other archives(including the old archived logs arch_121.rdo to arch_143.rdo). 兩個database 的 archivelog 混在一起了 mixing

- At a later stage, if recovery requires arch_124.rdo, you need to make sure that the archived log restored from the backup is for the correct database incarnation, otherwise an error will result.

4. 在備份和恢複之前, 要一直確認 Alert Log file, 因為所有的流程的資訊都會被儲存在 alert log file 裡.

執行不完整恢複的步驟:

1. Shutdown and backup the database.

例如: shutdown immediate

2. Restore all datafiles. Do not restore the control file, redo logs, password file, or parameter file.

這一步的目的是, 將所有的 datafile 和 archivelog file 備份一下, 是將目前資料庫目錄中的資料檔案和 archivelog檔案copy 到別的地方.

3. Mount the database.

startup mount;

4. Recovery the datafiles to a point before the time of failure.

recover database until cancel

recover database until time ‘2014-03-14:14:22:22’

recover database until time ‘2014-03-14:14:22:22’ using backup controlfile -- 使用以前備份的控制檔案

recover [automatic] database <option> , 其中:

automatic 表示: 自動應用 archived 和 redo log files.

option: until time ‘YYYY-MM-DD:HH:MI : SS’;

until cancel;

until scn <integer>;

using backup control file;

5. Open the database with RESETLOGS.

alter database open resetlogs;

archive log list; -- 可以看到目前的 log sequence 號碼, 例如上邊說明, 之前的 seq 號已經到了 144, 可能你恢複完以後就看到 seq 號為0, 那麼表示恢複成功了.

6. Perform a closed database backup.

shutdown immediate;

copy 所有的檔案, 備份起來(全備), 注意, 全備以後, archivelog 檔案就沒有用了, 前面也提到了, 如果繼續使用, 會出現混合mixing, 所以全備以後, 刪除所有的資料庫指定目錄的archivelog 檔案, 至於你在恢複之前的 archivelog 檔案, 是否刪除自己考慮, 因為對目前資料庫沒有影響(儲存在別的目錄)

注意: 由於資料庫恢複到了之前的一個時間點, 那麼該時間點之後的正確事務要再進行一次.

例子:

cancel-based recovery 例子 (跟記錄檔有關)

假設:

現在是12：00, EMPLOYEES table was dropped while someone was trying to fix bad blocks, log files 同時存放在這個磁碟上, 這個 table 是在上午 11:45 左右被刪除的, 現在開會: 開會發現:

redo log 沒有多工, 換句話丟失的 redo log 沒有鏡像. 1 個 redo log file missing. 並且丟失的這個 log file 也沒有被歸檔. (log2a.rdo 丟失)

現在有的 redo log 包含了 11:34 的資訊. 26 分鐘的資料丟失了. 通過 v$logfile 可以看到這個時間.

這時候查詢 v$log_history 可以看到 缺失的那個 log seq 號, 這裡是 48.

恢複的步驟與前面基本相同, 只是恢複的命令是 recover database until cancel. 注意, 這樣是恢複到了(recover the database until log seq 48) 前面seq 47 的內容全面恢複了, 恢複完以後, 可以查看該 EMPLOYEES, 看到該內容可以尋找的到.

Using backup control file recovery :

假設:

現在是12:00, tablespace containing the EMPLOYEES table has been dropped. The error occurred around 11:45, Many employee records were updated this morning, but not since 11:00. 並且每天晚上都會做一次備份.

事件順序:

1. someone, drop tablespace emp_ts including contents;

2. 立刻告訴所有使用者退出登入, 你將資料庫設定成 restircted, 限制使用者登入, alter system enable restricted session;

3. 經過分析, 你找到了昨天晚上備份的 control file, 因為當前的 control file 將被覆蓋, 所以你要先確認目前這個 control file 裡的資訊.

select * from v$log;

select tablespace_name, file_name from dba_data_files where tablespace_name = ‘EMP_TS’

通過以上確認, 可以發現

EMP_TS tablespace has one datafile.

The current log sequence number is 61.

You confirm that the tablespace was dropped at 11:44:54 ( 通過 alert_log file 中的時間戳記, 可以確認這個操作的時間 )

datafile number 4 is offline.

4. shutdown the database, backup control files. 然後將之前備份的包含了該tablespace資訊的 control file 和 datafile 移動到當前資料庫檔案的目錄.

5. 要確認所有的 offline datafiles 都變成 online, because any offline files may be unrecoverable after recovery:

select * from v$recover_file; 看到有 offline的, 就 alter database datafile 4 online;

6. recover database until time ‘2001-03-09:11:44:00’ using backup controlfile;

7. alter database open resetlogs;

8. 確認 EMPLOYEES table 是否存在

9. 全備

10. 通知使用者, 11:44 分之後的操作要重做.

Loss of Current Redo log files 丟失了當前正在使用的 redo log file

1. 當想要開啟資料庫時, 會得到錯誤, current log file 丟失.

2. 需要 recovery 了, 首先確認 log sequence number , select * from v$log; 假如 current log seq no. 是 61

3. 將原來備份的 datafile copy 到資料庫指定的路徑. 然後, recover until cancel, 這個操作會將資料庫恢複到 log seq 到 60.

4. alter database open resetlogs

5. The database should now be operational, because any missing log files will be re-created.

Note: If log files need to be re-created on another disk due to media failure, use the ALTER DATABASE DROP LOG GROUP and ALTER DATABASE ADD LOG GROUP commands to create the log files manually.

6. 全備

Control file 專題