DBA入门之路：察微知渐细致入微

数据和云

发布于 2018-03-05 17:21:50

7640

发布于 2018-03-05 17:21:50

文章被收录于专栏：数据和云数据和云

在DBA的职业生涯中，要面临无数的艰难险阻、排忧解难，所以细致入微，严谨认真的风格必不可少。养成了察微知渐的习惯，才能在分析诊断故障时层剖缕析，直指核心；而我也一直认为，将这种习惯贯彻到学习积累之中，才能形成自己沉稳的技术根基。

我在微信群的交流中，经常看到很多人屡屡提出非常简单的问题，这些问题事实上并未超越大家的能力范畴，只要仔细阅读，稍加思考就能找到答案，我认为这就是学习方法的问题。大家应该首先找到适合自己的学习方法，然后才能在技术生涯中快速进步，提升自我。

以下是我对于一些小的案例、知识点的学习思考，与大家作为借鉴。

登录计数

在OracleDatabase 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 loginattempts）:

会话审计

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

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

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

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

SELECTTO_CHAR(current_timestamp AT TIME ZONE 'GMT',

'YYYY-MM-DD HH24:MI:SS TZD') AScurr_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用于记录审计对于数据库所有的CONNECT和DISCONNECT操作，底层表为AUD$。在Database / Grid Control中如果启用了Failed Login Count Metric监控，就可能遇到这个问题，一个建议的解决方案就是停用这个监控。

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