This post is part of a blog series.

Another small but useful addition in Data Guard 26ai is a set of new columns in V$FS_FAILOVER_OBSERVERS:

• LAST_PING_PRIMARY
• LAST_PING_TARGET
• LOG_FILE
• STATE_FILE
• CURRENT_TIME

These columns give a bit more visibility into observer activity and configuration, which can help when checking Fast-Start Failover health or troubleshooting connectivity issues.

A simple query shows them:

This is particularly useful when there are multiple observers:

• if LAST_PING_PRIMARY increases, that observer may no longer be reaching the primary
• if LAST_PING_TARGET increases, the connectivity issue may be on the standby side
• if both increase, that observer may have lost connectivity more broadly
• LOG_FILE shows the path of the observer log file in use. Depending on your standards (or lack of), the location is not always the same.
• STATE_FILE shows the path of the observer state file
• CURRENT_TIME shows the time of the last update to the view

Overall, this is not a major feature, but it is a nice diagnostic improvement in 26ai and makes V$FS_FAILOVER_OBSERVERS a bit more informative.

This post is part of a blog series.

Oracle Database 26ai introduces V$FS_LAG_HISTOGRAM, a new view that exposes the distribution of Fast-Start Failover (FSFO) lag.

When FSFO is configured (including observe-only mode), it samples the lag every minute, and puts it into buckets to count how often each range occurs. The buckets can be queried from this new view:

Where:

• LAG_TIME: upper bound of the bucket
• LAG_COUNT: number of occurrences
• LAST_UPDATE_TIME: most recent occurrence

So:

• 5 → 0–5 seconds
• 10 → 5–10 seconds
• 15 → 10–15 seconds

This view is particularly useful to tune FastStartFailoverLagLimit in Maximum Performance mode (ASYNC replication).

Why this matters:

Instead of relying on point-in-time lag or implementing external monitoring (which is still a good idea), you can analyze the actual distribution and choose a value that reflects your RPO: failover will not occur if lag exceeds this limit.

How to set the FastStartFailoverLagLimit based on the buckets

Use the histogram to understand the typical and peak lag behavior, then set FastStartFailoverLagLimit:

• Slightly above your normal/daily peak lag (if any)
• In line with your acceptable data-loss window (RPO)
• Less than or equal to FastStartFailoverThreshold

With proper setting, failovers are not unnecessarily prevented, while still respecting your data protection requirements.

This post is part of a blog series.

I hope you’ve caught the pattern from previous posts: with Oracle AI Database 26ai we made a big effort in improving the management of Data Guard configurations directly from SQL. Similar to the fixed view for broker properties, a similar enhancement is available for Fast-Start Failover (FSFO).

Before 26ai, if you wanted to inspect Fast-Start Failover settings, you had to rely on the broker command:

Starting with Oracle 26ai, you can now query the new fixed view V$FAST_START_FAILOVER_CONFIG that exposes FSFO configuration details.

This provides direct access to FSFO configuration using standard SQL, making automation and observability much simpler.

Deprecation of V$DATABASE.FS_FAILOVER_* Columns

Some FSFO-related information was historically exposed via columns in V$DATABASE, such as:

• FS_FAILOVER_MODE
• FS_FAILOVER_STATUS
• FS_FAILOVER_CURRENT_TARGET
• FS_FAILOVER_THRESHOLD
• FS_FAILOVER_OBSERVER_PRESENT
• FS_FAILOVER_OBSERVER_HOST

This information doesn’t really belong there.

In Oracle 26ai, these columns are deprecated and will be desupported in a future release.

If you are currently relying on these columns, you should transition to the new view.

Here is how the deprecated V$DATABASE columns map to the new V$FAST_START_FAILOVER_CONFIG view:

V$FAST_START_FAILOVER also include these additional columns:

• PING_INTERVAL
• PING_RETRY
• PROTECTION_MODE
• LAG_LIMIT
• AUTO_REINSTATE
• OBSERVER_RECONNECT
• OBSERVER_OVERRIDE
• SHUTDOWN_PRIMARY
• LAG_TYPE
• LAG_GRACE_TIME

