Verwalten von Metadaten beim Bereitstellen einer Datenbank auf einer anderen Serverinstanz

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 Features selektiv installiert und gestartet. Auf diese Weise wird die angreifbare Oberfläche eines Systems verringert. Bei neuen Installationen sind viele Features in der Standardkonfiguration nicht aktiviert. Wenn die Datenbank von einem standardmäßig deaktivierten Dienst oder Feature abhängig ist, muss dieser Dienst bzw. dieses Feature auf der Zielserverinstanz aktiviert werden.

Weitere Informationen zu diesen Einstellungen sowie Informationen zum Aktivieren oder Deaktivieren dieser Einstellungen finden Sie unter Grundlegendes zur Oberflächenkonfiguration und Festlegen von 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 diesem Feature 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).

In SQL Server 2000 Service Pack 3 (SP3) und späteren Versionen von SQL Server werden durch Trenn- und Anfügevorgänge die datenbankübergreifenden Besitzketten für die Datenbank deaktiviert. Informationen zur Aktivierung der Verkettung finden Sie unter cross db ownership chaining (Option).

Weitere Informationen finden Sie auch unter:

• Besitzketten

• Erweitern des Identitätswechsels bei Datenbanken durch Verwenden von EXECUTE AS

• Vorgehensweise: Einrichten der TRUSTWORTHY-Eigenschaft für eine Spiegeldatenbank

[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 Features finden Sie unter Verteilte Abfragen, Verbindungsserver und Zugreifen auf Metadaten von Verbindungsservern.

[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 ohne Hinweis 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. Tritt bei dieser Entschlüsselung ein Fehler auf, wird der Anmeldeinformationenspeicher von SQL Server nach Anmeldeinformationen des Hauptschlüssels durchsucht, die denselben Familien-GUID wie die Datenbank aufweisen, für die der Hauptschlüssel benötigt wird. Anschließend wird von SQL Server versucht, 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 ='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:

• Verschlüsselungshierarchie

• Einrichten einer verschlüsselten Spiegeldatenbank

• Vorgehensweise: Erstellen identischer symmetrischer Schlüssel auf zwei Servern

[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

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

• Vorgehensweise: Erstellen einer WMI-Ereigniswarnung (SQL Server Management Studio)

So funktionieren Ereignisbenachrichtigungen für eine gespiegelte Datenbank

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. Weitere Informationen finden Sie unter Verteilte Abfragen.

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 Erweiterte gespeicherte Prozeduren.

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

Weitere Informationen finden Sie auch unter:

• Sichern und Wiederherstellen eines SQL Server 2008-Volltextkatalogs

• Datenbankspiegelung und Volltextkataloge

• Schrittweise Wiederherstellung und Volltextindizes

[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 Vorgehensweise: Konfigurieren eines Benutzers für das Erstellen und Verwalten von Aufträgen des SQL Server-Agents (SQL Server Management Studio).

• 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 Einrichten von Windows-Dienstkonten.

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

• 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 von SQL Server-Agent-Proxys und Problembehandlung von proxybasierten Multiserveraufträgen.

Weitere Informationen finden Sie auch unter:

• Implementieren von Aufträgen

• Verwalten von Anmeldungen und Anmeldeaufträgen nach einem Rollenwechsel (für die Datenbankspiegelung)

• Einrichten von Windows-Dienstkonten (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

• Überwachen der Auftragsaktivität

• sp_help_job (Transact-SQL)

• Vorgehensweise: Anzeigen von Auftragsschrittinformationen (SQL Server Management Studio)

• sysjobs (Transact-SQL)

So erstellen Sie einen Auftrag

• Vorgehensweise: Erstellen eines Auftrags (SQL Server Management Studio)

• Vorgehensweise: Erstellen eines Auftrags für den SQL Server-Agent (Transact-SQL)

So erstellen Sie ein Skript für einen vorhandenen Auftrag

• Vorgehensweise: Erstellen von Skripts für Aufträge mithilfe von Transact-SQL (SQL Server Management Studio)

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. Weitere Informationen finden Sie unter Vorgehensweise: Erstellen eines Skripts (SQL Server Management Studio).

Informationen zum Anzeigen der SQL Server-Anmeldenamen und zum Erkennen und Auflösen von verwaisten Benutzern auf einer Serverinstanz finden Sie unter Problembehandlung bei verwaisten Benutzern.

Hinweis
Informationen zum Einrichten von Anmeldenamen für eine gespiegelte Datenbank finden Sie unter Einrichten von Anmeldekonten für die Datenbankspiegelung und Verwalten von Anmeldungen und Anmeldeaufträgen nach einem Rollenwechsel.

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

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. Weitere Informationen finden Sie unter Vorgehensweise: Erstellen eines Skripts (SQL Server Management Studio).

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

• CREATE CERTIFICATE (Transact-SQL)

• CREATE ASYMMETRIC KEY (Transact-SQL)

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. Weitere Informationen finden Sie unter Vorgehensweise: Erstellen eines Skripts für Replikationsobjekte (SQL Server Management Studio). 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, Replikation und Datenbankspiegelung und Replikation und Protokollversand.

[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. Weitere Informationen finden Sie unter Migration (Service Broker).

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

Weitere Informationen finden Sie unter Automatische Ausführung gespeicherter Prozeduren.

[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 diesem Feature finden Sie unter DDL-Trigger.

[Nach oben]

Siehe auch

Aufgaben

Konzepte