为什么老是报错：事务日志已满

Question

日志已满自动增长

Answer 1

如果恢復模式選擇簡單則不需要進行事務日誌的備份，sqlserver在進行checkpoint的時候會自動進行日誌截斷的動作是否需要進行日誌備份要看你能夠容忍多長時間內的數據丟失，如果像你現在所做的每天進行一次完整備份，這個時候如果在完整備份前出現問題，此時可能丟失的數據就是從上一次完整備份到出現問題這段時間內所做的所有異動假設在原本每天完整備份的基礎上你再進行每兩個小時一次的日誌備份，此時如果備份文件都是安全的，最壞的情況就是丟失這兩次日誌備份之間的數據，也就是兩個小時的異動資料

Answer 2

我在本机遇到过一个非常特殊的情况，一切设置合理，也是保事务日志已满的错误原因是：存放事务日志的盘符为FAT32分区格式，FAT32格式的测试单个最大文件不超过4G，结果日志接近4G的时候就一直这个错误

Answer 3

FAT32格式的磁盘单个最大文件不超过4G，结果日志接近4G的时候就一直这个错误

Answer 4

不可能到100%用尽时才报错，总是要留点空间给收缩日志时用（毕竟以数据库的容量不可能采用新开一个文件、把要保留的数据写入新文件、用新文件替换就文件这样的粗暴方案，只能在当前文件空间中整理）。
收缩只能释放未使用的空间，已占用的空间是释放不了的。必须先截短日志才行。送你一个无节操清理日志的脚本，慎用！！！
-- 不要连被操作的数据库（关闭相关活动），连 master 就行
backup log 数据库名 with TRUNCATE_ONLY;
WAITFOR DELAY '00:00:10';
DBCC SHRINKDATABASE(数据库名);

Answer 5

先查看一下log_reuse_desc確認一下吧SELECT [name] AS [Database Name], recovery_model_desc AS [Recovery Model], log_reuse_wait_desc AS [Log Reuse Wait Description] from sys.databases
事务日志到达11411M时，还没到达12152M就报“事务日志已满”的错误--設定為10%增長 11411 + 11411 * 0.1 = 12552.1 > 12152 已經沒辦法再做下一次增長了，建議設定為每次增長固定大小

Answer 6

谢谢，不过我分区全是NTFS格式啊

Answer 7

SELECT [name] AS [Database Name], recovery_model_desc AS [Recovery Model], log_reuse_wait_desc AS [Log Reuse Wait Description] from sys.databases执行一下

Answer 8

mydd    Recovery Model      Log Reuse Wait Description
master SIMPLE             NOTHING
tempdb SIMPLE             NOTHING
model FULL             NOTHING
msdb SIMPLE             NOTHING
mydb BULK_LOGGED         ACTIVE_TRANSACTION
注：mydb现在上午刚改成“大容量日志”恢复模式，具体作用暂时我也不清楚，呵呵

Answer 9

SELECT * FROM sys.sysprocesses WHERE open_tran<>0
查一下

Answer 10

dbcc opentran 
执行这个试试

Answer 11

没有处于打开状态的活动事务。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

Answer 12

另外执行一下这两个脚本看看有没有数据，还有，你的是企业版还是什么版本？SELECT TOP 10
        atx.transaction_id ,
        atxs.[name]
FROM    sys.dm_tran_active_snapshot_database_transactions AS atx
        INNER JOIN sys.dm_tran_active_transactions AS atxs ON atx.transaction_id = atxs.tran_id
SELECT TOP 1
        atx.*
FROM    sys.dm_tran_active_snapshot_database_transactions AS atx
ORDER BY atx.max_version_chain_traversed