Lors de la mise à niveau de WebSphere ESB version 6.2, les outils de migration tentent uniquement de mettre à niveau les instances de Cloudscape accessibles à l'aide de l'architecture intégrée. (la nouvelle version de Cloudscape est la version
10.1.x, basée sur Derby). La mise à niveau automatique exclut les instances Cloudscape
pour lesquelles existent des transactions avec des applications via l'architecture Network Server. Cette exclusion élimine le risque d'altération des applications tierces
accédant aux mêmes instances de base de données que WebSphere ESB.
Vous devez mettre à niveau manuellement les instances de base de données accessibles via l'architecture
Network Server. Vous devez faire de même pour les bases de données dont migration automatique échoue.
Avant de commencer
N'utilisez pas Cloudscape v10.1.x en tant que base de données de production.
Utilisez cette base de données uniquement pour les activités de développement et de test.
En savoir plus : La nouvelle version de Cloudscape combine l'environnement d'exécution Derby et des avantages supplémentaires tels que l'assurance qualité IBM® Quality Assurance (QA) et un support multilingue (NLS).
Pour les instances de Cloudscape accessibles via l'architecture intégrée, déterminez pour quelles instances le processus de mise à niveau automatique a échoué et celles pour lesquelles une seule mise à niveau partielle a été accomplie. La
Vérification de la migration automatique de Cloudscape v10.1.x décrit la méthode permettant de détecter les erreurs de base de données et de diagnostiquer les données à partir des différents journaux de migration. Les messages journalisés contiennent les noms exacts des chemins d'accès nouveaux et anciens que vous devez spécifier pour exécuter la migration manuelle. Notez soigneusement ces chemins d'accès.
Pour réduire les risques d'erreurs de migration sur les bases de données dont seule une mise à niveau partielle a été effectuée durant la mise à niveau automatique, supprimez la nouvelle base de données. Résolvez les incidents affectant la base de données d'origine conformément aux données de diagnostic journalisées, puis procédez à la migration manuelle de la base de données d'origine.
Pourquoi et quand exécuter cette tâche
La section suivante comprend les étapes permettant de faire migrer les instances Cloudscape accessibles par les deux architectures (intégrée et Network
Server). Les étapes qui s'appliquent uniquement à l'architecture Cloudscape Network Server sont indiquées le cas échéant. Lors d'une migration, il convient de s'assurer que votre ID utilisateur est
doté de l'un des droits suivants :
- Administrateur du serveur accédant à l'instance Cloudscape
- Une référence "umask" permettant d'accéder à l'instance du gestionnaire de bases de données
Dans le cas contraire, des erreurs d'exécution risquent de signaler l'accès en lecture seule de l'instance de base de données.
Procédure
- Architecture Network Server uniquement : Assurez-vous que chaque client de la base de données Cloudscape prend en charge Cloudscape v10.1.x. Les clients WebSphere ESB de la
base de données doivent exécuter les versions 6.0.1.x ou supérieures de WebSphere ESB.
- Architecture Network Server uniquement : Mettez la base de données hors ligne. Aucun client ne peut y accéder durant le processus de migration.
- Examinez un exemple de script de migration de Cloudscape fourni par WebSphere ESB. Selon le système d'exploitation que vous utilisez, WebSphere ESB fournit un des scripts de migration suivants :

