sqlserver關(guān)于日志傳輸log shipping的知識點有哪些

這篇文章主要講解了“sqlserver關(guān)于日志傳輸log shipping的知識點有哪些”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“sqlserver關(guān)于日志傳輸log shipping的知識點有哪些”吧！

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

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

3、主庫導(dǎo)出的trn格式的日志文件，這些文件拷貝到從庫時，也是trn格式的日志文件

4、主庫生成2個job，一個alert，一個backup，alert調(diào)用存儲過程sys.sp_check_log_shipping_monitor_alert，backup調(diào)用sqllogship.exe命令，每搭建一個logshipping，主庫就生成一個backup job，alert job不會再增加

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

6、可以設(shè)置主庫的網(wǎng)絡(luò)備份目錄、主庫的本地備份目錄、從庫的拷貝目錄都是設(shè)置成網(wǎng)絡(luò)上的同一個目錄

7、如果采用上面6的模式，則可以關(guān)閉從庫的copy job，不影響log shipping

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

9、logshipping正常同步的過程中，如果主庫手工做了一次backup log的備份，那么日志被截斷了，從庫logshipping的restore log job會開始報錯，找不到需要恢復(fù)的日志，此時主庫的backup log job和從庫的copy job仍然正常運行(比如bakcup log job每小時執(zhí)行一次，8:00開始執(zhí)行，8:30手工突然執(zhí)行了一次backup log，9:00執(zhí)行backup log job的時候的日志就只有8:30-9:00的了，而從庫需要8:00-9:00的日志，這樣loggshipping從庫的restore log job就報錯了)

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

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

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

個人實驗過2：行，從庫直接使用8:30的日志備份進行restore ，可以restore成功，后續(xù)從庫的restore log job正常運行

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

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、主服務(wù)器上的完整備份不影響logshipping，因為完整備份不會截斷日志

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

15、查看logshipping是否正常，可以右鍵實例-->Reports-->Standard Reports-->Transaction Log Shipping Status,主庫只顯示主庫的狀態(tài)，從庫只顯示從庫的狀態(tài)，所以必須要同時登錄主庫和從庫進行檢查

16、刪除logshipping，則只要登錄主庫實例，右鍵數(shù)據(jù)庫-->Properties-->Transaction Log Shipping-->取消勾選Enable this as a primary database in a log shipping configuration，刪除后，主庫和從庫的job都自動刪除了，就算job被disable禁用了，也會被自動刪除掉

17、刪除logshipping后，要恢復(fù)從庫為讀寫狀態(tài)

如果從庫原來狀態(tài)圖標是顯示綠色小箭頭restoring，執(zhí)行如下

RESTORE DATABASE [testdb] with recovery

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

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，并且要導(dǎo)出原來主庫的一些業(yè)務(wù)job放在從庫上執(zhí)行，因為logshipping不會同步j(luò)ob

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

20、8:30開始搭建logshipping，此過程中，如果8:30主庫執(zhí)行了一次日志備份截斷了日志，那么從庫只使用主庫8:00的全備份還能搭建成功嗎?從搭建開始到結(jié)束都不會報錯，這點不同于mirror，但是搭建成功后無法正常同步，假設(shè)8:35搭建成功，主庫開始執(zhí)行backup log job，主庫backup log job和從庫copy job、restore log job都正常執(zhí)行，但是從庫的報表Transaction Log Shipping Status會出現(xiàn)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可以看到有多少個數(shù)據(jù)庫搭建了logshipping，以后日志備份的腳本里面可以排除這些數(shù)據(jù)庫，就是這些數(shù)據(jù)庫就不備份日志了，以免截斷這些數(shù)據(jù)庫的日志

