解析SQLServer事务日志压缩与删除的方法

做项目的时候拿到一个只有280M的数据库备份,可是在SQLServer
2000下恢复的时候等了半天才都没有恢复完毕,感觉很不可思议,于是怀疑有什么猫腻。到了数据文件的目录下一看,果不其然竟然声称了一个接近10G的数据库日志文件!以前从来没有做过那么多数据的数据库,而且更没有做过有3年数据库日志记录的数据库。

这对于硬盘空间不是很充裕的我来说已经超过了能够忍受的极限,而且另一个80M的数据库回复之后生成的日志文件更是夸张的达到了5G+!这是不能忍受的,也是不能被原谅的。

刚开始的时候不太懂,直接把数据库日志删除了,发现这样数据库就不能用了,于是百度了一下,发现网上很多提到了日志的压缩和删除技术,正是我想要掌握的内容。仔细整理了一下,大致有这么几种方法解决。

------------------------

方法一: 
这是对数据库和日志进行收缩,比较麻烦,也不是我想要的。

第一步:

backup log database_name with no_log

或者 backup log database_name with truncate_only

no_log和truncate_only是在这里是同义的,随便执行哪一句都可以。

第二步:

1.收缩特定数据库的所有数据和日志文件,执行:

dbcc shrinkdatabase (database_name,[,target_percent])

database_name是要收缩的数据库名称;target_percent是数据库收缩后的数据库文件中所要的剩余可用空间百分比。

2.收缩一次一个特定数据库中的数据或日志文件,执行

dbcc shrinkfile(file_id,[,target_size])

file_id是要收缩的文件的标识 (ID) 号,若要获得文件 ID,请使用 FILE_ID 函数或在当前数据库中搜索 sysfiles;target_size是用兆字节表示的所要的文件大小(用整数表示)。如果没有指定,dbcc shrinkfile 将文件大小减少到默认文件大小。两个dbcc都可以带上参数notruncate或truncateonly,具体意思查看联机帮助.

-----------------------------------

方法二: 
这个正是我想要的,删除原来的日志文件。但是在操作的时候总是提示我数据库正在使用当中,如果我停掉数据库管理器有进不去企业管理器找到要收缩的数据库,没办法只好放弃,改试第三种。

第一步:

先备份整个数据库以备不测 。

第二步:

备份结束后,在Query Analyzer中执行如下的语句:

exec sp_detach_db yourDBName,true

卸除这个DB在MSSQL中的注册信息

第三步:

到日志的物理文件所在的目录中去删除该日志文件或者将该日志文件移出该目录

第四步:

在Query Analyzer中执行如下的语句:

exec sp_attach_single_file_db yourDBName,‘

d:\mssql\data\yourDBName_data.mdf ‘

以单文件的方式注册该DB,如果成功则MSSQL将自动为这个DB生成一个500K的日志文件。

---------------------------------------

方法三:  完美解决!

1. 进入企业管理器,选中数据库,比如demo

2. 所有任务->分离数据库

3. 到数据库文件的存放目录,将demo_log.LDF文件删除,以防万一,你可以拷出去,或者是给它改名

4. 企业管理器->附加数据库,选demo,这个时候你会看见日志文件这项是一个叉,不要紧,继续,此时数据库就会提示你该数据库无日志是否创建一个新的,确定就是了。

5. 记得数据库重新附加后用户要重新设置一下。

如果以后,不想要它变大:

SQL2000下使用:

在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型。

或用SQL语句:

alter database 数据库名 set recovery simple

----------------------------------------

第三种办法完美解决了我的问题,真是令人愉快的一天啊!而且安装好了数据库之后很顺利的能够对项目进行部署了,希望接下来一切顺利。

时间: 2024-12-17 06:35:10

解析SQLServer事务日志压缩与删除的方法的相关文章

(转)解释一下SQLSERVER事务日志记录

本文转载自桦仔的博客http://www.cnblogs.com/lyhabc/archive/2013/07/16/3194220.html 解释一下SQLSERVER事务日志记录 大家知道在完整恢复模式下,SQLSERVER会记录每个事务所做的操作,这些记录会存储在事务日志里,有些软件会利用事务日志来读取 操作记录恢复数据,例如:log explorer 那么事务日志记录怎麽查看,里面都记录了些什么? 打开可以利用下面SQL语句来查看所在数据库的事务日志记录 1 USE [GPOSDB] -

