> Paul Conte

Paul Conte

Paul Conte est un professionnel IT et rédacteur sur iTPro.fr : Découvrez ses articles informatique

Les plus consultés sur iTPro.fr

Revue Smart DSI

La Revue du Décideur IT

Bases de donnéesUne question d’intégrité : guide pratique des transactions sur bases de données

Le traitement transactionnel est au coeur de la plupart des applications i5. Une application est une opération logique unique qui consiste généralement à lire ou à mettre à jour une ou plusieurs tables de bases de données (plus banalement, des fichiers). Quelle que soit l’action des utilisateurs : saisir des commandes, planifier des réservations d’hôtel, ou exécuter des transactions financières, une application doit être conçue de telle sorte que toutes les transactions satisfassent au test « ACID »« ACID » :
• Atomicité (Atomicity) : Tous les effets d’une transaction réussissent ou tous échouent.
• Cohérence (Consistency) : La base de données reste dans un état cohérent vis-à-vis de ses règles d’intégrité, et cela qu’une transaction s’exécute correctement ou échoue.
• Isolation : Les effets d’une transaction sont isolés des effets des transactions effectuées au même moment par d’autres applications et utilisateurs.
• Durabilité (Durability) : Les effets d’une transaction bien « committed » persistent même en cas de défaillance du système.

Sans la puissance et la sophistication de i5/OS et de DB2, il serait pratiquement impossible de s’assurer que les applications remplissent tous les critères ACID. Heureusement, il est facile d’effectuer des transactions fiables sur le i5 quand les applications bénéficient de la journalisation et du contrôle de commitment : deux fonctions intégrées dans l’architecture i5 depuis le S/38.

Deux de ces critères, la cohérence et la durabilité, sont plutôt simples et assurés automatiquement, pour la plupart, par DB2. Pour maintenir la cohérence de la base de données, DB2 rejette les mises à jour qui violent les contraintes suivantes d’une table : clé primaire, unique, clé étrangère, ou vérification. Les développeurs d’applications n’ont que deux choses à faire :

• Définir les contraintes appropriées sur l’instruction Create Table SQL ou sur la commande CL Add Physical File Contrainst (AddPfCst).
• Ajouter le code applicatif nécessaire pour détecter et traiter les erreurs d’I/O, y compris les violations de contraintes.

La durabilité est instaurée quand une table est journalisée: c’est ce qui se passe par défaut quand on crée une table avec une instruction SQL Create Table. On peut aussi utiliser la commande CL JrnPf pour journaliser une table (ou un fichier physique non-SQL). Quand une table est journalisée, le système écrit une entrée dans un récepteur du journal et l’envoie de force en stockage auxiliaire avant que la table de base de données associée ne soit physiquement modifiée. Quand une table est ouverte sous le contrôle de commitment, le système écrit aussi les entrées du journal pour les opérations commit et rollback.

Si une table est endommagée, vous pouvez récupérer ses mises à jour en restaurant la table à l’aide de la sauvegarde la plus récente puis en appliquant les entrées du journal pour amener la table au niveau de la dernière opération de mise à jour ou de la dernière transaction « committed ». La journalisation des tables est une bonne pratique que l’on devrait appliquer systématiquement pour la plupart des tables de base de données. (Vous trouverez de la documentation sur la journalisation dans la rubrique Systems ManagementIJournal Management dans le V5R4 Information Center.) DB2 prend aussi en charge le principe de « toutes ou aucune » transactions (c’est-à-dire l’atomicité) et plusieurs niveaux d’isolation des transactions. Bien que ce soient des aspects distincts du support des transactions, sur l’i5 ils sont tous assurés par l’environnement de contrôle de commitment i5/OS. Le contrôle de commitment, à son tour, compte sur la journalisation pour garantir le principe « toutes ou aucune » tra

WindowsTirez la quintessence de votre base de données grâce à  RPG & SQL !

Aidez-vous des résultats de nos tests pour accroître la vitesse et de l'efficacité de vos applications.Qu'il s'agisse de développer de nouvelles "e-applications" ou d'améliorer d'anciennes "t-applications " (applications traditionnelles), les performances de la base de données est souvent le facteur prépondérant dans la rapidité du logiciel. La satisfaction de la direction et des clients est proportionnelle à la rapidité d'obtention des données. Avec DB2 Universal Database for AS/400 (DB2 UDB), on peut améliorer considérablement les performances applicatives (éventuellement en multipliant plusieurs fois le débit de l'application non optimisée) en choisissant judicieusement la méthode de mise en œuvre et de configuration.

La satisfaction de la direction et des clients est proportionnelle à la rapidité d'obtention des données

Pour obtenir des données concrètes à l'appui de ces types de décisions, j'ai effectué de nombreux benchmarks en utilisant les versions V4R4 de RPG IV et SQL. Certaines constatations sont étonnantes et mettent à nu la manière dont ces langages et DB2 UDB pratiquent l'accès aux bases de données.
Après avoir étudié ces résultats et en avoir discuté avec les IBMers de Rochester, j'ai conclu que les seuls manuels AS/400 ne sont pas suffisants pour optimiser les performances des bases de données. Tandis qu'avec les données et les analyses comparatives de cet article, vous pourrez pousser vos applications dans leurs derniers retranchements. Et aussi comparer les performances des I/O intégrées et du SQL imbriqué dans le RPG IV. (Si vous découvrez le coding SQL, voyez l'encadré " Quelques canevas SQL pour programmeurs RPG", qui fournit des information sur un article en ligne démontrant les techniques de coding SQL/400 pour programmeurs RPG.)