DB2. Effizientes DB-Design und Physische Strukturen. Standards, Tipps und Grundlagen zu DB2-Datenmodellen und deren Implementierung in der DB2-Physik

Transkript

1 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) Ausgabe 10: Seite von V

2 Inhaltsverzeichnis Inhaltsverzeichnis 1 VORWORT GRUNDSÄTZLICHES ZU DB2 UND PERFORMANCE Optimierungspotentiale bei DB Logische Datenmodellierung Ziel der Datenmodellierung Integrität Redundanzen Wartbarkeit und Flexibilität Wiederverwendbarkeit und Mehrfachverwendbarkeit Eigenschaften des logischen Datenmodells Einsatzmöglichkeiten des logischen DM im Sofware-Life-Cycle(SLC) Logische Datenmodellierung Beispiel Physisches DB-Design und seine Umsetzung nach DB Allgemeine Vorgehensweise Vorgehensweise gemäß Ziel-DBMS DAS PHYSISCHE DB-DESIGN BEI DB Überführung des Informationsmodells - allgemeine Vorgehensweise Übernahme von Satztypen Zusammenlegen von Satztypen Denormalisierung Trennen von Satztypen Schaffung zusätzlicher Tabellen Ergänzen zusätzlicher Felder im physischen Datenmodell Grundsätzliche Regel bei DB Überführen der Beziehungen Einrichten der Zugriffspfade am Beispiel DB Festlegen der physikalischen DB-Struktur Festlegen der DB2 Datentypen VARCHAR Alternativen zugunsten der Performance Weitere Limits in DB2 seit Version S.K.Consulting Services GmbH ++49 (0) Seite 2 von 104

3 Inhaltsverzeichnis 4 EMPFEHLUNGEN ZUM PHYSISCHEN DESIGN VON DB2 DATENBANKEN Allgemeines zum Design von DB2-Datenbanken Empfehlungen zum physischen Design von DB2 Datenbanken DB2-OBJEKTE STRUKTURIERUNGSEMPFEHLUNGEN Die Hierarchie der physischen DB2-Objekte Datenbanken (Databases) Die wichtigsten Definitionsparameter Autorisierungen Beispiele zur Definition von Databases Tipps zum Erzeugen von Databases Tabellenspeicher (Tablespaces) Die Namensvergabe für TS Explizites Erzeugen eines Tablespace Implizites Erzeugen eines Tablespace Die DB2 Tablespace Typen EA-enabled Tablespaces und Indexspaces Simple table spaces Universal Table spaces Large Object Tablespaces (LOB TS) inline LOBs (ab DB2 10) XML Tablespaces Partitionierte Tablespaces Ziel und Einsatz von PTS Weitere Überlegungen zu PTS(Pros und Contra) TS Limits ab V PTS-Typen seit DB2 Version Einsatz und Aufbau von segmented TS Empfehlungen zu "tablespaces" Die Zuweisung von TS auf einen physischen Speicherplatz TABLESPACE- Definition Beispiele zum CREATE TS Die TS und ihre Zustände(Status) Tabellen (Tables) Die Datentypen für DB2 Tabellen Strategien zur Anordnung von Tabellenspalten Tabellendesign und JAVA Performance Neue Tabellen- TS-Typen seit DB2 Version Die wichtigsten Definitionsparameter zur table Die Größe von Tabellen (Tables) Große Tabellen (LARGE Tables) Partitionierung großer Tabellen (LTS) INSERT-Algorithmen unter Nutzung des "partitioned Index" INSERT-Algorithmen unter Nichtbeachtung des "partitioned Index" "Combined Technique"-INSERT-Algorithmen "Code-Tables" "Flip-Flop Tables" "Hot Spots" VOLATILE Tables Global temporary Tables - CTT, DTT S.K.Consulting Services GmbH ++49 (0) Seite 3 von 104

