IBM DB2 for z/os. DB2 Version 9 - Übersicht. (DB2_V9_DBAnews.ppt) Oktober, (*)

Transkript

1 (*) IBM DB2 for z/os DB2 Version 9 - Übersicht (DB2_V9_DBAnews.ppt) (*) ist eingetragenes Warenzeichen der IBM International Business Machines Inc. 1

2 DB2 V9 neue DBA Funktionalität Universal Tablespace (UTS) Clone-tables XML-Tables ( eig. Kapitel ) Änderungen und Verbesserungen an Utilities autonomic computing security ROLE & trusted context Verbesserte DDL Konsistenz Performance Optimization Service Center (OSC) Data Studio 2

3 DB2 V9 Universal Tablespace Simple table spaces können nicht mehr erzeugt werden Der default table space ist nun der segmented TS UTS ist eine Hybride zwischen partitioned und segmented Tablespace Inkompatibel mit MEMBER CLUSTER Verbessertes space management Unterstützung von Massen-Deletes / TRUNCATE Immer noch EINE Tabelle pro Tablespace Kann Range Based partitioning (as before: PBR) oder Partitioned By Growth (PBG) unterstützen DROP / CREATE ist erforderlich, um bestehende page sets auf UTS zu migrieren Typ-1: Partitioned-by-growth immer UTS (PBG) CREATE TABLESPACE MAXPARTITIONS integer CREATE TABLE PARTITIONED BY SIZE EVERY integer G Bei einem Single Table Tablespace und Universal Tablespace (UTS) möglich (max. 128 TB) default segsize = 4, max. Grösse für die einzelne Partition = 4GB und die max. Anzahl Partitions = 256 ; dies begrenzt die default size einer Tabelle auf 1 TB Typ-2: Partitioned-by-range (PBR) Mass Delete oder Truncate Table, z.b. Lösung für das Rotate Partition Problem CREATE TABLESPACE SEGSIZE integer NUMPARTS integer 3

4 DB2 V9 Universal Tablespace 4

5 DB2 V9 Universal Tablespace (Beispiele) CREATE LARGE TABLESPACE suts001 IN dbuts001 NUMPARTS 2 SEGSIZE 16 CREATE TABLE tuts001 PARTITON BY RANGE ( PNR ASC) ( PARTITION 1 ENDING ( 20 ), PARTITION 2 ENDING ( 40 ) ) PBR CREATE LARGE TABLESPACE suts001 IN dbuts001 MAXPARTITIONS 2 SEGSIZE 16 CREATE TABLE tuts001 PBG Restriktionen für universal tablespace nur EINE einzige Tabelle - Drop ist nicht erlaubt! es gibt keinen migration path - Drop und recreate erforderlich KEIN Member Cluster Reduzieren der #parts ist nicht möglich speziell: Maxpartitions 5

6 DB2 V9 CLONE TABLE Annähernd alle Utilities sind online nutzbar, nicht aber Load Replace. Alias oder View hilft, um zwischen zwei identischen Tabelle hin-und her zu schalten. Auswirkungen hat ein DROP und recreate des ALIAS bzw. des VIEW Entspricht einem ONLINE LOAD REPLACE Kopie der bestehenden TABLE Alle INDEXES werden geclont TABLE und INDEX Daten werden nicht bewegt Die Datasets werden getauscht (wie im Fastswitch) Nur für Single Table Tablespace (muss ein UTS sein) Keine RI, AFTER TRIGGER und MQTs Utilities (ausser RUNSTATS) können gegen den CLONE laufen 6

7 DB2 V9 CLONE TABLE DDL: Alter Table bbb Add Clone ccc Generiert einen neuen Eintrag in SYSTABLES mit Typ C Die Spaltennamen bleiben identisch Add Column ist nicht mehr möglich (Alter statement) Indexes, LOBs, XMLs sind identisch CREATE eines neuen Index ist erlaubt Es existieren dieselben check constraints ADD / DROP constraint ist nicht mehr möglich (Alter statement) Identische Before triggers CREATE neuer Before Trigger ist erlaubt KEIN cloning für Views : kann über bbb and ccc definiert werden Identity: gleiche Definition für Base und Clone Authorization: Kann unterschiedlich für bbb and ccc sein Nur Ein Eintrag in der Tabelle SYSTABLESPACE hlq.dsndbc.database.tsp.i0002.a001 Neue Spalte Instance : Inhalt 1oder 2 NEUE DDL EXCHANGE: Schaltet zwischen Base und Clone Table um ist in der SYSCOPY registriert: Ictype=A(lter) und Stype=E(xchange) Recover vor den letzten Exchange ist nicht möglich Alter Table bbb Drop Clone: Drop Table ccc ist nnicht erlaubt Alter Tablespace / Index / Table: ist nicht mehr erlaubt 7

