손상된 사용자 데이터베이스 복구

데이터베이스 시스템 관리에 있어서 재난에 대비한 복구 전략의 수립은 필수적인 요소입니 다. 그 중에서도 특히 중요한 요소는 백업과 복구 전략이라고 할 수 있습니다. 백업 및 복구 전략을 수립하는 목적은, 데이터 손실은 최소화하면서 가능한 한 빠른 시간 내에 업무를 정상화 하는 것입니다. 즉, 복구는 목적이고 백업은 수단의 일부라는 사실을 유념해야 합니다. 간혹, 백업은 열심히 하면서 복구 훈련은 한번도 하지 않는 경우도 있습니다.

재난에 대비한 복구 전략을 수립하는 데 있어서, 가장 먼저 해야 할 일은 재난에 대한 정의를 올바르게 하는 일입니다. 재난의 정의에 빈틈이 생기면 그에 대한 대비 전략에도 빈틈이 생길 수 밖에 없기 때문입니다. 따라서, 어느 날 갑자기 대포동 미사일이나 ICBM이 테헤란로에 떨어지는 상황에서부터 디스크의 손상, DBA나 개발자의 실수에 이르기까지 모든 상황을 염두에 두어야 합니다. 서버룸에 이산화탄소 분사 장치로 화재 상황에 대비는 했지만 운영인력을 위해서 산소마스크는 준비해 두지 않는 곳이 많이 있습니다. 화재 발생시 시스템은 무사한데 운영인력이 없어서 장애가 발생할 수도 있는 상황인 것입니다.

SQL Server로 돌아 옵니다. SQL Server DBA는 SQL Server 백업과 복구의 기능과 특성을 버 전 별로 정확히 알고 있어야 합니다. 그래야만 운영중인 SQL Server 버전에 따라서 올바른 복구 전략을 수립할 수 있습니다. 본 가이드에서는 SQL Server의 백업과 복구 기능에 대해서는 다루지 않습니다. SQL Server DBA 가이드(전현경 저)의 백업과 복구 부분을 참조하여 올바르게 숙지하기 바랍니다.

데이터베이스를 운영하는 중에 데이터베이스가 주의 대상 (SUSPECT) 모드가 되는 경우가 있습니다. 데이터베이스가 손상을 입은 경우입니다. 데이터 페이지가 손상을 입었을 수도 있고 외장형 스토리지와의 연결이 정상적이지 않을 수도 있으며 로그 파일이 손상되었을 수도 있습니다. 데이터베이스가 주의대상 모드인 경우는 다음과 같이 확인할 수 있습니다.

1) 엔터프라이즈 관리자에서 확인하는 경우

2) 시스템 함수로 확인하는 경우

3) SQL Server 오류 로그에서 확인하는 경우

4) 이벤트 로그에서 확인하는 경우

5) 데이터베이스 사용 시점에 확인하는 경우

데이터 파일 손상 시 복구 방법

사용자 데이터베이스가 주의 대상 모드로 변경된 경우에는 원인을 찾기 위해서 윈도우즈 이벤트 로그와 SQL Server 오류 로그를 면밀히 검토해야 합니다. SQL Server 오류 로그에서 다음과 같은 오류 메시지를 발견한 경우에 데이터베이스를 복구하는 방법을 살펴보겠습니다.

먼저 증상을 확인하기 위해서 해당 메시지와 관련된 마이크로소프트 기술문서를 검색합니다. 아래 링크의 KB828337 기술 문서를 확인하면 DBCC CHECKDB를 실행해서 데이터페이지의 오류나 일관성의 오류 등이 발생했는지 여부를 점검하도록 권장하고 있습니다.

현재는 데이터베이스가 주의 대상 모드이므로 데이터베이스에 접근이 불가능한 상태라 해당 데이터베이스에서 아무런 작업도 할 수 없습니다. 이런 경우에는 먼저 응급 복구 (EMERGENCY) 모드로 변경해서 작업하도록 합니다. 모든 데이터베이스의 상태 정보는 master.dbo.sysdatabases 시스템 테이블의 status 컬럼과 status2 컬럼에 저장되어 있습니다. ALTER DATABASE 구문이나 sp_dboption 시스템 저장 프로시저를 사용하여 데이터 베이스 구성 옵션을 변경하는 경우에도 바로 이 값이 변경됩니다. SQL Server 2005에서는 ALTER DATABASE ~ SET EMERGENCY 구문을 제공하고 있으나 SQL Server 2000에서 는 직접 시스템 테이블을 수정해야 합니다. 시스템 테이블을 직접 수정할 수 있는 경우는 SQL Server 서비스를 /m 옵션으로 시작하는 단일 사용자 모드인 경우와 SQL Server의 구 성 옵션인“allow updates”의 설정값을 1로 변경한 경우 입니다.

1. 사용자 데이터베이스 점검을 위하여 서비스를 단일 사용자 모드로 다시 시작하는 것은 비효율적이므로 다음과 같이 서버의 구성 옵션을 변경하고 점검 작업을 수행합니다.
   

   

2. master.dbo.sysdatabases 시스템 테이블의 status 컬럼을 응급 복구 모드로 변경합니다. 응급 복구 모드로의 변경은 기존 status 컬럼 값에 32768을 비트 OR 연산하여 변경합니다. 복구가 완료되면 그 값에 (~32768) 을 비트 & 연산을 수행함으로써 원래 상태의 값으로 다시 변경할 수 있습니다. DBA는 데이터베이스의 설정 상태를 유지하기 위해 데이터베이스 별로 평상시 이 값의 정보를 관리자 노트에 기록해 놓아야 합니다.
   

   

3. 이제 응급 복구 모드로 변경므로 DBCC CHECKDB를 실행하여 원인을 분석합니다.
   

   

4. DBCC CHECKDB를 실행한 결과 2개의 일관성 오류가 발견되었다는 리포트를 받았습니다. 이런 경우 SQL Server 2005는 해당 데이터베이스의 백업으로부터 손상된 페이지만 복구하는 기능을 제공합니다. 반면에 SQL Server 2000은 이와 같은 기능을 제공하지 않고 있습니다. 따라서, 일부 데이터페이지가 손상된 경우라도 해당 데이터베이스의 백업이나 데이터 파일의 백업을 이용해서 복구해야 합니다. 그러나 가용한 백업이 없다는 가정으로 최대한 데이터를 복구하기 위해서 좀 더 정밀하게 분석해 보겠습니다.
5. DBCC CHECKDB의 실행 결과를 자세히 살펴 보면 mytab이란 테이블은 총 99개 페이지 에 297개 행이 점검 가능하였고 (1:138) 페이지의 하나의 행이 손상을 입어서 해당 페이 지를 처리할 수 없다는 것을 알 수 있습니다. 해당 테이블과 관련된 추가적인 정보를 확인 하기 위해서 아래 그림과 같이 sysindexes 시스템 테이블을 통해서 mytab의 테이블의 페 이지 할당 정보를 확인하고 DBCC CHECKDB 처리 결과와 비교합니다.
   

   

sysindexes 시스템 테이블과 DBCC CHECKDB의 실행 결과를 분석한 결과는 다음과 같습니다.

① mytab 테이블은 HEAP으로 구성되어 있고 Non-Clustered 인덱스가 1개 존재합니다. (indid 컬럼 값이 0=HEAP, 2~250 =Non-Clustered INDEX)

② 데이터는 총 100개 페이지를 사용하며 데이터는 300행입니다.
(DBCC CHECKDB 의“99개 페이지 297개 행이 있다”는 결과 메시지와 비교합니다.)

③ 사용중인 페이지는 데이터 100 개 페이지, 해당 테이블의 IAM 1개 페이지 인덱스 1개 페이지, 인덱스 IAM 1개 페이지를 포함하여 총 103개의 페이지입니다.

④ 테이블에서 사용하고 있는 데이터 페이지 가운데 0x8A (138) 페이지가 첫 번째 페이지이며 이 가운데 1개 행이 손상을 입었습니다.

필요한 정보를 정리하면 ② 번에서 확인한 정보와 앞에서 실행한 DBCC CHECKDB의 실행결과와 비교하여 mytab 테이블은 총 300행으로 100개의 페이지를 사용하고 있으며 1번 파일의 138번 페이지(1:138)에 3개의 행 가운데 하나의 행이 손상되었음을 알게 되었습니다.

손상된 데이터베이스를 복구하기 위해서 DBCC CHECKDB 또는 DBCC CHECKTABLE을 REPAIR_ALLOW_DATA_LOSS 복구 옵션과 함께 실행하게 되면 다음 구문에서 설명하는 바와 같이 손상된 1개 페이지의 할당이 취소되므로 3개 행 전체를 잃게 됩니다.

