• Article

Gestion des métadonnées lors de la mise à disposition d'une base de données sur une autre instance de serveur

Cette rubrique concerne l'utilisation de Microsoft SQL Server 2005 et versions ultérieures dans les situations suivantes :

  • lors de la configuration de la mise en miroir d'une base de données ;

  • lorsque vous vous préparez à intervertir les rôles des serveurs primaire et secondaire dans une configuration de la copie des journaux de transactions ;

  • lors de la restauration d'une base de données sur une autre instance de serveur ;

  • lors de l'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 n'appartiennent pas au champ d'action d'une base de données mono-utilisateur. Généralement, une application possède des dépendances sur les bases de données master et msdb ainsi que 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 pour une application sont stockées comme métadonnées dans la base de données master, et elles 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 de l'Agent SQL Server, dont les métadonnées sont stockées dans la base de données msdb, vous devez recréer ces travaux sur l'instance du serveur de destination. De la même façon, les métadonnées d'un déclencheur de niveau 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 des objets dépendants dans les bases de données master et msdb sur l'instance du serveur de destination. Par exemple, si une application de base de données utilise des déclencheurs au niveau serveur, il ne suffit pas d'attacher ou de restaurer la base de données sur le nouveau système. La base de données ne fonctionnera pas correctement, sauf si vous recréez manuellement les métadonnées pour 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

La suite de cette rubrique résume les problèmes susceptibles d'affecter une base de données qui est rendue disponible 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 consulter un résumé, cliquez sur le lien correspondant à l'élément.

  • Paramètres de configuration du serveur

  • Informations d'identification

  • Requêtes de bases de données croisé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 d'indexation et de recherche en texte intégral pour les propriétés SQL Server

  • Travaux

  • Connexions

  • Autorisations

  • Paramètres de réplication

  • applications Service Broker

  • Procédures de démarrage

  • Déclencheurs (au niveau du serveur)

Paramètres de configuration du serveur

SQL Server 2005 et les versions ultérieures installent et démarrent sélectivement les services et les fonctionnalités clés. Ainsi, la surface d'exposition vulnérable aux attaques d'un système est réduite. Dans la configuration par défaut des nouvelles installations, de nombreuses fonctionnalités ne sont pas activées. Si la base de données repose sur une fonctionnalité ou un service qui est désactivé par défaut, cette fonction ou ce service doit être activé sur l'instance du serveur de destination.

Pour plus d'informations sur ces paramètres et leur activation ou leur désactivation, consultez Présentation de la configuration de la surface d'exposition et Définition des options de configuration de serveur.

[Haut de la page]

Informations d'identification

Les informations d'identification correspondent à 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 sont composées d'un nom de 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).

Notes

Les comptes proxy de l'Agent SQL Server utilisent des informations d'identification. Pour connaître les informations d'identification d'un compte proxy, utilisez la table système sysproxies.

[Haut de la page]

Requêtes de bases de données croisées

Les options de base de données DB_CHAINING et TRUSTWORTHY sont désactivées par défaut. Si elles sont définies à ON pour la base de données d'origine, vous devrez peut-être les activer sur la base de données de l'instance du serveur de destination. Pour plus d'informations, consultez ALTER DATABASE (Transact-SQL).

Dans SQL Server 2000 Service Pack 3 (SP3) et les versions ultérieures de SQL Server, les opérations d'attachement et de détachement désactivent le chaînage des propriétés des bases de données croisées pour la base de données. Pour plus d'informations sur la manière d'activer le chaînage, consultez Option cross db ownership chaining.

Pour plus d'informations, consultez également :

[Haut de la page]

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 à l'origine de 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 issues de multiples sources de données hétérogènes sur le même ordinateur ou sur des ordinateurs différents. Une configuration de serveurs liés permet à SQL Server d'exécuter des commandes sur les sources de données OLE°DB hébergées par des serveurs distants. Pour plus d'informations sur ces fonctionnalités, consultez Requêtes distribuées, Liaison des serveurs et Obtention de métadonnées de serveurs liés.

[Haut de la page]

Données chiffrées

