Über unsMediaKontaktImpressum
Joachim Klassen 14. Juni 2016

DB2 BLU Shadow Tables – Teil 2: Installation und Konfiguration von CDC

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

Damit das transparente Umleiten von analytischen Anfragen auf die Spiegeltabellen sinnvoll funktionieren kann, müssen diese permanent aktualisiert werden. Kommen wir deshalb zur Installation und Konfiguration von CDC.

Installation

Die Installationspakete für CDC werden mit den Advanced Editionen von DB2 LUW ausgeliefert – inklusive einer Lizenz zur Nutzung für die Synchronisation von Spiegeltabellen.
Folgende CDC-Komponenten werden benötigt:

  • "Infosphere CDC for DB2 for LUW 10.2.1." oder höher
    Die Replication Engine
  • "Infosphere CDC Access Server"
    Server-Prozess für die Kommunikation mit der Management Console und der CDC-Kommandozeile (CHCCLP)
  • "Infosphere CDC Management Console"
    GUI – nur für Windows verfügbar,
    Benötigt den Infosphere CDC Access Server
    Optional – aber unbedingt empfehlenswert

Dank der recht guten Dokumentation "Implementieren von Spiegeltabellen" und dem intuitiven Frontend "Management Console" ist es auch ohne CDC-Kenntnisse möglich, die Replikation für Spiegeltabellen aufzusetzen und zu konfigurieren.

Im Folgenden wird das Vorgehen schrittweise beschrieben – dabei wird davon ausgegangen, dass sowohl Datenbank-Server als auch die CDC Replication Engine auf einer Linux/UNIX-Plattform betrieben werden. Für das Verständnis der nächsten Schritte zunächst noch ein kurzer Einblick in Begriffe aus der CDC-Technik:

Begriffe aus der CDC-Technik

Begriff Beschreibung
CDC-Instanz Eine Instanz der CDC Replikation Engine. Für Spiegeltabellen wird nur eine CDC-Instanz benötigt, da Quelle und Ziel der Replikation (Source und Target DB) identisch sind.
Datastore Hier werden Informationen zu den Datenquellen und Verbindungen gespeichert, unter anderem auch performance-relevante Einstellungen. Es gibt einen Datastore für alle Spiegeltabellen einer Datenbank.
Table Mapping Verknüpfung zwischen Quell- und Zieltabelle. Hier wird u. a. festgelegt, welche Spalten der Quelltabelle in die Spiegeltabelle repliziert werden.
Subscription Eine Gruppe von Table Mappings. Alle Table Mappings für Spiegeltabellen müssen in einer Subscription zusammengefast werden. Die Replikation kann auf Ebene der Subscription gestartet und gestoppt werden.
Replikation Überbegriff über die permanente Synchronisation der Inhalte von Quell- und Zieltabellen.
Mirroring Das kontinuierliche Abgleichen der Daten von Tabellen in einer Subscription.
Refresh Komplette Übernahme der Daten in die Zieltabelle, z. B. beim erstmaligen Start der Replikation. Erst danach startet das Mirroring.
Latency Die Latenz gibt an, wie synchron die Daten der Spiegeltabellen mit den Quelltabellen sind. Latenz wird üblicherweise in Sekunden angegeben.

Die CDC Capture Engine liest die Daten für den initialen Load bzw. Refresh direkt aus den Tabellen des Source Datastore. Anschließende Datenänderungen an den Tabellen werden aus dem Transaktionslog der Datenbank ermittelt. Die Übertragung der Daten zum Ziel erfolgt direkt mittels TCP/IP. Die CDC-Instanz auf dem Ziel-System pflegt die erhaltenen Daten in die Zieltabellen ein. Für die Replikation von Spiegeltabellen vereinfacht sich die Darstellung insofern, dass es nur einen Datastore gibt. Source und Target Datastore sind hier ein und derselbe, ansonsten ist der Prozess identisch.

Vor der Installation der CDC-Software müssen zunächst Benutzer und Arbeitsverzeichnis festgelegt bzw. definiert werden:

  • DB2 CDC User
    Eine lokale Userid mit DATAACCESS sowie SYSADM- oder DBADM-Recht auf der Datenbank.
    CDC verbindet sich später mit diesem User zur Datenbank und wertet über die DB2ReadLog-API die DB2 Log Files aus. Dazu wird die SYSADM oder DBADM Berechtigung benötigt.
    Beim Definieren des CDC Data Store erstellt dieser User Tabellen für CDC-Metadaten in der Datenbank.
    Tipp: Vorab einen separaten Tablespace sowie das Schema für die CDC Metadaten-Objekte erstellen und dem DB2 CDC User die notwendigen Rechte darauf geben.
    - USE Recht für Tablespace
    - CREATEIN-, ALTERIN-, DROPIN-Rechte für Schema
  • CDC User
    Userid für die Installation und initiale Konfiguration von InfoSphere CDC Replication Engine und Access Server.
    Dieser User benötigt Lesezugriff auf das “Local database directory” (…/NODE0000/sqldbdir) der Datenbank.
    Für den DB2 CDC- und den CDC-User kann derselbe Account verwendet werden.
    Tipp: Die DB2-Profildatei (sqllib/db2profile) im Login Profile des CDC User sourcen.
  • Arbeitsverzeichnis für LOAD Refresh-Operationen
    Hier werden Daten für die LOAD-Operationen beim initialen Beladen oder einem kompletten Refresh der Spiegeltabellen zwischengespeichert.
    Der DB2 Instance Owner und der DB2 CDC User benötigen hier Read/Write-Zugriff.
    Für optimale I/O-Performance wird ein separates Filesystem empfohlen.

