this chapter describes the various configuration and database properties that help you view and control the behavior of entire broker configurations, individual databases, redo transport services, and log apply services.
this chapter discusses the following topics:
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#chebhgfb">configuration properties</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i90558">monitorable (read-only) database properties</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i103444">configurable database properties</a>
properties have either configuration-wide scope, database-wide scope, or instance-specific scope. configuration-wide properties control the behavior of the broker on all databases in the configuration. the values of such properties apply uniformly across all databases in the configuration.
database-wide properties allow you to view or control the behavior of a specific database. 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 instances of that database.
instance-specific properties allow you to view or control the behavior of an individual database instance. such a property exists for all instances of an oracle 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.
<a></a>
configuration properties control the behavior of the 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.
a configuration property has configuration-wide scope; meaning that the value you set for the property applies uniformly to each database in the configuration.
the following sections describe the configuration properties:
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#babeagji">bystandersfollowrolechange</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#cacfghfh">communicationtimeout</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#chebjedb">externaldestination1</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#cheeghcf">externaldestination2</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#babedaag">faststartfailoverautoreinstate</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#babhbaec">faststartfailoverlaglimit</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#babcdhde">faststartfailoverpmyshutdown</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#babehddc">faststartfailoverthreshold</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#chejhbhj">observeroverride</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#chefbcge">observerreconnect</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#chefibia">operationtimeout</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#chefaach">primarylostwriteaction</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#chebhfbc">tracelevel</a>
the <code>bystandersfollowrolechange</code> 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 <code>all</code> 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 <code>none</code> 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. if fast-start failover is enabled, the observer will automatically reinstate the standby databases after failover has completed. otherwise, you will have to manually reinstate the standby databases after failover has completed.
category description
datatype
string
valid value
<code>all</code> or <code>none</code>
broker default
<code>all</code>
imported?
no
parameter class
not applicable
role
primary and standby
standby type
corresponds to
scope
broker configuration. this property will be consumed by broker on the database that is the target of a complete failover.
enterprise manager name
the <code>communicationtimeout</code> configuration property allows you to decide how many seconds the broker should wait before timing out its network communication between databases in the configuration. a value of zero indicates that a network communication should never be timed out.
integer
valid values
>= 0
180 seconds
broker configuration. this property will be consumed by broker on all databases in the configuration.
the <code>externaldestination1</code> configuration property is used to specify a redo transport destination that can receive redo data from the current primary database. to set up transport of redo data to the specified destination, the broker uses the values specified for this parameter to define a <code>log_archive_dest_</code><code>n</code>initialization parameter on the primary database. the broker also monitors the health of the transport to the specified destination.
after a role change, the broker automatically sets up a <code>log_archive_dest_</code><code>n</code> initialization parameter on the new primary database to ship redo data to the specified destination.
any <code>log_archive_dest_</code><code>n</code> attributes, with the exception of the following:
<code>alternate</code>
<code>location</code>
<code>max_failures</code>
<code>sync</code>
<code>valid_for</code>
<code>template</code>
<code>mandatory</code>
<code>delay</code>
<code>net_timeout</code>
empty string
primary
configuration
the <code>externaldestination2</code> configuration property is used to specify a redo transport destination that can receive redo data from the current primary database. to set up transport of redo data to the specified destination, the broker uses the values specified for this parameter to define a <code>log_archive_dest_</code><code>n</code>initialization parameter on the primary database. the broker also monitors the health of the transport to the specified destination.
the <code>faststartfailoverautoreinstate</code> configuration property causes the former primary database to be automatically reinstated if a fast-start failover was initiated because the primary database was either isolated or had crashed. to prevent automatic reinstatement of the former primary database in these cases, set this configuration property to <code>false</code>.
the broker never automatically reinstates the former primary database if a fast-start failover was initiated because a user configuration condition was detected or was requested by an application calling the<code>dbms_dg.initiate_fs_failover</code> function.
boolean
<code>true</code> or <code>false</code>
<code>true</code>
broker configuration. this property will be consumed by the observer after fast-start failover has been enabled.
automatically reinstate primary
the <code>faststartfailoverlaglimit</code> 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.
integral number of seconds. must be greater than, or equal to, 10.
30 seconds
broker configuration. this property will be consumed by the primary database after fast-start failover has been enabled.
lag limit
the <code>faststartfailoverpmyshutdown</code> configuration property causes the primary database to shut down if fast-start failover is enabled and <code>v$database.fs_failover_status</code> indicates the primary has been <code>stalled</code>for longer than <code>faststartfailoverthreshold</code> seconds. in such a situation, it is likely that the primary has been isolated and a fast-start failover has already occurred. a value of <code>true</code> helps to ensure that an isolated primary database cannot satisfy user queries.
setting this property to <code>false</code> will not prevent the primary database from shutting down if a fast-start failover occurred because a user configuration condition was detected or was requested by an application by calling the <code>dbms_dg.initiate_fs_failover</code> function.
automatically shutdown primary
the observer ignores the threshold completely if a configurable fast-start failover condition is detected or an application has requested that fast-start failover be initiated.
integral number of seconds. must be greater than, or equal to, 6.
target standby database that is about to fail over to the primary role
oracle enterprise manager presents this as "failover threshold" on the data guard overview page.
the <code>observeroverride</code> configuration property is available only in oracle database 11g release 2 (11.2.0.4) and higher.
<code>false</code>
the <code>observerreconnect</code> configuration property is available only in oracle database 11g release 2 (11.2.0.4) and higher.
>=0
the <code>operationtimeout</code> configuration property specifies the maximum amount of time the broker should wait for health check, get monitorable property, and set property operations to complete.
>= 30 and <= 600
<code>continue</code> - the primary database continues operating if a standby database detects that a lost write has occurred at the primary database. this is the default action.
<code>shutdown</code> - the primary database performs a shutdown abort if a standby database detects that a lost write has occurred at the primary database.
fast start failover is disabled if a standby detects that a lost write has occurred at the primary database. automatic failover will therefore not occur if a standby detects that a lost write has occurred at the primary database, even if <code>primarylostwriteaction</code> is set to <code>shutdown</code>.
diagnostic information is written to the database alert and broker logs at the primary database and at the standby database where the lost write was detected.
the <code>primarylostwriteaction</code> configuration property is available only in oracle database 11g release 2 (11.2.0.4).
the <code>db_lost_write_protect</code> database initialization parameter must be set to <code>typical</code> or <code>full</code> at the primary database and at each standby database in the configuration to ensure that lost primary writes can be detected by all standby databases in the configuration.
<code>continue</code> or <code>shutdown</code>
<code>continue</code>
broker configuration
the <code>tracelevel</code> configuration property is used to control the amount of tracing performed by the broker for every member in the configuration. setting the property to <code>user</code> limits the tracing to completed operations and to any warning or error messages resulting from an operation or health check. setting the property to <code>support</code>increases the amount of tracing to include lower-level information needed by oracle support services.
the <code>tracelevel</code> configuration property is available only in oracle database 11g release 2 (11.2.0.3) and higher.
<code>user</code>, <code>support</code>
<code>user</code>
database
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, <code>logxptstatus</code> may show <code>instance1</code> transmitting redo data to <code>standby2</code> has an error and <code>instance2</code> transmitting redo data to<code>standby4</code> has an error.
the following sections describe the monitorable database properties:
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i99516">inconsistentlogxptprops (inconsistent redo transport properties)</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i91156">inconsistentproperties (inconsistent database properties)</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i105769">logxptstatus (redo transport status)</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i91174">lsbyfailedtxninfo (logical standby failed transaction information)</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i91186">lsbyparameters (logical standby parameters)</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i91194">lsbyskiptable (logical standby skip table)</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i91207">lsbyskiptxntable (sql apply skip transaction table)</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i95461">recvqentries (receive queue entries)</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i96589">sendqentries (send queue entries)</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#chddiidi">topwaitevents</a>
the <code>inconsistentlogxptprops</code> 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-specific properties, the inconsistency is reported on an instance-specific 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:
<code>instance_name</code>
the value identifying the sid for the instance.
<code>standby_name</code>
the database unique name (<code>db_unique_name</code>) of the standby database to which this redo transport services property pertains.
<code>property_name</code>
the name of the redo transport services property with an inconsistent value.
<code>memory_value</code>
the runtime value being used in the database.
<code>broker_value</code>
the value of the redo transport services property saved in the broker configuration file.
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:
the name of the database property with the inconsistent value.
the corresponding runtime value being used in the database.
<code>spfile_value</code>
the corresponding value saved in the server parameter file (spfile).
the value of the database property saved in the broker configuration file.
the <code>logxptstatus</code> 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:
<code>primary_instance_name</code>
the value identifying the sid for the instance on the primary database.
<code>standby_database_name</code>
the database unique name (<code>db_unique_name</code>) of the standby database.
<code>error</code>
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 <code>status</code> from <code>south_sales</code> is empty because there is no error for the<code>south_sales</code> destination. the <code>south_report</code> destination returned the <code>ora-01034</code> message.
the <code>lsbyfailedtxninfo</code> 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 <code>dba_logstdby_events</code>view:
<code>xidusn</code>: transaction id undo segment number
<code>xidslt</code>: transaction id slot number
<code>xidsqn</code>: transaction id sequence number
<code>status_code</code>: status (or oracle error code) belonging to the <code>status</code> message
<code>status</code>: 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 <code>lsbyparameters</code> monitorable database property contains a string that identifies the value of <code>max_sga</code>(maximum system global area) and <code>max_servers</code> (maximum number of parallel query servers) specifically reserved for log apply services. these values are separated by a string of number signs (###) in the<code>lsbyparameters</code> property.
the <code>lsbyskiptable</code> 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 <code>dba_logstdby_skip</code>view:
indicates if the statement should be skipped (<code>y</code>) or if errors should be returned for the statement (<code>n</code>)
<code>statement_opt</code>
indicates the type of statement that should be skipped
<code>schema</code>
the schema name for which this skip option should be used
<code>name</code>
name of the object for which this skip option should be used
<code>procedure</code>
name of the stored procedure to execute when processing the skip option
the <code>lsbyskiptxntable</code> monitorable database property lists the skip settings chosen. this property returns a table with following columns:
<code>active</code>: description of the current activity of the process or the reason why sql apply stopped
this property pertains to sql apply.
the <code>recvqentries</code> 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:
<code>status</code>
the <code>status</code> column is set to one of the following values for a log file on a logical standby database:
<code>not_applied</code>: no redo records in this log file have been applied.
<code>partially_applied</code>: some of the redo records in this log file have been applied while others have not.
<code>committed_transactions_applied</code>: 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.
<code>resetlogs_id</code>
resetlogs identifier associated with the archived redo log file
<code>thread</code>
the redo thread number
<code>log_seq</code>
the online redo log file sequence number
<code>time_generated</code>
the first time when the online redo log file was written to the primary database
<code>time_completed</code>
the next time when the log file was archived on the primary database (corresponds to the <code>next_change#</code>column)
<code>first_change#</code>
first change number in the archived redo log file
<code>next_change#</code>
first change in the next log file
<code>size (kbs)</code>
the <code>size</code> of the online redo log file in kilobytes
for example:
enterprise manager displays this information on the log file details page.
the <code>sendqentries</code> 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 value can be empty or it can contain the database unique name (<code>db_unique_name</code>) of a standby database. if empty, the <code>status</code> column will contain a value of <code>current</code> or <code>not_archived</code>.
the <code>status</code> column is set to one of the following values:
<code>current</code>: a log file to which online redo is currently being written.
<code>not_archived</code>: a completed online redo log file that has not been archived locally.
<code>archived</code>: a completed log file that has been archived locally but has not been transmitted to the standby database specified in the <code>standby_name</code> column.
the table contains exactly one row with the value of <code>status=current</code>. there can be multiple rows with the value <code>status=archived</code> or <code>status=not_archived</code>.
the redo thread number.
the log sequence number. multiple rows may have the same <code>log_seq</code> value (for different <code>standby_name</code>values).
the first time when the online redo log file was written to the primary database.
the next time when the log file was archived on the primary database (corresponds to the <code>next_change#</code>column).
first change number in the archived redo log file.
first change in the next log file.
the <code>size</code> of the online redo log file in kilobytes.
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 <code>show instance</code> command:
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.
if there is an asterisk (*) present, it indicates that the property value can be set for all instances of an oracle rac database using the <code>edit instance * on database</code> command.
configuration—the value of the property is configuration wide, not instance or database specific.
configurable property name scope pertains to
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i103200">alternatelocation</a>
instance
redo transport services
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i103210">applyinstancetimeout</a>
redo apply and sql apply
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#chedfdda">applylagthreshold</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i84996">applyparallel</a>
redo apply
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#babeeeij">archivelagtarget</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i83748">binding</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i80616">dbfilenameconvert</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i83633">delaymins</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i103260">dgconnectidentifier</a>
broker communication, redo transport services
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#babecdbc">faststartfailovertarget</a>
fast-start failover
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i88366">logarchiveformat</a>
instance *
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i80562">logarchivemaxprocesses</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i80570">logarchiveminsucceeddest</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i82637">logarchivetrace</a>
diagnosis
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i80931">logfilenameconvert</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i84507">logshipping</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i87097">logxptmode</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i86012">lsbyaskipcfgpr</a>
sql apply
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i99899">lsbyaskiperrorcfgpr</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i88222">lsbyaskiptxncfgpr</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i104631">lsbydskipcfgpr</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i99966">lsbydskiperrorcfgpr</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i88258">lsbydskiptxncfgpr</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i88374">lsbymaxeventsrecorded</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i100374">lsbymaxsga</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i88375">lsbymaxservers</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#babedgdc">lsbypreservecommitorder</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i88376">lsbyrecordappliedddl</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i96640">lsbyrecordskipddl</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i96673">lsbyrecordskiperrors</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#babgjcih">maxconnections</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i86177">maxfailure</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i101032">nettimeout</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#babdggdg">observerconnectidentifier</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i101122">preferredapplyinstance</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#babjhiae">redocompression</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i100954">reopensecs</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i103249">sidname</a>
instance identification
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i103134">standbyarchivelocation</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#i82998">standbyfilemanagement</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#cacjedba">staticconnectidentifier</a>
instance startup
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#chejhehe">transportdisconnectedthreshold</a>
<a href="http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#chehhadf">transportlagthreshold</a>
see also:
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.
directory specification on system where the standby instance is located
dynamic
physical, logical, or snapshot
on the standby instance, the <code>location</code> attribute for the <code>log_archive_dest_</code><code>n</code>initialization parameter that represents an alternate destination of the local destination that matches the configurable database property <code>standbyarchivelocation</code>
on the primary database, the <code>template</code> attribute for the <code>log_archive_dest_</code><code>n</code>initialization parameter that represents an alternate destination
<code>alternate standby location</code>
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.
on a logical standby database, oracle recommends the <code>location</code> attribute of the <code>log_archive_dest_</code><code>n</code>initialization parameter for the local destination be different from the value of <code>alternatelocation</code>configurable database property.
<code>>=0</code> (seconds)
<code>0</code> (results in immediate apply instance failover)
standby
physical or logical
the <code>applylagthreshold</code> configuration property is available only in oracle database 11g release 2 (11.2.0.4) and higher.
number
0 seconds
physical, logical
the <code>applyparallel</code> 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.
<code>auto</code>—the number of parallel processes used for redo apply is automatically determined by oracle based on the number of cpus that the system has.
<code>no</code>—no parallel apply
<code>2</code>, <code>3</code>, and so on—manually specify the number of parallel processes used for redo apply. (specifying <code>0</code> is the same as specifying <code>no</code>; specifying <code>1</code> is the same as specifying <code>auto</code>.)
<code>auto</code>
physical
<code>auto</code> corresponds to the <code>parallel</code> clause of the<code>alter database recover managed standby database</code> statement
<code>no</code> corresponds to the <code>noparallel</code> clause of the<code>alter database recover managed standby database</code> statement
<code>2</code>, <code>3</code>, and so on corresponds to the <code>parallel</code> <code>n</code> clause of the<code>alter database recover managed standby database</code> statement
seconds (either 0 seconds, or any number from 60 to 7200 seconds)
0 (disabled)
yes, from the <code>archive_lag_target</code> initialization parameter
<code>archive lag target</code>
you can specify a policy for reuse of online redo log files using the <code>mandatory</code> value. if the archiving operation of a mandatory destination fails, online redo log files cannot be overwritten.
<code>optional</code>
you can specify a policy for reuse of online redo log files using the <code>optional</code> value. if the archiving operation of an optional destination fails, the online redo log files are overwritten.
yes, from the <code>binding</code> column of the <code>v$archive_dest</code> view of the primary database
<code>mandatory</code> and <code>optional</code> attributes for the <code>log_archive_dest_</code><code>n</code> initialization parameter of the primary database
<code>binding</code> column of the <code>v$archive_dest</code> view of the primary database
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 <code>log_archive_dest_</code><code>n</code> value of the primary database.
this property is used in the following situations:
at physical standby mount time, it is used to rename primary datafile filenames to standby datafile filenames if the datafile file path on the physical 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 physical standby database if the <code>standbyfilemanagement</code> configurable database property is set to<code>'auto'</code>. oracle uses the data-file file-path mapping information from the <code>dbfilenameconvert</code> property to determine the standby file path of the new standby data file. if the <code>standbyfilemanagement</code> property is set to <code>'manual'</code>, you must add a corresponding file to the physical standby database.
when a database is added to the configuration, the broker sets the initial value of this property to the in-memory value of the <code>db_file_name_convert</code> initialization parameter. it is possible that the in-memory value and server parameter file (spfile) value of this parameter will differ. if you want to use the parameter's in-memory value, then enable the database and the broker will ensure that the spfile value of the parameter is set to the in-memory value. if you want to use the spfile value, then set the property value to be the parameter's value stored in the spfile. then enable the database.
set the value of this property to a list of string pairs:
the first string is the substring found in the datafile names on the primary database.
the second string is the substring found in the datafile names on the standby database.
for example, <code>('string1', 'string2', 'string3', 'string4',...)</code>
where:
<code>string1</code> is the substring of the primary database filename.
<code>string2</code> is the substring of the standby database filename.
<code>string3</code> is the substring of the primary database filename.
<code>string4</code> is the substring of the standby database filename.
yes, from the <code>db_file_name_convert</code> initialization parameter
static
<code>db_file_name_convert</code> initialization parameter
<code>db file name convert</code>
if the <code>delaymins</code> property is set to 0, start log apply services as follows:
start redo apply on physical standby databases using the following sql statement:
start sql apply on logical standby databases using the following sql statement:
>=0 (minutes)
<code>0</code>
yes, from the <code>delay_mins</code> column of the <code>v$archive_dest</code> view of the primary database
physical and logical
<code>delay</code> attribute for the <code>log_archive_dest_</code><code>n</code> initialization parameter of the primary database
<code>delay_mins</code> column of the <code>v$archive_dest</code> view of the primary database
options used to start redo apply and sql apply
<code>apply delay (mins)</code>
ps:this proeprty would impact on the redo applying method, when it set as zero, dg would enable real-time apply.
allow all other databases in the configuration to reach it.
allow the database to reach itself.
allow all instances of an oracle rac database to be reached.
specify a service that all instances dynamically register with the listeners so that connect-time failover on an oracle rac database is possible.
have failover attributes set to allow the primary database's redo transport services to continue shipping redo data to an oracle rac standby database, even if the receiving instance of that standby database has failed.
the value of this property is specified in the <code>service</code> attribute of the <code>log_archive_dest_</code>n parameter when the broker configures redo transport services on the primary database.
a connect identifier that can be used to connect to this database
<code>service_name</code> attribute of the <code>log_archive_dest_</code><code>n</code> initialization parameter of the primary database
prior to oracle database release 11.1, the <code>dgconnectidentifier</code> configurable database property was known as the <code>initialconnectidentifier</code> property. when upgrading a 10g configuration to this release, the<code>initialconnectidentifier</code> value will be retained as the new <code>dgconnectidentifier</code> value for that database.
if this is an oracle rac database, then before the upgrade, you must ensure that the<code>initialconnectidentifier</code> meets the criteria just listed for <code>dgconnectidentifier</code>.
<a href="http://docs.oracle.com/cd/e11882_01/network.112/e41945/toc.htm">oracle database net services administrator's guide</a>
<code>db_unique_name</code> of the database that is the target of the fast-start failover.
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<code>faststartfailovertarget</code> value explicitly, prior to enabling fast-start failover. the indicated target is verified when fast-start failover is enabled.
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.
primary or standby
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.
when a database is added to the configuration, the broker sets the initial value of this property to the in-memory value of the <code>log_archive_format</code> initialization parameter. it is possible that the in-memory value and server parameter file (spfile) value of this parameter will differ. if you want to use the parameter's in-memory value, then enable the database and the broker will ensure that the spfile value of the parameter is set to the in-memory value. if you want to use the spfile value, then set the property value to be the parameter's value stored in the spfile. then enable the database.
<code>%d_%t_%s_%r</code>
yes, from the <code>log_archive_format</code> initialization parameter on the primary database
<code>log_archive_format</code> initialization parameter
instance (on an oracle rac database, you can use the <code>edit instance * on database</code>command to have all instances use the same value for this property.)
1 to 30
<code>4</code>
yes, from the <code>log_archive_max_processes</code> initialization parameter
<code>log_archive_max_processes</code> initialization parameter
<code>archiver processes</code>
1 to 10
1
yes, from the <code>log_archive_min_succeed_dest</code> initialization parameter
<code>log_archive_min_succeed_dest</code> initialization parameter
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 <code>archivelog</code> destination activity
16: track detailed <code>archivelog</code> destination activity
32: track <code>archivelog</code> destination parameter modifications
64: track arc<code>n</code> process state activity
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)
255
yes, from the <code>log_archive_trace</code> initialization parameter
<code>log_archive_trace</code> initialization parameter
<code>log archive trace</code>
when a database is added to the configuration, the broker sets the initial value of this property to the in-memory value of the <code>log_file_name_convert</code> initialization parameter. it is possible that the in-memory value and server parameter file (spfile) value of this parameter will differ. if you want to use the parameter's in-memory value, then enable the database and the broker will ensure that the spfile value of the parameter is set to the in-memory value. if you want to use the spfile value, then set the property value to be the parameter's value stored in the spfile. then enable the database.
set the value of this property to a list of an even number of string pairs, separated by commas.
yes, from the <code>log_file_name_convert</code> initialization parameter
<code>log_file_name_convert</code> initialization parameter
<code>log file name convert</code>
<code>on</code> or <code>off</code>
<code>on</code>
<code>enable</code> and <code>defer</code> values for the <code>log_archive_dest_state_</code>n initialization parameter of the primary database
<code>log shipping</code>
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 <code>log_archive_dest_</code>n value of the primary database.
configures redo transport services for this standby database using the <code>sync</code> and <code>affirm</code> attributes of the<code>log_archive_dest_</code><code>n</code> 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 <code>async</code> and <code>noaffirm</code> attributes of the <code>log_archive_dest_</code><code>n</code> 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 <code>sync</code>.
<code>sync</code> or <code>async</code>
<code>async</code>
yes, from the <code>archiver</code>, <code>transmit_mode</code>, and <code>affirm</code> columns of <code>v$archive_dest</code> view of the primary database
<code>sync</code>, <code>async</code>, <code>affirm</code>, and <code>noaffirm</code> attributes for the <code>log_archive_dest_</code><code>n</code>initialization parameter of the primary database
<code>archiver</code>, <code>transmit_mode</code>, and <code>affirm</code> columns of <code>v$archive_dest</code> view of the primary database
<code>redo transport service</code>
the <code>lsbyaskipcfgpr</code> 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 <code>skip</code> 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.
a valid set of arguments to the <code>dbms_logstdby.skip</code> procedure
dynamic; sql apply does not require restart
logical
<code>dbms_logstdby.skip</code> procedure
<code>add skip table entries</code>
<a href="http://docs.oracle.com/cd/e11882_01/appdev.112/e40758/toc.htm">oracle database pl/sql packages and types reference</a>
the <code>lsbyaskiperrorcfgpr</code> 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.
a valid set of arguments to the <code>dbms_logstdby.skip_error</code> procedure. the string must contain comma separators between the arguments.
<code>dbms_logstdby.skip_error</code> procedure
the <code>lsbyaskiptxncfgpr</code> 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 (<code>xidsqn number</code>) 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.
a valid set of arguments to the <code>dbms_logstdby.skip_transaction</code> procedure. use comma separators between the arguments.
<code>dbms_logstdby.skip_transaction</code> procedure
<code>skip edit properties</code>
enterprise manager indirectly supports skipping a transaction using the skip edit properties page.
a valid set of arguments to the <code>dbms_logstdby.unskip</code> procedure
<code>dbms_logstdby.unskip</code> procedure
<code>remove skip table entries</code>
a valid set of arguments to the <code>dbms_logstdby.unskip_error</code> procedure. the string must contain comma separators between the arguments.
<code>dbms_logstdby.unskip_error</code> procedure
a valid set of arguments to the <code>dbms_logstdby.unskip_transaction</code>procedure
<code>dbms_logstdby.unskip_transaction</code> procedure
the <code>lsbymaxeventsrecorded</code> configurable database property specifies the number of events that will be stored in the <code>dba_logstdby_events</code> table, which stores logical standby event information.
yes, from the <code>max_events_recorded</code> row of <code>system.logstdby$parameters</code>
<code>dbms_logstdby.apply_set('max_events_recorded')</code> and the<code>dbms_logstdby.apply_unset('max_events_recorded')</code> procedures
<code>max events recorded</code>
the <code>lsbymaxsga</code> configurable instance-specific 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 <code>shared_pool_size</code> initialization parameter.
yes, from the <code>max_sga</code> row of <code>system.logstdby$parameters</code>
<code>dbms_logstdby.apply_set('max_sga')</code> and the<code>dbms_logstdby.apply_unset('max_sga')</code> procedures
<code>max sga (mb)</code>
the <code>lsbymaxservers</code> configurable instance-specific 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.
yes, from the <code>max_servers</code> row of <code>system.logstdby$parameters</code>
<code>dbms_logstdby.apply_set('max_servers')</code> and the<code>dbms_logstdby.apply_unset('max_servers')</code> procedures
<code>max servers</code>
the <code>lsbypreservecommitorder</code> 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:
<code>true</code>: transactions are applied to the logical standby database in the exact order in which they were committed on the primary database.
<code>false</code>: transactions containing non-overlapping sets of rows may be committed in a different order than they were committed on the primary database.
yes, from the <code>preserve_commit_order</code> row of <code>system.logstdby$parameters</code>
static; sql apply requires restart
<code>dbms_logstdby.apply_set('preserve_commit_order')</code> and<code>dbms_logstdby.apply_unset('preserve_commit_order')</code> procedures
<code>preserve commit order</code>
the <code>lsbyrecordappliedddl</code> configurable database property controls whether or not sql statements that were applied to the logical standby database are recorded in the <code>dba_logstdby_events</code> table. specify one of the following values:
<code>true</code>: ddl statements applied to the logical standby database are recorded in the<code>dba_logstdby_events</code> table. this is the default setting.
<code>false</code>: applied ddl statements are not recorded.
yes, from the <code>record_applied_ddl</code> row of <code>system.logstdby$parameters</code>
<code>dbms_logstdby.apply_set('record_applied_ddl')</code> and the<code>dbms_logstdby.apply_unset('record_applied_ddl')</code> procedures
<code>record applied ddl</code>
the <code>lsbyrecordskipddl</code> configurable database property controls whether or not skipped ddl statements are recorded in the <code>dba_logstdby_events</code> table. specify one of the following values:
<code>true</code>: skipped ddl statements are recorded in the <code>dba_logstdby_events</code> table. this is the default setting.
<code>false</code>: skipped ddl statements are not recorded in the <code>dba_logstdby_events</code> table.
yes, from the <code>record_skip_ddl</code> row of <code>system.logstdby$parameters</code>
<code>dbms_logstdby.apply_set('record_skip_ddl')</code> and the<code>dbms_logstdby.apply_unset('record_skip_ddl')</code> procedures
<code>record skip ddl</code>
the <code>lsbyrecordskiperrors</code> configurable database property controls whether or not skipped errors (as described by the <code>dbms_logstdby.skip_error</code> procedure) are recorded in the <code>dba_logstdby_events</code> table. specify one of the following values:
<code>true</code>: skipped errors are recorded in the <code>dba_logstdby_events</code> table.
<code>false</code>: skipped errors are not recorded in the <code>dba_logstdby_events</code> table.
yes, from the <code>record_skip_errors</code> row of <code>system.logstdby$parameters</code>
<code>dbms_logstdby.apply_set('record_skip_errors')</code> and the<code>dbms_logstdby.apply_unset('record_skip_errors')</code> procedures
<code>record skip errors</code>
the <code>maxconnections</code> 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 <code>maxconnections</code> property is set to a value greater than 1, redo transport services use multiple arcn processes to transmit redo data to archived redo log files at the remote destinations.
1 to 20
yes, from the <code>max_connections</code> column of the <code>v$archive_dest</code> view for the primary database.
<code>max_connections</code> attribute for the <code>log_archive_dest_</code><code>n</code> initialization parameter of the primary database
<code>max_connections</code> column of the <code>v$archive_dest</code> view of the primary database
footnote 1 the <code>log_archive_max_processes</code> initialization parameter affects the actual number of arcnprocesses used by an instance.
the <code>maxfailure</code> 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.
yes, from the <code>max_failure</code> column of <code>v$archive_dest</code> view of the primary database
<code>max_failure</code> attribute for the <code>log_archive_dest_</code>n initialization parameter of the primary database
<code>max_failure</code> column of the <code>v$archive_dest</code> view of the primary database
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 <code>log_archive_dest_</code>n value of the primary database.
0, 15 to 1200
30
yes, from the <code>net_timeout</code> column of <code>v$archive_dest</code> view of the primary database
<code>net_timeout</code> attribute of the <code>log_archive_dest_</code><code>n</code> initialization parameter of the primary database
<code>net_timeout</code> column of <code>v$archive_dest</code> view of the primary database
the <code>observerconnectidentifier</code> 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.
a connect identifier that observer can use to connect to this database
<code>observer connect identifier</code>
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 instance name (sid) or empty string. note that on certain platforms, sids may be case-sensitive.
<code>apply instance</code>
the <code>redocompression</code> configurable database property is used to specify whether redo data is transmitted to a standby database in compressed or uncompressed form.
redo transport compression is a feature of the oracle advanced compression option. you must purchase a license for this option before using the redo transport compression feature.
<code>disable</code> or <code>enable</code>
<code>disable</code>
yes, from the <code>compression</code> column of the <code>v$archive_dest</code> view of the primary database
<code>compression</code> attribute for the <code>log_archive_dest_</code>n initialization parameter of the primary database
<code>compression</code> column of the <code>v$archive_dest</code> view of the primary database
the <code>reopensecs</code> 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.
>=0 seconds
<code>300</code>
yes, from the <code>reopen_secs</code> column of <code>v$archive_dest</code> view of the primary database
<code>reopen</code> attribute for the <code>log_archive_dest_</code>n initialization parameter of the primary database
<code>reopen_secs</code> column of the <code>v$archive_dest</code> view of the primary database
sid of the instance. note that on certain platforms, sids may be case-sensitive.
yes
<code>instance_name</code> column of the <code>v$instance</code> view
the <code>standbyarchivelocation</code> 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.
nonempty file specification of the location of archived redo log files on the standby database. use <code>db_recovery_file_dest</code> if a database recovery area is desired.
<code>dgsby_</code>db_unique_name
yes, from the <code>destination</code> column of the <code>v$archive_dest</code> fixed view of the standby database where the destination is a local destination and where the <code>valid_for</code> attribute is compatible with the string <code>(standby_role, standby_logfile)</code>; if no such destination exists, import is from the <code>standby_archive_dest</code> initialization parameter. note that the<code>standby_archive_dest</code> parameter has been deprecated and is supported for backward compatibility only.
<code>location</code> attribute of the <code>log_archive_dest_</code>n initialization parameter of the standby database with <code>valid_for</code> compatible with <code>(standby_role, standby_logfile)</code>
<code>destination</code> column of the <code>v$archive_dest</code> view of the standby database
<code>standby archive location</code>
on a logical standby database, oracle recommends the <code>location</code> attribute of the <code>log_archive_dest_</code>ninitialization parameter for the local destination be different from the value of <code>standbyarchivelocation</code>property, unless you are using a database recovery area.
the <code>standbyfilemanagement</code> 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 <code>auto</code>, in conjunction with valid settings in the <code>dbfilenameconvert</code> 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 <code>dbfilenameconvert</code> property.
<code>auto</code> or <code>manual</code>
yes, from the <code>standby_file_management</code> initialization parameter
<code>standby_file_management</code> initialization parameter
the <code>staticconnectidentifier</code> configurable instance-specific property specifies the connection identifier that the dgmgrl client will use when starting database instances.
a connect identifier that refers to a service that is statically registered.
the <code>address</code> attribute value of the listener that is specified for the<code>local_listener</code> initialization parameter
the value for the <code>service_name</code> attribute will be set to a concatenation of<code>db_unique_name_dgmgrl.db_domain</code>
yes, from the <code>local_listener</code> and <code>db_unique_name</code> initialization parameters.
footnote 1 if the instance specified by the <code>sidname</code> property is started on a different host (read from the<code>host_name</code> column of the <code>v$instance</code> view) than the host on which it had been previously started, the broker automatically updates the default value of the <code>staticconnectidentifier</code> property to incorporate the current<code>address</code> attribute of the listener that is specified for the <code>local_listener</code> initialization parameter.
the <code>transportdisconnectedthreshold</code> configuration property is available only in oracle database 11grelease 2 (11.2.0.4) and higher.
standby database
physical, logical, or snapshot standby
the <code>transportlagthreshold</code> configuration property is available only in oracle database 11g release 2 (11.2.0.4) and higher.
參考至：http://docs.oracle.com/cd/e11882_01/server.112/e40771/dbpropref.htm#dgbkr3782
如有錯誤，歡迎指正
作者：czmmiao 文章出處：http://czmmiao.iteye.com/blog/2124975
![龍珠訓練營task04[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)