Verteilte Verarbeitung in in SQL Server 2005

Transcription

Verteilte Verarbeitung in
in SQL Server 2005
Technologie Memo
April 2006
 Dr. Arno Schmidhauser
Verteilte Verarbeitung in SQL Server 2005
Inhalt
1
2
3
4
5
6
7
8
Referenz................................................................................... 3
Einleitung ................................................................................. 3
Lokale Transaktionen.................................................................. 3
Isolationsgrade.......................................................................... 4
Verteilte Transaktionen............................................................... 8
Partitionierung..........................................................................11
Replikation...............................................................................13
Partitionierung und Replikation ...................................................23
Technologie Memo
Arno Schmidhauser
2
1 Referenz
Die folgenden Kapitel beziehen sich auf Microsoft SQL Server 2005, Version 9.00.
2 Einleitung
In diesem Technologie-Memo wird auf verschiendene Aspekte der
Transkationssteuerung in SQL Server 2005 eingegangen. Insbesondere
werden die Möglichkeiten zur Verwaltung verteilter Datenbestände besprochen. Hierzu gehören die Abwicklung verteilter Transaktionen, die Optimierung des Datenzugriffs in verteilten Transaktionen, die Partitionierung
von Tabellen und die Replikation von Daten auf verschiedene DatenbankKnoten, sowie neue Ansätze des Concurrency Control. Es wird nur über
Mechansimen gesprochen, die innerhalb der Datenbank aufgebaut und
konfiguriert werden können, und gegenüber Applikationen, die mit SQLBefehlen auf die Datenbank zugreifen, transparent sind. In vielen Fällen
ist dies als Vorteil anzusehen, da der Data-Tier gegenüber den Applikationen (Business Logic) als einheitliches, konsistentes Gesamtsystem in Erscheinung tritt. Der Nachteil kann darin liegen, dass für kleine Datenbankhersteller nur eingeschränkte Schnittstellen-Module (Minimaler ODBC) zur
Verfügung stehen, welche die Server-to-Server Kommunikation einschränken.
3 Lokale Transaktionen
Explizite Transaktionen werden mit BEGIN TRANSACTION gestartet. Sie
können verschachtelt sein, aber nur das äusserste Commit/Rollback hat
tatsächlich Auswirkungen auf die Datenbank.
Defaultverhalten ist autocommit.
Mit SET IMPLICIT_TRANSACTIONS ON wird auf verkettete Transaktion
umgeschaltet. Das heisst nur commit und rollback werden explizit abgesetzt.
Das Transaktionslog in SQL Server ist eine wesentliche Komponente für

o
o
o
o
Transaktions-Recovery
Incremental Online-Backup
Erzeugen von Snapshot-Datenbanken
Replikation von Daten
Technologie Memo
Arno Schmidhauser
3
4 Isolationsgrade
Beim konkurrierenden Zugriff auf Daten durch mehrere Prozesse spielt die
Art der Zugriffssteuerung eine entscheidende Rolle für die Performance
(Gesamtdurchsatz an Transaktionen) der Datenbank. Die Zugriffssteuerung muss auf Anforderungen Rücksicht nehmen, die teilweise gegeneinander wirken:
Hohe Parallelität aller zugreifenden Prozesse, möglichst wenig Wartesituationen.
Ein Prozess soll durch Änderungen von anderen Prozessen nicht beeinflusst werden. Es dürfen keine Inkonsistenzen entstehen, weil zwei Prozesse gleichzeitig mit der Datenbank arbeiten (Isolation, Serialiserbarkeit).
Möglichst wenig Deadlocks sollen auftreten (Deadlocks sind prinzipiell
unmvermeidlich).
Transaktionssicherheit muss gewährleistet werden, das heisst ein Rollback muss zu jedem Zeitpunkt möglich sein.

