我需要在transactionlog文件中找到一些特定的事务,所以我使用了fn_dblog函数。但是函数只返回几行。同时,我的数据库的LDF文件至少是几千兆字节。
我知道fn_dblog函数只搜索日志的活动部分:
发布于 2018-01-23 15:22:12
参考资料:
我知道fn_dblog函数只是搜索日志的活动部分:但是这意味着什么呢?
日志文件从MinLSN到最后写入的日志记录的部分称为日志的活动部分,即活动日志。这是完成数据库全面恢复所需的日志部分。活动日志的任何部分都不能被截断。所有日志记录必须在MinLSN之前从日志的各个部分中截断。
下图显示了带有两个活动事务的事务结束日志的简化版本.检查点记录已压缩为单个记录。

LSN 148是事务日志中的最后一条记录。在处理记录在LSN 147的检查点时,Tran 1已经提交,Tran 2是唯一的活动事务。这使得Tran 2的第一个日志记录成为在上一个检查点时活动的事务的最古老的日志记录。这使得LSN 142成为Tran 2 ( MinLSN )的开始事务记录。
什么时候事务日志的一部分会变得不活跃?
在上面的例子中,一旦检查点(LSN147)发生,LSN141部分就变得不活跃。SQL server在虚拟日志文件块(称为VLF)中管理这些文件。
迈克·希尔维格( Mike Hillwig )著的什么甚低频
通常,日志截断在下列事件之后会自动发生,但由于某种原因而延迟的情况除外:
我怎样才能搜索不活跃的部分?
我不知道任何有文件记载的微软程序都会这样做。Paul在fn_dump_dblog文章中展示了一个名为这的无文档化过程。
有第三方产品,您可以使用。
其中之一是:
发布于 2018-01-23 15:26:22
你的努力的总体问题,尽管我赞扬它,是得到日志不是困难的部分。读取日志就是,因为它根本没有文档化。有第三方产品可以帮助你,但你阅读日志和问这些问题是不会有很好的结果。写这篇文章并不是为了让你延迟,只是为了表示日志不是人类的可读性很强,文档化的,或者是其他人用来浏览的。
有了这一点,以下几点将对你有所帮助:
我知道fn_dblog函数只搜索日志的活动部分:
除非你设置了正确的跟踪标志。我不打算重新发明轮子,在这里,保罗已经有一个关于这个的伟大的职位。
·但这意味着什么呢?
意思是如果没有TF,它就不会看到日志中不活跃的部分.不活动VLFs
事务日志的一部分何时变得不活跃?
当成功备份时,恢复(和/或依赖于恢复模型)不再需要它。请参阅上面的日志架构链接。
·我怎样才能搜索不活跃的部分?
看保罗的博客。
发布于 2018-01-23 15:21:26
假设您在FULL或BULK-LOGGED恢复模式下运行并引用事务日志截断事务日志截断:
在完整恢复模型或大容量日志恢复模型下,在日志备份中捕获所有日志记录之前,日志的非活动部分无法被截断。这是维护日志链所必需的--一系列日志记录具有完整的日志序列号序列(LSNs)。当您备份事务日志时,假设存在以下条件,日志将被截断:
至于您关于“以及如何搜索非活动部分?”的问题,有一篇广泛的文章读取服务器事务日志备份以查找发生事务的时间向您展示了如何使用无文档的命令fn_dump_dblog()来查找Server事务日志备份中的数据。
https://dba.stackexchange.com/questions/196021
复制相似问题