问题标签 [transaction-log]

有没有办法查看正在写入事务日志的内容？

我有一个在过去 20 分钟内增长了 15 Gig 的日志文件。有没有办法让我找出造成这种情况的原因？

我有一个在客户端 SQL Server 2000 机器上运行的数据库，其中事务日志文件的大小只有 1MB。这似乎很奇怪。

我找不到任何明确缩小它的数据库维护计划或单个 SQL 代理作业，所以我不确定如何找出它何时发生。

是否有系统表或视图可用于找出事务日志的最后一次收缩操作何时完成？

在将数据库恢复模型配置为 的 SQL Server 2008 中full，查询如

从表名中选择 col1、col2、col3

记录到事务日志文件。

换句话说，我可以使用事务日志备份确定特定日期在数据库上运行了哪些查询吗？

我有一个 SQL Server 2008 数据库，其中的事务日志每天都在快速增长。有没有人知道有什么工具可以用来更详细地分析哪些事务构成了日志批量的大部分？这样我就知道应该把注意力放在哪里。

非常感谢任何帮助！

最好的问候马库斯

我有一个巨大的表（30 亿行），不幸的是其中大部分包含过期数据。我想简单地删除所有这些过期的行，并保留其余的。

我可以执行这样的语句：

执行计划以某种方式估计将删除大约 4 亿行。

执行时，不仅一个小时后没有完成，而且数据库事务日志文件也从 6 GB 增长到 90 GB。请注意，发生这种情况时，数据库处于批量日志恢复模式。我最终取消了这个查询，因为我确信一定有更好的方法来做到这一点。

我有几个表需要执行类似的操作。如果我绝对不想恢复它们，那么删除这些行的最快和最节省空间的方法是什么？

请注意，我使用的是 Microsoft SQL Server 2005。

我已经阅读了 SQL Server 事务日志，但仍然不完全了解如何使用/管理它们。我知道它们对于事务回滚、镜像、复制和日志传送等事情很重要。

对我来说，它们仍然看起来像一个黑匣子，我对用它们做任何事情都不太舒服。是否有工具可以让我查看事务日志文件或获取有关它的信息？如果我不需要事务日志传送之类的东西，我可以定期缩小和/或截断我的日志文件吗？特别是在将备份恢复到测试实例的情况下——我真的需要一个占用空间的多 GB 日志文件吗？我还需要注意哪些其他功能特别依赖于事务日志并且如果我缩小/截断日志文件将无法工作？

已经有一个每 15 分钟运行一次的备份作业计划。我创建了事务日志传送过程，但在 1 或 2 个恢复的日志之后，此作业停止工作（错误：找不到匹配的日志）。显然，有两个单独的作业创建的日志，并且对于日志传送过程，只有部分日志被复制到辅助数据库（不包括备份作业计划创建的日志）。这是否意味着我将不得不关闭备份工作计划？

我有一个数据库 [My DB]，它包含以下信息：
SQL Server 2008
MDF 大小：30 GB
LDF 大小：67 GB

我想尽可能地缩小日志文件，所以我开始寻求弄清楚如何做到这一点。警告：我不是 DBA（甚至不是接近 DBA），并且一直在通过这个任务取得进展。

首先，我刚刚进入 SSMS、数据库属性、文件，并将初始大小 (MB) 值编辑为 10。这将日志文件减少到 62 GB（不完全是我输入的 10 MB）。因此，我附加了 SQL Profiler，看到正在调用 DBCC SHRINKFILE。然后我将该命令输入到查询编辑器中，结果如下。

输出是：

然后我对此进行了一些研究并发现了这一点：

http://support.microsoft.com/kb/907511

这表示我需要在收缩文件之前备份日志文件，以便释放虚拟日志文件并且收缩文件可以完成它的工作 - 我不知道这意味着什么......我只是在这里解释:)

所以，我想我会尝试备份日志文件，然后执行 DBCC SHRINKFILE（我将新的日志文件大小更改为 12800，因为这是在之前的 DBCC SHRINKFILE 命令的输出中确定的 MinimumSize）

结果和第一次一样。我只能将日志文件缩小到 62 GB。

我不确定我做错了什么以及接下来应该尝试什么。

传统观点认为，基于集合的表处理应始终优于 RBAR - 特别是当表变大和/或您需要更新许多行时。

但这总是成立吗？我经历过很多情况——在不同的硬件上——基于集合的处理显示时间消耗呈指数增长，而将相同的工作负载分成更小的块会产生线性增长。

我认为被证明完全错误会很有趣——如果我遗漏了一些明显的东西——或者如果没有，那么知道什么时候分担工作量是值得的，这将是非常好的。随后确定哪些指标有助于决定使用哪种方法。我个人希望以下组件很有趣：

• 工作量大小
• 日志文件的大小和增长
• 内存量
• 磁盘系统的速度

任何其他？CPU/CPU 核心数？

示例 1：我有一个 1200 万行的表，我必须使用另一个表中的数据更新每行中的一个或两个字段。如果我在一个简单的 UPDATE 中执行此操作，我的测试箱需要大约 30 分钟。但是如果我把它分成十二块，我会在大约 24 分钟内完成 - 即：

示例 2：是一个 200+ 百万行的表，还需要对几乎所有行进行多次计算。如果一个做全套，我的盒子会运行三天，甚至不会完成。如果我编写一个简单的 C# 来执行完全相同的 SQL，但附加了 WHERE 子句以一次将事务大小限制为 100k 行，它将在大约 14 小时内完成。

记录一下：我的结果来自相同的数据库，基于相同的物理硬件，更新了统计信息，索引没有变化，简单的恢复模型等。

不，我还没有尝试过“真正的”RBAR，尽管我可能应该尝试过——尽管这只是看看真正需要多长时间。

我想讨论一下SQL Server的事务日志，我四处寻找，找到了一些完成的产品，例如Lumigent Log Explorer。但我仍然对它感兴趣。

我知道的方法： 1.直接从物理日志文件中读取 2.使用数据库命令/查询，DBCC LOG 或通过 fn_dblog

问题/困难： 1. 日志文件结构难以逆向工程。2.当我做了很多INSERT时，fn_dblog并没有全部，例如我INSERT 50000条记录时，fn_dblog只有29616条LOP_INSERT_ROWS记录，这意味着20384条记录被截断？我不知道内部关于 fn_dblog 的逻辑，有人可以解释一下吗？ fn_dblog 有限制吗？

很高兴听到一些关于 SQL Server 事务日志的研究。