Analysis Services mit Always On-Verfügbarkeitsgruppen

Gilt für:SQL Server unter Windows

Eine Always On-Verfügbarkeitsgruppe ist eine vordefinierte Sammlung relationaler SQL Server-Datenbanken, die gemeinsam ein Failover ausführen, wenn Bedingungen in einer der Datenbanken ein Failover auslösen. Dabei werden Anforderungen an eine gespiegelte Datenbank in einer anderen Instanz in der gleichen Verfügbarkeitsgruppe umgeleitet. Wenn Sie als Hochverfügbarkeitslösung Verfügbarkeitsgruppen verwenden, können Sie in einer tabellarischen oder mehrdimensionalen Analysis Services-Lösung eine Datenbank in dieser Gruppe als Datenquelle verwenden. Alle folgenden Analysis Services-Vorgänge werden bei Verwendung einer Verfügbarkeitsdatenbank wie erwartet ausgeführt: das Verarbeiten oder Importieren von Daten, das direkte Abfragen von relationalen Daten (im ROLAP-Speichermodus oder DirectQuery-Modus) und das Rückschreiben.

Verarbeitung und Abfragen sind schreibgeschützte Workloads. Sie können die Leistung verbessern, indem Sie diese Arbeitsauslastungen in ein lesbares sekundäres Replikat auslagern. Dieses Szenario erfordert zusätzliche Konfiguration. Stellen Sie mithilfe der Prüfliste in diesem Thema sicher, dass Sie alle Schritte ausführen.

Voraussetzungen

Sie benötigen auf allen Replikaten eine SQL Server-Anmeldung. Verfügbarkeitsgruppen, Listener und Datenbanken müssen von einem Mitglied der sysadmin -Rolle konfiguriert werden. Benutzer benötigen jedoch für den Zugriff auf die Datenbank von einem Analysis Services-Client aus lediglich db_datareader -Berechtigungen.

Verwenden Sie einen Datenanbieter, der das TDS (Tabular Data Stream)-Protokoll, Version 7.4 oder höher, unterstützt, z. B. SQL Server Native Client 11.0 oder den Datenanbieter für SQL Server in .NET Framework 4.02.

(Für Nur-Lese-Workloads). Die Rolle des sekundären Replikats muss für schreibgeschützte Verbindungen konfiguriert werden, die Verfügbarkeitsgruppe muss über eine Routingliste verfügen, und die Verbindung in der Analysis Services-Datenquelle muss den Listener der Verfügbarkeitsgruppe angeben. In diesem Thema finden Sie Anweisungen.

Checkliste: Ein sekundäres Replikat für schreibgeschützte Vorgänge verwenden

Sofern Ihre Analysis Services-Lösung keinen Schreibzugriff umfasst, können Sie eine Datenquellenverbindung so konfigurieren, dass ein lesbares sekundäres Replikat verwendet wird. Wenn Sie über eine schnelle Netzwerkverbindung verfügen, weist das sekundäre Replikat eine sehr geringe Datenlatenz auf und stellt nahezu die gleichen Daten wie das primäre Replikat bereit. Durch die Verwendung des sekundären Replikats für Analysis Services-Vorgänge können Sie die Lese-/Schreibkonkurrenz auf dem primären Replikat reduzieren und eine bessere Auslastung der sekundären Replikate in Ihrer Verfügbarkeitsgruppe erzielen.

Standardmäßig sind sowohl der Lese-/Schreibzugriff als auch der Zugriff für beabsichtigte Lesevorgänge für das primäre Replikat zulässig, und es werden keine Verbindungen mit sekundären Replikaten zugelassen. Zum Einrichten einer schreibgeschützten Clientverbindung zu einem sekundären Replikat ist zusätzliche Konfiguration erforderlich. Bei der Konfiguration müssen Eigenschaften auf dem sekundären Replikat festgelegt und ein T-SQL-Skript ausgeführt werden, das eine schreibgeschützte Routingliste definiert. Stellen Sie mithilfe der folgenden Verfahren sicher, dass Sie beide Schritte ausgeführt haben.

Hinweis

Für die folgenden Schritte werden eine vorhandene Always On-Verfügbarkeitsgruppe und vorhandene Datenbanken vorausgesetzt. Wenn Sie eine neue Gruppe konfigurieren, verwenden Sie den Assistenten für neue Verfügbarkeitsgruppen, um die Gruppe zu erstellen und die Datenbanken zu verknüpfen. Der Assistent überprüft, ob die Voraussetzungen erfüllt sind, bietet Anleitungen für die einzelnen Schritte und führt die Erstsynchronisierung aus. Weitere Informationen finden Sie unter Verwenden des Assistenten für Verfügbarkeitsgruppen (SQL Server Management Studio).

Schritt 1: Konfigurieren des Zugriffs auf ein Verfügbarkeitsreplikat

  1. Stellen Sie im Objekt-Explorer eine Verbindung mit der Serverinstanz her, die das primäre Verfügbarkeitsreplikat hostet, und erweitern Sie die Serverstruktur.

    Hinweis

    Diese Schritte sind unter Konfigurieren des schreibgeschützten Zugriffs auf ein Verfügbarkeitsreplikat (SQL Server) beschrieben. Dort finden Sie zusätzliche Informationen und alternative Anweisungen zum Ausführen dieser Aufgabe.

  2. Erweitern Sie den Knoten Hohe Verfügbarkeit (immer aktiviert) und den Knoten Verfügbarkeitsgruppen .

  3. Klicken Sie auf die Verfügbarkeitsgruppe, deren Replikat geändert werden soll. Erweitern Sie Verfügbarkeitsreplikate.

  4. Klicken Sie mit der rechten Maustaste auf das sekundäre Replikat, und klicken Sie auf Eigenschaften.

  5. Ändern Sie im Dialogfeld Eigenschaften des Verfügbarkeitsreplikats den Verbindungszugriff für die sekundäre Rolle wie folgt:

    • Wählen Sie in der Dropdownliste Lesbares Sekundär die Option Nur Leseabsicht aus.

    • Wählen Sie in der Dropdownliste Verbindungen in primärer Rolle den Eintrag Alle Verbindungen zulassenaus. Dies ist die Standardeinstellung.

    • Optional können Sie in der Dropdownliste Verfügbarkeitsmodus den Eintrag Synchroner Commitauswählen. Dieser Schritt ist nicht erforderlich, jedoch wird durch das Festlegen dieser Option Datenparität zwischen dem primären und sekundären Replikat sichergestellt.

      Diese Eigenschaft ist auch eine Voraussetzung für geplantes Failover. Wenn Sie zu Testzwecken ein geplantes manuelles Failover ausführen möchten, legen Sie für das primäre und das sekundäre Replikat Verfügbarkeitsmodus auf Synchroner Commit fest.

Schritt 2: Konfigurieren von schreibgeschütztem Routing

  1. Stellen Sie eine Verbindung mit dem primären Replikat her.

    Hinweis

    Diese Schritte sind unter Konfigurieren des schreibgeschützten Routings für eine Verfügbarkeitsgruppe (SQL Server) beschrieben. Dort finden Sie zusätzliche Informationen und alternative Anweisungen zum Ausführen dieser Aufgabe.

  2. Öffnen Sie ein Abfragefenster, und fügen Sie das folgende Skript ein. Dieses Skript führt drei Aufgaben aus: Es aktiviert lesbare Verbindungen mit einem sekundären Replikat (standardmäßig deaktiviert), legt die URL für das schreibgeschützte Routing fest und erstellt die Routingliste, in der die Priorisierung der Weiterleitung von Verbindungsanforderungen festgelegt ist. Die erste Anweisung, die lesbare Verbindungen zulässt, ist redundant, wenn Sie die Eigenschaften bereits in Management Studiofestgelegt haben, sie wird jedoch der Vollständigkeit halber aufgeführt.

    ALTER AVAILABILITY GROUP [AG1]  
 MODIFY REPLICA ON  
N'COMPUTER01' WITH   
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));  

