[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資料庫
- 【北亞資料恢復】異常斷電導致Oracle資料庫報錯的oracle資料恢復資料恢復Oracle資料庫
- RMAN資料庫恢復異常報錯ORA-01180資料庫
- 資料庫資料恢復-ORACLE資料庫的常見故障&各種故障下的資料恢復可能性資料庫資料恢復Oracle
- 【vSAN資料恢復案例】異常斷電導致vSAN底層資料損壞的資料恢復資料恢復
- 【北亞資料恢復】異常斷電導致linux伺服器無法啟動，資料庫損壞的資料恢復資料恢復Linux伺服器資料庫
- 【資料庫資料恢復】ORACLE常見資料災難&資料恢復可能性資料庫資料恢復Oracle
- MySQL異常恢復之無主鍵情況下innodb資料恢復的方法MySql資料恢復
- 【資料庫資料恢復】SAP資料庫資料恢復案例資料庫資料恢復
- 【資料庫資料恢復】透過恢復NDF檔案修復資料庫的資料恢復過程資料庫資料恢復
- 寶塔資料庫恢復 mysql資料庫丟失恢復 mysql資料庫刪除庫恢復 寶塔mysql資料庫恢復資料庫MySql
- 【資料庫資料恢復】windows server下SqlServer資料庫的資料恢復資料庫資料恢復WindowsServerSQL
- 【資料庫資料恢復】如何恢復Oracle資料庫truncate表的資料資料庫資料恢復Oracle
- 【硬碟資料恢復】加電有異響的硬碟資料恢復硬碟資料恢復
- 【資料庫資料恢復】Sql Server資料庫資料恢復案例資料庫資料恢復SQLServer
- 【資料庫資料恢復】Oracle資料庫誤truncate table的資料恢復案例資料庫資料恢復Oracle
- 【資料庫資料恢復】誤truncate table的Oracle資料庫資料恢復方案資料庫資料恢復Oracle
- 備份與恢復：Polardb資料庫資料基於時間點恢復資料庫
- SQL Server資料庫恢復常見問題SQLServer資料庫
- 伺服器資料恢復—透過拼接資料庫碎片恢復SqlServer資料庫資料的資料恢復案例伺服器資料恢復資料庫SQLServer
- 【伺服器資料恢復】xen server儲存庫(sr)常見故障的資料恢復方案伺服器資料恢復Server
- 【PARANETERS】Oracle異常恢復相關的隱含引數Oracle
- 伺服器資料恢復—供電電壓不穩導致伺服器異常關機且資料丟失的資料恢復案例伺服器資料恢復
- 資料庫修復資料恢復資料庫資料恢復
- 【資料庫資料恢復】sql server資料庫連線失效的資料恢復案例資料庫資料恢復SQLServer
- 【資料庫資料恢復】SqlServer資料庫無法讀取的資料恢復案例資料庫資料恢復SQLServer
- 【資料庫資料恢復】MongoDB資料庫檔案損壞的資料恢復案例資料庫資料恢復MongoDB
- MySQL資料庫的恢復MySql資料庫
- SQLServer異常故障恢復(二)SQLServer
- DG同步異常恢復文件
- 資料庫資料恢復—附加資料庫錯誤823的SQL Server資料恢復案例資料庫資料恢復SQLServer
- 【資料庫資料恢復】SQL Server資料庫磁碟空間不足的資料恢復案例資料庫資料恢復SQLServer
- 【資料庫資料恢復】ASM磁碟組掉線的Oracle資料庫資料恢復案例資料庫資料恢復ASMOracle
- [20210930]bbed恢復刪除的資料.txt
- 【伺服器資料恢復】異常斷電導致ESXI無法連線儲存的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】多次異常斷電後儲存執行中突然崩潰的資料恢復伺服器資料恢復
- DG修復：異常關庫導致的資料庫啟動失敗ORA-01110及GAP修復資料庫
- 【資料庫資料恢復】透過資料頁恢復Sql Server資料庫資料的過程資料庫資料恢復SQLServer