SQL Server

Hohe Verfügbarkeit für SQL Server

Zach Nichter

Kurz zusammengefasst:

• Spiegelung
• Datenbanksnapshots
• Protokollversand
• Clusterbildung
• Replikation

Laden Sie den Code für diesen Artikel herunter: NichterHA2007_03.exe (151KB)

Hohe Verfügbarkeit ist ein Begriff, den jeder Datenbankadministrator verstehen sollte. Er bezieht sich auf die Reaktionsfähigkeit und die Verfügbarkeit eines Systems. Hohe Verfügbarkeit kann in einigen Situationen eine in Sekunden gemessene Antwortzeit bezeichnen, in anderen Situationen ist jedoch die Angabe einer Antwortzeit in

Bruchteilen einer Sekunde erforderlich. Während meiner Beratertätigkeit in einem Unternehmen war die Angabe von Roundtrip-Antwortzeiten für SQL-Abfragen in Millisekunden erforderlich. Wenn die Antwort diese Beschränkung überschritt, wurde das Datenbanksystem als inaktiv betrachtet, und der Webserver stellte eine Verbindung zum nächsten verfügbaren Datenbankserver her.

Heutzutage werden immer schnellere Anwendungen gefordert. Wenn Sie über ein umfangreiches Wissen über hohe Verfügbarkeit und schnelle Antwortzeiten verfügen, werden Sie auch in Zukunft in der Lage sein, datenabhängige Anwendungen genau zu planen.

Glücklicherweise besitzt SQL Server™ 2005 eine Anzahl von Optionen, mit denen die Verfügbarkeit, einschließlich Replikation, Clusterbildung, Datenbankspiegelungen, Datenbanksnapshots und Datenbankprotokollversand, verbessert werden kann. In den folgenden Ausführungen werden diese Features genauer betrachtet. Darüber hinaus erhalten Sie Entscheidungshilfen, mit denen Sie die für Ihre Umgebung geeigneten Features auswählen können. Betrachten Sie Abbildung 1. Hier werden die Verfügbarkeitsoptionen in SQL Server 2005 beschrieben.

Figure 1 Optionen für hohe Verfügbarkeit

Definieren hoher Verfügbarkeit

Eines Ihrer ersten Ziele beim Planen einer Anwendung mit hoher Verfügbarkeit besteht darin, zu definieren, was dies für Ihre spezielle Umgebung bedeutet. Für einige Organisationen bedeutet hohe Verfügbarkeit das Vorhandensein von mit der Produktionshardware vergleichbarer redundanter Hardware. Dabei müssen die Daten sowie die Hardware eine Betriebszeit und Verfügbarkeit von 99,995 Prozent oder mehr haben. Andere Organisationen beziehen den Begriff möglicherweise nur auf die hohe Verfügbarkeit von Daten. Für sie steht die Leistung auf Produktionsebene im Falle eines erforderlichen Failovers im Hintergrund. Wenn Sie die richtige Lösung für Ihre Situation bestimmen möchten, müssen Sie den Begriff der hohen Verfügbarkeit definieren.

Darüber hinaus ist es erforderlich, dass Sie die Arten möglicherweise eintretender Ausfälle identifizieren und deren Auswirkungen auf Ihre Vereinbarungen zum Servicelevel (Service Level Agreement, SLA) angeben. Zu den Ausfällen, die Ihre Verfügbarkeit betreffen können, gehören geplante und nicht geplante Ausfälle sowie eine herabgesetzte Leistung.

Bei einem geplanten Ausfall handelt es sich in der Regel um ein geplantes Wartungsfenster, über das die Benutzer im Voraus informiert werden. Ein ungeplanter Ausfall ist normalerweise das Ergebnis eines Hardware- oder Softwarefehlers, infolge dessen auf Ihre Daten nicht mehr zugegriffen werden kann. Eine Leistungsbeeinträchtigung kann ebenso Ausfälle verursachen und wird häufig in Endbenutzerantwortzeit gemessen. Diese wird gewöhnlich im Voraus vom Unternehmen sowie von der IT-Organisation in einer bestimmten Form des SLA festgelegt.

Neben dem Identifizieren von potenziellen Quellen für Ausfälle müssen Sie die Aktivitätsstufe Ihrer Daten bestimmen. Legen Sie dabei fest, ob sie immer online sein müssen oder gelegentlich z. B. auch offline sein können. Darüber hinaus muss die Entscheidung gefällt werden, ob die Verfügbarkeitsoption den gleichen geografischen Ort oder einen Remotestandort betreffen. Budgeteinschränkungen spielen wahrscheinlich für Ihre Entscheidung auch eine Rolle. Im Folgenden wird jede Verfügbarkeitsoption erläutert.

