记一次Oracle归档日志异常增长问题的排查过程 |
您所在的位置：网站首页 › 乡愁是几年级的课文人教版 › 记一次Oracle归档日志异常增长问题的排查过程 |
|
Oracle归档日志是Oracle数据库的重要功能，用于将数据库的重做日志文件（Redo Log）保存到归档日志文件（Archive Log）中。归档日志的作用是提供数据库的备份和恢复功能，以及支持数据库的持续性和数据完整性。 当数据库处于归档模式时，数据库引擎会将已经写满的重做日志文件保存到归档日志文件中，而不是覆盖已有的重做日志。这样可以确保数据库的完整性，并且可以使用归档日志文件进行数据库的恢复操作。 归档日志对于数据库的备份和恢复非常重要。通过定期备份归档日志文件，可以保证数据库在发生故障时能够进行恢复。同时，归档日志还允许将数据库恢复到特定的时间点，以满足特定业务需求。 基础操作在Oracle数据库中，可以通过以下步骤来设置和查看归档日志空间： 首先，确认数据库是否处于归档模式。可以通过以下SQL语句查询： SQL> SELECT log_mode FROM v$database; LOG_MODE ARCHIVELOG如果log_mode的值为ARCHIVELOG，则数据库处于归档模式；如果值为NOARCHIVELOG，则数据库未启用归档模式。 如果数据库未启用归档模式，可以通过以下SQL语句将其切换到归档模式： 修改归档模式的操作只能在 mount 状态下进行，不能处于 open 状态 SQL> shutdown immediate 数据库已经关闭。 已经卸载数据库。 ORACLE 例程已经关闭。 SQL> startup mount ORACLE 例程已经启动。 Total System Global Area 3290345472 bytes Fixed Size 2180224 bytes Variable Size 2382367616 bytes Database Buffers 889192448 bytes Redo Buffers 16605184 bytes 数据库装载完毕。 SQL> alter database archivelog; 数据库已更改。 SQL> alter database open; 数据库已更改。 确认数据库已切换到归档模式后，可以设置归档日志空间的大小。可以通过以下SQL语句设置归档日志空间的大小为50MB（根据需求进行调整）： 52428800 = 50 * 1024 * 1024 SQL> alter system set db_recovery_file_dest_size= 52428800; 系统已更改。 使用以下SQL语句查询当前归档日志空间的使用情况： select name, space_limit / 1024 / 1024 / 1024 || 'GB' as 空间限制, space_used / 1024 / 1024 / 1024 || 'GB' 已使用 from v$recovery_file_dest这将显示归档日志目标的名称、空间限制和已使用的空间。 问题发生下面进入对一次因归档日志空间占满，导致系统停止服务的故障在某个阳光明媚的周末发生后的处理过程。 系统停止响应，数据库登录有以下提示： ORA-00257:archiver error. Connect internal only,until freed 很明显，归档日志满了，立即删除归档日志，保留最近3天。 rman RMAN> connect target 用户名/密码; 连接到目标数据库: ORCL (DBID=1616110362) RMAN> delete archivelog until time 'sysdate-3'; 问题未解决，查看归档空间占用情况。 select name, space_limit / 1024 / 1024 / 1024 || 'GB' as 空间限制, space_used / 1024 / 1024 / 1024 || 'GB' 已使用 from v$recovery_file_dest 发现占用空间未释放，接着删除所有归档： RMAN> delete archivelog all; 系统恢复。过了几个小时，问题再次发生。再次删除所有归档日志，系统恢复，开始排查问题原因。 排查过程 按天统计 select to_char(COMPLETION_TIME, 'yyyymmdd'), count(*) from v$archived_log t where COMPLETION_TIME > sysdate - 7 group by to_char(COMPLETION_TIME, 'yyyymmdd') order by to_char(COMPLETION_TIME, 'yyyymmdd');这是一个查询语句，用于查询过去7天内完成的归档日志数量，并按照日期进行分组和排序。 发现前6天正常，当天归档日志异常增长。 2. 按小时统计 select to_char(FIRST_TIME, 'yyyymmddhh24'), count(*) from sys.v_$archived_log t where t.FIRST_TIME > trunc(sysdate) group by to_char(FIRST_TIME, 'yyyymmddhh24') order by to_char(FIRST_TIME, 'yyyymmddhh24')该SQL用于查询当天开始的归档日志数量，并按照小时进行分组和排序。 3. 按天和小时综合统计 SELECT TO_CHAR(FIRST_TIME,'YYYY-MM-DD') DAY, TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'00',1,0)),'999') "00", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'01',1,0)),'999') "01", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'02',1,0)),'999') "02", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'03',1,0)),'999') "03", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'04',1,0)),'999') "04", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'05',1,0)),'999') "05", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'06',1,0)),'999') "06", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'07',1,0)),'999') "07", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'08',1,0)),'999') "08", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'09',1,0)),'999') "09", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'10',1,0)),'999') "10", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'11',1,0)),'999') "11", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'12',1,0)),'999') "12", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'13',1,0)),'999') "13", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'14',1,0)),'999') "14", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'15',1,0)),'999') "15", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'16',1,0)),'999') "16", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'17',1,0)),'999') "17", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'18',1,0)),'999') "18", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'19',1,0)),'999') "19", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'20',1,0)),'999') "20", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'21',1,0)),'999') "21", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'22',1,0)),'999') "22", TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'23',1,0)),'999') "23" FROM V$LOG_HISTORY GROUP BY TO_CHAR(FIRST_TIME,'YYYY-MM-DD') ORDER BY 1 DESC;此SQL语句，用于统计每天每个小时的日志数量，并按照日期倒序排序 3. 根据按小时统计分析，发现归档日志集中在当天2个时间段，其他时间段基本正常。怀疑是在相关时间自动执行的后台任务造成，经深入排查予以否认。 4. AWR报告生成 sqlplus /nolog conn / as sysdba @?/rdbms/admin/awrrpt.sql报告生成失败，原因是没有快照（Snap） 5. 分析没有快照（Snap）原因，网上说一般是SYSAUX表空间不足造成的，查询表空间占用情况，果然满了 6. 清理表空间 select distinct 'truncate table ' || segment_name || ';', s.bytes / 1024 / 1024 MB from dba_segments s where s.segment_name like 'WRH$%' and segment_type in ('TABLE PARTITION', 'TABLE') and s.bytes / 1024 / 1024 > 100 order by s.bytes / 1024 / 1024 desc;此SQL可生成清理以 ‘WRH$’ 开头的、大于100MB的表的SQL。生成后执行，完成表空间清理。 问题解决，真是阴差阳错。猜测的原因： 因SYSAUX表空间满，造成连锁反应，表现为归档日志异常增长。 一般情况分析归档日志增长一般是DML操作大量数据造成的，而由SYSAUX表空间满的原因所造成的则比较少见，故记之。 排查归档日志暴增的方法，一般包括以下三个手段： SQL语句AWR挖掘归档日志本文到此结束，感谢您的观看！！！ |
今日新闻 |
推荐新闻 |
| CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |