Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S'applique à :SQL Server
Remarque
Cette fonctionnalité sera supprimée dans une version future de SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité. Utilisez Groupes de disponibilité Always On à la place.
Contrôle la mise en miroir d'une base de données. Les valeurs spécifiées avec les options de mise en miroir de bases de données s'appliquent aux deux copies de la base de données et à l'ensemble de la session de mise en miroir de bases de données. Une <seule database_mirroring_option> est autorisée par ALTER DATABASE déclaration.
Remarque
Nous vous recommandons de configurer la mise en miroir de la base de données pendant les heures creuses car l’opération de configuration peut avoir une incidence sur les performances.
Pour les ALTER DATABASE options, voir ALTER DATABASE. Pour les ALTER DATABASE SET options, voir ALTER DATABASE SET Options.
Conventions de la syntaxe Transact-SQL
Syntaxe
ALTER DATABASE database_name
SET { <partner_option> | <witness_option> }
<partner_option> ::=
PARTNER { = 'partner_server'
| FAILOVER
| FORCE_SERVICE_ALLOW_DATA_LOSS
| OFF
| RESUME
| SAFETY { FULL | OFF }
| SUSPEND
| TIMEOUT integer
}
<witness_option> ::=
WITNESS { = 'witness_server'
| OFF
}
Arguments
Important
Une SET commande PARTENAIRE ou SET TÉMOIN peut s’exécuter avec succès une fois saisie, mais échouer plus tard.
Remarque
ALTER DATABASE Les options de miroir de base de données ne sont pas disponibles pour une base de données contenue.
database_name Spécifie le nom de la base de données à modifier.
PARTNER <partner_option> contrôle les propriétés de base de données qui définissent les partenaires de basculement d’une session de mise en miroir de bases de données ainsi que leur comportement. Certaines SET options PARTENAIRE peuvent être activées sur l’un ou l’autre partenaire ; d’autres sont limitées au serveur principal ou au serveur miroir. Pour plus d'informations, consultez les options PARTNER individuelles décrites ci-dessous. Une SET clause PARTENAIRE affecte les deux copies de la base de données, quel que soit le partenaire sur lequel elle est spécifiée.
Pour exécuter une SET instruction PARTNER, l’ÉTAT des points de terminaison des deux partenaires doit être défini sur STARTED. Notez également que le ROLE point d’extrémité de miroir de chaque instance serveur partenaire doit être défini soit PARTNER, soit ALL. Pour plus d’informations sur la façon de spécifier un point de terminaison, consultez Créer un point de terminaison de mise en miroir de bases de données pour l’authentification Windows. Pour connaître le rôle et l'état du point de terminaison de mise en miroir de bases de données d'une instance de serveur, utilisez l'instruction Transact-SQL suivante sur cette instance :
SELECT role_desc, state_desc FROM sys.database_mirroring_endpoints
<partner_option> ::=
Remarque
Un <seul partner_option> est autorisé selon SET la clause PARTNER.
'partner_server' Spécifie l’adresse réseau du serveur d’une instance de SQL Server pour agir en tant que partenaire de basculement dans une nouvelle session de mise en miroir de bases de données. Chaque session requiert deux serveurs partenaires : l'un démarre comme serveur principal et l'autre démarre comme serveur miroir. Les deux serveurs partenaires doivent de préférence résider sur des ordinateurs différents.
Cette option est spécifiée une seule fois par session sur chaque serveur partenaire. L’initiation d’une session de miroir de base de données nécessite deux ALTER DATABASE instructions PARTNER ='partner_server' de base de donnéesSET. Leur ordre est important. D’abord, connectez-vous au serveur miroir et spécifiez l’instance principale du serveur comme partner_server (SET PARTNER = 'principal_server'). Ensuite, connectez-vous au serveur principal et spécifiez l’instance du serveur miroir comme partner_server (SET PARTENAIRE = 'mirror_server') ; cela lance une session de miroir de base de données entre ces deux partenaires. Pour plus d’informations, consultez Configuration de la mise en miroir d’une base de données.
La valeur de partner_server est une adresse réseau de serveur. La syntaxe est la suivante :
TCP** ://<system-address>:**<port>
où
- <system-address> est une chaîne, telle qu’un nom de système, un nom de domaine complet ou une adresse IP, qui identifie de manière unique l’ordinateur de destination.
- <port> est un numéro de port associé au point de terminaison de mise en miroir de l’instance du serveur partenaire.
Pour plus d’informations, consultez Spécifier une adresse réseau de serveur (mise en miroir de bases de données).
L’exemple suivant illustre la SET clause PARTNER ='partner_server' :
'TCP://MYSERVER.mydomain.Adventure-Works.com:7777'
Important
Si une session est configurée en utilisant l’instruction ALTER DATABASE au lieu de SQL Server Management Studio, la session est réglée par défaut en mode sécurité totale des transactions (SÉCURITÉ est réglé en PLEIN) et s’exécute en mode sécurité élevée sans basculement automatique. Pour autoriser le basculement automatique, configurez un témoin et pour le mode hautes performances, désactivez la sécurité des transactions (SAFETY OFF).
FAILOVER bascule manuellement le serveur principal vers le serveur miroir. Vous ne pouvez spécifier l'option FAILOVER que sur le serveur principal. Cette option est valide dans le seul cas où le paramètre SAFETY a la valeur FULL (valeur par défaut).
L’option FAILOVER nécessite master comme contexte de base de données.
FORCE_SERVICE_ALLOW_DATA_LOSS force le service de base de données vers la base de données miroir après la défaillance du serveur principal avec la base de données dans un état non synchronisé ou dans un état synchronisé si le basculement automatique ne se produit pas.
Il est vivement conseillé de ne forcer le service que si le serveur principal n'est plus en cours d'exécution. Sinon, certains clients peuvent continuer à accéder la base de données principale d'origine au lieu de la nouvelle base de données principale. FORCE_SERVICE_ALLOW_DATA_LOSS est disponible uniquement sur le serveur miroir et seulement dans les circonstances suivantes :
- Le serveur principal est hors service.
- WITNESS a la valeur OFF ou le témoin est connecté au serveur miroir.
Forcez le service uniquement si vous pouvez prendre le risque de perdre des données afin de restaurer immédiatement le service à la base de données.
Lorsque vous forcez le service, la session est interrompue ; toutes les données sont conservées temporairement dans la base de données principale d'origine. Une fois que le principal d'origine est en service et en mesure de communiquer avec le nouveau serveur principal, l'administrateur de base de données peut réactiver le service. Lors d'une reprise de la session, tous les enregistrements de journal non envoyés et les mises à jour correspondantes sont perdus.
OFF supprime une session de mise en miroir de bases de données et supprime la mise en miroir de la base de données. Vous pouvez définir la valeur OFF sur l'un et l'autre des serveurs partenaires. Pour plus d’informations sur l’impact de la suppression d’une mise en miroir de bases de données, consultez Suppression d’une mise en miroir des bases de données.
RESUME reprend une session de mise en miroir de bases de données interrompue. Vous ne pouvez spécifier l'option RESUME que sur le serveur principal.
SAFETY { FULL | OFF } définit le niveau de sécurité des transactions. Vous ne pouvez spécifier l'option SAFETY que sur le serveur principal.
La valeur par défaut est FULL. Avec la sécurité complète, la session de mise en miroir de bases de données s’exécute de façon synchrone (mode haute sécurité). Si l’option SAFETY est désactivée (OFF), la session de mise en miroir de bases de données s’exécute de façon asynchrone (mode hautes performances).
Le comportement du mode haute sécurité dépend en partie du témoin :
Lorsque SAFETY a la valeur FULL et qu'un témoin est défini pour la session, la session s'exécute en mode haute sécurité avec basculement automatique. En cas de perte du serveur principal, la session bascule automatiquement si la base de données est synchronisée et si l'instance du serveur miroir et le témoin sont toujours connectés l'un à l'autre (en d'autres termes, ils ont un quorum). Pour plus d’informations, consultez Quorum : Effets d’un témoin sur la disponibilité de la base de données (mise en miroir de bases de données).
Si un témoin est défini pour la session mais qu'il est déconnecté à ce moment-là, la perte du serveur miroir provoque l'arrêt du serveur principal.
Lorsque SAFETY prend la valeur FULL et que le témoin a la valeur OFF, la session s'exécute en mode haute sécurité sans basculement automatique. L'arrêt éventuel de l'instance de serveur miroir n'a aucune incidence sur l'instance de serveur principal. Par contre, si l'instance de serveur principal s'arrête, le service peut être forcé (avec perte de données, le cas échéant) sur l'instance de serveur miroir.
Si SAFETY a la valeur OFF, la session s'exécute en mode hautes performances et les basculements manuel et automatique ne sont pas pris en charge. Cependant, les problèmes survenant sur le miroir n’ont pas d’incidence sur l’instance du serveur principal qui, si elle s’arrête, peut être si nécessaire, relayée par l’instance de serveur miroir dont vous forcez le service (avec une perte possible des données). Pour cela, WITNESS doit avoir la valeur OFF, ou le témoin doit être connecté à ce moment-là au miroir. Pour plus d'informations sur le service forcé, consultez « FORCE_SERVICE_ALLOW_DATA_LOSS » plus haut dans cette section.
Important
Le mode hautes performances n'a pas été prévu pour utiliser un témoin. Toutefois, il est vivement recommandé de vérifier que WITNESS a la valeur OFF chaque fois que l'option SAFETY est désactivée (OFF).
SUSPEND suspend une session de mise en miroir de bases de données.
Vous pouvez définir la valeur SUSPEND sur l'un et l'autre des serveurs partenaires.
TIMEOUT integer spécifie le délai d’attente en secondes. Le délai d'attente est la durée maximale pendant laquelle une instance de serveur attend de recevoir un message PING d'une autre instance de la session de mise en miroir avant de considérer que cette dernière est déconnectée.
Vous ne pouvez spécifier l'option TIMEOUT que sur le serveur principal. Si vous ne précisez pas de valeur, le délai défini par défaut est 10 secondes. Si vous spécifiez 5 ou une valeur supérieure, le délai d'attente correspond au nombre de secondes indiqué. Si vous spécifiez une valeur comprise entre 0 et 4 secondes, le délai d'attente est automatiquement de 5 secondes.
Important
Le temps d'attente recommandé est de 10 secondes minimum. En définissant une valeur inférieure à 10 secondes, vous créez la possibilité qu'un système surchargé soit à court de PING et qu'il déclare à tort une défaillance.
Pour plus d’informations, consultez Défaillances possibles pendant la mise en miroir d’une base de données.
WITNESS <witness_option> contrôle les propriétés de base de données qui définissent un témoin de mise en miroir de bases de données. Une clause WITNESS affecte SET les deux copies de la base de données, mais vous pouvez spécifier SET WITNESS uniquement sur le serveur principal. Si un témoin est défini pour une session, le quorum est obligatoire pour servir la base de données sans tenir compte de l’option SAFETY. Pour plus d’informations, consultez Quorum : Effets d’un témoin sur la disponibilité de la base de données (mise en miroir de bases de données).
Les partenaires de basculement et témoins doivent de préférence résider sur des ordinateurs différents. Pour plus d’informations sur le témoin, consultez Témoin de mise en miroir de base de données.
Pour exécuter une SET instruction WITNESS, l’ÉTAT des points d’extrémité des instances principale et du serveur witness doit être défini sur START. Notez également que le ROLE point de terminaison de miroir de la base de données d’une instance serveur témoin doit être défini soit sur WITNESS, soit sur ALL. Pour plus d’informations sur la spécification d’un point de terminaison, consultez Point de terminaison de mise en miroir de bases de données.
Pour connaître le rôle et l'état du point de terminaison de mise en miroir de bases de données d'une instance de serveur, utilisez l'instruction Transact-SQL suivante sur cette instance :
SELECT role_desc, state_desc FROM sys.database_mirroring_endpoints
Remarque
Les propriétés de base de données ne peuvent pas être définies sur le témoin.
<witness_option> ::=
Remarque
Une <seule witness_option> est autorisée selon SET la clause TÉMOIN.
'witness_server' Spécifie une instance de l’Moteur de base de données pour agir en tant que serveur témoin pour une session de mise en miroir de bases de données. Vous pouvez spécifier SET les déclarations WITNESS uniquement sur le serveur principal.
Dans une SET affirmation WITNESS ='witness_server' , la syntaxe de witness_server est la même que celle de partner_server.
OFF supprime le témoin d’une session de mise en miroir de bases de données. Si le témoin a la valeur OFF, le basculement automatique est désactivé. Lorsque la base de données est configurée avec l'option FULL SAFETY et le témoin avec la valeur OFF, une défaillance du serveur miroir conduit le serveur principal à rendre la base de données inaccessible.
Notes
Exemples
R. Création d'une session de mise en miroir de bases de données avec un témoin
Configurer le miroir de base de données avec un témoin nécessite de configurer la sécurité et de préparer la base de données miroir, ainsi que d’utiliser ALTER DATABASE pour définir les partenaires. Pour obtenir un exemple illustrant la procédure d’installation complète, consultez Configuration de la mise en miroir de bases de données.
B. Basculement manuel d'une session de mise en miroir de bases de données
Le basculement manuel peut être débuté par l'un ou l'autre des serveurs partenaires de mise en miroir de bases de données. Avant le basculement, assurez-vous que le serveur considéré comme serveur principal est effectivement le serveur principal. Par exemple, pour la base de données AdventureWorks2025, sur l'instance de serveur représentant, selon vous, le serveur principal, exécutez la requête suivante :
SELECT db.name, m.mirroring_role_desc
FROM sys.database_mirroring m
JOIN sys.databases db
ON db.database_id = m.database_id
WHERE db.name = N'AdventureWorks2022';
GO
Si l'instance de serveur est effectivement le principal, la valeur de mirroring_role_desc est Principal. Si cette instance de serveur est le serveur miroir, l'instruction SELECT retourne Mirror.
L'exemple suivant suppose que le serveur est le principal actuel.
Basculez manuellement vers le serveur partenaire de mise en miroir de bases de données :
ALTER DATABASE AdventureWorks2022 SET PARTNER FAILOVER; GOPour vérifier les résultats du basculement sur le nouveau miroir, exécutez la requête suivante :
SELECT db.name, m.mirroring_role_desc FROM sys.database_mirroring m JOIN sys.databases db ON db.database_id = m.database_id WHERE db.name = N'AdventureWorks2022'; GO
La valeur actuelle de mirroring_role_desc est désormais Mirror.