Datenbankspiegelung

Bevor die Datenbankspiegelung eingehend besprochen wird, sollen einige Begriffe definiert werden.

Der Prinzipal ist der primäre Produktionsserver, auf dem die Datenbank untergebracht ist, die die Transaktionsprotokolle kontinuierlich an den Spiegelserver und die Datenbank sendet.

Der Spiegel ist der sekundäre Server, auf dem die Sicherungskopie der Datenbank gespeichert ist. Die Spiegelkopie wird mit der Prinzipaldatenbank einheitlich synchronisiert.

Die Rolle gibt den Zweck des bestimmten Servers an, d. h. ob er als Prinzipal oder Spiegel dient.

Der Zeuge stellt die Instanz dar, die den Prinzipal und die Spiegelserver überwacht, während sie ihre Aufgaben durchführen. Er kann ein automatisches Failover initiieren.

Ein Partner kann entweder der Prinzipalserver oder der Spiegelserver sein.

In einer typischen Umgebung wird die Prinzipaldatenbank auf der Prinzipalinstanz gesichert, und die Sicherung wird auf der Spiegelinstanz wiederhergestellt (siehe Abbildung 2). Nachdem die Datenbank wiederhergestellt wurde, muss die Spiegelung auf dem Prinzipalserver entweder mithilfe des Eigenschaftenfensters der Prinzipaldatenbank in SQL Server Management Studio (SMSS) oder mithilfe von T-SQL-Skripts eingerichtet werden.

Abbildung 2** Datenbankspiegelungsarchitektur **(Klicken Sie zum Vergrößern auf das Bild)

Nachdem die Spiegelung konfiguriert und die Spiegelungssitzung eingerichtet wurde, werden der Prinzipal und die gespiegelten Datenbanken synchronisiert. Die Prinzipaldatenbank sendet anschließend ihr Transaktionsprotokoll der Ereignisse, die seit der letzten Anwendung der Sicherung auf den Spiegel aufgetreten sind. Der Spiegel erhält das Protokoll und versucht, es so schnell wie möglich anzuwenden. Wenn Sie SQL Server 2005 Enterprise Edition verwenden, handelt es sich um einen Multithreadprozess, ansonsten ist es ein Singlethreadvorgang. Sobald diese Protokolle auf den Spiegel angewendet wurden, werden die Datenbanken als synchronisiert betrachtet und bleiben synchronisiert, bis die gespiegelte Sitzung unterbrochen wird.

Während Clients neue Transaktionen ausführen, führt der Prinzipalserver die Transaktionen anhand der Prinzipaldatenbank aus. Dabei sendet er die Transaktionsprotokolldatensätze aus der Prinzipaldatenbank an das Wiederherstellungsprotokoll (bzw. an die Protokollwarteschlangen) der gespiegelten Datenbank. Hier wird es übernommen und auf die gespiegelte Datenbank angewendet. Nachdem die Transaktion angewendet und auf die Spiegeldatenbank übertragen wurde, wird an den Prinzipal eine Antwort mit der Nachricht gesendet, dass die Transaktion auf den Spiegel übertragen wurde. Der Prinzipal bestätigt erst weitere Transaktionen, die möglicherweise im System ankommen, wenn die Bestätigung vom Spiegel eingegangen ist.

Falls ein Fehler auftritt, kann der Spiegel einen Autofehler initiieren. Der Zeuge unterstützt dabei den Prozess, indem er bestimmt, ob die Prinzipaldatenbank verfügbar ist. Sobald ein Fehler auftritt, muss der aktuelle Spiegelpartner definiert werden, bevor er wieder Prinzipalpartner werden kann. Nachdem die Probleme mit dem Spiegelpartner gelöst wurden, wird die Verschiebung zurück auf den Spiegelpartnerserver initiiert, und die Datenbanken werden wieder synchronisiert. Sobald sie synchronisiert sind, kann die Spiegelungssitzung erneut beginnen.

Dieser spezielle Spiegelungsmodus ist ein Hochsicherheitsmodus, der synchrone Transaktionsvorgänge bietet, indem Transaktionssicherheit aktiviert wird. Es ist jedoch kein Zeuge erforderlich, weil das automatische Failover nicht genutzt wird. Alle Failovers werden manuell initiiert. Ein weiterer Spiegelungsmodus bietet synchrone Transaktionsvorgänge: der Modus für hohe Verfügbarkeit. Er erfordert nicht nur eine aktivierte Transaktionssicherheit, sondern auch, dass im Fall eines Fehlers ein Zeuge für das automatische Failover verwendet wird.

