Teilen über

Verwalten von Anmeldungen für Aufträge mithilfe von Datenbanken in einer Always On-Verfügbarkeitsgruppe

  • Artikel

Gilt für: SQL Server

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

  • SQL Server -Agentaufträge

    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 VG hosten, könnten unterschiedlich konfiguriert sein, z. B. mit anderen Laufwerkbuchstaben. Bei den Aufträgen für die einzelnen Verfügbarkeitsreplikate müssen derartige Unterschiede berücksichtigt werden.

    Sicherungsaufträge, die sys.fn_hadr_backup_is_preferred_replica-Funktion verwenden können, um zu identifizieren, ob das lokale Replikat entsprechend den Sicherungseinstellungen der VG das bevorzugte Replikat für Sicherungen ist. Mit Verwendung des Wartungsplanungs-Assistenten erstellte Sicherungsaufträge verwenden diese Funktion systemintern. 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 Auslagern von unterstützten Sicherungen auf sekundäre Replikate einer Verfügbarkeitsgruppe.

  • Anmeldungen

    Wenn Sie eigenständige Datenbanken verwenden, können Sie enthaltene Benutzer in den Datenbanken konfigurieren. Für diese Benutzer müssen Sie keine Anmeldenamen auf den Serverinstanzen erstellen, die ein sekundäres Replikat hosten. Für eine nicht eigenständige 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 SQL Server -Authentifizierung oder eine lokale Windows-Anmeldung verwendet, siehe Anmeldenamen von Anwendungen, die die SQL Server-Authentifizierung oder eine lokale Windows-Anmeldung verwenden weiter unten in diesem Artikel.

    Hinweis

    Ein Datenbankbenutzer, für den die SQL Server-Anmeldung auf einer Serverinstanz nicht oder falsch definiert ist, kann sich bei der Instanz nicht 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

    Anmeldenamen und Aufträge sind nicht die einzigen Informationen, die auf jeder Serverinstanz, die für eine gegebene VG ein sekundäres Replikat hostet, neu erstellt werden müssen. Beispielsweise müssen Sie möglicherweise Serverkonfigurationseinstellungen, Anmeldeinformationen, verschlüsselte Daten, Berechtigungen, Replikationseinstellungen, Service Broker-Anwendungen, Trigger (auf Serverebene) usw., neu erstellen. Weitere Informationen finden Sie unter Verwalten von Metadaten beim Bereitstellen einer Datenbank auf einem anderen Server.

SQL Server-Authentifizierung oder lokale Windows-Anmeldung

Wenn eine Anwendung die SQL Server-Authentifizierung oder eine lokale Windows-Anmeldung verwendet, können nicht übereinstimmende Sicherheits-ID (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.

Sie sollten Vorbeugemaßnahmen ergreifen, wenn Sie eine 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 zur Vermeidung dieses Problems finden Sie im KB-Artikel 918992-Übertragen von Benutzernamen und Kennwörtern zwischen Instanzen von 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).

Zugehöriger Inhalt