Gérer les métadonnées lors de la mise à disposition d’une base de données sur une autre instance de serveur (SQL Server)

Cette rubrique est pertinente dans les situations suivantes :

• Configuration des réplicas de disponibilité d’un groupe de disponibilité des groupes de disponibilité Always On.

• Configuration de la mise en miroir d'une base de données.

• Lors de la préparation à la modification des rôles entre les serveurs principaux et secondaires dans une configuration d'expédition des journaux.

• Restauration d’une base de données sur une autre instance de serveur.

• Attachement d’une copie d’une base de données sur une autre instance de serveur.

Certaines applications dépendent d’informations, d’entités et/ou d’objets qui se trouvent en dehors de l’étendue d’une base de données utilisateur unique. En règle générale, une application a des dépendances sur les bases de données master et msdb , ainsi que sur la base de données utilisateur. Les informations stockées en dehors d'une base de données utilisateur et nécessaires au bon fonctionnement de cette base de données doivent être disponibles sur l'instance du serveur de destination. Par exemple, les connexions d’une application sont stockées en tant que métadonnées dans la base de données master et doivent être recréées sur le serveur de destination. Si un plan de maintenance d’application ou de base de données dépend des travaux SQL Server Agent, dont les métadonnées sont stockées dans la base de données msdb , vous devez recréer ces travaux sur l’instance de serveur de destination. De même, les métadonnées d’un déclencheur au niveau du serveur sont stockées dans master.

Lorsque vous déplacez la base de données d’une application vers une autre instance de serveur, vous devez recréer toutes les métadonnées des entités et objets dépendants dans master et msdb sur l’instance de serveur de destination. Par exemple, si une application de base de données utilise des déclencheurs au niveau du serveur, l’attachement ou la restauration de la base de données sur le nouveau système ne suffit pas. La base de données ne fonctionnera pas comme prévu, sauf si vous recréez manuellement les métadonnées de ces déclencheurs dans la base de données master .

Informations, entités et objets stockés en dehors des bases de données utilisateur

Le reste de cette rubrique récapitule les problèmes potentiels susceptibles d’affecter une base de données mise à disposition sur une autre instance de serveur. Vous devrez peut-être recréer un ou plusieurs des types d’informations, d’entités ou d’objets répertoriés dans la liste suivante. Pour afficher un résumé, cliquez sur le lien de l’élément.

• Paramètres de configuration du serveur

• Identifiants

• Requêtes entre plusieurs bases de données

• Propriété de la base de données

• Requêtes distribuées/serveurs liés

• Données chiffrées

• Messages d’erreur définis par l’utilisateur

• Notifications d’événements et événements WMI (Windows Management Instrumentation) (au niveau du serveur)

• Procédures stockées étendues

• Moteur de recherche en texte intégral pour les propriétés SQL Server

• Tâches

• Connexions

• Autorisations

• Paramètres de réplication

• Applications de Service Broker

• Procédures de démarrage

• Déclencheurs (au niveau du serveur)

Paramètres de configuration du serveur

SQL Server 2005 et versions ultérieures installent et démarrent sélectivement les services et fonctionnalités clés. Cela permet de réduire la surface d’attaque d’un système. Dans la configuration par défaut des nouvelles installations, de nombreuses fonctionnalités ne sont pas activées. Si la base de données s’appuie sur un service ou une fonctionnalité désactivé par défaut, ce service ou cette fonctionnalité doit être activé sur l’instance de serveur de destination.

Pour plus d’informations sur ces paramètres et leur activation ou leur désactivation, consultez Options de configuration du serveur (SQL Server).

[Top]

Informations d’identification

Les informations d’identification sont un enregistrement qui contient les informations d’authentification requises pour la connexion à une ressource en dehors de SQL Server. La plupart des informations d’identification se composent d’une connexion Windows et d’un mot de passe.

Pour plus d’informations sur cette fonctionnalité, consultez Informations d’identification (moteur de base de données).

[Top]

Requêtes inter-bases de données

Les options de base de données DB_CHAINING et TRUSTWORTHY sont désactivées par défaut. Si l’un de ces éléments est défini sur ON pour la base de données d’origine, vous devrez peut-être les activer sur la base de données sur l’instance de serveur de destination. Pour plus d'informations, voir ALTER DATABASE (Transact-SQL).

