Oracle® Data Guard Broker 10g Release 2 (10.2) Part Number B14230-02 |
|
|
View PDF |
This appendix details the Data Guard broker features that were changed, deprecated or made obsolete. This appendix provides the following sections:
This section contains information about Data Guard broker features that were changed.
The following sections list features that have changed:
Changed failover behavior
After failover to a logical standby database, the broker disables all standby databases in the configuration that were not directly involved in the failover. The disabled databases must be reenabled before they can serve as standby to the new primary database. Previously, failover to a logical standby database resulted in the broker disabling only physical standby databases.
Changed DelayMins
property behavior
When the DelayMins
property is set to 0, log apply services apply redo data to the standby database as soon as it is received, including using real-time apply if the standby database is configured with standby redo logs.
If Flashback Database is enabled on the primary database, you can reinstate the old primary database after a failover, avoiding having to perform the manual steps required to reenable a database. In addition, when failing over to a physical standby database, other physical standby databases that were not directly involved in the failover can be reinstated (if they had Flashback Database enabled prior to the failover).
Additionally, if you specified the DelayMins
and RealTimeApply
properties on your release 10.1 database, the delay behavior might change unexpectedly. This is due to the RealTimeApply
property being deprecated in release 10.2
For example, if your release 10.1 database had the DelayMins
property set to a nonzero value and the RealTimeApply
property set to YES
, the delay setting was ignored because the real-time apply setting overrides any delay settings. However, because in release 10.2 the RealTimeApply
property is deprecated, the release 10.2 database will no longer be affected by the RealTimeApply
property and unexpectedly delay the application of redo according to the time specified by the DelayMins
property.
The concept of a graceful failover was renamed to complete failover while forced failover was renamed to immediate failover.
See Also:
Chapter 8 for information about the Oracle Database 10g Data Guard brokerFAILOVER
commandThe concept of a primary site was changed to a primary database and standby site was changed to standby database. The former site object of a broker configuration was eliminated for Oracle Data Guard.
The Enterprise Manager default behavior has been reversed when removing parts of a broker configuration. Enterprise Manager now clears the archive destination parameter upon removal of a database from the broker configuration, or clears all of the parameters upon removal of the entire configuration. Enterprise Manager still provides the option of preserving these values as was done by default in previous releases.
The following sections list properties that have changed:
The following properties were changed in release 10.2:
Table A-1 Changed Properties in Release 10.2
Property Name | Description of Change |
---|---|
|
The default value has changed from 120 seconds to 0 seconds. |
|
|
|
Using this property is the preferred method for delaying the application of redo data to a standby database. If you set
If you have more than one physical standby database in the configuration, Oracle recommends using Flashback Database after a failing over to a physical standby databases. You can use Flashback Database to reinstate any physical standby databases that were disabled but were not the target of the failover. |
|
Range of valid values is now from 1 to 30 (was from 1 to 10) |
|
Now imports the value of |
|
The default value has changed from 30 seconds to 180 seconds. |
Table A-2 shows properties that changed in release 10.1:
Table A-2 Changed Properties in Release 10.1
Property Name | Description of Change |
---|---|
|
|
|
|
|
|
|
New default values are:
|
|
|
|
|
|
|
|
|
See Also:
Chapter 9, "Database Properties"Table A-3 shows the state names that changed in Release 10.1:
Table A-3 State Name Changes
Database Type | State Name Prior to Oracle Database 10g | New State Name as of Oracle Database 10g |
---|---|---|
Primary |
|
|
Primary |
|
|
Physical standby |
|
|
Physical standby |
|
|
Logical standby |
|
|
Logical standby |
|
|
See Also:
Section 4.2, "Database States"Data Guard command-line interface (DGMGRL) commands that changed in Oracle Database 10g (10.2) include:
FAILOVER
EDIT CONFIGURATION
EDIT DATABASE
SHOW CONFIGURATION
When removing a standby database from the broker configuration, DGMGRL provides you with a choice about removing the standby destination from the primary database so that log files are no longer transported to that standby database. The default for this choice in Oracle Database 10g (starting in Release 10.1) is to remove that destination. This is a reversal of the default (and only) behavior as it was implemented in the Oracle9i DGMGRL command-line interface.
This section contains information about Enterprise Manager features that changed in release 10.1.
You cannot disable broker management of the broker configuration from within Enterprise Manager as had been allowed in previous releases. You can only do this from the command-line interface.
In this release of Oracle Database 10g, the Test Application feature will not be available.
View Log does not view alert or broker log files.
When removing a standby database from the broker configuration, Enterprise Manager presents you with a choice about removing the standby destination from the primary database so that log files are no longer transported to that standby database. The default for this choice in Oracle Database 10g is to remove that destination. This is a reversal of the default as it was implemented in Oracle9i Data Guard Manager.
The following sections list features that have been deprecated or made obsolete:
This section contains information about Data Guard broker features that were deprecated or are obsolete.
Table A-4 Deprecated Properties
Deprecated Property | Replacement Property (if any) |
---|---|
|
No replacement. |
|
Set the |
|
None. Specifying the number of blocks is no longer necessary. The transport mode is determined automatically by redo transport services, based on the protection mode defined for the Data Guard configuration. |
|
Set the |
This section contains information about Data Guard broker features that were deprecated or are obsolete.
The concept of a site object is obsolete.
The concept of a database resource object is obsolete.
Both of these objects were replaced by database objects.
Also, the following sections list properties, DGMGRL commands, and Enterprise Manager features deprecated or made obsolete in release 10.1
Table A-5 shows properties that were deprecated and if there is a replacement property.
Table A-5 Deprecated Properties
Deprecated Property | Replacement Property (if any) |
---|---|
|
No replacement |
|
|
|
|
See Also:
Chapter 9, "Database Properties" for information about the properties that replaced deprecated properties.Table A-6 shows DGMGRL commands or keywords that were deprecated or made obsolete, and indicates if there is a replacement command or keyword.
Note:
Existing Oracle9i command-line scripts are supported in Oracle Database 10g for non-RAC databases. Oracle recommends upgrading your scripts to replace deprecated commands and keywords with their Oracle Database 10g replacements.Table A-6 Deprecated Commands or Keywords
Deprecated Command or Keyword | Replacement Command or Keyword |
---|---|
|
|
|
No replacement |
|
|
|
|
|
|
|
No replacement |
|
|
|
No replacement |
|
|
|
No replacement |
|
|
|
No replacement |
|
|
|
|
|
|
|
No replacement |
|
No replacement |
|
|
|
No replacement |
|
|
See Also:
Chapter 8, "Data Guard Command-Line Interface Reference" for information about the commands that replaced deprecated commands.