4 Inhaltsverzeichnis Clone Tables "materialized query tables"(mqt's) und "automatic query rewrite"(aqr) Temporal Tables (ab DB2 10) DB2 9 neue Datenformate(RRF/BRF etc) Optimales Logging Verhalten bei DB2 Tabellen Referenzielle Constraints Table Check Constraints Definition einer generierten Spalte in einer neuen Tabelle Beispiele zum Table CREATE Weitere Tips zum Table Design Indizes (Indexe) Indexstrukturen und Konzepte Indexarten Die Indexdefinition Überlegungen zu Indizes Die Struktur eine Typ-2 Index Der Einsatz von "clustering" Indizes Der "Partitioned Index" "Non-Partitioning Secondary Indexes"(NPSI) "Data Partitioned Secondary Indexes"(DPSI) LOB Indexes XML Indexe Non-Unique Indexe Ersatzstrategien zu Non-Unique Indizes über Design-Maßnahmen Die Index-Klausel UNIQUE WHERE NOT NULL "Non-Partititioned" Index "Pieces" Indizes zur Vermeidung von Sort-Vorgängen Indizes auf mehr als einer Spalte Anlegen und Wiederfinden von langen IX-Einträgen Match-Codes Ergänzen weiterer Felder Die Indizierung von VARCHAR Spalten Index on expression Weitere Tipps zum Index-Design Indexing -Strategien für optimale Performance Komprimieren von Indizes Index Maintenance Queries und mögliche Indizierungsstrategien CREATE INDEX - Beispiele Views Sinn und Zweck von Views Benutzen von common table expression anstelle von VIEWs Alias Besondere DB2-Objekte Sequences Die Entscheidung für identities und/oder sequences Beispiele für sequences und Identity columns Tabellen mit mehrdimensionalem Clustering MDC Tabellen Materialized Query Tables MQT s PARALLELE VERARBEITUNGSPROZESSE Locking bei DB Die Begriffe beim "Locking S.K.Consulting Services GmbH ++49 (0) Seite 4 von 104

5 Inhaltsverzeichnis Probleme beim Locking Verbessern der Lock-Verwendung Generelle Empfehlungen Vermeiden von "false contention" Monitoring auf "false contention" Wieviel contention ist akzeptabel? Wie kann man false contentions reduzieren? Verändern der Größe einer lock structure Dynamische Änderung der lock structure Größe Ändern der lock structure Größe durch Neuaufbau Verringern der lock entry size Reduzieren der Zeit bis zur Auflösung von contentions Vermeiden von partition locks auf alle TS Partitions Der LOCKSIZE-Parameter und seine Bedeutung Anzahl "rows per page" Die Ebenen der Kontrolle "Lock Escalation" "row locking" und seine Kosten Index-Design und konkurrierende Verarbeitung Konkurrierende Verarbeitung UPDATE und SELECT(Fall 1) Konkurrierende Verarbeitung UPDATE und SELECT(Fall 2) QUERIES UND PARALLELVERARBEITUNG Queries und Partitionierung Queries und Verarbeitung von PTS Der notwendige Parallelitätsgrad von Queries Einrichten von PTS für Parallelverarbeitung SQL Formulierungen für parallele Verarbeitung Wann ist keine Parallelverarbeitung möglich? DB2 SPEICHERPLATZZUWEISUNG UND SPEICHERVERWALTUNG Das IBM Storage Management Subsystem Speicherplatzgruppen ( Storage Groups ) Typen von Storage Groups Speicherplatzgruppen und die Verteilung der Datasets Beispiele für Storage Groups Tips zu STORAGE GROUPS Der Buffer Manager Grobe Berechnung der Berechnung DB2-Datenbank-Buffer Bereitstellen der Bufferpools Funktionsweise des Buffermanagers Eine Methode zur buffer pool Dimensionierung DB2 Logging LOGBUFSZ - Log buffer size LOGFILSIZ Parameter MINCOMMIT DB Konfigurationsparameter DB2 Work Files workfile spaces Hinzufügen von workfiles S.K.Consulting Services GmbH ++49 (0) Seite 5 von 104

6 Inhaltsverzeichnis 8.6 Temporary Tables CTT s und DTT s im Vergleich Declared Temporary Tables und Performance der AP DB2 Katalog und Directory Performance - Indikatoren im Katalog Überwachung der Speicherorganisation Der Umgang mit PLAN und PACKAGES DB2 und Extents DB2 - PERFORMANCE VON SUBSYSTEMEN Asynchroner Preformat Parallel "data set open" Messumgebung CPU bound Testfall I/O bound Testfall Virtual storage Entlastung Instrumentation Facility Verbesserungen Database address space Nutzung des virtual storage Evaluate uncommitted Beschreibung von EVALUNC Empfehlung Reduziertes Logging für variable-length rows DDL Verbesserung der Parallelverarbeitung Die IRLM-Umgebung und die LOCK-Anforderungen Traces Monitoring DB2 locking Das Kommando DISPLAY DATABASE Nutzung des "coupling facility structure activity report" aus RMF Errechnen der Prozent von "contentions" Anwenden des "DB2 statistics trace" Berechnen der prozentualen "global contentions" Nutzen des "DB2 accounting trace" Nutzen des "DB2 performance trace" Z/OS - FAKTOREN DSNZPARMS Ausgabe der current settings Parameter die für online Änderungen verfügbar sind Beispiele DSNZPARMS S.K.Consulting Services GmbH ++49 (0) Seite 6 von 104

7 Inhaltsverzeichnis 11 ANHANG Checkliste zum physischen DB-Design DB Abbildungsverzeichnis Index Glossar Literaturhinweise S.K.Consulting Services GmbH ++49 (0) Seite 7 von 104

8 Vorwort 1 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 IT- Umgebung 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) Seite 8 von 104

