Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
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