Heutige Datenbanksysteme müssen ausserdem immer stärker zwei grundsätzlich verschiedenen Gebrauchsarten zufriedenstellen:
1. Lesen, Ändern, Einfügen, Löschen von Datensätzen in geringem Umfang im Verhältnis zur Datenbankgrösse. Beispielsweise das Einfügen
einer Bestellung in einem Webshop, das Ändern eines Statuseintrages
der Bestellung oder das Hinzufügen einer neuen Bestellposition. Diese
Operationen sind auch unter dem Namen OLTP (On Line Transaction
Processing) bekannt.
2. Lesen eines grossen Teils oder der gesamten Datenbank für Überwachungsaufgaben, für statistische Auswertungen, oder für Backups. Diese Art Operationen sind unter dem Namen OLAP (On Line Analytical
Processing) bekannt.
Der Entwickler oder DBA entscheidet aufgrund obiger Kriterien, mit welchen Isolationsgrad Daten bearbeitet werden. Der SQL-Standard kennt
vier Arten von Isolationsgrad:
Isolationsgrad
SERIALIZABLE
Alle Transaktionen
unterliegen dem SerialisierbarkeitsParadigma)
REPEATABLE
READ (Eine Abfrage
liefert immer dasselbe
Resultat, mit Ausnahme neu hinzukommender Datensätze)
Technologie Memo
Vorteile
Absolute Konsistenzgarantie.
Nachteile
Parallelität klein, Deadlockgefahr gross.
Einmal gelesene Daten
bleiben eingefroren. Parallelität mittel.
Je nach Applikationsart entsteht das Phantom-Problem.
Deadlockgefahr gross. Lesende
Pprozesse behindern schreibende Prozesse erheblich (Livelock möglich).
Arno Schmidhauser
4
READ COMMITTED
(Es werden nur Daten
gelesen, die einem
bestätigen Zustand
entsprechen)
Gelesene Daten sind korrekt, aber nicht eingefroren. Können sofort nach
dem Lesen durch andere
modifiziert werden. Parallelität hoch. Kaum Deadlocks.
READ UNCOMMITTED
(Aktuelle Datenwerte
werden gelesen, unabhängig vom Transaktionszustand)
Es wird gelesen, was da
ist. Leseoperationen werden nie blckiert. Deadlockfrei. Wird Auch als Dirty Read bezeichnet.
Lost Update-Problem kann auftreten und gravierende Inkonsistenzen zur Folge haben.
Berechnungen über mehrere
Abfragen hinweg können inkonsistent sein, weil Daten
zwischen den Abfragen geändert wurden.
Keine Konsistenzgarantie. Gelesene Daten können von einem anderen Prozess, der diese gerade modifiziert hat, gerollbacked werden.
Ob und wie stark die genannten Nachteile auftreten, hängt entscheidend
von der Implementationsart abhängig. Heutige Datenbanksysteme haben
erhebliche Fortschritte in der Behebung dieser Nachteile gemacht. SQLServer 2005 vereinigt einige vorteilhafte Konzepte unter einem Dach. Die
Zugriffsparallelität und die Deadlock-Minimierung konnte dadurch massiv
verbessert werden.
SQL Server 2005 hat für die Kontrolle des konkurrenzierenden Zugriffs
zwei Mechanismen, zum Ersten ein sehr fein steuerbares Locking, und
zum Zweiten einen Datensatz-Versionierung.
4.1 Locking
Locks werden auf Datensätze, IO-Pages und Tabellen gesetzt. Beim Lesen
werden normalerweise Shared Locks auf einzelne Datensätze gesetzt,
beim Schreiben immer Exclusive Locks. Wenn genügend Datensätze betroffen sind, können Locks vom Datenbanksystem automatisch auf Ebene
IO-Page oder Tabelle eskalieren. Die Lockstrategie kann manuell eingestellt werden oder sie wird durch den gewählten Isolationsgrad bestimmt.
Eine manuelle Einstellung wird für einzelne Tabellen im Rahmen eines
SQL-Befehles vorgenommen. Beispielsweise: SELECT * FROM Bestellung
WITH (TABLOCKX). Folgende manuelle Optionen existieren:
NOLOCK, NOWAIT, PAGLOCK, READCOMMITTED, READCOMMITTEDLOCK,
READPAST1, READUNCOMMITTED, REPEATABLEREAD, ROWLOCK, SERIALIZABLE, TABLOCK, TABLOCKX, UPDLOCK, XLOCK.
Achtung: Die Lock-Art (UPDLOCK, XLOCK) kann nur für Lesebefehle geändert werden. Schreiboperationen finden immer mit Exclusive Locks statt.
Ein Update-Lock bewirkt, dass andere Prozesse Daten noch lesen, aber
selber nicht mit einem Update-Lock belegen können. Ein Update Lock ist
dann sinnvoll, wenn ein Prozess die gelesenen Daten später verändern
will. Gegenüber einem Shared Lock liegt der Unterschied in der Vermeidung von Deadlocks zwischen Prozessen, die zuerst Lesen dann Schreiben
wollen.
1
Gesperrte Datensätze überpringen.
Technologie Memo
Arno Schmidhauser
5
SQL-Server arbeitet mit Range-Locks zur Gewährleistung von serialisierbaren Transaktionsabläufen. Range-Locks können vom Typ S-S, S-U, I-N
und X-X sein. Der erste Teil definiert den Lock auf dem Range, der zweite
Teil den Lock auf den eigentlich Datensätzen in diesem Range.
Bestehender Lock
Shared (S)
Update (U)
Exclusive (X)
RangeS-S
RangeS-U
RangeI-N
RangeX-X
S
Yes
Yes
No
Yes
Yes
Yes
No
U
Yes
No
No
Yes
No
Yes
No
X
No
No
No
No
No
Yes
No
Angeforderter Lock
RangeS-S
RangeS-U
RangeI-N
Yes
Yes
Yes
Yes
No
Yes
No
No
Yes
Yes
Yes
No
Yes
No
No
No
No
Yes
No
No
No
RangeX-X
No
No
No
No
No
No
No
Kompatibilitätstabelle für Range-Locks in SQL-Server
4.2 Datensatz-Versionierung
Jede Transaktion bekommt vom Datenbanksystem eine fortlaufende
Nummer zugeteilt. Modifiziert eine Transaktion einen Datensatz, wird vorerst der alte Datensatz aufbewahrt. Dieser alte Datensatz besitzt eine Versionsnummer, nämlich die Nummer der Transaktion, die ihn als letztes
modifiziert oder erzeugt hat. Der neue Datensatz bekommt die laufende
Transaktionsnummer als Versionsnummer zugeteilt. Mit diesem Vorgehen
können zwei nützliche Ziele erreicht werden.

Snapshot Isolation: Eine Transaktion T mit dem Isolationgrad Snapshot
sieht nur Datensätze, die vor ihrem Start committed wurden. Das Datenbanksystem liefert nur Datensätze an T aus, die zwei Bedingungen
erfüllen: 1) die Datensatzversion ist die höchste, noch kleinere Nummer als die Transaktionsnummer der laufenden Transaktion, 2) die Datensatznummer gehört nicht zur Liste der Transaktionen, die beim
Start der Transaktion T laufend waren, ausser der eigenen (Das Datenbanksysteme muss als für T eine Liste der bei Beginn von T laufenden
Transaktionen mitführen). Lost-Update-Problem werden vermieden, indem beim Zurückschreiben die ursprünglich gelesene Datensatzversion
mit der aktuellen Version in der Datenbank verglichen wird. Falls keine
Übereinstimmung besteht, wird die Transaktion zurückgesetzt (Dies
entspricht dem oft genannten Zeitstempel- oder optimistischen Verfahren).

Read Committed Isolation ohne Lesesperren: Für jede SQL-Abfrage
wird vor ihrem Start die letzte vergebene Transaktionsnummer N ermittelt, sowie die beim Start der Abfrage laufenden Transaktionen. Als
Abfrageresultate kommen nur Datensätze in Frage, deren Versionsnummer kleiner ist als N, und deren Versionsnummern nicht in der Liste der laufenden Transaktionen zu Beginn der SQL-Abfrage waren.
Technologie Memo
Arno Schmidhauser
6
4.3 Isolationsgrade in SQL Server
Isolationsgrad im SQL Server
SERIALIZABLE
SNAPSHOT
REPEATABLE READ
READ COMMITTED, DB-Option
READ_COMMITTED_SNAPSHOT auf
ON gesetzt.
READ COMMITTED, DB-Option
READ_COMMITTED_SNAPSHOT auf
OFF gesetzt.
READ UNCOMMITTED
Eigenschaften
Entspricht dem Isolationsgrad SERIALIZABLE
nach ANSI-Standard.
Entspricht dem Isolationsgrad SERIALIZABLE
nach ANSI-Standard. Update-Konflikte werden
erst am Schluss der Transaktion festgestellt, im
Gegensatz zum klassischen Lock-Verfahren.
entspricht REPEATABLE READ nach SQL Standard. Realisierung mit Shared Locks.
entspricht READ COMMITTED nach SQL Standard.
Kein Warten auf Sperrfreigaben und garantiert
deadlockfrei. Lost-Update-Probleme können auftreten.
entspricht READ COMMITTED nach SQL Standard.
Realisierung mit kurzen Lesesperren, deadlockarm, Behinderungen möglich.
entspricht READ UNCOMMITTED nach SQL Standard. Änderungen einer anderen Transaktionen
sind sofort sichtbar.
4.4 Allgemeines