Once again, a 26ai feature that improves configuration and automation of Data Guard environments.

This post is part of a blog series.

Each Oracle release makes setup easier, but configuring naming resolution and authentication for Data Guard is still a challenging step. Editing files like tnsnames.ora and sqlnet.ora remains tedious, even with LDAP (recommended) or EZConnect. Automation tools like Puppet, Ansible, or cloud solutions help, but aren’t always in place.

For Data Guard, accurate naming resolution and authentication are crucial for successful broker connections. The DGConnectIdentifier property defines the main connection string.

Data Guard 26ai introduces the VALIDATE DGConnectIdentifier command, which tests connectivity, including credentials, from each instance to every member.

This proactive check helps you avoid errors like ORA-01017 and ORA-12514 during operations such as SWITCHOVER. Unlike earlier manual sqlplus checks, this command verifies connections using the actual database environment, offering true validation from the connecting database.

This post is part of a blog series.

Previously, the only supported way to view broker properties for members or configurations was by running the DGMGRL SHOW DATABASE or SHOW CONFIGURATION commands. These commands made it difficult to gather all properties for every member or to check for inconsistencies. Monitoring required manual parsing of the output, and there was no direct SQL option.

With Data Guard 26ai, you can now use the new V$DG_BROKER_PROPERTY view.

This lets you easily query all broker properties for each member or for the whole configuration, using familiar SQL tools.

This post is part of a blog series.

Data Guard 26ai introduces a new fixed view, V$DG_BROKER_ROLE_CHANGE, which tracks the last ten role transitions for a configuration. This view gathers information dynamically from the broker configuration file, logging both automatic and manual failovers (with reasons), switchovers, and each operation’s start and end times. We plan to add recovery point SCN details in a future Release Update, but this isn’t available yet.

This view makes it easy to see recent role changes without searching through alert logs. It also helps identify what was the primary database at any given moment. The view stores only the ten most recent role changes; to keep a longer history, you can copy its records into a regular table; for example, using a STARTUP trigger on the primary database.

This post is part of a blog series.

Until now, checking whether a database was ready to switch over or fail over meant running the VALIDATE DATABASE command through DGMGRL: there was no direct SQL alternative, and the VALIDATE DATABASE command isn’t available with other broker interfaces.

In Data Guard 26ai, the V$DG_BROKER_CONFIG view now includes two new columns: SWITCHOVER_READY and FAILOVER_READY. These columns, updated every minute by the Data Guard Broker’s health check, provide the status for switchover and failover readiness.

This means you can now monitor configuration topology, member status, and role change readiness directly with a SQL query, streamlining observability and monitoring through any SQL*Net client, without relying on DGMGRL.

For now, if either column shows “NO”, you still need DGMGRL for detailed diagnostics.

This post is part of a blog series.

Monitoring your Data Guard configuration is essential to ensure your database remains healthy. The Data Guard broker includes a VALIDATE DATABASE command which assesses the system’s health and determines its readiness for switchover or failover.
Up 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.
For 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.
Oracle Data Guard 26ai introduces strict database validation. This feature marks a database as not ready for switchover or failover if any advanced checks fail.

Strict validation checks include:

• Matching apply properties
• Matching transport properties
• All data files online
• All PDBs online
• Flashback logging and force logging enabled
• Properly configured and cleared log files
• No saved PDB states, which is important to avoid issues with Active Data Guard

To run all these checks at once, use:

This post is part of a blog series.

With release 26ai, generating AWR reports from Active Data Guard standby databases is now simple and direct, without extra configuration required.

Previously, starting in version 12c Release 2, you had to set up DB links and use the Remote Management Framework (RMF) with the DBMS_UMF package to let the primary database collect remote AWR snapshots from standby databases. This process, documented in MOS note 2409808.1 How to Generate AWRs in Active Data Guard Standby Databases (now KB140685), was complex and could lead to non-working state, especially after failovers.

Now, you can generate reports right on the standby database.
Under the hood, the procedure exports the snapshot to a dump file, transfers it internally to the primary host using Data Guard communication, and imports it on the primary database. All of this is transparent.