企業での SSIS パッケージ データ フローのチューニング (SQL Server ビデオ)
適用対象 : Microsoft SQL Server Integration Services |
作成者 : デイビッド ノーア、Microsoft Corporation |
再生時間 : 00:15:50 サイズ : 68.1 MB 種類 : WMV ファイル |
ビデオの概要
このビデオでは、Integration Services パッケージでデータ フローのパフォーマンスを向上させる方法を説明します。このビデオでは、データ フローの次の各フェーズをチューニングする方法を学習します。
- 抽出
- 変換
- 読み込み
データ フローのデザイン、開発、および実行の際に、これらのパフォーマンス チューニング ヒントを適用できます。
謝辞
「SSIS : パフォーマンス向上のためのデザインとチューニングに関する SQL Server ビデオ シリーズ」の資料提供においては、トマス カイザー氏にご協力いただきました。これは、当シリーズの 2 番目のビデオです。
カルラ サボータ氏とダグラス ラウデンシュラーガー氏からは、アドバイスと貴重なフィードバックを頂きました。ありがとうございました。
ビデオの内容
| ビデオのタイムスタンプ | 音声 |
|---|---|
00:00 |
こんにちは。デイビッド ノーアです。ここ Microsoft で SQL Server Integration Services のシニア ディベロップメント リードをしています。当ビデオ、「企業での SSIS パッケージ データ フローのチューニング」をご覧くださいましてありがとうございます。 これは、「SSIS : パフォーマンス向上のためのデザインとチューニング」という 4 部構成シリーズの 2 番目のビデオです。シリーズの第 1 回では、デニーが SSIS パッケージのパフォーマンスを適切に測定して理解する方法を説明しました。この回では、それを基に、SSIS パッケージ データ フローのパフォーマンスを向上させる方法を見ていきます。まず、すべてのデータ フローに共通のテーマを特定し、パフォーマンスを向上させるために最初に調整する必要があるデータ フロー部分を選択する方法を確認します。パフォーマンスの問題が発生している箇所を特定できると、データ フローをより速く効率的に実行するために、さまざまな対策を講じることができます。ここでは、データ フローのデザイン、開発、さらには実行に際して適用できる、一連の具体的なヒントを確認します。 それでは見ていきましょう。 ほとんどのパッケージ データ フローでは、ETL とも呼ばれる、抽出、変換、読み込みの処理を重要なデータに対して行います。データ フローのチューニングでは、このようなデータ フローの抽出、変換、読み込みという各フェーズをチューニングします。 抽出では、SSIS ソース コンポーネントとそれらによって実行されるクエリをチューニングすることによって、ソース システムに対する影響を最小限に抑えながらパフォーマンスを最大化する方法を説明します。 データ フローにおける変換のチューニングでは、行う必要がある作業を確認し、その作業を行う最適な方法を選択します。ここでは、不要な手順を排除すると共に、自動で変換が行われるように元のソース クエリを適宜変更します。 最後に、データ フローの読み込み処理のチューニングとして、SSIS 変換先コンポーネント、ネットワーク、ロックなど、データを変換先に読み込む際にデータ フロー処理の妨げとなる可能性がある要素をチューニングします。 このビデオでは、データ フローの 3 つのフェーズすべてを対象に、チューニングが必要な箇所を探すために役立つ、実用的なヒントを説明します。 これらのヒントを確認する前に、1 つ理解しておくことがあります。それは、通常、パフォーマンスの問題に対処するときに確実な方法はないということです。ここで説明するヒントをどれか使用して、データ フローで発生するパフォーマンスの問題をすべて修正できるわけではありません。一般的なケースでは、ここで説明するヒントが役立ちますが、個々の問題は、単に多数のヒントを使用するだけでは解決しません。最も確実なのは、常にデータ フローの意図を理解し、その目的に合うようにデータ フローを適切にデザインすることです。この場合、現在のパフォーマンスを測定した後で、データ フローに対して何度も変更を加えながら、その変更によってパフォーマンスが向上したかどうかを測定します。 また、パフォーマンスの問題を確認する際、よく知っているテクノロジやコードがある場合などに、そうした特定のテクノロジやコンポーネントにばかり目を向けがちです。しかし、どんな理由があるにせよ、生態系全体、つまり、一般的には複数のリレーショナル データベース、ネットワーク、オペレーティング システム、ファイル システムといった多数の要素を含んだコンテキストを念頭に置いて、データ フローを検討するようにします。この生態系全体を詳しく知れば知るほど、いずれかの要素が直面している実際のパフォーマンスの問題に関して、より完全な状況を把握できるようになり、より効率的かつ安全な変更を行えるようになります。 |
03:38 |
それでは、データ フローの開始点である抽出から見ていきましょう。ソースとして SQL Server または他のデータベースをバルク インターフェイスで使用する場合は、パケット サイズを大きくしてみてください。通常は、SQL Server の既定値 "4096" で問題なく動作しますが、抽出により大量のデータを移動するため、この値を増やす方が賢明です。これを有効にするには、ネットワーク管理者に依頼してネットワークで "特大のフレーム" を有効にする必要があります。ただし、パッケージでこの効果をテストすることが必要です。OLE DB ソースのような一括操作と (OLE DB コマンドのような) 単一行操作で同じ接続マネージャを使用している場合は、OLE DB コマンド操作用として 2 つ目の接続マネージャを作成し、こちらでは小さいパケット サイズを扱うことを検討します。 お気付きのように、ETL を Windows 2008 で実行しており、複数の NIC が備わったマルチコア コンピュータを使用している場合は、ネットワーク カードを個々のコアに関連付けることによってネットワーク パフォーマンスを少し向上させることができます。詳細については、MSDN サイトにあるブログの投稿「Windows での過剰なネットワーク トラフィック発生時のスケーラビリティ向上」を参照してください。 抽出のチューニングで最も簡単に行えることの 1 つは、使用するクエリのチューニングです。単に抽出元のテーブルを選択する方が簡単なので、その方法ですべての列を取得してしまいがちですが、実際に必要な列のみを選択した方が、はるかに良い結果が得られます。この場合、ネットワーク トラフィックとメモリの使用量が減るだけでなく、データベース サーバーがクエリの要求を満たすために必要とする I/O も大幅に減る可能性があります。 ご覧いただいているように、SQL Server ではヒントを使用して、選択の実行中に共有ロックが発行されないことを示すこともできます。この場合、コミットされていないデータやダーティ データをクエリが読み取る可能性もあります。この操作を行うのは、どうしてもパフォーマンスを最優先させる必要があり、かつ、ETL ジョブでダーティ データを読み取ってもまったく問題がないことがわかっている場合に限定してください。 参照は、抽出とも変換とも考えられますが、どちらにせよ、前のスライドで示したのと同じ考え方を一部当てはめる必要があります。ここでは、ネットワークの最適化のためだけでなくインメモリ キャッシュの最適化のためにも、必要な列のみを選択することがいっそう重要です。 SQL Server 2008 を使用している場合、パフォーマンスの向上に最適な機能の 1 つとして、新しい共有参照キャッシュの追加が挙げられます。参照キャッシュを共有すると、参照データを一度フェッチした後、パッケージ内の複数の参照操作で再利用することも、キャッシュをファイルに保存することによって複数のパッケージで再利用することもできます。同じテーブルを参照する参照コンポーネントが複数ある場合は、パッケージの速度を大幅に高める手段として、この新しいオプションを検討します。このオプションは非常に簡単に利用できる可能性があります。パッケージ内でキャッシュ接続マネージャを作成し、新しいキャッシュ変換を使用してキャッシュにデータを設定します。次に、このキャッシュ接続を参照して参照データを取得するように、参照を変更します。 |
06:29 |
続いて、ETL の 2 番目のフェーズである変換について見ていきましょう。変換では、既にデータ フローに読み込まれたデータを処理して、後で読み込めるように正しい形状に変えます。SSIS では、すべての変換が、デザイン上にドラッグ可能なオブジェクトとして表示されますが、すべての変換が同じ性質になるわけではありません。それでは、SSIS にある 3 種類の変換について確認してみましょう。
これで基本的な内容の説明が終わりました。続いて、その他の具体的なヒントを少し見ていきましょう。
|
11:59 |
続いて、読み込みフェーズについて見ていきましょう。 SQL Server にデータを読み込む場合は、パフォーマンスが高い 2 つのオプションを利用できます。
これらのすべてについて、コミットのサイズを 0 にすると、読み込みが最も速くなります。 大規模な読み込みを行う場合、変換先システムのインデックスを削除することも広く行われていますが、いつ削除するかに関して、いくつかのガイドラインに従う必要があります。一般的なガイドラインでは、読み込みによる予想増加率と、テーブルに設定されているインデックスの種類に基づいて、インデックスを削除するかどうかを決定します。
他の処理が実行されているテーブルにデータを読み込む場合は、その方法を工夫する必要があります。一括読み込みを行うと、多くの場合、すべてではなくても、ほとんどの変換先テーブルに制限が適用されます。これに問題がないことを確認するか、パーティション分割を使用するようにしてください。運用中のデータベースにデータを読み込む必要がある場合は、現在運用中のデータをアクティブな状態で維持できるように、読み込み先となるパーティションを設定できます。読み込みが遅い場合は、そのテーブルまたはパーティションで他にどのような処理が行われているかを調べ、競合している処理がないことを確かめます。 一括読み込みとパーティションのパフォーマンス向上に関する役立つガイドについては、MSDN にある SQLCAT の記事「データ読み込みパフォーマンス ガイド」を参照してください。 また、再読み込みを行う場合は、削除がトランザクション単位にならないように、DELETE ではなく TRUNCATE を使用してデータを消去します。 ネットワーク接続を使用する変換先でも、既に説明したのと同じネットワークの問題が発生します。読み込み時に最適のパフォーマンスが得られるように、パケット サイズを大きくして、ネットワークで "特大のフレーム" を有効にすることを検討します。 |
15:02 |
以上で、このパフォーマンス シリーズの第 2 回は終了です。今回、トマスには、このビデオ シリーズの基礎となる多くの有益な情報を提供していただきました。また、カルラとダグラスからは、このシリーズの作成に関するさまざまなアドバイスを頂きました。ありがとうございました。これらのトピックの詳細については、「SQL Server Integration Services に関するベスト プラクティス トップ 10」を参照してください。 ご覧くださいましてありがとうございました。このビデオ シリーズ「SSIS : パフォーマンス向上のためのデザインとチューニング」には、他に 3 つのビデオがありますので、そちらもご覧ください。このビデオが皆様のお役に立ちましたら幸いです。また、皆様からのご感想をお待ちしております。その際には、ビデオ ホーム ページの右上にある、評価とフィードバックのリンクをご利用ください。 |