sqlserver關於日誌傳輸log shipping的總結

官方文件

1、搭建logshipping是在主庫上進行，必須先對主庫進行全備，不需要先對從庫進行恢復，右鍵主庫--properties--Transaction log shipping，可以直接參考圖形介面一步步來，圖形介面中如果指定了主庫的備份路徑則可以自動對從庫進行恢復，此時恢復預設以norepalce形式進行

2、先對從庫進行恢復的話，如果主庫full備份後有日誌備份，則從庫要restore到主庫的最後一個備份的日誌，且是norecovery 模式，再在主庫上搭建logshipping

3、主庫匯出的trn格式的日誌檔案，這些檔案複製到從庫時，也是trn格式的日誌檔案

4、主庫生成2個job，一個alert，一個backup，alert呼叫儲存過程sys.sp_check_log_shipping_monitor_alert，backup呼叫sqllogship.exe命令，每搭建一個logshipping，主庫就生成一個backup job，alert job不會再增加

5、備庫生成3個job，一個alert，一個copy，一個restore，alert呼叫儲存過程sys.sp_check_log_shipping_monitor_alert，copy和restore都是呼叫sqllogship.exe命令，每搭建一個logshipping，從庫就生成一個copy job和restore job，alert job不會再增加

6、可以設定主庫的網路備份目錄、主庫的本地備份目錄、從庫的複製目錄都是設定成網路上的同一個目錄

7、如果採用上面6的模式，則可以關閉從庫的copy job，不影響log shipping

8、主庫的本地備份目錄、從庫的複製目錄是同一個目錄時，兩者的delete都有效，哪個先觸發刪除條件，哪個就開始delete

9、logshipping正常同步的過程中，如果主庫手工做了一次backup log的備份，那麼日誌被截斷了，從庫logshipping的restore log job會開始報錯，找不到需要恢復的日誌，此時主庫的backup log job和從庫的copy job仍然正常執行(比如bakcup log job每小時執行一次，8:00開始執行，8:30手工突然執行了一次backup log，9:00執行backup log job的時候的日誌就只有8:30-9:00的了，而從庫需要8:00-9:00的日誌，這樣loggshipping從庫的restore log job就報錯了)，官方有類似的問題https://support.microsoft.com/zh-cn/help/329133/description-of-error-message-14420-and-error-message-14421-that-occur

10、上面9的場景下，如果8:30手工執行的備份包還在，可以恢復嗎

以下兩個實驗都真實存在過

個人實驗過1：不行，從庫直接使用8:30的日誌備份進行restore ，報錯The log in this backup set begins at LSN XXX, which is too recent to apply to the database，發現8:30手工備份的日誌居然接不上logshipping的日誌LSN

個人實驗過2：行，從庫直接使用8:30的日誌備份進行restore ，可以restore成功，後續從庫的restore log job正常執行

11、logshipping的backup log job是使用sqllogship.exe，而我們普通t/sql就是backup log命令，就算兩種備份生成的字尾名不一樣，但是logshipping的backup log job生成的日誌備份也可以手工使用restore log進行恢復

12、搭建logshipping後，主庫檢視msdb.dbo.log_shipping_primary_databases會記錄logshipping的資訊，但是主庫檢視msdb.dbo.log_shipping_secondary_databases沒有記錄。從庫相反，從庫檢視msdb.dbo.log_shipping_secondary_databases記錄logshipping的資訊，從庫檢視msdb.dbo.log_shipping_primary_databases沒有記錄

13、主伺服器上的完整備份不影響logshipping，因為完整備份不會截斷日誌

14、從庫Restore Transaction Log選擇NO recovery mode，則從庫的圖示狀態顯示綠色小箭頭restoring，此時從庫無法讀。選擇Standby mode，則從庫的圖示狀態顯示灰色(Standby/Read-Only),此時從庫可以讀

