Oracle執行個體恢複

--=======================

-- Oracle 執行個體恢複

--=======================

一、Oracle執行個體失敗

Oracle執行個體失敗多為執行個體非一致性關閉所致，通常稱為崩潰(crash)。執行個體失敗的結果等同於shutdown abort。

執行個體失敗的原因

電源負載故障

硬體故障

後台進程失敗

異常關閉資料庫

執行個體失敗後的狀況

資料庫可能丟失已提交的事務以及儲存了未提交的事務，導致資料庫出現不一致的情況

解決方案

使用startup 重新啟動執行個體。執行個體實現自動回復，根據聯機記錄檔前滾提交的事務，復原未提交的事務

查看警示日誌、追蹤記錄檔等找出出現故障的原因

二、檢查點

檢查點在體繫結構中已經討論，執行個體的恢複與檢查點息息相關，因此再次討論檢查點進程

1.什麼是檢查點

是一個資料庫事件，用於減少崩潰恢復，檢查點位置決定了執行個體恢複的起始位置

由後台進程觸發，觸發時ckpt進程通知dbwn進程將資料緩衝區的髒資料寫入到資料檔案

ckpt進程同時負責更新資料檔案的頭部資訊及控制檔案上的檢查點資訊

2.檢查點的觸發條件

在日誌切換的時候(自動切換或手動切換)

資料庫用immediate ，transaction ，normal選項shutdown資料庫的時候

使用者手動觸發(alter system checkpoint)

alter tablespace tablespace_name begin | end bakcup

alter tablespace tablespace_name offline

alter database datafile '<dir>' offline

alter tablespace | datafile read only

3.檢測點隊列

是一個髒資料庫鏈表

檢查點隊列中的每一條修改過的記錄包一個唯一的資料區塊標識符(記錄檔號，塊編號，位移量)

最早隊列將被優先寫入到資料檔案(而不論期間是否被多次修改)

最早隊列被寫入完成後將從隊列中清除

4.檢查點的分類

完全檢查點

在Oracle 8i 以前，當檢查點發生時，Oracle將髒緩衝列表上的資料全部寫入到資料檔案，稱為完全檢查點，又稱常規檢查點

特定的觸發條件

alter system switch logfile

shutdown normal,immediate,transactional

alter system checkpoint

增量檢查點(fast-start checkpoint)

主要是引入了檢查點隊列機制,每s，ckpt將檢查點隊列中最老的RBA更新到控制檔案，RBA(重做日誌塊地址)同時將作為執行個體恢複的起點

增量檢查點則細分了完全檢查點，使得資料可以周期性按最老的資料區塊寫入到資料檔案

每一個髒塊會被移到檢查點隊列裡面去，按照LRBALow RBA第一次對此塊修改對應的redo block address）來排列

最早寫入檢查點隊列資料區塊的low rba值是最小的，即便該隊列中的最小隊列被修改多次，但修改後它在檢查點隊列裡的順序不會改變

當執行增量檢查點時，DBWn從檢查點隊列按照LRBA的順序來保證先修改的資料可以按順序優先被寫出來實現檢查點的增進

此時ckpt進程使用輕量級的控制檔案更新協議，將當前最低的RBA寫入控制檔案

ckpt在進行輕量級更新時，並不會改寫控制檔案中資料檔案的檢查點資訊及資料檔案頭資訊

僅僅是記錄控制檔案檢查點SCN並根據增量檢查點寫出增進RBA資訊

通過將完全檢查點轉變為增量檢查點將大大縮短執行個體的恢復

註：更新資料檔案頭部及控制檔案滯後於檢查點事件的發生

增量檢查點的觸發

滿足初始話檔案log_checkpoint_interval、log_checkpoint_timeout、

fast_start_io_target、fast_start_mttr_target的設定的值

最小的記錄檔的大小

Buffer Cacha中髒塊的數量

部分檢查點

資料表空間的髒資料寫入到磁碟

