故障排除(數(shù)據(jù)庫引擎)

1、故障排除（數(shù)據(jù)庫引擎）1. 故障排除概念本節(jié)包含有關(guān)排除 SQL Server 數(shù)據(jù)庫引擎 故障的信息。1.1 數(shù)據(jù)收集器故障排除 提供有關(guān)數(shù)據(jù)收集器常見問題的疑難解答信息。本主題解決以下類別的疑難問題：· 錯誤情況。此類別包含對象模型和運行時錯誤。· 性能問題。此類別包含一般和特定的性能情況。· 系統(tǒng)掛起。此類別包含數(shù)據(jù)收集過程中發(fā)生的子組件掛起。1.1.1 錯誤情況錯誤可能會由對象模型或在運行時引發(fā)。 對象模型錯誤數(shù)據(jù)收集器對象模型是一種托管 API，它提供一種編程方式來管理數(shù)據(jù)收集器屬性和數(shù)據(jù)收集組。對象模型是為數(shù)據(jù)收集器提供配置機制的一組存儲

2、過程和視圖周圍的薄包裝。有關(guān)詳細信息，請參閱數(shù)據(jù)收集器編程。對象模型錯誤可能來自對象模型的下列組件之一：· Transact-SQL 錯誤由從其中一個數(shù)據(jù)收集器存儲過程調(diào)用的存儲過程或 Transact-SQL 代碼引發(fā)。· Transact-SQL 錯誤由數(shù)據(jù)收集器存儲過程直接引發(fā)。· 托管異常由對象模型直接引發(fā)。下表說明了對象模型可能引發(fā)的錯誤。錯誤消息 錯誤號 說明 無法更新活動收集組 '%s' 的名稱、目標(biāo)、proxy_id 或 collection_mode。請停止該收集組，然后再次嘗試將其更新。14669試圖更新活動收集組。必須先停止收

3、集組，然后才能進行任何該類型的更新。當(dāng)收集組處于活動狀態(tài)時，只能更改上載計劃。無法刪除活動收集組 '%s'。請停止該收集組，然后再次嘗試將其刪除。14670試圖刪除正在運行的收集組。無法更新活動收集組 '%s' 中收集項 '%s' 的名稱或參數(shù)。請停止該收集組，然后再次嘗試更新該收集項。14671試圖更新正在運行的收集組中的收集項。無法刪除活動收集組 '%s' 中的收集項 '%s'。請停止該收集組，然后再次嘗試刪除該收集項。14672試圖刪除正在運行的收集組中的收集項。無法刪除收集器類型 '%s'。

4、請刪除與此收集器類型關(guān)聯(lián)的所有收集項，然后再次嘗試將其刪除。14673試圖刪除具有關(guān)聯(lián)的收集項的收集器類型。無法上載非活動收集組 '%s' 的數(shù)據(jù)。請啟動該收集組，然后再次嘗試上載數(shù)據(jù)。14674試圖上載由未在運行的收集組收集的數(shù)據(jù)。無法更新名稱、目標(biāo)、proxy_id、logging_level 或 collection_mode，或者無法向活動收集組 '%s' 添加收集項。請停止該收集組，然后再次嘗試將其更新。14675試圖更新正在運行的收集組。該用戶無權(quán)更改 '%s'。該用戶必須是數(shù)據(jù)收集器角色 '%s' 的成員。14676

5、用戶試圖更新只能由特定數(shù)據(jù)收集器角色更改的屬性。該用戶無權(quán)執(zhí)行此操作。該用戶必須是數(shù)據(jù)收集器角色 '%s' 的成員。14677用戶試圖執(zhí)行某操作，但不是所需的數(shù)據(jù)收集器角色的成員。外部用戶已停止并關(guān)閉了 ID 為 %d 的 SQL Server 跟蹤。SQL Server 跟蹤收集器將嘗試重新創(chuàng)建該跟蹤。14678由數(shù)據(jù)收集器創(chuàng)建并使用的跟蹤已在收集器運行時之外停止和關(guān)閉。此數(shù)據(jù)倉庫中指定的 %s (%s) 無效。14679傳遞給管理數(shù)據(jù)倉庫中某個存儲過程的參數(shù)的值與倉庫中的其他條目不匹配。只能對運行 SQL Server 2005 或更高版本的服務(wù)器執(zhí)行此版本的 instmd

6、w.sql。14680試圖在運行 SQL Server 2000 或早期版本的服務(wù)器上安裝管理數(shù)據(jù)倉庫。禁用收集器時不能執(zhí)行此過程。請啟用收集器，然后重試。14681試圖執(zhí)行與收集器的狀態(tài)相沖突的操作。收集組的狀態(tài)已更改，但是只有在啟用收集器后，它才能啟動或停止。14682試圖在未啟用收集器時啟動或停止收集組?？煺罩谢蜻B續(xù)模式下的收集組需要一個計劃。14683在快照中或連續(xù)模式下創(chuàng)建或更新收集組而未提供計劃。捕捉到錯誤，編號: %d，級別: %d，狀態(tài): %d，過程: %s，行: %d，消息: %s14684數(shù)據(jù)收集器組件中發(fā)生一般性錯誤；在 catch 塊中捕獲到該錯誤并再次引發(fā)該錯誤。操作

7、無效。ID 為 %d 的收集組的狀態(tài)當(dāng)前為“未運行”。14685針對 is_running 狀態(tài)為 0 的收集組調(diào)用 sp_syscollector_create_set_queue_and_service。配置存儲區(qū)的 MDWInstance 和 MDWDatabase 參數(shù)不能為 Null。14686MDWInstance 或 MDWDatabase 參數(shù)的管理數(shù)據(jù)倉庫連接字符串為 Null。cache_window 參數(shù)的值 (%d) 無效。允許的值為: -1 (緩存以前上載失敗的所有上載數(shù)據(jù))、0 (不緩存上載數(shù)據(jù))、N (緩存以前 N 次上載失敗的數(shù)據(jù)，其中 N >= 1)14

