sql收缩数据库日志的几种办法

在SQL Server 2000/2005中可以快速压缩日志log文件，通过SQL,

方法一：

--BigData为数据库名

DUMP TRANSACTION BigData WITH NO_LOG

BACKUP LOG BigData WITH NO_LOG

DBCC SHRINKDATABASE(BigData )

执行以上语句可以快速压缩日志文件到1M。

但是以上语句中前两行在SQL Server 2008下无法执行 ，

第一行提示“Incorrect syntax near the keyword 'TRANSACTION'”

第二行提示“One or more of the options (no_log) are not supported for this statement Review the documentation for supported options ”

第三行可以执行。但日志log文件没有任何变化。

原来SQL Server 2008　已经不再支持 DUMP TRANSACTION和BACKUP LOG WITH NO_LOG，

sql Server 2005说明中明确：包含 DUMP 语句是为了向后兼容。而 后续版本的 Microsoft SQL Server 将删除该功能。请避免在新的开发工作中使用该功能，并着手修改当前还在使用该功能的应用程序。 使用 BACKUP。

SQL Server 2008说明：BACKUP LOG WITH NO_LOG 和 WITH TRUNCATE_ONLY 选项已废止。使用完整恢复模式或大容量日志恢复模式时，如果必须删除数据库中的日志备份链，请切换至简单恢复模式。有关详细信息，请参阅有关从完整恢复模式或大容量日志恢复模式切换的注意事项。

方法二：　

use DB_NAME

sp_dboption DB_NAME, "trunc log on chkpt", true

checkpoint

sp_dboption DB_NAME, "autoshrink", true

方法三：（请提前备份文件！！）

Detach数据库。

删除log文件。

附加数据库，选移除log文件，此时SQL Server 会自动重新建立一个512K 的Log 文件。

方法四： 

USE BigData;

GO

BACKUP LOG DATABASENAME TO DISK='d:\testbak'

-- Shrink the truncated log file to 1 MB

DBCC SHRINKFILE (Bigdata_Log, 1);

GO

具体方法有3种。

方法一:

第一步：

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_datamdf '

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

方法三:

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

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

3 到数据库文件的存放目录，将MuOnline_logLDF文件删除，以防万一，你可以拷出去

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

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

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

SQL2000下使用：

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

或用SQL语句：

alter database 数据库名 set recovery simple

收缩数据库

数据库中的每个文件都可以通过删除未使用的页的方法来减小。尽管数据库引擎会有效地重新使用空间，但某个文件多次出现无需原来大小的情况后，收缩文件就变得很有必要了。数据和事务日志文件都可以减小（收缩）。可以成组或单独地手动收缩数据库文件，也可以设置数据库，使其按照指定的间隔自动收缩。

文件始终从末尾开始收缩。例如，如果有个 5 GB 的文件，并且在 DBCC SHRINKFILE 语句中将 target_size 指定为 4 GB，则数据库引擎将从文件的最后一个 1 GB 开始释放尽可能多的空间。如果文件中被释放的部分包含使用过的页，则数据库引擎先将这些页重新放置到文件的保留部分。只能将数据库收缩到没有剩余的可用空间为止。例如，如果某个 5 GB 的数据库有 4 GB 的数据，并且在 DBCC SHRINKFILE 语句中将 target_size 指定为 3 GB，则只能释放 1 GB。

自动数据库收缩

将 AUTO_SHRINK 数据库选项设置为 ON 后，数据库引擎将自动收缩具有可用空间的数据库。此选项可以使用 ALTER DATABASE 语句来进行设置。默认情况下，此选项设置为 OFF。数据库引擎会定期检查每个数据库的空间使用情况。如果某个数据库的 AUTO_SHRINK 选项设置为 ON，则数据库引擎将减少数据库中文件的大小。该活动在后台进行，并且不影响数据库内的用户活动。

将数据库设置为自动收缩

ALTER DATABASE (Transact-SQL)

手动数据库收缩