9 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 DB- Design 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/O- Strukturen 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) Seite 9 von 104

10 Grundsätzliches zu DB2 und Performance 2 Grundsätzliches zu DB2 und Performance 2.1 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. DB-Design Design (20%) 4 = Anwendung (60%) = OS System (10%) Bild-01: Tuningpotentiale im DB2-Umfeld S.K.Consulting Services GmbH ++49 (0) Seite 10 von 104

11 Grundsätzliches zu DB2 und Performance 2.2 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) Seite 11 von 104

12 Grundsätzliches zu DB2 und Performance 2.3 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: 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: 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 Wartbarkeit und Flexibilität Die Wartung einer Datenbank teilt sich in technische und strukturelle Aspekte. Zu den technischen Aspekten gehört zum Beispiel das Reindizieren 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) Seite 12 von 104

13 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 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) Seite 13 von 104

14 Grundsätzliches zu DB2 und Performance 2.5 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) Seite 14 von 104

15 Grundsätzliches zu DB2 und Performance 2.6 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 - Beispiel S.K.Consulting Services GmbH ++49 (0) Seite 15 von 104

16 Grundsätzliches zu DB2 und Performance 2.7 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 n- terscheiden. Der physische Designschritt erfolgt erst NACH allen anderen fachlich orientierten Analyse- und Modellierungsschritten. Funk- tions- Analyse Informa- tions- Analyse abgestimmtes Informations- Modell Phys. DB-Design Abstimmung Kanonische Synthese Funk- tions- Modell Elem.- Funktion Informa- tions- Modell 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) Seite 16 von 104

17 Grundsätzliches zu DB2 und Performance Allgemeine Vorgehensweise Basis des physischen DB-Designs bilden die methodischen Säulen: Konzeptionelles Informationsmodell und Prozess- oder Funktionsmodell: Dabei liefern diese beiden Ergebnistypen generell folgende Anhaltspunkte für das Physische Datenbank- Design: Konzeptionelles Informationsmodell Funktionsmodell Grafik Dokumente (Mengen) ( business rules" / Domänen) Grafik Beschreibung (Häufigkeiten) (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) Seite 17 von 104

18 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) Seite 18 von 104

19 Empfehlungen zum physischen Design bei DB2 DBs 3 Das physische DB-Design bei DB2 3.1 Ü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 von 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) 3. Überführen der Beziehungen Behandlung von 1 : 1 "relationship" Behandlung von 1 : n Beziehungen 4. Einrichten der Zugriffspfade Behandlung der Einstiegspunkte Auswahl der physischen Zugriffspfade 5. Festlegen der DBMS-spezifischen Parameter Blockgröße / Satzgröße Speicherplatzgrößen physische Speicherungsfolgen organisatorisch/technische Einflüsse usw. S.K.Consulting Services GmbH ++49 (0) Seite 19 von 104