Les opérations d’attachement et de détachement désactivent le chaînage d'appartenance entre bases de données. Pour plus d’informations sur l’activation du chaînage, consultez l’option de configuration du serveur de chaînage de propriétés de base de données croisée.

Pour plus d’informations, consultez également Configurer une base de données miroir pour utiliser la propriété Trustworthy (Transact-SQL)

[Top]

Propriété de la base de données

Lorsqu’une base de données est restaurée sur un autre ordinateur, la connexion SQL Server ou l’utilisateur Windows qui a lancé l’opération de restauration devient automatiquement le propriétaire de la nouvelle base de données. Lorsque la base de données est restaurée, l’administrateur système ou le nouveau propriétaire de la base de données peut modifier la propriété de la base de données.

Requêtes distribuées et serveurs liés

Les requêtes distribuées et les serveurs liés sont pris en charge pour les applications OLE DB. Les requêtes distribuées accèdent aux données à partir de plusieurs sources de données hétérogènes sur les mêmes ordinateurs ou différents. Une configuration de serveur lié permet à SQL Server d’exécuter des commandes sur des sources de données OLE DB sur des serveurs distants. Pour plus d’informations sur ces fonctionnalités, consultez Serveurs liés (moteur de base de données).

[Top]

Données chiffrées

Si la base de données que vous mettez à disposition sur une autre instance de serveur contient des données chiffrées et si la clé principale de base de données est protégée par la clé principale du service sur le serveur d’origine, il peut être nécessaire de recréer le chiffrement de clé principale du service. La clé principale de base de données est une clé symétrique utilisée pour protéger les clés privées des certificats et des clés asymétriques dans une base de données chiffrée. Une fois créée, la clé principale de base de données est chiffrée à l’aide de l’algorithme Triple DES et d’un mot de passe fourni par l’utilisateur.

Pour activer le déchiffrement automatique de la clé principale de base de données sur une instance de serveur, une copie de cette clé est chiffrée à l’aide de la clé principale du service. Cette copie chiffrée est stockée à la fois dans la base de données et dans master. En règle générale, la copie stockée dans master est mise à jour silencieusement chaque fois que la clé principale est modifiée. SQL Server tente d’abord de déchiffrer la clé principale de base de données avec la clé principale du service de l’instance. Si ce déchiffrement échoue, SQL Server recherche dans le magasin d’informations d’identification les informations d’identification de clé principale qui ont le même GUID de famille que la base de données pour laquelle elle requiert la clé principale. SQL Server tente ensuite de déchiffrer la clé principale de base de données avec chaque informations d’identification correspondantes jusqu’à ce que le déchiffrement réussisse ou qu’il n’y ait plus d’informations d’identification. Une clé principale qui n’est pas chiffrée par la clé principale du service doit être ouverte à l’aide de l’instruction OPEN MASTER KEY et d’un mot de passe.

Lorsqu’une base de données chiffrée est copiée, restaurée ou attachée à une nouvelle instance de SQL Server, une copie de la clé principale de base de données chiffrée par la clé principale du service n’est pas stockée dans master sur l’instance de serveur de destination. Sur l’instance du serveur de destination, vous devez ouvrir la clé principale de la base de données. Pour ouvrir la clé principale, exécutez l'instruction suivante : OUVRIR CLÉ MAÎTRE DÉCHIFFREMENT PAR MOT DE PASSE ='password'. Nous vous recommandons ensuite d’activer le déchiffrement automatique de la clé principale de base de données en exécutant l’instruction suivante : ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. Cette instruction ALTER MASTER KEY provisionne l’instance de serveur avec une copie de la clé principale de base de données chiffrée avec la clé principale du service. Pour plus d’informations, consultez OPEN MASTER KEY (Transact-SQL) et ALTER MASTER KEY (Transact-SQL).

Pour plus d’informations sur l’activation du déchiffrement automatique de la clé principale de base de données d’une base de données miroir, consultez Configurer une base de données miroir chiffrée.

Pour plus d’informations, consultez également :

• Hiérarchie de chiffrement

• Configurer une base de données miroir chiffrée

• Créer des clés symétriques identiques sur deux serveurs

[Top]

Messages d’erreur définis par l’utilisateur

