MS SQL Server的事务日志简介一览

交易日志,或称事务日志(Transaction logs)是数据库结构中非常重要但又经常被忽略的部分。由于它并不像数据库中的schema那样活跃,因此很少有人关注交易日志。

交易日志是针对数据库改变所做的记录,它可以记录针对数据库的任何操作,并将记录结果保存在独立的文件中。对于任何每一个交易过程,交易日志都有非常全面的记录,根据这些记录可以将数据文件恢复成交易前的状态。从交易动作开始,交易日志就处于记录状态,交易过程中对数据库的任何操作都在记录范围,直到用户点击提交或后退后才结束记录。每个数据库都拥有至少一个交易日志以及一个数据文件。

出于性能上的考虑,SQL Server将用户的改动存入缓存中,这些改变会立即写入交易日志,但不会立即写入数据文件。交易日志会通过一个标记点来确定某个交易是否已将缓存中的数据写入数据文件。当SQL Server重启后,它会查看日志中最新的标记点,并将这个标记点后面的交易记录抹去,因为这些交易记录并没有真正的将缓存中的数据写入数据文件。这可以防止那些中断的交易修改数据文件。

维护交易日志

因为很多人经常遗忘交易日志,因此它也会给系统带来一些问题。随着系统的不断运行,日志记录的内容会越来越多,日志文件的体积也会越来越大,最终导致可用磁盘空间不足。除非日常工作中经常对日志进行清理,否则日志文件最终会侵占分区内的全部可用空间。日志的默认配置为不限容量,如果以这种配置工作,它就会不断膨胀,最终也会占据全部可用空间。这两种情况都会导致数据库停止工作。

对交易日志的日常备份工作可以有效的防止日志文件过分消耗磁盘空间。备份过程会将日志中不再需要的部分截除。截除的方法是首先把旧记录标记为非活动状态,然后将新日志覆盖到旧日志的位置上,这样就可以防止交易日志的体积不断膨胀。如果无法对日志进行经常性的备份工作,最好将数据库设置为"简单恢复模式"。在这种模式下,系统会强制交易日志在每次记录标记点时,自动进行截除操作,以新日志覆盖旧日志。

截除过程发生在备份或将旧标记点标为非活动状态时,它使得旧的交易记录可以被覆盖,但这并不会减少交易日志实际占用的磁盘空间。就算不再使用日志,它依然会占据一定的空间。因此在维护时,还需要对交易日志进行压缩。压缩交易日志的方法是删除非活动记录,从而减少日志文件所占用的物理硬盘空间。

通过使用DBCC SHRINKDATABASE语句可以压缩当前数据库的交易日志文件,DBCC SHRINKFILE语句用来压缩指定的交易日志文件,另外也可以在数据库中激活自动压缩操作。当压缩日志时,首先会将旧记录标记为非活动状态,然后将带有非活动标记的记录彻底删除。根据所使用的压缩方式的不同,你可能不会立即看到结果。在理想情况下,压缩工作应该选在系统不是非常繁忙的时段进行,否则有可能影响数据库性能。

恢复数据库

交易记录备份可以用来将数据库恢复到某一指定状态,但交易记录备份本身不足以完成恢复数据库的任务,还需要备份的数据文件参与恢复工作。恢复数据库时,首先进行的是数据文件的恢复工作。在整个数据文件恢复完成前,不要将其设为完成状态,否则交易日志就不会被恢复。当数据文件恢复完成,系统会通过交易日志的备份将数据库恢复成用户希望的状态。如果在数据库最后一次备份后,存在多个日志文件的备份,备份程序会按照它们建立的时间依次将其恢复。

另一种被称为log shipping的过程可以提供更强的数据库备份能力。当log shipping配置好后,它可以将数据库整个复制到另一台服务器上。在这种情况下,交易日志也会定期发送到备份服务器上供恢复数据使用。这使得服务器一直处于热备份状态,当数据发生改变时它也随之更新。另一个服务器被称作监视(monitor)服务器,可以用来监视按规定时间间隔发送的shipping信号。如果在规定时间内没有收到信号,监视服务器会将这一事件记录到事件日志。这种机制使得log shipping经常成为灾难恢复计划中使用的方案。

时间: 2016-04-07

MS SQL Server的事务日志简介一览的相关文章

SQL Server 为什么事务日志自动增长会降低你的性能

原文地址:点击打开链接   在这篇文章里,我想详细谈下为什么你要避免事务日志(Transaction Log)上的自动增长操作(Auto Growth operations).很多运行的数据库服务器,对于事务日志,用的都是默认的日志文件大小和自动增长设置.人们有时会很依赖自动增长机制,因为它们刚好能正常工作.当然,如果它正常工作的话,你不必太关注它,但很快你会发现会有问题出现.   只依赖于事务日志的自动增长机制总不是个好主意.首先它会导致严重的日志碎片(Log Fragmentation),在