8、687試圖將收集器配置存儲區(qū)的 CacheWindow 參數(shù)的值設(shè)置為小于 -1 的值。SQL Server 代理停止時收集組無法啟動。請啟動 SQL Server 代理。14688試圖在未啟用 SQL Server 代理時啟動收集組。如果未配置管理數(shù)據(jù)倉庫，則收集組無法啟動。請運行 instmdw.sql 腳本以創(chuàng)建并配置管理數(shù)據(jù)倉庫。14689試圖在未設(shè)置管理數(shù)據(jù)倉庫時啟動收集組。啟用收集器時無法執(zhí)行此過程。請禁用收集器，然后重試。14690試圖執(zhí)行與收集器的狀態(tài)相沖突的操作。收集器的狀態(tài)不能為 Null。這可能表示收集器配置數(shù)據(jù)發(fā)生內(nèi)部損壞。14691對 sp_syscollector_

9、verify_collector_state 的調(diào)用發(fā)現(xiàn) CollectorEnabled 參數(shù)的值為 Null。這可能表示收集器的配置數(shù)據(jù)發(fā)生內(nèi)部損壞。 運行時錯誤當(dāng)收集包或上載包在運行中遇到問題時便會發(fā)生運行時錯誤。這些錯誤可能來自下列組件之一：· SQL Server 2008 Integration Services (SSIS) 包的數(shù)據(jù)流。這些錯誤可能是由于數(shù)據(jù)轉(zhuǎn)換失敗或出現(xiàn)數(shù)據(jù)截斷導(dǎo)致的。數(shù)據(jù)收集器會記錄受錯誤影響的行號，并將其記錄在數(shù)據(jù)收集器日志表中。· SSIS 包的控制流。這些錯誤記錄在 msdb 數(shù)據(jù)庫的 SSIS 日志表 (msdb.d

10、bo.sysssislog) 中，并冒泡到數(shù)據(jù)收集器日志表中。· 數(shù)據(jù)收集器運行時組件 (dcexec.exe)。這些錯誤直接記錄在數(shù)據(jù)收集器日志表中。有關(guān)詳細信息，請參閱數(shù)據(jù)收集器日志記錄。我們建議采用以下方法之一獲取有關(guān)運行時錯誤的狀態(tài)信息。.1 Transact-SQL 存儲過程和視圖若要查看所有當(dāng)前正在運行和已完成的收集組或包的狀態(tài)，請運行以下查詢：復(fù)制代碼use msdbselect * from syscollector_execution_log_full上述查詢將返回以下結(jié)果集。列名 說明 log_id每個收集組執(zhí)行的唯一 ID。它用于將此視圖與其他詳細

11、日志聯(lián)接起來。parent_log_id父包或收集組的 ID。對于收集組而言，此值為 NULL。各個 ID 以父子關(guān)系鏈接在一起，以便可以輕松確定哪個收集組啟動了哪個包。此外，此視圖將日志條目按其父子鏈接進行分組并縮進包的名稱，從而使調(diào)用鏈清晰可見。name該日志條目所表示的收集組或包的名稱。collection_mode記錄該條目時的收集組活動，即收集或上載。start_time收集組或包啟動的時間。last_iteration_time對于連續(xù)運行的包而言，是包上次捕獲快照的時間。finish_time對于已完成的包和收集組而言，是運行完成的時間。duration包或收集組已經(jīng)運行的時間（

12、以毫秒為單位）。operator啟動該收集組或包的操作員。status收集組或包的狀態(tài)。此值可以為：· 0 - 正在運行· 1 - 已完成· 2 - 失敗failure_task當(dāng)收集組或包失敗時，導(dǎo)致失敗的 SSIS 包中的任務(wù)的名稱。package_execution_id指向 SSIS 日志表的鏈接。collection_set_id指向數(shù)據(jù)收集器配置表的鏈接。注意：您可以使用 collection_set_id 作為篩選器以專注于日志中的特定收集組。 有關(guān)詳細信息，請參閱 syscollector_execution_log_full (Transact-

13、SQL)。您可以通過執(zhí)行數(shù)據(jù)收集器提供的函數(shù)之一獲取有關(guān)收集組和包執(zhí)行的其他信息。以下函數(shù)將返回有關(guān)收集組或包的詳細統(tǒng)計信息，包括由包記錄的錯誤行的數(shù)目。復(fù)制代碼select * from fn_syscollector_get_execution_stats(log_id)下一個函數(shù)將返回與某個包的 package_execution_id 相匹配的 SSIS 日志 (sysdtslog90) 部分。如果該包失敗，則這是找出錯誤根源的最好方式。復(fù)制代碼select * from fn_syscollector_get_execution_details(log_id).2 數(shù)據(jù)

14、收集器狀態(tài)報表您可以通過查看 SQL Server Management Studio 中提供的日志獲取與前面的 Transact-SQL 查詢返回的信息相同的信息。有關(guān)詳細信息，請參閱如何查看收集組日志。1.1.2 性能問題有三個主要的數(shù)據(jù)源可用于檢查和診斷性能。首先，上一部分介紹的日志表還提供了可用于解決性能問題的有用信息。fn_syscollector_get_execution_stats 函數(shù)可返回以下信息。列名 說明 avg_row_count_in進入包的數(shù)據(jù)流任務(wù)的平均行數(shù)。min_row_count_in進入包的數(shù)據(jù)流任務(wù)的最小行數(shù)。max_row_count_in進入包的數(shù)