Befehl zum Setzen des Isolationsgrades
SET TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SNAPSHOT | SERIALIZABLE }

Für Snapshot Isolation muss die entsprechenden Datenbankoption gesetzt sein: ALTER DATABASE MYDB SET ALLOW_SNAPSHOT_ISOLATION ON

Für READ COMMITTED mit Datensatzversionierung muss die entsprechenden Datenbankoption gesetzt sein: ALTER DATABASE MYDB SET
READ_COMMITTED_SNAPSHOT ON. Default ist off.

Der Datenbank-Default ist READ COMMITTED. Ein anderer Default kann
nicht direkt in der Datebank gesetzt werden.
4.5 Verteilte Isolation
Für verteilte Transaktionen steht keine Snapshot Isolation zur Verfügung,
weil dafür übergeordnete Transaktions-Nummern erforderlich wären.
Hingegen kann mit SET TRANSACTION ISOLATION LEVEL jeder andere Isolationsgrad gewählt werden.
Technologie Memo
Arno Schmidhauser
7
5 Verteilte Transaktionen
Architektur von SQL Server für verteilte Transaktionen:
5.1 Distributed Transaction Coordinator DTC
Der DTC ist der Transaktionsmanager für verteilte Transaktionen für alle
Arten von OLE-fähigen Resource Managern (Datenbanken). Der DTC ist
über OLE-DB Schnittstellen ansteuerbar. Er kann seinerseits OLE- (SQL
Server, Access, Excel) fähige Resourcen ansteuern. Über eine OLE-ODBC
API sind auch ODBC-fähige Resourcen ansprechbar. Das Mapping der OLE
DB-Transaktionsbefehle in das XA-Protokoll obliegt dem ODBC-Treiber.
DTC kann das 2PC-Protokoll asynchron durchführen, das heisst, alle Resource-Manager parallel ansprechen für prepare-, global commit- oder
global abort-Befehle.
5.2 Ausführung verteilter Transaktionen
Folgende Schritte für die Konfiguration sind vorerst notwendig:
1. Registrierung eines fremden Servers als OLE DB Datenquelle (SQL Management Studio)
2. Zulassung des Servers in der lokalen Datenbank für verteilte Transaktions- und SQL-Aufgaben (Interaktiv oder via sp_addlinkedserver)
3. Bekanntgabe, unter welchem Login auf einem fremden Server gearbeitet werden solll (Interaktiv oder via sp_addlinkedsrvlogin)
Es kann nun beispielsweise folgende Transaktion durchgeführt werden:
BEGIN DISTRIBUTED TRANSACTION;
Technologie Memo
Arno Schmidhauser
8
-- Join einer lokalen und einer entfernten Tabelle
SELECT * FROM Kunde k, remoteserver.remotedb.dbo.Bestellung b
WHERE k.idKunde = b.idKunde
COMMIT;
Mit dem Befehl BEGIN DISTRIBUTED TRANSACTION wird der DTC (Distributed Transaction Coordinator) involviert.
In obiger Abfrage ist allerdings noch erkennbar, dass die BestellungsTabelle auf einem Remote-Server (Server corpus, Datenbank remotedb)
liegt. Dem kann durch Definition eines Synonyms abgeholfen werden. Beispiel:
CREATE SYNONYM Bestellung
FOR remoteserver.remotedb.dbo.Bestellung;
Damit wird nun folgende Befehlssequenz möglich:
BEGIN DISTRIBUTED TRANSACTION;
SELECT * FROM Kunde k, Bestellung b
COMMIT;
5.3 Verteilte Optimierung
Obiges Beispiel wirft sofort die Frage nach der Performance und Optimierung auf, weil der Join über zwei Datenbanksysteme und über ein Netzwerk hinweg stattfindet.
Ein Query Optimierer arbeitet heute nach einem Cost-Based-Verfahren: Er
versucht, den Ausführungsplan mit dem kleinsten Zeitaufwand zu finden.
Die Anzahl Zugriffe auf IO-Pages eines Speichermediums (physical reads)
spielen dabei eine ausschlaggebende Rolle.
Bei SQL-Abfragen, die Zugriffe auf Remote-Tabellen enthalten, geht der
Query-Optimierer davon aus, dass der Transfer von Datensätzen über ein
Netzwerk die teuerste Operation ist, neben dem Zugriff auf lokale IOPages2. Es gilt also in erster Linie, die Anzahl transferierter Datensätze zu
minimieren.
Für Abfragen, welche ausschliesslich Tabellen eine Remote-Datenbank
betreffen, wird die gesamte Abfrage an diese Remote-Datenbank delegiert.
Für Abfragen, welche Tabellen aus verschiedenen Datenbanksystemen
enthalten, wird versucht, möglichst geringe Transferraten zu erreichen.
Beispiel einer zu optimierenden Abfrage:
2
Das Anfordern und der Transport einer IO-Page über ein Netzwerk bei einem anderen Datenbanksystem benötigt ganz grob die doppelte Zeit wie die Anforderung bei einem lokalen IO-System
(Protokollstack-Zeit, IO-Zeit auf dem Remote-Rechner).
Technologie Memo
Arno Schmidhauser
9
SELECT *
FROM Kunde k,
remnode.remdb..Bestellung b,
remnode.remdb..Artikel a
AND
b.idArtikel = a.idArtikel AND k.kundenNr = 3
Kunde sei 10'000 Einträge gross, Bestellung 100'000 und Artikel 1'000.
Beispiel von zwei möglichen Ausführungsplänen:
Plan 1
select
Join
Transfer 100'000 Datensätze
Join
Restriction
Kunde
Artikel
Bestellung
Plan 2
select
Transfer 10 Datensätze
Join
Join
Artikel
Transfer 1 Datensatz
Restriction
Bestellung
Kunde
Graue Rechtecke sind Tabellenzugriffe oder Operationen, die auf dem Remote-Server stattfinden, weisse Rechtecke sind Tabellenzugriffe oder
Operationen die lokal stattfinden. Dicke Pfeile symbolisieren NetzwerkTransfers.
Technologie Memo
Arno Schmidhauser
10
Plan 2 wird als günstiger angesehen, weil wesentlich weniger Datensätze
zwischen Servern transerferiert werden müssen, obwohl zwei Transfers
insgesamt erfolgen.
Die OLE-DB Schnittstelle bietet nur grobe Funktionen für das Ausführen
von Abfragen an. Es können daher nicht direkt Operationenbäume, sondern nur folgende API-Funktionen ausgeführt werden: Remote Query,
Remote Scan, Remote Update, Remote Delete, Remote Insert, RID
Lookup.
Der Query Optimizer muss die ermittelten Operationen-Teilbäume
meist wieder in ein SQL-Query umformulieren und dieses an den Remote-Server übergeben. Der Query Optimizer wird daher auch versuchen, einen möglichsten grossen Teilbaum in einem einzigen Query zu
verpacken. In Plan 2 wäre das beispielsweise: select * from Bestellung join Artikel join AbfrageResultatKunde.
6 Partitionierung
Partitionierung ist eine Art verteiltes System auf Ebene Speichermedien.
Datensätze einer Tabelle werden dabei auf mehreren physikalischen Medien (Disks), aber innerhalb derselben logischen Datenbank untergebracht. Die Aufteilung dient der Parallelisierung von Zugriffen oder der
Vergrösserung des maximalen Diskplatzes. Greifen bestimmte Abfragen
nur auf Datensätze einer Partition zu, kann mit der Partitionierung eine
wesentliche Verbesserung der Performance erreicht werden. Die Verteilung von Datensätzen auf unterschiedliche Disks heisst horizontale, die
Verteilung von Tabellenspalten auf unterschiedliche Disks heisst vertikale
Paritionierung. SQL-Server ermöglicht die horizontale Partionierung (Nur
Enterprise Edition). Die Formulierung von SQL-Abfragen ist natürlich unahbhängig vom Standort der betroffenen Datensätze. Die Partitionierung
beeinflusst nur die Performance, nicht die Logik der Datenbankbenutzung.
Mit der Partitionierung können beispielsweise wenig benützte Daten in die
eine, aktuelle und viel benutzte Daten in eine andere Partition gelegt werden.
Die Definition der Partitionen erfolgt aufgrund von konstanten Wertebereichen. Diese sind nicht dynamisch, dürfen also beispielsweise nicht das Aktuelle Datum enthalten, welches jeden Tag ändert. Jedoch können die
Wertebereiche explizit durch den Administrator weiter gesplittet oder wieder verschmolzen werden. Die Lagerung (oder Umlagerung nach einem
Update-Befehl) eines Datensatzes erfolgt automatisch durch das Datenbanksystem.
Tabelle T1
a
b
c
Partition 1, b <= 100
Technologie Memo
Arno Schmidhauser
11
Partition 2, b > 100, b <= 200
Partition 3, b > 200
Befehle für den Aufbau einer Partitionierung:
-- Erstellen einer Datenbank mit unterschiedlichen File-Gruppe,
-- die später Tabellenpartitionen aufnehmen.
CREATE DATABASE large_db
ON PRIMARY ( name = 'file1', filename = '…', size = 10GB )
FILEGROUP FG1 ( name = 'file2', filename = '…', size = 10GB,
name = 'file3', filename = '…', size = 10GB )
FILEGROUP FG2 ( … )
FILEGROUP FG3 ( … );
-- Partitionierungsfunktion definieren. Diese ist noch unabhängig von einer
-- Tabelle, auf die sie angewendet wird.
CREATE PARTITION FUNCTION PF1 AS RANGE FOR VALUES ( 100, 200 );
-- Zuweisung von physischem Platz zu den Partitionen. Die durch die
-- Partitionierungsfunktionen erzeugten Partitionen werden der Reihe
-- nach den aufgeführten Filegruppen zugewiesen.
CREATE PARTITION SCHEME PS1 AS PARTITION PF1 TO ( FG1, FG2, FG3 );
-- Abbildung einer Tabelle auf das Partitionierungsschema.
CREATE TABLE T1 ( a varchar, b, varchar, c varchar ) ON PS1( c );
Indexe werden entsprechend der Tabellendefinition partitioniert. Grundsätzlich kann ein Index aber auf eine anderes Partionierungsschema gelegt werden als die Basistabelle. Beispiel:
CREATE PARTITION SCHEME PS2 AS PARTITION PF1 ALL TO ( PRIMARY );
CREATE INDEX X1 ON T1( c ) ON PS2( c );
Der Partitionierungsmechanismus dient quasi auch seinem Gegenteil, dem
Clustering von zwei Tabellen. Für das Durchführen von Join-Operationen,
kann es nützlich sein, wenn zu verbindende Datensätze mit demselben
Wert für das Join-Attribut auch in derselben Partition liegen.
CREATE TABLE T2 ( c varchar, d, varchar, e varchar ) ON PS1( c );
Alle Partitionierungsdefinitionen können geändert werden mit ALTER DATABASE, ALTER PARTITION FUNCTION, ALTER PARTITION SCHEME und ALTER TABLE. Allerdings können Änderungen sehr resourcen-intensiv sein, da sie unter Umständen die Umlagerung sehr vieler Datensätze erfordern. Auch ein Update auf Datensätze, der ihre Partitionszugehörigkeit ändert, hat natürlich
eine Umlagerung zur Folge.
Technologie Memo
Arno Schmidhauser
12
7 Replikation
7.1 Warum Replikation?

