Informatica PowerCenter 9.0.1 パフォーマンスのチューニングの … Documentation/1/PC_901... · Informatica PowerCenter パフォーマンスのチューニングの概要

Informatica PowerCenter (参照項目 9.0.1)

パフォーマンスのチューニングの概要

Informatica PowerCenter パフォーマンスのチューニングの概要

参照項目 9.0.16月 2010

著作権 1998-2010 Informatica. すべての権利を保留する.

本ソフトウェアおよびマニュアルには、Informatica Corporationの所有権下にある情報が収められています。これらは使用および開示の制限等を定めた使用許諾契約のもとに提供され、著作権法により保護されています。本ソフトウェアのリバースエンジニアリングは禁じられています。本マニュアルのいかなる部分も、いかなる手段（電子的複写、写真複写、録音など）によっても、Informatica Corporation の事前の承諾なしに複製または転載することは禁じられています。このソフトウェアは、米国および/または国際的な特許、およびその他の出願中の特許によって保護されています。

合衆国政府によるソフトウェアの使用、複製または開示は、DFARS 227.7202-1（a）および227.7702-3（a）（1995年）、DFARS252.227-7013©（1）（ii）（1988年10月）、FAR 12.212（a）（1995年）、FAR 52.227-19、またはFAR 52.227-14（ALT III）に記載されているとおりに、当該ソフトウェア使用許諾契約に定められた制限によって規制されます。

本製品または本書の情報は、予告なしに変更されることがあります。お客様が本製品または本書内に問題を発見された場合は、書面にて当社までお知らせください。

Informatica、Informatica Platform、Informatica Data Services、PowerCenter、PowerCenterRT、PowerCenter Connect、PowerCenterData Analyzer、PowerExchange、PowerMart、Metadata Manager、Informatica Data Quality、Informatica Data Explorer、InformaticaB2B Data Transformation、Informatica B2B Data Exchange、およびInformatica On Demandは、Informatica Corporationの米国および世界中の管轄地での商標または登録商標です。 BEAおよびWebLogicはBEA Systems, Incの登録商標です。その他の会社名および製品名はすべてそれぞれの所有者の商品名または商標です。

本ソフトウェアまたはドキュメントの一部は、次のサードパーティが有する著作権に従います（ただし、これらに限定されません）。Copyright DataDirect Technologies.All Rights Reserved.Copyright © Sun Microsystems.All Rights Reserved.Copyright © RSASecurity Inc. All Rights Reserved.Copyright © Ordinal Technology Corp. All rights reserved. Copyright © Aandacht c.v. Allrights reserved. Copyright Genivia, Inc. All rights reserved. Copyright 2007 Isomorphic Software. All RightsReserved.Copyright © Meta Integration Technology, Inc. All rights reserved. Copyright © Oracle. All Rights Reserved.Copyright© Adobe Systems Incorporated. All Rights Reserved.Copyright © DataArt, Inc. All rights reserved. Copyright © ComponentSource.All Rights Reserved.Copyright © Microsoft Corporation. All Rights Reserved.Copyright © Rouge Wave Software, Inc. All rightsreserved. Copyright © Teradata Corporation. All Rights Reserved.Copyright © Yahoo! Inc. All rights reserved. Copyright ©

Glyph & Cog, LLC. All Rights Reserved.

本製品には、Apache Software Foundation（http://www.apache.org/）によって開発されたソフトウェア、およびApache License, Version2.0（「ライセンス」）の下に許諾されたその他のソフトウェアが含まれています。ライセンスのコピーはhttp://www.apache.org/licenses/LICENSE-2.0から入手することができます。適用法にて要求されないか書面にて合意されない限り、ライセンスの下に配布されるソフトウェアは「現状のまま」で配布され、明示的あるいは黙示的かを問わず、いかなる種類の保証も行われません。ライセンス下での許諾および制限を定める具体的文言については、ライセンスを参照してください。

本製品には、Mozilla（http://www.mozilla.org/）によって開発されたソフトウェア、ソフトウェアcopyright The JBoss Group, LLC, allrights reserved; ソフトウェアcopyright, Red Hat Middleware, LLC, all rights reserved; Copyright © 1999-2006 by Bruno Lowagieand Paulo SoaresおよびGNU Lesser General Public License Agreement（http://www.gnu.org/licenses/lgpl.htmlを参照）の下に許諾されたその他のソフトウェアが含まれています。資料は、Informaticaが無料で提供しており、一切の保証を伴わない「現状渡し」で提供されるものとし、Informatica Corporationは市場性および特定の目的の適合性の黙示の保証などを含めて、一切の明示的及び黙示的保証の責任を負いません。

>製品には、ワシントン大学、カリフォルニア大学アーバイン校、およびバンダービルト大学のDouglas C.Schmidtおよび同氏のリサーチグループが著作権を持つACE（TM）およびTAO（TM）ソフトウェアが含まれています。Copyright © 1993-2006, all rights reserved.

本製品には、OpenSSL Toolkitを使用するためにOpenSSL Projectが開発したソフトウェア（copyright The OpenSSL Project.All RightsReserved）が含まれ、このソフトウェアの再配布は、http://www.openssl.orgにある使用条件に従います。

本ソフトウェアには、CurlソフトウェアCopyright 1996-2007, Daniel Stenberg, <[email protected]>が含まれます。All Rights Reserved.本ソフトウェアに関する許諾および制限は、http://curl.haxx.se/docs/copyright.htmlにある使用条件に従います。すべてのコピーに上記の著作権情報とこの許諾情報が記載されている場合、目的に応じて、本ソフトウェアの使用、コピー、変更、ならびに配布が有償または無償で許可されます。

本製品には、ソフトウェアcopyright 2001-2005 (©) MetaStuff, Ltd. All Rights Reserved.が含まれます。本ソフトウェアに関する許諾および制限は、http://www.dom4j.org/license.htmlにある使用条件に従います。

製品には、ソフトウェアcopyright © 2004-2007, The Dojo Foundationが含まれます。All Rights Reserved.本ソフトウェアに関する許諾および制限は、http://svn.dojotoolkit.org/dojo/trunk/LICENSEにある使用条件に従います。

本製品には、ICUソフトウェアcopyright International Business Machines Corporation and othersが含まれます。All Rights Reserved.本ソフトウェアに関する許諾および制限は、http://source.icu-project.org/repos/icu/icu/trunk/license.htmlにある使用条件に従います。

本製品には、ソフトウェアcopyright © 1996-2006 Per Bothnerが含まれます。All Rights Reserved.お客様がこのようなソフトウェアを使用するための権利は、ライセンスで規定されています。http://www.gnu.org/software/kawa/Software-License.htmlを参照してください。

本製品には、OSSP UUIDソフトウェアCopyright © 2002 Ralf S. Engelschall, Copyright © 2002 The OSSP Project Copyright © 2002Cable & Wireless Deutschlandが含まれます。本ソフトウェアに関する許諾および制限は、http://www.opensource.org/licenses/mit-license.phpにある使用条件に従います。

本製品には、Boost（http://www.boost.org/）によって開発されたソフトウェアまたはBoostソフトウェアライセンスの下で開発されたソフトウェアが含まれています。本ソフトウェアに関する許諾および制限は、http://www.boost.org/LICENSE_1_0.txtにある使用条件に従います。

本製品には、ソフトウェアcopyright © 1997-2007 University of Cambridgeが含まれます。本ソフトウェアに関する許諾および制限は、http://www.pcre.org/license.txtにある使用条件に従います。

本製品には、ソフトウェアcopyright © 2007 The Eclipse Foundationが含まれます。All Rights Reserved.本ソフトウェアに関する許諾および制限は、http://www.eclipse.org/org/documents/epl-v10.phpにある使用条件に従います。

本製品には、http://www.tcl.tk/software/tcltk/license.html、http://www.bosrup.com/web/overlib/?License、http://www.stlport.org/doc/license.html、http://www.asm.ow2.org/license.html、http://www.cryptix.org/LICENSE.TXT、http://hsqldb.org/web/hsqlLicense.html、http://httpunit.sourceforge.net/doc/license.html、http://jung.sourceforge.net/license.txt、http://www.gzip.org/zlib/zlib_license.html、http://www.openldap.org/software/release/license.html、http://www.libssh2.org、http://slf4j.org/license.html、http://www.sente.ch/software/OpenSourceLicense.html、およびhttp://fusesource.com/downloads/license-agreements/fuse-message-broker-v-5-3-license-agreementの条項の下に許諾されたソフトウェアが含まれています。

本製品には、Academic Free License（http://www.opensource.org/licenses/afl-3.0.php/）、Common Development and DistributionLicense（http://www.opensource.org/licenses/cddl1.php）、Common Public License（http://www.opensource.org/licenses/cpl1.0.php）およびBSD License（http://www.opensource.org/licenses/bsd-license.php）の下に許諾されたソフトウェアが含まれています。

本製品には、ソフトウェアcopyright © 2003-2006 Joe WaInes, 2006-2007 XStream Committersが含まれています。All Rights Reserved.本ソフトウェアに関する許諾および制限は、http://j.org/license.htmlにある使用条件に従います。本製品には、Indiana UniversityExtreme! Labによって開発されたソフトウェアが含まれています。詳細については、http://www.extreme.indiana.edu/を参照してください。

本ソフトウェアは、米国の特許番号5,794,246; 6,014,670; 6,016,501; 6,029,178; 6,032,158; 6,035,307; 6,044,374; 6,092,086;6,208,990; 6,339,775; 6,640,226; 6,789,096; 6,820,077; 6,823,373; 6,850,947; 6,895,471; 7,117,215; 7,162,643; 7,254,590; 7,281,001; 7,421,458; 7,584,422、国際的な特許、およびその他の出願中の特許によって保護されています。

免責：本文書は、一切の保証を伴わない「現状渡し」で提供されるものとし、Informatica Corporationは他社の権利の非侵害、市場性および特定の目的への適合性の黙示の保証などを含めて、一切の明示的および黙示的保証の責任を負いません。Informatica Corporationでは、本ソフトウェアまたはドキュメントに誤りのないことを保証していません。本ソフトウェアまたはドキュメントに記載されている情報には、技術的に不正確な記述や誤植が含まれる場合があります。本ソフトウェアまたはドキュメントの情報は、予告なしに変更されることがあります。

特記事項

Informatica製品（以下「ソフトウェア」）には、Progress Software Corporation（以下「DataDirect」）の事業子会社であるDataDirectTechnologiesの特定のドライバ（以下「DataDirectドライバ」）が含まれています。DataDirectドライバには、次の用語および条件が適用されます。

1.IBMおよびその直接または間接の子会社は、DataDirectドライバを特定物として現存するままの状態で提供し、商品性の保証、特定目的

適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。国または地域によって

は、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

2.DataDirectまたは第三者は、予見の有無を問わず発生したODBCドライバの使用に関するいかなる直接的、間接的、偶発的、特別、ある

いは結果的損害に対して責任を負わないものとします。本制限事項は、すべての訴訟原因に適用されます。訴訟原因には、契約違反、保

証違反、過失、厳格責任、詐称、その他の不法行為を含みますが、これらに限るものではありません。

Part Number: PC-PTG-90100-0001

目次

序文.............................................. vi

Informaticaのリソース. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Informaticaカスタマポータル. . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Informaticaのマニュアル. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

InformaticaのWebサイト. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Informatica How-To Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Informatica Knowledge Base. . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Informatica Multimedia Knowledge Base. . . . . . . . . . . . . . . . . . . . . vii

Informaticaグローバルカスタマサポート. . . . . . . . . . . . . . . . . . . . . vii

第 1 章 : パフォーマンスのチューニングの概要....... 1

パフォーマンスのチューニングの概要. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

第 2 章 : ボトルネック............................. 3

ボトルネックの概要. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

スレッド統計の使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

スレッド統計に基づくボトルネックの除去. . . . . . . . . . . . . . . . . . . . . . 5

例. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

ターゲットのボトルネック. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

ターゲットのボトルネックの特定. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

ターゲットのボトルネックの除去. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

ソースのボトルネック. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

ソースのボトルネックの特定. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

ソースのボトルネックの除去. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

マッピングのボトルネック. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

マッピングのボトルネックの特定. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

マッピングのボトルネックの除去. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

セッションのボトルネック. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

セッションのボトルネックの特定. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

セッションのボトルネックの除去. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

システムのボトルネック. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

システムのボトルネックの特定. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

システムのボトルネックの除去. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

目次 i

第 3 章 : ターゲットの適化...................... 12

フラットファイルターゲットの適化. . . . . . . . . . . . . . . . . . . . . . . . . . . 12

インデックスおよびキー制約の削除. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

データベースのチェックポイント間隔を長く設定. . . . . . . . . . . . . . . . . . . . 13

バルクロードの使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

外部ローダーの使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

デッドロックの小化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

データベースのネットワークパケットサイズの拡張. . . . . . . . . . . . . . . . . . 15

Oracleターゲットデータベースの適化. . . . . . . . . . . . . . . . . . . . . . . . . . 15

第 4 章 : ソースの適化.......................... 16

クエリの適化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

条件フィルタの使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

データベースのネットワークパケットサイズの拡張. . . . . . . . . . . . . . . . . . 17

Oracleデータベースソースへの接続. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Teradata FastExportの使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

SybaseまたはMicrosoft SQL Serverのテーブルを結合するためのtempdbの使

用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

第 5 章 : マッピングの適化...................... 19

マッピングの適化の概要. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

フラットファイルソースの適化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

連続行のバッファ長の適化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

区切りフラットファイルソースの適化. . . . . . . . . . . . . . . . . . . . . . . 20

XMLおよびフラットファイルソースの適化. . . . . . . . . . . . . . . . . . . . 20

Single-Pass読み込みの設定. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

パススルーマッピングの適化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

フィルタの適化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

データタイプ変換の適化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

式の適化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

共通ロジックの抽出. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

集計関数呼び出しの小化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

ローカル変数での共通の式の置き換え. . . . . . . . . . . . . . . . . . . . . . . . 23

文字列演算の代わりに数値演算を実行. . . . . . . . . . . . . . . . . . . . . . . . 23

Char対CharおよびChar対Varcharの比較の適化. . . . . . . . . . . . . . . . . 23

LOOKUPの代わりにDECODEを選択. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

関数の代わりに演算子を使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

IIF関数の適化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

式の評価. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

ii 目次

External Procedureの適化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

第 6 章 : トランスフォーメーションの適化........ 26

Aggregatorトランスフォーメーションの適化. . . . . . . . . . . . . . . . . . . . . 26

単純なカラム別のグループ化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

ソート済み入力の使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

差分集計の使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

集計前のデータのフィルタリング. . . . . . . . . . . . . . . . . . . . . . . . . . . 27

ポート接続の制限. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Customトランスフォーメーションの適化. . . . . . . . . . . . . . . . . . . . . . . . 28

Joinerトランスフォーメーションの適化. . . . . . . . . . . . . . . . . . . . . . . . 28

Lookupトランスフォーメーションの適化. . . . . . . . . . . . . . . . . . . . . . . . 29

適なデータベースドライバの使用. . . . . . . . . . . . . . . . . . . . . . . . . . 29

ルックアップテーブルのキャッシュ. . . . . . . . . . . . . . . . . . . . . . . . . . 29

ルックアップ条件の適化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Lookup行のフィルタリング. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

ルックアップテーブルのインデックス処理. . . . . . . . . . . . . . . . . . . . . 32

複数のルックアップの適化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

パイプラインLookupトランスフォーメーションの作成. . . . . . . . . . . . . . 32

Sequence Generatorトランスフォーメーションの適化. . . . . . . . . . . . . . . 33

Sorterトランスフォーメーションの適化. . . . . . . . . . . . . . . . . . . . . . . . 33

メモリの割り当て. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

パーティションのワークディレクトリ. . . . . . . . . . . . . . . . . . . . . . . . 34

Source Qualifierトランスフォーメーションの適化. . . . . . . . . . . . . . . . . 34

SQLトランスフォーメーションの適化. . . . . . . . . . . . . . . . . . . . . . . . . . 34

トランスフォーメーションエラーの除去. . . . . . . . . . . . . . . . . . . . . . . . . . 35

第 7 章 : セッションの適化...................... 36

グリッド. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

プッシュダウンの適化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

コンカレントセッションおよびワークフロー. . . . . . . . . . . . . . . . . . . . . . . 37

バッファメモリ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

DTMバッファサイズの拡大. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

バッファブロックサイズの適化. . . . . . . . . . . . . . . . . . . . . . . . . . . 39

キャッシュ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

接続されるポート数の制限 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

キャッシュディレクトリの場所. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

キャッシュサイズの拡張 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

64ビットバージョンのPowerCenterの使用. . . . . . . . . . . . . . . . . . . . . . 42

ターゲットベースのコミット. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

目次 iii

リアルタイム処理. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

フラッシュ待ち時間. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

ソースベースのコミット. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

ステージングエリア. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

ログファイル. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

エラートレース. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

セッション実行後のメール. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

第 8 章 : グリッドのデプロイメントの適化........ 45

グリッドのデプロイメントの適化の概要. . . . . . . . . . . . . . . . . . . . . . . . 45

ファイルの格納. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

高帯域幅共有ファイルシステムのファイル. . . . . . . . . . . . . . . . . . . . . 46

低帯域幅共有ファイルシステムのファイル. . . . . . . . . . . . . . . . . . . . . 46

ローカルストレージファイル. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

共有ファイルシステムの使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

共有ファイルシステムの設定. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

CPUとメモリの使用量の均衡化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

PowerCenterマッピングとセッションの設定. . . . . . . . . . . . . . . . . . . . 48

ファイルシステム全体へのファイルの分散. . . . . . . . . . . . . . . . . . . . . . . . 49

ファイルを分散するようにセッションを設定. . . . . . . . . . . . . . . . . . . . 50

Sequence Generatorトランスフォーメーションの適化. . . . . . . . . . . . . . . 51

第 9 章 : PowerCenterコンポーネントの適化...... 52

PowerCenterコンポーネントの適化の概要. . . . . . . . . . . . . . . . . . . . . . . 52

PowerCenterリポジトリのパフォーマンスの適化. . . . . . . . . . . . . . . . . . . 52

リポジトリサービスプロセスおよびリポジトリの場所. . . . . . . . . . . . . . 53

オブジェクトクエリの条件の整理. . . . . . . . . . . . . . . . . . . . . . . . . . . 53

単一ノードのDB2データベースのテーブルスペース. . . . . . . . . . . . . . . . 53

データベーススキーマの適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Integration Serviceのパフォーマンスの適化. . . . . . . . . . . . . . . . . . . . 54

ネイティブドライバおよびODBCドライバの使用. . . . . . . . . . . . . . . . . . 54

ASCIIデータ移動モードでのIntegration Serviceの実行. . . . . . . . . . . . 55

リポジトリサービスのPowerCenterメタデータのキャッシュ . . . . . . . . . . 55

第 10 章 : システムの適化....................... 56

システムの適化の概要. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

ネットワークの速度の向上. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

複数のCPUの使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

ページングの削減. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

プロセッサバインドの使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

iv 目次

第 11 章 : パイプラインパーティションの使用....... 59

パイプラインパーティションの使用の概要. . . . . . . . . . . . . . . . . . . . . . . . 59

パーティション数の増加. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

良のパフォーマンスを得るためのパーティションタイプの選択. . . . . . . 60

複数のCPUの使用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

パーティション化のためのソースデータベースの適化. . . . . . . . . . . . . . . . 62

データベースのチューニング. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

ソート済みデータのグループ化. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

単一のソート済みクエリの適化. . . . . . . . . . . . . . . . . . . . . . . . . . . 63

パーティション化のためのターゲットデータベースの適化. . . . . . . . . . . . . 63

付録 A : パフォーマンスカウンタ................... 65

パフォーマンスカウンタの概要. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Errorrowsカウンタ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

ReadfromcacheカウンタおよびWritetocacheカウンタ. . . . . . . . . . . . . . . . . 66

ReadfromdiskおよびWritetodiskカウンタ. . . . . . . . . . . . . . . . . . . . . . . . . 66

Rowsinlookupcacheカウンタ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

索引.............................................. 68

目次 v

序文

『PowerCenterパフォーマンスのチューニングの概要』は、PowerCenterのパフォーマンス

向上に関心のあるPowerCenterの管理者および開発者、ネットワーク管理者、データベース

管理者を対象としています。読者は、オペレーティングシステム、ネットワーク、

PowerCenter、リレーショナルデータベースの概念、および使用する環境内のフラットファ

イルについて理解している必要があります。本ガイドで取り上げられていないデータベー

スパフォーマンスチューニングの詳細については、データベース製品の付属マニュアルを

参照してください。

Informaticaのリソース

Informaticaカスタマポータル

Informaticaのユーザーとして、Informaticaカスタマポータルサイト

（http://mysupport.informatica.com）にアクセスできます。このサイトには、製品情

報、ユーザーグループ情報、ニュースレター、Informaticaカスタマサポート事例管理シス

テム（ATLAS）へのアクセス、Informatica How-To Library、Informatica Knowledge

Base、Informatica Product Documentation、Informaticaユーザーグループコミュニティ

へのアクセスが含まれています。

Informaticaのマニュアル

Informaticaのマニュアルチームは、正確で役に立つマニュアルの作成に努めています。こ

のマニュアルに関する質問、コメント、ご意見の電子メールの送付先は、Informaticaマニ

ュアルチーム（[email protected]）です。お客様のフィードバック

は、マニュアルの改良に利用させていただきます。コメントに返信をご希望のお客様は、

その旨をお知らせください。

マニュアルチームは、必要に応じてマニュアルを更新します。製品の新のマニュアルを

入手するには、http://mysupport.informatica.comから製品マニュアルにアクセスしま

す。

vi

http://mysupport.informatica.com

mailto:[email protected]


InformaticaのWebサイト

Informatica社のWebサイトは、http://www.informatica.comからアクセスできます。この

サイトでは、Informatica社の概要と沿革、今後のイベント、営業拠点などの情報を提供し

ています。また、製品情報やパートナー情報もあります。サービス関連のページには、テ

クニカルサポート、トレーニングと教育、および実装に関するサービスの重要な情報を掲

載しています。

Informatica How-To Library

Informaticaのユーザーとして、Informatica How-To Library

（http://mysupport.informatica.com）にアクセスできます。How-To Libraryは、

