le SGBDR DB2 UDB for i5

Transcription

DB2-020
le SGBDR DB2 UDB
for i5
Auteur : Dominique Vignez
© Institut de Poly-informatique (2003)
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.
2.
Introduction ........................................................................................................................ 5
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
fichier
index secondaire
enregistrement
item
librairie
fichier physique
fichier logique
format
champs
collection
table
vue
rangée ou tupple
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
IXCREATOR
COLNAME
COLNO
COLSEQ
ORDERING
char(10)
char(10)
char(10)
integer
integer
char(1)
nom de l'index
propriétaire de l' index
nom du champs contenu dans l' index
n° d'ordre du champs dans l'enregistrement
n° d'ordre du champs dans la clé
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
Table
nombre d'enregistrements par PF
Index
clé composée ou simple
tables par vue jointe
champ de type CHAR
champs par record
Nom d'une table
Taille maxi
240 Go
> 2 000 000 000
4 Go
2048 octets
32
32 767 octets
32 767
18 caractères

le SGBDR DB2 UDB for i5

Transcription

Documents pareils

Perfectionnement

Sortie en Baie de Somme + Char Voile (05/04/10)

Eole Loisirs Côte d`Opale Pièces à fournir

SEJOUR BORD DE MER ETE 2016 Surf Char à Voile

[Jérémy ROCH] Curriculum Vitæ

L`arrivée ou le retour du char Sherman

Ressources documentaires Le dieu Apollon sur son char. Le Char d

ROUBEYRIE Olivier

Marie-Claude CHAR

File - Ronan Le Prioux Administrateur système, réseaux