日期:2014-5-17 浏览次数:20037次

日志暴大,无法收缩,谁来挑战一下!

环境:windows server 2008  sqlserver 2008
报磁盘空间满,上去查看发现数据库的ldf文件暴大,本人随已不用sqlserver 1年,但是以前干过,对sqlserver谈不上精通,也大概知道点皮毛?
立即写脚本操作,步骤如下。
alter database DBName set recovery simple;      --逻辑操作,VLF 248 kb 标记为可重用,磁盘空间不会缩小
use DBName 
DECLARE @lname AS VARCHAR(50)   
SELECT name
FROM sys.database_files WHERE type=1
DBCC SHRINKFILE (@lname,100);                   --物理操作收缩 截断了的空间。但是空间一点没有变小。所以怀疑有可能是一个很大很长的事务在执行。
alter database DBName set recovery full;

use DBName
go
dbcc opentran
--结果如下
/*
已复制的事务信息:
        最早的分布式 LSN     : (0:0:0)
        最早的非分布式 LSN : (5067131:1370:2)
DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。
*/

DBCC loginfo()  --全是2 木有 0 都是活动事务,断不了,更收缩不了。

-- 一个没有spid的东西。怎么杀啊? 查事务,
select transaction_begin_time,  
case transaction_type   
when 1 then 'Read/Write transaction'  
when 2 then 'Read-Only transaction'  
when 3 then 'System transaction'  
when 4 then 'Distributed transaction'  
end tran_Type,  
case transaction_state  
when 0 then 'not been comoletely initaialiaed yet'  
when 1 then 'initaialiaed but ha notstarted'  
when 2 then 'active'  
when 3 then 'ended (read-only transaction)'  
when 4 then 'commit initiated for distributed transaction'  
when 5 then 'transaction prepared and waiting resolution'  
when 6 then 'commited'  
when 7 then 'being rolled back'  
when 0 then 'been rolled back'  
end transaction_state  
from   
sys.dm_tran_active_transactions
--没有发现异常的事务。没有做过复制,没有做过镜像。

--查看log状态
SELECT log_reuse_wait_desc  FROM sys.databases WHERE NAME='DBName' 
--REPLICATION  某做过复制,竟然出来个这。

use DBName
checkpoint
go
sp_removedbreplication 'DBName'
DBCC SHRINKFILE(DBName_Log,100);

DBCC loginfo()  --还是全是活动的。
dbcc opentran 还有的那个没有spid的复制事务。

某有头绪了!
临时解决方案,新建了个log文件在其他盘,能顶个10几天。趁这段时间跑来问问大牛?