SQL Server的实例恢复解析

同Oracle一样,SQL Server在非一致性关闭的时候也会进行实例恢复(Instance Recovery),本文根据stack overflow的文章介绍一些SQL Server实例恢复的知识。

原文链接:https://stackoverflow.com/questions/41932735/sql-server-instance-recovery

关于Oracle的实例恢复参考之前的博文:http://www.cnblogs.com/leohahah/p/6973600.html

首先看一下SQL Server中事务日志的作用:

在SQL Server数据库中,事务日志用于记录事务在Buffer Cache中的做的页更改。

当我们更新一些数据时,数据库会把相关数据页的前镜像和后镜像都记录在事务日志中,并为每个事务生成一个唯一的LSN(log seq number),在检查点发生时SQL Server确保检查点LSN之前的脏块被全部写入到磁盘。因此SQL Server的事务日志兼有redo和undo的作用。

但是,如果我们的数据库被强制关闭或者服务器异常掉电重启,数据库就将处于非一致性的状态(没业务的库除外),这意味检查点之后的所有事务(无论是提交还是未提交的),都出现了异常,提交的事务可能脏块未被写入磁盘,未提交的长事务可能有一部分脏块已经被写入到磁盘,数据库必须处于一致状态才能被正常打开,因此此时必须进行实例恢复

SQL Server的实例恢复分两个阶段:

1.前滚

此阶段只处理已提交的事务,根据boot page中记录的检查点和事务日志的记载,SQL Server重构检查点之后的内存脏块并按正常机制提交已提交事务的脏块。

对未提交事务的脏块暂时不做操作。

2.回滚

此阶段处理未提交的事务,SQL Server根据事务日志中记载的更改块前镜像,去覆盖硬盘上那些未提交事务涉及的数据块。

总结一下:

1)实例恢复的目的:

  • 将所有已提交事务的脏块写入磁盘。
  • 回滚未提交的事务。
  • 将检查点推进至已被写入磁盘的事务LSN。

2)实例崩溃之前:

  • 一些已提交的事务被事务日志记录,但是脏块未被写入到磁盘
  • 一些未提交的长事务中的脏块已经被写入到磁盘
  • 一些未提交的事务,其日志还留在log buffer中未被写入到磁盘中的事务日志文件。

3)实例恢复阶段:

  • Log buffer中所有未提交事务的日志在掉电时全部被清空。(已提交事务的日志默认被写入了磁盘事务日志文件)
  • 从boot page中识别出上一个检查点,作为实例恢复的起点。
  • 在前滚阶段,SQL Server根据事务日志的记录对所有脏块进行重现。(无论是提交还是未提交的事务)然后将已提交事务的脏块写入磁盘,对未提交事务的脏块暂不作操作。
  • 在回滚阶段,SQL Server根据事务日志中记载的前镜像对所有未提交的事务进行回滚。
  • 更新boot page中的检查点LSN和事务日志中的LSN。

在以上的介绍中我们提到了boot page,那么什么是boot page呢?

每个数据库都会有一个记录数据库重要信息的页,只有一页一般是 PRIMARY filegroup的第9个页。我们可以使用如下命令查看这一页的信息:

DBCC TRACEON (3604);
go
DBCC PAGE (‘test‘,1,9,0)
go
关于DBCC PAGE的用法这里解释一下:
dbcc page ( {‘dbname‘ | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])
The printopt parameter has the following meanings:
0 - print just the page header
1 - page header plus per-row hex dumps and a dump of the page slot array (unless its a page that doesn‘t have one, like allocation bitmaps)
2 - page header plus whole page hex dump
3 - page header plus detailed per-row interpretation

检查点LSN被记录在boot page中,这是实例恢复的起点,如果这个page无法被访问,那么数据库就不能被附加,打开,或者做其他任何操作。检查点LSN只会被记录在bootpage中,因此这是一个对于实例恢复来说不可或缺的页。

对于SQL Server中检查点的解释:

当检查点发生时,无论这个检查点是如何触发的(手动执行检查点命令,或者数据库执行差异差异备份,或者数据库自动生成的检查点),数据库都会做以下操作:

  • 所有的脏块都被写入磁盘,无论事务是否已提交。
  • 在这些脏块被写入磁盘之前,所有关于这些脏块更改的事务日志也要被从log buffer中写入到磁盘,这样可以确保实例恢复的有效性和有序性,这个操作被称作write-ahead logging(日志先写),日志被写入硬盘的操作是严格按时间序列化的,不可能以事务为单位来离散的写入到磁盘,因此某个脏块的写入磁盘操作,可能引发log buffer中一些之前的、与本脏块无关的事务日志也被写入磁盘。但这是有好处的,事务日志总是被越早写入磁盘越好。
  • 检查点的LSN会被记录到数据库boot page中的dbi_checkptLSN区域。

这里可以复习一些Oracle的检查点机制,也是CKPT进程触发DBWR写脏块,同时如果要写的脏块的scn大于LGWR的scn,DBWR也会触发LGWR把要写的脏块的相关log buffer写入redo文件中,与SQL Server日志先写的机制相似。

时间: 2025-01-04 15:20:13

