Oracle® Data Guard Broker 11g Release 1 (11.1) Part Number B28295-01 |
|
|
View PDF |
Database properties help you to view and control the behavior of databases, redo transport services, and log apply services in a broker configuration.
This chapter discusses the following topics:
The scope of some properties is said to be database-wide. If the database (primary or standby) is an Oracle RAC database consisting of multiple instances, the value of such a property applies uniformly across all of the instances of that database. The scope of other properties is said to be instance-specific. Such a property exists for all instances of the RAC database, but its value may differ from one specific instance to another.
Note:
This chapter presents properties primarily from the point of view of the Data Guard command-line interface (DGMGRL). Using DGMGRL, the properties described in this chapter may be viewed or modified using discrete DGMGRL commands.Enterprise Manager explicitly presents some of these properties on the Edit Properties page. Information from other properties may be implicitly incorporated into other Web pages displayed by Enterprise Manager. Each property's description in this chapter indicates how Enterprise Manager presents that property.
Monitorable database properties allow you to view information related to the database or the instance, but you cannot change the values of these properties. You can view all of the monitorable properties using the DGMGRL SHOW
commands.
Note:
Information for monitorable properties can be seen only when broker management of the database is enabled. Enterprise Manager displays the information obtained from these properties on the Property page.If the database is an Oracle RAC database, the output values of some properties may also show instance-specific information. For example if the primary database is an Oracle RAC database, LogXptStatus
may show Instance1
transmitting redo data to Standby2
has an error and Instance2
transmitting redo data to Standby4
has an error.
The following sections describe the monitorable database properties:
InconsistentLogXptProps (Inconsistent Redo Transport Properties)
LsbyFailedTxnInfo (Logical Standby Failed Transaction Information)
The InconsistentLogXptProps
monitorable database property returns a table that shows all properties related to redo transport services whose values are inconsistent between the broker configuration file and the runtime value in the database.
Although the properties reported in this table are database-level properties, the inconsistency is reported on an instance-level basis. A database-specific property only ensures that there is one value in the broker's configuration file for all instances sharing the database, but the runtime values among the instances can be different. This means that a database-specific property may be inconsistent only on some instances.
This property pertains to the primary database. The table contains the following columns:
INSTANCE_NAME
The value identifying the SID for the instance.
STANDBY_NAME
The database unique name (DB_UNIQUE_NAME
) of the standby database to which this redo transport services property pertains.
PROPERTY_NAME
The name of the redo transport services property with an inconsistent value.
MEMORY_VALUE
The runtime value being used in the database.
BROKER_VALUE
The value of the redo transport services property saved in the broker configuration file.
The InconsistentProperties
monitorable database property returns a table that shows all database properties whose values contained in the broker configuration file are inconsistent with the values in the corresponding server parameter file or the runtime values in the database.
The properties reported in this table can be either database-specific properties or instance-specific properties. A database-specific property only ensures that there is one value in the broker's configuration file for all instances sharing the database, but the runtime memory values or SPFILE values among the instances can be different. This means that a database-specific property may be inconsistent only on some instances.
Each individual database has this property. The table contains the following columns:
INSTANCE_NAME
The value identifying the SID for the instance.
PROPERTY_NAME
The name of the database property with the inconsistent value.
MEMORY_VALUE
The corresponding runtime value being used in the database.
SPFILE_VALUE
The corresponding value saved in the server parameter file (SPFILE).
BROKER_VALUE
The value of the database property saved in the broker configuration file.
The LogXptStatus
monitorable database property returns a table that contains the error status of redo transport services for each of the enabled standby databases. This property pertains to the primary database.
The table contains the following columns:
PRIMARY_INSTANCE_NAME
The value identifying the SID for the instance on the primary database.
STANDBY_DATABASE_NAME
The database unique name (DB_UNIQUE_NAME
) of the standby database.
ERROR
The text of the redo transport error. If there is no error, the field is empty.
Each entry in the table indicates the status of redo transport services on one primary instance to one standby database.
The error status can be an empty string, which indicates there is no error.
In the following example, the STATUS
from DR_Sales
is empty because there is no error for the DR_Sales
destination. The South_Report
destination returned the ORA-01034
message.
DGMGRL> SHOW DATABASE 'North_Sales' 'LogXptStatus' ; LOG TRANSPORT STATUS PRIMARY_INSTANCE_NAME STANDBY_DATABASE_NAME STATUS sales1 DR_Sales sales1 South_Report ORA-01034: ORACLE not available
The LsbyFailedTxnInfo
monitorable database property identifies a failed transaction that caused log apply services to stop. This property contains a string with the following values from the DBA_LOGSTDBY_EVENTS
view:
XIDUSN
: Transaction ID undo segment number
XIDSLT
: Transaction ID slot number
XIDSQN
: Transaction ID sequence number
STATUS_CODE
: Status (or Oracle error code) belonging to the STATUS
message
STATUS
: Description of the current activity of the process or the reason why log apply services stopped
The transaction IDs and status information are separated by a string of number signs (###).
This property pertains to a logical standby database.
The LsbyParameters
monitorable database property contains a string that identifies the value of MAX_SGA
(maximum system global area) and MAX_SERVERS
(maximum number of parallel query servers) specifically reserved for log apply services. These values are separated by a string of number signs (###) in the LsbyParameters
property.
This property pertains to a logical standby database.
The LsbySkipTable
monitorable database property lists the SQL Apply skip specifications. These skip specifications specify filters for SQL Apply to skip applying a certain class of online redo log files on the logical standby database. This property returns a table with the following columns from the DBA_LOGSTDBY_SKIP
view:
ERROR
Indicates if the statement should be skipped (Y
) or if errors should be returned for the statement (N
)
STATEMENT_OPT
Indicates the type of statement that should be skipped
SCHEMA
The schema name for which this skip option should be used
NAME
Name of the object for which this skip option should be used
PROCEDURE
Name of the stored procedure to execute when processing the skip option
This property pertains to a logical standby database.
The LsbySkipTxnTable
monitorable database property lists the skip settings chosen. This property returns a table with following columns:
XIDUSN
: Transaction ID undo segment number
XIDSLT
: Transaction ID slot number
XIDSQN
: Transaction ID sequence number
ACTIVE
: Description of the current activity of the process or the reason why SQL Apply stopped
This property pertains to SQL Apply.
The RecvQEntries
monitorable database property returns a table indicating all log files that were received by the standby database but have not yet been applied. If no rows are returned, it implies all log files received have been applied. This property pertains to a standby database.
The table contains the following columns in the order shown:
STATUS
The STATUS
column is set to one of the following values for a log file on a logical standby database:
NOT_APPLIED
: No redo records in this log file have been applied.
PARTIALLY_APPLIED
: Some of the redo records in this log file have been applied while others have not.
COMMITTED_TRANSACTIONS_APPLIED
: This status value only applies to a logical standby database. All redo records belonging to the committed transactions have been applied. Redo records belonging to uncommitted transactions have not been read by LogMiner and may still be needed when the transactions are committed in the future. Therefore, it is not safe yet to discard this online redo log file.
RESETLOGS_ID
Resetlogs identifier associated with the archived redo log file
THREAD
The redo thread number
LOG_SEQ
The online redo log file sequence number
TIME_GENERATED
The first time when the online redo log file was written to the primary database
TIME_COMPLETED
The next time when the log file was archived on the primary database (corresponds to the NEXT_CHANGE#
column)
FIRST_CHANGE#
First change number in the archived redo log file
NEXT_CHANGE#
First change in the next log file
SIZE (KBs)
The SIZE
of the online redo log file in kilobytes
For example:
DGMGRL> SHOW DATABASE 'DR_Sales' 'RecvQEntries' ; STATUS RESETLOGS_ID THREAD LOG_SEQ TIME_GENERATED TIME_COMPLETED FIRST_CHANGE# NEXT_CHANGE# SIZE (KBs) NOT_APPLIED 497198843 1 5 06/20/2003 14:55:38 06/20/2003 16:31:26 202138 210718 7364 NOT_APPLIED 497198843 1 6 06/20/2003 16:31:26 06/20/2003 16:31:39 210718 210753 13 NOT_APPLIED 497198843 1 7 06/20/2003 16:31:39 06/20/2003 16:31:54 210753 210758 1 NOT_APPLIED 497198843 1 8 06/20/2003 16:31:54 06/20/2003 16:31:59 210758 210789 11
Note:
Enterprise Manager displays this information on the Log File Details page.The SendQEntries
monitorable database property returns a table that shows all log files on the primary database that were not successfully archived to one or more standby databases. This property pertains to the primary database.
The table contains the following columns:
STANDBY_NAME
The value can be empty or it can contain the database unique name (DB_UNIQUE_NAME
) of a standby database. If empty, the STATUS
column will contain a value of CURRENT
or NOT_ARCHIVED
.
STATUS
The STATUS
column is set to one of the following values:
CURRENT
: A log file to which online redo is currently being written.
NOT_ARCHIVED
: A completed online redo log file that has not been archived locally.
ARCHIVED
: A completed log file that has been archived locally but has not been transmitted to the standby database specified in the STANDBY_NAME
column.
The table contains exactly one row with the value of STATUS=CURRENT
. There can be multiple rows with the value STATUS=ARCHIVED
or STATUS=NOT_ARCHIVED
.
RESETLOGS_ID
Resetlogs identifier associated with the archived redo log file
THREAD
The redo thread number.
LOG_SEQ
The log sequence number. Multiple rows may have the same LOG_SEQ
value (for different STANDBY_NAME
values).
TIME_GENERATED
The first time when the online redo log file was written to the primary database.
TIME_COMPLETED
The next time when the log file was archived on the primary database (corresponds to the NEXT_CHANGE#
column).
FIRST_CHANGE#
First change number in the archived redo log file.
NEXT_CHANGE#
First change in the next log file.
SIZE (KBs)
The SIZE
of the online redo log file in kilobytes.
For example, the following shows output from a SHOW DATABASE
command:
DGMGRL> SHOW DATABASE 'North_Sales' 'SendQEntries' ; PRIMARY_SEND_QUEUE STANDBY_NAME STATUS RESETLOGS_ID THREAD LOG_SEQ TIME_GENERATED TIME_COMPLETED FIRST_CHANGE# NEXT_CHANGE# SIZE (KBs) DR_Sales ARCHIVED 497198843 1 9 06/20/2003 16:31:59 06/20/2003 16:39:57 210789 211411 186 DR_Sales ARCHIVED 497198843 1 10 06/20/2003 16:39:57 06/20/2003 16:40:01 211411 211415 1 DR_Sales ARCHIVED 497198843 1 11 06/20/2003 16:40:01 06/20/2003 16:40:07 211415 211418 1 CURRENT 497198843 1 12 06/20/2003 16:40:07 211418 1
Note:
Enterprise Manager displays this information on the Log File Details page.The StatusReport
monitorable database property returns a table that provides a list of errors or warnings about the status of the database. In an Oracle RAC database environment, it also includes the status of all running instances. Each individual database has this property. The table contains the following columns in the order shown:
INSTANCE_NAME
The value identifying the SID for the instance.
ERROR_TEXT
Formatted error text.
SEVERITY
The severity of the error message. The value is either WARNING
or ERROR
.
For example, the following shows output from a SHOW DATABASE
command:
DGMGRL> SHOW DATABASE 'North_Sales' 'StatusReport' ; STATUS REPORT INSTANCE_NAME SEVERITY ERROR_TEXT sales1 ERROR ORA-16737: the redo transport service for standby "DR_Sales" has an error * ERROR ORA-16745: unable to add DB_UNIQUE_NAME DR_Sales into the DG_CONFIG list because it is full
The TopWaitEvents
monitorable database property specifies the 5 events with the longest waiting time in the specified instance. The events and their waiting time are retrieved from V$SYSTEM_EVENT
. Each instance in the configuration has this property. This property is an instance level monitorable property. The table contains the following columns in the order shown:
Event
The system wait event.
Wait Time
The total amount of time waited for this event in hundredths of a second.
The following example shows output from a SHOW INSTANCE
command:
DGMGRL> SHOW INSTANCE sales1 'TopWaitEvents'; TOP SYSTEM WAIT EVENTS Event Wait Time rdbms ipc message 671350 SQL*Net message from client 62390 pmon timer 47897 Queue Monitor Wait 43016 wakeup time manager 38508
Configurable database properties control the behavior of databases in a broker configuration. You can view and dynamically update the values of these properties using either DGMGRL or Enterprise Manager. However, some properties can only be updated through DGMGRL.
In most cases, the configurable database property is said to have database scope; meaning the value you set for the property applies uniformly to each instance of the database. However, in a few cases, the configurable database property is said to have instance scope; meaning, for a multiple-instance database environment, it is possible that the values of some particular properties may differ from one instance of the database to the next. Table 9-1 lists each configurable database property and indicates if the scope of the property is database-wide or instance-specific. If the Scope column contains:
Database—The value of the property is database wide, not instance or configuration specific.
Instance—The value of the property is instance specific, not database or configuration specific.
Configuration—The value of the property is configuration wide, not instance or database specific.
Table 9-1 Configurable Properties
Configurable Property Name | Scope | Pertains To |
---|---|---|
|
Instance |
Redo transport services |
|
Database |
Redo Apply and SQL Apply |
|
Database |
Redo Apply |
|
Database |
Redo transport services |
|
Database |
Redo transport services |
|
Configuration |
Fast-start failover |
|
Database |
Redo transport services |
|
Database |
Redo Apply and SQL Apply |
|
Database |
Broker communication, Redo transport services |
FastStartFailoverAutoReinstate |
Configuration |
Fast-start failover |
|
Configuration |
Fast-start failover |
|
Configuration |
Fast-start failover |
|
Database |
Fast-start failover |
|
Configuration |
Fast-start failover |
|
Instance |
Instance identification |
|
Instance |
Redo transport services |
|
Database |
Redo transport services |
|
Database |
Redo transport services |
|
Instance |
Diagnosis |
|
Database |
Redo transport services |
|
Database |
Redo transport services |
|
Database |
Redo transport services |
|
Database |
SQL Apply |
|
Database |
SQL Apply |
|
Database |
SQL Apply |
|
Database |
SQL Apply |
|
Database |
SQL Apply |
|
Database |
SQL Apply |
|
Database |
SQL Apply |
|
Instance |
SQL Apply |
|
Instance |
SQL Apply |
|
Database |
SQL Apply |
|
Database |
SQL Apply |
|
Database |
SQL Apply |
|
Database |
SQL Apply |
|
Database |
Redo transport services |
|
Database |
Redo transport services |
|
Database |
Redo transport services |
|
Database |
Fast-start failover |
|
Database |
Redo Apply and SQL Apply |
|
Database |
Redo transport services |
|
Database |
Redo transport services |
|
Instance |
Instance identification |
|
Instance |
Redo transport services |
|
Database |
Redo Apply and SQL Apply |
See Also:
Chapter 4 for more information about database property managementNote:
When a broker configuration with its primary database is created and standby databases are added to the configuration, the broker imports existing settings from the databases to set many of the properties. If importing an existing setting fails, or if a property value is not imported, then the broker uses a broker default value. The default values and whether or not a property is imported is indicated within each property description.The AlternateLocation
configurable database property specifies an alternate disk location to store the archived redo log files in the standby when the location specified by the StandbyArchiveLocation
configurable database property fails. The property has an instance scope, and the location it specifies has to be accessible by the instance.
Category | Description |
---|---|
Datatype | String |
Valid values | Directory specification on system where the standby instance is located |
Broker default | Empty string |
Imported? | No |
Parameter class | Dynamic |
Role | StandbyFoot 1 |
Standby type | Physical, logical, or snapshot |
Corresponds to |
|
Scope | Instance |
Enterprise Manager name | Alternate Standby Location |
Footnote 1 Although this property is set for the standby instance, it is indirectly related to redo transport services for the primary database. The broker sets up both an alternate local destination on the standby instance and an alternate remote destination on the primary database.
Note:
On a logical standby database, Oracle recommends theLOCATION
attribute of the LOG_ARCHIVE_DEST_
n
initialization parameter for the local destination be different from the value of AlternateLocation
configurable database property.The ApplyInstanceTimeout
configurable database property specifies the number of seconds the broker waits after detecting the current apply instance failed and before initiating the apply instance failover.
Category | Description |
---|---|
Datatype | Integer |
Valid values | >=0 (seconds) |
Broker default | 0 (results in immediate apply instance failover) |
Imported? | No |
Parameter class | Not applicable |
Role | Standby |
Standby type | Physical or logical |
Corresponds to | Not applicable |
Scope | Database |
Enterprise Manager name | Not applicable |
The ApplyParallel
configurable database property specifies whether Redo Apply should use multiple processes to apply redo data to the physical standby database. If Redo Apply is shut off, then setting the property has no immediate effect. However, when Redo Apply is running again, the value of the property is used to determine the parallel apply behavior of Redo Apply.
Category | Description |
---|---|
Datatype | String |
Valid values |
|
Broker default | AUTO |
Imported? | No |
Parameter class | Not applicable |
Role | Standby |
Standby type | Physical |
Corresponds to |
|
Scope | Database |
Enterprise Manager name | Not applicable |
The ArchiveLagTarget
configurable database property limits the amount of data that can be lost and effectively increases the availability of the standby database by forcing a log switch after the amount of time you specify (in seconds) elapses. That way, the standby database will not miss redo records generated from a time range longer than the value set for the ARCHIVE_LAG_TARGET
initialization parameter.
The
Binding
configurable database property specifies whether the standby destination is MANDATORY
or OPTIONAL
.
Category | Description |
---|---|
Datatype | String |
Valid values |
|
Broker default | OPTIONAL |
Imported? | Yes, from the BINDING column of the V$ARCHIVE_DEST view of the primary database |
Parameter class | Dynamic |
Role | StandbyFoot 1 |
Standby type | Physical, logical, or snapshot |
Corresponds to |
|
Scope | Database |
Enterprise Manager name | Not applicable |
Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_
n
value of the primary database.
The BystandersFollowRoleChange
configuration property allows the user to decide whether the broker should determine whether bystander standby databases will be viable standby databases for the new primary database as part of performing a complete failover. Setting the property to ALL
directs the broker to evaluate and detect each standby database that can be a viable standby database to the new primary database, as part of failover processing. Setting the property to NONE
directs the broker to perform failover without evaluating standby database viability. This option decreases the processing time for failover, but disables broker management of all databases in the configuration. You will have to manually reenable the standby databases after failover has completed.
Category | Description |
---|---|
Datatype | String |
Valid value | ALL or NONE |
Broker default | ALL |
Imported? | No |
Parameter class | Not applicable |
Role | Primary and standby |
Standby type | Not applicable |
Corresponds to | Not applicable |
Scope | Broker configuration. This property will be consumed by broker on the database that is the target of a complete failover. |
Enterprise Manager name | Not applicable |
The DbFileNameConvert
configurable database property distinguishes standby datafile filenames from primary datafile filenames. You must set this property on all standby databases. If you add a datafile to the primary database, this property converts the datafile name on the primary database to the datafile on the standby database.
This property is used in the following situations:
At standby mount time, it is used to rename primary datafile filenames to standby datafile filenames if the datafile file path on the standby system is different from the primary database system.
When a new data file is created on the primary database, a corresponding new data file will be created on the standby database if the StandbyFileManagement
configurable database property is set to 'AUTO'
. Oracle uses the data-file file-path mapping information from the DbFileNameConvert
property to determine the standby file path of the new standby data file. If the StandbyFileManagement
property is set to 'MANUAL'
, you must add a corresponding file to the standby database.
Category | Description |
---|---|
Datatype | String |
Valid values | Set the value of this property to a list of string pairs:
For example, Where:
|
Broker default | Empty string |
Imported? | Yes, from the DB_FILE_NAME_CONVERT initialization parameter |
Parameter class | Static |
Role | Standby |
Standby type | Physical |
Corresponds to | DB_FILE_NAME_CONVERT initialization parameter |
Scope | Database |
Enterprise Manager name | DB File Name Convert |
The DelayMins
configurable database property specifies the number of minutes log apply services will delay applying the archived redo log data on the standby database. When the
DelayMins
property is set to the default value of 0 minutes, log apply services apply redo data as soon as possible.
If the DelayMins
property is set to 0, start log apply services as follows:
Start Redo Apply on physical standby databases using the following SQL statement:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
Start SQL Apply on logical standby databases using the following SQL statement:
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Category | Description |
---|---|
Datatype | Integer |
Valid values | >=0 (minutes) |
Broker default | 0 |
Imported? | Yes, from the DELAY_MINS column of the V$ARCHIVE_DEST view of the primary database |
Parameter class | Dynamic |
Role | StandbyFoot 1 |
Standby type | Physical and logical |
Corresponds to |
|
Scope | Database |
Enterprise Manager name | Apply Delay (mins) |
Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_
n
value of the primary database.
The DGConnectIdentifier
configurable database property specifies the connection identifier the broker uses when making connections to a database. If using DGMGRL, you supply the value when you enter the CREATE CONFIGURATION
or ADD DATABASE
command. If using Enterprise Manager, the value is supplied automatically.
The value of this property is specified in the SERVICE
attribute of the LOG_ARCHIVE_DEST_
n parameter when the broker configures redo transport services on the primary database.
Category | Description |
---|---|
Datatype | String |
Valid values | A connect identifier that can be used to connect to this database |
Broker default | Not applicable |
Imported? | No |
Parameter class | Not applicable |
Role | Primary and standby |
Standby type | Physical, logical, or snapshot |
Corresponds to | SERVICE_NAME attribute of the LOG_ARCHIVE_DEST_ n initialization parameter of the primary database |
Scope | Database |
Enterprise Manager name | Not applicable |
Note:
Prior to Oracle Database release 11.1, theDGConnectIdentifier
configurable database property was known as the InitialConnectIdentifier
property. When upgrading a 10g configuration to Oracle Database release 11.1, the InitialConnectIdentifier
value will be retained as the new DGConnectIdentifier
value for that database. Before the upgrade, you must ensure that the InitialConnectIdentifier
will reach all instances if this is an Oracle RAC database.The FastStartFailoverAutoReinstate
configuration property allows the user to decide whether the observer should automatically reinstate the old primary after a fast-start failover occurred because the primary database either crashed or lost connectivity with the observer and target standby database. The former primary database is never automatically reinstated if a fast-start failover occurred because a user configurable condition was detected or was requested by an application by calling the DBMS_DG.INITIATE_FS_FAILOVER
function. In some cases, an automatic reinstatement might not be wanted until further diagnostic or recovery work is done.
Category | Description |
---|---|
Datatype | Boolean |
Valid value | TRUE or FALSE |
Broker default | TRUE |
Imported? | No |
Parameter class | Not applicable |
Role | Primary and standby |
Standby type | Not applicable |
Corresponds to | Not applicable |
Scope | Broker configuration. This property will be consumed by the observer after fast-start failover has been enabled. |
Enterprise Manager name | Automatically Reinstate Primary |
The FastStartFailoverLagLimit
configuration property establishes an acceptable limit, in seconds, that the standby is allowed to fall behind the primary in terms of redo applied, beyond which a fast-start failover will not be allowed. The lowest possible value is 10 seconds.
This property is used when fast-start failover is enabled and the configuration is operating in maximum performance mode.
Category | Description |
---|---|
Datatype | Integer |
Valid value | Integral number of seconds. Must be greater than, or equal to, 10. |
Broker default | 30 seconds |
Imported? | No |
Parameter class | Not applicable |
Role | Primary and standby |
Standby type | Not applicable |
Corresponds to | Not applicable |
Scope | Broker configuration. This property will be consumed by the observer after fast-start failover has been enabled. |
Enterprise Manager name | Lag Limit |
The FastStartFailoverPmyShutdown
configuration property allows the user to decide whether the primary database shuts down if redo generation has stalled and the primary database has lost connectivity with the observer and target standby database for longer than FastStartFailoverThreshold
seconds. The primary database always shuts down if fast-start failover occurred because a user configurable condition was detected or was requested by an application by calling the DBMS_DG.INITIATE_FS_FAILOVER
function.
Category | Description |
---|---|
Datatype | Boolean |
Valid value | TRUE or FALSE |
Broker default | TRUE |
Imported? | No |
Parameter class | Not applicable |
Role | Primary and standby |
Standby type | Not applicable |
Corresponds to | Not applicable |
Scope | Broker configuration. This property will be consumed by the observer after fast-start failover has been enabled. |
Enterprise Manager name | Automatically Shutdown Primary |
The FastStartFailoverTarget
configuration property specifies the DB_UNIQUE_NAME
of the database that will be the target of a fast-start failover when this database is the primary database. See Step 2 in Section 5.5.2 for more information about setting this property.
Category | Description |
---|---|
Datatype | String |
Valid value | DB_UNIQUE_NAME of the database that is the target of the fast-start failover. |
Broker default | If only one physical or logical standby database exists, then the broker selects that as the default value for this property on the primary database when fast-start failover is enabled. If more than one physical or logical standby database exists, you must specify the FastStartFailoverTarget value explicitly, prior to enabling fast-start failover.
For the target standby database, the broker automatically selects the current primary database as the value for this property when fast-start failover is enabled. |
Imported? | No |
Parameter class | Not applicable |
Role | Primary or standby |
Standby type | Physical or logical |
Corresponds to | Not applicable |
Scope | Database |
Enterprise Manager name | Enterprise Manager displays the value for the current primary database on the Data Guard Overview page, along with whether or not fast-start failover has been enabled. |
The FastStartFailoverThreshold
configuration property defines the number of seconds the observer attempts to reconnect to the primary database before initiating a fast-start failover to the target standby database. The time interval starts when the observer first loses connection with the primary database. If the observer is unable to regain a connection to the primary database within the specified time, then the observer initiates a fast-start failover. See Step 4 in Section 5.5.2 for more information about setting this property. The observer ignores the threshold completely if a configurable fast-start condition is detected or an application has requested that fast-start failover be initiated.
Category | Description |
---|---|
Datatype | Integer |
Valid value | Integral number of seconds. Must be greater than, or equal to, 6. |
Broker default | 30 seconds |
Imported? | No |
Parameter class | Not applicable |
Role | Target standby database that is about to fail over to the primary role |
Standby type | Not applicable |
Corresponds to | Not applicable |
Scope | Broker configuration. This property will be consumed by the observer after fast-start failover has been enabled. |
Enterprise Manager name | Oracle Enterprise Manager presents this as "Failover Threshold" on the Data Guard Overview page. |
The HostName
configurable database property specifies the name of the host on which the instance that is specified by SidName
configurable database property is running. You can update this property only when broker management of the database is disabled. You should only update the value when the host is renamed, in which case you need to disable broker management of the database, update the HostName
property to match with the new host name, and then reenable broker management of the database.
Note:
If the instance that is specified by theSidName
property is started on a different host than was specified by HostName
, the broker updates the value in HostName
to match the actual name of the host, and broker management of the database may proceed.Category | Description |
---|---|
Datatype | String |
Valid values | Name of the host on which the instance is running |
Broker default | Not applicable |
Imported? | Yes |
Parameter class | Not applicable |
Role | Primary and standby |
Standby type | Physical, logical, or snapshot |
Corresponds to | HOST_NAME column of the V$INSTANCE view |
Scope | Instance |
Enterprise Manager name | Not applicable |
The LogArchiveFormat
configurable database property specifies the format for filenames of archived redo log files using a database ID (
%d
), thread (%t
), sequence number (%s
), and resetlogs ID (%r
).
Category | Description |
---|---|
Datatype | String |
Valid values | %d_%t_%s_%r |
Broker default | Empty string |
Imported? | Yes, from the LOG_ARCHIVE_FORMAT initialization parameter on the primary database |
Parameter class | Static |
Role | Primary and standby |
Standby type | Physical, logical, or snapshot |
Corresponds to | LOG_ARCHIVE_FORMAT initialization parameter |
Scope | Instance |
Enterprise Manager name | Not applicable |
The LogArchiveMaxProcesses
configurable database property specifies the initial number of archiver processes (ARCn) the Oracle database invokes. The actual number of archiver processes in use may increase subsequently based on the archiving workload.
Category | Description |
---|---|
Datatype | Integer |
Valid values | 1 to 30 |
Broker default | 4 |
Imported? | Yes, from the LOG_ARCHIVE_MAX_PROCESSES initialization parameter |
Parameter class | Dynamic |
Role | Primary and standby |
Standby type | Physical, logical, or snapshot |
Corresponds to | LOG_ARCHIVE_MAX_PROCESSES initialization parameter |
Scope | Database |
Enterprise Manager name | Archiver Processes |
The LogArchiveMinSucceedDest
configurable database property controls when online redo log files are available for reuse. For the online redo log files to be available for reuse, archiving must succeed to a minimum number of destinations.
Category | Description |
---|---|
Datatype | Integer |
Valid values | 1 to 10 |
Broker default | 1 |
Imported? | Yes, from the LOG_ARCHIVE_MIN_SUCCEED_DEST initialization parameter |
Parameter class | Dynamic |
Role | Primary |
Standby type | Not applicable |
Corresponds to | LOG_ARCHIVE_MIN_SUCCEED_DEST initialization parameter |
Scope | Database |
Enterprise Manager name | Not applicable |
Set the
LogArchiveTrace
configurable database property to an integer value to see the progression of the archiving of online redo log files on the primary and the standby databases. The Oracle database writes an audit trail of the archived redo log files received from the primary database into process trace files.
Category | Description |
---|---|
Datatype | Integer |
Valid values | A valid value is the sum of any combination of any of the following values:
0: Disable archive redo log tracing 1: Track archiving of online redo log file 2: Track archiving status of each archive redo log destination 4: Track archiving operational phase 8: Track 16: Track detailed 32: Track 64: Track ARC 128: Track FAL (fetch archive log) server related activities 256: Tracks RFS Logical Client 512: Tracks LGWR redo shipping network activity 1024: Tracks RFS physical client 2048: Tracks RFS/ARCn ping heartbeat 4096: Tracks real-time apply activity 8192: Tracks Redo Apply (media recovery or physical standby) |
Broker default | 255 |
Imported? | Yes, from the LOG_ARCHIVE_TRACE initialization parameter |
Parameter class | Dynamic |
Role | Primary and standby |
Standby type | Physical, logical, or snapshot |
Corresponds to | LOG_ARCHIVE_TRACE initialization parameter |
Scope | Instance |
Enterprise Manager name | Log Archive Trace |
The LogFileNameConvert
configurable database property converts the filename of an online redo log file on the primary database to the filename of a corresponding online redo log file on the standby database.
Category | Description |
---|---|
Datatype | String |
Valid values | Set the value of this property to a list of an even number of string pairs, separated by commas.
For example, Where:
|
Broker default | Empty string |
Imported? | Yes, from the LOG_FILE_NAME_CONVERT initialization parameter |
Parameter class | Static |
Role | Standby |
Standby type | Physical |
Corresponds to | LOG_FILE_NAME_CONVERT initialization parameter |
Scope | Database |
Enterprise Manager name | Log File Name Convert |
The
LogShipping
configurable database property specifies whether or not redo transport services can send archived redo log files to the particular standby database. The broker uses the value of the LogShipping
property only when the primary database is in the TRANSPORT-ON
state:
If the primary database is in the TRANSPORT-OFF
state, then redo transport services to all standby databases are disabled, regardless of whether or not the LogShipping
property is set to ON
or OFF
.
If the primary database is in the TRANSPORT-ON
state and the value of the LogShipping
property is ON
, then redo transport services are enabled to send archived redo data to the particular standby database. If the LogShipping
property is OFF
, then redo transport services are disabled to send archived redo data to the particular standby database.
Category | Description |
---|---|
Datatype | String |
Valid values | ON or OFF |
Broker default | ON |
Imported? | No |
Parameter class | Dynamic |
Role | StandbyFoot 1 |
Standby type | Physical, logical, or snapshot |
Corresponds to | ENABLE and DEFER values for the LOG_ARCHIVE_DEST_STATE_ n initialization parameter of the primary database |
Scope | Database |
Enterprise Manager name | Log Shipping |
Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_
n value of the primary database.
The LogXptMode
configurable database property enables you to set the redo transport service. You set the redo transport services on each standby database to one of the following modes:
Configures redo transport services for this standby database using the SYNC
and AFFIRM
attributes of the LOG_ARCHIVE_DEST_
n
initialization parameter. Standby redo log files are required. This mode is required for the maximum protection or maximum availability data protection modes. This redo transport service enables the highest grade of data protection to the primary database, but also incurs the highest performance impact.
Configures redo transport services for this standby database using the ASYNC
and NOAFFIRM
attributes of the LOG_ARCHIVE_DEST_
n
initialization parameter. Standby redo log files are required. This mode enables a moderate grade of data protection to the primary database, and incurs a lower performance impact than SYNC
.
Category | Description |
---|---|
Datatype | String |
Valid values | SYNC or ASYNC |
Broker default | ASYNC |
Imported? | Yes, from the ARCHIVER , TRANSMIT_MODE , and AFFIRM columns of V$ARCHIVE_DEST view of the primary database |
Parameter class | Dynamic |
Role | StandbyFoot 1 |
Standby type | Physical, logical, or snapshot |
Corresponds to |
|
Scope | Database |
Enterprise Manager name | Redo Transport Service |
Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_
n
value of the primary database.
See Also:
Chapter 4 for more information about setting data protection modes for redo transport servicesThe LsbyASkipCfgPr
configurable database property provides a way to add a skip specification to SQL Apply to control the apply service to skip (ignore) SQL statements that you do not want to apply to the logical standby database. The SKIP
operation:
Sets the criteria for identifying the SQL statements that will not be applied to the standby database
Specifies any additional processing that will be done, if necessary
Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.
Category | Description |
---|---|
Datatype | String |
Valid values | A valid set of arguments to the DBMS_LOGSTDBY.SKIP procedure |
Broker default | Empty string |
Imported? | No |
Parameter class | Dynamic; SQL Apply does not require restart |
Role | Standby |
Standby type | Logical |
Corresponds to | DBMS_LOGSTDBY.SKIP procedure |
Scope | Database |
Enterprise Manager name | Add Skip Table Entries |
The LsbyASkipErrorCfgPr
configurable database property adds a skip error specification to SQL Apply. It provides criteria to determine if an error should cause SQL Apply to stop. All errors to be skipped are stored in system tables that describe how exceptions should be handled.
Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.
Category | Description |
---|---|
Datatype | String |
Valid values | A valid set of arguments to the DBMS_LOGSTDBY.SKIP_ERROR procedure. The string must contain comma separators between the arguments. |
Broker default | Empty string |
Imported? | No |
Parameter class | Dynamic; SQL Apply does not require restart |
Role | Standby |
Standby type | Logical |
Corresponds to | DBMS_LOGSTDBY.SKIP_ERROR procedure |
Scope | Database |
Enterprise Manager name | Add Skip Table Entries |
The LsbyASkipTxnCfgPr
configurable database property skips over a transaction that caused SQL Apply to stop applying transactions to the logical standby database. This property enables you to specify the transaction ID (XIDSQN NUMBER
) of the problematic transaction that you want SQL Apply to ignore. Before you restart SQL Apply, you should issue a SQL transaction that will correctly update the logical standby database in place of the skipped transaction. Applying a compensating transaction will help keep the logical standby database transactionally consistent with the primary database.
Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.
Category | Description |
---|---|
Datatype | String |
Valid values | A valid set of arguments to the DBMS_LOGSTDBY.SKIP_TRANSACTION procedure. Use comma separators between the arguments. |
Broker default | Empty string |
Imported? | No |
Parameter class | Dynamic; SQL Apply does not require restart |
Role | Standby |
Standby type | Logical |
Corresponds to | DBMS_LOGSTDBY.SKIP_TRANSACTION procedure |
Scope | Database |
Enterprise Manager name | Skip Edit Properties |
Note:
Enterprise Manager indirectly supports skipping a transaction using the Skip Edit Properties page.The LsbyDSkipCfgPr
configurable database property deletes an existing skip specification from SQL Apply. It reverses or removes the actions of the LsbyASkipCfgPr property by finding the record, matching all the parameters, and removing the record from the system table. The match must be exact, and multiple skip actions can be removed only by a matching number of unskip actions. You cannot remove multiple skip actions by using wildcard characters as a value to this property.
Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.
Category | Description |
---|---|
Datatype | String |
Valid Values | A valid set of arguments to the DBMS_LOGSTDBY.UNSKIP procedure |
Broker Default | Empty string |
Imported? | No |
Parameter Class | Dynamic; SQL Apply does not require restart |
Role | Standby |
Standby type | Logical |
Corresponds to | DBMS_LOGSTDBY.UNSKIP procedure |
Scope | Database |
Enterprise Manager name | Remove Skip Table Entries |
The LsbyDSkipErrorCfgPr
configurable database property deletes an existing skip error specification from SQL Apply. It reverses or removes the actions of the LsbyASkipErrorCfgPr property by finding the record, matching all of the parameters and removing the record from the system table. The match must be exact, and multiple skip actions can be removed only by a matching number of unskip actions. You cannot remove multiple skip actions by using wildcard characters as a value to this property.
Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.
Category | Description |
---|---|
Datatype | String |
Valid values | A valid set of arguments to the DBMS_LOGSTDBY.UNSKIP_ERROR procedure. The string must contain comma separators between the arguments. |
Broker default | Empty string |
Imported? | No |
Parameter class | Dynamic; SQL Apply does not require restart |
Role | Standby |
Standby type | Logical |
Corresponds to | DBMS_LOGSTDBY.UNSKIP_ERROR procedure |
Scope | Database |
Enterprise Manager name | Remove Skip Table Entries |
The LsbyDSkipTxnCfgPr
configurable database property reverses or removes the actions of the LsbyASkipTxnCfgPr property. The transaction IDs must match exactly, and multiple skip transaction actions can be removed only by a matching number of unskip transaction actions. You cannot remove multiple skip transaction actions by using wildcard characters as a value to this property.
Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.
Category | Description |
---|---|
Datatype | String |
Valid values | A valid set of arguments to the DBMS_LOGSTDBY.UNSKIP_TRANSACTION procedure |
Broker default | Empty string |
Imported? | No |
Parameter class | Dynamic; SQL Apply does not require restart |
Role | Standby |
Standby type | Logical |
Corresponds to | DBMS_LOGSTDBY.UNSKIP_TRANSACTION procedure |
Scope | Database |
Enterprise Manager name | Not applicable |
The LsbyMaxEventsRecorded
configurable database property specifies the number of events that will be stored in the DBA_LOGSTDBY_EVENTS
table, which stores logical standby event information.
Category | Description |
---|---|
Datatype | Integer |
Valid values | >=0 |
Broker default | 0 |
Imported? | Yes, from the MAX_EVENTS_RECORDED row of SYSTEM.LOGSTDBY$PARAMETERS |
Parameter class | Dynamic; SQL Apply does not require restart |
Role | Standby |
Standby type | Logical |
Corresponds to | DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED') and the DBMS_LOGSTDBY.APPLY_UNSET('MAX_EVENTS_RECORDED') procedures |
Scope | Database |
Enterprise Manager name | Max Events Recorded |
The LsbyMaxSga
configurable database property specifies the number of megabytes for the allocation of SQL Apply cache in the system global area (SGA). If the value is 0, SQL Apply uses one quarter of the value set for the SHARED_POOL_SIZE
initialization parameter.
Category | Description |
---|---|
Datatype | Integer |
Valid values | >=0 |
Broker default | 0 |
Imported? | Yes, from the MAX_SGA row of SYSTEM.LOGSTDBY$PARAMETERS |
Parameter class | Dynamic; SQL Apply does not require restart |
Role | Standby |
Standby type | Logical |
Corresponds to | DBMS_LOGSTDBY.APPLY_SET('MAX_SGA') and the DBMS_LOGSTDBY.APPLY_UNSET('MAX_SGA') procedures |
Scope | Instance |
Enterprise Manager name | Max SGA (MB) |
The LsbyMaxServers
configurable database property specifies the number of parallel query servers specifically reserved for SQL Apply. If the value is 0, SQL Apply uses all available parallel query servers to read the log files and apply changes.
Category | Description |
---|---|
Datatype | Integer |
Valid values | >=0 |
Broker default | 0 |
Imported? | Yes, from the MAX_SERVERS row of SYSTEM.LOGSTDBY$PARAMETERS |
Parameter class | Dynamic; SQL Apply does not require restart |
Role | Standby |
Standby type | Logical |
Corresponds to | DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS') and the DBMS_LOGSTDBY.APPLY_UNSET('MAX_SERVERS') procedures |
Scope | Instance |
Enterprise Manager name | Max Servers |
The LsbyRecordAppliedDdl
configurable database property controls whether or not DDL statements that were applied to the logical standby database are recorded in the DBA_LOGSTDBY_EVENTS
table. Specify one of the following values:
TRUE
: DDL statements applied to the logical standby database are recorded in the DBA_LOGSTDBY_EVENTS
table. This is the default setting.
FALSE
: Applied DDL statements are not recorded.
Category | Description |
---|---|
Datatype | String |
Valid values | TRUE or FALSE |
Broker default | TRUE |
Imported? | Yes, from the RECORD_APPLIED_DDL row of SYSTEM.LOGSTDBY$PARAMETERS |
Parameter class | Dynamic; SQL Apply does not require restart |
Role | Standby |
Standby type | Logical |
Corresponds to | DBMS_LOGSTDBY.APPLY_SET('RECORD_APPLIED_DDL') and the DBMS_LOGSTDBY.APPLY_UNSET('RECORD_APPLIED_DDL') procedures |
Scope | Database |
Enterprise Manager name | Record Applied DDL |
The LsbyRecordSkipDdl
configurable database property controls whether or not skipped DDL statements are recorded in the DBA_LOGSTDBY_EVENTS
table. Specify one of the following values:
TRUE
: Skipped DDL statements are recorded in the DBA_LOGSTDBY_EVENTS
table. This is the default setting.
FALSE
: Skipped DDL statements are not recorded in the DBA_LOGSTDBY_EVENTS
table.
Category | Description |
---|---|
Datatype | String |
Valid values | TRUE or FALSE |
Broker default | TRUE |
Imported? | Yes, from the RECORD_SKIP_DDL row of SYSTEM.LOGSTDBY$PARAMETERS |
Parameter class | Dynamic; SQL Apply does not require restart |
Role | Standby |
Standby type | Logical |
Corresponds to | DBMS_LOGSTDBY.APPLY_SET('RECORD_SKIP_DDL') and the DBMS_LOGSTDBY.APPLY_UNSET('RECORD_SKIP_DDL') procedures |
Scope | Database |
Enterprise Manager name | Record Skip DDL |
The LsbyRecordSkipErrors
configurable database property controls whether or not skipped errors (as described by the DBMS_LOGSTDBY.SKIP_ERROR
procedure) are recorded in the DBA_LOGSTDBY_EVENTS
table. Specify one of the following values:
TRUE
: Skipped errors are recorded in the DBA_LOGSTDBY_EVENTS
table.
FALSE
: Skipped errors are not recorded in the DBA_LOGSTDBY_EVENTS
table.
Category | Description |
---|---|
Datatype | String |
Valid values | TRUE or FALSE |
Broker default | TRUE |
Imported? | Yes, from the RECORD_SKIP_ERRORS row of SYSTEM.LOGSTDBY$PARAMETERS |
Parameter class | Dynamic; SQL Apply does not require restart |
Role | Standby |
Standby type | Logical |
Corresponds to | DBMS_LOGSTDBY.APPLY_SET('RECORD_SKIP_ERRORS') and the DBMS_LOGSTDBY.APPLY_UNSET('RECORD_SKIP_ERRORS') procedures |
Scope | Database |
Enterprise Manager name | Record Skip Errors |
The LsbyPreserveCommitOrder
configurable database property controls whether transactions are committed on the logical standby database in the exact same order in which they were committed on the primary database. Specify one of the following values:
TRUE
: Transactions are applied to the logical standby database in the exact order in which they were committed on the primary database. This option may affect performance.
FALSE
: Transactions may be committed out of order and no attempt is made to provide read-consistent results. This results in better performance. If applications reading the logical standby database make no assumptions about transaction order, this option works well.
Category | Description |
---|---|
Datatype | String |
Valid values | TRUE or FALSE |
Broker default | TRUE |
Imported? | Yes, from the PRESERVE_COMMIT_ORDER row of SYSTEM.LOGSTDBY$PARAMETERS |
Parameter class | Static; SQL Apply requires restart |
Role | Standby |
Standby type | Logical |
Corresponds to | DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER') and DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER') procedures |
Scope | Database |
Enterprise Manager name | Preserve Commit Order |
The MaxConnections
configurable database property specifies how many ARCn processes will be used in parallel to transmit redo data from a single archived redo log on the primary database to the archived redo log at the remote site. If the MaxConnections
property is set to a nonzero value, redo transport services use multiple ARCn processes to transmit redo data to archived redo log files at the remote destinations.
Category | Description |
---|---|
Datatype | Integer |
Valid values | >=0 |
Broker default | 0 |
Imported? | Yes, from the MAX_CONNECTIONS column of the V$ARCHIVE_DEST view for the primary database. |
Parameter class | Dynamic |
Role | Standby |
Standby type | Physical, logical, or snapshot |
Corresponds to |
|
Footnote 1 The LOG_ARCHIVE_MAX_PROCESSES
initialization parameter affects the actual number of ARCn processes used by an instance.
The MaxFailure
configurable database property specifies the maximum number of contiguous archiving failures before the redo transport services stop trying to transport archived redo log files to the standby database. A value of zero indicates that an unlimited number of failures are allowed.
Category | Description |
---|---|
Datatype | Integer |
Valid values | >=0 |
Broker default | 0 |
Imported? | Yes, from the MAX_FAILURE column of V$ARCHIVE_DEST view of the primary database |
Parameter class | Dynamic |
Role | StandbyFoot 1 |
Standby type | Physical, logical, or snapshot |
Corresponds to |
|
Scope | Database |
Enterprise Manager name | Not applicable |
Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_
n value of the primary database.
The NetTimeout
configurable database property specifies the number of seconds the LGWR waits for Oracle Net Services to respond to a LGWR request. It is used to bypass the long connection timeout in TCP. This property is only used when the LogXptMode
configurable database property of the same database is set to SYNC
or ASYNC
. Data Guard broker also uses this value to timeout its own network communication between databases in the configuration.
Category | Description |
---|---|
Datatype | Integer |
Valid values | 0, 15 to 1200 |
Broker default | 180 |
Imported? | Yes, from the NET_TIMEOUT column of V$ARCHIVE_DEST view of the primary database |
Parameter class | Dynamic |
Role | Primary and Standby |
Standby type | Physical, logical, or snapshot |
Corresponds to |
|
Scope | Database |
Enterprise Manager name | Not applicable |
The ObserverConnectIdentifier
configurable database property specifies a connect identifier that can be used by the observer to connect to this database. This can pertain only to the primary database, or to the target standby database when fast-start failover is enabled.
Category | Description |
---|---|
Datatype | String |
Valid Values | A connect identifier that observer can use to connect to this database |
Broker Default | Empty StringFoot 1 |
Imported? | No |
Parameter Class | Not applicable |
Role | Primary and Standby |
Standby Type | Physical or logical |
Corresponds to | Not applicable |
Scope | Database |
Enterprise Manager name | Observer Connect Identifier |
Footnote 1 When this is Empty String (not set by the user), the connect identifier specified by this database's DGConnectIdentifier property will be used by the observer.
The PreferredApplyInstance
configurable database property indicates that a particular instance is the preferred choice for serving log apply services. It is only used when the database is a standby RAC database. The value could be an empty string (default) which means the broker chooses the apply instance.
Category | Description |
---|---|
Datatype | String |
Valid Values | The instance name (SID) or empty string |
Broker Default | Empty string |
Imported? | No |
Parameter Class | Not applicable |
Role | Standby |
Standby Type | Physical or logical |
Corresponds to | Not applicable |
Scope | Database |
Enterprise Manager name | Apply Instance |
See Also:
Section 4.5.7 for more informationThe RedoCompression
configurable database property specifies whether network compression is enabled or disabled. When network compression is enabled, Data Guard compresses archived redo logs as they are transmitted over the network to standby databases.
Category | Description |
---|---|
Datatype | String |
Valid value | DISABLE or ENABLE |
Broker Default | DISABLE |
Imported? | Yes, from the COMPRESSION column of the V$ARCHIVE_DEST view of the primary database |
Parameter class | Dynamic |
Role | StandbyFoot 1 |
Standby type | Physical, logical, or snapshot |
Corresponds to |
|
Scope | Database |
Enterprise Manager name | Not applicable |
Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_
n
value of the primary database.
The ReopenSecs
configurable database property specifies the minimum number of seconds before the archiver process (ARCn, foreground, or log writer process) should try again to access a previously failed destination.
Category | Description |
---|---|
Datatype | Integer |
Valid values | >=0 seconds |
Broker default | 300 |
Imported? | Yes, from the REOPEN_SECS column of V$ARCHIVE_DEST view of the primary database |
Parameter class | Dynamic |
Role | StandbyFoot 1 |
Standby type | Physical, logical, or snapshot |
Corresponds to |
|
Scope | Database |
Enterprise Manager name | Not applicable |
Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_
n
value of the primary database.
The SidName
configurable database property specifies the SID of the instance. The property can only be updated when broker management of the database is disabled. You should only update the value when the SID is changed, in which case you need to disable broker management of the database, update the SidName
property to match with the new SID, and reenable broker management of the database.
Note:
If no existing instance object in the broker configuration, for the database object whose name matches this instance'sdb_unique_name
, has a SidName
property with a value that matches this instance's actual SID
, then the broker will create a new instance object for this database that has this instance's db_unique_name
. See Section 1.3, "Data Guard Broker Management Model" for more information.Category | Description |
---|---|
Datatype | String |
Valid values | SID of the instance |
Broker default | Not applicable |
Imported? | Yes |
Parameter class | Not applicable |
Role | Primary and standby |
Standby type | Physical, logical, or snapshot |
Corresponds to | INSTANCE_NAME column of the V$INSTANCE view |
Scope | Instance |
Enterprise Manager name | Not applicable |
The StandbyArchiveLocation
configurable database property specifies the location of archived redo log files arriving from a primary database. Oracle recommends that you always explicitly set the value.
Category | Description |
---|---|
Datatype | String |
Valid values | Nonempty file specification of the location of archived redo log files on the standby database. Use DB_RECOVERY_FILE_DEST if database recovery area is desired. |
Broker default | dgsby_ db_unique_name |
Imported? | Yes, from the DESTINATION column of the V$ARCHIVE_DEST fixed view of the standby database where the destination is a local destination and where the VALID_FOR attribute is compatible with the string (STANDBY_ROLE, STANDBY_LOGFILE) ; if no such destination exists, import is from the STANDBY_ARCHIVE_DEST initialization parameter |
Parameter class | Dynamic |
Role | Standby |
Standby type | Physical, logical, or snapshot |
Corresponds to |
|
Scope | Instance |
Enterprise Manager name | Standby Archive Location |
Note:
On a logical standby database, Oracle recommends theLOCATION
attribute of the LOG_ARCHIVE_DEST_
n initialization parameter for the local destination be different from the value of StandbyArchiveLocation
property, unless you are using database recovery area.The StandbyFileManagement
configurable database property affects how the add datafile operation on the primary database is applied on the standby database. If this property is set to AUTO
, in conjunction with valid settings in the DbFileNameConvert
configurable database property, a corresponding new datafile is automatically created on the standby database. The location of this new standby datafile is determined by the value of the DbFileNameConvert
property.
If this property is set to MANUAL
, you have to create the correct new datafile on the standby database manually.
Category | Description |
---|---|
Datatype | String |
Valid values | AUTO or MANUAL |
Broker default | AUTO |
Imported? | Yes, from the STANDBY_FILE_MANAGEMENT initialization parameter |
Parameter class | Dynamic |
Role | Standby |
Standby type | Physical, logical, or snapshot |
Corresponds to | STANDBY_FILE_MANAGEMENT initialization parameter |
Scope | Database |
Enterprise Manager name | Not applicable |