Kapitel 7 - Fehlerbehebung

Tools


Probleme mit dem Anwendungsserver

Probleme mit der Umgebung

Der Pseudobenutzer auf dem Anwendungsserver muss in WebSphere Product Center die folgenden Umgebungsvariablen konfigurieren, bevor er WebSphere Product Center startet:

Außerdem muss die Shellprozedur init_ccd_vars.sh vor dem Starten von WebSphere Product Center abgeleitet werden. Dies geschieht normalerweise in der Benutzerdatei .bashrc

Die Umgebungsvariable CLASSPATH sollte nicht mehr geändert werden, nachdem init_ccd_vars.sh abgeleitet wurde.

Häufig vorkommende Fehler beim Einrichten der Konfigurationsdatei

Der häufigste Fehler ist eine nicht korrekte Datenbankkennung in der Datei common.properties. Eine falsch konfigurierte Datenbank zeigt die folgenden Symptome:

Anwendungsserver, Ereignisprozessor, Warteschlangenmanager, Planungsfunktion und Workflow-Engine können nicht gestartet werden

Fehler in den Protokolldateien logs/db_pool und logs/svc/

smtp_address. Smtp_address sollte auf ein SMTP-Relais zeigen, entweder Sendmail auf dem lokalen Host, oder auf ein anderes System, das E-Mails außerhalb des Unternehmens versenden kann.

Wenn die Lizenzdatei (WPC_license.xml) fehlt oder fehlerhaft ist, werden keine Services gestartet. Dieser Fehler zeigt sich in den Protokolldateien unter logs/svc

Anwendungsserver antwortet nicht

Szenario

Der Anwendungsserver reagiert praktisch nicht mehr. Obwohl man für den Server ein Pingsignal absetzen kann, kann der Benutzer sich nicht in der Umgebung und der Administrator sich nicht am Anwendungsserver anmelden.

Überprüfen Sie Folgendes:

Stellen Sie fest, ob ein Benutzer kürzlich einen ungewöhnlich großen Job gestartet hat. Wenn dieser Job beabsichtigt war, prüfen Sie das von dem Job verwendete Script.


Probleme mit der Datenbank

1. Zeichenkonvertierung während des Imports oder Exports von Daten

2. Probleme bei der Datenbankbereichszuordnung

3. Probleme durch Datenblockbeschädigung und Indexbeschädigung

4. Import- oder Exportblockierung, ohne Änderungen in der Statusleiste, auch nach längerer Zeit

5. Nach dem Abbruch eines auszuführenden Jobs wird die Anwendung extrem langsam

6. Probleme beim Zurücknehmen des Widerrufs für Protokollwechsel

7. Blockierung der WebSphere Product Center-Middleware und der GUI

8. Blockierung der Analyse von Schemajobs

9. SQL-Verbindung wird automatisch erneut gestartet


1. Zeichenkonvertierung während des Imports oder Exports von Daten

Problem

Während des Exports oder Imports einer Datenbank werden beim Erstellen von Testumgebungen mittels einer Kopie der Datenbank Fehlernachrichten angezeigt, die den verwendeten Zeichensatz betreffen.

Symptome

Wenn z. B. eine Datenbank unter Verwendung des Zeichensatzes US7ASCII exportiert wird, erscheint die folgende Fehlernachricht im Exportprotokoll:

Export done in US7ASCII character set and UTF8 NCHAR character set server uses UTF8 character set (possible charset conversion)

Problemlösung

Richten Sie bei jedem Export oder Import der Datenbank den Parameter NLS_LANG so ein, dass der Zeichensatz american_america.utf8 verwendet wird.

2. Probleme bei der Datenbankbereichszuordnung

Problem

Import- und Exportjobs schlagen gelegentlich fehl, weil Tabellen, Indizes, ROLLBACK-Segmenten und temporären Segmenten nicht genügend Speicherplatz zugeordnet wurde.

Symptom

Wenn das ROLLBACK-Segment oder der Tabellenbereich des ROLLBACK-Segments voll sind, erscheint in der Alertprotokolldatei in etwa die folgende Fehlernachricht:

ORA-1650: unable to extend rollback segment RBS8 by 512 in tablespace RBS

Failure to extend rollback segment 9 because of 1650 condition FULL status of rollback segment 9 set.

