Oracle體系結構之SCN、實例恢復

時間 2019-12-19

標籤 oracle 體系結構 scn 實例恢復欄目 Oracle 简体版

原文原文鏈接

SCN：System Change Numbersql

SCN是Oracle數據庫的一個邏輯的內部時間戳，用以標識數據庫在某個確切時刻提交的版本。在事務提交或回滾時，它被賦予一個唯一的標識事務的SCN，用來保證數據庫的一致性。數據庫

SQL> select dbms_flashback.get_system_change_number, SCN_TO_TIMESTAMP(dbms_flashback.get_system_change_number) from dual;
GET_SYSTEM_CHANGE_NUMBER SCN_TO_TIMESTAMP(DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER)
------------------------ -------------------------------------------------------
                 1819076 06-JUL-13 11.40.12.000000000 PM
SQL>select  current_scn from v$database;
CURRENT_SCN
-----------
    1819065

SCN在數據庫中是無處不在的，常見的控制文件、數據文件頭部、日誌文件等都記錄有SCN。緩存

控制文件中oracle

系統檢查點SCN(System Checkpoint SCN)app

SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
           1809219

文件檢查點SCN(Datafile Checkpoint SCN)
async
文件結束SCN(Stop SCN)ide

SQL> select name,checkpoint_change#,last_change# from v$datafile;
NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#
--------------------------------------------- ------------------ ------------
+DATA/orcl/datafile/system.256.817343229                 1809219
+DATA/orcl/datafile/sysaux.257.817343231                 1809219
+DATA/orcl/datafile/undotbs1.258.817343231               1809219
+DATA/orcl/datafile/users.259.817343231                  1809219
+DATA/orcl/datafile/example.265.817343543                1809219

數據文件頭部spa

開始SCN(Start SCN)指針

SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
           1809219
           1809219
           1809219
           1809219
           1809219

日誌文件中日誌

FIRST SCN：redo log file中第一條日誌的SCN
NEXT SCN：redo log file中最後一條日誌的SCN(即下一個redo log file的第一條日誌的SCN)

一般,只有當前的重作日誌文件組寫滿後才發生日誌切換,可是能夠經過設置參數ARCHIVE_LOG_TARGET控制日誌切換的時間間隔,在必要時也能夠採用手工強制進行日誌切換.

一組redo log file寫滿後，會自動切換到下一組redo log file。上一組redo log的High SCN就是下一組redo log的Low SCN,且對於Current日誌文件的High SCN爲無窮大(FFFFFFFF)。

SQL> select group#,sequence#,status,first_change#,next_change# from v$log;
    GROUP#  SEQUENCE# STATUS           FIRST_CHANGE#       NEXT_CHANGE#
---------- ---------- ---------------- ------------- ------------------
         1         34 INACTIVE               1746572            1770739
         2         35 INACTIVE               1770739            1808596
         3         36 CURRENT                1808596    281474976710655

實例崩潰恢復：

在open數據庫時,Oracle經過控制文件進行了如下驗證：

檢查數據文件頭部所記錄的Start SCN 和控制文件中所記錄的System Checkpoint SCN 是否一致,若不一樣則須要進行介質恢復
檢查數據文件頭部所記錄的Start SCN 和控制文件中記錄的Stop SCN是否也一致,若不一樣則須要進行實例恢復.

若是兩個都一致了,說明全部已被修改的數據塊已經寫入到了數據文件中,才能夠正常open,

當數據庫open並正常運行期間,系統SCN、文件SCN和數據文件頭部的開始SCN都是一致的,且(大於或)等於ACTIVE/CURRENT日誌文件的最小FIRST SCN,但文件結束SCN爲NULL(無窮大);

當數據庫正常關閉時,Oracle經過徹底檢查點將buffer cache中的全部緩存寫到磁盤上,同時根據關閉數據庫的時間點更新控制文件中的系統SCN、文件SCN、結束SCN和數據文件頭部中的開始SCN,且SCN都是一致的,且LRBA指針指向on disk RBA,不然須要前滾;

當數據庫非正常關閉(崩潰/掉電)後啓動實例時,Oracle將檢測到控制文件中的系統SCN、文件SCN和數據文件頭部的開始SCN都是一致的,可是結束SCN爲NULL,則在須要參與實例崩潰恢復的redo log file中根據控制文件中記錄的LRBA地址(前滾起點)和on disk RBA(前滾終點)地址找出相應的日誌項進行實例崩潰恢復,最終纔可將數據庫open.

實例恢復的詳細過程：

前滾階段(前滾靠redo,又叫緩衝區恢復cache recovery,即負責恢復已經在內存中但尚未寫入數據文件中的內容)

Oracle是按照redo log file的記錄來前滾的(無論有沒有commit),因此前滾完成後,data file中可能會有沒有提交的數據(因此須要後面的回退過程).

另外,因爲undo的生成也是要記錄redo log的,因此還會按照redo從新生成後面回退時須要的undo信息.

數據庫open階段

