Konfiguration DB2
- Dieses Thema hat 6 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 13 Jahre, 9 Monaten von
Anonym.
-
AuthorPosts
-
23. November 2009 um 15:31 Uhr #4061
AnonymInaktivHallo,
ich bin blutiger Anfänger, bzw. habe nur selten etwas mit Datenbanken und speziell DB2 zu tun.
Ich muss eine alten DB2 Version 5 auf NT supporten….und die ist gerade gecrashed.
Aufgesetzt wurde das System Ende der 90er Jahre – der aktuelle Rechner ist ein Image des ersten Rechners (es gibt keine original-CDs mehr!)Die Datenbank hat nur 3 Tabellen für die Fertigung.
Eine ist irrelevant klein (3 Spalten/ ca. 20 Datensätze)
Die 2. hat 30 Spalten / max. ca. 500 Datensätze
Die 3. hat dann schon 60 Spalten und hatte beim Crash ca. 7500 DatensätzenDie Spaltenanzahl ist im laufe der letzten Jahre angewachsen (ca. 10 dazugekommen).
Seit ca. 2 Jahren kamen beim Löschen der Datenbankinhalte immer Fehlermeldungen das die Transaktions-Protokolldateien voll seine.
Daraufhin wurde die Datenbank dann bei ca. 3500 Datensätzen (vorher über 40000) gelöscht.
Jetzt hatte ich die Konfiguration über die Steuerzentrale wie folgt geändert:
Alte Konfiguration Neue Konfiguration
Logfilesize 250 2500
Logprimary 3 50
Logsecond 2 50Locklist 25 50
maxlocks 22 80maxappls steht bei 40 unverändert.
…..der absolute Blindflug.
Was heißt Bindungen erneuern? Ich habe die Datenbank getrennt und neu verbunden….richtig???Was ich nicht geändert habe ist die Größe des Bufferpools…der steht bei Standardeinstellung 250.
Fehlermeldung bei dem Crash bezogen sich auf die volle Ausnutzung des Bufferpools (wortlaut weiß ich jetzt nicht mehr)Highlight der Fehlermeldungen waren das was über einen CRC-Fehler und eine fehlerhafte Protokolldatei!
Was habe ich falsch gemacht / nicht gemacht oder zuviel?
Ich kann mit den Angaben in der DB2-Hilfe und im www kaum etwas anfangen, da mein Wissen gegen Null tendiert!Brauche dringend Hilfe!
Viele Grüße
Verena Speer
23. November 2009 um 18:14 Uhr #4223
AnonymInaktivHi Heinzdosenkohl (oder lieber Verena?),
das Vergrößern der Log-Dateien ist schon mal der richtige Weg, um die Löschprobleme zu lösen.
Mit "Bindungen erneuern" (die deutsche Version ist nicht immer verständlich übersetzt >:( ) würde ich ein REBIND auf die Packages ("Pakete") verstehen. Habt Ihr Programme im Einsatz, um die Daten auszuwerten oder zu löschen?
Ein Bufferpool von 250 Blöcken (Pages) ist nur 1 MB groß. Auch unter Windows dürfte er deutlich größer sein, je nach Hauptspeicher des Servers (2500 = 10 MB, 25000 = 100 MB). Wenn mit der Datenbank nicht viel gearbeitet wird, bringt die Vergrößerung des Bufferpools nicht unbedingt eine große Leistungssteigerung. Allerdings wäre die Fehlermeldung wichtig, um das Problem genau beurteilen zu können. Eine Vergrößerung Eures Bufferpoolchens kann aber nicht schaden. 😉MfG
AxelP
23. November 2009 um 18:23 Uhr #4344
AnonymInaktivHi,
ich hab mal das db2diag-logfile auf die Meldungen von heute gekürzt und hänge das mal dran…
Viele Grüße
heinzdosenkohl 😉23. November 2009 um 19:10 Uhr #4428
AnonymInaktivHallo Verena,
das Handbuch sagt zu SQLCODE -984 folgendes:
SQL0984C
COMMIT oder ROLLBACK nicht erfolgreich abgeschlossen. Nachfolgende SQL-Anweisungen können nicht verarbeitet werden.
Erläuterung:Ein Commit oder Rollback konnte auf Grund eines Systemfehlers nicht erfolgreich ausgeführt werden. Das Anwendungsprogramm darf keine zusätzlichen SQL-Anweisungen ausgeben. Eine Recoveryroutine, die dem Anwendungsprogramm zugeordnet ist, darf beispielsweise keine zusätzlichen SQL-Anweisungen ausgeben. Die Datenbank erhält eine Markierung, die besagt, dass eine Recovery erforderlich ist. Alle Anwendungen, die die Datenbank verwenden, werden am Zugriff auf die Datenbank gehindert.
Die Anweisung kann nicht verarbeitet werden.
Benutzeraktion:Notieren Sie die Nachrichtennummer (SQLCODE) und alle Fehlerinformationen aus dem SQL-Kommunikationsbereich (SQLCA), sofern dies möglich ist. Beenden Sie alle Anwendungen, die die Datenbank verwenden. Starten Sie die Datenbank erneut. Wird die Beispieldatenbank installiert, löschen Sie diese, und installieren Sie sie erneut.
Ist die Recovery nicht möglich, stellen Sie die Datenbank mit Hilfe einer Backup-Kopie wieder her.
War der Trace aktiv, rufen Sie an der Eingabeaufforderung des Betriebssystems die unabhängige Trace-Einrichtung auf. Teilen Sie dem Kundendienst die folgenden Informationen mit:
Erforderliche Informationen:
  * Fehlerbeschreibung
  * SQLCODE
  * Inhalt des SQL-Kommunikationsbereichs (SQLCA), wenn möglich
  * Trace-Datei, wenn möglichBenutzer föderierter Systeme: Stellen Sie fest, in welcher Datenquelle die Anforderung fehlgeschlagen ist (die Vorgehensweise wird im Handbuch Fehlerbehebung beschrieben). Ergreifen Sie dann die erforderlichen Diagnosemaßnahmen, und führen Sie die Schritte zur Recovery der Datenbank für die betreffende Datenquelle aus. Da es für unterschiedliche Datenquellen auch unterschiedliche Vorgehensweisen zur Problembestimmung und Datenbankrecovery gibt, sind die in der für die betreffende Datenquelle gültigen Dokumentation enthaltenen Angaben zu befolgen.
sqlcode: -984
sqlstate: 58005
Probier’s mal so:
– db2 deactivate db db
– db2stop
– db2start
– restart database db
Sollte dies nicht helfen, wird wohl der RESTORE der Datenbank erforderlich sein.Auf jeden Fall solltest Du die Logs ganz schnell ausreichend groß einrichten. Insgesamt können (ich glaube bis V7.1) max. 2 GB als Log Space verwendet werden. Dies ergibt sich durch eine einfache Multiplikation von (LOGPRIMARY+LOGSECOND)*LOGFILSZ. Eine hohe Anzahl LOGSECONDary hat den Vorteil, dass die Log Files wieder gelöscht werden, sofern sie nicht mehr benötigt werden, also nur bereitstehen, wenn sie (dringend) benötigt werden.
‚Ne Frage zur Vorsicht: Die Platte hat noch ausreichend Kapazität? :-[ Und ein CHKDSK meldet auch keine Plattenprobleme?  :-/
Viel Erfolg
Gernot
23. November 2009 um 20:20 Uhr #4482
AnonymInaktivHallo, danke erst mal für die schnellen Antworten!
Probier’s mal so:
– db2 deactivate db db
– db2stop
– db2start
– restart database db
Sollte dies nicht helfen, wird wohl der RESTORE der Datenbank erforderlich sein.….mach ich das in der Steuerzentrale? Da finde ich nur ein "Erneut starten" (also restart) oder mit der Befehlszentrale?
Plattenplatz ist schon noch was da (ca. 8 GB)….halt ein neuerer Rechner mit dem Image drauf.
Ist die neue Konfiguration der Logfiles immer noch zu Klein?
Neue Konfiguration
Logfilesize 2500
Logprimary 50
Logsecond 50Locklist 50
maxlocks 80Die Bufferpools muss ich auf jeden Fall vergrössern.
Viele Grüße
heinzdosenkohl
24. November 2009 um 19:42 Uhr #4510
AnonymInaktivHi Verena,
Du kannst wie folgt DB2 Commands direkt eingeben:
– Windows Start Button
– Ausführen: db2cmd
– in eine ‚DB2 CLP‘ Fenster – sieht aus wie ein DOS Fenster -Â jeden Command mit "db2 … cmd …" beginnen
– Hilfe gibts mit "db2 ?"Es gibt einen Thread im Forum, der eine ähnliche Konstellation beschreibt, allerdings ging es um Hauptspeicher. Allerdings ist der Thread vor allem wegen der Vorgehensweise interessant für Dich. Schau also bitte mal nach … https://www.ruban.de/cgi-bin/yabb2/YaBB.pl?num=1225363616
Melde Dich, wenn Du noch ‚was brauchst!
Gruß
Gernot
3. Dezember 2009 um 14:34 Uhr #4531
AnonymInaktivHallo,
melde mich erst spät….hab in dem empfohlenen Beitrag gestöbert….habe aber noch nichts angewendet.
Es hat sich herausgestellt, das der Absturz durch den defekten Lüfter der CPU verursacht wurde.
Die schlecht optimierte DB besteht aber immer noch….leider komme ich nur zur Zeit nicht online an den Rechner.
Die Änderungen bezüglich des Bufferpools muss ich also verschieben bis ich demnächst selber dort aufschlage.
Ich fürchte allerdings das ich aus mangelnden DB-Kenntnissen nur eine gerade mal funktionierende DB hin bekomme… :-[Wie üblich ist das Problem direkt von anderen Problemen überlagert worden…wenn man Wissen selten anwendet vergisst man so schnell…hänge jetzt an einem SQL-Problem fest!
Hier erst mal Danke für die Hilfe! Ich weiss zumindest wo ich auf jeden Fall dran schrauben muss!
Viele Grüße
Verena -
AuthorPosts
You must be logged in to reply to this topic.