Verwalten von Metadaten beim Bereitstellen einer Datenbank auf einer anderen Serverinstanz (SQL Server)

Artikel
06/25/2013

Dieses Thema ist in den folgenden Situationen relevant:

Konfigurieren der Verfügbarkeitsreplikate einer AlwaysOn-Verfügbarkeitsgruppen-Verfügbarkeitsgruppe.
Einrichten der Datenbankspiegelung für eine Datenbank.
Beim Vorbereiten einer Rollenänderung zwischen primären und sekundären Servern in einer Protokollversandkonfiguration.
Wiederherstellen einer Datenbank auf einer anderen Serverinstanz.
Anfügen einer Kopie einer Datenbank an eine andere Serverinstanz.

Einige Anwendungen sind von Informationen, Entitäten und/oder Objekten abhängig, die sich außerhalb des Bereichs einer einzelnen Benutzerdatenbank befinden. Normalerweise weist eine Anwendung Abhängigkeiten von den Datenbanken master und msdb sowie von der Benutzerdatenbank auf. Alle Daten, die außerhalb einer Benutzerdatenbank gespeichert werden und für die richtige Funktionsweise dieser Datenbank erforderlich sind, müssen auf der Zielserverinstanz bereitgestellt werden. Beispielsweise werden die Anmeldungen für eine Anwendung als Metadaten in der master-Datenbank gespeichert, und sie müssen auf dem Zielserver neu erstellt werden. Wenn ein Anwendungs- oder Datenbank-Wartungsplan von Aufträgen des SQL Server-Agents abhängig ist, deren Metadaten in der msdb-Datenbank gespeichert sind, müssen Sie diese Aufträge auf der Zielserverinstanz neu erstellen. Analog dazu werden die Metadaten für einen Trigger auf Serverebene in master gespeichert.

Wenn Sie die Datenbank für eine Anwendung auf eine andere Serverinstanz verschieben, müssen Sie alle Metadaten der abhängigen Entitäten und Objekte in master und msdb auf der Zielserverinstanz neu erstellen. Wenn für eine Datenbankanwendung beispielsweise Trigger auf Serverebene verwendet werden, genügt es nicht, die Datenbank im neuen System lediglich anzufügen oder wiederherzustellen. Die Datenbank funktioniert nicht wie erwartet, wenn Sie die Metadaten für diese Trigger in der master-Datenbank nicht manuell neu erstellen.

Informationen, Entitäten und Objekte, die außerhalb der Benutzerdatenbanken gespeichert werden

Im übrigen Teil dieses Themas werden die potenziellen Probleme zusammengefasst, die eine Datenbank betreffen können, die auf einer anderen Serverinstanz bereitgestellt werden soll. Möglicherweise müssen Sie einen oder mehrere Typen von Informationen, Entitäten oder Objekten neu erstellen, die in der folgenden Liste aufgeführt sind. Klicken Sie zum Anzeigen einer Zusammenfassung auf den Link für das Element.

Serverkonfigurationseinstellungen
Anmeldeinformationen
Datenbankübergreifende Abfragen
Datenbankbesitz
Verteilte Abfragen/Verbindungsserver
Verschlüsselte Daten
Benutzerdefinierte Fehlermeldungen
Ereignisbenachrichtigungen und WMI-Ereignisse (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation) auf Serverebene
Erweiterte gespeicherte Prozeduren
Eigenschaften des Volltextsuchmoduls für SQL Server
Aufträge
Benutzernamen
Berechtigungen
Replikationseinstellungen
Service Broker-Anwendungen
Autostartprozeduren
Trigger (auf Serverebene)

Serverkonfigurationseinstellungen

In SQL Server 2005 und höheren Versionen werden wichtige Dienste und Funktionen selektiv installiert und gestartet. Auf diese Weise wird die angreifbare Oberfläche eines Systems verringert. Bei neuen Installationen sind viele Funktionen in der Standardkonfiguration nicht aktiviert. Wenn die Datenbank von einem standardmäßig deaktivierten Dienst oder Funktion abhängig ist, muss dieser Dienst bzw. diese Funktion auf der Zielserverinstanz aktiviert werden.

Weitere Informationen zu diesen Einstellungen sowie Informationen zum Aktivieren oder Deaktivieren dieser Einstellungen finden Sie unter Serverkonfigurationsoptionen.

