问题标签 [transaction-log]

我一直在寻找整个互联网，我找不到我的问题可接受的解决方案，我想知道是否有一个没有妥协的解决方案......

我不是 DBA，但我是一个单人团队，在一个巨大的网站上工作，没有额外的资金用于额外的机构，所以我正在尽我所能。

我们的备用计划很糟糕，我很难改进它。目前，有两台服务器运行 SQL Server 2005。我有一个似乎运行良好的镜像数据库（无见证）。我在中午和午夜进行完整备份。这些由我们的服务提供商每晚备份到磁带上，我每周将备份文件刻录到 dvd 以保留旧记录。最终我想切换到日志传送，因为如果没有见证服务器，镜像似乎毫无意义。

问题是事务日志不断增长。从我所做的研究来看，我似乎无法截断镜像数据库的日志文件。那么如何阻止文件增长！？

基于此网页，我尝试了以下操作：

但这没有用。我发现的所有其他内容都表明我需要在运行备份日志命令之前禁用镜像才能使其工作。

我的问题 (TL;DR)

如何在不禁用镜像的情况下缩小我的事务日志文件？

我有一个简单地执行存储过程的 SQL 作业。每天早上，当作业尝试运行时，我都会收到以下错误：

当前事务无法提交，并且无法支持写入日志文件的操作。

当我继续尝试重新开始工作时，它一直给我同样的错误。但是，如果我只执行存储过程而不使用 Job，它就可以正常工作。

这是真正非常棘手的部分。如果我只是运行存储过程，取消它，然后运行作业，那么作业就可以正常工作了。

有没有人遇到过这个相当独特的问题或有任何想法可能导致它？

问题是这样的：

如何在 t3（现在）之后恢复已删除的记录？我希望数据库处于 t0 和 t1 之间的状态。日志级别为已满。

编辑：我已经运行 DBCC LOG(DB-Name, 3)，但日志似乎被截断。尽管必须有数千个，但只有 10 个项目。

我有 SQL Server 2005 数据库，其中事务日志在一周内没有更新。由于用完所有可用磁盘空间的情况，事务日志最近被截断。我在同一台服务器上有一个测试数据库，该数据库按预期每天都在增长。这可能是什么原因？

在 SQL Server 2000 系统上，我有一个 templog.ldf 文件，该文件似乎无限增长！但是当我检查时，tempdb 中从来没有任何打开的事务（使用 DBCC OPENTRAN），我也没有在 tempdb 中使用显式事务。

但是，我确实在我的存储过程中使用了临时表。谁知道 ASP.NET 数据访问对象在幕后会做什么？该数据库支持一个 ASP.NET 网站。

无论如何，tempdb.mdf 文件——tempdb 数据文件——是相当合理的 700 MB。templog.ldf 文件一天可以增长到 30 GB！如果我没有用完磁盘空间，可能会更多。我没有明确删除存储过程中的#tables，但同样，mdf 文件似乎永远不会变得非常大。

为什么没有未完成的事务时事务日志会增长？事务日志是否会回收空间？此外，带有 NO_LOG 的 DUMP TRAN 不会收缩文件，CHECKPOINT 事件也不会通过 trunc 收缩。在 tempdb 上启用了登录 chkpt。停止 SQL Server 会清除 tempdb（可能 DBCC SHRINKFILE 会，但我没有这样做）。

谢谢你的帮助！

我正在尝试编写一个 T-SQL 例程，该例程根据数据库的逻辑名称使用DBCC SHRINKFILE收缩事务日志文件。该DB_NAME()函数为您提供数据库的逻辑名称。事务日志是否有等效的日志？如果没有，是否有其他方法可以获取此信息？事务日志的默认名称是<<Database Name>>_log，但我宁愿不依赖它。

好的，到此为止。我不是数据库专家或管理员。事实上，除了偶尔的索引/查询调优之外，我并没有经常在数据库中闲逛。我经常忽略的一件事是 SQL Server 事务日志。我知道它的用途、它包含什么以及它是如何工作的（至少在概念上），但我想我不明白为什么 SQL Server 似乎如此依附于事务日志。

这是第一个问题。如果我错了，请纠正我，但在我看来，默认情况下事务日志将只包含数据库中所有更改的整个历史记录。有两个迹象表明情况可能确实如此。当我创建一个新数据库时，其日志的最大大小设置为“无限制增长”。第二个原因是我经常处理带有大量事务日志的小型数据库，无论我做什么都无法缩小。这似乎很奇怪，我无法相信这是真的。为什么我会默认想要整个历史记录？我只关心处于一致状态的最新版本数据。好吧，我怀疑在某些情况下可能有正当理由，但我认为这是一个额外的选择。

我的第二个问题是为什么摆脱转换日志如此复杂？只是我，还是真的没有直接的方法可以做到这一点？就在最近，我试图摆脱 5MB 数据库的 100MB+ 日志，我发现最简单的方法是分离数据库，删除日志并重新附加它（甚至 SQL Serve 也抱怨了一下）。我用我能找到的所有可能的选项尝试了缩小命令，但我只能缩小到大约 50%。数据库没有使用（没有活动连接），老实说，我根本不关心过去的任何转换。我注意到可能还有其他一些“方法”可以做到这一点；一些涉及备份和恢复。

我努力尝试阅读 MSDN 文档并了解更多关于转换的知识，但大约 15 分钟后，感觉就像在泥泞中转圈一样，我放弃了。我知道对于数据库管理员和专家来说，我的问题听起来很愚蠢。我很感激任何反馈。

编辑：在第一个答案之后，我意识到我可能不够清楚。我知道事务日志在事务期间是如何工作的，为什么它很重要，并且它可以用于备份目的。我想我想从开发人员的角度提出更多问题。大多数时候，我处理暂存/测试临时数据库，这些数据库不需要任何备份，除了我之外没有人使用，我经常发现自己需要传输它，并且在这种情况下拥有巨大的过渡日志是不必要的不​​便.

我正在使用 SQL Server 2000，并尝试将字段的数据类型从 varchar 更改为 nvarchar，以便它可以处理国际字符。但是，该表中已经有很多数据，当我尝试保存更改时，出现以下错误：

无法修改表。ODBC 错误：[Microsoft][ODBC SQL Server Driver][SQL Server]数据库“AppTest_Apps”的日志文件已满。备份数据库的事务日志以释放一些日志空间。

这是一次性更新——我该如何解决这个错误？

我有一个数据库，其 tlog 已增长到 4.5 GB。数据库处于完全恢复模式，我已经尝试了几个事务日志备份以及 DBCC 收缩文件。而且不会缩水。有没有人有任何想法？

有几个事务的状态 = 2，但数据库中没有活动事务。我想知道为什么他们仍然以 status=2 出现。

我正在调查与 ETL 过程中的大型日志扩展相关的问题，即使数据库设置为批量记录模式（并且它不是以伪简单但真正批量记录的方式运行）

使用 ::fn_dblog(null,null) 函数来检查事务日志操作和操作的上下文，日志扩展几乎完全取决于在 LCX_Heap 上下文上记录 LOP_FORMAT_PAGE 操作。（97% 的扩展是该操作，单次数据加载在日志中出现超过 60 万次。）

问题是， lop_format_page 做了什么/记录了 SQL 做了什么？

鉴于此，我应该能够反转逻辑并理解导致这种情况的因果链是什么，并且能够在适当的情况下更改 ETL。

我没想到很多人都遇到过这个问题，关于操作和上下文的可用详细信息很少甚至没有。