ALTER AVAILABILITY GROUP [AG1]  
 MODIFY REPLICA ON  
N'COMPUTER01' WITH   
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.contoso.com:1433'));  

ALTER AVAILABILITY GROUP [AG1]  
 MODIFY REPLICA ON  
N'COMPUTER02' WITH   
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));  

ALTER AVAILABILITY GROUP [AG1]  
 MODIFY REPLICA ON  
N'COMPUTER02' WITH   
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER02.contoso.com:1433'));  

ALTER AVAILABILITY GROUP [AG1]   
MODIFY REPLICA ON  
N'COMPUTER01' WITH   
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER02','COMPUTER01')));  

ALTER AVAILABILITY GROUP [AG1]   
MODIFY REPLICA ON  
N'COMPUTER02' WITH   
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER01','COMPUTER02')));  
GO

  3. Ändern Sie das Skript, und ersetzen Sie die Platzhalter durch gültige Werte für Ihre Bereitstellung:

    • Ersetzen Sie 'COMPUTER01' durch den Namen der Serverinstanz, die das primäre Replikat hostet.

    • Ersetzen Sie 'COMPUTER02' durch den Namen der Serverinstanz, die das sekundäre Replikat hostet.

    • Ersetzen Sie 'contoso.com' durch den Namen der Domäne, oder lassen Sie den Namen aus dem Skript aus, wenn sich alle Computer in der gleichen Domäne befinden. Behalten Sie die Portnummer bei, wenn der Listener den Standardport verwendet. Der tatsächlich vom Listener verwendete Port ist auf der Eigenschaftenseite in Management Studioaufgeführt.

  4. Führen Sie das Skript aus.

    Erstellen Sie anschließend eine Datenquelle in einem Analysis Services-Modell, die eine Datenbank aus der soeben von Ihnen konfigurierten Gruppe verwendet.

Erstellen einer Analysis Services-Datenquelle mithilfe einer Always On-Verfügbarkeitsdatenbank

