Oracle数据库备份恢复的概念：错误类型、实例恢复方法等

1.明确Oracle数据库中可能发生的错误类型; 

2.描述实例恢复的方法; 

3.明确checkpoints,redo log files和archive log files的重要性; 

4.配置快速闪回区; 

5.配置归档模式;

Part of Your Job

DBA的职责就是要保证数据库是可使用的而且是高效的; 

1.避免数据库发生常规错误:比如用户无权限,表空间不足等等; 

2.增加MTBF(Mean Time Between Failures),即两次发生故障的时间间隔; 

3.使用冗余方式保护关键组件,主要是硬件冗余的方式:比如使用RAC,DG等技术; 

4.减少MTTR(Mean Time To Recover),即发生错误时的恢复时间; 

5.最小化数据丢失,提交的数据保留,未提交的数据丢失:使用archive log files,flashback technology, dataguard技术;

Categories of Failure

1.语句级别错误:比如select,insert,update,delete错误; 

2.用户进程错误:比如一个数据库的会话失败了; 

3.网络错误:数据库的连接丢失; 

4.用户错误:比如删除了一个表,删除了一个用户等等; 

5.实例错误:比如数据库突然宕机; 

6.媒体错误:比如因为磁盘损坏或者OS级别删除而丢失了数据库文件;

Statement Failure

1.试图往表中插入非法数据:需要程序前端做验证,或者让用户修改数据; 

2.尝试执行某个操作时权限不足:需要dba授权某个对象权限或者系统权限; 

3.尝试分配空间失败:开始可重新开始的空间分配,增加用户的磁盘配额,对表空间添加空间; 

4.应用程序中的逻辑错误:需要开发人员去修改程序错误;

TIPS:这个过程大部分是因为设计错误,例如安全机制和配额规则;需要DBA参与进来处理错误,比如为用户添加权限,分配空间,同时也要参与查看逻辑错误的过程;

User Process Failure

用户突然中断连接,异常结束或者是程序错误导致的会话中断:不需要DBA去处理,实例后台进程会回滚未提交的改变并释放相关的锁; 

PMON后台进程会阶段性的检查Server Processes,并检查他们的会话是否连接;如果PMON发现某一个Server Process不再连接了,则会恢复增在进行的事务(回滚未提交事务和释放相关的锁); 

如果是少量的错误则不需要关心,只需要让用户重新做一次相关操作即可;如果是大量的连接错误,则需要检查是不是设置的processes参数太小了,或者对用户进行培训;

Network Failure

1.监听失败:配置一个备用的的监听器进行连接超时的故障转移; 

2.NIC失败:配置多个网卡; 

3.网络连接失败:配置备用的网络连接; 

解决的方式就是通过做冗余来提供高可用;

User Error

1.用户无意(inadvertently)删除或者修改了数据:如果没有提交的话,不需要任何处理;否则需要使用闪回或者回退表; 

2.用户误删除了一个表:从回收站恢复;如果使用了purge选项的话,则需要使用基于时间点的恢复(PITR, Point-in-time Recovery)来还原表;

Flashback Technology

1.查看数据之前的状态; 

2.使数据在一个时间段内反复的回放,类似于磁带一样可以前后倒带(back and forth,反复的,来回的) 

3.帮助用户做错误分析和恢复; 

4.Error Analysis: 

• Flashback Query:闪回查询,可以查看表中过去一个时间点已提交的数据;使用AS OF子句; 

• Flashback Versions Query:闪回版本查询,可以查看表中已提交的数据各个版本变化的过程; 

• Flashback Transaction Query:闪回事务查询,可以查看事务级别数据库的改变;

5.Error Recovery:

• Flashback Transaction Backout:事务回退,可以回退指定的事务和它依赖的事务; 

• Flashback Table:删回表,可以回退一个或者多个表的内容到之前的一个时间点,而不影响其它的数据库对象; 

