Db2 Engine Enhancements in Continuous Delivery

Transkript

1 Db2 Engine Enhancements in Continuous Delivery Oliver Draese, STSM Db2 for z/os Development IBM Silicon Valley Lab

2 Disclaimer Disclaimer IBM s statements regarding its plans, directions and intent are subject to change or withdrawal without notice at IBM s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products many not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our product remains at our sole discretion. 2

3 Agenda Neue Statistiken für REAL Storage Version 0 Selbstbeschreibende PageSets Erweiterungen für den Insert Algorithmus 2 Verschlüsselung der Db2 Daten im DataSet Unterstützung der neuen zhyperlinks Neue Huffman Kompression für Daten 3

4 Neue Statistiken für REAL Storage [1/2] Aktuell kann ein Capacity Planner nur den maximalen Speicherverbrauch eines Db2 ermitteln. RSM Limitationen beim Ermitteln der HVSHARED und HVCOMMON Objekte. Außerdem benötigt RSM einen Spin-Lock, um die Statistiken zu erstellen. Gebraucht wird jedoch die ganze Bandbreite (min, max pro DSG Member), um sicher sagen zu können, ob genug Speicher für neue Anwendungen bereit steht. V11: PI82191 V12: PI

5 Neue Statistiken für REAL Storage [2/2] 4 neue Felder im Accounting (IFCID225) Stealable, discarded pages Private Shared Shared Stack Common Wird einmal pro Tag (Mitternacht + Offset) geschrieben Offset vermeidet, dass alle Member den Spin-Lock gleichzeitig haben wollen. 5

6 Version 0 Selbstbeschreibende PageSets [1/2] Scenario: Db2 TableSpaces werden via DSN1COPY zwischen Systemen kopiert. Die Tabellen Definitionen sind auf Quelle und Ziel nicht absolut identisch. Potentiell wurde das DDL auf der Ziel Seite abgeändert ausgeführt. Problematisch, wenn viele Tabellen in einem MTS TableSpace sind, der auch Tabellen in der Version 0 enthält. Db2 schreibt die Tabellen Formate für geänderte Tabellen, aber nicht für Tabellen in Version 0 Tabellen in Version 0 sind nicht selbstbeschreibend. Wenn ein Schema Unterschied vorliegt, kann es zu Daten Korruption kommen! 6

7 Version 0 Selbstbeschreibende PageSets [2/2] Vorgenommene Erweiterungen: Version 0 System Pages werden bei INSERT, UPDATE, REORG oder LOAD in den TableSpace aufgenommen. Neue Anweisung im REPAIR Utility: INSERTVERSIONPAGES Verbesserte Schema Validierung im REPAIR CATALOG TEST sowie während eines REORG RUNSTATS COPY REBUILD INDEX CHECK DATA 7

8 Erweiterungen für den Insert Algorithmus 2 [1/3] Generelles Ziel: Performance Verbesserungen für INSERT Operationen, wenn der TableSpace als MEMBER CLUSTER definiert wurde. Vermeidung von SpaceMap Contention So wenig Konfiguration notwendig wie möglich zparm für Standard Einstellung DDL Option, um zparm zu überschreiben 8

9 Erweiterungen für den Insert Algorithmus 2 [2/3] Erhaltenes Feedback: Wie kann ich erkennen, das IAG2 benutzt wurde? Performance ist nicht besser geworden Single Threaded INSERT Verschiebung des Engpasses. Nicht robust genug Fehlerszenarien führen zum Abbruch der Transaktion 9

10 Erweiterungen für den Insert Algorithmus 2 [3/3] Erweitertes Monitoring (IFCID 2 & 3), für die Anzahl der Low-Level INSERTs, getrennt für Algorithmus 1 und 2. PCTFREE_FOR_UPDATE Unterstützung Bessere Fehler Handhabung / Vermeidung Automatisches reaktivieren von Algorithmus 2 für temporäre Probleme Komplette Deaktivierung via zparm 10

