SQLServer日志

  1.清空日志  
  DUMP     TRANSACTION     库名     WITH     NO_LOG          
   
  2.截断事务日志： 
  BACKUP   LOG   数据库名   WITH   NO_LOG  

 3. --收缩数据库 
  DBCC   SHRINKDATABASE(客户资料)  
   
  4.--收缩指定数据文件,收缩到10M
  DBCC   SHRINKFILE('log_name.log',10)  
 
  5.如果想以后不让它日志增长得太大  
  企业管理器--服务器--右键数据库--属性--事务日志 
  --将文件增长限制为xM(x是你允许的最大数据文件大小)  
  --SQL语句的设置方式:  
  alter   database   数据库名   modify   file(name=逻辑文件名,maxsize=20)  

6.如果日志无法收缩，可以尝试多次备份后收缩

declare
 @i tinyint
,@sql varchar(100);
select
 @i=1
,@sql='';
while @i<=3
begin
 select @sql='backup log databasename to disk=''i:\Backuplog\databasename_'+cast(@i as varchar(2))+'.trn'''
 execute(@sql)
 set @i=@i+1
end

use databasename
dbcc SHRINKFILE (databasename_Log,10240);

7.日志无法收缩原因查找

7.1.开启了replication服务
DBCC OPENTRAN('dbname')
已复制的事务信息:
        最早的分布式 LSN     : (0:0:0)
        最早的非分布式 LSN : (2888961:70:1)
--------------------------------------------------------------------
replicated transaction
   latest distribution LSN
   latest Non-distribution LSN

sp_removedbreplication @dbname='dbname',@type='tran'

7.2查找其他原因
DBCC LOGINFO('dbname')
我们看到status=0的日志，代表已经备份到磁盘的日志文件；而status=2的日志还没有备份。
当我们收缩日志文件时，收缩掉的空间其实就是status=0的空间，如果日志物理文件无法减小，
这里一定能看到非常多status=2的记录

查看日志截断延迟原因

活跃(active)的日志无法通过收缩来截断，有各种原因会使日志截断延迟，
具体表现就是事务日志的物理文件无法通过截断、收缩来减小，
通过下面的代码可以看到实例上每个数据库的日志截断延迟原因：

USE [master]

SELECT [name] ,[database_id] ,[log_reuse_wait] ,[log_reuse_wait_desc] FROM [sys].[databases]

各种原因及解释如下：
log_reuse_wait_desc 值 

说明 
NOTHING
 当前有一个或多个可重复使用的虚拟日志文件。
 
CHECKPOINT
 自上次日志截断之后，尚未出现检查点，或者日志头部尚未跨一个虚拟日志文件移动（所有恢复模式）。
        这是日志截断延迟的常见原因。有关详细信息，请参阅检查点和日志的活动部分。
 
LOG_BACKUP
 需要日志备份，以将日志的头部前移（仅适用于完整恢复模式或大容量日志恢复模式）。
注意：日志备份不会妨碍截断。                          
完成日志备份后，日志的头部将前移，一些日志空间可能变为可重复使用。
 
ACTIVE_BACKUP_OR_RESTORE
 数据备份或还原正在进行（所有恢复模式）。
        数据备份与活动事务的运行方式相同。数据备份在运行时，将阻止截断。有关详细信息，请参阅本主题后面的“数据备份操作与还原操作”部分。
 
ACTIVE_TRANSACTION
 事务处于活动状态（所有恢复模式）。
       
一个长时间运行的事务可能存在于日志备份的开头。在这种情况下，可能需要进行另一个日志备份才能释放空间。有关详细信息，请参阅本主题后面的“长时间运行的活动事务”部分。
事务被延迟（仅适用于 SQL Server 2005 Enterprise Edition 及更高版本）。“延迟的事务”是有效的活动事务，因为某些资源不可用，其回滚受阻。有关导致事务延迟的原因以及如何使它们摆脱延迟状态的信息，请参阅延迟的事务。
 
DATABASE_MIRRORING
 数据库镜像暂停，或者在高性能模式下，镜像数据库明显滞后于主体数据库（仅限于完整恢复模式）。
        有关详细信息，请参阅本主题后面的“数据库镜像与事务日志”部分。
 
REPLICATION
 在事务复制过程中，与发布相关的事务仍未传递到分发数据库（仅限于完整恢复模式）。
        有关详细信息，请参阅本主题后面的“事务复制与事务日志”部分。
 
DATABASE_SNAPSHOT_CREATION
 正在创建数据库快照（所有恢复模式）。
        这是日志截断延迟的常见原因，通常也是主要原因。
 
LOG_SCAN
 正在进行日志扫描（所有恢复模式）。
        这是日志截断延迟的常见原因，通常也是主要原因。

原因：
LOG_BACKUP
备份日志后再执行收缩即可

REPLICATION
这是我遇到的情况，但我根本没有启用过REPLICATION，据查，
这好像是SQLSERVER2008的一个BUG，解决方法是给标有“REPLICATION”的数据库任意
一个表创建数据库事务复制（TRANSACTION REPLICATION），然后再删除，
执行数据库与日志备份后，就可以收缩了。

DATABASE_MIRRORING
说明镜像数据库之间数据传递延时严重，需要停掉镜像，才能收缩

 

本文出自 “飞扬过海” 博客，转载请与作者联系！