Envio de Log do SQL Server 2012

Sou desenvolvedor de uma pequena loja que não possui um DBA e estou tentando obter o envio de logs com o sql server 2012 funcionando. Estou tentando descarregar os relatórios do sistema de transações para um novo data warehouse e utilizarei esse banco de dados como uma área de preparação.

Executei o assistente de envio de logs e os trabalhos principais de backup e cópia de arquivos funcionam sempre. O trabalho de restauração secundária parece falhar aleatoriamente.

O servidor principal possui apenas um trabalho de log de transações. O backup diferencial está desativado (não tenho certeza se isso importa), mas existe um backup completo.

O servidor secundário é uma instalação nova, sem planos de manutenção, backups ou usuários ativos.

Existe uma maneira de forçar o backup de volta à sincronização ou sempre garantir que ele permaneça sincronizado?

Parece tão frágil. Por favor informar.

Log redigido abaixo:

*Starting transaction log copy. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Retrieving copy settings. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Retrieved copy settings. 
Primary Server: '', 
Primary Database: 'db', Backup Source Directory: '\\server\folder', 
Backup Destination Directory: '\\server\folder', 
Last Copied File: '\\server\folder\db_20160105070002.trn'
Starting transaction log restore. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Retrieving restore settings. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
Copying log backup files. 
Primary Server: 'server', Primary Database: 'db', 
Backup Source Directory: '\\server\folder', 
Backup Destination Directory: '\\server\folder'
Retrieved common restore settings. 
Primary Server: 'server', 
Primary Database: 'db', 
Backup Destination Directory: '\\server\folder', 
File Retention Period: 14400 minute(s)
Retrieved database restore settings. 
Secondary Database: 'db', 
Restore Delay: 10, 
Restore All: True, 
Restore Mode: Standby, 
Disconnect Users: True, 
Last Restored File: \\server\folder\db_20160105060002.trn, 
Block Size: Not Specified, 
Buffer Count: Not Specified, 
Max Transfer Size: Not Specified
Disconnecting users. 
Secondary DB: 'db'
Copying log backup file to temporary work file.
 Source: '\\server\folder\db_20160105080001.trn', 
Destination: '\\server\folder\db_20160105080001.wrk'
Renamed temporary work file. 
Source: '\\server\folder\db_20160105080001.wrk',
Destination: '\\server\folder\db_20160105080001.trn'
Checking to see if any previously copied log backup files that are required by the restore operation are missing. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'
The copy operation was successful. 
Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7', 
Number of log backup files copied: 1
An error occurred restoring the database access mode. (Alter failed for Database 'db'. )
The file '\\server\folder\db_20160105070002.trn' is too recent to apply to the secondary database 'db'. 
(The log in this backup set begins at LSN 52498000002221000001, which is too recent to apply to the database. An earlier log backup that includes LSN 52498000002197900001 can be restored.
RESTORE LOG is terminating abnormally.)
Searching for an older log backup file. 
Secondary Database: 'db'
Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105060002.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105050001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105040001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105030001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105020000.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105010001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160105000001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104230001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104220001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104210001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104200001.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104190004.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104180000.trn'

Skipped log backup file. Secondary DB: 'EntRIS', File: '\\server\folder\db_20160104170002.trn'

Could not find a log backup file that could be applied to secondary database 'db'.
Deleting old log backup files. Primary Database: 'db'

The restore operation completed with errors. Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7'*

UPDATE: executando abaixo da consulta, há algum backup de log de transações ímpares (talvez)

O NUL é o que está na tabela. Não faço ideia por que não é NULL

Hora de término do backup, dispositivo e tipo

2016-01-08 02: 00: 01.000 D: \ Folder \ DB_20160108090001.trn Log

2016-01-08 01: 00: 01.000 D: \ Folder \ DB_20160108080001.trn Log

2016-01-08 00: 00: 00.000 D: \ Pasta \ DB_20160108070000.trn Log

2016-01-07 23: 46: 41.000 NUL Log

07-01-2016 23: 41: 07.000 {51C661F9-2DC2-4424-913F-B9CFADA69FEE} 1 banco de dados

2016-01-07 23: 00: 01.000 D: \ Folder \ DB_20160108060001.trn Log

Parece tão frágil.

O logshipping é testado e comprovado desde o sql server 2000 (e até mais antigo) dias. Não é frágil.

Veja os erros ...

Última arquivo restaurado: \ server \ pasta \ db_201601050 60002 .trn,

O logshipping está tentando restaurar

Destino: '\ server \ pasta \ db_201601050 80001 .trn'

Isso significa que você tem uma lacuna na sequência do log . Pode haver backups ad-hoc de log que estão quebrando a cadeia de log.

Consulte a minha resposta - Como o envio de logs sabe acompanhar .

Você pode até restringir os usuários a COPY ONLY backups de log , para que backups ad-hoc não quebrem a cadeia de logs. Além disso,

A @ Spörri fez um argumento válido para desativar o serviço de gravador SQL VSS, para que a ferramenta de backup de terceiros não possa interagir com o SQL. É difícil descobrir isso, já que os softwares de terceiros são loucos às vezes !

Para descobrir falhas nos backups de log, você pode usar a consulta abaixo

SELECT 
    s.database_name,s.backup_finish_date,y.physical_device_name
FROM 
    msdb..backupset AS s INNER JOIN
    msdb..backupfile AS f ON f.backup_set_id = s.backup_set_id INNER JOIN
    msdb..backupmediaset AS m ON s.media_set_id = m.media_set_id INNER JOIN
    msdb..backupmediafamily AS y ON m.media_set_id = y.media_set_id
WHERE 
    (s.database_name = 'databaseNamePrimaryServer')
ORDER BY 
    s.backup_finish_date DESC;

Outra consulta útil:

-- http://sqlblog.com/blogs/tibor_karaszi/archive/2014/11/03/can-you-restore-from-your-backups-are-you-sure.aspx
-- modified by Kin to include backup start and finish dates
SELECT TOP(100)
database_name
,CASE bs.TYPE
   WHEN 'D' THEN 'Full'
   WHEN 'I' THEN 'Differential'
   WHEN 'L' THEN 'Log'
   WHEN 'F' THEN 'File or filegroup'
   WHEN 'G' THEN 'Differential file '
   WHEN 'P' THEN 'Partial'
   WHEN 'Q' THEN 'Differential partial'
END AS backup_type
,bs.is_copy_only
,bs.is_snapshot
,bs.backup_start_date
,bs.backup_finish_date
,DATEDIFF(SECOND, bs.backup_start_date, bs.backup_finish_date) AS backup_time_sec
,mf.physical_device_name
,bs.database_name
FROM msdb.dbo.backupset AS bs
  INNER JOIN msdb.dbo.backupmediafamily AS mf ON bs.media_set_id = mf.media_set_id  
  where database_name = 'master' -- change here for your database 
ORDER BY backup_finish_date DESC;