Skalierbarkeit und Verfügbarkeit erhöhen
Data Warehouses und Reporting von OLTP trennen
Bedienung heterogener Datenbanken (Bsp. Oracle, DB2)
Integration heterogener Datenbanken
Integration von Point-of-Sale Sites (Einsammeln/Konsolidieren/Verteilen)
Mobile Clients bedienen und synchronisieren
7.2 Vorbemerkungen
Verteilte Transaktionen und Replikation sind zwei unabhängige Konzepte.
Mit verteilten Transaktionen können Daten auf mehreren Datenbanksystemen konsistenz gehalten werden. Dabei wird nichts darüber ausgesagt,
ob es sich um Kopien derselben Daten oder um verschiedene Daten handelt. Replikation von Daten kann über verteilte Transaktion oder -heute
praktisch immer- über asynchrone Mechanismen, beispielsweise ein Messageing-System oder einen datenbankeigenen Replikationsprozess nach
dem Publisher/Subscriber-Verfahren abgewickelt werden.
Replikationsarten
Synchronität Æ
Asynchron
Synchron
Lesen überall möglich, Update nur an einem Ort möglich. Master-Slave-Topologie.
Schwache Inkonsistenzen
(kurzzeitig unterschiedlicher
Informationsstand) möglich.
Verteilte Transaktion notwendig. Keine Inkonsistenzen möglich. Wird auch für
Hot-Standbye-Systeme verwendet.
Änderungen von Daten bei
jedem Replikat möglich.
Grundsätzlich schwere Inkonsistenzen möglich. Konfliktauflösungs-Strategie erforderlich.
Verteilte Transaktion notwendig. Keine Inkonsistenzen möglich. Einziger Vorteil: Lesen wird verteilt.
Symmetrie È
Asymmetrisch
Symmetrisch
SQL-Server unterstützt auf vielfältige Weise die asynchrone, sowie teilweise die synchrone Replikation. Bei allen asynchronen Verfahren gelten folgende Grundsätze:
Es werden nur korrekte und bestätigte Daten aus der Quelldatenbank
repliziert. Daten, die sich gerade in Änderung befinden, werden nie für
die Replikation berücksichtigt.
Der Replikationsprozess ändert am Zielort Daten. Diese Änderungen
müssen den allgemeinen Transaktionsregeln (ACID-Eigenschaften) un-
Technologie Memo
Arno Schmidhauser
13
terliegen. Ein unvorhergesehen abgestürzter Replikationsprozess darf
keine Inkonsistenzen zurücklassen. Der Replikationsprozess muss darauf Rücksicht nehmen, dass die Daten während der (Erneuerungs-)
Replikation durch andere Benützer in Gebrauch sind (mindestens lesend). Der Replikationsprozess führt also eine eigene Transaktion gegen die Zieldatenbank aus, die dem Concurreny Control unterliegt.
SQL Server Lösungen
Zeitliche Koordination Æ
Asynchron
Synchron
Symmetrie È
Snapshot-Replikation
Asymmetrisch
Symmetrisch
Zweiseitig transaktionale Replikation mit Message-Queue
Merge-Replikation
Transaktionale Peer-to-Peer
Replikation (Keine Konfliktauflösung)
Einseitig transaktionale
Replikation mit Two Phase
Commit
Zweiseitig transaktionale
Replikation mit Two Phase
Commit
7.3 Publisher/Subscriber-Prinzip
Die Grundlage zum Festlegen der Replikationstopologie ist eine Publisher/Subscriber-Prinzip. Dieses legt fest, wer von wem welche Information
bezieht.
Eine Publikation hat einen Namen. Die Publikation kann über diesen
Namen abonniert (subscribed) werden. Eine Publikation ist eine Sammlung von Artikeln.
Ein Artikel ist typischerweise eine Tabelle, die sowohl bezüglich der Datensätze, wie der ausgewählten Spalten eingeschränkt sein kann. Die
Datensatz-Einschränkung findet über eine WHERE-Klausel statt. Eine
Tabelle kann nur publiziert werden, wenn sie einen Primärschlüssel besitzt. Ein publizierter Artikel kann auch eine Stored Procedure, eine User Defined Function oder eine View sein.
Eine Subskription bezieht sich auf eine Publikation. Die Subskription
wird auf dem Server definiert, der die Daten haben will.