Der dritte und letzte für die Spiegelung verfügbare Modus ist der Modus für hohe Leistung. Im diesem Modus muss die Transaktionssicherheit deaktiviert werden, wodurch die asynchrone Betriebsunterstützung zugelassen wird. Dies wiederum ermöglicht die Übertragung der Transaktionen auf den Prinzipalpartner, ohne dass darauf gewartet werden muss, bis der Transaktionsdatensatz auf den Spiegel geschrieben wurde. Der Modus für hohe Leistung benötigt in der Konfiguration keinen Zeugen.

Beachten Sie, dass die Spiegelung die gleiche Version von SQL Server auf dem Prinzipal und auf dem Spiegel benötigt. Für den Zeugen kann jedoch SQL Server Express Edition verwendet werden. Darüber hinaus ist es wichtig, dass sich die Prinzipaldatenbank im vollständigen Wiederherstellungsmodus befindet.

ADO.NET 2.0 ist in SQL Server 2005 integriert und enthält Unterstützung für die Datenbankspiegelung. Des Weiteren wird ein transparentes Failover für die Anwendung zur gespiegelten Umgebung zur Verfügung gestellt. Dadurch erhält die ADO.NET-Anwendung eine Methode für ein automatisches Failover ohne zusätzliche Codierung oder Konfiguration, wenn eine Verbindung zur Prinzipaldatenbank nicht hergestellt werden kann. Die Konfiguration ist so einfach wie die Angabe eines gemeinsamen Benutzers für die beiden Umgebungen und des Failoverpartners in der Verbindungszeichenfolge. Hier sehen Sie ein Beispiel für eine ADO.NET-Verbindungszeichenfolge, die den Failoverpartner für die gespiegelte Datenbankumgebung identifiziert:

"Provider=SQLNCLI.1;Data Source=MirrorDB;Failover Partner=SQL03;
 Initial Catalog=AdventureWorks;
Persist Security Info=True;User ID=TestUser; Password=TestPswd; Pooling=True;
Connect Timeout=5;Application Name=ADOMirrorTest"

Die Datenbankspiegelung kann je nach Anwendung und Datenanforderungen für Ihr Unternehmen eine geeignete Option sein. Sie sollten jedoch ein paar Dinge beachten, um eine optimale Leistung sicherzustellen. Sie sollten zum Beispiel überlegen, wie hoch die Transaktionsrate des Systems oder die Menge der Datenänderung ist. Wenn Sie Datenbankspiegelungen einsetzen möchten, muss eine ausreichende Bandbreite und Netzwerkgeschwindigkeit gewährleistet sein, um die Datenmengen und die Transaktionsverarbeitungsrate bewältigen zu können. Bedenken Sie auch die Sättigung der Verbindung. Dies ist besonders wichtig, wenn sich der Spiegel an einem anderen geografischen Ort befindet. Darüber hinaus ist es wichtig, Ihr System im Voraus zu überwachen, um festzustellen, ob Einschränkungen in der Umgebung eine effiziente Spiegelung verhindern könnten.

Eine Datenbankspiegelung ist besonders geeignet, wenn es darum geht, die Kosten gering zu halten. Die Datenbankspiegelungsarchitektur benötigt für die Ausführung der Umgebung weder freigegebene Datenträger noch erweiterte oder spezielle Fähigkeiten. Im Gegensatz zur Clusterbildung ist es für die Datenbankspiegelung nicht erforderlich, dass die beiden Partner die gleiche Hardware besitzen. Des Weiteren gestaltet sich die Überwachung mithilfe des Setup-Assistenten als überaus einfach. Sie können darauf im Eigenschaftenfenster der Datenbank auf der Spiegelungsregisterkarte zugreifen (siehe Abbildung 3). Das Whitepaper „Database Mirroring Best Practices and Performance Considerations“ (auf Englisch) unter go.microsoft.com/fwlink/?LinkId=80897 enthält weitere nützliche Informationen.

Abbildung 3** Setup-Assistent für die Spiegelung **(Klicken Sie zum Vergrößern auf das Bild)

Datenbanksnapshots

Bei den Datenbanksnapshots handelt es sich um eine in SQL Server 2005 Enterprise Edition integrierte neue Technologie, die jedoch nicht als Option für hohe Verfügbarkeit betrachtet wird. Datenbanksnapshots sollten als Wiederherstellungsoption oder in Kombination mit anderen Technologien als geeignete Berichtsoption verwendet werden. Ein Snapshot ist einfach eine schreibgeschützte Ansicht einer Datenbank zu einem bestimmten Zeitpunkt.

