截断数据库日志方法

  • 格式:docx
  • 大小:56.10 KB
  • 文档页数:6

有用的SQL语句关键是要在截断日志之前做一次完整备份。

做完整备份的时候,用参数WITH NO_LOG;然后执行收缩数据库的操作。

BACKUP DATABASE [ado] TO DISK= N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\ado0427inrunning.bak'WITH NOFORMAT, NOINIT,NAME= N'ado-完整数据库备份',SKIP,NOREWIND,NOUNLOAD,STATS= 10 ;BACKUP LOG [ado] TO DISK= N'C:\Program Files\Microsoft SQLServer\MSSQL.1\MSSQL\Backup\ado0427inrunning.bak'WITH NO_LOG;GOUSE [ado];GODBCC SHRINKDATABASE(N'ado');执行结果为:SQL Server 事务日志的收缩和截断SQL Server中事务日志的作用:持续记录数据库所有的事务和这些事务对数据库所做的修改;一旦数据库出现灾难事件,就需要事务日志来进行近期数据的恢复操作。

但是,在此条件下受益的同时也要付出相应的代价:在活动数据库中,事务日志会消耗大量的存储空间,假如你不做任何的干预,事务逻辑日志将会一直增长,直到塞满存储这些日志文件的所有可用空间。

下面我们来详细介绍SQL Server提供的两个用来平衡事务日志对空间巨大需求的操作:收缩事务日志和截断事务日志。

◆日志收缩截断日志虽然确实从日志文件中清除了事务,但它并不会真正的减小物理日志文件的大小。

SQL Server希望事务日志最终会扩展到其截断前的大小,所以截断不会释放已经分配给日志的硬盘空间。

如果你的日志在某一时刻人为地扩展到某个大小,却再也无法恢复到这个大小的话可就麻烦大了。

在这种情况下,要释放硬盘物理空间做其他用途,就要手动进行事务日志文件收缩操作。

你可以使用下面的T-SQL命令实现日志文件的收缩:DBCC SHRINKFILE(,)上面命令中的desired_shrink_size指的是你想要回收的硬盘空间大小(以MB为单位)。

你可以在执行完事务日志截断操作之后立即回收大部分的磁盘空间。

◆日志截断截断事务日志操作就是清除事务日志文件中的非活动记录。

在一般的情况下,SQL Server能够自动执行截断操作,不需要人工干预管理。

截断的频率取决于数据库的使用程度。

你每进行一次完整恢复模式或大容量日志恢复模式的数据库备份,SQL Server就会截断一次事务日志。

如果是在简单恢复模式下(不能还原事务日志),SQL Server会在每个检查点之后截断事务日志。

你也可以通过间接的方式手动驱使SQL Server执行事务日志截断操作,需要运行备份操作,不过你可以给SQL Server下指示,表明你只想执行事务日志的备份操作,不做执行其他任何操作。

通过以下的T-SQL命令仍然可以达到上述效果:BACKUP LOG WITH TRUNCATE_ONL Y;截断数据库日志方法1. 为什么要截断数据库日志日志文件很重要,它记录用户对数据库的所有操作,在发生故障时,可以以此回复。

但日志文件的大小到达一定程度时,会影响数据库性能。

经常的,日志文件会大于数据库主文件本身,长时间不截断,甚至会达到10-20倍之多。

如果ERP用户操作越频繁,相差会越大。

比如,数据库文件为1G,而日志文件可能会有10G。

一般3-6个月检查一次日志文件的大小。

如果发现,日志文件比数据库文件大3~5倍,应该考虑截断数据库日志。

在截断之前,锐减使用最简单的方法:务必做一次“完整备份”!2. 检查日志文件的大小方法有多种。

3. 截断日志文件在查询分析器中,使用SQL语句:BACKUP LOG {database_name | database_name_var}{[WITH {NO_LOG | TRUNCA TE_ONL Y }]}例:backup log “database_name” with no_log4. 收缩数据库做完第三个步骤之后,数据库的日志文件的大小将会被缩小,有可能只有1M左右的大小。

具体缩小到一个什么程度,得看数据库的日志文件在数据库创建时的大小。

截断数据库的命令DBCC SHRINKDATABASEDBCC SHRINKDATABASE收缩指定数据库中的数据文件和日志文件的大小。

语法:DBCC SHRINKDATABASE(database_name | database_id | 0[ ,target_percent ][ , { NOTRUNCATE | TRUNCATEONL Y } ])[ WITH NO_INFOMSGS ]例子:收缩ado的数据库文件和日志文件USE [ado]GODBCC SHRINKDATABASE(N'ado')GO参数:database_name | database_id | 0要收缩的数据库的名称或ID。

