Das Klonen eines WebSphere Portal Servers ist eine komplexe Angelegenheit die sich gut und gerne etwas länger hinzieht. Umso besser, dass IBM eine Anleitung dazu stellt.

Doch auch wenn man der Anleitung genau folgt kann es zu unerwarteten Problemen kommen, die dort nicht erläutert werden.

Das ist mir passiert und da ich schon ne Weile gebraucht habe um auf die Lösung zu kommen, könnte es auch andere interessieren.

Das Problem ist/war, dass bei Schritt 2. in der Anleitung von IBM:

To delete the scheduled tasks, run the following ConfigEngine task:
<profile_home>/ConfigEngine/ConfigEngine.sh action-clean-scheduled-tasks

Eine Menge von Fehlern ausgespuckt werden:

Bild 1: Der Stacktrace der Exception

Dabei werden folgende Fehler ausgespuckt:

ERROR XSDB6: Another instance of Derby may have already booted the database

Could not shutdown the database!
[sqlproc] SQL Exception: Database ‚xxxdb‘ not found.

ERROR: Error during the execution of the sql files.

Dabei sind die Fehler etwas verwirrend wie ich fand, denn der erste besagt, dass die Datenbank die seit Version 6.1 nun „derby“ heißt und nicht mehr „cloudscape“ und der zweite sagt, dass diese nicht gefunden wurde!

Nungut, nach einer langen Suche in den Logs und einer engen Zusammenarbeit mit Google war die Lösung dann doch ganz einfach!

Dabei bringt der erste Fehler es auf den Punkt! Es läuft bereits eine Instanz der Datenbank. Was aber nicht der Fall ist. Aber das Skript glaubt das, da der user dafür noch in einer Session „eingeloggt ist“.

Wenn man diese Session-Dateien (*.lck) löscht, wird der Weg für einen erneuten Login durch das Skript frei.

Diese Dateien liegen im Verzeichnis <wp_profile>/PortalServer/derby/wpsdb.

Bild 2: Die zwei LCK-Dateien, die die Session blockieren

Wenn man nun diese zwei Dateien löscht läuft das Skript ganz normal durch. Der weitere Cloning-prozess verlief dann relativ unspektakulär.

Lösungsquelle war ein IBM-Hilfe Dokument, dass zwar für was anderes Gedacht war aber das Problem sehr ähnlich war!