SQL Server附加数据库出现错误5123的正确解决方法
因为自己有一本基于SQL Server 2005的数据库教程,里边使用的
示例数据库是AdventureWorks for SQL Server 2005,而我的机子上装的是SQL Server 2008,示例数据库是AdventureWorks for SQL Server 2008。起初我以为示例数据库AdventureWorks for SQL Server 2005 与AdventureWorks for SQL Server 2008 数据库结构应该差不多,可是在练习的过程中,我发现两个数据库中很多表的结构还是有很多不一样的地方。于是决定到微软下载中心将示例数据库AdventureWorks for SQL Server 2005下过来,附加到SQL Server 2008上,以便顺利进行练习。我以SQL Server 2008的超级管理员账户“sa”连接登录到实例SQLSERVER2008:
在附加示例数据库AdventureWorks for SQL Server 2005时,弹出了下图这个错误:
![](https://i-blog.csdnimg.cn/blog_migrate/b3264a17e0dd0cc551fd31dbd8617851.png)
![](https://i-blog.csdnimg.cn/blog_migrate/905bd58485ab14b8c1ab395f76338643.png)
仔细看了一下主要信息“
尝试打开或创建物理文件......时,CREATE FILE遇到操作系统错误 5(拒绝访问。)” ,一看就知道应当是对要附加的数据文件的操作权限不够。 按一般的思维习惯,我们会对操作权限不够的文件授予足够的操作权限。比如,有网友说“给要附加的数据文件和相应的日志文件授予Everyone的权限”,授权过程如下三张截图所示(注意数据文件和日志文件都必须授权):
![](https://i-blog.csdnimg.cn/blog_migrate/a8e913327c28468474c9fc775fa38da3.png)
(图1:授权数据文件)
![](https://i-blog.csdnimg.cn/blog_migrate/922164cc1bed2e3ac27b72c81ded651a.png)
(图2:数据文件授权后)
![](https://i-blog.csdnimg.cn/blog_migrate/af4197440a3dab35c041b7d73221675c.png)
(图3:日志文件授权后)
对要附加的数据文件和日志文件分别授予Everyone【读取和执行】、【读取】的权限后,在SQL Server 2008中重新尝试附加数据库,发现可以附加成功了!
是不是问题就这样解决了呢?这样子做对吗? 如果在真实的数据库管理过程中,我们把数据文件、日志文件的权限放大到Everyone,那肯定是不对的做法。因为这样数据库的安全性将大打折扣,虽然对Everyone只授予了【读取和执行】、【读取】的权限,但这仍然有泄漏数据的危险。
我们应当保证能正常访问的情况下,使数据文件具有最小的访问权。我们之前授权给Everyone,那所有用户或账户都能操作相应的文件了,这肯定不安全的。那么如何才能授予最小的访问权限呢?思考一下,我们用SQL Server 2008去附加相应的数据文件,报出“拒绝访问”即权限不够的错误,换句话说,当前SQL Server 2008没有权限访问这些文件。我们右键文件,到文件属性中查看一下文件的权限情况,如下图所示:
![](https://i-blog.csdnimg.cn/blog_migrate/d4d6a545228fcc9c4cfaa85642bc5be6.png)
(相应数据文件原本的权限情况)
我们发现只有SYSTEM和xrm这两个组或用户才有权操作此数据文件。SYSTEM是一个用户组,即【本地系统】组,而xrm是一个管理员用户,如图示:
![](https://i-blog.csdnimg.cn/blog_migrate/c18bf899e583abc4ae9a3ad6103346e4.png)
(xrm用户的信息)
SYSTEM用户组和xrm这个管理员用户都有权限操作此数据文件和日志文件,而以SQL Server 2008的超级管理员
SA连接登录实例后,SQL Server却没有权限访问此数据文件。换句话说,以SQL Server 2008的超级管理员SA连接登录实例后,登录的身份不在SYSTEM用户组,也不是xrm这个管理员。那会是什么呢?
我们查看一下当前SQL Server 2008的实例服务的相关信息就知道了,打开
Sql Server Configuration Manager (即SQL Server 配置管理器)查看一下当前连接到的实例服务的相关信息,如下图所示:
![](https://i-blog.csdnimg.cn/blog_migrate/976f8499c6462b8d08ee2f478ffb88ad.png)
(当前实例服务的相关信息)
发现当前实例SQLSERVER2008的登录身份为“NT AUTHORITY\LocalService”,即操作系统授权的【本地服务】,本地服务也是了个用户组。换句话说,如果我们仅授予【本地服务】这个用户组的权限(而不是Everyone),应该也可以在SQL Server 2008中用sa的账户附加数据库了。为此,将刚刚授予相应数据文件和日志文件Everyone的权限都删除,再授予LocalService用户组相应数据文件和日志文件的权限,重新尝试附加相应的数据库,发现的确可以附加成功!不必说,授予操作系统授权的【本地服务】用户组比起授予Everyone来说肯定要安全的多。
上面提到的方法中,我们都是改变了数据文件原来的权限范围(原来的权限范围只有SYSTEM即【本地系统】用户组和xrm这个系统管理员) 。而更好的办法是不要改变数据文件的权限范围,仍然以SA身份连接登录SQL Server 2008的实例也能访问相应的数据文件。而要达到这个目的,我们只需要将相应实例的登录身份改为SYSTEM【本地系统】用户组,SYSTEM也是在相应数据文件的权限范围之内的用户组,而且SQL Server实例以本地系统身份运行,安全性将更高。我们可以在SQL Server 配置管理器中将相应的SQL Server实例的登录身份修改为【本地系统】即Local System,如下列图所示:
![](https://i-blog.csdnimg.cn/blog_migrate/e3916e169d61971fd99514b161c9593d.png)
(修改实例的登录身份)
![](https://i-blog.csdnimg.cn/blog_migrate/2d0e1b865b15c88c995fdeb86f81eb9e.png)
(实例的登录身份变为LocalSystem)
然后重启相应实例服务,重新以SA身份连接登录SQL Server 2008的相应实例并尝试附加数据库, 同样可以成功的将数据库附加上!!!
其实,如果不是要特别地以SA身份连接登录SQL Server 2008的相应实例来附加相应数据库,那么在连接登录SQL Server 2008的相应实例时,身份验证选择【Windows 身份验证】,不做前文中所述的其他修改就可以把数据库附加上去了,原因就在于:【Windows 身份验证】用的是当前操作系统的用户的权限,权限一般都足够大的。另外,在【SQL Server 配置管理器】中针对实例服可以做的操作,在Windows的【服务】上也可以做到。
![](https://i-blog.csdnimg.cn/blog_migrate/8547be3ce88a7ee9507b1356a30aa350.png)