eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« Oracle自动存储管理 ASMLib的支持变化 | Blog首页 | DBA手记:OEM罪几何?-空间监控的性能问题 »

DBA手记:Failed Login Count带来的性能问题

这是《Oracle DBA手记II》一书的内容连载,我将抽时间将以前所写过的一些书上的内容转引出来。

在《Oracle DBA手记 I》中,最后一则案例中,曾经提到关于Failed Login Count的问题,简要的引用一下用来承前启后。

Oracle Database 10g中,默认的用户管理上有个小的改进,就是对默认的失败登录次数的限制,用户的PROFILE中,FAILED_LOGIN_ATTEMPTS设置口令失败尝试次数为10,如果连续进行了10次口令失败的登录尝试,用户账号将被锁定。

SQL> select * from dba_profiles where resource_name=' FAILED_LOGIN_ATTEMPTS';

PROFILE          RESOURCE_NAME                    RESOURCE LIMIT

---------------- -------------------------------- -------- ------------------------------

DEFAULT          FAILED_LOGIN_ATTEMPTS            PASSWORD 10

那么这里的10次登陆失败计数是如何完成的呢?查看底层表USER$的字段,其中LCOUNT字段就是用来完成这个功能的:

SQL> desc user$

 Name                          Null?    Type

 ----------------------------- -------- --------------------

 USER#                         NOT NULL NUMBER

 NAME                          NOT NULL VARCHAR2(30)

 TYPE#                         NOT NULL NUMBER

 PASSWORD                               VARCHAR2(30)

 DATATS#                       NOT NULL NUMBER

 TEMPTS#                       NOT NULL NUMBER

DEFROLE                       NOT NULL NUMBER

 DEFGRP#                                NUMBER

 DEFGRP_SEQ#                            NUMBER

 ASTATUS                       NOT NULL NUMBER

 LCOUNT                        NOT NULL NUMBER

。。。。。。。。

可以通过sql.bsq文件来进一步确认,这个文件提示lcount正是失败的登录尝试计数(count of failed login attempts:

dbanb201.png

在最近的一次客户数据库性能优化中,再次遇到了类似的一个案例。这是一个Oracle Database 11g 11.1.0.6的数据库环境:

dbanb202.png

在这个数据库的SQL ordered by Gets诊断中,发现了一条可疑的SQL,如下图所示,这个SQL的逻辑读排在第三位,占整体数据库逻辑读的14.23%,其SQL Module: Oracle Enterprise Manager.Metric Engine

dbanb203.png

在这里我想强调一点的是,很多时候DBA在遇到数据库系统自身调用的内部SQL时,常常下意识的选择回避,认为数据库的自身功能不会存在太大的问题,而事实往往相反。我的一个座右铭是,决不放过任何一句可疑的SQL代码。这里的Module显示,该SQLOEMMetric引擎发起的,一个数据库的内部功能在任何时候都不应该消耗大量的系统资源。

格式化一下该SQL代码得到如下完整输出:

SELECT TO_CHAR(current_timestamp AT TIME ZONE 'GMT',

               'YYYY-MM-DD HH24:MI:SS TZD') AS curr_timestamp,

       COUNT(username) AS failed_count

  FROM sys.dba_audit_session

 WHERE returncode != 0

   AND TO_CHAR(timestamp, 'YYYY-MM-DD HH24:MI:SS') >=

       TO_CHAR(current_timestamp - TO_DSINTERVAL('0 0:30:00'), 'YYYY-MM-DD HH24:MI:SS')

从这段代码可以看到,该SQL是用于监控和计算失败登陆次数(failed_count)的,这一监控结果可以在某用户发生失败登陆尝试时给出告警。这里的DBA_AUDIT_SESSION用于记录审计对于数据库所有的CONNECTDISCONNECT操作,底层表为AUD$。在Database / Grid Control中如果启用了Failed Login Count Metric监控,就可能遇到这个问题,一个建议的解决方案就是停用这个监控。

但是为什么会出现这样的问题呢?检查这个SQL的执行计划,可以发现一些端倪,如下图所示,对于AUD$表的访问出现了一个全表扫描,然后进行NESTED LOOPS OUTER连接:

dbanb204.png

如果此处AUD$表的数据量较大,就可能产生非常大量的逻辑读,影响性能,恰恰AUD$表经常会存在大量的数据,这就是原因所在。在新版本中,Oracle正在尝试通过对该表进行分区,提升数据清理效率,并通过适当的索引提升访问性能。

对于DBA_AUDIT_SESSION的各种访问都可能遇到类似的问题,另外一则报告的问题SQL如下:

select a.CURRENT_AUDIT_SETTING, b.TOTAL_SUCC_LOGINS

  from (select value as CURRENT_AUDIT_SETTING

          from v$parameter

         where name = 'audit_trail') a,

       (select count(*) as TOTAL_SUCC_LOGINS

          from dba_audit_session

         where (action_name = 'LOGON' and returncode = 0 or

               action_name like 'LOGOFF%')

           and timestamp > EMIP_BIND_START_DATE

           and timestamp < EMIP_BIND_END_DATE) b

这段SQL在客户环境中的执行计划如下图所示,类似的执行计划和全表访问,导致了SQL执行成本的上升,极大的影响了性能:

dbanb205.png

任何时候,我们都应当对系统的功能与SQL心存警惕,不能掉以轻心。



历史上的今天...
    >> 2008-02-18文章:
    >> 2006-02-18文章:
           涛声帆影 崖门曾战酣
    >> 2005-02-18文章:

无觅

By eygle on 2011-02-18 10:31 | Comments (1) | Case | SQL.PLSQL | 2730 |

1 Comment

心思够缜密的,学习受教了


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com