ibm db2 for z/os - s.k. consulting · 1 januar 2013 db2 version 10 kapitel 10: „performance“...

1 Januar 2013

DB2 Version 10

Kapitel 10: „Performance“

(10_DB2V10_performance.pptx)

IBMIBM DB2 for z/OSDB2 for z/OS

(*)

(*) ist eingetragenes Warenzeichen der IBM International Business Machines Inc.

2 Januar 2013

DB2 Version DB2 Version 10 10 -- PerformancePerformance

Inhalte:

(10) Performance und Automation DBA, Anwendungsentwickler • Verbesserte Optimierungstechniken

• Verbesserungen am „Dynamic prefetch“

• „Dynamic statement cache“ Verbesserungen

• INSERT Performance Verbesserungen

• „Hash access“

• Zusätzliche “non-key” Spalten in einem “unique” Index

• Parallelismus Verbesserungen

• Bufferpool Verbesserungen

• „Work file“ Verbesserungen

• Sonstige Verbesserungen

Performance Verbesserungen für lokale Java und ODBC Applikationen

Logging Verbesserungen

LOB Verbesserungen

DB2 Support für “solid state drive”

Erweiterter Support für SQL/PL

„Referential integrity“ checking Verbesserungen

„Preemptable backout“

DDF Verbesserungen

Eliminierung von “mass delete locks” für UTS

Unterstützung des z/OS „enqueue management“

Online performance buffers in 64-bit common

„Enhanced instrumentation“

3 Januar 2013


Performance-Erwartungen

• Verbesserungen der „access paths“ zur Laufzeit

• Index I/O Parallelismus und generelle „sequential insert“ Verbesserungen

• Verbesserte “dynamic prefetch” und “list prefetch” Verfahren für Indexes

• Mehr “query parallelism” und deshalb mehr Verlagerung von Queries und Teilen davon in die zIIP

• Verbesserungen des “buffer pool system paging”

• DDF Optimierung und RELEASE(DEALLOCATE) Nutzung

• Logging Verbesserungen und damit Reduzieren von I/Os und “buffer fixing”

• Synergien mit der neuen Hardware

• Ausnutzen der neuen „hardware instructions“ (z10, z196)

Historisches Ziel unter 5% Performance Rückschritt

Ziel 5% -10% initiale Performance Verbesserung

Einige Transaktionen reduzieren die CPU Zeit um 10% - 20% Durchschn. % C P U Verbesserung von

Version zu Version

4 Januar 2013


Verbesserte Optimierungstechniken – „safe optimization“

Eine rein kostenbasierte Optimierung wird nicht immer den optimalen “access plan” generieren.

Dafür gibt es eine Menge Gründe; z.B.:

• Falsche Annahmen bei der Query Optimierung, wie die “default” Selektivität bei einem RANGE Prädikat

• Ein unbekanntes „runtime environment“, wie z.B.: konkurrierende RID Pool Nutzung etc.

Der DB2 Optimizer kann manchmal das “filtering” eines Prädikat überbewerten. Das passiert z.B.: wenn

Literalwerte unbekannt sind; z.B.: wenn das Prädikat ein “range predicate” ist, wenn die datenverteilung “non uniform”

ist oder wenn Hostvariable bzw. “Parameter Markers” verwendet werden.

Der folgende Wert kann 0-100% einer Tabelle betreffen – abhängig vom vorgesehenen Literalwert:

WHERE BIRTHDATE < ?

Im folgenden Beispiel ist der Wert zu 99% “Y” und zu 1% “N” abhängig vom zur “run time“ eingesetzten Wert:

WHERE STATUS = ?

VOR DB2 10 war die empfohlene Lösung der Einsatz des REOPT BIND Parameters, um so DB2 die Möglichkeit zu

geben, die “access paths” auf der Basis der aktuellen Hostvariablen-Werte neu zu evaluieren. Dennoch ist diese Lösung

nicht in allen Fällen eine gute Lösung, da der “overhead” bei der “reoptimization” jeder SQL Ausführung zutrifft.

DB2 10 quantifiziert diese Kostenunsicherheit und bezieht sie in das “cost-based optimizing” während der Festlegung

des “access path” mit ein, besonders bei der Auswahl eines Index. Haben also zwei IX ähnliche (geschätzte) Kosten-

werte, so wird der DB2 Optimierungsvorgang die Unsicherheit von “matching” und “screening” Prädikaten bei der

Wahl des effizientesten IX berücksichtigen. DB2 wird den IX mit höherer (sicherer) Kostenschätzung einem anderen

mit weniger Kostensicherheit vorziehen.

Diese “safer optimization” Funktion steht bereits unter DB2 10 CM zur Verfügung, wenn BIND/REBIND erfolgt ist.

