[分享贴]Logminer实战记录

时间: 2005-4-15 4PM
地点: 项目开发中心

1601: 程序员A惊呼: 我写的procedure变成旧版本了!
1602: 程序员B: 我的也是
1603: 数据库维护员C (红着脸跑来):
刚才我把一期的数据库建立文本跑了一遍,想装在本机的,结果没想到直接在开发服务器上运行了....
1610: 开发经理: 经过检查,程序员的机器没有备份程序 ( what a terriable management !)
1618: 开发停止,检查损失:共有9个Package被误编译,从4月7日开发的新版本Package旧版本覆盖
大致损失10个工作日的程序量
1630: 开发经理和超人X紧急磋商解决方案.期间超人X通过专家Y咨询,得到两套方案
解决方案1: recovery in time
解决方案2: logminer
1640: 方案确定: logminer . 由于数据库是运行在noarchivelog 模式,并且没有任何备份,recovery in time 方案过于复杂,不可实施.

1645: 超人X开始实施解决方案1
a. 鉴定当前active的redo log . 通过数据字典
b. 得到此redo log的log switch时间点t1.
c. 和开发经理确认所有的的Package新的编译时间t2.
d. t2在t1之后,很幸运,只要通过active redo log 就应该能够得到package的编码.
e. 停止所有程序员的数据库联接
f. telnet联上数据库服务器进行操作
g. 生成数据字典文件,是通过dbms_logmnr_d.build()来完成。
(由于utl_file_dir='*',所以设置这个参数的步骤可以省略)
SQL> BEGIN
2 dbms_logmnr_d.build(
3 dictionary_filename => 'logminer.dat',
4 dictionary_location => '/oradata/home'
5 );
6 END;
7 /
h. 建立一个日志分析表
a、建立日志分析表数据库必须在mount或nomount状态,启动数据库到mount状态。
sql>shutdown immediate
sql>starup mount

b、建立日志分析表,使用dbms_logmnr.add_logfile()
SQL> BEGIN
2 dbms_logmnr.add_logfile(
3 options => dbms_logmnr.new,
4 logfilename => '/oradata/home/redo2' --active的redolog
5 );
6 END;
7 /
i.启动LogMiner进行分析。
SQL> BEGIN
2 dbms_logmnr.start_logmnr(
3 dictfilename => '/u01/arch/logminer_dict.dat',
4 starttime => to_date('20050408 01:00:00','yyyymmdd hh24:mi:ss'), --小于t1
5 endtime => to_date('20050413 23:00:30','yyyymmdd hh24:mi:ss') --大于t2
6 );
7 END;
8 /

j.查看日志分析的结果,通过查询v$logmnr_contents可以查询到
set heading off
spool packagename.txt
SELECT sql_redo
FROM V$logmnr_contents
WHERE seg_name = 'PACKAGENAME';
/
spool off

重复j的过程为每个package都生成output文件
每个文件中最后的package应该为最新的source

k.结束LogMiner的分析。
SQL>BEGIN
2 dbms_logmnr.end_logmnr;
3 end;
4 /

1930: 整个操作结束,所有package得到恢复!整个团队对超人X表示感谢 :)

结论: a.source备份的重要性
b.数据库备份的重要性
c.logminer的神奇功效