MS-SQL日志文件过大,数据文件才不到500M,日志文件却已经超过了40G,而且还在疯长
查阅了大量网上资料,网友提出的解决方案大致可以分为两种
一种是使用如下命令
dump transaction db_name with no_log
backup db_name with no_log
dbcc shrinkdatabase(db_name)
另外一种是先分离数据库,然后直接删除日志文件,然后再附加数据库
但是以上两种试了,发现在当时有效,过不了两天日志文件又变回修改前的大小(比如这里的40多G).
每天都要运行一个作业,该作业差不多要运行几个小时,但是个人感觉也没那么疯狂吧,难道几个小时的作业就能产生那么大的日志文件?
再还有是设置数据库的属性的选项里设置模型为简单模式以限制日志文件的增长速度,好像这个都不管用,日志文件还是照样疯长

解决方案 »

  1.   

    、用BACKUP LOG database WITH NO_LOG清除日志 把数据库属性中的故障还原模型改为“简单”可以大大减慢日志增长的速度。    如果把还原模型调到简单,这样就不支持时间点还原了,但是日志文件会很小,如果数据比较重要推荐还是把数据库的还原模型调为完全 用BACKUP LOG database WITH NO_LOG命名后,会截断不活动日志,不减小物理日志文件的大小,但逻辑日志会减小,收缩数据库后会把不活动虚拟日志删除来释放空间,不会损坏数据。 如果日志被截断并收缩数据库后,就不能直接用最近的一个全库备份做时间点还原,建议立即备份数据库,以防万一。 2、sql server运行中,是否能删除主数据库事务日志文件  
    步骤如下:(1)、分离数据库企业管理器--数据库--右击你要删除日志的数据库--所有 任务--分离数据库 
    (2)、然后删除日志文件 
    (3)、然后再附加数据库 
    企业管理器--数据库--右击数据库--所有任务--附加数据库这时候只附加。mdf就可以了。 3、压缩SQL数据库及日志的详细方法 SQL Server 2000基础教程——压缩数据库数据库在使用一段时间后,时常会出现因数据删除而造成数据库中空闲空间太多的情况,这时就需要减少分配给数据库文件和事务 日志文件的磁盘空间,以免浪费磁盘空间。当数据库中没有数据时,可以修改数据库文件属性直接改变其占用空间,但当数据库中有数据时,这样做会破坏数据库中 的数据,因此需要使用压缩的方式来缩减数据库空间。可以在数据库属性选项中选择“Auto shrink”选项,让系统自动压缩数据库,也可以用人工的方法来压缩。人工压缩数据库有以下两种方式: 1、用Enterprise Manager 压缩数据库 在Enterprise Manager 中在所要压缩的数据库上单击右键,从快捷菜单中的“所有任务(All Tasks)”中选择“Shrink Database(压缩数据库)”选项,就会出现如图6-10 所示的对话框。可以在图6-10 所示的对话框中选择数据库的压缩方式,也可以选择使用压缩计划或压缩单个文件单击图6-10 中的“Files”按钮,会出现如图6-11 所示的压缩数据库文件对话框,可以针对每个数据库文件进行不同的压缩设置。 
      
    单击图6-10 中的“Change” 按钮,会出现如图6-12 所示的压缩计划编辑对话框,可以指定压缩计划的执行方式。单击图6-12 中的“Change” 按钮,会出现如图6-13 所示的循环工作计划编辑对话框,可以编辑计划执行的周期或时间点。设置完成后单击“OK” 按钮就开始压缩数据库,在压缩结束后会显示一个压缩情况信息框。  
      
      
    2、用Transact-SQL 命令压缩数据库 可以使用DBCC SHRINKDATABASE 和DBCC SHRINKFILE 命令来压缩数据库。其中DBCC SHRINKDATABASE 命令对数据库进行压缩,DBCC SHRINKFILE 命令对数据库中指定的文件进行压缩。 
    (1) DBCC SHRINKDATABASE  
    DBCC SHRINKDATABASE 命令语法如下: 
    DBCC SHRINKDATABASE (database_name [, target_percent] 
    [, {NOTRUNCATE | TRUNCATEONLY}] ) 
    各参数说明如下:  
    ?target_percent 指定将数据库压缩后,未使用的空间占数据库大小的百分之几。如果指定的百分比过大,超过了压缩前未使用空间所占的比例,则数据库不会被压缩。并且压缩后的数据库不能比数据库初始设定的容量小。  
    ?NOTRUECATE 
    将数据库缩减后剩余的空间保留在数据库,中不返还给操作系统 。如果不选择此选项,则剩余的空间返还给操作系统。  
    ?TRUNCATEONLY 
    将数据库缩减后剩余的空间返还给操作系统。使用此命令时SQL Server 将文件缩减到最后一个文件分配,区域但不移动任何数据文件。选择此项后,target_percent 选项就无效了。例6-14: 压缩数据库mytest 的未使用空间为数据库大小的20% 。 
    dbcc shrinkdatabase (mytest, 20) 
    运行结果如下: 
    DBCC execution completed. If DBCC printed error  messages, contact your system administrator.  
    (2) DBCC SHRINKFILE 
    DBCC SHRINKFILE 命令压缩当前数据库中的文件。其语法如下: 
    DBCC SHRINKFILE ( {file_name | file_id } 
    { [, target_size] | 
    [, {EMPTYFILE | NOTRUNCATE | TRUNCATEONLY}] } ) 
    各参数说明如下: 
    ?file_id 
    指定要压缩的文件的鉴别号(Identification number, 即ID) 。文件的ID 号可以通过 FILE_ID()函数或如本章前面所讲述 的Sp_helpdb 系统存储过程来得到。  ?target_size 指定文件压缩后的大小。以MB 为单位。如果不指定此选项,SQL Server 就会尽最大可能地缩减文件。  ?EMPTYFILE 指明此文件不再使用,将移动所有在此文件中的数据到同一文件组中的其它文件中去。执行带此参数的命令后,此文件就可以用ALTER DATABASE 命令来删除了。 其余参数NOTRUNCATE 和TRUNCATEONLY 与DBCC SHRINKDATABASE  命令中的含义相同。 例6-15: 压缩数据库mydb 中的数据库文件mydb_data2 的大小到1MB。 use mydb dbcc shrinkfile (mydb_data2, 1) 
      
    企业管理器里面的方法: 
    1、打开企业管理器 
    2、打开要处理的数据库 
    3、点击最上面菜单>工具>SQL查询分析器,打开SQL查询分析器 
    4、在输入窗口里面输入: Code: 
    DUMP TRANSACTION [数据库名] WITH  NO_LOG 
    BACKUP LOG [数据库名] WITH NO_LOG 
    DBCC SHRINKDATABASE([数据库名]) 
    点击绿色的小三角(或按F5)执行查询,等状态栏提示处理完成 即可! 
    程序里面的方法: 
    压缩数据库日志 
    --1.清空日志 
    exec(’DUMP TRANSACTION [’+@dbname+’] WITH  NO_LOG’)  
    --2.截断事务日志: 
    exec(’BACKUP LOG [’+@dbname+’] WITH NO_LOG’) 
    --3.收缩数据库文件(如果不压缩,数据库的文件不会减小 
    exec(’DBCC SHRINKDATABASE([’+@dbname+’])’) 
      4、减小日志的方法: 一、用如下步做了: 
    1、DUMP TRANSACTION 库名 WITH no_log 
    2、dbcc shrinkfile(logfilename) 
    3、收缩数据库 
    4、设定自动收缩。   二、分离数据库,删除日志文件,再附加,OK!右击数据库--所有任务--分离or 附加   三、1、backup log 库名 WITH no_log,2、dbcc shrinkfile(logfilename),3、收缩数据库 
    4、设定自动收缩。
      

  2.   

    楼上的大虾,实在不行我可不可以直接不要日志文件啊?
    反正我也隔天完全备份,还有就是sqlserver2000只是临时性的,数据库马上要移植到Oracle上去了。
      

  3.   

    simple都搞不定,就真不知道您那程序是怎么写的了
      

  4.   

    sql2000数据库属性中事务日志那个TAB页里有一个选项
    有一个最大文件大小选项不过我没用过,你敢不敢试试?
      

  5.   

    你看一下你的作业里有没有在循环里反复UPDATE,DELETE之类的,这种问题一般都是循环引起的
      

  6.   


    /*
    标题:Log Explorer for SQL Server v4.0.2的下载地址和使用说明
    作者:爱新觉罗·毓华 
    时间:2008-07-14
    地点:新疆乌鲁木齐
    资料来源:http://topic.csdn.net/u/20090305/00/849723bf-74ad-495f-8fc6-22d2108beb10.html?seed=1633183628
    */1、Lumigent Log Explorer for SQL Server v4.0.2 特别版下载地址
       http://down.chinaz.com/soft/7887.htm
       Log Explorer for SQL Server 4.2 注册码 
       wv5rc-uxvpz-e33-nr4694qs2 2、Log Explorer for SQL Server v4.0.2 
       安装完毕后,注册该程序(压缩文件有注册机) 
       打开log explorer file=>attach log file->选择服务器和登陆方式->connect-> 
       选择数据库->attach->左面对话框中browse->view log->就可以看到log记录了 
       点击“View DDL Commands”里面就有很多drop table 命令 
       点击下面的“undo”按钮是生成表结构的语句(create table ....) 
       点击下面的“Salvage”按钮是生成插入语句的(insert into ...values....) 
       想恢复的话: 右键log记录 undo transation->选择保存文件名和路径->然后打开该文件到查询分析器里执行T-sql代码就可以了    例如 如果log是delete table where ...的话,生成的文件代码就是insert table ....    log explorer使用的几个问题 
       1)、对数据库做了完全、差异和日志备份 
           备份时选用了删除事务日志中不活动的条目 
           再用Log explorer打试图看日志时 
           提示No log recorders found that match the filter,would you like to view unfiltered data 
           选择yes,就看不到刚才的记录了 
           如果不选用了删除事务日志中不活动的条目 
           再用Log explorer打试图看日志时,就能看到原来的日志 
       2)、修改了其中一个表中的部分数据,此时用Log explorer看日志,可以作日志恢复 
       3)、然后恢复备份,(注意:恢复是断开log explorer与数据库的连接,或连接到其他数据上, 
           否则会出现数据库正在使用无法恢复) 
           恢复完后,再打开log explorer 提示No log recorders found that match the filter,would you like to view unfiltered data 
           选择yes,就看不到刚才在2中修改的日志记录,所以无法做恢复. 
       4)、不要用SQL的备份功能备份,搞不好你的日志就破坏了. 
           正确的备份方法是: 
           停止SQL服务,复制数据文件及日志文件进行文件备份. 
           然后启动SQL服务,用log explorer恢复数据 
       5)、如果你的数据库的日志恢复模型是simple,那就不可能用log explorer恢复 
       6)、Log explorer必须安装在要恢复数据库的sql server服务器上,或者在sql server服务器上安装服务端,在操作的电脑上安装客户端进行数据恢复 3、如果数据量比较大的话,使用磁带机和集群的话,安装了正版的VERITAS ,恢复数据是比较好的方法。 
       下面是该软件重要的新功能: 
       1)、灾难恢复演习(Disaster Recovery Fire Drill)--能够自由测试、规划和检验灾难恢复计划,而不会中断生产过程。 
       2)、集群模拟器(Cluster Simulator)--可测试应用故障切换方案,以验证应用的可用性,确认应用是否根据计划的故障切换策略和应用需求,迁移到最适当的服务器。 
       3)、全局集群选件(Global Cluster Option)--当可用性要求从本地迁移到广域灾难恢复时,能够快速、轻松地升级到任何体系结构。 
       4)、即时访问复制数据--在复制数据的同时,能够即时访问数据,只占用客户的部分可用存储容量。 
       5)、卷复制顾问工具(Volume Replicator Advisor)--准确地分析带宽需求,确保应用得到优化。 
    4、几点恢复数据心得: 
       1)、平时需要做好双机热备份,日备份,月备份,年备份,数据复制,异常记录等工作,在数据丢失的情况下才能做到心中不急。
       2)、如果硬盘损害错误,或者误删除数据库的时候,可以考虑用Easyrecovery或者Recover4all等软件恢复删除或者受到损害的文件,再恢复数据。 
       3)、如果实在遇到自然因素,网络又断开了复制操作的情况下,建议只有手工"造取"一批数据出来弥补丢失数据,一般选取类似纬度(如时间、区域等)的数据。 
      

  7.   

    很久的帖子了,工作后就很少接触数据库了
    这个问题已经解决了
    问题在于有个作业设计的很不合理,疯狂的update和delete,最要命的是这个作业每天都要跑
    优化之后,日志缩小几十倍