Partager via


Bases de données autonomes

Unebase de données autonome est une base de données isolée d’autres bases de données et de l’instance de SQL Server qui héberge la base de données. SQL Server 2014 aide l’utilisateur à isoler sa base de données de l’instance de 4 façons.

  • La plupart des métadonnées qui décrivent une base de données sont conservées dans la base de données. (En plus ou au lieu de conserver les 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 effectué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.

  • Les rapports de l’environnement SQL Server (DMV, XEvents, etc.) peuvent agir sur les informations de confinement.

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 2014. Certains avantages des bases de données partiellement autonomes, telles que l’authentification au niveau de la base de données et le classement du catalogue, doivent être activés avant qu’ils ne soient disponibles. La contenance partielle est activée à l’aide des déclarations CREATE DATABASE et ALTER DATABASE, ou en utilisant SQL Server Management Studio. Pour plus d’informations sur l’activation de l’autonomie partielle de la base de données, consultez Migrer vers une base de données partiellement autonome.

Cette rubrique contient les sections suivantes.

Concepts de bases de données partiellement confinées

Une base de données entièrement autonome inclut tous les paramètres et métadonnées nécessaires pour définir la base de données et n’a aucune dépendance de configuration sur l’instance du moteur de base de données SQL Server où la base de données est installée. Dans les versions précédentes de SQL Server, la séparation d’une base de données de l’instance de SQL Server peut prendre du temps et avoir besoin d’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 facilitent la séparation d’une base de données de l’instance de SQL Server et d’autres bases de données.

La base de données concernant le confinement prend en compte les caractéristiques relatives au confinement. Toute entité définie par l’utilisateur qui s’appuie uniquement sur les fonctions qui résident dans la base de données est considérée comme entièrement autonome. Toute entité définie par l’utilisateur qui s’appuie sur des fonctions qui résident en dehors de la base de données est considérée comme non détenue. (Pour plus d’informations, consultez la section Contenant-contenu 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 détenu
Élément qui traverse la limite de base de données.

Base de données non autonome
Base de données dont le confinement est défini sur NONE. Toutes les bases de données des versions antérieures à SQL Server 2012 ne sont pas autonomes. Par défaut, toutes les bases de données SQL Server 2012 et ultérieures ont un conteneur de contenu défini sur NONE.

Base de données partiellement contenue
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 la base de données. SQL Server inclut la possibilité de déterminer quand la limite de confinement est franchie.

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

  • Principaux Windows

    Les utilisateurs et membres Autorisés de Windows 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 approuve l’authentification par Windows.

Les utilisateurs basés sur des connexions dans la base de données master peuvent être autorisés à accéder à 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 basée sur les identifiants voir commentaire pour les bases de données partiellement contenues.

Important

L'activation de bases de données partiellement autonomes délègue le contrôle de l'accès à l'instance de SQL Server aux propriétaires des bases 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
Étant donné que les bases de données partiellement autonomes séparent les fonctionnalités de base de données de celles de l’instance, il existe une ligne clairement définie entre ces deux éléments appelés la limite de base de données.

À l’intérieur de la limite de base de données est le modèle de base de données, où les bases de données sont développées et gérées. Parmi les exemples d’entités situées à l’intérieur de la base de données figurent des tables système telles que sys.tables, des utilisateurs de base de données contenant des 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, il s’agit du modèle de gestion, qui se rapporte aux fonctions et à la gestion au niveau de l’instance. Parmi les exemples d’entités situées en dehors de la limite de base de données, citons les tables système telles que sys.endpoints, les utilisateurs mappés aux connexions et les tables utilisateur d’une autre base de données référencée 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 contenues. Toutes les entités qui résident en dehors de la base de données, ou qui s’appuient sur l’interaction avec des fonctions en dehors de la base de données, sont considérées comme non liées.

En général, les entités utilisateur appartiennent aux catégories suivantes d’isolement :

  • Entités utilisateur entièrement autonomes (celles qui ne dépassent jamais la limite de base de données), par exemple sys.indexes. Tout code qui utilise ces fonctionnalités ou tout objet qui référence uniquement ces entités est également entièrement contenu.

  • Les entités utilisateur non contenues (celles qui franchissent la frontière de la base de données), par exemple sys.server_principals ou un principal de serveur (identifiant) lui-même. Tout code qui utilise ces entités ou toute fonction qui fait référence à ces entités ne sont pas contenus.

Base de données partiellement contenue

La fonctionnalité de base de données contenue est actuellement disponible uniquement dans un état partiellement contenu. Une base de données partiellement autonome est une base de données autonome qui permet l’utilisation de fonctionnalités non contenues.

Utilisez la vue sys.dm_db_uncontained_entities et sys.sql_modules (Transact-SQL) pour retourner des informations sur les objets ou fonctionnalités non liés. En déterminant l’état de l’isolement des éléments de votre base de données, vous pouvez découvrir quels objets ou fonctionnalités doivent être remplacés ou modifiés pour promouvoir l’endiguement.

Important

Étant donné que certains objets ont un paramètre de confinement par défaut de NONE, cette vue peut retourner des faux positifs.

Le comportement des bases de données partiellement autonomes diffère le plus de celui des bases de données non autonomes en ce qui concerne le classement. Pour plus d’informations sur les problèmes de collation, consultez Collations de base de données contenue.

Avantages de l’utilisation de bases de données partiellement autonomes

Il existe des problèmes et des complications associés aux bases de données non autonomes qui peuvent être résolues à l’aide d’une base de données partiellement autonome.

Déplacement de base de données

L’un des problèmes qui se produisent 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 à une autre. Par exemple, les informations de connexion sont stockées dans l’instance au lieu de la base de données. Lorsque vous déplacez une base de données non autonome d’une instance vers une autre instance de SQL Server, ces informations sont laissées derrière elles. Vous devez identifier les informations manquantes et les déplacer avec votre base de données vers la nouvelle instance de SQL Server. Ce processus peut être difficile et fastidieux.

La base de données partiellement contenue peut stocker des informations importantes, ce qui lui permet de conserver ces informations après son déplacement.

Remarque

Une base de données partiellement autonome peut fournir une documentation décrivant les 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 liées entre elles, les paramètres système requis par la base de données, mais qui ne peuvent pas être contenus, et ainsi de suite.

Avantage des utilisateurs de base de données autonome avec AlwaysOn

En réduisant les liens avec l’instance de SQL Server, les bases de données partiellement autonomes peuvent être utiles pendant le basculement lorsque vous utilisez des 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, comme dans une solution AlwaysOn. Si les utilisateurs sont des utilisateurs autonomes, en cas de basculement, les utilisateurs peuvent se connecter à la base de données secondaire sans créer de connexions sur l’instance hébergeant le serveur secondaire. Cela offre un avantage immédiat. Pour plus d’informations, consultez Vue d’ensemble des groupes de disponibilité AlwaysOn (SQL Server) et prérequis, restrictions et recommandations pour les groupes de disponibilité AlwaysOn (SQL Server).

Développement initial de base de données

Étant donné qu’un développeur ne sait peut-être pas où une nouvelle base de données sera déployée, limiter les impacts environnementaux déployés sur la base de données réduit le travail et la préoccupation du développeur. Dans le modèle non autonome, le développeur doit envisager les impacts environnementaux possibles sur la nouvelle base de données et le nouveau programme en conséquence. Toutefois, en utilisant des bases de données partiellement contenues, les développeurs peuvent détecter les impacts au niveau de l'instance sur la base de données et les préoccupations 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, au lieu de la base de données master, permet à chaque propriétaire de base de données d’avoir plus de contrôle sur sa base de données, sans accorder l’autorisation sysadmin du propriétaire de la base de données.

Limites

Les bases de données partiellement restreintes n’autorisent pas les fonctionnalités suivantes.

  • Les bases de données partiellement autonomes ne peuvent pas utiliser la réplication, la capture de données modifiées ou le suivi des modifications.

  • Procédures numérotées

  • Objets liés au schéma qui dépendent des fonctions intégrées avec des modifications de classement

  • Modification de liaison résultant des modifications de classement, y compris les références aux objets, aux colonnes, aux symboles ou aux types.

  • Réplication, capture de données modifiées et suivi des modifications.

Avertissement

Les procédures stockées temporaires sont autorisées pour le moment. Étant donné que les procédures stockées temporaires violent la contenance, elles ne sont pas censées être prises en charge dans les futures versions de la base de données contenue.

Identification du confinement de la base de données

Il existe deux outils permettant d’identifier l’état de l’isolement 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 détenue réelle est identifiée au moment de l’exécution.

sys.dm_db_uncontained_entities

Cette vue montre toutes les entités de la base de données qui ont le potentiel d’être non conservées, telles que celles qui dépassent la limite de la base de données. Cela inclut les entités utilisateur qui peuvent utiliser des objets en dehors du modèle de base de données. Toutefois, étant donné que l’isolement de certaines entités (par exemple, certaines d’entre elles utilisent SQL dynamique) ne peut pas être déterminé avant l'exécution, la vue peut afficher certaines entités qui ne sont pas réellement des entités non contenues. Pour plus d’informations, consultez sys.dm_db_uncontained_entities (Transact-SQL).

événement utilisation_non_contenue_de_base_de_données

Cet événement XEvent se produit chaque fois qu’une entité non détenue est identifiée au moment de l’exécution. Cela inclut les entités qui ont leur origine dans le code client. Cet événement XEvent se produit uniquement pour les entités non détenues réelles. Toutefois, l’événement se produit uniquement au moment de l’exécution. Par conséquent, toutes les entités utilisateur non conservées que vous n’avez pas exécutées ne seront pas identifiées par ce XEvent

Fonctionnalités modifiées (base de données contenue)

Classements de base de données contenus

Meilleures pratiques de sécurité recommandées avec les bases de données autonomes

Migrer vers une base de données partiellement autonome