DBCC CHECKDB | CHECKTABLE

‘( 테이블 이름’, REPAIR_FAT

             | REPAIR_REBUILD

             | REPAIR_ALLOW_DATA_LOSS )



REPAIR_FAST : 클러스터드 인덱스의 별도 키를 복구하는 것과 같이 사소 하고

              시간이 소요되지 않는 복구 작업을 수행합니다. 이러한 복구는

              데이터 손실의 위험 없이 빨리 실행할 수 있습니다.



REPAIR_REBUILD :

                 REPAIR_FAST에서 이루어지는 모든 복구 작업을 수행하고

                 인덱스 다시 작성과 같이 시간이 소요되는 복구를 포함합니다.

                 이러한 복구는 데이터 손실의 위험 없이 실행할 수 있습니다.



REPAIR_ALLOW_DATA_LOSS :

                 REPAIR_REBUILD에서 수행하는 모든 복구 작업을 수행하며 할

                 당 오류, 구조적 행 오류나 페이지 오류, 손상된 텍스트 개체 삭제

                 를 수정하기 위한 행과 페이지의 할당 및 할당 취소가 포함 됩니

                 다. 이러한 복구를 할 경우 일부 데이터가 손실될 수 있습니다. 복

                 구 작업은 사용자가 변경 사항을 롤백할 수 있도록 사용자 트랜

                 잭션 내에서 수행합니다. 복구가 롤백되어도 데이터베이스에는

                 오류가 그대로 포함되므로 백업에서 데이터베이스를 복원해야

                 합니다. 제공된 복구 수준 때문에 오류 복구를 생략한 경우 해당

                 복구에 종속적인 모든 복구도 생략됩니다. 복구를 완료한 다음에

                 데이터베이스를 백업합니다.

따라서, 손상되지 않은 나머지 2개의 행을 복구하기 위해서 손상된 행을 추적합니다.
다음과 같이 EXEC sp_help‘ mytab’을 실행해서 테이블의 정보를 확인해 보았습니다.

실행 결과에서 mytab 테이블은 col1, col2, col3 3개의 컬럼으로 구성되어 있고 col1 컬럼에 PK가 만들어져 있으며 IDENTITY(1,1) 속성이 있다는 정보도 확인했습니다. HEAP은 데이터 가 INSERT 되는 대로 저장되므로 첫 번째 페이지에 존재할 수 있는 행의 IDENTITY 값의 빈틈이 없는 경우 col1의 값이 1~3일 가능성이 높음을 추리해낼 수 있습니다.

빈틈이 존재하는지 여부를 확인하기 위해서 먼저 col1 컬럼에 만들어져 있는 손상되지 않은 인덱스를 통해서 col1 컬럼의 값을 확인합니다. 아래와 같이 인덱스를 통해서 확인한 결과 col1 컬럼의 IDENTITY는 빈틈이 없이 1~300까지 존재함을 확인했습니다.

이제 첫 번째 페이지에 있을 것으로 추정되는 col1 컬럼의 값이 1~3인 행을 제외하고 검색 합니다. 에러가 발생하지 않고 297행이 반환되었습니다. 그렇다면 위의 쿼리에 WHERE 조 건절을 추가하고 col1=1, col1=2, col1=3을 차례로 입력하고 실행해서 손상된 행이 어느 행 인지 확인합니다.

위와 같이 col1 컬럼의 값이 2일 때만 오류가 발생했으므로 손상된 행이 col1 컬럼의 값이 2 임?? 행을 SELECT * INTO 구문으로 다른 데이터베이스로 백업합니다.

이어서 DBCC CHECKDB 또는 DBCC CHECKTABLE을 REPAIR_ALLOW_DATA_LOSS 복구옵션과 함께 실행하기 위해서 다음과 같이 설정했던 응급 복구 모드를 해제하고, sp_resetstatus 시스템 저장 프로시저를 실행해서 주의 대상 모드를 해제합니다. master 데이터베이스의 sysdatabases 시스템 테이블에 있는 pubs 데이터베이스의 status 컬럼값은 0으로 리셋 됩니다.

<응급 복구 모드 해제>

<데이터베이스 리셋>

이어서 DBCC DBRECOVER를 IGNOREERRORS 옵션과 함께 실행합니다. IGNOREERRORS 옵션은 데이터베이스를 복구하는 과정에서 오류가 발생해도 무시하고 복구를 계속 진행하겠 다는 옵션입니다.

