Fehlerbehebung bei der Migration
Während der Migration von einer älteren Version von WebSphere Application Server können Fehler auftreten.
Vorbereitende Schritte

Dieser Artikel beschreibt die Migration von Profilkonfigurationen. Wenn Sie Ihre Anwendungen auf die aktuellste Version migrieren möchten, verwenden Sie WebSphere Application Server Migration Toolkit. Weitere Informationen finden Sie unter Migration Toolkit on WASdev.
sptcfgVorgehensweise
- Wenn bei der Migration von einer früheren Version von WebSphere Application Server auf
Version 9.0 ein Fehler auftritt,
überprüfen Sie Ihre Protokolldateien und alle weiteren verfügbaren Informationen.
- Suchen Sie die folgenden Protokolldateien und durchsuchen Sie sie nach Anhaltspunkten für den Fehler.
- Migrationssicherungsverzeichnis/logs/WASPreUpgrade.Zeitmarke.log
- Migrationssicherungsverzeichnis/logs/WASPostUpgrade.Zeitmarke.log
- Stammverzeichnis_des_Anwendungsservers/logs/clientupgrade.Zeitmarke.log
- Suchen Sie in einer der Protokolldateien die Nachricht
MIGR0259I: Erfolgreich ausgeführt oder MIGR0271W:
Die Operation wurde mit Warnungen ausgeführt.
- Migrationssicherungsverzeichnis/logs/WASPreUpgrade.Zeitmarke.log
- Migrationssicherungsverzeichnis/logs/WASPostUpgrade.Zeitmarke.log
- Stammverzeichnis_des_Anwendungsservers/logs/clientupgrade.Zeitmarke.log
Wenn die Nachricht MIGR0286E: Die Migration konnte nicht durchgeführt werden angezeigt wird, versuchen Sie, alle Fehler, die auf den in der Protokolldatei erscheinenden Fehlernachrichten basieren, zu beheben. Nachdem Sie alle Fehler behoben haben, führen Sie den Befehl im Unterverzeichnis "bin" des Stammverzeichnisses der Produktinstallation erneut aus.
- Öffnen Sie das Serviceprotokoll des Servers, der die Ressource enthält, auf die Sie zugreifen möchten, und suchen Sie nach Fehlernachrichten und Warnungen.
- Führen Sie den Befehl dumpNameSpace aus. Verwenden Sie das Pipe-Zeichen, das Umleitungssymbol oder
die Option "more", um die Ausgabe besser lesen zu können. WebSphere Application Server muss dazu aktiv sein.
Dieser Befehl führt dazu, dass alle Objekte im Namespace von WebSphere Application Server angezeigt werden, einschließlich des Verzeichnispfads und des Objektnamens.
- Wenn das Objekt, auf das ein Client zugreifen muss, nicht erscheint, überprüfen Sie mithilfe der
Administrationskonsole, ob folgende Bedingungen zutreffen:
- Der Server, auf dem sich die Zielressource befindet, ist gestartet.
- Der Webmodul- oder Enterprise JavaBean-Container, der die Zielressource hostet, ist aktiv.
- Der JNDI-Name der Zielressource ist richtig angegeben.
- Analysieren Sie die Tracedaten
aus den Migrationstools oder leiten Sie die Daten zur Analyse an die entsprechende Organisation weiter. Wenn Sie den Befehl WASPreUpgrade oder den Befehl WASPostUpgrade verwenden, können Sie die folgenden Parameter zur Traceerstellung angeben:
- -traceString
- Dieser Parameter ist optional. Der für Tracespezifikation angegebene Wert gibt die Traceinformationen an, die Sie erfassen möchten.
- Geben Sie für "Tracespezifikation" den Wert "*=all=enabled" (mit Anführungszeichen) an, um alle Traceinformationen zu erfassen.
Es wird eine sehr große Tracedatei erstellt. Für den Befehl WASPostUpgrade kann die Datei über 1 GB groß sein.
- Geben Sie den Wert "Migration.*=all" an, um ausschließlich Migrationsinformationen zu erfassen.
- Geben Sie den Wert "Migration.Flow=all:Migration.*=finer" an, um umfassende Migrationsinformationen zu erfassen.
- Geben Sie "Migration.Flow=finer:Migration.*=fine" an, um ein Minimum an Migrationsinformationen zu erfassen, die von Unterstützungsteams benötigt werden.
Dies ist die Standardeinstellung.
- Geben Sie für "Tracespezifikation" den Wert "*=all=enabled" (mit Anführungszeichen) an, um alle Traceinformationen zu erfassen.
- -traceFile
- Dieser Parameter ist optional. Der für Dateiname angegebene Wert gibt den Namen der Ausgabedatei für die Traceinformationen an.
Wenn Sie den Parameter -traceString oder den Parameter -traceFile nicht angeben, erstellt der Befehl standardmäßig eine Tracedatei im Verzeichnis Sicherungsverzeichnis/logs.
Aktuelle Informationen des IBM® Support zu bekannten Problemen und ihrer Behebung finden Sie auf der Webseite des IBM Support. Der IBM Support hat Dokumente, mit denen Sie Zeit bei der Erfassung der für die Lösung des Problems erforderlichen Informationen sparen können. Bevor Sie einen PMR öffnen, lesen Sie die Informationen auf der Webseite des IBM Support.
- Suchen Sie die folgenden Protokolldateien und durchsuchen Sie sie nach Anhaltspunkten für den Fehler.
- Während des Migrationsprozesses können bei Verwendung des Tools
WASPreUpgrade oder des Tools
WASPostUpgrade Fehler auftreten.
- Bei Verwendung des Tools WASPreUpgrade können Fehler auftreten.
- Eine Nachricht zeigt an, dass das Verzeichnis oder die Datei nicht gefunden wurde oder nicht vorhanden ist
(Not found oder No such file or directory).
Dieses Problem kann auftreten, wenn Sie versuchen, das Tool WASPreUpgrade in einem anderen Verzeichnis als dem Verzeichnis Stammverzeichnis_des_Anwendungsservers\bin von Version 9.0 auszuführen. Stellen Sie sicher, dass sich das Script WASPreUpgrade im Verzeichnis Stammverzeichnis_des_Anwendungsservers\bin von Version 9.0 befindet, und starten Sie die Datei von dieser Position aus.
- Der DB2-JDBC-Treiber und DB2-JDBC-Treiber (XA) sind nicht in der Dropdown-Liste mit den unterstützten JDBC-Providern in der Administrationskonsole aufgeführt.
In der Administrationskonsole werden die Namen veralteter JDBC-Provider nicht mehr angezeigt. Die neuen JDBC-Providernamen in der Administrationskonsole sind beschreibende Namen und weniger verwirrend. Der Unterschied zwischen den neuen und veralteten Providern besteht nur im Namen.
Die veralteten Namen werden aus Migrationsgründen (z. B. für vorhandene JACL-Scripts) weiterhin in der Datei jdbc-resource-provider-templates.xml aufgeführt. Es wird jedoch empfohlen, in JACL-Scripts die neuen JDBC-Providernamen zu verwenden.
- Sie empfangen folgende Nachricht:
MIGR0108E: Das angegebene WebSphere-Verzeichnis enthält keine upgradefähige WebSphere-Version.
Dieser Fehler kann folgende Ursachen haben:- Ist WebSphere Application Server Version 7.0 oder höher
installiert, haben Sie
das Tool WASPreUpgrade möglicherweise nicht im
Unterverzeichnis bin des Installationsstammverzeichnisses von Version 9.0
ausgeführt.
- Wenn das Tool WASPreUpgrade ausgeführt wird, prüfen Sie, ob eine
Nachricht wie die folgende angezeigt wird: IBM WebSphere Application Server Release 6.x.
Diese Nachricht gibt an, dass das Migrationsdienstprogramm von WebSphere Application Server Version 7.0 oder höher und nicht das Migrationsdienstprogramm von Version 9.0 ausgeführt wird.
- Ändern Sie den Umgebungspfad oder das aktuelle Verzeichnis in der Weise, dass Sie das Tool WASPreUpgrade von Version 9.0 starten können.
- Wenn das Tool WASPreUpgrade ausgeführt wird, prüfen Sie, ob eine
Nachricht wie die folgende angezeigt wird: IBM WebSphere Application Server Release 6.x.
- Möglicherweise wurde beim Start des Tools WASPreUpgrade ein ungültiges Verzeichnis angegeben.
- Ist WebSphere Application Server Version 7.0 oder höher
installiert, haben Sie
das Tool WASPreUpgrade möglicherweise nicht im
Unterverzeichnis bin des Installationsstammverzeichnisses von Version 9.0
ausgeführt.
- Das Tool WASPreUpgrade wird möglicherweise beendet, ohne dass Ihre vorherige Umgebung gesichert wurde. Das Tool scheint ordnungsgemäß zu arbeiten, wie das folgende Beispiel zeigt:
In der Tracedatei für die Migration wird möglicherweise eine Nachricht ähnlich der folgenden angezeigt:MIGR0201I: Die Migrationsfunktion hat die Protokolldatei WASPreUpgrade.log initialisiert. MIGR0300I: Die Migrationsfunktion beginnt mit dem Speichern der vorhandenen Aplication-Server-Umgebung. MIGR0302I: Die vorhandenen Dateien werden gespeichert. MIGR0303I: Die vorhandene Application-Server-Umgebung wird gespeichert. MIGR0420I: Der erste Schritt der Migration wurde ordnungsgemäß ausgeführt.
[10/9/08 18:26:40:363 CDT] 00000000 Save 1 Skipped instance dmgr01 because user root /opt/migration_backup/profiles/dmgr01 does not exist.
Das Tool WASPreUpgrade gibt eine Kopie der Datei profileList.ser aus, die Verweise auf das Sicherungsverzeichnis enthält, die vom Tool WASPostUpgrade verwendet werden. Wird diese Datei aus irgendeinem Grund nicht von der Migration gelöscht, werden die alten Pfade anstelle der realen Pfade verwendet, wenn Sie das Tool WASPreUpgrade in späteren Migrationen ausführen. Zur Behebung dieses Problems können Sie die Datei profileList.ser gefahrlos löschen und das Tool WASPreUpgrade erneut ausführen.
Weitere Informationen hierzu finden Sie im Artikel Befehl "WASPreUpgrade".
Fehler vermeiden: Wenn Sie eine Migration von einem eingebundenen Knoten mit Version 6.1 auf Version 9.0 durchführen, kann der Befehl WASPreUpgrade fehlschlagen. Ein Fehler wie im folgenden Beispiel kann angezeigt werden:
Dieses Problem kann auf einem Knoten mit WebSphere Version 6.1 auftreten, wenn eine DB2-Datenbank erstellt wurde, die IBM JCC Provider Driver verwendet, und wenn der Knoten mit WebSphere Version 6.1 mit dem Deployment Manager von Version 9.0 synchronisiert ist. Der Knoten mit Version 6.1 bietet keine Unterstützung für die Treiberstufe der Version 7.0 oder höher. Der Prozess der Knotensynchronisation kann nicht alle Treiberdefinitionen entfernen.[07/16/2011 11:07:10:357 CDT] MIGR0344I: Die Konfigurationsdatei /opt/WAS61fep/profiles/v6109node74_01/config/cells/ndcell/clusters/Station1EJBCluster /resources.xml wird verarbeitet. [07/16/2011 11:07:10:436 CDT] org.eclipse.emf.ecore.resource.Resource$IOWrappedExcept ion: Unresolved reference 'DataSource_1310769433958'. (file:/opt/WAS61fep/profiles/v6109node74_01/config/cells/ndcell/clusters/Station1EJBC luster/resources.xml, 9, 323) java.lang.Exception: org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Unresolved reference 'DataSource_1310769433958'. (file:/opt/WAS61fep/profiles/v6109node74_01/config/cells/ndcell/clusters/Station1EJBC luster/resources.xml, 9, 323) at com.ibm.wsspi.migration.document.wccm.WCCMDocument.setInputStream(WCCMDocument.ja va:162)
Zum Beheben dieses Problems sichern Sie alle Dateien des Typs "resources.xml", die modifiziert werden sollen. Stoppen Sie den Node-Agent-Prozess von Version 6.1. Bearbeiten Sie die Dateien des Typs "resources.xml" auf dem Knoten mit WebSphere Version 6.1 und entfernen Sie die verwaisten Einträge des Typs "resources.jdbc:CMPConnectorFactory", bevor Sie den Befehl WASPreUpgrade ausführen. Die Deployment-Manager-Kopie darf nicht bearbeitet werden.
gotcha - Eine Nachricht zeigt an, dass das Verzeichnis oder die Datei nicht gefunden wurde oder nicht vorhanden ist
(Not found oder No such file or directory).
- Bei Verwendung des Tools WASPostUpgrade können Fehler auftreten.
- Möglicherweise sehen Sie in den WASPostUpgrade-Protokollen eine Ausnahme, die nach der Migration eines eingebundenen Knotens ausgelöst wurde. Diese Ausnahme könnte ähnlich wie im folgenden Text angezeigt werden:
Diese Ausnahme tritt während der syncNode-Operation auf und wird als Fehler geführt, sie verursacht jedoch keine Ausfälle. Die Aktion insgesamt wurde erfolgreich abgeschlossen und die Nachricht wird nicht erneut angezeigt. Nachdem der Server auf dem migrierten Knoten gestartet wurde, wird die fragliche Datei neu generiert. Sie können diese Nachricht ignorieren.MIGR0304I: Die vorherige WebSphere-Umgebung wird wiederhergestellt. MIGR0367I: Die aktuelle Application-Server-Umgebung wird gesichert. CEIMI0006I Die Migration von Common Event Infrastructure wird gestartet. MIGR0486I: Die Einstellung Transports in der Datei server.xml ist veraltet. MIGR0486I: Die Einstellung PMIService:initialSpecLevel in der Datei server.xml ist veraltet. MIGR0486I: Die Einstellung PMIService:initialSpecLevel in der Datei server.xml ist veraltet. MIGR0404W: Die Verwendung des Node Agent aus der alten Konfiguration ist nicht zulässig. Sie wurde inaktiviert. MIGR0351I: Die Migrationsfunktion versucht die Synchronisation mit dem Deployment Manager unter Verwendung des Protokolls SOAP. MIGR0241I: Ausgabe von syncNode. ADMU0116I: Die Toolinformationen werden in der Datei /usr/WAS80/profiles/AppSrv01/logs/syncNode.log ADMU0128I: Das Tool wird mit dem Profil AppSrv01 gestartet. ADMU0401I: Die syncNode-Operation für Knoten aaixae15aNode01 mit Deployment Manager packppc.rtp.raleigh.ibm.com: 8879 wird gestartet. ADMU0016I: Die Konfigurationen auf dem Knoten und in der Zelle werden synchronisiert. AWXJR0006E Die Datei /usr/WAS80/java/jre/PdPerm.properties wurde nicht gefunden. ArchiveUtil.toLocalURLs ArchiveUtil.toLocalURLs ArchiveUtil.toLocalURLs ADMU0402I: Die Konfiguration für Knoten aaixae15aNode01 wurde mit Deployment Manager packppc.rtp.raleigh.ibm.com: 8879 synchronisiert. MIGR0352I: Die Synchronisation mit Deployment Manager war erfolgreich. CEIMI0007I Die Common-Event-Infrastructure-Migration ist abgeschlossen. MIGR0307I: Die Wiederherstellung der vorherigen Application-Server-Umgebung ist abgeschlossen. MIGR0271W: Die Migration wurde mit Warnungen durchgeführt.
- Sie empfangen möglicherweise die folgende Fehlernachricht:
MIGR0484E: Es wurden keine Profile oder Instanzen mit dem Namen -profileName wasio2651 gefunden. MIGR0272E: Die Migrationsfunktion kann den Befehl nicht ausführen.
Der Name des alten und des neuen Profils müssen übereinstimmen. Führen Sie den Befehl WASPostUpgrade erneut aus undverwenden Sie dabei ein Profil von Version 9.0, das dem Namen entspricht, der als Wert für das Argument "-profileName" in der Nachricht MIGR0484E angegeben ist.
- Eine Nachricht zeigt an,
dass das Verzeichnis oder die Datei
nicht gefunden wurde oder nicht vorhanden ist.
Dieses Problem kann auftreten, wenn Sie versuchen, das Tool WASPostUpgrade in einem anderen Verzeichnis als dem Verzeichnis Stammverzeichnis_des_Anwendungsservers\bin von Version 9.0 auszuführen. Stellen Sie sicher, dass sich das Script WASPostUpgrade im Verzeichnis Stammverzeichnis_des_Anwendungsservers\bin von Version 9.0 befindet, und starten Sie die Datei von dieser Position aus.
- Sie empfangen folgende Nachricht:
MIGR0102E: Ungültiger Befehlszeilenparameter. MIGR0105E: Sie müssen den Namen des Primärknotens angeben.
Dieser Fehler wurde höchtwahrscheinlich dadurch verursacht, dass WebSphere Application Server Version 7.0 oder höher installiert ist und das Tool WASPostUpgrade nicht im Unterverzeichnis bin des Installationsstammverzeichnisses von Version 9.0 ausgeführt wurde.
Zur Behebung dieses Fehlers führen Sie den Befehl WASPostUpgrade im Unterverzeichnis bin des Installationsstammverzeichnisses von Version 9.0 aus.
- Bei der Migration der eingebundenen Knoten in einer Zelle werden
folgende Fehlernachrichten angezeigt:
MIGR0304I: Die vorherige WebSphere-Umgebung wird wiederhergestellt. com.ibm.websphere.management.exception.RepositoryException: com.ibm.websphere.management.exception.ConnectorException: ADMC0009E: Das System konnte den SOAP-RPC-Aufruf nicht durchführen: invoke MIGR0286E: Die Migration konnte nicht durchgeführt werden.
Wenn der eingebundene Knoten versucht, während des Migrationsschritts "WASPostUpgrade" Konfigurationsaktualisierungen vom Deployment Manager abzurufen, wird die Verbindung aufgrund der Überschreitung des Verbindungszeitlimits beendet. Das Kopieren der gesamten Konfiguration kann länger dauern als das festgelegte Verbindungszeitlimit, wenn die Konfiguration, die Sie auf Version 9.0 migrieren, folgende Elemente enthält:- viele kleine Anwendungen
- einige große Anwendungen
- eine sehr große Anwendung
Die beste Vorgehensweise ist hier, den Zeitlimitwert zu erhöhen, bevor Sie den Befehl WASPostUpgrade für die Migration eines eingebundenen Knotens ausführen.- Das Profil, auf das Sie den eingebundenen Knoten migrieren, finden Sie im folgenden Verzeichnis
von Version 9.0:
Profilstammverzeichnis/properties
- Öffnen Sie die Datei soap.client.props in diesem Verzeichnis und suchen Sie nach dem Wert für die Eigenschaft "com.ibm.SOAP.requestTimeout". Dies ist der Zeitlimitwert in Sekunden. Der Standardwert beträgt 180 Sekunden.
- Erhöhen Sie den Wert der Eigenschaft "com.ibm.SOAP.requestTimeout"
so weit, dass er groß genug ist für die Migration Ihrer Konfiguration.
Beispielsweise legt der folgende Eintrag einen Zeitlimitwert von einer halben Stunde fest:
com.ibm.SOAP.requestTimeout=1800
Anmerkung: Wählen Sie den kleinstmöglichen Wert aus, der für Ihre Anforderungen genügt. Stellen Sie sich darauf ein, mindestens die dreifache Zeit des Zeitlimits abzuwarten: einmal für das Herunterladen von Dateien in das Sicherungsverzeichnis, einmal für das Hochladen der migrierten Dateien in den Deployment Manager und einmal für die Synchronisation des Deployment Manager mit dem migrierten Node Agent. - Wechseln Sie im Sicherungsverzeichnis, das mit dem Befehl WASPreUpgrade erstellt wurde,
zu folgendem Unterverzeichnis:
Sicherungsverzeichnis/profiles/Profilname/properties
- Öffnen Sie die Datei soap.client.props in diesem Verzeichnis und suchen Sie nach dem Wert für die Eigenschaft "com.ibm.SOAP.requestTimeout".
- Ändern Sie den Wert für die Eigenschaft "com.ibm.SOAP.requestTimeout" in den Wert, den Sie in der Datei von Version 9.0 verwendet haben.
Alternativ dazu können Sie folgende Lösung verwenden: Sie können im Befehl WASPostUpgrade -includeApps script angeben, wenn Sie den Deployment Manager auf Version 9.0 migrieren und eine der folgenden Bedingungen zutrifft:- Sie möchten alle Knoten in der Zelle schnell migrieren. Nachdem die gesamte Zelle migriert wurde, müssen Sie jedoch bereit sein, das Script zur Anwendungsinstallation für jede Anwendung im Sicherungsverzeichnis des Deployment Manager manuell auszuführen und anschließend die Konfiguration mit allen migrierten Knoten zu synchronisieren.
- Sie können das System ausführen, ohne dass Anwendungen installiert sind.
Führen Sie folgende Schritte aus, um diese alternative Vorgehensweise zu verwenden:- Geben Sie bei Migration des Deployment Manager auf Version 9.0 im Befehl WASPostUpgrade -includeApps script an.
- Migrieren Sie die gesamte Zelle auf Version 9.0, bevor Sie Anwendungen installieren.
- Führen Sie den den Befehl
wsadmin aus, um die einzelnen Anwendungen zu installieren.
- Installieren Sie die Anwendungen in der Konfiguration von Version 9.0 während des normalen Betriebs oder während der Wartungszeiten.
- Geben Sie -conntype NONE an. Beispiel:
wsadmin -f Anwendungsscript -conntype NONE
- Synchronisieren Sie die Konfiguration mit allen migrierten Knoten.
- Sie empfangen folgende Nachricht:
"Unable to copy document to temp file"
Beispiel:
MIGR0304I: Die vorherige WebSphere-Umgebung wird wiederhergestellt. com.ibm.websphere.management.exception.DocumentIOException: Unable to copy document to temp file: cells/sunblade1Network/applications/LARGEApp.ear/LARGEApp.ear
Möglicherweise ist Ihr Dateisystem vollständig belegt. In diesem Fall sollten Sie Speicherplatz freigeben und den Befehl WASPostUpgrade erneut ausführen.
- Sie empfangen folgende Nachricht:
MIGR0108E: Das angegebene WebSphere-Verzeichnis enthält keine upgradefähige WebSphere-Version.
Dieser Fehler kann folgende Ursachen haben:- Ist WebSphere Application Server
Version 6.1 installiert, haben Sie
das Tool WASPostUpgrade möglicherweise nicht im
Unterverzeichnis bin des Installationsstammverzeichnisses von Version 9.0
ausgeführt.
- Wenn das Tool WASPostUpgrade ausgeführt wird, prüfen Sie, ob eine
Nachricht wie die folgende angezeigt wird: IBM WebSphere Application Server Release 6.1.
Diese Nachricht gibt an, dass Sie ein Migrationsdienstprogramm aus einem früheren Release und nicht das Migrationsdienstprogramm von Version 9.0 ausführen.
- Ändern Sie den Umgebungspfad oder das aktuelle Verzeichnis in der Weise, dass Sie das Tool WASPostUpgrade von Version 9.0 starten können.
- Wenn das Tool WASPostUpgrade ausgeführt wird, prüfen Sie, ob eine
Nachricht wie die folgende angezeigt wird: IBM WebSphere Application Server Release 6.1.
- Möglicherweise wurde beim Start des Tools WASPreUpgrade ein ungültiges Verzeichnis angegeben, oder das Tool WASPostUpgrade wurde nicht ausgeführt.
- Das Tool WASPreUpgrade wurde nicht ausgeführt.
- Ist WebSphere Application Server
Version 6.1 installiert, haben Sie
das Tool WASPostUpgrade möglicherweise nicht im
Unterverzeichnis bin des Installationsstammverzeichnisses von Version 9.0
ausgeführt.
- Sie empfangen folgende Fehlernachricht:
MIGR0253E: Das Sicherungsverzeichnis Migrationssicherungsverzeichnis ist nicht vorhanden.
Dieser Fehler kann folgende Ursachen haben:- Das Tool
WASPreUpgrade wurde nicht ausgeführt, bevor
das Tool WASPostUpgrade gestartet wurde.
- Prüfen Sie, ob das in der Fehlernachricht angegebene Sicherungsverzeichnis existiert.
- Ist dies nicht der Fall, führen Sie das Tool
WASPreUpgrade aus.
Nähere Informationen finden Sie im Artikel Befehl "WASPreUpgrade".
- Versuchen Sie erneut, das Tool WASPostUpgrade zu starten.
- Möglicherweise wurde ein ungültiges Sicherungsverzeichnis angegeben.
Beispielsweise könnte es sich bei dem angegebenen Verzeichnis um ein Unterverzeichnis in der Verzeichnisstruktur von Version 7.0 oder höher handeln, das gelöscht wurde, nachdem das Tool WASPreUpgrade ausgeführt und die älterer Produktversion deinstalliert wurde, aber bevor das Tool WASPostUpgrade ausgeführt wurde.
- Stellen Sie fest, ob die in der Fehlernachricht angegebene vollständige Verzeichnisstruktur vorhanden ist.
- Falls möglich, führen Sie das Tool WASPreUpgrade erneut aus und geben Sie den richtigen vollständigen Pfad des Migrationssicherungsverzeichnisses an.
- Wenn das Sicherungsverzeichnis nicht vorhanden ist und die ältere Version, von der es erstellt wurde, gelöscht wurde, müssen Sie die ältere Version aus einem Sicherungsverzeichnis oder einer XML-Konfigurationsdatei erneut erstellen.
- Führen Sie das Tool WASPreUpgrade erneut aus.
- Das Tool
WASPreUpgrade wurde nicht ausgeführt, bevor
das Tool WASPostUpgrade gestartet wurde.
- Sie entscheiden, dass das Tool
WASPreUpgrade erneut ausgeführt werden muss, nachdem der Befehl
WASPostUpgrade bereits ausgeführt wurde.
Während der Migration eines Deployment Manager oder eines eingebundenen Knotens kann WASPostUpgrade die alte Umgebung inaktivieren. Wenn Sie nach Ausführung des Tools WASPostUpgrade das Tool WASPreUpgrade erneut für die alte Installation ausführen möchten, müssen Sie das Script migrationDisablementReversal.jacl ausführen, das im alten Verzeichnis Stammverzeichnis_des_Anwendungsservers/bin gespeichert ist. Nach Ausführung dieses JACL-Scripts ist die Umgebung mit Version 7.0 oder höher wieder gültig, sodass Sie das Tool WASPreUpgrade ausführen und gültige Ergebnisse damit erzeugen können.
- Die Migration eines eingebundenen Knotens schlägt mit der Nachricht MIGR0405E fehl.Die auf dem Deployment Manager durchgeführte Migration eines eingebundenen Knotens ist fehlgeschlagen. Ausführlichere Informationen zur Ursache dieses Fehlers erhalten Sie, wenn Sie den Ordner Name_Ihres_Knotens_migration_temp öffnen, der in Ihrem Deployment-Manager-Knoten im Verzeichnis ...DeploymentManagerProfile/temp enthalten ist. Beispiel:
/websphere80/appserver/profiles/dm_profile/temp/nodeX_migration_temp
Die Protokolle und alles, was zur Migration dieses Knotens auf dem Deployment-Manager-Knoten gehört, sind in diesem Ordner enthalten. Dieser Ordner ist auch erforderlich, wenn Sie in diesem Szenario Unterstützung vom IBM Support benötigen.
- Anwendungen von Version 9.0
gehen während der Migration verloren.
Wenn während der Migration eines eingebundenen Knotens Anwendungen von Version 9.0 nicht installiert werden können, gehen diese Anwendungen während der Synchronisation der Konfigurationen verloren. Dies liegt daran, dass als einer der letzten Schritte des Tools WASPostUpgrade der Befehl syncNode ausgeführt wird. Bei der Ausführung dieses Befehl wird die Konfiguration des Deployment Manager heruntergeladen und die Konfiguration auf dem eingebundenen Knoten überschrieben. Wenn die Anwendungen nicht installiert werden können, sind sie nicht in der Konfiguration auf dem Deployment-Manager-Knoten enthalten. Sie können dieses Problem beheben, indem Sie die Anwendungen nach der Migration manuell installieren. Falls es sich um Standardanwendungen von Version 9.0 handelt, sind sie im Verzeichnis Stammverzeichnis_des_Anwendungsservers/installableApps enthalten.
Zur manuellen Installation einer Anwendung, die während der Migration verloren gegangen ist, verwenden Sie den Befehl wsadmin, um das Script install_Anwendungsname.jacl auszuführen, das von den Migrationstools im Sicherungsverzeichnis erstellt wurde.
Verwenden Sie in einer Linux-Umgebung beispielsweise die folgenden Parameter:./wsadmin.sh -f Migrationssicherheitsverzeichnis/install_Anwendungsname.jacl -conntype NONE
Verwenden Sie die folgenden Parameter:Stammverzeichnis_des_Anwendungsservers/bin/wsadmin -f Migrationssicherungsverzeichnis/install_Anwendungsname.jacl -conntype NONE
- Anwendungen von Version 9.0
können nicht installiert werden.
Installieren Sie die Anwendungen nach Ausführung des Tools WASPostUpgrade manuell mit dem Befehl wsadmin.
Zur manuellen Installation einer Anwendung, die während der Migration nicht installiert wurde, verwenden Sie den Befehl wsadmin, um das Script install_Anwendungsname.jacl auszuführen, das von den Migrationstools im Sicherungsverzeichnis erstellt wurde.
Verwenden Sie in einer Linux-Umgebung beispielsweise die folgenden Parameter:./wsadmin.sh -f Migrationssicherheitsverzeichnis/install_Anwendungsname.jacl -conntype NONE
Verwenden Sie die folgenden Parameter:Stammverzeichnis_des_Anwendungsservers/bin/wsadmin -f Migrationssicherungsverzeichnis/install_Anwendungsname.jacl -conntype NONE
Nähere Informationen finden Sie im Artikel Befehl "WASPostUpgrade".
- Möglicherweise sehen Sie in den WASPostUpgrade-Protokollen eine Ausnahme, die nach der Migration eines eingebundenen Knotens ausgelöst wurde. Diese Ausnahme könnte ähnlich wie im folgenden Text angezeigt werden:
- Die Tracedatei überschreitet die zugeordnete Größe von 400 MB, aber WASPostUpgrade ist weiterhin aktiv. Wenn kein zusätzlicher Plattenspeicher verfügbar ist, schlägt die Migration fehl. Wenn Sie annehmen, dass dieses Problem während der Migration auftreten könnte, führen Sie die folgenden Aktionen aus:
- Stoppen Sie den Migrationsassistenten, bevor der Befehl "WASPostUpgrade" abgesetzt wird.
- Führen Sie den Befehl "WASPostUpgrade" in der Befehlszeile für jedes zu migrierende Profil aus.
Wenn Sie den Befehl "WASPostUpgrade" in der Befehlszeile absetzen, beachten Sie Folgendes:
- Geben Sie die Parameter -oldProfile und -profileName an, um die zu migrierenden Profile anzugeben.
- Fügen Sie der Tacezeichenfolge den Parameter com.ibm.ejs.ras.TraceNLS* hinzu, um die Größe des Traceprotokolls zu verringern. Geben Sie beispielsweise folgende Traceeinstellung an:
com.ibm.ejs.ras.TraceNLS*=info
- Bei Verwendung des Tools WASPreUpgrade können Fehler auftreten.
- Wenn Sie die Option auswählen, durch die die
Unternehmensanwendungen, die in der Konfiguration von
Version 7.0 oder höher vorhanden sind, vom Migrationsprozess in
der neuen Konfiguration von Version 9.0
installiert werden,
werden während der Migrationsphase der Anwendungsinstallation möglicherweise
Fehlernachrichten angezeigt.
Die Anwendungen, die in der Konfiguration von Version 7.0 oder höher vorhanden sind, enthalten möglicherweise ungültige Implementierungsinformationen (in der Regel ungültige XML-Dokumente, die in früheren Laufzeiten von WebSphere Application Server nicht ausreichend validiert wurden). Die Laufzeit verfügt jetzt über einen verbesserten Validierungsprozess bei der Anwendungsinstallation und installiert solche fehlerhaften EAR-Dateien nicht. Dies verursacht ein Fehlschlagen der Anwendungsinstallationsphase im Migrationsschritt WASPostUpgrade und erzeugt eine Fehlernachricht des Typs "E:". Dies ist ein schwerwiegender Migrationsfehler.
Wenn die Migration auf diese Art und Weise während der Anwendungsinstallation fehlschlägt, können Sie eine der folgenden beiden Vorgehensweisen wählen:- Beheben Sie die Fehler in den Anwendungen von Version 7.0 oder höher und führen Sie die Migration anschließend erneut durch.
- Setzen Sie die Migration fort und ignorieren Sie diese Fehler.
In diesem Fall installiert der Migrationsprozess zwar nicht die fehlerhaften Anwendungen, er führt aber alle anderen Migrationsschritte aus.
Anschließend können Sie die Fehler in den Anwendungen beheben und diese Anwendungen manuell, mithilfe der Administrationskonsole oder mit einem Installationsscript, in der neuen Konfiguration von Version 9.0 installieren.
- Wenn Sie einen Deployment Manager
von einer Konfiguration von Version 6.1, die
von einem Deployment Manager von Version 5.1 migriert wurde, auf
IBM Version 9.0
migrieren, schlägt der Befehl syncNode auf allen eingebundenen Knoten mit
Version 5.1 in der Zelle fehl. Es werden möglicherweise Nachrichten ähnlich den folgenden angezeigt, wenn Sie den Befehl syncNode auf einem Knoten mit Version 5.1 ausführen:
bash-3.00# ./syncNode.sh dmgrhostname 8879 -username MyAdminUser -password MyAdminPassword
ADMU0116I: Die Toolinformationen werden in der Datei /usr/WebSphere/AppServer/logs/syncNode.log ADMU0401I: Die syncNode-Operation für Knoten My511Node mit Deployment Manager dmgrhostname wird gestartet: 8879 ADMU0111E: Das Programm wird mit dem folgenden Fehler beendet: com.ibm.websphere.management.exception. AdminException: ADMU2092E: Knoten und Deployment Manager müssen dieselben Produkterweiterungen haben, aber sie stimmen nicht überein. Auf dem Knoten ist die Produkterweiterung BASE und im Deployment Manager ist PME installiert. ADMU0211I: Sie finden möglicherweise Fehlerdetails in der folgenden Datei: /usr/WebSphere/AppServer/logs/syncNode.log ADMU1211I: Wenn Sie einen vollständigen Trace für den Fehler erstellen möchten, verwenden Sie die Option -trace.
- Da die Annotation "javax.ejb.Remote" in der EJB-3.0-Spezifikation enthalten ist, können
möglicherweise bestimmte EJB-2.1-Beans nicht kompiliert werden, wenn Enterprise Java™ Beans für den Import der vollständigen javax.ejb- und java.rmi-Pakete geschrieben wurden. Es treten dann Kompilierungsfehler ähnlich der im folgenden Beispiel beschriebenen Fehler auf:
ejbModule/com/ibm/websphere/samples/trade/ejb/QuoteHome.java(17): The type Remote is ambiguous
- Wenn Sie WebSphere Application Server
Version 6.1 installieren und einen Knoten in einen Deployment Manager von Version 9.0
einbinden, treten möglicherweise unerwartete Ausnahmenachrichten und fortlaufend Ausnahmenachrichten zur Sicherheit auf. Die Protokolldatei system.out des Node Agent enthält die folgenden Ausnahmen:
[7/8/08 16:41:31:416 EDT] 0000001c DefaultTokenP E HMGR0149E: Der Versuch, eine Verbindung zur Stammgruppe DefaultCoreGroup herzustellen, wurde zurückgewiesen. Der sendende Prozess hat den Namen wasinst101Cell01\ndrack104Node08\server1 und die IP-Adresse /9.42.92.86. Die globale Sicherheit im lokalen Prozess ist auf Aktiviert eingestellt. Die globale Sicherheit im sendenden Prozess ist 'Aktiviert'. Das empfangene Token beginnt mit x2>W 9 Sv?. Die Ausnahme ist com.ibm.websphere.security.auth.WSLoginFailedException: Die Validierung des LTPA-Token ist fehlgeschlagen aufgrund ungültiger Schlüssel oder ungültigem Tokentyp. at com.ibm.ws.security.ltpa.LTPAServerObject. validateToken(LTPAServerObject.java:876) at com.ibm.ws.security.token.WSCredentialTokenMapper. validateLTPAToken(WSCredentialTokenMapper.java:1178) at com.ibm.ws.hamanager.runtime.DefaultTokenProvider. authenticateMember(DefaultTokenProvider.java:214) at com.ibm.ws.hamanager.coordinator.impl.DCSPluginImpl. authenticateMember(DCSPluginImpl.java:723) at com.ibm.ws.dcs.vri.transportAdapter.rmmImpl.ptpDiscovery. DiscoveryRcv.acceptStream(DiscoveryRcv.java:266) at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor. fetchStream(PacketProcessor.java:470) at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor. run(PacketProcessor.java:917)
Der Deployment Manager verwendet Version 9.0 und alle Knoten und Aliasknoten verwenden Version 6.1. Um dieses Problem zu beheben, führen Sie ein Upgrade aller Knoten mit Version 6.1 auf Version 6.1.0.17 oder höher durch.
Zu den neuen Ports, die auf einem migrierten Node Agent von Version 9.0 registriert sind, gehören folgende: WC_defaulthost, WC_defaulthost_secure, WC_adminhost, WC_adminhost_secure SIB_ENDPOINT_ADDRESS, SIB_ENDPOINT_SECURE_ADDRESS ,SIB_MQ_ENDPOINT_ADDRESS, SIB_MQ_ENDPOINT_SECURE_ADDRESS. Diese Ports werden vom Node Agent nicht benötigt und können gefahrlos gelöscht werden.
Nächste Schritte
Wenn Ihr Problem nicht aufgeführt ist, wenden Sie sich an den IBM Support.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-iseries&topic=tmig_troubleshoot
Dateiname:tmig_troubleshoot.html