[Nach oben]

Anmeldeinformationen

Anmeldeinformationen sind in einem Datensatz gespeichert, in dem die Authentifizierungsinformationen enthalten sind, die zum Herstellen einer Verbindung mit einer Ressource außerhalb von SQL Server erforderlich sind. Die meisten Anmeldeinformationen bestehen aus einem Windows-Anmeldenamen und -Kennwort.

Informationen zu dieser Funktion finden Sie unter Anmeldeinformationen (Datenbankmodul).

Hinweis
Für Proxykonten des SQL Server-Agents werden Anmeldeinformationen verwendet. Die ID der von einem Proxykonto verwendeten Anmeldeinformationen kann anhand der sysproxies-Systemtabelle festgestellt werden.

[Nach oben]

Datenbankübergreifende Abfragen

Die Datenbankoptionen DB_CHAINING und TRUSTWORTHY sind standardmäßig auf OFF festgelegt. Falls eine dieser Optionen für die ursprüngliche Datenbank auf ON festgelegt ist, müssen Sie die betreffende Option u. U. auch auf der Zielserverinstanz aktivieren. Weitere Informationen finden Sie unter ALTER DATABASE (Transact-SQL).

Durch Anfüge- und Trennvorgänge wird die datenbankübergreifende Besitzverkettung für die Datenbank deaktiviert. Informationen zum Aktivieren der Verkettung finden Sie unter Datenbankübergreifende Besitzverkettung (Serverkonfigurationsoption).

Weitere Informationen finden Sie auch unter Einrichten der TRUSTWORTHY-Eigenschaft für eine Spiegeldatenbank (Transact-SQL).

[Nach oben]

Datenbankbesitz

Wenn eine Datenbank auf einem anderen Computer wiederhergestellt wird, wird der SQL Server-Anmeldename oder der Windows-Benutzer, der den Wiederherstellungsvorgang initiiert, automatisch zum Besitzer der neuen Datenbank. Nach dem Wiederherstellen der Datenbank kann der Systemadministrator oder der neue Datenbankbesitzer den Datenbankbesitz ändern.

Verteilte Abfragen und Verbindungsserver

Verteilte Abfragen und Verbindungsserver werden für OLE DB-Anwendungen unterstützt. Verteilte Abfragen greifen auf Daten von mehreren heterogenen Datenquellen auf demselben oder auf unterschiedlichen Computern zu. Durch die Konfiguration von Verbindungsservern ist es SQL Server möglich, Befehle für OLE DB-Datenquellen auf Remoteservern auszuführen. Weitere Informationen zu diesen Funktionen finden Sie unter Verbindungsserver (Datenbankmodul).

[Nach oben]

Verschlüsselte Daten

Wenn die Datenbank, die Sie auf einer anderen Serverinstanz verfügbar machen, verschlüsselte Daten enthält und wenn der Datenbank-Hauptschlüssel durch den Diensthauptschlüssel auf dem ursprünglichen Server geschützt wird, muss die Verschlüsselung des Diensthauptschlüssels u. U. neu erstellt werden. Der Datenbank-Hauptschlüssel ist ein symmetrischer Schlüssel, der zum Schützen von privaten Schlüsseln von Zertifikaten und asymmetrischen Schlüsseln in einer verschlüsselten Datenbank verwendet wird. Beim Erstellen wird der Datenbank-Hauptschlüssel mithilfe des Triple DES-Algorithmus und eines vom Benutzer angegebenen Kennworts verschlüsselt.

Um die automatische Entschlüsselung des Datenbank-Hauptschlüssels auf einer Serverinstanz zu ermöglichen, wird eine Kopie dieses Schlüssels mit dem Diensthauptschlüssel verschlüsselt. Diese verschlüsselte Kopie wird sowohl in der Datenbank als auch in der master-Datenbank gespeichert. In der Regel wird die in master gespeicherte Kopie im Hintergrund aktualisiert, sobald der Hauptschlüssel geändert wird. SQL Server versucht zuerst, den Datenbank-Hauptschlüssel mit dem Diensthauptschlüssel der Instanz zu entschlüsseln. Wenn beim Entschlüsseln ein Fehler auftritt, wird der Anmeldeinformationsspeicher von SQL Server nach Anmeldeinformationen des Hauptschlüssels durchsucht, die dieselbe Familien-GUID wie die Datenbank aufweisen, für die der Hauptschlüssel benötigt wird. Anschließend versucht SQL Server, den Datenbank-Hauptschlüssel mit allen übereinstimmenden Anmeldeinformationen zu entschlüsseln, bis die Entschlüsselung erfolgreich ausgeführt wurde oder keine Anmeldeinformationen mehr vorhanden sind. Ein Hauptschlüssel, der nicht mit dem Diensthauptschlüssel verschlüsselt ist, muss mithilfe der OPEN MASTER KEY-Anweisung und eines Kennworts geöffnet werden.

