1,
Table 5-1 LOG_ARCHIVE_DEST_STATE_n Initialization Parameter Attributes
Attribute  Description

ENABLE
 

Redo transport services can transmit redo data to this destination. This is the default.

DEFER
 

Redo transport services will not transmit redo data to this destination. This is a valid but unused destination.

ALTERNATE
 

This destination is not enabled, but it will become enabled if communication to its associated destination fails.

RESET
 

Functions the same as DEFER, but clears any error messages for the destination if it had previously failed.

2,
To configure a flash recovery area, use the DB_RECOVERY_FILE_DEST initialization parameter.
LOG_ARCHIVE_DEST_10 is implicitly set to USE_DB_RECOVERY_FILE_DEST (meaning that archived redo log files will be sent to the flash recovery area)
if you create a recovery area and do not set any other local archiving destinations

5 Redo Transport Services
5.2.3.1 Using the LOG_ARCHIVE_DEST_10 Destination

3,默认flash recovery area采用log_archive_dest_10(隐式由oracle配置了）,如果想让其它log_archive_dest_x使用flash recovery area,请采用
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'
--细看location中的值为use_db_recovery_file_dest

4,在主备库间共享flash recovery area

 Sharing a Flash Recovery Area Between Primary and Standby Databases

You can share a flash recovery area between databases provided each database that shares the flash recovery area has a unique database name, specified with the DB_UNIQUE_NAME initialization parameter.

The following examples show how to specify initialization parameters on the primary and standby databases that will share a flash recovery area in the /arch/oradata location. Although the DB_UNIQUE_NAME parameter is not specified in Example 5-3, it defaults to PAYROLL, which is the name specified for the DB_NAME initialization parameter.

Example 5-3 Primary Database Initialization Parameters for a Shared Recovery Area

DB_NAME=PAYROLL
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'
DB_RECOVERY_FILE_DEST='/arch/oradata'
DB_RECOVERY_FILE_DEST_SIZE=20G

Example 5-4 Standby Database Initialization Parameters for a Shared Recovery Area

DB_NAME=PAYROLL
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'
STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'
DB_RECOVERY_FILE_DEST='/arch/oradata'
DB_RECOVERY_FILE_DEST_SIZE=5G

5,dg主备库间redo日志的传输，采用lgwr或者arc，但不能二者同用，向一个目标地传送重作日志，但可以向一些目标地用lgwr,另一些目标地用arc,反之亦可
6,arc仅用于dg的最大性能保护模式，lgwr,用于除最大性能保护模式的其它模式

7
    *

      On the remote destination, the remote file server process (RFS) will, in turn, write the redo data to an archived redo log file from a standby redo log file.
Log apply services use Redo Apply (MRP processFoot 1 ) or SQL Apply (LSP processFoot 2 ) to apply the redo to the standby database.

Because the online redo log files are archived locally first, the LGWR process reuses the online redo log files much earlier
than would be possible if the ARCn processes archived to the standby database concurrently with the local destination.

8
Synchronous LGWR processing is required for the maximum protection and maximum availability modes of data protection in Data Guard configurations.

9
If you configure a destination to use the LGWR process, but for some reason the LGWR process becomes unable to archive to the destination,
then redo transport will revert to using the ARCn process to complete archival operations.--oracle 有些聪明哟，可以自我判断

10
Specifying the SYNC attribute on the LOG_ARCHIVE_DEST_n parameter is optional, because this is the default for LGWR archival processing.
 The NET_TIMEOUT attribute is recommended, because it controls the amount of time that the LGWR process waits for status from the network
 server process before terminating the network connection.
If there is no reply within NET_TIMEOUT seconds, then the LGWR process returns an error message.

11  ---valid_for通俗点就是两手准备，用于角色转换（主备库）,valid_for=(日志类型，数据库角色类型）;否则，呵，一旦发生role transation,你就要重新起草新的spfile文件了
The VALID_FOR attribute enables you to configure destination attributes for both the primary and standby database roles in one server parameter file (SPFILE), so that your Data Guard configuration operates properly after a role transition. This simplifies switchovers and failovers by removing the need to enable and disable the role-specific parameter files after a role transition.

When you specify the VALID_FOR attribute of the LOG_ARCHIVE_DEST_n parameter, it identifies when redo transport services can transmit redo data to destinations based on the following factors:

    *

      Whether the database is currently running in the primary or the standby role
    *

      Whether archival of the online redo log file, standby redo log file, or both is required depending on the current role of the database

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 redo_log_type keyword identifies the destination as valid for archiving the following:
 ONLINE_LOGFILE, STANDBY_LOGFILE, or ALL_LOGFILES. The database_role keyword identifies the role in which the current database
must be in for the destination to be valid: PRIMARY_ROLE,
STANDBY_ROLE, or ALL_ROLES.

12
The LOG_ARCHIVE_CONFIG parameter also has SEND, NOSEND, RECEIVE, and NORECEIVE attributes:

    *

      SEND enables a database to send redo data to remote destinations
    *

      RECEIVE enables the standby database to receive redo from another database

To disable these settings, use the NOSEND and NORECEIVE keywords.

For example, to ensure the primary database never accidentally receives any archived redo data, set the LOG_ARCHIVE_CONFIG initialization parameter to NORECEIVE on the primary database, as follows:

LOG_ARCHIVE_CONFIG='NORECEIVE,DG_CONFIG=(chicago,boston)'

13
alter system set log_archive_config='nosend,dg_config=(centos,rhel)' scope=spfile;--send与receive各含义：是否发送重作日志到其它库；receive是否接受来自其它库的重作日志;要新添send之流属性，要重启库

14,用于控制当log_archive_dest_n出错，如何处理，有如下参数
SQL> alter system set log_archive_dest_1='location=/oracle/centosarch reopen=30 max_failure=3';

System altered.

SQL> show parameter log_archive_dest_

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1                   string      location=/oracle/centosarch re  --reopen是过多久时间（秒）再次重试此目标地点;max_failure是连续重试次数，出现此参数必须要出现reopen
                                                 pen=30 max_failure=3  ---location可立速生效
log_archive_dest_10                  string
log_archive_dest_2                   string      SERVICE=rhel lgwr async valid_   --service（用于传递到备库），要使以上reopen和max_failure生效，须重启库；采用scope=spfile;
                                                 for=(online_logfiles,primary_r
                                                 ole) db_unique_name=rhel

15,升极或降级dg保护模式
 在主库，
  shutdown immediate
  startup mount
  SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;--查看目前主库的保护模式
 在主库
  ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY; --SQL ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}
 打开主库
  alter database open
 在变更dg保护级别后,在主库再次查询保护模式
  SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;--查看目前主库的保护模式

16
The location where archived redo log files are stored on the standby database is determined according to the following list of rules. When the database instance is started, the archived redo log files are evaluated in the list order:

   1.

      If the STANDBY_ARCHIVE_DEST initialization parameter is specified on the standby database, that location is used.
   2.

      If the LOG_ARCHIVE_DEST_n parameter contains the VALID_FOR=(STANDBY_LOGFILE,*) attribute, then the location specified for this destination is used.
   3.

      If the COMPATIBLE parameter is set to 10.0 or greater and none of the LOG_ARCHIVE_DEST_n parameters contain the VALID_FOR=(STANDBY_LOGFILE,*)attribute, then an arbitrary LOG_ARCHIVE_DEST_n parameter that is valid for the destination is used.
   4.

      If none of the initialization parameters have been specified, then archived redo log files are stored in the default location for the STANDBY_ARCHIVE_DEST initialization parameter.

17
log_archive_dest_n可以配置归档到指定目标，重用在线重作日志的策略（也就是说：当值为optional时，就是归档失败，在线重作日志照样重用；当值为mandatory时，归档到指定目标不成功时，在线日志不能重用，一直到归档到指定目标成功；一般本地归档全为mandatory(default);remote archival为optional
log_archive_dest_3='LOCATION=/oracle/thirdarch/ OPTIONAL';--这样配置吧

18  --dependency，用于多个备库可以共同访问或者叫共享归档日志（就是都去访问）,否则没意义
Specifying a destination dependency can be useful in the following situations:

    *

      When you configure a physical standby database and a logical standby database on the same system.
    *

      When you configure the standby database and the primary database on the same system. Therefore, the archived redo log files are implicitly accessible to the standby database.
    *

      When clustered file systems are used to provide remote standby databases with access to the primary database archived redo log files.
    *

      When operating system-specific network file systems are used, providing remote standby databases with access to the primary database archived redo log files.

For example, assume there are two standby databases stdby1 and stdby2 that reside on the same piece of hardware. There is no need to use network bandwidth and disk space to send the same redo data to both destinations. The databases can share the same archived redo log files if you use the DEPENDENCY attribute to designate one of the destinations as being a dependent destination. That is, the primary database sends redo to be archived on the destination that is not defined as the dependent destination. If the redo data successfully arrives at that destination, the primary database considers it archived to both destinations. For example:

LOG_ARCHIVE_DEST_1='LOCATION=DISK1 MANDATORY'
LOG_ARCHIVE_DEST_2='SERVICE=stdby1 OPTIONAL'
LOG_ARCHIVE_DEST_3='SERVICE=stdby2 OPTIONAL DEPENDENCY=LOG_ARCHIVE_DEST_2' ---dependency的值为依赖性的另一个log_archive_dest_x

19 ---要注意一点是：如果主库一直不可以用，但这时你又配置多个备库，可以通过其它备库（与主库的网络连接正常）来应用出现log gap的备库，但你要在此备库配置额外的参数
The important consideration here is that automatic gap recovery is contingent on the availability of the primary database.
If the primary database is not available and you have a configuration with multiple physical standby databases, you can set up additional initialization parameters so that the Redo Apply can resolve archive gaps from another standby database,

20
Define the FAL_CLIENT and FAL_SERVER initialization parameters only for physical standby databases in the initialization parameter

fal_server可以包括多个值：
FAL_SERVER=standby2_db,standby3_db

21
手工处理物理及逻辑备库的log lag
SQL> alter database stop logical standby apply; ---停止逻辑备库的日志应用

Database altered.

对于逻辑备库，
ls -l --根据show parameter log_archive_dest_x的值，查看目录最新的归档序列号
ls -l --同上，查看主库的最新的归档序号
对比以上主备库ls -l归档的差异序列号
把差异序列号的归档日志，以tar包cp到备库
然后tar xvf解开
ALTER DATABASE REGISTER LOGICAL LOGFILE '/disk1/oracle/dbs/log-1292880008_10.arc'; --在备库注册手工添加的相关归档日志
alter database stop logical standby apply; ---停止逻辑备库的日志应用
开始逻辑备库日志应用
 ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

对于物理备库
To determine if there is an archive gap on your physical standby database, query the V$ARCHIVE_GAP view as shown in the following example:

SQL> SELECT * FROM V$ARCHIVE_GAP;
    THREAD#  LOW_SEQUENCE#  HIGH_SEQUENCE#
-----------  -------------  --------------
          1              7              10

The output from the previous example indicates your physical standby database is currently missing log files from sequence 7 to sequence 10 for thread 1. After you identify the gap, issue the following SQL statement on the primary database to locate the archived redo log files on your primary database (assuming the local archive destination on the primary database is LOG_ARCHIVE_DEST_1):

SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND   2> SEQUENCE# BETWEEN 7 AND 10;
NAME
--------------------------------------------------------------------------------
/primary/thread1_dest/arcr_1_7.arc /primary/thread1_dest/arcr_1_8.arc /primary/thread1_dest/arcr_1_9.arc

Copy these log files to your physical standby database and register them using the ALTER DATABASE REGISTER LOGFILE statement on your physical standby database. For example:

SQL> ALTER DATABASE REGISTER LOGFILE
'/physical_standby1/thread1_dest/arcr_1_7.arc';
SQL> ALTER DATABASE REGISTER LOGFILE
'/physical_standby1/thread1_dest/arcr_1_8.arc';

After you register these log files on the physical standby database, you can restart Redo Apply.

ARCn Process Wait Events