これは私の最初の質問ですので、ご容赦ください。支払いとしてできる場合は、どこかで答えようとしますが、私のスキルがまだ十分かどうかはわかりません.
私は SQL 2008 にストアド プロシージャを持っていますが、現時点では約 600 の奇数行の結果で実行され、その中にユニオンがあり、複数回使用されるユーザー定義関数があります。法外なことは何もありません。クエリは、管理スタジオのクエリ ウィンドウを介して 7 秒で完了します。
BIDS 内で SSIS を作成すると、同じ SP がデータ フローの一部として OLEDB ソースとして使用されます。結果セットは Excel に出力されます。
同じクエリが実行前フェーズ内で 40 分ほどハングアップしてから完了します。
奇妙な癖があった場合に備えて、同じデータフローを再作成しようとしました。クエリ内のUDFを置き換えて、それが問題であるかどうかを確認しましたが、役に立ちませんでした。
問題が何であるか、または調査を進めるために私が何をすべきかについて、誰か考えがありますか。
敬具、
マット・H
spではなくソースとしてspでクエリを実行しようとしましたか? それは同じくらい遅いですか？
助けてくれたすべての人に乾杯。アップデート.......
昨日同様の問題に遭遇したため、昨日見つけた解決策は少し簡単だと思いました。
問題は、他の場所で言及されていることが判明しました-それは私の顧客データが基本的に悪い製品です。
パッケージ内のデータ ソースから実行されるストアド プロシージャは、インデックスにヒットする必要があります。これらのデータ ソースには、主キーを持つテーブルと対話するクエリがありますが、これらの特定のクエリの顧客データが不適切なため、結合で他のフィールドを参照する必要があるため、テーブル データに対していくつかのクリーニング タスクを実行し、一意のデータ テーブルを作成しました。それらから。
パッケージ内のデータ ソースから同じクエリを実行すると (主キーを参照する結合を使用)、数時間ではなく数秒で実行されるようになりました。
したがって、他の人々の同様の問題について私が読んだすべてのことは、テーブル全体がクエリされていることが原因であり、実行前の段階でそのようなことがおそらく真実に近いと推測されます........私にとっての解決策は、基礎となるデータを見て、きしむ音を出すことでした。
将来誰かに役立つことを願っています
マット・H
何が問題なのかわからない。結果を一時テーブルに出力してから、それらの結果をスプレッドシートに移動してみてください。