Troubleshooting

Oracle/MariaDB 상태 점검 가이드

Oracle과 MariaDB 상태 점검을 서비스, 접속, 세션, 락, 저장공간, 오류 로그, 백업 검증, 복제 상태 기준으로 나누어 정리한 운영 가이드입니다.

devmes

• 조회 114

Oracle과 MariaDB 상태 점검은 단순히 프로세스가 떠 있는지만 보는 작업이 아닙니다. 서비스 기동 상태, 접속 가능 여부, 세션/락, 저장공간, 오류 로그, 백업 검증, 복제 상태까지 나누어 확인해야 실제 운영 장애를 놓치지 않습니다. Oracle과 MariaDB를 각각 운영 점검 관점에서 볼 수 있도록 명령과 SQL을 분리해 정리합니다.

공통 점검 순서

  1. OS에서 DB 프로세스와 포트가 살아 있는지 확인합니다.
  2. DB 클라이언트로 실제 접속이 되는지 확인합니다.
  3. 인스턴스 상태, 세션, 락, 저장공간, 오류 로그를 확인합니다.
  4. 백업 또는 논리/물리 검증 명령은 운영 부하를 고려해 수행합니다.
  5. 복제나 클러스터 구성이 있으면 primary/replica 역할과 지연 시간을 따로 확인합니다.

Oracle 점검

1. OS 프로세스와 리스너 확인

ps -ef | egrep 'pmon|tnslsnr' | grep -v grep
lsnrctl status

ora_pmon_<SID> 프로세스가 보이면 해당 SID의 Oracle 인스턴스가 떠 있는 것입니다. 리스너가 떠 있어도 DB 인스턴스가 down이면 애플리케이션 접속은 실패할 수 있으므로 둘을 따로 봅니다.

2. SQL*Plus 접속과 기본 상태

sqlplus / as sysdba
SET LINESIZE 200
SET PAGESIZE 100

SELECT banner FROM v$version;
SELECT instance_name, host_name, status, database_status, startup_time FROM v$instance;
SELECT name, open_mode, database_role, log_mode FROM v$database;

v$instance.status가 OPEN인지, v$database.open_mode가 READ WRITE 또는 의도한 standby 상태인지 확인합니다.

3. Tablespace 사용률

SELECT
 df.tablespace_name,
 ROUND(df.bytes / 1024 / 1024) AS total_mb,
 ROUND((df.bytes - NVL(fs.bytes, 0)) / 1024 / 1024) AS used_mb,
 ROUND(NVL(fs.bytes, 0) / 1024 / 1024) AS free_mb,
 ROUND((df.bytes - NVL(fs.bytes, 0)) / df.bytes * 100, 2) AS used_pct
FROM
 (SELECT tablespace_name, SUM(bytes) bytes FROM dba_data_files GROUP BY tablespace_name) df
 LEFT JOIN (SELECT tablespace_name, SUM(bytes) bytes FROM dba_free_space GROUP BY tablespace_name) fs
 ON df.tablespace_name = fs.tablespace_name
ORDER BY used_pct DESC;

사용률이 높다고 바로 datafile을 늘리기보다 autoextend 설정, filesystem/ASM 여유 공간, 증가 추이를 같이 확인합니다.

4. 세션과 락 확인

SELECT username, status, COUNT(*) AS sessions
FROM v$session
WHERE username IS NOT NULL
GROUP BY username, status
ORDER BY sessions DESC;

SELECT
 s.sid,
 s.serial#,
 s.username,
 s.status,
 s.event,
 s.seconds_in_wait,
 s.blocking_session
FROM v$session s
WHERE s.blocking_session IS NOT NULL
ORDER BY s.seconds_in_wait DESC;

blocking session이 있으면 바로 kill하기 전에 어떤 SQL과 업무 배치가 잡고 있는지 확인합니다.

SELECT s.sid, s.serial#, s.username, q.sql_text
FROM v$session s
JOIN v$sql q ON s.sql_id = q.sql_id
WHERE s.sid = <SID>;

5. Alert log 확인

adrci exec="show homes"
adrci exec="set homepath diag/rdbms/<db_name>/<instance_name>; show alert -tail 100"

Alert log에서는 ORA-, checkpoint 지연, archiver 오류, datafile 오류, listener registration 문제를 중점적으로 봅니다.

6. DBVERIFY와 RMAN 검증

dbv file=/path/to/datafile.dbf
rman target /
RUN {
 ALLOCATE CHANNEL ch1 TYPE DISK;
 BACKUP VALIDATE CHECK LOGICAL DATABASE;
 RELEASE CHANNEL ch1;
}

