外文翻譯--如何解決 SQL Server 2000 中的連接問題

附錄 B 外文文獻 How to troubleshoot connectivity issues in SQL Server 2000 Chris Tull, Microsoft Help and Support This article can help you to resolve connectivity problems with Microsoft SQL Server 2000. This article contains descriptions of common connectivity problems and the steps that you can take to help resolve your connectivity problems. SQL Server 2000 supports several methods of communication between the instance of SQL Server and the client applications. If your client application and the instance of SQL Server reside on the same computer, Microsoft Windows interprocess communication (IPC) components, such as local named pipes or the Shared Memory protocol, are used to communicate. However, when the client application and the instance of SQL Server reside on different computers, a network IPC, such as TCP/IP or named pipes, is used to communicate. SQL Server 2000 uses Net-Library, a DLL, to communicate with a particular network protocol. A matching pair of Net-Libraries must be active on the client computer and the server computer to support the network protocol that you want to use. For example, if you want to enable a client application to communicate with a specific instance of SQL Server across TCP/IP, the client TCP/IP Sockets Net-Library (Dbnetlib.dll) must be configured to connect to the server on the client computer. Likewise, the server TCP/IP Sockets Net-Library (Ssnetlib.dll) must listen on the server computer. In this scenario, the TCP/IP protocol stack must be installed on both the client computer and the server computer. After you install SQL Server 2000, you can configure the properties of the client Net-Libraries by using Client Network Utility. You can configure the properties of the server Net-Libraries by using Server Network Utility (Svrnetcn.exe). The server Net-Libraries are installed during the installation of the server tools in SQL Server Setup. However, some of the server Net-Libraries may not be active. By default, SQL Server 2000 enables and listens on TCP/IP, named pipes, and Shared Memory. Therefore, for a client to connect to a server computer, the client must connect by using a client Net-Library that matches one of the server Net-Libraries that is currently being used by the instance of SQL Server. For additional information about SQL Server communication components and Net-Libraries, see the following topics in SQL Server Books Online: Communication Components Client and Server Net-Libraries Managing Clients Troubleshoot connectivity issues Most of the connectivity issues that you may notice in SQL Server 2000 occur because of problems with TCP/IP, Windows authentication, or a combination of TCP/IP and Windows authentication. Important Before you start to troubleshoot connectivity issues in SQL Server 2000, make sure that the MSSQLServer service is started on the computer that is running SQL Server. Verify your DNS settings The name resolution process in Domain Name System (DNS) is used to resolve the IP address to the name of the instance of SQL Server. If the name resolution process does not work correctly, the instance of SQL Server is not reachable, and you may receive one or more of the following error messages: SQL Server does not exist or access denied General Network Error Cannot Generate SSPI Context To verify that the name resolution process is resolving the correct server, you can ping the server by using the server name and the IP address of the server. To do so, follow these steps: 1. Click Start, and then click Run. 2. In the Run dialog box, type cmd in the Open box, and then click OK. 3. At the command prompt, run the following command: ping Note the IP address that is returned. 4. At the command prompt, run the following command (where IP address is the IP address that you noted in step 3): ping a Verify that the command resolves to the correct server name. If either of the specified commands are not successful, time out, or do not return the correct values, the DNS lookup is not working correctly or the problem occurs because of other networking or routing issues. To see your current DNS settings, run the following command at a command prompt: ipconfig /all To work around this problem, add an entry for the server to the %systemroot%system32d- riversetchosts file on the client computer. You can also work around the problem by connecting to the server by using the Named Pipes Net-library. Verify the enabled protocols and aliases Connectivity problems may occur if the alias on the client computer is set incorrectly. You can view the aliases by using Client Network Utility. To do so, follow these steps: 1. Start Client Network Utility. If the SQL Server client tools are installed on the computer that is running the client application, follow these steps to start Client Network Utility: a. Click Start, and then point to Programs. b. Point to Microsoft SQL Server, and then click Client Network Utility. If the SQL Server client tools are not installed on the client computer, follow these steps to start Client Network Utility: a. Click Start, and then click Run. b. In the Run dialog box, type cliconfg in the Open box, and then click OK. 2. In the SQL Server Client Network Utility window, click the General tab, and then enable all the protocols that you want to use. Note You must at least enable the TCP/IP protocol and the named pipes protocol. 3. Click the Alias tab, and then verify the aliases that are configured for the instance of SQL Server. 4. Verify the properties of the aliases to make sure that the server name or IP address and the protocol are configured correctly. You can create a new alias to test the connectivity by using the server name, the IP address, or even by using a different protocol. Note Earlier versions of Microsoft Data Access Components (MDAC) have a different user interface for Client Network Utility. Therefore, if you do not see the options that are listed in this article, install a later version of MDAC on the computer that is running the client application. Verify that the instance of SQL Server is listening correctly To verify that the instance of SQL Server is listening on named pipes, TCP/IP, or another protocol that you are using at the client application, open the current SQL Server error log file. The SQL Server error log file may contain entries that are similar to the following: 2003-11-06 09:49:36.17 server SQL server listening on TCP, Shared Memory, Named Pipes. 2003-11-06 09:49:36.17 server SQL server listening on 192.168.1.5:1433, 127.0.0.1:1433. If you analyze the entries in the SQL Server error log file, you can verify that the instance of SQL Server is listening on the correct IP address and on the correct port. By default, a default instance of SQL Server listens on the port 1433. You can also use Server Network Utility to verify the protocol settings for SQL Server and to change the properties in SQL Server, including the protocols that can connect to SQL Server and the ports that can be used. For more information about using Server Network Utility, see the SQL Server Network Utility topic in SQL Server Books Online. Sometimes, SQL Server 2000 may not bind to port 1433 or any other specified port. This problem may occur if the port is being used by another application or if you are trying to connect by using an IP address that is not correct. Therefore, the TCP/IP connections to SQL Server may not be successful and you may receive the following error message in the SQL Server error log file: 2001-11-14 15:49:14.12 server SuperSocket Info: Bind failed on TCP port 1433.If you cannot connect to the instance of SQL Server by using a TCP/IP connection, try to use the named pipes protocol or the Shared Memory protocol. Run the following command at a command prompt to obtain information about the ports that are in use: NETSTAT an You can also use the Portqry command-line utility to obtain more information about the ports that are in use. Note For named instances of SQL Server, SQL Server dynamically determines the port and listens on the determined port. Therefore, when you start the named instance of SQL Server, SQL Server tries to listen on the port that was previously being used. If SQL Server cannot bind to that port, the named instance may dynamically bind to a different port. In that situation, make sure that the client application is also set to determine the port dynamically. Alternatively, you can also specify a static port for the named instance to bind to and to listen on by using Client Network Utility. Troubleshoot MDAC Issues Connectivity problems may also occur because of problems with MDAC. For example, a software installation may overwrite some of the MDAC files or change the permissions that you must have to access the MDAC files. You can run the MDAC Component Checker to verify the MDAC installation on your computer. Note If you are connecting to a named instance of SQL Server, make sure that you are running MDAC 2.6 or later on your computer. Earlier versions of MDAC do not recognize named instances of SQL Server. Therefore, connections to named instances may not be successful. You can use the Odbcping.exe utility to verify connections through the SQL Server ODBC driver. You can also test connectivity to the instance of SQL Server by using a .udl file. Troubleshoot firewall issues If firewall exists between the client computer and the computer that is running SQL Server, make sure that the ports that are required to communicate through the firewall are open. If you use the TCP/IP protocol to connect to the instance of SQL Server, make sure that you can use the Telnet program to connect to the port where SQL Server is listening. To use the Telnet program, run the following command at a command prompt: Telnet If the Telnet program is not successful and you receive an error message, resolve the error and then try to connect again. Note Because of issues that were caused by the Slammer virus, the User Datagram Protocol (UDP) port 1434 may be blocked on your firewall. Troubleshoot authentication and security issues Connections to SQL Server may not be successful because of authentication failures. If the authentication fails, you may receive one of the following error messages: Login failed for user Login failed for user NTAUTHORITYANONYMOUS LOGON Login failed for user null If you receive an error message because of an authentication failure and the error message does not mention a specific SQL Server login name, troubleshoot the problem with Windows authentication. You may receive the following error message because of problems with Windows authentication: Cannot generate SSPI Context The following problems may cause authentication and security issues: Problems occur with NTLM authentication or with Kerberos authentication. The domain controller cannot be contacted because of connectivity issues. Problems occur with trust relationships across domains. For more information about possible causes, see the event logs on the computer. To work around connectivity problems with Windows authentication, you can use SQL Server Authentication to connect to the instance of SQL Server. If the connection is not successful when you use SQL Server Authentication, you receive the following error message: Login failed for user . Not associated with a trusted connection To troubleshoot this problem, follow these steps. Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. 1. Make sure that the instance of SQL Server is configured to use Windows authentication and SQL Server Authentication. To do so, make sure that the following registry keys are on the computer that is running SQL Server. For the default instance of SQL Server: HKEY_LOCAL_MACHINESoftwareMicrosoftMSSQLServerMSSQLServerLoginMode For the named instance of SQL Server: HKEY_LOCAL_MACHINESoftwareMicrosoftMicrosoft SQL ServerMSSQLServerLoginMode Make sure that the following registry key values are set: Authentication type Value Windows authentication only 1 Mixed mode (SQL Server Authentication and Windows authentication) 2 Note If you make any changes to the registry, you must stop and then restart the instance of SQL Server for the changes to take effect. 2. Try to connect to the instance of SQL Server by using different Windows accounts or SQL Server login accounts. This can help determine if the connection is not successful because of problems with a particular login account. For example, the password of the login account may have been changed. 3. Try to connect to the instance of SQL Server by using different protocols. For example, the connections that use the TCP/IP protocol with Windows authentication may not be successful, but connections that use the named pipes protocol with Windows authentication may be successful. If you are using certificates, you may receive a Secure Sockets Layer (SSL) security error message when you try to connect to the instance of SQL Server. Troubleshoot stress on TCP/IP sockets When you use the SQL Server ODBC driver, the Microsoft OLE DB Provider for SQL Server, or the System.Data.SqlClient managed provider, you can disable connection pooling by using the appropriate application programming interfaces (APIs). When you disable connection pooling and your application frequently opens and closes connections, the stress on the underlying SQL Server network library may increase. Sometimes, the Web servers and the JDBC drivers may also try to connect to the instance of SQL Server. Therefore, the increase in connection requests to SQL Server may be more than SQL Server can handle. This may stress the TCP/IP sockets, and you may receive the following error message in the SQL Server error log file: 2003-08-07 20:46:21.11 server Error: 17832, Severity: 20, State: 6 2003-08-07 20:46:21.11 server Connection opened but invalid login packet(s) sent. Connection closed. For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base: 154628 INF: SQL logs 17832 with multiple TCPIP connection requests 328476 TCP/IP settings for SQL Server drivers when pooling is disabled Note You may not notice the stress on TCP/IP sockets if you are running SQL Server 2000 SP3 or SQL Server 2000 SP3a because a limit on the number of login packets was added. The 17832 error occurs when you use third-party drivers to connect to the instance of SQL Server. To resolve this problem, contact the third-party vendor and obtain drivers that have been tested to work with SQL Server 2000 SP3 and SQL Server 2000 SP3a. See if the instance of SQL Server is started in single-user mode If the instance of SQL Server that you are trying to connect to is started in single-user mode, only one connection can be established with SQL Server. If you have software running on your computer that automatically connects to SQL Server, the software can easily use the only connection. For example, the following software can automatically connect to the instance of SQL Server: SQL Server Agent Third-party backup software Third-party monitoring software Third-party virus software Microsoft Internet Information Services (IIS) SQL Server Enterprise Manager The client application that is trying to connect to the instance of SQL Server receives the following error message: SQL Server does not exist or Access Denied This error generally occurs during SQL Cluster Setup and service pack setup when the setup process starts the instance of SQL Server in single-user mode. The specified applications may automatically connect to the instance of SQL Server using the only available connection, and setup is not successful. To determine if the instance of SQL Server has been started in single-user mode, check to see if the SQL Server error log file has an entry that is similar to following: 2003-07-31 11:26:43.79 spid3 Warning * 2003-07-31 11:26:43.80 spid3 SQL Server started in single user mode. Updates allowed to system catalogs. Verify named pipes connectivity to SQL Server If you cannot connect to the instance of SQL Server by using named pipes, make sure that the instance of SQL Server is configured to accept named pipes connections. Troubleshoot connections that time out during the recovery process Every time that you start an instance of SQL Server, SQL Server recovers each database. During this recovery process, SQL Server rolls back the transactions that are not committed. SQL Server also rolls forward the transactions that are committed and the changes that were not written to the hard disk when the instance of SQL Server was stopped. When the recovery process is complete, SQL Server logs the following message in the SQL Server error log file: Recovery Complete During the recovery process, SQL Server may not accept connections. Clients that try to connect to the instance of SQL Server during that time may receive an error message that is similar to the following: Timeout Expired The SQL Server Agent service may not start because it waits for SQL Server to recover the databases. Therefore, when you receive the following message in the SQL Server error log file, the connections will no longer fail with a timeout error: Recovery Complete If the recovery process takes a long time, you may have to additionally troubleshoot the recovery process. Test different ways to connect to the instance of SQL Server If you experience connectivity problems when you connect to the instance of SQL Server, you can use one or more of the following methods to work around the connectivity problem. Test the connectivity to the instance of SQL Server by using both SQL Server Authentication and Windows authentication. Test the connectivity to the instance of SQL Server from other data sources, such as an ODBC DSN, a .udl file, SQL Query Analyzer, SQL Server Enterprise Manager, the isql utility, or the osql utility. Test the connectivity to the instance of SQL Server by using different protocols. You can specify different protocols by creating a new alias for the instance of SQL Server using that protocol. You can also specify the protocol in your connection string by adding tcp:, np:, lpc:, or rpc: to the beginning of the name of the instance of SQL Server. For example, if TCP/IP connections are not successful, named pipes connections succeed. Test the connectivity by using a different login account to help you determine if the problem is associated with a particular login account. Try to add an entry that corresponds to the IP address of the computer that is running the instance of SQL Server to the %systemroot%system32driversetchosts file. Try to connect to the instance of SQL Server from the computer that is running SQL Server and from the client. If you are connecting from the computer that is running SQL Server, you can specify . or (local) (without the quotation marks) instead of the server name and then connect. Try to connect to the instance of SQL Server by using the IP address instead of the server name. Try to specify the specific port that the instance of SQL Server is listening on, either by creating an alias or by adding a port number to the connection string (MyServerMyInstance, 1433, for example). 附錄 C 外文文獻中文譯文 如何解決 SQL Server 2000 中的連接問題 Chris Tull, Microsoft Help and Support 這一篇文章能幫助你解決微軟 SQL 伺候器 2000 的連接性問題。這一篇文章包含你能拿幫助解決你的連接性問題的通常連接性問題和步驟的描述。 SQL Server的例證和客戶端申請之間的溝通的 SQL Server 2000 支持一些方法。如果你的客戶申請和 SQL Server 的例證在相同的計算機上住 , Microsoft Windows 處理之間的 溝通 (IPC) 成份 （ 像是當?shù)氐拿芑蛘弑环窒淼挠洃浻涗?） 用來溝通。 然而 , 當客戶 端 申請和 SQL Server的例證在不同的計算機 ， 網(wǎng)絡 IPC（ 像是 TCP/IP 上住的時候或者命名管道 ） 用來溝通。 SQL Sever 2000 使用 網(wǎng)絡控件庫 （一個 DLL）與一個特別的網(wǎng)絡記錄溝通。 一雙相配 網(wǎng)絡控件庫 一定在客戶計算機和服務器計算機上是活躍的支援你想要使用的網(wǎng)絡記錄。 舉例來說，如果你想要使一個客戶申請能夠與通過 TCP/IP的一個 SQL Server的特定例證溝通 , 客戶 TCP/IP套接字網(wǎng)絡控件庫 (Dbnetlib.dll) 一定配置成在客戶計算機上對伺候器連接。 同樣地 , 服務器 TCP/IP套接字網(wǎng)絡控件庫 (Ssnetlib.dll) 一定在伺候 器計算機上聽。 在這一個情節(jié)中 , TCP/IP協(xié)議堆棧 一定是裝置在客戶計算機和服務器計算機。 在你安裝 SQL Server 2000 之后，你能配置客戶端網(wǎng)絡的特性使用客戶端網(wǎng)絡公用程序的網(wǎng)絡庫屬性。你能配置服務器網(wǎng)絡的特性使用服務器網(wǎng)絡公用程序(Svrnetcn.exe)的網(wǎng)絡控件庫屬性。在安裝 SQL Server 安裝程序中的服務器工具期間，服務器的網(wǎng)絡庫也被同時安裝了。然而，一些服務器的網(wǎng)絡庫可能不是激活的。如此， SQL Server 2000 啟用并偵聽 TCP/IP、命名管道和共享內存。因此，讓 一個客戶端對一部服務器計算機連接，客戶端一定使用一個客戶端網(wǎng)絡庫，該網(wǎng)絡庫匹配與 SQL Server實例正在使用的服務器網(wǎng)絡庫之一。 對于關于 SQL Server 通訊部件和網(wǎng)絡庫的其它信息，請參見 “SQL Server 在線參考書 ”中的下列主題： 通信部件 客戶端和服務器網(wǎng)絡庫 管理客戶端 解決連接問題 在 SQL Server 2000 中大多數(shù)連接問題你可能會注意到的都是由 TCP/IP 的問題或 Windows 身份認證的問題引起，或者兩者共同組合引起。 重要說明：你開始 解決 SQL Server 2000 的連接問題之前，確定MSSQLServer 服務已在運行 SQL Server 的計算機上啟動。 驗證 DNS 設置 域名系統(tǒng) (DNS)的名稱解析過程被用于解決 IP 對 SQL Server實例名稱。如果名稱解析程序不正確地工作， SQL 服務器的實例不是可到達的，你可能接受到一條或多條下列錯誤信息： SQL Server does not exist or access denied General Network Error Cannot Generate SSPI Context 為了 要確認名稱解析程序是解析正確的服務器，你能使用服務器的服務器名字和 IP 地址 ping服務器。為此，請遵從如下步驟操作： 1. 單擊 “開始 ”，然后單擊 “運行 ”。 2. 在 “運行 ”對話框中，在 “打開 ”框中鍵入 cmd，然后單擊 “確定 ”。 3. 在命令提示符下，運行下列命令： ping 記錄返回的 IP 地址。 4. 在命令提示符下，運行下列命令（此處的 IP address 就是你在步驟 3 中記錄的 IP 地址）： ping a 確認指令跟正確的服務器名字 解決。如果任一指定指令不成功、超時或者沒有返回正確的數(shù)值在兩個指定的命令，那么 DNS 查找未能正常工作，或者因為其它的網(wǎng)絡問題引發(fā)問題。要查看當前 DNS 設定，在命令提示符下運行下列命令： ipconfig /all 要 解 決 此 問 題 ， 可 以 在 客 戶 端 計 算 機 上的 %systemroot%system32driversetchosts 文件中為服務器添加一個條目。要解決此問題，還可以使用命名管道網(wǎng)絡庫連接到服務器。 啟用的協(xié)議和別名的驗證 如果客戶端計算機上的別名錯誤設置，可能會引起連接問題。你可以查看別名使用客 戶端網(wǎng)絡實用程序。為此，請按以下步驟操作： 1. 啟動客戶端網(wǎng)絡實用程序。如果 SQL Server 客戶端工具被安裝在正在運行客戶端應用程序的計算機上，請啟動客戶端網(wǎng)絡實用程序按照以下步驟： a. 單擊 “開始 ”，然后指向 “程序 ”。 b. 指向 “Microsoft SQL Server”，然后單擊 “客戶端網(wǎng)絡實用程序 ”。 如果 SQL Server 客戶端工具沒有安裝在客戶端計算機上，請按照以下步驟啟動客戶端網(wǎng)絡實用程序： a. 單擊 “開始 ”，然后單擊 “運行 ”。 b. 在 “運行 ”對話框中，在 “打開 ”框中鍵入 cliconfg，然后單擊 “確定 ”。 2. 在 “SQL Server 客戶端網(wǎng)絡實用程序 ”窗口中，單擊 “常規(guī) ”標簽，然后啟用你要使用的所有協(xié)議。 注意：你必須啟用 TCP/IP 協(xié)議和命名管道協(xié)議至少。 3. 單擊 “別名 ”標簽，然后驗證為 SQL Server 實例所配置的別名。 4. 驗證別名的屬性，確認服務器名或 IP 地址和協(xié)議的配置是正確的。 你可以測試連接性能創(chuàng)建一個新的別名，通過使用服務器名、 IP 地址或者其他協(xié)議。 注意 ：在 Microsoft 數(shù)據(jù)存取部件 (MDAC) 的早期版本中，客戶端網(wǎng)絡實用程序的用戶界面是不同的。因此，如果你沒有看到選項在本文中列出的，請在正在運行客戶端應用程序的計算機上安裝 MDAC 的新版本。 驗證 SQL Server 實例正在正確地偵聽 要驗證 SQL Server 實例正在正確地偵聽命名管道、 TCP/IP 或你在客戶端應用程序中使用的其他協(xié)議，請打開當前的 SQL Server 錯誤紀錄文件 。 SQL Server 錯誤日志文件可能包括與以下類似的條目： 2003-11-06 09:49:36.17 server SQL server listening on TCP, Shared Memory, Named Pipes. 2003-11-06 09:49:36.17 server SQL server listening on 192.168.1.5:1433, 127.0.0.1:1433. 通過分析 SQL Server 錯誤日志文件中的條目，可以驗證 SQL Server 實例是否正在偵聽正確的 IP 地址和端口。在默認情況下，一個 SQL Server 實例默認偵聽端口 1433。你還可以驗證 SQL Server 的協(xié)議 設置并更改 SQL Server 中的屬性使用服務器網(wǎng)絡實用程序，包括可以連接到 SQL Server 和可以使用的端口的協(xié)議。關于使用服務器網(wǎng)絡實用程序的更多信息，請參見 SQL Server 在線參考書中的 “SQL Server 網(wǎng)絡實用程序 ”專題。 有時候， SQL Server 2000 可能不會綁定于端口 1433 或任何其他指定的端口。如果端口正被其他應用程序使用，或者如果你正在嘗試使用一個錯誤的 IP 地址進行連接，就可能會出現(xiàn)此問題。因此， TCP/IP 到 SQL Server 的連接 可能不成功，在 SQL Server 錯誤日志中你會收到下列錯誤信息： 2001-11-14 15:49:14.12 server SuperSocket Info:Bind failed on TCP port 1433. 如果通過 TCP/IP 連接你不能連接到 SQL Server 實例，請嘗試使用命名管道協(xié)議或共享內存協(xié)議。運行下面的命令在命令提示符下，以獲取信息關于正在使用的端口： NETSTAT -an 注意 ：對于 SQL Server 命名實例， SQL Server 動態(tài)地決定端口并偵聽決定 的端口。因此，當你啟動 SQL Server 命名實例時， SQL Server 將設法偵聽之前使用的端口。如果 SQL Server 不能綁定到該端口，命名實例可能會動態(tài)地綁定到另一個端口。在這種情況下，請確認客戶端應用程序也被設置為動態(tài)地決定端口。作為選擇，你還可以為命名實例指定一個靜態(tài)端口，通過客戶端網(wǎng)絡實用程序對其進行綁定和偵聽。 解決 MDAC 問題 MDAC 的問題也可能會引起連接問題。例如，安裝一個軟件可能會覆蓋一些 MDAC 文件或更改權限，而你需要這些權限才能訪問 MDAC 文件。你可以運行 MDAC 部件檢查器來驗證 MDAC 在計算機上的安裝。 注意 ：如果你正連接到 SQL Server 的一個命名實例，請確認計算機上運行的是 MDAC 2.6 或更新的版本。 MDAC 的早期版本不識別 SQL Server 的命名實例。因此，可能無法連接到命名實例。 你可以使用 Odbcping.exe 實用程序來驗證通過 SQL Server ODBC 驅動程序的連接。 解決防火墻問題 如果防火墻存在于客戶端計算機和正在運行 SQL Server 的計算機之間，請確認通過防火墻進行通信時所需的端口已打開 。 如果你使用 TCP/IP 協(xié)議連接 SQL Server 實例，請確認能夠用 Telnet 程序連接到 SQL Server 正在偵聽的端口。要使用 Telnet 程序，在命令提示符下運行下列命令： Telnet 如果 Telnet 程序沒有成功，并且你接收到錯誤信息，請解決此錯誤然后嘗試再次連接。 注意 ：因為由 Slammer 病毒引起的問題，在你的防火墻上，用戶數(shù)據(jù)報協(xié)議 (UDP) 端口 1434 可能被阻擋。 解決身份驗證和安全問題 由于身份 認證失敗，可能無法連接到 SQL Server。如果身份認證失敗，你可能收到下列錯誤信息之一： Login failed for user Login failed for user NTAUTHORITYANONYMOUS LOGON Login failed for user null 如果你接受 一個錯誤信息因為身份認證失敗和錯誤信息不提到一個特定的SQL Server 登錄名，請使用 Windows 身份認證解決該問題。由于 Windows 身份認證的問題，你可能會 收到下列錯誤信息： Cannot generate SSPI Context 下列問題可能會引起身份認證和安全問題： NTLM 身份認證或 Kerberos 身份認證出現(xiàn)問題。 由于連接問題，無法聯(lián)系域控制器。 域之間的信任關系出現(xiàn)問題。 有關可能原因的更多信息，請參見計算機上的事件日志。要解決 Windows 身份認證的連接問題，你可以使用 SQL Server 身份認證連接到 SQL Server 實例。 有關如何診斷和解決 “Cannot Generate SSPI Context” 如果在使用 SQL Server 身份認證時連接沒有成功，你會收到下列錯誤信息： Login failed for user .Not associated with a trusted connection 若要解決此問題，請按照以下步驟操作。 警告 ：不恰當?shù)氖褂?“注冊表編輯器 ”可能導致嚴重問題，可能需要重新安裝操作系統(tǒng)。 Microsoft 不能保證你可以解決因 “注冊表編輯器 ”使用不當而導致的問題。使用 “注冊表編輯器 ”的風險需要你承擔。 1. 請確認 SQL Server 實 例配置為使用 Windows 身份認證和 SQL Server 身份認證。為此，請確認在正在運行 SQL Server 的計算機上存在下列注冊表項。對于默認的 SQL Server 實例： HKEY_LOCAL_MACHINESoftwareMicrosoftMSSQLServerMSSQLServerLoginMode 對于 SQL Server 的命名實例： HKEY_LOCAL_MACHINESoftwareMicrosoftMicrosoft SQL ServerMSSQLServerLoginMode 請確認已設置下列注冊表項的值： 身份認證類型 值 僅限于 Windows 身份認證 1 混合模式（ SQL Server 身份認證和 Windows 身份認證） 2 注意：如果你對注冊表進行了任何更改，必須關閉并重新啟動 SQL Server 實例使更改生效。 2. 嘗試使用其他 Windows 帳戶或 SQL Server 登錄帳戶連接到 SQL Server 實例。這樣能夠幫助確定是否是由于某個特殊的登錄帳戶的問題而造成連接失敗。例如，登錄帳戶 的密碼可能已被更改。 3. 嘗試使用其他協(xié)議連接到 SQL Server 實例。例如，使用 TCP/IP 協(xié)議進行