Wird eine verschlüsselte Datenbank auf eine neue Instanz von SQL Server kopiert, auf dieser wiederhergestellt oder an diese angefügt, wird keine Kopie des vom Diensthauptschlüssels verschlüsselten Datenbank-Hauptschlüssels in der master-Datenbank der Zielserverinstanz gespeichert. Auf der Zielserverinstanz müssen Sie den Hauptschlüssel der Datenbank öffnen. Führen Sie zum Öffnen des Hauptschlüssels die folgende Anweisung aus: OPEN MASTER KEY DECRYPTION BY PASSWORD = 'password'. Es empfiehlt sich, die automatische Entschlüsselung des Datenbank-Hauptschlüssels mit folgender Anweisung zu aktivieren: ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. Durch diese ALTER MASTER KEY-Anweisung wird für die Serverinstanz eine Kopie des mit dem Diensthauptschlüssel verschlüsselten Datenbank-Hauptschlüssels bereitgestellt. Weitere Informationen finden Sie unter OPEN MASTER KEY (Transact-SQL) und ALTER MASTER KEY (Transact-SQL).

Informationen zum Aktivieren der automatischen Entschlüsselung des Datenbank-Hauptschlüssels einer Spiegeldatenbank finden Sie unter Einrichten einer verschlüsselten Spiegeldatenbank.

Weitere Informationen finden Sie auch unter:

[Nach oben]

Benutzerdefinierte Fehlermeldungen

Benutzerdefinierte Fehlermeldungen sind in der sys.messages-Katalogsicht enthalten. Diese Katalogsicht wird in der master-Datenbank gespeichert. Wenn eine Datenbankanwendung benutzerdefinierte Fehlermeldungen verwenden muss und die Datenbank auf einer anderen Serverinstanz bereitgestellt wird, können Sie mit sp_addmessage diese Fehlermeldungen auf der Zielserverinstanz hinzufügen.

[Nach oben]

Ereignisbenachrichtigungen und WMI-Ereignisse (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation) auf Serverebene

Ereignisbenachrichtigungen auf Serverebene

Ereignisbenachrichtigungen auf Serverebene werden in msdb gespeichert. Wenn eine Datenbankanwendung von einer Ereignisbenachrichtigung auf Serverebene abhängt, muss diese Ereignisbenachrichtigung daher auf der Zielserverinstanz neu erstellt werden. Die Ereignisbenachrichtigungen auf einer Serverinstanz werden in der sys.server_event_notifications-Katalogsicht angezeigt. Weitere Informationen finden Sie unter Ereignisbenachrichtigungen.

Zudem werden Ereignisbenachrichtigungen mithilfe von Service Broker übermittelt. Routen für eingehende Nachrichten sind in der Datenbank, die einen Dienst enthält, nicht eingeschlossen. Stattdessen werden explizite Routen in msdb gespeichert. Wenn Ihr Dienst eine explizite Route in der msdb-Datenbank verwendet, um eingehende Nachrichten an den Dienst weiterzuleiten, müssen Sie diese Route erneut erstellen, wenn Sie eine Datenbank in einer anderen Instanz anfügen.

WMI-Ereignisse (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation)

Über den WMI-Anbieter für Serverereignisse können Sie Ereignisse in SQL Server mithilfe von WMI (Windows Management Instrumentation) überwachen. Jede Anwendung, die auf Ereignissen der Serverebene beruht, die über den WMI-Anbieter verfügbar gemacht werden, auf dem eine Datenbank beruht, muss für den Computer der Zielserverinstanz definiert werden. Der WMI-Ereignisanbieter erstellt Ereignisbenachrichtigungen mit einem Zieldienst, der in msdb definiert wird.

