le SGBDR DB2 UDB for i5

DB2-020 le SGBDR DB2 UDB for i5 Auteur : Dominique Vignez DB2_020.doc version 4 du 04/10/2004 13:58

DB2-020 Cette page est laissée intentionnellement blanche. DB2_020.doc version 4 du 04/10/2004 13:58

DB2-020 TABLE DES MATIÈRES 1. Introduction... 5 2. Description des tables... 5 2.1. Utilisation de DataBase navigator... 5 2.1.1. Création d un schéma... 6 2.1.2. Accès aux définitions de tables... 8 2.1.3. Accès aux données... 9 2.2. Utilisation de Websphere Studio... 10 2.2.1. Création d une nouvelle base... 11 2.2.2. Création de table... 12 2.2.3. Création de colonnes... 12 2.2.4. Contrainte de clé primaire... 13 2.2.5. Contrainte d intégrité... 14 2.2.6. Modification ultérieure d une table... 15 2.2.7. Création de vues... 16 2.2.8. Exportation vers le serveur... 17 2.2.9. Exécution d un script... 18 2.3. Terminologie... 19 3. SQL/400... 20 3.1. SYSINDEXES... 20 3.2. SYSKEYS... 21 3.3. SYSCOLUMNS... 21 3.4. SYSTABLES... 22 3.5. SYSVIEWDEP... 22 3.6. SYSVIEWS... 22 3.7. Support des contraintes d'intégrité référentielle... 23 3.8. Support des triggers ou déclencheurs... 24 3.9. Les messages escape du SGBD... 25 3.10. Procédures cataloguées... 25 3.11. Pocédures stockées... 25 3.12. Validation à deux phases ou two phases commit... 26 4. Autres fonctions base de données... 26 4.1. National Language Support... 26 4.2. Predictive Query Governor... 26 4.3. Amélioration des performances... 27 4.4. Bases de données distribuées... 27 4.5. Passerelles vers d'autres SGBDR... 27 4.6. Data Propagator... 28 4.7. Opticonnect... 28 5. Bases de données parallèles... 28 5.1. La base de données SMP (Symetric Multiprocessing Parallel)... 28 5.2. La base de données faiblement associée... 28 6. Sécurité des données... 29 6.1. La journalisation... 29 6.2. La protection des chemins d'accès par le système (SMAPP)... 29 6.3. Le contrôle de validation... 29 7. Limitations... 30 DB2_020.doc version 4 du 04/10/2004 13:58

DB2-UDB 5 1. Introduction De par son caractère intégré, situé pour partie au dessus du MI et pour partie à l'intérieur du SLIC, la base de données de l'i5 atteint un niveau d'efficacité plus important qu'une autre base de données qui serait construite au dessus du système d'exploitation. La base de données de l'as400 avait été conçu pour le S38 dès 1975 par Perry Taylor à une époque où E.F. Codd travaillait pour IBM sur un projet appelé System/R et avait décrit un système relationnel de table à deux dimensions, sur laquelle on pouvait réaliser quatre opérations (order, selection, projection, join). Perry Taylor entra en contact avec Codd pour lui faire part de ses propres travaux et lui demander d'unir leurs efforts. Mais Codd le pris de haut annonçant que les bases de données relationnelles ne pouvaient être conçues que pour les gros systèmes et qu'un petit système n'avait besoin que d'un tri et d'une fusion de fichiers. De ce fait il a fallu développer une interface native : les DDS. Les spécifications du langage SQL ne sont venues que plus tard et une décennie a été nécessaire à leur stabilisation. Ceci explique que les DDS sont livrées encore aujourd'hui en standard et gratuites alors que le kit de développement SQL UDB est fourni en option et payant. Cette nécessité historique fait que longtemps le SQL a été moins performant et quasiment inutilisé sur AS400. La réécriture du SGBD DB2/400 avec la V3.R1. de l'os400 a gommé cette différence. DDS et SQL sont maintenant au même niveau de performances sur l'i5. Depuis la V4 de l OS400, toutes les améliorations portées à la base de données sont réservées à SQL. Une base de données moderne sur un i5 se doit d être au format DB2 UDB et non plus au format DB2/400. Il faut bien entendu assumer l héritage du passé et il est hors de question de réécrire tous les programmes utilisant des accès fichier sur de fichiers logiques ou physiques. Par contre toutes les nouvelles applications et toutes les nouvelles tables créées devraient l être en conformité avec UDB. 2. Description des tables Deux outils sont disponibles pour décrire les données en plus du SQL interactif. Ce sont DataBase Navigator et WebSphere Studio. Websphere Studio V5 est très pratique et très utile pour la conception et la mise au point d une nouvelle Base de données, mais n est pas adapté à la maintenance d une base existante. En environnement OS400 on lui préférera Data Base Navigator pour la maintenance. 2.1. Utilisation de DataBase navigator iseries Navigator permet de gérer la base de données par interface graphique. Les requêtes SQL sont générées automatiquement par l interface. A partir de la V4.R4. c est l outil le plus puissant de l i5 pour gérer les possibilités de DB2 Universal DataBase. La motivation principale de l utilisation de DataBase Navigator est la possibilité de reverse engieneering sur une base existante.