15、據(jù)流任務(wù)的最大行數(shù)。avg_row_count_out退出包的數(shù)據(jù)流任務(wù)的平均行數(shù)。min_row_count_out退出包的數(shù)據(jù)流任務(wù)的最小行數(shù)。max_row_count_out退出包的數(shù)據(jù)流任務(wù)的最大行數(shù)。avg_duration在包的數(shù)據(jù)流組件中消耗的平均時間（以毫秒為單位）。min_duration在包的數(shù)據(jù)流組件中消耗的最短時間（以毫秒為單位）。max_duration在包的數(shù)據(jù)流組件中消耗的最長時間（以毫秒為單位）。第二個性能數(shù)據(jù)源是 syscollector_execution_log_full 表，該表提供有關(guān)已經(jīng)完成運行或正在運行的收集組所用時間的信息。最后，可以使用性能計

16、數(shù)器來幫助評估性能問題。尤其是，數(shù)據(jù)收集器進程 (dcexec.exe) 實例的標(biāo)準(zhǔn)進程計數(shù)器為數(shù)據(jù)收集器運行時組件使用了多少系統(tǒng)資源提供了非常好的指示器。 性能問題具體情況運行數(shù)據(jù)收集器時最有可能出現(xiàn)兩種性能問題情況：· 數(shù)據(jù)收集器消耗的系統(tǒng)資源過多。· 數(shù)據(jù)收集器無法承受收集負荷。.1 系統(tǒng)資源過度消耗如果進程性能計數(shù)器的分析表明 dcexec.exe 進程使用的系統(tǒng)資源過多，則需要進行以下調(diào)查。首先，確定是否大部分資源都由一個收集組占用。· 若要標(biāo)識該收集組，請將進程 ID 映射到 syscollector_execution_l

17、og_full 中的收集組 ID，然后在 syscollector_collection_sets 表中查找該收集組。· 確定該收集組所收集的內(nèi)容。使用以下查詢列出該收集組中的所有收集項：復(fù)制代碼select * from syscollector_collection_set_items where collection_set_id = <id>· 使用來自上述查詢的信息，考慮以下問題：o 收集項是否過多？o 大部分問題是否都由一個收集項所導(dǎo)致？o 收集的數(shù)據(jù)是否過多？o 如果對上述任何問題的回答為“是”，請考慮修改收集或收集項以減少所收集的數(shù)據(jù)量。這將減少

18、資源消耗。其次，確定問題是否由活動收集組的數(shù)量過多所導(dǎo)致。· 使用以下查詢查看系統(tǒng)中定義的收集組數(shù)：復(fù)制代碼select count(*) from syscollector_collection_sets· 使用以下查詢查看當(dāng)前正在運行的收集組數(shù)：復(fù)制代碼select count(*) from syscollector_execution_log_full where parent_log_id is null and status = 1· 如果性能問題是間歇性的，請檢查問題是否映射到任何收集或上載活動。如果所有計劃都完全相同，則這可能是導(dǎo)致問題的原因。通過

19、調(diào)整收集或上載計劃或許就可以解決問題。.2 無法承受負荷這種情況只發(fā)生在連續(xù)運行的收集組中。如果收集頻率較高并且要收集的數(shù)據(jù)量較大，則收集包可能無法在為單個快照迭代分配的時間內(nèi)處理數(shù)據(jù)。可以通過將日志表中的 avg_duration 和 max_duration 列與為特定收集項定義的收集頻率進行比較來檢測這種情況。如果 max_duration 值大于頻率值，則收集包可能無法始終滿足配置的頻率要求。如果 avg_duration 值大于頻率值，則收集包會一直出現(xiàn)相同的問題。對于后一種情況，應(yīng)減小頻率或修改收集項以限制所收集的數(shù)據(jù)量。1.1.3 系統(tǒng)掛起如果作為數(shù)據(jù)收集器的一部分

20、運行的某個包停止處理但并未退出而是停留在該狀態(tài)，則會出現(xiàn)系統(tǒng)掛起。多數(shù)系統(tǒng)掛起問題都可以通過停止并重新啟動收集組得到解決。區(qū)分真正掛起和預(yù)期行為非常重要。· 連續(xù)運行的收集包多數(shù)時間處于等待狀態(tài)，它會定期醒來收集數(shù)據(jù)快照。收集數(shù)據(jù)后，該包會回到等待狀態(tài)。這種等待狀態(tài)可能看似系統(tǒng)掛起，實際并不是。若要對此進行驗證，請檢查可疑包的 syscollector_execution_log_full 表。如果 last_iteration_time 不晚于當(dāng)前時間，則該情況不屬于掛起。· 包可能會設(shè)計為等待某個將觸發(fā)收集操作的事件。這種情況下，包將會等待該事件。這種情況并不是掛起。若

21、要驗證是否有與數(shù)據(jù)收集器相關(guān)的系統(tǒng)掛起，請執(zhí)行以下檢查：· 首先，標(biāo)識與要調(diào)查的收集組相對應(yīng)的 dcexec.exe 進程 ID。· 接下來，檢查該進程是否正在運行以及是否使用了任何資源。任何掛起進程的 CPU 占用率通常都為 0% 并且不會分配較多內(nèi)存。該進程也可能會占用高百分比的 CPU。如果是這種情況，則它可能正在進行循環(huán)并且未退出內(nèi)存。· 最后，檢查進程的日志表以查看它上次更新的時間。如果更新時間長于收集項的頻率，則該進程可能已掛起。有多種原因可導(dǎo)致數(shù)據(jù)收集器進程掛起。下面列出了最常見的原因：· 包等待發(fā)出下一個迭代信號，但沒有信號發(fā)出。

22、3; 包等待由另一個包所占有的共享鎖，但該鎖未釋放。· 包執(zhí)行過程中出現(xiàn)錯誤且未得到適當(dāng)處理，控制流中斷，但包未完全失敗。在上述任何情況下，日志中都會有與系統(tǒng)掛起相關(guān)的特定條目。請查看是否有任何指示原因的消息。出現(xiàn)系統(tǒng)掛起時，請創(chuàng)建 dcexec.exe 進程的轉(zhuǎn)儲并做進一步調(diào)查。1.2 對數(shù)據(jù)庫引擎連接進行故障排除 包含有關(guān)解決數(shù)據(jù)庫引擎連接問題的信息。1.2.1 故障排除：超時時間已到 當(dāng) SQL Server 數(shù)據(jù)庫引擎實例未運行、服務(wù)器名稱鍵入錯誤或者存在網(wǎng)絡(luò)問題或防火墻時，通常會發(fā)生“超時時間已到”錯誤。 錯誤文本在 SQL Server Management

