oracle审计AUD$过大导致的数据库登录异常

 

今天,省分技术人员反映数据库登录异常。

 

查询oerr,发现该错误是一般性提示,可能导致的原因有数据库未注册、本地文件配置问题等。由于平时连接并没有问题,是突发情况,所以排除了配置问题。

远程登录查询监听,发现监听并无问题,但在尝试本地登录时出现ora 00020错误

  1. oracle@dxxxx:~> 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

  1. oracle@xxxx:/myimp/aud> sqlplus yy/yy@node2: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$是审计相关。因此查询系统表空间使用情况,并查找系统表空间内数据量最大的表。

  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  

 

  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。

查看审计规则,可以看到数据库审计了每次的连接。

现在清楚了。新有的连接因为审计策略需要写入系统表空间的AUD$表,但由于系统表空间已达到空间配额,数据无法写入,导致连接失败。

数据库急需可用,而该表因bug问题不能用数据泵导出,只能exp,耗时太长,因此直接truncate操作。

截断aud$后,从节点1本地连接数据库正常。但从B库连接A库节点1实例仍报ora 00020错误。查看节点1进程数

 

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

 

查看参数为1200,节点2进程数为121.因此,怀疑省分配置的tnsnames.ora并未使用LB,导致所有连接只会去节点1.

目前节点1不能连接,是因为之前的连接都hung在这儿,导致连接拥堵。停掉节点一后,B库远程可以连到A库。

  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进程数降下来,可以正常连接。

posted @ 2018-01-03 13:09  lclc  阅读(1113)  评论(1编辑  收藏  举报