oracle審計AUD$過大導致的資料庫登入異常

標籤：bytes   serve   ora   rac   策略   attribute   size   服務   tracking   

 

今天，省分技術人員反映資料庫登入異常。

 

查詢oerr，發現該錯誤是一般性提示，可能導致的原因有資料庫未註冊、本地檔案配置問題等。由於平時串連並沒有問題，是突發情況，所以排除了配置問題。

遠程登入查詢監聽，發現監聽並無問題，但在嘗試本地登入時出現ora 00020錯誤

[html] view plain copy

1. [email protected]:~> sqlplus / as sysdba  
2.   
3. SQL*Plus: Release 11.2.0.4.0 Production on Mon Apr 25 10:40:08 2016  
4.   
5. Copyright (c) 1982, 2013, Oracle.  All rights reserved.  
6.   
7. ERROR:  
8. ORA-00020: maximum number of processes (1200) exceeded  
9.   
10.   
11. Enter user-name:  

 

這說明進程數超過了資料庫設定值。嘗試在另一個節點登入則並無問題。

那麼應用應該不會出現問題才對，因為至少有一個節點是可用的。

為了尋找問題根源，我從另一台伺服器上使用輕鬆串連的方式串連節點2的執行個體，結果報ora 01653

[html] view plain copy

1. [email protected]:/myimp/aud> sqlplus yy/[email protected]:1521/xxxx  
2.   
3. SQL*Plus: Release 11.2.0.4.0 Production on Mon Apr 25 10:04:32 2016  
4.   
5. Copyright (c) 1982, 2013, Oracle.  All rights reserved.  
6.   
7. ERROR:  
8. ORA-00604: error occurred at recursive SQL level 1  
9. ORA-01653: unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM  
10. ORA-02002: error while writing to audit trail  
11. ORA-00604: error occurred at recursive SQL level 1  
12. ORA-01653: unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM  
13.   
14.   
15. Enter user-name:  

問題很明顯了，系統資料表空間應該是爆了。而aud$是審計相關。因此查詢系統資料表空間使用方式，並尋找系統資料表空間內資料量最大的表。

[html] view plain copy

1. SQL> col file_name for a50  
2. SQL> select file_name,bytes/1024/1024/1024 GB from dba_data_files where tablespace_name=‘SYSTEM‘;  
3.   
4. FILE_NAME                                                  GB  
5. -------------------------------------------------- ----------  
6. +DATADG/data/datafile/system.259.783425779         31.9726563  

 

[html] view plain copy

1. SQL> select * from (  
2.   2  select table_name,blocks*8192/1024/1024/1024 GB from user_tables where blocks is not null order by 2 desc)  
3.   3  where rownum<10;  
4.   
5. TABLE_NAME                             GB  
6. ------------------------------ ----------  
7. AUD$                           27.4380493  
8. IDL_UB1$                       .257354736  
9. WRM$_SNAPSHOT_DETAILS          .232673645  
10. WRI$_ADV_OBJECTS               .193763733  
11. HISTGRM$                       .130683899  
12. WRH$_ACTIVE_SESSION_HISTORY     .11491394  
13. WRH$_FILESTATXS                .112823486  
14. OBJ$                           .068336487  
15. SOURCE$                        .066230774  
16.   
17. 9 rows selected.  

 

可以看出，系統資料表空間已達到上限32G，且其中審計表AUD$佔了27G。

查看審計規則，可以看到Database Audit了每次的串連。

現在清楚了。新有的串連因為審計策略需要寫入系統資料表空間的AUD$表，但由於系統資料表空間已達到空間配額，資料無法寫入，導致串連失敗。

資料庫急需可用，而該表因bug問題不能用資料泵匯出，只能exp，耗時太長，因此直接truncate操作。

截斷aud$後，從節點1本地串連資料庫正常。但從B庫串連A庫節點1執行個體仍報ora 00020錯誤。查看節點1進程數

 

[html] view plain copy

1. SQL> select count(*) from v$process;  
2.   
3.   COUNT(*)  
4. ----------  
5.       1198  

 

查看參數為1200，節點2進程數為121.因此，懷疑省分配置的tnsnames.ora並未使用LB，導致所有串連只會去節點1.

目前節點1不能串連，是因為之前的串連都hung在這兒，導致串連擁堵。停掉節點一後，B庫遠程可以連到A庫。

[html] view plain copy

1. SQL> show parameter process  
2.   
3. NAME                                 TYPE        VALUE  
4. ------------------------------------ ----------- ------------------------------  
5. aq_tm_processes                      integer     1  
6. cell_offload_processing              boolean     TRUE  
7. db_writer_processes                  integer     16  
8. gcs_server_processes                 integer     6  
9. global_txn_processes                 integer     1  
10. job_queue_processes                  integer     1000  
11. log_archive_max_processes            integer     4  
12. processes                            integer     1200  
13. processor_group_name                 string  
14. SQL> select count(*) from v$process;  
15.   
16.   COUNT(*)  
17. ----------  
18.        121  

重啟後，節點1進程數降下來，可以正常串連。

oracle審計AUD$過大導致的資料庫登入異常