[20200309]資料庫異常關閉恢復的終點.txt
[20200309]資料庫異常關閉恢復的終點.txt
--//在連結:http://blog.itpub.net/267265/viewspace-2638170/=>[20190312]關於增量檢查點的疑問(補充).txt
--//我在裡面提到資料庫異常關閉恢復的起點是low_rba到on_disk_rba作為恢復終點.
--//實際上可能更新這些資訊可能慢於寫入日誌,這樣可能出現恢復終點大於on_disk_rba的情況.特別是生產系統出現異常關閉的情況
--//透過例子驗證:
1.環境:
SYS@book> @ ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
2.測試:
--//以sys使用者執行:
$ cat ac.txt
@check.sql
create table scott.t tablespace users as select * from all_objects;
shutdown abort
SYS@book> @ ac.txt
檢查點佇列
當前時間 髒塊數量
low_rba on_disk_rba on_disk_rba_scn( on_disk_rba_time(CP full checkpoint_rba full_checkpoint( full_checkpoint_tim diff_scn(on_disk_rdb-ch_scn) current_group SYSDATE CPDRT
-------------------- -------------------- ---------------- ------------------- --------------------- ---------------- ------------------- ---------------------------- ------------- ------------------- ------------
822.802.0 822.904.0 13277803650 2020-03-09 09:39:23 822.801.16 13277803347 2020-03-09 09:39:11 303 2 2020-03-09 09:39:26 32
Table created.
ORACLE instance shut down.
3.測試:
SYS@book> startup mount;
ORACLE instance started.
Total System Global Area 643084288 bytes
Fixed Size 2255872 bytes
Variable Size 205521920 bytes
Database Buffers 427819008 bytes
Redo Buffers 7487488 bytes
Database mounted.
SYS@book> @ check
檢查點佇列
當前時間 髒塊數量
low_rba on_disk_rba on_disk_rba_scn( on_disk_rba_time(CP full checkpoint_rba full_checkpoint( full_checkpoint_tim diff_scn(on_disk_rdb-ch_scn) current_group SYSDATE CPDRT
-------------------- -------------------- ---------------- ------------------- --------------------- ---------------- ------------------- ---------------------------- ------------- ------------------- ------------
822.802.0 822.904.0 13277803650 2020-03-09 09:39:23 822.801.16 13277803347 2020-03-09 09:39:11 303 2 2020-03-09 09:40:05 32
--//on_disk_rba=822.904.0.明顯不可能，因為我在關閉前建立表t在users表空間裡面。
SYS@book> alter database open ;
Database altered.
SYS@book> @ check
檢查點佇列
當前時間 髒塊數量
low_rba on_disk_rba on_disk_rba_scn( on_disk_rba_time(CP full checkpoint_rba full_checkpoint( full_checkpoint_tim diff_scn(on_disk_rdb-ch_scn) current_group SYSDATE CPDRT
-------------------- -------------------- ---------------- ------------------- --------------------- ---------------- ------------------- ---------------------------- ------------- ------------------- ------------
823.3.0 823.123.0 13277823928 2020-03-09 09:41:02 823.2.16 13277823734 2020-03-09 09:41:01 194 3 2020-03-09 09:41:05 41
--//檢查alert*.log:
[2020-03-09 09:41:00] Mon Mar 09 09:41:00 2020
[2020-03-09 09:41:00] alter database open
[2020-03-09 09:41:00] Beginning crash recovery of 1 threads
[2020-03-09 09:41:01] parallel recovery started with 23 processes
[2020-03-09 09:41:01] Started redo scan
[2020-03-09 09:41:01] Completed redo scan
[2020-03-09 09:41:01] read 10237 KB redo, 90 data blocks need recovery
[2020-03-09 09:41:01] Started redo application at
[2020-03-09 09:41:01] Thread 1: logseq 822, block 802
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--//等於low_rba=822.802.0.恢復起點。
[2020-03-09 09:41:01] Recovery of Online Redo Log: Thread 1 Group 2 Seq 822 Reading mem 0
[2020-03-09 09:41:01] Mem# 0: /mnt/ramdisk/book/redo02.log
[2020-03-09 09:41:01] Completed redo application of 0.12MB
[2020-03-09 09:41:01] Completed crash recovery at
[2020-03-09 09:41:01] Thread 1: logseq 822, block 21276, scn 13277823731
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[2020-03-09 09:41:01] 90 data blocks read, 90 data blocks written, 10237 redo k-bytes read
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--// 21276-802 = 20474,20474*512/1024 = 10237 K。
--//可以發現恢復到 822.21276.0. 也就是恢復儘可能的讀取日誌，直到不能讀為止。而不是到on_disk_rba=822.904.0結束。
[2020-03-09 09:41:01] Mon Mar 09 09:41:00 2020
[2020-03-09 09:41:01] LGWR: STARTING ARCH PROCESSES
[2020-03-09 09:41:01] Mon Mar 09 09:41:00 2020
[2020-03-09 09:41:01] ARC0 started with pid=45, OS id=2352
[2020-03-09 09:41:02] ARC0: Archival started
[2020-03-09 09:41:02] LGWR: STARTING ARCH PROCESSES COMPLETE
[2020-03-09 09:41:02] ARC0: STARTING ARCH PROCESSES
[2020-03-09 09:41:02] Thread 1 advanced to log sequence 823 (thread open)
[2020-03-09 09:41:02] Thread 1 opened at log sequence 823
--//切換使用新的日誌seq=823，oracle這樣做的好處是避免可能的日誌覆蓋情況。
[2020-03-09 09:41:02] Current log# 3 seq# 823 mem# 0: /mnt/ramdisk/book/redo03.log
[2020-03-09 09:41:02] Successful open of redo thread 1
[2020-03-09 09:41:02] MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
[2020-03-09 09:41:02] Mon Mar 09 09:41:01 2020
[2020-03-09 09:41:02] SMON: enabling cache recovery
[2020-03-09 09:41:02] Mon Mar 09 09:41:01 2020
[2020-03-09 09:41:02] ARC1 started with pid=46, OS id=2354
[2020-03-09 09:41:02] [2304] Successfully onlined Undo Tablespace 2.
[2020-03-09 09:41:02] Undo initialization finished serial:0 start:2332169638 end:2332169688 diff:50 (0 seconds)
[2020-03-09 09:41:02] Verifying file header compatibility for 11g tablespace encryption..
[2020-03-09 09:41:02] Verifying 11g file header compatibility for tablespace encryption completed
[2020-03-09 09:41:02] SMON: enabling tx recovery
[2020-03-09 09:41:02] Database Characterset is ZHS16GBK
[2020-03-09 09:41:02] No Resource Manager plan active
[2020-03-09 09:41:02] replication_dependency_tracking turned off (no async multimaster replication found)
[2020-03-09 09:41:02] WARNING: AQ_TM_PROCESSES is set to 0. System operation might be adversely affected.
[2020-03-09 09:41:03] Completed: alter database open
[2020-03-09 09:41:03] Mon Mar 09 09:41:02 2020
[2020-03-09 09:41:03] db_recovery_file_dest_size of 61440 MB is 0.00% used. This is a
[2020-03-09 09:41:03] user-specified limit on the amount of space that will be used by this
[2020-03-09 09:41:03] database for recovery-related files, and does not reflect the amount of
[2020-03-09 09:41:03] space available in the underlying filesystem or ASM diskgroup.
[2020-03-09 09:41:03] Mon Mar 09 09:41:02 2020
[2020-03-09 09:41:03] Starting background process CJQ0
[2020-03-09 09:41:03] Mon Mar 09 09:41:02 2020
[2020-03-09 09:41:03] CJQ0 started with pid=48, OS id=2370
[2020-03-09 09:41:03] ARC1: Archival started
[2020-03-09 09:41:03] ARC0: STARTING ARCH PROCESSES COMPLETE
[2020-03-09 09:41:03] ARC0: Becoming the 'no FAL' ARCH
[2020-03-09 09:41:03] ARC0: Becoming the 'no SRL' ARCH
[2020-03-09 09:41:03] ARC1: Becoming the heartbeat ARCH
[2020-03-09 09:41:04] Archived Log entry 1487 added for thread 1 sequence 822 ID 0x4fb7d86e dest 1:
[2020-03-09 09:41:04] Mon Mar 09 09:41:03 2020
[2020-03-09 09:41:04] Incremental checkpoint up to RBA [0x337.3.0], current log tail at RBA [0x337.7b.0]
--// 0x7b = 123
SYS@book> select count(*) from scott.t;
COUNT(*)
------------
85032
SYS@book> select count(*) from all_objects;
COUNT(*)
------------
85032
--//可以發現建立的表T存在。
4.總結：
--//資料庫異常關閉恢復的起點是low_rba，終點至少到on_disk_rba,特別在生產系統完成可能超過on_disk_rba，oracle儘量的讀取滿足需求的日誌，
--//日誌檔案裡面記錄seq號。最後都是切換使用新的日誌。
--//大家可以對比http://blog.itpub.net/267265/viewspace-2638170/的測試。
5.指令碼check.sql:
$ cat check.sql
column "full checkpoint_rba" format a21
column low_rba format a20
column low_rba16 format a20
column on_disk_rba format a20
column on_disk_rba16 format a20
column rtckp_rba format a20
column diff_date format 9999999.99
rem column CPOSD_ono_disk_rba_scn format 99999999999999999999999999999999
column cpdrt heading "檢查點佇列|髒塊數量|CPDRT"
column cpodt_on_disk_rba heading "檢查點佇列|on disk rba|時間戳|CPODT"
column cpods heading "檢查點佇列|on disk rba scn|CPODS"
column cphbt heading "檢查點心跳|CPHBT"
column current_sysdate heading "當前時間|SYSDATE"
set num 12
SELECT b.cplrba_seq || '.' || b.cplrba_bno || '.' || b.cplrba_bof "low_rba"
,b.cpodr_seq || '.' || b.cpodr_bno || '.' || b.cpodr_bof "on_disk_rba"
,b.CPODS "on_disk_rba_scn(CPODS)"
,TO_DATE (b.CPODT, 'MM-DD-YYYY HH24:MI:SS') "on_disk_rba_time(CPODT)"
,a.rtckp_rba_seq || '.' || a.rtckp_rba_bno || '.' || a.rtckp_rba_bof
"full checkpoint_rba"
,a.rtckp_scn "full_checkpoint(rtckp_scn)"
,TO_DATE (a.rtckp_tim, 'MM-DD-YYYY HH24:MI:SS')
"full_checkpoint_time_rtckp_tim"
,b.CPODS - a.rtckp_scn "diff_scn(on_disk_rdb-ch_scn)"
,a.rtcln "current_group"
,sysdate current_sysdate
,CPDRT
FROM x$kccrt a, x$kcccp b
WHERE a.rtnum = b.cptno AND A.INST_ID = b.inst_id;
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/267265/viewspace-2679116/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 恢復之資料庫關閉時的完全恢復資料庫
- 關閉資料庫的備份與恢復資料庫
- [20210722]資料庫異常關閉的處理.txt資料庫
- SCN異常增長導致資料庫異常關閉風險的防範資料庫
- 【北亞資料恢復】異常斷電導致Oracle資料庫報錯的oracle資料恢復資料恢復Oracle資料庫
- Oracle資料庫終極恢復Oracle資料庫
- Oracle異地資料庫恢復Oracle資料庫
- Backup And Recovery User's Guide-執行完全資料庫恢復-執行關閉的資料庫的恢復GUIIDE資料庫
- RAC資料庫的RMAN備份異機恢復到單節點資料庫資料庫
- 資料庫常規恢復案例資料庫
- Oracle 資料庫不一致導致異常的恢復Oracle資料庫
- 資料庫異機冷備恢復資料庫
- 恢復之非歸檔模式下資料庫非正常關閉的備份與恢復模式資料庫
- dataguard利用從庫的檔案恢復主庫發生異常的資料檔案。
- 資料庫資料恢復-ORACLE資料庫的常見故障&各種故障下的資料恢復可能性資料庫資料恢復Oracle
- 【資料庫資料恢復】ORACLE常見資料災難&資料恢復可能性資料庫資料恢復Oracle
- MySQL異常恢復之無主鍵情況下innodb資料恢復的方法MySql資料恢復
- Oracle資料庫冷備份的異地恢復Oracle資料庫
- SCN與資料庫恢復的關係資料庫
- 【北亞資料恢復】異常斷電導致linux伺服器無法啟動，資料庫損壞的資料恢復資料恢復Linux伺服器資料庫
- RMAN資料庫恢復異常報錯ORA-01180資料庫
- 【資料庫資料恢復】SAP資料庫資料恢復案例資料庫資料恢復
- 【資料庫資料恢復】透過恢復NDF檔案修復資料庫的資料恢復過程資料庫資料恢復
- 【vSAN資料恢復案例】異常斷電導致vSAN底層資料損壞的資料恢復資料恢復
- 【硬碟資料恢復】加電有異響的硬碟資料恢復硬碟資料恢復
- 寶塔資料庫恢復 mysql資料庫丟失恢復 mysql資料庫刪除庫恢復 寶塔mysql資料庫恢復資料庫MySql
- 【資料庫資料恢復】如何恢復Oracle資料庫truncate表的資料資料庫資料恢復Oracle
- 【資料庫資料恢復】windows server下SqlServer資料庫的資料恢復資料庫資料恢復WindowsServerSQL
- oracle資料庫正常關閉狀態下丟失undo檔案的恢復Oracle資料庫
- 【資料庫資料恢復】Sql Server資料庫資料恢復案例資料庫資料恢復SQLServer
- SQL Server資料庫恢復常見問題SQLServer資料庫
- 資料庫常見故障及恢復原理(轉)資料庫
- 【資料庫資料恢復】Oracle資料庫誤truncate table的資料恢復案例資料庫資料恢復Oracle
- 【資料庫資料恢復】誤truncate table的Oracle資料庫資料恢復方案資料庫資料恢復Oracle
- 伺服器資料恢復—供電電壓不穩導致伺服器異常關機且資料丟失的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】xen server儲存庫(sr)常見故障的資料恢復方案伺服器資料恢復Server
- 伺服器資料恢復—透過拼接資料庫碎片恢復SqlServer資料庫資料的資料恢復案例伺服器資料恢復資料庫SQLServer
- DG同步異常恢復文件