ETL运行时出现 'ACTIVE_TRANSACTION' FULL 错误

Posted 2020-07-14 悦光阴

看到ETL Step在进行 retry attemp，打开Log，看到错误信息：“The transaction log for database ‘xxxx‘ is full due to ‘ACTIVE_TRANSACTION‘.”

‘ACTIVE_TRANSACTION‘ full，说明 log 文件已经不能再容纳新的transaction。

Log 文件从逻辑行划分为多个VLF（Virtual Log Files），以VLF为resule unit，如果一个vlf 存在active transaction，那么vlf就不能被截断和重用。如果log文件中已经耗尽，没有可用的vlf，那么系统就不能处理新增的事务，并抛出 ‘ACTIVE_TRANSACTION‘ full 的错误。

It cannot reuse a virtual log file that contains transaction log records of a transaction that is still active.SQL Server will return a log_reuse_wait_desc value of ACTIVE_TRANSACTION if it runs out of virtual log because of that.

 

出现‘ACTIVE_TRANSACTION‘ full 错误的可能原因是Transaction 运行的时间太长，导致其他transaction虽然被commint，但是其占用的VLF仍然被标记为Active，不能被truncate和reuse，当log文件中没有可用的VLF，而SQL Server Engine又要处理新增的Transaction时，系统报错。此时，Log File的可用空间集合为0，Log File Size 达到最大值，不能增长。

这次ETL遇到的情况有所不同，DB的Recovery Mode 是 simple，log文件还能够持续增长，而Disk 还有很大的可用空间，很诡异。

可用的Scenario 如下：

1. Issue a CHECKPOINT command to free up log space in the log file.
2. Check the available log space with DBCC SQLPERF(‘logspace‘). If only a small percentage of your log file is actually been used, you can try a DBCC SHRINKFILE (LogFileName,1)  command. This can however possibly introduce corruption in your database.

 

引用文档《Factors That Can Delay Log Truncation》

Log truncation frees space in the log file for reuse by the transaction log. Because the active part of the log cannot be truncated or removed by shrinking, truncation can be delayed when log records remain active for a long time.

You can discover what, if anything, is preventing log truncation by using the log_reuse_wait and log_reuse_wait_desc columns of the sys.databases catalog view.

 

引用文档《Log Reuse Waits Explained: ACTIVE_TRANSACTION》

SQL Server will return a log_reuse_wait_desc value of ACTIVE_ TRANSACTION if it runs out of virtual log files because of an open transaction. Open transactions prevent virtual log file reuse, because the information in the log records for that transaction might be required to execute a rollback operation.

To prevent this log reuse wait type, make sure you design you transactions to be as short lived as possible and never require end user interaction while a transaction is open.

To resolve this wait, you have to commit or rollback all transactions. The safest strategy is to just wait until the transactions finish themselves. Well-designed transactions are usually short lived, but there are many reasons that can turn a normal transaction into a log running one. If you cannot afford to wait for an extra-long running transaction to finish, you might have to kill its session. However, that will cause that transaction to be rolled back. Keep this in mind when designing your application and try to keep all transactions as short as possible.

One common design mistake that can lead to very long running transactions is to require user interaction while the transaction is open. If the person that started the transaction went to lunch while the system is waiting for a response, this transaction can turn into a very-long-running transaction. During this time other transactions, if they are not blocked by this one, will eventually fill up the log and cause the log file to grow.

 

推荐阅读：

Log Reuse Waits Explained: CHECKPOINT

Log Reuse Waits Explained: LOG_BACKUP

Log Reuse Waits Explained: ACTIVE_BACKUP_OR_RESTORE

Log Reuse Waits Explained: ACTIVE_TRANSACTION

Log Reuse Waits Explained: DATABASE_MIRRORING

Log Reuse Waits Explained: REPLICATION

Log Reuse Waits Explained: DATABASE_SNAPSHOT_CREATION

Log Reuse Waits Explained: LOG_SCAN