20 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. Entity- Type = 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 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) Seite 20 von 104

21 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) Seite 21 von 104

22 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 JOIN- Operationen zu verhindern und so die Performance in bestimmten Bereichen, d.h. beim LESEN ( SELECT...), zu steigern. Beispiel: Relation: KUNDE { KD_NR, KD-Name, KD-PLZ, KD-ORT, KD-Strasse..} normalisiert: KUNDE { KD-NR. KD-Name, KD-OKZ, KD-STRNR...} ORT KUNDE_WOHNT_IN { OKZ, O-PLZ, O-ORT, EINWOHNERZAHL...} {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 KONSIS- TENT 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) Seite 22 von 104

23 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 ( 10 Mio. Zeilen ) TRANS-FILIALE TRANS-LFD-NR TRANS-ART.. TRANS-STATUS-1 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. TRANS-STATUS-2 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) Seite 23 von 104

24 Empfehlungen zum physischen Design bei DB2 DBs ACHTUNG Das Problem von Kombinationen verschiedener Status- Informationen 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 von Tabellen zur Verfügung. - Replikation - Partitionierung Vorausgesetzt die technische Implementierung des DBMS bietet diese "features" in der aktuellen Version an. S.K.Consulting Services GmbH ++49 (0) Seite 24 von 104

25 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) Seite 25 von 104

26 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 <columns> FROM account a LEFT OUTER JOIN billing b ON a.accnt# = b.accnt# AND a.optionalbill = Y LEFT OUTER JOIN address c ON a.accnt# = c.accnt# AND a.optionaladress = Y. WHERE a.accnt# = 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, ) Weiterverarbeitungsinformationen z.b. für Datawarehousing, Reporting, Aggregationen... Spezielle Sicherheitskennzeichen S.K.Consulting Services GmbH ++49 (0) Seite 26 von 104

27 Empfehlungen zum physischen Design bei DB2 DBs 3.2 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 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: Eine mögliche Kompressionsrate bei kommerziellen Daten liegt bei % 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. 3.3 Überführen der Beziehungen Beziehungen werden über Schlüsselredundanzen realisiert: primary key" foreign key". Dabei ist es wichtig zu wissen, ob nur eine oder BEIDE Richtungen der Beziehungen benötigt werden. S.K.Consulting Services GmbH ++49 (0) Seite 27 von 104

28 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) Seite 28 von 104

29 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. 5.5 ff.). S.K.Consulting Services GmbH ++49 (0) Seite 29 von 104

30 Empfehlungen zum physischen Design bei DB2 DBs 3.5 Festlegen der physikalischen DB-Struktur 1. Berechnen der TS-Größe a) primary space" / secondary space" b) Bestimmen zusammengehöriger Tabellen für EINEN TS c) Bestimmen des TS-Typs (STS, PTS, normaler TS) d) Festlegen des Füllgrades (PCTFREE, FREEPAGE) e) COMPRESS YES/NO 2. Berechnen der IX-Parameter und der Index-Größe 3. Bestimmen der LOCKING und ISOLATION - Parameter a) LOCKSIZE b) ISOLATION Level RR / CS c) Zuordnung zu STOGROUPS d) DEGREE ANY(?) 4. Festlegen der Datentypen in den Tabellen a) wenige NULL-Felder eher NOT NULL WITH DEFAULT b) keine Tabellen-PROC ( VALIDPROC, EDITPROC, FIELDPROC...) c) keine LONGVARCHAR / VARCHAR - Felder d) VARCHAR und NULL-Felder ans Ende der Tabelle e) Definition der RI-Bedingungen (falls nötig) 5. Festlegen der views" 6. Definition der DB2-Datenbanken a) nach organisatorisch / administrativen Gesichtspunkten b) nach Datenverfügbarkeitsanforderungen (mit Hilfe der Datenbankadministration!) c) 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) Seite 30 von 104

