oracle恢复原理.docx
- 文档编号:30017995
- 上传时间:2023-08-04
- 格式:DOCX
- 页数:46
- 大小:45.50KB
oracle恢复原理.docx
《oracle恢复原理.docx》由会员分享,可在线阅读,更多相关《oracle恢复原理.docx(46页珍藏版)》请在冰豆网上搜索。
oracle恢复原理
1 简介
Oracle数据库提供了下列两类失败模式下的数据库恢复:
1.实例失败:
丢失了Oracle数据缓存中的数据或者内存中的数据
2.介质失败:
丢失了数据库文件
上面两种模式的任一种失败情景,在恢复的时候想要保证数据库一致性,都有一些前提条件必须满足。
虽然恢复的过程有一些共同点,但前提条件的差异使得恢复的执行也有很大差异:
1.实例恢复:
恢复Oracle数据缓存中丢失的数据
2.介质恢复:
恢复数据库文件丢失的数据
1.1 实例恢复和介质恢复的共同的机制
实例恢复和介质恢复都依赖重做日志。
重做日志由一些重做日志线程组成。
单实例环境中重做日志只有一个重做线程,多实例环境中每个实例都有一个重做线程。
一个重做日志线程指的的是一组存放在操作系统上的文件,文件里记录了该实例对数据库的所有变更--已提交的变更和未提交的变更(后者指还存在Oracle数据缓存区中的数据块变更)。
因为实例也修改了回滚段中的块,所以回滚段的变更也记录在重做日志线程中。
实例恢复和介质恢复的第一步都是前滚。
前滚属于数据库恢复层面的。
在前滚的过程中,重做日志中记录的数据变更被重新应用到数据文件中。
因为回滚段的变更也记录在重做日志中,所以前滚过程还会重新构建回滚段块。
当前滚结束时,重做日志中记录的所有变更都应用到数据文件上了。
此刻,数据块不仅包含了已经提交的数据,也包含了一些未提交的数据。
实例恢复和介质恢复的第二步就是回滚。
回滚属于数据库事务层的任务。
回滚过程中,回滚段中记录的由前滚导致的未提交的事务所做的修改将被撤销。
1.2 实例失败和恢复,崩溃失败和恢复
实例失败指当实例突然终止时(如因为shutdownabort或主机掉电),实例数据缓存中的内容就都丢失了。
崩溃失败指数据库的所有实例都同时失败。
单实例环境中实例失败等同于崩溃失败。
崩溃恢复指的是将所有实例都恢复到崩溃前的一致状态。
这一切都是在命令alterdatabaseopen之后自动进行的,用户无法干预。
实例失败会损害数据库的一致性因为它导致该实例的脏数据丢失。
所谓“脏数据”就是指实例数据缓存中的数据块内容比数据文件上的要新。
当实例崩溃时,还没有来得及将脏数据写入到数据文件中。
之所以导致存在这个脏数据丢失问题是因为Oracle的缓存管理采用的是有利于事务处理性能的算法而不是有利于防止实例崩溃的。
如下这些有利于性能调优的缓存管理算法使得实例恢复过程有点复杂:
1.LRU(最近最少使用)缓存替换算法
2.提交时不强制将脏数据刷新到数据文件中
上面的算法导致实例失败时对数据库完整性的损害体现在如下几点:
A.在实例崩溃时,数据文件中可能包含一个原子事务修改的所有块中的部分块而不是全部
B.在实例崩溃时,数据文件中可能包含一些未提交事务修改的块
C.在实例崩溃时,一些已提交事务修改的块可能还没有刷新到数据文件中,数据文件中包含的是该事务修改之前的数据块。
在实例恢复过程中,数据库恢复层修复了上面的损害点A和C,然后后续的数据库事务层修复了损害点B。
除了那些用来修复数据库完整性损害的前提条件外,实例恢复还需要满足一些前提条件:
1.实例恢复必须在联机的数据文件上进行恢复。
2.实例恢复必须使用联机重做日志文件,不能要求使用归档重做日志文件。
虽然实例恢复也可以通过使用归档重做日志文件进行恢复(数据库运行在非归档模式除外),但那种恢复过程在要求用户先还原归档日志文件的的时候是不能自动进行的。
3.实例恢复过程的调用是自动的,隐含的在下次数据库启动的时候被调用。
4.实例恢复过程中侦测修复的文件或修复过程本身都是自动进行的,无需人工干预。
5.实例恢复中前滚时间的长短是由Oracle数据库内部机制(checkpoint)和用户配置的参数(如日志文件的大小和数量,checkpoint的频率,并行恢复的参数等)决定的。
综上所述,Oracle的内存管理策略适合于性能调优而不是降低实例崩溃的影响。
本文描述了Oracle为解决采用这种LRU和提交不刷新数据块的算法带来的问题所用到的一些内部机制。
这些机制保证了实例恢复的前提条件得到满足同时又兼顾了数据库性能。
这些机制如下:
1.提交前先刷新日志块
这个机制修复损害C,保证了在事务提交的时候,所有跟该事务有关的重做日志记录包括提交记录都已经写入到重做日志文件中。
2.检查点机制
界定了实例恢复时必须应用的重做日志的量。
这一点跟联机日志切换结合起来使用确保实例恢复的时候只需要联机重做日志和当前联机数据文件。
3.联机重做日志切换机制
跟检查点机制结合起来使用确保实例恢复的时候只需要联机重做日志和当前联机数据文件。
它保证当前的检查点总是超前即将被重用的联机重做日志文件。
4.写日志优先
这个机制修复损害A,B,因为a)在实例崩溃时刻,数据文件上的所有变更都在重做日志中找到记录;b)所有数据块在写到数据文件之前都先写入跟回滚段和数据块的重做记录。
5.写重做日志记录是原子的
这个机制可以修复损害A,B。
(注:
每笔重做日志记录都是由三个部分组成:
重做日志记录头,回滚段改变向量,数据库改变向量。
这三部分在写入重做日志时是原子的,不可分割的!
)
6.线程打开标志位
用于数据库启动时判断是否需要崩溃恢复。
1.3 介质失败和恢复
实例失败影响逻辑上的数据库完整性。
因为实例失败的时候数据文件是可以恢复到一致状态的,实例恢复以当前数据文件为起点,用联机重做日志进行恢复。
介质失败则不同,影响的是物理上的数据库完整性或可用性。
因为数据文件已经损坏,介质恢复要先还原该数据文件的备份作为介质恢复的起点,用归档重做日志和联机重做日志做前滚操作,直至数据文件备份后实例崩溃前最近的一个一致状态或者数据文件备份后实例崩溃前的任意一个一致状态。
介质恢复操作必须由下面命令来执行:
RECOVERDATABASE,RECOVERTABLESPACE,RECOVERDATAFILE。
根据失败场景分析,介质失败对数据库完整性的破坏可能跟实例失败一样。
如当一个块被读入到数据缓冲区中修改后正要被DBWR进程将更新后的数据块写回到数据文件中时发生I/O故障,也可能导致前面提到的A,B,C三点损害.此外,介质失败时不仅仅是当前脏数据永久丢失了,而且该数据文件上自上次备份后的所有更新的都丢失了。
在介质恢复之前,必须先还原被损坏的数据文件。
然后在这些数据文件上应用相关的归档日志和联机重做日志前滚到介质失败前的一致状态。
介质恢复和实例恢复上面提到A,B,C三种损害有一些共同的前提条件。
然而介质恢复和实例恢复的前提条件还是有如下五点不同:
1.介质恢复前必须先还原受损坏的数据文件。
2.介质恢复除了要求联机重做日志外还要有归档重做日志。
3.介质恢复必须显示调用,需要人工干预。
4.介质失败不能自动被侦测到。
只有在某个数据文件或数据库备份被还原的时候才能自动侦测到需要介质恢复。
5.介质恢复所用的前滚时间长短是由用户备份策略决定的(如备份的频率,并行恢复参数等),而不是有Oracle内部机制决定。
2 基础数据结构
2.1 Controlfile
控制文件包含了数据库中所有其他文件的状态信息。
控制文件包含了如下几类数据:
A.数据库信息记录(一条)
B.数据文件记录(每个数据文件一条)
C.线程记录(每个线程一条。
注:
每个实例一个线程)
D.日志文件记录(每个日志文件一条)
E.文件名记录(每个数据文件或者日志文件成员一条)
F.日志历史记录(每个已经完成的日志文件一条)
控制文件的被后面文档引用到的字段如下,后面是引用该字段的章节:
2.1.1 数据库信息记录(控制文件)
所含字段:
A.resetlogstimestamp:
8.2
B.resetlogsscn:
8.2
C.enabledthreadbitvec:
8.3
D.forcearchivingscn:
3.8
E.databasecheckpointthread(threadrecordindex):
2.13,3.10
2.1.3 数据文件记录(控制文件)
A.threadcheckpointstructure:
2.12,3.4,8.3
B.thread-openflag:
3.9,3.11,8.3
C.currentlog(logfilerecordindex)
D.headandtail(logfilerecordindices)oflistoflogfilesinthread:
2.8
2.1.4 日志文件记录(控制文件)
A.logsequencenumber:
2.7
B.threadnumber:
8.4
C.nextandprevious(logfilerecordindices)oflistoflogfilesinthread:
2.8
D.countoffilesingroup:
2.8
E.lowSCN:
2.7
F.nextSCN:
2.7
G.headandtail(filenamerecordindices)oflistoffilenamesingroup:
2.8
H."beingcleared"flag:
10.3
I."archivingnotneeded"flag:
10.3
2.1.5 文件名记录(控制文件)
A.filename
B.filetype
C.nextandprevious(filenamerecordindices)oflistoffilenamesingroup:
2.8
2.1.6 日志文件历史记录(控制文件)
A.threadnumber:
2.11
B.logsequencenumber:
2.11
C.lowSCN:
2.11
D.lowSCNtimestamp:
2.11
E.nextSCN:
2.11
2.2 数据文件头
数据文件头部分的被后面文档引用的字段如下,后面跟的是引用该字段的章节:
A.datafilecheckpointstructure:
2.14
B.backupcheckpointstructure:
4.1
C.checkpointcounter:
2.16,3.4,5.3,6.2
D.esetlogstimestamp:
8.2
E.resetlogsSCN:
8.2
F.creationSCN:
8.1
G.online-fuzzybit:
3.5,6.7.1,8.1
H.hotbackup-fuzzybit:
4.1,4.4,6.7.1,8.1
I.media-recovery-fuzzybit:
6.7.1,8.1
2.3 日志文件头
日志文件头部分的被后面文档引用的字段如下,后面跟的是引用该字段的章节:
A.threadnumber:
2.7
B.sequencenumber:
2.7
C.lowSCN:
2.7
D.nextSCN:
2.7
E.end-of-threadflag:
6.10
F.resetlogstimestamp:
8.2
G.resetlogsSCN:
8.2
2.4 改变向量(ChangeVector)
改变向量表示对数据块的一次变更。
改变向量头部记录了发生变更的数据块的DBA地址,该块的版本号,序列值和操作代码。
头部以后的内容跟具体的变更操作有关。
数据块版本号和序列值是在创建改变向量时从数据块的头部复制过来的。
当块被更新后,版本号值就比原来的值大一点,而序列号则被设为1。
此后数据块每变更一次,序列值就增长1.
2.5 重做记录
一个重做记录是由一组改变向量组成,代表一个数据库变更。
如一个事物的重做记录由三部分组成。
首先是事务表(回滚段段首)的改变向量,再次是回滚块的改变向量,最后是数据块的改变向量。
一个事物可以产生多个重做记录组成。
一个重做记录是数据库恢复的最小单位,一个重做记录由多个改变向量组成的机制允许多个数据块被修改并且这些修改要么都发生要么就都没发生,即使发生突然的失败。
这种原子性是由数据库缓冲层的一个基础Job来保证的。
Oracle恢复保证重做记录是不可分割的,即使在数据库失败的时候。
2.6 SystemChangeNumber(SCN)
SCN描述了数据库的一次事物提交版本。
一次查询也是查询数据库的某个SCN产生时刻时的内容。
SCN会被分配和保存在事务的重做记录的头部。
SCN也会保存在控制文件和数据文件中。
SCN是由48位长的数字组成。
2.7 重做日志
所有数据块的变更发生时都是先构建一个重做记录,然后把这个重做记录保存到重做日志中,最后在数据块中应用该变更。
恢复的过程就是在老的数据块上应用重做日志是该数据块变成当前的数据块。
这个过程在当前版本数据丢失的情况下是必须的。
当一个重做日志文件写满了时,就会发生日志切换。
每个日志是由一个线程号标识,序列号(一个线程以内再分)和该日志跨越的SCN范围。
这些信息保存在日志文件头中。
重做日志文件中的重做记录是根据SCN排序的。
此外,重做记录中包含的具体数据块的改变向量也是按SCN递增顺序发生的,即使是跨多个线程(这种情况发生在多个实例环境中)。
只有某些重做记录头部包含有SCN信息,但是所有的记录都是在某个SCN被分配后才发生的。
日志文件的头部包含了最小的SCN和下一个SCN。
最小的SCN是这个日志文件中第一个重做记录对应的SCN。
下一个SCN是当前日志序列递增后的下一个日志文件的的最小SCN。
当前在使用的重做日志的下一个SCN都是无限大,因为还没有日志文件的序列号比当前日志的序列要大。
2.8 重做线程
每个实例产生的重做日志被称为一个重做日志线程。
一个日志线程由联机重做日志和归档重做日志(前提是数据库运行在归档模式下)。
联机重做日志是由两个或更多个日志组组成,每个日志组由一个或更多重复的日志成员组成。
通常说一个日志组,重做日志,联机日志或简称日志都是指一个日志组的成员集合(可能是一个或者多个)。
一个重做日志只包含该日志所属的线程记录的日志。
各个线程在写日志时分配日志文件的序列号是彼此独立的,各个线程的日志组之间的日志切换也是独立进行的。
每个日志文件组在控制文件中都有一笔记录描述它的信息,每笔记录通过日志号码查找。
注意日志号跟日志组的号码是一致的,而且是全局唯一的(多实例环境中)。
每个重做线程的日志文件组列表记录都在每个重做线程记录的后面(类似于一种Head-Detail结构),各个日志文件组的记录中都分别有一个向前和向后的字段记录上一个日志文件组和下一个日志文件组(通过日志文件组号来记录)。
日志文件组的成员信息在日志文件组的记录中描述。
2.9 RedoByteAddress(RBA)
RBA指定了重做日志的位置,长度为10字节,由三部分组成:
日志序号,块号以及块中的字节序号。
2.10 检查点结构
检查点结构定义了数据库重做日志的一个点。
检查点结构信息保存数据文件头部和控制文件中每个重做线程的记录中。
这些检查点结构用于恢复时告诉数据库从哪个重做日志的哪一笔重做记录开始恢复。
检查点结构的关键字段是检查点SCN和当前激活的线程标志。
检查点SCN能有效的定位每个激活中重做日志的任一位置(激活的定义见3.11)。
对于每个重做线程,检查点SCN就是发生一次提交时的时间点以及对应重做日志的位置,根据重做日志文件头部的重做记录可以发现第一笔重做记录产生时分配的SCN是检查点SCN或更高一点.
当前激活的线程标志标记了这个检查点SCN被分配时哪个重做线程处于激活状态。
注意每个线程在激活时都有一个状态位被设置,不管它是打开还是关闭状态。
每个激活的线程都有一个重做日志,重做日志包含该检查点SCN,这点证明了该重做日志存在(联机或者已经归档)。
检查点结构还还保存了这个检查点SCN被分配时的时间戳,这个时间戳只是输出一些信息便于用户查找日志。
此外,检查点结构还保存了检查点SCN被分配时的线程的数量和线程中当前RBA地址。
显示的存储线程的RBA地址(相对于存储SCN作为线程的隐式的指针)使得在单实例环境中日志序列和归档日志名称更容易找到。
检查点在一段时间内可以支持高达1023个重做日志线程,总计150字节长。
2.11 日志历史
2.12 线程检查点
每个激活的线程在控制文件中的记录中都包含了一个检查点结构,我们称之为线程检查点。
这个检查点中的SCN字段就是线程检查点SCN,还有线程序号和RBA字段指明了这个线程检查点跟哪个SCN相关。
线程检查点结构在实例每次对其线程发出检查点操作时被更新(见3.4)。
检查点发生时,跟该实例相关的线程会把重做日志里记录的小于该线程检查点SCN的重做记录保护的脏数据写入到联机数据文件中。
线程检查点事件保证了该线程的重做日志中所有小于该线程检查点SCN的重做记录对应的脏数据都被写入到磁盘(注意到如果该线程关闭了,重做日志里就没有SCN比线程检查点SCN还小的记录。
)
实例恢复的时候要保证对应线程的所有重做日志都应用到数据文件中。
因为线程检查点SCN以前的重做日志已经被应用了,所以实例恢复可以保证,在启动重做日志进程时只要从线程检查点SCN开始应用,直至重做日志文件的尾部,所有线程的重做日志都被应用。
2.13 数据库检查点结构
数据库检查点结构就是所有打开的线程中线程检查点SCN最小的那个线程检查点。
数据库检查点线程的序号--当前线程检查点是数据库检查点的那个线程的序号--被记录在控制文件的数据库信息部分。
因为每个实例都保证对应线程检查点SCN以前的重做日志保护的脏数据已经写到数据文件中,并且数据库检查点SCN是所有线程中线程检查点SCN最小的,所以可以说所有实例中在数据库检查点SCN以前的重做日志记录所保护的脏数据都被写到数据文件中。
换句话说是数据库所有联机数据文件都在数据库检查点时发生了检查点操作。
这就是一个实例检查点了对应线程时用数据库检查点更新了所有联机数据文件检查点(见下面)的基本原理(见3.4)。
2.14 数据文件检查点结构
数据文件检查点结构指的是每个数据文件的头部包含的检查点结构,其中的SCN字段就是数据文件检查点SCN。
由前面而知,针对每个数据文件,在其检查点SCN以前的所有线程的重做日志保护的脏数据都已经被写入到数据文件。
每个联机的数据文件会把它的检查点SCN记录在控制文件中,但这个值可能跟数据文件头部的检查点SCN不一致。
Oracle恢复层设计成能接受这种不一致。
当实例失败发生在更新数据文件头部的检查点之后提交控制文件“事务”之前时,二者没有及时同步造成不一致。
(注:
控制文件“事务”是数据库内部机制,独立于Oracle事务层,指的是保证对控制文件任意大的更新都能够自动被“提交”)。
数据文件检查点执行时(见3.6),数据文件头部的检查点结构会被更新,并且保证所有线程产生的重做日志记录在该检查点SCN以前对应的脏数据都已经被写入到磁盘上了。
线程检查点事件(见3.4)保证了所有线程产生的所有SCN在检查点SCN以前的重做日志记录对应的脏数据都被写入到磁盘了。
线程检查点事件可能会推进数据库检查点(如在单实例环境中;或该线程的检查点最旧了)如果数据库检查点推进了,新的检查点将更新所有联机数据文件的检查点结构(热备份中的数据文件除外,见第4节)。
介质恢复时要保证对即将恢复的数据文件把任一个线程产生的重做日志记录都要应用上去。
由前面知对即将恢复的数据文件来说,每个线程产生的重做日志在该数据文件检查点SCN以前的重做日志都已经得到应用,介质恢复在重新应用日志时只需要从数据文件检查点SCN开始支持恢复结束点。
注:
用户指定结束的SCN或时间点等(不完全回复),又或者是所有线程的结束点(完全恢复)。
因为数据文件检查点保存在数据文件的头部中,所以在数据文件的备份中同样也存在。
如果是热备份产生的备份,热备份保证了当数据文件处于热备份状态时,即使在复制要备份的数据文件过程中数据库要更新该数据文件上的脏数据,数据文件中所有数据库的版本跟数据文件头部的检查点结构的版本是一致的,都是在热备份开始那一刻时的版本。
2.15 结束SCN
每个数据文件在控制文件的记录中都有一个字段叫结束SCN。
如果该数据文件是脱机状态或只读的,该结束SCN的值表示对该数据文件不会有再比这个结束SCN更大的重做记录。
如果该数据文件是联机的并且有一个实例打开了数据库,结束SCN就会被设置为无限大(注:
值为0xffff.ffffffff)。
结束SCN用于介质恢复时告诉重做程序在该数据文件上应用重做日志时到了这个SCN时就停止。
这保证了在数据库打开的状态下恢复一个脱机的数据文件时介质恢复能停下来。
不管数据文件脱机或者只读,结束SCN都会被设置为具体的SCN。
不管脱机操作时“立即”(因为I/O错误导致或者因为数据文件所在表空间被立即脱机)还是“临时的“或“正常的”(数据文件所在表空间正常脱机)。
不过在数据文件被立即脱机时,不会发生数据文件检查点(见3.6),并且对应的脏数据都丢失了。
因此在将该脱机文件变成联机时介质恢复需要重新应用重做日志直至结束SCN。
介质恢复不需要应用结束SCN以后的重做日志,因为就不存在这样的重做日志。
如果结束SCN等于数据文件检查点SCN,那么该数据文件就不需要恢复。
2.16 检查点计数
在数据文件头部和数据文件在控制文件的记录部分都有一个检查点技术。
检查点计数是用来判断数据文件或者控制文件是否是过时的(从一个备份中恢复出来的)。
每次发生线程检查点事件时,检查点计数都会递增。
从而即使数据文件的检查点没有被推进时检查点计数也会增加。
线程检查点事件时数据文件检查点没有被推进的原因可能是数据文件处于热备份状态,或者它的SCN比要更新的检查点SCN值还要新(如数据文件时新增的或者刚经历了一次数据文件检查点事件)。
2.17 表空间干净结束SCN
数据字典TS$有两列表示表空间干净结束SCN(注:
9i中是SCNWRP和SCNBAS组合表示)。
它表示表空间是在这个SCN时被脱机或者设置为只读。
如在对数据文件发出检查点操作后(见3.6),数据文件检查点SCN被记录到TS$中作为表空间干净结束SCN。
这样的表空间在数据库以重置日志方式打开后不需要被删除(见8.6)。
在介质恢复时,以重置日志方式打开日之前,这种表空间会处于脱机状态。
重置日志后,表空间也不需要恢复,允许被直接设置为联机状态或读写状态。
重置日志后建议立即备份表空间。
当把一个脱机且干净的表空间置为联机或者可读写时,表空间干净结束SCN会被设置为0(中间可能短暂性被设置为无穷大)。
立即或临时性的将表空间置为脱机状态,tablespace-clen-stopSCN也会是0.
一个在TS$中表
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- oracle 恢复 原理