由alter tablespace tablespace_name offline 觸發

5.完全檢查點與增量檢查點的差異

完全檢查點會將檢查點的資訊同時寫入到控制檔案及資料檔案

增量檢查點則只將RBA寫入到控制檔案

6.查看檢查點的資訊,設定LOG_CHECKPOINTS_TO_ALERT參數為true

ALTER SYSTEM SET LOG_CHECKPOINTS_TO_ALERT = TRUE ;

--查看log_checkpoints_to_alert參數

SQL> SHOW PARAMETER log_checkpoints_to_alert

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

log_checkpoints_to_alert boolean FALSE

--設定log_checkpoints_to_alert參數

SQL> ALTER SYSTEM set log_checkpoints_to_alert = TRUE;

System altered.

--清空警示記錄檔的內容

SQL> ho cat /dev/null > /u01/app/oracle/admin/orcl/bdump/alert_orcl.log

--查看資料檔案頭部資訊中控制檔案的資訊為3037172

SQL> SELECT file#,status,tablespace_name ,

2 dbms_flashback.get_system_change_number cur_scn,

3 to_char(resetlogs_time,'yyyy-mm-dd hh24:mi:ss') rst_dt,

4 resetlogs_change# rst_scn,

5 to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') ckpt_dt,

6 checkpoint_change# ckpt_scn,checkpoint_count ckpt_cnt

7 FROM v$datafile_header;

FILE# STATUS TABLESPACE_NAME CUR_SCN RST_DT RST_SCN CKPT_DT CKPT_SCN CKPT_CNT

---------- ------- --------------- ---------- ------------------- ---------- ------------------- ---------- ----------

1 ONLINE SYSTEM 3037641 2010-07-20 11:59:23 2837290 2010-07-25 19:05:30 3037172 531

2 ONLINE UNDOTBS1 3037641 2010-07-20 11:59:23 2837290 2010-07-25 19:05:30 3037172 493

3 ONLINE SYSAUX 3037641 2010-07-20 11:59:23 2837290 2010-07-25 19:05:30 3037172 532

4 ONLINE USERS 3037641 2010-07-20 11:59:23 2837290 2010-07-25 19:05:30 3037172 534

5 ONLINE EXAMPLE 3037641 2010-07-20 11:59:23 2837290 2010-07-25 19:05:30 3037172 489

6 ONLINE TBS1 3037641 2010-07-20 11:59:23 2837290 2010-07-25 19:05:30 3037172 412

7 ONLINE TBS1 3037641 2010-07-20 11:59:23 2837290 2010-07-25 19:05:30 3037172 407

7 rows selected.

SQL> save /u01/app/oracle/oradata/query_1.sql;

Created file /u01/app/oracle/oradata/query_1.sql

SQL> ALTER SYSTEM SWITCH LOGFILE; --切換日誌

System altered.

SQL> ho cat /u01/app/oracle/admin/orcl/bdump/alert_orcl.log | more --查看警示日誌

Sun Jul 25 19:14:29 2010

Beginning log switch checkpoint up to RBA [0xd.2.10], SCN: 3037657

Thread 1 advanced to log sequence 13

Current log# 3 seq# 13 mem# 0: /u01/app/oracle/oradata/orcl/redo3a.rdo

Current log# 3 seq# 13 mem# 1: /u01/app/oracle/oradata/orcl/redo3b.rdo

SQL> @/u01/app/oracle/oradata/query_1.sql; --資料檔案頭部滯後分鐘後與警示日誌記錄的SCN相同

FILE# STATUS TABLESPACE_NAME CUR_SCN RST_DT RST_SCN CKPT_DT CKPT_SCN CKPT_CNT

---------- ------- --------------- ---------- ------------------- ---------- ------------------- ---------- ----------

1 ONLINE SYSTEM 3037803 2010-07-20 11:59:23 2837290 2010-07-25 19:14:29 3037657 532