31 Empfehlungen zum physischen Design bei DB2 DBs 3.6 Festlegen der DB2 Datentypen Die Festlegung des Datentyps führt zu 2 wichtigen Bestimmungen bei DB2- Tabellen: 1. Inhalt (Wertebereich) der Spalte, z.b. kann INTEGER nur ganzzahlige Werte aufnehmen von bis Länge des Datenfeldes, z.b. INTEGER ist 4 Byte lang. Datentyp Bedeutung max. Wert Länge CHAR(n) / CHA- RACTER (n) alphanumerisches Feld fester Länge 0 < n < 255 n VARCHAR (n) alphanumerisches Feld variabler Länge 4046 B für 4-KB pages 8128 B für 8-KB pages B für 16-KB pages B für 32-KB pages n LONG VARCHAR "string" variabler Länge Byte <= 32KB BIT repräsentiert nicht ausschließlich CHAR und wird nicht auf druckbare Zeichen konvertiert siehe CHAR SBCS "single-byte-characters": Inhalte werden nach CCSID konvertiert CCSID: "coded chracter set identifier" siehe CHAR MIXED repräsentiert SBCS oder DBCS-Zeichen: "doublebyte-character" siehe CHAR DEC(n,m) / DECIMAL(n,m) NUMERIC(n,m) numerisch gepackt Achtung: Leerstelle nach Komma 1-10**31 bis 10**31-1 <= 8 DECFLOAT IEEE 754r Zahl mit Dezimalpunkt bis oder bis max. Präz. 34 Zahlen. INT / INTEGER binäres Vollwort bis SMALLINT binäres Halbwort bis BIGINT Binäres Doppelwort von 63 Bits , REAL / FLOAT (n) FLOAT / FLOAT (n) DOUBLE PRECI SION TIME (**) Gleitkommakonstante mit einf. Genauigkeit Gleitkommakonstante mit doppelter Genauigkeit interne Zeitdarstellung ( ttmmss ) FP in 32 bits bis FP in 64 bits bis Zeitwert: bis DATE (**) interne Datumsdarstel- Datum: bis 4 S.K.Consulting Services GmbH ++49 (0) Seite 31 von 104

32 Empfehlungen zum physischen Design bei DB2 DBs Datentyp Bedeutung max. Wert Länge lung ( yyyymmdd ) TIMESTAMP (**) Datum + Zeit + Systemzeit TIMESTAMP WITHOUT TIME ZONE TIMESTAMP WITH TIME ZONE ' ' : (2B TZ) ROWID eindeutiger Identfier einer Tab-Zeile(ausschliesslich BIT) 17(intern) CLOB variabel Large CHAR Objekt (SBCS oder mixed ) 2 GB - 1 BLOB variabel Large binary Objekt(for BIT DATA) 2 GB - 1 DBLOB variabel double-byte CHAR Objekt (DBCS) 1 GB 1 BINARY fixed length Binär-String 1 bis 255 VARBINARY XML variable length Binär- String Ein XML Wert mit der Repräsentation eines well-formed XML als XML Dokument, XML Inhalt, der eine Folge von XML nodes. 1 bis DISTINCT Type (*) Ist ein "user defined datatype" Bild-14: Länge und Typen von Datenfeldern CREATE TYPE MONEY AS DECIMAL(9,2); CREATE FUNCTION "+"(MONEY,MONEY) RETURNS MONEY SOURCE SYS- IBM."+"(DECIMAL(9,2),DECIMAL(9,2)); CREATE TABLE SALARY_TABLE (SALARY MONEY, COMMISSION MONEY); SELECT SALARY + COMMISSION FROM SAL- ARY_TABLE; (*) 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 "builtin 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 und alle diese Funktionen sind nicht auf andere Datentypen anwendbar. S.K.Consulting Services GmbH ++49 (0) Seite 32 von 104

33 Empfehlungen zum physischen Design bei DB2 DBs (**) Da die defaults in 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 NOT NULL UNIQUE, e_dat DATE DEFAULT ' ' ) IN... 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 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 bei stark variierenden Wertevorkommen in einer Spalte gesetzt werden ( ab Bytes Feldlänge ). VARCHARs werden bei SORT-Vorgängen IMMER auf ihre maximale Länge expandiert ( Anzahl work files, merge Durchgänge, längere SORT- Zeiten ) VARCHARs sparen Platz für die Tabellen aber nicht für Indexe sie expandieren immer zur vollen Länge (außer ab DB2 V8 mit dem optionalen PAD- DED Parameter) 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 darzustellen Einsatz von LOBs (falls die Referenz auf die LOB-Werte nicht zu hochfrequent ist) Man muss allerdings den entstehenden Aufwand testen Nutzen von fixen Spalten anstatt VARCHARs und Auslagern der overflow - Daten in eine eigene Tabelle Das funktioniert immer, 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 synchrone durchzuführenden I/Os Daten-Scans verursachen, was die Performance sehr negativ beeinflussen kann. S.K.Consulting Services GmbH ++49 (0) Seite 33 von 104

34 Empfehlungen zum physischen Design bei DB2 DBs Häufig modifizierte VARCHAR-Felder haben außerdem die Eigenschaft, häufigere REORG-Aktivitäten zu verursachen, was wiederum die Verfügbarkeit der Daten negativ beeinflussen kann. Bei Indexen gibt es sei9t DB2 V8 die Option NOT PADDED. Damit werden VAR- CHAR-Felder im Index nicht mehr auf ihre volle Länge expandiert. Man kann damit den Index für INDEX ONLX Zugriffe einsetzen. Will man diese Option ändern ALTER INDEX. NOT PADDED - so wird der IX in den Status rebuild pending (RBDP) versetzt, bis er neu erstellt wird. Aber auch hier gilt: NOT PADDED IX sind komplex in ihrer Verarbeitung (Längenermittlung) NOT PADDED IX verbrauchen mehr CPU Spaltenvergleiche sind erheblich teurer bei NOT PADDED 3.8 Weitere Limits in DB2 seit Version 8 Seit der DB2 V8 gelten noch weitere Limits, die hier berücksichtigt werden müssen: Objekt Länge des Table name (*) Länge des Column name Max. Größe des Index key (Bytes) Max. Hex / Character Literale Max. Länge von Prädikaten Max. SQL Statement Länge Tables in einer Tabelle / Join Max. Anzahl offene Datasets Max. Anzahl Partitions beim PTS Max. Table /TS Grösse Max. Anzahl Databases Max. Anzahl Objekte pro Database Anz. concurrent threads Max. Zeilenlänge einer Tabelle Max. Anzahl Spalten im View/Tabelle Max. Anzahl Spalten in einem IX Anzahl max. Dezimalstellen Max. Grösse einer VARCHAR-Spalte DB2 V KB 225 / TB ( ) K DB2 V MB 225 / TB (*) gilt auch für die meisten anderen DB2 Objekte, wie views, aliases, index, triggers, synonyms,... Bild-15: Neue Längen und Limits in DB2 V8 S.K.Consulting Services GmbH ++49 (0) Seite 34 von 104

35 4 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 SMITH ROBERT (null) Anschließend SMITH ROBERT Z dann wird der letzte Satz nicht als "high key" verarbeitet (!) S.K.Consulting Services GmbH ++49 (0) Seite 35 von 104

36 (5) "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) Seite 36 von 104

37 (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 wich- S.K.Consulting Services GmbH ++49 (0) Seite 37 von 104

38 tig, 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 CURR- ENTDATA 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) Seite 38 von 104

39 (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 grundlegende Empfehlungen zum Umgang mit DB2-Objekten und DB2- Programmen. 4.2 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. Man sollte die Designer ihre Arbeit machen lassen und die Datenbank eine erste Entscheidung für die Zugriffspfade. Es sollte ein Einfaches sein, Testtabellen zu erstellen und wichtige Performance- Situationen 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 - Messen Sie die Alternativen - Erstellen Sie Dokumentationen und Reports S.K.Consulting Services GmbH ++49 (0) Seite 39 von 104

40 5 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) 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 Punkten 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) Seite 40 von 104