Hinweis
Weitere Informationen finden Sie unter Konzepte des WMI-Anbieters für Serverereignisse.

So erstellen Sie mithilfe von SQL Server Management Studio eine WMI-Warnung

Erstellen einer WMI-Ereigniswarnung

So funktionieren Ereignisbenachrichtigungen für eine gespiegelte Datenbank

Die datenbankübergreifende Übermittlung von Ereignisbenachrichtigungen, an der eine gespiegelte Datenbank beteiligt ist, erfolgt grundsätzlich remote, da für die gespiegelte Datenbank ein Failover auftreten kann. In Service Broker wird eine besondere Unterstützung für gespiegelte Datenbanken in Form von gespiegelten Routen bereitgestellt. Eine gespiegelte Route weist zwei Adressen auf: eine für die Prinzipalserverinstanz und eine für die Spiegelserverinstanz.

Durch das Einrichten gespiegelter Routen wird dem Service Broker-Routing die Datenbankspiegelung bewusst gemacht. Durch die gespiegelten Routen wird es Service Broker ermöglicht, Konversationen mit der aktuellen Prinzipalserverinstanz transparent weiterzuleiten. Stellen Sie sich beispielsweise einen Dienst (Service_A) vor, der von einer gespiegelten Datenbank (Database_A) gehostet wird. Angenommen, Sie benötigen einen weiteren Dienst (Service_B), der von Database_B gehostet wird, sodass ein Dialog mit Service_A stattfinden kann. Damit dieser Dialog möglich ist, muss Database_B eine gespiegelte Route für Service_A enthalten. Zudem muss Database_A eine nicht gespiegelte TCP-Transportroute zu Service_B enthalten, die im Gegensatz zu einer lokalen Route nach einem Failover gültig bleibt. Mit diesen Routen können ACKs nach einem Failover wiederkehren. Da der Dienst des Absenders stets auf dieselbe Art und Weise benannt wird, muss mit der Route die Broker-Instanz angegeben werden.

Die Anforderung für gespiegelte Routen gilt unabhängig davon, ob der Dienst in der gespiegelten Datenbank den Initiatordienst darstellt oder den Zieldienst:

Wenn sich der Zieldienst in der gespiegelten Datenbank befindet, muss der Initiatordienst eine gespiegelte Route zum Ziel zurück aufweisen. Das Ziel kann jedoch eine normale Route zurück zum Initiator besitzen.
Wenn sich der Initiatordienst in der gespiegelten Datenbank befindet, muss der Zieldienst eine gespiegelte Route zum Initiator zurück aufweisen, damit Bestätigungen und Antworten übermittelt werden können. Der Initiator kann jedoch eine normale Route zum Ziel besitzen.

[Nach oben]

Erweiterte gespeicherte Prozeduren

Wichtig
Diese Funktion wird in zukünftigen Versionen von Microsoft SQL Server nicht mehr bereitgestellt. Verwenden Sie diese Funktion beim Entwickeln neuer Anwendungen nicht, und planen Sie das Ändern von Anwendungen, in denen es zurzeit verwendet wird. Verwenden Sie stattdessen die CLR-Integration.

Erweiterte gespeicherte Prozeduren werden mithilfe der API für erweiterte gespeicherte Prozeduren von SQL Server programmiert. Mitglieder der festen Serverrolle sysadmin können eine erweiterte gespeicherte Prozedur bei einer Instanz von SQL Server registrieren und anderen Benutzern Berechtigungen zum Ausführen der Prozedur erteilen. Erweiterte gespeicherte Prozeduren können nur zur master-Datenbank hinzugefügt werden.

Erweiterte gespeicherte Prozeduren werden direkt im Adressraum einer Instanz von SQL Server ausgeführt und können Arbeitsspeicherverluste oder andere Probleme hervorrufen, die die Leistung und Zuverlässigkeit des Servers reduzieren. Sie sollten in Betracht ziehen, erweiterte gespeicherte Prozeduren in einer anderen Instanz von SQL Server als der Instanz zu speichern, die die Daten enthält, auf die verwiesen wird. Erwägen Sie auch die Verwendung von verteilten Abfragen für den Zugriff auf die Datenbank.