DB2-UDB 6 En sélectionnant une bibliothèque on peut rechercher les objets Base de Données et créer un Schéma. 2.1.1. Création d un schéma Il est possible de sélectionner un objet et de demander son ajout à l organigramme de la base.

DB2-UDB 7 L ajout d un élément entraîne l ajout des éléments ayant des relation avec celui-ci.

DB2-UDB 8 Le schéma relationnel ainsi créé pourra être sauvegardé pour un usage rapide ultérieur. 2.1.2. Accès aux définitions de tables Par un click droit sur un élément sélectionné, il est possible d obtenir de nombreuses informations. Les propriétés d une table sont visualisables et modifiables d un simple click.

DB2-UDB 9 Exemple ci-dessous pour une contrainte de clé primaire. 2.1.3. Accès aux données DataBase Navigator permet aussi de manipuler les données en accès graphique. Il suffit d un double click sur une table pour l ouvrir.

DB2-UDB 10 On peut ensuite accéder directement aux données à condition de détenir des droits suffisants bien entendu. 2.2. Utilisation de Websphere Studio Websphere Studio V5 est très pratique et très utile pour la conception et la mise au point d une nouvelle Base de données. Il faut utiliser la perspective Données.

DB2-UDB 11 2.2.1. Création d une nouvelle base Un assistant est disponible dont il suffit de suivre les instructions. De nombreux fournisseurs de SGBD sont disponibles : Après la base de données, il faut créer un schéma.

DB2-UDB 12 2.2.2. Création de table Une fois un schéma créé, il faut commencer à créer des tables. Une préférence sera donnée à la création des tables de base (ne comprenant pas de clé étrangère). Si d aventure une table sous-jacente était créée avant la table mère, il suffit d ignorer la définition de clé étrangère et la faire postérieurement à la création ultérieure de la table mère. 2.2.3. Création de colonnes Une fois la table créée, il faut définir les colonnes la composant.

DB2-UDB 13 2.2.4. Contrainte de clé primaire

DB2-UDB 14 2.2.5. Contrainte d intégrité

DB2-UDB 15 2.2.6. Modification ultérieure d une table L ouverture d une table permet l accès à toutes ses définitions sur l espace de travail grâce à des onglets.

DB2-UDB 16 2.2.7. Création de vues L assistant permet de générer les instructions aisément de manière intuitive.

DB2-UDB 17 2.2.8. Exportation vers le serveur Il est possible soit de générer directement la base sur le serveur distant, soit de générer un script SQL qui sera exécuté ultérieurement sur le serveur.

DB2-UDB 18 2.2.9. Exécution d un script Il faut ensuite se connecter au serveur via JDBC et utiliser le bon Driver.

DB2-UDB 19 2.3. Terminologie Suivant la méthode employée les notions logiques de mêmes entités peuvent être nommées différemment. La liste suivante donnera les termes pour une organisation traditionnelle puis selon l'os400 puis selon SQL. répertoire librairie collection fichier fichier physique table index secondaire fichier logique vue enregistrement format rangée ou tupple item champs colonne ou attribut Ces termes bien que regroupant des conceptions identiques ne sont pas simplement des homonymes mais bien des entités différentes qui ne peuvent être utilisées l'une pour l'autre. Ces parallèles ne sont faits que pour aider à la compréhension. Pour de plus amples informations sur ce sujet, consultez les brochures IBM programming data base guide, programming data management guide.