Si la base de données que vous mettez à disposition sur une autre instance du 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 à clé principale du service. La clé principale de base de données est une clé symétrique qui permet de protéger les clés privées des certificats et les clés asymétriques dans une base de données chiffrée. Lors de sa création, 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 permettre 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 dans la base de données et dans la base master. En général, la copie stockée dans master est mise à jour sans avertissement 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 à l'aide de la clé principale de service de l'instance. Si ce déchiffrement échoue, SQL Server recherche dans la banque d'informations d'identification les informations d'identification de clé principale qui possèdent le même GUID de famille que la base de données pour laquelle la clé principale est requise. SQL Server tente alors de déchiffrer la clé principale de base de données avec toutes les informations d'identification correspondantes, jusqu'à ce que le déchiffrement réussisse ou qu'il ne reste plus d'informations d'identification. Une clé principale qui n'est pas chiffrée par la clé principale de 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 la base de données chiffrée par la clé principale du service n'est pas stockée dans la base master sur l'instance du 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 : OPEN MASTER KEY DECRYPTION BY PASSWORD ='mot de passe'. Nous vous recommandons d'activer alors le déchiffrement automatique de la clé principale de la base de données en exécutant l'instruction suivante : ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. Cette instruction ALTER MASTER KEY fournit à l'instance du serveur une copie de la clé principale de la base de données qui est chiffrée à l'aide de 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 la méthode d'activation du déchiffrement automatique de la clé principale d'une base de données miroir, consultez Configuration d'une base de données miroir chiffrée.

Pour plus d'informations, consultez également :

[Haut de la page]

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 la base de données master. Si une application de base de données dépend des messages d'erreur définis par l'utilisateur et la base de données est mise à disposition sur une autre instance du serveur, utilisez sp_addmessage pour ajouter ces messages définis par l'utilisateur sur l'instance du serveur de destination.

[Haut de la page]

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

Notifications d'événements au niveau du serveur

Les notifications d'événements au niveau du serveur sont stockées dans la base de données msdb. Par conséquent, si une application de base de données repose sur une notification d'événements au niveau du serveur, cette notification doit être recréée sur l'instance du 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 (moteur de base de données).

De plus, les notifications d'événements sont remises à 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 la base de données msdb. Si, pour acheminer les messages entrants jusqu'au service, votre service utilise un itinéraire explicite dans la base de données msdb, vous devez recréer cet itinéraire lorsque vous attachez une base de données dans une instance différente. Pour plus d'informations, consultez Routage Service Broker.

Pour configurer une base de données pour une remise de messages distante

Événements WMI (Windows Management Instrumentation)

Le fournisseur WMI pour les événements SQL Server vous permet d'utiliser WMI (Windows Management Instrumentation) pour surveiller les événements dans SQL Server. Toutes les applications qui reposent sur des événements au niveau du serveur exposés par le biais du fournisseur WMI (Windows Management Instrumentation) sur lequel repose une base de données doivent être définies sur l'ordinateur de l'instance du serveur de destination. Le fournisseur d'événements WMI crée des notifications d'événements à l'aide d'un service cible défini dans msdb.

Notes

Pour plus d'informations, consultez Fournisseur WMI pour les concepts des événements de serveur.

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

Fonctionnement des notifications d'événements pour une base de données miroir

La remise entre bases de données des notifications d'événements qui comprend une base de données miroir se fait à distance, par définition, en raison du risque de basculement de la base de données miroir. Service Broker fournit une prise en charge spéciale des bases de données miroir sous la forme d'itinéraires mis en miroir. Un itinéraire mis en miroir possède deux adresses : celle de l'instance du serveur principal et celle de l'instance du serveur miroir.

En configurant des itinéraires mis en miroir, vous rendez le routage Service Broker capable de reconnaître la mise en miroir des 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 en cours. Par exemple, imaginons un service, Service_A, hébergé par une base de données mise en miroir, Database_A. Supposons que vous ayez besoin qu'un autre service, Service_B, hébergé par Database_B, dialogue avec Service_A. Pour ce faire, Database_B doit posséder un itinéraire mis en miroir pour Service_A. Database_A doit aussi contenir un itinéraire de transport TCP non mis en miroir vers Service_B, qui, contrairement à un itinéraire local, reste valide après un basculement. Ces itinéraires permettent aux accusés de réception de revenir après un basculement. Comme le service de l'expéditeur est toujours nommé de la même manière, l'itinéraire doit spécifier l'instance de broker.

