我正在将一些历史数据库转换为只读并尝试清理它们。我想将事务日志缩小到1MB。我意识到缩小事务日志通常被认为是不好的做法,但我认为这可能是规则的例外。
数据库设置为SQL Server 2012 Standard上的SIMPLE恢复。所以我希望在发出CHECKPOINT语句后,事务日志的内容可以缩小,但是这不起作用。
我试过了:
在我尝试运行的每次尝试之后:
我已经多次看到此错误消息:
无法缩小日志文件2(MYDATABASE_2010_log)因为总数 逻辑日志文件不能少于2个。
有一次,我尝试创建一个虚拟表并向其添加记录,试图让事务日志翻转并移动到文件的末尾,但这只是一个疯狂的猜测。
以下是DBCC SQLPERF(LOGSPACE)
的结果Database Name Log Size (MB) Log Space Used (%) Status
MyDatabase_2010 10044.13 16.71015 0
以下是DBCC LOGINFO的结果:
RecoveryUnitId FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
0 2 5266014208 8192 15656 0 64 0
0 2 5266014208 5266022400 15673 2 128 0
有没有人知道我做错了什么?
答案 0 :(得分:3)
如果您无法截断和收缩日志文件,那么您应该做的第一件事就是检查是否存在避免日志被截断的真正原因。执行此查询:
SELECT name ,
log_reuse_wait ,
log_reuse_wait_desc ,
FROM sys.databases AS D
您可以按数据库名称
进行过滤如果log_reuse_wait
的值为0
,则可以截断数据库日志。如果该值不是0,则有一些东西可以避免截断。请参阅sys.databases文档中的日志重用等待值的说明。或者甚至更好:Factors That Can Delay Log Truncation。如果值为1
,您可以等待检查点,或手动运行:CHECKPOINT。
一旦检查了没有理由避免日志文件被截断,您就可以执行通常的备份序列(日志,完全增量)和DBCC SHRINKDATABASE
或DBCC SHRINKFILE
。文件应缩小或不缩小。
如果此时文件没有缩小,请不要担心,原因是日志文件的物理结构,可以解决:
日志文件用作循环缓冲区,只能通过删除文件末尾来截断。如果循环缓冲区的已使用部分位于文件末尾,则无法截断。您只需要等到事务日志的已使用部分前进,然后从文件末尾移动到文件的开头。一旦发生这种情况,您可以运行其中一个收缩命令,您的文件将缩小而不会出现故障。在此页面中对此进行了详细说明:How to shrink the SQL Server log。
如果要强制日志文件活动部件从缓冲区的末尾移动到开头:
答案 1 :(得分:1)
预先考虑通常需要备份的警告。我在SQLServerCentral
找到了答案DETACH数据库,重命名日志文件,使用以下方法ATTACH数据库:
CREATE DATABASE xxxx ON (FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA\xxxx.MDF') FOR ATTACH_REBUILD_LOG;
答案 2 :(得分:0)
这对我来说是一个新错误。但是,课程似乎很清楚;将日志文件扩展一小部分以创建一些新的VLF,然后在数据库中引起一些流失,以便当前大的VLF不是活动的。
答案 3 :(得分:0)
前两个VLF的大小各为5GB。你不知何故需要摆脱它们。我可以想到没有任何收缩和增长的序列可以做到这一点。我从未听说过拆分或缩小VLF的可能性。
只需创建一个新的日志文件。数据库可以有多个。然后,删除旧的日志文件。