我支持一个古老的webapp(即将退休),该webapp仍将“ aspnetdb”用于其身份验证系统。当我发现测试服务器抱怨以下错误时,我正在做一些准备工作以使其退役:
由于'NOTHING',数据库'aspnetdb'的事务日志已满。
现在,通常我会认为问题出在数据库事务日志中...但是该数据库最近已切换到简单的恢复模式(我们的管理员对我们感到不满,抱怨test-SQL-Server空间不足因此她将其切换为简单恢复)。
我尝试了几次运气不好的实验,并做了很多谷歌搜索。有人以前看过这个错误吗?以简单的恢复模式在数据库上完整的事务日志?
它在SQL Server 2016上运行,并且以2008兼容模式运行,因为aspnetdb很旧。
答案 0 :(得分:2)
即使在简单的恢复模式下,您仍然可以获得完整的事务日志。简单的恢复模式只是意味着在每个完成的事务之后,事务日志都会被截断。
事务日志仍然需要空间来容纳所有活动事务和所有正在回滚的事务。
所以一个可能的原因是您的数据库上仍然有未完成的事务。如果发生这种情况,事务日志将不会被截断。
另一个角度是实际的空间可用性。如果您已将日志文件配置为具有最大文件大小,或者在磁盘空间不足时可以使用此文件。
答案 1 :(得分:2)
知道了,从stackexchange获得了帮助。
自动增长设置为0。不幸的是,在SSMS中无法查看此操作,因为它隐藏了有关恢复模式简单DB的设置。
通过@HandyD查询以查看Autogrowth的真正价值:
SELECT
db.name AS [Database],
mf.name AS [File],
CASE mf.[type_desc]
WHEN 'ROWS' THEN 'Data File'
WHEN 'LOG' THEN 'Log File'
END AS [FileType],
CAST(mf.[size] AS BIGINT)*8/1024 AS [SizeMB],
CASE
WHEN mf.[max_size] = -1 THEN 'Unlimited'
WHEN mf.[max_size] = 268435456 THEN 'Unlimited'
ELSE CAST(mf.[max_size]*8/1024 AS NVARCHAR(25)) + ' MB'
END AS [MaxSize],
CASE [is_percent_growth]
WHEN 0 THEN CONVERT(VARCHAR(6), CAST(mf.growth*8/1024 AS BIGINT)) + ' MB'
WHEN 1 THEN CONVERT(VARCHAR(6), CAST(mf.growth AS BIGINT)) + '%'
END AS [GrowthIncrement]
FROM sys.databases db
LEFT JOIN sys.master_files mf ON mf.database_id = db.database_id
where mf.name like 'aspnetdb%'
另一个问题是,在这种状态下,您无法更改自动增长。但是您可以更改大小。因此,通过增加大小并 then 引入自动增长,可以解决问题。
ALTER DATABASE aspnetdb MODIFY FILE (
NAME = aspnetdb_log
, SIZE = 1GB
) --this fixes the problem
GO
ALTER DATABASE aspnetdb MODIFY FILE (
NAME = aspnetdb_log
, SIZE = 1025MB
, MAXSIZE = UNLIMITED
, FILEGROWTH = 10MB
) -- now we have autogrowth
GO
USE aspnetdb
DBCC SHRINKFILE(aspnetdb_log,1) --now we can shrink the DB back to a sane minimum since autogrowth is in place
GO