New Standby Database Parameters - Oracle

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:

• send Indicates that the database, when in primary database mode, can send redo logs to the standby database (default).

• nosend Opposite of send, the database cannot send redo logs to the standby.

• receive Indicates that when running in standby mode, the database can receive redo logs from the primary database (default).

• noreceive Opposite of receive, the database cannot receive redo logs from the primary database.

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:

LOG_ARCHIVE_CONFIG=('SEND,RECEIVE, DB_CONFIG=('MAIN_DB_DFW','STBY_NY','STBY_LAX')')

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:

• The ability to instantiate your logical standby database with zero downtime

• The ability of logical standby databases to support maximum protection mode

• New SQL Apply support for data types

• Optimized switchover operations on logical standby databases

• New data dictionary views to manage standby databases

• The ability to bypass the SQL Apply services to make changes to the logical standby database

• The ability to skip a failed transaction

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:

1. Take an online backup of the primary database (no quiesce is required; also note there is no need to record the SCN at the end of the backup).

2. After the backup is complete, create a logical standby database control file on the primary by using the alter database create standby logical control file command:
   
   Alter database Create standby logical control file AS '/tmp/control_logical.fil';
   
3. Copy the backed-up datafiles, archived redo logs, and the logical standby control file to the location where you will create the logical standby database.

4. Restore the database at the standby site with the logical standby control file. Do not open the database.

5. Configure log transport services on the primary and standby database sites so that redo can be shipped from the primary site to the standby sites as it’s generated.

6. Start managed recovery on the standby database with the alter database command:
   
   Alter database recover managed standby database;
   
   Note that this is the same method of recovering a physical standby database.
   
   
7. Activate the standby database with the alter database command:
   
   Alter database activate standby database;
   
8. Using the DBNEWID program, change the DBNAME and DBID of the standby database. Follow the instructions in the Oracle Database 10g Database Utilitiesguide on how to do this.

9. Start the logical standby database log application services:
   
   Alter database start logical standby apply;

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.