SQL Server 2005 Integration Services: 第 1 部 - プロジェクト REAL からの教訓

Richard Waymire
Len Wyatt
John H. Miller
Donald Farmer
Microsoft Corporation

Jyoti Jacob
Scalability Experts, Inc.

March 2005
日本語版最終更新日 2005 年 11 月 14 日

概要 : プロジェクト REAL では、実在する企業の大量の実データとシナリオに基づき、Microsoft SQL Server 2005 のプレリリース版を使用して、ビジネス インテリジェンス システムを実装しています。また、その過程で、ベスト プラクティスを策定したり、潜在的な問題を特定しています。このホワイト ペーパーでは、プロジェクト REAL の第 1 フェーズで、データの抽出、変換、および読み込み (ETL) を行った際に学んだ教訓の一部を紹介します。

On This Page

はじめに : プロジェクト REAL について
第 1 フェーズの実装
SQL Server 2000 DTS からのアップグレード
移行ウィザードの使用
移行ウィザードの使用に関する考慮事項
Beta 2 および Community Preview Release での移行に関する考慮事項
手動アップグレードの実行
SQL Server 2005 Integration Services での SQL Server 2000 DTS パッケージの実行
SQL Server 2005 Integration Services パッケージの開発から学んだ教訓
ベスト プラクティスの実装
プロパティ式
障害発生後の問題の回避
優先順位制約エディタ
パッケージ実行
Analysis Services によるパーティションの複製
カスタム ソース コンポーネントと変換コンポーネントによる SSIS データ フロー タスクの拡張
詳細エディタ
パフォーマンスに関するヒント
発生した問題
製品に対する機能強化の要請
まとめ

はじめに : プロジェクト REAL について

プロジェクト REAL は、実際のユーザー シナリオに基づいた実装例を構築することによって、Microsoft SQL Server 2005 を使用してビジネス インテリジェンス アプリケーションを作成する場合のベスト プラクティスを調査するプロジェクトです。ユーザー データを社内に用意して、ユーザーが展開時に直面する問題と同じ問題に対処しています。ユーザーが直面する問題には、次のようなものがあります。

• スキーマのデザイン

• データの抽出、変換、および読み込み (ETL) のプロセスの実装

• 実稼動に適したシステムのサイズ調整

• 日常的なシステムの管理とメンテナンス

実際の展開シナリオを使用することにより、ツールの使用方法について理解を深めています。このプロジェクトは、大企業で実際に SQL Server を展開するときに直面することが予想されるあらゆる問題に対処することを目的としています。このホワイト ペーパーでは、プロジェクト REAL の第 1 フェーズで ETL の実装から学んだ教訓の一部を紹介します。

プロジェクト REAL では、マイクロソフトのビジネス インテリジェンス ユーザー 2 社のデータを使用しています。このプロジェクトの第 1 フェーズは、Microsoft SQL Server 2000 のデータ ウェアハウスで売上データと在庫データを管理している家電量販店のシミュレーションです。このユーザーは、データ フローの管理に、SQL Server 2000 データ変換サービス (DTS) を使用しており (データは、リレーショナル データベースに渡され、その後、SQL Server 2000 Analysis Services のキューブに渡されレポート作成とインタラクティブなクエリが行われます)、リレーショナル ストアには約 200 GB のデータを格納しています。このデータは、すべて Analysis Services のキューブで処理されます。第 1 フェーズの実装では、既存の SQL Server 2000 ユーザーが SQL Server 2005 への移行を行ったときに直面する可能性のある問題に重点を置いています。ここでは、主に既存の機能の移行を取り上げますが、必要に応じて、いくつかの新しい機能の使用方法も紹介します。ETL の実装では、既存の SQL Server 2000 DTS パッケージを基に SQL Server 2005 Integration Services (SSIS) を使用してパッケージを作成するのに、多くの作業が必要になりました。

    注意   SQL Server Integration Services (SSIS) は、以前 DTS と呼ばれていたコンポーネントに付けられた新しい名称です。このコンポーネントは Beta 2 以降で名前が変更されました。そのため、このホワイト ペーパーに含まれる SSIS のスクリーン ショットでは、古い名称を使用しているものが多数あります。

SSIS は、まったく新しいアーキテクチャに基づいているので、SQL Server 2000 の多数の概念や技法は継承されていません。このホワイト ペーパーでは、これらの違いについても重点を置いて説明します。

プロジェクト REAL の第 2 フェーズは、別のユーザーが所持する大量のデータ セットに基づいています。第 2 フェーズは、SQL Server 2005 ソリューションの新しい実装なので、第 1 フェーズよりも SQL Server 2005 の新しい機能を使用しています。今後もプロジェクト REAL についてのホワイト ペーパーは順次公開される予定です。

プロジェクト REAL は、マイクロソフト、Unisys、EMC、Scalability Experts、Panorama、Proclarity、および Intellinet による共同の取り組みです。このホワイト ペーパーに記載されている作業は、マイクロソフトと Scalability Experts が行ったものです。

第 1 フェーズの実装

第 1 フェーズのユーザーは、主に次の 2 つのソースの情報をデータ ウェアハウスに格納しています。

• TLOG ファイル。売り場の店舗販売時点管理 (POS) レジの出力 (SQL Server のトランザクション ログ ファイルと混同しないように注意してください)。

• 業務管理に使用する JDA システムから抽出したフラット ファイル (JDA システムは、パッケージ化された市販のソフトウェア アプリケーションです)。

図 1 に、SQL Server 2000 DTS によって管理されている全体的なデータ フローを示します。

主要な ETL プロセス

このユーザーのデータ ウェアハウスを読み込むために実行する主要な ETL プロセスは、次のとおりです。

1. 店舗販売時点管理 (POS) レジの TLOG ファイルは、圧縮率の高い特殊な形式であるため、このファイルを読み込むには、圧縮を解除する必要があります。このユーザーのアプリケーションでは、これらの POS トランザクションを、定義済みの仕様に基づいて 10 進形式で圧縮し、各ファイルを店舗番号に基づいて個別のディレクトリに格納します。

2. アプリケーションでは、各ファイルの名前に連続した数字を割り当て、店舗番号に基づいて、適切なディレクトリにファイル名を格納します。この名前付け規則は、複数の日をまたぐファイルをサポートしたり、1 日に複数のファイルが記述される状況をサポートするために必要です。

3. Perl スクリプトを使用して TLOG バイナリ ファイルを複数のテキスト ファイルに解析してから、データをデータベースに読み込みます。このスクリプトは、定義済みテンプレートを使用してデータを展開し、その後、.ini ファイルで定義された一連のルールに従ってデータの圧縮を解除します。

4. このスクリプトの出力は、フラット ファイルに格納されます。このフラット ファイルは、DTS パッケージにより読み取られ、データがデータベースに格納されます。このように、データを処理するには、データを解析して、フラット ファイルへの出力を読み込むという 2 つの追加の手順が必要になります。

Scalability Experts では、ETL プロセスを SSIS に移行するために、SSIS パイプラインで実行する TLOG パーサーを作成しました。このパーサーにより、高コストな追加の手順が必要なくなり、TLOG ファイルの処理に必要な記憶域の要件が緩和されます。圧縮データを含む各 TLOG ファイルは、"カスタム ソース コンポーネント" を使用して SSIS パイプラインに直接読み込み、"カスタム変換コンポーネント" を使用して解析することができます。

   注意   TLOG パーサーの実装に必要なカスタム変換を記述する過程で学んだ教訓については、別のホワイト ペーパーで紹介します。

システムを十分に検証するため、ユーザーからは、データ ウェアハウスの初期状態だけでなく、売上システムと在庫システムの両方について 3 か月分の日単位の増分更新データも提供されました。その結果、このプロジェクトでは、短時間で、リレーショナル データベースと OLAP データベースの両方について自動化されたパーティション管理など、完全な処理サイクルをシミュレーションすることができました。

このホワイト ペーパーで説明する ETL についての取り組み以外にも、プロジェクト REAL の第 1 フェーズでは、他のさまざまな作業を行いました。たとえば、次のようなものがあります。

• スキーマを完全に維持した状態でのリレーショナル データの SQL Server 2000 から SQL Server 2005 への移行。

