KB2653893 - FIX: Leva muito tempo para restaurar uma base de dados no SQL Server 2008 R2 ou no SQL Server 2008 ou no SQL 2012

Sintomas

Pode demorar muito tempo a restaurar uma base de dados no Microsoft SQL Server 2008 R2 ou no Microsoft SQL Server 2008 ou no Microsoft SQL Server 2012.

Causa

Este problema ocorre porque leva muito tempo a construir a lista de Ficheiros de Registo Virtual (VLF) quando existem muitos VLFs na base de dados.

Resolução

Estado

A Microsoft confirmou que este problema ocorre nos produtos da Microsoft listados na secção "Aplica-se a".

Mais Informações

Pode verificar o número de segmentos VLF, revendo o ficheiro de registo de erros SQL e, em seguida, encontrando o número da sequência de registo (LSN) em cada ficheiro de cópia de segurança do registo de transações. Os primeiros dígitos antes do símbolo do cólon nas LSNs correspondem ao número do LSN. Por exemplo, o primeiro número da primeira mensagem informativa para o LSN é 1. No entanto, o primeiro número da segunda mensagem informativa para o LSN é 100001. Neste cenário, existem 100.000 VLFs que são usados entre o momento da primeira mensagem informativa e a segunda mensagem informativa. Portanto, o registo de transações fragmentado registado que tem muitos Ficheiros de Registo Virtual (VLFs) assemelha-se ao seguinte:

{O Log foi apoiado. Base de dados: mydbname, data de criação(hora): 2010/07/08 (12:36:46), primeiro LSN: 1:5068:70, último LSN: 1:5108:1, número de dispositivos de despejo: 1, informação do dispositivo: (FILE=1, TYPE=DISK: {'C\pasta\logbackup1.trn'}). Esta é apenas uma mensagem informativa. Não é necessária qualquer ação do utilizador. O registo estava atrasado. Base de dados: mydbname, data de criação (hora): 2010/07/08 (15:36:46), primeiro LSN: 100001:5108:1, último LSN: 100002:5108:1, número de dispositivos de despejo: 1, informações do dispositivo: (FILE=2, TYPE=DISK: {'C:\pasta\logbackup2.trn'}). Esta é apenas uma mensagem informativa. Não é necessária qualquer ação do utilizador.}

Referências

Para obter mais informações sobre os números da sequência de registo (LSN), visite o seguinte website da MSDN:

Informações gerais sobre números de sequência de registo

Para obter mais informações sobre como uma estrutura de ficheiros de registo pode afetar o tempo de recuperação da base de dados, visite o seguinte website da MSDN:

Como uma estrutura de ficheiros de registo pode afetar o tempo de recuperação da base de dadosPara mais informações sobre o registo de transações VLFs, visite o seguinte website da MSDN:

Informações gerais sobre o ficheiro de registo de transações

Solução

• Aguarde que a operação de restauro ou recuperação esteja concluídaSe tiver uma base de dados não recuperada que esteja a experimentar o desempenho lento quando restaurar ou recuperar a base de dados, poderá ter de esperar que a operação de restauro ou recuperação esteja concluída. Por exemplo, pode ver o estado offline ou o estado de recuperação no SQL Server Management Studio (SSMS) para uma base de dados não recuperada. Parar o SQL Server geralmente não oferece alívio para uma recuperação lenta e pode levar mais tempo para repetir a mesma fase de análise de recuperação, fase de redo ou desfazer fase.

• Evite restaurar a sequência de registo de transações que contém milhares de VLFsSe experimentar o desempenho lento enquanto restaura e recupera uma base de dados utilizando um ficheiro de backup, pode evitar restaurar as sequências de registo de transações que contêm milhares de VLFs. Para identificar o ficheiro de cópia de segurança que tem mais ficheiros de registos virtuais gravados, utilize a seguinte declaração para ver as colunas FirstLSN e LastLSN nos ficheiros de backup de registo: RESTAURAR HEADERONLY FROM DISK='C:\folder\file.trn'Pode decidir evitar restaurar os ficheiros de cópia de segurança de registo. Ou, pode utilizar a declaração STOP AT nos comandos RESTORE para evitar as partes altamente fragmentadas dos registos de transações. Se não restaurar totalmente as sequências de registo até ao ponto mais recente durante um cenário de recuperação de falhas, a perda de dados ocorre na sua base de dados SQL Server. Esta perda de dados ocorre porque nem todas as transações estão a ser mantidas. Portanto, há uma decisão de troca de negócios. Pode restaurar totalmente um registo de transações altamente fragmentado. No entanto, esta operação pode demorar muitas horas. Ou, pode utilizar a declaração STOP AT na recuperação para parar a recuperação antes da parte altamente fragmentada do tronco. No entanto, quaisquer transações em falta que omitas estão perdidas.Nota Sem instalar este hotfix, não existe normalmente um recurso seguro para uma recuperação acelerada após reiniciar o SQL Server. O SQL Server tem de localizar a lista de VLFs para analisar os ficheiros de registo, para refazer as transações concluídas e, em seguida, desfazer transações incompletas para terminar a recuperação para colocar a base de dados online em segurança. Não é possível saltar com segurança as transações durante a recuperação.