![]() | |
#41
| |||
| |||
|
|
Just to make sure, I rebooted both nodes. Once both nodes are back online, checked the app log. after the windows startup information, I start to see the SQL events: Log Name: Application Source: MSSQLSERVER Date: 9/30/2008 12:29:09 PM Event ID: 18456 Task Category: (4) Level: Information Keywords: Classic,Audit Failure User: ANONYMOUS LOGON Computer: wrangell.grad.washington.edu Description: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. [CLIENT: 128.208.112.63] Log Name: Application Source: MSSQLSERVER Date: 9/30/2008 12:29:09 PM Event ID: 19019 Task Category: (3) Level: Error Keywords: Classic User: N/A Computer: wrangell.grad.washington.edu Description: [sqsrvres] ODBC sqldriverconnect failed Log Name: Application Source: MSSQLSERVER Date: 9/30/2008 12:29:09 PM Event ID: 19019 Task Category: (3) Level: Error Keywords: Classic User: N/A Computer: wrangell.grad.washington.edu Description: [sqsrvres] checkODBCConnectError: sqlstate = 28000; native error = 4818; message = [Microsoft][SQL Native Client][SQL Server]Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. This repeats for about 1 minute, then I see: Log Name: Application Source: MSSQLSERVER Date: 9/30/2008 12:29:09 PM Event ID: 19019 Task Category: (3) Level: Error Keywords: Classic User: N/A Computer: wrangell.grad.washington.edu Description: [sqsrvres] OnlineThread: Error connecting to SQL Server. Log Name: Application Source: MSSQLSERVER Date: 9/30/2008 12:29:11 PM Event ID: 19019 Task Category: (3) Level: Error Keywords: Classic User: N/A Computer: wrangell.grad.washington.edu Description: [sqsrvres] OnlineThread: did not connect after 10 attempts resource failed Then (I'm just copying the details for below as there is quite a bit): Service Broker manager has shut down. SQL Server is terminating in response to a 'stop' request from Service Control Manager. This is an informational message only. No user action is required. SQL Trace was stopped due to server shutdown. Trace ID = '1'. This is an informational message only; no user action is required. The SQL Network Interface library could not deregister the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098. Administrator should deregister this SPN manually to avoid client authentication errors. MSDTC encountered an error (HR=0x80000171) while attempting to establish a secure connection with system WRANGELL. [sqsrvres] CheckServiceAlive: Service is dead [sqsrvres] OnlineThread: service stopped while waiting for QP. [sqsrvres] OnlineThread: Error 1 bringing resource online. [sqsrvres] CheckServiceAlive: Service is dead "Virgil Gloria" wrote: I have a 2 active/passive cluster running Windows Server 2008 Enterprise. I just installed SQL 2005 Server, which had no problems. However, when I look at failover cluster managment, under Services and Application, SQL server is listed as failed, and SQL server Agent is listed as offline (due to being dependant on SQL Server being online). If I attempt to bring the failed resource online, the status goes to 'Pending' for a few seconds, then failed yet again. I know I added the service account that I used in the SQL server setup as local admin. Below is what I see in Event log. Log Name: System Source: Microsoft-Windows-FailoverClustering Date: 9/30/2008 11:36:31 AM Event ID: 1069 Task Category: Resource Control Manager Level: Error Keywords: User: SYSTEM Computer: <my_cluster_node Description: Cluster resource 'SQL Server' in clustered service or application '<my_SQL_cluster_virtual name' failed. Anyone have an idea of how to approach/solve this problem? If I search on support.microsoft.com, I find the following KB: http://support.microsoft.com/kb/883732/en-us which has the same error message. I'm not sure if this will cure my problems but will try it. The only problem is in the resolution, it states to use regedit and drill down to the following key: HKEY_LOCAL_MACHINE\Cluster\Resources\<GUID>\Parame ters How do I know which <GUID> to use? |
#42
| |||
| |||
|
|
This looks like a side effect of running the cluster under local system instead of a domain account. The local system cannot connect to the SQL Service to execute the looksalive and isalive checks. Since the cluster cannot see SQL, it thinks the resource failed and drops offline. Try starting SQL on one node only via the service control manager or via command-line. It should start but won't be under cluster control. If that is the case, then we can proceed to try and fix this. |
#43
| |||
| |||
|
|
This looks like a side effect of running the cluster under local system instead of a domain account. The local system cannot connect to the SQL Service to execute the looksalive and isalive checks. Since the cluster cannot see SQL, it thinks the resource failed and drops offline. Try starting SQL on one node only via the service control manager or via command-line. It should start but won't be under cluster control. If that is the case, then we can proceed to try and fix this. |
#44
| |||
| |||
|
|
This looks like a side effect of running the cluster under local system instead of a domain account. The local system cannot connect to the SQL Service to execute the looksalive and isalive checks. Since the cluster cannot see SQL, it thinks the resource failed and drops offline. Try starting SQL on one node only via the service control manager or via command-line. It should start but won't be under cluster control. If that is the case, then we can proceed to try and fix this. |
#45
| |||
| |||
|
|
This looks like a side effect of running the cluster under local system instead of a domain account. The local system cannot connect to the SQL Service to execute the looksalive and isalive checks. Since the cluster cannot see SQL, it thinks the resource failed and drops offline. Try starting SQL on one node only via the service control manager or via command-line. It should start but won't be under cluster control. If that is the case, then we can proceed to try and fix this. |
#46
| |||
| |||
|
|
This looks like a side effect of running the cluster under local system instead of a domain account. The local system cannot connect to the SQL Service to execute the looksalive and isalive checks. Since the cluster cannot see SQL, it thinks the resource failed and drops offline. Try starting SQL on one node only via the service control manager or via command-line. It should start but won't be under cluster control. If that is the case, then we can proceed to try and fix this. |
#47
| |||
| |||
|
|
This looks like a side effect of running the cluster under local system instead of a domain account. The local system cannot connect to the SQL Service to execute the looksalive and isalive checks. Since the cluster cannot see SQL, it thinks the resource failed and drops offline. Try starting SQL on one node only via the service control manager or via command-line. It should start but won't be under cluster control. If that is the case, then we can proceed to try and fix this. |
#48
| |||
| |||
|
|
This looks like a side effect of running the cluster under local system instead of a domain account. The local system cannot connect to the SQL Service to execute the looksalive and isalive checks. Since the cluster cannot see SQL, it thinks the resource failed and drops offline. Try starting SQL on one node only via the service control manager or via command-line. It should start but won't be under cluster control. If that is the case, then we can proceed to try and fix this. |
#49
| |||
| |||
|
|
This looks like a side effect of running the cluster under local system instead of a domain account. The local system cannot connect to the SQL Service to execute the looksalive and isalive checks. Since the cluster cannot see SQL, it thinks the resource failed and drops offline. Try starting SQL on one node only via the service control manager or via command-line. It should start but won't be under cluster control. If that is the case, then we can proceed to try and fix this. |
#50
| |||
| |||
|
|
This looks like a side effect of running the cluster under local system instead of a domain account. The local system cannot connect to the SQL Service to execute the looksalive and isalive checks. Since the cluster cannot see SQL, it thinks the resource failed and drops offline. Try starting SQL on one node only via the service control manager or via command-line. It should start but won't be under cluster control. If that is the case, then we can proceed to try and fix this. |
![]() |
| Thread Tools | |
| Display Modes | |
| |