• Flashback Drop:从回收站中恢复已删除的表; 

• Flashback Database:使整个数据库都回退到过去的某个时间点

Instance Failure

1.典型的错误有断电,硬件出错,核心的后台进程出错,紧急关机等;一般不需要DBA的干预,在实例启动时会自动进行实例恢复的过程; 

2.需要实例恢复时因为数据库实例在关闭的之前没有把内存中的数据和数据文件进行同步;

Understanding Instance Recovery:CKPT Process

1.检查点事件由CKPT后台进程触发,当检查点发生时,CKPT进程会负责通知DBWR进程将脏数据(Dirty Buffer)写出到数据文件中;CKPT进程的另外一个职责是负责更新数据文件头和控制文件上的检查点信息; 

2.检查点分为增量检查点和全量检查点两种; 

3.日志切换的过程中,CKPT进程也会把检查点信息写入到数据文件头中; 

4.检查点存在的原因:

• 保证内存中修改的数据块定期写入磁盘,以至于在系统失败或者数据库失败的时候不会丢失数据;(数据有修改就写入,影响性能) 

• 减少实例恢复的时间;(如果一直不写入,效率高) 

• 保证关机的时候所有已提交的数据都写入到了数据文件中

5.检查点信息包括检查点的位置,SCN,RBA(Recovery Block Address)和日志的信息等等

Understanding Instance Recovery:Redo Log Fiels and Log Writer

1.什么是事务; 

• ACID特性:原子性(Atomicity),一致性(Consistency),隔离性(Isolation),持续性(Durability); 

• 事务是数据库内的逻辑单元,是有一条或者多条sql语句组成; 

• 在实例返回给用户commit complete之前,必须把事务信息写入到磁盘上,这样就强制保证了数据在丢失之后可以被恢复

2.Redo log files: 

• 记录了数据库中的一切改变,以事务为单位; 

• 可以预防数据丢失,比如突然断电,磁盘损坏等情况; 

• 推荐采用多路复用放在不同磁盘的方式,每隔在线日志组可以包含多个在线日志文件,它们互为镜像; 

• LGWR进程对在线日志组中日志文件同时写,是循环使用的存储空间

3.LGWR进程出发的条件: 

• 事务提交时; 

• 每隔三秒钟; 

• 在DBWn写之前; 

• 在clean shutdown之前,即除了shutdown abort

Understanding Instance Recovery

1.数据库的实例恢复是自动完成的; 

2.主要是因为没有正常的关闭数据库,在数据库启动时检查数据文件与控制文件中记录的信息不一致,数据库判断需要做实例恢复; 

3.需要做的工作是使用在线日志组的内容来同步数据文件,主要包含两个过程: 

• 前滚:把redo log file中记录的日志条目都重新做一边,包括提交和未提交的; 

• 回滚:把未提交的事务都回滚掉

Phases of Instance Recovery

1.当数据库启动到mount状态后,要打开数据文件,此时要检查数据文件头记录的SCN和控制文件中记录的SCN是否一致;如果一致的话就正常打开数据库; 

2.如果不一致的话,实例会按照顺序应用在线重做日志中的改变,提交和未提交的事务都在这个阶段被重新执行; 

3.当数据文件和控制文件同步之后,会打开数据库,用户可以登录并进行操作; 

4.之后会读取UNDO中数据来回滚为提交的事务;最终,只有提交的数据会保留

Tuning Instance Recovery

1.实例恢复的过程中,会从上次发生checkpoint的位置一直应用到在线日志的末尾处; 

2.所以,实例恢复调优本质就是控制检查点到日志结尾的距离(事务量); 

3.为了数据库性能,要隔一段时间才把Buffer Cache中的脏数据写入到数据文件,因为DBWRn进程要比LGWR进程慢很多; 

4.每隔3s,CKPT进程会把redo log中当前的checkpoint位置写入到控制文件中,因此数据库就知道在线日志组中哪些日志实体是在恢复中需要的,哪些是不需要的; 

