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.

# Limites, remarques et recommandations relatives au Multi-AZ déploiement de Microsoft SQL Server
<a name="USER_SQLServerMultiAZ.Recommendations"></a>

Voici certaines limites liées à l'utilisation de Multi-AZ déploiements sur RDS pour les instances de base de données SQL Server :
+ Cross-Region Multi-AZ n'est pas pris en charge.
+ L'arrêt d'une instance de base de données RDS for SQL Server dans un déploiement multi-AZ n'est pas pris en charge.
+ Vous ne pouvez pas configurer l'instance de base de données secondaire pour accepter l'activité de lecture de base de données.
+ Multi-AZ avec Always On Availability Groups (AG) prend en charge l'optimisation en mémoire.
+ Multi-AZ with Always On Availability Groups (AG) ne prend pas en charge l'authentification Kerberos pour l'écouteur des groupes de disponibilité. En effet, l'écouteur ne possède pas de nom de principal de service (SPN).
+ Multi-AZ avec réplication au niveau des blocs n'est actuellement prise en charge que pour les instances de SQL Server Web Edition.
+ Vous ne pouvez pas renommer une base de données sur une instance de base de données SQL Server faisant partie d'un Multi-AZ déploiement SQL Server. Si vous devez renommer une base de données sur une telle instance, désactivez d'abord l'instance de base Multi-AZ de données, puis renommez la base de données. Enfin, Multi-AZ réactivez l'instance de base de données. 
+ Vous ne pouvez restaurer que les Multi-AZ instances de base de données sauvegardées à l'aide du modèle de restauration complète.
+ Multi-AZ les déploiements sont limités à 10 000 tâches SQL Server Agent.

  Si vous avez besoin d'une limite plus élevée, demandez une augmentation en contactant 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.
+ Vous ne pouvez pas avoir de base de données hors ligne sur une instance de base de données SQL Server qui est déployée dans le cadre d'un Multi-AZ déploiement SQL Server.
+ RDS for SQL Server ne réplique pas les autorisations de base de données MSDB sur l’instance secondaire. Si vous avez besoin de ces autorisations sur l’instance secondaire, vous devez les recréer manuellement.
+ Les métriques de volume ne sont pas disponibles pour l'hôte secondaire de l'instance utilisant la réplication au niveau des blocs.

