(2.8)备份与还原--在大容量恢复模式下事务日志的角色

简介

日志的作用是保证持久性和数据一致性,通过日志可以实现数据的Undo与Redo,因此通过日志,SQL Server不仅仅可以实现灾难恢复,还可以通过日志的Redo来实现高可用性。本篇文章主要讲述日志在SQL Server中提供的几种高可用性中的作用以及在灾难恢复中的角色。

日志损坏

日志可能会由于IO子系统的故障而损坏,当出现日志损坏时,如果您对日志的原来略有了解,并能在日志损坏的情况下尽量挽救数据,那么感觉一定是非常好的:-),下面我们来了解几种日志损坏的情况下的恢复情况。

1.数据库正常关闭,日志损坏。

当数据库正常关闭时,日志损坏就不是那么重要了,因为此时数据库中所有提交的事务对应的脏数据都已经CheckPoint到物理磁盘,因此不存在数据不一致的问题。因此,如果MDF和NDF文件完好,直接指定 FOR ATTACH_REBUILD_LOG参数后附加即可,如图1所示。

图1.如果数据库正常关闭,直接附加即可

但值得注意的是,使用该方式附加数据库会自动重建日志文件,日志文件大小为0.5MB,也就是2个VLF,自动增长为10%,因此您需要手动再来设置一下日志的大小,避免出现太多VLF的情况。

2.数据库非正常关闭,日志损坏

在讲述这种情况之前,我们首先来看数据库所能处在的几种状态,一个完整的模型如图2所示。

图2.数据库所能处在的状态关系

上面的几种状态的具体转换关系超出了本文的讨论范围,但是这里我会强调两种和日志损坏关系很大的状态:RECOVERY_PENDING和SUSPECT状态。

假如出现了数据库没有正常关闭,也就是还有数据没有CheckPoint到磁盘,如果数据库要启动就必须经历Recovery过程,如果日志损坏,则无法进行该Recovery过程,就会造成数据不一致的问题。

此时,数据库可能处于下面两种状态之一:

  • RECOVERY_PENDING:需要运行crash recovery,但该过程由于资源等待无法开始,比如说日志完全损坏
  • SUSPECT:crash recovery已经开始,但无法完成

因此处理该类情况要基于您所在的业务环境是否允许数据损失,可以选择从备份中恢复数据,或是将数据库状态改为EMERGENCY。EMERGENCY模式意味着数据库跳过crash recovery阶段,此时虽然可以访问数据库,但是会存在数据事务不一致的问题,如果仅仅是某些数据页不一致还好,但如果是对表结构修改的事务存在,那就可能存在数据库架构不一致的问题。如果您没有合适的备份集,那只能通过该方式来恢复数据。将数据库设置为EMERGENCY模式非常简单,如代码清单1所示。

ALTER DATABASE AdventureWorks2012 SET EMERGENCY

代码清单1.将数据库设置为紧急模式

与该模式有关的一个选项是REPAIR_ALLOW_DATA_LOSS,该选项依然会执行crash recovery过程,但会跳过受损的日子,从而尽可能的修复数据一致性问题,该选项会创建一个新的日志文件,最后使得数据库处于ONLINE状态,使用该选项的一个简单例子如代码清单2所示。

ALTER DATABASE AdventureWorks2012 SET SINGLE_USER
 
DBCC CHECKDB(AdventureWorks2012,REPAIR_ALLOW_DATA_LOSS)

代码清单2.使用REPAIR_ALLOW_DATA_LOSS选项

值得注意的是,作为DBA永远是要有“备”无患,上面这些操作是在您准备工作不充分的情况下才要去考虑的。

3.数据库处于在线状态,日志损坏

在这种情况下,如果SQL Server在运行时需要使用的日志损坏(比如说回滚时),则SQL Server会将数据库下线,并转为SUSPECT模式。

同样如果没有备份的话,只能考虑使用EMERGENCY模式。

还有一种方式是,将数据库的恢复模式改为简单,然后手动发起一个CheckPoint来截断日志,最后再将数据库改回完整恢复模式。但这种方式会破坏日志链。但可能会将被损坏的日志清除掉。

日志在高可用性中的作用

镜像与AlwaysOn

这两种高可用性技术都是基于日志来维护一个数据库的副本。通过将日志实时的传送到副本,在副本上来不断的进行REDO操作,就可以保证主体和副本数据库之间的实时同步。

对于镜像来说,可以同步或异步将日志传送的1个副本。

而对于AlwaysOn可用性组来说,就可以将日志最多同步到2个副本+异步到2个副本(据说SQL Server 2014已经将该特性翻倍,也就是最多可以4个同步副本和最多4个异步副本,但目前还没有发布,所以只是小道消息)。