您可以使用 DBCC SHRINKDATABASE 语句或 DBCC SHRINKFILE 语句来手动收缩数据库或数据库中的文件。如果 DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 语句无法回收日志文件中的所有指定空间，则该语句将发出信息性消息，指明必须执行什么 *** 作以便释放更多空间。有关收缩日志文件的详细信息，请参阅收缩事务日志。

在该过程中任意时间都可停止 DBCC SHRINKDATABASE 和 DBCC SHRINKFILE *** 作，所有已完成工作都将保留。

在使用 DBCC SHRINKDATABASE 语句时，您无法将整个数据库收缩得比其初始大小更小。因此，如果数据库创建时的大小为 10 MB，后来增长到 100 MB，则该数据库最小只能收缩到 10 MB，即使已经删除数据库的所有数据也是如此。

但是，使用 DBCC SHRINKFILE 语句时，可以将各个数据库文件收缩得比其初始大小更小。必须对每个文件分别进行收缩，而不能尝试收缩整个数据库。

事情的起因 昨天 系统管理员告诉我 我们一个内部应用数据库所在的磁盘空间不足了 我注意到数据库事件日志文件XXX_Data ldf文件已经增长到了 GB 于是我决意缩小这个日志文件 经过收缩数据库等 *** 作未果后 我犯了一个自进入行业以来的最大最愚蠢的错误:竟然误删除了这个日志文件!后来我看到所有论及数据库恢复的文章上都说道: 无论如何都要保证数据库日志文件存在 它至关重要 甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的 我真是不知道我那时候是怎么想的!这下子坏了!这个数据库连不上了 企业管理器在它的旁边写着 (置疑) 而且最要命的 这个数据库从来没有备份了 我唯一找得到的是迁移半年前的另外一个数据库服务器 应用倒是能用了 但是少了许多记录 表和存储过程 真希望这只是一场噩梦!数据库日志文件的误删或别的原因引起数据库日志的损坏 方法一 新建一个同名的数据库 再停掉sql server(注意不要分离数据库) 用原数据库的数据文件覆盖掉这个新建的数据库 再重启sql server 此时打开企业管理器时会出现置疑 先不管 执行下面的语句(注意修改其中的数据库名) 完成后一般就可以访问数据库中的数据了 这时 数据库本身一般还要问题 解决办法是 利用数据库的脚本创建一个新的数据库 并将数据导进去就行了 USE MASTERGOSP_CONFIGURE ALLOW UPDATES RECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS = WHERE NAME= 置疑的数据库名 Gosp_dboption 置疑的数据库名 single user true GoDBCC CHECKDB( 置疑的数据库名 )Goupdate sysdatabases set status = where name= 置疑的数据库名 Gosp_configure allow updates reconfigure with overrideGosp_dboption 置疑的数据库名 single user false Go 方法二 事情的起因昨天 系统管理员告诉我 我们一个内部应用数据库所在的磁盘空间不足了 我注意到数据库事件日志文件XXX_Data ldf文件已经增长到了 GB 于是我决意缩小这个日志文件 经过收缩数据库等 *** 作未果后 我犯了一个自进入行业以来的最大最愚蠢的错误:竟然误删除了这个日志文件!后来我看到所有论及数据库恢复的文章上都说道: 无论如何都要保证数据库日志文件存在 它至关重要 甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的 我真是不知道我那时候是怎么想的!这下子坏了!这个数据库连不上了 企业管理器在它的旁边写着 (置疑) 而且最要命的 这个数据库从来没有备份了 我唯一找得到的是迁移半年前的另外一个数据库服务器 应用倒是能用了 但是少了许多记录 表和存储过程 真希望这只是一场噩梦!没有效果的恢复步骤附加数据库_Rambo讲过被删除日志文件中不存在活动日志时 可以这么做来恢复: 分离被置疑的数据库 可以使用sp_detach_db 附加数据库 可以使用sp_attach_single_file_db但是 很遗憾 执行之后 SQL Server质疑数据文件和日志文件不符 所以无法附加数据库数据文件 DTS数据导出不行 无法读取XXX数据库 DTS Wizard报告说 初始化上下文发生错误 紧急模式怡红公子讲过没有日志用于恢复时 可以这么做: 把数据库设置为emergency mode 重新建立一个log文件 把SQL Server 重新启动一下 把应用数据库设置成单用户模式 做DBCC CHECKDB 如果没有什么大问题就可以把数据库状态改回去了 记得别忘了把系统表的修改选项关掉我实践了一下 把应用数据库的数据文件移走 重新建立一个同名的数据库XXX 然后停掉SQL服务 把原来的数据文件再覆盖回来 之后 按照怡红公子的步骤走 但是 也很遗憾 除了第 步之外 其他步骤执行非常成功 可惜 重启SQL Server之后 这个应用数据库仍然是置疑!不过 让我欣慰的是 这么做之后 倒是能够Select数据了 让我大出一口气 只不过 组件使用数据库时 报告说: 发生错误: 未能在数据库 XXX 中运行 BEGIN TRANSACTION 因为该数据库处于回避恢复模式 最终成功恢复的全部步骤设置数据库为紧急模式停掉SQL Server服务;把应用数据库的数据文件XXX_Data mdf移走;重新建立一个同名的数据库XXX;停掉SQL服务;把原来的数据文件再覆盖回来;运行以下语句 把该数据库设置为紧急模式;运行 Use MasterGosp_configure allow updates reconfigure with overrideGo 执行结果:DBCC 执行完毕 如果 DBCC 输出了错误信息 请与系统管理员联系 已将配置选项 allow updates 从 改为 请运行 RECONFIGURE 语句以安装 接着运行 update sysdatabases set status = where name = XXX 执行结果:(所影响的行数为 行)重启SQL Server服务;运行以下语句 把应用数据库设置为Single User模式;运行 sp_dboption XXX single user true 执行结果:命令已成功完成 ü 做DBCC CHECKDB;运行 DBCC CHECKDB( XXX ) 执行结果: XXX 的 DBCC 结果 sysobjects 的 DBCC 结果 对象 sysobjects 有 行 这些行位于 页中 sysindexes 的 DBCC 结果 对象 sysindexes 有 行 这些行位于 页中 syscolumns 的 DBCC 结果 ………ü 运行以下语句把系统表的修改选项关掉;运行 sp_resetstatus XXX gosp_configure allow updates reconfigure with overrideGo 执行结果:在 sysdatabases 中更新数据库 XXX 的条目之前 模式 = 状态 = (状态 suspect_bit = ) 没有更新 sysdatabases 中的任何行 因为已正确地重置了模式和状态 没有错误 未进行任何更改 DBCC 执行完毕 如果 DBCC 输出了错误信息 请与系统管理员联系 已将配置选项 allow updates 从 改为 请运行 RECONFIGURE 语句以安装 重新建立另外一个数据库XXX Lost;DTS导出向导运行DTS导出向导;复制源选择EmergencyMode的数据库XXX 导入到XXX Lost;选择 在SQL Server数据库之间复制对象和数据 试了多次 好像不行 只是复制过来了所有表结构 但是没有数据 也没有视图和存储过程 而且DTS向导最后报告复制失败;所以最后选择 从源数据库复制表和视图 但是后来发现 这样总是只能复制一部分表记录;于是选择 用一条查询指定要传输的数据 缺哪个表记录 就导哪个;视图和存储过程是执行SQL语句添加的 维护Sql Server中表的索引在使用和创建数据库索引中经常会碰到一些问题 在这里可以采用一些另类的方法解决… 第一步:查看是否需要维护 查看扫描密度/Scan Density是否为 %declare @table_id intset @table_id=object_id( 表名 )dbcc showcontig(@table_id) 第二步:重构表索引dbcc dbreindex( 表名 pk_索引名 ) 重做第一步 如发现扫描密度/Scan Density还是小于 %则重构表的所有索引 并不一定能达 % dbcc dbreindex( 表名 ) lishixinzhi/Article/program/SQLServer/201311/22169

以上就是关于sql收缩数据库日志的几种办法全部的内容，包括:sql收缩数据库日志的几种办法、怎样压缩数据库的日志文件、收缩数据库有什么作用等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！