Início / dba / Perguntas / 63653
Accepted
RBarryYoung
Asked: 2014-04-23 07:36:09 +0800 CST

Corrigindo um arquivo de log corrompido em uma pequena janela de tempo de inatividade

  • 772

Estou trabalhando com um cliente que está recebendo o seguinte erro de seus backups de log de um de seus bancos de dados do SharePoint:

Backup detected log corruption in database FOOPORTAL_SP2010_Config. Context is FirstSector. 
  LogFile: 2 'D:\MSSQL2K8\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\FOOPORTAL_SP2010_Config_log.LDF' 
  VLF SeqNo: x864 VLFBase: x172d0000 LogBlockOffset: x176b1800 
  SectorStatus: 2 LogBlock.StartLsn.SeqNo: x771 LogBlock.StartLsn.Blk: x1f0c 
  Size: x400 PrevSize: x200

Eu entendo que isso é indicativo de problemas com o HW do disco e/ou subsistema IO, e estamos buscando isso com o provedor de hospedagem. Especificamente, este parece ser um "ponto ruim" no disco, porque é relatado consistentemente para o arquivo de log deste banco de dados, mas nenhum outro erro foi relatado para os outros 6 backups de log do banco de dados nas últimas semanas, nem para qualquer um dos mais de 20 outros backups de dados completos do banco de dados.

Meu problema imediato é que o cliente está funcionando dessa forma há várias semanas, porque este é um serviço obrigatório 24 horas por dia, 7 dias por semana, e eles não conseguiram me fornecer uma janela de serviço de tempo de inatividade para corrigir esse problema até (de repente) esta noite, por 2 horas . Infelizmente, corrupção de banco de dados e esse tipo de trabalho administrativo não é minha especialidade no SQL Server, e não tenho certeza de qual é a melhor/mais segura/mais confiável maneira de proceder.

Meu plano provisório agora é:

  1. Faça um backup completo do banco de dados assim que a janela de inatividade começar (os backups completos funcionaram sem erros durante isso)
  2. Desanexe o banco de dados antigo
  3. Exclua os arquivos de dados para o espaço
  4. Renomeie o arquivo de log (ainda mantendo-o)
  5. Restaure uma nova cópia do banco de dados do novo backup da etapa 1.

Minhas preocupações/ansiedade sobre isso são:

  • Isso deve funcionar? Ou existe uma abordagem mais segura/confiável?
  • Eu só tenho 2 horas, então existe uma abordagem mais eficiente em termos de tempo?

Quaisquer outras sugestões são bem-vindas.

sql-server sql-server-2008-r2

1 respostas

  1. Best Answer

    Se o seu arquivo de log estiver corrompido, minha preocupação é que um backup/restauração retenha a corrupção. Minha abordagem (que provavelmente seria mais rápida de concluir) seria:

    1. Execute um backup completo.
    2. Desanexar banco de dados.
    3. Exclua/renomeie o arquivo de log.
    4. Anexe o banco de dados e reconstrua o arquivo de log.
    5. Faça um segundo backup completo.

    Para anexar o banco de dados e reconstruir o arquivo de log, é apenas uma sintaxe adicional na instrução CREATE DATABASE :

    CREATE DATABASE [foo]
ON (FILENAME=<<Path to data file>>)
FOR ATTACH_REBUILD_LOG;

    Isso forçará o SQL Server a reconstruir o arquivo de log ao anexar o banco de dados.

    O risco disso é perder quaisquer transações que ocorram entre a conclusão do backup completo e a desanexação do banco de dados, mas parece que esse será um risco mínimo. Se você puder "congelar" o Sharepoint no início da janela de inatividade, isso ajudará a reduzir esse risco.

    • 6

relate perguntas