前滾完畢後,數據庫中全部已被修改的數據塊已經寫入到了數據文件中才能夠正常open

回滾階段(回滾靠undo,又叫事務恢復transaction recoery,即負責回退實例崩潰前沒有提交的事務)

正常關閉數據庫時：

系統SCN、文件SCN、結束SCN和數據文件頭部中的開始SCN都是相等的，且(大於或)等於ACTIVE/CURRENT日誌文件中的最小FIRST SCN

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area  459304960 bytes
Fixed Size                  2214336 bytes
Variable Size             289408576 bytes
Database Buffers          159383552 bytes
Redo Buffers                8298496 bytes
Database mounted.
SQL>  select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
           1822573
SQL>  select name,checkpoint_change#,last_change# from v$datafile;
NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#
--------------------------------------------- ------------------ ------------
+DATA/orcl/datafile/system.256.817343229                 1822573      1822573
+DATA/orcl/datafile/sysaux.257.817343231                 1822573      1822573
+DATA/orcl/datafile/undotbs1.258.817343231               1822573      1822573
+DATA/orcl/datafile/users.259.817343231                  1822573      1822573
+DATA/orcl/datafile/example.265.817343543                1822573      1822573
SQL> select name,checkpoint_change# from v$datafile_header;
NAME                                          CHECKPOINT_CHANGE#
--------------------------------------------- ------------------
+DATA/orcl/datafile/system.256.817343229                 1822573
+DATA/orcl/datafile/sysaux.257.817343231                 1822573
+DATA/orcl/datafile/undotbs1.258.817343231               1822573
+DATA/orcl/datafile/users.259.817343231                  1822573
+DATA/orcl/datafile/example.265.817343543                1822573
SQL> select group#,sequence#,status,first_change#,next_change# from v$log;
    GROUP#  SEQUENCE# STATUS           FIRST_CHANGE#       NEXT_CHANGE#
---------- ---------- ---------------- ------------- ------------------
         1         37 CURRENT                1822207    281474976710655
         3         36 INACTIVE               1808596            1822207
         2         35 INACTIVE               1770739            1808596

正常open數據庫時：

文件結束SCN爲NULL(無窮大)

SQL> alter database open;
Database altered.
SQL> select name,checkpoint_change#,last_change# from v$datafile;
NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#
--------------------------------------------- ------------------ ------------
+DATA/orcl/datafile/system.256.817343229                 1822576
+DATA/orcl/datafile/sysaux.257.817343231                 1822576
+DATA/orcl/datafile/undotbs1.258.817343231               1822576
+DATA/orcl/datafile/users.259.817343231                  1822576
+DATA/orcl/datafile/example.265.817343543                1822576

異常關機（實例崩潰）時：

文件結束SCN仍爲NULL(無窮大)

SQL> shutdown abort
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area  459304960 bytes
Fixed Size                  2214336 bytes
Variable Size             289408576 bytes
Database Buffers          159383552 bytes
Redo Buffers                8298496 bytes
Database mounted.
SQL> select name,checkpoint_change#,last_change# from v$datafile;
NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#
--------------------------------------------- ------------------ ------------
+DATA/orcl/datafile/system.256.817343229                 1822576
+DATA/orcl/datafile/sysaux.257.817343231                 1822576
+DATA/orcl/datafile/undotbs1.258.817343231               1822576
+DATA/orcl/datafile/users.259.817343231                  1822576
+DATA/orcl/datafile/example.265.817343543                1822576

啓動實例將進行實例恢復：

SQL> alter database open;
Database altered.
$ tailf /u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log
Sun Jul 07 00:10:07 2013
alter database open
Beginning crash recovery of 1 threads
 parallel recovery started with 3 processes
Started redo scan
Completed redo scan
 read 192 KB redo, 87 data blocks need recovery
Started redo application at
 Thread 1: logseq 37, block 533
Recovery of Online Redo Log: Thread 1 Group 1 Seq 37 Reading mem 0
  Mem# 0: +DATA/orcl/onlinelog/group_1.261.817343457
  Mem# 1: +FRA/orcl/onlinelog/group_1.257.817343463
Completed redo application of 0.15MB
Completed crash recovery at
 Thread 1: logseq 37, block 918, scn 1843004
 87 data blocks read, 87 data blocks written, 192 redo k-bytes read
Sun Jul 07 00:10:13 2013
Thread 1 advanced to log sequence 38 (thread open)
Thread 1 opened at log sequence 38
  Current log# 2 seq# 38 mem# 0: +DATA/orcl/onlinelog/group_2.262.817343467
  Current log# 2 seq# 38 mem# 1: +FRA/orcl/onlinelog/group_2.258.817343473
Successful open of redo thread 1
Sun Jul 07 00:10:14 2013
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
Sun Jul 07 00:10:17 2013
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Sun Jul 07 00:10:21 2013
QMNC started with pid=28, OS id=7140
Sun Jul 07 00:10:31 2013
Completed: alter database open

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。