Oracle Database 10g depreciates the lock_name_space parameter in favor of a new parameter, db_unique_name. Going forward, you should use the db_unique_name parameter to assign unique names to each of your standby databases. The name can be up to 30 characters long, and each Real Application Clusters instance should use the same name.
NOTE -- Deprecation of a parameter indicates that it is still available for use. If a parameter is obsolete, then it is no longer available for use in the database.
The remote_archive_enable parameter is replaced with the log_archive_config parameter (Oracle recommends replacing remote_archive_enable with log_ archive_config in Oracle Database 10g). The log_archive_config parameter allows you to define the standby database configuration currently in use, and update it dynamically. The db_unique_name parameter contains the name of each database in the standby database configuration, and then defines the role in the configuration as one of these four values:
The log_archive_config parameter should be the same for each Real Application Clusters instance. Also, the log_archive_config parameter has an attribute, db_config, that lists all databases in the standby database configuration. You can dynamically add databases to the configuration by changing this setting dynamically. This eliminates the need to shut down the database when running in maximum availability or maximum protection mode.
Here is an example of the configuration of the log_archive_config parameter, using the db_config parameter:
Changes to Standby Database Startups
Prior to Oracle Database 10g, you would first need to start the database instances (startup nomount) and then either mount it as a standby database and start managed recovery, or open the database in read-only mode.
In Oracle Database 10g, if you issue the startup mount command, Oracle Database 10g reads the database control file and, if the database is a standby database, mounts the database as a standby database in preparation for managed recovery to be started. You still need to start managed recovery. Also, if you have issued the startup command and the database is a standby database, it will open the standby database in read-only mode.
ARCH Process Writes to Standby Redo Logs
In Oracle Database 10g, the ARCH process now has the ability to write to standby redo logs. This helps with the registration of partially archived redo logs and allows for the configuration of an almost unlimited number of cascaded redo log destinations.
Assign Threads to Standby Redo Log Groups
Oracle Database 10g allows you to assign standby redo logs to specific redo threads if you are running a Real Application Clusters configuration. This is supported with the new thread parameter of the alter database add standby logfile command. The assignment of a thread is optional, however, and Oracle Database 10g will assign the standby redo log to a thread as required.
Logical Standby Database Enhancements
Oracle Database 10g offers a number of improvements in logical standby databases. These include the following:
Instantiate a Logical Standby Database with Zero Downtime
Prior to Oracle Database 10g, instantiation of a logical standby database would likely require an outage of the primary database, because the primary database would need to be quiesced, an operation that required that Resource Manager be enabled at database startup. Since many production databases operate without Resource Manager enabled, this would require a cycle of the database. Also, a quiesce of a database could take a long time, particularly in databases with a great deal of activity. Oracle Database 10g removes the requirement to quiesce the database before making the online backup that is the source of the logical standby database. This makes the creation of the logical standby database possible without any downtime at all. This change is supported by changes to the standby control file in Oracle Database 10g.
The following is a quick highlight of the steps needed to create a logical standby database, to demonstrate the changes in the procedure. I recommend that you look at the Oracle documentation (“Oracle Data Guard Concepts and Administration”) for more detail on this procedure (as it may change in interim releases of the database). The general steps are as follows:
Once these steps are complete, you have created an Oracle Database 10g logical standby database!
Logical Standby Database Support for Maximum Protection Mode
Previously, logical standby databases did not support maximum protection mode. This implied that there was always some level of data divergence between the primary and the logical standby database, which meant that there was a risk of data loss during an unplanned switchover operation.
Oracle Database 10g allows you to configure a logical standby database in maximum protection mode. You can now create standby redo logs for a logical standby database, which is required for maximum protection mode, and you can configure the primary database to send redo to the logical standby database in maximum protection mode.
blog comments powered by Disqus