
[TITLE]
Data Guard Broker Fixed Views – Detailed Descriptions for SQLcl and LLM Routing

[PURPOSE]
Provide detailed, authoritative descriptions of all Data Guard Broker fixed views so that SQLcl and LLM-based tooling can determine which fixed view to query when answering user questions related to configuration, health, properties, Fast-Start Failover (FSFO), role transitions, and metadata.

[SCOPE]
- Covers Data Guard Broker fixed views
- Includes both documented and selected undocumented views
- Intended for SQLcl query routing and question answering

======================================================================
[FIXED_VIEW_DETAILED_DESCRIPTIONS]
======================================================================
[VIEW]
V$DG_BROKER_CONFIG

[SUMMARY]
V$DG_BROKER_CONFIG provides a summary view of an Oracle Data Guard Broker configuration.
The information exposed by this view is similar to the output of the DGMGRL command
"SHOW CONFIGURATION".

It presents a logical view of the entire broker configuration and can be queried
from any database that is a member of the configuration.

[PRIMARY_USAGE]
Use this view when the user asks:
- What databases are part of the Data Guard configuration?
- What is the role of each database (PRIMARY, STANDBY, FAR SYNC, etc.)?
- Is a database enabled and managed by the broker?
- What is the current broker status or error for a database?
- What severity level does the broker report?

[DATA_SCOPE]
- One row per database or broker-managed member
- Includes configuration-level and member-level state

[COLUMNS]

COLUMN: DATABASE
Type: VARCHAR2(512)
Description:
Database unique name for the broker configuration member.

COLUMN: CONNECT_IDENTIFIER
Type: VARCHAR2(512)
Description:
Net connect identifier used by the broker to reach the database.

COLUMN: DATAGUARD_ROLE
Type: VARCHAR2(27)
Description:
Oracle Data Guard role of the database.
Possible values include:
- PRIMARY
- PHYSICAL STANDBY
- LOGICAL STANDBY
- SNAPSHOT STANDBY
- FAR SYNC INSTANCE
- RECOVERY APPLIANCE

COLUMN: REDO_SOURCE
Type: VARCHAR2(30)
Description:
Database unique name of the redo source for this database.

COLUMN: ENABLED
Type: VARCHAR2(5)
Description:
Indicates whether the database is managed by Oracle Data Guard Broker.
Possible values:
- TRUE
- FALSE

COLUMN: STATUS
Type: NUMBER
Description:
Oracle error number that denotes the current broker status of the database.

COLUMN: SEVERITY
Type: VARCHAR2(30)
Description:
Severity of the broker-reported Oracle error.
Possible values:
- FAILURE
- SUCCESS
- WARNING

COLUMN: STATUS_MESSAGE
Type: VARCHAR2(256)
Description:
Error message associated with the Oracle error number recorded in the STATUS column.

COLUMN: VERSION
Type: VARCHAR2(30)
Description:
Version of the Data Guard Broker configuration.

COLUMN: CON_ID
Type: NUMBER
Description:
ID of the container to which the data pertains.
Possible values:
- 0: Data pertains to the entire CDB or a non-CDB
- 1: Data pertains only to the root container
- n: Data pertains to the specified container ID

[USAGE_GUIDANCE]
- Prefer this view for high-level configuration inspection.
- This view does not provide detailed runtime metrics such as transport or apply lag.
- For health check or status report details, use V$DG_BROKER_STATUS.

[SQLCL_ROUTING_HINT]
If a user question contains keywords such as:
- configuration
- members
- roles
- primary / standby
- enabled or disabled

Then SQLcl or LLM-based tooling should query V$DG_BROKER_CONFIG first.

---------------------------------------------------------------------
[VIEW]
V$DG_BROKER_PROPERTY

[SUMMARY]
V$DG_BROKER_PROPERTY exposes Data Guard Broker properties that are publicly documented.
Each row represents a broker configuration, member, or instance property that is either configurable or monitorable.

This view is the primary source for answering questions about broker properties that are visible and supported in public documentation.

[PRIMARY_USAGE]
Use this view when the user asks:
- What is the current value of a specific broker property?
- Which properties apply to a given configuration or member?
- Whether a property is configurable or monitorable
- For which role or scope a property is effective

[DATA_SCOPE]
- One row per (member, property, instance) combination as applicable
- Includes configuration-level, member-level, and instance-level properties
- Contains only publicly documented properties

[COLUMNS]

COLUMN: MEMBER
Type: VARCHAR2(31)
Description:
Identifies the member of the broker configuration for which the property applies.
For databases, this is the value of the DB_UNIQUE_NAME initialization parameter.
For configuration-level properties, the configuration name is shown.

COLUMN: INSTANCE
Type: VARCHAR2(17)
Description:
Indicates instance specificity when the member is a RAC database.
Used to identify whether a property applies to a particular instance of a RAC member.

COLUMN: DATAGUARD_ROLE
Type: VARCHAR2(18)
Description:
The role of the member in the broker configuration.
Possible values include:
- CONFIGURATION  (logical configuration-level entry)
- PRIMARY
- PHYSICAL STANDBY
- LOGICAL STANDBY
- SNAPSHOT STANDBY
- FAR SYNC INSTANCE
- RECOVERY APPLIANCE
- OTHER  (used if the role cannot be determined)

COLUMN: PROPERTY
Type: VARCHAR2(31)
Description:
The broker property name.

COLUMN: PROPERTY_TYPE
Type: VARCHAR2(12)
Description:
Indicates whether the property is:
- CONFIGURABLE  (value can be set or changed)
- MONITORABLE   (exposes runtime or derived information)

