DB2 DB-Design und physische Strukturen

DB2 –Physisches Design
Inhaltsverzeichnis
Standards, Tipps und Grundlagen
zu DB2-Datenmodellen und deren
Implementierung in der DB2-Physik
DB2
Effizientes DB-Design
und Physische Strukturen
© S.K.Consulting Services GmbH
++49 (0)162 4468790
Ausgabe
www.sk-consulting.de
11:Seite
2015
V77
20.01.1
1 von
DB2 –Physisches Design
Inhaltsverzeichnis
Inhaltsverzeichnis
1
VORWORT ....................................................................................................................... 8
2
GRUNDSÄTZLICHES ZU DB2 UND PERFORMANCE ................................................ 10
2.1
Optimierungspotentiale bei DB2 ........................................................................... 10
2.2
Logische Datenmodellierung ................................................................................. 11
2.3
2.3.1
2.3.2
2.3.3
2.3.4
Ziel der Datenmodellierung ................................................................................... 12
Integrität ................................................................................................................... 12
Redundanzen ............................................................................................................ 12
Wartbarkeit und Flexibilität ...................................................................................... 12
Wiederverwendbarkeit und Mehrfachverwendbarkeit .............................................. 13
2.4
Eigenschaften des logischen Datenmodells ........................................................... 13
2.5
Einsatzmöglichkeiten des logischen DM im Sofware-Life-Cycle(SLC) ............. 14
2.6
Logische Datenmodellierung - Beispiel ................................................................. 15
2.7
2.7.1
2.7.2
Physisches DB-Design und seine Umsetzung nach DB2 ...................................... 16
Allgemeine Vorgehensweise .................................................................................... 17
Vorgehensweise gemäß Ziel-DBMS ........................................................................ 18
3
DAS PHYSISCHE DB-DESIGN BEI DB2 ...................................................................... 19
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
Überführung des Informationsmodells - allgemeine Vorgehensweise ............... 19
Übernahme von Satztypen ........................................................................................ 20
Zusammenlegen von Satztypen ................................................................................ 20
Denormalisierung ..................................................................................................... 22
Trennen von Satztypen ............................................................................................. 23
Schaffung zusätzlicher Tabellen ............................................................................... 25
Ergänzen zusätzlicher Felder im physischen Datenmodell ....................................... 26
3.2
Grundsätzliche Regel bei DB2 ............................................................................... 27
3.3
Überführen der Beziehungen ................................................................................. 27
3.4
Einrichten der Zugriffspfade am Beispiel DB2 .................................................... 29
3.5
Festlegen der physikalischen DB-Struktur ........................................................... 30
3.6
Festlegen der DB2 Datentypen .............................................................................. 31
3.7
VARCHAR Alternativen zugunsten der Performance ....................................... 33
3.8
Weitere Limits in DB2 seit Version 8 bis V11 ...................................................... 34
4
EMPFEHLUNGEN ZUM PHYSISCHEN DESIGN VON DB2 DATENBANKEN ........... 36
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 2 von 77
DB2 –Physisches Design
Inhaltsverzeichnis
4.1
Allgemeines zum Design von DB2-Datenbanken ................................................. 36
4.2
Spezielle Empfehlungen zum physischen Design von DB2 Datenbanken ........... 40
5
DB2-OBJEKTE – STRUKTURIERUNGSEMPFEHLUNGEN ........................................ 41
5.1
Die Hierarchie der physischen DB2-Objekte ....................................................... 41
5.2
5.2.1
5.2.2
5.2.3
5.2.4
Datenbanken (Databases) ...................................................................................... 42
Die wichtigsten Definitionsparameter ...................................................................... 43
Autorisierungen ........................................................................................................ 44
Beispiele zur Definition von Databases .................................................................... 44
Gründe separate „Databases“ zu erzeugen .............................................................. 45
5.3
5.3.1
5.3.2
5.3.3
5.3.4
5.3.5
5.3.6
5.3.7
5.3.8
5.3.9
5.3.10
5.3.11
5.3.12
5.3.13
5.3.14
5.3.15
5.3.16
5.3.
5.3.18
5.3.19
5.3.20
5.3.21
5.3.22
Tabellenspeicher (Tablespaces) ............................................................................. 46
Die Privilegien für CREATE TS .............................................................................. 46
Die Namensvergabe für TS ...................................................................................... 47
Explizites Erzeugen eines Tablespace ...................................................................... 47
Implizites Erzeugen eines Tablespace ...................................................................... 47
Die DB2 Tablespace Typen ...................................................................................... 48
“EA-enabled” Tablespaces und Indexspaces ............................................................ 49
Simple table spaces ................................................................................................... 51
Universal Table spaces ............................................................................................. 51
Large Object Tablespaces (LOB TS)........................................................................ 61
“inline LOBs” (ab DB2 10) ...................................................................................... 64
XML Tablespaces ..................................................................................................... 68
Partitionierte Tablespaces ......................................................................................... 69
Ziel und Einsatz von PTS ......................................................................................... 71
Weitere Überlegungen zu PTS(Pros und Contra) ..................................................... 71
TS Limits ab V8 ....................................................................................................... 74
PTS-Typen seit DB2 Version 8 ................................................................................ 74
Einsatz und Aufbau von “segmented TS“ ................................................................ 85
Empfehlungen zu "tablespaces" ................................................................................ 88
Die Zuweisung von TS auf einen physischen Speicherplatz .................................... 89
TABLESPACE- Definition ...................................................................................... 90
Beispiele zum CREATE TS ..................................................................................... 97
Die TS und ihre Zustände(Status) ........................................................................... 100
5.4
5.4.1
5.4.2
5.4.3
5.4.4
5.4.5
5.4.6
5.4.7
5.4.8
5.4.9
5.4.10
5.4.11
5.4.12
5.4.13
5.4.14
5.4.15
5.4.16
5.4.17
5.4.18
5.4.19
Tabellen (Tables) .................................................................................................. 103
Die Privilegien für CREATE TABLE .................................................................... 103
Die Datentypen für DB2 Tabellen .......................................................................... 104
Strategien zur Anordnung von Tabellenspalten ...................................................... 105
Tabellendesign und JAVA Performance ................................................................ 106
Neue Tabellen- TS-Typen seit DB2 Version 8 ....................................................... 107
Die wichtigsten Definitionsparameter zur „table“ .................................................. 107
Die Größe von Tabellen (Tables) ........................................................................... 126
Große Tabellen (LARGE Tables) ........................................................................... 127
Partitionierung großer Tabellen (LTS) ................................................................... 128
VOLATILE Tables ................................................................................................. 132
„Global temporary Tables“ - CTT, DTT ................................................................ 133
“Clone Tables” ....................................................................................................... 137
"materialized query tables"(MQT's) und "automatic query rewrite"(AQR) ........... 143
„Temporal Tables“(ab DB2 10) .............................................................................. 145
„Hash organized Tables“ ........................................................................................ 167
DB2 9/10 – neue Datenformate(RRF/BRF etc) ...................................................... 170
Optimales Logging Verhalten bei DB2 Tabellen ................................................... 172
Referenzielle Constraints ........................................................................................ 172
„Table Check Constraints“ ..................................................................................... 173
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 3 von 77
DB2 –Physisches Design
Inhaltsverzeichnis
5.4.20
5.4.21
5.4.22
5.4.23
5.4.24
5.4.25
5.4.26
5.4.27
5.4.28
Definition einer generierten Spalte in einer neuen Tabelle ..................................... 174
INSERT-Algorithmen unter Nutzung des "partitioned Index" ............................... 176
INSERT-Algorithmen unter Nichtbeachtung des "partitioned Index".................... 179
"Combined Technique"-INSERT-Algorithmen ...................................................... 180
"Code-Tables" ........................................................................................................ 181
"Flip-Flop Tables" .................................................................................................. 182
"Hot Spots" ............................................................................................................. 183
Beispiele zum Table CREATE ............................................................................... 184
Weitere Tips zum Table – Design .......................................................................... 189
5.5
5.5.1
5.5.2
5.5.3
5.5.4
5.5.6
5.5.7
5.5.8
5.5.9
5.5.10
5.5.11
5.5.12
5.5.13
5.5.14
5.5.15
5.5.16
5.5.17
5.5.18
5.5.19
5.5.20
5.5.21
5.5.22
5.5.23
5.5.24
5.5.25
5.5.26
5.5.27
5.5.28
5.5.29
Indizes (Indexe) ..................................................................................................... 193
Indexstrukturen und Konzepte ................................................................................ 194
Die Indexarten ........................................................................................................ 198
Die Indexdefinition ................................................................................................. 198
Überlegungen zu Indizes ........................................................................................ 206
Die Definition eines PK Index ................................................................................ 208
Der Einsatz von "clustering" Indizes ...................................................................... 210
Der "partitioned“ und der „partitioning“ Index ..................................................... 212
"Non-Partitioning Secondary Indexes"(NPSI)....................................................... 213
"Data Partitioned Secondary Indexes"(DPSI)........................................................ 214
LOB Indexes .......................................................................................................... 216
XML Indexe ........................................................................................................... 216
Non-Unique Indexe ................................................................................................ 217
Ersatzstrategien zu „Non-Unique“ Indizes über Design-Maßnahmen .................... 219
Die Index-Klausel UNIQUE WHERE NOT NULL ............................................... 220
"Non-Partititioned" Index "Pieces" ......................................................................... 220
Indizes zur Vermeidung von Sort-Vorgängen ........................................................ 220
Indizes auf mehr als einer Spalte ............................................................................ 221
Anlegen und Wiederfinden von langen IX-Einträgen ............................................ 224
Match-Codes ........................................................................................................... 225
Ergänzen weiterer Felder ........................................................................................ 226
Die Indizierung von VARCHAR Spalten ............................................................... 227
Index “on expression”............................................................................................. 227
Weitere Tipps zum Index-Design ........................................................................... 230
„Indexing“-Strategien für optimale Performance ................................................... 232
Komprimieren von Indizes ..................................................................................... 237
Index Maintenance ................................................................................................. 246
Queries und mögliche Indizierungsstrategien ......................................................... 247
CREATE INDEX - Beispiele ................................................................................. 254
5.6
5.6.1
5.6.2
Views ...................................................................................................................... 256
Sinn und Zweck von Views .................................................................................... 256
Benutzen von „common table expression“ anstelle von VIEWs ............................ 258
5.7
Alias ....................................................................................................................... 259
5.8
5.8.1
5.8.2
5.8.3
5.8.4
5.8.5
5.8.6
5.8.7
5.8.8
5.8.9
5.8.10
Besondere DB2-Objekte ....................................................................................... 259
Sequences und „identity columns“ ......................................................................... 259
Die Entscheidung für “identities” und/oder “sequences” ....................................... 260
Beispiele für „sequences“ und „Identity columns” ................................................. 261
Tabellen mit mehrdimensionalem Clustering – MDC Tabellen ............................. 272
Materialized Query Tables – MQT’s ...................................................................... 272
“inline” - LOB Daten .............................................................................................. 275
Eigendefinierte (SQL-) Variable ............................................................................ 275
Eigendefinierte ARRAYs ....................................................................................... 276
“temporal special registers” .................................................................................... 278
Temporäre INCLUDE Variable.............................................................................. 279
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 4 von 77
DB2 –Physisches Design
6
Inhaltsverzeichnis
PARALLELE VERARBEITUNGSPROZESSE ............................................................ 280
6.1
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
6.1.6
6.1.7
6.1.8
6.1.9
6.1.10
6.1.11
6.1.12
6.1.13
6.1.14
6.1.15
Locking bei DB2.................................................................................................... 280
Die Begriffe beim "Locking ................................................................................... 280
Probleme beim “Locking“ ...................................................................................... 281
Verbessern der Lock-Verwendung ......................................................................... 281
Generelle Empfehlungen ........................................................................................ 282
Vermeiden von "false contention" .......................................................................... 283
Monitoring auf "false contention" .......................................................................... 283
Wie viel “contention” ist akzeptabel? ..................................................................... 283
Wie kann man “false contentions” reduzieren? ...................................................... 284
Verändern der Größe einer „lock structure“ ........................................................... 284
Dynamische Änderung der “lock structure“ Größe ................................................ 284
Ändern der “lock structure” Größe durch Neuaufbau ............................................ 285
Verringern der “lock entry size” ............................................................................. 287
Reduzieren der Zeit bis zur Auflösung von “contentions” ..................................... 288
Vermeiden von “partition locks” auf alle TS Partitions ......................................... 288
DB2 und Locking (Begriffe) .................................................................................. 290
6.2
6.2.1
6.2.2
6.2.3
6.2.4
Der LOCKSIZE-Parameter und seine Bedeutung ............................................ 292
Anzahl "rows per page" .......................................................................................... 292
Die Ebenen der Kontrolle ....................................................................................... 293
"Lock Escalation" ................................................................................................... 294
"row locking" und seine Kosten ............................................................................. 295
6.3
6.3.1
6.3.2
Index-Design und konkurrierende Verarbeitung .............................................. 296
Konkurrierende Verarbeitung UPDATE und SELECT(Fall 1) .............................. 298
Konkurrierende Verarbeitung UPDATE und SELECT(Fall 2) .............................. 299
7
QUERIES UND PARALLELVERARBEITUNG ............................................................ 301
7.1
7.1.1
7.1.2
7.1.3
7.1.4
7.1.5
8
Queries und Partitionierung ................................................................................ 301
Queries und Verarbeitung von PTS ........................................................................ 301
Der notwendige Parallelitätsgrad von Queries ....................................................... 305
Einrichten von PTS für Parallelverarbeitung .......................................................... 306
SQL Formulierungen für parallele Verarbeitung .................................................... 306
Wann ist keine Parallelverarbeitung möglich? ....................................................... 309
DB2 SPEICHERPLATZZUWEISUNG UND SPEICHERVERWALTUNG ................... 310
8.1
Das IBM Storage Management Subsystem ........................................................ 310
8.2
8.2.1
8.2.2
8.2.3
8.2.4
Speicherplatzgruppen („Storage Groups“) ........................................................ 310
Typen von Storage Groups ..................................................................................... 311
Speicherplatzgruppen und die Verteilung der Datasets .......................................... 313
Beispiele für Storage Groups .................................................................................. 314
Tipps zu STORAGE GROUPS .............................................................................. 314
8.3
8.3.1
8.3.2
8.3.3
8.3.4
8.3.5
8.3.6
8.3.7
Der Buffer Manager ............................................................................................. 316
Grobe Berechnung der Berechnung DB2-Datenbank-Buffer ................................. 316
Der Bufferpool für und seine Funktionalität ........................................................... 316
Bereitstellen der Bufferpools .................................................................................. 322
Funktionsweise des Buffermanagers ...................................................................... 323
Eine Methode zur “Bufferpool“ Dimensionierung ................................................. 325
Wichtige “Buffer Pool Performance Metrics” ........................................................ 328
Zusammenfassung BP ............................................................................................ 330
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 5 von 77
DB2 –Physisches Design
Inhaltsverzeichnis
8.4
8.4.1
8.4.2
8.4.3
DB2 Logging.......................................................................................................... 331
LOGBUFSZ - Logbuffer size ................................................................................. 333
LOGFILSIZ Parameter ........................................................................................... 334
MINCOMMIT – DB Konfigurationsparameter ...................................................... 334
8.5
8.5.1
8.5.2
DB2 Work Files ..................................................................................................... 336
„work file spaces“ ................................................................................................... 336
Hinzufügen von “worfle” ....................................................................................... 336
8.6
8.6.1
8.6.2
Temporary Tables ................................................................................................ 337
CTT’s und DTT’s im Vergleich ............................................................................. 337
Declared Temporary Tables und Performance der AP ........................................... 339
8.7
8.7.1
8.7.2
8.7.3
8.7.5
DB2 Katalog und Directory ................................................................................. 339
Performance - Indikatoren im Katalog ................................................................... 340
Überwachung der Speicherorganisation ................................................................. 342
Der Umgang mit PLAN und PACKAGES ............................................................. 345
DB2 und Extents ..................................................................................................... 346
9
DB2 - PERFORMANCE VON SUBSYSTEMEN .......................................................... 349
9.1
Asynchroner Preformat ....................................................................................... 349
9.2
9.2.1
9.2.2
9.2.3
Parallel "data set open" ....................................................................................... 350
Messumgebung ....................................................................................................... 350
“CPU bound” Testfall ............................................................................................. 351
“I/O bound” Testfall ............................................................................................... 351
9.3
9.3.1
9.3.2
“Virtual storage” Entlastung ............................................................................... 352
„Instrumentation Facility“ Verbesserungen ............................................................ 352
„Database address space” —Nutzung des “virtual storage” ................................... 352
9.4
9.4.1
9.4.2
„Evaluate uncommitted“...................................................................................... 353
Beschreibung von EVALUNC ............................................................................... 353
Empfehlung ............................................................................................................ 354
9.5
Reduziertes Logging für “variable-length rows” ............................................... 354
9.6
DDL – Verbesserung der Parallelverarbeitung ................................................. 354
9.7
Die IRLM-Umgebung und die LOCK-Anforderungen ..................................... 354
9.8
Traces..................................................................................................................... 355
9.9
9.9.1
9.9.2
9.9.3
9.9.4
9.9.5
9.9.6
9.9.7
Monitoring DB2 locking ....................................................................................... 356
Das Kommando DISPLAY DATABASE .............................................................. 356
Nutzung des "coupling facility structure activity report" aus RMF ........................ 357
Errechnen der Prozent von "contentions" ............................................................... 357
Anwenden des "DB2 statistics trace" ..................................................................... 357
Berechnen der prozentualen "global contentions" .................................................. 359
Nutzen des "DB2 accounting trace" ....................................................................... 359
Nutzen des "DB2 performance trace" ..................................................................... 360
10 Z/OS - FAKTOREN ...................................................................................................... 361
10.1
DSNZPARMS ....................................................................................................... 361
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 6 von 77
DB2 –Physisches Design
Inhaltsverzeichnis
10.2
Ausgabe der “current settings” ........................................................................... 362
10.3
Parameter die für „online“ Änderungen verfügbar sind .................................. 362
10.4
Beispiele von DSNZPARMS ................................................................................ 363
11 ANHANG ...................................................................................................................... 365
11.1
Checkliste zum physischen DB-Design DB2 ....................................................... 365
11.2
Limits bei DB2 (V11) ............................................................................................ 371
11.3
Abbildungsverzeichnis ......................................................................................... 374
11.4
Glossar ................................................................................................................... 381
11.5
Literaturhinweise.................................................................................................. 418
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 7 von 77
DB2 –Physisches Design
1
Vorwort
Vorwort
„Information steht heute und auch in Zukunft im Mittelpunkt wirtschaftlichen
Handelns. Information wurde zur treibenden Kraft der Informationsgesellschaft ... „. Das Zitat von John Naisbitt über die Ressource “Information” in seinem
Bestseller „Megatrends“ von 1988 sagt in Kürze immer noch alles über die Bedeutung der Information in unserer Gesellschaft aus.
Information ist ein denkbar abstrakter Stoff, der leichter, effizienter und produktiver
verwendet werden kann, wenn er geordnet und seinem sinnvollen Zusammenhang
gemäß dargestellt und angeboten wird. Datenbankmanagementsysteme sind die
Werkzeuge, mit denen Informationen strukturiert, verwaltet und bedarfsgerecht aufbereitet, geliefert werden können. Über sie werden moderne Informationssysteme
erst möglich.
DB2 von IBM ist eines dieser Datenbanksysteme, das in einer modernen ITUmgebung in der Lage ist, Informationsarchitekturen und -systeme über und für die
gesamte Unternehmenshierarchie umfassend zu ermöglichen.
Informationsverarbeitung ist dann effizient, wenn die richtigen Informationen zum
richtigen Zeitpunkt am richtigen Ort sind. Dazu bedarf es einer sorgfältigen Planung, einer technisch perfekten Implementierung und einer ständigen Kontrolle und
Abstimmung. Die Datenbank als Informationsspeicher muss in der Lage sein, die
gestellten Anforderungen sicher, konsistent und schnell zu erfüllen: Manche Informationen sind eben nur dann wertvoll, wenn sie hochaktuell sind. Und - jeder
Nutzer spezifischer Informationen kann seine eigenen individuellen und subjektiven
Ansprüche an diese Ressource “Information” stellen. Dies erfordert seitens der
Technologie hochperformante und flexible, aber auch stabile und sichere Systeme.
DB2 bietet alle Möglichkeiten, so eingestellt zu werden, dass alle erforderlichen Aktivitäten und Anwendungen auf effizienteste Art und Weise bedient werden. Dazu
müssen alle (System-)Parameter optimal gewählt und die Datenstrukturen nach
sorgfältiger Analyse in die physische DB2-Umgebung umgesetzt werden. Dies gilt
umso mehr, als mit der Ausweitung der Informationstechnik die Komplexität der Information selbst und die Quantität angebotener Datenmengen ständig zunimmt, andererseits die Informationsqualität aber weiter verbessert und die verfügbaren Informationen immer effektiver und genauer dargeboten werden sollen.
Denn: Ein Datenbanksystem selbst bringt den Unternehmen noch keinen oder
nur geringen Nutzen. Dieser entsteht erst aus der intensiven Nutzung verfügbarer
Information und der daraus resultierenden Wertschöpfung: Je mehr Nutzung, um so
besser für das Unternehmen. Die Erkenntnis, dass der Unternehmenserfolg, wie bei
den bekannten „klassischen“ Produktionsfaktoren - Finanzen, Material, Anlagen und
Personal - unmittelbar von einer erschöpfenden und werteffizienten Verwertung dieser „fünften Kraft“ Information abhängt, führte zur Suche nach neuen Konzepten in
einem neuen betriebswirtschaftlichen Umfeld - der Informationswirtschaft. Im
Zentrum dieser wirtschaftlichen Aspekte steht die Informationstechnologie - ihre
Möglichkeiten, ihre Produkte. Die Erwartungen an die Leistungsfähigkeit eines
DBMS sind folglich enorm hoch.
In dieser Handbuchserie werden unter DB2 Performance-Gesichtspunkten alle
wichtigen Fragen zu und die Möglichkeiten bei DB2 thematisiert. Die Serie besteht
aus folgenden Büchern:
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 8 von 77
DB2 –Physisches Design
Vorwort
01_Die Umgebung von DB2 – Eine Architekturübersicht
02_DB2 und das Relationenmodell von Dr. Codd
03_DB2 und SQL-Performance
04_Physisches DB-Design und DB2-Performance
05_ DB2 und effiziente Anwendungsentwicklung
06_Administration von DB2 Umgebungen
07_Tunig-Beispiele zu DB2: Erfahrungen aus der Praxis
08_DB2 im Client-Server Umfeld
09_Tools und hilfreiche Produkte zu DB2
Die Handbuch-Serie besteht natürlich nicht aus „Manuals“ im Sinne von Systemdokumentation – wie sie vom Hersteller sowieso angeboten wird -, sondern vielmehr
ist beabsichtigt DB2 vor unter Nutzbarkeits- und Performance-Gesichtspunkten
möglichst umfassend darzustellen.
Die gesamte Serie ist für Kenner, nicht in erster Linie für Neulinge im Umgang mit
DB2 konzipiert.
Das vorliegende Handbuch beschäftigt sich mit dem Thema: „Physisches DBDesign und DB2-Performance“ Es soll als Leitfaden dienen, das System ursprünglich, ständig und zukünftig optimal planen und einstellen zu können - immer
mit dem Ziel, höchstmöglicher Performance in allen direkt betroffenen und umliegenden Betrachtungsfeldern.
Vergessen Sie dabei nicht, dass man sich gerade beim Thema „Physisches Design
und physische DB2-Parameter“ natürlich nahe an der Hardware – sprich DASDs,
SANs etc. – bewegt. Entsprechend unterschiedlich sind auch die Zugriffs- und I/OStrukturen für das jeweilige DB2 zu planen und einzustellen. Trotz gemeinsamen
Namens ist DB2 LUW (Unix, Linux, Windows) sehr unterschiedlich zu Db2 for z/OS
– man könnte sagen: Es gibt kaum Gemeinsamkeiten – nicht einmal in der Terminologie, auch wenn die Begriffe gleich klingen.
Viel Spaß beim Lesen und viel Erfolg bei der Nutzung von IBM’s DB2 for z/OS und
auch von DB2 LUW.
Mit freundlichen Grüßen
S.K. Consulting Services GmbH
Sepp Kraus
Für die Mitarbeit an diesem Handbuch bedanken wir uns insbesondere bei den Firmen
ARAL AG, Bochum
AXA Versicherungen, Köln
BMW AG, München
Itellium AG, Fürth
VWFS AG, Braunschweig
IT-Verlag, Sauerlach b. München
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 9 von 77
DB2 –Physisches Design
2
2.1
Grundsätzliches zu DB2 und Performance
Grundsätzliches zu DB2 und Performance
Optimierungspotentiale bei DB2
Die Optimierungspotentiale bei relationalen Datenbanksystemen unterscheiden sich
generell – auch zwischen DB2 und Oracle, SQL Server und SYBASE - nur minimal.
Sicher ist, dass die höchsten Potentiale, um diese relationalen Datenbanksysteme
schneller zu machen im Bereich der Abfragesprache SQL und damit im Umfeld
der Anwendungsentwicklung und der Programme zu suchen ist (siehe Grafik unten).
Eine weitere Fehlerquelle ist das physische DB-Design, gefolgt von der Einstellung
der Systemparameter im DB2 selbst und im Betriebssystem (OS/390, z/OS, AIX,
UNIX usw.)
Empfehlenswert ist es, im Tuningfall dort zuerst zu suchen, wo das größte Potential
zum Lösen der Tuningaufgaben existiert. Man darf nur die anderen Bereiche nicht
vergessen.
In diesem Handbuch werden vorrangig die Problematiken des physischen Designs bei DB2 behandelt. Die Problematik der SQL-Verarbeitung findet man im
Band „SQL und DB2 Performance“ aus dieser Reihe „Tuning und Performance für
DB2-Umgebungen“.
2 = DB2
System
(10%)
3 = phys.
DBDB-Design
(20%)
4 = Anwendung
(60%)
1
2
3
4
1 = OS
System
(10%)
Bild-01: Tuningpotentiale im DB2-Umfeld
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 10 von 77
DB2 –Physisches Design
2.2
Grundsätzliches zu DB2 und Performance
Logische Datenmodellierung
Die Leistungsfähigkeit heutiger Informations- und Kommunikationstechnologien schafft eine Vielzahl von effizienten Möglichkeiten für die Informationsversorgung eines Unternehmens.
Unabdingbare Voraussetzung für die zielgerichtete Nutzung dieser Technologien ist aber die methodische und organisatorische Behandlung der Resource
"Information" selbst.
Die Informationsanalyse dient der strukturierten Beschreibung aller für das Unternehmen (oder den Unternehmensteil) relevanten Informationen.
Sie schafft somit die organisatorische und analytische Basis für eine zukunftsorientierte Informationswirtschaft.
Zur Ermittlung des logischen Informationsmodells wird die Begriffswelt eines Untersuchungsbereichs bestimmt, definiert und in einem "Top-Down"Prozess schrittweise verfeinert.
Das Ergebnis stellt eine detaillierte Beschreibung aller für die Anwendung relevanten Begriffe dar, untergliedert nach
 Informationsobjekten (entity types),
 deren Eigenschaften (attribute types),
 sowie der Beziehungen (relationship types) der Informationsobjekte untereinander.
Ziele der methodischen Behandlung der Ressource "Information"
sind:

Erfassen und ordnen sämtlicher relevanter Begriffe für den betreffenden
Untersuchungsbereich im Unternehmen

Fortschreibung der Ergebnisse bei betrieblichen Änderungen oder Erweiterungen des Untersuchungsbereichs

Förderung der Kommunikation mit der Fachabteilung zur qualitativen Abstimmung der Untersuchungsergebnisse

Unabhängigkeit von der technischen Realisierung der Informationshaltung
oder –verarbeitung

Grundlage für weitergehende Datenanalyse und Datenadministration
Dabei gelten die Nebenbedingungen:
(1) Die "business processes" des Untersuchungsbereichs liefern wichtige Informationen zur Konsistenz und Richtigkeit des Informationsmodells
(2) Die Ergebnisse der Informationsmodellierung können mit Tools einfacher
und sicherer verwaltet und dokumentiert werden als per Hand
(3) Eine geeignete Methode führt zum Erfolg, wenn sie richtig eingesetzt wird
(egal ob ERM, UML, ISA, usw. ) und
(4) "...A fool with a tool is still a fool ..."
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 11 von 77
DB2 –Physisches Design
2.3
Grundsätzliches zu DB2 und Performance
Ziel der Datenmodellierung
Ziel der Datenmodellierung ist es, qualitativ hochwertige Datenstrukturen zu erzeugen. Die Qualität von Datenstrukturen lässt sich an folgenden Kriterien festmachen:






2.3.1
Ein Maximum an Integrität und
ein Minimum an Redundanz
Wartbarkeit, Stabilität und Flexibilität
Wiederverwendbarkeit und Mehrfachverwendbarkeit („sharability“
Konsistenz
Nutzbarkeit und zeitgerechte Zugriffsmöglichkeiten
Integrität
Die Integrität der Daten steht an erster Stelle. Niemandem nutzt eine superschnelle
Applikation, die einfach zu warten ist und deren Ergebnisse sich vielfach weiterverwenden lassen, wenn man sich auf eben diese Ergebnisse nicht verlassen kann.
Drei Punkte sind wichtig für die Integrität eines Datenmodells:



2.3.2
Bedeutung der Information für das Unternehmen evaluieren
(Was ist ...?)
Redundanzen vermeiden - eine Information an einer Stelle („one fact in
one place“)
Datenkonsistenz durch Integritätsmechanismen , z.B. RI, „constraints“
usw. sichern
Redundanzen
Redundanzen sind im logischen Modell vollkommen überflüssig.
Die Maxime „one fact in one place“ beschreibt die Tatsache, dass eine Information einmal im System vorhanden – von allen Seiten konsistent genutzt werden können
sollte.
Redundanzen – vor allem ungewollte – führen immer zu Verarbeitungsanomalien;
d.h. eine Änderung der Information an einer Stelle muss aus Integritäts- und Konsistenzgründen an n anderen Stellen auch noch durchgeführt werden, bevor die Dateninhalte wieder alle gleich sind.
Es ist dabei genau zu unterscheiden zwischen Redundanz, Replikation, Denormalisierungsstrukturen usw.
2.3.3
Wartbarkeit und Flexibilität
Die Wartung einer Datenbank teilt sich in technische und strukturelle Aspekte. Zu
den technischen Aspekten gehört zum Beispiel das Re-Indizieren und Sichern, Laden von Tabellen. Hier mag der Hinweis reichen, dass zur technischen Wartung einer Datenbank i.d.R. gute Werkzeuge von Drittanbietern zur Verfügung stehen.
Die strukturellen Aspekte der Wartbarkeit spielen bei der Datenmodellierung jedoch
eine große Rolle. Wartbarkeit und Integrität sind (anders als die Performance) Ziele,
die sich nicht widersprechen.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 12 von 77
DB2 –Physisches Design
Grundsätzliches zu DB2 und Performance
So macht eine sauber normalisierte Datenstruktur sicher weniger Probleme bei notwendig werdenden Erweiterungen oder Änderungen als eine nicht normalisierte
Struktur. Gleichzeitig sind normalisierte Strukturen der beste Garant für integre und
redundanzfreie Daten.
2.3.4
Wiederverwendbarkeit und Mehrfachverwendbarkeit
Auch das Qualitätskriterium Wiederverwendbarkeit hat zwei unterschiedliche Aspekte. Zum einen kann bei der Datenmodellierung darauf geachtet werden, dass die
entstehenden Strukturen wiederverwendbar sind. Dies führt dann zu der Aufteilung
einer Gesamtaufgabe in einzelne Module, die jeweils eine eigene, fest umrissenen
Aufgabenstellung haben und nur über ihre definierten Schnittstellen miteinander
kommunizieren. Der erfahrene Datenbank-Entwickler wird hier gleich eine mögliche
Performancefalle wittern. Zu Recht - auch die strukturelle Wiederverwendbarkeit ist
ein Ziel, dass häufig im Widerspruch zum Qualitätskriterium „Performance“ steht.
Die zweite Art der Wiederverwendbarkeit betrifft die Daten selbst. Ein mögliches
Modellierungsziel kann sein, den gleichen Datenbestand aus mehreren Applikationen heraus nutzen zu können. Dann werden vielleicht nicht alle Felder einer Tabelle
von jeder Applikation genutzt. Aus der Sicht einer einzelnen Applikation heraus sind
diese Felder schlicht überflüssig. Der negative Einfluss auf die Performance ist dabei aber gering.
2.4
Eigenschaften des logischen Datenmodells
Eigenschaften des logischen Datenmodells sind am ehesten durch folgende Attribute zu beschreiben:
→ umfassend
→ vollständig (realitätsgemäß)
→ widerspruchsfrei
→ anwendungsneutral
→ systemneutral
→ stabil
→ flexibel
Alle diese Eigenschaften auf ein Datenmodell zu projezieren verlangt viel Arbeit, ein
strukturelles Vorgehen und Erfahrung.
Ein logisches Datenmodell dient letztendlich auch, Klarheit in einen betrieblichen
Untersuchungsbereich zu bringen.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 13 von 77
DB2 –Physisches Design
2.5
Grundsätzliches zu DB2 und Performance
Einsatzmöglichkeiten des logischen DM im Sofware-Life-Cycle(SLC)
Der methodische Baustein der Informationsanalyse (IA mit der LDM) lässt sich in
verschiedenen Phasen des SLC sinnvoll einsetzen.
Bild-02: Einsatz des LDM im Software-Life-Cycle
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 14 von 77
DB2 –Physisches Design
2.6
Grundsätzliches zu DB2 und Performance
Logische Datenmodellierung - Beispiel
Das logische Datenmodell enthält lediglich die fachlich/logischen Elemente der betrachteten Realität: Untersuchungsbereich.
Das Modell wird mit all seinen Eigenschaften und Attributen beschrieben.
Bild-03: Logisches DM(LDM) - Beispiel
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 15 von 77
DB2 –Physisches Design
2.7
Grundsätzliches zu DB2 und Performance
Physisches DB-Design und seine Umsetzung nach DB2
Auf dem Markt gibt es eine Vielzahl von Datenbankmanagementsystemen, die
sich zwar leicht in Gruppen, wie

Relational

CODASYL

Hierarchisch

Objektorientiert(objektrelational)
einteilen lassen, sich aber in ihren Leistungsmerkmalen deutlich voneinander u nterscheiden.
Der physische Designschritt erfolgt erst NACH allen anderen fachlich orientierten
Analyse- und Modellierungsschritten.
abgestimmtes
InformationsModell
FunktionsAnalyse
Phys.
DB-Design
Ab
st
im
m
un
g
InformationsAnalyse
Kanonische
Synthese
FunktionsModell
Elem.Funktion
InformationsModell
Datensichten
und "dataflow"Modell
Bild-04: Der Vorgang der Modellierung für IT-Systeme - Übersicht
Ziel des systemspezifischen DB-Design ist es, ausgehend vom konzeptionellen Informationsmodell, systematische Überführungsschritte
in das Ziel-DBMS festzulegen, in denen insbesondere die Stärken des
Zielsystems berücksichtigt werden.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 16 von 77
DB2 –Physisches Design
2.7.1
Grundsätzliches zu DB2 und Performance
Allgemeine Vorgehensweise
Basis des physischen DB-Designs bilden die methodischen Säulen: Konzeptionelles
Informationsmodell, Prozess- oder Funktionsmodell und ein „eventgetriebenes“
Konditionsmodell: Dabei liefern diese beiden Ergebnistypen generell folgende Anhaltspunkte für das Physische Datenbank-Design:
Konzeptionelles Informationsmodell
Funktionsmodell
 Grafik
 Grafik
 Dokumente
 Beschreibung
 (Mengen)
 (Häufigkeiten)
 („business rules" / Domänen)
 (Zugriffsarten / Verarbeitungswege)...
Bild-05: Allgemeine Vorgehensweise beim Informationsdesign
Nach der Abstimmung der Informationsbedarfe aus dem FM und dem Ergebnis der
Datenmodellierung entsteht ein QS-gesichertes logisches DM, das folgende Eigenschaften aufweisen sollte:
 Vollständigkeit
 Widerspruchsfreiheit
Das heißt:
1)
Alle Informationsobjekte, die in den Funktionsabläufen benutzt werden, müssen vollständig definiert sein
2)
Alle Attribute der Prozessmitteilungen müssen Attributen der definierten Informationsobjekte entsprechen.
3)
Alle Informationsobjekte der Untersuchungsbereichs müssen von den zugehörigen Prozessen gelesen und/oder modifiziert werden
Jetzt ist das logische Modell bereit zur Überführung in ein physisches, datenbankorientiertes Modell – beim RIS in die Db2-Physik. Dabei werden aber immer
noch Aktionen erforderlich, die nichts direkt mit dem DBMS zu tun haben.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 17 von 77
DB2 –Physisches Design
2.7.2
Grundsätzliches zu DB2 und Performance
Vorgehensweise gemäß Ziel-DBMS
Jedes Ziel-DBMS, ob relational oder von anderer Architektur, verlangt nach individueller Anpassung der konzeptionellen Strukturen unter Performance- und Nutzungsgesichtspunkte.
Bild-06: Überführen des logischen DM in ein physisches DM (PDM)
Hier werden die Datenobjekte sowohl an die Gegebenheiten von zentralem DBMS im Client-Server-Umfeld aber auch an dezentrale Anforderungen - angepasst.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 18 von 77
DB2 –Physisches Design
3
3.1
Empfehlungen zum physischen Design bei DB2 DBs
Das physische DB-Design bei DB2
Überführung des Informationsmodells - allgemeine Vorgehensweise
Die Überführung kann beim physischen DB-Design aus den folgenden Schritten
kumulativ oder selektiv erfolgen:
1. Überführung des Informationsmodells
 Übernahme der logischen Satztypen/“entities“
 Zusammenlegen von Satztypen/“entities“
 Trennen von Satztypen/“entities“
 Normalisierung
 Denormalisierung
 Festlegen der Datentypen der Attribute
