[20171208]ORA-16014(10G).txt
--//别人配置dg遇到的问题,当时没有记录.在自己的环境做一个演示.这个问题相对隐藏很深.主要是自己不注意这些细节.
1.环境:
SYS@orcl> @ &r/ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- ----------------------------------------------------------------
x86_64/Linux 2.4.xx 10.2.0.4.0 Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
--//主库:
SYS@orcl> show parameter log_archive_dest_1
NAME TYPE VALUE
------------------ ------ -------------------------------------------------------------------------------------------------------------
log_archive_dest_1 string LOCATION=/data/log/ORCL/archivelog MANDATORY REOPEN=60 VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl
SYS@orcl> show parameter log_archive_dest_2
NAME TYPE VALUE
------------------ ------ ----------------------------------------------------------------------------------------------------
log_archive_dest_2 string SERVICE=standby LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby
--//备库:
SYS@xxxdg2> show parameter log_archive_dest_1
NAME TYPE VALUE
------------------ ------ ---------------------------------------------------------------------------------------------------------------
log_archive_dest_1 string LOCATION=/data/log/ORCL/archivelog MANDATORY REOPEN=60 VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=xxxdg2
SYS@xxxdg2> show parameter log_archive_dest_2
NAME TYPE VALUE
------------------ ------ ----------------------------------------------------------------------------------------------------
log_archive_dest_2 string SERVICE=orcl LGWR ASYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl
--//正常我配置dg基本如上,这些参数,非常机械,也不用什么记忆.直接从文档拷贝和粘贴.
--//对方把备库的参数log_archive_dest_1
log_archive_dest_1 string LOCATION=/data/log/ORCL/archivelog MANDATORY REOPEN=60 VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=xxxdg2
--//配置成:
log_archive_dest_1 string LOCATION=/data/log/ORCL/archivelog MANDATORY REOPEN=60 VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=xxxdg2
--//结果报错ora-16014错误,我仅仅重复演示:
2.演示:
--//备库执行:
SYS@xxxdg2> create pfile='/tmp/@.ora' from spfile ;
File created.
--//修改/tmp/xxxdg2.ora文件:
*.log_archive_dest_1='LOCATION=/data/log/ORCL/archivelog MANDATORY REOPEN=60 VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=xxxdg2'
--//如下:
*.log_archive_dest_1='LOCATION=/data/log/ORCL/archivelog MANDATORY REOPEN=60 VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=xxxdg2'
--//使用修改的参数启动备库:
SYS@xxxdg2> shutdown immediate ;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SYS@xxxdg2> startup mount pfile='/tmp/xxxdg2.ora'
ORACLE instance started.
Total System Global Area 3221225472 bytes
Fixed Size 2087416 bytes
Variable Size 654312968 bytes
Database Buffers 2550136832 bytes
Redo Buffers 14688256 bytes
Database mounted.
SYS@xxxdg2> show parameter log_archive_dest_1
NAME TYPE VALUE
------------------ ------ ----------------------------------------------------------------------------------------------------
log_archive_dest_1 string LOCATION=/data/log/ORCL/archivelog MANDATORY REOPEN=60 VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=xxxdg2
--//在备库执行:
SYS@xxxdg2> alter database recover managed standby database using current logfile disconnect ;
Database altered.
--//在主库执行:
SYS@orcl> alter system archive log current ;
System altered.
SYS@xxxdg2> @ &r/dg/dg
PROCESS PID STATUS CLIENT_P GROUP# THREAD# SEQUENCE# BLOCK# BLOCKS DELAY_MINS
--------- ------- ------------ -------- -------------- --------------- --------------- --------------- ---------------
ARCH 8835 CONNECTED ARCH N/A 0 0 0 0 0
ARCH 8837 CONNECTED ARCH N/A 0 0 0 0 0
RFS 8866 IDLE UNKNOWN N/A 0 0 0 0 0
MRP0 8870 WAIT_FOR_LOG N/A N/A 1 56077 0 0 0
--//日志并不应用.
Mon Dec 11 10:17:03 2017
ORA-16014: log 10 sequence# 56077 not archived, no available destinations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ORA-00312: online log 10 thread 1: '/data/orcl/redostb02.log'
Mon Dec 11 10:17:03 2017
Errors in file /u01/app/oracle/admin/orcl/bdump/xxxdg2_arc1_8837.trc:
ORA-16014: log 10 sequence# 56077 not archived, no available destinations
ORA-00312: online log 10 thread 1: '/data/orcl/redostb02.log'
Mon Dec 11 10:17:07 2017
Recovery of Online Redo Log: Thread 1 Group 10 Seq 56077 Reading mem 0
Mem# 0: /data/orcl/redostb02.log
Mon Dec 11 10:17:08 2017
Archiver process freed from errors. No longer stopped
$ cat /u01/app/oracle/admin/orcl/bdump/xxxdg2_arc1_8837.trc
/u01/app/oracle/admin/orcl/bdump/xxxdg2_arc1_8837.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/10.2.0/rac_db
System name: Linux
Node name: xxxdg2
Release: 2.6.18-92.el5
Version: #1 SMP Tue Jun 10 18:51:06 EDT 2008
Machine: x86_64
Instance name: xxxdg2
Redo thread mounted by this instance: 1
Oracle process number: 15
Unix process pid: 8837, image: oracle@xxxdg2 (ARC1)
*** 2017-12-11 10:17:03.780
*** SERVICE NAME:() 2017-12-11 10:17:03.780
*** SESSION ID:(650.1) 2017-12-11 10:17:03.780
ARCH: Connecting to console port...
ARCH: Connecting to console port...
*** 2017-12-11 10:17:03.790 21373 kcrr.c
ORA-16014: log 10 sequence# 56077 not archived, no available destinations
ORA-00312: online log 10 thread 1: '/data/orcl/redostb02.log'
*** 2017-12-11 10:22:52.574
ARCH: Connecting to console port...
ARCH: Connecting to console port...
*** 2017-12-11 10:22:52.574 21373 kcrr.c
ORA-16014: log 10 sequence# 56077 not archived, no available destinations
ORA-00312: online log 10 thread 1: '/data/orcl/redostb02.log'
--//很明显出现ORA-16014错误,目的存在问题,我开始google,发现提示都是磁盘空间不足的问题或者Inode不足的情况.
--//明显我的问题不是.
$ oerr ora 16014
16014, 00000, "log %s sequence# %s not archived, no available destinations"
// *Cause: An attempt was made to archive the named log, but the archive was
// unsuccessful. The archive failed because there were no archive log
// destinations specified or all destinations experienced debilitating
// errors.
// *Action: Verify that archive log destinations are being specified and/or
// take the necessary step to correct any errors that may have
// occurred.
SYS@xxxdg2> @ &r/dg/dg_dest
DEST_ID DEST_NAME STATUS TYPE DATABASE_MODE RECOVERY_MODE PROTECTION_MODE DESTINATION ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# ERROR
------- -------------------- --------- ---------- --------------- ----------------------- -------------------- ------------------------- ---------------- --------------- --------------- --------------- ------
1 LOG_ARCHIVE_DEST_1 VALID PHYSICAL MOUNTED-STANDBY MANAGED REAL TIME APPLY MAXIMUM PERFORMANCE /data/log/ORCL/archivelog 0 0 0 0
2 LOG_ARCHIVE_DEST_2 DEFERRED PHYSICAL MOUNTED-STANDBY MANAGED REAL TIME APPLY MAXIMUM PERFORMANCE orcl 0 0 0 0
--//配置好像也没有问题.我当时并没有发现log_archive_dest_1配置错误.
--//我继续执行如下在备库:
SYS@xxxdg2> alter database recover managed standby database cancel ;
Database altered.
SYS@xxxdg2> alter database recover managed standby database using current logfile disconnect ;
Database altered.
--//主库执行:
SYS@orcl> alter system archive log current ;
System altered.
--//问题依旧,但是mrp0进程可以应用日志了,仔细检查备库的alert.log:
Mon Dec 11 10:26:16 2017
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 11: '/data/orcl/redostb03.log'
Mon Dec 11 10:26:23 2017
Media Recovery Waiting for thread 1 sequence 56079 (in transit)
Mon Dec 11 10:26:23 2017
Recovery of Online Redo Log: Thread 1 Group 11 Seq 56079 Reading mem 0
Mem# 0: /data/orcl/redostb03.log
Mon Dec 11 10:26:52 2017
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 12: '/data/orcl/redostb04.log'
Mon Dec 11 10:26:57 2017
Media Recovery Waiting for thread 1 sequence 56080 (in transit)
Mon Dec 11 10:26:57 2017
Recovery of Online Redo Log: Thread 1 Group 12 Seq 56080 Reading mem 0
Mem# 0: /data/orcl/redostb04.log
Mon Dec 11 10:27:52 2017
ARCH: Archival stopped, error occurred. Will continue retrying
Mon Dec 11 10:27:52 2017
ORACLE Instance xxxdg2 - Archival Error
Mon Dec 11 10:27:52 2017
ORA-16014: log 10 sequence# 56077 not archived, no available destinations
ORA-00312: online log 10 thread 1: '/data/orcl/redostb02.log'
Mon Dec 11 10:27:52 2017
Errors in file /u01/app/oracle/admin/orcl/bdump/xxxdg2_arc1_8837.trc:
ORA-16014: log 10 sequence# 56077 not archived, no available destinations
ORA-00312: online log 10 thread 1: '/data/orcl/redostb02.log'
--//当时我还删除备库的standby log ,重新建立一遍.问题依旧.
--//仔细检查才发现备库的log_archive_dest_1设置错误.改正后一切正常.
--//但是实际上这个问题在要引起一定的注意,实际上现在日志不是实时应用,而且传输到备库的归档放那里呢?继续探究:
Mon Dec 11 14:44:54 2017
Completed: alter database recover managed standby database using current logfile disconnect
Mon Dec 11 14:48:45 2017
Using STANDBY_ARCHIVE_DEST parameter default value as ?/dbs/arch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~10g下也指定?/dbs/arch作为归档.
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 9909
RFS[1]: Identified database type as 'physical standby'
Mon Dec 11 14:48:45 2017
RFS LogMiner: Client disabled from further notification
Mon Dec 11 14:49:47 2017
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 9913
RFS[2]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 9: '/data/orcl/redostb01.log'
Mon Dec 11 14:50:46 2017
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[3]: Assigned to RFS process 9922
RFS[3]: Identified database type as 'physical standby'
RFS[3]: Archived Log: '/u01/app/oracle/product/10.2.0/rac_db/dbs/arch0001_0000056096_628034536.dbf'
~~~~~~~~~~~~~~~~~~~~~~=> 把前面1个archive log保存在 ?/dbs/arch.
Mon Dec 11 14:50:50 2017
Media Recovery Log /u01/app/oracle/product/10.2.0/rac_db/dbs/arch0001_0000056096_628034536.dbf
Mon Dec 11 14:51:05 2017
Media Recovery Waiting for thread 1 sequence 56097 (in transit)
Mon Dec 11 14:51:05 2017
Recovery of Online Redo Log: Thread 1 Group 9 Seq 56097 Reading mem 0
Mem# 0: /data/orcl/redostb01.log
Mon Dec 11 14:52:51 2017
ARCH: Archival stopped, error occurred. Will continue retrying
Mon Dec 11 14:52:51 2017
ORACLE Instance xxxdg2 - Archival Error
Mon Dec 11 14:52:51 2017
Primary database is in MAXIMUM PERFORMANCE mode
Mon Dec 11 14:52:51 2017
ORA-16014: log 9 sequence# 56097 not archived, no available destinations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ORA-00312: online log 9 thread 1: '/data/orcl/redostb01.log'
Mon Dec 11 14:52:51 2017
Errors in file /u01/app/oracle/admin/orcl/bdump/xxxdg2_arc0_9877.trc:
--//而日志的应用可以不断:
SYS@xxxdg2> @ &r/dg/dg
PROCESS PID STATUS CLIENT_P GROUP# THREAD# SEQUENCE# BLOCK# BLOCKS DELAY_MINS
--------- ------- ---------- -------- ------- ------- --------- ------------ ------------ ------------
ARCH 9877 CONNECTED ARCH N/A 0 0 0 0 0
ARCH 9879 CONNECTED ARCH N/A 0 0 0 0 0
RFS 9922 IDLE UNKNOWN N/A 0 0 0 0 0
RFS 9913 IDLE LGWR 1 1 56099 6952 19 0
MRP0 9886 APPLYING_L N/A N/A 1 56099 6969 102400 0
OG
SYS@xxxdg2> select * from v$standby_log ;
GROUP# DBID THREAD# SEQUENCE# BYTES USED ARC STATUS FIRST_CHANGE# FIRST_TIME LAST_CHANGE# LAST_TIME
------ ---------- ------- --------- ----------- ------------ --- ---------- ------------- ------------------- ------------ -------------------
9 1155815272 1 56097 52428800 1133056 NO ACTIVE 20236977651 2017-12-11 14:49:47 20237011654 2017-12-11 14:52:51
10 1155815272 1 56098 52428800 975872 NO ACTIVE 20237011654 2017-12-11 14:52:51 20237070891 2017-12-11 14:58:29
11 1155815272 1 56099 52428800 4561920 YES ACTIVE 20237070891 2017-12-11 14:58:29 20237121258 2017-12-11 15:02:43
12 UNASSIGNED 1 0 52428800 512 NO UNASSIGNED 0 0
13 UNASSIGNED 1 0 52428800 512 NO UNASSIGNED 0 0
14 UNASSIGNED 1 0 52428800 512 NO UNASSIGNED 0 0
15 UNASSIGNED 1 0 52428800 512 YES UNASSIGNED 0 0
16 UNASSIGNED 1 0 52428800 512 YES UNASSIGNED 0 0
17 UNASSIGNED 1 0 52428800 512 YES UNASSIGNED 0 0
18 UNASSIGNED 1 0 52428800 512 YES UNASSIGNED 0 0
19 UNASSIGNED 2 0 52428800 512 NO UNASSIGNED 0 0
20 UNASSIGNED 2 0 52428800 512 NO UNASSIGNED 0 0
21 UNASSIGNED 2 0 52428800 512 NO UNASSIGNED 0 0
22 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
23 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
24 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
25 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
26 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
27 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
28 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
20 rows selected.
--//一旦主库日志切换,ARC变成NO.多次在主库切换日志后发现,把standby log全部写满:
SYS@xxxdg2> select * from v$standby_log ;
GROUP# DBID THREAD# SEQUENCE# BYTES USED ARC STATUS FIRST_CHANGE# FIRST_TIME LAST_CHANGE# LAST_TIME
------ ---------- ------- --------- ----------- ------------ --- ---------- ------------- ------------------- ------------ -------------------
9 1155815272 1 56097 52428800 1133056 NO ACTIVE 20236977651 2017-12-11 14:49:47 20237011654 2017-12-11 14:52:51
10 1155815272 1 56098 52428800 975872 NO ACTIVE 20237011654 2017-12-11 14:52:51 20237070891 2017-12-11 14:58:29
11 1155815272 1 56099 52428800 4867072 NO ACTIVE 20237070891 2017-12-11 14:58:29 20237133042 2017-12-11 15:03:45
12 1155815272 1 56100 52428800 13312 NO ACTIVE 20237133042 2017-12-11 15:03:45 20237134932 2017-12-11 15:03:51
13 1155815272 1 56101 52428800 3584 NO ACTIVE 20237134932 2017-12-11 15:03:51 20237135645 2017-12-11 15:03:56
14 1155815272 1 56102 52428800 69120 NO ACTIVE 20237135645 2017-12-11 15:03:56 20237137612 2017-12-11 15:04:03
15 1155815272 1 56103 52428800 120320 NO ACTIVE 20237137612 2017-12-11 15:04:03 20237139962 2017-12-11 15:04:15
16 1155815272 1 56104 52428800 25088 NO ACTIVE 20237139962 2017-12-11 15:04:15 20237142033 2017-12-11 15:04:26
17 1155815272 1 56105 52428800 31232 NO ACTIVE 20237142033 2017-12-11 15:04:26 20237143097 2017-12-11 15:04:34
18 1155815272 1 56106 52428800 188416 NO ACTIVE 20237143097 2017-12-11 15:04:34 20237146528 2017-12-11 15:04:51
19 UNASSIGNED 2 0 52428800 512 NO UNASSIGNED 0 0
20 UNASSIGNED 2 0 52428800 512 NO UNASSIGNED 0 0
21 UNASSIGNED 2 0 52428800 512 NO UNASSIGNED 0 0
22 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
23 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
24 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
25 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
26 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
27 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
28 UNASSIGNED 2 0 52428800 512 YES UNASSIGNED 0 0
20 rows selected.
--//注:我目前测试环境原来系统建立standby log还建立thread 2.基本不用.你可以发现主库传输过来的归档现在实际上在standby log日志中.
--//seq = 56107的日志在那里呢?
$ ls -l /u01/app/oracle/product/10.2.0/rac_db/dbs/arch*
-rw-r----- 1 oracle oinstall 3801600 2017-12-11 10:14:50 /u01/app/oracle/product/10.2.0/rac_db/dbs/arch0001_0000056075_628034536.dbf
-rw-r----- 1 oracle oinstall 464384 2017-12-11 10:14:51 /u01/app/oracle/product/10.2.0/rac_db/dbs/arch0001_0000056076_628034536.dbf
-rw-r----- 1 oracle oinstall 28266496 2017-12-11 14:50:47 /u01/app/oracle/product/10.2.0/rac_db/dbs/arch0001_0000056096_628034536.dbf
-rw-r----- 1 oracle oinstall 4608 2017-12-11 15:04:55 /u01/app/oracle/product/10.2.0/rac_db/dbs/arch0001_0000056107_628034536.dbf
-rw-r----- 1 oracle oinstall 30208 2017-12-11 15:04:58 /u01/app/oracle/product/10.2.0/rac_db/dbs/arch0001_0000056108_628034536.dbf
-rw-r----- 1 oracle oinstall 48128 2017-12-11 15:05:15 /u01/app/oracle/product/10.2.0/rac_db/dbs/arch0001_0000056109_628034536.dbf
-rw-r----- 1 oracle oinstall 52429312 2017-12-11 15:10:38 /u01/app/oracle/product/10.2.0/rac_db/dbs/arch0001_0000056110_628034536.dbf
SYS@xxxdg2> @ &r/dg/dg
PROCESS PID STATUS CLIENT_P GROUP# THREAD# SEQUENCE# BLOCK# BLOCKS DELAY_MINS
--------- ------- ---------- -------- ------- ------- --------- ------------ ------------ ------------
ARCH 9877 CONNECTED ARCH N/A 0 0 0 0 0
ARCH 9879 CONNECTED ARCH N/A 0 0 0 0 0
RFS 9922 IDLE UNKNOWN N/A 0 0 0 0 0
RFS 9913 IDLE LGWR 2 1 56110 3312 6 0
MRP0 9886 WAIT_FOR_L N/A N/A 1 56110 0 0 0
OG
--//不断执行,可以RFS进程(PID=9913),BLOCK#不断增加.实际上现在已经不是实时应用日志,而是写满了或者切换了,再应用日志.
$ ls -l /proc/9913/fd/ | grep arch
lrwx------ 1 oracle oinstall 64 2017-12-11 15:16:31 14 -> /u01/app/oracle/product/10.2.0/rac_db/dbs/arch0001_0000056110_628034536.dbf
--//查询进程的FD也可以发现现在是写入如下路径.
SYS@xxxdg2> show parameter standby_archive_dest
NAME TYPE VALUE
-------------------- ------ -----------
standby_archive_dest string ?/dbs/arch
3.总结:
--//实际上这个问题十分隐蔽,不小心可能就遗漏.
--//实际上一旦出现Using STANDBY_ARCHIVE_DEST parameter default value as ?/dbs/arch,一定要注意,一定是某个参数配置错误.
Mon Dec 11 14:44:54 2017
Completed: alter database recover managed standby database using current logfile disconnect
Mon Dec 11 14:48:45 2017
Using STANDBY_ARCHIVE_DEST parameter default value as ?/dbs/arch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Redo Shipping Client Connected as PUBLIC
4.摘抄文档:
https://docs.oracle.com/cd/E11882_01/server.112/e41134/log_arch_dest_param.htm#SBYDB01116
Usage Notes
The VALID_FOR attribute is optional. However, Oracle recommends that the VALID_FOR attribute be specified for each
redo transport destination at each database in a Data Guard configuration so that redo transport continues after a
role transition to any standby database in the configuration.
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 one of the following:
ONLINE_LOGFILE—This destination is valid only when archiving online redo log files.
STANDBY_LOGFILE—This destination is valid only when archiving standby redo log files.
ALL_LOGFILES— This destination is valid when archiving either online redo log files or standby redo log files.
The database_role keyword identifies the role in which this destination is valid for archiving:
PRIMARY_ROLE—This destination is valid only when the database is running in the primary role.
STANDBY_ROLE—This destination is valid only when the database is running in the standby role.
ALL_ROLES—This destination is valid when the database is running in either the primary or the standby role.
If you do not specify the VALID_FOR attribute for a destination, by default, archiving online redo log files and
standby redo log files is enabled at the destination, regardless of whether the database is running in the primary
or the standby role. This default behavior is equivalent to setting the (ALL_LOGFILES,ALL_ROLES) keyword pair on the
VALID_FOR attribute.
--//注:实际上你不写VALID_FOR参数,缺省就是(ALL_LOGFILES,ALL_ROLES).
The VALID_FOR attribute enables you to use the same initialization parameter file for both the primary and standby roles.
Example
The following example shows the default VALID_FOR keyword pair:
LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata VALID_FOR=(ALL_LOGFILES, ALL_ROLES)'
When this database is running in either the primary or standby role, destination 1 archives all log files to the
/disk1/oracle/oradata local directory location.
https://docs.oracle.com/cd/B19306_01/server.102/b14239/log_arch_dest_param.htm#i83986
Usage Notes
The VALID_FOR attribute is optional. However, Oracle recommends that you define a VALID_FOR attribute for each
destination so that your Data Guard configuration operates properly after a role transition.
Note:
Although the (ALL_LOGFILES,ALL_ROLES) keyword pair is the default, it is not appropriate for every destination. For
example, if the destination is a logical standby database, which is an open database that is creating its own redo data,
the redo data being transmitted by redo transport services could potentially overwrite the logical standby database's
local online redo log files.
--//还找到1个表格.奇怪11G的相对文档没有这个表格.
Table 14-2 VALID_FOR Attribute Values
VALID_FOR Definition Primary Role Physical Standby Role Logical Standby Role
--------------------------------------------------------------------------------------------
ONLINE_LOGFILE, PRIMARY_ROLE Active Inactive Invalid
ONLINE_LOGFILE, STANDBY_ROLE Inactive Invalid Active
ONLINE_LOGFILE, ALL_ROLES Active Invalid Active
STANDBY_LOGFILE, PRIMARY_ROLE Error Error Error
STANDBY_LOGFILE, STANDBY_ROLE Invalid Active Active
STANDBY_LOGFILE ALL_ROLES Invalid Active Active
ALL_LOGFILES, PRIMARY_ROLE Active Inactive Invalid
ALL_LOGFILES, STANDBY_ROLE Invalid Active Active
ALL_LOGFILES, ALL_ROLES Active Active Active
--------------------------------------------------------------------------------------------
