In Pufferpool 4096 sind keine Seiten verfügbar
- Dieses Thema hat 6 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 14 Jahre, 10 Monaten von
Anonym.
-
AuthorPosts
-
30. Oktober 2008 um 10:46 Uhr #4007
AnonymInaktivHallali,
habe das Forum schon durchsucht und möglicherweise jenen Topic übersehen, in welchem nachfolgendes Problem bereits behandelt wurde.
Für diesen Fall: im Voraus "Sorry.".Problem:
Folgende Fehlermeldung:
SQL1218N In Pufferpool "4096" sind zur Zeit keine Seiten verfügbar. SQLSTATE=57011Keine Ahnung, was ich tun soll, da ich bereits sämtliche Bufferpools, die sich vergrößern lassen (besser gesagt: die ich gefunden habe) vergrößert habe.
Die Frage ist natürlich auch, was mit "4096" gemeint ist. Kann ich irgendwie erkennen welcher Bufferpool 4096 ist?Im Einsatz ist DB2 Version 8.1 15254
Betriebssystem: Windows Standard-Server 2003 Service Pack 2 Standard EditionVielen Dank im Voraus
Mit freundlichen Grüßen
Jürgen Büchner
3. November 2008 um 20:44 Uhr #4180
AnonymInaktivHallalo,
erstmal vorneweg: Die Version V8.1 geht am 30.04.2009 aus der Wartung! Die neue Version 9.1 oder 9.5 bietet erheblich mehr Komfort, was die automatische Konfigurierung des Systems anbelangt. Hier ist sehr viel passiert, so dass schon deswegen der Umstieg lohnt. [Zahlreiche Infos hier auf der Web Site!]
Unter Umständen lohnt der Blick auf den AUTOCONFIGURE-Befehl, auch unter V8!
Hier findet man zum DB2 V8 Info Center: http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp, Suchbegriff Bufferpool eingeben.
Die Bufferpools können mit "S ELECT * FROM SYSCAT.BUFFERPOOLS" abgefragt werden.
Für die Performance ist wichtig, dass verfügbarer Hauptspeicher, der für Bufferpools verwendet werden kann, auf Objekte mit unterschiedlichen Eigenschaften verteilt wird. Also kleine Referenz-Tabellen beispielsweise in einen separeten Bufferpool. Objekte, die 1-malig, oder wenig, dafür meist vollständig gelesen werden (z.B. in einem Data Warehouse) in andere Bufferpools, Indexes in separate Bufferpools legen.
Ein paar Fragen zum System:
A) Wie groß ist der bzw sind die Bufferpools?
B) Art des DB-Systems: Transaktionen oder Auskunfts-System?
C) Größe des realen Hauptspeichers?
D) Kann DB2 den Speicher konsumieren oder gibt es weitere Anwendungen auf dem System?Viele Grüße
Gernot RubanPS: Wem das Control Center (Steuerzentrale) zu umständlich und zu langsam ist, der sollte auf [highlight]DbVisualizer[/highlight] umsteigen. Es gibt sogar eine "Free Version", die persönliche Premium Lizenz kostet €160. Bei http://dbsc.de/Software/Software_von_MINQ/Minq_DbVisualizer_Preise_und_A/minq_dbvisualizer_preise_und_a.html reinschauen!
6. November 2008 um 12:08 Uhr #4312
AnonymInaktivHallali Herr Ruban,
vielen Dank für die Antwort.
Das Problem ist, dass die DB2-Datenbank seither grundsätzlich funktioniert hat.
Nun sind jedoch weitere Datenbanken hinzugekommen und das Bufferpool-Problem tritt auf, wenn zusätzlichen Datenbanken
verwendet werden.Vorab:
REORGS und RUNSTATS laufen regelmäßig bzw. diese werden grundsätzlich direkt nach dem Laden von Tabellen ausgeführt.
Der Fehler ist aber nicht in diesem Zusammenhang bzw. zu jenem Zeitpunkt aufgetreten, wo REORGs bzw. RUNSTATs gelaufen sind.
Was ist mit Non-Advanced Windows gemeint?
Kann Windows 2003 mehr als 2 GB Hauptspeicher addressieren bzw. kann DB2 auf darüberliegenden Speicher bei Windows 2003 zugreifen bzw. wo und wie kann ich dies erkennen?Hier noch einige Antworten auf Ihre in der Antwort enthaltenen Fragen, woraus sich möglicherweise weitere Anhaltspunkte bzw. Antworten ergeben. Insbesondere vieleicht auch, was mit "In Pufferpool "4096"" gemeint ist.
A) Wie groß ist der bzw sind die Bufferpools?
BPNAME Â Â Â NPAGES Â BUFFERPOOLID Â PAGESIZE
BP_XY1 Â Â Â 120000 Â 2 Â Â Â Â Â Â 4096
BP_XY2 Â Â Â 10000 Â Â 5 Â Â Â Â Â Â 16384
BP_XY3 Â Â Â 100000 Â 3 Â Â Â Â Â Â 4096
BP_XY4 Â Â Â 60000 Â Â 4 Â Â Â Â Â Â 4096
IBMDEFAULTBP 60000 Â Â 1 Â Â Â Â Â Â 4096B) Art des DB-Systems: Transaktionen oder Auskunfts-System?
Ich denke Auskunftssystem (kann ich das irgendwo nachträglich abfragen?)C) Größe des realen Hauptspeichers?
Angepaßte Installation Windows Standard Server 2003 – Intel(R)Xeon(TM) CPU 2.40 GHz 2.39 GHz, 2,50 GB RAMD) Kann DB2 den Speicher konsumieren oder gibt es weitere Anwendungen auf dem System?
Neben DB2 befindet sich auf dem DB2-Server noch ein Webserver und diverse Perl-Skripte, sowie natürlich die DB2-"Geschichten", wie z. B. die Steuerzentrale.Habe nachfolgend noch nachgesehen, was DB2 (via Steuerzentrale) für Einstellungen empfehlen würde.
Wenngleich ich hier bei den Vorgaben keine Änderungen gemacht habe.
Hier der entsprechende Screenshot:
<a href="http://www.bildercode.de/galerie/1225973020_59817/configdb2.gif">
<img src="http://www.bildercode.de/img/1225973020_59817/s/configdb2.gif" border="0" title="http://www.bildercode.de kostenloses Bilderhosting">Tschüüüsss und schonmal wieder vielen Dank im Voraus
Jürgen Büchner
7. November 2008 um 7:10 Uhr #4405
AnonymInaktivGuten Morgen,
Win 2003 Standard Server kommt mit max 4 GB zurecht, DB2 kann 2 GB, bei Nutzung eines Features 3 GB nutzen. Das liegt in der Natur der Sache – 32 Bit Adressierung. Ich empfehle zu diesem Thema das IBM Redbook "Scaling DB2 UDB on Windows Server 2003" http://www.redbooks.ibm.com/redbooks/pdfs/sg247019.pdf. Um die vielen Parameter, die DB2 anbietet, zu verstehen, empfehle ich den Aufsatz "The DB2 UDB memory model – How DB2 uses memory" http://www.ibm.com/developerworks/db2/library/techarticle/dm-0406qi/.
Zugegeben, viel Lesestoff für jemanden, der von der Problematik überrascht wird.  😕Im Grunde sieht es doch gar nicht so schlecht aus. Die Frage ist nun, an welcher Stelle (Statement, Tabelle) tritt das Problem auf? Häufig hilft ein Blick in das DB2 Diagnose Log, unter …sqllibdb2 als db2diag.log zu finden. [Ansonsten unter …sqllib mit dir -s db2diag.log suchen.]
Steht hier nichts Aufschlußreiches kann der Grad der Diagnose erhöht werden:
1) <Start> <ausführen> "db2cmd"
2) Command eingeben: db2 get dbm cfg (Hier stehen diagpath [da steht als das db2diag.log] und der diaglevel. Den Level ggf. auf z.B. 4 erhöhen
3) db2 update dbm cfg using diaglevel 4
4) Den schadhaften Prozess wiederholen und einen Blick in das db2diag.log werfen.Wenn wir hier gerade sind! Die Konfiguration (die wir hier vielleicht noch benötigen) kann man wie folgt auslesen (und mit dem cmd>>config.file gleich in eine File umlenken):
[tt]ver[/tt] Â Â Â Â Â Â Windows Version
[Folgende Commands im db2cmd bzw. db2clp Fenster:]
[tt]db2level[/tt] Â Â die DB2 Version
[tt]db2lic -l   [/tt]  die DB2 Software Version
[tt]db2 get dbm cfg
db2 get db cfg for [db][/tt]Die Bufferpools sind verhältnismäßig groß. Eigentlich sollte eine Operation damit zurecht kommen. Ich vermute der Übeltäter ist  ein  Massen-Update mit keinem COMMIT oder zu geringer COMMIT Frequenz?
Vielleicht liegen Tables/Tablespace in ungeeigneten Bufferpools und könnten in einen größeren verlegt werden?Hast Du die Erklärung zu SQL1218N eigentlich schon gelesen? Vielleicht hast Du eine Idee?
[tt]Der Pufferpool ist nicht groß genug, um zu diesem Zeitpunkt Seiten für alle Datenbankprozesse und -Threads bereitzustellen. Entweder ist der Pufferpool zu klein, oder es sind zu viele Prozesse und Threads aktiv.
Die Anweisung wird bei einem erneuten Versuch möglicherweise erfolgreich ausgeführt. Tritt dieser Fehler häufig auf, ergreifen Sie mindestens eine der folgenden Maßnahmen: 1. Vergrößern Sie den Pufferpool.
 2. Verringern Sie die maximale Anzahl von Datenbankagenten und/oder Datenbankverbindungen.
 3. Verringern Sie den maximalen Grad der Parallelität.
 4. Verringern Sie den Wert für die Vorablesezugriffsgröße für die Tabellenbereiche in diesem Pufferpool.
 5. Versetzen Sie einige Tabellenbereiche in andere Pufferpools.[/tt]Da fallen mir die Parameter (siehe DBM/DB CFG Output)  INTRA_PARALLEL, DFT_DEGREE und MAX_QUERY_DEGREE
