¿Cuál es la diferencia entre el usuario `dbo` y el propietario de la base de datos almacenada en sys.databases

Recientemente tuvimos una pregunta llegar a donde el usuario dboen una base de datos tenía una sidque no coincidía con la owner_sidde sys.databases. Entiendo cómo el propietario de la base de datos es diferente de los miembros del rol, db_ownerpero siempre pensé que el usuario dboera el propietario real de la base de datos. No es ese el caso? Y si es así, ¿hay alguna diferencia real entre dboy qué hay sys.databases?

Siempre pensé que el usuario dboera el propietario real de la base de datos.

Eso es (o al menos debería ser) correcto. El nombre "dbo" de ese Usuario nunca cambia, sin embargo, el SID subyacente sí depende de quién creó la base de datos, o quién se configuró para ser a través de sp_changedbowner (aunque, incluido, SQL Server 2005) o ALTERAR AUTORIZACIÓN (comenzando con SQL Servidor 2008).

En los tres casos, el registro sys.databasestambién cambia para que se mantengan sincronizados. Sin embargo, al restaurar una base de datos, ya sea desde otro sistema o desde la misma instancia, pero desde una base de datos que fue respaldada / desconectada antes de que se ejecutara uno de esos 2 comandos SQL para cambiar el propietario, luego al RESTAURAR o adjuntar, habrá haber un desajuste entre la owner_sidcolumna en sys.databasesy el "dbo" siden sys.database_principalsel hecho de que DB.

Hasta donde yo sé, el registro en sys.database_principalscada base de datos es el propietario real , y la owner_sidcolumna en sys.databaseses una cuestión de mantenimiento de registros / conveniencia (similar a la desnormalización; sin sys.databasesel sistema necesitaría hacer consultas separadas en todas las bases de datos para obtenga esa información, cada vez que lo solicite!) y seguridad. Una cosa para la que se utiliza es para identificar un DB restaurado / adjunto potencialmente dañino / inválido si esos registros no coinciden. Intentar acceder a los ensamblados SQLCLR marcados como EXTERNAL_ACCESSo UNSAFEno se cargarán si uno ha elegido la ruta menos segura de activación, TRUSTWORTHYya que depende del SID "dbo", ya que debe coincidir con un inicio de sesión que tenga EXTERNAL ACCESS ASSEMBLYoUNSAFE ASSEMBLYpermiso. Y cuando hay una falta de coincidencia en el SID entre esas dos vistas de catálogo del sistema, no se puede determinar cuál usar, y se usa como una señal de alerta por un posible problema de seguridad. De hecho, pruebo esta condición en el script de instalación para SQL # para alertar a alguien para que realice el cambio apropiado, solo para que no tengan que perder el tiempo buscándolo en caso de que SQL Server se queje en algún momento.