SQL Server数据库错误5123解决方案

在数据库实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《SQL Server数据库错误5123解决方案》，聊聊错误、数据库、SQLServer，希望可以帮助到正在努力赚钱的你。

因为自己有一本基于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时，弹出了下图这个错误：

仔细看了一下主要信息“尝试打开或创建物理文件......时，CREATE FILE遇到操作系统错误 5(拒绝访问。)”，一看就知道应当是对要附加的数据文件的操作权限不够。 按一般的思维习惯，我们会对操作权限不够的文件授予足够的操作权限。比如，有网友说“给要附加的数据文件和相应的日志文件授予Everyone的权限”，授权过程如下三张截图所示（注意数据文件和日志文件都必须授权）：

（图1：授权数据文件）

（图2：数据文件授权后）

（图3：日志文件授权后）

对要附加的数据文件和日志文件分别授予Everyone【读取和执行】、【读取】的权限后，在SQL Server 2008中重新尝试附加数据库，发现可以附加成功了！是不是问题就这样解决了呢？这样子做对吗？ 如果在真实的数据库管理过程中，我们把数据文件、日志文件的权限放大到Everyone，那肯定是不对的做法。

因为这样数据库的安全性将大打折扣，虽然对Everyone只授予了【读取和执行】、【读取】的权限，但这仍然有泄漏数据的危险。 我们应当保证能正常访问的情况下，使数据文件具有最小的访问权。我们之前授权给Everyone，那所有用户或账户都能操作相应的文件了，这肯定不安全的。

那么如何才能授予最小的访问权限呢？思考一下，我们用SQL Server 2008去附加相应的数据文件，报出“拒绝访问”即权限不够的错误，换句话说，当前SQL Server 2008没有权限访问这些文件。我们右键文件，到文件属性中查看一下文件的权限情况，如下图所示：

（相应数据文件原本的权限情况）

我们发现只有SYSTEM和xrm这两个组或用户才有权操作此数据文件。SYSTEM是一个用户组，即【本地系统】组，而xrm是一个管理员用户，如图示：

（xrm用户的信息）

SYSTEM用户组和xrm这个管理员用户都有权限操作此数据文件和日志文件，而以SQL Server2008的超级管理员SA连接登录实例后，SQL Server却没有权限访问此数据文件。换句话说，以SQL Server2008的超级管理员SA连接登录实例后，登录的身份不在SYSTEM用户组，也不是xrm这个管理员。

那会是什么呢？ 我们查看一下当前SQL Server 2008的实例服务的相关信息就知道了，打开Sql ServerConfiguration Manager (即SQL Server 配置管理器)查看一下当前连接到的实例服务的相关信息,如下图所示：

（当前实例服务的相关信息）

发现当前实例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，如下列图所示：

（修改实例的登录身份）

（实例的登录身份变为LocalSystem）

然后重启相应实例服务，重新以SA身份连接登录SQL Server 2008的相应实例并尝试附加数据库，同样可以成功的将数据库附加上！！！

其实，如果不是要特别地以SA身份连接登录SQL Server 2008的相应实例来附加相应数据库，那么在连接登录SQL Server 2008的相应实例时，身份验证选择【Windows 身份验证】，不做前文中所述的其他修改就可以把数据库附加上去了，原因就在于：【Windows 身份验证】用的是当前操作系统的用户的权限，权限一般都足够大的。另外，在【SQL Server 配置管理器】中针对实例服务可以做的操作，在Windows的【服务】上也可以做到。

到这里，我们也就讲完了《SQL Server数据库错误5123解决方案》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于mysql的知识点！