41 Database Non-partitioned TS Table t1 Table t2 Storage Group G1 Volume 1 Index Space Index Space Volume 3 Index X1 Index X2 Volume 2 Partitioned Táblespace Table Part1 Indexspace Partitioning IX Part1 Part2 Part2 Part3 Part3 Part4 Part4 Storage Group G2 Volume 1 Volume 3 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) 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) Seite 41 von 104

42 5.2.1 Die wichtigsten Definitionsparameter 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 darf nicht bestehen aus 8 Zeichen, die mit DSN beginnen, gefolgt von genau 5 Ziffern. 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. AS WORKFI- LE kann ausschließlich in data sharing Umgebungen angegeben werden. Es kann dort nur EINE work file database pro DB2 Subsystem geben. Die work file database wird genutzt für work files, created global temporary tables, declared temporary tables und sensitive static scrollable cursors. 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 wurde. 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 EN- CODING SCHEME im Installationspanel DSNTIPF. Die CCSID Klausel ist nicht erlaubt, wenn die Klausel AS WORKFILE angegeben wurde. S.K.Consulting Services GmbH ++49 (0) Seite 42 von 104

43 5.2.2 Autorisierungen Die erforderlichen Privilegien für einen CREATE DATABASE müssen mindestens eine der folgenden Autorisierungen beinhalten: CREATEDBA CREATEDBC SYSADM oder SYSCTRL 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 DATABASE D8D91P STOGROUP STG8G910 BUFFERPOOL BP8K1 INDEXBP BP2; 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; Tipps zum Erzeugen von Databases 1. Nutzen Sie DB2-Datenbanken als Einheiten für die Verfügbarkeit von Tabellen und Indizes (START/STOP). 2. DB2-"security"-Mechanismen können auch auf "database"-ebene vergeben werden. 3. Vermeiden Sie Verweilzeiten im DB2-Katalog. Geben Sie JEDEM Entwickler SEINE (private) "database". 4. Es kann sinnvoll sein, nur EINE TS pro DATABASE zu erlauben, besonders, wenn die Tabelle(n) sehr groß sind ( ) 5. generell gilt die Regel, dass nicht mehr als 50 bis 100 TS in einer database angelegt werden sollten 6. Die maximale Anzahl von database.-objekten, die in einem DB2- Subsystem verwaltet werden können, sind derzeit S.K.Consulting Services GmbH ++49 (0) Seite 43 von 104

44 5.3 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-18: Die neuen TS Typen seit DB2 V9 TS Die Namensvergabe für TS Ein TS-Name kann aus bis zu acht Buchstaben/Ziffern bestehen und müssen 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. Im CM (V9) ist der TS Typ dabei segmented. Im NFM (V9) ist der TS Typ entweder partition-by-growth oder range-partitioned. S.K.Consulting Services GmbH ++49 (0) Seite 44 von 104

45 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 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 ff). Detaillierte Information über CREATE TABLESPACE erhält man aus den Manual DB2 SQL Reference 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 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 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 zu- S.K.Consulting Services GmbH ++49 (0) Seite 45 von 104

46 sammen 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) usw. Sie sind entsprechend ihrer Verwendungsabsicht zu definieren, um so u.a. ein Fundament für gute, technische DB2-Performance zu legen 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 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 Partitions auf. (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 oder auch bekannt als auxiliary TS) sind erforderlich zur Speicherung von LOB-Daten, wie Grafiken, Videodaten oder sehr großen Text- Strings. S.K.Consulting Services GmbH ++49 (0) Seite 46 von 104

47 Passen die Daten nicht mehr in eine Datenpage, so kann man also eine oder mehrere Spalten einer Tabelle als LOB Spalte definieren. (7) XML Tablespaces Ein XML Tablespace speichert eine XML Tabelle EA-enabled Tablespaces und Indexspaces 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 maximale Partitiongrösse (DSSIZE) so gewählt hat, dass sie im CREATE TAB- LESPACE 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 Bis zu 4096 Partitions mit je 64 GB Erzeugt mit einem beliebigen Wert für DSSIZE Datasets sind SMS managed Erfordert einen speziellen Setup Non-EA-enabled Tablespaces Bis zu 4096 Partitions mit jeweils 4 GB DSSIZE kann nicht grösser als 4 GB sein Datasets sind VSAM- oder SMSmanaged Kein spezieller Setup erforderlich Bild-19: Unterschiede zwischen EA-enabled und non-ea enabled TS 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 S.K.Consulting Services GmbH ++49 (0) Seite 47 von 104