Wichtig
Systemadministratoren sollten, bevor sie dem Server erweiterte gespeicherte Prozeduren hinzufügen und Benutzern EXECUTE-Berechtigungen für die Prozedur erteilen, jede Prozedur gründlich überprüfen, um sicherzustellen, dass sie keinen schädlichen oder bösartigen Code enthält.

Weitere Informationen finden Sie unter GRANT (Objektberechtigungen) (Transact-SQL), DENY (Objektberechtigungen) (Transact-SQL) und REVOKE-Objektberechtigungen (Transact-SQL).

[Nach oben]

Eigenschaften des Volltextsuchmoduls für SQL Server

Die Eigenschaften für das Volltextsuchmodul werden mit sp_fulltext_service festgelegt. Stellen Sie sicher, dass die Zielserverinstanz die erforderlichen Einstellungen für diese Eigenschaften aufweist. Weitere Informationen zu diesen Eigenschaften finden Sie unter FULLTEXTSERVICEPROPERTY (Transact-SQL).

Wenn die Wörtertrennungs- und Wortstammerkennungs-Komponente oder die Filterkomponente auf der ursprünglichen Serverinstanz und der Zielserverinstanz jeweils unterschiedliche Versionen haben, weisen die Volltextindizierung und die Volltextabfragen möglicherweise ein anderes Verhalten auf. Ebenso wird der Thesaurus in instanzspezifischen Dateien gespeichert. Sie müssen entweder eine Kopie dieser Dateien in einen entsprechenden Speicherort auf der Zielserverinstanz übertragen oder die Dateien auf der neuen Instanz erneut erstellen.

Hinweis
Wenn Sie eine SQL Server 2005-Datenbank mit Volltextkatalogdateien an eine SQL Server 2012-Serverinstanz anfügen, werden die Katalogdateien von ihrem vorherigen Speicherort aus zusammen mit den anderen Datenbankdateien angefügt. Dies entspricht der Vorgehensweise in SQL Server 2005. Weitere Informationen finden Sie unter Aktualisieren der Volltextsuche von SQL Server 2005.

Weitere Informationen finden Sie auch unter:

[Nach oben]

Aufträge

Wenn die Datenbank SQL Server-Agent-Aufträge verwendet, müssen Sie diese auf der Zielserverinstanz neu erstellen. Aufträge sind von der jeweiligen Umgebung abhängig. Wenn Sie vorhaben, einen vorhandenen Auftrag auf der Zielserverinstanz neu zu erstellen, müssen Sie die Zielserverinstanz ggf. so ändern, dass sie mit der Umgebung dieses Auftrags auf der ursprünglichen Serverinstanz übereinstimmt. Die folgenden Umgebungsfaktoren sind dabei von Bedeutung:

Der vom Auftrag verwendete Anmeldename

Wenn Sie SQL Server-Agent-Aufträge erstellen oder ausführen möchten, müssen Sie der Zielserverinstanz zuerst alle für den Auftrag erforderlichen SQL Server-Anmeldenamen hinzufügen. Weitere Informationen finden Sie unter Konfigurieren eines Benutzers zum Erstellen und Verwalten von SQL Server-Agent-Aufträgen.
Startkonto für den SQL Server-Agent-Dienst

Das Dienststartkonto definiert das Microsoft Windows-Konto, in dem der SQL Server-Agent ausgeführt wird, und legt dessen Netzwerkberechtigungen fest. Der SQL Server-Agent wird als angegebenes Benutzerkonto ausgeführt. Der Kontext des Agent-Diensts hat eine Auswirkung auf die Einstellungen für den Auftrag und dessen Ausführungsumgebung. Das Konto muss Zugriff auf die vom Auftrag benötigten Ressourcen haben, z. B. auf Netzwerkfreigaben. Informationen zum Auswählen und Ändern des Dienststartkontos finden Sie unter Auswählen eines Kontos für den SQL Server-Agent-Dienst.

Damit eine ordnungsgemäße Funktionsweise sichergestellt ist, muss das Dienststartkonto mit den richtigen Domänen-, Dateisystem- und Registrierungsberechtigungen konfiguriert sein. Ein Auftrag benötigt u. U. auch eine freigegebene Netzwerkressource, die für das Dienstkonto konfiguriert werden muss. Weitere Informationen finden Sie unter Konfigurieren von Windows-Dienstkonten und -Berechtigungen.

