Quelle est la différence entre l'utilisateur `dbo` et le propriétaire de la base de données stockée dans sys.databases
Nous avons récemment posé une question où l'utilisateur dbo dans une base de données avait un sid qui ne correspondait pas au owner_sid dans sys.databases. Je comprends en quoi le propriétaire de la base de données est différent des membres du rôle db_owner mais j'avais toujours pensé que l'utilisateur dbo était le véritable propriétaire de la base de données. N'est-ce pas le cas? Et si tel est le cas, existe-t-il de réelles différences entre dbo et ce qu'il y a dans sys.databases?
J'avais toujours pensé que l'utilisateur
dboétait le véritable propriétaire de la base de données.
C'est (ou du moins devrait être) correct. Le nom "dbo" de cet utilisateur ne change jamais, mais le SID sous-jacent le fait en fonction de la personne qui a créé la base de données ou de qui il a été défini via sp_changedbowner (bien que, y compris SQL Server 2005) ou ALTER AUTHORIZATION (à partir de SQL Server 2008).
Dans ces trois cas, le dossier en sys.databases est également modifié afin qu'ils soient synchronisés. Cependant, lors de la restauration d'une base de données, à partir d'un autre système ou de la même instance, mais à partir d'une base de données qui a été sauvegardée/détachée avant l'exécution de l'une de ces 2 commandes SQL pour changer de propriétaire, puis lors de la restauration ou de la connexion, il y aura être un décalage entre le owner_sid colonne dans sys.databases et le "dbo" sid dans sys.database_principals dans cette BD.
Pour autant que je sache, l'enregistrement dans sys.database_principals dans chaque base de données est le propriétaire réel , et le owner_sid colonne dans sys.databases est une question d'archivage/de commodité (similaire à la dénormalisation; sans sys.databases le système devrait effectuer des requêtes distinctes sur toutes les bases de données pour obtenir ces informations, à chaque fois demandé!) et la sécurité. Il sert à identifier une base de données restaurée/attachée potentiellement nuisible/non valide si ces enregistrements ne correspondent pas. Tentative d'accès aux assemblys SQLCLR marqués comme EXTERNAL_ACCESS ou UNSAFE ne se chargera pas si l'on a choisi de suivre la voie moins sécurisée d'activation de TRUSTWORTHY car cela dépend du SID "dbo" car il doit correspondre à un Login qui a soit le EXTERNAL ACCESS Assembly ou UNSAFE Assembly autorisation. Et quand il y a un décalage dans le SID entre ces deux vues de catalogue système, il ne peut pas être déterminé lequel utiliser, et utilisé comme drapeau rouge en cas de problème de sécurité potentiel. En fait, je teste cette condition dans le script d'installation pour SQL # pour alerter quelqu'un de faire le changement approprié, juste pour ne pas perdre de temps à le rechercher au cas où SQL Server se plaindrait à ce sujet à un moment donné.