<데이터베이스 복구>

DBCC DBRECOVER ‘( pubs’, ignoreerrors)를 실행할 때 오류가 발생했지만 복구 작업이 계 속 진행되었습니다. SQL Server 오류 로그를 통해서 복구 작업이 진행되었음을 확인합니다.

<데이터베이스 복구 결과 확인>

이제 DBCC CHECKDB 나 DBCC CHECKTABLE 문을 실행하여 손상된 페이지를 복구합니다. 이미 앞에서 mytab 테이블만 손상되었다는 것을 확인하였으므로 DBCC CHECKDB를 수행하지 않고 해당 테이블에 DBCC CHECKTABLE을 수행합니다.

DBCC CHECKDB 나 DBCC CHECKTABLE 을 REPAIR_ALLOW_DATA_LOSS 옵션과 함께 실행하기 위해서는 데이터베이스를 단일 사용자 모드로 변경해야 합니다.

이어서 DBCC CHECKTABLE‘ ( mytab’, REPAIR_ALLOW_DATA_LOSS) 구문을 실행합니다.

<DBCC CHECKTABLE 수행 결과>

위의 그림에서 DBCC CHECKTABLE을 REPAIR_ALLOW_DATA_LOSS 복구 옵션과 함께 실 행하여 인덱스 ID 0 (HEAP)에서 손상된 페이지의 할당이 취소되고 인덱스 ID 2 가 다시 작성되 었다는 메시지를 확인할 수 있습니다. 이어서 메시지가 나타내는 대로 mytab 테이블이 297개 행만으로 복구가 되었는지 SELECT * FROM mytab 쿼리를 실행하여 확인합니다.

<DBCC 결과 확인을 위한 QUERY>

이상이 없다면 DBCC CHECKDB‘( pubs’)를 실행하여 추가로 발생한 문제가 없는지 확인 합 니다.

<해당 데이터베이스 재 점검>

다른 데이터베이스에 백업해 놓은 col1=1,3 의 데이터를 다시 mytab에 로드하고 ALTER DATABASE pubs SET MULTI_USER WITH NO_WAIT을 실행? 옵션 설정을 원래 상태로 복원하면 모두 마무리가 됩니다.

데이터베이스 파일이 저장된 디스크와 운영체제의 연결이 비정상적인 경우 복구

이번에는 데이터 파일이나 로그 파일이 포함된 디스크와 운영체제의 연결이 비정상적인 경우를 살펴 봅니다. 다음은 외장형 스토리지와 운영체제간의 연결 장애로 데이터베이스가 주의 대상 모드로 변경된 경우입니다. 역시, SQL Server 오류 로그와 윈도우즈 이벤트 로그를 확인합니다.

이와 같은 현상이 발생하면 운영체제와 스토리지 시스템간의 연결을 확인합니다. 윈도우즈 디스크 관리자에서 [동작] 메뉴 선택→ [디스크 다시 검사]를 실행하여 디스크를 다시 연결 합니다.

연결한 다음에 DBCC DBRECOVER 명령을 통해서 서비스를 다시 시작하지 않고 데이터베이스를 복구합니다. 윈도우즈 이벤트 로그나 SQL Server 오류 로그에 다음과 같이 복구가 완료되었다는 로그를 확인합니다.

로그 파일 손상 시 복구

SQL Server의 트랜잭션 로그 파일은 트랜잭션을 시작하기 위해서 뿐만 아니라 데이터베이스 손상 시에 데이터베이스가??드시 필요한 필수 구성 요소입니다.

로그 파일은 데이터 파일과 다른 구조로 구성되어 있습니다. 로그 파일은 여러 개의 가상 로그 파일로 구성 되어 있으며 트랜잭션이 시작되면 각 가상의 로그 파일에 순환 방식으로 트랜잭션을 기록해 나갑니다다. 로그가 백업되어 가상의 로그 파일이 비워져 (TRUNCATE) 다시 사용 할 수 있게 되면 비로소 가상의 로그 파일 단위로 삭제가 가능하게 됩니다.

로그 파일은 가상 로그 파일을 전형적인 순차적 액세스 방식에 따라서 순서대로 트랜잭션 로그를 기록하므로, 여러 개의 물리적인 로그 파일은 성능상으로 별다른 기능을 하지 못하고 오히려 관리 부담만 가중시키게 됩니다. 따라서, 특별한 경우가 아니면 로그 파일은 하나만 유지하도록 권장합니다.