15、檢視logshipping是否正常，可以右鍵例項-->Reports-->Standard Reports-->Transaction Log Shipping Status,主庫只顯示主庫的狀態，從庫只顯示從庫的狀態，所以必須要同時登入主庫和從庫進行檢查

16、刪除logshipping，則只要登入主庫例項，右鍵資料庫-->Properties-->Transaction Log Shipping-->取消勾選Enable this as a primary database in a log shipping configuration，刪除後，主庫和從庫的job都自動刪除了，就算job被disable禁用了，也會被自動刪除掉

17、刪除logshipping後，要恢復從庫為讀寫狀態

如果從庫原來狀態圖示是顯示綠色小箭頭restoring，執行如下

RESTORE DATABASE [testdb] with recovery

如果從庫原來狀態圖示是顯示灰色(Standby/Read-Only)，執行如下

ALTER DATABASE [testdb] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

RESTORE DATABASE [testdb] WITH RECOVERY

ALTER DATABASE [testdb] SET MULTI_USER

18、logshipping，主庫故障後，需要把從庫切換為讀寫，操作類似上面17，不過從庫還要手工刪除原來的copy job和restore log job，並且要匯出原來主庫的一些業務job放在從庫上執行，因為logshipping不會同步job

19、logshipping從庫，不管是Standby/Read-Only狀態還是restoring狀態，都可以直接delete刪除，這點和mirror不一樣，mirror從庫restoring狀態無法delete刪除

20、8:30開始搭建logshipping，此過程中，如果8:30主庫執行了一次日誌備份截斷了日誌，那麼從庫只使用主庫8:00的全備份還能搭建成功嗎?從搭建開始到結束都不會報錯，這點不同於mirror，但是搭建成功後無法正常同步，假設8:35搭建成功，主庫開始執行backup log job，主庫backup log job和從庫copy job、restore log job都正常執行，但是從庫的報表Transaction Log Shipping Status會出現alert 報警，從庫的restore log job不會報錯但是有如下資訊，找不到全備份時刻點之後的起始log，會跳過後面8:35生成的所有主庫bakcup log job生成的log備份

Searching through log backup files for first log backup to restore. Secondary DB: 'testdb'

Skipped log backup file. Secondary DB: 'testdb', File: '\\logship\testdb_20190111083500.trn'

21、logshipping搭建成功後，主庫檢視msdb.dbo.log_shipping_primary_databases可以看到有多少個資料庫搭建了logshipping，以後日誌備份的指令碼里面可以排除這些資料庫，就是這些資料庫就不備份日誌了，以免截斷這些資料庫的日誌

22、如果主庫備份過程中比如備份到網路路徑，備份了一半突然網路中斷了，bakcup log job不會馬上停止只是會報錯，當網路好了，backup log job會對某一過程重試。

2019-01-13 11:04:00.36 Backup file '\\db\LOG\E_20190113161502.trn' does not exist

2019-01-13 11:04:00.36 Retry backup database 'E' to file '\\db\LOG\E_20190113161502.trn'

23、如果從庫的restore log job失敗了，restore log job重新執行正常，不會說前面restore 了一半，後面就無法接上了。這樣情況和上面22一樣，檔案在網路上，restore 了一半，後面網路中斷了，之後重新執行restore log job正常。

Error: The log backup file '\\db\LOG\E_20190110020001.trn' was verified but could not be applied to secondary database

24、logshipping，在從庫上看不到主庫是哪個。如果要看，則在從庫選中restore log job右鍵選擇view history，裡面的job日誌會記錄Primary Server和Primary Database

25、如果從庫的logshipping同步發生問題，但是logshipping的日誌都沒有丟，直接使用主庫的備份在從庫執行restore databae恢復即可，執行這個restore databae之前，不需要取消主庫的logshipping配置，但是最好把從庫的restore log job停止並禁用，等恢復好了再啟用這個job

26、主庫有full、diff的備份，也有diff之前的一個loggshipping日誌和之後的所有logshipping的日誌，經過實驗和生產環境驗證，從庫重新恢復使用full和diff備份後，從庫的restore log job會skip掉diff之前的log，後面的會restore，說明從庫的restore log job會使用從庫的最新的LSN去找需要的log進行恢復