DB2-UDB 20 3. SQL/400 Le langage de requête structuré SQL/400 peut être utilisé pour pour décrire une base de données DB2-UDB. SQL/400 supporte les instructions pour décrire les champs d'une base de données, et pour créer les tables. Si l'application que vous développez doit s'inscrire dans un contexte de portabilité entre systèmes, il sera préférable de décrire vos données par SQL. Pour de plus amples informations à ce sujet, consultez la brochure IBM SQL/400 programmer's guide. Lorsque l'on utilise la méthode SQL, l'environnement s'enrichi encore et la base de données devient une collection par adjonction des éléments suivants : - QSQJRN journal associé au contrôle de validation SQL, - QSQJRN0001 récepteur de journal, - 8 vues logiques assurants la comptatibilité avec la norme SQL QSQTABLES basé sur P02 et P30; QSQCOLUMNS basé sur P10, P02, P20, P30, P31, QADBXREF; SYSCOLUMNS mêmes bases que le précédent; SYSINDEXES basé sur P30, QADBXREF, QADBFDEP; SYSKEYS basé sur P02, P10, P20, P51, QADBXREF; SYSTABLES basé sur P30, QADBXREF; SYSVIEWDEP basé sur P30, QADBXREF, QADBFDEP; SYSVIEW basé sur P30, P52, QADBXREF. Cette configuration est nécessaire pour créer des tables, des vues, des enregistrements par SQL. Mais pour gérer les données en lecture, en mise à jour ou en ajout à l'aide de SQL, il n'est pas indispensable que ces dernières soient incluses dans une collection. SQL400 est capable de gérer les données de l'i5 quelque soit leur mode de définition. 3.1. SYSINDEXES Cette vue logique contient un enregistrement pour chaque index de la base de données. NAME char(10) nom de l'index CREATOR char(10) propriétaire de l' index TBNAME char(10) nom du fichier physique TBCREATOR char(10) propriétaire du fichier physique TBDBNAME char(10) nom de la librairie du fichier physique UNIQUERULE char(1) clés en double autorisées D=oui (duplicates) U=non (unallowed) COLCOUNT integer nombre de champs dans la clé DBNAME char(10) nom de la lbrairie contenant l'index

DB2-UDB 21 3.2. SYSKEYS Cette vue logique contient un enregistrement pour chaque champs contenu dans un index. IXNAME char(10) nom de l'index IXCREATOR char(10) propriétaire de l' index COLNAME char(10) nom du champs contenu dans l' index COLNO integer n d'ordre du champs dans l'enregistrement COLSEQ integer n d'ordre du champs dans la clé ORDERING char(1) sens du tri du champs dans la clé A=ascendant D=descendant 3.3. SYSCOLUMNS Cette vue logique contient un enregistrement pour chaque champs de chaque fichier logique et physique. NAME char(10) nom du champs TBNAME char(10) nom du fichier contenant le champs TBCREATO char(10) propriétaire du fichier R COLNO smallint n d'ordre du champs dans le fichier COLTYPE char(8) type de donnée INTEGER entier long SMALLINT entier court FLOAT nombre flottant CHAR caractère DECIMAL décimal packé NUMERIC décimal zoné LENGHT smallint longueur ou précision 4 bytes integer 2 " smallint 8 " float,float(n) n=25 à 53 ou double précision 4 bytes float(n) n = 1 à 24, réel longueur de la chaîne char nombre de digits decimal nombre de digits numeric SCALE smallint échelle de donnée numérique (zéro si non decimal, numeric ou non nul precision binaire) NULLS char(1) N=non, Y=oui le champs peut-il contenir une valeur nulle UPDATES char(1) N,Y le champs peut-il être modifié REMARKS char(254) commentaires DEFAULT char(1) N,Y si le champs a une valeur par défaut LABEL char(30) entête de colonne STORAGE smallint besoin en espace mémoire pour le stockage du champs idem définition de lenght sauf pour decimal = (nbre digits / 2) + 1 PRECISION smallint précision d'un champs numeric (Zéro si non numeric)

