Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Häufige DBA-Aufgaben für Amazon RDS für Microsoft SQL Server Dieser Abschnitt beschreibt die Amazon-RDS-spezifischen Implementierungen einiger häufiger DBA-Aufgaben für DB-Instances, auf denen die Microsoft-SQL-Server-Datenbank-Engine ausgeführt wird. Um eine verwaltete Service-Erfahrung zu bieten, stellt Amazon RDS keinen Shell-Zugriff auf DB-Instances bereit, und beschränkt den Zugriff auf bestimmte Systemprozeduren und -tabellen, die erweiterte Sonderrechte erfordern. **Anmerkung** Wenn Sie mit einer SQL Server DB-Instance arbeiten, können Sie Skripts für die Änderung einer neu erstellten Datenbank ausführen. Sie können jedoch nicht die [Modell]-Datenbank ändern, die von der Datenbank als Modell für neue Datenbanken verwendet wurde. **Topics** + [ # Zugriff auf die Datenbank tempdb in Microsoft-SQL-Server-DB-Instances in Amazon RDS ](SQLServer.TempDB.md) + [ # Analysieren Ihrer Datenbank-Workload auf einer Amazon RDS for SQL Server DB-Instance mit Database Engine Tuning Advisor ](Appendix.SQLServer.CommonDBATasks.Workload.md) + [ # Ändern des `db_owner`- in das `rdsa`-Konto für Ihre Server-Datenbank in Amazon RDS für SQL ](Appendix.SQLServer.CommonDBATasks.ChangeDBowner.md) + [ # Verwalten von Sortierungen und Zeichensätzen für Amazon RDS für Microsoft SQL Server ](Appendix.SQLServer.CommonDBATasks.Collation.md) + [ # Erstellen eines Datenbankbenutzers für Amazon RDS für SQL Server ](Appendix.SQLServer.CommonDBATasks.CreateUser.md) + [ # Bestimmen eines Wiederherstellungsmodells für Ihre Datenbank in Amazon RDS für SQL Server ](Appendix.SQLServer.CommonDBATasks.DatabaseRecovery.md) + [ # Ermitteln der letzten Failover-Zeit für Amazon RDS für SQL Server ](Appendix.SQLServer.CommonDBATasks.LastFailover.md) + [ # Behebung von zeitpunktbezogenen Wiederherstellungsfehlern aufgrund einer Lücke bei der Protokollsequenznummer ](Appendix.SQLServer.CommonDBATasks.PITR-LSN-Gaps.md) + [ # Verweigern oder Zulassen des Anzeigens von Datenbanknamen für Amazon RDS für SQL Server ](Appendix.SQLServer.CommonDBATasks.ManageView.md) + [ # Deaktivieren schneller Einfügungen während des Massenladens für Amazon RDS für SQL Server ](Appendix.SQLServer.CommonDBATasks.DisableFastInserts.md) + [ # Verwerfen einer Datenbank in einer DB-Instance in Amazon RDS für Microsoft SQL Server ](Appendix.SQLServer.CommonDBATasks.DropMirrorDB.md) + [ # Umbenennen einer Datenbank in Amazon RDS für Microsoft SQL Server in einer Multi-AZ-Bereitstellung ](Appendix.SQLServer.CommonDBATasks.RenamingDB.md) + [ # Zurücksetzen der db\$1owner-Rollenmitgliedschaft für den Master-Benutzer für Amazon RDS für SQL Server ](Appendix.SQLServer.CommonDBATasks.ResetPassword.md) + [ # Wiederherstellen von DB-Instances für Amazon RDS für SQL Server, die aus Lizenzgründen beendet wurden ](Appendix.SQLServer.CommonDBATasks.RestoreLTI.md) + [ # Übergang einer Server-Datenbank in Amazon RDS für SQL von OFFLINE zu ONLINE ](Appendix.SQLServer.CommonDBATasks.TransitionOnline.md) + [ # Verwenden von Change Data Capture für Amazon RDS für SQL Server ](Appendix.SQLServer.CommonDBATasks.CDC.md) + [ # Verwenden von SQL Server Agent für Amazon RDS ](Appendix.SQLServer.CommonDBATasks.Agent.md) + [ # Arbeiten mit Microsoft-SQL-Server-Protokollen ](Appendix.SQLServer.CommonDBATasks.Logs.md) + [ # Arbeiten mit Trace- und Dump-Dateien für Amazon RDS für SQL Server ](Appendix.SQLServer.CommonDBATasks.TraceFiles.md) # Zugriff auf die Datenbank tempdb in Microsoft-SQL-Server-DB-Instances in Amazon RDS Sie können auf die `tempdb`-Datenbank auf Ihren Microsoft-SQL-Server-DB-Instances auf Amazon RDS zugreifen. Sie können Code auf `tempdb` mit Transact-SQL über Microsoft SQL Server Management Studio (SSMS) oder über eine andere Standard-SQL-Clientanwendung ausführen. Weitere Informationen zum Herstellen einer Verbindung zur DB-Instance finden Sie unter [Herstellen einer Verbindung mit Ihrer DB-Instance von Microsoft SQL Server](USER_ConnectToMicrosoftSQLServerInstance.md). Der Hauptbenutzer der DB-Instance erhält `CONTROL`-Zugriff auf `tempdb`, so dass dieser Benutzer die `tempdb`-Datenbankoptionen ändern kann. Der Hauptbenutzer ist nicht der Besitzer der `tempdb`-Datenbank. Falls notwendig, kann der Hauptbenutzer anderen Benutzern den `CONTROL`-Zugriff gewähren, damit diese ebenfalls die `tempdb`-Datenbankoptionen ändern können. **Anmerkung** Für die `tempdb`-Datenbank können keine Datenbankkonsolenbefehle (Database Console Commands, DBCC) ausgeführt werden. # Ändern der Datenbankoptionen für tempdb Sie können die Datenbankoptionen für die `tempdb`-Datenbank auf den Amazon-RDS-DB-Instances ändern. Weitere Informationen darüber, welche Optionen geändert werden können, finden Sie unter [tempdb Database](https://msdn.microsoft.com/en-us/library/ms190768%28v=sql.120%29.aspx) in der Microsoft-Dokumentation. Datenbankoptionen wie z. B. die Optionen für die maximale Dateigröße bleiben nach einem Neustart der DB-Instance bestehen. Sie können die Datenbankoptionen ändern, um die Leistung beim Datenimport zu optimieren und um Speicherplatzmangel vorzubeugen. ## Optimieren der Leistung beim Import von Daten Setzen Sie die Eigenschaften `SIZE` und `FILEGROWTH` der Datenbank "tempdb" auf hohe Zahlenwerte, um beim Importieren von großen Datenmengen in die DB-Instance die Leistung zu optimieren. Weitere Informationen zur Optimierung von `tempdb` finden Sie unter [Optimieren der Leistung von tempdb](https://technet.microsoft.com/en-us/library/ms175527%28v=sql.120%29.aspx) in der Microsoft-Dokumentation. Im folgenden Beispiel wird die Größe auf 100 GB und das Datenwachstum auf 10 Prozent eingestellt. ``` 1. alter database[tempdb] modify file (NAME = N'templog', SIZE=100GB, FILEGROWTH = 10%) ``` ## Vorbeugen von Speicherproblemen Legen Sie einen Wert für die Eigenschaft `tempdb` fest, damit die `MAXSIZE`-Datenbank nicht den gesamten verfügbaren Speicherplatz belegt. Im folgenden Beispiel wird diese Eigenschaft auf 2048 MB festgelegt. ``` 1. alter database [tempdb] modify file (NAME = N'templog', MAXSIZE = 2048MB) ``` # Verkleinern der Datenbank tempdb Es gibt zwei Möglichkeiten, um die `tempdb`-Datenbank auf der Amazon-RDS-DB-Instance zu verkleinern. Sie können die Prozedur `rds_shrink_tempdbfile` verwenden oder einen Wert für die Eigenschaft `SIZE` definieren. ## Verwenden der Prozedur rds\$1shrink\$1tempdbfile Mithilfe der Amazon-RDS-Prozedur `msdb.dbo.rds_shrink_tempdbfile` verkleinern Sie die `tempdb`-Datenbank. Sie können `rds_shrink_tempdbfile` nur aufrufen, wenn Sie `CONTROL`-Zugriff auf `tempdb` haben. Durch den Aufruf von `rds_shrink_tempdbfile` wird keine Betriebsunterbrechung der DB-Instance verursacht. Die Prozedur `rds_shrink_tempdbfile` hat die folgenden Parameter. **** | Parametername | Datentyp | Standard | Erforderlich | Beschreibung | | --- | --- | --- | --- | --- | | `@temp_filename` | SYSNAME | — | Erforderlich | Der logische Name der Datei, die verkleinert werden soll. | | `@target_size` | int | Null | optional | Die neue Größe für diese Datei in Megabytes. | Im folgenden Beispiel werden die Namen der Dateien für die `tempdb`-Datenbank abgerufen. ``` 1. use tempdb; 2. GO 3. 4. select name, * from sys.sysfiles; 5. GO ``` Im folgenden Beispiel wird eine `tempdb`-Datenbankdatei mit dem Namen `test_file` verkleinert und die neue Größe auf `10` MB festgelegt: ``` 1. exec msdb.dbo.rds_shrink_tempdbfile @temp_filename = N'test_file', @target_size = 10; ``` ## Festlegen der Eigenschaft SIZE Sie können die `tempdb`-Datenbank auch verkleinern, indem Sie die Eigenschaft `SIZE` festlegen und anschließend die DB-Instance neu starten. Weitere Informationen zum Neustart der DB-Instance finden Sie unter [Eine DB-Instance DB-Cluster neu starten](USER_RebootInstance.md). Im folgenden Beispiel wird die Eigenschaft `SIZE` auf 1024 MB festgelegt. ``` 1. alter database [tempdb] modify file (NAME = N'templog', SIZE = 1024MB) ``` # TempDB-Konfiguration für Multi-AZ-Bereitstellungen Sie sollten einige Punkte zur Verwendung der `tempdb`-Datenbank berücksichtigen, wenn sich Ihre DB-Instance von RDS für SQL Server in einer Multi-AZ-Bereitstellung mit Datenbankspiegelung oder Always-On-Verfügbarkeitsgruppen befindet. Sie können keine `tempdb`-Daten von Ihrer primären DB-Instance auf Ihre sekundäre DB-Instance replizieren. Wenn Sie ein Failover zu einer sekundären DB-Instance durchführen, ist `tempdb` auf dieser sekundären DB-Instance leer. Sie können die Konfiguration der `tempdb`-Datenbankoptionen, einschließlich der Einstellungen für Dateigröße und automatische Erweiterung, von Ihrer primären DB-Instance mit Ihrer sekundären DB-Instance synchronisieren. Die Synchronisation der `tempDB`-Konfiguration wird auf allen Versionen von RDS für SQL Server unterstützt. Sie können die automatische Synchronisation der `tempdb`-Konfiguration mithilfe der folgenden gespeicherten Prozedur aktivieren: ``` EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'TempDbFile'; ``` **Wichtig** Bevor Sie die gespeicherte Prozedur `rds_set_system_database_sync_objects` verwenden, stellen Sie sicher, dass Sie Ihre bevorzugte `tempdb`-Konfiguration auf Ihrer primären DB-Instance und nicht auf Ihrer sekundären DB-Instance festgelegt haben. Wenn Sie die Konfigurationsänderung auf Ihrer sekundären DB-Instance vorgenommen haben, könnte Ihre bevorzugte `tempdb`-Konfiguration gelöscht werden, wenn Sie die automatische Synchronisation aktivieren. Sie können die folgende Funktion verwenden, um zu überprüfen, ob die automatische Synchronisation der `tempdb`-Konfiguration aktiviert ist: ``` SELECT * from msdb.dbo.rds_fn_get_system_database_sync_objects(); ``` Wenn die automatische Synchronisation der `tempdb`-Konfiguration aktiviert ist, wird ein Wert für das Feld `object_class` zurückgegeben. Wenn sie deaktiviert ist, wird kein Wert zurückgegeben. Sie können die folgende Funktion verwenden, um zu ermitteln, wann Objekte zuletzt synchronisiert wurden (in (UTC): ``` SELECT * from msdb.dbo.rds_fn_server_object_last_sync_time(); ``` Wenn Sie beispielsweise die `tempdb`-Konfiguration um 01:00 Uhr geändert und dann die Funktion `rds_fn_server_object_last_sync_time` ausgeführt haben, sollte der für `last_sync_time` zurückgegebene Wert nach 01:00 Uhr liegen, was darauf hinweist, dass eine automatische Synchronisation stattgefunden hat. Wenn Sie auch die Auftragsreplikation von SQL Server Agent verwenden, können Sie die Replikation sowohl für SQL-Agent-Aufträge als auch für die `tempdb`-Konfiguration aktivieren, indem Sie sie im Parameter `@object_type` angeben: ``` EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'SQLAgentJob,TempDbFile'; ``` Weitere Informationen zur Auftragsreplikation von SQL Server Agent finden Sie unter [Aktivieren der Auftragsreplikation von SQL Server Agent](Appendix.SQLServer.CommonDBATasks.Agent.md#SQLServerAgent.Replicate). Als Alternative zur Verwendung der gespeicherten Prozedur `rds_set_system_database_sync_objects`, um sicherzustellen, dass `tempdb`-Konfigurationsänderungen automatisch synchronisiert werden, können Sie eine der folgenden manuellen Methoden verwenden: **Anmerkung** Wir empfehlen, die automatische Synchronisation der `tempdb`-Konfiguration mithilfe der gespeicherten Prozedur `rds_set_system_database_sync_objects` zu aktivieren. Durch die automatische Synchronisation müssen Sie diese manuellen Aufgaben nicht jedes Mal ausführen, wenn Sie Ihre `tempdb`-Konfiguration ändern. + Ändern Sie zuerst die DB-Instance und deaktivieren Sie Multi-AZ. Dann modifizieren Sie "tempdb" und aktivieren abschließend wieder Multi-AZ. Durch diese Methode entsteht keine Ausfallzeit. Weitere Informationen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md). + Ändern Sie zuerst `tempdb` auf der ursprünglichen primären Instance, führen Sie dann manuell ein Failover durch, und ändern Sie dann `tempdb` auf der neuen primären Instance. Bei dieser Methode kommt es zu einem Ausfall. Weitere Informationen finden Sie unter [Eine DB-Instance DB-Cluster neu starten](USER_RebootInstance.md). # Analysieren Ihrer Datenbank-Workload auf einer Amazon RDS for SQL Server DB-Instance mit Database Engine Tuning Advisor Database Engine Tuning Advisor ist eine von Microsoft bereitgestellte Client-Anwendung, die den Workload der Datenbank analysiert und einen optimalen Satz von Indizes für Ihre Microsoft SQL Server-Datenbanken basierend auf den Arten von Abfragen empfiehlt, die Sie ausführen. Wie auch SQL Server Management Studio kann der Optimierungshelfer von einem Client-Computer ausgeführt werden, der eine Verbindung zu Ihrer Amazon RDS-DB-Instance aufbaut, auf der SQL Server ausgeführt wird. Beim Clientcomputer kann es sich um einen lokalen hauseigenen Computer innerhalb Ihres Netzwerks oder um eine Amazon EC2-Windows-Instance handeln, die in der gleichen Region wie Ihre Amazon RDS-DB-Instance ausgeführt wird. In diesem Abschnitt wird gezeigt, wie ein Workload für eine Analyse im Optimierungshelfer erfasst wird. Das ist die bevorzugte Vorgehensweise für die Erfassung einer Workload, da der Host-Zugriff auf die SQL Server-Instance durch Amazon RDS beschränkt wird. Weitere Informationen finden Sie unter [Database Engine Tuning Advisor](https://docs.microsoft.com/en-us/sql/relational-databases/performance/database-engine-tuning-advisor) in der Microsoft-Dokumentation. Um den Optimierungshelfer zu verwenden, müssen Sie dem Helfer eine sogenannte Workload zur Verfügung stellen. Eine Workload besteht aus einer Reihe von Transact-SQL-Statements, die in einer oder in mehreren Datenbanken ausgeführt werden, die Sie optimieren möchten. Der Datenbank-Engine-Optimierungshelfer verwendet bei der Optimierung von Datenbanken Trace-Dateien, Trace-Tabellen, Transact-SQL-Skripts oder XML-Dateien als Workload-Input. Bei der Arbeit mit Amazon RDS kann eine Workload eine Datei auf einem Clientcomputer oder eine Datenbanktabelle in einer Amazon RDS for SQL Server-DB sein, die für Ihren Clientcomputer zugänglich ist. Die Datei oder Tabelle muss Abfragen für die zu optimierenden Datenbanken enthalten, die in einem Format vorliegen, das für eine erneute Wiedergabe geeignet ist. Damit der Optimierungshelfer optimal arbeiten kann, muss eine Workload so realistisch sein wie möglich. Sie können eine Workload-Datei oder -Tabelle erzeugen, indem Sie ein Trace für Ihre DB-Instance durchführen. Sie können während der Ausführung eines Trace entweder eine Belastung Ihrer DB-Instance simulieren oder Ihre Anwendungen mit normaler Belastung ausführen. Es gibt zwei Arten von Traces: clientseitig und serverseitig. Die Einrichtung eines clientseitigen Trace ist unkomplizierter und es können im SQL Server Profiler Trace-Ereignisse in Echtzeit erfasst werden. Die Einrichtung eines serverseitigen Trace ist komplizierter und erfordert etwas Transact-SQL-Scripting. Darüber hinaus wird durch den Trace Speicherplatz verbraucht, da der Trace in der Amazon RDS-DB-Instance in eine Datei geschrieben wird. Es ist wichtig, zu beachten, wie viel Speicherplatz die Ausführung eines serverseitigen Trace benötigt, da die DB-Instance in den Storage-Full-Status wechseln könnte und dann nicht mehr verfügbar ist, sobald der Speicherplatz ausgeht. Sobald in SQL Server Profiler bei einer Client-seitigen Nachverfolgung eine ausreichende Menge an Daten erfasst wurde, können Sie die Workload-Datei erzeugen, indem Sie die Nachverfolgung entweder als Datei auf dem lokalen Computer oder in einer Datenbank-Tabelle auf einer DB-Instance speichern, die für den Client-Computer verfügbar ist. Der Hauptnachteil bei der Verwendung eines clientseitigen Trace ist der, dass unter großer Auslastung eventuell nicht alle Abfragen vom Trace erfasst werden. Das könnte die Effektivität der vom Datenbank-Engine-Optimierungshelfer durchgeführten Analyse negativ beeinträchtigen. Muss ein Trace unter großer Auslastung ausgeführt werden und Sie möchten sicherstellen, dass während einer Trace-Sitzung alle Abfragen erfasst werden, sollte ein serverseitiger Trace zum Einsatz kommen. Für einen serverseitigen Trace müssen die Trace-Dateien in der DB-Instance in einer geeigneten Workload-Datei gespeichert oder der Trace in einer Tabelle in der DB-Instance gespeichert werden, nachdem der Trace abgeschlossen ist. Sie können den SQL Server Profiler verwenden, um den Trace in einer Datei auf Ihrem lokalen Computer zu speichern oder lassen den Optimierungshelfer aus der Trace-Tabelle in der DB-Instance lesen. # Ausführung eines clientseitigen Trace in einer SQL Server-DB-Instance **Ausführen einer clientseitigen Nachverfolgung in einer SQL Server-DB-Instance** 1. Starten Sie SQL Server Profiler. Sie finden das Tool im Ordner Leistungstools Ihres SQL Server-Instance-Ordners. Um einen clientseitigen Trace zu starten, muss eine Trace-Definitionsvorlage geladen oder definiert werden. 1. Wählen Sie im Menü SQL Server Profiler File die Option **New Trace (Neue Nachverfolgung)**. Im Dialogfeld **Connect to Server (Mit Server verbinden)** geben Sie DB-Instance-Endpunkt, Masterbenutzernamen und das Passwort für die Datenbank ein, für die eine Nachverfolgung ausgeführt werden soll. 1. Im Dialogfeld **Trace Properties (Eigenschaften der Nachverfolgung)** geben Sie einen Namen für die Nachverfolgung ein und wählen eine Definitionsvorlage für die Nachverfolgung aus. Die Standardvorlage TSQL\$1Replay wird mit der Anwendung geliefert. Diese Vorlage kann für das Definieren Ihres Trace bearbeitet werden. Ereignisse und Ereignisinformationen können unter der Registerkarte **Events Selection (Auswahl von Ereignissen)** im Dialogfeld **Trace Properties (Eigenschaften der Nachverfolgung)** bearbeitet werden. Weitere Informationen zu Trace-Definitionsvorlagen und zur Verwendung von SQL Server Profiler zur Angabe eines clientseitigen Trace finden Sie in der Microsoft-Dokumentation in [Database Engine Tuning Advisor](https://docs.microsoft.com/en-us/sql/relational-databases/performance/database-engine-tuning-advisor). 1. Starten Sie den clientseitigen Trace und beobachten Sie die SQL-Abfragen in Echtzeit, die für Ihre DB-Instance ausgeführt werden. 1. Wählen Sie im Menü **File (Datei)** die Option **Stop Trace (Nachverfolgung beenden)** aus, sobald die Nachverfolgung abgeschlossen ist. Speichern Sie die Ergebnisse als Datei oder als Trace-Tabelle in Ihrer DB-Instance. # Ausführung eines serverseitigen Trace in einer SQL Server-DB-Instance Das Schreiben eines Skripts für das Erstellen eines serverseitigen Trace kann eine komplexe Angelegenheit sein und geht über dieses Dokument hinaus. Dieser Abschnitt enthält Beispiel-Skripts, die Sie als Beispiele verwenden können. Wie auch bei einem clientseitigen Trace liegt das Ziel darin, eine Workload-Datei oder eine Trace-Tabelle zu erstellen, die mit dem Datenbank-Engine-Optimierungshelfer geöffnet werden kann. Hier ist ein gekürztes Beispiel-Script, das einen serverseitigen Trace startet und die Details in einer Workload-Datei erfasst. Der Trace wird zunächst in der Datei RDSTrace .trc im Verzeichnis D:\$1RDSDBDATA\$1Log gespeichert und alle 100 MB wird ein Rollover ausgeführt, sodass nachfolgende Trace-Dateien die Namen RDSTrace \$11.trc, \$12.trc usw. erhalten. RDSTrace ``` DECLARE @file_name NVARCHAR(245) = 'D:\RDSDBDATA\Log\RDSTrace'; DECLARE @max_file_size BIGINT = 100; DECLARE @on BIT = 1 DECLARE @rc INT DECLARE @traceid INT EXEC @rc = sp_trace_create @traceid OUTPUT, 2, @file_name, @max_file_size IF (@rc = 0) BEGIN EXEC sp_trace_setevent @traceid, 10, 1, @on EXEC sp_trace_setevent @traceid, 10, 2, @on EXEC sp_trace_setevent @traceid, 10, 3, @on . . . EXEC sp_trace_setfilter @traceid, 10, 0, 7, N'SQL Profiler' EXEC sp_trace_setstatus @traceid, 1 END ``` Das folgende Beispiel ist ein Script, mit dem ein Trace angehalten wird. Beachten Sie, dass ein vom vorherigen Script erstellter Trace solange ausgeführt wird, bis Sie den Trace explizit anhalten oder die Festplattenkapazität für den Vorgang nicht mehr ausreicht. ``` DECLARE @traceid INT SELECT @traceid = traceid FROM ::fn_trace_getinfo(default) WHERE property = 5 AND value = 1 AND traceid <> 1 IF @traceid IS NOT NULL BEGIN EXEC sp_trace_setstatus @traceid, 0 EXEC sp_trace_setstatus @traceid, 2 END ``` Die Ergebnisse des serverseitigen Trace können in einer Datenbank-Tabelle gespeichert, und die Datenbank-Tabelle mithilfe der Funktion fn\$1trace\$1gettable als Workload für den Optimierungshelfer verwendet werden. Mit den folgenden Befehlen werden die Ergebnisse aller Dateien mit dem Namen RDSTrace .trc im Verzeichnis D:\$1rdsdbdata\$1Log, einschließlich aller Rollover-Dateien wie \$11.trc, in eine Tabelle mit dem Namen in der aktuellen Datenbank geladen. RDSTrace RDSTrace ``` SELECT * INTO RDSTrace FROM fn_trace_gettable('D:\rdsdbdata\Log\RDSTrace.trc', default); ``` Um eine bestimmte Rollover-Datei in einer Tabelle zu speichern, z. B. die Datei RDSTrace \$11.trc, geben Sie den Namen der Rollover-Datei an und ersetzen Sie den Wert 1 anstelle von default als letzten Parameter für fn\$1trace\$1gettable. ``` SELECT * INTO RDSTrace_1 FROM fn_trace_gettable('D:\rdsdbdata\Log\RDSTrace_1.trc', 1); ``` # Ausführung des Optimierungshelfers mit einem Trace Sobald Sie einen Trace erstellen, entweder als lokale Datei oder als Datenbank-Tabelle, können Sie den Optimierungshelfer für Ihre DB-Instance ausführen. Die Verwendung des Optimierungshelfers für Amazon RDS entspricht dem Vorgang der Arbeit mit einer eigenständigen Remote-SQL Server-Instance. Sie können entweder die Benutzerfläche des Optimierungshelfers auf Ihrem Client-Computer oder das Hilfsprogramm dta.exe von der Befehlszeile aus verwenden. In beiden Fällen müssen bei der Verwendung des Optimierungshelfers mithilfe des Endpunkts der DB-Instance eine Verbindung zur Amazon RDS-DB-Instance hergestellt und Ihr Master User Name und Master User Password eingegeben werden. Das folgende Code-Beispiel demonstriert die Verwendung des Befehlszeilen-Hilfsprogramms dta.exe für eine Amazon RDS-DB-Instance mit dem Endpunkt **dta.cnazcmklsdei.us-east-1.rds.amazonaws.com**. Das Beispiel enthält den Master-Benutzernamen **admin** und das Master-Benutzerkennwort **test**, die zu tunende Beispieldatenbank heißt „machine“ **C:\$1RDSTrace.trc**. Der Befehlszeilenbeispielcode legt außerdem eine Nachverfolgungssitzung mit dem Namen **RDSTrace1** fest und legt die Output-Dateien auf dem lokalen Computer mit dem Namen **RDSTrace.sql** für das SQL-Output-Script, **RDSTrace.txt** für eine Ergebnisdatei und **RDSTrace.xml** für eine XML-Datei der Analyse fest. In der Datenbank RDSDTA wird außerdem eine Fehlertabelle mit dem Namen festgeleg **RDSTraceErrors**. ``` dta -S dta.cnazcmklsdei.us-east-1.rds.amazonaws.com -U admin -P test -D RDSDTA -if C:\RDSTrace.trc -s RDSTrace1 -of C:\ RDSTrace.sql -or C:\ RDSTrace.txt -ox C:\ RDSTrace.xml -e RDSDTA.dbo.RDSTraceErrors ``` Hier sehen Sie den gleichen Befehlszeilenbeispielcode mit der Ausnahme, dass es sich bei der Input-Workload um eine Tabelle in der Amazon RDS-Instance mit dem Namen **RDSTrace** handelt, die sich in der Datenbank **RDSDTA** befindet. ``` dta -S dta.cnazcmklsdei.us-east-1.rds.amazonaws.com -U admin -P test -D RDSDTA -it RDSDTA.dbo.RDSTrace -s RDSTrace1 -of C:\ RDSTrace.sql -or C:\ RDSTrace.txt -ox C:\ RDSTrace.xml -e RDSDTA.dbo.RDSTraceErrors ``` Eine vollständige Liste der Befehlszeilenparameter des dta-Dienstprogramms finden Sie unter [dta Utility](https://docs.microsoft.com/en-us/sql/tools/dta/dta-utility) in der Microsoft-Dokumentation. # Ändern des `db_owner`- in das `rdsa`-Konto für Ihre Server-Datenbank in Amazon RDS für SQL Wenn Sie eine Datenbank in einer RDS-für-SQL-Server-DB-Instance erstellen oder wiederherstellen, legt Amazon RDS den Besitzer der Datenbank auf `rdsa` fest. Wenn Sie eine Multi-AZ-Bereitstellung mit SQL Server Database Mirroring (DBM) oder Always On Availability Groups (AGs) haben, setzt Amazon RDS den Besitzer der Datenbank auf der sekundären DB-Instance auf. `NT AUTHORITY\SYSTEM` Der Besitzer der sekundären Datenbank kann erst geändert werden, wenn die sekundäre DB-Instance zur primären Rolle heraufgestuft wurde. In den meisten Fällen ist es bei der Ausführung von Abfragen unproblematisch, wenn der Besitzer der Datenbank auf `NT AUTHORITY\SYSTEM` festgelegt ist. Es kann dabei jedoch zu Fehlern kommen, wenn gespeicherte Systemprozeduren wie `sys.sp_updatestats` ausgeführt werden, für deren Ausführung erhöhte Berechtigungen erforderlich sind. Sie können die folgende Abfrage verwenden, um den Besitzer der Datenbanken von `NT AUTHORITY\SYSTEM` zu identifizieren: ``` SELECT name FROM sys.databases WHERE SUSER_SNAME(owner_sid) = 'NT AUTHORITY\SYSTEM'; ``` Sie können die gespeicherte Amazon-RDS-Prozedur `rds_changedbowner_to_rdsa` verwenden, um den Besitzer der Datenbank in `rdsa` zu ändern. Die folgenden Datenbanken dürfen nicht mit `rds_changedbowner_to_rdsa` verwendet werden: `master, model, msdb, rdsadmin, rdsadmin_ReportServer, rdsadmin_ReportServerTempDB, SSISDB`. Rufen Sie die gespeicherte `rds_changedbowner_to_rdsa`-Prozedur auf und geben Sie den Namen der Datenbank an, um den Besitzer der Datenbank in `rdsa` zu ändern. **Example Verwendung:** ``` exec msdb.dbo.rds_changedbowner_to_rdsa 'TestDB1'; ``` Der folgende Parameter ist erforderlich: + `@db_name` – Der Name der Datenbank, deren Besitzer in `rdsa` geändert werden soll. **Wichtig** Sie können `rds_changedbowner_to_rdsa` nicht verwenden, um den Besitz einer Datenbank in einen anderen Anmeldenamen zu ändern als `rdsa`. Beispielsweise können Sie den Besitzer des Anmeldenamens, mit dem Sie die Datenbank erstellt haben, nicht ändern. Um die verloren gegangene Mitgliedschaft in der `db_owner`-Rolle für Ihren Master-Benutzer wiederherzustellen, wenn kein anderer Datenbankbenutzer verwendet werden kann, um die Mitgliedschaft zu gewähren, setzen Sie das Master-Benutzerpasswort zurück, um die Mitgliedschaft in der `db_owner`-Rolle zu erhalten. Weitere Informationen finden Sie unter [Zurücksetzen der db\$1owner-Rollenmitgliedschaft für den Master-Benutzer für Amazon RDS für SQL Server](Appendix.SQLServer.CommonDBATasks.ResetPassword.md). # Verwalten von Sortierungen und Zeichensätzen für Amazon RDS für Microsoft SQL Server Dieses Thema enthält Anleitungen zur Verwaltung von Sortierungen und Zeichensätzen für Microsoft SQL Server in Amazon RDS. Es wird erklärt, wie Sortierungen während der Datenbankerstellung konfiguriert und später geändert werden, um sicherzustellen, dass Textdaten entsprechend den Sprach- und Gebietsschemaanforderungen ordnungsgemäß behandelt werden. Darüber hinaus werden bewährte Methoden zur Aufrechterhaltung der Kompatibilität und Leistung in SQL-Server-Umgebungen in Amazon RDS behandelt. SQL Server unterstützt das Sortieren auf verschiedenen Ebenen. Sie legen die Standardsortierung für den Server fest, wenn Sie die DB-Instance erstellen. Sie können die Sortierung auf der Ebene von Datenbanken, Tabellen und Spalten überschreiben. **Topics** + [ ## Sortierung auf Serverebene bei Microsoft SQL Server ](#Appendix.SQLServer.CommonDBATasks.Collation.Server) + [ ## Sortierung auf Datenbankebene bei Microsoft SQL Server ](#Appendix.SQLServer.CommonDBATasks.Collation.Database-Table-Column) ## Sortierung auf Serverebene bei Microsoft SQL Server Wenn Sie eine Microsoft SQL Server-DB-Instance erstellen können Sie die zu verwendende Sortierung des Servers festlegen. Wenn Sie keine andere Sortierung wählen, ist die Sortierung auf Serverebene standardmäßig SQL\$1Latin1\$1General\$1 \$1CI\$1AS. CP1 Die für den Server festgelegte Sortierung wird standardmäßig für alle Datenbanken und Datenbankobjekte verwendet. **Anmerkung** Sie können die Sortierung nicht ändern, wenn Sie aus einem DB-Snapshot wiederherstellen. Derzeit unterstützt Amazon RDS die folgenden Sortierungen für Server: | Kollation | Description | | --- | --- | | Arabic\$1CI\$1AS | Arabisch, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Chinesisch\$1PRC\$1 BIN2 | Chinesisch-VR China, Sortierreihenfolge für binäre Codepunkte | | Chinese\$1PRC\$1CI\$1AS | Chinesisch-PRC, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Chinese\$1Taiwan\$1Stroke\$1CI\$1AS | Chinesisch-Taiwan-Stroke, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Danish\$1Norwegian\$1CI\$1AS | Dänisch-Norwegisch, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Danish\$1Norwegian\$1CI\$1AS\$1KS | Dänisch-Norwegisch, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, Beachtung des Kana-Typs, keine Beachtung der Breite | | Danish\$1Norwegian\$1CI\$1AS\$1KS\$1WS | Dänisch-Norwegisch, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, Beachtung des Kana-Typs, Beachtung der Breite | | Danish\$1Norwegian\$1CI\$1AS\$1WS | Dänisch-Norwegisch, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, Beachtung der Breite | | Danish\$1Norwegian\$1CS\$1AI | Dänisch-Norwegisch, Beachtung der Groß-/Kleinschreibung, keine Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Danish\$1Norwegian\$1CS\$1AI\$1KS | Dänisch-Norwegisch, Beachtung der Groß-/Kleinschreibung, keine Beachtung von Akzenten, Beachtung des Kana-Typs, keine Beachtung der Breite | | Finnish\$1Swedish\$1100\$1BIN | Finnisch-Schwedisch-100, binäre Sortierung | | Finnisch\$1Schwedisch\$1100\$1 BIN2 | Finnisch-Schwedisch-100, binäre Codepunkt-Vergleichssortierung | | Finnish\$1Swedish\$1100\$1CI\$1AI | Finnisch-Schwedisch-100, keine Beachtung der Groß-/Kleinschreibung, keine Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Finnish\$1Swedish\$1100\$1CI\$1AS | Finnisch-Schwedisch-100, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Finnish\$1Swedish\$1CI\$1AS | Finnisch, Schwedisch und Schwedisch (Finnland), Groß-/Kleinschreibung irrelevant, Diakritika relevant, Kana-Typ irrelevant, Breite irrelevant | | French\$1CI\$1AS | Französisch, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Greek\$1CI\$1AS | Griechisch, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Greek\$1CS\$1AS | Griechisch, Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Hebrew\$1BIN | Hebräisch, binäre Sortierung | | Hebrew\$1CI\$1AS | Hebräisch, Groß-/Kleinschreibung irrelevant, Diakritika relevant, Kana-Typ irrelevant, Breite irrelevant | | Japanese\$1BIN | Japanisch, binäre Sortierung | | Japanese\$1CI\$1AS | Japanisch, Groß-/Kleinschreibung irrelevant, Diakritika relevant, Kana-Typ irrelevant, Breite irrelevant | | Japanese\$1CS\$1AS | Japanisch, Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Japanese\$1XJIS\$1140\$1CI\$1AS | Japanisch, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite, zusätzliche Zeichen, keine Beachtung der Variierungsauswahlzeichen | | Japanese\$1XJIS\$1140\$1CI\$1AS\$1KS\$1VSS | Japanisch, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, Beachtung des Kana-Typs, keine Beachtung der Breite, zusätzliche Zeichen, Beachtung der Variierungsauswahlzeichen | | Japanese\$1XJIS\$1140\$1CI\$1AS\$1VSS | Japanisch, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite, zusätzliche Zeichen, Beachtung der Variierungsauswahlzeichen | | Japanese\$1XJIS\$1140\$1CS\$1AS\$1KS\$1WS | Japanisch, Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, Beachtung des Kana-Typs, Beachtung der Breite, zusätzliche Zeichen, keine Beachtung der Variierungsauswahlzeichen | | Korean\$1Wansung\$1CI\$1AS | Koreanisch-Wansung, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Latin1\$1General\$1100\$1BIN | Latein1-Allgemein-100, binäre Sortierung | | Lateinisch1\$1Allgemein\$1100\$1 BIN2 | Latin1-General-100, binäre Codepunkt-Sortierreihenfolge | | Lateinisch1\$1Allgemein\$1100\$1 \$1 BIN2 UTF8 | Latin1-General-100, binäre Codepunkt-Sortierreihenfolge, UTF-8-kodiert | | Latin1\$1General\$1100\$1CI\$1AS | Latein1-Allgemein-100, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Lateinisch1\$1Allgemein\$1100\$1CI\$1AS\$1SC\$1 UTF8 | Latin1-General-100, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, zusätzliche Zeichen, UTF-8-kodiert | | Latin1\$1General\$1BIN | Latein1-Allgemein, binäre Sortierung | | Latin1\$1Allgemein\$1 BIN2 | Latin1-General, binäre Codepunkt-Sortierreihenfolge | | Latin1\$1General\$1CI\$1AI | Latein1-Allgemein, keine Beachtung der Groß-/Kleinschreibung, keine Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Latin1\$1General\$1CI\$1AS | Latein1-Allgemein, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Latin1\$1General\$1CI\$1AS\$1KS | Latein1-Allgemein, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, Beachtung des Kana-Typs, keine Beachtung der Breite | | Latin1\$1General\$1CS\$1AS | Latein1-Allgemein, Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Modern\$1Spanish\$1CI\$1AS | Spanisch-Modern, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Polish\$1CI\$1AS | Polnisch, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | SQL\$11xCompat\$1 \$1CI\$1AS CP850 | Latein1-Allgemein, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite für Unicode-Daten, SQL-Server-Sortierreihenfolge 49 auf Codepage 850 für Daten, die nicht in Unicode codiert sind | | SQL\$1Latin1\$1Allgemein\$1 \$1CI\$1AI CP1 | Latein1-Allgemein, keine Beachtung der Groß-/Kleinschreibung, keine Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite für Unicode-Daten, SQL-Server-Sortierreihenfolge 54 auf Codepage 1252 für Daten, die nicht in Unicode codiert sind | | **SQL\$1Latin1\$1General\$1 CP1 \$1CI\$1AS (Standard)** | Latein1-Allgemein, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite für Unicode-Daten, SQL-Server-Sortierreihenfolge 52 auf Codepage 1252 für Daten, die nicht in Unicode codiert sind | | SQL\$1Latin1\$1General\$1 CP1 \$1CS\$1AS | Latein1-Allgemein, Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite für Unicode-Daten, SQL-Server-Sortierreihenfolge 51 auf Codepage 1252 für Daten, die nicht in Unicode codiert sind | | CP437SQL\$1Latin1\$1General\$1 \$1CI\$1AI | Latein1-Allgemein, keine Beachtung der Groß-/Kleinschreibung, keine Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite für Unicode-Daten, SQL-Server-Sortierreihenfolge 34 auf Codepage 437 für Daten, die nicht in Unicode codiert sind | | CP850SQL\$1Latin1\$1General\$1 \$1BIN | Latin1-General, binäre Sortierreihenfolge für Unicode-Daten, SQL-Server-Sortierreihenfolge 40 auf Codepage 850 für Daten, die nicht in Unicode codiert sind | | CP850SQL\$1Latin1\$1Allgemein\$1 \$1 BIN2 | Lateinisch 1 (allgemein), binäre Codepoint-Sortierreihenfolge für Unicode-Daten, SQL Server-Sortierreihenfolge 40 auf Codepage 850 für Daten, die nicht in Unicode kodiert sind | | CP850SQL\$1Latin1\$1Allgemein\$1 \$1CI\$1AI | Latein1-Allgemein, keine Beachtung der Groß-/Kleinschreibung, keine Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite für Unicode-Daten, SQL-Server-Sortierreihenfolge 44 auf Codepage 850 für Daten, die nicht in Unicode codiert sind | | CP850SQL\$1Latin1\$1General\$1 \$1CI\$1AS | Latein1-Allgemein, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite für Unicode-Daten, SQL-Server-Sortierreihenfolge 42 auf Codepage 850 für Daten, die nicht in Unicode codiert sind | | SQL\$1Latin1\$1General\$1Pref\$1 CP850 \$1CI\$1AS | Latein1-Allgemein-Präf, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite für Unicode-Daten, SQL-Server-Sortierreihenfolge 183 auf Codepage 850 für Daten, die nicht in Unicode codiert sind | | CP1256SQL\$1Latin1\$1General\$1 \$1CI\$1AS | Latein1-Allgemein, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite für Unicode-Daten, SQL-Server-Sortierreihenfolge 146 auf Codepage 1256 für Daten, die nicht in Unicode codiert sind | | CP1255SQL\$1Latin1\$1General\$1 \$1CS\$1AS | Latein1-Allgemein, Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite für Unicode-Daten, SQL-Server-Sortierreihenfolge 137 auf Codepage 1255 für Daten, die nicht in Unicode codiert sind | | Thai\$1CI\$1AS | Thai, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | | Turkish\$1CI\$1AS | Türkisch, keine Beachtung der Groß-/Kleinschreibung, Beachtung von Akzenten, keine Beachtung des Kana-Typs, keine Beachtung der Breite | Sie können die Liste der unterstützten Sortierungen auch programmgesteuert abrufen, indem Sie die AWS CLI verwenden: ``` aws rds describe-db-engine-versions --engine sqlserver-ee --list-supported-character-sets --query 'DBEngineVersions[].SupportedCharacterSets[].CharacterSetName' | sort -u ``` Auswahl der Sortierung: + Wenn Sie die Amazon-RDS-Konsole verwenden, wählen Sie beim Erstellen einer neuen DB-Instance **Additional configuration** (Zusätzliche Konfiguration) aus und geben Sie die Sortierung im Feld **Collation** (Sortierung) ein. Weitere Informationen finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md). + Wenn Sie die verwenden, verwenden Sie die Option zusammen mit dem Befehl. AWS CLI`--character-set-name` `create-db-instance` Weitere Informationen finden Sie unter [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html). + Wenn Sie die Amazon-RDS-API verwenden, verwenden Sie den Parameter `CharacterSetName` mit der `CreateDBInstance`-Operation. Weitere Informationen finden Sie unter [Erstellen DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html). ## Sortierung auf Datenbankebene bei Microsoft SQL Server Die Standardsortierung kann auf Datenbank-, Tabellen- oder Spaltenebene durch außer Kraft setzen der Sortierung beim Erstellen einer neuer Datenbank oder eines Datenbankobjekts geändert werden. Wenn Ihre Standard-Serversortierung beispielsweise SQL\$1Latin1\$1General\$1 \$1CI\$1AS ist, können Sie sie zur Unterstützung der Mohawk-Sortierung in CP1 Mohawk\$1100\$1CI\$1AS ändern. Selbst Argumente in einer Abfrage können einer Typumwandlung unterzogen werden, um bei Bedarf eine andere Sortierung zu verwenden. Die folgende Abfrage würde beispielsweise die Standardsortierung für die Spalte in Mohawk\$1100\$1CI\$1AS ändern AccountName ``` CREATE TABLE [dbo].[Account] ( [AccountID] [nvarchar](10) NOT NULL, [AccountName] [nvarchar](100) COLLATE Mohawk_100_CI_AS NOT NULL ) ON [PRIMARY]; ``` Die Microsoft SQL Server-DB-Engine unterstützt durch die integrierten Datentypen NCHAR, NVARCHAR und NTEXT auch Unicode. Wenn Sie z. B. CJK-Unterstützung benötigen, verwenden Sie diese Unicode-Datentypen für die Zeichenspeicherung und setzen bei der Erstellung Ihrer Datenbanken und Tabellen die Server-Standardsortierung außer Kraft. Hier sind verschiedene Links von Microsoft, die das Thema Sortierung und Unicode-Support für SQL Server behandeln: + [Arbeiten mit Sortierungen](http://msdn.microsoft.com/en-us/library/ms187582%28v=sql.105%29.aspx) + [Sortierung und internationale Terminologie](http://msdn.microsoft.com/en-us/library/ms143726%28v=sql.105%29) + [Verwenden von SQL Server-Sortierungen](http://msdn.microsoft.com/en-us/library/ms144260%28v=sql.105%29.aspx) + [Internationale Erwägungen für Datenbanken und Datenbank-Engine-Anwendungen](http://msdn.microsoft.com/en-us/library/ms190245%28v=sql.105%29.aspx) # Erstellen eines Datenbankbenutzers für Amazon RDS für SQL Server Sie können einen Datenbankbenutzer für Ihre DB-Instance von Amazon RDS für Microsoft SQL Server erstellen, indem Sie ein T-SQL-Skript wie im folgenden Beispiel ausführen. Verwenden Sie eine Anwendung wie SQL Server Management Suite (SSMS). Sie melden sich bei der DB-Instance als Hauptbenutzer an, der beim Erstellen der DB-Instance erstellt wurde. ``` --Initially set context to master database USE [master]; GO --Create a server-level login named theirname with password theirpassword CREATE LOGIN [theirname] WITH PASSWORD = 'theirpassword'; GO --Set context to msdb database USE [msdb]; GO --Create a database user named theirname and link it to server-level login theirname CREATE USER [theirname] FOR LOGIN [theirname]; GO ``` Ein Beispiel für das Hinzufügen eines Datenbankbenutzers zu einer Rolle finden Sie unter [Hinzufügen eines Benutzers zur Rolle SQLAgentUser](SQLServerAgent.AddUser.md). **Anmerkung** Wenn Sie beim Hinzufügen eines Benutzers Berechtigungsfehler erhalten, können Sie die Berechtigungen wiederherstellen, indem Sie das Passwort für den DB-Instance-Hauptbenutzer ändern. Weitere Informationen finden Sie unter [Zurücksetzen der db\$1owner-Rollenmitgliedschaft für den Master-Benutzer für Amazon RDS für SQL Server](Appendix.SQLServer.CommonDBATasks.ResetPassword.md). Es ist keine bewährte Methode, Master-Benutzerberechtigungen in Ihren Anwendungen zu klonen. Weitere Informationen finden Sie unter [So klonen Sie Master-Benutzerberechtigungen in Amazon RDS für SQL Server](https://aws.amazon.com/blogs/database/how-to-clone-master-user-permissions-in-amazon-rds-for-sql-server/). # Bestimmen eines Wiederherstellungsmodells für Ihre Datenbank in Amazon RDS für SQL Server In Amazon RDS sind Wiederherstellungsmodell, Aufbewahrungszeitraum und Datenbankstatus miteinander verknüpft. Daher ist es wichtig, sich über die Konsequenzen klar zu werden, bevor eine Änderung an diesen Einstellungen vorgenommen wird. Jede Einstellung kann sich auf andere auswirken. Zum Beispiel: + Wenn Sie das Wiederherstellungsmodell einer Datenbank bei aktiviertem Aufbewahrungszeitraum auf SIMPLE oder BULK\$1LOGGED ändern, setzt Amazon RDS das Wiederherstellungsmodell innerhalb von fünf Minuten wieder auf FULL zurück. Es führt außerdem dazu, dass RDS einen Snapshot der DB-Instance erstellt. + Wenn Sie als Aufbewahrungszeitraum `0` Tage einstellen, stellt RDS als Wiederherstellungsmodus SIMPLE ein. + Wenn Sie das Wiederherstellungsmodell der Datenbank von SIMPLE auf eine beliebig andere Option ändern, während der Aufbewahrungszeitraum auf `0` eingestellt ist, setzt RDS das Wiederherstellungsmodell wieder auf SIMPLE zurück. **Wichtig** Das Wiederherstellungsmodell für Multi-AZ-Instances sollte niemals geändert werden, auch wenn dies möglich zu sein scheint, so z. B. mit ALTER DATABASE. Für Multi-AZ ist ein Aufbewahrungszeitraum für Backups und damit der vollständige (FULL) Wiederherstellungsmodus erforderlich. Wenn Sie das Wiederherstellungsmodell ändern, wird es von RDS sofort wieder in "FULL (Vollständig)" geändert. Dieses automatische Zurücksetzen zwingt RDS, die Spiegelung vollständig neu zu erstellen. Während der Neuerstellung ist die Verfügbarkeit der Datenbank ca. 30–90 Minuten lang beeinträchtigt, bis die Spiegelung für ein Failover bereit ist. Bei der DB-Instance kann es genauso wie während der Konvertierung von Einzel-AZ in Multi-AZ ebenso zu Leistungseinschränkungen kommen. Wie lange die Leistung beeinträchtigt ist, ist von der Speichergröße der Datenbank abhängig – je größer die gespeicherte Datenbank, desto länger dauert die Beeinträchtigung an. Weitere Informationen zu SQL Server-Wiederherstellungsmodellen finden Sie unter [Wiederherstellungsmodelle (SQL Server)](https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/recovery-models-sql-server) in der Microsoft-Dokumentation. # Ermitteln der letzten Failover-Zeit für Amazon RDS für SQL Server Um die letzte Failover-Zeit zu bestimmen, verwenden Sie das folgende gespeicherte Verfahren: ``` execute msdb.dbo.rds_failover_time; ``` Dieses Verfahren gibt die folgenden Informationen zurück. **** | Ausgabeparameter | Beschreibung | | --- | --- | | errorlog\$1available\$1from | Zeigt die Zeit an, ab der Fehlerprotokolle im Protokollverzeichnis verfügbar sind. | | recent\$1failover\$1time | Zeigt die letzte Failover-Zeit an, wenn sie in den Fehlerprotokollen verfügbar ist. Andernfalls wird angezeig `null`. | **Anmerkung** Das gespeicherte Verfahren durchsucht alle verfügbaren SQL Server-Fehlerprotokolle im Protokollverzeichnis, um die letzte Failover-Zeit abzurufen. Wenn die Failover-Nachrichten von SQL Server überschrieben wurden, wird die Failover-Zeit vom Verfahren nicht abgerufen. **Example Kein Failover in letzter Zeit** Dieses Beispiel zeigt die Ausgabe, wenn in den Fehlerprotokollen kein aktuelles Failover vorhanden ist. Seit 2020-04-29 23:59:00.01 ist kein Failover aufgetreten. | errorlog\$1available\$1from | recent\$1failover\$1time | | --- | --- | | 2020-04-29 23:59:00.0100000 | Null | **Example Failover in letzter Zeit** Dieses Beispiel zeigt die Ausgabe, wenn ein Failover in den Fehlerprotokollen vorliegt. Das letzte Failover erfolgte am 2020-05-05 18:57:51.89. | errorlog\$1available\$1from | recent\$1failover\$1time | | --- | --- | | 2020-04-29 23:59:00.0100000 | 2020-05-05 18:57:51.8900000 | # Behebung von zeitpunktbezogenen Wiederherstellungsfehlern aufgrund einer Lücke bei der Protokollsequenznummer Beim Versuch einer zeitpunktbezogenen Wiederherstellung (PITR) in RDS für SQL Server können Fehler auftreten, die auf Lücken in den Protokollsequenznummern (LSNs) zurückzuführen sind. Diese Lücken verhindern, dass RDS Ihre Datenbank zum angeforderten Zeitpunkt wiederherstellt, und RDS versetzt Ihre wiederherstellende Instance in den Status `incompatible-restore`. Dies sind häufige Ursachen für dieses Problem: + Manuelle Änderungen am Datenbank-Wiederherstellungsmodell. + Änderungen des automatischen Wiederherstellungsmodells durch RDS aufgrund unzureichender Ressourcen für die Durchführung von Transaktionsprotokollsicherungen. Führen Sie diese Abfrage aus, um LSN-Lücken in Ihrer Datenbank zu identifizieren: ``` SELECT * FROM msdb.dbo.rds_fn_list_tlog_backup_metadata(database_name) ORDER BY backup_file_time_utc desc; ``` Wenn Sie eine LSN-Lücke entdecken, können Sie: + Einen Wiederherstellungspunkt vor der LSN-Lücke auswählen. + Warten und auf einen Zeitpunkt nach Abschluss der nächsten Instance-Sicherung wiederherstellen. Um dieses Problem zu vermeiden, empfehlen wir, das Wiederherstellungsmodell Ihrer RDS-für -SQL-Server-Datenbanken nicht manuell zu ändern, da dies die Instance-Beständigkeit unterbricht. Wir empfehlen Ihnen außerdem, einen Instance-Typ mit ausreichenden Ressourcen für Ihre Arbeitslast zu wählen, um regelmäßige Backups der Transaktionsprotokolle sicherzustellen. Weitere Informationen über das Transaktionsprotokollmanagement finden Sie unter [SQL Server transaction log architecture and management guide](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide?view=sql-server-ver16) in der Dokumentation zu Microsoft SQL Server. # Verweigern oder Zulassen des Anzeigens von Datenbanknamen für Amazon RDS für SQL Server Der Hauptbenutzer kann nicht `DENY VIEW ANY DATABASE TO LOGIN` festlegen, um Datenbanken vor einem Benutzer zu verbergen. 
 Verwenden Sie stattdessen die folgende gespeicherte Prozedur, um diese Berechtigung zu ändern: + Den Zugriff auf *LOGIN* über die Datenbankansicht verweigern: ``` EXEC msdb.dbo.rds_manage_view_db_permission @permission=‘DENY’, @server_principal=‘LOGIN’
 go ``` + Den Zugriff auf *LOGIN* über die Datenbankansicht zulassen: ``` EXEC msdb.dbo.rds_manage_view_db_permission @permission='GRANT', @server_principal='LOGIN' 
go ``` Berücksichtigen Sie Folgendes, wenn Sie diese gespeicherte Prozedur verwenden: + Datenbanknamen sind im SSMS und in den internen DMV (Dynamic Management Views; dynamische Verwaltungsansichten) verborgen. Datenbanknamen sind jedoch weiterhin in Audit-, Protokoll- und Metadatentabellen sichtbar. Dies sind gesicherte `VIEW ANY DATABASE`-Serverberechtigungen. Weitere Informationen finden Sie unter [
 DENY Server Permissions](https://learn.microsoft.com/en-us/sql/t-sql/statements/deny-server-permissions-transact-sql?view=sql-server-ver16#permissions). + Sobald die Berechtigung wieder auf `GRANT` zurückgesetzt wurde (erlaubt), kann das *LOGIN* alle Datenbanken einsehen. + Wenn Sie *LOGIN* löschen und neu erstellen, wird die mit dem LOGIN verknüpfte Anzeigeberechtigung auf `ALLOW` zurückgesetzt. + Legen Sie für Multi-AZ-Instances die Berechtigung `DENY` oder `GRANT` nur für das *LOGIN* auf den primären Host fest. Die Änderungen werden automatisch auf den sekundären Host übertragen. + Diese Berechtigung ändert nur, ob ein Login die Datenbanknamen einsehen kann. Der Zugriff auf Datenbanken und die darin enthaltenen Objekte wird jedoch separat verwaltet. # Deaktivieren schneller Einfügungen während des Massenladens für Amazon RDS für SQL Server Ab SQL Server 2016 sind schnelle Einfügungen standardmäßig aktiviert. Schnelle Einfügungen nutzen die minimale Protokollierung, die auftritt, während sich die Datenbank im einfachen oder in massenprotokolliertem Wiederherstellungsmodell befindet, um die Einfügeleistung zu optimieren. Bei schnellen Einfügungen erhält jeder Massenladestapel neue Ausdehnungen, wobei die Zuweisungssuche nach vorhandenen Ausdehnungen mit freiem Speicherplatz umgangen wird, um die Einfügeleistung zu optimieren. Bei schnellen Einfügungen können Massenlasten mit kleinen Stapelgrößen jedoch zu einem erhöhten ungenutzten Speicherplatz führen, der von Objekten genutzt wird. Wenn eine Erhöhung der Stapelgröße nicht möglich ist, kann das Aktivieren des Ablaufverfolgungs-Flags 692 dazu beitragen, ungenutzten reservierten Speicherplatz zu reduzieren, jedoch auf Kosten der Leistung. Durch das Aktivieren dieses Ablaufverfolgungs-Flags werden schnelle Einfügungen beim Massenladen von Daten in Heap- oder Cluster-Indizes deaktiviert. Sie aktivieren den Ablaufverfolgungs-Flag 692 als Startup-Parameter mittels DB-Parametergruppen. Weitere Informationen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). Ablaufverfolgungs-Flag 692 wird für Amazon RDS SQL Server 2016 und höher unterstützt. Weitere Informationen zu Ablaufverfolgungs-Flags finden Sie unter [DBCC TRACEON - Trace-Flags](https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql) in der Microsoft-Dokumentation. # Verwerfen einer Datenbank in einer DB-Instance in Amazon RDS für Microsoft SQL Server Sie können eine Datenbank einer Amazon-RDS-DB-Instance verwerfen, auf der Microsoft SQL Server in einer Single-AZ- oder Multi-AZ-Bereitstellung ausgeführt wird. Verwenden Sie den folgenden Befehl, um die Datenbank zu verwerfen: ``` --replace your-database-name with the name of the database you want to drop EXECUTE msdb.dbo.rds_drop_database N'your-database-name' ``` **Anmerkung** Verwenden Sie im Befehl einfache gerade Anführungszeichen. Typographische Anführungszeichen verursachen einen Fehler. Nachdem Sie diese Vorgehensweise zum Löschen der Datenbank verwendet haben, löscht Amazon RDS alle vorhandenen Verbindungen zur Datenbank und entfernt den Sicherungsverlauf der Datenbank. Gehen Sie wie folgt vor, um anderen Benutzern die Möglichkeit zur Sicherung und Wiederherstellung zu gewähren: ``` USE master GO CREATE LOGIN user1 WITH PASSWORD=N'changeThis', DEFAULT_DATABASE=master, CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF GO USE msdb GO CREATE USER user1 FOR LOGIN user1 GO use msdb GO GRANT EXECUTE ON msdb.dbo.rds_backup_database TO user1 GO GRANT EXECUTE ON msdb.dbo.rds_restore_database TO user1 GO ``` # Umbenennen einer Datenbank in Amazon RDS für Microsoft SQL Server in einer Multi-AZ-Bereitstellung Gehen Sie wie folgt vor, um eine Multi-AZ nutzende Microsoft SQL Server-Datenbank-Instance umzubenennen: 1. Deaktivieren Sie zunächst Multi-AZ für die DB-Instance. 1. Ändern Sie den Datenbanknamen, indem Sie den Befehl ausführe `rdsadmin.dbo.rds_modify_db_name`. 1. Aktivieren Sie anschließend die Multi-AZ-Spiegelung oder AlwaysOn-Verfügbarkeitsgruppen für die DB-Instance, um den Ausgangszustand wiederherzustellen. Weitere Informationen finden Sie unter [Hinzufügen von Multi-AZ zu einer Microsoft SQL Server-DB-Instance](USER_SQLServerMultiAZ.md#USER_SQLServerMultiAZ.Adding). **Anmerkung** Falls Ihre Instance keine Multi-AZ verwendet, müssen vor oder nach dem Ausführen von keinerlei Einstellungen geändert werde `rdsadmin.dbo.rds_modify_db_name`. Sie können eine Datenbank auf einer Read-Replica-Quell-Instance nicht umbenennen. **Beispiel: **Im folgenden Beispiel wird mithilfe der gespeicherten Prozedur `rdsadmin.dbo.rds_modify_db_name` die Datenbank **MOO** umbenannt in **ZAR**. Dies entspricht der ausgeführten Anweisung `DDL ALTER DATABASE [MOO] MODIFY NAME = [ZAR]`. ``` EXEC rdsadmin.dbo.rds_modify_db_name N'MOO', N'ZAR' GO ``` # Zurücksetzen der db\$1owner-Rollenmitgliedschaft für den Master-Benutzer für Amazon RDS für SQL Server Wenn Sie Ihren Master-Benutzer von der `db_owner`-Rollenmitgliedschaft in Ihrer Datenbank für RDS für SQL Server ausschließen und kein anderer Datenbankbenutzer die Mitgliedschaft gewähren kann, können Sie die verloren gegangene Mitgliedschaft wiederherstellen, indem Sie das Master-Benutzerkennwort der DB-Instance ändern. Durch die Änderung des Master-Benutzerpassworts der DB-Instance gewährt RDS den Datenbanken in der DB-Instance die `db_owner`-Mitgliedschaft, die möglicherweise versehentlich gesperrt wurde. Sie können das DB-Instance-Passwort ändern, indem Sie die Amazon RDS-Konsole, den AWS CLI Befehl [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)oder den Vorgang „DBInstanceAPI [modifizieren](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)“ verwenden. Weitere Informationen zum Ändern einer DB-Instance finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md). # Wiederherstellen von DB-Instances für Amazon RDS für SQL Server, die aus Lizenzgründen beendet wurden Microsoft hat Amazon-RDS-Kunden, die ihre Microsoft-License-Mobility-Informationen nicht gemeldet haben, aufgefordert, ihre DB-Instance zu beenden. Amazon RDS erstellt Schnappschüsse dieser DB-Instances und diese lassen sich in eine neue DB-Instance mit dem Modell „Lizenz enthalten“ wiederherstellen. Sie können aus einem Snapshot der Standard Edition die Standard Edition oder Enterprise Edition wiederherstellen. Sie können aus einem Snapshot der Enterprise Edition die Standard Edition oder Enterprise Edition wiederherstellen. **Für eine Wiederherstellung aus einem SQL Server-Snapshot, nachdem Amazon RDS einen abschließenden Snapshot Ihrer Instance erstellt hat** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Wählen Sie im Navigationsbereich die Option **Snapshots**. 1. Wählen Sie den Snapshot Ihrer SQL-Server-DB-Instance aus. Amazon RDS erstellt einen endgültigen Snapshot Ihrer DB-Instance. Der Name des beendeten Instance-Snapshots weist das Format au `instance_name-final-snapshot`. Wenn Ihr DB-Instance-Name beispielsweise lautet**mytest.cdxgahslksma.us-east-1.rds.com**, wird der endgültige Snapshot aufgerufen ** mytest-final-snapshot** und befindet sich in derselben AWS Region wie die ursprüngliche DB-Instance. 1. Wählen Sie unter **Actions (Aktionen)** die Option **Restore Snapshot (Snapshot wiederherstellen)**. Das Fenster **Restore DB Instance (DB-Instance wiederherstellen)** wird angezeigt. 1. Für **License Model (Lizenzmodell)** wählen Sie **license-included (Lizenz enthalten)** aus. 1. Wählen Sie die SQL Server-DB-Engine, die Sie verwenden möchten. 1. Geben Sie für **DB Instance Identifier (DB-Instance-Kennung)** den Namen Ihrer wiederhergestellten DB-Instance ein. 1. Klicken Sie auf **Restore DB Instance** (DB-Instance wiederherstellen). Weitere Informationen zum Wiederherstellen aus einem Snapshot finden Sie unter [Wiederherstellen auf eine DB-Instance](USER_RestoreFromSnapshot.md). # Übergang einer Server-Datenbank in Amazon RDS für SQL von OFFLINE zu ONLINE Der Übergang Ihrer Microsoft SQL Server-Datenbank in einer Amazon-RDS-DB-Instance von `OFFLINE` zu `ONLINE` ist möglich. **** | SQL Server-Methode | Amazon-RDS-Methode | | --- | --- | | ONLINE *db\$1name* EINGESTELLTE DATENBANK ÄNDERN; | EXEC rdsadmin.dbo.rds\$1set\$1database\$1online *db\$1name* | # Verwenden von Change Data Capture für Amazon RDS für SQL Server Amazon RDS unterstützt auch die Erfassung von Datenänderungen (Change Data Capture, CDC) für Ihre DB-Instances, die auf Microsoft SQL Server laufen. CDC erfasst Änderungen an Daten in Ihren Tabellen. Es speichert Metadaten über jede Änderung, auf die Sie später zugreifen können. Weitere Informationen über die Arbeitsweise von CDC finden Sie unter [Change Data Capture](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/track-data-changes-sql-server#Capture) in der Microsoft-Dokumentation. Bevor Sie CDC für Ihre Amazon-RDS-DB-Instances verwenden, aktivieren Sie es in der Datenbank, indem Sie `msdb.dbo.rds_cdc_enable_db` ausführen. Nachdem CDC aktiviert wurde, kann jeder Benutzer, der `db_owner` dieser Datenbank ist, CDC für Tabellen in dieser Datenbank aktivieren oder deaktivieren. **Wichtig** Während einer Wiederherstellung wird CDC deaktiviert. Alle zugehörigen Metadaten werden automatisch aus der Datenbank entfernt. Dies gilt für Snapshot-Wiederherstellungen und point-in-time Wiederherstellungen. Nachdem Sie eine dieser Wiederherstellungsarten durchgeführt haben, können Sie CDC wieder aktivieren und nachzuverfolgende Tabellen neu festlegen. Um CDC für eine DB-Instance zu aktivieren, führen Sie die gespeicherte `msdb.dbo.rds_cdc_enable_db`-Prozedur aus. ``` 1. exec msdb.dbo.rds_cdc_enable_db 'database_name' ``` Um CDC für eine DB-Instance zu deaktivieren, führen Sie die gespeicherte `msdb.dbo.rds_cdc_disable_db`-Prozedur aus. ``` 1. exec msdb.dbo.rds_cdc_disable_db 'database_name' ``` Um einem Benutzer CDC-Berechtigungen zu erteilen, gehen Sie wie folgt vor: ``` 1. go 2. GRANT EXECUTE ON msdb.dbo.rds_cdc_enable_db TO User1 3. GRANT EXECUTE ON msdb.dbo.rds_cdc_disable_db TO User1 ``` **Topics** + [ ## Nachverfolgen von Tabellen mit Change Data Capture ](#Appendix.SQLServer.CommonDBATasks.CDC.tables) + [ ## Change Data Capture-Aufträge ](#Appendix.SQLServer.CommonDBATasks.CDC.jobs) + [ ## Change Data Capture für Multi-AZ-Instances ](#Appendix.SQLServer.CommonDBATasks.CDC.Multi-AZ) ## Nachverfolgen von Tabellen mit Change Data Capture Nachdem CDC für die Datenbank aktiviert wurde, können Sie mit der Nachverfolgung spezifischer Tabellen beginnen. Sie wählen die nachzuverfolgenden Tabellen durch Ausführen von [sys.sp\$1cdc\$1enable\$1table](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-enable-table-transact-sql). ``` 1. --Begin tracking a table 2. exec sys.sp_cdc_enable_table 3. @source_schema = N'source_schema' 4. , @source_name = N'source_name' 5. , @role_name = N'role_name' 6. 7. --The following parameters are optional: 8. 9. --, @capture_instance = 'capture_instance' 10. --, @supports_net_changes = supports_net_changes 11. --, @index_name = 'index_name' 12. --, @captured_column_list = 'captured_column_list' 13. --, @filegroup_name = 'filegroup_name' 14. --, @allow_partition_switch = 'allow_partition_switch' 15. ; ``` Um die CDC-Konfiguration für Ihre Tabellen anzuzeigen, führen Sie [sys.sp\$1cdc\$1help\$1change\$1data\$1capture](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-help-change-data-capture-transact-sql) aus. ``` 1. --View CDC configuration 2. exec sys.sp_cdc_help_change_data_capture 3. 4. --The following parameters are optional and must be used together. 5. -- 'schema_name', 'table_name' 6. ; ``` Weitere Informationen zu CDC-Tabellen, Funktionen und gespeicherten Prozeduren in der SQL Server-Dokumentation finden Sie im Folgenden: + [Change Data Capture – gespeicherte Prozeduren (Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/change-data-capture-stored-procedures-transact-sql) + [Change Data Capture – Funktionen (Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-functions/change-data-capture-functions-transact-sql) + [Change Data Capture – Tabellen (Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-tables/change-data-capture-tables-transact-sql) ## Change Data Capture-Aufträge Wenn Sie CDC aktivieren, erstellt SQL Server die CDC-Aufträge. Datenbankbesitzer (`db_owner`) können die CDC-Aufträge anzeigen, erstellen, ändern und löschen. Sie gehören jedoch dem RDS-Systemkonto. Aus diesem Grund sind die Aufträge in nativen Ansichten, Prozeduren oder in SQL Server Management Studio nicht sichtbar. Für die Kontrolle des Verhaltens von CDC in einer Datenbank verwenden Sie native SQL Server-Prozeduren wie [sp\$1cdc\$1enable\$1table](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-enable-table-transact-sql) und [sp\$1cdc\$1start\$1job](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-start-job-transact-sql). Für die Änderung der Parameter von CDC-Aufträgen wie `maxtrans` und `maxscans` verwenden Sie [sp\$1cdc\$1change\$1job](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-change-job-transact-sql). Um weitere Informationen zu den CDC-Aufträgen zu erhalten, können Sie die folgenden dynamischen Verwaltungsansichten abfragen: + sys.dm\$1cdc\$1errors + sys.dm\$1cdc\$1log\$1scan\$1sessions + sysjobs + sysjobhistory ## Change Data Capture für Multi-AZ-Instances Wenn Sie CDC für eine Multi-AZ-Instance verwenden, vergewissern Sie sich, dass die CDC-Auftragskonfiguration der Spiegelung mit derjenigen auf dem Prinzipal übereinstimmt. CDC-Aufträge werden auf die abgebilde `database_id`. Wenn sich die Datenbank IDs auf der Sekundärseite vom Prinzipal unterscheidet, werden die Jobs nicht der richtigen Datenbank zugeordnet. Um Fehler nach dem Failover zu vermeiden, verwirft RDS die Aufträge auf dem neuen Prinzipal und erstellt sie neu. Die neu erstellten Aufträge verwenden die Parameter, die der Prinzipal vor dem Failover aufgezeichnet hat. Obwohl dieser Prozess schnell abläuft, ist es immer noch möglich, dass die CDC-Aufträge ausgeführt werden, bevor RDS sie korrigieren kann. Hier gibt es drei Möglichkeiten zum Erzwingen der Konsistenz der Parameter von primären und sekundären Replicas: + Verwenden Sie die gleichen Auftragsparameter für alle Datenbanken, die CDC aktiviert haben. + Bevor Sie die CDC-Auftragskonfiguration ändern, konvertieren Sie die Multi-AZ-Instance zu Single-AZ. + Übertragen Sie die Parameter manuell, wenn Sie sie auf dem Prinzipal ändern. Um die CDC-Parameter anzuzeigen und zu definieren, mit denen die CDC-Aufträge nach einem Failover neu erstellt werden, verwenden Sie `rds_show_configuration` und `rds_set_configuration`. Im folgenden Beispiel wird der Wert für zurückgegebe `cdc_capture_maxtrans`. Für alle Parameter, die auf `RDS_DEFAULT` gesetzt sind, konfiguriert RDS den Wert automatisch. ``` -- Show configuration for each parameter on either primary and secondary replicas. exec rdsadmin.dbo.rds_show_configuration 'cdc_capture_maxtrans'; ``` Um die Konfiguration auf dem sekundären Server einzurichten, führen Sie au `rdsadmin.dbo.rds_set_configuration`. Dieses Verfahren legt die Parameterwerte für alle Datenbanken auf dem sekundären Server fest. Diese Einstellungen werden nur nach einem Failover verwendet. Im folgenden Beispiel wird `maxtrans` für alle CDC-Erfassungsaufträge der Wert wie folgt festgelegt: *1000* ``` --To set values on secondary. These are used after failover. exec rdsadmin.dbo.rds_set_configuration 'cdc_capture_maxtrans', 1000; ``` Um die CDC-Auftragsparameter auf dem Prinzipal festzulegen, verwenden Sie stattdessen [sys.sp\$1cdc\$1change\$1job](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-change-job-transact-sql). # Verwenden von SQL Server Agent für Amazon RDS Mit Amazon RDS können Sie SQL Server Agent in einer DB-Instance verwenden, in der Microsoft SQL Enterprise Edition, Standard Edition oder Web Edition ausgeführt wird. SQL Server Agent ist ein Service von Microsoft Windows für die Ausführung geplanter administrativer Aufgaben, so genannte Jobs. Sie können SQL Server Agent für die Ausführung von T-SQL-Jobs für den erneuten Aufbau von Indizes, die Ausführung von Beschädigungsprüfungen und für die Zusammenfassung von Daten in einer SQL Server-DB-Instance verwenden. Wenn Sie eine SQL-Server-DB-Instance erstellen, wird der Hauptbenutzer mit der Rolle `SQLAgentUserRole` registriert. SQL Server Agent kann einen Job nach Plan, als Antwort auf ein bestimmtes Ereignis oder auf Abruf ausführen. Weitere Informationen finden Sie unter [SQL Server Agent](http://msdn.microsoft.com/en-us/library/ms189237) in der Microsoft-Dokumentation. **Anmerkung** Vermeiden Sie es, Jobs zu planen, die während der Wartungs- und Backup-zeitfenster für Ihre DB-Instance ausgeführt werden. Die Wartungs- und Backup-Prozesse, die von AWS gestartet werden, könnten einen Job unterbrechen oder dazu führen, dass er abgebrochen wird. In Multi-AZ-Bereitstellungen werden Aufträge von SQL Server Agent vom primären Host auf den sekundären Host repliziert, wenn die Auftragsreplikationsfunktion aktiviert ist. Weitere Informationen finden Sie unter [Aktivieren der Auftragsreplikation von SQL Server Agent](#SQLServerAgent.Replicate). Multi-AZ-Bereitstellungen haben ein Limit von 10 000 SQL-Server-Agent-Aufträgen. Wenn Sie ein höheres Limit benötigen, können Sie Support kontaktieren, um eine Erhöhung anzufordern. Öffnen Sie die Seite des [AWS Support-Centers](https://console.aws.amazon.com/support/home#/), melden Sie sich an und wählen Sie **Fall erstellen** aus. Wählen Sie **Service Limit increase (Erhöhung des Servicelimits)**. Füllen Sie das Formular aus und senden Sie es ab. Um den Verlauf eines einzelnen SQL Server Agent-Auftrags in SQL Server Management Studio (SSMS) anzuzeigen, öffnen Sie den Objektexplorer, klicken mit der rechten Maustaste auf den Auftrag und wählen dann **View History (Verlauf anzeigen)**. Da der SQL Server-Agent auf einem verwalteten Host in einer DB-Instance ausgeführt wird, werden einige Aktionen nicht unterstützt: + Die Ausführung von Replikationsjobs und die Ausführung der Befehlszeilen-Skripts mithilfe von ActiveX, Windows Command-Shell oder Windows PowerShell werden nicht unterstützt. + Sie können SQL Server-Agent nicht manuell starten, stoppen oder neu starten. + E-Mail-Benachrichtigungen über SQL Server Agent sind von einer DB-Instance aus nicht verfügbar. + Warnungen und Operatoren von SQL Server-Agenten werden nicht unterstützt. + Die Verwendung von SQL Server-Agent zum Erstellen von Backups wird nicht unterstützt. Verwenden Sie Amazon RDS, um Ihre DB-Instance zu sichern. + Derzeit unterstützt RDS für SQL Server die Verwendung von SQL-Server-Agent-Tokens nicht. ## Aktivieren der Auftragsreplikation von SQL Server Agent Sie können die Auftragsreplikation von SQL Server Agent mithilfe der folgenden gespeicherten Prozedur aktivieren: ``` EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'SQLAgentJob'; ``` Sie können die gespeicherte Prozedur in allen SQL-Server-Versionen ausführen, die von Amazon RDS für SQL Server unterstützt werden. Es werden Aufträge in den folgenden Kategorien repliziert: + [Uncategorized (Local)] + [Uncategorized (Multi-Server)] + [Uncategorized] + Datenauflister + Database Engine Tuning Advisor + Datenbankwartung + Volltext Es werden nur Aufträge, die T-SQL-Auftragsschritte verwenden, repliziert. Aufträge mit Schritttypen wie SQL Server Integration Services (SSIS), SQL Server Reporting Services (SSRS), Replikation und PowerShell werden nicht repliziert. Aufträge, die Datenbank-E-Mail und Objekte auf Serverebene verwenden, werden nicht repliziert. **Wichtig** Der primäre Host ist die Informationsquelle für die Replikation. Stellen Sie vor dem Aktivieren der Auftragsreplikation sicher, dass sich Ihre SQL-Server-Agent-Aufträge auf dem primären Host befinden. Andernfalls werden Ihre SQL-Server-Agent-Aufträge ggf. gelöscht, wenn Sie die Funktion aktivieren und sich neuere Aufträge auf dem sekundären Host befinden. Sie können die folgende Funktion verwenden, um zu überprüfen, ob die Replikation aktiviert ist. ``` SELECT * from msdb.dbo.rds_fn_get_system_database_sync_objects(); ``` Die T-SQL-Abfrage gibt Folgendes zurück, wenn die Aufträge von SQL Server Agent repliziert werden. Wenn sie nicht repliziert werden, wird für `object_class` kein Wert zurückgegeben. ![\[Aufträge von SQL Server Agent werden repliziert.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/SQLAgentJob.png) Sie können die folgende Funktion verwenden, um zu ermitteln, wann Objekte zuletzt synchronisiert (UTC) wurden. ``` SELECT * from msdb.dbo.rds_fn_server_object_last_sync_time(); ``` Angenommen, Sie ändern einen Auftrag von SQL Server Agent um 01:00 Uhr. Sie erwarten, dass die letzte Synchronisationszeit nach 01:00 Uhr liegt, was darauf hinweist, dass die Synchronisation stattgefunden hat. Nach der Synchronisation wird erwartet, dass die für `date_created` und `date_modified` auf dem sekundären Knoten zurückgegebenen Werte übereinstimmen. ![\[Serverobjekte wurden zuletzt um 01:21:23 Uhr synchronisiert.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/SQLAgentJob_last_sync_time.png) Wenn Sie auch die Replikation von `tempdb` verwenden, können Sie die Replikation sowohl für SQL-Agent-Aufträge als auch für die `tempdb`-Konfiguration aktivieren, indem Sie sie im Parameter `@object_type` angeben: ``` EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'SQLAgentJob,TempDbFile'; ``` Weitere Informationen über die `tempdb`-Replikation finden Sie unter [TempDB-Konfiguration für Multi-AZ-Bereitstellungen](SQLServer.TempDB.MAZ.md). # Rollen von SQL Server Agent RDS für SQL Server unterstützt die folgenden Rollen von SQL Server Agent mit unterschiedlichen Berechtigungsebenen für die Verwaltung von Aufgaben: + **SQLAgentUserRole** Berechtigungen + Eigene Aufträge, Zeitpläne und Operatoren erstellen und verwalten + Eigenschaften ihrer eigenen Aufträge und Zeitpläne anzeigen + Aufträge, die von anderen Benutzern erstellt wurden, können nicht angezeigt oder verwaltet werden Diese Rolle eignet sich für Benutzer, die ihre eigenen Aufträge erstellen und verwalten müssen, aber keinen Zugriff auf Aufträge benötigen, die von anderen Benutzern erstellt wurden. + **SQLAgentReaderRole** Berechtigungen + Alle Berechtigungen der SQLAgentUserRole + Liste aller Aufträge und Zeitpläne anzeigen, einschließlich derer, die von anderen erstellt wurden + Eigenschaften aller Aufträge anzeigen + Auftragshistorie einsehen Diese Rolle eignet sich für Benutzer, die den Status aller Aufträge überwachen, diese aber nicht verwalten müssen. + **SQLAgentOperatorRole** Berechtigungen + Alle Berechtigungen der SQLAgentUserRole und SQLAgentReaderRole + Aufträge ausführen, anhalten oder starten + Auftragshistorie verwalten + Aufträge und Zeitpläne aktivieren/deaktivieren + Operatoren und Proxys anzeigen Diese Rolle bietet die umfassendsten Berechtigungen und eignet sich für Benutzer, die die volle Kontrolle über alle Aufträge haben müssen. Verwenden Sie den folgenden Befehl, um Ihrem SQL-Server-Anmeldenamen die Rollen zuzuweisen: ``` USE msdb; EXEC sp_addrolemember 'SQLAgentOperatorRole', 'username'; ``` ## Verwalten der SQLAgentOperatorRole in RDS für SQL Server Um die aktuellen Aufträge anzuzeigen, müssen Sie Ihrem SQL-Server-Anmeldenamen die Rolle SQLAgentOperatorRole hinzufügen und sie entfernen, bevor Sie die Verbindung zu Ihrer Datenbank trennen. Gehen Sie wie folgt vor, um die Struktur von SQL Server Agent in SQL Server Management Studio zu visualisieren: **Anzeigen von SQL Server Agent in SQL Server Management Studio (SSMS)** 1. Melden Sie sich mit den RDS-Hauptanmeldeinformationen bei der Instance von RDS SQL Server an und weisen Sie dem gewünschten Benutzer die SQLAgentUserRole zu. ``` USE msdb GO IF NOT EXISTS(SELECT name FROM sys.database_principals WHERE name = 'UserName') BEGIN CREATE USER UserName FROM LOGIN UserName END GO ALTER ROLE SQLAgentUserRole ADD MEMBER UserName GO GRANT ALTER ON ROLE::[SQLAgentOperatorRole] to UserName GO ``` Mit diesen Befehlen wird der Benutzer in der `msdb`-Datenbank erstellt, falls er nicht existiert. Außerdem wird der Benutzer zur SQLAgentUserRole hinzugefügt, sodass die Struktur von SQL Server Agent in SSMS sichtbar ist. Darüber hinaus werden dem Benutzer Änderungsberechtigungen für die SQLAgentOperatorRole gewährt. Auf diese Weise kann der Benutzer sich selbst zu dieser Rolle hinzufügen oder daraus entfernen. 1. Um sich selbst zu der oben genannten Rolle hinzuzufügen, stellen Sie mit dem Benutzer, der die Aufträge sehen muss, eine Verbindung zur Instance von RDS SQL Server her und führen Sie das folgende Skript aus. ``` use msdb go ALTER ROLE SQLAgentOperatorRole ADD MEMBER UserName GO ``` Danach klicken Sie mit der rechten Maustaste auf den Ordner **Aufträge** und wählen Sie **Aktualisieren**. 1. Wenn Sie diese Aktion ausführen, wird auf der Registerkarte **Aufträge** eine Schaltfläche mit einem Pluszeichen (**\$1**) angezeigt. Klicken Sie darauf, um die Liste der Aufträge für SQL Server Agent zu erweitern. 1. **Wichtig** Bevor Sie die Verbindung zur Instance von RDS SQL Server trennen, müssen Sie sich selbst aus der SQLAgentOperatorRole entfernen. Um Ihren Anmeldenamen aus der SQLAgentOperatorRole zu entfernen, führen Sie die folgende Abfrage aus, bevor Sie Management Studio trennen oder schließen: ``` USE msdb GO ALTER ROLE SQLAgentOperatorRole DROP MEMBER UserName GO ``` Weitere Informationen finden Sie unter [Leveraging SQLAgentOperatorRole in RDS SQL Server](https://aws.amazon.com/blogs/database/leveraging-sqlagentoperatorrole-in-rds-sql-server/). # Hinzufügen eines Benutzers zur Rolle SQLAgentUser Damit eine zusätzliche Anmeldung oder ein zusätzlicher Benutzer SQL Server Agent verwenden kann, müssen Sie sich als Hauptbenutzer anmelden und wie folgt vorgehen: 1. Erstellen Sie mithilfe des Befehls `CREATE LOGIN` eine weitere Anmeldung auf Serverebene. 1. Erstellen Sie mithilfe des Befehls `msdb` einen Benutzer in `CREATE USER` und verknüpfen Sie dann diesen Benutzer mit der Anmeldung, die Sie im vorherigen Schritt erstellt haben. 1. Fügen Sie den Benutzer`SQLAgentUserRole` mit der gespeicherten Systemprozedur `sp_addrolemember` hinzu. Nehmen wir beispielsweise an, Ihr Hauptbenutzername lautet **admin** und Sie möchten einem Benutzer mit dem Namen **theirname** und dem Passwort **theirpassword** den Zugriff auf SQL Server Agent erlauben. In diesem Fall können Sie das folgende Verfahren verwenden. **So fügen Sie zur Rolle SQLAgentUser einen Benutzer hinzu** 1. Melden Sie sich als Hauptbenutzer an. 1. Führen Sie die folgenden Befehle aus: ``` --Initially set context to master database USE [master]; GO --Create a server-level login named theirname with password theirpassword CREATE LOGIN [theirname] WITH PASSWORD = 'theirpassword'; GO --Set context to msdb database USE [msdb]; GO --Create a database user named theirname and link it to server-level login theirname CREATE USER [theirname] FOR LOGIN [theirname]; GO --Added database user theirname in msdb to SQLAgentUserRole in msdb EXEC sp_addrolemember [SQLAgentUserRole], [theirname]; ``` # Löschen eines SQL Server-Agent-Jobs Sie verwenden die gespeicherte Prozedur `sp_delete_job`, um SQL Server-Agent-Jobs auf Amazon RDS für Microsoft SQL Server zu löschen. Sie können SSMS nicht verwenden, um SQL Server-Agent-Jobs zu löschen. Falls Sie dies versuchen, erhalten Sie eine Fehlermeldung ähnlich der folgenden: ``` The EXECUTE permission was denied on the object 'xp_regread', database 'mssqlsystemresource', schema 'sys'. ``` Als verwalteter Service ist RDS von der Ausführung von Prozeduren ausgeschlossen, die auf die Windows-Registrierung zugreifen. Wenn Sie SSMS verwenden, versucht es, einen Prozess (`xp_regread`) auszuführen, für den RDS nicht autorisiert ist. **Anmerkung** Bei RDS für SQL Server dürfen nur Mitglieder der sysadmin-Rolle Jobs aktualisieren oder löschen, die einem anderen Anmeldenamen gehören. Weitere Informationen finden Sie unter [Leveraging SQLAgentOperatorRole in RDS SQL Server](https://aws.amazon.com/blogs/database/leveraging-sqlagentoperatorrole-in-rds-sql-server/). **So löschen Sie einen SQL Server-Agent-Job** + Führen Sie die folgende T-SQL-Anweisung aus: ``` EXEC msdb..sp_delete_job @job_name = 'job_name'; ``` # Arbeiten mit Microsoft-SQL-Server-Protokollen Sie können die SQL-Server-Agent-Protokolle, Microsoft-SQL-Server-Fehlerprotokolle und SQL Server Reporting Services (SSRS)-Protokolle mit der Amazon-RDS-Konsole anzeigen, beobachten und herunterladen. ## Beobachten von Protokolldateien Wenn Sie in der Amazon-RDS-Konsole ein Protokoll anzeigen, entsprechen dessen Inhalte diesem Moment. Das Beobachten eines Protokolls in der Konsole öffnet es in einem dynamischen Status, so dass die Aktualisierungen nahezu in Echtzeit angezeigt werden. Lediglich das aktuelle Protokoll ist zur Beobachtung aktiv. Nehmen wir an, es werden die folgenden Protokolle angezeigt: ![\[Ein Bild des Abschnitts „Protokolle“ aus der Amazon-RDS-Konsole mit einem ausgewählten Fehlerprotokoll.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/logs_sqlserver.png) Nur Protokoll/FEHLER, da das aktuelle Protokoll aktiv aktualisiert wird. Sie können auch andere beobachten, aber diese sind statisch und werden nicht aktualisiert. ## Archivieren von Protokolldateien In der Amazon-RDS-Konsole werden die Protokolle für die letzte Woche bis zum heutigen Tag angezeigt. Die Protokolle können zur Referenzzwecken für einen späteren Zeitpunkt heruntergeladen und archiviert werden. Eine Möglichkeit, Protokolle zu archivieren, besteht darin, sie in einen Amazon S3-Bucket zu laden. Anweisungen zum Einrichten eines Amazon S3-Buckets und zum Hochladen einer Datei finden Sie unter [Amazon S3-Grundlagen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AmazonS3Basics.html) im *Handbuch "Erste Schritte" zu Amazon Simple Storage Service* unter **Erste Schritte**. ## Anzeigen von Fehler- und Agent-Protokollen Um Microsoft SQL Server-Fehler- und Agent-Protokolle anzuzeigen, verwenden Sie die in Amazon RDS gespeicherte Prozedur `rds_read_error_log` mit den folgenden Parametern: + **`@index`** – die Version des abzurufenden Protokolls. Der Standardwert ist 0, der das aktuelle Fehlerprotokoll abruft. Legen Sie 1 fest, um das vorherige Protokoll abzurufen, legen Sie 2 fest, um das Protokoll davor abzurufen usw. + **`@type`** – die Art des abzurufenden Protokolls. Legen Sie 1 fest, um ein Fehlerprotokoll abzurufen. Legen Sie 2 fest, um ein Agent-Protokoll abzurufen. **Example** Das folgende Beispiel fordert das aktuelle Fehlerprotokoll an. ``` EXEC rdsadmin.dbo.rds_read_error_log @index = 0, @type = 1; ``` Weitere Informationen zu SQL Server-Fehlern finden Sie unter [Fehler der Datenbank-Engine](https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-events-and-errors) in der Microsoft-Dokumentation. # Arbeiten mit Trace- und Dump-Dateien für Amazon RDS für SQL Server Dieser Abschnitt beschreibt das Arbeiten mit Trace- und Dump-Dateien für Ihre Amazon-RDS-DB-Instances, auf denen Microsoft SQL Server ausgeführt wird. ## Generieren einer Trace-SQL-Abfrage ``` 1. declare @rc int 2. declare @TraceID int 3. declare @maxfilesize bigint 4. 5. set @maxfilesize = 5 6. 7. exec @rc = sp_trace_create @TraceID output, 0, N'D:\rdsdbdata\log\rdstest', @maxfilesize, NULL ``` ## Anzeigen eines offenen Trace ``` 1. select * from ::fn_trace_getinfo(default) ``` ## Anzeigen der Trace-Inhalte ``` 1. select * from ::fn_trace_gettable('D:\rdsdbdata\log\rdstest.trc', default) ``` ## Festlegen des Aufbewahrungszeitraums für Trace- und Dump-Dateien Trace- und Dump-Dateien können sich ansammeln und viel Festplattenspeicher belegen. Amazon RDS löscht automatisch Trace-und Dump-Dateien, die älter als sieben Tage sind. Um den aktuellen Aufbewahrungszeitraum für Trace- und Dump-Dateien anzuzeigen, verwenden Sie die Prozedur `rds_show_configuration`, wie im folgenden Beispiel zu sehen ist. ``` 1. exec rdsadmin..rds_show_configuration; ``` Um den Aufbewahrungszeitraum für Trace-Dateien zu ändern, verwenden Sie die Prozedur `rds_set_configuration` und legen `tracefile retention` in Minuten fest. Beim folgenden Beispiel wird der Aufbewahrungszeitraum für Trace-Dateien auf 24 Stunden festgelegt: ``` 1. exec rdsadmin..rds_set_configuration 'tracefile retention', 1440; ``` Um den Aufbewahrungszeitraum für Dump-Dateien zu ändern, verwenden Sie die Prozedur `rds_set_configuration` und legen `dumpfile retention` in Minuten fest. Beim folgenden Beispiel wird der Aufbewahrungszeitraum für Dump-Dateien auf 3 Tage festgelegt: ``` 1. exec rdsadmin..rds_set_configuration 'dumpfile retention', 4320; ``` Aus Sicherheitsgründen kann eine bestimmte Trace- oder Dump-Datei in einer SQL Server-DB-Instance nicht von Ihnen gelöscht werden. Damit alle ungenutzten Trace- oder Dump-Dateien gelöscht werden, legen sie den Aufbewahrungszeitraum für die Dateien auf 0 fest.