私は多くのタグと属性を持つ約800 MBの大きなXMLファイルを持っています。このファイルから別の値を引き出す必要があるため、多くのSORTとJOINの変換を使用しました。それらのすべてはうまくいき、後でSORTの変形が赤い楕円形で表示されていることを除いて、時間がかかりすぎません。これは永遠にかかります。私は小さいXMLファイルを使用する場合、それはスルー行くと、あまりにも多くの時間がかかることはありませんSORT変換には永遠にかかります
。だから私は問題は、そのデータセットのサイズを扱っていると仮定します。あなたがこのような状況に対処するのに役立つ方法を知っているかどうか疑問に思っていました。この特定のケースのパフォーマンスを向上させるために変更する必要があるプロパティ。私はVisual Studio 2015を使用しています。ありがとう！
SSISで並べ替えの変換を高速化することは実際にはあまりできません。最良の解決策は、ソート変換をまったく使用する必要がない方法を見つけることです。これは、通常、データを索引付きデータベース表に入れ、SELECT ... ORDER BY問合せでソートを実行することを意味します。
ありがとうございます。残念ながら、 'SORT'を避けることは、OLE DBソースとMergeからいくつかの状態名を取得するためにMERGE JOINを使用する必要があるため、私にとってはオプションではないようです。私はまた、このためのETLテーブルを作成する権限を持っていないし、それが私の最後のオプションになることを求める。 – TheEsnSiavashi
状態名をマージしていて、マージする可能性のある名前が約50程度しかない場合は、マージ結合ではなく参照変換の方がパフォーマンスが向上する可能性があります。特に、状態名が変更されず、したがってキャッシュすることができる場合。ルックアップの前に入力行をソートする必要はありません。 –
私もこれについて考えましたが、 'MERGE JOIN'は' left join'を行います。 'LOOK UP'は私にマッチングとノンマッチングを与えます。私はとにかく 'LOOK UP'が左の結合として動作することは知りません。 – TheEsnSiavashi
SQLクエリを作成し、Exec SQLステップを使用してルックアップとマージを行う代わりに状態値を更新することを検討しましたか？また、すべてのソースXMLですか？そうであれば、ある時点で実際のテーブルにピボットすることができます。パフォーマンスが向上します。 –
@ JacobHあなたが提案しているものが得られていない場合は私を修正してください。しかし、私は "更新"していないし、 "検索"もしていません。私はちょうど状態のIDに基づいて状態名を結合するために状態の小さなテーブルを照会しています。ここでExec SQLタスクをどのように使用できるかわかりません。 – TheEsnSiavashi
データをルックアップしていない場合、なぜ "LKP"と呼ばれるステップがありますか？ :)私の質問は立っています。あなたは、さまざまなデータソースから膨大な量のマージとソートを持っていて、他のものよりも速度が遅い以外の情報は私たちに与えていません。 –