SQL Server 2000부터는 복구 모델이 최대(FULL)로 설정된 경우 로그 파일만 손상되지 않았다면 WITH NO_TRUNCATE 옵션으로 로그를 백업할 수 있기 때문에 데이터베이스가 손상된 시점까지 복구가 가능합니다. 대량 로그(BULK_LOGGED) 모델인 경우는 로그에 기록되지 않는 작업이 진행되면 로그백업을 수행해야만 데이터베이스가 손상되더라도 로그 파일이 손상되지 않은 경우 WITH NO_TRUNCATE 옵션으로 로그를 백업할 수 있습니다. 따라서, 복구 모델의 설정에 따라서 올바른 백업 전략을 수립하고 로그 파일은 RAID1 또는 RAID 1+0 으로 구성된 하드디스크에 위치시켜 손상될 확률을 줄여야 합니다.

그럼에도 불구하고 SQL Server 오류 로그에서 확인한 것과 다음 그림과 같이 로그 파일의 손상으로 데이터베이스가 주의 대상 모드가 된 경우 다음과 같이 작업을 수행합니다.

<SQL Server 오류 로그>

<로그 파일의 손상으로 주의 대상 모드로 변경된 경우>

로그 파일 손상 시 진행중인 트랜잭션이 없는 단일 로그 파일의 경우

1. 손상된 데이터베이스를 응급 복구 모드로 변경합니다.
2. sp_detach_db 시스템 저장 프로시저를 사용하여 데이터베이스를 분리합니다. 이때 어떤 오류메시지도 발생하지 않아야 합니다. 오류가 발생하면 손상된 트랜잭션이 존재하는 경우 이며 이런 경우에는 DBCC REBUILD_LOG 명령을 사용해서 로그를 다시 생성해야만 하고 반드시 데이터의 무결성을 점검해야 합니다.
3. sp_attach_single_file_db 시스템 저장 프로시저를 사용하여 새로운 로그 파일을 생성하고 데이터베이스를 서버에 연결합니다.sp_attach_single_file_db‘ 데이터베이스 이름’,’새로운 물리적 로그 파일 이름

   <sp_attach_single_file_db 시스템 저장 프로시저 사용 복구>

4. 엔터프라이즈 관리자나 master 데이터베이스의 sysdatabases 시스템 테이블의 status컬럼 값을 변경하여 데이터베이스 옵션 설정을 응급 복구 모드 변경 이전 상태로 재구성합니다.

다중 로그 파일인 경우

다중 로그 파일인 경우나 손상된 트랜잭션이 존재해서 sp_detach_db 시스템 저장 프로시저를 실행해서 분리할 때 오류가 발생한 경우에는 DBCC REBUILD_LOG를 사용해야 합니다.

DBCC REBUIL_LOG는 sp_attach_single_file_db 시스템 저장 프로시저를 사용하는 경우처럼 데이터베이스를 분리하게 되면 실행할 수 없습니다. 따라서 로그 파일이 손상된 것이 확인되면 데이터베이스를 응급 복구 모드로 변경하고 로그 파일의 개수를 확인합니다.

MultiLog 데이터베이스는 다음 그림과 같이 두 개의 로그 파일을 가지고 있습니다.

<다중 로그 파일의 데이터베이스>

따라서, 데이터베이스를 분리하지 않고 응급 복구 모드로 변경한 뒤 DBCC REBUILD_LOG 구문을 실행하여 새로운 로그 파일을 생성합니다.

DBCC REBUILD_LOG ‘( 데이터베이스_이름’,‘ 새로운 물리적 로그 파일 이름’)

손상된 트랜잭션이 존재하는 경우

로그 파일이 손상되기 전에 진행중인 트랜잭션이 있는 경우에는 데이터베이스를 분리하는 과정에서 오류가 발생해서 sp_attach_singl_file_db 시스템 저장 프로시저로 새로운 로그 파일을 생성하면서 연결할 수 없게 됩니다. 이런 경우에도 다중의 로그 파일과 마찬가지로 DBCC REBUIL_LOG를 통해서 새로운 로그 파일을 생성합니다. 이런 경우에는 데이터의 무결성의 손상이 의심됩니다.

다음과 같이 MissingLog 데이터베이스의 emp 테이블에는 데이터가 9행 있었는데 사용자 트랜잭션으로 23개 행이 추가되었습니다. 이어서 CHECKPOINT가 발생해서 추가로 삽입된 23개 행의 정보가 데이터 파일에 기록되었습니다.

