Brigando com os Erros 17182, 17826 e 17120
Bom, o problema se resume que após instalar o SQL Server 2005 em configuração Cluster Ativo/Passivo, entrei no SQL Server Configuration Manager, adicionei alguns trace flags (padrão do meu ambiente) e em IP Address, em IPALL configurei “Ports” como 1433,14330. Ou melhor, esta era a intenção mas por um erro de digitração acabei colocando 1433;14330. Salvei as configuarações, fui até o Cluster Administrator e forcei um failover.
Hehe, para minha surpresa o serviço do SQL Server falhou e aí começaram meus problemas. Ao tentar iniciar o serviço do SQL Server no cluster, o SQL Server não iniciava e no errorlog log eram apresentadas as seguintes mensagens:
2008-02-15 23:39:00.63 Server Error: 17182, Severity: 16, State: 1.
2008-02-15 23:39:00.63 Server TDSSNIClient initialization failed with error 0xd, status code 0x10.
2008-02-15 23:39:00.63 spid5s The NETBIOS name of the local node that is running the server is ‘SQLPRD1′. This is an informational message only. No user action is required.
2008-02-15 23:39:00.63 Server Error: 17182, Severity: 16, State: 1.
2008-02-15 23:39:00.63 Server TDSSNIClient initialization failed with error 0xd, status code 0x1.
2008-02-15 23:39:00.63 Server Error: 17826, Severity: 18, State: 3.
2008-02-15 23:39:00.63 Server Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.
2008-02-15 23:39:00.63 Server Error: 17120, Severity: 16, State: 1.
2008-02-15 23:39:00.63 Server SQL Server could not spawn FRunCM thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.
No blog do SQL Server Protocols Team, encontrei vários posts falando sobre o problema e todos eles citavam algum erro na configuração dos protocolos. No entanto, embora para muitos as soluções passadas funcionaram, no meu caso, não funcionava.
(Reune vários post no blog SQL Protocols)
http://blogs.msdn.com/sql_protocols/search.aspx?q=TDSSNIClient+initialization+failed+with+error+0xd%2c+status+code+0x10&p=1
Identifiquei então o problema na configuração das portas e voltei a configuração original. Ao reiniciar o serviço do SQL Server no Cluster, ele não subiu! Achei estranho e verifiquei novamente a configuração das portas, para minha surpresa, a configuração incorreta havia voltado.
Fiquei “P” e pensei, caramba….de onde ele está pegando esta configuração….acabei de corrigir!
Pensei…ok, vou radicalizar e alterar no registry. Acessei então a chave do registro HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Microsoft SQL Server/MSSQL.1/MSSQLServer/SuperSocketNetLib/Tcp/IPAll e lá estava. Na chave TcpPort eu tinha 1433;14330. Alterei o valor da chava para o valor default (1433) e fechei o registro. Abri o SQL Server Configuration Manager e estava tudo certo. Tentei então iniciar o serviço do SQL Server….. pau !! O pior, voltou tudo errado novamente.
Refiz as alterações no registro, mas desta vez nos dois nós do cluster e reinicei as máquinas deixando o SQL Server offline no cluster. Após as máquinas subirem, verifiquei mais uma vez as configurações no registry e no SSCM e estava tudo certo. Pensei…agora vai! Abri o Cluster Administrator e iniciei o serviço do SQL Server online…pau e tudo voltou à estaca zero. Não entendi nada!
Pesquisando agora por este tipo de comportamento, encontrei no mesmo blog do SQL Server Protocol o post “Unable to correct invalid SQL Server Network Configuration on clustered SQL Server causes clustered SQL Server fail to start “permanently“que parecia ser a solução do problema. Ele explica porque embora eu corrigia as configurações no Server Configuration Manager, o cluster não as considerava e pior, fazia tipo um rollback das configurações corretas. O post dizia como resolver o problema e tudo parecia ser muito simples, bastava desativar o serviço de checkpoint do cluster, corrigir as informações no SQL Server Configuration Manager, subir o SQL Server e ativar o checkpoint. O post descrevia os passos exatamente como estão apresentados abaixo:
Nota: Na chave do registro a barra correta é a de separação de diretório. Tive que inverter aqui devida a uma limitação técnica.
============
1. While SQL Server instance is in offline/failed state, disable cluster checkpointing for network configuration by:
cluster res “SQL Server” /removecheck:”Software/Microsoft/Microsoft SQL Server/MSSQL.XXX/MSSQLSERVER”
2. Correct the configuration by using SSCM. Verified the key was corrected on both nodes.
3. Bring SQL cluster back online.
4. Re-enabled cluster checkpointing for network configuration by:
cluster res “SQL Server” /addcheck: ”Software/Microsoft/Microsoft SQL Server/MSSQL.XXX/MSSQLSERVER”
Note that, for named instance, the resource display name “SQL Server” should be replaced with “SQL Server (
============
Pensei… excelente, isso faz todo sentido e deve resolver meu problema. Abri o prompt do DOS e parti então para o primeiro passo:
cluster res “SQL Server” /removecheck:”Software/Microsoft/Microsoft SQL Server/MSSQL.1/MSSQLSERVER”
Logo de cara recebi a mensagem de erro abaixo:
The ‘removecheck’ option does not require any parameters to be specified.
See “CLUSTER RESOURCE /?” for correct syntax.
Fui então em busca de mais informações sobre “cluster res e removecheck”. Foi aí que encontrei um artigo oficial da Microsoft (KB 912397 – http://support.microsoft.com/kb/912397/en-us) sobre o título “The SQL Server service cannot start when you change a startup parameter for a clustered instance of SQL Server 2000 or of SQL Server 2005 to a value that is not valid“. O artigo fala sobre o problema e tambén indica a utilização do comando cluster res com as opções /removecheck e /addcheck como solução. Exatamente o mesmo já descrito acima. O WORKAROUND não funcionava, sempre era apresentada a mensagem de erro já descrita.
Bom, isso já era umas 02:00 da manhã e resolvi então abrir um chamado no suporte premier para buscar uma solução mais rápida. O engenheiro acessou meu servidor e o problema foi resolvido executando os 5 passos descritos abaixo:
Nota: Na chave do registro a barra correta é a de separação de diretório. Tive que inverter aqui devida a uma limitação técnica.
Passo 1:
=========
Este primeiro passo apenas lista as entradas no registry para o recurso SQL Server. No prompt do DOS execute:
C:/> cluster res “SQL Server” /checkpoints
Listing registry checkpoints for resource ‘SQL Server’…
Resource Registry Checkpoint
——————– ——————————————————–
SQL Server ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/Cluster’
SQL Server ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/MSSQLServer’
SQL Server ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/Replication’
SQL Server ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/SQLServerAgent’
SQL Server ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/PROVIDERS’
SQL Server ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/SQLServerSCP’
SQL Server ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/CPE’
Passo 2:
=========
Este segundo passo efetivamente remove a entrada especificada do registry.
C:/>cluster res “SQL Server” /removecheckpoints:”Software/Microsoft/Microsoft SQL Server/MSSQL.1/MSSQLServer”
Removing registry checkpoint ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/MSSQLServer’ for resource ‘SQL Server’…
Depois o comando abaixo foi executado apenas para garantir que a chave não é mais listada. Notem que foi removida a chave: ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/MSSQLServer’
C:/>cluster res “SQL Server” /checkpoints
Listing registry checkpoints for resource ‘SQL Server’…
Resource Registry Checkpoint
——————– ——————————————————–
SQL Server ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/Cluster’
SQL Server ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/Replication’
SQL Server ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/SQLServerAgent’
SQL Server ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/PROVIDERS’
SQL Server ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/SQLServerSCP’
SQL Server ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/CPE’
Passo 4:
========
Neste ponto o engenheiro solicitou que eu abrisse o SQL Server Configuration Manager e alterasse as configurações para as corretas. Fiz isso e o engenheiro continuou executando o comando abaixo. Este comando efetivamente adicionou no registry uma nova entrada para o recurso do SQL Server.
C:/>cluster res “SQL Server” /addcheckpoints:”Software/Microsoft/Microsoft SQL Server/MSSQL.1/MSSQLServer”
Adding registry checkpoint ‘Software/Microsoft/Microsoft SQL Server/MSSQL.1/MSSQLServer’ for resource ‘SQL Server’…
Pass 5:
=======
Após executar o passo 4 o engenheiro solicitou para iniciar o serviço do SQL Server no cluster. BINGO, problema resolvido!!
Bom, não preciso nem dizer que fiquei literalmente “PUTO” né !? Eu estava indo no caminho certinho não fosse:
1. Usar /removecheck no lugar de /removecheckpoints
2. Usar MSSQLServer no lugar de MSSQLSERVER (a porcaria dos comandos são case-sensitive e é preciso informar a chave exatamente como ela aparece no registro do windows.
Pena que os posts do blog e nem mesmo o KB da MS diziam isso né? Assim eu não teria aberto um chamado desnecessário.
Logicamente que reclamei do KB e foi aberto um ocorrência interna para sua revisão e alteração, também deverá ser adicionado ao KB o uso da opção /checkpoints que certamente ajuda bastante na identificação da chave correta.
Bom, problema solucionado, SQL Server no ar e vamos para o próximo
Abraços e espero que este artigo possa ajudar quem estiver passando pelo mesmo problema.
Um abraço
Nilton Pinheiro
|
|
Fonte: Nilton Pinheiro