Freigeben über

Verwaltung von Anmeldungen und Aufträgen für die Datenbanken einer Verfügbarkeitsgruppe (SQL Server)

Sie sollten den gleichen Satz von Benutzeranmeldungen und SQL Server-Agent-Aufträgen in jeder primären Datenbank einer AlwaysOn-Verfügbarkeitsgruppe und den entsprechenden sekundären Datenbanken routinemäßig verwalten. Die Anmeldungen und Aufträge müssen auf jeder Instanz von SQL Server reproduziert werden, die ein Verfügbarkeitsreplikat für die Verfügbarkeitsgruppe hostet.

  • Aufträge des SQL Server-Agents

    Sie müssen relevante Aufträge von der Serverinstanz, die das ursprüngliche primäre Replikat hostet, manuell auf die Serverinstanzen kopieren, die die ursprünglichen sekundären Replikate hosten. Für alle Datenbanken müssen Sie am Anfang jedes relevanten Auftrags Logik hinzufügen, damit der Auftrag nur auf der primären Datenbank ausgeführt wird, das heißt nur dann, wenn das lokale Replikat das primäre Replikat für die Datenbank ist.

    Die Serverinstanzen, die die Verfügbarkeitsreplikate einer Verfügbarkeitsgruppe hosten, können unterschiedlich konfiguriert werden, mit unterschiedlichen Bandlaufwerkbuchstaben oder solchen. Bei den Aufträgen für die einzelnen Verfügbarkeitsreplikate müssen derartige Unterschiede berücksichtigt werden.

    Beachten Sie, dass Sicherungsaufträge die sys.fn_hadr_is_preferred_backup_replica-Funktion verwenden können, um zu ermitteln, ob das lokale Replikat gemäß den Sicherungseinstellungen der Verfügbarkeitsgruppe die bevorzugte für Sicherungen ist. Sicherungsaufträge, die mit dem Wartungsplan-Assistenten erstellt wurden, verwenden diese Funktion nativ. Für andere Sicherungsaufträge empfiehlt es sich, diese Funktion in den Sicherungsaufträgen als Bedingung zu verwenden, sodass sie nur auf dem bevorzugten Replikat ausgeführt werden. Weitere Informationen finden Sie unter Active Secondaries: Backup on Secondary Replicas (AlwaysOn Availability Groups).

  • Anmeldungen

    Wenn Sie enthaltene Datenbanken verwenden, können Sie enthaltene Benutzer in den Datenbanken konfigurieren, und für diese Benutzer müssen Sie keine Anmeldungen für die Serverinstanzen erstellen, die ein sekundäres Replikat hosten. Für eine nicht enthaltene Verfügbarkeitsdatenbank müssen Sie Benutzer für die Anmeldungen auf den Serverinstanzen erstellen, die die Verfügbarkeitsreplikate hosten. Weitere Informationen finden Sie unter CREATE USER (Transact-SQL).

    Wenn eine Ihrer Anwendungen die SQL Server-Authentifizierung oder eine lokale Windows-Anmeldung verwendet, lesen Sie Die Anmeldungen von Anwendungen, die sql Server-Authentifizierung oder eine lokale Windows-Anmeldung verwenden, weiter unten in diesem Thema.

    Hinweis

    Ein Datenbankbenutzer, für den die SQL Server-Anmeldung nicht definiert ist oder in einer Serverinstanz falsch definiert ist, kann sich nicht bei der Instanz anmelden. Diese Benutzer werden als verwaiste Benutzer der Datenbank dieser Serverinstanz bezeichnet. Wenn ein Benutzer auf einer bestimmten Serverinstanz ein verwaister Benutzer ist, können Sie jederzeit die Benutzeranmeldungen einrichten. Weitere Informationen finden Sie unter Problembehandlung bei verwaisten Benutzer*innen (SQL Server).

  • Weitere Metadaten

    Anmeldungen und Aufträge sind nicht die einzigen Informationen, die für jede Serverinstanz neu erstellt werden müssen, die ein sekundäres Replikat für eine bestimmte Verfügbarkeitsgruppe hostet. Sie müssen z. B. Serverkonfigurationseinstellungen, Anmeldeinformationen, verschlüsselte Daten, Berechtigungen, Replikationseinstellungen, Dienstbrokeranwendungen, Trigger (auf Serverebene) usw. neu erstellen. Weitere Informationen finden Sie unter Verwalten von Metadaten beim Bereitstellen einer Datenbank auf einer anderen Serverinstanz (SQL Server).

Anmeldenamen von Anwendungen, die die SQL Server-Authentifizierung oder eine lokale Windows-Anmeldung verwenden

Wenn eine Anwendung die SQL Server-Authentifizierung oder eine lokale Windows-Anmeldung verwendet, können nicht übereinstimmende SIDs verhindern, dass der Anmeldename der Anwendung auf einer Remoteinstanz von SQL Serveraufgelöst wird. Aufgrund der nicht übereinstimmenden SIDs wird der Anmeldename auf der Remoteserverinstanz als verwaister Benutzer behandelt. Dieses Problem kann auftreten, wenn von einer Anwendung nach einem Failover eine Verbindung mit einer gespiegelten oder Protokollversand-Datenbank hergestellt wird bzw. wenn eine Verbindung mit einer Replikationsabonnenten-Datenbank hergestellt wird, die von einer Sicherung initialisiert wurde.

Um dieses Problem zu vermeiden, sollten Sie Vorbeugemaßnahmen ergreifen, wenn Sie eine solche Anwendung für die Verwendung einer Datenbank einrichten, die auf einer Remoteinstanz von SQL Servergehostet wird. Eine Vorbeugungsmaßnahme besteht darin, die Anmeldenamen und Kennwörter von der lokalen Instanz von SQL Server auf die Remoteinstanz von SQL Serverzu übertragen. Weitere Informationen zum Verhindern dieses Problems finden Sie im KB-Artikel 918992-How to transfer the logins and the passwords between instances of SQL Server).

Hinweis

Dieses Problem betrifft lokale Windows-Konten auf unterschiedlichen Computern. Bei Domänenkonten tritt das Problem jedoch nicht auf, da die SID auf allen Computern identisch ist.

Weitere Informationen finden Sie unter Verwaiste Benutzer bei Datenbankspiegelung und Protokollversand (Blog zur Datenbank-Engine).

Verwandte Aufgaben

Siehe auch

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)
Eigenständige Datenbanken
Arbeitsplätze schaffen

  • Last updated on