我总是使用完整的恢复模型,因为它是默认的,但今天我遇到了这个错误：
Microsoft OLE DB Provider for sql Server (0x80040E14) The transaction
log for database ‘DATABASE NAME’ is full. To find out why space in the
log cannot be reused,see the log_reuse_wait_desc column in
sys.databases
特定数据库实际上是我服务器上最小和最不活跃的数据库之一,所以我不知道如何在这个数据库上完成日志,而不是其他数据库.
为了缩小日志并使数据库再次可访问,我将恢复模型从FULL更改为SIMPLE并缩小逻辑文件日志,使用以下命令
alter database myDbName SET recovery simple
go
dbcc shrinkfile('LOG FILE LOGICAL NAME',100)
go
它有所帮助,但现在我需要了解为什么它有所帮助,这种情况如何开始以及如何在未来阻止这种情况？
编辑：
每天晚上1点,我们正在对服务器上的每个数据库进行脚本备份.这是由31行脚本完成的,其中最重要的部分是
set @Filename = 'D:\backup\' + convert(varchar,getDate(),112) + ' - ' + @DBName + '.bak' set @Description = 'Full backup of database ' + @Filename BACKUP DATABASE @DBName TO DISK = @Filename WITH INIT,NOUNLOAD,NAME = @Description,NOSKIP,STATS = 10,NOFORMAT
新恢复模型和databaseshrink是否会与此脚本发生冲突？
我们没有对数据库进行任何其他类型的备份,因此我们不应该使用事务日志吗？
解决方法
When should I use the full recovery model and when should I use the simple recovery model for databases?
当您需要数据库的时间点恢复时,应使用完整恢复模型.如果不需要数据库的时间点恢复,并且上次完全备份或差异备份足以作为恢复点,则应使用简单恢复模型. (注意：还有另一种恢复模式,批量记录.有关批量记录恢复模型的详细信息,请参阅this reference)
Microsoft OLE DB Provider for sql Server (0x80040E14) The transaction log for database ‘DATABASE NAME’ is full. To find out why space in the log cannot be reused,see the log_reuse_wait_desc column in sys.databases
您遇到此错误(最有可能)的原因是您没有备份事务日志.当它没有备份时,它将继续物理增长事务日志文件(提供了autogrowth并且maxsize允许),因为它不能重用事务日志的任何“部分”(虚拟日志文件).它只能标记这些VLF以供重用,并在执行事务日志备份时允许事务日志的“环绕”特性(以及一些其他要求,例如没有活动事务,某些复制方面等).
To shrink the log and making the database accessable again,I changed the recovery model from FULL to SIMPLE and shrinked the logical file log,with the following command
……
It helped,but now I need to understand WHY it helped,HOW this situation started and HOW to prevent this in the future?
这对您有所帮助,因为通过将数据库设置为简单恢复模型,您告诉sql Server您不再关心时间点恢复,并且需要确保不再需要保留虚拟日志文件并将其标记为活动状态,现在,检查点进程将这些VLF标记为非活动状态.
摘录/引自this MSDN reference：
Under the simple recovery model,unless some factor is delaying log truncation,an automatic checkpoint truncates the unused section of the transaction log. In contrast,under the full and bulk-logged recovery models,once a log backup chain has been established,automatic checkpoints do not cause log truncation.
然后你做了一个物理数据库文件收缩,因为你的事务日志中有可用空间,现在它能够物理收缩NTFS文件.
阅读值得花一些时间：
> Recovery Models
> Managing Transaction Logs (Gail Shaw)
> Factors That Can Delay Log Truncation
编辑后编辑：
Is the new recovery model and databaseshrink going to be a conflict with this script?
该BACKUP DATABASE命令将适用于任一恢复模型.至于常规数据库收缩…不要做它!!!!严重的是,相应地调整数据库的大小,如果您使用完整的恢复模型,那么请确保您正在执行例行和频繁的事务日志文件,而不仅仅是保持事务日志大小,还要满足恢复点对象.
We are not doing any other kind of backup of the databases,and therefore not the transaction logs,should we?
如果您的数据库正在使用完整恢复模型,那么您应该进行事务日志备份.如果您的数据库处于简单恢复状态,那么您实际上无法进行事务日志备份.
至于使用什么恢复模型(简单与完整),我们无法为您做出决定.只有您,您的业务团队和SLA才能.
