> Tech > 2. Simplifier la création des bases de donénes SQL

2. Simplifier la création des bases de donénes SQL

Tech - Par iTPro - Publié le 24 juin 2010
email

La figure 3 montre que la plupart des scripts de création des bases de données contiennent des opérations de suppression et de création pour chaque objet base de données créé. Cette technique est intéressante en cas de test parce que le script de création est capable de nettoyer automatiquement d'éventuels

2. Simplifier la création des bases de donénes SQL

objets existants, et ce que
l’on utilise DDS ou SQL pour créer les
objets DB2.
L’inclusion systématique de l’opération
suppression pose un problème : la
première exécution du script déclenche
une erreur pour la simple raison que
l’objet DB2 n’existe pas encore. Les
scripts qui utilisent la commande CL
CRTPF (Create Physical File) utilisent la
commande CL MONMSG (Monitor
Message) pour traiter cette condition,
en ignorant l’erreur et en laissant le
script poursuivre son exécution. Avant
la V5R3, le script base de données SQL
qui utilisait la commande RUNSQLSTM
(Run SQL Statement) pour exécuter un
script n’avait pas cette possibilité. Si une
instruction SQL DROP ne pouvait pas
trouver l’objet DB2, la commande
RUNSQLSTM se terminait immédiatement en produisant
une erreur. Cet état de fait imposait souvent deux versions
du script de création : l’une avec les seules opérations de
création et l’autre avec les opérations de création et de
suppression.
DB2 a résolu ce problème en V5R3 en changeant le niveau
de gravité de l’erreur associé aux instructions DROP qui
génèrent une erreur Object Not Found. Les instructions SQL
DROP qui échouent avec ce type d’erreur en V5R3 génèrent
désormais un niveau de gravité de message d’erreur de 20.Dans les releases antérieures, ce niveau était de 30 pour les
erreurs DROP.
Pour bénéficier de ce changement du niveau de gravité
des erreurs DROP, on peut assortir la commande RUNSQLSTM
du paramètre ERRLVL. Le paramètre niveau d’erreur
adopte par défaut un niveau de gravité de 10. Cette valeur signifie
que RUNSQLSTM cesse d’exécuter les instructions
SQL dès réception de messages d’erreur d’un niveau de gravité
supérieur à  10. C’est ce que montre la figure 4.
La commande


RUNSQLSTM SRCFILE(mysrc) SRCMBR(s1)

échoue et arrête l’exécution immédiatement après l’instruction
DROP, parce que le message d’erreur DOP (SQL0204)
présente un niveau de gravité supérieur à  10. En V5R3, on
peut spécifier un niveau de gravité de 20 sur la commande

RUNSQLSTM SRCFILE(mysrc)

SRCMBR(s1) ERRLVL(20)
ce qui permet à  la commande d’ignorer le message d’erreur
DROP et de continuer à  exécuter le script SQL, comme le
montre la figure 5. Par opposition à 
l’exemple précédent, le message d’erreur
DROP est signalé, mais le traitement
du script SQL continue parce que
le niveau de gravité de 20 n’est pas supérieur
à  20. On voit aussi dans la figure
5 que la commande RUNSQLSTM
échoue parce que l’instruction CREATE
VIEW échoue avec un message de gravité
de niveau 30. Cet échec démontre
les actions pré-V5R3 de l’instruction
DROP, dans lesquelles une condition
Object Not Found (Objet non trouvé)
générait un message d’erreur d’un niveau
de gravité 30.
A l’évidence, exécuter et gérer des
scripts SQL avec RUNSQLSTM est beaucoup
plus facile en V5R3, avec l’ajustement
du niveau de gravité pour les erreurs
d’instruction DROP « normales ».

Téléchargez gratuitement cette ressource

Guide de Services Cloud Managés

Guide de Services Cloud Managés

Accélérer votre transformation digitale, protéger et sécuriser vos environnements Cloud avec les offres de support, d'accompagnement et de services managés. Découvrez le TOP 3 des Services Managés pour accompagner la transformation de vos environnements Cloud, gagner en agilité et en sécurité dans un monde d'incertitudes.

Tech - Par iTPro - Publié le 24 juin 2010