Oracle的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 2019 +08:00LENGTH : '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.oradb_name=calsga_target=80M
然後直接啟動到nomount階段,我們來看看效果怎麼樣。[oracle@oel1 ~]$ sqlplus / as sysdbaSQL*Plus: Release 10.2.0.3.0 - Production on Thu Oct 29 23:27:55 2019Copyright (c) 1982, 2006, Oracle. All Rights Reserved.Connected to an idle instance.SQL> startup nomountORACLE instance started.Total System Global Area 83886080 bytesFixed Size 1260216 bytesVariable Size 54527304 bytesDatabase Buffers 25165824 bytesRedo Buffers 2932736 bytes
這個時候發現 這個簡單的監控語句在nomount狀態下也是可用的,這個時候還沒有初始化數據字典,但是就是可以進行一些計算工作。SQL> select 'Oracle is alive' from dual;'ORACLEISALIVE'Oracle is alive
那麼進行一些計算怎麼樣呢?SQL> select 2+5 from dual;2+57
SQL> select decode(2,2,3) from dual;DECODE(2,2,3)---3
查看時間也沒有問題。SQL> select sysdate from dual;SYSDATE----29-OCT-19
SQL> select systimestamp from dual;SYSTIMESTAMP29-OCT-19 03.15.30.081816 PM +08:00
再來一個稍微複雜的,就是運行pl/sql看看效果。SQL> set serveroutput onSQL> begin2 for i in 1.10 loop3 dbms_output.put_line('aaaa');4 end loop;5 end;6 /aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaPL/SQL procedure successfully completed.發現這些檢查點都能夠完成,那麼這個時候動態性能視圖是不是都不能訪問了呢SQL> select count(*)from v$session;COUNT(*)11
不過對於v$datafile就不可以了。這個時候才會提示你需要mountSQL> 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表更深刻的補充:
dual表在不同的階段欄位還會發生一些微妙的變化,建議還是採用其它的數據字典吧。SQL>startup nomountSQL> select * from dual;ADDR INDX INST_ID DUM--- ---0FD69304 0 1 XSQL> alter database mount;Database altered.SQL> select *from dual;ADDR INDX INST_ID D--- -0FD69304 0 1 XSQL> alter database open;Database altered.SQL> select *from dual;D-X