Informaticaの製品および機能についての詳細を確認できるリソースのコレクションです。

一般的な問題に対するソリューションを提供したり、機能や動作を比較したり、特定の実

際のタスクを実行するための方法を示したりする記事やインタラクティブなデモンストレ

ーションが含まれています。

Informatica Knowledge Base

Informaticaのユーザーとして、Informatica Knowledge Base

（http://mysupport.informatica.com）にアクセスできます。このKnowledge Baseを利用

して、Informatica製品に関する既知の技術的問題の解決策を検索することができます。ま

た、FAQ（よくある質問）の答え、技術的ホワイトペーパー、技術的なヒントも得られま

す。Knowledge Baseに関する質問、コメント、ご意見の電子メールの送付先は、

Informatica Knowledge Baseチーム（[email protected]）です。

Informatica Multimedia Knowledge Base

Informaticaのユーザとして、Informatica Multimedia Knowledge Base

（http://mysupport.informatica.com）にアクセスできます。Multimedia Knowledge

Baseは、一般的な概念の理解を助け、具体的な各タスクの実行をガイドする教育用のマル

チメディアファイルの集まりです。 Multimedia Knowledge Baseに関する質問、コメン

ト、ご意見の電子メールの送付先は、Informatica Knowledge Baseチーム

（[email protected]）です。

Informaticaグローバルカスタマサポート

電話、またはオンラインサポートからカスタマサポートセンターに連絡できます。オンラ

インサポートのご利用には、ユーザ名とパスワードが必要です。

http://mysupport.informatica.comから、ユーザー名とパスワードが入手できます。

電話によるInformaticaグローバルカスタマサポートへの問い合わせ先は次のとおりです。

北米／南米ヨーロッパ／中東／アフ

リカ

アジア／オーストラ

リア

フリーダイヤル

ブラジル: 0800 891

0202


フランス: 00800 4632

4357


オーストラリア: 1

800 151 830

はじめに vii

http://www.informatica.com







北米／南米ヨーロッパ／中東／アフ

リカ

アジア／オーストラ

リア

メキシコ: 001 888 209

8853

北米: +1 877 463 2435

有料（標準料金）

北米: +1 650 653 6332

ドイツ: 00800 4632 4357

イスラエル: 00800 4632

4357

イタリア: 800 915 985

オランダ: 00800 4632

4357

ポルトガル: 800 208 360

スペイン: 900 813 166

スイス:00800 4632 4357

または0800 463 200

英国:00800 4632 4357また

は0800 023 4632


ベルギー: +31 30 6022

797

フランス: 0805 804632

ドイツ: 01805 702702

オランダ: +030 6022 797

ニュージーランド: 1

800 151 830

シンガポール: 001

800 4632 4357


インド：+91 80 4112

5738

viii 序文

第 1 章

パフォーマンスのチューニングの概要

¨ パフォーマンスのチューニングの概要, 1 ページ

パフォーマンスのチューニングの概要パフォーマンスのチューニングの目的は、パフォーマンスのボトルネックを取り除くこと

によって、セッションのパフォーマンスを適化することです。セッションのパフォーマ

ンスをチューニングするには、まずパフォーマンスのボトルネックを特定して、これを取

り除きます。以後、満足できる水準のセッションパフォーマンスが得られるまで、ボトル

ネックの特定と除去を続けます。セッションのパフォーマンスをチューニングするときに

は、テストロードオプションを使用してセッションを実行できます。

すべてのボトルネックのチューニングが済むと、セッション内のパイプラインパーティシ

ョンの数を増やして、セッションをさらに適化することができます。パーティションを

追加すると、セッションの処理中により多くのシステムハードウェアを利用できるように

なるため、パフォーマンスが向上します。

パフォーマンスを向上させる善の方法を見つけるには、複雑な作業が必要になります。

そこで、変数を１つずつ変更し、その前後でのそれぞれのセッションの実行時間を比較し

ます。その結果としてセッションのパフォーマンスが向上しなければ、設定を元に戻しま

す。

セッションのパフォーマンスを改善するには、以下のタスクを実行します。

1. ターゲットの適化。Integration Serviceによる、ターゲットへの書き込みを効率

化します。

2. ソースの適化。Integration Serviceによる、ソースデータの読み込みを効率化しま

す。

3. マッピングの適化。Integration Serviceによる、データのトランスフォーメーシ

ョンおよび移動を効率化します。

4. トランスフォーメーションの適化。Integration Serviceによる、マッピング内の

トランスフォーメーションの処理を効率化します。

1

5. セッションの適化。Integration Serviceによる、セッションの実行速度を速くしま

す。

6. グリッドのデプロイメントの適化。Integration Serviceによる、適なパフォー

マンスをグリッド上で実行可能にします。

7. PowerCenterコンポーネントの適化。Integration Serviceおよびリポジトリサービ

スによる、適な機能を可能にします。

8. システムの適化。PowerCenterサービスのプロセスによる、より高速での実行を可能

にします。

2 章 1: パフォーマンスのチューニングの概要

第 2 章

ボトルネック

この章では、以下の項目について説明します。

¨ ボトルネックの概要, 3 ページ

¨ スレッド統計の使用, 4 ページ

¨ ターゲットのボトルネック, 6 ページ

¨ ソースのボトルネック, 6 ページ

¨ マッピングのボトルネック, 8 ページ

¨ セッションのボトルネック, 9 ページ

¨ システムのボトルネック, 9 ページ

ボトルネックの概要パフォーマンスをチューニングする上での初の手順として、パフォーマンスのボトルネ

ックを特定します。パフォーマンスのボトルネックは、ソースおよびターゲットデータベ

ース、マッピング、セッション、ならびにシステムで発生します。方針としては、パフォ

ーマンスのボトルネックを特定して取り除いたら、以後、満足できる水準のパフォーマン

スが得られるまでボトルネックの特定と除去を続けるというものです。

パフォーマンスのボトルネックは、以下の順に調査します。

1. ターゲット

2. ソース

3. マッピング

4. セッション

5. システム

次の方法でパフォーマンスのボトルネックを特定します。

¨ テストセッションの実行。フラットファイルソースからの読み込みを行うテストセッ

ションまたはフラットファイルターゲットへの書き込みを行うテストセッションの際

に、ソースおよびターゲットのボトルネックが特定されるようにテストセッションを設

定できます。

3

¨ パフォーマンスの詳細の分析。パフォーマンスカウンタなどのパフォーマンスの詳細を

分析して、セッションのパフォーマンスが低下している箇所を特定します。

¨ スレッド統計の分析。スレッド統計を分析して、適なパーティションポイント数を決

定します。

¨ システムパフォーマンスの監視。システム監視ツールを使用して、CPU使用率、入出力

待ちおよびページングを表示することにより、システムのボトルネックを特定できま

す。 Workflow Monitorを使用して、システムリソースの使用状況を表示することもで

きます。

スレッド統計の使用セッションログでスレッド統計を使用すると、ソース、ターゲットまたはトランスフォー

メーションのボトルネックを特定できます。デフォルトでは、Integration Serviceはセッ

ションを処理するためにreaderスレッドを1つ、トランスフォーメーションスレッドを1

つ、writerスレッドを1つ使用します。ビジー率のも高いスレッドが、セッションのボ

トルネックです。

セッションログは次のスレッド統計を示します。

¨ 実行時間。スレッドの実行時間。

¨ アイドル時間。スレッドのアイドル時間。これには、アプリケーション内の他のスレ

ッドの処理を、このスレッドが待機している時間が含まれます。アイドル時間には、

Integration Serviceによってスレッドがブロックされた時間が含まれますが、オペレ

ーティングシステムによってブロックされた時間は含まれません。

¨ ビジー時間。以下の式に従って計算されたスレッド実行時間の割合。

(run time - idle time) / run time X 100

総実行時間が60秒以下などと短い場合、高いビジー率は無視できます。これは必ずしも

ボトルネックを示していません。

¨ スレッド作業時間。Integration Serviceで、1つのスレッド内の各トランスフォーメー

ションの処理にかかった時間の割合。セッションログには、トランスフォーメーショ

ンスレッド作業時間に関する以下の情報が表示されます。

Thread work time breakdown: <transformation name>: <number> percent <transformation name>: <number> percent <transformation name>: <number> percent

トランスフォーメーションにかかった時間が短い場合、そのトランスフォーメーション

はセッションログに記録されません。セッションの実行時間が短かったため、スレッド

の正確な統計がない場合は、統計が正確でないことがセッションログにレポートされま

す。

4 章 2: ボトルネック

スレッド統計に基づくボトルネックの除去

スレッド統計に基づいてボトルネックを除去するには、以下のタスクを実行します。

¨ readerまたはwriterスレッドが100%ビジーである場合、ソースポートまたはターゲット

ポートにてStringデータ型の使用を検討する必要があります。文字列でないポートは、

さらに処理をする必要があります。

¨ トランスフォーメーションスレッドが100%ビジーである場合は、セグメントへのパーテ

ィションポイントの追加を検討します。マッピングにパーティションポイントを追加す

ると、Integration Serviceはセッションで使用するトランスフォーメーションスレッ

ドの数を増加します。ただし、マシンが大限または大限に近い容量で実行されて

いる場合は、さらにスレッドを追加しないでください。

¨ 1つのトランスフォーメーションが他より多くの処理時間を必要とする場合は、このト

ランスフォーメーションにパススルーパーティションポイントを追加することを検討し

ます。

例

セッションを実行すると、セッションログは実行情報や、次のテキストと類似したスレッ

ド統計を一覧表示します。

***** RUN INFO FOR TGT LOAD ORDER GROUP [1], CONCURRENT SET [1] *****Thread [READER_1_1_1] created for [the read stage] of partition point [SQ_two_gig_file_32B_rows] has completed. Total Run Time = [505.871140] secs Total Idle Time = [457.038313] secs Busy Percentage = [9.653215]Thread [TRANSF_1_1_1] created for [the transformation stage] of partition point [SQ_two_gig_file_32B_rows] has completed. Total Run Time = [506.230461] secs Total Idle Time = [1.390318] secs Busy Percentage = [99.725359] Thread work time breakdown: LKP_ADDRESS: 25.000000 percent SRT_ADDRESS: 21.551724 percent RTR_ZIP_CODE: 53.448276 percentThread [WRITER_1_*_1] created for [the write stage] of partition point [scratch_out_32B] has completed. Total Run Time = [507.027212] secs Total Idle Time = [384.632435] secs Busy Percentage = [24.139686]

このセッションログでは、トランスフォーメーションスレッドの総実行時間が506秒、ビジ

ー率が99.7%です。これは、トランスフォーメーションスレッドが506秒の間、アイドルで

はなかったことを示します。readerおよびwriterのビジーの割合は、それぞれ9.6%および

24%と著しく低くなっています。このセッションでは、トランスフォーメーションスレッド

がマッピングのボトルネックとなっています。

トランスフォーメーションスレッド内でボトルネックになっているトランスフォーメーシ

ョンを特定するには、スレッド作業時間分析で各トランスフォーメーションのビジー率を

確認します。このセッションログで、トランスフォーメーションRTR_ZIP_CODEのビジー率

は53%です。

スレッド統計の使用 5

ターゲットのボトルネックも一般的なパフォーマンスのボトルネックは、Integration Serviceがターゲットデータ

ベースへの書き込みを行う場合に発生します。チェックポイント間隔が短いこと、データ

ベースのネットワークパケットサイズが小さいこと、または負荷の高いロード操作時の問

題によって、ターゲットのボトルネックが発生する可能性があります。

ターゲットのボトルネックの特定

ターゲットのボトルネックを特定するには、以下のタスクを実行します。

¨ フラットファイルターゲットに書き込むセッションのコピーを設定します。セッション

のパフォーマンスが著しく向上する場合は、ターゲットにボトルネックがあります。そ

のセッションで既にフラットファイルターゲットに書き込みしている場合、ターゲット

にはボトルネックがないと考えられます。

¨ セッションログのスレッド統計を読み込みます。Integration Serviceがトランスフォ

ーメーションまたはreaderスレッドよりもwriterスレッドで時間を多く使用していれ

ば、それがターゲットのボトルネックです。

ターゲットのボトルネックの除去

ターゲットのボトルネックを除去するには、以下のタスクを実行します。

¨ データベース管理者に、クエリーを適化することによってデータベースのパフォーマ

ンスを適化するように依頼します。

¨ データベースのネットワークパケットサイズを大きくします。

¨ インデックスおよびキー制約を設定します。

関連項目：

¨ 「ターゲットの適化」 (12ページの)

ソースのボトルネックパフォーマンスのボトルネックは、Integration Serviceがソースデータベースからの読み

込みを行うときに発生する可能性があります。不適切なクエリ、またはデータベースのネ

ットワークパケットサイズが小さいことによって、ソースのボトルネックが発生する可能

性があります。

ソースのボトルネックの特定

セッションログのスレッド統計を読み込んで、ソースがボトルネックになっているかどう

かを判断することもできます。Integration Serviceがトランスフォーメーションまたは

writerスレッドよりもreaderスレッドで時間を多く使用していれば、それがソースのボト

ルネックです。


セッションでリレーショナルソースからの読み込みを行う場合、次の方法でソースのボト

ルネックを特定します。

¨ Filterトランスフォーメーション

¨ 読み込みテストマッピング

¨ データベースクエリー

セッションでフラットファイルソースからの読み込みが行われる場合、ソースにはボトル

ネックがないと考えられます。

Filterトランスフォーメーションの使用

マッピング内のFilterトランスフォーメーションを使用して、ソースデータの読み込みに

かかる時間を測定できます。

各Source Qualifierの後ろにFilterトランスフォーメーションを追加します。Filterトラ

ンスフォーメーションの条件をfalseに設定すると、データがそのトランスフォーメーショ

ンを通過できなくなります。新しいセッションの実行時間が以前と同じ場合は、ソースに

ボトルネックがあります。

読み込みテストマッピングの使用

読み込みテストマッピングを作成して、ソースのボトルネックを特定できます。読み込み

テストマッピングでは、マッピング内のトランスフォーメーションを削除することによっ

て、読み込みクエリーを見つけ出します。

読み込みテストマッピングを作成するには、以下の手順を実行します。

1. 元のマッピングのコピーを作成します。

2. マッピングのコピー内で、ソース、Source Qualifier、およびユーザ作成の任意の結

合やクエリーのみを保存します。

3. トランスフォームをすべて削除します。

4. Source Qualifierをファイルターゲットに接続します。

読み込みテストマッピングに対してセッションを実行します。セッションのパフォーマン

スが元のセッションのパフォーマンスとあまり変わらない場合、ソースにボトルネックが

あると考えられます。

データベースクエリの使用

ソースのボトルネックを特定するには、ソースデータベースに対して読み込みクエリーを

直接実行します。

セッションログから、読み込みクエリーを直接コピーします。ISQLなどのクエリーツール

を使用して、ソースデータベースに対してクエリーを実行します。Windowsでは、クエリー

の結果をファイルにロードすることができます。UNIXでは、クエリーの結果を/dev/nullに

ロードすることができます。

クエリーの実行時間およびクエリーが初のレコードを返すまでにかかる時間を測定しま

す。

ソースのボトルネック 7

ソースのボトルネックの除去

ソースのボトルネックを除去するには、以下のタスクを実行します。

¨ Integration Serviceでフラットファイルソースから読み込みを行っている場合は、

Integration Serviceが読み込む行単位のバイト数を設定します。

¨ データベース管理者に、クエリーを適化することによってデータベースのパフォーマ

ンスを適化するように依頼します。

¨ データベースのネットワークパケットサイズを大きくします。

¨ インデックスおよびキー制約を設定します。

¨ データベースクエリーの2回の測定間で遅延が大きい場合は、オプティマイザヒントを

使用します。

関連項目：

¨ 「ソースの適化」 (16ページの)

マッピングのボトルネックソースまたはターゲットにボトルネックがないことを確認した場合は、マッピングにボト

ルネックが存在する可能性があります。

マッピングのボトルネックの特定

マッピングのボトルネックを特定するには、以下のタスクを実行します。

¨ セッションログからスレッド統計および作業時間統計を読み込みます。Integration

Serviceがwriterまたはreaderスレッドよりもトランスフォーメーションスレッドで時

間を多く使用していれば、それがトランスフォーメーションのボトルネックです。

Integration Serviceがトランスフォーメーションでより多くの時間を使用していれ

ば、それがトランスフォーメーションスレッド内のボトルネックです。

¨ パフォーマンスカウンタを分析します。errorrowsカウンタおよびrowsinlookupcache

カウンタの高い値によって、マッピングのボトルネックが示されます。

¨ 各ターゲット定義の前にFilterトランスフォーメーションを追加します。データがター

ゲットテーブルにロードされないように、フィルタ条件を偽に設定します。新しいセッ

ションの実行時間が元のセッションの実行時間と同じ場合は、マッピングにボトルネッ

クがあると考えられます。

マッピングのボトルネックの除去

マッピングのボトルネックを除去するには、マッピングのトランスフォーメーション設定

を適化します。


関連項目：

¨ 「マッピングの適化」 (19ページの)

セッションのボトルネックソース、ターゲット、またはマッピングにボトルネックがないことを確認できた場合、セ

ッションにボトルネックが存在する可能性があります。キャッシュのサイズやバッファの

メモリ容量の不足、およびコミットの間隔が短いことが原因で、セッションのボトルネッ

クが発生することがあります。

セッションのボトルネックの特定

セッションのボトルネックを特定するには、パフォーマンスの詳細を分析します。パフォ

ーマンスの詳細には、入力行、出力行およびエラー行の数など、各トランスフォーメーシ

ョンに関する情報が表示されます。

セッションのボトルネックの除去

セッションのボトルネックを除去するには、セッションを適化します。

関連項目：

¨ 「セッションの適化」 (36ページの)

システムのボトルネックソース、ターゲット、マッピングおよびセッションをチューニングした後、システムのボ

トルネックを回避するためにシステムのチューニングを検討します。Integration Service

ではシステムリソースを使用して、トランスフォーメーションの処理、セッションの実

行、およびデータの読み込みと書き込みを行います。また、Integration Serviceでは、

システムメモリを使用して、Aggregator、Joiner、Lookup、Sorter、XMLおよびRankなど

のトランスフォーメーションのためのキャッシュファイルを作成します。

システムのボトルネックの特定

システムのリソース使用率は、Workflow Monitorで確認できます。システムツールを使用

すると、WindowsシステムおよびUNIXシステムをモニタリングできます。

Workflow Monitorを使用したシステムのボトルネックの特定

Workflow MonitorでIntegration Serviceプロパティを表示すると、Integration Service

でタスクプロセスを実行しているときのシステムのCPU使用率、メモリ使用量およびスワッ

セッションのボトルネック 9

プ使用状況を確認できます。パフォーマンスの問題を特定するには、以下のIntegration

Serviceプロパティを使用します。

¨ CPU%。CPU使用率には、システムで実行されている他の外部タスクの使用分が含まれま

す。

¨ メモリ使用量。メモリ使用率には、システムで実行されている他の外部タスクの使用分

が含まれます。メモリ使用量が95%に近づいた場合、システム上で実行されているタス

クがWorkflow Monitorで指示された量を使用しているかどうか、またメモリリークが存

在するかどうかを確認してください。トラブルシューティングするには、システムツー

ルを使ってセッション実行前後のメモリ使用量を調べ、その結果をセッションを実行中

のメモリ使用量と比較します。

¨ スワップの使用。スワップ使用状況は、メモリリークの可能性または同時実行されるタ

スク数の過多によって発生したページングの実績です。

Windowsにおけるシステムのボトルネックの特定

システムの情報は、タスクマネージャの[パフォーマンス]タブおよび[プロセス]タブで表

示できます。タスクマネージャの［パフォーマンス］タブには、CPUの使用率とメモリの総

使用量が表示されています。パフォーマンスモニタを使用すると、より詳細な情報が表示

されます。

Windowsのパフォーマンスモニタを使用して、以下の情報を示すためのチャートを作成しま

す。

¨ パーセントごとのプロセッサ時間。複数のCPUがある場合は、各CPUのパーセントごとの

プロセッサ時間を監視します。

¨ ページ/秒。ページ/秒が5を超えている場合は、メモリに過大な負担がかかっている

（スラッシング）可能性があります。

¨ 物理ディスクパーセント時間。読み込みまたは書き込みの要求を実行するときに、物理

ディスクがビジーになるパーセント時間を示します。

¨ 物理ディスクキュー長。同一のディスクデバイスへのアクセスを待っているユーザーの

数。

¨ 秒あたりのサーバー処理バイト合計。サーバーとネットワークの間で送信および受信し

たバイト数。

UNIXにおけるシステムのボトルネックの特定

以下のツールを使用して、UNIXでシステムのボトルネックを特定します。

¨ top。システム全体のパフォーマンスを表示します。このツールでは、システム、およ

びシステム上で実行されている個々のプロセスに関するCPU使用率、メモリ使用量およ

びスワップ使用状況が表示されます。

¨ iostat。データベースサーバに取り付けられているすべてのディスクに対するロード操

作を監視します。 iostatには、ディスクが物理的にアクティブになっている時間の割

合が表示されます。ディスクアレイを使用する場合は、iostatは使用しないで、ディス

クアレイに同梱されているユーティリティを使用します。

¨ vmstat。ディスクのスワップ動作を監視します。セッション中にスワップが発生する

ことはありません。


¨ sar。 CPU使用率、メモリ使用量、およびディスク使用状況に関する詳細システムアク

ティビティレポートを表示します。このツールは、CPUのロード監視に使用できます。

ユーザ、システム、アイドル時間および待ち時間の使用率を知ることができます。この

ツールは、ディスクのスワップ動作の監視にも使用できます。

システムのボトルネックの除去

システムのボトルネックを除去するには、以下のタスクを実行します。

¨ CPU使用率が80%を超過した場合は、同時実行タスクの数をチェックしてください。負荷

を変更するかまたはグリッドを使って複数ノードにタスクを分散させることを検討する

必要があります。負荷が低下しない場合は、プロセッサの追加を検討します。

¨ スワップが発生する場合は、物理メモリを増設するか、またはディスク上のメモリ集約

型アプリケーションの数を減らします。

¨ メモリが極端に圧迫される場合は（スラッシング）、物理メモリの追加を検討します。

