dg 备库归档位置不一致

1、dg的数据库版本是11.2.0.1

2、备库的参数文件中没有使用参数STANDBY_ARCHIVE_DEST

3、参数文件添加的如下参数

*.DB_NAME=rac
*.DB_UNIQUE_NAME=orcl
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(rac,orcl)'
*.LOG_ARCHIVE_DEST_1='LOCATION=/arc VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl'
*.LOG_ARCHIVE_DEST_2='SERVICE=rac ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=rac'
*.LOG_ARCHIVE_DEST_STATE_1=ENABLE
*.LOG_ARCHIVE_DEST_STATE_2=ENABLE
*.REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
*.LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
*.LOG_ARCHIVE_MAX_PROCESSES=30
*.FAL_SERVER=rac
*.fal_client=orcl
*.DB_FILE_NAME_CONVERT='+data/rac/datafile/','/u01/app/oradata/','+data/rac/tempfile','/u01/app/oradata'
*.LOG_FILE_NAME_CONVERT='+data/rac/onlinelog/','/u01/app/oradata/','+data/asm/onlinelog/','/u01/app/oradata/'
*.STANDBY_FILE_MANAGEMENT=AUTO

4、发现部分日志的归档位置不对

SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1;

NAME
--------------------------------------------------------------------------------
/arc/1_108_819834549.arc
/arc/1_109_819834549.arc
/arc/1_110_819834549.arc
/arc/1_111_819834549.arc
/arc/1_112_819834549.arc
/arc/1_113_819834549.arc
/arc/1_114_819834549.arc
/arc/1_115_819834549.arc
/arc/1_116_819834549.arc
/arc/1_117_819834549.arc
/arc/1_118_819834549.arc
/arc/1_119_819834549.arc
/arc/1_120_819834549.arc
/arc/1_121_819834549.arc
/arc/1_122_819834549.arc
/arc/1_123_819834549.arc
/arc/1_124_819834549.arc
/arc/1_125_819834549.arc
/arc/1_126_819834549.arc
/arc/1_127_819834549.arc
/arc/1_128_819834549.arc
/arc/1_129_819834549.arc
/arc/1_130_819834549.arc
/arc/1_131_819834549.arc
/arc/1_132_819834549.arc
/arc/1_133_819834549.arc
/arc/1_134_819834549.arc
/arc/1_135_819834549.arc
/arc/1_136_819834549.arc
/arc/1_137_819834549.arc
/arc/1_138_819834549.arc
/arc/1_139_819834549.arc
/arc/1_140_819834549.arc
/arc/1_141_819834549.arc
/arc/1_142_819834549.arc
/arc/1_143_819834549.arc
/arc/1_144_819834549.arc
/u01/app/product/dbs/arch1_148_819834549.arc
/u01/app/product/dbs/arch1_149_819834549.arc
/arc/1_145_819834549.arc
/arc/1_146_819834549.arc
/arc/1_147_819834549.arc
/arc/1_150_819834549.arc
/u01/app/product/dbs/arch1_151_819834549.arc
/arc/1_152_819834549.arc
/arc/1_153_819834549.arc
60 rows selected.

发现部分归档日志在/arc目录下面，部分归档在/u01/app/product/dbs/ 目录下，很是疑惑这是为什么，最后在飞总的指导下，明白了这是为什么，下面我就来解释一下这个问题的原因把：

造成这个问题的原因和参数这个连个参数的设置有关系：standby_archive_dest和log_archive_dest_n

下面是standby_archive_dest和log_archive_dest_n 关系

1)主库的LOG_ARCHIVE_DEST_n= 'service' 默认的arch传输方式，primary会远程将archived log传输到standby_archive_dest下

 

2)fal_*是通过arch传输过来的，所以使用的是STANDBY_ARCHIVE_DEST目录，如果不存在这个目录，就使用LOG_ARCHIVE_DEST_n

 

3)If both parameters are specified, the STANDBY_ARCHIVE_DEST initialization parameter

   overrides the directory location specified with the LOG_ARCHIVE_DEST_n parameter.

如果STANDBY_ARCHIVE_DEST和LOG_ARCHIVE_DEST_n两个参数指定,STANDBY_ARCHIVE_DEST初始化覆盖LOG_ARCHIVE_DEST_n目录指定位置参数。

 

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.

如果STANDBY_ARCHIVE_DEST和LOG_ARCHIVE_DEST_n都没有配置，将会把归档日志放到STANDBY_ARCHIVE_DEST的默认目录

 

5)如果STANDBY_ARCHIVE_DEST未配置，而配置了LOG_ARCHIVE_DEST_n,那么产生的归档将放置到LOG_ARCHIVE_DEST_n

 

6)建议：STANDBY_ARCHIVE_DEST和LOG_ARCHIVE_DEST_n=‘location’的配置相同

 

7)在11g，已经不建议使用STANDBY_ARCHIVE_DEST，也就是说建议配置dg的时候尽量使用standby redo logfile




后来我去查了 一个表

