DB2 BLU Shadow Tables – Teil 1: OLAP in OLTP
Dies ist der erste Teil einer zweiteiligen Reihe von Joachim Klassen zum Thema DB2 BLU Shadow Tables. Der zweite Teil ist unter DB2 BLU Shadow Tables – Teil 2: Installation und Konfiguration von CDC erschienen.

Immer häufiger stehen Datenbank-Administratoren vor der Tatsache und Herausforderung, dass analytische Auswertungen (OLAP) auf die operationalen Daten einer OLTP-Datenbank-Umgebung ausgeführt werden müssen. Man findet hierfür auch den Begriff OLTAP in der Literatur.
Ein verbreiteter Ansatz, diese Problemstellung anzugehen, ist der, die vorhandene OLTP-Umgebung für analytische Auswertungen zu optimieren. Geeignet sind folgende Maßnahmen:
- Definieren zusätzlicher Indexe auf die operationalen Tabellen
- INSERT-, DELETE- und evtl. UPDATE-Operationen werden dadurch aufwändiger
- Die Dauer von RUNSTATS- und REORG-Läufen erhöht sich
- Erstellen von Materialized Query Tables (MQT – oder auch Materialized Views genannt)
- Hoher Aufwand für den DBA, die "richtigen" MQT zu definieren
- Speichern der Tabellen als Multi-dimensional Clustered Tables (MDC)
- Auch hier hoher Aufwand für den DBA, die "richtigen" Dimensionen zu finden
Während diese Maßnahmen positiv für die analytischen Auswertungen sind, wirken Sie sich oft negativ auf die eigentliche, OLTP-orientierte Workload aus – und sie beschäftigen den DBA.
Ein anderer Ansatz geht dahin, die operationalen Daten, die für analytischen Auswertungen benötigt werden, in eine weitere Datenbank auszulagern, die dann für OLAP optimiert ist. Dabei muss allerdings folgendes berücksichtigt werden:
- Zusätzliche Hardware- und Lizenzkosten fallen an,
- der Aufwand, der entsteht, um eine Infrastruktur für das regelmäßige Aktualisieren der Daten in der OLAP-Umgebung aufzubauen und zu betreuen und
- eventuell muss ein ETL-Tool beschafft werden.
Mit dem Konzept der DB2 BLU Shadow Tables ist nun eine weitere Alternative hinzugekommen, die ich in diesem Artikel vorstellen möchte.
DB2 BLU – Kurzvorstellung
Doch bevor wir uns näher mit den Shadow Tables (oder von nun an Spiegeltabellen) befassen, zunächst eine kurze Vorstellung des DB2 BLU Features: Im April 2013 wurde die Version 10.5 von DB2 LUW offiziell vorgestellt. Die wahrscheinlich größte technische Neuerung dieser Version ist die "BLU Acceleration". BLU ist die Abkürzung für Blink Ultra – doch wofür steht Blink?
Blink steht für eine Reihe von Techniken zur Beschleunigung von analytischen Auswertungen, die im IBM-Labor in Almaden seit 2006 entwickelt werden. In den Produkten "IBM Smart Analytics Optimizer for DB2 for z/OS" und "Informix Warehouse Accelerator", die bereits in den Jahren 2010 bzw. 2011 auf den Markt kamen, wurden bereits Blink Techniken integriert. Hier eine Auswahl der wichtigsten Techniken:
- Spaltenorientierte Speicherung von Tabellen
- Nur Daten einer Spalte einer Tabelle werden auf einem Speicherblock (= Page) abgelegt.
- Optimierung für In-Memory-Verarbeitung
- Aber ohne die Notwendigkeit, alle Daten komplett im RAM ablegen zu müssen.
- Effiziente Komprimierung
- Wertebasiert unter Beibehaltung der Reihenfolge.
- Dadurch müssen die Daten für Vergleiche mit Prädikaten wie "=" oder ">" nicht dekomprimiert werden.
- Synopsis-Tabellen
- eine Art von "negativen" Indexen – "wo sind die gesuchten Daten nicht".
- Ähnlich der Zone Maps von Netezza.
- Optimale Ausnutzung der CPU-Ressourcen
- Verwendung von SIMD-Instruktionen (Single Instruction Multiple Data) um mehrere Werte in einer CPU-Instruktion zu vergleichen.
- Maximierte Nutzung des L2 und L3 CPU Cache.
- Geringer Administrations- und Konfigurationsaufwand
- "Load-and-go".
Durch diese Techniken können komplexe Abfragen auf große Tabellen um Faktoren beschleunigt werden. Kunden berichten hier von Beschleunigungen um Faktor 10-20 – in Extremfällen auch bis Faktor 100 oder mehr. BLU steht für die Implementierung der aktuellsten Blink-Technologien in DB2 LUW. Dabei ist BLU kein eigenständiges Produkt oder eine separate Datenbank-Engine, sondern integraler Bestandteil von DB2 LUW. Spaltenorientierte und reihenorientierte Tabellen können dadurch in derselben Datenbank gespeichert und auch zusammen ausgewertet werden. Durch diese tiefe Integration ist die BLU-Funktionalität prinzipiell in jeder DB2-Edition enthalten und muss nur über einen dieser Lizenzschlüssel freigeschaltet werden:
- Advanced Workgroup Server Edition.
- Advanced Enterprise Server Edition.
- IBM DB2 BLU Acceleration In-Memory Offering
Zusatzpaket für Workgroup und Enterprise Edition
Weitere Details zur BLU-Technik finden Sie im Wikipedia-Eintrag [1] und im "rapid adoption guide" von IBM [2].
Problematik OLTP – OLTAP mit BLU angehen?
Die eingangs geschilderte Problematik – analytische Auswertungen auf operationalen Daten – könnte also auch durch den Einsatz von BLU und das Umstellen der bestehenden reihenorientierten Tabellen auf die Spaltenorientierung angegangen werden. Zumal mit dem db2convert-Kommando [3] ein Tool zur Verfügung steht, welches diese Konvertierung im laufenden Betrieb mit minimaler Ausfallzeit der Tabelle durchführen kann. Jedoch haben spaltenorientierte Tabellen in einer überwiegend OLTP-orientierten Umgebung auch ihre Nachteile. So sind Einzelsatzoperationen und Abfragen, deren Ergebnismengen viele Spalten und/oder Reihen aufweisen, mit spaltenorientierten Tabellen nicht so performant umzusetzen wie mit herkömmlichen reihenorientierten Tabellen. Und es gibt eine ganze Reihe von Restriktionen für spaltenorientierte Tabellen – wie zum Beispiel keine Unterstützung von:
- Datenbanken mit einem anderem Zeichensatz als UTF-8 (Unicode)
Mit der kommenden DB2 LUW-Version 11 wird wohl auch Codepage 819 unterstützt werden. - Trigger sowie Check- und Referential-Constraints.
- LOB- und XML-Datentypen.
- Range-Partitioning.
- Temporalen und temporären Tabellen.
- Trigger und Check Constraints.
- Row und Column Access Control (RCAC).
BLU Shadow Tables
Verwende ich für meine Tabellen nun die reihen- oder die spaltenorientierte Speicherung? Beides!
An diesem Punkt kommt das Konzept der DB2 BLU-Spiegeltabellen ins Spiel, die im August 2014 mit dem Fixpack 4 für DB2 LUW Version 10.5 (auch Cancun Release genannt) eingeführt wurden. Eine Spiegeltabelle ist eine Kopie einer reihenorientierten Tabelle, die spaltenorientiert gespeichert wird. Dabei können alle oder auch nur ein Subset der Spalten der Originaltabelle in der Spiegeltabelle abgebildet werden. Technisch wird eine Spiegeltabelle als eine "replication-maintained Materialized Query Table" realisiert. Dadurch kann der DB2-Optimierer Abfragen auf die Originaltabellen automatisch und transparent für die Anwendung auf die Spiegeltabelle umleiten, wie wir das von den bekannten MQT gewohnt sind.
Die Aktualisierung der Spiegeltabellen wird durch das Produkt "Infosphere Change Data Capture Replikation for DB2 (CDC)" implementiert. Die Änderungen an den Originaltabellen werden dabei asynchron und blockweise in die Spiegeltabelle einarbeitet. Auf die damit einhergehende Latenz wird später eingegangen. Weitere Informationen sind im DB2 Knowledge Center zu finden [4]. Abb.1 zeigt, wie eine OLTP DB-Umgebung mit BLU Shadow-Tabellen aussieht.
DML Operationen wie INSERT, UPDATE, DELETE oder MERGE sowie SELECT Anweisungen, die nur wenige Datensätze ansprechen oder große Ergebnismengen produzieren, werden wie bisher auf die Originaltabellen ausgeführt.
Dagegen werden SELECT Anweisungen, die große Datenmengen verarbeiten und aggregieren, vom DB2 SQL Optimierer umgeschrieben und gegen die Spiegeltabelle ausgeführt - transparent für die Anwendung.
Technische Details
Hier ein Beispiel für ein CREATE TABLE DDL Statement einer Spiegeltabelle:
CREATE TABLE SHADOW.TAB1 AS (SELECT C1,C3,C4,C5,C8 FROM PROD.TAB1) DATA INITIALLY DEFERRED REFRESH DEFERRED ENABLE QUERY OPTIMIZATION MAINTAINED BY REPLICATION ORGANIZE BY COLUMN IN TS_SHADOW;
Betrachten wir die Definition der Spiegeltabelle etwas genauer:
- CREATE TABLE SHADOW.TAB1
Eine Spiegeltabelle kann in einem eigenen Schema oder im Schema der Originaltabelle definiert werden. Im Falle von letzterem muss ein entsprechendes Suffix oder Präfix an den Namen der Tabelle angehängt werden. - AS (SELECT C1,C3,C4,C5,C8 FROM PROD.TAB1)
Ein SQL Fullselect auf die Originaltabelle. Der Fullselect darf einzelne Spalten aufzählen, aber keine Ausdrücke oder Funktionen sowie keine AS-, WHERE-, GROUP BY-, HAVING- oder ORDER BY-Klausel enthalten. - DATA INITIALLY DEFERRED REFRESH DEFERRED
Diese Klauseln kennen wir schon von den Materialized Query Tables (MQT). Sie bewirken, dass die Spiegeltabelle nach dem Anlegen zunächst leer ist (DATA INTIALLY DEFERRED) und nach dem initialen Beladen asynchron aktualisiert wird (REFRESH DEFERRED). Andere als diese Optionen sind derzeit nicht möglich. - ENABLE QUERY OPTIMIZATION
Hinweis für den SQL-Optimierer, dass er diese Tabelle grundsätzlich für das transparente Umschreiben von Anweisungen (Query Rewrite) verwenden darf. - MAINTAINED BY REPLICATION
Festlegung, dass die Spiegeltabelle durch ein Replikationsverfahren aktualisiert wird. - ORGANIZE BY COLUMN
Die Tabelle wird spaltenorientiert gespeichert. - IN TS_SHADOW
Der Tabellenbereich (Tablespace) für die physikalische Speicherung. Für Spiegeltabellen werden hier separate Tabellenbereiche empfohlen. Weitere Details dazu in den "Best Practises", auf die wir später im Artikel eingehen.
Voraussetzungen:
- Die Originaltabelle muss einen Primärschlüssel oder Unique Constraint besitzen, der auch in der Spaltenliste der Spiegeltabelle sein muss.
- Die Spiegeltabelle muss denselben Primärschlüssel haben.
- Es kann nur eine Spiegeltabelle je Originaltabelle definiert werden.
- Die Datenbank muss mit dem UTF-8-Zeichensatz angelegt worden sein.
Die Aktualisierung der Spiegeltabellen erfolgt wie schon erwähnt mit dem Produkt "Infosphere Change Data Capture Replikation for DB2" (ab jetzt nur CDC). Auf die Installation und Konfiguration der CDC-Replikation wird am Ende des Artikels detailliert eingegangen. Für jetzt gehen wir erstmal davon aus, dass CDC aufgesetzt ist und die Synchronisation der Spiegeltabellen aktiviert ist.
Systemtabelle SYSTOOLS.REPL_MQT_LATENCY
Da die Aktualisierung einer Spiegeltabelle nur asynchron erfolgen kann, gibt es immer eine Differenz zwischen der Aktualität der Daten der Originaltabellen und den Daten der Spiegeltabellen. Diese Differenz wird in einer Systemtabelle festgehalten, die von CDC permanent aktualisiert wird: SYSTOOLS.REPL_MQT_LATENCY [5]. Die Tabelle SYSTOOLS.REPL_MQT_LATENCY muss für jede Datenbank mit Spiegeltabellen manuell mit diesem Prozeduraufruf erzeugt werden:
CALL SYSPROC.SYSINSTALLOBJECTS(’REPL_MQT’, ’C’, ’SYSTOOLSPACE’, NULL);
Im obigen Beispiel wird die Tabelle im Tabellenbereich SYSTOOLSPACE gespeichert (3. Parameter), in dem auch andere systemnahe Objekte definiert sind.
SYSTOOLS.REPL_MQT_LATENCY enthält nur einen Datensatz mit den Spalten:
- COMMIT_POINT
Zeitpunkt der letzten Commit-Operation nach der die Änderungen an Spiegeltabellen repliziert wurden (in Sekunden seit dem 1.1.1970).
Dies ist der Startzeitpunkt, an dem der Wert für die zweite Spalte DELAY_OFFSET generiert wird. - DELAY_OFFSET
Die Anzahl von Sekunden zwischen dem Zeitpunkt, an dem die Quellentabellendaten gelesen werden und dem letzten COMMIT von Änderungen an den Spiegeltabelle.
Um den Zeitstempel der letzten Refresh-Operation zu ermitteln, muss der Wert von DELAY_OFFSET vom Zeitpunkt COMMIT_POINT abgezogen werden. Eine entsprechende SQL-Abfrage sieht dann so aus:
SELECT ( TIMESTAMP('1970-01-01') + (COMMIT_POINT - DELAY_OFFSET) SECONDS + CURRENT TIMEZONE) AS LAST_REFRESH_TIMESTAMP FROM SYSTOOLS.REPL_MQT_LATENCY;
Um die aktuelle Latenzzeit zu ermitteln:
SELECT CURRENT TIMESTAMP - ((TIMESTAMP('1970-01-01') + (COMMIT_POINT - DELAY_OFFSET) SECONDS) + CURRENT TIMEZONE ) FROM SYSTOOLS.REPL_MQT_LATENCY
Jede Datenbank-Sitzung kann über das Spezial-Register CURRENT REFRESH AGE festlegen, wie groß die maximale Latenzzeit sein darf, unter der Spiegeltabellen noch berücksichtigt werden:
SET CURRENT REFRESH AGE 230
Wichtig: CURRENT REFRESH_AGE wie auch die berechnete Latenzzeit aus SYSTOOLS.REPL_MQT_LATENCY repräsentieren eine Zeitdauer in der Form "YYYYMMDDhhmmss" – nicht Sekunden. So ist der Wert 230 für CURRENT REFRESH_AGE aus dem obigen Beispiel eine Zeitdauer von 2 Minuten und 30 Sekunden und nicht 230 Sekunden!
Liegt die aktuelle Latenzzeit aus SYSTOOLS.REPL_MQT_LATENCY über dem Wert des CURRENT REFRESH AGE Register der Sitzung wird der DB2 SQL-Optimierer Spiegeltabellen nicht berücksichtigen und die Abfrage nicht umschreiben. Andere mögliche Werte für CURRENT REFRESH_AGE sind:
- ANY
Die Latenzzeit wird ignoriert und die Abfrage auf jeden Fall auf die Spiegeltabellen umgeleitet, sofern alle sonstigen Voraussetzungen erfüllt sind. - 0
Der DB2-Optimierer berücksichtigt die Spiegeltabellen nicht.
Voraussetzungen für das Umleiten von Abfragen
Damit der DB2-Optimierer das transparente Umleiten von SELECT-Anweisungen (Query Rerouting) auf die Spiegeltabellen überhaupt in Erwägung zieht, müssen weitere Voraussetzungen erfüllt sein:
- Alle Tabellen, die in der Abfrage angesprochen werden, müssen eine entsprechende Spiegeltabelle aufweisen, d.h. auch für kleine, statische Lookup-Tabellen müssen Spiegeltabellen definiert werden.
- Alle Spalten, die in der Abfrage angesprochen werden, müssen in den Spiegeltabellen vorhanden sein.
Folgende Systemeinstellungen müssen entweder auf Sitzungs- oder Datenbankebene aktiv sein:
- Die partitionsinterne Parallelität muss aktiviert sein
Für die aktuelle Sitzung: CALL ADMIN_SET_INTRA_PARALLEL(’YES’)
Generell in der DBM CFG: INTRA_PARALLEL YES - Der Grad der Parallelität muss auf einen Wert größer 1 gesetzt sein. Der Wert ANY überlässt dem System die Wahl des tatsächlichen Werts
Sitzung: SET CURRENT DEGREE ’ANY’
DB CFG: DFT_DEGREE ANY - Dem DB2-Optimierer muss erlaubt werden, Spiegeltabellen als besondere Art von Materialized Query Tables (MQT) für die Optimierung von Abfragen zu verwenden
Sitzung: SET CURRENT MAINTAINED TABLE TYPES FOR OPTIMIZATION = REPLICATION
DB CFG: DFT_MTTB_TYPES REPLICATION - Spezial-Register CURRENT REFRESH_AGE muss auf einen Wert größer Null oder ANY gesetzt sein
Sitzung: SET CURRENT REFRESH AGE ’ANY’
DB CFG: DFT_REFRESH_AGE ANY
Alle notwendigen Systemeinstellungen können also auf Datenbankebene generell gesetzt werden und sind damit für alle Datenbank-Sitzungen gültig. Wenn wir jedoch nochmals auf die Ausgangslage zurückblicken, nämlich dass in einer OLTP-Umgebung zusätzlich Auswertungen für analytische Zwecke möglich sein sollen, wird klar, dass die Verwendung von Spiegeltabellen und die damit einhergehenden Systemeinstellungen nicht für jede Datenbank-Sitzung Sinn machen. Speziell die partitionsinterne Parallelität kann für klassischen OLTP-Betrieb durchaus auch einen gegenteiligen Effekt haben. Deshalb müssen die oben genannten Einstellungen meist nur für bestimmte Anwendungen (BI-Tools wie Cognos) oder Anwender (Controlling, GL …) auf Sitzungsebene aktiviert werden.
Eine Möglichkeit, das zu implementieren, ist die Verwendung einer Datenbank-Verbindungsprozedur, die beim Start jeder neuen Datenbank-Verbindung aufgerufen wird. In der Datenbank-Konfiguration wird dazu der Name der Prozedur im Parameter CONNECT_PROC hinterlegt. Ein Beispiel für eine Verbindungsprozedur und das Aktivieren in der DB CFG:
CREATE OR REPLACE PROCEDURE DB2INST1.CONN_PROC() BEGIN DECLARE APPNAME VARCHAR(128);-- SET APPNAME = (SELECT COALESCE(CLIENT_APPLNAME,’’) FROM TABLE(MON_GET_CONNECTION(MON_GET_APPLICATION_HANDLE(), -1))); IF (APPNAME = ’REPORTS’) THEN CALL SYSPROC.ADMIN_SET_INTRA_PARALLEL(’YES’); SET CURRENT DEGREE ’ANY’; SET CURRENT MAINTAINED TYPES REPLICATION; SET CURRENT REFRESH AGE 230; END IF; END
Die Prozedur ermittelt über die Systemfunktion MON_GET_CONNECTION den Namen der aktuellen Anwendung und setzt für die Anwendung REPORTS die notwendigen Einstellungen. Für alle anderen Anwendungen wird die Umgebung nicht verändert.
Wichtig: Die Prozedur muss von jedem potentiellen Datenbank-Benutzer ausgeführt werden können:
GRANT EXECUTE ON PROCEDURE db2inst1.conn_proc TO PUBLIC UPDATE DB CFG USING CONNECT_PROC db2inst1.conn_proc IMMEDIATE
Kritisch bei der Verwendung einer Datenbank-Verbindungsprozedur kann es werden, wenn die Prozedur invalidiert wurde. Das passiert beispielsweise, wenn ein in der Prozedur verwendetes Objekt (Tabelle, View, Index …) gelöscht und anschließend wieder neu angelegt wird. Vorsichtige DB2-Anwender werden deshalb die automatische Revalidierung von Objekten aktivieren.
UPDATE DB CFG USING AUTO_REVAL ON
Kontrolle ist besser…
Wenn dann alle Voraussetzungen erfüllt sind, kann mit der SQL EXPLAIN-Funktion überprüft werden, ob das Umleiten von Abfragen auf die Spiegeltabellen auch tatsächlich funktioniert.
Im Folgenden zwei simple Beispiele, bei denen wir davon ausgehen, dass es zur Tabelle PROD.CUSTOMER eine Spiegeltabelle SHADOW.CUSTOMER gibt:
CONNECT TO <dbname> CALL ADMIN_SET_INTRA_PARALLEL(’YES’) SET CURRENT DEGREE ’ANY’ SET CURRENT MAINTAINED TYPES REPLICATION SET CURRENT REFRESH AGE 230 SET CURRENT EXPLAIN MODE EXPLAIN SELECT COUNT(*) FROM PROD.CUSTOMER SET CURRENT EXPLAIN MODE NO
Durch die Anweisung CURRENT EXPLAIN MODE EXPLAIN wird nur ein EXPLAIN erstellt, die SELECT-Anweisung wird nicht ausgeführt. Die Auswertung des EXPLAIN kann anschließend z. B. mit dem Kommandozeilentool db2exfmt erfolgen:
db2exfmt –d <dbname> -1
Abb.2 zeigt die Darstellung des Ausführungsplans aus der db2exfmt-Ausgabe.
Wie man sieht, wurde die Abfrage umgeschrieben auf die Tabelle SHADOW.CUSTOMER. Die Diagnosemeldung EXP0149W bestätigt dies auch nochmals. Als Grad der Parallelität (Query Degree) wurde 4 gewählt – das System orientiert sich hier an der Anzahl der verfügbaren CPU Cores.
Nun dieselbe Abfrage nochmals, nur diesmal ohne Parallelität und mit REFRESH AGE 0 (s. Abb.3):
SET CURRENT DEGREE 1 SET CURRENT REFRESH AGE 0 SET CURRENT EXPLAIN MODE EXPLAIN SELECT COUNT(*) FROM PROD.CUSTOMER SET CURRENT EXPLAIN MODE NO
Die Abfrage wurde nicht umgeschrieben – Diagnosemeldung EXP0054W sagt uns auch warum. Zu beachten ist, dass die Kosten für die Abfrage deutlich höher liegen als bei dem vorigen Beispiel. Außerdem verwendet der DB2-Optimierer für den COUNT(*) den Primärschlüsselindex anstatt einer Table-Scan-Operation.
Dass der DB2-Optimierer Spiegeltabellen nicht zwangsläufig verwendet, auch wenn die notwendigen Voraussetzungen erfüllt sind, zeigt das zweite Beispiel:
CALL ADMIN_SET_INTRA_PARALLEL(’YES’) SET CURRENT DEGREE ’ANY’ SET CURRENT MAINTAINED TYPES REPLICATION SET CURRENT REFRESH AGE 230 SET CURRENT EXPLAIN MODE EXPLAIN SELECT * FROM PROD.CUSTOMER SET CURRENT EXPLAIN MODE NO
Dieses Mal wird kein COUNT ermittelt, sondern die komplette Tabelle soll als Ergebnismenge zurückgegeben werden (s. Abb.4).
Der DB2-Optimierer leitet die Abfrage dieses Mal nicht auf die Spiegeltabelle um, da die Kosten hierfür höher wären. Das ist für diese Art von Abfrage nicht überraschend – Ergebnismengen mit vielen Spalten und Zeilen können mit traditionellen reihenorientierten Tabellen effizienter erstellt werden.
Best Practises
Speicher für Sortierungen und Hash-Joins
Spiegeltabellen werden, wie alle spaltenorientierten Tabellen, ausschließlich mit Table-Scan-Operationen gelesen. Dadurch werden häufig Sortierungen notwendig, da ein Index als Alternative zur Sortierung nicht zur Verfügung steht. Als Verfahren zum Verknüpfen von Spiegeltabellen (JOIN) wird mit DB2 V10.5 nur der Hash-Join unterstützt.
Sowohl Sortierungen als auch das Hash-Join-Verfahren benötigen im BLU-Umfeld meist große Mengen an Hauptspeicher aus dem datenbankweiten Sortierspeicher, der mit den DB CFG-Parametern SHEAPTHRES_SHR und SORTHEAP konfiguriert wird. Der Sortierspeicher sollte deshalb deutlich erhöht werden. Empfehlungen:
- 40-50 % des gesamten Hauptspeichers, welcher der Datenbank zur Verfügung steht (DB CFG Parameter DATABASE_MEMORY) für den datenbankweiten Sortierspeicher (SHEAPTHRES_SHR) reservieren.
- 5-20 % davon für den Sortierspeicher einer Sitzung (SORTHEAP).
Diese Empfehlungen stehen aber im Kontrast zum eigentlichen OLTP Workload, der ja normalerweise keine großen Ansprüche an den Sortierspeicher hat. Deshalb kann mit der DB2 Registry-Variablen DB2_EXTENDEND_OPTIMIZATION festgelegt werden, dass für Abfragen auf herkömmliche, reihenorganisierte Tabellen nicht der aktuelle Wert von SORTHEAP aus der DB CFG verwendet werden soll, sondern ein anderer, fester Wert:
db2set DB2_EXTENDEND_OPTIMIZATION=„OPT_SORTHEAP_EXCEPT_COL nnnn“
Cache für den Systemkatalog
Durch die Spiegeltabellen sind mehr Objekte in der Datenbank vorhanden. Deshalb sollte der Cachebereich für den DB2-System-Katalog (DB CFG-Parameter CATALOGCACHE_SZ) um 10-20 Prozent vergrößert werden, je nach Anzahl der zusätzlichen Objekte.
LOAD Utility
Für das initiale Beladen der Spiegeltabellen (Refresh) verwendet CDC das LOAD Utility. LOAD erstellt dabei vor dem eigentlichen Laden ein Dictionary (Wörterbuch) für die Komprimierung und komprimiert die Daten beim anschließenden Laden anhand dieses Wörterbuchs. Damit ein effizientes Komprimierungs-Wörterbuch für die Spiegeltabellen erstellt werden kann, sollte zumindest für die Dauer der initialen Refresh-Operationen der Speicherbereich für Utilities (DB CFG Parameter UTIL_HEAP_SZ) deutlich vergrößert werden. Empfehlung ist hier 1.000.000 Pages, bei mehr als 256 GB verfügbaren RAM 4.000.000 Pages.
I/O-Optimierung
Spiegeltabellen sollten in separaten Tabellenbereichen (Tablespaces) mit diesen Eigenschaften gespeichert werden:
- Pagegröße 32 KB
- Extentgröße 4
Für ein effizientes I/O-Management sollten die Tabellenbereiche der Spiegeltabellen dedizierten Bufferpools zugeordnet werden. Damit und mit den gestiegenen Anforderungen an Sortierspeicher ist auch klar, dass man der DB2-Instanz deutlich mehr Hauptspeicher zur Verfügung stellen sollte, wenn Spiegeltabellen eingesetzt werden.
Dies ist der erste Teil einer zweiteiligen Reihe von Joachim Klassen zum Thema DB2 BLU Shadow Tables. Der zweite Teil ist unter DB2 BLU Shadow Tables – Teil 2: Installation und Konfiguration von CDC erschienen.
- Wikipedia: IBM BLU Acceleration
- IBM: DB2 with BLU Acceleration: A rapid adoption guide
- IBM Knowledge Center: db2convert-Tool
- IBM Knowledge Center: Shadow Tables
- IBM Knowledge Center: SYSTOOLS.REPL_MQT_LATENCY