如何使用logdump与logmnr定位SQL语句

本次测试实验目的：
通过logdump工具解析trail文件内容信息，分析日志文件信息，精准定位，实现反向解析数据库事务。
对于Oracle GoldenGate实现多平台下的各类数据库之间的数据同步任务，时下已非常流行，对于Logdump工具与Logmnr是如何相互配合呢？
带着上述的问题，今天就来做一个小小的试验，通过小试验可以了解到如何使用logdump来定位事务所在的归档日志的位置，同时如何使用logmnr去挖掘指定的时间点的redo信息。
话不多说，直接进入实验操作中：
前提：数据库的附加日志已添加完成。
通过OGG_HOME软件环境变量进入logdump：

$cd $OGG_HOME
$./logdump
Logdump 2 >open /goldengate/dirdat/t1000022039
Current LogTrail is /goldengate/dirdat/t1000022039
Logdump 3 >ghdr on       
Logdump 4 >detail on      
Logdump 5 >detail data on
Logdump 6 >ggstokens on
Logdump 7 >usertokens on
Logdump 8 >n
2022/03/03 15:25:38.639.139 FileHeader           Len  1408 RBA 0 
Name: *FileHeader* 
 3000 01df 3000 0008 4747 0d0a 544c 0a0d 3100 0002 | 0...0...GG..TL..1...  
 0003 3200 0004 0000 27ea 3300 0008 02f2 ff7e c2c7 | ..2.....'.3......~..  
 5123 3400 003a 0038 7572 693a 6462 6462 3131 3a3a | Q#4..:.8uri:dbdb11::  
 686f 6d65 3a6f 7261 636c 653a 7072 6f64 7563 743a | home:oracle:product:  
 4a4c 524d 5330 313a 676f 6c64 656e 6761 7465 3a45 | orcl01:goldengate:E  
 5854 4b41 3600 003c 003a 2f68 6f6d 652f 6f72 6163 | XTKA6..<.:/home/orac  
 6c65 2f70 726f 6475 6374 2f4a 4c52 4d53 3031 2f67 | le/product/orcl01/g  
 
Logdump 9 >n
___________________________________________________________________ 
Hdr-Ind    :     E  (x45)     Partition  :     .  (x04)  
UndoFlag   :     .  (x00)     BeforeAfter:     B  (x42)  
RecLength  :  4927  (x133f)   IO Time    : 2022/03/03 15:25:36.000.000   
IOType     :     3  (x03)     OrigNode   :   255  (xff) 
TransInd   :     .  (x01)     FormatType :     R  (x52) 
SyskeyLen  :     0  (x00)     Incomplete :     .  (x00) 
AuditRBA   :      38422       AuditPos   : 47334440 
Continued  :     N  (x00)     RecCount   :     1  (x01) 

2022/03/03 15:25:36.000.000 Delete               Len  4927 RBA 11523 
Name: test_logdmp.test_logdmp
Before Image:                                             Partition 4   G  m   
 0000 0008 0000 0004 3338 3034 0001 0012 0000 000e | ........3804........  
 4141 3952 4530 3632 3030 3030 3333 0002 0018 0000 | AA9RE062000033......  
 0014 c5cc bdf5 b5ea c3c5 b5ea d0a1 b5e7 d7e9 d6f7 | ....................  
 c8ce 0003 0029 0000 0025 4a4c 5f50 4f53 5f43 3030 | .....)..  
 333b 4a4c 5f50 4f53 5f43 3033 373b 4a4c 5f50 4f53 | 62000033......  
 4357 5f43 3033 3200 0400 0800 0000 0430 3030 3700 | 62000033......7.qwq  
 0500 0d00 0000 0933 3830 3433 4141 3952 0006 0004 | .......38043AA9R....  
Column     0 (x0000), Len     8 (x0008)  
 0000 0004 3338 3034                               | ....3804  
Column     1 (x0001), Len    18 (x0012)  
 0000 000e 4141 3952 4530 3632 3030 3030 3333      | ....AA9RE062000033  
Column     2 (x0002), Len    24 (x0018)  
 0000 0014 c5cc bdf5 b5ea c3c5 b5ea d0a1 b5e7 d7e9 | ....................  
 d6f7 c8ce                                         | ....  
Column     3 (x0003), Len    41 (x0029)  
 0000 0025 4a4c 5f50 4f53 5f43 3030 333b 4a4c 5f50 | ...%sdiwoq;KSKOWOLLL  
 4f53 5f43 3033 373b 4a4c 5f50 4f53 4357 5f43 3033 | .......38043AA9R....  
 32                                                | 2  
Column     4 (x0004), Len     8 (x0008)  
 0000 0004 3030 3037                               | ....0007  
Column     5 (x0005), Len    13 (x000d)  
 0000 0009 3338 3034 3341 4139 52                  | ....38043AA9R  
Column     6 (x0006), Len     4 (x0004)  
 ffff 0000                                         | ....  
Column     7 (x0007), Len     6 (x0006)  
 0000 0002 2d31                                    | ....-1  
Column     8 (x0008), Len   289 (x0121)  

。。。。。。。。。。。。。。。。。。。。。。。

GGS tokens: 
 5200 0014 4141 414f 596c 4141 4d41 4146 666b 7541 | R...AAAOYlAAMAAFfkuA  
 4141 0001 7401 0000                               | AA..t... 

Logdump 12 >

在logdump中我们可以根据:AuditRBA : 38422 来定位当前需要分析的归档日志号,通过AuditPos：47334440 可以定位需要分析的点位，即事务record commit地址。

SQL> SELECT name FROM v$archived_log WHERE SEQUENCE# =38422;

NAME
--------------------------------------------------------------------------------
oracle
/home/oracle/archivelog/1_38422_880331898.dbf

SQL> EXEC dbms_logmnr.add_logfile(logfilename =>'/home/oracle/archivelog/1_38422_880331898.dbf');

PL/SQL procedure successfully completed.

SQL> EXEC dbms_logmnr.start_logmnr(options => dbms_logmnr.dict_from_online_catalog + dbms_logmnr.no_rowid_in_stmt);

PL/SQL procedure successfully completed.

SQL> col scn for 999999999999999999999999999
SQL> SELECT scn FROM v$logmnr_contents WHERE rbablk *512+ rbabyte =47334440;

                         SCN
----------------------------
              11068646910100

SQL> SELECT sql_redo FROM v$logmnr_contents WHERE scn =11068646910100;

SQL_REDO
--------------------------------------------------------------------------------
delete from "test_logdmp"."test_logdmp" where "col1" = '3804' and "col2" = 'AA9SE067000099'
 and "col3" = '12' and "col4" = 'test_logdump' and
 "col5" = '0001' and "col6" = '38SUYIIO' and "col7" IS NULL 
.........

8 rows selected.

SQL> 
至此本次实验测试反向解析SQL语句完成。
通过上述小小的实验，我们可以很快通过LOGMNR针对定位好的归档日志进行数据库事务挖掘，分析数据库事务的执行语句。
对于如何使用logdump针对trail文件进行详细分析，可以查看：http://blog.itpub.net/25174901/viewspace-2121452/，或者查看官方文档。
引申话题，如果出现误删数据想要定位该时间点的SQL语句，找回误删的数据是否可以呢，答案显而易见，也是可以的，在后续的篇章中，我们会结合真是案例进行分析讲解，敬请关注下回分解！