Início / dba / Perguntas / 154260
Accepted
Scott Hodgin - Retired
Asked: 2016-11-05 05:05:21 +0800 CST

Cenário DBCC CHECKDB interessante

  • 772

Acordei esta manhã com corrupção em um dos meus bancos de dados. Eu tenho um trabalho que executa DBCC CHECKDBs diários para todos os bancos de dados em um servidor. A saída indicou corrupção em apenas UMA tabela (felizmente).

Msg 8935, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). The previous link (5:216001) on page (5:216002) does not match the previous page (5:2603841) that the parent (5:3902159), slot 23 expects for this page.
Msg 8936, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). B-tree chain linkage mismatch. (5:628894)->next = (5:628895), but (5:628895)->Prev = (5:2602254).
Msg 8935, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). The previous link (5:1165706) on page (5:1165707) does not match the previous page (5:2602253) that the parent (5:1529), slot 33 expects for this page.
Msg 8980, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). Index node page (5:2239068), slot 33 refers to child page (5:2602254) and previous child (5:628894), but they were not encountered.
Msg 8980, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). Index node page (5:3902159), slot 22 refers to child page (5:2603841) and previous child (5:216001), but they were not encountered.
Msg 8981, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 10, partition ID 72057601280507904, alloc unit ID 72057601393229824 (type In-row data). The next pointer of (5:1212172) refers to page (5:3489726). Neither (5:3489726) nor its parent were encountered. Possible bad chain linkage.
Msg 8980, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). Index node page (5:1529), slot 32 refers to child page (5:2602253) and previous child (5:1165706), but they were not encountered.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 10, partition ID 72057601280507904, alloc unit ID 72057601393229824 (type In-row data). Page (5:3489727) is missing a reference from previous page (5:1212172). Possible chain linkage problem.
Msg 2533, Level 16, State 1, Line 1
Table error: page (5:2602253) allocated to object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (5:2602254) allocated to object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (5:2602255) allocated to object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (5:2603840) allocated to object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (5:2603841) allocated to object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (5:2603842) allocated to object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 8935, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). The previous link (5:2602255) on page (5:15918) does not match the previous page (5:15917) that the parent (5:3904979), slot 8 expects for this page.
Msg 8936, Level 16, State 1, Line 1
Table error: Object ID 1946163866, index ID 11, partition ID 72057601280442368, alloc unit ID 72057601393164288 (type In-row data). B-tree chain linkage mismatch. (5:15917)->next = (5:15918), but (5:15918)->Prev = (5:2602255).
CHECKDB found 0 allocation errors and 16 consistency errors in table 'AperioCompare.PolicyAmendmentCompare' (object ID 1946163866).
CHECKDB found 0 allocation errors and 16 consistency errors in database 'Aperio'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Aperio).

Estou sempre procurando a última linha para descobrir o nível mínimo de recuperação envolvido. Nesse caso, diz "repair_allow_data_loss é o nível mínimo de reparo para os erros encontrados pelo DBCC CHECKDB".

Olhei para o ID do objeto e verifiquei que OBJECT_NAME (1946163866) realmente apontava para minha tabela ONE. O relatório de erro mostrou problemas com os IDs de índice 10 e 11. Em seguida, selecionei sys.indexes para object_id=1946163866 e encontrei as linhas de índice para os índices 10 e 11 - ambos os índices não estão agrupados. Eliminei e recriei ambos os índices não clusterizados e executei novamente meu DBCC CHECKDB - nenhum erro foi relatado.

Estou intrigado com o nível mínimo de recuperação relatado pelo DBCC CHECKDB como sendo repair_allow_data_loss. Isso não deveria ser reconstruído?

Estou perdendo algo óbvio aqui?

dbcc sql-server-2016

2 respostas

  1. Bem, você está excluindo dados, mesmo que seja apenas o índice. ;-) A exclusão de um índice não clusterizado, no entanto, não incorre em perda de dados.

    Há um artigo sobre stackoverflow que pode fornecer mais informações:
    Que (tipo de) dados são perdidos ao usar REPAIR_ALLOW_DATA_LOSS?

    Ele faz referência a um artigo do site SQLSkills.com de Paul S. Randall, onde ele escreve em um artigo :

    REPAIR_ALLOW_DATA_LOSS é o nível de reparo que DBCC CHECKDB recomenda quando encontra corrupções. Isso ocorre porque a correção de quase tudo que não seja um problema menor de índice não clusterizado requer a exclusão de algo para repará-lo. Portanto, REPAIR_ALLOW_DATA_LOSS excluirá as coisas. Isso significa que provavelmente também excluirá alguns de seus dados. Se, por exemplo, encontrar um registro corrompido em uma página de dados, pode ser necessário excluir toda a página de dados, incluindo todos os outros registros da página, para corrigir a corrupção. Isso pode ser um monte de dados. Por esse motivo, o nome do nível de reparo foi escolhido com cuidado. Você não pode digitar REPAIR_ALLOW_DATA_LOSS sem perceber que provavelmente perderá alguns dados como parte da operação.

    Curto:

    Isso ocorre porque a correção de quase tudo que não seja um problema menor de índice não clusterizado requer a exclusão de algo para repará-lo.

    Então aí está. Se fosse algo diferente de um índice não clusterizado, você estaria perdendo dados.

    Corrigir os problemas de índice manualmente e, em seguida, executar novamente o DBCC checkdbcomando é provavelmente a melhor opção, pois você mantém o controle da perda de dados. Se depois de reparar o índice você ainda tiver dados corrompidos, precisará descobrir a importância dos dados e se precisar restaurar o banco de dados em um servidor diferente para recuperar os dados corrompidos.

    BTW: Paul estava na equipe de desenvolvimento do Microsoft SQL Server para o comando DBCC CHECKDB na versão 2000 do SQL Server e otimizou tudo na versão 2005 Bio

    • 1
  2. Best Answer

    Sim - há alguns erros em que CHECKDB escolhe REPAIR_ALLOW_DATA_LOSS mesmo que seja um índice não clusterizado. Você deve ser capaz de reconstruí-los manualmente (iniciar tran, desabilitar, reconstruir, confirmar tran). Meu palpite é uma gravação perdida, leitura obsoleta ou possivelmente um novo bug em 2016.

    • 1

relate perguntas