快捷導(dǎo)航

SQL Server數(shù)據(jù)庫錯(cuò)誤5123解決方案

更新時(shí)間：2020年06月17日 11:46:46 作者：歲月已走遠(yuǎn)

這篇文章主要介紹了SQL Server數(shù)據(jù)庫錯(cuò)誤5123解決方案,文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下

因?yàn)樽约河幸槐净赟QL Server 2005的數(shù)據(jù)庫教程，里邊使用的示例數(shù)據(jù)庫是AdventureWorks for SQL Server 2005，而我的機(jī)子上裝的是SQL Server 2008，示例數(shù)據(jù)庫是AdventureWorks for SQL Server 2008。起初我以為示例數(shù)據(jù)庫AdventureWorks for SQL Server 2005 與AdventureWorks for SQL Server 2008 數(shù)據(jù)庫結(jié)構(gòu)應(yīng)該差不多，可是在練習(xí)的過程中，我發(fā)現(xiàn)兩個(gè)數(shù)據(jù)庫中很多表的結(jié)構(gòu)還是有很多不一樣的地方。

于是決定到微軟下載中心將示例數(shù)據(jù)庫AdventureWorks for SQL Server 2005下過來，附加到SQL Server 2008上，以便順利進(jìn)行練習(xí)。

我以SQL Server 2008的超級(jí)管理員賬戶“sa”連接登錄到實(shí)例SQLSERVER2008：

在附加示例數(shù)據(jù)庫AdventureWorks for SQL Server 2005時(shí)，彈出了下圖這個(gè)錯(cuò)誤：

仔細(xì)看了一下主要信息“嘗試打開或創(chuàng)建物理文件......時(shí)，CREATE FILE遇到操作系統(tǒng)錯(cuò)誤 5(拒絕訪問。)”，一看就知道應(yīng)當(dāng)是對(duì)要附加的數(shù)據(jù)文件的操作權(quán)限不夠。按一般的思維習(xí)慣，我們會(huì)對(duì)操作權(quán)限不夠的文件授予足夠的操作權(quán)限。比如，有網(wǎng)友說“給要附加的數(shù)據(jù)文件和相應(yīng)的日志文件授予Everyone的權(quán)限”，授權(quán)過程如下三張截圖所示（注意數(shù)據(jù)文件和日志文件都必須授權(quán)）：

（圖1：授權(quán)數(shù)據(jù)文件）

（圖2：數(shù)據(jù)文件授權(quán)后）

（圖3：日志文件授權(quán)后）

對(duì)要附加的數(shù)據(jù)文件和日志文件分別授予Everyone【讀取和執(zhí)行】、【讀取】的權(quán)限后，在SQL Server 2008中重新嘗試附加數(shù)據(jù)庫，發(fā)現(xiàn)可以附加成功了！是不是問題就這樣解決了呢？這樣子做對(duì)嗎？如果在真實(shí)的數(shù)據(jù)庫管理過程中，我們把數(shù)據(jù)文件、日志文件的權(quán)限放大到Everyone，那肯定是不對(duì)的做法。

因?yàn)檫@樣數(shù)據(jù)庫的安全性將大打折扣，雖然對(duì)Everyone只授予了【讀取和執(zhí)行】、【讀取】的權(quán)限，但這仍然有泄漏數(shù)據(jù)的危險(xiǎn)。我們應(yīng)當(dāng)保證能正常訪問的情況下，使數(shù)據(jù)文件具有最小的訪問權(quán)。我們之前授權(quán)給Everyone，那所有用戶或賬戶都能操作相應(yīng)的文件了，這肯定不安全的。

那么如何才能授予最小的訪問權(quán)限呢？思考一下，我們用SQL Server 2008去附加相應(yīng)的數(shù)據(jù)文件，報(bào)出“拒絕訪問”即權(quán)限不夠的錯(cuò)誤，換句話說，當(dāng)前SQL Server 2008沒有權(quán)限訪問這些文件。我們右鍵文件，到文件屬性中查看一下文件的權(quán)限情況，如下圖所示：

（相應(yīng)數(shù)據(jù)文件原本的權(quán)限情況）

我們發(fā)現(xiàn)只有SYSTEM和xrm這兩個(gè)組或用戶才有權(quán)操作此數(shù)據(jù)文件。SYSTEM是一個(gè)用戶組，即【本地系統(tǒng)】組，而xrm是一個(gè)管理員用戶，如圖示：

