csh的空间

我们一直在努力....

SQL Server的数据库日志并不可怕!

标签: SQL Server 日志 收缩 备份 截断
SQL Server的数据库日志并不可怕!

首先在SQL Server的使用过程中,大多数人都可能会遇到同样的困惑。当我们理解和掌握
一些概念和理论后,这些问题处理起来就会轻松很多。需要说明的是,楼主所碰到的问题所
涉及的知识点还是挺多的,在这里不可能面面俱到。我只列出以下几点内容,更多的内容还
是在帮助里,其实帮助中相关文档还是非常全面的。

1.SQL Server在内部将每一个物理日志文件分成多个虚拟日志文件。用户无法控制虚拟日志
文件的大小,以及物理日志文件中所包含的虚拟日志文件数目,它们是由存储引擎动态选择的。

2.对数据库的访问所产生的日志记录就记录在虚拟日志文件中,这些日志记录称作逻辑日志。
简单说,我们可以将逻辑日志分成两类(状态),活动的和不活动的。其中活动的部分是永远无
法被截断的,因为它是数据库Restart Recovery所必需的,否则SQL Server就不能保证数
据库事务一致性。

3.根据问题描述,你当前数据库使用的恢复模式应该是FULL或是BULK_LOGGED。

4.当数据库执行过完整备份后,SQL Server即认为你在维护一个日志备份序列,而逻辑日志的
不活动部分只有在备份到备份设备后才能被截断。即这部分日志空间才可以被重用,进一步讲就
是这部分空间才可以被收缩。

5.事务日志截断操作,并不能物理上收缩日志文件的大小。日志截断操作旨在缩小逻辑日志的大小,
让日志空间得以重用,而不至于一直增长下去。一般来说,对于simple模式的数据库,在执行checkpoint
时会自动截断事务日志。对于另外两种恢复模式的数据库,则发生在事务日志备份后。所以
对于使用FULL或是BULK_LOGGED恢复模式的数据库,定期备份事务日志不仅能最小化工作丢失风险,
还有助于事务日志的截断。同时也要清楚导致日志截断延迟的一些因素。

6.日志文件不同于数据文件,它有它自己的增长和收缩方式。首先日志文件收缩操作必需是从物理
文件的尾部开始,并且以虚拟日志文件大小为单位。日志截断将一个或多个虚拟日志文件标记为非
活动之后,才能进行收缩。包含任何逻辑日志部分的虚拟日志文件都是不能被收缩的。

7.你可以使用下面的方法来截断并收缩日志文件:
BACKUP LOG dbname WITH NO_LOG
GO
DBCC SHRINKFILE (Log_FileName)
GO
需要注意2点:
a)上面手工截断日志的方法,在SQL Server 2008里不再被支持。SQL Server 2008中方法是
将数据库的恢复模式切换到simple模式,然后再切换回原来的恢复模式。
b)对于FULL或是BULK_LOGGED恢复模式的数据库,手工截断日志将破坏日志链。为了维护新的
日志备份序列,请在上述操作之后立即进行数据库完整备份。

8.你所使用的“删除日志物理文件”的方法是不可取的。你可以通过sp_detach_db来分离
数据库,这样可以确保分离后数据文件处于事务一致的状态。此时可以安全的删除日志文件,
接着可以通过sp_attach_single_file_db或是CREATE DATABASE ... FOR ATTACH语
句来附加数据库。

    评分: 请先登录再投票,同一篇博客一月只能投票一次!
    无人投票

相关博客:


评论


发表评论

关注此文的人们还关注