23、 Studio 中，此錯誤顯示為：“無法連接到 <服務(wù)器名>?！薄俺瑫r時間已到。在操作完成之前超時時間已過或服務(wù)器未響應(yīng)。（Microsoft SQL Server，錯誤: -2）”在 sqlcmd 中，可能出現(xiàn)的超時錯誤包括：“SQL 網(wǎng)絡(luò)接口: 定位指定的服務(wù)器/實例時出錯”“Sqlcmd: 錯誤: Microsoft SQL Server Native Client : 客戶端無法建立連接?！薄癝qlcmd: 錯誤: Microsoft SQL Server Native Client : 登錄超時時間已到?！薄盁o法與 SQL Server 建立連接”“建立與服務(wù)器的連接時出

24、錯。當(dāng)連接到 SQL Server 時，此故障可能會因為 SQL Server 在默認設(shè)置下不允許進行遠程連接而引發(fā)的?！?此錯誤的常見原因原因 解決方法 鍵入的服務(wù)器名稱不正確。使用正確的服務(wù)器名稱，然后重試。服務(wù)器中的 SQL Server 服務(wù)未運行。啟動 SQL Server 數(shù)據(jù)庫引擎實例。數(shù)據(jù)庫引擎實例的 TCP/IP 端口被防火墻阻塞。將防火墻配置為允許訪問數(shù)據(jù)庫引擎。數(shù)據(jù)庫引擎由于已被更改或者不是默認實例而不偵聽端口 1433，并且沒有運行 SQL Server Browser 服務(wù)。要么啟動 SQL Server Browser 服務(wù)，要么指定 TCP/IP 端

25、口號進行連接。SQL Server Browser 服務(wù)正在運行，但 UDP 端口 1434 被防火墻阻塞。將防火墻配置為允許訪問服務(wù)器上的 UDP 端口 1434，或者連接指定 TCP/IP 端口號?？蛻舳撕头?wù)器未配置為使用相同的網(wǎng)絡(luò)協(xié)議。使用 SQL Server 配置管理器，確認服務(wù)器和客戶端計算機至少有一個通用的啟用協(xié)議。網(wǎng)絡(luò)無法將服務(wù)器名稱解析為 IP 地址?？墒褂?PING 程序?qū)Υ诉M行測試。修復(fù)網(wǎng)絡(luò)上的計算機名稱解析問題，或者使用服務(wù)器的 IP 地址連接。這不是 SQL Server 問題。有關(guān)幫助，請參閱 Windows 文檔或與網(wǎng)絡(luò)管理員聯(lián)系。無法使用 IP 地址連接到網(wǎng)絡(luò)

26、?？墒褂?PING 程序?qū)Υ诉M行測試。修復(fù)網(wǎng)絡(luò)上的 TCP/IP 問題。這不是 SQL Server 問題。有關(guān)幫助，請參閱 Windows 文檔或與網(wǎng)絡(luò)管理員聯(lián)系。 不常見錯誤.1 多個服務(wù)器 IP 地址在連接到群集或具有多個 IP 地址的非群集計算機上安裝的 SQL Server 命名實例時，Windows Vista 或 Windows Server 2008 上的客戶端可能會收到此錯誤。所有 SQL Server 版本都可能會出現(xiàn)這種問題。原因 在連接到遠程計算機上的命名實例時，客戶端使用用戶數(shù)據(jù)報協(xié)議 (UDP) 連接到 SQL Server 計算機或群集

27、上的 SQL Server Browser 服務(wù)以獲取連接端點（TCP 端口號或命名管道）。Windows Vista 或 Windows Server 2008 客戶端上的防火墻不允許對 UDP 進行松散源映射。即，響應(yīng)必須是從所查詢的相同 IP 地址中返回的。如果響應(yīng)不是從最初針對的 IP 地址中返回的，客戶端防火墻將刪除數(shù)據(jù)包。在嘗試連接到群集服務(wù)器或具有多個 IP 地址的非群集服務(wù)器計算機時，可能會出現(xiàn)這種問題。下表介紹可導(dǎo)致 UDP 數(shù)據(jù)包被刪除的操作系統(tǒng)組合。這可以阻止連接到 SQL Server 的命名實例或未在 TCP 端口 1433 上偵聽的 SQL Server 默認實例。

28、客戶端操作系統(tǒng) 運行 SQL Server 的操作系統(tǒng) SQL Server 2008 結(jié)果 SQL Server 2005 結(jié)果 Windows XP 或 Windows Server 2003Windows XP 或 Windows Server 2003UDP 數(shù)據(jù)包未被刪除。UDP 數(shù)據(jù)包未被刪除。Windows XP 或 Windows Server 2003Windows Vista 或 Windows Server 2003UDP 數(shù)據(jù)包未被刪除。UDP 數(shù)據(jù)包未被刪除。Windows Vista 或 Windows Server 2008Windows XP 或 Windows

29、 Server 2003UDP 數(shù)據(jù)包被刪除。無法連接。UDP 數(shù)據(jù)包被刪除。無法連接。Windows Vista 或 Windows Server 2008Windows Vista 或 Windows Server 2008（x86、IA64）UDP 數(shù)據(jù)包未被刪除。UDP 數(shù)據(jù)包被刪除。無法連接。Windows Vista 或 Windows Server 2008Windows Vista 或 Windows Server 2008 (x64)UDP 數(shù)據(jù)包被刪除。無法連接。UDP 數(shù)據(jù)包被刪除。無法連接。解決方法 若要解決此問題，請執(zhí)行以下操作之一：· 在連接字符串中，將