5 Januar 2013


Verbesserte Optimierungstechniken und „RID Pool“ - Verbesserungen

DB2 nutzt den RID Pool für eine Reihe von SQL “access plans”, inklusive “list prefetch” und “hybrid join”. Wenn

aber der RID Pool voll wird, so sinkt die SQL Performance dramatisch. Der RID Zugriff geht auf einen TS Scan zu-

rück. Alle Arbeit, die bis zu diesem Zeitpunkt geleistet wurde, ist umsonst auch das “index filtering”.

Um diese Fehler abzumildern führt DB2 eine Prüfung der RID Pool Schwellwerte zur BIND Zeit durch. Aber diese

Typen von “RID pool failures” können trotzdem nicht komplett vermieden werden.

Beispiel: DB2 trifft zur BIND-Zeit keine Auswahl eines SQL Zugriffspfads, der “list prefetch”-Verarbeitung enthält,

wenn es schätzt, dass die Query mehr als 25% der “rows” einer Tabelle betrifft. Schätzt der Optimizer allerdings

weniger als 25% “rows” als “matching rows” und wird diese Schätzung schließlich zur “run time” überschritten, so wird

der “list prefetch” abgebrochen. Dieser Schwellwert heisst auch TERMINATED - EXCEEDED RDS LIMIT.

RUNSTATS und REBIND: Es ist in DB2 10 wie auch in vorherigen Versionen eine gute Vorgehensweise RUN-

STATS und REBIND regelmäßig durchzuführen. Das stellt sicher, dass die Statistiken in Plans und Packages aktuell

sind und vermeidet unnötige RID Pool Fehler.

Beispiel: Der RDS “threshold” (25% der “rows” einer Tabelle) wird zur BIND Zeit kalkuliert und in der “skeleton plan

table” bzw. der “skeleton cursor table” gespeichert. Erhöht sich nun die “row”-Zahl der Tabelle signifikant und

RUNSTATS / REBIND wird nicht angestossen, um diese Änderungen zu reflektieren, so kann der gespeicherte RDS

“threshold” leicht überschritten werden, auch in Fällen, in denenn weit weniger als 25% der “rows” gelesen werden. In

diesem Fall steuert DB2 9 unnötiger weise einen TS Scan an.

DB2 10 verwaltet den RID Pool besser und ermöglicht einem “access plan” den RID Pool so lange zu nutzen, so lange

er der günstigste Plan ist. Dies lässt den Optimizer die RID List “access plans” öfter auswählen als früher.

Zur Laufzeit erfolgt ein “overflow” der RIDs auf eine “work file” und die Verarbeitung wird mit 32 KB großen

Sätzen fortgesetzt. Jeder Satz hält nun die RIDs aus einem 32 KB RID Block.

6 Januar 2013


Verbesserte Optimierungstechniken – „Dynamic prefetch“ - Verbesserungen

Mit der DB2 Version 2.3 wurde der “dynamic prefetch” eingeführt. DB2 9 enthielt folgende

Änderungen zum Prefetch:

• “Sequential prefetch” wird nur für TS Scans eingeschaltet

• Beim SQL Zugriff reicht das Maximum für einen Prefetch von 128 KB (32 Pages) bei DB2 V8

bis 256 KB (64 Pages) bei DB2 9 bei “sequential prefetch” und LOB-bezogenem “list prefetch”

für “table spaces” und “indexes”, die auf 4 KB Bufferpools zugewiesen wurden. In DB2 10

beträgt die maximale “prefetch”-Rate immer noch 32 Pages bei “dynamic prefetch” und

“non-LOB list prefetch“.

• Für Utilities, die auf Objekte in 4 KB Bufferpools zugreifen, wurde die “prefetch quantity”

von 256 KB (64 Pages) bei DB2 V8 auf 512 KB (128 Pages) bei DB2 9 angehoben. Diese

Werte ändern sich für DB2 10 nicht.

DB2 10 verbessert die “prefetch” Verarbeitung dennoch und zwar beim “index access”:

• Index Scans können “list prefetch” nutzen

• „Row level sequential detection“ (bisher auf Page – Ebene)

• Progressive „prefetch“ Mengen

Diese Neuerungen sind bereits in DB2 10 CM ohne REBIND oder BIND verfügbar.

7 Januar 2013


Verbesserte Optimierungstechniken – „Dynamic statement cache “ - Verbesserungen

VOR DB2 V5 haben sich viele Applikationsentwickler geweigert, “dynamic SQL” zu nutzen, da jeder

Statement PREPARE Verarbeitung verursachte – ähnlich einem BIND – um den DB2 “access path”

zu wählen. Die Einführung des “dynamic statement cache” bedeutete, dass beim ersten Ausführen

