我总是使用完整的恢复模型,因为它是默认的,但今天我遇到了这个错误：
@H_404_4@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)
@H_404_4@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以供重用,并在执行事务日志备份时允许事务日志的“环绕”特性(以及一些其他要求,例如没有活动事务,某些复制方面等).
@H_404_4@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：
@H_404_4@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
编辑后编辑：
@H_404_4@Is the new recovery model and databaseshrink going to be a conflict with this script?
该BACKUP DATABASE命令将适用于任一恢复模型.至于常规数据库收缩…不要做它!!!!严重的是,相应地调整数据库的大小,如果您使用完整的恢复模型,那么请确保您正在执行例行和频繁的事务日志文件,而不仅仅是保持事务日志大小,还要满足恢复点对象.
@H_404_4@We are not doing any other kind of backup of the databases,and therefore not the transaction logs,should we?
如果您的数据库正在使用完整恢复模型,那么您应该进行事务日志备份.如果您的数据库处于简单恢复状态,那么您实际上无法进行事务日志备份.
至于使用什么恢复模型(简单与完整),我们无法为您做出决定.只有您,您的业务团队和SLA才能.
