Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Tâches d’administrateur de base de données courantes pour Amazon RDS for Microsoft SQL Server
Cette section décrit les implémentations spécifiques à Amazon RDS de certaines tâches d'administration de base de données courantes pour les instances de base de données exécutant le moteur de base de données Microsoft SQL Server. Pour offrir une expérience de service géré, Amazon RDS ne fournit pas l'accès shell aux instances de bases de données et limite l'accès à certaines tables et procédures système qui requièrent des privilèges avancés.
**Note**
Lors de l'utilisation d'une instance de base de données SQL Server, vous pouvez exécuter des scripts pour modifier une base de données nouvellement créée, mais vous ne pouvez pas modifier la base de données [model], celle utilisée comme modèle pour les nouvelles bases de données.
**Topics**
+ [Accès à la base de données tempdb sur des instances de base de données Microsoft SQL Server sur Amazon RDS](SQLServer.TempDB.md)
+ [Analyse de la charge de travail d'une base de données sur une instance de base de données Amazon RDS for SQL Server avec l'Assistant Paramétrage du moteur de base de données](Appendix.SQLServer.CommonDBATasks.Workload.md)
+ [Remplacement de `db_owner` par le compte `rdsa` pour votre base de données Amazon RDS for SQL Server](Appendix.SQLServer.CommonDBATasks.ChangeDBowner.md)
+ [Gestion des classements et des jeux de caractères pour Amazon RDS for Microsoft SQL Server](Appendix.SQLServer.CommonDBATasks.Collation.md)
+ [Création d’un utilisateur de base de données pour Amazon RDS for SQL Server](Appendix.SQLServer.CommonDBATasks.CreateUser.md)
+ [Détermination d’un modèle de récupération pour votre base de données Amazon RDS for SQL Server](Appendix.SQLServer.CommonDBATasks.DatabaseRecovery.md)
+ [Détermination de l’heure du dernier basculement pour Amazon RDS for SQL Server](Appendix.SQLServer.CommonDBATasks.LastFailover.md)
+ [Dépannage des échecs de reprise ponctuelle dus à un écart de numéro de séquence de journal](Appendix.SQLServer.CommonDBATasks.PITR-LSN-Gaps.md)
+ [Refus ou autorisation de l’affichage des noms de base de données pour Amazon RDS for SQL Server](Appendix.SQLServer.CommonDBATasks.ManageView.md)
+ [Désactivation des insertions rapides pendant le chargement en masse pour Amazon RDS for SQL Server](Appendix.SQLServer.CommonDBATasks.DisableFastInserts.md)
+ [Suppression d’une base de données dans une instance de base de données Amazon RDS for Microsoft SQL Server](Appendix.SQLServer.CommonDBATasks.DropMirrorDB.md)
+ [Modification du nom d’une base de données Amazon RDS for Microsoft SQL Server dans un déploiement multi-AZ](Appendix.SQLServer.CommonDBATasks.RenamingDB.md)
+ [Réinitialisation de l’appartenance au rôle db\$1owner pour Amazon RDS for SQL Server](Appendix.SQLServer.CommonDBATasks.ResetPassword.md)
+ [Restauration des instances de base de données résiliées faute de licence pour Amazon RDS for SQL Server](Appendix.SQLServer.CommonDBATasks.RestoreLTI.md)
+ [Passage d’une base de données Amazon RDS for SQL Server de l’état OFFLINE à l’état ONLINE](Appendix.SQLServer.CommonDBATasks.TransitionOnline.md)
+ [Utilisation de la capture des données de modification pour Amazon RDS for SQL Server](Appendix.SQLServer.CommonDBATasks.CDC.md)
+ [Utilisation de SQL Server Agent pour Amazon RDS](Appendix.SQLServer.CommonDBATasks.Agent.md)
+ [Utilisation des journaux Amazon RDS for Microsoft SQL Server](Appendix.SQLServer.CommonDBATasks.Logs.md)
+ [Utilisation des fichiers de trace et de vidage pour Amazon RDS for SQL Server](Appendix.SQLServer.CommonDBATasks.TraceFiles.md)
# Accès à la base de données tempdb sur des instances de base de données Microsoft SQL Server sur Amazon RDS
Vous pouvez accéder à la base de données `tempdb` sur vos instances de base de données Microsoft SQL Server sur Amazon RDS. Vous pouvez exécuter le code sur `tempdb` à l'aide de Transact-SQL via Microsoft SQL Server Management Studio (SSMS) ou via toute autre application cliente SQL standard. Pour plus d'informations sur la connexion à votre instance de base de données, consultez [Connexion à votre instance de base de données Microsoft SQL Server](USER_ConnectToMicrosoftSQLServerInstance.md).
L'utilisateur principal pour votre instance de base de données bénéficie d'un accès `CONTROL` à `tempdb` afin qu'il puisse modifier les options de la base de données `tempdb`. L'utilisateur principal n'est pas le propriétaire de la base de données `tempdb`. Si nécessaire, l'utilisateur principal peut accorder un accès `CONTROL` à d'autres utilisateurs afin qu'ils puissent eux aussi modifier les options de la base de données `tempdb`.
**Note**
Vous ne pouvez pas exécuter de commandes DBCC (Database Console) sur la base de données `tempdb`.
# Modification des options de la base de données tempdb
Vous pouvez modifier les options de base de données sur la base de données `tempdb` sur vos instances de base de données Amazon RDS. Pour plus d'informations sur les options qui peuvent être modifiées, veuillez consulter [Base de données tempdb](https://msdn.microsoft.com/en-us/library/ms190768%28v=sql.120%29.aspx) dans la documentation Microsoft.
Les options de base de données telles que les options de taille maximale des fichiers sont persistantes une fois que vous redémarrez votre instance de base de données. Vous pouvez modifier les options de base de données pour optimiser les performances lors de l'importation des données et pour éviter le manque d'espace de stockage.
## Optimisation des performances lors de l'importation de données
Afin d'optimiser les performances lors de l'importation de grandes quantités de données dans votre instance de base de données, définissez les propriétés `SIZE` et `FILEGROWTH` de la base de données tempdb sur des grands chiffres. Pour plus d'informations sur la façon d'optimiser `tempdb`, veuillez consulter [Optimisation des performances de la base de données tempdb](https://technet.microsoft.com/en-us/library/ms175527%28v=sql.120%29.aspx) dans la documentation Microsoft.
L'exemple suivant illustre la définition de la taille sur 100 Go et la croissance des fichiers sur 10 pour cent.
```
1. alter database[tempdb] modify file (NAME = N'templog', SIZE=100GB, FILEGROWTH = 10%)
```
## Prévention des problèmes de stockage
Pour éviter que la base de données `tempdb` utilise tout l'espace disque disponible, définissez la propriété `MAXSIZE`. L'exemple suivant illustre la définition de la propriété sur 2 048 Mo.
```
1. alter database [tempdb] modify file (NAME = N'templog', MAXSIZE = 2048MB)
```
# Réduction de la base de données tempdb
Il existe deux façons de réduire la base de données `tempdb` sur votre instance de base de données Amazon RDS. Vous pouvez utiliser la procédure `rds_shrink_tempdbfile` ou vous pouvez définir la propriété `SIZE`.
## Utilisation de la procédure rds\$1shrink\$1tempdbfile
Vous pouvez utiliser la procédure Amazon RDS `msdb.dbo.rds_shrink_tempdbfile` pour réduire la base de données `tempdb`. Vous pouvez uniquement appeler `rds_shrink_tempdbfile` si vous disposez de l'accès `CONTROL` à `tempdb`. Lorsque vous appelez `rds_shrink_tempdbfile`, il n'y a aucun temps d'arrêt pour votre instance de base de données.
La procédure `rds_shrink_tempdbfile` possède les paramètres suivants.
****
| Nom du paramètre | Type de données | Par défaut | Obligatoire | Description |
| --- | --- | --- | --- | --- |
| `@temp_filename` | SYSNAME | — | obligatoire | Le nom logique du fichier à réduire. |
| `@target_size` | int | null | facultatif | La nouvelle taille du fichier en mégaoctets. |
L'exemple suivant permet d'obtenir les noms des fichiers de la base de données `tempdb`.
```
1. use tempdb;
2. GO
3.
4. select name, * from sys.sysfiles;
5. GO
```
L'exemple suivant réduit un fichier de base de données `tempdb` nommé `test_file` et demande une nouvelle taille de `10` mégaoctets :
```
1. exec msdb.dbo.rds_shrink_tempdbfile @temp_filename = N'test_file', @target_size = 10;
```
## Configuration de la propriété SIZE
Vous pouvez également réduire la base de données `tempdb` en configurant la propriété `SIZE` et en redémarrant votre instance de base de données. Pour plus d'informations sur le redémarrage de votre instance de base de données, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md).
L'exemple suivant illustre la définition de la propriété `SIZE` sur 1 024 Mo.
```
1. alter database [tempdb] modify file (NAME = N'templog', SIZE = 1024MB)
```
# Configuration de TempDB pour les déploiements multi-AZ
Si votre instance de base de données RDS for SQL Server est un déploiement multi-AZ qui utilise la mise en miroir de la base de données (DBM, Database Mirroring) ou les groupes de disponibilité (AG, Availability Groups) toujours actifs, gardez à l’esprit les points suivants concernant l’utilisation de la base de données `tempdb`.
Vous ne pouvez pas répliquer les données `tempdb` de votre instance de base de données principale vers votre instance de base de données secondaire. Lorsque vous basculez vers une instance de base de données secondaire, `tempdb` sera vide sur cette instance de base de données secondaire.
Vous pouvez synchroniser la configuration des options de la base de données `tempdb`, y compris ses paramètres de dimensionnement des fichiers et de croissance automatique, entre votre instance de base de données principale et celle secondaire. La synchronisation de la configuration `tempDB` est prise en charge sur toutes les versions de RDS for SQL Server. Vous pouvez activer la synchronisation automatique de la configuration `tempdb` à l’aide de la procédure stockée suivante :
```
EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'TempDbFile';
```
**Important**
Avant d’utiliser la procédure stockée `rds_set_system_database_sync_objects`, assurez-vous d’avoir défini votre configuration `tempdb` préférée sur votre instance de base de données principale plutôt que sur celle secondaire. Si vous avez modifié la configuration sur votre instance de base de données secondaire, votre configuration `tempdb` préférée risque d’être supprimée lorsque vous activerez la synchronisation automatique.
Vous pouvez utiliser la fonction suivante pour vérifier si la synchronisation automatique de la configuration `tempdb` est activée :
```
SELECT * from msdb.dbo.rds_fn_get_system_database_sync_objects();
```
Lorsque la synchronisation automatique de la configuration `tempdb` est activée, une valeur est renvoyée pour le champ `object_class`. Lorsqu’elle est désactivée, aucune valeur n’est renvoyée.
Vous pouvez utiliser la fonction suivante pour trouver la dernière synchronisation des objets selon le fuseau horaire UTC :
```
SELECT * from msdb.dbo.rds_fn_server_object_last_sync_time();
```
Par exemple, si vous avez modifié la configuration `tempdb` à 01 h 00, puis que vous exécutez la fonction `rds_fn_server_object_last_sync_time`, la valeur renvoyée pour `last_sync_time` doit être postérieure à 01 h 00, ce qui indique qu’une synchronisation automatique a eu lieu.
Si vous utilisez également la réplication des tâches SQL Server Agent, vous pouvez activer la réplication à la fois pour les tâches SQL Agent et pour la configuration `tempdb` en les fournissant dans le paramètre `@object_type` :
```
EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'SQLAgentJob,TempDbFile';
```
Pour plus d’informations sur la réplication des tâches SQL Server Agent, consultez[Activation de la réplication des tâches de l'agent SQL Server](Appendix.SQLServer.CommonDBATasks.Agent.md#SQLServerAgent.Replicate).
Au lieu d’utiliser la procédure stockée `rds_set_system_database_sync_objects` pour garantir la synchronisation automatique des modifications de configuration `tempdb`, vous pouvez utiliser l’une des méthodes manuelles suivantes :
**Note**
Nous vous recommandons d’activer la synchronisation automatique de la configuration `tempdb` à l’aide de la procédure stockée `rds_set_system_database_sync_objects`. L’utilisation de la synchronisation automatique évite d’avoir à effectuer ces tâches manuelles chaque fois que vous modifiez votre configuration `tempdb`.
+ Tout d'abord, modifiez votre instance de base de données et désactivez le déploiement multi-AZ, puis modifier tempdb, puis enfin réactivez le déploiement multi-AZ. Cette méthode n'entraîne aucun temps d'arrêt.
Pour plus d'informations, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
+ Tout d'abord, modifiez `tempdb` dans l'instance principale d'origine, puis exécutez un basculement manuel et enfin modifiez `tempdb` dans la nouvelle instance principale. Cette méthode implique un temps d'arrêt.
Pour plus d’informations, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md).
# Analyse de la charge de travail d'une base de données sur une instance de base de données Amazon RDS for SQL Server avec l'Assistant Paramétrage du moteur de base de données
L'Assistant Paramétrage du moteur de base de données est une application cliente fournie par Microsoft qui analyse la charge de travail de la base de données et recommande un ensemble optimal d'index pour vos bases de données Microsoft SQL Server en fonction des types de requêtes que vous exécutez. Comme SQL Server Management Studio, vous exécutez l'Assistant Paramétrage à partir d'un ordinateur client qui se connecte à votre instance de base de données Amazon RDS exécutant SQL Server. L'ordinateur client peut être un ordinateur local que vous exécutez sur site au sein de votre propre réseau ou une instance Amazon EC2 Windows qui s'exécute dans la même région que votre instance de base de données Amazon RDS.
Cette section montre comment capturer une charge de travail pour que l'Assistant Paramétrage l'analyse. Il s'agit du processus privilégié pour capturer une charge de travail parce que Amazon RDS limite l'accès de l'hôte à l'instance SQL Server. Pour plus d'informations, consultez [Assistant Paramétrage du moteur de base de données](https://docs.microsoft.com/en-us/sql/relational-databases/performance/database-engine-tuning-advisor) dans la documentation Microsoft.
Pour utiliser l'Assistant Paramétrage, vous devez lui fournir ce qu'on appelle une charge de travail. Une charge de travail est un ensemble d'instructions Transact-SQL qui s'exécutent sur une base de données ou des bases de données que vous voulez régler. L'Assistant Paramétrage du moteur de base de données utilise les fichiers trace, les tables de trace, les scripts Transact-SQL ou les fichiers XML comme entrées de charge de travail lors du réglage des bases de données. Lors de l'utilisation de Amazon RDS, une charge de travail peut être un fichier sur un ordinateur client ou une table de base de données sur une instance de base de données Amazon RDS for SQL Server accessible à votre ordinateur client. Le fichier ou la table doit contenir des requêtes sur les bases de données que vous voulez régler dans un format adapté à la relecture.
Pour que l'Assistant Paramétrage soit le plus efficace, une charge de travail doit être aussi réaliste que possible. Vous pouvez générer un fichier de charge de travail ou une table en exécutant une trace sur votre instance de base de données. Pendant l'exécution d'une trace, vous pouvez simuler une charge sur votre instance de base de données ou exécuter vos applications avec une charge normale.
Il existe deux types de trace : côté client et côté serveur. Une trace côté client est plus facile à configurer et vous pouvez observer les événements de trace capturés en temps réel dans SQL Server Profiler. Une trace côté serveur est plus complexe à configurer et nécessite une tâche de scripting Transact-SQL. De plus, comme la trace est écrite dans un fichier de l'instance de base de données Amazon RDS, l'espace de stockage est utilisé par la trace. Il importe de tracer la quantité d'espace de stockage qu'une trace côté serveur utilise, parce que l'instance de base de données peut entrer dans un état de stockage complet et n'être plus disponible si elle se trouve à court d'espace de stockage.
Pour une trace côté client, quand une quantité suffisante de données de trace a été capturée dans SQL Server Profiler, vous pouvez générer le fichier de charge de travail en enregistrant la trace sur un fichier de votre ordinateur local ou dans une table de base de données d'une instance de base de données accessible à votre ordinateur client. Le principal désavantage de l'utilisation d'une trace côté client est que la trace peut ne pas capturer toutes les requêtes quand elle est soumise à de lourdes charges. Cela pourrait affaiblir l'efficacité de l'analyse exécutée par l'Assistant Paramétrage du moteur de base de données. Si vous devez exécuter une trace soumise à des charges massives et que vous voulez vous assurer qu'elle capture chaque requête pendant une session de trace, vous devez utiliser une trace côté serveur.
Pour une trace côté serveur, vous devez obtenir les fichiers de trace de l'instance de base de données en un fichier de charge de travail adapté ou vous pouvez enregistrer la trace sur une table de l'instance de base de données une fois la trace terminée. Vous pouvez utiliser SQL Server Profiler pour enregistrer la trace sur un fichier de votre ordinateur local ou faire en sorte que l'Assistant Paramétrage lise à partir de la table de trace sur l'instance de base de données.
# Exécution d'une trace côté client sur une instance de base de données SQL Server
**Pour exécuter une trace côté client sur une instance de base de données SQL Server**
1. Démarrez SQL Server Profiler. Il est installé dans le dossier Outils de performance de votre dossier d'instances SQL Server. Vous devez charger ou définir un modèle de définition de trace pour démarrer une trace côté client.
1. Dans le menu du fichier SQL Server Profiler, choisissez **New Trace (Nouvelle trace)**. Dans la boîte de dialogue **Connect to Server (Se connecter au serveur)**, entrez le point de terminaison de l'instance de base de données, le port, l'identifiant principal et le mot de passe de la base de données sur laquelle vous souhaitez exécuter une trace.
1. Dans la boîte de dialogue **Propriétés de la trace**, entrez un nom de trace et choisissez un modèle de définition de trace. Un modèle par défaut, TSQL\$1Replay, est fourni avec l'application. Vous pouvez modifier ce modèle pour définir votre trace. Modifiez les événements et les informations relatives aux événements sous l'onglet **Sélection des événements** de la boîte de dialogue **Propriétés de la trace**.
Pour plus d'informations sur les modèles de définition de trace et l'utilisation de SQL Server Profiler pour spécifier une trace côté client, consultez [Assistant Paramétrage du moteur de base de données](https://docs.microsoft.com/en-us/sql/relational-databases/performance/database-engine-tuning-advisor) dans la documentation Microsoft.
1. Démarrez la trace côté client et observez les requêtes SQL en temps réel tandis qu'elles s'exécutent sur votre instance de base de données.
1. Sélectionnez **Stop Trace (Arrêter la trace)** dans le menu **Fichier** lorsque vous avez terminé la trace. Enregistrez les résultats comme fichier ou comme table de trace sur votre instance de base de données.
# Exécution d'une trace côté serveur sur une instance de base de données SQL Server
L'écriture de scripts pour créer une trace côté serveur peut être complexe et au-delà de la portée de ce document. Cette section contient des scripts que vous pouvez utiliser comme exemples. Comme pour une trace côté client, l'objectif est de créer un fichier de charge de travail ou une table de trace que vous pouvez ouvrir à l'aide de l'Assistant Paramétrage du moteur de base de données.
L'exemple abrégé suivant est un script qui démarre une trace côté serveur et capture les détails dans un fichier de charge de travail. La trace est initialement enregistrée dans le fichier RDSTrace .trc du répertoire D:\$1RDSDBDATA\$1Log et est reportée tous les 100 Mo, de sorte que les fichiers de trace suivants sont nommés RDSTrace \$11.trc, \$12.trc, etc. 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
```
L'exemple suivant illustre un script qui arrête une trace. Notez qu'une trace créée par le précédent script continue à s'exécuter jusqu'à ce que vous arrêtiez explicitement la trace ou que le processus ne dispose plus d'espace disque suffisant.
```
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
```
Vous pouvez enregistrer les résultats de la trace côté serveur sur une table de base de données et utiliser celle-ci comme charge de travail pour l'Assistant Paramétrage à l'aide de la fonction fn\$1trace\$1gettable. Les commandes suivantes chargent les résultats de tous les fichiers nommés RDSTrace .trc du répertoire D:\$1rdsdbdata\$1Log, y compris tous les fichiers de survol tels que RDSTrace \$11.trc, dans une table nommée dans la base de données actuelle. RDSTrace
```
SELECT * INTO RDSTrace
FROM fn_trace_gettable('D:\rdsdbdata\Log\RDSTrace.trc', default);
```
Pour enregistrer un fichier de survol spécifique dans une table, par exemple le fichier RDSTrace \$11.trc, spécifiez le nom du fichier de survol et remplacez 1 par défaut comme dernier paramètre de fn\$1trace\$1gettable.
```
SELECT * INTO RDSTrace_1
FROM fn_trace_gettable('D:\rdsdbdata\Log\RDSTrace_1.trc', 1);
```
# Exécution de l'Assistant Paramétrage avec une trace
Une fois que vous créez une trace, comme fichier local ou comme table de base de données, vous pouvez exécuter l'Assistant Paramétrage sur votre instance de base de données. L'utilisation de l'Assistant Paramétrage avec Amazon RDS repose sur le même processus que l'utilisation d'une instance SQL Server autonome et distante. Vous pouvez utiliser l'interface utilisateur de l'Assistant Paramétrage sur votre ordinateur client ou choisir l'utilitaire dta.exe à partir de la ligne de commande. Dans les deux cas, vous devez vous connecter à l'instance de base de données Amazon RDS à l'aide du point de terminaison de l'instance de base de données, et fournir votre nom d'utilisateur maître et votre mot de passe utilisateur maître lors de l'utilisation de l'Assistant Paramétrage.
L'exemple de code suivant illustre l'utilisation de l'utilitaire de ligne de commande dta.exe sur une instance de base de données Amazon RDS avec le point de terminaison **dta.cnazcmklsdei.us-east-1.rds.amazonaws.com**. L'exemple inclut le nom d'utilisateur principal **admin** et le mot de passe de l'utilisateur principal **test**. L'exemple de base de données à régler se nomme ordinateur nommé **C:\$1RDSTrace.trc**. L'exemple de code de ligne de commande spécifie également une session de trace nommée **RDSTrace1**, ainsi que les fichiers de sortie sur l'ordinateur local nommés **RDSTrace.sql** pour le script de sortie SQL, **RDSTrace.txt** pour un fichier résultat et **RDSTrace.xml** pour un fichier XML de l'analyse. Il existe aussi une table d'erreur spécifiée sur la base de données RDSDTA et nommée **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
```
Voici le même exemple de code de ligne de commande, à ceci près que la charge de travail en entrée est une table de l'instance Amazon RDS distante nommée **RDSTrace** qui se trouve sur la base de données **RDSDTA**.
```
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
```
Pour obtenir la liste complète des paramètres de ligne de commande de l'utilitaire dta, consultez[Utilitaire dta](https://docs.microsoft.com/en-us/sql/tools/dta/dta-utility) dans la documentation Microsoft.
# Remplacement de `db_owner` par le compte `rdsa` pour votre base de données Amazon RDS for SQL Server
Lorsque vous créez ou restaurez une base de données dans une instance de base de données RDS for SQL Server, Amazon RDS définit le propriétaire de la base de données sur `rdsa`. Si vous avez un déploiement multi-AZ utilisant SQL Server Database Mirroring (DBM) ou Always On Availability Groups ()AGs, Amazon RDS définit le propriétaire de la base de données sur l'instance de base de données secondaire sur. `NT AUTHORITY\SYSTEM` Le propriétaire de la base de données secondaire ne peut pas être modifié tant que l'instance de base de données secondaire n'est pas promue au rôle principal. Dans la plupart des cas, le fait de définir le propriétaire de la base de données sur `NT AUTHORITY\SYSTEM` ne pose pas de problèmes lors de l'exécution de requêtes, mais cela peut générer des erreurs pendant l'exécution de procédures stockées système telles que `sys.sp_updatestats`, qui ont besoin d'autorisations élevées pour s'exécuter.
Vous pouvez utiliser la requête suivante pour identifier le propriétaire des bases de données détenues par `NT AUTHORITY\SYSTEM` :
```
SELECT name FROM sys.databases WHERE SUSER_SNAME(owner_sid) = 'NT AUTHORITY\SYSTEM';
```
Vous pouvez utiliser la procédure stockée Amazon RDS `rds_changedbowner_to_rdsa` pour remplacer le propriétaire de la base de données par `rdsa`. Les bases de données suivantes ne sont pas autorisées à être utilisées avec `rds_changedbowner_to_rdsa` : `master, model, msdb, rdsadmin, rdsadmin_ReportServer, rdsadmin_ReportServerTempDB, SSISDB`.
Pour remplacer le propriétaire de la base de données par `rdsa`, appelez la procédure stockée `rds_changedbowner_to_rdsa` et fournissez le nom de la base de données.
**Example d'utilisation :**
```
exec msdb.dbo.rds_changedbowner_to_rdsa 'TestDB1';
```
Les paramètres suivants sont obligatoires :
+ `@db_name` – Nom de la base de données dont le propriétaire doit être remplacé par `rdsa`.
**Important**
Vous ne pouvez pas utiliser `rds_changedbowner_to_rdsa` pour remplacer le propriétaire d’une base de données par un identifiant autre que `rdsa`. Par exemple, vous ne pouvez pas modifier le propriétaire de l’identifiant avec lequel vous avez créé la base de données. Pour rétablir l’appartenance perdue au rôle `db_owner` de votre utilisateur principal alors qu’aucun autre utilisateur de base de données ne peut être utilisé pour accorder l’appartenance, réinitialisez le mot de passe de l’utilisateur principal pour obtenir l’appartenance au rôle `db_owner`. Pour plus d’informations, consultez [Réinitialisation de l’appartenance au rôle db\$1owner pour Amazon RDS for SQL Server](Appendix.SQLServer.CommonDBATasks.ResetPassword.md).
# Gestion des classements et des jeux de caractères pour Amazon RDS for Microsoft SQL Server
Cette rubrique fournit des conseils sur la gestion des classements et des jeux de caractères pour Microsoft SQL Server dans Amazon RDS. Elle explique comment configurer les classements lors de la création de la base de données et comment les modifier ultérieurement, afin de garantir une gestion appropriée des données textuelles en fonction des exigences en matière de langue et de paramètres régionaux. En outre, elle décrit les bonnes pratiques pour maintenir la compatibilité et les performances dans les environnements SQL Server sur Amazon RDS.
SQL Server prend en charge les classements à différents niveaux. Vous définissez le classement de serveur par défaut lorsque vous créez l'instance de base de données. Vous pouvez remplacer le classement au niveau de la base de données, de la table ou de la colonne.
**Topics**
+ [Classement de niveau serveur pour Microsoft SQL Server](#Appendix.SQLServer.CommonDBATasks.Collation.Server)
+ [Classement au niveau de la base de données pour Microsoft SQL Server](#Appendix.SQLServer.CommonDBATasks.Collation.Database-Table-Column)
## Classement de niveau serveur pour Microsoft SQL Server
Lorsque vous créez une instance de base de données Microsoft SQL Server, vous pouvez définir le classement de serveur que vous souhaitez utiliser. Si vous ne choisissez aucun autre classement, le classement au niveau du serveur prend par défaut la valeur SQL\$1Latin1\$1General\$1 \$1CI\$1AS. CP1 Le classement de serveur est appliqué par défaut à toutes les bases de données et à tous les objets de base de données.
**Note**
Vous ne pouvez pas modifier le classement lorsque vous effectuez une restauration à partir d'un instantané de base de données.
Amazon RDS prend actuellement en charge les classements de serveur suivants :
| Classement (Collation) | Description |
| --- | --- |
| Arabic\$1CI\$1AS | Arabe, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Chinois\$1PRC\$1 BIN2 | Chinois-PRC, ordre de tri des points de code binaire |
| Chinese\$1PRC\$1CI\$1AS | Chinois - RPC, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Chinese\$1Taiwan\$1Stroke\$1CI\$1AS | Chinois de Taiwan, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Danish\$1Norwegian\$1CI\$1AS | Danois-Norvégien, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Danish\$1Norwegian\$1CI\$1AS\$1KS | Danois-Norvégien, insensible à la casse, sensible aux accents, sensible au type de kana, insensible à la largeur |
| Danish\$1Norwegian\$1CI\$1AS\$1KS\$1WS | Danois-Norvégien, insensible à la casse, sensible aux accents, sensible au type de kana, sensible à la largeur |
| Danish\$1Norwegian\$1CI\$1AS\$1WS | Danois-Norvégien, insensible à la casse, sensible aux accents, insensible au type de kana, sensible à la largeur |
| Danish\$1Norwegian\$1CS\$1AI | Danois-Norvégien, sensible à la casse, insensible aux accents, insensible au type de kana, insensible à la largeur |
| Danish\$1Norwegian\$1CS\$1AI\$1KS | Danois-Norvégien, sensible à la casse, insensible aux accents, sensible au type de kana, insensible à la largeur |
| Finnish\$1Swedish\$1100\$1BIN | Finnois-Suédois-100, tri binaire |
| Finlandais\$1Suédois\$1100\$1 BIN2 | Finnois-Suédois-100, tri de comparaison de points de code binaire |
| Finnish\$1Swedish\$1100\$1CI\$1AI | Finnois-Suédois-100, insensible à la casse, insensible aux accents, insensible au type de kana, insensible à la largeur |
| Finnish\$1Swedish\$1100\$1CI\$1AS | Finnois-Suédois-100, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Finnish\$1Swedish\$1CI\$1AS | Finnois, suédois et suédois (Finlande), insensible à la casse, sensible aux accents, sensible aux caractères Kana et insensible à la largeur. |
| French\$1CI\$1AS | Français, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Greek\$1CI\$1AS | Grec, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Greek\$1CS\$1AS | Grec, sensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Hebrew\$1BIN | Hébreu, tri binaire |
| Hebrew\$1CI\$1AS | Hebrew, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Japanese\$1BIN | Japonais, tri binaire |
| Japanese\$1CI\$1AS | Japonais, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Japanese\$1CS\$1AS | Japonais, sensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Japanese\$1XJIS\$1140\$1CI\$1AS | Japonais, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur, caractères supplémentaires, insensible au sélecteur de variante |
| Japanese\$1XJIS\$1140\$1CI\$1AS\$1KS\$1VSS | Japonais, insensible à la casse, sensible aux accents, sensible au type de kana, insensible à la largeur, caractères supplémentaires, sensible au sélecteur de variante |
| Japanese\$1XJIS\$1140\$1CI\$1AS\$1VSS | Japonais, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur, caractères supplémentaires, sensible au sélecteur de variante |
| Japanese\$1XJIS\$1140\$1CS\$1AS\$1KS\$1WS | Japonais, sensible à la casse, sensible aux accents, sensible au type de kana, sensible à la largeur, caractères supplémentaires, insensible au sélecteur de variante |
| Korean\$1Wansung\$1CI\$1AS | Korean-Wansung, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Latin1\$1General\$1100\$1BIN | Latin1-General-100, tri binaire |
| Latin1\$1Général\$1100\$1 BIN2 | Latin1-General-100, ordre de tri des points de code binaire |
| Latin1\$1Général\$1100\$1 \$1 BIN2 UTF8 | Latin1-General-100, ordre de tri des points de code binaire, codé en UTF-8 |
| Latin1\$1General\$1100\$1CI\$1AS | Latin1-General-100, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Latin1\$1General\$1100\$1CI\$1AS\$1SC\$1 UTF8 | Latin1-General-100, insensible à la casse, sensible aux accents, caractères supplémentaires, codé en UTF-8 |
| Latin1\$1General\$1BIN | Latin1-General, tri binaire |
| Latin1\$1Général\$1 BIN2 | Latin1-General, ordre de tri des points de code binaire |
| Latin1\$1General\$1CI\$1AI | Latin1-General, insensible à la casse, insensible aux accents, insensible au type de kana, insensible à la largeur |
| Latin1\$1General\$1CI\$1AS | Latin1-General, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Latin1\$1General\$1CI\$1AS\$1KS | Latin1-General, insensible à la casse, sensible aux accents, sensible au type de kana, insensible à la largeur |
| Latin1\$1General\$1CS\$1AS | Latin1-General, sensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Modern\$1Spanish\$1CI\$1AS | Modern-Spanish, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Polish\$1CI\$1AS | Polonais, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| SQL\$11xCompat\$1 \$1CI\$1AS CP850 | Latin1-General, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur pour les données Unicode, ordre de tri SQL Server 49 sur la page de codes 850 pour les données non Unicode |
| SQL\$1Latin1\$1Général\$1 \$1CI\$1AI CP1 | Latin1-General, insensible à la casse, insensible aux accents, insensible au type de kana, insensible à la largeur pour les données Unicode, ordre de tri SQL Server 54 sur la page de codes 1252 pour les données non Unicode |
| **SQL\$1Latin1\$1General\$1 \$1CI\$1AS (par défautCP1)** | Latin1-General, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur pour les données Unicode, ordre de tri SQL Server 52 sur la page de codes 1252 pour les données non Unicode |
| SQL\$1Latin1\$1General\$1 \$1CS\$1AS CP1 | Latin1-General, sensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur pour les données Unicode, ordre de tri SQL Server 51 sur la page de codes 1252 pour les données non Unicode |
| SQL\$1Latin1\$1Général\$1 \$1CI\$1AI CP437 | Latin1-General, insensible à la casse, insensible aux accents, insensible au type de kana, insensible à la largeur pour les données Unicode, ordre de tri SQL Server 34 sur la page de codes 437 pour les données non Unicode |
| SQL\$1Latin1\$1Général\$1 \$1BIN CP850 | Latin1-General, ordre de tri binaire pour les données Unicode, ordre de tri SQL Server 40 sur la page de codes 850 pour les données non Unicode |
| SQL\$1Latin1\$1Général\$1 \$1 CP850 BIN2 | Latin1-General, ordre de tri des points de code binaire pour les données Unicode, ordre de tri SQL Server 40 sur la page de codes 850 pour les données non Unicode |
| SQL\$1Latin1\$1Général\$1 \$1CI\$1AI CP850 | Latin1-General, insensible à la casse, insensible aux accents, insensible au type de kana, insensible à la largeur pour les données Unicode, ordre de tri SQL Server 44 sur la page de codes 850 pour les données non Unicode |
| SQL\$1Latin1\$1General\$1 \$1CI\$1AS CP850 | Latin1-General, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur pour les données Unicode, ordre de tri SQL Server 42 sur la page de codes 850 pour les données non Unicode |
| SQL\$1Latin1\$1General\$1Pref\$1 \$1CI\$1AS CP850 | Latin1-General-Préf, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur pour les données Unicode, ordre de tri SQL Server 183 sur la page de codes 850 pour les données non Unicode |
| SQL\$1Latin1\$1General\$1 \$1CI\$1AS CP1256 | Latin1-General, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur pour les données Unicode, ordre de tri SQL Server 146 sur la page de codes 1256 pour les données non Unicode |
| SQL\$1Latin1\$1General\$1 \$1CS\$1AS CP1255 | Latin1-General, sensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur pour les données Unicode, ordre de tri SQL Server 137 sur la page de codes 1255 pour les données non Unicode |
| Thai\$1CI\$1AS | Thaï, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
| Turkish\$1CI\$1AS | Turc, insensible à la casse, sensible aux accents, insensible au type de kana, insensible à la largeur |
Vous pouvez également récupérer la liste des classements pris en charge par programme à l’aide de l’ AWS CLI :
```
aws rds describe-db-engine-versions --engine sqlserver-ee --list-supported-character-sets --query 'DBEngineVersions[].SupportedCharacterSets[].CharacterSetName' | sort -u
```
Pour choisir la classement :
+ Si vous utilisez la console Amazon RDS, lors de la création d'une nouvelle instance de base de données, choisissez **Additional configuration** (Configuration supplémentaire), puis saisissez le classement dans le menu **Collation** (Classement). Pour de plus amples informations, veuillez consulter [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
+ Si vous utilisez le AWS CLI, utilisez l'`--character-set-name`option avec la `create-db-instance` commande. Pour de plus amples informations, veuillez consulter [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html).
+ Si vous utilisez l'API Amazon RDS, utilisez le paramètre `CharacterSetName` avec l'opération `CreateDBInstance`. Pour plus d'informations, consultez la section [Créer DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html).
## Classement au niveau de la base de données pour Microsoft SQL Server
Vous pouvez modifier la classement par défaut au niveau base de données, table ou colonne, en remplaçant le classement de la création d'une nouvelle base de données ou d'un objet de base de données. Par exemple, si le classement de votre serveur par défaut est SQL\$1Latin1\$1General\$1 \$1CI\$1AS, vous pouvez le remplacer par CP1 Mohawk\$1100\$1CI\$1AS pour la prise en charge du classement Mohawk. Même les arguments d'une requête peuvent être l'objet d'un cast de type afin d'utiliser un classement différent si nécessaire.
Par exemple, la requête suivante changerait le classement par défaut de la AccountName colonne en Mohawk\$1100\$1CI\$1AS
```
CREATE TABLE [dbo].[Account]
(
[AccountID] [nvarchar](10) NOT NULL,
[AccountName] [nvarchar](100) COLLATE Mohawk_100_CI_AS NOT NULL
) ON [PRIMARY];
```
Le moteur de base de données Microsoft SQL Server prend en charge Unicode à l'aide des types de données intégrés NCHAR, NVARCHAR et NTEXT. Par exemple, si vous avez besoin du support CJC, utilisez ces types de données Unicode pour le stockage des caractères et remplacer le classement de serveur par défaut lors de la création de vos bases de données et tables. Voici plusieurs liens depuis Microsoft couvrant le classement et le support Unicode pour SQL Server :
+ [Working with Collations (Utilisation des collectes)](http://msdn.microsoft.com/en-us/library/ms187582%28v=sql.105%29.aspx)
+ [Collation and International Terminology (Collecte et terminologie internationale)](http://msdn.microsoft.com/en-us/library/ms143726%28v=sql.105%29)
+ [Using SQL Server Collations (Utilisation de collectes SQL Server)](http://msdn.microsoft.com/en-us/library/ms144260%28v=sql.105%29.aspx)
+ [International Considerations for Databases and Database Engine Applications (Considérations internationales pour les bases de données et les applications de moteur de base de données)](http://msdn.microsoft.com/en-us/library/ms190245%28v=sql.105%29.aspx)
# Création d’un utilisateur de base de données pour Amazon RDS for SQL Server
Vous pouvez créer un utilisateur de base de données pour votre instance de base de données Amazon RDS for Microsoft SQL Server en exécutant un script T-SQL, comme dans l'exemple suivant. Utilisez une application telle que SQL Server Management Suite (SSMS). Connectez-vous à l'instance de base de données en tant que l'utilisateur principal créé lors de la création de l'instance de base de données.
```
--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
```
Pour consulter un exemple d'ajout d'utilisateur de base de données à un rôle, consultez [Ajout d'un utilisateur au rôle SQLAgentUser](SQLServerAgent.AddUser.md).
**Note**
Si vous obtenez des erreurs d'autorisation lors de l'ajout d'un utilisateur, vous pouvez restaurer les privilèges en modifiant le mot de passe de l'utilisateur principal de l'instance de base de données. Pour plus d’informations, consultez [Réinitialisation de l’appartenance au rôle db\$1owner pour Amazon RDS for SQL Server](Appendix.SQLServer.CommonDBATasks.ResetPassword.md).
Il n’est pas recommandé de cloner les autorisations des utilisateurs principaux dans vos applications. Pour plus d’informations, consultez [Comment cloner les autorisations d’utilisateur principal dans Amazon RDS for SQL Server](https://aws.amazon.com/blogs/database/how-to-clone-master-user-permissions-in-amazon-rds-for-sql-server/).
# Détermination d’un modèle de récupération pour votre base de données Amazon RDS for SQL Server
Dans Amazon RDS, le modèle de récupération, la période de conservation et le statut de base de données sont liés.
Il est important de comprendre les conséquences avant de modifier l'un de ces paramètres. Chaque paramètre peut affecter les autres. Exemples :
+ Si vous remplacez le modèle de récupération d'une base de données par le modèle SIMPLE ou BULK\$1LOGGED alors que la conservation des sauvegardes est activée, Amazon RDS rétablit le modèle de récupération FULL dans les cinq minutes qui suivent. Cela entraîne également la prise d'un instantané de l'instance de base de données par RDS.
+ Si vous définissez la conservation des sauvegardes sur `0` jour(s), RDS définit le modèle de récupération sur SIMPLE.
+ Si vous remplacez le modèle de récupération d'une base de données SIMPLE par une autre option alors que la conservation des sauvegardes est définie sur `0` jour(s), RDS rétablit le modèle de récupération SIMPLE.
**Important**
Ne changez jamais le modèle de récupération sur des instances multi-AZ, même s'il semble que vous pouvez le faire (par exemple, en utilisant ALTER DATABASE). La conservation des sauvegardes et donc le mode de récupération FULL sont nécessaires pour l'option multi-AZ. Si vous modifiez le modèle de récupération, RDS le rétablit immédiatement sur FULL.
Cette réinitialisation automatique oblige RDS à reconstruire complètement le miroir. Au cours de cette reconstruction, la disponibilité de la base de données est dégradée pendant environ 30 à 90 minutes jusqu'à ce que le miroir soit prêt pour le basculement. L'instance de base de données connaît également une dégradation de performances de la même façon que lors d'une conversion du mode mono-AZ au mode multi-AZ. La durée pendant laquelle les performances sont dégradées dépend de la taille de stockage de base de données (plus la base de données stockée est grande, plus la dégradation est longue).
Pour plus d’informations sur les modèles de récupération SQL Server, consultez [Modes de récupération (SQL Server)](https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/recovery-models-sql-server) dans la documentation Microsoft.
# Détermination de l’heure du dernier basculement pour Amazon RDS for SQL Server
Pour déterminer l'heure du dernier basculement, utilisez la procédure stockée suivante :
```
execute msdb.dbo.rds_failover_time;
```
Cette procédure renvoie les informations suivantes.
****
| Paramètre de sortie | Description |
| --- | --- |
| errorlog\$1available\$1from | Affiche l'heure à partir de laquelle les journaux d'erreurs sont disponibles dans le répertoire des journaux. |
| recent\$1failover\$1time | Affiche l'heure du dernier basculement si elle est disponible à partir des journaux d'erreurs. Sinon, la valeur affichée est `null`. |
**Note**
La procédure stockée recherche l'heure de basculement la plus récente dans tous les journaux d'erreurs SQL Server disponibles dans le répertoire des journaux. Si les messages de basculement ont été remplacés par SQL Server, la procédure ne récupère pas l'heure de basculement.
**Example d'Aucun basculement récent**
Cet exemple illustre la sortie lorsqu'il n'y a pas de basculement récent dans les journaux d'erreurs. Aucun basculement ne s'est produit depuis le 29/04/2020 à 23:59:00.01.
| errorlog\$1available\$1from | recent\$1failover\$1time |
| --- | --- |
| 2020-04-29 23:59:00.0100000 | null |
**Example de Basculement récent**
Cet exemple illustre la sortie lorsqu'un basculement récent est détecté dans les journaux d'erreurs. Le basculement le plus récent a eu lieu le 05/05/2020 à 18:57:51.89.
| errorlog\$1available\$1from | recent\$1failover\$1time |
| --- | --- |
| 2020-04-29 23:59:00.0100000 | 2020-05-05 18:57:51.8900000 |
# Dépannage des échecs de reprise ponctuelle dus à un écart de numéro de séquence de journal
Lors d’une tentative de reprise ponctuelle (PITR) dans RDS for SQL Server, vous pouvez rencontrer des échecs en raison d’écarts de numéros de séquences de journal (LSN). Ces écarts empêchent RDS de restaurer votre base de données à l’heure demandée et RDS place l’instance de restauration à l’état `incompatible-restore`.
Causes courantes entraînant ce problème :
+ Modifications manuelles du modèle de récupération de base de données.
+ Le modèle de récupération automatique est modifié par RDS en raison de ressources insuffisantes pour effectuer les sauvegardes du journal des transactions.
Pour identifier les écarts de LSN dans la base de données, exécutez cette requête :
```
SELECT * FROM msdb.dbo.rds_fn_list_tlog_backup_metadata(database_name)
ORDER BY backup_file_time_utc desc;
```
Si vous découvrez un écart de LSN, vous pouvez :
+ Choisir un point de restauration avant l’écart de LSN.
+ Attendre et restaurer jusqu’à un point une fois la sauvegarde de l’instance suivante terminée.
Pour éviter ce problème, nous vous recommandons de ne pas modifier manuellement le modèle de restauration des bases de données RDS for SQL Server, car cela interrompt la durabilité de l’instance. Nous vous recommandons également de choisir un type d’instance doté de ressources suffisantes pour votre charge de travail afin de garantir des sauvegardes régulières du journal des transactions.
Pour plus d’informations sur la gestion des journaux de transactions, consultez [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) dans la documentation Microsoft SQL Server.
# Refus ou autorisation de l’affichage des noms de base de données pour Amazon RDS for SQL Server
L’utilisateur principal ne peut pas définir `DENY VIEW ANY DATABASE TO LOGIN` pour masquer les bases de données à un utilisateur.
Pour modifier cette autorisation, utilisez plutôt la procédure stockée suivante :
+ Refus de l’accès à la base de données à *LOGIN* :
```
EXEC msdb.dbo.rds_manage_view_db_permission @permission=‘DENY’, @server_principal=‘LOGIN’
go
```
+ Autorisation de l’accès à la base de données à *LOGIN* :
```
EXEC msdb.dbo.rds_manage_view_db_permission @permission='GRANT', @server_principal='LOGIN'
go
```
Tenez compte des éléments suivants lorsque vous utilisez cette procédure stockée :
+ Les noms des bases de données sont masqués dans le SSMS et dans les DMV (vues de gestion dynamique) internes. Cependant, les noms des bases de données sont toujours visibles dans les tables d’audit, les journaux et les tables de métadonnées. Il s’agit d’autorisations de serveur `VIEW ANY DATABASE` sécurisées. Pour plus d’informations, consultez [REFUSER autorisations du serveur](https://learn.microsoft.com/en-us/sql/t-sql/statements/deny-server-permissions-transact-sql?view=sql-server-ver16#permissions).
+ Une fois l’autorisation rétablie sur `GRANT` (autorisée), le *LOGIN* peut afficher toutes les bases de données.
+ Si vous supprimez et recréez le *LOGIN*, l’autorisation d’affichage associée au LOGIN est réinitialisée à `ALLOW`.
+ Pour les instances multi-AZ, définissez l’autorisation `GRANT` ou `DENY` uniquement pour le *LOGIN* sur l’hôte principal. Les modifications sont automatiquement répercutées sur l’hôte secondaire.
+ Cette autorisation change uniquement si un identifiant peut afficher les noms de base de données. Toutefois, l’accès aux bases de données et aux objets qu’elles contiennent est géré séparément.
# Désactivation des insertions rapides pendant le chargement en masse pour Amazon RDS for SQL Server
À partir de SQL Server 2016, les insertions rapides sont activées par défaut. Les insertions rapides tirent parti d'une journalisation minimale quand la base de données est en mode de récupération simple ou utilisant les journaux de transactions pour optimiser les performances d'insertion. Avec les insertions rapides, chaque lot de chargement en masse acquiert de nouvelles extensions en ignorant la recherche d'allocation des extensions existantes avec l'espace libre disponible pour optimiser les performances d'insertion.
Avec les insertions rapides, les chargements en masse de lots de petite taille peuvent aboutir à une plus grande quantité d'espace inutilisé consommée par les objets. S'il n'est pas possible d'augmenter la taille de lot, l'activation de cet indicateur de trace 692 peut contribuer à réduire l'espace réservé inutilisé, mais au détriment des performances. L’activation de cet indicateur de trace désactive les insertions rapides lors du chargement en masse de données dans un segment de mémoire ou un index cluster.
Vous activez l'indicateur de trace 692 en tant que paramètre de démarrage à l'aide de groupes de paramètres de base de données. Pour plus d’informations, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
L'indicateur de trace 692 est pris en charge pour Amazon RDS sur SQL Server 2016 et versions ultérieures. Pour plus d’informations sur les indicateurs de trace, consultez [DBCC TRACEON - Trace Flags](https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql) dans la documentation Microsoft.
# Suppression d’une base de données dans une instance de base de données Amazon RDS for Microsoft SQL Server
Vous pouvez supprimer la base de données d'une instance de base de données Amazon RDS exécutant Microsoft SQL Server dans un déploiement Multi-AZ ou à zone de disponibilité unique. Pour supprimer la base de données, utilisez la commande suivante :
```
--replace your-database-name with the name of the database you want to drop
EXECUTE msdb.dbo.rds_drop_database N'your-database-name'
```
**Note**
Utilisez des apostrophes droites dans la commande. Tout autre type de guillemet entraînera une erreur.
Après cette procédure de suppression de la base de données, Amazon RDS supprime toutes les connexions existantes à cette dernière, ainsi que son historique de sauvegarde.
Pour accorder une autorisation de sauvegarde et de restauration à d’autres utilisateurs, procédez comme suit :
```
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
```
# Modification du nom d’une base de données Amazon RDS for Microsoft SQL Server dans un déploiement multi-AZ
Pour renommer une instance de base de données Microsoft SQL Server qui utilise un déploiement Multi-AZ, procédez comme suit :
1. Commencez par désactiver Multi-AZ pour l'instance de base de données.
1. Renommez la base de données en exécutant `rdsadmin.dbo.rds_modify_db_name`.
1. Ensuite, activez la mise en miroir multi-AZ ou l'option Groupes de disponibilité AlwaysOn pour l'instance de base de données, afin de rétablir son état d'origine.
Pour plus d’informations, consultez [Ajout d'un déploiement multi-AZ à une instance de base de données Microsoft SQL Server](USER_SQLServerMultiAZ.md#USER_SQLServerMultiAZ.Adding).
**Note**
Si votre instance n'utilise pas le mode multi-AZ, vous n'avez pas besoin de modifier d'autres paramètres avant ou après l'exécution de `rdsadmin.dbo.rds_modify_db_name`.
Vous ne pouvez pas renommer une base de données sur une instance source de réplica en lecture.
**Exemple : **dans l'exemple suivant, la procédure stockée `rdsadmin.dbo.rds_modify_db_name` change le nom d'une base de données de **MOO** à **ZAR**. Cela revient à exécuter l'instruction `DDL ALTER DATABASE [MOO] MODIFY NAME = [ZAR]`.
```
EXEC rdsadmin.dbo.rds_modify_db_name N'MOO', N'ZAR'
GO
```
# Réinitialisation de l’appartenance au rôle db\$1owner pour Amazon RDS for SQL Server
Si vous empêchez l’utilisateur principal d’appartenir au rôle `db_owner` dans la base de données RDS for SQL Server et qu’aucun autre utilisateur de base de données ne peut accorder cette appartenance, vous pouvez rétablir l’appartenance perdue en modifiant le mot de passe de l’utilisateur principal de l’instance de base de données.
En modifiant le mot de passe de l’utilisateur principal de l’instance de base de données, RDS accorde l’appartenance à `db_owner` aux bases de données de l’instance de base de données susceptibles d’avoir été révoquées accidentellement. Vous pouvez modifier le mot de passe de l'instance de base de données à l'aide de la console Amazon RDS [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html), de la AWS CLI commande ou de l'opération [DBInstanceModify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API. Pour plus d’informations sur la modification d’une instance de base de données, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
# Restauration des instances de base de données résiliées faute de licence pour Amazon RDS for SQL Server
Microsoft a demandé que certains clients Amazon RDS n'ayant pas signalé leurs informations Microsoft License Mobility résilient leur instance de base de données. Amazon RDS prend des instantanés de ces instances de base de données, et vous pouvez restaurer à partir de l'instantané une nouvelle instance de base de données disposant du modèle License incluse.
Vous pouvez effectuer la restauration à partir d'un instantané de Standard Edition vers Standard Edition ou Enterprise Edition.
Vous pouvez effectuer la restauration à partir d'un instantané d'Enterprise Edition vers Standard Edition ou Enterprise Edition.
**Pour restaurer à partir d'un instantané SQL Server après que Amazon RDS a créé un instantané final de votre instance :**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Snapshots**.
1. Choisissez l'instantané de votre instance de base de données SQL Server. Amazon RDS crée un instantané final de votre instance de base de données. Le nom de l'instantané de l'instance terminée est au format `instance_name-final-snapshot`. Par exemple, si le nom de votre instance de base de données est**mytest.cdxgahslksma.us-east-1.rds.com**, le cliché final est appelé ** mytest-final-snapshot** et se trouve dans la même AWS région que l'instance de base de données d'origine.
1. Pour **Actions**, choisissez **Restore Snapshot (Restaurer l'instantané)**.
La fenêtre **Restore DB Instance (Restituer l'instance de base de données)** s'affiche.
1. Pour **Modèle de licence**, sélectionnez **licence incluse**.
1. Sélectionnez le moteur de base de données SQL Server que vous voulez utiliser.
1. Pour **DB Instance Identifier (Identifiant d'instance DB)**, entrez le nom de l'instance de base de données restaurée.
1. Choisissez **Restore DB Instance**.
Pour plus d'informations sur la restauration à partir d'un instantané, consultez [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md).
# Passage d’une base de données Amazon RDS for SQL Server de l’état OFFLINE à l’état ONLINE
Vous pouvez faire passer votre base de données Microsoft SQL Server sur une instance de base de données Amazon RDS de l'état `OFFLINE` à l'état `ONLINE`.
****
| Méthode SQL Server | Méthode Amazon RDS |
| --- | --- |
| MODIFIER LA BASE DE DONNÉES *db\$1name* MISE EN LIGNE ; | EXÉCUTEZ rdsadmin.dbo.rds\$1set\$1database\$1online *db\$1name* |
# Utilisation de la capture des données de modification pour Amazon RDS for SQL Server
Amazon RDS prend en charge la capture de données modifiées (CDC) pour vos instances de base de données s'exécutant sur Microsoft SQL Server. CDC capture les modifications apportées aux données de vos tables. CDC stocke les métadonnées relatives à chaque modification et vous pouvez y accéder ultérieurement. Pour plus d'informations sur le fonctionnement de CDC, consultez [Capture de données modifiées](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/track-data-changes-sql-server#Capture) dans la documentation Microsoft. Pour utiliser la fonction CDC avec vos instances de base de données Amazon RDS, vous devez tout d'abord l'activer au niveau de la base de données en exécutant `msdb.dbo.rds_cdc_enable_db`. Une fois la fonction CDC activée, tout utilisateur `db_owner` de cette base de données peut activer ou désactiver CDC sur les tables de cette base de données.
**Important**
Pendant les restaurations, la fonction CDC est désactivée. L'ensemble des métadonnées associées est automatiquement supprimé de la base de données. Cela s'applique aux restaurations de snapshots et aux point-in-time restaurations. Après avoir exécuté l'un de ces types de restaurations, vous pouvez réactiver CDC et respécifier les tables à suivre.
Pour activer CDC pour une instance de base de données, exécutez la procédure stockée `msdb.dbo.rds_cdc_enable_db`.
```
1. exec msdb.dbo.rds_cdc_enable_db 'database_name'
```
Pour désactiver CDC pour une instance de base de données, exécutez la procédure stockée `msdb.dbo.rds_cdc_disable_db`.
```
1. exec msdb.dbo.rds_cdc_disable_db 'database_name'
```
Pour accorder les autorisations CDC, utilisez la procédure suivante :
```
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**
+ [Suivi des tables avec CDC](#Appendix.SQLServer.CommonDBATasks.CDC.tables)
+ [Tâches CDC](#Appendix.SQLServer.CommonDBATasks.CDC.jobs)
+ [Capture de données modifiées (CDC) pour les instances multi-AZ](#Appendix.SQLServer.CommonDBATasks.CDC.Multi-AZ)
## Suivi des tables avec CDC
Une fois que CDC est activé sur la base de données, vous pouvez démarrer le suivi de tables spécifiques. Vous pouvez choisir les tableaux à suivre en exécutant [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. ;
```
Pour afficher la configuration CDC de vos tableaux, exécutez [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).
```
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. ;
```
Pour plus d'informations sur les tables, fonctions et procédures stockées CDC dans la documentation SQL Server, consultez les rubriques suivantes :
+ [Procédures stockées CDC (Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/change-data-capture-stored-procedures-transact-sql)
+ [Fonctions CDC (Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-functions/change-data-capture-functions-transact-sql)
+ [Tableaux CDC (Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-tables/change-data-capture-tables-transact-sql)
## Tâches CDC
Quand vous activez CDC, SQL Server crée les tâches CDC. Les propriétaires de base de données (`db_owner`) peuvent afficher, créer, modifier et supprimer les tâches CDC. Cependant, le compte système RDS en est propriétaire. Par conséquent, les tâches ne sont pas visibles des vues natives, des procédures ou de SQL Server Management Studio.
Pour contrôler le comportement de CDC dans une base de données, utilisez les procédures SQL Server natives telles que [sp\$1cdc\$1enable\$1table](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-enable-table-transact-sql) et [sp\$1cdc\$1start\$1job ](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-start-job-transact-sql). Pour modifier les paramètres des tâches CDC, comme `maxtrans` et `maxscans`, vous pouvez utiliser [sp\$1cdc\$1change\$1job.](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-change-job-transact-sql).
Pour obtenir plus d'informations sur les tâches CDC, vous pouvez interroger les vues de gestion dynamiques suivantes :
+ sys.dm\$1cdc\$1errors
+ sys.dm\$1cdc\$1log\$1scan\$1sessions
+ sysjobs
+ sysjobhistory
## Capture de données modifiées (CDC) pour les instances multi-AZ
Si vous utilisez CDC sur une instance multi-AZ, assurez-vous que la configuration de la tâche CDC du miroir correspond à celle du mandataire. Les tâches CDC sont mappées au `database_id`. Si la IDs base de données secondaire est différente de la base de données principale, les tâches ne seront pas associées à la base de données appropriée. Pour éviter toute erreur après le basculement, RDS supprimer et recrée les tâches sur le nouveau mandataire. Les tâches recréées utilisent les paramètres que le mandataire a enregistrés avant le basculement.
Même si ce processus s'exécute rapidement, il est toujours possible que les tâches CDC puissent s'exécuter avant que RDS puisse les corriger. Voici trois moyens de contraindre les paramètres à être cohérents entre les réplicas principaux et secondaires :
+ Utilisez les mêmes paramètres de tâche pour toutes les bases de données pour lesquelles CDC est activé.
+ Avant de modifier la configuration des tâches CDC, convertissez l'instance multi-AZ en mono-AZ.
+ Transférez manuellement les paramètres chaque fois que vous les modifiez sur le principal.
Pour afficher et définir les paramètres CDC utilisés pour recréer les tâches CDC après un basculement, utilisez `rds_show_configuration` et `rds_set_configuration`.
L'exemple suivant renvoie la valeur définie pour `cdc_capture_maxtrans`. Pour tout paramètre défini sur `RDS_DEFAULT`, RDS configure automatiquement la valeur.
```
-- Show configuration for each parameter on either primary and secondary replicas.
exec rdsadmin.dbo.rds_show_configuration 'cdc_capture_maxtrans';
```
Pour définir la configuration sur le réplica secondaire, exécutez `rdsadmin.dbo.rds_set_configuration`. Cette procédure définit les valeurs de paramètre pour toutes les bases de données du serveur secondaire. Ces paramètres ne sont utilisés qu'après un basculement. L'exemple suivant définit `maxtrans` pour toutes les tâches de capture CDC la valeur suivante *1000* :
```
--To set values on secondary. These are used after failover.
exec rdsadmin.dbo.rds_set_configuration 'cdc_capture_maxtrans', 1000;
```
Pour définir les paramètres de tâche CDC sur le principal, utilisez plutôt [sys.sp\$1cdc\$1change\$1job](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-change-job-transact-sql).
# Utilisation de SQL Server Agent pour Amazon RDS
Avec Amazon RDS, vous pouvez utiliser SQL Server Agent sur une instance de base de données exécutant Microsoft SQL Server Enterprise Edition, Standard Edition ou Web Edition. SQL Server Agent est un service Microsoft Windows qui exécute des tâches administratives planifiées, appelées travaux. Vous pouvez utiliser SQL Server Agent pour exécuter les travaux T-SQL jobs afin de reconstruire les index, d'exécuter les contrôles de corruption et de regrouper les données dans une instance de base de données SQL Server.
Lorsque vous créez une instance de base de données SQL Server, l'utilisateur principal est inscrit dans le rôle `SQLAgentUserRole`.
SQL Server Agent peut exécuter un travail en fonction d'une planification, en réponse à un événement spécifique, ou à la demande. Pour plus d'informations, consultez [SQL Server Agent](http://msdn.microsoft.com/en-us/library/ms189237) dans la documentation Microsoft.
**Note**
Évitez de planifier l'exécution de travaux pendant les fenêtres de maintenance et de sauvegarde de votre instance de base de données. Les processus de maintenance et de sauvegarde lancés par AWS peuvent interrompre un travail ou entraîner son annulation.
Dans les déploiements Multi-AZ, les tâches de l’agent SQL Server sont répliquées de l’hôte principal vers l’hôte secondaire lorsque la fonction de réplication des tâches est activée. Pour plus d’informations, consultez [Activation de la réplication des tâches de l'agent SQL Server](#SQLServerAgent.Replicate).
Les déploiements multi-AZ sont limités à 10 000 tâches SQL Server Agent. Si une limite plus élevée est nécessaire, demandez une augmentation en contactant le Support. Ouvrez la page du [Centre AWS Support](https://console.aws.amazon.com/support/home#/), connectez-vous si nécessaire, puis choisissez **Create case (Créer une demande de support)**. Sélectionnez **Service Limit increase (Augmentation des limites de service)**. Remplissez et envoyez le formulaire.
Pour afficher l'historique d'un travail SQL Server Agent dans SQL Server Management Studio (SSMS), ouvrez l'Explorateur d'objet, cliquez avec le bouton droit sur le travail, puis cliquez sur **View History (Afficher l'historique)**.
Étant donné que SQL Server Agent est exécuté sur un hôte géré dans une instance de base de données, certaines actions ne sont pas prises en charge :
+ L'exécution de travaux de réplication et de scripts de ligne de commande à l'aide d'ActiveX, du shell de commande Windows ou de Windows PowerShell n'est pas prise en charge.
+ Vous ne pouvez pas démarrer, arrêter ou redémarrer manuellement SQL Server Agent.
+ Les notifications par e-mail via SQL Server Agent ne sont pas disponibles à partir d'une instance de base de données.
+ Les alertes et les opérateurs SQL Server Agent ne sont pas pris en charge.
+ L'utilisation de SQL Server Agent pour créer des sauvegardes n'est pas prise en charge. Utilisez Amazon RDS for sauvegarder votre instance de base de données.
+ RDS for SQL Server ne prend pas en charge actuellement l’utilisation de jetons SQL Server Agent.
## Activation de la réplication des tâches de l'agent SQL Server
Vous pouvez activer la réplication des tâches de l'agent SQL Server à l'aide de la procédure stockée suivante :
```
EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'SQLAgentJob';
```
Vous pouvez exécuter la procédure stockée sur toutes les versions de SQL Server prises en charge par Amazon RDS for SQL Server. Les tâches des catégories suivantes sont répliquées :
+ [Uncategorized (Local)] ([Non classé (local)])
+ [Uncategorized (Multi-Server)] ([Non classé (multi-serveurs)])
+ [Uncategorized] ([Non classé])
+ Data Collector (Collecteur de données)
+ Database Engine Tuning Advisor (Assistant Paramétrage du moteur de base de données)
+ Database Maintenance (Maintenance de base de données)
+ Full-Text (Texte intégral)
Seules les tâches qui utilisent des étapes de travail T-SQL sont répliquées. Les tâches comportant des types d'étapes tels que SQL Server Integration Services (SSIS), SQL Server Reporting Services (SSRS), Replication et PowerShell ne sont pas répliquées. Les tâches qui utilisent Database Mail (Messagerie de base de données) et les objets au niveau du serveur ne sont pas répliquées.
**Important**
L'hôte principal est la source de vérité pour la réplication. Avant d'activer la réplication des tâches, assurez-vous que vos tâches SQL Server Agent se trouvent sur l'hôte principal. Si vous ne le faites pas, cela pourrait entraîner la suppression de vos tâches SQL Server Agent si vous activez la fonctionnalité lorsque des tâches plus récentes se trouvent sur l'hôte secondaire.
Vous pouvez utiliser la fonction suivante pour confirmer si la réplication est activée.
```
SELECT * from msdb.dbo.rds_fn_get_system_database_sync_objects();
```
La requête T-SQL renvoie le résultat suivant si les tâches de l'agent SQL Server sont répliquées. Si elles ne se répliquent pas, la requête ne renvoie rien pour `object_class`.
![\[Les tâches de l'agent SQL Server sont répliquées.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/SQLAgentJob.png)
Vous pouvez utiliser la fonction suivante pour trouver la dernière synchronisation des objets selon le fuseau horaire UTC.
```
SELECT * from msdb.dbo.rds_fn_server_object_last_sync_time();
```
Par exemple, supposons que vous modifiez une tâche de l'agent du serveur SQL à 01:00. Vous vous attendez à ce que l'heure de synchronisation la plus récente soit postérieure à 01:00, indiquant que la synchronisation a eu lieu.
Après la synchronisation, les valeurs renvoyées pour `date_created` et `date_modified` sur le nœud secondaire doivent correspondre.
![\[La dernière fois que les objets du serveur ont été synchronisés était à 01:21:23\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/SQLAgentJob_last_sync_time.png)
Si vous utilisez également la réplication `tempdb`, vous pouvez activer la réplication à la fois pour les tâches SQL Agent et pour la configuration `tempdb` en les fournissant dans le paramètre `@object_type` :
```
EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'SQLAgentJob,TempDbFile';
```
Pour plus d’informations sur la réplication `tempdb`, consultez [Configuration de TempDB pour les déploiements multi-AZ](SQLServer.TempDB.MAZ.md).
# Rôles SQL Server Agent
RDS for SQL Server prend en charge les rôles SQL Server Agent suivants avec différents niveaux d’autorisation pour la gestion des tâches :
+ **SQLAgentUserRole**
Autorisations
+ Créer et gérer leurs propres tâches, planifications et opérateurs
+ Afficher les propriétés de leurs propres tâches et planifications
+ Impossible d’afficher ou de gérer les tâches créées par d’autres utilisateurs
Ce rôle convient aux utilisateurs qui doivent créer et gérer leurs propres tâches, mais qui n’ont pas besoin d’accéder à celles créées par d’autres utilisateurs.
+ **SQLAgentReaderRole**
Autorisations
+ Toutes les autorisations de SQLAgentUserRole
+ Afficher la liste de toutes les tâches et planifications, y compris celles créées par d’autres
+ Afficher les propriétés de toutes les tâches
+ Consulter l’historique des tâches
Ce rôle convient aux utilisateurs qui ont besoin de surveiller l’état de toutes les tâches, mais qui n’ont pas besoin de les gérer.
+ **SQLAgentOperatorRole**
Autorisations
+ Toutes les autorisations de SQLAgentUserRole et de SQLAgentReaderRole
+ Exécuter, arrêter ou démarrer des tâches
+ Gérer l’historique des tâches
+ Activer/désactiver les tâches et les planifications
+ Afficher les opérateurs et les proxys
Ce rôle fournit les autorisations les plus complètes et convient aux utilisateurs qui ont besoin d’un contrôle total sur toutes les tâches.
Exécutez la commande suivante pour attribuer les rôles à votre identifiant SQL Server :
```
USE msdb;
EXEC sp_addrolemember 'SQLAgentOperatorRole', 'username';
```
## Gestion de SQLAgentOperatorRole dans RDS for SQL Server
Pour afficher les tâches en cours, vous devez ajouter le rôle SQLAgentOperatorRole à votre identifiant SQL Server et le supprimer avant de vous déconnecter de votre base de données.
Pour visualiser l’arborescence de SQL Server Agent dans SQL Server Management Studio, suivez les instructions suivantes :
**Afficher SQL Server Agent sur SQL Server Management Studio (SSMS)**
1. À l’aide des informations d’identification principales RDS, connectez-vous à l’instance RDS SQL Server et attribuez le rôle SQLAgentUserRole à l’utilisateur souhaité.
```
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
```
Ces commandes créent l’utilisateur dans la base de données `msdb`, dans le cas où elle n’existerait pas. Elles ajoutent également l’utilisateur au rôle SQLAgentUserRole, de sorte que l’arborescence SQL Server Agent sur SSMS soit visible. Enfin, elles accordent à l’utilisateur des autorisations de modification sur le rôle SQLAgentOperatorRole. Cela permet à l’utilisateur de s’ajouter/de se supprimer lui-même pour ce rôle.
1. Pour vous ajouter au rôle mentionné ci-dessus, connectez-vous à l’instance RDS SQL Server, avec l’utilisateur qui a besoin de voir les tâches, et exécutez le script suivant.
```
use msdb
go
ALTER ROLE SQLAgentOperatorRole ADD MEMBER UserName
GO
```
Ensuite, cliquez avec le bouton droit sur le dossier **Tâches**, puis choisissez **Actualiser**.
1. Lorsque vous effectuez cette action, l’onglet **Tâches** affiche un bouton **\$1** (plus). Cliquez pour développer la liste des tâches SQL Server Agent.
1.
**Important**
Avant de vous déconnecter de l’instance RDS SQL Server, vous devez vous retirer du rôle SQLAgentOperatorRole.
Pour supprimer votre connexion au rôle SQLAgentOperatorRole, exécutez la requête suivante avant de vous déconnecter ou de fermer le Management Studio :
```
USE msdb
GO
ALTER ROLE SQLAgentOperatorRole DROP MEMBER UserName
GO
```
Pour plus d’informations, consultez [Utilisation du rôle SQLAgentOperatorRole dans RDS SQL Server](https://aws.amazon.com/blogs/database/leveraging-sqlagentoperatorrole-in-rds-sql-server/).
# Ajout d'un utilisateur au rôle SQLAgentUser
Pour ajouter un utilisateur/une connexion supplémentaire afin d'utiliser SQL Server Agent, connectez-vous en tant qu'utilisateur principal et exécutez les actions suivantes :
1. Créez une autre connexion de niveau serveur à l'aide de la commande `CREATE LOGIN`.
1. Créez un utilisateur dans `msdb` avec la commande `CREATE USER` puis liez cet utilisateur à la connexion que vous avez créée à l'étape précédente.
1. Ajoutez l'utilisateur à la procédure `SQLAgentUserRole` à l'aide de la procédure stockée système `sp_addrolemember`.
Par exemple, supposons que votre identifiant principal soit **admin** et que vous souhaitez accorder l'accès à SQL Server Agent à un utilisateur nommé **theirname** avec le mot de passe **theirpassword**. Dans ce cas, vous pouvez utiliser la procédure suivante.
**Pour ajouter un utilisateur au rôle SQLAgentUser**
1. Connectez-vous en tant qu'utilisateur principal.
1. Exécutez les commandes suivantes :
```
--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];
```
# Suppression d'une tâche SQL Server Agent
Vous utilisez la procédure stockée `sp_delete_job` pour supprimer les travaux de l’agent SQL Server sur Amazon RDS for Microsoft SQL Server.
Vous ne pouvez pas utiliser SSMS pour supprimer des travaux de l'agent SQL Server Agent. Si vous le faites, vous obtenez un message d'erreur similaire au suivant :
```
The EXECUTE permission was denied on the object 'xp_regread', database 'mssqlsystemresource', schema 'sys'.
```
Cette erreur survient parce que, en tant que service géré, RDS est empêché d'exécuter les procédures qui accèdent au registre Windows. Lorsque vous utilisez SSMS, celui-ci tente d'exécuter un processus (`xp_regread`) pour lequel RDS n'est pas autorisé.
**Note**
Sur RDS for SQL Server, seuls les membres du rôle d'administrateur système sont autorisés à mettre à jour ou à supprimer des tâches appartenant à un identifiant de connexion différent. Pour plus d’informations, consultez [Utilisation du rôle SQLAgentOperatorRole dans RDS SQL Server](https://aws.amazon.com/blogs/database/leveraging-sqlagentoperatorrole-in-rds-sql-server/).
**Pour supprimer un travail SQL Server Agent**
+ Exécutez l'instruction T-SQL suivante :
```
EXEC msdb..sp_delete_job @job_name = 'job_name';
```
# Utilisation des journaux Amazon RDS for Microsoft SQL Server
Vous pouvez utiliser la console Amazon RDS for afficher, consulter et télécharger les journaux SQL Server Agent, les journaux d'erreurs Microsoft SQL Server et les journaux SQL Server Reporting Services (SSRS).
## Consultation des fichiers journaux
Si vous affichez un journal dans la console Amazon RDS, vous pouvez voir son contenu tel qu'il est à ce moment-là. L'observation d'un journal dans la console l'ouvre dans un état dynamique de telle sorte que vous puissiez voir ses mises à jour pratiquement en temps réel.
Seul le dernier journal est actif pour pouvoir être observé. Par exemple, supposons que les journaux affichent les informations suivantes :
![\[Image de la section Journaux de la console Amazon RDS avec un journal d’erreurs sélectionné.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/logs_sqlserver.png)
Seul log/ERROR, comme le journal le plus récent est en mise à jour active. Vous pouvez choisir d'en observer d'autres, mais ils sont statiques et ne sont pas mis à jour.
## Archivage des fichiers journaux
La console Amazon RDS affiche les journaux de la semaine écoulée jusqu'au même. Vous pouvez télécharger et archiver les journaux pour les garder comme référence au-delà de cette date. Une solution pour archiver les journaux consiste à les charger dans un compartiment Amazon S3. Pour savoir comment configurer un compartiment Amazon S3 et comment charger un fichier, consultez [Bases Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AmazonS3Basics.html) dans le *Guide de démarrage Amazon Simple Storage Service*, puis cliquez sur **Mise en route**.
## Affichage des journaux des erreurs et des agents
Pour consulter les journaux des erreurs et de l'agent Microsoft SQL Server, utilisez la procédure stockée Amazon RDS `rds_read_error_log` avec les paramètres suivants :
+ **`@index`** – version du journal à récupérer. La valeur par défaut est 0, qui permet de récupérer le journal des erreurs actuel. Spécifiez 1 pour récupérer le journal précédent, spécifiez 2 pour récupérer celui d'avant, et ainsi de suite.
+ **`@type`** – type de journal à récupérer. Spécifiez 1 pour récupérer un journal des erreurs. Spécifiez 2 pour récupérer un journal de l'agent.
**Example**
L'exemple suivant demande le journal des erreurs actuel.
```
EXEC rdsadmin.dbo.rds_read_error_log @index = 0, @type = 1;
```
Pour plus d'informations sur les erreurs SQL Server, consultez la section [Erreurs du moteur de base de données](https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-events-and-errors) dans la documentation Microsoft.
# Utilisation des fichiers de trace et de vidage pour Amazon RDS for SQL Server
Cette section décrit l'utilisation des fichiers de trace et des fichiers de vidage pour vos instances de base de données Amazon RDS exécutant Microsoft SQL Server.
## Génération d'une requête de trace SQL
```
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
```
## Affichage d'une trace ouverte
```
1. select * from ::fn_trace_getinfo(default)
```
## Affichage du contenu d'une trace
```
1. select * from ::fn_trace_gettable('D:\rdsdbdata\log\rdstest.trc', default)
```
## Configuration de la période de rétention pour les fichiers de trace et de vidage
Les fichiers de trace et de vidage peuvent s'accumuler et consommer de l'espace sur le disque. Par défaut, Amazon RDS purge les fichiers de trace et de vidage de plus de sept jours.
Pour consulter la période actuelle de rétention des fichiers de trace et de vidage, utilisez la procédure `rds_show_configuration`, comme illustré dans l'exemple suivant.
```
1. exec rdsadmin..rds_show_configuration;
```
Pour modifier la période de rétention des fichiers de trace, utilisez la procédure `rds_set_configuration` et définissez `tracefile retention` en minutes. L'exemple ci-dessous définit la période de rétention des fichiers de trace à 24 heures.
```
1. exec rdsadmin..rds_set_configuration 'tracefile retention', 1440;
```
Pour modifier la période de rétention des fichiers de vidage, utilisez la procédure `rds_set_configuration` et définissez `dumpfile retention` en minutes. L'exemple ci-dessous définit la période de rétention des fichiers de vidage à 3 jours.
```
1. exec rdsadmin..rds_set_configuration 'dumpfile retention', 4320;
```
Pour des raisons de sécurité, vous ne pouvez pas supprimer un fichier de trace ou de vidage spécifique sur une instance de base de données SQL Server. Pour supprimer tous les fichiers de trace ou de vidage inutilisés, définissez la période de rétention des fichiers à 0.