des SQL der “access path” berechnet wurde und jedes weitere Mal, wenn dasselbe SQL Statement

ausgeführt werden sollte, der PREPARE übergangen werden konnte, da der “access path” wieder-

verwendet werden konnte. Dies machte “dynamic SQL “ ähnlich effizient, wie “static SQL”. Gut für

alle Arten von “Customer Relationship Management”(CRM) Applikationen.

In DB2 10 können noch mehr SQL Statements aus dem Cache wiederverwendet werden und

zwar auch für unterschiedliche User. “Dynamic” SQL Statements können nun mit anderen bereits

“cached dynamic SQL Statements” gemeinsam verwendet werden, wenn der einzige Unterschied der

Statements in den “literal values” besteht.

Im “dynamic statement cache” werden Literale mit einem “ampersand” (&) ersetzt, das sich dann

ähnlich einem Parameter Marker verhält. Beispiel:

SELECT BALANCE FROM ACCOUNT WHERE ACCOUNT_NUMBER = 123456

Wird im SQL Cache ersetzt durch:

SELECT BALANCE FROM ACCOUNT WHERE ACCOUNT_NUMBER = &

Wird ein Gemisch aus Literal-Konstanten und Parameter Markers genutzt, so wird DB2 keine Literal

Translation durchführen.

8 Januar 2013



Folgende Methoden schalten diese Funktion ein:

• Auf dem Client sollte das PREPARE Statement die neue Klausel ATTRIBUTES enthalten, die

CONCENTRATE STATEMENTS WITH LITERALS spezifiziert

• Auf dem Client sollte der JCC “Driver” das Schlüsselwort “enableliteralReplacement=‘YES’”

enthalten. Es spezifiziert die “data source” bzw. die “connection property”.

• Die Option LITERALREPLACEMENT in der ODBC Initialisierungsdatei in z/OS sollte

gesetzt sein. Es ermöglicht allen SQL, die über ODBC ins DB2 kommen, das das “literal

replacement” eingeschaltet ist.

Die “lookup” Sequenz im “dynamic statement cache” ist dann wie folgt:

• Original SQL mit Literalen werden im Cache erkannt, was dem Verhalten von “pre-DB2 10”

Releases entspricht.

• Wird es nicht gefunden, so werden Literale ersetzt und das neue SQL im Cache erkannt. DB2

kann nur eine Übereinstimmung mit einem SQL feststellen, das mit demselben Attribut gespeichert

ist. So wird ein SQL im Cache mit “parameter markers” nicht als gleich erkannt.

• Wenn nicht gefunden wird ein neues SQL “prepared” und im Cache gespeichert.

9 Januar 2013



Hier ein Beispiel, wie man die neue Klausel ATTRIBUTES im SELECT nutzen kann:

EXEC SQL DECLARE C1 CURSOR FOR DYNSQL_WITH_LITERAL;

DYNSQL_SELECT = ‘SELECT X, Y, Z FROM TABLE1 WHERE X < 9’;

attrstring = ‘CONCENTRATE STATEMENTS WITH LITERALS’;

EXEC SQL PREPARE DYNSQL_WITH_LITERAL ATTRIBUTES :attrstring FROM :DYNSQL_SELECT;

EXEC SQL OPEN C1;

Hier ein Beispiel, wie man die neue Klausel ATTRIBUTES im INSERT nutzt:

DYNSQL_INSERT = ‘INSERT INTO TABLE1 (X, Y, Z) VALUES (1, 2, 3)’;

attrstring = ‘CONCENTRATE STATEME NTS WITH LITERALS’;

EXEC SQL PREPARE DYNSQL_WITH_LITERAL ATTRIBUTES :attrstring FROM :DYNSQL_INSERT;

EXEC SQL EXECUTE SYNSQL_WITH_LITERAL;

Beim Einsatz von Parameter Markers kann man von einer höheren “dynamic statement cache hit ratio”

ausgehen. Mit Literalen kann man einen besseren Zugriffspfad erhalten. Diese Methode enthält einen

Zielkonflikt, abhängig davon, welche Performance von einem “dynamic SQL call “ erwartet wird. Mit

CONCENTRATE STATEMENTS WITH LITERALS kann man auch eine schlechtere “execution-

only” Performance auslösen. Also ist der größte Performance-Gewinn für kleine “SQL Statements” mit

Literalen zu erwarten, die jetzt einen “cache” Treffer haben, vorher aber keinen hatten.

10 Januar 2013


Verbesserte Optimierungstechniken – „INSERT Performance“ - Verbesserungen

Applikationen mit hoher INSERT Aktivität, können eine Reihe von Anforderungen aufstellen, die