27、如果主庫的backup log job是把日誌備份到網路路徑上，如果生成過程中遇到網路故障，會報錯，檔案不會生成，日誌不會截斷，下一次主庫的backup log job執行過程中會重新接上次的LSN點繼續生成檔案。比如這個job是1小時執行一次，8:00生成過程中報錯，那麼8點的job會回滾，8點的檔案不會生成，LSN還是上次7:00點正常backup log job截斷的LSN，那9:00生成的時候，就是7:00-9:00的資料，這樣9:00的檔案就會比較平時大一倍。如下dblog_1.trn檔案並沒有成功生成，儲存上沒有這個檔案。

----- START OF TRANSACTION LOG BACKUP -----

2019-01-15 08:00:01.29 Backing up transaction log. Primary Database: 'db', Log Backup File: '\\logship\LOG\dblog_1.trn'

2019-01-15 08:32:10.82 First attempt to backup database 'db' to file '\\logship\LOG\dblog_1.trn' failed because Write on "\\logship\LOG\dblog_1.trn" failed: 59(An unexpected network error occurred.)

BACKUP LOG is terminating abnormally.

2019-01-15 08:32:12.76 Backup file '\\logship\LOG\dblog_1.trn' does not exist

2019-01-15 08:32:12.76 Retry backup database 'db' to file '\\logship\LOG\dblog_1.trn'

2019-01-15 09:35:46.79 *** Error: Write on "\\logship\LOG\dblog_1.trn" failed: 59(An unexpected network error occurred.)

BACKUP LOG is terminating abnormally.

----- END OF TRANSACTION LOG BACKUP -----

Exit Status: 1 (Error)

28、logshipping重建，不需要關閉logshipping，只需要把從庫進行資料庫恢復即可，restore database+restore diff就可以了，logshipping的restore log job 會自動找到diff備份後面的第一個logshipping生成的log進行restore，如果嫌從庫的logshipping的restore log job執行太慢，可以在從庫手工restore主庫backup log job生產的備份，此時從庫先禁用restore log job，但是不禁用主庫的backup log job，這樣在從庫上可以restore database+restore diff+restore logshipping log

29、loggshipping從庫的restore log job總是從上一個成功的最後一個log開始找下一個log，restore log job日誌會記錄上一次成功restore的最後一個日誌，然後找下一個，比如上一次成功的restore log job，restore 了4、5、6號日誌，下一次restore log job會記錄Last Restored File是6，下一個該restore的是7

30、手工停掉主庫的backup log jog和從庫的restore log job，都會回滾，比如主庫正在backup 8:00-9:00的日誌，停掉它，不會截斷日誌，下一次10:00主庫重新執行backup log job時，主庫backup 8:00-10:00的日誌。從庫的restore log job也是一樣，比如從庫正在restore 8:00-9:00的日誌，停掉它，下一次10:00從庫重新執行restore log job，從庫restore 8:00-10:00的日誌。

31、loggshipping期間在主庫上手工執行backup log了，之後logshipping主庫繼續生成logshipping格式的日誌，之後重新備份主庫，之後logshipping主庫繼續生成logshipping格式的日誌，從庫利用主庫的資料庫備份進行restore database，再加上主庫備份資料庫之後生成的logshipping格式的日誌，loggshipping可以正常下去

比如7:00-8:00主庫正常生成logshipping格式的日誌，8:15突然手工backup log(8:00-8:15的日誌被截斷了，備份日誌格式是手工backup log的格式)，8:30主庫正常生成logshipping格式的日誌(8:15-8:30的日誌被截斷了，備份日誌格式是logshipping格式日誌)，8:40主庫重新備份資料庫，9:00從庫利用主庫的備份包進行還原，這個時候logshipping的從庫需要8:40之後的logshipping格式的日誌，而這些日誌都是有的，是可以正常logshipping的

32、logshipping模式下，不管主庫還是從庫，上面的job都是事務狀態，如果手工停止，說明事務不成功，會回滾，不用擔心

----- START OF TRANSACTION LOG BACKUP -----

----- END OF TRANSACTION LOG BACKUP -----

----- START OF TRANSACTION LOG RESTORE -----

----- END OF TRANSACTION LOG RESTORE -----

33、主庫的backup job暫停，手工複製或建立log檔案到從庫，看從庫的restore job是否異常

1、如果複製從庫restore記錄的最後一個log檔案之後的第一個檔案，比如是logship_20190118061000.trn，則從庫的restore log正常restore logship_20190118061000.trn，log日誌裡面不會報錯，restore jog正常結束

2、如果複製從庫restore記錄的之前的一個log檔案，比如copy logship_20190118060800.trn，則從庫的restore log無法restore

logship_20190118060800.trn，log日誌裡面會報錯，但是restore jog正常結束

Error: Skipping log backup file because the log terminates at an LSN value that is too early to apply to the database. Secondary DB: 'logship', File: '\\testdb1\logship\log\logship_20190118060800.trn'

3、如果手工建立一個空檔案，命名為從庫restore記錄的最後一個log檔案之後的檔案，比如logship_20190118061200.trn，則從庫的restore job直接忽略該檔案，log日誌裡面沒有報錯，restore job正常結束

Could not find a log backup file that could be applied to secondary database 'logship'.

4、如果複製其他主庫生成的一個log檔案過來並且重新命名為從庫restore記錄的最後一個log檔案之後的檔案，比如cp DBA_20190115074503.trn logship_20190118061300.trn，則從庫的restore job無法restore logship_20190118061300.trn，log日誌裡面會報錯，restore job不正常結束

Error: Could not apply log backup file '\\testdb1\logship\log\logship_20190118062300.trn' to secondary database 'logship'

Error: The backup set holds a backup of a database other than the existing 'logship' database.

34、從庫的restore job暫停，主庫的backup job正常,經測試，發現從庫restore log job是按日誌的生成名稱來恢復的，找到正確的名稱後，如果發現這個名稱之後生成的trn日誌都恢復了，那麼報錯，見下面2的測試

1、從庫刪除一個還沒有restore 的log檔案，再啟用從庫的restore job，從庫restore log job日誌報錯，並且不正常退出

Error: The file '\\testdb1\logship\log\logship_20190118070100.trn' is too recent to apply to the secondary database 'logship'

Searching for an older log backup file. Secondary Database: 'logship'

Skipped log backup file. Secondary DB: 'logship', File: '\\testdb1\logship\log\logship_20190118065900.trn'

skiped...

2、從庫把上面1的檔案改名，往前面的時間改，並越過最後一個已經restore log的時間，再啟用從庫的restore job，從庫restore log job日誌報錯，但是正常退出

cp logship_20190118070100.trn logship_201901180655000.trn

Error: The file '\\testdb1\logship\log\logship_20190118070100.trn' is too recent to apply to the secondary database 'logship'.

Skipped log backup file. Secondary DB: 'logship', File: '\\testdb1\logship\log\logship_20190118065900.trn'

Skipped log backup file. Secondary DB: 'logship', File: '\\testdb1\logship\log\logship_20190118065800.trn'

Skipped log backup file. Secondary DB: 'logship', File: '\\testdb1\logship\log\logship_20190118065700.trn'

Found a log backup file to apply. Secondary Database: 'logship', File: '\\testdb1\logship\log\logship_201901180655000.trn'

Error: Skipping log backup file because the log terminates at an LSN value that is too early to apply to the database. Secondary DB: 'logship', File: '\\testdb1\logship\log\logship_20190118065601.trn'

Error: The log in this backup set terminates at LSN 34000003927200001, which is too early to apply to the database. A more recent log backup that includes LSN 34000003932900001 can be restored