SQL>  select DEST_NAME,NAME_SPACE,DESTINATION from v$archive_dest;

DEST_NAME     NAME_SP DESTINATION
-------------------- ------- --------------------
LOG_ARCHIVE_DEST_1   SYSTEM  /arc
LOG_ARCHIVE_DEST_2   SYSTEM  rac
LOG_ARCHIVE_DEST_3   SYSTEM
LOG_ARCHIVE_DEST_4   SYSTEM
LOG_ARCHIVE_DEST_5   SYSTEM
LOG_ARCHIVE_DEST_6   SYSTEM
LOG_ARCHIVE_DEST_7   SYSTEM
LOG_ARCHIVE_DEST_8   SYSTEM
LOG_ARCHIVE_DEST_9   SYSTEM
LOG_ARCHIVE_DEST_10  SYSTEM
LOG_ARCHIVE_DEST_11  SYSTEM
LOG_ARCHIVE_DEST_12  SYSTEM
LOG_ARCHIVE_DEST_13  SYSTEM
LOG_ARCHIVE_DEST_14  SYSTEM
LOG_ARCHIVE_DEST_15  SYSTEM
LOG_ARCHIVE_DEST_16  SYSTEM
LOG_ARCHIVE_DEST_17  SYSTEM
LOG_ARCHIVE_DEST_18  SYSTEM
LOG_ARCHIVE_DEST_19  SYSTEM
LOG_ARCHIVE_DEST_20  SYSTEM
LOG_ARCHIVE_DEST_21  SYSTEM
LOG_ARCHIVE_DEST_22  SYSTEM
LOG_ARCHIVE_DEST_23  SYSTEM
LOG_ARCHIVE_DEST_24  SYSTEM
LOG_ARCHIVE_DEST_25  SYSTEM
LOG_ARCHIVE_DEST_26  SYSTEM
LOG_ARCHIVE_DEST_27  SYSTEM
LOG_ARCHIVE_DEST_28  SYSTEM
LOG_ARCHIVE_DEST_29  SYSTEM
LOG_ARCHIVE_DEST_30  SYSTEM
LOG_ARCHIVE_DEST_31  SYSTEM
STANDBY_ARCHIVE_DEST SYSTEM  /u01/app/product//dbs
32 rows selected.



结果发现虽然我在参数文件中没有设置 STANDBY_ARCHIVE_DEST ，但是默认的路径自己设置了，所以有部分日志去了STANDBY_ARCHIVE_DEST/u01/app/product//dbs

所以有部分日志不在 /arc目录下面

下面我有一个疑问，怎么知道是通过fal传输日志还是通过主库的LOG_ARCHIVE_DEST_n='service' 的方式传输日志呢？

通过查询一个视图

SQL> select process,client_process,status,thread#,sequence#,block#,blocks from v$managed_standby;
PROCESS   CLIENT_P STATUS   THREAD#  SEQUENCE# BLOCK#     BLOCKS
--------- -------- ------------ ---------- ---------- ---------- ----------
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CLOSING 1  153   10240 708
ARCH  ARCH   CLOSING 2  191   77824       1533
ARCH  ARCH   CLOSING 1  154   88064 510
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
ARCH  ARCH   CONNECTED 0    0       0  0
RFS  N/A   IDLE 0    0       0  0
RFS  N/A   IDLE 0    0       0  0
RFS  LGWR   IDLE 2  192   42179  1
RFS  LGWR   IDLE 1  155   27925  1
RFS  UNKNOWN  IDLE 0    0       0  0

35 rows selected.



通过对视图参数的理解：

PROCESS:

• RFS - Remote file server

• MRP0 - Detached recovery server process

• MR(fg) - Foreground recovery session

• ARCH - Archiver process

• FGRD

• LGWR

• RFS(FAL)

• RFS(NEXP)

• LNS - Network server process

  通过参数我们可以知道 RFS 是通过LOG_ARCHIVE_DEST_n='service' 方式传输的日志，RFS(FAL)是通过fal方式传输日志

STATUS:

• UNUSED - No active process

• ALLOCATED - Process is active but not currently connected to a primary database

• CONNECTED - Network connection established to a primary database

• ATTACHED - Process is actively attached and communicating to a primary database

• IDLE - Process is not performing any activities

• ERROR - Process has failed

• OPENING - Process is opening the archived redo log

• CLOSING - Process has completed archival and is closing the archived redo log

• WRITING - Process is actively writing redo data to the archived redo log

• RECEIVING - Process is receiving network communication

• ANNOUNCING - Process is announcing the existence of a potential dependent archived redo log

• REGISTERING - Process is registering the existence of a completed dependent archived redo log

• WAIT_FOR_LOG - Process is waiting for the archived redo log to be completed

• WAIT_FOR_GAP - Process is waiting for the archive gap to be resolved

• APPLYING_LOG - Process is actively applying the archived redo log to the standby database

  
  

  
  

CLIENT_PROCESS:

• Archival - Foreground (manual) archival process (SQL)

• ARCH - Background ARCn process

• LGWR - Background LGWR process