原因:
由于某生产系统db_sc用户模式下t_sc表数据丢失,需要分析丢失的原因,下面是整个恢复步骤!
过程:
1、必须运行以下脚本,建立相应的包和表
SQL> @$ORACLE_HOME/rdbms/admin/dbmslm.sql
Package created.
Grant succeeded.
Synonym created.
SQL> @$ORACLE_HOME/rdbms/admin/dbmslmd.sql
Package created.
Synonym created.
SQL> @$ORACLE_HOME/rdbms/admin/dbmslms.sql
Package created.
No errors.
Grant succeeded.
2、指出数据字典存放的位置(先建好目录),并重启数据库
SQL> alter system set utl_file_dir='/tmp/hfsc' scope=spfile;
System altered.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 701485056 bytes
Fixed Size 2216664 bytes
Variable Size 322964776 bytes
Database Buffers 373293056 bytes
Redo Buffers 3010560 bytes
Database mounted.
Database opened.
SQL> EXECUTE dbms_logmnr_d.build( 'mydictionary.ora', '/tmp/hfsc');
3、加入要分析的归档日志
execute dbms_logmnr.add_logfile('/tmp/hfsc/arch/scdb/1_441401.dbf',dbms_logmnr.addfile);
execute dbms_logmnr.add_logfile('/tmp/hfsc/arch/scdb/1_441402.dbf',dbms_logmnr.addfile);
.......
execute dbms_logmnr.add_logfile('/tmp/hfsc/arch/scdb/1_441500.dbf',dbms_logmnr.addfile);
以上日志是我们发现信息丢失的归档日志
4、分析归档日志
执行日志分析
EXECUTE dbms_logmnr.start_logmnr(dictfilename=>'/tmp/hfsc/mydictionary');
将临时表的数据写入到一个固定表中
create table logmnr.logmnrtab5 nologging as select * from v$logmnr_contents;
结束分析
SQL> exec sys.dbms_logmnr.end_logmnr;
5、根据表查询所要找的对象和用户
select * from logmnrtab5 where seg_owner = 'DB_SC' and seg_name = 'T_SC'
sql_redo:主要反映当时执行的sql语句
session_info:主要反映当时客户端执行的情况信息,包括ip\osname\machine\dbuser等重要信息
timestamp:执行操作的具体时间。
6、分析结果:
客户端session情况:
login_username=DB_SC client_info=192.168.1.101 OS_username=Administrator Machine_name=MSHOME\MARTSON OS_terminal=MARTSON OS_process_id=2388:2712 OS_program name=PlSqlDev.exe
执行语句:
-- Drop table
drop table T_SC cascade constraints;
执行时间:
201x-x-1x 10:xx:xx
经过分析,正好符合客户提供数据丢失的时间段!
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29468144/viewspace-1079262/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/29468144/viewspace-1079262/