WebSphere Enterprise Service Bus, Version 6.2.0 Systèmes d'exploitation: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Mise à niveau manuelle de Cloudscape

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 : 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
  1. 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.
  2. Architecture Network Server uniquement : Mettez la base de données hors ligne. Aucun client ne peut y accéder durant le processus de migration.
  3. 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 :
    • For Linux operating systemFor UNIX operating system Sur les plateformes Linux® et UNIX® : Utilisez le script db2jmigrate.sh qui se trouve dans le répertoire suivant : racine_installation/derby/bin/embedded/...
    • For Windows operating system 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.
  4. 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.
    1. 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.
    2. Sélectionnez le nom du serveur.
    3. Cliquez sur Modifier les niveaux de détail de consignation.
    4. Facultatif : Si l'option Tous les composants est activée, il est souhaitable de la désactiver, puis d'activer les composants spécifiques.
    5. 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.
    6. 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.

    7. Sélectionnez Appliquer, puis OK.
  5. 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.
  6. 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)
  7. 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


task Rubrique relative à une tâche

Conditions d'utilisation | Commentaires en retour


Icône d'horodatage Dernière mise à jour: 07 juillet 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/tdat_vtv_mancloudsmig.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
Ce centre d'information est mis en service par la technologie Eclipse (http://www.eclipse.org).