¿Qué es exactamente el enlace en DB2?

Recientemente pasé de ser un desarrollador de Java a un DBA real en nuestra empresa. Estoy aprendiendo las cuerdas, por así decirlo, sobre ser un DBA (que en realidad es una nueva posición para nuestra empresa).

He visto varios scripts donde ejecutamos el comando DB2 BIND bind_file other_parameters.

Estoy desconcertado por lo que hacen. Le pregunté a nuestros otros DBA, pero no me lo pudieron explicar de una manera que tuviera sentido. He buscado en el Centro de información de IBM el comando BIND , pero tampoco estaba claro para mí.

Sé que la vinculación es de alguna manera importante, porque se supone que debemos ejecutar REORGS, ejecutar STATS y volver a vincular en nuestras bases de datos regularmente para ayudar con el rendimiento.

Como todavía soy un DBA n00b, me preguntaba si alguien puede proporcionar un "¿Qué es BINDing for Dummies?" ¿explicación?

EDITAR : En edición a la respuesta a continuación, recientemente me encontré con el siguiente artículo de desarrollador: "Paquetes de DB2: conceptos, ejemplos y problemas comunes: comprensión del sistema de DB2 y paquetes de aplicaciones de usuario" . Muy útil. Especialmente para los paquetes del sistema, que es con lo que nos estábamos encontrando principalmente.

20130905 EDITAR : Esta entrada de blog de DB2 DBA Ember Crooks es estelar en lo que respecta al enlace y lo que significa. También escribió una entrada anterior sobre los paquetes que no se encuentran y cuándo subir el número CLIPKG para los enlaces y lo que eso significa. Estos artículos están muy bien explicados. Básicamente como leer "Enlaces y paquetes de DB2 para Dummies" si tal cosa existiera.

Veo que su enlace del Centro de información va a LUW 9.7, y usted menciona que ha programado en Java, pero la mayor parte de la experiencia que tengo con el enlace es con DB2 en el Mainframe con COBOL. Por lo tanto, es posible que deba adaptar un poco la explicación (pero en general, los conceptos deberían ser los mismos).

Creo que el enlace solo es relevante cuando compila programas que incluyen SQL incorporado que está precompilado (SQL enlazado estáticamente). Si, por ejemplo, está utilizando JDBC, no es necesario que ejecute un BIND. El controlador JDBC hará PREPAREla declaración dinámicamente.

Cuando ejecuta un programa a través de un precompilador de DB2, lo PRECOMPILEejecuta a través de su programa, y ​​si encuentra algún SQL incorporado (en COBOL, estos son bloques de instrucciones que van de EXEC SQLa END-EXEC.), extrae cuidadosamente el SQL y lo reemplaza por un llame a la interfaz COBOL-DB2. Después de esto, hay dos salidas de PRECOMPILE, la fuente COBOL que ha eliminado todo el SQL incorporado ( Ade ahora en adelante), y una DBRMque contiene todo el SQL que fue eliminado ( B).

La precompilación realiza algunas comprobaciones básicas de sintaxis, pero tenga en cuenta que las comprobaciones solo se basan en las declaraciones de su tabla dentro del programa. ¡No se adjunta a DB2 para verificar esto!

Estos dos archivos están completamente separados, y cuando ejecuta el programa COBOL, tiene que encontrar un Ay un Bque se generaron al mismo tiempo.

En este punto, Ase compila y se vincula con el compilador COBOL estándar en ay se load modulecoloca en una biblioteca de carga para usarlo más adelante.

Sin embargo, todavía hay mucho trabajo por hacer B, el DBRM. Aquí es donde BINDentra. BINDEs algo así como un compilador para el código SQL incorporado, y la salida de la "compilación" es a package.

Para vincular el SQL en un "paquete" ejecutable, el proceso BIND se adjunta a DB2 y hace algunas cosas:

• Verifica que el AuthID actual esté autorizado para realizar un enlace.
• Comprueba la sintaxis de su SQL, con la ayuda de los datos del catálogo de DB2.
• Finalmente, y lo más importante, el enlace optimizará su SQL

Durante el último paso, todo su SQL se ejecuta a través del Optimizador, que tiene en cuenta todas las estadísticas y diversas rutas que el motor de DB2 podría tomar para obtener sus datos. Luego elige la ruta que se le ocurrió que tiene el costo más bajo asociado (con las versiones más nuevas de DB2 [DB2 10 para z / OS] , puede decidir tomar una ruta de "costo más alto", pero de "riesgo más bajo"). Una vez que se selecciona la ruta, se compila y se convierte en un paquete, que se almacena en el catálogo (puede ver todos sus paquetes actuales con SELECT * FROM SYSIBM.SYSPACKAGE(z / OS)).

Finalmente, hay una última pieza que permite que nuestros programas se reúnan con sus paquetes, el PLAN. Crea un plan haciendo otro BIND ( BIND PLAN). Un plan es una colección de paquetes que el programa puede revisar para encontrar el paquete que comparte el mismo nombre. Con COBOL, usted especifica en qué plan debe buscar el programa en su JCL.

En resumen, el código compilado sigue estos pasos para generar un usable BIND PLAN:

Precompilación -> Crea un DBRM (con C [++], el precompilador envía el SQL precompilado a un archivo HFS, que puede enviarse a través del programa de enlace de línea de comandos ) -> el DBRM está optimizado y un conjunto de rutas de acceso ( a package) se crea -> El paquete se agrega a a BIND PLAN, que es un grupo de paquetes que le permite crear una "ruta de búsqueda" para que sus programas lo examinen.

Dado que estos programas están vinculados estáticamente, si las estadísticas de su tabla cambian drásticamente, entonces la ruta de acceso que el optimizador eligió en el momento de vinculación podría no ser la mejor ruta, y volver a vincular le permitirá volver a evaluar el SQL y quizás elegir un Mejor camino.

Editar (actualizar para comentario): si está utilizando el procesador de línea de comandos, puede pasar un paquete de enlace único (.bnd) o una lista de nombres de archivo de enlace (.lst). Si pasa una lista, el nombre del archivo debe anteponerse con un@(por ejemplo/path/to/@packages.lst). Dentro del archivo .lst, puede colocar cada paquete en una línea individual o puede separarlos con+:

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