Server2008 数据库收缩日志文件，不减反暴涨几十G，咋整？

[jedjoy2007]

USE [master]
GO
ALTER DATABASE A SET RECOVERY SIMPLE WITH NO_WAIT
GO 
ALTER DATABASE A SET RECOVERY SIMPLE
GO
USE A 
GO
DBCC SHRINKFILE (N'DataBaseFile_log' , 0,TRUNCATEONLY)

数据库A数据文件原本运行容量110G多，日志文件2G，

这两天日志文件莫名突然暴涨50G，

我用上面几个命令做了数据收缩，

结果数据文件和日志文件都暴涨了几十个G，磁盘空间告急，这可咋整？

数据库类型SqlServer2008，一直都是简单恢复模式，加自动收缩的。

求大神指正，让数据库恢复到原来的大小。

[Mr_Nice]

引用 10 楼 jedjoy2007 的回复:

[quote=引用 8 楼 giftzheng 的回复:] 你这真实的样暴涨了几十个G 是不是系统哪出问题了吧 好好排查一下 看下每个表都占了多少空间 有没有哪个表占的空间异常

我这是走的K3 12.2的帐套，像出入库表本来就很大的。[/quote] 导入导出操作！ K3就是这个样子。DBCC SQLPERF(LOGSPACE)看百分比。通常20%左右都OK 过大的就需要具体看了。

[jedjoy2007]

引用 6 楼 DBA_Huangzj 的回复:

先别考虑这些,先做一个完整备份，再做一个日志备份然后用DBCC SQLPERF(LOGSPACE)看看对应的百分比

完整备份我在做了，日志备份该怎么做？

[jedjoy2007]

引用 2 楼 DBA_Huangzj 的回复:

应该是有会话在做东西，你先用完整模式，做一个完整备份，再做一个日志备份，就可以收缩了

引用 12 楼 OrchidCat 的回复:

导入导出操作！ K3就是这个样子。DBCC SQLPERF(LOGSPACE)看百分比。通常20%左右都OK 过大的就需要具体看了。

A是真实帐套,A2013是测试帐套。 Database Name Log Size (MB) Log Space Used (%) Status A 99996.18 99.47356 0 A2013 82.42969 10.20875 0

[發糞塗牆]

引用 13 楼 jedjoy2007 的回复:

[quote=引用 6 楼 DBA_Huangzj 的回复:] 先别考虑这些,先做一个完整备份，再做一个日志备份然后用DBCC SQLPERF(LOGSPACE)看看对应的百分比

完整备份我在做了，日志备份该怎么做？[/quote]

BACKUP LOG [test] TO  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\test.bak' WITH NOFORMAT, NOINIT,  NAME = N'test-Transaction Log  Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

[發糞塗牆]

引用 14 楼 jedjoy2007 的回复:

[quote=引用 2 楼 DBA_Huangzj 的回复:] 应该是有会话在做东西，你先用完整模式，做一个完整备份，再做一个日志备份，就可以收缩了

引用 12 楼 OrchidCat 的回复:

导入导出操作！ K3就是这个样子。DBCC SQLPERF(LOGSPACE)看百分比。通常20%左右都OK 过大的就需要具体看了。

A是真实帐套,A2013是测试帐套。 Database Name Log Size (MB) Log Space Used (%) Status A 99996.18 99.47356 0 A2013 82.42969 10.20875 0[/quote]你的A库满了

[發糞塗牆]

先做日志备份，再执行一次看看

[jedjoy2007]

引用 17 楼 DBA_Huangzj 的回复:

先做日志备份，再执行一次看看

恩，在完整备份，相当的慢。

[jedjoy2007]

引用 12 楼 OrchidCat 的回复:

[quote=引用 10 楼 jedjoy2007 的回复:] 我这是走的K3 12.2的帐套，像出入库表本来就很大的。

导入导出操作！ K3就是这个样子。DBCC SQLPERF(LOGSPACE)看百分比。通常20%左右都OK 过大的就需要具体看了。 [/quote] K3 数据引出操作，会导致数据库庞大吗？

[發糞塗牆]

那么大，完整很慢的，但是日志应该很快啊

[jedjoy2007]

引用 20 楼 DBA_Huangzj 的回复:

那么大，完整很慢的，但是日志应该很快啊

消息 4208，级别 16，状态 1，第 1 行
当恢复模式为 SIMPLE 时，不允许使用 BACKUP LOG 语句。请使用 BACKUP DATABASE 或用 ALTER DATABASE 更改恢复模式。
消息 3013，级别 16，状态 1，第 1 行
BACKUP LOG 正在异常终止。

日志备份要改恢复模式，现在改不了...等完整备份结束。

[發糞塗牆]

额.....

