Oracle 备份与恢复基础

Oracle 备份与恢复基础 ：三思笔记

 备份与恢复

A whole database backup is either a consistent backup or an inconsistent backup.

Whether a backup is consistent determines whether you need to apply redo logs after

restoring the backup.

Tablespace Backups

A tablespace backup is a backup of the datafiles that constitute the tablespace. For

example, if tablespace users contains datafiles 2, 3, and 4, then a backup of

tablespace users backs up these three datafiles.

Tablespace backups, whether online or offline, are valid only if the database is

operating in ARCHIVELOG mode. The reason is that redo is required to make the

restored tablespace consistent with the other tablespaces in the database.

Datafile Backups

A datafile backup is a backup of a single datafile. Datafile backups, which are not as

common as tablespace backups, are valid in ARCHIVELOG databases. The only time a

datafile backup is valid for a database in NOARCHIVELOG mode is if:

■ Every datafile in a tablespace is backed up. You cannot restore the database unless

all datafiles are backed up.

■ The datafiles are read only or offline-normal.

such as

compression or incremental backup. You must use RMAN to restore a backup set.

RMAN with Online Backups

Because the database continues writing to the file during an online backup, there is the

possibility of backing up inconsistent data within a block. For example, assume that

either RMAN or an operating system utility reads the block while database writer is in

the middle of updating the block. In this case, RMAN or the copy utility could read the

old data in the top half of the block and the new data in the bottom top half of the

block. The block is a fractured block, meaning that the data in this block is not

consistent.

During an RMAN backup, the Oracle database server reads the datafiles, not an

operating system utility. The server reads each block and determines whether the

block is fractured. If the block is fractured, then Oracle re-reads the block until it gets a

consistent picture of the data.

When you back up an online datafile with an operating system utility (rather than

with RMAN), you must use a different method to handle fractured blocks. You must

first place the files in backup mode with the ALTER TABLESPACE BEGIN BACKUP 

statement (to back up an individual tablespace), or the ALTER DATABASE BEGIN

BACKUP statement (to back up the entire database). After an online backup is

completed, you must run the ALTER TABLESPACE ... END BACKUP or ALTER

DATABASE END BACKUP statement to take the tablespace out of backup mode.

1备份：

所谓备份就是冗余，本质是将当前的数据复制一份（或多份）到其他位置

1.1 备份类型

  1 物理备份：核心是复制文件，数据文件，日志文件，控制文件，归档文件等oracle数据库启动的相关文件，复制到其他路径或存储设备中

  2 逻辑备份：核心是复制数据，按照oracle提供的命令，通过逻辑的方式直接将数据保存到其他位置，包括exp，expdp，dblink+ctas等，

1.2 数据库状态

     启动和关闭状态，

      1 热备份：db处于启动状态创建的备份，联机备份，这种状态下创建的备份是不一致备份，利用不一致备份进行恢复时，可能需要利用到归档日志和在线重做日志，db必须出具归档状态，archived

      2 冷备份：db处于关闭状态时创建的备份，脱机备份，利用冷备份恢复时，如果数据库正常关闭，则不需要进行恢复，否则也需要归档跟redo log才能将db恢复到一个一致性的状态，

处于open read only状态，创建的备份也是冷备份

 1.3 备份的状态

1 一致性备份：备份的data file跟control file有相同的scn，即一致性备份，（必须是冷备份）

2 不一致备份：通常db处于open read write或shutdown abort等时都不会是一致性状态，因为备份操作不可能同时完成，data file 随便都是写，scn随时都在变，

  热备份肯定是不一致备份,但不一致备份不一定是热备份（shutdown abort）

  只有archived模式下的不一致备份才是有效备份

 1.4 备份规模

1 完全备份：完成备份，包含data file，redo log，control log，init ora，archived log等

  归档模式下

    数据库处于正常打开状态下的备份是不一致备份（有效）

    Db正常关闭的备份是有效备份

  非归档模式

    数据库处于正常打开状态下的备份是不一致备份（无效）

    Db正常关闭的备份是有效备份

 2表空间备份

  备份一个或多个tablespace，实质是备份data file，当满足一下2个条件之一才是有效备份

   数据库处于归档模式，tablespace处于offline或read only状态

 3 备份数据文件

  备份一个或多个data file，大多数情况db处于archived模式，或者db处于 open read only

 4 控制文件备份

   备份control file，控制文件是db 到mount状态的必须条件

 5 归档日志文件备份

  归档日志保存了数据库曾经做过的操作，数据库处于归档模式或者force logging模式

