关于数据库的ldf和mdf文件变得超大解决办法

转自：http://blog.csdn.net/yandong19861103/archive/2009/03/05/3959046.aspx

截断事务日志 
如果从来没有从事务日志中删除日志记录，逻辑日志就会一直增长，直到填满容纳物理日志文件的磁盘上的所有可用空间。在某个即时点，必须删除恢复或还原数据库时不再需要的旧日志记录，以便为新日志记录腾出空间。删除这些日志记录以减小逻辑日志的大小的过程称为截断日志。 
 
永远不能截断事务日志的活动部分。日志的活动部分是在任何时间恢复数据库所需的日志部分，因此必须有回滚所有未完成的事务所需的日志映像。这部分必须始终在数据库中，因为一旦服务器发生故障，在服务器重新启动时必须用它恢复数据库。日志活动部分起点处的记录由最小恢复日志序号  (MinLSN)  标识。 
 
为数据库选择的恢复模式决定了在数据库内，必须在活动部分之前保留的事务日志量。虽然  MinLSN  之前的日志记录对恢复活动事务没有作用，但在使用日志备份将数据库还原到故障点时，必须用这些记录前滚修改。如果由于某种原因丢失了数据库，则可以通过还原上次的数据库备份，然后还原自该数据库备份后的每个日志备份来恢复数据。这意味着这些日志备份必须包含自数据库备份后所写入的每个日志记录。当维护事务日志备份序列时，日志记录直到写入日志备份时才能被截断。 
 
 
--------------------------------------------------------------- 
 
DBCC  SHRINKDATABASE 
DBCC  SHRINKDB 
DBCC  SHRINKFILE 
--------------------------------------------------------------- 
 
DBCC  SHRINKFILE 
在企业管理器--〉收缩数据库--〉收缩文件--〉选日志文件--〉确定 
--------------------------------------------------------------- 
 
-假设test2为数据库名称  日志已经很大的时候用   
方法一此方法适用于7.0和2000。   
 
1、在查询分析器中执行：  exec  sp_detach_db  'DB_Name','true'   
 
2、在我的电脑中将日志的物理文件xxx_Log.LDF改名。   
 
3、在查询分析器中执行：  exec  sp_attach_single_file_db  'DB_Name','C:\Program  Files\Microsoft  SQL  Server\MSSQL\Data\DB_Name.MDF'   
 
4、如果上一步成功，将步骤2中改名后的文件删除。如果上一步不成功，改回原来的文件名，用sp_attach_db将数据库附加到服务器，然后用方法二。   
 
方法二   
 
6.X中  DUMP  TRANSACTION  test2  with  NO_LOG  DUMP  TRANSACTION  test2  with  TRUNCATE_ONLY  将上面的语句多次执行，直到日志缩小。7.0和2000中  backup  log  test2  with  NO_LOG  backup  log  test2  with  TRUNCATE_ONLY  DBCC  SHRINKDATABASE(test2)  将上面的语句多次执行，直到日志文件缩小。上面的方法治标不治本，标本兼治要用下面的方法。   
 
方法三：   
 
--6.X和7.0中改为日志处于截断模式，2000中恢复模型改为简单恢复  exec  sp_dboption  'test2','trunc.  log  on  chkpt.','on'  --7.0和2000中设为自动收缩,6.x中不用执行。  exec  sp_dboption  'test2','autoshrink','on'  通常用于测试环境。   
 
方法四:  --7.0中改为日志不处于截断模式，2000中恢复模型改为完全恢复  exec  sp_dboption  'test2','trunc.  log  on  chkpt.','off'  --7.0和2000中设为自动收缩,6.x中不用执行。  exec  sp_dboption  'test2','autoshrink','on'  建立作业,每半个小时一次日志备份,每天一次完全数据库备份。  7.0和2000中：在Log收缩到正常大小后，将autoshrink选项设置为off。通常用于真实环境。  在产品化系统中将autoshrink选项设置为开启状态并非明智之举（除非您真的需要这样做），这是因为，当您的系统正在忙于完成其它任务时，autoshrink选项可能会同时启动，从而降低系统运行速度。然而，对于那些数据库管理员无暇估计并且数据库尺寸有可能在您毫无察觉的情况下超出控制范围的桌面或远程系统来说，开启这一选项却是一种非常有效的措施。  收缩事务日志  在下列情况下，日志文件的物理大小将减少：   
 
*执行  DBCC  SHRINKDATABASE  语句时。   
 
*执行引用日志文件的  DBCC  SHRINKFILE  语句时。   
 
*自动收缩操作发生时。  日志收缩操作依赖于最初的日志截断操作。日志截断操作不减小物理日志文件的大小，但减小逻辑日志的大小，并将没有容纳逻辑日志任何部分的虚拟日志标记为不活动。日志收缩操作会删除足够多的不活动虚拟日志，将日志文件减小到要求的大小。  按下面任一方式控制事务日志的大小：   
 
*在维护日志备份序列时，调度  BACKUP  LOG  语句按间隔发生，以使事务日志不致增长到超过预期的大小。   
 
*当不维护日志备份序列时，指定简单恢复模式。  详情请参考  MS  SQL  Server  2000  联机丛书：  目录-->  SQL  Server构架-->数据库构架-->物理数据库构架-->事务日志构架-->收缩事务日志  目录-->  SQL  Server构架-->数据库构架-->物理数据库构架-->事务日志构架-->截断事务日志 
 
--------------------------------------------------------------- 
 
 
请确认你的数据库属性-〉选项-〉故障还原模型选择“简单”或者“大容量日志记录恢复”。 
 
BACKUP  LOG  database_name  WITH  NO_LOG 
GO 
DBCC  SHRINKFILE  (datafile,  size) 
GO 
DBCC  SHRINKFILE  (logfile,  size) 
GO 
 
 
--------------------------------------------------------------- 
 
彻底解决的方法： 
     定时备份日志，会自动截断日志，用job调度，不用人工干预。对万一情况的恢复也有帮助。建议用维护计划。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/yandong19861103/archive/2009/03/05/3959046.aspx