2多小时产生了4G ARCHIVELOG文件!!

[复制链接]
查看11 | 回复9 | 2005-4-26 14:47:45 | 显示全部楼层 |阅读模式
凌晨3点,客户打电话给我告诉我应用程序全部登陆不了数据库,慌忙打个的杀过去,发现是ARCHIVELOG日志满了,一开始觉得不太可能,我们使用CA对数据库进行备份,其中有一个策略就是每天晚上12点,备份ARCHIVELOG文件,然后删除。短短两个多小时不可能产生4GB的ARCHIVE log文件,怀疑又是公司开发人员有什么JOB进行了大批量的插入或更新。仔细询问,都答没有。
谁可以告诉我怎么查找怎么会产生这么多的归档日志?苦呀,用户要求我们书面解释这件事。
现在好像正常了,归档日志容量也正常。
回复

使用道具 举报

千问 | 2005-4-26 14:47:45 | 显示全部楼层
看看alert文件中有没有什么有用的信息么
回复

使用道具 举报

千问 | 2005-4-26 14:47:45 | 显示全部楼层
有一个定律叫做:用户方说没有进行操作,那一定是假的.
-By Fenng
回复

使用道具 举报

千问 | 2005-4-26 14:47:45 | 显示全部楼层
use logminer, it is not difficult to see who did what.
回复

使用道具 举报

千问 | 2005-4-26 14:47:45 | 显示全部楼层
alter文件应该不会有这种记录吧,因为我想日志满 本身不是什么错误。
ogminer怎么使用,希望能详细告知,谢谢!!
回复

使用道具 举报

千问 | 2005-4-26 14:47:45 | 显示全部楼层
How to use logminer:
1. make sure that sys.dbms_logmnr_d exist(if not , create it with dbmslogmnrd.sql in /rdbms/admin)
2. check utl_file_dir is valid (for example /ora05/logminer)
3. create logminer dictionary file: execute dbms_logmnr_d.build(‘log_dict.txt’,’/ora05/logminer’);
4. identify which archived logs need to be analyzed, these need to be copied to utl_file_dir first
execute dbms_logmnr.add_logfile('/ora05/logminer/arch_POOLDB_0000000015.arc',dbms_logmnr.new);
execute dbms_logmnr.add_logfile('/ora05/logminer/arch_POOLDB_0000000016.arc',dbms_logmnr.addfile);
5start logminer
execute dbms_logmnr.start_logmnr(DICTFILENAME => '/ora05/logminer/log_dict.txt');
6analyze data: select timestamp, username, sql_redo,sql_undo from v$logmnr_contents;
7. end logminer : execute dbms_logmnr.end_logmnr;
回复

使用道具 举报

千问 | 2005-4-26 14:47:45 | 显示全部楼层
最初由 Fenng 发布
[B]有一个定律叫做:用户方说没有进行操作,那一定是假的.
-By Fenng [/B]


这句话简直是真理!
回复

使用道具 举报

千问 | 2005-4-26 14:47:45 | 显示全部楼层
可不一定。
回复

使用道具 举报

千问 | 2005-4-26 14:47:45 | 显示全部楼层
肯定了,事实明摆着, 那么多的日志
回复

使用道具 举报

千问 | 2005-4-26 14:47:45 | 显示全部楼层
1.先看看alert.log文件,看看日志文件切换的频率和时间
2.使用logminer对这段时间产生的归档日志进行分析,看看在这段时间内数据库到底做了什么?
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行