IBM DB2 V9 - S.K. Consulting€¦ · Fähigkeit von DB2 LUW. Ein “feature” hierfür ist das Database Partitioning Feature (DPF). „Table partitioning“ “table partitioning”

Aug2012 1

DB2 – „application development“ (Teil II)

IBM DB2 V9 for LUW

(*)

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

Aug2012 2

DB2 for LUW DB2 for LUW –– ApplikationsentwicklungApplikationsentwicklung

Kapitelinhalt

• DB2 und verteilte Umgebungen/Objekte

• PL/SQL und DB2 Sprachstruktur und Einsatz

Beispiele

• Cursor-Verarbeitung Types of cursors,

Scope of cursors

Create and manipulate cursors

Fehlerbehandlung und SQLCA

• Lockingmechanismen und „lock avoidance“ ISOLATION Levels

Sperrmechanismen

Sperrkompatibilität

• Unit of Work, Unit of Recovery COMMIT, ROLLBACK

SAVEPOINTs

Aug2012 3


Kapitelinhalt

• Erläuterung der EXPLAIN Funktion Einführung in die DB2 Optimizer Arbeitsweise

Zugriffspläne lesen, verstehen und zur SQL-Optimierung analysieren

Explain durchführen

SQL Analyse-Tools von IBM (Visual EXPLAIN, db2advis etc.)

Analyse Tools von Drittanbietern

• DB2 Utilities und Statistiken

• DB2 Optimizer Richtlinien

• Monitoring und Fehleranalyse

Aug2012 4


Kapitelinhalt



Beispiele


Scope of cursors




Sperrmechanismen



SAVEPOINTs

Aug2012 5

Möglichkeiten der Verteilung von Objekten bei DB2 LUW

DB2 for LUW DB2 for LUW –– verteilte Umgebungen / Objekteverteilte Umgebungen / Objekte

„Q replication“

“Q replication” ist eine Replikationslösung, die WebSphere MQ Message Queues nutzt, um Transaktionen

zwischen “source” und “target databases” zu übertragen. “Q replication” wird in 3 Formen wirksam:

• Unidirectional

• Bidirectional

• „peer-to-peer“

„DB2 Database Partitioning Feature“

DB2 LUW ist in höchstem skalierbar und in der Lage, Hardware Plattformen vom “1-Prozessor Laptop”,

“single” und “clustered Symmetric Multiprocessing (SMP) “ Server bis hin zu parallelen systemen mit

hunderten von Knoten und mehreren Prozessoren pro Knoten zu unterstützen. Diese extrem

anpassungsfähige Funktionalität und die Granularität beim gesteuerten Wachstum ist eine herausragende

Fähigkeit von DB2 LUW. Ein “feature” hierfür ist das Database Partitioning Feature (DPF).

„Table partitioning“

“table partitioning” wurde erst in DB2 9 eingeführt. Es erlaubt den “database administrators” (DBAs)

Tabellen in Partitions aufzuteilen und diese in separaten oder mehreren Tablespaces zu speichern. Nebenbei

liefert dieses “feature” eine einfachere Verwaltung, verbesserte Performance und ebenfalls zusätzliche

Skalierbarkeit in der DB2 Umgebung bei großen DBs.

Aug2012 6

Möglichkeiten der Verteilung bei DB2 LUW

„Q replication“

“Q replication” ist eine Replikationslösung mit WebSphere MQ “messages queues” , um so Transaktionen

zwischen Quell- und Ziel-Datenbanken zu übertragen.

“Q replication” gibt es in drei Ausprägungen:

Unidirectional

Bei einer “unidirectional Q replication”, werden Änderungen am “Quell-Knoten” aufgezeichnet und zum

Zielknoten repliziert. “unidirectional Q replication” kann von einer “source” auf ein oder mehrere “targets”

erfolgen. Bei “unidirectional Q replication”, wird das “target” typischerweise “read-only” genutzt.

Bidirectional

Bei einer “bidirectional Q replication”, replizieren sich zwei Tabellen auf zwei Servern gegenseitig.

Änderungen auf einer der Tabellen werden auf die entsprechende korrespondiesende Tabelle repliziert. Man

kann nicht “subset of rolls” replizieren und jede Tabelle muss dieselbe Anzahl Spalten und dieselben Daten-

typen für diese Spalten aufweisen - Schemas und Tabellennamen können jedoch unterschiedlich sein.

Peer-to-peer

Bei einer “peer-to-peer Q replication” werden Tabellen über zwei oder mehr Server hinweg repliziert.

Wie bei der “bidirectional Q replication” müssen die replizierten Tabellen dieselbe Struktur aufweisen -

Schemas und Tabellennamen können jedoch unterschiedlich sein.

“Q replication” kann es in unterschiedlichsten Konfigurationen geben: Replikation zwischen DBs auf

demselben Server oder “remote servers”, als “one-to-many relationship” oder “many-to-one relationship”.


Aug2012 7


„Q replication“ - Beispiel

„Unidirectional setup“

Hier ein schrittweise dargestelltes Beispiel eines “unidirectional Q replication setup” mit zwei “remote

servers”.


Folgende Schritte sind für eine

“unidirection Q replication”

Umgebung erforderlich:

1. Setup of the database on both the

source and target database servers.

2. Setup of WebSphere MQ objects on

the source server and the target server.

3. Start the listener and the channel on

the source and the target

4. Optional: Test the queues.

5. Create the Q Capture Control tables.

6. Create the Q Apply Control tables.

7. Create a Q subscription.

8. Configure target to source server

connectivity.

9. Start Q Capture.

10. Start Q Apply.

Aug2012 8


Übersicht über DPF

Ein Hardware Trend, den man beobachten kann, ist es, “enterprise” Systeme aufzubauen, indem man eine

Gruppe kostengünstiger kleiner Server zu Verfügung stellt. Die Kunden möchten profitieren, da die Daten-

volumina wachsen und es für sie sehr schwierig ist, abzuschätzen, wie groß ihre Datenbank in einigen

Jahren sein wird. DieDatenbankarchitektur muss flexibel genug sein, auch Vorteile aus dem Hinzufügen

von “processing power” eines weiteren Serverknotens zum existenten “cluster”, zu ziehen.

Das „Database Partitioning Feature“ (DPF) – verfügbar in der DB2 for LUW Enterprise Server Edition

(ESE) erweitert die Funktionalität des relationalen “ data-

base managers” für den Einsatz in einer parallelen,

“multi-node” Umgebung. Mit DPF wird die DB skalierbar,

indem man neue Server hinzudefinieren und die Daten-

banken über diese hinweg verteilen kann; d.h. mehr CPUs,

mehr Speicher und mehr “disks” von jedem zusätzlichen

Server für die Datenbank. DB2 ESE mit DPF ist ideal für

DWHs, “data mining” und Last, die vom “online analytical

processing” (OLAP) kommt. Es kann aber auch in einem

“online transaction processing” (OLTP) Umfeld gut

funktionieren.

Hier im Bild: DB2 partitioniert” auf “networked

machines”. Eine Applikation kann sich an jede “database

partition“ anmelden.


Aug2012 9



Ist eine “database” partitioniert, so wird die DB in mehrere unabhängige Teile aufgeteilt – jeder Bestandteil

hat seine eigenen Daten in “table space containers”, eigene “configuration files”, Indexe und

“transaction logs”. Auf einen physischen Server können mehrere Partitions zugewiesen sein, die sich dann

die Ressourcen dieses Servers teilen. Eine “database partition” wird auch manchmal als “Knoten”(“node”)

bezeichnet – ähnlich, wie ein Server in einem “cluster” auch “node” genannt wird. So brauchen “non-

replicated partitioned databases” alle “nodes” verfügbar, um aktiv werden zu können. Das folgende Bild zeigt

DB2 “partitioning” auf SMP Maschinen.

DB2 implementiert DPF über eine “shared nothing” Architektur. Der Vorteil dieser Architektur ist, dass

man keine spezielle Hardware braucht

und jeder Server lediglich einen Teil

der Arbeit zu leisten hat. Als Ergebnis

gewinnt man Performance aus den

“not sharing resources” des Netzes.

Die “Shared Nothing Architecture”

eliminiert den “overhead” des “distri-

buted lock Management”.

Die DB-Größe ist skalierbar über die

Plattenanzahl und die Anzahl der

Prozessoren.


Aug2012 10



Die DPFArchitektur ist höchst skalierbar und benötigt minimale Kommunikation zwischen den Knoten. Die

DPF “shared nothing” Architektur setzt DB2 in die Lage beste Skalierbarkeit und /oder Kosten/Performance

anzubieten – oder beides zusammen.

Eine “single-partition database” ist per definitione

eine DB, die nur aus EINER “database partition”

besteht. Alle Daten der DB werden in dieser Partition

abgelegt.

Eine “multi-partitioned database” ist eine DB, die

nur aus ZWEI oder MEHR “database partitions”

besteht. Da die Daten über die “database partitions”

verteilt sind, kann man die Leistung von “multiple

processors” auf mehreren “physical “nodes” nutzen,

um die Informationsanforderungen zu erfüllen.

DB2 unterstützt zudem ein “partitioned Storage”

Modell, bei dem der #1 IX (partitioning key) genutzt

wird , eine Tabelle über ein “set of database parti-

tions” zu verteilen; d,h, die Daten werden physisch

auf mehr als einer “database partition” gespeichert

und können dennoch so zugegriffen werden, als

befänden sie sich am gleichen Platz (in einer Tabelle?).


Aug2012 11


Übersicht „Table Partitioning“

Das “Table partitioning feature” ist ein Tabellenorganisationsschema in dem die Tabellendaten in Partitions

gemäß den Werten in einer oder mehreren “table partition key columns” der Tabelle aufgeteilt werden. Jede

Partition kann separat auf einem “storage” Objekt – “data partition” oder “range” genannt – abgespeichert

werden.

Diese “storage objects” können sich

• Auf unterschiedlichen TS

• In einem einzelnen TS oder

• Einer Kombination aus beidem

befinden.

Die Entscheidung, wo diese “storage objects” platziert sein sollen, fällt zu Zeitpunkt CREATE/ALTER

TABLE über die Klausel PARTITION BY .

DB2 9 unterstützt “data partitions” / “data ranges” auf der Basis verschiedener Attribute. Eine Möglichkeit

wäre die Partitionierung nach Datumsdaten. Hier kann man Daten nach Jahr / Monat / ??? in Partitions

gruppieren. Man kann auch numerische Attribute, z.B ID’s etc. , partitionieren. Ein Beispiel wäre auch,

Mandanten, z.B. Bankfilialen , nach Partitions zu trennen.

Obwohl man Partitionen über Namen und/oder Nummern referenzieren kann, können sie für Applikationenj

vollständig transparent sein: Sie können über die Angabe von Spalten- und Tabellenname ihre Daten

erreichen. – Sie müssen nicht wissen, in welcher Partition die Daten gespeichert sind.


Aug2012 12



“partitioned tables” können mehr Daten enthalten als eine einfache Tabelle. Sie können aus bis zu 32767

“data partitions” bestehen.

“Data partitions” können hinzugefügt, angehängt bzw. abgehängt werden .

Mit ALTER TABLE ... ATTACH / DETACH können „roll in“/“roll-out“ Arbeiten einfach erledigt werden.

Der Einsatz von Partitions kann auch zur Verbesserung von Query- Performance beitragen. So werden

nur relevante Daten durchsucht, die sich evtl. In EINER Partition befinden.

Die SQL “engine” kann während des “data read” Partitionen ausblenden, wenn sie keine Daten enthalten,

die zum Resultat einer Query beitragen können.

Die Spalten, die in der Klausel PARTITION BY die Partitionierung bestimmen heissen “table partitioning

key columns”. Man kann die Klauseln DISTRIBUTE BY und PARTITION BY kombinieren und die

Datenpartitionen so über mehrere “table spaces” verteilen.

Die Db2 Organisationsschemas umfassen

• DISTRIBUTE BY HASH

• PARTITION BY RANGE

• ORGANIZE BY DIMENSIONS

• “Partitioned hierarchical”, “temporary tables”, “range-clustered tables” und “partitioned views” sind

derzeit nicht unterstützt. Ebenso, wie die Datentypen Long Varchar, Long Vargraphic, BLOB,

CLOB DBCLOB, XML und DATALINK nicht zur Partitionierung zugelassen sind.


Aug2012 13



Vorteile von „table partitioning"

Schnelles “roll-in” und “roll-out” , einfachere Administration großer Tabellen, flexible IX Platzierung

und erhöhte Query Performance können Vorteile von “table partitioning” sein. Und:

• Bei großen DWHs in denen man häufig daten hinzufügt oder löscht – auf der Basis von bekannten

Kriterien ; z.B.: Datumsdaten. In solchen Situationen kann ein System vom einfacheren “roll-in” /

“roll-out” der Tabellendaten profitieren.

• Große DWH mit großen Tabellen und

Query-Kriterien, die einen Split der

Daten über mehrere “devices” zulassen.

• Man braucht eine “Hierarchical

Storage Management” (HSM) Lösung,

die besonders effektiv sein soll.

• Man will Indexe auf unterschiedliche

“devices” legen, abhängig von der

Geschwindigkeit der Platte und der

Nutzungsfrequenz der jeweiligen

Indexe.

Index distribution on a partitioned table


Aug2012 14



Hier ein Index auf einer “partitioned table”, der

zusätzlich noch über mehrere “database partitions“

verteilt ist.

CREATE TABLE lineitem (

l_orderkey DECIMAL(10,0) NOT NULL,

l_quantity DECIMAL(12,2),

l_shipdate DATE,

l_year_month INT GENERATED ALWAYS AS

(YEAR(l_shipdate)*100 +

MONTH(l_shipdate)))

PARTITION BY RANGE (l_shipdate)

(STARTING ('1/1/1992')

ENDING ('12/31/1992')

EVERY 1 MONTH);


Aug2012 15

Funktionen der DBs und DRDA Protokolle (“Distributed Relational Database Architecture „):

Die Konversation beim DRDA Protokoll:


15

Aug2012 16

“High Availability Options” bei DB2 LUW

DB2 bietet verschiedene Möglichkeiten, die hohe Verfügbarkeit von DB Servern sicherzustellen. Im großen

und ganzen sind das:

• High Availability and Disaster Recovery (HADR)

• Automatic Client Reroute (ACR)

• SQL replication

• Q replication

Einige DB2 Funktionen erhöhen ebenfalls die Verfügbarkeit von Operationen, Applikationen, Daten,

Transaktionen etc. wie z.B: “online backup” und die sogen. “in-place reorganization”.

Zusätzlich dazu gibt es eine Reihe von Software und Hardware Angeboten seitens der IBM und anderer

Provider, die helfen, die Verfügbarkeit einer DB2 Umgebung höchstmöglich zu halten.

Hardware-basierte Lösungen

• RAID

• “Remote storage mirroring“

• „clustering“ Lösungen

• Replikationslösungen (SQL, Q Replication …)

• Hybrid Nutzung von “shared disk cluster” und HADR

HADR – High Availability Disaster Recovery


16

Aug2012 17


Kapitelinhalt



Beispiele


Scope of cursors




Sperrmechanismen


Aug2012 18

DB2 und PL/SQL

PL/SQL (Procedural Language/Structured Query Language) Statements können kompiliert und über

jegliche DB2® Interfaces ausgeführt werden.

Dies reduziert die Komplexität beim Anpassen von bestehenden PL/SQL Lösunegn(Oracle), um sie so am

DB2 Data Server zum Laufen zu bringen (98% Deckungsgrad).

Die unterstützten Schnittstellen umfassen:

• DB2 “command line processor “(CLP)

• DB2 CLPPlus

• IBM® Data Studio

PL/SQL Statements können allerdings nicht per “default” von diesen Schnittstellen bedient werden. Es

muss der “PL/SQL statement execution support” auf dem DB2 Server eingeschaltet sein.

PL/SQL features

PL/SQL Statements und Skripte können unter DB2 kompiliert und zur Ausführung gebracht werden:

Anonyme Blöcke; zum Beispiel DECLARE…BEGIN…END

CREATE OR REPLACE FUNCTION Statement

CREATE OR REPLACE PACKAGE / PACKAGE BODY Statement

CREATE OR REPLACE PROCEDURE Statement

CREATE OR REPLACE TRIGGER Statement

DROP PACKAGE / PACKAGE BODY Statement

PL/SQL Prozeduren und “functions” können von PL/SQL Statements oder von DB2 SQL PL Statements aus

gestartet werden - via CALL Statement

DB2 for LUW DB2 for LUW –– DB2DB2--Routinen und PL/SQLRoutinen und PL/SQL

http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.apdv.plsql.doc/doc/c0053610.html

Aug2012 19

DB2 und PL/SQL

Creating PL/SQL procedures and functions from a CLP script

PL/SQL Prozeduren und “functions” können aus einem DB2 command line processor (CLP) Skript aus

erzeugt werden.

Vorgehensweise (1) Formulieren einer PL/SQL “procedure” / “function” Definition innerhalb einer CLP Skript - Datei.

Terminieren jedes Statements mit “new line” und einem “forward slash” Zeichen (/). Andere Statement Terminationszeichen

werden ebenfalls unterstützt.

(2) Speichern der “file” – hier “script.db2”.

(3) Ausführen des Skripts aus CLP. Wurde ein “forward slash” – Zeichen oder ein “Semikolon” als Terminator für die

Statements eingesetzt, setzt man folgendes Kommando ab:

db2 -td/ -vf script.db2

Wurde ein anderes Zeichen als Terminator für die Statements eingesetzt – beispielsweise @ - so muss man über das Kommando

dieses Zeichen bekanntgeben:

db2 -td@ -vf script.db2

Restriktionen beim PL/SQL support

Es sit wichtig die Restriktionen der Kompilierung von PL/SQL zu kennen bevor man dazu übergeht, PL/SQL

Kompilationsergebnisse auf Fehler zu untersuchen oder “runtime” Probleme zu analysieren:

• PL/SQL Funktionen und Triggers können nicht auf “partitioned database” Umgebungen erstellt werden.

• Der Datentyp NCLOB wird in PL/SQL Statements orde in PL/SQL Kontexts nicht unterstützt, wenn die DB nicht als “Unicode

database” definiert ist. In “Unicode databases” wird NCLOB auf DB2® DBCLOB Datentypen “gemapped”

• Der Datentyp XMLTYPE ist nicht unterstützt.

• TYPE Deklarationen sind nicht erlaubt in Funktionen, TSP’s , Triggers oder in “anonymous blocks”.


http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.apdv.plsql.doc/doc/t0053609.html






Aug2012 20

DB2 und PL/SQL

Transparenz(Obfuscation)

“Obfuscation” kodiert dne “body” eines DDL Statements bei DB-Objekten wie Routinen, Triggers, Views,

und PL/SQL Packages. Dies soll helfen, den Code als geistiges Eigentum zu schützen, da kein User den

Code lesen kann, DB2 Database for Linux, UNIX und Windows kann damit aber arbeiten.

“Blocks “(PL/SQL)

PL/SQL Block Strukturen können in PL/SQL Prozeduren, Funktionen bzw. Trigger Definition enthalten sein

bzw. als “anonymous block” Statement ausgeführt werden.

Prozeduren (PL/SQL)

Der DB2 Server unterstützt die Kompilierung und Ausführung von PL/SQL Prozeduren. PL/SQL

“procedures” siege DB2 STP’s.

“Functions” (PL/SQL)

Der DB2 Server unterstützt die Kompilierung und Ausführung von PL/SQL Funktionen. PL/SQL

“functions” siehe DB2 “functions”.

“Collections” (PL/SQL)

Die Verwendung von PL/SQL “collections” wird ebenfalls vom DB2 Server unterstützt. Eine PL/SQL

“collection” ist eine Menge geordneter datenelemente mit demselben Datentyp. Individuelle Datenelemente

in diesem “set” können über “subscript notation” in Klammern angesprochen werden.

“Variables” (PL/SQL)

Variable müssen deklariert werden bevor sie verwendet werden können.











Aug2012 21

DB2 und PL/SQL

PL/SQL support

“Basic statements” (PL/SQL)

Die Statements in Programmen einer PL/SQL Applikation include: assignment, DELETE, EXECUTE

IMMEDIATE, INSERT, NULL, SELECT INTO, and UPDATE.

“Control statements” (PL/SQL)

“Control statements” sind die Programm-Statements, die PL/SQL zu einem vollwertigen prozeduralen

Ersatz für SQL machen können.

“Cursors” (PL/SQL)

Ein cursor ist einen “control structure” mit Namen, die von einem Anwendungsprogramm genutzt werden

kann, auf Daten-”rows” in einer Resultatsmenge zu verweisen und diese zu lesen. Anstatt eine Query immer

wieder auszuführen, kann man Ccursor nutzen, um das Query-Resultat satzweise zu bearbeiten.

Triggers (PL/SQL)

Trigger – siehe DB2 Trigger

Packages (PL/SQL)

PL/SQL Package Definitionen werden von DB2 ebenfalls unterstützt. Ein PL/SQL Package ist eine

“collection” von “functions”, “procedures”, “variables”, “cursors”, “user-defined types” und Sätzen, die

über einen gemeinsamen “qualifier” genutzt werden können – dem “package”-Namen







Aug2012 22

DB2 und PL/SQL

PL/SQL “features”

Die folgenden PL/SQL Statements können in DB2 zur Ausführung kommen:

• “Anonymous blocks”; z.B. DECLARE…BEGIN…END

• CREATE OR REPLACE FUNCTION

• CREATE OR REPLACE PACKAGE

• CREATE OR REPLACE PACKAGE BODY

• CREATE OR REPLACE PROCEDURE

• CREATE OR REPLACE TRIGGER

• DROP PACKAGE

• DROP PACKAGE BODY

PL/SQL STP’s und Funktionen können aus anderen PL/SQL Statements oder aus DB2 SQL PL Statements aufgerufen

werden. Man kann auch eine PL/SQL “procedure” aus SQL PL über ein CALL Statement aufrufen.

Die folgenden Basis – Programmelement können in PL/SQL und SQL PL verwendet werden:

• Associative arrays

• Record types

• VARRAY types

Variable Deklarationen:

• %ROWTYPE

• %TYPE

“Basic statements”, Klauseln und Statement Attribute:

“Assignment” Statement

NULL Statement

RETURNING INTO Klausel

Statement Attribute inkl. SQL%FOUND, SQL%NOTFOUND, und SQL%ROWCOUNT


Aug2012 23

DB2 und PL/SQL

“Control statements” und Strukturen

• CASE

• “Exception handling”

• EXIT

• FOR

• GOTO

• IF

• LOOP

• WHILE

“Static cursors”:

• CLOSE

• Cursor FOR loop Statement

• FETCH (inkl. FETCH INTO eine %ROWTYPE Variable)

• OPEN

• “Parameterized cursors”

• “Cursor” Attribute

REF CURSOR Unterstützung:

• Variable und Parameters des Typs REF CURSOR

• REF CURSORs

• OPEN FOR

• Zurückgeben von REF CURSORs an JDBC Applikationen

“Error handling support”:

• RAISE_APPLICATION_ERROR Prozedur

• RAISE statement

• SQLCODE Funktion

• SQLERRM Funktion


Aug2012 24


Kapitelinhalt



Beispiele


Scope of cursors




Sperrmechanismen



SAVEPOINTs

Aug2012 25

DB2 Anwendungsentwurf

DB2 for LUW DB2 for LUW –– CursorCursor

SQL ???? ... Alles eine Frage der Formulierung und Mengendefinition ...

… to the airport

please…

Aug2012 26

DB2 Anwendungsentwurf - Cursortypen


Non-Cursorbefehle

• SELECT .... (nur eine Zeile, sonst –811)

• INSERT

• UPDATE

• DELETE

• MERGE

Diese Befehle unterliegen keinen Einschränkungen

im Vergleich zum interaktiven Betrieb ...

Aug2012 27



Cursor

Das Problem ist: DB2 kann als relationales DBMS Mengenverarbeitung -, die meisten