COLUMN: VALUE
Type: VARCHAR2(4000)
Description:
The property value.
For monitorable properties, the literal string "(monitorable)" is shown instead of a concrete value.

COLUMN: VALUE_TYPE
Type: VARCHAR2(11)
Description:
The data type of the property value.
Possible types include:
- STRING
- XML
- UNDEFINED
- BYTE STRING

COLUMN: SCOPE
Type: VARCHAR2(31)
Description:
Defines the scope over which the property takes effect.
Possible values:
- CONFIGURATION  (affects the entire configuration, for example FastStartFailoverThreshold)
- INSTANCE       (affects a single instance, for example StaticConnectIdentifier)
- MEMBER         (affects a single member, for example ApplyLagThreshold)

COLUMN: VALID_ROLE
Type: VARCHAR2(31)
Description:
Specifies the member role in which the property has effect.
Possible values:
- PRIMARY  (effective only when the member is primary, for example SendQEntries)
- STANDBY  (effective only when the member is standby, for example ApplyLagThreshold)
- BOTH     (effective regardless of role, for example DGConnectIdentifier)

[USAGE_GUIDANCE]
- Use V$DG_BROKER_PROPERTY to retrieve supported, documented broker properties.
- When a user asks for configuration, member, or instance-level settings, this view should be checked first.
- If a property is not found here but is known to exist internally, V$DG_BROKER_PROPERTY_INT may contain it.

[SQLCL_ROUTING_HINT]
If a user question includes keywords such as:
- "property", "broker property", "FastStartFailoverThreshold"
- "ApplyLagThreshold", "StaticConnectIdentifier"
- "what is the value of X", "show configuration property"
then SQLcl or LLM-based tooling should query V$DG_BROKER_PROPERTY.

---------------------------------------------------------------------

[VIEW]
V$DG_BROKER_ROLE_CHANGE

[SUMMARY]
V$DG_BROKER_ROLE_CHANGE provides a fixed view of recent role changes performed through Data Guard Broker.
The role change history is stored in the broker configuration metadata, and the view exposes up to 10 of the most recent role change records.

Each row describes a single role change operation such as switchover, failover, fast-start failover, or immediate failover, including timing and the old/new primary databases.

[PURPOSE]
- Allow users and tools to inspect recent broker-managed role transitions.
- Provide a history of switchovers, failovers, fast-start failovers, and converts.
- Expose timing and reason information useful for auditing and diagnostics.

[DATA_SCOPE]
- At most 10 records are retained in the configuration metadata.
- Records are returned in chronological order (oldest first).
- Only records with non-empty BEGIN_TIME and END_TIME are visible in the fixed table and view.

[COLUMNS]

COLUMN: EVENT
Type: VARCHAR2(30)
Description:
The type of role change event.
Examples include:
- Physical Failover
- Logical Failover
- Physical Switchover
- Logical Switchover
- Physical Immediate Failover
- Logical Immediate Failover
- Fast-Start Failover

COLUMN: STANDBY_TYPE
Type: VARCHAR2(30)
Description:
Type of standby involved in the role change.
Possible values:
- Physical
- Logical

COLUMN: OLD_PRIMARY
Type: VARCHAR2(30)
Description:
DB_UNIQUE_NAME of the database that was primary before the role change.

COLUMN: NEW_PRIMARY
Type: VARCHAR2(30)
Description:
DB_UNIQUE_NAME of the database that became primary after the role change.

COLUMN: FS_FAILOVER_REASON
Type: VARCHAR2(255)
Description:
For Fast-Start Failover events, records the reason for the failover.
Example values:
- Primary database disconnected
- Manual Failover

COLUMN: BEGIN_TIME
Type: DATE
Description:
Start time of the role change operation.
Semantics:
- For SWITCHOVER: time when ALTER DATABASE SWITCHOVER is issued on the old primary.
- For FAILOVER: time when ALTER DATABASE FAILOVER is issued on the target standby.

COLUMN: END_TIME
Type: DATE
Description:
Completion time of the role change operation.
For both switchover and failover:
- Time when ALTER DATABASE OPEN completes on the first instance of the new primary database.


[EXAMPLE_QUERY]
Example query to display role change history:

SELECT
  EVENT,
  STANDBY_TYPE,
  OLD_PRIMARY,
  NEW_PRIMARY,
  FS_FAILOVER_REASON,
  TO_CHAR(BEGIN_TIME, 'DD-MON-YYYY HH24:MI:SS') AS BEGIN_TIME,
  TO_CHAR(END_TIME,   'DD-MON-YYYY HH24:MI:SS') AS END_TIME
FROM
  V$DG_BROKER_ROLE_CHANGE;

Sample output:

EVENT               STANDBY_TYPE OLD_PRIMARY NEW_PRIMARY FS_FAILOVER_REASON   BEGIN_TIME           END_TIME
------------------- ------------ ----------- ----------- -------------------- -------------------- --------------------
Failover            Physical     dgaime1     dgaime1b    Manual Failover      30-APR-2021 19:01:14 30-APR-2021 19:01:35
Switchover          Physical     dgaime1b    dgaime1                          30-APR-2021 19:04:53 30-APR-2021 19:05:15
Switchover          Physical     dgaime1     dgaime1b                         30-APR-2021 20:51:38 30-APR-2021 20:52:03
Failover            Physical     dgaime1b    dgaime1     Manual Failover      30-APR-2021 20:52:46 30-APR-2021 20:53:04
Switchover          Physical     dgaime1     dgaime1c                         30-APR-2021 19:53:14 30-APR-2021 19:54:14
Switchover          Physical     dgaime1c    dgaime1                          30-APR-2021 20:03:14 30-APR-2021 20:04:04
Switchover          Logical      dgaime1     dgaime1d                         30-APR-2021 20:24:46 30-APR-2021 20:26:32
Switchover          Logical      dgaime1d    dgaime1                          30-APR-2021 20:35:27 30-APR-2021 20:35:48
Fast-Start Failover Physical     dgaime1     dgaime1b    Primary Disconnected 30-APR-2021 20:13:51 30-APR-2021 20:14:53

[PRIMARY_USAGE]
Use V$DG_BROKER_ROLE_CHANGE when the user asks:
- “What were the last role changes in this configuration?”
- “When did the last failover or switchover happen?”
- “What was the reason for the last Fast-Start Failover?”
- “How long did a role change take?”

[SQLCL_ROUTING_HINT]
If a question mentions:
- “role change history”
- “recent switchovers” or “recent failovers”
- “Fast-Start Failover reason”
- “how long did the failover take”
then SQLcl or LLM-based tooling should query V$DG_BROKER_ROLE_CHANGE.

---------------------------------------------------------------------

[VIEW]
V$DG_BROKER_TAG

[SUMMARY]
V$DG_BROKER_TAG displays all tags stored in the Data Guard Broker configuration.
Each broker configuration member can have zero or more tags.
A tag is defined as a simple key-value pair that can be associated either with the entire configuration or with an individual member.

This view exposes tags exactly as they are stored in broker metadata.

[PURPOSE]
- Provide access to user-defined metadata associated with Data Guard broker objects
- Enable classification, labeling, and automation workflows
- Allow external tooling to retrieve broker tags in a structured manner

[DATA_SCOPE]
- One row per (member, tag) combination
- Tags may exist at:
  - Configuration level
  - Individual member level
- Configuration-level tags are identified by a NULL value in the MEMBER column

[COLUMNS]

COLUMN: MEMBER
Type: VARCHAR2(30)
Description:
Name of the broker configuration member to which the tag applies.
Possible values:
- DB_UNIQUE_NAME of a configuration member
- NULL, indicating a configuration-level tag that applies to the entire Data Guard configuration

COLUMN: NAME
Type: VARCHAR2(30)
Description:
The name (key) of the tag.

COLUMN: VALUE
Type: VARCHAR2(4000)
Description:
The value associated with the tag.
The value is stored as a string and may contain arbitrary user-defined content.

[USAGE_GUIDANCE]
- Use this view to retrieve all tags associated with a Data Guard configuration or its members.
- Configuration-level tags can be filtered by MEMBER IS NULL.
- Member-level tags can be filtered by MEMBER = '<db_unique_name>'.
- Tags are not interpreted by the broker and have no effect on broker behavior.

[EXAMPLE_QUERY]
Query all broker tags:

SELECT
  MEMBER,
  NAME,
  VALUE
FROM
  V$DG_BROKER_TAG;

Sample output:

MEMBER       NAME   VALUE
------------ ------ ------------------------------
NULL         k01    v01
NULL         k02    v02
database_1   k11    v11-reset
database_1   k13    v12 < new3
database_2   k21    v21
database_2   k22    v22-new1

[PRIMARY_USAGE]
Use V$DG_BROKER_TAG when the user asks:
- What tags are defined in the Data Guard configuration?
- What tags are associated with a specific database?
- Retrieve metadata labels for broker members
- List configuration-level or member-level tags

[SQLCL_ROUTING_HINT]
If a user question includes:
- "tag", "tags"
- "metadata label"
- "show broker tags"
then SQLcl or LLM-based tooling should query V$DG_BROKER_TAG.

---------------------------------------------------------------------

[VIEW]
V$FAST_START_FAILOVER_CONFIG

[SUMMARY]
V$FAST_START_FAILOVER_CONFIG provides configuration-level and runtime information for Fast-Start Failover (FSFO).
This view consolidates FSFO-related columns that were previously exposed through V$DATABASE and additional properties shown by the DGMGRL command "SHOW FAST_START FAILOVER".

Six FSFO-related columns were moved from V$DATABASE into this view and will be deprecated in Oracle Database 23c.
This view is the authoritative source for Fast-Start Failover configuration and state.

[PURPOSE]
- Expose Fast-Start Failover configuration, thresholds, and runtime state
- Provide a single fixed view for FSFO-related settings
- Support diagnostics, monitoring, and automation for FSFO

[BACKGROUND]
The following legacy columns were moved from V$DATABASE into this view and are deprecated in 23c:
- FS_FAILOVER_MODE
- FS_FAILOVER_STATUS
- FS_FAILOVER_CURRENT_TARGET
- FS_FAILOVER_THRESHOLD
- FS_FAILOVER_OBSERVER_PRESENT
- FS_FAILOVER_OBSERVER_HOST

Additional FSFO properties displayed by "SHOW FAST_START FAILOVER" are also included in this view.

[DATA_SCOPE]
- One row per Data Guard configuration
- Configuration-level view (not member-specific)
- Reflects broker-managed Fast-Start Failover state

[COLUMNS]

COLUMN: FAST_START_FAILOVER_MODE
Type: VARCHAR2(19)
Description:
Current Fast-Start Failover mode.
Possible values:
- DISABLED
  Fast-start failover is disabled.