2. Ergänzen des DB-Modells
 Schaffung zusätzlicher Tabellen
 Ergänzen der Tabellen um zusätzliche Felder(Summen, Status,...)
 Definition der PK
 Definition der „clustering“ IX
 Definition der Beziehungen (PK – FK Beziehungen)
 Ergänzen der Datenbankobjekte um Triggers, „stored procedures“, UDFs
3. Überführen der Beziehungen
 Behandlung von 1 : 1 "relationship"
 Behandlung von 1 : n Beziehungen
4. Einrichten der Zugriffspfade
 Behandlung der Einstiegspunkte(Suchkriterien)
 Auswahl der physischen Zugriffspfade
5. Festlegen der DBMS-spezifischen Parameter
 Blockgröße / Satzgröße
 Speicherplatzgrößen
 physische Speicherungsfolgen
 organisatorisch/technische Einflüsse
 Steuerparameter für das DBMS usw.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 19 von 77
DB2 –Physisches Design
3.1.1
Empfehlungen zum physischen Design bei DB2 DBs
Übernahme von Satztypen
In der Regel können bei relationalen Datenbanksystemen die konzeptionellen Strukturen zumindest teilweise 1:1 in die Datenbank übernommen werden, d.h. EntityType = Tabelle
Die Gefahr dabei ist, dass in der Datenbank viele "kleine" Tabellen entstehen, die im
Applikationsumfeld zu übermäßigen "Join"-Aktivitäten führen und damit die Performance, abhängig von der Anzahl solcher Aktionen, durchaus negativ beeinflussen.
Daher gilt grundsätzlich die Empfehlung, das konzeptionelle Datenmodell (KDM)
gemäß den Möglichkeiten der DBMS-Physik zu transformieren, sodass der technische Aufwand des Systems für den zukünftigen Produktionsbetrieb minimiert werden kann.
Beispiel:
Bild-07: Übernahme von Satztypen beim Informationsdesign
3.1.2
Zusammenlegen von Satztypen
Bei einer 1:1 - Beziehung kann eine Zusammenlegung günstig sein, falls beide
Satztypen in wichtigen Benutzersichten gemeinsam verwendet werden.
In den Applikationen ist dann kein „join" erforderlich.
ACHTUNG: Man berücksichtige die Einstiegspunkte, die
von den Funktionen vorgegeben werden. – So ist
in diesem Beispiel Kd-konto als Tabellenspalte
ein Schlüssel- bzw. Index-Kandidat
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 20 von 77
DB2 –Physisches Design
Empfehlungen zum physischen Design bei DB2 DBs
Bei einer 1:n - Beziehung ist eine Zusammenlegung von Satztypen dann sinnvoll,
wenn der n-Satztyp ISOLIERT im Informationsmodell steht.
Unter isolierten Satztypen versteht man Entitätstypen, die zwar von einer "relationship-type" erreicht werden, die aber in keiner Beziehung zu anderen "entity types"
stehen. Eine Zusammenlegung ist insbesondere dann empfehlenswert, wenn der
Wunsch nach Detaildaten im abhängigen Objekt durch die Verfügbarkeit beispielsweise der aktuellsten ("letzten") Daten zum Objekt ersetzt werden kann.
Im folgenden Beispiel wird das Vorgehen dadurch erleichtert, dass die Anzahl abhängiger "entities" pro übergeordnetem "entity" begrenzt ist.
Bild-08: Zusammenlegung von Satztypen beim Informationsdesign
ACHTUNG
Beachten Sie, inwieweit Informationen verloren gehen, wenn
Sie "entity-types" aus Performance-Gründen zusammenlegen.
KEINEZUSAMMENLEGUNG bei unterschiedlicher Existenzberechtigung / -dauer!!!
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 21 von 77
DB2 –Physisches Design
3.1.3
Empfehlungen zum physischen Design bei DB2 DBs
Denormalisierung
Denormalisierung bedeutet nichts anderes, als Datenstrukturen, die sich in der 3.
Normalform befinden, wieder in eine der vorgeordneten Normalformen zurückzuführen.
Denormalisierte Strukturen helfen insbesondere bei relationalen DBMS JOINOperationen zu verhindern und so die Performance in bestimmten Bereichen, d.h.
beim LESEN ( SELECT ...), zu steigern.
Beispiel:
Relation:
KUNDE
normalisiert: KUNDE
ORT
{ KD_NR, KD-Name, KD-PLZ, KD-ORT, KD-Strasse ..}
{ KD-NR. KD-Name, KD-OKZ, KD-STRNR ....}
{ OKZ, O-PLZ, O-ORT, EINWOHNERZAHL...}
KUNDE_WOHNT_IN
{OKZ. O-STRNR. KD-STRNR. ETAGE. RAUM...}
STRASSE
{OKZ, O-STRNR. STR_BEZEICHNUNG ...}
Unter der Annahme, dass die Kundendaten in 90% aller Fälle auch die Adressdaten
des Kunden enthalten müssen, ist eine Denormalisierung wie folgt empfehlenswert:
KUNDE
{ KD-NR, KD-NAME,..., KD-PLZ, KD-ORT, KD-STR,
KD-STR-NR, KD-HAUS, KD-ETAGE,....}
ACHTUNG
Bei jeder Denormalisierung entstehen Redundanzen, die
GEPFLEGT werden müssen, um die DB-Inhalte
KONSISTENT zu halten
Als Bedingung und sinnvolle Voraussetzung für denormalisierte Strukturen
gilt:
1.
Die Denormalisierung spart in hohem Maße DBMS-Zugriffe
("Joins")
2.
Der Änderungsaufwand der Redundanzen ist überschaubar
3.
Die Änderungshäufigkeit der entstandenen redundanten Daten ist
möglichst gering !
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 22 von 77
DB2 –Physisches Design
3.1.4
Empfehlungen zum physischen Design bei DB2 DBs
Trennen von Satztypen
Die Trennung von Satztypen kann dann sinnvoll sein, wenn die Daten eines Entitätstyps von vollständig unterschiedlichen Organisationseinheiten genutzt und bearbeitet werden sollen, vorgangsorientierte Daten verarbeitet und zur Verfügung
gestellt werden sollen.
Beispiel:
BANKTRANSAKTIONEN
•
•
TRANS-FILIALE
TRANS-LFD-NR
TRANS-ART
……..
TRANS-STATUS-1
TRANS-STATUS-2
…………
( 10 Mio. Zeilen )
bezeichnet den Zustand im
Bearbeitungsverlauf:
B = gebucht ( 5 Mio )
G = Vorlage zur Genehmigung
( 1 Mio )
C = zur Überweisung freigegeben
( 4 Mio )
D = überwiesen ( 27 Mio inkl.
Historiendaten)
usw.
bearbeitet
( 8 Mio / 2 Mio )
Bild-09: Trennen von Satztypen beim Informationsdesign
Im o.g. Beispiel besteht das Problem darin, dass Anforderungen wie "...alle genehmigungspflichtigen Transaktionen... " oder " ... alle zur Überweisung freigegebenen
Transaktionen ..." aber insbesondere " ... alle nicht bearbeiteten Transaktionen ..."
bei DB2 zu einem "tablespace-scan", d.h. zum sequentiellen Lesen von 10 Millionen Datensätzen führen würde, da eine Indizierung über Spalten mit zu wenigen
Ausprägungen keine DB2-adäquate Selektivität aufweisen könnte.
Möglicherweise liegt in einem solchen Fall ein Analyse-Fehler vor. Andernfalls
könnte folgende Empfehlung gelten, um die benötigten Teilmengen möglichst genau
einzuschränken:
Relation_1:
GEBUCHTE_TRANSAKTIONEN { .... }
Relation_2: GENEHMIGUNGSPFLICHTIGE_TRANSAKTIONEN { .... }
Relation_3: ……
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 23 von 77
DB2 –Physisches Design
Empfehlungen zum physischen Design bei DB2 DBs
ACHTUNG
Das Problem von Kombinationen verschiedener StatusInformationen kann durch diese Vorgehensweise
NICHT gelöst werden: REDESIGN ist angesagt
Sollen die gleichen Daten mehreren unterschiedlichen Organisationseinheiten (OE) zur
Verfügung gestellt werden, z.B. in "Client-Server"- oder verteilten Umgebungen, so stehen hier seitens des DBMS die Möglichkeiten der
-
Replikation
-
Partitionierung
von Tabellen zur Verfügung.
Vorausgesetzt die technische Implementierung des DBMS bietet diese "features" in
der aktuellen Version an.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 24 von 77
DB2 –Physisches Design
3.1.5
Empfehlungen zum physischen Design bei DB2 DBs
Schaffung zusätzlicher Tabellen
In vielen Fällen kann die Schaffung zusätzlicher Spalten/Tabellen aus Performance-Gründen nützlich sein. Dies gilt für
 Ergebnis- und Summendaten

