Ik kom regelmatig situaties tegen waarbij logshipdatabases (=secondaries) niet meer via logshipping wordt bijgewerkt. Meestal zien we dan in de geschiedenis van de LSRestore-job in de SQL Agent van de database server waar de logshipdatabase op draait een melding die aangeeft dat transactielogs niet meer kunnen worden ingelezen omdat ze ‘out-of-sequence’ of ‘too recent’ zijn. Deze situatie wordt meestal door één van onderstaande scenario’s veroorzaakt:

• Er is een FULL backup van de database gemaakt zonder de optie COPY_ONLY.
• Het recovery model is aangepast. Het aanpassen van het recovery model wordt in de SQL Server gelogd als Setting database option RECOVERY to SIMPLE for database ‘[naam van de database]’ (zonder blokhaken).
• Er heeft een RESTORE plaats gevonden waarbij de database in NonRecovery is gezet
• Er zijn transactielogs van de brondatabase verwijderd of naar een andere locatie gekopieerd. Wanneer deze transactielogs nog ergens zijn te vinden, kan worden volstaan met het plaatsen van de transactielogs in de folder van waaruit de LSRestore-job de transactielogs inleest. Voor de veiligheid worden deze transactielogs uit de bronfolder gekopieerd en niet verplaatst.

De gebruikte query om inzicht te krijgen in uitgevoerde restore jobs is

SELECT
       rh.destination_database_name AS [Database],
       CASE
             WHEN rh.restore_type = 'D' THEN 'Database'
             WHEN rh.restore_type = 'F' THEN 'File'
             WHEN rh.restore_type = 'I' THEN 'Differential'
             WHEN rh.restore_type = 'L' THEN 'Log'
       ELSE rh.restore_type END AS [Restore Type],
       rh.restore_date AS [Restore Date],
       bmf.physical_device_name AS [Source], 
       rf.destination_phys_name AS [Restore File],
       rh.user_name AS [Restored By]
FROM msdb.dbo.restorehistory rh
INNER JOIN msdb.dbo.backupset bs ON rh.backup_set_id = bs.backup_set_id
INNER JOIN msdb.dbo.restorefile rf ON rh.restore_history_id = rf.restore_history_id
INNER JOIN msdb.dbo.backupmediafamily bmf ON bmf.media_set_id = bs.media_set_id
-- WHERE destination_database_name = '[naam van de database]' -- zonder blokhaken
ORDER BY rh.restore_date DESC
GO

De gebruikte query voor inzicht in gemaakte backups is:

SELECT
       s.database_name,
       m.physical_device_name,
       CAST(CAST(s.backup_size / 1000000 AS INT) AS VARCHAR(14)) + ' ' + 'MB' AS bkSize,
       CAST(DATEDIFF(second, s.backup_start_date,
       s.backup_finish_date) AS VARCHAR(4)) + ' ' + 'Seconds' TimeTaken,
       s.backup_start_date,
       CAST(s.first_lsn AS VARCHAR(50)) AS first_lsn,
       CAST(s.last_lsn AS VARCHAR(50)) AS last_lsn,
       CASE s.[type] WHEN 'D' THEN 'Full'
       WHEN 'I' THEN 'Differential'
       WHEN 'L' THEN 'Transaction Log'
       END AS BackupType,
       s.server_name,
       s.recovery_model
FROM msdb.dbo.backupset s
INNER JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id
WHERE s.database_name = DB_NAME() -- Remove this line for all the database
ORDER BY backup_start_date DESC, backup_finish_date;

In de meeste gevallen dient de logshipdatabse opnieuw te worden opgebouwd. Alleen wanneer de melding ‘too recent’ zich voordoet en de transactielogs die ontbreken zijn nog beschikbaar, kan de logshipdatabase met de ontbrekende transactielogs worden hersteld.