Fala Pessoal,<\/p>\n
Ontem, ao chegar em meu ambiente de trabalho, verifiquei que minha rotina de CHECKDB de um dos meus servidores havia falhado.<\/p>\n
JOB RUN:\u00a0\u00a0 \u00a0‘DBA – CHECKDB’ was run on 15\/3\/2011 at 21:20:00
\nDURATION:\u00a0\u00a0 \u00a01 hours, 29 minutes, 17 seconds
\nSTATUS: \u00a0\u00a0 \u00a0Failed<\/p>\n
At\u00e9 a\u00ed estava tudo bem pois ela j\u00e1 havia falhado anteriormente por falta de recursos dispon\u00edveis para execut\u00e1-la. Entretanto, ao verificar minha planilha com o checklist di\u00e1rio do DBA<\/a>, na aba CHECKDB, encontrei a seguinte mensagem:<\/p>\n DBCC CHECKDB (Nome_Database) WITH no_infomsgs executed by Nome_Usuario found 2 errors and repaired 0 errors<\/strong>. Elapsed time: 0 hours 20 minutes 20 seconds.<\/p>\n Agora a casa tinha ca\u00eddo.<\/p>\n Ao abrir o log do SQL Server, verifiquei a seguinte mensagem nas execu\u00e7\u00f5es do comando DBCC CHECKDB dessa database:<\/p>\n Duvido que essa frase no log do SQL Server n\u00e3o te da um frio na barriga tamb\u00e9m: *DBCC database corruption<\/strong><\/p>\n Olhando o hist\u00f3rico do Job encontrei o seguinte resultado:<\/p>\n Page (1:88888888)<\/strong>, slot 4<\/strong> in object ID 77777777, index ID 1, partition ID 99999999999999999999, Page (1:88888888)<\/strong>, slot 4<\/strong> in object ID 77777777, index ID 1, partition ID 99999999999999999999, CHECKDB found 0 allocation errors and 2 consistency errors in table ‘Nome_Tabela<\/strong>‘ (object ID 99999999). [SQLSTATE 01000] (Error 8990) Recorri ao google e rapidamente encontrei esse KB da microsoft<\/a> que utilizei como refer\u00eancia para resolver o problema.<\/p>\n Olhando em outros sites, verifiquei que esse erro era bem comum de ser encontrado em migra\u00e7\u00f5es do SQL Server 2000 para o SQL Server 2005 ou superior, entretanto, esse n\u00e3o era o meu caso pois\u00a0 essa base j\u00e1 estava criada no SQL Server 2005 a anos e o dbcc checkdb \u00e9 executado diariamente nela.<\/p>\n Como a database que deu problema \u00e9 restaurada diariamente em um servidor de teste. Verifiquei que o mesmo erro estava acontecendo na database de teste e fui encontrar uma solu\u00e7\u00e3o.<\/p>\n Pelas mensagens de erro, o problema estava na mesma p\u00e1gina de dados de um mesmo objeto (os n\u00fameros do post s\u00e3o fict\u00edcios): Seguindo o KB e executando o comando abaixo para verificar os registros da p\u00e1gina com problema:<\/p>\n DBCC TRACEON ( 3604 ) Tive o retorno de um grande result set.<\/p>\n Pesquisei no resultado pelo nome das duas colunas retornadas no erro e encontrei um n\u00famero absurdo para uma destas colunas exatamente no slot 4, que foi retornado nos 2 erros.<\/p>\n Slot 4<\/strong> Column 33 Offset 0x10c Length 9<\/p>\n Nome_COluna1 = -1634.41<\/p>\n Slot 4<\/strong> Column 57 Offset 0x1a7 Length 9<\/p>\n Nome_Coluna2 = 89998897014397766.68<\/strong><\/p>\n Sendo que a coluna 2 era do tipo numeric(15,2).<\/p>\n Encontrado o valor com problema, fui tentar fazer um select para encontrar toda a linha:<\/p>\n Essa query retornava um erro: Todavia, essa era executada com sucesso: Como o count(*) retornou 1 registro, rodei um update para descobrir todo o conte\u00fado da linha que estava com problema: Com a query abaixo, verifiquei que os dois valores do slot 4 (-1634.41 e 89998897014397766.68) <\/strong>pertenciam a mesma linha. Como j\u00e1 tinha acertado o valor absurdo da coluna 2, executei o comando abaixo para testar novamente a consist\u00eancia da tabela: O comando continuou retornando um erro, entretanto, agora apenas para a coluna 1:<\/p>\n Msg 2570, Level 16, State 3, Line 1 Fiz um update do valor da coluna1 para o mesmo valor:<\/p>\n update Tabela Executei o comando abaixo para testar novamente e o mesmo n\u00e3o retornou nenhum erro. Pronto, havia conseguido resolver o problema de consist\u00eancia com a perda de apenas uma coluna de uma linha.<\/p>\n No meu caso real, o registro com problema foi importado de outra fonte durante a noite, ent\u00e3o foi poss\u00edvel exclu\u00ed-lo e import\u00e1-lo novamente.<\/p>\n Caso eu n\u00e3o tivesse essa sorte, como eu descobri o problema em um dia, era s\u00f3 voltar o \u00faltimo backup limpo dessa database e conferir o valor das colunas com problema.<\/p>\n Caso voc\u00ea n\u00e3o tivesse um backup limpo, com a solu\u00e7\u00e3o que realizamos nesse post perder\u00edamos o valor da Coluna2.<\/p>\n N\u00e3o sei com certeza o motivo da gera\u00e7\u00e3o do problema, pois o registro com problema foi inserido dessa forma: Se fosse retornado um valor absurdo no select, seria gerado um erro no insert, ent\u00e3o acredito que o motivo da corrup\u00e7\u00e3o dessa p\u00e1gina de dados foi uma parada que aconteceu no servi\u00e7o do SQL Server no dia anterior por causa de uma press\u00e3o de mem\u00f3ria no servidor.<\/p>\n Conforme j\u00e1 havia escrito em um artigo para a revista Codificando.NET Quanto tempo levaria para descobrir uma database corrompida?<\/a>, \u00e9 extremamente importante possuir uma rotina de CHECKDB. Nesse caso os registros corrompidos foram poucos, mas poderiam ser muito mais. Se eu n\u00e3o tivesse essa rotina, o problema s\u00f3 seria descoberto quando algum usu\u00e1rio utiliz\u00e1-se o valor dessa coluna, o que poderia demorar dias. Com isso, todos os meus backups estariam corrompidos.<\/p>\n Voc\u00ea ainda pode achar que esse problema \u00e9 raro e se n\u00e3o aconteceu at\u00e9 hoje, nunca vai acontecer com suas databases. Eu criei minha rotina de CHECKDB a mais de um ano e nunca havia retornado nenhum erro na mesma, entretanto, agora retornou.<\/p>\n Fica a dica. Caso j\u00e1 tenha passado por esse problema e queria acrescentar alguma informa\u00e7\u00e3o, deixe um coment\u00e1rio.<\/p>\n Gostou dessa dica?<\/b><\/p>\n Cadastre seu e-mail para receber novos Posts e curta minha P\u00e1gina no Facebook<\/a> para receber Dicas de Leituras e Eventos sobre SQL Server.<\/p>\n\n
\nalloc unit ID 6666666666666666 (type “In-row data”). Column “Nome_Coluna1<\/strong>” value is out of range for data type “decimal”.
\nUpdate column to a legal value. [SQLSTATE 42000] (Error 2570)<\/p>\n
\nalloc unit ID 6666666666666666 (type “In-row data”). Column “Nome_Coluna2<\/strong>” value is out of range for data type “numeric”.
\nUpdate column to a legal value. [SQLSTATE 42000] (Error 2570)<\/p>\n
\nCHECKDB found 0 allocation errors and 2 consistency errors in database ‘Nome_Database<\/strong>‘. [SQLSTATE 01000] (Error 8989).\u00a0 The step failed.<\/p>\n
\nErro na Coluna 1: Page (1:88888888), slot 4 in object ID 77777777
\nErro na Coluna 2: Page (1:88888888), slot 4 in object ID 77777777<\/p>\n
\nDBCC PAGE ( Nome_Database , 1 , 88888888 , 3 )<\/p>\n
\nSELECT *
\nFROM Tabela
\nWHERE Nome_Coluna2 = 89998897014397766.68<\/p>\n
\nSELECT count(*)
\nFROM Tabela
\nWHERE Nome_Coluna2 = 89998897014397766.68<\/p>\n
\nupdate Tabela
\nset Nome_Coluna2 = 9999999999
\nWHERE Nome_Coluna2 = 89998897014397766.68<\/p>\n
\nSELECT *
\nFROM Tabela
\nWHERE Nome_Coluna2 = 9999999999<\/p>\n
\nDBCC CHECKTABLE(‘Nome_Tabela’)<\/p>\n
\nPage (1:88888888)<\/strong>, slot 4<\/strong> in object ID 77777777, index ID 1, partition ID 99999999999999999999,alloc unit ID 6666666666666666 (type “In-row data”). Column “Nome_Coluna1<\/strong>” value is out of range for data type “decimal”.Update column to a legal value.<\/p>\n
\nset Nome_Coluna1 = -1634.41
\nWHERE Chave_Tabela = xxxxxx<\/p>\n
\nDBCC CHECKTABLE(‘Nome_Tabela’)<\/p>\n
\nINSERT INTO Tabela
\nSELECT Colunas FROM Tabela
\nWHERE …<\/p>\n