- OBSERVE-ONLY
  Fast-start failover is enabled in test drive mode.
- ZERO DATA LOSS
  Fast-start failover is enabled and cannot incur data loss.
- POTENTIAL DATA LOSS
  Fast-start failover is enabled and may incur data loss within FastStartFailoverLagLimit seconds.

COLUMN: STATUS
Type: VARCHAR2(22)
Description:
Current Fast-Start Failover status.
Possible values include:
- DISABLED
- BYSTANDER
- SYNCHRONIZED
- UNSYNCHRONIZED
- SUSPENDED
- STALLED
- LOADING DICTIONARY
- PRIMARY UNOBSERVED
- REINSTATE REQUIRED
- REINSTATE FAILED
- TARGET OVER LAG LIMIT
- TARGET UNDER LAG LIMIT

COLUMN: CURRENT_TARGET
Type: VARCHAR2(30)
Description:
DB_UNIQUE_NAME of the standby database that is currently selected as the fail-safe observer target standby.

COLUMN: THRESHOLD
Type: NUMBER
Description:
Time in seconds that the observer will attempt to reconnect to a disconnected primary before initiating a fast-start failover.

COLUMN: OBSERVER_PRESENT
Type: VARCHAR2(7)
Description:
Indicates whether the master observer is currently connected to the local database.
Possible values:
- YES
- NO

COLUMN: OBSERVER_HOST
Type: VARCHAR2(512)
Description:
Host name of the machine currently running the master observer process.
Returns NULL if Fast-Start Failover is not enabled.

COLUMN: PING_INTERVAL
Type: NUMBER
Description:
Frequency, in milliseconds, at which the observer pings the primary database.

COLUMN: PING_RETRY
Type: NUMBER
Description:
Number of times the observer retries a failed ping before initiating failover to the target standby.

COLUMN: PROTECTION_MODE
Type: VARCHAR2(30)
Description:
Data protection mode of the Data Guard configuration.
Possible values:
- Maximum Availability
- Maximum Performance
- Maximum Protection

COLUMN: LAG_LIMIT
Type: NUMBER
Description:
Maximum allowed redo apply lag, in seconds, for Fast-Start Failover eligibility.

COLUMN: AUTO_REINSTATE
Type: VARCHAR2(5)
Description:
Indicates whether the former primary is automatically reinstated after a Fast-Start Failover if the primary was isolated or crashed.
Possible values:
- TRUE
- FALSE

COLUMN: OBSERVER_RECONNECT
Type: NUMBER
Description:
Interval in seconds at which the observer attempts to re-establish a connection to the primary database.

COLUMN: OBSERVER_OVERRIDE
Type: VARCHAR2(5)
Description:
Indicates whether an automatic failover is allowed when the observer loses connectivity to the primary.
Possible values:
- TRUE
- FALSE

COLUMN: SHUTDOWN_PRIMARY
Type: VARCHAR2(5)
Description:
Indicates whether the primary database should be shut down under specific Fast-Start Failover conditions.
Possible values:
- TRUE
- FALSE

[USAGE_GUIDANCE]
- Use this view to determine whether Fast-Start Failover is enabled or disabled.
- Use this view to inspect FSFO thresholds, lag limits, and observer behavior.
- Prefer this view over V$DATABASE for FSFO-related information starting in 23c.
- This view does not provide per-observer runtime details; use V$FS_FAILOVER_OBSERVERS for observer-specific state.

[PRIMARY_USAGE]
Use V$FAST_START_FAILOVER_CONFIG when the user asks:
- Is Fast-Start Failover enabled?
- What FSFO mode is configured?
- What is the current failover target?
- What threshold or lag limit is in effect?
- Where is the observer running?
- Will the primary be shut down or reinstated automatically?

[SQLCL_ROUTING_HINT]
If a user question contains:
- "fast-start failover"
- "FSFO mode"
- "failover threshold"
- "observer configuration"
- "shutdown primary" or "auto reinstate"

then SQLcl or LLM-based tooling should query V$FAST_START_FAILOVER_CONFIG.

---------------------------------------------------------------------

[VIEW]
V$FS_FAILOVER_OBSERVERS

[SUMMARY]
V$FS_FAILOVER_OBSERVERS provides detailed runtime information about Fast-Start Failover (FSFO) observers.
Each row represents a configured observer process known to the Data Guard Broker.

When queried on the primary database, the view returns three rows, each describing a possible observer.
Only rows with a non-empty NAME value correspond to started observers.
When queried on a non-primary database, the behavior of this view is undefined.

[PURPOSE]
- Expose runtime state of Fast-Start Failover observers
- Identify which observer is active and which is the master observer
- Diagnose observer connectivity to the primary and target standby databases
- Support monitoring and automation of FSFO infrastructure

[DATA_SCOPE]
- One row per observer slot
- A maximum of three observer rows are returned when queried on the primary database
- Only observers with a non-empty NAME are currently started
- Observer state is broker-managed

[QUERY_LOCATION_REQUIREMENT]
- This view must be queried on the PRIMARY database for defined and reliable behavior
- Querying this view on non-primary databases yields undefined results

[COLUMNS]

COLUMN: NAME
Type: VARCHAR2(513)
Description:
The Fast-Start Failover observer name.
A non-empty value indicates a started observer.
An empty value indicates an unused observer slot.

COLUMN: REGISTERED
Type: VARCHAR2(4)
Description:
Indicates whether the observer is registered with the broker.
Possible values:
- YES
- NO
Note:
An observer is considered registered only if HOST is not NULL.