• ユーザー データのマスクによる機密情報の保護。

• Analysis Services 2000 データベースの SQL Server Analysis Services (SSAS) への移行。

• ユーザーが設定したフロントエンド ツール (Excel と Proclarity) によるクライアント接続の確認。

• SQL Server 2005 Reporting Services (SSRS) による新しいキューブのサンプル レポートの作成。

• SSAS への新しい在庫用キューブの完全実装。以前、このユーザーは、データの容量が大きいことが原因で、準加法メジャーを使用するのに苦労しており、この機能を使うことを断念していました。Analysis Services 2005 の新しい機能により、準加法メジャーは、大容量のデータに対しても実用性を発揮するようになりました。

このホワイト ペーパーの残りの部分では、ユーザーの ETL プロセスを SQL Server 2005 Integration Services に移行する過程で学んだ教訓とさまざまなベスト プラクティスを紹介します。

SQL Server 2000 DTS からのアップグレード

SQL Server 2000 DTS ユーザーが最初に直面する問題の 1 つは、SSIS へのアップグレード方法でしょう。SSIS へのアップグレードは、移行ウィザードを使用したり、手動で移行を実行したり、またはパッケージを独立させ、パッケージ実行タスクを使用してパッケージを実行するなど複数の方法があります。ここでは、この各方法の概要を説明します。

プロジェクト REAL では、既存の DTS パッケージを移行するよりも、SSIS で ETL プロセスの新しい実装を作成した方が、ユーザー満足度が高くなることが判明しました。プロジェクト REAL では、DTS 移行ウィザードなど、いくつかのアップグレード ツールを使用して既存の DTS パッケージを移行することに成功しましたが、SQL Server 2005 の強化された機能を利用するために、SSIS でさまざまなパッケージを書き直すことに多大な労力を要しました。

移行ウィザードの使用

移行ウィザードは、DTS から SSIS にパッケージを移行するための最もわかりやすい方法です。ここでは、移行ウィザードの使用方法と、このウィザードを使用すべきかどうかを判断する際の重要な検討事項について説明します。

移行ウィザードを使用するには

1. SQL Server Integration Services の Business Intelligence Development Studio で新しいプロジェクト (Integration Services プロジェクト) を作成すると、Package.dtsx という新しい既定のパッケージが自動的に作成されます。ただし、この新しいパッケージは、右クリックし、[削除] をクリックして、削除することができます。

2. ソリューション エクスプローラで [SSIS パッケージ] フォルダを右クリックし、[DTS 2000 パッケージを移行] をクリックします。この操作により、パッケージ移行ウィザードが起動します。

3. [次へ] をクリックし、変換元のパッケージがある場所を選択します (図 2 参照)。

   注意   移行ウィザードは手動で起動することもできます。既定では、移行ウィザードは C:\Program Files\Microsoft Sql Server\90\Dts\binn\Dtsmigrationwizard.exe にあります。

   

   図 2

4. 移行したパッケージを格納する場所を指定します (図 3 参照)。

   

   図 3

5. 移行する DTS パッケージ (およびバージョン) を選択します (図 4 参照)。パッケージには複数のバージョンを含めることができるので、既定の設定 (現在のバージョン) をそのまま使用するか、または以前のバージョンのパッケージをアップグレードするように選択することができます。

   

   図 4

6. 移行中にウィザードによって加えられた変更内容の詳細を記録するログ ファイルを指定します。移行の完了時に、このログ ファイルで移行中に警告やエラーが発生していないことを確認します。

   

   図 5

7. [次へ] をクリックし、概要を確認して、[完了] をクリックします。パッケージの移行が完了したことを示す図 6 のようなダイアログ ボックスが表示されます。

   

   図 6

8. ウィザードを終了し、ソリューション エクスプローラで、[SSIS パッケージ] フォルダを展開します。移行したパッケージをダブルクリックし、エディタで開きます。

   図 7 は移行後のパッケージで、図 8 は、SQL Server 2000 の DTS デザイナで表示した移行前のパッケージです。

      

   図 7

      

   図 8

移行ウィザードの使用に関する考慮事項

前の説明内容からわかるように、移行ウィザードを使用することは難しい操作ではありません。ただし、このウィザードを使用する際には、いくつかの事項について考慮する必要があります。

SQL Server 2005 Integration Services は、まったく新しい製品です。SSIS では、SQL Server 2000 DTS パッケージを継続して実行できますが、デザイン画面、オブジェクト モデル、および内部デザインが新しくなっています (SSIS で SQL Server 2000 DTS パッケージを継続して実行する方法については、このホワイト ペーパーの後半で詳しく説明します)。SQL Server 2000 DTS でデザインできるすべてのパッケージについて、必ずしも同等または端的なアップグレード方法があるとは限りません。移行ウィザードは、最善の移行方法を試行するツールです。

ここに記載する一部のカテゴリに含まれるタスクがパッケージに含まれている場合、移行ウィザードでエラーや障害が発生する可能性が高くなります。この動作は予想されるものであり、ウィザードを使用して移行できないパッケージは書き直す必要があります。

SQL Server 2000 DTS タスクは、次の 3 つのカテゴリに分類できます。移行処理は、タスクがどのカテゴリに属するかによって異なります。

カテゴリ 1: 単純なタスク

SQL Server 2005 Integration Services にそのまま移行できます。このようなタスクには、次のようなものがあります。

• SQL 実行タスク

• 一括挿入タスク

• ファイル転送プロトコル タスク

• プロセス実行タスク

• メール送信タスク

• オブジェクト コピー タスク

• パッケージ実行タスク

パッケージに、これらのタスクしか含まれていない場合、移行処理は簡単なものになります。

カテゴリ 2: 複雑なタスク

SQL Server 2005 Integration Services に移行できますが、移行後に機能しなくなる可能性があります。この現象は、ActiveX タスクや動的プロパティ タスクによく見られます。通常、これらのタスクは、SQL Server 2000 DTS オブジェクト モデルと相互作用しますが、SSIS オブジェクト モデルには SQL Server 2000 DTS との下位互換性がありません。このようなタスクには、次のようなものがあります。

• ActiveX スクリプト タスク

• 動的プロパティ タスク

• Analysis Services DTS 処理タスク

これらのタスクを含むパッケージを移行するには、最低でも、これらのタスクのコンポーネントを新しく開発する必要があり、場合によっては、パッケージのデザインの大幅な見直しが必要になることもあります。

カテゴリ 3: カプセル化されたタスク

SQL Server 2005 Integration Services に移行できません。移行ウィザードが完了すると、これらのタスクを含む新しい DTS 2000 パッケージが作成されます。これらの SQL Server 2000 DTS タスクを実行するには、DTS 2000 パッケージ実行タスクを使用して、新しく作成されたパッケージを呼び出す必要があります。このようなタスクには、次のようなものがあります。

• カスタム タスク

• データ ポンプ タスク

• データ ドリブン クエリ タスク

• データ変換タスク

• 並列データ ポンプ タスク

• データベース コピー ウィザード タスク

このカテゴリのタスクを移行する場合は SSIS でコンポーネントを書き直すか、または DTS 2000 パッケージ実行タスクを使用してタスクを呼び出す必要があります。

SQL Server 2005 を新規にインストールしたサーバーで SQL Server 2000 DTS パッケージを実行する計画を立てている場合は、セットアップで [詳細設定] オプションを選択して、DTS 2000 ランタイム エンジンをインストールする必要があります。SQL Server 2000 の管理ツール (具体的には Enterprise Manager) がサーバーにインストールされていない場合、セットアップでは、この機能は "オプション" のコンポーネントと見なされます。この機能をインストールするには、図 9 に示すようにセットアップのオプションを変更する必要があります。

 

Beta 2 および Community Preview Release での移行に関する考慮事項

Beta 2 と Community Preview Release (IDW9) では、移行ウィザードにいくつかの問題があります。

• Analysis Services 処理タスクまたはデータ マイニング予測タスクのいずれかを含むパッケージがアップグレードされません。

  この問題は、Beta 3 で修正される予定です。

• 移行中に ActiveX スクリプト タスクのコードが検証されません。

  SSISではループを使用できるとされていますが、オブジェクトを反復処理するコードをループに変換できません。