11 Verschlüsselung der Db2 Daten im DataSet [1/4] Unterstützung für die neue DFSMS DataSet Encryption (z/os 2.2) zur Verschlüsselung der Db2 Daten. Jemand mit TSO Privilegien, der Zugriff auf die Db2 DataSets hat, bekommt keinen Zugriff auf die eigentlichen Daten. Kann in drei Stufen ausgerollt werden Verschlüsselung der Active/Archive Log DataSets Verschlüsselung der Catalog/Directory TableSpaces Verschlüsselung von User TableSpaces 11

12 Verschlüsselung der Db2 Daten im DataSet [2/4] ICSF Admin definiert einen neuen Encryption Key und Key Label Security Admin erlaubt Db2 die Nutzung des Key Labels. Es gibt vier Optionen zur Nutzung des Key Labels: 1. Security Admin spezifiziert den Key Label im DataSet Profil 2. System Database Admin setzt den System Key Label (Nur V12) 3. Application Database Admin setzt den System Key Label für TableSpaces oder STOGROUPs (Nur V12) 4. Storage Admin setzt den KeyLabel für die DFSMS data class 12

13 Verschlüsselung der Db2 Daten im DataSet [3/4] Verschlüsselung der Logs Für die Verschlüsselung der Active Logs muss das Db2 Member gestoppt sein. 1. Neues Log DataSet wird mit Verschlüsselung definiert 2. Inhalt des unverschlüsselten DataSet wird in das neue DataSet kopiert. 3. Starten des Db2 Member 4. DISPLAY LOG zeigt das aktuelle Key Label Neue Archive Log DataSets sind automatisch verschlüsselt. DISPLAY ARCHIVE zeigt das aktuelle Key Label 13

14 Verschlüsselung der Db2 Daten im DataSet [4/4] Verschlüsselung des Catalog / Directory REORG TABLESPACE gegen Catalog/Directory TableSpaces Mit REPORT TABLESPACESET kann der aktuelle Key Label angezeigt werden. Verschlüsselung von User TableSpaces CREATE/ALTER TABLE wurden erweitert, um ein optionales Key Label angeben zu können. CREATE/ALTER STOGROUP erlaubt die Spezifikation eines Key Label für alle Objekte in der Group REORG materialisiert den neuen Key Label 14

15 Unterstützung der neuen zhyperlinks [1/3] zhyperlink ist eine optische Punkt-zu-Punkt Verbindung zwischen dem CEC und dem DASD System. I/O wird synchron (ähnlich wie bei einer CF Anbindung) in den DASD Cache übertragen. Typische Latenz von 20µs..40µs (~10x schneller) Voraussetzung z/os 2.1 DS888x und Firmware Level 8.3 z14 mit zhyperlink Express Adapter 15

16 Unterstützung der neuen zhyperlinks [2/3] Synchrones Read I/O, direkt vom DS8K Cache Versucht bei einem BP Miss, zunächst die Page aus dem Cache der DS8K zu bekommen. Falls die Page im DS8K Cache ist, kann sie direkt genutzt werden. Ansonsten wird es in einen normalen, asynchronen Read I/O umgewandelt. Alle Page Größen unterstützt. V12 Verfügbarkeit in diesem Monat. V11 in Arbeit Log Write I/O Schreibt einen Log Eintrag direkt in den DS8K Cache Wird genutzt für Change COMMIT, Index Splits bei GBP abhängigen Objekten,... DS8K Code aktuell noch nicht verfügbar 16

17 Unterstützung der neuen zhyperlinks [3/3] zhyperlink funktioniert nur, wenn die Daten im Disk Cache der DS8K sind. Synchroner I/O bedeutet hier: Keine asynchrone I/O Interrupt Abarbeitung Daher kein Context Switch Wie bekommt man heraus, ob zhyperlink für Db2 nützlich wäre? zbna Tool (Batch Network Analyzer Tool) Accounting Class 3 InMemory Data Buffer Pools Disk Cache Disk Time 17

