{"id":2369,"date":"2026-02-26T17:40:17","date_gmt":"2026-02-26T15:40:17","guid":{"rendered":"https:\/\/www.ludovicocaldara.net\/dba\/?p=2369"},"modified":"2026-02-26T17:40:17","modified_gmt":"2026-02-26T15:40:17","slug":"dg26ai-strict-database-validation","status":"publish","type":"post","link":"https:\/\/www.ludovicocaldara.net\/dba\/dg26ai-strict-database-validation\/","title":{"rendered":"Data Guard 26ai – #20: Strict database validation"},"content":{"rendered":"

This post is part of a blog series.<\/a><\/p>\n

Monitoring your Data Guard configuration is essential to ensure your database remains healthy. The Data Guard broker includes a VALIDATE DATABASE<\/a> command which assesses the system\u2019s health and determines its readiness for switchover or failover.
\nUp to 21c, this command checks technical readiness for these operations and confirms whether they are likely to succeed. However, some misconfigurations, such as disabled flashback logging or offline PDBs, might not cause immediate failures but still present risks of data loss or other operational issues.
\nFor example, if flashback logging is disabled, a failover would require reinstating the former primary. If there are offline PDBs on the standby database, perhaps because the primary was cloned without copying over the data files, these PDBs would not be available after a failover. This situation could cause data loss. Other issues may not block a switchover, yet still lead to unwanted results.
\nOracle Data Guard 26ai introduces strict database validation. This feature marks a database as not ready for switchover or failover if any advanced checks fail.<\/p>\n

\"Syntax<\/a>Strict validation checks include:<\/p>\n