（xrm用戶的信息）

SYSTEM用戶組和xrm這個(gè)管理員用戶都有權(quán)限操作此數(shù)據(jù)文件和日志文件，而以SQL Server2008的超級(jí)管理員SA連接登錄實(shí)例后，SQL Server卻沒有權(quán)限訪問此數(shù)據(jù)文件。換句話說，以SQL Server2008的超級(jí)管理員SA連接登錄實(shí)例后，登錄的身份不在SYSTEM用戶組，也不是xrm這個(gè)管理員。

那會(huì)是什么呢？我們查看一下當(dāng)前SQL Server 2008的實(shí)例服務(wù)的相關(guān)信息就知道了，打開Sql ServerConfiguration Manager (即SQL Server 配置管理器)查看一下當(dāng)前連接到的實(shí)例服務(wù)的相關(guān)信息,如下圖所示：

（當(dāng)前實(shí)例服務(wù)的相關(guān)信息）

發(fā)現(xiàn)當(dāng)前實(shí)例SQLSERVER2008的登錄身份為“NT AUTHORITY\LocalService”，即操作系統(tǒng)授權(quán)的【本地服務(wù)】，本地服務(wù)也是了個(gè)用戶組。換句話說，如果我們僅授予【本地服務(wù)】這個(gè)用戶組的權(quán)限（而不是Everyone），應(yīng)該也可以在SQL Server 2008中用sa的賬戶附加數(shù)據(jù)庫了。

為此，將剛剛授予相應(yīng)數(shù)據(jù)文件和日志文件Everyone的權(quán)限都刪除，再授予LocalService用戶組相應(yīng)數(shù)據(jù)文件和日志文件的權(quán)限，重新嘗試附加相應(yīng)的數(shù)據(jù)庫，發(fā)現(xiàn)的確可以附加成功！不必說，授予操作系統(tǒng)授權(quán)的【本地服務(wù)】用戶組比起授予Everyone來說肯定要安全的多。

上面提到的方法中，我們都是改變了數(shù)據(jù)文件原來的權(quán)限范圍（原來的權(quán)限范圍只有SYSTEM即【本地系統(tǒng)】用戶組和xrm這個(gè)系統(tǒng)管理員）。

而更好的辦法是不要改變數(shù)據(jù)文件的權(quán)限范圍，仍然以SA身份連接登錄SQL Server 2008的實(shí)例也能訪問相應(yīng)的數(shù)據(jù)文件。

而要達(dá)到這個(gè)目的，我們只需要將相應(yīng)實(shí)例的登錄身份改為SYSTEM【本地系統(tǒng)】用戶組，SYSTEM也是在相應(yīng)數(shù)據(jù)文件的權(quán)限范圍之內(nèi)的用戶組，而且SQL Server實(shí)例以本地系統(tǒng)身份運(yùn)行，安全性將更高。我們可以在SQL Server 配置管理器中將相應(yīng)的SQL Server實(shí)例的登錄身份修改為【本地系統(tǒng)】即Local System，如下列圖所示：

（修改實(shí)例的登錄身份）

（實(shí)例的登錄身份變?yōu)長ocalSystem）

然后重啟相應(yīng)實(shí)例服務(wù)，重新以SA身份連接登錄SQL Server 2008的相應(yīng)實(shí)例并嘗試附加數(shù)據(jù)庫，同樣可以成功的將數(shù)據(jù)庫附加上?。?！

其實(shí)，如果不是要特別地以SA身份連接登錄SQL Server 2008的相應(yīng)實(shí)例來附加相應(yīng)數(shù)據(jù)庫，那么在連接登錄SQL Server 2008的相應(yīng)實(shí)例時(shí)，身份驗(yàn)證選擇【W(wǎng)indows 身份驗(yàn)證】，不做前文中所述的其他修改就可以把數(shù)據(jù)庫附加上去了，原因就在于：【W(wǎng)indows 身份驗(yàn)證】用的是當(dāng)前操作系統(tǒng)的用戶的權(quán)限，權(quán)限一般都足夠大的。另外，在【SQL Server 配置管理器】中針對(duì)實(shí)例服務(wù)可以做的操作，在Windows的【服務(wù)】上也可以做到。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

您可能感興趣的文章: