В чем разница между пользователем `dbo` и владельцем базы данных, хранящейся в sys.databases

Недавно у нас возник вопрос, где у пользователя dboв базе данных есть sidчто не соответствует owner_sidin sys.databases. Я понимаю, как владелец базы данных отличается от участников роли, db_ownerно я всегда думал, что пользователь dboявляется фактическим владельцем базы данных. Разве это не так? И если так, есть ли реальные различия между dboи что в sys.databases?

Я всегда думал, что пользователь dboбыл фактическим владельцем базы данных.

Это (или, по крайней мере, должно быть) правильно. Имя «dbo» для этого пользователя никогда не меняется, однако базовый SID зависит от того, кто создал базу данных или кем она была задана через sp_changedbowner (хотя и включительно, SQL Server 2005) или ALTER AUTHORIZATION (начиная с SQL Сервер 2008).

Во всех этих трех случаях запись в sys.databasesтакже изменяется, так что они синхронизируются. Однако при восстановлении базы данных, либо из другой системы, либо из того же экземпляра, но из базы данных, для которой было выполнено резервное копирование / отсоединение до выполнения одной из этих двух команд 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как и полагается на «ДБО» SID , как это должно соответствовать Логин , который имеет либо EXTERNAL ACCESS ASSEMBLYилиUNSAFE ASSEMBLYразрешение. И когда существует несоответствие в SID между этими двумя представлениями системного каталога, невозможно определить, какой из них использовать, и использовать его в качестве красного флажка для потенциальной проблемы безопасности. Фактически, я проверяю это условие в скрипте установки для SQL #, чтобы предупредить кого-либо о необходимости внести соответствующие изменения, просто чтобы им не пришлось тратить время на его поиск в случае, если SQL Server в какой-то момент пожалуется на это.