WebSphere ESB version 6.2 nécessite l'exécution d'une version de Cloudscape au moins égale à v10.1.x. (il est à noter que Cloudscape v10.1.x est inclus dans le codebase d'Apache Derby version 10.1) Durant la mise à niveau de WebSphere ESB version 6.2, l'outil de migration met automatiquement à niveau les instances de base de données accessibles
à certains composants internes de l'architecture intégrée, tels que le registre UDDI. L'outil tente également de mettre à niveau les instances Cloudscape auxquelles vos applications accèdent via l'architecture intégrée. Les résultats de la migration
de ces bases de données dorsales nécessite que vous fassiez une vérification.
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 plus d'informations sur le code Open source de Cloudscape v10.1.x, consultez les
pages Web relatives au produit Cloudscape .
Les outils de migration tentent de mettre à niveau les instances de base de données Cloudscape accessibles via l'architecture intégrée uniquement. La mise à niveau des instances Cloudscape pour lesquels existent des instances avec des serveurs de l'architecture Derby Network Server doit être effectuée manuellement (pour plus d'informations, voir Mise à niveau manuelle de Cloudscape). Cette exigence élimine le risque d'altération des applications tierces
qui utilisent l'architecture Network Server pour accéder aux mêmes instances de base de données que WebSphere ESB.
L'accès des autres applications à Cloudscape sur Network Server est possible car l'architecture, contrairement à l'architecture intégrée, fournit un logiciel de connectivité en même temps que la base de données. Cloudscape Network Server peut effectuer des transactions avec plusieurs JVM (Java™ Virtual Machine) (ou serveurs) au même moment, tandis que Cloudscape associée à l'architecture intégrée ne fonctionne qu'avec une seule machine JVM. Les mises en oeuvre regroupées ou coexistantes
de WebSphere ESB requièrent
Network Server. Pour plus d'informations, voir le centre de documentation IBM Cloudscape.
Pourquoi et quand exécuter cette tâche
Pour les instances de base de données auxquelles vos applications accèdent par le biais de l'architecture imbriquée, la migration automatique peut, selon les cas, aboutir ou échouer entière, ou aboutir avec des avertissements. Une migration entraînant des messages d'avertissement crée bien une base de données Cloudscape v10.1.x avec vos données, mais n'effectue pas la migration de la logique configurée et de tous les autres paramètres, tels que :
- Clés
- Contrôles
- Vues
- Déclencheurs
- Alias
- Procédures stockées
Pour distinguer une migration complète d'une migration partielle,
vous devez vérifier les résultats de la migration automatique en consultant les journaux généraux post-migration et les journaux de base de données individuels.
L'exécution de ces tâches vous permet de disposer de données de
diagnostic essentielles pour résoudre les incidents affectant les bases de données partiellement migrées, ainsi que celles dont la migration automatique a totalement échoué. En dernier lieu, la migration de ces bases de données s'effectuera manuellement.
Procédure
- Ouvrez le journal de post-mise à niveau de chaque nouveau profil WebSphere ESB version 6.2. Le chemin d'accès au fichier journal est racine_installationprofiles/nom_profil/logs/WASPostUpgrade.horodatage.log.
- Examinez le fichier journal de post-mise à niveau et recherchez les messages d'erreurs relatifs aux bases de données. Ces exceptions indiquent des échecs lors de la migration des bases de données. Les lignes suivantes
sont un exemple de contenu d'un journal postérieur à une mise à niveau, dans lequel le code d'erreur de base de données
est DSRA7600E (l'outil de migration fait référence à toutes les
exceptions de base de données au moyen du préfixe DSRA).
MIGR0344I: Processing configuration file /opt/WebSphere60/AppServer/cloudscape
/db2j.properties.
MIGR0344I: Processing configuration file /opt/WebSphere60/AppServer/config/cells
/migr06/applications/MyBankApp.ear/deployments/MyBankApp/deployment.xml.
DSRA7600E: Cloudscape migration of database instance /opt/WebSphere61/Express
/profiles/default/databases/_opt_WebSphere60_AppServer_bin_DefaultDB failed,
reason: java.sql.SQLException: Failure creating target db
MIGR0430W: Cloudscape Database /fvt/temp/60BaseXExpress/PostUpgrade50BaseFVTTest9
/testRun/pre/websphere_backup/bin/DefaultDB failed to migrate <new database name>
Important : Contactez l'assistance IBM WebSphere ESB si vous constatez la présence d'un message d'erreur de migration concernant une instance Cloudscape un laquelle un composant interne WebSphere a accédé (c'est-à-dire un composant contribuant à contenir WebSphere ESB plutôt que l'une de vos applications).
- Ouvrez le journal individuel de migration de base de données associé à chacune de vos bases de données dorsales Cloudscape. Ces journaux sont marqués du même horodatage que celui du journal général de post-mise à niveau. Les journaux contiennent
davantage de détails sur les erreurs indiquées dans le journal général de post-mise à niveau et décrivent
les erreurs non documentées dans le journal général.
Le chemin d'accès de chaque journal de base de données est WAS_HOME/profiles/nom_profil/logs/myFulldbPathName_migrationLoghorodatage.log.
- Recherchez les erreurs éventuelles dans chaque journal de migration de base de données. Dans le cas d'une migration complète, le journal consigne un message similaire au suivant :
MIGR0429I: Cloudscape Database F:\temp\60BaseXExpress\PostUpgrade50BaseFVTTest2\testRun
\pre\websphere_backup\bin\DefaultDB was successfully migrated. See log C:\WebSphere61
\Express\profiles\default\logs\DefaultDB_migrationLogSun-Dec-18-13.31.40-CST-2007.log
Dans le cas contraire, le journal consigne les messages d'erreur dans le format de l'exemple suivant :
connecting to source db <jdbc:db2j:/fvt/temp/60BaseXExpress/PostUpgrade50BaseFVTTest9
/testRun/pre/websphere_backup/bin/DefaultDB>
connecting to source db <jdbc:db2j:/fvt/temp/60BaseXExpress/PostUpgrade50BaseFVTTest9
/testRun/pre/websphere_backup/bin/DefaultDB> took 0.26 seconds
creating target db <jdbc:derby:/opt/WebSphere61/Express/profiles/default/databases
/_opt_WebSphere60_AppServer_bin_DefaultDB>
ERROR: An error occurred during migration. See debug.log for more details.
shutting down databases
shutting down databases took 0.055 seconds
- 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. L'utilitaire de migration de WebSphere Application Server déclenche par défaut un débogage de trace de migration. Cette fonction génère les journaux du débogage de base de données. Le chemin d'accès complet à un journal de débogage est
WAS_HOME/profiles/nom_profil/logs/myFulldbPathName_migrationDebughorodatage.log.
Les lignes suivantes montrent un exemple du texte de débogage. Ces lignes comportent des données d'exception détaillées sur l'erreur référencée dans l'exemple de journal de migration
de base de données précédent.
java.sql.SQLException: Database_opt_WebSphere60_AppServer_bin_DefaultDB already exists.
Aborting migration
at com.ibm.db2j.tools.migration.MigrateFrom60Impl.go(Unknown Source)
at com.ibm.db2j.tools.migration.MigrateFrom60Impl.doMigrate(Unknown Source)
at com.ibm.db2j.tools.MigrateFrom60.doMigrate(Unknown Source)
at com.ibm.ws.adapter.migration.CloudscapeMigrationUtility.migr
Résultats
- L'utilitaire de migration de WebSphere ESB modifie vos configurations JDBC Cloudscape, quel que soit le résultat de la migration des instances de base de données auxquelles accèdent vos applications. L'outil modifie les chemins d'accès aux classes de fournisseur JDBC Cloudscape, les classes d'implémentation des sources de données, ainsi que les classes auxiliaires des sources de données. Le tableau suivant décrit ces modifications :
Tableau 1. Nouvelles informations de classeType de classe |
Ancienne valeur |
Nouvelle valeur |
Chemin d'accès aux classes JDBC |
${CLOUDSCAPE_JDBC_DRIVER_PATH}/db2j.jar |
${DERBY_JDBC_DRIVER_PATH}/derby.jar- Où DERBY_JDBC_DRIVER_PATH correspond à la variable d'environnement WebSphere qui définit votre fournisseur JDBC Cloudscape
- où derby.jar est le nom de base du fichier classe du pilote JDBC (dans votre environnement, référencez le fichier classe du pilote JDBC en indiquant le nom du chemin d'accès complet).
|
Classe d'implémentation de source de données : pool de connexions |
com.ibm.db2j.jdbc.DB2jConnectionPool DataSource |
org.apache.derby.jdbc.EmbeddedConnection PoolDataSource |
Classe d'implémentation de source de données : XA |
com.ibm.db2j.jdbc.DB2jXADataSource |
org.apache.derby.jdbc.EmbeddedXADataSource |
Classe auxiliaire de source de données |
com.ibm.websphere.rsadapter.Cloudscape DataStoreHelper |
com.ibm.websphere.rsadapter.Derby DataStoreHelper |
De plus, le fichier db2j.properties est modifié comme suit :- Le nom WAS_HOME/cloudscape/dbj.properties est modifié en WAS_HOME/derby/derby.properties
- Dans le fichier, les noms de propriété passent de db2j.drda.* à derby.drda.*
- Une migration de base de données partielle ou complète modifie l'emplacement et le nom de la base de données conformément à l'exemple suivant :
- Ancien nom de base de données : c:\temp\mydb
- Nouveau nom de base de données : Le nouveau nom inclut un code haché
qui combine le nom du chemin d'accès complet à l'ancienne base de données et l'horodatage de la migration. Le nouveau nom inclut également le nom de l'ancienne base de données et l'horodatage repris littéralement. Voici un exemple : racine_installation\profiles\nom_profil\databases\my_db_hashCode_timestamp
Notez les noms exacts des chemins d'accès : Aussi bien dans le cas de migrations partielles que de migrations ayant échoué, 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.
Que faire ensuite
Si une migration partielle a eu lieu, ne tentez de résoudre les incidents affectant la nouvelle base de données v10.1.x que si vous possédez une connaissance approfondie de Cloudscape. Dans le cas contraire, supprimez la nouvelle base de données. Procédez manuellement à la migration de la base de données originale, comme vous le feriez pour chaque base de données dont la migration automatique a échoué.
Voir
Mise à niveau manuelle de Cloudscape pour obtenir des instructions.
Pour les instances Cloudscape entièrement migrées, sachez que les nouvelles sources de données à portée de cellule ne sont utilisables que par des noeuds exécutant la version 6.0.2 ou une version ultérieure de WebSphere ESB. Les précédentes versions de ce produit ne prennent pas en en charge la nouvelle base de données Cloudscape. Lorsque des applications installées sur des noeuds antérieurs à la version 6.0.2 tentent d'accéder à une source de données Cloudscape 10.1.x, le serveur génère des exceptions au moment de l'exécution.