• トランザクションが、接続からコンテナに移動されます。

  マッピングが維持されないので、SSIS でコーディングを行う必要があります。

• カスタム変換コンポーネントを SSIS に移行する必要があります。

  カスタム変換コンポーネントで DTS オブジェクト モデルを使用している場合、移行ウィザードを使用して移行できますが、SSIS では正常に機能しません。

手動アップグレードの実行

DTS 移行ウィザードを使用する代わりに、手動でパッケージをアップグレードすることができます。実際、この方法は、SQL Server 2000 DTS を SQL Server 2005 Integration Services に移行する好ましい方法です。移行ウィザードを使用して、一部の既存のパッケージをアップグレードすることは可能ですが、新しいサービスや機能を利用するようにパッケージを書き直さなければ、SSIS のメリットを完全に享受することができません。

プロジェクト REAL では、手動アップグレードを行いました。一部のビジネス ロジックでは、引き続きストアド プロシージャを使用することにしたので表面的にパッケージは非常によく似ているところもありますが、ストアド プロシージャ呼び出しから大量のロジックを抜き出して、SSIS パッケージに移動しました。

たとえば、第 1 フェーズのユーザーが売上データの読み込みに使用していたプロセスが、これに該当します。当初、データは、動的な一括挿入タスクを使用して、1 つの大きなテキスト文字列として読み込まれ、その後、select-insert ステートメントを使用して、有効な一連の型指定されたデータに変換されていました。また、レコードは、変換時に、読み込まれたデータからフィルタで除外されていました。場合によっては、レコードの約半数がフィルタで除外されることもありました。SSIS では、フラット ファイル接続を使用してデータを開き、その後、動的な一括挿入タスクの後に行われていた処理と同じロジックを使用してデータをフィルタ処理しました。その後、データは、適切に型指定され、フィルタ選択された状態で指定のテーブルに直接読み込まれました。この処理は、SSIS の強化機能により実現されました。

SQL Server 2005 Integration Services での SQL Server 2000 DTS パッケージの実行

パッケージを SQL Server 2000 DTS 形式で維持したまま、SQL Server 2005 にアップグレードすることは可能です。このシナリオでも、SQL Server 2000 DTS パッケージは、引き続き機能します。これらのパッケージは、DTS 2000 パッケージ実行タスクを呼び出す、SSIS の管理パッケージから実行されます。

図 10 に、DTS 2000 パッケージとパッケージ タスクの関係例を示します。これらのパッケージは、タスク エディタで [パッケージの編集] ボタンをクリックして SQL Server 2005 SSIS エディタで編集することもできます (これは Beta 2 時点での情報です)。

 

このボタンをクリックすると、パッケージが SQL Server 2000 DTS デザイナで読み込まれます (図 11 参照)。この操作は、以前に、SQL Server 2000 Enterprise Manager がインストールされていたサーバーでのみ行うことができます。SQL Server 2005 のセットアップ プログラムには、DTS 2000 デザイナをインストールするオプションは用意されていません。

 

この方法は、多くのユーザーにとって、短期的な移行計画としては最適な方法です。この方法を使用すると、SQL Server のインストールを SQL Server 2005 にアップグレードし、既存の DTS 2000 パッケージをそのまま実行することができます。時間をかけて、(移行ウィザードを使用するか、またはパッケージを書き直して) 各パッケージを移行し、SQL Server 2005 の強化された機能を利用するようにすることができます。

SQL Server 2005 Integration Services パッケージの開発から学んだ教訓

プロジェクト REAL の第 1 フェーズに取り組む過程で、いくつかの有益なベスト プラクティスと製品についてのいくつかの問題点を発見しました。ここでは、このようなベスト プラクティスと問題点について説明します。

ベスト プラクティスの実装

ここでは、プロジェクト REAL の第 1 フェーズに取り組む過程で発見したベスト プラクティスを紹介します。

パッケージへのログ記録機能の追加

SSIS パッケージでは、ログ記録を使用することを推奨します。ここでは、ログ記録の機能を追加する方法を紹介します。SQL Server 2005 では、ログ記録の機能は簡単に追加することができます。

パッケージにログ記録の機能を追加するには  

1. 制御フローのデザイン画面の任意の場所を右クリックし、[ログ記録] をクリックします (図 12 参照)。この操作により、[SSIS ログの構成] ダイアログ ボックスが表示されます。

    

   図 12

   注意   Community Preview Release (IDW9) では、画面左側に表示されるツリー コントロールで、パッケージの隣のチェック ボックスをオンにする必要があります。次に、[プロバイダ] ボックスの隣にある [追加] ボタンをクリックして、ログ ファイルを追加します。

   ログ   ファイルの種類  

   ログ記録は、テキスト ファイルだけでなく、次の場所にも出力することができます。

   • SQL Server プロファイラ

   • SQL Server テーブル

   • Windows 2000 Server イベント ログ

   • XML ファイル

   ログ記録の出力先には、どこを選択したらよいでしょうか。

   • SQL Server プロファイラのログ ファイルは、SQL Server プロファイラの GUI を使用して開くことができます。パフォーマンス モニタのカウンタを読み込む機能と組み合わせると、実行時間が予想外に長い場合など、特定の状況で強力な解析ツールとしての役割を果たします。

   • SQL Server テーブルでは、リレーショナル言語の機能を最大限に利用してログを調査し、SQL ステートメントを使用して、ログ エントリに基づいた操作を行うことができます。

   • Microsoft Operations Manager などの運用管理ソフトウェアを使用してサーバーを監視している場合、Windows イベント ログに記録することが最良の選択になるでしょう。パッケージのログ エントリに基づいて警告を発生させたり、操作を行うことができます。この選択肢は、アプリケーションを実稼働環境に移行した後に使用を検討することをお勧めします。

   • XML ファイル形式は、ログを視覚的に参照する場合に便利です。また、XML ファイル形式を使用すると、XSLT 変換を使用して、ログを Web ページとして参照することができます。また、第三者と結果を共有する必要がある場合や SQL Server などのさまざまなデータ ソースからログ ファイルを統合する場合にも XML は適切な中間形式として機能します。

   • 特に、パッケージの基本的なテスト フェーズでは、テキスト ファイルは、簡単に参照、構成、および定義することができるので有益です。

2. [追加] ボタンをクリックしたら、DTS ログ プロバイダを確認します (図 13 参照)。[構成] 列をクリックすると、一覧が表示されます。図 13 に示すように、一覧から [<新しい接続>] を選択します。

    

   図 13

   この操作により、[ファイル接続マネージャ エディタ] ダイアログ ボックスが表示されます (図 14 参照)。

3. この例では、[使用法の種類] ボックスの一覧の [ファイルの作成] をクリックし、個人用のログとして使用するためのファイル名を指定しました (図 14 参照)。

   このダイアログ ボックスは、SQL Server プロファイラと共通の作業インフラストラクチャを基に構築されているので、SQL Server プロファイラと同じグラフィカル インターフェイスが使用されています。そのため、SQL Server ではログ記録の機能はわかりやすく、一貫性があります。

    

   図 14

4. [OK] をクリックします。SSIS パッケージにログ記録の機能を追加すると、パッケージの実行後にログを確認できるようになります。

5. ログに記録する内容の詳細を構成するには、[OK] をクリックし、[詳細設定] タブをクリックします (図 15 参照)。このタブでは、ログに記録するイベントの種類を選択できます。

    

   図 15

   注意    [詳細設定] ボタンをクリックすると、ログに記録するイベントを細かく制御することができます (図 16 参照)。

       

   図 16

SQL 実行タスクの使用

SQL 実行タスクを使用すると、クエリのパラメータ値を設定して、単一行または複数行を返すか、あるいは XML に出力することができます。

SQL Server Integration Services ではクエリは自動的には最適化されないので、このタスクを実行する際のパフォーマンスを確保するには、従来からあるクエリの最適化ツールを使用してクエリを最適化する必要があります。これは、SQL Server からデータを抽出する場合にも当てはまります。パフォーマンスを最適化するには、クエリでは本当に必要な列のみを返すようにします。Select * from <sometable> のようなクエリでは、不要なデータも返されるので、このようなクエリは使用しないことをお勧めします。