Performace, Skalierbarkeit unf Verfühbarkeit beeinträchtigen. DB2 muss diese Hindernisse

beseitigen, indem es die schnelleren Host- und Speicher-Server beansprucht.

DB2 10 verbessert die Performance für Applikationen mit hohen INSERT Raten durch::

• I/O Parallelität bei „index updates“

• Sequentielle INSERTs in der Mitte eines “clustering index”

11 Januar 2013


Parallelität beim Index Update

• Für Tabellen mit vielen Indexes

• V10 Parallel Index Update

– I/O parallelism für „non-clustered“ Indexes • > 2 Indexes (ohne clustered Index) pro Tabelle

– zPARM: INDEX_IO_PARALLELISM = YES (default)

– Reduzierte Index I/O „wait time“

– Laufzeitvorteil

• Abhängig von Bufferpool „hit ratio“

• Monitoring über IFCID 358 zu I/O Parallelverarbeitung

• bis zu 50% elapsed time Verbesserung gemessen (6 Indexes)

– UTS & klassische „partitioned tablespaces“

Beim INSERT mit DB2 9 muss ein korrespondierender INSERT in alle definierten IX dieser Tabelle

erfolgen. Alle diese INSERTs in die IX werden seriell durchgeführt – immer einer zu einer Zeit.

DB2 10 ermöglicht es, in mehreren IX einer Tabelle parallel zu einzufügen. “Index insert I/O

Parallelismus“ steuert konkurrierende I/O Anforderungen auf unterschiedliche IX im Bufferpool

parallel, mit dem Ziel, die synchrone I/O “wait time” für unterschiedliche IX derselben Tabelle zu

überlagern. Dies kann zu signifikanten Verbesserungen von I/O orientierten INSERT-Lasten und zur

Reduktion von “elapsed times” führen – besonders bei LOAD RESUME YES SHRLEVEL CHANGE

Utility Läufen. Die Utility Funktion ähnelt hier einem MASS INSERT.

12 Januar 2013


Mehr Flexibilität bei der Datenkomprimierung

• Tablespace mit COMPRESS YES

• Datenkomprimierung benötigt ein Dictionary

• Heute in V9 – Dictionary Erstellung

• LOAD, REORG

• LOAD COPYDICTIONARY 1 ... PART 3

– Problem: keine regelmäßige Nutzung von REORG/LOAD

– Anforderung: Anwendung fügt Daten hinzu!

• V10 Neuerung bei Dictionary Erstellung – MERGE

– INSERT

– LOAD .... SHRLEVEL CHANGE

– „Internal threshold“

– Asynchroner Dictionary Aufbau

• Inserts sind unkomprimiert

13 Januar 2013


Index INCLUDE Column

• Optimierung von Abfragen auf die KFZ Tabelle mit Vertrags-/Kundennr., Kasko

• In V9

CREATE UNIQUE INDEX I1 ON KFZ (VERTRAGSNR);

CREATE INDEX I2 ON KFZ (VERTRAGSNR, KUNDENNR, KASKO);

ALTER INDEX I1 ADD INCLUDE COLUMN (KUNDENNR); ...

DROP INDEX I2;

Alternativ

Index I1 geht in „rebuild-pending state“

CREATE UNIQUE INDEX I1 ON KFZ (VERTRAGSNR) INCLUDE (KUNDENNR, KASKO)

Optimierung in V10

14 Januar 2013


„Index probing“

Eine der Herausforderungen der Querytunings ist, dass einige SQL Statements auf Statistiken extrem

sensitiv reagieren und so zum Grund für die Veränderung von “access paths” werden, wenn Packages

neu “gebunden” werden. Der DB2 Optimizer überschätzt manchmal die Filterung eines Prädikates und

das z.B. wenn ein Literalwert unbekannt ist, wie bei “range predicates”, wenn die Datenverteilung nicht

gleichverteilt ist oder “host variables” bzw. “parameter markers” genutzt werden.

VOR DB2 10 war eine bevorzugte Lösung die Option REOPT BIND zu nutzen und so DB2 zu veran-

lassen, die “access paths” auf der Basis der aktuellen Hostvariablenwerte neu zu evaluieren. Aber:

Diese Lösung ist nicht für jeden Fall wünschenswert, da der “overhead” der “re-optimization” bei jeder

Ausführung des SQL erfolgen muss.

In DB2 10 kann der Optimizer die Real Time Statistics (RTS) Daten nutzen und die IX “non leaf

pages” untersuchen, um so bessere Schätzungen zur Filterung bei “matching predicates” zu erzielen.

DB2 10 nutzt das sogen. “index probing” in folgenden Situationen:

wenn das RUNSTATS Utility anzeigt, dass die Tabelle leer ist

