バックグラウンド:
3つのテーブルを含むSQL Server 2008 Enterprise Editionデータベースがあります。テーブルには、それぞれ300万行、1400万行、1450万行が含まれています。
問題:
レポート作成のために、データベースからデータを抽出する必要があります。これには、3つのテーブルを結合し、各行をテキストファイルに書き込む必要があります。このデータベースは現在本番トラフィックを使用しているため、パフォーマンスへの影響を制限したいと思います。このデータ抽出は、プロセスの過程で発生する読み取り、書き込み、または更新を妨げるべきではありません。
私が行った調査から、データ抽出クエリに「NOLOCK」ヒントを追加すると、データ抽出の主要なタスクを実行しながら、本番トラフィックを正常に動作させることができると思います。 「NOLOCK」ヒントに関連付けられたダーティリードがデータ抽出クエリに分離されることを想定しています。
データ抽出クエリの「NOLOCK」ヒントは特定の1つのクエリのみに影響を与えると私は思いますか?データ抽出クエリの実行中にデータベースで実行されているすべてのクエリに影響しますか?
上記で示したものよりも私の目標を達成するためのより良いアプローチはありますか?
このシナリオにアプローチできる多くの方法。
レポート作成のために、データベースからデータを抽出する必要があります。
データベーススナップショットはディスクのスペースを占有し、データが頻繁に更新される本番環境では特に、ディスクスペースが多すぎるとディスクスペースがいっぱいになる可能性があることに注意してください。さらに、データベーススナップショットを使用すると、書き込み操作が実行されるときにデータページがコピーされるため、データベースのI/Oが増加するため、パフォーマンスが少し低下します。
Microsoft SQL Serverデータベースのスナップショットとシノニム を参照して、スナップショットのいくつかの制限と回避策を克服してください。
最後に、どのオプションも実行できない場合は、適切なテストを行ってデータベースの分離レベルをRCSI(Read Committed Snapshot Isolation)に変更することを検討します。これはCOST of TEMPDBパフォーマンスになります。
-- check if RCSI is enabled
SELECT name, is_read_committed_snapshot_on
FROM sys.databases
WHERE name = '<dbname>'
-- Enable RCSI
ALTER DATABASE <dbname> SET READ_COMMITTED_SNAPSHOT ON
From データ読み込みパフォーマンスガイド :
RCSIは基本的に、ブロックするデータを読み取るクエリ、または同じテーブルのデータを変更する他のクエリによってブロックされるクエリを防ぎます。データの完全でトランザクション上一貫したビューを保証し、特別なヒントを必要としないため、NOLOCKの強力な代替手段です。 RCSIは元々、OLTPワークロードに共通するシナリオを対象としていましたが、この機能は、データウェアハウスのワークロードまたは大規模な一括挿入操作を含むシナリオで強力なツールになる可能性があります。
RCSIは、データベース全体の設定として有効になります。有効にすると、リーダークエリは行、ページ、またはテーブルの共有ロックを取得しないため、Xまたは他のユーザーが取得したBUロックによってブロックされません。代わりに、テーブルの新しい行または変更された行には17バイトのバージョン識別子が付けられ、トランザクションによって変更(更新または削除)された行の変更前イメージは、SQL Server内の行バージョン管理メカニズムを使用してtempdbにコピーされます。リーダークエリは、クエリの開始時点でコミットされた行のみを考慮します。それ以降のバージョン番号を無視し、適切な以前のバージョンの行のtempdbを参照します。
また、SQL CATチームからの RCSIとのさまざまな結果の比較とコミットの読み取り についても確認してください。
最後に、NOLOCKヒントに触れるために、私はあなたに読むことをお勧めします
「NOLOCK」ヒントに関連付けられたダーティリードがデータ抽出クエリに分離されることを想定しています。
ドキュメントを読むことを検討してください。
NOLOCKは、両方向にロックがないことを意味します-発行せず、尊重しません。つまり、いいえ、ダーティリードがあります。読み取り中にインデックス分割が発生すると、行が2回表示されることがあります。 BAAAAAD。
あなたができる最善のことは、別のデータベースにバックアップ/復元し、そこから作業することです。
データウェアハウス(レポート)が実装されており、OLTPビジネスデータベース-大規模なレポートが実行されない-「同じテーブルへの影響なし」の要件を満たせない)には理由があります。
Enterprise Editionを使用しているときに、データベーススナップショットを調べましたか?
データ抽出中の変更の量によっては、ディスク領域に問題が発生する可能性がありますが、完全なバックアップと復元を行わなくても、データを一貫して表示できます。
MSにはすべての詳細があります: http://msdn.Microsoft.com/en-us/library/ms189940(v = sql.100).aspx