web-dev-qa-db-ja.com

DB2で正確に何がバインドされていますか？

私は最近、Java開発者から当社の実際のDBAに転向しました。いわば、DBAになることについてのロープを学んでいます（実際にはDBAの新しい立場の1つです）当社）。

コマンドDB2 BIND bind_file other_parametersを実行するスクリプトをいくつか見ました。

これらが何をするのか私は困惑しています。私は他のDBAに尋ねましたが、彼らはそれを理にかなった方法で私に説明することができませんでした。私は IBMのBINDコマンドに関するインフォメーションセンター を見てきましたが、どちらもわかりませんでした。

REORGSを実行し、STATSを実行し、パフォーマンスを支援するために定期的にデータベースでBINDを再実行することになっているので、バインディングが何とか重要であることを知っています。

私はまだn00bのDBAなので、だれでも「ダミーのバインドとは」を提供できるかどうか疑問に思っていました。説明？

[〜＃〜] edit [〜＃〜]：以下の答えに対する版で、私は最近、次のdeveloperworksの記事に出くわしました： "DB2パッケージ：概念、例、および一般的な問題：DB2システムおよびユーザーアプリケーションパッケージの理解" 。非常に役立ちます。特にシステムパッケージの場合、これは主に実行されていたものです。

20130905 EDIT：This blog entry by DB2 DBA Ember Crooksは、バインディングとその意味。彼女は パッケージに関する以前のエントリ が見つからないこと、およびバインドのCLIPKG番号をいつアップするかとその意味を書いています。これらの記事は非常によく説明されています。基本的には「 DB2 Binding and Packages for Dummies」のようなものが存在した場合。

db2
8
Chris Aldrich

情報センターのリンクがLUW 9.7に移動し、Javaでプログラミングしたとおっしゃっていますが、私がバインドした経験のほとんどは、COBOLを使用したメインフレーム上のDB2での経験です。そのため、説明を少し変更する必要がある場合があります（ただし、一般に、概念は同じである必要があります）。

バインドは、プリコンパイルされた埋め込みSQL（静的にバインドされたSQL）を含むプログラムをコンパイルする場合にのみ関係があると思います。たとえば、JDBCを使用している場合、BINDを実行する必要はありません。 JDBCドライバーは PREPARE ステートメントを動的に実行します。

DB2プリコンパイラーを介してプログラムを実行すると、 PRECOMPILE がプログラムを介して実行され、埋め込みSQL（COBOLでは）が見つかった場合、これらはEXEC SQL to END-EXEC.）、SQLを慎重に削除し、COBOL-DB2インターフェースの呼び出しに置き換えます。この後、PRECOMPILEの2つの出力、すべての埋め込みSQLが削除されたCOBOLソース（A以降）、およびすべてを含むDBRMがあります。削除されたSQL（B）。

プリコンパイルはいくつかの基本的な構文チェックを行いますが、チェックはプログラム内のテーブル宣言にのみ基づいていることに注意してください。これらを検証するためにDB2に接続することはありません！

これら2つのファイルは完全に独立しており、COBOLプログラムを実行するときに、同時に生成されたAとBを見つける必要があります。

この時点で、Aはコンパイルされ、標準のCOBOLコンパイラーでload moduleにリンクされ、後で使用するためにロードライブラリに配置されます。

ただし、DBRMであるBを使用して行う作業はまだたくさんあります。これがBINDの出番です。BINDは組み込みSQLコードのコンパイラのようなもので、「コンパイル」の出力はpackageです。

SQLを実行可能な「パッケージ」にバインドするために、BINDプロセスはDB2に接続し、いくつかのことを行います。

  • 現在のAuthIDがバインドの実行を許可されていることを確認します。
  • DB2カタログのデータを利用して、SQLの構文をチェックします。
  • 最後に、そして最も重要なこととして、バインドはSQLを最適化します

最後のステップでは、すべてのSQLがオプティマイザーを介して実行されます。オプティマイザーは、データをフェッチするためにDB2エンジンが取る可能性のあるすべての統計とさまざまなパスを考慮します。次に、関連付けられたコストが最も低いパスを選択します（DB2の新しいバージョンでは [DB2 10 for z/OS] 、 "より高いコスト"をとることがありますが、 "低リスク」の経路）。パスが選択されると、それがコンパイルされ、パッケージになり、カタログに格納されます（現在のパッケージはすべて SELECT * FROM SYSIBM.SYSPACKAGE （z/OS）で確認できます）。

最後に、プログラムがパッケージと再結合できるようにする最後のピース、PLANがあります。別のBIND（ BIND PLAN ）を実行して計画を作成します。プランは、プログラムが同じ名前を共有するパッケージを見つけるために調べることができるパッケージのコレクションです。 COBOLでは、プログラムがJCLで検索するプランを指定します。

つまり、コンパイルされたコードは次の手順を実行して、使用可能なBIND PLANを生成します。

プリコンパイル-> DBRMを作成します（C [++]を使用すると、プリコンパイラはプリコンパイルされたSQLをHFSファイルに出力します。これは コマンドラインバインドプログラム を介して送信できます）-> DBRMが最適化されますそして、一連のアクセスパス（package）が作成されます->パッケージはBIND PLANに追加されます。これは、プログラムの「検索パス」を作成できるようにするパッケージのグループです目を通してください。

これらのプログラムは静的にバインドされているため、テーブルの統計情報が大幅に変化すると、バインド時にオプティマイザが選択したアクセスパスが最適パスではなくなる可能性があり、再バインドによってSQLを再評価し、おそらくより良い道。

Edit（コメントの更新）：コマンドラインプロセッサを使用している場合は、単一のバインドパッケージ（.bnd）、またはバインドファイル名のリスト（.lst）。リストを渡す場合、ファイル名の前に@を付ける必要があります（例：/path/to/@packages.lst）。 .lstファイル内では、各パッケージを個別の行に配置するか、+で区切ることができます。

package1.bnd
package2.bnd
package3.bnd+package4.bnd+package5.bnd
3
bhamby