資料庫不會自己變好,只會在疏忽中悄悄變壞。頂級 DBA 與普通運維的分水嶺,在於是否建立了「標準化、可量化、可追溯」的每日巡檢體系。本文提煉 10 項每日必做核心檢查,涵蓋例項、儲存、日誌、備份、資料檔、表空間、效能、問題處理,附關鍵 SQL 與命令,可直接製成巡檢腳本或檢查表單。
| # | 檢查項目 | 關鍵動作 / SQL / 命令 | 異常閾值 / 處置原則 |
|---|---|---|---|
| 1 | 例項與進程存活 | ps -ef | grep ora_ (Linux/Unix)services.msc 檢查 OracleService | 缺失關鍵進程(SMON、PMON、DBWn、LGWR、CKPT、ARCn、MMAN、RECO、MMON、MMNL)→ 立即告警、啟動例項 |
| 2 | 檔案系統空間 | df -h (Linux/Unix)磁碟管理 / 磁碟清理 (Windows) | 剩餘 < 20% → 清理追蹤檔、核心轉儲、舊歸檔、臨時檔;必要時擴容 |
| 3 | Alert Log 與 Trace 檔錯誤 | tail -f $ORACLE_BASE/diag/rdbms/或 Enterprise Manager / ADRCI | 新增 ORA- 錯誤(特別是 ORA-00600、ORA-07445、ORA-01555、ORA-16038、ORA-27072)→ 記錄、分析、解決、追蹤至關閉 |
| 4 | 備份有效性驗證 | • RMAN: LIST BACKUP SUMMARY;、檢查第三方備份軟體日誌• EXP/EXPDP: 檢查 .log 檔「successfully completed」 • 物理備份: 校驗檔案大小、校驗和 | 備份失敗、未在備份窗口完成、備份集損壞 → 最高優先級處理,補全備份鏈 |
| 5 | 離線資料檔檢測與恢復 | SELECT file_name FROM dba_data_files WHERE status = 'OFFLINE'; | 任何 OFFLINE 檔 → 依故障類型(介質損壞/人為離線)執行 RECOVER DATAFILE / ALTER DATABASE DATAFILE ONLINE |
| 6 | 表空間使用率總覽 | | • < 10% → 立即擴容或添加資料檔 • 10-20% → 納入本周擴容計畫 • 關注 TEMP/UNDO 表空間突增 |
| 7 | 表空間碎片與最大連續空間 | | 最大連續塊 < 下一個段擴展需求 → 執行 ALTER TABLESPACE ... COALESCE 或啟用 SMON 自動合併(PCTINCREASE > 0) |
| 8 | 效能基線報告生成 | • Statspack: @?/rdbms/admin/statspack.snap → @?/rdbms/admin/spreport.sql• AWR (授權): @?/rdbms/admin/awrrpt.sql | 對比基線:DB Time、邏輯讀、物理讀、硬解析、等待事件 Top 5 → 異常趨勢啟動專項調優 |
| 9 | 系統資源佔用 | vmstat 5 5, iostat -x 5 5, top -bn1 | head -20, glance (HP-UX) | CPU 長期 > 70%、I/O await > 20ms、記憶體交換發生、網絡錯誤包率 > 1% → 關聯資料庫會話分析 |
| 10 | 當日異常問題處理記錄 | 記錄:時間、現象、影響範圍、根因、處置動作、驗證結果、預防措施 → 存入知識庫/工單系統 | 零記錄 = 零改進。每個問題都是優化檢查清單的契機 |
ANALYZE/DBMS_STATS 全庫統計資訊收集、表空間碎片整理、效能調優機會挖掘、空間規劃提案、全面狀態巡檢每日 10 項檢查,單項耗時不超 5 分鐘,全套不超 30 分鐘。但這 30 分鐘,是資料庫從「被動救火」走向「主動掌控」的分水嶺。請從今天開始,把這份清單變成你的「早安儀式」——因為穩定,不是運氣,是紀律。