L'exigence définie pour les itinéraires mis en miroir est valable 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. Cependant, la cible peut avoir un itinéraire standard qui ramène à l'initiateur.

  • Si le service initiateur est dans la base de données miroir, le service cible doit avoir un itinéraire mis en miroir qui ramène à l'initiateur pour remettre les accusés et les réponses. Cependant, l'initiateur peut avoir un itinéraire standard qui ramène à la cible.

Pour plus d'informations, consultez également :

[Haut de la page]

Procédures stockées étendues

Important

Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft 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 plutôt l'intégration CLR.

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 enregistrer une procédure stockée étendue avec une instance de SQL Server, puis octroyer à d'autres utilisateurs l'autorisation 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 elles peuvent générer des fuites de mémoire ou d'autres problèmes qui diminuent les performances et la fiabilité du serveur. Il est préférable de stocker les procédures stockées étendues dans une instance de SQL Server distincte de celle qui contient les données de référence et d'utiliser des requêtes distribuées pour accéder à la base de données. Pour plus d'informations, consultez Requêtes distribuées.

Important

Avant d'ajouter des procédures stockées étendues au serveur et d'accorder à d'autres utilisateurs des autorisations d'exécution (EXECUTE), il est conseillé à l'administrateur système de vérifier minutieusement chaque procédure stockée étendue afin de s'assurer qu'elle ne contient aucun code nuisible ou malveillant. Pour plus d'informations, consultez Procédures stockées étendues.

Pour plus d'informations, consultez GRANT – octroi d'autorisations d'objet (Transact-SQL), DENY – refus d'autorisations d'objet (Transact-SQL) et REVOKE – révocation d'autorisations d'objet (Transact-SQL).

[Haut de la page]

Moteur d'indexation et de recherche en texte intégral pour les propriétés SQL Server

Les propriétés sont définies sur le Moteur d'indexation et de recherche en texte intégral par sp_fulltext_service. Vérifiez que l'instance du serveur de destination possède les paramètres requis pour ces propriétés. Pour plus d'informations sur ces propriétés, consultez FULLTEXTSERVICEPROPERTY (Transact-SQL).

Par ailleurs, si le composant d'analyseurs lexicaux et générateurs de formes dérivées ou le composant de filtres de recherche en texte intégral ont des versions différentes sur les instances du serveur d'origine et de destination, il est possible que les requêtes et l'index de texte intégral n'aient pas le même comportement. En outre, le dictionnaire des synonymes est stocké dans des fichiers spécifiques à l'instance. Vous devez transférer une copie de ces fichiers à un emplacement équivalent sur l'instance du serveur de destination ou les recréer sur la nouvelle instance.

Notes

Lorsque vous attachez une base de données SQL Server 2005 qui contient des fichiers catalogue de texte intégral à une instance de serveur SQL Server 2008, les fichiers catalogue sont attachés à partir de leur emplacement précédent avec les autres fichiers de base de données, les mêmes que dans SQL Server 2005. Pour plus d'informations, consultez Mise à niveau de la fonction de recherche en texte intégral.

Pour plus d'informations, consultez également :

[Haut de la page]

Travaux

