oracle10g data guard redo transport service

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