In diesem Abschnitt wird das Erstellen einer Analysis Services-Datenquelle beschrieben, die eine Verbindung mit einer Datenbank in einer Verfügbarkeitsgruppe herstellt. Sie können mithilfe dieser Anweisungen eine Verbindung mit einem primären Replikat (Standard) oder einem lesbaren sekundären Replikat konfigurieren, das Sie mit Schritten in einem vorherigen Abschnitt konfiguriert haben. Always On-Konfigurationseinstellungen sowie die im Client festgelegten Verbindungseigenschaften bestimmen, ob ein primäres oder sekundäres Replikat verwendet wird.

  1. Klicken Sie in SQL Server Data Toolsin einem Analysis Services-Projekt für mehrdimensionale und Data Mining-Modelle mit der rechten Maustaste auf Datenquellen , und wählen Sie Neue Datenquelleaus. Klicken Sie auf Neu , um eine neue Datenquelle zu erstellen.

    Alternativ können Sie für ein tabellarisches Modellprojekt auf das Menü „Modell“ und anschließend auf Aus Datenquelle importierenklicken.

  2. Wählen Sie im Verbindungs-Manager unter "Anbieter" einen Anbieter aus, der das TDS (Tabular Data Stream)-Protokoll unterstützt. Dieses Protokoll wird von SQL Server Native Client 11.0 unterstützt.

  3. Geben Sie im Verbindungs-Manager unter „Servername“ den Namen des Verfügbarkeitsgruppenlistenersein, und wählen Sie anschließend eine Datenbank aus, die in der Gruppe verfügbar ist.

    Der Verfügbarkeitsgruppenlistener leitet eine Clientverbindung für Lese-/Schreibanforderungen an ein primäres Replikat oder, wenn Sie in der Verbindungszeichenfolge Read-Intent angeben, an ein sekundäres Replikat um. Da sich die Rollen der Replikate während eines Failovers (bei dem das primäre Replikat zum sekundären Replikat und das sekundäre Replikat zum primären Replikat wird) ändern, sollten Sie immer den Listener angeben, sodass die Clientverbindung entsprechend umgeleitet wird.

    Sie können einen Datenbankadministrator fragen oder eine Verbindung mit einer Instanz in der Verfügbarkeitsgruppe herstellen und die entsprechende Always On-Verfügbarkeitskonfiguration anzeigen, um den Namen des Verfügbarkeitsgruppenlisteners zu bestimmen.

  4. Klicken Sie im Verbindungs-Manager im linken Navigationsbereich auf Alle , um das Eigenschaftenraster des Datenanbieters anzuzeigen.

    Legen Sie Anwendungszweck auf READONLY fest, wenn Sie eine schreibgeschützte Clientverbindung mit einem sekundären Replikat konfigurieren. Behalten Sie andernfalls die Standardeinstellung READWRITE bei, um die Verbindung an das primäre Replikat umzuleiten.

  5. Wählen Sie unter „Informationen zum Identitätswechsel“ die Option Einen bestimmten Windows-Benutzernamen und ein bestimmtes Kennwort verwenden aus, und geben Sie dann ein Benutzerkonto einer Windows-Domäne ein, das mindestens über db_datareader-Berechtigungen für die Datenbank verfügt.

    Wählen Sie weder Anmeldeinformationen des aktuellen Benutzers noch Erben aus. Sie können Dienstkontoauswählen, jedoch nur, wenn dieses Konto über Leseberechtigungen für die Datenbank verfügt.

    Stellen Sie die Datenquelle fertig, und schließen Sie den Datenquellen-Assistenten.

  6. Fügen Sie der Verbindungszeichenfolge MultiSubnetFailover=Yes hinzu, damit der aktive Server schneller erkannt wird und schneller eine Verbindung mit ihm hergestellt wird. Weitere Informationen zu dieser Eigenschaft finden Sie unter SQL Server Native Client-Unterstützung für hohe Verfügbarkeit, Notfallwiederherstellung.

    Diese Eigenschaft wird im Eigenschaftenraster nicht angezeigt. Klicken Sie mit der rechten Maustaste auf die Datenquelle, und wählen Sie Code anzeigenaus, um die Eigenschaft hinzuzufügen. Fügen Sie der Verbindungszeichenfolge MultiSubnetFailover=Yes hinzu.

Die Datenquelle ist jetzt definiert. Sie können jetzt ein Modell erstellen, wobei Sie mit der Datenquellensicht beginnen. Für tabellarische Modelle beginnen Sie mit dem Erstellen von Beziehungen. Wenn Daten aus der Verfügbarkeitsdatenbank abgerufen werden müssen (wenn Sie z. B. die Lösung verarbeiten oder bereitstellen möchten), können Sie die Konfiguration testen, um zu überprüfen, ob Zugriff auf Daten aus dem sekundären Replikat erfolgt.

Testen der Konfiguration

Nachdem Sie das sekundäre Replikat konfiguriert und in Analysis Services eine Datenquellenverbindung erstellt haben, können Sie überprüfen, ob Verarbeitungs- und Abfragebefehle an das sekundäre Replikat umgeleitet werden. Sie können auch ein geplantes manuelles Failover ausführen, um den Wiederherstellungsplan für dieses Szenario zu überprüfen.

