Exporter (0) Imprimer
Développer tout
Développer Réduire
Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.
Traduction
Source

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)

État de la rubrique : certaines informations de cette rubrique constituent une documentation préliminaire et peuvent faire l'objet de modifications dans les versions à venir. Ces informations préliminaires décrivent les nouvelles fonctionnalités ou les modifications apportées à des fonctionnalités existantes de Microsoft SQL Server 2014.

Cette rubrique concerne les situations suivantes :

  • Configuration des réplicas de disponibilité d'un groupe de disponibilité Groupes de disponibilité AlwaysOn.

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

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 Options de configuration du serveur (SQL Server).

[Haut de la page]

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 Informations d'identification (moteur de base de données).

Remarque Remarque

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]

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

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

[Haut de la page]

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.

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

[Haut de la page]

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 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 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 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'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 = 'password'. 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 Configurer une base de données miroir chiffrée.

Pour plus d'informations, consultez également :

[Haut de la page]

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

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.

É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 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 mises en 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. En outre, Database_A doit contenir un itinéraire de transport TCP non mis en miroir vers Service_B, qui, à la différence d'un itinéraire local, reste valide après le 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.

[Haut de la page]

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

Important 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 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]

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.

Remarque Remarque

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 2014, 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]

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

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

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

  • 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éer un proxy de SQL Server Agent 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. 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]

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 attribuez à l'option Créer un script des connexions la valeur True.

[Haut de la page]

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

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

Remarque 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 Hiérarchie de chiffrement.

[Haut de la page]

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

[Haut de la page]

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.

[Haut de la page]

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.

[Haut de la page]

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]

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft