我们有一个相对简单的 SQL Server 2008 数据库 (30 MB) 的大事务日志 (1.3 GB)。它 (日志) 包含自数据库首次投入生产以来的所有更新，并且 (现在我们看到它) 代表了我们感兴趣的宝贵时间数据源。
是否有某种方法可以在类似的数据库上“重播”整个日志（像原始数据库，但添加了历史表和触发器）？
这样，我们就可以重建相同的数据库，但时间数据是从日志中“提取”的。这是我们第一次忽略的宝贵知识，不应依赖于服务器日志文件。
更新
我是不是遇到“大型”事务日志的问题。我不想截断日志。其中包含的时间信息很有价值（我真诚地希望现在一切都清楚了，因为这是我第三次重复）。
对于“西方最快的枪手”，请在上面的“我们有一个很大的事务日志……”之后继续阅读。我开始认为用这些话开始提问实际上是我的错，因为看起来 80% 的读者认为这个问题是关于日志截断的。
对于那些希望“建议”另一种备份和日志截断作为“解决方案”的人（顺便说一句，完全没有抓住重点），请阅读此文。
答案1
事务日志包含自上次日志截断以来应用于数据库的修改的二进制增量；这里的关键字是“二进制”：它们不包含 SQL 查询或类似内容，但实际上更类似于应用于程序的二进制补丁。
因此，它们只能在它们最初链接到的精确物理数据库文件上重播；在另一个数据库上重播它们（即使具有相同的模式）就像将补丁应用到与其编写的可执行文件不同的可执行文件上：根本不可能。
你也无法在相同的数据库，如果被修改了；也就是说，您无法从旧备份中还原数据库，使其联机，对其进行任何修改，然后重播针对它的日志；一旦将数据库完全联机，您实际上就会失去任何日志重播功能（SQL Server 还原操作中甚至有一个特定标志）。
答案2
这里他们说：
请注意，您可以转储当前的使用未记录的 DBCC 命令的日志文件：
DBCC LOG('<dbname>', [<option>])其中
<option>是 1 到 4 之间的整数，它控制 DBCC LOG 显示的信息的详细程度。
如果我对我的一个数据库执行此操作，我会获得大量信息，但我认为不足以重播日志。
在其他帖子中，他们提到了这些可能解决您的问题的产品：
答案3
重读了您的帖子几次后，我认为您应该寻找一些第三方日志分析工具。
如果您有 SQL Server 2000，RedGate SQL 日志救援工具是免费的。我还没有找过其他工具，但我确信有一些。
答案4
澄清后重写的问题
我投票将其移至 serverfault.com。他们需要告诉你，你误读了 Truncate_Only 的备份日志：就像一个 Bear Trap。请注意关于“仅截断“。
请参阅与第一篇文章链接的“收缩数据库”，阅读并理解它。这并不是说您永远不应该截断日志：而是您应该只结合完整备份、事务日志备份和可能的差异备份的适当计划来截断它们。
一旦日志被安全备份，就不再需要将其保留在磁盘上。但是，我不是 DBA，我认为您可能需要听取专家的意见才能理解这一点，所以我投票赞成这样做。