30、TCP 端口號或命名管道名稱指定為服務(wù)器名稱的一部分。· 在客戶端計算機上具有高級安全功能的 Windows 防火墻中創(chuàng)建例外。注意：如果在防火墻中創(chuàng)建例外，可能會使計算機或網(wǎng)絡(luò)更容易受到惡意用戶或惡意軟件（如病毒）的攻擊。建議您不要使用這種解決方法，此處提供該信息的目的是，如果沒有切實可行的替代方法，您可以自行決定是否采用這種解決方法。 · 例外可以是以下任一情況：o 為連接到 SQL Server 的應(yīng)用程序添加例外規(guī)則。o 添加一個入站規(guī)則，以允許來自 SQL Server 計算機或群集的所有可能的 IP 地址的通信。1.2.2 故障排除：強行關(guān)閉的連接 使用 TCP

31、/IP 連接到 SQL Server 時，可能會出現(xiàn)此錯誤。 錯誤文本該錯誤出現(xiàn)時可能具有以下格式：· TCP_PROV: 現(xiàn)有連接被遠程主機強行關(guān)閉。· 訪問接口編號: 7，錯誤: 10054，錯誤消息:“TCP 訪問接口: 現(xiàn)有連接已被遠程主機強行關(guān)閉”· 未處理的異常: 在向服務(wù)器發(fā)送請求時發(fā)生傳輸級錯誤。(訪問接口: TCP 訪問接口，錯誤: 0 - 現(xiàn)有連接已被遠程主機強行關(guān)閉。) 此錯誤的常見原因下表列出了此錯誤的常見原因和解決方法。原因 解決方法 客戶端已與不支持的 SQL Server Native Client 版本連

32、接。將客戶端計算機更新為 SQL Server Native Client 的服務(wù)器版本。發(fā)生故障的網(wǎng)絡(luò)硬件正在刪除部分 TCP 通信。使用網(wǎng)絡(luò)監(jiān)視程序分析 TCP SYN、ACK 和 FIN 消息。SynAttackProtect 設(shè)置可能正在刪除連接。請參閱后面的“在 Windows Server 2003 SP1 上運行時，連接可能被強行關(guān)閉”部分。.1 在 Windows Server 2003 SP1 上運行時，連接可能被強行關(guān)閉當(dāng)使用大量到 Windows Server 2003 Service Pack 1 上運行的 SQL Server 數(shù)據(jù)庫引擎實例的客戶端連接

33、嘗試測試可伸縮性時，如果請求到達的速度快于 SQL Server 提供的連接速度，則 Windows 可能會刪除這些連接。這是 Windows Server 2003 Service Pack 1 的一項安全功能，可實現(xiàn)有限的傳入 TCP 連接請求隊列。若要解決此問題，請使用 regedit.exe 實用工具添加以下注冊表項：項 類型 名稱 值 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersDWORDSynAttackProtect00000000安全說明：設(shè)置此注冊表項可能會使服務(wù)器面臨 SYN 泛濫和拒絕服務(wù)

34、攻擊的威脅。只有在必要并且了解這些安全風(fēng)險的情況下，才可以添加此注冊表值。完成測試后，請刪除此注冊表值。 1.2.3 故障排除：在管道的另一端沒有進程 連接到 SQL Server 的客戶端如果在 SQL Server 上未啟用命名管道支持時連接到該服務(wù)器（即使可以使用其他協(xié)議，如 TCP/IP），可能會遇到此命名管道錯誤。如果服務(wù)器上未啟用命名管道，則拒絕客戶端試圖使用命名管道進行連接。以下兩種情況下會出現(xiàn)此錯誤：· 客戶端試圖只使用命名管道進行連接，而服務(wù)器上未啟用命名管道協(xié)議。· 客戶端試圖使用任何可用的協(xié)議進行連接，但在客戶端協(xié)議順序中，named pipes 列在

35、 TCP 之前。 錯誤文本named pipes 提供程序：在管道的另一端沒有進程。Microsoft SQL Server Native Client：通信鏈接失敗。Microsoft SQL Server Native Client：在與服務(wù)器建立連接時出現(xiàn)錯誤。當(dāng)連接到 SQL Server 時，此故障可能是因為 SQL Server 在默認設(shè)置下不允許進行遠程連接而引發(fā)的。 此錯誤的常見原因原因 解決方法 客戶端試圖使用 named pipes 進行連接，而服務(wù)器沒有配置為允許使用 named pipes 進行遠程連接。使用 TCP/IP 進行連接，或使用

36、SQL Server 配置管理器通過 named pipes 進行遠程連接。客戶端協(xié)議順序是在嘗試 TCP 協(xié)議之前試圖使用 named pipes 協(xié)議進行連接，而服務(wù)器上未啟用 named pipes。在客戶端計算機上使用 SQL Server 配置管理器，在協(xié)議順序列表中將 TCP 移動到 Named Pipes 之前。1.2.4 故障排除：用戶 'x' 登錄失敗 因密碼或用戶名錯誤而使身份驗證失敗并導(dǎo)致連接嘗試被拒時，類似下面的消息將返回到客戶端：“用戶 '<user_name>' 登錄失敗”。（Microsoft SQL Server，錯誤

37、: 18456）”。返回到客戶端的其他信息有：“用戶 '<user_name>' 登錄失敗。（.Net SqlClient 數(shù)據(jù)訪問接口）”-“服務(wù)器名稱: <computer_name>”“錯誤號: 18456”“嚴重性: 14”“狀態(tài): 1”“行號: 65536”也可能返回以下消息：“消息 18456，級別 14，狀態(tài) 1，服務(wù)器 <computer_name>，第 1 行”“用戶 '<user_name>' 登錄失敗?！?其他錯誤信息為了增強安全性，返回到客戶端的錯誤消息有意隱藏身份驗證錯誤的本

