Log shipping SQL Server 2012

Sono uno sviluppatore in un piccolo negozio che non ha un DBA e sto cercando di ottenere la consegna dei log con SQL Server 2012 funzionante. Sto cercando di trasferire i report di caricamento dal sistema di transazione a un nuovo data warehouse e userò questo db come area di gestione temporanea.

Ho eseguito la procedura guidata di distribuzione dei log e i processi di backup e copia file principali funzionano ogni volta. Il processo di ripristino secondario sembra non riuscire in modo casuale.

Il server primario ha un solo processo di registro delle transazioni. Il backup differenziale è disabilitato (non sono sicuro che sia importante) ma ha un backup completo.

Il server secondario è una nuova installazione senza piani di manutenzione, backup o utenti attivi.

Esiste un modo per forzare la sincronizzazione del backup o assicurarsi sempre che rimanga sincronizzato?

Sembra così fragile. Si prega di avvisare.

Registro redatto di seguito:

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

AGGIORNAMENTO: In esecuzione sotto la query c'è qualche backup del registro delle transazioni strano (forse)

Il NUL è quello che c'è nella tabella. Non ho idea del perché non sia NULL

Questo è il tempo di fine backup, dispositivo, tipo

08/01/2016 02: 00: 01.000 D: \ Cartella \ DB_20160108090001.trn Registro

08/01/2016 01: 00: 01.000 D: \ Cartella \ DB_20160108080001.trn Registro

08/01/2016 00: 00: 00.000 D: \ Cartella \ DB_20160108070000.trn Registro

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

07/01/2016 23: 41: 07.000 {51C661F9-2DC2-4424-913F-B9CFADA69FEE} 1 Database

07-01-2016 23: 00: 01.000 D: \ Cartella \ DB_20160108060001.trn Registro

Sembra così fragile.

Logshipping è testato e provato dai server sql 2000 (e anche più vecchi) giorni. Non è fragile.

Guarda gli errori ...

Ultimo file ripristinato: \ server \ folder \ db_201601050 60002 .trn,

Logshipping sta tentando di ripristinare

Destinazione: '\ server \ folder \ db_201601050 80001 .trn'

Ciò significa che hai una lacuna nella sequenza del registro . È possibile che si stiano verificando backup dei log ad hoc che interrompono la catena di log.

Fare riferimento alla mia risposta - In che modo Log shipping sa tenere traccia .

È anche possibile Limitare gli utenti alla COPIA SOLO dei backup dei registri , in modo che i backup dei registri ad hoc non interrompano la catena dei registri. Anche,

@ Spörri ha dichiarato valido per disabilitare il servizio SQL VSS writer, in modo che lo strumento di backup di terze parti non possa interagire con SQL. È un dolore scoprirlo, dato che i software di terze parti sono pazzi a volte !

Per scoprire lacune nei backup del log, è possibile utilizzare la query seguente

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;

Un'altra utile query:

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