18 Neue Huffman Kompression für Daten [1/7] Ziele Effizientere Kompression für TableSpaces Wiederverwenden der existenten ZIV Baum basierten Kompression. Das bewährte Konzept bleibt erhalten. Die aktuelle Kompression (Fixed Length) bleibt ebenso erhalten. So wenig Konfiguration wie möglich Nutzung der CMPSC Erweiterungen im z14 Prozessor Grundvoraussetzungen Db2 for z/os Version 12 z14 Hardware 18

19 Neue Huffman Kompression für Daten [2/7] Ein neuer zparm wird eingeführt, um Huffman zu aktivieren Der zparm muss auf allen DSG Membern gleich gesetzt werden. TS_COMPRESSION_TYPE Specifies the setting for the DB2 subsystem parameter TS_COMPRESSION_TYPE. This parameter indicates the type of compression algorithm to use when creating new compressed table spaces and when reorganizing existing compressed table spaces. Range : FIXED_LENGTH, HUFFMAN Default : FIXED_LENGTH Update : option?? on panel DSNTIPB DS scope : In data sharing, all members of the group need to use the same setting for this parameter Online change : This parameter is not blocked from online change DSNZPxxx : DSN6SPRM.TS_COMPRESSION_TYPE 19

20 Neue Huffman Kompression für Daten [3/7] Huffman Kompression darf nur aktiviert werden, wenn alle Member der DSG auf z14 laufen. Emulation in Software kostet zu viel CP. Daher gilt für <z14: SW Expansion wird unterstützt. Software Kompression wird es nicht geben. Neue Records werden unkomprimiert geschrieben. Es wird eine WTO geschrieben, wenn Huffman auf einer z13 (oder älteren HW) aktiviert wird. 20

21 Neue Huffman Kompression für Daten [4/7] Mögliche, spätere Erweiterung: Eine DDL Option, um das Kompressionsverfahren pro Objekt einzeln bestimmen zu können. CRATE TABLE CREATE TABLESPACE ALTER TABLESPACE.-COMPRESS NO > > +-COMPRESS YES <--- use zparm value +-COMPRESS YES FIXEDLENGTH-+ <--- new option '-COMPRESS YES HUFFMAN-----' <--- new option 21

22 Neue Huffman Kompression für Daten [5/7] Mit z14 erhalten wir Unterstützung für eine Symbol Translation Table, mit der ein fester Code oder ZIV Baum Index auf einen Code mit variabler Länge übersetzt werden kann. Sehr häufige Indizes bekommen einen sehr kurzen Code zugewiesen. Seltene Indizes bekommen einen langen (bis zu 16 Bit) Code. 22

23 Neue Huffman Kompression für Daten [6/7] Nachdem der ZIV Baum erstellt wurde, bauen wir nun einen neuen, temporären Baum den Huffman Tree. Um so tiefer ein Knoten in diesem Baum landet, um so geringer war seine Häufigkeit. Der Pfad von der Wurzel bis zum Blatt beschreibt den zu generierenden Code, der in der STT landet. 23

24 Neue Huffman Kompression für Daten [7/7] Implikationen Neben dem Kompressions Verzeichnis wird nun auch noch eine STT geschrieben. Ein Dictionary wächst somit um mindestens 8KB. Die z14 Hardware begrenzt die maximale Code Länge auf 16 Bits. Somit wird etwas Entropie verloren. Software basierende Expansion/Dekompression (falls die Daten auf einer z13 gelesen werden) hat signifikante CP Kosten. Die komprimierten Daten werden Bit für Bit gelesen und interpretiert! Initial werden wir die Dictionary Form nicht explizit externalisieren. Sie kann aber mit DSN1PRNT ermittelt werden. 24

25 Danke! Oliver Draese STSM, Db2 for z/os Development, IBM Silicon Valley Lab 25