KB2653893 - CORREÇÃO: demora muito tempo a restaurar uma base de dados no SQL Server 2008 R2 ou no SQL Server 2008 ou no SQL 2012

Sintomas

Poderá 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 demora muito tempo a criar a lista de Ficheiros de Registo Virtual (VLF) quando existem muitas 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 ao rever o ficheiro de registo de erros do SQL e, em seguida, ao encontrar o número da sequência de registos (LSN) em cada ficheiro de cópia de segurança do registo de transações. Os primeiros dígitos antes do símbolo de dois pontos nos LSNs correspondem ao número do LSN.

Por exemplo, o primeiro número na primeira mensagem informativa do LSN é 1. No entanto, o primeiro número na segunda mensagem informativa para o LSN é 100001. Neste cenário, existem 100 000 VLFs que são utilizados entre a hora da primeira mensagem informativa e a segunda mensagem informativa. Por conseguinte, o registo de transações fragmentado registado que tem muitos Files de Registo Virtual (VLFs) assemelha-se ao seguinte:

{Foi efetuada uma cópia de segurança do registo. Base de dados: mydbname, data(hora de criação): 07/2010/08(12:36:46), primeiro LSN: 1:5068:70, última LSN: 1:5108:1, número de dispositivos de informação de falha de sistema: 1, informações do dispositivo: (FILE=1, TYPE=DISK: {'C:\folder\logbackup1.trn'}). Esta é apenas uma mensagem informativa. Não é necessária nenhuma ação do utilizador.

Foi efetuada uma cópia de segurança do registo. Base de dados: mydbname, data(hora de criação): 07/2010/08(15:36:46), primeiro LSN: 100001:5108:1, última LSN: 100002:5108:1, número de dispositivos de informação de falha de sistema: 1, informações do dispositivo: (FILE=2, TYPE=DISK: {'C:\folder\logbackup2.trn'}). Esta é apenas uma mensagem informativa. Não é necessária nenhuma ação do utilizador.}

Referências

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

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

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 site da MSDN:

Como uma estrutura de ficheiros de registo pode afetar o tempo

de recuperação da base de dadosPara obter mais informações sobre os VLFs do registo de transações, visite o seguinte site da MSDN:

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

Solução

• Aguarde pela conclusão
  
  da operação de restauro ou recuperação Se tiver uma base de dados não recuperada que esteja a ter um desempenho lento ao restaurar ou recuperar a base de dados, poderá ter de aguardar pela conclusão da operação de restauro ou recuperação. Por exemplo, poderá 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 SQL Server normalmente não oferece nenhum alívio para uma recuperação lenta e pode demorar mais tempo a repetir a mesma fase de análise de recuperação, fase de repetição ou fase de anulação.

• Evite restaurar a sequência de registo de transações que contém milhares de VLFs
  
  Se tiver um desempenho lento enquanto restaura e recupera uma base de dados com um ficheiro de cópia de segurança, 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 registo virtual registados, utilize a seguinte instrução para ver as colunas FirstLSN e LastLSN nos ficheiros de cópia de segurança de registo:
  RESTORE HEADERONLY FROM DISK='C:\folder\file.trn'Pode
  
  decidir evitar restaurar os ficheiros de cópia de segurança de registo. Em alternativa, pode utilizar a instruçã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 anterior no tempo mais recente durante um cenário de recuperação de falhas, a perda de dados ocorre na 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. Em alternativa, pode utilizar a instrução STOP AT na recuperação para parar a recuperação antes da parte altamente fragmentada do registo. No entanto, todas as transações em falta que omitir serão perdidas.
  
  Nota Sem instalar esta correção, normalmente não existe nenhum recurso seguro para uma recuperação acelerada após reiniciar SQL Server. SQL Server tem de localizar a lista de VLFs para analisar os ficheiros de registo, refazer as transações concluídas e, em seguida, anular transações incompletas para concluir a recuperação para colocar a base de dados online em segurança. Não pode ignorar as transações em segurança durante a recuperação.