DB2 for z/OS V10 - Anwendungsoptimierung

(*)
IBM DB2 for z/OS
DB2 Version 10 – Kapitel „Anwendungsoptimierung“
(05_DB2V10_anwendungsoptimierung.pptx)
(*) ist eingetragenes Warenzeichen der IBM International Business Machines Inc.
Oktober 2012
1
DB2 Version 10 - Migration
DB2 10 for z/OS –
Im Einsatz, wo andere längst aufgeben...
Oktober 2012
2
DB2 Version 10 – AP Optimierung
Inhalte:
(5) Anwendungsoptimierung
•
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
Oktober 2012
DBA, Anwendungsentwickler
3
DB2 Version 10 - AP Optimierung
Statements mit Literalen überfüllen den DB2 Cache
Kunde
kundennummer
+
SELECT
+
KUNDENNUMMER
------
FROM ISV.KUNDE WHERE
vorname
------
+
=
+
'Stuttgart'
+
NACHNAME
+
=
+
+
ORT
+
AND
'Maier'
nachname
Maier
Stmt I
ort
Stuttgart
Oktober 2012
Stmt A
4
DB2 Version 10 - AP Optimierung
Änderungsmöglichkeit ist oft nicht gegeben
•
Bisherige Ausgangslage:
X
X
Schlechte Coding Praxis oder Notwendigkeit für hochdynamisches SQL mit
String Concatenation
Nutzung externer Frameworks oder Anwendungen
SELECT ORT FROM ISV.KUNDE WHERE KUNDENNUMMER = 2337168
...
•
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 = &
Oktober 2012
5
DB2 Version 10 - AP Optimierung
Aktivieren von „Literal Replacement“ in Anwendungen
Auf Connection-Ebene in Java
mit JCC-Property
( oder
)
statementConcentrator
((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
...
Beim PREPARE als Attribut:
Oktober 2012
–
CONCENTRATE STATEMENTS WITH
LITERALS
6
DB2 Version 10 - AP Optimierung
Timeout-Risiko bei Lesezugriffen auf aktuelle Daten
Anwendung A
SELECT ... FROM ISV.KUNDE ...
SELECT ... FROM ISV.KUNDE ...
SELECT ... FROM ISV.KUNDE ...
INSERT INTO ISV.KUNDE ...
INSERT INTO ISV.KUNDE ...
DELETE FROM ISV.KUNDE ...
DELETE FROM ISV.KUNDE ...
Anwendung B
Oktober 2012
7
DB2 Version 10 - AP Optimierung
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
•
Lösung mit DB2 10:
– „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)
Oktober 2012
8
DB2 Version 10 - AP Optimierung
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
Lösung mit DB2 10:
–
–
–
Oktober 2012
Mit Inline LOB Columns verbleibt ein vorgegebener Teil der LOBDaten 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)
9
DB2 Version 10 - AP Optimierung
Definition und Funktionsweise von Inline LOBs
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);
•
„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
Oktober 2012
10
DB2 Version 10 - AP Optimierung
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
Oktober 2012
11
DB2 Version 10 - AP Optimierung
Vorteile von Inline LOBs (beim UPDATE / DELETE)
“Class 2 elapsed time” bei 5,000 “random updates/deletes” mit 200 Byte LOBs
Oktober 2012
12
DB2 Version 10 - AP Optimierung
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
•
Lösung mit DB2 10:
–
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
Oktober 2012
13
DB2 Version 10 - AP Optimierung
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
Oktober 2012
14
DB2 Version 10 - AP Optimierung
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
Oktober 2012
15
DB2 Version 10 - AP Optimierung
„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.
Oktober 2012
16
DB2 Version 10 - AP Optimierung
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).
Oktober 2012
17
DB2 Version 10 - AP Optimierung
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 .
Oktober 2012
18
DB2 Version 10 - AP Optimierung
DB2 10 for z/OS –
Im Einsatz, wo andere längst aufgeben...
Oktober 2012
19