wenn das RUNSTATS Utility anzeigt, dass es leere qualifizierende Partitions gibt

wenn die Katalogstatistiken “default” Werte aufweisen

Wenn ein “matching predicate” geschätzt 0 “rows” qualifiziert

Diese neue Query Optimierungstechnologie auch als “index probing” bezeichnet, wird nur für “ma-

tching index predicates” mit fix kodierten Literalen oder wenn REOPT() angegeben ist, angewendet.

15 Januar 2013


„Index probing“

“Index probing” wird auch bei VOLATILE “tables” und Tabellen, die kleiner sind, als die Page-Anzahl,

die im Systemparameter NPGTHRSH angegeben ist. Der Grund: existierende RUNSTATS Werte

sind für diese Tabellen per definitione unrealistisch.

Explain Resultate für “index probing” (“non VOLATILE”)

Man beachte, dass DB2 10 für 11 von13 Queries gut optimiert, während DB2 9 nur für 3 von 13 Queries optimale

Zugriffe finden konnte.

16 Januar 2013


Index-Zugriffe sind nicht immer der effizienteste Weg

47582 Maier

Index auf

PERSONUM

Hash Area (fixe Größe) Overflow Area

SELECT NACHNAME FROM OLTP.PERSONTB WHERE PERSONUM = 47582

Overflow Index

DB2-interner Hash Algorithmus

17 Januar 2013


Index-Zugriffe sind nicht immer der effizienteste Weg – Kandidaten für „HASHING“

Man beobachte Applikationen und “workload” sorgfältig, bevor man “hashing” einführt. “Hash

organized tables” liefern die “response time”-Werte in speziellen Situationen:

die Tabelle besitzt einen eindeutigen “key”

Es gibt Queries, die Gleichheitsprädikate auf “unique” Werte absetzen, damit nur eine “row”

bzw. “columns” einer “row” aus einem einzigen “index key” zurückgegeben werden

Die meisten Zugriffe auf die Daten sind wirklich “random”

Applikationen mit “range scans” über einen “cluster index” werden bei “hash organized tables”

nicht optimal ablaufen. IFCID199 gibt einen Anhaltspunkt, ob Zugriffe wirlich “random” ablaufen.

Die Größe der Daten in den Tabellen ist relativ stabil bzw. die maximale Grösse der Daten

bekannt. Der Platzbedarf für eine “hash organized table” ist fix festgelegt.

Ist die Grösse bekannt, kann der korrekte HASH SPACE zum Zeitpunkt “ CREATE TABLE”

zugewiesen werden, ohne die “overflow area” zu beanspruchen

Es passen möglichst viele einzelne “rows” in eine einzelne Datenpage. – Enthält eine Page zu

wenige “rows”, wird zusätzlich Platz verbraucht, um die Vorteile einer “hash organization” nutzen

zu können

Die Tabelle enthält möglichst viele “rows” von relativ gleicher Größe

Die Vorteile des “hash access” erhöhen sich linear je höher die “levels of an index” eines

“unique key” angelegt sind. “Hash access” wird signifikant besser, wenn ein IX mit 3 oder mehr

Levels ersetzt werden kann.

18 Januar 2013


Hashing einrichten per CREATE TABLE Statement

CREATE TABLE OLTP.PERSONTB

(PERSONUM INTEGER NOT NULL,

...)

ORGANIZE BY HASH UNIQUE (PERSONNUM)

HASH SPACE 1M;

• DB2 erstellt automatisch einen Overflow Index (dient ggf. auch zur Sicherstellung der

Uniqueness des Primary Keys)

• HASH SPACE ~ geschätzte Größe der Tabelle

• Bis zu 64 Columns:

– Definiert als NOT NULL

– Summe der Length Attribute höchstens 255

– Keine LOB, DECFLOAT oder XML Columns

19 Januar 2013


Hashing einrichten per ALTER TABLE Statement

ALTER TABLE OLTP.PERSONTB

ADD ORGANIZE BY HASH UNIQUE (PERSNUM)

HASH SPACE 2G;

• Logische Änderung sofort zur Sicherstellung der Uniqueness

• Physische Reorganisation erst nach REORG:

– Table Space steht auf Advisory REORG Pending (AREOR)

– Overflow Index steht auf REBUILD Pending (PSRBD)

20 Januar 2013


Hashing Performance

Random Select Performance (mit I/O): “Hash table” vs. “3-level Indexed table”

“Class 2 CPU” Reduktion mit “Hash” in Prozent

21 Januar 2013


Hashing Performance

Performance eines CREATE einer “hash table”

Load einer großen “hash table”

22 Januar 2013


Bufferpool Verbesserungen – BP Speicherzuweisungen

Die Verbesserungen am Bufferpool in DB2 10, die bereits im CM verfügbar sind, eröffnen die

