Recentemente, tivemos uma pergunta chegar onde o usuário dboem um banco de dados tinha um sidque não combinava com o owner_sidno sys.databases. Entendo como o proprietário do banco de dados é diferente dos membros da função, db_ownermas sempre pensei que o usuário dboera o proprietário real do banco de dados. Não é esse o caso? E se houver, existem diferenças reais entre dboe o que está acontecendo sys.databases?
Respostas:
Eu sempre pensei que o usuário
dboera o proprietário real do banco de dados.
Isso é (ou pelo menos deveria estar) correto. O nome "dbo" desse Usuário nunca muda, mas o SID subjacente depende de quem criou o banco de dados ou de quem foi definido como sp_changedbowner (embora, inclusive, SQL Server 2005) ou ALTER AUTHORIZATION (começando com SQL Server 2008).
Nos três casos, o registro sys.databasestambém é alterado para que sejam mantidos sincronizados. No entanto, ao restaurar um banco de dados, de outro sistema ou da mesma instância, mas de um banco de dados que foi copiado / desanexado antes de um desses 2 comandos SQL serem executados para alterar o proprietário, depois de RESTORE ou anexar, haverá ser uma incompatibilidade entre a owner_sidcoluna sys.databaseseo "dbo" sidem sys.database_principalsem que a DB.
Tanto quanto sei, o registro em sys.database_principalscada banco de dados é o proprietário real e a owner_sidcoluna sys.databasesé uma questão de manutenção / conveniência de registros (semelhante à desnormalização; sem sys.databaseso sistema, seria necessário fazer consultas separadas em todos os bancos de dados para obtenha essas informações, sempre que solicitado!) e segurança. Uma coisa é usada para identificar um banco de dados restaurado / anexado potencialmente perigoso / inválido, pois esses registros não correspondem. Tentativa de acessar assemblies SQLCLR marcados como carregados EXTERNAL_ACCESSou UNSAFEnão, se alguém optar por seguir a rota menos segura de habilitação, TRUSTWORTHYpois depende do SID "dbo", pois precisa corresponder a um logon que possua o EXTERNAL ACCESS ASSEMBLYouUNSAFE ASSEMBLYpermissão. E quando há uma incompatibilidade no SID entre essas duas visualizações de catálogo do sistema, não é possível determinar qual usar e como sinalizador vermelho, pois existe um possível problema de segurança. Na verdade, testei essa condição no script de instalação do SQL # para alertar alguém para fazer a alteração apropriada, apenas para que eles não precisem perder tempo procurando por ela, caso o SQL Server se queixe em algum momento.