ITPub博客

首页 > 数据库 > SQL Server > sqlserver关于日志传输log shipping的总结

sqlserver关于日志传输log shipping的总结

原创 SQL Server 作者:lusklusklusk 时间:2019-03-27 22:14:55 0 删除 编辑

官方文档

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来定义的

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30126024/viewspace-2639526/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Welcome to Lukes DB HOME。 Oracle OCM、Mysql OCP, 8年以上DBA工作经验,博客仅记录自己的一个学习过程,不代表完全准确,如有需要,欢迎转载。

注册时间:2015-02-02

  • 博文量
    435
  • 访问量
    767256