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.
所以有部分日志不在 /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方式传输日志
-
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
-
Archival
- Foreground (manual) archival process (SQL) -
ARCH
- BackgroundARC
n
process -
LGWR
- BackgroundLGWR
process