Log_archive_dest_n parameter explanation

In the Dataguard configuration, the configuration of the Log_archive_dest_n parameter is more important, so do the next finishing

The following is a list of the reference

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M00/74/5F/wKiom1Yba_vgDW8lAAJpiISrUH4021.jpg "title=" 1.png " alt= "Wkiom1yba_vgdw8laajpiisruh4021.jpg"/>

thelog_archive_dest_N Initializationparameter defines up to (whereN= 1, 2, 3, ... Destinations,each of which must specify either the Locationor theSERVICEattribute to specify where toarchive the redo data. All other attributes is optional. Note that whether youare specifying the Locationattribute or theSERVICEattribute, it must is the firstattribute supplied in the list of attributes.

If you choosenot to enter any attributes and then you can specify a NULL string by entering thefollowing:

Log_archive_dest_N= ";

you set theattributes for the  Log_archive_dest_ N  initialization parameter to Control differentaspects of how Redo transport services transfer redo data from a production orprimary database Destinatio N to another (standby) database destination. You canquery the  v$archive_ DEST  view Tosee the Current attribute settings for each destination ( n ).

For everyLOG_ARCHIVE_DEST_n initialization parameter That's define, you must specify AcorrespondingLOG_ARCHIVE_DEST_STATE_n parameter. theLOG_ARCHIVE_DEST_STATE_n (wheren is a integer from 1 to + ) initialization parameter specifies whetherthe corresponding destination is currently ENABL Ed or disabled.

DestinationsLOG_ARCHIVE_DEST_11 throughLOG_ARCHIVE_DEST_31  don't support theSYNC, ARCH, LOCATION, MANDATORY, orALTERNATE attributes, and cannot be specified as the target of theALTERNATE attribute.

LOG_ARCHIVE_DEST_11 throughLOG_ARCHIVE_DEST_31 can only is used when theCOMPATIBLE initialization parameter is set to11.2.0 or higher.

Parameter explanation:

1.affirm and Noaffirm

affirm explicitly specifies that the redo transport destination notifies the carrier that redo data was received after writing redo data to standby redo log

noaffirm explicitly specify that the redo transport destination notifies the carrier of the redo data before writing redo data to the standby redo log

If not explicitly specified, when the Sync property is specified, the default is affirm, and when the async attribute is specified, the default is Noaffirm

2.db_unique_name

This parameter specifies the unique name of the database at the destination, and if there are multiple standby databases in the DG, this property is useful, and using the Db_unique_name property can clearly identify the relationship between the primary and standby databases. Db_unique_name the name specified must match one of the values db_unique_name in the Dg_config list, the name specified by the Db_unique_name attribute must also match the specified destination database initialization parameters Db_unique_ The value of name, and if not specified, the connection is rejected.

3.delay

Delay The parameter explicitly specifies the time at which an standby location application receives the archived redo data delay, which is optional, and the default is no delay, the setting of the delay property indicates that the archive redo log is inactive at the standby destination. The log is not applied until the specified time interval expires, on the standby database, when the redo database is successfully transferred and archived, the time interval of delay is measured in minutes, which can be used to protect the standby database from user errors or corruption from the primary database , is a compromise solution, in the process of failover will inevitably need more time to apply the log. Delay does not affect the redo time transfer to the standby destination, and any delay that is set will be ignored if the real-time application is started. Changing the Delay property setting will work when the next redo time is archived, and the log being archived is unaffected

4. location and service

Each destination must have a location or service attribute that is used to develop the redo transport service to plug out Redo data to a local disk directory or remote database destination.

log_archive_dest_1-log_archive_dest_10 destinations can include

Location property or service property

log_archive_dest_11-log_archive_dest_31 destination can only include

Service property.

If you want to specify multiple properties for the Log_archive_dest_n initialization parameter, first specify the location or service attribute in the list of attributes. Make sure that the database local archive redo log directory is accessible by using the Location property to specify at least one local disk directory. By specifying location=' use_db_recovery_file_dest '

You can specify the file transfer location as the Flashback recovery area. Corresponding database initialization parameters db_recovery_file_dest the specified directory, Oracle automatically manages the files stored in the Flashback recovery area through OMF, and must use the Oracle Net service name in the service attribute

5.SYNC and Async

Specifies that synchronous sync transfer or asynchronous async transfer mode is used.

log_archive_dest_11-log_archive_dest_31 The sync attribute is not supported, and the Sync property indicates that redo data generated by food must be received by each enabled destination before the food is submitted, and the Async attribute indicates that the redo data generated by the food does not need to be received by the destination before the transaction commits, if not specified, The default value is async

6.vaild_for

In DG, Oracle determines whether the directory specified by log_archive_dest_n generates an appropriate archive redo log based on the database role and the redo log type, and the Vaild_for attribute is optional. Oracle recommends that each database in the DG configuration specify the Vaild_for attribute for the log transport destination, so that redo transport can continue to work after the primary database role transitions to any standby database in the configuration.

Configure valid_for parameters for each log_archive_dest_n destination

Valid_for= (Redo_log_type,database_role)

Redo_log_type keyword indicates that the destination generates an archived redo log type

Online_logfile : The destination only archives online redo logs

Standby_logfile : The destination only archives Standbyredo logs

All_logfiles : Destination Both archive online redo log, also archive standby redo log

Database_role indicates that the destination generates an archived database role

Primary_role : Only the database is master, the destination will generate an archive

Standby_role : Only the database is prepared, the destination will generate an archive

All_role : When the database is either master or standby, the destination will generate an archive

If the destination does not specify the Valid_for property, by default, the destination will archive the online redo and standby redo, regardless of whether the database is master or standby, and the default behavior is equal to setting the Valid_for= (All_logfiles,all_roles) property value , the Valid_for property can be enabled in the primary and standby databases using the same initialization parameter settings

Example:

log_archive_dest_1 the Vaild_for property is set to (Online_logfile,all_roles), the Vaild_for property of the Log_archive_dest_3 is set to (Standby_logfile,standby_role), When the database is primary, only the online logs are archived to the directory specified by Log_archive_dest_1, and if the database is converted to standby, the Standbyredo log is archived to the Log_archive_dest_3 specified directory, log_archive_ Dest_1 does not archive standby redo logs

Not to be continued ...

This article is from "The girl said" blog, please be sure to keep this source http://sugarlovecxq.blog.51cto.com/6707742/1702145

Log_archive_dest_n parameter explanation