Programmiersprachen und Entwicklungssysteme können das aber nicht (“1-row-at-a-time”)

select name, vorname, geb_dat

from mitarbeiter_tab m

where gehalt > 2600

Ergebnis ???? – wieviele “rows”

Ein Cursor wird in einem AP benötigt, um einzelne “rows” aus einem “result set” zu lesen und/oder zu

verarbeiten. Um einen Cursor nutzen zu können, muss man folgendes tun:

• DECLARE des Cursors. Das Statement DECLARE CURSOR enthält den SQL Text den der Cursor ausführen soll. Ist

der Cursor mit "with hold“ erklärt, so bleibt er über einen COMMIT-Punkt hinweg geöffnet – ansonsten schließt eine

COMMIT-Anweisung den Cursor.

Anmerkung: Das Statement DECLARE CURSOR ist eine Deklarationsanweisung, und wird bei der Definition nicht

ausgeführt.

• OPEN des Cursors. Jetzt werden alle Hostvariablen an DB2 übergeben und das Ergebnis des Cursors in den DB2-Pools

dargestellt.

• FETCH der einzelnen “rows” aus der “Cursor-Menge”. Man führt soviele FETCHes aus, wie nötig. Werden keine

“rows” zurückgeliefert, so ist der SQLCODE des FETCH 100.

• CLOSE des Cursor.

Aug2012 28



Cursor

1. Definition der Ergebnismenge => DECLARE CURSOR

2. Zeilenweises Einlesen ins Programm("host-variables") => FETCH ... INTO ...

DECLARE <cname> CURSOR FOR ...

OPEN <cname> .....

CLOSE <cname>...

FETCH <cname> INTO ...

SQLCODE = + 100

Aug2012 29



Declare und Verwendung eines Cursors in in einem AP mit dynamischem SQL

Hier sind sich dynamisches und statisches SQL sehr ähnlich. Ist der Cursor deklariert, so ist er auch mit seiner Query

verbunden. Mit dem Statement FETCH wird der Cursor auf die aktuelle(nächste) “row” positioniert und die Datenwerte aus

dieser Zeile den “host variables” zugewiesen.

Beim “static” SQL ist die Query ein SELECT Statement in Textformat, während beim “dynamic” SQL die Query über einen

Statement-Namen in einem PREPARE Statement angegeben ist: referenzierte “host variables” werden über PM s(“parameter

markers”) dargestellt.

Der Hauptunterschied zwischen statischem und dynamischem Cursor ist, dass ein statischer Cursor zum “precompile” Zeitpunkt

und ein dynamischer Cursor zur Laufzeit “prepared” wird. Die “host variables” werden über PM’s repräsentiert und ebenfalls

zur Laufzeit beim OPEN CURSOR mit Werten versorgt:

Aug2012 30



Cursor

1) Abgrenzung eines SQL-Statements: zwischen EXEC SQL und einem Terminator

2) Definition der eingesetzten DB2-Ressourcen(Tabellen, Views): alle DB2-Objekte sollten über DECLARE TABLE

definiert sein, um dem DB2-Precompiler zu erlauben, Syntax und die Kompatibilität der Datenfelder zu prüfen

3) Vorsicht mit reservierten Worten: z.B. HV dürfen nicht mit „SQL“ beginnen, Externe Namen(auch Plan-Namen)

dürfen nicht mit „DSN“ beginnen

4) Einsatzmöglichkeiten von HV: statische / dynamische SQL-Statements erlauben nur an bestimmten Stellen HV

5) Kennzeichnung von HV: sämtlichen HV muss innerhalb eines SQL-Statements ein „:“ vorangestellt sein.

6) Nutzung des SQL-Standards über die Precompile-Optionen; z.B.: SQLSTD (YES)

- Die SQLCA wird automatisch (ohne INCLUDE) vom Precompiler generiert

- Die SQL-Returncodes SQLCODE und/oder SQLSTATE müssen explizit definiert werden

7) Nach jedem ausführbaren SQL-Statement sind die SQLCODES zu prüfen

- SQLCODE und SQLWARN

- SQLSTATE

- Weitere Felder

- Bei Fehlern innerhalb eines Änderungsprozesses ROLLBACK aktivieren ansonsten drohen Konsistenzprobleme

Diese Codierregeln sollten bei DB2 selbstverständlich sein

Aug2012 31

DB2 Anwendungsentwurf - Cursortypen


Deklaration des Cursors... DECLARE CURSOR

• Eine Cursordeklaration ist ausschließlich deklarativ.

• Für die Cursorverarbeitungsfähigkeit sind folgende Schlüsselworte verantwortlich:

• FOR SELECT ... Die Result Table wird hiermit beschrieben. Sie kann updateable oder non-updateable sein. Hierzu sind folgende

Parameter relevant:

FOR UPDATE OF: Die Suchbedingung wird mit WHERE CURRENT OF ... Vorgegeben

Beim Datenzugriff wird die Page im LOCK-Mode „U“ gesperrt.

Es können auch Spalten verändert werden, die nicht innerhalb der Result

Table des Cursors definiert sind.

Alternativ zu ORDER BY, FOR FETCH ONLY bzw. FOR READ ONLY

FOR FETCH ONLY bzw. FOR READ ONLY

Diese Angabe kennzeichnet die Result Table grundsätzlich als „read only“.

LOCK-Avoidance erfolgt, sofern CURRENTDATA (NO) spezifiziert ist

WITH HOLD Bei einem COMMIT bleiben Result Table und die Positionierung

innerhalb der Result Table erhalten. Bei CICS sichert ein expliziter

CLOSE die Wiederverwendbarkeit des Thread, da CICS den Cursor nicht

automatisch schliesst.

Empfehlung: bei klassischen Transaktionen ohne WITH HOLD arbeiten

Aug2012 32

DB2 Anwendungsentwurf - Cursor


• CLOSE CURSOR sollte genutzt werden, um belegte Ressourcen freizugeben - insbesondere nach der Nutzung eines

Cursors mit der Klausel WITH HOLD und/oder der Verwendung von „scrollable cursors“ (seit DB2 V7).

• Aber nicht nur dann, denn wenn ein Cursor nach Fehler nicht geschlossen wird, bleiben SKCT-Teile unnötigerweise im

EDM-Pool erhalten.

• Auch die Abfrage auf einen SQL Returncode bei Close Cursor ist nicht überflüssig:

COMMIT und ROLLBACK Operationen schließen die Cursor.

• SQLCODES -404, -652, -679, -802, -901, -904, -909, -910, -911, und -913 veranlassen das Schließen des Cursors.

• Ist der Cursor dann geschlossen, so erfolgt auf weitere FETCHEs und CLOSE CURSOR Aktionen der SQLCODE -

501. Wurden bisher keine SQL Return Codes gesprüft, so ist die Logik des AP zu korrigieren, damit sichergestellt ist,

dass der CURSOR “offen” ist, wenn FETCH / CLOSE Statements ausgeführt werden.

• In vielen Batch Jobs definiert man oft CURSOR, die LOCKS über einen COMMIT Punkt hinaus halten. Wann

immer man die entsprechende Verarbeitung erledigt hat, sollte man den verarbeiteten Cursor unmittelbar schliessen.

Ansonsten bleiben die sogenannten “shared locks” erhalten und können andere Jobs zum Absturz bringen.

• Das Schliessen eines Cursors nach seiner Verarbeitung scheint logisch, aber viele Entwickler machen kein CLOSE

CURSOR und ermöglichen es so, dass Locks gehalten werden, bis das Programm beendet. Dies wiederum kann

Ursache für “deadlock/timeout” Probleme sein, da möglicherweise ein Job auf die Durchführung eines Update wartet,

während ein anderer die Page auf einem “shared lock” festhält.

Aug2012 33


DB2 kann für die Bereitstellung der Result Table mehrere Zugriffsalternativen nutzen:

• Direkte Positionierung auf die Basistabelle Die Result Table wird direkt auf den Basisdaten positioniert. Das AP erhält die Daten mit der Konsistenz zum

jeweiligen Anforderungszeitpunkt. Sie kann nur für Einzeldaten garantiert werden. Für Mengen ist die

Konsistenz undefiniert (!)

• Bereitstellen der Result Table über eine Interimstabelle Die RT kann durch komplettes Durchsuchen der Basisdaten gewonnen werden, muss aufgrund von ORDER

BY intern sortiert und dann in einer temporären Tabelle bereitgestellt werden (Materialisierte RT)

• Für den Anwendungsentwickler ist weiterhin wichtig, ob die RT

- Read-only (bei JOIN und ORDER BY) oder

- updateable ist (für „positioned UPDATE“ und „embedded CHANGE“ möglich)

- Gegen konkurrierendes Update geschützt ist

• Desweiteren ist interessant, ob die Basistabelle

- aktuell ist

- „read-only“ oder updateable ist (bei JOIN und ORDER BY)

- Gegen konkurrierendes Update geschützt ist

Performanceprobleme: - temporäre Result Tables sind aufwendig zu erstellen

- bei grossen Datenmengen mit SORT usw. umso mehr

- „sequential prefetch“ kann, muss aber nicht eingesetzt werden

Aug2012 34


Für jeden Cursor Typ in DB2 gibt 3 READ-Typen

1. Read Only 2. Updatable 3. Ambiguous Cursor

• Read Only Cursor: Bei Read Only Cursors kann DB2 „record blocking“ durchführen und so mehrere Sätze gleichzeitig lesen. Es braucht sich nicht um LOCK-Anforderungen zu kümmern, die es bräuchte, sollten die Sätze verändert werden (Was es ohne READ ONLY nicht weiß!!!). Gibt man also FOR FETCH ONLY an, so hilft das dem DB2 schneller zu lesen ohne LOCKS einzusetzen. Benutzt man Order by oder Group by, so nimmt DB2sowieso an, dass es sich um einen „Read only Cursor“ handelt.

• Updatable Cursor: Ein Cursor ist „updatable“, wenn FOR UPDATE im SELECT angegeben wurde; d.h. dass alle „rows“ über ein „Update Where Current Of..“ Statement modifiziert werden können. Das funktioniert sowieso nur bei einem SELECT Statement, das eine EINZIGE Tabelle enthält.

• Ambiguous cursors Ein Cursor ist „ambiguous“, wenn DB2 aus der Cursordefinition heraus nicht entscheiden kann, ob es sich um einen „read-only“ oder einen „updatable“ Cursor handelt. Mit anderen Worten, der SELECT für den Cursor wurde weder mit FOR READ ONLY noch mit FOR UPDATE spezifiziert. Er ist „ambiguous“ – mehrdeutig(!).

Für einen solchen Cursor macht DB2 weder „record blocking“, auch wenn die BLOCKING Option im BIND für diese Applikation gesetzt ist.

Aug2012 35

DB2 Cursor


WITH UR kann nur mit SELECT Queries eingesetzt werden. In diesem Fall liest DB2 ALLE „qualifying rows“ (inklusive der „uncommitted rows“ ) . Wenn nun der ändernde Prozess ROLLBACK absetzt, so hat man „falsche“ Daten gelesen. Generell nutzt man WITH UR, um LOCKS auf einer Tabelle zu vermeiden. WITH UR verursacht nicht einmal „claims“.

Das Lesen von „uncommitted data“ führt zu einer gewissen Unsicherheit in der Datenkonsistenz.

• Einsetzen der ISOLATION (UR):

o Wenn keine Fehler auftreten können:

– „Reference tables“ (Teile mit <teilenummer>, die sich seltenst ändert bzw. in RI eingebunden ist)

– Tabellen mit eingeschränkten Zugriffen („security“, „legacy“ Tabellen, …)

o Wenn Fehler akzeptiert werden können ( … bei statistischen Auswertungen, DWH, … )

o Wenn die Daten bereits Inkonsistenzen enthalten

• Vermeiden der ISOLATION (UR):

o Wenn Berechnungen passen müssen

o Wenn die geforderte Antwort auf jeden Fall genau sein muss

o Wann immer man unsicher ist, ob die ISOLATION (UR) schädlich sein könnte oder nicht….

Bei langlaufenden Queries auf Clients können nach Erfahrungen so bis zu 30% CPU-Zeit gespart werden.

Aug2012 36

DB2 Anwendungsentwurf - Cursor

Anmerkung: Bei der Verwendung von dynamischem SQL ist der Cursor immer mehrdeutig

(„ambigous“).

SQL-Anweisungen mit Blockung Aktualisierbare SELECT-Anweisungen (die Anweisungen

UPDATE/DELETE WHERE CURRENT OF verwenden) stellen nicht geblockte Abfragen dar, daher sollten

sie nur verwendet werden, wenn dies absolut erforderlich ist.

Eine aktualisierbare SELECT-Anweisung stellt sicher, dass die Zeile zwischen dem Zeitpunkt des Beendens

von SELECT und dem Zeitpunkt der Eingabe von UPDATE/DELETE nicht geändert wird. Wenn diese

Stufe des gemeinsamen Zugriffs für Ihre Anwendung nicht wichtig ist, kann stattdessen DELETE oder

UPDATE mit Suchkriterien verwendet werden, die auf von einer nicht aktualisierbaren SELECT-Anweisung

übergebenen Werten basieren.

Für SELECT mit Lesezugriff geben Sie FOR FETCH ONLY an (außer unter VM und VSE, da es dort

nicht unterstützt wird).


Aug2012 37


Statisches und dynamisches SQL

Verwenden Sie so oft wie möglich statisches SQL. Hierdurch werden mehrdeutige Cursor und die

Vorbereitung von SQL-Abschnitten zur Laufzeit vermieden. Wenn dynamisches SQL sich nicht vermeiden

lässt, können folgende Maßnahmen ergriffen werden, damit der Datenaustausch auf dem Netzwerk

minimiert und die Leistung verbessert wird:

• Wenn die Anweisung eine Anweisung SELECT ist und eine Vorbereitung erforderlich ist, führen Sie PREPARE ... INTO

für einen SQL-Deskriptorbereich durch. Für den SQL-Deskriptorbereich sollte die vollständige Größe zugeordnet

werden, die für die verwendeten Einstellungen erforderlich ist.

• Wenn die maximale Anzahl von Spalten x beträgt und sich voraussichtlich nichts ändern wird, sollte ein SQL-

Deskriptorbereich mit x SQLVARs zugeordnet werden.

• Wenn die Anzahl möglicher Spalten unsicher ist (und Hauptspeicher keinen Engpass darstellt), sollte die maximale

Anzahl von SQLVARs (256) verwendet werden.

• Wenn der zugeordnete Wert für den SQL-Deskriptorbereich nicht groß genug zum Speichern des übergebenen SQL-

Deskriptorbereichs ist, muss das Programm eine weitere Anweisung DESCRIBE mit einem SQL-Deskriptorbereich

absetzen, der groß genug ist, um das Ergebnis erneut zu speichern. Hierdurch wird der Datenaustausch auf dem Netzwerk

erhöht.

• Die Folge aus PREPARE und DESCRIBE sollte nicht verwendet werden. Die Verwendung der Anweisung

PREPARE.....INTO bietet eine bessere Leistung.


Aug2012 38


Statisches und dynamisches SQL

• Binden Sie statische SQL-Anweisungen COMMIT / ROLLBACK statt „dynamic“ COMMIT / ROLLBACK.

• Wenn es sich nicht um eine Anweisung SELECT, COMMIT oder ROLLBACK handelt, sollte EXECUTE IMMEDIATE

statt einer Folge aus PREPARE und EXECUTE zum Ausführen der Anweisung gegeben werden.

• ODBC-Anwendungen verwenden dynamisches SQL. Sie können die Leistung unter Umständen mithilfe der statischen

CLI/ODBC-Profilierungsfunktion verbessern. Mit dieser Funktion können Sie ODBC-Aufrufe erfassen und in statische

Anweisungen umsetzen, die in einem PACKAGE gespeichert werden. Die tatsächliche Leistung, die Sie erhalten, hängt

allerdings von der Komplexität der Anwendung ab.

Weitere Überlegungen zu SQL

• Die Verwendung des Befehlszeilenprozessors (CLP) ist im Allgemeinen langsamer als die Verwendung von dynamischer

SQL im Programm, weil der CLP die Eingabedaten syntaktisch analysieren muss, bevor die SQL-Anweisungen an die DB-

Control Component übergeben werden.

• Der CLP formatiert die Daten auch bei deren Eingang, was für Ihre Anwendung möglicherweise gar nicht erforderlich ist.

• SQL-Anweisungen in einer interpretierten Sprache (z. B. REXX) sind wesentlich langsamer als dieselben SQL-

Anweisungen in einer Compilersprache (z. B. C).

• Es gibt zwei Typen der Anweisung CONNECT (Typ 1 / Typ 2). Bei Verbindungen des Typs 2 wird beim Herstellen einer

Verbindung zur DB die vorherige Verbindung in Ruhezustand versetzt, aber nicht beendet. Durch das spätere

Umschalten zu einer im IDLE befindlichen Verbindung kann der Systemaufwand für das Laden von Bibliotheken und das

Einrichten interner Datenstrukturen umgangen werden. Aus diesem Grund kann die Verwendung von Verbindungen des

Typs 2 die Leistung von Anwendungen verbessern.


Aug2012 39

DB2 for LUW DB2 for LUW –– CursortypenCursortypen

Beachtenswertes und Programmierempfehlungen

1. Arbeiten Sie mit einem DB2 Qualitätssicherungstool. Beginnen Sie damit frühzeitig in der

Realisierungsphase. Sie werden rechtzeitig auf Probleme im physischen Datenbankdesign aufmerksam

gemacht. Kritische Queries können vor Produktionseinsatz identifiziert werden. Sie können Ihr Indexdesign

für die ganze Anwendung optimieren anstatt pro Statement im ‘Nebel’ zu stochern.

2. Nutzen Sie die Möglichkeiten des SQL Analyse-Tools bei der Weiterentwicklung und Pflege der

Anwendungen.

3. Falls Sie Anforderungen an Performance und hohe Verfügbarkeit haben, schreiben Sie die DB2

Statements NICHT wie Zugriffe auf sequentielle Dateien oder andere Datenbanksysteme. DB2 ist nicht

ADABAS oder IMS! DB2 arbeitet mengenorientiert.

4. Falls Sie mit CASE-Tools(z.B. ERWIN) arbeiten, übernehmen Sie nicht einfach generierte DDL oder

DML. Achten Sie darauf, daß Schlüssel und Indizes sinnvoll aufgebaut sind. Keycolumns mit geringer

Kardinalität gehören nicht an den Anfang. Das verwirrt nur den DB2 Optimizer.

5. Die Reihenfolge der Spalten in der Tabelle ist für DB2 ohne Bedeutung.

6. Verwenden Sie immer EXPLAIN(YES) und überprüfen Sie die Zugriffspfade.

7. Benutzen Sie generierte Strukturen, um für Tabellen/Views entsprechende Datenstrukturen zu erzeugen.

Für alle Prädikate gilt, daß Datentyp, Länge und Nachkommastellen von Spalten, Hostvariablen und

Literalen übereinstimmen müssen.

8. Selektieren Sie nur die Spalten einer Tabelle, die benötigt werden. Jede ausgewählte Spalte bedeutet

zusätzlichen CPU-Verbrauch. Selektieren Sie keine Spalten, die in der Anwendung schon bekannt sind und

beispielsweise in der WHERE-Klausel in einem ‘Gleichheitsprädikat’ verwendet werden.

Aug2012 40


Beachtenswertes und Programmierempfehlungen

8. Selektieren Sie nur die Spalten einer Tabelle, die benötigt werden. Jede ausgewählte Spalte bedeutet zusätzlichen

CPU-Verbrauch. Selektieren Sie keine Spalten, die in der Anwendung schon bekannt sind und beispielsweise in der

WHERE-Klausel in einem ‘Gleichheitsprädikat’ verwendet werden.

9. Verwenden Sie nie ‘SELECT *’. Falls die Tabelle geändert wird, müssen Sie alle entsprechenden Programme ändern.

Dazu kommt der erhöhte System-Overhead.

10. Verwenden Sie keine 1:1 Views auf Tabellen. Sie haben keinen funktionalen Vorteil.

11. Verwenden Sie in allen (Batch-)Programmen, die Tabellen ändern, ein standardisiertes Checkpoint/Restart

Verfahren. Setzen Sie regelmäßig Commit-Punkte (etwa alle 1000 - 5000 Änderungen). Die Frequenz sollte

einstellbar sein. Bauen Sie das Checkpoint/Restart Verfahren auch in kurzlaufende Programme oder

‘Einmalprogramme’ ein. Häufig werden aus diesen Kurzläufern in Sonderaktionen oder durch Datenwachstum

Endlosprogramme, die stundenlang ohne Commits laufen. Dadurch wird das DB2 übermäßig belastet, die eigenen

und andere Anwendungen werden behindert. Im Fehlerfall kann der Rollback lange dauern. Ein Wiederaufsetzen

am Anfang bedeutet zusätzlichen Zeitverlust und Ressourcenverbrauch. Benutzen Sie die WITH HOLD Option

beim DECLARE CURSOR.

12. Versuchen Sie langlaufende Programme in mehrere Teile zu zerlegen, die parallel arbeiten können.

13. Vermeiden Sie unnötige SORT Operationen. DISTINCT wird bei UNION beispielsweise nicht benötigt. Benutzen

Sie Indizes, die den Sort unterstützen.

14. Vermeiden Sie NULL Felder. Sie erhöhen in den meisten Fällen nur den Programmieraufwand.

15. Vermeiden Sie VARCHAR Felder. Sie erhöhen den Programmieraufwand und den "System-Overhead".

Aug2012 41


Beachtenswertes und Programmierempfehlungen (contn‘d)

16. Kontrollieren Sie im Programm sorgfältig jeden auftretenden SQLCODE.

17. Vermeiden Sie unnötige Cursor. Falls Sie in 95% der Fälle nur einen Satz zurückbekommen, fangen Sie mit einem

einfachen SELECT an. Beim SQLCODE -811 öffnen Sie dann einen entsprechenden Cursor.

18. Die gleiche Technik können Sie unter Umständen beim INSERT oder UPDATE verwenden, falls Sie nicht wissen,

ob ein bestimmter Schlüssel existiert (-803). Sie können so ein unnötiges SELECT vermeiden.

19. Verwenden Sie eine Retry-Logik bei bestimmten Fehlern (-911). Begrenzen Sie die Anzahl der Versuche; z.B. auf 5.

20. Definieren Sie für jede Tabelle einen Primary Key.

23. Geben Sie immer einen Index für das CLUSTERING an. Das muß nicht der Index auf dem Primary Key sein. Dieser

Index bestimmt, in welcher Reihenfolge die Daten physisch beim Insert im Tablespace abgelegt werden. Dies wird auch

beim REORG benutzt. Verwenden Sie den CLUSTER Parameter nicht, kann das unvorhersehbare Effekte bei den

Zugriffspfaden bewirken. Der Optimizer bevorzugt bei Join Operationen die „Clustering Indizes“.

24. Definieren Sie einen Index möglichst als UNIQUE. DB2 kann solche Indizes wesentlich effizienter nutzen.

Uniqueness erleichtert dem Optimizer die Indexnutzung bei der Auswahl des Zugriffspfades.

25. Um dem Optimizer möglichst genaue Informationen zu liefern, sollte das RUNSTATS Utility zumindest nach einer

Anwendungsimplementierung ausgeführt werden.

26. RUNSTATS auf eine leere Tabelle kann die Ursache für ungewollte Tablespacescans sein.

Aug2012 42


Beachtenswertes und Programmierempfehlungen(contn‘d)

27. Rechnen Sie nicht in der WHERE Klausel (...WHERE Betrag = :HV + 3). Damit verhindern Sie, daß

DB2 einen Index für dieses Feld benutzt. Das gleiche gilt auch für Datumsfelder. Meist lässt sich das mit

wenig Aufwand im Programm selber bestimmen.

28. Prüfen Sie im Einzelfall, „OPTIMIZE FOR n ROWS“ zu nutzen. DB2 wählt dann unter Umständen