COLUMN: HOST
Type: VARCHAR2(513)
Description:
Name of the host machine on which the observer process is running.
Returns NULL if the observer is not registered.

COLUMN: ISMASTER
Type: VARCHAR2(4)
Description:
Indicates whether this observer is the master observer.
Possible values:
- YES
- NO

COLUMN: TIME_SELECTED
Type: TIMESTAMP(9)
Description:
Time at which this observer became the master observer.
If ISMASTER is NO, the constant value is shown:
1990-01-01 00:00:00.00

COLUMN: PINGING_PRIMARY
Type: VARCHAR2(4)
Description:
Indicates whether the observer is currently connected to the primary database.
Possible values:
- YES  – connected
- NO   – not connected
Note:
In Oracle RAC environments, this value is consistent across all instances.
If the observer is connected to any primary instance, all instances report YES.

COLUMN: PINGING_TARGET
Type: VARCHAR2(4)
Description:
Indicates whether the observer is currently connected to the target standby database.
Possible values:
- YES  – connected
- NO   – not connected
Note:
In Oracle RAC environments, this value is consistent across all instances.
If the observer is connected to any target standby instance, all instances report YES.

COLUMN: LOG_FILE
Type: VARCHAR2(513)
Description:
Full file system path to the observer log file.

COLUMN: STATE_FILE
Type: VARCHAR2(513)
Description:
Full file system path to the observer runtime state data file.

COLUMN: CON_ID
Type: NUMBER
Description:
Identifier of the container to which the data pertains.
Possible values:
- 0: Data pertains to the entire CDB or a non-CDB
- 1: Data pertains only to the root container
- n: Data pertains to the specified container ID

[ADDITIONAL_COLUMNS]
The following columns were added in later releases to improve observability:

COLUMN: LAST_PING_PRIMARY
Type: NUMBER
Description:
Time in seconds since the observer last successfully pinged the primary database.

COLUMN: LAST_PING_TARGET
Type: NUMBER
Description:
Time in seconds since the observer last successfully pinged the target standby database.

COLUMN: CURRENT_TIME
Type: TIMESTAMP(9)
Description:
Timestamp representing the time when the view was queried.
Useful for calculating observer ping latency using LAST_PING_PRIMARY and LAST_PING_TARGET.

[USAGE_GUIDANCE]
- Use this view to determine which observers are running and registered.
- Use ISMASTER and TIME_SELECTED to identify the active master observer.
- Use PINGING_PRIMARY and PINGING_TARGET to diagnose connectivity problems.
- Use LAST_PING_* columns for precise observer-liveness analysis.
- Always query this view on the primary database for consistent results.

[PRIMARY_USAGE]
Use V$FS_FAILOVER_OBSERVERS when the user asks:
- Which FSFO observers are running?
- Which observer is the master observer?
- Is the observer connected to the primary or standby?
- Where is the observer running?
- When was the observer last able to ping the primary or target?

[SQLCL_ROUTING_HINT]
If a user question includes terms such as:
- "observer"
- "FSFO observer status"
- "master observer"
- "observer connectivity"
- "last ping"

then SQLcl or LLM-based tooling should query V$FS_FAILOVER_OBSERVERS.
---------------------------------------------------------------------

[VIEW]
V$FS_FAILOVER_STATS

[SUMMARY]
V$FS_FAILOVER_STATS displays statistics about the most recent Fast-Start Failover (FSFO) event that occurred in the system.
The view contains a single logical record describing the last FSFO operation.

[PURPOSE]
- Provide summary information about the most recent Fast-Start Failover
- Expose the time and reason for the last FSFO
- Support diagnostics, auditing, and post-failover analysis

[DATA_SCOPE]
- Contains information only for the most recent Fast-Start Failover
- Exposes at most one logical record
- Data is not historical and does not store multiple FSFO events

[AVAILABILITY_NOTE]
- Data in this view is not persisted across database restarts
- If the database instance is restarted, the statistics are lost
- Data is available only on the new primary database after a Fast-Start Failover
- No rows are returned if Fast-Start Failover has never occurred

[COLUMNS]

COLUMN: LAST_FAILOVER_TIME
Type: VARCHAR2(20)
Description:
Timestamp indicating when the most recent Fast-Start Failover occurred.

COLUMN: LAST_FAILOVER_REASON
Type: VARCHAR2(255)
Description:
Describes the reason for the most recent Fast-Start Failover.
Example reasons include:
- Primary database disconnected
- Primary database crashed
- Other FSFO-triggering conditions

COLUMN: CON_ID
Type: NUMBER
Description:
Identifier of the container to which the data pertains.
Possible values:
- 0: Data pertains to the entire CDB or a non-CDB
- 1: Data pertains only to the root container
- n: Data pertains to the specified container ID

[USAGE_GUIDANCE]
- Use this view to quickly determine whether an FSFO has occurred recently.
- Use this view for high-level diagnosis after an automatic failover.
- For detailed role-change history across switchovers and failovers, use V$DG_BROKER_ROLE_CHANGE.
- For observer connectivity and ping diagnostics, use V$FS_FAILOVER_OBSERVERS or V$FS_OBSERVER_HISTOGRAM.

[PRIMARY_USAGE]
Use V$FS_FAILOVER_STATS when the user asks:
- When did the last Fast-Start Failover occur?
- Why did the last Fast-Start Failover happen?
- Has FSFO ever been triggered on this system?

[SQLCL_ROUTING_HINT]
If a user question includes:
- "last fast-start failover"
- "last FSFO time"
- "why did fast-start failover happen"
- "reason for automatic failover"
then SQLcl or LLM-based tooling should query V$FS_FAILOVER_STATS.

