一括挿入時間の大きなばらつき

そのため、ステージングテーブルからデータを取得してデータマートに移動するための単純な一括挿入プロセスがあります。

このプロセスは、「バッチあたりの行数」のデフォルト設定を持つ単純なデータフロータスクであり、オプションは「tablock」および「チェック制約なし」です。

テーブルはかなり大きいです。データサイズが201GBでインデックススペースが49GBの587,162,986。テーブルのクラスター化インデックスは次のとおりです。

CREATE CLUSTERED INDEX ImageData ON dbo.ImageData
(
    DOC_ID ASC,
    ACCT_NUM ASC,
    MasterID ASC
)

主キーは次のとおりです。

ALTER TABLE dbo.ImageData 
ADD CONSTRAINT ImageData 
PRIMARY KEY NONCLUSTERED 
(
    ImageID ASC,
    DT_CRTE_DOC ASC
)

現在、BULK INSERTSSIS経由の実行速度が非常に遅いという問題が発生しています。100万行を挿入するのに1時間。テーブルに入力するクエリは既にソートされており、入力するクエリの実行には1分もかかりません。

プロセスの実行中に、5〜20秒かかり、次の待機タイプを示すBULK挿入を待機しているクエリを確認できます。 PAGEIOLATCH_EX。プロセスは、一度にINSERT約1000行までしか実行できません。

昨日、このプロセスをUAT環境に対してテストしているときに、同じ問題に直面していました。私はプロセスを数回実行し、この遅い挿入の根本原因を特定しようとしました。その後、突然5分未満で実行が開始されました。それで、私はそれをさらに数回実行しましたが、すべて同じ結果になりました。また、5秒以上待機していた一括挿入の数は、数百から約4に減少しました。

今、これは私たちが活動を大幅に落としてしまったというわけではないので困惑しています。

期間中のCPUが低い。

遅いときは、ディスクでの待機が少ないように見えます。

プロセスが5分未満で実行されていた時間枠の間に、実際にはディスク遅延が増加します。

また、このプロセスの実行が不十分な間、IOはずっと低くなりました。

すでに確認しましたが、ファイルが70％しかいっぱいになっていないため、ファイルの増加はありませんでした。ログファイルの残りは50％です。DBはシンプルリカバリモードです。DBには1つのファイルグループしかありませんが、4つのファイルに分散しています。

私が疑問に思っていることA：なぜ、これらの一括挿入でこんなに長い待ち時間が見られたのか。B：実行速度を上げるためにどのような魔法が発生しましたか？

サイドノート。今日もがらくたのように走ります。

現在パーティション化されているUPDATE。しかし、それはせいぜい愚かな方法で行われます。

CREATE PARTITION SCHEME [ps_Image] AS PARTITION [pf_Image] 
TO ([FG_Image], [FG_Image], [FG_Image], [FG_Image])

CREATE PARTITION FUNCTION [pf_Image](datetime) AS 
RANGE RIGHT FOR VALUES (
      N'2011-12-01T00:00:00.000'
    , N'2013-04-01T00:00:00.000'
    , N'2013-07-01T00:00:00.000'
);

これにより、基本的にすべてのデータが4番目のパーティションに残ります。ただし、すべて同じファイルグループに送信されるためです。現在、データはこれらのファイル間でほぼ均等に分割されています。

更新2 これらは、プロセスの実行が不十分な場合の全体的な待機です。

これは、プロセスを実行できた期間中の待機時間です。

ストレージサブシステムはローカルに接続されたRAIDであり、SANは関係しません。ログは別のドライブにあります。RAIDコントローラーは、キャッシュサイズが1 GBのPERC H800です。（UATの場合）ProdはPERC（810）です。

バックアップなしのシンプルなリカバリを使用しています。本番コピーから毎晩復元されます。

IsSorted property = TRUEデータは既にソートされているため、SSISで設定しました。

原因を特定することはできませんが、BULK INSERT操作のデフォルトのバッチごとの行数は「すべて」であると考えています。行に制限を設定すると、操作がより消化しやすくなります。そのため、これがオプションです。（これからも、Transact-SQLの「BULK INSERT」ドキュメントを参照しているので、SSISの方がいいかもしれません。）

これは、操作をX行の複数のバッチに分割し、それぞれが個別のトランザクションとして動作するという効果があります。エラーがある場合、終了したバッチは宛先テーブルにコミットされたままになり、停止されたバッチはロールバックされます。それがあなたがしていることに耐えられる場合、つまり、後でそれを再実行して追いつくことができるなら、それを試してください。

現在のすべての挿入を1つのテーブルパーティションに配置するパーティション関数を使用することは間違いありませんが、同じファイルグループ内のパーティションでパーティション分割するのがどのように役立つかわかりません。日付時刻の使用は貧弱であり、実際にはSQL Server 2008以降、明示的なCONVERT式なしで日付時刻と 'YYYY-MM-DD'に対して壊れています修正して「YYYYMMDD」に変更するか、CONVERT（datetime、 'YYYY-MM-DDT00：00：00'、126）、そうだと思います）。ただし、日付値（年をint、または年+四半期）にプロキシを使用してパーティション分割する方が適切だと思います。

他の場所からコピーされたデザイン、または複数のデータマート間で複製されたデザインかもしれません。これが真のデータマートである場合、部門マネージャーに再生するデータを提供するためのデータウェアハウスからのダンプであり、それは（ユーザーによって）他の場所に送信されず、データユーザーに関する限り、おそらく読み取り専用です、その後、パーティション関数を削除するか、またはそれを変更して、すべての新しいデータを明示的に4番目のパーティションに入れることができるように思えます。（おそらく、誰も気にしないことを確認する必要があります。）

パーティション1の内容を将来的にドロップし、さらに新しいデータ用に別の新しいパーティションを作成するという計画のように感じますが、ここで起こっているようには思えません。少なくとも2013年以降は発生していません。

大きなパーティションテーブルへの挿入時に、これと同じ散発的な極端な遅延が発生することがあります。宛先テーブルの統計を更新してから、もう一度実行してみましたか？極端な待機時間は、統計情報の不足が原因である可能性があり、テスト中のある時点で統計情報の更新がトリガーされた場合、速度の向上が説明されます。ただ考えて検証する簡単なテスト。