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

私は最近、Java開発者から私たちの実際のDBAに乗り換えました。私は、いわば、DBAになることについてロープを学んでいます（実際、これは私たちの会社にとっては新しいポジションの1つです）。

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

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

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

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

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

20130905編集：DB2 DBAのEmber Crooksによるこのブログエントリは、バインディングとその意味に関して優れています。彼女はまた、パッケージが見つからないこと、バインドのCLIPKG番号をいつ上げるか、およびそれが何を意味するかについての以前のエントリーを書きました。これらの記事は非常によく説明されています。基本的に、「DB2 Binding and Packages for Dummies」が存在する場合は、そのようなものを読むのと同じです。

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

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

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

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

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

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

ただし、BDBRMで行う作業はまだたくさんあります。これが登場する場所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が最適化され、アクセスパスのセット（ a package）が作成されます->パッケージがに追加されますBIND PLAN。これは、プログラムが参照する「検索パス」を作成できるようにするパッケージのグループです。

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

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

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