而元数据的查看现在也搭配安全管理权限，让用户只能查看可以访问的对象。另外，所有的权限都可以通过 T-SQL 的 GRANT、REVOKE、DENY 赋予或禁止，这也称为 Granular permissions。
在默认安全性部分，新版默认可以利用 SQL Server 访问外部资源（如 OpenRowset 系统函数、 xp_cmdshell 系统存储过程、启动 .NET CLR等），或外部可以使用 SQL Server 的管道（如 HTTP 访问）关闭。同时新增“SQL Server Surface 界面区配置”工具程序，让你可以通过统一的界面来打开或关闭这些功能。
安全的安装和维护、通信和储存等方面提供数据加密，程序可以特定身份执行。新版 SQL Server 提供管理密码钥匙的层次架构，用来加密数据的钥匙可以安全地保存在数据库内，用数据库钥匙加密一般的钥匙，再用 SQL Server 实例的钥匙加密数据库钥匙，最后实例的钥匙通过 Windows 操作系统的 DPAPI 保护。另外，登录账号永远是被加密的。而存储过程或用户自定义函数可以特定身份执行（run as），以符合最小权限准则，不必普遍赋予用户账号各种权利，只有通过特定的程序或函数转换身份后，才能完成需要特殊权限的对象访问。
另外，新版也可以为 SQL Agent 不同的工作定义不同的代理账号，而不像以往只有通过 SQL Agent 服务账号或一个代理账号可以设置。
本机的 HTTP 支持
不知道你是否曾经有过这样的疑问，为什么 OSI 网络七层结构中或互连网四层结构中，传输层与网络层可以几近统一使用 TCP 和 IP 协议，但为何在应用层需要熟悉这么多种协议，例如传输文件用 FTP 或 WebDev 协议、发送电子邮件用 SMTP、收电子邮件用 POP3、访问 SQL Server 用 TDS、调用远端应用程序用 DCOM、浏览网页用 HTTP等等。应用层是否也可以使用统一的协议？慢慢地，答案似乎呼之欲出。是的，就是 SOAP，也就是 HTTP 加上 XML。
在微软和 IBM 等大厂渐渐取得共识后，各项新的产品几乎都开始采用 SOAP 当作标准的访问协议。而 SQL Server 2005 的各项服务大都支持 “web services/SOAP” 的访问，例如 Analysis Services 和 Reporting Services 都直接通过 web services /SOAP 访问。
SQL Server 数据库引擎也可以设置让前端应用程序直接通过 web services 的方式调用存储过程，这让 SQL Server 可以更广泛地支持各种平台。由于 SQL Server 引擎通过 Windows 2003 或 Windows XP SP2 等版本操作系统核心的 http.sys 直接处理 SOAP 协议，因此该机器上不需要安装与启动 IIS 服务，就可以让 SQL Server 数据库引擎通过 Web Services 提供服务，以 XML 的格式传回执行结果。换句话说，开发者直接在数据库层建立 web services，SQL Server 可以当作 HTTP listener，接受以 web services 模式沟通的前端应用程序访问。这让其他平台的程序开发者，如 Java、Linux 等，除了 JDBC 或其他特殊的机制外，也都可以通过标准的 web services/SOAP 访问 SQL Server。
Service Broker
提供消息导向或异步的程序开发平台，通过 SQL Server 所提供的队列（Queue）让服务间异步地沟通，并保证消息传递质量，也就是消息一定寄达，且按照发送的先后顺序只寄达一次。以往建立分布式运算、消息导向或异步访问架构时，我们以程序代码调用 MSMQ 服务，两个程序通过 MSMQ 提供的 COM 对象彼此协调沟通后，再各自更新自己的数据库。而今可以各自跟数据库沟通，让数据库服务器来完成消息合作。程序设计员可以减少了解 MSMQ 架构的需求。当然，若统一在 SQL Server 的平台上，你多了一种架构选择。但若是异质平台集成或应用程序分散的拓扑（topology）复杂，或整个系统中根本不需要数据库的存在，你依然会采用 MSMQ。
另外，SQL Server 2005 本身在许多机制上都使用 Service Broker，让原本前台同步的运作可以改为后台异步运作。例如新增的 Database Mail 就会在用户通过系统存储过程要求寄发电子邮件时，先将需求放入到 Service Broker 中，把执行权立刻还给用户，而不必让用户空等系统和 SMTP 服务沟通，后台程序再从队列中读取命令，完成电子邮件的寄发。
而新提供的 Event Notification 也是通过 Service Broker 收集各种系统事件，它提供了与 DDL/DML 触发器不同的架构。也就是若你在用户执行 DDL 或 DML 语言后，需要立刻处理的商业逻辑可以通过触发器来完成，但也由于默认触发器执行时会与上述的语句绑在同一个事务中，因此会延长系统回应用户的时间，甚至由于打开事务过久，而卡住大量的系统资源，破坏了在线同时访问的能力。因此若触发的事件可以批次后台执行，通过 SQL Server 2005 新提供的 Event Notification 机制，你可以通过队列累积需求，在系统不忙碌的时间来完成这些需求。而本文前述 SQL Server 2005 和 ADO.NET 2.0 合作的主动通知机制，其实也是建立在 Service Broker 之上的。
你所编写的应用程序也可以通过 Service Broker 将同步运行改成异步，以往通过触发器立刻处理数据变换后该完成的商业逻辑，或许也可以通过 Service Broker 累积需求，选择在系统不忙碌的时间再批次完成。由于 Service Broker 还提供在需求量大时调整负荷的机制，让你更能够善用多 CPU 的服务器资源。
Notification Service
让大量的事件与大量的订阅可以在 SQL Server 平台上聚合，如数百万人对数百支股票各有各的兴趣，每个人可以自行订阅他有兴趣的多个事件。当大量的人订阅了各种事件，并设置了需要通知的条件和通知的机制，SQL Server 在收集大量事件的发生后，以 Join 的方式集成需求，然后通知各订阅者。
这个服务在 SQL Server 2000 时就以外挂的方式提供，至今已经可以直接从微软网站下载 2.0 版。但很可惜的是它没有友善的设置界面以及简易的程序编写模型，因此你需要花点功夫来学习设置与编写程序。
责任编辑：小草
您现在的位置： 