eg:控制文件的心跳就是3s一次,可以通过3s转储2次控制文件信息查看,也可以通过alert文件查看; 

5.实例恢复的时间就是应用上次checkpoint的位置到控制文件总记录最新SCN的位置这些日志所需要的时间,DBA通过设置fast_start_mttr_target参数和设置在线日志组大小来控制这个时间(数据库内部机制保证了,上次发生检查点的位置到在线日志结尾的距离不能超过日志组中最小日志文件的90%)

Using the MTTR Advisor

1.指定实例恢复的期望时间,可以使用EM操作也可以在sqlplus中设置(show parameter fast_start_mttr_target); 

2.默认值是0,即禁用,由系统自行决定;如果设置了fast_start_mttr_target的值,则由MTTR向导(EM->Advisor Central->MTTR Advisor)转换这个值来设置其它参数来达到期望的时间内恢复; 

3.最大值是3600s; 

4.tips:如果fast_start_mttr_target这个值设置太小的话,会增加I/O负载,如果太大的话,则恢复时间太长;

Media Failure

1.磁盘驱动器,磁盘控制器损坏,或者数据文件被删除/损坏;主要是包括数据文件,控制文件或者在线日志文件损坏; 

2.从备份中还原,如果必要的话把数据库还原到一个新的位置等;

Configuring for Recoverability

为了配置数据库的最大可恢复行,必须做的几项操作: 

1.制定常规备份策略:大部分的媒体错误都需要从备份中恢复损坏或者丢失的文件; 

2.控制文件多路复用:相当于数据库的大脑,推荐使用至少两份控制文件,如果所有控制文件都丢失恢复起来相当困难; 

3.在线日志组多路复用:在实例恢复和媒体恢复时都需要使用到在线联机日志,用于对提交事务的前滚操作;如果丢失在线联机日志的话,就可能丢失数据,推荐每个日志组至少包含两个日志文件并且放在不同的磁盘上

4.打开归档模式:如果一个数据文件丢失的话,从备份中恢复需要使用到备份后所有的日志文件,在线联机日志文件是循环使用的,内容会被覆盖,所以需要把内容拷贝到归档日志文件中;就是所谓的归档模式,虽然打开之后会对数据库性能有一定影响,但是这个是非常有必要的;查看命令archive log list

Configuring the Fast Recovery Area

1.快速闪回区是一块存储空间,用来存放归档日志,备份,闪回日志,多路复用的控制文件和多路复用的在线日志文件; 

2.强烈推荐用于备份存储管理,应该把这个目录与数据库的数据文件,控制文件,主要在线日志文件的目录放在不同的磁盘上; 

3.快速闪回区的空间理论上是越大越好,但是推荐至少是数据库文件(数据文件,在线日志文件,控制文件等)大小的两倍; 

4.快速闪回区中的内容自动被备份保留策略管理,Oracle数据库会自动删除那些还原不需要的文件;rman target /;show all; 

5.设置快速闪回区:设置db_recovery_file_dest_size和db_recovery_file_dest参数;有顺序设置

Multiplexing Control Files

1.控制文件是一个非常小的二进制文件,用来描述数据库结构信息;在数据库mount或者open状态下,必须可用;如果没有控制文件的话,数据库不能被mount,此时可以还原控制文件或者重建重置文件; 

2.如果丢失一个控制文件的话,恢复很简单,只需要做个拷贝即可;如果全部丢失的话,恢复起来非常困难,但是也不算是个灾难; 

3.如果使用ASM的话,在+DATA和+FRA各放一份控制文件即可; 

4.如果是文件系统的话,推荐至少两份拷贝,而且放在不同的磁盘上,增加控制文件的步骤:

• 修改spfile中初始化参数:ALTER SYSTEM SET control_files='/u01/app/oracle/oradata/ORCL/control01.ctl','/u01/app/oracle/fast_recovery_area/ORCL/control02.ctl','/u01/app/oracle/oradata/ORCL/control03.ctl' scope=spfile; 

