Während des Upgrades von WebSphere ESB Version 6.2 versuchen die Migrationstools, ein Upgrade der Instanzen von Cloudscape durchzuführen, auf die nur über das eingebettete Framework zugegriffen wird. (Die neue Version von Cloudscape ist die auf Derby basierende Version 10.1.x.) Das automatische Upgrade schließt Cloudscape-Instanzen aus, die mit Anwendungen über das Network Server-Framework Transaktionen durchführen. Durch diesen Ausschluss wird verhindert, dass Anwendungen anderer Anbieter beschädigt werden, die auf dieselben Datenbankinstanzen zugreifen wie WebSphere ESB.
Sie müssen für Datenbankinstanzen manuell ein Upgrade durchführen, auf die über das Network Server-Framework zugegriffen wird. Führen Sie dasselbe für Datenbanken aus, bei denen die automatische Migration fehlgeschlagen ist.
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).
Stellen Sie für Instanzen von Cloudscape fest, auf die über das eingebettete Framework zugegriffen wird, bei welchen Instanzen der automatische Upgradeprozess völlig fehlgeschlagen ist und bei welchen nur ein teilweises Upgrade durchgeführt wurde. Im Thema
Automatische Migration von Cloudscape v10.1.x prüfen wird beschrieben, wie Datenbankfehler erkannt und Diagnosedaten aus verschiedenen Migrationsprotokollen abgerufen werden. Die Protokollnachrichten enthalten die exakten alten und neuen Datenbankpfadnamen, die Sie verwenden müssen, um die manuelle Migration auszuführen. Beachten Sie diese neuen Pfadnamen genau.
Löschen Sie die neue Datenbank, um für Datenbanken, bei denen während des automatischen Migrationsprozesses das Upgrade nur teilweise durchgeführt wurde, das Risiko von Migrationsfehlern zu minimieren. Beheben Sie die Fehler in der ursprünglichen Datenbank anhand der Diagnosedaten aus dem Protokoll und führen Sie anschließend eine manuelle Migration der ursprünglichen Datenbank durch.
Informationen zu diesem Vorgang
Im folgenden Abschnitt werden die Migrationsschritte für Cloudscape-Instanzen aufgeführt, auf die über beide Frameworks, das eingebettete Framework und das Network Server-Framework, zugegriffen wird. Schritte, die nur für das Cloudscape Network Server-Framework gelten, sind entsprechend markiert. Es empfiehlt sich für die Migration sicherzustellen, dass Ihre Benutzer-ID über eine der folgenden Berechtigungen verfügt:
- Administrator des Servers, der auf die Cloudscape-Instanz zugreift
- umask, das auf die Datenbankinstanz zugreifen kann
Andernfalls erhalten Sie Laufzeitfehler darüber, dass die Datenbankinstanz schreibgeschützt ist.
Vorgehensweise
- Nur Network Server-Framework: Stellen Sie sicher, dass jeder Client der Cloudscape-Datenbank Cloudscape v10.1.x unterstützen kann. WebSphere ESB-Clients der Datenbank müssen von WebSphere ESB die Versionen 6.0.1.x oder höher ausführen können.
- Nur Network Server-Framework: Inaktivieren Sie die Datenbank. Während des Migrationsprozesses können keine Clients auf die Datenbank zugreifen.
- Untersuchen Sie eines der Musterscripts für die Cloudscape-Migration, die von
WebSphere ESB bereitgestellt werden. Abhängig von Ihrem Betriebssystem stellt WebSphere ESB eines der folgenden Migrationsscripts bereit:

Auf Linux®- und UNIX®-Plattformen: Verwenden Sie das Script db2jmigrate.sh, das sich im folgenden
Verzeichnis befindet: installationsverzeichnis/derby/bin/embedded/...
Auf Windows®-Plattformen:
Verwenden Sie das Script db2jmigrate.bat, das sich im folgenden Verzeichnis
befindet: installationsstammverzeichnis\derby\bin\embedded\...
Sie können das Script entsprechend den Anforderungen Ihrer Umgebung modifizieren. Wenn Sie Informationen zu den Optionen benötigen, die Sie zusammen mit dem Script verwenden können, lesen Sie die Angaben im Dokument Migrating IBM Cloudscape to Version 10. So können Sie z. B. die Option -DB2j.migrate.ddlFile=dateiname verwenden, um die DDL-Datei für die neue Datenbank anzugeben.
- Wenn Sie bei der Ausführung des Migrationsscripts, Datenbankdebugprotokolle generieren wollen, stellen Sie sicher, dass der Debugmigrationstrace aktiv ist. Diese Tracefunktion ist standardmäßig aktiviert. Reaktivieren Sie den Debug-Trace, falls dieser inaktiviert ist.
- Wenn Sie die Traceoptionen in der Administrationskonsole festlegen wollen, klicken Sie auf Fehlerbehebung > Protokollierung und Tracing in der Konsolennavigationsstruktur.
- Wählen Sie den Servernamen aus.
- Klicken Sie auf Detailstufe für Protokoll ändern.
- Optional: Falls Alle Komponenten aktiviert wurde, können Sie diese Option inaktivieren und anschließend spezifische Komponenten aktivieren.
- Optional: Wählen Sie einen Komponenten- oder Gruppennamen aus.
Weitere Informationen finden Sie unter Einstellungen für Protokollstufe im WebSphere Application Server Network Deployment, Version 6.1 Information Center. Falls der ausgewählte Server nicht aktiv ist, können Sie keine einzelne Komponente im Grafikmodus anzeigen.
- Geben Sie eine Tracezeichenfolge in das Feld für die Tracezeichenfolge ein. Geben Sie eine der folgenden Zeichenfolgen ein:
- all traces*=all
- com.ibm.ws.migration.WASUpgrade=all
Weitere Informationen zur Tracefunktion finden Sie unter Trace verwenden im WebSphere Application Server Network Deployment, Version 6.1 Information Center.
- Wählen Sie Anwenden und anschließend OK aus.
- Geben Sie den Namen der alten Datenbank und den vollständigen Pfad des neuen Datenbanknamens nach der Migration an, wenn Sie das Script ausführen. Beispiel: E:\WebSphere\ProcServer\derby\bin\embedded>db2jMigrate.bat meineAlteDatenbank meineNeueDatenbank Die Protokolle der automatischen Migration enthalten die genauen Pfadnamen, die für die alte Datenbank und die Zieldatenbank anzugeben sind.
Sie müssen die neue Datenbank mit diesem Zieldatenbanknamen angeben, weil Ihre migrierten Cloudscape-Datenquellen (die von den WebSphere ESB-Migrationsdienstprogrammen aktualisiert wurden) nun auf den Zieldatenbanknamen verweisen. Im folgenden Mustertext wird veranschaulicht, wie Zieldatenbanknamen in Protokollnachrichten angezeigt werden:
Die Cloudscape-Migration der Datenbankinstanz C:\temp\migration2\profiles\Srv01\
installedApps\ghongellNode01Cell\DynamicQuery.ear\EmployeeFinderDB auf
die neue Datenbankinstanz C:\WebSphere\ESB
\profiles\Srv01\databases\C__WAS602_ProcServer_profiles_ProcSrv01_
installedApps_ghongellNode01Cell_DynamicQuery.ear_
EmployeeFinderDB ist fehlgeschlagen. Ursache: java.sql.SQLException:
Failure creating target db
Geben Sie für Instanzen von Cloudscape, auf die über das
Network Server-Framework zugegriffen wird, einen beliebigen Namen ein, den Sie der neuen Datenbank zuweisen wollen. Denken Sie daran, Ihre vorhandenen Datenquellen so zu modifizieren, dass sie auf den neuen Datenbanknamen verweisen.
- Wenn der Migrationsprozess abgeschlossen ist, überprüfen Sie die Ergebnisse anhand des Datenbankmigrationsprotokolls. Der Pfadname jedes Datenbankmigrationsprotokolls ist installationsstammverzeichnis/logs/derby/meinVollständigerDatenbankpfadname_migrationLog.log.
Für eine fehlerfreie Migration zeigt das Datenbankmigrationsprotokoll eine Nachricht an, die dem folgenden Text ähnelt:
Check E:\WebSphere\ESB\derby\myOldDB_migrationLog.log for progress
Migration Completed Successfully
E:\WebSphere\ESB\derby\bin\embedded>
Andernfalls werden die Fehlernachrichten vom Protokoll im Format des folgenden Beispiels angezeigt:
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)
- Weitere Daten zu einem Migrationsfehler finden Sie im Debugprotokoll, das dem Datenbankmigrationsprotokoll entspricht. Der vollständige Pfadname einer Debugprotokolldatei lautet installationsstammverzeichnis/logs/derby/meinVollständigerDatenbankpfadname_migrationDebug.log
Die folgenden Zeilen sind ein Beispiel eines Debugtextes.
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
Ergebnisse
Wie in den vorherigen Schritten dargestellt, zeigt das Datenbankmigrationsprotokoll entweder die Nachricht
Migration Completed Successfully (Migration erfolgreich abgeschlossen) an, oder es wird eine Nachricht mit Ausnahmebedingungen wegen Migrationsfehlern angezeigt.
Nächste Schritte
- Führen Sie für Datenbanken, bei denen die Migration fehlgeschlagen ist, eine Fehlerbehebung anhand der protokollierten Fehlerdaten durch. Führen Sie anschließend das Migrationsscript aus.
- Modifizieren Sie Ihre Datenquellen so, dass sie auf die neuen Datenbanknamen verweisen, damit auf die Datenbanken, für die ein Upgrade erfolgreich durchgeführt wurde, über das eingebettete Framework zugegriffen werden kann.
- Damit auf die Datenbanken, für die ein Upgrade erfolgreich durchgeführt wurde, über das Network Server-Framework zugegriffen werden kann, können Sie entweder den DB2 Universal-JDBC-Treiber oder den Derby-Client-JDBC-Treiber verwenden.