STATUS of v$archive_dest的一些情况
原文地址：http://blog.itpub.net/15415488/viewspace-594659/
关于admin guide中v$archive_dest的status这一列有好7种值，文档说得太抽象，于是本文做了一部分实验来看看这些值到底在什么情况下会显示。
VALID -- The user has properly initialized the destination, which is available for archiving.
INACTIVE -- The user has not provided or has deleted the destination information.
ERROR -- An error occurred creating or writing to the destination file; refer to error data.
FULL -- Destination is full (no disk space).
DEFERRED -- The user manually and temporarily disabled the destination.
DISABLED -- The user manually and temporarily disabled the destination following an error; refer to error data.
BAD PARAM -- A parameter error occurred; refer to error data.
另外还有一种ALTERNATE 的status。
-------TEST begins----------
1.VALID很好理解，就是这个归档路径被申明了，并且有效。
mkdir -p /oracle/DDS/data01/haozhu/archive/tmp/
SQL> alter system set log_archive_dest_2='location=/oracle/DDS/data01/haozhu/archive/tmp/';
System altered.
SQL> select STATUS from v$archive_dest where DEST_ID=2;
STATUS
---------------------------
VALID
2.INACTIVE就是如文档所示，用户没有申明log_archive_dest_N,或者删除了log_archive_dest_N的信息。注意，这里并不是指删除了log_archive_dest_N所对应的文件路径。于是又两种情况会造成INACTIVE。
SQL> select distinct STATUS from v$archive_dest where DESTINATION is null;
STATUS
---------------
INACTIVE
我本来有一个alternate的归档目录log_archive_dest_2，当把它的信息删除后，status就成为INACTIVE了：
SQL> show parameter log_archive_dest_2
NAME TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------------------------------------------------------------------
log_archive_dest_2 string
location=/oracle/DDS/data01/haozhu/archive2/
SQL> select status from v$archive_dest where DEST_NAME='LOG_ARCHIVE_DEST_2';
STATUS
---------------------------
ALTERNATE
SQL> alter system set log_archive_dest_2='';
System altered.
SQL> select status from v$archive_dest where DEST_NAME='LOG_ARCHIVE_DEST_2';
STATUS
---------------------------
INACTIVE
3.ERROR 就是指oracle在开始归档时，对这个归档路径进行归档发生了一些错误。
如果你只是删除了某个归档目录，而oracle在此之后并没有进行归档，那么它不会发现这个目录是不是有存在。
所以ERROR都是在真正归档的时刻将问题暴露出来，并不表明此刻问题才发生。
SQL> alter system set log_archive_dest_2='location=/oracle/DDS/data01/haozhu/archive/tmp/';
System altered.
SQL> select STATUS from v$archive_dest where DEST_ID=2;
STATUS
---------------------------
VALID
rmdir tmp
SQL> select STATUS from v$archive_dest where DEST_ID=2;
STATUS
---------------------------
VALID
SQL> alter system switch logfile;
System altered.
SQL> select STATUS from v$archive_dest where DEST_ID=2;
STATUS
---------------------------
ERROR
alert log:
Errors in file /oracle/DDS/data01/haozhu/bdump/haozhu_arc0_7091.trc:
ORA-07286: sksagdi: cannot obtain device information.
SVR4 Error: 2: No such file or directory
Sat May 9 20:57:45 2009
Cannot translate archive destination string 'LOG_ARCHIVE_DEST_2'
重建这个目录，并不能使其成为VALID：
mkdir tmp
SQL> alter system switch logfile;
System altered.
SQL> select STATUS from v$archive_dest where DEST_ID=2;
STATUS
---------------------------
ERROR
再次申明这个目录或者alter system set log_archive_dest_state_N=enable;才可以使其成为VALID：
SQL> alter system set log_archive_dest_2='location=/oracle/DDS/data01/haozhu/archive/tmp/';
System altered.
SQL> select STATUS from v$archive_dest where DEST_ID=2;
STATUS
---------------------------
VALID
再模拟另一种error，即将归档路径身为read only（chmod 444 tmp）：
SQL> alter system switch logfile;
System altered.
SQL> select STATUS from v$archive_dest where DEST_ID=2;
STATUS
---------------------------
ERROR
alert log:
ORA-19504: failed to create file "/oracle/DDS/data01/haozhu/archive/tmp/haozhu_111.1_685267645_arc"
ORA-27037: unable to obtain file status
SVR4 Error: 13: Permission denied
如果直接enable这个归档路径，但是这个归档路劲其实仍然是只读的，但在下一次归档发生之前，oracle会暂时认为它的status是VALID的：
SQL> alter system set log_archive_dest_state_2=enable;
System altered.
SQL> select STATUS from v$archive_dest where DEST_ID=2;
STATUS
---------------------------
VALID
4.FULL很容易理解，就是这个归档路径mount point满了。但是有谁真正试过么？
我的环境有限，但是在测试机器上试了一把，发现当mount point满了时，显示的是ERROR而非FULL。
当然我没有在其他平台测试过，说不定不一样。我的测试平台是Oralce 10203 @ Solaris10 @ sparc
df -h|grep data04
107G 107G 0K 100% /oracle/DDS/data04
SQL> alter system set log_archive_dest_3='location=/oracle/DDS/data04/';
System altered.
SQL> select status from v$archive_dest where DEST_NAME='LOG_ARCHIVE_DEST_3';
STATUS
---------------------------
VALID
SQL> alter system switch logfile;
System altered.
SQL> select status,error from v$archive_dest where DEST_NAME='LOG_ARCHIVE_DEST_3';
STATUS
---------------------------
ERROR
----------------------------------------------------------------------------------------------------------------------------------
ERROR
ORA-19504: failed to create file ""
alert log:
Errors in file /oracle/DDS/data01/haozhu/bdump/haozhu_arc0_7091.trc:
ORA-19504: failed to create file "/oracle/DDS/data04/haozhu_144.1_685267645_arc"
ORA-27044: unable to write the header block of file
SVR4 Error: 28: No space left on device
5.DEFERRED就是指用户手动关掉了这个归档目录。如何手动关掉？这个是由log_archive_dest_state_N控制的。
关掉这个目录的归档后，oracle不会再往里写归档日志了。
From refrence：
--defer
--Specifies that valid destination information and attributes are preserved,
--but the destination is excluded from archiving operations until re-enabled
SQL> alter system set log_archive_dest_state_2=defer;
System altered.
SQL> select STATUS from v$archive_dest where DEST_ID=2;
STATUS
---------------------------
DEFERRED
6.DISABLED的官方解释和DEFRRED很像，但是多了半句话“following an error; refer to error data”。
我测出的情况中，当一个拥有ALTERNATE的归档路径的归档路径出现ERROR之后，并且ENABLE了它的ALTERNATE归档路径之后，它自身变成DISABLED，而它的ALTERNATE的归档路径变成VALID。
在测试之前，我们需要测试什么情况下ALTERNATE的归档路径能够代替掉原来的路径呢？需要如何设置？
这里需要注意的是REOPEN参数如果你没有显式申明的话，那么它的默认值是300秒。当出错的情况发生后，oracle每300秒去检测一下这个路径。
跟REOPEN参数相关的另一个参数是MAX_FAILURE，它的默认值是0，也就是永远不会disable掉这个归档路径，无论发生了多少次ERROR在这上面。
所以，当我们需要使用ALTERNATE的归档路径，要么申明NOREOPEN，要么申明REOPEN和MAX_FAILURE到一个你可以接受的值。
只有当原来的归档路径在经历了你指定的若干次ERROR后，被disable掉后，它所对应的ALTERNATE归档路径开始生效，作为替代路径。
From refrence:
--alternate
--Specifies that a log archive destination is not enabled
--but will become enabled if communications to another destination fail.
SQL> alter system set log_archive_dest_state_2=alternate;
System altered.
#给dest1指明noreopen，这样一旦出错，立马enable dest2.
SQL> alter system set log_archive_dest_1='location=/oracle/DDS/data01/haozhu/archive/ alternate=log_archive_dest_2 noreopen';
System altered.
SQL> select STATUS from v$archive_dest where DEST_ID<=2;
STATUS
---------------------------
VALID
ALTERNATE
chmod 444 archive --这里将log_archive_dest_1的目录设为只读
SQL> alter system switch logfile;
System altered.
SQL> select STATUS from v$archive_dest where DEST_ID<=2;
STATUS
---------------------------
DISABLED
VALID
#重新chmod 777 archive,并且再次将dest1 enable，讲dest2设为alternate，来做第二次试验。
#这里设置reopen=1和max_failure=5，表明如果出错则每秒都检测一次dest1，如果一共出现5次error，则enable dest2
SQL> alter system set log_archive_dest_1='location=/oracle/DDS/data01/haozhu/archive/ alternate=log_archive_dest_2 reopen=1 max_failure=5';
System altered.
chmod 444 archive
SQL> alter system switch logfile;
System altered.
#这时虽然dest1已经出错，但是dest2还没有立即enable
SQL> /
STATUS
---------------------------
ERROR
ALTERNATE
#在alertlog里，当出现了五次这样的error后，dest2才成为valid，而dest1才disable
ARC1: Error 19504 Creating archive log file to '/oracle/DDS/data01/haozhu/archive/haozhu_135.1_685267645_arc'
SQL> /
STATUS
---------------------------
DISABLED
VALID
7.BAD PARAM这种情况我还没有模拟出来，因为错误的log_archive_dest_N参数根本就写不进oracle。
然而我在网上找到了两则案例，其中提到了这个情况。都是跟配置dataguard出错相关。
而且很具代表性，因为第一则情况BAD PARAM发生在从库上，第二则发生在主库上。
第一则：http://www.itpub.net/thread-1054909-1-1.html
作者配置dataguard时，在从库上设置DG_CONFIG时出错，导致了：
haozhu oracle@qadb27:/oracle/DDS/archive > oerr ora 16053
16053, 00000, "DB_UNIQUE_NAME %s is not in the Data Guard Configuration"
// *Cause: The specified DB_UNIQUE_NAME is not in the Data Guard
// Configuration.
// *Action: If the DG_CONFIG attribute of the LOG_ARCHIVE_CONFIG parameter
// is enabled, you must specify a valid DB_UNIQUE_NAME. The list
// of valid DB_UNIQUE_NAMEs can be seen with the V$DATAGUARD_CONFIG
// view. This problem can also occur when specifying a non-standby
// destination with an DB_UNIQUE_NAME attribute that does not match
// the DB_UNIQUE_NAME initialization parameter for the current
// instance.
第二则：http://www.itpub.net/thread-709839-1-1.html
作者设置了DG_CONFIG，但是主库的log_archive_dest_2缺少了DB_UNIQUE_NAME,导致了：
haozhu oracle@qadb27:/oracle/DDS/archive > oerr ora 16052
16052, 00000, "DB_UNIQUE_NAME attribute is required"
// *Cause: The DB_UNIQUE_NAME attribute is required when DG_CONFIG is enabled.
// *Action: Use the DB_UNIQUE_NAME attribute to specify a valid Data Guard
// Name for the destination. The list of valid DB_UNIQUE_NAMEs can
// be seen with the V$DATAGUARD_CONFIG view.
以上7点tips其实包括了status of v$archive_dest的八种值的实际发生的例子的情况。
肯定还有其他情况，欢迎其他XDJM补充~