SQL Server的实例恢复解析的相关文章

如何在 SQL Server 2005 实例之间传输登录和密码

简介 0" style="box-sizing: border-box; outline: none; margin-right: auto; margin-left: auto; max-width: 1600px; width: 761.391px;"> 本文介绍如何在不同服务器上的 Microsoft SQL Server 2005 实例之间传输登录和密码. 有关如何在其他版本的 SQL Server 实例之间传输登录和密码的更多信息,请单击下面的文章编号,以查看

查看SQL Server多实例的版本

通过 select @@version 查看当前的 SQL Server 安装的版本: 结果返回的是 SQL Server 2008 R2 (SP1),可安装的明明是 SQL Server 2012 (SP1). 然后通过 菜单-帮助-关于 显示的SQL Server Management Studio 版本却是SQL Server 2012. 此时纳闷了. 打开SQL Server Configuration Manager 才注意到有两个实例. 然后回看第一张图才知道原来登录的时候用的是Sh

通过端口 8080 连接到主机 localhost 的 TCP/IP 连接失败。错误:“驱动程序收到意外的登录前响应。请验证连接属性,并检查 SQL Server 的实例正在主机上运行,且在此端口接受

1. 点击 开始 --> 所有程序 --> Microsoft SQL Server2005 --> 配置工具-->SQL Server configuration Manager- 选择左边 SQL Server 2005 网络配置 -->双击 MSSQLSERVER 协议--> 选中 TCP/IP 右键 点击启用:2. 选择左边 SQLServer 2005 服务 --> 选择右边SQL Server(MSSQLSERVER) --> 右击选择重新启动

SQL Server 多实例下的复制

一.本文所涉及的内容(Contents) 本文所涉及的内容(Contents) 背景(Contexts) 搭建步骤(Procedure) 注意事项(Attention) 二.背景(Contexts) 在服务器A有一个数据库Task,需要把部分表部分字段发布订阅到服务器B的TaskSiteInfo数据库上,但是A服务器有些特别,因为它除了有个默认的实例之外,还有一个命名实例:TZR06\SQLSERVER2008R2,如果是默认实例到不会遇到太多的问题,现在因为有命名实例在创建发布订阅的过程中出现

Step7:SQL Server 多实例下的复制

一.本文所涉及的内容(Contents) 本文所涉及的内容(Contents) 背景(Contexts) 搭建步骤(Procedure) 注意事项(Attention) 二.背景(Contexts) 在服务器A有一个数据库Task,需要把部分表部分字段发布订阅到服务器B的TaskSiteInfo数据库上,但是A服务器有些特别,因为它除了有个默认的实例之外,还有一个命名实例:TZR06\SQLSERVER2008R2,如果是默认实例到不会遇到太多的问题,现在因为有命名实例在创建发布订阅的过程中出现

SQL Server 连接问题案例解析(1)

SQL Server 连接问题案例解析(1) 转载自:http://blogs.msdn.com/b/apgcdsd/archive/2015/04/27/sql.aspx?CommentPosted=true#commentmessage Microsoft Network Monitor(Netmon)是由微软发布的一款网络协议数据分析工具,利用Netmon可以捕获网络数据并进行查看和分析. 在处理SQL Server 的连接问题时,Netmon常常会起到关键的作用.在本篇博文中,我将为大家

SQL Server 命名实例更改端口进行发布订阅

原文:SQL Server 命名实例更改端口进行发布订阅 两台数据库服务器,都没有加入域,都安装多实例,端口也不一样了.现在使用命名实例进行复制,折腾了好久,才发现解决方法. 服务器A:myserverA MSSQL命名实例: mymssql MSSQL端口:14433 服务器B:myserverB MSSQL命名实例: mymssql MSSQL端口:14433 正常连接数据库的方法: myserverA\mymssql,14433 但是创建发布订阅时,连不到双方数据库出错! 试了一些方法都不

[SQL Server]数据库的恢复

数据库恢复是和数据库备份相对应的操作,它是将数据库备份重新加载到系统中的过程.数据库恢复可以创建备份完成时数据库中存在的相关文件,但是备份以后的所有数据库修改都将丢失. SQL Server进行数据库恢复时,系统将自动进行安全性检查,以防止误操作而使用了不完整的信息或其他的数据备份覆盖现有的数据库.当出现以下几种情况时,系统将不能恢复数据库. (1)还原操作中的数据库名称与备份集中记录的数据库名称不匹配. (2)需要通过还原操作自动创建一个或多个文件,但已有同名的文件存在. (3)还原操作中命名

SQL Server 系统数据库恢复

标签:SQL SERVER/MSSQL SERVER/数据库/DBA/故障恢复/master 概述 SQL Server 维护一组系统级数据库(称为“系统数据库”),这些数据库对于服务器实例的运行至关重要.每次进行大量更新后,都必须备份多个系统数据库.必须备份的系统数据库包括 msdb.master 和 model.如果有任何数据库在服务器实例上使用了复制,则还必须备份 distribution 系统数据库.备份这些系统数据库,就可以在发生系统故障(例如硬盘丢失)时还原和恢复 SQL Serve