Unterstützung von Aggregatsfunktionen im
Rahmen von Auswertungen
 Historischen/Historisierten Daten
Eingestreut
separat
Bild-10: Aufbau zusätzlicher Tabellen beim Informationsdesign
Problematisch kann dies bei referentieller Integrität sein !
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 25 von 77
DB2 –Physisches Design
3.1.6
Empfehlungen zum physischen Design bei DB2 DBs
Ergänzen zusätzlicher Felder im physischen Datenmodell
Zusätzliche Felder sind Felder, die Zugriffe beschleunigen können, Updates sicherer
machen, Joins verhindern helfen usw. aber aufgrund der konzeptionellen Datenmodellierung nicht erforderlich wären.
Beispiele:
 Abgeleitete Daten
z.B.
Brutto-Betrag, Summenfelder
 Kennzeichen, ob in abhängigen Tabellen weitere Informationen vorliegen
oder nicht; z.B.
Zweit-/Dritt-Adressen
Beispiel: optionale Lieferadressen, Rechnungsadressen usw. deren Existenz in der
jeweiligen „Haupttabelle“ mit „Y“ oder „N“ angezeigt wird:
SELECT
FROM
…….
WHERE
<columns>
account a LEFT OUTER JOIN
ON a.accnt# = b.accnt#
AND a.optionalBill = ‘Y’
LEFT OUTER JOIN
ON a.accnt# = c.accnt#
AND a.optionalAdress = ‘Y’
a.accnt#
=
billing b
address c
1
Bild-11: Zusätzliche Kennungen bei optional vorhandenen „entities“/“rows“
 Für zusätzliche Zugriffsmöglichkeiten
z.B. Matchcode, phonetisierte Schreibweise, Großschrift
 Als Protokollierungs- und Steuerungsinformation
z.B. Datum letzte Änderung, Langfrist-Sperrkennzeichen
 Für Zugriffsschutz
z.B. Code für Benutzerberechtigung
 Gültigkeitsinformationen
 Technische Informationen
z.B. Visualisierungsinformationen (CRT, 3270 ... )
 Weiterverarbeitungsinformationen
z.B. für Datawarehousing, Reporting, Aggregationen ...
 Spezielle Sicherheitskennzeichen
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 26 von 77
DB2 –Physisches Design
3.2
Empfehlungen zum physischen Design bei DB2 DBs
Grundsätzliche Regel bei DB2
Speicherplatzersparnis ist nicht so wichtig wie weniger Tabellen.
Zum Thema Komprimierung vorab folgende Informationen:
Der Einsatz von Komprimierungsfunktionen macht viele Speicherplatzüberlegungen
annähernd überflüssig.
Die Komprimierung heute bringt bei der Verarbeitung von riesigen Datenmengen
(und bei SAP) insofern Vorteile, als mehr Daten in eine Datenpage passen und somit mit einem physischen I/O mehr Daten gelesen werden, wodurch bei gleicher
Verarbeitung auch noch I/O’s gespart werden können.
So gesehen lautet die Empfehlung bei einer physischen Struktur, die EINE Tabelle
in EINEM Tablespace vorsieht eindeutig COMPRESS YES für den TS zu setzen.
Die heute möglichen Kompressionsraten und die damit verbundenen Platzersparnisse erfordern nur marginal höhere Aufwände bei CPU- und Laufzeiten bei den
Prozessen:
3.3

Eine mögliche Kompressionsrate bei kommerziellen Daten liegt bei
40 - 70 %

Die Erhöhung der CPU-Zeit wird mit ca. 15 %* kalkuliert

Die Verringerung der Laufzeit serieller Prozesse liegt bei ca. 10 %*
(stark schwankend in Einzelfällen!!)
(*)
heute fallen die genannten Zeitverluste noch geringer aus, da die meisten
„compression routines“ hardware-unterstützt ablaufen und vollständig in der
Betriebssystemumgebung integriert sind.
Überführen der Beziehungen
Beziehungen werden über Schlüsselredundanzen realisiert: „primary key"  „foreign key".
Dabei ist es unbedingt wichtig zu wissen, ob nur eine oder BEIDE Richtungen der
Beziehungen benötigt werden.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 27 von 77
DB2 –Physisches Design
Empfehlungen zum physischen Design bei DB2 DBs
Bild-12: Beispiel-1 - Übernehmen der Beziehungen beim Informationsdesign
Im ersten Fall könnte man einen aus der "auf-nr" und der "kd-nr" zusammengesetzten Identifikator verwenden. Im zweiten Fall kann man davon ausgehen, dass
eine „künstliche“ Auftragsnummer - laufende Nummer - definiert wurde, die mit
den Kundendaten direkt nichts zu tun hat. Die "kd-nr" kommt lediglich als „foreign
key“ als Abbildung der Beziehung zwischen KUNDE und AUFTRAG zum Einsatz.
Beziehungen werden über Schlüsselredundanzen realisiert:
„primary key“
„foreign key“
Es ist dabei wichtig zu wissen, ob nur eine
oder BEIDE Richtungen der Beziehungen benötigt werden.
Eine vollständige Indizierung der PK/FK-Beziehungen ist bei DB2 dringend zu
empfehlen:
 Von Tabelle zu Tabelle
 Bei „self referencing tables“
 Pro Tabelle sollte mindestens definiert sein:
1 Primary Key (PK)
1 „clustering key (CK)“
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 28 von 77
DB2 –Physisches Design
Empfehlungen zum physischen Design bei DB2 DBs
Bild-13: Beispiel-2 - Übernehmen der Beziehungen beim Informationsdesign
3.4
Einrichten der Zugriffspfade am Beispiel DB2
DB2 kennt Methoden für


„Index based" Zugriffe und
„tablespace scan"
Ziel eines effizienten physischen DB-Designs wird es sein, indexbasierte Zugriffe
zu ermöglichen.
Ob DB2 dann aber Indizes nutzt, hängt nicht allein vom DB-Design, sondern unter
anderem und vor allem auch von der Formulierung der SQL-„Query" ab. Allerdings
muss man pro „Tabelle" mindestens einen Index zur Verfügung stellen:


einen „primary key index"
evtl. „cluster index"
Ausgangspunkt für die Festlegung sind dabei die Einstiegspunkte der konzeptionellen Datenstruktur und die Nutzung der Daten in den Anwendungen!
Man beachte:
Bei konkurrierenden Einstiegspunkten sollte der Index gewählt werden, der möglichst „hochwertig" ist:
1. „cluster index"
2. „primary key" oder „unique index"
3. „normaler" Index
Wird der Datenbestand sehr häufig erweitert (INSERT ) oder verringert (DELETE),
so sollten im Sinne der Performance möglichst SELEKTIVE , aber WENIGE Indizes auf den Tabellen liegen(siehe auch Kapitel: "Indizierung" Pkt. Fehler! Verweisquelle konnte nicht gefunden werden. ff.).
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 29 von 77
DB2 –Physisches Design
3.5
Empfehlungen zum physischen Design bei DB2 DBs
Festlegen der physikalischen DB-Struktur
1. Berechnen der TS-Größe
a)
b)
c)
d)
e)
primary space" / „secondary space"
Bestimmen zusammengehöriger Tabellen für EINEN TS
Bestimmen des TS-Typs (STS, PTS, normaler TS)
Festlegen des Füllgrades (PCTFREE, FREEPAGE)
COMPRESS YES/NO
2. Berechnen der IX-Parameter und der Index-Größe
3. Bestimmen der LOCKING und ISOLATION - Parameter
a)
b)
c)
d)
LOCKSIZE
ISOLATION Level RR / CS
Zuordnung zu STOGROUPS
DEGREE ANY(?)
4. Festlegen der Datentypen in den Tabellen
a)
b)
c)
d)
e)
wenige NULL-Felder eher NOT NULL WITH DEFAULT
keine Tabellen-PROC ( VALIDPROC, EDITPROC, FIELDPROC...)
keine LONGVARCHAR / VARCHAR - Felder
VARCHAR und NULL-Felder ans Ende der Tabelle
Definition der RI-Bedingungen (falls nötig)
5. Festlegen der „views"
6. Definition der DB2-Datenbanken
a)
b)
c)
nach organisatorisch / administrativen Gesichtspunkten
nach Datenverfügbarkeitsanforderungen
(mit Hilfe der Datenbankadministration !)
Test mit Hilfe „manuell" eingetragener RUNSTATS-Werte
7. Definition von „remote“-Zugriffswegen
Testdatenbanken sind selten gleich der
PROD-Datenbank !!
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 30 von 77
DB2 –Physisches Design
3.6
Empfehlungen zum physischen Design bei DB2 DBs
Festlegen der DB2 Datentypen
Die Festlegung des Datentyps führt zu 2 wichtigen Bestimmungen bei DB2-Tables:
1.
Inhalt (Wertebereich) der Spalte, z.B. kann INTEGER nur ganzzahlige
Werte aufnehmen von -2.147.483.648 bis + 2.147.483.647
2.
Länge des Datenfeldes, z.B. INTEGER ist 4 Byte lang.
Datentyp
Bedeutung
CHAR(n) /
CHARACTER (n)
alphanumerisches Feld fester
Länge
VARCHAR (n)
alphanumerisches Feld variabler Länge
CHAR VARIYNG(n)
max. Wert
Länge
0 < n < 255
n
4046 B für 4-KB pages
8128 B für 8-KB pages
16320 B für 16-KB pages
32704 B für 32-KB pages
n
LONG VARCHAR
"string" variabler Länge
FOR BIT DATA
repräsentiert nicht ausschließlich CHAR und wird nicht auf
druckbare Zeichen konvertiert
siehe CHAR (FOR BIT DATA) –
Spalte enthält BIT Daten (nicht für
CLOBs)
FOR SBCS DATA
"single-byte-characters": Inhalte werden nach CCSID
konvertiert  CCSID: "coded
chracter set identifier"
siehe CHAR – Spalte enthält “single Byte data”
FOR MIXED DATA
repräsentiert SBCS oder
DBCS-Zeichen: "double-bytecharacter"
siehe CHAR – Spalte enthält
„MIXED data“
DEC(n,m) /
DECIMAL(n,m)
NUMERIC(n,m)
numerisch gepackt
Achtung: Leerstelle nach
Komma
n = 1 bis 10**32 - 1
m(optional) = 0 bis „precision of
scale“
<= 8
DECFLOAT(integer)
IEEE 754r (FLOAT-) Zahl mit
Dezimalpunkt
10-383 bis 10+384 oder 10-6143 bis
10+6144
max. Präz.
34 Zahlen.
32.767 Byte
<= 32KB
(integer kann entweder 16 oder
32 sein)
INT / INTEGER
binäres Vollwort
-2.147.483.648 bis
+2.147.483.647
4
SMALLINT
binäres Halbwort
-32.768 bis +32.767
2
BIGINT
Binäres Doppelwort von 63
Bits.
-9223372036854775808 ,
+9223372036854775807.
8
REAL / FLOAT (n)
Gleitkommakonstante mit einf.
Genauigkeit
FP in 32 bits
-7.2×1075 bis 7.2×1075 (n = 1 bis
21)
4
FLOAT / FLOAT (n)
DOUBLE PRECI SION
Gleitkommakonstante mit doppelter Genauigkeit
FP in 64 bits
-7.2×1079 bis 7.2×1079 (n = 22 bis
53)
8
TIME (**)
interne Zeitdarstellung
( ttmmss )
Zeitwert: 00.00.00 bis 24.00.00
3
DATE (**)
interne Datumsdarstellung
( yyyymmdd )
Datum: 0001-01-01 bis
9999-12-31
4
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 31 von 77
DB2 –Physisches Design
Empfehlungen zum physischen Design bei DB2 DBs
Datentyp
TIMESTAMP (**)
Bedeutung
max. Wert
Länge
Datum + Zeit + Systemzeit
2010-02-10-08.15.00.000000
10
TIMESTAMP WITHOUT TIME
ZONE
'2010-02-10-08.15.00-00000000
7-13
'2010-02-10-08.15.00-5:00
9-15 (2B TZ)
TIMESTAMP WITH TIME
ZONE
Der Wert für integer ist 1 bis 12.
Default = 6
Kann nicht modifiziert werden…
17(intern)
1 to 2 147 483 647
“default length” ist 1M
(möglich 1K bis 2097152K max.
Länge = 1024 * <integer> oder
1M bis 2048M max. Länge = 1 048
576 <integer>
oder 1G bis 2G max.Länge =
1073741824 * <integer>)
2 GB - 1
variabel Large binary Objekt(for BIT DATA)
<integer> = 1 bis 2 147 483 647
wenn nicht angegeben ist der
“default” 1M
2 GB - 1
DBCLOB(integer
[K|M|G])
variabel double-Byte CHAR
“large” Objekt (DBCS)
Integer = 1 bis 1073741823. Eine DBCLOB hat eine “varyinglength”.
1 GB – 1
BINARY
“fixed length” Binär-String
Integer = 1 bis 255
1 bis 255
VARBINARY
“variable length” Binär-String
Integer = 1 bis 32704
1 bis 32704
GRAPHIC(integer)
“fixed-length graphic string”
der Länge <integer>
<integer> = 1 bis 127
VARGRAPHIC(integer)
„variable-length graphic string”
der Länge <integer>
1 bis n/2, wobei n die maximale
“row-size” minus 2 Bytes ist
XML
Ein XML Wert mit der Repräsentation eines “well-formed”
XML als XML Dokument, XML
Inhalt, der eine Folge von
„XML nodes“.
DISTINCT Type (*)
Ist ein "user defined datatype"
ROWID
eindeutiger Identfier einer TabZeile(ausschliesslich BIT)
CLOB(integer)
variabel Large CHAR Objekt
(SBCS oder „mixed“)
BLOB (integer [K|M|G])
CREATE TYPE MONEY AS
DECIMAL(9,2);
CREATE FUNCTION
"+"(MONEY,MONEY)
RETURNS MONEY SOURCE
SYSIBM."+"(DECIMAL(9,2),D
ECIMAL(9,2));
CREATE TABLE SALARY_TABLE
(SALARY MONEY,
COMMISSION MONEY);
SELECT SALARY +
COMMISSION FROM
SALARY_TABLE;
Bild-14: Länge und Typen von Datenfeldern
(*) Ein distinct type ist ein "user-defined data type", der seine interne Repräsentation mit einem "built-in data type" (seinem source type) teilt. Dennoch stellt er einen, eigenständigen und inkompatiblen Datentyp für andere Operationen dar. Zum
Beispiel nutzen die Semantiken für Bild, Audio und Text intern alle denselben "built© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 32 von 77
DB2 –Physisches Design
Empfehlungen zum physischen Design bei DB2 DBs
in data type" BLOB, sind aber trotzdem unterschiedlich. Ein "distinct type" wird mit
dem Statement CREATE DISTINCT TYPE erzeugt:
CREATE DISTINCT TYPE AUDIO AS BLOB (1M);
Obwohl AUDIO dieselbe Repräsentation wie der "built-in data type" BLOB besitzt,
ist er ein eigenständiger Datentyp und nicht vergleichbar mit BLOB oder einem beliebigen anderen Datentyp. Dies wiederum ermöglicht es Funktionen speziell für
diesen neuen Datentyp AUDIO bereitzustellen. Alle diese Funktionen sind nicht auf
andere Datentypen anwendbar. Auch DISTINCT Datentypen können mit
„defaults“(**) versehen werden.
(**) Da die „defaults“ bei bestimmten Datentypen eher ungünstig ausgelegt sind,
z.B. bei den Datumsdatentypen immer CURRENT..., ist es empfehlenswert,
DEFAULTs beim CREATE TABLE entweder nicht zuzulassen, oder über die
DEFAULT Klausel selbst festzulegen.
Beispiel:
CREATE TABLE mitarbeiter
( p#
INTEGER
e_dat
DATE
)
IN <database>.<tablespace> ;
NOT NULL UNIQUE,
DEFAULT '01.01.0001'
In diesem Fall kann man den „Default“-Wert durch seine speziellen Inhalte erkennen
und in Programmen oder DML-Statements behandeln.
3.7
VARCHAR Alternativen zugunsten der Performance
Das Problem bei VARCHAR Datentypen besteht zunächst einmal darin, dass immer
mindestens ein Längenfeld gelesen werden muss, um die exakte Länge der Spalte
zu erfahren und so den Beginn einer nächsten „column“ zu evaluieren. Das kostet 2
Byte pro VARCHAR-Feld und zusätzliche CPU-Zeit.
Nun wird in vielen Applikationen, die von einer Server- auf die z/OS Plattform portiert werden, fast ausschließlich mit VARCHAR-Formaten gearbeitet, selbst bei
Feldlängen von 1. Dazu gibt es einiges zu bedenken:

VARCHAR’s sollten nur bei stark variierenden Wertevorkommen und „column“-Längen in einer Spalte gesetzt werden ( ab 80-100 Bytes Feldlänge ).

VARCHARs werden bei SORT-Vorgängen IMMER auf ihre maximale Länge
expandiert ( Anzahl „work files“, „merge“ Durchgänge, längere SORTZeiten…)

VARCHARs sparen Platz für die Tabellen aber nicht für Indexe – sie expandieren immer zur vollen Länge (außer ab DB2 V8 ist der optionale
PADDED Parameter gesetzt)

VARCHARs sind nicht die besten Platzsparer – COMPRESS ist weitaus
wirksamer
VARCHAR-Alternativen zugunsten der Performance lauten:

variable Daten in eine eigene Tabelle stellen und über primary/foreign key
Indexe verknüpfen

Nutzen von „multiple rows“ mit fixer Länge und einer „sequence“ Nummer
in einer „child“-Tabelle anstatt VARCHARs, um Textdaten beliebiger Länge
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 33 von 77
DB2 –Physisches Design
Empfehlungen zum physischen Design bei DB2 DBs
darzustellen

Einsatz von LOBs (falls die Referenz auf die LOB-Werte nicht zu hochfrequent ist) – Man muss allerdings den entstehenden Aufwand testen und der
sollte bei sogenannten“inline LOBs“ günstiger sein als bei „external“ LOBs.

Nutzen von fixen Spalten anstatt VARCHARs und Auslagern der „overflow“Daten in eine eigene Tabelle – Das funktioniert immer dann, wenn Daten annähernd dieselbe Länge besitzen
Achtung: Bei UPDATEs auf leere VARCHAR-Felder kann es zu Verlagerungen
der „rows“ kommen, die letztendlich wegen der synchron durchzuführenden I/Os
Daten-Scans verursachen, was die Performance sehr negativ beeinflussen kann.
Häufig modifizierte VARCHAR-Felder haben außerdem die Eigenschaft, häufiger
nach REORG-Aktivitäten zu verlangen, was wiederum, trotz „online“ REORG Fähigkeiten, die allgemeine Verfügbarkeit negativ beeinflussen kann.
Bei Indexen gibt es seit DB2 V8 die Option NOT PADDED. Damit werden
VARCHAR-Felder im Index nicht mehr auf ihre volle Länge expandiert. Man kann
damit den Index für INDEX ONLY Zugriffe einsetzen.
Will man die Option für „padding“ ändern – ALTER INDEX …. NOT PADDED - so
wird der IX in den Status „rebuild pending“ (RBDP) versetzt, bis er neu erstellt
(REBUILD) oder reorganisiert wird.
Aber auch hier gilt:

NOT PADDED IX sind komplex in ihrer Verarbeitung (Längenermittlung)

NOT PADDED IX verbrauchen mehr CPU

Spaltenvergleiche sind bei NOT PADDED erheblich teurer
3.8
Weitere Limits in DB2 seit Version 8 bis V11
Seit der DB2 V11 gelten weitere Limits, die hier berücksichtigt werden müssen. Ihre
Listen und Eigenschaften sind im Anhang unter Pkt. 6.2 ff aufgeführt. Hier nur ein
kurzer Auszug:
Objekte
Länge des Tabellennamens(*) beim
CREATE
Länge des „column“ Namens
Maximale Gesamtlänge des HostIndikators auf den in der SQLDA gezeigt
werden kann
DB2 V11
128
30
32767 Bytes
2147483 Bytes(2GB – 1
Byte) bei einem LOB.
Beeinflusst durch Limits
des „applicationsenvironment“ und die Programmsprache
maximale Grösse der AP SQLDA für ein
Statement, das HV oder Parametermarkers referenzieren kann
Maximale Anzahl von Partitions in einem
PTS oder einem PI
© S.K.Consulting Services GmbH
Next DB2
99016 Bytes
64 bei TS, die nicht mit
LARGE oder einer
DSSIZE > 2 GB definiert
++49 (0)162 4468790
www.sk-consulting.de
Seite 34 von 77
DB2 –Physisches Design
Empfehlungen zum physischen Design bei DB2 DBs
Objekte
DB2 V11
sind. 4096, abhängig davon, was in DSSIZE oder
LARGE und der Pagegrösse angegeben ist.
Maximale der Summe der Längen aller
Limit Key Werte für eine Partitiongrenze
Maximale Grösse von „non“-LOB Tabellen oder TSs
Maximale Grösse Logspace 6Byte Format
10Byte Format
Maximale Anzahl von Spalten in einer
Tabelle/View(der Wert hängt von der
Komplexität des CFREATE VIEW ab) oder der Anzahl von Spalten, die von einer
„table function“ zurückgegeben werden
können
Maximale Anzahl von Basistabellen in einem VIEW, SELECT, UPDATE, INSERT,
MERGE, DELETE
Maximale Anzahl von „rows“, die mit einem einzelnen INSERT oder MERGE
eingefügt werden können
Maximale Anzahl von VOLUME IDs in einer „storage group“
Next DB2
765 UTF-8 Bytes
128 TB
48
2 Byte
42
2 Byte
750 , oder weniger(inklusive der „hidden
columns“)
749 , wenn die Tabelle
eine abhängige Tabelle
ist
225
32767
133
Bild-15: Neue Längen und Limits in DB2 V10/V11
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 35 von 77
DB2 –Physisches Design
4
DB2 Objekte - Strukturierungsempfehlungen
Empfehlungen zum physischen Design von DB2 Datenbanken
Die Empfehlungen zum physischen Design von DB2-Datenbanken gliedern sich in
einen

Allgemeinen Teil und einen