Möglichkeit, den Transaktionsdurchsatz zu erhöhen und profitieren von den größeren BP und die

Reduktion der “latch class” 14 und 24 “contention”. Dies wiederum verringert den BP CPU

“overhead” und ,vermeidet “transaktion I/O delays” durch “preloads” von Objekten:

„Buffer storage allocation“

“In-memory table spaces” und Indexes

VOR DB2 10 wurde der Speicher des BP (VPSIZE) zugewiesen, sobald der erste logische “open of a

page set” erfolgte. Dies auch dann, wenn keine Daten eines TS oder IX zugegriffen wurden, die

diesem BP zugeordnet waren. Jetzt wird der BP Speicher “on-demand” allokiert, nämlich, wenn

Daten eingelagert werden. Braucht eine Query dabei nur wenige Datenpages, so wird nur ein kleiner

Teil des BP Speichers zugewiesen.

“logical open” bedeutet, wenn das “page set” entweder physisch OPEN ist (der erste SELECT)

oder “pseudo opened” (beim ersten UPDATE nach einem physischen OPEN für Lesen). Es erfolgt

keine BP “allocation”, da die Zuweisung bereits geschehen ist.

Zusätzlich muss für eine “index-only” Query kein BP für den Tablespace zugewiesen werden. DB2

10 führt keinen “logical open” des TS mher für “index-only” Zugriffe durch.

Bei Bufferpools mit PGFIX=YES Definitionen, fordert DB2 BP mit 1 MB “page frames” an, wenn

solche verfügbar sind – anstatt der bisherigen 4 KB “page frames”.

23 Januar 2013


Bufferpool Verbesserungen – „in memory tablespaces / indexes“

In der Vergangenheit wurden die Kosten für den physischen OPEN eines “page set” vom ersten SQL,

das das “data set” zugriff, getragen. Diese Kosten hatten natürlich Auswirkungen auf die

Applikationsperformance, typischerweise nach einem DB2 Restart. Ausserdem sind bestimmte

Tabellen kritisch für die Applikationsperformance und sollten “resident” in den Bufferpools sein.

DB2 10 besitzt ein Bufferpool Attribut, das man nutzen kann, um festzulegen, dass alle Objekte in

diesem BP sogen. “in-memory objects” sind. Daten von “in-memory” Objekten werden in den BP

“preloaded”, sobald das Objekt physisch geöffnet wird, ausser das Objekt wird für einen Utility Zugriff

geöffnet. Die Pages bleiben “resident” solange das Objekt offen ist.

Wurde ein “page set” als Teil einer DB2 “restart” Verarbeitung geöffnet, so werden IX und TS nicht mit

“prefetch” in den Bufferpool gestellt.

“Page sets” können immer noch physisch VOR dem ersten SQL Zugriff geöffnet werden, indem man

das Kommando ACCESS DATABASE absetzt. Nun kann man alle Daten in den BP “preloaden”.

Anmerkung: Es ist in DB2 10 wichtig, genügend große Bufferpools zu haben, um alle “in-memory

page sets” speichern zu können. DB2 baut einen “access plan” basierend auf dem minimalen I/O

Aufwand für diese “page sets”. Sind die Bufferpools zu klein, um alle Daten aufnehmen zu können,

kann die Performance beeinflusst werden, da DB2 einen “non-optimal access plan” nutzt, der die “extra

I/Os” nicht erlaubt. Dazu kommt noch, dass, wenn DB2 I/Os machen muss, um eine Page in den BP zu

bringen, dieser I/O synchron abläuft, da der “prefetch” ausgeschaltet ist.

24 Januar 2013


„workfile“-Verbesserungen

DB2 10 in NFM unterstützt “partition-by-growth” TS in der “work file database”. “Declared

global tem-porary tables” (DGTTs) bemühen sich um Speicher gegen andere Aktivitäten auf der “work

file data-base”, aber sie können “work file table spaces” nicht zusammensetzen. “PBG work file table

spaces” helfen, diese Applikationen mit SQLCODE -904 (“unavailable resource”) zu minimieren,

indem sie die Möglichkeit schaffen, die maximale Grösse von “work file table spaces” über DSSIZE

und MAXPARTITIONS zu kontrollieren.

Beispiel: Man kann einen “partitioned by growth” TS auf 3 GB begrenzen:

MAXPARTITIONS 3 DSSIZE 1G

Über DB2-”managed segmented table spaces” war diese Funktion nicht verfügbar. Man kann das

Wachstum auf 2 GB oder weniger (mit PRIQTY nK SECQTY 0) limitieren.

Ist der DSNZPARM WFDBSEP NO (“default”), so versucht DB2 ausschliesslich “work file PBG TS”