¨ パーセント時間が高い場合は、PowerCenterのキャッシュをチューニングして、ディス

クに書き込む代わりにインメモリキャッシュを使用するようにします。キャッシュをチ

ューニングしても、リクエストがまだキューにあり、ディスクのビジーの割合が低で

も50%ある場合は、ディスクデバイスを追加するか、速いディスクデバイスにアップグ

レードしてください。このほか、セッションの各パーティションで異なるディスクを使

用することもできます。

¨ 物理ディスクキュー長が2を超える場合は、別のディスクデバイスの追加、または現在

のディスクデバイスのアップグレードを検討する必要があります。このほか、reader、

writer、およびトランスフォーメーションスレッドでも異なるディスクを使用すること

ができます。

¨ ネットワーク帯域幅の改善を検討します。

¨ UNIXシステムをチューニングする場合は、主要なデータベースシステムのサーバもチュ

ーニングします。

¨ I/O（%wio）で待機している時間のパーセンテージが高い場合、使用率の低い他のディ

スクの使用を検討する必要があります。たとえば、ソースデータ、ターゲットデータ、

ルックアップ、ランク、および集計キャッシュファイルのすべてが1つのディスクに格

納されている場合、これらの一部を別のディスクに移すことを検討する必要がありま

す。

関連項目：

¨ 「ページングの削減」 (58ページの)

¨ 「システムの適化」 (56ページの)

システムのボトルネック 11

第 3 章

ターゲットの適化


¨ フラットファイルターゲットの適化, 12 ページ

¨ インデックスおよびキー制約の削除, 12 ページ

¨ データベースのチェックポイント間隔を長く設定, 13 ページ

¨ バルクロードの使用, 13 ページ

¨ 外部ローダーの使用, 14 ページ

¨ デッドロックの小化, 14 ページ

¨ データベースのネットワークパケットサイズの拡張, 15 ページ

¨ Oracleターゲットデータベースの適化, 15 ページ

フラットファイルターゲットの適化フラットファイルターゲット用に共有ストレージディレクトリを使用する場合、他のタス

クを実行せず、ファイルの保存および管理を専用に行うマシンに共有ストレージディレク

トリを作成することで、セッションのパフォーマンスを適化できます。

Integration Serviceが単一ノード上で実行されているとき、セッションがフラットファイ

ルターゲットに書き込みを行う場合は、Integration Serviceプロセスノードに対してロー

カルなフラットファイルターゲットに書き込むと、セッションのパフォーマンスを適化

できます。

インデックスおよびキー制約の削除ターゲットテーブルにキー制約またはインデックスを定義している場合は、これらのテー

ブルへのデータのロードが遅くなります。パフォーマンスを改善するには、インデックス

およびキー制約を削除してからセッションを実行します。インデックスおよびキー制約

は、セッションの完了後に再構築することができます。

12

インデックスおよびキー制約を定期的に削除して再構築する場合は、次の方法によりセッ

ションを実行するたびにその処理を行うことができます。

¨ ロード前/後のストアドプロシージャを使用します。

¨ セッション実行前/実行後のSQLコマンドを使用します。

注: パフォーマンスを適化するには、必要に応じて、制約に基づくロードを実行しま

す。

データベースのチェックポイント間隔を長く設定

Integration Serviceがデータベースでのチェックポイント実行を待つたびに、パフォーマ

ンスが低下します。チェックポイント数を減らしてパフォーマンスを向上させるには、デ

ータベースのチェックポイント間隔を大きくします。

注: チェックポイント数を減らすとパフォーマンスは向上しますが、データベースが予期

せずシャットダウンした場合のリカバリ時間も長くなります。

バルクロードの使用一括ロードの使用により、DB2、Sybase ASE、Oracle、またはMicrosoft SQL Serverのデ

ータベースに大量データを挿入するセッションのパフォーマンスを向上させることができ

ます。一括ロードはセッションのプロパティで設定できます。

一括ロードを行う場合は、Integration Serviceはデータベースログを無視するため、パフ

ォーマンスが向上します。ただし、データベースログへの書き込みが行われないので、タ

ーゲットデータベースではロールバックを実行できません。その結果、リカバリを実行で

きない場合があります。一括ロードを実行する場合は、セッションのパフォーマンスを向

上させる機能と、不完全なセッションをリカバリする機能のどちらを重視するかを検討す

る必要があります。

Microsoft SQL ServerやOracleのターゲットに一括ロードを行う場合には、パフォーマン

スを向上させるためにコミット間隔を大きく定義します。Microsoft SQL ServerとOracle

ではコミットのたびに新しい一括ロードトランザクションが開始されます。コミット間隔

を大きくすることで、一括ロードの回数を減らしてパフォーマンスを向上できます。

データベースのチェックポイント間隔を長く設定 13

関連項目：

¨ 「ターゲットベースのコミット」 (42ページの)

外部ローダーの使用セッションのパフォーマンスを向上させるには、以下のタイプのターゲットデータベース

に外部ローダーを使用するようにPowerCenterを設定します。

¨ IBM DB2 EEまたはEEE

¨ Oracle

複数のパーティションを含むパイプラインを使用してOracleデータベースにデータをロ

ードする場合、そのセッションで使用するパーティションと同じ番号でOracleターゲッ

トテーブルを作成すると、パフォーマンスが向上します。

¨ Sybase IQ

UNIXシステム上のIntegration ServiceプロセスでSybase IQデータベースをローカル

に使用している場合は、名前付きのパイプからターゲットテーブルにデータを直接ロー

ドすると、パフォーマンスを向上させることができます。グリッドでIntegration

Serviceを実行する場合は、リソースをチェックしてSybase IQをリソースとし、そのリ

ソースをグリッドのすべてのノードから使用できるようにロードバランサを設定しま

す。次に、Workflow Managerで、Sybase IQリソースを適切なセッションに割り当てま

す。

¨ Teradata

デッドロックの小化ターゲットに書き込みを試行した際にIntegration Serviceでデッドロックが発生した場合

は、デッドロックは同じターゲット接続グループのターゲットにのみ影響します。

Integration Serviceは、他のターゲット接続グループのターゲットにも正常に書き込みを

行います。

デッドロックが発生すると、セッションのパフォーマンスが低下することがあります。セ

ッションのパフォーマンスを向上させるために、Integration Serviceではセッションでタ

ーゲットへの書き込みに使用するターゲット接続グループの数を増やすことができます。

セッションで各ターゲットに対して個別のターゲット接続グループを使用するには、各タ

ーゲットインスタンスに対して個別のデータベース接続名を使用します。各接続名に同じ

接続情報を指定できます。

14 章 3: ターゲットの適化

データベースのネットワークパケットサイズの拡張

Oracle、Sybase ASE、またはMicrosoft SQL Serverのターゲットに対して書き込みを行う

場合、ネットワークパケットのサイズを拡張してパフォーマンスを向上させることができ

ます。ネットワークパケットのサイズを拡張して、大きなデータパケットが一度にネット

ワークを流れるようにします。書き込み先のデータベースに基づいて、ネットワークパケ

ットのサイズを拡張します。

¨ Oracle。データベースサーバのネットワークパケットのサイズは、listener.oraと

tnsnames.oraで拡張できます。必要に応じて、パケットサイズの拡張の詳細につい

て、データベースのマニュアルを参照してください。

¨ Sybase ASEおよびMicrosoft SQL Server。パケットサイズの拡張方法の詳細について

は、データベースのマニュアルを参照してください。

Sybase ASEまたはMicrosoft SQL Serverについては、Workflow Managerでリレーショナル

接続オブジェクト内のパケットサイズを変更して、データベースサーバのパケットサイズ

に対応させることも必要です。

Oracleターゲットデータベースの適化ターゲットデータベースにOracleを使用している場合、ストレージ句、領域の割り当て、

およびロールバックまたは取り消しセグメントをチェックすることによって、ターゲット

データベースを適化できます。

Oracleデータベースへの書き込みを行うときに、データベースオブジェクトのストレージ

句をチェックします。テーブルで大きな初期値と増分値が使用されていることを確認しま

す。また、データベースでは、テーブルとインデックスデータを別々のテーブルスペース

（別々のディスクが望ましい）に格納する必要があります。

Oracleデータベースへの書き込みを行うとき、データベースではロード時にロールバック

または取り消しセグメントを使用します。Oracleのデータベース管理者に依頼して、デー

タベースによってロールバックまたは取り消しセグメントがそれぞれ適切なテーブルスペ

ース（別々のディスクが望ましい）に保存されていることを確認します。また、ロールバ

ックまたは取り消しセグメントには、適切なストレージ句が必要です。

Oracleデータベースを適化するには、OracleのREDOログをチューニングします。Oracle

データベースでは、REDOログを使用してロード処理を記録します。REDOログおよびバッフ

ァのサイズが適であることを確認してください。REDOログのプロパティは、init.oraフ

ァイルで見ることができます。

Integration Serviceが単一ノード上で実行されているときに、Oracleインスタンスが

Integration Serviceプロセスノードに対してローカルである場合は、IPCプロトコルを使

用してOracleデータベースに接続すると、パフォーマンスを適化できます。 Oracleデー

タベースへの接続は、listener.oraおよびtnsnames.oraで設定できます。

Oracleデータベースの適化の詳細については、Oracleのマニュアルを参照してくださ

い。

データベースのネットワークパケットサイズの拡張 15

第 4 章

ソースの適化


¨ クエリの適化, 16 ページ

¨ 条件フィルタの使用, 17 ページ

¨ データベースのネットワークパケットサイズの拡張, 17 ページ

¨ Oracleデータベースソースへの接続, 18 ページ

¨ Teradata FastExportの使用, 18 ページ

¨ SybaseまたはMicrosoft SQL Serverのテーブルを結合するためのtempdbの使

用, 18 ページ

クエリの適化セッションで1つのSource Qualifier内にある複数のソーステーブルを結合する場合、適

化のヒントを利用してクエリーを適化することによって、パフォーマンスを向上できる

ことがあります。また、ORDER BY句またはGROUP BY句を使用した単独テーブル選択文に対

しては、インデックスの追加などの適化が役立ちます。

通常、データベースオプティマイザでは、ソースデータを処理する際のも効率的な方法

を判定します。ただし、ユーザはデータベースのオプティマイザが認識できないソーステ

ーブルの属性を知っている場合があります。データベース管理者は、ソーステーブルの特

定のセットに対するクエリーの実行方法をデータベースに指示するためのオプティマイザ

ヒントを作成できます。

データを読み込むためにIntegration Serviceが使用するクエリは、セッションログに記録

されます。 Source Qualifierトランスフォーメーションでも、クエリーを見ることができ

ます。データベース管理者にクエリーの分析を依頼し、オプティマイザヒントやソーステ

ーブルのインデックスを作成します。

クエリーの実行を開始するとき、およびPowerCenterでデータの初のレコードを受け取る

ときに大きな遅れが発生する場合は、適化のヒントを使用します。オプティマイザヒン

トが、すべてのレコードを一度に返すのではなく、できるだけ早くレコードを返すように

設定します。これにより、Integration Serviceは、クエリの実行と並行してレコードを処

理できるようになります。

16

ORDER BYカラムまたはGROUP BYカラムにインデックスを作成することにより、ORDER BY句

またはGROUP BY句を含むクエリの効率が向上します。クエリーを適化したら、SQLオーバ

ーライドオプションを使用して、適化の際の修正が大限に活用されるようにします。

また、ソースデータベースで並行クエリーを実行できるように設定して、パフォーマンス

を向上させることもできます。平行クエリーの設定の詳細については、データベースのマ

ニュアルを参照してください。

条件フィルタの使用インデックスが設定されていないことが原因で、ソースデータベース上の簡単なソースフ

ィルタが、パフォーマンスに悪影響を及ぼすことがあります。Source Qualifierで、

PowerCenterの条件フィルタを使用すると、パフォーマンスを向上させることができます。

PowerCenterの条件フィルタを使用してパフォーマンスを向上できるかどうかは、セッショ

ンによって異なります。たとえば、複数のセッションで同一のソースから同時に読み込み

を行う場合、PowerCenterの条件フィルタでパフォーマンスを向上できることがあります。

ただし、ソースデータベース上のソースデータにフィルタをかける方が、実行速度が速く

なるセッションもあります。データベースフィルタおよびPowerCenterフィルタの両方でセ

ッションをテストして、どの方法でパフォーマンスを向上させるべきかを判定できます。

データベースのネットワークパケットサイズの拡張

Oracle、Sybase ASE、またはMicrosoft SQL Serverのソースから読み込む場合、ネットワ

ークパケットのサイズを拡張してパフォーマンスを向上させることができます。ネットワ

ークパケットのサイズを拡張して、大きなデータパケットが一度にネットワークを流れる

ようにします。読み込み対象となる以下のデータベースの種類に応じて、ネットワークパ

ケットのサイズを拡張します。

¨ Oracle。データベースサーバのネットワークパケットのサイズは、listener.oraと

tnsnames.oraで拡張できます。必要に応じて、パケットサイズの拡張の詳細につい

て、データベースのマニュアルを参照してください。

¨ Sybase ASEおよびMicrosoft SQL Server。パケットサイズの拡張方法の詳細について

は、データベースのマニュアルを参照してください。

Sybase ASEまたはMicrosoft SQL Serverについては、Workflow Managerでリレーショナル

接続オブジェクト内のパケットサイズを変更して、データベースサーバのパケットサイズ

に対応させることも必要です。

条件フィルタの使用 17

Oracleデータベースソースへの接続Integration Serviceが単一ノード上で実行されているときに、Oracleインスタンスが

Integration Serviceプロセスノードに対してローカルである場合は、IPCプロトコルを使

用してOracleデータベースに接続することによって、パフォーマンスを適化できます。

Oracleデータベースへの接続は、listener.oraおよびtnsnames.oraで設定できます。

Teradata FastExportの使用FastExportは複数のTeradataセッションを使用して、Teradataデータベースから大容量の

データを素早くエクスポートするツールです。FastExportを使用してTeradataソースをす

ばやく読み込むPowerCenterセッションを作成できます。FastExportを使用するには、

Teradataソースデータベースとのマッピングを作成します。そのセッション中は、

Relational readerに代わってFastExport readerを使用します。セッションにエクスポー

トしたいTeradataテーブルでFastExport接続を使用します。

SybaseまたはMicrosoft SQL Serverのテーブルを結合するためのtempdbの使用

SybaseまたはMicrosoft SQL Serverのデータベースで大きいテーブルを結合すると、メモ

リを効率的に割り当てるためのインメモリデータベースとしてtempdbを作成することでパ

フォーマンスが向上する可能性があります。詳細については、SybaseまたはMicrosoft SQL

Serverのマニュアルを参照してください。

18 章 4: ソースの適化

第 5 章

マッピングの適化


¨ マッピングの適化の概要, 19 ページ

¨ フラットファイルソースの適化, 19 ページ

¨ Single-Pass読み込みの設定, 20 ページ

¨ パススルーマッピングの適化, 21 ページ

¨ フィルタの適化, 21 ページ

¨ データタイプ変換の適化, 22 ページ

¨ 式の適化, 22 ページ

¨ External Procedureの適化, 25 ページ

マッピングの適化の概要マッピングレベルの適化はその実装に時間がかかりますが、セッションのパフォーマン

スを大幅に向上させることができます。マッピングレベルの適化は、ターゲットおよび

ソースの適化が完了した後にのみ実施できます。

通常、マッピングの適化では、マッピング内のトランスフォーメーションの数を減ら

し、トランスフォーメーション間の不要なリンクを削除します。大限の処理を行うに

は、トランスフォーメーションと式をできるだけ少なくしてマッピングを設定します。ト

ランスフォーメーション間の不要なリンクを削除して、移動するデータの量を小限に抑

えます。

フラットファイルソースの適化フラットファイルソースを適化するには、次のタスクを実行します。

¨ 連続行のバッファ長を適化します。

¨ 区切りフラットファイルソースを適化します。

¨ XMLおよびフラットファイルソースの適化

19

連続行のバッファ長の適化

セッションでフラットファイルソースからの読み込みを行う場合は、Integration Service

で各行の読み込みバイト数を設定することにより、セッションのパフォーマンスを向上さ

せることができます。デフォルトでは、Integration Serviceは1行につき1024バイトを

読み込みます。ソースファイル内の各行のバイト数がデフォルト設定の値より少ない場

合、セッションのプロパティで連続行のバッファ長の値を低くすることができます。

区切りフラットファイルソースの適化

ソースが区切りフラットファイルの場合、区切り文字を指定してソースファイルのデータ

のカラムを分ける必要があります。また、エスケープ文字も指定する必要があります。区

切り文字の前にエスケープ文字を入れると、Integration Serviceは区切り文字を通常の文

字として読み込みます。ソースファイルが引用符やエスケープ文字を含まないようにすれ

ば、セッションのパフォーマンスを向上できます。

XMLおよびフラットファイルソースの適化

XMLファイルにはタグ情報があるので、通常はフラットファイルよりもサイズが大きくなり

ます。XMLファイルの大きさは、XMLファイルのタグ付けのレベルによって異なります。タ

グの数が多いと、ファイルサイズは大きくなります。その結果、Integration Serviceでは

XMLソースを読み込みキャッシュするのに時間がかかることもあります。

Single-Pass読み込みの設定Single-Pass読み込みでは、1つのSource Qualifierを使用して複数のターゲットに値を入

れることができます。同じソースを使用する複数のセッションがある場合は、Single-Pass

読み込みの使用を検討します。各マッピングのトランスフォーメーションロジックを1つの

マッピングに結合し、各ソースで1つのSource Qualifierを使用することができます。

Integration Serviceは、各ソースを一度読み込んでからデータを異なるパイプラインに送

信します。状況に応じて、パイプラインの組み合わせや、パイプライン以外の組み合わせ

により、すべてのパイプラインで特定の行を使用することもできます。

たとえば、Purchasingソーステーブルがあり、そのソースを毎日使用して集計およびラン

ク付けを行うとします。AggregatorランスフォーメーションとRankトランスフォーメーシ

ョンを別個のマッピングおよびセッションに分けた場合、Integration Serviceに同じソー

ステーブルを2回読み込ませることになります。ただし、1つのSource Qualifierを有する

1つのマッピングに集計およびランキングロジックを含めると、Integration Serviceで

は、一度Purchasingソーステーブルを読み込んでから、異なるパイプラインに適切なデー

タを送信します。

Single-Pass読み込みを利用するようにマッピングを変更する場合は、マッピングに共通す

る処理を抽出することによって、この機能を適化します。たとえば、AggregatorとRank

の両方のトランスフォーメーションにおいてPriceポートからパーセンテージを減算する必

要がある場合は、パイプラインを分割する前にパーセンテージの減算処理を行うことによ

って処理を小限に抑えることができます。Expressionトランスフォーメーションを使用

20 章 5: マッピングの適化

してパーセンテージを減算してから、トランスフォーメーション実行後にマッピングを分

割します。

以下の図に、Expressionトランスフォーメーションの後にマッピングが分かれるSingle-

Pass読み込みを示します。

パススルーマッピングの適化パススルーマッピングのパフォーマンスを適化できます。データを、他のトランスフォ

ーメーションを使用せずに直接ソースからターゲットに渡す場合は、Source Qualifierト

ランスフォーメーションを直接ターゲットに接続します。基本操作ウィザードを使用して

パススルーマッピングを作成する場合は、このウィザードによって、Source Qualifierト

ランスフォーメーションとターゲットの間にExpressionトランスフォーメーションが作成

されます。

フィルタの適化データをフィルタするには、以下のトランスフォーメーションのいずれかを使用します。

¨ Source Qualifierトランスフォーメーション。Source Qualifierトランスフォーメー

ションによって、リレーショナルソースの行がフィルタリングされます。

¨ Filterトランスフォーメーション。Filterトランスフォーメーションはマッピング内の

データをフィルタリングします。 Filterトランスフォーメーションは、すべての種類

のソースからの行をフィルタリングします。

マッピングからのレコードにフィルタを適用する場合、データフローの早めの段階でフィ

ルタリングを行うことによって効率を上げることができます。Source Qualifierトランス

フォーメーションのフィルタを使用して、ソースから行を削除します。Source Qualifier

トランスフォーメーションは、リレーショナルソースから抽出した行セットを制限しま

す。

Source Qualifierトランスフォーメーションのフィルタを使用できない場合は、Filterト

ランスフォーメーションを使用して、できるだけSource Qualifierトランスフォーメーシ

ョンの近くまで移動してデータフローの初期段階で不必要なデータを削除します。Filter

トランスフォーメーションは、ターゲットに送信される行セットを制限します。

パススルーマッピングの適化 21

フィルタ条件では、複雑な式を使用しないようにします。Filterトランスフォーメーショ

ンを適化するには、フィルタ条件で簡単な整数式または真偽式を使用します。

注: 拒否された行を保持する必要がない場合、FilterまたはRouterトランスフォーメーシ

ョンを使用して、拒否された行をUpdate Strategyトランスフォーメーションから削除しま

す。

データタイプ変換の適化不要なデータ型変換を除去することにより、パフォーマンスが向上します。たとえば、

IntegerカラムからDecimalカラムへデータを移動した後に再びIntegerカラムにそのデータ

を戻すようなマッピングの場合、不必要なデータ型を変換することによってパフォーマン

スが低下します。可能な限り、不必要なデータ型の変換をマッピングから取り除きます。

システムのパフォーマンスを向上させるため、次のデータ型の変換を実行します。

¨ LookupトランスフォーメンションとFilterトランスフォーメーションを使用して比較を

実行する場合には、他のデータ型の代わりに整数値を使用する。たとえば、多くのデー

タベースでは、米国の郵便番号情報がCharデータ型またはVarcharデータ型として格納

されます。郵便番号のデータをIntegerデータ型に変換した場合、ルックアップデータ

ベースでは郵便番号の94303-1234を943031234という値で格納します。これで、郵便番

号に基づいたルックアップの比較条件の処理が高速化します。

¨ ポート間変換を通じて、ソースデータを文字列に変換して、セッションのパフォーマン

スを向上させる。ターゲット内のポートは文字列のままにしておくことも、Date/Time

ポートに変更することもできます。

式の適化トランスフォーメーションで使用する式を適化することもできます。可能な場合は、パ

