Nach dem für die Umbenennung notwendigen Neustart begrüßte mich der DB2-Dienst mit "SQL1042C Ein Systemfehler ist aufgetreten" ("SQL1042C An unexpected system error occurred") und weigerte sich fortan zu starten - weder als Dienst, noch manuell. Sogar das DB2-Befehlsfenster beendete sich immer sofort wieder.
In den Details der Protokolldateien fand ich die - mehr oder wendiger - informative Meldung: "SQL1022C There is not enogh memory available to process the command".
Zu diesem Zeitpunkt waren aber mehr als 6 GB physischer und sogar ungefähr 20 GB logischer Arbeitsspeicher noch frei!?!
Nach langer, ausgiebiger Recherche kam ich zu dem Schluss, dass mich die Fehlermeldung erfolgreich komplett auf die falsche Fährte gelockt hatte.
DB2 speichert unter Windows einige Informationen, u.a. über lokale Benutzer (in der Form ServerName\Benutzername) und den Hostnamen des Server in der Windows-Registrierung unter dem Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\IBM\DB2\InstalledCopies\DB2COPY1\GLOBAL_PROFILE. (ändere "DB2COPY1", wenn deine Instanz anders heißt).
Wenn ich es vorher gekannt hätte, wäre ich einfach den Anweisungen in diesem Dokument gefolgt: Changing hostname of the DB2 server. Aber ich wollte jetzt nicht erst die Umbenennung rückgängig machen, um alles jetzt einmal "richtig" zu wiederholen.
In diesem Blog-Eintrag How do you rename the Windows machine name for a DB2 v9.1.x database? und vor allem in den zugehörigen Kommentaren fand ich doch noch einen schnellere, einfacheren und direkteren Weg, um das DB2-System zu wieder zum Laufen zu bringen.
Da ich einen Workgroup-Server (WSE = Workgroup Server Edition) habe, entfällt das Anpassen der db2nodes.cfg.
In einer als Administrator gestarteten Eingabeaufforderung habe ich folgende Befehle ausgeführt:
- db2extsec -r
- db2extsec /a DB2ADMNS /u DB2USERS
- db2set -g DB2SYSTEM={NewHostName}