für DGTT zu verwenden; ist jedoch kein anderer TS vorhanden, so nutzt DB2 diese auch für “work

files”; z.B.: Sorts und CGTTs.

Mit WFDBSEP YES nutzt DB2 für “work files” ausschliesslich “partitioned by growth” TS bei DGTT

und falls kein anderer TS verfügbar ist, erhält die “workfile” Anwendung eine “resource unavailable“.

Bei DGTTs mit großer DSSIZE, kann man größere “work file” TS - d.h.: größer 64 GB - nutzen.

DB2 10 erweitert die Nutztung der “in-memory work files” durch die einfache

Prädikatsevaluation für “work files”. Dies, um die CPU Zeit für Queries, die kleine “work files”

nutzen, zu reduzieren. Diese “in-memory work file” Verbesserung ist in CM verfügbar.

25 Januar 2013


Sonstige Performance- Verbesserungen

• Performance Verbesserungen für lokale Java und ODBC Applikationen

• Logging Verbesserungen (siehe DBA Kapitel 11)

• LOB Verbesserungen (siehe Anwendungsoptimierung Kapitel 05)

• DB2 Support für “solid state drive”

Ein “solid state drive” (SSD) ist ein Speichergerät, das Daten auf einem “solid-state flash memory” speichert,

anstatt auf traditionellen Plattengeräten. Ein SSD enthält Elektrik, die sie in die Lage versetzt, “hard disk drives”

(HDD) zu emulieren. Die “drives” besitzen keine beweglichen Teile und nutzen “high-speed memory”, so dass

sie schnell und energie-effizient sind.

• Erweiterter Support für SQL/PL(siehe Anwendungsoptimierung Kapitel 05)

• „Referential integrity“ checking Verbesserungen (siehe Anwendungsoptimierung Kapitel 05)

• „Preemptable backout“

In DB2 10 wird der SRB, der die “backout” Operation durchführen soll, in einer “enclave” eingeplant, so dass

er auch vorweg uaf eine höhere Priorität gesetzt werden kann. Das “n-thread n-way” Scenario kann dabei eine

CPU “Bremse” für niedriger priorisierte Tasks darstellen. Das System ist aber immer noch verantwortlich für

Operator Kommandos und höher priorisierte Aufgaben.

• DDF Verbesserungen

Die Applikationsperformance und die Transaktionslast im Netz wird optimiert wenn die SELECT Statements mit

der FETCH 1 ROW ONLY Klausel kodiert sind. DB2 erkennt die Klausel im SELECT Statement FETCH 1

ROW ONLY und kombiniert die API Calls und die “messages”, um so die Anzahl “messages” auf Netz und

System zu minimieren.

26 Januar 2013



• Eliminierung von “mass delete locks” für UTS Der “mass delete lock” erfolgt, um eine “mass delete” Operation mit einem INSERT auf “table level” zu

serialisieren. “Mass delete locks” werden für klassische “partitioned” TS in V8, DB2 9 und DB2 10 eingesetzt.

Der “mass delete” Prozess erhält einen “exclusive mass delete lock”. Dann fordert der INSERT, wenn der User

ein deallokiertes Page –Segment wieder allokieren will, einen “shared mass delete lock” an, damit der “mass

delete”, der das Segment freigegeben hat “committed” werden kann und somit kann der “mass delete” natürlich

nicht mehr ROLLBACKed werden. Der “mass delete lock” wird auch dazu genutzt “uncommitted readers” auf

den IX für “mass delete” zu serialisieren.

DB2 10 vermeidet die Notwendigkeit eines “mass delete lock” auf UTS. Die Serialisierung erfolgt über einen

“mass delete timestamp”, der in der “Header Page” aufgezeichnet wird.

• Unterstützung des z/OS „enqueue management“ DB2 V8 nutzt das “enqueue management” des Workload Manager for z/OS (WLM). Hat eine Transaktion die

Hälfte der Zeit des “lock timeout” Wertes auf einen Lock gewartet, so wird die Priorität des WLM in Bezug auf

die Transaktion, die den Lock hält, erhöht (auf die Priorität des “lock waiters”, wenn letzterer eine höhere

Priorität besitzt). Wenn die “lock holding transaction” fertig ist, so nimmt sie ihre originale “Service Class”

wieder auf. Im Falle, dass mehrere Transaktionen einen Lock gemeinsam halten, wird dieser Vorgang auf alle

diese Transaktionen angewendet.

DB2 10 nutzt das “enqueue management” des IBM Workload Manager for z/OS um die “lock holders” und die

“waiters” effizienter verwalten zu können. DB2 informiert den WLM auch über “threads”, die verzögert werden,