[SEE_ALSO]
- V$DG_BROKER_ROLE_CHANGE
- V$FAST_START_FAILOVER_CONFIG
- V$FS_FAILOVER_OBSERVERS


---------------------------------------------------------------------

[VIEW]
V$FS_LAG_HISTOGRAM

[SUMMARY]
V$FS_LAG_HISTOGRAM displays statistics based on the frequency distribution of Fast-Start Failover (FSFO) lag times.
The histogram reflects how often different ranges of lag were observed by the primary database.

Lag time is evaluated by the primary database at one-minute intervals.
This view is populated only when Fast-Start Failover is enabled.

[PURPOSE]
- Quantify redo apply and transport lag observed by the primary database
- Provide empirical data for tuning Fast-Start Failover behavior
- Support selection of an appropriate FastStartFailoverLagLimit value
- Diagnose whether lag conditions could prevent fast-start failover

[DATA_SCOPE]
- One row per (redo thread, lag type, lag-time bucket) combination
- Histogram-based (bucketized) representation of lag samples
- Evaluated by the primary database only
- No rows are returned when Fast-Start Failover is disabled

[LAG_EVALUATION_SEMANTICS]
- Lag samples are assessed every one minute by the primary database
- Each lag sample is categorized into a lag-time bucket
- Buckets represent upper bounds of observed lag times

[COLUMNS]

COLUMN: THREAD#
Type: NUMBER
Description:
Redo thread number to which the lag statistics apply.
In Oracle RAC environments, multiple redo threads may be present.

COLUMN: LAG_TYPE
Type: VARCHAR2(32)
Description:
Type of lag being measured.
Possible values:
- APPLY
  Lag represents redo apply delay on the standby database.
- TRANSPORT
  Lag represents redo transport delay from primary to standby.

COLUMN: LAG_TIME
Type: NUMBER
Description:
Upper bound of the lag time bucket, expressed in seconds.
If LAG_TIME = N, the bucket represents lag times < N seconds
that are not included in any smaller bucket.

COLUMN: LAG_COUNT
Type: NUMBER
Description:
Number of times lag samples fell into this LAG_TIME bucket.
A value of 0 indicates that no lag samples were observed for this range.

COLUMN: LAG_UPDATE_TIME
Type: VARCHAR2(20)
Description:
Timestamp indicating when this histogram bucket was last updated.

COLUMN: CON_ID
Type: NUMBER
Description:
Identifier of the container to which the data pertains.
Possible values:
- 0: Data pertains to the entire CDB or a non-CDB
- 1: Data pertains only to the root container
- n: Data pertains to the specified container ID

[POPULATION_RULES]
- No rows are shown when Fast-Start Failover is disabled.
- Buckets with LAG_COUNT = 0 may still appear to define lag boundaries.
- Histogram reflects historical lag observations, not a single point-in-time lag.

[USAGE_GUIDANCE]
- Use this view to understand the distribution of apply or transport lag.
- Identify the maximum lag intervals that occur with non-zero frequency.
- Select a FastStartFailoverLagLimit value that is greater than most observed lag samples.
- Persistent high values in larger lag buckets may indicate transport or apply issues.

[FAST_START_FAILOVER_LAG_LIMIT_GUIDANCE]
FastStartFailoverLagLimit should be configured to a value that exceeds the typical observed lag.
This prevents fast-start failover from being blocked by normal, transient lag behavior.

[EXAMPLE_SCENARIO]
Observed lag intervals:
- 0 to 5 seconds: 122 occurrences
- 5 to 10 seconds: 5 occurrences
- 10 to 15 seconds: 2 occurrences

Corresponding histogram output:

THREAD#  LAG_TYPE   LAG_TIME  LAG_COUNT  LAG_UPDATE_TIME      CON_ID
1        APPLY      5         122        01/23/2023 10:46:07  0
1        APPLY      10        5          01/02/2023 16:12:42  0
1        APPLY      15        2          12/25/2022 12:01:23  0
1        APPLY      30        0                              0
1        APPLY      60        0                              0
1        APPLY      120       0                              0
1        APPLY      180       0                              0
1        APPLY      300       0                              0
1        APPLY      65535     0                              0

In this example, FastStartFailoverLagLimit should be set to a value larger than 10–15 seconds,
depending on tolerance for occasional lag spikes.

[PRIMARY_USAGE]
Use V$FS_LAG_HISTOGRAM when the user asks:
- How much apply or transport lag is typically observed?
- Is lag preventing Fast-Start Failover?
- What value should FastStartFailoverLagLimit be set to?
- Are lag spikes transient or frequent?

[SQLCL_ROUTING_HINT]
If a user question includes:
- "lag histogram"
- "apply lag"
- "transport lag"
- "FastStartFailoverLagLimit"
- "redo lag distribution"
then SQLcl or LLM-based tooling should query V$FS_LAG_HISTOGRAM.

[SEE_ALSO]
- V$FAST_START_FAILOVER_CONFIG
- V$FS_OBSERVER_HISTOGRAM
- V$FS_FAILOVER_OBSERVERS

---------------------------------------------------------------------

[VIEW]
V$FS_OBSERVER_HISTOGRAM

[SUMMARY]
V$FS_OBSERVER_HISTOGRAM displays statistics based on the frequency of successful pings between the Fast-Start Failover (FSFO) observer and the primary database.
The statistics are organized as a histogram of inter-ping wait times, representing periods during which observer-to-primary pings failed.