2 ONLINE UNDOTBS1 3037803 2010-07-20 11:59:23 2837290 2010-07-25 19:14:29 3037657 494

3 ONLINE SYSAUX 3037803 2010-07-20 11:59:23 2837290 2010-07-25 19:14:29 3037657 533

4 ONLINE USERS 3037803 2010-07-20 11:59:23 2837290 2010-07-25 19:14:29 3037657 535

5 ONLINE EXAMPLE 3037803 2010-07-20 11:59:23 2837290 2010-07-25 19:14:29 3037657 490

6 ONLINE TBS1 3037803 2010-07-20 11:59:23 2837290 2010-07-25 19:14:29 3037657 413

7 ONLINE TBS1 3037803 2010-07-20 11:59:23 2837290 2010-07-25 19:14:29 3037657 408

SQL> SELECT TO_CHAR(sysdate,'yyyy-mm-dd hh24:mi:ss') FROM dual; --時間滯後分鐘 19:19:59 - 19:14:29

TO_CHAR(SYSDATE,'YY'

-------------------

2010-07-25 19:19:59

SQL> ALTER SYSTEM CHECKPOINT; --產生檢查點

System altered.

SQL> ho cat /u01/app/oracle/admin/orcl/bdump/alert_orcl.log | more --查看警示日誌中的SCN: 3037881

Sun Jul 25 19:14:29 2010

Beginning log switch checkpoint up to RBA [0xd.2.10], SCN: 3037657

Thread 1 advanced to log sequence 13

Current log# 3 seq# 13 mem# 0: /u01/app/oracle/oradata/orcl/redo3a.rdo

Current log# 3 seq# 13 mem# 1: /u01/app/oracle/oradata/orcl/redo3b.rdo

Sun Jul 25 19:19:34 2010

Completed checkpoint up to RBA [0xd.2.10], SCN: 3037657

Sun Jul 25 19:21:55 2010

Beginning global checkpoint up to RBA [0xd.116.10], SCN: 3037881

Completed checkpoint up to RBA [0xd.116.10], SCN: 3037881

SQL> @/u01/app/oracle/oradata/query_1.sql; --資料檔案頭部同步與警示日誌記錄的SCN相同，為3037881

FILE# STATUS TABLESPACE_NAME CUR_SCN RST_DT RST_SCN CKPT_DT CKPT_SCN CKPT_CNT

---------- ------- --------------- ---------- ------------------- ---------- ------------------- ---------- ----------

1 ONLINE SYSTEM 3037890 2010-07-20 11:59:23 2837290 2010-07-25 19:21:55 3037881 533

2 ONLINE UNDOTBS1 3037890 2010-07-20 11:59:23 2837290 2010-07-25 19:21:55 3037881 495

3 ONLINE SYSAUX 3037890 2010-07-20 11:59:23 2837290 2010-07-25 19:21:55 3037881 534

4 ONLINE USERS 3037890 2010-07-20 11:59:23 2837290 2010-07-25 19:21:55 3037881 536

5 ONLINE EXAMPLE 3037890 2010-07-20 11:59:23 2837290 2010-07-25 19:21:55 3037881 491

6 ONLINE TBS1 3037890 2010-07-20 11:59:23 2837290 2010-07-25 19:21:55 3037881 414

7 ONLINE TBS1 3037890 2010-07-20 11:59:23 2837290 2010-07-25 19:21:55 3037881 409

--查看完全檢查點

SQL> SELECT addr,indx ,rtckp_scn,

2 rtckp_tim,

3 rtckp_rba_seq,rtckp_rba_bno

4 FROM x$kccrt;

ADDR INDX RTCKP_SCN RTCKP_TIM RTCKP_RBA_SEQ RTCKP_RBA_BNO

-------- ---------- ---------------- -------------------- ------------- -------------

B7D59C10 0 3037881 07/25/2010 19:21:55 13 278

SQL> show parameter log_check --查看log_checkpoint_timeout的值

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

log_checkpoint_interval integer 0

log_checkpoint_timeout integer 1800

log_checkpoints_to_alert boolean TRUE

ho cat /u01/app/oracle/admin/orcl/bdump/alert_orcl.log --警示記錄檔中Incremental checkpoint

----------------------------------------------------------------------------------

Sun Jul 25 19:22:46 2010

Incremental checkpoint up to RBA [0xd.119.0], current log tail at RBA [0xd.119.0]

Sun Jul 25 19:52:51 2010

Incremental checkpoint up to RBA [0xd.37a.0], current log tail at RBA [0xd.420.0]

---------------------------------------------------------------------------------

SQL> select CPDRT,CPLRBA_SEQ||'.'||CPLRBA_BNO||'.'||CPLRBA_BOF "Low RBA",

2 CPODR_SEQ||'.'||CPODR_BNO||'.'||CPODR_BOF "On disk RBA",CPODS,CPODT,CPHBT

3 from x$kcccp where indx = 0; --獲得控制檔案中增量檢查點的資訊

CPDRT Low RBA On disk RBA CPODS CPODT CPHBT

---------- ------------------- ------------- ------- -------------------- --------

97 13.5574.0 13.6391.0 3041226 07/25/2010 22:16:37 725323317

--CPDRT列是檢查點隊列中的髒塊數目.

--CPODS列是on disk rba的scn

--CPODT列是on disk rba的時間戳記

--CPHBT列是心跳

三、執行個體恢複

1.當開啟非一致性關閉或shutdown abort資料庫時，將導致執行個體恢複

2.執行個體恢複過程為自動

3.使用聯機重做記錄檔中的資訊來同步資料檔案

4.涉及到兩類不同的操作

前滾：資料檔案被還原到執行個體失敗之前的狀態

復原：已修改但未提交的資料將被撤銷到修改之前的狀態

四、執行個體恢複的過程

下面的圖片來自Oracle官方教材

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/204S0M11-0.jpg" title="1.jpg" alt="165908555.jpg" />

1.首先Oracle會比較控制檔案中檢查點與資料檔案頭部資訊，探索資料不一致

2.從最後檢查點之後到記錄檔尾部將被重新應用到資料檔案，同時產生undo資訊(復原)，此階段也稱為cache recovery

3.資料檔案中包含已提交或未提交的資料，儘管存在未提交的資料，此時資料庫已經被開啟，允許使用者串連

4.未提交的事務將被復原

5.資料檔案中僅包含已提交的資料

五、調整執行個體恢複

1.為參數檔案中對恢複過程有影響的聯機日誌記錄數量和資料區塊設定合適的大小

2.調整聯機記錄檔的大小來影響檢查點發生的頻率

3.使用SQL 命令發生檢查點事件

4.使用Fast-start fault recovery

5.幾個恢複相關的參數

LOG_CHECKPOINT_TIMEOUT -->兩次checkpoint之間間隔的時間(單位是秒) ，該參數現已很少使用

LOG_CHECKPOINT_INTERVAL -->兩次checkpoint之間redo block 資料區塊的個數(不是db_block),

-- redo block size = os block size 該參數現已很少使用

FAST_START_MTTR_TARGET -->指定多長時間完成執行個體恢複(單位是秒) (後面示範中重點討論)

RECOVERY_PARALLELISM -->指定前滾時的並發度

FAST_START_PARALLEL_ROLLBACK -->復原階段時預先UNDO需要使用的塊，然後增加復原並發度

-- 2路CPU建議設定為LO,四路CPU建議設定為HI，否則預設置為false

FAST_START_IO_TARGET -->資料庫宕機所要做的恢複所需的IO的數量，10g之後很少使用

六、執行個體恢複相關的視圖

V$INSTACE_RECOVERY -->查看fast_start_mttr_target設定以及系統MTTR相關資訊

V$FAST_START_SERVERS -->交易回復時相關並發資訊

V$FAST_START_TRANSACTION -->正在恢複的事務的相關資訊

完全檢查點

select * from X$KCCRT where indx=0;

增量檢查點

SQL> select * from X$KCCCP where indx=0;

七、執行個體恢複示範

--刪除警示日誌

SQL> ho rm -f /u01/app/oracle/admin/orcl/bdump/alert_orcl.log

SQL> SELECT * FROM scott.emp WHERE ename = 'SCOTT';

EMPNO ENAME JOB MGR HIREDATE SAL DEPTNO

---------- ------------------------------ --------- ---------- --------- ---------- ----------

7788 SCOTT ANALYST 7566 19-APR-87 7100 20

--更新SCOTT的薪水且提交事務

SQL> UPDATE scott.emp SET sal = sal / 2 WHERE ename = 'SCOTT';

1 row updated.

SQL> COMMIT;

Commit complete.

--插入兩條新記錄且不提交事務

SQL> INSERT INTO scott.emp(empno,ename,job) SELECT '2001','Mark','Develpoer' FROM dual;

1 row created.

SQL> INSERT INTO scott.emp(empno,ename,job) SELECT '2002','Mary','Designer' FROM dual;

1 row created.

SQL> SELECT * FROM scott.emp WHERE empno IN (2001,2002);

EMPNO ENAME JOB MGR HIREDATE SAL DEPTNO

---------- ------------------------------ --------- ---------- --------- ---------- ----------

2001 Mark Develpoer

2002 Mary Designer

--強制關閉執行個體並重啟執行個體，則執行個體將自動復原

SQL> SHUTDOWN ABORT;

ORACLE instance shut down.

SQL> STARTUP

ORACLE instance started.

Total System Global Area 251658240 bytes

Fixed Size 1218796 bytes

Variable Size 88082196 bytes

Database Buffers 159383552 bytes

Redo Buffers 2973696 bytes

Database mounted.

Database opened.

--從警示日誌中獲得復原的相關資訊

SQL> ho ls /u01/app/oracle/admin/orcl/bdump

alert_orcl.log orcl_arc0_4016.trc orcl_arc1_4018.trc orcl_lgwr_3995.trc

SQL> ho cat /u01/app/oracle/admin/orcl/bdump/alert_orcl.log

----------------------------------------------------------------

ALTER DATABASE MOUNT

Thu Jul 22 12:44:40 2010

Setting recovery target incarnation to 10

Thu Jul 22 12:44:40 2010

Successful mount of redo thread 1, with mount id 1252833332

Thu Jul 22 12:44:40 2010

Database mounted in Exclusive Mode

Completed: ALTER DATABASE MOUNT

Thu Jul 22 12:44:41 2010

ALTER DATABASE OPEN

Thu Jul 22 12:44:41 2010

Beginning crash recovery of 1 threads --開始crash recovery

Thu Jul 22 12:44:41 2010

Started redo scan --掃描redo

Thu Jul 22 12:44:42 2010

Completed redo scan

142 redo blocks read, 58 data blocks need recovery

Thu Jul 22 12:44:42 2010

Started redo application at

Thread 1: logseq 4, block 3156

Thu Jul 22 12:44:42 2010

Recovery of Online Redo Log: Thread 1 Group 3 Seq 4 Reading mem 0

Mem# 0 errs 0: /u01/app/oracle/oradata/orcl/redo3a.rdo

Mem# 1 errs 0: /u01/app/oracle/oradata/orcl/redo3b.rdo

Thu Jul 22 12:44:42 2010

Completed redo application

Thu Jul 22 12:44:43 2010

Completed crash recovery at --完成恢複

Thread 1: logseq 4, block 3298, scn 2921577

58 data blocks read, 58 data blocks written, 142 redo blocks read

Thu Jul 22 12:44:43 2010

LGWR: STARTING ARCH PROCESSES

ARC0: Archival started

ARC1: Archival started

LGWR: STARTING ARCH PROCESSES COMPLETE

ARC1 started with pid=17, OS id=4018

ARC0 started with pid=16, OS id=4016

Thu Jul 22 12:44:45 2010

Thread 1 advanced to log sequence 5

Thread 1 opened at log sequence 5

Current log# 1 seq# 5 mem# 0: /u01/app/oracle/oradata/orcl/redo1a.rdo

Current log# 1 seq# 5 mem# 1: /u01/app/oracle/oradata/orcl/redo1b.rdo

Successful open of redo thread 1

Thu Jul 22 12:44:45 2010

MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set --FAST_START_MTTR_TARGET未設定

--------------------------------------------------------------------------------------------------

--對scott使用者已提交，故恢複之後為已提交的狀態

SQL> SELECT * FROM scott.emp WHERE ename = 'SCOTT';

EMPNO ENAME JOB MGR HIREDATE SAL DEPTNO

---------- ------------------------------ --------- ---------- --------- ---------- ----------

7788 SCOTT ANALYST 7566 19-APR-87 3550 20

--新增加的兩條記錄未提交，執行個體恢複之後被復原

SQL> SELECT * FROM scott.emp WHERE empno IN (2001,2002);

no rows selected

八、設定FAST_START_MTTR_TARGET參數

/*

FAST_START_MTTR_TARGET參數的作用就是減少cache recovery的恢復。

當設定了FAST_START_MTTR_TARGET值後，資料庫管理增量檢查點寫入嘗試達到設定的目標恢復

如果設定的值合理，則整個恢複過程將接近所設定的時間

註：當使用FAST_START_MTTR_TARGET參數時，應當關閉FAST_START_IO_TARGET, LOG_CHECKPOINT_INTERVAL,

LOG_CHECKPOINT_TIMEOUT 參數。如果設定這些參數將會妨礙cache recovery滿足指定的FAST_START_MTTR_TARGET值

應當為FAST_START_MTTR_TARGET設定合理的時間值

預設值為0,表示關閉檢查點自動調整功能

最大值為3600,當設定值大於3600,將被自動取整為3600

最小值為1,當設定為時1，事實上不切合實際因此，恢復也不能達到設定的目標值 */

--將fast_start_mttr_target的值置為0

SQL> alter system set fast_start_mttr_target = 0;

System altered.

SQL> CREATE TABLE tb_test AS SELECT * FROM all_objects WHERE 1=2; --建立一張表

Table created.

SQL> INSERT INTO tb_test SELECT * FROM all_objects; --插入記錄到新表

49945 rows created.

--下面的查詢中可以看到ESTIMATED_MTTR為28

SQL> SELECT recovery_estimated_ios,actual_redo_blks,target_mttr,estimated_mttr,

2 optimal_logfile_size FROM v$instance_recovery;

RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE

---------------------- ---------------- ----------- -------------- --------------------

762 11661 0 28

SQL> COMMIT; --提交事務

Commit complete.

SQL> SELECT recovery_estimated_ios,actual_redo_blks,target_mttr,estimated_mttr,

2 optimal_logfile_size FROM v$instance_recovery;

RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE

---------------------- ---------------- ----------- -------------- --------------------

767 11669 0 28

--由上可知，commit僅僅是將日誌緩衝區的內容更新到記錄檔

SQL> ALTER SYSTEM CHECKPOINT; --手動更新檢查點

System altered.

SQL> SELECT recovery_estimated_ios,actual_redo_blks,target_mttr,estimated_mttr,

2 optimal_logfile_size FROM v$instance_recovery;

RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE

---------------------- ---------------- ----------- -------------- --------------------

0 0 0 28

--上面的查詢可以看到欄位RECOVERY_ESTIMATED_IOS和ACTUAL_REDO_BLKS 的值已經減少到0

--檢查點的產生將database buffer中的髒內容寫入到了資料檔案中

--ESTIMATED_MTTR沒有發生變化，因為該列為非即時更新列

oracle視頻教程請關注:http://u.youku.com/user_video/id_UMzAzMjkxMjE2.html