Les messages d’erreur définis par l’utilisateur résident dans l’affichage catalogue sys.messages . Cet affichage catalogue est stocké dans master. Si une application de base de données dépend des messages d’erreur définis par l’utilisateur et que la base de données est mise à disposition sur une autre instance de serveur, utilisez sp_addmessage pour ajouter ces messages définis par l’utilisateur sur l’instance de serveur de destination.

[Top]

Notifications d’événements et événements WMI (Windows Management Instrumentation) (au niveau du serveur)

Notifications d’événements Server-Level

Les notifications d’événements au niveau du serveur sont stockées dans msdb. Par conséquent, si une application de base de données s’appuie sur des notifications d’événements au niveau du serveur, cette notification d’événement doit être recréé sur l’instance de serveur de destination. Pour afficher les notifications d’événements sur une instance de serveur, utilisez l’affichage catalogue sys.server_event_notifications . Pour plus d’informations, consultez Notifications d’événements.

En outre, les notifications d’événements sont fournies à l’aide de Service Broker. Les itinéraires pour les messages entrants ne sont pas inclus dans la base de données qui contient un service. Au lieu de cela, les itinéraires explicites sont stockés dans msdb. Si votre service utilise un itinéraire explicite dans la base de données msdb pour router les messages entrants vers le service, lorsque vous attachez une base de données dans une autre instance, vous devez recréer cet itinéraire.

Événements WMI (Windows Management Instrumentation)

Le fournisseur WMI pour les événements serveur vous permet d’utiliser WMI (Windows Management Instrumentation) pour surveiller les événements dans SQL Server. Toute application qui s’appuie sur des événements au niveau du serveur exposés via le fournisseur WMI sur lequel une base de données s’appuie doit être définie sur l’ordinateur de l’instance de serveur de destination. Le fournisseur d’événements WMI crée des notifications d’événements avec un service cible défini dans msdb.

Pour créer une alerte WMI à l’aide de SQL Server Management Studio

• Créer une alerte d’événement WMI

Fonctionnement des notifications d’événements pour une base de données mise en miroir

La livraison entre bases de données des notifications d'événements impliquant une base de données mise en miroir est éloignée, par définition, car la base de données mise en miroir peut basculer. Service Broker fournit une prise en charge spéciale des bases de données mises en miroir, sous la forme d’itinéraires mis en miroir. Un itinéraire mis en miroir a deux adresses : une pour l’instance de serveur principal et une pour l’instance de serveur miroir.

En configurant des itinéraires mis en miroir, vous devez rendre le routage Service Broker conscient de la mise en miroir de bases de données. Les itinéraires mis en miroir permettent à Service Broker de rediriger de manière transparente les conversations vers l’instance de serveur principal actuelle. Par exemple, considérez un service, Service_A, qui est hébergé par une base de données mise en miroir, Database_A. Supposons que vous avez besoin d’un autre service, Service_B, qui est hébergé par Database_B, pour avoir une boîte de dialogue avec Service_A. Pour que cette boîte de dialogue soit possible, Database_B doit contenir un itinéraire mis en miroir pour Service_A. En outre, Database_A doit contenir un itinéraire de transport TCP non-miroir vers Service_B, qui, contrairement à un itinéraire local, reste valide après le basculement. Ces itinéraires permettent aux ACKs de revenir après un basculement. Étant donné que le service de l’expéditeur est toujours nommé de la même manière, l’itinéraire doit spécifier l’instance broker.

La condition requise pour les itinéraires mis en miroir s’applique, que le service de la base de données mise en miroir soit le service initiateur ou le service cible :

• Si le service cible est dans la base de données mise en miroir, le service initiateur doit avoir un itinéraire mis en miroir qui ramène à la cible. Toutefois, la cible peut avoir un itinéraire régulier vers l’initiateur.

• Si le service initiateur se trouve dans la base de données mise en miroir, le service cible doit avoir un itinéraire mis en miroir vers l’initiateur pour remettre les accusés de réception et les réponses. Toutefois, l’initiateur peut avoir un itinéraire régulier vers la cible.

[Top]

Procédures stockées étendues

Les procédures stockées étendues sont programmées à l’aide de l’API de procédure stockée étendue SQL Server. Un membre du rôle serveur fixe sysadmin peut inscrire une procédure stockée étendue auprès d’une instance de SQL Server et accorder l’autorisation aux utilisateurs d’exécuter la procédure. Les procédures stockées étendues ne peuvent être ajoutées qu’à la base de données master .

Les procédures stockées étendues s’exécutent directement dans l’espace d’adressage d’une instance de SQL Server, et peuvent produire des fuites de mémoire ou d’autres problèmes qui réduisent les performances et la fiabilité du serveur. Vous devez envisager de stocker des procédures stockées étendues dans une instance de SQL Server distincte de l’instance qui contient les données référencées. Vous devez également envisager d’utiliser des requêtes distribuées pour accéder à la base de données.

Pour plus d’informations, consultez GRANT Object Permissions (Transact-SQL), DENY Object Permissions (Transact-SQL) et REVOKE Object Permissions (Transact-SQL).

[Top]

moteur Full-Text pour les propriétés de SQL Server

Les propriétés sont définies sur le moteur Full-Text par sp_fulltext_service. Vérifiez que l’instance de serveur de destination a les paramètres requis pour ces propriétés. Pour plus d’informations sur ces propriétés, consultez FULLTEXTSERVICEPROPERTY (Transact-SQL).

En outre, si les composants séparateurs de mots et racinisateurs ou filtres de recherche de texte intégral ont des versions différentes sur les instances de serveur d’origine et de destination, l’index de recherche en texte intégral et les requêtes peuvent se comporter différemment. En outre, le dictionnaire des synonymes est stocké dans des fichiers spécifiques à l’instance. Vous devez transférer une copie de ces fichiers vers un emplacement équivalent sur l’instance du serveur de destination ou les recréer sur une nouvelle instance.

Pour plus d’informations, consultez également :

• Sauvegarder et restaurer des catalogues et des index Full-Text

• Mise en miroir de bases de données et catalogues Full-Text (SQL Server)

[Top]

Emplois

Si la base de données s’appuie sur des travaux SQL Server Agent, vous devez les recréer sur l’instance de serveur de destination. Les travaux dépendent de leurs environnements. Si vous envisagez de recréer un travail existant sur l’instance de serveur de destination, l’instance de serveur de destination peut être modifiée pour correspondre à l’environnement de ce travail sur l’instance de serveur d’origine. Les facteurs environnementaux suivants sont importants :

• Identifiant utilisé par la tâche

  Pour créer ou exécuter des travaux SQL Server Agent, vous devez d’abord ajouter les connexions SQL Server requises par le travail à l’instance de serveur de destination. Pour plus d’informations, consultez Configurer un utilisateur pour créer et gérer des travaux SQL Server Agent.

• Compte de démarrage du service SQL Server Agent

  Le compte de démarrage du service définit le compte Microsoft Windows dans lequel s’exécute SQL Server Agent, ainsi que ses autorisations réseau. SQL Server Agent s’exécute en tant que compte d’utilisateur spécifié. Le contexte du service Agent affecte les paramètres du travail et de son environnement d’exécution. Le compte doit avoir accès aux ressources, telles que les partages réseau, requis par le travail. Pour plus d’informations sur la sélection et la modification du compte de démarrage du service, consultez Sélectionner un compte pour le service SQL Server Agent.

  Pour fonctionner correctement, le compte de démarrage du service doit être configuré pour disposer des autorisations de domaine, de système de fichiers et de Registre appropriées. En outre, un travail peut nécessiter une ressource réseau partagée qui doit être configurée pour le compte de service. Pour plus d’informations, consultez Configurer des comptes de service Windows et des autorisations.

• Le service SQL Server Agent, associé à une instance spécifique de SQL Server, possède sa propre ruche de Registre et ses travaux ont généralement des dépendances sur un ou plusieurs des paramètres de cette ruche de Registre. Pour se comporter comme prévu, un travail nécessite ces paramètres de Registre. Si vous utilisez un script pour recréer un travail dans un autre service SQL Server Agent, son Registre peut ne pas avoir les paramètres appropriés pour ce travail. Pour que les travaux recréé se comportent correctement sur une instance de serveur de destination, les services SQL Server Agent d’origine et de destination doivent avoir les mêmes paramètres de Registre.

  Avertissement

  La modification des paramètres de Registre sur le service SQL Server Agent de destination pour gérer un travail recréé peut poser problème si les paramètres actuels sont requis par d’autres travaux. En outre, la modification incorrecte du registre peut endommager gravement votre système. Avant d’apporter des modifications au registre, nous vous recommandons de sauvegarder les données importantes sur l’ordinateur.

