죽어버린 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상태로 설정할 수 있다. |
가장 내가 우선적으로 해야 할 일은 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...
'MS-SQL' 카테고리의 다른 글
| [Tip]MS-SQL에서 Transaction Log File Shrink하기 (2) | 2009.04.14 |
|---|---|
| [Tip]MS-SQL 2005 DB 호환성 레벨 변경 (2) | 2008.03.30 |
| [Tip]MS-SQL에서 Database 목록을 쿼리하는 SQL 문장 (4) | 2007.05.09 |