einen anderen Zugriffspfad. Für n = 1 wird aus einem Hybrid Join immer ein Nested Loop Join. Die

Ergebnismenge wird nicht verändert. Benötigen Sie die gesamte Result Table, kann dies allerdings zu

einem insgesamt schlechteren Zugriffspfad führen.

29. Verwenden Sie bei reinen Lesezugriffen FOR FETCH ONLY.

30. Schließen Sie CURSOR unmittelbar nachdem die Verarbeitung abgeschlossen wurde oder wenn die

“EOF-Bedingung” eingetreten ist (SQLCODE= +100).

Grund: Ressource-Nutzung: Zwischen-Ergebnistabellen („result tables“)

bleiben solange erhalten, bis ihre zugehörigen CURSOR geschlossen sind.

31. Wird eine Ergebnistabelle aufgebaut, so sollten nicht mehr “rows” als

notwendig angefordert werden. Wenn möglich, so sollte in der

WHERE-Klausel ein Anfangs- und eine Endwert spezifiziert sein.

Grund: Sperren und “ressource”-Nutzung werden miniminiert. Seit

Version 3.1 werden alle “page”-S-Locks gehalten bis die

letzte „result table“ vollständig erstellt wurde.

Aug2012 43


Beachtenswertes und Programmierempfehlungen(contn‘d)

32. Nutzen Sie die ORDER BY-Klausel, um Zeilen in einer gewünschten Sequenz zu erhalten

(CLUSTER’d oder anders)

Grund: Tabellen sind in der CLUSTER-Sequenz nur nach REORG. Zwischenzeitlich erfolgte INSERTed

“rows” können in einer beliebigen “page” stehen. Um die gewünschte Sequenz sicherzustellen

muß ORDER BY benutzt werden.

33. Kein “kritisches” Batch-Programm sollte mehr als 15 Minuten benötigen, um im Falle eines Fehlers

einen RESTART durchzuführen.

Grund: Problematik kritischer Systeme geeignete RESTART-Methoden evaluieren.

34. Stellen Sie sicher, daß ein Commit-Vorgang (UOR) abgeschlossen ist, bevor Informationen am

Terminal/PC ausgegeben werden.

Grund: Sperren; alle Sperren werden beibehalten bis eine folgende Verarbeitung sie freigibt, oder bis ein

“deadlock” /“timeout“ geschieht.

Aug2012 44

DB2 Anwendungen

COBOL-Beispiel:


***********************************************************************

** (c) Copyright IBM Corp. 2007 All rights reserved.

**

** The following sample of source code ("Sample") is owned by International

** Business Machines Corporation or one of its subsidiaries ("IBM") and is

** copyrighted and licensed, not sold. You may use, copy, modify, and

** distribute the Sample in any form without payment to IBM, for the purpose of

** assisting you in the development of your applications.

**

** The Sample code is provided to you on an "AS IS" basis, without warranty of

** any kind. IBM HEREBY EXPRESSLY DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR

** IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF

** MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Some jurisdictions do

** not allow for the exclusion or limitation of implied warranties, so the above

** limitations or exclusions may not apply to you. IBM shall not be liable for

** any damages you suffer as a result of using, copying, modifying or

** distributing the Sample, even if IBM has been advised of the possibility of

** such damages.

***********************************************************************

**

** SOURCE FILE NAME: advsql.sqb

**

** SAMPLE: How to read table data using CASE

**

** This sample shows how to read table data using advanced

** SQL statements with CASE.

**

Aug2012 45

DB2 Anwendungen

COBOL-Beispiel:


***********************************************************************************************************

**

** SQL STATEMENTS USED:

** BEGIN DECLARE SECTION

** END DECLARE SECTION

** CONNECT

** DECLARE

** FETCH

** OPEN

**

**

***********************************************************************************************************

**

** For more information on the sample programs, see the README file.

**

** For information on developing embedded SQL applications see the Developing Embedded SQL Applications book.

**

** For information on using SQL statements, see the SQL Reference.

**

** For the latest information on programming, compiling, and running DB2 applications, visit the DB2 Information

Center:

** http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp

***********************************************************************************************************

Identification Division.

Program-ID. "advsql".

Aug2012 46

DB2 Anwendungen

COBOL-Beispiel:


Data Division.

Working-Storage Section.

copy "sqlenv.cbl".

copy "sql.cbl".

copy "sqlca.cbl".

EXEC SQL BEGIN DECLARE SECTION END-EXEC.

01 userid pic x(8).

01 passwd.

49 passwd-length pic s9(4) comp-5 value 0.

49 passwd-name pic x(18).

01 lname.

49 lname-length pic s9(4) comp-5 value 15.

49 lname-name pic x(15).

01 wdept pic x(3).

EXEC SQL END DECLARE SECTION END-EXEC.

77 errloc pic x(80).

77 counter pic s9(4) comp-5 value 0.

Procedure Division.

Main Section.

display "Sample COBOL program: ADVSQL".

display "the statment to be executed:".

display " ".

Aug2012 47

DB2 Anwendungen

COBOL-Beispiel:


display "SELECT LASTNAME, WORKDEPT FROM EMPLOYEE".

display " WHERE CASE".

display " WHEN BONUS+COMM = 0 THEN NULL".

display " ELSE SALARY/(BONUS+COMM)".

display " END > 10".

display " ".

* Get database connection information.

display "Enter your user id (default none): "

with no advancing.

accept userid.

if userid = spaces

EXEC SQL CONNECT TO sample END-EXEC

else

display "Enter your password : " with no advancing

accept passwd-name.

* Passwords in a CONNECT statement must be entered in a VARCHAR

* format with the length of the input string.

inspect passwd-name tallying passwd-length for characters

before initial " ".

display " ".

EXEC SQL CONNECT TO sample USER :userid USING :passwd

END-EXEC.

move "CONNECT TO" to errloc.

Aug2012 48

DB2 Anwendungen

COBOL-Beispiel:


call "checkerr" using SQLCA errloc.

* declare the cursor for the advanced SQL statement.

EXEC SQL DECLARE c1 CURSOR FOR

SELECT LASTNAME, WORKDEPT FROM employee

WHERE CASE

WHEN BONUS+COMM = 0 THEN NULL

ELSE SALARY/(BONUS+COMM)

END > 10 END-EXEC.

EXEC SQL OPEN c1 END-EXEC.

move "OPEN" to errloc.


display "LASTNAME WORKDEPT".

* FETCH the rows from the table corresponding to the SQL statement.

perform Fetch-Loop thru End-Fetch-Loop

until SQLCODE not equal 0.

display " ", counter, " record(s) selected".

EXEC SQL CONNECT RESET END-EXEC.

move "CONNECT RESET" to errloc.


End-Main.

go to End-Prog.

Aug2012 49

DB2 Anwendungen

COBOL-Beispiel:


Fetch-Loop Section.

move spaces to lname-name.

EXEC SQL FETCH c1 INTO :lname, :wdept END-EXEC.

if SQLCODE not equal 0

go to End-Fetch-Loop.

display lname-name, " ", wdept.

add 1 to counter.

End-Fetch-Loop. exit.

End-Prog.

stop run.

Aug2012 50

DB2 und Anwendungsentwicklung – Fehleranalyse (SQLCA)

DB2 for LUW DB2 for LUW –– FehleranalyseFehleranalyse

Aug2012 51



Aug2012 52



Aug2012 53



SQLWARN0 bis 10: diverse Warnings

Aug2012 54

DB2 und Anwendungsentwicklung –

Fehleranalyse


Aug2012 55


Kapitelinhalt



Beispiele


Scope of cursors




Sperrmechanismen



SAVEPOINTs

Aug2012 56

DB2 for LUW DB2 for LUW –– LockingLocking und COMMIT/ROLLBACKund COMMIT/ROLLBACK

1. Sperren von Systemressourcen = "locking"

Schutz gegen Fehler bei konkurrierender Verarbeitung über LOCK/LATCH gegen :

-- gleichzeitige Veränderung von Datengleichzeitige Veränderung von Daten

-- Bearbeitung ungesicherter DatenBearbeitung ungesicherter Daten

Aug2012 57


DB2DB2--Maßnahmen zur DatensicherheitMaßnahmen zur Datensicherheit:

Fehler des OS und - beim nächsten Restart werden die Daten automatisch

der Systemsoftware in einen konsistenten Zustand gebracht

Fehler auf den - Logging hilft zusammen mit Utilities und archivierten

Platten Sicherungsbeständen

- Log-Inhalte werden benötigt

- Dual-Logging

- hierarchisches Log-Konzept

Fehler in AP's - Isolation, LUoW und COMMIT, UoR

und interakti- - ROLLBACK einer LUoW / UoR

ven Prozessen

Aufgabe von Sperren auf Systemressourcen = "locking"

DB2-Maßnahmen in Abhängigkeit Nutzungsmöglichkeiten:

„local DB's" / „remote" DB's

Aug2012 58


Aufgabe von Sperren auf Systemressourcen = "locking"

1. Um “concurrency” Probleme auszuschliessen

2. Um parallele Verarbeitungsmodi zuzulassen

3. DB2 kennt im Grossen und Ganzen zwei

Typen von LOCKs:

• Locks zur Kontrolle des Lesevorgangs

• Locks zur Kontrolle des Modifikations-

vorgangs

Das ist natürlich vereinfacht gesagt.

DB2 verwendet mehrere Varianten dieser

zwei LOCK-Typen.

Aug2012 59


LUW = LUW = UoWUoW Logical Unit of Work / Unit of Work als Einheit der physischen

Transaktion bei DB2 Prozessen

Eine Transaktion kann aus einer oder mehreren UoW's bestehen

SYNCPOINT / CHECKPOINT begrenzen eine UoW

UoRUoR Unit of Recovery bei DB2 die Konsistenz-Einheit innerhalb einer Lokation.

Die UoR ist eine Untermenge der UoW's. Sie beginnt mit der ersten

Datenänderungsanforderung eines Thread und endet mit COMMIT / ROLLBACK

bzw. Transaktionsende

Probleme Lost Update: wird ein Satz von einer AP-1 verändert, so darf keine andere Applikation während der

Wartezeiten der AP-1 diese Daten verändern.

Beispiel: Eine "online"-AP schreibt eingelesene Daten nach einer bestimmten Zeit

(verändert) wieder zurück

Zugriff auf Daten, deren UoW noch nicht abgeschlossen ist:

werden Daten innerhalb einer UOW verändert, so dürfen diese bis zum Ende der

UOW/UoR (COMMIT / ROLLBACK ) keiner anderen AP zugänglich sein

Wiederholtes Einlesen von Daten innerhalb einer UoW:

funktioniert nur, wenn der Datenzustand nicht verändert wurde

Deadlock/Timeout: da das DBMS Sperren einsetzt, um die Konsistenz der Daten zu sichern, können

Situationen entstehen, in denen sich zwei UOW's/UoR‘s gegenseitig behindern

Die Begriffe beim "locking"

Aug2012 60


DB2 und Locking – Lock Charakteristika bei DB2

Das alles macht das Locking aus:

Lock-Objekt die zu schützende Ressource

Lock-Niveau Umfang der Sperrung auf einem Lock-Objekt

Lock-Dauer Dauer der Sperre auf einem Lock-Objekt

Isolation-Level Isolations-Grad und Sperrdauer lesender Anforderungen im Hinblick auf

konkurrierende Anwendungen (CS, RS, RR, UR )

Lock-Modus die von DB2 ermittelte Art der Sperre ( IS, IX, S, Z, …. )

Pgm 1 Pgm 2

LOCKSIZE TABLE

PK = 20

PK = 40

Table 5

PK = 15

PK = 35

Table 8

1

2

Pgm 1 Pgm 2

LOCKSIZE ROW

PK = 20

PK = 40

Page 5

PK = 15

PK = 35

Page 8

1

2

2

1

Aug2012 61


Sperrenverwaltung bei DB2

Die Sperrenverwaltung ist einer der Faktoren, die sich auf die Anwendungsleistung auswirken. Effiziente

Sperrenverwaltung kann helfen, die Leistung von Datenbankanwendungen zu maximieren:

Sperren und Steuerung des gemeinsamen Zugriffs Zur Steuerung des gemeinsamen Zugriffs sowie zur Verhinderung eines unkontrollierten Datenzugriffs aktiviert der DBM Sperren

für Pufferpools, Tabellen, Datenpartitionen, Tabellenblöcke oder Tabellenzeilen.

Sperrgranularität Wenn eine Anwendung eine DB-Objekt Sperre aktiviert hat, kann eine andere Anwendung auf dieses Objekt evtl. nicht zugreifen.

Deshalb sind Sperren auf Zeilenebene bzgl. eines maximalen gemeinsamen Zugriffs besser als Sperren auf Blockebene,

Datenpartitionsebene oder Tabellenebene; das gesperrte Datenvolumen, wird minimiert.

Sperrenattribute Die Sperren des Datenbankmanagers verfügen über eine Reihe von Basisattributen:

Modus: Der Typ des Zugriffs, der dem Sperreneigner gewährt wird, sowie der Typ des Zugriffs, der Benutzern gewährt wird, die

das gesperrte Objekt gleichzeitig verwenden. Dies wird auch als Status der Sperre bezeichnet ( IN, IS, IX, S, U, X, Z….).

Objekt: Die Ressource, die gesperrt ist. Der einzige Typ von Objekt, den Sie explizit sperren können, ist eine Tabelle. Der DBM

aktiviert Sperren auch für andere Typen von Ressourcen, wie „rows“ und TS. Für MDC-Tabellen können außerdem Blocksperren

aktiviert werden und für partitionierte Tabellen können Sperren auf Partitions aktiviert werden. Das Objekt, das gesperrt wird,

bestimmt die Granularität der Sperre.

Zähler für Sperre: Der Zeitraum, während dessen eine Sperre aktiviert ist. Die Isolationsstufe, unter der eine Abfrage ausgeführt

wird, beeinflusst den Zähler.

http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.perf.doc/doc/c0005266.html



Aug2012 62


Faktoren mit Auswirkungen auf Sperren Eine Reihe von Faktoren beeinflusst den Modus und die Granularität von Sperren des Datenbankmanagers:

• Die Art der Verarbeitung, die von der Anwendung ausgeführt wird

Anwendungsverarbeitung mit Lesezugriff (z.B. FOR READ ONLY, FOR FETCH ONLY)

Anwendungsverarbeitung mit Änderungsabsicht (z.B. FOR UPDATE, USE AND KEEP UPDATE LOCKS, USE AND

KEEP EXCLUSIVE LOCKS… ).

Anwendungsverarbeitung mit Änderung (z.B. UPDATE-, INSERT- und DELETE – nicht UPDATE WHERE CURRENT OF

oder DELETE WHERE CURRENT OF. Für diesen Typ sind exklusive Sperren (IX oder X) erforderlich).

Cursorgesteuerte Anwendungsverarbeitung ( Dieser Verarbeitungstyp umfasst Anweisungen mit UPDATE WHERE

CURRENT OF und DELETE WHERE CURRENT OF…)

• Die Datenzugriffsmethode

Ein Zugriffsplan ist die Methode, die der Optimierer zum Abrufen von Daten aus einer bestimmten Tabelle auswählt. Der

Zugriffsplan kann erhebliche Auswirkungen auf Sperrmodi haben. Wenn eine Indexsuche zum Auffinden einer bestimmten Zeile verwendet wird, wählt der Optimizer gewöhnlich Sperren auf

Zeilenebene (IS) für die Tabelle aus. Wenn die Tabelle EMPLOYEE zum Beispiel einen Index für die Spalte EMPNO

(Personalnummer) hat, könnte ein Zugriff über diesen Index ausgeführt werden:

select * from employee where empno = '000310'

Wenn kein Index verwendet wird, muss die gesamte Tabelle der Reihe nach durchsucht werden, um die erforderlichen Zeilen zu finden.

In diesem Fall wählt der Optimizer wahrscheinlich eine einzelne Sperre auf Tabellenebene (S) aus. Wenn zum Beispiel kein Index für

die Spalte SEX vorhanden ist, könnte eine Table Scan eangewandt werden:

select * from employee where sex = 'M'

• Die Werte verschiedener Konfigurationsparameter



Aug2012 63


Sperrtypenkompatibilität Die Sperrenkompatibilität wird zu einem Problem, wenn eine Anwendung eine Sperre für ein Objekt aktiviert hat und eine

weitere Anwendung eine Sperre für dasselbe Objekt anfordert. Wenn die beiden Sperrmodi kompatibel sind, kann die

Anforderung für eine zweite Sperre für das Objekt zugelassen werden.

Auszug aus der Kompatibilitätenliste:


http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.perf.doc/doc/r0005274.html

Aug2012 64


Sperren der nächsten Schlüssel Während der Einfügung eines Schlüssels in einen Index, wird die Zeile, die dem Schlüssel entspricht, der auf den neuen Schlüssel

im Index als Nächstes folgt, nur gesperrt, wenn diese Zeile momentan durch eine Indexsuche unter der Isolationsstufe

'Wiederholbares Lesen' (RR) gesperrt ist. Wenn dies geschieht, wird die Einfügung des neuen Indexschlüssels ausgesetzt, bis die

Transaktion, die die RR-Suche ausgeführt hat, abgeschlossen wird.

Sperrmodi und Zugriffspläne für Standardtabellen Der Typ von Sperre, den eine Standardtabelle aktiviert, hängt von der geltenden Isolationsstufe sowie vom verwendeten

Datenzugriffsplan ab.

Nur ein beispiel:

Sperrmodi für MDC-Tabellen- und Satz-ID-Indexsuchen Der Typ von Sperre, den eine Tabelle mit mehrdimensionalem Clustering (MDC-Tabelle) bei einer Tabellen- oder Satz-ID-

Indexsuche aktiviert, hängt von der geltenden Isolationsstufe sowie vom verwendeten Datenzugriffsplan ab.

Sperrmodi für MDC-Blockindexsuchen Der Typ von Sperre, den eine Tabelle mit mehrdimensionalem Clustering (MDC-Tabelle) bei einer Blockindexsuche aktiviert,

hängt von der geltenden Isolationsstufe sowie vom verwendeten Datenzugriffsplan ab.

















Aug2012 65


Sperrverhalten für partitionierte Tabellen Zusätzlich zu einer Sperre für die gesamte Tabelle wird eine Sperre für jede Datenpartition einer partitionierten Tabelle aktiviert.

Auf diese Weise können die zu sperrenden Bereiche besser differenziert und der gemeinsame Zugriff im Vergleich zu einer nicht

partitionierten Tabelle erhöht werden. Die Datenpartitionssperre wird in der Ausgabe des Befehls db2pd, von

Ereignismonitoren, von Verwaltungssichten und von Tabellenfunktionen ausgewiesen.

Wenn auf eine Tabelle zugegriffen wird, wird zunächst eine Tabellensperre aktiviert. Anschließend werden

Datenpartitionssperren nach Bedarf aktiviert. Aufgrund der verwendeten Zugriffsmethoden und Isolationsstufen ist es möglich,

dass Datenpartitionen gesperrt werden müssen, die nicht zur Ergebnismenge gehören.

Bei einer Suche in einem IX unter der Isolationsstufe 'Cursor Stability' (CS) können Sperren für Partitionen, auf die zuvor

zugegriffen wurde, beibehalten werden, um den Aufwand für eine erneute Aktivierung von Partitionssperren zu verringern.

Partitionssperren beinhalten auch den Aufwand für die Sicherstellung des Zugriffs auf TS. Bei nicht partitionierten Tabellen

wird der Zugriff auf TS durch Tabellensperren gesteuert. Partitionssperren werden aktiviert, auch wenn exklusive oder eine

Sperre (Share) auf Tabellenebene für den gemeinsamen Zugriff aktiviert ist.

Sperrenumwandlung Die Änderung des Modus einer Sperre, die bereits aktiviert ist, wird als Lock-Promotion bezeichnet.

Lock-Promotion erfolgt, wenn ein Prozess auf ein Datenobjekt zugreift, für das er bereits eine Sperre aktiviert hat, und der

Zugriffsmodus eine noch stärker einschränkende als die aktuelle Sperre erfordert. Ein Prozess kann immer nur eine Sperre für

ein Datenobjekt gleichzeitig aktiviert haben, obwohl er eine Lock für dasselbe Datenobjekt mehrfach indirekt anfordern kann.

Einige Sperrmodi gelten nur für Tabellen, andere nur für Zeilen, Blöcke oder Datenpartitionen. Für Zeilen oder Blöcke

findet eine Umwandlung in der Regel statt, wenn eine X-Sperre benötigt wird und eine S- oder U-Sperre (Update) aktiviert ist.

Lock-Promotion findet implizit bei der Ausführung einer Abfrage statt. Die Systemmonitorelemente lock_current_mode und

lock_mode können Informationen zu Lock-Promotions bereitstellen.




Aug2012 66


Wartestatus und Zeitlimitüberschreitungen für Sperren Das Erkennen von Überschreitungen der Sperrzeit ist eine DBM-Funktion, die verhindert, dass Anwendungen unendlich lange

auf die Freigabe einer Sperre warten.

Eine Transaktion könnte beispielsweise auf eine Objekt warten, das von einer anderen Anwendung gesperrt ist. Der andere

Benutzer hat seine Workstation verlassen, ohne ein Ende der UoR zu veranlassen. Um nun eine Blockade zu vermeiden, setzt

man den DBCONFIG-Parameter locktimeout auf maximale Zeitdauer, die eine Anwendung auf eine Sperre warten muß.

Durch die Einstellung dieses Parameters können globale Deadlocks besser vermieden werden, ibesonders in Anwendungen mit

DUoWs („Distributed Units of Work“). Wenn die Zeit der Sperrenanforderung länger dauert, als die im Parameter locktimeout

definierte Zeit, wird ein Fehler an die anfordernde Anwendung gegeben und Transaktion mit ROLLBACK rückgängig gemacht.

Beispiel: Wenn Anwendung APPL1 versucht, eine Sperre zu erhalten, die bereits für Anwendung APPL2 aktiv ist, empfängt

Anwendung APPL1 den SQLCODE -911 (SQLSTATE 40001) mit Reason-Code 68, wenn das Zeitlimit überschritten ist. Der

Standardwert für locktimeout ist -1, d. h., dass die Erkennung von Überschreitungen der Sperrzeit ausgeschaltet ist.

Für Tabellen-, Zeilen-, Datenpartitions- und MDC-Blocksperren kann eine Anwendung den Wert des Parameters locktimeout

überschreiben, indem sie den Wert des Spezialregisters CURRENT LOCK TIMEOUT ändert.






Aug2012 67


Deadlocks Ein Deadlock entsteht, wenn zwei Anwendungen Daten sperren, die die jeweils andere Anwendung benötigt. Daraufhin kommt es

zu einer Situation, in der weder die eine noch die andere Anwendung ihre Ausführung fortsetzen kann.

Da Anwendungen Sperren für Daten, die sie benötigen, nicht von sich aus freigeben, ist ein Detektorprozess erforderlich, der

Deadlocks auflöst. Der Deadlock-Detektor überwacht Agenten, die auf Sperren warten, und wird in Intervallen aktiv, die durch

den DB-Konfigurationsparameter dlchktime angegeben werden.

Ermittelt der Deadlock-Detektor einen Deadlock, definiert er einen der Prozesse im Deadlock als „selected“ Prozess, für den

Rollback durchgeführt werden muss. Dieser Prozess wird aktiviert und gibt den SQLCODE -911 (SQLSTATE 40001) mit

Reasoncode 2 an die aufrufende Anwendung

zurück. Der DBM macht „non commited“

Transaktionen aus dem Prozess automatisch

rückgängig (ROLLBACK). Sind die Rollback-

Operation beendet, werden Sperren, die zum

Prozess gehörten, freigegeben und die anderen

am Deadlock beteiligten Prozesse können

fortfahren.

Zur Gewährleistung einer guten Leistung

muß man einen geeigneten Wert für den

Konfigurationsparameter dlchktime aus-

wählen. Ein zu kurzes Intervall verursacht

unnötigen Systemaufwand, ein zu langes

