| Oracle Data Guard Concepts and Administration Release 2 (9.2) Part Number A96653-02 |
|
|
View PDF |
| Oracle Data Guard Concepts and Administration Release 2 (9.2) Part Number A96653-02 |
|
|
View PDF |
This chapter describes log transport services and how they control the transmission of redo data to standby databases. It includes the following topics:
Log transport services control the automated transfer of redo data within a Data Guard configuration.
Log transport services also control the level of data protection for your database. You can configure log transport services to balance data protection and availability against performance. In a Data Guard environment, log transport services coordinate with log apply services and role management services for switchover and failover operations.
Figure 5-1 shows a simple Data Guard configuration with redo logs being archived from a primary database to a local destination and to a remote standby database destination using log transport services.
Text description of the illustration logtrans.gif
The following concepts are important in understanding log transport services:Redo logs contain the data needed to recover a database. They are also used on a standby system to apply updates to the standby database.
Redo log destinations specify the location and types of redo logs along with the policies used to manage them.
Log transport services are responsible for the transmission and reception of redo data. This involves transmitting redo data throughout a Data Guard configuration and ensuring that data from the redo logs is committed to disk.
You can set archive destination attributes and log transport services options to enforce any of the three distinct modes of data protection.
In summary, log transport services transmit redo logs to various destinations where redo data is written to archived redo logs.
A Data Guard configuration always runs in one of three data protection modes: maximum protection, maximum availability, or maximum performance. Each of these protection modes provides a different balance of data protection, data availability, and primary database performance. To select the protection mode that best meets your business needs, you should carefully consider your data protection requirements and the performance expectations of your users.
Maximum protection mode offers the highest level of data protection. A primary database transaction will not commit until the redo data needed to recover that transaction is written to at least one physical standby database that meets the minimum requirements for this mode. If the primary database is unable to write the redo data to at least one such standby database, the primary database will shut down to prevent the generation of unprotected data. This protection mode guarantees no data loss, but it has the highest potential impact on the performance and availability of the primary database.
Maximum availability mode offers the next highest level of data protection. A primary database transaction will not commit until the redo data needed to recover that transaction is written to at least one standby database that meets the minimum requirements for this mode. Unlike maximum protection mode, the primary database will not shut down if it is unable to write the redo data to at least one such standby database. Instead, the protection mode will be temporarily lowered to maximum performance mode until the fault is corrected and the standby database catches up with the primary database. This mode guarantees no data loss unless the primary database fails while it is in maximum performance mode. This protection mode provides the highest level of data protection that is possible without affecting the availability of the primary database.
Maximum performance mode is the default protection mode. A primary database transaction will not wait to commit until the redo data needed to recover that transaction is written to a standby database. Therefore, some data might be lost if the primary database fails and the redo data needed to recover committed transactions is not available at any standby database. This mode provides the highest level of data protection that is possible without affecting the performance or availability of the primary database.
Each of these data protection modes requires that at least one standby database in the configuration use a specific set of log transport services attributes. The remainder of this chapter describes those attributes in detail. Once you understand these attributes, you can make the appropriate configuration changes needed to support the Data Guard protection mode that is right for your business.
See Section 5.7 for a description of the SQL statement that is used to set the data protection mode for a Data Guard configuration.
Data Guard automatically maintains the standby database by transmitting primary database redo data to the standby system and then applying the redo logs to the standby database. This section describes using the following types of redo logs in a Data Guard configuration:
The online redo logs are a set of two or more files that record all changes made to Oracle datafiles and control files. Whenever a change is made to the database, the Oracle database server writes the data and generates a redo record in the redo buffer. The logwriter process flushes the contents of the redo buffer into the online redo log.
The current online redo log is the one being written to by the logwriter process. When the logwriter process gets to the end of the file, it performs a log switch and begins writing to a new log file. If you run the database in ARCHIVELOG mode, then an archiver process copies the online redo log into an archived redo log.
A redo log group is a set of two or more redo logs that are multiplexed for redundancy. The logwriter process will write the same redo data to all redo logs in a group. If a write error occurs on one of the logs, then the redo data will still be available in the other redo logs in the group.
Both the size of the online redo logs and the frequency with which they switch affect the generation of archived redo logs at the primary site. In general, the most important factor in deciding what size to make an online redo log is the amount of application data that needs to be applied to a standby database during a database failover operation. The larger the online redo log, the more data needs to be applied to a standby database to make it consistent with the primary database.
The Oracle database server will attempt a checkpoint at each log switch. Therefore, if the online redo log size is too small, frequent log switches will lead to frequent checkpointing and negatively affects system performance on the standby database.
| See Also:
Oracle9i Database Administrator's Guide for more details about configuring online redo logs and online redo log groups |
An archived redo log is a copy of one of the filled members of an online redo log group made when the database is in ARCHIVELOG mode. After the LGWR process fills each online redo log with redo records, the archiver process copies the log to one or more archive log destinations.
By archiving filled online redo logs, older redo log data is preserved for operations such as media recovery, while the preallocated online redo logs continue to be reused to store the most current database changes. On a standby system, the archived redo logs are used to apply primary database changes to the standby database.
Permission for the archiving of online redo logs to remote destinations is specified using the REMOTE_ARCHIVE_ENABLE initialization parameter. This parameter provides TRUE, FALSE, SEND, and RECEIVE options. In most cases, you should set this parameter to TRUE on both the primary and standby databases in a Data Guard environment. To independently enable and disable the sending and receiving of remote archived redo logs, use the SEND and RECEIVE values.
For example, to ensure that the primary database never accidentally receives any archived redo logs, you can set the REMOTE_ARCHIVE_ENABLE initialization parameter to SEND on the primary database. Conversely, to ensure that the standby database never remotely archives the standby redo logs, you can set the REMOTE_ARCHIVE_ENABLE initialization parameter to RECEIVE on the standby database.
| See Also:
Chapter 7 for information about setting initialization parameters for role transition operations |
The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter specifies the minimum number of days that must pass before a reusable record in the control file can be reused. Setting this parameter prevents log transport services from overwriting a reusable record in the control file. (It applies only to records in the control file that are serially reusable.) This parameter helps to ensure that the archived redo log information remains available on the standby database. This is especially important when you have specified an apply delay for the standby database. The range of values for this parameter is 0 to 365 days. The default value is 7 days.
| See Also:
Oracle9i Database Reference for more details about the |
In some cases, you may want to create a time lag between the archiving of a redo log at the primary site and the applying of the redo log at the standby site. A time lag can protect against the application of corrupted or erroneous data from the primary site to the standby site.
Use the DELAY=minutes attribute of the LOG_ARCHIVE_DEST_n initialization parameter to specify a time lag for applying redo logs at the standby site. The DELAY interval is relative to when the archived redo log is complete at the destination. It does not delay the transport of the redo log to the standby database. The default setting for this attribute is NODELAY. If the DELAY attribute is set with no value specified, then the value for this attribute is 30 minutes.
See Also:
|
Standby redo logs are similar to online redo logs and are required for physical standby databases running in maximum protection mode and maximum availability mode. Redo data transmitted from the primary database is received by the remote file server process (RFS) on the standby system where the RFS process will write the redo data to either standby redo logs or to archived redo logs.
Standby redo logs form a separate pool of log file groups. During a failover operation, they enable Data Guard to apply more redo data than what is available in the archived redo logs alone. Because standby redo logs must be archived before the data can be applied to the standby database, the archiver process must be started on the standby database. Figure 5-2 shows a Data Guard configuration in which the RFS process receives redo data from the log writer process and writes it to standby redo logs. A log switch on the primary database triggers a log switch on the standby database that results in the archiver process archiving the standby redo logs to archived redo logs on the standby database.
Text description of the illustration redologs.gif
The size of a standby redo log must exactly match the primary database online redo logs. For example, if the primary database uses two online redo log groups whose log size is 100K and 200K, respectively, then the standby database should have standby redo log groups with those same sizes.
The minimum configuration should have one more standby redo log group than the primary database.
It might be necessary to create additional standby log groups on the physical standby database, so that the archival operation has time to complete before the standby redo log is reused by the RFS process. If the primary database is operating in maximum protection mode and a standby redo log cannot be allocated, the primary database instance might shut down immediately. If the primary database is operating in maximum protection mode or maximum availability mode, then the primary database might wait for the standby redo log to become available. Therefore, be sure to allocate an adequate number of standby redo logs.
During testing, the easiest way to determine if the current standby log configuration is satisfactory is to examine the contents of the RFS process trace file and the database alert log. If messages indicate that the RFS process frequently has to wait for a group because archiving did not complete, add more standby log groups.
When you use Real Application Clusters, the various standby redo logs are shared among the various primary database instances. Standby redo log groups are not dedicated to a particular primary database thread.
Consider the database parameters that can limit the number of standby redo log groups before setting up or altering the configuration of the standby redo log groups. The following parameters limit the number of standby redo log groups that you can add to a database:
MAXLOGFILES clause of the CREATE DATABASE statement for the primary database determines the maximum number of groups of standby redo logs per physical standby database. The only way to override this limit is to re-create the primary database or control file.LOG_FILES parameter can temporarily decrease the maximum number of groups of standby redo logs for the duration of the current instance.MAXLOGMEMBERS clause of the CREATE DATABASE statement used for the primary database determines the maximum number of members per group. The only way to override this limit is to re-create the primary database or control file.
Standby redo logs are created using the ADD STANDBY LOGFILE clause of the ALTER DATABASE statement.
To verify that standby redo logs were created, query the V$STANDBY_LOG view (displays standby redo log status as ACTIVE or INACTIVE) or the V$LOGFILE view. The following example queries the V$LOGFILE view:
SQL> SELECT * FROM V$LOGFILE WHERE TYPE = 'STANDBY';
Standby redo logs can be multiplexed to increase the availability of redo logs, similar to the way that online redo logs are multiplexed. Plan the standby redo log configuration of a database and create all required groups and members of groups after you instantiate the standby database. To create new standby redo log groups and members, you must have the ALTER DATABASE system privilege. A database can have as many groups as the value of the MAXLOGFILES clause that was specified on the SQL CREATE DATABASE statement.
To create a new group of standby redo logs, use the ALTER DATABASE statement with the ADD STANDBY LOGFILE clause.
The following statement adds a new group of standby redo logs to a physical standby database:
SQL> ALTER DATABASE ADD STANDBY LOGFILE 2> ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500K;
You can also specify a number that identifies the group using the GROUP option:
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 10 2> ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500K;
Using group numbers can make administering standby redo log groups easier. However, the group number must be between 1 and the value of the MAXLOGFILES initialization parameter. Do not skip redo log file group numbers (that is, do not number groups 10, 20, 30, and so on), or you will use additional space in the physical standby database control file.
The physical standby database begins using the newly created standby redo logs the next time there is a log switch on the primary database. To verify that the standby redo log groups are created and running correctly, invoke a log switch on the primary database, and then query the V$STANDBY_LOG view on the physical standby database.
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG; GROUP# THREAD# SEQUENCE# ARC STATUS ---------- ---------- ---------- --- ---------- 3 1 16 NO ACTIVE 4 0 0 YES UNASSIGNED 5 0 0 YES UNASSIGNED
In some cases, it might not be necessary to create a complete group of standby redo logs. A group could already exist, but not be complete because one or more members were dropped (for example, because of disk failure). In this case, you can add new members to an existing group.
To add new standby redo log group members, use the ALTER DATABASE statement with the ADD STANDBY LOGFILE MEMBER parameter. The following statement adds a new member to redo log group number 2:
SQL> ALTER DATABASE ADD STANDBY LOGFILE MEMBER '/disk1/oracle/dbs/log2b.rdo' 2> TO GROUP 2;
Use fully-qualified filenames of new log members to indicate where the file should be created. Otherwise, files will be created in either the default or current directory of the database server, depending upon your operating system.
Log transport services transmit redo data to up to 10 redo log destinations. You configure the primary database to perform archiving using the LOG_ARCHIVE_DEST_n (where n is an integer from 1 to 10) initialization parameter and corresponding LOG_ARCHIVE_DEST_STATE_n (where n is an integer from 1 to 10) initialization parameter. You can also use these initialization parameters to set up cascading standby databases, as described in Appendix D.
There are a several initialization parameters that are used to configure destinations. Some parameters, such as LOG_ARCHIVE_DEST_n might have several attributes that further refine the meaning of the parameter.
Archive destination attributes specify all aspects of destinations, not just the location. Particularly, they specify the following properties:
The parameters related to archive destinations follow:
LOG_ARCHIVE_DEST_n
Controls most of the behavior and properties of the destination; this parameter has many attributes. Refer to Chapter 12 for a full description of all of the LOG_ARCHIVE_DEST_n attributes.
LOG_ARCHIVE_DEST_STATE_n
Controls state of the destination. For each LOG_ARCHIVE_DEST_n parameter, there is a corresponding LOG_ARCHIVE_DEST_STATE_n parameter.
STANDBY_ARCHIVE_DEST
Determines the location of archived redo logs on the standby database.
LOG_ARCHIVE_FORMAT
Specifies the format for archived redo log filenames. STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT are concatenated to generate fully-qualified standby database archived redo log filenames.
LOG_ARCHIVE_MIN_SUCCEED_DEST
Defines the minimum number of local destinations that must receive redo logs successfully before the log writer process on the primary database can reuse the online redo logs.
REMOTE_ARCHIVE_ENABLE
Enables or disables the sending of redo logs to remote destinations and the receipt of remote redo logs
In addition to setting up the primary database to run in ARCHIVELOG mode, you must configure the primary database to archive redo logs by setting destinations and associated states. You do this using the LOG_ARCHIVE_DEST_n initialization parameter and corresponding LOG_ARCHIVE_DEST_STATE_n parameter.
The LOG_ARCHIVE_DEST_STATE_n (where n is an integer from 1 to 10) initialization parameter specifies the state of the corresponding destination indicated by the LOG_ARCHIVE_DEST_n initialization parameter (where n is the same integer). For example, the LOG_ARCHIVE_DEST_STATE_3 parameter specifies the state of the LOG_ARCHIVE_DEST_3 destination.
Table 5-1 describes the LOG_ARCHIVE_DEST_STATE_n parameter attributes.
To set up log transport services to archive redo logs to the standby database named payroll2 on a remote node, make the following modifications to the primary database initialization parameter file. These modifications will take effect after the next log switch. For example:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=payroll2'; SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
Use the STANDBY_ARCHIVE_DEST initialization parameter on the standby database to specify the directory in which to store the archived redo logs. Log transport services use this value in conjunction with the LOG_ARCHIVE_FORMAT parameter to generate the archived redo log filenames on the standby site.
Log transport services store the fully-qualified filenames in the standby control file. Log apply services use this information to perform recovery operations on the standby database. The following example shows how to set the LOG_ARCHIVE_FORMAT initialization parameter:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_FORMAT='log%d_%t_%s.arc';
Issue the following query on the primary database to display the list of archived redo logs that are on the standby system:
SQL> SELECT NAME FROM V$ARCHIVED_LOG; NAME -------------------------------------------------------------------------------- /arc_dest/log_1_771.arc /arc_dest/log_1_772.arc /arc_dest/log_1_773.arc /arc_dest/log_1_774.arc /arc_dest/log_1_775.arc
When standby redo logs are used, the LOG_ARCHIVE_DEST_n initialization parameter (where n is a value from 1 to 10) on the standby database specifies the directory in which to archive standby redo logs.
You can specify a policy for reuse of online redo logs using the attributes OPTIONAL or MANDATORY with the LOG_ARCHIVE_DEST_n parameter. Oracle Corporation recommends that you set remote destinations to OPTIONAL. (This is the default.) The archival operation of an optional destination can fail, and the online redo logs are overwritten. If the archival operation of a mandatory destination fails, online redo logs cannot be overwritten.
By default, one local destination is mandatory even if you designate all destinations to be optional.
Example 5-1 shows how to set a mandatory local archiving destination and enable that destination.
LOG_ARCHIVE_DEST_3 = 'LOCATION=/arc_dest MANDATORY'
Archiving redo logs to a remote database can be defined as being dependent upon the success or failure of an archival operation for another destination. This is known as a dependent destination.
Use the DEPENDENCY attribute of the LOG_ARCHIVE_DEST_n initialization parameter to define a dependent destination. This attribute indicates that this destination depends on the successful completion of archival operations for the parent destination.
Figure 5-3 shows a Data Guard configuration in which the primary database transports redo data to one archiving destination that acts as a shared destination for both a logical standby database and a physical standby database.
Text description of the illustration dependentdest.gif
Specifying a destination dependency can be useful in the following situations:
In these situations, although a physical archival operation is not required, the standby database needs to know the location of the archived redo logs. This allows the standby database to access the archived redo logs when they become available for application by log apply services. You must specify an archiving destination as being dependent on the success or failure of another (parent) destination.
Use the REOPEN and MAX_FAILURES attributes of the LOG_ARCHIVE_DEST_n initialization parameter to specify what actions are to be taken when archiving to a destination fails. These actions include:
Use the REOPEN attribute of the LOG_ARCHIVE_DEST_n parameter to determine if and when the archiver process or the log writer process attempts to archive redo logs again to a failed destination following an error.
Use the REOPEN=seconds attribute to specify the minimum number of seconds that must elapse following an error before the archiving process will try again to access a failed destination. The default value is 300 seconds. The value set for the REOPEN attribute applies to all errors, not just connection failures. You can turn off the option by specifying NOREOPEN, which will prevent the destination from being retried after a failure occurs.
You can use the REOPEN attribute, in conjunction with the MAX_FAILURE attribute, to limit the number of consecutive attempts that will be made to reestablish communication with a failed destination. Once the specified number of consecutive attempts is exceeded, the destination is treated as if the NOREOPEN attribute was specified.
The REOPEN attribute is required when you use the MAX_FAILURE attribute. Example 5-2 shows how to set a retry time of 5 seconds and limit retries to 3 times.
LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=60 MAX_FAILURE=3'
There are four types of remote destinations: physical standby databases, logical standby databases, archive log repositories, and cross-instance archival database environments. The more common destinations, physical and logical standby databases, are described in Chapter 1. The following list describes some additional destinations:
This type of destination allows off-site archiving of redo logs. An archive log repository is created by using a physical standby control file, starting the instance, and mounting the database. This database contains no datafiles and cannot be used for primary database recovery. This alternative is useful as a way of holding redo logs for a short period of time, perhaps a day, after which the logs can then be deleted. This avoids most of the storage and processing expense of another fully-configured standby database.
A cross-instance archival database environment is possible on both the primary and standby databases. Within a Real Application Clusters environment, each instance directs its archived redo logs to a single instance of the cluster. This instance, known as the recovery instance, is typically the instance where managed recovery is performed. The recovery instance typically has a tape drive available for RMAN backup and restoration support.
Log transport services automatically transmit and receive all redo logs in a Data Guard configuration. You can tailor the characteristics of transmission and reception to balance data protection levels against performance.
Archiving redo logs to a remote destination requires uninterrupted connectivity through Oracle Net. If the destination is a remote physical standby database, a physical standby database must be mounted or open in read-only mode to receive the archived redo logs. A logical standby database must be open.
You can specify the following with respect to log transport services:
To minimize data loss in the event of a primary database failure, you want to copy data from the primary database to the standby database as it is being generated. You can choose to have either the log writer process or the archiver process transmit redo logs to a destination.
To specify which process transmits redo data, use either the ARCH or LGWR attribute of the LOG_ARCHIVE_DEST_n initialization parameter.
| Attribute | Example | Default |
|---|---|---|
|
{ |
|
|
The LGWR and ARCH attributes are mutually exclusive. Therefore, you cannot specify both attributes for the same destination. However, you can specify either the LGWR or the ARCH attribute for individual destinations. This allows you to choose the log writer process to transmit redo data for some destinations, while the archiver process transmits redo data to other destinations.
Choosing the ARCH attribute indicates that an archiver process (ARCn) will archive the current redo logs to the associated destination when a redo log switch occurs on the primary database. This is the default setting.
Choosing the LGWR attribute indicates that the log writer process (LGWR) will transmit redo data to the associated destination as it is generated. As redo is generated for the primary database, it is also propagated to the standby system where the RFS process writes the redo to either a standby redo log or to a standby archived redo log.
The only way to ensure you do not have any data loss is to write redo data to the standby database before it is committed on the primary database. If you specify the SYNC attribute, all network I/O operations are performed synchronously, in conjunction with each write operation to the online redo log. The transaction is not committed on the primary database until the redo data necessary to recover that transaction is received by the destination.
When you use the log writer process to archive redo logs, you can specify synchronous (SYNC) or asynchronous (ASYNC) network transmission of redo logs to archiving destinations using the SYNC or ASYNC attributes. If you do not specify either the SYNC or ASYNC attribute, the default is the SYNC network transmission mode. Each of these transmission methods is described in the following list:
SYNC network transmission method
The SYNC attribute has the potential to affect primary database performance adversely, but provides the highest degree of data protection at the destination site. Synchronous transmission is required for no data loss environments.
ASYNC network transmission method
If you specify the ASYNC attribute, all network I/O operations are performed asynchronously, and control is returned to the executing application or user immediately. You can specify a block count to determine the size of the SGA network buffer to be used. Block counts from 0 to 20,480 are allowed. The attribute allows the optional suffix value K to represent 1,000 (the value 1K indicates 1,000 512-byte blocks). In general, for slower network connections, use larger block counts.
Use the [NO]AFFIRM attribute of the LOG_ARCHIVE_DEST_n initialization parameter to specify if log archiving disk write I/O operations are to be performed synchronously or asynchronously.
|
Note: The |
Log transport services transport redo data to the systems in a Data Guard configuration. The processes used to transport redo data include the following:
The log writer process collects transaction redo data on the primary database and updates the online redo logs. Furthermore, LGWR can transmit online redo data directly to standby systems.
The archiver process copies both online redo logs and standby redo logs to archive destinations. Archive destinations can be either local or remote. The archiver process runs on both primary and standby systems.
The remote file server runs on the standby system and receives redo data over the network from both LGWR and ARCn. The RFS process will write the redo data to either a standby redo log or to a standby archived redo log.
The fetch archive log process helps to resolve gaps in archived redo logs. If a physical standby database detects that it is missing a redo log, the local FAL client will fetch the log.
The following figures show how log transport services work in various configurations.
Figure 5-4 shows the simplest configuration with a single local destination. The log writer process writes redo data to online redo logs. When each online redo log is filled, a log switch occurs and the archiver process archives the filled online redo log to an archived redo log. The filled online redo log is now available for reuse.
Text description of the illustration basicarch.gif
Figure 5-5 shows a Data Guard configuration with a local destination and a standby destination. At log switch time, the archiver process archives to both the local destination and the standby destination. Note that the archiver process uses Oracle Net to send redo data over the network to the RFS process. The RFS process writes the redo data to archived redo logs on the standby database. This figure also shows that themanaged recovery process (MRP) or logical standby process (LSP) is used to apply the redo logs to the standby database.
| See Also:
Chapter 6 for MRP and LSP process information |
Text description of the illustration archarch.gif
Figure 5-6 shows a Data Guard configuration with a local destination and a standby destination. In this configuration, the archiver on the primary system is archiving only to the local destination. Notice that the logwriter process is sending redo data to the standby system at the same time it is writing the data to the online redo log. The RFS process writes the redo data to an online redo log on the standby database. A log switch on the primary database triggers a log switch on the standby database, which causes the archiver process on the standby database to archive the redo logs to archived redo logs on the standby database. This configuration is a prerequisite for the highest level of data protection. For physical standby databases, Oracle Corporation recommends that you use standby redo logs. Standby redo logs are not supported for logical standby databases.
Text description of the illustration lgwrarch.gif
Figure 5-7 shows a Data Guard configuration with a local destination and a remote logical standby destination. In this configuration, the archiver on the primary system is archiving only to the local destination. Notice that the logwriter process is sending redo data to the standby system at the same time it is writing the data to the online redo logs. The RFS process receives the redo data and writes it to archived redo logs on the standby database. A log switch on the primary database triggers a log switch on the standby database, which causes the archiver process on the standby database to archive the redo logs on the standby database.
Text description of the illustration archlogical.gif
Each of the Data Guard data protection modes requires that at least one standby database in the configuration meet the minimum set of requirements listed in Table 5-2.
The standby database that is used to satisfy the minimum requirements for a given mode must be enabled and ready to receive redo data from the primary database before you can switch to that mode.
Before changing the data protection mode of your configuration, review the descriptions of the three data protection modes. Carefully consider the level of data protection that your business requires, and the performance and availability impact of operating in the mode that provides that level of protection.
|
Note: Oracle Corporation recommends that a Data Guard configuration that is run in maximum protection mode contains at least two physical standby databases that meet the requirements listed in Table 5-2. That way, the primary database can continue processing if one of the physical standby databases cannot receive redo data from the primary database. |
After verifying that your Data Guard configuration meets the minimum requirements for the protection mode that you want to use, use the ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE statement to switch to that mode. The syntax for this statement is:
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}
| See Also:
Chapter 13 and Oracle9i SQL Reference for information about SQL statements |
The following sections describe how to control log transport services options using database initialization parameters.
Although most initialization parameters on the primary and standby databases will be identical, some initialization parameters such as the CONTROL_FILES and DB_FILE_NAME_CONVERT parameters must differ. Only change parameter values when it is required for the functionality of the standby database or for filename conversions.
| See Also:
Chapter 11 for a complete list of the initialization parameters that play a key role in the configuration of a standby database |
To set up log transport services, modify the database parameter initialization file before starting the database instance. When using a traditional text initialization parameter file, all parameters must be specified on one line.
|
Note: For the discussions in this section, examples are shown using a traditional text initialization parameter file so you can see the different ways you can specify parameters and changes. |
Example 5-3 shows how to specify a parameter with a single attribute on one line.
LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll'
Example 5-4 shows how to specify a parameter with multiple attributes on one line.
LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll LGWR'
For the majority of the log transport services initialization parameters, specifying a new value completely replaces any previously specified value.
At runtime, the LOG_ARCHIVE_DEST_n initialization parameter can be changed using ALTER SYSTEM SET statements. You can specify the attributes in one or more strings in one statement. Any changes you make using the ALTER SYSTEM SET statements with the SCOPE=MEMORY clause are not persistently changed.
Example 5-5 shows how to specify a parameter with a single attribute on one line.
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll';
For the majority of the log transport services initialization parameters, specifying a new value completely replaces any previously specified value.
Before performing a switchover or failover operation, you must configure certain initialization parameters on both the primary and standby databases so that your Data Guard configuration operates properly after a role transition.
During the creation process, you configured:
Now, you must set up the primary database to operate in the standby role and the standby database to operate in the primary role.
The following sections discuss only those initialization parameters that affect the log transport services and log apply services. The discussions do not mention any other parameters that you set during the creation of the primary and standby databases. Any parameter not mentioned in the following sections either must stay the same (such as the DATABASE_NAME parameter) or, if possible and necessary, can be modified to meet your requirements (such as the LOCK_NAME_SPACE or SHARED_POOL parameters).
On the primary database, you define initialization parameters that control log transport services while the database is in the primary role. There are additional parameters you need to add that control the receipt of the redo data and log apply services when the primary database is transitioned to the standby role.
Example 5-6 shows the primary role initialization parameters that you maintain on the primary database.
LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll/' LOG_ARCHIVE_DEST_2='SERVICE=sales1' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_FORMAT=%d_%t_%s.arc REMOTE_ARCHIVE_ENABLE=SEND
These parameters control how log transport services send redo data to the standby system and the archiving of redo data on the local file system. The last parameter, REMOTE_ARCHIVE_ENABLE=SEND, allows the primary database to send redo data to the standby database, but prevents the primary database from receiving redo data from another system.
Example 5-7 shows the additional standby role initialization parameters on the primary database. These parameters take effect when the primary database is transitioned to the standby role.
FAL_SERVER=sales1 FAL_CLIENT=sales DB_FILE_NAME_CONVERT=('/standby','/primary') LOG_FILE_NAME_CONVERT=('/standby','/primary') STANDBY_ARCHIVE_DEST=/disk1/oracle/oradata/payroll/ STANDBY_FILE_MANAGEMENT=AUTO
Specifying the initialization parameters shown in Example 5-7 sets up the primary database to resolve gaps and convert new data and log file path names from a new primary database and archives the incoming redo data when this database is in the standby role.
On the standby database, you define initialization parameters that control the receipt of the redo data and log apply services when the database is in the standby role. There are additional parameters you need to add that control the log transport services while the database is in the primary role.
Example 5-8 shows the standby role initialization parameters that you would maintain on the standby database.
FAL_SERVER=sales FAL_CLIENT=sales1 DB_FILE_NAME_CONVERT=("/primary","/standby") LOG_FILE_NAME_CONVERT=("/primary","/standby") STANDBY_ARCHIVE_DEST=/disk1/oracle/oradata/payroll/standby/arc LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll/standby/arc/' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_FORMAT=%d_%t_%s.arc STANDBY_FILE_MANAGEMENT=AUTO REMOTE_ARCHIVE_ENABLE=RECEIVE
These initialization parameters allow the standby database to:
The last parameter allows the standby database to receive redo data from a primary database, but it prevents the standby database from sending redo data.
Example 5-9 shows the additional primary role parameters to be added to the standby database that take effect when the standby database is transitioned to the primary role.
LOG_ARCHIVE_DEST_2='SERVICE=sales' LOG_ARCHIVE_DEST_STATE_2=ENABLE
These additional parameters control how log transport services send redo data to a new standby system.
With the initialization parameters on both the primary and standby databases set as described in Section 5.8.2.1 and Section 5.8.2.2, the only parameter that needs to change after a role transition is the REMOTE_ARCHIVE_ENABLE parameter. Change this parameter on both the original primary database and the standby database that assumes the primary role.
On the original primary database (the new standby) set this parameter to allow the receipt of the redo from the new primary database. For example:
SQL> ALTER SYSTEM SET REMOTE_ARCHIVE_ENABLE=RECEIVE SCOPE=MEMORY;
On the new primary database (the former standby) set this initialization parameter to allow the sending of redo to the standby database.
SQL> ALTER SYSTEM SET REMOTE_ARCHIVE_ENABLE=SEND SCOPE=MEMORY;
Setting the initialization parameter using the SCOPE=MEMORY clause ensures that the two databases will revert back to their original settings when the role transition is reversed, and the databases resume their original roles. If you expect that these databases will be restarted at some point without performing a role transition, replace the SCOPE=MEMORY with SCOPE=BOTH. In this event, this initialization parameter will have to be reset manually again after a new role transition.
The parameter values shown in the examples in Section 5.8.2.1 and Section 5.8.2.2 are suitable for both a physical and a logical standby configuration. If you plan to perform role transitions between a primary database and a logical standby database, then you must set the archiving destinations differently on the logical standby database and eventually on the primary database (for when it transitions to the logical standby database role).
When you create the logical standby database, you should specify different directories for the initialization parameters shown in Example 5-10.
STANDBY_ARCHIVE_DEST=/disk1/oracle/oradata/payroll/standby/incoming LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll/standby/arc/'
These parameters will continue to function correctly when the standby database assumes the primary role.
When the primary database assumes a logical standby role after a role transition, you must also configure the local archiving parameters to transmit the incoming redo data to a different location (as you did with the logical standby database).
STANDBY_ARCHIVE_DEST=/disk1/oracle/oradata/payroll/incoming LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll/arc/'
The parameter values shown in Example 5-11 ensure that the redo data stream coming from the primary database will be archived to a different location than where the archive logs generated by the database are located when it is in the logical standby role.
This section describes manual methods of monitoring redo log archival activity for the primary database.
| See Also:
Oracle9i Data Guard Broker and the Data Guard Manager online help for more information about the Oracle9i Data Guard Manager graphical user interface that automates many of the tasks involved in monitoring a Data Guard environment |
Enter the following query on the primary database to determine the current redo log sequence numbers:
SQL> SELECT THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$LOG; THREAD# SEQUENCE# ARC STATUS -------- --------- --- ------ 1 947 YES ACTIVE 1 948 NO CURRENT
Enter the following query at the primary database to determine the most recently archived redo log file:
SQL> SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG; MAX(SEQUENCE#) -------------- 947
Enter the following query at the primary database to determine the most recently archived redo log file to each of the archive destinations:
SQL> SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ# 2> FROM V$ARCHIVE_DEST_STATUS 3> WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE'; DESTINATION STATUS ARCHIVED_THREAD# ARCHIVED_SEQ# ------------------ ------ ---------------- ------------- /private1/prmy/lad VALID 1 947 standby1 VALID 1 947
The most recently archived redo log file should be the same for each archive destination listed. If it is not, a status other than VALID might identify an error encountered during the archival operation to that destination.
You can issue a query at the primary database to find out if a log was not sent to a particular site. Each archive destination has an ID number associated with it. You can query the DEST_ID column of the V$ARCHIVE_DEST fixed view on the primary database to identify archive destination IDs.
Assume the current local archive destination is 1, and one of the remote standby archive destination IDs is 2. To identify which logs were not received by this standby destination, issue the following query:
SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM 2> (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) 3> LOCAL WHERE 4> LOCAL.SEQUENCE# NOT IN 5> (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND 6> THREAD# = LOCAL.THREAD#); THREAD# SEQUENCE# --------- --------- 1 12 1 13 1 14
| See Also:
Appendix A, "Troubleshooting the Standby Database" to learn more about monitoring the archiving status of the primary database |
To see the progression of the archiving of redo logs to the standby site, set the LOG_ARCHIVE_TRACE parameter in the primary and standby initialization parameter files.
| See Also:
Section 6.7 for complete details and examples. |
|
 Copyright © 1998, 2002 Oracle Corporation. All Rights Reserved. |
|