38、質(zhì)。但是，在 SQL Server 錯誤日志中，對應(yīng)的錯誤包含映射到身份驗證失敗條件的錯誤狀態(tài)。將錯誤狀態(tài)與以下列表進行比較以確定登錄失敗的原因。狀態(tài) 說明 2用戶 ID 無效。5用戶 ID 無效。6嘗試同時使用 SQL Server 身份驗證與 Windows 登錄名。7登錄已禁用，密碼不正確。8密碼不正確。9密碼無效。11登錄有效，但服務(wù)器訪問失敗。12登錄是有效的登錄，但服務(wù)器訪問失敗。18必須更改密碼。存在其他錯誤狀態(tài)，并表示一個意外的內(nèi)部處理錯誤。 示例在此示例中，身份驗證錯誤狀態(tài)為 8。這指示密碼不正確。日期 來源 消息 2007-12-05 20:12:56.34登

39、錄錯誤: 18456，嚴重性: 14，狀態(tài): 8。2007-12-05 20:12:56.34登錄用戶 '<user_name>' 登錄失敗。CLIENT: <IP 地址>注意：如果 SQL Server 使用 Windows 身份驗證模式進行安裝，并隨后更改為 SQL Server 和 Windows 身份驗證模式，則最初禁用 sa 登錄名。這會導(dǎo)致狀態(tài) 7 錯誤：“用戶 'sa' 登錄失敗”。要啟用 sa 登錄名，請參閱如何更改服務(wù)器身份驗證模式。1.2.5 故障排除：在系統(tǒng)管理員被鎖定時如何連接到 SQL Server本主題介紹作為

40、系統(tǒng)管理員如何可以重新獲得對 SQL Server 數(shù)據(jù)庫引擎的訪問權(quán)限。系統(tǒng)管理員可能會由于下列原因之一失去對 SQL Server 實例的訪問權(quán)限：· 作為 sysadmin 固定服務(wù)器角色成員的所有登錄名都已經(jīng)被誤刪除。· 作為 sysadmin 固定服務(wù)器角色成員的所有 Windows 組都已經(jīng)被誤刪除。· 作為 sysadmin 固定服務(wù)器角色成員的登錄名用于已經(jīng)離開公司或者無法找到的個人。· sa 帳戶被禁用或者沒有人知道密碼?？梢宰屇匦芦@得訪問權(quán)限的一種方法是重新安裝 SQL Server 并將所有數(shù)據(jù)庫附加到新實例。這種解決方案很耗時，

41、并且若要恢復(fù)登錄名，可能還需要從備份中還原 master 數(shù)據(jù)庫。如果 master 數(shù)據(jù)庫的備份較舊，則它可能未包含所有信息。如果 master 數(shù)據(jù)庫的備份較新，則它可能與前一個實例具有同樣的登錄名；因此管理員仍將被鎖定。 解決方法使用 -m 或 -f 選項在單用戶模式下啟動 SQL Server 的實例。計算機的本地 Administrators 組的任何成員都可以隨后作為 sysadmin 固定服務(wù)器角色的成員連接到 SQL Server 實例。注意：在單用戶模式下啟動 SQL Server 實例時，請首先停止 SQL Server Agent 服務(wù)。否則，SQL Ser

42、ver 代理可能會首先連接，并阻止您作為第二個用戶連接。 當(dāng)您將 -m 選項與 sqlcmd 或 SQL Server Management Studio 一起使用時，可以將連接限制為指定的客戶端應(yīng)用程序。例如，-m"sqlcmd" 將連接限制為單個連接并且該連接必須將自身標(biāo)識為 sqlcmd 客戶端程序。當(dāng)您正在單用戶模式下啟動 SQL Server 并且未知的客戶端應(yīng)用程序正在占用這個唯一的可用連接時，使用此選項。若要通過 Management Studio 中的查詢編輯器進行連接，請使用 -m"Microsoft SQL Server Management

43、Studio - Query"。重要提示：不要將此選項作為安全功能使用。客戶端應(yīng)用程序提供客戶端應(yīng)用程序名稱，并且提供假名稱來作為連接字符串的一部分。 有關(guān)如何在單用戶模式下啟動 SQL Server 的分步說明，請參閱如何配置服務(wù)器啟動選項（SQL Server 配置管理器）。1.3 對數(shù)據(jù)庫郵件進行故障排除 提供有關(guān)數(shù)據(jù)庫郵件常見問題的疑難解答信息。1.3.1 數(shù)據(jù)庫郵件故障排除：常規(guī)步驟 數(shù)據(jù)庫郵件故障排除涉及到對數(shù)據(jù)庫郵件系統(tǒng)進行下列方面的常規(guī)檢查。這些過程按邏輯順序介紹，但可以按任何順序進行評估。 確定是否啟用了數(shù)據(jù)庫郵件1. 在 SQL Server Man

44、agement Studio 中，使用查詢編輯器窗口連接到 SQL Server 的實例，然后執(zhí)行下面的代碼：復(fù)制代碼sp_configure 'show advanced', 1; GORECONFIGURE;GOsp_configure;GO2. 在“結(jié)果”窗格中，確認 Database Mail XPs 的 run_value 設(shè)置為 1。3. 如果 run_value 不為 1，將不會啟用數(shù)據(jù)庫郵件。數(shù)據(jù)庫郵件不會自動啟用，以減少惡意用戶可用來發(fā)起攻擊的功能數(shù)。有關(guān)詳細信息，請參閱了解外圍應(yīng)用配置器。4. 如果您確定可以啟用數(shù)據(jù)庫郵件，請執(zhí)行下面的代碼：復(fù)制代碼sp_c

45、onfigure 'Database Mail XPs', 1; GORECONFIGURE;GO5. 要將 sp_configure 過程還原為不顯示高級選項的默認狀態(tài)，請執(zhí)行下面的代碼：復(fù)制代碼sp_configure 'show advanced', 0; GORECONFIGURE;GO 確定是否對用戶進行了正確的配置以發(fā)送數(shù)據(jù)庫郵件1. 若要發(fā)送數(shù)據(jù)庫郵件，用戶必須是 DatabaseMailUserRole 的成員。sysadmin 固定服務(wù)器角色和 msdb db_owner 角色的成員將自動成為 DatabaseMailUserRo

46、le 角色的成員。若要列出 DatabaseMailUserRole 的所有其他成員，請執(zhí)行以下語句：復(fù)制代碼EXEC msdb.sys.sp_helprolemember 'DatabaseMailUserRole'2. 若要將用戶添加到 DatabaseMailUserRole 角色中，請使用以下語句：復(fù)制代碼sp_addrolemember rolename = 'DatabaseMailUserRole' ,membername = '<database user>'3. 若要發(fā)送數(shù)據(jù)庫郵件，用戶必須有權(quán)訪問至少一個數(shù)據(jù)庫郵件

47、配置文件。若要列出用戶（主體）及其有權(quán)訪問的配置文件，請執(zhí)行以下語句：復(fù)制代碼EXEC msdb.dbo.sysmail_help_principalprofile_sp;4. 使用數(shù)據(jù)庫郵件配置向?qū)?chuàng)建配置文件并授予用戶訪問這些配置文件的權(quán)限。 確定是否已啟動數(shù)據(jù)庫郵件1. 當(dāng)有電子郵件要處理時，將激活數(shù)據(jù)庫郵件外部程序。當(dāng)指定的超時期限內(nèi)沒有要發(fā)送的電子郵件時，將退出該程序。若要確定是否已啟動數(shù)據(jù)庫郵件激活，請執(zhí)行以下語句：復(fù)制代碼EXEC msdb.dbo.sysmail_help_status_sp;2. 如果未啟動數(shù)據(jù)庫郵件激活，請執(zhí)行以下語句將其啟動：復(fù)制代碼EXEC

48、 msdb.dbo.sysmail_start_sp;3. 如果已啟動數(shù)據(jù)庫郵件外部程序，請使用以下語句檢查郵件隊列的狀態(tài)：復(fù)制代碼EXEC msdb.dbo.sysmail_help_queue_sp queue_type = 'mail'4. 郵件隊列的狀態(tài)應(yīng)為 RECEIVES_OCCURRING。郵件隊列的狀態(tài)可能會不時發(fā)生改變。如果郵件隊列的狀態(tài)不是 RECEIVES_OCCURRING，請使用 sysmail_stop_sp 嘗試停止隊列，然后再使用 sysmail_start_sp 啟動隊列。注意：使用 sysmail_help_queue_sp 結(jié)果集中的 le

49、ngth 列確定郵件隊列中的電子郵件數(shù)量。 確定數(shù)據(jù)庫郵件中的問題是影響配置文件中的所有帳戶，還是只影響某些帳戶1. 如果確定只有某些配置文件可以發(fā)送郵件，而不是所有配置文件都可以，則可能是有問題的配置文件所使用的數(shù)據(jù)庫郵件帳戶存在問題。若要確定哪些帳戶可以成功發(fā)送郵件，請執(zhí)行以下語句：復(fù)制代碼SELECT sent_account_id, sent_date FROM msdb.dbo.sysmail_sentitems;2. 如果有問題的配置文件未使用列出的任何帳戶，那么可能是該配置文件可以使用的所有帳戶都不能正常工作。若要測試各個帳戶，請使用數(shù)據(jù)庫郵件配置向?qū)?chuàng)建一個只包

50、含一個用戶的新配置文件，然后通過“發(fā)送測試電子郵件”對話框使用新帳戶發(fā)送郵件。3. 若要查看數(shù)據(jù)庫郵件返回的錯誤消息，請執(zhí)行以下語句：復(fù)制代碼SELECT * FROM msdb.dbo.sysmail_event_log;注意：當(dāng)郵件被成功傳遞到 SMTP 郵件服務(wù)器上時，數(shù)據(jù)庫郵件即認為郵件已被發(fā)送。雖然后續(xù)錯誤（例如，收件人的電子郵件地址無效）仍然可能會使郵件無法傳遞，但是不會包含在數(shù)據(jù)庫郵件日志中。 配置數(shù)據(jù)庫郵件以重試郵件傳遞1. 如果確定數(shù)據(jù)庫郵件失敗是由于無法可靠地到達 SMTP 服務(wù)器而導(dǎo)致的，則可以通過增大數(shù)據(jù)庫郵件嘗試發(fā)送每封郵件的次數(shù)來增加郵件傳送的成功率

51、。啟動數(shù)據(jù)庫郵件配置向?qū)?，然后選擇“查看或更改系統(tǒng)參數(shù)”選項。還可以將更多帳戶與配置文件相關(guān)聯(lián)，這樣，當(dāng)從主帳戶進行故障轉(zhuǎn)移時，數(shù)據(jù)庫郵件將使用故障轉(zhuǎn)移帳戶發(fā)送電子郵件。2. 在“配置系統(tǒng)參數(shù)”頁上，“帳戶重試次數(shù)”的默認值為 5 次，“帳戶重試延遲時間”的默認值為 60 秒，這意味著如果在 5 分鐘之內(nèi)不能到達 SMTP 服務(wù)器，郵件傳遞將失敗。增大這些參數(shù)可以延長郵件傳遞失敗之前的時間。注意：當(dāng)發(fā)送大量郵件時，雖然較大的默認值可以提高可靠性，但會顯著增加資源的使用量，因為會一遍又一遍地嘗試傳遞大量郵件。若要從根本上解決問題，需要解決阻礙數(shù)據(jù)庫郵件與 SMTP 服務(wù)器快速建立聯(lián)系的網(wǎng)絡(luò)問題或

