'用戶 'sa' 登錄失敗。該用戶與可信 SQL Server 連接無關聯 問題一、忘記了登錄Microsoft SQL Server 2005 的sa的登錄密碼 解決方法:先用windows身份驗證的方式登錄進去,然後在‘安全性’-‘登錄’-右鍵單擊‘sa’-‘屬性’,修改密碼點擊確定就可以了。 問題二、已成功與服務器建立連接,但是在登錄過程中發生錯取。(provider:共享內存提供程序,error:0-管道的另一端上無任何進程。)(Microsoft SQL Server,錯誤:233) 解決方法:打開‘程序’-‘所有程序’-‘Microsoft SQL Server 2005 ’-‘配置工具’-‘SQL Server 配置管理器’,在彈出的窗體中,找到‘SQL Server 2005 網絡配置’,把‘MSSQLSERVER的協議’下的“Named Pipes”和“TCP/IP”啓動,然後重新啓動Microsoft SQL Server 2005就可以了。 問題三、無法打開用戶默認數據庫。登錄失敗。用戶‘sa’登錄失敗。(Microsoft SQL Server, 錯誤:4064) 解決方法:先用windows身份驗證的方式登錄進去,然後在‘安全性’-‘登錄’-右鍵單擊‘sa’-‘屬性’,將默認數據庫設置成master,點擊確定就可以了。 問題四、sql server 2005 錯誤 18452 無法連接到服務器 服務器:消息18452, 級別16,狀態1 [Microsoft][ODBC SQL Server Driver][SQL Server]用戶‘sa’登陸失敗。原因:未與信任SQL Server連接相關聯 該錯誤產生的原因是由於SQL Server使用了"僅 Windows"的身份驗證方式,因此用戶無法使用SQL Server的登錄帳戶(例如 sa )進行連接,解決方法如下 設置允許SQL Server身份登錄 (基本上這個很有用) 操作步驟: 1。在企業管理器中,展開"SQL Server組",鼠標右鍵點擊SQL Server服務器的名稱 2。選擇"屬性" 3。再選擇"安全性"選項卡 4。在"身份驗證"下,選擇"SQL Server和 Windows" 5。確定,並重新啓動SQL Server服務 問題五、用戶 'sa' 登錄失敗。該用戶與可信 SQL Server 連接無關聯。 解決方法:檢查你的數據庫的認證模式,windows 和 混合模式,需要SA登陸的請選擇混合模式。 檢查計算機1433連接端口,1434數據端口是否打開 針對sql 2005 進入管理器中“安全”==》“用戶”==》雙擊用戶(彈出屬性對話框)==》“狀態”把狀態改成enable,退出管理器重新登錄(用戶驗證模式) 即:右鍵數據庫屬性對話框,選擇“安全性”選項卡,服務器身份驗證模式選擇“SQL Server和Windows身份驗證模式 。然後重新配置sa的登陸信息即可。 SQL SERVER 2005使用sa 登錄失敗-提示該用戶與可信 SQL Server 連接無關聯 錯誤提示: sa 登錄失敗,提示該用戶與可信 SQL Server 連接無關聯 解決方法: 打開SQL Server Management Studio Express, 右鍵點擊服務器,選擇Properties(屬性),在彈出窗口中點擊Security(安全)切換到安全面板, 將server authentication服務器認證從windows authentication mode(windows用戶認證模式) 修改爲Sql Server and Windows Authentication mode(Sql server和windows認證模式),ok。 打開security(安全性) -- logins(登錄名) ,右鍵選中sa,選擇properties(屬性),點擊Status(狀態)切換到狀態面板,將Login(登錄)設置爲Enabled(啓用)。 切記:一定要把SQL2005服務重啓才生效。
你所不知道的SQL Server數據庫啓動過程,以及啓動不起來的各種問題的分析及解決技巧
目前SQL Server數據庫作爲微軟一款優秀的RDBMS,其本身啓動的時候是很少出問題的,我們在平時用的時候,很少關注起啓動過程,或者很少了解其底層運行過程,大部分的過程只關注其內部的表、存儲過程、視圖、函數等一系列應用方式,而當有一天它運行的正常的時候突然啓動不起來了,這時候就束手無策了,能做的或許只能是重裝、配置、還原等,但這一個過程其實是一個非常耗時的過程,尤其當我們面對是龐大的生產庫的時候,可能在這火燒眉毛的時刻,是不允許你再重搭建一套環境的。
所以作爲一個合格的數據庫使用者,我們要了解其啓動、運行過程的事情,一旦發生問題,我們也能及時定位,迅速解決。
閒言少敘,我們進入本篇的正題。
SQL Server本身就是一個Windows服務,每一個實例對應的就是一個sqlserver.exe進程。這是一個可執行的文件,默認就放在SQL Server的安裝目錄下,當我們啓動的時候,就是直接調用這個文件,然後啓動這個服務。
第一部分、SQL Server實例啓動的方法和啓動所發生的問題
SQL Server實例分爲下面幾種啓動方法:
(1)在Windows服務控制檯裏手動啓動,或者自動啓動(默認),這個也是最常用的方式
(2)第二種方式是SQL Server本身自己提供的啓動方式,我們這裏可以手動啓動
(3)在SQL Server的SSMS裏面手動啓動它,這個方式一般大部分利用這種方式進行手動重啓
(4)通過Windows命令窗口,用'net start'命令手動啓動,這種方法也可以用
以上這幾種方式都可以啓動SQL Sever,並且都會在SQL 日誌信息中有所記錄。
----------------------------------------------------------霸氣的分割線-----------------------------------------------------------------------
第二部分、SQL Server實例啓動的詳細過程以及所發生的問題項
第一步、檢查註冊表項
當一個sqlserver.exe文件開始啓動的時候,首先要乾的第一件事就是先檢查它的配置信息存放於註冊表的值項
比較重要的幾個鍵值有下面幾個:
這裏的
AuditLevel:其實就是SQL 如何記錄用戶登錄記錄;
LoginMode:是SQL Server服務器身份驗證方式等;
BackupDirectory:默認的備份路徑等信息;
關於註冊表信息簡要了解即可,不建議做任何修改,當然這些值的信息默認在SQL Server中都能設置:
在不修改註冊表的情況下,一般這一步的啓動順序一般不會出現問題,當然出現問題了也通常沒有辦法解決,大部分的解決方式只有重裝了。
但這一步驟,通常出現以下兩個個問題通常是可以解決的:
<1>啓動賬號權限問題
如果我們啓動SQL Server的進程使用的賬號連讀註冊表的權限都沒有,那這個服務是怎麼也啓動不了的,通常這時候連SQL 的錯誤日誌都沒有能力生成出來。
這時候我們該如何發現呢,雖然這時候它沒有能力創建SQL 的錯誤日誌,但是它在Windows層面留下了痕跡,我們來看:
我將服務啓動賬號設置成gust來賓賬號,來啓動該服務
這時候會產生以下錯誤信息:
在Windows的日誌信息裏也會產生一條錯誤日誌記錄:
這裏的拒絕訪問指的就是拒絕訪問註冊表信息了。
解決方法:
此問題的解決方式就很簡單了,只需要將當然的用戶提權到SQL Server服務的啓動賬號就行了,提權的方式也很簡單,只需要添加到SQL的本地用戶的啓動服務組就可以了。
當然,也可以直接換一個更高級別的用戶登錄。一般默認都用的超級管理員賬戶。
<2>訪問日誌和文件夾出現問題
默認在SQL Server啓動的時候會創建一個啓動日誌文件,記錄所有正確的日誌信息,當然也包括錯誤的日誌信息,如果這時候找不到這個日誌信息的路徑,或者已經存在一個日誌,但是日誌被鎖定了(某些NB的殺毒軟件擅長幹這個),這時候這個服務也是啓動不了的,同樣也創建不出SQL Server的日誌文件,這時候我們還得藉助於Windows平臺本身,來解決。
SQL Server啓動的創建的日誌文件路徑,同樣存在於註冊表項裏,我們來看這個參數:
這裏我們故意改成一個錯誤的路徑,來啓動下看看:
會產生以下錯誤
系統的錯誤日誌信息
錯誤說明的很清楚。
解決方法:
這個問題解決起來也很簡單,只需要檢查好該路徑,確保路徑下的文件正確就可以。
不過有一點需要注意,當SQL Server還沒啓動起來的時候,有部分錯誤信息日誌需要檢查Windows平臺下的系統日誌。
----------------------------------------------------------霸氣的分割線-----------------------------------------------------------------------
第二步、檢查系統配置環境,包括硬盤、內存與CPU等
當我們進行完第一步的時候,SQL Server已經讀取完註冊表信息,完成了它的errorlog文件的創建,然後開始進行第二步的進行,這一步驟所有的信息就會按照順序依次記錄到errorlog文件中,我們可以通過查看該文件來詳細跟蹤這一步驟的進行,根據上一步的註冊表信息,我們先來手動清空下這個日誌,然後重啓一下SQL Server服務,查看下這個日誌記錄
我們簡單大致分了以下幾大步驟:
一、首先檢查系統的軟件環境,包括OS版本、電腦信號、內存、硬盤、註冊表基礎配置項是否正確等
二、啓動系統數據庫master
三、開始利用服務用戶登錄系統、啓動系統資源數據庫、檢查數據庫版本信息等
四、啓動系統數據庫model
五、開始網絡配置進行連接,對外提供服務,使用的默認的1433端口
我們接着分析下面的日誌:
六、其實完成上面的第五步之後,也就開始啓動msdb系統數據庫
七、這時候開始真正的啓動用戶數據庫,並且完整各個庫的完整性校驗,並且在啓動用戶數據庫之前,先將系統庫的tempdb進行清空
八、在搭建完成之後,纔開始啓系統的另外一個數據庫tempdb
上面的整個SQL Server系統啓動的過程產生了詳細的日誌記錄,我們下面會依次按照該步驟進行詳細的進行逐步分析。
在檢查系統軟硬件環境的過程中,基本不會發生什麼致命錯誤。比較常見的問題就是內存配置問題,其實在上面的日誌記錄中有一句特別重要,它反映的就是SQL Server利用內存的情況,我們來看:
這句話的意思是將所有的數據頁鎖定到內存中,作爲大部分數據庫而言,內存就是生命線,SQL Server同樣也是,如果系統(64bit中)沒有內存壓力的情況下,才能將數據頁正常的鎖定到內存中,如果內存壓力過大,系統內存是不允許將數據頁也加入到內存中,而這樣導致的問題就是SQL Server嚴重的性能問題。
很多用戶希望限制SQL Server內存使用,並且有些客戶機將它限制到服務都不能啓動的情況,這時候在SQL Server的日誌中是這樣展現的,我們來看:
可以看到,該錯誤的原因還是挺清楚的,修復該錯誤的解決方法也很簡單,將內存配置調大就可以。
跟內存有關的還有一種特殊的情況,就是SQL Server的啓動賬號在服務器上沒有Lock page in memory的權限,如果沒有這個權限,在明細日誌中查看不到上面的日誌記錄,該問題的解決方法也很簡單,只需要將需要權限加上就可,加權限的方式如下:
經過上面的步驟基本,完成數據的軟硬件檢測過程。
----------------------------------------------------------霸氣的分割線-----------------------------------------------------------------------
第三步、啓動系統數據庫master
master數據庫是SQL Server系統啓動過程中的第一個系統庫,是非常關鍵的數據庫。如果這個庫不能被正常打開,則SQL Server就不能正常啓動。
和其它數據庫一樣,master數據庫也分爲數據文件和日誌文件,啓動的過程是依次打開,然後做恢復動作,如果這個過程沒問題的話,在Errorlog日誌文件中,我們會看到如下的這句話:
如果這個過程出現了任何問題,SQL Server的啓動過程都會被中斷,啓動過程失敗。
而這個過程發生的錯誤,無非就集中以下幾種情況,我們來分析一下:
<1>在指定的路徑找不到master數據的數據文件或日誌文件
關於這個SQL Server的最主要的系統數據庫的路徑,它是以註冊表形式存在的,在一下註冊表項,可以看到
如果在該路徑下找不到這個系統數據庫的話,服務是啓動不了的,並且會產生相應的錯誤日誌信息,我們來模擬下,關掉服務,將這兩個文件移除走,然後啓動看一下:
首先,該服務是啓動失敗的
我們來看一下系統日誌
看Errorlog的日誌信息
可以看到,該問題提示錯誤信息還是挺詳細的。我們來看第二種情況
<2>文件找到了,但是沒有權限訪問,或者不能以排他的方式打開該文件(默認的是獨佔鎖進行文件打開的)
此種情況也是有可能產生的,比如某些NB的殺毒軟件就可以幹這個事,讓你的系統庫無法訪問,這樣同樣也是啓動不了的,我們這樣來看,提示的錯誤的信息有哪些:
來看Errorlog的錯誤記錄:
<3>文件找到了,訪問權限也有,但是文件有問題,就是說是數據庫損壞了
這個問題也經常出現,比如磁盤壞掉了,恢復後發現文件有問題,不能正常打開,這種問題我們來看錯誤信息:
日誌中的信息
關於master系統庫的啓動過程,基本就是上面的三種錯誤,關於這三種問題,我們該如何解決呢?
解決方法:首先如果根據錯誤日誌定位出問題的性質,如果是前兩種問題其實是挺好解決的,比如文件沒找到、權限項不對等,這些問題相應的去解決就可以,最棘手的就是第三種情況,出現這種情況最理想的情況是master數據庫進行了備份,通過備份文件進行恢復就可以,一切就可以正常,當然通過暴力的停掉服務,拷貝文件進去也可以解決。
最揪心的就是這個庫就沒備份,那該如何解決呢?這種方式的解決就得藉助SQL Server的安裝程序,進行重建master數據了,但是這種方式重建的master數據庫會導致以前的SQL Server的設定全部清空掉。
清空的信息包括:所有的賬戶信息(意味着需要重建)、msdb中的所有job信息等(也需要重建)、用戶數據庫信息(必須全部重新附加attch上)
而這一系列過程如果是一個生產庫,可能會是一個非常大的工作量!
----------------------------------------------------------霸氣的分割線-----------------------------------------------------------------------
第四步、啓動系統資源數據庫,並檢查數據版本信息
資源數據庫是SQL Server2005中引入的邏輯數據庫,在實例下是看不到的,但是有它的物理文件,主數據庫默認名稱爲:mssqlsystemresource.mdf、日誌名稱爲:mssqlsystemresource.ldf
如果該數據庫啓動的過程中也出現了問題,那SQL Server也不能正常啓動。
這個系統數據庫比較特別,它是一個只讀數據庫,完全由SQL Server自己維護,用戶是不能更改的,所以我們只要保證它的是數據庫文件和日誌完好就可以,不需要對它進行任何的跟蹤和維護。
當然如果非要看這個數據庫,可以通過單用戶的DAC方式進行連接。
所以這個數據庫在一般情況下不會發生意外,基本上是能正常啓動,不過特殊情況下,不能啓動的情況就以下兩種:
<1>數據庫文件不存在,無法訪問,或者文件壞掉了
其實它的報的錯誤信息,類似於上面的master數據庫,我來截個圖,看一下:
這個是errorlog記錄的錯誤信息
在windows層面也有它自己的錯誤日誌信息:
<2>資源數據庫的版本和SQL Server的版本不一致
這個有可能是人爲的更改了這個資源數據庫,導致現有的資源數據庫文件和數據庫版本不一致,這樣的話也會導致錯誤的形成
windwos平臺也記錄下了該錯誤的信息,看下面的圖片:
解決方法:
關於資源庫的這兩個問題解決方法,非常的簡單。只要找到和這臺服務器上的SQL Server的版本一致的數據庫,拷貝過來就行。
當然最好的預防措施是:每當安裝完SQL Server或者打完補丁之後,就及時的備份這個兩個文件,放在安全的地方,用的時候拷貝過來就行,備份是數據庫管理員的天職
當然有時候在緊急的情況下,找不到相同版本的數據庫,理論上這個庫是隻讀的,所以不會發生任何改變,我們隨便找一臺機器,安裝一下同版本數據庫,然後拷貝過來就行,當然一定注意的是這裏面是相同版本。
----------------------------------------------------------霸氣的分割線-----------------------------------------------------------------------
第五步、啓動系統數據庫model
model系統數據庫同樣也是SQL Server啓動過程中用到的一個非常關鍵的數據庫,如果這個庫損壞,SQL Server啓動也會失敗,關於model數據不能啓動的原因基本和master的類似,同樣也是兩種:1、數據庫文件早不到或者不能訪問;2、數據庫文件能訪問但是是損壞的文件。
診斷此種問題的方式也和上面的兩種方式一樣,查看啓動過程產生的errorlog文件或者windows系統日誌,這裏我們就不重現該問題了。
我們只給出此種問題的解決方法:
1、如果該庫我們已經做過備份,那最直接也是最有效的解決方式就是直接還原,這裏的還原方式可能和普通庫的還原方式不一樣,因爲SQL Server實例還沒有啓動,我們恢復過程採取以下過程:
a.用參數啓動SQL Server,在命令提示行中執行以下命令,這樣的話SQL Server啓動就會跳過model數據庫恢復這一步
net start MSSQLSERVER /f /m /T3608
b.現在恢復model數據庫,打開SSMS,直接輸入
RESTORE DATABASE model FROM DISK ='G:\data\model.bak' WITH MOVE 'modeldev' TO 'E:\dataDefaultFileManger\MSSQL10.MSSQLSERVER\MSSQL\DATA\model.mdf' MOVE 'modellog' TO 'E:\dataDefaultFileManger\MSSQL10.MSSQLSERVER\MSSQL\DATA\model.ldf' ,replace
c.恢復成功後,直接重啓SQL Server既可以。
2、將SQL Server關閉,然後直接採取暴力的方式將model數據文件拷貝回來就可以,這種方式簡單有效,但是非常規操作
3、還有一種方式是利用setup安裝文件,重建該數據庫,過程緩慢,稍顯複雜,很不推薦。
----------------------------------------------------------霸氣的分割線-----------------------------------------------------------------------
第六步、開始網絡配置進行連接,對外提供服務,使用的默認的1433端口
當上面的幾個重要的系統庫都已經啓動完成之後,下一步就是開始檢查網絡環境,進行網絡服務的配置,對外進行提供服務了,一般來講,在SQL Server中利用的網絡啓動協議有三種:Shared Memory、Named Pope和TCP/IP,其實在日常我們最常用的就是TCP/IP這種方式了,並且默認開啓的是1433端口。
我們來看一下正常啓動過程中,該部分的詳細日誌:
這裏面的Shared Memory是專供本地連接通過LPC(Local Procedure Call)技術向SQL Server做的連接。它不走網絡層,所以他是速度最快的連接方式。正常啓動後會顯示上面的正常日誌。
Named Pipe方式正常啓動,也會顯示出上面的日誌。可以看到。
這其中我們最常用的TCP/IP這種方式,也正常的啓動了,並且指定了兩種訪問方式,ipv4/ipv6,然後後面加上了1433端口號。
在這個過程中最常出現的問題就是,1433端口被其它程序佔用,這樣就導致TCP/IP協議無法正常啓動,這樣我們會看到如下日誌信息
並且在windows 系統日誌中也會有記錄
解決方法:
其實這裏出現的問題還是挺好解決的,只需要找到佔用這個端口的應用程序,採取措施讓它把這個端口給讓出來就可以。
當然出現這些問題就意味着客戶端已經無法通過TCP/IP這種遠程連接的方式進行連接訪問了。
這時候一般管理員可以採用SQL Server給其提供的“專用管理員連接”(DAC)進行連接,這種方式我們以後再介紹。
當然,在SQL Server啓動的過程中,一般出現這種網絡問題,或者協議不能成功加載,SQL Server會報出錯誤信息,但是一般情況下是不會影響SQL Server的正常啓動的。受影響的可能只是出問題的那種協議功能。
我們只需要根據日誌,定位問題,然後解決掉,重新啓動就可以了。
----------------------------------------------------------霸氣的分割線-----------------------------------------------------------------------
第七步、開始啓動msdb系統數據庫
關於msdb這個系統數據庫,它是被安排在系統庫中接近最後一個了,除了用戶數據庫和臨時庫tempdb之外,當啓動過程中已經進行到這一步的時候,其實我們的實例就已經啓動起來了,並且能夠連接。
我們知道msdb這個庫中主要的存儲的信息是應用各個庫的備份信息,各種job的歷史跑批信息等,其實諸多的都是來自於用戶數據庫所產生的一些客觀數據。
我們來看一下這個庫出現了問題會產生什麼現象:
我將這個庫文件移除走,然後重新啓動服務,啓動過程中沒有報任何錯誤,並且能夠順利啓動,我們用SSMS直接連接過去,也可以正常連接
但是當我們點擊開數據的時候,其實是看不到任何用戶數據庫的,並且會產生一個錯誤提示:
看來是不能使用的,我們來查看一下錯誤日誌:
雖然這個庫的重要性比起master之類的庫重要性要稍顯差一些,但是缺少了它我們的SQL Server雖然能啓動,但是依然不能使用。
解決方法:
要解決這個問題其實方式就很多種了,因爲到此我們的SQL Server實例已經能夠正常啓動了,我們可以採取:
1、利用備份還原該庫,參考文章前面的方式(推薦)
2、關掉服務,利用暴力的拷貝文件的方式進行恢復,簡單有效,非常規操作
3、找臺相同的環境,找到相同的文件,直接拷貝過來使用
4、利用安裝文件進行恢復(不推薦)
----------------------------------------------------------霸氣的分割線-----------------------------------------------------------------------
第八步、啓動用戶數據庫,並且完整各個庫的完整性校驗,並且在啓動用戶數據庫之前,先將系統庫的tempdb進行清空
本步驟所遇到的問題層出不窮,各種樣式,我打算再重新組織一篇文章,專門列舉,此篇就不介紹了。
但有一點需要記住:在這一步之前SQL Server會將tempdb這個系統庫清空掉,也就是說,每次的重啓操作,系統都會將tempdb清空,然後重建,這一步一般不會發生異常,成功之後會出現以下日誌信息:
第九步、開始重建系統的另外一個數據庫tempdb
tempdb這個庫比較特殊,每次重啓的時候都是重新創建的,SQL Server會根據master數據庫裏的記錄的信息以model數據庫爲版本進行創建。所以只要我們保證model數據庫沒有問題,然後硬盤沒有問題,tempdb的數據庫文件就應該沒有問題。
關於temdb這個庫的所有配置信息是存儲於master的數據庫中的,裏面的內容信息是存儲於model系統庫中的
這樣就帶來了一個問題,有時候我們的master的庫是從別的機器下面備份下來的,所以它裏面會記錄這個tempdb這個庫在原來機器上的路徑,這樣在啓動創建的時候就會報錯。
所以我們需要執行以下命令更改這個庫路徑
a、用參數啓動SQL Server
net start MSSQLSERVER /f /m /T3608
b.修改數據文件和日誌文件路徑
ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,FILENAME='C:\right path....\temdb.mdf'); go ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,FILENAME='C:\right path....\temdblog.ldf'); go
c.正常啓動數據庫既可以
還有一種情況,就是創建該文件的時候,提供的硬盤空間不足,或者權限不夠,我們也是根據上面的方式,修改到一個正確的路徑,並且確保權限正確。
也可以更改temp文件的大小,默認是4M,代碼如下:
ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,SIZE=100MB); go ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,SIZE=100MB); go
至此,如果上面的整個過程都沒出問題的話,一個正常的SQL Server就可以啓動成功的。
文章轉載自:http://www.cnblogs.com/zhijianliutang/p/4085546.html