商业源码 SQL Server！急救！！！
(一)SQLServer支持Windows身份验证模式和混合模式两种身份验证模式。这两种身份验证模式的区别有：
(1) Windows 身份验证模式
只进行 Windows 身份验证。用户不能指定 SQL Server 2000 登录 ID。这是 SQL Server 2000 的默认身份验证模式。不能为在 Windows 98 上运行的 SQL Server 实例指定 Windows 身份验证模式，因为此操作系统不支持 Windows 身份验证。
(2) 混合模式
如果用户在登录时提供了 SQL Server 2000 登录 ID，则系统将使用 SQL Server 身份验证对其进行验证。如果没有提供 SQL Server 2000 登录 ID 或请求 Windows 身份验证，则使用 Windows 身份验证对其进行身份验证。
（二）角色让你将用户集中到一起，以利于更简单的管理。就像用户一样，角色也是数据库的对象。例如，你可以在自己的采购数据库里定义一个“销售”角色，并让所有的产品所有销售人员都成为这个角色的成员。如果你随后赋予这个“销售”角色许可，那么这些许可会自动地应用于该角色的所有成员上。此外，一个用户可以是多个角色的成员。
有三种类型的角色：
公共——这个角色会为所有的用户设置缺省的基本许可，所有的用户都会被分配公共角色。
服务器——服务器角色适用于整个服务器。
数据库——这些角色适用于专门的数据库。
服务器和数据库角色都有预先定义的类别:
服务器
SysAdmin
所指派的成员能够在服务器进行任何操作。
ServerAdmin
所指派的成员能够设置服务器配置选项。
SetupAdmin
所指派的成员能够管理被连接的服务器和SQL服务器的启动选项以及任务。
SecurityAdmin
所指派的成员能够管理服务器的安全。
ProcessAdmin
所指派的成员可以取消服务器上有所的进程。
dbCreator
所指派的成员能够创建、更改、停止和恢复数据库。
DiskAdmin
所指派的成员能够管理服务器磁盘文件。
BulkAdmin
所指派的成员能够运行大多数插入命令。
数据库
db_owner
所指派的成员具有对数据库的完全访问权。
db_accessadmin
所指派的成员能够管理Windows组以及SQL服务器的登录。
db_datareader
所指派的成员能够读取数据库里的所有数据。
db_datawriter
所指派的成员能够添加、删除，或者修改数据库里的数据。
db_ddladmin
所指派的成员能够运行动态链接库（DLL）陈述式。
db_securityadmin
所指派的成员能够修改角色成员的所属，并能够管理许可。
db_denydatareader
所指派的成员不能够查看数据库里的数据。
db_bckupoperator
所指派的成员可以备份数据库。
db_denydatawriter
所指派的成员不能更改或者删除数据。
解决办法一
1)将登录方式设为"混合认证"(右击服务器->选择"安全性"->点选"Sql Server"和Windows身份认证模式)
前提是已经启用了数据库的混合身份验证,即sa用户已经启用。
3)设置sa账户(数据库->安全性(与上面的不是同一个,这个不用右击)->登录名->sa账户->设置密码->用户映射->映射到你的数据库
3)重启服务Sql server(net stop mssqlserver)
解决办法二
先看看数据库有没有混合身份验证,同时查看即sa用户已经启用。在都已启用的情况下，再如下图设置。
在数据库右键属性：文件--〉所有者--〉选择用户sa，即可用此sa用户登录数据库
以上面的方法设置好后，就可以作用了
SQL Server所谓的分布式查询（Distributed Query）是能够访问存放在同一部计算机或不同计算机上的SQL Server或不同种类的数据源， 从概念上来说分布式查询与普通查询区别 它需要连接多个MSSQL服务器也就是具有多了数据源。实现在服务器跨域或跨服务器访问。 而这些查询是否被使用完全看使用的需要。
本篇将演示利用SQL ServerExpress链接远程SQL Server来获取数据方式来详细说明分布式查询需要注意细节。先看一下系统架构数据查询基本处理：
当然如果采用了分布式查询 我们系统采取数据DataBase也就可能在多个远程［Remote Server］上访问时：
如上截取系统架构中关于数据与缓存流向中涉及的分布式查询业务， 当我们从客户端Client发起请求数据时。 首先检查MemCache Server缓存服务器是否有我们想要数据。 如果没有我需要查询数据库。 而此时数据要求查询多个远程服务器上多个数据库中表， 这时利用分布式查询。获得数据 然后更新我们在缓存服务器MemCache Server上数据保持数据更新同步， 同时向客户端Client直接返回数据。那如何来执行这一系列动作中最为关键分布式查询？
《1》分布式查询方式
我们知道Microsoft微软公用的数据访问的API是OLE_DB， 而对数据库MSSQL Server 2005的分布式查询支持也是OLE_DB方式SQL Server 用户可以使用分布式查询访问以下内容：
A：存储在多个 SQL Server 实例中的分布式数据
B：存储在各种可以使用 OLE DB 访问接口访问的关系和非关系数据源中的异类数据
OLE DB 访问接口将在称为行集的表格格式对象中公开数据。SQL Server 允许在 Transact-SQL 语句中像引用 SQL Server 表一样引用
OLE DB 访问接口中的行集，［其实不用关心这个行集概念 它的功能类似SQL Server中临时表 不过它容积更大 能容纳类型更多 更丰富］
SQL Server 实例的客户机与 OLE DB 访问接口之间的连接
从上图可以看出。客户端借助OLEDB接口可以访问Oracle/MS Jet/MS SQL/ODBC/第三方等这些丰富数据源来我们分布式查询提供数据。 说了这么多关于OLEDB底层支持。 关于在MS SQL 2005中则支持两种方式来进行分布式查询：
使用添加链接服务器方式（Add Link Server）
使用特定名称及特定数据源来直接指定（Add Host Names）
其实这两种方式在实际运用中是有区别的：
方式A:Add Link Server方式建立服务器之间关联。创建一个链接的服务器，使其允许对分布式的、针对 OLE DB 数据源的异类查询进行访问。 一般适用于持久的数据操作 对于数据量偏大 服务器之间交付时间长特点。
方式B： Add Host Name 利用域来唯一识别数据库以及数据库表对象。 来实现跨服务器访问。 这种方式一般比较简单 主要适用于对数据需求临时性查询是使用偏多。 不适合做大批量数据提取。 有性能瓶颈。
《2》分布式查询实现
在进行实现分布式查询之前。本次测试Demo对应的SQL版本：
确定SQL Server版本后如下会演示两种方式来实现分布式查询，并对Distributed Query中详细细节进行说明。
《21》链接服务器查询
链接服务器配置使 SQL Server 可以对远程服务器上的 OLE DB 数据源执行命令。链接服务器具有以下优点：
访问远程服务器。
能够对企业内的异类数据源发出分布式查询、更新、命令和事务。
能够以相似的方式确定不同的数据源
下图显示了链接服务器配置的基础：
现在利用链接服务器方式实现数据访问远程服务器数据库CustomerDB中Users表数据先本地添加LinkServer：
以下是代码片段：
-- 建立连接服务器 第一步建立连接 IP方式来控制
EXEC sp_addlinkedserver '19216810104' , 'SQL Server'
-- 查看链接服务器信息 [测试连接成功]
select name , product, provider, data_source, query_timeout, lazy_schema_validation, is_remote_login_enabled, is_rpc_out_enabled
from sysservers
where is_linked= 1
如上市建立连接服务器最简单方式。建立链接服务器过程其实调用了系统存储过程Sp_addlinkedserver 第一个参数为Name 其实用来唯一标识链接服务器。 当然可以其他任何有意义字符串来定义，但我个人建议使用远程服务器的IP来标识。第二个参数是要添加为链接服务器的 OLE DB 数据源的产品名称。 默认为Null，如果指定”SQL Server“则无需指定其他参数。
如果你的本地装有多个数据库实例。 第一个种方式就不适用。这是就需要用SQL Server2005架构来唯一标识：
-- 含架构名 查询数据两种模式
select top 10 from [19216810104] wl 架构名 表名
-- 架构名 [采用默认架构名 ]
select top 10 from [19216810104] CustomerDB dbo Users
对于SQL Server 2005架构这个概念很多人比较陌生：
在用户角色设置中需要对指定访问数据CustomerDB具有读写权限：
#p#副标题#e#
在远程服务器创建TEst用户时使用SQL Server身份验证方式登录 这时设置密码为RemoteDB在使用非Sa用户进行远程：
以下是代码片段：
-- 执行前先删除已经存在数据
Exec sp_droplinkedsrvlogin [1921681076],Null
Exec sp_dropserver 'demodb'
-- 创建服务器连接
EXEC sp_addlinkedserver
@server='demodb',-- 被访问的服务器别名
@srvproduct='',
@provider='SQLOLEDB',
@datasrc='1921681076' -- 要访问的服务器
EXEC sp_addlinkedsrvlogin
'demodb', -- 被访问的服务器别名
'false',
NULL,
'Test', -- 帐号
'RemoteDB' -- 密码
如上我们首先清除已经可能创建服务器数据记录 然后创建服务器连接sp_addlinkedSrvlogin系统存储过程用来创建链接服务器上远程登录之间的映射 即我们可以详细设置本地与远程服务器详细的映射信息 例如设置我们特定用户访问的用户名和密码
查询数据
-- 查询指定用户Test数据 select from [demodb]CustomerDBdboUsers -- [如上测试成功]
查询结果
指定用户Test对CustomerDB访问数据方式测试成功。
当测试完成后我们不需要这个连接服务器是即可利用SP_DroplinkServer删除掉。 对应参数为创建时Name唯一标识。 通过Sp_helpserver来查看连接服务器详细信息。
注意如上创建连接服务器时设置srvproduct参数即OLED数据源名称时我们采用了SQlServer方式。
下面说明这种方式特点。：
这种方式是最为简单直接的一种建立链接服务器方式。 但是存在前提的。 测试发现：
在所有数据库的远程连接 dbo 的方式必须建立在SA 密码相同的基础上 ，否则容易产生无法连接的情况 Sa用户登录失败。 你也就明白这个SQlServer参数其实就是在本地数据拷贝服务器角色SysAdmin下用户SA来对服务器进行登录。 如果你的本地Sa密码与远程服务器上密码不一致 则无法正常连接。
经过测试还发现一种情况：
利用Windows7访问XP（Sp2）系统时始终提示无法解析或拒绝连接SQL Server2005这个问题我整了好久后来才到官方链接参数中发现。：如果你的XP系统没有打上SP4的补丁包 这个问题会始终出现。 需要特别注意。
《22》直接指定数据源分布式查询
其实相对第一种方式， 直接指定方式在SQL Server架构中 其实跳过本地与远程服务器建立映射关系的这一步。 通过链接关系建立 其实就是建立一种内部映射关系。 如果没有映射关系则 大部分设置需要手动控制。
直接指定数据源方式 需要开启分布式查询的基本权限 来进行查询：
以下是代码片段：
-- 如果想使用分布式查询，必须先开通分布式查询 [外围配置 这点是所有查询操作前提]
-- sp_configure--显示或更改当前服务器的全局配置设置
-- reconfigure 指定如果配置设置不需要服务器停止并重新启动，则更新当前运行的值
-- SQL2005默认是没有开启’Ad Hoc Distributed Queries’ 组件
-- 启用权限
exec sp_configure 'show advanced options',1 -- 显示高级配置
reconfigure -- 更新值
exec sp_configure 'Ad Hoc Distributed Queries',1 -- 启用分布式查询
reconfigure
go
-- 关闭分布式查询
exec sp_configure 'Ad Hoc Distributed Queries',0
reconfigure
exec sp_configure 'show advanced options',0
reconfigure
go
-- 开启权限后 另外一种查询方式
-- 查询格式
SELECT FROM OPENDATASOURCE('SQLOLEDB',
'Data Source=远程ip;User ID=sa;Password=密码')库名dbo表名
WHERE 条件
-- 需要开启权限
-- 开启权限 提示[远程的SqlServer不允许远程连接]
select from OPENDATASOURCE('SQLOLEDB','Data Source=1921681067; User
如上我们首先清除已经可能创建服务器数据记录 然后创建服务器连接sp_addlinkedSrvlogin系统存储过程用来创建链接服务器上远程登录之间的映射 即我们可以详细设置本地与远程服务器详细的映射信息 例如设置我们特定用户访问的用户名和密码
查询数据
-- 查询指定用户Test数据 select from [demodb]CustomerDBdboUsers -- [如上测试成功]
查询结果
指定用户Test对CustomerDB访问数据方式测试成功。
《3》问题排查与更多查询方式
当我们在实际编程中进行访问远程数据时 因为不同操作环境会引发各种各样的异常，如下我会提出一种常见的异常方式解决办法和关于远程数据操作更多查询方式。
《31》无法建立远程连接
其实这个问题在做分布式查询时极其常见。 而引起这个问题的因素过多。 我们一时无法判断真正引发这个异常地方。 只能通过逐个排查方式来进行设置：
例如我们在建立关联关系后 进行查询时会遇到：
提示是： 在进行远程连接时超时， 引起这个问题原因可能是远程服务器积极拒绝访问！
首先要在SQL Server Configuation Manager中保证你服务已经运行 且是开机自动运行。
再次检查SQL Server 2005外围配置DataBaseEngine允许远程连接：
设置完成后。我们还需要设置SQL Server Analysis Services分析服务也支持远程数据查询：
在远程服务器上如果启用了防火墙则可能对目前SQL Server Server方位实例进行拦截。 所以在服务器端启用防火墙情况下要为SQL Server DAtaBase创建例外。防止客户端请求被拦截。
《32》进程被其他用户占用
当我们在远程分布式查询中有创建动作或是类似创建一个新的数据库。 有时会提示 “该数据库无法操作 已经别其他进程占用”异常。 导致我们无法访问数据库。 或是执行我们要做的创建操作
遇到这种情况我们可以利用SA权限查询到Master数据库对应数据库被占用的进程 并杀掉Kill Process查询：
以下是代码片段：
-- [sysprocesses 表中保存关于运行在 Microsoft SQL Server 上的进程的信息。
-- 这些进程可以是客户端进程或系统进程。sysprocesses 只存储在 master 数据库中]
use Master
go
SELECT FROM sysprocesses ,sysdatabases
WHERE sysprocessesdbid=sysdatabasesdbid AND sysdatabasesName='CustomerDB'
select from sysprocesses
select from sysdatabases
-- 杀死占用进程
kill 5
当我们对进程占用清除时有可能访问数据库被系统进程占用。 则这时用Sa无法杀死。这时提示：
“Only use Process can be Kill ”在SQL Server2005 只有只有用户进程才能Kill掉。
《33》更多的查询操作
往往我们在实际操作中需要对数据读写有更多要求。 例如从远程连接多个服务器进行数据读取或是把本地数据提交到服务器上。 为了提高效率和性能采用分布式事务来进行批量操作等等。 如下简单介绍在分布式查询中多中数据操作：
把远程数据导入本地：
以下是代码片段：
-- 把本地表导入远程表 [openWset方式]
insert openrowset( 'SQLOLEDB ', 'sql服务器名 '; '用户名 '; '密码 ',数据库名dbo表名) select from 本地表
-- 把本地表导入远程表 [open Query方式]
insert openquery(ITSV, 'SELECT FROM 数据库dbo表名 ')
导入时使用Into方式 自动在本地创建CopyDB表完全复制远程服务器上Users表的数据结构。但是要注意在进行后 的CopyDB将不包含原表的主键和索引约束。 虽然能快构建 但是主键和索引设置都会丢失。
本地数据导入远程：
-- 把本地表导入远程表 [openWset方式] insert openrowset( 'SQLOLEDB ', 'sql服务器名 '; '用户名 '; '密码 ',数据库名dbo表名) select from 本地表 -- 把本地表导入远程表 [open Query方式] insert openquery(ITSV, 'SELECT FROM 数据库dbo表名 ')
更新本地表数据：
以下是代码片段：
-- 把本地表导入远程表 [opendataSource方式]
insert opendatasource( 'SQLOLEDB ', 'Data Source=ip/ServerName;User ID=登陆名;Password=密码 ')数据库dbo表名
-- 更新本地表 [openowset方式]
update b set b列A=a列A from openrowset( 'SQLOLEDB ', 'sql服务器名 '; '用户名 '; '密码 ',数据库名dbo表名)
as a inner join 本地表 b on acolumn1=bcolumn1
当然还有更多方式来操作分布式查询操作。各位都可以尝试。
《4》尾 语
如上是我最近在项目中处理关于分布式查询涉及到方方面面。 从系统架构到分部是查询具体操作细节。基本都是一些非常基础运用。当然也参考不少资料。以及动手来验证整个过程出现问题原因所在。 篇幅有限 写的有些仓促。 难免有纰漏地方 还望各位指正。
#p#副标题#e#
出现此问题的原因为：权限设置问题造成的。
解决的方法和详细的操作步骤如下：
1、第一步，选择要设置的用户，如下图所示，然后进入下一步。
2、其次，完成上述步骤后，右键单击并选择“属性”选项，如下图所示，然后进入下一步。
3、接着，完成上述步骤后，单击“安全对象”选项，见下图，然后进入下一步。
4、然后，完成上述步骤后，勾选右下角的相应权限，如下图所示，然后进入下一步。
5、随后，完成上述步骤后，授予用户超级管理员的角色，如下图所示，然后进入下一步。
6、最后，完成上述步骤后，就可以看到已授予权限，如下图所示。这样，问题就解决了。
sql server 用户访问权限设置:
/--示例说明 示例
在数据库pubs中创建一个拥有表jobs的所有权限、拥有表titles的SELECT权限的角色r_test ，随后创建了一个登录l_test，然后在数据库pubs中为登录l_test创建了用户账户u_test， 同时将用户账户u_test添加到角色r_test中，使其通过权限继承获取了与角色r_test一样的权限， 最后使用DENY语句拒绝了用户账户u_test对表titles的SELECT权限。 经过这样的处理，使用l_test登录SQL Server实例后，它只具有表jobs的所有权限。
--/ USE pubs --
创建角色 r_test ： EXEC sp_addrole r_test --
授予 r_test 对 jobs 表的所有权限 ：GRANT ALL ON jobs TO r_test --
授予角色 r_test 对 titles 表的 SELECT 权限： GRANT SELECT ON titles TO r_test --
添加登录 l_test,设置密码为pwd,默认数据库为pubs ： EXEC sp_addlogin l_test,pwd,pubs --
为登录 l_test 在数据库 pubs 中添加安全账户 u_test ： EXEC sp_grantdbaccess l_test,u_test --
添加 u_test 为角色 r_test 的成员： EXEC sp_addrolemember r_test,u_test --
-----------------------------补充-------------- --
上面的授权为对单表进行授权，2005可对SCHEMA级别进行授权 ，
授予安全账户 u_test，架构interface下的查询权限： GRANT SELECT ON SCHEMA::interface TO u_test --
拒绝安全账户 u_test，架构dbo下的权限： DENY VIEW DEFINITION ON SCHEMA::dbo TO risk --
拒绝安全账户 u_test 对 titles 表的 SELECT 权限： DENY SELECT ON titles TO u_test /--
完成上述步骤后，用 l_test 登录，可以对jobs表进行所有操作，但无法对titles表查询，虽然角色 r_test 有titles表的select权限，但已经在安全账户中明确拒绝了对titles的select权限，所以l_test无titles表的select 权限。--/ --
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
从数据库 pubs 中删除安全账户： EXEC sp_revokedbaccess u_test --
删除登录 l_test： EXEC sp_droplogin l_test --
删除角色 r_test： EXEC sp_droprole r_test exec sp_dropsrvrolemember Naa, sysadmin go exec sp_addsrvrolemember Naa, securityadmin go --
作好SQL的安全管理，首先做好用户安全，简单的，只允许sql的用户访问sql(防止利用administrator组用户访问)
1、企业管理器--右键SQL实例--属性--安全性--身份验证--选择"sql server和windows"--确定 2、企业管理器--安全性--登陆--右键sa--设置密码--其他用户也设置密码 3、删除用户： BUILTINAdministrators Administrator --这个用户不一定有 这样可以防止用windows身份登陆SQL 4、设置进入企业管理器需要输入密码：在企业管理器中 --右键你的服务器实例(就是那个有绿色图标的) --编辑SQL Server注册属性 --选择"使用 SQL Server 身份验证" --并勾选"总是提示输入登录名和密码" --确定 --经过上面的设置,你的SQL Server基本上算是安全了。
其次，改默认端口隐藏服务器，减少被攻击的可能性 SQL Server服务器： --开始 --程序 --Microsoft SQL Server --服务器网络实用工具 --启用的协议中"TCP/IP" --属性 --默认端口,输入一个自已定义的端口，比如2433 --勾选隐藏服务器
管好sql的用户，,防止访问他不该访问的数据库(总控制，明细还可以控制他对于某个数据库的具体对象具有的权限) ---切换到你新增的用户要控制的数据库： use 你的库名 go ----新增用户： exec sp_addlogin test ----添加登录： exec sp_grantdbaccess Ntest ----使其成为当前数据库的合法用户： exec sp_addrolemember Ndb_owner, Ntest ----授予对自己数据库的所有权限 -----这样创建的用户就只能访问自己的数据库。及数据库中包含了guest用户的公共表 go ----删除测试用户： exec sp_revokedbaccess Ntest ----移除对数据库的访问权限： exec sp_droplogin Ntest ----删除登录： 如果在企业管理器中创建的话，就用，企业管理器--安全性--右键登录--新建登录 常规项--名称中输入用户名 --身份验证方式根据你的需要选择(如果是使用windows身份验证,则要先在操作系统的用户中新建用户) --默认设置中，选择你新建的用户要访问的数据库名、 服务器角色项 这个里面不要选择任何东西， 数据库访问项 勾选你创建的用户需要访问的数据库名， 数据库角色中允许，勾选"public","db_ownew" 确定，这样建好的用户与上面语句建立的用户一样。
最后一步，为具体的用户设置具体的访问权限，这个可以参考下面的最简示例：
--添加只允许访问指定表的用户： exec sp_addlogin 用户名,密码,默认数据库名 -----添加到数据库： exec sp_grantdbaccess 用户名 ----分配整表权限： GRANT SELECT , INSERT , UPDATE , DELETE ON table1 TO [用户名] -----分配权限到具体的列： GRANT SELECT , UPDATE ON table1(id,AA) TO [用户名]
sa 是数据库系统管理员，密码是管理员设定的
可以看下这个
http://blogcsdnnet/songyuhongnannan/article/details/7279070
SQLServer 角色与权限管理
sqlserversql server数据库microsoft服务器insert
安全性是所有数据库管理系统的一个重要特征。理解安全性问题是理解数据库管理系统安全性机制的前提。
1第一个安全性问题：当用户登录数据库系统时，如何确保只有合法的用户才能登录到系统中？这是一个最基本的安全性问题，也是数据库管理系统提供的基本功能。
在Microsoft SQL Server 2008系统中，通过身份验证模式和主体解决这个问题。
1）身份验证模式
Microsoft SQL Server 2008系统提供了两种身份验证模式：Windows身份验证模式和混合模式。
Windows身份验证模式：
在该模式中，用户通过Windows用户账户连接SQL Server时，使用Windows操作系统中的账户名和密码。
混合模式：
在混合模式中，当客户端连接到服务器时，既可能采取Windows身份验证，也可能采取SQL Server身份验证。
主体是可以请求系统资源的个体或组合过程。例如，数据库用户是一种主体，可以按照自己的权限在数据库中执行操作和使用相应的数据。
2）主体
主体是可以请求系统资源的个体或组合过程。例如，数据库用户是一种主体，可以按照自己的权限在数据库中执行操作和使用相应的数据。
Microsoft SQL Server 2008系统有多种不同的主体，不同主体之间的关系是典型的层次结构关系，位于不同层次上的主体其在系统中影响的范围也不同。位于层次比较高的主体，其作用范围比较大；位于层次比较低的主体，其作用范围比较小。
2第二个安全性问题：当用户登录到系统中，他可以执行哪些操作、使用哪些对象和资源？
在Microsoft SQL Server 2008系统中，通过安全对象和权限设置来解决这个问题。
3第三个安全性问题：数据库中的对象由谁所有？如果是由用户所有，那么当用户被删除时，其所拥有的对象怎么办，难道数据库对象可以成为没有所有者的“孤儿”吗？
在Microsoft SQL Server 2008系统中，这个问题是通过用户和架构分离来解决的。
安全机制的5个等级：
客户机安全机制
网络传输的安全机制
实例级别安全机制
数据库级别安全机制
对象级别安全机制
四角色
1固定服务器角色
v固定服务器角色是服务器级别的主体，它们的作用范围是整个服务器。
v固定服务器角色已经具备了执行指定操作的权限，可以把其他登录名作为成员添加到固定服务器角色中，这样该登录名可以继承固定服务器角色的权限。
固定服务器角色的特点
v在Microsoft SQL Server系统中，可以把登录名添加到固定服务器角色中，使登录名作为固定服务器角色的成员继承固定服务器角色的权限。
v对于登录名来说，可以选择其是否成为某个固定服务器角色的成员
按照从最低级别的角色（bulkadmin）到最高级别的角色（sysadmin）的顺序进行描述：
Bulkadmin：这个服务器角色的成员可以运行BULK INSERT语句。这条语句允许从文本文件中将数据导入到SQL Server 2008数据库中，为需要执行大容量插入到数据库的域账户而设计。
Dbcreator：这个服务器角色的成员可以创建、更改、删除和还原任何数据库。这不仅是适合助理DBA的角色，也可能是适合开发人员的角色。
Diskadmin：这个服务器角色用于管理磁盘文件，比如镜像数据库和添加备份设备。它适合助理DBA。
Processadmin：SQL Server 2008能够多任务化，也就是说可以通过执行多个进程做多个事件。例如，SQL Server 2008可以生成一个进程用于向高速缓存写数据，同时生成另一个进程用于从高速缓存中读取数据。这个角色的成员可以结束（在SQL Server 2008中称为删除）进程。
Securityadmin：这个服务器角色的成员将管理登录名及其属性。他们可以授权、拒绝和撤销服务器级权限。也可以授权、拒绝和撤销数据库级权限。另外，它们可以重置SQL Server 2008登录名的密码。
Serveradmin：这个服务器角色的成员可以更改服务器范围的配置选项和关闭服务器。例如SQL Server 2008可以使用多大内存或监视通过网络发送多少信息，或者关闭服务器，这个角色可以减轻管理员的一些管理负担。
Setupadmin：为需要管理链接服务器和控制启动的存储过程的用户而设计。这个角色的成员能添加到setupadmin，能增加、删除和配置链接服务器，并能控制启动过程。
Sysadmin：这个服务器角色的成员有权在SQL Server 2008中执行任何任务。
Public:有两大特点，第一，初始状态时没有权限；第二，所有的数据库用户都是它的成员。
2数据库角色
三种类型的数据库角色:
固定数据库角色：微软提供的作为系统一部分的角色；
用户定义的标准数据库角色：你自己定义的角色，将Windows用户以一组自定义的权限分组；
应用程序角色：用来授予应用程序专门的权限，而非授予用户组或者单独用户。
1）固定数据库角色
微软提供了9个内置的角色，以便于在数据库级别授予用户特殊的权限集合
db_owner:该角色的用户可以在数据库中执行任何操作。
db_accessadmin:该角色的成员可以从数据库中增加或者删除用户。
db_backupopperator:该角色的成员允许备份数据库。
db_datareader:该角色的成员允许从任何表读取任何数据。
db_datawriter:该角色的成员允许往任何表写入数据。
db_ddladmin：该角色的成员允许在数据库中增加、修改或者删除任何对象（即可以执行任何DDL语句）。
db_denydatareader:该角色的成员被拒绝查看数据库中的任何数据，但是他们仍然可以通过存储过程来查看。
db_denydatawriter: 像db_denydatareader角色，该角色的成员被拒绝修改数据库中的任何数据，但是他们仍然可以通过存储过程来修改。
db_securityadmin:该角色的成员可以更改数据库中的权限和角色。
public：在SQL Server 2008中每个数据库用户都属于public数据库角色。当尚未对某个用户授予或者拒绝对安全对象的特定权限时，这该用户将据称授予该安全对象的public角色的权限，这个数据库角色不能被删除
2）用户自定义数据库角色
3）应用程序角色
应用程序角色允许用户为特定的应用程序创建密码保护的角色。
五权限
1常用的权限
安全对象
常用权限
数据库
CREATE DATABASE、CREATE DEFAULT、CREATE FUNCTION、CREATE PROCEDURE、CREATE VIEW、CREATE TABLE、CREATE RULE、BACKUP DATABASE、BACKUP LOG
表
SELECT、DELETE、INSERT、UPDATE、REFERENCES
表值函数
SELECT、DELETE、INSERT、UPDATE、REFERENCES
视图
SELECT、DELETE、INSERT、UPDATE、REFERENCES
存储过程
EXECUTE、SYNONYM
标量函数
EXECUTE、REFERENCES
964 操作权限
权限分为3种状态：授予、拒绝、撤销，可以使用如下的语句来修改权限的状态。
授予权限（GRANT）：授予权限以执行相关的操作。通过角色，所有该角色的成员继承此权限。
撤销权限（REVOKE）：撤销授予的权限，但不会显示阻止用户或角色执行操作。用户或角色仍然能继承其他角色的GRANT权限。
拒绝权限（DENY）：显式拒绝执行操作的权限，并阻止用户或角色继承权限，该语句优先于其他授予的权限。
1授予权限
本语法格式：
GRANT
{ALL|statement[,n] }
TO security_account[,n]
ALL：表示希望给该类型的对象授予所有可用的权限。不推荐使用此选项，保留些选项仅用于向后兼容。授予ALL参数相当于授予以下权限：
如果安全对象为数据库，则ALL表示CREATE DATABASE、CREATE DEFAULT、CREATE FUNCTION、CREATE PROCEDURE、CREATE VIEW、CREATE TABLE、CREATE RULE等权限。
如果安全对象为标量函数，则ALL表示EXECUTE和REFERENCES。
如果安全对象为表值函数，则ALL表示SELECT、DELETE、INSERT、UPDATE、REFERENCES。
如果安全对象为存储过程，则ALL表示EXECUTE、SYNONYM。
如果安全对象为表，则ALL表示SELECT、DELETE、INSERT、UPDATE、REFERENCES。
如果安全对象为视图，则ALL表示SELECT、DELETE、INSERT、UPDATE、REFERENCES。
Statement:表示可以授予权限的命令，例如，CREATE DATABASE。
security_account:表示定义被授予权限的用户单位。security_account可以是SQL Server的数据库用户，可以是SQL Server的角色，也可以是Windows的用户或工作组
解决方法：该错误产生的原因是由于SQL Server采取了仅使用Windows账户的身份验证方式，因此用户无法使用SQL Server的登录账户（如sa）进行连接。解决方法如下所述：
步骤/方法
第1步，在SQL Server服务器上依次单击“开始”→“所有程序”→Microsoft SQL Server→“企业管理器”菜单命令，打开SQL Server Enterprise Manager窗口。使用Windows身份验证连接上SQL Server
第2步，在左窗格中展开SQL Server组（本例为Database），然后右键单击SQL Server服务器的名称（本例为hanjiangit），选择“属性”快捷命令。在打开的“SQL Server属性（配置）-HANJIANGIT”对话框中切换至“安全性”选项卡，并在“安全性”区域将身份验证方式选择为SQL Server和Windows。最后单击“确定”按钮使设置生效，
第3步，重新启动SQL Server服务。
在上述解决方法中，如果即使用Windows身份验证的方式依然连接失败的话，那么将使用户处于两难境地。因为SQL Server服务器只允许使用Windows身份验证，然而由于一些特殊原因，使用Windows身份验证却无法连接上SQL Server。这样就造成了无论用何种身份验证方式均无法连接的情况。遇到这种情况，只能通过修改注册表将身份验证方式改为SQL Server和Windows混合验证方式，具体操作方法如下：
第1步，依次单击“开始”→“运行”菜单命令，在运行编辑框中键入Regedit命令并回车，打开“注册表编辑器”窗口。
第2步，依次展开[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer]分支，单击选中MSSQLServer选项，在右窗格中找到并双击LoginMode项。在打开的“编辑DWORD值”对话框中将“数值数据”修改为2，并单击“确定”按钮使设置生效，
第3步，关闭“注册表编辑器”窗口，并重新启动SQL Server服务。
通过上述设置，用户可以使用SQL Server账户sa连接数据库，并能够在“企业管理器”中新建SQL Server注册。不过此时仍然无法使用Windows身份验证模式来连接SQL Server，因为在SQL Server中有两个缺省的登录账户BUILTIN\Administrators和“机器名\Administrator”被删除。可以通过下面的步骤恢复这两个账户：
第1步，打开“企业管理器”窗口，在左窗格中依次展开“SQL Server组”→“SQL Server服务器”→“安全性”目录。然后右键单击“登录”选项，执行“新建登录”快捷命令，
第2步，打开“SQL Server登录属性-新建登录”对话框，保持身份验证方式为Windows身份验证，然后在“名称”编辑框中键入BUILTIN\Administrators，
第3步，单击“服务器角色”标签，在“服务器角色”选项卡中选中System Administrators复选框，并单击“确定”按钮，
第4步，重复上述步骤添加“‘机器名（域名）’\Administrator”账户。
与SQL SERVER安全控制相关的几点说明
（一）几个基本术语
身份验证（Authentication）是指通过提交服务器评估的凭据以登录到主体请求访问的 SQL Server 的过程。身份验证可以确定接受身份验证的用户或进程的标识。
用户、账户、账号、登录名、[数据库]用户名
用户是指能够在SQL Server安全机制下，访问数据库对象中的数据的操作员或客户。用户若要访问数据库对象，必须获得数据库管理员（DBA）分配的账号和密码。从SQL Server管理系统的角度来看，用户就是一组匹配的账户和密码。
账户和账号是一个概念的不同说法，在服务器中的账户又叫登录名（Login Name），因此访问服务器也称为登录服务器。服务器的登录名可以映射到数据库中成为[数据库]用户名(User Name)。一个登录名可以映射多个数据库用户，而一个用户只能映射一个登录名。
连接或登录SQL Server服务器时是用的登录名而非用户名登录的，程序里面的连接字符串中的用户名也是指登录名。
通常用户名与登录名相同（不是强制相同，但为了一目了然通常都在创建用户名时使用与登录名相同的名字）。
提示：登录名（Login Name）和用户名(User Name)是两个不同的概念：
登录名：服务器方的一个实体，登录名只能进入SQL Server服务器，但是不能让用户访问服务器中的数据库资源。
用户名：一个或多个登录对象在数据库中的映射，可以对用户对象进行授权，以便为登录对象提供对数据库的访问权限。
登录名作用于它所在的服务器。每个登录名的定义存放在master系统数据库的syslogins表中。
用户名作用于它所在的数据库。用户定义信息存放在每个数据库的sysusers表中。用登录名登录到SQL Server后，在访问操作各个数据库时，SQL Server会自动查询此数据库中是否存在与此登录名关联的用户名，若存在就使用此用户的权限访问此数据库，若不存在就是用guest用户访问此数据库（guest是一个特殊的用户名，后面会讲到）。
SQL身份验证：适合于非windows平台的用户或Internet用户，需要提供账户和密码。
Windows身份验证：适合于windows平台用户，利用Windows账户和windows集成验证，不需要提供密码。
用户想要操作数据库的某个对象（如某张表）需要过三关：
第一关：我们需要登录到SQL Server系统，即需要登录账户；
第二关：我们需要访问某个数据库，即需要该数据库的用户账户；
第三关：我们需要访问数据库中的某个对象（如某张表），需要有该对象的权限。
主体(principal)是可被授予对安全资源的访问权限的实体（例如登录名、用户、进程、组或角色）。主体可以是主体的集合（比如数据库角色或Windows组）或不可分割的主体（比如本地登录或域登录）。每个主体都具有一个 ID (identification)和一个安全 ID (SID)。
⊙ Windows级别的主体：Windows组、Windows域登录名、Windows本地登录名。
⊙ SQL Server级的主体：服务器角色、SQLServer登录名。
⊙数据库级的主体：数据库角色、数据库用户、应用程序角色。
上下文切换 (context switch)，更改检查执行语句或执行操作的权限时所依据的标识。
服务器(server)
1)指安装了SQL SERVER的计算机。2）指SQL Server实例——计算机上运行的 SQLServer的副本。3）指为用户提供服务的计算机软件或组件。
需要根据上下文理解。
注册服务器
注册服务器使您可以存储服务器连接信息（服务器的类型、服务器的名称、登录到服务器时使用的身份验证的类型等），以供将来连接时使用——下次连接该服务器时，不需要重新输入登录信息。
SQLServer 2000在SQL Server企业管理器中注册服务器，才能使用 SQL Server企业管理器来管理这些服务器。从SQLServer 2005始，在 SQL ServerManagement Studio 中注册服务器，才能使用 SQL Server Management Studio 来管理这些服务器。
在 Microsoft SQL Server中，可以注册以下类型的服务器：SQLServer数据库引擎、Analysis Services、Reporting Services、IntegrationServices和 SQL Server Compact 35SP1。
（二）SQL Server实例(SQL Server instance)
SQLServer实例(SQL Server instance)，简称实例 (instance)，是计算机上运行的SQLServer 的副本。同一台计算机上可以安装运行的多个 SQLServer副本。每个SQL Server实例都包含数据库引擎、Analysis Services和 ReportingServices的 SQL Server，每个SQL Server数据库实例各有一套不为其他实例共享的系统及用户数据库。
数据库引擎是用于存储、处理和保护数据的核心服务。利用数据库引擎可控制访问权限并快速处理事务。
实例又分为“默认实例”(default instance)和“命名实例”(namedinstance)，如果在一台计算机上安装第一个SQLSERVER,命名设置保持默认的话，那这个实例就是默认实例。默认实例与安装计算机具有相同名称。命名实例指安装SQL Server时给定了名称，可以安装多个命名实例，给定名称是为了与同一台计算机上的其他命名实例和默认实例区分开。
SQLServer应用程序可以通过仅指定服务器名称而连接到 SQLServer的默认实例。SQL Server应用程序在连接到服务器上的某个命名实例时必须既指定服务器名称又指定实例名称，计算机名称\实例名称。
一台计算机上最多只有一个默认实例，也可以没有默认实例，默认实例名与计算机名相同。如果要访问本机上的默认SQL服务器实例，使用计算机名、(local)、localhost、127001、、本机IP地址，都可以达到相同的目的。但如果要访问非本机的SQL服务器，那就必须使用计算机名称\实例名称。
默认实例和命名实例的区别:
1、服务中服务名称的区别：
(1)默认实例:MSSQLSERVER。
(2)有名命名实例：实列名为benet，在服务中的名称是MSSQL$BENET。
注：如果你有多个实例的时候会在服务中出现多个服务名称。
2、连接到查询分析器或探查器的时候区别：
(1)默认实例可以使用:“”(点)、“(local)”、“计算机名称”。
(2)实例名称：计算机名pcname，实例名benet，连接时使用的名称是pcname\benet。
(三)安全对象和权限
安全对象(Securable)，可以通过权限得到保护的实体。是SQLServer数据库引擎授权系统控制对其进行访问的资源。如表、视图、触发器等。
SQLServer中将安全对象分为三个层次,分别为:
⊙服务器层级，包含的安全对象：端点、登录、服务器角色、数据库。
⊙数据库层级，包含的安全对象：用户、数据库角色、应用程序角色、程序集、消息类型、路由、服务、远程服务绑定、全文目录、证书、非对称密钥、对称密钥、约定、架构。
⊙构架（SCHEMA）层级，包含的安全对象：类型、XML架构集合、对象（函数、过程、同义词、表、视图）
这三个层级是从上到下包含的，级别从高到低。
说明：端点(endpoint)为服务器级安全对象。Microsoft SQL Server 2005 中的连接管理基于“端点”。一个端点就是一个SQL Server对象，它能够使 SQL Server在网络中通信。对于数据库镜像，服务器实例需要有自己专用的“数据库镜像端点”。此端点用途特殊，专门用于接收来自其他服务器实例的数据库镜像连接。
权限 (permission)，与对象关联的规则，用来规定哪些用户可以获得该对象的访问权限以及方式如何。对安全对象的访问通过授予或拒绝权限进行控制。
权限可以明确用户能够使用哪些数据库对象，并对它们进行何种操作。用户在数据库内的权限取决于用户账号的权限和该用户所属的角色的权限。
提示：在设置权限时，尤其要注意权限在安全对象上的继承关系。对于高级别安全对象上设置的权限，会被自动继承到低级别安全对象上。
理解权限的继承和权限的覆盖会在设置权限时减少很多问题，最佳方法是统筹规划，上机验证。
（四）架构(schema)
架构是指包含表、视图、过程等的容器。它位于数据库内部，而数据库位于服务器内部。这些实体就像嵌套框放置在一起。服务器是最外面的框，而架构是最里面的框。架构包含表、视图、过程、函数、同义词、类型、队列、XML架构集合等安全对象。
注意：
在 SQL Server 2000和早期版本中，数据库可以包含一个名为“架构”的实体， SQL Server 2000包含 CREATE SCHEMA语句，但此实体实际上是所有者（创建对象时的用户）。在 SQL Server 2005 开始，架构既是一个容器，又是一个命名空间。任何用户都可以拥有架构，并且架构所有权可以转移。从 SQL Server 2005开始，每个用户都拥有一个默认架构。可以使用 CREATE USER或 ALTER USER的 DEFAULT_SCHEMA选项设置和更改默认架构。如果未定义 DEFAULT_SCHEMA，则数据库用户将使用 dbo作为默认架构。
在SQL Server 2000中，DataBaseNamedboTableName解释为：数据库名所有者表名。
从 SQL Server 2005开始，DataBaseNamedboTableName解释为：数据库名架构名表名。
在SQL Server 2000中，数据库对象全称是server_name[database_name][owner_name]object_name
从SQL Server 2005始，数据库对象全称是server_name[database_name][schema_name]object_name
在SQL SERVER2000或以前版本中创建一个对象，对象必须要有一个所有者(owner)。对象是如何属于某个所有者的呢？这依赖于创建对象时的用户。您不能取消对象所有者(object owner)的特权(privileges)。对象所有者可以执行任何与对象有关的操作（例如 INSERT、UPDATE、DELETE、SELECT或 EXECUTE），也可以管理对象的权限。
从2005/2008后，一个我们必须重新认识的情况是对象不再有所有者（owner）。架构包含对象，架构有所有者。
在2005前（如SQL Server 2000中），没有架构的概念，只有用户的概念，那时候DBO是默认用户。到了2005，有了架构概念，但是为了向后兼容，保留了DBO，并且把DBO作为默认架构，在不指定架构的情况下，默认为dbo，“默认架构”的概念，用于解析未使用其完全限定名称引用的对象的名称。在 SQL Server 2005 中，每个用户都有一个默认架构，用于指定服务器在解析对象的名称时将要搜索的第一个架构。可以使用 CREATE USER和 ALTER USER的 DEFAULT_SCHEMA选项设置和更改默认架构。如果未定义 DEFAULT_SCHEMA，则数据库用户将把 DBO作为其默认架构。
（五）dbo
dbo既是默认架构，也是默认用户。在SQL Server 2000中，dbo作为默认用户。在SQL Server2005中，dbo既作为默认用户，也作为默认架构（如图）。
dbo作为默认用户，dbo (DataBase Owner，数据库的所有者，拥有数据库中的所有对象)，每个数据库都有dbo， sysadmin服务器角色的成员自动映射成dbo，无法删除 dbo用户，且此用户始终出现在每个数据库中。通常，登录名sa映射为库中的用户dbo。另外，固定服务器角色 sysadmin的任何成员都映射到每个数据库内称为 dbo的一个特殊用户上。由固定服务器角色sysadmin的任何成员创建的任何对象都自动属于 dbo。由固定服务器角色 sysadmin的任何成员或 dbo用户创建的任何对象都自动属于dbo，由任何其他用户（包括 db_owner固定数据库角色成员）创建的对象，属于创建该对象的用户，而不是 dbo，用创建该对象的用户名限定。例如：
如果用户 Andrew是固定服务器角色sysadmin的成员，并创建表 T1，则表 T1属于 dbo，并以 dboT1而不是 AndrewT1进行限定。相反，如果 Andrew不是固定服务器角色sysadmin的成员，而只是固定数据库角色 db_owner的成员，并创建表 T1，则 T1属于 Andrew，并限定为AndrewT1。该表属于 Andrew，因为该成员没有将表限定为dboT1。
dbo作为默认架构，在不指定架构的情况下，默认为dbo，“默认架构”的概念，用于解析未使用其完全限定名称引用的对象的名称。在 SQL Server 2005 中，每个用户都有一个默认架构，用于指定服务器在解析对象的名称时将要搜索的第一个架构。可以使用 CREATE USER和 ALTER USER的 DEFAULT_SCHEMA选项设置和更改默认架构。如果未定义 DEFAULT_SCHEMA，则数据库用户将把 DBO作为其默认架构。
（六）Guest用户
guest用户不需要映射到登录名。这种用户账号是供数据库中没有明确授予权限给已映射至认证用户使用的。guest供那些已经成功登录到SQL SERVER实例，但是却没有通过用户访问数据库的权限的登录者使用的。
SQLSERVER 2000中guest用户可以删除；而2005/2008中是不能删除的，却可以取消CONNECT权限，而且为安全起见，所有用户定义的数据库中缺省情况下guest用户的权限都是被取消了的，可在除master和tempdb之外的任何数据库中禁用Guest用户。
在SQL SERVER 2000中，新建的数据库中没有Guest用户，但可以添加它，也可删除它，添加与删除方法与普通数据库相同。
在SQL Server 2005或以上版本中GUEST已经默认存在于每个数据库中，但默认情况下，会在新数据库中禁用GUEST用户(在“对象资源管理器→安全性→登录”节点中图标上有禁用标识)，我们可以通过以下语句启用GUEST用户：GRANT CONNECT TO GUEST 。当你决定不再想让该数据库被非数据库授权的用户以GUEST身份进行访问时，可以再次将GUEST帐号禁用。值得一提的是，GUEST用户在数据库中不能被删除，我们只能通过以下语句禁用GUEST用户：REVOKE CONNECT FROMGUEST 。
在SQL SERVER 2000中，要允许guest用户帐户访问数据库，可以像添加其它数据库用户那样添加它，如：
USE<Database Name>
GO
EXECsp_grantdbaccess 'guest'
GO
在SQL SERVER 2005中，允许guest用户帐户
USE<Database Name>
GO
GRANT CONNECT TO GUEST
GO
需要提醒的是，对于是否添加Guest用户要谨慎权衡利弊。
--SQLServer 2000删除guest用户账号
USE<Database Name>
GO
EXECsp_revokedbaccess 'guest'
GO
-- SQLServer 2005禁用guest用户账号
USE<Database Name>
GO
REVOKECONNECT FROM GUEST
GO
（七）sa登录名
SQLServer的 sa登录名是服务器级的主体。默认情况下，该登录名是在安装实例时创建的。在 SQL Server 2005和 SQL Server2008中，sa的默认数据库为 master。这是对早期版本的 SQLServer的行为的更改。
sa（system administrator系统管理员）是为向后兼容而提供的特殊登录。sysadmin是一种角色。该角色能够执行SQLServer上的任何操作。本质上，任何具有这种角色成员身份的人都是那个服务器上的sa。这种服务器角色的创建为微软提供了某一天去除sa登录的能力——实际上，联机丛书把sa称作本质上为遗留物的东西。
与以前版本不同，SQL Server 2008，即使是用混合模式安装，sa也默认禁用。
注意，sa是一个默认的SQL Server登录名，拥有操作SQL Server系统的所有权限，该登录名不能被删除。当采用混合模式安装Microsoft SQL Server系统之后，应该为sa指定一个密码，应为 sa登录分配一个强密码（strongpassword）。
sa登录名会映射到 sysadmin固定服务器角色，它对整个服务器有不能撤销的管理凭据。如果攻击者以系统管理员的身份获取了访问权限，则可能造成的危害是无法预计的。
(八)其它几个默认配置的的登录（Logins）和用户（Users）
默认配置的的登录和用户除了dbo用户、Guest用户、sa登录，还有如下几个：
Administrators组是一个特殊的登录。administrator用户默认administrators组的成员。
Administrators组实际名称为BUILTIN\Administrators。早期版本，这个组的所有成员均为 sysadmin 角色的成员（这意味着Administrators组中的成员具有最高权限），但可以从该角色中移除这些成员。与以前版本不同，SQL Server 2008默认情况下，本地 Windows组 BUILTIN\Administrators不再包含在新的 SQL Server 2008安装上的 SQL Server的 sysadmin固定服务器角色中。
提示：每个版本的 SQL Server都具有不同的安全功能，默认配置也不尽相同，后出的版本更有利于安全，但安全性和使用方便这两种需求可能有矛盾的一面，最佳方法是上机了解验证。
NETWORKSERVICE和SYSTEM登录账户
NETWORKSERVICE和SYSTEM登录账户，实际名称为NT AUTHORITY\NETWORK SERVICE和NT AUTHORITY\SYSTEM，是否存在这些，依赖于服务器的配置。如果配置了报表服务器，将出现NETWORK SERVICE登录账户。
INFORMATION_SCHEMA和sys用户
INFORMATION_SCHEMA和sys又是SQL Server 预定义的架构（内置架构）名称，它们与INFORMATION_SCHEMA和sys用户具有相同的名称。不能删除，主要用于向后兼容性。可以使用INFORMATION_SCHEMA用户和sys用户访问INFORMATION_SCHEMA和sys架构的系统视图，获取有关数据库元数据信息。
（九）SQL Server中的角色
角色 (role)，是SQL Server用来管理服务器和数据库权限的，是安全帐户的集合，在管理权限时可以视为一个单元——作为分配权限的单位。
SQLServer中的角色分为服务器级别和数据库级别角色。
◇服务器级别角色
服务器级别角色用于帮助管理服务器上的权限。服务器角色的权限作用域为服务器范围。可以将登录名（Login Name）添加到服务器角色。
符合权限要求的用户，可以将服务器级主体（SQL Server登录名、Windows帐户和 Windows组）添加到服务器级角色。固定服务器角色的每个成员都可以将其他登录名添加到该同一角色。
固定服务器角色简介：
1）sysadmin：系统管理员，角色成员可对SQLServer服务器进行所有的管理工作，为最高管理角色。这个角色一般适合于数据库管理员（DBA）。
2）securityadmin：安全管理员，角色成员可以管理登录名及其属性。可以授予、拒绝、撤销服务器级和数据库级的权限。另外还可以重置SQL Server登录名的密码。
3）serveradmin：服务器管理员，角色成员具有对服务器进行设置及关闭服务器的权限。
4）setupadmin：设置管理员，角色成员可以添加和删除链接服务器，并执行某些系统存储过程。
5）processadmin：进程管理员，角色成员可以终止SQLServer实例中运行的进程。
6）diskadmin：用于管理磁盘文件。
7）dbcreator：数据库创建者，角色成员可以创建、更改、删除或还原任何数据库。
8）bulkadmin：可执行BULK INSERT语句，但是这些成员对要插入数据的表必须有INSERT权限。BULK INSERT语句的功能是以用户指定的格式复制一个数据文件至数据库表或视图。
9）在sql server 2005 sp2（补丁）及以后版本，服务器角色中还可以看到一个public角色。每个 SQL Server登录名均属于 public服务器角色。 如果未向某个服务器主体授予或拒绝对某个安全对象的特定权限，该用户将继承授予该对象的 public角色的权限。public服务器角色默认拥有 VIEW ANY DATABASE（查看任何数据库）权限。[VIEW ANY DATABASE权限控制是否显示sysdatabases和 syssysdatabases视图以及 sp_helpdb系统存储过程中的元数据(metadata)。]
从 SQL Server 2012开始，您可以创建用户定义的服务器角色，并将服务器级权限添加到用户定义的服务器角色。
每个版本的 SQL Server都具有不同的安全功能，版本越高，功能越强。
可以利用系统函数IS_SRVROLEMEMBER指示当前用户的 SQLServer登录名是否是固定服务器角色的成员。
可以利用系统存储过程sp_helpsrvrolemember返回有关 SQL Server 固定服务器角色成员的信息。
--查询 sysadmin固定服务器角色的成员。
execsp_helpsrvrolemember 'sysadmin'
◇数据库级别的角色
数据库级别角色用于帮助管理数据库中的权限。数据库级角色的权限作用域为数据库范围。可以将[数据库]用户名(User Name)添加到数据库角色。
SQLServer中有两种类型的数据库级角色：数据库中预定义的“固定数据库角色”和您可以创建的“灵活数据库角色”（自定义数据库角色）。
固定数据库角色是在数据库级别定义的，并且存在于每个数据库中。 db_owner和db_securityadmin数据库角色的成员可以管理固定数据库角色成员身份。但是，只有db_owner数据库角色的成员能够向db_owner固定数据库角色中添加成员。 msdb数据库中还有一些特殊用途的固定数据库角色。
符合权限要求的用户，可以向数据库级角色中添加数据库帐户和其他 SQL Server角色。固定数据库角色的每个成员都可向同一个角色添加其他登录名。
固定数据库角色简介：
1）db_owner：数据库所有者，这个数据库角色的成员可执行数据库的所有管理操作。
2）db_accessadmin：数据库访问权限管理者，角色成员具有添加、删除数据库使用者、数据库角色和组的权限。
3）db_securityadmin：数据库安全管理员，角色成员可管理数据库中的权限，如设置数据库表的增加、删除、修改和查询等存取权限。
4）db_ddladmin：数据库DDL管理员，角色成员可增加、修改或删除数据库中的对象。
5）db_backupoperator：数据库备份操作员，角色成员具有执行数据库备份的权限。
6）db_datareader：数据库数据读取者，角色成员可以从所有用户表中读取数据。
7）db_datawriter：数据库数据写入者，角色成员具有对所有用户表进行增加、删除、修改的权限。
8）db_denydatareader：数据库拒绝数据读取者，角色成员不能读取数据库中任何表的内容。
9）db_denydatawriter：数据库拒绝数据写入者，角色成员不能对任何表进行增加、删修、修改操作。
10）public：是一个特殊的数据库角色，每个数据库用户都是public角色的成员，因此不能将用户、组或角色指派为public角色的成员，也不能删除public角色的成员。public数据库角色默认的权限很少[使用某些系统过程查看并显示master数据库中的信息；执行一些不需要一些权限的语句(例如PRINT)]。
可以利用系统函数IS_MEMBER检查当前用户是否是数据库角色或Windows域组的成员。
可以利用系统存储过程sp_helprolemember显示数据库角色的成员。
可以利用系统存储过程sp_helpuser报告有关当前数据库中数据库级主体的信息。
可以利用系统存储过程sp_helprotect报告当前数据库中某对象的用户权限或语句权限的信息。
--查询用户拥有的数据库角色
useyourdb
execsp_helpuser 'UserName'
go
--查询用户被赋予的权限
useyourdb
execsp_helprotect @username = 'user name'
0条评论