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

Größe: px
Ab Seite anzeigen:

Download "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

DB2 DB-Design und physische Strukturen

DB2 DB-Design und physische Strukturen Standards, Tipps und Grundlagen zur DB2-Datenmodellen und deren Implementierung in der DB2-Physik DB2 DB-Design und physische Strukturen Ausgabe 2: 2004/2005 S.K. Consulting Services ++49 8106 994390 www.sk-consulting.de

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Cassandra Query Language (CQL)

Cassandra Query Language (CQL) Cassandra Query Language (CQL) Seminar: NoSQL Wintersemester 2013/2014 Cassandra Zwischenpräsentation 1 Gliederung Basic facts Datentypen DDL/DML ähnlich zu SQL Besonderheiten Basic facts CQL kurz für

Mehr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr Raum: LF 230 Bearbeitung: 9.-11. Mai 2005 Datum Gruppe Vorbereitung Präsenz Aktuelle Informationen unter: http://www.is.informatik.uni-duisburg.de/courses/dbp_ss03/ Tabellen in IBM DB2 Tabellen Eine relationale

Mehr

Inhaltsverzeichnis. Installationsübersicht. A. Installationsübersicht

Inhaltsverzeichnis. Installationsübersicht. A. Installationsübersicht Inhaltsverzeichnis A. Installationsübersicht B. und Optimierungsbereiche B.1 Hardware B.2 OperatingSystem Z/OS B.3 Databasemanagementsystem DB2 B.4 Applikation C. Organisation BSS_Chart-library 1 Installationsübersicht

Mehr

SQL (Structured Query Language) Schemata Datentypen

SQL (Structured Query Language) Schemata Datentypen 2 SQL Sprachelemente Grundlegende Sprachelemente von SQL. 2.1 Übersicht Themen des Kapitels SQL Sprachelemente Themen des Kapitels SQL (Structured Query Language) Schemata Datentypen Im Kapitel SQL Sprachelemente

Mehr

ORACLE und IBM DB2 Datentypen 14.12.2011

ORACLE und IBM DB2 Datentypen 14.12.2011 1/27 ORACLE und IBM DB2 Datentypen PHP-User-Group Stuttgart 14.12.2011 ORACLE Datentypen ein Überblick IBM DB2 Datentypen ein Überblick 2/27 ORACLE und IBM DB2 Datentypen Wer Wer bin bin ich ich?? Thomas

Mehr

IBM DB2 für Linux/Unix/Windows Monitoring und Tuning

IBM DB2 für Linux/Unix/Windows Monitoring und Tuning IBM DB2 für Linux/Unix/Windows Monitoring und Tuning Seminarunterlage Version: 4.05 Version 4.05 vom 9. Februar 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt-

Mehr

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten Einführung in SQL Die Sprache SQL (Structured Query Language) ist eine Programmiersprache für relationale Datenbanksysteme, die auf dem ANSI-SQL-Standard beruht. SQL wird heute von fast jedem Datenbanksystem

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar Qt-Seminar Dienstag, 10.2.2009 SQL ist......die Abkürzung für Structured Query Language (früher sequel für Structured English Query Language )...ein ISO und ANSI Standard (aktuell SQL:2008)...eine Befehls-

Mehr

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software SQL Tutorial SQL - Tutorial SS 06 Hubert Baumgartner INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien Inhalt des Tutorials 1 2 3 4

Mehr

ANDREAS PROUZA. Wien, 2015-03-27. andreaspr@aon.at andreas@prouza.at. http://www.prouza.at

ANDREAS PROUZA. Wien, 2015-03-27. andreaspr@aon.at andreas@prouza.at. http://www.prouza.at DB2 & SQL E I N F Ü H R U N G T U N I N G O P T I M I E R U N G S E C R E T S ANDREAS PROUZA andreaspr@aon.at andreas@prouza.at http://www.prouza.at Wien, 2015-03-27 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis...

Mehr

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen: 1 Einführung in Datenbanksysteme Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte

Mehr

Einführung in SQL Datenbanken bearbeiten

Einführung in SQL Datenbanken bearbeiten Einführung in SQL Datenbanken bearbeiten Jürgen Thomas Entstanden als Wiki-Buch Bibliografische Information Diese Publikation ist bei der Deutschen Nationalbibliothek registriert. Detaillierte Angaben

Mehr

Transaktionen in der Praxis. Dr. Karsten Tolle

Transaktionen in der Praxis. Dr. Karsten Tolle Transaktionen in der Praxis Dr. Karsten Tolle Praxisbeispiel in Java Connection con = null; try { con = DriverManager.getConnection("jdbc:db2:sample"); } catch (Exception e) { e.printstacktrace(); } con.setautocommit(false);

Mehr

