Por que as falhas de login podem fazer com que o SQL 2005 seja descartado e descartado?

Question

Nosso servidor SQL 2005 começou a expirar e finalmente parou de responder em 26 de outubro. Os logs do aplicativo mostraram uma tonelada de 17883 eventos que levaram a uma reinicialização. Após a reinicialização, tudo estava bem, mas ainda estávamos coçando nossas cabeças. Avanço rápido 6 dias ... aconteceu de novo. Então novamente 2 dias depois. A última noite. Hoje aconteceu três vezes até agora. A linha do tempo é bastante previsível quando acontece:

1. Backups de log trans.
2. Falha de login para "user2".
3. Minidump
4. Outro minidump para o planejador
5. Eventos 17883 repetidos.
6. O servidor falha pouco a pouco até não aceitar solicitações.
7. A reinicialização é tudo o que nos faz ir de novo (um band-aid)

Interessante, porém, é que a própria caixa do servidor não parece ter nenhum problema. O uso da CPU é normal. Conectividade de rede está bem. Podemos remotamente e ver os logs. O estúdio de gerenciamento, no final das contas, atola.

Hoje, pela primeira vez, tentamos interromper os serviços em vez de uma reinicialização. Todos os serviços pararam sozinhos, exceto pelo serviço do SQL Server. Nós finalmente fizemos uma "tarefa final" e conseguimos trazer tudo de volta. Ele funcionou bem por cerca de 30 minutos até que começamos a ver tempos de espera e 17883 novamente. Desta vez, provavelmente porque não reiniciamos todo o caminho, vimos um monte de 844 eventos misturados com os 17883's.

Toda a nossa equipe de tecnologia aqui está coçando as cabeças ... algumas ideias que estamos inventando:

• A Atualização cumulativa do MS atingiu o mesmo tempo de quando tivemos um problema pela primeira vez. Desde então, nós o revertemos. Talvez não tenha retrocedido todo o caminho.
• A situação se parece com um "estouro de pilha" não manipulado (sem relação), pois começa pequeno e se compõe com o tempo. Problema com isso é que não há uso significativo da CPU. De qualquer forma, não estamos descartando o bug do SQL 2005.
• Talvez tenhamos adicionado muitos processos de importação e atingido nosso limite nessa caixa. (difícil de acreditar).

Olhando para SQLDUMP0151.log no momento de uma das falhas. Existem algumas "falhas de login" e, em seguida, há dois despejos de pilha. 1º um despejo de pilha normal, 2º para um despejo de agendador. Aqui está um trecho: (desculpe pela falta de quebras de linha)

2009-11-10 11:59:14.95 spid63 Using 'xpsqlbot.dll' version '2005.90.3042' to execute extended stored procedure 'xp_qv'. This is an informational message only; no user action is required. 2009-11-10 11:59:15.09 spid63 Using 'xplog70.dll' version '2005.90.3042' to execute extended stored procedure 'xp_msver'. This is an informational message only; no user action is required. 2009-11-10 12:02:33.24 Logon Error: 18456, Severity: 14, State: 16. 2009-11-10 12:02:33.24 Logon Login failed for user 'standard_user2'. [CLIENT: 50.36.172.101] 2009-11-10 12:08:21.12 Logon Error: 18456, Severity: 14, State: 16. 2009-11-10 12:08:21.12 Logon Login failed for user 'standard_user2'. [CLIENT: 50.36.172.101] 2009-11-10 12:13:49.38 Logon Error: 18456, Severity: 14, State: 16. 2009-11-10 12:13:49.38 Logon Login failed for user 'standard_user2'. [CLIENT: 50.36.172.101] 2009-11-10 12:15:16.88 Logon Error: 18456, Severity: 14, State: 16. 2009-11-10 12:15:16.88 Logon Login failed for user 'standard_user2'. [CLIENT: 50.36.172.101] 2009-11-10 12:18:24.41 Logon Error: 18456, Severity: 14, State: 16. 2009-11-10 12:18:24.41 Logon Login failed for user 'standard_user2'. [CLIENT: 50.36.172.101] 2009-11-10 12:18:38.88 spid111 Using 'dbghelp.dll' version '4.0.5' 2009-11-10 12:18:39.02 spid111 ***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\SQLDump0149.txt 2009-11-10 12:18:39.02 spid111 SqlDumpExceptionHandler: Process 111 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process. 2009-11-10 12:18:39.02 spid111 * ******************************************************************************* 2009-11-10 12:18:39.02 spid111 * 2009-11-10 12:18:39.02 spid111 * BEGIN STACK DUMP: 2009-11-10 12:18:39.02 spid111 * 11/10/09 12:18:39 spid 111 2009-11-10 12:18:39.02 spid111 * 2009-11-10 12:18:39.02 spid111 * 2009-11-10 12:18:39.02 spid111 * Exception Address = 0159D56F Module(sqlservr+0059D56F) 2009-11-10 12:18:39.02 spid111 * Exception Code = c0000005 EXCEPTION_ACCESS_VIOLATION 2009-11-10 12:18:39.02 spid111 * Access Violation occurred writing address 00000000 2009-11-10 12:18:39.02 spid111 * Input Buffer 138 bytes - 2009-11-10 12:18:39.02 spid111 * " N R S C _ P T A 22 00 4e 00 52 00 53 00 43 00 5f 00 50 00 54 00 41 00 2009-11-10 12:18:39.02 spid111 * C _ Q A . d b o . 43 00 5f 00 51 00 41 00 2e 00 64 00 62 00 6f 00 2e 00 2009-11-10 12:18:39.02 spid111 * U s p S e l N e x 55 00 73 00 70 00 53 00 65 00 6c 00 4e 00 65 00 78 00 2009-11-10 12:18:39.02 spid111 * t A c c o u n t 74 00 41 00 63 00 63 00 6f 00 75 00 6e 00 74 00 00 00 2009-11-10 12:18:39.02 spid111 * @ i n t F o r m I 0a 40 00 69 00 6e 00 74 00 46 00 6f 00 72 00 6d 00 49 2009-11-10 12:18:39.02 spid111 * D & 8 @ t x 00 44 00 00 26 04 04 38 00 00 00 09 40 00 74 00 78 00 2009-11-10 12:18:39.02 spid111 * t A l i a s § 74 00 41 00 6c 00 69 00 61 00 73 00 00 a7 0f 00 09 04 2009-11-10 12:18:39.02 spid111 * Ð GQE9732 d0 00 00 07 00 47 51 45 39 37 33 32 2009-11-10 12:18:39.02 spid111 *
2009-11-10 12:18:39.02 spid111 * 2009-11-10 12:18:39.02 spid111 * MODULE BASE END SIZE 2009-11-10 12:18:39.02 spid111 * sqlservr 01000000 02C09FFF 01c0a000 2009-11-10 12:18:39.02 spid111 * ntdll 7C800000 7C8C1FFF 000c2000 2009-11-10 12:18:39.02 spid111 * kernel32 77E40000 77F41FFF 00102000

    

Answer 1

UspSelNex - este é um procedimento armazenado que está sempre em execução quando você tem o seu problema?