如果指定0,则使用当前数据库。

target_percent数据库收缩后的数据库文件中所需的剩余可用空间百分比。

NOTRUNCATE通过将已分配的页从文件末尾移动到文件前面的未分配页来压缩数据文件中的数据。

target_percent是可选参数。

文件末尾的可用空间不会返回给操作系统,文件的物理大小也不会更改。

因此,指定NOTRUNCATE 时,数据库看起来未收缩。

NOTRUNCATE 只适用于数据文件。

日志文件不受影响。

TRUNCATEONL Y将文件末尾的所有可用空间释放给操作系统,但不在文件内部执行任何页移动。

数据文件只收缩到最近分配的区。

如果与TRUNCA TEONL Y 一起指定,将忽略target_percent。

TRUNCATEONL Y 只适用于数据文件。

日志文件不受影响。

WITH NO_INFOMSGS取消严重级别从0 到10 的所有信息性消息。

压缩日志及数据库文件大小1.清空日志DUMP TRANSACTION 库名WITH NO_LOG2.截断事务日志:BACKUP LOG 数据库名WITH NO_LOG3.收缩数据库文件(如果不压缩,数据库的文件不会减小企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了--选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了也可以用SQL语句来完成--收缩数据库DBCC SHRINKDA TABASE(客户资料)--收缩指定数据文件,1是文件号,可以通过这个语句查询到:select * from sysfiles DBCC SHRINKFILE(1)4.为了最大化的缩小日志文件a.分离数据库:企业管理器--服务器--数据库--右键--分离数据库b.在我的电脑中删除LOG文件c.附加数据库:企业管理器--服务器--数据库--右键--附加数据库此法将生成新的LOG,大小只有500多K或用代码:下面的示例分离pubs,然后将pubs 中的一个文件附加到当前服务器。

a.分离EXEC sp_detach_db @dbname = 'pubs'b.删除日志文件c.再附加EXEC sp_attach_single_file_db @dbname = 'pubs',@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.md f'5.为了以后能自动收缩,做如下设置:企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩"--SQL语句设置方式:EXEC sp_dboption '数据库名', 'autoshrink', 'TRUE'6.如果想以后不让它日志增长得太大企业管理器--服务器--右键数据库--属性--事务日志--将文件增长限制为xM(x是你允许的最大数据文件大小)--SQL语句的设置方式:alter database 数据库名modify file(name=逻辑文件名,maxsize=20)'--------------------------------------------如何使Microsoft SQL Server的日志文件不会增大?作者:怡红公子来源:开发者俱乐部加入时间:2002-12-11当易软件站如何缩小MSSQL的日志文件已经是一个经常性的问题了,不过这个问题在精华区已经有不少答案了,我这里也不再赘述。

现在我们讨论一下治本的问题,即如何使日志文件不再增大?先介绍一个简单的方法。

就是把数据库的故障还原模型设置为“简单”(SQL2K)。

这样它就会在Checkpoint的时候截断日志。

具体操作方法是:1、在Enterprise Manager中右键点数据库,“属性|选项|故障还原”,选择“简单”就可以了,如果是SQL7,在“属性|选项”中有一个“trunc. log on chkpt. ”,选中就可以了。

2、如果不想用Enterprise Manager,在Query Analyser或者isql里面执行EXEC sp_dboption 'your_dbname', 'trunc. log on chkpt.', 'TRUE'就可以了但是,要注意的是,这样做了之后,虽然日志不会增大,但是也意味着你一旦出现误操作,将不会有利用日志恢复的机会。

(如何利用日志来恢复请参见精华区的FAQ)所以,绝对不建议在生产数据库上截断日志,除非你有充足的理由和足够的把握,或者……承担责任的不是你。

既然这种方法不安全,下面我将介绍一种安全的方法。

大家都知道,SQL Server 在完成事务日志备份时将自动截断事务日志中的不活动部分。

这些不活动的部分包含已完成的事务,因此在恢复过程中不再使用。

相反,事务日志的活动部分包含仍在运行但尚未完成的事务。

SQL Server 将重新使用事务日志中这些截断的非活动空间,而不是任由事务日志继续增大并占用更多的空间。

所以,我们备份事务日志就可以使日志文件不再增大了。

但是呢,日志文件一直放着也不是个办法,删除呢,又会失去恢复的可能性。