Gérer les métadonnées lors de la mise à disposition d’une base de données sur un autre serveur

  • Article

S’applique à :SQL Server

Cet article est utile dans les cas suivants :

  • lors de la configuration des réplicas de disponibilité d'un groupe de disponibilité des groupes de disponibilité Always On ;

  • 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.

  • lors de l'exécution d'une mise à niveau du moteur de base de données à l'aide de la méthode Migrer vers une nouvelle installation ;

  • lors de la migration de bases de données vers Azure SQL (machine virtuelle ou Managed Instance).

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 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 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 la base de données master.

Quand 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 ni de restaurer la base de données sur le nouveau système. La base de données ne fonctionne pas comme prévu, 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 cet article résume les problèmes susceptibles d’affecter une base de données qui est 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 consulter un résumé, sélectionnez le lien correspondant à l'élément.

Paramètres de configuration du serveur

SQL Server 2005 (9.x) 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 désactivation, consultez Options de configuration de serveur (SQL Server).

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 sont composées d'un nom de connexion Windows et d'un mot de passe.

Pour plus d'informations sur cette fonctionnalité, consultez Identifiants (moteur de base de données).

Remarque

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

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 sur 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).

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 l’activation du chaînage, consultez Chaînage des propriétés des bases de données croisées (option de configuration de serveur).

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

Propriété de la base de données

Lorsqu'une base de données est restaurée sur un autre ordinateur, le compte de 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 du 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 sur des serveurs distants. Pour plus d'informations sur ces fonctionnalités, consultez Serveurs liés (moteur de base de données).

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 à la fois dans la base de données et dans 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 tout d'abord de déchiffrer la clé principale de base de données avec la clé principale de service de l'instance. Si ce déchiffrement échoue, SQL Server recherche dans le Credential Store les informations d'identification de la 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 ensuite 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'identifiants. 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 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 l’activation du déchiffrement automatique de la clé principale d’une base de données miroir, consultez Configurer une base de données miroir chiffrée.

Pour plus d'informations, consultez également :

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 du serveur, utilisez sp_addmessage pour ajouter ces messages définis par l’utilisateur sur l’instance du serveur de destination.

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 msdb. Par conséquent, si une application de base de données repose sur une notification d’événement 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, voir Event Notifications.

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 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.

Événements WMI (Windows Management Instrumentation)

Le fournisseur WMI pour les événements de serveur 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.

Remarque

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 de notifications d'événements entre bases de données qui implique une base de données mise en miroir est distante, par définition, car la base de données mise en miroir peut basculer. Service Broker assure une prise en charge spéciale des bases de données miroir, sous la forme d'itinéraires 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 miroir, vous rendez le routage Service Broker capable de reconnaître la mise en miroir de bases de données. Les itinéraires 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 miroir vers 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.

Procédures stockées étendues

Important

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 l’intégration CLR à la place.

Les procédures stockées étendues sont programmées à l'aide de l'API Extended Stored Procedure de 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 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.

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 Autorisations d'objet GRANT (Transact-SQL), Autorisations d'objet DENY (Transact-SQL) et Autorisations d'objet REVOKE (Transact-SQL).

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 de 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 des analyseurs lexicaux et générateurs de formes dérivées ou le composant des 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.

Remarque

Quand vous attachez une base de données SQL Server 2005 (9.x) qui contient des fichiers catalogue de texte intégral à une instance de serveur SQL Server, 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 (9.x). Pour plus d’informations, consultez Mise à niveau de la fonction de recherche en texte intégral.

Pour plus d'informations, consultez également :

Tâches

Si la base de données repose sur les travaux de SQL Server Agent, 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 SQL Server Agent, vous devez d'abord ajouter tous les comptes de connexion SQL Server requis par la tâche à l'instance du serveur de destination. Pour plus d’informations, consultez Configurer un utilisateur de manière à créer et à gérer des travaux de l’Agent SQL Server.

  • 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 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 façon de sélectionner et de modifier le compte de démarrage du service, consultez Sélectionner un compte pour le service SQL Server Agent.

    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 Configurer les comptes de service Windows et les autorisations.

  • SQL Server Agent, qui est associé à une instance spécifique de SQL Server, possède son propre Hive de Registre, et ses travaux dépendent généralement d'un ou de plusieurs paramètres de ce Hive 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.

    Attention

    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.

  • Proxy SQL Server Agent

    Un proxy SQL Server Agent 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éer un proxy d’Agent SQL Server et Résoudre les problèmes liés aux 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

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. Vous pourrait ainsi identifier les incompatibilités éventuelles et essayer 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.

Connexions

L'ouverture d'une session sur une instance de SQL Server nécessite un compte de connexion SQL Server valide. Ce compte de connexion est utilisé 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 le compte de connexion SQL Server n'est pas défini sur une instance de 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 attribuez à l'option Créer un script des connexions la valeur True.

Remarque

Pour plus d'informations sur la configuration des connexions pour une base de données mise en miroir, consultez Configurer des comptes de connexion pour la mise en miroir de bases de données ou les groupes de disponibilité Always On (SQL Server) et Gestion des connexions et des travaux après un basculement de rôle (SQL Server).

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 vues, 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 attribuez à l’option Créer un script des autorisations au niveau objet la valeur True.

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 la 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 de la base de données master. Pour plus d'informations sur l'interrogation de ces affichages catalogue et l'octroi d'autorisations sur les objets système, consultez Autorisations d'objet système GRANT (Transact-SQL). Pour plus d'informations, consultez Autorisations d'objet système REVOKE (Transact-SQL) et Autorisations d'objet système DENY (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_principalset 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 Autorisations de serveur GRANT (Transact-SQL), Autorisations de serveur REVOKE (Transact-SQL) et Autorisations de serveur DENY (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.

Remarque

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 Encryption Hierarchy.

Propriété Trustworthy

La propriété de base de données TRUSTWORTHY permet d’indiquer si cette instance de SQL Server fait confiance à la base de données et à son contenu. Quand une base de données est attachée, par défaut et pour des raisons de sécurité, cette option est définie sur OFF, même si elle était définie sur ON sur le serveur d’origine. Pour plus d'informations sur cette propriété, consultez TRUSTWORTHY, propriété de base de données. Pour savoir comment activer cette option (ON), consultez ALTER DATABASE (Transact-SQL).

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 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 Sauvegarder et restaurer des bases de données répliquées, Mise en miroir de bases de données et réplication (SQL Server) et Copie des journaux de transaction et réplication (SQL Server).

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. Par défaut et pour des raisons de sécurité, quand une base de données est attachée à partir d’un autre serveur, les options pour is_broker_enabled, is_honor_broker_priority_on sont définies sur OFF. Pour plus d'informations sur l'activation de ces options (ON), consultez ALTER DATABASE (Transact-SQL).

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.

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 activer des déclencheurs DDL.

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

Voir aussi

Bases de données autonomes
Copier des bases de données sur d’autres serveurs
Attacher et détacher 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)
Migrer vers une nouvelle installationVue d'ensemble de la migration : SQL Server vers SQL Server sur ordinateurs virtuels Azure