Nous avons récemment eu une question venir où l'utilisateur dbodans une base de données avait une sidqui ne correspond pas à la owner_siddans sys.databases. Je comprends en quoi le propriétaire de la base de données est différent des membres du rôle, db_ownermais j'avais toujours pensé que l'utilisateur dboétait le propriétaire réel de la base de données. N'est-ce pas le cas? Et si oui, y a-t-il de réelles différences entre dboet de quoi s'agit-il sys.databases?
Réponses:
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 change en fonction de la personne qui a créé la base de données ou qui a été définie pour être via sp_changedbowner (bien que, y compris SQL Server 2005) ou ALTER AUTHORIZATION (à partir de SQL Server 2008).
Dans ces trois cas, l'enregistrement dans sys.databasesest é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 le propriétaire, puis lors de la restauration ou de la connexion, il y aura un décalage entre la owner_sidcolonne sys.databaseset le « dbo » siddans le fait sys.database_principalsque DB.
Pour autant que je sache, l'enregistrement dans sys.database_principalschaque base de données est le véritable propriétaire, et la owner_sidcolonne dans sys.databasesest une question de conservation / commodité d'enregistrement (similaire à la dénormalisation; sans sys.databasesle système, il faudrait effectuer des requêtes distinctes sur toutes les bases de données pour obtenir cette information, 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 étant EXTERNAL_ACCESSou UNSAFEne se chargeant pas si l’on a choisi d’opter pour la voie d’activation la moins sécurisée TRUSTWORTHYcar elle dépend du SID «dbo» car elle doit correspondre à une connexion qui possède le EXTERNAL ACCESS ASSEMBLYouUNSAFE ASSEMBLYautorisation. 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 de SQL # pour alerter quelqu'un pour effectuer le changement approprié, juste pour qu'il n'ait pas à perdre de temps à le rechercher au cas où SQL Server s'en plaindrait à un moment donné.