MSSQL EMERGENCY 모드로 DB, TABLE 복구하기(CHECKDB, CHECKTABLE)

DB 장애는 절대 나면 안되지만 노후가 원인인 disk fault를 제외하고도 SW 혹은 OS 레벨적인 문제로 인해 데이터, 혹은 데이터 파일에 문제가 생기는 경우가 있다.

이때 MSSQL은 DB 응급모드로 전환 -> DB 검사 -> 데이터 복구 ->  DB Online 상태로 변경을 통해서 해결하면 된다.

단 복구까지 서비스 중단은 피할 수 없다.

--먼저 ALTER DATABASE를 통해 DB를 응급모드로 전환한다

ALTER DATABASE 데이터베이스명 SET EMERGENCY

GO

DBCC CHECKDB('데이터베이스명')

GO

CHECKDB를 통해 대략 해결할 수 있는 문제인지 파악이 가능하다. 물론 하드웨어적인 문제면 해결이 불가능하다.

-- SINGLE_USER 모드로 전환한다. (절대 세션을 닫지 않도록 조심하자)

ALTER DATABASE DB명 SET SINGLE_USER WITH ROLLBACK IMMEDIATE

GO

-- DBCC CHECKDB 옵션

1. REPAIR_FAST : 빠른 회복으로 데이터의 손실이 없다.

2. REPAIR_REBUILD : REPAIR_FAST가 하는 모든 작업을 수행하며 인덱스 재생성 등 빌드를 다시 하며 시간이 꽤 소요된다. 역시 데이터 손실이 없다.

3. REPAIR_ALLOW_DATA_LOSS : REPAIR_REBUILD가 수행하는 모든 작업과 할당 및 행, 페이지 오류, 손상된 텍스트 개체 등을 조회하며 손상된 곳을 재할당하며 데이터 손실이 있을 수 있다. 최후의 수단이라고 볼 수 있다.

-- DB 복구

DBCC CHECKDB('데이터베이스 명', REPAIR_FAST)

DBCC CHECKDB('데이터베이스 명', REPAIR_REBUILD)

DBCC CHECKDB('데이터베이스 명', REPAIR_ALLOW_DATA_LOSS)

순서대로 REPAIR_FAST -> REPAIR_REBUILD -> REPAIR_ALLOW_DATA_LOSS 를 수행하면 되며 REPAIR_ALLOW_DATA_LOSS까지 가지 않는다면 가장 BEST REPAIR 시나리오가 될 것이다.

참고로 시간이 부족할 때, 그리고 확실히 특정 테이블이 문제인 것을 알고 있다면 데이터베이스 레벨에서 복구가 아닌 테이블 레벨에서의 복구인 DBCC CHECKTABLE를 통해 복구를 해도 된다.

-- 복구 완료 후 MULTI_USER 모드로 변경한다.

ALTER DATABASE DB명 SET MULTI_USER

GO

-- 응급 모드가 자동 해제되지 않는다면 온라인 모드로 변환해준다.

ALTER DATABASE 데이터베이스명 SET ONLINE;