48 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 TAB- LESPACE 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 änder, um z.b. die extended addressability bzw. die extended format Attribute abzuschalten. Ändert jemand die data class, um die extended addressability bzw. die extended format Attribute abzuschalten, so setzt DB2 eine Fehlermeldung ab, wenn das page set das nächste Mal geöffnet werden soll 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 LOCKSI- ZE Angabe mit ROW. Empfehlung: Man sollte alle noch existierenden simple TS so schnell, wie möglich, in segmented TS konvertieren 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 und range-partitioned TS. TS, die beides sind segmented und partitioned werden sowohl mit SEGSIZE und NUMPARTS Parameter definiert. Der letztendliche UTS Typ wird über die Spezifikation in den Klauseln SEGSIZE, MAXPARTITIONS bzw. NUMPARTS festgelegt. Gibt man SEGSIZE mit NUMPARTS an, so wird der TS als range-partitioned UTS angelegt. Ist SEGSIZE mit MAXPARTITIONS angegeben, wird der TS als partitionby-growth UTS angelegt. S.K.Consulting Services GmbH ++49 (0) Seite 48 von 104

49 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 Nicht spezifiziert Nicht spezifiziert Nicht spezifiziert PBG TS mit implizit SEGSIZE 4 Segmented TS mit implizit SEGSIZE 4 Nicht spezifiziert Nicht spezifiziert spezifiziert Partitioned TS Bild-20a: UTS: Die Tablespace-Typen 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 S.K.Consulting Services GmbH ++49 (0) Seite 49 von 104

50 Die Nutzung von UTS in DB2 9 In DB2 9 wurden UTS für folgende Zwecke angelegt: XML TS, wobei die base table segmentiert, partitioniert oder UTS sein kann CLONE Tables Die Nutzung von UTS in DB2 10 In DB2 10 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 partitioned table spaces, nicht aber mit segmented table spaces Konvertieren auf UTS In DB2 9 kann man einen TS nicht auf UTS konvertieren, ohne DROP und re- CREATE. 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) Seite 50 von 104

51 ALTER 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 Sie verwenden das Attribut MAXPARTITIONS des ALTER TABLESPACE Statements, um die maximale partition size für partition-by-growth TS festzulegen. Man kann dieses Attribut auch dazu verwenden, um eine single-table in einem S.K.Consulting Services GmbH ++49 (0) Seite 51 von 104

52 simple tablespace oder eine single-table in einem segmented tablespace auf einen partition-by-growth Universal TAS zu konvertieren. Zusätzlich dazu kann man das Attribut SEGSIZE im ALTER TABLESPACE dzu nutzen, einen partitioned tablespace in einen range-partitioned universal table space zu konvertieren. Bild-20b: UTS: Konvertierung von Tablespaces Diverse Konvertierungen sind nur erlaubt für single-table table spaces und Konvertierungen aus hash table spaces zurück, nutzt nicht mehr die Technik der pending changes Neuer default table space zur CREATE Zeit In DB2 10, wenn ein neuer TS angelegt werden soll, so sind segmented table spaces nicht mehr der default. Partition-by-growth UTS lautet der neue default. Will man einen range partitioned UTS anlegen, so müssen die Werte für NUM- PARTS und SEGSIZE gesetzt werden. Will man einen klassischen partitioned table space erzeugen, muss man SEGSIZE 0 beim CREATE TABLESPACE verwenden. Man kann aber auch den neuen default partition SEGSIZE DSNZPARM DPSEGSZ=0 im Makro DSN6SYSP setzen ( default ist 32). Will man 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(!) MEMBER CLUSTER Option für UTS N/A für non SYSPLEX S.K.Consulting Services GmbH ++49 (0) Seite 52 von 104