数据表中数据被删了，我怎么查谁干的？

Yong Huang

> 我就随口一说，黄版还真当会事
> 学习了

I also 学习了!

> 10g 貌似 不启动日志追加模式 是挖掘不到dml的  以前是这样理解的  看了黄版的test    明白了

I already posted the easiest, simplest, minimalist test case. If you all can test, I'd be glad to see what happens. There's one factor in my case that is not deterministic: IMU could be flushed at an unknown time. So more tests help.

Yong Huang

bigacer

如果在10G里面使用ALTER DATABASE ADD SUPPLEMENTAL LOG DATA的话，那么归档日志的大小就要变大很多，能不能这么理解？

Yong Huang

原帖由 bigacer 于 2010-3-11 22:31 发表
如果在10G里面使用ALTER DATABASE ADD SUPPLEMENTAL LOG DATA的话，那么归档日志的大小就要变大很多，能不能这么理解？

I didn't measure it. Can you test? We'd love to have some test results. If you do, remember to tell us the exact Oracle version. Thanks.

Yong huang

jametong

IMU 只会降低undo 文件的写频率以及写的内容大小,不会降低redo日志相关的的大小.

打开Supplemental log以后,,日志文件确实会增大,,我们这边对9i/10g的处理都会带来这个结果..

大概地解释如下:
打开supplemental log以后,,对应表的每条记录的变更,,都会包含其打开的相应字段(eg: primary key),而这对于那些没有打开supplement log的应用是不需要记录.. 我自己对此的理解就是打开Supplemental log以后, Oracle相当于帮你实现了一个完全基于redo的内部trigger. 并且这个Trigger并不会判断这变更如何处理的,,处理了多少字段,,也就是它的逻辑很简单,,就是多记录这几个打开Supplemental log的字段的内容到日志中..

[ 本帖最后由 jametong 于 2010-3-13 14:36 编辑 ]

Yong Huang

原帖由 jametong 于 2010-3-13 00:35 发表
IMU 只会降低undo 文件的写频率以及写的内容大小

It lowers the frequency of undo writes. But does it lower the amount of undo, in terms of bytes written? My test in 10.2.0.4 shows that it does not:

delete from test;
rollback;
select a.name, b.value from v$statname a, v$mystat b
where a.statistic#=b.statistic# and (name like '%undo%' or name like '%rollback%') and value>0
order by 1;

It's better to run the above twice and take the second set of values. Then
alter session set "_in_memory_undo" = false;
and run the above again.

My test shows that "rollback changes - undo records applied" increased by the same amount in the two runs. So did "undo change vector size".

Yong Huang

[ 本帖最后由 Yong Huang 于 2010-3-13 16:10 编辑 ]

liqy103

Another place is listener log file, if someone choose to do some illegal things , he/she may choose off-peak hour ,  like weekend.  Based the timestamp, machine, os id , then can question he/she why logon at that moment.
This can not tell exact command executed, but can be a factor for a police case.
This did happen in my company.

eagle_fan

Is it possible to dump the archive logs and find the client info?

jametong

原帖由 eagle_fan 于 2010-3-15 23:42 发表
Is it possible to dump the archive logs and find the client info?

logmnr 或者dump log的时候,,有时有session_info,,,有时没有session_info,,client_info(dbms_application_info.set_client_info设置的那个)不会出现在日志中..

我自己也在工作中遇到过类似的需求,,实在没有其它办法的情况,,我会尝试使用Logmnr来分析log看是否能够找到蛛丝马迹.. 结论如上所述,,有时欢喜有时悲.

[ 本帖最后由 jametong 于 2010-3-16 10:26 编辑 ]

eagle_fan

很早之前做过此类事情，因为没有记下来，原来的例子已经找不到了。记得当时是用的dump logfile

一点印象是是如果redo log中已经记录过某session number, serial  number的详细client information(包括username,machine name,client info,program name等等），下一次再记录时，只会记录session number, serial number

所以如果是长连接的话，可能除了sid, serial#外看不到其他的信息，不过可以到v$session中碰碰运气，也许该session还在
如果是短连接的话，看不到其他的信息，可以试着向前dump几个archive log，也许就可以找到client information

eagle_fan

原帖由 jametong 于 2010-3-16 10:25 发表


logmnr 或者dump log的时候,,有时有session_info,,,有时没有session_info,,client_info(dbms_application_info.set_client_info设置的那个)不会出现在日志中..

我自己也在工作中遇到过类似的需求,,实在没有其它办法的情况,,我会尝试使用Logmnr来分析log看是否能够找到蛛丝马迹.. 结论如上所述,,有时欢喜有时悲.

记得看到有client info这一列，具体会不会记录倒没注意