데이터베이스가 열리지 않음 / 접속 불가

증상

서비스에 연결할 수 없고, 'connection refused', 인스턴스가 시작되지 않으며, listener가 응답하지 않는다.

1. 어디서 끊기는가: 네트워크, 서비스, 인스턴스

서버에 도달할 수 있는가(ping/ssh)? DB 프로세스/서비스가 실행 중인가(ps/systemctl/services.msc)? 포트가 listening 상태인가(ss -ltnp / telnet host port)? 이로써 문제를 네트워크 / 서비스 / 데이터베이스 인스턴스 중 한 계층으로 좁힌다.

2. 서비스와 listener를 확인한다

DB 프로세스가 올라와 있지 않으면 시작을 시도한다. 올라와 있는데 연결이 실패하면 listener/포트와 인증 계층을 확인한다.

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 / startup, mysqld error log, SQL Server ERRORLOG, redis log. 디스크 가득 참, 손상된 파일, 권한, 포트 충돌, 누락 파일 — 모두 여기에 나타난다.

4. 흔한 원인을 처리한다: 디스크, 권한, 포트, 손상

디스크가 100% 찼는가(가장 흔한 원인)? 데이터 디렉터리 권한이 깨졌는가? 다른 프로세스가 포트를 점유했는가? (장애 후) 복구가 필요한가? 컨트롤 파일/redo log가 손상되었는가? 로그 메시지에 따라 각각을 처리한다.

5. 복구하고 장애 기록을 남긴다

crash recovery는 대개 자동으로 완료되므로 기다린다. 손상이 있으면 백업/PITR로 복구한다(데이터 손상 플레이북 참조). 이후 근본 원인 분석(RCA)을 작성한다: 무슨 일이 왜 일어났고 재발을 어떻게 막을지.