Ein Snapshot wird mithilfe eines CREATE DATABASE-Befehls folgendermaßen erstellt:

CREATE DATABASE SnapDB_20061028_2030 ON
(NAME = SnapDB_Data, FILENAME = 
    'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SnapDB_20061028_2030.snp')
AS SNAPSHOT OF SnapDB;
GO

Wenn der Datenbanksnapshot erstellt ist, verwendet er eine oder mehrere Dateien mit geringer Dichte anstelle der in einer Datenbank gewöhnlich verwendeten Datendateien. Diese Dateien mit geringer Dichte sind hauptsächlich virtuelle Speicherorte, die anfänglich keine Daten verbrauchen. Sie werden nur zum Speichern von Daten verwendet, wenn die Daten in der Quelldatenbank geändert oder gelöscht wurden. Die Daten werden in die Dateien mit geringer Dichte seitenweise geschrieben. Der tatsächliche Datenbanksnapshot zeigt dabei nur die Daten an, die seit dem Erstellen des Snapshots geändert wurden. Die restlichen Daten werden aus den Datenseiten der Quelldatenbank abgerufen.

Den Datenbanksnapshotdateien wird die Datenbankgröße zugeordnet, wenn der Snapshot erstellt wird. Die zugeordnete Größe sagt nicht viel über die tatsächlich enthaltene Datenmenge aus. Um diese Informationen abzurufen, führen Sie eine T-SQL-Anweisung wie die folgende aus:

SELECT *
FROM fn_virtualfilestats(DB_ID(N'SnapDB_20061028_
    2030'), 1);
GO

Aufgrund der Methode, mit der Daten beim Zugriff auf den Datenbanksnapshot in den Dateien mit geringer Dichte sowie in der Datenbank gespeichert werden, werden die Datenseiten in den ursprünglichen Datenbankdatendateien und -datenseiten aus den Dateien mit geringer Dichte des Snapshots wiederhergestellt. Snapshots können nur auf dem Server mit der Quelldatenbank existieren, aus der der Snapshot entnommen wurde, da Datenseiten gemeinsam verwendet werden müssen. Snapshots stellen keine gültige sinnvolle Berichtsoption dar, da diese Architektur keine E/A-Vorgänge in der Quelldatenbank verhindert und somit nicht der korrekte Status der Datenbank dargestellt wird.

Stellen Sie sich ein Szenario vor, in dem die Datenbankspiegelung zusammen mit Snapshots verwendet wird. Dadurch können die Berichtsdaten, der Spiegel und die Snapshotdatenbanken physisch von der Prinzipaldatenbank getrennt werden. Der Datenbanksnapshot wird mithilfe von SQL Server Agent und eines benutzerdefinierten Skripts geplant, um aktualisierte Snapshots in regelmäßigen Abständen bereitzustellen. Das Beispielskript in Abbildung 4 zeigt die gespeicherte Prozedur, die hierfür verwendet wird. Sie wird in einem Job verwendet, um das Erstellen und Löschen von Snapshots für eine bestimmte Datenbank in Ihrer Umgebung zu verwalten. Dies würde eine akzeptable Lösung für die Berichterstellung ermöglichen, weil die Berichtsdaten von den Produktionsdaten getrennt würden.

Figure 4 Gespeicherte Prozeduren zum Planen von Snapshots

use msdb;
GO
set nocount on
GO

CREATE PROCEDURE usp_snaprefresh 
     @database    sysname = NULL    --name of the database to snapshot
    ,@keepsnap    int        = 24   --# of hours to keep a snapshot 
                                    --after it was created 
                                    --use a value of '0' to keep all
                                    --existing snapshots
    ,@fileloc    sysname            --location for snapshot
        = 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\'    
AS

DECLARE 
     @dt            datetime        ,@cnt          int
    ,@databaseid    int             ,@snap         sysname
    ,@sql           nvarchar(1000)  ,@yy           varchar(4)
    ,@mm            varchar(2)      ,@dd           varchar(2)
    ,@h             varchar(2)      ,@m            varchar(2)
    ,@lname         sysname         ,@pname        sysname
    ,@file          sysname         ,@pos1         int
    ,@pos2          int

-- initialize variables
SELECT 
     @dt = getdate()
    ,@cnt = 0, @pos1 = 0, @pos2 = 0
    ,@databaseid = db_id(@database)

-- check if valid database was provided
IF @databaseid IS NULL
BEGIN
    RAISERROR ('Missing database name. Rerun the procedure specifying a
       valid database name.',16,1)
    RETURN (0) 
END

--determine if snapshots should be kept
IF @keepsnap <> 0
BEGIN
    -- determine if other snapshots exist for this server older than @
    -- keepsnap value hrs
    SELECT ROW_NUMBER() OVER(ORDER BY name DESC) AS [RowNum], 
        name INTO #t1 
    FROM master.sys.databases 
    WHERE source_database_id = @databaseid
        AND create_date < dateadd(hh,-(@keepsnap),getdate())

    IF (SELECT max(RowNum) FROM #t1 where name is not null) > 0
    BEGIN
        WHILE @cnt <= (SELECT max(RowNum) FROM #t1)
        BEGIN
            SELECT @snap = name FROM #t1 WHERE RowNum = @cnt

            PRINT 'Dropping snapshot ''' + @snap + ''''

            SET @sql = 'DROP DATABASE ' + @snap

            EXEC(@sql)
            SELECT @cnt = @cnt + 1
        END
    END
END

-- break apart point in time date time information for file name
SELECT @yy = convert(varchar(4),year(@dt)),@mm = convert(varchar(2),
   month(@dt))
    ,@dd = convert(varchar(2), day(@dt)),@h = convert(varchar(2),
         datepart(hh,@dt)) 
    ,@m = convert(varchar(2), datepart(mi,@dt))

-- piece together the database snapshot name and the file name
SELECT @file = @database + '_' + @yy + @mm + @dd + '_' + @h + @m

-- identify logical file name of primary data file
SET @sql = 'SELECT name INTO tempdb..t1
FROM ' + @database + '.sys.database_files 
WHERE file_id = 1'

EXEC(@sql)

--setting logical filename for the snap
SELECT @lname = name FROM tempdb..t1

-- making sure the file location ends with '\'
IF substring(@fileloc, len(@fileloc), 1) <> '\'
BEGIN
    SET @fileloc = @fileloc + '\'
END

-- build sql statement to be run
SET @sql = N'CREATE DATABASE ' + @file + ' ON
(NAME = ' + @lname + ', FILENAME = ''' + @fileloc + @file + '.snp'')
AS SNAPSHOT OF ' + @database

EXEC(@sql)

-- cleanup
DROP TABLE tempdb..t1;
GO

Beachten Sie jedoch, dass die Datenbanksnapshots als temporär betrachtet werden, da Snapshots weder gesichert werden können noch ohne ihre Quelldatenbank existieren können. Wenn einer Datei mit geringer Dichte nicht genügend Speicherplatz zur Verfügung steht, wird der Snapshot als beschädigt betrachtet und muss gelöscht werden.

Außerdem kann die Systemleistung durch Datenbanksnapshots während der Durchführung von Datenänderungsvorgängen in der Quelldatenbank herabgesetzt werden, weil die Datenseiten für jeden Snapshot aus den Quelldatenbankdateien in die Datei mit geringer Dichte geschrieben werden. Dadurch wird die Anzahl der Schreibvorgänge um die Anzahl der in der Datenbank vorhandenen Snapshots vervielfacht.

Leseberechtigungen werden von der Quelldatenbank zum Zeitpunkt des Snapshots definiert und können nicht geändert werden. Der Snapshot muss sich in der gleichen Instanz wie die Quelldatenbank befinden, weil sie dieselben Datenseiten sowie denselben Puffercache verwenden.

Es empfiehlt sich, Snapshots nur dann als Berichterstellungslösung zu verwenden, wenn Sie auch eine Spiegelung verwenden. Andernfalls kann Ihre Umgebung nicht von einer Leistungssteigerung profitieren. Datenbanksnapshots stellen möglicherweise die schnellste Methode dar, Daten vor der Ausführung eines fragwürdigen Vorgangs auf einem System beizubehalten. Eine Datenbank kann im ursprünglichen Zustand des Snapshots wiederhergestellt werden, oder die Daten können dem Snapshot entnommen werden, um die Daten in der Quelldatenbank zu ersetzen.

Sie müssen einen Benennungsstandard für die Snapshotdatenbanken festlegen. Der hier verwendete Standard lautet „ursprünglicherDatenbankname_Datum_Zeit.snp“. Zuerst wird die Quelldatenbank angegeben, dann der Tag und die Zeit (im 24-Stundenformat) der Snapshotaufnahme.

Protokollversand

Der Protokollversand stellt eine beschränkte Option für hohe Verfügbarkeit dar, die Sicherungen und Wiederherstellungen verwendet, um eine kostengünstige Lösung einzurichten. Der Protokollversand nutzt Transaktionsprotokollsicherungen in geplanten Intervallen, um die Aktualität einer sekundären Datenbank zu gewährleisten.

In SQL Server 2005 verwendet der Protokollversand Assistenten, die durch den Prozess des Setups, der Planung, der Initialisierung und der Überwachung führen (siehe Abbildung 5). Der Prozess ist einfach und kann in wenigen Minuten abgeschlossen werden.

Abbildung 5** Protokollversand-Setup-Assistent **(Klicken Sie zum Vergrößern auf das Bild)

Nachdem die primäre Datenbank identifiziert wurde, werden ein Zeitplan erstellt und das Dateialter für Sicherungsdateien festgelegt. Als Nächstes müssen die Dateifreigaben für die Sicherungsdateien eingerichtet werden. Nachdem die Dateifreigaben eingerichtet wurden, muss der sekundäre Speicherort der Datenbank eingerichtet werden. Darüber hinaus ist die Datenbank durch Abschließen einer Wiederherstellung der primären Datenbank zu initialisieren. Schließlich müssen Sie die Zeitpläne für die Sicherungsdateikopien und die Wiederherstellungen der Transaktionsprotokollsicherungen zusammen mit allen Warnungen oder Verzögerungen festlegen, die für jeden Schritt benötigt werden.

Sobald das Setup abgeschlossen wurde, sichert der Protokollversand regelmäßig das Transaktionsprotokoll einer Datenbank auf einem freigegebenen Netzwerkspeicherort. Nachdem die Dateien an die Freigabe gesendet wurden, wird die Sicherung nach einem festen Zeitplan auf die sekundäre Datenbank angewendet.

Der Protokollversand funktioniert wegen seiner Einfachheit in vielen Situationen. Er stellt eine gute Option für hohe Verfügbarkeit dar, die preiswert ist und für ein System mit hoher Transaktion geeignet ist. Die beim Protokollversand eingesetzte sekundäre Datenbank kann nur im schreibgeschützten Modus verwendet werden. Dadurch ist sie für eine Berichtsdatenbank nützlich. Der Protokollversand benötigt nur einen minimalen Mehraufwand. Er braucht jedoch eine Warnungsrichtlinie, falls Behandlungsfehler auftreten.

Falls Sie den Protokollversand für Ihre Umgebung in Betracht ziehen, denken Sie an die Vorteile wie einfaches Setup und einfache Verwaltung. Beachten Sie auch, dass wenige oder keine speziellen Fähigkeiten erforderlich sind. Der Protokollversand stellt keine Echtzeitlösung für hohe Verfügbarkeit dar, auch wenn er zu diesem Zweck mit der Datenbankspiegelung kombiniert werden kann. Er wird von Zeitplänen sowie von Vorgängen wie Sicherungen, Dateikopien und Wiederherstellungen begrenzt. Er erfordert zudem ein manuelles Failover. Aus diesen Gründen stellt der Protokollversand eine einfache Lösung für Umgebungen bereit, in denen keine hohen Zeitanforderungen bestehen.

SQL Server-Clusterbildung

Serverclusterbildung funktioniert auf Betriebssystemebene und beinhaltet Hardwareduplikate sowie freigegebene Datenträgerressourcen, auf die der Cluster zugreifen kann. Die Clusterbildung beeinträchtigt das Verhalten der Endbenutzer möglicherweise am wenigsten, ist jedoch wahrscheinlich auch die teuerste Methode. Es benötigt mindestens die doppelte Menge an Hardware im Vergleich zu einer nicht gruppierten Instanz.

Das Thema Clusterbildung ist sehr umfangreich. Deshalb soll im Folgenden auf eine Erläuterung aller Einzelheiten verzichtet und eine allgemeine Übersicht vermittelt werden. Die Clusterbildung benötigt zwei oder mehr Server, die unter der gleichen Version von Windows® 2000 Advanced Edition oder Datacenter Edition bzw. unter Windows Server® 2003 Enterprise Edition oder Datacenter Edition installiert werden müssen. Darüber hinaus ist die Installation von Microsoft® Cluster Services (MSCS) erforderlich. Diese Dienste regeln die Besitzrechte freigegebener Ressourcen zwischen Servern und verwalten IP-Adressen, freigegebene Datenträger sowie Netzwerknamen. Die Clusterbildung benötigt zudem eine freigegebene Datenträgerressource, gewöhnlich in Form eines Storage Area Network (SAN) oder eines SCSI-angeschlossenen Speichers.

Eine SQL Server-Instanz wird auch als Ressource betrachtet, und sowohl Standard Edition als auch Enterprise Edition von SQL Server 2005 können in einer Clusterkonfiguration installiert werden. Unter „Feature Comparison Chart for SQL Server 2005“ (auf Englisch) (microsoft.com/sql/prodinfo/features/compare-features.mspx) finden Sie eine Liste der von beiden Versionen von SQL Server 2005 unterstützten Features.

Sobald die Ressourcen auf dem Cluster eingerichtet wurden, kommuniziert der sekundäre Knoten des Clusters regelmäßig mit dem primären Knoten des Clusters. Dies erfolgt über einen Takt, der in einem privaten Netzwerk zwischen den beiden Knoten des Clusters eingerichtet wurde. Der Takt ist ein Intervallprüfpunkt, mit dem bestimmt wird, ob der primäre Knoten Fehler enthält.

Falls der primäre Knoten fehlerhaft ist, werden die Ressourcen auf den sekundären Knoten verschoben, während der Status des logischen Servers nicht verändert wird. Dadurch können die Clients ihre Arbeit nur mit einer Pause in der Interaktion fortsetzen. Der ganze Failoverprozess kann zwischen 5 Sekunden und 30 Sekunden lang sein, in einigen Fällen noch länger. Die Dauer hängt von der Hardware, der Software und den am Cluster beteiligten Netzwerkkomponenten ab.

Die Clusterbildung kann eine teure und komplexe Technologie darstellen, deren Fehler im System nur unter Zuhilfenahme spezieller Fähigkeiten aufgelöst werden können. Es stellt jedoch von allen automatischen Failoveroptionen für Endnutzer das reibungsloseste Failover zur Verfügung. Jede Anwendung ist anders. Einige sind möglicherweise nicht für Cluster geeignet, was im schlimmsten Fall dazu führen kann, dass die Anwendung eine neue Verbindung herstellen muss.

Replikation

Eine SQL Server 2005-Replikation kann ebenfalls in Architekturen für hohe Verfügbarkeit verwendet werden. Es stehen vier Replikationstypen zur Verfügung: Snapshot, Transaktion, Peer-to-Peer und Merge. Peer-to-Peer ist tatsächlich nur eine Form der Transaktionsreplikation. Aus diesem Grund soll an dieser Stelle nicht weiter darauf eingegangen werden.

Mithilfe der Replikation erhalten Sie die Möglichkeit, zum Zwecke der hohen Verfügbarkeit einen sekundären Standort und eine sekundäre Datenbank einzurichten, die die gleiche Funktionalität wie die primäre Datenbank besitzt. Hierfür können Sie die Mergereplikation verwenden. Sie entnimmt der primären sowie der sekundären Datenbank Transaktionen und führt die Änderungen aus beiden in einer dritten Datenbank zusammen. In dieser Konfiguration wird ein Konfliktauflösungsverfahren benötigt.

Die Transaktionsreplikation ist in ihrem logischen Entwurf mit einer Datenbankspiegelung vergleichbar. Auf die primäre Datenbank angewendete Transaktionen werden an die sekundäre Datenbank gesendet, um eine konsistente Umgebung sicherzustellen. Nach Eingang werden die Transaktionen auf die sekundäre Datenbank angewendet, die anschließend auf die nächste Transaktion wartet, die auf das System angewendet werden soll.

Die Snapshotreplikation ist insofern mit dem Protokollversand vergleichbar, als dass beide in geplanten Intervallen ausgeführt werden. Zudem wird die sekundäre Datenbank als Ganzes aktualisiert, statt dass jede Transaktion während der Übertragung auf beide Systeme angewendet wird. Beide Technologien werden mehr oder weniger auf die gleiche Art und Weise verwendet.

Die Replikation erfordert spezielle Kenntnisse. Dies stellt für Umgebungen, die über keinen engagierten DBA verfügen, ein Problem dar. Die Problembehandlung kann sich bei der Replikation als aufwändig erweisen. Zudem erfordert die Replikation ein umfassenderes Design, wenn sie als Option für hohe Verfügbarkeit eingesetzt werden soll.

Die Replikation kann die Anforderungen an eine Lösung mit hoher Verfügbarkeit angemessen erfüllen. Diese Technologie kann mithilfe der Transaktionsreplikation auf Datensatzebene die gleichen Aufgaben wie eine Datenbankspiegelung erfüllen, jedoch ohne Option für ein automatisches Failover. Wenn Sie über genügend Ressourcen und ein wenig Kreativität verfügen, sollte das Skripting einer Lösung für ein automatisches Failover kein allzu großes Problem sein.

Im Unterschied zur Datenbankspiegelung können Clientanwendungen aber vollständig sowohl auf die Quell- als auch auf die Zieldatenbanken zugreifen. Die Replikation stellt die gleiche Funktionalität wie der Protokollversand unter Verwendung der Snapshotreplikation bereit.

Beachten Sie jedoch, dass sich die Replikationstechnologie bewährt hat und gut dokumentiert ist. Es bestehen aber auch Nachteile in der Verwendung der Replikation für eine Lösung mit hoher Verfügbarkeit. Die Leistung kann ebenfalls ein Problem darstellen, jedoch nur in dem Umfang wie bei der Datenbankspiegelung. Jede Lösung mit hoher Verfügbarkeit, die Sie mithilfe der Replikation entwerfen, hat wahrscheinlich eine noch kompliziertere zu verwaltende Architektur. Diese ist nicht unbedingt weiter entwickelt, aber sicherlich komplexer. Darüber hinaus stellen Änderungen an der Datenbanktabellenstruktur oder das Hinzufügen einer zu replizierenden Tabelle eine der größten Hürden dar, die nicht außer Acht gelassen werden dürfen. Sie müssen hierfür die Veröffentlichung unterbrechen und hinsichtlich der Änderungen neu definieren, sodass sie in beiden Datenbanken vorhanden sind.

Zusammenfassung

Das Erstellen einer Lösung mit hoher Verfügbarkeit für Ihre Umgebung erfordert offensichtlich eine gewisse Kreativität. Jede SQL Server 2005-Technologie für hohe Verfügbarkeit hat Schwächen und Stärken, und jede ist für unterschiedliche Situationen geeignet.

Der Protokollversand, die Snapshotreplikation und sogar Datenbankspiegelungen im Modus für hohe Leistung wären geeignet, wenn eine primäre Internetdatenbank geografisch von den sekundären Datenbankumgebungen getrennt wird (insbesondere, wenn die sekundären Daten nicht in Echtzeit verfügbar sein müssen).

Wenn andererseits eine sekundäre Datenbank Echtzeitdaten benötigt, können die Transaktionsreplikation oder die Datenbankspiegelung die Last tragen, wenn die Transaktionsraten auf dem primären Server niedrig sind und die Verbindung zwischen den beiden Umgebungsstandorten schnell und nicht gesättigt ist.

Beachten Sie auch das Ausmaß der Benutzerfreundlichkeit dieser Technologien. Wenn Sie bereits über praktische Erfahrungen in einigen dieser Technologien besitzen, sollte es keine Probleme geben. Wenn Sie Manager sind und keinen engagierten DBA haben, sollten Sie sich von komplexen Technologien wie Replikation fernhalten, die aus vielen beweglichen Einzelteilen bestehen und deren Problembehandlung kompliziert sein kann. Es empfiehlt sich auch, über den Einsatz eines erfahrenen SQL Server-Beraters nachzudenken. Dieser kann Ihnen beim Entwerfen und Implementieren helfen und möglicherweise auch Ihr Personal schulen, sodass es in die Lage versetzt wird, neue, für Ihre Umgebung geeignete hohe Verfügbarkeit zu verwalten.

Wenn für Ihre Organisation hohe Verfügbarkeit lediglich bedeutet, dass die Daten zu einem hohen Prozentsatz der Zeit verfügbar sein sollen und Datenausfallzeiten ein ernst zu nehmendes Problem sind, stellt die Clusterbildung möglicherweise die beste Option für Sie dar.

Zusammenfassend lässt sich sagen, dass SQL Server 2005 eine Reihe neuer Optionen zum Implementieren von hoher Verfügbarkeit zur Verfügung stellt, die an unterschiedliche Umgebungen angepasst sind. Eine einzelne Verfügbarkeitsoption mag Ihren Bedürfnissen entsprechen, oder Sie können eine Kombination aus Technologien nutzen. Wählen Sie unter den unterschiedlichen Möglichkeiten die beste Lösung für Sie aus.

Zach Nichter ist SQL Server-Experte und verfügt über mehr als 10 Jahre Erfahrung in diesem Bereich. Er hat bereits mehrere SQL Server-Supportrollen innegehabt, einschließlich DBA, Teamleiter, Manager und Berater. Derzeit ist Zach bei Levi Strauss & Co. als DBA-Architekt tätig. Der Schwerpunkt seiner Tätigkeit liegt im Bereich der Leistung, Überwachung und Architektur von SQL Server und in anderen strategischen Initiativen.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.