| Oracle® Data Guard Broker 11g Release 1 (11.1) Part Number B28295-01 |
|
|
View PDF |
| Oracle® Data Guard Broker 11g Release 1 (11.1) Part Number B28295-01 |
|
|
View PDF |
This appendix describes 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 database startup behavior.
The Data Guard broker honors the startup option specified by the database administrator. This removes the current requirement that databases belonging in a Data Guard configuration only be mounted. Previously, a primary or a logical standby database would be opened even if the DBA had only mounted it, but this will no longer happen. This also means that Data Guard actions will not start taking place until the database is opened in the case of a primary or a logical standby database. The DBA must explicitly open the database.
Database States and descriptions have changed.
See Table A-3, "Database State Name Changes in Release 11.1"
The ADD DATABASE CONNECT IDENTIFIER IS clause is now optional if a pre-existing standby is being added to the configuration.
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 behavior for the DelayMins configurable database property
When the DelayMins property is set to 0, log apply services apply redo data to the standby database as soon as possible, including using real-time apply if the standby database is configured with standby redo logs.
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 the application of redo according to the time specified by the DelayMins property may be unexpectedly delayed.
The following sections list properties that have changed:
The following properties were changed in release 11.1:
Table A-1 Changed Properties in Release 11.1
| Property Name | Description of Change |
|---|---|
|
|
This property has been changed to When upgrading a 10g configuration to Oracle Database release 11.1, the |
|
|
This property has been changed to |
The following properties were changed in release 10.2:
Table A-2 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-3 shows the database state names that changed in Release 11.1:
Table A-3 Database State Name Changes in Release 11.1
| Database Type | State Name Prior to Oracle Database 11.1 | New State Name as of Oracle Database 11.1 |
|---|---|---|
|
Primary |
|
|
|
Primary |
|
|
|
Physical standby |
|
|
|
Physical standby |
|
|
|
Physical standby |
|
NoneFoot 1 |
|
Logical standby |
|
|
|
Logical standby |
|
|
|
All |
|
NoneFoot 2 |
Footnote 1 Prior to Release 11.1, the READ-ONLY state allowed a physical standby database to be opened read-only. In Release 11.1, this database state has been deprecated because a physical standby database can apply redo while opened read-only. Therefore this state change operation through the broker is no longer necessary.
Footnote 2 This database state has been deprecated. You can shut down a database using either the SQL*Plus SHUTDOWN command or the DGMGRL SHUTDOWN command.
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
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.
Deprecated database properties include:
LocalListenerAddress
The READ-ONLY state for physical standby databases has been deprecated
The OFFLINE and ONLINE states have been deprecated
The ADD DATABASE ... MAINTAINED AS {PHYSICAL|LOGICAL} statement is deprecated. Specifically, the MAINTAINED AS clause of ADD DATABASE command is deprecated. The broker now automatically finds out the standby database type.
This section contains information about Data Guard broker features that were deprecated or are obsolete.
Table A-5 Deprecated and Obsolete Properties in Release 10.2
| 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 |
