Envio de Log - RESTORE WITH STANDBY - no SQL Server 2012 continua quebrando

Estamos usando o envio de logs e RESTORE WITH STANDBYno SQL Server 2012 para restaurar o banco de dados no modo somente leitura para fins de relatório. No entanto, a configuração de envio de log continua interrompida após a conclusão de uma restauração de um ou dois backups de log. O envio de logs é interrompido apenas quando está sendo executado como RESTORE WITH STANDBY; RESTORE WITH NORECOVERYnão causa nenhum problema.

Minha única intuição sobre isso é que o banco de dados primário não é tão dinâmico. Portanto, quando não há transações, isso causa problemas no RESTOREprocesso, talvez?

Alguma idéia, correções conhecidas?

Eu trabalhei por alguns dias executando um trabalho regular que faz atualização pesada em duas tabelas. Quando o trabalho parou de executar, a configuração de envio de log falhou rapidamente, incapaz de processar o arquivo .trn. Reinicializei o envio de logs e tentei ver se ele continuaria sendo executado apenas fazendo uma pequena atualização, alterando o valor de uma coluna de um registro em uma tabela, independentemente de quem ainda falhasse.

Obrigado por todas as suas respostas.

PS: Um trecho do nosso log

02/25/2013 13: 00: 00, LSRestore_DBDB01-A_BulldogDB, em andamento, 1, DBREPORTS, LSRestore_DBDB01-A_BulldogDB, etapa da tarefa de log de restauração de envio de log., 2013-02-25 13: 00: 12.31 *** Erro: Não foi possível aplicar o arquivo de backup de log '\\ dbsan01 \ DBBackups \ LSBackup_BulldogDB \ BulldogDB_20130225180000.trn' ao banco de dados secundário 'BulldogDB'. (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.31 *** Erro: ocorreu um erro ao processar o log do banco de dados 'BulldogDB'. Se possível, restaure a partir do backup. Se um backup não estiver disponível, pode ser necessário reconstruir o log.
Ocorreu um erro durante a recuperação, impedindo que o banco de dados 'BulldogDB' (8: 0) fosse reiniciado. Diagnosticar os erros de recuperação e corrigi-los ou restaurar a partir de um backup conhecido bom. Se os erros não forem corrigidos ou esperados, entre em contato com o Suporte técnico.
RESTORE LOG está sendo finalizado de forma anormal.
Processou 0 páginas para o arquivo 'BulldogDB' do banco de dados 'BulldogDB' no arquivo 1.
1 páginas processadas para o arquivo 'BulldogDB' do banco de dados 'BulldogDB_log' no arquivo 1. (. Net SqlClient Data Provider) ***
2013-02-25 13: 00: 12.32 *** Erro: Não foi possível registrar o histórico / mensagem de erro. (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.32 *** Erro: ExecuteNonQuery requer uma conexão aberta e disponível. O estado atual da conexão está fechado. (System.Data) ***
2013-02-25 13: 00: 12.32 Ignorando o arquivo de backup de log '\\ dbsan01 \ DBBackups \ LSBackup_BulldogDB \ BulldogDB_20130225180000.trn' para o banco de dados secundário 'BulldogDB' porque o arquivo não pôde ser verificado.
2013-02-25 13: 00: 12.32 *** Erro: Não foi possível registrar o histórico / mensagem de erro. (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.32 *** Erro: ExecuteNonQuery requer uma conexão aberta e disponível. O estado atual da conexão está fechado. (System.Data) ***
2013-02-25 13: 00: 12.33 *** Erro: ocorreu um erro ao restaurar o modo de acesso ao banco de dados. (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Erro: ExecuteScalar requer uma conexão aberta e disponível. O estado atual da conexão está fechado. (System.Data) ***
2013-02-25 13: 00: 12.33 *** Erro: Não foi possível registrar o histórico / mensagem de erro. (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Erro: ExecuteNonQuery requer uma conexão aberta e disponível. O estado atual da conexão está fechado. (System.Data) ***
2013-02-25 13: 00: 12.33 *** Erro: ocorreu um erro ao restaurar o modo de acesso ao banco de dados. (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Erro: ExecuteScalar requer uma conexão aberta e disponível. O estado atual da conexão está fechado. (System.Data) ***
2013-02-25 13: 00: 12.33 *** Erro: Não foi possível registrar o histórico / mensagem de erro. (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Erro: ExecuteNonQuery requer uma conexão aberta e disponível. O estado atual da conexão está fechado. (System.Data) ***
2013-02-25 13: 00: 12.33 Excluindo arquivos antigos de backup de log. Banco de dados primário: 'BulldogDB'
2013-02-25 13: 00: 12.33 *** Erro: Não foi possível registrar o histórico / mensagem de erro. (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Erro: ExecuteNonQuery requer uma conexão aberta e disponível. O estado atual da conexão está fechado. (System.Data) ***, 00: 00: 12,0,0 ,,,, 0

Se os backups de log puderem ser restaurados enquanto o banco de dados secundário estiver em NORECOVERY e só falharem quando estiver em READ-ONLY / STANDBY, eu assumiria que os backups de log estão corretos e não estão corrompidos.

Pode ser que seu componente de relatório tenha uma conexão aberta com o banco de dados; portanto, ao restaurar o arquivo de log, ele não pode obter uma conexão exclusiva com o banco de dados devido às conexões abertas. Haveria uma opção ao configurar o envio de logs para desconectar todas as conexões, permitindo restaurar o backup do log.

Em espera A restauração secundária desconecta os usuários apenas quando o trabalho é iniciado, depois que os usuários iniciam a conexão ... e isso interrompe o processo de restauração com o erro "acesso exclusivo". Eu recebi um serviço que tentou conectar-se ao banco de dados em espera durante a restauração. Isso fez com que o processo de restauração fosse interrompido após 1-10 / 100 arquivos restaurados.