Um banco de dados corrompido \u00e9 provavelmente um dos piores pesadelos do DBA. Isso resulta em tempo de inatividade, gritos de gerentes e todos os outros tipos de coisas desagrad\u00e1veis<\/p>\n\n\n\n
Neste artigo, vou explicar algumas das coisas que n\u00e3o devem ser feitas em um banco de dados corrompido e, em seguida, examinarei algumas das coisas que devem ser feitas, alguns dos cen\u00e1rios e as corre\u00e7\u00f5es para eles.<\/p>\n\n\n\n
A corrup\u00e7\u00e3o \u00e9 normalmente bastante \u00f3bvia quando algu\u00e9m percorre as p\u00e1ginas danificadas. As consultas falham com erros de alta gravidade. Os backups ou tarefas de reindexa\u00e7\u00e3o falham com erros de alta gravidade. Algumas mensagens que indicam corrup\u00e7\u00e3o em um banco de dados s\u00e3o:<\/p>\n\n\n\n
SQL Server detected a logical consistency-based I\/O error: incorrect checksum (expected: 0xfdff74c9; actual: 0xfdff74cb). It occurred during a read of page (1:69965) in database ID 13 at offset 0x0000002229a000 in file 'D:\\Develop\\Databases\\Broken1.mdf'. Attempt to fetch logical page 1:69965 in database 13 failed. It belongs to allocation unit 72057594049069056 not to 281474980642816. \n<\/pre>\n\n\n\nO principal problema \u00e9 que, se as verifica\u00e7\u00f5es regulares de integridade do banco de dados n\u00e3o estiverem sendo feitas, a corrup\u00e7\u00e3o pode ser detectada horas, dias ou at\u00e9 meses ap\u00f3s ter ocorrido, ponto em que pode ser dif\u00edcil de resolver<\/p>\n\n\n\n
N\u00e3o vou cobrir a situa\u00e7\u00e3o em que o banco de dados est\u00e1 em um estado suspeito. Cobrindo as poss\u00edveis raz\u00f5es pelas quais um banco de dados \u00e9 suspeito, os m\u00e9todos para descobrir porque \u00e9 suspeito e os v\u00e1rios meios de consertar isso s\u00e3o um artigo inteiro em si, se n\u00e3o um livro completo.<\/p>\n\n\n\n
O que fazer quando o banco de dados est\u00e1 corrompido.<\/h2>\n\n\n\n
- N\u00e3o entre em p\u00e2nico<\/li>
- N\u00e3o desanexe o banco de dados<\/li>
- N\u00e3o reinicie o SQL<\/li>
- N\u00e3o execute apenas o reparo.<\/li>
- Execute uma verifica\u00e7\u00e3o de integridade<\/li>
- Depois, fa\u00e7a uma an\u00e1lise da causa raiz<\/li><\/ol>\n\n\n\n
N\u00e3o entre em p\u00e2nico<\/h4>\n\n\n\n
A coisa mais importante ao lidar com corrup\u00e7\u00e3o de banco de dados de qualquer forma \u00e9 n\u00e3o entrar em p\u00e2nico. Quaisquer decis\u00f5es ou a\u00e7\u00f5es tomadas devem ser cuidadosamente pensadas e feitas ap\u00f3s uma considera\u00e7\u00e3o cuidadosa com todos os fatores levados em considera\u00e7\u00e3o. \u00c9 muito f\u00e1cil piorar a situa\u00e7\u00e3o com decis\u00f5es mal pensadas.<\/p>\n\n\n\n
N\u00e3o desanexe o banco de dados<\/h4>\n\n\n\n
Embora seja poss\u00edvel que a mensagem de corrup\u00e7\u00e3o descreva uma condi\u00e7\u00e3o transit\u00f3ria, essa n\u00e3o \u00e9 a situa\u00e7\u00e3o normal. Na grande maioria dos casos, se o SQL detectar corrup\u00e7\u00e3o em um banco de dados, isso significa que realmente existem algumas p\u00e1ginas danificadas no banco de dados. Tentar enganar o SQL para n\u00e3o ver isso, desanexando e reanexando o banco de dados, fazendo backup e restaurando o banco de dados, reiniciando o servi\u00e7o SQL ou reinicializando a m\u00e1quina, n\u00e3o far\u00e1 com que a corrup\u00e7\u00e3o desapare\u00e7a.<\/p>\n\n\n\n
Se houver corrup\u00e7\u00e3o no banco de dados e o SQL detectar essa corrup\u00e7\u00e3o ao anexar o banco de dados, a conex\u00e3o falhar\u00e1. Existem maneiras de hackear o banco de dados de volta para SQL, mas \u00e9 muito melhor simplesmente n\u00e3o desanexar o banco de dados em primeiro lugar<\/p>\n\n\n\n
N\u00e3o reinicie o SQL<\/h4>\n\n\n\n
Semelhante \u00e0 desanexa\u00e7\u00e3o, reiniciar o servi\u00e7o SQL n\u00e3o corrigir\u00e1 a corrup\u00e7\u00e3o se ela estiver presente.<\/p>\n\n\n\n
Tal como acontece com a desanexa\u00e7\u00e3o do banco de dados, reiniciar o servi\u00e7o pode piorar as coisas. Se o SQL Server encontrar danos ao executar a recupera\u00e7\u00e3o de reinicializa\u00e7\u00e3o em um banco de dados, esse banco de dados ser\u00e1 marcado como suspeito, tornando qualquer reparo necess\u00e1rio muito mais dif\u00edcil de realizar.<\/p>\n\n\n\n
N\u00e3o execute apenas o reparo<\/h4>\n\n\n\n
Pode ser tentador apenas executar CheckDB com uma das op\u00e7\u00f5es de reparo (normalmente permite a perda de dados) e acreditar que isso tornar\u00e1 tudo melhor. Em muitos casos, executar o reparo n\u00e3o \u00e9 a corre\u00e7\u00e3o recomendada. N\u00e3o h\u00e1 garantia de corre\u00e7\u00e3o de todos os erros e isso pode resultar em perda de dados inaceit\u00e1vel.<\/p>\n\n\n\n
A repara\u00e7\u00e3o \u00e9, na maioria dos casos, o \u00faltimo recurso para consertar a corrup\u00e7\u00e3o. Deve ser feito apenas quando nenhuma das alternativas \u00e9 poss\u00edvel, n\u00e3o feito como a primeira coisa tentada.<\/p>\n\n\n\n
Execute uma verifica\u00e7\u00e3o de integridade<\/h4>\n\n\n\n
Para decidir sobre um m\u00e9todo de reparar a corrup\u00e7\u00e3o, os detalhes de exatamente o que est\u00e1 danificado devem ser conhecidos. A \u00fanica maneira de obter essas informa\u00e7\u00f5es \u00e9 executar CheckDB com a op\u00e7\u00e3o All_ErrorMsgs (no 2005 SP3, esta \u00e9 uma op\u00e7\u00e3o padr\u00e3o em CheckDB e n\u00e3o precisa ser especificada. Ela precisa ser especificada no SQL 2008). Al\u00e9m disso, a op\u00e7\u00e3o No_Infomsgs remove todas as informa\u00e7\u00f5es sobre o n\u00famero de linhas e o n\u00famero de p\u00e1ginas da tabela, o que \u00e9 desnecess\u00e1rio ao lidar com danos.<\/p>\n\n\n\n
CheckDB pode demorar um pouco em bancos de dados maiores, mas \u00e9 necess\u00e1rio deix\u00e1-lo ser executado at\u00e9 o fim. Uma estrat\u00e9gia de reparo n\u00e3o deve ser considerada sem conhecer todos os problemas no banco de dados<\/p>\n\n\n\n
Causa raiz<\/h4>\n\n\n\n
Uma vez que a corrup\u00e7\u00e3o foi resolvida, o trabalho n\u00e3o acabou. Se a causa raiz da corrup\u00e7\u00e3o n\u00e3o for encontrada, pode acontecer novamente. Normalmente, a principal causa de corrup\u00e7\u00e3o s\u00e3o problemas com o subsistema de E \/ S. Outras causas poss\u00edveis s\u00e3o drivers de filtro com comportamento inadequado (como um antiv\u00edrus), interven\u00e7\u00e3o humana ou um bug no SQL.<\/p>\n\n\n\n
Pr\u00f3ximos passos<\/h2>\n\n\n\n
As etapas para resolver a corrup\u00e7\u00e3o dependem inteiramente dos resultados do CheckDB. Vou passar por alguns dos cen\u00e1rios mais comuns aqui. Este n\u00e3o \u00e9 um documento abrangente de todas as poss\u00edveis corrup\u00e7\u00f5es em um banco de dados. 1<\/sup><\/p>\n\n\n\n
Esta lista est\u00e1 em ordem aproximada de gravidade, do problema menos grave ao mais grave. Cada um tem um exemplo de poss\u00edveis mensagens de erro que indicam esse problema espec\u00edfico. Em geral, o erro mais grave encontrado pelo CheckDB determina os m\u00e9todos dispon\u00edveis para resolver o problema de corrup\u00e7\u00e3o.<\/p>\n\n\n\n
Se algu\u00e9m encontrar um erro que n\u00e3o esteja detalhado aqui, consulte a \u00faltima se\u00e7\u00e3o – Obtendo Ajuda.<\/p>\n\n\n\n
Metadados de espa\u00e7o imprecisos<\/h4>\n\n\n\n
Inaccurate space metadata\n\nMsg 2508, Level 16, State 3, Line 1\nThe In-row data RSVD page count for object \"Broken1\", index ID 0, partition ID 76911687695381, alloc unit ID 76911687695381 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE.\n<\/pre>\n\n\n\nEste erro indica que a p\u00e1gina possui um valor incorreto para o espa\u00e7o reservado. No SQL 2000, era poss\u00edvel que as contagens de linhas e p\u00e1ginas de uma tabela ou \u00edndice estivessem incorretas, at\u00e9 mesmo negativas. CheckDB n\u00e3o pegou isso. No SQL 2005, as contagens devem ser mantidas corretamente e o CheckDB d\u00e1 um aviso quando encontra este cen\u00e1rio<\/p>\n\n\n\n
Este n\u00e3o \u00e9 um problema s\u00e9rio e \u00e9 trivial de corrigir. Como diz a mensagem, execute DBCC UPDATEUSAGE no banco de dados em quest\u00e3o e os avisos desaparecer\u00e3o. Isso \u00e9 comum em bancos de dados atualizados do SQL 2000, pelos motivos mencionados acima, e n\u00e3o deve ocorrer no banco de dados criado no SQL 2005\/2008.<\/p>\n\n\n\n
Msg 8914, Level 16, State 1, Line 1\nIncorrect PFS free space information for page (1:26839) in object ID 181575685, index ID 1, partition ID 293374720802816, alloc unit ID 76911687695381 (type LOB data). Expected value 0_PCT_FULL, actual value 100_PCT_FULL.\n<\/pre>\n\n\n\nEste erro indica que a p\u00e1gina PFS (espa\u00e7o livre da p\u00e1gina) que rastreia a quantidade de p\u00e1ginas inteiras tem valores incorretos. Isso, como o erro acima, n\u00e3o \u00e9 s\u00e9rio. O algoritmo que rastreou isso no SQL 2000 nem sempre foi preciso. Embora seja necess\u00e1rio executar CheckDB com a op\u00e7\u00e3o Repair_Allow_Data_Loss, se este for o \u00fanico erro que existe, ele n\u00e3o excluir\u00e1 nenhum dado.<\/p>\n\n\n\n
Corrup\u00e7\u00e3o apenas nos \u00edndices n\u00e3o clusterizados<\/h4>\n\n\n\n
Se todos os erros que checkDB retorna se referem a \u00edndices com IDs de 2 ou mais, isso indica que toda a corrup\u00e7\u00e3o est\u00e1 dentro dos \u00edndices n\u00e3o agrupados. Como os dados em um \u00edndice n\u00e3o clusterizado s\u00e3o redundantes, essas corrup\u00e7\u00f5es podem ser reparadas sem perda de dados.<\/p>\n\n\n\n
Se todos os erros que o CheckDB detecta estiverem nos \u00edndices n\u00e3o clusterizados, o n\u00edvel de reparo recomendado ser\u00e1 Repair_Rebuild.<\/p>\n\n\n\n
Msg 8941, Level 16, State 1, Line 1\nTable error: Object ID 181575685, index ID 4, page (3:224866). Test (sorted .offset >= PAGEHEADSIZE) failed. Slot 159, offset 0x1 is invalid.\n\nMsg 8942, Level 16, State 1, Line 1\nTable error: Object ID 181575685, index ID 4, page (3:224866). Test (sorted.offset >= max) failed. Slot 0, offset 0x9f overlaps with the prior row.<\/pre>\n\n\n\nEsses s\u00e3o apenas exemplos; existem muitos mais erros poss\u00edveis.<\/p>\n\n\n\n
Nesse caso, a corrup\u00e7\u00e3o pode ser completamente reparada eliminando os \u00edndices n\u00e3o clusterizados danificados e recriando-os. As reconstru\u00e7\u00f5es de \u00edndice online (e algumas das reconstru\u00e7\u00f5es de \u00edndice offline) l\u00eaem o \u00edndice antigo para criar o novo e, portanto, encontrar\u00e1 a corrup\u00e7\u00e3o. Portanto, \u00e9 necess\u00e1rio descartar completamente o \u00edndice antigo e criar um novo.<\/p>\n\n\n\n
Isso \u00e9 principalmente o que CheckDB com a op\u00e7\u00e3o repair_rebuild far\u00e1, entretanto, o banco de dados deve estar no modo de usu\u00e1rio \u00fanico para que o reparo seja feito. Portanto, geralmente \u00e9 melhor reconstruir manualmente os \u00edndices, pois o banco de dados pode permanecer online e em uso enquanto os \u00edndices afetados s\u00e3o recriados.<\/p>\n\n\n\n
Se n\u00e3o houver tempo suficiente dispon\u00edvel para reconstruir o \u00edndice afetado e houver um backup limpo com uma cadeia de log ininterrupta, as p\u00e1ginas danificadas podem ser restauradas do backup.<\/p>\n\n\n\n
Corrup\u00e7\u00e3o nas p\u00e1ginas LOB<\/h4>\n\n\n\n
Corruption in the LOB pages\nMsg 8964, Level 16, State 1, Line 1\nTable error: Object ID 181575685, index ID 1, partition ID 72057594145669120, alloc unit ID 72057594087800832 (type LOB data). The off-row data node at page (1:2444050), slot 0, text ID 901891555328 is not referenced.\n<\/pre>\n\n\n\nIsso indica que h\u00e1 p\u00e1ginas LOB (objeto grande) que n\u00e3o s\u00e3o referenciadas por nenhuma linha de dados. Isso pode acontecer se houver corrup\u00e7\u00e3o do \u00edndice clusterizado ou heap e as p\u00e1ginas danificadas forem desalocadas.<\/p>\n\n\n\n
Se esses forem os \u00fanicos erros retornados pelo CheckDB, executar o reparo com Allow_Data_Loss simplesmente desalocar\u00e1 essas p\u00e1ginas. Como as linhas de dados \u00e0s quais os dados LOB pertencem n\u00e3o existem, isso n\u00e3o resultar\u00e1 em mais perda de dados.<\/p>\n\n\n\n
Erros de pureza de dados<\/h4>\n\n\n\n
Data Purity errors\nMsg 2570, Sev 16, State 3, Line 17\nPage (1:1103587), slot 24 in object ID 34, index ID 1, partition ID 281474978938880, alloc unit ID 281474978938880 (type \"In-row data\"). Column \"modified\" value is out of range for data type \"datetime\". Update column to a legal value.\n<\/pre>\n\n\n\nO erro de pureza dos dados indica que h\u00e1 um valor na coluna que est\u00e1 fora do intervalo aceit\u00e1vel da coluna. Pode ser uma data e hora em que os minutos ap\u00f3s a meia-noite excedem 1440, uma string Unicode onde o n\u00famero de bytes n\u00e3o \u00e9 um m\u00faltiplo de 2, ou um float ou real com um valor de ponto flutuante inv\u00e1lido.<\/p>\n\n\n\n
Esses erros n\u00e3o s\u00e3o verificados por padr\u00e3o em um banco de dados atualizado do SQL 2000 ou inferior. CheckDB deve ser executado com sucesso uma vez, com a op\u00e7\u00e3o DATA_PURITY antes<\/p>\n\n\n\n
CheckDB n\u00e3o vai consertar isso. Ele n\u00e3o sabe quais valores colocar na coluna para substituir os inv\u00e1lidos. A corre\u00e7\u00e3o para isso \u00e9 bastante f\u00e1cil, mas manual. Os valores ruins devem ser atualizados anualmente para algo significativo. O principal desafio \u00e9 encontrar as linhas ruins. Este artigo da KB descreve as etapas em detalhes. http:\/\/support.microsoft.com\/kb\/923247<\/a><\/p>\n\n\n\n
Corrup\u00e7\u00e3o no \u00edndice clusterizado ou heap<\/h4>\n\n\n\n
Se houver corrup\u00e7\u00e3o nas p\u00e1ginas folha do \u00edndice clusterizado ou no heap, isso significa que os dados foram perdidos. As p\u00e1ginas de folha do \u00edndice clusterizado s\u00e3o as p\u00e1ginas de dados reais da tabela e, portanto, essa n\u00e3o \u00e9 uma informa\u00e7\u00e3o redundante.<\/p>\n\n\n\n
Se algum dos erros detectados pelo CheckDB estiver nas p\u00e1ginas de folha do \u00edndice clusterizado, o n\u00edvel de reparo recomendado ser\u00e1 Repair_Allow_Data_Loss<\/p>\n\n\n\n
Server: Msg 8976, Level 16, State 1, Line 2\nTable error: Object ID 181575685, index ID 1, partition ID 76911687695381, alloc unit ID 76911687695381 (type In-row data). Page (1:22417) was not seen in the scan although its parent (1:479) and previous (1:715544) refer to it. Server: Msg 8939, Level 16, State 1, Line 2\nTable error: Object ID 181575685, index ID 0, page (1:168576). Test (m_freeData >= PAGEHEADSIZE && m_freeData <= (UINT)PAGESIZE - m_slotCnt * sizeof (Slot)) failed. Values are 44 and 8028.<\/a>\n<\/pre>\n\n\n\nEsses s\u00e3o apenas exemplos; existem muitos mais erros poss\u00edveis. O que se deve notar \u00e9 que o ID do \u00edndice mencionado \u00e9 0 ou 1. Se algum dos erros retornados pelo CheckDB tiver um ID do \u00edndice 0 ou 1, significa que h\u00e1 danos \u00e0s tabelas base.<\/p>\n\n\n\n
Esse tipo de dano \u00e9 repar\u00e1vel, mas repar\u00e1-lo envolve o descarte de linhas ou p\u00e1ginas inteiras. Se CheckDB excluir dados para corrigir a corrup\u00e7\u00e3o, ele n\u00e3o verificar\u00e1 as chaves estrangeiras e n\u00e3o disparar\u00e1 gatilhos. As linhas ou p\u00e1ginas ser\u00e3o simplesmente desalocadas. Isso pode resultar em viola\u00e7\u00f5es de integridade de dados (registros filho sem um pai) e pode resultar em inconsist\u00eancias l\u00f3gicas do banco de dados (linhas de \u00edndice n\u00e3o clusterizadas ou p\u00e1ginas LOB que n\u00e3o fazem mais refer\u00eancia a uma linha). Como tal, o reparo n\u00e3o \u00e9 a rota recomendada.<\/p>\n\n\n\n
Se houver um backup limpo, a restaura\u00e7\u00e3o do backup geralmente \u00e9 o m\u00e9todo recomendado para corrigir esses erros. Se o banco de dados estiver em recupera\u00e7\u00e3o total e houver uma cadeia de log ininterrupta desde o backup do banco de dados limpo, ent\u00e3o \u00e9 poss\u00edvel fazer backup do final do log de transa\u00e7\u00f5es e restaurar todo o banco de dados ou apenas as p\u00e1ginas danificadas, sem perda de dados em todos.<\/p>\n\n\n\n
Se n\u00e3o houver um backup limpo, \u00e9 necess\u00e1rio executar CheckDB com a op\u00e7\u00e3o Repair_allow_data_loss. Isso requer que o banco de dados esteja no modo de usu\u00e1rio \u00fanico durante o reparo.<\/p>\n\n\n\n