RMAN validate는 운영 DB에 I/O 부하를 줄 수 있으므로 업무 피크 시간에는 피하고, 백업 정책과 함께 정기적으로 검증하는 방식이 좋습니다.

MariaDB 점검

1. 서비스와 포트 확인

systemctl status mariadb --no-pager
ss -tnlp | grep -E ':3306\\b'
mysqladmin -u root -p ping

mysqld is alive가 나오면 프로세스와 기본 접속은 되는 상태입니다. 다만 애플리케이션 계정 권한 문제, 특정 DB lock, replication 지연은 별도로 확인해야 합니다.

2. 기본 상태와 접속 수

mysqladmin -u root -p status
mysqladmin -u root -p processlist
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';
SHOW VARIABLES LIKE 'max_connections';
SHOW FULL PROCESSLIST;

운영 스크립트에서 비밀번호를 명령줄에 직접 넣으면 프로세스 목록이나 쉘 히스토리에 노출될 수 있습니다. 자동화가 필요하면 socket 인증 또는 root-only 권한의 option file을 우선 검토하고, 민감값은 공개 문서나 Git 저장소에 남기지 않습니다.

sudo install -m 600 /dev/null /root/.my.cnf
sudo vi /root/.my.cnf
[client]
user=root
socket=/var/lib/mysql/mysql.sock
mysqladmin --defaults-extra-file=/root/.my.cnf status

비밀번호 인증이 필요한 환경에서는 클라이언트가 prompt로 입력받게 하거나, 운영 환경의 secret 관리 절차에 맞춰 별도 주입합니다.

3. DB 크기와 테이블 상태

SELECT
 table_schema,
 ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
GROUP BY table_schema
ORDER BY size_mb DESC;
mysqlcheck -u root -p --check --all-databases
mysqlcheck -u root -p --check database_name table_name

mysqlcheck --repair는 스토리지 엔진과 장애 상황에 따라 위험할 수 있습니다. 특히 InnoDB에서는 무작정 repair를 실행하지 말고 백업, 오류 로그, 테이블스페이스 상태를 먼저 확인합니다.

4. InnoDB 상태와 lock 확인

SHOW ENGINE INNODB STATUS\\G

SELECT * FROM information_schema.innodb_trx\\G
SELECT * FROM information_schema.innodb_lock_waits\\G

SHOW ENGINE INNODB STATUS에서는 deadlock, row lock wait, buffer pool, checkpoint age를 확인합니다. DB가 느릴 때는 CPU보다 lock wait이 원인인 경우가 많습니다.

5. Replication 사용 시 확인

SHOW SLAVE STATUS\\G

MariaDB 버전에 따라 replica 용어와 명령이 달라질 수 있습니다. 기존 환경에서는 SHOW SLAVE STATUS\G가 많이 쓰이며, 확인 포인트는 다음과 같습니다.

  • Slave_IO_Running과 Slave_SQL_Running이 모두 Yes인지 확인합니다.
  • Seconds_Behind_Master가 계속 증가하면 복제 지연입니다.
  • Last_IO_Error, Last_SQL_Error에 오류가 있는지 확인합니다.

6. 오류 로그 확인

journalctl -u mariadb --since "1 hour ago" --no-pager

# 배포판/설정에 따라 경로가 다를 수 있음
sudo tail -n 200 /var/log/mariadb/mariadb.log 2>/dev/null || true
sudo tail -n 200 /var/log/mysql/error.log 2>/dev/null || true

운영 중 주의할 점

  • DB가 느리다고 바로 서비스를 재시작하면 lock, long transaction, replication 오류 증거가 사라질 수 있습니다.
  • 테이블 손상 의심 시 repair보다 백업 확보와 오류 로그 확인이 먼저입니다.
  • Oracle RMAN validate, MariaDB mysqlcheck는 I/O 부하를 만들 수 있으므로 실행 시간대를 조정합니다.
  • DB 비밀번호를 명령줄, 블로그, 문서, 채팅에 평문으로 남기지 않습니다.
  • 상태 점검 결과는 시간과 함께 저장해야 전후 비교가 가능합니다.

빠른 점검 명령 모음

# Oracle
ps -ef | egrep 'pmon|tnslsnr' | grep -v grep
lsnrctl status
sqlplus / as sysdba

# MariaDB
systemctl status mariadb --no-pager
mysqladmin -u root -p ping
mysqladmin -u root -p processlist
journalctl -u mariadb --since "1 hour ago" --no-pager
BGM EVER