Skipped log backup file. Secondary DB: 'logship', File: '\\testdb1\logship\log\logship_20190118065700.trn'

Skipped log backup file. Secondary DB: 'logship', File: '\\testdb1\logship\log\logship_20190118065800.trn'

Skipped log backup file. Secondary DB: 'logship', File: '\\testdb1\logship\log\logship_20190118065900.trn'

...

3、從庫把該檔案改名，往後面的時間改，後面的log都還沒有被從庫restore過，再啟用從庫的restore job，從庫restore log job日誌報錯，並且不正常退出

Error: The file '\\testdb1\logship\log\logship_20190118070100.trn' is too recent to apply to the secondary database 'logship'

Searching for an older log backup file. Secondary Database: 'logship'

Skipped log backup file. Secondary DB: 'logship', File: '\\testdb1\logship\log\logship_20190118065900.trn'

skiped...

35、使用主庫的fullbackup搭建logshipping執行後，從庫已經restore了很多log，從庫再拿這個fullbackup基礎上的diff備份來restore，可以restore的。

使用主庫的fullbackup把logshipping搭建好後，就算主庫的backup log job執行了很久，從庫的restore log job執行了很多，從庫的restore log job還剩一下log沒有restore ，這時主庫執行backup diff，從庫可以使用這個backup diff恢復，恢復後，從庫的restore log job會跳過原來那些沒有restore 的log，只會restore 主庫執行backup diff之後主庫backup log job生成的log，但是前提是，這個diif是基於搭建logshipping時使用的fullbackup，否則報錯This differential backup cannot be restored because the database has not been restored to the correct earlier state.

36、如果logshipping的日誌備份放在共享儲存上，且從庫不複製到本地路徑而是直接讀共享儲存上該檔案的場景，一旦遇到主庫的backup log job因為網路中斷，而導致檔案沒法寫，這是主庫的backup log job會卡很久大概10來個小時，如果手工停掉了主庫的backup log job。或主庫的backup log job執行時間很長，因為日誌特別大，這個時候因為特殊事情比如alter database add datafile操作，需要關閉backup，手工停掉了主庫的backup log job。會發現和上面27的場景不一樣，這時候檔案存在了共享儲存上，而且失敗的job中不會提示檔案不存在的現象，而且沒有END OF TRANSACTION LOG BACKUP這些關鍵字，所以不知道事務是否真正結束???。暫把這個檔案稱為A，後面主庫重新生成的檔案不知道包含還是不包含這個檔案A的所有資訊???而且從庫的restore log job會讀這個A檔案，讀這個A檔案的時候從庫Management-->SQL Server Logs裡面可以看到A檔案損壞的資訊。個人認為這種情況下這個A檔案沒有截斷日誌，這個事務正常回滾了，因為真實場景驗證過使用A檔案的下一個檔案可以正常手工執行restore log。見下面"正式環境遇到的問題"4

37、在主庫的logshipping配置裡面修改job的schedule時間和直接在job裡面修改schedule時間一樣。

38、主庫升級後，可以修改level，從庫升級後，無法修改level，但是主庫的日誌同步到從庫後，從庫對應的資料庫的level會和主庫一樣

39、主庫新增datafile後，從庫也會新增datafile，並且路徑和主庫的路徑一樣

40、從庫restore log job執行過程中，restore某個日誌遇到了too recent，表示這個日誌太新了，這個日誌的最小lsn大於從庫的當前lsn，restore某個日誌遇到了too early，表示這個日誌太舊了，這個日誌的最大lsn小於從庫的當前lsn

41、相對從庫loggshipping最後一次成功恢復日誌的記錄而言，從庫重新restore database後的資料庫太新，這樣已經存在的一些logshipping的日誌就太舊，從庫restore log job會skip日誌往新的日誌備份包查詢，直到找到了和從庫最新lsn接上的logshipping日誌後，從庫開始正常restore log