22、如果主庫備份過程中比如備份到網(wǎng)絡(luò)路徑，備份了一半突然網(wǎng)絡(luò)中斷了，bakcup log job不會馬上停止只是會報錯，當網(wǎng)絡(luò)好了，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重新執(zhí)行正常，不會說前面restore 了一半，后面就無法接上了。這樣情況和上面22一樣，文件在網(wǎng)絡(luò)上，restore 了一半，后面網(wǎng)絡(luò)中斷了，之后重新運行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同步發(fā)生問題，但是logshipping的日志都沒有丟，直接使用主庫的備份在從庫執(zhí)行restore databae恢復(fù)即可，執(zhí)行這個restore databae之前，不需要取消主庫的logshipping配置，但是最好把從庫的restore log job停止并禁用，等恢復(fù)好了再啟用這個job

26、主庫有full、diff的備份，也有diff之前的一個loggshipping日志和之后的所有l(wèi)ogshipping的日志，經(jīng)過實驗和生產(chǎn)環(huán)境驗證，從庫重新恢復(fù)使用full和diff備份后，從庫的restore log job會skip掉diff之前的log，后面的會restore，說明從庫的restore log job會使用從庫的最新的LSN去找需要的log進行恢復(fù)

27、如果主庫的backup log job是把日志備份到網(wǎng)絡(luò)路徑上，如果生成過程中遇到網(wǎng)絡(luò)故障，會報錯，文件不會生成，日志不會截斷，下一次主庫的backup log job運行過程中會重新接上次的LSN點繼續(xù)生成文件。比如這個job是1小時運行一次，8:00生成過程中報錯，那么8點的job會回滾，8點的文件不會生成，LSN還是上次7:00點正常backup log job截斷的LSN，那9:00生成的時候，就是7:00-9:00的數(shù)據(jù)，這樣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重建，不需要關(guān)閉logshipping，只需要把從庫進行數(shù)據(jù)庫恢復(fù)即可，restore database+restore diff就可以了，logshipping的restore log job 會自動找到diff備份后面的第一個logshipping生成的log進行restore，如果嫌從庫的logshipping的restore log job運行太慢，可以在從庫手工restore主庫backup log job生產(chǎn)的備份，此時從庫先禁用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期間在主庫上手工執(zhí)行backup log了，之后logshipping主庫繼續(xù)生成logshipping格式的日志，之后重新備份主庫，之后logshipping主庫繼續(xù)生成logshipping格式的日志，從庫利用主庫的數(shù)據(jù)庫備份進行restore database，再加上主庫備份數(shù)據(jù)庫之后生成的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主庫重新備份數(shù)據(jù)庫，9:00從庫利用主庫的備份包進行還原，這個時候logshipping的從庫需要8:40之后的logshipping格式的日志，而這些日志都是有的，是可以正常logshipping的

32、logshipping模式下，不管主庫還是從庫，上面的job都是事務(wù)狀態(tài)，如果手工停止，說明事務(wù)不成功，會回滾，不用擔(dān)心

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

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

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

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

33、主庫的backup job暫停，手工拷貝或創(chuàng)建log文件到從庫，看從庫的restore job是否異常

1、如果拷貝從庫restore記錄的最后一個log文件之后的第一個文件，比如是logship_20190118061000.trn，則從庫的restore log正常restore logship_20190118061000.trn，log日志里面不會報錯，restore jog正常結(jié)束

2、如果拷貝從庫restore記錄的之前的一個log文件，比如copy logship_20190118060800.trn，則從庫的restore log無法restore

logship_20190118060800.trn，log日志里面會報錯，但是restore jog正常結(jié)束

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正常結(jié)束

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不正常結(jié)束

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正常,經(jīng)測試，發(fā)現(xiàn)從庫restore log job是按日志的生成名稱來恢復(fù)的，找到正確的名稱后，如果發(fā)現(xiàn)這個名稱之后生成的trn日志都恢復(fù)了，那么報錯，見下面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的文件改名，往前面的時間改，并越過最后一個已經(jīng)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運行后，從庫已經(jīng)restore了很多l(xiāng)og，從庫再拿這個fullbackup基礎(chǔ)上的diff備份來restore，可以restore的。

使用主庫的fullbackup把logshipping搭建好后，就算主庫的backup log job執(zhí)行了很久，從庫的restore log job執(zhí)行了很多，從庫的restore log job還剩一下log沒有restore ，這時主庫執(zhí)行backup diff，從庫可以使用這個backup diff恢復(fù)，恢復(fù)后，從庫的restore log job會跳過原來那些沒有restore 的log，只會restore 主庫執(zhí)行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因為網(wǎng)絡(luò)中斷，而導(dǎo)致文件沒法寫，這是主庫的backup log job會卡很久大概10來個小時，如果手工停掉了主庫的backup log job?；蛑鲙斓腷ackup log job執(zhí)行時間很長，因為日志特別大，這個時候因為特殊事情比如alter database add datafile操作，需要關(guān)閉backup，手工停掉了主庫的backup log job。會發(fā)現(xiàn)和上面27的場景不一樣，這時候文件存在了共享存儲上，而且失敗的job中不會提示文件不存在的現(xiàn)象，而且沒有END OF TRANSACTION LOG BACKUP這些關(guān)鍵字，所以不知道事務(wù)是否真正結(jié)束???。暫把這個文件稱為A，后面主庫重新生成的文件不知道包含還是不包含這個文件A的所有信息???而且從庫的restore log job會讀這個A文件，讀這個A文件的時候從庫Management-->SQL Server Logs里面可以看到A文件損壞的信息。個人認為這種情況下這個A文件沒有截斷日志，這個事務(wù)正?；貪L了，因為真實場景驗證過使用A文件的下一個文件可以正常手工執(zhí)行restore log。見下面"正式環(huán)境遇到的問題"4

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

38、主庫升級后，可以修改level，從庫升級后，無法修改level，但是主庫的日志同步到從庫后，從庫對應(yīng)的數(shù)據(jù)庫的level會和主庫一樣

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

40、從庫restore log job執(zhí)行過程中，restore某個日志遇到了too recent，表示這個日志太新了，這個日志的最小lsn大于從庫的當前l(fā)sn，restore某個日志遇到了too early，表示這個日志太舊了，這個日志的最大lsn小于從庫的當前l(fā)sn

41、相對從庫loggshipping最后一次成功恢復(fù)日志的記錄而言，從庫重新restore database后的數(shù)據(jù)庫太新，這樣已經(jīng)存在的一些logshipping的日志就太舊，從庫restore log job會skip日志往新的日志備份包查找，直到找到了和從庫最新lsn接上的logshipping日志后，從庫開始正常restore log

比如：logshipping從庫的restore log job一直報錯，最后一次成功恢復(fù)的日志是DB_7.trn，下一次的日志應(yīng)該是DB_8.trn，但是這個DB_8.trn日志一直無法恢復(fù)成功，retore log job連續(xù)好幾天都如此反復(fù)識別。這樣我們就可以在從庫重新restore主庫最新的數(shù)據(jù)庫備份，讓恢復(fù)后的從庫的當前l(fā)sn大于DB_8.trn的最大lsn即可，這樣從庫的restore log job就會跳過DB_8.trn這個日志備份包

42、相對從庫loggshipping最后一次成功恢復(fù)日志的記錄而言，從庫重新restore database后的的數(shù)據(jù)庫太舊，這樣已經(jīng)存在的一些logshipping的日志太新，從庫restore log job會skip日志往舊的日志備份包查找，直到找到了和從庫最新lsn接上的logshipping日志后，從庫開始正常restore log

43、loggshipping從庫的restore log job從頭至尾都是報錯skip log，都沒有出現(xiàn)上面41、42場景所對應(yīng)的logshipping從庫最后一個成功的restore 的log

現(xiàn)象：restore log job是1:00開始執(zhí)行，9:00結(jié)束，顯示執(zhí)行成功，日志記錄是skip 第一個日志開始直到skip最后1:00的一個日志，restore log job第二次10:00運行時，日志記錄還是skip 第一個日志開始直到skip最后10:00的一個日志。

原因：個人覺得原因是從庫進行restore database時出問題了，恢復(fù)的從庫有問題，從庫的最后LSN不確定，從庫的restore log job才會一個個日志skip直到最后生成的一個logshipping log，下一次restore log job運行還是這樣，從skip 1到最新生成的一個日志，循環(huán)往復(fù)。如果是restore database后，對應(yīng)的第一個日志不存在，后面的第二個日志開始不是報skip，而是報數(shù)據(jù)庫太舊，而該日志太新了

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

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