SQL 実行タスクでは、パラメータ化したクエリを指定することができます。ストアド プロシージャやクエリの入力変数は、実行時に値 ? にマップされます。

Select EmployeeName from dbo.EmpTable where EmpID = ? 

パラメータは、順序に依存します。複数のパラメータを持つストアド プロシージャの場合、SSIS エンジンでは、入力変数が割り当てられた順に従って、値をマップします。そのため、最初の入力変数は最初の ? にマップされます。

クエリから完全な結果セット (複数行の結果セット) が返される場合は、[結果名] に「0」を設定して、値を変数に代入します (図 17 参照)。

単一行の結果セットが返される場合は、[結果名] の値には返される列の名前を設定します。

ストアド プロシージャがかかわるエラー処理については、[パラメータ マッピング] で [ReturnValue] の方向を変数にマップし、ストアド プロシージャの実行後にリターン コードを確認できるようにします。

"右" 側の列数が固定されていないファイルの処理

プロジェクト REAL で使用しているテキスト ファイルなど、一部のファイルでは、ファイルの末尾にある列数が固定されていません。省略可能な値は、データ ファイル行の末尾に記載されていることもありますが、記載されていないこともあります。SSIS では、フラット ファイル接続マネージャを使用し、幅合わせしない形式を使用して、この種類のファイルを処理することができます。ただし、このファイル形式を使用する場合には制限事項があり、可変にできるのは最後の列のみになります。つまり、ファイルでは、省略可能な列を複数定義することはできません。

ただし、この問題には簡単な回避策があります。最後の列を、すべての省略可能な列の最大長で定義し、派生列変換エディタを使用して、パッケージで使用する省略可能な列の列定義を作成することができます。図 18 に、フラット ファイル接続マネージャのファイルへの接続の定義を示し、図 19 には、最後の列 variablecol を 50 バイトで定義した状態を示します。

[接続マネージャ] の一覧に作成したフラット ファイル接続マネージャの接続を参照するフラット ファイル ソースを追加します。次に、派生列変換を追加して、フラット ファイル ソースを接続する必要があります。派生列変換をダブルクリックし、図 20 に示すように、省略可能な列の定義を作成します。

次に、SQL Server 変換先など、変換先を追加します。これで、列がファイルのすべての行に存在するかどうかに関係なく、すべての列を参照できるようになります。最終的なデータ フローは図 21 のようになります。

派生列変換を使用したデータの変換

派生列変換を使用すると、ユーザーは、入力に式を適用して新しい列を作成することができます。この式は、入力と変数の両方に適用することができます。SSIS には、ユーザーが入力を変換するための、独自に定義した式文法があります。この変換は、次のタスクで非常に役立ちます。

• ソースに、可変数および可変長の列が含まれている場合。既に説明したように、ユーザーは、フラット ファイル ソースの [幅合わせしない] オプションを使用して、ソース データを 1 つの列として読み取り、派生列変換を適用して、1 つの大きな列から複数の列を抽出することができます。

• 下流工程での処理をサポートするために、1 つ以上の変換元列に基づいて新しい列を派生させる必要がある場合。

• ETL プロセスでは、外部データをデータベースに挿入する前に最適化する必要があることは珍しくありません。たとえば、次のような場合があります。

  文字列型の列 : 先頭のNULL 文字を削除し、変換元列のサブストリングのみを抽出する必要があります。

  または

  整数型の列 : データは絶対値かつ丸められた値である必要があります。

これは、派生列変換のさまざまな文字列や数学関数を使用して、簡単に行うことができます。つまり、派生列では、従来データの最適化や変換を行うために使用されていた複雑なストアド プロシージャのロジックを簡単に置き換える方法が提供されます。

派生列

図 22 に示すように、単一の変換で定義した複数の関数を使用して、多数の複雑な式を簡単に適用することができます。たとえば、2 つ目の式で使用している Case/Switch ステートメントでは、結果を必要なデータ型にキャストするのに Substring 関数の結果に依存しています。

注意   このタスクおよび SSIS 内で実行する他のタスクで使用している式の構文は、Transact-SQL と Visual Basic のどちらにも基づいていないカスタム実装です。式の言語の詳細については、SQL Server Books Online を参照してください。

派生列変換を使用するには  

1. 派生列変換をデータ フロー ウィンドウにドラッグし、ダブルクリックして開きます。

2. 必要な派生列を追加し、派生列に値を代入する式を定義します。式は、入力または変数に対して記述できます。

3. [派生列] ボックスの一覧で、[<新しい列として追加>] を選択するか、または既存の列を選択して置き換えます。

4. 新しい列を定義するには、適切なデータ型、長さ、有効桁数、小数点以下桁数、およびコード ページを指定します。

派生列変換では、エラーまたはデータの切り捨てが発生した場合の、行レベルのコンポーネントの処理方法を構成できます。

図 23 に示すように、ユーザーは、列ごとに、エラーや列データの切り捨てが発生した場合の操作を定義できます。データの切り捨てが発生した場合、ArticleDesc 列についてはエラーを無視するように設定し、PartNo 列については行をエラー ファイルにリダイレクトするように設定しました。その他の列については、エラーが発生するか、またはデータが切り捨てられた場合、コンポーネントがエラーになるように設定しました。出力 Error 列が生成され、この列はエラー処理コンポーネントにマップして、下流工程での処理を行うことができます。

シーケンス コンテナの使用

図 24 に示すように、SQL Server 2000 DTS パッケージでは、複数のタスクが並行して実行されることがよくあります。

SQL Server 2005 Integration Services では、これらのタスクを "シーケンス コンテナ" にラップして、デザイナで多数のワークフローの接続を操作しなくて済むようにできます。また、シーケンス コンテナに依存関係のあるタスクを含めたり、ワークフローの下流工程にあるタスクがシーケンス コンテナの処理結果に応じて変化するようにもできます (シーケンス コンテナの使用例については、図 25 を参照してください)。シーケンス コンテナは、入力、出力、およびエラー処理に関して 1 つのタスクとして操作されます。

SSIS のループ処理

DTS 2000 でタスクのループ処理を行うには、開発者はランタイム エンジンを欺いて、タスクの実行が完了していても、タスクが待機中であるかのように思わせる "ハッカー" まがいの手段を講じる必要がありました。幸いにも、SSIS では、ループ処理を行うために、このような "ハッカー" まがいの行為を行う必要はありません。ForEach ループや For ループなど、いくつかのループ処理タスクが導入されました。

For ループ

For ループ コンテナでは、for 反復ステートメントを使用してパッケージで反復ワークフローを定義します。For ループ コンテナでは、ある式を評価し、式が False になるまで、ワークフローを繰り返します。次の図に示すように、タスクを反復処理するときには 1 つのループで複数のタスクを実行することができます。

ForEach ループ

ForEach ループ コンテナでは、foreach 反復ステートメントを使用してパッケージで反復ワークフローを定義します。SSIS では、次の種類の列挙子が用意されています。

• テーブルの行を列挙する Foreach ADO 列挙子

• フォルダ内にあるファイルを列挙する Foreach File 列挙子

• 指定した変数に含まれる列挙可能なオブジェクトを列挙する Foreach From Variable 列挙子

• SQL Server Management Object (SMO) を列挙する Foreach SMO 列挙子

• XML パス言語 (XPath) 式の結果セットを列挙する Foreach Nodelist 列挙子

Beta 3 までには、Foreach Directory 列挙子が追加される予定です。この列挙子は、当初は計画されていないものでした。プロジェクト REAL の要件の 1 つには、ストア ディレクトリを列挙し、TLOG ファイルにアクセスして処理し、データをデータベースに挿入することがありました。この要件により、当初の計画に含まれていなかった Foreach Directory 列挙子を使用する現実的なシナリオが見つかりました。幸いなことに、このシナリオは一般的であると見なされ、Beta 3 までに、この列挙子を SSIS に含めることになりました。それまで、Foreach Directory 列挙子のカスタム タスクは、SSIS サンプルで提供します。

SSIS は、必要なタスクが利用できない場合に、比較的簡単にカスタム タスクを作成して、SSIS パッケージの構築にカスタム タスクを使用できるようにすることを念頭に置いてデザインされています。この拡張性により、マイクロソフトが提供するベース セットを拡張するカスタム タスクをサードパーティが作成することは十分に考えられます。