Der SQL Server-Agent-Dienst ist einer bestimmten Instanz von SQL Server zugeordnet und verfügt über eine eigene Registrierungsstruktur. Die Aufträge dieses Agents hängen in der Regel von einer oder mehreren Einstellungen in dieser Registrierungsstruktur ab. Das gewünschte Verhalten eines Auftrags ist nur dann sichergestellt, wenn diese Registrierungseinstellungen vorliegen. Wenn Sie einen Auftrag mithilfe eines Skripts in einem anderen SQL Server-Agent-Dienst neu erstellen, sind in dessen Registrierung möglicherweise nicht die richtigen Einstellungen für diesen Auftrag vorhanden. Damit sich die auf einer Zielserverinstanz neu erstellten Aufträge wie gewünscht verhalten, müssen der ursprüngliche SQL Server-Agent-Dienst und der SQL Server-Agent-Zieldienst die gleichen Regstrierungseinstellungen aufweisen.

Vorsicht
Das Ändern der Registrierungseinstellungen auf dem SQL Server-Agent-Zieldienst zum Verarbeiten eines neu erstellten Auftrags kann zu Problemen führen, wenn die aktuellen Einstellungen auch für andere Aufträge erforderlich sind. Ein fehlerhaftes Bearbeiten der Registrierung kann zudem eine schwerwiegende Beschädigung Ihres Systems zur Folge haben. Bevor Sie Änderungen an der Registrierung vornehmen, ist es empfehlenswert, alle wichtigen Daten zu sichern, die sich auf dem Computer befinden.

Das Ändern der Registrierungseinstellungen auf dem SQL Server-Agent-Zieldienst zum Verarbeiten eines neu erstellten Auftrags kann zu Problemen führen, wenn die aktuellen Einstellungen auch für andere Aufträge erforderlich sind. Ein fehlerhaftes Bearbeiten der Registrierung kann zudem eine schwerwiegende Beschädigung Ihres Systems zur Folge haben. Bevor Sie Änderungen an der Registrierung vornehmen, ist es empfehlenswert, alle wichtigen Daten zu sichern, die sich auf dem Computer befinden.

SQL Server-Agent-Proxys

Von einem SQL Server-Agent-Proxy wird der Sicherheitskontext für einen angegebenen Auftragsschritt definiert. Damit ein Auftrag auf der Zielserverinstanz ausgeführt werden kann, müssen alle dafür erforderlichen Proxys auf dieser Instanz manuell neu erstellt werden. Weitere Informationen finden Sie unter Erstellen eines Proxys für den SQL Server-Agent und Problembehandlung von proxybasierten Multiserveraufträgen.

Weitere Informationen finden Sie auch unter:

Implementieren von Aufträgen
Verwaltung von Anmeldenamen und Aufträgen nach einem Rollenwechsel (SQL Server) (für die Datenbankspiegelung)
Konfigurieren von Windows-Dienstkonten und -Berechtigungen (beim Installieren einer Instanz von SQL Server)
Konfigurieren des SQL Server-Agents (beim Installieren einer Instanz von SQL Server)
Implementieren der SQL Server-Agent-Sicherheit

So zeigen Sie vorhandene Aufträge und deren Eigenschaften an

So erstellen Sie einen Auftrag

Bewährte Methoden zum erneuten Erstellen eines Auftrags mithilfe eines Skripts

Es wird empfohlen, zunächst ein Skript für einen einfachen Auftrag zu erstellen, den Auftrag für einen anderen SQL Server-Agent-Dienst neu zu erstellen und dann den Auftrag auszuführen, um zu sehen, ob er sich wie gewünscht verhält. Auf diese Weise können Sie Inkompatibilitäten feststellen und versuchen, diese zu lösen. Wenn ein durch Skript erstellter Auftrag in der neuen Umgebung nicht wie beabsichtigt ausgeführt wird, sollten Sie einen äquivalenten Auftrag erstellen, der in der betreffenden Umgebung ordnungsgemäß ausgeführt wird.

[Nach oben]

Anmeldenamen

Für die Anmeldung bei einer Instanz von SQL Server ist ein gültiger SQL Server-Anmeldename erforderlich. Dieser Anmeldename wird bei der Authentifizierung verwendet, die überprüft, ob der Prinzipal eine Verbindung mit der SQL Server-Instanz herstellen kann. Ein Datenbankbenutzer, für den ein entsprechender SQL Server-Anmeldename 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. Ein Datenbankbenutzer kann zu einem verwaisten Benutzer werden, wenn die Datenbank auf einer anderen SQL Server-Instanz wiederhergestellt, an eine andere SQL Server-Instanz angefügt oder auf eine andere Instanz kopiert wird.

Zum Erstellen eines Skripts für einige oder für alle Objekte in der ursprünglichen Kopie der Datenbank können Sie den Assistenten zum Generieren von SQL Server-Skripts verwenden und im Dialogfeld Skriptoptionen auswählen die Option Skripterstellung für Anmeldungen auf True festlegen.

Hinweis
Informationen zum Einrichten von Anmeldenamen für eine gespiegelte Datenbank finden Sie unter Einrichten von Anmeldekonten für die Datenbankspiegelung oder AlwaysOn-Verfügbarkeitsgruppen (SQL Server) und Verwaltung von Anmeldenamen und Aufträgen nach einem Rollenwechsel (SQL Server).

[Nach oben]

Berechtigungen

Möglicherweise werden die folgenden Berechtigungstypen beeinflusst, wenn eine Datenbank auf einer anderen Serverinstanz verfügbar gemacht wird.

GRANT-, REVOKE- oder DENY-Berechtigungen für Systemobjekte
GRANT-, REVOKE- oder DENY-Berechtigungen für die Serverinstanz (Berechtigungen auf Serverebene)

GRANT-, REVOKE- und DENY-Berechtigungen für Systemobjekte

Berechtigungen für Systemobjekte wie z. B. gespeicherte Prozeduren, erweiterte gespeicherte Prozeduren, Funktionen und Sichten werden in der master-Datenbank gespeichert und müssen auf der Zielserverinstanz konfiguriert werden.

Wichtig
Wenn Sie Skripts für Anmeldungen erstellen, werden keine Skripts für die Kennwörter erstellt. Bei Anmeldungen, die die SQL Server-Authentifizierung verwenden, müssen Sie das Skript auf dem Ziel ändern.

Systemobjekte werden in der sys.system_objects-Katalogsicht angezeigt. Die Berechtigungen für Systemobjekte werden in der sys.database_permissions-Katalogsicht in der master-Datenbank angezeigt. Informationen zum Abfragen dieser Katalogsichten und zum Erteilen von Berechtigungen für Systemobjekte finden Sie unter GRANT (Berechtigungen für Systemobjekte) (Transact-SQL). Weitere Informationen finden Sie unter REVOKE (Berechtigungen für Systemobjekte) (Transact-SQL) und DENY (Berechtigungen für Systemobjekte) (Transact-SQL).

GRANT-, REVOKE- und DENY-Berechtigungen für eine Serverinstanz

Die Berechtigungen im Serverbereich werden in der master-Datenbank gespeichert und müssen auf der Zielserverinstanz konfiguriert werden. Informationen zu den Serverberechtigungen einer Serverinstanz erhalten Sie durch Abfragen der sys.server_permissions-Katalogsicht, Informationen zu Serverprinzipalen erhalten Sie durch Abfragen der sys.server_principals-Katalogsicht, und Informationen zur Mitgliedschaft von Serverrollen erhalten Sie durch Abfragen der sys.server_role_members-Katalogsicht.

Weitere Informationen finden Sie unter GRANT (Serverberechtigungen) (Transact-SQL), REVOKE (Serverberechtigungen) (Transact-SQL) und DENY (Serverberechtigungen) (Transact-SQL).

Berechtigungen auf Serverebene für ein Zertifikat oder einen asymmetrischen Schlüssel

Einem Zertifikat oder einem asymmetrischen Schlüssel können Berechtigungen auf Serverebene nicht direkt erteilt werden. Berechtigungen auf Serverebene werden stattdessen einem zugeordneten Anmeldenamen erteilt, der ausschließlich für ein bestimmtes Zertifikat oder einen bestimmten asymmetrischen Schlüssel erstellt wird. Jedes Zertifikat oder jeder asymmetrische Schlüssel, für das bzw. den Berechtigungen auf Serverebene erforderlich sind, benötigt daher einen eigenen dem Zertifikat zugeordneten Anmeldenamen bzw. einen eigenen dem asymmetrischen Schlüssel zugeordneten Anmeldenamen. Wenn Sie einem Zertifikat oder einem asymmetrischen Schlüssel Berechtigungen auf Serverebene erteilen möchten, müssen Sie die Berechtigungen dem jeweils zugeordneten Anmeldenamen erteilen.

