DBA入門之路：察微知漸細致入微

在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連接：

如果此處AUD$表的數據量較大，就可能產生非常大量的邏輯讀，影響性能，恰恰AUD$表經常會存在大量的數據，這就是原因所在。在後續版本中，Oracle正在嚐試通過對該表進行分區，提升數據清理效率，並通過適當的索引提升訪問性能。

外一則

對於DBA_AUDIT_SESSION的各種訪問都可能遇到類似的問題，另外一則報告的問題SQL如下：

select a.CURRENT_AUDIT_SETTING, b.TOTAL_SUCC_LOGINS

 from (select value asCURRENT_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

   這段SQL在客戶環境中的執行計劃如下圖所示，類似的執行計劃和全表訪問，導致了SQL執行成本的上升，極大的影響了性能：

任何時候，我們都應當對係統的功能與SQL心存警惕，不能掉以輕心。

文章轉自數據和雲公眾號，原文鏈接