web-dev-qa-db-ja.com

CheckDB操作が失敗し、エラーが返される

メンテナンスウィンドウ中にCheckDBを実行すると、過去2か月間に障害が発生し始めたデータベースがあります。失敗後に再実行すると、毎回正常に完了します。

何が起こっているのか、そしてこれまでに何をしたのかを詳しく説明する前に、環境について少し説明します。

SQL Server 2008 R2 SP3 Enterprise/Windows Server 2008 R2Enterpriseで実行しています。このインスタンスには、従来のDW(ディメンションデザインを構成するビューを持つリレーショナルデザイン)が含まれています。 CheckDBが失敗するたびに、同じデータベースと同じファイルグループで失敗します。データベースサイズは7.5 TBで、218個のファイルグループで構成されています。これが失敗するたびに問題となるファイルグループが1つあり、641GBです。ファイルグループは現在I:ドライブにあります。 2.7 TBドライブ。

これが私たちが得ているエラーのいくつかです–

オペレーティングシステムは、ファイル 'I:\ MSSQL\SQLDATA\FG_A.ndf:MSSQL_DBCC13'のオフセット0x0000002ece0000での書き込み中に、SQL Serverにエラー665(ファイルシステムの制限のため、要求された操作を完了できませんでした)を返しました。
SQL Serverエラーログおよびシステムイベントログの追加メッセージにより、詳細が提供される場合があります。これは、データベースの整合性を脅かす深刻なシステムレベルのエラー状態であり、すぐに修正する必要があります。完全なデータベース整合性チェック(DBCC CHECKDB)を完了します。このエラーは多くの要因によって引き起こされる可能性があります。詳細については、SQL Server BooksOnlineを参照してください。

I:\ MSSQL\SQLDATA\FG_A.ndf:MSSQL_DBCC13:オペレーティングシステムエラー665(ファイルシステムの制限により、要求された操作を完了できませんでした)が発生しました。
コマンド:DBCC CHECKDB([DatabaseA])WITH NO_INFOMSGS、ALL_ERRORMSGS、DATA_PURITY Msg 5269、レベル16、状態1、サーバーServerA、行1
チェックが終了しました。データベース 'DatabaseA'(データベースID 6)の一時的なデータベーススナップショットは、IO操作の失敗により、疑わしいとマークされました。詳細については、SQLServerエラーログを参照してください。

Sqlcmd:エラー:Microsoft SQL Native Client:不特定のエラー。
内部データベーススナップショットには、分割点LSN = 003f2ecc:00003498:0001と最初のLSN = 003eb426:00002f58:0001があります。


私が最初に注意したいのは、失敗後にこれを手動で再実行したときはいつでも(そして多くの場合)、これは決して失敗しないということです。明らかに非常に長い時間がかかりますが、エラーなしで完了します。

今、私へのエラーは、ファイルシステムの制限のためにこれが失敗したことを示しています。 CheckDBを実行するときは、チェックするデータベースの一貫したビューが必要です。これを行うために、非表示のデータベーススナップショットを作成します。メッセージ:

内部データベーススナップショットには、スプリットポイントLSN = 003f2ecc:00003498:0001と最初のLSN = 003eb426:00002f58:0001 "があります。

..スナップショットが作成されたポイントを示します。

このエラーは失敗と同時に発生したため、一時スナップショットを作成するための十分なスペースがドライブにないために失敗したようです。監視を見ると、障害時に使用されたスペースの増加は見られませんでしたが、最初に使用可能なスペースの量を確認した場合、スペースの増加は見られない可能性があります。 CheckDBを手動で実行した場合でも、スペース使用率に大きなスパイクは見られません。

ファイルグループはI:ドライブにあり、ドライブのスペースが少し不足していたため、快適なギャップを作成するためにドライブを拡張しました。現在、2.7 TBドライブには515GBの空き容量があります。それを行った後も、まだ問題がありました。

より小さなドライブを作成し、ファイルグループを実際よりも多く分散させることを検討しましたが、このデータベースに送信されるSQLトランザクションレプリケーションが大量にあります。したがって、デタッチ、ファイルの移動、および再アタッチを行うと、レプリケーションが中断されると思われるため、実行していません。ただし、これで問題が解決するかどうかはわかりません。