8 DB2 V9 CLONE TABLE Utilities / Commands TABLE ist syntaktisch erlaubt: entweder Base oder Clone ; z.b. LOAD REPLACE INTO ccc TABLE ist syntaktisch NICHT erlaubt: neues Schlüsselwort CLONE bei RECOVER database.tsp CLONE bzw. START/STOP command... CLONE RUNSTATS und Modify Statistics ist eine Ausnahme: Annahme: Statistiken sind gleich für Base und Clone Utility ist nicht möglich auf der Clone table (DSNU1457I) Base und Clone können niemals gemeinsam in EINEM control statement angegeben werden Restriktionen: Sqlcode -148 Base table muss sich in einem Universal Tablespace befinden Pagesets müssen DB2 managed sein die Base table kann keine Catalog Table, MQT oder in ein RI-Konstrukt involvierte Tabelle sein 8

9 DB2 V9 DB2 Utility Verbesserungen CPU Reduzierung in LOAD und REORG Parallel REORG bei Partitioned Tablespaces UNLOAD und LOAD der einzelnen Partitions war vorher seriell Laufzeit und CPU Verbesserungen LOB File Reference Unterstützung - UNLOAD und LOAD TEMPLATE Switching z.b. Schreiben von Image Copy auf TAPE oder DASD je nach Grösse ONLINE CHECK DATA - shadow ONLINE CHECK LOB - shadow ONLINE REBUILD INDEX in place ONLINE REORG ohne BUILD2 Phase - shadow REORG SHRLEVEL REFERENCE für LOB Tablespaces 9

10 DB2 V9 DB2 Utility Verbesserungen RECOVER RESTOREBEFORE ermöglicht es, eine RBA / LRSN anzugeben, die Db2 veranlasst, kein Image Copy aus SYSCOPY zu verwenden, das eine höhere START_RBA aufweist, als den angegebenen Wert. Das REOVEr Utility wird also einen älteren full image copy als Recoverybasis für ein Objekt verwenden und alle folgenden incremental image copies VOR der angegebenen RBA dazu mischen. Dann werden die Log-Sätze angefügt, um das Objekt auf den aktuellsten Zeitpunkt, oder auch irgendeinen beabsichtigten point in time zurückzusetzen. 10

11 DB2 V9 Index - Performance Neue Index Grössen Bufferpool 8K, 16K, 32K Compression für 8K und 16K möglich Online ALTER für Bufferpool und Compression Autonomic Index Page Split Index split passiert wenn 50% der Index Page voll sind Problem bei sequentiellen INSERTs Neuer Algorithmus für sequential und random INSERTs - 4K gut für random INSERTs - > 4K gut für sequentielle INSERTs 11

12 DB2 V9 Dynamic Index ANDing für Star Joins... AND ( DP.C5 = 0 ) AND ( DP.C3 <= ) AND ( D2.C1 = 135 ) AND ( S1.C7 BETWEEN 'H' AND 'N' ) AND ( DT.C9 BETWEEN 50 AND 60 ) Typischerweise existieren viele Indizes, bestehend aus einer einzelnen Spalte, die möglichst jede Kombination von Filterprädikaten unterstützen sollen. Das Filtering kommt von mehreren dimensions Wenig abhängig von perfekten Statistiken!! 12

13 DB2 V9 Dynamic Index ANDing Filtering dimensions accessed in parallel Join each dimension table with fact table through index independently Build RID lists As filtering efficiency might not be known until runtime, the runtime optimizer may terminate parallel stream(s) that happen to provide poor filtering. Perform RID sort and RID merge (ANDing) of the RID lists Final RID list used to retrieve data from fact table and join back to dimensions 13

14 DB2 V9 LOB - Performance SHRLEVEL REFERENCE REORG LOB Freier Platz kann wieder gebraucht werden Eliminierung von LOB locks Neue Technik um LOBs zu lesen FETCH WITH CONTINUE FETCH CURRENT CONTINUE Für BLOBs, CLOBs, DBCLOBs und XML Network Flow Optimierung durch Progressive Locator Online Check LOB UNLOAD/LOAD LOBs > 32K 14

