IBM DB2 for z/OS

1 Oktober 2012

DB2 Version 10 – Kapitel „Anwendungsoptimierung“

(05_DB2V10_anwendungsoptimierung.pptx)

IBMIBM DB2 for z/OSDB2 for z/OS

(*)

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

2 Oktober 2012

DB2 Version DB2 Version 10 10 -- MigrationMigration

DB2 10 for z/OS –

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

3 Oktober 2012

DB2 Version DB2 Version 10 10 –– AP OptimierungAP Optimierung

Inhalte:

(5) Anwendungsoptimierung DBA, Anwendungsentwickler

• Caching von SQLs mit Literalen

• Vereinfachung bei Transaktionsverarbeitungen

• „inline“ LOBs

• RID Pool Nutzung

• RI Integrity Checks

• Die Precompiler NEWFUN Option

• Erweiterter Support für SQL/PL

4 Oktober 2012

DB2 Version DB2 Version 10 10 -- AP OptimierungAP Optimierung

Kunde

kundennummer

vorname

nachname

ort

------

------

Maier

Stuttgart

SELECT KUNDENNUMMER + +

+ + = 'Maier' + NACHNAME

Stmt A

Stmt I

ORT + FROM ISV.KUNDE WHERE

'Stuttgart' = AND + + +

Statements mit Literalen überfüllen den DB2 Cache

5 Oktober 2012


Änderungsmöglichkeit ist oft nicht gegeben

• Bisherige Ausgangslage:

X Schlechte Coding Praxis oder Notwendigkeit für hochdynamisches SQL mit

String Concatenation

X Nutzung externer Frameworks oder Anwendungen

• Lösung mit DB2 10:

– Literal Replacement liefert generisches SQL

– Dabei werden ohne Eingriff in die Anwendung Literale durch & ersetzt (ähnlich

Parameter-Markern)

SELECT ORT FROM ISV.KUNDE WHERE KUNDENNUMMER = 2337168

SELECT ORT FROM ISV.KUNDE WHERE KUNDENNUMMER = &

...

6 Oktober 2012


Aktivieren von „Literal Replacement“ in Anwendungen

Auf Connection-Ebene in Java

((DB2Connection)con).setDBStatementConcentrator(2);

pstmt = conn.prepareStatement ("SELECT NACHNAME FROM ISV.KUNDE

WHERE KUNDENNUMMER = '47582'");

Im ODBC Initialization File

MVSDEFAULTSSID=V10A LITERALREPLACEMENT=1

AUTOCOMMIT=0 ...

oder mit JCC-Property

statementConcentrator ( )

Beim PREPARE als Attribut: – CONCENTRATE STATEMENTS WITH

LITERALS

7 Oktober 2012


Timeout-Risiko bei Lesezugriffen auf aktuelle Daten

SELECT ... FROM ISV.KUNDE ...



INSERT INTO ISV.KUNDE ...

INSERT INTO ISV.KUNDE ...

DELETE FROM ISV.KUNDE ...

DELETE FROM ISV.KUNDE ...

Anwendung A

Anwendung B

8 Oktober 2012


Bisher keine zufriedenstellende Lösung vorhanden

• Bisherige Alternativen:

– Isolation Level Uncommitted Read

X Unter Umständen Verarbeitung von inkonsistenten Daten

– Isolation Level Cursor Stability oder höher

X SQLCODE -913/-911 … CAUSED BY DEADLOCK OR TIMEOUT


– „Currently Committed“ liefert für die Isolation Level CS oder RS

den Datenstand vom letzten Commit-Zeitpunkt

– Kein Warten auf die Freigabe inkompatibler Locks von

INSERT/DELETE Operationen (nicht für UPDATE)

9 Oktober 2012


DB2-interne Ablage für kleine LOBs unvorteilhaft

• Bisheriges Ablageverfahren:

X LOB-Daten werden unabhängig von ihrer Größe in einer Auxiliary Table im LOB Table Space abgelegt


– Mit Inline LOB Columns verbleibt ein vorgegebener Teil der LOB-Daten direkt im Base Table Space (muss im Reordered Row Format sein)

– Dadurch lassen sich Performance-Vorteile realisieren sowie Plattenplatz einsparen

– Inline LOBs erlauben die Definition von Default-Werten sowie von Indexes (on Expression)

10 Oktober 2012


Definition und Funktionsweise von Inline LOBs

• „Inline Length" zwischen 0 und 32680 Bytes

– LOB < Inline Length: Gesamtes LOB im Base Table Space

– LOB > Inline Length: Über Inline-Teil hinausgehend wird ausgelagert

• zPARM LOB_INLINE_LENGTH legt subsystemweit den Defaultwert fest (0

bedeutet per Default kein Inline-Teil)

• Table geht in REORG Pending Status bei Verkleinerung

CREATE TABLE ISV.VERTRAG

(VERTRAGSNR INTEGER NOT NULL,

VERTRAG CLOB(500K) INLINE LENGTH 1000);

ALTER TABLE ISV.VERTRAG ALTER COLUMN

VERTRAG SET INLINE LENGTH 1500);