weil sie Schlüsselressourcen wie z. B. “enqueues” und kritische “latches” halten.

27 Januar 2013



• Online Performance Buffers in 64-bit common

31-bit ECSA war eine wichtige und wertvolle Ressource in Versionen VOR DB2 10 und die “member Konso-

lidierung in DB2 10 ist geeignet, das Anwachsen auf Anforderung für 31-bit ECSA weiterzuführen. In DB2 10,

ist IFC ein signifikanter Nutzer der 64-bit Eigenschaften.

DB2 “online performance buffers” wurden in die 64-bit Umgebung verlagert. Die Buffer unterstützen jetzt

maximal 64 MB. Das “keyword” BUFSIZE im -START TRACE Kommando erlauft einem max. Wert von

67108864. Das Minimum und die “default” Größen sind auf 1 MB gesetzt (VORHER: 16 MB und 256 KB) .

• „Enhanced instrumentation“

Die DB2 Ausstattung inkludiert in DB2 10 auch noch folgende Verbesserungen:

Einminütiges “statistics trace” Intervall – ohne Rücksicht auf die Spazifikation im zugehörigen DSNZPARM

Parameter

IFCID 359 für den „index leaf page split“: Neuer IFCID zum Monitoring der “index leaf page splits”.

Separate DB2 “latch” und Transaction Locks in der “Accounting Class 8”: Eine neue Monitor Klasse zum

Überwachen der SQL Statements auf systemweiter Ebene, anstatt auf “thread-level“.

Separate DB2 “latch” und Transaction Locks in der “Accounting Class” 8 : DB2 10 externalisiert zwei Typen

von WAITs in zwei verschiedenen Feldern.

Speicherstatistiken für DIST “address space”: Nun ist der Speicher im DIST “address space” überwachbar

„Accounting“ der zIIP SECP Werte: zAAP auf zIIP und zIIP SECP Werte

“Package accounting” Information mit “rollup” (Zwischenergebnissen)

DRDA “remote location statistics” Detail: Diese MVS Funktion kann zum Komprimieren von DB2 SMF

Sätzen genutzt werden

DRDA “remote location statistics” Detail: Mehr Granularität bei der Überwachung von DDF Lokationen.

28 Januar 2013



• Verbessertes Monitoring

In typischen Umgebungen wird DB2 on z/OS “remote” von vielen unterschiedlichen Applikationen zugegriffen.

Diese haben unterschiedliche Eigenschaften. Einige sind wichtiger und einige Applikationen bedienen wiederum

mehr User als andere. Die Unterschiede führen zu folgenden Herausforderungen: Zur Kontrolle der Verbindungen

auf Anwendungsebene enthält DB2 9 ein “set” von Kennzahlen: CONDBAT und MAXDBAT kontrollieren z.B.

“connections” und “threads” auf der Ebene “Subsystem”.

“Rücksichtslose” Programme können DB2 9 Subsysteme überschwemmen, alle “connections” einvernahmen und

wichtige “business applications” behindern.

DB2 9 enthält auch Profile zur Identifikation einer Query bzw. eines “set of queries”. Profil-Tabellen enthalten

Informationen darüber, wie DB2 Statements ausführt oder diese überwacht. Profile werden in der Tabelle

SYSIBM.DSN_PROFILE_TABLE abgelegt. Man überwacht so alle Statements, die über ein Profil identifiziert

werden, auf der Basis von “keywords” und “attributes” aus der Tabelle SYSIBM.DSN_PROFILE_ATTRIBUTES.

Diese tabellen werden von Werkzeugen, wie dem Optimization Service Center (siehe IBM DB2 9 for z/OS: New

Tools for Query Optimization, SG24-7421) verwendet.

DB2 10 for z/OS verbessert die “profile table monitoring” Funktion, indem es die Filterung und die Überwachung

von Schwellwerten für systembezogene Aktivitäten, wie Anzahl “connections”, Anzahl von “threads” und “idle”

Zeiten eines “thread” , unterstützt. Dies bietet die Möglichkeit, die Schwellwerte(Limits), die bisher nur auf “sys-

tem level” über DSNZPARM (CONDBAT, MAXDBAT und IDTHTOIN) verfügbar waren, granularer zu sehen:

• IP Address (IPADDR)

• „Product Identifier“ (PRDID)

• “Role” und “Authorization Identifier” (ROLE, AUTHID)

• “Collection ID” und “Package Name” (COLLID, PKGNAME)

Verfügbar nur für “connections” an DB2 on z/OS über DRDA.

29 Januar 2013


DB2 10 for z/OS –

Im Einsatz, wo andere längst aufgeben...

ibm db2 for z/os - s.k. consulting · 1 januar 2013 db2 version 10 kapitel 10: „performance“...

Documents