Schritt 1: Überprüfen, ob die Datenquellenverbindung an das sekundäre Replikat umgeleitet wird

  1. Starten Sie SQL Server Profiler, und stellen Sie eine Verbindung mit der SQL Server-Instanz her, die das sekundäre Replikat hostet.

    Während die Ablaufverfolgung ausgeführt wird, zeigen die Ereignisse SQL:BatchStarting und SQL:BatchCompleting die von Analysis Services abgesetzten Abfragen an, die auf der Instanz des Datenbankmoduls ausgeführt werden. Diese Ereignisse sind standardmäßig ausgewählt, daher müssen Sie lediglich die Ablaufverfolgung starten.

  2. Öffnen Sie in SQL Server Data Toolsdas Analysis Services-Projekt oder die Analysis Services-Lösung, das bzw. die eine Datenquellenverbindung enthält, die Sie testen möchten. Stellen Sie sicher, dass die Datenquelle den Verfügbarkeitsgruppenlistener und nicht eine Instanz in der Gruppe angibt.

    Dieser Schritt ist wichtig. Wenn Sie den Namen einer Serverinstanz angeben, erfolgt kein Routing zum sekundären Replikat.

  3. Ordnen Sie die Anwendungsfenster so an, dass Server Profiler und SQL Server Data Tools nebeneinander angezeigt werden.

  4. Stellen Sie die Lösung bereit, und sobald die Bereitstellung abgeschlossen ist, beenden Sie die Ablaufverfolgung.

    Im Ablaufverfolgungsfenster sollten Ereignisse aus der Anwendung Microsoft SQL Server Analysis Servicesangezeigt werden. Es sollten SELECT -Anweisungen angezeigt werden, mit denen Daten aus einer Datenbank auf der Serverinstanz abgerufen werden, die das sekundäre Replikat hostet. Dies bedeutet, dass die Verbindung mit dem sekundären Replikat über den Listener hergestellt wurde.

Schritt 2: Ausführen eines geplanten Failovers zum Testen der Konfiguration

  1. Überprüfen Sie in Management Studio das primäre und sekundäre Replikat, um sicherzustellen, dass beide für den Modus mit synchronem Commit konfiguriert sind und gegenwärtig synchronisiert sind.

    In den folgenden Schritten wird davon ausgegangen, dass ein sekundäres Replikat für synchronen Commit konfiguriert ist.

    Öffnen Sie eine Verbindung mit jeder Instanz, die das primäre und sekundäre Replikat hostet, erweitern Sie den Ordner „Datenbanken“, und stellen Sie sicher, dass in jedem Replikat (Synchronisiert) und (Wird synchronisiert) an den Namen der Datenbank angefügt ist, um die Synchronisierung zu überprüfen.

    Hinweis

    Diese Schritte sind unter Ausführen eines geplanten manuellen Failovers einer Verfügbarkeitsgruppe (SQL Server) beschrieben. Dort finden Sie zusätzliche Informationen und alternative Anweisungen zum Ausführen dieser Aufgabe.

  2. Starten Sie in SQL Server Profiler Ablaufverfolgungen für jedes Replikat, und zeigen Sie die Ablaufverfolgungen nebeneinander an. In den folgenden Schritten vergleichen Sie Ablaufverfolgungen und bestätigen, dass die SQL-Abfragen, die zum Verarbeiten oder zum Ausführen von Abfragen in Analysis Services verwendet werden, von einem Replikat zum anderen wechseln.

  3. Führen Sie in Analysis Services einen Verarbeitungs- oder Abfragebefehl aus. Da Sie die Datenquelle für eine schreibgeschützte Verbindung konfiguriert haben, sollte angezeigt werden, dass der Befehl auf dem sekundären Replikat ausgeführt wird.

  4. Stellen Sie in Management Studioeine Verbindung mit dem sekundären Replikat her.

  5. Erweitern Sie den Knoten Hohe Verfügbarkeit (immer aktiviert) und den Knoten Verfügbarkeitsgruppen .

  6. Klicken Sie mit der rechten Maustaste auf die Verfügbarkeitsgruppe, für die ein Failover ausgeführt werden soll, und wählen Sie den Befehl Failover aus. Dies startet den Failover-Assistenten für Verfügbarkeitsgruppen. Wählen Sie mithilfe des Assistenten aus, welches Replikat als neues primäres Replikat verwendet werden soll.

  7. Vergewissern Sie sich, dass das Failover erfolgreich ausgeführt wurde:

    • Erweitern Sie in Management Studio die Verfügbarkeitsgruppen, um die Bezeichnungen „(primary)“ und „(secondary)“ anzuzeigen. Die Instanz, die zuvor ein primäres Replikat war, sollte jetzt ein sekundäres Replikat sein.

    • Prüfen Sie im Dashboard, ob Probleme mit dem Systemzustand erkannt wurden. Klicken Sie mit der rechten Maustaste auf die Verfügbarkeitsgruppe, und wählen Sie Dashboard anzeigenaus.

  8. Warten Sie ein oder zwei Minuten, bis das Failover im Backend abgeschlossen ist.

  9. Wiederholen Sie den Verarbeitungs- oder Abfragebefehl in der Analysis Services-Lösung, und verfolgen Sie dann die Ablaufverfolgungen in SQL Server Profiler nebeneinander. Es sollte zu erkennen sein, dass die Verarbeitung auf der anderen Instanz erfolgt, die jetzt das neue sekundäre Replikat ist.

Vorgänge nach einem Failover

Während eines Failovers wechselt ein sekundäres Replikat in die primäre Rolle, und das bisherige primäre Replikat wechselt in die sekundäre Rolle. Alle Clientverbindungen werden beendet, der Besitz des Listeners der Verfügbarkeitsgruppe geht zusammen mit der Rolle des primären Replikats auf eine neue SQL Server-Instanz über, und der Listener-Endpunkt wird an die virtuellen IP-Adressen und TCP-Ports der neuen Instanz gebunden. Weitere Informationen finden Sie unter Informationen zum Clientverbindungszugriff auf Verfügbarkeitsreplikate (SQL Server).

Wenn während der Verarbeitung ein Failover erfolgt, wird in Analysis Services in der Protokolldatei oder im Ausgabefenster der folgende Fehler angezeigt „OLE DB-Fehler: OLE DB- oder ODBC-Fehler: Kommunikationslinkfehler; 08S01; TPC-Anbieter: Eine vorhandene Verbindung wurde vom Remotehost geschlossen. ; 08S01.“

Dieser Fehler sollte behoben sein, wenn Sie eine Minute lang warten und es dann erneut versuchen. Sofern die Verfügbarkeitsgruppe ordnungsgemäß für ein lesbares sekundäres Replikat konfiguriert ist, wird die Verarbeitung auf dem neuen sekundären Replikat fortgesetzt, wenn Sie die Verarbeitung erneut starten.

Persistente Fehler treten wahrscheinlich aufgrund eines Konfigurationsproblems auf. Sie können versuchen, das T-SQL-Skript erneut auszuführen, um Probleme mit der Routingliste, den schreibgeschützten Routing-URLs und der Leseabsicht auf dem sekundären Replikat zu beheben. Sie sollten außerdem überprüfen, ob das primäre Replikat alle Verbindungen zulässt.

Rückschreiben bei Verwendung einer Always On-Verfügbarkeitsdatenbank

Writeback ist eine Analysis-Services-Funktion, die Was-wäre-wenn-Analysen in Excel unterstützt. Sie wird auch häufig für Budgetierungs- und Prognosetasks in benutzerdefinierten Anwendungen verwendet.

Die Unterstützung für Rückschreiben erfordert eine READWRITE-Clientverbindung. Wenn Sie in Excel versuchen, auf einer schreibgeschützten Verbindung zu schreiben, tritt der folgende Fehler auf: "Daten konnten nicht aus der externen Datenquelle abgerufen werden."

Wenn Sie eine Verbindung ausschließlich für den Zugriff auf ein lesbares sekundäres Replikat konfiguriert haben, müssen Sie jetzt eine neue Verbindung als READWRITE-Verbindung mit dem primären Replikat konfigurieren.

Erstellen Sie hierzu in einem Analysis Services-Modell eine zusätzliche Datenquelle, um die Lese-/Schreibverbindung zu unterstützen. Wenn Sie die zusätzliche Datenquelle erstellen, verwenden Sie den gleichen Listenernamen und die gleiche Datenbank, die Sie in der schreibgeschützten Verbindung angegeben haben. Behalten Sie jedoch die Standardeinstellung bei, die READWRITE-Verbindungen unterstützt, statt Anwendungszweckzu ändern. Sie können Ihrer Datenquellenansicht jetzt neue Fakten- oder Dimensionstabellen hinzufügen, die auf der Lese-/Schreibdatenquelle basieren, und anschließend Writeback für die neuen Tabellen aktivieren.

Verwandte Inhalte

  • Last updated on