Sur les plateformes Linux® et UNIX® : Utilisez le script db2jmigrate.sh qui se trouve dans le répertoire suivant : racine_installation/derby/bin/embedded/...
Sur les plateformes Windows® : Utilisez le script db2jmigrate.bat qui se trouve dans le répertoire suivant : racine_installation\derby\bin\embedded\...
Vous pouvez modifier le script suivant les exigences de votre environnement. Consultez la section Migration d'IBM Cloudscape vers la version 10 pour plus d'informations sur les options utilisables avec ce script. Vous pouvez par exemple définir
l'option -DB2j.migrate.ddlFile=nom_fichier pour spécifier le fichier
DDL de la nouvelle base de données.
- Pour générer des journaux de débogage de la base de données lors de l'exécution du script de migration, assurez-vous que la fonction debug migration trace est activée. Par défaut, cette fonction de trace
est activée. Si la fonction de trace de débogage est désactivée, réactivez-la.
- Pour définir les options de trace dans la console d'administration, cliquez sur Résolution des incidents > Consignation et trace dans l'arborescence de navigation de la console.
- Sélectionnez le nom du serveur.
- Cliquez sur Modifier les niveaux de détail de consignation.
- Facultatif : Si l'option Tous les composants est activée, il est souhaitable de la désactiver, puis d'activer les composants spécifiques.
- Facultatif : Sélectionnez un nom de composant ou de groupe.
Pour plus d'informations, voir la rubrique Paramètres du niveau de consignation dans le centre de documentation WebSphere Application Server Network Deployment,
version 6.1. Si le serveur sélectionné n'est pas en cours d'exécution, il n'est pas possible de visualiser individuellement chaque composant en mode graphique.
- Entrez une chaîne de trace dans la zone correspondante. Dans ce cas, entrez l'une des valeurs suivantes :
- all traces*=all
- com.ibm.ws.migration.WASUpgrade=all
Pour plus d'informations sur la fonction de trace, consultez la rubrique Utilisation de la fonction de trace dans le centre de documentation WebSphere Application Server Network Deployment,
version 6.1.
- Sélectionnez Appliquer, puis OK.
- Indiquez le nom de l'ancienne base de données ainsi que le chemin d'accès complet de postmigration de la nouvelle base de données lors de l'exécution du script. Exemple : E:\WebSphere\ProcServer\derby\bin\embedded>db2jMigrate.bat ancienne_base nouvelle_base Les journaux générés lors de la migration automatique contiennent les noms exacts des chemins d'accès à indiquer
à la fois pour l'ancienne base de données et la base cible.
Vous devez utiliser ce nom de base de données cible pour spécifier la nouvelle base de données, car les sources de données Cloudscape migrées (mises à jour via les utilitaires de migration WebSphere ESB) pointent désormais vers le nom de la base de données cible. L'exemple de texte suivant illustre la manière dont les messages indiquent les noms des bases de données cible :
Cloudscape migration of database instance C:\temp\migration2\profiles\Srv01\
installedApps\ghongellNode01Cell\DynamicQuery.ear\EmployeeFinderDB to
new database instance C:\WebSphere\ESB
\profiles\Srv01\databases\C__WAS602_ProcServer_profiles_ProcSrv01_
installedApps_ghongellNode01Cell_DynamicQuery.ear_
EmployeeFinderDB failed, reason: java.sql.SQLException:
Failure creating target db
Pour les instances de Cloudscape accessibles via l'architecture Network Server, indiquez un nom pour la nouvelle base de données. N'oubliez pas de modifier les sources de données existantes de sorte qu'elles pointent vers le nom de la nouvelle base de données.
- A la fin du processus de migration, examinez les résultats dans le journal de migration de la base de données. Le chemin d'accès au journal de migration de chaque base de données est
racine_installation/logs/derby/myFulldbPathName_migrationLog.log.
Dans le cas d'une migration complète, le journal de migration de base de données consigne un message similaire au texte suivant :
Check E:\WebSphere\ESB\derby\myOldDB_migrationLog.log for progress
Migration Completed Successfully
E:\WebSphere\ESB\derby\bin\embedded>
Dans le cas contraire, le journal consigne les messages d'erreur dans le format de l'exemple suivant :
Check E:\WebSphere\ESB\derby\myOldDB_migrationLog.log for progress
ERROR: An error occurred during migration. See debug.log for more details.
ERROR XMG02: Failure creating target db
java.sql.SQLException: Failure creating target db
at com.ibm.db2j.tools.migration.MigrationState.getCurrSQLException(Unknown Source)
at com.ibm.db2j.tools.migration.MigrateFrom51Impl.handleException(Unknown Source)
at com.ibm.db2j.tools.migration.MigrateFrom51Impl.go(Unknown Source)
at com.ibm.db2j.tools.migration.MigrateFrom51Impl.main(Unknown Source)
at com.ibm.db2j.tools.MigrateFrom51.main(Unknown Source)
- Pour plus d'informations sur une erreur de migration, consultez le journal de débogage
correspondant au journal de migration de la base de données. Le chemin d'accès complet à un journal de débogage est racine_installation/logs/derby/myFulldbPathName_migrationDebug.log
Les lignes suivantes montrent un exemple du texte de débogage.
sourceDBURL=jdbc:db2j:E:\WebSphere\myOldDB
newDBURL=jdbc:derby:e:\tempo\myNewDB
ddlOnly=false
connecting to source db <jdbc:db2j:E:\WebSphere\myOldDB>
connecting to source db <jdbc:db2j:E:\WebSphere\myOldDB> took 0.611 seconds
creating target db <jdbc:derby:e:\tempo\myNewDB>
creating target db <jdbc:derby:e:\tempo\myNewDB> took 6.589 seconds
initializing source db data structures
initializing source db data structures took 0.151 seconds
recording DDL to create db <E:\WebSphere\myOldDB>
recording DDL to create db <E:\WebSphere\myOldDB> took 5.808 seconds
Résultats
Comme indiqué au cours des étapes précédentes, le journal de migration de base de données affiche soit un message du type
Migration Completed Successfully (la migration a abouti), soit un message
contenant les exceptions relatives à l'échec de la migration.
Que faire ensuite
- Pour les bases de données dont la migration a échoué, identifiez les incidents d'après les données d'erreur consignées. Ensuite, exécutez à nouveau le script de migration.
- Pour accéder aux bases de données migrées avec succès via l'architecture imbriquée,
modifiez les sources de données de manière à ce qu'elles pointent vers les nouveaux noms de base de données.
- Pour accéder aux bases de données mises à niveau correctement via l'architecture Network Server, vous pouvez soit utiliser le pilote JDBC DB2 Universal ou le pilote JDBC Derby Client.
- Si vous souhaitez que les configurations JDBC existantes continuent d'utiliser le pilote JDBC DB2 Universal, modifiez les sources de données de manière à ce qu'elles pointent vers les nouveaux noms de base de données.
- Si vous souhaitez utiliser le pilote JDBC Derby Client, qui peut prendre en charge les sources de données XA, modifiez les fournisseurs JDBC de manière à ce qu'ils utilisent la nouvelle classe de pilote JDBC Derby Client et les nouvelles classes d'implémentation de sources de données.
Ensuite, configurez à nouveau
chacune des sources de données existantes de manière à ce qu'elles utilisent la classe auxiliaire de source de données Derby correcte et pointent vers le nouveau nom de base de données.
Consultez la rubrique Paramètres minimum requis pour les sources de données, par fournisseur
dans le centre de documentation de WebSphere Application Server Network Deployment,
version 6.1, pour tous les nouveaux noms de classe.
- Exécutez les scripts de mise à niveau de base de données dans le répertoire racine_installation/dbscripts/nom_composant/Derby pour mettre à niveau le schéma et les tables de base de données au niveau de WebSphere ESB version 6.2.
Pour plus d'informations,
reportez-vous à la rubrique Mise à niveau des bases de données en vue d'une migration.