The histogram is populated only when ping failures occur between the observer and the primary database.

[PURPOSE]
- Provide visibility into observer-to-primary communication stability
- Quantify the duration of observer ping failures
- Support selection of an appropriate FastStartFailoverThreshold value
- Diagnose intermittent connectivity issues between observer and primary

[DATA_SCOPE]
- One row per (observer, wait-time bucket) combination
- Rows appear only when ping failures have occurred
- No rows are returned for unregistered observers
- Data represents histogram buckets derived from inter-ping intervals

[WAIT_EVENT_SEMANTICS]
- The wait event represented in this histogram is the observer waiting for successful pings to the primary database.
- Each histogram bucket aggregates ping-pairs where at least one ping failure occurred between two successful pings.

[COLUMNS]

COLUMN: OBSERVER_NAME
Type: VARCHAR2(513)
Description:
The name of the Fast-Start Failover observer that generated this histogram data.

COLUMN: OBSERVER_HOST
Type: VARCHAR2(513)
Description:
The name of the host machine on which the observer process is running.

COLUMN: WAIT_TIME
Type: NUMBER
Description:
The upper bound, in seconds, of the inter-ping interval represented by this histogram bucket.

WAIT_TIME semantics:
- Represents the maximum duration of a ping failure for that bucket
- If WAIT_TIME = N, then this bucket includes inter-ping intervals <= N seconds
  that are not included in any smaller bucket
- Values represent the duration of time during which the observer experienced ping failures

COLUMN: WAIT_COUNT
Type: NUMBER
Description:
The number of ping-pairs whose inter-ping interval falls into this WAIT_TIME bucket.

Special behavior:
- If all pings have been successful so far, WAIT_COUNT is 0 for all buckets

COLUMN: LAST_UPDATE_TIME
Type: VARCHAR2(20)
Description:
The most recent timestamp at which this histogram bucket was updated.

COLUMN: CON_ID
Type: NUMBER
Description:
Identifier of the container to which the data pertains.
Possible values:
- 0: Data applies to the entire CDB or a non-CDB
- 1: Data applies to the root container
- n: Data applies to the specified container ID

[POPULATION_RULES]
- Histogram rows are generated only if at least one ping failure has occurred.
- Observers that are not registered do not produce histogram rows.
- Buckets with WAIT_COUNT = 0 may still be present to define upper bounds.

[USAGE_GUIDANCE]
- Use this view to understand how long observer-to-primary communication disruptions last.
- Identify the maximum observed ping failure duration.
- Select a FastStartFailoverThreshold value greater than the longest observed failure duration.
- This view analyzes observer behavior toward the primary database only.

[FAST_START_FAILOVER_THRESHOLD_GUIDANCE]
FastStartFailoverThreshold should be configured to a value larger than the longest observed WAIT_TIME with a non-zero WAIT_COUNT.
This prevents unnecessary fast-start failovers caused by transient connectivity issues.

[EXAMPLE_SCENARIO]
Assume the following observer ping sequence:

Ping Time   Result
1:00:00     SUCCESS
1:00:03     FAIL
1:00:06     FAIL
1:00:09     SUCCESS   -> Wait time of 6 seconds
1:00:12     SUCCESS
1:00:15     FAIL
1:00:18     FAIL
1:00:21     SUCCESS   -> Wait time of 6 seconds
1:00:24     SUCCESS
1:00:27     FAIL
1:00:30     SUCCESS   -> Wait time of 3 seconds

This sequence produces the following histogram:

WAIT_TIME   WAIT_COUNT   LAST_UPDATE_TIME
3           1            01:00:30
6           2            01:00:21
9           0
12          0
...

In this example, FastStartFailoverThreshold should be configured to a value greater than 6 seconds.

[PRIMARY_USAGE]
Use V$FS_OBSERVER_HISTOGRAM when the user asks:
- How stable is observer connectivity to the primary?
- How long do observer ping failures typically last?
- How should FastStartFailoverThreshold be chosen?
- Are connectivity glitches transient or prolonged?

[SQLCL_ROUTING_HINT]
If a question includes:
- "observer histogram"
- "observer ping failures"
- "FastStartFailoverThreshold"
- "ping latency" or "ping gaps"
then SQLcl or LLM-based tooling should query V$FS_OBSERVER_HISTOGRAM.

[SEE_ALSO]
- V$FAST_START_FAILOVER_CONFIG
- V$FS_FAILOVER_OBSERVERS
- Oracle Data Guard Broker documentation for FastStartFailoverThreshold

---------------------------------------------------------------------

[VIEW]
V$DG_BROKER_STATUS / GV$DG_BROKER_STATUS

[SUMMARY]
V$DG_BROKER_STATUS provides information for the most recent Data Guard Broker status report or health check executed on an instance.
The view exposes any errors, warnings, or success results captured during the last broker status evaluation.

The contents of this view are based on the fixed table X$RFSR.
GV$DG_BROKER_STATUS aggregates the status report results across all instances.

[PURPOSE]
- Report the outcome of the most recent broker status report
- Expose errors, warnings, or success states detected by broker health checks
- Support diagnostics and user-facing STATUS REPORT functionality

[DATA_SCOPE]
- Contains results from the **last** status report or health check only
- Does not retain historical status report data
- Each row represents one status entry captured during the report
- Results are instance-specific in V$DG_BROKER_STATUS
- Results are cluster-wide in GV$DG_BROKER_STATUS

[COLUMNS]