• Proxies SQL Server Agent

  Un proxy SQL Server Agent définit le contexte de sécurité d’une étape de travail spécifiée. Pour qu’un travail s’exécute sur l’instance du serveur de destination, tous les proxys requis doivent être recréé manuellement sur cette instance. Pour plus d’informations, consultez Créer un proxy SQL Server Agent et résoudre les problèmes liés aux travaux multiserveurs qui utilisent des proxys.

Pour plus d’informations, consultez également :

• Mettre en œuvre des tâches

• Gestion des connexions et des travaux après le basculement de rôle (SQL Server) (pour la mise en miroir de bases de données)

• Configurer des comptes de service Windows et des autorisations (lorsque vous installez une instance de SQL Server)

• Configurer SQL Server Agent (lorsque vous installez une instance de SQL Server)

• Mettre en œuvre la sécurité de SQL Server Agent

Pour afficher les emplois existants et leurs propriétés

• Surveiller l’activité des travaux

• sp_help_job (Transact-SQL)

• Afficher les informations sur l'étape du travail

• dbo.sysjobs (Transact-SQL)

Pour créer un travail

• Créer un emploi

• Créer un emploi

Meilleures pratiques pour l’utilisation d’un script pour recréer un travail

Nous vous recommandons de commencer par écrire un script de travail simple, de recréer le travail sur l’autre service SQL Server Agent et d’exécuter le travail pour voir s’il fonctionne comme prévu. Cela vous permet d’identifier les incompatibilités et d’essayer de les résoudre. Si un travail scripté ne fonctionne pas comme prévu dans son nouvel environnement, nous vous recommandons de créer un travail équivalent qui fonctionne correctement dans cet environnement.

[Top]

Connexions

La connexion à une instance de SQL Server nécessite une connexion SQL Server valide. Cette connexion est utilisée dans le processus d’authentification qui vérifie si le principal peut se connecter à l’instance de SQL Server. Un utilisateur de base de données pour lequel la connexion SQL Server correspondante n’est pas définie ou est incorrectement définie sur une instance de serveur ne peut pas se connecter à l’instance. L'utilisateur devient donc un utilisateur orphelin de la base de données sur cette instance du serveur. Un utilisateur de base de données peut devenir orphelin après la restauration, l'attachement ou la copie de la base de données dans une autre instance de SQL Server.

Pour générer un script pour certains ou tous les objets de la copie d’origine de la base de données, vous pouvez utiliser l’Assistant Générer des scripts et, dans la boîte de dialogue Choisir les options de script , définissez l’option Connexions de script sur True.

[Top]

Autorisations

Les types d’autorisations suivants peuvent être affectés lorsqu’une base de données est mise à disposition sur une autre instance de serveur.

• GRANT, REVOKE ou REFUSER les autorisations sur les objets système

• GRANT, REVOKE ou DENY autorisations sur l’instance de serveur (autorisations au niveau du serveur)

GRANT, REVOKE et DENY Autorisations sur les objets système

Les autorisations sur les objets système, tels que les procédures stockées, les procédures stockées étendues, les fonctions et les vues, sont stockées dans la base de données master et doivent être configurées sur l’instance de serveur de destination.

Pour générer un script pour certains ou tous les objets de la copie d’origine de la base de données, vous pouvez utiliser l’Assistant Générer des scripts et, dans la boîte de dialogue Choisir les options de script , définissez l’option Script Object-Level Autorisations sur True.

Les objets système sont visibles dans l’affichage catalogue sys.system_objects . Les autorisations sur les objets système sont visibles dans l’affichage catalogue sys.database_permissions dans la base de données master . Pour plus d’informations sur l’interrogation de ces vues de catalogue et l’octroi d’autorisations d’objet système, consultez GRANT System Object Permissions (Transact-SQL). Pour plus d’informations, consultez REVOKE System Object Permissions (Transact-SQL) et DENY System Object Permissions (Transact-SQL).

GRANT, REVOKE et REFUSER les autorisations sur une instance de serveur

Les autorisations au niveau de l’étendue du serveur sont stockées dans la base de données master et doivent être configurées sur l’instance du serveur de destination. Pour obtenir des informations sur les autorisations de serveur d’une instance de serveur, interrogez la vue de catalogue sys.server_permissions, pour des informations sur les principaux du serveur, interrogez la vue de catalogue sys.server_principals, et pour des informations sur l’appartenance aux rôles de serveur, interrogez la vue de catalogue sys.server_role_members.