Si la base de données repose sur les travaux de l'Agent SQL Server, vous devrez recréer ces derniers sur l'instance du serveur de destination. Les travaux dépendent de leur environnement. Si vous prévoyez de recréer un travail existant sur l'instance du serveur de destination, cette dernière devra peut-être être modifiée pour correspondre à l'environnement de ce travail sur l'instance du serveur d'origine. Les éléments d'environnement ci-après sont importants :

  • Connexion utilisée par le travail

    Pour créer ou exécuter des travaux de l'Agent SQL Server, vous devez d'abord ajouter toutes les connexions SQL Server requises par le travail à l'instance du serveur de destination. Pour plus d'informations, consultez Procédure : configurer un utilisateur pour qu'il puisse créer et gérer des travaux de l'Agent SQL Server (SQL Server Management Studio).

  • Compte de démarrage du service SQL Server Agent

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

    Le bon fonctionnement du compte de démarrage du service repose sur une configuration correcte du domaine, du système de fichiers et des autorisations de Registre. Qui plus est, un travail peut nécessiter une ressource réseau partagée qui doit être configurée pour le compte du service. Pour plus d'informations, consultez Configuration des comptes de service Windows.

  • Le service SQL Server Agent, qui est associé à une instance spécifique de SQL Server, possède sa propre ruche de Registre, et ses travaux dépendent généralement d'un ou de plusieurs paramètres de cette ruche de Registre. Pour qu'un travail fonctionne comme prévu, il a besoin de ces paramètres du Registre. Si vous utilisez un script pour recréer un travail dans un autre service SQL Server Agent, il est possible que son Registre ne dispose pas des paramètres corrects pour ce travail. Pour que les travaux recréés fonctionnent correctement sur une instance du serveur de destination, les services SQL Server Agent d'origine et de destination doivent posséder les mêmes paramètres de Registre.

    AttentionAttention

    La modification des paramètres du Registre sur le service SQL Server Agent de destination afin de gérer un travail recréé peut être problématique si les paramètres actuels sont requis par d'autres travaux. En outre, une modification incorrecte du Registre peut sérieusement endommager votre système. Avant que vous apportiez des modifications au Registre, nous vous recommandons de sauvegarder toutes les données importantes qui se trouvent sur l'ordinateur.

  • Proxys d'Agent SQL Server

    Un proxy d'Agent SQL Server définit le contexte de sécurité d'une étape de travail spécifiée. L'exécution d'un travail sur l'instance du serveur de destination implique la recréation manuelle de tous les proxys nécessaires sur cette instance. Pour plus d'informations, consultez Création de proxys d'Agent SQL Server et Dépannage des travaux multiserveurs qui utilisent des proxys.

Pour plus d'informations, consultez également :

Pour afficher des travaux existants et leurs propriétés

Pour créer un travail

Pour générer le script d'un travail existant

Meilleures pratiques pour utiliser un script afin de recréer un travail

Nous vous conseillons de commencer par générer le script d'un travail simple, en recréant le travail sur l'autre service SQL Server Agent et en exécutant le travail pour vérifier qu'il fonctionne comme prévu. Ces opérations vous permettront d'identifier d'éventuelles incompatibilités puis de les résoudre. Si un travail faisant l'objet d'un script ne fonctionne pas comme prévu dans son nouvel environnement, nous vous conseillons de créer un travail équivalent qui fonctionne correctement dans cet environnement.

[Haut de la page]

Connexions

Une ouverture de session sur 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 que 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 sur une instance serveur, ou l'est de façon incorrecte, ne peut pas se connecter à cette 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 lorsqu'une base de données a été restaurée, attachée ou copiée sur une autre instance de SQL Server.

Pour générer un script pour une partie ou l'intégralité des objets figurant dans la copie initiale de la base de données, vous pouvez utiliser l'Assistant Générer des scripts, et dans la boîte de dialogue Sélectionner les options de script, vous définissez l'option Créer un script des connexions à True. Pour plus d'informations, consultez Procédure : générer un script (SQL Server Management Studio).

Pour plus d'informations sur l'affichage des connexions SQL Server ainsi que sur la détection des utilisateurs orphelins sur une instance de serveur et la manière de les résoudre, consultez Dépannage des utilisateurs orphelins.

Notes

Pour plus d'informations sur la configuration des connexions d'une base de données mise en miroir, consultez Configuration des comptes de connexion pour la mise en miroir de bases de données et Gestion des connexions et des travaux après un basculement de rôle.

[Haut de la page]

Autorisations

Les types d'autorisations suivants peuvent être affectés par la mise à disponibilité d'une base de données sur une autre instance de serveur.

  • Autorisations GRANT, REVOKE ou DENY sur les objets système

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

Autorisations GRANT, REVOKE et DENY 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 affichages, sont stockées dans la base de données master et doivent être configurées sur l'instance du serveur de destination.

Pour générer un script pour une partie ou l'intégralité des objets figurant dans la copie initiale de la base de données, vous pouvez utiliser l'Assistant Générer des scripts, et dans la boîte de dialogue Sélectionner les options de script, vous définissez l'option Créer un script des autorisations au niveau objet à True. Pour plus d'informations, consultez Procédure : générer un script (SQL Server Management Studio).

Important

Si vous générez un script pour les connexions, les mots de passe ne sont pas chiffrés. Si vous disposez de connexions qui utilisent l'authentification SQL Server, vous devez modifier le script sur le serveur de destination.

