Verwalten von Metadaten beim Bereitstellen einer Datenbank auf einer anderen Serverinstanz (SQL Server)
Dieses Thema 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.
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 SQL Server-Agent Aufträgen abhängt, deren Metadaten in der msdb-Datenbank gespeichert sind, müssen Sie diese Aufträge auf dem Zielserver instance 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 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
SQL Server 2005 und höheren Versionen werden wichtige Dienste und Features 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 und zum Aktivieren oder Deaktivieren 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
SQL Server-Agent Proxykonten verwenden Anmeldeinformationen. 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. 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 unter Einrichten einer Spiegeldatenbank für die Verwendung der vertrauenswürdigen Eigenschaft (Transact-SQL).
Datenbankbesitz
Wenn eine Datenbank auf einem anderen Computer wiederhergestellt wird, wird der SQL Server Anmeldung oder der Windows-Benutzer, der den Wiederherstellungsvorgang initiiert hat, automatisch 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. Eine Verbindungsserverkonfiguration ermöglicht es SQL Server, 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 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, die Datenbank master Schlüssel mit dem Dienstschlüssel master Schlüssel des instance zu entschlüsseln. Wenn diese Entschlüsselung fehlschlägt, durchsucht SQL Server den Anmeldeinformationsspeicher nach master Schlüsselanmeldeinformationen, die dieselbe Familien-GUID wie die Datenbank aufweisen, für die sie den master Schlüssel benötigt. SQL Server versucht dann, die Datenbank master Schlüssel mit den entsprechenden Anmeldeinformationen zu entschlüsseln, bis die Entschlüsselung erfolgreich ist oder keine weiteren Anmeldeinformationen 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.
Wenn eine verschlüsselte Datenbank kopiert, wiederhergestellt oder an eine neue instance von SQL Server angefügt wird, wird eine Kopie der Datenbank master Schlüssels, der vom Dienst master Schlüssel verschlüsselt wurde, nicht in master auf dem instance des Zielservers gespeichert. Auf der Zielserverinstanz müssen Sie den Hauptschlüssel der Datenbank öffnen. Um den master Schlüssel zu öffnen, führen Sie 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:
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.
Ereignisbenachrichtigungen und WMI-Ereignisse (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation) auf Serverebene
Ereignisbenachrichtigungen auf Serverebene
Ereignisbenachrichtigungen auf Serverebene werden in msdbgespeichert. 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.
Darüber hinaus 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 msdbgespeichert. 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)
Mit dem WMI-Anbieter für Serverereignisse können Sie die Windows-Verwaltungsinstrumentation (WMI) verwenden, um Ereignisse in SQL Server zu ü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 msdbdefiniert 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 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.
Indem Sie gespiegelte Routen einrichten, machen Sie das Service Broker-Routing auf die Datenbankspiegelung aufmerksam. Mithilfe der gespiegelten Routen kann Service Broker Unterhaltungen transparent an den aktuellen Prinzipalserver instance umleiten. 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
Dieses Feature wird in einer künftigen Version von Microsoft SQL Server entfernt. 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 SQL Server-API für erweiterte gespeicherte Prozeduren programmiert. Ein Mitglied der festen Serverrolle sysadmin kann eine erweiterte gespeicherte Prozedur mit einer instance SQL Server registrieren und Benutzern die Berechtigung 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 eines instance SQL Server ausgeführt, und sie können zu Speicherverlusten oder anderen Problemen führen, die die Leistung und Zuverlässigkeit des Servers beeinträchtigen. Sie sollten erwägen, erweiterte gespeicherte Prozeduren in einer instance von SQL Server zu speichern, die von der instance getrennt ist, die die referenzierten Daten enthält. 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-Datenbank, die Volltextkatalogdateien enthält, an einen SQL Server 2014-Server instance anfügen, werden die Katalogdateien von ihrem vorherigen Speicherort aus zusammen mit den anderen Datenbankdateien angefügt, die identisch mit SQL Server 2005 sind. Weitere Informationen finden Sie unter Upgrade der Volltextsuche.
Weitere Informationen finden Sie auch unter:
Aufträge
Wenn die Datenbank von SQL Server-Agent Aufträgen abhängig ist, müssen Sie diese auf dem Zielserver instance 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
Um SQL Server-Agent Aufträge zu erstellen oder auszuführen, müssen Sie zunächst alle SQL Server Anmeldungen, die für den Auftrag erforderlich sind, dem Zielserver instance hinzufügen. Weitere Informationen finden Sie unter Konfigurieren eines Benutzers zum Erstellen und Verwalten von SQL Server-Agent-Aufträgen.
SQL Server-Agent 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, der einem bestimmten instance von SQL Server zugeordnet ist, verfügt über eine eigene Registrierungsstruktur, und seine Aufträge verfügen in der Regel über Abhängigkeiten von mindestens einer der Einstellungen in dieser Registrierungsstruktur. Das gewünschte Verhalten eines Auftrags ist nur dann sichergestellt, wenn diese Registrierungseinstellungen vorliegen. Wenn Sie ein Skript verwenden, um einen Auftrag in einem anderen SQL Server-Agent Dienst neu zu erstellen, verfügt die Registrierung möglicherweise nicht über die richtigen Einstellungen für diesen Auftrag. Damit sich neu erstellte Aufträge auf einem Zielserver instance ordnungsgemäß verhalten, sollten die ursprünglichen und SQL Server-Agent Zieldienste dieselben Registrierungseinstellungen aufweisen.
Achtung
Das Ändern der Registrierungseinstellungen für das Ziel SQL Server-Agent Diensts, um einen neu erstellten Auftrag zu verarbeiten, kann problematisch sein, wenn die aktuellen Einstellungen 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
Ein SQL Server-Agent Proxy definiert den Sicherheitskontext für einen angegebenen Auftragsschritt. 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:
Verwaltung von Anmeldungen und Aufträgen nach dem Rollenwechsel (SQL Server) (für Datenbankspiegelung)
Konfigurieren von Windows-Dienstkonten und -Berechtigungen (wenn Sie eine instance von SQL Server installieren)
Konfigurieren von SQL Server-Agent (wenn Sie eine instance von SQL Server installieren)
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 auf dem anderen SQL Server-Agent-Dienst neu zu erstellen und den Auftrag auszuführen, um festzustellen, ob er wie beabsichtigt funktioniert. 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
Die Anmeldung bei einer instance SQL Server erfordert eine gültige SQL Server Anmeldung. Diese Anmeldung wird im Authentifizierungsprozess verwendet, der überprüft, ob der Prinzipal eine Verbindung mit der instance von SQL Server herstellen kann. Ein Datenbankbenutzer, für den die entsprechende SQL Server Anmeldung nicht definiert oder auf einem Server falsch definiert ist instance kann sich nicht bei der instance anmelden. Diese Benutzer werden als verwaiste Benutzer der Datenbank dieser Serverinstanz bezeichnet. Ein Datenbankbenutzer kann verwaist werden, wenn eine Datenbank wiederhergestellt, angefügt oder in eine andere instance SQL Server kopiert wurde.
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 Anmeldungen für eine gespiegelte Datenbank finden Sie unter Einrichten von Anmeldekonten für die Datenbankspiegelung oder AlwaysOn-Verfügbarkeitsgruppen (SQL Server) und Verwaltung von Anmeldungen und Aufträgen nach dem 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. Wenn Sie über Anmeldungen verfügen, die SQL Server-Authentifizierung verwenden, müssen Sie das Skript für das 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 Systemobjektberechtigungen finden Sie unter GRANT-Systemobjektberechtigungen (Transact-SQL). Weitere Informationen finden Sie unter REVOKE System Object Permissions (Transact-SQL) und DENY System Object Permissions (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
So weisen Sie dem zugeordneten Anmeldenamen Berechtigungen zu
Weitere Informationen zu Zertifikaten und asymmetrischen Schlüsseln finden Sie unter Encryption Hierarchy.
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 replizierter 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.
Autostartprozeduren
Eine Startprozedur ist eine gespeicherte Prozedur, die für die automatische Ausführung gekennzeichnet ist und bei jedem Start 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)