DB接続設計 WASV6 Workshop による基幹システム設計

WASV6による基幹システム設計Workshop
DB接続設計
Agenda
データベース・アクセス基礎
一般的なデータベース・アクセスにおけるHint & Tips
Connect to DB2 UDB for LUW (Linux Unix Windows)
Connect to DB2 for z/OS using DB2 Connect
Connect to DB2 for z/OS using Universal JDBC Driver
データベース・アクセス基礎
データベース・アクセス関連コンポーネント
アプリケーション
データ・
データ・ソース定義
ソース定義 (Data Source)
接続プールやJDBCドライバーに関する設定を行う単位です。
接続プール
接続プール (Connection Pool)
アプリケーション・サーバーにインストールされたアプリケーションです。
接続オブジェクトを再利用することで、接続処理による負荷を軽減できます。
接続オブジェクト
接続オブジェクト(Connection
オブジェクト(Connection Object)
RDBMSへの接続を抽象化したオブジェクトです。
Managed Connection（（接続プール内の）接続オブジェクト）
Physical Connection （物理接続）
接続オブジェクトと物理接続の状態が、常に一致するとは限りません。
JDBCドライバー
JDBCドライバー
一般的にRDBMSベンダーから提供されるドライバーです。
Application Server
DataSource
Application
(JDBC or SQLJ)
Connection Pool
JDBC Driver
RDBMS
Data
Managed Connection
DataStoreHelper
Physical Connection
接続プールの設定
接続オブジェクトの管理
接続オブジェクトを管理する指針を設定する
接続タイムアウト
dataSource.getConnection()の待ち時間
最大接続数
最小接続数
パージ・ポリシー
リープ処理
一定時間おきに接続オブジェクトを監視し、タイムアウトをチェックする
リープ時間
未使用タイムアウト (Unused Timeout)
未使用の接続を解放
物理接続が最小接続数まで解放
経過タイムアウト (Aged timeout)
定期的にリソースを解放
物理接続が0になるまで解放
Application
最大接続数 = 10
最小接続数 = 5
Application
Connection Pool
最小接続数を超えて
いる場合のみ、未使
用タイムアウトによる
切断対象になる
接続オブジェクトのライフ・サイクル
Managed Connectionの3種類のステータス
Connection Pool
DoesNotExist
InUse
DoesNotExist
InFreePool
(5)
物理接続が存在し、利用されている
InFreePool
物理接続が無い
(4)
(3)
(2)
(1)
物理接続が存在するが、利用されていない
ステータスの遷移のタイミング
InUse
(1)
DoesNotExist → InUse
(2)
InUse → InFreePool
(3)
接続プール内に、InFreePoolの接続オブジェクトがあるときに、dataSource.getConnection()
InUse → DoesNotExist
(5)
connection.close()
InFreePool → InUse
(4)
接続プール内に、InFreePoolの接続オブジェクトがないときに、dataSource.getConnection()
StaleConnectionExceptionが発生
InFreePool → DoesNotExist
未使用タイムアウト、経過タイムアウトが発生
Purge PolicyがEntirePoolに設定されている接続プールに対して、StaleConnectionException
が発生（後述）
DataStoreHelperの働き
DataStoreHelper
SQLExceptionが発生すると、SQLCodeとSQLStateを元に、例外の種類を判別するためのマッピン
グ情報を持っています。
例外の種類には、StaleConnectionException、DuplicateKeyExceptionがあります。
com.ibm.websphere.ce.cm.StaleConnectionException
接続が失効したことを意味します。
SQLExceptionの子クラスで、元のSQLExceptionをオーバーライドしています。
接続プールにこの例外が戻ると、Purge Policyにしたがって、接続プール内の接続を操作します。
EntirePool
FailingConnectionOnly
接続プール内にあるInFreePoolの接続オブジェクトを、全てDoesNotExistにマークします。
StaleConnectionExceptionが発生した接続オブジェクトのみを、DoesNotExistにマークします。
マッピング情報
マッピング情報は
情報は各DataStoreHelperクラス
DataStoreHelperクラスの
クラスのJavadocで
Javadocで参照可能
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.javad
oc.doc/public_html/api/com/ibm/websphere/rsadapter/GenericDataStoreHelper.html
(1) エラーが
エラーが発生!!
Connection Pool
JDBC Driver
RDBMS
Application
StaleConnectionException
SQLException
DataStoreHelper
(3) Purge connections!!
Data
SQLException
(2) SQLExceptionのSQLCodeとSQLStateにより
、StaleConnectionExceptionにマッピングする
マッピングする
一般的なデータベース・アクセスにおけるHint & Tips
一般的なデータベース・アクセスにおけるHint & Tips
一般的なJDBC Driver選択基準
動的SQL (JDBC) VS. 静的SQL (SQLJ)
java.sql.Statement VS. java.sql.PreparedStatement
ステートメント・キャッシュによるPrepare処理の省略
グローバル参照 VS. リソース参照
共用可能接続 VS. 共用不可能接続
コンテナー管理認証 VS. アプリケーション管理認証
接続数の制御
接続処理による負荷の軽減
DBサーバー過負荷状態におけるリクエストの抑制
一般的なJDBC Driver選択基準
Type 1以外のJDBC Driverは、RDBMS固有の物を利用します。そのため
多くの場合、RDBMSベンダーから提供されています。
JDBCドライバーを選ぶ際は、機能とパフォーマンスに基づいて選択しま
す。一般的なJDBCドライバーの特長とパフォーマンスは、下記の通りで
す。
Type 1 (JDBC-ODBC Bridge)
Type 2 (Native API Partly)
アプリケーションからJNIを利用して、直接APIを利用します。
アプリケーションと同一筐体にRDBMSが存在する場合に利用します。
一般的には
一般的には、
には、直接API
直接APIを
APIを呼び出す為、機能が
機能が豊富で
豊富で、比較的パフォーマンス
比較的パフォーマンスが
パフォーマンスが良い方法です
方法です。
です。
Type 3 (Net-protocol pure Java)
Protocol変換するのは、ODBCドライバーに依存する、タイミング不明です。
一般的には、最もパフォーマンスが悪い方法です。
アプリケーションはネットワーク経由でリスナーにアクセスします。
リスナーがRDBMSにアクセスし、応答を返します。
一般的には、比較的パフォーマンスが悪い方法です。
Type 4 (Native-protocol pure Java)
Javaのみでコーディングされています。
ドライバーが、RDBMS固有の通信プロトコルに変換します。
一般的には
一般的には、
には、 RDBMS固有
RDBMS固有の
固有のプロトコルを
プロトコルを利用する
利用する為
する為、比較的パフォーマンス
比較的パフォーマンスの
パフォーマンスの良い方法で
方法で
す。
[参考]JDBC Driverが提供する実装
JDBCドライバーは、JDBCで定義されたAPIの実装を提供します。
JDBC APIのインターフェイスは、java.sql.* および、javax.sql.* パッケージに含まれます。
java.sql.*
Connection
に対する接続を抽象化したインターフェイス
主なメソッド
を実行するのに使用されるインターフェイス
主なメソッド
PooledConnection
済SQLを実行するのに使用されるインター
フェイス
Statementインターフェイスを継承
パラメーター・マーカー”?”を使用可能
主なメソッド
executeQuery(), executeUpdate()
接続プールを実装
ユーザーから利用することはない
データ・ソースへの物理接続
XADataSource
ConnectionPoolDataSourceインターフェイスを継承
XAConnectionのファクトリー
主なメソッド
execute(String sql),
executeUpdate(String sql)
close()
Prepare
getConnection()
ConnectionPoolDataSource
PreparedStatement
に対する接続のファクトリー
主なメソッド
RDBMS
SQL
commit()
rollback()
close()
createStatement()
prepareStatement(String sql)
DataSource
Statement
DB
javax.sql.*
getXAConnection()
XAConnection
分散トランザクションをサポートする接続オブジェクト
PooledConnectionを継承
主なメソッド
getXAResource()
CallableStatement
ストアード・プロシージャーを実行するのに使用される
インターフェイス
PreparedStatementインターフェイスを継承
ResultSet
結果セットを表すインターフェイス
主なメソッド
next()
hasNext()
close()
getString(), getObject()….
分散トランザクション
分散トランザクション（
トランザクション（後述）
後述）のために、
のために、WAS内部
で使用する
使用するインターフェイス
するインターフェイスです
インターフェイスです。
です。XAが利用できな
利用できな
いデータベースなどの
データベースなどの場合
などの場合、
場合、これらの実装
これらの実装は
実装は提供さ
提供さ
れません。
れません。
アプリケーションで
アプリケーションで使用する
使用するインターフェイス
するインターフェイスです
インターフェイスです。
です。
動的SQLの実行
動的SQLは実行時にSQLの解析を行います。
多くのRDBMSは、SQLのPrepare処理の結果作成された実
行計画をキャッシュします。
再度同じ
再度同じSQLを
SQLをPrepare処理
Prepare処理するように
処理するように要求
するように要求されると
要求されると、
されると、キャッ
シュを
シュを検索して
検索して同
して同じものがあれば、
じものがあれば、それを利用
それを利用することで
利用することで実
することで実
行計画を
行計画を決定する
決定するプロセス
するプロセスを
プロセスを省略します
省略します。
します。
JDBC Application
RDBMS
connection.prepareStatement(sql)
Prepare
(Parse)
構文チェック
セキュリティ・チェック
prepareStatement.executeQuery()
Execute
キャッシュの検索
実行計画の決定
resultSet.next()
resultSet.getXXXX()
Fetch
実行計画を
キャッシュから再利用
実行計画を
キャッシュに保存
DB2におけるSQLJアプリケーション開発フロー
SQLJを利用すると静的SQLを利用できます。
SQLに関する情報を事前にBINDすることで、実行時にSQLを解析す
る必要がありません。
開発者は、SQLJのソース・コー
ド(*.sqlj)を記述します。
RDBMSベンダーが提供する
SQLJトランスレーター(DB2
UDBの場合sqljコマンド)を利用
して、プリ・コンパイルすると、
Javaソース・コードと、SQLJプロ
ファイル(DB2 UDBの場合、
*.ser形式)が生成されます。
RDBMSベンダーが提供する
SQLJプロファイルBinder(DB2
UDBの場合db2sqljcustomizeコ
マンドやdb2sqljbindコマンド)を
利用して、BINDします。このとき
*.seｒファイルには、BIND情報が
更新されます。
Javaソース・コードは、通常通り
コンパイルしてできた*.classファ
イルを、配布します。また、
SQLJプロファイルは実行時に
も必要なので、*.classと一緒に
配布します。
SQLJ source
*.sqlj
開発者がコーディング
precompile
SQLJ translator
[ sqlj ]
SQLJ profile
*.ser
customize
bind
Generated Java
files
*.java
compile
Java compiler
SQLJ profile printer
[ db2sqljprint ]
Text output
Profile customizer
[ db2sqljcustomize]
bind (auto)
SQLJ profile binder
[ db2sqljbind ]
RDBMS (DB2)
package
Class files
*.class
実行時に必要
アクセス・プランなどの情報を含む、DB2側のオブジェクト。
SQLJ profileをBINDすると生成されます。
動的SQL (JDBC) VS. 静的SQL (SQLJ)
動的SQL
動的SQL (JDBC)
実行前
実行時
実行前
Precompile
Compile
Bind
実行時
Parse
Execute
Fetch
静的SQL
静的SQL (SQLJ)
Compile
Execute
Fetch
どちらの方法
どちらの方法で
方法でコーディングしても
コーディングしても、
しても、JDBCドライバー
JDBCドライバーを
ドライバーを利用して
利用してRDBMS
してRDBMSに
RDBMSに接続し
接続し
ます。
ます。
SQLJでは
SQLJでは事前
では事前に
事前にBindしておくことで
Bindしておくことで、
しておくことで、実行時に
実行時にParse処理
Parse処理を
処理を行わない分
わない分、高速に
高速に
SQLを
SQLを実行できます
実行できます。
できます。
SQLJの
SQLJのソースが
ソースが変更になるたびに
変更になるたびにBind
になるたびにBind処理
Bind処理を
処理を行う必要があるので
必要があるので、
があるので、アプリケー
ションの
ションのバージョン管理
バージョン管理は
管理は、SQLJの
SQLJの方が複雑になります
複雑になります。
になります。またアプリケーション
またアプリケーションの
アプリケーションの
開発者は
開発者は、Javaの
Javaの文法の
文法の他に、SQLJ固有
SQLJ固有の
固有の構文を
構文を理解する
理解する必要
する必要があります
必要があります。
があります。
java.sql.Statement VS. java.sql.PreparedStatement
PreparedStatementを利用することで、Prepare済のステート
メントを再利用できます。
HEAVY
JDBC Application
RDBMS
java.sql.Statement
文を実行する度に、SQLが
されます。
connection.createStatement()
Prepare
statement.executeQuery(sql)
Execute
resultSet.hasNext() resultSet.next()
resultSet.getXXXX()
Fetch
connection.preapreStatement(sql)
Prepare
preparedStatement.executeQuery()
Execute
resultSet.hasNext() resultSet.next()
resultSet.getXXXX()
Fetch
SQL
Parse
java.sql.PreparedStatement
回 されたSQLを、何回も実
行できます。これにより、RDBMSに
かかるParseの負荷を軽減できます。
特にデメリットはありませんので
デメリットはありませんので、
はありませんので、
コーディング上
コーディング上はこの
PreparedStatementを利用してく
利用してく
ださい
1 Parse
ステートメント・キャッシュによるPrepare処理の省略
アプリケーションからprepareを要求すると、ステートメント・キャッシュに同じSQL文が存在す
るか、検索します。
存在した場合、キャッシュ内のPreparedStatementを再利用します。
存在しなかった場合、Prepareを要求します。
PreparedStatementは、トランザクション終了時にキャッシュに戻ります。
ステートメント・キャッシュは、接続オブジェクト毎に用意されます。
ステートメント・
ステートメント・キャッシュ・
キャッシュ・サイズの
サイズの有効性は
有効性は、RDBMSの
RDBMSの種類や
種類や設定によって
設定によって異
によって異なります。
なります。
Application Server
RDBMS
JDBC Application
Prepare
connection.preapreStatement(sql)
Statement Cache
キャッシュに
キャッシュにHitしなかった場
しなかった場
合のみ、
のみ、Prepareを行います。
います。
preparedStatement.executeQuery()
Execute
resultSet.next()
resultSet.getXXXX()
Fetch
Tivoli Performance Viewer (TPV)による監視
TPVを使うと、破棄されたPreparedStatementの数を確認することができます。
この数が極端に多い場合には、ステートメント・キャッシュ・サイズを大きくすることを検討してください。
ステートメント・キャッシュが利用するHeapの量は、それほど多くありませんが、変更後は必ず負荷テストを行ってく
ださい。
ステートメント･キャッシュ再利用の条件
SQLの文字列が全く同じである必要があります。
1文字でも異なると判断されると、再利用されません。次のような場合
にも、異なると判断されます。
列名指定順の違い
大文字と小文字の違い
空白文字数の違い
connection.prepareStatement()で指定する引数が同じである
必要があります。
resultSetType, resultSetConcurrency, resultSetHoldabilityが同じで
ある必要があります。
グローバル参照 VS. リソース参照
グローバル参照
グローバル参照
(例) ctx.lookup(“jdbc/dataSourceName”);
AS上に定義したデータ・ソースを、アプリケーションで直接lookupする方法です。
J2EEでは非推奨です。できる限りリソース参照を利用してください。
実行時にアクセスするデータ・ソースが決定する場合など、特殊なケースでのみ使用してください。
リソース参照
リソース参照
通常はこの
通常はこの、
はこの、リソース参照
リソース参照を
参照を利用してください
利用してください。
してください。
AS上に定義したデータ・ソースに対して、デプロイメント記述子でリソース参照を定義します。アプリ
ケーションでは、リソース参照をlookupします。
(例) ctx.lookup(“java:comp/env/resrefName”);
DataSourceの各種設定を変更できます。
デフォルトの分離レベル
Container
Application
デフォルトでは共用可能です。
SQL文で分離レベル指定を行わない場合に、この分離レベルが適用されます。
これを設定しないと、デフォルト値はTRANSACTION_REPEATBLE_READです。
認証方法
共用可能 (Sharable) / 共用不可能 (Unsharable)
グローバル参照
グローバル参照で
参照でlookup
Application Server
ctx.lookup(“jdbc/dataSourceName”)
Enterprise Application
Class
Deployment Descriptor
Resource
Reference
リソース参照
リソース参照で
参照でlookup
ctx.lookup(“java:comp/env/resrefName”)
Data Source
RDBMS
[参考]分離レベルについて
JDBCでは、トランザクションの分離レベルが4種類定義されています。こ
の分離レベルは、DB2の分離レベルとは異なるので注意してください。
JDBC
TRANSACTION_SERIALIZABLE
TRANSACTION_REPEATABLE_READ
TRANSACTION_READ_COMMITED
TRANSACTION_READ UNCOMMITED
S
RR
RC
RU
DB2
Repeatable read
Read stability
Cursor stability
Uncommited read
RR
RS
CS
UR
CMPの分離レベルは、リソース参照のデフォルト分離レベルではなく、ア
クセス・インテントに従って決定されます。
分離レベル
分離 レベル
アクセス・
アクセス ・ インテント・
インテント ・ プロファイル
wsPessimisticUpdate- Weakest
LockAtLoad (デフォルト・ポリシー)
wsPessimisticUpdate
wsPessimisticRead
wsOptimisticUpdate
wsOptimisticRead
wsPessimisticUpdate-NoCollisions
wsPessimisticUpdate-Exclusive
更新ロック
更新 ロック
DB2
Oracle
SyBase
Informix
Cloudsca
pe
SQL
Server
RR
RC
RR
RR
RR
RR
RR
RR
RC
RC
RC
S
RC
RC
RC
RC
RC
S
RR
RR
RC
RC
RC
S
RR
RR
RC
RC
RC
S
RR
RR
RC
RC
RC
S
RR
RR
RC
RC
RC
S
No ※Oracle
のみYes
Yes
No
No
No
No
Yes
共用可能接続 VS. 共用不可能接続
Class A
共用可能接続
同じトランザクション・スコープ内で、getConnection()を
呼び出すと、リソース参照の設定が同じ場合、毎回同
じ接続が取得できます。
物理接続 : 接続オブジェクト = 1 : N
get/use/closeパターンでコーディングしてください。
グローバル・トランザクション内でcloseしても、スコープを抜けるま
で接続オブジェクトはFreePoolに戻りません。
ただし、
ただし、接続オブジェクト
接続オブジェクトの
オブジェクトのプロパティ（
プロパティ（例えば分離
えば分離レベル
分離レベル）
レベル）を変更
すると、
すると、SharingViolation例外
SharingViolation例外が
例外が発生します
発生します。
します。
get/use/closeパターンは、利用時に接続オブジェクトを取得し、利
用終すぐに解放するコーディング方法です。
基本的には
基本的には利用
には利用しないでください
利用しないでください。
しないでください。
グローバル・トランザクション利用時に、1 Phase
Commit最適化を起こりやすくする為に使ってください。
共用不可能接続
通常はこちらを
通常はこちらを使
はこちらを使ってください。
ってください。
毎回異なる接続オブジェクトが取得できます。
グローバル・トランザクション内で接続オブジェクトをcloseすると、
接続オブジェクトはグローバル・トランザクションの終了を待ちます。
物理接続 : 接続オブジェクト = 1 : 1
アプリケーション・コード内で、接続オブジェクトをキャッ
シュする場合に有効です。
Class B
共用
Transaction
Scope
get
Connection
Pool
use
close
Class C
get
use
close
Class A
Class B
共用不可能
Transaction
Scope
get
use
close
Class C
get
use
close
Connection
Pool
コンテナー管理認証 VS. アプリケーション管理認証
コンテナー管理認証
J2EEでは非推奨です。アプリケーション管理認証を利用してください。
データソースのコンテナー管理認証別名を使って、RDBMSにアクセスします。
コンテナー管理認証別名は、クライアント・コンテナー、もしくは別セル内の
サーバーで稼動するアプリケーションからも利用できる為、セキュリティー上
好ましくない場合があります。
アプリケーション管理認証
アプリケーション管理認証
データソースのコンポーネント管理認証別名を使って、RDBMSにアクセスし
ます。
コンポーネント管理認証別名は、アプリケーション・サーバーにインストールし
たアプリケーションから利用できます。クライアント・コンテナー、もしくは別セ
ル内のサーバーで稼動するアプリケーションからは利用できません。
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/co
m.ibm.websphere.base.doc/info/aes/ae/cdat_seccon.html
接続数の制御
最大接続数
最小接続数
ピーク時に1ASがデータベースへのアクセス数を設定してください。ただし、接続先RDBMSの許容量を超えるように
は設定しないでください。
最大接続数と同じ数に設定すると、使用されない接続が確立されたままになります。これにより、DBサーバーのリ
ソース解放のタイミングを逃すことになります。
定常状態の接続数を設定してください。基本的にはリソースの解放が目的ですが、特別な理由がない限り0には設
定しない方が良いです。定期的
定期的な
定期的なリソース解放
リソース解放が
解放が目的の
目的の場合には
場合には、
には、経過タイムアウト
経過タイムアウトを
タイムアウトを利用してください
利用してください。
してください。(DB2
UDBを
UDBを例にとって後述
にとって後述します
後述します。
します。)
未使用タイムアウト
最小接続数までリソースを解放する為に設定します。特別な理由により、使用しない接続の解放を強いられていな
いのであれば、初期値より短く設定する必要はありません。
実際に接続オブジェクトが解放されるのは、リープ処理のタイミングであることに注意してください。
Application
Application
最大接続数 = 10
最小接続数 = 5
Connection Pool
最小接続数を超えて
いる場合のみ、未使
用タイムアウトによる
切断対象になる
Tivoli Performance Viewer (TPV)による監視
TPVを使うと、接続プールの利用状況を確認できます。
接続プールを使い切っていて、且つ接続タイムアウトが多発しているような場合、最大接続数を増やすことで、接続
タイムアウトを減らすことができるかもしれません。RDBMSの負荷との兼ね合いともあるので、よく検討してチューニ
ングしてください。
WAS V6 NEW!!
接続処理による負荷の軽減
RDBMSに対して、同時に大量の接続要求を行うと、RDBMS
側のリソース割り当てがうまく行かず、接続処理の効率が悪
化する可能性があります。
これを回避する為に、WAS 6では接続プールの拡張設定とし
て、サージ保護に関する機能が追加されました。
設定項目
サージしきい値
同時に行っている接続要求がこのしきい値を超えると、サージ・モードが開始しま
す。
サージ作成間隔
サージ・モードが有効なときに、接続要求を発行する間隔を設定します。
WAS V6 NEW!!
DBサーバー過負荷状態におけるリクエストの抑制
過負荷に陥っているRDBMSに対して、更に処理を要求すると、全てのリ
クエストの処理効率が低下する可能性があります。
これを回避する為に、WAS 6では接続プールの拡張設定として、滞留
モードに関する機能が追加されました。
設定項目
滞留タイマー時間
滞留時間
リソースからレスポンスが戻るまでの待ち時間を設定してください。この時間を超えると、その
接続は滞留接続であると判定されます。
滞留しきい値
滞留状態をチェックする間隔を設定します。
滞留接続数がこのしきい値を超えると、接続プールは滞留状態になります。
滞留状態
滞留状態でgetConnection()を呼び出すと、
javax.resource.ResourceExceptionが発生します。アプリケーションは、この例
外を受け取ったら、RDBMS負荷を回避する為の対応を行うことで、効率的に
サービスを提供できます。
画面に「しばらくお待ちください」などのメッセージを表示して、ユーザーに待機を促すことで、
アプリケーション・サーバーに対する余計な負荷を回避できます。
DB2接続
ここからはDB2への接続に関するHint ＆ Tipsを紹介します。
DB2 UDB for LUW (Linux, Unix and Windows)
DB2 for z/OS using DB2 Connect
DB2 for z/OS using Universal JDBC Driver Type 4
DB2 UDB for LUW
WASとDB2 UDBが同一筐体内に導入されている場合は、Universal
JDBC Driver Type2を利用します。
別筐体に導入されている場合は、2つの接続方法があります。
Type 4による接続
直接接続できるため高速です。
Type 2によるClient Instance経由での接続
Application Server
Data Source
DB2 UDB
JDBC Driver
Type 2
Application Server
Data Source
DB2 UDB
JDBC Driver Type 4
DB2 for z/OS using DB2 Connect
DB2 for z/OS Version 7までは、TM (Transaction Manager)がWASの環
境でDB2 for z/OSをRM (Resource Manager)として利用する為には、
DB2 Connectによってプロトコル変換を行う必要がありました。
DB2 Connectはプロトコル変換に関する情報をSPMログに書き出します。
XAトランザクションを利用する場合、リカバリーの為にSPMログが必要で
す。
Application Server
Data Source
DB2 Connect
JDBC Driver
DB2 for z/OS
Type 2
SPM log
Application Server
Data Source
DB2 Connect
JDBC Driver Type 4
SPM log
DB2 for z/OS
DB2 for z/OS using Universal JDBC Driver Type 4
DB2 for z/OSは、Version 8からXAプロトコルに（一部）対応しました。
※詳細は「DRDA 2005 WAS - DB2 for z/OS連携ワークショップ」の資料
を参考にしてください。
その為Universal JDBC Driver Type 4を利用してDB2 for z/OSへの直接
接続した場合にも、XAが利用可能です。
Universal JDBC Driverには、Connect Instanceで行っていた接続プール
や、Sysplex Exploitation機能が実装されています。
新機能であるため、この構成はまだ適用されていませんが、SPMログが
必要ないなど、Connect Instanceを利用するよりも格段に構成をシンプル
にできます。
Application Server
DB2 for z/OS
Data Source
JDBC Driver Type 4
Connect to DB2 UDB for LUW
(Linux, Unix and Windows)
JDBC Driver選択基準
WASとDB2が同一筐体の場合は、Universal JDBC Driver Type 2を利用してくだ
さい。
CLI Driverは今後更新されず、廃止される予定です。
Type 4はTCP/IPを利用するのに対して、Type 2はメモリー間通信を行うので、一般的
に高速です。
別筐体の場合は、次の2つの選択肢があります。
Type 2 DriverでDB2 Client経由で接続
Type 4 Driverで直接接続 ← 直接接続できる為、一般的に高速
Application Server
Data Source
DB2 Client
JDBC Driver
Type 2
Catalog
DB2 UDB
[target]
Application Server
Data Source
JDBC Driver Type 4
DB2 UDB
[target]
DBサーバーのリソース解放
WASがPreparedStatementをステートメント・キャッシュに保持するのに対して、DB2ではSQLをParseした
結果（実行計画）をPackage Cache内にあるPackageのSectionに保持します。
多くの種類のSQLを利用するアプリケーションでは、applheap（アプリケーション・ヒープ）を多く消費する
傾向があります。公式な情報ではありませんが、下記のように動作しているようです。
Package名はデータ・ソースの拡張設定で設定可能です。
SQL実行時には、Sectionの情報をapplheapに読み込みます。
アプリケーションからPrepare要求が届くと、applheapに読み込まれているSectionについては、そのまま実行されま
す。
接続を切断すると、applheapを解放できます。
経過タイムアウト
経過タイムアウトで
タイムアウトで一定時間毎に
一定時間毎に接続を
接続を解放することで
解放することで、
することで、applheapなどの
applheapなどのdb2agent
などのdb2agentが
db2agentが利用する
利用するヒープ
するヒープ領
ヒープ領
域を定期的に
定期的に解放できます
解放できます。
できます。
Application Server
DB2
DataSource
Connection Pool
JDBC Driver
Statement
Cache
db2agent
applheap
Package
Section
db2agent
Statement
Cache
Package Cache
applheap
Section
Section
Section
Section
DataStoreHelper
Table
Statistics
DBサーバーへの接続負荷の軽減
接続プールを利用することで接続負荷を軽減できるのは、前
述の通りです。
しかし、前項で述べたとおり、リソースを定期的に解放するた
めには、接続を切断する必要があります。
接続を要求されると、接続処理の負荷がサーバーにかかります。
前述の通りWAS 6では接続プールの拡張機能として、サー
ジ保護と滞留モードが追加されました。
サージ保護
サージ保護を
保護を利用することで
利用することで、
することで、接続要求がまとまって
接続要求がまとまってDB
がまとまってDBサーバー
DBサーバーに
サーバーに
飛ばないように制御
ばないように制御できます
制御できます。
できます。これにより接続処理
これにより接続処理（
接続処理（db2agentの
db2agentの初期
化）において、
において、リソース割
リソース割り当てが競合
てが競合することによる
競合することによるDB
することによるDBサーバー
DBサーバーの
サーバーの
負荷を
負荷を軽減できます
軽減できます。
できます。
滞留モード
滞留モードを
モードを利用すると
利用すると、
すると、高負荷状態の
高負荷状態のDBサーバー
DBサーバーに
サーバーに、それ以上
それ以上の
以上の
処理を
処理を要求しないように
要求しないように制御
しないように制御できます
制御できます。
できます。
Client Reroute 利用時の考慮点
機能説明
接続先DBに障害が発生した時、Client側で接続先を切り替える機能です。
コードでリトライロジックを記述する必要があります。
接続先の切り替えが完了すると、クライアントにはSQLCode -30108（Client
Instanceによって切り替えた場合）、もしくは-4498（Type 4ドライバーによって
切り替えた場合）が発生します。
① 障害が発生
② Client Reroute機能により、代替サーバー(Alternate Server)に再接続
③ アプリケーションに-30108、もしくは-4498が戻ります。
この例外はStaleConnectionExceptionにマッピングされない為、接続プール
内のすべての接続オブジェクトで、Client Rerouteが発生することになります。
PK06078
-30108と-4498がStaleConnectionExceptionにマッピングされるようになりま
す。
Purge PolicyをEntierPoolに設定しておくことで、1つの接続オブジェクトで
Client Rerouteが発生すると、InFreePoolの接続オブジェクトをすべて解放で
きます。
1
JDBC Driver
JDBC Application
DB2
DB2 Client
3
2
DB2
64bitインスタンスへの接続方法
DB2 64bitインスタンスを利用するメリット
巨大なメモリー空間を利用可能になります。
これによりDB2は大きいバッファープールを作成可能になり、処理が高速になりま
す。
同一筐体でWASが64ビットで稼動している場合は、Type 2ドライバー
を使って、DB2の64ビットインスタンスに接続できます。
同一筐体でWASが稼動している場合でも、WASが32ビットで稼動して
いる場合は、Type 2接続は利用できません
32ビットのWASから、64ビットのDB2に接続する方法
Client Instanceを経由させる
WASからは32ビットのClient Instanceに接続し、Client InstanceでDBをカタログさ
せることで、接続可能です。
Type 4ドライバーを利用する
Type 4ドライバーはTCP/IPを利用するため、64ビット・インスタンスに対しても接
続可能です。
同一筐体内に2つのDB2インスタンス
DBを移行する際、2つのバージョンのDB2インスタンスに対して、接続し
たい場合、1つのサーバーから同時に、2つのDB2インスタンスにType 2
接続に、Type 2接続することはできません。
これはType 2接続ではネイティブ・ライブラリーがDB2のバージョンごとに
違う為です。
Type 2接続を続ける場合、WASのサーバーは最低でも2つ起動する必要が
あります。
Nodeagent起動時にdb2profileを読み込ませている場合、それぞれのサー
バーに適切なネイティブ・ライブラリーを読み込ませることができない場合が
あります。
Nodeagent起動時にはdb2profileを読み込ませず、サーバーごとに、適切
な「環境エントリー」を設定することで、上記問題を回避できます。
DB2INSTANCE
DBインスタンス名を設定します。
LIBPATH
DB2_INSTANCE_USER_HOME_DIRECTORY/sqllib/lib を設定します。
Connect to DB2 for z/OS
using DB2 Connect
XA利用時の考慮点
In-doubtトランザクションのリカバリー
XAはPresumed Nothing
DRDA XAはPresumed Abort
Phase 1 request (prepare)前にTMがlogを書き出す為、TMは再同期が必要である
かどうかを把握します。
Phase 1 request (prepare)前にARがlogを書き出さない為、ARは再同期が必要で
あるかどうか把握しません。
DB2 for z/OSトランザクション
z/OSトランザクションの
トランザクションのリカバリー要求
リカバリー要求は
要求はDB2 for z/OSから
z/OSから発行
から発行されるこ
発行されるこ
とがあるため、
とがあるため、リカバリー計画時
リカバリー計画時には
計画時には、
には、DB2 Connectと
Connectと合わせて考慮
わせて考慮する
考慮する必要
する必要が
必要が
あります。
あります。
Sysplexによるデータ共用環境において、負荷分散機能としてSysplex
Distributor（後述）だけを利用すると、インダウトの解決は保障されま
せん。
Application Server
DB2 Connect
TM
(Transaction Manager)
DB2 for z/OS
RM
(Resource Manager)
Presumed Nothing
Presumed Abort
AR
(Application Requester)
AS
(Application Server)
WASとDB2 Connectの接続プールの関係
WASの接続プール機能の他に、DB2 ConnectとDB2 for
z/OSでも、独自のプーリング機能があります。
DB2コネクトのConnection Pooling および Connection Concentrator
一度確立された接続を保持することで、DB2 for z/OSへの接続の確立と切断に
要する負荷を削減できます。
DB2/zのThread Pooling
DB2コネクトからの大量の接続を可能にしつつ、DB2 for z/OS内でメモリを消費す
るスレッドの数を削減できます。
Application Server
Application
Connection Pool
WAS
Connection Pool
DB2 Connect
Connection
Agents
DB2 Connect
Connection Pool
& Concentrator
DB2 for z/OS
DDF
DBM1
DB2 for z/OS
Thread Pool
Execute
SQL
DB2 Connectの接続プール機能
利用し終わったdb2agentをプーリングすることで、プロセス初期化の負荷
を軽減できます。
db2agentはDB2 for z/OS側にあるDDF上のスレッド（コネクション）と接続
を保ちます。
クライアント側は、接続数がMAX_CONNECTIONSになるまで、接続でき
ます。
db2agent数は通常、num_poolagent以下にはなりません。
DB2 Connectのヘルス・モニターが、プールされたdb2agentをDB2/zの監視
に利用することがあります。ヘルス・モニターはdb2agentを使用後、解放しま
す。
ヘルス・モニターはデフォルトでONに設定されています。
WASの
WASの接続プール
接続プールと
プールとDB2 Connectの
Connectの接続プール
接続プールを
プールを併用すると
併用すると、
すると、接続の
接続の管
理が複雑になります
複雑になります。
になります。以降で
以降で解説する
解説するDB2
するDB2 Connectを
Connectを利用した
利用した負荷分散
した負荷分散
機能を
機能を利用しない
利用しない場合
しない場合は
場合は、DB2 Connectの
Connectの接続プール
接続プールを
プールを利用する
利用する必要
する必要
はありません。
はありません。
Idle thread timeout利用時の考慮点
DDFに接続要求が届くと、スレッド・プール内のInactive Thread (RA)と1:1で結びつき、Active Thread
(DA)になります。
KEEPDYNAMIC(NO)に設定されていないと、ConnectionとDBATは切り離されないため、DBATがInactive
になることはありません。
with hold (holdability=true)指定されたCursorが開いたままだと、トランザクションが終了してもDBATは
Inactiveになりません。
サブシステム・パラメーター：CMTSTAT=INACTIVEに設定することで、スレッド・プールが利用可能になります。
DDF内のThreadは、DB2 for z/OS Version 8から、Connectionと呼ばれるようになりました。
必要な
必要な場合のみ
場合のみ、
のみ、holdabilityを
holdabilityをtrueにして
trueにしてSQL
にしてSQLを
SQLを発行してください
発行してください。
してください。
holdability=trueで
holdability=trueで得られた結果
られた結果セット
結果セットは
セットは、確実に
確実に解放してください
解放してください。
してください。
DBATがアクティブなまま、IDTHTOINで指定した時間を超えると、スレッドはPooled DBATに戻されます。
CMTSTAT=INACTIVE
DDF
DBM1
DBAT (Database Access Thread)
Inbound Connection
Active Connections
Active DBAT (RA)
R2
Inactive Connections
Pooled DBAT (DA)
IDTHTOIN=****
Idle thread timeout利用時の考慮点
スレッドがActiveかつIdle状態のまま、Idle thread timeoutで指定した時間
経過すると、スレッドは破棄されます。
データ・ソースのカスタム・プロパティーで、
retrieveMessagesFromServerOnGetMessage=trueに設定していると、
IDLE_THREAD_TIMEOUTによってRollback Pending状態になったトランザク
ションを利用して、ストアード・プロシージャーを呼び出してしまうため、複数の
例外が発生してしまいます。
retrieveMessagesFromServerOnGetMessage=false
retrieveMessagesFromServerOnGetMessage=falseに
=falseに設定することで
設定することで、
することで、この
問題は
問題は回避できます
回避できます。
できます。
InFreePool状態の接続先のスレッドで、Idle Thread Timeoutが発生する
問題が発生しました。
次のようなケースでInFreePool状態の接続先スレッドがActiveになる可能性
があります。
JDBC関連オブジェクトの解放が正しく行われなかった場合。
グローバル・トランザクション内でgetConnection()したものの、その接続を利用してSQLを発行
せずに、接続を解放した場合
最小接続数=0
最小接続数=0、
未使用タイムアウト<IDTHTOIN
設定することで回避
=0、未使用タイムアウト
タイムアウト<IDTHTOINに
<IDTHTOINに設定することで
することで回避できま
回避できま
す。
非常に
非常に特殊な
特殊なケースです
ケースです。
です。通常は
通常はIdle thread timeoutが
timeoutが発生するのは
発生するのはInUse
するのはInUse
の接続だけです
接続だけです。
だけです。同様の
同様の問題が
問題が発生して
発生して緊急
して緊急に
緊急に対処が
対処が必要な
必要な場合に
場合に適用し
適用し
てください。
てください。
ステートメント・キャッシュの必要性
DB2 for z/OSにおける2種類のキャッシュ機能
Global Cache
Local Cache
スレッドごとにPrepare済のSQLをキャッシュします。
DB2 for z/OSのスレッド・プールを利用する環境では、あるアプリケーションが同じスレッドを
利用するとは限らない為、Local Cacheの効果は見込めません。
DB2 Connectによる負荷分散機能（Sysplex Exploitation、Connection Concentrator）を利用
する場合は、KEEPDYNAMIC(NO)に設定するため、利用できません。
ステートメント・
ステートメント・キャッシュが
キャッシュが有効なのは
有効なのはKEEPDYNAMIC=YES
なのはKEEPDYNAMIC=YESの
KEEPDYNAMIC=YESの環境です
環境です。
です。
NOの
NOの場合はあまり
場合はあまり効果
はあまり効果が
効果が見込めません
見込めません。
めません。デフォルトは
デフォルトは
KEEPDYNAMIC=NOで
KEEPDYNAMIC=NOで、YESに
YESに変えるにはDB2Binder
えるにはDB2Binderコマンド
DB2Binderコマンドを
コマンドを使います。
います。
メンバーごとにPrepare済のSQLをキャッシュします。
SQLがGlobal Cacheに存在する場合、Short prepareになります。Short prepare (10-50K
Introductions)はFull prepare (500K Introductions)よりも大幅にprepareの時間を短縮できます。
(例) > java com.ibm.db2.jcc.DB2Binder -url
jdbc:db2://9.170.1.14:8181/KOARA -collection DB2013 -user DB2013 password DB2013 -keepdynamic yes
DB2 for z/OSにおけるキャッシング機能の詳細については「DRDA 2005
WAS - DB2 for z/OS連携ワークショップ」の「DRDAのPerformance関連
機能」の資料を参照してください。
Sysplexとデータ共用
DB2/zをSysplex構成にすることで、複数のメンバーへの負
荷分散が可能です。
OSやCPU障害時にFail overが可能です。
データ共用
データ共用グループ
共用グループ
z/OS System A
WLM Information
TCP/IP Stack
NI
DB2 for z/OS
Subsystem 1
DB2 for z/OS
Subsystem 2
Static VIPA
NI
DB2 Connect
or
Universal JDBC
Driver
Sysplex
Exploytation
SYSPLEX
Dynamic
VIPA
Database
CF
Connection
Concentrator
TCP/IP Stack
NI
NI
WLM Information
z/OS System B
DB2 for z/OS
Subsystem 1
DB2 for z/OS
Subsystem 2
DB2 Connectによる負荷分散機能利用時の考慮点
Sysplex Exploitation
負荷情報を取得するのは、新規に接続を確立する時です。
次のような条件があります。
DB2 Connectの接続プール機能を利用する必要があります。
KEEPDYNAMIC=NOに設定する必要があります。
経過タイムアウト
経過タイムアウトを
タイムアウトを利用して
利用して、
して、一定時間ごとに
一定時間ごとに接続
ごとに接続を
接続を切断することで
切断することで、
することで、
負荷の
負荷の均一化できます
均一化できます。
できます。
Connection Concentrator（+Sysplex Exploitation）
負荷情報を取得するのは、トランザクション完了時です。
KEEPDYNAMIC=NOに設定する必要があります。
Sysplex Exploytationとは違い、一定時間ごとに切断する必要はあり
ません。
VIPAによる高可用性機能利用時の考慮点
VIPA (Virtual IP Address)
Static VIPA
Dynamic VIPA
Static VIPAの機能に加えて、Sysplex構成されたメンバーに、TCP/IPスタックを引き継ぐ機能
です。TCP/IPスタックの障害に対応できます。
障害時には、DB2 Connectとの接続が一度切断されます。
Member specific DVIPA
物理インターフェイスを多重化できます。動的ルーティングと併用します。
Sysplex構成されたメンバーをまたがって、TCP/IPスタックを引き継ぐ機能ではありません。
障害時に引継ぎが発生しても、基本的にDB2 Connectとの接続は切断されませんが、切断さ
れる可能性が無いわけではありません。
DVIPAによってサブシステム毎に固有のIPを割り当てます。
サブシステムのCPUなどに障害があった時にも、データ共用グループ内の別システムにFail
overします。
VIPAを
VIPAを利用すると
利用すると、
over時にStaleConnectionExceptionが
StaleConnectionExceptionが発生する
発生する可能
すると、Fail over時
する可能
性があります。
があります。接続プール
接続プールの
プールの設定で
設定で、Purge Policyを
PolicyをEntirePoolに
EntirePoolに設定してく
設定してく
ださい。
ださい。アプリケーションは
アプリケーションはStaleConnectionExceptionの
StaleConnectionExceptionの扱いを検討
いを検討してくだ
検討してくだ
さい。
さい。
Sysplex Distributorによる初回接続の可用性
Sysplex Distributor
TCP/IPスタックを2重に用意して、Distributed StackとTarget Stackを分割し
ます。
Distributed Stack
DVIPAを割り当てる為、別のTCP/IPスタックにFail overできます。
クライアントからの接続要求を受け付け、負荷の小さいTarget Stackに割り振ります。
割り振りをCF (Coupling Facility)経由で行う為、毎回Distributed Stackを経由すると、XCF (CrossSystem Coupling Facility)に大きな負荷がかかります。
Target Stack
Member specific DVIPAで割り当てたTCP/IPスタック
Sysplex Exploitationを
Exploitationを利用している
利用しているクライアント
しているクライアントは
クライアントは、一度Target
一度Target Stackに
Stackに接続すると
接続すると、
すると、それ以降
それ以降
Distributed Stackには
Stackにはアクセス
にはアクセスしません
アクセスしません。
しません。これにより、
これにより、XCFの
XCFの負荷を
負荷を軽減できます
軽減できます。
できます。その為
その為、Sysplex
Distributorを
Distributorを利用する
利用する場合
Exploitationを有効にしてください
有効にしてください。
する場合は
場合は、Sysplex Exploitationを
にしてください。
z/OS System B
TCP/IP Stack
Distributed
DVIPA
Sysplex
Exploytation
DB2 Connect
or
Universal JDBC
Driver
DB2 for z/OS
Subsystem 1
Target
DVIPA
XCF
CF
Distributed
DVIPA
Target
DVIPA
TCP/IP Stack
z/OS System B
Database
DB2 for z/OS
Subsystem 2
Sysplex Distributor
Sysplex Distributor
単体での利用は推奨されておらず、Sysplex Exploitation（Connection
Concentrator）と併用されるのが一般的です。
Sysplex Distributor単体で利用すると、DB2 Connectが接続先を特定しない為、
In-doubtトランザクションが回復できない場合があります。
Sysplex Exploitationと併用するとでは、Fail over後も同じメンバーに接続するため、
In-doubtトランザクションが回復できます。
初めて接続を要求するときに、メンバーに障害があっても、正常に接
続できます。（初回冗長性あり）
接続要求はSysplex Distributorが提供するIP（Distribution Stack）に
送信しますが、実際に接続が確立されるのは、DVIPAが提供するIP
（Target Stack）です。Sysplex Exploitationを利用した場合は、その後
の処理要求は直接Target Stackに送ります。
Sysplex Distributor利用時
Distributor利用時は
利用時は、Sysplex Exploitationを
Exploitationを利用す
利用す
ることをお勧
ることをお勧めします。（
めします。（後述
。（後述の
後述のUniversal JDBC Driverの
Driverの時
も同様です
同様です。）
です。）
Connect to DB2 for z/OS
using DB2 Universal JDBC Driver Type 4
DB2 V.8.2 NEW!!
Universal JDBC Driverのコンポーネント
Universal JDBC Driverは、DB2 Connectが提供する負荷分
散機能を提供します。
接続プール機能
Sysplex Workload Balancing
Global Transport Object Poolが、db2agentと同等の働きをします。
DB2 ConnectのSysplex Exploitationと同等の機能を提供します。
Connection Concentrator
DB2 ConnectのConnection Concentratorと同等の機能を提供します。
JDBC Driver
Connection Pool
Physical Connection
Global Transport
Object Pool
DB2 for z/OS
DDF
DBM1
DB2 V.8.2 NEW!!
利用条件
DB2 UDB Connect for LUW FixPack 10
WebSphere Application Server バージョン5.1 以上
DB2 Universal JDBC Driverのバージョン
> java com.ibm.db2.jcc.DB2Jcc –version
IBM DB2 JDBC Universal Driver Architecture xxxx
⇒ xxxxが2.7以上であること
WLM for z/OS
DB2 UDB for OS/390® and z/OS バージョン7 以上
DB2 for z/OS 8より前のバージョンでは、XAをサポートしません。
DB2 V.8.2 NEW!!
設定方法
FixPack 10から使用できる新しいプロパティ
DB2 Universal JDBCドライバー
構成プロパティ
（DB2JccConfiguration.propertiesに記述）
db2.jcc.dumpPool
db2.jcc.dumpPoolStatisticsOnSchedule
db2.jcc.dumpPoolStatisticsOnScheduleFile
db2.jcc.maxTransportObjectIdleTime
db2.jcc.maxTransportObjectWaitTime
db2.jcc.maxTransportObjects
db2.jcc.minTransportObjects
省略時値
0 （サマリーの
み）
-1 （統計は作
成しない）
（統計は作成し
ない）
説明
グローバル・トランスポート・プール・イベントの統計のタイプを指定
グローバル・トランスポート・プールの統計が、db2.jcc.dumpPoolStatisticsOnScheduleFile
構成プロパティーに指定されたファイルに書き込まれる頻度を秒単位で指定
グローバル・トランスポート・プールの統計を作成するファイルの名前を指定
未使用のトランスポート・オブジェクトが、グローバル・トランスポート・オブジェクト・プール
内に置かれてからこのプールから削除されるまでの期間を秒数で指定
-1
db2.jcc.maxTransportObjects 値に達した場合に、アプリケーションがトランスポート・オブ
（無制限）
ジェクトを待機する最長期間を秒数で指定
-1
グローバル・トランスポート・オブジェクト・プール内のトランスポート・オブジェクト数の上
（無制限）
限を指定（全てのDataSourceからの接続の合計値）
0
グローバル・トランスポート・オブジェクト・プール内のトランスポート・オブジェクト数の下
（空になり得る） 限を指定
60秒
DB2 Universal JDBCドライバー
DataSourceプロパティ
省略時値
説明
enableConnectionConcentrator
false
(使用しない)
enableSysplexWLB
false
(使用しない)
DB2 Universal JDBC ドライバーの接続コンセントレーター機能を使用可能にするかどう
かを指示。この機能はDB2 UDB for z/OSサーバーへの接続に対してのみ使用可能
DB2 Universal JDBC ドライバーのSysplex ワークロード・バランシング機能を使用可能に
するかどうかを指示。この機能はDB2 UDB for z/OSサーバーへの接続に対してのみ使
用可能
グローバル・トランスポート・オブジェクト・プール内のトランスポート・オブジェクト数の上
限を指定
（特定のDataSourceからの接続のみ）
maxTransportObjects
-1
（無制限）
参考資料
Information Center
WebSphere Application Server Version 6.0.x
DB2 Universal Database
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp
SIL
「クライアント・リルートとWAS連携の考慮点」 (SIL-05-073N)
http://publib.boulder.ibm.com/infocenter/db2help/index.jsp
DB2 for z/OS
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp
http://www.ibm.com/jp/domino01/mkt/dminfo.nsf/doc/000DB513
Redbook
“DB2 UDB for z/OS Version 8 Performance Topics” (SG24-6465-00)
“Distributed Functions of DB2 for z/OS and OS/390” (SG24-6952-00)
“Squeezing the Most Out of Dynamic SQL with DB2 for z/OS and
OS/390” (SG24-6418-00)