Anwendungsorientierten Teil
4.1
Allgemeines zum Design von DB2-Datenbanken
(1)
"Keep Like Things Together"
Fassen Sie alle Tabellen, die zur selben Applikation gehören möglichst in einer Datenbank zusammen und geben Sie jedem Anwendungsprozess, der eigene Tabellen benötigt eine eigene "private" Datenbank. In einem idealen Umfeld nutzt jeder
Anwendungsprozess so wenige Datenbanken wie nur irgendwie möglich.
Gleich große Tabellen können bei DB2 in einem „segmented“ TS angelegt werden, vorausgesetzt, sie sind annähernd gleich groß und können gemeinsam
„recovered“ werden. Trotzdem gilt immer noch: Jede Tabelle (ob groß oder klein)
behält ihr grundsätzliches Anrecht auf einen eigenen Tablespace.
(2)
"Keep Unlike Things Apart"
Geben Sie den Benutzern unterschiedliche Autorisierungen für ihre Arbeit in unterschiedlichen Datenbanken; z.B. eine AUTHID für die Arbeit in einer gemeinsamen
und eine AUTHID für die Arbeit mit der "privaten" Datenbank.
(3)
"Cluster Your Data"
Versuchen Sie Daten, die zusammen zugegriffen werden sollen, mindestens in einer Tabelle, besser noch in einer einzigen "Page" zu halten.
Eine Tabelle, die bei Beginn der Verarbeitung leer ist und nach und nach gefüllt
wird, ist nie in einem effizientem "Cluster"-Zustand. Alle Einfügungen passieren am
Ende der Tabelle und verursachen Konflikte speziell während der Zeit in der die Tabelle annähernd leer ist und der Index nur eine oder zwei Ebenen besitzt. Typ 2 Indizes können diesem Manko Abhilfe schaffen.
(4)
"Consider Type 2 Indexes"
Bei Typ 2 Indizes werden nur die Daten gesperrt, nicht aber die Index-Pages. Dies
verursacht weniger Engpässe, da in den IX-Pages in der Regel mehr Daten gespeichert sind, als in einer Datenpage.
Auch IX-Page-Splits werden vom Typ 2 Index effizienter gehandhabt als von einem
Typ 1 Index. – Übrigens: Der Default Index-Typ ist Typ 2.
Achten Sie auf die Einfügung von NULL-Werten, da DB2 diese IMMER als "highvalue" interpretiert. Besitzt nun ein zusammengesetzter Index einen NULL-Wert in
der ersten Spalte, so können "non-NULL" Indexwerte von diesem speziellen "high
value"-Split trotz Typ 2 Index nicht profitieren.
Beispiel:
SMITH ROBERT J
=> INSERT
Anschließend
SMITH ROBERT (null)
SMITH ROBERT Z
dann wird der letzte Satz nicht als "high key" verarbeitet (!)
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 36 von 77
DB2 –Physisches Design
(5)
DB2 Objekte - Strukturierungsempfehlungen
"Use Locksize ANY"
LOCKSIZE ANY ist "default" beim CREATE TABLESPACE.
Dies ermöglicht DB2 die Sperrebene selbst zu wählen. Dabei benutzt DB2 in der
Regel "page" als Sperr-Level und/oder LOCKMAX aus den Systemparametern.
Bevor man LOCKSIZE auf ROW, PAGE, TABLE oder TABLESPACE setzt, sollte
man die Anforderungen der Anwendungen bezüglich der parallelen Verarbeitungsalgorithmen prüfen.
Andererseits sollte man auch die Angabe von LOCKSIZE ROW dahingehend überprüfen, ob dadurch nicht ein übermäßiger Aufwand für Locking entsteht.
(6)
"Examine Small Tables"
Für kleine Tabellen mit hoher Parallelverarbeitungsqualität überprüfe man die Anzahl Pages auf dem Tablespace und im Index. Ist der Indexeintrag kurz oder gibt es
viele doppelte Werte, kann man davon ausgehen, dass nur EINE "root-page" und
wenige "leaf-pages" existieren. In diesem Fall sollte man die Daten streuen, um
möglichst hohe Parallel-Verarbeitungsquoten zu erreichen. - Oder man entscheidet
sich für Typ 2 Indizes und "row locks".
(7)
"Partition your Data"
Online Queries machen erfahrungsgemäß wenige Änderungen, sind kurz, laufen
aber häufig ab.
Batch-Programme sind das genaue Gegenteil davon: Sie dauern länger, ändern viele "rows", laufen aber seltener.
Die beiden Verarbeitungsarten sind nicht besonders gut für parallele Verarbeitungsprozesse geeignet.
Es ist also häufig wichtig, Online und Batch voneinander zu trennen, falls dies möglich ist. Unterstützend dazu sollte auf der Datenbankseite über eine entsprechende
Partitionierung der Daten nachgedacht werden.
(8)
"Fewer Rows of Data per Page"
Über den Parameter MAXROWS kann man die maximale Anzahl von Datensätzen
pro Page festlegen.
Nutzt man z. B. MAXROWS 1, so besetzt jede "row" genau eine Page. Dies kann
eine Lösung sein, wenn "row locking" vermieden werden soll, wie das in "data sharing environments" oft gewünscht wird, da dort ein "row locking" übergroßen "overhead" erzeugen würde.
MAXROWS wirkt nicht auf Indizes.
(9)
"Access Data in Consistent Order"
Greifen unterschiedliche Applikationen auf dieselben Daten zu, sollte man versuchen die Programme dazu zu bringen dieselben Daten in derselben Sequenz zu lesen und zu verarbeiten; z. B. 1, 2, 3, 5.
In diesem Fall kann es sein, dass eine Applikation Zeit verliert, aber es wird nie zu
"deadlocks" kommen. Aus diesem Grund sollte man - wo möglich - auch Tabellen in
derselben Reihenfolge verarbeiten lassen.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 37 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
(10) "Commit As Soon As Practical"
Um unnötige Lock-Blockaden zu vermeiden, sollte nach Erreichen des "point-ofconsistency" so früh wie möglich ein COMMIT abgesetzt werden, auch in "readonly" - Programmen.
Um fehlerhafte SQL-Statements - wie z.B. PREPARE, daran zu hindern, Locks weiter zu halten, sollte man im Fehlerfall unbedingt einen ROLLBACK (ab-)setzen.
(11)
”Retry Application After Deadlock/Timeout"
Man sollte bei „deadlock“/“timeout“-Fehlern eine Logik in die Programme einbauen,
die die aktuelle (gescheiterte) Funktion/Transaktion nach einem "deadlock" oder einem "timeout" erneut versucht.
Dies macht Eingriffe seitens des Betriebspersonals bzw. des „Operatings“ überflüssig und erhöht den Komfort der Applikation für den User.
3-5 Versuche sind ein üblicher Wert.
(12) "Close Cursors"
CLOSE CURSOR sollte genutzt werden, um belegte Ressourcen freizugeben - insbesondere nach der Nutzung eines Cursors mit der Klausel WITH HOLD und der
Verwendung von „scrollable cursors“ (seit DB2 V7).
Aber nicht nur dann, denn wenn ein Cursor n ach Fehler nicht geschlossen wird,
bleiben SKCT-Teile unnötigerweise im EDM-Pool erhalten.
(13) "Bind Plans/Packages With ACQUIRE(USE)"
Hier sollen nur die gängigsten Kombinationen dieser BIND-Parameter diskutiert
werden:
ACQUIRE(USE) / RELEASE(DEALLOCATE): Diese Kombination führt in den
meisten Fällen zur effizientesten Nutzung von Prozessorzeiten:

Table, Partition oder Tablespace, die in einem Plan/Package verwendet werden, werden nur gesperrt, wenn dies notwendig ist.

Alle Tables / Tablespaces werden freigegeben, wenn der Plan beendet wird.

Der am höchsten restriktive Lock, der für die Ausführung des SQL Statements erforderlich ist, wird angewendet, mit der Ausnahme, dass, falls ein noch einschränkender Lock
von einem vorangegangenen Statement existiert, dieser ohne Änderungen übernommen wird.
Nachteil: Diese Kombination kann die Häufigkeit von "deadlocks" erhöhen. Da alle
Locks nur für den aktuellen Ablauf in ihrer Sequenz vorhersehbar angefordert werden, können mehr und längere Verzögerungen bei konkurrierender Verarbeitung
entstehen.
ACQUIRE(USE) / RELEASE(COMMIT): Diese Kombination stellt zugleich die
"default"-Kombination dieser Parameter dar und ermöglicht größtmögliche Parallelität in der Verarbeitung.
ABER: Es wird mehr Verarbeitungszeit verbraucht, wenn die Applikation häufig
COMMITs absetzt.

Table oder Tablespace werden nur gesperrt, wenn dies notwendig ist. Dies ist wichtig,
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 38 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
wenn ein Prozess viele SQL-Statements enthält, die selten genutzt werden oder solche,
die dazu tendieren unter Umständen "access data only" durchzuführen.

Alle Tables und TS werden freigegeben wenn:
___ TSO, Batch, and CAF ____________________________________________
|
|
| Ein SQL COMMIT oder ROLLBACK Statement abgesetzt wurde oder die
|
| Applikation beendet hat
|
|___________________________________________________________________|
___ IMS ____________________________________________________________
|
|
| Ein CHKP oder SYNC Call (für "single-mode transactions"), ein GU
|
| Call auf den I/O PCB oder ein ROLL / ROLB Call gesetzt wurde
|
|____________________________________________________________________|
___ CICS ___________________________________________________________
|
|
| Ein SYNCPOINT Kommando gesetzt wurde
|
|
|
|____________________________________________________________________|
Bild-16: Lock-Freigaben im DB2
Ausnahme: Wurde der Cursor mit der Klausel WITH HOLD definiert, so werden alle
Locks auf Table/Tablespace gehalten, die notwendig sind, die Cursorposition zu sichern – auch nach dem COMMIT.
Der am höchsten restriktive Lock, der für die Ausführung des SQL Statements erforderlich ist, wird angewendet, mit der Ausnahme, dass, falls ein noch einschränkender Lock von einem vorangegangenen Statement existiert, dieser ohne Änderungen übernommen wird.
Nachteile: Diese Kombination kann die Häufigkeit von "deadlocks" erhöhen. Da alle
Locks nur für den aktuellen Ablauf in ihrer Sequenz vorhersehbar angefordert werden, können mehr und längere Verzögerungen bei konkurrierender Verarbeitung
entstehen.
(14) "Bind With ISOLATION(CS) und CURRENTDATA(NO)"
Die verschiedenen "isolation levels" bieten mehr oder weniger Möglichkeiten der
Parallelverarbeitung zu Lasten von mehr oder weniger Schutz für die Anwendungsprozesse gegeneinander. Die Werte sollten gemäß den Anforderungen der jeweiligen Applikation gewählt werden.
Die CURRENTDATA Option hat mehrere unterschiedliche Auswirkungen, abhängig
davon, ob ein Zugriff „local“ oder "remote" erfolgt:

Für "local access", bedeutet die Option, ob die Daten, auf die ein Cursor positioniert ist,
identisch ( oder "current with" ) mit den Daten in der lokalen Basistabelle bleiben muss.
Für Cursor, die auf Daten einer "work file" positioniert sind hat die CURRENTDATA
Klausel keine Auswirkung. Sie wirkt nur auf "read-only" oder "ambiguous" Cursors in
Plänen oder Packages, die mit dem "isolation level" CS gebunden sind.
Anmerkung: Ein Cursor heißt "ambiguous" wenn DB2 nicht feststellen kann, ob er
"for update" oder nur für "read-only" Verarbeitung genutzt werden soll.

Bei einem Request an ein "remote system" hat CURRENTDATA Auswirkungen auf
"ambiguous cursors" mit den "isolation levels" RR, RS oder CS. In diesem Fall wird
"block fetching" ein- bzw. ausgeschaltet ("Read-only cursors" und UR Isolation bedeuten grundsätzlich "block fetch"). "Block fetch" bietet natürlich die beste Performance
bei „remote“-Zugriffen, aber es bedeutet auch, dass der Cursor nicht mit der Aktualität
der Basistabelle auf dem "remote" Knoten übereinstimmen muss.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 39 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
(15) Vermeide Probleme mit sogen. "ambiguous cursors"
"ambiguous cursors" können manchmal DB2 davon abhalten, sogenannte "lock
avoidance“ Techniken anzuwenden.
Deshalb gilt es immer als eine gute Programmiergepflogenheit, die Möglichkeit der
Mehrfachverwendbarkeit eines Cursors für DB2 auszuschließen, indem man
ihn entweder mit FOR FETCH ONLY oder aber mit FOR UPDATE definiert.
Soweit die grundlegenden Empfehlungen zum Umgang mit DB2-Objekten und DB2Programmen.
4.2
Spezielle Empfehlungen zum physischen Design von DB2 Datenbanken
Viel Entwickler- und DBA-Zeit kann in das physische Design der Datenbank und in
Datenbank-Abfragen gesteckt werden, alles auf Annahmen basierend.
Vieles dieser Zeit ist vergeudet, da diese Annahmen nicht genau genug sein können. Killerphrasen wie “Das geht nicht…”, “Ich glaube die DB wird den folgenden
Zugriffspfad wählen…“, „Alles soll so schnell, wie nur irgend möglich sein…“ prägen
diese Entwicklungsphasen.
Wenn dann die Applikationen implementiert sind und, wer hätte das gedacht, auch
noch schlechte Performance aufweisen, werden genau diese Leute überrascht sein:
„Wir haben doch an alles gedacht, oder ????“
Ein anderer Ansatz wäre es, so wenig wie möglich Zeit während der Entwicklung in
die Vorwegnahme möglicher Performance-Scenarios zu stecken und stattdessen,
Zeit für Performance Tests und Tuning im Projekt zu reservieren. Dies befreit die
Entwickler davon, ständig über Performance-Aspekte nachzudenken und gibt ihnen
den Vorteil, mehr Logik in ihren Queries zu verankern. Dies heißt kürzere Entwicklungszeit und mehr Möglichkeiten des (DB-)Tunings, was, wenn alle Logik im Programm stecken würde, normalerweise sehr schwer ist.
Es sollte ein Einfaches sein, Testtabellen zu erstellen und wichtige PerformanceSituationen mit einfachen Testprogrammen zu simulieren, um Fakten zu schaffen
und nicht auf Vermutungen bauen zu müssen. Also:
Testen Sie Ihre Ideen!
• Sie haben VLDB(Very Large Database) Design Vorgaben
-
Versteckte Updates auf die Datenbank
“High Speed Update” Anforderungen
Ausgewogenheit von Batch/Online bei der Zugriffshäufigkeit
Die Table ist physisch zu groß für eine einzelne DB2 Table
„Online Access” auf dem “Primary Index” ist zu langsam
Zusätzliche NPI sind erforderlich
• DB2 sollte uns sagen, WAS zu tun ist
-
Aufbau von Test Tables
Fertigen Sie Daten und Statements an
Führen Sie eine Datenanalyse durch
Lassen Sie die Queries laufen (und “tracen” sie sie)
Messen Sie die Alternativen
Erstellen Sie Dokumentationen und Reports über Ihre Tuningmassnahmen
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 40 von 77
DB2 –Physisches Design
5
DB2 Objekte - Strukturierungsempfehlungen
DB2-Objekte – Strukturierungsempfehlungen
Der Begriff “Objekte” umfaßt bei DB2 alles, was mit der Sprache
SQL definiert und manipuliert
werden kann (Im Rahmen der DDL und der DML).
Bei DB2 fallen folgende Begriffe unter die Bedeutung DB2-Objekte:
 Datenbanken (database)
 Tabellen (table) / View / Alias
 Benutzersichten (view)
 Synonyme (synonym) – in Kürze « deprecated »
 Indizes (index)
 Tabellenspeicher (tablespace / partition )
 Speicherplatz-Gruppen (storage group / file / extent)
 Constraints / Triggers / „stored procedures“ / “user defined
functions”
 User
 Plans
 Packages ....
 Schemas usw.
Die Objekte, die für das physische Design von vorrangiger Bedeutung sind werden
in den folgenden Abschnitten detailliert besprochen.
5.1
Die Hierarchie der physischen DB2-Objekte
Um Wirkung und Arbeitsweise von DB2-Optionen und Objekten beurteilen zu können, ist es unbedingt notwendig, die Zusammenhänge von logischen und physischen DB2-Objekten zu kennen. Die metamodellhafte (interne) Schematisierung der
DB2-relevanten Objekte sollte für Designer, DBA’s und auch Anwendungsprogrammierer zum Basiswissen über DB2 gehören.
Der hierarchische Zusammenhang der DB-Objekte zur Speicherung von Daten lässt
sich in der Übersicht wie folgt darstellen:
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 41 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
Database
Non-partitioned TS
Storage Group G1
Table t2
Table t1
Volume 1
Index Space
Index Space
Index X1
Index X2
Volume 3
Volume 2
Partitioned
Táblespace
Indexspace
Table
Part1
Partitioning
IX Part1
Part2
Part2
Part3
Part3
Part4
Part4
Storage Group G2
Volume 3
Volume 1
Volume 2
Bild-17: Physische DB2-Objekte in ihrem hierarchischen Zusammenhang
5.2
Datenbanken (Databases)
Die DB2-Datenbank dient als Objekt

der Regelung von Zugriffen

zum Starten und Stoppen von Info-Speichern (Datenverfügbarkeit)

zur organisatorische Abgrenzung von Datenobjekten
Auf Datenbankebene können DB-weit geltende Standards vereinbart werden, z.B.

Nutzung von "Storage Group"

Nutzung von "Bufferpool" usw.
Sie gelten für alle "Tablespaces" der jeweiligen "database", solange bei der Definition der untergeordneten Objekte keine anderweitige Festlegung getroffen wurde.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 42 von 77
DB2 –Physisches Design
5.2.1
DB2 Objekte - Strukturierungsempfehlungen
Die wichtigsten Definitionsparameter
DB2 Databases sind ein „set of DB2 structures”, das eine Sammlung von Tabellen,
ihre zugeordneten IX und die Tablespaces auf denen sie liegen, enthält. Man definiert eine Datenbank in DB2 mit dem CREATE DATABASE Statement.
Empfehlung: Man sollte eine möglichst kleine Anzahl von TS in einer DB verwalten
und damit eine kleinen Menge von Tabellen. Exzessive TS-Zahlen und Mengen
von Tabellen können Performance Einbussen zur Folge haben und sind zudem
nicht einfach zu verwalten. Vermindert man Anzahl TS und Tabellen in einer DB,
wird man bessere Performance erhalten, die Wartung minimieren, die Parallelitäten
der Verarbeitung erhöhen und die Belastung der LOG-Platten heruntersetzen.
database-name
benennt die “database”. Der Name darf nicht mit DSNDB beginnen und darf
keine Datenbank bezeichnen, die auf dem „current server“ bereits existiert.
database-name sollte aus nicht mehr als 8 Zeichen bestehen, besonders,
wenn sie in der z/OS JCL verwendet werden soll.
Soll die Datenbank eine „work file database” in einem “data sharing environment” sein, so ist DSNDB07 ein akzeptabler Name für diese „work file database“. Aber es kann immer nur EIN „member” der “data sharing group” den
Namen DSNDB07 als Namen seiner „work file database” verwenden.
BUFFERPOOL bpname
spezifiziert den “default buffer pool” Namen für die TS in der DB. Ist die DB eine „work file database”, so ist die Spezifikation von 8KB und 16KB Bufferpools
nicht zulässig. Wird der Parameter BUFFERPOOL nicht angegeben, so wird
der BP für User-Daten aus dem Installationspanel DSNTIP1 angenommen.
Der „default” Wert ist dort BP0.
INDEXBP bpname
definiert den “default bufferpool” Namen für Indizes in der DB. Dieser BP kann
4KB, 8KB, 16KB, oder 32KB Bufferpools referenzieren. Wird der Parameter
BUFFERPOOL nicht angegeben, so wird der BP für User-Indexe aus dem Installationspanel DSNTIP1 angenommen. Der „default” Wert ist dort BP0.
AS WORKFILE
gibt an, dass die Datenbank eine “work file database” sein soll.
Die “work file database” wird für “work files”, “created global temporary tables”,
“declared temporary tables” und “sensitive static scrollable cursors” genutzt.
Die Authorisierung PUBLIC erhält implizit das CREATETAB Privilege (ohne
die Authorisierung zum GRANT), um “declared temporary table” in der Work file database anlegen zu können. Dieses implizite Privilege wird im DB2 Katalog nicht aufgezeichnet und kann nicht widerrufen („revokes“) werden.
Die CCSID Klausel ist in einer „work file database“ nicht unterstützt.
FOR member-name
spezifiziert das “member”, für das diese DB erzeugt wurde. FOR membername darf nur in einer “data sharing” Umgebung angegeben werden. Ist FOR
member-name undefiniert, so ist das zugehörige “member” das DB2 Subsystem auf dem der CREATE DATABASE ausgeführt wird.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 43 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
STOGROUP stogroup-name
definiert die angegebene “storage group” als “default storage group” für Platzanforderungen von TS und Indexen innerhalb dieser DB. Der „default” ist
SYSDEFLT.
CCSID encoding-scheme
definiert das “default encoding scheme” für die Daten in dieser DB. Die Angabe gilt für die TS in der DB. Alle Tabellen in einem TS müssen dasselbe “encoding scheme” nutzen.
ASCII
ASCII CCSIDs
EBCDIC
EBCDIC CCSIDs
UNICODE
UNICODE CCSIDs.
Normalerweise benötigt jedes “encoding scheme” eine CCSID. Zusätzliche
CCSIDs werden gebraucht, wenn “mixed“, „graphic“ oder UNICODE Daten
verarbeitet werden.
Diese Option stützt sich als “default” auf den Wert des Feldes DEF
ENCODING SCHEME im Installationspanel DSNTIPF.
Die CCSID Klausel ist nicht erlaubt, wenn die Klausel AS WORKFILE angegeben wurde.
5.2.2
Autorisierungen
Die erforderlichen Privilegien für einen CREATE DATABASE müssen mindestens
eine der folgenden Autorisierungen beinhalten:




5.2.3
CREATEDBA
CREATEDBC
SYSADM oder SYSCTRL
System DBADM
Beispiele zur Definition von Databases
Beispiel 1: Die Datenbank D8D91P ist anzulegen. STG8G910 sei dabei die “default
storage group” for die TS und IX in der “database”. Es soll ein 8KB Bufferpool
BP8K1 als “default bufferpool” für die TS und BP2 als „default buffer pool“ für die Indexe zugewiesen werden
CREATE
STOGROUP
BUFFERPOOL
INDEXBP
DATABASE D8D91P
STG8G910
BP8K1
BP2;
Bild-18: Beispiel eines CREATE DATABASE - 1
Beispiel 2: Die Datenbank D8TEMP sei anzulegen. Dabei sollen die “defaults” für
die “default storage group“ und die „default Bufferpools“ gelten. ASCII sei das
“default encoding scheme” für die Daten in der DB.
CREATE
CCSID
DATABASE D8TEMP
ASCII;
Bild-19: Beispiel eines CREATE DATABASE - 2
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 44 von 77
DB2 –Physisches Design
5.2.4
DB2 Objekte - Strukturierungsempfehlungen
Gründe separate „Databases“ zu erzeugen
1.
Nutzen Sie DB2-Datenbanken als Einheiten für die Verfügbarkeit von Tabellen und Indizes (START/STOP).
2.
Separate DBs können auch fachlich/organisatorisch eine Abgrenzung der
Daten darstellen.
3.
Man kann die Status der einzelnen (DB-)eigenen Charakteristiken über einzelne Kommandos darstellen und mit ihnen nur die EINE DB abfragen.
4.
Einige Operationen sperren eine ganze Database. Beispielsweise, einige
Phasen des LOAD Utility verhindern einige SQL Statements (CREATE,
ALTER und DROP) dieselbe DB konkurrierend zu nutzen. Deshalb ist die
Platzierung von nicht abhängigen Tabellen in einer einzelnen DB oft lästig.
5.
DB2-"security"-Mechanismen können auch auf "database"-Ebene vergeben
werden.
6.
Vermeiden Sie Verweilzeiten im DB2-Katalog. Geben Sie JEDEM Entwickler und JEDEM QMF User möglichst SEINE (private) "database".
7.
Es kann sinnvoll sein, nur EINE TS pro DATABASE zu erlauben, besonders,
wenn die Tabelle(n) sehr groß sind
8.
generell gilt die Regel, dass nicht mehr als 50 bis 100 TS in einer “database” angelegt werden sollten
9.
Die maximale Anzahl von „database“.-Objekten, die in einem DB2Subsystem verwaltet werden können, sind derzeit 65279.
10.
Die internen „database descriptors” (DBDs) könnten ungewöhnlich gross
werden. DBDs wachsen in dem Masse, in dem neue Objekte definiert werden,
schrumpfen aber nicht unmittelbar, wenn die Objekte „gedropped“ werden.
Der DBD „space“ für ein „dropped object“ kann nicht wiederverwendet werden
bis ein MODIFY RECOVERY Utility die überflüssigen Kopien aus der
SYSIBM.SYSCOPY löscht. DBDs belegen Speicher und sind Objekte gelegentlicher Input und Output Operationen.
11.
Außerdem ist das Limitieren der Größen von DBDs ein weiterer Grund neue
Datenbanken anzulegen.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 45 von 77
DB2 –Physisches Design
5.3
DB2 Objekte - Strukturierungsempfehlungen
Tabellenspeicher (Tablespaces)
Der Tablespace(TS) besteht letztendlich aus einer oder mehreren VSAM ESDS
– Datei(en), in der/denen alle Zeilen einer oder mehrerer Tabellen gespeichert werden können.
Der TS ist physisch einer oder mehreren „storage groups“ zuzuordnen und gehört
zu genau einer Datenbank („database“).
Seit DB2 V9 gibt es einige Neuheiten, was die TS betrifft:



“Simple table spaces” können nicht mehr erzeugt, aber noch verwaltet werden
Der “default table space” Typ ist nun der “segmented” TS
Ein neuer TS-Typ ist der „universal TS“ (UTS)
Bild-20: Die neuen TS Typen seit DB2 V9 TS
5.3.1
Die Privilegien für CREATE TS
Das “privilege set”, muss mindestens eine der folgenden Authorisiertungen umschließen:




Das CREATETS Privileg für die “database“
DBADM, DBCTRL oder DBMAINT Autorisierung für die “database”
SYSADM oder SYSCTRL Autorisierung
System DBADM
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 46 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
Ist die DB implizit erzeugt, müssen die Privilegien auf der impliziten DB oder auf
DSNDB04 liegen.
Zusätzliche Privilegien könnten notwendig sein (siehe auch Beschreibung der
BUFFERPOOL und USING STOGROUP Klauseln).
Das „Privilege set”: Ist das Statement in einem AP “embedded” ist das “privilege
set” als Privilegien, die vom OWNER eines Plans/Packages gehalten werden zu sehen. Wird die Applikation in einem “trusted context” mit der Klausel ROLE AS
OBJECT OWNER spezifiziert, ist die “role” der OWNER. Ansonsten ist eine „authorization ID der OWNER.
Wird das Statement dynamisch “prepared”, ist das “privilege set” dien Menge an
Privilegien die von der SQL “authorization ID” des Prozesses gehalten werden, außer der Prozess läuft innerhalb eines „trusted context” und die Klausel ROLE AS
OBJECT OWNER ist angegeben. In diesem Fall ist das “privilege set” die Privilegien, die von der “role“ gehalten werden, die mit der „primary authorization ID” des
Prozesses verknüpft ist.
5.3.2
Die Namensvergabe für TS
Ein TS-Name kann aus bis zu acht Buchstaben/Ziffern bestehen und muß den Namenskonventionen für z/OS Dateien genügen.
Der TS kann über den DB-Namen qualifiziert werden. Tut man das nicht, so ist die
„default“-Database DSNDB04.
Tablespaces(TS) können EXPLIZIT oder IMPLIZIT erzeugt werden.
Spezifiziert man den TS nicht explizit, so wird der TS implizit erzeugt; d.h. DB2 leitet
den Namen aus dem Namen der Tabelle ab.
Ab dem CM (V9) ist der TS Typ dabei „segmented“. Im NFM (V9) ist der TS Typ
entweder „partition-by-growth“ oder „range-partitioned“.
Im CM ist die „default“ Database die DB DSNDB04, im NFM erzeugt DB2 entweder
eine neue DB für den „tablespace“ oder verwendet eine bereits implizit erzeugte DB.
5.3.3
Explizites Erzeugen eines Tablespace
Mit dem Statement CREATE TABLESPACE wird ein TS EXPLIZIT definiert. Das
Statement ermöglicht die Angabe aller erlaubten Attribute.
Generell wird DB2 beim CREATE TABLESPACE Statement mit einer USING
STOGROUP Klausel die “data sets” für den TS zuweisen. Gibt man jedoch die
Klausel DEFINE NO an, kann man das Allokieren der “datasets” bis zum ersten
INSERT oder einem LOAD in die entsprechende Tabelle/TS verzögern (siehe
auch Pkt. Fehler! Verweisquelle konnte nicht gefunden werden. ff).
Detaillierte Information über CREATE TABLESPACE erhält man aus den Manual
“DB2 SQL Reference”.
5.3.4
Implizites Erzeugen eines Tablespace
Ebenso wie bei DB2 Storage Groups und Databases, muss man keinen TS erzeugen, bevor man eine Tabelle anlegt, außer, man will eine “declared temporary table”
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 47 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
anlegen bzw. alle eigenen „data sets“ selbst verwalten. Setzt man ein CREATE
TABLE ab, so erzeugt DB2 einen passenden TS dazu. Aber: DB2 generiert den
TS nur dann, wenn CREATE TABLE ohne Angabe eines existierenden TS abgesetzt wurde. Befindet sich in der Tabelle eine LOB Spalte und SQL-RULES ist STD,
erzeugt DB2 den LOB TS, die „auxiliary table“ und den „auxiliary index“.
Ist kein Datenbankname mitgegeben, so versucht DB2 die „default database“
DSNDB04 und die „default DB2 storage group“ SYSDEFLT zu verwenden.
In den meisten DB2-Umgebungen ist die „default“-Database für die Nutzung durch
„normale“ User über die entsprechende Rechtevergabe gesperrt. Das führt bei fehlender Angabe einer Database bei einem CREATE TABLE zum SQLCODE -551.
Wird der TS implizit erzeugt, so nutzt DB2 natürlich auch „defaults“ für die Speicherplatz-Zuweisung. Die „default“-Werte für PRIQTY und SECQTY spezifizieren
die Platzzuweisung für den TS. Ist der Wert des Subsystem Parameters TSQTY ungleich 0, so werden darüber die „default“ Werte für PRIQTY und SECQTY bestimmt.
Ist der Wert von TSQTY 0, so werden die “default” Werte für PRIQTY und SECQTY
wie beim CREATE TABLESPACE Statement im Manual „DB2 SQL Reference“ bestimmt.
Wird kein TS Name im CREATE TABLE Statement angegeben (und der TS wird
implizit erzeugt), so leitet DB2 den TS-Namen aus dem Namen der Tabelle nach
folgenden Regeln ab:

Der TS Name ist gleich dem Tabellennamen, wenn folgendes zutrifft:
o Kein anderer TS oder IX Space in der DB besitzt bereits diesen Namen
o Der Tabellenname ist nicht länger als 8 Zeichen
o Die Zeichen sind alle alphanumerisch und das erste Zeichen ist keine Zahl.

Besitzt irgendein anderer TS in der DB bereits den Namen der Tabelle, so
weist DB2 einen Namen in der Form xxxxnyyy zu. Dabei sind xxxx die ersten
4 Zeichen des Tabellennamens und nyyy ist eine einstellige Zahl und 3 Buchstaben, die die Eindeutigkeit des Namens sicherstellen sollen.
DB2 speichert den Namen in der Katalog Tabelle SYSIBM.SYSTABLESPACE zusammen mit allen anderen TS Namen. Die Vorgaben für LOB TS findet man im Manual “DB2 SQL Reference“.
Zu beachten ist bei der Definition von TS, dass es verschiedene Typen gibt; z.B.:




„simple Tablespaces“ (wird nur noch selten/nicht mehr genutzt)
„partitioned Tablespaces“ (PTS)
„segmented Tablespaces“ (STS)
„universal Tablespaces“ (UTS) mit PBG/PBR Charakteristika usw.
Sie sind entsprechend ihrer Verwendungsabsicht zu definieren, um so u.a. ein
Fundament für gute, technische DB2-Performance zu legen.
5.3.5
Die DB2 Tablespace Typen
Jeder TS-Typ verfolgt bestimmte Ziele, besitzt eigene Stärken und Schwächen und
unterstützt bestimmte Eigenheiten der physischen Speicherung von Daten. Jeder
TS-Typ weist also somit auch unterschiedliche Charakteristika auf:
(1)
Tablespaces, die „segmented“ sind
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 48 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
Ein “segmented” Tablespace (STS) ist ideal für die Abspeicherung von mehr als einer Tabelle in einem TS – vor allem, wenn es sich dabei um kleine Tabellen handelt.
Die „page-sets” sind in diesem TS-Typ zu Segmenten zusammengefasst und jedes
Segment enthält den Satztyp genau einer Tabelle.
(2)
Tablespaces, die „partitioned“ sind
Ein “partitioned” Tablespace (PTS) enthält genau eine Tabelle und DB2 teilt den
Tablespace physisch in sogenannte Teile eines TS/„Partitions“ auf.
Diese Partitions können im Endeffekt jeder seine eigenen TS-Parameter bekommen.
(3)
„EA-enabled table spaces“ und Indexspaces
Man kann “partitioned tablespaces” für erweiterte Adressierbarkeit (extended addressability (EA)), eine Funktion des DFSMS™, vorbereiten. Die Bezeichnung für
solche Tablespaces bzw. Indexspaces ist “EA-enabled”.
(4)
„Simple Tablespaces“
Ein “simple Tablespace” ist weder “partitioned” noch “segmented”. Das Erzeugen
von “simple Tablespaces” wird seit DB2 Version 9 nicht mehr unterstützt, ihre Existenz und Verwaltung wird aber noch geduldet.
(5)
„Universal Tablespaces“
Man hat in DB2 V9 nun die Vorteile der Verwaltung von “segmented” Speicher
mit denen der Organisation von “partitioned Tablespaces“ kombiniert und nutzt
dazu den sogenannten „universal“ Tablespace Typ(UTS). Ein UTS ist also nichts
anderes als eine Kombination der Eigenschaften des “partitioned” TS mit den Charakteristika eines „segmented“ TS.
(6)
„Large object“ Tablespaces
“Large object” TS (LOB TS zusammen mit den als “auxiliary” TS) sind erforderlich
zur Speicherung von LOB-Daten(BLOBs, CLOBs, DBCLOBs), wie Grafiken, Videodaten oder sehr große (meist eingescannte) Text-Strings.
„Auxiliary TS“ werden bei “inline LOBs“ (< Tabellenpage) nicht erforderlich.
Passen die Daten nicht mehr in eine Datenpage, so kann man eine oder mehrere
Spalten einer Tabelle als LOB Spalte definieren.
(7)
XML Tablespaces
Ein XML Tablespace speichert eine XML Tabelle.
5.3.6
“EA-enabled” Tablespaces und Indexspaces
5.3.6.1 Eigenschaften von “EA-enabled TS und IXS
Man kann “partitioned tablespaces” für erweiterte Adressierbarkeit (extended addressability (EA)), eine Funktion des DFSMS™ vorbereiten. Die Bezeichnung für
Tablespaces bzw. Indexspaces, die dafür vorgesehen sind, ist “EA-enabled”.
“EA-enabled Tablespaces / Indexspaces” muss man dann einsetzen, wenn man die
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 49 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
maximale Partitiongrösse (DSSIZE) so gewählt hat, dass sie im CREATE
TABLESPACE Statement 4 GB übersteigt.
Beide “EA-enabled” und “non-EA-enabled partitioned TS” können eine Tabelle mit
bis zu 4096 Partitions enthalten. Im Folgenden werden die Unterschiede klar:
EA-enabled Tablespaces
Non-EA-enabled Tablespaces
Bis zu 4096 Partitions mit je 64 GB
Bis zu 4096 Partitions mit jeweils 4 GB
Erzeugt mit einem beliebigen Wert für
DSSIZE
DSSIZE kann nicht grösser als 4 GB
sein
Datasets sind “SMS managed”
Datasets sind “VSAM-“ oder “SMSmanaged”
Erfordert einen speziellen Setup
Kein spezieller Setup erforderlich
Bild-21: Unterschiede zwischen „EA-enabled“ und „non-EA enabled“ TS
5.3.6.2 Erzeugen von “EA-enabled” TS und Indexspaces
DFSMS™ besitzt eine “extended-addressability” Funktion. Sie ist erforderlich zur
Darstellung von Datasets, die grösser als 4 GB sind. „page sets”, die für “extended
addressability” angelegt wurden, heißen “EA-enabled”. Um diese “page sets” zu erzeugen muss man:
1.
SMS nutzen, um die Datasets zu verwalten, die mit den “EA-enabled page sets“
belegt werden sollen.
2.
Die Verbindung der Datasets zu den „page sets“ sollte über eine “data class”
(ein SMS Konstrukt) erfolgen, die das erweiterte Format und die „extended addressability“ Optionen definiert.
Um die Verbindung zwischen „data sets” und der “data class” darzustellen, benutzt man die “automatic class selection” (ACS) Routine. Sie weist die DB2®
„data sets“ der relevanten SMS „data class“ zu. Die ACS Routine erledigt dies
auf der Basis der “data set” Namen. Es gibt dabei keinerlei Bedenken bezüglich
der Performance, wenn man auf einer Datenklasse „non-EA-enabled“ und „EAenabled“ „page sets“ gemeinsam unterbringt.
Bei “user-managed data sets”, kann man die ACS Routine nutzen oder aber
auch die entsprechende “data class” im DEFINE CLUSTER Kommando angeben, wenn das „data set“ angelegt wird.
3.
Man erzeugt nun den “partitioned” oder LOB TS mit einer DSSIZE von 8 GB
oder größer. Der „partitioning Index” des “partitioned table space” übernimmt
nun das Attribut “EA-enabled” vom zugehörigen TS.
Nachdem ein „page set” erzeugt wurde, kann man mit dem ALTER
TABLESPACE Statement die DSSIZE nicht mehr ändern. Man muss dazu den
TS mit DROP und CREATE behandeln.
Außerdem kann man die „datasets” des “page set” nicht mehr ändern, um z.B.
die „extended addressability“ bzw. die „extended format“ Attribute abzuschalten.
Ändert jemand die „data class”, um die „extended addressability“ bzw. die „ex-
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 50 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
tended format“ Attribute abzuschalten, so setzt DB2 eine Fehlermeldung ab,
sobald das “page set” das nächste Mal geöffnet werden soll.
5.3.7
Simple table spaces
Ein “simple Tablespace” ist weder “partitioned” noch “segmented”.
Man kann zwar keine “simple” TS mehr erzeugen, aber, falls noch welche existieren, diese ändern, die Daten modifizieren bzw. lesen.
Wird ein TS implizit oder explizit angelegt, ohne dass SEGSIZE, NUMPARTS, oder
die MAXPARTITIONS Option verwendet wird, so erzeugt DB2® einen „segmented“ TS anstatt eines „simple Tablespace“.
Per “default” hat der “segmented” TS dann eine SEGSIZE von 4 und eine
LOCKSIZE Angabe ROW.
Empfehlung: Man sollte alle noch existierenden “simple” TS so schnell, wie
möglich, in “segmented” UTS konvertieren.
5.3.8
Universal Table spaces
Mit DB2 9 wurde ein neuer TS-Typ eingeführt: „universal table space“ (UTS). Ein
UTS ist ein TS, der die Eigenschaften eines “segmented” und eines „partitioned“ TS
miteinander kombiniert. Wichtig sind zwei Typen von UTS:


“partition-by-growth” TS(PBG) und
“range-partitioned” TS(PBR).
Der letztendliche UTS Typ wird über die Spezifikation in den Klauseln SEGSIZE,
MAXPARTITIONS bzw. NUMPARTS festgelegt. Gibt man beispielsweise SEGSIZE
mit NUMPARTS an, so wird der TS als “range-partitioned” UTS angelegt. Ist
SEGSIZE mit MAXPARTITIONS angegeben, wird der TS als “partition-by-growth”
UTS angelegt.
Die weiteren Kominationsmöglichkeiten sind im folgenden Schaubild dargestellt:
SEGSIZE Klausel
MAX PARTITIONS
Klausel
NUMPARTS Klausel
TS-Typ
spezifiziert
spezifiziert
Nicht spezifiziert
Partition-by-growth TS
spezifiziert
Nicht spezifiziert
Nicht spezifiziert
Segmented TS
spezifiziert
Nicht spezifiziert
spezifiziert
Range-partitioned UTS
Nicht spezifiziert
spezifiziert
Nicht spezifiziert
PBG TS mit implizit
SEGSIZE 4
Nicht spezifiziert
Nicht spezifiziert
Nicht spezifiziert
Segmented TS mit implizit SEGSIZE 4
Nicht spezifiziert
Nicht spezifiziert
spezifiziert
Partitioned TS
Bild-22: UTS: Die Tablespace-Typen
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 51 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
Der UTS ist also eine Hybride zwischen „partitioned“ und „segmented“ Tablespace und ist inkompatibel mit MEMBER CLUSTER (ab DB2 10 ist diese Restriktion aufgehoben)
•
Besitzt ein verbessertes „space management“
•
Unterstützt Massen-Deletes / TRUNCATE
•
Lässt immer noch nur EINE Tabelle pro Tablespace zu


Kann “Range Based partitioning (PBR)” oder
“Partitioned By Growth (PBG)” unterstützen
•
DROP / CREATE ist erforderlich, um bestehende “page sets” nach UTS zu
migrieren ( in DB2 V9 noch )
•
Eine „segmented space-map page” besitzt mehr Information über “free space”
als eine “ partitioned space-map page“
•
Partitioning ermöglicht den/ “support” von “large” TS und parallele Verarbeitung von Zugriffen
•
Alle TS auch die UTS werden per „default“ im RRF Format angelegt, außer
der DSNZPARM SPRMRRF ist auf DISABLE gesetzt
•
Die Option MEMBER CLUSTER , eingeführt für “partitioned” TS in “data sharing” Umgebungen wird von UTS in der Version DB2 10 wieder unterstützt.
Die Katalogtabelle SYSIBM.SYSTABLESPACE identifiziert die TS über folgende
Werte in der Spalte TYPE column:
blank
L
R
P
O
G
Der TS wurde ohne LOB oder CLUSTER Optionen erstellt
der TS kann größer als 64 GB sein
UTS “range-partitioned”
Impliziter UTS für XML Spalten
LOB TS
UTS “partitioned-by-growth” TS
5.3.8.1 Die Nutzung von UTS in DB2 9/10 und V11
In DB2 9 wurden UTS für folgende Zwecke angelegt:

XML TS, wobei die “base table” segmentiert, partitioniert oder UTS sein kann

CLONE Tables
In DB2 10/11 werden UTS angelegt für

„Hashing access“

XML „versioning“ Funktion. Die XML „base table“ muss UTS sein.

Die Nutzung von ALTER „online schema“ Verbesserungen. Einige „schema“
Änderungen sind wichtig für UTS mit neuen „pending changes” Techniken, die
für andere Strukturen von TS nicht zur Verfügung stehen

„Inline“ LOBs.

Zugriff auf „currently committed“ Daten

Insert IX I/O Parallelverarbeitung. Dies funktioniert für UTS oder klassische
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 52 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
“partitioned table spaces“, nicht aber mit „segmented table spaces“
5.3.8.2 Konvertieren auf UTS
In DB2 9 kann man einen TS nicht auf UTS konvertieren, ohne DROP und reCREATE.
DB2 10 vereinfacht diese Änderung auf die TS-Struktur und die Attribute. Es gibt einen ALTER TS mit Konvertierungsfunktion und zwar wie folgt:

Konvertieren von “index partitioned” TS nach “table partitioned” TS.

Konvertieren von klassisch “table partitioned” TS nach “range-partitioned” TS
mit Hinzufügen der Option SEGSIZE.

Konvertieren von “simple” TS mit EINER Tabelle auf einen “partition-by-growth”
TS

Konvertieren von “segmented” TS mit EINER Tabelle auf einen “partition-bygrowth” TS

Konvertieren von “partition-by-growth” TS auf “hash table space”

Konvertieren von “range-partitioned” TS auf “hash table space”
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 53 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
5.3.8.3 ALTER TS
Dazu die Syntax des ALTER
ALTER TABLESPACE
>>__ALTER TABLESPACE____________________________table-space-name____________><
|_database-name._|
>_BUFFERPOOL__bpname______________________________________________|
|_LOCKSIZE____ANY_________________________________________________|
|
|_TABLESPACE_|
|
|
|_TABLE______|
|
|
|_PAGE_______|
|
|
|_ROW________|
|
|
|_LOB________|
|
|_LOCKMAX____SYSTEM_______________________________________________|
|
|_integer_|
|
|_CLOSE______YES__________________________________________________|
|
|_NO__|
|
|_USING______VCAT__catalog-name___________________________________|
|
|_STOGROUP__stogroup-name_|
|
|_PRIQTY_____integer______________________________________________|
|_SECQTY_____integer______________________________________________|
|_ERASE______YES__________________________________________________|
|
|_NO__|
|
|_FREEPAGE___integer______________________________________________|
|_PCTFREE__ _integer_____________________________________________ |
|_COMPRESS____YES_________________________________________________|
|
|_NO__|
|
|_DROP PENDING CHANGES____________________________________________|
|_DSSIZE_integer_G________________________________________________|
|_MEMBER CLUSTER YES______________________________________________|
||_MEMBER CLUSTER NO__|
|
|_SEGSIZE_integer_________________________________________________|
|_GBPCACHE___CHANGED______________________________________________|
|
|_ALL_____|
|
|
|_SYSTEM__|
|
|
|_NONE____|
|
|_LOCKPART____YES_________________________________________________|
|
|_NO__|
|
|_MAXROWS_____integer_____________________________________________|
|_MAXPARTITIONS_integer___________________________________________|
|_TRACKMOD____YES_________________________________________________|
|
|_NO__|
|
|___LOGGED________________________________________________________|
| |_NOT LOGGED__|
|
|_CCSID__ccsid-value______________________________________________|
>>__ALTER PARTITION__integer____________________________________________________><
|_USING____VCAT__catalog-name_____________________________________|
|
|_STOGROUP__stogroup _|
|
|_PRIQTY__integer_________________________________________________|
|_SECQTY__integer_________________________________________________|
|_ERASE_______YES_________________________________________________|
|
|_NO__|
|
|_FREEPAGE__integer_______________________________________________|
|_PCTFREE___integer_______________________________________________|
|_COMPRESS____YES_________________________________________________|
|
|_NO__|
|
|_GBPCACHE____CHANGED_____________________________________________|
|
|_ALL_____|
|
|
|_SYSTEM__|
|
|
|_NONE____|
|
|_TRACKMOD____YES_________________________________________________|
|_NO__|
Bild-23: UTS: Der ALTER TABLESPACE
Sie verwenden das Attribut MAXPARTITIONS des ALTER TABLESPACE Statements, um die maximale „partition size“ für „partition-by-growth“ TS
festzulegen.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 54 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
Bei Erreichen dieses „thresholds“ wird eine neue PGB-Partition angelegt.
Man kann dieses Attribut auch dazu verwenden, um eine „single-table“ in einem
„simple tablespace“ oder eine „single-table“ in einem „segmented tablespace“ auf
einen „partition-by-growth“ Universal TS zu konvertieren.
Zusätzlich dazu kann man das Attribut SEGSIZE im ALTER TABLESPACE dazu
nutzen, einen „partitioned tablespace“ in einen „range-partitioned universal table
space“ zu konvertieren.
Single table
Simple TS
PBG TS
PBG TS
PBG TS
PBG TS
PBG TS
Hash TS
Single table
Segmented
TS
ONE
Classic PTS
trolled
Table controlled
ONE
PBG TS
PBG TS
PBG TS
PBG TS
PBR TS
Hash TS
ALTER verfügbar ab DB2 V8
Antique PTS
trolled
Index conrolled
Bild-24: UTS: Konvertierung von Tablespaces
Diverse Konvertierungen sind nur erlaubt für “single-table table spaces”.
Auch benutzen Konvertierungen aus “hash table spaces” zurück, nicht mehr die
Technik der „pending changes“.
5.3.8.4 Neuer “default table space” zur CREATE Zeit
In DB2 V10 sind “segmented table spaces” nicht mehr der “default”, wenn ein neuer
Tablespace angelegt werden soll.
„Partition-by-growth” UTS lautet der neue “default” jetzt.
Will man einen “range partitioned” UTS (PBR) anlegen, so müssen die Werte für
NUMPARTS und SEGSIZE gesetzt werden.
Will man nur einen klassischen „partitioned table space” erzeugen, muss man
SEGSIZE 0 beim CREATE TABLESPACE verwenden.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 55 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
Man kann aber auch den neuen “default partition SEGSIZE” im DSNZPARM
DPSEGSZ=0 im Makro DSN6SYSP setzen („default“ ist 32), dann entsteht per
„default“ ein „segmented partitioned TS“.
Will man nur einen “segmented table space” spezifizieren, darf MAXPARTITIONS
und NUMPARTS keinesfalls gesetzt sein und welcher Wert auch immer in
DPSEGSZ gesetzt ist, man bekommt einen „segmented table space“ mit 4 KB
SEGSIZE(!), was nicht wirklich effizient ist.
5.3.8.5 Die MEMBER CLUSTER Option für UTS
MEMBER CLUSTER zeigt an, dass in einer INSERT Operation eingefügte Daten
nicht über den Impliziten “clustering” Index (erster Index) oder den expliziten “clustering” Index “geclustered” werden..
Stattdessen wählt DB2 den Platz im TS in den die Daten geschrieben warden sollen
anhand des verfügbaren Platzes.
MEMBER CLUSTER für “segmented table spaces” ist verboten.
MEMBER CLUSTER für einen LOB TS oder einen TS in einer “work file database“ ist verboten.
MEMBER CLUSTER kann zusammen mit dem Parameter MAXPARTITIONS angegeben werden.
5.3.8.6 UTS “workload performance”
N/A für “non SYSPLEX”
5.3.8.7
“Non-range-defined table spaces”
N/A
5.3.8.8 “Range defined table spaces”
N/A
5.3.8.9 Überlegungen zur UTS Performance
In den meisten Fällen bieten “universal table spaces” eine optimale parallele Verarbeitung beim INSERT und damit höchste Performance in “data sharing environment”, umso mehr, wenn man die Option MC beim PBG UTS einsetzen kann.
Auch wenn MEMBER CLUSTER nicht verwendet wird, liefert ein PBG TS gute Performance. PBR liefert ebenfalls sehr gute Performance, wenn PLL “Locking” zum
Einsatz kommt oder wenn die INSERT’s “random” erfolgen.
Der einzige Fall, in dem die UTS Performance signifikant einbricht, ist bei einem
PBR “sequential“ INSERT mit „row level locking“ in einer „data sharing“ Umgebung und ohne Angabe von MC. Ist ein hoher Durchsatz bei parallelem INSERT
wichtig, und man will MC nicht nutzen, jedoch andere neue Funktionen auf UTS, so
sollte man „row level locking“ dringend vermeiden.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 56 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
5.3.8.10 Inferenzen zu “hash tables”
Angenommen, man überlegt sich “hash” Zugriffe einzusetzen: Um eine „hash” Organisation zu erzeugen, muss man einen „cluster index“ vorlegen. Startet man mit
einer leeren Tabelle, und füllt diese später mit INSERTs, so befindet sich in der
“hash table” normalerweise eine Menge an freiem Platz und es gibt keinen Anlass,
lange nach „free space“ zu suchen. Diese INSERTs erfolgen “random”, da die
“hash“ Werte „pseudo random“ sind(„hash“ Algorithmus). Wird die “hash table” aber
allmählich – sagen wir 80% bis 90% voll - so fangen die INSERTS an, immer öfter
die “overflow area” in Anspruch zu nehmen und dann beginnen die „overflow“ INSERTs sich wie sequentielle INSERTs auf normalen Tabellen zu benehmen.
5.3.8.11 Inferenzen zu “inline LOBs”
Angenommen, man überlegt sich „inline“ LOBs einzusetzen, so veranlassen diese
ein Anwachsen der „row size”; d.h. es existieren weniger „rows“ pro Page. Gibt es
nur noch eine “row” pro Page, so verhalten sich RLL und PLL identisch, ausser in
„data sharing“ Umgebungen, wo RLL einen „data page“ P-Lock erforderlich macht.
In Messungen kann man sehen, wie die RLL Performance “in die Knie geht”. Das
passiert allerdings nicht, wenn die “rows” sehr groß sind.
Also, wenn man die Performance von großen “rows” evaluieren will, so sollte man
sich die Messungen der PLL ansehen, auch wenn man plant RLL einzusetzen.
5.3.8.12 UTS: “Partition by growth”
“Partition-by-growth” TS erlauben eine Partitionierung, die sich dem Datenwachstum des TS anpasst. Das heißt, dass “segmented tables” gemäß ihrem Wachstum
partitioniert werden können, ohne die Erfordernis “key ranges” für die Partitionierung
festlegen zu müssen.
PBG’s verhalten sich, wie einzelne “segmented” DB2 TS. DB2 verwaltet die PBG
TS, indem es automatisch eine Partition erzeugt, wenn mehr Platz für die Daten,
beispielsweise beim INSERT, erforderlich wird. Der TS startet mit einer einzigen
Partition und wächst von da an automatisch bis auf maximal 128 TB. Diese maximale Größe wird über die Parameter MAXPARTITIONS und DSSIZE bestimmt.
Obwohl PBG’s partitioniert sind, sind sie in den einzelnen Partitions auch „segmented“ und besitzen damit automatisch die Eigenschaften von STS.
Die partitionierte Struktur erlaubt DB2 Utilities Operationen auf „part level“ und parallele Verarbeitungstechniken.
„Partition By Growth“ TS sind immer UTS (PBG)
•
•
•
CREATE TABLESPACE MAXPARTITIONS integer
CREATE TABLE PARTITIONED BY SIZE EVERY integer G
Bei einem „Single Table Tablespace“ und bei Universal Tablespaces (UTS)
möglich (max. 128 TB)
 „default segsize“ = 4 (ab DB2 V10: 32)
 max. Größe für die einzelne Partition = 4GB und
 die max. Anzahl Partitions = 256
 dies begrenzt die „default size“ einer Tabelle auf 1 TB
Bei einem implizit erzeugten TS kann man die Anzahl Partitions über die Klausel
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 57 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
PARTITION BY SIZE im CREATE TABLE Statement steuern:
CREATE LARGE TABLESPACE suts001 IN dbuts001
MAXPARTITIONS 2
SEGSIZE
16
…
CREATE TABLE tuts001
…
PBG
Bild-25: UTS: PBG Tablespace
CREATE TABLESPACE TS1 IN DB1
MAXPARTITIONS
55
SEGSIZE
64
DSSIZE
2G
LOCKSIZE
ANY;
CREATE TABLE
PARTITION
EVERY
MYTABLE
BY SIZE
INTEGER G in DB1.TS1;
Bild-26: UTS: DDL für PBG Tablespace
5.3.8.12.1 Überlegungen zu PBG TS

“Partition-by-growth” TS müssen über “storage groups” angelegt sein

Die Option MEMBER CLUSTER ist in der CREATE TABLESPACE Syntax nicht
mehr möglich(erst ab DB2 10 wieder).

LOB und XML Spaces, die mit einem “partition-by-growth” TS verknüpft sind,
werden von DB2 IMMER implizit definiert, unabhängig davon, ob SQLRULES
DB2 oder STD angewendet wird

Ein “partition-by-growth” TS kann nur eine einzige Tabelle beinhalten.

Wird eine neue Partition hinzugefügt, so werden die Werte für “drain” und
„claim“ von der vorangehenden Partition abgeleitet

einige DBET Status werden ebenfalls von der vorangehenden Partition abgeleitet, wenn eine neue Partition hinzugefügt wird. Dies sind vor allem die DBET
Status: RO*, UTUT, UTRO, PSRBD und ICOPY.
5.3.8.12.2 PBG Restriktionen

Die Option PART beim LOAD Utility ist nicht unterstützt

REBALANCE beim REORG ist nicht unterstützt

Die TS müssen „DB2-managed“ sein (nicht „user-managed“). DB2 muss die
Möglichkeit haben, „data sets“ zu erzeugen, wenn Partitions voll werden
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 58 von 77
DB2 –Physisches Design

DB2 Objekte - Strukturierungsempfehlungen
Partitions können nicht hinzugefügt, rotiert oder geändert(ALTER) werden
und so sind die folgenden Optionen für “partition-by-growth” TS nicht zulässig:
–
–
–
ALTER TABLE ADD PARTITION
ALTER TABLE ROTATE PARTITION
ALTER TABLE ALTER PARTITION

Ein „non-partitioning“ Index (NPI) verwendet einen 5 Byte langen „record
identifier“(RID)