• 关闭数据库:shutdown immediate; 

• 拷贝文件:cp/u01/app/oracle/oradata/ORCL/control01.ctl/u01/app/oracle/oradata/ORCL/control03.ctl; 

• 启动数据库:startup;

Redo Log Files

1.每个联机在线日志组中可以包含1个或者多个在线联机日志文件,一组中的多个文件互为拷贝;目的是用来预防媒体错误或者数据丢失,但是多个数据文件会增加数据库的I/O(事务只有当日志条目写入到磁盘之后才能返回成功,所以必须把联机日志文件放在快速磁盘上,而且要把不同的文件放在不同的磁盘上,因为一次只能写一个文件,而且如果磁盘损坏的话也有备份); 

2.建议每个日志组至少两个文件,如果是文件系统的话分别放在不同的磁盘上,如果是ASM的话分别放在+DATA和+FRA即可; 

3.如果丢失日志组中的一个成员的话,不会影响数据库的操作,但是会在alert日志中写警告;如果丢失一个日志组的话,会发生验证的媒体错误,导致丢失数据;恢复的方式会在管理2中介绍;

Multiplexing the Redo Log

1.通过EM添加在线日志组和在线日志文件,EM->Server->Redo Log Groups; 

2.通过sqlplus添加在线日志组合在线日志文件; 

• 查看当前日志组状况:SELECT * FROM v$logfile; 

• 日志文件组中添加数据文件:ALTER DATABASE ADD LOGFILE MEMBER '/u01/app/oracle/oradata/ORCL/redo01A.log' TO GROUP 1; 

• 添加日志文件组:ALTER DATABASE ADD LOGFILE GROUP 4 ('/u01/app/oracle/oradata/ORCL/redo04A.log','/u01/app/oracle/oradata/ORCL/redo04B.log') SIZE 50M;

Archive Log Files

1.因为在线联机日志组是一个循环使用的内存,为了数据库的最大可恢复性,需要在联机日志文件组在被覆盖之前做一个拷贝,称之为归档日志; 

2.配置归档日志需要有三个步骤: 

• 指定归档日志的命名规则; 

• 指定一个或者多个归档日志的路径; 

• 设置数据库到归档模式,之前归档日志路径必须存在;

3.如果使用了快速闪回区的话,那么可以不用设置前两步

Archiver(ARCn) Process

1.是一个可选的后台进程,当数据库为ARCHIVELOG模式的时候自动启动; ps -ef | grep arc; 

2.保存数据库中所有的改变,由log_archive_max_processes参数控制进程的个数; 

3.归档模式下,每次发生log switch时调用archive进程;非归档模式下没有这个进程

Archive Log File:Naming and Destinations

1.使用EM修改:EM->Availability->Configure Recovery Settings; 

2.使用sqlplus修改log_archive_format参数,推荐为%t_%s_%r.dbf; 

• %s:sequence number,日志文件的序号; 

• %t:thread,线程号; 

• %r:resetlogs id,主要是为了保证以resetlogs模式打开数据库后归档日志的名字能保证唯一性,10g之后的新特性; 

• %d:database id,数据库id,只有在多个数据库共享归档日志路径时才会使用

3.默认的,如果开启了快速闪回区,则USE_DB_RECOVERY_FILE_DEST就指定了归档日志文件的路径;如果想修改为其它路径的话,则ALTER SYSTEM SET log_archive_dest_1='location=/path'; 

4.11gR2中可以最多写入到31个不同的目录,由log_archive_dest_n参数指定,目标路径可以是本地的也可以是远程的

Enabling ARCHIVELOG Mode

sqlplus / as sysdba 

shutdown immediate 

startup mount 

alter database archivelog; 

archive log list; 

alter database open;

本文来自云栖社区合作伙伴“DBGEEK”