ms sql server 2005数据库日志文件过大,需要清除或者清空

数据库:ms sql server 2005 任务:ms sql server 2005数据库日志文件过大,需要清除. 方法: backup log [你的数据库名称] WITH NO_LOGbackup log [你的数据库名称] WITH TRUNCATE_ONLYDBCC SHRINKDATABASE([你的数据库名称]) 说明: backup log 指定仅备份事务日志.该日志是从上一次成功执行的 LOG 备份到当前日志的末尾.备份日志之后,可能会截断事务复制或活动事务不再需要的空间.

数据库-sql server 2005 事务日志删除问题

问题描述 sql server 2005 事务日志删除问题 sql server 2005 事务日志 删除对数据库有多大影响? 如何删除sql server 2005 事务日志 如何做到定期删除半年前的,保留半年的事务日志? 解决方案 如果你的数据库是full模式,那需要先做完整备份,再定期做日志备份,这样才能截断日志 如果数据库是simple模式,就不存在截断日志的问题

SQL Server 2008事务日志传送备份的实施过程详解

熟悉微软企业级数据库软件朋友,了解作为微软一个重大的产品版本,SQL Server 2008除了许多新的特性和关键的改进,使得它成为至今为止的最强大和最全面的SQL Server版本外,其实SQL Server 2008中的备份方式也是其一大亮点,SQL Server 2008使用的备份一个数据库有多种方法,如差异备份和事物日志备份.事务日志备份将复制上次完全或以前的事务日志备份的所有数据变化.事物日志备份通常是非常快并且非常小,仅次于镜像的高可靠性备份方案,可以达到分钟级的灾难恢复能力. 下面

ORACLE LOGFILE 和 SQL SERVER 2005 事务日志管理和恢复的比较

原创,转载请注明    其实如果要说这类日志的重要性,当然2个数据库都知道它的重要性.也淡淡的说一下.日志是进行数据库恢复重要的组建.用于将数据库恢复到故障点,也就是我们通常说的滚动,ORACLE叫他LOGFILE,而SQL SERVER 叫他事务日志.    ORACLE中有归档模式和非归档模式,而这对应了SQL SERVER 中的恢复模式的完整恢复模式和简单恢复模式.完整恢复模式和归档模式都是支持恢复到故障点的,而非归档模式和简单模式其实说白了都是不保存各自数据库的历史LOGFILE和事务日

MS SQL Server数据库事务锁机制分析

server|数据|数据库 锁是网络数据库中的一个非常重要的概念,它主要用于多用户环境下保证数据库完整性和一致性.各种大型数据库所采用的锁的基本理论是一致的,但在具体实现上各有差别.目前,大多数数据库管理系统都或多或少具有自我调节.自我管理的功能,因此很多用户实际上不清楚锁的理论和所用数据库中锁的具体实现. Microsoft SQL Server(以下简称SQL Server)作为一种中小型数据库管理系统,已经得到了广泛的应用,该系统更强调由系统来管理锁.在用户有SQL请求时,系统分析请求,自

SQL Server中事务日志已满的原因以及解决办法

  错误描述:数据库的事务日志已满.若要查明无法重用日志中的空间的原因 ,请参阅sys.databases 中的 log_reuse_wait_desc 列 .   首先引入一下事务日志的概念(来自百度百科):   事务日志是一个与数据库文件分开的文件.它存储对数据库进行的所有更改,并全部记录插入.更新.删除.提交.回退和数据库模式变化.事务日志还称作前滚日志或重做日志.   事务日志是备份和恢复的重要组件,也是使用 SQL Remote 或 [复制代理] 复制数据所必需的.   在缺省情况下,

MSSQL · 实现分析 · SQL Server实现审计日志的方案探索

摘要 这篇文章介绍四种实现MSSQL Server审计日志功能的方法探索,即解析数据库事务日志.SQL Profiler.SQL Audit以及Extended Event.详细介绍了这四种方法的具体实现,以及通过优缺点的对比和总结,最终得出结论,使用Extended Event实现审计日志是最好的选择,为产品化选型提供参考. 审计日志需求分析 对于关系型数据库来而言,在生产环境SQL Server数据库实例中,审计日志是一个非常重要且必须的强需求功能,主要体现在以下几个方面. 安全审计 问题排

MS SQL Server查询优化方法(1)●查询速度慢的原因很多,常见如下几种:

server|速度|优化 MS SQL Server查询优化方法(1) ●查询速度慢的原因很多,常见如下几种: 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建计算列导致查询不优化. 4.内存不足 5.网络速度慢 6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷)8.sp_lock,sp_who,活动的用户查看,原因是读写竞争资源.9.返回了不必