[發糞塗牆]

但是切换回去还要做一次完整备份哦

[Mr_Nice]

引用 14 楼 jedjoy2007 的回复:

[quote=引用 2 楼 DBA_Huangzj 的回复:] 应该是有会话在做东西，你先用完整模式，做一个完整备份，再做一个日志备份，就可以收缩了

引用 12 楼 OrchidCat 的回复:

导入导出操作！ K3就是这个样子。DBCC SQLPERF(LOGSPACE)看百分比。通常20%左右都OK 过大的就需要具体看了。

A是真实帐套,A2013是测试帐套。 Database Name Log Size (MB) Log Space Used (%) Status A 99996.18 99.47356 0 A2013 82.42969 10.20875 0[/quote] 99.47 % 这个够满的了。日志备份语句就楼上写的这个。

[Mr_Nice]

引用 19 楼 jedjoy2007 的回复:

[quote=引用 12 楼 OrchidCat 的回复:] [quote=引用 10 楼 jedjoy2007 的回复:] 我这是走的K3 12.2的帐套，像出入库表本来就很大的。

导入导出操作！ K3就是这个样子。DBCC SQLPERF(LOGSPACE)看百分比。通常20%左右都OK 过大的就需要具体看了。 [/quote] K3 数据引出操作，会导致数据库庞大吗？[/quote] 会，这个引出，在现象上看，就是重建一个库，然后把数据批量的导啊，导啊！ 他们的基础代码也好久都没修改过了。有点儿僵尸....

[jedjoy2007]

引用 23 楼 DBA_Huangzj 的回复:

但是切换回去还要做一次完整备份哦

嗯

引用 24 楼 OrchidCat 的回复:

99.47 % 这个够满的了。日志备份语句就楼上写的这个。

嗯

[专注or全面]

估计是应用程序中出现了异常，事务没有关闭，建议重启之后再收缩一下试试

[专注or全面]

数据库类型SqlServer2008，一直都是简单恢复模式，加自动收缩的。 简单恢复模式，除了正在执行的事务，不记录日志的，那就可以认为你有一个非常大的事务正在运行

[jedjoy2007]

引用 25 楼 OrchidCat 的回复:

[quote=引用 19 楼 jedjoy2007 的回复:] [quote=引用 12 楼 OrchidCat 的回复:] [quote=引用 10 楼 jedjoy2007 的回复:] 我这是走的K3 12.2的帐套，像出入库表本来就很大的。

导入导出操作！ K3就是这个样子。DBCC SQLPERF(LOGSPACE)看百分比。通常20%左右都OK 过大的就需要具体看了。 [/quote] K3 数据引出操作，会导致数据库庞大吗？[/quote] 会，这个引出，在现象上看，就是重建一个库，然后把数据批量的导啊，导啊！ 他们的基础代码也好久都没修改过了。有点儿僵尸....[/quote] 晕了，一下子暴涨38G，也太不可思议了。

[没分阿啊啊]

收缩日志文件时候如果文件尾部正被使用，是不会减小文件的物理大小的 可以自己做一个测试，备份日志文件后 执行dbcc loginfo 看最后几条 virtual log files 的状态，最后面如果有状态为2的，那么收缩日志文件就会卡在这个virtual log files 上不能减小多少物理大小。 我通常的做法是这样的 1、备份日志文件 2、DBCC SHRINKFILE (2,TRUNCATEONLY) 收缩日志尾部可释放的物理空间（当然很小） 3、以上两步是为了让事务日志转回日志文件开始，执行dbcc loginfo 看前几条 virtual log files 的状态 ，如果有状态等于2的，那么恭喜准备工作完成了 4 、DBCC SHRINKFILE (2,100) 收缩到100mb 吧 5、查找日志增加的问题，根本问题不解决才是硬伤

[没分阿啊啊]

引用 62 楼 wmoney 的回复:

收缩日志文件时候如果文件尾部正被使用，是不会减小文件的物理大小的 可以自己做一个测试，备份日志文件后 执行dbcc loginfo 看最后几条 virtual log files 的状态，最后面如果有状态为2的，那么收缩日志文件就会卡在这个virtual log files 上不能减小多少物理大小。 我通常的做法是这样的 1、备份日志文件 2、DBCC SHRINKFILE (2,TRUNCATEONLY) 收缩日志尾部可释放的物理空间（当然很小） 3、以上两步是为了让事务日志转回日志文件开始，执行dbcc loginfo 看前几条 virtual log files 的状态 ，如果有状态等于2的，那么恭喜准备工作完成了 4 、DBCC SHRINKFILE (2,100) 收缩到100mb 吧 5、查找日志增加的问题，根本问题不解决才是硬伤

错了 3、4 之间要做一次日志备份才有用