Déplacez et copiez des tables SQL facilement et efficacement. Par Paul Conte, dossier publié en Mai 2006 Les développeurs iSeries étendent le champ d’action de SQL pour créer des objets base de données. Au risque de rencontrer de nouvelles difficultés quand il s’agira de déplacer ou de copier des objets d’un schéma (c’est-à-dire, bibliothèque) ou système à un autre, en utilisant soit des commandes CL soit des opérations save/restore. Dans cet article, j’explique le déplacement et la copie des tables SQL, et j’y ajoute quelques conseils permettant de mener de telles opérations en douceur.
QUELQUES DEPLACEMENTS ET SAUVEGARDES AVEC LES TABLES SQL
Quand vous créez un schéma SQL à l’aide de l’instruction Create Schema, vous obtenez une bibliothèque OS/400 avec un journal, un récepteur de journal, et un ensemble de vues SQL qui mettent en oeuvre le catalogue SQL des objets base de données créés dans le nouveau schéma.
Quand vous utilisez l’instruction Create Table pour créer une nouvelle table SQL dans un schéma, vous obtenez un fichier physique monomembre qui est journalisé automatiquement sur le journal dans le même schéma par défaut. Il est généralement judicieux de journaliser les tables SQL actives, ainsi que les fichiers physiques créés à partir de DDS, parce que la journalisation favorise une bonne reprise de la base de données et est nécessaire pour l’isolation des transactions (contrôle de commitment) et pour les divers types de contraintes de base de données (par exemple, certaines formes de contraintes de clés étrangères).
Voici un bon tuyau : quand vous créez des contraintes de clés étrangères, assurez-vous que toutes les tables SQL (et les fichiers physiques DDS) qui sontassociées par une ou plusieurs clés étrangères, sont journalisées dans le même journal. Vous pourrez ainsi utiliser ce dernier pour la reprise afin que votre base de données maintienne l’intégrité référentielle parmi les tables associées.
Quand vous appliquez des entrées de journal pour récupérer une table ou un fichier dans un ensemble de tables et de fichiers associés par des contraintes de clés étrangères, vous devez appliquer les entrées du journal pour la totalité des tables et des fichiers associés. Vous devez aussi appliquer (ou supprimer) les entrées de journal à une limite de transaction, comme en spécifiant CmtBdy(*Yes) sur la commande Apply Journaled Changes (ApyJrnChg).
L’utilisation de la commande MovObj pour déplacer une table SQL journalisée vers un schéma différent sur le même système ne commute pas le journal. Et, quand on utilise CrtDupObj pour créer un double d’une table journalisée dans le même schéma ou dans un schéma différent, la nouvelle table n’est pas journalisée automatiquement.
Au lieu de CrtDup Obj, songez à utiliser la forme suivante de l’instruction Create Table, disponible à partir de la V5R2 :
Create Table –
As select-statement
With Data
Cette instruction journalisera automatiquement la nouvelle table. Vous pouvez aussi utiliser des commandes CL associées au journal pour gérer la journalisation de tables SQL. Par exemple, vous pouvez utiliser StrJrnPf et EndJrnPf pour commencer et terminer la journalisation d’une table. Si vous voulez que les nouvelles tables et les nouveaux fichiers physiques d’une bibliothèque (y compris ceux créés par une commande CrtDupObj) soient journalisés automatiquement, vous pouvez créer une zone de données nommée QDFJRN dans la bibliothèque et indiquer le nom de bibliothèque du journal dans les positions 1-10, le nom du journal dans les positions 11-20, et *FILE dans les positions 21-24.
Téléchargez cette ressource
Guide de Reporting Microsoft 365 & Microsoft Exchange
Comment bénéficier d’une vision unifiée de vos messageries, mieux protéger vos données sensibles, vous conformer plus aisément aux contraintes réglementaires et réduire votre empreinte carbone ? Découvrez la solution de reporting complet de l’utilisation de Microsoft Exchange, en mode on-premise ou dans le Cloud.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
