Data Guard Broker Properties
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:
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.
8.1 Configuration Properties
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:
8.1.1 BystandersFollowRoleChange
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. 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.
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 |
8.1.2 CommunicationTimeout
The CommunicationTimeout
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.
Datatype | Integer |
Valid values | >= 0 |
Broker default | 180 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 broker on all databases in the configuration. |
Enterprise manager name | Not applicable |
8.1.3 ExternalDestination1
The ExternalDestination1
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 LOG_ARCHIVE_DEST_
n
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 LOG_ARCHIVE_DEST_
n
initialization parameter on the new primary database to ship redo data to the specified destination.
Datatype | String |
Valid values | Any LOG_ARCHIVE_DEST_ n attributes, with the exception of the following:
See Oracle Data Guard Concepts and Administration for more information about the |
Broker default | Empty string |
Imported? | No |
Parameter class | Not applicable |
Role | Primary |
Standby type | Not applicable |
Corresponds to | Not applicable |
Scope | Configuration |
Enterprise Manager name | Not applicable |
8.1.4 ExternalDestination2
The ExternalDestination2
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 LOG_ARCHIVE_DEST_
n
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 LOG_ARCHIVE_DEST_
n
initialization parameter on the new primary database to ship redo data to the specified destination.
Datatype | String |
Valid values | Any LOG_ARCHIVE_DEST_ n attributes, with the exception of the following:
See Oracle Data Guard Concepts and Administration for more information about the |
Broker default | Empty string |
Imported? | No |
Parameter class | Not applicable |
Role | Primary |
Standby type | Not applicable |
Corresponds to | Not applicable |
Scope | Configuration |
Enterprise Manager name | Not applicable |
8.1.5 FastStartFailoverAutoReinstate
The FastStartFailoverAutoReinstate
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 FALSE
.
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 DBMS_DG.INITIATE_FS_FAILOVER
function.
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 |
8.1.6 FastStartFailoverLagLimit
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.
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 primary database after fast-start failover has been enabled. |
Enterprise Manager name | Lag Limit |
8.1.7 FastStartFailoverPmyShutdown
The FastStartFailoverPmyShutdown
configuration property causes the primary database to shut down if fast-start failover is enabled and V$DATABASE.FS_FAILOVER_STATUS
indicates the primary has been STALLED
for longer than FastStartFailoverThreshold
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 TRUE
helps to ensure that an isolated primary database cannot satisfy user queries.
Setting this property to FALSE
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 DBMS_DG.INITIATE_FS_FAILOVER
function.
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 primary database after fast-start failover has been enabled. |
Enterprise Manager name | Automatically Shutdown Primary |
8.1.8 FastStartFailoverThreshold
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 failover condition is detected or an application has requested that fast-start failover be initiated.
For help in determining an appropriate value for this property, you can use the information provided in the V$FS_OBSERVER_HISTOGRAM
view. This view displays statistics that are based on the frequency of successful pings between the observer and primary database for different time intervals. (See Oracle Database Reference for a description of the V$FS_OBSERVER_HISTOGRAM
view.)
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. |
8.1.9 ObserverOverride
The ObserverOverride
configuration property, when set to TRUE
, allows an automatic failover to occur when the observer has lost connectivity to the primary, even if the standby has a healthy connection to the primary.
The ObserverOverride
configuration property is available only in Oracle Database 11g Release 2 (11.2.0.4) and higher.
Datatype | Boolean |
Valid values |
TRUE or FALSE
|
Broker default | FALSE |
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 | Not applicable |
8.1.10 ObserverReconnect
The ObserverReconnect
configuration property specifies how often the observer establishes a new connection to the primary database. When this property is set to the default value of 0, the observer creates and maintains a connection to the primary database, but it does not periodically create a new connection to the primary database. While this eliminates the processing overhead associated with periodically establishing a new observer connection to the primary database, it also prevents the observer from detecting that it is not possible to create new connections to the primary database. Oracle recommends that this property be set to a value that is small enough to allow timely detection of faults at the primary database, but large enough to limit the overhead associated with periodic observer connections to an acceptable level.
The ObserverReconnect
configuration property is available only in Oracle Database 11g Release 2 (11.2.0.4) and higher.
Datatype | Integer |
Valid values | >=0 |
Broker default | 0 |
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 | Not applicable |
8.1.11 OperationTimeout
The OperationTimeout
configuration property specifies the maximum amount of time the broker should wait for health check, get monitorable property, and set property operations to complete.
Datatype | Integer |
Valid values | >= 30 and <= 600 |
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 broker on all databases in the configuration. |
Enterprise Manager name | Not applicable |
8.1.12 PrimaryLostWriteAction
The PrimaryLostWriteAction
configuration property determines what action is taken if a standby database detects that a lost write has occurred at the primary database:
-
CONTINUE
- 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. -
SHUTDOWN
- 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 PrimaryLostWriteAction
is set to SHUTDOWN
.
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.
If a lost write occurs at the primary database, then follow the guidelines in "Resolving ORA-752 or ORA-600 [3020] During Standby Recovery" in My Oracle Support Note 1265884.1 located at http://support.oracle.com
.
The PrimaryLostWriteAction
configuration property is available only in Oracle Database 11g Release 2 (11.2.0.4).
Note:
TheDB_LOST_WRITE_PROTECT
database initialization parameter must be set to TYPICAL
or FULL
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.Datatype | String |
Valid values |
CONTINUE or SHUTDOWN
|
Broker default | CONTINUE |
Imported? | No |
Parameter class | Not applicable |
Role | Primary and standby |
Standby type | Not applicable |
Corresponds to | Not applicable |
Scope | Broker configuration |
Enterprise Manager name | Not applicable |
8.1.13 TraceLevel
The TraceLevel
configuration property is used to control the amount of tracing performed by the broker for every member in the configuration. Setting the property to USER
limits the tracing to completed operations and to any warning or error messages resulting from an operation or health check. Setting the property to SUPPORT
increases the amount of tracing to include lower-level information needed by Oracle Support Services.
The TraceLevel
configuration property is available only in Oracle Database 11g Release 2 (11.2.0.3) and higher.
Datatype | String |
Valid values |
USER , SUPPORT
|
Broker default | USER |
Imported? | No |
Parameter class | Not applicable |
Role | Primary and standby |
Standby type | Not applicable |
Corresponds to | Not applicable |
Scope | Database |
Enterprise Manager name | Not applicable |
8.2 Monitorable (Read-Only) Database Properties
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)
8.2.1 InconsistentLogXptProps (Inconsistent Redo Transport Properties)
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-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:
-
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.
8.2.2 InconsistentProperties (Inconsistent Database Properties)
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.
8.2.3 LogXptStatus (Redo Transport Status)
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 South_Sales
is empty because there is no error for the South_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 north_sales1 South_Sales north_sales1 South_Report ORA-01034: ORACLE not available
8.2.4 LsbyFailedTxnInfo (Logical Standby Failed Transaction Information)
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 theSTATUS
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.
8.2.5 LsbyParameters (Logical Standby Parameters)
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.
8.2.6 LsbySkipTable (Logical Standby Skip Table)
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.
8.2.7 LsbySkipTxnTable (SQL Apply Skip Transaction Table)
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.
8.2.8 RecvQEntries (Receive Queue Entries)
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 'South_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.8.2.9 SendQEntries (Send Queue Entries)
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, theSTATUS
column will contain a value ofCURRENT
orNOT_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 theSTANDBY_NAME
column.
The table contains exactly one row with the value of
STATUS=CURRENT
. There can be multiple rows with the valueSTATUS=ARCHIVED
orSTATUS=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 differentSTANDBY_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) South_Sales ARCHIVED 497198843 1 9 06/20/2003 16:31:59 06/20/2003 16:39:57 210789 211411 186 South_Sales ARCHIVED 497198843 1 10 06/20/2003 16:39:57 06/20/2003 16:40:01 211411 211415 1 South_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.8.2.10 TopWaitEvents
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-specific 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 north_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
8.3 Configurable Database Properties
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-wide 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-specific 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 8-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.
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
EDIT INSTANCE * ON DATABASE
command. -
Configuration—The value of the property is configuration wide, not instance or database specific.
Table 8-1 Configurable Properties
Instance |
Redo transport services |
|
Database |
Redo Apply and SQL Apply |
|
Database |
Redo transport services |
|
Database |
Redo Apply |
|
Database |
Redo transport services |
|
Database |
Redo transport services |
|
Database |
Redo Apply |
|
Database |
Redo Apply and SQL Apply |
|
Database |
Broker communication, Redo transport services |
|
Database |
Fast-start failover |
|
Instance * |
Redo transport services |
|
Database |
Redo transport services |
|
Database |
Redo transport services |
|
Instance * |
Diagnosis |
|
Database |
Redo Apply |
|
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 |
|
Instance |
Instance Startup |
|
Database |
Redo transport services |
|
Database |
Redo transport services |
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.8.3.1 AlternateLocation
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 instance-specific scope, and the location it specifies has to be accessible by the instance.
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.8.3.2 ApplyInstanceTimeout
The ApplyInstanceTimeout
configurable database property specifies the number of seconds the broker waits after detecting the current apply instance failed before initiating the apply instance failover.
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 |
8.3.3 ApplyLagThreshold
The ApplyLagThreshold
configurable database property generates a warning status for a logical or physical standby when the database's apply lag exceeds the value specified by the property. The property value is expressed in seconds. A value of 0 seconds results in no warnings being generated when an apply lag exists.
The ApplyLagThreshold
configuration property is available only in Oracle Database 11g Release 2 (11.2.0.4) and higher.
Datatype | Number |
Valid values | >=0 |
Broker default | 0 seconds |
Imported? | No |
Parameter class | Not applicable |
Role | Standby |
Standby type | Physical, logical |
Corresponds to | Not applicable |
Scope | Database |
Enterprise Manager name | Not applicable |
8.3.4 ApplyParallel
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.
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 |
8.3.5 ArchiveLagTarget
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.
8.3.6 Binding
The
Binding
configurable database property specifies whether the standby destination is MANDATORY
or OPTIONAL
.
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.
8.3.7 DbFileNameConvert
The DbFileNameConvert
configurable database property distinguishes physical standby datafile filenames from primary datafile filenames. If you add a datafile to the primary database, this property converts the datafile name on the primary database to the datafile on the physical standby 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
StandbyFileManagement
configurable database property is set to'AUTO'
. Oracle uses the data-file file-path mapping information from theDbFileNameConvert
property to determine the standby file path of the new standby data file. If theStandbyFileManagement
property is set to'MANUAL'
, you must add a corresponding file to the physical standby database.
Note:
When a database is added to the configuration, the broker sets the initial value of this property to the in-memory value of theDB_FILE_NAME_CONVERT
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.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 |
8.3.8 DelayMins
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;
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) |
PS:this proeprty would impact on the redo applying method, when it set as zero, DG would enable real-time apply.
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.
8.3.9 DGConnectIdentifier
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 you are using Enterprise Manager, the value is supplied automatically. The connect identifier for a database must:
-
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 SERVICE
attribute of the LOG_ARCHIVE_DEST_
n parameter when the broker configures redo transport services on the primary database.
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 this release, the InitialConnectIdentifier
value will be retained as the new DGConnectIdentifier
value for that database.
If this is an Oracle RAC database, then before the upgrade, you must ensure that the InitialConnectIdentifier
meets the criteria just listed for DGConnectIdentifier
.
8.3.10 FastStartFailoverTarget
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.
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 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. |
8.3.11 LogArchiveFormat
The LogArchiveFormat
configurable instance-specific 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
).
Note:
When a database is added to the configuration, the broker sets the initial value of this property to the in-memory value of theLOG_ARCHIVE_FORMAT
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.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 (On an Oracle RAC database, you can use the EDIT INSTANCE * ON DATABASE command to have all instances use the same value for this property.) |
Enterprise Manager name | Not applicable |
8.3.12 LogArchiveMaxProcesses
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.
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 |
8.3.13 LogArchiveMinSucceedDest
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.
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 |
8.3.14 LogArchiveTrace
Set the
LogArchiveTrace
configurable instance-specific 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.
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 (On an Oracle RAC database, you can use the EDIT INSTANCE * ON DATABASE command to have all instances use the same value for this property.) |
Enterprise Manager name | Log Archive Trace |
8.3.15 LogFileNameConvert
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 physical standby database.
Note:
When a database is added to the configuration, the broker sets the initial value of this property to the in-memory value of theLOG_FILE_NAME_CONVERT
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.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 |
8.3.16 LogShipping
The
LogShipping
configurable database property specifies whether or not redo transport services can send redo data 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 theLogShipping
property is set toON
orOFF
. -
If the primary database is in the
TRANSPORT-ON
state and the value of theLogShipping
property isON
, then redo transport services are enabled to send redo data to the particular standby database. If theLogShipping
property isOFF
, then redo transport services are disabled to send redo data to the particular standby database.
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.
8.3.17 LogXptMode
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
andAFFIRM
attributes of theLOG_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
andNOAFFIRM
attributes of theLOG_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 thanSYNC
.
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 services8.3.18 LsbyASkipCfgPr
The 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.
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 |
8.3.19 LsbyASkipErrorCfgPr
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.
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 |
8.3.20 LsbyASkipTxnCfgPr
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.
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.8.3.21 LsbyDSkipCfgPr
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.
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 |
8.3.22 LsbyDSkipErrorCfgPr
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.
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 |
8.3.23 LsbyDSkipTxnCfgPr
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.
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 |
8.3.24 LsbyMaxEventsRecorded
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.
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 |
8.3.25 LsbyMaxSga
The LsbyMaxSga
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 SHARED_POOL_SIZE
initialization parameter.
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 (On an Oracle RAC database, you can use the EDIT INSTANCE * ON DATABASE command to have all instances use the same value for this property.) |
Enterprise Manager name | Max SGA (MB) |
8.3.26 LsbyMaxServers
The LsbyMaxServers
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.
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 (On an Oracle RAC database, you can use the EDIT INSTANCE * ON DATABASE command to have all instances use the same value for this property.) |
Enterprise Manager name | Max Servers |
8.3.27 LsbyPreserveCommitOrder
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. -
FALSE
: Transactions containing non-overlapping sets of rows may be committed in a different order than they were committed on the primary database.
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 |
8.3.28 LsbyRecordAppliedDdl
The LsbyRecordAppliedDdl
configurable database property controls whether or not SQL 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 theDBA_LOGSTDBY_EVENTS
table. This is the default setting. -
FALSE
: Applied DDL statements are not recorded.
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 |
8.3.29 LsbyRecordSkipDdl
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 theDBA_LOGSTDBY_EVENTS
table. This is the default setting. -
FALSE
: Skipped DDL statements are not recorded in theDBA_LOGSTDBY_EVENTS
table.
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 |
8.3.30 LsbyRecordSkipErrors
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 theDBA_LOGSTDBY_EVENTS
table. -
FALSE
: Skipped errors are not recorded in theDBA_LOGSTDBY_EVENTS
table.
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 |
8.3.31 MaxConnections
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 value greater than 1, redo transport services use multiple ARCn processes to transmit redo data to archived redo log files at the remote destinations.
Datatype | Integer |
Valid values | 1 to 20 |
Broker default | 1 |
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 |
|
Scope | Database |
Enterprise Manager name | Not applicable |
Footnote 1 The LOG_ARCHIVE_MAX_PROCESSES
initialization parameter affects the actual number of ARCn processes used by an instance.
8.3.32 MaxFailure
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.
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.
8.3.33 NetTimeout
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.
Datatype | Integer |
Valid values | 0, 15 to 1200 |
Broker default | 30 |
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 |
8.3.34 ObserverConnectIdentifier
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.
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.
8.3.35 PreferredApplyInstance
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 Oracle RAC database. The value could be an empty string (default) which means the broker chooses the apply instance.
Datatype | String |
Valid Values | The instance name (SID) or empty string. Note that on certain platforms, SIDs may be case-sensitive. |
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:
-
Oracle Database Administrator's Guide for more information about SIDs
-
Section 4.5.7 for information about apply services in an Oracle RAD environment
8.3.36 RedoCompression
The RedoCompression
configurable database property is used to specify whether redo data is transmitted to a standby database in compressed or uncompressed form.
Note:
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.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.
8.3.37 ReopenSecs
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.
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.
8.3.38 SidName
The SidName
configurable database property specifies the Oracle System Identifier (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.Datatype | String |
Valid values | SID of the instance. Note that on certain platforms, SIDs may be case-sensitive. |
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 |
See Also:
Oracle Database Administrator's Guide for more information about SIDs8.3.39 StandbyArchiveLocation
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.
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 a 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. Note that the STANDBY_ARCHIVE_DEST parameter has been deprecated and is supported for backward compatibility only. |
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 a database recovery area.8.3.40 StandbyFileManagement
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.
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 |
8.3.41 StaticConnectIdentifier
The StaticConnectIdentifier
configurable instance-specific property specifies the connection identifier that the DGMGRL client will use when starting database instances.
Datatype | String |
Valid values | A connect identifier that refers to a service that is statically registered. |
Broker default | Connect descriptor that is the concatenation of:Foot 1
|
Imported? | Yes, from the LOCAL_LISTENER and DB_UNIQUE_NAME initialization parameters. |
Parameter class | Not applicable |
Role | Primary and standby |
Standby type | Physical, logical, or snapshot |
Corresponds to | Not applicable |
Scope | Instance |
Enterprise Manager name | Not applicable |
Footnote 1 If the instance specified by the SidName
property is started on a different host (read from the HOST_NAME
column of the V$INSTANCE
view) than the host on which it had been previously started, the broker automatically updates the default value of the StaticConnectIdentifier
property to incorporate the current ADDRESS
attribute of the listener that is specified for the LOCAL_LISTENER
initialization parameter.
See Also:
Oracle Database Net Services Administrator's Guide for more information about statically registered services8.3.42 TransportDisconnectedThreshold
The TransportDisconnectedThreshold
configurable database property can be used to generate a warning status for a logical, physical, or snapshot standby when the last communication from the primary database exceeds the value specified by the property. The property value is expressed in seconds. A value of 0 seconds results in no warnings being generated.
The TransportDisconnectedThreshold
configuration property is available only in Oracle Database 11g Release 2 (11.2.0.4) and higher.
Datatype | Number |
Valid values | >=0 |
Broker default | 30 seconds |
Imported? | No |
Parameter class | Not applicable |
Role | Standby database |
Standby type | Physical, logical, or snapshot standby |
Corresponds to | Not applicable |
Scope | Database |
Enterprise Manager name | Not applicable |
8.3.43 TransportLagThreshold
The TransportLagThreshold
configurable database property can be used to generate a warning status for a logical, physical, or snapshot standby when the database's transport lag exceeds the value specified by the property. The property value is expressed in seconds. A value of 0 seconds results in no warnings being generated when a transport lag exists.
The TransportLagThreshold
configuration property is available only in Oracle Database 11g Release 2 (11.2.0.4) and higher.
Datatype | Number |
Valid values | >=0 |
Broker default | 0 seconds |
Imported? | No |
Parameter class | Not applicable |
Role | Standby database |
Standby type | Physical, logical, or snapshot standby |
Corresponds to | Not applicable |
Scope | Database |
Enterprise Manager name | Not applicable |
参考至:http://docs.oracle.com/cd/E11882_01/server.112/e40771/dbpropref.htm#DGBKR3782
如有错误,欢迎指正
邮箱:czmcj@163.com
相关推荐
- 使用Data Guard Broker或其他工具进行主备数据库间的同步操作。 #### 四、注意事项 - 确保所有文件路径正确无误。 - 在修改任何初始化参数文件之前,请先备份原文件。 - 检查网络连接,确保主备数据库之间的...
内容概要:本文探讨了模糊故障树(FFTA)在工业控制系统可靠性分析中的应用,解决了传统故障树方法无法处理不确定数据的问题。文中介绍了模糊数的基本概念和实现方式,如三角模糊数和梯形模糊数,并展示了如何用Python实现模糊与门、或门运算以及系统故障率的计算。此外,还详细讲解了最小割集的查找方法、单元重要度的计算,并通过实例说明了这些方法的实际应用场景。最后,讨论了模糊运算在处理语言变量方面的优势,强调了在可靠性分析中处理模糊性和优化计算效率的重要性。 适合人群:从事工业控制系统设计、维护的技术人员,以及对模糊数学和可靠性分析感兴趣的科研人员。 使用场景及目标:适用于需要评估复杂系统可靠性的场合,特别是在面对不确定数据时,能够提供更准确的风险评估。目标是帮助工程师更好地理解和预测系统故障,从而制定有效的预防措施。 其他说明:文中提供的代码片段和方法可用于初步方案验证和技术探索,但在实际工程项目中还需进一步优化和完善。
内容概要:本文详细探讨了双馈风力发电机(DFIG)在Simulink环境下的建模方法及其在不同风速条件下的电流与电压波形特征。首先介绍了DFIG的基本原理,即定子直接接入电网,转子通过双向变流器连接电网的特点。接着阐述了Simulink模型的具体搭建步骤,包括风力机模型、传动系统模型、DFIG本体模型和变流器模型的建立。文中强调了变流器控制算法的重要性,特别是在应对风速变化时,通过实时调整转子侧的电压和电流,确保电流和电压波形的良好特性。此外,文章还讨论了模型中的关键技术和挑战,如转子电流环控制策略、低电压穿越性能、直流母线电压脉动等问题,并提供了具体的解决方案和技术细节。最终,通过对故障工况的仿真测试,验证了所建模型的有效性和优越性。 适用人群:从事风力发电研究的技术人员、高校相关专业师生、对电力电子控制系统感兴趣的工程技术人员。 使用场景及目标:适用于希望深入了解DFIG工作原理、掌握Simulink建模技能的研究人员;旨在帮助读者理解DFIG在不同风速条件下的动态响应机制,为优化风力发电系统的控制策略提供理论依据和技术支持。 其他说明:文章不仅提供了详细的理论解释,还附有大量Matlab/Simulink代码片段,便于读者进行实践操作。同时,针对一些常见问题给出了实用的调试技巧,有助于提高仿真的准确性和可靠性。
内容概要:本文详细介绍了基于西门子S7-200 PLC和组态王软件构建的八层电梯控制系统。首先阐述了系统的硬件配置,包括PLC的IO分配策略,如输入输出信号的具体分配及其重要性。接着深入探讨了梯形图编程逻辑,涵盖外呼信号处理、轿厢运动控制以及楼层判断等关键环节。随后讲解了组态王的画面设计,包括动画效果的实现方法,如楼层按钮绑定、轿厢移动动画和门开合效果等。最后分享了一些调试经验和注意事项,如模拟困人场景、防抖逻辑、接线艺术等。 适合人群:从事自动化控制领域的工程师和技术人员,尤其是对PLC编程和组态软件有一定基础的人群。 使用场景及目标:适用于需要设计和实施小型电梯控制系统的工程项目。主要目标是帮助读者掌握PLC编程技巧、组态画面设计方法以及系统联调经验,从而提高项目的成功率。 其他说明:文中提供了详细的代码片段和调试技巧,有助于读者更好地理解和应用相关知识点。此外,还强调了安全性和可靠性方面的考量,如急停按钮的正确接入和硬件互锁设计等。
内容概要:本文介绍了如何将CarSim的动力学模型与Simulink的智能算法相结合,利用模型预测控制(MPC)实现车辆的智能超车换道。主要内容包括MPC控制器的设计、路径规划算法、联合仿真的配置要点以及实际应用效果。文中提供了详细的代码片段和技术细节,如权重矩阵设置、路径跟踪目标函数、安全超车条件判断等。此外,还强调了仿真过程中需要注意的关键参数配置,如仿真步长、插值设置等,以确保系统的稳定性和准确性。 适合人群:从事自动驾驶研究的技术人员、汽车工程领域的研究人员、对联合仿真感兴趣的开发者。 使用场景及目标:适用于需要进行自动驾驶车辆行为模拟的研究机构和企业,旨在提高超车换道的安全性和效率,为自动驾驶技术研发提供理论支持和技术验证。 其他说明:随包提供的案例文件已调好所有参数,可以直接导入并运行,帮助用户快速上手。文中提到的具体参数和配置方法对于初学者非常友好,能够显著降低入门门槛。
包括:源程序工程文件、Proteus仿真工程文件、论文材料、配套技术手册等 1、采用51单片机作为主控; 2、采用AD0809(仿真0808)检测"PH、氨、亚硝酸盐、硝酸盐"模拟传感; 3、采用DS18B20检测温度; 4、采用1602液晶显示检测值; 5、检测值同时串口上传,调试助手监看; 6、亦可通过串口指令对加热器、制氧机进行控制;
内容概要:本文详细介绍了双馈永磁风电机组并网仿真模型及其短路故障分析方法。首先构建了一个9MW风电场模型,由6台1.5MW双馈风机构成,通过升压变压器连接到120kV电网。文中探讨了风速模块的设计,包括渐变风、阵风和随疾风的组合形式,并提供了相应的Python和MATLAB代码示例。接着讨论了双闭环控制策略,即功率外环和电流内环的具体实现细节,以及MPPT控制用于最大化风能捕获的方法。此外,还涉及了短路故障模块的建模,包括三相电压电流特性和离散模型与phasor模型的应用。最后,强调了永磁同步机并网模型的特点和注意事项。 适合人群:从事风电领域研究的技术人员、高校相关专业师生、对风电并网仿真感兴趣的工程技术人员。 使用场景及目标:适用于风电场并网仿真研究,帮助研究人员理解和优化风电机组在不同风速条件下的性能表现,特别是在短路故障情况下的应对措施。目标是提高风电系统的稳定性和可靠性。 其他说明:文中提供的代码片段和具体参数设置有助于读者快速上手并进行实验验证。同时提醒了一些常见的错误和需要注意的地方,如离散化步长的选择、初始位置对齐等。
适用于空手道训练和测试场景
内容概要:本文介绍了金牌音乐作词大师的角色设定、背景经历、偏好特点、创作目标、技能优势以及工作流程。金牌音乐作词大师凭借深厚的音乐文化底蕴和丰富的创作经验,能够为不同风格的音乐创作歌词,擅长将传统文化元素与现代流行文化相结合,创作出既富有情感又触动人心的歌词。在创作过程中,会严格遵守社会主义核心价值观,尊重用户需求,提供专业修改建议,确保歌词内容健康向上。; 适合人群:有歌词创作需求的音乐爱好者、歌手或音乐制作人。; 使用场景及目标:①为特定主题或情感创作歌词,如爱情、励志等;②融合传统与现代文化元素创作独特风格的歌词;③对已有歌词进行润色和优化。; 阅读建议:阅读时可以重点关注作词大师的创作偏好、技能优势以及工作流程,有助于更好地理解如何创作出高质量的歌词。同时,在提出创作需求时,尽量详细描述自己的情感背景和期望,以便获得更贴合心意的作品。
linux之用户管理教程.md
包括:源程序工程文件、Proteus仿真工程文件、配套技术手册等 1、采用51/52单片机作为主控芯片; 2、采用1602液晶显示设置及状态; 3、采用L298驱动两个电机,模拟机械臂动力、移动底盘动力; 3、首先按键配置-待搬运物块的高度和宽度(为0不能开始搬运); 4、按下启动键开始搬运,搬运流程如下: 机械臂先把物块抓取到机器车上, 机械臂减速 机器车带着物块前往目的地 机器车减速 机械臂把物块放下来 机械臂减速 机器车回到物块堆积处(此时机器车是空车) 机器车减速 蜂鸣器提醒 按下复位键,结束本次搬运
内容概要:本文详细介绍了基于下垂控制的三相逆变器电压电流双闭环控制的仿真方法及其在MATLAB/Simulink和PLECS中的具体实现。首先解释了下垂控制的基本原理,即有功调频和无功调压,并给出了相应的数学表达式。随后讨论了电压环和电流环的设计与参数整定,强调了两者带宽的差异以及PI控制器的参数选择。文中还提到了一些常见的调试技巧,如锁相环的响应速度、LC滤波器的谐振点处理、死区时间设置等。此外,作者分享了一些实用的经验,如避免过度滤波、合理设置采样周期和下垂系数等。最后,通过突加负载测试展示了系统的动态响应性能。 适合人群:从事电力电子、微电网研究的技术人员,尤其是有一定MATLAB/Simulink和PLECS使用经验的研发人员。 使用场景及目标:适用于希望深入了解三相逆变器下垂控制机制的研究人员和技术人员,旨在帮助他们掌握电压电流双闭环控制的具体实现方法,提高仿真的准确性和效率。 其他说明:本文不仅提供了详细的理论讲解,还结合了大量的实战经验和调试技巧,有助于读者更好地理解和应用相关技术。
内容概要:本文详细介绍了光伏并网逆变器的全栈开发资料,涵盖了从硬件设计到控制算法的各个方面。首先,文章深入探讨了功率接口板的设计,包括IGBT缓冲电路、PCB布局以及EMI滤波器的具体参数和设计思路。接着,重点讲解了主控DSP板的核心控制算法,如MPPT算法的实现及其注意事项。此外,还详细描述了驱动扩展板的门极驱动电路设计,特别是光耦隔离和驱动电阻的选择。同时,文章提供了并联仿真的具体实现方法,展示了环流抑制策略的效果。最后,分享了许多宝贵的实战经验和调试技巧,如主变压器绕制、PWM输出滤波、电流探头使用等。 适合人群:从事电力电子、光伏系统设计的研发工程师和技术爱好者。 使用场景及目标:①帮助工程师理解和掌握光伏并网逆变器的硬件设计和控制算法;②提供详细的实战经验和调试技巧,提升产品的可靠性和性能;③适用于希望深入了解光伏并网逆变器全栈开发的技术人员。 其他说明:文中不仅提供了具体的电路设计和代码实现,还分享了许多宝贵的实际操作经验和常见问题的解决方案,有助于提高开发效率和产品质量。
内容概要:本文详细介绍了粒子群优化(PSO)算法与3-5-3多项式相结合的方法,在机器人轨迹规划中的应用。首先解释了粒子群算法的基本原理及其在优化轨迹参数方面的作用,随后阐述了3-5-3多项式的数学模型,特别是如何利用不同阶次的多项式确保轨迹的平滑过渡并满足边界条件。文中还提供了具体的Python代码实现,展示了如何通过粒子群算法优化时间分配,使3-5-3多项式生成的轨迹达到时间最优。此外,作者分享了一些实践经验,如加入惩罚项以避免超速,以及使用随机扰动帮助粒子跳出局部最优。 适合人群:对机器人运动规划感兴趣的科研人员、工程师和技术爱好者,尤其是有一定编程基础并对优化算法有初步了解的人士。 使用场景及目标:适用于需要精确控制机器人运动的应用场合,如工业自动化生产线、无人机导航等。主要目标是在保证轨迹平滑的前提下,尽可能缩短运动时间,提高工作效率。 其他说明:文中不仅给出了理论讲解,还有详细的代码示例和调试技巧,便于读者理解和实践。同时强调了实际应用中需要注意的问题,如系统的建模精度和安全性考量。
KUKA机器人相关资料
内容概要:本文详细探讨了光子晶体中的束缚态在连续谱中(BIC)及其与轨道角动量(OAM)激发的关系。首先介绍了光子晶体的基本概念和BIC的独特性质,随后展示了如何通过Python代码模拟二维光子晶体中的BIC,并解释了BIC在光学器件中的潜在应用。接着讨论了OAM激发与BIC之间的联系,特别是BIC如何增强OAM激发效率。文中还提供了使用有限差分时域(FDTD)方法计算OAM的具体步骤,并介绍了计算本征态和三维Q值的方法。此外,作者分享了一些实验中的有趣发现,如特定条件下BIC表现出OAM特征,以及不同参数设置对Q值的影响。 适合人群:对光子晶体、BIC和OAM感兴趣的科研人员和技术爱好者,尤其是从事微纳光子学研究的专业人士。 使用场景及目标:适用于希望通过代码模拟深入了解光子晶体中BIC和OAM激发机制的研究人员。目标是掌握BIC和OAM的基础理论,学会使用Python和其他工具进行模拟,并理解这些现象在实际应用中的潜力。 其他说明:文章不仅提供了详细的代码示例,还分享了许多实验心得和技巧,帮助读者避免常见错误,提高模拟精度。同时,强调了物理离散化方式对数值计算结果的重要影响。
内容概要:本文详细介绍了如何使用C#和Halcon 17.12构建一个功能全面的工业视觉项目。主要内容涵盖项目配置、Halcon脚本的选择与修改、相机调试、模板匹配、生产履历管理、历史图像保存以及与三菱FX5U PLC的以太网通讯。文中不仅提供了具体的代码示例,还讨论了实际项目中常见的挑战及其解决方案,如环境配置、相机控制、模板匹配参数调整、PLC通讯细节、生产数据管理和图像存储策略等。 适合人群:从事工业视觉领域的开发者和技术人员,尤其是那些希望深入了解C#与Halcon结合使用的专业人士。 使用场景及目标:适用于需要开发复杂视觉检测系统的工业应用场景,旨在提高检测精度、自动化程度和数据管理效率。具体目标包括但不限于:实现高效的视觉处理流程、确保相机与PLC的无缝协作、优化模板匹配算法、有效管理生产和检测数据。 其他说明:文中强调了框架整合的重要性,并提供了一些实用的技术提示,如避免不同版本之间的兼容性问题、处理实时图像流的最佳实践、确保线程安全的操作等。此外,还提到了一些常见错误及其规避方法,帮助开发者少走弯路。
内容概要:本文探讨了分布式电源(DG)接入对9节点配电网节点电压的影响。首先介绍了9节点配电网模型的搭建方法,包括定义节点和线路参数。然后,通过在特定节点接入分布式电源,利用Matlab进行潮流计算,模拟DG对接入点及其周围节点电压的影响。最后,通过绘制电压波形图,直观展示了不同DG容量和接入位置对配电网电压分布的具体影响。此外,还讨论了电压越限问题以及不同线路参数对电压波动的影响。 适合人群:电力系统研究人员、电气工程学生、从事智能电网和分布式能源研究的专业人士。 使用场景及目标:适用于研究分布式电源接入对配电网电压稳定性的影响,帮助优化分布式电源的规划和配置,确保电网安全稳定运行。 其他说明:文中提供的Matlab代码和图表有助于理解和验证理论分析,同时也为后续深入研究提供了有价值的参考资料。
内容概要:本文探讨了在两级电力市场环境中,针对省间交易商的最优购电模型的研究。文中提出了一个双层非线性优化模型,用于处理省内电力市场和省间电力交易的出清问题。该模型采用CVaR(条件风险价值)方法来评估和管理由新能源和负荷不确定性带来的风险。通过KKT条件和对偶理论,将复杂的双层非线性问题转化为更易求解的线性单层问题。此外,还通过实际案例验证了模型的有效性,展示了不同风险偏好设置对购电策略的影响。 适合人群:从事电力系统规划、运营以及风险管理的专业人士,尤其是对电力市场机制感兴趣的学者和技术专家。 使用场景及目标:适用于希望深入了解电力市场运作机制及其风险控制手段的研究人员和技术开发者。主要目标是为省间交易商提供一种科学有效的购电策略,以降低风险并提高经济效益。 其他说明:文章不仅介绍了理论模型的构建过程,还包括具体的数学公式推导和Python代码示例,便于读者理解和实践。同时强调了模型在实际应用中存在的挑战,如数据精度等问题,并指出了未来改进的方向。
内容概要:本文详细介绍了一套成熟的西门子1200 PLC轴运动控制程序模板,涵盖多轴伺服控制、电缸控制、PLC通讯、气缸报警块、完整电路图、威纶通触摸屏程序和IO表等方面的内容。该模板已在多个项目中成功应用,如海康威视的路由器外壳装配机,确保了系统的稳定性和可靠性。文中不仅提供了具体的代码示例,还分享了许多实战经验和技巧,如参数设置、异常处理机制、通讯优化等。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是那些需要进行PLC编程和轴运动控制的从业者。 使用场景及目标:适用于需要快速搭建稳定可靠的PLC控制系统的企业和个人开发者。通过学习和应用该模板,可以提高开发效率,减少调试时间和错误发生率,从而更好地满足项目需求。 其他说明:文章强调了程序模板的实用性,特别是在异常处理和参数配置方面的独特设计,能够有效应对复杂的工业环境挑战。此外,还提到了一些常见的陷阱和解决方案,帮助读者避开常见错误,顺利实施项目。