Intervall lässt zu, dass Deadlocks eine

Weile bestehen bleiben.



Aug2012 68


DB2 erlaubt 4 Ebenen von Locking

• Tablespace

• Partition (für “partitioned table spaces”)

• Table (für “segmented table spaces”)

• Page

• Row

Hohe Performance

Hohe Parallelität

„Positioned Updates/Deletes“ können zum Problem werden

Aug2012 69


DB2® Prozesse fordern oder vermeiden die Anforderung von Locks abhängig von bestimmten generellen Parametern. Um

die Datenintegrität sicherzustellen, verarbeitet ein Applikationsprozess Locks implizit unter der Kontrolle von DB2.

Es ist für einen Prozess nicht erforderlich, explizit einen Lock anzufordern, um “uncommitted data” zu verstecken. Deshalb

machen Sie sich keine Sorgen um DB2 Locks. Aber Sie können dazu beitragen, dass Ressourcen besser genutzt und

Parallelverarbeitung gefördert wird, indem Sie verstehen welchen Effekt die Parameter haben, mit denen DB2 Locks

kontrolliert.

“Concurrency” und Locks Definition: Concurrency ist die Fähigkeit, dass mehr als eine Applikation dieselben Daten zur

annähernd gleichen Zeit zugreifen kann.

Promotion grundlegender “concurrency”: Bei Befolgen von grundlegenden Empfehlungen kann man “concurrency” im DB2

System favorisieren.

Aspekte von “transaction locks”: Das Verständnis von Größen/Ebenen, Dauer, Modus und Objekten von “transaction locks”

hilft, zu verstehen, warum ein Prozess wartet oder auf “timeout” läuft bzw. auf “deadlock” geht und wie man diese Situation

ändern kann

Optionen zum “Tuning von Locks”: Bestimmte Optionen haben Einfluss darauf, wie DB2 mit “transaction locks”

umgeht(Anzahl “rows” pro Transaktion, Anzahl Locks pro TS etc.).

Kontrolle von DB2 Locks für LOBs/XML: Messungen helfen, zu erfahren, wie DB2 mit Locks auf LOB Daten und XML

Daten umgeht.. .

“Claims” und “drains” zur Kontrolle der “concurrency”: DB2 Utilities, Kommandos und einige ALTER, CREATE und

DROP Statements können den Zugriff auf bestimmte Objekte übernehmen, unabhängig von irgendwelchen Transaktionslocks

auf dem Objekt..

Programmierung von parallelfähigen Anwendungen

Aug2012 70


Achten Sie auf “user lock escalation”

Sammelt ein einzelner User mehr “lock”-Einträge in Der LOCKLIST als erlaubt, so wird das Programm über einen -904

SQLCODE informiert. Das Programm kann nun einen ROLLBACK absetzen und eine Meldung ausgeben, um eine höhere

COMMIT Frequenz zu erhalten oder die Lock-Strategie haben zu eskalieren: LOCK TABLE Statement.

Man sollte sich jedoch im Klaren sein, was ein LOCK TABLE verursacht, bevor man ihn auslöst.

Achten Sie auf die “lock promotion”

Bindet man ein Package mit ISOLATION RR, so entscheidet der Optimizer zuweilen, dass ein Table Lock besser für die

Performance sei als “row locks”. Dann hebt der Optimizer das “locking level” auf “table locking”, ohne Rücksicht auf die

Angabe im LOCKSIZE Parameter aus der DDL. Dieser Vorgang heisst: “lock promotion”.

Zur Kontrolle der “lock escalation” sollten DBM/DB Parameter verwendet werden

Die DBM/DBParameter für Locking-Kontrolle in DB2 definieren den Schwellwerte für der Anzahl “row locks”, die parallel für

eine Tabelle/TS über eine einzelne DB2 Applikation (“thread”) gehalten werden dürfen. Danach eskaliert DB2 alle “locks” für

Objekte mit LOCKSIZE ANY nach folgender Regel:

Alle “row locks” auf Daten werden auf “table locks” eskaliert.

Wird der Schwellwert für die maximale Anzahl von “row locks”, die von einer einzelnen DB2 Applikation gleichzeitig gehalten

werden können, erreicht und die Applikation fordert weitere Locks an, erhält sie eine Meldung “ressource not available”

(SQLCODE of -904).

Anleitung und Anmerkungen zum Locking

Aug2012 71



Nutzen Sie LOCK TABLE mit Vorsicht

Nutzen Sie LOCK TABLE, um die Effizienz des Locking in Programmen, die viele “page lock requests” setzen, zu steigern.

Es gibt zwei Typen von LOCK TABLE:

LOCK TABLE...IN SHARE MODE (S-lock auf alle genannten Tables )

LOCK TABLE...IN EXCLUSIVE MODE (X-lock auf die Tabelle im Statement)

Die “table locks” aus dem LOCK TABLE Statement werden gehalten bis zum nächsten COMMIT Punkt.

Fördern Sie “lock avoidance”

Um DB2 zu veranlassen, Locks zu vermeiden, sollte man folgendes versuchen:

• Wann immer praktikabel ISOLATION(CS) beim BIND (Package/Plan) angeben

• Vermeiden von „ambiguous cursors”, indem man FOR READ ONLY (FOR FETCH ONLY) setzt, wenn

der Cursor nicht dazu gedacht ist, Daten zu modifizieren.

Achten Sie auf “concurrent access” mit Partitionsunabhängigkeit

“Partition independence” ermöglicht es, mehr Jobs/Prozesse parallel zu fahren. Diese Fähigkeit kann Systemressourcen

belasten. Und so sollte man CPU Nutzung und I/O Verhalten genau beobachten, bevor man parallele Jobs einsetzt. Es kann

auch sein, dass man dann einige der Jobs wieder serialisieren muss.

Sehen Sie genau hin, wenn Sie einen Cursor WITH HOLD definieren

CURSOR WITH HOLD verursacht Locks und “claims”, die über den COMMIT-Punkt hinaus gehalten werden. Dies kann die

Anzahl von “timeouts” erhöhen und die Verfügbarkeit beinträchtigen. Bevor man die Klausel WITH HOLD in einem Cursor

einsetzt, sollte man sicher sein, damit auch Laufzeitvorteile zu erhalten.

Aug2012 72



Greifen Sie Tabellen, wenn möglich in derselben Reihenfolge zu

Designen Sie alle Programme so, dass Tabellen in derselben Reihenfolge zugegriffen werden können. Dies verringert die

Wahrscheinlichkeit von “deadlocks”:

Program 1 Program 2

Lock on DEPT Lock on EMP

Request Lock on EMP Request Lock on DEPT

In diesem Fall erfolgt ein “deadlock”. Aber, wenn beide Programme erst DEPT, dann EMP zugreifen, kann die “deadlock”-

Situation vollständig vermieden werden.

Designen Sie Anwendungen mit dem Hintergrund des Lock-Aufwands

Minimieren Sie den Effekt von Locking durch ein angemessenes Design der Anwendungsprogramme. Begrenzen Sie die

Anzahl “rows” durch Einsatz von genauen Prädikaten, die alle

ungewollten “rows” ausfiltern. Dies verringert die Anzahl von Locks,

auf Pages, die zwar zugegriffen, aber nicht benötigt werden ebenso,

wie “timeouts” und “deadlocks”.

Zudem sollte man Programme mit Update Aktionen so entwerfen,

dass der UPDATE so nahe am COMMIT Punkt verarbeitet wird,

wie nur möglich. Dies wiederum reduziert die Zeit, die Locks in einer

“unit of work” gehalten werden, was ebenfalls die Wahrscheinlichkeit

von “timeouts” und “deadlocks” verringert.

Aug2012 73


Kapitelinhalt



Beispiele


Scope of cursors




Sperrmechanismen



SAVEPOINTs

Aug2012 74

DB2 for LUW DB2 for LUW –– COMMIT / ROLLBACK / SAVEPOINTsCOMMIT / ROLLBACK / SAVEPOINTs

COMMIT - Unit of work(LUW) / Unit of Recovery(UoR)

Als “logical unit of work” in einer Applikation bezeichnet man ein “set of SQL” Statements, das einen

“business process” ausmacht. Jeder Fehler während einer “logical unit of work”, erfordert einen

ROLLBACK aller Modifikationen in dieser LUW, damit die DB bezüglich der Geschäftsregeln

konsistent bleibt. Auch nach dem Ende einer LUW sollen die Daten, die in einem Geschäftsprozess

manipuliert wurden, konsistent sein.

Eine “unit of recovery” stellt die Menge an UPDATE, DELETE und/oder INSERT Statements, die

von einem “point of consistency” zu einem anderen Applikationsprozess ausgeführt werden/wurden, dar.

Eine “unit of recovery” beginnt mit der ersten Änderung der Daten, nach Anlauf des Jobs oder in der

Folge auf den letzten “point of consistency” und endet am “commit point”.

Commit

Alle Applikationsprozesse, die Locks anfordern und einige Sekunden laufen, sollten periodisch COMMITs

durchführen. Die die Gründe für COMMITs:

• Jeder Prozess, der DB2 modifiziert, fordert Locks auf Objekten an und verhindert dadurch, dass

andere Prozesse diese Objekte frei zugreifen können. Werde3n diese Locks unn ötig lange gehalten, so

leidet die Parallelverarbeitung in DB2. Exzessiv lange Lockdauer führt zu “deadlocks” und “timeouts”.

• Jeder Prozess, der auf DB2 zugreift - inklusive von “read-only” Anwendungen – legen “claims” auf

Objekte, die verhindern, dass “drains” beendet werden können. “Drains” werden typischer Weise von

Utilities, die dafür sorgen sollen, dass “database objects” kontinuierlich verfügbar sind, eingesetzt.

Aug2012 75


Commit (cntn‘d)

• In gut designten Umgebungen werden die meisten “read-only applications” keine “page” bzw. “row” -

Level Locks anfordern. Sie versuchen “lock avoidance”. Ein Ansteigen der Anzahl oder der Dauer von X

Locks im System wird jedoch die Möglichkeiten von “lock avoidance” verringern. Die Anforderung von

zusätzlichen Locks wird sich auf die “elapsed time” von “read-only transactions” auswirken und die

Last im RLM Umfeld erhöhen, was wiederum zu einer Verschlechterung der gesamten System

Performance führen wird.

• Wann immer ein “batch program” abnormal beendet oder ein System Fehler auftritt, wird DB2 die

Änderungen an den Daten, die nicht “committed” wurden, zurücksetzen. Werden keine COMMITs

abgesetzt, so kann die Datenmenge für den “backout” sehr groß sein und der Prozess lange dauern. Der

Restart wird außerdem alle UPDATEs erneut anstoßen. Eine höhere Frequenz von COMMITs reduziert

das Datenvolumen für ROLLBACKs und den Aufwand beim Restart.

• COMMITs in einem “batch process” erfordern es, dass eine Applikation für Restart designed sein muss. .

Ein COMMIT beendet eine “unit of recovery” und bestätigt alle “database updates”, die in der “unit

of recovery” getätigt wurden. DB2 führt bei einem COMMIT folgende Aktionen durch:

(1) Alle “page” / “row” Locks werden freigegeben – mit Ausnahme derer, die von einem offenen Cursor

mit der Klausel WITH HOLD gehalten werden

(2) Ist die RELEASE(COMMIT) BIND Option gesetzt, so werden alle Tabellen- TS- und Partition Locks

freigegeben außer denen, die von Cursors mit WITH HOLD gehalten werden

Aug2012 76


Commit (cntn‘d)

(3) Alle “claims” werden freigegeben - außer ….WITH HOLD

(4) Bei RELEASE(COMMIT) werden auch alle Statistiken , die von einem “index look-aside” und/oder

einem “sequential detection” Prozess gehalten werden, weggeworfen

(5) Bei RELEASE(COMMIT) werden auch alle vom “thread” erstellten IPROCs bzw. UPROCs gelöscht

(6) Ein “write” wird aus dem Log Buffer auf die “active logs” veranlaßt. Die Zeit, die für diesen

“immediate write” der Log Buffer benötigt wird, hängt von der Menge der Daten, die seit dem letzten

“log wirte” verändert wurden, ab . Das Streuen der “updates” über die gesamte “unit of recovery”

erhöht die Chance, dass die Log-Daten bereits geschrieben sind, wenn der COMMIT erfolgt.

Das Aufsparen aller “update”, “insert” und “delete” Aktivitäten bis zum Zeitpunkt unmittelbar VOR dem

COMMIT kann die Sperrdauer minimieren. Es kann aber auch dazu führen, daß die Menge der zum

COMMIT-Zeitpunkt zu schreibenden Log-Daten ansteigt und der COMMIT-Vorgang des halb länger

dauert.

UPDATE COUNTER_TBL SET SEQ_NBR = SEQ_NBR + 1

SELECT SEQ_NBR INTO :SEQ_NBR

-- Application processing logic inserting into ORDER table for example

COMMIT -- the end of the transaction

Aug2012 77


Commit (cntn‘d)

Probleme, wenn kein COMMITkein COMMIT gesetzt wird:

•• Pages im BPPages im BP bleiben reserviert Erreichen des Buffer-Thresholds

•• LockLock--Table / LockTable / Lock--ListList (von RLM verwaltet) bläht sich auf und kann überlaufen

•• LogLog--EinträgeEinträge müssen gehalten werden (Problematisch, wenn die Einträge nicht mehr auf dem aktiven Log

vorhanden, sondern bereits archiviert sind)

•• Langläufer mit AbbruchLangläufer mit Abbruch verursachen lange ROLLBACKlange ROLLBACK--ZeitenZeiten und einen großen ROLLBACK-Aufwand

•• Langläufer sperren veränderte Ressourcen Langläufer sperren veränderte Ressourcen innerhalb der UoW bis zur Verhinderung des beabsichtigten

Parallelbetriebs

... Deshalb ist der Einsatz von COMMIT‘s zu empfehlenDeshalb ist der Einsatz von COMMIT‘s zu empfehlen ... Deshalb ist der Einsatz von COMMIT‘s zu empfehlenDeshalb ist der Einsatz von COMMIT‘s zu empfehlen

ODER ????ODER ????

Aug2012 78


Commit (cntn‘d)

Der Einsatz von COMMITCOMMIT ist dringend zu empfehlen, bringt aber nicht nur Vorteile !

•• Die Anwendung wird in logische Abschnitte unterteilt, Die Anwendung wird in logische Abschnitte unterteilt, für deren Synchronisation der Entwickler verantwortlich ist.

Regel:Regel: COMMIT nur nach Abschluss einer logischen Arbeitseinheit

-- Nach Bearbeiten jedes n.ten KundenNach Bearbeiten jedes n.ten Kunden

-- Ein COMMIT löst alle Sperren aufEin COMMIT löst alle Sperren auf

-- Bei Abbruch sind sofort ALLE Ressourcen wieder frei Bei Abbruch sind sofort ALLE Ressourcen wieder frei (trotz „partial“ COMMIT)

•• Das Programm Das Programm muss generell restartfähig sein

-- DB2 Tabellen müssen positioniert werdenDB2 Tabellen müssen positioniert werden

-- Evtl. bringen sequentielle Bestände Probleme Evtl. bringen sequentielle Bestände Probleme (wegen Synchronisation mit COMMITCOMMIT)

Lösung:Lösung: CLOSE des Bestandes direkt VOR dem COMMIT oder

keine Ausgabe sequentieller Bestände auf DB2-Tabellen oder zwei Schritte

-- Bei Abbruch sind sofort ALLE Ressourcen wieder frei Bei Abbruch sind sofort ALLE Ressourcen wieder frei (trotz „partial“ COMMIT)

•• Ein COMMIT kann offene Cursor Ein COMMIT kann offene Cursor schliessenschliessen

- Result Table und Positionierung gehen verloren

Wann wird eine eine UoWUoW beendet?

•• Explizit:Explizit: durch ein entsprechendes Kommandodurch ein entsprechendes Kommando

•• Implizit: Implizit: mit Ende des Programms(Thread bzw. Task)mit Ende des Programms(Thread bzw. Task)

Aug2012 79


Commit (cntn‘d)

Das Setzen von COMMIT-Punkten kann in einem “Langläufer” dazu führen, dass der CPU-Aufwand und

auch der Aufwand für das Schreiben der LOCKs steigt.

Aber man gewinnt auch:

• Reduzierte “lock contention” besonders

in “DPF environments”

• Verbesserte Effektivität bei der “lock

avoidance” auch hier besonders in

“DPF environments”

• Reduktion der “elapsed time” bei einem

DB2 System Restart nach Systemfehler

• Reduktion der “elapsed time” für einen

Rollback einer “unit of work”, nach einem

Anwendungsfehler, oder einem gezielten

ROLLBACK.

• Mögliche Parallelverarbeitung mit

Utilities wie beispielsweise dem „online

REORG“.

DB2 - Subsystem Logging

DB2-Katalog DB2-Daten Log-Dateien

RLM

DPF

Facility

Runtime

System Transaction

Monitor1 TM2 Batch

Aug2012 80


Commit (cntn‘d)

Wirkungen am Ende einer UoW:

•• Freigabe sämtlicher Freigabe sämtlicher ResultResult TablesTables und und WorkWork--FilesFiles, sowie , sowie BufferBuffer--BereicheBereiche

-- Ausnahme:Ausnahme: Cursor mit WITH HOLD

Dabei bleiben auch TEMP-Tables erhalten (!)

•• Freigabe Freigabe sämtlicher Sperrensämtlicher Sperren

-- Ausnahme:Ausnahme: . für Cursor mit WITH HOLD werden „X“- oder „U“-Locks auf „S“ gesetzt

. alle „prepared statements“ bleiben erhalten

. LOCK TABLE-Sperre bei entspr. BIND Parameter

•• Abschluss der Abschluss der UoRUoR auf dem auf dem aktiven LOGaktiven LOG: Damit endet die ROLLBACK: Damit endet die ROLLBACK--FähigkeitFähigkeit

•• Freigabe der mit PREPARE aufbereiteten Freigabe der mit PREPARE aufbereiteten dynamischen SQLdynamischen SQL--StatementsStatements

•• Freigabe der zur Freigabe vorgemerkten Freigabe der zur Freigabe vorgemerkten ConnectionsConnections

... gibt es gibt es ... Zu den letzten beiden Zu den letzten beiden freigegebenen Ressourcen freigegebenen Ressourcen gibt es gibt es

zusätzliche Bedingungen(siehe DB2 Manuals)zusätzliche Bedingungen(siehe DB2 Manuals)

Aug2012 81


Commit (cntn‘d)

Verwenden Sie in allen (Batch-)

Programmen, die Tabellen ändern, ein

standardisiertes Checkpoint/Restart

Verfahren.

regelmäßig Commit-Punkte (etwa alle

1000 - 5000 Änderungen ist -

GROSSZÜGIG!!! )

Die Frequenz sollte einstellbar sein.

Checkpoint/Restart Verfahren auch in

kurzlaufende Programme oder ‘Einmal-

programme’ einbauen.

Häufig werden aus diesen Kurzläufern in

Sonderaktionen oder durch Daten-wachs-

tum Endlosprogramme, die stundenlang

ohne Commits laufen. Dadurch wird das

DB2 übermäßig belastet, die eigenen und

andere Anwendungen werden behindert. Im

Fehlerfall kann Rollback sehr lange dauern.

Ein Wiederaufsetzen am Anfang eines

Cursors bedeutet zusätzlichen Zeitverlust

und Ressourcenverbrauch. Die Option

WITH HOLD beim DECLARE CURSOR

oder probate Wiederaufsetzverfahren

sollten genutzt werden

Transaktionsmonitor „runtime“ System DB2

Transaktion 1

SELECT

(1. SQL-Aufruf)

Transaktion 2

SELECT

(1. SQL-Aufruf)

INSERT

Syncpoint/

Checkpoint

UPDATE

UOW

UOW1

UOW2

Ende der Transaktion COMMIT

Thread A UOR keine, da

keine Mani-

pulation

der Daten

COMMIT

Ende der Transaktion COMMIT

Thread B

UOR1

UOR2

Dialog 3

SELECT

(1. SQL-Aufruf)

INSERT

UPDATE

DELETE

Linux/Unix kennt

kein UOW-Konzept

Dialogende COMMIT

Thread C

UOR

Aug2012 82

DB2 for LUW DB2 for LUW –– SAVEPOINTsSAVEPOINTs

Was ist ein „savepoint“ ?

Ein "savepoint" ist ein mit Namen versehenes "entity" das den Status eines Datenzustandes zu einem bestimmten

Zeitpunkt innerhalb einer "logical" UoW repräsentiert.

"savepoints" können gesetzt und freigegeben werden.

Es ist möglich einen "rollback" der Daten zu dem Status durchzuführen, den der benannte "savepoint" repräsentiert.

Ein "rollback" setzt alle "savepoints", welche nach dem "savepoint" auf den wir zurücksetzen, gesetzt wurden, zurück.

Daten (DML) und Schema (DDL) Änderungen durch die Transaktion, nachdem eine "savepoint" gesetzt ist kann zu dem

"savepoint“ zurückgesetzt werden, zu dem es die logische Anwendung benötigt. Das allgemeine Ergebnis einer Transaktion

wird davon nicht beeinträchtigt. Es gibr keine Grenze bezüglich der Anzahl von "savepoints" die gesetzt werden können. Der

Geltungsbereich eines „savepoint" ist abhängig vom DBMS auf welchem er gesetzt wurde.

Warum "savepoints" nutzen ?

"savepoints" ermöglichen die Kodierung von Zusammenhängen, oder von „what-if“ – Logiken.

Sie sind brauchbar für Programme mit intelligenter Fehlerbehandlung, oder für „stored procedure“-Updates, wenn ein

Fehler aufgetreten ist und nur die Änderungen der „stored procedure“ mit „rollback“ behandelt werden sollen.

Der Verwaltungsbedarf eines "savepoint" ist klein (Messungen zeigen, dass die Kosten eines "savepoint" mit einem

einfachen „fetch“ gleichzusetzen sind).

Die Freigabe eines "savepoint" soll aus Sicht der Anwendung und deren logischer Perspekive erfolgen.

COMMITs und SAVEPOINTs

Aug2012 83


Beispiele für einen „savepoint“ ?


Ein gutes Beispiel für die Verwendung von "savepoints" ist der Vorgang von Flugbuchungen:

John D. aus Australien plant einen Urlaub in Dänemark. Er bittet den Vertreter eines Reisebüros die Flüge zu buchen. Maximum 4 Abschnitte

(3 Stops) für beide Richtungen. Er verlässt Alice Springs, Australien und fliegt nach Melbourne. Von Melbourne aus kann er nach Singapur

und von dort nach Kopenhagen fliegen, oder über Kuala Lumpur und Amsterdam nach Kopenhagen. Das Bild zeigt die möglichen zu

fliegenden Strecken von A lice Springs nach Kopenhagen.

• erst machen wir die Flugreservierung nach

Melbourne und definieren einen „savepoint"

#FIRSTSTOP.

• dann reservieren wir den Flug nach Singapor

und definieren einen "savepoint" namens

#SECONDSTOP.

• Nun stellen wir fest, dass von Singapor nach

Kopenhagen keine Plätze frei sind.

• wir setzen ROLLBACK TO SAVEPOINT

#FIRSTSTOP, da wir die Reservierung nach

Melbourne nicht verlieren wollen.

• dann wir machen die Reservierung nach

Kuala Lumpur und setzen einen "savepoint"

namens #SECONDSTOP.

• und nach Amsterdam mit "savepoint"

#THIRDSTOP.

Aug2012 84


Beispiele für einen „savepoint“ ?


• und nach Kopenhagen mit "savepoint" #DESTINATION. Jetzt sind wir an unserem Bestimmungsort und haben nicht mehr als 3

Stops eingelegt. Wir können alle "savepoints" außer #DESTINATION freigeben.

• nun versuchen wir die Rückkehr-Reservierung erst nach Singapur mit einem "savepoint" #FIRSTSTOP.

