Quelle est exactement la liaison dans DB2?

Je suis récemment passé d'un développeur Java à un véritable DBA dans notre entreprise. J'apprends les ficelles, pour ainsi dire, d'être un DBA (ce qui est en fait un peu un nouveau poste pour notre entreprise).

J'ai vu plusieurs scripts où nous exécutons la commande DB2 BIND bind_file other_parameters.

Je suis perplexe par ce que cela fait. J'ai demandé à nos autres administrateurs de base de données, mais ils n'ont pas pu m'expliquer d'une manière qui avait du sens. J'ai regardé le centre de documentation d'IBM pour la commande BIND , mais ce n'était pas clair pour moi non plus.

Je sais que la liaison est en quelque sorte importante, car nous sommes censés exécuter REORGS, exécuter STATS et re BIND sur nos bases de données régulièrement pour améliorer les performances.

Étant donné que je suis toujours un DBA n00b, je me demandais si quelqu'un pouvait fournir un "Qu'est-ce que la LIAISON pour les nuls?" explication?

EDIT : Dans l'édition de la réponse ci-dessous, je suis récemment tombé sur l'article developerworks suivant: "Packages DB2: concepts, exemples et problèmes courants: compréhension du système DB2 et des packages d'application utilisateur" . Très utile. Surtout pour les packages système, c'est ce que nous rencontrions le plus souvent.

20130905 EDIT : Cette entrée de blog par DB2 DBA Ember Crooks est stellaire en ce qui concerne la liaison et ce que cela signifie. Elle a également écrit une entrée précédente sur les paquets non trouvés et quand augmenter le numéro CLIPKG pour les liaisons et ce que cela signifie. Ces articles sont très bien expliqués. Fondamentalement, comme lire "Liaison DB2 et packages pour les nuls" si une telle chose existait.

Je vois que votre lien Info Center va à LUW 9.7, et vous mentionnez que vous avez programmé en Java, mais la plupart de l'expérience que j'ai avec la liaison est avec DB2 sur le mainframe avec COBOL. Ainsi, vous devrez peut-être adapter un peu l'explication (mais généralement, les concepts doivent être les mêmes).

Je crois que la liaison n'est pertinente que lorsque vous compilez des programmes qui incluent du SQL embarqué qui est précompilé (SQL lié statiquement). Si, par exemple, vous utilisez JDBC, vous n'êtes pas obligé d'exécuter un BIND. Le pilote JDBC va PREPAREl'instruction dynamiquement.

Lorsque vous exécutez un programme via un précompilateur DB2, PRECOMPILEexécute votre programme et s'il trouve du SQL embarqué (dans COBOL, ce sont des blocs d'instructions qui vont de EXEC SQLà END-EXEC.), il déchire soigneusement le SQL et le remplace par un appel à l'interface COBOL-DB2. Après cela, il existe deux sorties de la PRECOMPILE, la source COBOL qui a supprimé tout le SQL incorporé (à Apartir de maintenant) et une DBRMqui contient tout le SQL qui a été supprimé ( B).

La précompilation effectue une vérification de base de la syntaxe, mais sachez que les vérifications ne sont basées que sur vos déclarations de table dans le programme. Il ne s'attache pas à DB2 pour les vérifier!

Ces deux fichiers sont complètement séparés, et lorsque vous exécutez le programme COBOL, il doit trouver un Aet un Bqui ont été générés en même temps.

À ce stade, Aest compilé et lié avec le compilateur COBOL standard dans un load moduleet placé dans une bibliothèque de chargement pour être utilisé plus tard.

Cependant, il reste encore beaucoup de travail à faire avec Ble DBRM. C'est là BINDqu'intervient. BINDEst un peu comme un compilateur pour le code SQL intégré, et la sortie de la "compilation" est un package.

Afin de lier le SQL dans un "package" exécutable, le processus BIND s'attache à DB2 et fait quelques choses:

• Vérifie que l'AuthID actuel est autorisé à effectuer une liaison.
• Vérifie la syntaxe de votre SQL, à l'aide des données du catalogue DB2.
• Enfin et surtout, la liaison optimisera votre SQL

Au cours de la dernière étape, tout votre SQL est exécuté via l'Optimizer, qui prend en compte toutes les statistiques et les différents chemins que le moteur DB2 pourrait prendre pour récupérer vos données. Il choisit ensuite le chemin qu'il a proposé qui a le coût le plus bas associé (avec les versions plus récentes de DB2 [DB2 10 pour z / OS] , il peut décider de prendre un chemin "à coût plus élevé" mais "à moindre risque"). Une fois le chemin sélectionné, il est compilé et devient un package, qui est stocké dans le catalogue (vous pouvez voir tous vos packages actuels avec SELECT * FROM SYSIBM.SYSPACKAGE(z / OS)).

Enfin, il y a une dernière pièce qui permet à nos programmes de se réunir avec leurs packages, le PLAN. Vous créez un plan en faisant un autre BIND ( BIND PLAN). Un plan est une collection de packages que le programme est autorisé à parcourir pour trouver le package qui partage le même nom. Avec COBOL, vous spécifiez dans quel plan le programme doit rechercher dans votre JCL.

En bref, le code compilé passe par ces étapes pour générer un utilisable BIND PLAN:

Précompilation -> Crée un DBRM (avec C [++], le précompilateur génère le SQL précompilé dans un fichier HFS, qui peut être envoyé via le programme de liaison en ligne de commande ) -> le DBRM est optimisé et un ensemble de chemins d'accès ( a package) est créé -> Le package est ajouté à a BIND PLAN, qui est un groupe de packages qui vous permet de créer un "chemin de recherche" pour vos programmes.

Étant donné que ces programmes sont liés statiquement, si vos statistiques de table changent radicalement, le chemin d'accès choisi par l'optimiseur au moment de la liaison n'est peut-être plus le meilleur chemin, et une nouvelle liaison lui permettra de réévaluer le SQL et peut-être de choisir un meilleur chemin.

Modifier (mise à jour pour commentaire): Si vous utilisez le processeur de ligne de commande, vous pouvez passer soit un seul package de liaison (.bnd), soit une liste de noms de fichiers de liaison (.lst). Si vous passez une liste, le nom de fichier doit être précédé d'un@(par exemple/path/to/@packages.lst). Dans le fichier .lst, vous pouvez soit placer chaque package sur une ligne individuelle, soit les séparer avec+:

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