パッケージ構成ウィザードの使用によるサーバー間のパッケージの移行の簡略化

このプロジェクトで直面した別の問題には、環境間でのパッケージの移行があります。たとえば、開発環境からテスト環境、そして実稼動環境への移行です。サーバーへの接続文字列、ハードコーディングされたファイルの場所などは、パッケージの開発環境で使用した物理サーバーやネットワークに依存することがあります。パッケージを別のサーバーやネットワークに移動すると、これらの接続文字列が無効になることがあります。SSIS には、この問題を解決するのに役立つすばらしい新機能があります。ただし、この機能を使用する際には、少し注意が必要です。

まず、ソリューション エクスプローラで、実際のパッケージ (dtsx) ファイルに付随するすべてのファイルが、プロジェクトに含まれていることを確認します (追加のファイルは、プロジェクトの [その他] フォルダに追加できます)。この確認を終えたら、パッケージ構成ウィザードを使用して、パッケージの一部を入力ソース (XML ファイルなど) で構成できるようにします。その後、SSIS 配置ユーティリティを実行して、新しい構成でパッケージを新しいサーバーにインストールするための、実行可能なセットアップ ファイルを構築します。

パッケージ構成ウィザードにアクセスするには

1. パッケージを構築したら、コントロール フローのデザイン画面を右クリックし、[パッケージ構成] をクリックします。

2. [パッケージの構成を有効にする] チェック ボックスがオンになっていることを確認し、[追加] をクリックします。この操作を行うと、図 28 のような状態になります。

   
   図 28

3. [次へ] をクリックし、使用する構成の種類を選択します (ここでは、既定の XML ファイルを使用しています)。選択した構成の種類に適切な情報を指定します (ここでは、構成の詳細を含む XML ファイルへのパスを指定しています)。

   図 29 に示すようなダイアログ ボックスが表示されます。

   

   図 29

4. [次へ] をクリックすると、[エクスポートするプロパティの選択] ダイアログ ボックスが表示されます (図 30 参照)。

5. [エクスポートするプロパティの選択] ダイアログ ボックスで、必要に応じてプロパティを設定します。これが、このプロセスで最も厄介な部分です。あるサーバーから別のサーバーにパッケージを移動した場合に、何が変更されるかを把握している必要があります。ここでは、テスト システムと実稼動システムで異なる可能性が高い mylog.txt と SQL Server への接続を選択しました。使用できるオブジェクトの一覧を下方向にスクロールすると、インストール時に構成できるものの多さに驚くでしょう。ここで構成する必要性が高い項目は、ファイルとデータベースへの接続です (この構成でも、ファイルとデータベースへの接続を選択しました)。

   

   図 30

6. この例では、[次へ] をクリックし、[完了] をクリックして、パッケージ構成ウィザードを終了します。プロジェクトを保存します。

   ソリューション エクスプローラで、プロジェクトを右クリックし、[プロパティ] をクリックします。左側のツリー コントロールで、[配置ユーティリティ] ノードをクリックすると、図 31 に示すようなダイアログ ボックスが表示されます。

   

   図 31

7. このダイアログ ボックスでは、[CreateDeploymentUtility] プロパティの値を [True] に変更します。[AllowConfigurationChanges] プロパティの値も [True] に設定されていることを確認し、[OK] をクリックします。

8. [ビルド] メニューの [ソリューションのビルド] をクリックします。パッケージが問題なくビルドされることを確認します。

9. 図 32 に示すように、Windows エクスプローラで、パッケージがビルドされた場所に移動し、その下にある \bin\deployment ディレクトリに移動します (このプロジェクトの場合は、My Documents\Visual Studio\Projects\Data Transformation Project 1\Data Transformation Project 1 です)。パッケージおよび実行可能インストーラと共に構成ファイルが存在することを確認してください。

      

   図 32

10. このディレクトリのコンテンツを、パッケージの移動先サーバーにコピーします。

11. DTSInstall.exe をダブルクリックします。パッケージ インストール ウィザードが起動します。

12. [次へ] をクリックすると、図 33 に示すようなパッケージ インストール ウィザードが表示されます。

13. 

    図 33

14. 配置の種類を選択します (パッケージをファイル システムにコピーするか、または SQL Server を実行しているサーバーにコピーするかを選択します)。この例では、[ファイル システムに配置] を選択します。

15. [次へ] をクリックし、図 34 に示すように、配置先のパスを選択します。

    

    図 34

16. [次へ] をクリックします。このダイアログ ボックスでは、SQL Server インストールへの接続文字列などの構成オプションを変更できます。図 35 に示すように、この例では、SQL Server データ ソースの名前を rwaymiyukon0 から FRED に変更しました。

       

    図 35

17. [次へ] をクリックし、[完了] をクリックします。

    パッケージは、パッケージ インストール ウィザードで設定した構成の変更が適用された状態で配置されます。

プロパティ式

構成は、パッケージの実行時に、一度だけ読み込まれ適用されます。構成はパッケージの実行中に動的に適用されるのではなく、実行前に適用されることに注意してください。ただし、パッケージの実行中にプロパティを動的に変更したい場合があるでしょう。プロパティ式の導入により、ユーザーは、変数を使用して実行時にコンポーネントのプロパティを動的に設定することができるようになりました。

プロパティ式を使用すると、ユーザーは、実行時に最小限の作業で変数の値を設定し、これらの変数を使用してコンポーネントからコンポーネントに情報を渡すことができます。そのため、開発者ではなくても、変数を簡単に操作できます。各タスクには、プロパティ式機能が備わっており、ユーザーは、さまざまな式を使用してコンポーネントのプロパティを設定することができます。プロパティ式の UI は、派生列タスクの UI と似ています (図 36 参照)。

ここで使用している SSIS パッケージの Foreach File 列挙子については、実行時に動的にフォルダ名のプロパティを設定するようにしたかったのですが、[式] プロパティの一覧には、これらのプロパティがありませんでした。ただし、後で、列挙子の構成プロパティは、[コレクション] のプロパティ式エディタで構成できることがわかりました。

図 37 は、一括挿入タスクの DestinationTableName プロパティの設定例です。

SQL Server 2000 DTS の動的プロパティ タスクの愛好家は、SSIS ではプロパティ式の機能を使用することをお勧めします。

SSIS の変数には、変数が定義されているコンテナの範囲内にスコープが設定されています。SQL Server 2000 DTS では、すべての変数はグローバル変数でしたが、SSIS では異なります。プロパティ式でプロパティに変数を割り当てると、子コンテナで定義されている変数は使用できなくなります。プロパティ式の設定に使用できるのは、コンテナと同じレベルまたは上位レベルで定義されている変数のみです。これは、エラー処理についても同様です。別の重要な条件として、変数のデータ型についても考慮する必要があります。変数は、割り当て先のプロパティと同じデータ型にキャストする必要があります。

障害発生後の問題の回避

パッケージのテストを開始したときに手を焼いたのは、データをステージング データベースに正常に読み込んだ後に、パッケージで障害が発生した場合です。この問題の救世主はチェックポイント機能でした。チェックポイント機能を有効にすると、SSIS では、チェックポイント ファイルに障害発生時点までの情報が記録されるようになります。パッケージを再実行すると、ランタイム エンジンでは、チェックポイント ファイルに記録されている情報を使用して、障害発生時点からパッケージを再実行します。

障害発生時点からパッケージを再実行できるようにするには、次のプロパティを設定する必要があります。

• カスタム フローのタスク ウィンドウで SaveCheckpoint プロパティを True に設定します。

• CheckpointFileName プロパティにチェックポイント ファイルの場所を指定します。

• CheckpointUsage プロパティを、次の 2 つの値のどちらかに設定します。

  Always: 常にチェックポイントからパッケージを再実行します。

  IfExists: チェックポイントが存在する場合は、チェックポイントからパッケージを再実行します。

• パッケージを再開する時点となるタスクおよびコンテナを構成します。

  タスクまたはコンテナで FailPackageOnFailure プロパティを True に設定します。