7.4 Replikationarten von SQL Server
Es werden folgende drei Replikationsarten unterschieden:
Technologie Memo
Arno Schmidhauser
14
7.4.1 Snapshot-Replikation
Von einer Publikation wird ein kompletter Snapshot aller Daten, inklusive
Schema-Definition der zugehörigen Artikel (Tabellen, Views), erstellt. Dieser Snapshot wird auf das Filesystem oder auf einem FTP-Server bereitgestellt. Der Snapshot kann in einem Klartextformat erstellt werden und ist
damit sehr robust gegen Details der Konfiguration in der Zieldatenbank.
Der Snapshot-Agent ist für die Erstellung verantwortlich. Er kann den
Snapshot einmalig (respektive durch explizite Auslösung) oder periodisch
erstellen. Der Distribution-Agent (oder Merge-Agent) lädt den Snapshot in
die Zieldatenbank, gemäss Einstellungen entweder manuell oder nach
Schedule. Die Snapshot-Replikation stellt die geringsten Anforderungen an
die Datenstruktur, beispielsweise sind keine Primärschlüssel in den Tabellen erforderlich. Sie ist ausserdem die Ausgangslage für die transaktionale
und die Merge-Replikation. Die Snapshot-Publikation ist ihrer Natur nach
eine asynchrone, asymmetrische Replikation.
Achtung: Snapshot-Replikation hat nichts mit Snapshot Isolation3 zu tun.
Eine Snapshot-Replikation erfordert umfangreiche Locks auf der publizierten Daten (Tabelleninhalt und Schemainformation) während der ganzen
Erstellung des Snapshots. Es wird also ein transaktionskonsistentes (serialiserbares) Abbild der publizierten Objekte erzeugt.
Snapshot-Replikation
7.4.2 Transaktionale Replikationen
7.4.2.1 Einseitig transaktionale Replikation
Ausgehend von einer einmaligen Snapshot-Replikation (Initialisierungsphase) wird im Wesentlichen das Transaktionlog vom Publisher beim
3
Snapsho- Backup und Database-Snapshot haben ebenfalls nichts mit Snapshot Isolation zu tun.
Snapshot-Backups und Datenbank-Snapshots sind zwar transaktionskonsistent, werden aber nach
dem Copy-on-Write-Verfahren erstellt: Von zu modifizierenden Seiten wird ab Beginn des Backups/Snapshots vorgängig eine Kopie erstellt zuhanden des Backup-Prozesses. Von Seiten, die bei
Backup-Start bereits in Gebrauch waren, wird aus dem Logfile der originalen Zustand wiederhergestellt.
Technologie Memo
Arno Schmidhauser
15
Subscriber nachgespielt. Es handelt sich um eine Art Simulation der Publisher-Transaktionen beim Subscriber. Die Vorteile dieses Verfahrens sind:
Transaktionstreue: Erfordert eine Transaktion die Einhaltung von
Constraints oder löst sie bei jeder Änderungsbefehlen Trigger aus, so
werden diese 1:1 in den replizierten Datenbanken nachgespielt.
Die transaktionale Replikation ist ausgelegt für hohe Performance und
hohe Änderungsraten in der Publisher-Datenbank. Sie hat eine kleine
Latenzzeit, das heisst, die Propagierung der Änderungen erfolgt in kurzen Zeitabständen (1 Sekunde).
Diese Replikationsart arbeitet asynchron und asymmetrisch (unidirektional). Es wird bei dieser Replikationsart ausserdem davon ausgegangen,
dass die Netzwerkverbindungen aktiv und stark sind. Für nicht immer
verfügbare Datenbanken ist die Merge Replikation anzuwenden.
Die transaktionale Replikation wird durch zwei Prozesse, den LogReaderAgent, und den Distribution-Agent kontrolliert. Der erste liest Transaktionen vom Logfile des Publishers und spielt sie in die Distributionsdatenbank, der zweite spielt sie von der Distributionsdatenbank zu den Subscribern. Der Distribution-Agent kann im Push-Vefahren arbeiten, wenn er auf
der Publisher-Engine (oder Distribution Engine) läuft, oder er kann im
Pull-Verfahren auf der Subscriber-Engine laufen.
Einseitig transaktionale Replikation, asynchron
7.4.2.2 Zweiseitig transaktionale Replikation, synchron
Prinzip wie normale transaktionale Replikation, aber mit der Möglichkeit
von Änderungen beim Subscriber. Die Änderungen werden, ausgelöst
durch einen zusätzlichen Trigger auf den replizierten Tabellen, synchron
an den Publisher propagiert, das heisst mit einem Two-Phase-Commit ProTechnologie Memo
Arno Schmidhauser
16
tokoll4. Sie ist damit frei von Konsistenzkonflikten. Vom Publisher zu den
anderen Subscribern werden die Änderungen wie bei der einseitigen
Replikation propagiert. Wenn die Subscriber unter sich disjunkte Datenmengen haben und nur gegenüber dem Publisher gemeinsame Daten,
dann entspricht dies einer vollständig synchronen Replikation.
Zweiseitig transaktionale Replikation, synchron
7.4.2.3 Zweiseitig transaktionale Replikation, asynchron
Prinzip wie normale transaktionale Replikation, aber mit der Möglichkeit
von Änderungen beim Subscriber. Die Änderungen werden asynchron propagiert über eine Replikations-Queue in der Subscriberdatenbank. Die
Messsages in dieser Queue sind die aufgezeichneten ReplikationsTransaktionen. Wird ein Datensatz in zwei oder mehr Replikaten gleichzeitig geändert, tritt beim Transfer dieser Änderung ein Konflikt auf. Es können drei Strategien für die Konfliktlösung eingestellt werden: a) immer die
Version des Publishers behalten, b) die Version des Subscribers behalten,
c) die Version des Publishers behalten und den Subscriber mit neuem
Snapshot des Publishers initialisieren. Wird die Version des Subscribers
behalten, entstehen gewisse Zufälligkeiten, wenn ein Datensatz bei mehreren Subscribern geändert wurde: Der Subscriber welcher zuletzt abgleicht, gewinnt über alle anderen Subscriber, da die absolute Zeit von
Änderungen nicht berücksichtigt wird.
4
Isolation Level READ COMMITTED.
Technologie Memo
Arno Schmidhauser
17
Zweiseitig transaktionale Replikation, asynchron
Wie merkt der Replikationsmechanismums, dass ein Konflikt aufgetreten
ist?
In einer publizierten Tabelle wird vom System ein neues Attribut eingefügt
mit dem Namen MSrepl_tran_version und diesem mit newid() ein global eindeutiger, zufälliger Wert zugeteilt (Dieser Wert wird nicht als Primärschlüssel, sondern nur als Versionenkennzeichnung verwendet). Bei
jeder Änderung des Datensatzes wird per Trigger diesem Attribut ein neuer Wert zugewiesen. Bei der Initialisierung einer replizierten Tabelle haben
korrespondierende Datensätze im Publisher und in den Subscribern denselben Wert. Wird nun beispielsweise auf dem Subscriber ein Datensatz
geändert, und sein Transaktions-Log an die Replikations-Queue geschickt,
passiert dort folgendes: Es wird die alte Versionenkennzeichnung im Transaktionlog mit der aktuellen Versionenkennzeichnung in der PublisherTabelle verglichen. Ist sie gleich, wurde im Publisher der Datensatz nicht
geändert und kann von der Queue (also eigentlich vom Subscriber) in den
Publisher übertragen werden. Der neue Wert der Versionenkennzeichnung
im Transaktionslog wird zum aktuellen Wert in der Publisher-Tabelle. Ist
der alte Eintrag im Transaktionslog nicht identisch mit dem aktuellen Wert
in der Publisher-Tabelle, wurde letztere entweder direkt oder durch einen
vorgängigen Abgleich mit einem anderen Subscriber geändert und es besteht ein Konflikt. Somit kommt eine der drei Konfliktlösungsmechanismen
kommt zum Zug.
7.4.2.4 Transaktionale Peer-to-Peer Replikation
Jede beteiligte Datenbank ist gleichzeitig Publisher und Subscriber. Es wird
asynchron repliziert und zwar in einer N:N Strategie. Allfällige Konflikte
werden nicht detektiert. Der Vorteil dieser Architektur liegt in einer hohen
Skalierbarkeit für Leseoperationen, zum Beispiel im Rahmen von Datawarehouse-Lösungen. Das Propagieren von Änderungen ist aufwändig, da
mit N2 wachsend. Während der Initialisierung darf keine Aktivität auf der
Datenbank stattfinden.
Technologie Memo
Arno Schmidhauser
18
Peer-to-Peer Replikation
7.4.3 Merge-Replikation
Die Merge-Replikation ist für folgende Situationen ausgelegt:
Replikation und Abgleich von Datenbanken, die zeitweise offline betrieben werden.
Änderungen an den replizierten Daten sind sowohl auf dem Publisher
wie auf den Subscribern möglich.
Daten werden zu einem bestimmten Zeitpunkt repliziert, dann offline
bearbeitet und später wieder abgeglichen.
Der Abgleich zwischen den Replikation kann zu unterschiedlichsten
Zeitpunkten stattfinden.
Beim Abgleich zwischen den beteiligten Replikaten sind nur BruttoÄnderungen von Interesse, also nur der Zustand der Daten unmittelbar
vor dem Abgleich.
Die Merge-Replikation ist vielseitig konfigurierbar:
o Transfer bidirektional oder unidirektional
o Der Abgleich der Daten kann auf Ebene Feld, physischer Datensatz oder logischer Datensatz (z.B. Bestellung inkl. Bestellpositionen) erfolgen.
Der Ablauf der Merge-Replikation besteht aus einer Initalisierungsphase
und einer Betriebsphase. In der Initialisierungsphase wird durch einen
Snapshot-Agent ein Snapshot der Publisher-Datenbank erstellt und in den
Subscriber-Datenbanken installiert. In der Betriebsphase werden durch
einen Merge-Agent periodisch die Änderungen bei den beteiligten DatenTechnologie Memo
Arno Schmidhauser
19
banken eingesammelt, konsolidiert und zurückgespielt. Die PublisherDatenbank hat einerseits eine Drehscheibenfunktion für die Durchführung
des Abgleichs: Änderungen von Subscribern werden zum Publisher propagiert, von dort zu allen anderen Subscribern. Auf dem Publisher können
aber andererseits auch direkt Änderungen an den Datentabellen vorgenommen werden.
Merge-Replikation
Eigenschaften der Merge-Replikation

