记一次Oracle归档日志异常增长问题的排查过程

这篇具有很好参考价值的文章主要介绍了记一次Oracle归档日志异常增长问题的排查过程。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Oracle归档日志是Oracle数据库的重要功能,用于将数据库的重做日志文件(Redo Log)保存到归档日志文件(Archive Log)中。归档日志的作用是提供数据库的备份和恢复功能,以及支持数据库的持续性和数据完整性。
当数据库处于归档模式时,数据库引擎会将已经写满的重做日志文件保存到归档日志文件中,而不是覆盖已有的重做日志。这样可以确保数据库的完整性,并且可以使用归档日志文件进行数据库的恢复操作。
归档日志对于数据库的备份和恢复非常重要。通过定期备份归档日志文件,可以保证数据库在发生故障时能够进行恢复。同时,归档日志还允许将数据库恢复到特定的时间点,以满足特定业务需求。

基础操作

在Oracle数据库中,可以通过以下步骤来设置和查看归档日志空间:

  1. 首先,确认数据库是否处于归档模式。可以通过以下SQL语句查询:
SQL> SELECT log_mode FROM v$database;
LOG_MODE
  ARCHIVELOG

如果log_mode的值为ARCHIVELOG,则数据库处于归档模式;如果值为NOARCHIVELOG,则数据库未启用归档模式。

  1. 如果数据库未启用归档模式,可以通过以下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;
数据库已更改。
  1. 确认数据库已切换到归档模式后,可以设置归档日志空间的大小。可以通过以下SQL语句设置归档日志空间的大小为50MB(根据需求进行调整):
    52428800 = 50 * 1024 * 1024
SQL> alter system set db_recovery_file_dest_size=  52428800;
系统已更改。
  1. 使用以下SQL语句查询当前归档日志空间的使用情况:
select name,
       space_limit / 1024 / 1024 / 1024 || 'GB' as 空间限制,
       space_used / 1024 / 1024 / 1024 || 'GB' 已使用
  from v$recovery_file_dest

这将显示归档日志目标的名称、空间限制和已使用的空间。

问题发生

下面进入对一次因归档日志空间占满,导致系统停止服务的故障在某个阳光明媚的周末发生后的处理过程。

  1. 系统停止响应,数据库登录有以下提示:
ORA-00257:archiver error. Connect internal only,until freed
  1. 很明显,归档日志满了,立即删除归档日志,保留最近3天。
rman
RMAN> connect target 用户名/密码;
连接到目标数据库: ORCL (DBID=1616110362)
RMAN> delete archivelog until time 'sysdate-3';
  1. 问题未解决,查看归档空间占用情况。
select name,
       space_limit / 1024 / 1024 / 1024 || 'GB' as 空间限制,
       space_used / 1024 / 1024 / 1024 || 'GB' 已使用
  from v$recovery_file_dest
  1. 发现占用空间未释放,接着删除所有归档:
RMAN> delete archivelog all;
  1. 系统恢复。过了几个小时,问题再次发生。
  2. 再次删除所有归档日志,系统恢复,开始排查问题原因。

排查过程

  1. 按天统计
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。生成后执行,完成表空间清理。

  1. 问题解决,真是阴差阳错。

猜测的原因:
因SYSAUX表空间满,造成连锁反应,表现为归档日志异常增长。

一般情况分析

归档日志增长一般是DML操作大量数据造成的,而由SYSAUX表空间满的原因所造成的则比较少见,故记之。

排查归档日志暴增的方法,一般包括以下三个手段:

  1. SQL语句
  2. AWR
  3. 挖掘归档日志

本文到此结束,感谢您的观看!!!文章来源地址https://www.toymoban.com/news/detail-622618.html

