Envoi de journaux SQL Server 2012

Je suis développeur dans une petite boutique qui n'a pas de DBA et j'essaie de faire fonctionner l'envoi de journaux avec SQL Server 2012. J'essaie de décharger les rapports du système de transactions vers un nouvel entrepôt de données et j'utiliserai cette base de données comme zone de transit.

J'ai exécuté l'assistant d'envoi de journaux et les travaux de sauvegarde et de copie de fichiers principaux fonctionnent à chaque fois. Le travail de restauration secondaire semble échouer de manière aléatoire.

Le serveur principal n'a qu'un seul travail de journal des transactions. La sauvegarde différentielle est désactivée (je ne sais pas si cela importe), mais a une sauvegarde complète.

Le serveur secondaire est une nouvelle installation sans plans de maintenance, sauvegardes ou utilisateurs actifs.

Existe-t-il un moyen de forcer la sauvegarde à se synchroniser ou de toujours s'assurer qu'elle reste synchronisée?

Cela semble tellement fragile. S'il vous plaît donnez votre avis.

Journal expurgé ci-dessous:

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

MISE À JOUR: En cours d'exécution en dessous des requêtes, une sauvegarde du journal des transactions impair (peut-être)

Le NUL est ce qui est dans le tableau. Aucune idée pourquoi ce n'est pas NULL

Il s'agit de l'heure de fin de la sauvegarde, du périphérique, du type

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

07/01/2016 23: 46: 41.000 Journal NUL

2016-01-07 23: 41: 07.000 {51C661F9-2DC2-4424-913F-B9CFADA69FEE} 1 Base de données

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

Cela semble tellement fragile.

Logshipping est testé et prouvé depuis 2000 jours sur SQL Server (et même plus). Ce n'est pas fragile.

Regardez les erreurs ...

Dernier fichier restauré: \ server \ folder \ db_201601050 60002 .trn,

Logshipping tente de restaurer

Destination: '\ serveur \ dossier \ db_201601050 80001 .trn'

Cela signifie que vous avez un écart dans la séquence de journaux . Il peut y avoir des sauvegardes de journaux ad hoc qui interrompent la chaîne de journaux.

Reportez-vous à ma réponse - Comment l'expédition de journaux sait-elle comment suivre ?

Vous pouvez même restreindre les utilisateurs à COPIER UNIQUEMENT les sauvegardes de journaux , afin que les sauvegardes de journaux adhoc ne brisent pas la chaîne de journaux. Aussi,

@ Spörri a fait valoir un argument valable pour désactiver le service d'écriture SQL VSS, afin que l'outil de sauvegarde tiers ne puisse pas interagir avec SQL. C'est pénible de le découvrir, car les logiciels tiers sont parfois fous !

Pour découvrir les lacunes dans vos sauvegardes de journaux, vous pouvez utiliser la requête ci-dessous

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;

Une autre requête utile:

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