热线电话: 18611015007 分享到:
首页>新闻中心>详细内容

日志传送的监控和故障排查


  如何监控日志传送的运行状态?最直观的办法是使用SQL ServerManagement Studio中的报表。用户可以在SQL Server Management Studio中右键实例名,选择“报表”,然后选择“标准报表”,最后选择“事务日志传送状态”。

  最前面的”status”栏显示当前日志传送的运行状况,除此之外还能看到备份作业的配置,以及最后一次被成功备份的日志文件是哪个。但是复制作业和还原作业由于是运行在辅助服务器端的,它们的信息只能在辅助服务器上看到。

  如果在辅助服务器端打开这个报表的话,就可以看到辅助服务器上日志传送的状态。

  在辅助服务器端,除了日志传送的状态外,还能看到最后一个被复制的日志备份文件和最后一个被还原的日志备份文件。

  除了使用报表之外,直接在master数据库中执行存储过程sp_help_log_shipping_monitor也能获得同样的信息。如果查看这个存储过程的定义,可以发现它实际上查询的是以下两张表:

  msdb.dbo.log_shipping_monitor_primary

  msdb.dbo.log_shipping_monitor_secondary

  如果发现日志传送发生任何异常,可以充分利用这些报表或者存储过程所提供的信息来做进一步的判断。

  首先,要明确是什么异常导致了日志传送不能工作。由于日志传送完全是依靠几个SQLAgent的作业来执行工作的,所以第一步应该去查看那些作业的历史信息,从历史信息中可以大致了解遇到的是什么问题。

  查看作业历史信息的简单办法,当然是在SQL ServerManagement Studio里找到作业,并且直接选择查看该作业的历史信息。用命令的方式查询作业历史信息,可以选择的方法有:

  1. 在主服务器和辅助服务器上执行查询select *from [msdb].[dbo].[sysjobs] where category_id = 6。获得所有日志传送作业的作业ID。然后查询msdb..sysjobhistory中对应的作业历史信息,查看具体的错误。这个方法比较传统,即使对日志传送的系统表不熟悉也可以使用。

  2. 在主服务器,辅助服务器和监视服务器(如果有的话)上执行查询SELECT* FROM [msdb].[dbo].[log_shipping_monitor_history_detail]。这个表会包含日志传送相关作业的历史信息。其中也自然包含出现错误作业执行以及详细的错误信息。

  3. 在主服务器,辅助服务器和监视服务器(如果有的话)执行查询SELECT* FROM [msdb].[dbo].[log_shipping_monitor_error_detail]。这个表包含所有出现错误的日志传送作业的历史信息。

  用这些方法,可能可以得到更准确的信息。有了错误信息,接下来该怎么做就会有思路了。

  这里先来明确两个问题。理解这两个问题,会有助于您找到解决日志传送问题的关键。

  1) 复制作业是如何知道当前应该复制哪个日志备份文件的?

  由于备份作业只会定期清理一段时间以前的日志备份,因此在共享目录中,一定会存在一些已经被复制到辅助服务器端的日志备份。总不见得每次都把目录中所有的文件都复制一遍吧?这个时候,复制作业其实是根据日志备份的文件名来判断应该复制哪些文件的。你会发现备份作业生成的日志备份的文件名格式是“主服务器名_<时间戳>”。这里的时间戳其实就是备份文件生成的时间。另外,在辅助服务器的MSDB数据库中会记录最近一次被复制的日志备份文件是什么。查询log_shipping_secondary表,就能够得到被复制的文件名,以及是什么时间做的复制。日志传送会检查共享目录中所有文件的文件名,比较辅助服务器上的记录。只有文件名中的时间戳大于最近一次被复制的文件的时间戳,文件才会被复制作业复制到辅助服务器上。

  2) 还原作业如何决定应该还原哪个文件?

  和第一个问题类似,它也是简单地使用了时间戳的比较。在MSDB中会记录最近一次被还原的备份文件名。查询log_shipping_secondary_databases这张系统表,就可以看到最近一次日志备份文件执行还原操作的时间。

  通常来说,日志传送发生的问题大部分出现在日志传送执行复制作业和还原作业的时候。如果备份作业出现问题,通常只需要把它当做一个单纯的备份失败问题进行处理就行了。

  复制和还原这两步,出问题相对比较麻烦。和复制作业相关的问题,通常会有以下三类问题:

  1. 权限问题。复制作业没有权限访问存放日志备份的共享目录;或者复制作业无法写入辅助服务器上的本地目录。这个时候要检查辅助服务器上的SQLServer Agent启动账号是否具有访问相应目录的权限。

  2. 共享目录不存在。有可能是该目录被移走了,或者没有被共享。也可能是由于网络原因导致访问失败(比如DNS解析问题等)。

  3. 日志备份文件名被人为修改了,时间戳小于了最近一次被复制的文件的时间戳,导致备份文件无法被复制作业复制到辅助服务器端。

  和还原作业相关的问题会相对更复杂一些。常见的会有以下四类:

  1. 还原作业无法访问日志备份文件,因为该文件正在被其他进程使用。

  这时您可以使用Process Explorer工具(可以在微软的网站免费下载)来查看是什么进程正在使用日志备份文件。如果Process Explorer无法找到使用该文件的进程,而且这个问题只是偶尔发生,有可能是服务器上有杀毒软件或者监控软件。当这些软件正在扫描到日志备份文件的时候,这个文件就不能被还原作业使用了。

  2. 还原作业没有权限读取本地目录中的日志备份文件。这种情况你只需要去检查辅助服务器上的SQLServer Agent启动账号对本地目录和其中文件的访问权限即可。

  3. 日志备份文件损坏无法还原。您可以尝试手动把该日志 备份文件从主服务器再次复制到辅助服务器上,然后运行一个restore命令来还原这个日志备份。如果依然还是得到同样的错误,那说明那个日志备份文件本身已经发生了损坏。这时别无选择,只能重建日志传送。

  4. 日志备份文件的LSN不在允许还原的范围内。在还原时,一个有效的日志备份文件,它的起始LSN一定不大于辅助数据库的最末LSN;日志备份文件的最末LSN一定大于辅助数据库的最末LSN。您可以使用下面的办法来获取LSN的信息。

  (1) 在主数据库上运行语句:

  SELECTDISTINCTs.first_lsn,s.last_lsn,s.backup_finish_date,y.physical_device_name

  FROM msdb..backupset AS s INNER JOIN

  msdb..backupfile AS f ON f.backup_set_id =s.backup_set_id INNER JOIN

  msdb..backupmediaset AS m ON s.media_set_id= m.media_set_id INNER JOIN

  msdb..backupmediafamily AS y ONm.media_set_id = y.media_set_id

  WHERE (s.database_name = 'xxxx') ORDER BY s.backup_finish_date DESC;

  这样可以得到每个日志备份文件的起始LSN和最末LSN。

  (2) 在辅助服务器上运行restore headeronly来检查日志备份文件的起始LSN和最末LSN。

  (3) 运行DBCC DBTABLE ('数据库名‘)命令来获得数据库的最末LSN。

  如果发现备份文件的起始LSN大于数据库的最末LSN,就是个典型的日志不连续的状态。此时可以使用步骤(1)中的查询来找到正确的备份文件,该文件具有和辅助数据库连续的LSN。找到有这样一个文件后,接下来就要研究为什么还原作业没有去还原这个日志备份文件,而是去直接还原更晚产生的日志备份文件?最可能的情况,是那个具有正确LSN的备份文件不是由日志传送生成,而是由某人手动执行备份命令生成。这样手动生成的备份文件,要么是文件名没有时间戳信息,要么是备份文件没有被放在到日志传送的共享目录。无论什么原因都会导致复制作业忽视了这个文件,没有把它复制到辅助服务器上。

  对于启用日志传送的数据库,任何手动的日志备份都会破坏日志传送的工作。如果找不到手动生成的备份文件,那日志传递链条就此中断,就只能重建整个日志传送。这点是管理数据库的时候要特别注意的。此外,对已经启用了日志传送任务的数据库,配置维护计划要特别注意,不能在维护计划中创建事务日志备份。你可以在维护计划中执行完整数据库备份和差异数据库备份,这些是不会与日志传送产生冲突的。


想了解更多?欢迎联系我们
服务邮箱 fei@bjjyhx.cn
周一至周五:9:00-18:00
热线电话 18611015007
周一至周五:9:00-18:00

在线表单

为了便于我们更好的为您服务,情正确填写一下信息,我们会在24小时内与您取得联系,并答复您的需求!

公司名称*
联  系  人*
联系电话*
详细地址*
产品描述*
留言内容*