记一次Oracle 归档进程卡死怎么去有效排查

发布时间:2026/10/30 4:57:59
记一次Oracle 归档进程卡死怎么去有效排查 目录一、快速判断与根本原因第一步检查 ASM 磁盘组剩余空间如果是 ASM 归档第二步检查归档目标状态与错误信息第三步检查 FRA快速恢复区与 ASM 磁盘组第四步确认归档进程状态第五步检查数据库运行日志最有力的证据二、应急处理与恢复2.1.清理过期归档2.2.验证恢复问题复现[gridhost03 ~]$ crsctl status resource -t--------------------------------------------------------------------------------Name Target State Server State details--------------------------------------------------------------------------------Local Resources--------------------------------------------------------------------------------ora.LISTENER.lsnrONLINE ONLINE host03 STABLEONLINE ONLINE host04 STABLEora.chadONLINE ONLINE host03 STABLEONLINE ONLINE host04 STABLEora.helperOFFLINE OFFLINE host03 IDLE,STABLEOFFLINE OFFLINE host04 STABLEora.net1.networkONLINE ONLINE host03 STABLEONLINE ONLINE host04 STABLEora.onsONLINE ONLINE host03 STABLEONLINE ONLINE host04 STABLEora.proxy_advmOFFLINE OFFLINE host03 STABLEOFFLINE OFFLINE host04 STABLE--------------------------------------------------------------------------------Cluster Resources--------------------------------------------------------------------------------ora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup)1 ONLINE ONLINE host03 STABLE2 ONLINE ONLINE host04 STABLEora.ASMNET2LSNR_ASM.lsnr(ora.asmgroup)1 ONLINE ONLINE host03 STABLE2 ONLINE ONLINE host04 STABLEora.DGDATA.dg(ora.asmgroup)1 ONLINE ONLINE host03 STABLE2 ONLINE ONLINE host04 STABLEora.DGMGMT.dg(ora.asmgroup)1 ONLINE ONLINE host03 STABLE2 ONLINE ONLINE host04 STABLEora.LISTENER_SCAN1.lsnr1 ONLINE ONLINE host03 STABLEora.LISTENER_SCAN2.lsnr1 ONLINE ONLINE host04 STABLEora.LISTENER_SCAN3.lsnr1 ONLINE ONLINE host04 STABLEora.MGMTLSNR1 ONLINE ONLINE host03 169.254.0.152 172.27.1.100 172.27.2.100,STABLEora.asm(ora.asmgroup)1 ONLINE ONLINE host03 Started,STABLE2 ONLINE ONLINE host04 Started,STABLEora.asmnet1.asmnetwork(ora.asmgroup)1 ONLINE ONLINE host03 STABLE2 ONLINE ONLINE host04 STABLEora.asmnet2.asmnetwork(ora.asmgroup)1 ONLINE ONLINE host03 STABLE2 ONLINE ONLINE host04 STABLEora.cvu1 ONLINE ONLINE host04 STABLEora.gns1 ONLINE ONLINE host04 STABLEora.gns.vip1 ONLINE ONLINE host04 STABLEora.host03.vip1 ONLINE ONLINE host03 STABLEora.host04.vip1 ONLINE ONLINE host04 STABLEora.mgmtdb1 ONLINE ONLINE host03 Open,STABLEora.orcl.db1 ONLINE INTERMEDIATE host04 Stuck Archiver,HOME/u01/app/oracle/product/19.3.0/dbhome_1,STABLE2 ONLINE INTERMEDIATE host03 Stuck Archiver,HOME/u01/app/oracle/product/19.3.0/dbhome_1,STABLEora.qosmserver1 ONLINE ONLINE host04 STABLEora.rhpserver1 OFFLINE OFFLINE STABLEora.scan1.vip1 ONLINE ONLINE host03 STABLEora.scan2.vip1 ONLINE ONLINE host04 STABLEora.scan3.vip1 ONLINE ONLINE host04 STABLE--------------------------------------------------------------------------------[gridhost03 ~]$核心问题很明确ora.orcl.db 的两个实例host03、host04状态均为 INTERMEDIATE且详细描述为 Stuck Archiver。这表示归档进程ARCn无法将联机重做日志写出导致日志切换阻塞进而使数据库实例处于挂起或半挂起状态。我们之前有处理过这问题记一次Oracle集群归档日志爆满之后如何处理涉及ASM磁盘的增添。有坑必踩_oracle归档日志满了如何处理-CSDN博客一、快速判断与根本原因Stuck Archiver的直接诱因通常是归档目标空间耗尽或归档路径不可写。在 RAC 环境中单个节点归档失败就可能拖累整个集群因为 LGWR 进程必须等待归档完成才能复用重做日志。结合实际的环境排查应优先聚焦在归档空间上。请按顺序执行以下只读检查快速定位是“真满了”还是“逻辑配额满了”。第一步检查 ASM 磁盘组剩余空间如果是 ASM 归档如果归档路径指向 ASM必须用 asmcmd lsdg 确认底层磁盘组是否还有真实可用空间。注意db_recovery_file_dest_size调大并不代表 ASM 磁盘组有空间底层满了照样报错。就像1.2章节即使逻辑空间上限是充足的。但底层空间将满归档依然不能写入到磁盘中导致归档进程异常。其实上图就已经能基本判断为归档空间饱满所致。第二步检查归档目标状态与错误信息以 oracle 用户登录任一实例查询归档目标状态。ERROR 列通常会直接给出线索如空间不足、权限问题。set lines 400; column destination format a50; SELECT DEST_ID, STATUS, DESTINATION, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE STATUS ! INACTIVE;附加问题归档路径配置错误。ora.orcl.db 的归档目标指向了本地文件系统路径 /u01/app/oracle/product/19.3.0/dbhome_1/dbs/arch而非 RAC 环境必需的共享存储ASM。该路径无法被 oracle 用户写入导致 ORA-19504: failed to create file 进而使 ARCn 进程卡住。假如我们把先把目录创建并修改目录权限看是否能通过修改进行解决可以看到并不能解决因为数据库的 LOG_ARCHIIVE_DEST_1 参数没有更新或者参数更新了但 RAC 的另一节点未同步生效ARCn 进程仍然会因为无法写入或路径配置未真正生效而卡住。强制切换日志也失败继续下边的排查这里有点奇怪暂时不知道什么原因也许是之前的双节点配置不一致一个显示配置路径一个使用闪回区的位置。也许吧第三步检查 FRA快速恢复区与 ASM 磁盘组Stuck Archivelog最常见的原因是归档空间满前面已经基本证实。下边我们需同时检查 Oracle 内部限额和底层存储的真实剩余空间。如果归档在 FRA闪回区文件系统查 v$recovery_file_dest看 space_used是否逼近 space_limit且 space_reclaimable 为 0 或极低。SELECT NAME, SPACE_LIMIT/1073741824 AS LIMIT_GB, SPACE_USED/1073741824 AS USED_GB, SPACE_RECLAIMABLE/1073741824 AS RECLAIM_GB FROM V$RECOVERY_FILE_DEST;可以看到FRA 配置为 DGDATA限额 16GB已用约 3GB可回收约 0.05GB。这样看起来感觉感觉空间还蛮多但是还需结合下面来进行判断。我们环境中归档存放在 ASM 磁盘组环境中有 DGDATA、DGMGMT归档很可能也在 ASM以 grid 用户执行 asmcmd lsdg查看对应归档磁盘组如 ARCH 或 DATA 中的归档目录的 Free_MB。若 Free_MB 极小或为 0即为存储层写满。asmcmd lsdg 输出揭示了一个关键且危险的新情况DGDATA 磁盘组的 Usable_file_MB 为 -1604。这意味着虽然 DGDATA 还有 888MB 的物理剩余空间Free_MB但这个空间不足以在磁盘故障后安全地恢复冗余。对于 NORMAL 冗余的磁盘组Usable_file_MB 为负值表示磁盘组已经处于“不安全”状态任何一块磁盘的故障都可能导致数据丢失或冗余降级。第四步确认归档进程状态查看 v$ARCHIVE_PROCESSES正常情况下 STATE 应为 IDLE 或 BUSY。若状态异常说明 ARCn 进程本身有问题。命令SELECT PROCESS, STATUS, STATE, LOG_SEQUENCE FROM V$ARCHIVE_PROCESSES;第五步检查数据库运行日志最有力的证据有力的证据就是结合看数据库的运行日志数据库告警日志Alert Log。从 Oracle 11g 开始日志统一由 ADR自动诊断库管理路径有规律可循但最准确的方式是直接查数据库。通用路径规律$ORACLE_BASE/diag/rdbms/db_name/SID/trace/alert_SID.log查询语句SELECT value FROM v$diag_info WHERE name Diag Trace;日志目录我当前的测试环境/u01/app/oracle/diag/rdbms/orcl/orcl1/trace二、应急处理与恢复在确认是空间问题后首要任务是释放空间让归档恢复实例才能从 INTERMEDIATE 回到ONLINE。这里我们由于是测试环境我们之前有专门讲过如何添加ASM磁盘组成员来扩容磁盘组来进行容量问题。记一次Oracle集群归档日志爆满之后如何处理涉及ASM磁盘的增添。有坑必踩_oracle归档日志满了如何处理-CSDN博客2.1.清理过期归档使用 RMAN 删除旧归档。注意在 RAC 中建议在每个节点分别连接本地实例执行避免并发冲突。# 在 host03 上 export ORACLE_SIDorcl1 rman target / RMAN DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE SYSDATE-2;2.2.验证恢复检查归档进程状态下图是我已经清理归档之后的状态空间释放后手动切换日志并观察 alert log看归档是否成功。ALTER SYSTEM ARCHIVE LOG CURRENT;随后再次执行 crsctl status resource -t观察 ora.orcl.db 的 STATE 是否变为 ONLINE,Stuck Archiver描述是否消失。[gridhost03 ~]$ crsctl status resource -t -------------------------------------------------------------------------------- Name Target State Server State details -------------------------------------------------------------------------------- Local Resources -------------------------------------------------------------------------------- ora.LISTENER.lsnr ONLINE ONLINE host03 STABLE ONLINE ONLINE host04 STABLE ora.chad ONLINE ONLINE host03 STABLE ONLINE ONLINE host04 STABLE ora.helper OFFLINE OFFLINE host03 IDLE,STABLE OFFLINE OFFLINE host04 STABLE ora.net1.network ONLINE ONLINE host03 STABLE ONLINE ONLINE host04 STABLE ora.ons ONLINE ONLINE host03 STABLE ONLINE ONLINE host04 STABLE ora.proxy_advm OFFLINE OFFLINE host03 STABLE OFFLINE OFFLINE host04 STABLE -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup) 1 ONLINE ONLINE host03 STABLE 2 ONLINE ONLINE host04 STABLE ora.ASMNET2LSNR_ASM.lsnr(ora.asmgroup) 1 ONLINE ONLINE host03 STABLE 2 ONLINE ONLINE host04 STABLE ora.DGDATA.dg(ora.asmgroup) 1 ONLINE ONLINE host03 STABLE 2 ONLINE ONLINE host04 STABLE ora.DGMGMT.dg(ora.asmgroup) 1 ONLINE ONLINE host03 STABLE 2 ONLINE ONLINE host04 STABLE ora.LISTENER_SCAN1.lsnr 1 ONLINE ONLINE host03 STABLE ora.LISTENER_SCAN2.lsnr 1 ONLINE ONLINE host04 STABLE ora.LISTENER_SCAN3.lsnr 1 ONLINE ONLINE host04 STABLE ora.MGMTLSNR 1 ONLINE ONLINE host03 169.254.0.152 172.27 .1.100 172.27.2.100, STABLE ora.asm(ora.asmgroup) 1 ONLINE ONLINE host03 Started,STABLE 2 ONLINE ONLINE host04 Started,STABLE ora.asmnet1.asmnetwork(ora.asmgroup) 1 ONLINE ONLINE host03 STABLE 2 ONLINE ONLINE host04 STABLE ora.asmnet2.asmnetwork(ora.asmgroup) 1 ONLINE ONLINE host03 STABLE 2 ONLINE ONLINE host04 STABLE ora.cvu 1 ONLINE ONLINE host04 STABLE ora.gns 1 ONLINE ONLINE host04 STABLE ora.gns.vip 1 ONLINE ONLINE host04 STABLE ora.host03.vip 1 ONLINE ONLINE host03 STABLE ora.host04.vip 1 ONLINE ONLINE host04 STABLE ora.mgmtdb 1 ONLINE ONLINE host03 Open,STABLE ora.orcl.db 1 ONLINE ONLINE host04 Open,HOME/u01/app/o racle/product/19.3.0 /dbhome_1,STABLE 2 ONLINE ONLINE host03 Open,HOME/u01/app/o racle/product/19.3.0 /dbhome_1,STABLE ora.qosmserver 1 ONLINE ONLINE host04 STABLE ora.rhpserver 1 OFFLINE OFFLINE STABLE ora.scan1.vip 1 ONLINE ONLINE host03 STABLE ora.scan2.vip 1 ONLINE ONLINE host04 STABLE ora.scan3.vip 1 ONLINE ONLINE host04 STABLE -------------------------------------------------------------------------------- [gridhost03 ~]$

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询