Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :SQL Server
Base de données Azure SQL
Azure SQL Managed Instance
Une base de données autonome est une base de données qui est isolée d’autres bases de données et de l’instance de SQL Server qui héberge cette base de données. SQL Server aide l'utilisateur à isoler sa base de données de l'instance de 4 manières différentes.
Une grande partie des métadonnées qui décrivent une base de données est conservée dans la base de données. (En plus ou en remplacement de la conservation des métadonnées dans la base de données MASTER.)
Toutes les métadonnées sont définies à l'aide du même classement.
L'authentification utilisateur peut être exécutée par la base de données, ce qui réduit la dépendance des bases de données sur les connexions de l'instance de SQL Server.
L'environnement SQL Server (DMV, XEvents, etc.) signale des informations relatives à la relation contenant-contenu et peut interagir sur celles-ci.
Certaines fonctionnalités de bases de données partiellement autonomes, telles que le stockage des métadonnées dans la base de données, s'appliquent à toutes les bases de données SQL Server. Certains avantages des bases de données partiellement autonomes, tels que l'authentification de niveau base de données et le classement de catalogue, doivent être activés pour pouvoir être disponibles. Le confinement partiel est activé à l’aide des instructions CREATE DATABASE et ALTER DATABASE, ou à l’aide de SQL Server Management Studio. Pour plus d'informations sur l’activation du confinement partiel de la base de données, consultez Migrer vers une base de données partiellement confinée.
Concepts relatifs aux bases de données partiellement autonomes
Une base de données autonome complète inclut tous les paramètres et métadonnées requis pour définir la base de données ; sa configuration ne dépend pas de l'instance du moteur de base de données SQL Server où la base de données est installée. Dans les versions antérieures de SQL Server, la séparation d'une base de données de l'instance de SQL Server pouvait être fastidieuse et nécessiter une connaissance détaillée de la relation entre la base de données et l'instance de SQL Server. Les bases de données partiellement autonomes simplifient la séparation d'une base de données de l'instance de SQL Server et des autres bases de données.
La base de données contenue prend en charge des fonctionnalités liées au modèle de contenance. Toute entité définie par l'utilisateur qui repose uniquement sur des fonctions présentes dans la base de données est considérée comme entièrement contenue. Toute entité définie par l'utilisateur qui dépend de fonctions situées en dehors de la base de données est considérée comme non contenue. (Pour plus d’informations, consultez la section Confinement, plus loin dans cette rubrique.)
Les termes suivants s'appliquent au modèle de base de données autonome.
Limite de base de données
Limite entre une base de données et l'instance de SQL Server. Limite entre une base de données et d'autres bases de données.
Contenu
Élément qui existe entièrement dans la limite de base de données.
Non contenu
Élément qui dépasse la limite de base de données.
Base de données non autonome
Base de données dont la relation contenant-contenu a la valeur NONE. Toutes les bases de données dans des versions antérieures à SQL Server 2012 (11.x) sont non autonomes. Par défaut, toutes les bases de données SQL Server 2012 (11.x) et de versions ultérieures ont une relation contenant-contenu définie avec la valeur NONE.
Base de données partiellement autonome
Une base de données partiellement autonome est une base de données autonome qui peut autoriser certaines fonctionnalités qui dépassent la limite de base de données. SQL Server permet de déterminer si la limite de la relation contenant-contenu est dépassée.
Utilisateur isolé
Il existe deux types d'utilisateurs pour les bases de données autonomes.
Utilisateur de base de données autonome avec mot de passe
Les utilisateurs de base de données autonome avec mots de passe sont authentifiés par la base de données. Pour plus d’informations, voir Utilisateurs de base de données autonome - Rendre votre base de données portable.
Principaux Windows
Les utilisateurs Windows autorisés et les membres de groupes Windows autorisés peuvent se connecter directement à la base de données et n'ont pas besoin de connexions dans la base de données master . La base de données fait confiance au processus d'authentification effectué par Windows.
Les utilisateurs, selon les connexions dans la base de données master, peuvent bénéficier de l'accès à une base de données autonome, mais cela créerait une dépendance sur l'instance SQL Server. Par conséquent, la création d’utilisateurs à partir de connexions nécessite un confinement partiel.
Important
L'activation de bases de données autonomes partielles transfère le contrôle de l'accès à l'instance de SQL Server aux propriétaires de la base de données. Pour plus d'informations, consultez Meilleures pratiques de sécurité recommandées avec les bases de données autonomes.
Limite de base de données
Comme les bases de données partiellement autonomes séparent les fonctionnalités de base de données de celles de l'instance, une frontière clairement définie existe entre ces deux éléments, appelée limite de base de données.
À l'intérieur de la limite de base de données se trouve le modèle de base de données, où les bases de données sont développées et gérées. Les entités situées dans la base de données sont, par exemple, des tables système telles que sys.tables, des utilisateurs de base de données autonome avec mots de passe et des tables utilisateur dans la base de données actuelle référencées par un nom en deux parties.
En dehors de la limite de base de données se trouve le modèle de gestion, qui se rapporte aux fonctions et à la gestion au niveau de l’instance. Les entités situées en dehors de la limite de base de données sont, par exemple, des tables système telles que sys.endpoints, des utilisateurs mappés aux connexions et des tables utilisateur dans une autre base de données référencées par un nom en trois parties.
Confinement
Les entités utilisateur qui résident entièrement dans la base de données sont considérées comme autonomes. Toutes les entités qui résident en dehors de la base de données, ou qui s'appuient sur une interaction avec des fonctions situées en dehors de la base de données, sont considérées sans relation contenant-contenu.
En général, les entités utilisateur se répartissent dans les catégories de conteneur suivantes :
Entités utilisateur entièrement contenues (celles qui ne franchissent jamais les limites de la base de données), par exemple sys.indexes. Tout code qui utilise ces fonctionnalités ou tout objet qui fait référence uniquement à ces entités est également entièrement contenu.
Entités utilisateur non contenues (celles qui franchissent la limite de la base de données), par exemple sys.server_principals ou un principal au niveau du serveur (login) proprement dit. Tout code qui utilise ces entités ou toute fonction qui les référence est sans relation contenant-contenu.
Base de données partiellement contenue
La fonctionnalité de base de données autonome est actuellement disponible uniquement en mode partiellement autonome. Une base de données partiellement contenue est une base de données contenue qui autorise l’utilisation de fonctionnalités non contenues.
Utilisez les vues sys.dm_db_uncontained_entities et sys.sql_modules (Transact-SQL) pour retourner des informations sur des objets ou des fonctionnalités sans relation contenant-contenu. En déterminant l'état de la relation contenant-contenu des éléments de votre base de données, vous pouvez découvrir les objets ou les fonctionnalités qui doivent être remplacés ou modifiés pour promouvoir la relation contenant-contenu.
Important
Étant donné que certains objets ont pour paramètre de relation contenant-contenu NONEpar défaut, cette vue peut retourner des faux positifs.
Le comportement des bases de données partiellement autonomes est très différent de celui des bases de données non autonomes en termes de classement. Pour plus d'informations sur les problèmes de classement, consultez Classements des bases de données autonomes.
Avantages de l'utilisation de bases de données partiellement autonomes
Les problèmes et les complications associés aux bases de données non autonomes peuvent être résolus à l'aide d'une base de données partiellement autonome.
Déplacement de base de données
Un des problèmes qui se produit lors du déplacement de bases de données est que certaines informations importantes peuvent être indisponibles lorsqu'une base de données est déplacée d'une instance à l'autre. Par exemple, les informations de connexion sont stockées dans l'instance, et non dans la base de données. Lorsque vous déplacez une base de données non autonome d'une instance vers une autre instance SQL Server, ces informations sont abandonnées. Vous devez identifier les informations manquantes et les déplacer avec votre base de données vers la nouvelle instance de SQL Server. Le processus peut nécessiter du temps et s'avérer difficile.
La base de données partiellement autonome peut stocker des informations importantes en son sein afin de conserver ces informations après son déplacement.
Remarque
Une base de données partiellement autonome peut fournir de la documentation décrivant ces fonctionnalités utilisées par une base de données qui ne peut pas être séparée de l'instance. Cela inclut une liste d'autres bases de données interdépendantes, des paramètres système dont la base de données a besoin mais qu'elle ne peut pas contenir, et ainsi de suite.
Avantages des utilisateurs de bases de données autonomes avec Always On
En réduisant les dépendances vis-à-vis de l’instance de SQL Server, les bases de données partiellement autonomes peuvent être utiles lors d’un basculement lorsque vous utilisez les groupes de disponibilité Always On.
La création d'utilisateurs contenus permet à l'utilisateur de se connecter directement à la base de données contenue. Il s’agit d’une fonctionnalité très importante dans les scénarios de haute disponibilité et de récupération d’urgence, notamment dans le cadre d’une solution Always On. Si les utilisateurs sont des utilisateurs contenus, en cas de basculement, les utilisateurs pourront se connecter au secondaire sans créer de comptes de connexion sur l’instance qui héberge le secondaire. Ceci constitue un avantage immédiat. Pour plus d’informations, consultez Vue d’ensemble des groupes de disponibilité Always On (SQL Server) et Conditions préalables requises, restrictions et recommandations pour les groupes de disponibilité Always On (SQL Server).
Développement initial de la base de données
Étant donné qu'un développeur ne peut pas savoir où une nouvelle base de données sera déployée, diminuer les impacts environnementaux déployés sur la base de données réduit le travail et les difficultés du développeur. Dans le modèle sans relation contenant-contenu, le développeur doit prendre en considération les impacts environnementaux potentiels sur la nouvelle base de données et le nouveau programme. Toutefois, en utilisant des bases de données partiellement contenues, les développeurs peuvent détecter les impacts du niveau de l’instance sur la base de données ainsi que les problèmes liés au niveau de l’instance pour le développeur.
Administration de bases de données
La gestion des paramètres de base de données dans la base de données, plutôt que dans la base de données master, permet à chaque propriétaire de la base de données d'avoir plus de contrôle sur sa base de données, sans donner au propriétaire de la base de données l'autorisation sysadmin .
Limites
Les bases de données partiellement contenues ne prennent pas en charge les fonctionnalités suivantes.
Réplication, capture des changements de données ou suivi des modifications.
Procédures numérotées
les objets liés par schéma qui dépendent de fonctions intégrées avec des modifications de classement ;
Changement de liaison résultant de modifications des règles de classement, y compris les références à des objets, des colonnes, des symboles ou des types.
Avertissement
Les procédures stockées temporaires sont actuellement autorisées. Étant donné que les procédures stockées temporaires rompent le confinement, elles ne devraient pas être prises en charge dans les futures versions des bases de données contenues.
Identification du confinement de la base de données
Il existe deux outils qui permettent d’identifier l’état de confinement de la base de données. sys.dm_db_uncontained_entities (Transact-SQL) est une vue qui affiche toutes les entités potentiellement non contenues dans la base de données. L'événement database_uncontained_usage se produit lorsqu'une entité non contenue est effectivement identifiée lors de l'exécution.
sys.dm_db_uncontained_entities
Cette vue affiche toutes les entités de la base de données qui peuvent être non contenues, par exemple celles qui franchissent la limite de la base de données. Cela inclut les entités d'utilisateur qui peuvent utiliser des objets à l'extérieur du modèle de base de données. Cependant, comme la relation contenant-contenu de certaines entités (par exemple, celles utilisant SQL dynamique) ne peut être déterminée qu'au moment de l'exécution, la vue peut afficher des entités qui ne sont pas réellement sans relation contenant-contenu. Pour plus d’informations, consultez sys.dm_db_uncontained_entities (Transact-SQL).
événement database_uncontained_usage
Ce XEvent se produit chaque fois qu'une entité sans relation contenant-contenu est identifiée lors de l'exécution. Cela inclut des entités provenant du code client. Ce XEvent survient uniquement pour les entités réelles non contenues. Toutefois, l'événement ne se produit qu'au moment de l'exécution. Par conséquent, toutes les entités utilisateur non autonomes que vous n’avez pas exécutées ne seront pas identifiées par cet XEvent
Voir aussi
Fonctionnalités modifiées (base de données autonome)
Interclassements des bases de données autonomes
Meilleures pratiques de sécurité recommandées avec les bases de données autonomes
Migrer vers une base de données partiellement autonome
Utilisateurs de base de données autonome - Rendre votre base de données portable