データベースがオープンしない / 到達不能

症状

サービスに接続できない、'connection refused'、インスタンスが起動しない、リスナーが応答しない。

1. どこで壊れているか: ネットワーク、サービス、インスタンス

サーバーに到達できるか (ping/ssh)。DB プロセス/サービスは動作しているか (ps/systemctl/services.msc)。ポートはリッスンしているか (ss -ltnp / telnet host port)。これで問題をネットワーク / サービス / データベースインスタンスのいずれかの層に特定する。

2. サービスとリスナーを確認する

DB プロセスが起動していなければ起動を試みる。起動しているのに接続が失敗する場合は、リスナー/ポートと認証層を確認する。

Oracle

-- OS: lsnrctl status  (listener)
-- SQL*Plus: STARTUP;  (if the instance is down)
SELECT status FROM v$instance;

PostgreSQL

-- OS: systemctl status postgresql ; pg_isready -h host
-- Logs: the last lines tell why it did not start

MySQL

-- OS: systemctl status mysqld ; mysqladmin ping

SQL Server

-- Services / SQL Server Configuration Manager; SQL Server Error Log

Redis

redis-cli ping  # expect PONG

3. ログを読む — 答えはそこにある

DB がオープンしない場合、理由はログに書かれている: alert log (Oracle)、postgresql.log / 起動ログ、mysqld エラーログ、SQL Server ERRORLOG、redis ログ。ディスクフル、ファイルの破損、権限、ポートの競合、ファイルの欠落 — すべてここに現れる。

4. 一般的な原因に対処する: ディスク、権限、ポート、破損

ディスクが 100% 満杯ではないか (最も一般的な原因)。データディレクトリの権限が壊れていないか。ポートが別のプロセスに使われていないか。(クラッシュ後に) リカバリが必要か。制御ファイル/redo ログが破損していないか。ログのメッセージに基づき、それぞれに対処する。

5. 復旧し、インシデント記録を残す

クラッシュリカバリは通常自動で完了するので、辛抱強く待つ。破損がある場合はバックアップ/PITR から復旧する (破損プレイブックを参照)。その後、根本原因分析 (RCA) を書く: 何が起きたか、なぜか、再発をどう防ぐか。