所谓的同步概念就是主副本只有将传送的日志发送到辅助副本之后,由辅助副本返回ACK信息后,才能够在本地提交,因此可能会造成明显的延迟并影响性能。这里还值得注意的是,主副本不是等待事务在辅助副本提交之后才能提交,而是只是需要收到辅助副本返回的收到日志的ACK信息即可。

无论对于上面两种高可用特性,无论是哪一种,都需要考虑监控发送队列和REDO队列。发送队列过长意味着当故障转移时,可能丢失大量数据,同时还会阻止日志截断。REDO队列过长意味着当故障转移时,RECOVERY截断将会消耗更多的时间,从而使得故障转移消耗的宕机时间延长。这两种队列的监控都可以使用性能监视器进行,如图3所示。

图3.监控队列的计数器

事务日志传送

相比其他高可用性功能来说,事务日志传送功能比较简单。本质上就是一个不断备份、传送、还原日志的过程。使用事务日志传送对于测试日志是否有效来说非常合适。

事务日志传送还有一点值得注意的地方就是,当有批量操作的时候,考虑使用大容量事务日志模式,从而避免大量的日志通过网络传输。

事务日志对于维护一个数据库冗余的副本来说是最简单的方式,虽然不能保证数据实时,但对于特定业务场景还是非常有意义的。

事务复制

与前几种高可用性特性不同的是,事务日志无法直接传送事务日志。因为发布端和订阅端数据库的结构可以完全不一样,订阅端可以仅仅订阅一个或多个表,表中的一部分列,或是一部分数据子集。由于发布端和订阅端的表结构和数据不一致,因此无法直接将发布端的日志传送到订阅端。

因此事务复制的原理是Log Reader Agent定期读取发布端的日志,汇总日志对发布内容的更改,从而将这些更改变为逻辑操作,从而使得订阅端可以Replay这些操作来打到数据同步的目的。

这里值得注意的是,如果Log Reader Agent还没有扫描最新的修改,事务复制可能造成发布端的日志无法截断。

小结

本篇文章作为对前面四篇文章的补充,讲述了日志在灾难恢复和高可用性中的原理和作用。这些原理对于设计一个好的备份计划、高可用性计划来说,是必不可少的。

转自:http://www.cnblogs.com/CareySon/archive/2013/06/16/3138742.html

评论列表

回复引用

#1楼 2013-12-13 20:44 桦仔

所谓的同步概念就是主副本只有将传送的日志发送到辅助副本之后,由辅助副本返回ACK信息后,才能够在本地提交,因此可能会造成明显的延迟并影响性能。这里还值得注意的是,主副本不是等待事务在辅助副本提交之后才能提交,而是只是需要收到辅助副本返回的收到日志的ACK信息即可

我明白镜像的两个性能模式了
运行模式
l 高性能模式(异步运行):事务不需要等待镜像服务器将日志写入磁盘便可提交,这样可最大程度地提高性能。这意味着事务不需要等待镜像服务器将日志写入磁盘便可提交,而此操作允许主体服务器在事务滞后时间最小的条件下运行,但可能会丢失某些数据。
l 高安全模式(同步运行):当会话开始时,镜像服务器使镜像数据库尽快与主体数据库同步。一旦同步了数据库,事务将在双方提交,这会延长事务滞后时间。

支持(0)反对(0)

回复引用

#2楼 2018-05-28 10:15 M哥

alwayson的同步也是伪同步,只是作为确保主从数据强一致性,相对来说延迟还是有的。

原文地址:https://www.cnblogs.com/gered/p/9178639.html

时间: 2024-11-06 16:36:47

(2.8)备份与还原--在大容量恢复模式下事务日志的角色的相关文章

(2.6)备份与还原--在简单恢复模式下事务日志的角色

简介 在简单恢复模式下,日志文件的作用仅仅是保证了SQL Server事务的ACID属性.并不承担具体的恢复数据的角色.正如"简单"这个词的字面意思一样,数据的备份和恢复仅仅是依赖于手动备份和恢复.在开始文章之前,首先要了解SQL Server提供的几种不同备份类型. SQL Server提供的几种备份类型 SQL Server所提供的几种备份类型基本可以分为以下三种(文件和文件组备份以及部分备份不在本文讨论之列): 1.完整(Full)备份:直接将所备份的数据的所有区(Extent)

(2.7)备份与还原--在完全恢复模式下事务日志的角色

简介 生产环境下的数据是如果可以写在资产负债表上的话,我想这个资产所占的数额一定不会小.而墨菲定律(事情如果有变坏的可能,无论这种可能性有多小,它总会发生)仿佛是给DBA量身定做的.在上篇文章介绍的简单恢复模式下,从最近一次备份到当前的数据都会存在丢失的风险.而完整备份模式使得数据丢失的风险大大减少.本文主要介绍在完整备份模式下概念原理和日志所处的角色. 完整(Full)恢复模式 完整恢复模式通过将对数据库的任何修改记录到日志来给予数据最大程度的保护.在完整恢复模式下,日志的作用不仅仅是保证了数

