环境：XP3，SQLSERVER 2008R2。已经为DB搭配好了mirror环境。
DB频繁出现事务日志不断增大，以致磁盘经常报警告。
比如：data只有300M，transcation log却有30G。因为有mirror环境，我无法将DB直接转换成SIMPLE。
所以我只好在principal上直接作shrink，运行：
USE [db_name]
GO
DBCC SHRINKFILE (N'db_name_log' , 0, TRUNCATEONLY)没有起到作用。在作shrink之前我先作了一次FULL备份。shrink完全没有将LOG减少。
后来，在FULL备份后做一次transaction log备份，然后再shrink，这次倒有减少一点点了。
dbcc sqlperf('logspace');
log space的使用空间也从原来的99%降到4%。
可是log却还是很大，只是减少了几百M而已。为什么？这个时候又该怎么做？
为什么FULL备份之后做SHRINK没有一点作用，反而是作了log备份后起到了一点点作用呢？备份SQL Servershrinkfiletransaction log事务日志
DB频繁出现事务日志不断增大，以致磁盘经常报警告。
比如：data只有300M，transcation log却有30G。因为有mirror环境，我无法将DB直接转换成SIMPLE。
所以我只好在principal上直接作shrink，运行：
USE [db_name]
GO
DBCC SHRINKFILE (N'db_name_log' , 0, TRUNCATEONLY)没有起到作用。在作shrink之前我先作了一次FULL备份。shrink完全没有将LOG减少。
后来，在FULL备份后做一次transaction log备份，然后再shrink，这次倒有减少一点点了。
dbcc sqlperf('logspace');
log space的使用空间也从原来的99%降到4%。
可是log却还是很大，只是减少了几百M而已。为什么？这个时候又该怎么做？
为什么FULL备份之后做SHRINK没有一点作用，反而是作了log备份后起到了一点点作用呢？备份SQL Servershrinkfiletransaction log事务日志
SQL2008:
'在SQL2008中清除日志就必须在简单模式下进行，等清除动作完毕再调回到完全模式。
USE [master]
GO
ALTER DATABASE DNName SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE DNName SET RECOVERY SIMPLE --简单模式
GO
USE DNName
GO
DBCC SHRINKFILE (N'DNName_Log' , 11, TRUNCATEONLY) GO '这里的DNName_Log 如果不知道在sys.database_files里是什么名字的话，可以用以下注释的语句进行查询'USE DNName'GO'SELECT file_id, nameFROM sys.database_files;'GO
USE [master]
GO
ALTER DATABASE DNName SET RECOVERY FULL WITH NO_WAIT
GO
ALTER DATABASE DNName SET RECOVERY FULL --还原为完全模式
GO
log太大后不得已也只能如此处理了。
可不能次次都这样啊，因为有mirror环境，无法改为SIMPLE模式。如果去掉mirror再清log，日志不同又得重新配置mirror了。这样很麻烦。
我已经弄了一个天天备份和shrinkfile计划了，是可以适当清一些log，可还是无法达到SIMPLE状态下的那种shrink。
现在一天增加1G的log，不用多久，我又得转成SIMPLE再搭配mirror，这样不科学啊。
我现在的log有3G，如果一小时备份一次，再大的硬盘也吃不消啊-_-
都不知道APP在搞什么，搞得事务日志增长如此之快。
我分析来分析去无非两点，事务等待提交，事务无法提交。所以越积越大。可是不知道怎么解决啊~~~
shrink出来的日志应该是可以同步到mirror的，2008R2，如果不行，那mirror的事务日志不断增长，那不折腾死人。
shrink出来的日志应该是可以同步到mirror的，2008R2，如果不行，那mirror的事务日志不断增长，那不折腾死人。
2005不会，2008之后的可以。http://support.microsoft.com/kb/937531/en-us
目前日志大小差不多2G，增长值10%。
现在已经做了一个每天定时备份日志的计划。
定时备份后再shrink，可就是日志大小没怎么减少，还是不断在增长。
现在就是用天天备份日志来尽量控制日志的增长。
我查过，备份前使用率99%，备份shrink后，未使用空间百分比1%。我昨天日志大小，1.3G左右，今天2G，备份后清理变成1.9G，只减少了100M左右。
今天看起来没怎么增长，明天再看看。
另外，一般来说，只有IO、网络会影响日志发送队列等队列，导致日志redo失败，主数据库日志不断增长，否则一般镜像是不会影响日志的，做好日常的日志备份、监控mirror是否有队列产生，一般就不会有问题。切记不要频繁收缩文件。
请教下怎么看mirror是否有队列产生？
我比较不解的是，日志备份后，DB的日志大小并没减少，同时硬盘还得存储日志备份。
这是不是不合理啊-_-
我比较不解的是，日志备份后，DB的日志大小并没减少，同时硬盘还得存储日志备份。
回答：ldf也就是你说的日志文件，虽然大小没小，这个需要用收缩来减小，但是里面有了很多空间可以重用，也就是合理的日志备份后，ldf一般都不会有明显的增大，如果你的镜像做得好，那么磁盘的日志备份文件生成之后就马上删除也没问题，不过建议你计划删除，你这个疑问是因为对日志的理解还没入门。去了解一下日志吧。不用太深入。
经过这段时间的折腾和大家的讨论，终于能够理解了事务日志、shrinkfile、备份对日志的作用等等。。从码农转到DBA，以前经常使用DB，以为已经很了解了。只是跨一小步，没想也只是门外汉啊。