ein: Auf OFF bzw 1 stellen, also Parallelität ausschalten.Ansonsten sollten wir hier erstmal einen Blick auf DBM und DB CFG, vielleicht auf Meldungen im DB2DIAG.LOG werfen.  :-/
Viel Erfolg
Gernot8. November 2008 um 7:12 Uhr #4468
AnonymInaktivHallali Herr Ruban,
Wow!!! Eine total umfangreiche Antwort von Ihnen. Bin begeistert und momentan dabei die von Ihnen benannten Links bzgl. DB2 und Win2003 durchzulesen (wenngleich "lesen" und "verstehen" nicht zwangsläufig deckungsgleich sein müssen).
Habe die Dingelchen, die Sie genannt haben, durchgeführt (so weit es möglich war), konnte den Fehler aber nur bedingt eingrenzen, da jener Bufferpool-Fehler nicht unbedingt sofort auftritt. Gestern ist er bspw. in der massiven Art (dass gar nichts mehr ging) gar nicht aufgetreten, jedoch konnte im Logfile erkannt werden, dass es bzgl. Bufferpool bzw. Speicher nicht sehr gut aussieht und es nur eine Frage der Zeit sein würde, bis die Meldung "In Pufferpool 4096 sind keine Seiten verfügbar" wieder aufblitzt.
Ich deute die Sache jetzt erst mal so: Die Default-Bufferpools bzw. jene, die manuell angelegt wurden, laufen voll. Im nächsten Schritt verwendet DB2 von sich aus irgendeinen Systembufferpool, den es mit "Pufferpool 4096" benennt (weswegen ich diesen auch nirgends finde). Tja, und dieser läuft schließlich auch noch voll und das war’s dann. Lieg ich da vom Prinzip (bzgl. Verständnis) her richtig?
Aber nun der Reihe nach:
1.) Systemwerte:
Hier, jeweils als Link hinterlegten Werte von DB2, von den Datenbanken, von der Windows-Version, usw.:
a) Windows-Version: ver
b) DB2Level: db2level
c) DB2-Konfiguration: db2 get dbm cfg
d) Die verschiedenen Datenbanken (MISIP, IPO, IPOTEMP, MARZIPAN, TOOLSDB, MISOLAP):
– MISIP = db2 get db cfg for misip
– IPO = db2 get db cfg for ipo
– IPOTEMP = db2 get db cfg for ipotemp
– MARZIPAN = db2 get db cfg for marzipan
– MISOLAP = db2 get db cfg for misolap
– TOOLSDB = db2 get db cfg for toolsdb2.) Logfile mit Bufferpool-, Speichermeldungen:
Hier Passagen aus dem Logfile, als es die Bufferpoolprobleme gab:
db2diaglog.txtHabe DB2 daraufhin gestoppt, neu gestartet und es wurde dafür gesorgt, dass nur noch auf die MISP-DB und nicht mehr auf die anderen DBs zugegriffen wird, wodurch zumindest die MISIP-DB problemlos lief. Allerdings werden die anderen DBs auch benötigt, weswegen ja dieser Eintrag im Forum entstand. Die anderen DBs benutzen übrigens andere Bufferpools. Bei der IPO ist es der Systembufferpool mit der Größe 256 und bei der IPOTEMP ist es der Systembufferbool mit einem extrem hohen Wert zwischen 60.000 und 270.000 (sorry… schreibe dies gerade von zu Hause und habe dämlicherweise den Wert nicht parat).
3.) Änderungen an den DB2-Einstellungen:
Habe die Einstellungen mal entsprechend Ihrer Antwort angepasst.
INTRA_PARALLEL habe ich belassen, da es bereits auf "Nein" stand.
Bei MAX_QUERYDEGREE habe ich den Wert auf von "-1" auf "1" gesetzt und die beiden im Screenshot dargestellten Häkchen deaktiviert.
max querydegree.gifEine Veränderung konnte ich nur insofern feststellen, dass es Anwendungen gab, die danach gefühlsmäßig langsamer liefen und andere Anwendungen bei denen die Ausführungsgeschwindigkeit offensichtlich stieg.
Wie aus dem Logfile erkennbar gab es während dieser Tests trotzdem Bufferpool-, Speicher-, sowie einige andere Meldungen, die ich auszugsweise hier als Link beigefügt habe:
db2diaglog.txt nach AnpassungTja, nun bin ich erstmal wieder mit dem Latein am Ende. Bzgl. Massenupdate mit keinem COMMIT oder zu geringer COMMIT-Frequenz bin ich momentan überfragt. Musss mich da ggf. noch vertiefen, ob dies irgendwo der Fall ist. Zusätzlich werde ich mal den Bufferpool bei der IPOTEMP deutlich verkleinern.
Vieleicht haben Sie ja noch eine Idee (Ferndiagnose), welche aufgrund meines Geschriebsels zur Lösung führen könnte.
Mit freundlichen Grüßen
Jürgen Büchner
10. November 2008 um 20:06 Uhr #4498
AnonymInaktivHi,
wenn ich ins db2diag.log schaue sehe ich zum Beispiel "Private memory and/or virtual address space exhausted.", oder "Database will come up with hidden buffer pools."
Vermutlich ist der Server einfach AM ENDE! Die alte bekannte Maurer-Problem: "Koi Speis mehr!"
Ich dachte erst, es würde sich nur um eine einzelne Datenbank handeln. Aber wenn die Bufferpools einer Datenbank schon 1 GB verzehren, naja …  😛
Deswegen sollte man nun erstmal den Hauptspeicher auf dem DB2 Server kontrollieren. Dafür stehen graphische Oberflächen zur Verfügung:
- Windows Monitor: Start – Programme -Verwaltung – Leistung – Leistungsindikator hinzufügen: Speicher/Verfügbare KB
- DB2 Memory Visualizer: Über Steuerzentrale oder [tt]db2cc -mv[/tt]
Mit DB2 Commands dann weiter in die Tiefe steigen …
- DB2 Memory Tracker: [tt]db2mtrk -i -d -w [-v][/tt]
- [tt]db2pd -osinfo  [/tt]  (zeigt CPU’s, Hauptspeicher inges. etc pp)
Bei Konfigurations-Änderungen beachten: Besser DB2 Datenbank ([tt]db2 deactivate db …/db2 activate db …[/tt]) oder Instance ([tt]db2stop/db2start[/tt]) durchstarten. Weil wir gerade bei dem Thema sind: [tt]db2 activate db …[/tt] bereitet die Datenbank für deren Nutzung vor, d.h. alle Speicherbereiche werden eingerichtet. In allen anderen Fällen geschieht das erst mit dem 1. Connect eines Benutzers. Ohne ACTIVATE und wenn sich alle Benutzer wieder abgemeldet haben, "fällt die Datenbank" (im Hauptspeicher) sozusagen wieder zusammen.
Sprich: Für Beobachtung des üblichen Hauptspeicherbedarfs ist [tt]db2 activate db …[/tt] also gar nicht schlecht!  😉Unter Umständen würde es helfen die Datenbanken auf 2 Instanzen auf demselben Server zu verteilen. Die dürften insgesamt mehr Speicher adressieren und besser ausnützen dürfen?!
In Anbetracht der Hautpspeicher-Situation Datenbanken gewichten, Bufferpool-Größen und Konfigurationsgrößen von weniger wichtigen DB’s herunterfahren. Diese übergroßen Bufferpools mit 60.000 und 270.000 Bufferpool Pages unbedingt radikal reduzieren – einfach mal mit z.B. 5.000 und 10.000 probieren!
Wir sind gespannt wie es weitergeht! Â 😮
Viel Erfolg
Gernot RubanPS: Ähm, am Ende der Analyse vielleicht dann kein [tt]db2 activate db …[/tt] mehr, damit der knappe Speicher von inaktiven DB’s dann schnell wieder den anderen aktiven DB’s zur Verfügung steht!
16. November 2008 um 3:43 Uhr #4520
AnonymInaktivHallali Herr Ruban,
vielen Dank für die gelungene Hilfe durch Ihre Antworten.
Sicherlich sind die Datenbanken immer noch weit davon entfernt optimal konfiguriert zu sein… aber zumindest "laufen" sie nun, ohne dass die Bufferpools überlaufen.
Besonders hilfreich war der Hinweis auf "db2 activate db", da so direkt beobachtet werden konnte, wie das System peu à peu in die Knie ging.
Nachdem ich die Bufferpools für die einzelnen DBs inzwischen angepasst habe sieht nun die "db2diag.log"-Datei wieder halbwegs akzeptabel aus.
Nachfolgend erkennbar der aktuelle Speicherplatzverbrauch (via DB2 Memory Visualizer) der einzelnen Datenbanken:
Hier die aktuellen Bufferpools, mit denen das System nun "läuft":
"db2pd -osinfo" ergibt nun folgendes Bild:
OSName: WIN32_NT
NodeName: G021SPWMK1MIS1
Version: 5.2
Release: Service Pack 2
Machine: x86 Family 15, model 2, stepping 7CPU Information:
TotalCPU OnlineCPU ConfigCPU Speed(MHz) HMTDegree Cores/Socket
4 4 4 2394 2 1Physical Memory and Swap (Megabytes):
TotalMem FreeMem AvailMem TotalSwap FreeSwap
2560 285 285 3950 3659Virtual Memory (Megabytes):
Total Reserved Available Free
6510 n/a n/a 3944In den nächsten Tagen wird noch ein bisschen Hauptspeicher eingebaut, der ein oder andere Bufferpool noch angepasst werden und dann dürfte wieder ausreichend Platz vorhanden sein (zumindest was die Bufferpooldinge betrifft).
Also… nochmals vielen Dank und bis vieleicht bald mal wieder.
Mit freundlichen Grüßen
Jürgen Büchner
-
AuthorPosts
You must be logged in to reply to this topic.