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补充~

猜你喜欢

转载自blog.csdn.net/cuiyan1982/article/details/79832800