2 恢复

  有有效的备份，才能更好的恢复

2.1 错误类型

   1 用户误操作导致的错误

   由于用户误操作的执行某些语句，需要撤销某些操作

   2 系统进程出现的错误

   3由于instance导致错误

    实例错误可能导致：提交的事务要修改的数据还未写到数据文件

                      未提交的事务已经修改了数据文件

  对于实例错误，下次在启动实例时，自动尝试进行实例恢复instance recovered

       4 存储介质导致的错误

        由于硬件问题出现，可能导致db崩溃，data file 等文件破坏，需要进行介质恢复，

2.2恢复类型

     1 实例恢复：由oracle自动恢复，通过读取当前的数据文件跟日志文件（不是归档日志）来恢复数据，使数据文件和控制文件恢复到崩溃前的一致性状态

         1 缓存恢复：恢复过程中已提交的事务但没写到数据文件，前滚

         2 事务恢复：前滚后，把没有提交的事务但是已经修改了数据文件的事务回滚，回滚

      2 介质恢复：需要利用到备份来进行恢复，或重新利用日志文件

          介质恢复是首先把db恢复到备份的状态，然后利用redo日志把db恢复到最近时间点（或某个时间点），通常提到的介质恢复都是修复数据文件。

2.3 恢复方式

     1 完全恢复：

将db恢复到最近时间点的恢复方式就是完全恢复，这种方式通常是当磁盘故障导致数据文件或控制文件无法访问时选择的恢复方式（还可以对表空间或数据文件进行完全恢复）

        如果对整个数据库做恢复，

        Mount数据库

        确认所有数据文件均为online状态，

        执行恢复操作，

        应用所有生成的redologs文件

       如果对表空间或数据文件进行完全恢复

        Open 数据库

        将要恢复的表空间或数据文件设置为offline状态

        执行恢复操作

        应用所有生成的redologs文件

   2 不完全恢复

     不完全恢复就是将db恢复到非当前时刻，只利用部分redo跟归档日志，恢复到知道的scn或者指定的时间点的状态，（基于时间点的恢复）

     不完全恢复使用于以下情况

       介质损坏导致部分日志不可用

       用户误删数据，无法逻辑恢复

       由于丢失部分归档，无法进行完全恢复

       控制文件丢失，只能以备份的控制文件打开数据库

要进行不完全恢复，必须要有适当的备份，并且备份是在恢复之前的时间点创建的，

首先利用备份恢复到备份时的状态，然后利用重做日志在恢复到指定的时间点，最后以

Open resetlogs打开db

 由于不完全恢复只利用了部分日志，需要给oracle指定结束标志

 基于时间：指定一个时间点

 基于scn：指定scn号，在oracle中，scn可以转换成时间点，scn更加精确

 基于cancel：应用所有能应用的日志，直到用户取消

 基于日志序号：指定归档日志文件序号

2.4 恢复操作：

1 db的恢复是指将db恢复到一个一致性的状态，

恢复操作可分为：数据修复和恢复

      修复：将要恢复的文件从备份集中读取出来，并保持到指定的路径，

      恢复：应用所有重做日志，将db恢复到崩溃前的状态，或者应用部分redo，恢复到指定的时间的状态，

   2 Resetlogs操作

  在执行完不完全恢复操作或者使用了备份的控制文件进行恢复或者执行了flashback database操作之后，在打开数据库时必须指定resetlogs

     必须在执行完不完全恢复后，以resetlogs操作，日志文件序号重置到1

 

 Resetlogs操作：

  归档当前的在线日志，然后清空日志，并把日志序号重置为1，（如果在线重做日志文件不存在，则重建）

 重置控制文件中关于在线日志文件的元数据

 更新数据文件和redo中的resetlogs scn 和重置时间信息，