트랜잭션을 COMMIT하지 못한 시점에서 로그 파일이 손상되어 데이터베이스가 주의 대상 모드가 된 상황을 가정하였습니다.

<트랜잭션 진행 중 로그 파일이 손상된 경우>

1. 이와 같은 경우 앞의 데이터 파일이 손상된 경우에서 살펴본 바와 같이 손상된 데이터베 이스를 응급 복구 모드로 변경합니다. 이때 master.dbo.sysdatabases 시스템 테이블의 status 컬럼을 확인하고 기록합니다.
   

   <현재 데이터베이스 설정 상태 확인>

2. 데이터베이스를 응급 복구 모드로 변경합니다.
   

   <응급 복구 모드 변경>

3. DBCC REBUIL_LOG를 실행하여 새로운 로그 파일을 생성합니다.
   

   <DBCC REBUILD_LOG 를 실행한 경우>

이제 SQL Server가 메시지를 통해 경고한 대로 데이터의 무결성을 점검합니다. 먼저, 작업 중이던 emp 테이블을 조회하면 트랜잭션이 COMMIT 되지 않았음에도 불구하고 32 행이 반환됩니다. 로그 파일의 손상으로 인스턴스 복구 프로세스를 진행할 수 없기 때문입니다.

<무결성 손상 여부 확인>

DBCC CHECKDB를 실행해서 점검해 보더라도 동일하게 다음과 같이 32행이 존재한다는 정보가 반환됩니다.
그러나 일부 다른 정보에는 이전에 9행이 있었던 상태를 유지하고 있습니다. sysindexes 시스템 테이블을 검색해 보면 기존의 9행이 있는 정보를 반환합니다. 이와 같이 로그 파일이 손상되기 전에 진행중인 트랜잭션이 있는 경우는 DBCC CHECKDB 실행결과와 sysindexes 시스템 테이블의 검색결과를 비교하여 무결성이 손상된 테이블과 데이터를 확인해야 합니다.

<DBCC CHECKTABLE 실행 시 결과>

이때 DBCC CHECKDB를 REPAIR_ALLOW_DATA_LOSS 등으로 복구하면 데이터가 서로 다른 정보를 유지하던 상황으로 종료됩니다. 그러나 COMMIT 되지 않은 데이터가 존재하는 무결성이 손상된 상황으로 마무리가 되므로 손상된 로그 파일을 복구 하는 경우에는 로그 파일 손상 시에 발생한 작업등을 면밀히 점검하고 데이터를 수동으로 복구할지 여부를 검토 한 뒤 실시해야 합니다. 이와 같은 상황에서는 emp 테이블의 id 컬럼값이 9보다 큰 데이터를 수동으로 삭제해야 합니다.

<무결성이 손상된 상황으로 마무리된 DBCC CHECKDB (REPAIR_ALLOW_DATA_LOSS)>

데이터베이스 분리 중 오류가 발생한 경우

새로운 로그 파일 생성을 위해서 데이터베이스를 분리하는 경우 오류가 발생하면 DBCC REBUILD_LOG 명령을 통해서 로그 파일을 생성해야 한다고 했습니다. 그러나, DBCC EBUIL_LOG는 데이터베이스가 분리되기 전에 실시해야만 합니다.

따라서, sp_attach_single_file_db를 실행할 수도 없고 DBCC REBUIL_LOG도 실행할 수 없는 상황에 놓이게 됩니다.

이런 경우에는 다음과 같은 방법을 사용하여 새로운 로그 파일로 데이터베이스를 복구합니다.

1. 분리된 데이터 파일을 모두 임시 폴더로 이동하고 동일한 이름과 파일구성을 가지는 새로운 데이터베이스를 생성합니다.
2. SQL Server 서비스를 종료합니다.
3. 새롭게 생성된 데이터베이스의 파일을 모두 삭제하고 임시 폴더로 이동했던 손상된 데이터 파일을 원래 위치로 다시 이동합니다.
4. 이제 다시 SQL Server 서비스를 시작합니다. 또 다시 주의 대상 모드인 데이터베이스를 발견하게 됩니다. 앞에서 설명한 DBCC REBUILD_LOG 명령을 사용해 새로운 로그 파일을 생성합니다.
5. master.dbo.sysdatabases 의 status 컬럼을 변경하여 기존의 데이터베이스 옵션 설정 상태로 변경합니다.