15 DB2 V9 LOB - Performance Redesign des LOB Locking Algorithmus V8: - S-LOB Lock temporär für space search während der LOB Allokation - bei LOB Deallokation bis zum COMMIT - bei LOB read bis zum COMMIT sogar bei UR Readers! - X-LOB Lock für LOB Allokation bis zum COMMIT V9: - No LOB Locks * für space search während der LOB Deallokation * für non-ur Readers (abhängig vom base row locking ) - S-LOB Lock * bei UR Readers, um festzustellen, ob das LOB vollständig ist (kurz) - X-LOB Lock temporär bei LOB Allokation - Freigabe unmittelbar nachdem die Allokation vollständig ist - Lock escalation kann nicht mehr erfolgen - Neues locking protocol-3 in NFM erforderlich 15

16 DB2 V9 RLF Verbesserungen DB2 ermöglicht die Beschränkung von Ressourcen für dynamic SQL über neue Kriterien Middleware Server diese Informationen nutzen CLI/JDBC Client Informationen können über API Einstellungen prüfen: Userid, Workstation und Applikationsname. Neue RLF Spalten RLFEUID User-id RLFEUAN Applisationsname RLFEUWN Workstation Name RLFIP Requesters IP Addresse RLFFUNC kontrolliert den reactive bzw. Den predictive Governor Beispiele von Query-Limits 16

17 DB2 V9 REOPT Verbesserungen V8 V9 REOPT BIND/REBIND parameter Dynamic SQL: NONE, ONCE und ALWAYS Static SQL: NONE, ALWAYS REOPT Verbesserungen Automatische Reoptimierung, wenn sich die Filter der Prädikate dramatisch ändern für cached dynamic SQL mit Parameter Markers Reoptimiierung am Anfang und Überwachung der runtime Werte für Parameter Markers Neuer REOPT Parameter: AUTO zparm: REOPTEXT=YES (default = NO) 17

18 DB2 V9 Query PLAN Stability Functional Overview Was steht im Katalog? SYSPACKAGE reflektiert das current copy SYSPACKDEP reflektiert dependencies of all copies der Rest des Katalogs (SYSPKSYSTEM...) reflektiert die Metadaten aller Kopien SPT01 erfordert ein Mehrfaches an Speicher es gibt ein APAR zum Komprimieren der SPT01 Invalidierung und Auto Bind sind erforderlich jede Kopie wird für sich auf INVALID gesetzt Keine Unterstützung für Trigger und stored procedure Packages bis jetzt SPÄTER Keine Unterstützung für DBRMs die direkt in einem PLAN gebunden sind Query Plan Stability PLANMGMT = BASIC Enthält bis zu 2 Kopien eines Package Current und current -1 ( previous ) Bei jedem REBIND Wird die previous copy verworfen die Current copy wird zur previous copy Das neue BIND-Ergebnis wird zum current copy Kann dazu führen, dass Packages von alten Releases endgültig gelöscht werden REBIND... SWITCH (PREVIOUS) schaltet zwischen current und previous copy hin und her bietet eine Möglichkeit, um ein fallback auf die letzte Kopie durchzuführen 18

19 DB2 V9 Query PLAN Stability Query Plan Stability PLANMGMT=EXTENDED enthält bis zu 3 Kopien eines Package Current, Previous und Original Bei jedem REBIND Wird die previous copy verworfen Gibt es keine Originalkopie, so wird die current copy zur Originalkopie die Current copy wird zur previous copy Das neue BIND-Ergebnis wird zum current copy Die Original Copy ist die Kopie, die von Anfang an existiert einmal gespeichert, niemals überschrieben kann auch ein V7/V8 Package sein REBIND... SWITCH (PREVIOUS) schaltet zwischen current und previous copy hin und her REBIND... SWITCH (ORIGINAL) Current copy wird zur previous und original copy wird zur current KOPIE bietet eine Möglichkeit, um ein fallback auf die älteste Kopie durchzuführen 19

