DBID
|
NUMBER
|
Database identifier calculated when the database is created and stored in all file headers
|
NAME
|
VARCHAR2(9)
|
Name of the database
|
CREATED
|
DATE
|
Creation date of the database. If the control file was re-created using the CREATE CONTROLFILE statement, then this column displays the date that the control file was re-created.
|
RESETLOGS_CHANGE#
|
NUMBER
|
System change number (SCN) at open resetlogs
|
RESETLOGS_TIME
|
DATE
|
Timestamp of open resetlogs
|
PRIOR_RESETLOGS_CHANGE#
|
NUMBER
|
SCN at prior resetlogs
|
PRIOR_RESETLOGS_TIME
|
DATE
|
Timestamp of prior resetlogs
|
LOG_MODE
|
VARCHAR2(12)
|
Archive log mode:
-
NOARCHIVELOG
-
ARCHIVELOG
-
MANUAL
|
CHECKPOINT_CHANGE#
|
NUMBER
|
Last SCN checkpointed
|
ARCHIVE_CHANGE#
|
NUMBER
|
Database force archiving SCN. Any redo log with a start SCN below this will be forced to archive out.
|
CONTROLFILE_TYPE
|
VARCHAR2(7)
|
Type of control file:
-
STANDBY - Indicates that the database is in standby mode
-
CLONE - Indicates a clone database
-
BACKUP | CREATED - Indicates the database is being recovered using a backup or created control file
-
CURRENT - database is available for general use
|
CONTROLFILE_CREATED
|
DATE
|
Creation date of the control file
|
CONTROLFILE_SEQUENCE#
|
NUMBER
|
Control file sequence number incremented by control file transactions
|
CONTROLFILE_CHANGE#
|
NUMBER
|
Last SCN in backup control file; null if the control file is not a backup
|
CONTROLFILE_TIME
|
DATE
|
Last timestamp in backup control file; null if the control file is not a backup
|
OPEN_RESETLOGS
|
VARCHAR2(11)
|
(NOT ALLOWED | ALLOWED | REQUIRED ) Indicates whether the next database open allows or requires the resetlogs option
|
VERSION_TIME
|
DATE
|
Version time
|
OPEN_MODE
|
VARCHAR2(20)
|
Open mode information:
|
PROTECTION_MODE
|
VARCHAR2(20)
|
Protection mode currently in effect for the database:
-
MAXIMUM PROTECTION - Database is running in maximized protection mode
-
MAXIMUM AVAILABILITY - Database is running in maximized availability mode
-
RESYNCHRONIZATION - Database is running in resynchronization mode
-
MAXIMUM PERFORMANCE - Database is running in maximized performance mode
-
UNPROTECTED - Database is unprotected (this normally occurs when the primary database is mounted and not open)
|
PROTECTION_LEVEL
|
VARCHAR2(20)
|
Aggregated protection mode currently in effect for the database:
-
MAXIMUM PROTECTION - Database is running in maximized protection mode
-
MAXIMUM AVAILABILITY - Database is running in maximized availability mode
-
RESYNCHRONIZATION - Database is running in resynchronization mode
-
MAXIMUM PERFORMANCE - Database is running in maximized performance mode
-
UNPROTECTED - Database is unprotected (this normally occurs when the primary database is mounted and not open)
Note: This column is an aggregation of the PROTECTION_MODE of all standby archive log destinations.
|
REMOTE_ARCHIVE
|
VARCHAR2(8)
|
Value of the REMOTE_ARCHIVE_ENABLE initialization parameter
|
ACTIVATION#
|
NUMBER
|
Number assigned to the database instantiation
|
SWITCHOVER#
|
NUMBER
|
Number assigned to the database switchover
|
DATABASE_ROLE
|
VARCHAR2(16)
|
Current role of the database:
-
SNAPSHOT STANDBY
-
LOGICAL STANDBY
-
PHYSICAL STANDBY
-
PRIMARY
-
FAR SYNC
|
ARCHIVELOG_CHANGE#
|
NUMBER
|
Highest NEXT_CHANGE# (from the V$ARCHIVED_LOG view) for an archive log
|
ARCHIVELOG_COMPRESSION
|
VARCHAR2(8)
|
Status of the archive log compression (ENABLED ) or (DISABLED )
|
SWITCHOVER_STATUS
|
VARCHAR2(20)
|
Indicates whether switchover is allowed:
-
NOT ALLOWED - On a primary database, this status indicates that there are no valid and enabled standby databases. On a standby database, this status indicates that a switchover request has not been received from the primary database.
-
SESSIONS ACTIVE - The database has active sessions. On a physical standby database, the WITH SESSION SHUTDOWN SQL clause must be specified to perform a role transition while in this state. On a logical standby database, a role transition can be performed while in this state, but the role transition will not complete until all current transactions have committed.
-
SWITCHOVER PENDING - On a physical standby database, this status indicates that a switchover request has been received from the primary database and is being processed. A physical standby database cannot switch to the primary role while in this transient state.
-
SWITCHOVER LATENT - On a physical standby database, this status indicates that a switchover request was pending, but the original primary database has been switched back to the primary role.
-
TO PRIMARY - The database is ready to switch to the primary role.
-
TO STANDBY - The database is ready to switch to either the physical or logical standby role.
-
TO LOGICAL STANDBY - The database has received a data dictionary from a logical standby database and is ready to switch to the logical standby role.
-
RECOVERY NEEDED - On a physical standby database, this status indicates that additional redo must be applied before the database can switch to the primary role.
-
PREPARING SWITCHOVER - On a primary database, this status indicates that a data dictionary is being received from a logical standby database in preparation for switching to the logical standby role. On a logical standby database, this status indicates that the data dictionary has been sent to the primary database and other standby databases.
-
PREPARING DICTIONARY - On a logical standby database, this status indicates that the data dictionary is being sent to the primary database and other standby databases in preparation for switching to the primary role.
-
FAILED DESTINATION - On a primary database, this status indicates that one or more standby destinations are in an error state.
-
RESOLVABLE GAP - On a primary database, this status indicates that one or more standby databases have a redo gap that can be automatically resolved by fetching the missing redo from the primary database or from another standby database.
-
UNRESOLVABLE GAP - On a primary database, this status indicates that one or more standby databases have a redo gap that cannot be automatically resolved by fetching the missing redo from the primary database or from another standby database.
-
LOG SWITCH GAP - On a primary database, this status indicates that one or more standby databases are missing redo due to a recent log switch.
|
DATAGUARD_BROKER
|
VARCHAR2(8)
|
Data Guard broker information:
-
ENABLED - Database is part of a broker configuration and broker management of the database is enabled
-
DISABLED - Database is part of a broker configuration and broker management of the database is disabled. This value is displayed if the user disabled broker management of the database or configuration, or if broker management was disabled due to a role change (for example, the old primary was disabled after a failover operation).
|
GUARD_STATUS
|
VARCHAR2(7)
|
Protects data from being changed:
-
ALL - Indicates all users other than SYS are prevented from making changes to any data in the database.
-
STANDBY - Indicates all users other than SYS are prevented from making changes to any database object being maintained by logical standby.
-
NONE - Indicates normal security for all data in the database.
|
SUPPLEMENTAL_LOG_DATA_MIN
|
VARCHAR2(8)
|
Ensures that LogMiner (and any products building on LogMiner technology) will have sufficient information to support chained rows and various storage arrangements such as cluster tables:
-
NO - None of the database-wide supplemental logging directives are enabled.
In a CDB, a value of NO means that minimal supplemental logging is not enabled in all of the PDBs in the CDB.
-
IMPLICIT - Minimal supplemental logging is enabled because all or a combination of primary key, unique key, and foreign key supplemental logging is enabled
-
YES - Minimal supplemental logging is enabled through an ALTER DATABASE ADD SUPPLEMENTAL LOG DATA statement.
In a CDB, a value of YES means that minimal supplemental logging is enabled in all of the PDBs in the CDB.
See Also: Oracle Database SQL Language Reference for additional information about the ALTER DATABASE ADD SUPPLEMENTAL LOG DATA statement
|
SUPPLEMENTAL_LOG_DATA_PK
|
VARCHAR2(3)
|
For all tables with a primary key, indicates whether all columns of the primary key are placed into the redo log whenever an update is performed (YES ) or not (NO ).
When a value of YES appears in a CDB, it means that primary key supplemental logging is enabled in all of the PDBs in the CDB.
When a value of NO appears in a CDB, query the PRIMARY_KEY column in the DBA_SUPPLEMENTAL_LOGGING view for each PDB in the CDB to see whether primary key supplemental logging is enabled in the PDB.
See Also: Oracle Database SQL Language Reference for more information about the ALTER DATABASE ADD SUPPLEMENTAL LOG supplemental_id_key_clause statement
|
SUPPLEMENTAL_LOG_DATA_UI
|
VARCHAR2(3)
|
For all tables with a unique key, indicates whether all other columns belonging to the unique key are placed into the redo log if any of the unique key columns are modified (YES ) or not (NO ).
When a value of YES appears in a CDB, it means that this value is enabled in all of the PDBs in the CDB.
When a value of NO appears in a CDB, query the UNIQUE_INDEX column in the DBA_SUPPLEMENTAL_LOGGING view for each PDB in the CDB to see whether unique column supplemental logging is enabled in the PDB.
See Also: Oracle Database SQL Language Reference for more information about the ALTER DATABASE ADD SUPPLEMENTAL LOG supplemental_id_key_clause statement
|
FORCE_LOGGING
|
VARCHAR2(39)
|
Indicates whether the database is under force logging mode (YES ) or not (NO )
|
PLATFORM_ID
|
NUMBER
|
Platform identification number of the database
|
PLATFORM_NAME
|
VARCHAR2(101)
|
Platform name of the database
|
RECOVERY_TARGET_INCARNATION#
|
NUMBER
|
Incarnation number where all data files are recovered by the RECOVER DATABASE command
|
LAST_OPEN_INCARNATION#
|
NUMBER
|
Record number of the incarnation in V$DATABASE_INCARNATION that was last opened successfully
|
CURRENT_SCN
|
NUMBER
|
Current SCN; null if the database is not currently open. For a standby database, it is the checkpoint SCN of the mounted physical standby database during media recovery and is always less than the last applied SCN tracked in V$RECOVERY_PROGRESS .
|
FLASHBACK_ON
|
VARCHAR2(18)
|
Possible values are as follows:
|
SUPPLEMENTAL_LOG_DATA_FK
|
VARCHAR2(3)
|
For all tables with a foreign key, indicates whether all other columns belonging to the foreign key are placed into the redo log if any foreign key columns are modified (YES ) or not (NO ).
When a value of YES appears in a CDB, it means that foreign key supplemental logging is enabled in all of the PDBs in the CDB.
When a value of NO appears in a CDB, query the FOREIGN_KEY column in the DBA_SUPPLEMENTAL_LOGGING view for each PDB in the CDB to see whether foreign key supplemental logging is enabled in the PDB.
See Also: Oracle Database SQL Language Reference for more information about the ALTER DATABASE ADD SUPPLEMENTAL LOG supplemental_id_key_clause statement
|
SUPPLEMENTAL_LOG_DATA_ALL
|
VARCHAR2(3)
|
For all columns, indicates whether all the fixed-length maximum size columns of that row are placed into the redo log (YES ) or not (NO ).
When a value of YES appears in a CDB, it means that all column supplemental logging is enabled in all of the PDBs in the CDB.
When a value of NO appears in a CDB, query the ALL_COLUMN column in the DBA_SUPPLEMENTAL_LOGGING view for each PDB in the CDB to see whether all column supplemental logging is enabled in the PDB.
See Also: Oracle Database SQL Language Reference for more information about the ALTER DATABASE ADD SUPPLEMENTAL LOG supplemental_id_key_clause statement
|
DB_UNIQUE_NAME
|
VARCHAR2(30)
|
Unique database name
|
STANDBY_BECAME_PRIMARY_SCN
|
NUMBER
|
SCN at which a physical standby database became a primary database. This SCN is useful for converting a failed primary database into a physical standby database after a forced failover.
See Also: Oracle Data Guard Concepts and Administration for more information about Oracle Data Guard.
|
FS_FAILOVER_STATUS
|
VARCHAR2(22)
|
Fast-start failover status:
-
DISABLED
-
BYSTANDER
-
SYNCHRONIZED
-
UNSYNCHRONIZED
-
SUSPENDED
-
STALLED
-
LOADING DICTIONARY
-
PRIMARY UNOBSERVED
-
REINSTATE REQUIRED
-
REINSTATE FAILED
-
TARGET OVER LAG LIMIT
-
TARGET UNDER LAG LIMIT
See Also: Oracle Data Guard Broker for detailed descriptions of these values
Note: If the value of this column is DISABLED , then the values for the FS_FAILOVER_CURRENT_TARGET , FS_FAILOVER_THRESHOLD , FS_FAILOVER_OBSERVER_PRESENT , and FS_FAILOVER_OBSERVER_HOST columns in this table are not meaningful.
|
FS_FAILOVER_CURRENT_TARGET
|
VARCHAR2(30)
|
DB_UNIQUE_NAME of the standby that is the current FSFO target standby for the Data Guard configuration
|
FS_FAILOVER_THRESHOLD
|
NUMBER
|
Time (in seconds) that the observer will attempt to reconnect with a disconnected primary before attempting FSFO with the target standby
|
FS_FAILOVER_OBSERVER_PRESENT
|
VARCHAR2(7)
|
Indicates whether the observer is currently connected to the local database (YES ) or not (NO )
Note: This column is consistent throughout an Oracle RAC environment; that is, if the observer is connected to any instance, then all instances will show a value of YES .
|
FS_FAILOVER_OBSERVER_HOST
|
VARCHAR2(512)
|
Machine name that is currently hosting the observer process
|
CONTROLFILE_CONVERTED
|
VARCHAR2(3)
|
Indicates whether the control file was implicitly converted from its original type during restore (YES ) or not (NO )
This column will be set to YES when RMAN restores a standby control file from a backup of the control file taken at the primary database or restores a backup control file from a backup taken at the physical standby database.
This column will change to NO when the file names are fixed using information in the recovery catalog schema.
|
PRIMARY_DB_UNIQUE_NAME
|
VARCHAR2(30)
|
For any Standby database (Physical, Logical, or Snapshot), this column will contain the DB_UNIQUE_NAME of the Primary database that this Standby last received current redo from.
If this standby has not received any current redo since last being started, then this column will be null.
For a Primary database that had previously been a Standby, this column will contain the DB_UNIQUE_NAME of the last Primary that this database received current redo from while acting as a Standby.
For a Primary database that has never been a Standby, this column will be null.
|
SUPPLEMENTAL_LOG_DATA_PL
|
VARCHAR2(3)
|
Indicates whether additional information is logged in the redo log (YES ) or not (NO ) during invocation of procedures in Oracle-supplied packages for which procedural replication is supported.
When a value of YES appears in a CDB, it means that supplemental logging for procedural replication is enabled in all of the PDBs in the CDB.
When a value of NO appears in a CDB, query the PROCEDURAL column in the DBA_SUPPLEMENTAL_LOGGING view for each PDB in the CDB to see whether supplemental logging for procedural replication is supported in the PDB.
See Also: Oracle Data Guard Concepts and Administration for a list of Oracle-supplied packages that are procedurally replicated to a logical standby database
|
MIN_REQUIRED_CAPTURE_CHANGE#
|
NUMBER
|
Minimum REQUIRED_CHECKPOINT_SCN for all local capture processes on the database
|
CDB
|
VARCHAR2(3)
|
Possible values are:
|
CON_ID
|
NUMBER
|
The ID of the container to which the data pertains. Possible values include:
-
0 : This value is used for rows containing data that pertain to the entire CDB. This value is also used for rows in non-CDBs.
-
1 : This value is used for rows containing data that pertain to only the root
-
n: Where n is the applicable container ID for the rows containing data
|
PENDING_ROLE_CHANGE_TASKS
|
VARCHAR2(512)
|
Tasks remaining after an Oracle Data Guard role change. Possible values:
-
NONE : No pending tasks remain
-
NOT APPLICABLE : The database is either standby or is not a DG_CONFIG member
-
BUILD_PENDING : The database was formerly a logical standby and has not yet taken a snapshot of its data dictionary into the redo stream
-
SRL_ARCHIVE_PENDING : The database was formerly a logical standby and the standby redo logs associated with the earlier failover operation have not yet been archived
-
ERROR : The database was formerly a logical standby and the snapshot of the dictionary failed
-
UNKNOWN : The database is not open or the query failed
|
CON_DBID
|
NUMBER
|
The database ID of the PDB
|
FORCE_FULL_DB_CACHING 1
|
VARCHAR2(3)
|
Indicates the status of the force full database caching feature in the database. Possible values:
-
YES - The database is in force full database caching mode.
-
NO - The database is not in force full database caching mode.
See Also: Oracle Database SQL Language Reference for information about the FORCE FULL DATABASE CACHING clause for the ALTER DATABASE statement
|