0

リアルタイムレポートの近くで実行する必要のあるログテーブルがあります。主キーは、非順次挿入されるGUIDです。レポート速度を支援するために他のインデックスが追加されると、挿入でタイムアウトが発生します。レポートインデックスを使用して複製テーブルを作成し、ログテーブルのにフィルファクターが75％のクラスター化インデックスのみを残すことを計画しています。

レプリケーションを使用するのは、1つのテーブルだけではやり過ぎだと思います。だから私の質問は、これをどのように達成する必要があるのか​​ということです。SQLエージェントジョブをスケジュールする必要がありますか？

どんな助けでも素晴らしいでしょう！ありがとう！

4

1 に答える 1

2

利用できるオプションはたくさんあります。差し迫った問題を解決するために、ロギングテーブルにシーケンシャルIDが設定されていることを確認し、新しいデータのみを適切にインデックス付けされたレポートテーブルにコピーします。次に、NON-LOCKING procを実行して、レポート内の対応する列の最大値だけを取得し、ログテーブルからさらに大きな値を取得できます。

DECLARE @MaxValue uniqueidentifier

SELECT @MaxValue = MAX(LogID) FROM LogTable

INSERT INTO 
   ReportingTable
   (...)
SELECT
   ...
FROM
   LogTable WITH NOLOCK
WHERE
   LogID > @MaxValue

注意：NOLOCKの議論については、これを参照してください。ログテーブルがBIGおよびBUSYの場合にのみ使用してください。ただし、シナリオはそれが理にかなっている例です。

何がGUIDを生成するかはわかりませんが、SQLサーバーの場合、列をデフォルトでNEWSEQUENTIALID（）にすると、完全にランダムではなく、シーケンシャルになります。他の場所からGUIDを取得している場合は、bigint IDENTITY（1,1）列を配置して、クラスター化インデックスがひどく断片化されていないことを確認することを検討してください。フラグメント化されたクラスター化インデックスは、他のインデックスがルックアップに使用するため、問題があります。そのため、インデックスがどれほど優れていても、プライマリよりも実行速度が遅くなります。

次に、GUIDのクラスター化インデックスを使用して、レポートテーブルを任意の方法で構造化し、適切にインデックス付けされたテーブルの最大値を使用して、まだ持っていない新しいデータのみを挿入できます。そのテーブルで再インデックスを実行して、可能な限り高速にすることもできます。

詳しくは..

システムが大幅に成長すると予想される場合は、他のレポートパターンを調べて、データをレポートテーブルにダンプするときに、データを非正規化または単純化する必要があります。

星のパターンを見てください。または、毎日または毎週の統計を次のような別のテーブルに非正規化することができます。

Date, TimespentTotal, TimespentAvg, UserFact2Count....

次に、非ロックのストアドプロシージャを実行して、一度に1日の統計を取得できます。また、実行するエージェントジョブが失敗した場合に備えて、レポートデータベースにないものに基づいて日数の統計をロードすることをお勧めします。次に実行するときに、バックログが処理されます。明らかに、これらのパターンははるかに手間がかかり、間違った選択は悪い場合があるため、レポートに何が期待されるかを知る必要がある場合にのみ、この選択を行ってください。

于 2012-04-26T22:18:08.840 に答える