20 DB2 V9 INSERT Performance CREATE TABLE... APPEND YES INSERT am Ende der Tabelle DB2 ignoriert die clustering Sequenz - Bei SQL INSERT und ONLINE LOAD Table kann schnell wachsen - FREESPACE und PCTFREE werden nicht beachtet Wenn die clustering sequenz nicht benötigt wird - Clustering kann über REORG wieder erreicht werden Für kritischen Workload mit hohen INSERT Raten DB2 V9 VARCHAR - Performance Reordered Row Format (RRF) vs Basic Row Format (BRF) zur direkten Adressierung (REORG) CREATE TABLE tbl ( c1 integer NOT NULL, c2 Varchar(120) NOT NULL, c3 char ( 10 ) NOT NULL, c4 varchar (60 ) C1 C2 C3 C A 0006 WILSON ANDREW 0008 SAN JOSE Basic row Format 2 byte Längenfeld C1 C3 O2 O4 C2 C A ANDREW WILSON SAN JOSE reordered row Format Offset auf C2 und C4 20

21 DB2 V9 Sicherheit Roles Network Trusted Contexts Verbessertes auditing Data Encryption Secure Socket Layer(C/S) 21

22 DB2 V9 Database ROLEs ROLE ist eine virtuelle authid Zugeordnet via TRUSTED CONTEXT Ermöglicht zusätzliche Rechte in einem trusted environment Benutzung mit der bestehenden primary AUTHID CREATE ROLE PROD_DBA; GRANT DBADM TO PROD_DBA; CREATE TRUSTED CONTEXT DBA1 DEFAULT ROLE PROD_DBA OWNER(ROLE); 22

23 DB2 V9 DDL Erweiterungen RENAME <column> ALTER TABLE tb1 RENAME COLUMN old_column_name TO new_column_name Überlegungen: Plan/Package Invalidation Restriktionen: Catalog Table Spalten, die in einem View, in einem Index on expression, in einem check constraint liegen Field procedure auf der Spalte; valid/edit procedure auf der Tabelle Tabelle mit trigger definition MQT RENAME <index> ALTER TABLE tb1 RENAME INDEX old_index_name TO new_index_name Der Qualifier wird vom ursprünglichen Index abgeleitet, die OBID bliebt erhalten Überlegungen: Plan/Package/DSC Invalidation und die Plan Table Inhalte passen nicht mehr Restriktionen: Keine Catalog Indexes Keine DGTT Indexes keine Index on expression 23

24 DB2 V9 DDL Erweiterungen Defaults und weitere Datentyp-Änderungen ALTER TABLE tb1 ALTER c1 SET / DROP DEFAULT NULL, USER, Constant, SESSION_USER... Neuer default: SESSION_USER ALTER TABLE tb1 ALTER c1 SET DATATYPE LONG VARCHAR to VARCHAR Neuer Spezialregister Wert, wenn SQL Daten ändert oder LOAD erfolgt Ändern eines Schema über CATMAINT UPDATE SCHEMA SWITCH(old_schema_name, new_schema_name) Ändert Creator, Owner und das Schema der Datenbankobjekte, Pläne und Packages Restriktion: Views, MQT, SQL Funktionen, Triggers, check constraints OWNER FROM (owner_name) TO ROLE Ändert die ownership von Objekten von einem User aufe eine ROLE 24

25 DB2 V9 Autonomic Computing Bufferpool Management durch WLM Recovery einzelner Objekte von Plattensicherungen Änderung des Early Code ohne IPL BACKUP / RESTORE von Band RECOVER auf Konsistenz Punkt MODIFY RECOVERY Automatische Definition von Datenbank und Tablespace Automatischer Index Page Split Schnellerer und automatisierter DB2 Restart Automatische Suche des passenden Checkpoint 25

26 DB2 V9 Performance CM ohne Zusatzaufwand: Utility CPU Reduktion Logging Verbesserungen Verbesserten index page split Grössere prefetch, write & preformat Einheiten LOB Performance DDF VSCR Optimization Service Center, Opt. Expert, & Data Studio Geänderter online REORG Verbesserter RUNSTATS Optimization Verbesserungen, EDMPOOL VSCR Mehr parallele Nutzung der ziip NFM LOB lock Vermeidung Reordered row format Index: grössere Pages, Kompression und index on expression I/O wait time tuning Buffer pool Tuning Kompression (Daten und Index) Synchroner read prefetch Tuning der I/O Konfiguration o Sicherstellen von genug I/O Ressourcen o Schnellere Geräte, wie z.b. DS8000 wo erforderlich o Parallel Access Volume (PAV) gegen I/O contentions mit hoher IOSQ Zeit in RMF o I/O striping 26

27 DB2 V9 Performance Database Design Tuning Index Änderungen: eine ganze Reihe neuer Optionen o Nutzungsmöglichkeiten des Index CLUSTER, PARTITIONed usw. o Clustering o Kompression o Index on expression, XML, Universal Tablespace Indexverbesserungen Variable Länge vn index keys Index-only Zugriff für VARCHAR Daten Maximum index key 2000 Bytes Predikate mit nicht gleichen Typen sind indexable (CHAR(8) = CHAR(4), INT = DEC ) Unterstützung von Datentypen, die nicht in Programmiersprachen wie JAVA, C++, C# unterstützt werden Backward Index Scan Partitioning separat vom clustering Data-partitioned secondary indexes (DPSI) Create index online während eines SELECT / INSERT Hinzufügen von Spalten zu einem Index Definieren von RANDOM index keys zum Vermeiden von hot spots mit mehreren Prozessen, die sequential keys einfügen 27

28 DB2 V9 Performance Unterschiede zwischen Daten- und Indexkomprimierung Die Index compression : DSN1COMP 28

29 DB2 V9 Performance / Utilities Messungen Utilities: CPU Verbesserungen 10 bis 20% für Image COPY, RECOVER INDEX 5 bis 30% für LOAD, REORG, REBUILD INDEX 20 bis 60% für CHECK INDEX (SHRLEVEL REFERENCE) : DSNU395I DSNUKPIK - INDEXES WILL BE BUILT IN PARALLEL, NUMBER OF TASKS = 3 30% für LOAD PARTITION 30 bis 40% für RUNSTATS INDEX 40 bis 50% für REORG INDEX Bis zu70% für LOAD REPLACE PARTITION mit dummy input 29

30 DB2 V9 Performance / Optimizung Verbesserungen Page range screening Verbesserungen in DB2 V9 DB2 V9 führt Verbesserungen im page range screening ein, wodurch weniger Partitionen gelesen werden müssen: Für Join predicates Ein Weg, die query performance für Tabellen mit data-partitioned secondary indexes (DPSI s) zu verfbessern, ist es, ein JOIN Prädikat für das page range screening einzusetzen. Beispiel: Tabelle T1 und T2 sind über das Feld TRANS_MONTH partitioniert. Der Zugriffspfad ist ein nested join loop von T1 auf T2 und der Zugriff auf T2 erfolgt über den DPSI Index auf T2.CUSTNUM: SELECT * FROM T1, T2 WHERE T1.TRANS_MONTH = T2.TRANS_MONTH AND T1.CUSTNUM = T2.CUSTNUM Da die Tabellen über die partitioning column gejoined werden, muss nur eine einzige Partition des DPSI Index auf T2 für jede row aus T1 zugegriffen werden. Das Eliminieren von Partitions verbessert die Performance enorm. Für Non-matching predicates non-matching predicates können nun auch zum page screening genutzt werden. Diese Prädikate auf dem partitioning key sind keine matching columns, da sie nicht die ersten Spalten des partitioning key sind. Beispiel: Tabelle T1 ist partitioned über REGION, STATE, MONTH. Die Anzahl Partitions ist gleich der Anzahl Regionen (4) multipliziert mit der Anzahl Staaten (50) multipliziert mit der Anzahl Monate(12) = 2,400 Partitions. Der Zugriff auf T1 erfolgt über den DPSI auf T1.STOR_ID.: SELECT SUM(GROSS_SALES) FROM T1 WHERE T1.MONTH =? AND T1.STOR_ID =? Da nur EIN Monat interessant ist und die page screening Funktion das Prädikat auf T1.MONTH nutzt, reduziert die so formulierte Query Anzahl der zugegriffenen Partitions auf 1/12tel von bzw

31 DB2 V9 Performance / Optimizung Verbesserungen Problemstellungen: Correlated and non-correlated subqueries Nested subqueries Bedingungen unter denen DB2 eine Subquery in einen Join transformiert: Die Transformation führt nicht zu Redundanz Die Subquery steht in einer WHERE Klausel Die Subquery enthält weder GROUP BY, HAVING bzw. aggregate functions. Die Subquery hat nur eine einzige Tabelle in der FROM Klausel Bei einer correlated subquery darf der Vergleichsoperator des Prädikats, das die Subquery enthält nur IN, = ANY, oder = SOME sein Bei einer noncorrelated subquery, darf der Vergleichsoperator des Prädikats, das die Subquery enthält nur IN, EXISTS, = ANY, oder = SOME sein Bei einer noncorrelated subquery, hat die Subquery select list nur eine einzige Spalte, für die über einen unique index, eindeutige Werte garntiert werden. Bei einer noncorrelated subquery ist die linke Seite des Prädikats eine einzelne Spalte mit demselben Datentyp und derselben Länge, wie die Spalte in der Subquery (bei einer correlated subquery kann die linke Seite einen beliebigen Ausdruck darstellen) Query parallelism is not enabled. USW. USW. Für UPDATE, INSERT und DELETE gelten zusätzliche Bedingungen zur Transformation 31

32 DB2 V9 Performance / Optimizung Verbesserungen Global Query Optimization Verbesserungen in DB2 V9: Subqueries die DB2 nicht auf JOINs transformieren kann Treffen die o.g. Bedingungen für eine Transformation nicht zu, so wird der DB2 Optimizer stattdessen die Subquery aus Gründen der Effizienz korrelieren oder de-korrelieren. Virtual tables Aus Optimierungsgründen behandelt DB2 eine Subquery, die nicht in einen JOIN transformiert werden kann als virtual table. Dies ist ähnlich der Verarbeitung von materialized views und table expressions. Jedoch im Gegensatz zu materialized views werden hier keinerlei work files aufgebaut. Die Nutzung von virtual tables zielt auf nested subqueries und non-nested subqueries. Early Out Verarbeitung Dies ist eine Technik, bei der duplicate rows nicht zurückgegeben werden, wenn sie nicht relevant sind und andererseits die Sortierkosten erhöhen würden. Correlating und de-correlating Subqueries Diese beiden Techniken haben unterschiedliche Vorteile in der Verarbeitung. Wo möglich transformiert der DB2 Optimizer die Query auf ihren höchst effizienten Typus. Der DB2 Optimizer kann eine correlated subquery auf eine non-correlated transformieren ( de-correlate ). Genauso kann der DB2 Optimizer eine noncorrelated subquery in eine correlated subquery transformieren ( correlate ). Bei gleichwertig geschätztem Ergebnis, wird der Optimizer auf der Basis der geschätzten Kosten handeln. Correlated subqueries erlauben mehr Filterung innerhalb der Subquery, Non-correlated subqueries erlauben mehr Filterung auf der Tabelle, deren Spalten mit dem Resultat der Subwuery verglichen werden. 32

33 DB2 V9 Performance / Optimizung Verbesserungen Global Query Optimization Correlating und de-correlating Subqueries Beispiel 1 In der non-correlated subquery wird die Tabelle BIG_TABLE materialisiert ; d.h. sie wird gescanned und in eine work file geschrieben. Die Tabelle SMALL_TABLE wird gegen die work file gejoined. Dies geschieht so in DB2 V8: SELECT * FROM SMALL_TABLE A WHERE A.C1 IN (SELECT B.C1 FROM BIG_TABLE B) In V9, kann DB2 die non-correlated subquery in eine correlated subquery transformieren. Mit dieser Umformulierung wird DB2 zuerst die Tabelle SMALL_TABLE und die Tabelle BIG_TABLE über den Index zugreifen, wodurch die work file vermieden wird. SELECT * WHERE FROM SMALL_TABLE A EXISTS (SELECT 1 FROM BIG_TABLE B WHERE B.C1 = A.C1) 33

34 DB2 V9 Performance / Optimizung Verbesserungen Global Query Optimization Correlating und de-correlating Subqueries Beispiel 2 In der folgenden correlated subquery wird die outer table BIG_TABLE durchsucht, um den Wert der Spalte A.C1 zu erhalten.und ein matching index führt zur Tabelle SMALL_TABLE. So geht das in V8. SELECT * FROM BIG_TABLE A WHERE EXISTS (SELECT 1 FROM SMALL_TABLE B WHERE A.C1 = B.C1) In V9, kann DB2 die correlated subquery in eine non-correlated subquery transformieren!. Mit dieser Umwandlung durchsucht DB2 die SMALL_TABLE und stellt diese in eine work file (klein!) und dies erlaubt einen effizienten matching index Zugriff auf der Tabelle BIG_TABLE. Einige Queries können nicht transformiert werden. Die meisten set functions und grouping functions machen es schwer, eine Subquery aus einer Form in die andere zu Form umzuschreiben. Ausdrücke, die dies verhindern können umfassen u.a.: Set functions und grouping functions Beispiel: In der folgenden Query, kann die non-correlated subquery nicht auf T1 korreliert werden, da damit das Resultat der Funktion SUM verändert würde. SELECT * FROM T1 WHERE T1.C2 IN (SELECT WHERE GROUP BY SUM(T2.C2) FROM T2, T3 T2.C1 = T3.C1 T2.C1) 34

35 DB2 V9 Performance / Optimizung Verbesserungen Global Query Optimization Correlated ranges und <> Vergleiche Einige range Vergleiche, die correlated columns umfassen, machen es schwer die Subquery zu de-korrelieren. Dies deshalb, weil, wenn die correlated subquery dekorreliert werden soll, dann müssen Duplikate entfernt werden, um die virtual table in der outer Position effizient nutzen zu können(siehe Early Out processing ). Dieses Entfernen der duplicates erfordert eine Reihe von equal-join Prädikaten und entsprechenden Spalten als key. Ohne die equal-join predicates bricht der early out Prozess zusammen und wird nicht funktionieren. Das wiederum bedeutet, dass die virtual table lediglich in ihrer correlated form (als inner table des Join) dargestellt werden kann. Beispiel: DB2 kann folgende Query nicht de-correlieren und nutzt sie um auf T1 zuzugreifen, da das Entfernen der Duplikate auf der Subquery T2.C2 nicht sicherstellt, dass das range predicate mit seiner Korrelation keine rows mehrfach auf T1 qualifiziert. SELECT * FROM T1 WHERE EXISTS (SELECT 1 FROM T2, T3 WHERE T2.C1 = T3.C1 AND T2.C2 > T1.C2 AND T2.C2 < T1.C3) 35

36 DB2 V9 Performance / Optimizung Verbesserungen Global Query Optimization Der Output beim EXPLAIN in der PLAN_TABLE wurde modifiziert, um virtual tables, die materialisieren, anzeigen zu können. Der Tabellenname einer virtual table folgt Namenskonventionen, ähnlich denen, die für mini-query blocks (MQBs) verwendet werden. Der Name enthält6 einen Indikator für die Queryblock-Nummer der zugehörigen Subquery; z.b. DSNFWQB(02). Der Tabellentyp für materialisierte virtual tables ist W für work file. Virtual tables, die nicht materialisieren sind im EXPLAIN Output nicht angezeigt. Eine neue Spalte wurde der PLAN_TABLE hinzugefügt: "PARENT_PLANNO". Bei correlated subqueries korrespondiert diese Nummer mit der Plan-Nummer im übergeordneten Queryblock, in dem die correlated Subquery aufgerufen wird. Bei non-correlated subqueries korrespondiert die Nummer mit der Plannummer im übergeordneten Queryblock der die work file für die Subquery repräsentiert. 36

37 DB2 V9 Performance / Memory Verbesserungen Star Join und sparse indexing Die Eigenschaften von star schema sparse indexes sind: Der In-memory index belegt bis zu 240 KB Untersucht über ein equal-join Prädikat Binary search für den Zielbereich der Tabelle Sequential search innerhalb des Zielbereichs, falls dieser als sparse qualifiziert wurde Die Eigenschaften von in-memory data caching (auch in-memory work file sind: Memory pool Grösse wird kontrolliert über den DSNZPARM SJMXPOOL eine bestimmte work file befindet sich in-memory (und ist deshalb nicht sparse ) durchsucht über binary search (wie beim sparse index ) 37

38 DB2 V9 Performance / Memory Verbesserungen Neuer DSNZPARM Parameter MXDTCACH zur Angabe des Maximums an Memory, das beim Daten-Caching zugewiesen werden darf. Der default ist 20MB Dynamic index ANDing bei star join Queries Aktuell unterstützt DB2 z/os folgende Methode um einen Star Join zu unterstützen: Cartesian Join auf die Dimension Tables VOR dem Join auf die Fact Table Multi-column Index Zugriff auf die Fact Table mit Index feedback Achtung: Der Installationsparameter SJMXPOOL wurde mit MXDTCACH ersetzt. Zusätzlich dazu wurde der data caching space für star joins in den lokalen Pool above the 2 GB bar verlegt. Die Probleme dabei sind: Der Cartesian Join kann als Messgrad der Performance-Verluste gelten, da keinerlei Filterung in der dimension table stattfinden kann. der User muss einen multi-column Index auf die Fact table legen um so über die Indexspalten die JOINs von den unterschiedlichen dimension tables zu unterstützen. Dabei ist es schwer, so einen multi-column index zu entwerfen, ohne die Join-Folgen der dimension tables zu kennen. Die Verbesserung führt einen neuen Typ eines JOIN innerhalb einer star join -Gruppe ein: Pair-Wise Join. 38

39 DB2 V9 Performance / Memory Verbesserungen Large Object (LOB/XML) flow optimization IBM DB2 Driver for JDBC and SQLJ ( progressive streaming ) Java Applikationen fordern explizit, was auf einem von zwei möglichen wegen geliefert werden soll: Voll materialized data (fullymaterializedlobdata = true) alle Daten werden zur selben Zeit geliefert. ist das Beste für not-so-huge large objects. Locators (fullymaterializedlobdata = false) nur ein Locator wird zurückgegeben. es gibt einen eigenen Datenfluss für (partial) data. ist das Beste für huge large objects. Der IBM DB2 Driver for JDBC and SQLJ inkludiert alle LOB support in JDBC 3.0 und früheren Spezifikationen. Dieser Treiber unterstützt LOBs in weiteren Methoden und weiteren Datentypen. Unterstützt der database server progressive streaming, dann kann auch der IBM DB2 Driver for JDBC und SQLJ progressive streaming anwenden, um Daten aus LOB oder XML Spalten zu holen. LOB Performance Verbesserungen (LOB Locking) 39

40 DB2 V9 Performance / WLM assisted BP Management Ein neuer Mechanismus wurde eingeführt, um einen BP mit Users in Verbindung zu bringen. Bufferpool Users sind CICS oder IMS Transaktionen, die über einen performance block (PB) dargestellt und DDF enclaves, darstellbar über eine enclave. Es wurde ein neuer Mechanismus eingeführt, der die laufenden states des Users verfolgen und melden soll. Diese neuen delays werden an den zugehörigen performance block der Datenanforderung weitergegeben. WLM bemerkt, twenn User auf daten im Bufferpool warten müssen. 40

41 DB2 V9 Performance / WLM assisted BP Management Schritte 1 und 2 Voraussetzung für buffer pool management mit WLM ist, dass der BP in WLM registriert ist und der Aufbau eines performance block für den database manager erfolgt. Die Bufferpool vector table sammelt ab dann alle buffer pool management blocks. Die buffer pool registration informiert über Datenansammlungen, über bestehende Anpassungen, als auch über Grössenlimitierungen. Die Anwendung beginnt den BP zu nutzen. In diesem Moment wird der BP performance block mit dem Enklave performance block in Verbindung gebracht. Ab sofort werden die Statusänderungen im enclave performance block aufgezeichnet. WLM sammelt diese performance block states. Schritte 3, 4 und 5 Der database manager legt den performance block an, der ausschließlich dazu dient, buffer pool delays aufzuzeichnen. Der performance block ist gekoppelt an die anfordernde Enklace und der buffer pool performance block ist verknüpft mit dem spezifischen enclave performance block. Schritte 6 und 7 Der database manager meldet alle buffer pool delays im buffer pool performance block. Verzögerungen (Delays) entstehen dann, wenn die angeforderten Daten nicht im BP verfügbar sind und damit vom buffer pool manager über I/O Operationen besorgt werden müssen. Die delays werden in der Performanceberechnung der Enklave Klasse berücksichtigt. Dies wiedferum beeinflußt auf direktem Weg die service class period PI der jeweiligen Enklave. Wenn erforderlich ruft WLM den adjustment exit, um die BP Grösse sofort zu ändern. Schritt 8 Wenn die Anforderung der Enklave erledigt ist, so wird der zugehörige buffer pool performance block wieder freigegeben. Er steht nun für das Reporting von states einer anderen Enklave wieder zur Verfügung. WLM entscheidet nach der Sammlung der delay Werte, ob eine Änderunge der BP Grösse erforderlich ist. Periodisch erfolgt nun automatisch eine Untersuchung der aktuellen BP Größe. 41

42 DB2 V9 Performance Skalierbarkeit Insert, Update und Delete Performance ist und bleibt eine der herausfordernsten Aufgaben in einem database management system. DB2 9 for z/os bietet eine unglaubliche performance/scalability Verbesserung in diesem Umfeld.. 42

43 DB2 V9 Optimization Center 43