데이터 손상

증상

읽기 중 'ORA-01578', 'page corruption', 'checksum mismatch', 'MISCONF', I/O 일관성 오류.

1. 침착하게 확산을 막는다

당황한 개입은 상황을 악화시킨다. 먼저 범위를 파악하고 가능하면 영향받은 객체에 대한 쓰기를 중지한다. 하드웨어(디스크/컨트롤러) 관련이라면 OS/하드웨어 로그도 확인한다 — DB를 고쳐도 디스크는 고쳐지지 않는다.

2. 범위를 파악한다: 얼마나 손상되었는가

단일 블록/페이지/객체인가, 광범위한가? 무결성 검사를 실행한다.

Oracle

RMAN> VALIDATE DATABASE;  -- or: SELECT * FROM v$database_block_corruption;

PostgreSQL

-- With data_checksums enabled it shows up in the logs; check indexes/heap with pg_amcheck:
-- pg_amcheck --heapallindexed -d mydb

MySQL

CHECK TABLE customer;  -- for InnoDB, innodb_force_recovery is the last resort

SQL Server

DBCC CHECKDB ('MyDB') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Redis

redis-check-rdb dump.rdb
# AOF (Redis 7+ multi-part: under appendonlydir/, pass the manifest file):
redis-check-aof appendonlydir/appendonly.aof.manifest
# --fix TRUNCATES everything after the corrupted point (writes in that part are lost); back up the directory first:
# redis-check-aof --fix appendonlydir/appendonly.aof.manifest

3. 우선순위: 백업에서 복구

손상 시 가장 안전한 방법은 정상 백업에서 복원하는 것이다. 블록/페이지 수준 복구가 지원되면 손상된 부분만 복구한다(Oracle RMAN BLOCKRECOVER, MSSQL page restore). 복구 도구(DBCC REPAIR_ALLOW_DATA_LOSS, innodb_force_recovery)는 데이터 손실을 일으킨다 — 최후의 수단이다.

4. 무결성을 검증한다

복구 후 검사(DBCC CHECKDB / RMAN VALIDATE / CHECK TABLE)를 다시 실행하여 깨끗하게 나오는지 확인한다. 애플리케이션 측에서도 데이터 일관성(행 수, 핵심 합계)을 검증한다.

5. 근본 원인: 대개 하드웨어

손상은 대개 디스크/메모리/컨트롤러 장애에서 비롯된다. 하드웨어를 테스트/교체하고, checksum을 활성화하며(data_checksums, PAGE_VERIFY CHECKSUM), 백업 + 검증 절차를 강화한다. 정기적인 DBCC CHECKDB / RMAN VALIDATE를 스케줄링한다.

DBAtlas에서 열기 →