データベースへのアクセスは可能ですが、トラフィックがほとんどない夜間に、定期的なDBCC CHECKDBを実行しています。先月以降、DBCC CHECKDBがこのエラーでクラッシュすることが何度かありました。
エラー状態5が原因で、sqladminによって実行されたDBCC CHECKDB(データベース1)WITH no_infomsgsが異常終了しました。経過時間:0時間47分9秒。
この前に、リソースが不十分であるいくつかのSQLアラート重大度17、およびSQLサーバーログのDBCC MEMORYSTATUSからの出力が続きます。したがって、メモリ不足が原因でDBCC CHECKDBがクラッシュすると思います。
DBCC CHECKDBを再度実行しても、エラーは返されません。 DBA以外のユーザーは、営業時間中に1回でも実行しましたが、パフォーマンスが低下し、完了するまでに3時間近くかかりましたが、メモリの問題は発生しませんでした。 (彼は二度とそれをしないように言われた)。
サーバー自体には12GBのRAMがありますが、SQサーバーに設定された最小および最大の制限はありません。 SQL Server自体は約10 GBのメモリを使用しますが、他のすべてのプロセスは1 GBを使用します。その時点でサーバーに負担をかける他のことは知りません。
編集:
「先月以来、DBCC CHECKDBがこのエラーでクラッシュすることが何度かありました...」という文は、先月、システムでこれを引き起こした可能性のある変更があったと思います。先月、あなたの知る限りで何か実装されましたか?たとえば、パッチ、SQL Serverの更新、およびアプリケーションがSQL Serverにインストールまたはアップグレードされたなどです。
以下の投稿を試して、問題がOSメモリの問題であるかどうか、またはエラーの原因がSQLであるかどうかを確認しましたか?
リソースの制約を緩和するために、DBCC CheckDBコマンドを分割してみることができます。
そこで、より低い最大メモリ設定を設定し、サーバーを監視することにしました。 CHECKDBを50分間実行した後、svchost.exeの1つがページフォールトを取得し始め、空きメモリが2GBから0にすぐに低下します(ただし、プロセス自体は300MBしか使用していませんでした)。混乱は約1分続き、その後システムは落ち着きます。今回はCHECKDBが中断されなかったため、sysadminはこの問題の原因となっている基盤となるサービスを確認するように求められます。約1か月前に新しい監視ツールがインストールされました。