比如：logshipping從庫的restore log job一直報錯，最後一次成功恢復的日誌是DB_7.trn，下一次的日誌應該是DB_8.trn，但是這個DB_8.trn日誌一直無法恢復成功，retore log job連續好幾天都如此反覆識別。這樣我們就可以在從庫重新restore主庫最新的資料庫備份，讓恢復後的從庫的當前lsn大於DB_8.trn的最大lsn即可，這樣從庫的restore log job就會跳過DB_8.trn這個日誌備份包

42、相對從庫loggshipping最後一次成功恢復日誌的記錄而言，從庫重新restore database後的的資料庫太舊，這樣已經存在的一些logshipping的日誌太新，從庫restore log job會skip日誌往舊的日誌備份包查詢，直到找到了和從庫最新lsn接上的logshipping日誌後，從庫開始正常restore log

43、loggshipping從庫的restore log job從頭至尾都是報錯skip log，都沒有出現上面41、42場景所對應的logshipping從庫最後一個成功的restore 的log

現象：restore log job是1:00開始執行，9:00結束，顯示執行成功，日誌記錄是skip 第一個日誌開始直到skip最後1:00的一個日誌，restore log job第二次10:00執行時，日誌記錄還是skip 第一個日誌開始直到skip最後10:00的一個日誌。

原因：個人覺得原因是從庫進行restore database時出問題了，恢復的從庫有問題，從庫的最後LSN不確定，從庫的restore log job才會一個個日誌skip直到最後生成的一個logshipping log，下一次restore log job執行還是這樣，從skip 1到最新生成的一個日誌，迴圈往復。如果是restore database後，對應的第一個日誌不存在，後面的第二個日誌開始不是報skip，而是報資料庫太舊，而該日誌太新了

解決方法：不關閉logshipping配置，重新備份主庫，拿最新的備份到從庫進行還原

解決實踐：比如主庫8:00進行備份，備份包為A，12:00備份完成，14:00從庫恢復備份包A，這個時候可以進入從庫的日誌複製路徑(主庫生成loggshipping日誌在主庫路徑，從庫複製過來到從庫的路徑)，刪除7:00之前logshipping生成的日誌備份，從庫restore log job執行時找到第一個日誌就是7:00的這個日誌，會skip這個日誌，直到找到8:00的loggshipping日誌，開始restore。此過程中，如果還是遇到一直skip的問題，也可以使用7:00的logshipping的日誌進行手工restore log，應該會報錯，提示日誌太舊，繼續使用8:00、9:00的logshipping的日誌進行手工restore log，直到成功，這樣從庫restore log job執行時，會skip跳過7:00、8:00、9:00日誌，成功提示found first log backup file to restore，進而成功進行入restore

44、如果logshipping的日誌備份放在共享儲存上，且從庫不複製到本地路徑而是直接讀共享儲存上該檔案的場景，一旦遇到主庫的backup log job因為網路中斷，而導致檔案沒法寫，這是主庫的backup log job會卡很久大概10來個小時，如果手工停掉了主庫的backup log job，發現和上面27的場景不一樣，這時候檔案存在了共享儲存上，而且失敗的job中不會提示檔案不存在的現象，而且沒有END OF TRANSACTION LOG BACKUP這些關鍵字，所以不知道事務是否真正結束???。暫把這個檔案稱為A，後面主庫重新生成的檔案不知道包含還是不包含這個檔案A的所有資訊???而且從庫的restore log job會讀這個A檔案，讀這個A檔案的時候從庫Management-->SQL Server Logs裡面可以看到A檔案損壞的資訊

個人認為：遇到這個問題，最好不要手工去關閉主庫的backup log job，但是如果如果不關閉，可能job卡住時間太長，比如此案例達10小時。

解決方法：

1、手工restore這個壞檔案之後的一個檔案，如果restore成功，則把這個壞檔案重新命名，使從庫的restore log job跳過這個檔案，真實環境驗證過一次可行。