Les objets système sont consultables dans l'affichage catalogue sys.system_objects. Les autorisations sur les objets système sont consultables dans l'affichage catalogue sys.database_permissions dans la base de données master. Pour plus d'informations sur l'interrogation de ces affichages catalogue et sur l'octroi d'autorisations sur les objets système, consultez GRANT – octroi d'autorisations d'objet système (Transact-SQL). Pour plus d'informations, consultez REVOKE – révocation d'autorisations d'objet système (Transact-SQL) et DENY – refus d'autorisations d'objet système (Transact-SQL).

Autorisations GRANT, REVOKE et DENY sur une instance de serveur

Les autorisations à l'échelle 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 plus d'informations sur les autorisations serveur d'une instance de serveur, interrogez l'affichage catalogue sys.server_permissions ; pour plus d'informations sur les principaux de serveur, interrogez l'affichage catalogue sys.server_principals ; et pour plus d'informations sur l'appartenance aux rôles de serveur, interrogez l'affichage catalogue sys.server_role_members.

Pour plus d'informations, consultez GRANT – octroi d'autorisations de serveur (Transact-SQL), REVOKE – révocation d'autorisations de serveur (Transact-SQL) et DENY – refus d'autorisations de serveur (Transact-SQL).

Autorisations au niveau serveur pour un certificat ou une clé asymétrique

Les autorisations au niveau serveur ne peuvent pas être accordées directement à un certificat ou à une clé asymétrique. Les autorisations au niveau serveur sont en fait accordées à une connexion mappée qui est créée exclusivement pour un certificat ou une clé asymétrique spécifique. Par conséquent, chaque certificat ou clé asymétrique qui nécessite des autorisations au niveau serveur doit posséder sa propre connexion mappée sur un certificat ou sa propre connexion mappée sur une clé asymétrique. Pour octroyer des autorisations au niveau serveur pour un certificat ou une clé asymétrique, accordez les autorisations à sa connexion mappée.

Notes

Une connexion mappée est utilisée uniquement pour l'autorisation du code signé à l'aide de la clé asymétrique ou du certificat correspondant. Les connexions mappées ne peuvent pas être utilisées pour l'authentification.

La connexion mappée et ses autorisations résident dans la base de données master. Si une clé asymétrique ou un certificat réside dans une base de données autre que la base master, vous devez les recréer dans la base master et les 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 du serveur de destination, les mapper à une connexion et accorder les autorisations au niveau serveur à la connexion.

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

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

Pour accorder des autorisations à la connexion mappée

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

[Haut de la page]

Paramètres de réplication

Si vous restaurez une sauvegarde d'une base de données répliquée sur un autre serveur ou dans 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 la totalité des abonnements et des publications une fois les sauvegardes restaurées. Pour faciliter ce processus, créez des scripts pour vos paramètres de réplication actuels, et également pour l'activation et la désactivation de la réplication. Pour plus d'informations, consultez Procédure : générer des scripts pour des objets de réplication (SQL Server Management Studio). Pour recréer facilement vos paramètres de réplication, copiez ces scripts et modifiez les références de nom de serveur afin qu'elles fonctionnent pour l'instance du serveur de destination.

Pour plus d'informations, consultez Sauvegarde et restauration de bases de données répliquées, Réplication et mise en miroir des bases de données et Réplication et copie des journaux de transaction.

[Haut de la page]

Applications Service Broker

De nombreux aspects d'une application Service Broker sont déplacés avec la base de données. Cependant, certains aspects doivent être recréés ou reconfigurés dans le nouvel emplacement. Pour plus d'informations, consultez Migration (Service Broker).

[Haut de la page]

Procédures de démarrage

Une procédure de démarrage est une procédure stockée qui est marquée pour l'exécution automatique et qui est exécutée à chaque démarrage de SQL Server. Si la base de données dépend de procédures de démarrage, celles-ci doivent être définies sur l'instance du serveur de destination et configurées pour s'exécuter automatiquement au démarrage.

Pour plus d'informations, consultez Exécution automatique des procédures stockées.

[Haut de la page]

Déclencheurs (au niveau du serveur)

Les déclencheurs DDL lancent des procédures stockées en réponse à différents événements DDL (Data Definition Language). Ces événements correspondent principalement à des instructions Transact-SQL qui commencent avec 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 lancer des déclencheurs DDL.

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

[Haut de la page]