| Oracle® Data Guard Concepts and Administration 10g Release 1 (10.1) Part Number B10823-01 |
|
|
View PDF |
| Oracle® Data Guard Concepts and Administration 10g Release 1 (10.1) Part Number B10823-01 |
|
|
View PDF |
This chapter provides syntax, values, and information on validity for the archival attributes of the LOG_ARCHIVE_DEST_n initialization parameter. The following list shows the attributes:
Each LOG_ARCHIVE_DEST_n destination you define must contain either a LOCATION or SERVICE attribute to specify a local disk directory or a remotely accessed database, respectively.
See Chapter 5 for information about defining LOG_ARCHIVE_DEST_n destinations to set up log transport services.
You can set and dynamically update most of the attribute values of the LOG_ARCHIVE_DEST_n and the LOG_ARCHIVE_DEST_STATE_n parameters using the ALTER SYSTEM SET and ALTER SESSION statements. Table 12-1 lists the attributes that can be changed using an ALTER SYSTEM or ALTER SESSION statement.
The modifications take effect after the next log switch on the primary database. For example, to defer log transport services from transmitting redo data to the remote standby database named boston, issue the following statements on the primary database:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=boston 2> VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'; SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;
When updating attribute values in this way, you can incrementally change one or more additional attributes without having to re-specify the entire parameter value. For example, the following statements set a REOPEN attribute for the LOG_ARCHIVE_DEST_2 destination, and set multiple attributes for the LOG_ARCHIVE_DEST_1 destination incrementally on separate lines:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='REOPEN=60'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='OPTIONAL';
Because specifying the LOCATION or SERVICE attribute causes the destination initialization parameter to be reset to its default values, note that the SERVICE or LOCATION attribute must be specified only on the first line. The statements are nonincremental because the LOG_ARCHIVE_DEST_1 destination is reset each time:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/ REOPEN=60'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/';
To clear a previously entered destination specification, enter a null value:
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/' LOG_ARCHIVE_DEST_1=''
Query the V$ARCHIVE_DEST view to see current settings of the LOG_ARCHIVE_DEST_n initialization parameter.
The AFFIRM and NOAFFIRM attributes control whether synchronous or asynchronous network I/O is used to write redo data to a remote standby redo log file or archived redo log file:
AFFIRM attribute is required to achieve no data loss.If neither the AFFIRM nor the NOAFFIRM attribute is specified, the default is NOAFFIRM.
The AFFIRM attribute indicates all disk I/O to archived redo log files and standby redo log files is to be performed synchronously, even when the redo data is transmitted to a remote standby database. The AFFIRM attribute can be specified with either the LOCATION or SERVICE attributes for archival operations to local or remote destinations.
This attribute has the potential to affect primary database performance, as follows:
LGWR and AFFIRM attributes, the log writer process synchronously writes the redo data to disk, control is not returned to the user until the disk I/O completes, and online redo log files on the primary database might not be reusable until archiving is complete.ARCH and AFFIRM attributes, ARCn processes synchronously write the redo data to disk, the archival operation might take longer, and online redo log files on the primary database might not be reusable until archiving is complete.ASYNC and AFFIRM attributes, performance is not affected.Query the AFFIRM column of the V$ARCHIVE_DEST fixed view to see whether or not the AFFIRM attribute is being used for the associated destination.
|
Note: When the primary database is in the maximum protection or maximum availability mode, destinations using the log writer process are automatically placed in |
See also the SYNC and ASYNC attributes.
The NOAFFIRM attribute indicates that all disk I/O to archived redo log files and standby redo log files is to be performed asynchronously; the LGWR process on the primary database does not wait until the disk I/O completes before continuing. The NOAFFIRM attribute can be specified with either the LOCATION attribute for local destinations and with the SERVICE attribute for remote destinations.
The following example shows the AFFIRM attribute for a remote destination.
LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR SYNC AFFIRM' LOG_ARCHIVE_DEST_STATE_3=ENABLE
These attributes control whether or not an alternate destination is used when the original archiving destination fails:
ALTERNATE--defines an alternate archiving destination.NOALTERNATE--prevents archiving to an alternate destination.If neither the ALTERNATE nor the NOALTERNATE attribute is specified, the default is NOALTERNATE. If the NOALTERNATE attribute is specified, or if no alternate destination is specified, the destination does not automatically change to another destination upon failure.
The ALTERNATE attribute specifies another LOG_ARCHIVE_DEST_n destination that will be used if archival operations to the original destination fails. An alternate destination can reference either a local or remote archiving destination. For example, the following parameter specifies that if the LOG_ARCHIVE_DEST_1 destination fails, archival operations will automatically switch to the LOG_ARCHIVE_DEST_2 destination.
LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY' LOG_ARCHIVE_DEST_STATE_2=ALTERNATE
You can specify only one alternate destination for each LOG_ARCHIVE_DEST_n parameter. An alternate destination is used when the transmission of redo data from the primary site to the standby site fails. If it fails and the REOPEN attribute is specified with a value of zero (0), or NOREOPEN is specified, archival operations will attempt to transmit redo data to the alternate destination the next time redo data is archived.
A destination can also be in the ALTERNATE state; this state is specified using the LOG_ARCHIVE_DEST_STATE_n initialization parameter. The ALTERNATE state defers processing of the destination until such time as another destination failure automatically enables this destination, if the alternate destination attributes are valid. See Section 5.2.2 for information about the LOG_ARCHIVE_DEST_STATE_n parameter.
Figure 12-1 shows a scenario where redo data is archived to a local disk device. If the original destination device becomes full or unavailable, the archival operation is automatically redirected to the alternate destination device.
Text description of the illustration archloc1.gif
The REOPEN attribute takes precedence over the ALTERNATE attribute. The alternate destination is used only if one of the following is true:
NOREOPEN attribute is specified.REOPEN attribute.REOPEN attribute and a nonzero MAX_FAILURE count were exceeded.The ALTERNATE attribute takes precedence over the MANDATORY attribute. This means that a destination fails over to a valid alternate destination even if the current destination is mandatory.
The following table shows the attribute precedences for standby destinations. In the left-most column, a 1 indicates highest precedence; 4 indicates lowest precedence.
| Precedence | Attribute |
|---|---|
|
1 |
|
|
2 |
|
|
3 |
|
|
4 |
|
The use of a standby database as the target of an alternate destination should be carefully handled. Ideally, a standby alternate destination should only be used to specify a different network route to the same standby database system.
If no enabled destination references the alternate destination, the alternate destination is implied to be deferred, because there is no automatic method of enabling the alternate destination.
An alternate destination can be manually enabled at runtime. Conversely, an alternate destination can be manually deferred at runtime. See Oracle Database Administrator's Guide for more information about changing initialization parameter settings using SQL at runtime.
There is no general pool of alternate standby destinations. Ideally, for any enabled destination, the database administrator should choose an alternate destination that closely mirrors that of the referencing destination, although that is not required.
Each enabled destination can have its own alternate destination. Conversely, several enabled destinations can share the same alternate destination. This is known as an overlapping set of destinations. Enabling the alternate destination determines the set to which the destination belongs.
Increasing the number of enabled destinations decreases the number of available alternate archiving destinations.
Any destination can be designated as an alternate given the following restrictions:
LOG_ARCHIVE_MIN_SUCCEED_DEST parameter value.Destinations defined using the SQL ALTER SESSION statement do not activate an alternate destination defined at the system level. Conversely, system-defined destinations do not activate an alternate destination defined at the session level.
If the REOPEN attribute is specified with a nonzero value, the ALTERNATE attribute is ignored. If the MAX_FAILURE attribute is also specified with a nonzero value, and the failure count exceeds the specified failure threshold, the ALTERNATE destination is enabled. Therefore, the ALTERNATE attribute does not conflict with a nonzero REOPEN attribute value.
Use the NOALTERNATE attribute of the LOG_ARCHIVE_DEST_n parameter to prevent the original destination from automatically changing to an alternate destination when the original destination fails.
In the sample initialization parameter file in Example 12-1, LOG_ARCHIVE_DEST_1 automatically fails over to LOG_ARCHIVE_DEST_2 on the next archival operation if an error occurs or the device becomes full.
LOG_ARCHIVE_DEST_1= 'LOCATION=/disk1 MANDATORY NOREOPEN ALTERNATE=LOG_ARCHIVE_DEST_2' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY' LOG_ARCHIVE_DEST_STATE_2=ALTERNATE
The sample initialization parameter file in Example 12-2 shows how to define an alternate Oracle Net service name to the same standby database.
LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2='SERVICE=stby1_path1 NOREOPEN OPTIONAL ALTERNATE=LOG_ARCHIVE_DEST_3' LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_3='SERVICE=stby1_path2 NOREOPEN OPTIONAL' LOG_ARCHIVE_DEST_STATE_3=ALTERNATE
The optional ARCH and LGWR attributes specify the process that will perform archival operations:
ARCH--the archiver processes (ARCn) are responsible for transmitting redo data to archival destinations.LGWR--the log writer process (LGWR) is responsible for transmitting redo data to archival destinations.By default, archiving is performed by ARCn processes; you must explicitly specify the LGWR attribute for log transport services to use the LGWR process. Although you cannot specify both LGWR and ARCn processes for the same destination, you can choose to use the log writer process for some destinations, while archiver processes transmit redo data for other destinations.
If you change a destination's current archival process (for example, from the ARCn process to the LGWR process), archival processing does not change until the next log switch occurs.
If neither the ARCH or LGWR attribute is specified, the default is ARCH.
See the LOCATION and SERVICE attributes for information about controlling the transmission of redo data to local and remote standby destinations.
The ARCH attribute indicates that archiver processes (ARCn) will transmit the current redo data to the associated destination when a redo log switch occurs on the primary database. As redo data is transmitted to the standby system, the RFS process writes the redo data to the archived redo log file and to the standby redo log file, if implemented. The ARCH attribute is the default setting.
When the ARCH attribute is specified for the destination, log transport services only perform synchronous network transmission. An error message is returned if you specify the ARCH and ASYNC attributes together.
The LGWR attribute indicates that redo data is transmitted to the standby destination by the background LGWR process at the same time as it writes to the online redo log file on the primary database. As redo data is generated for the primary database, it is also propagated to the standby system where the RFS process writes the redo data to either a standby redo log file or an archived redo log file.
However, when you specify either the LGWR and ASYNC attributes or the LGWR and SYNC=PARALLEL attributes, the LGWR process uses a Network Server (LNS) process that transmits the redo data to the standby destination on behalf of the LGWR process. See Section 5.3.2 for more information.
When transmitting redo data to remote destinations, the LGWR process establishes a network connection to the destination instance. Because the redo data is transmitted concurrently, the redo data is not retransmitted to the corresponding destination during the archival operation. If a destination running in maximum availability or maximum performance mode fails, the destination automatically reverts to using the ARCn process until the problem is corrected.
The following example shows the LGWR attribute with the LOG_ARCHIVE_DEST_n parameter. Section 5.3 provides more examples using these attributes.
LOG_ARCHIVE_DEST_3='SERVICE=denver LGWR' LOG_ARCHIVE_DEST_STATE_3=ENABLE
The DB_UNIQUE_NAME attribute specifies the database unique name for this destination. The DB_UNIQUE_NAME attribute must match the value that was defined originally for this database with the DB_UNIQUE_NAME initialization parameter.
There is no default value for this attribute.
The DB_UNIQUE_NAME=name attribute must match the DB_UNIQUE_NAME initialization parameter of the database identified by the destination. If the LOG_ARCHIVE_CONFIG=DG_CONFIG parameter is not specified, the DB_UNIQUE_NAME attribute is optional. If the LOG_ARCHIVE_CONFIG=DG_CONFIG parameter is specified, the DB_UNIQUE_NAME attribute:
SERVICE attribute) and must match one of the DB_UNIQUE_NAME values in the DG_CONFIG list. Furthermore, log transport services validates that the DB_UNIQUE_NAME of the database at the specified destination matches the DB_UNIQUE_NAME attribute or the connection to that destination is refused.LOCATION attribute). However, when you specify a local destination, the name you specify with the DB_UNIQUE_NAME attribute must match the name specified for the database's DB_UNIQUE_NAME initialization parameter.If you specify the NODB_UNIQUE_NAME attribute and the LOG_ARCHIVE_CONFIG parameter is not defined, this will reset the database unique name for the destination. That is, the NODB_UNIQUE_NAME attribute clears any value that you previously specified with the DB_UNIQUE_NAME attribute. The NODB_UNIQUE_NAME attribute is not valid if the LOG_ARCHIVE_CONFIG parameter is defined.
The following example is a portion of a text initialization parameter file showing how to specify the DB_UNIQUE_NAME attribute on the LOG_ARCHIVE_DEST_n parameter. The definitions for the DB_UNIQUE_NAME and the LOG_ARCHIVE_CONFIG initialization parameters are provided to add clarity.
In the example, the DB_UNIQUE_NAME for this database is boston (DB_UNIQUE_NAME=boston), which is also specified with the DB_UNIQUE_NAME attribute on the LOG_ARCHIVE_DEST_1 parameter. The DB_UNIQUE_NAME attribute on the LOG_ARCHIVE_DEST_2 parameter specifies the chicago destination. Both boston and chicago are listed in the LOG_ARCHIVE_CONFIG=DG_CONFIG parameter.
DB_UNIQUE_NAME=boston LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)' LOG_ARCHIVE_DEST_1='LOCATION=/arch1/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_ NAME=boston' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2='SERVICE=Sales_DR VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_ NAME=chicago' LOG_ARCHIVE_DEST_STATE_2=ENABLE . . .
When log apply services are enabled on a physical standby database, redo data is written to archived redo log files or standby redo log files and then applied (except when real-time apply is enabled which allows Data Guard to recover redo data from the current standby redo log file as it is being filled up). However, a DELAY attribute, which specifies a time lag between archiving redo data on the standby site and applying the archived redo log file to the standby database, may be used to protect the standby database from corrupted or erroneous primary data.
|
Note: You can set this attribute only for physical standby databases. To delay the application of archived redo log files on a logical standby databases, use the |
If neither the DELAY nor the NODELAY attribute is specified, the default is NODELAY.
Use the DELAY attribute of the LOG_ARCHIVE_DEST_n initialization parameter to specify a time lag for the application of archived redo log files to the physical standby database. The DELAY attribute does not affect the transmittal of redo data to the physical standby destination. If you have real-time apply enabled, any delay that you set will be ignored.
|
Note: Changes to the |
The DELAY attribute indicates the archived redo log files at the standby destination are not available for recovery until the specified time interval has expired. The time interval is expressed in minutes, and it starts when the redo data is successfully transmitted to and archived at the standby site.
You can use the DELAY attribute to set up a configuration where multiple standby databases are maintained in varying degrees of synchronization with the primary database. For example, assume primary database A supports standby databases B, C, and D. Standby database B is set up as the disaster recovery database and therefore has no time lag. Standby database C is set up to protect against logical or physical corruption, and is maintained with a 2-hour delay. Standby database D is maintained with a 4-hour delay and protects against further corruption.
You can override the specified delay interval at the standby site. To immediately apply an archived redo log file to the standby database before the time interval expires, use the NODELAY keyword of the RECOVER MANAGED STANDBY DATABASE clause. For example:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
When you specify the NODELAY attribute and Redo Apply is enabled on the physical standby database, archived redo log files are applied when a log switch occurs on the primary database.
See Oracle Database SQL Reference for information about the DELAY attribute on the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE statement.
The following example shows the DELAY attribute with the LOG_ARCHIVE_DEST_n parameter.
LOG_ARCHIVE_DEST_3='SERVICE=stby1 DELAY=240' LOG_ARCHIVE_DEST_STATE_3=ENABLE
The DEPENDENCY attribute transmits redo data to a destination that then shares its archived redo log files among multiple standby databases.
DEPENDENCY--defines one archival destination to receive redo data on behalf of several destinations.NODEPENDENCY--specifies there is no dependency on the success or failure of an archival operation to another destination.The transmission of redo data to the remote destination makes the child destinations dependent upon the success or failure of an archival operation to the parent destination.
If neither the DEPENDENCY nor the NODEPENDENCY attribute is specified, the default is NODEPENDENCY.
Specify the DEPENDENCY attribute to define a local destination, a physical standby database, or a logical standby database. Specifying a destination dependency can be useful in the following configurations:
In these situations, although a physical archival operation does not occur for the dependent destination, the standby database needs to know the location of the archived redo log files. This allows the standby database to access the archived redo log files when they become available.
Consider the case of a two-node cluster where a primary node shares access to the destination with the standby node through a mirrored disk device. This configuration, where you maintain a local standby database, is useful for off-loading ad hoc queries and reporting functions.
The primary database archives an online redo log file locally and, upon successful completion, the archived redo log file is immediately available to the standby database for Redo Apply by a physical standby database. This does not require a physical remote archival operation for the standby destination. In this case, two destinations are used: one for local archiving and another for archiving at the standby site. The standby destination is not valid unless the primary destination succeeds. Therefore, the standby destination has a dependency upon the success or failure of the local destination.
The DEPENDENCY attribute has the following restrictions:
DEPENDENCY attribute cannot be modified at the session level.REGISTER attribute is required.SERVICE attribute is required.When one or more destinations are dependent upon the same parent destination, all attributes of the dependent destinations still apply to that destination. It appears as if the archival operation was performed for each destination, when only one archival operation actually occurred.
Consider, for example, that two standby databases are dependent upon the same parent destination. You can specify different DELAY attributes for each destination, which enables you to maintain a staggered time lag between the primary database and each standby database.
Similarly, a dependent destination can specify an alternate destination, which itself might or might not be dependent on the same parent destination.
Specifies there is no dependency on the success or failure of an archival operation to another destination.
One reason to use the DEPENDENCY attribute is if the standby database is on the same site as the primary database. Using this configuration, you only need to archive the redo data once and, because the standby database resides on the local system, it can access the same archived redo log files. The following is an example of the LOG_ARCHIVE_DEST_n parameters in this scenario:
# Set up the mandatory local destination: # LOG_ARCHIVE_DEST_1='LOCATION=/oracle/dbs/ MANDATORY' LOG_ARCHIVE_DEST_STATE_1=ENABLE # # Set up the dependent standby database that resides on the local system: # LOG_ARCHIVE_DEST_2='SERVICE=dest2 DEPENDENCY=LOG_ARCHIVE_DEST_1 OPTIONAL' LOG_ARCHIVE_DEST_STATE_2=ENABLE
Another reason to use the DEPENDENCY attribute is if two standby databases reside on the same system. The parent and child standby databases can be any mix of physical and logical standby databases. The following is an example of this scenario:
# Set up the mandatory local destination: # LOG_ARCHIVE_DEST_1='LOCATION=/oracle/dbs/ MANDATORY' LOG_ARCHIVE_DEST_STATE_1=ENABLE # # Set up the remote standby database that will receive the redo data: # LOG_ARCHIVE_DEST_2='SERVICE=dest2 OPTIONAL' LOG_ARCHIVE_DEST_STATE_2=ENABLE # # Set up the remote standby database that resides on the same system as, and is # dependent on, the first standby database: # LOG_ARCHIVE_DEST_3='SERVICE=dest3 DEPENDENCY=LOG_ARCHIVE_DEST_2 OPTIONAL' LOG_ARCHIVE_DEST_STATE_3=ENABLE
Each destination must specify either the LOCATION or the SERVICE attribute to identify either a local disk directory or a remote database destination where log transport services can transmit redo data. For each Data Guard configuration, you must specify at least one local disk directory with the LOCATION attribute. This ensures the local archived redo log files are accessible should media recovery of the primary database be necessary. You can specify up to nine additional local or remote destinations. Specifying remote destinations with the SERVICE attribute ensures Data Guard can maintain a transactionally consistent remote copy of the primary database for disaster recovery.
Either the LOCATION or the SERVICE attribute must be specified. There is no default. The LOCATION attribute conflicts with QUOTA_SIZE and QUOTA_USED only when the USE_DB_RECOVERY_FILE_DEST value is specified on the LOCATION attribute.
|
Note: If you are specifying multiple attributes, specify the |
To verify the current settings for LOCATION and SERVICE, query the V$ARCHIVE_DEST fixed view:
TARGET column of the V$ARCHIVE_DEST fixed view identifies if the destination is local or remote to the primary database.DESTINATION column of the V$ARCHIVE_DEST fixed view identifies the values that were specified for a destination. For example, the destination parameter value specifies the Oracle Net service name identifying the remote Oracle instance where the archived redo log files are located.When you specify a LOCATION attribute, you can specify one of the following:
LOCATION=local_disk_directory
This specifies a valid path name for a disk directory on the system that hosts the database. Each destination that specifies the LOCATION attribute must identify a unique directory path name. This is the local destination for archived redo log files.
Local destinations indicate that the archived redo log files are to reside within the file system that is accessible to the local database. Local archived redo log files remain physically within the primary database namespace. The destination parameter value specifies the local file system directory path where the log files are copied.
LOCATION=USE_DB_RECOVERY_FILE_DEST
To configure a flash recovery area, you specify the directory, file system, or Oracle Storage Manager disk group that will serve as the flash recovery area using the DB_RECOVERY_FILE_DEST initialization parameter. If no local destinations are defined, Data Guard implicitly uses the LOG_ARCHIVE_DEST_10 destination as the default disk location for the flash recovery area and for storing the archived redo log files. See Section 5.2.3 for more information about flash recovery areas.
You identify remote destinations by specifying the SERVICE attribute with a valid Oracle Net service name (SERVICE=net_service_name) that identifies the remote Oracle database instance to which the redo data will be sent.
Transmitting redo data to a remote destination requires a network connection and an Oracle database instance associated with the remote destination to receive the incoming redo data.
The Oracle Net service name that you specify with the SERVICE attribute is translated into a connection descriptor that contains the information necessary for connecting to the remote database.
See Oracle Net Services Administrator's Guide for details about setting up Oracle Net service names.
The following example shows the LOCATION attribute with the LOG_ARCHIVE_DEST_n parameter:
LOG_ARCHIVE_DEST_2='LOCATION=/disk1/oracle/oradata/payroll/arch/' LOG_ARCHIVE_DEST_STATE_2=ENABLE
The following example shows the SERVICE attribute with the LOG_ARCHIVE_DEST_n parameter:
LOG_ARCHIVE_DEST_3='SERVICE=stby1' LOG_ARCHIVE_DEST_STATE_3=ENABLE
You can specify a policy for reusing online redo log files using the OPTIONAL or MANDATORY attributes. If a destination is optional, archiving to that destination may fail, yet the online redo log file is available for reuse and may be overwritten eventually. If the archival operation of a mandatory destination fails, online redo log files cannot be overwritten.
If neither the MANDATORY nor the OPTIONAL attribute is specified, the default is OPTIONAL. At least one destination must succeed even if all destinations are designated to be optional.
The LOG_ARCHIVE_MIN_SUCCEED_DEST=n parameter (where n is an integer from 1 to 10) specifies the number of destinations that must archive successfully before the log writer process can overwrite the online redo log files. All mandatory destinations and non-standby optional destinations contribute to satisfying the LOG_ARCHIVE_MIN_SUCCEED_DEST=ncount. For example, you can set the parameter as follows:
# Database must archive to at least two locations before # overwriting the online redo log files. LOG_ARCHIVE_MIN_SUCCEED_DEST = 2
When determining how to set your parameters, note that:
OPTIONAL or MANDATORY.
At least one local destination is operationally treated as mandatory, because the minimum value for the LOG_ARCHIVE_MIN_SUCCEED_DEST parameter is 1.
LOG_ARCHIVE_MIN_SUCCEED_DEST parameter irrelevant.LOG_ARCHIVE_MIN_SUCCEED_DEST parameter value cannot be greater than the number of destinations, nor greater than the number of mandatory destinations plus the number of optional local destinations.The BINDING column of the V$ARCHIVE_DEST fixed view specifies how failure affects the archival operation.
Specifies that the transmission of redo data to the destination must succeed before the local online redo log file can be made available for reuse.
Specifies that successful transmission of redo data to the destination is not required before the online redo log file can be made available for reuse. If the value set for the LOG_ARCHIVE_MIN_SUCCEED_DEST parameter (that defines the minimum number of destinations that must receive redo data successfully before the log writer process on the primary database can reuse the online redo log file) is met, the online redo log file is marked for reuse.
The following example shows the MANDATORY attribute:
LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest MANDATORY' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_3='SERVICE=denver MANDATORY' LOG_ARCHIVE_DEST_STATE_3=ENABLE
These attributes control the number of times log transport services will attempt to reestablish communication to a failed destination.
MAX_FAILURE--the maximum number of reopen attempts before the primary database permanently gives up on the standby database.NOMAX_FAILURE--allows an unlimited number of consecutive attempts to transport archive redo log files to the failed destination.If neither the MAX_FAILURE nor the NOMAX_FAILURE attribute is specified, the default is NOMAX_FAILURE.
The MAX_FAILURE attribute specifies the maximum number of consecutive times log transport services attempt to transmit redo data to a failed destination. It limits the number of times log transport services attempt to reestablish communication and resume sending redo data to a failed destination. When you specify the MAX_FAILURE attribute, you must also set the REOPEN 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.
Using this attribute, you can provide failure resolution for destinations to which you want to retry transmitting redo data after a failure, but not retry indefinitely. When you specify the MAX_FAILURE attribute, you must also set the REOPEN attribute to specify how often archiving is retried to the particular destination.
If you set both the MAX_FAILURE and REOPEN attributes to nonzero values, log transport services limits the number of archival attempts to the number of times specified by the MAX_FAILURE attribute. Each destination contains an internal failure counter that tracks the number of consecutive archival failures that have occurred. You can view the failure count in the FAILURE_COUNT column of the V$ARCHIVE_DEST fixed view. The related column REOPEN_SECS identifies the REOPEN attribute value.
If an archival operation fails for any reason, the failure count is incremented until:
MAX_FAILURE attribute.
ALTER SYSTEM SET statement to dynamically change the MAX_FAILURE attribute (or any other destination attribute). The failure count is reset to zero (0) whenever the destination is modified by an ALTER SYSTEM SET statement. This avoids the problem of setting the MAX_FAILURE attribute to a value less than the current failure count value.
Once the failure count is greater than or equal to the value set for the MAX_FAILURE attribute, the REOPEN attribute value is implicitly set to the value zero (0), which causes log transport services to transport redo data to an alternate destination (defined with the ALTERNATE attribute) on the next archival operation.
Log transport services attempt to archive to the failed destination indefinitely if you do not specify the MAX_FAILURE attribute (or if you specify MAX_FAILURE=0 or the NOMAX_FAILURE attribute), and you specify a nonzero value for the REOPEN attribute. If the destination has the MANDATORY attribute, the online redo log file is not reusable in the event of a repeated failure.
Specify the NOMAX_FAILURE attribute to allow an unlimited number of archival attempts to the failed destination.
The NOMAX_FAILURE attribute is equivalent to specifying MAX_FAILURE=0.
The following example allows log transport services up to three consecutive archival attempts, tried every 5 seconds, to the arc_dest destination. If the archival operation fails after the third attempt, the destination is treated as if the NOREOPEN attribute was specified.
LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3' LOG_ARCHIVE_DEST_STATE_1=ENABLE
The NET_TIMEOUT and NONET_TIMEOUT attributes determine how long the log writer process waits before terminating the network connection:
NET_TIMEOUT--specifies the number of seconds the log writer process on the primary system waits for status from the network server (LNSn) process before terminating the network connection.NONET_TIMEOUT -- reverses or undoes the timeout value that was previously specified with the NET_TIMEOUT attribute.If you do not specify the NET_TIMEOUT attribute (or if you specify the NONET_TIMEOUT attribute), the primary database can potentially stall. To avoid this situation, specify a small, nonzero value for the NET_TIMEOUT attribute so the primary database can continue operation after the user-specified timeout interval expires when waiting for status from the network server.
If neither the NET_TIMEOUT nor the NONET_TIMEOUT attribute is specified, the default is NONET_TIMEOUT.
| 1 Although a minimum value of 1 second is allowed, Oracle recommends 8 to 10 seconds as a minimum to avoid false errors and disconnection from the standby database. |
The NET_TIMEOUT attribute is used only when the log writer process transmits redo data using a network server (LNSn) process and when either the ASYNC or the SYNC=PARALLEL attribute is specified.
The log writer process waits for the specified amount of time to receive status about the network I/O. If there is a possible network disconnection, even one that was terminated due to a network timeout, the log writer process automatically tries to reconnect to the standby database to resolve network brownouts and false network terminations. Typically, except when the network is physically broken, the log writer process can successfully reconnect to the network. The reconnection attempts continue for a period of time that depends on the following factors:
NET_TIMEOUT attribute on the primary database.EXPIRE_TIME parameter or keep alive intervals on the standby databases.
Even though the network connection might be terminated on the primary database, the network connection remains active on the standby database until the corresponding TCP/IP network timers expire. For this reason, you need to coordinate the setting for the NET_TIMEOUT attribute on the primary database with the setting of the Oracle Net EXPIRE_TIME parameter on each standby database.
For example, a primary database operating in the maximum availability protection mode with a NET_TIMEOUT attribute value set to 60 seconds and an EXPIRE_TIME of 1 minute could actually take a minimum of 1 minute to connect or up to 3 minutes to terminate the connection to the standby database.
Without careful coordination of the timeout parameter values on the primary and standby systems, it is possible that the primary system might detect a network problem and disconnect, while the standby database might not recognize the network disconnection if its default network timeout values are too high. If the network timers are not set up properly, subsequent attempts by the log writer process on the primary database to attach to the standby database will fail because the standby database has not yet timed out and the broken network connection still appears to be valid. See Oracle Net Services Administrator's Guide.
The NONET_TIMEOUT attribute implies the log writer process waits for the default network timeout interval established for the system. The default network timeout interval differs from system to system.
The following example shows how to specify a 40-second network timeout value on the primary database with the NET_TIMEOUT attribute.
LOG_ARCHIVE_DEST_2='SERVICE=stby1 LGWR NET_TIMEOUT=40 SYNC=PARALLEL' LOG_ARCHIVE_DEST_STATE_2=ENABLE
The QUOTA_SIZE and the NOQUOTA_SIZE attributes of the LOG_ARCHIVE_DEST_n parameter indicate the maximum number of 512-byte blocks of physical storage on a disk device that can be used by a local destination.
If neither the QUOTA_SIZE nor the NOQUOTA_SIZE attribute is specified, the default is NOQUOTA_SIZE. The LOCATION attribute conflicts with QUOTA_SIZE and QUOTA_USED only when the USE_DB_RECOVERY_FILE_DEST value is specified on the LOCATION attribute.
The QUOTA_SIZE attribute indicates the maximum number of 512-byte blocks of physical storage on a disk device that might be used by a local destination. The value is specified in 512-byte blocks even if the physical device uses a different block size. The optional suffix values K, M, and G represent thousand, million, and billion, respectively (the value 1K means 1,000 512-byte blocks).
A local archiving destination can be designated as being able to occupy all or some portion of the physical disk. For example, in a Real Application Clusters environment, a physical archived redo log file's disk device might be shared by two or more separate nodes (through a clustered file system, such as is available with Sun Clusters). As there is no cross-instance initialization parameter knowledge, none of the Real Application Clusters nodes is aware that the archived redo log file's physical disk device is shared with other instances. This can lead to significant problems when the destination disk device becomes full; the error is not detected until every instance tries to archive to the already full device. This affects database availability.
For example, consider an 8-gigabyte (GB) disk device /dev/arc_dest that is further subdivided into node-specific directories: node_a, node_b, and node_c. The DBA could designate that each of these instances is allowed to use a maximum of 2 GB, which would allow an additional 2 GB for other purposes. This scenario is shown in Figure 12-2.
Text description of the illustration quotasiz.gif
No instance uses more than its allotted quota.
The quota is common to all users of the destination, including foreground archival operations, archiver processes, and even the log writer process.
Oracle highly recommends that the ALTERNATE attribute be used in conjunction with the QUOTA_SIZE attribute. However, this is not required.
See also the ALTERNATE and NOALTERNATE attributes.
Use of the NOQUOTA_SIZE attribute, or the QUOTA_SIZE attribute with a value of zero (0), indicates that there is unlimited use of the disk device by this destination; this is the default behavior.
The following example shows the QUOTA_SIZE attribute with the LOG_ARCHIVE_DEST_n parameter.
LOG_ARCHIVE_DEST_4='QUOTA_SIZE=100K'
The QUOTA_USED and the NOQUOTA_USED attributes of the LOG_ARCHIVE_DEST_n parameter identify the number of 512-byte blocks of data that were archived on a specified destination.
If neither the QUOTA_USED nor the NOQUOTA_USED attribute is specified, the default is NOQUOTA_USED. The QUOTA_USED attribute has a default value of zero (0) for remote archival destinations. The LOCATION attribute conflicts with QUOTA_SIZE and QUOTA_USED only when the USE_DB_RECOVERY_FILE_DEST value is specified on the LOCATION attribute.
The QUOTA_USED attribute identifies the number of 512-byte blocks of data that were archived on the specified local destination. The value is specified in 512-byte blocks even if the physical device uses a different block size. The optional suffix values K, M, and G represent thousand, million, and billion, respectively (the value 1K means 1,000 512-byte blocks).
This attribute cannot be modified at the session level.
If you specify a QUOTA_SIZE attribute value greater than zero (0) for a destination, but do not specify a QUOTA_USED attribute value in the database initialization parameter file, the QUOTA_USED attribute value is automatically determined when the database is initially mounted. The QUOTA_USED attribute value defaults to the actual number of blocks residing on the local archiving destination device. If the calculated QUOTA_USED attribute value exceeds the QUOTA_SIZE attribute value, the QUOTA_SIZE attribute value is automatically adjusted to reflect the actual storage used. This automatic calculation of the QUOTA_USED value applies only to local archiving destinations.
If, at runtime, you dynamically modify the QUOTA_SIZE attribute value, but not the QUOTA_USED attribute value, the QUOTA_USED attribute value is not automatically recalculated.
For local destinations, the QUOTA_USED attribute value is incremented at the start of an archival operation. If the resulting value is greater than the QUOTA_SIZE attribute value, the destination status is changed to FULL, and the destination is rejected before the archival operation begins.
The QUOTA_SIZE and QUOTA_USED attributes are very important because they can be used together to detect a lack of disk space before the archival operation begins. Consider the case where the QUOTA_SIZE attribute value is 100K and the QUOTA_USED attribute value is 100K also. The destination status is VALID at this point. However, an attempt to archive 1 block results in the QUOTA_USED attribute value being changed to 101K, which exceeds the QUOTA_SIZE attribute value. Therefore, the destination status is changed to FULL, and the destination is rejected before the archival operation begins.
Specifies that an unlimited number of blocks of data can be archived on a specified destination.
Data Guard automatically sets this value. You do not need to change the value of the QUOTA_USED and the NOQUOTA_USED attributes.
The REGISTER and the NOREGISTER attributes of the LOG_ARCHIVE_DEST_n parameter indicate if the location of the archived redo log file is to be recorded at the destination site.
If neither the REGISTER nor the NOREGISTER attribute is specified, the default is REGISTER.
The REGISTER attribute indicates that the location of the archived redo log file is to be recorded at the corresponding destination.
For a physical standby destination, the name of the archived redo log file is recorded in the destination database control file, which is then used by Redo Apply.
For a logical standby database, the name of the archived redo log file is recorded in the tablespace maintained by the logical standby database control file, which is then used by SQL Apply.
The REGISTER attribute implies that the destination is a Data Guard standby database.
By default, the location of the archived redo log file, at a remote destination, is derived from the destination's STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT initialization parameters.
|
Note: You can also set the |
The optional NOREGISTER attribute indicates the location of the archived redo log file is not to be recorded at the corresponding destination. This setting pertains to remote destinations only. The location of each archived redo log file is always recorded in the primary database control file.
The NOREGISTER attribute is required if the destination is a standby database that is not part of a Data Guard configuration. (For example, the primary database automatically transmits redo data to a standby database only if the standby database is implemented in a Data Guard environment. If a standby database is not established as a part of a Data Guard configuration, you must manually transfer log files using some other means, such as with an operating system copy utility.)
The following example shows the REGISTER attribute with the LOG_ARCHIVE_DEST_n parameter.
LOG_ARCHIVE_DEST_5='REGISTER'
The REOPEN and the NOREOPEN attributes of the LOG_ARCHIVE_DEST_n parameter specify the minimum number of seconds before the archiver processes (ARCn) or the log writer process (LGWR) should try again to access a previously failed destination. You can turn off the attribute by specifying NOREOPEN.
If neither the REOPEN nor the NOREOPEN attribute is specified, the default is REOPEN.
REOPEN applies to all errors, not just connection failures. These errors include, but are not limited to, network failures, disk errors, and quota exceptions.
If you specify REOPEN for an OPTIONAL destination, it is still possible for the Oracle database to overwrite online redo log files even if there is an error. If you specify REOPEN for a MANDATORY destination, log transport services stall the primary database when it is not possible to successfully transmit redo data. When this situation occurs, consider the following options:
SERVICE attribute value.When you use the REOPEN attribute, note that:
REOPEN attribute, the archiving process checks if the time of the recorded error plus the REOPEN interval is less than the current time. If it is, the archival operation to that destination is retried.MAX_FAILURE=count attribute of the LOG_ARCHIVE_DEST_n initialization parameter.If you specify NOREOPEN, the failed destination remains disabled until:
ALTER SYSTEM SET or an ALTER SESSION SET statement with the REOPEN attribute.The following example shows the REOPEN attribute with the
LOG_ARCHIVE_DEST_n parameter.
LOG_ARCHIVE_DEST_3='SERVICE=stby1 MANDATORY REOPEN=60' LOG_ARCHIVE_DEST_STATE_3=ENABLE
The SYNC and the ASYNC attributes of the LOG_ARCHIVE_DEST_n parameter specify that network I/O is to be done synchronously or asynchronously when using the log writer process (LGWR).
When you specify the LGWR attribute, but you do not specify either the SYNC or ASYNC attribute, the default is SYNC=PARALLEL. When the ARCH attribute is specified for the destination, only the SYNC attribute is valid; an error message is returned if you specify the ARCH and ASYNC attributes together.
The SYNC attribute specifies that network I/O is to be performed synchronously for the destination, which means that once the I/O is initiated, the LGWR process waits for the I/O to complete before continuing. The SYNC attribute is one requirement for setting up a no-data-loss environment, because it ensures the redo records are successfully transmitted to the standby site before continuing.
If the LGWR process is defined to be the transmitter to multiple standby destinations that use the SYNC attribute, the user has the option of specifying SYNC=PARALLEL or SYNC=NOPARALLEL for each of those destinations.
SYNC=NOPARALLEL is used, the LGWR process initiates an I/O to the first destination and waits until it completes before initiating the I/O to the next destination. Specifying SYNC=NOPARALLEL is the same as specifying ASYNC=0.SYNC=PARALLEL is used, the LGWR process submits the network I/O request to the LNSn process for that destination and waits for an acknowledgment from the LNSn process. The LNSn process does not write the redo data to a buffer, but immediately transmits it to the standby database, and responds to the waiting LGWR process with status information about the network I/O.
Specifying SYNC=PARALLEL is useful when you have more than one destination defined with the SYNC attribute. This is because the LGWR process uses a separate LNSn process for each destination. Thus, the LGWR issues I/O requests to the LNSn process that initiates the network I/O to multiple destinations in parallel. Once the I/O is initiated, the LNSn processes wait for all I/O requests to complete before continuing, and the LGWR waits for an acknowledgment from all of the LNSn processes. This is, in effect, the same as performing multiple, synchronous I/O requests simultaneously. When you have more than one destination defined with the LGWR and SYNC attributes, the use of SYNC=PARALLEL is likely to perform better than SYNC=NOPARALLEL. See Figure 5-6 for an illustration of the LNSn process in a Data Guard configuration.
Because the PARALLEL and NOPARALLEL qualifiers only make a difference if multiple destinations are involved, Oracle recommends that all destinations use the same value.
The ASYNC attribute specifies that network I/O is to be performed asynchronously for the destination. You can optionally specify a block count (from 0 to 102,400) that determines the size of the SGA network buffer to be used. The actual allowable maximum value may be lower, depending on your operating system. Data Guard dynamically adjusts the value down to an appropriate number of blocks, if necessary.
With asynchronous processing, the LGWR process submits the network I/O request to the LNSn process for that destination and then LGWR continues processing the next request without waiting for the I/O to complete and without checking the completion status of the I/O. Use of the ASYNC attribute allows standby environments to be maintained with little or no performance effect on the primary database.
If the LNSn process is slow (for example, due to a slow network), it will result in the LGWR process filling up the ASYNC buffer to its specified capacity, causing an error during asynchronous archival operations. When this happens, the ARCn process will eventually transmit the redo data based on the current values of the REOPEN and MAX_FAILURE attributes for the destination. See Figure 5-6 for an illustration of the LNSn process in a Data Guard configuration.
When you use the ASYNC attribute, there are several events that cause the network I/O to be initiated:
The following example shows the SYNC attribute with the LOG_ARCHIVE_DEST_n parameter.
LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR SYNC' LOG_ARCHIVE_DEST_STATE_3=ENABLE
The TEMPLATE and the NOTEMPLATE attributes of the LOG_ARCHIVE_DEST_n parameter define a directory specification and format template for names of the archived redo log files or standby redo log files at the standby destination. You can specify these attributes in either the primary or standby initialization parameter file, but the attribute applies only to the database role that is archiving.
The TEMPLATE attribute overrides the STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT initialization parameter settings at the remote archive destination.
The TEMPLATE and NOTEMPLATE attributes are valid only with remote destinations (that is, destinations that are specified with the SERVICE attribute).
|
Note: If used on a destination that also specifies the |
There is no default value for this attribute.
Use the optional TEMPLATE attribute to define a directory specification and format for archive redo log filenames or standby redo log filenames at the standby destination. The definition is used to generate a filename that is different from the default filename format defined by the STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT initialization parameters at the standby destination.
The filename_template value of the TEMPLATE attribute must contain the %s, %t, and %r directives that are described in Table 12-2.
The filename_template value is transmitted to the standby destination, where it is translated and validated before creating the filename.
If you do not specify the TEMPLATE attribute, the setting is the same as REGISTER.
Use the optional NOTEMPLATE attribute to cancel a previously specified TEMPLATE attribute and allow the filename format template defined by the STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT initialization parameters take effect.
In the following example, prmy1 transmits redo data to the remote destination, stby1. The TEMPLATE attribute indicates that stby1 is located in the directory /usr/oracle/prmy1 with the p1_thread#_sequence#_resetlogs.dbf filename format.
LOG_ARCHIVE_DEST_1='SERVICE=boston MANDATORY REOPEN=5 TEMPLATE=/usr/oracle/prmy1/p1_%t_%s_%r.dbf' LOG_ARCHIVE_DEST_STATE_1=ENABLE
The VALID_FOR attribute of the LOG_ARCHIVE_DEST_n parameter identifies when log transport services can transmit redo data to destinations based on the following factors:
The default value for this attribute is VALID_FOR=(ALL_LOGFILES, ALL_ROLES).
| Category | VALID_FOR=(redo_log_type, database_role) |
|---|---|
|
Datatype of the attribute |
String value |
|
Minimum attribute value |
Not applicable |
|
Maximum attribute value |
Not applicable |
|
Default attribute value |
Note: Do not use the default value, |
|
Requires attributes ... |
Not applicable |
|
Conflicts with attributes ... |
Not applicable |
|
Attribute class |
|
|
Corresponding |
|
|
Related |
Not applicable |
To configure these factors for each LOG_ARCHIVE_DEST_n destination, you specify this attribute with a pair of keywords: VALID_FOR=(redo_log_type,database_role):
The following table shows the VALID_FOR attribute values and the roles in which each might be used.
If you do not specify the VALID_FOR attribute for a destination, by default, archiving online redo log files and standby redo log files is enabled at the destination, regardless of whether the database is running in the primary or the standby role. This default behavior is equivalent to setting the (ALL_LOGFILES,ALL_ROLES) keyword pair on the VALID_FOR attribute. For example:
LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll/arch/ VALID_FOR=(ALL_ LOGFILES,ALL_ROLES)
Although the (ALL_LOGFILES,ALL_ROLES) keyword pair is the default, it is not appropriate for every destination. For example, if the destination is a logical standby database, which is an open database that is creating its own redo data, the redo data being transmitted by log transport services could potentially overwrite the logical standby database's local online redo log files.
Therefore, it is recommended that you define a VALID_FOR attribute for each destination so that your Data Guard configuration operates properly, including after a role transition.
The VALID_FOR attribute enables you to set up initialization parameters for the primary and standby roles in the same initialization parameter file. Thus, it is not necessary to maintain separate initialization parameter files when anticipating role reversal in future switchovers or failovers.
The following example shows the default VALID_FOR keyword pair:
LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata VALID_FOR=(ALL LOGFILES, ALL_ROLES)'
When this database is running in either the primary or standby role, destination 1 archives all log files to the /disk1/oracle/oradata local directory location.
See the scenarios in Section 10.1 for detailed examples of various Data Guard configurations using the VALID_FOR attribute.
The VERIFY and NOVERIFY attributes indicate whether or not an archiver (ARCn) process should verify the correctness of the contents of a completed archived redo log file.
VERIFY--thoroughly scans and verifies the completed archived redo log files, either local or remote, for correctness.NOVERIFY--indicates that the archived redo log file contents will not be verified.If neither the VERIFY nor the NOVERIFY attribute is specified, the default is NOVERIFY.
Use the VERIFY attribute to scan and verify completed archived redo log files, either local or remote, for correctness after successfully completing the archival operation. The verification is significantly more thorough than the normal checksum verification that is always performed; the redo verification may take a substantial amount of time to complete. Consequently, archived redo log file verification is performed only when using archiver processes. The use of the VERIFY attribute may have an affect on primary database performance.
The default value is NOVERIFY, which means that the archived redo log file will not be verified. The NOVERIFY attribute indicates that normal checksum verification of the archived redo log file will still be performed, but verification of the redo contents will not be performed.
The LOG_ARCHIVE_DEST_n initialization parameter has many attributes. Some of these attributes conflict with each other. Some of the attributes require other attributes to be defined. Table 12-4 lists the supported attributes and the requirements associated with each one.
The LOCATION attribute conflicts with QUOTA_SIZE and QUOTA_USED attributes only when USE_DB_RECOVERY_FILE_DEST is specified on the LOCATION attribute.
|
 Copyright © 1999, 2003 Oracle Corporation All Rights Reserved. |
|