SQL Server 2008：有没有办法避免写入事务日志？
尽管我的查询是正确的，但我会间歇性地收到此错误。有没有办法避免写入事务日志？
当我检查指定列时，每列的文本为：“Nothing”
错误：
数据库的事务日志 “tempdb”已满。找出原因 日志中的空间无法重复使用，请参阅 log_reuse_wait_desc 列 sys.databases”。
谢谢，非常感谢，有点紧急。
Although my query is correct, I will intermittently get this error. Is there a way to avoid writing to transaction log?
When I checked the specified column, each column's text read: "Nothing"
The Error:
The transaction log for database
'tempdb' is full. To find out why
space in the log cannot be reused, see
the log_reuse_wait_desc column in
sys.databases".
Thanks, greatly appreciated, somewhat urgent.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您需要使用事务日志。这是 SQL 在出现错误或部分完成查询时回滚的方式。
根本原因不是事务日志，而是查询。您可以：
1 - 查询优化不佳（大量排序或散列连接可能会导致这种情况）
2 - 在查询中过度使用#temp 表
3< /strong> - 有驱动器空间问题
您可以发布您正在运行的查询吗？
编辑：
为了澄清可能导致问题的原因...
如果您有多个
#temp表，它们都会占用 tempdb 中的空间。查询引擎必须执行的任何排序（没有索引的
ORDER BY、不使用索引的复杂JOIN条件、大量GROUP BY或聚合函数，等）写入
tempdb的事务日志，因为所有排序都在那里完成。查询本身可能运行正常，但可能需要对其进行优化以避免这些问题。
You need to use the transaction log. It's how SQL rolls back in case of an error or partial completion of a query.
The root cause is not the transaction log, it's the query. You either:
1 - Have a poorly optimized query (lots of sorts or hash joins can cause this)
2 - Are overusing #temp tables in your query
3 - Have a drive space issue
Can you post the query you are running?
EDIT:
To clarify what could be causing the issue...
If you have multiple
#temptables, they all take up space in tempdb. Any sorting that the query engine has to do(
ORDER BYwithout an index, complicatedJOINconditions that don't use indexes, lots ofGROUP BY, or aggregate functions, etc)writes to the transaction log for
tempdbbecause all that sorting is done there.The query itself may function fine but it probably needs to be optimized to avoid these issues.
不，每笔交易都会被记录。然而，这不是日志记录的问题。
它表明 tempdb 已满，而不是您的日志文件。您正在处理大量记录吗？使用临时表？
您需要管理增长，因为您可能需要进行批量处理并更频繁地提交。
No, EVERY transaction gets logged. However, this is not a problem with logging.
It states the tempdb is full, not your log file. Are you processing a lot of records? Using temp table?
You need to manage the growth in the sense that you may need to do batches and commit more often.
SQL Server 使用事务日志来跟踪它所做的事情，没有办法避免这种情况（出于很多很多原因，你也不想这样做）。问题是这样的：
temdb 是 sql server 中的一个系统数据库，sql server 使用它来写入临时数据，例如超长查询的缓存数据，以及临时表（任何使用 #、## 创建的表） 。
当您首次安装 sql server 时，它会在所有数据所在的驱动器上创建 tempdb。
当您运行执行临时表或长时间运行的查询时，缓存的数据将写入 tempdb 中 - 当执行此操作时，它本质上也会使用 tempdb 的事务日志。
在您的情况下，数据库的日志文件被填满可能是因为有太多数据被缓存/写入到 tempdb，并且 tempdb 日志文件的驱动器可能已满。您应该为您的 tempdb 启用“自动收缩”选项，并且要轻松解决此问题，您可以重新启动 sql 服务，它会自动消除 tempdb 日志文件中的额外数据。
您可以尝试稍微调整您的查询，这样它就不必向 tempdb 写入太多数据（消除长结果集。避免 #temptables 等）
SQL Server uses transaction logs to keep track of what its doing, there is no way to avoid this (nor would you want to, for many, many reasons). The issue is here is this:
temdb is a system DB in sql server that sql server uses to write temp data, such as cached data for really long queries, and temp tables (any tables created with #, ## as the prefix).
when you first installed the sql server, it created the tempdb on the drive all the data is on.
when you run a query that does temp tables, or is long running, the cached data is written in tempdb - when it does that, it also inherently uses the transaction log of the tempdb.
In your case, the log file of the DB gets filled up probably because there is too much data being cached/written to tempdb, and the drive that tempdb log file is probably full. You should have 'shrink automatically' option 'on' for your tempdb, and to fix this problem easily, you can restart sql services, and it will automatically eliminate the extra data in the log file for tempdb.
You could try to tune your query a little bit, so it doesn't have to write too much data to the tempdb (eliminate long result sets. avoid #temptables, etc)
只是为了验证 tempdb 问题，在您的 JOINS 中，强制 LOOP join ex：
从测试中选择 *
内循环连接
测试2
在 x=y 上
并删除所有 ORDER BY 子句。
如果查询运行时没有填充您的 tempdb（但可能会慢很多），那么您就知道需要哈希（或排序）并且使用了太多的 tempdb 空间。
它可能需要良好的查询分析来解决这个问题，但检查执行计划并尝试尽一切可能删除任何排序或散列连接，如果可能的话通过创建索引或有时强制连接类型（但通常如果统计数据良好，则可以应该仅将其作为最后的可能性）。
祝你好运
Just to validate the tempdb problem, in your JOINS, force LOOP join ex:
select * from test
inner LOOP join
test2
on x=y
AND remove all ORDER BY clauses.
If the query runs without filling your tempdb (but may be a lot slower) then you know that hash (or sorting) is required and using too much tempdb space.
It may requires good query analysis to fix that, but check the execution plan and try to do everything possible to remove any sorting or hash join, if possible by creating index(es) or sometimes forcing join type (but normally if statistics are good you should do that only as the last possibility).
Good luck