Y a-t-il des inconvénients aux bases de données contenues?
SQL Server 2012 a introduit le concept de bases de données "contenues", où tout (enfin, presque tout) les besoins de la base de données est contenu dans la base de données elle-même. Cela offre de gros avantages lors du déplacement de bases de données entre des serveurs. Je voudrais donc savoir si cela devrait être ma stratégie par défaut lors de la conception d'une nouvelle base de données.
MSDN répertorie plusieurs inconvénients des bases de données contenues, et les plus importants sont le manque de prise en charge du suivi des modifications et de la réplication. Y en a-t-il d'autres? Si je ne vais pas utiliser ces fonctionnalités, y a-t-il une raison de ne pas utiliser les bases de données contenues?
Le but principal des bases de données contenues est de faciliter le portage de votre base de données vers un nouveau serveur sans beaucoup d'échafaudage autour. Dans cet esprit, je traiterai quelques problèmes potentiels qui rendront cette migration plus difficile - et la plupart tournent autour du fait que les bases de données contenues ne sont que partiellement contenues dans SQL Server 2012 (le confinement n'est pas réellement appliqué).
Chaînes de connexion
Les chaînes de connexion à une base de données contenue doit spécifier explicitement la base de données dans la chaîne de connexion. Vous ne pouvez plus compter sur la base de données par défaut de la connexion pour établir une connexion; si vous ne spécifiez pas de base de données, SQL Server ne va pas parcourir toutes les bases de données contenues et essayer de trouver une base de données où vos informations d'identification peuvent correspondre.
Requêtes inter-db
Même si vous créez le même utilisateur avec le même mot de passe dans deux bases de données contenues différentes sur le même serveur, votre application ne pourra pas effectuer de requêtes inter-bases de données. Les noms d'utilisateur et mots de passe peuvent être identiques, mais ils sont pas le même utilisateur. La raison de cela? Si vous avez contenu des bases de données sur un serveur hébergé, vous ne devriez pas être empêché d'avoir le même utilisateur contenu que quelqu'un d'autre qui se trouve utiliser le même serveur hébergé. Lorsque le confinement complet arrive (probablement dans la version après SQL Server 2012 jamais), les requêtes entre bases de données seront de toute façon absolument interdites. Je recommande fortement, fortement, fortement de ne pas créer de connexions au niveau du serveur avec le même nom que les utilisateurs de bases de données contenues et d'essayer d'éviter de créer le même nom d'utilisateur contenu dans les bases de données contenues. Si vous devez exécuter des requêtes qui touchent plusieurs bases de données contenues, faites-le en utilisant une connexion au niveau du serveur qui dispose des privilèges appropriés (vous pourriez penser que c'est sysadmin, mais pour les requêtes en lecture seule, c'est CONNECT ANY DATABASE et SELECT ALL USER SECURABLES).
Synonymes
La plupart des noms en 3 et 4 parties sont faciles à identifier et apparaissent dans un DMV. Cependant, si vous créez un synonyme qui pointe vers un nom en 3 ou 4 parties, ceux-ci n'apparaissent pas dans le DMV. Donc, si vous faites un usage intensif de synonymes, il est possible que vous manquiez certaines dépendances externes, ce qui peut provoquer des problèmes au moment où vous migrez la base de données vers un autre serveur. Je me suis plaint de ce problème, mais il a été fermé "par conception" et n'a pas survécu à la migration vers le nouveau système de rétroaction . Notez que le DMV manquera également les noms en 3 et 4 parties qui sont construits via SQL dynamique.
Politique de mot de passe
Si vous avez créé un utilisateur de base de données confiné sur un système sans stratégie de mot de passe en place, il peut être difficile de créer le même utilisateur sur un système différent qui dispose d'une stratégie de mot de passe. En effet, la syntaxe CREATE USER Ne prend pas en charge le contournement de la stratégie de mot de passe. J'ai déposé un bug à propos de ce problème, et il reste ouvert (et il n'a pas non plus survécu au déménagement lorsque Connect a été retiré). Et il me semble étrange que sur un système avec une stratégie de mot de passe en place, vous pouvez créer une connexion au niveau du serveur qui contourne facilement la stratégie, mais vous ne pouvez pas créer un utilisateur de base de données qui le fasse - même si cet utilisateur est intrinsèquement moins de risque pour la sécurité.
Assemblage
Comme nous ne pouvons plus compter sur le classement de tempdb, vous devrez peut-être modifier tout code qui utilise actuellement le classement explicite ou DATABASE_DEFAULT Pour utiliser à la place CATALOG_DEFAULT. Voir cet article BOL pour certains problèmes potentiels .
IntelliSense
Si vous vous connectez à une base de données contenue en tant qu'utilisateur contenu, SSMS ne prend pas entièrement en charge IntelliSense. Vous obtiendrez un soulignement de base pour les erreurs de syntaxe, mais pas de listes ou d'infobulles à saisie automatique et toutes les choses amusantes. J'ai déposé un bug sur ce problème, et il reste ouvert - et un de plus qui n'a pas survécu au déménagement.
Outils de données SQL Server
Si vous prévoyez d'utiliser SSDT pour le développement de bases de données, il n'existe actuellement pas de prise en charge complète des bases de données contenues. Ce qui signifie vraiment que la construction du projet n'échouera pas si vous utilisez une fonctionnalité ou une syntaxe qui rompt le confinement, car SSDT ne sait actuellement pas ce qu'est le confinement et ce qui pourrait le casser.
ALTER DATABASE
Lorsque vous exécutez une commande ALTER DATABASE À partir du contexte d'une base de données contenue, plutôt que ALTER DATABASE foo, Vous devrez utiliser ALTER DATABASE CURRENT - c'est ainsi que si la base de données est déplacée, renommée , etc. ces commandes n'ont besoin de rien savoir de leur contexte ou référence externe.
Quelques autres
Certaines choses que vous ne devriez probablement pas encore utiliser mais doivent néanmoins être mentionnées dans la liste des choses qui ne sont pas prises en charge ou sont obsolètes et ne doivent pas être utilisées dans les bases de données contenues:
- procédures numérotées
- procédures temporaires
- changements de classement dans les objets liés
- changer la capture des données
- suivi des modifications
- réplication
Cela dit, ce ne sont pas nécessairement des inconvénients à l'utilisation de bases de données contenues, ce ne sont que des problèmes que vous devez connaître et qui ne sont pas tous explicitement divulgués dans la documentation officielle.
Vous devrez également vous assurer que si une base de données contenue va être migrée, ou fait partie d'un groupe de disponibilité ou est mise en miroir, que tous les serveurs de destination potentiels ont l'option sp_configurecontained database authentication réglé sur 1.
Vous pouvez trouver cet article de blog utile, ainsi que celui-ci , même s'ils sont antérieurs à RTM.
Pour ceux qui souhaitent obtenir plus de détails sur les bases de données contenues, je peux leur recommander de lire cet article http://www.sqlshack.com/contained-databases-in-sql-server/
L'article met en évidence les principaux avantages/inconvénients de l'utilisation des bases de données contenues.
Inconvénients
Les bases de données partiellement contenues ne peuvent pas utiliser des fonctionnalités telles que la réplication, la capture de données modifiées, le suivi des modifications, les objets liés au schéma qui dépendent des fonctions intégrées avec des modifications de classement.
Avantages
D'un autre côté, comme déjà mentionné, l'utilisation de bases de données contenues présente certains avantages, tels que:
- Il est assez facile de déplacer la base de données d'un serveur à un autre,
car il n'y aura pas de problèmes d'utilisateurs orphelins - Les métadonnées sont stockées dans des bases de données contenues, ce qui les rend plus faciles et plus portables
- Il est possible d'avoir à la fois l'authentification SQL Server et Windows pour les utilisateurs de bases de données contenues
L'article aide également à:
- créer une nouvelle base de données contenue (en définissant le type de confinement comme partiel dans la page Options de SQL Server et en utilisant la requête T-SQL pour créer une base de données par la suite)
- connexion à la base de données contenue à l'aide de SQL Server Management Studio (il est nécessaire de spécifier le nom de la base de données contenue dans le paramètre de connexion)
- conversion d'une base de données existante en une base de données contenue
- travailler sur une base de données contenue et répertorier toutes les connexions de type utilisateur contenu
Un inconvénient est qu'un utilisateur de base de données confiné ne peut pas être contraint de modifier son propre mot de passe comme le pourraient les connexions (MUST_CHANGE). Les utilisateurs ne peuvent pas gérer leur propre mot de passe à moins que vous ne leur accordiez une autorisation de modification d'utilisateur et que vous leur indiquiez comment le modifier à l'aide d'une instruction SQL. Il n'est nulle part facile pour eux de le gérer via des interfaces utilisateur ou du moins je ne sais pas comment.
Remarque supplémentaire: j'ai trouvé l'utilisation de métadonnées inattendue et non documentée dans la clause "PIVOT" ET "UNPIVOT" que je pensais qu'elle ne devrait figurer que dans le catalogue système (sys.tables/sys.columns/etc). Comme indiqué dans msdn :
Dans une base de données contenue, le classement catalogue Latin1_General_100_CI_AS_WS_KS_SC . Ce classement est le même pour toutes les bases de données contenues sur toutes les instances de SQL Server et ne peut pas être modifié.
Mais ils n'ont pas mentionné que les clauses "PIVOT" ET "UNPIVOT" utilisent également les catalogues système comme mécanisme d'exécution. il génère donc une erreur de conflit de classement partout près de l'utilisation des clauses "PIVOT" ET "UNPIVOT" pendant la migration. voici une repro:
/*step1 create a table belongs to a contained database and populate some data*/
create table dbo.test1 (col1 varchar(100),col2 varchar(100))
insert dbo.test1 values('a','x')
insert dbo.test1 values('b','y')
insert dbo.test1 values('c','z')
/*step2 lets see its collation you will see it is correctly as same as its (contained) database */
select name,collation_name from sys.columns where object_name(object_id) = 'test1'
/*step3 reproduce an unpivoted column*/
select * into dbo.test2
from (select * from dbo.test1) a unpivot (val for col in (col1,col2)) a
/*step4 lets check its collation you will see the column specified at "FOR" clause is created as Latin1_General_100_CI_AS_KS_WS_SC */
select name,collation_name from sys.columns where object_name(object_id) = 'test2'
/*step5 make use of the unpivoted table without awareness will cause an error*/
select val + ' = ' + col from dbo.test2
/*step6 clean up*/
drop table dbo.test1
drop table dbo.test2
vous pouvez également voir que les articles sur la base de données contenue sont pour la plupart incomplets. donc décider de l'utiliser nécessite une très bonne improvisation.