Verwalten von Anmeldungen und Anmeldeaufträgen nach einem Rollenwechsel

Es wird nur der Inhalt der Prinzipaldatenbank gespiegelt. Zugeordnete Informationen in den master- oder msdb-Systemdatenbanken können nicht gespiegelt werden. Zu diesen zugeordneten Informationen gehören Aufträge, die für die Prinzipaldatenbank eingerichtet werden, und Anmeldungen, die zum Prinzipalserver hinzugefügt werden.

Wenn diese Informationen für die Unterstützung des Rollenwechsels wichtig sind, sollten sie auf der gespiegelten Site dupliziert werden. Nach dem Rollenwechsel sollten die Informationen möglichst in der neuen Prinzipaldatenbank programmgesteuert reproduziert werden. Am häufigsten tauchen Probleme im Zusammenhang mit Anmeldungen und Aufträgen auf.

Benutzernamen

Damit Benutzer nach einem Rollenwechsel auf die Datenbank zugreifen können, muss eine Anmeldung für den Prinzipalserver mit Zugriffsberechtigungen für die Prinzipaldatenbank auch auf dem Spiegelserver definiert werden. Die master-Datenbank kann jedoch nicht gespiegelt werden. Wenn Sie auf dem aktuellen Prinzipalserver einen neuen Anmeldenamen für diese Anmeldung bei der Prinzipaldatenbank erstellen, müssen Sie dies also auch auf dem Spiegelserver tun.

Die Anmeldung muss für jeden Benutzer der Datenbank manuell auf dem Spiegel- und auf dem Prinzipalserver definiert werden. Andernfalls können Benutzer, deren Anmeldungen nicht auf dem früheren Spiegelserver definiert sind, nicht auf den neuen Prinzipalserver zugreifen, wenn die Prinzipalrolle gewechselt wird und der frühere Spiegelserver seine Datenbank als Prinzipaldatenbank anbietet. Die Benutzer sind verwaist.

Wenn ein Benutzer auf dem neuen Prinzipalserver verwaist ist, erstellen Sie die Anmeldung auf dem neuen Prinzipalserver, und führen Sie sp_change_users_login (Transact-SQL) aus. Weitere Informationen finden Sie unter Problembehandlung bei verwaisten Benutzern.

Anmeldenamen von Anwendungen, die die SQL Server-Authentifizierung verwenden

Wenn eine Anwendung, die versucht, eine Verbindung mit einer gespiegelten Datenbank herzustellen, die SQL Server-Authentifizierung verwendet, kann ein SID-Konflikt dazu führen, dass der Anmeldename der Anwendung nach einem Failover nicht aufgelöst werden kann. Dadurch wird der Anmeldename zu einem verwaisten Benutzer. Sie können einen verwaisten Benutzer mit sp_change_users_login auflösen (siehe Problembehandlung bei verwaisten Benutzern).

Es wird jedoch empfohlen, Vorbeugemaßnahmen zu ergreifen, wenn Sie eine solche Anwendung für die Verwendung der Spiegeldatenbank einrichten. Weitere Informationen zu Vermeidung dieses Problems finden Sie im KB-Artikel 918992 Übertragen der Anmeldenamen und Kennwörter zwischen Instanzen von SQL Server 2005 und SQL Server 2008.

Hinweis
Dieses Problem tritt bei der Windows-Authentifizierung nicht auf, weil die SIDs für Windows-Anmeldenamen nicht computerspezifisch sind und von Active Directory bereitgestellt werden.

Aufträge

Aufträge, wie z. B. Sicherungsaufträge, erfordern besondere Aufmerksamkeit. Nach einem Rollenwechsel muss der Datenbankbesitzer oder der Systemadministrator die Aufträge für die neue Prinzipaldatenbank gewöhnlich erneut erstellen.

Wenn der frühere Prinzipalserver verfügbar ist, sollten Sie die ursprünglichen Aufträge auch aus der neuen Spiegeldatenbank löschen. Es treten Fehler bei Aufträgen in der Spiegeldatenbank auf, da die Datenbank den RESTORING-Status hat und daher nicht verfügbar ist.

Hinweis
Die Partner sind möglicherweise anders konfiguriert und haben beispielsweise andere Bandlaufwerkbuchstaben. Bei den Aufträgen für die einzelnen Partner müssen derartige Unterschiede berücksichtigt werden.

Siehe auch

Konzepte

Problembehandlung bei verwaisten Benutzern