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:
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:
- A primeira parte, em verde, refere-se ao número do processo (PID) no Windows;
- A segunda parte, em amarelo, é o número da thread (TID) aberta pelo processo;
- A terceira parte, em roxo, é o timestamp da operação, sempre em GMT;
- A quarta e a última partes, em vermelho, é a mensagem referente ao erro da operação, neste caso Error 5;
- A quinta parte, em cinza, refere-se ao componente onde ocorreu a falha, neste caso um Resource [RS];
- 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:
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.
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:
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://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 PinheiroAnonymous
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