sqlserver关于日志传输logshipping的知识点有哪些

这篇文章主要讲解了“sqlserver关于日志传输log shipping的知识点有哪些”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“sqlserver关于日志传输log shipping的知识点有哪些”吧！

创新互联是一家做网站、网站建设，提供网页设计，网站设计，网站制作，建网站，按需网站制作，网站开发公司，于2013年创立是互联行业建设者，服务者。以提升客户品牌价值为核心业务，全程参与项目的网站策划设计制作，前端开发，后台程序制作以及后期项目运营并提出专业建议和思路。

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就报错了)

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: 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分钟。

感谢各位的阅读，以上就是“sqlserver关于日志传输log shipping的知识点有哪些”的内容了，经过本文的学习后，相信大家对sqlserver关于日志传输log shipping的知识点有哪些这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！

文章题目：sqlserver关于日志传输logshipping的知识点有哪些
标题链接：http://myzitong.com/article/jododi.html

sqlserver关于日志传输logshipping的知识点有哪些

其他资讯