Доставка журналов SQL Server 2012

Я являюсь разработчиком в небольшом магазине, у которого нет администратора базы данных, и я пытаюсь заставить работать доставку журналов с SQL Server 2012. Я пытаюсь загрузить отчеты из системы транзакций в новое хранилище данных и буду использовать эту базу данных в качестве промежуточной области.

Я запустил мастер доставки журналов, и основные задания резервного копирования и копирования файлов работают каждый раз. Вторичное задание восстановления, по-видимому, случайно завершается неудачей.

Основной сервер имеет только одно задание журнала транзакций. Дифференциальное резервное копирование отключено (не уверен, если это имеет значение), но имеет полное резервное копирование.

Вторичный сервер - это новая установка без планов обслуживания, резервных копий или активных пользователей.

Есть ли способ принудительно синхронизировать резервную копию или всегда обеспечивать ее синхронизацию?

Это просто кажется таким хрупким. Пожалуйста, порекомендуйте.

Отредактированный журнал ниже:

*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'*

ОБНОВЛЕНИЕ: Выполнение ниже запроса есть некоторая странная резервная копия журнала транзакций (возможно)

NUL - это то, что в таблице. Не знаю, почему это не NULL

Это время завершения резервного копирования, устройство, тип

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: \ Folder \ DB_20160108070000.trn Log

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

2016-01-07 23: 41: 07.000 {51C661F9-2DC2-4424-913F-B9CFADA69FEE} 1 База данных

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

Это просто кажется таким хрупким.

Logshipping проверен и доказан начиная с SQL Server 2000 (и даже старше) дней. Это не хрупкий.

Посмотри на ошибки ...

Последний восстановленный файл: \ server \ folder \ db_201601050 60002 .trn,

Logshipping пытается восстановить

Пункт назначения: '\ сервер \ папка \ db_201601050 80001 .trn'

Это означает, что у вас есть пробел в последовательности журнала . Могут происходить резервные копии журналов adhoc, которые нарушают цепочку журналов.

Обратитесь к моему ответу - Как служба доставки журналов может отслеживать .

Вы даже можете ограничить пользователей только резервным копированием журнала , чтобы резервные копии журнала adhoc не нарушали цепочку журналов. Также,

@ Spörri сделал правильный шаг, чтобы отключить службу записи SQL VSS, чтобы стороннее средство резервного копирования не могло взаимодействовать с SQL. Это трудно понять, так как сторонние программы иногда просто сумасшедшие !

Чтобы найти пробелы в резервных копиях журналов, вы можете использовать запрос ниже

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;

Еще один полезный запрос:

-- 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;