关于写丢失导致的ORA-00742问题分析
本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客
本文链接地址: 关于写丢失导致的ORA-00742问题分析
近期某客户环境不定期出现写丢失报错,到账数据库无法进行归档。
1 2 3 4 5 6 |
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=3, mask=0x0) ----- Error Stack Dump ----- ORA-00742: Log read detects lost write in thread %d sequence %d block %d ORA-00312: online log 4 thread 2: '+DATA/xxxxxx/onlinelog/group_4.695.1127508625' ----- SQL Statement (None) ----- Current SQL information unavailable - no cursor. |
类似上述错误,Oracle在进行归档时发现redo log有写丢失的情况,即数据不一致(会进行校验),则抛出上诉错误。
ORA-00742错误不太好模拟,这里简单模拟一下ORA-00312.
首先创建测试表,并进行相关update操作,在进行update的同时,通过strace lgwr进程定位相关偏移量。
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 |
SQL> select a.object_id,dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) blk# from test0413 2 a; OBJECT_ID FILE# BLK# ---------- ---------- ---------- 2 1 133065 3 1 133065 4 1 133065 5 1 133065 6 1 133065 7 1 133065 8 1 133065 9 1 133065 8 rows selected. SQL> update test0413 set object_name='lizhenxu' where object_id=6; 1 row updated. SQL> commit; Commit complete. SQL> select dump('lizhenxu',16) from dual; DUMP('LIZHENXU',16) -------------------------------------------------------------------------- Typ=96 Len=8: 6c,69,7a,68,65,6e,78,75 GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARCHIV STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME ---------- ---------- ---------- ---------- ---------- ---------- ------ -------------------------------- ------------- ------------------- ------------ ------------------- 1 1 196 52428800 512 1 YES INACTIVE 6794486 2023-04-14 16:37:16 6794585 2023-04-14 16:38:44 2 1 197 52428800 512 1 NO CURRENT 6794585 2023-04-14 16:38:44 2.8147E+14 3 1 195 52428800 512 1 YES INACTIVE 6791372 2023-04-14 16:00:15 6794486 2023-04-14 16:37:16 SQL> |
接下来我们看下lgwr trace的相关情况:
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 |
[root@Ora11g-ogg-Target ~]# strace -fr -o /tmp/30734.log -p 30734 strace: Process 30734 attached ^Cstrace: Process 30734 detached [root@Ora11g-ogg-Target ~]# [root@Ora11g-ogg-Target ~]# more /tmp/30734.log |grep 'write' 30734 0.000171 pwrite64(259, "\1\"\0\0\314\22\0\0\305\0\0\0\20\200\370\254\354\2\0\0\5\0\0\0006\276g\0\1\0ef"..., 1024, 2463744) = 1024 30734 0.000122 pwrite64(259, "\1\"\0\0\316\22\0\0\305\0\0\0\20\200\214[h\2\0\0\5A\0\0008\276g\0\1\0N\2"..., 1024, 2464768) = 1024 30734 0.000055 pwrite64(259, "\1\"\0\0\320\22\0\0\305\0\0\0\20\200\247Up\0\0\0\6N\0\0:\276g\0\1\0\30\f"..., 512, 2465792) = 512 30734 0.000061 pwrite64(259, "\1\"\0\0\321\22\0\0\305\0\0\0\20\200i\211\364\2\0\0\5J\0\0=\276g\0\1\0xp"..., 1024, 2466304) = 1024 30734 0.000094 pwrite64(259, "\1\"\0\0\323\22\0\0\305\0\0\0\20\200\256Np\2\0\0\5V\0\0?\276g\0\1\0\1N"..., 1024, 2467328) = 1024 30734 0.000055 pwrite64(259, "\1\"\0\0\325\22\0\0\305\0\0\0\20\200w\n\354\2\0\0\0050\0\0C\276g\0\1\0re"..., 1024, 2468352) = 1024 30734 0.000050 pwrite64(259, "\1\"\0\0\327\22\0\0\305\0\0\0\20\200\36$h\2\0\0\5 \0\0E\276g\0\1\0M\7"..., 1024, 2469376) = 1024 30734 0.000060 pwrite64(259, "\1\"\0\0\331\22\0\0\305\0\0\0\20\200\345E\300\0\0\0\6N\0\0G\276g\0\1\0UB"..., 512, 2470400) = 512 30734 0.000134 pwrite64(259, "\1\"\0\0\332\22\0\0\305\0\0\0\20\200k\212\354\2\0\0\0054\0\0\361\276g\0\1\0003\5"..., 1024, 2470912) = 1024 30734 0.000121 pwrite64(259, "\1\"\0\0\334\22\0\0\305\0\0\0\20\200^\210h\2\0\0\5\7\0\0\363\276g\0\1\00020"..., 1024, 2471936) = 1024 30734 0.000066 pwrite64(259, "\1\"\0\0\336\22\0\0\305\0\0\0\20\200*Z\354\2\0\0\0054\0\0\377\276g\0\1\0re"..., 1024, 2472960) = 1024 30734 0.000051 pwrite64(259, "\1\"\0\0\340\22\0\0\305\0\0\0\20\200\203\215h\2\0\0\5\301\0\0\1\277g\0\1\0LI"..., 1024, 2473984) = 1024 ---这行记录 30734 0.000059 pwrite64(259, "\1\"\0\0\342\22\0\0\305\0\0\0\20\200\25\242\274\1\0\0\r\16\0\0\3\277g\0\1\0-2"..., 7168, 2475008) = 7168 30734 0.000054 pwrite64(259, "\1\"\0\0\360\22\0\0\305\0\0\0\20\200\323\317\f\2\0\0\5z\0\0\5\277g\0\1\0sO"..., 1536, 2482176) = 1536 30734 0.000049 pwrite64(259, "\1\"\0\0\363\22\0\0\305\0\0\0\20\200y\233\214\0\0\0\5M\0\0\10\277g\0\1\0\377\4"..., 3072, 2483712) = 3072 30734 0.000051 pwrite64(259, "\1\"\0\0\371\22\0\0\305\0\0\0\20\200\366\251\4\2\0\0\5P\0\0\16\277g\0\1\0M\7"..., 1024, 2486784) = 1024 30734 0.000047 pwrite64(259, "\1\"\0\0\373\22\0\0\305\0\0\0\20\200\246Op\0\0\0\6I\0\0\20\277g\0\1\0\301\2"..., 512, 2487808) = 512 30734 0.000054 pwrite64(259, "\1\"\0\0\374\22\0\0\305\0\0\0\20\200#\277\354\2\0\0\5:\0\0\25\277g\0\1\0\5V"..., 1024, 2488320) = 1024 30734 0.000151 pwrite64(259, "\1\"\0\0\376\22\0\0\305\0\0\0\20\200\20\277h\2\0\0\5L\0\0\27\277g\0\1\0\f-"..., 1024, 2489344) = 1024 30734 0.000056 pwrite64(259, "\1\"\0\0\0\23\0\0\305\0\0\0\20\200\272Np\0\0\0\6 \0\0\31\277g\0\1\0\10\30"..., 512, 2490368) = 512 30734 0.000055 pwrite64(259, "\1\"\0\0\1\23\0\0\305\0\0\0\20\200\307\353\354\2\0\0\5C\0\0\35\277g\0\1\0t\377"..., 1024, 2490880) = 1024 30734 0.000167 pwrite64(259, "\1\"\0\0\3\23\0\0\305\0\0\0\20\200\303\233h\2\0\0\5N\0\0\37\277g\0\1\0UB"..., 1024, 2491904) = 1024 30734 0.000131 pwrite64(259, "\1\"\0\0\5\23\0\0\305\0\0\0\20\2001m\354\2\0\0\5\30\0\0'\277g\0\1\0\f-"..., 1024, 2492928) = 1024 30734 0.000123 pwrite64(259, "\1\"\0\0\7\23\0\0\305\0\0\0\20\200\26\321h\2\0\0\5\f\0\0)\277g\0\1\0'\0"..., 1024, 2493952) = 1024 30734 0.000054 pwrite64(259, "\1\"\0\0\t\23\0\0\305\0\0\0\20\200\272\374\364\2\0\0\5b\0\0.\277g\0\1\0ss"..., 1024, 2494976) = 1024 30734 0.000052 pwrite64(259, "\1\"\0\0\v\23\0\0\305\0\0\0\20\200\257\354p\2\0\0\5\377\0\0000\277g\0\1\0AS"..., 1024, 2496000) = 1024 30734 0.000060 pwrite64(259, "\1\"\0\0\r\23\0\0\305\0\0\0\20\200\10\363\354\2\0\0\5V\0\0004\277g\0\1\0\1N"..., 1024, 2497024) = 1024 30734 0.000049 pwrite64(259, "\1\"\0\0\17\23\0\0\305\0\0\0\20\200/\367h\2\0\0\5D\0\0006\277g\0\1\0\2,"..., 1024, 2498048) = 1024 30734 0.000130 pwrite64(259, "\1\"\0\0\21\23\0\0\305\0\0\0\20\200\326Rp\0\0\0\6I\0\0008\277g\0\1\0LA"..., 512, 2499072) = 512 |
定位到偏移量之后,这里我们可以借助bbed小工具来进行修改redo,以实现模拟写丢失的情况:
1 2 3 4 5 6 7 8 9 10 11 |
SQL> select dump('lizhenxu',16) from dual; DUMP('LIZHENXU',16) -------------------------------------------------------------------------- Typ=96 Len=8: 6c,69,7a,68,65,6e,78,75 SQL> select dump('enmotech',16) from dual; DUMP('ENMOTECH',16) -------------------------------------------------------------------------- Typ=96 Len=8: 65,6e,6d,6f,74,65,63,68 |
如上是我需要进行修改的数据并进行了16进制dump,下面来修改一下:
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 |
BBED> info File# Name Size(blks) ----- ---- ---------- 1 /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log 0 BBED> set file FILE# 1 BBED> set blocksize 512 BLOCKSIZE 512 BBED> set block 4834 BLOCK# 4834 BBED> find /x 6c69 File: /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log (1) Block: 4834 Offsets: 180 to 243 Dba:0x004012e2 ------------------------------------------------------------------------ 6c697a68 656e7875 05021b00 0300ffff d000c000 27be6700 00000000 0100ffff 04002000 04000100 b3140000 b417c000 4c042c00 1200a400 00000000 00000000 <32 bytes per line> BBED> modify /x 656e6d6f offset 180 File: /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log (1) Block: 4834 Offsets: 180 to 243 Dba:0x004012e2 ------------------------------------------------------------------------ 656e6d6f 656e7875 05021b00 0300ffff d000c000 27be6700 00000000 0100ffff 04002000 04000100 b3140000 b417c000 4c042c00 1200a400 00000000 00000000 <32 bytes per line> BBED> modify /x 74656368 offset 184 File: /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log (1) Block: 4834 Offsets: 184 to 247 Dba:0x004012e2 ------------------------------------------------------------------------ 74656368 05021b00 0300ffff d000c000 27be6700 00000000 0100ffff 04002000 04000100 b3140000 b417c000 4c042c00 1200a400 00000000 00000000 00000000 <32 bytes per line> BBED> d /v offset 180 count 16 File: /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log (1) Block: 4834 Offsets: 180 to 195 Dba:0x004012e2 ------------------------------------------------------- 656e6d6f 74656368 05021b00 0300ffff l enmotech........ <16 bytes per line> BBED> sum apply Check value for File 1, Block 4834: current = 0x01bc, required = 0x01bc |
修改完成之后,我们来尝试切换一下redo log,看此时Oracle数据库是否能够进行正常归档。
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 |
Fri Apr 14 17:50:03 2023 Thread 1 advanced to log sequence 198 (LGWR switch) Current log# 3 seq# 198 mem# 0: /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo03.log Fri Apr 14 17:50:03 2023 Incomplete read from log member '/u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log'. Trying next member. ARC3: Log corruption near block 4834 change 6799106 time ? CORRUPTION DETECTED: thread 1 sequence 197 log 2 at block 4834. Arch found corrupt blocks Errors in file /u01/app/oracle/diag/rdbms/oggdb/oggdb/trace/oggdb_arc3_31280.trc (incident=6185): ORA-00353: log corruption near block 4834 change 6799106 time 04/14/2023 16:38:44 ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log' Incident details in: /u01/app/oracle/diag/rdbms/oggdb/oggdb/incident/incdir_6185/oggdb_arc3_31280_i6185.trc ARC3: All Archive destinations made inactive due to error 354 ARC3: Closing local archive destination LOG_ARCHIVE_DEST_1: '/u01/app/oracle/oradata/arch/OGGDB/archivelog/2023_04_14/o1_mf_1_197_l3l8gcgz_.arc' (error 354) (oggdb) Committing creation of archivelog '/u01/app/oracle/oradata/arch/OGGDB/archivelog/2023_04_14/o1_mf_1_197_l3l8gcgz_.arc' (error 354) Deleted Oracle managed file /u01/app/oracle/oradata/arch/OGGDB/archivelog/2023_04_14/o1_mf_1_197_l3l8gcgz_.arc ARCH: Archival stopped, error occurred. Will continue retrying ORACLE Instance oggdb - Archival Error ORA-16038: log 2 sequence# 197 cannot be archived ORA-00354: corrupt redo log block header ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log' Fri Apr 14 17:50:04 2023 ARCH: Archival stopped, error occurred. Will continue retrying ORACLE Instance oggdb - Archival Error ORA-16014: log 2 sequence# 197 not archived, no available destinations ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log' Fri Apr 14 17:50:04 2023 Sweep [inc][6185]: completed Fri Apr 14 17:50:04 2023 Sweep [inc2][6185]: completed Incomplete read from log member '/u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log'. Trying next member. Incomplete read from log member '/u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log'. Trying next member. Errors in file /u01/app/oracle/diag/rdbms/oggdb/oggdb/trace/oggdb_m000_32589.trc (incident=6353): ORA-00353: log corruption near block 4834 change 6799106 time 04/14/2023 17:35:49 ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log' Incident details in: /u01/app/oracle/diag/rdbms/oggdb/oggdb/incident/incdir_6353/oggdb_m000_32589_i6353.trc Fri Apr 14 17:50:04 2023 Dumping diagnostic data in directory=[cdmp_20230414175004], requested by (instance=1, osid=31280 (ARC3)), summary=[incident=6185]. Checker run found 1 new persistent data failures |
从上述alert log来看,此时数据库已经报redo log corruption了,无法进行正常归档。我们进一步来看下归档进程的堆栈信息:
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 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 |
*** ACTION NAME:() 2023-04-14 17:50:03.643 Dump continued from file: /u01/app/oracle/diag/rdbms/oggdb/oggdb/trace/oggdb_arc3_31280.trc ORA-00353: log corruption near block 4834 change 6799106 time 04/14/2023 16:38:44 ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log' ========= Dump for incident 6185 (ORA 353 [4834] [6799106]) ======== *** 2023-04-14 17:50:03.643 dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0) ----- SQL Statement (None) ----- Current SQL information unavailable - no cursor. ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- skdstdst()+41 call kgdsdst() 000000000 ? 000000000 ? 7FFD053DA860 ? 7FFD053DA938 ? 7FFD053DF3E0 ? 000000002 ? ksedst1()+103 call skdstdst() 000000000 ? 000000000 ? 7FFD053DA860 ? 7FFD053DA938 ? 7FFD053DF3E0 ? 000000002 ? ksedst()+39 call ksedst1() 000000000 ? 000000001 ? 7FFD053DA860 ? 7FFD053DA938 ? 7FFD053DF3E0 ? 000000002 ? dbkedDefDump()+2746 call ksedst() 000000000 ? 000000001 ? 7FFD053DA860 ? 7FFD053DA938 ? 7FFD053DF3E0 ? 000000002 ? ksedmp()+41 call dbkedDefDump() 000000003 ? 000000002 ? 7FFD053DA860 ? 7FFD053DA938 ? 7FFD053DF3E0 ? 000000002 ? ksfdmp()+69 call ksedmp() 000000003 ? 000000002 ? 7FFD053DA860 ? 7FFD053DA938 ? 7FFD053DF3E0 ? 000000002 ? dbgexPhaseII()+1764 call ksfdmp() 000000003 ? 000000002 ? 7FFD053DA860 ? 7FFD053DA938 ? 7FFD053DF3E0 ? 000000002 ? dbgexProcessError() call dbgexPhaseII() 7F8545F0F730 ? 7F8542B29898 ? +2680 7FFD053E3EB8 ? 7FFD053DA938 ? 7FFD053DF3E0 ? 000000002 ? dbgeExecuteForError call dbgexProcessError() 7F8545F0F730 ? 7F8542B29898 ? ()+88 000000001 ? 000000000 ? 7FFD053DF3E0 ? 000000002 ? dbgePostErrorKGE()+ call dbgeExecuteForError 7F8545F0F730 ? 7F8542B29898 ? 2136 () 000000001 ? 000000001 ? 000000000 ? 000000002 ? dbkePostKGE_kgsf()+ call dbgePostErrorKGE() 00C105560 ? 7F8545F145F0 ? 71 000000161 ? 000000001 ? 000000000 ? 000000002 ? kgeade()+351 call dbkePostKGE_kgsf() 00C105560 ? 7F8545F145F0 ? 000000161 ? 000000001 ? 000000000 ? 000000002 ? kgerelv()+140 call kgeade() 00C105560 ? 00C105720 ? 7F8545F145F0 ? 000000161 ? 000000000 ? 000000002 ? kgerev()+34 call kgerelv() 00C105560 ? 7F8545F145F0 ? 000000161 ? 00A96EB74 ? 000000000 ? 000000002 ? kserec3()+170 call kgerev() 00C105560 ? 7F8545F145F0 ? 000000161 ? 00A96EB74 ? 7FFD053E4B50 ? 000000002 ? kcrcrl()+208 call kserec3() 00C105560 ? 000000000 ? 0000012E2 ? 000000001 ? 000000007 ? 7FFD053E4BB4 ? krse_arc_spool()+19 call kcrcrl() 7F8541684038 ? 000000162 ? 011 0000012E2 ? 7FFD053E4BA0 ? 000000007 ? 7FFD053E4BB4 ? krse_arc_driver_cor call krse_arc_spool() 7FFD053E60FC ? 000000162 ? e()+1185 0000012E2 ? 7FFD053E4BA0 ? 000000007 ? 7FFD053E4BB4 ? krse_arc_driver()+5 call krse_arc_driver_cor 7FFD053E60FC ? 000000162 ? 22 e() 0000012E2 ? 000000000 ? 000000000 ? 7FFD053E8F34 ? kcrrwkx()+4421 call krse_arc_driver() 7FFD053E8EA0 ? 000000002 ? 7FFD053E8E50 ? 000000000 ? 000000000 ? 7FFD053E8F34 ? kcrrwk()+283 call kcrrwkx() 7FFD053E9868 ? 000000030 ? 000000001 ? 000000000 ? 000000000 ? 7FFD053E8F34 ? ksbabs()+771 call kcrrwk() 7FFD053E9868 ? 000000030 ? 000000001 ? 000000000 ? 000000000 ? 7FFD053E8F34 ? krsv_abs()+59 call ksbabs() 7FFD053E9868 ? 000000030 ? 000000001 ? 000000000 ? 000000000 ? 7FFD053E8F34 ? ksbrdp()+1045 call krsv_abs() 0000006FA ? 000000030 ? 000000001 ? 000000000 ? 000000000 ? 7FFD053E8F34 ? opirip()+623 call ksbrdp() 0000006FA ? 000000030 ? 000000001 ? 000000000 ? 000000000 ? 7FFD053E8F34 ? opidrv()+603 call opirip() 000000032 ? 000000004 ? 7FFD053EAB08 ? 000000000 ? 000000000 ? 7FFD053E8F34 ? sou2o()+103 call opidrv() 000000032 ? 000000004 ? 7FFD053EAB08 ? 000000000 ? 000000000 ? 7FFD053E8F34 ? opimai_real()+250 call sou2o() 7FFD053EAAE0 ? 000000032 ? 000000004 ? 7FFD053EAB08 ? 000000000 ? 7FFD053E8F34 ? ssthrdmain()+265 call opimai_real() 000000000 ? 7FFD053EACD0 ? 000000004 ? 7FFD053EAB08 ? 000000000 ? 7FFD053E8F34 ? main()+201 call ssthrdmain() 000000003 ? 7FFD053EACD0 ? 000000001 ? 000000000 ? 000000000 ? 7FFD053E8F34 ? __libc_start_main() call main() 000000003 ? 7FFD053EAE70 ? +245 000000001 ? 000000000 ? 000000000 ? 7FFD053E8F34 ? _start()+41 call __libc_start_main() 000A175F0 ? 000000001 ? 7FFD053EAE68 ? 000000000 ? 000000000 ? 7FFD053E8F34 ? |
从上面的堆栈信息来看,与客户环境的报错相关堆栈是基本匹配的(客户环境是AIX平台,我这里是Linux)。由于我前面测试环境中,redo log组只有一个member成员,如果是每个redo log组有2个member,那么其中一个出现写丢失或者损坏,那么会影响归档吗? 带着这个疑问,我再次进行了测试。
首先我这里先处理一下故障环境,然后增加了log member成员:
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 |
SQL> alter database drop logfile group 2; alter database drop logfile group 2 * ERROR at line 1: ORA-00350: log 2 of instance oggdb (thread 1) needs to be archived ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log' SQL> alter database clear unarchived logfile group 2; Database altered. SQL> alter database add logfile member '/u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02_b.log' to group 2; Database altered. SQL> select * from v$Log; GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARCHIV STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME ---------- ---------- ---------- ---------- ---------- ---------- ------ -------------------------------- ------------- ------------------- ------------ ------------------- 1 1 199 52428800 512 1 NO ACTIVE 6822146 2023-04-14 22:00:12 6959649 2023-04-17 11:11:11 2 1 200 52428800 512 2 NO CURRENT 6959649 2023-04-17 11:11:11 2.8147E+14 3 1 198 52428800 512 1 NO INACTIVE 6800058 2023-04-14 17:50:03 6822146 2023-04-14 22:00:12 SQL> alter database add logfile member '/u01/app/oracle/oradata/data/OGGDB/onlinelog/redo03_b.log' to group 3; Database altered. SQL> alter database add logfile member '/u01/app/oracle/oradata/data/OGGDB/onlinelog/redo01_b.log' to group 1; Database altered. SQL> |
接下来我们继续重复上述的测试过程:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
SQL> select * from v$Log; GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARCHIV STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME ---------- ---------- ---------- ---------- ---------- ---------- ------ -------------------------------- ------------- ------------------- ------------ ------------------- 1 1 202 52428800 512 2 YES INACTIVE 6961062 2023-04-17 11:17:17 6961065 2023-04-17 11:17:19 2 1 203 52428800 512 2 YES INACTIVE 6961065 2023-04-17 11:17:19 6961068 2023-04-17 11:17:23 3 1 204 52428800 512 2 NO CURRENT 6961068 2023-04-17 11:17:23 2.8147E+14 SQL> update test0413 set object_name='lizhenxu' where object_id=8; 1 row updated. SQL> commit; Commit complete. SQL> select object_name from test0413 where object_id=8; OBJECT_NAME -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- lizhenxu |
同时打开strace跟踪,方便定位redo的读写偏移量:
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 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 |
[root@Ora11g-ogg-Target ~]# strace -fr -o /tmp/30734_0417.log -p 30734 strace: Process 30734 attached ^Cstrace: Process 30734 detached [root@Ora11g-ogg-Target ~]# [root@Ora11g-ogg-Target ~]# cat /tmp/30734_0417.log|grep write 30734 0.000087 pwrite64(260, "\1\"\0\0(\0\0\0\314\0\0\0\20\200\273\r\354\2\0\0\5\0\0\0\3677j\0\1\0002\0"..., 1024, 20480) = 1024 30734 0.000261 pwrite64(266, "\1\"\0\0(\0\0\0\314\0\0\0\20\200\273\r\354\2\0\0\5\0\0\0\3677j\0\1\0002\0"..., 1024, 20480) = 1024 30734 0.000057 pwrite64(260, "\1\"\0\0*\0\0\0\314\0\0\0\20\200sNh\2\0\0\5\0\0\0\3717j\0\1\0I\0"..., 1024, 21504) = 1024 30734 0.000221 pwrite64(266, "\1\"\0\0*\0\0\0\314\0\0\0\20\200sNh\2\0\0\5\0\0\0\3717j\0\1\0I\0"..., 1024, 21504) = 1024 30734 0.000047 pwrite64(260, "\1\"\0\0,\0\0\0\314\0\0\0\20\200\262.\354\2\0\0\5\31\0\0\0058j\0\1\0\0\0"..., 1024, 22528) = 1024 30734 0.000228 pwrite64(266, "\1\"\0\0,\0\0\0\314\0\0\0\20\200\262.\354\2\0\0\5\31\0\0\0058j\0\1\0\0\0"..., 1024, 22528) = 1024 30734 0.000040 pwrite64(260, "\1\"\0\0.\0\0\0\314\0\0\0\20\200\n\24h\2\0\0\5W\0\0\0078j\0\1\0G\2"..., 1024, 23552) = 1024 30734 0.000154 pwrite64(266, "\1\"\0\0.\0\0\0\314\0\0\0\20\200\n\24h\2\0\0\5W\0\0\0078j\0\1\0G\2"..., 1024, 23552) = 1024 30734 0.000062 pwrite64(260, "\1\"\0\0000\0\0\0\314\0\0\0\20\200\317\214\354\2\0\0\5\0\0\0\r8j\0\1\0\1\0"..., 1024, 24576) = 1024 30734 0.000294 pwrite64(266, "\1\"\0\0000\0\0\0\314\0\0\0\20\200\317\214\354\2\0\0\5\0\0\0\r8j\0\1\0\1\0"..., 1024, 24576) = 1024 30734 0.000054 pwrite64(260, "\1\"\0\0002\0\0\0\314\0\0\0\20\200\205zh\2\0\0\0058\0\0\0178j\0\1\0\0\0"..., 1024, 25600) = 1024 30734 0.000169 pwrite64(266, "\1\"\0\0002\0\0\0\314\0\0\0\20\200\205zh\2\0\0\0058\0\0\0178j\0\1\0\0\0"..., 1024, 25600) = 1024 30734 0.000060 pwrite64(260, "\1\"\0\0004\0\0\0\314\0\0\0\20\200|\306<\2\0\0\r\0\0\0\0258j\0\1\0\36\24"..., 1024, 26624) = 1024 30734 0.000291 pwrite64(266, "\1\"\0\0004\0\0\0\314\0\0\0\20\200|\306<\2\0\0\r\0\0\0\0258j\0\1\0\36\24"..., 1024, 26624) = 1024 30734 0.000077 pwrite64(260, "\1\"\0\0006\0\0\0\314\0\0\0\20\20016\354\2\0\0\5\0\0\0\0308j\0\1\0\1\0"..., 1024, 27648) = 1024 30734 0.000227 pwrite64(266, "\1\"\0\0006\0\0\0\314\0\0\0\20\20016\354\2\0\0\5\0\0\0\0308j\0\1\0\1\0"..., 1024, 27648) = 1024 30734 0.000049 pwrite64(260, "\1\"\0\0008\0\0\0\314\0\0\0\20\200\361\354h\2\0\0\5\0\0\0\0328j\0\1\0\377\377"..., 1024, 28672) = 1024 30734 0.000163 pwrite64(266, "\1\"\0\0008\0\0\0\314\0\0\0\20\200\361\354h\2\0\0\5\0\0\0\0328j\0\1\0\377\377"..., 1024, 28672) = 1024 30734 0.000056 pwrite64(260, "\1\"\0\0:\0\0\0\314\0\0\0\20\200\177\242\354\2\0\0\5\26\0\0\"8j\0\1\0\363\257"..., 1024, 29696) = 1024 30734 0.000224 pwrite64(266, "\1\"\0\0:\0\0\0\314\0\0\0\20\200\177\242\354\2\0\0\5\26\0\0\"8j\0\1\0\363\257"..., 1024, 29696) = 1024 30734 0.000050 pwrite64(260, "\1\"\0\0<\0\0\0\314\0\0\0\20\200k\\h\2\0\0\5\0\0\0$8j\0\1\0\2\0"..., 1024, 30720) = 1024 30734 0.000167 pwrite64(266, "\1\"\0\0<\0\0\0\314\0\0\0\20\200k\\h\2\0\0\5\0\0\0$8j\0\1\0\2\0"..., 1024, 30720) = 1024 30734 0.000060 pwrite64(260, "\1\"\0\0>\0\0\0\314\0\0\0\20\200\313\271\364\2\0\0\5\0\0\0(8j\0\1\0\0\0"..., 1024, 31744) = 1024 30734 0.000409 pwrite64(266, "\1\"\0\0>\0\0\0\314\0\0\0\20\200\313\271\364\2\0\0\5\0\0\0(8j\0\1\0\0\0"..., 1024, 31744) = 1024 30734 0.000061 pwrite64(260, "\1\"\0\0@\0\0\0\314\0\0\0\20\200@\2p\2\0\0\5\r\0\0*8j\0\1\0\300\0"..., 1024, 32768) = 1024 30734 0.000230 pwrite64(266, "\1\"\0\0@\0\0\0\314\0\0\0\20\200@\2p\2\0\0\5\r\0\0*8j\0\1\0\300\0"..., 1024, 32768) = 1024 30734 0.000068 pwrite64(260, "\1\"\0\0B\0\0\0\314\0\0\0\20\200\366R\354\2\0\0\5\0\0\0.8j\0\1\0\1\0"..., 1024, 33792) = 1024 30734 0.000242 pwrite64(266, "\1\"\0\0B\0\0\0\314\0\0\0\20\200\366R\354\2\0\0\5\0\0\0.8j\0\1\0\1\0"..., 1024, 33792) = 1024 30734 0.000055 pwrite64(260, "\1\"\0\0D\0\0\0\314\0\0\0\20\200\356Xh\2\0\0\5\22\0\00008j\0\1\0\t\324"..., 1024, 34816) = 1024 30734 0.000185 pwrite64(266, "\1\"\0\0D\0\0\0\314\0\0\0\20\200\356Xh\2\0\0\5\22\0\00008j\0\1\0\t\324"..., 1024, 34816) = 1024 30734 0.000161 pwrite64(260, "\1\"\0\0F\0\0\0\314\0\0\0\20\200e2\354\2\0\0\5\0\0\00068j\0\1\0\34\2"..., 1024, 35840) = 1024 30734 0.000473 pwrite64(266, "\1\"\0\0F\0\0\0\314\0\0\0\20\200e2\354\2\0\0\5\0\0\00068j\0\1\0\34\2"..., 1024, 35840) = 1024 30734 0.000117 pwrite64(260, "\1\"\0\0H\0\0\0\314\0\0\0\20\200\252\17h\2\0\0\5\0\0\00088j\0\1\0\0\0"..., 1024, 36864) = 1024 30734 0.000286 pwrite64(266, "\1\"\0\0H\0\0\0\314\0\0\0\20\200\252\17h\2\0\0\5\0\0\00088j\0\1\0\0\0"..., 1024, 36864) = 1024 30734 0.000180 pwrite64(260, "\1\"\0\0J\0\0\0\314\0\0\0\20\200W\250\354\2\0\0\5\0\0\0D8j\0\1\0bR"..., 1024, 37888) = 1024 30734 0.000388 pwrite64(266, "\1\"\0\0J\0\0\0\314\0\0\0\20\200W\250\354\2\0\0\5\0\0\0D8j\0\1\0bR"..., 1024, 37888) = 1024 30734 0.000122 pwrite64(260, "\1\"\0\0L\0\0\0\314\0\0\0\20\200\32\320h\2\0\0\5\22\0\0F8j\0\1\0\0Z"..., 1024, 38912) = 1024 30734 0.000309 pwrite64(266, "\1\"\0\0L\0\0\0\314\0\0\0\20\200\32\320h\2\0\0\5\22\0\0F8j\0\1\0\0Z"..., 1024, 38912) = 1024 [root@Ora11g-ogg-Target ~]# [root@Ora11g-ogg-Target ~]# ls -ltr /proc/30734/fd total 0 lrwx------. 1 oracle oinstall 64 Mar 26 14:28 12 -> socket:[36157618] lrwx------. 1 oracle oinstall 64 Apr 14 17:31 9 -> /u01/app/oracle/product/11.2.0.4/dbhome_1/dbs/hc_oggdb.dat lr-x------. 1 oracle oinstall 64 Apr 14 17:31 8 -> /dev/zero lr-x------. 1 oracle oinstall 64 Apr 14 17:31 7 -> /proc/30734/fd lr-x------. 1 oracle oinstall 64 Apr 14 17:31 6 -> /u01/app/oracle/product/11.2.0.4/dbhome_1/rdbms/mesg/oraus.msb lr-x------. 1 oracle oinstall 64 Apr 14 17:31 5 -> /dev/null lr-x------. 1 oracle oinstall 64 Apr 14 17:31 4 -> /dev/null lr-x------. 1 oracle oinstall 64 Apr 14 17:31 3 -> /dev/null lrwx------. 1 oracle oinstall 64 Apr 14 17:31 265 -> /u01/app/oracle/oradata/data/OGGDB/datafile/temp01.dbf lrwx------. 1 oracle oinstall 64 Apr 14 17:31 264 -> /u01/app/oracle/oradata/data/OGGDB/datafile/users01.dbf lrwx------. 1 oracle oinstall 64 Apr 14 17:31 263 -> /u01/app/oracle/oradata/data/OGGDB/datafile/undotbs01.dbf lrwx------. 1 oracle oinstall 64 Apr 14 17:31 262 -> /u01/app/oracle/oradata/data/OGGDB/datafile/sysaux01.dbf lrwx------. 1 oracle oinstall 64 Apr 14 17:31 261 -> /u01/app/oracle/oradata/data/OGGDB/datafile/system01.dbf lrwx------. 1 oracle oinstall 64 Apr 14 17:31 260 -> /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo03.log lrwx------. 1 oracle oinstall 64 Apr 14 17:31 259 -> /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02.log lrwx------. 1 oracle oinstall 64 Apr 14 17:31 258 -> /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo01.log lrwx------. 1 oracle oinstall 64 Apr 14 17:31 257 -> /u01/app/oracle/fast_recovery_area/OGGDB/control02.ctl lrwx------. 1 oracle oinstall 64 Apr 14 17:31 256 -> /u01/app/oracle/oradata/data/OGGDB/control01.ctl l-wx------. 1 oracle oinstall 64 Apr 14 17:31 2 -> /dev/null lr-x------. 1 oracle oinstall 64 Apr 14 17:31 11 -> /u01/app/oracle/product/11.2.0.4/dbhome_1/rdbms/mesg/oraus.msb lrwx------. 1 oracle oinstall 64 Apr 14 17:31 10 -> /u01/app/oracle/product/11.2.0.4/dbhome_1/dbs/lkOGGDB l-wx------. 1 oracle oinstall 64 Apr 14 17:31 1 -> /dev/null lr-x------. 1 oracle oinstall 64 Apr 14 17:31 0 -> /dev/null lrwx------. 1 oracle oinstall 64 Apr 17 11:20 268 -> /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo02_b.log lrwx------. 1 oracle oinstall 64 Apr 17 11:20 267 -> /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo01_b.log lrwx------. 1 oracle oinstall 64 Apr 17 11:20 266 -> /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo03_b.log [root@Ora11g-ogg-Target ~]# |
从上面跟踪信息来看,偏移量在25600位置,写了2个block,那么偏移量则为52. 接下来通过bbed定位到52 号block,进行修改:
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 |
BBED> set filename '/u01/app/oracle/oradata/data/OGGDB/onlinelog/redo03.log' FILENAME /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo03.log BBED> set blocksize 512 BLOCKSIZE 512 BBED> set block 52 BLOCK# 52 BBED> find /x 6c69 File: /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo03.log (0) Block: 52 Offsets: 228 to 243 Dba:0x00000000 ------------------------------------------------------------------------ 6c697a68 656e7875 05021f00 0300ffff <32 bytes per line> BBED> d /v offset 228 count 32 File: /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo03.log (0) Block: 52 Offsets: 228 to 259 Dba:0x00000000 ------------------------------------------------------- 6c697a68 656e7875 05021f00 0300ffff l lizhenxu........ f000c000 ea376a00 00000000 0100ffff l .....7j......... <16 bytes per line> BBED> modify /x 656e6d6f offset 228 Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y File: /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo03.log (0) Block: 52 Offsets: 228 to 259 Dba:0x00000000 ------------------------------------------------------------------------ 656e6d6f 656e7875 05021f00 0300ffff f000c000 ea376a00 00000000 0100ffff <32 bytes per line> BBED> modify /x 74656368 offset 232 File: /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo03.log (0) Block: 52 Offsets: 232 to 263 Dba:0x00000000 ------------------------------------------------------------------------ 74656368 05021f00 0300ffff f000c000 ea376a00 00000000 0100ffff 04002000 <32 bytes per line> BBED> sum apply Check value for File 0, Block 52: current = 0x1428, required = 0x1428 |
完成redo 修改之后,我们这里在进行redo 切换,看看是否能够正常归档或者是像前面一样报错呢?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
++++Session 2 Thread 1 advanced to log sequence 204 (LGWR switch) Current log# 3 seq# 204 mem# 0: /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo03.log Current log# 3 seq# 204 mem# 1: /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo03_b.log Mon Apr 17 11:17:23 2023 Archived Log entry 199 added for thread 1 sequence 203 ID 0x5f3bddcc dest 1: Mon Apr 17 11:36:19 2023 Thread 1 advanced to log sequence 205 (LGWR switch) Current log# 1 seq# 205 mem# 0: /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo01.log Current log# 1 seq# 205 mem# 1: /u01/app/oracle/oradata/data/OGGDB/onlinelog/redo01_b.log Mon Apr 17 11:36:19 2023 Archived Log entry 200 added for thread 1 sequence 204 ID 0x5f3bddcc dest 1: Mon Apr 17 11:36:30 2023 |
可以看到此时数据库是正常运行的,redo归档不受任何影响,这也是符合预期的。
Leave a Reply
You must be logged in to post a comment.