Quelle est exactement la liaison dans DB2?
Je suis récemment passé d'un développeur Java à un DBA réel dans notre entreprise. J'apprends les ficelles, pour ainsi dire, d'être un DBA (qui est en fait un peu une nouvelle position pour notre compagnie).
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é IBM's Information Center for the BIND command , 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?
[~ # ~] modifier [~ # ~] : 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 des packages système DB2 et des applications 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 liaison et ce que cela signifie. Elle a également écrit ne entrée précédente sur les packages introuvable 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 " DB2 Binding and Packages for Dummies "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 PREPARE l'instruction dynamiquement.
Lorsque vous exécutez un programme via un précompilateur DB2, PRECOMPILE s'exécute dans 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 arrache soigneusement le SQL et le remplace par un appel à l'interface COBOL-DB2. Après cela, il y a deux sorties de PRECOMPILE, la source COBOL qui a supprimé tout le SQL embarqué (A à partir de maintenant), et une DBRM qui 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 sont uniquement basées 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 A et un B qui ont été générés en même temps.
À ce stade, A est compilé et lié avec le compilateur COBOL standard dans un load module et placé dans une bibliothèque de chargement pour être utilisé plus tard.
Cependant, il reste encore beaucoup de travail à faire avec B, le DBRM. C'est là que BIND entre en jeu. BIND est un peu comme un compilateur pour le code SQL incorporé, 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, l'intégralité de votre SQL est exécutée via l'Optimiseur, 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 nouvelles versions de DB2 [DB2 10 pour z/OS] , il peut décider de prendre un "coût plus élevé", mais " "risque plus faible"). 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 BIND PLAN:
Précompiler -> Crée un DBRM (avec C [++], le précompilateur sort 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 (un package) est créé -> Le package est ajouté à un 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.
Edit (mise à jour pour commentaire): Si vous utilisez le processeur de ligne de commande, vous pouvez passer soit un seul package de liaison (.bnd) ou une liste de noms de fichiers liés (.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