DB2-UDB 22 3.4. SYSTABLES Cette vue logique contient un enregistrement pour chaque fichier physique ou logique de la base de données. NAME char(10) nom du fichier logique ou physique CREATOR char(10) propriétaire du fichier TYPE char(1) type de fichier L=fichier Logique P=fichier Physique T=Table (SQL) V=Vue (SQL) COLCOUNT smallint nombre de champs du fichier RECLENGHT smallint longueur des enregistrements LABEL char(30) chaîne accessible par ordre SQL LABEL ON REMARKS char(254) commentaire DBNAME char(10) nom de la librairie contenant le fichier 3.5. SYSVIEWDEP Cette vue enregistre les dépendances des vues logiques sur les fichiers physiques. DNAME char(10) nom du fichier logique DCREATOR char(10) propriétaire de la vue BNAME char(10) nom du fichier physique BCREATOR char(10) nom du propriétaire du fichier physique BDBNAME char(10) nom de la librairie du fichier physique BTYPE char( 1) type de l'objet sur lequel la vue porte T=fichier physique V=vue logique 3.6. SYSVIEWS Cette vue contient un ou plusieurs enregistrements pour chaque vue logique de la base de données. Chaque enregistrement contient les 70 premiers caractères de la commande de création de la vue. NAME char(10) nom du fichier logique CREATOR char(10) propriétaire de la vue SEQNO integer n d'ordre d'enregistrement dans la vue le premier étant 1 CHECK char(1) inutilisé sur AS400, présent pour assurer la compatibilité avec la norme SQL TEXT char(70) début de l'ordre SQL de création de la vue. D'autre part, les tables sytème SQL sont en réalité stockées dans QSYS2, leur nombre a également augmenté. Nom de catalogue SQL contient les infos concernant SYSCOLUMNS attributs de colonnes SYSCST toutes les contraintes SYSCSTCOL colonnes référencées dans une contrainte SYSCSTDEP dépendances des contraintes sur les tables index SYSINDEXES index, SYSKEYS clés d'index

DB2-UDB 23 SYSKEYCST SYSPACKAGE SYSREFCST SYSTABLES SYSVIEW SYSVIEWDEP clés uniques, primaires et étrangères packages contraintes d'intégrité référentielle tables et vues définitions de vues dépendances des vues sur les tables 3.7. Support des contraintes d'intégrité référentielle L'intégrité référentielle permet de gérer l'intégrité de la cohérence de la base de données à l'extérieur des programmes. C'est un progrès considérable par rapport à la base de données version 2.3.0. Mais il y a un revers. Tout système applicatif possédant des fichiers et existant sur l'i5 n'est pas nécessairement normalisé. C'est à dire que souvent la base de données applicative n'est en réalité pas une vraie base de données. C'est notamment souvent le cas dans des applications qui ont été développées à l'origine sur un système 36. Pour mettre en oeuvre l'intégrité référentielle, il est indispensable, que la base de données satisfasse aux règles des formes normales. Si ce n'est pas le cas, mieux vaut rester en l'état. Si, donc votre base de données est normalisée (vous avez peut être utilisé MERISE pour la concevoir), vos programmes vont se trouver alégés d'un grand nombre de lignes de code maintenant inutiles. Avec l'intégrité référentielle, le gestionnaire de base de données peut seul et automatiquement géré les relations entre un fichier père et un fichier fils. La règle est que toute clé étrangère non nulle doit obligatoirement avoir son équivalent en clé primaire dans le fichier père. Autrement dit : il ne peut exister d'enregistrement commande dont le no de client ne serait pas une valeur d'une clé du fichier client. La commande CL ADDPFCST permet d'ajouter une contrainte à un fichier physique, de même que la commande SQL CREATE ALTER TABLE. Le fichier physique doit être mono membre. Il est donc impossible de mettre une contrainte sur un fichier multi membres. La contrainte se définie sur le fichier dépendant donc le fichier fils. Les contrôles sont soit implicites (automatiques) en cas de création ou de mise à jour de clé associée, soit explicites en cas de suppression. Il faut alors indiquer la règle de mise en oeuvre au paramètre DLTRULE. Les valeurs possibles sont : - *NOACTION suppression d'un record dans le père interdit si au moins un record du fils fait référence à cette clé. - *RESTRICT idem *noaction mais contrôle immédiat avant la suppression du père. - *CASCADE lorsqu'un record du père est supprimé, tous les records du fils contenant la même valeur de clé sont supprimés. - *SETNULL lorsqu'un record du père est supprimé, tous les records du fils sont mis à jour avec la valeur nulle à condition que cette valeur soit admise dans la description du fils. - *SETDEFAULT idem *SETNULL mais c'est la valeur par défaut définie dans le fils qui est utilisée. La différence entre *NOACTION et *RESTRICT est subtile mais importante. Si vous utilisez *NOACTION la journalisation est obligatoire. En effet toutes les mises à jour et suppressions

