一度に何百人ものユーザーがアクセスしている ms sql 2000 にデータベースがあります。Reporting Services 2005 を使用して同じデータベースにヒットする集中的なレポートがあります。
多くのレポートが実行されており、同時にデータベースを使用している人がいる場合、その状況でしばらくすると、システムがトランザクションにタイムアウトを与え始めるレベルまでプロセスがブロックされていることがわかります。
トランザクションの流れを継続できるように、ブロッキングを最小限に抑えるグローバルな方法はありますか。
レポートにはすでにNOLOCKヒントとREADUNCOMMITTED分離レベルを使用しているため、調査では、着信するトランザクションクエリに目を向ける必要があります。これは深くなる可能性があります。おそらく、アプリケーションがトランザクションを長時間開いたままにしている可能性があります。また、他のクエリボリュームの一部に多数のテーブルスキャンまたは範囲スキャンがあり、それらが長時間実行されるトランザクションの共有ロックを保持している場合もあります。これらの共有ロックは、ライターをブロックします。
sp_lockを調べて、未処理のロックの種類を確認し、ブロックされたクエリが取得しようとしているロックを確認してから、リクエスターをブロックしているクエリを調べる必要があります。
これは、SQLServerのロックに慣れていない場合に役立ちます 。SQLServer2000のロックについて
また、ディスクサブシステムについて説明することもできます。小さすぎるかもしれません。
レポートは使用できますWITH(NOLOCK)。
その他の可能性としては、レポートをデータベースの読み取り専用レプリカから実行するか、レポートのニーズに合わせて最適化されたデータベースのデータ ウェアハウス バージョンから実行することです。
更新が頻繁に発生せず、データベースが主にレポートに使用される場合は、楽観的ロックを使用します。
SQL Server には、非常に悲観的なロックの既定値があります。
SQL Serverのテーブル ヒントを調べると、手がかりになるかもしれません。
ご支援いただきありがとうございます。問題を軽減するために私たちが行ったことは、1 時間ごとにログ配布手順を使用して新しいデータベースを作成し、実際のデータベースとの同期を維持することでした。リアルタイム データを必要としないレポートはそのデータベースを指し、リアルタイム データを必要とするレポートは制限されているため、少数の人しかアクセスできません。この方法の欠点は、データが最大 1 時間同期されず、そのためだけに新しいサーバーを作成する必要があることです。また、loggshipping 手順が実行されると、すべての接続が非常に短い期間ドロップされますが、非常に長い手順やレポートでは問題になる可能性があります。この後、レポートからクエリを検証して、最適化できるものを理解できるようにします。ありがとうございます。IT 部門全体にこのサイトをお勧めします。