官方文档https://docs.microsoft.com/zh-cn/sql/database-engine/log-shipping/about-log-shipping-sql-server?view=sql-server-2017
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.