对于相对简单的SQL Server 2008数据库（30 MB），我们有一个很大的事务日志（1.3 GB）。 它（log）包含自db第一次投入生产以来的所有更新，并且（现在我们看到它）代表了对我们有意义的时间数据的宝贵来源。
有一些方法可以在类似的数据库上“重放”整个日志（比如原始的，但添加了历史表和触发器）？
这样我们可以重build相同的数据库，但从日志中提取“时间”数据。 这是我们第一次忽略的有价值的知识，不应该停留在服务器日志文件上。
UPDATE
我没有任何问题与“大”的事务日志。 我不想截断日志。 包含在其中的时间信息是有价值的 （ 我真诚地期望现在会清楚，因为这是我第三次重复它 ）。
对于那里的“西部最快枪手”，请继续上面的“我们有一个大交易logging…”后继续阅读。 我开始认为，实际上我的错误是用这些词开始提问，因为似乎有80％的读者认为这个问题是关于日志截断的。
对于任何人可能希望“build议”另一个备份和日志截断作为“解决scheme”（顺便说一句，完全错过了这一点），请阅读。
事务日志包含自上次日志截断以来应用于数据库的修改的二进制增量; 这里的关键字是“二进制”：它们不包含SQL查询或类似的东西，但实际上更类似于应用于程序的二进制补丁。
出于这个原因，它们只能在它们最初链接的确切的物理数据库文件上重放; 在另一个数据库（甚至是相同的模式）上重播它们就像是将一个补丁应用于不同的可执行文件到它所写的补丁：完全不可能。
如果被修改，你也不能在同一个数据库上重放它们; 即不能从旧备份中恢复数据库，使其联机，对其进行任何修改，然后重播日志; 只要将数据库完全联机（甚至在SQL Server还原操作中有一个特定的标志），实际上就会失去任何日志重放function。
他们在这里说：
请注意，您可以使用未logging的DBCC命令来转储当前日志文件的内容：
DBCC LOG('<dbname>', [<option>])其中
<option>是1到4之间的整数，用于控制DBCC LOG显示的信息的详细程度。
如果我用我的数据库的一个这样做，我得到了很多的信息，但我认为不足以重播日志。
在其他职位，他们提到这些产品可以解决你的问题：
重新阅读你的post几次后，我会说你应该寻找一些第三方的日志分析工具。
如果你有Sql Server 2000，那么RedGate SQL Log Rescue工具是免费的。 我没有find其他工具，但我确定有一些。
去购买第三方软件来获得交易，因为RESTORE LOG显然不符合您的更改（如最初build议的那样）。
此外，如果您真的想重新运行一堆事务，则应该使用SQL Server Profiler。 但是，这个计划很糟糕，所以你会掏腰包。
我投票把这移到serverfault.com。 他们需要告诉你，你用Truncate_Only误读备份日志：就像一个熊陷阱。 注意关于“ 仅截断 ”的部分。
请参阅缩小与第一篇文章链接的数据库，阅读并理解它。 这并不是说你不应该截断你的日志：它只能截断它们，配合完整的备份，事务日志备份和可能的差异备份。
一旦日志安全备份，不再需要将其保存在磁盘上。 但是，我不是DBA，我想你可能需要倾听专家的意见才能理解这一点，所以我正在投票移动。