由dual导致的一个潜在的监控问题

Oracle对于sys用户的审计是默认的操作，所以不管你开启了什么审计策略，sys的登录等操作都会记录下来，这也是Oracle的默认配置，可能他们也没有料到有些应用可能把这个影响放大，毕竟频繁登录sys听起来是不现实的。但是放到自动化监控的部分，这个影响就会放大，可能有些功能还不够严谨，存在一定的问题。
比如下面的这个场景，发现在审计目录下存在着一些细小的文件，生成时间也很紧凑，可见还是有一些操作很频繁的使用了sys,而且生成了意料之外的大批量审计日志文件。
$  ls -lrt|head -5
-rw-r-----. 1 oracle oinstall 1717 Oct 29 23:01 statdb1_ora_6057_b.aud
-rw-r-----. 1 oracle oinstall 3609 Oct 29 23:01 statdb1_ora_6085_12.aud
-rw-r-----. 1 oracle oinstall 2390 Oct 29 23:01 statdb1_ora_6126_13.aud
-rw-r-----. 1 oracle oinstall 1579 Oct 29 23:01 statdb1_ora_8395_16.aud
$ pwd
/U01/app/oracle/admin/statdb1/adump
我们打开一个审计日志文件，可以看到是通过操作系统用户认证登录以后，做了一个简单的查询，通过语句可以猜出其实是在做一个判断，判断数据库实例是否可用。
Thu Oct 29 23:02:03 2015 +08:00
LENGTH : '183'
ACTION :[34] 'select 'Oracle is alive' from dual'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[0] ''
STATUS:[1] '0'
DBID:[10] '2677618732'

这个监控的目的就是如果实例可访问就返回 Oracle is alive，否则就报警。可能在大批量的服务器环境中还是会有这样的使用场景，需要在很短的时间间隔里去判断哪些数据库实例可能存在问题。
听起来还是可以接受的，如果审计日志文件太多，还可以定期清理。
那么这个监控语句对不对呢。
我们来做一个简单的实验来验证。我来把数据库用最少的参数启动到Nomount阶段，这个时候数据库实例其实还是不可用的，看看这个监控语句是否可用。
首先就是最简单的参数文件。就配置了两个参数
[oracle@oel1 dbs]$ cat initcal.ora
db_name=cal
sga_target=80M
然后直接启动到nomount阶段，我们来看看效果怎么样。
[oracle@oel1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.3.0 - Production on Thu Oct 29 23:27:55 2015
Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
Connected to an idle instance.
SQL> startup nomount
ORACLE instance started.
Total System Global Area   83886080 bytes
Fixed Size                  1260216 bytes
Variable Size              54527304 bytes
Database Buffers           25165824 bytes
Redo Buffers                2932736 bytes
这个时候发现 这个简单的监控语句在nomount状态下也是可用的，这个时候还没有初始化数据字典，但是就是可以进行一些计算工作。
SQL> select 'Oracle is alive' from dual;
'ORACLEISALIVE'
---------------
Oracle is alive
那么进行一些计算怎么样呢？
SQL> select 2+5 from dual;
       2+5
----------
         7
SQL> select decode(2,2,3) from dual;
DECODE(2,2,3)
-------------
            3
查看时间也没有问题。
SQL> select sysdate from dual;
SYSDATE
---------
29-OCT-15
SQL> select systimestamp from dual;
SYSTIMESTAMP
---------------------------------------------------------------------------
29-OCT-15 03.15.30.081816 PM +08:00
再来一个稍微复杂的，就是运行pl/sql看看效果。
SQL> set serveroutput on
SQL> begin
  2  for i in 1..10 loop
  3  dbms_output.put_line('aaaa');
  4  end loop;
  5  end;
  6  /
aaaa
aaaa
aaaa
aaaa
aaaa
aaaa
aaaa
aaaa
aaaa
aaaa
PL/SQL procedure successfully completed.
发现这些检查点都能够完成，那么这个时候动态性能视图是不是都不能访问了呢
SQL> select count(*)from v$session;
  COUNT(*)
----------
        11
不过对于v$datafile就不可以了。这个时候才会提示你需要mount
SQL> select name from v$datafile;
select name from v$datafile
                 *
ERROR at line 1:
ORA-01507: database not mounted

所以通过这个细小的案例还是发现，其实监控的一些指标参数还是需要斟酌，如果做数据库是否可用的检查验证，使用了select 'Oracle is alive'的方式验证，那么可能数据库还没到open阶段，通过这个语句就“验证”数据库服务已经OK了，这种情况还是很容易造成误导。还是需要好好注意一下，使用dual来做监控还是存在一定的隐患。
来一个更深刻的例子。dual表在不同的阶段字段还会发生一些微妙的变化。还是采用其它的数据字典吧。
SQL>startup nomount
SQL> select * from dual;
ADDR           INDX    INST_ID DUM
-------- ---------- ---------- ---
0FD69304          0          1 X
SQL> alter database mount;
Database altered.
SQL> select *from dual；
ADDR           INDX    INST_ID D
-------- ---------- ---------- -
0FD69304          0          1 X
SQL> alter database open;
Database altered.
SQL> select *from dual;
D
-
X