web-dev-qa-db-ja.com

SQL Server 2008 R2（要注意）モード-修復方法

SQL Server 2008 R2データベースをサスペクトモードで使用しています。私はこのクエリを実行してそれを修正しようとしました：

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

しかし、修復の出力は次のメッセージでした。

Warning: You must recover this database prior to access.
Msg 8921, Level 16, State 1, Line 5
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Warning: The log for database 'ServeDB' has been rebuilt. Transactional consistency has been lost. The RESTORE chain was broken, and the server no longer 
has context on the previous log files, so you will need to know what they were. You should run DBCC CHECKDB to validate physical consistency. The database has 
been put in dbo-only mode. When you are ready to make the database available for use, you will need to reset database options and delete any extra log files.
Msg 8921, Level 16, State 1, Line 9
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.

データベースを完全に修復する方法は？私が行ったこの修復は数日間しか機能せず、データベースは再び疑わしいモードになります...

sql-serversql-server-2008-r2corruptiondbcc
5
Vytas999

私は同様の問題に遭遇しました。ただし、バックアップも疑わしいため、データベースを疑わしくすることはできませんでした。 SSMSのエクスポート機能を使用して、テーブルとデータを新しい空のデータベースに移動しました。

ただし、これによってすべてのストアドプロシージャ、ビュー、関数などが移動するわけではありません。すべての構造の移行を処理するRedGateのSQL Compare（SQLスキーマを定期的に操作するすべての人に強くお勧めします）のコピーがあります。そのため、プロセスはかなり簡単になりました。 RedGateを使用する必要がある場合は、RedGateのソフトウェアを14日間試用できます。

テーブルや少量のプロシージャ、ビューなどがある場合、SSMSの「スクリプトの生成」機能を使用してこれらのアイテムの作成スクリプトを作成し、新しいDBで実行できます。

RedGateのSQL比較： http://www.red-gate.com/products/sql-development/sql-compare/

5
AJ Piscitelli

このデータベースは修復できません。また、実行した可能性のある修復が完了していません。 理由データベースが破損していることを必ず理解してください。ディスクシステムをチェックしてください。これが最も可能性の高い原因です。

次に、バックアップからデータベースを復元します。ただし、そのバックアップ自体でDBCC CHECKDBを実行して、データベース自体が破損していないことを確認してください。

REPAIR_ALLOW_DATA_LOSSを使用したDBCC CHECKDBは、これまでに行くべき最後の手段です。その前に、有効なバックアップを復元する必要があります。 REPAIR_ALLOW_DATA_LOSSを使用した後は、データベースが魔法のように再び復活するとは思わないでください。この場合、特にシステムテーブルの破損について不平を言っているため、修復不可能な損傷が発生している可能性があります。

7
Mark S. Rasmussen

ポール・ランダルが推奨するものを試しましたか？ 疑わしいデータベースの作成、切り離し、再接続、修正

  1. まったく同じファイルレイアウトで、デタッチされたデータベースのファイルサイズにできるだけ近い新しいダミーデータベースを作成します。
  2. SQL Serverをシャットダウンする
  3. 破損したデータベースファイルを交換する
  4. SQL Serverを再起動します
  5. 緊急モードの修復を使用する
6
Carol Baker West