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

Question

目前的状态 数据文件收缩前才126,000MB左右，每月的增量在2G左右。日志文件收缩前55,296MB左右，这也是暴涨过的容量，正常应该只有2G多点。

Answer 1

做日志备份，然后用DBCC SQLPERF(LOGSPACE)看看对应的百分比

Answer 2

我现在的数据库已经比原来超大38G了，这38G的空间能收缩回来吗？照理，数据库月增量2G，38G可以管好几年了。

Answer 3

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

Answer 4

是SQLServer 2008 R2。

Answer 5

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

Answer 6

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

Answer 7

完整备份我在做了，日志备份该怎么做？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

Answer 8

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

Answer 9

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

Answer 10

消息 4208，级别 16，状态 1，第 1 行
当恢复模式为 SIMPLE 时，不允许使用 BACKUP LOG 语句。请使用 BACKUP DATABASE 或用 ALTER DATABASE 更改恢复模式。
消息 3013，级别 16，状态 1，第 1 行
BACKUP LOG 正在异常终止。日志备份要改恢复模式，现在改不了...等完整备份结束。

Answer 11

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

Answer 12

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

Answer 13

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

Answer 14

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

Answer 15

DBCC OPENTRAN可以看到有没有开启的事务

Answer 16

我重启了数据库服务器，数据库A（正在恢复），时间挺长了，但是Sqlserver.exe进程内存占用才1个多G。

Answer 17

我重启了数据库服务器，数据库A（正在恢复），时间挺长了，但是Sqlserver.exe进程内存占用才1个多G。

重启数据库的恢复时间长短，应该是受事物undo影响的吧，按照我的理解，你数据库重启之前，做了很多DML操作，事物没有提交，但是写入了日志，重启后要根据日志做undo

Answer 18

如果有一个大事务你计算强制还是自动回滚，一样的，我有一次修改一个千万级大表的排序规则，等得不耐烦，直接重启sqlserver，结果还是在恢复，又等了一个小时

Answer 19

DBCC SQLPERF(LOGSPACE)
运行结果
Database Name Log Size (MB) Log Space Used (%) Status
A 99996.18 74.57049 0

Answer 20

是的，还有75%是被占用了，你看看这个的结果：
SELECT log_reuse_wait_desc FROM sys.databases
where name='你的库名'

Answer 21

真实帐套
log_reuse_wait_desc
LOG_BACKUP
测试帐套
log_reuse_wait_desc
ACTIVE_TRANSACTION

Answer 22

LOG_BACKUP 证明你还需要做一次完整备份+日志备份
ACTIVE_TRANSACTION 证明这个有事务还在活动，是否有大操作的程序在跑

Answer 23

做了之后看看DBCC那个命令的百分比