Яка різниця між користувачем `dbo` та власником бази даних, що зберігається в sys.databases

Нещодавно ми мали питання придумати , де користувач dboв базі даних мав , sidщо не збігається з owner_sidін sys.databases. Я розумію, чим власник бази даних відрізняється від членів ролі, db_ownerале я завжди вважав, що користувач dboє фактичним власником бази даних. Хіба це не так? І якщо так, чи існують якісь реальні відмінності між dboтим, що відбувається sys.databases?

Я завжди думав, що користувач dboє фактичним власником бази даних.

Це (або принаймні повинно бути) правильно. Ім'я "dbo" цього Користувача ніколи не змінюється, але базовий SID залежить від того, хто створив базу даних, або для кого вона була встановлена ​​через sp_changedbowner (хоча і в тому числі, SQL Server 2005) або ВЗАЄМОДУВАННЯ (починаючи з SQL Сервер 2008).

У всіх трьох цих випадках запис у sys.databasesтакож змінюється, щоб вони зберігалися синхронізовано. Однак, коли відновлюється База даних, або з іншої системи, або з тієї ж інстанції, але з БД, яка була резервна копія / відключення до виконання однієї з цих 2 команд SQL, щоб змінити власника, тоді після RESTORE або вкладення буде бути невідповідність між owner_sidстовпчика в sys.databasesі «DBO» sidв sys.database_principalsв цій БД.

Наскільки мені відомо, запис у sys.database_principalsкожній БД є справжнім власником, а owner_sidстовпець у sys.databases- питання обліку / зручності (подібно до денормалізації; без sys.databasesсистеми потрібно було б робити окремі запити для всіх БД до отримуйте цю інформацію, щоразу запитуючи!) та безпеку. Одне, для чого використовується, - це ідентифікувати потенційно шкідливий / недійсний відновлений / доданий БД - це те, що записи не відповідають. Спроба отримати доступ до зборів SQLCLR, позначених як EXTERNAL_ACCESSабо UNSAFEне завантажуються, якщо хтось вирішив пройти менш безпечний маршрут увімкнення, TRUSTWORTHYоскільки це покладається на "dbo" SID, оскільки він повинен відповідати входу, що має EXTERNAL ACCESS ASSEMBLYабоUNSAFE ASSEMBLYдозвіл. І коли між цими двома переглядами системного каталогу є невідповідність у SID, неможливо визначити, який саме використовувати та використовувати як червоний прапор для можливої ​​проблеми безпеки. Насправді, я перевіряю цю умову в інсталяційному скрипті для SQL #, щоб попередити когось про внесення відповідних змін, просто так, що їм не доведеться витрачати час на пошук цього випадку, якщо SQL Server скаржиться на це в якийсь момент.