4つのファイルグループ(ボリュームごとに1つ)の検索テーブルを作成するタスクが割り当てられているため、ETLプロセス中に、ファイルグループの読み取りと書き込みが同時に行われないように配置されます。
すべてのパッケージ、データフローのタスク、手順、およびビューを確認し、どのテーブルがどの順序で読み取られているかを確認しました。
ここで、テーブルの最適な配置を決定するためのクエリを作成する必要があります。
論理的には次のようなものがありますが、次のルールに分解します。
シーケンスごとに、ソーステーブルと宛先テーブルを同じボリュームに配置することはできません。テーブルは複数のボリュームに存在できません。
このプロセスが価値があるかどうかについての人々の意見を聞くことに興味がありますが、それにもかかわらず、質問を解決するための助けをいただければ幸いです。
以下に、テーブルを作成してテストデータを挿入するためのスクリプトを示します。
提案を事前に感謝します。
-- Create table
CREATE TABLE [dbo].[TestData]
(
[TestDataID] [smallint] IDENTITY(1,1) NOT NULL,
[Src] [nvarchar](50) NOT NULL,
[Dest] [nvarchar](50) NOT NULL,
[Seq] [int] NOT NULL,
CONSTRAINT PK_TestData PRIMARY KEY CLUSTERED (TestDataID)
)
GO
-- Insert data
INSERT INTO TestData(Src, Dest, seq)
SELECT 'A', 'B', 1
UNION ALL
SELECT 'A', 'C', 1
UNION ALL
SELECT 'C', 'D', 2
UNION ALL
SELECT 'A', 'D', 3
UNION ALL
SELECT 'B', 'D', 3
GO
悪いニュース。 ETLプロセスについておっしゃいましたが、これは大量のデータの読み込みを意味し、挿入/更新/削除には、トランザクションログファイルという1つのディスクボトルネックがあります。複数のトランザクションログファイルを追加できますが、それらは順次使用され、負荷分散されません(一部の 実際にはエッジケースのシナリオ を除く)。
代わりに、必要なのは複数のデータベースです。データウェアハウスでは、通常、ステージングデータベースなど、宛先データベースとは異なるソースデータベースを使用します。そうすれば、データベースをさまざまなドライブ(さらにはさまざまなクラスのドライブ)に配置できます。たとえば、一部のステージングデータベースは安価なローカルSSD上にあります。
データファイルの読み取りまたは書き込みでストレージのボトルネックが発生している場合は、メモリを追加するか(データをキャッシュして読み取りを完全に回避するため)、データをより多くのドライブにストライピングすることで、その問題を解決することをお勧めします。データファイルを小さな部分に分割し、それぞれに少ないドライブを割り当てることで、通常、問題が悪化します。