대부분의 경우,. 자체의 기존 경로의 DB 이었거나 detach 등의 데이터 베이스중 로그파일이 손상되어 mdf 파일만 있는 경우에는 거의 대부분 sp_attach_single_file_db 프로시져나 EM 의 데이터베이스 연결을 통해서 복구가 가능합니다.

- SQL Server 2005 이후에는 데이터베이스 연결 프로시져인 sp_attach_single_file_db 대신에 CREATE DATABASE database_name FOR ATTACH 를 사용하는 것이 좋습니다 -




그러나,. 단일 mdf 파일만 가지고선 복구가 안되는 경우가 다른 서버나 경로에서 정상적인 분리없이 가져와진 단일 mdf 파일만 있는 경우 입니다. 정상적인 분리이었거나 원래 서버 및 경로인 경우에는 위와 같은 ldf 가 없더라도 정상적으로 로그파일이 생성이 됩니다.



그러나 비정상적인 경우에는 다음과 같은 메시지가 나오면서 작업진행이 더 이상안 되지요.. 물론 쿼리문으로 실행하는 것도 같습니다. 어차피 EM 으로 작동되는게 모두 쿼리문의 SQL Server 엔진에 전달이 되니깐요..


이런 경우 해당 데이터베이스 명의 로그파일을 바꿔치기 하는 방법으로 복구 가능합니다. 이러한 복구 방법은 이미 주의대상(Suspect) 모드에서의 복구 절차와 거의 같습니다.


1. 먼저 wssplex 와 동일한 이름의 데이터베이스를 만듭니다.
2. 그다음에,. SQL Server 를 종료한 다음에 원본wssplex 와 바꿔치기를 합니다.
3. SQL Server 서비스를 재시작 하면, 새로 생성된 ldf는 원본wssplex 의 원래 로그과 다르므로 아래와 같은 주의 대상 상태로 변경 됩니다.





4. 이때, 다음과 같은 쿼리문을 실행하여 wssplex 상태를 변경 시킵니다.

sp_configure 'allow updates',1
go
reconfigure with override
go
update sysdatabases set
status=-32768 where dbid=DB_ID('wssplex')
go
sp_configure 'allow updates',0
go
reconfigure with override
go

32768 은 데이터베이스 응급 모드로 상태를 변경하겠다는 것입니다.


5. 그다음으로, SQL Server 서비스를 종료 합니다. 그리고 현재 상태에서의 문제가 되는 로그파일을 삭제후 SQL Server 서비스를 재시작 하면 다음과 같이 응급 모드로 변경이 됩니다.




6. 이제 wssplex 데이터 베이스는 ldf 가 없는 읽기 가능한 상태로, 레코드 조회나 DTS 를 통해서 데이터 끌어갈수도 있게 되었으나 역시 읽기전용 모드 입니다.


7
. 현재 상태는 로그파일이 정상적이지 않은 상태이므로, 로그파일을 재생성을 해주면 되며, 다음과 같은 쿼리를 실행하고 완료후 wsspelx 는 이제 정상적인 데이터베이스가 되었습니다.

dbcc rebuild_log('wssplex','d:\wssplex_log.ldf')


경고: 'wssplex' 데이터베이스에 대한 로그가 다시 작성되었습니다.
트랜잭션에 일관성이 없습니다. 물리적 일관성을 검사하려면 DBCC CHECKDB를 실행해야 합니다.
데이터베이스 옵션을 원래대로 설정하고 다른 로그 파일을 삭제해야 합니다.
DBCC 실행이 완료되었습니다. DBCC에서 오류 메시지를 출력하면 시스템 관리자에게 문의하십시오.





물론 현재 다음과 같이 엑세스 제한 상태입니다.



이제 위 제한값만 체크 해제를 해주면 곧바로 사용할수 있겠네요..^^




최초 시도했던 attach 경로 및 데이터베이스 DB 및 로그파일이 생성이 완료 되었고 정상적으로 데이터베이스 이용이 가능해 졌습니다.!!

출처 : http://www.wssplex.net/TipnTech.aspx?Seq=470
2009/08/25 14:21 2009/08/25 14:21

Trackback Address :: 이 글에는 트랙백을 보낼 수 없습니다