Empfehlung für die Installation der CDC-Software:

  • die Replication-Engine und den Access-Server direkt auf dem Datenbank-Server installieren und
  • die Management-Console auf den Windows-Workstations der Administratoren.

CDC Konfiguration

Der CDC Access Server User, der für die Arbeit mit der Management Console und der Kommandozeile benötigt wird, sowie die CDC-Instanz müssen mit dem CDC User über die Kommandozeile erstellt und konfiguriert werden. Alles Weitere kann (und sollte) mit der CDC Management Console erfolgen.

CDC Access Server User anlegen

  • Im bin-Verzeichnis der Access Server-Installation:
    ./dmcreateuser cdcacc cdcacc cdcacc Passw0rd SYSADMIN TRUE TRUE TRUE
  • cdcacc steht hier für Userid,-name und Beschreibung unisono.
  • Passw0rd ist das initiale Passwort.
  • Der Benutzer hat die SYSADMIN Rolle und Manager Rechte (1. TRUE).
  • Dass Passwort muss beim ersten Login geändert werden und läuft nicht ab (2. und 3. TRUE).

InfoSphere CDC Instanz anlegen

  • CDC-Konfiguration-Tool im bin-Verzeichnis der Replication Engine-Installation starten:
    ./dmconfigurets
  • Nach der "Welcome Page" eine 2 eingeben, dann "add an InfoSphere CDC instance" wählen.
  • Eingaben:
    • Name der CDC Instanz – muss eindeutig sein.
    • TCP/IP-Portnummer – Default port ist 10901(Diese Portnummer wird in der CDC Management Console für den Zugriff auf den Datastore benötigt).
    • cdc-staging-store-size angeben – Default ist 100 GB (Zwischenspeicher für ausgelesene Log-Daten).
    • RAM für die InfoSphere CDC instance angeben (Default sind 1024 MB für eine 64-bit-Instanz, Empfehlung 3600 MB).
    • TCP/IP als exklusive Kommunikationsmethode zwischen Datastores auswählen.
    • Name von DB2-Instanz und Datenbank angeben.
    • Advanced parameters configuration umgehen (Wird später über die Management Console durchgeführt).
    • db2-cdc-user mit Passwort angeben (Das Konfigurationstool zeigt nun die in der DB vorhandenen Schemata an).
    • Das Schema, welches für die CDC-Metadaten verwendet werden soll, auswählen.
    • Den refresh_loader_path angeben.
    • Die cdc-instance-name wird nun erstellt und auf Anfrage gestartet.
    • Den Start hier ablehnen und Option 6 (Exit) wählen.

Konfiguration der InfoSphere CDC Instanz 

  • Automatische Aktualisierung der SYSTOOLS.REPL_MQT_LATENCY Table aktivieren:
    ./dmset -I <cdc-instance> maintain_replication_mqt_latency_table=true 
  • Zeit zwischen zwei Restart-Versuchen für persistente Subskriptionen setzen:
    ./dmset -I <cdc-instance> mirror_auto_restart_interval_minutes=2
  • CDC-Instanz starten:
    nohup ./dmts64 -I <cdc-instance> &
  • Optional: Verifikation
    ./dmset -I <cdc-instance>

CDC Management Console

Das Erstellen und Konfigurieren von Datastore, Subscription, Table Mappings etc. führt man am besten mit der CDC Management Console durch. Die IP-Adresse im Feld "Server Name" ist die Adresse des Hosts, auf dem der CDC Access Server läuft. Die Portnummer wurde bei der Installation des Access Server vergeben – nicht zu verwechseln mit der Portnummer der CDC Instanz!

Die CDC Management Console unterscheidet drei Bereiche für Monitoring, Konfiguration und Access Manager – in Abb.3 oben farblich markiert.

CDC Datastore erstellen und konfigurieren

Ein CDC Datastore wird im Bereich "Access Manager" erstellt. Dazu ein Rechtsklick im Tab "Datastore Management" (s. Abb.4 links).

Hostname und Port Nummer der CDC-Instanz angeben. Die Datastore Properties werden automatisch über den "Ping"-Button übernommen (s. Abb.4 rechts).

