이 문서에서는 SQL Server 의심스러운 데이터베이스를 해결하는 방법에 대해 설명합니다. 때때로 데이터베이스가 실수로 의심스러운 것으로 표시됩니다. 1. 먼저 .mdf 및 .ldf 파일이 백업되었는지 확인합니다.
2. SQL Server에서 동일한 이름을 가진 새 데이터베이스를 생성한 다음 SQL Server 서비스를 중지합니다.
3. 새 데이터베이스에 해당하는 .mdf 및 .ldf 파일을 원본 .mdf 및 .ldf 파일로 덮어씁니다.
4. SQL Server 서비스를 다시 시작하면 데이터베이스가 의심되는 상태인지 확인해야 합니다.
5. SQL 쿼리 분석기에서 다음 명령을 실행하여 시스템 테이블을 업데이트할 수 있습니다.
mastergosp_configure '업데이트 허용'을 사용하고, 재정의로 재구성하고
6. 이 데이터베이스를 비상 모드로 설정합니다.
sysdatabases 설정 상태 = 32768 업데이트, 여기서 이름 = 'db_name'go
7. DBCC CHECKDB 명령을 사용하여 데이터베이스의 오류를 확인합니다.
DBCC CHECKDB('db_name')GO
8. DBCC CHECKDB 명령이 실패하면 10단계로 이동하고, 그렇지 않으면 복구를 시도하기 전에 데이터베이스를 단일 사용자 모드로 설정합니다.
sp_dboption 'db_name','단일 사용자','true'DBCC CHECKDB('db_name', REPAIR_ALLOW_DATA_LOSS)GO
DBCC CHECKDB('db_name', REPAIR_ALLOW_DATA_LOSS) 명령을 실행할 때 데이터베이스가 단일 사용자 모드가 아니라는 메시지가 표시되면 SQL Server 서비스를 다시 시작하고 계속 시도하세요.
9. DBCC CHECKDB('db_name', REPAIR_ALLOW_DATA_LOSS) 명령이 실패하면 10단계로 이동하고, 그렇지 않으면 데이터베이스 오류가 성공적으로 복구된 경우:
DBCC CHECKDB('db_name') 명령을 다시 실행하여 데이터베이스에 오류가 없는지 확인합니다.
데이터베이스의 의심되는 상태 지우기: sp_resetstatus 'db_name'
데이터베이스의 단일 사용자 모드 상태 지우기: sp_dboption 'db_name','single user','false'
SQL Server 서비스를 다시 시작합니다. 모든 것이 정상이면 데이터베이스가 성공적으로 복원된 것입니다.
10. 위 단계를 수행해도 문제가 해결되지 않는 경우 첨부 문서를 참조하신 후 트랜잭션 로그를 재구축하여 데이터베이스의 데이터를 복원해 보시기 바랍니다. MDF 파일만 있는 경우 문제는 더욱 복잡해지며 트랜잭션 로그를 직접 다시 작성해야 합니다.
1. SQL Server에서 동일한 이름을 가진 새 데이터베이스를 생성한 다음 SQL Server 서비스를 중지합니다.
2. 원본 ldf 파일을 사용하여 새로 생성된 데이터베이스에 해당하는 .mdf 파일을 덮어쓰고 해당 로그 파일(.ldf)을 삭제합니다.
3. SQL Server 서비스를 시작하고 데이터베이스를 긴급 모드로 전환합니다(위와 동일: 5단계 및 6단계).
4. SQL Server 서비스를 중지했다가 다시 시작합니다.
5. 다음 명령을 실행하여 데이터베이스 로그 파일을 다시 작성하십시오. (다음은 예입니다. 실제 데이터베이스 이름을 사용해야 합니다.)
DBCC REBUILD_LOG('cas_db', 'D:cas_dbcas_db_Log.LDF')
6. 데이터베이스를 단일 사용자 모드로 교체합니다.
7. DBCC CHECKTABLE 또는 DBCC CHECKDB 명령을 사용하여 다시 시도하여 데이터베이스의 오류를 확인하고 수정합니다.
-