52、 SMTP 服務(wù)器問題。 安全性只有 sysadmin 固定服務(wù)器角色的成員才能對數(shù)據(jù)庫郵件的所有方面進行故障排除。如果用戶不是 sysadmin 固定服務(wù)器角色的成員，則只能獲得他們嘗試發(fā)送的電子郵件的有關(guān)信息，而不能獲得其他用戶發(fā)送的電子郵件的有關(guān)信息。1.3.2 數(shù)據(jù)庫郵件故障排除：發(fā)送測試電子郵件 使用“發(fā)送測試電子郵件”對話框來測試使用特定配置文件發(fā)送郵件的能力。 過程.1 發(fā)送測試電子郵件1. 使用對象資源管理器，連接到配置了數(shù)據(jù)庫郵件的 SQL Server 數(shù)據(jù)庫引擎實例，展開“管理”，右鍵單擊“數(shù)據(jù)庫郵件”，然后單擊“發(fā)送測試電子郵

53、件”。如果不存在數(shù)據(jù)庫郵件配置文件，將通過一個對話框提示用戶創(chuàng)建配置文件，同時還會打開數(shù)據(jù)庫郵件配置向?qū)А?. 在“從 <實例名> 發(fā)送測試電子郵件”對話框中，從“數(shù)據(jù)庫郵件配置文件”框中選擇要測試的配置文件。3. 在“收件人”框中，鍵入測試電子郵件收件人的電子郵件名稱。4. 在“主題”框中，鍵入測試電子郵件的主題行。更改默認主題，以便更好地標(biāo)識電子郵件以進行故障排除。5. 在“正文”框中，鍵入測試電子郵件的正文。更改默認主題，以便更好地標(biāo)識電子郵件以進行故障排除。6. 單擊“發(fā)送測試電子郵件”，將測試電子郵件發(fā)送到數(shù)據(jù)庫郵件隊列。7. 發(fā)送測試電子郵件將打開“數(shù)據(jù)庫郵件測試電子郵

54、件”對話框。請記下“發(fā)送電子郵件”框中顯示的數(shù)字。這是測試電子郵件的 mailitem_id。單擊“確定”。8. 在工具欄上，單擊“新建查詢”以打開“查詢編輯器”窗口。執(zhí)行以下語句以確定測試電子郵件的狀態(tài)：復(fù)制代碼SELECT * FROM msdb.dbo.sysmail_allitems WHERE mailitem_id = <the mailitem_id from the previous step> ;9. sent_status 列將指示是否已發(fā)送測試電子郵件。10. 如果發(fā)生錯誤，則執(zhí)行以下語句以查看錯誤消息： 權(quán)限只有 sysadmin 固定服務(wù)器角

55、色的成員才能使用“發(fā)送測試電子郵件”對話框。如果用戶不是 sysadmin 固定服務(wù)器角色的成員，可以使用 sp_send_dbmail 過程來測試數(shù)據(jù)庫郵件。1.3.3 數(shù)據(jù)庫郵件故障排除：找不到存儲過程“sp_send_dbmail” sp_send_dbmail 存儲過程安裝在 msdb 數(shù)據(jù)庫中。您必須從 msdb 數(shù)據(jù)庫執(zhí)行 sp_send_dbmail，或為存儲過程指定一個由三部分構(gòu)成的名稱。使用數(shù)據(jù)庫郵件配置向?qū)⒂貌⑴渲脭?shù)據(jù)庫郵件。1.3.4 數(shù)據(jù)庫郵件故障排除：配置文件無效 本主題說明如何排除報告配置文件無效的錯誤消息的故障。導(dǎo)致出現(xiàn)此消息的可能原因有兩個。指定的配置文件不存

56、在，或者運行 sp_send_dbmail (Transact-SQL) 的用戶沒有訪問配置文件的權(quán)限。若要檢查配置文件的權(quán)限，請使用配置文件名作為參數(shù)來運行存儲過程 sysmail_help_principalprofile_sp (Transact-SQL)。使用存儲過程 sysmail_add_principalprofile_sp (Transact-SQL) 或數(shù)據(jù)庫郵件配置向?qū)?msdb 用戶或組授予訪問配置文件的權(quán)限。1.3.5 數(shù)據(jù)庫郵件故障排除：拒絕了對 sp_send_dbmail 的權(quán)限 本主題介紹如何對報告嘗試發(fā)送數(shù)據(jù)庫郵件的用戶不具有執(zhí)行 sp_send_dbmai

57、l 的權(quán)限的錯誤消息進行故障排除。錯誤文本如下：復(fù)制代碼EXECUTE permission denied on object 'sp_send_dbmail', database 'msdb', schema 'dbo'.若要發(fā)送數(shù)據(jù)庫郵件，用戶必須是 msdb 數(shù)據(jù)庫中的用戶，并且是 msdb 數(shù)據(jù)庫中的 DatabaseMailUserRole 數(shù)據(jù)庫角色的成員。若要將 msdb 用戶或組添加到此角色中，請使用 SQL Server Management Studio 或?qū)π枰l(fā)送數(shù)據(jù)庫郵件的用戶或角色執(zhí)行以下語句。復(fù)制代碼EXEC msd

58、b.dbo.sp_addrolemember rolename = 'DatabaseMailUserRole' ,membername = '<user or role name>'GO1.3.6 數(shù)據(jù)庫郵件故障排除：郵件已排隊，但未傳遞 本主題說明如何解決電子郵件已成功排隊但沒有傳送的問題。 診斷問題數(shù)據(jù)庫郵件外部程序在 msdb 數(shù)據(jù)庫中記錄電子郵件活動。首先，要確認數(shù)據(jù)庫郵件是否已啟用，應(yīng)使用 sp_configure 系統(tǒng)存儲過程的 Database Mail XPs 選項。然后在 msdb 數(shù)據(jù)庫中執(zhí)行下面的語句，檢查郵件隊列的