Teilen über

Verwalten von Metadaten beim Bereitstellen einer Datenbank auf einem anderen Server

  • Artikel

Gilt für: SQL Server

Dieser Artikel ist in den folgenden Situationen relevant:

  • Konfigurieren der Verfügbarkeitsreplikate einer Always-On-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.

  • Durchführen eines Datenbankmodulupgrades mithilfe der Methode – Migrieren zu einer neuen Installation.

  • Migrieren von Datenbanken zu Azure SQL (virtuelle Maschine oder verwaltete Instanz).

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 müssen auf dem Zielserver neu erstellt werden. Wenn ein Anwendungs- oder Datenbankwartungsplan 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 der master-Datenbank gespeichert.

Wenn Sie die Datenbank für eine Anwendung in eine andere Serverinstanz verschieben, müssen Sie alle Metadaten der abhängigen Entitäten und Objekte in den Datenbanken master und msdb 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 nur dann wie erwartet, wenn Sie die Metadaten für diese Trigger in der master-Datenbank manuell neu erstellen.

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

Im restlichen Teil dieses Artikels 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

Für SQL Server 2005 (9.x) und höhere 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 (SQL Server).

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.

Weitere Informationen zu diesem Feature finden Sie unter Anmeldeinformationen (Datenbank-Engine).

Hinweis

Für SQL Server Agent Proxy Konten werden Anmeldeinformationen verwendet. Die ID der von einem Proxykonto verwendeten Anmeldeinformationen kann anhand der sysproxies -Systemtabelle festgestellt werden.

Datenbankübergreifende Abfragen

Die Datenbankoptionen DB_CHAINING und TRUSTWORTHY sind standardmäßig auf OFF festgelegt. Ist eine dieser Optionen für die ursprüngliche Datenbank auf ON festgelegt, 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 unter Einrichten der TRUSTWORTHY-Eigenschaft für eine Spiegeldatenbank (Transact-SQL).

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 Features finden Sie unter Verbindungsserver (Datenbank-Engine).

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 master 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. SQL Server versucht dann, 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 master 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 ='Kennwort'. 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:

Benutzerdefinierte Fehlermeldungen

Benutzerdefinierte Fehlermeldungen sind in der sys.messages -Katalogsicht enthalten. Diese Katalogsicht wird in master 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.

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 Event Notifications.

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, wenn Sie eine Datenbank in einer anderen Instanz anfügen, müssen Sie diese Route erneut erstellen.

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

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. Service Broker bietet eine besondere Unterstützung für gespiegelte Datenbanken in Form von gespiegelten Routen. 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.

Erweiterte gespeicherte Prozeduren

Wichtig

Diese Funktion wird in einer zukünftigen Version von SQL Serverentfernt. Nutzen Sie diese Funktionen bei Neuentwicklungen nicht mehr, und planen Sie die Änderung von Anwendungen, die diese Funktion zurzeit verwenden. 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).

Eigenschaften der Volltext-Engine für SQL Server

Die Eigenschaften für die Volltext-Engine werden mit sp_fulltext_servicefestgelegt. 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 (9.x)-Datenbank mit Volltextkatalogdateien an eine SQL Server-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 (9.x). Weitere Informationen finden Sie unter Upgrade der Volltextsuche.

Weitere Informationen finden Sie auch unter:

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.

  • SQL Server-Agent Server-Dienststartkonto

    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. Informationen finden Sie unter Konfigurieren von Windows-Dienstkonten und -Berechtigungen.

  • 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 Registrierungseinstellungen aufweisen.

    Achtung

    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 Proxies

    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:

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.

Anmeldungen

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 die entsprechende 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. Ein Datenbankbenutzer kann zu einem verwaisten Benutzer werden, wenn die Datenbank auf einer anderen -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 Truefestlegen.

Hinweis

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

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.

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 Berechtigungen auf Objektebene auf True festlegen.

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 (Systemobjektberechtigungen) (Transact-SQL) und DENY (Systemobjektberechtigungen) (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 Katalogsicht sys.server_permissions. Informationen zu Serverprinzipalen erhalten Sie durch Abfragen der Katalogsicht sys.server_principals und Informationen zur Mitgliedschaft von Serverrollen durch Abfragen der Katalogsicht sys.server_role_members.

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 master gespeichert. Zertifikate oder asymmetrische Schlüssel, die sich in einer anderen Datenbank als master befinden, müssen in master 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

So weisen Sie dem zugeordneten Anmeldenamen Berechtigungen zu

Weitere Informationen zu Zertifikaten und asymmetrischen Schlüsseln finden Sie unter Encryption Hierarchy.

Trustworthy-Eigenschaft

Die TRUSTWORTHY-Datenbankeigenschaft gibt an, ob diese Instanz von SQL Server die Datenbank und ihre Inhalte als vertrauenswürdig einstuft. Wenn eine Datenbank angefügt wird, ist diese Option standardmäßig und aus Sicherheitsgründen auf OFF festgelegt, selbst wenn sie im ursprünglichen Server auf ON festgelegt ist. Weitere Informationen zu dieser Eigenschaft finden Sie unter TRUSTWORTHY-Datenbankeigenschaft, und Informationen zum Ändern dieser Option auf ON finden Sie unter ALTER DATABASE (Transact-SQL).

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).

Service Broker-Anwendungen

Viele Aspekte einer Service Broker-Anwendung werden mit der Datenbank verschoben. Einige Aspekte der Anwendung müssen jedoch erneut erstellt oder am neuen Speicherort neu konfiguriert werden. Standardmäßig und aus Sicherheitsgründen sind die Optionen für is_broker_enabled und is_honoor_broker_priority_on auf OFF festgelegt, wenn eine Datenbank aus einem anderen Server angefügt wird. Informationen darüber, wie diese Optionen auf ON festgelegt werden, finden Sie unter ALTER DATABASE (Transact-SQL).

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.

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 Triggers.

Weitere Informationen

Eigenständige Datenbanken
Kopieren von Datenbanken auf andere Server
Anfügen und Trennen von Datenbanken (SQL Server)
Failover zu einer sekundären Datenbank für den Protokollversand (SQL Server)
Rollenwechsel während einer Datenbank-Spiegelungssitzung (SQL Server)
Einrichten einer verschlüsselten Spiegeldatenbank
SQL Server-Konfigurations-Manager
Problembehandlung bei verwaisten Benutzern (SQL Server)
Migrieren zu einer neuen Installationsmigrationsübersicht: SQL Server zu SQL Server auf Azure-VMs