Problemlösung

3. WebSphere Product Center wird langsamer, sobald ein aktiver Job abgebrochen wird.

Problem

Wenn ein Job wie Import oder Export abgebrochen wird, muss das Datenbanksystem die komplette Transaktion zurücksetzen, um die Datenbank wieder in einen konsistenten Status zu versetzen. Dieser ROLLBACK-Prozess benötigt maximale Systemressourcen, wie CPU-Zeit und Speicher.

Symptome

Die Middleware von WebSphere Product Center wird langsamer, nachdem ein laufender Job abgebrochen wurde.

Problemlösung

Warten Sie, bis die ROLLBACK-Operation abgeschlossen ist und das System wieder normal funktioniert. Brechen Sie laufende Jobs nicht ab, wenn es nicht notwendig ist.

4. Probleme beim Wechsel des Protokolls für die Rücknahme des Widerrufs

Problem

Eine unverhältnismäßige Anzahl oder Größe von Protokolldateien kann dazu führen, dass das Datenbanksystem lange wartet, bis ein Protokollwechsel ausgeführt wird.

Symptome

Das Datenbanksystem wartet sehr lange auf einen Protokollwechsel und darauf, dass alle Dateien für den Widerruf des Protokollwechsels aktiv sind.

Problemlösung

5. Blockierung der WebSphere Product Center-Middleware und der GUI

Problem

Wenn Fehler beim Zugriff auf die Middleware von WebSphere Product Center auftreten, ist möglicherweise die Verbindung zur Datenbank verloren gegangen.

Symptome

Die Middleware von WebSphere Product Center ist blockiert oder im Dauer-Wartestatus. Es treten Fehler auf, wenn versucht wird, auf die Middleware von WebSphere Product Center zuzugreifen.

Problemlösung

6. Blockierung des Jobs für Schemaanalyse

Problem

Es wird empfohlen, gelegentlich das Schema zu analysieren, wenn Sie große Datenmengen in die Datenbank laden oder die Datenbanktabellen bereinigen.

Die Middleware von WebSphere Product Center muss gestoppt werden, bevor Sie eine Analyse des Schemas ausführen. Wenn die Middleware nicht gestoppt wird, wird der Job für die Schemaanalyse möglicherweise blockiert, weil die Tabellen noch von der Middleware verwendet werden.

Symptome

WebSphere Product Center ist blockiert, wenn eine Schemaanalyse ausgeführt wird.

Problemlösung

Wenn die Schemaanalyse blockiert ist, brechen Sie den Analysejob ab, stoppen Sie die Middleware von WebSphere Product Center, analysieren Sie das Schema noch einmal und starten Sie WebSphere Product Center erneut.

Analysieren Sie das Schema in regelmäßigen Abständen, um die neusten Statistiken über die Datenverteilung in der Datenbank zu erfassen.


Protokolldateien auf Fehler überwachen

Das Überwachen und Überprüfen von Systemprotokolldateien kann zum Diagnostizieren und Lösen zahlreicher Probleme beitragen.

Hinweis: Dieses Kapitel wird in der nächsten Version des Dokuments erweitert. Sie erhalten dann weitere Informationen zur Verwendung von Protokolldateien und zu Fehlerbehebungsverfahren.


Konnektivitätsprobleme

HTTP-Sendefehler

Wenn HTTP-Sendefehler auftreten, untersuchen Sie Folgendes:

1.    Kann die WebSphere Product Center-Maschine das Ziel erkennen?

  • Verwenden Sie einen Linux- oder Unix-HTTP-Browser, wie z. B. "Lynx", und geben Sie die URL der WebSphere Product Center-Middleware ein, um festzustellen, ob auf das Ziel zugegriffen werden kann.
  • Wenn ein Browser über den WebSphere Product Center-Server, nicht verfügbar ist, versuchen Sie über Telnet auf den Zielport 80 zu gelangen. Beispiel: Wenn die Ziel-URL http://myserver/>urlname< lautet, geben Sie "telnet myserver 80" ein (Port 80 ist der Standard-HTTP-Browser der meisten Web-Server).