ForEach ループ コンテナとトランザクション化されたコンテナは、分離できない 1 つの作業単位と見なされることに注意してください。ForEach ループの子コンテナは、チェックポイント ファイルに記録されません。そのため、パッケージが ForEach タスクで再実行されると、ForEach ループ タスクに含まれるすべての子コンテナは、障害発生時に正常に完了していたとしても、再実行されます。たとえば、SQL 実行タスクを使用してテーブルからファイル名を抽出し、Foreach File 列挙子タスクを使用してファイルをループ処理し、一括挿入タスクを実装して抽出したファイル データをテーブルに挿入するパッケージがあるとします。このパッケージが SQL 実行タスクで失敗した場合、このタスクが再実行するタスクとして設定されていると、パッケージを再実行したときには、このタスクから再開されます。ただし、Foreach File 列挙子を使用していくつかのファイルをループ処理し、一括処理タスクを使用してデータを読み込んだ後にタスクが失敗した場合、このパッケージを再実行すると、ForEach ループ コンテナと ForEach ループ タスクに含まれる一括挿入タスクが再実行されます。

優先順位制約エディタ

優先順位制約エディタでは、優先順位制約にさまざまな条件と制約を設定することによって、次のコンポーネントへのデータ フローを制御します。この機能は、ある条件が満たされる場合にのみ、他のタスクを実行する前に特定のタスクを実行するなど、条件付きフローで役立ちます。ここでは前のタスクの実行結果が成功で、かつ (実行時に動的に設定された) 変数 @CountPartitions の値が 0 の場合にのみワークフローの次のタスクを実行するように設定します。この制御は、図 39 に示すような条件を設定することで実現しました。

1つのタスクに複数の優先順位制約を設定する場合、ユーザーは、次のタスクを実行するために、すべての制約を満たす必要があるのか、またはいずれかの制約を満たせばよいのかを指定できます。次の例では、すべての優先順位制約が True の場合のみ、次のタスクを実行するようにプロパティを設定しました。

パッケージ実行

実行時、DTS ランタイム エンジンでは、パッケージ内の各タスクを、パッケージ ワークフローで指定されている順に実行します。DTS パッケージは、Business Intelligence Development Studio の SSIS デザイナから、SSIS インポートおよびエクスポート ウィザードから、または SSIS パッケージ実行ユーティリティを使用して実行できます。

Business Intelligence Development Studio では、パッケージの実行中にパッケージをデバッグすることができます。BI Development Studio では、Microsoft Visual Studio と似たパッケージのデバッグ環境が提供されます。パッケージのテストでは、特定の場所にブレークポイントを設定したり、変数にウォッチを設定して変数を監視することによって、多数のエラーを解決することができました。ブレークポイントは、次のイベントに設定できます。

• OnPreExecute

• OnPostExecute

• OnError

• OnWarning

• OnInformation

• OnTaskFailed

• OnProgress

• OnQueryCancel

• OnVariableValueChanged

• OnCustomEvent

ブレークポイントの追加

ブレークポイントを設定するタスクを右クリックします。[ブレークポイントの編集] をクリックし、イベントを選択します (または F9 キーを押して、選択したオブジェクトに実行前ブレークポイントを追加することもできます)。パッケージを実行すると、図 40 に示すように、選択したイベントで実行が中断されます。

このホワイトペーパーの前半の「パッケージへのログ記録機能の追加」で説明したログ記録の機能を有効にして、パッケージ実行に関するイベントを記録することをお勧めします。

DTExec ユーティリティを使用すると、コマンド ラインからパッケージを実行することができます。また、接続、プロパティ、変数、ログ記録、進行状況インジケータなど、パッケージの構成と実行に関するすべての機能にアクセスできるだけでなく、3 つのソース (Microsoft SQL Server データベース、DTS サービス、ファイル システム) からパッケージを読み込む機能も用意されています。

Analysis Services によるパーティションの複製

第 1 フェーズで使用した SQL Server 2000 DTS パッケージには、SQL Server に接続するコードが含まれており、このコードでは、追加されたデータの日付に基づいて Analysis Services のキューブに新しい月単位のパーティションが必要かどうかを判断しています。このクエリは、SQL-DMO を使用した ActiveX スクリプト タスクの一部として SQL Server に対して実行されています。新しい月単位のパーティションを作成する必要がある場合は、Decision Support オブジェクト (DSO) コードが実行され、Analysis Services に対応するパーティションが作成されました。この DSO コードでは、既存のパーティションの "複製" を作成し、読み込まれたデータの新しい年と月に基づいたスライス値を使用した新しい名前が付けられていました。

この機能を SSIS に移行する際には、同等のタスクを実行する方法を再考する必要があり、次のような問題を解決する必要がありました。

• SQL-DMO と DSO を引き続き使用するか、または .NET スクリプト タスクにアップグレードするかどうか。

• .NET スクリプトを使用するか、または SSIS のネイティブなタスクを使用するかどうか。

• 既存のプログラミング モデルを使用するか、または SQL Server 2005 の同等のプログラミング モデル (SQL 管理オブジェクト (SMO) / 分析管理オブジェクト (AMO)) を使用するかどうか。

いくつかはすぐに決断しました。まず、.NET スクリプト タスクを使用することにしました。そして、ActiveX スクリプト タスクのコードをアップグレードすることにしました。1 つ目に関しては、SQL-DMO を呼び出して、新しいパーティションを作成するかどうかを判断するコードを開発する必要がありました。クエリ アクセスには管理オブジェクト モデルを使用できないので、ADO.NET を使用してデータ アクセス コードを記述し直しましたが、この作業では、Microsoft Developer Network (MSDN) からコード サンプルを切り取って、貼り付けることができたので、とても簡単でした。このコードは、次のようになりました。

Dim sPartition As String
        Dim conn As SqlConnection = New SqlConnection("Data Source=servername;" &                                                       
"Integrated Security=SSPI;Initial Catalog=DW1")
        Dim partCMD As SqlCommand = conn.CreateCommand()
        partCMD.CommandText = "select partitionname from partitions where status = 'N'"
        conn.Open()
        Dim myReader As SqlDataReader = partCMD.ExecuteReader()
        myReader.Read()
        'if this is not a new month, exit out
        If myReader.HasRows = False Then
            'update DTS global variable
Dts.VariableDispenser.LockOneForWrite("ItemSalesXML", vars)
            vars.Item("ItemSalesXML").Value = " "
            Exit Sub
        'it is a new month, set the partition variable value
        Else
            sPartition = myReader("partitionname").ToString()
        End If

2 つ目については、DSO コードを AMO にアップグレードするのか、または別の方法を採用するのかを決める必要がありました。ここでは、別の方法を採用することにしました。SQL Server Management Studio のグラフィカル インターフェイスを使用し、SQL Server Management Studio で (XML for Analysis スクリプト言語を使用して) Anlysis Services データベースのパーティションをスクリプト化し、.NET スクリプト タスクでパーティション名を動的に変更しました。その後、.NET スクリプト タスクで、新しく形成した XML for Analysis 文字列を SSIS のグローバル変数に割り当てました。さらに、SSIS グローバル変数で定義した XML for Analysis コードを実行する追加のタスク (新しい Analysis Services DDL 実行タスク) を準備しました。

ここでは、AMO プログラミング モデルを使用してコードを記述し直すという選択肢もありましたが、このアプローチを採用するには、より長い学習時間が必要になります。技術的な堅牢性は劣りますが、すばやく実装することができるため、XML for Analysis アプローチを採用しました。このアプローチは、ベスト プラクティスではないかもしれませんが、切羽詰った開発者が最も楽な方法として選択するアプローチであることは間違いないでしょう。

カスタム ソース コンポーネントと変換コンポーネントによる SSIS データ フロー タスクの拡張

「主要な ETL プロセス」で説明したように、読み込む売上データは、ユーザーの店舗販売時点管理 (POS) レジで生成される TLOG データの形式になっています。

このパッケージを SSIS に移行するには、TLOG データをデータベースに読み込む方法のデザインを再考する必要がありました。引き続き Perl スクリプトを使用してデータを解析するか、またはパーサーをパイプライン内でデータを解析するカスタム データ フロー コンポーネントに変換するべきかで悩みました。後者のアプローチは、パフォーマンスが優れており、合理的で効率的な ETL プロセスが提供されると判断しました。また、このアプローチには、データを TLOG ファイルからフラット ファイルにコピーし、さらにデータベースにコピーするという高コストな手順を回避できるという大きな魅力がありました。このアプローチは管理性にも優れているため、TLOG データを読み込むカスタム タスクを実装することにしました。