11 Oktober 2012


Vorteile von Inline LOBs

Inline LOBs bieten einige Performance Vorteile gegenüber LOBs, die in “auxiliary

tables” gespeichert werden – sogen. “outline LOBs” :

Plattenplatzeinsparungen – 2 LOBs können sich nicht eine einzelne Page auf

einem LOB TS teilen

Plattenplatzeinsparungen – der “inline” Teil eines LOB kann komprimiert werden

Synchrone I/Os gegen den AUX Index und den LOB TS werden vermieden

“ CPU savings” im Zusammenhang mit dem Zugriff auf den AUX Index und den

LOB TS

“Sequential” und “dynamic prefetch” I/O für LOBs

Verbesserte Effizienz der Funktion FETCH CONTINUE beim “scan” von “rows”

“Index on expression” ist für LOB Daten möglich

12 Oktober 2012


Vorteile von Inline LOBs (beim UPDATE / DELETE)

“Class 2 elapsed time” bei 5,000 “random updates/deletes” mit 200 Byte LOBs

13 Oktober 2012


Komplexität durch generierte LOB und XML Objekte

DB2 10 for z/OS bietet zusätzliche Performance Verbesserungen indem es die Unterstützung für

“LOB und XML streaming” erweitert und so die Materialisierung für LOB und XML in einigen

Situationen vermeidet.

Das Bild auf der nächsten Seite zeigt die Unterschiede zwischen DB2 9 und DB2 10. Der DDF Server

braucht auf das entsprechende LOB / XML Objekt nicht mehr länger zu warten, bevor es an den “data

manager“ übergeben werden kann.

• Bisherige Ausgangslage:

X Vor allem Kaufsoftware erstellt oft eine Vielzahl an DB2 Objekten (Tabellen,

Indexes…), von denen später nur wenige tatsächlich genutzt werden oder die nicht den

internen (firmeneigenen) Richtlinien entsprechen


– DEFINE NO greift nun auch für LOB und XML Objekte (Table Spaces und Indexes)

und verzögert die Erstellung der entsprechenden VSAM Data Sets

– Der Verzicht auf die direkte, physische Allokation mindert auch die Auswirkungen auf

den Speicherbedarf und bestehende Backup-/Recovery-Prozesse

14 Oktober 2012


Komplexität durch generierte LOB und XML Objekte

DB2 materialisiert bis zu 2 MB für LOBs und 32 KB für XML bevor es die Daten an den “database

manager” übergibt. Der Speicher, der für diese LOB / XML Werte benötigt wird wird für folgende

“chunks” wieder verwendet, bis das entsprechende LOB / XML verarbeitet ist.

Streaming LOBs und XML

15 Oktober 2012


RID List “work file overflow”

DB2 10 liefert neue Techniken zur Verwaltung des RID Pool und seiner bisherigen Limits. DB2 10

erlaubt einem “access plan” auf eine “work file” zu überzulaufen und die RIDs weiterzubearbeiten,

auch wenn einer der RID “thresholds” zur Laufzeit erreicht werden sollte.

Wird der RID Pool zur Laufzeit voll, so erfolgt ein Überlauf der RIDs auf die “work file” und die Verarbeitung wird mit

32 KB großen Sätzen weitergeführt. Dabei hält jeder Satz die RIDs aus einem 32 KB RID Block. Dies erfordert nur

selten, dass der RID Zugriff auf einen TS Scan zurückgeführt werden muss (wie beispielsweise bei DB2 9). In einigen

Fällen kann man sehen, dass die “work file” Nutzung sich erhöht. Großer Speicher mit einem großen “work file”-

Bufferpool verhindert I/Os für die RID Blöcke. Sogar, wenn man nicht genügend Speicher hat, um I/Os auf den “work

files” zu vermeiden, so ist ein “work file” I/O bei

weitem besser als ein Paging I/O auf einem

überdimensioniertem RID Pool.

DB2 9 und DB2 10 garantieren einen“request”

für 6524 RIDs oder weniger (EIN RID Block).

In früheren Versionen erfolgte, wenn der RID

Pool voll war und eine kleine Query auch nur

einen einzigen RID Pool Block anforderte, ein

Fehler auf dem RID Pool “requests” und die

Query kehrte zum “tablespace scan” zurück.

RID Pool Overflow Performance Zahlen

