Então você DBA deve realizar a importância do papel que desempenha na empresa e em última instância deve garantir que os dados não serão perdidos, e que estarão íntegros e consistentes. Se ainda não se deu conta da sua importância, pense novamente.
O Cenário
Depois deste pequeno preâmbulo, vamos ao acontecido. Segunda-feira cedo, meu telefone toca e um cliente menciona estar com um problema em um processo que criamos, impedindo que este continue a executar.
Neste ambiente nós trabalhamos com o snapshot de um banco de dados específico, que faz parte do funcionamento do procedimento de importação diário de uma massa considerável de dados, e é a maneira pela qual o ambiente garante a consistência dos dados nesta base. Um snapshot é criado, o arquivo é importado (podendo tocar inúmeras tabelas) e caso algum problema aconteça, podemos reverter o banco de dados à sua imagem original e trabalhar no problema, garantindo que não haverá meio arquivo importado e nem que teremos transações monstras com milhares de operações. Chamo este padrão do SSIS de consistência extrema e apresentei-o no evento em 2009, o virtual 24hs PASS LATAM.
O Problema
Analisando o estado do ambiente podemos verificar que se tratava de uma corrupção do database snapshot, seguem alguns registros. Os nomes foram trocados por XXXXX para garantir o sigilo do cliente.
Log do SQL Server:
| 1/29/2012 6:30:04 AM | Starting up database 'XXXXX_20120129063004_XXXXX'. |
| 1/29/2012 6:30:05 AM | E:\Data\XXXXX_20120129063004_XXXXXXX.NDF: Operating system error 112(There is not enough space on the disk.) encountered. |
| 1/29/2012 6:30:05 AM | Database snapshot 'XXXXX_20120129063004_XXXXX' has failed an IO operation and is marked suspect. It must be dropped and recreated. |
Seguindo o procedimento normal de importação automático, foi criado um snapshot para a importação do arquivo XXXXX, a importação dos dados começou normalmente e um segundo depois tivemos um problema relacionado ao subsistema de disco. Como não havia mais espaço disponível no disco, a operação de I/O que guarda os dados no snapshot não pode acontecer e o snapshot entrou em estado suspect.
Foi possível verificar que o arquivo de snapshot chegou a 6,71 MB, então efetivamente recebeu páginas que foram alteradas no banco de dados de origem. Consultando a tabela afetada notamos que alguns registros do arquivo haviam sido importados para o banco de dados, colocando o banco de dados em um estado inconsistente para o negócio.
Porém a partir desse momento o procedimento de recuperação automática do processo de importação falhou, pois não foi possível reverter o banco de dados para o estado original, dado que o snapshot estava corrompido. Abaixo alguns exemplos das tentativas de utilizar o snapshot, com a respectiva mensagem de erro:
USE 'XXXXX_20120129063004_XXXXX
GO
Msg 926, Level 14, State 1, Line 1
Database 'XXXXX_20120129063004_XXXXX ' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.
RESTORE DATABASE XXXXX
FROM DATABASE_SNAPSHOT = 'XXXXX_20120129063004_XXXXX'
Msg 3137, Level 16, State 1, Line 1
Database cannot be reverted. Either the primary or the snapshot names are improperly specified, all other snapshots have not been dropped, or there are missing files.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
Uma curiosidade da interface do SSMS é que ela não indica que um database snapshot está marcado como suspect, da mesma forma que é feito para outros bancos de dados, então se você olhar pelo object explorer aparentemente está tudo ok. Consultando a sys.databases vemos o status 4, SUSPECT.
Solução do problema
Diferente de outros bancos de dados, as medidas de recuperação não podem ser aplicadas para o database snapshot.
Consultando a documentação do produto podemos ver claramente o que deve ser feito neste caso: “Database snapshots consume disk space. If a database snapshot runs out of disk space, it is marked as suspect and must be dropped. (The source database, however, is not affected; actions on it continue normally.)”. Para confirmar que efetivamente não existe possibilidade, buscamos outra referência (que não sabe quase nada de DR e teste de consistência em um banco de dados) sobre o problema: http://www.sqlmag.com/blog/sql-server-questions-answered-28/sql-server/why-can-a-database-snapshot-run-out-of-space-137145.
Como não podemos utilizar o snapshot, foi necessária uma intervenção manual. Apagamos o snapshot que estava corrompido e foram removidos do banco de dados todos os registros relativos a este arquivo. Depois disso o arquivo foi reprocessado com sucesso, bem como todos os outros arquivos que estavam parados por conta do snapshot que estava impedindo a importação automática de ocorrer.
Conclusão
Felizmente no nosso caso o problema aconteceu com um arquivo simples e a intervenção manual foi bem tranquila e em pouco tempo já tínhamos colocado o banco em estado consistente, com os arquivos importado, e pronto para ser utilizado por outras aplicações.
Porém suponhamos que o problema tivesse acontecido em outro arquivo mais complexo ou em um processamento pesado que devesse ter acontecido durante a janela da madrugada, provavelmente teríamos impactado o ambiente, que não teria os dados disponíveis dentro do SLA do serviço, ou pior, que a intervenção manual não fosse possível para colocar a base em um estado consistente, exigindo um restore... Nada bom.
Sinceramente, não acho que este post tenha uma grande relevância técnica. Mostra que em casos de falta de espaço em disco um snapshot pode se corromper facilmente e o banco de origem continua funcionando normalmente, ignorando o snapshot que passa a ser um arquivo inútil. O que eu gostaria de ressaltar são alguns pontos para reflexão...
A culpa do problema foi do DBA?
De bate-pronto muitos poderiam responder que sim, pois ele deixou acabar o espaço em disco. Mas acho que não podemos ser tão simplistas...
E se eu disser que durante o capacity planning para este servidor fui eu quem escreveu um documento recomendando o dobro de espaço que nos foi disponibilizado? E como fazemos com os procedimentos de manutenção? Deixamos rebuild de lado? Ou fazemos um rebuild de índice a índice, seguindo de um shrink após cada rebuild? (QUE IDEIA FANTÁSTICA! Potencialmente levando a uma fragmentação lógica do índice que acabou de ser reconstruído).
O DBA neste caso tem que fazer malabarismos com o ambiente que lhe foi entregue, tentando gerenciar a escassez dos recursos e, claro, será cobrado se o ambiente ficar fora do ar ou houver perda de dados (e têm que ser cobrado por isso!). Simples? Nem um pouco, é uma baita responsabilidade que não sei se todos os DBAs percebem. Então você DBA têm que continuar aprimorando seus conhecimentos, seu ambiente, e tratando dele com muito carinho e cuidado. Se esse cenário fosse uma extrema exceção à regra, ótimo, o problema é que parece ser muito comum. No fim acho que muitos DBAs têm que receber bem, quem sabe, muito bem...
Termino com uma pérola que ouvi de um gerente de infraestrutura. “Senhor C3PO, precisamos trabalhar com alta disponibilidade dado que nosso ambiente é crítico”, em resposta “Fica tranquilo, a máquina nova é um R2D2 com N processadores XWING, 999999999 de memória e ligado na storage”... Depois de um momento de perplexa reflexão eu gostaria de ir até a sala do gerente e perguntar “Também é feito de adamantium?”.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Nenhum comentário:
Postar um comentário