Die Verbindungsinformationen werden im Tab "Connection Management" per Rechtsklick auf den zuvor erstellten Datastore konfiguriert: "Assign User" (s. Abb.5, links oben).

In der "Select Users"-Listbox werden die zuvor erstellten CDC User gelistet (s. Abb.5, links unten).

Nach der Auswahl des CSC Users wird der Dialog für die Datenbank-Verbindungsparameter geöffnet (s. Abb.5, rechts).

CDC Subscription erstellen und konfigurieren

Nach der Definition des Datastore ist der nächste logische Schritt die Subscription für die künftigen Spiegeltabellen aufzusetzen (s. Abb.6).

Wichtig: In den "Advanced Settings" die Checkbox "Mark subscription as persistent" setzen, damit die Subscription automatisch restartet wird (s. Abb.7).

Nach dem Erstellen der Subscription bietet die Management Console an, im nächsten Schritt die Table Mappings vorzunehmen.

CDC Table Mapping erstellen und konfigurieren

Die CDC Management Console bietet grundsätzlich die Möglichkeit, die Zieltabellen für die Replikation zu erstellen. Für Spiegeltabellen ist das jedoch keine Option, da die Management Console aktuell nicht die spezielle CREATE TABLE-Syntax für Spiegeltabellen erstellen kann.
Alle künftigen Spiegeltabellen müssen also vorneweg erstellt worden sein und werden nun in einer Subskription zusammen spezifiziert.

Table Mapping-Einstellungen können für eine einzelne Tabelle oder für mehrere Tabellen auf einmal durchgeführt werden (s. Abb.8).

Zunächst ein Beispiel für ein "Custom Table Mapping" – hier für Tabelle CUSTOMER im Schema JKUSER (s. Abb.9). Über "Filter Columns" können optional einzelne Spalten von der Replikation ausgenommen werden.

Im darauf folgenden Schritt wird die Zieltabelle spezifiziert, die wie gesagt bereits existieren muss.

Nochmals zur Erinnerung: Die Zieltabelle muss dieselben Spaltennamen und Datentypen verwenden, wie die Quelltabelle!

Zum Schluss muss noch der Primärschlüssel der Shadow Table festgelegt werden, sowie die Replikationsmethode. Für Spiegeltabellen ist hier "Mirror" die einzig mögliche Option.

Um mehrere Spiegeltabellen zu definieren ist die "Multiple One-to-One Mapping"-Methode wesentlich effizienter.

Alle Quelltabellen, denen eine Spiegeltabelle zugewiesen werden soll, können durch Mehrfachauswahl markiert werden. Auch hier können über "Filter Columns" einzelne Spalten von der Replikation ausgenommen werden.

Bei der Zuweisung der Zieltabellen können wie auch beim "Custom Table Mapping" nur existierende Tabellen verwendet werden. Dazu wird das erste Mapping manuell definiert (s. Abb.13 – JKUSER.DATE - SHADOW.DATE), welches dann für die restlichen Tabellen adaptiert wird.

Liegen die Spiegeltabellen im Schema der Originaltabellen, sollte man ein festes Namenssuffix oder -prefix für die Spiegeltabellen verwenden, wie z. B. _SHADOW. Die Management Console ist dann auch hier in der Lage, die restlichen Mappings automatisch zu erkennen.

CDC-Replikation starten

Nach erfolgreichem Table Mapping sind alle Tabellen im Status "Refresh", d. h. nach dem Start der Replikation werden alle Tabellen initial befüllt (s. Abb.15).

Die Replikation wird mit "Start Mirroring" für die gesamte Subscription gestartet. Als "Mirror Method" wird "Continous" eingestellt, wodurch die Tabellen nach dem initialen Refresh inkrementell synchronisiert werden, bis die Replikation explizit gestoppt wird.

In der Monitoring-Perspektive kann der Fortschritt des Refresh beobachtet werden.

Nach dem Refresh startet dann das Mirroring der Spiegeltabellen. Die Latenz wird ab jetzt in der Systemtabelle SYSTOOLS.REPL_MQT_LATENCY aktualisiert und der SQL-Optimierer kann seine Arbeit aufnehmen und geeignete Abfragen auf die Spiegeltabellen umleiten.

Fazit

Spiegeltabellen sind ein interessanter Ansatz um analytische Abfragen in einer OLTP-Umgebung zu beschleunigen, ohne dabei die eigentlichen Transaktionen allzu stark zu beeinflussen. Das Ganze mit einem vertretbaren Aufwand für den DBA.

Autor

Joachim Klassen

Joachim Klassen ist als Consultant und Trainer seit 1999 beim Distributor LIS.TEC GmbH in Ludwigsburg tätig. Dort berät er Partner und ISVs der LIS.TEC GmbH im Bereich IBM Datenbankmanagement Systeme.
>> Weiterlesen
botMessage_toctoc_comments_9210