16 Oktober 2012


„Referential integrity checking“ Verbesserung

Beim INSERT in eine abhängige Tabelle muss DB2 den “parent key” wegen der Prüfung des RI

“constraint” zugreifen. DB2 10 Änderungen helfen den CPU “overhead” für RI Prüfungen zu

minimieren indem “index probes” für ”parent keys” minimiert werden:

• DB2 10 erlaubt “sequential detection”, um einen “dynamic prefetch” zur “parent key” RI Prüfung anzustossen

• DB2 10 schaltet auch “index look-aside” zur “parent key” RI Prüfung ein. “Index look-aside” heißt, dass DB2 die

“key range” Werte in den Cache schreibt. DB2 verfolgt die IX Wertebereiche und prüft, ob der erforderliche Eintrain

den “leaf pages” des vorangegangenen Calls zu finden ist. Wird der Eintrag gefunden, so kann DB2 das “getpage”

und eine Suche auf dem IX-“tree” vermeiden. Wird der Eintrag nicht gefunden, so prüft DB2 den “parent non-leaf

page’s” niedrigsten und höchsten Schlüssel. Wird der Eintrag in der “parent non-leaf range” gefunden, so muss DB2

einen “getpage” durchführen, kann aber dafür eine vollle Suche in IX – Baum vermeiden.

• DB2 kann den “IX lookup” ebenfalls vermeiden, falls der zu prüfende “non-unique key” vorher schon geprüft wurde.

INSERT KEY A, INSERT KEY A, .... INSERT KEY A, COMMIT;

Ist der 1st INSERT KEY A, prüft DB2 den “parent table” IX auf RI. Keine RI Prüfung erfolgt für nachfolgende

INSERTs.

INSERT KEY A, COMMIT; INSERT KEY A, COMMIT;

• DB2 prüft beim INSERT mit oder ohne commit, ob der “key” bereits in der “child table” existiert. DB2 prüft nicht

den “parent key” Wert noch einmal.

Aber: Es muss ein IX auf der “child table” existieren, mit einem Bezug auf die “primary key

column(s)” als führende Spalten im IX. Sonst wird man zwar von der “index look-aside” Technik auf der

“parent table” profitieren, aber nicht wegen des Schlüssels, der bereits existiert.

17 Oktober 2012


Precompiler NEWFUN Option

Die Option NEWFUN im Precompiler zeigt an, ob der DB2 Precompiler SQL, das NFM im

aktuellen Release nutzt, akzeptiert. Traditionale “settings” sind YES / NO: NEWFUN(YES) bedeutet,

es werden SQLs, die NFM erforderlich machen, während NEWFUN(NO) dies nicht tut. Wird die

NEWFUN Option nicht explizit angegeben, so verwendetbder Precompiler das “setting” des

Parameters NEWFUN aus dem DSNHDECP Modul.

In DSNHDECP sind ebenfalls YES / NO gültig und der “default” ist YES.

Im Sinne der “skip-release” Migration auf DB2 10 sind die SQL Verarbeitungsoptionen

NEWFUN(YES) und NEWFUN(NO) abgeschafft. DB2 10 führt die versionsspezifischen (absoluten)

“settings” Vnn (d. h. NEWFUN(V10), NEWFUN(V9), NEWFUN(V8)) für die NEWFUN

Precompiler Option wieder ein.

In DB2 10 werden die absoluten “settings” bevorzugt; aber: NO und YES werden immer noch

akzeptiert. In DB2 10 bedeutet NEWFUN(NO) dasselbe wie NEWFUN(V9), was bedeutet, dass der

Precompiler alle SQLs akzeptiert , die in DB2 9 NFM gültig sind, aber nicht SQLs, die DB2 10 NFM

benötigen.

NEWFUN(YES) bedeutet dasselbe, wie NEWFUN(V10).

18 Oktober 2012


Erweiterter Support für SQL/PL

DB2 9 for z/OS führte SQL Prozeduren ein. DB2 10 for z/OS verbessert diese im “new-function

mode” mit folgenden Funktionen:

• Die Fähigkeit, einen Parameter oder eine SQL Variable als “distinct type” zu definieren(gleiche

Möglichkeit gibt es auch für SQL Funktionen)

• CREATE und ALTER Statements für SQL Prozeduren können in ein Applikationsprogramm

“embedded” werden

Es gibt generelle Performance Verbesserungen für SQL/PL, die bis zu 20% CPU Zeit im Vergleich zu

DB2 9 sparen können. DB2 10 for z/OS verbessert das SQL Control Assignment Statement durch die

Möglichkeit mehrfacher Zuweisungen .

19 Oktober 2012


DB2 10 for z/OS –

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

Documents

IBM DB2 for z/OS