This command cannot be executed if fast-start failover is enabled and database-name specifies the name of the target standby database. The following example shows how to remove a database from the Oracle Data Guard broker configuration. Removes a far sync instance from an Oracle Data Guard broker configuration. The name of the far sync instance to be removed from the broker configuration. A far sync instance that has its RedoRoutes property set cannot be removed.
The following example removes a far sync instance named dallas from the broker configuration. The name of the database or the far sync with which the instance-name is associated. The option of specifying a far sync is available only in Oracle Database 12 c Release 1 The broker automatically adds started instances to the broker configuration.
However, the broker does not automatically remove instances from the database. If the instance-name is not unique within the configuration, then you must specify both the database-name or far sync-name, and the instance-name to fully identify the instance. This command is rejected if this is the only instance currently associated with a database or far sync. Displa ys a summary and status of the broker configuration.
The summary lists all members included in the broker configuration and other information pertaining to the broker configuration itself, including the fast-start failover status. The health of the configuration and its members is evaluated once a minute. Specifying the VERBOSE keyword forces an immediate health evaluation of the configuration and its members before the health information is displayed.
The following example provides a summary of the DRSolution configuration for which fast-start failover is disabled. The output shows a far sync instance named FS in the broker configuration. The following example provides detailed information about the DRSolution configuration, including configuration properties, and fast-start failover-related information:. Displa ys the redo transport configuration that would be in effect if the specified database were the primary database.
This command is available in Oracle Database 12 c Release 1 The name of the database for which you want to see what the redo transport configuration would be if it were the primary database. You can use this information to identify ahead of time any redo transport configurations that would be incorrect after a role change. These displays are based upon the RedoRoutes property being set as follows for each member:. Displays information or property values of the specified database and its instances.
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. If a property name is specified, the output shows only the specified property not all properties of the database , regardless of whether or not the VERBOSE keyword is specified.
They both show the status of the database. For a non-Oracle RAC database, the values of the instance-specific properties are those of the only instance of the database.
For an Oracle RAC database, the values of the instance-specific properties will not be shown, although the property names are still listed. For the primary database, properties specific to physical or snapshot standby databases are shown only if there is at least one physical or snapshot 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 and snapshot standby databases, properties specific to logical standby databases are not shown. For logical standby databases, properties specific to physical and snapshot standby databases are not shown. Shows information about a far sync instance.
The name of the far sync instance for which the broker will show information. If a property name is specified, the output shows only the specified property not all properties of the far sync , regardless of whether or not the VERBOSE keyword is specified.
Displays information or property values for the specified instance. The name of the instance for which you want to display information. If a property name is specified, the output shows only the specified property not all properties , regardless of whether or not the VERBOSE keyword is specified.
The name of the database or far sync associated with the instance for which you want to show information. They both show the status of the instance. For instances of the primary database, properties specific to physical or snapshot standby instances are shown only if there is at least one physical or snapshot 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 or snapshot standby databases, properties specific to logical standby instances are not shown. For instances of logical standby databases, properties specific to physical and snapshot standby instances are not shown.
Shuts down a currently running Oracle instance. 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.
If you use the ABORT option on the primary database when fast-start failover is enabled and the observer is running, a fast-start failover may ensue. 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.
This is the default option. The process waits for users to disconnect from the database. For example, use the following syntax:. 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.
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. If a directory path is not specified with the FILE parameter, the observer searches the current working directory for the fsfo. If an fsfo. Oracle recommends you ensure this file is protected from unauthorized access. If fast-start failover is enabled, the observer will retrieve primary and target standby connect identifiers 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 in order for this command to complete successfully.
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. When using Oracle Wallet as a secure external password store, be sure to add credentials for both the primary and fast-start failover target standby databases.
The database connect string that you specify when adding the credentials for each database must match the ObserverConnectIdentifer or DGConnectIdentifier database property.
Starts an Oracle database instance with any of the following options:. 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.
Otherwise, it should not be used. The default files are platform specific. See your operating system-specific documentation for more information about the default parameter files. 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. 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.
The following command starts an instance using the parameter file testparm without mounting the database. This command does not disable fast-start failover, but a fast-start failover cannot be initiated in the absence of an observer. Otherwise the following error is returned:. Note that 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.
The observer does not discover it has been stopped until the next time the observer contacts the broker. 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 started for the broker configuration.
A switchover operation is a planned transition in which the primary database exchanges roles with one of the standby databases. If fast-start failover is enabled, you may switch over only to the fast-start failover target standby database. The broker verifies that the primary and standby databases are in the following states before starting the switchover:.
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 bystander standby database will not prevent the switchover from proceeding.
Switchover to a logical standby database is not allowed when the configuration is operating in maximum protection mode. If the broker configuration is operating in either maximum protection mode or maximum availability mode, the switchover maintains the protection mode even after the operation described in Before You Perform a Switchover Operation.
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 the old primary database will be restart ed 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.
If the standby database that is assuming the primary role is a logical standby database, then the original primary becomes a logical standby database. If an Oracle RAC primary database is becoming a physical standby database, all but one instance of the primary database will be shut down before performing the switchover.
See Switchover 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. 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 Reenabling Disabled Databases After a Role Change to re-create your physical standby database. If you intend to switch back to the original primary database relatively soon, you may allow the physical and snapshot standbys to remain disabled. Once you have completed the switchover back to the original primary, you may then reenable the physical and snapshot standby databases since they are still viable standbys for the original primary database.
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. Performs a comprehensive set of database checks prior to a role change. The checks use information available in various Oracle Data Guard views as well as the Automatic Diagnostic Repository.
Performs a comprehensive set of checks for a far sync instance. The checks use information available in various Oracle Data Guard views. The name of the far sync instance for which you want to display information.
The validation of the far sync instance is performed based on the specified database being the primary database. If you specify more than one option on the command, you can specify the options in any order.
Command Examples. Command Parameters database-name The name that will be used by the broker to refer to this standby database.
Usage Notes To issue this command, you must connect to the primary database or to an enabled standby database that is already in the configuration. What do I get with a subscription? With your subscription - you'll gain access to our exclusive IT community of thousands of IT pros. We can't always guarantee that the perfect solution to your specific problem will be waiting for you.
If you ask your own question - our Certified Experts will team up with you to help you get the answers you need. Who are the certified experts? How quickly will I get my solution?
We can't guarantee quick solutions - Experts Exchange isn't a help desk. I believe if we are sharing the knowledge is equal to we are gaining knowledge. Step 6: Now configure the broker service on the primary server. Step 7 : Now add the standby database in the above configuration.
Note: — help add command will show the syntax of how to add the standby database in the above configuration. Thank you for giving your valuable time to read the above information. Follow us on Website : www. Save my name, email, and website in this browser for the next time I comment. Follow Share this post.
Share via:. For example, when we tried to create a configuration for 19c data guard broker , we got ORA like this. There're several possibilities may cause the problem. But if it's the worst case, you should make room for your files so as to solve ORA For Linux, you can use df -h to check space usage. The directory owner had better to be oracle , so we changed the owner from root into oracle. As we can see, the directory cannot be written.
0コメント