Die einzelnen Replikate sind untereinander praktisch unabhängig.
Es können Abgleich-Konflikte auftreten, die aufgelöst werden müssen.
Für diese Konfliktauflösung stehen verschiedenste vorprogrammierte
Varianten zur Verfügung (Prioritäten, Zeitstempel, Sum/Min/Max/AvgWert usw.)
Die Merge Replikation ist für eine hohe Funktionalität, aber für kleine
Datenmengen ausgelegt. Die Performance ist kritisch, da umfangreiche
Hilfsdaten gesammelt werden und ein N:N – Abgleich unter allen beteiligten Datenbanken stattfindet. Die abzugleichenden Datensätze werden einzeln behandelt, so dass pro Datensatz mindestens ein SQLUpdate-, Insert- oder Delete-Befehl für jede abzugleichende Datenbank
notwendig ist, neben zahlreichen Kontrollabfragen und –aktionen.
7.4.3.1 Hilfsstrukturen für die Merge-Replikation
Für den Betrieb der Merge-Replikationen werden einige Hilfsstrukturen
benötigt:

Für den Abgleich muss jeder Datensatz in einer publizierten Tabelle
global identifizierbar sein. Es wird hierzu, falls es noch nicht besteht,
ein Attribut namens rowguid vom Typ uniqueidentifier hinzugefügt
und mit dem Defaultwert newsequentialid() belegt.
Technologie Memo
Arno Schmidhauser
20