44、如果logshipping的日志備份放在共享存儲上，且從庫不拷貝到本地路徑而是直接讀共享存儲上該文件的場景，一旦遇到主庫的backup log job因為網(wǎng)絡(luò)中斷，而導(dǎo)致文件沒法寫，這是主庫的backup log job會卡很久大概10來個小時，如果手工停掉了主庫的backup log job，發(fā)現(xiàn)和上面27的場景不一樣，這時候文件存在了共享存儲上，而且失敗的job中不會提示文件不存在的現(xiàn)象，而且沒有END OF TRANSACTION LOG BACKUP這些關(guān)鍵字，所以不知道事務(wù)是否真正結(jié)束???。暫把這個文件稱為A，后面主庫重新生成的文件不知道包含還是不包含這個文件A的所有信息???而且從庫的restore log job會讀這個A文件，讀這個A文件的時候從庫Management-->SQL Server Logs里面可以看到A文件損壞的信息

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

解決方法：

1、手工restore這個壞文件之后的一個文件，如果restore成功，則把這個壞文件重命名，使從庫的restore log job跳過這個文件，真實環(huán)境驗證過一次可行。

2、如果上面1失敗了，則只能恢復(fù)主庫的full+diff備份到從庫，diff備份必須是這個損壞A文件結(jié)尾LSN之后的diff備份，真實環(huán)境驗證過一次可行。

45、dblog_1.trn和dblog_2.trn都實際存在，主庫backup提示前者備份失敗(主庫下一個job調(diào)度時沒有任何關(guān)于這個文件的信息，直接是文件dblog_2.trn)，從庫restore的時候查到前者格式不對自動跳過

46、logshipping主從庫都進行了升級，從庫的restore log job出現(xiàn)如下報錯，只能重新對從庫進行full backup恢復(fù)，但是不用拆掉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日期都有效，哪個先觸發(fā)刪除條件，哪個就開始delete

48、從庫應(yīng)用日志發(fā)現(xiàn)日志格式錯誤，也會跳過這個日志

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，但是只發(fā)現(xiàn)主庫上的backup log job的scheduler正常修改了，從庫的restore log job的scheduler沒有變化，除非自己手工去從庫上修改restore log job的scheduler

50、logshipping主庫增加數(shù)據(jù)文件或日志文件，但是從庫沒有相應(yīng)的目錄，則從庫的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的數(shù)據(jù)庫搭建logshipping，從庫是norecovery模式時，從庫看不到文件系統(tǒng)目錄。從庫是standby read only模式時，從庫可以查看通過下面三條語句查看到文件系統(tǒng)目錄。但是兩種模式下，從庫都無法直接進入\\SERVERNAME\FILESTREAM_SHARE_NAME\FILESTREAM_DIRECTORY_NAME\FILETABLE_DIRECTORY目錄

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

查詢數(shù)據(jù)庫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來實現(xiàn)數(shù)據(jù)和主庫的同步的，并不是說從庫這個時候狀態(tài)是只讀，就無法應(yīng)用日志。一開始初始化從庫的時候也是norecover模式，從庫狀態(tài)顯示restoreing，一旦從庫應(yīng)用完第一個日志后，從此時開始從庫狀態(tài)顯示Standby/Read-Only，從庫顯示為Standby/Read-Only后可以繼續(xù)應(yīng)用主庫的日志

53、關(guān)于mirror和logshipping的選擇，遇到數(shù)據(jù)庫在短時間內(nèi)產(chǎn)生的日志很大，比如15分鐘內(nèi)產(chǎn)生了500MB，

那么mirror不如logshipping，因為mirror需要消耗更多的內(nèi)存，mirror很容易出現(xiàn)suspend的狀態(tài)

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

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

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

感謝各位的閱讀，以上就是“sqlserver關(guān)于日志傳輸log shipping的知識點有哪些”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對sqlserver關(guān)于日志傳輸log shipping的知識點有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！