Voici quelques remarques concernant l'utilisation des Multi-AZ déploiements sur RDS pour les instances de base de données SQL Server :
+ Amazon RDS expose le [point de terminaison de l'écouteur des groupes de disponibilité](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover) Always On. Le point de terminaison est visible dans la console et est renvoyé par l'opération d'API `DescribeDBInstances` en tant qu'entrée dans le champ des points de terminaison.
+ Amazon RDS prend en charge les [basculements à plusieurs sous-réseaux du groupe de disponibilité](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover).
+ Pour utiliser SQL Server Multi-AZ avec une instance de base de données SQL Server dans un cloud privé virtuel (VPC), créez d'abord un groupe de sous-réseaux de base de données comportant des sous-réseaux dans au moins deux zones de disponibilité distinctes. Affectez ensuite le groupe de sous-réseaux de base de données au réplica principal de l'instance de base de données SQL Server. 
+ Lorsqu'une instance de base de données est modifiée pour être un Multi-AZ déploiement, elle a le statut de modification pendant la **modification**. Amazon RDS crée l'instance de secours et effectue une sauvegarde de l'instance de base de données principale. Une fois le processus terminé, le statut de l'instance de base de données principale devient **disponible**.
+ Multi-AZ les déploiements maintiennent toutes les bases de données sur le même nœud. Si une base de données sur l'hôte principal bascule, toutes vos bases de données SQL Server basculent en tant qu'unité atomique vers votre hôte de secours. Amazon RDS approvisionne un nouvel hôte sain et remplace l'hôte non sain.
+ Multi-AZ avec DBM, AG ou la réplication au niveau des blocs prend en charge une seule réplique de secours.
+ Les utilisateurs, les ID de connexion et les autorisations sont automatiquement répliqués pour vous sur l'instance secondaire. Vous n'avez pas besoin de les recréer. User-defined les rôles de serveur sont répliqués dans des instances de base de données qui utilisent des AG Always On ou une réplication au niveau des blocs pour les Multi-AZ déploiements. 
+ Lors Multi-AZ des déploiements, RDS for SQL Server crée des connexions SQL Server pour autoriser les AG Always On ou la mise en miroir de bases de données. RDS crée une connexion avec le modèle suivant, `db_<dbiResourceId>_node1_login`, `db_<dbiResourceId>_node2_login` et `db_<dbiResourceId>_witness_login`.
+ RDS for SQL Server crée un identifiant SQL Server pour autoriser l’accès aux réplicas en lecture. RDS crée une connexion avec le modèle suivant, `db_<readreplica_dbiResourceId>_node_login`.
+ Lors Multi-AZ des déploiements, les tâches de l'agent SQL Server sont répliquées de l'hôte principal vers l'hôte secondaire lorsque la fonctionnalité de réplication des tâches est activée. Pour de plus amples informations, veuillez consulter [Activation de la réplication des tâches de l'agent SQL Server](Appendix.SQLServer.CommonDBATasks.Agent.md#SQLServerAgent.Replicate).
+ Il est possible que vous observiez des temps de latence élevés par rapport à un déploiement d'instance de base de données standard (dans une zone de disponibilité unique) en raison de la réplication synchrone des données.
+ Les délais de basculement sont affectés par le temps nécessaire à la réalisation du processus de récupération. Le délai de basculement est allongé pour les transactions de volume important.
+ Dans les Multi-AZ déploiements de SQL Server, le redémarrage avec basculement redémarre uniquement l'instance de base de données principale. Après le basculement, l'instance de base de données principale devient la nouvelle instance de base de données secondaire. Les paramètres peuvent ne pas être mis à jour pour Multi-AZ les instances. Pour le redémarrage sans basculement, les instances de base de données principale et secondaire redémarrent, et les paramètres sont mis à jour après le redémarrage. Si l'instance de base de données ne répond pas, nous vous recommandons de procéder à un redémarrage sans basculement.

Voici quelques recommandations relatives à l'utilisation des Multi-AZ déploiements sur RDS pour les instances de base de données Microsoft SQL Server :
+ Pour les bases de données utilisées en production ou préproduction, nous vous recommandons les options suivantes :
  + Multi-AZ déploiements pour une haute disponibilité
  + IOPS provisionnés pour des performances rapides et cohérentes
  + « Mémoire optimisée » plutôt que « Usage général »
+ Vous ne pouvez pas sélectionner la zone de disponibilité (AZ) pour l'instance secondaire. Tenez-en compte lorsque vous déployez les hôtes d'application. Votre base de données peut basculer vers une autre zone de disponibilité et les hôtes d'application peuvent ne pas se trouver dans la même zone de disponibilité que la base de données. Pour cette raison, nous vous recommandons d'équilibrer les hôtes de vos applications entre toutes les zones de disponibilité de la AWS région donnée.
+ Pour de meilleures performances, n'activez pas la mise en miroir de bases de données, les AG Always On ou la réplication au niveau des blocs lors d'une opération de chargement de données importante. Si vous souhaitez que le chargement des données soit aussi rapide que possible, terminez le chargement des données avant de convertir votre instance de base de données en Multi-AZ déploiement. 
+ Les applications qui ont accès aux bases de données SQL Server doit disposer d'une gestion des exceptions qui identifie les erreurs de connexion. L'exemple de code suivant montre un try/catch bloc qui détecte une erreur de communication. Dans cet exemple, l'instruction `break` quitte la boucle `while` si la connexion réussit, mais relance jusqu'à 10 tentatives si une exception est déclenchée.

  ```
  int RetryMaxAttempts = 10;
  int RetryIntervalPeriodInSeconds = 1;
  int iRetryCount = 0;
  while (iRetryCount < RetryMaxAttempts)
  {
     using (SqlConnection connection = new SqlConnection(DatabaseConnString))
     {
        using (SqlCommand command = connection.CreateCommand())
        {
           command.CommandText = "INSERT INTO SOME_TABLE VALUES ('SomeValue');";
           try
           {
              connection.Open();
              command.ExecuteNonQuery();
              break;
           }
           catch (Exception ex) 
           {
              Logger(ex.Message);
              iRetryCount++;
           }
           finally {
              connection.Close();
           }
        }
     }
     Thread.Sleep(RetryIntervalPeriodInSeconds * 1000);
  }
  ```
+ N'utilisez pas la `Set Partner Off` commande lorsque vous travaillez avec des Multi-AZ instances utilisant DBM ou AG. Cette commande n'est pas prise en charge sur les instances utilisant la réplication au niveau des blocs. Par exemple, n'effectuez pas les opérations suivantes : 

  ```
  --Don't do this
  ALTER DATABASE db1 SET PARTNER off
  ```
+ Ne définissez pas le mode de récupération sur `simple`. Par exemple, n'effectuez pas les opérations suivantes : 

  ```
  --Don't do this
  ALTER DATABASE db1 SET RECOVERY simple
  ```
+ N'utilisez pas le `DEFAULT_DATABASE` paramètre lors de la création de nouvelles connexions sur des Multi-AZ instances de base de données, sauf si vous utilisez la réplication au niveau des blocs pour une haute disponibilité, car ces paramètres ne peuvent pas être appliqués au miroir de secours. Par exemple, n'effectuez pas les opérations suivantes : 

  ```
  --Don't do this
  CREATE LOGIN [test_dba] WITH PASSWORD=foo, DEFAULT_DATABASE=[db2]
  ```

  En outre, n'effectuez pas les opérations suivantes :

  ```
  --Don't do this
  ALTER LOGIN [test_dba] WITH DEFAULT_DATABASE=[db3]
  ```