[Tip]죽어버린 Sharepoint 팀 사이트를 살려라 1 - Suspect 상태의 DB 회복시키기

죽어버린 Sharepoint 팀 사이트를 살려라. 사건개요 보기

사고 직후, DB를 SQL Management Studio를 열었더니 DB는 오프라인 상태로 되어 있었고, DB 이름 옆에 (Suspect)라고 되어 있었다. DB에 손상이 있었구나라는 짐작을 할 수 있었다.

참고로 Database의 각 State는 다음과 같다.

상태	정의
ONLINE	데이터베이스는 접속이 가능한 상태이다. 비록 리커버리의 Undo가 끝나지 않았어도 , 프라이머리 파일 그룹이 온라인 상태이다.
OFFLINE	데이터베이스는 접속 불가능한 상태이다. 사용자가 명시적으로 offline으로 지정했다면, 그것을 다시 되돌리기 전까지는 데이터베이스는 계속 offline상태로 머무르게 된다. 예를 들면 새로운 디스크로 파일을 옮기기 위해서 offline모드로 바꿀 수 있다. 이 파일 이동 작업이 끝나면 다시 online으로 되돌릴 수 있다.
RESTORING	프라이머리 파일 그룹의 하나 이상의 파일이 복구되고 있을 때, 혹은 세컨더리 파일 그룹의 파일이 복구되고 있는 상태이다. 데이터베이스 접속은 불가능하다.
RECOVERING	데이터베이스가 리커버리되고 있는 상태이다. 리커버리 프로세스는 일시적인 것으로, 리커버리가 성공되면 자동적으로 데이터베이스는 온라인 상태로 복구된다. 하지만 리커버리가 실패하면 데이터베이스는 suspect 상태로 바뀌게 된다. 이 때도 역시 데이터베이스 접속은 불가능하다.
RECOVERY PENDING	리커버리 도중에 리소스 관련 문제가 발생한 상태이다. 데이터베이스가 손상된 것은 아니지만, 파일이 없어졌을 수도 있고 시스템 상의 리소스 제약때문에 문제가 발생했을 수도 있다. 데이터베이스 접속은 불가능하다. 이 문제를 풀기 위해서는 사용자의 행동이 필요하며, 그래야만이 리커버리 프로세스가 완료될 수 있다.
SUSPECT	프라이머리 파일 그룹에 문제가 있거나 손상된 것이다. SQL 서버를 다시 시작시켜도 데이터베이스는 복구되지 않는다. 데이터베이스 접속은 불가능하다. 문제를 해결하기 위해서는 사용자의 행동이 필요하다.
EMERGENCY	이 상태는 사용자가 설정했을 때만 가능하다. 데이터베이스가 single-user 모드일 때에만 데이터베이스는 수리(Repair)와 복원이 가능하다. 이때 데이터베이스는 읽기 전용이며 로깅이 꺼지며 sysadmin 그룹의 사용자만이 접속이 가능하다. 이 Emergency 상태는 장애 복구의 용도로 사용된다. 예를 들면 Suspect 상태의 데이터베이스는 Emergency상태로 설정할 수 있다. 이 때 system administrator는 데이터베이스에 읽기 전용으로 접속할 수 있다. sysadmin그룹의 사용자만이 데이터베이스를 Emergency상태로 설정할 수 있다.

* 죄송하게도 번역이 매끄럽지 못하다. -_-;; 그래도 제 딴에는 최선을 다한 것이니 양해 부탁드린다. 오역이 있다면 덧글로 남겨주시길.. 원본은 SQL 2005 help이다.



가장 내가 우선적으로 해야 할 일은 DB를 살리는 것이었다. suspect 상태의 DB를 살리기 위해서 구글신에게 물어보았더니, 아래와 같은 답을 주셨다.

How to Restore SQL Server 2005 Suspect Database - The Code Project

위 페이지에서 제시하는 해답은 다음과 같다. 아래의 스텝을 순서대로 하면 되겠다.

1. EXEC sp_resetstatus 'yourDBname';

일단, DB에서 Suspect 마크를 없앤다. sp_resetstatus는 바로 그 일을 해주는 내장 스토어드 프로시저이다.

2. ALTER DATABASE yourDBname SET EMERGENCY

데이터베이스 상태를 Emergency로 바꾼다.

3. DBCC checkdb('yourDBname')

Emergency모드이므로, 현재 데이터베이스는 읽기 전용이다. 이 상태에서 먼저 CheckDB를 수행해서 DB문제점을 파악한다.

4. ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Repair를 위해서, DB상태를 Sigle User 모드로 바꾼다.

5. DBCC CheckDB ('yourDBname', REPAIR_ALLOW_DATA_LOSS)

CheckDB를 통해서 Repair를 수행하는데, REPAIR_ALLOW_DATA_LOSS옵션을 사용한다. 위에 링크한 원본 글에도 나와 있지만, 이 옵션외에는 쓸 수가 없다. (위 글의 저자는 자신의 경우 어떤 데이터 LOSS도 없었다고 하는데, 실제로 나는 데이터를 다소 잃었다. -_-;; 이건 팔자려니 생각하자.)

6. ALTER DATABASE yourDBname SET MULTI_USER

Repair가 끝났다면 Database를 다시 Multi User모드로 복원시키면 된다.

위 스텝을 정리하자면 다음과 같다.

EXEC sp_resetstatus 'yourDBname';
ALTER DATABASE yourDBname SET EMERGENCY
DBCC checkdb('yourDBname')
ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ('yourDBname', REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE yourDBname SET MULTI_USER

이 스텝을 통해서, Suspect 상태의 DB를 거의 복구시킬 수 있었다. 아마 대부분의 경우 위 스텝으로 거의 100% 복구가 가능할 것이라 생각되나.. 내 경우는 조금 달랐다. 문제는 디스크에 오류가 있기 때문에, DB는 복구가 되었지만 Sharepoint 는 문제가 계속 있었던 것이다. 데이터의 읽기는 아무런 문제없이 정상적인데, 문서를 올리거나 게시물을 작성하면 2번에 1번 꼴로 에러가 발생했다. 그래서 어쩔 수 없이 DB를 포함해서 모두를 다른 서버로 옮기기로 했다. 이 이야기는 다음에..

To Be Continued...