到了这里,关于记一次Oracle归档日志异常增长问题的排查过程的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 记一次Apache HTTP Client问题排查

    通过日志查看,存在两种异常情况。 第一种:开始的时候HTTP请求会报超时异常。 762663363 [2023-07-21 06:04:25] [executor-64] ERROR - com.xxl.CucmTool - CucmTool|sendRisPortSoap error,url:https://xxxxxx/realtimeservice/services/RisPort org.apache.http.conn.HttpHostConnectException: Connect to xxx [/xxx] failed: 连接超时 第二种

    2024年02月12日
    浏览(49)
  • 记一次jedis连接池顽固问题排查与修改

    这辈子不想再看到jedisBrokenPipe!!   测试环境运行16天后报错信息: 05:42:32.629 [http-nio-8093-exec-2] ERROR o.a.c.c.C.[.[.[.[dispatcherServlet] - [log,175] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is redis.clients.jedis.exceptions.JedisCon

    2023年04月21日
    浏览(45)
  • ORACLE 10G版本数据库系统产生大量归档日志问题的分析

    近期接到用户告知 数据库归档暴增,导致生产库归档空间满,手动删除后,归档空间很快就会满。 立即登陆数据库系统,查询发现归档日志异常增长,从以前的每小时产生3 00M ,增长到每小时产生5 9150M 。拉取问题时段的A WR 报告,将问题S QL 提交给应用运维人员,应用修复

    2024年02月03日
    浏览(34)
  • 记一次 .Net+SqlSugar 查询超时的问题排查过程

    环境和版本:.Net 6 + SqlSuger 5.1.4.*   ,数据库是mysql 5.7 ,数据量在2000多条左右 业务是一个非常简单的查询,代码如下: tb_name 下配置了一对多的关系导航,但是执行时没有include导航属性,当执行上述代码时,查询非常慢,甚至会超时报错: The Command Timeout expired before the o

    2024年02月07日
    浏览(34)
  • 记一次 MySQL timestamp 精度问题的排查 → 过程有点曲折

    下午正准备出门,跟正刷着手机的老妈打个招呼 我:妈,今晚我跟朋友在外面吃,就不在家吃了 老妈拿着手机跟我说道:你看这叫朋友骗缅北去了,tm血都抽干了,多危险 我:那是他不行,你看要是吴京去了指定能跑回来 老妈:还吴京八经的,特么牛魔王去了都得耕地,唐

    2024年02月01日
    浏览(43)
  • 记一次MySQL5初始化被kill的问题排查

    由于测试环境JED申请比较繁琐,所以Eone提供了单机版Mysql供用户使用,近期Eone搭建Mysql5的时候发现莫名被kill了,容器规格是4C8G,磁盘30G 这不科学,之前都是可以的,镜像没变,配置没变,咋就不行了呢,一定不是我的问题,是机器的问题 通过多次搭建mysql5进行采样,发现

    2024年02月08日
    浏览(36)
  • 记一次 Redisson 线上问题 → ERR unknown command 'WAIT' 的排查与分析

    昨晚和一个朋友聊天 我:处对象吗,咱俩试试? 朋友:我有对象 我:我不信,有对象不公开? 朋友:不好公开,我当的小三 程序在生产环境稳定的跑着 直到有一天,公司执行组件漏洞扫描,有漏洞的  jar  要进行升级修复 然后我就按着扫描报告将有漏洞的  jar  修复到指

    2024年02月09日
    浏览(43)
  • 记一次 RestTemplate 请求失败问题的排查 → RestTemplate 默认会对特殊字符进行转义

    今天中午,侄子在沙发上玩手机,他妹妹屁颠屁颠的跑到他面前 小侄女:哥哥,给我一块钱 侄子:叫妈给你 小侄女朝着侄子,毫不犹豫的叫到:妈! 侄子:不是,叫妈妈给你 小侄女继续朝他叫到:妈妈 侄子受不了,从兜里掏出一块钱说道:我就只有这一块钱了,拿去拿去

    2024年02月05日
    浏览(40)
  • 一次日志配置未生效问题排查记录

    某天排查业务问题时,在我司的日志收集平台上,未能发现相关业务服务接口访问日志。经过和相关同事确定,发现业务服务未能将接口访问日志吐到日志收集平台,由此开启一段有点漫长的排查之旅。 业务服务是典型的SpringBoot web应用,日志记录采用slf4j+log4j2组合。 通过applica

    2024年02月11日
    浏览(31)
  • 好文分享 | 记一次Oracle12c数据库SQL短暂缓慢问题分析

    本文为墨天轮社区作者 张sir 原创作品,记录了日常运维Oracle数据库过程中遇到的一个慢SQL问题的解决、优化过程,文章内容全面具体、分析到位,且含有经验总结,分享给各位。 这次出问题的数据库比较特殊,承接的系统交易要求很高,SQL基本都是短平快,响应时间基本不

    2024年02月05日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包