DB_NAME

DB_NAME specifies a database identifier of up to 8 characters. This parameter must be specified and must correspond to the name specified in the CREATE DATABASE statement.

If you have multiple databases, the value of this parameter should match the Oracle instance identifier of each one to avoid confusion with other databases running on the system. The value of DB_NAME should be the same in both the standby and production initialization parameter files.

The database name specified in either the STARTUP command or the ALTER DATABASE ... MOUNT statement for each instance of the cluster database must correspond to the DB_NAME initialization parameter setting.

The following characters are valid in a database name: alphanumeric characters, underscore (_), number sign (#), and dollar sign ($). No other characters are valid. Oracle removes double quotation marks before processing the database name. Therefore you cannot use double quotation marks to embed other characters in the name. The database name is case insensitive.

DB_UNIQUE_NAME

DB_UNIQUE_NAME specifies a globally unique name for the database. Databases with the same DB_NAME within the same DB_DOMAIN (for example, copies of a database created for reporting or a physical standby) must have a unique DB_UNIQUE_NAME. Every database's DB_UNIQUE_NAME must be unique within the enterprise.

The value of DB_UNIQUE_NAME can be up to 30 characters and is case insensitive. The following characters are valid in a database name: alphanumeric characters, underscore (_), number sign (#), and dollar sign ($).

LOG_ARCHIVE_CONFIG

{
 [ SEND | NOSEND ]
 [ RECEIVE | NORECEIVE ]
 [ DG_CONFIG=(remote_db_unique_name1 [, ... remote_db_unique_name9) | NODG_CONFIG ]
 }

LOG_ARCHIVE_CONFIG enables or disables the sending of redo logs to remote destinations and the receipt of remote redo logs, and specifies the unique database names (DB_UNIQUE_NAME) for each database in the Data Guard configuration.

Values:

• SEND

  Enables the sending of redo logs to remote destinations

• NOSEND

  Disables the sending of redo logs to remote destinations

• RECEIVE

  Enables the receipt of remotely archived redo logs

• NORECEIVE

  Disables the receipt of remotely archived redo logs

• DG_CONFIG

  Specifies a list of up to 9 unique database names (defined with the DB_UNIQUE_NAME initialization parameter) for all of the databases in the Data Guard configuration.

• NODG_CONFIG

  Eliminates the list of service provider names previously specified with the DG_CONFIG option.

CONTROL_FILES

Every database has a control file, which contains entries that describe the structure of the database (such as its name, the timestamp of its creation, and the names and locations of its datafiles and redo files). CONTROL_FILES specifies one or more names of control files, separated by commas.

Oracle recommends that you multiplex multiple control files on different devices or mirror the file at the operating system level.

LOG_ARCHIVE_DEST_n

{ null_string |
 { LOCATION=path_name | SERVICE=service_name }
 [ { MANDATORY | OPTIONAL } ]
 [ REOPEN[=seconds] ]
 [ DELAY[=minutes] ]
 [ NOREGISTER ]
 [ TEMPLATE=template] ]
 [ ALTERNATE=destination ]
 [ DEPENDENCY=destination ]
 [ MAX_FAILURE=count ]
 [ ARCH | LGWR ]
 [ SYNC | ASYNC ]
 [ AFFIRM | NOAFFIRM ]
 [ NET_TIMEOUT=seconds ]
 [ VALID_FOR=(redo_log_type,database_role) ]
 [ DB_UNIQUE_NAME ]
 [ VERIFY ]
 }

The LOG_ARCHIVE_DEST_n initialization parameter defines up to ten (where n = 1, 2, 3, ... 10) destinations, each of which must specify either the LOCATION or the SERVICE attribute to specify where to archive the redo data. All other attributes are optional. Note that whether you are specifying the LOCATION attribute or the SERVICE attribute, it must be the first attribute supplied in the list of attributes.

If you choose not to enter any attributes, you can specify a null string by entering the following:

LOG_ARCHIVE_DEST_n=' ';

You set the attributes for the LOG_ARCHIVE_DEST_n initialization parameter to control different aspects of how redo transport services transfer redo data from a production or primary database destination to another (standby) database destination. You can query the V$ARCHIVE_DEST view to see the current attribute settings for each destination (n).

For every LOG_ARCHIVE_DEST_n initialization parameter that you define, you must specify a 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 whether the corresponding destination is currently enabled or disabled.

Values:

• Control whether or not redo transport services use synchronous or asynchronous disk I/O to write redo data to the archived redo log files. The default is NOAFFIRM.

• Specifies an alternate archiving destination to be used when the original destination fails. There is no default value; if an alternate destination is not specified, then archiving does not automatically change to another destination if the original destination fails.

• Uses the archiver processes (ARCn) to collect transaction redo data and transmit it to standby destinations. If neither the ARCH or LGWR attribute is specified, the default is ARCH.

• Specifies that network I/O is to be done asynchronously when archival is performed using the log writer process (LGWR) and the network server (LNSn) processes.

• Specifies a unique name for the database at this destination. You must specify a name; there is no default value.

• Specifies a time lag between when redo data is archived on a physical standby site and when the archived redo log file is applied to the physical standby database. You cannot set the DELAY attribute for a logical standby database destination. If you specify the DELAY attribute without a time interval, the default is 30 minutes.

• Defines one archival destination to receive redo data on behalf of several destinations. Redo transport services transmit redo data to the destination that then shares its archived redo log files with multiple standby databases.

• Uses the log writer process (LGWR) to collect transaction redo data and transmit it to standby destinations. If neither the ARCH or LGWR attributes are specified, the default is ARCH.

• Specifies either a local file system destination or the directory, file system, or Oracle Storage Manager disk group that will serve as the flash recovery area. You must specify this attribute for at least one destination. You can specify either a local disk directory or flash recovery area with the LOCATION attribute. You must include either the LOCATION or the SERVICE attribute for each destination to specify where to archive the redo data.

• 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. If neither the MANDATORYOPTIONAL attribute is specified, the default is OPTIONAL. nor the

• Specifies the maximum number of network connections that can be used to transmit redo data to this destination.

• Controls the consecutive number of times redo transport services attempt to reestablish communication and transmit redo data to a failed destination before the primary database permanently gives up on the standby database.

• 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. The default is 180 seconds.

• Indicates that the location of the archived redo log file is not to be recorded at the corresponding destination.

• 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 neither the MANDATORY nor the OPTIONAL attribute is specified, the default is OPTIONAL.

• Specifies 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. The default is 300 seconds.

• Specifies a valid Oracle Net service name (SERVICE=net_service_name) that identifies the remote Oracle database instance to which redo data will be sent. Each destination must specify either the LOCATION or the SERVICE attribute. There is no default net service name.

• Specifies that network I/O is to be performed synchronously for the destination, which means that once I/O is initiated, the log writer 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 destination before continuing

• Defines a directory specification and format template for names of the archived redo log files or standby redo log files 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. There is no default template format.

• Identifies when redo transport services can transmit redo data to destinations based on the following factors:

  • redo_log_type—whether online redo log files, standby redo log files, or both are currently being archived on the database at this destination

  • database_role—whether the database is currently running in the primary or the standby role

• Indicates if an archiver (ARCn) process should scan and verify the correctness of the contents of a completed archived redo log file, either local or remote, after successfully completing the archival operation. By default, archived redo log files are not verified.

Deprecated Attributes for LOG_ARCHIVE_DEST_n

The following attributes are deprecated for the LOG_ARCHIVE_DEST_n parameter. They are retained for backward compatibility only.

In addition, note the following changes to the ASYNC and SYNC attributes:

• The BLOCKS keyword on the ASYNC attribute is no longer needed.

  It is no longer necessary to set this keyword because Data Guard dynamically adjusts the block count up or down to an appropriate number of blocks, as necessary.

• The PARALLEL and NOPARALLEL keywords on the SYNC attribute are no longer needed.

LOG_ARCHIVE_DEST_STATE_n

The LOG_ARCHIVE_DEST_STATE_n parameters (where n = 1, 2, 3, ... 10) specify the availability state of the corresponding destination. The parameter suffix (1 through 10) specifies one of the ten corresponding LOG_ARCHIVE_DEST_n destination parameters.

Values:

• enabled

  Specifies that a valid log archive destination can be used for a subsequent archiving operation (automatic or manual). This is the default.

• defer

  Specifies that valid destination information and attributes are preserved, but the destination is excluded from archiving operations until re-enabled.

• alternate

  Specifies that a log archive destination is not enabled but will become enabled if communications to another destination fail.

The LOG_ARCHIVE_DEST_STATE_n parameters have no effect on the ENABLE state for the LOG_ARCHIVE_DEST or LOG_ARCHIVE_DUPLEX_DEST parameters.

The V$ARCHIVE_DEST dynamic performance view shows values in use for the current session. The DEST_ID column of that view corresponds to the archive destination suffix n.

REMOTE_LOGIN_PASSWORDFILE

REMOTE_LOGIN_PASSWORDFILE specifies whether Oracle checks for a password file.

Values:

• NONE

  Oracle ignores any password file. Therefore, privileged users must be authenticated by the operating system.

• SHARED

  One or more databases can use the password file. The password file can contain SYS as well as non-SYS users.

LOG_ARCHIVE_FORMAT

LOG_ARCHIVE_FORMAT is applicable only if you are using the redo log in ARCHIVELOG mode. Use a text string and variables to specify the default filename format when archiving redo log files. The string generated from this format is appended to the string specified in the LOG_ARCHIVE_DEST parameter.

The following variables can be used in the format:

%s log sequence number

%S log sequence number, zero filled

%tthread number

%Tthread number, zero filled

%a activation ID

%d database ID

%r resetlogs ID that ensures unique names are constructed for the archived log files across multiple incarnations of the database

Using uppercase letters for the variables (for example, %S) causes the value to be fixed length and padded to the left with zeros. An example of specifying the archive redo log filename format follows:

LOG_ARCHIVE_FORMAT = 'log%t_%s_%r.arc'

Neither LOG_ARCHIVE_DEST nor LOG_ARCHIVE_FORMAT have to be complete file or directory specifiers themselves; they only need to form. a valid file path after the variables are substituted into LOG_ARCHIVE_FORMAT and the two parameters are concatenated together.

LOG_ARCHIVE_MAX_PROCESSES

LOG_ARCHIVE_MAX_PROCESSES specifies the number of archiver background processes (ARC0 through ARC9) Oracle initially invokes.

• If the LOG_ARCHIVE_START initialization parameter has the value true, then this value is evaluated at instance startup. Note that the LOG_ARCHIVE_START initialization parameter was deprecated as of Oracle Database 10g Release 1 (10.1).

• Otherwise, this parameter is evaluated when the archiver process is first invoked by SQL*Plus or SQL syntax.

The actual number of archiver processes in use may vary subsequently based on archive workload.

COMPATIBLE

COMPATIBLE allows you to use a new release of Oracle, while at the same time guaranteeing backward compatibility with an earlier release. This is helpful if it becomes necessary to revert to the earlier release.

This parameter specifies the release with which Oracle must maintain compatibility. It allows you to take advantage of the maintenance improvements of a new release immediately in your production systems without testing the new functionality in your environment. Some features of the release may be restricted.

When using a standby database, this parameter must have the same value on both the primary and standby databases.

FAL_SERVER

FAL_SERVER specifies the FAL (fetch archive log) server for a standby database. The value is an Oracle Net service name, which is assumed to be configured properly on the standby database system to point to the desired FAL server.

FAL_CLIENT

FAL_CLIENT specifies the FAL (fetch archive log) client name that is used by the FAL service, configured through the FAL_SERVER parameter, to refer to the FAL client. The value is an Oracle Net service name, which is assumed to be configured properly on the FAL server system to point to the FAL client (standby database).

Given the dependency of FAL_CLIENT on FAL_SERVER, the two parameters should be configured or changed at the same time.

DB_FILE_NAME_CONVERT

DB_FILE_NAME_CONVERT is useful for creating a duplicate database for recovery purposes. It converts the filename of a new datafile on the primary database to a filename on the standby database. If you add a datafile to the primary database, you must add a corresponding file to the standby database. When the standby database is updated, this parameter converts the datafile name on the primary database to the datafile name on the standby database. The file on the standby database must exist and be writable, or the recovery process will halt with an error.

If you specify an odd number of strings (the last string has no corresponding replacement string), an error is signalled during startup. If the filename being converted matches more than one pattern in the pattern/replace string list, the first matched pattern takes effect. There is no limit on the number of pairs that you can specify in this parameter (other than the hard limit of the maximum length of multivalue parameters).

Set the value of this parameter to two strings. The first string is the pattern found in the datafile names on the primary database. The second string is the pattern found in the datafile names on the standby database.

You can also use DB_FILE_NAME_CONVERT to rename the datafiles in the clone control file when setting up a clone database during tablespace point-in-time recovery.

LOG_FILE_NAME_CONVERT

LOG_FILE_NAME_CONVERT converts the filename of a new log file on the primary database to the filename of a log file on the standby database. If you add a log file to the primary database, you must add a corresponding file to the standby database.

If you specify an odd number of strings (the last string has no corresponding replacement string), an error is signalled during startup. If the filename being converted matches more than one pattern in the pattern/replace string list, the first matched pattern takes effect. There is no limit on the number of pairs that you can specify in this parameter (other than the hard limit of the maximum length of multivalue parameters).

When the standby database is updated, this parameter converts the log file name on the primary database to the log file name on the standby database. The file must exist on the standby database and must be writable or the recovery process will halt with an error.

The first string is the pattern found in the log file names on the primary database. The second string is the pattern found in the log file names on the standby database.

You should also use LOG_FILE_NAME_CONVERT to rename the logfiles in the clone control file when setting up the clone database during tablespace point-in-time recovery.

STANDBY_FILE_MANAGEMENT

STANDBY_FILE_MANAGEMENT enables or disables automatic standby file management. When automatic standby file management is enabled, operating system file additions and deletions on the primary database are replicated on the standby database.

Values:

• MANUAL

  disables automatic standby file management

• AUTO

  enables automatic standby file management

Setting STANDBY_FILE_MANAGEMENT to AUTO causes Oracle to automatically create files on the standby database and, in some cases, overwrite existing files. Care must be taken when setting STANDBY_FILE_MANAGEMENT and DB_FILE_NAME_CONVERT so that existing standby files will not be accidentally overwritten.

If the standby database is on the same system as the primary database, then ensure that the primary and standby systems do not point to the same files.

STANDBY_ARCHIVE_DEST

STANDBY_ARCHIVE_DEST is relevant only for a standby database in managed recovery mode. It specifies the location of archive logs arriving from a primary database. Oracle uses STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT to fabricate the fully qualified standby log filenames and stores the filenames in the standby control file.

You can see the value of this parameter by querying the V$ARCHIVE_DEST data dictionary view.