我有几个数据库,其中事务日志(.LDF)比数据库文件(.MDF)大许多倍。
我可以做些什么来自动收缩这些或防止它们变得如此之大?
答案 0 :(得分:6)
那应该做的工作
use master
go
dump transaction <YourDBName> with no_log
go
use <YourDBName>
go
DBCC SHRINKFILE (<YourDBNameLogFileName>, 100) -- where 100 is the size you may want to shrink it to in MB, change it to your needs
go
-- then you can call to check that all went fine
dbcc checkdb(<YourDBName>)
警告语
您只能在不需要适当备份策略的测试/开发数据库中使用它,因为转储日志会导致丢失事务历史记录。在实时系统中,您应该使用Cade Roux
提取的解决方案答案 1 :(得分:4)
备份事务日志并缩小它。
如果正在定期备份数据库并在检查点上截断数据库,它应该不会失控,但是,如果您在这些时间间隔之间执行大量(大小)事务,它将一直增长到下一个检查点
答案 2 :(得分:3)
右键单击Enterprise Manager中的数据库&gt;所有任务&gt;收缩数据库。
答案 3 :(得分:2)
DBCC SHRINKFILE。
答案 4 :(得分:1)
这里没有人这么说,所以我会:永远不会缩小交易日志。从SQL Server的角度来看,这是一个坏主意。
通过执行每日数据库备份和每小时(或更少)事务日志备份来保持事务日志的小型化。事务日志备份间隔取决于数据库的繁忙程度。
答案 5 :(得分:0)
您可以尝试的另一件事是将数据库的恢复模式设置为简单(如果它们尚未存在),这将使日志文件不会快速增长。我们最近遇到了这个问题,我们的交易日志已经填满,我们不再允许交易了。
多个答案和简单恢复模式的收缩文件的组合确保我们的日志文件保持合理的大小。
答案 6 :(得分:0)
使用查询分析器:
USE yourdabatase
SELECT * FROM sysfiles
你应该找到类似的东西:
FileID …
1 1 24264 -1 1280 1048578 0 yourdabatase_Data D:\MSSQL_Services\Data\yourdabatase_Data.MDF
2 0 128 -1 1280 66 0 yourdabatase_Log D:\MSSQL_Services\Data\yourdabatase_Log.LDF
检查日志文件的文件ID(大部分时间是2)。 执行checkpoint命令的2或3次,将每个页面写入硬盘驱动器。
Checkpoint
GO
Checkpoint
GO
执行以下transactional命令将日志文件中继为1 MB
DUMP TRAN yourdabatase WITH no_log
DBCC SHRINKFILE(2,1) /*(FileID , the new size = 1 Mb)*/
答案 7 :(得分:0)
这是我一直在使用的
BACKUP LOG <CatalogName> with TRUNCATE_ONLY
DBCC SHRINKDATABASE (<CatalogName>, 1)
use <CatalogName>
go
DBCC SHRINKFILE(<CatalogName_logName>,1)
答案 8 :(得分:-1)
尝试sp_force_shrink_log,你可以在这里找到 http://www.rectanglered.com/sqlserver.php