Oracle® Data Guard Broker 10g Release 2 (10.2) Part Number B14230-02 |
|
|
View PDF |
The Data Guard command-line interface (DGMGRL) enables you to manage a Data Guard broker configuration and its databases directly from the command line, or from batch programs or scripts. You can use the Data Guard command-line interface as an alternative to Oracle Enterprise Manager for managing a Data Guard configuration.
This chapter provides reference information for the Data Guard command-line interface.
To run DGMGRL, you must have SYSDBA
privileges.
Start the command-line interface by entering DGMGRL
at the command-line prompt on a system where Oracle is installed:
% dgmgrl DGMGRL for Linux: Version 10.2.0.1.0 - ProductionCopyright (c) 2000, 2005, Oracle. All rights reserved.Welcome to DGMGRL, type "help" for information. DGMGRL>
You can supply optional parameters on the command line to indicate how you want the Data Guard command-line interface to display output such as command prompts, banners, and messages.
Additionally, a single command mode is available. In this mode, DGMGRL executes one command and exits upon the completion of the command. The exit code is the result of the command. If the exit code is 0, the command completed successfully. Otherwise, there was an error.
The command line of DGMGRL appears as follows:
% DGMGRL [<options>] [<logon> [<command>] ]
Specify any of the following keywords when you invoke the DGMGRL command-line interface:
<options>
can be one of the following choices:
-echo
Displays command input and output to the default display device. If you do not use this parameter, only the output from the command is displayed.
-logfile
<file-spec> "<dgmgrl-command>"
Specifies a file into which you can capture the actions of the DGMGRL command-line interface. This is particularly useful when DGMGRL is being invoked to serve as the fast-start failover observer. See the "START OBSERVER" command for more information.
-silent
Suppresses the display of the DGMGRL (DGMGRL>
) command prompt on your default display device. This option is useful if you are directing the command output to a file or to another display tool.
<logon>
is:
username/password [@connect-identifier]
The username
and password
used to connect to the database. The connect-identifier
is a fully specified connect descriptor or a name to be resolved by an Oracle naming method (for example, TNS). The connect-identifier
is optional.
<command>
is a single command.
For example:
% DGMGRL sys/knl_test7@primary "show database 'North_Sales'"
The following subsections specify the command format that you enter at the DGMGRL>
command prompt.
The DGMGRL commands allow you to create and maintain one broker configuration at a time. A broker configuration can consist of a primary database and up to 9 standby databases.
After you invoke the command-line interface, you can enter any of the DGMGRL commands listed in Table 8-1. Each command and its associated parameters are described in detail in later sections of this chapter.
Table 8-1 Summary of DGMGRL Commands
Command | Effect |
---|---|
|
Adds a new standby database profile to the existing broker configuration. |
|
Connects to the specified database using the specified username. |
|
Creates a broker configuration and creates and adds a primary database profile to the configuration. |
|
Disables broker management of a configuration so that the configuration and all of its databases are no longer managed by the broker. |
|
Disables broker management of the named standby database. |
|
Disables fast-start failover. |
|
Changes the value of a property for the broker configuration. |
EDIT CONFIGURATION (Protection Mode) |
Changes the current protection mode setting for the broker configuration. |
|
Changes the value of a property for the named database. |
|
Changes the name used by the broker to refer to the specified database. |
|
Changes the state of the specified database. |
|
Sets the name of the initialization parameter file for the specified instance. |
|
Changes the value of a property for the specified instance. |
|
Enables broker management of the broker configuration and all of its databases. |
|
Enables broker management of the specified database. |
|
Enables the broker to automatically failover from the primary database to a target standby database. |
|
Exits the Data Guard command-line interface. |
|
Performs a database failover operation in which the standby database, to which DGMGRL is currently connected, fails over to the role of primary database. |
|
Displays online help for the Data Guard command-line interface. |
Quits the Data Guard command-line interface. |
|
|
Reinstates the database after a failover. |
|
Removes the broker configuration including all of its database profiles from the broker configuration file. |
|
Removes the specified standby database profile from the broker configuration. |
|
Removes knowledge of an instance from an existing database profile in the broker configuration. |
|
Displays information about the broker configuration. |
|
Displays information about the specified database. |
|
Displays information about the specified instance. |
|
Shuts down a currently running Oracle database. |
|
Starts the observer. |
|
Starts an Oracle instance with the same options as SQL*Plus, including mounting and opening a database. |
|
Stops the observer. |
|
Performs a switchover operation in which the current primary database becomes a standby database, and the specified standby database becomes the primary database. |
Note:
Existing Oracle9i command-line scripts are supported in Oracle Database 10g for non-RAC databases. See Appendix A for information about deprecated commands.To use DGMGRL, the following must be true:
The DG_BROKER_START
dynamic initialization parameter is set to TRUE
.
To enable broker operations that require restarting instances without manual intervention, Oracle Net Services must be configured on each of the hosts that contain the primary and standby database instances. Specifically, the listener.ora file must contain static configuration information about the instance. The GLOBAL_DBNAME
attribute must be set to db_unique_name
_DGMGRL.
db_domain
. See Section 2.2 for additional information.
The net service name, if used, must be resolvable from any of the hosts in the configuration.
See Also:
Section 2.1 for information about the listener prerequisites. Chapter 7 for more information about preparing and starting Oracle Data Guard broker. See the Oracle Database Administrator's Guide for more information about setting up the network files and listener on the standby database.You must have SYSDBA privileges to use the Data Guard command-line interface. Do not include AS SYSDBA
on the CONNECT
command because SYSDBA is the default setting for this command.
The password for SYS needs to be identical on all databases, and all databases should use the remote password file (either SHARED or EXCLUSIVE).
See Also:
Oracle Data Guard Concepts and Administration for information about passwordsIf you specify more than one option on the command, you can specify the options in any order.
A semicolon is required at the end of each DGMGRL command.
Characters specified in a DGMGRL command string value are interpreted as lowercase characters, unless enclosed in double (") or single (') quotation marks. For example, database and DatAbaSe are equivalent, but "database" and "DatAbaSe" are not.
You can use the backslash (\) to escape a single quotation mark ('), a double quotation mark ("), and the backslash character (\) itself if these characters appear in a character string.
Some operations on a broker configuration may require that one or more databases be shut down and restarted. In most cases, DGMGRL will automatically shut down and restart a given database for you if the following are true:
The instance-name
is the SID (this applies to Enterprise Manager as well as DGMGRL).
The broker must be able to connect to the database using the username and password given in the last CONNECT
command, even if the last CONNECT
command was used to connect to another database. Thus, the remote password file for the database must contain the username and password given in the last CONNECT
command.
See Also:
Oracle Database Administrator's Guide for more information about setting up remote password files and the default location of the PFILE and SPFILE initialization parameter files.Command Examples
Example 1
This example demonstrates how to connect to the DGMGRL command-line interface on a local system.
% dgmgrl DGMGRL for Linux: Version 10.2.0.1.0 - ProductionCopyright (c) 2000, 2005, Oracle. All rights reserved.Welcome to DGMGRL, type "help" for information. DGMGRL> CONNECT sys/change_on_install; Connected.
Example 2
This example demonstrates how to connect to the Data Guard (DGMGRL) command-line interface on a remote system.
DGMGRL> CONNECT sys/change_on_install@remote-stby; Connected.
When you are done working with the command-line interface and want to return to the operating system, enter the EXIT
or QUIT
command at the DGMGRL command prompt. For example:
DGMGRL> EXIT;
Creates a new standby database profile and adds it to the existing broker configuration. The standby database type (physical or logical) is specified by the MAINTAINED AS
clause.
Format
ADD DATABASE database-name AS
CONNECT IDENTIFIER IS connect-identifier
MAINTAINED AS {PHYSICAL | LOGICAL};
Command Parameters
The name that will be used by the broker to refer to this standby database. It must match (case-insensitive) the value of the corresponding database DB_UNIQUE_NAME
initialization parameter.
A fully specified connect descriptor or a name to be resolved by an Oracle Net Services naming method (for example, TNS).
Usage Notes
You must connect to the primary database to issue this command.
The broker uses the specified connect-identifier
to communicate with the specified database from other databases. Therefore, you must ensure that the connect-identifier
can be used to address the specified database from all databases in your configuration. For example, if you use tnsnames.ora files to resolve the connect-identifier
, you must ensure it will be resolved to the same connect descriptor in all tnsnames.ora files and the resulting connect descriptor can be used to reach the database specified in this ADD DATABASE
command.
If the connection cannot be made, the broker does not add the new database to the configuration.
Command Example
Example 1
The following example shows how to add a database named DR_Sales
.
DGMGRL> ADD DATABASE DR_Sales AS > CONNECT IDENTIFIER IS DR_Sales.foo.com > MAINTAINED AS PHYSICAL; Database "DR_Sales" added
Connects a given username to the specified database.
Format
CONNECT username/password [@connect-identifier];
Command Parameters
Represents the username and password with which you want to connect to the database.
Consists of the Oracle Net Services connect identifier of the database to which you want to connect. The exact syntax depends upon the Oracle Net Services communications protocol your Oracle installation uses.
Usage Notes
The username and password must be valid for the database to which you are trying to connect. The username you specify must have the SYSDBA privilege. You do not have to include AS SYSDBA
on the CONNECT
command because SYSDBA is the default setting for this command.
If the CONNECT
command returns an error, check to see that you specified a valid connect-identifier
.
Command Examples
Example 1
This example connects to the default database on the local system.
DGMGRL> CONNECT sys/change_on_install; Connected.
Example 2
This example connects to a remote database whose connect-identifier
is prmy
.
DGMGRL> CONNECT sys/change_on_install@prmy; Connected.
Example 3
This example connects to a database using CONNECT '/'
so that connection credentials are not visible on the command line:
DGMGRL> CONNECT /@prmy;
You must set up Oracle Wallet to use CONNECT '/'
. By setting up Oracle Wallet, you can write a script to securely start and run the observer as a background job without specifying database credentials in the script.
See Also:
Oracle Database Advanced Security Administrator's Guide for more information about Oracle WalletCreates a new broker configuration, and creates and adds a primary database profile to the configuration.
Format
CREATE CONFIGURATION configuration-name AS
PRIMARY DATABASE IS database-name
CONNECT IDENTIFIER IS connect-identifier;
Command Parameters
A user-friendly name for the configuration you are creating. Valid names contain any alphanumeric characters. If spaces are included in the name, the name must be enclosed in double or single quotation marks. The name must consist of 30 or fewer bytes.
The name that will be used by the broker to refer to the primary database. It must match (case-insensitive) the value of the corresponding database DB_UNIQUE_NAME
initialization parameter.
A fully specified connect descriptor or a name to be resolved by an Oracle Net Services naming method (for example, TNS).
Usage Notes
A broker configuration is a named collection of one or more databases that you want to manage as a group. You must specify a value for each of the command parameters. There are no default values.
You must connect to the primary database to issue this command.
The broker uses the specified connect-identifier
to communicate with the specified database from other databases. Therefore, you must ensure that the connect-identifier
can be used to address the specified database from all databases in your configuration. For example, if you use tnsnames.ora files to resolve the connect-identifier
, you must ensure it will be resolved to the same connect descriptor in all tnsnames.ora files and the resulting connect descriptor can be used to reach the primary database specified in this CREATE CONFIGURATION
command.
To add standby databases after you create the broker configuration, use the ADD DATABASE command.
Command Example
Example 1
The following example creates a new broker configuration named DRSolution
with a primary database named North_Sales
.
DGMGRL> CREATE CONFIGURATION 'DRSolution' AS > PRIMARY DATABASE IS 'North_Sales' > CONNECT IDENTIFIER IS North_Sales.foo.com; Configuration "DRSolution" created with primary database "North_Sales"
Disables broker management of a configuration so that the configuration and all of its databases are no longer managed by the broker.
Format
DISABLE CONFIGURATION;
Command Parameters
None.
Usage Notes
A disabled configuration and all of its constituent databases are no longer managed by the broker.
The only way to disable broker management of the primary database is to use the DISABLE CONFIGURATION
command.
This command does not remove the broker configuration. See the REMOVE CONFIGURATION command for more information about removing the configuration.
You can edit database properties and modify the configuration's protection mode while the configuration is disabled. However, any changes made to properties or to the protection mode will not take effect until the configuration is enabled.
This command cannot be executed if fast-start failover is enabled.
Command Example
Example 1
The following example disables management of the broker configuration and all of its databases.
DGMGRL> DISABLE CONFIGURATION; Disabled.
Disables broker management of the named standby database. This means that broker directed state changes will be disallowed for this database, and the broker will not monitor the database for health status or for monitorable property values.
Format
DISABLE DATABASE database-name;
Command Parameter
Name of the standby database to be disabled.
Usage Notes
You cannot specify the name of a primary database.
Use the DISABLE CONFIGURATION
command to disable the primary and all standby databases.
If the sole standby database is disabled, you have no failover option. This standby database is not viable for failover until it is reenabled.
This command cannot be executed if fast-start failover is enabled.
Command Example
Example 1
The following example shows how to disable a database named DR_Sales
.
DGMGRL> DISABLE DATABASE 'DR_Sales'; Disabled.
Disables fast-start failover and prevents the observer from initiating a failover to the target standby database. See Section 5.5.4, "Disabling Fast-Start Failover" for complete information.
Format
DISABLE FAST_START FAILOVER [ FORCE ];
Command Parameters
None.
Usage Notes
If the primary and target standby database have a network connection, use DISABLE FAST_START FAILOVER
without the FORCE
option to disable fast-start failover on all databases in the broker configuration. If errors occur during the disable operation, the broker returns an error message and stops the disable operation. You may need to reissue the DISABLE FAST_START FAILOVER
command with the FORCE
option to override the error conditions and disable fast-start failover.
Use DISABLE FAST_START FAILOVER
with the FORCE
option when the network between the primary and target standby databases is disconnected or when the database upon which the command is received does not have a connection with the primary database. The FORCE
option disables fast-start failover on the database to which you are connected, even when errors occur.
Disabling fast-start failover with the FORCE
option on a primary database that is disconnected from the observer and the target standby database does not prevent the observer from initiating a fast-start failover to the target standby database.
You can disable fast-start failover while connected to any database in the broker configuration.
If disabled by force at the target standby database and the connection subsequently resumes with the primary database, fast-start failover is disabled on all databases in the configuration.
Command Example
Example 1
The following example shows how to disable fast-start failover.
DGMGRL> DISABLE FAST_START FAILOVER; Disabled.
Changes the value of a property for the broker configuration.
Format
EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = threshold-seconds;
Command Parameter
Usage Notes
Issue this command while connected to the primary database or to any standby database in the broker configuration having connectivity to the primary database.
This command specifies a value for the FastStartFailoverThreshold
property. The number of seconds you specify determines how long the observer and target standby database should simultaneously wait to hear from the primary database before initiating a fast-start failover. The FastStartFailoverThreshold
property is discussed in Section 9.2.10 and in Section 5.5.2.
Set this property to increase or decrease the sensitivity of the fast-start failover trigger.
Specify the threshold-value as a positive, nonzero number of seconds. The default value is 30 seconds and may be made to be configuration-dependent (for example, if the primary database is a RAC.)
This property may be modified whether fast-start failover is enabled or disabled.
Use the SHOW CONFIGURATION
command to display the current property information for the configuration.
Command Example
Example 1
The following example shows how to set the FastStartFailoverThreshold
property to 90 seconds.
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThresdhold=90;
Edits the current protection mode setting for the broker configuration.
Format
EDIT CONFIGURATION SET PROTECTION MODE AS protection-mode;
Command Parameter
The data protection mode in which you want the configuration to run when the configuration is enabled. The possible protection modes are:
MAXPROTECTION
MAXAVAILABILITY
MAXPERFORMANCE
Usage Notes
Before you use the EDIT CONFIGURATION
command to set the protection mode to either the MAXPROTECTION
or MAXAVAILABILITY
mode, ensure that standby redo log files are configured on a standby database.
The following table shows the configuration protection modes and the minimum corresponding settings for redo transport services:
Protection Mode | Redo Transport | Standby Redo Log Files Needed? | Required for Fast-Start Failover? |
---|---|---|---|
MAXPROTECTION |
SYNC |
Yes | No |
MAXAVAILABILITY |
SYNC |
Yes | Yes |
MAXPERFORMANCE |
ARCH or ASYNC |
Yes for ASYNC |
No |
The default protection mode for the configuration is MAXPERFORMANCE
.
See Also:
Chapter 4 for more information about the protection modes and redo transport servicesMAXAVAILABILITY
is required in order to enable fast-start failover.
This command cannot be executed if fast-start failover is enabled.
After you change the protection mode, the broker will automatically restart the primary database, if necessary.
Use the SHOW CONFIGURATION
command to display the current protection mode for the configuration.
DGMGRL> SHOW CONFIGURATION;
Configuration
Name: DRSolution
Enabled: YES
Protection Mode: MaxPerformance
Databases:
North_Sales - Primary database
DR_Sales - Physical standby database
Current status for "DRSolution":
SUCCESS
If broker management of the configuration is disabled when you enter the EDIT CONFIGURATION
command, the protection mode of the configuration does not take effect until the next time you enable the configuration with the ENABLE CONFIGURATION command.
Command Example
Example 1
The following example shows how to upgrade the broker configuration to the MAXPROTECTION
protection mode. The broker configuration will have the maximum amount of data protection after these commands complete.
Verify that standby redo log files are configured on the standby database and that the redo transport service is set to SYNC
, for example:
DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'LogXptMode'='SYNC'; Property "LogXptMode" updated DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION; Operation requires shutdown of instance "sales1" on database "North_Sales" Shutting down instance "sales1"... Database closed. Database dismounted. ORACLE instance shut down. Operation requires startup of instance "sales1" on database "North_Sales" Starting instance "sales1"... ORACLE instance started. Database mounted.
The broker automatically stops and restarts the primary database.
Changes the value of a property for the named database.
Format
EDIT DATABASE database-name
SET PROPERTY property-name = value;
Command Parameters
The name of the database for which you want to change a property value.
The name of an existing database-specific property. If this is a RAC database, this property change affects all instances of the database.
The new value for the property.
Caution:
This command can be used to change the value of a per-instance property if and only if just one instance is known by the broker for the named database. An attempt to use this command to change a per-instance property when the broker knows of multiple instances of the database will be rejected. It is recommended to only useEDIT INSTANCE (property)
to change the value of a per-instance property.Command Examples
Example 1
Edit a database level property.
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'ArchiveLagTarget'=1200; Property "ArchiveLagTarget" updated
Example 2
Edit an instance level property of a non-RAC database.
DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY > 'StandbyArchiveLocation'='/archfs/arch/'; Property "StandbyArchiveLocation" updated
Example 3
Edit an instance level property of a RAC database. This will not succeed because it is not clear to which instance the property change should be applied.
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY > 'StandbyArchiveLocation'='/archfs/arch/'; Error: ORA-16587: ambiguous object specified to Data Guard broker Failed.
Changes the name used by the broker to refer to the specified database, as recorded in that database's profile in the broker configuration.
Format
EDIT DATABASE database-name
RENAME TO new-database-name;
Command Parameters
The name of the database that you want to change.
The name of the new database.
Usage Notes
Use this command to track changes to the DB_UNIQUE_NAME
initialization parameter for this database.
Caution:
The database-name
must always match the value for that database's DB_UNIQUE_NAME
initialization parameter.
This command can only be done when broker management of the database that you are renaming is disabled.
Command Example
Example 1
The following example shows how to edit and rename a database.
DGMGRL> EDIT DATABASE 'DR_Sales_typo' RENAME TO 'DR_Sales'; Succeeded. DGMGRL> ENABLE DATABASE 'DR_Sales'; Enabled.
Changes the state of the specified database.
Format
EDIT DATABASE database-name
SET STATE = state
[WITH APPLY INSTANCE = instance-name];
Command Parameters
The name of the database for which you want to change the state.
The state in which you want the database to be running. The possible states are:
ONLINE
LOG-TRANSPORT-OFF
(primary database only)LOG-APPLY-OFF
(standby database only)READ-ONLY
(physical standby database only)OFFLINE
The name of the instance you want to become the apply instance if this is a RAC standby database.
Usage Notes
If the target state is ONLINE
and this database is currently in the standby role, the optional WITH APPLY INSTANCE
clause specifies which instance will become the apply instance.
If the target state is not ONLINE
or if the database is currently in the primary role, the WITH APPLY INSTANCE
clause is ignored even if it is specified.
All instances of a RAC database are affected by this database state change.
Command Example
The following examples show how to change the state of a database.
Example 1
DGMGRL> EDIT DATABASE 'DR_Sales' SET STATE='READ-ONLY'; Succeeded.
Example 2
DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='OFFLINE'; Operation requires shutdown of instance "sales1" on database "North_Sales" Shutting down instance "sales1"... Database closed. Database dismounted. ORACLE instance shut down.
Sets the name of the initialization parameter file for the specified instance.
Format
EDIT INSTANCE instance-name
[ON DATABASE database-name]
SET AUTO PFILE [= { initialization-file | OFF } ];
Command Parameters
The name of the instance (SID) for which you want to specify its initialization parameter file.
The name of the database to which the instance-name
is associated.
Executes the startup operation for the instance when a subsequent broker operation requires the instance to be started automatically. If SET AUTO PFILE
is set to OFF
, automatic restart of that instance is disabled. When a subsequent operation needs to start that instance, you must start it manually. If you do not specify SET AUTO PFILE
for the instance, the automatic startup operation looks for the initialization parameter file at the default location.
Usage Notes
The instance-name
can be unique across the configuration. If instance-name
is not unique, you must specify both the database-name
and the instance-name
to fully identify the instance.
SET AUTO PFILE
is valid only for the duration of the current DGMGRL session. You must specify SET AUTO PFILE
again if you quit and reenter DGMGRL.
Command Example
Example 1
The following example shows how to edit an instance of a database.
DGMGRL> EDIT INSTANCE 'dr_sales1' ON DATABASE 'DR_Sales' > SET AUTO PFILE='initsales1.ora'; Instance 'dr_sales1' updated
Changes the value of a property for the specified instance.
Format
EDIT INSTANCE instance-name
[ON DATABASE database-name]
SET PROPERTY property-name = value;
Command Parameters
The name of the instance (SID) for which you want to change a per-instance property value.
The name of the database to which the instance-name
is associated.
The name of the per-instance property for which you want to set a new value.
The new value for the property.
Usage Notes
The instance-name
can be unique across the configuration. If instance-name
is not unique, you must specify both the database-name
and the instance-name
to fully identify the instance.
This command cannot be used to change a database-specific property.
Command Examples
Example 1
Edit an instance level property.
DGMGRL> EDIT INSTANCE 'sales1' ON DATABASE 'North_Sales' > SET PROPERTY 'StandbyArchiveLocation'='/archfs/arch/'; Property "StandbyArchiveLocation" updated.
Example 2
Edit a database level property. This will not be allowed.
DGMGRL> EDIT INSTANCE 'sales1' ON DATABASE 'North_Sales' > SET PROPERTY 'LogXptMode'='SYNC'; Error: ORA-16586: could not edit database property through instance Failed.
Enables the broker to actively manage the broker configuration including all of its databases.
Format
ENABLE CONFIGURATION;
Command Parameters
None.
Usage Notes
Use this command to enable broker management of the primary database.
By default, broker management of the configuration's databases is enabled in the ONLINE
state with redo transport services turned on at the primary database and log apply services turned on at the standby databases. You can change the state of any database using the EDIT DATABASE (State) command, but not when the database or the entire configuration is disabled.
Use the SHOW CONFIGURATION command to display information about the configuration.
Command Example
Example 1
The following example enables management of a broker configuration.
DGMGRL> ENABLE CONFIGURATION; Enabled.
Enables broker management of the specified standby database.
Caution:
Do not issue theENABLE DATABASE
command on a standby database that needs to be reinstated. See Section 5.4.3 for more details.Format
ENABLE DATABASE database-name;
Command Parameter
The name of the standby database for which you want to enable broker management.
Usage Notes
A standby database may have been disabled by the broker as a consequence of a prior failover or switchover operation. See Section 5.4.3 to understand how the database can be reenabled.
By default, broker management of the standby database is enabled in the ONLINE
state with log apply services enabled. You can change the state of the standby database using the EDIT DATABASE (State) command, but only when the database is enabled.
Use the SHOW DATABASE command to display information about the database.
For a RAC database, only one instance is required to be started and mounted for this command to succeed.
Command Example
Example 1
The following example shows how to enable a database named DR_Sales
.
DGMGRL> ENABLE DATABASE 'DR_Sales'; Enabled.
Enables the broker to fail over to a specifically-chosen, synchronized standby database in the event of loss of the primary database, without requiring you to perform any manual steps to invoke the failover. See Section 5.5.2, "Enabling Fast-Start Failover" for complete information.
Format
ENABLE FAST_START FAILOVER;
Command Parameters
None.
Usage Notes
The prerequisites described in Section 5.5.1 must be met before you issue this command to enable fast-start failover.
Issuing the ENABLE FAST_START FAILOVER
command does not trigger a failover, it only allows the observer to monitor the configuration and initiate fast-start failover if conditions warrant a failover.
You can enable fast-start failover while connected to any database system in the broker configuration.
If you do not start the observer after you have enabled fast-start failover, the ORA-16819
warning displays for the primary and target standby databases. For example:
DGMGRL> SHOW DATABASE 'North_Sales'; Database Name: North_Sales Role: PRIMARY Enabled: YES Intended State: ONLINE Instance(s): sales1 Current status for "North_Sales": Warning: ORA-16819: Fast-Start Failover observer not started
To enable fast-start failover for a broker configuration with multiple standby databases, the FastStartFailoverTarget
property on the primary database and one standby database must be set to point to each other. Both the primary database and the target standby database must have:
Standby redo logs configured
The LogXptMode
property set to SYNC
Flashback Database enabled on both the primary and standby databases
In addition, the configuration protection mode must be set to MAXAVAILABILITY
. Step 2 in Section 5.5.2 and Section 9.2.9 provide more information about the FastStartFailoverTarget
property.
Once you have enabled fast-start failover, you must comply with the restrictions described in Section 5.5.2.2, "Restrictions When Fast-Start Failover is Enabled".
Command Example
Example 1
The following example enables fast-start failover.
DGMGRL> ENABLE FAST_START FAILOVER; Enabled.
Example 2
The following example attempts to enable fast-start failover when the configuration protection mode is MAXPERFORMANCE
.
DGMGRL> SHOW CONFIGURATION; Configuration Name: The SUPER cluster Enabled: YES Protection Mode: MaxPerformance Fast-Start Failover: DISABLED Databases: dgb1 - Primary database dgb12 - Physical standby database Current status for "The SUPER cluster": SUCCESS DGMGRL> ENABLE FAST_START FAILOVER; Error: ORA-16651: requirements not met for enabling Fast-Start Failover Failed.
Exits (quits) the command-line interface.
Format
EXIT;
Command Parameters
None.
Usage Notes
This command has the same effect as the QUIT command.
A database connection is not required to execute this command. However, if you are connected, this command breaks the connection.
Command Example
Example 1
The following example demonstrates how to exit (quit) the command-line interface.
DGMGRL> EXIT;
Invokes a failover that transitions the named (target) standby database into the role of a primary database. This type of failover is referred to as manual failover. See Section 5.4, "Manual Failover" for more information.
Note:
Because a failover results in a transition of a standby database to the primary role, it should be performed only in the event of a catastrophic failure of the primary database when there is no possibility of recovering the primary database in a timely manner. Failover may or may not result in data loss depending on the protection mode in effect at the time of the failover and whether the target standby database was synchronized with the primary database.Use the SWITCHOVER
command if you want the current primary database and a standby database to switch roles with no data loss.
Format
FAILOVER TO database-name
[ IMMEDIATE ];
Command Parameters
The name of the standby database you want to fail over to the primary database role.
Usage Notes
You can perform a manual failover or set up the broker to perform a fast-start failover. See the ENABLE FAST_START FAILOVER command for information about allowing the broker to automatically invoke failover, when conditions warrant a failover.
If fast-start failover is enabled, you may perform a complete manual failover only to the target standby database and only if the target standby database is synchronized with the primary database, and only when the observer is started. You cannot perform an immediate manual failover when fast-start failover is enabled.
The specified standby database must be enabled before the primary database fails. However, an enabled standby database that was taken offline can be a candidate for the failover operation. In this case, restart the standby database using DGMGRL STARTUP
command, then issue the FAILOVER
command.
The failover operates on the specified standby database and changes one its role to a primary database. Any other standby databases not involved in the failover remain in the standby role.
Before you issue the FAILOVER
command, verify that you are connected to the standby database that will become the new primary database. If necessary, issue a CONNECT command to connect to the standby database.
If the FAILOVER
command is issued without any options, the standby database chosen as the failover target applies all unpiled redo it has received before changing to the primary role.
If the standby database that you want to fail over to the primary role is a RAC database, the broker will shut down all of the instances except the apply instance before it continues the failover operation. See Section 5.4.3 for details.
If the standby database that is transitioning into the role of primary database is a physical standby database, then the database instance (or instances) will be restarted if the database was opened read-only prior to the failover. The database restart occurs as part of the failover. If the database is a logical standby database, the database instance (or instances) does not need to be restarted. Failing over to a logical standby database has the side effect of disabling all other standby databases in the configuration.
If the broker configuration is in either MAXPROTECTION
or MAXAVAILABILITY
protection mode, a manual failover operation will force the protection mode to be MAXPERFORMANCE
. The redo transport service settings are unaffected. You need to restore the desired protection mode for the resulting configuration after the failover operation.
Note:
With fast-start failover, the broker preserves the protection mode at the same maximum availability level in which it was operating before the failover.If the FAILOVER
command is issued with the IMMEDIATE
option, no attempt is made to apply any unapplied redo that has been received. This option more likely results in lost application data even when standby redo log files are configured on the standby database. Additionally, any remaining standby databases in the configuration cannot function as such until they are reenabled. See Section 5.4.3 for more information about reenabling databases.
If Flashback Database was enabled on the former (failed) primary database prior to the failover, the former primary database can be reinstated using the broker's REINSTATE
command (see the REINSTATE DATABASE command).
If failover was performed to a physical standby database, any other physical standby databases that were disabled by the failover can be reinstated if Flashback Database was enabled on the standby database and there are sufficient flashback logs available. See Section 5.4.3, "Reenabling Disabled Databases After Failover or Switchover" for step-by-step instructions.
The original primary database can only participate in the configuration as a standby database after it is reenabled.
Caution:
You should shut down the original primary database if it still has any active instances running prior to failing over.See Also:
Section 5.4.3 about reenabling the original primary database so that it could serve as a standby database to the primary databaseCommand Examples
Example 1
The following example performs a failover in which the standby database, DR_Sales
, transitions to the primary role:
DGMGRL> FAILOVER TO "DR_Sales"; Performing failover NOW, please wait... Operation requires shutdown of instance "dr_sales1" on database "DR_Sales" Shutting down instance "dr_sales1"... ORA-01109: database not open Database dismounted. ORACLE instance shut down. Operation requires startup of instance "dr_sales1" on database "DR_Sales" Starting instance "dr_sales1"... ORACLE instance started. Database mounted. Failover succeeded, new primary is "DR_Sales"
Displays online help for the Data Guard command-line interface.
Format
HELP [topic];
Command Parameter
The topic for which you want to display help information. If you do not specify a topic, the command lists all of the topics and the format. Valid topics are:
ADD
CONNECT
CREATE
DISABLE
EDIT
ENABLE
EXIT
FAILOVER
HELP
QUIT
REINSTATE
REM
REMOVE
SHOW
SHUTDOWN
START
STARTUP
STOP
SWITCHOVER
Usage Note
A database connection is not required to execute this command.
Command Examples
Example 1
The following examples get help on the HELP
and CONNECT
commands.
DGMGRL> HELP HELP; Display description and syntax for a given command Syntax: HELP [<command>]; DGMGRL> HELP CONNECT; Connect to an Oracle instance Syntax: CONNECT <username>/<password>[@<connect identifier>]
Example 2
The following example gets help on the EDIT
commands.
DGMGRL> HELP EDIT Edit a configuration, database or instance Syntax: EDIT CONFIGURATION SET PROTECTION MODE AS {MaxProtection|MaxAvailability|MaxPerformance}; EDIT CONFIGURATION SET PROPERTY <property name> = <value>; EDIT DATABASE <database name> SET PROPERTY <property name> = <value>; EDIT DATABASE <database name> RENAME TO <new database name>; EDIT DATABASE <database name> SET STATE = <state> [WITH APPLY INSTANCE = <instance name>]; EDIT INSTANCE <instance name> [ON DATABASE <database name>] SET AUTO PFILE [ = {<initialization file path>|OFF} ]; EDIT INSTANCE <instance name> [ON DATABASE <database name>] SET PROPERTY <property name> = <value>;
Quits (exits) the Data Guard command-line interface.
Format
QUIT;
Command Parameters
None.
Usage Notes
This command has the same effect as the EXIT command.
A database connection is not required to execute this command. However, if you are connected, this command breaks the connection.
Command Example
Example 1
The following example shows how to quit (exit) the command-line interface.
DGMGRL> QUIT;
Reinstates a former primary database as a new standby database in the broker configuration for the current primary database.
Format
REINSTATE DATABASE database-name;
Command Parameter
The name of the database that is to be reinstated in the broker configuration.
Usage Notes
If the conditions for reinstatement described in Section 5.5.7 are not satisfied, the reinstatement will fail with an appropriate error status and the specified database will remain disabled.
If the database-name
specified is that of the old primary and fast-start failover is enabled, the old primary database will be reinstated as a standby to the new primary, and the fast-start failover environment will be updated to reflect the availability of the new standby database. It will accept redo data from the new primary database and be the target of a fast-start failover should the new primary database fail. Reinstatement occurs automatically if the observer is running.
This command does not require that fast-start failover is enabled. It can be used to reinstate an old primary database after a complete manual failover has been performed.
Issue this command while connected to any database in the broker configuration, except the database that is to be reinstated.
Command Examples
Example 1
The following example reinstates the DR_Sales
database as a standby database in the broker configuration.
DGMGRL> REINSTATE DATABASE 'North_Sales'; Reinstating database "North_Sales", please wait... Operation requires shutdown of instance "sales1" on database "North_Sales" Shutting down instance "sales1"... ORA-01109: database not open Database dismounted. ORACLE instance shut down. Operation requires startup of instance "sales1" on database "North_Sales" Starting instance "sales1"... ORACLE instance started. Database mounted. Continuing to reinstate database "North_Sales" ... Reinstatement of database "North_Sales" succeeded
Removes all of the broker configuration information, including all database profiles, from the Data Guard configuration file, and terminates broker management of all of the databases associated with the broker configuration.
Caution:
When you use theREMOVE CONFIGURATION
command, all profile information is deleted from the Data Guard configuration file and cannot be recovered.Format
REMOVE CONFIGURATION [ PRESERVE DESTINATIONS ];
Command Parameters
None.
Usage Notes
When you remove a broker configuration, management of all of the databases associated with that configuration is disabled.
By default, the command removes the corresponding broker settings of the LOG_ARCHIVE_DEST_
n
initialization parameter on the primary database and the LOG_ARCHIVE_CONFIG
initialization parameters on all databases in the configuration. To preserve these settings, use the PRESERVE DESTINATIONS
option.
This command does not remove or affect the actual primary or standby database instances, databases, datafiles, control files, initialization parameter files, server parameter files, or log files of the underlying Data Guard configuration.
You cannot remove the configuration when fast-start failover is enabled.
Command Example
The following examples show a successful and an unsuccessful REMOVE CONFIGURATION command.
Example 1 Successful REMOVE CONFIGURATION Command
The following command shows how to remove configuration information from the configuration file.
DGMGRL> REMOVE CONFIGURATION; Removed configuration DGMGRL> SHOW CONFIGURATION; Error: ORA-16532: Data Guard broker configuration does not exist Configuration details cannot be determined by DGMGRL
Example 2 Unsuccessful REMOVE CONFIGURATION Command
The following command is unsuccessful because fast-start failover is enabled.
DGMGRL> REMOVE CONFIGURATION; Error: ORA-16654: Fast-Start Failover was enabled Failed. DGMGRL> SHOW CONFIGURATION VERBOSE; Configuration Name: DRSolution Enabled: YES Protection Mode: MaxAvailability Fast-Start Failover: ENABLED Databases: North_Sales - Primary database West_Sales - Logical standby database - Fast-Start Failover target DR_Sales - Physical standby database Fast-Start Failover Threshold: 45 seconds Observer: stacm29 Current status for "DRSolution": SUCCESS
Removes the specified standby database's profile from the broker configuration and terminates broker management of the standby database.
Caution:
When you use theREMOVE DATABASE
command, the database's profile information is deleted from the broker configuration file and cannot be recovered.Format
REMOVE DATABASE database-name [ PRESERVE DESTINATIONS ];
Command Parameter
The name of the standby database whose profile you want to remove from the broker configuration.
Usage Note
An error is returned if you specify the name of the primary database in the broker configuration.
By default, the command removed the corresponding broker settings of the LOG_ARCHIVE_DEST_
n
initialization parameter on the primary database and the LOG_ARCHIVE_CONFIG
initialization parameter on all databases in the configuration. To preserve these settings, use the PRESERVE DESTINATIONS
option.
This command cannot be executed if fast-start failover is enabled and database-name specifies the name of the target standby database.
Command Example
Example 1
The following example shows how to remove a database from the Data Guard configuration.
DGMGRL> SHOW CONFIGURATION; Configuration Name: DRSolution Enabled: NO Protection Mode: MaxPerformance Fast-Start Failover: DISABLED Databases: North_Sales - Primary database DR_Sales - Physical standby database Current status for "DRSolution": SUCCESS DGMGRL> REMOVE DATABASE 'DR_Sales'; Removed database "DR_Sales" from the configuration DGMGRL> SHOW CONFIGURATION; Configuration Name: DRSolution Enabled: NO Protection Mode: MaxPerformance Fast-Start Failover: DISABLED Databases: North_Sales - Primary database Current status for "DRSolution": SUCCESS
Removes an instance from an existing database profile in the broker configuration.
Format
REMOVE INSTANCE instance-name
[ON DATABASE database-name];
Command Parameters
The name of the instance (SID) that you want to remove from the broker configuration.
The name of the database to which the instance-name
is associated.
Usage Notes
In a RAC database, the broker automatically adds started instances into the corresponding database profile. However, the broker may not automatically remove instances from the database profile. The REMOVE INSTANCE
command can be used to manually remove any instance that no longer exists from the database profile.
The instance-name
can be unique across the configuration. If instance-name
is not unique, you must specify both the database-name
and the instance-name
to fully identify the instance.
This command is rejected for an instance that is currently active in the broker configuration.
This command is rejected if this is the only instance currently associated with a database profile.
Command Example
Example 1
The following example shows how to remove an instance of the database.
DGMGRL> REMOVE INSTANCE 'dr_sales3' ON DATABASE 'DR_Sales'; Removed instance "dr_sales3" from the database "DR_Sales"
Displays a summary and status of the broker configuration. The summary lists all databases included in the broker configuration and other information pertaining to the broker configuration itself, including the fast-start failover status.
Format
SHOW CONFIGURATION [VERBOSE];
Command Parameters
None.
Usage Notes
Use SHOW CONFIGURATION VERBOSE
to show the fast-start failover threshold and the observer host system when fast-start failover is enabled.
Command Examples
Example 1 Showing a Summary of the DRSolution Configuration
The following example provides a summary of the DRSolution
configuration.
DGMGRL> SHOW CONFIGURATION; Configuration Name: DRSolution Enabled: YES Protection Mode: MaxPerformance Fast-Start Failover: DISABLED Databases: North_Sales - Primary database DR_Sales - Physical standby database Current status for "DRSolution" SUCCESS
Example 2 Verifying the Readiness of Fast-Start Failover
The following example verifies the readiness of the fast-start failover configuration:
DGMGRL> SHOW CONFIGURATION VERBOSE; Configuration Name: DRSolution Enabled: YES Protection Mode: MaxAvailability Fast-Start Failover: ENABLED Databases: North_Sales - Primary database DR_Sales - Physical standby database - Fast-Start Failover target Fast-Start Failover Threshold: 45 seconds Observer: observer.foo.com Current status for "DRSolution": SUCCESS
Displays information or property values of the specified database and its instances.
Format
SHOW DATABASE [VERBOSE] database-name [property-name];
Command Parameters
The name of the database for which you want to display information.
The name of the property for which you want to display a value.
Usage Notes
The SHOW DATABASE
command shows a brief summary of the database. SHOW DATABASE VERBOSE
shows properties of the database in addition to the brief summary. They both show the status of the database.
The SHOW DATABASE VERBOSE
command shows database-specific properties and instance-specific properties. For a non-RAC database, the values of the instance-specific properties are those of the only instance of the database. For a RAC database, the values of the instance-specific properties will not be shown, although the property names are still listed. To see the instance-specific values of these properties, use the SHOW INSTANCE
command.
The properties that the SHOW DATABASE VERBOSE
command shows depend on the database role and the configuration composition:
For the primary database, properties specific to physical standby databases are shown only if there is at least one physical standby database in the configuration. The properties specific to logical standby databases are shown only if there is at least one logical standby database in the configuration.
For physical standby databases, properties specific to logical standby databases are not shown.
For logical standby databases, properties specific to physical standby databases are not shown.
This command is rejected if you use SHOW DATABASE
property-name
command to show an instance-specific property in a RAC database.
Command Examples
Example 1
Shows database information in an abbreviated format.
DGMGRL> SHOW DATABASE 'DR_Sales'; Database Name: DR_Sales Role: PHYSICAL STANDBY Enabled: YES Intended State: ONLINE Instance(s): dr_sales1 Current status for "DR_Sales": SUCCESS
Example 2
Shows database information in an extended format.
DGMGRL> SHOW DATABASE VERBOSE 'North_Sales' Database Name: North_Sales Role: PRIMARY Enabled: YES Intended State: ONLINE Instance(s): sales1 Properties: InitialConnectIdentifier = 'North_Sales.foo.com' LogXptMode = 'ARCH' Dependency = '' DelayMins = '0' Binding = 'OPTIONAL' MaxFailure = '0' MaxConnections = '0' ReopenSecs = '30' NetTimeout = '180' LogShipping = 'ON' PreferredApplyInstance = '' ApplyInstanceTimeout = '0' ApplyParallel = 'AUTO' StandbyFileManagement = 'AUTO' ArchiveLagTarget = '0' LogArchiveMaxProcesses = '5' LogArchiveMinSucceedDest = '1' DbFileNameConvert = 'dbs/s2t, dbs/t' LogFileNameConvert = 'dbs/s2t, dbs/t' FastStartFailoverTarget = '' StatusReport = '(monitor)' InconsistentProperties = '(monitor)' InconsistentLogXptProps = '(monitor)' SendQEntries = '(monitor)' LogXptStatus = '(monitor)' RecvQEntries = '(monitor)' HostName = 'north.foo.com' SidName = 'sales1' LocalListenerAddress = '(ADDRESS=(PROTOCOL=TCP)(HOST=north.foo.com)(PORT=1514))' StandbyArchiveLocation = '/archfs/arch/' AlternateLocation = '' LogArchiveTrace = '255' LogArchiveFormat = 'r_%d_%t_%s_%r.arc' LatestLog = '(monitor)' TopWaitEvents = '(monitor)' Current status for "North_Sales": SUCCESS
Displays information or property value of the specified instance.
Format
SHOW INSTANCE [VERBOSE] instance-name [property-name]
[ON DATABASE database-name];
Command Parameters
The name of the instance for which you want to display information.
The name of the property for which you want to display a value.
The name of the database to which is associated the instance for which you want to show information.
Usage Notes
The SHOW INSTANCE
command shows a brief summary of the instance. SHOW INSTANCE VERBOSE
shows properties of the instance in addition to the brief summary. They both show the status of the instance.
The SHOW INSTANCE VERBOSE
command only shows instance-specific properties.
The properties that the SHOW INSTANCE VERBOSE
command shows depend on the database role and the configuration composition:
For instances of the primary database, properties specific to physical standby instances are shown only if there is at least one physical standby database in the configuration. The properties specific to logical standby instances are shown only if there is at least one logical standby database in the configuration.
For instances of physical standby databases, properties specific to logical standby instances are not shown.
For instances of logical standby databases, properties specific to physical standby instances are not shown.
The instance-name
can be unique across the configuration. If instance-name
is not unique, you must specify both the database-name
and the instance-name
to fully identify the instance.
Command Example
Example 1
The following example shows information about a specific instance of a database.
DGMGRL> SHOW INSTANCE sales1; Instance 'sales1' of database 'North_Sales' Host Name: north.foo.com Current status for "sales1": SUCCESS
Example 2
Shows instance information in an extended format.
DGMGRL> SHOW INSTANCE VERBOSE sales1; Instance 'sales1' of database 'North_Sales' Host Name: north.foo.com PFILE: Properties: HostName = 'north.foo.com' SidName = 'sales1' LocalListenerAddress = '(ADDRESS=(PROTOCOL=TCP)(HOST=north.foo.com)(PORT=1514))' StandbyArchiveLocation = '/archfs/arch' AlternateLocation = '' LogArchiveTrace = '255' LogArchiveFormat = 'r_%d_%t_%s_%r.arc' LsbyMaxSga = '0' LsbyMaxServers = '0' LatestLog = '(monitor)' TopWaitEvents = '(monitor)' Current status for "sales1": SUCCESS
Shuts down a currently running Oracle instance.
Format
SHUTDOWN [ ABORT | IMMEDIATE | NORMAL ];
Command Parameters
None.
Usage Notes
Using the SHUTDOWN
command with no arguments is equivalent to using the SHUTDOWN NORMAL
command.
The following list describes the options to the SHUTDOWN
command:
ABORT
Proceeds with the fastest possible shutdown of the database without waiting for calls to complete or for users to disconnect from the database. Uncommitted transactions are not rolled back. Client SQL statements being processed are terminated. All users connected to the database are implicitly disconnected, and the next database startup will require instance recovery. You must use this option if a background process terminates abnormally.
Caution:
If you use theABORT
option on the primary database when fast-start failover is enabled and the observer is running, a fast-start failover may ensue. Use the IMMEDIATE
or NORMAL
option to prevent an unexpected fast-start failover from occurring.IMMEDIATE
Does not wait for current calls to complete or users to disconnect from the database. Further connections are prohibited. The database is closed and dismounted. The instance is shut down, and no instance recovery is required on the next database startup.
NORMAL
This is the default option. The process waits for users to disconnect from the database. Further connections are prohibited. The database is closed and dismounted. The instance is shut down, and no instance recovery is required on the next database startup.
Command Example
Example 1
The following command shuts down the primary database in normal mode.
DGMGRL > SHUTDOWN; Database closed. Database dismounted. Oracle instance shut down.
Starts the fast-start failover observer.
Format
START OBSERVER [ FILE=observer_configuration_filename ];
Command Parameters
Specifies an explicit directory path and file name on the observer computer.
Usage Notes
The Oracle Client Administrator kit, or the full Oracle Database Enterprise Edition or Oracle Personal Edition kit must be installed on the observer computer to monitor a broker configuration for which fast-start failover is to be enabled. See Section 5.5.1 for more information.
The START OBSERVER
command must be issued on the observer computer. Once the observer is successfully started, control is not returned to the user until the observer is stopped (for example, by issuing the STOP OBSERVER command from a different client connection). If you want to perform further interaction with the broker configuration, you must connect through another client.
The observer runs autonomously once it has been successfully started. For this reason, it is recommended that when invoking DGMGRL for the purpose of issing the START OBSERVER
command, specify the -logfile
optional parameter on the command line so that output generated while acting as the observer is not lost. See Section 8.1.1 for more information about this parameter and see Section 10.5.3 for an example use of the -logfile
option.
If a directory path is not specified with the FILE
parameter, the observer searches the current working directory for the fsfo.dat
file. If an fsfo.dat
file is not found and this is the first time the START OBSERVER
command is issued, the observer creates a fsfo.dat
file.
The primary and target standby database DB_UNIQUE_NAME
initialization parameter and connect descriptors are stored in the fsfo.dat
configuration file. Oracle recommends you ensure this file is protected from unauthorized access.
Fast-start failover does not need to be enabled before you issue this command.
If fast-start failover is enabled, the observer will retrieve primary and target standby connect descriptors from the broker configuration and begin monitoring the configuration.
If fast-start failover is not enabled, the observer continually monitors for when fast-start failover is enabled.
Only the primary database needs to be running when you issue this command; the standby database that will be the target of a fast-start failover does not need to be running.
If the observer is stopped:
Because the STOP OBSERVER
command was issued, you can issue the START OBSERVER command on any computer to restart the observer.
For any reason other than because the STOP OBSERVER
command was issued, you must issue the START OBSERVER
command on the same observer computer where it was started originally.
If an observer is already running, the START OBSERVER
command fails and returns one of the following errors:
ORA-16647: could not start more than one observerDGM-16954: unable to open and lock the Observer configuration file.
If the primary and target standby databases stay connected but they lose the connection to the observer, then the primary database goes into an unobserved state. This state is reported by the broker's health check capability.
Use the SHOW CONFIGURATION VERBOSE
command, or query the FS_FAILOVER_*
columns in the V$DATABASE
view on the primary database to see the status of the observer and its host computer.
Command Examples
Example 1
The following example shows...
DGMGRL> CONNECT sys/password@North_Sales.foo.com; DGMGRL> START OBSERVER; Observer started
Example 2
The following example shows how to start the observer using CONNECT '/' so that connection credentials are not visible on the command line:
DGMGRL> CONNECT /@North_Sales.foo.com; DGMGRL> START OBSERVER; Observer started.
You must set up Oracle Wallet to use CONNECT '/'
. By setting up Oracle Wallet, you can write a script to securely start and run the observer as a background job without specifying database credentials in the script.
See Also:
Oracle Database Advanced Security Administrator's Guide for more information about Oracle WalletStarts an Oracle database instance with any of the following options:
FORCE
: shuts down the current Oracle instance in the SHUTDOWN
ABORT
mode before restarting it.
RESTRICT
: allows only Oracle users with the RESTRICTED SESSION
system privilege to connect to the instance.
PFILE
: specifies the PFILE
initialization parameter file to be used when the database instance is started.
MOUNT
: mounts the specified database without opening it. However, if the broker is enabled (DG_BROKER_START=TRUE
) and the specified database is a primary database or a logical standby database, the broker will attempt to open the database if the database profile indicates the database should be opened.
OPEN
: mounts and opens the specified database.
NOMOUNT
: starts the specified database instance without mounting the database.
Format
STARTUP
[FORCE]
[RESTRICT]
[PFILE=filename]
[MOUNT] | OPEN [open-options] | NOMOUNT];
Command Parameters
The name of the initialization parameter file to be used when starting the database instance. If you do not specify the PFILE
parameter option, then the default server parameter file (specific to your operating system) is used.
The mode of access in which you want the specified database to start. The possible modes are:
READ ONLY
READ WRITE
Usage Notes
Using the STARTUP
command with no arguments is equivalent to using the STARTUP OPEN
command.
If you do not use the FORCE
clause when you use the STARTUP
command and the current database instance is running, an error results. The FORCE
clause is useful when you are debugging or when error conditions are occurring. Otherwise, it should not be used.
Use the RESTRICT
clause to allow only Oracle users with the RESTRICTED SESSION
system privilege to connect to the instance. Later, you can use the ALTER SYSTEM
command through SQL*Plus to disable the restricted session feature.
If you do not use the PFILE
clause to specify the initialization parameter file, the STARTUP
command uses the default server parameter file, if it exists. Otherwise, the STARTUP
command uses the default initialization parameter file. The default files are platform specific.
See your operating system-specific documentation for more information about the default parameter files.
Use the OPEN
clause to mount and open the specified database.
The NOMOUNT
clause starts the database instance without mounting the database. You cannot use the NOMOUNT
clause with the MOUNT
or OPEN
options.
Command Examples
Example 1
The following examples show two different methods for starting a database instance. Each command starts a database instance using the standard parameter file, mounts the default database in exclusive mode, and opens the database.
DGMGRL> STARTUP; DGMGRL> STARTUP OPEN;
Example 2
The following command shuts down the current instance, immediately restarts it without mounting or opening the database, and allows only users with restricted session privileges to connect to it.
DGMGRL > STARTUP FORCE RESTRICT NOMOUNT;
Example 3
The following command starts an instance using the parameter file testparm
without mounting the database.
DGMGRL > STARTUP PFILE=testparm NOMOUNT;
Example 4
The following example starts and mounts a database instance, but does not open it.
DGMGRL> STARTUP MOUNT;
Note:
If the broker is enabled (DG_BROKER_START=TRUE
) and the specified database is a primary database or a logical standby database, the broker will attempt to open the database if the database profile indicates the database should be opened.Stops the fast-start failover observer.
Format
STOP OBSERVER;
Command Parameters
None.
Usage Notes
You can issue this command while connected to any database in the broker configuration.
This command does not disable fast-start failover.
Fast-start failover does not need to be enabled when you issue this command.
If fast-start failover is enabled when you issue the STOP OBSERVER
command, then the primary and standby databases must be connected and communicating with each other. Otherwise the following error is returned:
ORA-16636 Fast-Start Failover target standby in error state, cannot stop observer
If fast-start failover is not enabled when you issue the STOP OBSERVER
command, then only the primary database must be running when you stop the observer.
The observer does not stop immediately when the STOP OBSERVER
command is issued. The observer does not discover is has been stopped until the next time the observer contacts the broker.
As soon as you have issued the STOP OBSERVER
command, you may enter the START OBSERVER
command again on any computer. You can start a new observer right away, even if the old observer has not yet discovered it was stopped. Any attempt to restart the old observer will fail, because a new observer has been registered with the broker configuration.
Command Examples
Example 1
The following example stops the observer.
DGMGRL> STOP OBSERVER;
A switchover operation is a planned transition in which the primary database exchanges roles with one of the standby databases. When you issue the SWITCHOVER
command, the current primary database becomes a standby database, and the specified standby database becomes the primary database.
Format
SWITCHOVER TO database-name;
Command Parameter
The name of the standby database you want to change to the primary database role.
Usage Notes
If fast-start failover is enabled, you may switch over only to the target standby database and only when the observer is running.
The broker verifies that the primary and standby databases are in the following states before starting the switchover:
The primary database must be enabled and ONLINE
, with redo transport services started.
The standby database must be enabled and ONLINE
, with log apply services started.
The broker allows the switchover to proceed as long as there are no redo transport services errors for the standby database that you selected to participate in the switchover. However, errors occurring for any other standby database not involved in the switchover will not prevent the switchover from proceeding.
Switchover to a logical standby database is not allowed when the configuration is running in maximum protection mode.
If the broker configuration is in either MAXPROTECTION
or MAXAVAILABILITY
mode, the switchover maintains the protection mode even after the operation (described in Section 5.3.1). The switchover will not be allowed if the mode cannot be maintained because the target standby database of the switchover was the only standby that satisfied the protection mode requirement.
If the standby database that is assuming the primary role is a physical standby database, then both the primary and standby databases will be restarted after the switchover completes. If the standby database is a logical standby database, then neither the primary database nor the logical standby database is restarted.
If the standby database that is assuming the primary role is a physical standby database, then the original primary becomes a physical standby database. Otherwise, it becomes a logical standby database.
If the primary database is a RAC database, the broker will keep only one instance running and shut down all other instances before it continues the switchover. If the standby database you want to switch to the primary role is a RAC database, the broker will shut down all instances except the apply instance before it continues the switchover. See Section 5.3 for details.
If the standby database that is assuming the primary role is a logical standby database and there are physical standby databases in the configuration, after the switchover, the physical standby databases will be disabled until they are reenabled.
Caution:
For this reason, Oracle generally recommends that you specify your physical standby database for switchover instead of your logical standby database. If you must switch over to your logical standby database, see Section 5.4.3 to reenable your physical standby database.Command Examples
Example 1
The following example shows a successful switchover in which the standby database, DR_Sales
, transitions into the primary role.
DGMGRL> SWITCHOVER TO DR_Sales; Performing switchover NOW, please wait... Operation requires shutdown of instance "sales1" on database "North_Sales" Shutting down instance "sales1"... ORA-01109: database not open Database dismounted. ORACLE instance shut down. Operation requires shutdown of instance "dr_sales1" on database "DR_Sales" Shutting down instance "dr_sales1"... ORA-01109: database not open Database dismounted. ORACLE instance shut down. Operation requires startup of instance "sales1" on database "North_Sales" Starting instance "sales1"... ORACLE instance started. Database mounted. Operation requires startup of instance "dr_sales1" on database "DR_Sales" Starting instance "dr_sales1"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "DR_Sales"
Example 2
If you connect to the database using operating system authentication, you can use any username and password to connect. However, DGMGRL may not be able to shut down and start up the primary and standby database automatically because it cannot remotely authenticate itself.
The following example shows a switchover that succeeded but returns an error because DGMGRL cannot shut down and start up the primary and standby databases.
DGMGRL> CONNECT / Connected DGMGRL> SWITCHOVER TO "DR_Sales"; Performing switchover NOW, please wait... Operation requires shutdown of instance "sales1" on database "North_Sales" Shutting down instance "sales1"... ORA-01017: invalid username/password; logon denied You are no longer connected to ORACLE Please connect again. Unable to shut down instance "sales1" You must shut down instance "sales1" manually Operation requires shutdown of instance "dr_sales1" on database "DR_Sales" You must shut down instance "dr_sales1" manually. Operation requires startup of instance "sales1" on database "North_Sales" You must start instance "sales1" manually. Operation requires startup of instance "dr_sales1" on database "DR_Sales" You must start instance "dr_sales1" manually. Switchover succeeded, new primary is "DR_Sales"
Note:
For DGMGRL to restart instances automatically, you must connect to the database as SYSDBA using the username and password you specified in the remote password file before you begin the switchover. The username and password must be the same on the primary and standby databases.You must manually issue the SHUTDOWN and STARTUP commands to restart the new primary and standby database instances in this configuration.