私も走りましたDBCC CheckDB WITH ESTIMATEONLYそして、CHECKALLOCに必要な推定TempDBスペースとして1.5GBを返し、CHECKTABLESに必要な推定TempDBスペースとして1KBを返しました。古いバージョンのSQLでは、これはあまり正確ではないと思いますが、先に進んで確認しました。

また、このサーバーにはSANストレージを使用します。古いストレージデバイスで問題が発生し始め、現在すべてのSQL Serverを移動している新しいストレージデバイスに移動したところ、問題は解消されました。数週間後、再開しました。これは2つの完全に別個のストレージデバイスで発生し、両方に問題があります。さらに、これらのストレージデバイスで実行されているものがいくつかあり、他の場所ではこの問題は発生していません。

いくつかの調査を行った後、問題に役立つと思われる製品の修正プログラムを実行しました。

NTFSボリューム内の大きく断片化されたファイルは、特定のサイズを超えて大きくなることはありません

これを適用するプロセスを実行しましたが、問題は解決しませんでした。

エラーは、障害がファイルシステムの制限によるものであることを示しているようですが、その制限が何であるかを判断することはできません。 ORいくつかのアラートのように、実際の問題を実際に示していない一般的なエラーが発生しているだけです。

システム管理者とストレージ管理者に確認して、これに影響を与える可能性のある重い操作がバックグラウンドで発生していないことを確認しました。これまでのところ、何も決定されていません。

週末のスケジュールを可能な限り調整して、違いが生じるかどうかを確認しましたが、違いがあるかどうかはわかりません。私たちが探しているべき場所が他にあるかどうか、または私たちが見逃している可能性のあるものがあるかどうかを確認するために皆さんに確認したかったのです。ありがとう

エラーの履歴を確認したところ、CheckDBが同じ曜日のほぼ同じ時刻に同じエラーで失敗することがわかりました。現時点で何かが起こっているかどうかを確認するために、管理者にもう一度確認します。

1
Dustin

@ Nic's の情報を複製したくなかったので、これは彼の提案を補足するものになります。

オペレーティングシステムがエラー665を返しました...

NTFS上のスパースファイルに関する一般的な問題。ちょっと待ってください、この答えはずっと良くなります。

いくつかの調査を行った後、問題に役立つと思われる製品の修正プログラムを実行しました...これを適用するプロセスを実行しましたが、問題は解決しませんでした。

それが私が期待することです。これは、修正プログラムがNTFSファイルシステムの/ Lオプション(大きな属性記述子)にsupportを追加するためです。これが素晴らしい部分です。このオプションを使用してボリュームをフォーマットすることによってのみ有効にできます。したがって、もちろん、ボリュームがこのオプションでフォーマットされていないため、役に立ちませんでした。

新しいボリュームを作成し、/ Lでフォーマットし、ファイルをコピーするか、サードパーティのアプリケーションを使用してtryしてファイルを圧縮することができます(メタデータも圧縮する必要があります)、それが機能するかどうかを確認します。さらに、NTFSアロケーションユニットサイズが大きくなると(SQL Serverの場合)、NTFSメタデータの断片化がはるかに少なくなります。

3
Sean Gallardy

破損の問題ではなく、問題は、DBCCコマンドがデータベースの内部スナップショットを取得して(一貫性の理由で)それをチェックすることによって引き起こされるスパースファイルの制限です。これを解決するには、実際には2つの方法しかありません。

  • スナップショットの代わりにデータベース内のオブジェクトに排他ロックを使用するDBCC CHECKDB WITH TABLOCKを実行します。これの欠点は、チェックされているオブジェクトがデータベースでブロックされることです。これは、トランザクションフローに深刻な影響を与える可能性があります。
  • 各テーブルのチェックをDBCC CHECKDB WITH PHYSICAL_ONLY、次にDBCC CHECKTABLEに分類します。これにより、スナップショットの存続時間が短縮されます。ここでの難しさは、CHECKTABLEを管理して、スレッドプールの問題を引き起こす可能性があるため、(小さなテーブルの場合)それらを実際に迅速に実行しないようにすることです。 Minionware CheckDB (free)のようなものを見てみることをお勧めします。これは、多くの手間のかかる作業を行うことができます。
1
Nic