フォーマンスを低下させている式を見つけて簡素化します。

パフォーマンスを低下させている式を見つけるため、次のタスクを実行します。

1. マッピングから1つずつ式を削除します。

2. マッピングを実行して、トランスフォーメーション抜きでマッピングを実行したとき

の時間を測定します。

セッションの実行時間が著しく異なる場合は、パフォーマンスを低下させている式を適

化する方法を探します。

共通ロジックの抽出

マッピングによって複数の箇所で同じ処理が実行される場合、その処理をマッピングの初

期段階に移すことによって、マッピングによる処理の実行回数を減らします。たとえば、

マッピングに5つのターゲットテーブルがある場合を検討しましょう。各ターゲットには、

社会保障番号のルックアップが必要です。この場合、ルックアップを5回実行する代わり


に、データフローが分かれる前のマッピングにLookupトランスフォーメーションを配置し

ます。次に、ルックアップの結果を5つのターゲットすべてに渡します。

集計関数呼び出しの小化

式を書き込む場合、集計関数の呼び出しをできる限り減らします。集計関数が呼び出され

るたびに、Integration Serviceではデータの検索とグループ化を行う必要が生じます。

たとえば、次の式では、Integration Serviceは初にCOLUMN_Aを読み込んでその合計を

求めます。次に、COLUMN_Bを読み込んでその合計を求め、後に2つの合計の和を求めま

す。

SUM(COLUMN_A) + SUM(COLUMN_B)

次の例のように集計関数の呼び出しを減らした場合、Integration ServiceはCOLUMN_Aを

COLUMN_Bに足した後でその合計を求めます。

SUM(COLUMN_A + COLUMN_B)

ローカル変数での共通の式の置き換え

1つのトランスフォーメーションにおいて同じ式が複数回使用されている場合は、その部分

式をローカル変数にすることができます。ローカル変数はトランスフォーメーション内で

のみ使用できます。ただし、変数の計算は一度で済むので、パフォーマンスを向上させる

ことができます。

文字列演算の代わりに数値演算を実行

Integration Serviceでは、数値演算の方が文字列演算よりも高速に処理されます。たと

えば、2つの列（EMPLOYEE_NAMEとEMPLOYEE_ID）で大量のデータを検索する場合、

EMPLOYEE_IDにルックアップを設定することでパフォーマンスが改善されます。

Char対CharおよびChar対Varcharの比較の適化

Integration ServiceがCHAR列とVARCHAR列の比較を行う場合、行の末尾に空白が検出され

るたびに処理速度が低下します。 Informatica AdministratorでIntegration Serviceを

設定する場合に、TreatCHARasCHARonReadオプションを使用すると、Integration Service

はChar型ソースフィールドの末尾の空白を削除しません。

LOOKUPの代わりにDECODEを選択

LOOKUP関数を使用すると、Integration Serviceではデータベース内のテーブルを検索す

る必要が生じます。 DECODE関数を使用するとルックアップ値が式自体に取り込まれ、

Integration Serviceが個々のテーブルを検索する必要がなくなります。したがって、検

索する値が変化せず、その数も少ない場合は、DECODEを使用するとパフォーマンスが向上

します。

式の適化 23

関数の代わりに演算子を使用

Integration Serviceでは、関数を使用して書かれた式よりも、演算子を使用して書かれた

式の方がより高速で読み込まれます。したがって、できるだけ演算子を使用して式を記述

してください。たとえば、CONCAT関数をネストした次のような式があるとします。

CONCAT( CONCAT( CUSTOMERS.FIRST_NAME, ‘ ’) CUSTOMERS.LAST_NAME)

||演算子を使用すると、上記の式を次のように表すことができます。

CUSTOMERS.FIRST_NAME || ‘ ’ || CUSTOMERS.LAST_NAME

IIF関数の適化

IIF関数では、値およびアクションを返すことができるため、式をより簡潔にできます。た

とえば、FLG_A、FLG_B、FLG_Cという3つのY/Nフラグを含むソースがあり、各フラグの値に

基づく値を返したいとします。

次の式を使用します。

IIF( FLG_A = 'Y' and FLG_B = 'Y' AND FLG_C = 'Y',

VAL_A + VAL_B + VAL_C,

IIF( FLG_A = 'Y' and FLG_B = 'Y' AND FLG_C = 'N',

VAL_A + VAL_B ,

IIF( FLG_A = 'Y' and FLG_B = 'N' AND FLG_C = 'Y',

VAL_A + VAL_C,

IIF( FLG_A = 'Y' and FLG_B = 'N' AND FLG_C = 'N',

VAL_A ,

IIF( FLG_A = 'N' and FLG_B = 'Y' AND FLG_C = 'Y',

VAL_B + VAL_C,

IIF( FLG_A = 'N' and FLG_B = 'Y' AND FLG_C = 'N',

VAL_B ,

IIF( FLG_A = 'N' and FLG_B = 'N' AND FLG_C = 'Y',

VAL_C,

IIF( FLG_A = 'N' and FLG_B = 'N' AND FLG_C = 'N',

0.0,

))))))))

この式では、8個のIIF、16個のAND、および少なくとも 24回の比較が必要です。

IIF関数を利用すると、上記の式を次のように表すことができます。

IIF(FLG_A='Y', VAL_A, 0.0)+ IIF(FLG_B='Y', VAL_B, 0.0)+ IIF(FLG_C='Y', VAL_C, 0.0)

この式で使用するIIFは3つ、比較は2つ、加算は2つとなり、その結果、セッションが高速

化されます。


式の評価

どの式がパフォーマンスを低下させているか不明な場合は、式のパフォーマンスを評価し

て問題を見つけ出します。

式のパフォーマンスを評価する次のステップを実行します。

1. 元の式を使用してセッションを計測します。

2. マッピングをコピーし、複雑な式の半分を定数に置き換えます。

3. 編集したセッションを実行して時間を計測します。

4. マッピングのコピーをもう1つ作成し、複雑な式の残りの半分を定数で置き換えます。

5. 編集したセッションを実行して時間を計測します。

External Procedureの適化External Procedureで入力グループからの読み込みを切り換える必要がある場合は、入力

データをブロックする必要があります。ブロック機能を使わない場合、入力データをバッ

ファリングする手続きコードを書く必要があります。通常はセッションのパフォーマンス

を低下させるバッファリングの代わりに、入力データをブロックすることができます。

たとえば、2つの入力グループでExternal procedureを作成するとします。このExternal

Procedureは、初の入力グループのデータを1行読み込んでから、2つ目の入力グループの

データを1行読み込みます。ブロックを使用すれば、一方の入力グループからのデータを処

理している間は他の入力グループからのデータフローをブロックするExternal Procedure

コードを書くことができます。データをブロックするExternal Procedureコードを書く

と、そのプロシージャではソースデータをバッファにコピーする必要がないため、パフォ

ーマンスが向上します。しかし、データを処理する準備ができるまで、バッファを割り当

てて入力グループからバッファにデータをコピーするExternal Procedureを書くこともで

きます。ソースデータのバッファへのコピーはパフォーマンスを低下させます。

External Procedureの適化 25

第 6 章

トランスフォーメーションの適化


¨ Aggregatorトランスフォーメーションの適化, 26 ページ

¨ Customトランスフォーメーションの適化, 28 ページ

¨ Joinerトランスフォーメーションの適化, 28 ページ

¨ Lookupトランスフォーメーションの適化, 29 ページ

¨ Sequence Generatorトランスフォーメーションの適化, 33 ページ

¨ Sorterトランスフォーメーションの適化, 33 ページ

¨ Source Qualifierトランスフォーメーションの適化, 34 ページ

¨ SQLトランスフォーメーションの適化, 34 ページ

¨ トランスフォーメーションエラーの除去, 35 ページ

Aggregatorトランスフォーメーションの適化

Aggregatorトランスフォーメーションではデータを処理する前にそれをグループ化しなけ

ればならないため、パフォーマンスが低下することがよくあります。Aggregatorトランス

フォーメーションは、中間のグループ結果を格納するための追加メモリを必要とします。

Aggregatorトランスフォーメーションのパフォーマンスを適化するには、以下のガイド

ラインに従います。

¨ 単純なカラム別にグループ化する。

¨ ソート済み入力を使用する。

¨ 差分集計を使用する。

¨ 集計する前にデータをフィルタリングする。

¨ ポート接続数を制限する。

26

単純なカラム別のグループ化

単純なカラム別のグループ化を行う際は、Aggregatorトランスフォーメーションを適化

することができます。可能な場合には、GROUP BYで使用するカラムでは、文字列や日付で

はなく数値を使用します。アグリゲータの式が複雑にならないようにします。

ソート済み入力の使用

セッションのパフォーマンスを向上させるには、Aggregatorトランスフォーメーションの

データをソートします。データのソートには、Sorted Inputオプションを使用します。

Sorted Inputオプションは、集計キャッシュの使用頻度を低くします。Sorted Inputオプ

ションを使用すると、Integration Serviceはすべてのデータがグループ別にソートされて

いるものと想定します。 Integration Serviceは1つのグループに対する行を読み込むとき

に、読み込みながら集計計算を実行します。必要に応じて、メモリにグループ情報を格納

します。

Sorted Inputオプションは、キャッシュに格納されるデータ量をセッション中に減らし

て、パフォーマンスを向上させます。このオプションをSource QualifierのNumber of

Sorted PortsオプションまたはSorterトランスフォーメーションと組み合わせて使用する

と、ソート済みデータをAggregatorトランスフォーメーションに渡すことができます。

複数のパーティションが含まれるセッションでSorted Inputオプションを使用すると、パ

フォーマンスが向上します。

差分集計の使用

ターゲットの半分未満のみに影響するソースから変更内容を取得できれば、差分集計を使

用してAggregatorトランスフォーメーションのパフォーマンスを適化できます。

差分集計を使用すると、取得したソースの変更がセッションで集計計算に適用されます。

Integration Serviceでは、ソース全体を処理しないでターゲットの差分のみを更新し、セ

ッションを実行するたびに同じ計算を再計算します。

ディスクにページングせずにすべてのデータをメモリ内に格納できるように、インデック

スキャッシュサイズおよびデータキャッシュサイズを増やすことができます。

関連項目：

¨ 「キャッシュサイズの拡張」 (41ページの)

集計前のデータのフィルタリング

集計する前にデータをフィルタリングします。マッピングでFilterトランスフォーメーシ

ョンを使用する場合、そのあとにAggregatorトランスフォーメーションを置いて、不要な

集計を減らしてください。

ポート接続の制限

接続される入出力ポートまたは出力ポートの数を制限することにより、Aggregatorトラン

スフォーメーションがデータキャッシュに格納するデータ量を減らします。

Aggregatorトランスフォーメーションの適化 27

Customトランスフォーメーションの適化Integration ServiceではCustomトランスフォーメーションプロシージャに対して1行ずつ

渡したり、配列内の行をブロック単位で渡したりすることができます。手続きコードを作

成して、手続きが1行ずつ受け取るか、ブロック単位で受け取るかを指定できます。

ブロック単位で手続きが行を受け取ると、パフォーマンスが向上します。

¨ Integration Serviceやプロシージャが行う関数呼び出しの数を減らすことができま

す。Integration Serviceによる入力行通知関数の呼び出し回数が減り、プロシージャ

による出力通知関数の呼び出し回数が減ります。

¨ データに対するメモリアクセススペースの局所性を高めることができます。

¨ 手続きコードを作成し、データの各行ではなく、ブロック単位にアルゴリズムを実行す

るようにできます。

Joinerトランスフォーメーションの適化Joinerトランスフォーメーションでは、中間結果を格納するための追加領域を実行時に必

要とするため、パフォーマンスが低下することがあります。Joinerトランスフォーメーシ

ョンを適化する必要があるかどうかを判断するには、Joinerパフォーマンスカウンタの

情報を表示します。

次のヒントを使用して、Joinerトランスフォーメーションによるセッションのパフォーマ

ンスを向上できます。

¨ 重複キー値が少ない方のソースをマスターとして指定する。Integration Serviceは、

ソート済みJoinerトランスフォーメーションを処理するときに、一度に100個の一意の

キーについての行をキャッシュに格納します。マスターソースに同じキー値を持つ多

数の行が含まれる場合、Integration Serviceはより多くの行をキャッシュに格納する

必要があるため、パフォーマンスが低下することがあります。

¨ 行が少ない方のソースをマスターとして指定する。セッションの間、Joinerトランスフ

ォーメーションは明細ソースの各行をマスターソースと比較します。マスター内の行

が少なければ、結合のための比較が繰り返される回数も少なくなり、その結果、結合プ

ロセスが高速になります。

¨ 可能な場合は、データベース内で結合を実行する。データベース内で結合を実行する

と、セッション内で結合を実行するよりも高速で行えます。パフォーマンスは、使用

するデータベース結合の種類によっても変わってきます。ノーマルジョインは、アウタ

ージョインよりも高速で、結果的にレコード数が少なくて済みます。場合によって、た

とえば2つの異なるデータベースまたはフラットファイルシステムとテーブルを結合す

る場合は、これが不可能なこともあります。

データベース内で結合を実行したい場合は、次のオプションを使用します。

-セッション実行前に起動されるストアドプロシージャを作成して、データベース内で

テーブルを結合する。

- Source Qualifierトランスフォーメーションを使用して結合を実行する。

28 章 6: トランスフォーメーションの適化

¨ 可能な場合は、ソート済みデータを結合する。セッションのパフォーマンスを改善する

には、ソート済みの入力を使用するようにJoinerトランスフォーメーションを設定しま

す。 Joinerトランスフォーメーションでソート済みデータを使うように設定すると、

Integration Serviceはディスクの入出力を小化してパフォーマンスを高めます。大

量のデータセットを扱う場合に、パフォーマンスを大限に向上させることができま

す。未ソートJoinerトランスフォーメーションの場合、行の比較的少ないソースをマス

ターソースとして指定します。

Lookupトランスフォーメーションの適化Lookupテーブルがマッピングにおいてソーステーブルと同じデータベースにあり、キャッ

シュが使用できない場合は、Lookupトランスフォーメーションを使用する代わりに、ソー

スデータベース内でテーブル同士を結合します。

Lookupトランスフォーメーションを使用する場合、次のタスクを実行してパフォーマンス

を向上させることができます。

¨ 適なデータベースドライバを使用する。

¨ Lookupテーブルをキャッシュする。

¨ Lookup条件を適化する。

¨ Lookupの行をフィルタする。

¨ Lookupテーブルをインデックスに入れる。

¨ 複数のLookupを適化する。

¨ パイプラインLookupトランスフォーメーションを作成して、ルックアップソースを作成

するパイプラインでパーティションを設定する。

適なデータベースドライバの使用

Integration Serviceは、ネイティブデータベースドライバまたはODBCドライバを使用して

Lookupテーブルに接続することができます。ネイティブデータベースドライバは、ODBCド

ライバよりも高いパフォーマンスを得ることができます。

ルックアップテーブルのキャッシュ

マッピングにLookupトランスフォーメーションが含まれている場合は、ルックアップキャ

ッシングを有効にします。キャッシングを有効にしている場合、Integration Serviceはル

ックアップテーブルをキャッシュに格納して、セッション中にルックアップキャッシュを

参照します。このオプションを有効にしていない場合、Integration Serviceは行ごとに

ルックアップテーブルを参照します。

Lookupテーブルをキャッシュに格納するかどうかに関わらず、Lookupクエリーの結果およ

び処理は同じです。ただし、ルックアップキャッシュを使用するとセッションのパフォー

マンスを向上させることができます。通常、必要なサイズが300 MB未満のLookupテーブル

は、キャッシュに入れます。

Lookupトランスフォーメーションの適化 29

Lookupトランスフォーメーションのパフォーマンスをさらに改善するには、以下のタスク

を実行します。

¨ 適切なキャッシュタイプを使用する。

¨ コンカレントキャッシュを有効にする。

¨ Lookup条件の一致を適化する。

¨ キャッシュに入れるレコード数を減らす。

¨ ORDER BY文を上書きする。

¨ メモリの多いマシンを使用する。

関連項目：

¨ 「キャッシュ」 (40ページの)

キャッシュのタイプ

次のキャッシュのタイプを使用して、パフォーマンスを向上させることができます。

¨ 共有キャッシュ。複数のトランスフォーメーション間でルックアップキャッシュを共有

できます。名前なしキャッシュを同じマッピング内のトランスフォーメーション間で

共有することができます。名前付きキャッシュを同じマッピング内、または異なるマッ

ピング内のトランスフォーメーション間で共有することができます。

¨ 永続キャッシュ。キャッシュファイルを保存して再使用するには、永続キャッシュを使

用できるようにトランスフォーメーションを設定します。この機能は、セッションの

実行間でルックアップテーブルが変更されていないことが明らかな場合に使用します。

Integration Serviceはメモリキャッシュをデータベースではなくキャッシュファイル

から作成するので、永続キャッシュを使用するとパフォーマンスが向上します。

コンカレントキャッシュの有効化

Lookupトランスフォーメーションを含むIntegration Serviceがセッションを処理する場

合、Integration Serviceはキャッシュを使用するLookupトランスフォーメーションでデ

ータの初の行を処理するときに、メモリにキャッシュを構築します。マッピングに複数

のLookupトランスフォーメーションがある場合、Lookupトランスフォーメーションによっ

てデータの初の行が処理されると、Integration Serviceは順番にキャッシュを作成しま

す。これにより、Lookupトランスフォーメーションの処理は遅くなります。

コンカレントキャッシュを有効にすると、パフォーマンスを向上させることができます。

並行処理する追加パイプライン数が1つまたは複数に設定されると、Integration Service

は順番にではなく同時にキャッシュを作成します。Aggregator、Joiner、またはSorterト

ランスフォーメーションなど、処理するのに時間のかかるアクティブなトランスフォーメ

ーションがセッションに多数存在していると、パフォーマンスを大限に向上させること

ができます。複数のコンカレントパイプラインを有効にすると、Integration Serviceはキ

ャッシュを構築するまでアクティブセッションを待たなくなります。パイプライン内の他

のLookupトランスフォーメーションも、同時にキャッシュを作成します。

ルックアップ条件の一致の適化

LookupトランスフォーメーションでルックアップキャッシュデータとLookup条件が一致す

ると、初に一致した値と後に一致した値を判断するため、データをソートし並べ替え


ます。Lookup条件に一致する値を何か返すように、トランスフォーメーションを設定でき

ます。Lookupトランスフォーメーションが一致する値を何か返すよう設定すると、トラン

スフォーメーションはLookup条件に一致する初の値を返します。一致する初の値を返

すか、または後の値を返すようにトランスフィーメーションを設定すると、通常どおり

にすべてのポートをインデックスに入れません。一致する値を使用すると、パフォーマン

ス低下の原因でもある、トランスフォーメーションによるすべてのポートのインデックス

を行わないため、パフォーマンスを改善することができます。

キャッシュされる行数の削減

キャッシュに入れるレコード数を減らして、パフォーマンスを向上させることができま

す。Lookup SQLオーバーライドオプションを使用すると、デフォルトのSQL文にWHERE句を

追加できます。

ORDER BY文の上書き

デフォルトでは、Integration ServiceはキャッシュされたLookupに対してORDER BY文を

生成します。ORDER BY文にはすべてのLookupポートが含まれます。パフォーマンスを向上

させるには、デフォルトのORDER BY文を使用しないで、カラム数の少ないORDER BYを上書

きで入力します。

上書きでORDER BY文を入力しても、Integration Serviceは常にORDER BY文を生成します。

ORDER BY上書きのあとに2個のダッシュ（--）を挿入して、生成したORDER BY文を抑止しま

す。

たとえば、Lookup トランスフォーメーションが次のLookup条件を使用するとします。

ITEM_ID = IN_ITEM_IDPRICE <= IN_PRICE

Lookupトランスフォーメーションには、マッピングで使用される3つのLookupポート

（ITEM_ID、ITEM_NAME、およびPRICE）が含まれます。ORDER BY文を入力した場合、

Lookup条件にポートを入力したのと同じ順番でカラムを入力します。また、すべてのデー

タベース予約語は引用符で囲みます。

Lookup SQLオーバーライドで次のLookupクエリーを入力します。

SELECT ITEMS_DIM.ITEM_NAME, ITEMS_DIM.PRICE, ITEMS_DIM.ITEM_ID FROM ITEMS_DIM ORDER BY ITEMS_DIM.ITEM_ID, ITEMS_DIM.PRICE --

メモリの多いマシンの使用

セッションのパフォーマンスを向上させるには、大容量のメモリを搭載したIntegration

Serviceノード上でセッションを実行します。マシンに負荷をかけない範囲で、インデッ

クスキャッシュサイズおよびデータキャッシュサイズをできる限り増やします。

Integration Serviceノードに十分なメモリがある場合は、ディスクにページングしなくて

もすべてのデータをメモリ内に保存できるよう、キャッシュを増やします。

ルックアップ条件の適化

複数のルックアップ条件を入れる場合は、ルックアップのパフォーマンスを適化するた

めに、次の順序で条件を指定します。

¨ 等しい（=）

Lookupトランスフォーメーションの適化 31

¨ より小さい (<)、より大きい(>)、より小さいまたは等しい (<=)、より大きいまたは等

しい (>=)

¨ 等しくない（!=）

Lookup行のフィルタリング

ルックアップキャッシュ作成時にソースから検索されるLookup行の数を減らすには、フィ

ルタ条件を作成します。

ルックアップテーブルのインデックス処理

Integration Serviceは、ルックアップ条件カラムの値に対してクエリ、ソート、および比

較を行う必要があります。インデックスには、Lookup条件で使用する各カラムを含めなけ

ればなりません。

次の種類のLookupにおいて、パフォーマンスを向上させることができます。

¨ キャッシュを使用したルックアップ。パフォーマンスを向上させるには、ルックアップ

ORDER BY文のカラムにインデックスを付けます。セッションログにはORDER BY文が含

まれます。

¨ キャッシュを使用しないルックアップ。パフォーマンスを向上させるには、ルックアッ

プ条件のカラムにインデックスを付けます。 Integration Serviceは、Lookupトラン

スフォーメーションに入る各行に対してSELECT文を発行します。

複数のルックアップの適化

マッピングに複数のルックアップが含まれている場合、キャッシングが有効になっていて

