oracle dg switchover,DG Switchover fails
发布日期:2025-04-29 11:25:16 浏览次数:13 分类:精选文章

本文共 2237 字,大约阅读时间需要 7 分钟。

Transport between the New Primary and the New Standby Appears to Be Malfunctioning

I noticed that transport functionality between the newly implemented primary and standby databases is not working as expected. Just recently, I conducted a switchover test on my system, and the same issue arose.

Running the following command:

/home/oracle:STANDBY > dgmgrl

The output indicated that DGMGRL for Linux, Version 12.1.0.2.0 - 64bit Production, was successfully connected. After connecting as SYSDG, the following validation was performed:

DGMGRL> validate database 'standby'  Database Role: Physical standby database  Primary Database: PRIMARY  Readiness Status: Ready for Switchover: Yes  Readiness Status: Ready for Failover: Yes (Primary Running)  Flashback Database Status:  PRIMARY: On  standby: Off

The log file group configuration was also checked, revealing the following:

  • Primary Database: 1 online redo log group, 3 standby redo log groups, status: Insufficient SRLs
  • Standby Database: 1 online redo log group, 3 standby redo log groups, status: Insufficient SRLs

Furthermore, the transport-related property settings indicated that log shipping was enabled on the standby but turned off on the primary. This discrepancy could be a critical issue.

After executing the switchover command:

DGMGRL> switchover to STANDBY
The operation was completed successfully, and the new primary database was established as "standby."

However, upon reviewing the alert logs, I noticed that archive actions were not properly reflected on the new primary. The logs indicated that the following files were involved:

  • /u01/app/oracle/flash_recovery_area/PRIMARY/archivelog/2017_02_08/o1_mf_1_1066_d9pym311_.arc
  • /u01/app/oracle/flash_recovery_area/PRIMARY/archivelog/2017_02_08/o1_mf_1_1067_d9pyns7o_.arc

It's essential to verify the following:

  • Ensure that the Flash Recovery Area (FRA) is sufficiently sized on both the primary and standby databases.
  • Confirm that archive logs are being correctly applied on the new primary database.
  • Review the alert logs on the new standby database for any additional clues or errors related to archive operations.
  • If the FRA is insufficient, consider increasing its size to accommodate the necessary recovery processes.

    上一篇:Oracle E-Business Suite软件 任意文件上传漏洞(CVE-2022-21587)
    下一篇:Oracle dbms_job.submit参数错误导致问题(ora-12011 无法执行1作业)

    发表评论

    最新留言

    不错!
    [***.144.177.141]2026年05月30日 21时35分24秒

    关于作者

        喝酒易醉,品茶养心,人生如梦,品茶悟道,何以解忧?唯有杜康!
    -- 愿君每日到此一游!

    推荐文章