2、如果上面1失敗了，則只能恢復主庫的full+diff備份到從庫，diff備份必須是這個損壞A檔案結尾LSN之後的diff備份，真實環境驗證過一次可行。

45、dblog_1.trn和dblog_2.trn都實際存在，主庫backup提示前者備份失敗(主庫下一個job排程時沒有任何關於這個檔案的資訊，直接是檔案dblog_2.trn)，從庫restore的時候查到前者格式不對自動跳過

46、logshipping主從庫都進行了升級，從庫的restore log job出現如下報錯，只能重新對從庫進行full backup恢復，但是不用拆掉logshipping也不需要重新配置

2019-01-26 20:35:23.00 *** Error: Could not apply log backup file '\\logship\LOG\Backups_20190125121503.trn' to secondary database 'Backups'.(Microsoft.SqlServer.Management.LogShipping) ***

2019-01-26 20:35:23.00 *** Error: SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:1536251; actual 1:864359). It occurred during a read of page (1:1536251) in database ID 14 at offset 0x000002ee1f6000 in file 'G:\DEFAULT.DATA\Backups.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

RESTORE LOG is terminating abnormally.

Processed 0 pages for database 'Backups', file 'Backups' on file 1.

Processed 3273 pages for database 'Backups', file 'Backups_log' on file 1.(.Net SqlClient Data Provider) ***

47、如果主庫的backup log job的檔案存放路徑和從庫copy job的檔案存放路徑一樣，則主庫的backup log job和從庫copy job限制的檔案delete日期都有效，哪個先觸發刪除條件，哪個就開始delete

48、從庫應用日誌發現日誌格式錯誤，也會跳過這個日誌

2019-02-21 06:54:01.26 *** Error: Could not apply log backup file '\\logship\LOG\dblog_1.trn' to secondary database 'npdb2_1'.(Microsoft.SqlServer.Management.LogShipping) ***

2019-02-21 06:54:01.26 *** Error: The file ID 1 on device '\\logship\LOG\dblog_1.trn' is incorrectly formed and can not be read.

RESTORE LOG is terminating abnormally.(.Net SqlClient Data Provider) ***

2019-02-22 02:26:21.60 Skipping log backup file '\\logship\LOG\dblog_1.trn' for secondary database 'db' because the file could not be verified.

49、logshipping配置介面，重新配置了backup log job和restore log job的scheduler，但是隻發現主庫上的backup log job的scheduler正常修改了，從庫的restore log job的scheduler沒有變化，除非自己手工去從庫上修改restore log job的scheduler

50、logshipping主庫增加資料檔案或日誌檔案，但是從庫沒有相應的目錄，則從庫的restore log job會報錯，就算從庫有預設的datafile和logfile路徑，從庫的restore log job有如下報錯資訊

File 'logship2' cannot be restored to 'L:\20190401\logship2.ndf'. Use WITH MOVE to identify a valid location for the file.

Directory lookup for the file "L:\20190401\logshiplog2.ldf" failed with the operating system error 2(The system cannot find the file specified.).

File 'logshiplog2' cannot be restored to 'L:\20190401\logshiplog2.ldf'. Use WITH MOVE to identify a valid location for the file.

51、FILETABLE的資料庫搭建logshipping，從庫是norecovery模式時，從庫看不到檔案系統目錄。從庫是standby read only模式時，從庫可以檢視透過下面三條語句檢視到檔案系統目錄。但是兩種模式下，從庫都無法直接進入\\SERVERNAME\FILESTREAM_SHARE_NAME\FILESTREAM_DIRECTORY_NAME\FILETABLE_DIRECTORY目錄

從庫是standby read only模式時，在從庫右鍵FILETABLE表，看到Explore FileTable Directory是灰色，無法檢視。

查詢資料庫FILESTREAM功能的DIRECTORY_NAME
select db_name(database_id),* from sys.database_filestream_options
查詢FILETABLE表的DIRECTORY_NAME
select object_name(object_id),* from sys.filetables
查詢filetable表testdb.dbo.table1中的檔案完整路徑名稱
SELECT FileTableRootPath()+[file_stream].GetFileNamespacePath(),name FROM testdb.dbo.table1