数据库完整恢复模式下的日志增长问题

最近在弄alwaysOn的时候有遇到磁盘满了的情况,这个是因为参与alwaysOn的数据库必须是完整恢复模式, 而完整恢复模式,数据库收缩还无效果,所以只能采用事务日志备份的方式来进行事务日志截断. 这个还要感谢@i6first大神和@桦仔大神的文章才了解到必须使用事务日志备份才可行(原谅我是小白一枚,竟然不知道完整恢复模式需要用事务日志备份才能解决日志大小问题.目前还在成长中..).开此文章,用于记录完整模式下日志增长问题. 论证如下 ↓↓↓↓ ------------------------

SQL Server中的事务日志管理(6/9):大容量日志恢复模式里的日志管理

当一切正常时,没有必要特别留意什么是事务日志,它是如何工作的.你只要确保每个数据库都有正确的备份.当出现问题时,事务日志的理解对于采取修正操作是重要的,尤其在需要紧急恢复数据库到指定点时.这系列文章会告诉你每个DBA应该知道的具体细节. 这个标题有点用词不当,因为运行在大容量日志恢复模式里的数据库,我们通常是长期不管理日志.但是,DBA会考虑在大容量加载时,短期切换到大容量恢复模式.当数据库在大容量模式里运行时,一些其他例如索引重建的操作会最小化日志(minimally logged),因此在日

浅谈SQL Server中的事务日志(四)----在完整恢复模式下日志的角色

浅谈SQL Server中的事务日志(四)----在完整恢复模式下日志的角色 本篇文章是系列文章中的第四篇,也是最后一篇,本篇文章需要前三篇的文章知识作为基础,前三篇的文章地址如下: 浅谈SQL Server中的事务日志(一)----事务日志的物理和逻辑构架 浅谈SQL Server中的事务日志(二)----事务日志在修改数据时的角色 浅谈SQL Server中的事务日志(三)----在简单恢复模式下日志的角色 简介 生产环境下的数据是如果可以写在资产负债表上的话,我想这个资产所占的数额一定不会

解决简单恢复模式下产生的日志增长

简介 最近测试服务器进行数据归档,其间程序员发现一个问题,空间不足,我查看原因发现日志文件暴涨.然后将数据库改为简单恢复模式,但是依然存在这个问题.经过查询资料发现了日志文件在简单模式下依然增加的原因. Simple概念 Simple恢复模式也叫做”Checkpoint with truncate log“,其实这个名字更形象,在Simple模式下,SQL Server会在每次checkpoint或backup之后自动截断log,也就是丢弃所有的闲置日志记录,仅保留用于实例启动时自动发生的ins

浅谈SQL Server中的事务日志(三)----在简单恢复模式下日志的角色

浅谈SQL Server中的事务日志(三)----在简单恢复模式下日志的角色 本篇文章是系列文章中的第三篇,前两篇的地址如下: 浅谈SQL Server中的事务日志(一)----事务日志的物理和逻辑构架 浅谈SQL Server中的事务日志(二)----事务日志在修改数据时的角色 简介 在简单恢复模式下,日志文件的作用仅仅是保证了SQL Server事务的ACID属性.并不承担具体的恢复数据的角色.正如”简单”这个词的字面意思一样,数据的备份和恢复仅仅是依赖于手动备份和恢复.在开始文章之前,首先

sql server 备份与恢复系列三 简单恢复模式下的备份与还原

原文:sql server 备份与恢复系列三 简单恢复模式下的备份与还原 一.概述 前面讲了备份的一些理论知识,这篇开始讲在简单恢复模式下的备份与还原.在简单模式下是不能做日志备份的,发生灾难后,数据库最后一次备份之后做的数据修改将是全部丢失的,所以在生产环境下,数据又很重要,一般不建议使用这种模式. 例如对一个数据库有5次完整数据备份,时间是t5,  之后发生灾难,就会部丢失. 当数据库越来越大,完整备份时间会越来越长,为了减少丢失风险,引入差异备份.例如下图演示:在第一次建立数据库完整备份后

如何通过trn日志文件恢复SQL Server 事务日志 还原 备份

首先恢复时一个完整的备份,但在完整的备份里一定要选择with nonerecovery(企业管理器里选项中是第2项) sql 语句是: restore database mydata from disk = 'c:\temp\movedb.bak'  with norecovery 这时数据库就会变成恢复模式,这样你就可以一条一条的把trn文件添加进行恢复了. 语句是: restore log Mydata from disk =    "D:\Program Files\Microsoft S