Für WebSphere ESB Version 6.2 muss Cloudscape in der Mindestversion
10.1.x vorliegen. (Bitte beachten Sie, dass Cloudscape v10.1.x
aus der Codebasis von Apache Derby Version 10.1. besteht.) Während des Upgrades von WebSphere ESB Version 6.2 führt das Migrationstool automatisch ein Upgrade der Datenbankinstanzen durch, auf die einige interne Komponenten, wie z. B. die UDDI-Registry, über das eingebettete Framework zugreifen. Das Tool versucht außerdem, ein Upgrade der Cloudscape-Instanzen durchzuführen, auf die Ihre Anwendungen über das eingebettete Framework zugreifen. Sie müssen die Migrationsergebnisse für diese Back-End-Datenbanken überprüfen.
Vorbereitende Schritte
Cloudscape v10.1.x darf nicht als Produktionsdatenbank verwendet werden.
Verwenden Sie das Programm nur für Entwicklungs- und Testzwecke.
Weitere Informationen: Die neue Version von Cloudscape stattet die Derby-Laufzeit mit weiteren Vorteilen aus, wie z. B. IBM® Quality Assurance (QA) und der Unterstützung landessprachlicher Versionen (NLS). Informationen zur Open-Source-Codebasis
von Cloudscape v10.1.x
finden Sie auf den
Cloudscape-Produktwebseiten.
Das Migrationstool versucht, ein Upgrade der Cloudscape-Datenbankinstanzen durchzuführen, auf die nur über das eingebettete Framework zugegriffen wird. Sie müssen ein Upgrade der Cloudscape-Instanzen manuell durchführen, die mit Servern im Derby Network Server-Framework Transaktionen durchführen. (Siehe Cloudscape-Upgrade manuell durchführen.) Durch diese Anforderung wird verhindert, dass Anwendungen anderer Anbieter beschädigt werden, die mithilfe des Network Server-Frameworks auf dieselben Datenbankinstanzen zugreifen wie WebSphere ESB.
Andere Anwendungen können auf Cloudscape unter Network Server zugreifen, da das Framework der Datenbank eine Konnektivitätssoftwarebasis bereitstellt; dies ist beim eingebetteten Framework nicht der Fall. Cloudscape Network Server kann mit mehreren JVMs (Java™ Virtual
Machines) (oder Servern) gleichzeitig Transaktionen ausführen, wohingegen Cloudscape im eingebetteten Framework mit nur einer einzelnen JVM ausgeführt werden kann. In Gruppen zusammengefasste oder koexistierende Implementierungen von WebSphere ESB benötigen
Network Server. Weitere Informationen finden Sie im IBM Cloudscape Information Center.
Informationen zu diesem Vorgang
Bei Datenbankinstanzen, auf die Ihre Anwendungen über das eingebettete Framework zugreifen, kann die automatische Migration völlig fehlerfrei durchgeführt werden, völlig fehlschlagen oder mit Warnungen erfolgreich durchgeführt werden. Von einer Migration, bei der Warnungen auftreten, wird eine Cloudscape v10.1.x-Datenbank mit Ihren Daten erstellt, aber es wird nicht Ihre gesamte konfigurierte Logik und es werden z. B. nicht die unten aufgeführten Einstellungen migriert:
- Schlüssel
- Prüfungen
- Sichten
- Auslöser
- Aliasnamen
- Gespeicherte Prozeduren
Zur Unterscheidung einer teilweisen und einer völlig fehlerfreien Migration müssen Sie die Ergebnisse der automatischen Migration überprüfen, indem Sie das allgemeine Upgradenachbereitungsprotokoll und die einzelnen Datenbankprotokolle überprüfen.
Durch die Ausführung dieser Tasks erhalten Sie grundlegende Diagnosedaten, um Fehler in den teilweise migrierten Datenbanken wie auch in den Datenbanken zu beheben, bei denen die automatische Migration vollständig fehlgeschlagen ist. Letztendlich migrieren Sie diese Datenbanken in einem manuellen Prozess.
Vorgehensweise
- Öffnen Sie das Upgradenachbereitungsprotokoll für jedes neue Profil von WebSphere ESB Version 6.2. Der Pfadname des Protokolls lautet installationsstammverzeichnis/profiles/profilname/logs/WASPostUpgrade.zeitmarke.log.
- Überprüfen Sie das Upgradenachbereitungsprotokoll auf Datenbankfehlernachrichten. Diese Ausnahmebedingungen weisen auf Datenbankmigrationsfehler hin. Die folgenden Zeilen sind ein Beispiel für den Inhalt eines Upgradenachbereitungsprotokolls, in dem der Datenbankfehlercode DSRA7600E lautet. (Das Migrationstool gibt alle Datenbankausnahmebedingungen mit dem Präfix DSRA an.)
MIGR0344I: Die Konfigurationsdatei /opt/WebSphere60/AppServer/cloudscape
/db2j.properties wird verarbeitet.
MIGR0344I: Die Konfigurationsdatei /opt/WebSphere60/AppServer/config/cells
/migr06/applications/MyBankApp.ear/deployments/MyBankApp/deployment.xml wird verarbeitet.
DSRA7600E: Die Cloudscape-Migration der Datenbankinstanz /opt/WebSphere61/Express
/profiles/default/databases/_opt_WebSphere60_AppServer_bin_DefaultDB ist fehlgeschlagen.
Ursache: java.sql.SQLException: Failure creating target db
MIGR0430W: Die Cloudscape-Datenbank /fvt/temp/60BaseXExpress/PostUpgrade50BaseFVTTest9
/testRun/pre/websphere_backup/bin/DefaultDB konnte n icht in die Datenbank<neuer_datenbankname> migriert werden.
Wichtig: Wenden Sie sich an die IBM WebSphere ESB-Unterstützungsfunktion, wenn eine Migrationsfehlernachricht für eine Cloudscape-Instanz angezeigt wird, auf die eine interne WebSphere-Komponente zugreift (d. h. eine Komponente, die ein Teil von WebSphere ESB ist und nicht zu einer anderen Anwendung gehört).
- Öffnen Sie für jede Ihrer Back-End-Cloudscape-Datenbanken das entsprechende Datenbankmigrationsprotokoll. Diese Protokolle haben dieselbe Zeitmarke wie das allgemeine Upgradenachbereitungsprotokoll. Die Protokolle enthalten mehr Details zu den im allgemeinen Upgradenachbereitungsprotokoll aufgeführten Fehlern. Außerdem werden in diesen Protokollen Fehler offen gelegt, die im allgemeinen Protokoll nicht dokumentiert sind.
Der Pfadname jedes Datenbankprotokolls lautet WAS_HOME/profiles/profilname/logs/meinVollständigerDatenbankpfadname_migrationLogzeitmarke.log.
- Überprüfen Sie jedes Datenbankmigrationsprotokoll auf Fehler. Für eine völlig fehlerfreie Migration zeigt das Protokoll eine Nachricht an, die dem folgenden Text ähnelt:
MIGR0429I: Die Cloudscape-Datenbank F:\temp\60BaseXExpress\PostUpgrade50BaseFVTTest2\testRun
\pre\websphere_backup\bin\DefaultDB wurde ordnungsgemäß migriert. Schauen Sie sich das Protokoll C:\WebSphere61\Express\profiles\default\logs\DefaultDB_migrationLogSun-Dec-18-13.31.40-CST-2005.log an.
Andernfalls werden die Fehlernachrichten vom Protokoll im Format des folgenden Beispiels angezeigt:
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
- Weitere Daten zu einem Migrationsfehler finden Sie im Debugprotokoll, das dem Datenbankmigrationsprotokoll entspricht. Das Migrationsprogramm von WebSphere Application Server löst standardmäßig einen Debugmigrationstrace aus. Diese Tracefunktion generiert die Datenbankdebugprotokolle. Der vollständige Pfadname eines Debugprotokolls lautet WAS_HOME/profiles/profilname/logs/meinVollständigerDatenbankpfadname_migrationDebugzeitmarke.log.
Die folgenden Zeilen sind ein Beispiel eines Debugtextes. Die Zeilen stellen ausführliche Ausnahmedaten für den Fehler dar, der im vorherigen Beispiel der Datenbankmigrationsprotokolldaten angegeben wurde.
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
Ergebnisse
- Das Migrationsprogramm von WebSphere ESB ändert Ihre Cloudscape-JDBC-Konfigurationen ungeachtet einer fehlerlosen oder fehlerhaften Migration der Datenbankinstanzen, auf die Ihre Anwendungen zugreifen. Das Tool ändert die Cloudscape-JDBC-Providerklassenpfade, die Datenquellenimplementierungsklassen und die Datenquellenunterstützungsklassen. In der folgenden Tabelle werden diese Änderungen beschrieben:
Tabelle 1. Neue KlasseninformationenKlassentyp |
Alter Wert |
Neuer Wert |
JDBC-Providerklassenpfad |
${CLOUDSCAPE_JDBC_DRIVER_PATH}/db2j.jar |
${DERBY_JDBC_DRIVER_PATH}/derby.jar- Dabei ist DERBY_JDBC_DRIVER_PATH die WebSphere-Umgebungsvariable, die Ihren
Cloudscape-JDBC-Provider definiert.
- Dabei ist derby.jar der Basisdateiname der JDBC-Treiberklassendatei. (Geben Sie in Ihrer Umgebung die JDBC-Treiberklassendatei mit dem vollständigen Pfadnamen an.)
|
Datenquellenimplementierungsklasse: Verbindungspool |
com.ibm.db2j.jdbc.DB2jConnectionPool DataSource |
org.apache.derby.jdbc.EmbeddedConnection PoolDataSource |
Datenquellenimplementierungsklasse: XA |
com.ibm.db2j.jdbc.DB2jXADataSource |
org.apache.derby.jdbc.EmbeddedXADataSource |
Datenquellenunterstützungsklasse |
com.ibm.websphere.rsadapter.Cloudscape DataStoreHelper |
com.ibm.websphere.rsadapter.Derby DataStoreHelper |
Darüber hinaus ändert die Datei db2j.properties Folgendes:- Der Name WAS_HOME/cloudscape/dbj.properties wird in WAS_HOME/derby/derby.properties geändert.
- In der Datei werden Merkmalnamen von db2j.drda.* in derby.drda.* geändert.
- Eine teilweise oder völlig fehlerfreie Datenbankmigration ändert die Position und den Namen der Datenbank entsprechend dem folgenden Beispiel:
- Alter Datenbankname: c:\temp\meinedatenbank
- Neuer Datenbankname: Der neue Name schließt einen Hashcode mit ein, der eine Kombination aus dem vollständigen Pfadnamen der alten Datenbank und der Migrationszeitmarke bildet. Der neue Name enthält außerdem den alten Datenbanknamen und die ausführliche Darstellung der Zeitmarke. Beispiel: installationsstammverzeichnis\profiles\profile_name\databases\meinedatenbank_hashcode_zeitmarke
Beachten Sie die exakten Pfadnamen: Bei teilweisen oder fehlgeschlagenen Migrationen enthalten die Protokollnachrichten die exakten alten und neuen Datenbankpfadnamen, die Sie verwenden müssen, um die manuelle Migration auszuführen. Beachten Sie diese neuen Pfadnamen genau.
Nächste Schritte
Versuchen Sie bei einer teilweisen Migration, nur dann Fehler in der neuen v10.1.x-Datenbank zu beheben, wenn Sie ein Experte im Umgang mit Cloudscape sind. Andernfalls löschen Sie die neue Datenbank. Führen Sie die manuelle Migrationsprozedur für die ursprüngliche Datenbank wie bei jeder anderen Datenbank aus, bei der die automatische Migration vollständig fehlgeschlagen ist.
Anweisungen hierzu finden Sie unter
Cloudscape-Upgrade manuell durchführen.
Beachten Sie bei erfolgreich migrierten Cloudscape-Instanzen, dass neue zellweite Datenquellen nur von Knoten verwendet werden können, auf denen Version 6.0.2 oder höher von
WebSphere ESB ausgeführt wird. Ältere Versionen des Produkts unterstützen nicht die neue Version von Cloudscape; wenn Anwendungen auf Knoten mit Versionen vor Version 6.0.2 versuchen, auf eine Cloudscape 10.1.x-Datenquelle zuzugreifen, gibt der Server während der Ausführung Ausnahmebedingungen aus.