Pour plus d’informations, consultez GRANT Server Permissions (Transact-SQL), REVOKE Server Permissions (Transact-SQL) et DENY Server Permissions (Transact-SQL).

autorisations Server-Level pour un certificat ou une clé asymétrique

Les autorisations au niveau du serveur ne peuvent pas être accordées directement à un certificat ou à une clé asymétrique. Au lieu de cela, les autorisations au niveau du serveur sont accordées à une connexion mappée créée exclusivement pour un certificat ou une clé asymétrique spécifique. Par conséquent, chaque certificat ou clé asymétrique nécessitant des autorisations au niveau du serveur nécessite sa propre connexion mappée par certificat ou une connexion à clé asymétrique mappée. Pour accorder des autorisations au niveau du serveur pour un certificat ou une clé asymétrique, accordez les autorisations à sa connexion mappée.

La connexion mappée et ses autorisations résident tous deux dans master. Si un certificat ou une clé asymétrique réside dans une base de données autre que master, vous devez le recréer dans master et le mapper à une connexion. Si vous déplacez, copiez ou restaurez la base de données sur une autre instance de serveur, vous devez recréer son certificat ou sa clé asymétrique dans la base de données master de l’instance de serveur de destination, mapper à une connexion et accorder les autorisations de niveau serveur requises à la connexion.

Pour créer un certificat ou une clé asymétrique

• CRÉER CERTIFICAT (Transact-SQL)

• CRÉER UNE CLÉ ASYMÉTRIQUE (Transact-SQL)

Pour mapper un certificat ou une clé asymétrique à une connexion

• CRÉER UNE CONNEXION (Transact-SQL)

Pour attribuer des autorisations à la connexion mappée

• GRANT – octroi d'autorisations de serveur (Transact-SQL)

Pour plus d’informations sur les certificats et les clés asymétriques, consultez Hiérarchie de chiffrement.

[Top]

Paramètres de réplication

Si vous restaurez une sauvegarde d’une base de données répliquée sur un autre serveur ou une autre base de données, les paramètres de réplication ne peuvent pas être conservés. Dans ce cas, vous devez recréer toutes les publications et abonnements une fois les sauvegardes restaurées. Pour faciliter ce processus, créez des scripts pour vos paramètres de réplication actuels, ainsi que pour l’activation et la désactivation de la réplication. Pour vous aider à recréer vos paramètres de réplication, copiez ces scripts et modifiez les références de nom de serveur pour fonctionner pour l’instance de serveur de destination.

Pour plus d’informations, consultez Sauvegarde et restauration des bases de données répliquées, Mise en miroir et réplication de bases de données (SQL Server) et Expédition des journaux et réplication (SQL Server).

[Top]

Applications de Service Broker

De nombreux aspects d’une application Service Broker se déplacent avec la base de données. Toutefois, certains aspects de l’application doivent être recréés ou reconfigurés dans le nouvel emplacement.

[Top]

Procédures de démarrage

Une procédure de démarrage est une procédure stockée marquée pour l’exécution automatique et exécutée chaque fois que SQL Server démarre. Si la base de données dépend des procédures de démarrage, elles doivent être définies sur l’instance de serveur de destination et être configurées pour être exécutées automatiquement au démarrage.

[Top]

Déclencheurs (au niveau du serveur)

Les déclencheurs DDL activent les procédures stockées en réponse à divers événements DDL (Language de définition de données). Ces événements correspondent principalement aux instructions Transact-SQL qui commencent par les mots clés CREATE, ALTER et DROP. Certaines procédures stockées système qui effectuent des opérations de type DDL peuvent également activer des déclencheurs DDL.

Pour plus d’informations sur cette fonctionnalité, consultez Déclencheurs DDL.

[Top]

Voir aussi

Bases de données autonomes
Copier des bases de données sur d’autres serveurs
Détacher et attacher une base de données (SQL Server)
Basculer vers une base de données secondaire de copie des journaux de transaction (SQL Server)
Basculement de rôle durant une session de mise en miroir de bases de données (SQL Server)
Configurer une base de données miroir chiffrée
Gestionnaire de configuration SQL Server
Résoudre les problèmes d’utilisateurs orphelins (SQL Server)