Inhalt. Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle. Daten und Tabellen - ein Beispiel. Daten und Tabellen - Normalisierung

Inhalt. Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle. Daten und Tabellen - ein Beispiel. Daten und Tabellen - Normalisierung Inhalt Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle Daten und Tabellen Normalisierung, Beziehungen, Datenmodell SQL - Structured Query Language Anlegen von Tabellen Datentypen (Spalten,

Mehr

Zugriffe auf DB2-Datenbanken

Zugriffe auf DB2-Datenbanken Zugriffe auf DB2-Datenbanken S.K. Consulting GmbH, München DB2_SQL_PERF - 1 - Inhaltsverzeichnis I. Der Zugriffspfad bei DB2 1.1 Query Typen 1.2 Ermittlung des Zugriffspfads 1.2.1 Faktoren der Entscheidung

Mehr

PostgreSQL im praktischen Einsatz. Stefan Schumacher

PostgreSQL im praktischen Einsatz. Stefan Schumacher PostgreSQL im praktischen Einsatz 2. Brandenburger Linux Infotag 2005 Stefan Schumacher , PGP Key http:/// $Header: /home/daten/cvs/postgresql/folien.tex,v 1.11 2005/04/25

Mehr

7 Die Reorganisation von DB2

7 Die Reorganisation von DB2 Ab und an sollte eine Tabelle reorganisiert werden. Besonders, nachdem größere Datenmengen eingefügt oder gelöscht wurden, muß über eine Reorganisation nachgedacht werden. Eine optimale Performance ist

Mehr

17.2 MS-Access Projekte

17.2 MS-Access Projekte 964 Von MS-Access 2000 zum SQL-Server 17.2 MS-Access Projekte MS-Access-Projekte, die die Dateiendung adp besitzen, werden als Front-End-Anwendung verwendet. Für die Back-End-Seite gibt es mehrere Möglichkeiten.

Mehr

SQL structured query language

SQL structured query language Umfangreiche Datenmengen werden üblicherweise in relationalen Datenbank-Systemen (RDBMS) gespeichert Logische Struktur der Datenbank wird mittels Entity/Realtionship-Diagrammen dargestellt structured query

Mehr

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER INHALTSVERZEICHNIS 1. Datenbanken 2. SQL 1.1 Sinn und Zweck 1.2 Definition 1.3 Modelle 1.4 Relationales Datenbankmodell 2.1 Definition 2.2 Befehle 3.

Mehr

SQL Performance - Tips Do's & Don'ts

SQL Performance - Tips Do's & Don'ts SQL Performance - Tips Do's & Don'ts S.K. Consulting GmbH, München DB2_SQL_PERF - 1 - Inhaltsverzeichnis I. Richtlinien bei der Verwendung von SQL 1.1. In Programmen "verbotene" SQL- Anweisungen 1.2 SQL

Mehr

(*) IBM DB2 V8 for z/os. DB2 Versionen. (*) ist eingetragenes Warenzeichen der IBM International Business Machines Inc. Feb 2005 1

(*) IBM DB2 V8 for z/os. DB2 Versionen. (*) ist eingetragenes Warenzeichen der IBM International Business Machines Inc. Feb 2005 1 (*) IBM DB2 V8 for z/os DB2 Versionen (*) ist eingetragenes Warenzeichen der IBM International Business Machines Inc. 1 Neuerungen der DB2 UDB Version 7 für z/os (Release-Datum: ca. Juli 2001): Universelle

Mehr

Performance Tuning mit @enterprise

Performance Tuning mit @enterprise @enterprise Kunden-Forum 2005 Performance Tuning mit @enterprise Herbert Groiss Groiss Informatics GmbH, 2005 Inhalt Datenbank RMI JAVA API HTTP Konfiguration Analyse Groiss Informatics GmbH, 2005 2 Datenbank

Mehr

DGD-DB2-Ausbildung. DB2-IMP Implementierung des physischen Daten-Modells. DB2-Temporal Tables Fachliche und technische Daten-Versionierung

DGD-DB2-Ausbildung. DB2-IMP Implementierung des physischen Daten-Modells. DB2-Temporal Tables Fachliche und technische Daten-Versionierung 1 DGD-DB2-Ausbildung Strategischer Überblick Grundausbildung DB2-M DB2-Einführung und Konsequenzen SQL-GR SQL-Grundlagen Einführung in die Sprache Logische Daten-Modellierung DB2-PROG DB2-Anwendungsprogrammierung

Mehr

Relationale Datenbanken in der Praxis

Relationale Datenbanken in der Praxis Seite 1 Relationale Datenbanken in der Praxis Inhaltsverzeichnis 1 Datenbank-Design...2 1.1 Entwurf...2 1.2 Beschreibung der Realität...2 1.3 Enitiy-Relationship-Modell (ERM)...3 1.4 Schlüssel...4 1.5

Mehr

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

Erste Schritte, um selber ConfigMgr Reports zu erstellen

Erste Schritte, um selber ConfigMgr Reports zu erstellen Thomas Kurth CONSULTANT/ MCSE Netree AG thomas.kurth@netree.ch netecm.ch/blog @ ThomasKurth_CH Erste Schritte, um selber ConfigMgr Reports zu erstellen Configuration Manager Ziel Jeder soll nach dieser

Mehr

IBM Informix SQL. Seminarunterlage. Version 11.04 vom

IBM Informix SQL. Seminarunterlage. Version 11.04 vom Seminarunterlage Version: 11.04 Version 11.04 vom 27. April 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1.

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1. Inhalt der Vorlesung Literatur 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen

Mehr

Einstieg in das SQL- und Datenbanktuning 14.01.2009. Loblied auf den Tabellen-Index!

Einstieg in das SQL- und Datenbanktuning 14.01.2009. Loblied auf den Tabellen-Index! 1/40 PHP-User-Group Stuttgart 14.01.2009 Warum Datenbanken einen Hals bekommen und was sich dagegen tun lässt. Tuning und Performancesteigerung ohne zusätzliche Hardware. Ein. Loblied auf den Tabellen-Index!

Mehr

Oracle Datenbank - Tuning

Oracle Datenbank - Tuning Oracle Datenbank - Tuning H.-G. Hopf Georg-Simon-Ohm Fachhochschule Nürnberg Datenbank Tuning / 1 Η. G.Hopf / 10.04.2003 Inhaltsverzeichnis Tuning Datenstruktur-Ebene SQL-Befehls-Ebene Anwendungsebene

Mehr

DB2 SQL, der Systemkatalog & Aktive Datenbanken

DB2 SQL, der Systemkatalog & Aktive Datenbanken DB2 SQL, der Systemkatalog & Aktive Datenbanken Lehr- und Forschungseinheit Datenbanken und Informationssysteme 1 Ziele Auf DB2 Datenbanken zugreifen DB2 Datenbanken benutzen Abfragen ausführen Den Systemkatalog

Mehr

Dipl. Inf. Eric Winter. PostgreSQLals HugeData Storage Ein Erfahrungsbericht

Dipl. Inf. Eric Winter. PostgreSQLals HugeData Storage Ein Erfahrungsbericht Dipl. Inf. Eric Winter Entwicklungsleiter PTC GPS-Services GmbH PostgreSQLals HugeData Storage Ein Erfahrungsbericht Inhalt 1. Problembeschreibung 2. Partielle Indexierung 3. Partitionierung 1. Vererbung

Mehr

Persönlichkeiten bei bluehands

Persönlichkeiten bei bluehands Persönlichkeiten bei Technologien bei Skalierbare Anwendungen mit Windows Azure GmbH & co.mmunication KG am@.de; posts..de/am 1 2 3 4 5 6 7 8 9 Immer mehr Mehr Performance Mehr Menge Mehr Verfügbarkeit

Mehr

IBM Informix Tuning und Monitoring

IBM Informix Tuning und Monitoring Seminarunterlage Version: 11.01 Copyright Version 11.01 vom 25. Juli 2012 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Isolationsstufen für. Dr. Karsten Tolle Dienstag 31. Januar 2012

Isolationsstufen für. Dr. Karsten Tolle Dienstag 31. Januar 2012 Isolationsstufen für Transaktionen / Sicherheit Dr. Karsten Tolle Dienstag 31. Januar 2012 Praxisbeispiel in Java Connection con = null; try { con = DriverManager.getConnection("jdbc:db2:sample"); } catch

Mehr

3 Indizes. 3.1 Indexarchitektur von SQL Server. SQL Server 2008: Datenbankentwicklung

3 Indizes. 3.1 Indexarchitektur von SQL Server. SQL Server 2008: Datenbankentwicklung 3 Indizes 3.1 Indexarchitektur von SQL Server Die folgende Abbildung zeigt die Organisationsstruktur einer Tabelle. Eine Tabelle befindet sich in einer oder mehreren Partitionen, und jede Partition enthält

Mehr

TimeSafe Leistungserfassung

TimeSafe Leistungserfassung Keep your time safe. TimeSafe Leistungserfassung Adressimport 1/8 Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 Allgemeines... 3 1.1 Adressen in der TimeSafe Leistungserfassung... 3 1.2 Organisationen und/oder

Mehr

NoSQL mit Postgres 15. Juni 2015

NoSQL mit Postgres 15. Juni 2015 Tag der Datenbanken 15. Juni 2015 Dipl.-Wirt.-Inform. Agenda l Vorstellung l Marktübersicht l Warum PostgreSQL? l Warum NoSQL? l Beispielanwendung Seite: 2 Vorstellung Dipl.-Wirt.-Inform. [1990] Erste

Mehr

PostgreSQL in großen Installationen

PostgreSQL in großen Installationen PostgreSQL in großen Installationen Cybertec Schönig & Schönig GmbH Hans-Jürgen Schönig Wieso PostgreSQL? - Die fortschrittlichste Open Source Database - Lizenzpolitik: wirkliche Freiheit - Stabilität,

Mehr

7. Datenbank-Zugriff. Vorlesung und Übung Dr. Peter Pfahler Institut für Informatik Universität Paderborn. Zum Beispiel aus PHP-Skripten: Client 7-2

7. Datenbank-Zugriff. Vorlesung und Übung Dr. Peter Pfahler Institut für Informatik Universität Paderborn. Zum Beispiel aus PHP-Skripten: Client 7-2 5 Vorlesung und Übung Dr. Peter Pfahler Institut für Informatik Universität Paderborn 7 7. Datenbank-Zugriff Zum Beispiel aus PHP-Skripten: Client 7-2 Struktur einer Datenbank 7-3 Erzeugen von Datenbanken

Mehr

Und ewig "locked" die Datenbank - Locking in Oracle R11 und IBM DB2

Und ewig locked die Datenbank - Locking in Oracle R11 und IBM DB2 Und ewig "locked" die Datenbank - Locking in Oracle R11 und IBM DB2 PROMATIS software GmbH Ettlingen (TechnologieRegion Karlsruhe) Schlüsselworte R11, DB2, Locking, Partitionierung, LOB, Materialized Views,

Mehr

Einführung in die Informatik II

Einführung in die Informatik II Einführung in die Informatik II Die Structured Query Language SQL Prof. Dr. Nikolaus Wulff SQL Das E/R-Modell lässt sich eins zu eins auf ein Tabellenschema abbilden. Benötigt wird eine Syntax, um Tabellen

Mehr

Werkzeuge für Datenbank Handwerker: IBM Data Studio und IBM Optim QWT

Werkzeuge für Datenbank Handwerker: IBM Data Studio und IBM Optim QWT Werkzeuge für Datenbank Handwerker: IBM Data Studio und IBM Optim QWT Neue Technologien effizient nutzen Ehningen, 3. Juli 2014 Rodney Krick rk@aformatik.de aformatik Training & Consulting GmbH & Co. KG

Mehr

Nachtrag: Farben. Farbblindheit. (Light und Bartlein 2004)

Nachtrag: Farben. Farbblindheit. (Light und Bartlein 2004) Nachtrag: Farben Farbblindheit (Light und Bartlein 2004) 1 Vorgeschlagene Farbskalen (Light and Bartlein 2004) Farbkodierung metrisch skalierter Daten Unterscheide: 1. Sequential Data (ohne Betonung der

Mehr

Gliederung und Einordnung

Gliederung und Einordnung Gliederung und Einordnung 1. Objektorientierte Programmierung mit Object Pascal (5. Studienbrief, Kapitel 5) 9.4. + 16.4. 2. Software-Bausteine am Beispiel der Delphi-Komponenten (5. Studienbrief, Kapitel

Mehr

Oracle 9i Einführung. Performance Tuning. Kurs. Teil 9 Sortiervorgänge. Universität Hannover. Sortiervorgänge. Migration. Konfiguration.

Oracle 9i Einführung. Performance Tuning. Kurs. Teil 9 Sortiervorgänge. Universität Hannover. Sortiervorgänge. Migration. Konfiguration. Kurs Oracle 9i Einführung Performance Tuning Teil 9 Anhang Timo Meyer Wintersemester 2005 / 2006 Seite 1 von 14 Seite 1 von 14 Agenda 1. Einführung 2. 3. 4. Der Sortiervorgang 5. 6. Statische Informationen

Mehr

DOAG 2010 ORACLE PLATTFORM MIGRATION CROSS PLATFORM TRANSPORTABLE TABLESPACES (XTTS)

DOAG 2010 ORACLE PLATTFORM MIGRATION CROSS PLATFORM TRANSPORTABLE TABLESPACES (XTTS) DOAG 2010 ORACLE PLATTFORM MIGRATION CROSS PLATFORM TRANSPORTABLE TABLESPACES (XTTS) METHODE UND ERFAHRUNGSBERICHT JOSEF LIPPERT FREIBERUFLICHER IT CONSULTANT MÜNCHEN Wer bin ich Freiberuflicher IT Consultant

Mehr

Aufbau einer Oracle Datenbank Tablespace, Arten von Dateien

Aufbau einer Oracle Datenbank Tablespace, Arten von Dateien Aufbau einer Oracle Datenbank Tablespace, Arten von Dateien Boris Meißner 05-INDT Fachbereich Informatik, Mathematik und Naturwissenschaften HTWK-Leipzig 05. Juni 2008 Boris Meißner (Fb IMN - HTWK-Leipzig)

Mehr

SQL-Loader. Prof. Dr. Waldemar Rohde Dipl.-Ing. Jörg Höppner 05.05.2006 1

SQL-Loader. Prof. Dr. Waldemar Rohde Dipl.-Ing. Jörg Höppner 05.05.2006 1 SQL-Loader Prof. Dr. Waldemar Rohde Dipl.-Ing. Jörg Höppner 05.05.2006 1 Beschreibung Definition transferiert Daten aus einer oder mehreren externen Dateien in eine oder mehrere Tabellen einer Oracle-Datenbank.

Mehr

SQL-Anweisungen. SELECT (SQL Data Query Language)

SQL-Anweisungen. SELECT (SQL Data Query Language) SQL-Anweisungen SELECT (SQL Data Query Language) SELECT * SELECT * FROM "meine Tabelle"; SELECT feldname1, feldname2 SELECT feldname1, feldname2 FROM meinetabelle ORDER BY feldname2, feldname1 DESC; WHERE

Mehr

WHERE Klausel Generierung mit.net und Oracle. Aus unserer Projekterfahrung und Architektur-Kurs

WHERE Klausel Generierung mit.net und Oracle. Aus unserer Projekterfahrung und Architektur-Kurs Betrifft Art der Info Quelle WHERE Klausel Generierung mit.net und Oracle Technical Info Aus unserer Projekterfahrung und Architektur-Kurs Where ist the WHERE? Der Artikel untersucht die Möglichkeiten,

Mehr

Microsoft SQL Server 2005 für Administratoren

Microsoft SQL Server 2005 für Administratoren Microsoft SQL Server 2005 für Administratoren Irene Bauder ISBN 3-446-22800-4 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-22800-4 sowie im Buchhandel Sichern von

Mehr

Built in Function. BIF Compatibility. Eine anonymisierte Kundenpräsentation. von Siegfried Fürst SOFTWARE ENGINEERING GmbH

Built in Function. BIF Compatibility. Eine anonymisierte Kundenpräsentation. von Siegfried Fürst SOFTWARE ENGINEERING GmbH GIVE and TAKE Programme Inspiring experiences Built in Function BIF Compatibility Eine anonymisierte Kundenpräsentation von Siegfried Fürst SOFTWARE ENGINEERING GmbH 2015 SOFTWARE ENGINEERING GMBH and

Mehr

SQL-Befehlsliste. Vereinbarung über die Schreibweise

SQL-Befehlsliste. Vereinbarung über die Schreibweise Vereinbarung über die Schreibweise Schlüsselwort [optionale Elemente] Beschreibung Befehlsworte in SQL-Anweisungen werden in Großbuchstaben geschrieben mögliche, aber nicht zwingend erforderliche Teile

Mehr

3. Architektur eines DBS (Oracle)

3. Architektur eines DBS (Oracle) 3. Architektur eines DBS (Oracle) aus Sicht des Datenbank Server Rechners Connectivity Komponente(n) des DBS (z.b. Oracle Listener) Installation ORACLE_HOME Instanz ORACLE_SID Datenbank Oracle: 1 (aktive)

Mehr

Fundamentals of Software Engineering 1

Fundamentals of Software Engineering 1 Folie a: Name Fundamentals of Software Engineering 1 Grundlagen der Programmentwurfstechnik 1 Sommersemester 2012 Dr.-Ing. Stefan Werner Fakultät für Ingenieurwissenschaften Folie 1 Inhaltsverzeichnis

Mehr

DB2 Version 10 Kapitel IT-Sicherheit

DB2 Version 10 Kapitel IT-Sicherheit (*) IBM DB2 for z/os DB2 Version 10 Kapitel IT-Sicherheit (06_DB2V10_itsicherheit.pptx) (*) ist eingetragenes Warenzeichen der IBM International Business Machines Inc. 1 DB2 Version 10 IT Sicherheit DB2

Mehr

27. 03. 2007 IT-Frühstück IT Trend Virtualisierung Hype oder Nutzen? Praxisaspekte

27. 03. 2007 IT-Frühstück IT Trend Virtualisierung Hype oder Nutzen? Praxisaspekte Ole Raether raether@oraservices.de 27. 03. 2007 IT-Frühstück IT Trend Virtualisierung Hype oder Nutzen? Praxisaspekte Inhalt oraservices.de Probleme: Failover Cluster, RAC 24*7 Fazit Was tun? oraservices.de

Mehr

MS SQL Server: Index Management. Stephan Arenswald 10. Juli 2008

MS SQL Server: Index Management. Stephan Arenswald 10. Juli 2008 MS SQL Server: Index Management Stephan Arenswald 10. Juli 2008 Agenda 1. Einführung 2. Grundlagen Tabellen 3. Grundlagen Indexe 4. Indextypen 5. Index-Erstellung 6. Indexe und Constraints 7. Und Weiter...?

Mehr

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann Blatt Nr. 11 Übung zur Vorlesung Einsatz und Realisierung von Datenbanksystemen im SoSe15 Moritz Kaufmann (moritz.kaufmann@tum.de)

Mehr

Tuning von PostGIS mit Read- Only-Daten von OpenStreetMap

Tuning von PostGIS mit Read- Only-Daten von OpenStreetMap Tuning von PostGIS mit Read- Only-Daten von OpenStreetMap Prof. Stefan Keller (Fach-)Hochschule für Technik Rapperswil (bei Zürich) 11.11.2011 PGConf.DE - Stefan Keller 1 Was ist OpenStreetMap? Wikipedia

Mehr

Datenmodellierung und Datenbanksysteme. Vorlesung. Informationswissenschaft und Informationssysteme. Hans Uszkoreit & Brigi1e Jörg

Datenmodellierung und Datenbanksysteme. Vorlesung. Informationswissenschaft und Informationssysteme. Hans Uszkoreit & Brigi1e Jörg Vorlesung Informationswissenschaft und Informationssysteme Hans Uszkoreit & Brigi1e Jörg Definitionen Data modeling in software engineering is the process of creating a data model by applying formal data

Mehr

Hochschule Karlsruhe Technik und Wirtschaft- 10.7.2013. Anhänge: Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Prof. Schmidt.

Hochschule Karlsruhe Technik und Wirtschaft- 10.7.2013. Anhänge: Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Prof. Schmidt. Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Datenbanken und Informationssysteme II Szenario: Projektverwaltung. Es gibt Projekte, Projektleiter, Mitarbeiter und ihre Zuordnung zu Projekten.

Mehr

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. DB Einleitung / Entity-Relationship

Mehr

SQL-DDL und SQL-Anfragen. CREATE TABLE Kategorie (Bezeichnung VARCHAR(15) NOT NULL PRIMARY KEY, Klassifikationskriterium VARCHAR(100) NOT NULL )

SQL-DDL und SQL-Anfragen. CREATE TABLE Kategorie (Bezeichnung VARCHAR(15) NOT NULL PRIMARY KEY, Klassifikationskriterium VARCHAR(100) NOT NULL ) Technische Universität München WS 2003/04, Fakultät für Informatik Datenbanksysteme I Prof. R. Bayer, Ph.D. Lösungsblatt 6 Dipl.-Inform. Michael Bauer Dr. Gabi Höfling 1.12.2003 SQL-DDL und SQL-Anfragen

Mehr

Datenbanken und SQL. Kapitel 1. Übersicht über Datenbanken. Edwin Schicker: Datenbanken und SQL (1)

Datenbanken und SQL. Kapitel 1. Übersicht über Datenbanken. Edwin Schicker: Datenbanken und SQL (1) Datenbanken und SQL Kapitel 1 Übersicht über Datenbanken Übersicht über Datenbanken Vergleich: Datenorganisation versus Datenbank Definition einer Datenbank Bierdepot: Eine Mini-Beispiel-Datenbank Anforderungen

Mehr

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1 Datenbanksystem System Global Area Hintergrundprozesse Dr. Frank Haney 1 Komponenten des Datenbanksystems System Global Area Program Global Area Hintergrundprozesse Dr. Frank Haney 2 System Global Area

Mehr

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

Powerful PL/SQL: Collections indizieren mit VARCHAR2- Indizes ein Praxisbeispiel

Powerful PL/SQL: Collections indizieren mit VARCHAR2- Indizes ein Praxisbeispiel Powerful PL/SQL: Collections indizieren mit VARCHAR2- Indizes ein Praxisbeispiel Schlagworte Autor: Klaus Friemelt, MT AG dynamisches BULK SQL, VARCHAR2-indizierte PL/SQL-Tabellen Einleitung Mit den letzten

Mehr

DB2 for VM / VSE 7.5. News & Experiences. Torsten Röber. GSE Frühjahrstagung April 2008, Bonn. IBM Software Group

DB2 for VM / VSE 7.5. News & Experiences. Torsten Röber. GSE Frühjahrstagung April 2008, Bonn. IBM Software Group DB2 for VM / VSE 7.5 News & Experiences IBM Software Group Torsten Röber GSE Frühjahrstagung April 2008, Bonn Agenda DB2 Server/Client for VSE & VM 7.5 Migrationsprojekte Performance Hints & Tipps Lessons

Mehr

Sructred Query Language

Sructred Query Language Sructred Query Language Michael Dienert 11. November 2010 Inhaltsverzeichnis 1 Ein kurzer Versionsüberblick 1 2 SQL-1 mit einigen Erweiterungen aus SQL-92 2 3 Eine Sprache zur Beschreibung anderer Sprachen

Mehr

Informationsintegration

Informationsintegration Informationsintegration Grundlegende Architekturen Ulf Leser Inhalt diese Vorlesung Klassifikation verteilter, autonomer, heterogener Systeme Weitere Klassifikationskriterien Schichtenaufbau integrierter

Mehr

Transaktionsverwaltung

Transaktionsverwaltung Transaktionsverwaltung VU Datenbanksysteme vom 21.10. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Transaktionsverwaltung

Mehr

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11 Datenbanksysteme WS 05/ 06 Gruppe 12 Martin Tintel Tatjana Triebl Seite 1 von 11 Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 3 2. Datenbanken... 4 2.1. Oracle... 4 2.2. MySQL... 5 2.3 MS

Mehr

Dokumentation QuickHMI-Schnittstelle. Datenbanken

Dokumentation QuickHMI-Schnittstelle. Datenbanken Dokumentation QuickHMI-Schnittstelle für SQLServer Datenbanken Version 1.0 D-28359 Bremen info@indi-systems.de Tel + 49 421-989703-30 Fax + 49 421-989703-39 Inhaltsverzeichnis Was ist die QuickHMI-Schnittstelle

Mehr

Datenadminstrator, Datenbankdesigner, Systemanalytiker (für die logische Sicht zuständig)

Datenadminstrator, Datenbankdesigner, Systemanalytiker (für die logische Sicht zuständig) 1 Grundlagen Begriffe Daten bekannte zutreffende Tatsachen über die Domäne/Miniwelt DBS Einsatz eines DBMS für eine Datenbank, DBS besteht aus folgenden Komponenten: 1. DBMS 2. Datenbank DBMS Software

Mehr

Portierung einer DB2/VM-Datenbank nach DB2 unter zlinux 4 Jahre später - Wie würde ich heute vorgehen?

Portierung einer DB2/VM-Datenbank nach DB2 unter zlinux 4 Jahre später - Wie würde ich heute vorgehen? Portierung einer DB2/VM-Datenbank nach DB2 unter zlinux 4 Jahre später - Wie würde ich heute vorgehen? Tipps aus der Praxis zur Anwendungsentwicklung, Migration und Performanceuntersuchung 1 Einleitung

Mehr

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2 Seminar Cloud Data Management WS09/10 Tabelle1 Tabelle2 1 Einführung DBMS in der Cloud Vergleich verschiedener DBMS Beispiele Microsoft Azure Amazon RDS Amazon EC2 Relational Databases AMIs Was gibt es

Mehr

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen C3: Structured Query Language Lernziele: Nach der Bearbeitung dieser Lektion haben Sie folgende Kenntnisse erworben: Sie können elementaren

Mehr

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Michael Hahne T&I GmbH Workshop MSS-2000 Bochum, 24. März 2000 Folie 1 Worum es geht...

Mehr

Build in Function BIF Compatibility. Udo Puschkarsky DB2-Guide 18.05.2015

Build in Function BIF Compatibility. Udo Puschkarsky DB2-Guide 18.05.2015 Build in Function BIF Compatibility Udo Puschkarsky DB2-Guide 18.05.2015 Ausgangssituation Mit DB2 V10 Compatibility Mode Änderungen bei der STRING Formatierung von Decimal Data bei der CHAR und VARCHAR

Mehr

6 InfoCubes erstellen und konfigurieren

6 InfoCubes erstellen und konfigurieren InfoCubes bilden die Reportingschicht in der LSA; sie sind für die Performance des Reportings entscheidend. In diesem Kapitel stellen wir Ihnen vor, welche InfoCubes es gibt und wie Sie damit arbeiten.

Mehr

Inhalt. Vorwort...11. 1 Die Eigenschaften von PostgreSQL...15. 2 Das ideale DBMS...45. 3 Der Datenbankadministrator...59

Inhalt. Vorwort...11. 1 Die Eigenschaften von PostgreSQL...15. 2 Das ideale DBMS...45. 3 Der Datenbankadministrator...59 Inhalt Vorwort...11 1 Die Eigenschaften von PostgreSQL...15 1.1 Die Geschichte von PostgreSQL...16 1.2 Die Lizenz von PostgreSQL...17 1.3 Grundlegende Konzepte von Postgres...17 1.3.1 Die Eigenschaften

Mehr

15 Bilder und Dateien im SQL Server

15 Bilder und Dateien im SQL Server Leseprobe aus Access und SQL Server http://www.acciu.de/asqllesen 15 Bilder und Dateien im SQL Server Eines der großen Probleme von Access-Datenbanken ist der vergleichsweise geringe Speicher platz. Sicher,

Mehr

Andrea Held. Motivation ILM: Definition und Strategien Lösungen für Oracle Datenbanken. Empfehlungen

Andrea Held. Motivation ILM: Definition und Strategien Lösungen für Oracle Datenbanken. Empfehlungen Andrea Held Motivation ILM: Definition und Strategien Lösungen für Oracle Datenbanken Partitionierung Komprimierung ILM Assistant Flashback Data Archive Empfehlungen 1 Datenwachstum Wachsende Kosten Schlechtere

Mehr

Integritätsbedingungen / Normalformen- Beispiel: Kontoführung

Integritätsbedingungen / Normalformen- Beispiel: Kontoführung Technische Universität München WS 2003/04, Fakultät für Informatik Datenbanksysteme I Prof. R. Bayer, Ph.D. Lösungsblatt 8 Dipl.-Inform. Michael Bauer Dr. Gabi Höfling 12.01. 2004 Integritätsbedingungen

Mehr

Oracle Datenbankadministration Grundlagen

Oracle Datenbankadministration Grundlagen Oracle Datenbankadministration Grundlagen Seminarunterlage Version: 12.02 Version 12.02 vom 14. April 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Oracle 10g Einführung

Oracle 10g Einführung Kurs Oracle 10g Einführung Teil 9 Benutzer und Timo Meyer Administration von Oracle-Datenbanken Timo Meyer Sommersemester 2006 Seite 1 von 11 Seite 1 von 11 Agenda GridAgenda Computing 1 2 3 ta 4 5 Ändern

Mehr

Verschiedene Arten des Datenbankeinsatzes

Verschiedene Arten des Datenbankeinsatzes 1 Beispiele kommerzieller DBMS: Kapitelinhalt Was charakterisiert und unterscheidet verschiedene Einsatzbereiche für. Welche prinzipiell unterschiedlichen Anforderungen ergeben sich für das DBMS bei Ein-

Mehr

Innovator 11 excellence. DDL importieren. Data-Definition-Language-Dateien in Datenbankschema importieren. HowTo. www.mid.de

Innovator 11 excellence. DDL importieren. Data-Definition-Language-Dateien in Datenbankschema importieren. HowTo. www.mid.de Innovator 11 excellence DDL importieren Data-Definition-Language-Dateien in Datenbankschema importieren HowTo www.mid.de Zweck In Innovator Data excellence können Sie mit dem DDL-Import Ihr physisches

Mehr

DB2 for z/os. Musterlösungen zu den Übungen

DB2 for z/os. Musterlösungen zu den Übungen Musterlösungen zu den Übungen 4. Januar 2013 Eine Ausarbeitung von: cps4it Ralf Seidler Stromberger Straße 36A 55411 Bingen Fon: +49-6721-992611 Fax: +49-6721-992613 Mail: ralf.seidler@cps4it.de Internet

Mehr

Physische Datenbankdefinition in. Arthur Bauer

Physische Datenbankdefinition in. Arthur Bauer Physische Datenbankdefinition in Arthur Bauer Inhalt Cluster Index-Cluster Hash-Cluster Vor- und Nachteile Index-Organisierte Tabelle (IOT) Partitionierung STORAGE-Klausel in DDL Indexstrukturen Oracle

Mehr

Datenbanken und Oracle, Teil 2

Datenbanken und Oracle, Teil 2 Datenbanken und Oracle, Teil 2 Mathias Weyland Linux User Group Switzerland 29. Juni 2007 SQL*Plus CHAR/VARCHAR2 Dokumentation Teil I Nachträge 1 SQL*Plus 2 CHAR/VARCHAR2 3 Dokumentation SQL*Plus SQL*Plus

Mehr

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen WEITER BLICKEN. MEHR ERKENNEN. BESSER ENTSCHEIDEN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN VERSION 1.0 OPTIMIERUNG VON ABFRAGEN IN MS SQL

Mehr

tcvision Freigabemitteilung Version 6

tcvision Freigabemitteilung Version 6 tcvision Freigabemitteilung Version 6 Stand: 5. Mai 2015 TCP/IP TCP/IP Verbindungen werden dynamisch auf- und abgebaut, um Stabilitätsproblemen in der Infrastruktur zu begegnen. Mit Hilfe des tcscript

Mehr

Numerische Datentypen. Simon Weidmann

Numerische Datentypen. Simon Weidmann Numerische Datentypen Simon Weidmann 08.05.2014 1 Ganzzahlige Typen 1.1 Generelles Bei Datentypen muss man immer zwei elementare Eigenschaften unterscheiden: Zuerst gibt es den Wertebereich, zweitens die

Mehr