2.    Falls WebSphere Product Center das Ziel sehen kann, arbeitet der WebSphere Product Center-Verteiler korrekt?

  • Prüfen Sie in $TOP/public_html/created_files/distributor, ob neue Dateien vorhanden sind. Überprüfen Sie, ob eine Datei die ungefähre Zeitmarke des Zeitpunkts hat, als Sie versuchten, die Datei durchzuleiten.
  • Es ist möglich, dass ein nicht mehr steuerbares Script eine fehlerhafte Ausgabedatei generiert hat. Überprüfen Sie die Dateigröße. Entspricht die Dateigröße Ihren Erwartungen? Wenn es sich um eine XML-Datei oder eine sonstige lesbare Datei handelt, geben Sie die Datei aus. Enthält sie die korrekten Informationen, die Sie erwartet hatten?

3.    Wenn die Datei vorhanden ist, schreitet die Übertragung voran?

  • Sie können verschiedene Tools verwenden, um festzustellen, ob tatsächlich eine Übertragung stattfindet und voranschreitet. Sie benötigen mindestens den kombinierten Einsatz von "netstat" und "snoop" (unter Solaris) oder "tcpdump" (unter Linux).
  • Passen Sie Ihre Erwartungen an. Wenn die Datei 300 MB groß ist, und an eine URL über das Internet übertragen wird, kann die Datei höchstens mit der maximalen Geschwindigkeit der Internetverbindung gesendet werden.

FTP-Abruffehler

Wenn WebSphere Product Center versucht, sich an einem Ziel-FTP-Server anzumelden und das angegebene Verzeichnis nicht finden kann, tritt der Fehler "Unable to change to remote directory."  auf.

Dieser Fehler hat mehrere Ursachen:

Java-Konnektivität testen

Die JDBC-URL wird in der Datei common.properties definiert. Wenn Sie die Java-Konnektivität von der WebSphere Product Center-Middleware zur JDBC-URL testen möchten, verwenden Sie das folgende Script:

$TOP/bin/test_java_db.sh

Das Script versucht, eine Verbindung zur Datenbank herzustellen und einen einfachen Befehl 'select count(*) from dual' auszuführen. Wenn die Verbindung aufgebaut werden konnte, werden die Ergebnisse aus dem Testscript angezeigt.


Sonstige Probleme

WebSphere Product Center stoppen und erneut starten

Es sind Probleme beim Einsatz regelmäßiger Stopscripts unter Linux/Solaris berichtet worden. Anscheinend stoppt WebSphere Product Center nicht ordnungsgemäß und reibungslos. In diesem Fall sollten Sie WebSphere Product Center mit den folgenden Schritten stoppen und starten:

1. Versuchen Sie, WebSphere Product Center auf die "sanfte" Art zu stoppen, indem Sie das folgende Script ausführen:

 $TOP/bin/go/stop_local.sh

2. Warten Sie etwa eine Minute und geben Sie dann den folgenden Befehl ein:

ps –u (Benutzername ohne runde Klammern angeben)

3. Sollten etwaige Java-Prozesse aktiv sein, ist möglicherweise ein terminierter Job noch in der Verarbeitung. Falls gewünscht, können Sie warten, bis der Job beendet ist, oder stoppen Sie ihn manuell mit dem folgenden Script:

$TOP/bin/go/abort_local.sh

Warten Sie etwa 30 Sekunden und geben Sie dann den folgenden Befehl ein:

ps –u (Benutzername ohne runde Klammern angeben)

5. Wenn weiterhin aktive Java-Prozesse vorhanden sind, ist die JVM höchstwahrscheinlich abgestürzt. Die Java-Prozesse müssen manuell mit dem folgenden Befehl abgebrochen werden:

kill `ps -u (Benutzername ohne runde Klammern angeben)
| grep java | cut -b10-15`

Hinweis: Falls noch immer Java-Prozesse vorhanden sind, muss das System eventuell erneut gestartet werden.

6. Wenn alle Java-Prozesse abgebrochen wurden, starten Sie WebSphere Product Center erneut und verwenden Sie das folgende Script:

$TOP/bin/go/start_local.sh

7. Warten Sie etwa eine Minute und prüfen Sie, ob WebSphere Product Center ordnungsgemäß gestartet wurde. Führen Sie das Script $TOP/bin/go/rmi_status.sh aus oder melden Sie sich in der WebSphere Product Center-Umgebung an.