• Es gibt keine Plätze von Singapor nach Melbourne und wir benötigen einen ROLLBACK TO SAVEPOINT #DESTINATION.

Das ist Kopenhagen. Der Rollback gibt auch den #FIRSTSTOP "savepoint" frei.

• dann versuchen wir die Reservierung von Kopenhagen nach Amsterdam mit einem "savepoint" #FIRSTSTOP

• und nach Kuala Lumpur mit "savepoint" #SECONDSTOP.

• und nach Melbourne mit "savepoint" #THIRDSTOP.

• wenn die Reservierung von Melbourne nach Alice Springs fehlschlägt, möchten wir die ganze Reservierung mit ROLLBACK

zurücksetzen; d.h. an den Anfang einer dem "logical" UoW. Wenn wir ein Platz nach Alice Springs finden können und die Anzahl der

Stops nicht mehr als 3 beträgt, können wir die UOW mit COMMIT abschliessen.

Dieses Beispiel zeigt dass es manchmal einen Bedarf nach zusätzlichen Zeitpunkten für "rollback" gibt. Sie ändern nicht die Logik - noch

die Notwendigkeit – von COMMITs.

"savepoint" Merkmale

Das SAVEPOINT Statement wird zum Setzen eines "savepoint" verwendet. Nach Ausführung sollte man den SQL-Returncode genau

prüfen, um sicherzustellen, dass der "savepoint" auch wirklich gesetzt ist. Es ist auch empfehlenswert, einen möglichst sprechenden

Namen zu wählen (maximale Länge 128 Bytes). „savepoint“-Statements und verwandte Angaben ( SAVEPOINT, ROLLBACK TO

SAVEPOINT und RELEASE SAVEPOINT ) können von einem AP oder von einer „stored procedure“, die mit MODIFIES SQL

DATA definiert ist, gesetzt werden. Diese Statements können nicht verwendet werden,

• während einer „User Defined Function (UDF)“

• innerhalb eines Triggers

Aug2012 85



"savepoint" Merkmale

WICHTIG:WICHTIG: "savepoints" sind kein Ersatz für COMMITs. Beispiel: Einstellen eines "savepoint"

EXEC SQL SAVEPOINT START_OVER

UNIQUE

ON ROLLBACK RETAIN CURSORS

ON ROLLBACK RETAIN LOCKS ;

Tip: Man kann einen "savepoint", der als UNIQUE spezifiziert ist, wiederverwenden, wenn der frühere "savepoint" mit gleichem Namen

vor der Wiederverwendung freigegeben wurde ( durch die Verwendung eines ROLLBACK oder eines RELEASE SAVEPOINT ).

"savepoint" Einschränkungen

• keine "savepoints" in „global transactions“.

• keine "savepoints" in „triggers“.

• keine "savepoints" in UDF.

• keine "savepoints" in „stored procedures“ die von einem „trigger“ oder einer UDF gerufen wird.

• „rollback“ auf einen "savepoint" annulliert nicht die Änderungen auf temporären Tabellen.

• „rollback“ auf einen "savepoint" gibt keine „locks“ frei.

• Die Cursorposition ändert sich nicht, bei „rollback“ auf einen "savepoint".

• "savepoint" Namen können nicht über Host-Variablen spezifiziert sein.

ROLLBACK

Aug2012 86



Aug2012 87


COMMITs - Zusammenfassung

Achten Sie aufAchten Sie auf

• Effiziente Bereitstellung der Result Result TablesTables

• Konsistentes und ressourcenschonendes Anzeigen von Anzeigen von

ErgebnissenErgebnissen

• Konzeption der UoW‘sUoW‘s

•• Effiziente WiederaufsetzEffiziente Wiederaufsetz--TechnikenTechniken bei Cursorverarbeitung

• Möglichkeiten die SuchtechnikenSuchtechniken zu verbessern

• Queueing bei asynchroner Verarbeitungasynchroner Verarbeitung

• Sinnvollen Einsatz von Einsatz von COMMIT‘sCOMMIT‘s

•• Konkurrierende UPDATEKonkurrierende UPDATE-Situationen

• Vermeiden von DEADLOCK‘sDEADLOCK‘s

... Alles das gehört zu effizienten DB2... Alles das gehört zu effizienten DB2--Anwendungen ....Anwendungen ....

Aug2012 88


Kapitelinhalt







• DB2 Utilities und Statistiken und Systemkommandos


Aug2012 89

DB2 for LUW DB2 for LUW –– Die Funktion EXPLAINDie Funktion EXPLAIN

EXPLAIN Statement

Das Statement EXPLAIN eruiert Informationen aus dem “access plan”, die vom Optimizer für das

entsprechende SQL-Statement zusammengestellt werden.Die Daten werden in den “explain tables” abgelegt.

Ein “explainable statement” ist

• ein gültiges XQuery Statement

• Eines der folgenden SQL Statements: CALL,

Compound SQL (Dynamic),

DELETE, INSERT, VALUES, VALUES INTO…, MERGE, UPDATE,REFRESH, SELECT, SELECT INTO,

SET INTEGRITY,

Aufruf

Das Statement kann in einem “application program” stehen oder interaktiv aufgerufen werden. EXPLAIN ist

ein ausführbares Statement, das dynamisch “prepared” werden kann.

Das Statement , das “explained” wird, wird nicht ausgeführt

Beschreibung diverser Parameter

“PLAN SELECTION” zeigt an, dass Informationen aus der Phase “plan selection” bei der Query Kompilierung in die “explain

tables” eingetragen werden soll.

ALL ist ein Equivalent zu PLAN SELECTION.

PLAN Die Option PLAN soll Syntax-Kompatibilität mit anderen DB-Systemen herstellen

Aug2012 90


EXPLAIN Statement (cnt’nd)

Beschreibung diverser Parameter

FOR SNAPSHOT zeigt an, dass nur ein “explain snapshot” gezogen und in die SNAPSHOT Spalte der Tabelle

EXPLAIN_STATEMENT geschrieben werden soll. Es wird keine weitere EXPLAIN Information aufgezeichnet als die,

aus den Tabellen EXPLAIN_INSTANCE und EXPLAIN_STATEMENT.

Die “explain snapshot information” ist für die Nutzung im Visual Explain gedacht.

WITH SNAPSHOT gibt an, dass zusätzlich zur allgemeinen “explain information” noch eine “explain snapshot” gezogen

werden soll. Das “default” Vderhalten des EXPLAIN Statement ist, keinen “explain snapshot” zu erstellen.

default (weder FOR SNAPSHOT noch WITH SNAPSHOT ist angegeben) schreibt die “explain” Informationen in die “explain

tables”. Es wird kein “snapshot” für die Nutzung mit Visual Explain erstellt. .

SET QUERYNO = <integer > belegt das Feld QUERYNO in der Tabelle EXPLAIN_STATEMENT mit einer angegebenen

Nummer, um das entsprechende Statement bei der Analyse wiederfinden zu können. Bei einem “static” EXPLAIN

Statement ist der “default”-Wert die “statement number” aus dem entsprechenden Precompiler.

SET QUERYTAG = <string-constant> belegt das Feld QUERYTAG in der Tabelle EXPLAIN_STATEMENT mit einer

angegebenen Zeichenfolge , um das entsprechende Statement bei der Analyse wiederfinden zu können. Es können

beliebige Zeichen bis zu 20 Bytes Länge verwendet werden. Default sind <blanks>.

FOR <explainable-sql-statement> zeigt das SQL Statement, das “explained” werden soll. Das kann ein beliebiges, gültiges

Statement sein (s.o).

Aug2012 91


Beispiele

(1) Explain eines einfachen SELECT Statement ujnd Kennzeichnung mit QUERYNO = 13.

EXPLAIN PLAN SET QUERYNO = 13 FOR SELECT C1 FROM T1

(2) Explain eines einfachen SELECT Statement ujnd Kennzeichnung mit QUERYTAG = 'TEST13'.

EXPLAIN PLAN SELECTION SET QUERYTAG = 'TEST13' FOR SELECT C1 FROM T1

(3) Explain eines einfachen SELECT Statement ujnd Kennzeichnung mit QUERYNO = 13 und QUERYTAG = 'TEST13'.

EXPLAIN PLAN SELECTION SET QUERYNO = 13 SET QUERYTAG = 'TEST13' FOR SELECT C1 FROM T1

(4) Versuch EXPLAIN Information zu erhalten, wenn die EXPLAIN Tabellen nicht existieren:

EXPLAIN ALL FOR SELECT C1 FROM T1

Fehler: SQLSTATE 42704.

(5) Das folgende Statement funktioniert, wenn es im “package cache” gefunden wird und mit REOPT ONCE kompiliert wurde.

EXPLAIN ALL WITH REOPT ONCE FOR SELECT C1 FROM T1 WHERE C1 = :<host variable>

(5) Diese Beispiel nutzt die Funktion db2-fn:xmlcolumn, die den “case- sensitiven” Namen einer XML Spalte als Argument b

esitzt und eine XML “sequence” bestehend aus einer “concatenation” von XML Spaltenwerten zurückgibt.

Die tabelle heisst BUSINESS.CUSTOMER mit der XML Spalte INFOEine einfache Xquery, die alle Dokumente aus der

Spalte INFO liefert lautet :

EXPLAIN PLAN SELECTION FOR XQUERY 'db2-fn:xmlcolumn ("BUSINESS.CUSTOMER.INFO")'

Ist ein Spaltenwert NULL, so ist die “return sequence” der entsprechenden “row” leer.

Aug2012 92


Explain tables

Die “explain tables” erhalten Informationen des Zugriffspfads, wenn der EXPLAIN aktiviert ist. Die

“explain tables” müssen VOR Ausführung des EXPLAIN angelegt werden. So geht’s:

(1) Aufruf der Prozedur SYSPROC.SYSINSTALLOBJECTS:

db2 CONNECT TO database-name db2

CALL SYSPROC.SYSINSTALLOBJECTS ('EXPLAIN‘

, 'C‘

, CAST (NULL AS VARCHAR(128))

, CAST (NULL AS VARCHAR(128)))

Erzeugt alle “explain tables” im Schema SYSTOOLS . Um sie unter einem anderen Schema zu erzeugen,

spezifziert man einen “schema name “ als letzten Parameter im Call.

(2) Ausführen der EXPLAIN.DDL DB2® “command file”:

db2 CONNECT TO database-name db2 -tf EXPLAIN.DDL

Erzeugt alle “explain tables” im aktuellen Schema. Die Datei liegt im Directory DB2PATH\misc directory

bei Windows Systemen und in INSTHOME/sqllib/misc directory bei Linux und UNIX

Betriebssystemen. DB2PATH ist der Pfad, auf dem die DB2 Kopie installiert ist und INSTHOME ist das

“instance home directory”.

Das Explain facility nutzt folgende IDs als Schema, wenn die “explain tables” geschrieben werden:

• “session authorization ID” bei dynamischem SQL

• “statement authorization ID” bei statischem SQL

Aug2012 93


Explain tables

Das jeweilige Schema kann mit einem “set” von Explain Tabellen bestückt werden. Werden keine Schema-

bezogenen EXPLAIN-Tabellen angelegt, so sucht das “Explain facility” im Schema SYSTOOLS nach den

Tabellen.

Das Füllen der “Explain tables” durch die Funktion EXPLAIN aktiviert weder Triggers noch “referential”

bzw. “check constraints”. Beispiel: Ein “insert” Trigger auf der Tabelle EXPLAIN_INSTANCE und ein

EXPLAIN, der Einfügungen in diese tabelle verursacht, würde den Trigger nicht auslösen.

Die EXPLAIN Tables sind

ADVISE_INDEX table

ADVISE_INSTANCE table

ADVISE_MQT table

ADVISE_PARTITION table

ADVISE_TABLE table

ADVISE_WORKLOAD table

EXPLAIN_ACTUALS table

EXPLAIN_ARGUMENT table

EXPLAIN_INSTANCE table

EXPLAIN_OBJECT table

EXPLAIN_OPERATOR table

EXPLAIN_PREDICATE table

EXPLAIN_STATEMENT table

EXPLAIN_STREAM table

Aug2012 94


Explain Beispiel Access Plan:

-----------

Total Cost: 45835.2

Query Degree: 1

Rows

RETURN

( 1)

Cost

I/O

|

0.333333

NLJOIN

( 2)

45835.2

11880

/----------+-----------\

542955 6.13925e-07

FETCH FILTER

( 3) ( 5)

7202.28 28.3295

6848 4

/------+------\ |

107 1.62886e+06 1

IXSCAN TABLE: L4_FDB GRPBY

( 4) L4_FDB_GP_STAMM_ALLGEMEIN ( 6)

35.7012 Q7 28.3293

0 4

| |

1.62886e+06 0.5

INDEX: SYSIBM NLJOIN

SQL120824170333980 ( 7)

Q7 28.3293

4

/------+------\

Cardinality of the result of the