TLOG ファイルには、各行が改行またはコンマによって区切られている、圧縮された decimal 型のデータが含まれています。そのため、既存のデータ フロー ソースを使用して、データ ファイルを読み取ることができず、データを解析するには、圧縮された decimal 型のデータを展開する必要がありました。処理と管理を単純にするため、バイナリ ファイルを展開するロジックは、テンプレート ファイルに基づいてデータを解析するロジックと切り離すことにしました。その結果、次の 2 つのカスタム パイプライン コンポーネントを実装しました。

• データを読み取るためのカスタム ソース コンポーネント

• データを解析するためのカスタム変換コンポーネント

これらのコンポーネントは、どちらも PipelineComponent 基本クラスから派生されたもので、適切なメソッドをオーバーライドします。ソース コンポーネントでは、ファイル接続を使用して外部の TLOG ファイルに接続し、入力としてテンプレート ファイルを使用することができます。ソース コンポーネントでは、テンプレートに基づいて、圧縮された decimal 型のデータを展開し、適切な 16 進数または ASCII 文字に変換します。次にテンプレート形式の例を示します。

"02" => ["H2","H10","H6","H2"],

"99-Data" => ["H2","A4","A99"]

ソース コンポーネントは、テンプレートに基づいてデータを展開し、1 つの列を持つ DT_TEXT 型の 1 行を出力します。

図 41 は、ソース コンポーネントのコンポーネント プロパティの一例です。

カスタム コンポーネントでは、上流工程のデータ フローから展開されたデータを読み取り、.ini ファイルに基づいてデータを解析し、下流工程のデータ フローに対して複数の出力を生成します。カスタム変換コンポーネントでは、次の 2 つの入力を指定できます。

構成ファイル : .ini ファイルのパス

店舗名 : 解析する TLOG ファイルの店舗番号

次に、この形式の ,ini ファイルの例を示します。

[01]
Filename="Item"
DelimiterCharacter=","
OutputFields="%store,%line,1-0,%term,%tran,%datetime,1-1,1-2,1-3,1-4

カスタム変換コンポーネントでは、図 42 に示すように、.ini ファイルで定義されている一連のルールに基づいて複数の DT_STR 型の出力を生成します。

図 43 は、TLOG のソース コンポーネントと変換コンポーネントを含むパッケージです。

カスタム データフロー コンポーネントのデザインの詳細とサンプル コードについては、別のホワイト ペーパーで取り上げる予定です。

詳細エディタ

通常、パッケージを編集する場合、項目のプロパティを編集するには、タスクまたはデータ フロー項目をダブルクリックしますが、一部のオブジェクトについては、既定のエディタと詳細エディタの 2 つのエディタを使用することができます。詳細エディタが存在するオブジェクトについては、詳細エディタを使用すると、そのオブジェクトの詳細なプロパティを変更することができます。SSIS で使用するオブジェクトの種類ごとに、どのような場合に詳細エディタを使用して、どのような場合に既定のエディタを使用するのかを調査することをお勧めします。詳細エディタを起動するには、タスクやソースなどを右クリックし、[詳細エディタの表示] をクリックします (図 44 参照)。

詳細エディタを使用するときは、SQL Server 2000 DTS でオフライン編集モードを使用するときと同様の注意を払う必要があります。詳細エディタでは、多数のプロパティに直接アクセスすることができますが、設定を誤るとパッケージに深刻な悪影響を及ぼす可能性があります。ただし、詳細エディタを使用するのが、パッケージで発生している問題を解決する最善の方法になる場合があります (この例については、このホワイト ペーパーの後半にある「ファイル接続オブジェクトへの変更がフラット ファイル ソースに反映されないことがある」で紹介しています)。

パフォーマンスに関するヒント

• パッケージが接続先の SQL Server 2005 リレーショナル データベース インスタンスと同じサーバーで実行されている場合は、OLE DB 接続ではなく、SQL Server 変換先コンポーネントを使用します。このコンポーネントは、インプロセスで実行されるため、接続のオーバーヘッドを回避できます。このコンポーネントを使用すると、OLE DB 接続と比較して、最大で 25% も高速になります。

• パフォーマンスを向上させるには、データ フローから不要な列を削除します。データ フロー エンジンでは、使用されていない出力列に関する警告メッセージを表示します。このような列を削除すると、エンジンでは、使用されない領域を割り当てたり、データを処理する必要がなくなります。

• タスクの EngineThreads プロパティには、タスクで使用するスレッドの数を設定します。既定値は 5 ですが、マルチプロセッサ サーバーでは、この数値を大きくしてパフォーマンスを向上させることができます。最適なパフォーマンスを実現するスレッド数は、テストによって特定できます。

マルチプロセッサ サーバーでは、依存関係のないタスクを同時に実行します。たとえば、データ ウェアハウス プロジェクトの場合、ファクト テーブルで異なるディメンション テーブルにアクセスしており、同時に読み込んでも問題がなければ、データ ウェアハウスにディメンション テーブルを読み込んだら、図 45 に示すようにデータを並列に読み込むことができます。

同時実行により最適なパフォーマンスを実現するタスクの数を特定するにはテストを行う以外に方法がありませんが、まずは、プロセスと同数のタスクを同時に実行してみることをお勧めします。

発生した問題

開発中の製品で問題が発生するのは避けられないことですが、このプロジェクトでは、多数の技術的な問題に遭遇しました。SQL Server 2005 の Community Preview Release (IDW9) を使用している場合は、同じ問題に遭遇する可能性があります。ここで紹介する問題は、SQL Server 2005 Beta 3 リリースで解決されることを見込んでいます。

名前付きインスタンスに対して SQL Server 変換先が機能しない

データ フロー タスクを作成するとき、SQL Server 変換先を使用すると、最も効率的に SQL Server テーブルを読み込むことができます。SQL Server 変換先は、SQL Server インスタンスへの高度に最適化されたメモリ内接続で、可能な限り SQL Server インスタンスへの接続として使用する必要があります (この接続を使用すると、図 46 に示す OLE DB の高速読み込みの対象を使用する方法よりも、最大で 25% 高速になります)。

SQL Server 変換先の欠点は、SQL Server インスタンスが SSIS パッケージと同じサーバーに存在する必要があるということです。これには、開発時の環境も含まれるため、データ フローに SQL Server 変換先を追加するには、変換先となる SQL Server がインストールされたコンピュータで開発を行う必要があります。別のサーバーで開発を行う必要がある場合は、OLE DB 変換先を使用して、SQL Server のインスタンスを指定し、図 46 に示すように [データ アクセス モード] ボックスの一覧で "高速読み込み" を選択する必要があります。