Für jede publizierte Tabelle wird ein Insert-, ein Update- und ein Delete-Trigger erzeugt. Diese Trigger zeichnen Änderungsinformation in
folgenden Hilfstabellen auf:
Tabelle MSmerge_contents
Wird durch den Update- und Insert-Trigger benützt. Enthält Tabellenkürzel und rowguid eines geänderten Datensatzes. Pro Nutzdatensatz
wird hier ein Kontrolldatensatz geführt. Die eigentlichen, aktuellen Datenwerte sind in der Nutzdatentabelle zu finden. Die Tabelle enthält
ausserdem die Nummer des Abgleichpaketes ("Generation").
Tabelle MSmerge_tombstone
Wird durch den Delete-Trigger benützt. Wird ein Datensatz aus der
Nutzdatentabelle gelöscht, wird hier das Tabellenkürzel und die rowguid eingetragen. Kommt ein gelöschter Datensatz auch in MSmerge_contents vor, wird er dort gelöscht. Die Löschung hat also lokal
Vorrang vor der Änderung5. Die Tabelle enthält ausserdem die Nummer
des Abgleichpaketes ("Generation").
Tabelle MSmerge_genhistory
Enthält Information über alle Abgleichpakete ("Generations"), die von dieser
Datenbank stammen, oder an diese geschickt wurden. Ein Abgleichpaket ist
die Menge aller zum Abgleich anstehenden Datensätze zu einem bestimmten Zeitpunkt, wo der Merge-Agent aktiv wird. Ein Abgleichpaket ist offen
(wird momentan gefüllt durch die Aktivität auf der Datenbank), geschlossen
(wird durch den Merge-Agent nun abgeglichen, oder fremd (wurde dieser
Datenbank durch den Merge-Agent zugestellt).
Tabelle sysmergesubscriptions
Beim Subscriber enthält diese Tabelle einen Datensatz für den Subscriber. Beim Publisher enthält diese Tabelle einen Datensatz für den Publisher und einen für jeden Subscriber. In jedem Datensatz wird die
Nummer des letzten gesendeten und des letzten empfangenen Abgleichpaketes aufgezeichnet. Damit kann festgestellt werden, bei welchem Abgleichpaket der Merge-Agent seine Arbeit aufnehmen soll.
Daneben gibt es zahlreiche weitere, hier nicht aufgeführte Hilfstabellen und
Attribute zur Steuerung der Replikation.
7.4.3.2 Ablauf der Merge-Replikation
Für jeden Subscriber gibt es einen Merge-Agent, der manuell, periodisch
oder nach einem bestimmten Fahrplan einen Abgleich zwischen seinem
Publisher und seinem Subscriber vornimmt. Der Merge-Agent kann sowohl
unter der Publisher-Engine (Push), wie unter der Subscriber-Engine laufen
5
Hat jedoch beispielsweise ein anderer Subscriber den Datensatz geändert und hat dieser bei der
Konfliktauflösung Priorität, so wird der Datensatz wieder installiert.
Technologie Memo
Arno Schmidhauser
21
(Pull). Der Abgleich läuft immer paarweise zwischen dem Publisher und je
einem Subscriber.
Wird, hypothetisch gesehen, während diesen paarweisen Abgleichen auf
keiner Datenbank eine Änderung vorgenommen, so erreichen schliesslich
alle Replikate einen identischen Zustand. In einem Umfeld, wo während
den Abgleichen aber sofort wieder Änderungen stattfinden, wird durch diesen sequentiell paarweisen Abgleich eventuell gar nie ein global einheitlicher Zustand erreicht (Die Replikation konvergiert nicht). Dies ist eine Eigenschaft jeder asynchronen Replikationstechnologie.
Bei Beginn der Replikation schliesst der Merge-Agent beim Subscriber (oder allenfalls beim Publisher) das offene Abgleichpaket. Nachfolgende Änderungen beim Subscriber kommen in das nächste Abgleichpaket. Der Inhalt von MSmerge_contents und MSmerge_tombstone (als Join mit von
MSmerge_genhistory) wird an den Publisher gesendet. Pro Zeile dieserTabellen werden dann insert, delete oder update-Befehle beim Publisher
ausgeführt, nachdem eine Konfliktprüfung vorgenommen wurde. Dasselbe
Prozedere findet gegebenfalls auch in die umgekehrte Richtung, vom Publisher zum Subscriber, statt. Wurde ein Abgleichpaket vom Subscriber
zum Publisher geschickt, wird dieses solange aufbewahrt, bis es vom Publisher gegen alle anderen Subscriber abgeglichen werden konnte. Dabei
kann es zu Konflikten kommen, beispielsweise indem Subscriber A einen
Datensatz x mit dem Publisher abgleicht, dann der Publisher mit dem
Subscriber B den Abgleich von x durchführen will. Dabei wird entdeckt,
dass B den Datensatz x seinerseits bereits geändert hat. Aufgrund einer
Prioritätenregelung gilt die Änderung von B. Damit muss die Änderung von
B im Publisher durchgeführt werden. Dies gilt als Datenänderung im Publisher, die zum Subscriber A propagiert werden muss beim nächsten Abgleich.
Grundsätzlich können mehrere Merge-Agents gleichzeitig laufen, beispielsweise weil sie auf den gleichen Zeitpunkt starten und eine gewissse
Zeit dauern. Da mit dem Isolationsgrad READ COMMITTED gearbeitet
wird, sind prinzipiell Lost Update Probleme denkbar, beispielsweise bei einer Konfliktauflösung, wo der grössere von zwei Datenwerten über den
Gewinner des Abgleichs entscheidet. Parallel laufende Merge-Agents können jedoch ausgeschlossen werden, durch Einstellung der maximalen Anzahl gleichzeitiger Merge-Agents auf 1 (@max_concurrent_merge), beim
Publisher.
7.4.3.3 Konflikterkennung und -auflösung
Ein Konflikt ist dann vorhanden, wenn sowohl für den Publisher wie für
den Subscriber in den Tabellen MSmerge_contents und MSmerge_tombstone Einträge für denselben Datensatz vorhanden sind. Die Konflikte können nach einer bestimmten Voreinstellung oder nach einem
selbstdefinierten Verfahren aufgelöst werden.
Folgende Möglichkeiten der Konfliktauflösung können ausgewählt werden:
Technologie Memo
Arno Schmidhauser
22

Feste Priorität für jeden Subscriber und den Publisher. Im Konfliktfall
gilt die Änderung der Datenbank mit der höchsten Priorität.
Erster Subscriber gewinnt.
Der Datensatz mit dem grössten/kleinsten Wert einer bestimmten
Spalte gewinnt.
Der Datensatz mit dem kleinsten/grössten Datumswert in einer bestimmten Spalte gewinnt.
Der jeweilige Subscriber gewinnt immer.
Subscriber kann nur Änderungen empfangen, nicht ausliefern.
Subscriber kann nur Änderungen ausliefern, nicht empfangen.
Beim feldbezogenen (statt datensatzbezogenen) Abgleich wird im Konfliktfall der Mittelwert oder die Summe der konfliktierenden Werte gebildet.
Folgendes Beispiel soll den Verlauf eines Abgleiches illustrieren: Tabelle
mit Best-Laufzeiten von Sprintern. Vom jedem Datensatz existieren drei
Replikate. An den zwei Subscriber-Replikaten wird je eine Änderung vorgenommen, bevor der Abgleich-Prozess beginnt. Die Konfliktlösungsstrategie wurde so gewählt, dass jeweils der Datensatz mit dem kleinsten
Wert übernommen wird.
Datensatz mit Bestzeit auf 100 m
Startzustand der Replikate
Änderung auf Subscriber 1
Änderung auf Subscriber 2
Abgleich Publisher / Subscriber 1
Endzustand nach 3 Abgleichen
Publisher
[Hans, 12.7]
[Hans, 12.7]
[Hans, 12.7]
[Hans, 11.5]
[Hans, 10.9]
[Hans, 10.9]
[Hans, 10.9]
Subscriber 1
[Hans, 12.7]
[Hans, 11.5]
[Hans, 11.5]
[Hans, 11.5]
[Hans, 11.5]
[Hans, 10.9]
[Hans, 10.9]
Subscriber 2
[Hans, 12.7]
[Hans, 12.7]
[Hans, 10.9]
[Hans, 10.9]
[Hans, 10.9]
[Hans, 10.9]
[Hans, 10.9]
Zu beachten ist, dass ein global einheitlicher Zustand erst nach drei Abgleichschritten entsteht.
8 Partitionierung und Replikation
Das Konzept der lokalen Partitionierung kann sinngemäss auf Replikationen erweitert werden, indem mit Hilfe der Merge-Replikation ein Filter definiert wird, der dazu führt, dass jeder Subscriber disjunkte Teilmengen
der Originaldaten bekommt. Eine Publikation kann in SQL-Server beispielsweise mit einem Filter der Form where name = HOST_NAME().
HOST_NAME() muss im Filter vorkommen. Der Rückgabewert von
HOST_NAME() kann aber beim Subscriber, resp. beim Merge-Agent
(@hostname-Parameter) für diesen Subscriber angegeben werden .
Technologie Memo
Arno Schmidhauser
23
Auch eine vertikale Partitionierung kann vorgenommen werden, indem unterschiedliche Publikationen mit einem unterschiedlichen Set von publizierten Spalten definiert werden. Alle nicht publizierten Spalten müssen entweder den null-Wert zulassen, einen Defaultwert haben oder ein identityZähler sein. Damit ergeben sich keine Einschränkungen bezüglich dem
Einfügen neuer Datensätze beim Subscriber.
Technologie Memo
Arno Schmidhauser
24