ヒープメモリが十分にあっても、ルックアップによりパフォーマンスが低下することがあ

ります。一番多くのデータを問い合わせるLookupトランスフォーメーションを探して、全

体のパフォーマンスを向上させることができます。

どのLookupトランスフォーメーションが多くのデータを処理するかを判断するには、それ

ぞれのLookupトランスフォーメーションのLookup_rowsinlookupcacheカウンタを調べま

す。このカウンタの値が大きいLookupトランスフォーメーションがあれば、そのLookup式

をチューニングすることにより効果を得られます。このような式を適化すると、セッシ

ョンのパフォーマンスが向上します。

関連項目：

¨ 「式の適化」 (22ページの)

パイプラインLookupトランスフォーメーションの作成

パイプラインLookupトランスフォーメーションが含まれるマッピングには、部分的なパイ

プラインが含まれます。このパイプラインには、ルックアップソースおよびSource

Qualifierがあります。Integration Serviceでは、このパイプラインでルックアップソー

スのデータが処理されます。 Lookupトランスフォーメーションが含まれるパイプラインに

ルックアップソースのデータが渡され、キャッシュが作成されます。


部分的なパイプラインは、セッションプロパティ内の個別のターゲットのロード順グルー

プです。このパイプラインに複数のパーティションを設定すると、パフォーマンスを改善

できます。

Sequence Generatorトランスフォーメーションの適化

Sequence Generatorトランスフォーメーションを適化するには、再利用可能なSequence

Generatorを作成して、複数のマッピング内で同時に使用します。また、キャッシュされる

値の数プロパティも設定します。

キャッシュされる値の数プロパティでは、Integration Serviceによって一度にキャッシュ

される値の数を指定します。 Number of Cached Valueの数値は、小さすぎる値にしない

でください。Number of Cached Valuesは、1,000より大きい値に設定する必要がありま

す。

キャッシュ値がない場合は、Number of Cache Valuesに0を設定します。キャッシュを使

用しないSequence Generatorトランスフォーメーションは、キャッシュを必要とするもの

よりも高速です。

関連項目：

¨ 「Sequence Generatorトランスフォーメーションの適化」 (51ページの)

Sorterトランスフォーメーションの適化次のタスクを実行して、Sorterトランスフォーメーションを適化します。

¨ データをソートするのに十分なメモリを割り当てる。

¨ Sorterトランスフォーメーション内にある各パーティションに異なるワークディレクト

リを指定する。

メモリの割り当て

適なパフォーマンスを実現するには、Integration Serviceノードで利用可能な物理RAM

量以下の値をSorterキャッシュサイズに設定します。 Sorterトランスフォーメーションを

使用してデータをソートするには、低16MBの物理メモリを割り当てます。デフォルトで

は、Sorterキャッシュサイズは16,777,216バイトに設定されます。 Integration Service

がデータをソートするのに十分なメモリを割り当てられない場合、セッションは失敗しま

す。

入力されるデータの量がSorterキャッシュサイズよりも大きい場合、Integration Service

はデータを一時的にSorterトランスフォーメーションのワークディレクトリに保存しま

す。Integration Serviceがデータをワークディレクトリに保存する場合、低でも入力さ

れるデータの量の2倍のディスク領域が必要です。入力されるデータの量がSorterキャッシ

Sequence Generatorトランスフォーメーションの適化 33

ュサイズよりはるかに大きい場合、Integration Serviceはワークディレクトリで利用可能

なディスク領域の2倍の量よりさらに多くの量を必要とする可能性があります。

下記の式で入力されるデータのサイズを求めます。

# input rows ([Sum(column size)] + 16)

パーティションのワークディレクトリ

Integration Serviceはデータをソートするとき、一時ファイルを作成します。一時ファイ

ルは、ワークディレクトリに保存されます。Integration Serviceノードの任意のディレク

トリをワークディレクトリとして使用できるように指定できます。デフォルトでは、

Integration Serviceは$PMTempDirサービスプロセス変数に指定されている値を使用しま

す。

Sorterトランスフォーメーションを使ってセッションをパーティション化する場合、パイ

プライン内のパーティションごとに異なるワークディレクトリを指定できます。セッショ

ンのパフォーマンスを向上させるためには、Integration Serviceのノード上の物理的に異

なるディスクでワークディレクトリを指定します。

Source Qualifierトランスフォーメーションの適化

Integration Serviceがソースから一意な値を選択するようにしたい場合は、Source

Qualifierトランスフォーメーションに対してSelect Distinctオプションを使用します。

Select Distinctオプションを使用して、データフローの初期段階で不必要なデータにフィ

ルタをかけます。これによってパフォーマンスが向上します。

SQLトランスフォーメーションの適化SQLトランスフォーメーションの作成時には、トランスフォーメーション内で定義した外部

SQLクエリーを使用するように、トランスフォーメーションを設定します。SQLトランスフ

ォーメーションをスクリプトモードで実行するように設定すると、Integration Serviceで

は、各入力行に対して外部SQLスクリプトを処理します。トランスフォーメーションをクエ

リーモードで実行すると、Integration Serviceでは、トランスフォーメーション内で定義

したSQLクエリーを処理します。

Integration Serviceは、セッション内で新しいクエリーを処理するたびに、SQLPrepare

という関数を呼び出し、SQLプロシージャを作成してデータベースに渡します。入力行ごと

にクエリーが変更されると、パフォーマンスに影響します。

トランスフォーメーションをクエリーモードで実行すると、トランスフォーメーションに

静的クエリーが作成され、パフォーマンスが改善されます。クエリー句内のデータが変更

されても、静的クエリーステートメントは変更されません。静的クエリーを作成するに

は、SQLエディタで文字列の置換の代わりにパラメータのバインドを使用します。パラメー


タのバインドの使用時は、クエリー句内のパラメータを、トランスフォーメーション入力

ポート内の値に設定します。

SQLクエリーにコミットおよびクエリーステートメントが含まれる場合、Integration

Serviceでは、コミットまたはロールバックするたびにSQLプロシージャを再作成する必要

があります。パフォーマンスを適化するためには、SQLトランスフォーメーションクエリ

ーでトランザクションステートメントを使用しないでください。

SQLトランスフォーメーションの作成時には、トランスフォーメーションをデータベースに

接続する方法を設定します。接続方法には、静的に接続する方法と、実行時に接続情報を

トランスフォーメーションに渡す方法があります。

静的接続を使用するようにトランスフォーメーションを設定する場合は、Workflow

Manager接続から接続を1つ選択します。SQLトランスフォーメーションは、セッション中に

一度だけデータベースに接続します。動的情報を渡すと、SQLトランスフォーメーション

は、入力行を処理するたびにデータベースに接続します。

トランスフォーメーションエラーの除去トランスフォーメーションエラーが多数発生すると、Integration Serviceのパフォーマン

スが低下します。それぞれのトランスフォーメーションエラーに対して、Integration

Serviceは、一時停止してそのエラーを調べ、エラーの原因となっている行をデータフロー

から削除します。次に、通常はIntegration Serviceのセッションログファイルにその行

が書き込まれます。

Integration Serviceで変換エラー、競合しているマッピングロジック、およびエラーとし

て設定されている条件（Null入力など）が検出されると、トランスフォーメーションエラ

ーが発生します。トランスフォーメーションエラーが発生した箇所を調べるには、セッシ

ョンログをチェックします。エラーが特定のトランスフォーメーションで発生している場

合は、そのトランスフォーメーション制約を評価してください。

大量のトランスフォーメーションエラーを発生させるセッションを実行する必要がある場

合は、トレースレベルを低く設定することによってパフォーマンスを向上させることがで

きます。ただし、この方法はトランスフォーメーションエラーに対する長期的な対策とし

てはお勧めできません。

関連項目：

¨ 「エラートレース」 (43ページの)

トランスフォーメーションエラーの除去 35

第 7 章

セッションの適化


¨ グリッド, 36 ページ

¨ プッシュダウンの適化, 37 ページ

¨ コンカレントセッションおよびワークフロー, 37 ページ

¨ バッファメモリ, 38 ページ

¨ キャッシュ, 40 ページ

¨ ターゲットベースのコミット, 42 ページ

¨ リアルタイム処理, 42 ページ

¨ ステージングエリア, 43 ページ

¨ ログファイル, 43 ページ

¨ エラートレース, 43 ページ

¨ セッション実行後のメール, 44 ページ

グリッドグリッドを使用することで、セッションやワークフローのパフォーマンスを向上させるこ

とができます。グリッドは、一連のノードに対して割り当てられたエイリアスのことで、

ノードに対するワークフローやセッションの割り当てを自動化することができます。

ロードバランサは、どのノードにも過負荷をかけることのないように、ノード間にタスク

を分散します。

グリッドを使用すると、Integration Serviceはワークフロータスクおよびセッションスレ

ッドを複数のノードに割り当てます。ロードバランサは、どのノードにも過負荷をかける

ことのないように、ノード間にタスクを分散します。グリッドのノード上で実行されてい

るワークフローおよびセッションは、次のようなパフォーマンス向上を実現します。

¨ Integration Serviceの負荷を平均化する。

¨ コンカレントセッションのプロセスが速くなる。

¨ パーティションのプロセスが速くなる。

36

Integration Serviceは、入力データの解析および出力データのフォーマット設定にCPUリ

ソースを必要とします。セッションの抽出/ロードステップにパフォーマンスボトルネック

がある場合は、グリッドによるパフォーマンス向上が可能です。

メモリまたは一時記憶域がパフォーマンスボトルネックとなっている場合は、グリッドに

よるパフォーマンス向上が可能です。キャッシュメモリを持つトランスフォーメーション

がPowerCenterマッピングに含まれている場合は、十分なキャッシュメモリおよび各キャッ

シュインスタンス用の別個のディスクストレージを配置することにより、パフォーマンス

を向上できます。

グリッド上でセッションを実行すると、グリッドにより提供されるセッション実行用リソ

ースが増えるため、スループットを向上できます。セッション数が少数の場合はグリッド

上で一括実行すれば、パフォーマンスが向上します。コンカレントセッションのパーティ

ション数がノード数を下回る場合、グリッド上でのセッション実行のほうが、グリッド上

でのワークフロー実行よりも効率的です。

グリッド上で複数のセッションを実行すると、セッションのサブタスクと他のコンカレン

トセッションのサブタスクとでノードリソースが共有されます。グリッド上でセッション

を実行するには、別のいくつかのノード上で実行されているプロセス間の協調が必要で

す。マッピングによっては、グリッド上でセッションを実行するには、あるノードから別

のノードへのデータ移動に追加のオーバーヘッドを必要とする場合があります。グリッド

上での複数セッション実行時には、各ノード上にメモリおよびCPUリソースがロードされる

だけでなく、ネットワークトラフィックが増大します。

グリッド上でのワークフロー実行時には、ノード間の協調を必要とすることなしに、ノー

ド上にメモリおよびCPUリソースがロードされます。

関連項目：

¨ 「グリッドのデプロイメントの適化」 (45ページの)

プッシュダウンの適化セッションのパフォーマンスを向上させるには、ソースデータベースまたはターゲットデ

ータベースにトランスフォーメーションロジックを転送します。マッピングおよびセッシ

ョンの設定に基づき、Integration Serviceはサービス内のトランスフォーメーションロジ

ックを処理する代わりに、ソースやターゲットデータベースに対してSQLを実行します。

コンカレントセッションおよびワークフロー可能な限り、パフォーマンスを向上させるためにセッションおよびワークフローを同時に

実行します。たとえば、次元テーブルやファクトテーブルがある分析スキーマにデータを

ロードすると、次元テーブルが同時にロードされます。

プッシュダウンの適化 37

バッファメモリIntegration Serviceでは、セッションを初期化するときに、ソースデータとターゲットデ

ータを保持するためのメモリブロックが割り当てられます。 Integration Serviceは、ソ

ースパーティションおよびターゲットパーティションごとに少なくとも2つのブロックを割

り当てます。多数のソースやターゲットを使用するセッションでは、追加のメモリブロッ

クが必要になる場合があります。Integration Serviceでソースデータ保持のための十分な

メモリブロックを割り当てることができない場合、セッションは失敗します。

バッファメモリの量を設定したり、ランタイムのバッファ設定を計算するように

Integration Serviceを設定したりすることができます。

空きメモリブロック数を増やすには、以下のセッションプロパティを調整します。

¨ DTMバッファサイズ。セッションプロパティの［プロパティ］タブにあるDTMバッファサ

イズを増やします。

¨ デフォルトのバッファブロックサイズ。セッションプロパティの［設定オブジェクト］

タブにあるバッファブロックサイズを減らします。

これらの値を設定する前に、Integration Serviceでセッションを初期化するために必要と

なるメモリブロック数を指定します。次に、デフォルト設定に基づいて、バッファサイズ

およびバッファブロックサイズを計算し、必要なセッションブロック数を割り出します。

マッピングにXMLのソースまたはターゲットを持つ場合には、そのXMLソースまたはXMLター

ゲットのグループ数を計算に使ってソースとターゲットの総数を求めてください。

たとえば、50個のソースと50個のターゲットを含むマッピングを使用した、1つのパーティ

ションを含むセッションを作成するとします。次に、以下の計算を行います。

1. まず、そのセッションに低200個のメモリブロックが必要になるものとします。

[(total number of sources + total number of targets)* 2] = (session buffer blocks)100 * 2 = 200

2. デフォルト設定に基づいて、［DTMバッファサイズ］を15,000,000に変更するか、また

は［デフォルトのバッファブロックサイズ］を 54,000に変更するかの、いずれかが可

能であることがわかります。

(session Buffer Blocks) = (.9) * (DTM Buffer Size) / (Default Buffer Block Size) * (number of partitions)200 = .9 * 14222222 / 64000 * 1

または

200 = .9 * 12000000 / 54000 * 1

注: n個のパーティションを含むセッションの場合、DTMバッファサイズは1つのパーティ

ションだけのセッションの値に対して少なくともn倍に設定します。Log Managerは、メモ

リブロックが小さすぎるために生じるパフォーマンスの低下があった場合、セッションロ

グに警告メッセージを書き込みます。Log Managerでは、セッションを実行するのに十分な

数のメモリブロックがある場合でも、警告メッセージを書き込みます。警告メッセージ

は、この他、正しい値も提案します。

DTMバッファサイズを変更する場合は、バッファブロックサイズの倍数でプロパティを増や

します。

38 章 7: セッションの適化

DTMバッファサイズの拡大

［DTMバッファサイズ］の設定では、Integration ServiceがDTMバッファメモリとして使

用するメモリの量を指定します。 Integration Serviceは、DTMバッファメモリを使用し

て、Integration Serviceのデータのやり取りに用いる内部データ構造およびバッファブロ

ックを作成します。 DTMバッファメモリを拡張すると、Integration Serviceで作成され

るバッファブロックが増大するため、一時的な速度低下時のパフォーマンスが向上しま

す。

DTMバッファメモリ割り当てを増やすと、一般的にパフォーマンスは初に上昇した後で安

定します。DTMバッファメモリ割り当てを増やす際には、Integration Serviceプロセスシ

ステム上で利用可能なメモリの総量を考慮します。

パフォーマンスが大きく向上しない場合は、DTMバッファメモリ割り当てがセッションのパ

フォーマンスに影響を及ぼしていないことが分かります。

注: DTMバッファ割り当てを減らすと、Integration Serviceが必要なプロセスにメモリ

を割り当ることができなくなるため、プロセスの初期段階でセッションの失敗を引き起こ

す可能性があります。

DTMバッファサイズを増やすには、セッションプロパティを開いて［プロパティ］タブをク

リックし、［パフォーマンス］設定のDTMバッファサイズのプロパティを編集します。

デフォルトのDTMバッファサイズは、12,000,000バイトです。バッファサイズを数倍ずつ数

回にわたって拡大し、この設定を大きくしながら、メモリサイズを拡大するたびにシステ

ムを稼動してセッションの時間を計測します。

バッファブロックサイズの適化

セッションのソースデータに応じて、バッファブロックサイズを増減させる必要がありま

す。

マシンが物理的なメモリを制限し、セッションのマッピングに多くのソース、ターゲッ

ト、パーティションがあるときには、バッファサイズを減らした方がよい場合もありま

す。

非常に大きなデータ行を操作する場合は、バッファブロックサイズを増やすとパフォーマ

ンスが向上します。おおよその行サイズがわからない場合は、以下の手順を実行して設定

されている行サイズを確認します。

必要なバッファサイズを評価するには：

1. Mapping Designerで、セッションのマッピングを開きます。

2. ターゲットインスタンスを開きます。

3. このトランスフォーメーションには以下のポートがあります。

4. ターゲット内の全カラムの精度を合計します。

5. マッピング内に複数のターゲットがある場合は、追加するターゲットごとに手順2～4

を繰り返して、各ターゲットの精度を計算します。

6. マッピング内の各ソース定義に対して、手順2～5を繰り返します。

7. ソースおよびターゲットの精度すべての中から大の精度を選択してバッファブロッ

クサイズの合計の精度を求めてください。

バッファメモリ 39

合計の精度は、データの大のレコード1つを移動するのに必要な合計のバイト数を表しま

す。たとえば、合計の精度が33,000である場合、Integration Serviceがその行を移動す

るには33,000バイトのバッファが必要になります。バッファブロックサイズが64,000バイ

トであれば、Integration Serviceは一度に1行しか移動できません。

バッファは、100行を一度に保持できることが理想的とされます。したがって合計の精度が

32,000よりも大きい場合は、バッファのサイズを増やしてパフォーマンスを向上させま

す。

バッファブロックサイズを増やすには、セッションプロパティを開いて［設定オブジェク

ト］タブをクリックし、［詳細設定］の［デフォルトのバッファブロックサイズ］プロパ

ティを編集します。

行の大きさに応じて、DTMバッファブロックの設定を増やします。DTMバッファメモリ割り

当てと同様、バッファブロックサイズを増やしてもパフォーマンスは向上します。パフォ

ーマンスが大きく向上しない場合は、バッファブロックサイズがセッションのパフォーマ

ンスに影響を及ぼしていないことが分かります。

キャッシュIntegration Serviceは、XMLターゲット、およびAggregator、Rank、Lookup、Joinerの各

トランスフォーメーションに対してインデックスとデータキャッシュを使用します。

Integration Serviceは、パイプラインに返す前に変換されたデータをデータキャッシュに

格納します。グループ情報はインデックスキャッシュに格納されます。また、

Integration Serviceはキャッシュを使用して、Sorterトランスフォーメーションのデー

タを格納します。

キャッシュメモリの量を設定するには、キャッシュカルキュレータを使用するか、または

キャッシュサイズを指定します。また、Integration Serviceを設定して、ランタイムにキ

ャッシュメモリ設定を計算するようにすることもできます。

割り当て済みキャッシュがデータの格納に十分な大きさでない場合、Integration Service

では一時ディスクファイル（キャッシュファイル）内にデータを格納することにより、セ

ッションデータの処理を可能にします。パフォーマンスは、Integration Serviceが一時フ

ァイルに対してページングを行うたびに低下します。パフォーマンスカウンタを検証し、

Integration Serviceがどのくらいの頻度でファイルに対してページングしているかを確認

します。

キャッシュを適化するには、次のタスクを実行します。

¨ 接続される入出力ポートまたは出力ポートを制限する。

¨ キャッシュディレクトリに適な場所を選択する。

¨ キャッシュサイズを増やす。

¨ 64ビットバージョンのPowerCenterを使用して、大きいキャッシュセッションを実行す

る。


接続されるポート数の制限

データキャッシュを使用するトランスフォーメーションでは、接続する入出力ポートや出

力ポートを制限します。入出力ポートや出力ポートの接続数を制限することで、トランス

フォーメーションがデータキャッシュに格納するデータ量を減らします。

キャッシュディレクトリの場所

グリッドでIntegration Serviceを実行し、一部のIntegration Serviceノードのみが共有

キャッシュファイルディレクトリに高速アクセスしている場合は、ディレクトリへのアク

セスが高速なノードで実行するように、大きいキャッシュを持つ各セッションを設定しま

す。ディレクトリへのアクセスが高速なノードで実行するようにセッションを設定するに

は、以下の手順を実行します。

1. PowerCenterリソースを作成します。

2. ディレクトリへのアクセスが高速なノードで、そのリソースを使用できるようにしま

す。

3. そのリソースをセッションに割り当てます。

グリッドのすべてのIntegration Serviceプロセスがキャッシュファイルに低速でアクセス

している場合は、Integration Serviceプロセスごとに別々のローカルキャッシュファイル

ディレクトリを設定します。キャッシュディレクトリを含むマシンと同一のマシンで

Integration Serviceプロセスを実行する場合は、キャッシュファイルへのアクセスが高速

になることもあります。

注: マップドライブまたはマウントドライブ上に大量のデータをキャッシュするときに、

パフォーマンスの低下に関する問題に遭遇する場合があります。

キャッシュサイズの拡張

キャッシュサイズを設定して、トランスフォーメーションを処理するために割り当てられ

るメモリ量を指定します。設定するメモリ容量は、使用するメモリキャッシュおよびディ

スクキャッシュのサイズによって異なります。設定したキャッシュサイズが、メモリでト

ランスフォーメーションを処理するのに十分な大きさではない場合は、Integration

Serviceではトランスフォーメーションの一部はメモリで実行され、残りのトランスフォー

メーションを処理するためにキャッシュファイルに情報がページングされます。パフォー

マンスは、Integration Serviceが一時ファイルに対してページングを行うたびに低下しま

す。

セッションのパフォーマンス詳細を調べて、Integration Serviceがキャッシュファイルに

いつページングしているかを特定します。Aggregator、Rank、またはJoinerトランスフォ

ーメーションのTransformation_readfromdiskカウンタまたは

Transformation_writetodiskカウンタには、トランスフォーメーションを処理するために

Integration Serviceがディスクに対して何回ページングするかが示されます。

セッション内にキャッシュを使用するトランスフォーメーションがあり、十分にメモリの

あるマシンでセッションを実行する場合は、キャッシュサイズを増やして、トランスフォ

ーメーションがメモリで処理されるようにします。

キャッシュ 41

64ビットバージョンのPowerCenterの使用

大量のデータを処理したり、メモリ集約型トランスフォーメーションを実行する場合、64

ビットのPowerCenterバージョンを使用してセッションのパフォーマンスを向上させること

