2010. 4. 4. 23:48

Suspect 상태 해결 - SQL 2000

SQL 2000

Suspect 상태 해결 방법

상태를 변경

Problem
I have a SQL Server 2000 database that has the wrong database status.  For some reason it is in the 'Suspect\Offline' mode.  I just need to correct the problem quickly and get my database back online.  How can I do so?   Once the status is correct, do I need to take any further steps?

Solution
To cut to the chase, the script below can be used to correct the SQL Server 2000 database status, but in reality this is only a third of the equation.  We also need to correct any sort of corruption and understand why this occurred in the first place.

Database Status Correction Script

The script below will change the database to be in simple recovery mode, which may or may not be the needed configuration for your database.  As such, it is necessary to review your database configurations once this script has been executed.  In addition, it is necessary to change the 'YourDatabaseName' to your database name in single quotes.

USE Master
GO

-- Determine the original database status
SELECT [Name], DBID, Status
FROM master.dbo.sysdatabases
GO

-- Enable system changes
sp_configure 'allow updates',1
GO
RECONFIGURE WITH OVERRIDE
GO

-- Update the database status
UPDATE master.dbo.sysdatabases
SET Status = 24
WHERE [Name] = 'YourDatabaseName'
GO

-- Disable system changes
sp_configure 'allow updates',0
GO
RECONFIGURE WITH OVERRIDE
GO

-- Determine the final database status
SELECT [Name], DBID, Status
FROM master.dbo.sysdatabases
GO

Check for Corruption

The next step in this process is very key.  It is necessary to determine if the database has any corruption and ensure that the database will be able to support the users.  If the database has corruption, you may be exposing yourself to more issues by just changing the database status without correcting the underlying issue.  To identify the underlying issue, execute the following commands:

  • DBCC CHECKDB - Validate the overall database integrity
  • DBCC CHECKCATALOG - Validate the system catalog integrity
  • DBCC CHECKTABLE - Validate the integrity for a single table

To resolve the issue, you may need to do one or more of the following:

  • Drop and Recreate Index(es)
  • Move the recoverable data from an existing table to a new table
  • Update statistics
  • DBCC UPDATEUSAGE
  • sp_recompile

To ensure the issue is corrected, it is a good idea to re-run the identification commands listed above and validate that they do not have any issues.

To address these items, check out the following MSSQLTips.com:

Determine the Root Cause

In the long term, it is imperative to understand what caused the suspect/offline database.  At a minimum the following questions should be addressed:

  • What has recently changed in your environment?
  • Review your SQL Server logs to see if you can determine when the error occurred.
  • Talk to your team members to ask them what changes have been made.
  • Review your change management and auditing processes to see what has changed in SQL Server or at a systems level.
  • See if the issue has occurred on any other databases in your environment

MS 자료

ByPass 모드

시작하기에 앞서...
매우 죄송한 말이지만 여기서 실험한 것은 로그파일이 깨진 경우입니다.
데이터 파일도 수정해서 사용해봤지만 전적은 12전 12패... -_-;
참담함 그 자체입니다.
혹시 데이터 파일을 아작내서도 성공하신 분은 제게 메일을 날려주시면 매우 감사...

그리고 사용한 방법은 정원혁님이 기술하신 Bypass모드 사용방법을 사용했습니다.
음... 이런 좋은방법 써주신 정원혁님께 감사의 마음을 드리면서...
시작하지요...
우선 MSSQL Server 서비스를 중지시킵니다.
그리고 메모장으로 Pubs 데이터베이스의 로그파일인 Pubs_log.ldf 파일을 끄적거렸습니다.
다시 MSSQL Server 서비스를 실행시키고 나서 EM으로 가서보면?
Pubs 데이터베이스에 Suspect 상태가 생겼습니다.
여기서 시스템 테이블을 직접 수정할수 있도록 옵션을 설정합니다.
EM에서도 할 수 있지요...
Server behavior에서 첫번째 Allow modifications~에 체크해주시면 됩니다.
이제 바이패스 모드로 실행을 하겠습니다.
우선 MSSQL Server 서비스를 중지해 주시고 도스 명령창에서 다음과 같이 합니다.
sqlservr.exe -T3608 이란 명령어를 실행시킵니다.
(저는 어디서 3608이란게 튀어나오는지... -_-;
추적 플래그를 뒤져보아도 3608이란 숫자가 뭘 지정하는지는 모르겠습니다.)
그럼 다운된것처럼 커서만 껌벅 거리는데 닫지 마시고 최소화시켜 놓습니다.
또 다른 도스명령창을 열어서 isql을 실행시킵니다.
... -_-... 보안상 패스워드는 지웠슴다...
Master 데이터베이스로 가서 sysdatabases를 수정합니다.
pubs 데이터베이스를 Emergency Mode로 변경합니다.
여기서 정원혁님이 쓰신말...
'1 row affected가 아닌 에러가 난다면 말짱헛거' ... 라는데 저는 한번도 에러가 나지 않았네요...
Commit하고 나갑니다.

바이패스 모드로 시작한 창으로 가서 Ctrl+C키를 누르고 Y를 눌러서 서비스를 중지시킵니다.
이제 다시 정상적으로 MSSQL Server 서비스를 실행시킵니다.
EM에 가서 확인한 광경입니다.

검색이 됩니다!
이제 어여 자료들을 다 빼야지요...
그리고 나서 Suspect 상태의 데이터베이스는 삭제시킵니다.
EM에서 삭제시 뭐라고 에러가 뜨는데 굴하지 말고 계속 OK누르면 결국 지워집니다.
이제 데이터 파일과 로그 파일만 지워주면 깨끗하게 해결된겁니다.
마지막으로 이 상황은 로그파일이 깨진지 모르는 상황에서 사용하는 것이고...
만약 로그파일이 깨져서 Suspect 상태인것을 안 상태라면?
굳이 이런 방법 쓰지 않아도 됩니다.
간단히 sp_detach_db 하여 데이터베이스를 떼어내고 mdf 파일만 이용하여 붙이면 만사OK입니다.
Suspect 상태의 DB에서도 sp_detach_db는 말을 듣는 답니다.
물론 데이터 파일이 깨졌을 경우는 떼어냈다가 붙일 방법이 없겠지요... ^^


제 생각이지만 역시 백업을 잘해놓아야 합니다.
재수없다면 디스크 스크래치 한방에 이런 불상사가 생기니 말입니다.
그리고 제가 이런 상황에 처했다면 아마 바로 리스토어 풀어버릴겁니다.
이 방법이 제대로 된다는 보장도 없고 아직까지 제가 데이터 파일을 건들여서 성공한 적이 없어서요... -_-;
그럼~ Zzz~