Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se:SQL Server
Este artigo fornece informações sobre os seguintes problemas:
- Etapas básicas de solução de problemas
- Recuperar de uma falha do cluster de failover
- Resolver os problemas mais comuns de cluster de failover
- Usar procedimentos armazenados estendidos e objetos COM
Etapas para solucionar problemas
A primeira etapa de diagnóstico é executar uma nova verificação de validação do cluster. Para obter detalhes sobre validação, confira Criar um cluster de failover: Validar a configuração. Isso pode ser concluído sem qualquer interrupção do serviço, pois não afeta nenhum recurso de cluster online.
A validação pode ser executada a qualquer momento após a instalação do recurso de Clustering de Failover, incluindo antes da implantação do cluster, durante a criação do cluster e enquanto o cluster está em execução. Na verdade, testes adicionais são executados quando o cluster está em uso, que verificam se as práticas recomendadas estão sendo seguidas para cargas de trabalho altamente disponíveis. Nessas dezenas de testes, apenas alguns deles afetam a execução de cargas de trabalho de cluster e todos eles estão dentro da categoria de armazenamento, portanto, ignorar toda essa categoria é uma maneira fácil de evitar testes disruptivos.
O cluster de failover possui uma proteção integrada para evitar tempo de inatividade acidental ao executar os testes de armazenamento durante a validação. Se o cluster tiver grupos online quando a validação for iniciada e os testes de armazenamento permanecerem selecionados, ele solicitará ao usuário a confirmação se deseja executar todos os testes (e causar tempo de inatividade) ou ignorar o teste dos discos de qualquer grupo online para evitar o tempo de inatividade. Se toda a categoria de armazenamento foi excluída de ser testada, esse prompt não será exibido. Isso habilita a validação de cluster sem tempo de inatividade.
Como revalidar seu cluster
No snap-in Cluster de Failover, na árvore do console, certifique-se de que Gerenciamento de Cluster de Failover esteja selecionado e, em seguida, em Gerenciamento, selecione Validar uma Configuração.
Siga as instruções no assistente para especificar os servidores e os testes e execute-os. A página Resumo aparecerá após a execução dos testes.
Enquanto ainda estiver na página Resumo , selecione Exibir Relatório para exibir os resultados do teste.
Para exibir os resultados dos testes depois de fechar o assistente, veja
%SystemRoot%\Cluster\Reports\Validation Report date and time.htmlonde%SystemRoot%está a pasta na qual o sistema operacional está instalado (por exemplo,C:\Windows).Para exibir artigos de ajuda que ajudam você a interpretar os resultados, selecione Mais sobre testes de validação de cluster.
Para visualizar artigos de ajuda sobre validação de cluster após fechar o assistente, no snap-in Cluster de Failover, selecione Ajuda, selecione Tópicos de Ajuda, selecione a guia Conteúdo expanda o conteúdo da ajuda do cluster de failover e selecione Validando uma Configuração de Cluster de Failover. Após a conclusão do assistente de validação, o Relatório de Resumo exibirá os resultados. Todos os testes devem ser aprovados com uma marca de verificação verde ou, em alguns casos, com um triângulo amarelo (aviso). Ao procurar áreas de problema (Xs vermelhos ou pontos de interrogação amarelos), na parte do relatório que resume os resultados do teste, selecione um teste individual para examinar os detalhes. Quaisquer problemas com marca de X vermelho precisam ser corrigidos antes de proceder à solução de problemas no SQL Server.
Instalar atualizações
A instalação de atualizações é uma parte importante para evitar problemas com seu sistema. Links úteis:
- Hotfixes e atualizações recomendados para clusters de failover com base no Windows Server 2012 R2
- Hotfixes e atualizações recomendados para clusters de failover com base no Windows Server 2012
- Hotfixes e atualizações recomendados para clusters de failover com base no Windows Server 2008 R2
- Hotfixes e atualizações recomendados para clusters de failover baseados no Windows Server 2008
Recuperar de falha de cluster de failover
Normalmente, uma falha no cluster de failover resulta de uma destas duas causas:
Falha de hardware em um nó de um cluster que tem dois nós. Essa falha de hardware pode ter sido causada por uma falha na placa SCSI ou no sistema operacional.
Para se recuperar dela, remova o nó com falha do cluster de failover usando o programa de Instalação do SQL Server , corrija a falha de hardware com o computador offline, coloque-o online novamente e adicione o nó reparado de volta à instância de cluster de failover.
Para obter mais informações, consulte Criar uma nova instância de cluster de failover Always On (Configuração) e Recuperar de falha de instância de cluster de failover.
Falha do sistema operacional. Neste caso, o nó está offline, mas não está irremediavelmente danificado.
Para se recuperar de uma falha do sistema operacional, recupere o nó e teste o failover. Se a instância do SQL Server não fizer failover corretamente, você deverá usar o programa de Instalação do SQL Server para remover o SQL Server do cluster de failover, fazer os reparos necessários, fazer backup do computador e, em seguida, adicionar o nó reparado de volta à instância do cluster de failover.
A recuperação de uma falha do sistema operacional dessa maneira pode ser demorada. Se a falha do sistema operacional puder ser recuperada facilmente, evite usar esta técnica.
Para obter mais informações, consulte Criar uma nova instância de cluster de failover Always On (Configuração) e Recuperar de falha de instância de cluster de failover.
Resolver problemas comuns
A lista a seguir descreve problemas de uso comum e explica como resolvê-los.
Problema: uso incorreto da sintaxe de prompt de comando para instalar o SQL Server
Problema 1: É difícil diagnosticar problemas de instalação ao usar a opção /qn no prompt de comando, pois a opção /qn suprime todas as caixas de diálogo de configuração e alertas de erro. Se a opção /qn for especificada, todas as mensagens de instalação, incluindo mensagens de erro, serão gravadas nos arquivos de log de Instalação. Para obter mais informações sobre arquivos de log, consulte Exibir e ler arquivos de log de Instalação do SQL Server.
Resolução 1: use a opção /qb em vez da opção /qn . Se você usar a opção /qb , a interface do usuário básica em cada etapa será exibida, incluindo mensagens de erro.
Problema: o SQL Server não pode se conectar à rede depois de migrar para outro nó
Problema 1: as contas de serviço do SQL Server não conseguem fazer contato com um controlador de domínio.
Resolução 1: verifique nos logs de eventos se existem sinais de problemas de rede, como falhas de adaptador ou problemas de DNS. Verifique se você consegue executar ping no controlador de domínio.
Problema 2: As senhas da conta de serviço do SQL Server não são idênticas em todos os nós de cluster ou o nó não reinicia um serviço do SQL Server que migrou de um nó com falha.
Resolução 2: altere as senhas das contas de serviço do SQL Server usando o SQL Server Configuration Manager. Se você não fizer isso e alterar as senhas da conta de serviço do SQL Server em um nó, também deverá alterar as senhas em todos os outros nós. SQL Server Configuration Manager faz isso automaticamente.
Problema: o SQL Server não pode acessar os discos de cluster
Problema 1: o firmware ou os drivers não estão atualizados em todos os nós.
Resolução 1: Verifique se todos os nós estão usando as versões corretas de firmware e a mesma versão de driver.
Problema 2: um nó não consegue recuperar discos de cluster que foram migrados de um nó com falha em um disco de cluster compartilhado com uma letra de unidade diferente.
Resolução 2: as letras de unidade de disco dos discos de cluster devem ser iguais em ambos os servidores. Se não estiverem, examine a instalação original do sistema operacional e do MSCS (Serviço de Cluster da Microsoft).
Problema: a falha de um serviço do SQL Server provoca failover
Resolução: para impedir que a falha de serviços específicos cause o failover do grupo do SQL Server , configure esses serviços usando o Administrador de Cluster do Windows, da seguinte forma:
- Desmarque a caixa de seleção Afetar o Grupo na guia Avançado da caixa de diálogo Propriedades de Texto Completo . Porém, se o SQL Server gerar um failover, o serviço de pesquisa de texto completo será reiniciado.
Problema: o SQL Server não é iniciado automaticamente
Resolução: Use o Administrador de Clusteres do MSCS para iniciar automaticamente um cluster de failover. O serviço SQL Server deve ser definido para ser iniciado manualmente; o Administrador de Cluster deve ser configurado no MSCS para iniciar o serviço SQL Server . Para saber mais, confira Gerenciando serviços.
Problema: o Nome da Rede está offline e você não pode se conectar ao SQL Server usando TCP/IP
Problema 1: o DNS falha quando o recurso de cluster está configurado para exigir DNS.
Resolução 1: corrija os problemas de DNS.
Problema 2: há um nome duplicado na rede.
Resolução 2: Use nbtstat para localizar o nome duplicado e corrigir o problema.
Problema 3: O SQL Server não está se conectando usando pipes nomeados.
Solução 3: Para se conectar usando Named Pipes, crie um alias usando o SQL Server Configuration Manager para acessar o computador correto. Por exemplo, se você tiver um cluster com dois nós (Nó A e Nó B) e uma instância do cluster de failover (Virtsql) com uma instância padrão, poderá se conectar ao servidor que está com o recurso de Nome de Rede offline seguindo estas etapas:
Determine em qual nó o grupo que contém a instância do SQL Server está sendo executado usando o Administrador de Cluster. Para este exemplo, é o Nó A.
Inicie o serviço SQL Server nesse computador usando net start. Para saber mais sobre como usar net start, confira Iniciando o SQL Server manualmente.
Inicie o SQL Server SQL Server Configuration Manager no Nó A. Veja o nome do pipe em que o servidor está escutando. Deve ser semelhante a
\\.\$$\VIRTSQL\pipe\sql\query.No computador cliente, inicie o SQL Server Configuration Manager.
Crie um alias
SQLTEST1para se conectar por meio de Named Pipes a este nome de pipe. Para fazer isso, digite Node A como o nome do servidor e edite o nome do pipe para\\.\pipe\$$\VIRTSQL\sql\query.Conecte-se a essa instância usando o alias
SQLTEST1como o nome do servidor.
Problema: a instalação do SQL Server falha em um cluster com o erro 11001
Problema: Uma chave órfã no Registro em HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\Cluster.
Resolução: certifique-se de que o hive do registro MSSQL.X não esteja em uso e, em seguida, exclua a chave do cluster.
Problema: erro de instalação do cluster: "O instalador não tem privilégios suficientes para acessar este diretório: <drive>\Microsoft SQL Server. A instalação não pode continuar. Efetue logon como administrador ou contate o administrador do sistema"
Questão: Esse erro é causado por uma unidade compartilhada SCSI que não é particionada corretamente.
Resolução: Recrie uma única partição no disco compartilhado usando as seguintes etapas:
- Exclua o recurso de disco do cluster.
- Exclua todas as partições do disco.
- Verifique nas propriedades do disco se o disco é um disco básico.
- Crie uma partição no disco compartilhado, formate o disco e atribua a ele uma letra de unidade.
- Adicione o disco ao cluster usando o Administrador de Cluster (cluadmin).
- Execute a instalação do SQL Server.
Problema: aplicativos não inscrevem recursos do SQL Server em uma transação distribuída
Questão: Como o Ms DTC (Coordenador de Transações Distribuídas da Microsoft) não está completamente configurado no Windows, os aplicativos podem falhar ao inscrever recursos do SQL Server em uma transação distribuída. Esse problema pode afetar servidores vinculados, consultas distribuídas e procedimentos armazenados remotos que usam transações distribuídas. Para obter mais informações sobre como configurar o MS DTC, consulte Antes de instalar o Clustering de Failover.
Resolução: para evitar problemas desse tipo, você deve habilitar totalmente os serviços MS DTC nos servidores em que o SQL Server está instalado e o MS DTC está configurado.
Para habilitar completamente o MS DTC, use as seguintes etapas:
No Painel de Controle, abra Ferramentas Administrativase Gerenciamento do Computador.
No painel esquerdo do Gerenciamento de Computadores, expanda Serviços e Aplicativos e selecione Serviços.
No painel direito do Gerenciamento do Computador, clique com o botão direito do mouse em Coordenador de Transações Distribuídase selecione Propriedades.
Na janela Coordenador de Transações Distribuídas , selecione a guia Geral e, em seguida, selecione Parar para interromper o serviço.
Na janela Coordenador de Transações Distribuídas , selecione a guia Logon e defina a conta
NT AUTHORITY\NetworkServicede logon.Selecione Aplicar e OK para fechar a janela Coordenador de Transações Distribuídas . Feche a janela Gerenciamento do Computador . Feche a janela Ferramentas Administrativas .
Problema: o SQL Server Agent não consegue se conectar a uma instância de cluster de failover de várias sub-redes em uma porta personalizada
Problema: O SQL Server Agent não consegue se conectar ao Mecanismo de Banco de Dados local quando todas as seguintes condições são verdadeiras:
- O SQL Server é instalado como uma instância de cluster de failover em várias sub-redes.
- A instância do cluster de failover é uma instância padrão.
- O Mecanismo de Banco de Dados escuta em uma porta TCP fixa diferente da 1433 padrão.
- O SQL Server Agent se conecta à instância local durante a inicialização.
Para uma instância de cluster de failover com várias sub-redes, a conexão inicial do SQL Server Agent usa MultiSubnetFailover=Yes. Essa configuração faz com que o cliente use TCP. A conexão não recorre à memória compartilhada nem a pipes nomeados. Quando o alvo está (local) e nenhuma porta é especificada, a conexão tenta a porta TCP 1433. A conexão falha se o Mecanismo de Banco de Dados não estiver ouvindo nessa porta.
Você pode ver uma conexão semelhante à seguinte em um rastreamento ODBC:
DRIVER=ODBC Driver 17 for SQL Server;SERVER=(local);APP=SQLAgent - Initial Boot Probe;DATABASE=master;MultiSubnetFailover=YES;
Resolução: Crie um alias TCP que direcione a conexão do SQL Server Agent para o nome da rede virtual e a porta TCP configurada da instância do cluster de failover. Configure o alias em cada nó que possa hospedar a instância do cluster de failover.
Passo 1: Confirme a porta TCP configurada
- No nó ativo, abra o SQL Server Configuration Manager.
- Expanda a Configuração de Rede do SQL Server e depois selecione Protocolos para MSSQLSERVER.
- Abra TCP/IP e então selecione a aba Endereços IP .
- Se Listen All estiver configurado para Sim, note o valor da porta TCP em IPAll.
- Se o Listen All estiver definido como Não, note o valor da porta TCP para cada endereço IP habilitado usado pela instância do cluster de failover.
- Confirme que o registro de erros do SQL Server mostra que o Mecanismo de Banco de Dados está ouvindo na porta esperada.
Para obter mais informações, consulte Configurar o SQL Server para escutar em uma porta TCP específica.
Passo 2: Crie o alias TCP em cada nó do cluster
Complete estes passos em cada nó que possa hospedar a instância do cluster de failover:
- Abra a ferramenta de configuração de alias cliente do SQL Server que se aplica à versão instalada do SQL Server.
- Crie um novo pseudônimo.
- Em Nome do Alias, digite um nome exclusivo para a conexão local do SQL Server Agent. Use o mesmo nome de pseudónimo em todos os nós.
- Selecione TCP/IP como protocolo.
- No Servidor, insira o nome da rede virtual da instância do cluster de failover. Não insira o nome físico do nó.
- Na Porta Nº, insira a porta TCP fixa identificada na etapa 1.
- Guarde o pseudônimo.
Para instruções detalhadas e requisitos de versão, veja Criar ou excluir um alias de servidor para uso por um cliente.
Importante
Um alias SQL Server é uma configuração de cliente. Crie um alias idêntico em cada nó que possa possuir a instância do cluster de failover. Caso contrário, o SQL Server Agent pode falhar depois que a instância se move para um nó onde o alias não está configurado.
Passo 3: Configure o SQL Server Agent para usar o alias
- No SQL Server Management Studio, conecte-se à instância do cluster de failover.
- No Pesquisador de Objetos, expanda a instância.
- Clique com o botão direito no SQL Server Agent e depois selecione Propriedades.
- Em Selecionar uma página, selecione Conexão.
- No servidor host local Alias, insira o nome do alias criado na etapa 2.
- Selecione OK.
- Reinicie o SQL Server Agent.
Para mais informações, veja Definir um alias SQL Server para o serviço SQL Server Agent.
Passo 4: Validar a configuração
- Confirme que o SQL Server Agent iniciou com sucesso.
- Revise o log do SQL Server Agent e confirme que o Agent está conectado à instância local pretendida do Mecanismo de Banco de Dados.
- Execute um job simples do SQL Server Agent para confirmar que os jobs podem se conectar à instância.
- Em um momento em que isso não interrompesse as atividades normais do negócio, mova a instância do cluster de failover para outro possível nó proprietário.
- Confirme que o SQL Server Agent é iniciado e que o trabalho de teste é concluído com êxito nesse nó.
- Repita o teste para cada nó proprietário possível.
Use procedimentos armazenados estendidos e objetos COM
Quando você usa procedimentos armazenados estendidos com uma configuração de clustering de failover, todos os procedimentos armazenados estendidos devem ser instalados em um disco de cluster dependente do SQL Server. Isso garante que, quando um nó executar failover, os procedimentos armazenados estendidos ainda poderão ser usados.
Se os procedimentos armazenados estendidos usam componentes COM, o administrador deve registrar esses componentes em cada nó do cluster. As informações para carregar e executar componentes COM devem estar no Registro do nó ativo para que os componentes sejam criados. Caso contrário, as informações permanecerão no Registro do computador em que os componentes COM foram registrados primeiro.