SQL Server 2008 R2のログ配布で復元を処理する方法は失敗しますか？

Question

私はプライマリServer1（SQL Server 2008 R2）からセカンダリServer2（SQL Server 2008 R2）へのログ配布をスタンバイモードで行っています。

だから、3ジョブがある：Server1で

• バックアップ、
• コピー、
• はSERVER2に復元します。

バックアップ元と宛先のパスはserver2にあり、フォルダアクセスの問題はありません。

最初のジョブが実行され、バックアップが作成され、2番目のジョブがコピーと復元を作成します。 初めてのときはうまくいきましたが、5分、7分、9分でスケジュールしました。

しかし、その第二の試みに取り組んでいない私はそれを手動で実行にもかかわらず、でもジョブがエラーの下に投げる復元：1つの以上のログバックアップは、プライマリサーバ上で起こってありますので、

The restore operation completed with errors. Secondary ID: 
could not find a log backup file that could be applied to secondary database. 

はこの起こっています？はいの場合、どうすればログバックアップ（外部ログバックアップとログ配布）の両方を管理できますか。

Answer 1

Message 
2015-10-13 21:09:05.13  *** Error: The file ‘C:\LS_S\LSDemo_20151013153827.trn’ is too recent to apply to the secondary database ‘LSDemo’.(Microsoft.SqlServer.Management.LogShipping) *** 
2015-10-13 21:09:05.13  *** Error: The log in this backup set begins at LSN 32000000047300001, which is too recent to apply to the database. An earlier log backup that includes LSN 32000000047000001 can be restored. 
RESTORE LOG is terminating abnormally.(.Net SqlClient Data Provider) *** 
Above error is a shown in failure of the history of restore job. If the failure is more than configured thresholds, then we would start seen below error in SQL ERRORLOG on secondary also: 
2015-10-14 06:22:00.240 spid60  Error: 14421, Severity: 16, State: 1. 
2015-10-14 06:22:00.240 spid60  The log shipping secondary database PinalServer.LSDemo has restore threshold of 45 minutes and is out of sync. No restore was performed for 553 minutes. Restored latency is 4 minutes. Check agent log and logshipping monitor information. 

To start troubleshooting, we can look at Job activity monitor on secondary which would fail with the below state: 

SQL SERVER - Log Shipping Restore Job Error: The file is too recent to apply to the secondary database LS-Restore-01 

If you know SQL transaction log backup basics, you might be able to guess the cause. If we look closely to the error, it talks about LSN mismatch. Most of the cases, a manual transaction log backup was taken. I remember few scenarios where a 3rd party tool would have taken transaction log backup of database which was also part of a log shipping configuration. 

Since we know the cause now, what we need to figure out is – where is that “out of band” backup? Here is the query which I have written on my earlier blog. 

-- Assign the database name to variable below 
DECLARE @db_name VARCHAR(100) 
SELECT @db_name = 'LSDemo' 
-- query 
SELECT TOP (30) 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 'Diff`enter code here`erential' 
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 
ORDER BY backup_start_date DESC 
,backup_finish_date 

Once we run the query, we would get list of backups happened on the database. This information is picked from MSDB database. 

Below picture is self-explanatory. 

SQL SERVER - Log Shipping Restore Job Error: The file is too recent to apply to the secondary database LS-Restore-02 

Once we found the “problematic” backup, we need to restore it manually on secondary database. Make sure that we are using either norecovery or standby option so that other logs can be restored. Once file is restored, the restore job would be able to pick-up from the same place and would catch up automatically. 

    enter code here 

What are the other problems you have seen with Log-shipping? If you can share some of the common errors, it would be of great help for others and I will try to blog about them too with your help. 

Reference: Pinal Dave (https://blog.sqlauthority.com)