Eigener Bufferpool für Regeldatenbank sinnvoll?
- Dieses Thema hat 1 Antwort und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 14 Jahre von
Anonym.
-
AuthorPosts
-
23. September 2009 um 8:37 Uhr #4049
AnonymInaktivHallo zusammen,
wir haben eine Schreibschnittstelle in Cobol realisiert, die mit Hilfe einer Regeldatenbank (3 DB2-Tabellen, <5MB incl. Indices) Prüfungen ausführt. Zur Laufzeit werden die Regeln gelesen und interpretiert. Vorteil: Wenn neue Regeln erforderlich sind, ist nur ein Insert in die Regeldatenbank erforderlich und keine Programmänderung notwendig.
Die Schreibschnittstelle wird im Online (CICS) und im Batch genutzt.
Normalerweise werden nur wenige Daten in unser System geschrieben. Die IO’s auf die Regeldatenbank fallen nicht so ins Gewicht. Während einer Migration von Fremddaten in unser System werden besonders viele Daten geschrieben.
Analysen im DB2PM haben ergeben, dass ca. 50% der IO’s durch unsere Regeldatenbank verursacht werden.
Nach unseren Analysen wird die kleine Regeldatenbank immer wieder vollständig gelesen.Überlegung: Durch eine Cache-Systematik die Regelbank die IO’S reduzieren.
Frage: Ist die Definition eines eigenen Bufferpools nur für unsere Regeldatenbank, der ausreichend groß ist um die gesamte Regeldatenbank zu speichern eine sinnvolle, vielversprechende Maßnahme?
Um die physischen IO’s auf Platte zu reduzieren?
Um CPU time zu reduzieren?
Um elapsed time zu reduzieren?Andere Lösungsmöglichkeiten? Welche erfahrungen habt ihr.
Freue mich über jeden Hinweis / Ratschlag.
Gruss Klaus
24. September 2009 um 7:10 Uhr #4214
AnonymInaktivHallo Klaus,
das klingt doch alles sehr vernünftig. CPU-Time wirst Du wohl nicht einsparen, die Logik, die ausgeführt werden muss, bleibt ja dieselbe. Also auch die Menge an CPU-Sekunden. Nur der IO wird in den Hauptspeicher verlagert. Da das Lesen von Platte aber wegfällt, werden die CPU-Sekunden schneller abgearbeitet, das kann dann punktuell zu einer höheren prozentualen CPU-Belastung führen.Wir hatten mal den Fall bei einem Join auf 2 Tabellen, die beide in Bufferpool passten, wurde plötzlich ein falscher Plan benutzt. Das führte dann dazu, dass Unmengen von unnötigen Leseoperationen gegen den Pool ausgeführt wurde. Und das hat dann die CPU-Auslastung des Hostes gegen 100% getrieben, weil die CPU nicht mehr auf die Platten warten musste.
bis denn
Kay
-
AuthorPosts
You must be logged in to reply to this topic.