Oracle 11g 審計功能實戰：快速定位導致帳號鎖定的失敗登入來源

前言

在 Oracle 11g 資料庫中，預設啟用了對登入/登出操作的審計。當使用者帳號因密碼錯誤次數過多而被鎖定時，善用審計功能可快速追蹤來源主機與用戶，協助 DBA 精準定位問題根因。本文將透過實際案例，示範如何查詢審計軌跡找出導致帳號鎖定的失敗連線。

背景知識：FAILED_LOGIN_ATTEMPTS 參數

使用者設定檔中的 FAILED_LOGIN_ATTEMPTS 參數預設值為 10，意即連續 10 次輸入錯誤密碼即會鎖定帳號。失敗次數記錄於 USER$ 表的 lcount 欄位，預設為 0，失敗一次加 1，成功登入則歸零。生產環境常依需求調整此參數，設為 UNLIMITED 可防帳號被鎖，但也失去防禦暴力破解的能力，需權衡利弊。

實戰查詢：找出登入失敗的來源

Oracle 11g 預設審計 LOGON/LOGOFF 操作，失敗登入的錯誤碼為 1017 (ORA-01017)。查詢 DBA_AUDIT_TRAIL 即可統計失敗來源：

SELECT os_username, userhost, terminal, username, COUNT(*)
FROM dba_audit_trail
WHERE returncode = 1017
GROUP BY os_username, userhost, username, terminal;

查詢結果範例

上例顯示同一作業系統用戶從同一主機嘗試不同資料庫帳號登入失敗，疑似為應用程式設定錯誤或自動化腳本密碼過期所致。

關鍵風險提示：高頻登入導致 Row Cache Lock

若資料庫 LOGON PER SECOND 極高，且應用程式設定檔密碼錯誤導致短時間大量會話嘗試登入，可能引發頻繁的 dc_users 字典快取鎖，造成用戶無法登入甚至整個實例 Hang 住。此問題可參考 Maclean Liu 的部落格分析：Row Cache lock Problem。

總結

善用 11g 內建審計功能，配合 DBA_AUDIT_TRAIL 查詢 returncode=1017，能快速鎖定導致帳號鎖定的來源主機與程式，是 DBA 排查登入問題的利器。同時需注意 FAILED_LOGIN_ATTEMPTS 設定與高頻登入帶來的字典鎖風險，做好預防與監控。