残念ながら、このプロジェクトの開発に使用した IDW9 Community Preview Release では、名前付きインスタンスに対して SQL Server 接続を使用することができませんでした (bug #323570)。この問題は、次に公開されるバージョンの SQL Server 2005 では確実に修正されることが見込まれます。

ファイル接続オブジェクトへの変更がフラット ファイル ソースに反映されないことがある

通常、フラット ファイル接続マネージャを使用してファイルへの接続を作成する場合は、列とそのレイアウトを定義します。この情報は、この接続をデータ フローでフラット ファイル ソースとして使用するときに取得されます。ただし、列のレイアウトに変更を加えた場合、その変更がフラット ファイル ソースに反映されないことがあります。列のレイアウト変更をフラット ファイル ソースに反映するには、データ フローに含まれるフラット ファイル ソースを編集し、列の定義を手動で更新する必要があります。この問題は、列の長さを設定するプロパティを更新した場合に、特によく見られました。また、この変更を行うには、詳細エディタを使用して、フラット ファイル ソースのプロパティを変更する必要がありました。フラット ファイル ソースをダブルクリックすると、図 47 に示すような既定のエディタが起動します。

フラット ファイル ソースを右クリックすると、ショートカット メニューの [詳細エディタの表示] が表示されます。このオプションをクリックすると、フラット ファイル ソースの詳細エディタが起動されます。詳細エディタでは、既定のエディタには表示されない列のプロパティを構成して、必要な変更を加えることができます。たとえば、図 48 に示すように、列のマッピングや各列のさまざまなプロパティを管理することができます。

SSIS パッケージのデバッグ中に BI Development Studio を最小化すると GUI が表示されなくなる

デバッグ中に BI Development Studio のグラフィカル インターフェイスが表示されなくなるという現象が何度か発生しました。この現象を再現する一貫した方法はありませんが、この現象の影響は大きいため、指摘に値すると判断しました。パッケージのデバッグ中に、デバッガを最小化すると、開発環境が表示されなくなることがありました。通常画面下部にある Windows タスク バーに表示されず、視覚的にも表示されず、とにかく消えてしまったように見えました。ただし、タスク マネージャを確認すると BIENV.EXE (BI Developer Studio の実行可能ファイル) はシステムで実行しているプロセスとして一覧されていました。Alt キーを押しながら、Tab キーを押してデザイナを表示すると、問題が解決しました (Windows タスク バーには表示されませんでしたが、Alt + Tab キーを押すと表示されるようになりました)。この操作を行うと、開発環境にフォーカスが戻り、Windows タスク バーにも開発環境が復元されました。

製品に対する機能強化の要請

第 1 フェーズでの SSIS についての取り組みでは、製品について、いくつかの機能強化の要請を行いました。ここでは、これらの要請を紹介します。

フラット ファイルの読み込み中に発生する "不完全な行" の問題

ファイルの読み込み中に、"不完全な行" に関するエラーが発生しました。メモ帳では、この "不完全な行" を確認できませんでした。この問題のトラブルシューティングを行う際、Visual Studio に有益な機能を見つけました (この機能については、後で説明します)。ファイルを開くときには、([ファイル] メニューの [開く] をクリックして、ファイルをクリックすると) 図 49 に示すように、[開く] ボタンの隣にある下向き矢印をクリックすることができます。

[プログラムから開く] をクリックすると、図 50 に示すように、バイナリ エディタを選択することができます。

バイナリ エディタで表示すると、このファイルの末尾に 16 進数の "1A" が表示されます (図 51 参照)。これは Windows (少なくとも Windows Server 2003) のファイルの終わり (EOF) マークで、通常のコピー コマンドでは、この値がファイルの末尾に挿入されます。このホワイト ペーパーの執筆時点では、SSIS により、このマークはデータ ファイルの新しい行と見なされ、不完全な行として処理されました。残念ながら、この状況では、SSIS はファイルの読み取りを停止し、タスクの状態は失敗に設定されます。

この変更要請は #323638 に記録され、最低でも、ファイルの終わり (EOF) マークを無視するオプションを提供するように要求しました。このプロジェクトでは、この問題の回避策として、実行しているコピー コマンドを変更し、/B オプションを含めるようにしました。このオプションをコピー コマンドに追加すると、ファイルの種類がバイナリに設定されるため、コピーしたファイルの内容が変更されることはありません。

派生列変換エディタで列の定義を変更するとデータの型が変更される

派生列変換を作成しているときに、列の定義を変更する必要が出てきました。この単純な変更を加えたところ、文字列 (DT_STR) と指定していたデータ型が Unicode 文字列 (DT_WSTR) に変更されました。ここでは、新しい列の定義に使用する既存の列のサブストリング ステートメントに変更を加えましが、"substring(optional, 1, 8)" を "substring(optional, 1, 9)" にするという単純な変更でした。このような小さな変更により、対象となる派生列のデータ型がリセットされてしまうことを予想する人はいないでしょう。技術的には、これは、対象となる派生列のデータ型を既定の定義にリセットする列への変更であるため、このホワイト ペーパーの執筆時点では、この動作は "仕様" と見なされています。今後のリリースで、この動作が解決されない場合、これは注意する必要がある問題です。

一括挿入タスクでフラット ファイル接続をソースとして使用できない

ファイルを開いてレコードのフィルタ選択を実行する際には、"フラット ファイル接続マネージャ" 接続を使用しました。この接続を使用すると、列のレイアウトとファイルの場所を定義することができました。テキスト ファイルをフィルタ処理した後で、ファイルを保存し、同じ接続を使用して一括挿入タスクでファイルを読み込むことにしました。ところが、一括挿入タスクでは "ファイル接続マネージャ" からの接続しか使用できませんでした (違いは軽微なものですが、名前が違うことに注意してください)。一括挿入タスクを実行するには、"ファイル接続マネージャ" を使用して冗長な接続を定義する必要がありました。そのため、一括挿入タスクで "フラット ファイル接続マネージャ" オブジェクトを直接ソースとして使用できるようにするデザイン変更要請を行いました。Beta 3 では、フラット ファイル接続マネージャ オブジェクトは、より幅広い用途で使用できるようになる予定です。

ファイル システム タスクでワイルドカード文字を指定できない

プロジェクト REAL で必要な操作には、ディレクトリ構造をループ処理しながらファイルをコピーしたり、移動することが必要な場合がありました。たとえば、複数のファイルの内容を 1 つのテキスト ファイルにコピーしたり、ファイルを読み込んだ後に "処理する" ディレクトリから "処理済み" のディレクトリに移動するなどの操作がありました。通常、SQL Server 2000 DTS では、これらのタスクには、バッチ ファイルを呼び出すプロセス実行タスクが使用されていました。SSIS では、この操作が、バッチファイルに依存せずに、ファイル システム タスクを使用できるようになることを期待していました。

残念ながら、ファイル システム タスクは、あるディレクトリまたは一連のディレクトリに含まれている、すべてのファイルに対して動作します。厄介なことに、ほとんどのディレクトリには、複数の種類のファイルが存在するため、(*.txt ファイルのみなど) 特定のファイルの種類に対してタスクを実行することを希望していました。ファイル システム タスクは、ファイルの拡張子でフィルタ選択を実行することができないため、プロセス実行タスクを使用することになりました。そのため、フィルタ選択でファイルの拡張子を使用できるようにするというデザイン変更要請を行いました。

Analysis Services 処理タスクの進行状況についての情報が不十分である

Analysis Services 処理タスクでは、複雑なキューブの処理中に多数の "% 完了しました" というメッセージを [進行状況] タブに出力します。残念ながら、このメッセージには、どのオブジェクトの進行状況が報告されているのかを特定する情報が含まれていません。このような情報では、プロセスの状況を測定することができません。そのため、このログ記録で詳細情報を提供するようにするというデザイン変更要請を行いました。このホワイト ペーパーの執筆時点では、この要請についての回答は得られませんでした。

まとめ

このホワイト ペーパーで説明したように、SQL Server 2000 DTS と SQL Server 2005 の新しい Integration Services の間には多数の相違点があります。マイクロソフトでは、ユーザーが既存の SQL Server 2000 DTS パッケージを継続して実行できるように取り組みましたが、このホワイト ペーパーの簡単な説明から、常に単純明快な移行手段が簡単に利用できるとは限らないことがおわかりいただけたと思います。SQL Server 2005 Integration Services の大幅なアーキテクチャの変更と拡張機能により、既存の DTS 2000 パッケージを正常に移行するには、どのタスクが移行可能で、どのタスクを書き直す必要があるのかを把握することが重要になります。移行する各パッケージを評価したら、十分な時間を確保して、移行できないタスクを書き直すか、またはそのようなタスクの書き直し作業が完了するまで DTS 2000 ランタイム エンジンを使用してパッケージを実行する計画を立てる必要があります。

また、SQL Server 2005 Integration Services では、多数の新しい概念が導入されました。たとえば、効率的な処理を行うために、既存の DTS 2000 プログラマが受け入れる必要のあるパラダイム シフトがあります。この製品の主要な新機能を理解するには、同梱されているサンプルの調査に時間をかけることをお勧めします。Visual Basic や Visual C# などの Visual Studio (VS) の言語を熟知している開発者は、新しい SQL Server 2005 BI Development Studio は、わかりやすく使い慣れた感じがするでしょう。VS に詳しくない開発者には、Visual Studio のトレーニングやオンライン チュートリアルが役立つことがあります。

詳細情報

Integration Services など、SQL Server 2005 の詳細については、Microsoft SQL Server 2005 ホーム ページを参照してください。