暂无图片
longminer挖掘DDL问题
我来答
返回问答列表
分享
Wind
2022-07-01
longminer挖掘DDL问题
logminer

故障现象：有人私自更改了表结构，增加了几个字段，导致数据同步此表时出错，不能正常同步数据了。

表结构是3天前修改的，归档日志都在，最小的补充日志已打开，客户要求查出是谁修改了表结构？

使用logminer挖掘日志，如下：


begin dbms_logmnr_d.build('dict.ora','/home/oracle');end;


begin
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344165.1780.1108483937',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344166.1679.1108484275',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344167.3970.1108484629',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344168.2990.1108485007',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344169.1359.1108485119',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344170.845.1108485487',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344171.2490.1108485883',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344172.1858.1108486203',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344173.2614.1108486627',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344174.1383.1108486971',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344175.5043.1108487377',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344176.3959.1108487827',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344177.3560.1108488245',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344178.3044.1108488593',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344179.3427.1108488895',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344180.4973.1108489127',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344181.2901.1108489345',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344182.4981.1108489703',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344183.4511.1108490145',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_1_seq_344184.3384.1108490607',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369457.1252.1108483985',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369458.3154.1108484415',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369459.3092.1108484969',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369460.4592.1108485051',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369461.1143.1108485093',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369462.1974.1108485113',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369463.3961.1108485371',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369464.2615.1108485861',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369465.3457.1108486401',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369466.6266.1108487007',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369467.1603.1108487597',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369468.3981.1108488101',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369469.1344.1108488329',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369470.2370.1108488361',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369471.2800.1108488671',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369472.641.1108488887',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369473.1068.1108489205',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369474.3247.1108489785',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369475.3151.1108490015',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369476.1804.1108490157',options=>DBMS_LOGMNR.ADDFILE);end;
begin dbms_logmnr.add_logfile(logfilename=>'+LOG/mes/archivelog/2022_06_27/thread_2_seq_369477.4634.1108490733',options=>DBMS_LOGMNR.ADDFILE);end;
end;

begin dbms_logmnr.start_logmnr(dictfilename => '/home/oracle/dict.ora');end;

select * from v$logmnr_contents where table_name='xxxxxx' and operation not in ('UPDATE','INSERT','DELETE');

BEGIN DBMS_LOGMNR.END_LOGMNR();END;


挖掘了5天前的日志，仍然没有找到增加字段的信息。

大师们，帮忙看看以上logminer的使用是否有问题？如果有完整挖掘DDL的步骤，能否回复一下？感谢，感谢！



我来答
添加附件
收藏
分享
问题补充
8条回答
默认
最新
刘贵宾

https://docs.oracle.com/cd/E11882_01/server.112/e22490/logminer.htm#SUTIL019

看看官网

暂无图片 评论
暂无图片 有用 0
冯睿

相关日志是否全部都添加？
https://www.modb.pro/db/177287
参考一下这篇文章，第5步select部分改一下，分析完毕后结束挖掘。
查看DDL分析结果
select to_char(timestamp,‘yyyy-mm-dd hh24:mi:ss’) time,sql_redo from v$logmnr_contents where sql_redo like ‘%ALTER%’ or sql_undo like ‘%ALTER%’

查看DML分析结果
select operation,sql_redo,sql_undo from v$logmnr_contents where seg_name=‘xxxx’

暂无图片 评论
暂无图片 有用 0
锡
按你说法，你查询应该这样：select * from v$logmnr_contents where SQL_REDO like 'CREATE%';
暂无图片 评论
暂无图片 有用 0
冯睿

问题描述中提到，“有人私自更改了表结构，增加了几个字段”，我的理解这个操作是
alter table table_name add (new_col type1,new_co2 type2…);

暂无图片 评论
暂无图片 有用 0
Wind

添加挖掘的归档日志，我是添加每2个小时的归档日志来挖掘的，表是28日中午11：00前发现增加了字段。但是28日11：00前的归档日志很多，我怕撑爆内存，影响生产，所以分段挖掘。

增加字段，应该就是alter table xxx add column这样的操作。所以，我把DML的语句先排除了。

暂无图片 评论
暂无图片 有用 0
JiekeXu
暂无图片

是的，增加字段肯定是 alter，排查 DML 没问题。如果确定是 DDL 的话，可以先确定大概的一个时间。
可以先查此表最近的 DDL 发生在什么时候，dba_objects 的 LAST_DDL_TIME 记录了最近一次的 DDL 时间。当然如果三天后还有 DDL 就不行了。

LogMiner 也有不支持的数据类型和表存储属性。如果表包含具有这些不受支持的数据类型的列，则 LogMiner 将忽略整个表。那么也就查看不了。具体信息参考官方文档。

暂无图片 评论
暂无图片 有用 0
Wind

各位大师，添加字段的DDL，我已挖掘出来了，但是，OS_USERNAME,MACHINE_NAME和SESSION_INFO显示UNKOWN，那就查不出来是谁操作的了？我添加了早上6：00到中午11：00所有的归档，但还是显示UNKNOWN，我是不是还要继续添加更早的归档日志，包含用户的登录信息的归档日志，才能不显示UNKNOWN？各位大师，有谁再指点一下？补充一下最小的补充日志是打开的，SUPPLEMENTAL_LOG_DATA_MIN是YES。

暂无图片 评论
暂无图片 有用 0
cqiwen

查出添加字段的DDL具体时间点后，再查下v$sql、V$active_session_history中是否还有相关记录，另外再查下审计日志和监听日志，基本上能判定出是哪个用户哪个IP在操作。话说，你们的DG没有开ddl同步功能吗？

暂无图片 评论
暂无图片 有用 0
回答交流
提交
问题信息
请登录之后查看
邀请回答
暂无人订阅该标签，敬请期待~~
暂无图片墨值悬赏