MCDBA Brasil


  • Home
  • Sobre
  • Contato

Livros





Links Rápidos

SQL Server Builds (All Versions/Editions)


Download SQL Server 2017 (trial)


SQL Server 2017 Feature Pack


SQL Server 2016 Feature Pack


Cumulative Update SQL Server 2017 builds


Cumulative Update SQL Server 2016 builds


Cumulative Update SQL Server 2014 builds


Cumulative Update SQL Server 2012 builds


SQL Server 2005/2008 Samples Databases


Documentando o Servidor SQL Server


Analisando a Performance do Servidor-CheckList


Virtual PASS PT


Faça parte do maior virtual chapter do PASS com conteúdos técnicos em Português sobre SQL Server.

Todos os meses um evento Online para você! Acompanhe aqui os WebCasts já agendados

Sindicalize seu blog ou site ao VirtualPASSPT

SQL Server Blogs

SQL Server Query Processing Team


SQL Programmability & API Development Team


SQL Server Manageability Team


Latin America Support Team


Database + Disk + Performance


Microsoft SQL Server Support


SQL CLR Team


SQL Query Optimization Team


SQL 2005 Code Samples


SQL Server Express Team


SQL SMO Samples


SQL Storage Engine Team


SQL CAT Team


SQL Protocols Team


PSS SQL Server Engineers


Slava Oks on SQLOS


Ken Henderson’s blog


LUTI@Microsoft Blog


kimberly L. Trip’s blog


Fernando Garcia Blog

Artigos

Brigando com os Erros 17182, 17826 e 17120

por Nilton Pinheiro julho 24, 2017 Nenhum comentário

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 (<instance name>)”.
============

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

Avaliação:
Compartilhe:
  • Anterior Brigando com o erro Msg 538 anos atrás
  • Próximo Documentando o Servidor SQL Server8 anos atrás

Deixe uma resposta Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

MVP Reconnect Award

Categorias

  • Artigos (359)
  • Dica da Semana (95)
  • Documentação (54)
  • Downloads (113)
  • MSDE 2000 (3)
  • Sem categoria (1)
  • Tutoriais (9)

Posts recentes

  • #FechouBrasil #PartiuPortugal
  • Brigando com o erro “The cached MSI file is missing”
  • MCDBABRASIL está de volta
  • Documentando o Servidor SQL Server
  • Brigando com os Erros 17182, 17826 e 17120

SQL Server AlwaysOn Video Series

Video1: Introdução ao SQLServer2012 AlwaysOn


Video2: Introdução ao SQLServer2012 AlwaysOn Availability Group


Video3: Introdução ao SQLServer2012 AlwaysOn AVG-Demo


Video4: Introdução ao SQLServer2012 AlwaysOn Listener


Video5: Introdução ao SQLServer2012 AlwaysOn Readable Secondaries


Video6: Introdução ao SQLServer2012 AlwaysOn Readable Secondaries-Demo


Video7: Introdução ao SQLServer2012 AlwaysOn Failover Clustering


Serie SQL Server Failover Clustering End-to-End

Parte 1: Configuração da Rede e Ambiente


Parte 2: Configurando o Windows 2008 R2 Domain Controler e DNS


Parte 3: Preparando os nós para o Failover Cluster


Parte 4: Configurando um Failover Cluster de 2 nós


Parte 5: Configurando as LUNs no iSCSI Software Target (Parte 1)


Parte 6: Configurando as LUNs no iSCSI Software Target (Parte 2)


Parte 7: Apresentando as LUNs para os nós do Failover Cluster


Parte 8: Configurando os discos no Failover Cluster


Parte 9: Instalando a primeira instância virtual do SQL Server 2008


Parte 10: Instalando a segunda instância virtual do SQL Server 2008


Parte 11: Instalando e Configurando o MSDTC no Failover Cluster


Parte 12: Configurando Mount Points no Cluster e SQL Server 2008


Vídeo Extra: Removendo uma Instância do SQL Server 2008 R2 em Cluster


Alta Disponibilidade no SQL Server 2008 R2: Failover Clustering Overview


Alta Disponibilidade no SQL Server 2008 R2: Failover Clustering na Prática

Menu

  • Home
  • Sobre
  • Contato

Mais

  • RSS Feeds
2025 MCDBA Brasil.