ができます。64ビットバージョンには大型のメモリスペースがあり、ディスクの入出力を

劇的に削減または除去することができます。

これにより、以下の領域でのセッションパフォーマンスを改善できます。

¨ キャッシュ。64ビットプラットフォームにより、Integration Serviceは、32ビットプ

ラットフォームの2 GBキャッシュ制限による制約を受けません。

¨ データスループット。利用可能な大型のメモリスペースにより、readerやwriter、DTM

スレッドは大型のデータブロックを処理することができます。

ターゲットベースのコミットコミット間隔の設定は、Integration Serviceがターゲットにデータをコミットするポイン

トを指定するためのものです。 Integration Serviceがコミットするたびに、パフォーマ

ンスは低下します。したがって、コミット間隔が短いほどIntegration Serviceはターゲ

ットデータベースに頻繁に書き込みを行い、その結果、全体のパフォーマンスが低下しま

す。

コミット間隔を長く設定すると、Integration Serviceがコミットする回数が減り、パフォ

ーマンスが向上します。

コミット間隔を長くする場合は、ターゲットデータベースでのログファイルの制限を考慮

に入れてください。コミット間隔が長すぎる場合、Integration Serviceがデータベースロ

グファイルの大サイズまで書き込みを行って、その結果、セッションの失敗を引き起こ

す可能性があります。

そのため、コミット間隔を長くした場合の利点と、失敗したセッションのリカバリに要す

る時間とのどちらを重視するかを比較検討する必要があります。

セッションプロパティの［全般オプション］設定をクリックして、コミット間隔を確認

し、調整します。

リアルタイム処理

フラッシュ待ち時間

フラッシュ待ち時間は、Integration Serviceでソースからリアルタイムデータをフラッシ

ュする頻度を決定します。フラッシュ待ち時間の間隔を短く設定すると、Integration

Serviceがターゲットにメッセージをコミットする頻度が増えます。Integration Service

がターゲットにメッセージをコミットするたびに、セッションでリソースが消費されてス

ループットが低下します。


スループットを改善するには、フラッシュ待ち時間を長くします。ハードウェアおよび使

用可能なリソースに従って、特定のしきい値までフラッシュ待ち時間を大きくすると、ス

ループットが向上します。

ソースベースのコミット

ソースベースのコミット間隔は、Integration Serviceでターゲットにリアルタイムデータ

をコミットする頻度を決定します。待ち時間を短にするには、ソースベースのコミット

を1に設定します。

ステージングエリアステージング領域を使用すると、Integration Serviceはデータに対して複数のパスを実行

します。可能であれば、ステージングエリアを削除してパフォーマンスを向上させます。

Integration Serviceは1回のパスで複数のソースを読み出すことができるため、ステージ

ングエリアの必要性はそれほど大きくありません。

関連項目：

¨ 「Single-Pass読み込みの設定」 (20ページの)

ログファイルセッションログファイルおよびワークフローログファイルに書き込まないようにワークフ

ローを設定すると、ワークフローの実行が高速化されます。ワークフローおよびセッショ

ンでは、常にバイナリログが作成されます。ログファイルに書き込むようにセッションま

たはワークフローを設定すると、Integration Serviceによってロギングイベントが2回書

き込まれます。バイナリログセッションおよびワークフローログには、管理者ツールから

アクセスできます。

エラートレースパフォーマンスを改善するには、Integration Serviceがセッションを実行するときに生成

されるログイベントの数を削減します。セッション内に大量のトランスフォーメーション

エラーがあっても、修正する必要がない場合は、トレースレベルを［Terse］に設定しま

す。このトレースレベルの場合、Integration Serviceはエラーメッセージやリジェクトデ

ータの行レベル情報を書き込みません。

マッピングをデバッグする必要があり、トレースレベルを［Verbose］に設定すると、セッ

ションを実行した際にパフォーマンスの著しい低下を体験する可能性があります。パフォ

ーマンスのチューニングを行っているときは、［Verbose］を使用しないでください。

ステージングエリア 43

セッションのトレースレベルは、マッピング内のトランスフォーメーション固有のトレー

スレベルをオーバーライドします。ただし、この方法は多くのトランスフォーメーション

エラーが発生する場合の長期的な対策としてはお勧めできません。

セッション実行後のメールセッション後に発信される電子メールにセッションログを添付すると、フラットファイル

のロギングが有効になります。フラットファイルのロギングを有効にすると、Integration

Serviceはディスクからセッションログファイルを取得します。フラットファイルのロギン

グを有効にしない場合、Integration ServiceはLog Managerからログイベントを取得し、

電子メールに添付するセッションログファイルを生成します。Integration Serviceがログ

サービスからセッションログを取得する場合は、特にセッションログファイルが大きく、

マスターDTMとは異なるノードでログサービスが実行されているときに、ワークフローのパ

フォーマンスが低下します。高のパフォーマンスを実現するには、セッションログを添

付するためにセッション後のメールを設定するときに、セッションによるログファイルへ

の書き込みが行われるように設定します。


第 8 章

グリッドのデプロイメントの適化


¨ グリッドのデプロイメントの適化の概要, 45 ページ

¨ ファイルの格納, 45 ページ

¨ 共有ファイルシステムの使用, 47 ページ

¨ ファイルシステム全体へのファイルの分散, 49 ページ

¨ Sequence Generatorトランスフォーメーションの適化, 51 ページ

グリッドのデプロイメントの適化の概要グリッド上でPowerCenterを実行するとき、リソースを効率的に使用し、拡張性を大限ま

で活用するように、グリッド、セッション、ワークフローを設定できます。

グリッドのPowerCenterのパフォーマンスを改善するには、以下のタスクを実行します。

¨ グリッドへのノードの追加

¨ ストレージ容量および帯域幅の拡張

¨ 共有ファイルシステムの使用

¨ 次のタスク完了時に高スループットのネットワークを使用

-ネットワーク経由でのソースおよびターゲットへのアクセス

-［グリッド上のセッション］オプション使用時に、グリッドのノード間でデータを転

送

ファイルの格納PowerCenterをグリッドで実行するように設定する場合は、ソースファイル、ログファイル

およびキャッシュファイルなど、さまざまなタイプのセッションファイルの格納場所を指

45

定します。パフォーマンスを改善するには、適な場所にファイルを格納します。たとえ

ば、永続キャッシュファイルは、高帯域幅の共有ファイルシステムに格納します。ファイ

ルタイプが異なれば、格納要件も異なります。

ファイルを格納できる場所のタイプは、以下のとおりです。

¨ 共有ファイルシステム。すべてのIntegration Serviceプロセスが同じファイルにアク

セスできるように、ファイルを共有ファイルシステムに格納します。ファイルを低帯

域幅および高帯域幅共有ファイルシステムに格納できます。

¨ ローカル。ほかのIntegration Serviceプロセスからファイルへのアクセスが必要ない

ときは、そのファイルはIntegration Serviceプロセスを実行しているローカルマシン

に格納します。

高帯域幅共有ファイルシステムのファイル

以下のファイルはセッション中に頻繁にアクセスされることがあるため、高帯域幅共有フ

ァイルシステムに格納します。

¨ ソースファイル（ルックアップ用のフラットファイルを含む）。

¨ ターゲットファイル（パーティション化されたセッション用の統合ファイルを含む）。

¨ ルックアップまたは差分集計用の永続キャッシュファイル。

¨ グリッド上のグリッド対応セッション専用の非永続キャッシュファイル。

これにより、Integration Serviceはキャッシュを1回だけ構築できます。これらのキャ

ッシュファイルをローカルファイルシステムに格納すれば、Integration Serviceはパ

ーティショングループごとにキャッシュを構築します。

低帯域幅共有ファイルシステムのファイル

以下のファイルはセッション中にアクセスされる回数が少ないため、低帯域幅共有ファイ

ルシステムに格納します。

¨ パラメータファイルまたは他の設定関連のファイル。

¨ 間接ソースファイルまたは間接ターゲットファイル。

¨ ログファイル。

ローカルストレージファイル

共有ファイルシステム使用時に不要なファイル共有を避けるために、以下のファイルはロ

ーカルで格納します。

¨ グリッドに非対応なセッション用の非永続キャッシュファイル（Sorterトランスフォー

メーションの一時ファイルを含む）。

¨ パーティション化されたセッション用に順次統合を実行する場合の、さまざまなパーテ

ィション用の個別ターゲットファイル。

¨ セッション実行の後に削除されるその他の一時ファイル。通常、これを実現するに

は、ローカルファイルシステムに$PmTempFileDirを設定します。

帯域幅が高いときでも、これらのファイルを共有ファイルシステムに格納することは避け

ます。

46 章 8: グリッドのデプロイメントの適化

共有ファイルシステムの使用ファイル共有には、以下の共有ファイルシステムを使用できます。

¨ WindowsのCIFS（SMB）またはUNIXのNetwork File System（NFS）などのネットワーク

ファイルシステム。ネットワークファイルシステムは高パフォーマンスの計算向けで

はありませんが、シーケンシャルファイルアクセスにもうまく機能します。

¨ クラスタファイルシステム。クラスタファイルシステムでは、高帯域幅のファイルア

クセスを可能にするノードグループの他に、ファイルおよびディレクトリ用の統合され

た名前空間を提供します。クラスタファイルシステムのパフォーマンスは、直接接続

されたローカルファイルシステムに似ています。

注: 高可用性オプションがある場合には、クラスタファイルシステムを使用します。

適正な設定とチューニングがグリッドのわずかなパフォーマンスにとって重要となりま

す。また、マッピングとセッションの設定によって、共有ファイルシステムの本質的な限

界を回避できます。

共有ファイルシステムの設定

以下の一般ガイドラインに従って、共有ファイルシステムを設定します。

¨ ネットワークは十分な帯域幅を確保する。

¨ 内在するストレージが十分なI/O帯域幅を確保する。

¨ 共有ファイルシステムのデーモンを、特にクライアントを、ファイルアクセスを迅速に

するだけの十分なスレッドを持つように設定する。たとえば、IBMは、同時アクセスを

必要とするファイル数を見積もり、各ファイルに低2個のbiodスレッドを与えること

を推奨しています。

フラットファイルソースまたはターゲットを使用するグリッド上で同時セッションを実

行するときは、同時に必要とするソースまたはターゲットファイルに各パーティション

がアクセスできるように、十分なスレッドを用意します。

¨ アクセス要件に基づいて、共有ファイルシステムのマウントポイントを設定する。フ

ラットファイルソースまたはターゲットを使用するグリッド上でシーケンシャルセッシ

ョンを実行するときは、デフォルトの先読みプロセスまたは後書きプロセスの有効性を

低下させる可能性のある設定を回避します。ファイルシステムは、先読みおよび後書き

でシーケンシャルファイルアクセスを適化します。

¨ 必要に応じて、共有ファイルシステムの先読みおよび後書きの設定をチューニングす

る。

¨ クライアントとサーバーの両方の共有ファイルシステムのキャッシュ設定を検討する。

デフォルトの設定を増大すると、パフォーマンスを増大することができます。

¨ データアクセス後にメモリページを解放するには、ファイルシステムの「release-

behind」値を設定します。そうしなければ、大きいファイルの読み出しまたは書き込み

時に、システムパフォーマンス低下の可能性があります。

¨ アクセスパターンの違いにより、ソースおよびターゲット、永続キャッシュに対して異

なるマウントポイント使用できます。

詳細については、共有ファイルシステムのマニュアルを参照してください。

共有ファイルシステムの使用 47

CPUとメモリの使用量の均衡化

ローカルファイルシステムとは異なり、共有ファイルシステムサーバーでは、追加のCPUサ

イクルを使用してファイルにアクセスできます。計算ノードの1つを残りのノードの共有

ファイルシステムサーバーとして使用すると、そのノードが過負荷となってグリッド全体

のボトルネックとなるおそれがあります。共有ファイルシステムサーバーが過負荷状態に

なると、反復転送およびタイムアウト要求と同様に、CPUサイクルが増大します。

これを回避するために、PowerCenterグリッドノード専用の共有ファイルシステムサーバー

として、1台以上のマシンを使用します。各マシンは、要求されるタスクに対応した十分

なストレージ、CPU数およびネットワーク帯域幅を持つ必要があります。

また、共有ファイルシステムサーバーをクロスマウントして、ファイルサーバーの負荷を

グリッドのノード全体に分散できます。 I/OとCPUの使用率が均衡するようにPowerCenter

のマッピングとセッションを設定する場合は、共有ファイルシステムサーバーのクロスマ

ウントによってパフォーマンスを適化できます。グリッド内のノード数が小さく、I/O

とCPUの使用率がつり合っている場合は、専用の共有ファイルシステムサーバーは必要とな

らないことがあります。

専用のまたはクロスマウントされた複数の共有ファイルシステムサーバーを使用すると

き、サーバー全体に共有ファイルを分散するようにします。

関連項目：

¨ 「ファイルシステム全体へのファイルの分散」 (49ページの)

PowerCenterマッピングとセッションの設定

パフォーマンスを向上させるも重要な方法の1つは、不要なファイル共有を避けることで

す。設定が適切であると、共有ファイルシステムにおけるソースおよびターゲットファイ

ルのシーケンシャルアクセスは十分なパフォーマンスを実現します。ただし、永続キャッ

シュファイル、特に大きい永続キャッシュファイルに要求されるランダムアクセスは問題

となることがあります。

共有ファイルシステムを備えたグリッドの永続的なダイナミックルックアップなどの永続

キャッシュファイルを設定するには、以下のガイドラインに従います。

¨ できれば、より小さい永続キャッシュファイルをメモリ内で維持するように、セッショ

ンのキャッシュサイズを設定する。

¨ Sorterトランスフォーメーションをマッピングに追加して、永続的なルックアップの前

に入力行をソートする。作業を永続ルックアップからSorterトランスフォーメーション

に移行することにより、Sorterトランスフォーメーションはローカルファイルシステム

を使用できるので、パフォーマンスを向上できます。

¨ ルックアップキャッシュの同じページへのアクセスを必要とする行をグループ化して、

Integration Serviceがキャッシュの各ページを読む回数を小に抑える。

¨ 入力データのサイズが大きいときは、入力データの管理にソースベースのコミットを使

用して、メモリ内でソートが実行できるようにする。

たとえば、マッピングロジックの変更がなければ縮小できない永続ダイナミックルック

アップが4 GB、またソースデータが10 GBとします。初に、Sorterトランスフォーメ


ーションを追加して入力データをソートし、ルックアップキャッシュのランダムアクセ

スを削減し、その後、以下のタスクを完了します。

-ソースベースのコミットを1 GBのコミット間隔で実行するように、セッションを設定

する。

- Sorterトランスフォーメーションのトランザクション範囲を「トランザクション」に

設定する。

-ソース入力に十分な1 GBキャッシュサイズに合わせて、Sorterトランスフォーメーシ

ョンを設定する。

この設定では、Integration Serviceは、一度に1 GBの入力データをソートし、キャッシ

ュ内の似たデータへのサクセスを必要とする行を永続ルックアップへ渡します。

¨ 複数のファイルシステムが使用可能な場合は、個々のファイルシステムを使用するため

に、各パーティションのキャッシュファイルを設定します。

¨ 複数のファイルシステムが使用可能な場合は、ファイルを別々のファイルシステムに分

散するようにセッションを設定します。

ファイルシステム全体へのファイルの分散各ファイルシステムが独立した物理ディスクサブシステムを使用することを想定し、ファ

イルシステムの結合した帯域幅を使用するために、ファイルを異なるファイルシステムに

分散させます。別のファイルシステムにファイルを分散することにより、共有ファイルシ

ステムまたは対称型マルチプロセッシング（SMP）のいずれかを使用するグリッド上で、パ

フォーマンスを向上させることができます。

適なI/O帯域幅のために、複数のストレージデバイスにわたってファイルを分散するファ

イルシステムを選択します。クラスタファイルシステムを使用する場合は、ファイルをサ

ーバー間で分散させます。可能な場合には、ソース、ターゲット、キャッシュの各ファイ

ルを別々のストレージデバイスに配置します。

以下のガイドラインに従って、ファイルをファイルシステムに分散させます。

¨ ソースファイル。Integration Serviceが大量のファイルからデータを読み出せるよ

う、ファイルシステムにソースファイルを配置する場合は、ファイルシステムの先読み

設定を、大きなファイルのキャッシュ前にチューニングします。

¨ 一時ファイル。Integration Serviceが大きなファイルからデータを読み出して一時フ

ァイルに書き込めるよう、ファイルシステムに一時ファイルを配置する場合は、大きな

ファイルに対するファイルシステムの読み書き設定をチューニングします。

¨ ターゲットファイル。Integration Serviceが大きなファイルをディスクに書き込める

よう、ファイルシステムにターゲットファイルを配置する場合は、大きなブロックの同

時書き込み用にファイルシステムをチューニングします。ターゲットファイルには、

パーティション化されたセッション用の統合ファイルを含めることができます。グリ

ッド上のパーティション化されたセッションはファイルをディスクに書き込む必要があ

るため、ロックパフォーマンスが適になるよう、ファイルシステムをチューニングし

ます。

ファイルシステム全体へのファイルの分散 49

ファイルを分散するようにセッションを設定

ファイルの負荷を分散するようにセッションを手動で設定できます。負荷が大幅に変化す

るとき、あるいはクロスマウントされた共有ファイルシステムを持つグリッドへの新しい

ノードの追加を含めて、新しいセッションまたはファイルシステムを追加するとき、セッ

ションを編集する必要があります。

セッションを手動で編集する代わりに、セッション変数を使用して、ファイルを別のディ

レクトリへ分散します。これにより、セッションファイルを必要に応じて別のファイルサ

ーバへリダイレクトできます。

セッション変数を使用するには以下のガイドラインを使用します。

¨ ビジネスロジックを表わすように、セッションのファイル名およびディレクトリ用の変

数に名前を付ける。

¨ パラメータファイル内で、使用可能なすべてのファイルシステム全体にファイル負荷が

均一に分散するように、各変数を定義する。また、ノード特有の変数も定義できます。

¨ 必要に応じて、パラメータファイルを処理するスクリプトを使用して、再設定を自動化

する。

注: スクリプトを使用するとき、スクリプトで必要に応じてセッション変数を再定義

できるように、パラメータファイルでプレースホルダを使用します。

パラメータファイルとスクリプトのガイドライン

パラメータファイルおよびスクリプトを作成する場合は、以下のガイドラインに従いま

す。

¨ セッションファイルの場所の柔軟性と制御を容易に維持するには、スクリプトを使用し

てパラメータファイル内のプレースホルダを置き換える。

¨ ファイルの場所を定義するとき、推定のファイルサイズとファイルシステム容量を検討

する。

¨ セッションおよびワークフローがビジネスに関係するファイルに同時にアクセスする必

要がある場合は、ビジネスロジックに従ったファイルの整理を避ける。たとえば、カ

リフォルニアのファイルをあるファイルシステムに格納し、ニューヨークのファイルを

別のファイルシステムに格納した場合は、セッションが両方のファイルに同時にアクセ

スする必要があるときにボトルネックが発生することがあります。

¨ できる限り、同じソース、ターゲットまたはルックアップの異なるパーティション用の

ファイルを別の複数のファイルシステムに格納する。

例

次の生のパラメータファイルの抜粋では、プレースホルダ“{fs}”は、ディレクトリが配

置されるファイルシステムを表わし、使用される前にスクリプトによってそのファイルシ

ステムを割り当てる必要があります。

[SessionFFSrc_FFTgt_CA] $InputFile_driverInfo_CA={fs}/driverinfo_ca.dat $SubDir_processed_CA={fs}# Session has Output file directory set to: # $PmTargetFileDir/$SubDir_processed_CA# This file is the input of SessionFFSrc_DBTgt_CA. $SubDir_RecordLkup_Cache_CA={fs}# This session builds this persistent lookup cache to be used


# by SessionFFSrc_DBTgt_CA.# The Lookup cache directory name in the session is set to: # $PmCacheDir/$SubDir_RecordLkup_Cache_CA[SessionFFSrc_FFTgt_NY] $InputFile_driverInfo_NY={fs}/driverinfo_ny.dat $SubDir_processed_NY={fs}[SessionFFSrc_DBTgt_CA] $SubDir_processed_CA={fs}# session has Source file directory set to: # $PmTargetFileDir/$SubDir_processed_CA $SubDir_RecordLkup_Cache_CA={fs}# Use the persistent lookup cache built in SessionFFSrc_FFTgt_CA.

次のパラメータファイルの抜粋では、プレースホルダがfile_system_1とfile_system_2な

どの該当するファイルシステム名にスクリプトによって置き換わります。

[SessionFFSrc_FFTgt_CA] $InputFile_driverInfo_CA=file_system_1/driverinfo_ca.dat $SubDir_processed_CA=file_system_2# Session has Output file directory set to: # $PmTargetFileDir/$SubDir_processed_CA# This file is the input of SessionFFSrc_DBTgt_CA. $SubDir_RecordLkup_Cache_CA=file_system_1# This session builds this persistent lookup cache to be used # by SessionFFSrc_DBTgt_CA.# The Lookup cache directory name in the session is set to: # $PmCacheDir/$SubDir_RecordLkup_Cache_CA[SessionFFSrc_FFTgt_NY] $InputFile_driverInfo_NY=file_system_2/driverinfo_ny.dat $SubDir_processed_NY=file_system_1[SessionFFSrc_DBTgt_CA] $SubDir_processed_CA=file_system_1# session has Source file directory set to: # $PmTargetFileDir/$SubDir_processed_CA $SubDir_RecordLkup_Cache_CA=file_system_2# Use the persistent lookup cache built in SessionFFSrc_FFTgt_CA.

Sequence Generatorトランスフォーメーションの適化

Sequence Generatorトランスフォーメーションを使用してグリッドでセッションを実行す

るときのパフォーマンスを向上させるには、キャッシュ値の数をデータの各行と同じ数ま

で増やします。この結果、マスターDTMプロセスおよびワーカDTMプロセスとリポジトリの

間の通信が削減されます。マスターDTMおよびワーカDTMでは、1キャッシュ値につき1回の

通信を行います。

たとえば、150,000行のデータおよび7つのSequence Generatorトランスフォーメーション