„partitioned IX“ werden nicht unterstützt, es sind nur NPI’s erlaubt
“Partition-by-growth” (PBG) TS sind sinnvoll für TS, in denen Tabellen keinen
wirklichen “partitioning key” besitzen, aber erwartungsgemäß über 64 GB wachsen
und so das Limit für „simple“ bzw. “segmented” TS überschreiten werden.
Die Größe eines PBG TS liegt bei einem maximalen Limit von 128TB.
Ein PBG TS startet i. d. R. mit einem “single-partition” TS und wächst dann automatisch über weitere Partitions – falls erforderlich. Wird die erste Partition gefüllt, entsteht keinerlei “resource unavailable” Bedingung – auch nicht, wenn die nächste
Partition erzeugt wird usw. Dies geschieht solange, bis das zum Erstellungszeitpunkt definierte Maximum an Partitions erreicht ist. Erst dann entsteht eine „resource unavailable” Situation.
Die Datenstruktur eines PBG TS ähnelt der eines “segmented” Tablespace.
Weitere Informationen zum PBG TS bezüglich des Utility Einsatzes im Handbuch „DB2 - Utilities allgemein (Best Practise)“.
5.3.8.13 UTS: “Partition by range”
"Range-partitioned”(“partitioned by range” oder auch PBR) UTS hat die Eigenschaften von “partitioned” und „segmented“ TS miteinander kombiniert. Sie sind ab
DB2 V8 auch als „table controlled“ PTS bekannt.
Man erzeugt diesen Typ TS, indem man die Schlüsselworte NUMPARTS oder
SEGSIZE und NUMPARTS in einem CREATE TABLESPACE Statement angibt.
PBR TS können mit im CREATE TABLESPACE erzeugt werden.
Die „ranges“ der einzelnen Partitions können in einem folgenden CREATE TABLE
Statement festgelegt werden.
Hat man einmal einen „range-partitioned” TS erzeugt, kann man die meisten Aktionen, die man auch auf “partitioned” / “segmented” TS durchführen kann, ansteuern.
Einige Vorteile von “range-partitioned” TS:

Verbessertes “space” Management in Verbindung mit Sätzen variabler Länge. Der Grund: Eine “segmented space map page” besitzt mehr Informa-tionen
über “free space“, als eine „partitioned space map page“.

Verbesserte “mass delete” Performance. Der “mass delete” auf einem “segmented” TS ist schneller als auf andere TS Typen, wie “partitioned” oder gar
„simple“ TS.

DB2 benutzt alle bzw. die meisten Segmente nach einem DROP bzw. einem
“mass delete” wieder, wenn diese Aktion “committed” ist.
Hier ein Beispiel eines SQL CREATE Statement für einen PBR. SEGSIZE und
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 59 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
NUMPARTS definieren den PBR. Nach dem CREATE des TS sollte eine “tablecontrolled partitioning” Tabelle erstellt werden:
CREATE LARGE TABLESPACE suts001 IN dbuts001
NUMPARTS
2
SEGSIZE
16
…
CREATE TABLE tuts001
…
PARTITON BY RANGE
( PNR ASC)
( PARTITION 1 ENDING ( 20 )
, PARTITION 2 ENDING ( 40 ) )
PBR
Bild-27: UTS: PBR Tablespace
CREATE TABLESPACE
NUMPARTS
SEGSIZE
LOCKSIZE
PRB_TS1 IN UTS_DB1
3
64
ANY;
CREATE TABLE
MyTable
( C1
CHAR(4),
C2
VARCHAR(20),
C3
INTEGER )
PARTITION
BY (C1)
( PARTITION
1
ENDING AT (‘DDDD’),
PARTITION
2
ENDING AT (‘HHHH’),
PARTITION
3
ENDING AT (‘ZZZZ’) )
IN UTS_DB1.PRB_TS1;
Bild-28: UTS: CREATE eines PBR Tablespace
5.3.8.13.1 Einige Überlegungen zu PBR TS

Alle “range-partitioned” UTS sind LARGE Tablespaces.

Die Spalte TYPE in SYSIBM.SYSTABLESPACE erhält ein 'R' für „rangepartitioned“ Universal Tablespaces.

Das Schlüsselwort MEMBER CLUSTER ist für “range-partitioned” Universal
Tablespaces nicht erlaubt(erst ab DB2 10 wieder)

„Range partitioned” TS folgen dem regulären “partitioned table space” Locking Schema; d.h. LOCKSIZE TABLE ist ungültig in der CREATE
TABLESPACE Syntax

Man muss die Syntax für „table-controlled partitioning” einsetzen, wenn
man einen “range-partitioned universal table space” anlegen will

“Range-partitioned universal table spaces” existieren zusätzlich zu den regulären “partitioned tablespaces”.

“Mass delete” Locks werden auf Tabellenebene, anstatt auf TS „level” gesetzt

Enthält ein „range-partitioned universal table space” eine XML Spalte, so ist
der zugehörige XML Tablespace ebenfalls ein „range-partitioned“ UTS
Achtung: “index-controlled partitioning” ist nicht mehr erlaubt. Derartige Aktionen führen zu einem SQLCODE = -662 Fehler.
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 60 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
5.3.8.14 Vorteile / Nachteile von UTS generell
Einige der wichtigsten Vorteile eines “universal Tablespaces” (UTS) sind:

Besseres “space management” für variabel lange “rows”, da eine “segmented space-map page” mehr Information über den freien Platz auf dem TS
besitzt als eine “partitioned space-map page”

Verbesserte „mass delete” Performance

“Table scans” werden auf Segment-Ebene durchgeführt

Unmittelbare Wiederverwendbarkeit aller oder fast aller Segmente einer
Tabelle nach DROP bzw. “mass delete”.
Restriktionen:

UTS können nicht in der “work file database” angelegt werden.

UTS erfordern mehr “space map pages” als ein “partitioned” TS
5.3.9
Large Object Tablespaces (LOB TS)
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 61 von 77
DB2 –Physisches Design
© S.K.Consulting Services GmbH
DB2 Objekte - Strukturierungsempfehlungen
++49 (0)162 4468790
www.sk-consulting.de
Seite 62 von 77
DB2 –Physisches Design
© S.K.Consulting Services GmbH
DB2 Objekte - Strukturierungsempfehlungen
++49 (0)162 4468790
www.sk-consulting.de
Seite 63 von 77
DB2 –Physisches Design
6
DB2 Objekte - Strukturierungsempfehlungen
Anhang
6.1
Checkliste zum physischen DB-Design DB2
I. Logisches DB-Modell und seine Umsetzung nach DB2
1.
Beachten Sie die Stärken und Schwächen des Ziel-DBMS
2.
Überführen des logischen DM
3.
Legen Sie Satztypen zusammen, wo erforderlich
4.
Trennen Sie Satztypen auf, wo nützlich
5.
Nutzen Sie die Denormalisierungsmöglichkeiten
6.
Erzeugen Sie zusätzliche Tabellen, wo dienlich
7.
Ergänzen Sie das DM um zusätzliche Felder
8.
Überführen Sie die Beziehungen
9.
Richten Sie die Zugriffspfade in DB2 ein (mindestens PK,
FK als Indexe)
10.
Bestimmen Sie die IX-Typen
11.
Ermitteln Sie Ihr Mengengerüst
12.
Untersuchen Sie die Nutzungsfrequenz der Objekte
Notizen:
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 64 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
II. Festlegen der physikalischen DB2-Struktur
1. Legen Sie die DB2 Datentypen fest
2. Bestimmen Sie TS-Größe und TS-Typ
3. Berechnen Sie die Index-Größen
4. Planen Sie mit Ihrem Betrieb die Verteilung derTS auf die Platten
Notizen:
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 65 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
III. DB2-Objekte – Strukturierungsempfehlungen
1. Definieren Sie Ihre Datenbank(en) (Databases)
2. Definieren Sie Ihre Tabellenspeicher (Table Spaces)
3. Entwerfen Sie Ihre Tabellen (Tables)
a.
Beachten Sie die Größe von Tabellen (Tables)
b.
Beachten Sie die INSERT-Algorithmen
c.
Behandeln Sie „Code Tables"
d.
Behandeln Sie „Flip-Flop Tables"
e.
Behandeln Sie „Hot spots"
f.
Berücksichtigen Sie die weiteren Tips zum Table –Design
4. Definieren Sie Ihre Indizes (Index)
a.
Prüfen Sie mögliche Indexstrukturen und Konzepte
b.
Prüfen Sie den Einsatz von „clustering" Indizes
c.
Prüfen Sie den Einsatz von „Partitioned Index"
d.
Prüfen Sie den Einsatz von „Non-Unique Index"
e.
Nutzen Sie UNIQUE WHERE NOT NULL, falls erforderlich
f.
Bestimmen Sie „Non-Partititioned" Index „Pieces"
g.
Definieren Sie Indizes zur Vermeidung von Sort-Vorgängen
h.
Setzen Sie Indizes aus mehr als einer Spalte ein
i.
Beachten Sie die Indizierung von langen alphanumerischen Spalten
j.
Beachten Sie die Indizierung von VARCHAR Spalten
k.
Beachten Sie die weiteren Tips zum Index-Design
5. Definieren Sie Ihre Views
Notizen:
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 66 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
IV. Parallele Verarbeitung
1. Prüfen Sie Ihre LOCKSIZE-Angaben
2. Beachten Sie die Anzahl „rows per page"
3. Beachten Sie die Ebenen der Kontrolle beim LOCK
4. Beachten Sie die „Lock Escalation"
5. Beachten Sie die Kosten von „row locking"
6. Prüfen Sie Index-Design und konkurrierende Verarbeitung
Notizen:
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 67 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
V. Überlegungen zu Queries
1.
Queries und Partitionierung
2.
Gibt es einen minimalen Parallelitätsgrad ?
3.
Wann sollten PTS eingerichtet werden ?
4.
SQL Formulierungen für Parallelverarbeitung
Notizen:
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 68 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
VI. DB2 Speicherplatzzuweisung und Speicherverwaltung
1.
Definieren Sie Ihre Speicherplatzgruppe(n) (Storage Group)
2.
Beachten Sie die Speicherplatzgruppen und die Verteilung der Datasets
3.
Beachten Sie weitere Tips zu STORAGE GROUPS
VII. DBMS Systemressourcen
1. Der Buffer Manager
2. DB2 Logging
3. Work Files
4. Katalog und Directory
5. Die IRLM-Umgebung und die LOCK-Anforderungen
6. Traces
VIII. z/OS-Ressourcen
Notizen:
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 69 von 77
DB2 –Physisches Design
6.2
DB2 Objekte - Strukturierungsempfehlungen
Limits bei DB2 (V11)
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 70 von 77
DB2 –Physisches Design
© S.K.Consulting Services GmbH
DB2 Objekte - Strukturierungsempfehlungen
++49 (0)162 4468790
www.sk-consulting.de
Seite 71 von 77
DB2 –Physisches Design
© S.K.Consulting Services GmbH
DB2 Objekte - Strukturierungsempfehlungen
++49 (0)162 4468790
www.sk-consulting.de
Seite 72 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
6.3
Abbildungsverzeichnis
6.4
Glossar
6.5
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 73 von 77
DB2 –Physisches Design
6.6
DB2 Objekte - Strukturierungsempfehlungen
Literaturhinweise
DB2 Universal Database Server for OS/390 und z/OS Version 7/8/9 “product libraries”:
DB2 for OS/390 and z/OS
v DB2 Administration Guide, SC26-9931
v DB2 Application Programming and SQL Guide, SC26-9933
v DB2 Application Programming Guide and Reference for Java, SC26-9932
v DB2 Command Reference, SC26-9934
v DB2 Data Sharing: Planning and Administration, SC26-9935
v DB2 Data Sharing Quick Reference Card, SX26-3846
v DB2 Diagnosis Guide and Reference, LY37-3740
v DB2 Diagnostic Quick Reference Card, LY37-3741
v DB2 Image, Audio, and Video Extenders Administration and Programming, SC26-9947
v DB2 Installation Guide, GC26-9936
v DB2 Licensed Program Specifications, GC26-9938
v DB2 Messages and Codes, GC26-9940
v DB2 ODBC Guide and Reference, SC26-9941
v DB2 Reference for Remote DRDA Requesters and Servers, SC26-9942
v DB2 Reference Summary, SX26-3847
v DB2 Release Planning Guide, SC26-9943
v DB2 SQL Reference, SC26-9944
v DB2 Text Extender Administration and Programming, SC26-9948
v DB2 Utility Guide and Reference, SC26-9945
v DB2 What's New? GC26-9946
v DB2 XML Extender for OS/390 and z/OS Administration and Programming, SC27-9949
v DB2 Program Directory, GI10-8182
DB2 Administration Tool
v DB2 Administration Tool for OS/390 and z/OS User’s Guide, SC26-9847
DB2 Buffer Pool Tool
v DB2 Buffer Pool Tool for OS/390 and z/OS User’s Guide and Reference, SC26-9306
Net.Data ®
v Net.Data Library: Administration and Programming Guide for OS/390 and z/OS
v Net.Data Library: Language Environment Interface Reference
v Net.Data Library: Messages and Codes
v Net.Data Library: Reference
DB2 PM for OS/390
v DB2 PM for OS/390 Batch User's Guide, SC27-0857
v DB2 PM for OS/390 Command Reference, SC27-0855
v DB2 PM for OS/390 Data Collector Application Programming Interface Guide, SC27-0861
v DB2 PM for OS/390 General Information, GC27-0852
v DB2 PM for OS/390 Installation and Customization, SC27-0860
v DB2 PM for OS/390 Messages, SC27-0856
v DB2 PM for OS/390 Online Monitor User's Guide, SC27-0858
v DB2 PM for OS/390 Report Reference Volume 1, SC27-0853
v DB2 PM for OS/390 Report Reference Volume 2, SC27-0854
v DB2 PM for OS/390 Using the Workstation Online Monitor, SC27-0859
v DB2 PM for OS/390 Program Directory, GI10-8223
Query Management Facility (QMF ™ )
v Query Management Facility: Developing QMF Applications, SC26-9579
v Query Management Facility: Getting Started with QMF on Windows, SC26-9582
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 74 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
v Query Management Facility: High Peformance Option User’s Guide for OS/390 and z/OS,
SC26-9581
v Query Management Facility: Installing and Managing QMF on OS/390 and z/OS, GC269575
CICS Transaction Server for OS/390
v CICS Application Programming Guide, SC33-1687
v CICS External Interfaces Guide, SC33-1703
v CICS DB2 Guide, SC33-1939
v CICS Resource Definition Guide, SC33-1684
Data Facility Data Set Services
v Data Facility Data Set Services: User's Guide and Reference, SC26-4388
Database Design
v DB2 Design and Development Guide by Gabrielle Wiorkowski and David Kull, Addison
Wesley, ISBN 0-20158-049-7
v Handbook of Relational Database Design by C. Fleming and B. Von Halle, Addison Wesley, ISBN 0-20111-434-8
DB2 Connect ®
v DB2 Connect Enterprise Edition for OS/2 and Windows: Quick Beginnings, GC09-2953
v DB2 Connect Enterprise Edition for UNIX: Quick Beginnings, GC09-2952
v DB2 Connect Personal Edition Quick Beginnings, GC09-2967
v DB2 Connect User's Guide, SC09-2954
DB2 Red Books
v DB2 UDB Server for OS/390 Version 6 Technical Update, SG24-6108-00
v DB2 for z/OS and OS/390 Version 7: Using the Utilities Suite, SG24-6289
v DB2 UDB Server for OS/390 and z/OS Version 7 Presentation Guide, SG24-6121
v DB2 Java Stored Procedures -- Learning by Example, SG24-5945
v DB2 UDB for OS/390 Version 7 Performance Topics, SG24-5351
v DB2 for OS/390 Capacity Planning, SG24-2244
v DB2 for OS/390 and Continuous Availability, SG24-5486
v Parallel Sysplex Configuration: Cookbook, SG24-2076-00
v DB2 for OS390 Application Design for High Performance, GG24-2233
v Storage Management with DB2 for OS/390, SG24-5462
DB2 Universal Database for UNIX, Windows, OS/2
v DB2 UDB Administration Guide: Planning, SC09-2946
v DB2 UDB Administration Guide: Implementation, SC09-2944
v DB2 UDB Administration Guide: Performance, SC09-2945
v DB2 UDB Administrative API Reference, SC09-2947
v DB2 UDB Application Building Guide, SC09-2948
v DB2 UDB Application Development Guide, SC09-2949
v DB2 UDB CLI Guide and Reference, SC09-2950
v DB2 UDB SQL Getting Started, SC09-2973
v DB2 UDB SQL Reference Volume 1, SC09-2974
v DB2 UDB SQL Reference Volume 2, SC09-2975
Distributed Relational Database Architecture ™
v Data Stream and OPA Reference, SC31-6806
v IBM SQL Reference, SC26-8416
v Open Group Technical Standard
v DRDA Version 2 Vol. 1: Distributed Relational Database Architecture (DRDA)
v DRDA Version 2 Vol. 2: Formatted Data Object Content Architecture
v DRDA Version 2 Vol. 3: Distributed Data Management Architecture
Parallel Sysplex ® Library
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 75 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
v OS/390 Parallel Sysplex Application Migration, GC28-1863
v System/390 Z/OS Sysplex Hardware and Software Migration, GC28-1862
v OS/390 Parallel Sysplex Overview: An Introduction to Data Sharing and Parallelism,
GC28-1860
v OS/390 Parallel Sysplex Systems Management, GC28-1861
v OS/390 Parallel Sysplex Test Report, GC28-1963
Storage Management
v DFSMS/Z/OS Storage Management Library: Implementing System-Managed Storage,
SC26-3123
v MVS/ESA Storage Management Library: Leading a Storage Administration Group, SC263126
v MVS/ESA Storage Management Library: Managing Data, SC26-3124
v MVS/ESA Storage Management Library: Managing Storage Groups, SC26-3125
System/370 ™ and System/390 ®
v ESA/370 Principles of Operation, SA22-7200
v ESA/390 Principles of Operation, SA22-7201
v System/390 MVS Sysplex Hardware and Software Migration, GC28-1210
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 76 von 77
DB2 –Physisches Design
DB2 Objekte - Strukturierungsempfehlungen
ENDE
© S.K.Consulting Services GmbH
++49 (0)162 4468790
www.sk-consulting.de
Seite 77 von 77