某数据库主机突然掉电，重启数据库库后进行实例恢复，没想到这个恢复一直进行了近一个小时，唉，当时真有shutdown abort重来的冲动了，幸好没做！真是想不明白，oracle的前滚要做这么长的时间！
50分钟的内，做了38384 data blocks的recovery，按照8k一个db block，大约也就是300M左右的数据做恢复。不过竟然等了50分钟，这个时间确实有点长了。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
ALTER DATABASE MOUNT Thu Jul 17 23:40:34 2008 Successful mount of redo thread 1, with mount id 2819316398 Thu Jul 17 23:40:34 2008 Database mounted in Exclusive Mode. Completed: ALTER DATABASE MOUNT Thu Jul 17 23:40:35 2008 ALTER DATABASE OPEN Thu Jul 17 23:53:00 2008 Beginning crash recovery of 1 threads Thu Jul 17 23:54:12 2008 Started redo scan Thu Jul 17 23:55:00 2008 Completed redo scan 96595 redo blocks read, 38384 data blocks need recovery --------- 这边，等待了近50分钟 ----------------------------- Fri Jul 18 00:41:59 2008 Started recovery at Thread 1: logseq 54295, block 335001, scn 0.0 Fri Jul 18 00:41:59 2008 Recovery of Online Redo Log: Thread 1 Group 3 Seq 54295 Reading mem 0 Mem# 0 errs 0: /dev/vg_ora1/rredo31 Mem# 1 errs 0: /dev/vg_ora2/rredo32 Fri Jul 18 00:44:23 2008 Completed redo application ---- 这边，也等了近10分钟 ------------------------ Fri Jul 18 00:56:50 2008 Ended recovery at Thread 1: logseq 54295, block 431596, scn 4.3244460870 38384 data blocks read, 38384 data blocks written, 96595 redo blocks read Crash recovery completed successfully Fri Jul 18 00:56:56 2008 LGWR: Primary database is in CLUSTER CONSISTENT mode FAST_START_MTTR_TARGET 300 is out of the valid MTTR range, use 394 instead. Thread 1 advanced to log sequence 54296 Thread 1 opened at log sequence 54296 Current log# 1 seq# 54296 mem# 0: /dev/vg_ora1/rredo11 Current log# 1 seq# 54296 mem# 1: /dev/vg_ora2/rredo12 Successful open of redo thread 1 Fri Jul 18 00:56:57 2008 SMON: enabling cache recovery Fri Jul 18 00:56:57 2008 ARC0: Evaluating archive log 3 thread 1 sequence 54295 ARC0: Beginning to archive log 3 thread 1 sequence 54295 Creating archive destination LOG_ARCHIVE_DEST_1: '/arch/hnmisc_1_54295.arc' Fri Jul 18 00:56:57 2008 Successfully onlined Undo Tablespace 51. Fri Jul 18 00:56:57 2008 SMON: enabling tx recovery Fri Jul 18 00:56:57 2008 Database Characterset is ZHS16GBK replication_dependency_tracking turned off (no async multimaster replication found) Completed: ALTER DATABASE OPEN |
另外，这边再提一下redo log的计算：
每个redo block的大小：
|
1 2 3 4 5 |
SQL> select max(lebsz) from x$kccle; MAX(LEBSZ) ---------- 1024 |
96595 redo blocks read，即在做前滚的时候，96595×1024/1024=96595 KB的redo被读取了。