があると想定します。キャッシュ値の数は10です。マスターDTMおよびワーカDTMでは、

15,000回の通信を行います。キャッシュ値の数を15,000に増やすと、マスターDTMおよびワ

ーカDTMの通信は10回になります。

Sequence Generatorトランスフォーメーションの適化 51

第 9 章

PowerCenterコンポーネントの適化


¨ PowerCenterコンポーネントの適化の概要, 52 ページ

¨ PowerCenterリポジトリのパフォーマンスの適化, 52 ページ

¨ Integration Serviceのパフォーマンスの適化, 54 ページ

PowerCenterコンポーネントの適化の概要次のPowerCenterコンポーネントのパフォーマンスを適化することができます。

¨ PowerCenterリポジトリ

¨ Integration Service

PowerCenterを複数のマシンで実行する場合、リポジトリサービスとIntegration Service

は個別のマシンで実行します。大量のデータをロードする場合、処理能力の高いマシンで

Integration Serviceを実行します。また、リポジトリサービスはPowerCenterリポジトリ

をホスティングするマシンで実行します。

PowerCenterリポジトリのパフォーマンスの適化

PowerCenterリポジトリのパフォーマンスを適化する次のタスクを実行します。

¨ PowerCenterリポジトリがリポジトリサービスプロセスと同じマシンにあることを確認

します。

¨ オブジェクトクエリーの条件を整理します。

¨ DB2データベースにインストールした場合は、PowerCenterリポジトリの単一ノードのテ

ーブルスペースを使用します。

52

¨ リポジトリをDB2データベースまたはMicrosoft SQL Serverデータベースにインストー

ルした場合は、PowerCenterリポジトリのデータベーススキーマを適化します。

リポジトリサービスプロセスおよびリポジトリの場所

高可用性オプションを設定していないリポジトリサービスのパフォーマンスを適化する

ことができます。パフォーマンスを適化するには、リポジトリデータベースを格納した

マシンでリポジトリサービスプロセスを実行中であることを確認します。

オブジェクトクエリの条件の整理

リポジトリサービスは複数の条件が設定されているパラメータを入力順に処理します。予

想通りの結果を得るため、また、パフォーマンスを向上させるためには、実行する順番に

パラメータを入力してください。

単一ノードのDB2データベースのテーブルスペース

PowerCenterリポジトリを単一ノードのテーブル領域に格納する場合、IBM DB2 EEEデータ

ベースのリポジトリ性能を適化することができます。IBM DB2 EEEデータベースを設定す

る際に、データベース管理者は単一ノードでデータベースを定義することができます。

PowerCenterクライアントおよびIntegration Serviceは、テーブル領域に1つのノードが

含まれる場合、リポジトリテーブルが別々のデータベースノードに置かれている場合より

も素早くリポジトリにアクセスできます。

リポジトリの作成、コピー、リストアを行う際にテーブル領域名を指定しない場合は、

DB2システムにより各リポジトリテーブルにデフォルトのテーブル領域が指定されます。

DB2システムで単一ノードのテーブル領域が指定される場合もあれば、指定されない場合も

あります。

データベーススキーマの適化

Administration Consoleでリポジトリサービスのデータベーススキーマの適化オプショ

ンを有効にすると、IBM DB2データベースおよびMicrosoft SQL Serverデータベース上の

リポジトリのパフォーマンスを改善できます。データベーススキーマの適化オプション

を有効にすると、リポジトリサービスでは、可能な場合は常に可変長文字データをCLOB列

ではなくVarchar(2000)列に格納します。 Varchar(2000)列を使用すると、以下のように

リポジトリのパフォーマンスが改善されます。

¨ ディスクアクセスの減少。PowerCenterリポジトリでは、データベーステーブル内の列

にVarcharデータを直接格納します。 CLOBデータの場合は、別のテーブルに参照として

格納されます。リポジトリからCLOBデータを取得するために、リポジトリサービスで

は、1つのデータベーステーブルにアクセスして参照を取得してから、参照先のテーブ

ルにアクセスしてデータを読み込む必要があります。 Varcharデータを取得するため

に、リポジトリサービスでは1つのデータベーステーブルにアクセスします。

¨ キャッシングの改善。リポジトリデータベースバッファマネージャでは、Varchar列は

キャッシュできますが、CLOB列はキャッシュできません。

PowerCenterリポジトリのパフォーマンスの適化 53

データベーススキーマを適化すると、以下の操作のリポジトリパフォーマンスを改善で

きます。

¨ リポジトリのバックアップ

¨ リポジトリのリストア

¨ リポジトリオブジェクトのエクスポート

¨ オブジェクト間の依存関係の一覧表示

¨ フォルダの配置

通常、リポジトリデータベースおよびページサイズが大きくなると、パフォーマンスもそ

れに応じて改善されます。したがって、大規模なPowerCenterリポジトリでは、データベー

ススキーマを適化すると、より大幅にパフォーマンスを改善できます。

リポジトリコンテンツを作成するか、既存のリポジトリをバックアップおよびリストアす

る場合は、データベーススキーマを適化できます。データベーススキーマを適化する

には、リポジトリデータベースが以下のページサイズ要件を満たす必要があります。

¨ IBM DB2。データベースのページサイズが4KB以上。ページサイズが16KB以上ある一時

テーブルスペースを少なくとも1つ。

¨ Microsoft SQL Server。データベースのページサイズが8KB以上。

Integration Serviceのパフォーマンスの適化

Integration Serviceのパフォーマンスを適化する次のタスクを実行します。

¨ Integration Serviceでは、ODBCドライバの代わりにネイティブドライバを使用しま

す。

¨ 文字データが7ビットASCIIまたはEBCDICの場合、Integration ServiceをASCIIデータ

移動モードで実行します。

¨ リポジトリサービスのPowerCenterメタデータをキャッシュします。

¨ Integration Serviceを高可用性で実行します。

注: Integration Serviceを高可用性に設定した場合、Integration Serviceはワークフ

ローおよびセッションをリカバリしますが、一時的なネットワーク障害やマシンの故障に

より失敗することもあります。ワークフローまたはセッションからリカバリする場合、

Integration Serviceは各ワークフローおよびセッションの状態を共有ディレクトリにある

一時ファイルに書き込みます。これにより、パフォーマンスが低下する可能性がありま

す。

ネイティブドライバおよびODBCドライバの使用

Integration Serviceでは、ODBCドライバまたはネイティブドライバを使用してデータベ

ースに接続することができます。ネイティブドライバを使用して、パフォーマンスを向上

させます。

54 章 9: PowerCenterコンポーネントの適化

ASCIIデータ移動モードでのIntegration Serviceの実行

Integration Serviceによって処理される文字データがすべて7ビットASCIIまたはEBCDIC

である場合は、Integration ServiceをASCIIデータ移動モードで実行するように設定しま

す。 ASCIIモードの場合は、Integration Serviceでは1文字を1バイトとして保存しま

す。 UnicodeモードでIntegration Serviceを実行した場合は、1文字に2バイトが使用さ

れるため、セッションのパフォーマンスが低下することがあります。

リポジトリサービスのPowerCenterメタデータのキャッシュ

Repository Agentキャッシュを使用して、DTMプロセスのパフォーマンスを向上することが

できます。Repository Agentキャッシュを有効にすると、リポジトリサービスは

Integration Serviceがリクエストしたメタデータをキャッシュします。メタデータをキャ

ッシュすると、Integration Serviceはリポジトリからメタデータを取得する代わりに、タ

スク実行以降のキャッシュを読み込みます。キャッシュされるのは、Integration Service

が要求したメタデータのみです。

たとえば、1,000セッションのワークフローを実行するとします。このとき、キャッシュが

有効になってから初めてワークフローを実行すると、Integration Serviceはリポジトリか

らメタデータを取得しますが、それ以降のワークフローでは、リポジトリサービスはキャ

ッシュされたセッションのメタデータを取得するようになります。これにより、DTMプロセ

スのパフォーマンスが向上します。

Integration Serviceのパフォーマンスの適化 55

第 1 0 章

システムの適化


¨ システムの適化の概要, 56 ページ

¨ ネットワークの速度の向上, 57 ページ

¨ 複数のCPUの使用, 57 ページ

¨ ページングの削減, 58 ページ

¨ プロセッサバインドの使用, 58 ページ

システムの適化の概要セッションが非効率的な接続や過負荷のIntegration Serviceプロセスシステムに依存して

いると、パフォーマンスの低下が頻繁に発生します。システムの遅延は、ルータ、スイッ

チ、ネットワークプロトコル、および同時利用者数の過多が原因で生じることもありま

す。

ソースおよびターゲットのデータベース、ソースおよびターゲットのファイルシステム、

およびドメイン内のノードが低速であると、セッションのパフォーマンスが低下する場合

があります。システム管理者に依頼して、使用しているマシンのハードディスクを評価し

てもらってください。

システム監視ツールを使用してシステムにボトルネックがあると判断した場合、以下のグ

ローバルな変更を加えることによって、すべてのセッションのパフォーマンスを向上させ

ることができます。

¨ ネットワーク速度の改善。ネットワーク接続速度が遅いと、セッションのパフォーマン

スが低下することがあります。ネットワークの応答性が良好かどうかをシステム管理

者に調べてもらってください。Integration Serviceプロセスとデータベースの間のネ

ットワークホップ数を減らします。

¨ 複数のCPUを使用する。複数のCPUを使用すると、複数のセッションや複数のパイプライ

ンパーティションを並列で実行できます。

¨ ページングの削減。オペレーティングシステムの物理メモリが不足した場合は、物理メ

モリを解放するためにディスクへのページングが開始されます。ディスクへのページ

ングが小限になるように、Integration Serviceプロセスマシン用の物理メモリを構

成します。

56

¨ プロセッサバインドの使用。マルチプロセッサUNIX環境では、Integration Serviceが

大量のシステムリソースを使用する場合があります。プロセッサバインドを使用し

て、Integration Serviceプロセスによるプロセッサの使用を制御します。また、ソー

スデータベースとターゲットデータベースが同じマシン上にある場合は、プロセッサバ

インドを使用して、データベースが使用するリソースを制限します。

ネットワークの速度の向上Integration Serviceのパフォーマンスは、ネットワーク接続に影響されます。ローカル

ディスクでは、ネットワークよりも5～20倍の速度でデータを転送できます。ネットワーク

アクティビティを小限に抑えてIntegration Serviceのパフォーマンス向上を図るため、

以下の事項を検討します。

セッションでフラットファイルをソースまたはターゲットとして使用し、Integration

Serviceが単一ノード上で実行されている場合は、Integration Serviceと同じマシン上に

ファイルを保存して、パフォーマンスを向上させます。フラットファイルをIntegration

Service以外のマシン上に格納すると、セッションのパフォーマンスはネットワーク接続の

パフォーマンスに依存するようになります。ファイルをIntegration Serviceプロセスシ

ステム上に移動し、ディスク領域を追加することで、パフォーマンスを向上させることが

できます。

リレーショナルソースまたはリレーショナルターゲットのデータベースを使用する場合

は、ソースおよびターゲットデータベースとIntegration Serviceプロセスの間のネットワ

ークホップ数を小限にするようにします。ターゲットデータベースをサーバーシステム

上に移動することで、Integration Serviceのパフォーマンスを向上させることができま

す。

複数のパーティションを含むセッションを実行しているときは、ネットワーク管理者に依

頼して、ネットワークを分析し、ネットワーク全体ですべてのパーティションからのデー

タ移動を扱うのに十分なバンド幅が確保されていることを確認してもらってください。

複数のCPUの使用追加のCPUを使用できるようにシステムを設定して、パフォーマンスを向上させます。複数

のCPUを使用すると、システムは複数のセッションや複数のパイプラインパーティションを

並列で実行できます。

ただし、CPUを追加すると、ディスクにボトルネックが発生する可能性があります。ディス

クのボトルネックを防ぐには、ディスクにアクセスするプロセス数を小限に抑えます。

ディスクにアクセスするプロセスには、データベース関数とオペレーティングシステム関

数が含まれています。並列のセッションやパイプラインパーティションにもディスクアク

セスが必要です。

ネットワークの速度の向上 57

ページングの削減ページングは、Integration Serviceプロセスで特定の処理を行う際にオペレーティングシ

ステムのメモリが不足して、メモリの代わりにローカルディスクを使用する場合に発生し

ます。ページングとその結果生じるパフォーマンスの低下を減らすには、メモリをさらに

解放をするか、または物理的メモリを増やします。システムツールを使ってページング動

作を監視してください。

システムメモリを増やして対処したほうがよい状況を以下に示します。

¨ キャッシュに格納された、大きなルックアップを使用するセッションを実行する場合。

¨ 多くのパーティションで構成されるセッションを実行する場合。

メモリを解放できない場合は、システムにメモリを追加します。

プロセッサバインドの使用マルチプロセッサUNIX環境では、多数のセッションを実行したときにIntegration Service

が大量のシステムリソースを使用する場合があります。その結果、マシン上の他のアプリ

ケーションが十分なシステムリソースを使用できなくなる可能性があります。プロセッサ

バインドを使用して、Integration Serviceプロセスノードによるプロセッサの使用を制御

できます。また、ソースデータベースとターゲットデータベースが同じマシン上にある場

合は、プロセッサバインドを使用して、データベースが使用するリソースを制限します。

Sun Solaris環境では、システム管理者はpsrsetコマンドを使用して、プロセッサセットの

作成と管理を行うことができます。システム管理者は次にpbindコマンドを使用して

Integration Serviceをプロセッサセットにバインドし、そのプロセッサセットが

Integration Serviceのみを実行するように設定できます。また、Sun Solaris環境では、

psrinfoコマンドによる設定済みの各プロセッサに関する詳細の表示、および、psradmコマ

ンドによるプロセッサのオペレーショナルステータスの変更を行うこともできます。詳細

については、システム管理者に問い合わせるか、Sun Solarisのマニュアルを参照してくだ

さい。

HP-UX環境の場合、システム管理者はProcess Resource Managerユーティリティを使って

システムのCPU使用状況を制御できます。Process Resource Managerは小限のシステム

リソースを割り当て、大限のリソースを使用します。詳細については、システム管理者

に問い合わせるか、HP-UXのマニュアルを参照してください。

AIX環境の場合、システム管理者はAIX 5LのWorkload Managerを使って、要求のピーク時

におけるシステムリソースを管理できます。Workload Managerは、リソースを割り当て、

CPU、メモリ、およびディスクI/Oバンド幅を管理できます。詳細については、システム管

理者に問い合わせるか、AIXのマニュアルを参照してください。

58 章 10: システムの適化

第 1 1 章

パイプラインパーティションの使用


¨ パイプラインパーティションの使用の概要, 59 ページ

¨ パーティション化のためのソースデータベースの適化, 62 ページ

¨ パーティション化のためのターゲットデータベースの適化, 63 ページ

パイプラインパーティションの使用の概要アプリケーション、データベース、およびシステムがシングルパーティションで高パフ

ォーマンスを実現できるようチューニングした後で、システムが十分には活用されていな

いことが判明する場合があります。この時点では、セッションに2つ以上のパーティション

を持たせるよう設定することができます。

パイプラインパーティションを使用すると、セッションのパフォーマンスを向上させるこ

とができます。パーティションまたはパーティションポイントの数を増やすと、スレッド

の数が増えます。したがって、パーティションまたはパーティションポイントの数を増や

すと、Integration Serviceのノードに対する負荷も大きくなります。Integration

Serviceのノードに十分なCPUバンド幅がある場合は、セッションで並列にデータ行を処理

すると、セッションのパフォーマンスを向上させることができます。

注: 単一ノードのIntegration Serviceを使用して大量のデータを処理するセッションで

たくさんのパーティションまたはパーティションポイントを作成すると、システムの負荷

が大きくなりすぎる場合もあります。

Partitioningオプションがある場合は、次のタスクに従ってパーティションを手動で設定

します。

¨ パーティション数を増やす。

¨ パイプラインの特定のポイントにあるパーティションタイプで、もパフォーマンスの

高いものを選択する。

¨ 複数のCPUを使用する。

59

パーティション数の増加

セッションのパフォーマンスを改善するために、パイプライン内のパーティション数を増

やすことができます。パーティションの数を増やすことにより、Integration Serviceはソ

ースへの複数の接続を作成し、ソースデータのパーティションを並列に処理することがで

きます。

セッションがファイルソースを使用するときは、1つまたは複数のスレッドでソースを読み

込むようにセッションを設定できます。複数のスレッドでファイルソースを読み込むよう

セッションを設定し、セッションのパフォーマンスを向上させます。Integration Service

は、ファイルソースへの同時接続を複数作成します。

セッションを作成するときに、Workflow Managerはパーティション化に対してマッピング

内の各パイプラインを検査します。Integration Serviceがパーティション化データを処理

するときに、データの一貫性を保持できれば、パイプラインに複数のパーティションを指

定することができます。

パーティションをセッションに追加する場合には、以下のヒントを使用します。

¨ 一度に1つずつパーティションを追加。高の監視パフォーマンスを実現するには、パ

ーティションを一度に1つずつ追加し、各パーティションの追加前にセッション設定を

記録しておきます。

¨ DTMバッファメモリの設定。パーティションの数を増やす際、DTMバッファサイズも増や

します。セッションにn個のパーティションが含まれる場合は、1つのパーティション

を持つセッションの値の少なくともn倍の値までDTMバッファサイズを増やします。

¨ Sequence Generatorにキャッシュされた値の設定。セッションにn個のパーティション

がある場合、Sequence Generatorトランスフォーメーションで［キャッシュされる値の

数］プロパティを使用する必要はありません。この値を0より大きい値に設定する場合

は、1つのパーティションを持つセッションの元の値の少なくともn倍にします。

¨ ソースデータの均一なパーティション化。各パーティションで同じ行数が抽出されるよ

うに設定します。

¨ セッションの実行時にシステムを監視。CPUサイクルに空きがある場合は、パーティシ

ョンを追加してパフォーマンスを改善できます。たとえば、システムに20%のアイドル

時間があるときは、CPUサイクルに余裕がある場合があります。

¨ パーティション追加後のシステムを監視。CPU利用率が向上しない場合、I/Oタイムの待

機時間が延びた場合、または合計のデータトランスフォーメーション率が下落した場合

には、ハードウェアまたはソフトウェアにボトルネックがあると考えられます。 I/Oタ

イムの待機時間が大幅に延びる場合には、システムをチェックしてハードウェアにボト

ルネックがないか確認します。それ以外の場合、データベース設定をチェックしてくだ

さい。

関連項目：

¨ 「バッファメモリ」 (38ページの)

良のパフォーマンスを得るためのパーティションタイプの選択

パイプライン上のさまざまなポイントに対してそれぞれのパーティションタイプを指定す

ることで、セッションのパフォーマンスを向上させることができます。セッションのパフ

60 章 11: パイプラインパーティションの使用

ォーマンスを適化するには、ソースデータベースおよびターゲットデータベースにデー

タベースパーティション化パーティションタイプを使用します。データベースのパーティ

ション化は、OracleおよびIBM DB2ソース、そしてIBM DB2ターゲットで使用できます。ソ

ースデータベースのパーティション化を使用する場合、Integration Serviceは、データベ

ースシステムにテーブルパーティション情報を要求し、データをセッションパーティショ

ンに取り出します。ターゲットデータベースのパーティション化を使用する場合、

Integration Serviceは対応するデータベースパーティションノードにデータをロードしま

す。

パイプラインパーティションおよびデータベースパーティションは複数使用することがで

きます。パフォーマンスを向上させるには、パイプラインパーティションの数がデータベ

ースパーティションの数と一致することを確認します。サブパーティション化したOracle

ソースのパフォーマンスを向上させるには、パイプラインパーティションの数がデータベ

ースサブパーティションの数と一致することを確認します。

パフォーマンスを向上させるには、パイプラインでの次のパーティションポイントにおけ

るパーティションタイプを指定します。

¨ Source Qualifierトランスフォーメーション。複数のフラットファイルからデータを同

時に読み込むには、Source Qualifierトランスフォーメーション内の各フラットファイ

ルに対して1つのパーティションを指定します。デフォルトのパーティションタイプで

あるパススルーを適用します。

¨ Filterトランスフォーメーション。ソースファイルのサイズが変化するため、各パーテ

ィションで処理するデータの量が異なります。 Filterトランスフォーメーションに1つ

のパーティションポイントを設定し、Filterトランスフォーメーションに送られる負荷

を平均化するために、ラウンドロビンパーティション化を選択します。

¨ Sorterトランスフォーメーション。SorterトランスフォーメーションとAggregatorトラ

ンスフォーメーションで重複するグループを無くすために、Sorterトランスフォーメー

ションで自動ハッシュキーパーティション化を使用します。これにより、Integration

ServiceはSorterトランスフォーメーションとAggregatorトランスフォーメーションで

行が処理される前に、同じ説明を持つすべての項目が同じパーティションにグループ化

されます。Aggregatorトランスフォーメーションにあるデフォルトのパーティションポ

イントは削除できます。

¨ ターゲット。ターゲットテーブルはキー範囲によりパーティション化されるため、ター

ゲットにキー範囲パーティション化を指定してターゲットへのデータの書き込みを適

化します。

複数のCPUの使用

Integration Serviceは、パイプラインでの読み込み、トランスフォーメーション、および

書き込み処理を並列に行います。PowerCenter Serverは、セッション内のパイプラインの

複数のパーティションを並列に処理するほか，複数のセッションを並列に実行することが

できます。

対称型マルチプロセッシング（SMP）プラットフォーム上では、複数のCPUを使用してセッ

ションデータまたはデータのパーティションを並列に処理できます。すなわち真の並列処

理が実現されるので、パフォーマンスが向上します。シングルプロセッサプラットフォー

ム上ではこれらの作業はCPUを共有するので、並列処理は存在しません。

Integration Serviceは、複数のCPUを使用して、複数のパーティションを含むセッション

を処理することができます。使用されるCPUの数は、パーティションの数、スレッドの数、

パイプラインパーティションの使用の概要 61

利用可能なCPUの数、およびマッピングを処理するのに必要なリソースの量などの要素に依

存します。

パーティション化のためのソースデータベースの適化

パーティションを追加して、クエリーの速度を高めることも考慮できます。通常、reader

側の各パーティションで、処理対象になるデータのサブセットを表します。

次のタスクを実行して、パーティション化のためにソースデータベースを適化します、

¨ データベースのチューニング。データベースが適切にチューニングされない場合は、パ

ーティションを作成してもセッションが速く処理されない可能性があります。

¨ 並列クエリの有効化。データベースの中には、並列クエリを有効にするために設定する

必要があるオプションが備えられているものがあります。これらのオプションに関す

るデータベースのマニュアルを参照してください。これらのオプションがオフの場合、

Integration Serviceでは複数のパーティションのSELECT文が連続して実行されます。

¨ データを異なるテーブルスペースに分割。各データベースでは、データを異なるテーブ

ルスペースに分割するオプションが提供されています。データベースが許容する場

合、PowerCenter SQLオーバーライド機能を使用して、1つのパーティションからデータ

を抽出するクエリを指定できます。

¨ ソート済みデータのグループ化。ソースデータのパーティション化やグループ化によっ

て、ソートされたJoinerトランスフォーメーションのパフォーマンスを向上させること

ができます。

¨ 単一のソート済みクエリの大化。

データベースのチューニング

データベースが適切にチューニングされない場合は、結果的にセッションを高速化できな

いこともあります。データベースをテストして、チューニングが正しく行われているかを

確認できます。

データベースが正しくチューニングされているかを確認するには：

1. 1つのパーティションを含むパイプラインを作成します。

2. Workflow Monitorでreaderスループットを測定します。

3. パーティションを追加します。

4. スループットが直線的に拡張しているか確認します。

たとえば、セッションに2つのパーティションが存在する場合、readerスループットの

速さは2倍になっているはずです。スループットが直線的に拡張していない場合は、デ

ータベースのチューニングが必要になりそうです。


ソート済みデータのグループ化

ソースデータをパーティション化したりグループ化することで、ソートされたJoinerトラ

ンスフォーメーションのパフォーマンスを向上させることができます。パーティションポ

イントをSorterトランスフォーメーションの前に置くことによって、各グループ内でデー

タを確実にグループ化しソートすることができます。

データをグループ化するには、同じキー値を持つ行を確実に同じパーティションにルーテ

ィングする必要があります。複数のパーティションに対してデータを均等にグループ化し

配分するためのも効果的な方法は、自動ハッシュキーまたはキー範囲のパーティション

ポイントを、ソート基点より前に追加することです。

単一のソート済みクエリの適化

データベースで単一のソート済みクエリを適化するには、並列処理を実現する以下のチ

ューニングオプションを検討します。

¨ 自動チューニングを実行する設定パラメータの確認。たとえば、Oracleには

parallel_automatic_tuningというパラメータがあります。

¨ 内部並列処理が有効になっていることを確認。内部並列処理は、1つのクエリで複数の

スレッドを実行できる機能です。たとえば、Oracleでは

parallel_adaptive_multi_userを確認してください。DB2ではintra_paralleｌを確認

してください。

¨ 並列実行に利用可能な並列処理の大数の確認。たとえば、Oracleの場合は、

parallel_max_serversを確認します。 DB2ではmax_agentsを確認します。

¨ 並列化で使用されている各種リソースのサイズの確認。たとえば、Oracleには、

large_pool_size、shared_pool_size、hash_area_size、

parallel_execution_message_size、optimizer_percent_parallelなどのパラメータが

あります。 DB2には、dft_fetch_size、fcm_num_buffers、sort_heapなどのパラメー

タがあります。

¨ 並列度の確認。このオプションは、データベース設定パラメータ、またはテーブルやク

エリのオプションとして指定できます。たとえば、Oracleには

parallel_threads_per_cpuおよびoptimizer_percent_parallelというパラメータがあ

ります。DB2には、dft_prefetch_size、dft_degree、max_query_degreeなどの設定パ

ラメータがあります。

¨ データベースの拡張性に影響を及ぼす可能性のあるオプションをオフ。たとえば、

Oracleでは、アーカイブロギングと時間統計を無効にします。

データベースチューニングオプションのすべてのリストについては、データベースのマニ

ュアルを参照してください。

パーティション化のためのターゲットデータベースの適化

セッションに複数のパーティションが含まれている場合は、各パーティションのスループ

ットをシングルパーティションセッションのスループットと同じにするとよいでしょう。

パーティション化のためのターゲットデータベースの適化 63

この相関関係がない場合は、データベースはおそらくレコードを連続的に挿入していま

す。

データベースが行を並列に挿入しているかどうかを確認するには、ターゲットデータベー

スで以下の設定オプションをチェックしてください。

¨ データベースにオプションを設定して並列挿入を有効化。たとえば、

db_writer_processesを設定し、OracleデータベースのDB2のmax_agentsオプション

で、並列化挿入を有効にします。データベースの中には、これらのオプションをデフ

ォルトで有効にしているものもあります。

¨ ターゲットテーブルのパーティション化の考慮。可能な場合、Routerトランスフォーメ

ーションを使用し、各パーティションでシングルデータベースパーティションへの書き

込みを行います。また、パイプラインパーティション間のI/O競合を防ぐために、別々

のディスクにデータベースパーティションを設けることを検討してください。

¨ データベースにオプションを設定してデータベースの拡張性を向上。たとえば、Oracle

データベースでは、アーカイブロギングや時間統計を無効にして、拡張性を向上させま

す。


付録 A

パフォーマンスカウンタ

この付録では、以下の項目について説明します。

¨ パフォーマンスカウンタの概要, 65 ページ

¨ Errorrowsカウンタ, 65 ページ

¨ ReadfromcacheカウンタおよびWritetocacheカウンタ, 66 ページ

¨ ReadfromdiskおよびWritetodiskカウンタ, 66 ページ

¨ Rowsinlookupcacheカウンタ, 67 ページ

パフォーマンスカウンタの概要すべてのトランスフォーメーションはカウンタを持っています。Integration Serviceで

は、トランスフォーメーションごとに入力行、出力行、およびエラー行の数が追跡されま

す。一部のトランスフォーメーションには、パフォーマンスカウンタを持つものがありま

す。以下のパフォーマンスカウンタを使用すると、セッションのパフォーマンスを向上さ

せることができます。

¨ Errorrows

¨ ReadfromcacheおよびWritetocache

¨ ReadfromdiskおよびWritetodisk

¨ Rowsinlookupcache

Errorrowsカウンタトランスフォーメーションのエラーは、セッションのパフォーマンスに影響を与えます。

Transformation_errorrowsカウンタのいずれかで、トランスフォーメーションに多数のエ

ラー行がある場合は、エラーを除去するとパフォーマンスを改善できます。

65

関連項目：

¨ 「トランスフォーメーションエラーの除去」 (35ページの)

ReadfromcacheカウンタおよびWritetocacheカウンタ

セッションにAggregator、RankまたはJoinerの各トランスフォーメーションが含まれる場

合は、Transformation_readfromcacheおよびTransformation_writetocacheカウンタ以外

にも、Transformation_readfromdiskおよびTransformation_writetodiskカウンタを確認

して、Integration Serviceによるディスクからの読み出しまたはディスクへの書き込みを

分析します。セッションの実行中にセッションのパフォーマンス詳細を表示するには、

Workflow Monitorでセッションを右クリックし、［プロパティ］を選択します。詳細ダイ

アログボックスで［プロパティ］タブをクリックします。

ディスクアクセスを分析するには、初にヒット/ミス率を計算します。ヒット率は、

Integration Serviceがキャッシュに対して実行する読み出し/書き込み操作回数を示しま

す。

ミス率は、Integration Serviceがディスクに対して実行する読み出し/書き込み操作回数

を示します。

キャッシュのミス率を計算するには、次の式を使用します。

[(# of reads from disk) + (# of writes to disk)]/[(# of reads from memory cache) + (# of writes to memory cache)]

キャッシュのヒット率を計算するには、次の式を使用します。

[1 - Cache Miss ratio]

ディスクへの読み出し/書き込みを小限に抑えるには、キャッシュサイズを増やしてくだ

さい。適なキャッシュヒット率は1です。

ReadfromdiskおよびWritetodiskカウンタセッションにAggregator、RankまたはJoinerの各トランスフォーメーションが含まれる場

合は、Transformation_readfromdiskおよびTransformation_writetodiskの各カウンタを

確認します。セッションの実行中にセッションのパフォーマンス詳細を表示するには、

Workflow Monitorでセッションを右クリックし、［プロパティ］を選択します。詳細ダイ

アログボックスで［プロパティ］タブをクリックします。

これらのカウンタにゼロ以外の数値が表示されている場合は、キャッシュサイズを大きく

するとセッションのパフォーマンスを改善できます。Integration Serviceでは、グループ

情報の格納にはインデックスキャッシュが使用され、トランスフォーメーション後のデー

タの格納にはデータキャッシュが使用されます。一般に、トランスフォーメーション後の

データの方が、グループ情報よりも大きなサイズになります。したがって、インデックス

キャッシュとデータキャッシュの両方のサイズがパフォーマンスに影響するものの、デー

66 付録 A: パフォーマンスカウンタ

タキャッシュのサイズを大きくしなければならない可能性の方が、インデックスキャッシ

ュを大きくしなければならない可能性より高くなります。ただし、データキャッシュサイ

ズ拡張によってパフォーマンスを向上できるのは、処理済みデータのボリュームが使用可

能メモリより大きい場合です。

たとえば、Integration Serviceではインデックスキャッシュの格納に100MB、データキャ

ッシュの格納に500MBが使用されます。200回のアクセスをインデックスキャッシュおよび

データキャッシュのそれぞれに対してランダムに分散させる場合、次のキャッシュ設定方

法があります。

¨ パフォーマンスの適化を目的に、インデックスキャッシュに100MB、データキャッシ

ュに200MBの割り当て。Integration Serviceは、データの100%をインデックスキャッ

シュからアクセスし、データの40%をデータキャッシュからアクセスします。

Integration Serviceはインデックスキャッシュへは常時アクセスしますが、そのうち

120回はデータキャッシュにはアクセスしません。その結果、データアクセス比率は70%

となります。

¨ インデックスキャッシュに50MB、データキャッシュに250MBの割り当て。Integration

Serviceは、データの50%をインデックスキャッシュからアクセスし、データの50%をデ

ータキャッシュからアクセスします。Integration Serviceは、インデックスキャッシ

ュへのアクセスと、データキャッシュへのアクセスをそれぞれ100回ずつ行いますが、

一度に両方にアクセスすることはありません。その結果、データアクセス比率は50%と

なります。

セッションで差分集計を実行する場合は、Integration Serviceはセッション中にローカル

ディスクから履歴集計データを読み込み、履歴データの保存時にディスクに書き込みま

す。その結果、Aggregator_readtodiskカウンタおよびAggregator_writetodiskカウンタ

には、ゼロ以外の数字が表示されます。

ただし、Integration Serviceではセッション終了時にファイルに履歴データが書き込まれ

るため、セッション中にこれらのカウンタを評価することもできます。セッションの実行

中、カウンタにゼロ以外の数値が表示される場合は、キャッシュサイズをチューニングす

るとパフォーマンスを向上させることができます。ただし、メモリの割り当てまたは割り

当て解除にはコストが生じるため、Integration Serviceでのデータ処理量を把握している

場合は、キャッシュサイズの拡張をなるべく控えてデータボリュームの増大に対処しま

す。

Rowsinlookupcacheカウンタ複数のルックアップはセッションの処理を低下することがあります。セッションのパフォ

ーマンスを改善するには、大きなLookupテーブルに対するLookup式をチューニングしま

す。

関連項目：

¨ 「複数のルックアップの適化」 (32ページの)

Rowsinlookupcacheカウンタ 67

索引

記号クラスタ化されたファイルシステム

共有ファイルシステムも参照

aaa] 47

高可用性 47

CPU

コンカレントワークフローのための複数 57

パイプラインのパーティション化のための複数 61

DB2

PowerCenterリポジトリのパフォーマンス 53

FastExport

Teradataソース用 18

IBM DB2

リポジトリデータベーススキーマ、適化 53

Microsoft SQL Server

インメモリデータベース 18


ネットワークファイルシステム

共有ファイルシステムを参照

aaa] 47

Oracle

IPCプロトコル 18

外部ローダ 14

接続の適化 18

ターゲットのチューニング 15

Sybase IQ

外部ローダ 14

Windows

ボトルネック 10

ボトルネック、除去 11

AAggregatorトランスフォーメーション

限定ポート接続による適化 27

差分集計 27

ソート済み入力による適化 27

チューニング 26

パフォーマンスの詳細 66

フィルタによる適化 27

ポート別のグループでの適化 27

ASCIIモード

パフｫーマンス 55

CCharデータ型

末尾の空白の削除 23

Customトランスフォーメーション

関数呼び出しの小化 28


データブロックの処理 28

DDECODE関数

LOOKUP関数との比較 23

適化に使用 23

DTMバッファ

適なプールサイズ 39

EExternal Procedureトランスフォーメーション

データのブロック 25

IIIF式


Integration Service

グリッド 36

コミット間隔 42

適なデータベースドライバ 54


IPCプロトコル

Oracleソース 18

JJoinerトランスフォーメーション

ソート済みデータ 28



マスターソースの指定 28

LLOOKUP関数

DECODE関数との比較 23

適化のための小化 23

Lookupトランスフォーメーション

ORDER BY文による適化 31

インデックス処理による適化 32

68

キャッシュ削減による適化 31

キャッシュによる適化 29

コンカレントキャッシュによる適化 30

適化 67

大容量メモリ搭載マシンによる適化 31


データベースドライバによる適化 29

複数のルックアップ式の適化 32

ルックアップ条件の一致の適化 30

ルックアップ条件の適化 31

OORDER BY

Lookupトランスフォーメーションのための適化 31

PPowerCenterリポジトリ

DB2のパフォーマンス 53

適な場所 53


RRankトランスフォーメーション


SSequence Generatorトランスフォーメーション

グリッドパフォーマンス 51

再利用可能 33


Single-Pass読み込み

定義 20

Sorterトランスフォーメーション


パーティションディレクトリの適化 34

メモリ割り当てによる適化 33

Source Qualifierトランスフォーメーション


SQLトランスフォーメーション


Sybase ASE

インメモリデータベース 18

TTeradata FastExport

ソースのパフォーマンス 18

UUNIX

システムのボトルネック 10

プロセッサバインド 58


VVarcharデータ型

末尾の空白の削除 23

XXMLソース

バッファメモリの割り当て 38

XMLファイル

フラットファイルとの比較 20

あアイドル時間

スレッド統計 4

い一時ファイル

適なストレージ 46

一括ロード

リレーショナルターゲットのチューニング 13

インデックス

Lookupテーブル用 32

削除 12

インデックスキャッシュ

適なサイズ 41

適な場所 41

え永続キャッシュ

ルックアップ用 30

永続キャッシュファイル


設定ガイドライン 48

エラー

トレースレベルの小化 43

エラートレース

トレースレベルを参照

aaa] 43

演算

数値対文字列 23

演算子

関数との比較 24

おオブジェクトクエリ

条件の整理 53

か外部ローダ


索引 69

関数

DECODE対LOOKUP 23

演算子との比較 24

関数の呼び出し

Customトランスフォーメーションのための小化 28

きキー制約

削除 12

キャッシュ

キャッシュされる行の削減 31

適なサイズ 41

適な場所 41

シーケンス値 33


リポジトリメタデータ 55

キャッシュディレクトリ

共有 41

キャッシュファイル


共有キャッシュ

ルックアップ用 30

共有ファイルシステム

CPU、均衡化 48

概要 47

高帯域幅 46

サーバ負荷、分散 48

設定 47

低帯域幅 46

くクエリ

リレーショナルソースのチューニング 16

区切りフラットファイル

ソース 20

グリッド

Sequence Generatorのパフォーマンス、向上 51

適な格納場所 45

ノードのボトルネック 48

パフｫーマンス 36, 45

グリッド上のセッション

Sequence Generatorのパフォーマンス、向上 51

け結合

データベース 28

こ高可用性

クラスタ化されたファイルシステム 47

個別選択

ソースデータのフィルタリング 34

コミット間隔

セッションのパフォーマンス 42

さ小化

集計関数の呼び出し 23

適なファイルストレージ

一時ファイル 46

ソースファイル 46

ターゲットファイル 46

パラメータファイル 46

非永続キャッシュファイル 46

ログファイル 46

削除

インデックスおよびキー制約 12

末尾の空白スペース 23

差分集計


し式


評価 25

ローカル変数への置き換え 23

シーケンシャル統合

適なファイルストレージ 46

システム

UNIXのボトルネック、特定 10

Windowsのボトルネック、特定 10


ボトルネック、Workflow Monitorを使用した特定 9

ボトルネック、原因 9


実行後に発信されるメール


集計関数

呼び出しの小化 23

す数値演算

文字列演算との比較 23

ステージングエリア

削除 43

スペース

末尾、削除 23

スレッド

アイドル時間 4

スレッド作業時間 4

ビジー時間 4

ボトルネック、特定 4

ランタイム 4

スレッド統計



せセッション

グリッド 36

コンカレント 37

70 索引


プッシュダウンの適化 37




セッションログファイル

無効化 43

そソース

クエリーのチューニング 16

フｨルタ 17



ボトルネックの特定 6

リレーショナル、チューニング 16

ソースファイル


フラット対XML 20

ソート済み入力


たターゲット

バッファメモリの割り当て 38



ボトルネックの特定 6

ターゲットファイル


単純マッピング


ちチｪックポイント間隔

長く設定 13

抽出

マッピングから共通ロジック 22

チューニング

Aggregatorトランスフォーメーション 26

Customトランスフォーメーション 28

Integration Service 54

Joinerトランスフォーメーション 28

Lookupトランスフォーメーション 29

PowerCenterリポジトリ 52

Sequence Generatorトランスフォーメーション 33

Sorterトランスフォーメーション 33

Source Qualifierトランスフォーメーション 34

SQLトランスフォーメーション 34

キャッシュ 40

式 22

システム 56

セッション 36

トランスフォーメーション 26

ネットワーク 57

マッピング 19

リレーショナルソース 16

てディスク

アクセス、小化 57

ディレクトリ

共有キャッシュ 41

データ移動モード

適 55

データ型

Char 23

Varchar 23

変換の適化 22

データキャッシュ

適なサイズ 41

適な場所 41

接続ポート 41

データフロー

適化 65

モニタリング 65

データベース

Oracleターゲットのチューニング 15

結合 28

ソースのチューニング 16

単一のソート済みクエリーのチューニング 63

チｪックポイント間隔 13

デッドロックの小化 14

ネットワークパケットのサイズ 15, 17

パーティション化のためのソースの適化 62

パーティション化のためのターゲットの適化 63

データベースクエリー

ソースのボトルネック、特定 7

データベースドライバ

Integration Serviceに適 54

デッドロック

小化 14

テーブルスペース

DB2に適なタイプ 53

とトランスフォーメーション

エラーの除去 35

適化 65


トランスフォーメーションスレッド

スレッド作業時間 4

トレースレベル

小化 43

ねネットワーク

速度の改善 57


ネットワークパケット

長く設定 15, 17

索引 71

はパイプライン

データフローのモニタリング 65

パイプラインのパーティション化

適なパーティションタイプ 60

ソースデータベースの適化 62

ソースデータベースのチューニング 62

ターゲットデータベースの適化 63

パーティションの追加 60

パフォーマンスの適化 59

複数のCPU 61

バインディング

プロセッサ 58

バッファ長

適設定 20

バッファブロックサイズ

適 39

バッファメモリ

割り当て 38

バッファリング

データ 25

パーティション

追加 60

パーティションタイプ

適 60

パフｫーマンス

チューニング、概要 1

フラッシュ待ち時間 42

リアルタイムセッション 42


パフォーマンスカウンタ

Transformation_errorrows 65

Transformation_readfromcache 66

Transformation_readfromdisk 66

Transformation_writetocache 66

Transformation_writetodisk 66

Rowsinlookupcache 67

タイプ 65

パラメータファイル


パフォーマンスのガイドライン 50

ひ非永続キャッシュ


ビジー時間


評価

式 25

ふフｧイル共有

ネットワークファイルシステム 47

クラスタファイルシステム 47

ファイルシステム

共有、設定 47

クラスタ 47

ネットワーク 47

ファイルストレージ

共有ファイルシステム 45

タイプ 45

ローカル 45

フｨルタ

ソース 17

Filterトランスフォーメーション


フィルタリング

ソースデータ 34

データ 21

プッシュダウンの適化


フラッシュ待ち時間

パフォーマンス、向上 42

フラットフｧイル

XMLファイルとの比較 20

区切りソースファイル 20

適な格納場所 57

ソースの適化 19

バッファ長 20

フラットファイルターゲット

セッション実行後のメール 44

プロセッサ

バインディング 58

へページサイズ

リポジトリデータベーススキーマを適化するための

小 53

ページング

削減 58

変換

データ型 22

ほポート

接続される、制限 41

ポート別のグループ


ボトルネック

UNIX 10

Windows 10

識別 3

システム 9

除去 3


セッション 9

ソース 6

ターゲット 6

マッピング 8

まマッピング

Single-Pass読み込み 20

共通ロジックの抽出 22

単純マッピング、チューニング 21


72 索引



めメソッド

データのフィルタリング 21

メモリ

64-bit PowerCenter 42

Microsoft SQL Serverデータベース 18

Sybase ASEデータベース 18

長く設定 58

バッファ 38

も文字列演算

小化 23

数値演算との比較 23

よ読み込みテストマッピング


らランタイム


りリアルタイムセッション

パフォーマンス、向上 42

リポジトリ

データベーススキーマ、適化 53

リポジトリサービス

リポジトリメタデータのキャッシング 55

リポジトリサービスプロセス

適な場所 53

るルックアップSQLオーバーライドオプション

キャッシュサイズの削減 31

ルックアップ条件

一致 30

適化 31

ろローカル変数

式の置き換え 23

ログファイル


わワークフロー

コンカレント 37

ワークフローログファイル

無効化 43

索引 73

Documents

Informatica PowerCenter 9.0.1 パフォーマンスのチューニング の … Documentation/1/PC_901... · Informatica PowerCenter パフォーマンスのチューニングの概要

Informatica PowerCenter 9.0.1 パフォーマンスのチューニングの … Documentation/1/PC_901... · Informatica PowerCenter パフォーマンスのチューニングの概要