- Protokolldateianalyse
- netstat
- ps
- kill
- svrmgrl oder sqlplus
- telnet
- jar
- tar
- gunzip
- Oftmals ist Superuserzugriff auf Web und Anwendungsserver unerlässlich
Probleme mit der Umgebung
Der Pseudobenutzer auf dem Anwendungsserver muss in WebSphere Product Center die folgenden Umgebungsvariablen konfigurieren, bevor er WebSphere Product Center startet:
- TOP: Das Stammverzeichnis, in dem WebSphere Product Center installiert ist
- DB2_HOME: wird für DB2-Client-Binärobjekte benötigt
- JAVA_HOME: wird für das JDK benötigt
- PATH: Muss $DB2_HOME/bin und sollte $JAVA_HOME/bin einschließen
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
- common.properties
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.
- Lizenzdatei
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.
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
- Stellen Sie sicher, dass ausreichend freier Speicherbereich in den Tabellenbereichen verfügbar ist. Bei größeren Jobs wird möglicherweise noch mehr Speicherplatz in den ROLLBACK- und temporären Segmenten benötigt.
- Überprüfen Sie täglich die Alertprotokolldatei der Datenbank, um festzustellen, ob etwaige Fehler generiert wurden, die mit Speicherplatzproblemen in der Datenbank zusammenhängen.
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
- Erhöhen Sie die Anzahl der Protokolldateien
- Erhöhen Sie die Anzahl der Protokolldateien für den Widerruf des Protokollwechsels.
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
- Überprüfen Sie den Status des Listener-Prozesses.
- Überprüfen Sie den Status der Datenbank, wenn Sie keine Verbindung zur Datenbank herstellen oder die Anzeigen der Middleware von WebSphere Product Center nicht aufgebaut werden können.
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.
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.
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:
- Die Ziel-FTP-Adresse ist über den WebSphere Product Center-Server nicht zugänglich. Versuchen Sie, über den WebSphere Product Center-Server eine direkte FTP-Übertragung an das Ziel-FTP auszuführen, und prüfen Sie die Dateiübertragung.
- Der verwendete Dateiname ist möglicherweise falsch. Überprüfen Sie, ob Sie Fehler in der Großschreibung oder Rechtschreibfehler gemacht haben.
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.
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.