DB2-UDB 24 seront effectuées avant que la contrainte soit lancée. Au cas ou un message d'erreur survient (le message ESCAPE est le moyen de communication entre le SGBD et votre programme) vous devez invalider les mises à jour. Or sans la possibilité du ROLLBACK c'est une opération périlleuse. Si par contre vous utilisez *RESTRICT, la vérification est lancée avant les mises à jour et le message intervient dans votre programme RPG sans que vous ayez à faire une mise à jour arrière. *RESTRICT donne donc de meilleures performances et doit être préféré à *NOACTION qui est pourtant la valeur par défaut du paramètre. 3.8. Support des triggers ou déclencheurs Sur AS400 le déclencheur et le programme déclenché s'appellent tous deux trigger, d'où une confusion possible. Un trigger est un call automatique d'un programme écrit dans n'importe quel langage disponible sur l'as400 et dont le contenu et l'action est entièrement laissé à la discrétion du programmeur. il y a également des règles (rules) pour l'ajout, la mise à jour ou la suppression d'enregistrement (les triggers de zone ne sont pour l'instant pas disponibles sur AS400). Généralement un trigger de record est utilisé pour faire les contrôles de zones du record. Ainsi vos programmes se trouvent déchargés du contrôle des zones qui est laissé à la charge du SGBD. Ici encore le moyen de communication entre votre programme RPG et le SGBD est le message de type *ESCAPE. La commande ADDPFTRG permet d'ajouter un trigger à un fichier physique. Le SQL de l'as400 ne supporte pas pour le moment et ce au moins jusqu'en 1996 d'ordre pour les triggers et ce en attente d'une normalisation devant être effective avec la norme SQL3. Néanmoins la fonction trigger est très riche et permet de définir pour un seul record un trigger avant et après création, mise à jour et suppression. Six triggers différents peuvent donc être déclenchés pour un même record. Le programme déclenché a obligatoirement deux paramètres d'entrée qui sont une structure et la longueur de la structure.le dessin de la structure est : - nom du fichier (fichier, bibliothèque, membre) - type d'opération (création, mise à jour, suppression) - moment de l'appel (avant, après) - niveau de verrouillage - pointeur position et longueur (dans la structure) du buffer avant l'opération - pointeur position et longueur (dans la structure) du buffer après l'opération - valeurs du buffer avant - valeurs du buffer après un exemple de description de structure est disponible dans le membre LIBUXX/XXX,XXXCITRG en RPGIII et dans LIBUXX/ZZZ, XXXXCITRG pour RPG IV.

DB2-UDB 25 3.9. Les messages escape du SGBD En cas de violation de l'intégrité référentielle, les messages suivants sont émis : - CPF502D violation de CIR sur le membre &4 en ajout dans un fichier fils sans correspodance dans le fichier père. - CPF503A violation de CIR sur le membre &4 en suppression du fichier père alors qu'il existe des records du fichier fils faisant référence à cette valeur de clé étrangère. - CPF502E enregistrement verrouillé, la CIR ne peut être lancée. - CPF523B erreur de CIR lors du traitement du membre &4 impossibilité système. - CPF523C erreur dans le journal d'intégrité référentielle. les règles demandent un contrôle de validation, mais la journalisation n'est pas démarrée ou les récepteurs de journaux des deux fichiers sont différents. De plus RPGIV ILE envoie les messages suivants : - RNQ1022 (*inquiry) et RNX1022 (*escape) correspondant aux messages CPF502D et CPF503A. - RNQ1299 (*inquiry) et RNX1299 (*escape) correspondant aux messages CPF523C et CPF523B. Il est donc capital de savoir gérer les messages escape en RPG grâce aux APIs de messages. 3.10. Procédures cataloguées Une implémentation de SQL pour mise à niveau avec SQL2 permet à DB2/400 de mettre en oeuvre les procédures cataloguées. La syntaxe SQL est : EXEC SQL DECLARE nomdeprogramme PROCEDURE (:parm1 IN CHAR(10) :parm2 IN DECIMAL (5,2)) EXTERNAL NAME nomlib/nomde programme LANGUAGE RPG END-EXEC. EXEC SQL CALL nomdeprogramme (:parm1, :parm2) END-EXEC. Il est ainsi possible d'appeler dans le SQL un programme écrit dans n'importe quel langage disponible sur l'as400 avec passage de paramètres. 3.11. Pocédures stockées Le langage SPL (Stored Procedure Language), composante du SQL permêt de programmer une logique applicative réalisée par le serveur de Base de données. C est une composante importante des applications Client/Serveur, des architectures multi-tiers ou du modèle de programmation MVC (Model View Controller).

DB2-UDB 26 3.12. Validation à deux phases ou two phases commit DB2/400 supporte le niveau 2 de DRDA et assure automatiquement la gestion des commit et roll back sur des bases de données réparties même en cas de rupture du réseau. 4. Autres fonctions base de données 4.1. Support des transactions Les transactions SQL sont liées au contrôle de validation. Un support d administration des transactions est fourni dans iseries Navigator. 4.2. National Language Support En V3R1 le premier pas vers la mise en oeuvre de Unicode a été effectué en encodant les noms d'objets dans certains composants de IFS. Avec la V3R6 ce support a été étendu pour permettre aux fichiers BD de stocker des données dans Unicode (USC2 niveau 1). Par exemple des données en français, en allemand, en hébreu, en chinois, en russe ou en toute autre langue peuvent coexister dans un même fichier BD. SQL a la possibilité de convertir de et vers Unicodeafin que les requêtes et les manipulations sur les données Unicode puissent être réalisées dans une même application. 4.3. Predictive Query Governor La plupart des bases de données comportent un genre de Query Predictor, qui permet de s'assurer que les requêtes ne s'exécutent pas pendant un temps anormalement long. Au bout d'un certain temps, cet outil stoppe la requête en cours si elle dépasse le temps prévu. Dans DB2/400 si la prévision dépasse une certaine limite la requête n est même pas lancée. Ainsi les ressources du système ne sont pas gaspillées à exécuter une requête qui serait arrêtée de toutes façons. Un optimiseur de requêtes est utilisé pour analyser comment il faut attaquer la base avant l'exécution d'une requête et quel est le meilleur moyen d'y parvenir dans le temps imparti. La prédiction de la durée d'exécution fait partie de l'analyse réalisée par l'optimiseur. Ce temps

DB2-UDB 27 prévu est mis en regard de la limite associée à cet utilisateur. Si la durée calculée est supérieure à la limite autorisée, un message est envoyé à l'utilisateur qui peut choisir soit de stopper, soit d"exécuter malgré le dépassement de limite. 4.4. Amélioration des performances On peut utiliser la commande EXPLAIN pour prévoir ou visualiser les caractéristiques d'exécution d'une requête. Ceci est aussi réalisé dans l'historique du travail si le programme qui lance la requête est en mode DEBUG actif. On peut alors utiliser les informations recueillies pour améliorer les performances soit en modifiant la base de données, soit en modifiant la requête. Pour les accès séquentiels l'utilisateur peut mettre en oeuvre des mécanismes de cache très pointus comme le cache statique ou l'expert cache. Un cache expert s'agrandit ou s'amenuise en fonction des besoins. Ce type de cache utilise des algorithmes d'intelligence artificielle (IA) pour modifier dynamiquement la taille du cache, en fonction de la charge CPU, des prévisions d'activité de la base de données et des ressources allouées. De même un utilisateur peut définir un cache statique en mémoire pour permettre à une table complète ou à une portion de table d'entrer dans une zone de mémoire. 4.5. Bases de données distribuées L'i5 permet à un programme applicatif d'accéder de façon transparente à une base de données situées sur un autre système de la même manière que si elle était en local. Autrement dit un programme peut traiter un fichier sans savoir réellement où il se trouve physiquement. La possibilité d'accéder à une base de données distante et pour d'autres systèmes d'avoir accès à la base de données locale est réalisée grâce à la mise en oeuvre de deux architectures : - DRDA (Distributed Relational Database Architecture) pour SQL, - DDM (Distributed Data Management) pour les accès en natif. 4.6. Passerelles vers d'autres SGBDR L'i5 fonctionne avec les bases de données supportant DDM ou DRDA, mais il offre également une approche intégrée pour accéder aux autres bases de données. Ce support permet de travailler directement avec n'importe quel SGBD d'un autre constructeur présent sur le réseau. En plus de la Distributed Database Directory de l'os400, il ya un Distributed Driver Manager. Ce gestionnaire fonctionne avec les drivers des différentes bases de données Unix et Micro et permettent à une application AS400 de travailler avec ces bases de données de la même manière qu'avec une base de données DRDA. En sortie, le support d'un driver ODBC est également disponible pour les bases compatibles avec l'architecture distribuée de Microsoft. Un dirver JDBC très puissant offre des accès en mode SQL ou en mode fichier pour les applications écrites en Java.

DB2-UDB 28 4.7. Data Propagator Dans un environnement distribué il peut exister plusieurs exemplaires d'un même fichier sur des systèmes distincts. La modification de l'un des exemplairesn'est pas immédiatement répercutée sur les autres exemplaires. Data Propagator fourni un mécanisme de répercussion des mises à jour sur tous les systèmes. A intervalles définis par l'utilisateur, les modifications d'un fichier donné sont répliquées à travers l'ensemble des systèmes même si tous ne sont pas connectés au réseau simultanément. Les modifications peuvent être répercutées sur toute base DB2 aussi bien sous Windows que sous AIX ou Linux ou MVS. 4.8. Opticonnect Comme système isolé, le i5 admet des configurations assez importantes. Mais pour des clients ayant des besoins allant au delà de ce qu'il est possible de faire avec un seul i5 et même avec un réseau de systèmes, les charges liées au trafic réseau vont limiter les performances. Opticonnect pour l'os400 permet à plusieurs i5 d'être reliés entre eux par fibre optique. Dans une telle configuration, certaines machines seront réservées aux traitements applicatifs et d'autres machines seront spécialisées pour les traitements base de données. Opticonnect met en oeuvre DDM, mais avec un protocole particulier qui élimine les couches redondantes de contrôle de transmission liées aux lignes LAN bruyantes. Avec Opticonnect il faut seulement ajouter 3 millisecondes au temps nécessaire pour accéder à la base de données qui oscile de 3 à 8 millisecondes en temps normal et selon les modèles de DASD (Data Auxillary Storage Drive). 5. Bases de données parallèles Dans un système tel que le i5, avec de multiples processeurs, les opérations base de données peuvent être partagées entre plusieurs processeurs pour atteindre un haut niveau de performances. Par exemple, un requête peut être divisée en sous requêtes, chacune s'exécutant sur des processeurs distincts et sur des machines distinctes. Deux approches permettent de réaliser de telles améliorations. 5.1. La base de données SMP (Symetric Multiprocessing Parallel) Disponible sur les i5 multiprocesseurs. Les requêtes sont fractionnées en unités de travail plus petites, réparties ensuite entre les processeurs, en une répartition équitable de la charge sur les différents processeurs. La commande CHGQRYA (Change Query Attributs) comporte une option permettant à l'utilisateur que la requête doit mettre à proffit les processeurs multiples. 5.2. La base de données faiblement associée Ce support de base de données répartie permet à de multiples i5 de s'interconnecter pour fonctionner comme une seule base de données. On appelle ce type d'interconnection une grappe faiblement associée, parce que chaque système (un noeud ou node) de la grappe tourne avec son propre système d'exploitation et ne peut adresser que sa propre mémoire. Dans l'absolu, il n'y a pas de limite au nombre de connections, mais pour l'instant seulement 32 systèmes peuvent être interconnectés. Cela correspond à une base de données de 16 To avec 128 processeurs tournant en parallèle, ce qui n'est pas si mal pour un début.

DB2-UDB 29 Pour la mise en oeuvre, voir les commandes : - CRTNODGRP create node group, - CHGNODGRPA change node group attributs, - CRTPF mots clé NODGRP et PTNKEY (partitionning key), - CREATE TABLE pour accès SQL. 6. Sécurité des données 6.1. La journalisation Un journal est l'enregistrement chronologique des modifications apportées à un ensemble de données. Le but du journal est d'offrir la possibilité de reconstruire une version précédente de cet ensemble de données. Deux objets AS400 servent de support à la journalisation. L'un est le journal, l'autre le récepteur de journal. Le journal identifie les objets à journaliser, le récepteur de journal contient les entrées de journal (les modifications effectuées). Chaque entrée de journal contient plusieurs éléments d'information, dont le nom du fichier, de la bibliothèque, le nom du programme, le numéro relatif d'enregistrement, l'heure et la date, l'identification du travail, de l'utilisateur et du poste de travail. La copie de l'enregistrement modifié est également inscrite, et optionnellement, la copie avant modification peut aussi être inscrite. Les journaux de base de données sont utilisés pour pouvoir reprendre après une panne système, mais aussi après des problèmes de base de données liés à des programmes. S'il se produit une anomalie, les fichiers journalisés sont automatiquement restaurés lors de l'ipl suivant. Il est possible de restaurer soit en avant soit en arrière. La restauration supprime les modifications erronées du fichier. 6.2. La protection des chemins d'accès par le système (SMAPP) IBM a conçu SMAPP (System Managed Access Path Protection) pour réaliser une journalisation automatique des chemins d'accès fichiers, ntamment pour les utilisateurs qui n'utilisent pas la journalisation explicite. Le système calcule automatiquement la durée maximale qu'il va allouer à la reconstruction des chemins d'accès pendant l'ipl après un arrêt anormal. Il utilise ensuite cette durée maximale pour déterminer combien il faut journaliser de chemins d'accès. L'utilisateur a la possibilité de modifier cette valeurcalculée dans un sens ou dans l'autre. Plus la valeur est petite, plus il faudra de ressources à la journalisation, plus la valeur est grande, plus l'ipl durera dans le temps. 6.3. Le contrôle de validation Lorsque de multiples mises à jour de plusieurs tables sur une seule opération sont nécessaires, il est possible que de par l'action de l'utilisateur final ou de par une anomalie de

DB2-UDB 30 fonctionnement, une partie seulement des mises à jour soient effectuées. Si la situation en reste là, l'intégrité de la base de données est compromise. Le système doit donc gérer la possibilité de prendre en compte ou d'annuler un groupe de mises à jour. Celà s'appelle le contrôle de validation. Le système doit donc protéger un groupe de mises à jour et ne les libérer que lorsque toutes les mises à jour sont effectuées. Une opération COMMIT permet au système d'enterriner un groupe de modifications, alors que l'opération ROLLBACK permet d'invalider un groupe de mises à jour. Le contrôle de validation utilise la journalisation pour mettre en oeuvre ces opérations. 7. Limitations Les limitations actuelles sont le fait de la version actuelle du SLIC, dans l'absolu le MI n'a pas de limite à la taille des objets système car il est indépendant de la technologie. Par le passé, les limitations ont déjà été repoussées plusieurs fois. Element Taille maxi Table 240 Go nombre d'enregistrements par PF > 2 000 000 000 Index 4 Go clé composée ou simple 2048 octets tables par vue jointe 32 champ de type CHAR 32 767 octets champs par record 32 767 Nom d'une table 18 caractères