52、logshipping搭建成standby 模式時，從庫也是正常restore lob job來實現資料和主庫的同步的，並不是說從庫這個時候狀態是隻讀，就無法應用日誌。一開始初始化從庫的時候也是norecover模式，從庫狀態顯示restoreing，一旦從庫應用完第一個日誌後，從此時開始從庫狀態顯示Standby/Read-Only，從庫顯示為Standby/Read-Only後可以繼續應用主庫的日誌

53、關於mirror和logshipping的選擇，遇到資料庫在短時間內產生的日誌很大，比如15分鐘內產生了500MB，

那麼mirror不如logshipping，因為mirror需要消耗更多的記憶體，mirror很容易出現suspend的狀態

54、當然logshipping的restore log job比正常手工的restore log慢很多，親測過，500MB的日誌，

手工backup命令備份出來（備份時長大概20秒）的格式再手工restore命令恢復只需要40秒，

但是logshipping 的backup job備份出來（備份時長大概20秒）的格式在使用logshipping restore job需要3分鐘。

55、Always on的輔助節點的資料庫wdb1配置了logshipping，這個wdb1對應的LSBackup作業突然報錯，報錯資訊如下
2020-09-08 09:15:05.55    First attempt to backup database 'wdb1' to file '\\log.hbank.com\WONDB\LOG\wdb1_20200908161504.trn' failed because Log backup for database "wdb1" on a secondary replica failed because the last backup LSN (0x00752347:00036eb5:0001) from the primary database is greater than the current local redo LSN (0x00752344:011b9f14:0176). No log records need to be backed up at this time. Retry the log-backup operation later.

解決方法：只能等Always on的主節點的日誌都在輔助節點應用完畢，這個時候Always on的輔助節點的資料庫wdb1的LSBackup作業才會自動恢復正常

56、一個logshipping的從庫的伺服器名稱明明是IBDC3DBALIASAWS，但是生成的LSAlert_XX居然是LSAlert_DBPROD115，然後生成的LSRestore_masternode_C3InterfaceDB執行總是報錯說Failed to connect to server DBPROD115，檢視LSRestore_masternode_C3InterfaceDB的程式碼"C:\Program Files\Microsoft SQL Server\120\Tools\Binn\sqllogship.exe" -Restore XX -server DBPROD115，然後把DBPROD115改成masternode再執行LSRestore_masternode_C3InterfaceDB報錯The specified agent_id YY or agent_type 1 do not form a valid pair for log shipping monitoring processing，把"C:\Program Files\Microsoft SQL Server\120\Tools\Binn\sqllogship.exe" -Restore XX -server masternode裡的masternode再改成DBPROD115後正常了。 執行select @@servername,SERVERPROPERTY('machinename')才發現servername是DBPROD115，然後machinename是IBDC3DBALIASAWS，得出結論logshipping在從庫生成的所有資訊都是以從庫的servername來定義的，而不是從庫的machinename來定義的

57、log shipping選擇standby mode的時候如果勾選了Disconnect users in the database when restoring backups，則從庫restore日誌job執行的時候會把已經連線的會話斷開，job步驟裡有一步Disconnecting users. Secondary DB: 'DBNAME'，會話重新連線的時候如果restore沒有完成就會報如下錯誤：The connection is broken and recovery is not possible.  The client driver attempted to recover the connection one or more times and all attempts failed.  Increase the value of ConnectRetryCount to increase the number of recovery attempts.
如果沒有勾選Disconnect users in the database when restoring backups，則從庫restore日誌的時候不會把已經連線的會話斷開，此時如果有會話連上了這個資料庫，這restore日誌的job會報錯 Exclusive access could not be obtained because the database is in use. 如果資料庫正在restoring的狀態，我們無法連線資料庫，會報錯Database 'XX' cannot be opened. It is in the middle of a restore