COLUMN: SEVERITY
Type: VARCHAR2(30)
Description:
Severity level of the broker-reported Oracle error or status.
Possible values:
- FAILURE
  Indicates a critical error condition.
- WARNING
  Indicates a non-fatal issue that may require attention.
- SUCCESS
  Indicates successful validation for the reported item.

COLUMN: STATUS
Type: NUMBER
Description:
Oracle error number associated with the reported condition.

COLUMN: ERROR_TAG1
Type: VARCHAR2(30)
Description:
The first argument associated with the Oracle error.
Provides additional context for the reported status.

COLUMN: ERROR_TAG2
Type: VARCHAR2(30)
Description:
The second argument associated with the Oracle error.
Provides supplemental metadata related to the reported condition.

COLUMN: STATUS_MESSAGE
Type: VARCHAR2
Description:
Error or status message text corresponding to the Oracle error number stored in the STATUS column.

COLUMN: TIMESTAMP
Type: DATE
Description:
Timestamp indicating when the status entry was captured during the status report or health check.

COLUMN: CON_ID
Type: NUMBER
Description:
Identifier of the container to which the data pertains.
The value is always 0, indicating that the data applies to the entire CDB or a non-CDB.

[USAGE_GUIDANCE]
- Use this view to inspect the most recent broker health check results.
- Use GV$DG_BROKER_STATUS in RAC environments to retrieve status entries from all instances.
- This view reflects diagnostic results only and does not provide configuration or historical context.

[RELATIONSHIP_TO_OTHER_VIEWS]
- Use V$DG_BROKER_CONFIG for configuration structure and roles.
- Use V$DG_BROKER_ROLE_CHANGE for role transition history.
- Use V$FAST_START_FAILOVER_CONFIG for FSFO configuration and state.
- Use V$DG_BROKER_STATUS specifically for status report results.

[PRIMARY_USAGE]
Use V$DG_BROKER_STATUS / GV$DG_BROKER_STATUS when the user asks:
- Is the Data Guard configuration healthy?
- What errors or warnings does the broker report?
- Why does a status report show FAILURE or WARNING?
- What issues were detected in the last health check?

[SQLCL_ROUTING_HINT]
If a user question includes:
- "status report"
- "broker status"
- "health check"
- "FAILURE", "WARNING", or "error message"
then SQLcl or LLM-based tooling should query V$DG_BROKER_STATUS.
Use GV$DG_BROKER_STATUS if instance-wide or RAC-wide results are required.

[SEE_ALSO]
- V$DG_BROKER_CONFIG
- V$DG_BROKER_ROLE_CHANGE
- V$FAST_START_FAILOVER_CONFIG

======================================================================
[CONCLUSION]
======================================================================

This document consolidates and standardizes the authoritative descriptions of Data Guard Broker fixed views that are relevant to SQLcl-based querying and LLM-assisted question answering.

Each fixed view documented herein includes:
- A detailed, reference-equivalent description
- Column-level semantics and valid values
- Clear usage boundaries and limitations
- Explicit guidance on when the view should be queried
- SQLcl / LLM routing hints for reliable view selection

Together, these fixed views form a complete and consistent knowledge foundation for understanding:
- Data Guard Broker configuration and roles
- Broker properties 
- Role change history and fast-start failover behavior
- Observer runtime state and connectivity
- Lag and observer stability analysis
- Broker status reports and health checks

This document is intended to serve as the primary source of truth for SQLcl logic and LLM-based tooling when answering user questions related to Data Guard Broker.

======================================================================
[LIMITATIONS_AND_EXCLUSIONS]
======================================================================

The following constraints apply to the scope of this document:

- Only the most recent state or event is available for some views:
  - V$DG_BROKER_STATUS reflects only the last status report.
  - V$FS_FAILOVER_STATS reflects only the most recent fast-start failover.
- Historical data beyond what is exposed by fixed views is not preserved.
- Some views have query-location constraints:
  - V$FS_FAILOVER_OBSERVERS has defined behavior only when queried on the primary database.
- Undocumented and internal behavior may exist beyond what is described here.

======================================================================
[POTENTIALLY_MISSING_OR_OUT_OF_SCOPE_INFORMATION]
======================================================================

The following areas are intentionally not covered or may require additional sources:

- Detailed runtime transport and apply metrics (for example, per-archive status or gap resolution)
- Historical trend analysis beyond histogram-based views
- Fixed tables (X$ views) not surfaced through supported fixed views
- Broker command behavior that is exclusive to interactive DGMGRL workflows
- Manual failover and switchover procedures outside broker-managed operations

If such information is required, additional documentation or views outside the scope of this resource file must be consulted.

======================================================================
[EXTENSION_GUIDANCE]
======================================================================

Future enhancements to this document may include:
- Example SQL queries mapped to common user questions
- Cross-view correlation guidance (for example, combining broker status with role history)
- Version-specific behavior differences as broker features evolve
- Additional broker-related fixed views introduced in newer database releases

Any extensions should follow the same structured format used in this document to ensure compatibility with SQLcl routing logic and LLM-based retrieval.

======================================================================
[INTENDED_USAGE]
======================================================================

This document is designed to be used as:
- A resource file for LLM-based Data Guard question answering
- A routing reference for SQLcl logic to determine the appropriate fixed view
- A stable internal reference for Data Guard Broker diagnostics

It is not intended to replace official Oracle documentation, but rather to translate that documentation into a form that enables deterministic query selection and accurate, context-aware responses.

======================================================================
[LAST_UPDATED]
======================================================================

2025-12
