理论是这样的：任何可以被授予权限的东西都是‘securable’.所有的securables都有一个所有者.安全的所有者对安全性有绝对的控制权,不能否认任何特权.实例级别的安全性由服务器principals(登录)拥有.数据库级别的安全性由数据库主体(用户)拥有.校长有两种风格：初级(身份)和中级(会员).默认情况下,服务器级别安全性由当前记录的主服务器主体拥有.数据库级别安全性由当前数据库主体默认拥有,但默认情况下由架构所有者拥有的架构绑定对象除外.所有securables都在创建时支持AUTHORIZATION子句以强制执行不同的所有者. ALTER AUTHORIZATION可以在以后用于更改任何安全的所有者.

由于数据库是安全的服务器级别,因此默认情况下,它将由发出CREATE DATABASE语句的主要主体拥有. IE浏览器.离职员工的NT登录.

所以你的问题真的是“为什么安全性需要拥有者？”.因为所有者是信任的根源.它是所有者授予,拒绝和撤销对象的权限.安全系统可以在没有安全设备所有者的情况下进行设计吗？可能是的,但是必须有一些机制来取代所有者在当前模型中扮演的角色.例如,考虑到爸爸的安全性没有所有者(例如,而不是拥有一个安全的,原始的创建者只是被授予控制权)它可以为每个人创建一个安全的和撤销访问权限,包括他自己.所有者的要求可以避免这个问题,因为所有者无法将自己锁定.

创建由原始NT登录所拥有的安全(数据库)的CREATE DATABASE的鲜为人知的副作用已经烧毁了许多.每个安全规则的规则都相同,但有些因素会加剧DATABASE所有者的问题：

>其他服务器级别的安全性(端点,服务器角色,登录)很少使用,移动等.
>数据库级别的安全性通常由dbo(数据库主体)或其他一些数据库主体拥有,因此所有者包含在数据库中
>将数据库所有权默认为NT主体创建包含问题(所有者是由AD管理的NT SID,不随数据库文件一起传输,NT帐户可以缩略等等)
>最重要的事情：数据库所有者有重要的副作用,特别是EXECUTE AS context.这个后来的问题是烧毁大多数用户的问题.由于Service Broker广泛使用EXECUTE AS(消息传递具有隐式EXECUTE AS上下文,以及具有明确的队列激活)通常是Service Broker用户首先发现此问题.

BTW,Kudos调查和解决你的原始问题:)