Hinweis
Ein zugeordneter Anmeldename wird nur für die Autorisierung von Code verwendet, der mit dem entsprechenden Zertifikat oder asymmetrischen Schlüssel signiert ist. Zugeordnete Anmeldenamen können nicht für Authentifizierungszwecke verwendet werden.

Der zugeordnete Anmeldename und dessen Berechtigungen werden in der master-Datenbank gespeichert. Zertifikate oder asymmetrische Schlüssel, die sich in einer anderen Datenbank als der master-Datenbank befinden, müssen in der master-Datenbank neu erstellt und einem Anmeldenamen zugeordnet werden. Wenn Sie die Datenbank auf eine andere Serverinstanz verschieben oder kopieren bzw. auf einer anderen Serverinstanz wiederherstellen, müssen Sie das zugehörige Zertifikat oder den zugehörigen asymmetrischen Schlüssel in der master-Datenbank der Zielserverinstanz neu erstellen, einem Anmeldenamen zuordnen und dem Anmeldenamen die erforderlichen Berechtigungen auf Serverebene erteilen.

So erstellen Sie ein Zertifikat oder einen asymmetrischen Schlüssel

So ordnen Sie einem Anmeldenamen ein Zertifikat oder einen asymmetrischen Schlüssel zu

CREATE LOGIN (Transact-SQL)

So weisen Sie dem zugeordneten Anmeldenamen Berechtigungen zu

GRANT (Serverberechtigungen) (Transact-SQL)

Weitere Informationen zu Zertifikaten und asymmetrischen Schlüsseln finden Sie unter Verschlüsselungshierarchie.

[Nach oben]

Replikationseinstellungen

Wenn Sie eine Sicherungskopie einer replizierten Datenbank auf einem anderen Server bzw. in einer anderen Datenbank wiederherstellen, können Replikationseinstellungen nicht beibehalten werden. In diesem Fall müssen nach der Wiederherstellung der Sicherungskopien sämtliche Veröffentlichungen und Abonnements neu erstellt werden. Um diesen Vorgang zu vereinfachen, können Sie für die aktuellen Replikationseinstellungen und auch für das Aktivieren und Deaktivieren der Replikation Skripts erstellen. Damit Sie diese Skripts beim Neuerstellen der Replikationseinstellungen verwenden können, kopieren Sie diese Skripts, und ändern Sie die Verweise auf die Servernamen passend für die Zielserverinstanz.

Weitere Informationen finden Sie unter Sichern und Wiederherstellen von replizierten Datenbanken, Datenbankspiegelung und Replikation (SQL Server) und Protokollversand und Replikation (SQL Server).

[Nach oben]

Service Broker-Anwendungen

Viele Aspekte einer Service Broker-Anwendung werden zusammen mit der Datenbank verschoben. Einige Aspekte der Anwendung müssen jedoch erneut erstellt oder am neuen Speicherort neu konfiguriert werden.

[Nach oben]

Autostartprozeduren

Eine Autostartprozedur ist eine gespeicherte Prozedur, die für die automatische Ausführung markiert ist und bei jedem Start von SQL Server ausgeführt wird. Wenn die Datenbank von irgendwelchen Autostartprozeduren abhängt, müssen Sie diese auf der Zielserverinstanz definieren und so konfigurieren, dass sie beim Start automatisch ausgeführt werden.

[Nach oben]

Trigger (auf Serverebene)

DDL-Trigger lösen gespeicherte Prozeduren als Reaktion auf verschiedene DDL-Ereignisse (Data Definition Language, Datendefinitionssprache) aus. Diese Ereignisse entsprechen in erster Linie Transact-SQL-Anweisungen, die mit den Schlüsselwörtern CREATE, ALTER und DROP beginnen. Bestimmte gespeicherte Systemprozeduren, die DDL-ähnliche Vorgänge ausführen, können ebenfalls DDL-Trigger auslösen.

Informationen zu dieser Funktion finden Sie unter DDL-Trigger.

[Nach oben]