operator below (# of rows)

Operator name

Operator sequence number

cost

I/O cost

Aug2012 95


Explain Beispiel(contn’d)

4

/------+------\

1 0.5

IXSCAN FILTER

( 8) ( 9)

14.1645 14.1647

2 2

| |

1.62886e+06 1

INDEX: L4_FDB GRPBY

L4_FDB_GP_STAMM_AXX_U2_IDX ( 10)

Q4 14.1646

2

|

0.333333

IXSCAN

( 11)

14.1646

2

|

1.62886e+06

INDEX: L4_FDB

L4_FDB_GP_STAMM_AXX_U2_IDX

Q1

Ein IX führte hier zu einer Kostensenkung von 138.488 CPU auf 45.835,2 CPU-Kosten!

Aug2012 96


Kapitelinhalt









Aug2012 97

DB2 for LUW DB2 for LUW –– Performance & Tuning ( AP und SQL )

Der Optimizer und die Suche nach dem Zugriffspfad

SELECT d.name, sum(e.id), avg(e.compensation)

FROM employees e, departments d, projects p

WHERE d.location in (‘SVL’, ‘ARC’)

and d.id = e.dept

and e.id = p.employeeID

and p.class in (‘top secret’, ‘confidential’)

GROUP BY d.name

ORDER BY d.name

Annahmen:

– Index: ix1(d.location)

ix2(e.id), ix3(e.dept)

ix4(p.class)

– Cardinality:

card(e) = 300000

card(d) = 20000

card(p) = 50000

– Filtering factor:

FF(P1) = 1%,

FF(P4) = 10% # von „join sequences“ (3! = 6)

# von „access methods“ (RSCAN, ISCAN, Midx, etc)

# von „join methods“ (NLJ, SMJ, HBJ)

Gesamtzahl von Zugriffspfaden

Kostenschätzung (elapsed time)

Zugriffspfadwahl (kürzeste“elapsed time“)

Letztendlicher Zugriffspfad

Projects

Department

Employee

Aug2012 98


1.1. Holen Sie Holen Sie das absolute Minimum an Datendas absolute Minimum an Daten in die DB2 „Engine“in die DB2 „Engine“

Reduktion der Zeilenanzahl durch genaue Prädikate in der WHERE-Klausel, soweit möglich (Suche die kleinste „row“-Menge)

Reduktion der Spaltenanzahl, soweit sinnvoll und möglich (Lies nur die Spalten, die wirklich benötigt werden)

2.2. FilternFiltern Sie Sie alle „nonalle „non--qualifyingqualifying“ Daten“ Daten aus der aus der ResultatsmengeResultatsmenge

Vorgabe möglichst präziser Prädikate(Filtern) und ausschließlich Anforderung benötigter Daten (Kodiere Prädikate, die selektiv sind)

3.3. Geben Sie nur das Geben Sie nur das absolute Minimum an Daten an den „absolute Minimum an Daten an den „requestorrequestor““ zurückzurück

Formulieren möglichst wirksamer Prädikate (Nutze „stage1“-Prädikate)

4.4. Erledigen Sie die Erledigen Sie die Verarbeitung in der kleinsten Menge funktionaler SQLVerarbeitung in der kleinsten Menge funktionaler SQL--StatementsStatements

Formulieren kompakter und komplexer SQL-Statements (Reduziere die Anzahl der SQL-Statements)

5.5. Erledigen Sie Erledigen Sie soviel Funktionalität wie möglich im SQLsoviel Funktionalität wie möglich im SQL--StatementStatement (nicht im Programm)(nicht im Programm)

Grundsätzlich gilt:Grundsätzlich gilt: Alles, was nicht in Stage1 verarbeitet werden kann, wird in Alles, was nicht in Stage1 verarbeitet werden kann, wird in Stage2 erledigt.Stage2 erledigt.

Maxime bei SQL: Sei so selektiv wie möglich !Maxime bei SQL: Sei so selektiv wie möglich !

Aug2012 99


Performance&Tuning von DB2 SQL - Grundsätzliche Empfehlungen

(1) Definition von Vergleichsspalten mit gleicher Länge und gleichem Format

Definition von Vergleichsspalten mit gleicher Länge und gleichem Format (Achte auf Datentyp und –kompatibilität)

(2) Vornanstellen der effizientesten Filter-Prädikate

Effiziente Prädikate an den Anfang der WHERE-Klausel (Kodiere die selektivsten Prädikate zuerst)

(3) Anstreben einer möglichst effizienten Index-Unterstützung - Dabei auf Filterfaktoren und inhaltliche Streuung achten

(4) Erledigen Sie die Verarbeitung in der kleinsten Menge funktionaler SQL-Statements

(5) Bei Work-Files auf Mengengerüste achten. Work-Files werden in zentralen Multi-User-Ressourcen gehalten und sind daher besonders Performance-relevant

Work-Files sind zentrale Multi-User-Ressourcen und daher besonders performance-relevant (Prüfe alle SQL-Statements mit EXPLAIN)

(6) Grundsätzlich sollten ALLE lesenden SQL’s mit FOR FETCH ONLY versehen werden – soweit syntaktisch möglich.

(7) WITH UR ist beim Lesen meist OK, hat mit der FFO-Klausel aber nichts zu tun.

(8) WHENEVER mit GO TO ist in jedem Fall mit einer „ernsthaften“ Fehlerbehandlung zu ersetzten.

(9) Alle Cursor, die geöffnet wurden, sind auch wieder zu schließen.

Aug2012 100


Grundsätzliche Empfehlungen zum Fromulieren von SQL Staterments

(10) Überlegen Sie, ob Sie beim Durchlesen ganzer Tabellen nicht auf „multi row“-FETCH umstellen….(Performancegewinn beim Lesen bis zu 50%)

(11) Dasselbe gilt für den „multi-row“ INSERT, wenn grosse Mengen von Sätzen eingefügt werden sollen(Performancegewinn beim INSERT >15%)

(12) Wiederholbare oder redundante SQL Statements gibt es innerhalb eines Prozesses normalerweise nicht allzu viele. Aber geht man davon aus, dass ein Prozess mehrfach wiederholt wird, dann schon, z.B. täglich häufig angestoßene OLTP Transaktionen. Man stelle sich vor, eine Aktion, wie z.B. „SELECT current date“ wird pro Tag zwei millionenmal ausgeführt! – Da ist es besser das Spezialregister „SET :hv = CURRENT DATE“ zu verwenden – aber die gibt es nur im „embedded SQL“.

(13) Wenn die normale Verarbeitung durch mehrere funktionale Ebenen läuft, dann kann das SQL-Statement zu einem einzigen zusammengefasst werden, das alle Spalten zurückgibt. Manchmal jedoch ist es nicht offensichtlich, wo Redundanz eigentlich entsteht. – Es gibt keinen Fehler im SQL-Statement, aber es handelt sich um den klassischen Fall des so genannten „cut and paste“ SQL, was immer zu einem Desaster führen muss. In unserem Fall existieren in einem Programm drei Cursor. Jeder wird über „cut and paste“ vom Original aus aufgebaut. Jeder Cursor basiert auf einem eigenen „rule set“ und gibt ein anderes Resultat zurück. Das SQL dieser drei Cursor wird nun zu einem SQL SELECT zusammengefasst. Die Unterschiede der folgenden SQL SELECTs bestehen in der WHERE - Klausel und den Hostvariablen, die die Ergebnisse aufnehmen:

Aug2012 101


Grundsätzliche Empfehlungen zum Zusammenfassen von SQL Statements

SELECT Statement3:

SELECT SUM(cumqty) INTO :ws-cat-3 FROM kd_konto

ar

WHERE teile_typ = :ws-item-typ

AND teile_mengen-klasse = :ws-amount-class

AND gruppen# = :ws-group-num

AND teile_jahr = :ws-teile-jahr

AND transaktion_code IN ( 034, 100, 104, 105, 106, 332, 334, 341

)

AND transaktion_datum = ( SELECT MAX(transaktion_datum)

FROM kd_konto )

SELECT Statements(konsolidiert):

SELECT

SUM( CASE WHEN transaktion_code = 034 ... = 341 THEN cumqty END )



INTO :ws-cat-1, :ws-cat-2, :ws-cat-3

FROM kd_konto ar





AND transaktion_code IN ( 208, 400, 434, 441, 210, 211, 221, 223,

224, 225, 034, 100, 104, 105, 106, 332, 334, 341 )

AND transaktion_datum = ( SELECT MAX(transaktion_datum)

FROM kd_konto )

SELECT Statement1:

SELECT SUM(cumqty) INTO :ws-cat-1

FROM kd_konto ar





AND transaktion_code IN (208, 400, 434, 441)

AND transaktion_datum =

( SELECT MAX(transaktion_datum)

FROM kd_konto )

SELECT Statement2:

SELECT SUM(cumqty) INTO :ws-cat-2

FROM kd_konto ar





AND transaktion_code IN ( 210, 211, 221,

223, 224, 225 )

AND transaktion_datum =

( SELECT MAX(transaktion_datum)

FROM kd_konto )

Aug2012 102


Grundsätzliche Empfehlungen zum Formulieren von SQL Statements

(14) Viele "subqueries" sind in JOINs umformulierbar (Nutze JOINs anstatt „subqueries“)

(15) Existenzprüfungen sind oft effizienter als OUTER Joins (Nutze erprobte Methoden zur Existenzprüfung(EXISTS))

(16) Prüfen von Subqueries als einzelne Queries (Subqueries sind zu „tunen“)

(17) Vermeiden aufwendiger SQL-Statements (nur weil sie leichter zu verstehen sind als komplexe Formulierungen) (Vermeide UNIONs(ALL))

(18) SQLs entsprechend der gültigen (eingesetzten Version von DB2) formulieren (Benutze die ON-Klausel für alle JOIN-Prädikate)

(19) Überprüfen gererierter SQL-Statements (Verwende nie von Tools generiierte SQL-Statements)

(20) Nutzen neuer (kritischer) Funktionen bei Release-Wechseln und Einbau in bestehende Abläufe. (Sie können die Performance nachhaltig beeinflussen!)

Aug2012 103



“How NOT to Check for Existence”

SELECT COUNT(*) FROM AGT…. WHERE…

Oft ist dies der erste Versuch, wenn man über Existenzprüfungen nachdenkt.

Aber: Man will ja nur wissen, ob EINE “row” WENIGSTENS existiert oder nicht. Es gibt keinen Grund, dazu alle

betreffenden Sätze zu lesen und zu zählen.

Es gilt als häufig kommuniziertes Missverständnis der EXISTS Klausel, dass die Subquery beendet wird, sobald die

Existenz einer “row” festgestellt wird und es egal ist, ob eine “row” zur Ergebnismenge gehört oder Millionen!

Leider stimmt das so nicht. Das trifft nur dann zu, wenn die Subquery eine “correlated subquery” ist. Ist sie das nicht,

so kann eine solche Query in der Performance sogar noch schlechter sein als der SELECT COUNT(*). Sie verursacht ja

die Kosten des Zugriffs auf die sysibm.sysdummy1 und die Kosten für den Zugriff auf alle “rows”, die mit der

WHERE Klausel spezifiziert wurden..

SELECT 1 FROM SYSIBM.SYSDUMMY1 WHERE EXISTS (SELECT 1 FROM AGT…. WHERE… )

Existenzprüfungen

Aug2012 104



Existenzprüfungen - – „correlated“ vs „non-correlated“ Subqueries

SELECT STUDENT_NAME FROM STUDENT_TABLE

WHERE SCHOOLNUM = (SELECT SCHL_NO FROM SCHOOL_NAME_TABLE

WHERE NAME = ‘PALO VERDE’);

Wie schon erwähnt ist auch eine „non-correlated“ Subquery für die „existence“ Prüfung keine effiziente Alternative. Eine

„non-correlated“ Subquery hat, wie der Name schon sagt, keine Verknüpfung bzw. Referenz zur sogenannten „outer query”

SELECT STUDENT_NAME, CUM FROM STUDENT_TABLE A INNER JOIN GRADE_TABLE B

ON A.STUDENT_ID = B.STUDENT_ID

WHERE CUM = (SELECT MAX(CUM) FROM GRADE_TABLE C WHERE A.STUDENT_ID = C.STUDENT_ID);

Hier ist es nicht möglich, die “inner query” als erstes auszuführen, da die Werte der “outer query” noch nicht bekannt sind.

DB2 durchläuft in diesem Falle folgende Schritte:

1. Zugriff auf die “outer table” – über TS Scan oder Indexzugriff

2. Für jede qualifizierende “row” der “outer table” wird die Subquery gestartet

3. Übergabe der Resultate an die “outer query” –“row“-weise

4. Prüfen der “outer query” gegen die “inner query” Resultate – “auch “row”-weise

Es wird keinerlei Information aus der “outer query” benötigt, um die “inner query” ablaufen zu lassen. DB2 verarbeitet die

“inner query” zuerst, da die “outer query” von deren Resultat abhängt. DB2 durchläuft dafür folgende Schritte:

1. Zugriff auf die “inner table” – über TS Scan oder Indexzugriff

2. Sortieren der Resultate und Entfernen der Duplikate

3. Ablage des Resultats in einer Zwischentabelle

4. Zugriff auf die “outer table”, Vergleichen alle qualifizierenden “rows” mit denen in der Zwischentabelle

Aug2012 105



Existenzprüfungen

Machen wir also die „non-correlated query“ zu einer „correlated query“.

Sie erinnern sich noch ?????

Die Spalte IBMREQD ist die einzige Spalte der Tabelle SYSDUMMY1. Durch die Kodierung des “always true” Prädikates in der

Subquery, wird die Subquery nicht ausgeführt, bis die erste (und einzige) “row” von SYSDUMMY1 gelesen wird.

Jetzt funktioniert die EXISTS Klausel genauso wie erwartet. SYSDUMMY1 besitzt nur 1 “row”. Diese wird gelesen und dann die

“correlated subquery” ausgeführt.

Über die EXISTS Klausel wird beim ersten Treffer die Suche beendet und die Information TRUE an die „outer query“ gegeben.

Um das Thema zu ergänzen, sollte auch folgende Möglichkeit evaluiert wrde, vor allem dann, wenn eine reine Existenzprüfung durchgeführt

werden soll:

SELECT ‘Y’ FROM <table> T WHERE <col1> = :<hostvariable1> AND <col2> = :hostvariable2>

FETCH FIRST ROW ONLY

SELECT 1 FROM SYSIBM.SYSDUMMY1 X

WHERE EXISTS (SELECT 1 FROM AGT…. WHERE… AND X.IBMREQD = X.IBMREQD )

SELECT 1 FROM SYSIBM.SYSDUMMY1 WHERE EXISTS (SELECT 1 FROM AGT…. WHERE… )

Aug2012 106



Existenzprüfungen

“Existence check” mit OPTIMIZE FOR n ROWS….

EXEC SQL

DECLARE CURS-OPT CURSOR FOR

SELECT 1 FROM SSASIDB1.AATP_PERIOD_ATTEND WHERE ABSENCE_CODES LIKE '%AAA%'

OPTIMIZE FOR 1 ROW

END-EXEC.

Das folgende Messbeispiel zeigt, dass ein “optimized cursor”, ja sogar ein “non-optimized cursor” sich als schneller erweist

als eine WHERE EXISTS Klausel in unserem vorangegangenen Beispiel.

Das Beispielprogramm produzierte folgende Resultate:

• Exists Klausel mit “correlated subquery”: 6254 microseconds

• “Non-optimized” Cursor: 1726 microseconds

• “Optimized cursor”: 1121 microseconds

• Select count: 2 Minuten 14 Secunden

Manche Verfasser von SQL Performance Artikeln meinen wörtlich “For existence checking in V6 and earlier, the technique

of coding a cursor with OPTIMIZE FOR ONE ROW, opening the cursor, and simply fetching one row, has generally

proven to be the existence checking method that provides the best performance.”

Aber die Kodierung eines Cursors mit der Klausel OPTIMIZE FOR ONE ROW teilt DB2 mit, dass man beabsichtigt

lediglich die erste “row” abzuholen, ohne Rücksicht darauf, wieviele “rows” zurückgeliefert werden.

Der Optimizer wird Optimierungsfunktionen wie “List”- und “Sequential”-Prefetch ausschalten, abhängig davon, ob der

Zugriffspfad davon profitieren kann oder nicht. Ohne diese Klausel entscheidet sich der Optimizer für den effizientesten

Zugriff für das Gesamtresultat. Das ist aber verständlicherweise nicht der beste Pfad für den Zugriff auf nur eine “row”.

PROBLEM: OPTIMIZE stellt keine gültige Syntax für einzelne SELECTs dar !!!!!!!

Aug2012 107



Existenzprüfungen

“Existence check” mit OPTIMIZE FOR n ROWS….

Die FETCH FIRST (1) ROW ONLY Klausel, erstmals implementiert in DB2 V7, begrenzt die Anzahl zurückzuliefernder

“rows” auf genau eine einzige Zeile. Dabei spielt es keine Rolle, wieviele “rows” sich für die WHERE Klausel qualifiziert

haben.

Die Klausel beinhaltet auch die OPTIMIZE FOR 1 ROW Angabe.

Sie kann auch in einem “singleton select” kodiert werden, wo sie den Optimizer informiert, den besten Zugriffspfad für die

Rückgabe nur einer “row” zu suchen und nicht intern einen zweiten FETCH vorzusehen, den SQL normalerweise vornimmt,

um dann auf einen Fehlercode –811 zu laufen.

“Aufgrund der Begrenzung des Resultats auf EINE “row” und der Fähigkeit, den Optimizer über diese Absicht zu

informieren, ist diese Technik genau das, was ab DB2 V7 den „existence check“ ausmachen sollte.“

Zusammenfassung

Für einen “existence check” gilt also folgende Priorisierung:

(1) OPEN eines Cursor (optional mit der OPTIMIZE FOR ONE ROW Klausel) und Fetch einer EINZIGEN „row“

(2) oder Nutzung der WHERE EXISTS Klausel mit einer “correlated subquery”

Sehr wichtig: Man achte auf die unterschiedlichen Möglichkeiten des ”existence checks” und wenn ein Weg sich als zu ineffizient zeigt, sollte man einen anderen Weg gehen.

Aug2012 108



Datumsarithmetik

Gestern, heute, morgen - Datumsarithmetik im DB2

DB2 besitzt eine Reihe von Funktionen, die für Datumsberechnungen verwendet werden können. Ähnliche Funktionen gibt es

auch für Uhrzeitberechnungen, jedoch werden diese nicht so oft Verwendung finden.

Für die Speicherung und Verarbeitung eine Datums gibt es im DB2 das spezielle Format Date. Datumsarithmetik läßt sich nur

dann nutzen, wenn das Datum in diesem Format vorliegt (Hostvariablen müssen ggf. mit der skalaren Funktion Date ()

umgewandelt werden). Analog gilt für die Uhrzeit das interne Format time und die skalare Funktion time(). Für ganz exakte

Zeitstempel gibt es noch das Format timestamp, das Datum und Uhrzeit auf die Mikrosekunde genau speichert.

Das Spezialregister current date

Das Spezialregister current date beinhaltet das aktuelle Datum und ist nahezu universell einsetzbar.

Beispiele:

INSERT INTO tabelle ( sp1,sp2,sp3 ) VALUES ( current date , :host2 , :host3 ) ;

SELECT sp1,sp2, current date FROM tabelle ...;

UPDATE ... SET sp1 = current date WHERE ...;

SELECT ... WHERE sp1 < current date

Set :hostvariable = current date ;

analog existieren auch die Spezialregister current time und current timestamp

Aug2012 109



Datumsarithmetik

Die einfachste Form der Datumsarithmetik besteht darin, zu einem Datum eine bestimmte Zeitspanne zu addieren oder zu

subtrahieren. DB2 erlaubt, Tage, Monate , Jahre sowie eine Kombination daraus zu addieren/subtrahieren. Dies ist überall

dort erlaubt, wo im SQL-Statement ein normaler Ausdruck stehen darf. Der Ergebnistyp ist wieder Date.

Beispiele:

Set :host1 = DATE (:host2) + 1 YEAR + 5 MONTH + 10 DAYS ;

( in der Hostvariable< host2> muss hier natürlich ein gültiges Datum stehen . <host1> enthält dann das Datum, das 1 Jahr 5

Monate und 10 Tage nach <host2> liegt )

Select ... WHERE sp1 > current date - 1 MONTH;

Selbstverständlich können auch Hostvariablen als Zeitspanne verwendet werden:

SET:datneu = Date (:datalt) + :n YEARS - :m DAYS;

Als Zeitspanne ist dabei möglich: für ein Datum: für eine Uhrzeit: für einen Timestamp zusätzlich:

- Tage ( day ) - Stunden ( hour ) - Mikrosekunden ( microsecond )

- Monate ( month ) - Minuten ( minute )

- Jahre ( year ) - Sekunden ( second )

grundsätzlich erlaubt DB2 auch die Pluralformen ( also days , months , years usw. )

Wird durch eine Addition oder Subtraktion von Monaten oder Jahren ein Monatsende überschritten, so gleicht DB2 das

Ergebnis automatisch an. Ein '31.01.2001' + 1 Month würde eigentlich den 31.02.2001 ergeben, DB2 gibt hier den

Monatsletzten ( '28.02.2001' ) zurück

Aug2012 110



Datumsarithmetik

Die Date - Duration

Das ist eine Besonderheit im DB2. Sie ist das Ergebnis einer Subtraktion zweier Date-Felder.

hre externe Darstellung ist eine Decimal(8) - Zahl, bestehend aus JJJJMMTT (positionsgerecht). ( Hinweis: Im PL/1 sollten bei Dezimalvariablen keine geraden Stellenanzahlen verwendet werden, da sie den Compiler zu "Umwegen" zwingen können. DB2 toleriert auch ein DECIMAL(9) - Feld. )

Beispiel:

Date ( '17.03.2003') - Date ('08.01.1999')

ergibt die Dezimalzahl 40209 ( die Differenz ist 4 Jahre, 2 Monate, 9 Tage ).

Eine Date-Duration kann ihrerseits zu einem Datum addiert oder davon subtrahiert werden und ergibt wieder ein neues Datum.

Aber Vorsicht: DATE ist auch eine Konvertierungsfunktion!

Aug2012 111



Datumsarithmetik

Beispiel:

Die Konvertierungsfunktion heisst also …. Keine Indexnutzung für das entsprechende Prädikat !

EXEC SQL SELECT COUNT(*)

INTO :H-COUNT00

FROM CLTSXI00

WHERE RC = 0

AND DATE(LOGDAT) <= :DATUM-CLTSXI00

END-EXEC.

Lösung:

1. Man definiere das Tabellenfeld mit DATE ( PIC X(10) ) oder TIMESTAMP ( PiC X(26) )

2. Man definiere einen Index auf das Feld LOGDAT oder LOGDAT + RC

3. Man definiere die Hostvariable datumskonform

4. Man formuliere die Query wie folgt um:

SELECT COUNT(*)

INTO :h-count00

FROM cltsxi00

WHERE RC = 0

AND LOGDAT < :datum-cltsxi00

WITH UR

Aug2012 112


Kapitelinhalt









Aug2012 113

Übersicht über Utilities und CLP Commands

ACTIVATE DATABASE

…..

ARCHIVE LOG

ATTACH

AUTOCONFIGURE

BACKUP DATABASE

BIND

CATALOG DATABASE , DCS DATABASE ……

CHANGE DATABASE COMMENT , …..

….

DEACTIVATE DATABASE

…..

DESCRIBE

DETACH

…….

EXPORT

FORCE APPLICATION

GET ADMIN CONFIGURATION , ALERT CFG,..….

GET CONNECTION STATE , INSTANCE , …..

…..

GET SNAPSHOT

….

IMPORT

….

INSPECT

LIST ACTIVE DATABASES , APPLICATIONS , ….

……

LIST HISTORY

LIST INDOUBT TRANSACTIONS

…..

LIST PACKAGES/TABLES

LIST TABLESPACE CONTAINERS

LIST TABLESPACES

LIST UTILITIES

LOAD

……

PRECOMPILE

…..

QUIESCE

….

REBIND

RECOVER DATABASE

……

REORGCHK

RESET ADMIN CONFIGURATION , ALERT CFG, ….

…..

RESTART DATABASE

RESTORE DATABASE

……

ROLLFORWARD DATABASE

……

DB2 for LUW DB2 for LUW –– Utilities und KommandosUtilities und Kommandos

Aug2012 114

Übersicht über Utilities und CLP Commands

……

RUNSTATS

SET CLIENT , RUNTIME DEGREE , SERVEROUTPUT, TABLESPACE CONTAINERS

…..

START DATABASE MANAGER

START HADR

STOP DATABASE MANAGER

STOP HADR

…..

UNCATALOG DATABASE

…..

UNQUIESCE

UPDATE ADMIN CONFIGURATION

……


Aug2012 115

DB2 for LUW DB2 for LUW –– RUNSTATSRUNSTATS

Einführung

Das Utility RUNSTATS erfasst Statistikdaten für Tabellen, Indizes und „statistical views“, um präzise Informationen für

den Optimierer zur Auswahl von Zugriffsplänen bereitzustellen.

RUNSTATS ist sinnvoll in folgenden Situationen:

• Nachdem Daten in eine Tabelle geladen und geeignete Indizes erstellt wurden.

• Nachdem ein neuer Index für eine Tabelle erstellt wurde.

• Nachdem eine Tabelle mit dem REORG reorganisiert wurde.

• Nachdem eine Tabelle und zugehörige Indizes mit UPDATE-, INSERT- oder DELETE-Operationen in erheblichem

Umfang geändert wurden.

• Vor dem BIND von Anwendungsprogrammen, deren Leistung von kritisch ist.

• Zum Vergleich von aktuellen und früheren Statistiken

• Wenn der Wert für die Größe des PREFETCHING(PREFETCHSIZE) geändert wurde.

• Nachdem der Befehl REDISTRIBUTE DATABASE PARTITION GROUP ausgeführt wurde.

• Wenn XML-Spalten vorhanden sind. Wird RUNSTATS nur zum Sammeln von Statistikdaten für XML-Spalten verwendet, werden Statistikdaten für Nicht-XML-

Spalten, die während einer Ladeoperation oder durch eine frühere Ausführung des RUNSTATS gesammelt wurden, behalten.

Wenn Statistikdaten zuvor für einige XML-Spalten gesammelt wurden, werden diese ersetzt oder, falls die aktuelle RUNSTATS-

Operation diese Spalten nicht umfasst, gelöscht.

Zur Verbesserung der Leistung von RUNSTATS und zur Einsparung von Plattenspeicherplatz für Statistiken sollte man

nur die Spalten angeben, für die Datenverteilungsstatistiken erfasst werden sollen.

Aug2012 116


RUNSTATS – Beispiele

(1) Sammeln von Statistiken nur auf einer Tabelle, auf allen Spalten – ohne “distribution statistics”:

RUNSTATS ON TABLE db2user.employee

(2) Sammeln von Statistiken nur auf einer Tabelle, auf den Spalten empid und empname – mit “distribution statistics”:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS (empid, empname)

(3) Sammeln von Statistiken nur auf einer Tabelle, auf allen Spalten – mit “distribution statistics” mit einem entsprechenden

“frequency limit” für die Tabelle und Übernahme der Einstellungen für “num_quantiles” aus der DB2-Konfiguration :

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50

(4) Sammeln von Statistiken nur auf einer Tabelle, auf allen Spalten – mit “distribution statistics” und auf der “column

group” JOB, WORKDEPT, and SEX:

RUNSTATS ON TABLE db2user.employee ON ALL COLUMNS

AND COLUMNS ((JOB, WORKDEPT, SEX)) WITH DISTRIBUTION

(5) Sammeln von Statistiken auf einem “set of indexes”:

RUNSTATS ON TABLE db2user.employee for indexes db2user.empl1, db2user.empl2

(6) Sammeln von Basis-Statistiken auf allen “indexes” (ausschliesslich):

RUNSTATS ON TABLE db2user.employee FOR INDEXES ALL

(7) Sammeln von Basis-Statistiken auf der Tabelle und allen “indexes” mit “sampling” auf den “detailed index statistics”:

RUNSTATS ON TABLE db2user.employee AND SAMPLED DETAILED INDEXES ALL

Aug2012 117


RUNSTATS – Beispiele

(8) Sammeln von Statistiken auf allen Spalten, die in IX benutzt werden und für alle IX:

RUNSTATS ON TABLE db2user.employee ON KEY COLUMNS AND INDEXES ALL

(9) Sammeln von Statistiken für T1 für die individuellen Spalten c1 und c5 und auf den “column groups” (c2, c3) und (c2, c4).

“Multicolumn cardinality” ist sehr nützlich für den Optimizer, wenn er Filterfaktoren für Prädikate auf Spalten berechnen

soll, die “correlated” sind.

RUNSTATS ON TABLE db2user.T1 ON COLUMNS (c1, (c2, c3), (c2, c4), c5)

(10)Registrieren eines “statistics profile” zum Sammeln von Statistiken auf einer Tabelle, auf allen Spalten, mit “distribution statistics” und

einem eigenen “frequency” Limit für die Tabelle, während der Wert für “num_quantiles” aus der Konfiguration genommen wird. Die

“statistics“ werden nicht modifiziert:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT

NUM_FREQVALUES 50 SET PROFILE ONLY

(11)Modifizieren eines vorher registrierten “statistics profile” durch Ändern der NUM_FREQVALUES Werte von 50 auf 30. Das

Kommando modifiziert die “statistics“ wie angegeben:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT

NUM_FREQVALUES 30

UPDATE PROFILE

(12) Sammeln der Statistiken einer Tabelle mit Aufnahme der Optionen in das “statistics profile” dieser Tabelle:

RUNSTATS ON TABLE db2user.employee USE PROFILE

Aug2012 118


RUNSTATS – Vorgang

Der DB2 Optimizer benötigt möglichst genaue “statistics”, um so den optimalen Zugriffspfad auswählen zu können; d.h.

Angaben über Anzahl „rows“, Kardinalitäten von Werten, Schätzvorgaben zur Selektivität von Query-Prädikaten etc wären

sehr hilfreich.

Die einfachste Methode zum Erheben von Statistiken ist das Einschalten von “automatic runstats” wie im Folgenden

dargestellt. Dies ist seit DB2 Version 9.7. “default”:

DB2 UPDATE DB CFG USING AUTO_RUNSTATS ON

RUNSTATS kann CPU-intensiv sein.

Bevorzugt man die manuelle Ausführung von RUNSTATS und dies beeinflusst die Performance in der Produktion negativ,

so sollte man folgende Empfehlungen befolgen:

• Sammeln der Statistiken auf allen Tabellen und Aktuell-Halten der Statistiken

• Ist das RUNSTATS Kommando fertig, sollte man COMMIT absetzen, um die Locks von den Katalogtabellen wieder

zu entfernen

• Für Systemtabellen sollte man folgende Anweisung benutzen:

REORGCHK UPDATE STATISTICS ON TABLE SYSTEM

• RUNSTATS sollte genutzt werden, um Verteilungs- und IX-Statistiken zu erheben

RUNSTATS ON TABLE SCM.TAB WITH DISTRIBUTION

AND SAMPLED DETAILED INDEXES ALL

Aug2012 119


RUNSTATS – Vorgang (cntn‘d)

Beispiel: das erste Kommando sammelt die “distribution statistics”, das zweite sammelt Statistiken auf dem Index TMP.I0 und die

“distribution statistics” werden nicht gespeichert.

RUNSTATS ON TABLE TMP.TAB0 WITH DISTRIBUTION

RUNSTATS ON TABLE TMP.TAB0 AND INDEXES TMP.I0

Empfehlungen:

Wenn man für eine gefüllte Tabelle einen IX anlegt (oder für die der RUNSTATS gerade Statistiken erstellt hat) , so sollten die “index

statistics” während des Indexaufbaus gesammelt werden. Im Folgenden Fragmente des CREATE INDEX Statements mit den relevanten

Optionen:

DB2 CREATE INDEX… …. COLLECT SAMPLED DETAILED STATISTICS

Man sollte nun die gesamten RUNSTATS Kommando-Optionen in einem Profile ablegen. Dieses “profile” sollt für den nächsten

RUNSTATS , der ein Profil verwenden soll, bereitgestellt sein. So sichert man die K onsistenz in der Anwendung der Optionen.

RUNSTATS ON TABLE SCM.TAB - <COMPLETE COMMAND> ...

SET PROFILE ONLY

-— Any time later _

RUNSTATS ON TABLE SCM.TAB USE PROFILE

-— Check profile

SELECT STATISTICS PROFILE

FROM SYSCAT.TABLES

WHERE (TABSCHEMA,TABNAME) = ('SCM' 'TAB')

Aug2012 120


Automatisieren von Utilities (und RUNSTATS)

Automatic maintenance (AUTO_MAINT)

|

|-- Automatic database backup (AUTO_DB_BACKUP)

|

|-- Automatic table maintenance (AUTO_TBL_MAINT)

|

|---- Automatic runstats (AUTO_RUNSTATS)

|

|-------- Automatic statement statistics (AUTO_STMT_STATS)

|

|---- Automatic statistics profiling (AUTO_STATS_PROF)

|

|--------- Automatic profile updates (AUTO_PROF_UPD)

|

|---- Automatic reorganization (AUTO_REORG)

Die DB2-Parameter

Das ist eine Hierarchie:

Wenn man einen “child”-Parameter auf ON setzen will, muss der zugehörige “parent” auch ON sein !

AUTO_RUNSTATS

führt automatisch RUNSTATS auf Tabellen aus... Wenig “impact” auf die anderen Prozesse (7-10%) – ohne Rücksicht

darauf auf welchen Wert UTIL_IMPACT_PRIORITY gesetzt wurde ... RUNSTATS wird dabei nur auf die Tabellen

ausgeführt,die sich um mehr als 10-15% geändert haben. db2 luw v9.7 schaltet diesen Parameter automatisch an,

wenn eine neue DB erzeugt wird...

Aug2012 121

DB2 for LUW DB2 for LUW –– REORGREORG

Übersicht - REORG

Reorganisiert einen Index oder eine Tabelle.

Vorgehensweise

Folgende Schritte sind für eine Tabellen- oder Indexreorganisation auszuführen:

1. Ermitteln Sie, ob und welche Tabellen oder Indizes reorganisiert werden müssen.

2. Wählen Sie eine Reorganisationsmethode.

3. Führen Sie die Reorganisation für die ermittelten Objekte aus.

4. Optional: Überwachen Sie den Fortschritt der Reorganisation.

5. Stellen Sie fest, ob die Reorganisation erfolgreich war. Bei einer Offlinetabellenreorganisation und einer beliebigen

Indexreorganisation erfolgt die Operation synchron; das Ergebnis ist beim Abschluss der Operation sichtbar. Bei der

Onlinetabellenreorganisation erfolgt die Operation asynchron; Details können über die Logfile abgerufen werden.

6. Erfassen Sie Statistikdaten für reorganisierte Objekte neu(RUNSTATS)

7. Führen Sie einen Rebind für Anwendungen durch, die auf reorganisierte Objekte zugreifen.

Mit der Option CLEANUP ONLY in der Index-Klausel wird eine Bereinigung ohne Neuaufbau der Indexes

vorgenommen.

Dieser Befehl kann nicht gegen Indizes von „declared temporary tables“ oder „global temporary tables“ laufen

(SQLSTATE 42995).

Aug2012 122


REORG TABLE

Nach zahlreichen Änderungen an Tabellendaten können sich logisch sequenzielle Daten auf nicht mehr in der Sequenz

liegenden Pages befinden, sodass der DBM zusätzliche Leseoperationen ausführen muss, um auf die Daten zuzugreifen.

Wenn zahlreiche Zeilen gelöscht wurden, fallen auch zusätzliche Leseoperationen an. In diesem Fall kann man eine

Reorganisation der Tabelle durchführen, um die Tabelle mit dem Index neu zu ordnen und Speicherplatz wieder verfügbar

zu machen.

Man kann (und sollte) auch die Systemkatalogtabellen reorganisieren.

Da die Reorganisation einer Tabelle in der Regel mehr Zeit als das Aktualisieren von Statistikdaten beansprucht, kann

man den Befehl RUNSTATS ausführen, um die Statistiken auf den aktuellen Stand zu bringen. Wenn aktualisierte

Statistiken keine Leistungsverbesserungen bringen, kann evtl. ein REORG helfen.

Folgende Faktoren können darauf hinweisen, dass ein REORG erforderlich ist:

• hohes Aufkommen an INSERT-, UPDATE- und DELETE-Aktivitäten an Tabellen

• wesentliche Änderungen in der Leistung von Abfragen, die einen Index mit einem hoher „clusterratio“ verwenden

• Die Leistung wird durch die Ausführung des Befehls RUNSTATS nicht besser.

• Die Ausgabe des Befehls REORGCHK zeigt den Bedarf an einer Reorganisation an.

Aug2012 123


REORG INDEX

Im Lauf der Modifikationen von Tabellen kann sich die Indexleistung verschlechtern.

• Pages werden fragmentiert - es steigt der I/O Aufwand

• Die physische Indexseitenreihenfolge stimmt nicht mehr mit der Reihenfolge der Schlüssel auf diesen Seiten überein,

was zu einem Index mit schlechter Clusterbildung führt – „sequential prefetch“ ist nicht mehr effizient und die Anzahl

der Wartezeiten auf I/O-Vorgänge erhöht sich.

• Der Index entwickelt zu viele Levels. In einem solchen Fall sollte der Index reorganisiert werden.

Eine Indexreorganisation setzt folgendes voraus:

• SYSADM, SYSMAINT, SYSCTRL, DBADM , SQLADM oder CONTROL für die Tabelle und ihre Indizes.

• Jede Menge an freiem Speicherplatz in dem TS, in dem die Indizes gespeichert sind.

• Zusätzlicher Log-Platz. REORG protokolliert seine Aktivitäten.

Wenn die Option MINPCTUSED beim CREATE INDEX angeben wurde, führt der Datenbankserver automatisch Index-

Pages zusammen, wenn ein Schlüssel gelöscht wird und der freie Speicherplatz geringer als der angegebene Prozentsatz ist.

Dieser Vorgang wird als Online-Indexdefragmentierung bezeichnet.

Um das IX „clustering“ wiederherzustellen, Speicherplatz freizugeben und die Anzahl von Page - Levels zu verringern,

kann man eine der folgenden Methoden anwenden:

• Löschen und erneutes Erstellen des Index.

• Verwenden von REORG TABLE mit Optionen, die eine Offlinereorganisation der Tabelle und ihrer IX ermöglichen.

• Reorganisieren von IX „online“ mit REORG INDEXES. Diese Methode ist in einer Produktionsumgebung geeignet,

da sie Benutzern ermöglicht, die Tabellendaten zu lesen und zu schreiben, während ihre Indizes neu erstellt werden.

Aug2012 124


REORG Methoden

Auswählen einer Methode zur Tabellenreorganisation

Es stehen zwei Methoden für die Tabellenreorganisation zur Verfügung: die klassische Reorganisation (offline) und die

Inplace-Reorganisation (online).

Die Offlinereorganisation ist Standard. Zur Angabe einer Onlinereorganisation verwendet man die Option INPLACE beim

REORG TABLE.

Jede Methode hat ihre Vor- und Nachteile.

Vorteile der Offlinereorganisation

• Sie führt Tabellenreorganisationsoperationen am schnellsten aus, insbesondere wenn LOB-Daten (große Objekte) oder

LONG-Daten (Langfelddaten) nicht mit eingeschlossen werden.

• Tabellen und Indizes haben nach Abschluss ein perfektes Clustering.

• IX werden beim REORG einer Tabelle automatisch erneut erstellt, sodass keine separate IX-Erstellung nötig ist

• verwendet einen TS für temporäre Tabellen zur Erstellung einer Spiegelkopie. Dadurch verringert sich der

Speicherbedarf für den TSh, in dem die Zieltabelle bzw. der Index gespeichert ist.

• ermöglicht die Verwendung eines anderen Index als den Clusterindex zur Herstellung eines Datenclusterings.

Nachteile der Offlinereorganisation

• Der Tabellenzugriff ist eingeschränkt: nur ein Lesen während der Sortier- und „BUILD“-Phase eines REORG

• großer Platzbedarf für die Spiegelkopie der Tabelle, die reorganisiert wird.

• Der REORG-Prozess bietet weniger Steuerungsmöglichkeiten: Eine Offline-REORG lässt sich nicht anhalten und

wieder starten.

Aug2012 125


REORG Methoden

Auswählen einer Methode zur Tabellenreorganisation (cntn‘d)

Vorteile der Onlinereorganisation

• Es besteht voller Tabellenzugriff außer während der SWITCH-Phase eines REORG

• Mehr Steuerungsmöglichkeiten für den REORG-Prozess, der asynchron im Hintergrund ausgeführt wird. Der

Prozess kann angehalten, fortgesetzt oder gestoppt werden. Man kann zum Beispiel eine in Bearbeitung befindliche

REORG-Operation anhalten, wenn eine größere Anzahl von Aktualisierungs- oder Löschoperationen für die Tabelle

anstehen.

• Der Prozess ist im Fall eines Fehlers wiederherstellbar.

• Der Bedarf an Arbeitsspeicher ist geringer, weil die Tabelle inkrementell verarbeitet wird.

• Die Vorteile der Reorganisation sind unverzüglich verfügbar, sogar vor Abschluss des REORG

Nachteile der Onlinereorganisation

• Nicht optimales Daten- oder Indexclustering abhängig vom Typ der Transaktionen, die während eines REORG-auf

die Tabelle zugreifen.

• Geringere Leistung als bei einem „offline“ ausgeführten REORG

• Potenziell hoher Protokollierungsbedarf abhängig von der Anzahl der Zeilen, die versetzt werden, der Anzahl von

Indizes, die für die Tabelle definiert sind, und der Größe dieser Indizes.

• Potenzielle Notwendigkeit einer nachfolgenden Indexreorganisation, da Indizes gepflegt, jedoch nicht neu erstellt

werden.

Aug2012 126


REORG Methoden


Vergleich zwischen Online- und Offlinereorganisation

Merkmal Offlinereorganisation Onlinereorganisation

Leistung Schnell. Langsam.

Clusterfaktor der Daten bei Abschluss Gut. Nicht optimal.

Gemeinsamer Zugriff (auf die Tabelle) Reicht von 'kein Zugriff' bis 'Lesezugriff'. Reicht von 'Lesezugriff' bis 'Vollzugriff'.

Datenspeicherplatzbedarf Beträchtlich. Nicht erheblich.

Protokollspeicherplatzbedarf Nicht erheblich. Kann beträchtlich sein.

Benutzerkontrolle (Möglichkeit zum Anhalten und Neustarten des Prozesses)

Weniger Kontrolle. Mehr Kontrolle.

Wiederherstellbarkeit Nicht wiederherstellbar. Wiederherstellbar.

Indexneuerstellung Wird ausgeführt. Wird nicht ausgeführt.

Unterstützung für alle Tabellentypen Ja Nein

Möglichkeit zur Angabe eines anderen Index als des Clusterindex

Ja Nein

Verwendung eines Tabellenbereichs für temporäre Tabellen

Ja Nein

Aug2012 127


REORG Methoden


Unterstützte Tabellentypen für Online- und Offlinereorganisationen

Tabellentyp Offlinereorganisation unterstützt Onlinereorganisation unterstützt

Tabellen mit mehrdimensionalem Clustering (MDC-Tabellen)

Ja1 Nein

Bereichsclustertabelle (RCT-Tabelle) Nein2 Nein

Tabellen im Anfügemodus Nein Nein3

Tabellen mit Langfelddaten oder LOB-Daten (LOB, große Objekte)

Ja4 Nein

Systemkatalogtabellen: SYSIBM.SYSDBAUTH, SYSIBM.SYSROUTINEAUTH, SYSIBM.SYSSEQUENCES, SYSIBM.SYSTABLES

Ja Nein

Anmerkungen: 1. Da das Clustering automatisch durch MDC-Blockindizes sichergestellt wird, dient die Reorganisation einer MDC-Tabelle lediglich zur

Freigabe von Speicherplatz. Es können keine Indizes angegeben werden. 2. Der Bereich einer RCT-Tabelle (Bereichsclustertabelle) bleibt stets in Clustern angeordnet. 3. Eine Onlinereorganisation kann ausgeführt werden, nachdem der Anfügemodus (APPEND) inaktiviert wurde. 4. Die Reorganisation von Langfelddaten oder LOB-Daten (LOB, Large Object) kann eine geraume Zeit in Anspruch nehmen und führt zu keiner

Verbesserung der Abfrageleistung. Sie sollte nur zur Freigabe von Speicherplatz ausgeführt werden.

Aug2012 128


REORG Beispiele

(1) Zum Reorganisieren einer Tabelle um Speicherplatz zu gewinnen und dabei den temporären TS mytemp1 zu verwenden,

nutzt man folgende Anweisung:

db2 reorg table homer.employee use mytemp1

(2) Zum Reorganisieren von Tabellen in einer “partition group”, bestehend aus den Knoten 1, 2, 3, und 4 eines “vier-node-

systems” nutzt man folgende Anweisung:

db2 reorg table employee index empid on dbpartitionnum (1,3,4)

db2 reorg table homer.employee index homer.empid

on all dbpartitionnums except dbpartitionnum (2)

(3) Um die “pseudo deleted keys” und “pseudo empty pages” in allen IX der Tabelle EMPLOYEE aufzuräumen, während

andere Trasaktionen lesend und schreibend auf die Tabelle zugreifen können sollen, gilt folgendes:

db2 reorg indexes all for table homer.employee allow write access cleanup only

(4) Um die “pseudo empty pages” in allen IX der Tabelle EMPLOYEE aufzuräumen, während andere Trasaktionen lesend und

schreibend auf die Tabelle zugreifen können sollen, gilt folgendes:

db2 reorg indexes all for table homer.employee allow write access cleanup only pages

(5) Um die Tabelle EMPLOYEE unter Nutzung des “system temporary tablespace” TEMPSPACE1 als “work area” zu

reorganisieren:

db2 reorg table homer.employee use tempspace1

Aug2012 129

DB2 for LUW DB2 for LUW –– BACKUP & RESTOREBACKUP & RESTORE

Übersicht

Eine Datenbank kann aufgrund von Hardware- oder Softwarefehlern (oder beidem) unbrauchbar werden.

Irgendwann treten Speicherprobleme, Stromausfälle oder Anwendungsfehler auf, und jedes Fehlerszenario erfordert

unterschiedliche Recoveryaktionen. Man schützt die Daten vor Verlust, indem man eine gut erprobte

Recoverystrategie bereithhält. Bei der Entwicklung der Recovery-Strategie sollte man unter anderem folgende Fragen

beantworten können:

• Soll die Datenbank wiederherstellbar sein?

• Wie viel Zeit steht für die Recovery der Datenbank zur Verfügung?

• In welchen Abständen werden Backup-Operationen durchgeführt?

• Wie viel Speicher kann für Backupkopien und Archivprotokolldateien zugeordnet werden?

• Sind Backups auf TS-Eebene ausreichend, oder muss die gesamte Datenbank gesichert werden?

• Sollte ein „ready“ System manuell oder über HADR (High Availability Disaster Recovery) konfiguriert werden?

Eine Strategie zur Recovery der Datenbank sollte sicherstellen, dass alle Informationen verfügbar sind, wenn sie für

eine Recovery der Datenbank benötigt werden.

Sie sollte einen Zeitplan für regelmäßige Backups enthalten. Im Fall von partitionierten Datenbanken sollten auch

nach einer Skalierung des Systems, d. h. nach dem Hinzufügen oder Löschen von Datenbankpartitionsservern oder -

knoten, Backups durchgeführt werden können.

Die Gesamtstrategie sollte auch Prozeduren zum Wiederherstellen von Befehlsscripts, Anwendungen,

benutzerdefinierten Funktionen, als Code gespeicherter Prozeduren in Betriebssystembibliotheken sowie von

Ladekopien berücksichtigenn.

Aug2012 130


Übersicht

1. Hier wird die „database” WSDB, definiert auf allen 4 “database partitions“, nummeriert von 0 bis 3, gesichert. Der Pfad

/dev3/backup kann von allen “database partitions” bearbeitet werden. Die Database Partition 0 ist die “catalog partition”.

Der folgende Befehl startet einen “offline backup” aller “database partitions” von WSDB auf /dev3/backup. Er muss

von der „database partition” 0 abgesetzt werden:

db2 BACKUP DATABASE wsdb ON ALL DBPARTITIONNUMS TO /dev3/backup

Der Backup wird auf allen Partitions simultan gefahren. Alle vier “database partition backup images” werden im

Directory /dev3/backup abgelegt. Dieses kann ein “shared directory” sein, das von mehr als einer Partition zugegriffen

werden kann oder aber es kann ein “locally-mounted” Directory sein, das von jeder Partition individuell oder bearbeitet werden kann. Man kann aber auch eine Kombination aus beidem haben.

Beispiele

Aug2012 131


2. Hier wird die DB SAMPLE auf einen TSM Server gesichert. Es werden 2 parallele TSM Client Sessions genutzt.

DB2 kalkuliert die optimale Puffergröße für die Umgebung

db2 BACKUP DATABASE sample USE TSM OPEN 2 SESSIONS WITH 4 BUFFERS

3. Im folgenden Beispiel wird der Backup auf “table space-level” für die TS “syscatspace”, “userspace1” der “database”

payroll auf Band durchgeführt:

db2 BACKUP DATABASE payroll TABLESPACE (syscatspace, userspace1) TO/dev/rmt0, /dev/rmt1 WITH 8 BUFFERS WITHOUT PROMPTING

4. Das Schlüsselwort USE TSM OPTIONS kann zur Spezifikation der TSM Information für die Backup Operation

eingesetzt werden. Hier wird gezeigt, wie ein VOLL qualifizierter “file name” mit USE TSM OPTIONS angegeben

werden kann:

db2 BACKUP DB sample USE TSM OPTIONS @/u/dmcinnis/myoptions.txt

Die Datei myoptions.txt enthält folgende Information: -fromnode=bar -fromowner=dmcinnis

5. Im Folgenden wird eine wöchentliche “incremental backup” Strategie für eine “recoverable database” umgesetzt. Sie

umfasst eine wöchentliche “full database” Backup Operation, einen täglichen “non-cumulative (delta)” Backup und

einen „mittwöchentlichen“ „cumulative (incremental)“ Backup:

(Sun) db2 backup db sample use tsm

(Mon) db2 backup db sample online incremental delta use tsm

(Tue) db2 backup db sample online incremental delta use tsm

(Wed) db2 backup db sample online incremental use tsm

(Thu) db2 backup db sample online incremental delta use tsm

(Fri) db2 backup db sample online incremental delta use tsm

(Sat) db2 backup db sample online incremental use tsm

Beispiele - BACKUP

Aug2012 132


In der einfachsten Form des DB2-Befehls RESTORE DATABASE muss man lediglich den Aliasnamen der Datenbank

angeben, die man wiederherstellen möchte. Beispiel:

db2 RESTORE DB sample

Da die Datenbank SAMPLE vorhanden ist und beim Absetzen des Befehls RESTORE DATABASE ersetzt wird, wird in

diesem Beispiel die folgende Nachricht zurückgegeben:

SQL2539W Achtung! Restore in eine bestehende Datenbank, die mit der

Datenbank des Backup-Images identisch ist. Die Datenbankdateien werden

gelöscht.Fortfahren ? (j/n)

Gibt man j an, sollte die Restoreoperation erfolgreich beendet werden können.

Für den Restore einer Datenbank ist eine exklusive Verbindung erforderlich, d. h., es können keine Anwendungen für die

Datenbank ausgeführt werden, sobald die Operation gestartet ist. Das Restore-Utility verhindert, dass andere

Anwendungen vor der erfolgreichen Beendigung der Operation auf die Datenbank zugreifen.

Der Restore eines TS kann hingegen online erfolgen.

Ein TS kann erst nach der erfolgreichen Beendigung der Recoveryoperation (und evtl. anschließender ROLLFORWARD-

Recovery) wieder verwendet werden.

Bei Tabellen, die sich über mehrere TS erstrecken, ist es ratsam, die betreffende Gruppe von TSen zusammen zu sichern

(und wiederherzustellen).

Bei der partiellen oder selektiven Restoreoperation kann man ein Backup-Image auf TS-Ebene oder ein Image eines

vollständigen Datenbank-Backups verwenden, aus dem man mindestens einen TS auswählt. Alle Protokolldateien, die

diesen TS ab dem Zeitpunkt der Erstellung des Backup-Images zugeordnet wurden, müssen vorhanden sein.

RESTORE - Übersicht

Aug2012 133


Es wird angenommen, dass eine wiederherstellbare Datenbank mit dem Namen SAMPLE vorhanden ist und diese drei

Datenbankpartitionen enthält:

Datenbankpartition 1 enthält die TSe SYSCATSPACE, USERSP1 und USERSP2 und ist die Katalogpartition.

Datenbankpartition 2 enthält die TSe USERSP1 und USERSP3.

Datenbankpartition 3 enthält die TSe USERSP1, USERSP2 und USERSP3.

Die folgende Prozedur veranschaulicht die Anwendung der Befehle RESTORE DATABASE und ROLLFORWARD

DATABASE über den CLP zur erneuten Erstellung der gesamten Datenbank bis zum Ende der Log-Protokolle.

1. Ausführen des Befehls RESTORE DATABASE mit der Option REBUILD in Datenbankpartition 1:

db2 RESTORE DB sample REBUILD WITH ALL TABLESPACES IN DATABASE TAKEN AT BK31 WITHOUT PROMPTING





4. Ausführen des Befehls ROLLFORWARD DATABASE mit der Option TO END OF LOGS auf der Katalogpartition:

db2 ROLLFORWARD DB sample TO END OF LOGS

5. Ausführen Befehl ROLLFORWARD DATABASE mit der Option STOP:

db2 ROLLFORWARD DB sample STOP

RESTORE – Vorgehensweise und Beispiel

Aug2012 134

DB2 Systemkommandos

Alle DB2 Systemkommandos werden unter sqllib/bin installiert. Einige der wichtigsten Kommandos in

DB2 findet man in den folgenden Listen. Mehr Informationen gibt es in den DB2 Manuals, und dort im

Mnaual “DB2 Command Reference”:

http://www.ibm.com/support/docview.wss?rs=71&uid=swg27015148

Instance Kommandos


http://www.ibm.com/support/docview.wss?rs=71&uid=swg27015148

Aug2012 135

Handling genereller „database tasks“


Aug2012 136

DB2 DAS Instance Kommandos

DB2 informationale Kommandos


Aug2012 137

DB2 grafische Tools


Aug2012 138

DB2 Interfaces in Zukunft

Anmerkung:

• das Control Center und die damit verbundenen Komponenten werden seit der

Version 9.7 nicht mehr empfohlen und in späteren Releases entfernt werden

• Empfehlung: Anwenden der neuen “suite” von GUI Tools zur DB2 Datenverwaltung

und zur Verwaltung von “data-centric” Programmen.

• Diese neuen Tools umfassen

IBM Data Studio,

OptimDevelopment Studio und

Optim Database Administrator.

DB2 for LUW DB2 for LUW –– Die Zukunft mit ToolsDie Zukunft mit Tools

Aug2012 139


Kapitelinhalt






• DB2 Utilities und Statistiken



Aug2012 140

Fundamentale Aspekte zur Performance

Annahmen

Sie sind KEIN Experte

Sie wollen nicht notwendigerweise ein Experte werden

Sie wollen nur Ihren Job gut machen

Sie wollen nicht alle möglichen Wege zum Ziel wissen

Ein guter Weg zum Ziel reicht

80% optimaler Performance ist ausreichend (?)

Performance “Wahrheiten”

Es gibt IMMER ein “bottleneck”!

Die 5 fundamentalen potentiellen “bottlenecks” sind:

1. Application

2. CPU

3. Memory

4. Disk

5. Network

DB2 for LUW DB2 for LUW –– MonitoringMonitoring & Fehleranalyse& Fehleranalyse

Aug2012 141


„Sizing“ einer Konfiguration - Idealerweise kennt man:

Die Applikation

Die Lastanforderungen für die Verarbeitung

Die Anzahl „concurrent users“/“jobs“

Die größten Tabellen

Typische Query Scenarios

Die Größe der Ergebnisse, die erzeugt werden

Die “response time” Zielsetzungen für Last und Queries

…

„Sizing“ – Anhaltspunkte( “Rules of Thumb”)

Die Wahl der Plattform

DPF („database partitioning facility“) - GB/node

Memory

Disk - „Space“ / „Spindles“ (LUNs)


Aug2012 142


Plattform Auswahl

DB2 ist für alle größeren Plattformen optimiert (Linux, AIX, Windows, Solaris, HP-UX)

Weitaus mehr als eine Frage der Performance

Integration mit anderen Systemen

„Skills“ / Bedienbarkeit / Verwaltbarkeit…

€€€€

Oft gibt es mehr als 1 “gute” Wahl !!!!!

DB2 mit und ohne DPF

Die Unterschiede werden KLEINER: Die Produkte konvergieren

Wenn, dann sollte man mit einem DPF auf einem Knoten starten (“1-node” DPF)

Ähnliche Performance

Enthält die Funktion zum späteren Wachsen

DPF ist wenig üblich für - OLTP, ERP, CRM

DPF ist üblich bei – „Business Intelligence“ Anwendungen


Aug2012 143


Memory! – Wieviel brauche ich ????

Das hängt von vielen Faktoren ab….

Von der Anzahl User(“connections”)

Von der geplanten Query Last

Davon, ob andere Software die Maschinen ebenfalls benutzen soll oder nicht (ist zu messen)

Heute sind 64-bit Prozessoren üblich

Aber das OS (und DB2) kann immer noch nur 32-bit

Trotzdem würde man 64-bit Durchsatz bevorzugen

4GB / Prozessor ist dabei heute ein guter “starting point“

Disk! Wieviel GB braucht man?

Mehr als man denkt!

Man vergesse NICHT:

Working storage

Tempspace

Indexes, AST’s („abstract

syntax trees“) etc.

Raw data x 4 (unmirrored)

Raw data x 5 (RAID5)

Raw data x 8 (RAID10)


Aug2012 144


Disk! Wieviele “Spindles” sind notwendig?

Man beginne mit einem ausbalancierten System

Nicht zu viele kleine Disks

Nicht zu wenige große Disks ( verursachen womöglich I/O „bottlenecks“)

Unterschiedliche Anforderungstypen

„Latency“ (Wartezeiten)

Durchsatz

Letztendlich sollten es 6-10 Disks pro CPU”core” sein und zusätzliche

Laufwerke für die Logs.

Physical Database Design

1 “database” pro Instanz

Der “create database” sollte möglicht EINFACH sein: Man nutze die „default

tablespace“ Definition

Wenn möglich mit AUTOMATIC STORAGE Option (seit 8.2.2):

CREATE DATABASE DB2 AUTOMATIC STORAGE YES ON X

Erweiterungen/Anpassungen später über “CREATE / ALTER

TABLESPACE”

Vergrößern Sie nicht einfach den “default Tablespace“ mit dem

„createdb“ Befehl


Aug2012 145


Auswahl der Page Size

Nutzen Sie nie mehr als 2 Page Größen

Beispielsweise 4K und 16K oder 8K und 32K

OLTP: kleinere Pages sind besser (e.g. 4K, 8K)

DSS: Grosse „pages sizes” bieten häufig Vorteile (e.g. 8K, 16K, 32K)

Seit 8.2.2 kann man jede beliebige “page size” als “base page size”

für die DB wählen

Tablespace Design

Stellen Sie sicher, dass „temp tablespaces“ existieren

1 pro “page size”

Die Anzahl “tablespaces” sollte möglichst klein sein

1 für “look up” Tabellen in einer “single node nodegroup”

1 pro “fact table” (größte Tabellen)

1 für alle anderen

Verteilen Sie jeden “tablespace” über mehrere / alle Disks


Aug2012 146


Die Optimierung im Schema

Man muss entscheiden, WIE die Daten strukturiert werden sollen

Verteilen der Daten über die Knoten: Mit DPF „hash-partitioning“

Die Datenorganisation: Mit MDC („multi dimensional clustering“)

Hilfreiche andere Datenstrukturen

Existieren die richtigen Indizes? “Clustered”, “clustering”, “include columns” für “unique” IX

Können “Materialized query tables” (MQT) helfen?

Man sollte den Einsatz des Design Advisor überlegen

Was nun - DMS vs. SMS

Es gibt keine generelle Empfehlung (mehr)

DMS “raw” kann am schnellsten sein

DMS “file” wird immer mehr der bevorzugte Mechanismus

o Performance annähernd RAW

o Flexibilität annährend SMS (besonders seit 8.2.2.)

SMS ist immer noch die beste Wahl für TEMP TS (außer bei sehr großen “temps”)

Man kann auch einen Mix beschließen

Seit 8.2.2 läuft “direct I/O” (“concurrent I/O”) auch auf “temps” (SMS

und DMS File)


Aug2012 147


Tablespace Tips für RAID Systeme

bei DSS Last

Man wählt eine EXTENTSIZE, die ein Vielfaches der RAID “stripe size” ist (idealerweise,

„raid_stripe_size“ * „num_disks_in_stripe“ = „extent_size“)

Kann die Notwendigkeit nach sich ziehen, DB2_PARALLEL_IO zu setzen ( wenn nur 1 Container im

TS)

bei OLTP Betrieb:

Ähnliches Layout wie bei DSS, aber das “prefetching” auf den TS sollte ausgeschaltet sein, wenn die # der “prefetched pages read” gering ist: db2 “alter tablespace <tbname> prefetchsize 0”

Typischerweise haben die RAID “controller”/”Storage Manager” Caches, die selektiv für

“read”/”write” caching eingeschaltet werden können

Für DSS:

Einschalten des “read cache” mit “read ahead” Funktion – sinnvoll für “prefetching“

Einschalten des ”write cache” für “temps”

Für OLTP:

Ausschalten von “read”, als auch “write cache” bei großen Datenmengen und

Zugriff vorwiegend “random”

Einschalten des “read cache” bei kleinen Datenmengen und begrenztem Memory

(einige “caches” mit 2GB oder mehr)

Es macht sich bezahlt, zu verstehen, was in einem RAID Subsysystem passiert


Aug2012 148


Table Design

Es ist OK mehrere Tabellen in einem Tablespace zu platzieren

Einmal definiert, wählt man die entsprechenden Optionen über ALTER Table

APPEND MODE – wenn die Inserts am Tabellenende erfolgen (ALTER TABLE ... APPEND ON)

LOCKSIZE – “table level locking” (ALTER TABLE ... LOCKSIZE TABLE)

PCTFREE – Reservieren von “space” nach “load”/”reorg” (ALTER TABLE ...PCTFREE 10)

“constraints” sollten nach der Erstellung der IX erfolgen

Index Design

Man wähle die angemessenen Optionen

PCTFREE – sollte 0 sein bei “read-only tables”

PAGE SPLIT HIGH/LOW – für aufsteigend zu bgeschreibende IX

CLUSTER – Definition von “clustering index”

INCLUDE “columns” - extra “cols” in “unique” IX für “index-only” Zugriffe

ALLOW REVERSE SCANS – macht IXe “bi-directional”

CREATE INDEX ... ON ... (CUSTKEY) INCLUDE (C_ADDRESS) COLLECT STATISTICS …

Seit 8.2.2 kann man auch auf IX auf “global temporary tables”

COLLECT STATISTICS einsetzen

Beim Laden von Tabellen: “fastparse“, „totalfreespace“


Aug2012 149

Tuning “Knobs”

Die „Magie"

optimaler

Performance ...

Performance Anleitung

Konfigurationsparameter

„registry settings“


Aug2012 150


Operating System Tuning

Man sollte jedenfalls sicherstellen, dass man auf dem aktuellen „maintenance level“ ist !

„Paging space“

Auf 2 oder mehr separaten Disks

2x “real memory”

Option vmtune minperm/maxperm

Besonders bei SMS (AIX)

Performance Configuration Advisor

Bietet ein “starter set” von “configuration” Parametern:

Database und Database Manager

Verfügbar über

Das DB2 CC / DataStudio

Einen API Call

Den „Command Line Processor“ (CLP)

DB2 AUTOCONFIGURE … APPLY DB AND DBM…

… eine ideale Methode zum STARTEN!!

vmstat/iostat sollten regelmäßig genutzt werden!


Aug2012 151


Database Manager Config Parms

INTRA_PARALLEL: grundsätzlich auf NO – nur bei geringer CPU Nutzung und ausschliesslich

komplexem SQL „environment“ auf YES

NUM_INITAGENTS / NUM_POOLAGENTS: durchschn. Anzahl erwarteter „concurrent“ User

SHEAPTHRES: abhängig von der Anzahl sort-intensiver „concurrent“ Users – normalerweise 10 x

– 100 x SORTHEAP

RQRIOBLK and ASLHEAPSZ: Erhöhen bei großen Resultatsmengen

Database Configuration Parameters

DFT_DEGREE: typischerweise auf -1 gesetzt (ANY)

DFT_QUERYOPT: „Default” 5, häufig 2 oder 7 als Alternativen

APPLHEAPSZ, PCKCACHESZ: Erhöhen bei mehr Applikarionen/Packages

SEQDETECT: normalerweise auf dem „default” YES

SET CURRENT DEGREE und die BIND Option DEGREE bestimmen

den gewünschten Parallelitätsgrad beim Compile

Der “snapshot monitor” ist sehr gut geeignet, diese und noch mehr

Parameter zu überwachen


Aug2012 152


BUFFERPOOLs

Ein einzelner höchst wichtiger Tuning Parameter

NIEMALS auf “default” stehen lassen

Normalerweise sind nur einige wenige BP definiert: mind. 2 für jede Page Größe ( 1Temp, 1 für

den Rest)

Man sollte SYSBUFFERPOOLS prügen nicht BUFFPAGE

SOFTMAX: kontrolliert die „dirty page writes“

Workload abhängig – beeinflusst Performance und “recovery time”

Kleiner Wert = kürzere “recovery time” = potentiell mehr “writes”

Hoher Wert = längere “recovery time” = weniger “writes” = potentiell bessere Performance

Ein vollständiges Bild ergibt die Kombination aus DB2 “monitoring“

und OS „monitoring“


Aug2012 153


SORTHEAP

Kritisch beim unterschiedlichen Einsatz für OLTP und DSS

Bei OLTP: klein - besonders bei hoher konkurrierender Verarbeitung – beeinflusst das PLAN

Optimizing

Bei DSS: Betrifft beide “private” und “shared” (SMP) Sorts, sowie “Sort”/”hash join”/

“table”-Verarbeitung im Speicher

Logging

Database Logs müssen auf ihre eigenen Disks geschrieben werden: permanent… gespiegelt

über “write-cache”….

LOGFILSIZ: sollte über den „default“ erhöht werden … 5000 4K Pages oder mehr

LOGPRIMARY: alle Logs sollten als „primary logs“ allokiert sein. LOGSECOND sollte nur für

„emergency space“ eingesetzt werden

LOGBUFSZ : sollte auf 512 oder mehr erweitert werden (nur wenn „log pages read“ hoch ist

MINCOMMIT: sollte auf dem „default“ 1 stehen bleiben (typischerweise nie

höher als 2-3)

Man nutze DB2 und OS Tools, um die Log Aktivitäten zu beobachten

Man beobachte die Schlüsselwerte im Monitor Output


Aug2012 154


I/O Configuration Parameters

NUM_IOSERVERS: einen pro Disk (bzw.pro RAID „array“ mit DB-Daten; Limit: 2 x #CPUs

NUM_IOCLEANERS: einen pro CPU

CHNGPGS_THRESH: niedriger als der „default“ ist ein empfohlener Wert; z.B. 40

Man kann auch die Funktion DB2_ALTERNATE_PAGE_CLEANING einsetzen

“File system caching” beeinflusst die Performance sowohl von SMS als auch DMS „file

tablespaces“

In einem 64bit DB2 mit mehr als 3GB Memory, läßt man die Bufferpools das “caching” erledigen

und schaltet den “file system cache” aus

In einem 32 bit DB2 mit mehr als 3GB Memory, sollte man überlegen, den “system cache “ für TS

einzuschalten, “rows” verwalten, die häufig wiedergelesen werden; z.B: nutzt man dann den “file

system cache” als Erweiterung des “db2 bufferpool caching”

LOBS werden ebenfalls nicht im Bufferpool “gecached”, so sollte man sie , wenn möglich, im “file

system cache” vorhalten

Die Empfehlungen im Administration helfen hier bei der Konfiguration der

“database“

Seit V8.2 kann man die Nutzung des “file system cache “ pro TS kontrollieren

OFF: ALTER TABLESPACE <tablespace name> ... NO FILE SYSTEM CACHING

ON: ALTER TABLESPACE <tablespace name> ... FILE SYSTEM CACHING


Aug2012 155


Registry Settings

Typischerweise zum Einschalten von sehr neue Funktionen genutzt

Neue Features: DB2LINUXAIO = true (seit 8.2.2)

Seltene und unübliche Funktionen (use with caution)

DB2_SKIPINSERTED (8.2.2)

DB2_SKIPDELETED

DB2_EVALUNCOMMTTED

Überprüfen Sie die README Files jedes “fixpack” auf “new Features“


Aug2012 156

DB2 for LUW DB2 for LUW –– SQL Tuning & SQL Tuning & MonitoringMonitoring


Die Quellen der DB2 Performance Probleme

Aug2012 157



Die Top 10 Gründe schlechter Performance

#1: zu wenige Disks

• Man muss I/O und CPU Nutzung ausbalancieren

Databases sind I/O intensiv – bei Random I/O und “sequential” I/O

• Erkennung über:

Hohe I/O “waits”, hohe Disk Nutzung

Das System arbeitet gut, bei geringer Belastung - und kippt unter Last “aus den Latschen”

• Man kann berechnen:

Random I/O’s (io’s/txn * #txn’s/sec = io’s/sec)

Sequentielle I/O‘s als MB/sec

• Lösung:

Hinzufügen von Disks/LUN‘s und Rekonfigurieren der Disk Umgebung

Aug2012 158




#2: Schlechte Konfiguration der Bufferpools

• Man sollte den “real memory” gut genug / optimal nutzen

• Man achte auf „defaults“:

z.B. der DB Konfigurationsparameter “Buffpage” wird nur wirksam, wenn BUFFPOOL Größe mit –1 im

Katalog angelegt ist


Speicher ist unterbeschäftigt

Disks sind mehr beansprucht als erwartet

Monitoring auf „Table Level“ I/O

• Lösung:

Review der TS-Zuweisung auf die Bufferpools

Erhöhen der BP Größen

Aug2012 159




#3: Logs schlecht konfiguriert

• Logs werden ausschliesslich sequentiell geschrieben

Ein Engpass für alle Transaktionen

• Sowohl logische als auch physikalische Eigenschaften spielen eine Rolle


Suchen nach “hot” Disk Scenarios

Unerwartet schlechte Antwortzeiten

• Lösung:

Stellen Sie sicher, dass das Log isoliert ist und “write-cache” unterstützt wird

Konfigurieren Sie Logs gemäß maximaler Performance

Man kann “raw logs” oder auch “solid-state” Disk Log Devices einsetzen, um ein

Maximum an Logging Performance zu erhalten

Aug2012 160




#4: SORTHEAP zu groß für OLTP

• Große „sortheaps“ verursachen Sorts

• Vorsicht beim Skalieren der user mit großen “sortheaps“


Hoher Speicherverbrauch, „paging“

Hoher Verbrauch an „temp“-Speicher

Große Anzahl Sorts, lange Sortierzeiten (im Monitor)

• Lösung:

Reduzieren der “sortheap” Größe, Erhöhen der “sheapthres”

Tuning der SQL’s mit hohen SORT-Anforderungen

Aug2012 161




#5: Tempspace schlecht konfiguriert

• Wichtig ist das Tuning für beide Arten von Queries: DSS und OLTP


Hohe Disk-Nutzungsrate

Tablespace ist gefüllt mit mehreren „temp Tablespaces“

• Lösung:

NUR 1 “temp tablespace” pro Page-Größe

Verteilung über eine möglichst große Anzahl Disks

Aug2012 162




#6: Fehlende oder „out-of-date“ Statistiken

• Der intelligente DB2-Optimizer benötigt aktuelle Statistiken

Man achte auf die Granularität, die dabei möglich ist


Lang laufende Queries

Erklärungsbedürftige Zugriffspläne

• Lösung:

Die richtigen Statistiken (RUNSTATS) auf alle Tabellen

Einsatz von Detail- und Verteilungs-Statistiken

Erhöhen der Parameter num_quantiles und num_freq_values

“automatic” RUNSTATS

Ein REORGCHK kann Statistiken für ALLE Tabellen anfordern

Aug2012 163




#7: schlecht oder gar nicht „getuntes“ SQL

• Je besser SQL formuliert ist, desto einfacher ist es zu evaluieren

SQL ist sehr mächtig – Nutzen Sie diese „power“


Dynamische SQL „snapshots“

Suchen der „long-running“ SQl Statements

Vergleich von „rows to read“ gegen „rows to be returned“

Weitere Verfeinerungen in der Applikation

• Lösung:

Formulieren Sie nur, was Sie benötigen / wünschen

Befolgen Sie die SQL-Tuning-Regeln !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Setzen Sie den Design Advisor ein

Aug2012 164




#8: „concurrency“ Probleme

• Manche “concurrent” Users benötigen Anleitung


Lange „lock wait“ Zeiten

„lock timeouts“

Schlechter Durchsatz

• Lösung:

Auswahl des passenden “isolation level”

Aktuelle, passende Index-Strukturen (type-2, “compressed”, Block-IX

etc.)

Vergrößern der “lock list” ( evtl. maxlocks)

Setzen von “locktimeout” auf einen anderen Wert als -1

Kürzere Transaktionen

SKIPINSERTED oder SQL-Statements mit WITH UR / FOR FETCH ONLY

Aug2012 165




#9: Naive JAVA Applikationen

• Es gibt Tausende von Möglichkeiten JAVA zu schreiben – nicht alle sind OPTIMAL


Schlechte Trefferraten im „package cache“

Hohe CPU/Memory Verbräuche auf der „client“-Seite

Hohe Netzverweilzeiten

CLI Trace

JDBC Trace für alle DB2 „data sources“ (z.B: dataSource.setTraceFile(“<path to an existing directory>"); dataSource.setTraceLevel(<trace level>);

• Lösung: Nutzen von Parametermarkern in CLI/JAVA

SQLJ bei statischen, komplexen SQL, zum Vermeiden von “prepare time”

Auffinden von mimmemmode/trustapp Modes in CLI

Vergrößern des “package cache”

Untersuchen des “connection pool”

Ausschalten von AutoCommit in der JAVA Applikation und Kontrolle der Commits über

die Applikationslogik

Gerade der AutoCommit wird oft zur Falle – bei hohen Insert/Update Folgen!

Aug2012 166




#10: „Page cleaning“/Bufferpools

• Bufferpools haben eine endliche Größe des Speichers(!)

Manchmal sollten sie aus Performance-Gründen “getuned” werden


Schlechte „hit ratio“

Hohe CPU/Memory Verbräuche auf der „client“-Seite

PageWrites vs AsyncPageWrites ist hoch (d.h. es erfolgen “page steals”/”synch writes”)

• Lösung:

Erhöhen der Anzahl “cleaners”

Anpassen von CHNGPGS_THRESH

Möglicherweise Anlegen zusätzlicher separater Bufferpools für Daten und

Indexes

Aug2012 167



…. Und noch ein paar “Todsünden”

• Nicht korrekte Nutzung von “stored procedures”

Zu wenige: zu viel Netzverkehr / Netzverweilzeiten

Zu viele: nur 1 Statement pro Prozedur

Falsche Implementierungssprache

• Überbeanspruchen von UDF’s

Gerade “trusted UDF’s generieren “overhead”

Man kann häufig auch DB2-”built-in” Funktionen einsetzen

• Überbeanspruchen von LOBs, LONG VARCHAR etc.

Es gibt auch VARCHAR(32K) mit eben 32K Pages

• MINCOMMIT ist zu hoch angesetzt

Sollte auf dem „default“ 1 stehen bleiben

DB2 ist performant !!!!!!!!!

Aug2012 168


DB2 bietet ausserdem eine Reihe von „snapshots“ und Monitoringhilfen

Hier eine kleine Auswahl

• Database snapshot showing intra_parallelism monitor element . .

• Snapshot showing block remote cursor information ..

• dbm snapshot for connections

• db snapshot for connections

• dbm snapshot for sorting

• db snapshot for sorting

• db snapshot for locking

• db snapshot for buffer pools

• db snapshot for catalogcache_sz and pckcachesz

• Dynamic SQL snapshot

• …

• Application snapshot

• db2exfmt output for the problem query

• db2batch command

• db2batch output

DB2 bietet für jede Information Funktionen an!!!!!!!!!

Aug2012 169

DB2 for LUW DB2 for LUW –– LiteraturLiteratur

… und es gibt Literatur „satt“

Hier eine Auswahl

Administrative API Reference SC27-2435-02 September, 2010

Administrative Routines and Views SC27-2436-02 September, 2010

Call Level Interface Guide and Reference,Volume 1 SC27-2437-02 September, 2010

Call Level Interface Guide and Reference, Volume 2 SC27-2438-02 September, 2010

Command Reference SC27-2439-02 September, 2010

Data Movement Utilities Guide and Reference SC27-2440-00 August, 2009

Data Recovery and High Availability Guide and Reference SC27-2441-02 September, 2010

Database Administration Concepts and Configuration Reference SC27-2442-02 September, 2010

Database Monitoring Guide and Reference SC27-2458-02 September, 2010

Database Security Guide SC27-2443-01 November, 2009

DB2 Text Search Guide SC27-2459-02 September, 2010

Developing ADO.NET and OLE DB Applications SC27-2444-01 November, 2009

Developing Embedded SQL Applications SC27-2445-01 November, 2009

Developing Java Applications SC27-2446-02 September, 2010

Developing Perl, PHP, Python, and Ruby on Rails Applications SC27-2447-01 September, 2010

Developing User-defined Routines (SQL and External) SC27-2448-01 November, 2009

Getting Started with Database Application Development GI11-9410-01 November, 2009

Getting Started with DB2 Installation and Administration on Linux and Windows GI11-9411-00 August, 2009

Installing DB2 Servers GC27-2455-02 September, 2010

Installing IBM Data Server Clients GC27-2454-01 September, 2010

Message Reference Volume 1 SC27-2450-00 August, 2009

Message Reference Volume 2 SC27-2451-00 August, 2009

Aug2012 170

… und es gibt Literatur „satt“

Hier eine Auswahl (contn’d)

Net Search Extender Administration and User's Guide SC27-2469-02 September, 2010

Partitioning and Clustering Guide SC27-2453-01 November, 2009

pureXML Guide SC27-2465-01 November, 2009

Query Patroller Administration and User's Guide SC27-2467-00 August, 2009

Spatial Extender and Geodetic Data Management Feature User's Guide and Reference SC27-2468-01 September, 2010

SQL Procedural Languages: Application Enablement and Support SC27-2470-02 September, 2010

SQL Reference, Volume 1 SC27-2456-02 September, 2010

SQL Reference, Volume 2 SC27-2457-02 September, 2010

Troubleshooting and Tuning Database Performance SC27-2461-02 September, 2010

Visual Explain Tutorial SC27-2462-00 August, 2009

What's New for DB2 Version 9.7 SC27-2463-02 September, 2010

Workload Manager Guide and Reference SC27-2464-02 September, 2010

XQuery Reference SC27-2466-01 November, 2009

Installing and Configuring DB2 Connect Personal Edition SC27-2432-02 September, 2010

Installing and Configuring DB2 Connect Servers SC27-2433-02 September, 2010

DB2 Connect User's Guide SC27-2434-02 September, 2010

Information Integration: Administration Guide for Federated Systems SC19-1020-02 August, 2009

Information Integration: Configuration Guide for Federated Data Sources SC19-1034-02 August, 2009

Information Integration: SQL Replication Guide and Reference SC19-1030-02 August, 2009

Information Integration: Introduction to Replication and Event Publishing GC19-1028-02 August, 2009

DB2 for LUW DB2 for LUW –– LiteraturLiteratur

Aug2012 171

Aufgaben

DB2 for LUW DB2 for LUW –– AufgabenAufgaben

1. Welche Verteilungsoptionen kennt DB2 for LUW ?

2. Wozu sind Cursor in DB2 vorgesehen?

- Welche Typen gibt es ?

- Was ist bei ihrer Verwendung zu beachten =

3. Was verhindert DB2 mit seinen Lock-Prozessen?

- Welche Locktypen kennen Sie bei DB2 LUW 9.7 ?

- Welche Lock-Levels sind vorgesehen?

- Wie werden Indexe gelockt?

- Was verursacht der „drain“-Prozess?

4. Was ist eine LUW / UoR ?

- Wie wird eine LUW/UoR begrenzt?

- Wie heisst die Einheit (programmtechnisch), die sich hinter einer UoR verbirgt?

- Was ist ein SAVEPOINT ?

5. Wozu dient die Funktion EXPLAIN?

- Welche Informationen im EXPLAIN-Resultat sind wichtig?

- welche Funktion im DB2 erstellt die EXPLAIN-Daten?

6. Was sind die wichtigsten Utilities für DB2-AE und Optimierung?

Aug2012 172

Aufgaben

DB2 for LUW DB2 for LUW –– AufgabenAufgaben

7. Formulieren Sie folgende Queries nach den gehörten Empfehlungen in effiziente Queries um:

a) SELECT PERS_NR

, NACHNAME

, VORNAME

FROM V_MITARBEITER M

WHERE PERS_NR IN ( SELECT PERS_NR

FROM V_M_PROJ_AKT

WHERE PERS_NR IS NOT NULL

)

ORDER BY 2

b) SELECT ABT_NR

, AVG(GEHALT)

FROM V_MITARBEITER

WHERE ABT_NR IS NOT NULL

GROUP BY ABT_NR

HAVING AVG(GEHALT) <= ALL ( SELECT AVG(GEHALT)

FROM V_MITARBEITER

WHERE ABT_NR IS NOT NULL

)

8. Nennen Sie die Maxime für Optimierung bei DB2(relationalen DBMS)

Aug2012 173

DB2 for LUW DB2 for LUW –– Ende AP Teil IIEnde AP Teil II

Documents

IBM DB2 V9 - S.K. Consulting€¦ · Fähigkeit von DB2 LUW. Ein “feature” hierfür ist das Database Partitioning Feature (DPF). „Table partitioning“ “table partitioning”