SqlServer 事务日志已满

use master go backup transaction logtest with no_log go DBCC SHRINKDATABASE(logtest) Go SqlServer 事务日志已满

sqlserver 事务日志已满解决方案

sqlserver 事务日志已满解决方案 一.手动收缩: 1.数据库右键属性-选项-恢复模式-下拉选择简单-最后点击确定 2.右键数据库-任务-收缩-文件类型-下拉选择日志-收缩操作-在释放未使用....(默认收缩到1MB)-最后点击确定 3.最后别忘了回到第一步骤把恢复模式改为完整! 二.自动收缩: 原文地址:https://www.cnblogs.com/zlp520/p/9191373.html

SqlServer 事务日志传输

基本概念 可以使用日志传送将事务日志不间断地从一个数据库(主数据库)发送到另一个数据库(辅助数据库).不间断地备份主数据库中的事务日志,然后将它们复制并还原到辅助数据库,这将使辅助数据库与主数据库基本保持同步.目标服务器充当备份服务器,并可以将查询处理从主服务器重新分配到一个或多个只读的辅助服务器.日志传送可与使用完整或大容量日志恢复模式的数据库一起使用. 日志传送由三项操作组成: 在主服务器实例中备份事务日志. 将事务日志文件复制到辅助服务器实例. 在辅助服务器实例中还原日志备份. 日志可传送

DB2事务日志已满的解决方法

DB2命令终端输入: db2 update db cfg for <dbname> using LOGPRIMARY 50 db2 update db cfg for <dbname> using LOGSECOND 20 db2 update db cfg for <dbname> using LOGFILSIZ 10240

(转)对SQLSERVER数据库事务日志的疑问

本文转载自桦仔的博客http://www.cnblogs.com/lyhabc/archive/2013/06/10/3130856.html 对SQLSERVER数据库事务日志的疑问 摸不透SQLSERVER了 实验环境:SQLSERVER2005 SP4,Windows7 本来没什么心情写文章,反正没人看,关于我文章中提到的问题,有些可以从文章结尾的MSDN补充那里找到答案,而有些还没有答案 根据CSDN博客的这篇文章介绍,大家可以先看一下,然后再继续往下看,因为下面会引用到CSDN博客里的

为什么SQL Server需要事务日志

为什么我们需要事务日志,可不可以删除或者不添加日志文件?答案是否定的,如果没有事务日志,你的数据库根本无法工作! 事务日志支持以下操作: 事务回滚 如果用户或程序使用了Rollback 语句或者是数据库检测到了失败的操作 . 这些日志文件就会被用来做回滚. 恢复未完成的事务 如果你在数据库发生错误时重新启动数据库服务器(服务),可能发现数据库处于恢复模式(In Recovery),这表明数据库正在回滚服务器(服务)重启之前未完成的事务,或者是继续执行那些已经写入到了日志文件却没有写入数据文件的事

【转】SQL Server如何截断(Truncate)和收缩(Shrink)事务日志

SQL Server如何截断(Truncate)和收缩(Shrink)事务日志分类: SQL Server数据库备份还原2010-01-25 14:321708人阅读评论(4)举报 当SQL Server截断事务日志时,它仅仅是在虚拟日志文件中做个标记,以便不再使用它,然后准备以重用形式来做备份(假如运载在完整或是批量日志恢复模型).也就是说,在使用简单恢复模型时,事务日志包括如下的日志记录: 当checkpoint发生时,虚拟日志文件1.2不再被使用,因为事务1.2已经被提交了,而且日志记录也

SQL Server如何截断(Truncate)和收缩(Shrink)事务日志

原文:http://blog.csdn.net/tjvictor/article/details/5253931 ? 当SQL Server截断事务日志时,它仅仅是在虚拟日志文件中做个标记,以便不再使用它,然后准备以重用形式来做备份(假如运载在完整或是批量日志恢复模型).也就是说,在使用简单恢复模型时,事务日志包括如下的日志记录: 当checkpoint发生时,虚拟日志文件1.2不再被使用,因为事务1.2已经被提交了,而且日志记录也不再需要回滚了.然后SQL Server重用虚拟日志文件1.2,