Analisando Cluster Log

Olá, algumas semanas atrás minha colega Renata Festa e eu fomos acionados para trabalharmos em um caso bem interessante que envolvia um Cluster Windows 2008 com Analysis Services 2008 e SQL Server 2008.

Pois bem, a ferramenta de monitoração do cliente gerou alguns alarmes acusando “erros e warnings” no Cluster Log. O primeiro passo a partir daí foi gerarmos uma saída do Cluster Log em formato legível para analisarmos.

Para tal fomos ao prompt de comando cmd.exe com privilégios elevados “run as administrator” e digitamos o comando a seguir para gerarmos o Cluster Log dos nós:

cluster.exe log /gen /copy:C:\Temp\ClusterLog

Para mais informações sobre Cluster Log no Windows 2008, consulte:

https://blogs.technet.com/b/askcore/archive/2010/04/13/understanding-the-cluster-debug-log-in-2008.aspx

Após gerarmos o cluster log dos nós, fomos ao diretório C:\Temp\ClusterLog - conforme solicitado - e editamos os arquivos, usando o notepad ou wordpad.

Fomos até o fim do arquivo para identificar o último evento e procuramos pela string “ERR” ou “WARN”.

Na primeira parte deste artigo vou discutir como interpretar o Cluster Log de forma amigável. Vejamos a mensagem abaixo:

00004728.000025b8::2011/06/18-14:24:12.026 ERR [RES] Physical Disk <Databases\User\Log\Disk01(CORP01)>: VerifyFS: Failed to open file \\?\GLOBALROOT\Device\Harddisk17\Partition1\DBLOG.LDF Error: 5.

Pois bem, vamos discutir de maneira segregada cada item que está colorido na mensagem acima:

  1. A primeira parte, em verde, refere-se ao número do processo (PID) no Windows;
  2. A segunda parte, em amarelo, é o número da thread (TID) aberta pelo processo;
  3. A terceira parte, em roxo, é o timestamp da operação, sempre em GMT;
  4. A quarta e a última partes, em vermelho, é a mensagem referente ao erro da operação, neste caso Error 5;
  5. A quinta parte, em cinza, refere-se ao componente onde ocorreu a falha, neste caso um Resource [RS];
  6. A sexta parte, em azul, é a operação em que ocorreu este erro, para este caso específico foi VerifyFS (Verify File System);

Muito bem, tendo estes itens esclarecidos vamos agora interpretar esse tal Error 5; para algumas pessoas pode parecer simples, pois realmente é para este caso. Porém, para outras, sem a interpretação acima pode ser uma “sopa de letrinhas”.

Vamos abrir um prompt de comando: cmd.exe

Digite: net helpmsg 5 – conforme exemplo:

image

Agora que descobrimos o significado do erro falta descobrirmos o por quê deste problema ter ocorrido e, obviamente, confirmarmos se realmente é este o problema. Para isso vou utilizar a ferramenta Process Explorer da sysinternals.

Com o process explorer (usando o módulo file manager) conseguimos confirmar que o Cluster tenta acessar esses arquivos, porém recebe acesso negado. A figura abaixo é apenas ilustrativa de como utilizar o process explorer e não se refere ao erro citado.

image

Agora, com essa informação confirmada, podemos tomar uma ação; entretanto ainda não respondemos o por quê disso ter ocorrido tendo em vista que anteriormente o cluster estava funcionando normalmente. Para responder tal questão recorremos ao console do SQL Server 2008 e, com a seguinte query, verificamos os arquivos de bancos de dados existentes:

image

Confirmamos que não existiam arquivos criados com este nome para nenhum dos bancos de dados da instância e infelizmente o ERRORLOG não registra operação de “detach”; então fomos verificar com a equipe de DBA’s se haviam feito um “detach” de algum banco de dados e a resposta foi “SIM”.

A partir deste momento identificamos a causa e a solução para o problema:

Causa

Ao efetuarmos um “detach” do banco de dados pelo SSMS as permissões para o arquivo foram "reiniciadas”, deixando apenas o usuário do DBA responsável pela operação com acesso a estes arquivos de dados e log.

Solução

Reatribuir as permissões para permitir acesso aos arquivos pelo Cluster e, consequentemente, seus componentes.

Links úteis

Para maiores informações sobre como analisar Cluster Log e identificar seus componentes seguem alguns artigos e blogs disponíveis:

https://msdn.microsoft.com/en-us/library/aa949696(BTS.10).aspx

https://msdn.microsoft.com/en-us/library/aa949696(BTS.10).aspx

https://blogs.technet.com/b/askcore/archive/2009/11/23/resource-hosting-subsystem-rhs-in-windows-server-2008-failover-clusters.aspx

https://technet.microsoft.com/en-us/library/cc962184.aspx

 

Espero que este post possa ser útil a vocês.

Obrigado e até a próxima!

Rodrigo Souza

Comments

  • Anonymous
    July 21, 2011
    Olá grande Rodrigo... Embora eu nunca tenha vivenciado este problema, entendo que estamos diante de um bug, certo? Ou esta "remoção" de permissões é algo esperado! Algum BK referenciando este problema? abs Nilton Pinheiro

  • Anonymous
    July 26, 2011
    Opa Nilton, tudo bem? Não é BUG é um comportamento esperado ao fazer um "detach", o SQL revoga todas as permissões e coloca acesso apenas para o usuário que fez o procedimento. Não vefiquei nenhum KB, mas vou procurar se encontrar coloco aqui para todos. Obrigado pelo comentário! Abraços, Rodrigo Souza