Cet article explique principalement comment terminer le processus de transplantation du système d'application PHP basé sur DB2 de la plate-forme AIX vers la plate-forme Linux. L'article contient les étapes détaillées de la transplantation de la base de données DB2 sous-jacente et du système d'application PHP de couche supérieure, ainsi que les problèmes et les solutions qui peuvent être rencontrés au cours du processus de transplantation.
Présentation des tâches
Le travail de migration du système est principalement divisé selon les aspects suivants :
1. Migration multiplateforme du système de base de données DB2
2. Installation et configuration du serveur Apache et du système d'application PHP
Ci-dessous, nous présenterons les étapes spécifiques de la migration et de la configuration sous deux aspects. .
Migration multiplateforme du système
de base de données DB2 Environnement de base de données
Environnement source : AIX+DB2 v8.1
Environnement cible : Linux+DB2 v8.1
La base de données source contient 2 instances de base de données : SRCDB1 et SRCDB2. La base de données SRCDB1/SRCDB2 contient des centaines de tables de base de données et possède de nombreux index, contraintes de clé étrangère, déclencheurs, procédures stockées et certaines tables avec des champs à incrémentation automatique (tables avec des champs définis GENERATED ALWAYS AS IDENTITY). Pour rendre les choses encore plus difficiles, nous ne disposons pas de scripts de création précis pour ces objets de base de données.
Sélection du plan de migration
Si le système source et le système de destination à migrer appartiennent au même type de système d'exploitation, comme par exemple une migration entre Linux ou une migration entre systèmes AIX, la situation est relativement simple. DB2 lui-même a fourni des outils pratiques pertinents pour y parvenir. . Migration de bases de données entre plateformes du même type, telles que les commandes BACKUP et RESTORE. Bien entendu, selon la situation, vous devez avoir une compréhension claire des paramètres fournis par l'utilitaire. Par exemple, si le système source et le système cible utilisent des espaces table différents, le problème de la redirection de l'espace table sera impliqué. Cet article étant axé sur la transplantation multiplateforme, cette solution ne peut évidemment pas répondre aux besoins et ne sera pas abordée ici.
Alors, comment gérer les problèmes de migration de bases de données multiplateformes ? Est-il possible d'utiliser l'utilitaire db2move ? db2move peut uniquement migrer les données des tables, mais ne peut pas migrer les objets de base de données tels que les index, les contraintes de clé étrangère, les déclencheurs et les procédures stockées. De plus, db2move présente également certaines limitations pour les tables contenant des données de champ à incrémentation automatique. Et db2move peut uniquement importer des données dans des tables de base de données existantes et ne peut pas afficher l'emplacement de l'espace table spécifié. Étant donné que lors du processus de migration du système de base de données, non seulement les données des tables doivent être migrées, mais également les objets de la base de données tels que les index, les contraintes de clé étrangère, les déclencheurs et les procédures stockées. Par rapport à la solution sélectionnée dans cet article, cette dernière a. plus d'avantages. Vous pouvez utiliser db2move uniquement comme alternative à la migration des données de table.
Pour l'exportation et l'importation, vous ne pouvez exporter et importer qu'une seule table à la fois, et vous devez saisir manuellement les commandes d'exportation et d'importation ainsi que le nom de la table de données à importer et exporter lorsque le nombre de tables de base de données n'est pas important. , cette option peut encore être envisagée, mais ce n'est pas la meilleure option. Dans le cas d'un grand nombre de tables dans la base de données, cette approche est fondamentalement irréaliste et la commande d'importation ne garantit pas que les données des champs auto-incrémentés seront cohérentes avec les données de la table d'origine.
Basé sur le mécanisme de traitement des objets de base de données de DB2, cet article utilise une méthode qui combine db2look avec des scripts DDL et DML et gère séparément les déclencheurs, les procédures stockées et les contraintes de clé étrangère dans la base de données d'origine pour fournir une solution DB2 multiplateforme réalisable pour migration du système de base de données.
Prenons SRCDB1 comme exemple pour présenter le processus global de migration de base de données dans ce cas. Il existe quatre modes de base de données : SRCDB1, ASN, DB2DBG et SQLDBA dans la base de données SRCDB1. Supposons que le nom d'utilisateur de la base de données SRCDB1 est user_srcdb1 et que le mot de passe est pw_srcdb1.
Opérations associées sur le système source (AIX)
1. Utilisez la commande db2look pour extraire la liste des scripts DDL qui génèrent les objets de base de données
. 1. Commande et paramètres db2look
# db2look -d SRCDB1 -e -o srcdb1.ddl -a -i user_srcdb1 -w pw_srcdb1
db2look : Générez du DDL pour recréer les objets défini dans la base de données
Syntaxe : db2look -d DBname [-e] [-u Creator] [-z Schema]
[-t Tname1 Tname2...TnameN] [-tw Tname] [-h] [-o Fname] [- a]
[- m] [-c] [-r] [-l] [-x] [-xd] [-f] [-fd] [-td x]
[-noview] [-i ID utilisateur] [- w password]
[ -v Vname1 Vname2 ... VnameN] [-wrapper WrapperName]
[-server ServerName] [-nofed]
-d : nom de la base de données, paramètre obligatoire
-e : extraire le fichier DDL requis pour répliquer la base de données, cette option générera un fichier DDL contenant un script pour les instructions
-o : Rediriger la sortie vers le nom de fichier donné, si l'option -o n'est pas spécifiée, la sortie par défaut est stdout
-a : Générer des statistiques pour tous les programmes créés, si cette option est spécifiée, il sera ignoré -option u
-i : Spécifiez l'ID utilisateur utilisé pour se connecter au serveur où se trouve la base de données
-w : Spécifiez le mot de passe utilisé pour se connecter au serveur où se trouve la base de données
2. Différenciez les scripts DDL des objets de base de données en fonction des différents types d'objets.
Étant donné que chaque donnée de table de la base de données source a été traitée par des objets de base de données tels que des déclencheurs et des procédures stockées, afin de garantir la cohérence et l'intégrité des données de la base de données, ces bases de données. les objets doivent être créés après l'importation de données pour empêcher l'exécution répétée d'objets de base de données tels que des déclencheurs et des procédures stockées afin de générer des données erronées lors de l'importation de données de table. Utilisez un éditeur de texte pour modifier le fichier srcdb1.ddl généré par db2look, divisez les instructions DDL qui créent des tables et des index, créez des contraintes de clé étrangère et créez des déclencheurs et des procédures stockées en quatre groupes, puis enregistrez-les sous les quatre scripts DDL suivants :
srcdb1_tables.ddl srcdb1_foriegnkeys.ddl
srcdb1_triggers.ddl srcdb1_procedures.ddl
srcdb1_tables.ddl : contient des instructions ddl pour créer SEQUENCE, UDF, TABLE, VIEW et d'autres objets de base de données.
Listing 2. Instruction srcdb1_tables.ddl
CREATE SEQUENCE "SRCDB1"."SAMPLE_SEQ_1" AS INTEGER
MINVALUE 1 MAXVALUE 9999999999
COMMENCER AVEC 1 INCREMENT BY 1;
CREATE FUNCTION " SRCDB1"." SAMPLE _FUNC_1" (
VARCHAR(254),
VARCHAR(25 4) ,
VARCHAR(254)
) RETOURNE VARCHAR(254)
EXEMPLE SPÉCIFIQUE _FUNC_1 ……;
CREATE
TABLE " SRCDB1"." SAMPLE _TAB_1" (
"TAB_COL1" CHAR(20) NOT NULL ,
"TAB_COL2" VARCHAR(70) NOT NULL ) ;
TABLE " SRCDB1"." SAMPLE _TAB_2" (…);
…
CREATE TABLE " SRCDB1"." SAMPLE _TAB_N" (…);
CREATE VIEW SRCDB1.SAMPLE_VIEW_1 (VIEW_COL1,VIEW_COL2) AS SELECT distinct
COL1 , COL2 FROM SAMPLE_TAB WHERE … …;
CREATE VIEW SRCDB1.SAMPLE_VIEW_2 …;
…
CREATE VIEW SRCDB1.SAMPLE_VIEW_N …;
srcdb1_foriegnkeys.ddl : contient l'instruction ddl pour créer des contraintes de clé étrangère.
Listing 3. Instruction srcdb1_foriegnkeys.ddl
ALTER TABLE " SRCDB1". "SAMPLE_FK_1"
ADD CONSTRAINT "SQL030903143850120" FOREIGN KEY
("FK_COL1")
RÉFÉRENCES " SRCDB1". "SAMPLE_TABLE"
("COL1")
; LE_FK_2 " ADD ……;
……
ALTER TABLE " SRCDB1"."SAMPLE_FK_N" ADD ……;
srcdb1_triggers.ddl : contient des instructions ddl pour créer des déclencheurs.
Listing 4. Instruction srcdb1_triggers.ddl
CREATE TRIGGER SRCDB1.SAMPLE_TRIG_1 AFTER UPDATE OF col1 ON SRCDB1.SAMPLE_TAB
RÉFÉRENCEMENT DE NEW AS n POUR CHAQUE LIGNE MODE DB2SQL WHEN ( n.col1 > 3)
BEGIN ATOMIC
update SAMPLE_TAB
set(col2) = 'anotherValue' où col1 = n.col1 ;--
CREATE
TRIGGER
SRCDB1 …
;
SRCDB1. SAMPLE_TRIG_N… ;
srcdb1_procedures.ddl : contient des instructions ddl pour créer des procédures stockées SQL et des procédures stockées Java.
Listing 5. Instruction srcdb1_procedures.ddl
CREATE PROCEDURE " SRCDB1"." JAVA_PROCEDURE_1" (
OUT SQLSTATE CHARACTER(5),
OUT ROWS_SUBMITED INTEGER,
IN BATCH_ID INTEGER,
IN LEVEL VARCHAR(4000)
)
JEUX DE RÉSULTATS DYNAMIQUES 0
SPECIFIQUE SUBMIT_BATCH
EXTERNE NOM 'Submit_batch ! submit_batch'
LANGUE PARAMÈTRE JAVA
STYLE JAVA
NON DÉTERMINISTE
CLÔTURE THREADSAFE
MODIFIE LES DONNÉES
SQL
NON
DBINFO
;
SPÉCIFIQUE
SRCDB1
.SQL_PROCEDURE_1
LANGAGE SQL
--------------------------------------- -------- ---
-- Procédure stockée SQL
---------------------------------- ----------- -------
P1 : BEGIN
……
END P1 ;
CREATE
PROCEDURE
SRCDB1.SQL_PROCEDURE_2
…… ;
La version db2 v6 de db2look n'a pas encore implémenté l'extraction telle que les instructions UDF, TRIGGER, UserSpace, NodeGroup, BufferPool et d'autres objets de base de données ddl. À partir de db2 v7, db2look peut extraire le DDL des objets ci-dessus, mais il ne peut toujours pas extraire l'instruction ddl qui crée l'objet de procédure stockée. À partir de db2 v8.2, la prise en charge de la fonction db2look a été améliorée et la fonction d'extraction des instructions ddl de procédure stockée a été implémentée. Étant donné que le système de base de données source impliqué dans cet article est d'une version inférieure (DB2 v8.1), la solution ci-dessus doit être adoptée pour obtenir les informations DDL de tous les objets de base de données :
1). D'un système DB2 v8.2 vers SRCDB1. (version DB2 v8.1) effectuez l'opération CATALOG :
db2 catalog db SRCDB1 en tant que SRCDB1 ;
2). Effectuez le processus d'extraction db2look sur SRCDB1 à partir du système DB2 v8.2 :
db2look -d SRCDB1 -e -o srcdb1.ddl -a -i user_srcdb1 -w pw_srcdb1
; Informations DDL de l'objet de base de données.
3. Générer un script d'exportation d'exportation de données
Utilisez un script shell pour générer et exporter un script DML pour toutes les données et le rediriger vers le fichier srcdb1_export.sql. Pour les utilisateurs familiarisés avec DB2, sachez que chaque table, vue et alias créés dans la base de données correspond à une ligne d'enregistrements dans SYSCAT.TABLES. Par conséquent, toutes les informations requises sur la table de base de données peuvent être obtenues via l'instruction de sélection de base de données correspondante. Si nécessaire, le script shell suivant sélectionnera les noms de table de toutes les tables de schéma d'onglets dans SRCDB1 qui sont SRCDB1, ASN, SQLDBA et DB2DBG en fonction du champ tabname de la table système SYSCAT.TABLES, et générera les instructions d'exportation correspondantes en fonction de leurs noms. . Atteindre l'objectif de l'exportation par lots. La fonction rtrim est utilisée pour supprimer les espaces sur le côté droit des données du champ tabname.
Listing 6. Générer le script d'exportation
# db2 "select 'export to ' rtrim(tabname) '.ixf of ixf select * from '
rtrim(tabname) ';' from syscat.tables
où tabschema in('SRCDB1', 'ASN', 'SQLDBA', 'DB2DBG')" > srcdb1_export.sql ;
modifiez le srcdb1_export.sql généré, supprimez les informations statistiques affichées dans l'en-tête et la queue et conservez uniquement les instructions d'exportation nécessaires. En modifiant les informations du schéma d'onglets contenues dans le script ci-dessus, vous pouvez spécifier la plage de tables à exporter, c'est-à-dire tous les noms de tables requis pendant le processus de migration. L'instruction export export générée a la forme de commande suivante :
db2 export to tablename.ixf of ixf select * from tablename
4. Générer un script de chargement pour l'importation de données
Utilisez un script shell pour générer un script de chargement pour importer des données dans le système cible : srcdb1_load.sql
Listing 7. Générer un script de chargement
# db2 "sélectionnez 'load from ' rtrim(tabname) '.ixf de ixf insérez dans '
rtrim( tabname) ';' de syscat.tables
où tabschema in ('SRCDB1', 'ASN', 'SQLDBA', 'DB2DBG')" > srcdb1_load.sql ;
Modifiez le srcdb1_load.sql généré et supprimez les statistiques de tête et de queue. , ne conservez que les instructions de chargement nécessaires. Semblable à l'instruction d'exportation, le script shell ci-dessus sélectionne les noms de toutes les tables de SRCDB1 à partir de la table système et génère les instructions d'importation correspondantes en fonction de leurs noms pour atteindre l'objectif d'importation par lots. Le formulaire de commande d'instruction import import généré est le suivant :
db2 chargement depuis tablename.ixf de ixf insert into tablename ;