比如上面的图：我们规定每到一个时间节点我们就备份一次数据，但是在上面的“现在这个时间节点”处发生了故障，数据丢失了，那么可以利用前一次的备份时间点2进行还原，但是上面的从“备份时间2”到“现在这个时间节点”段的数据使用日志进行恢复。也可以使用“备份时间点1”的作为还原，但是恢复的话，就是从“备份时间点1”到“现在这个时间节点”。

2.备份概述

（1）备份的原则

日志文件归档到磁盘。归档日志文件最好不要与数据库文件或联机重做日志文件存储在同一个物理磁盘设备上。
如果数据库文件备份到磁盘上，应使用单独的磁盘或磁盘组保存数据文件的备份。备份到磁盘上通常可以在较短时间内恢复。
应保持控制文件的多个备份，控制文件的备份应置于不同磁盘控制器下的不同磁盘设备上。增加控制文件可以先关闭数据库，备份控制文件，改变服务器参数文件的参数CONTROL_FILES，再重新启动数据库即可
联机日志文件应为多个，每个组至少应保持两个成员。日志组的两个成员不应保存在同一个物理设备上，因为这将削弱多重日志文件的作用。
保持归档重做日志文件的多个备份，在多个磁盘上都保留备份。使用服务器参数文件中的 LOG_ARCHIVE_DUPLEX_DEST和 LOG_ARCHIVE_MIN_SUCCEED_DEST参数，Oracle会自动双向归档日志文件。
通过在磁盘上保存最小备份和数据库文件向前回滚所需的所有归档重做日志文件，在许多情况下可以使得从备份中向前回滚数据库或数据库文件的过程简化和加速。
增加、重命名、删除日志文件和数据文件，改变数据库结构和控制文件等操作都应备份，因为控制文件存放数据库的模式结构。此外，增加数据文件后也要备份。
若企业有多个Oracle数据库，则应使用具有恢复目录的Oracle恢复管理器。这将使用户备份和恢复过程中的错误引起的风险最小化。

（2）数据库备份的应用

实例失败
磁盘失败

注意：如果丢失的是归档重做日志文件，就无法恢复。因此，最重要的是使归档重做日志文件目标设备也保持镜像。归档重做日志文件与联机重做日志文件同等重要。

（3）数据库备份类型

备份一个Oracle数据库有三种标准方式：导出（Export）（逻辑备份）、脱机备份（Offline Backup）(冷备份)和联机备份（Online Backup） (热备份)。其中导出方式是数据库的逻辑备份。脱机备份和联机备份都是物理备份（也称为低级备份）。

①逻辑备份

逻辑备份。导出是将数据库中数据备份到一个称为“导出转储文件”的二进制系统文件中。

三种模式：

用户模式（user）：导出用户所有对象以及对象中的数据。
表模式（table）：导出用户的所有表或者用户指定的表。
全局模式（full）：导出数据库中所有对象，包括所有数据、数据定义和用来重建数据库的存储对象。

导出备份的三种类型：

完全型：对所有表执行全数据库导出或仅对上次导出后修改过的表执行全数据库导出。
积累型：备份上一次积累型备份所改变的数据。
增量型：备份上一次备份后改变的数据。

提示：导入是导出的逆过程，导入时读取导出创建的转储二进制文件以恢复数据。可以导入全部或部分已导出的数据。如果导入一个完全导出的整个导出转储文件，则所有数据库对象（包括表空间、数据文件和用户）都会在导入时创建。如果只打算从导出转储文件中导入部分数据，那么表空间、数据文件和将拥有并存储那些数据的用户必须在导入前设置好。

②物理备份

物理备份是备份数据库文件而不是其逻辑内容。Oracle支持两种不同类型的物理备份：脱机备份（也称为冷备份）和联机备份（也称为热备份）。

脱机备份：

在数据库已经正常关闭的情况下进行。数据库正常关闭后会给用户提供一个完整的数据库。当数据库处于脱机备份状态时，备份的文件包括所有数据文件、所有控制文件、所有联机重做日志和服务器参数文件（可选）。当数据库关闭时，对所有这些文件进行备份可以提供一个数据库关闭时的完整镜像。以后可以从备份中获取整个文件集并恢复数据库的功能。

提示：冷备份一般在SQL PLUS中进行，在进行备份之前，首先确定备份哪些文件，通过v$DATAFILE视图可以获取数据文件的列表；

select * from v$datafile;

通过v$LOGFILE视图可以获取联机重做日志文件的列表：

select * from v$logfile;

正常关闭要备份的实例：

conn [用户名]/[密码] as sysdba;

shutdown normal;

关于Oracle中的关闭和启动数据库的几种方式（五）

联机备份：

数据库可能要求24小时运行，而且随时会对数据进行操作。联机备份可以在数据库打开的情况下进行。一般通过使用ALTER命令改变表空间的状态来开始进行备份，备份完成后恢复原来状态，否则重做日志会错配，在下次启动数据库时引起表空间的修改。进行联机备份时要求数据库必须在归档方式下操作，在数据库不使用或使用率低的情况下进行，同时要有大量的存储空间。

联机备份也称为热备份或者ARCHIVELOG备份，要求数据库运行在ARCHIVELOG方式之下。Oracle系统以循环的方式编写联机重做日志文件，也就是第一个日志文件写满之后，接着从第二日志文件开始写，……直到写满所有的日志文件之后，又从第一个日志文件开始写（覆盖原来的内容）。

以archivelog方式运行：

第一步：使用管理员的身份连接数据：conn sys/[密码] as sysdba;

第二步：关闭数据库：shutdown immediate;

第三步：启动数据库：startup mount;

第四步：alter database archivelog;

第五步：archive log start;

第六步：alter database open;

从server manger中显示当前数据库的archivelog:

archive log list;

执行数据库联机备份：

一旦以archivelog方式打开并对用户可用时，那么就可以进行备份；

将表空间设置为备份状态：alter tablespace system begin backup;
使用操作系统备份表空间中的数据：copy E:\\Oracle\\TableSpace\\DEMO1.DBF E:\\Oracle\\TableSpace\\copy
指定结束联机备份：alter tablespace system end backup;
备份归档重做日志文件：archive log start;
备份控制文件：alter database backup controlfile to 'E:\\Oracle\\TableSpace\\file.bak'

3.恢复概述

恢复分为：实例恢复和介质恢复。

实例恢复：

在数据库实例的运行期间，当意外掉电、后台进程故障或人为中止时出现实例故障，此时需要实例恢复。如果出现实例故障，由于Oracle实例没有正常关闭，而且当实例发生故障时，服务器可能正在管理对数据库信息进行处理的事务。

实例恢复的目的就是将数据库恢复到与故障之前的事务一致的状态。实例恢复只需要联机日志文件，不需要归档日志文件。实例恢复的最大特点是，Oracle在下次数据库启动时会自动地执行实例恢复。

实例恢复的步骤：

为了解恢复数据文件中没有记录的数据，进行向前回滚。该数据记录在联机日志中，包括对回退段的内容恢复。
回退未提交的事务，按步骤（1）重新生成回退段所指定的操作。
释放在发生故障时正在处理事务所持有的资源。
解决在发生故障时正经历这一阶段提交的任何悬而未决的分布事务。

介质恢复：

如果在联机备份时发现实例故障，则需介质恢复。介质恢复主要在由于存储介质发生故障，导致数据文件被破坏时使用。介质故障是当一个文件或者磁盘不能读取或写入时出现的故障。这种状态下的数据库都是不一致的，这需要DBA手动进行数据库的恢复。这种恢复有两种形式：完全介质恢复和不完全介质恢复。

完全介质恢复：它使用重做数据或增量备份将数据库更新到最近的时间点，通常在介质故障损坏数据文件或控制文件后执行完全介质恢复操作。实施完全数据库恢复时，根据数据库文件的破坏情况，可以使用不同的方法。
不完全介质恢复：是在完全介质恢复不可能或者有特殊要求时进行的介质恢复。

4.导入与导出

（1）导出

Export指定运行期选项
关键字	描述
Userid	执行指定账户的用户名和口令，如果是EXP命令后的第一个参数，则关键字Userid可以省略。
Buffer	用户获取数据行的缓冲区尺寸，默认值随系统而定，通常设定一个高值。
File	导出转储文件的名称。
Full	若设为Y，表示执行Full数据导出。
Tables	导出表的清单，可以执行这些表的Table导出（也就是要导出的表名称）。

EXP USERID=SCOTT/Admin123123@myorcl FULL=N BUFFER=10000 FILE=XSB TABLES=XSB

提示：将表导出之后，可以看到导出的文件是在当前目录下面。

（2）导入

Import指定运行期选项
关键字	描述
Userid	执行指定账户的用户名和口令，如果是imp命令后的第一个参数，则关键字Userid可以不必指定。
Buffer	用户获取数据行的缓冲区尺寸，默认值随系统而定，通常设定一个高值（>100 000）。
File	要导入的导出转储文件名称。
Full	Y/N，若设为Y，表示执行Full数据导入，并导出转储文件。
Table	导出表的清单，可以执行这些表的Table导出。

IMP USERID=SCOTT/Admin123123@myorcl FULL=N BUFFER=10000 FILE=XSB TABLE=XSB

Oracle备份恢复之无备份情况下恢复undo表空间

UNDO表空间存储着DML操作数据块的前镜像数据，在数据回滚，一致性读，闪回操作，实例恢复的时候都可能用到UNDO表空间中的数据。如果在生产过程中丢失或破坏了UNDO表空间，可能导致某些事务无法回滚，数据库无法恢复到一致性的状态，Oracle实例可能宕机，之后实例无法正常启动；如果有多个UNDO表空间数据文件，丢失其中一个数据文件数据库实例可能不会导致实例宕机，数据库无法干净的关闭（只能SHUTDOWN ABORT），数据库实例能正常的重启，但所有未回滚的数据块依然无法处理，尝试新建UNDO表空间、exp、expdp等操作都会收到ORA-604, ORA-376, and ORA-1110的报错，下面通过一个实际的案例讨论如何处理UNDO损坏后的恢复。

如果你的数据库还能干净的关闭，但在正常情况下无法新建UNDO表空间，那么执行以下的步骤：
I.A. THE DATABASE WAS CLEANLY SHUT DOWN
---------------------------------------
If you are ABSOLUTELY POSITIVE that the database was cleanly shutdown,
i.e., it was closed with either shutdown NORMAL or IMMEDIATE, then
the simplest solution is to offline drop the missing datafile, open the
database in restricted mode, and then drop and recreate the undo
tablespace to which the file belonged. DO NOT follow this procedure
if the database was shut down ABORT or if it crashed.
The steps are:
1. Make sure the database was last cleanly shut down.
   Check the alert.log file for this instance. Go to the bottom of
   the file and make sure the last time you shut the database down
   you got the messages:
        "Shutting down instance (immediate)"
   OR
"alter database close normal
         Completed: alter database close normal"
   This also includes the case of a clean shutdown followed by a
   failed attempt to startup the database. In that case, Oracle will
   issue error messages and shut itself down abort. For the purposes
   of this solution, though, this counts as a clean shutdown.
   If that is not the case, i.e., if the last time YOU shut the database
   down it was in abort mode, or the database crashed itself, it is
   NOT safe to proceed. You should follow the instructions for
   case I.B below.
2. If using automatic UNDO_MANAGEMENT, comment out this entry from the parameter
   file, or set it to MANUAL.
将UNDO_MANAGEMENT修改为MANUAL是因为UNDO表空间在自动管理模式下，如果不能成功新建回滚段（后面会DROP现有表空间）将导致数据库实例宕机。
   If using rollback segments, remove all the rollback segments in the
   tablespace to which the lost datafile belongs from the ROLLBACK_SEGMENTS
   parameter in the init.ora file for this instance. If you are not sure about which rollbacks are
   in that tablespace, simply comment out the whole ROLLBACK_SEGMENTS entry.
3. Mount the database in restricted mode.
   SQL> STARTUP RESTRICT MOUNT
以RESTRICT模式启动实例是避免在处理过程中有其他客户端连接。
4. Offline drop the lost datafile.
   SQL> ALTER DATABASE DATAFILE ‘‘ OFFLINE DROP;
5. Open the database.
   SQL> ALTER DATABASE OPEN
   You should receive the message "Statement processed,".
   If instead you get ORA-604, ORA-376, and ORA-1110, it is likely the shutdown
   was not normal/immediate. Review the rest of the options available and/or
   contact Oracle Support Services.
6. Drop the undo tablespace or tablespace which contains rollback segments
   to which the datafile belonged.
   SQL> DROP TABLESPACE INCLUDING CONTENTS;
7. Recreate the undo tablespace. If using rollback segments, recreate the
   rollback segment tablespace and all it‘s rollback segments. Remember to
   bring the rollbacks online after you create them.
SQL> CREATE TABLESPACE UNDOTBS2 DATAFILE <datafile_name< span="" style="word-wrap: break-word;">> SIZE 1G AUTOEXTEND ON NEXT 100M;
8. Edit the parameter file setting:
   UNDO_MANAGEMENT=AUTO
   UNDO_TABLESPACE=
   If using rollback segments, reinclude the rollbacks you just recreated in
   the ROLLBACK_SEGMENTS parameter in the init.ora file for this instance.
   As rollback segments were brought online in step #7, no need to proceed
   with shutdown/startup as needed for undo tablespace. All that is required
   is:
   SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;

如果你的数据库不能正常关闭，只需要在重启数据库实例之前将下面的参数加到参数文件：
_allow_resetlogs_corruption=TRUE
_offline_rollback_segments="_SYSSMU1$"
_offline_rollback_segments="_SYSSMU2$"
_offline_rollback_segments="_SYSSMU3$"
_offline_rollback_segments="_SYSSMU4$"
_offline_rollback_segments="_SYSSMU5$"
_offline_rollback_segments="_SYSSMU6$"
_offline_rollback_segments="_SYSSMU7$"
_offline_rollback_segments="_SYSSMU8$"
_offline_rollback_segments="_SYSSMU9$"
_offline_rollback_segments="_SYSSMU10$"
_corrupted_rollback_segments="_SYSSMU1$"
_corrupted_rollback_segments="_SYSSMU2$"
_corrupted_rollback_segments="_SYSSMU3$"
_corrupted_rollback_segments="_SYSSMU4$"
_corrupted_rollback_segments="_SYSSMU5$"
_corrupted_rollback_segments="_SYSSMU6$"
_corrupted_rollback_segments="_SYSSMU7$"
_corrupted_rollback_segments="_SYSSMU8$"
_corrupted_rollback_segments="_SYSSMU9$"
_corrupted_rollback_segments="_SYSSMU10$"
rollback_segments的具体值可以从v$rollname中获得。
处理完成后停止数据库实例，去掉以上参数，修改好UNDO相关参数即可正常启动数据库实例，之后再手动处理TEMP表空间丢失的TEMP数据文件。
虽然数据库实例能够正常启动，也恢复了UNDO表空间的使用，但这并不代表不一致的块已经恢复，执行某些查询的时候可能会收到报错，数据库完全恢复正常后应该立即执行一次逻辑备份+物理备份，确保数据库的安全。

如果Oracle在运行中很不幸遇到undo损坏，当然最好的方法是完全恢复，不过如果没有备份，可以采用一种非常规的手段（利用Oracle的隐藏参数），如果此时undo包含未提交的事务，会造成一点点的数据丢失（一般都是可忍受的），如果没有未提交的事务，则不会有数据丢失。其主要步骤有：

1. 修改undo表空间管理为手动；
2. 设置隐藏参数(_offline_rollback_segments或_corrupted_rollback_segments)标识受影响的回滚段，使Oracle忽略其上的未提交事务；
3. 手动删除受影响的回滚段和undo表空间，然后重建新的undo表空间；
4. 还原undo表空间管理为自动。

实验如下：
Step 1.
如果undo数据文件损坏，数据库只能到mount状态，open时会出现以下错误：
ORA-01157: cannot identify/lock data file 14 - see DBWR trace file
ORA-01110: data file 14: ‘I:INTEL_DATAO06DMS0UNDO1.O06DMS0‘
说明该undo文件已经损坏或丢失，把该文件offline之后就可以打开数据库了：
SQL> alter database datafile ‘I:INTEL_DATAO06DMS0UNDO1.O06DMS0‘ offline drop; 这个地方需要指定具体的文件名，否则自我试了几次出错
SQL> alter database open;
打开数据库的目的是为了找出受影响的回滚段：
SQL> select segment_name,status from dba_rollback_segs;
SEGMENT_NAME                   STATUS
------------------------------ ----------------
SYSTEM                         ONLINE
_SYSSMU10_1201331463$          OFFLINE
_SYSSMU9_2926456744$           OFFLINE
_SYSSMU8_640224757$            OFFLINE
_SYSSMU7_3984293596$           OFFLINE
_SYSSMU6_3694658906$           OFFLINE
_SYSSMU5_3475919656$           OFFLINE
_SYSSMU4_168502732$            OFFLINE
_SYSSMU3_1987193959$           OFFLINE
_SYSSMU2_3908286755$           OFFLINE
_SYSSMU1_3281912951$           OFFLINE

SQL> show parameter undo

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------------
undo_management                      string      AUTO
undo_retention                       integer     900
undo_tablespace                      string      undo1
关闭数据库：
SQL> shutdown immediate;

Step 2.
创建一个临时的pfile：
SQL> create pfile=‘H:initO06DMS0.ora‘ from spfile;
修改pfile如下：
*.undo_management=‘manual‘ -- undo表空间管理方式修改为手动
*.undo_tablespace=‘undo2‘ --指定一个新的undo表空间
*._offline_rollback_segments=(‘_SYSSMU10_1201331463$‘,‘_SYSSMU9_2926456744$‘,‘_SYSSMU8_640224757$‘,‘_SYSSMU7_3984293596$‘,‘_SYSSMU6_3694658906$‘,‘_SYSSMU5_3475919656$‘,‘_SYSSMU4_168502732$‘,‘_SYSSMU3_1987193959$‘,‘_SYSSMU2_3908286755$‘,‘_SYSSMU1_3281912951$‘) --把所有受影响的回滚段都列在这里
并以改pfile重新启动数据库：
SQL> startup pfile=‘H:initO06DMS0.ora‘

Step 3.
手动删除受影响的回滚段：
SQL>drop rollback segment "_SYSSMU10_1201331463$";
SQL>drop rollback segment "_SYSSMU9_2926456744$";
SQL>drop rollback segment "_SYSSMU8_640224757$";
SQL>drop rollback segment "_SYSSMU7_3984293596$";
SQL>drop rollback segment "_SYSSMU6_3694658906$";
SQL>drop rollback segment "_SYSSMU5_3475919656$";
SQL>drop rollback segment "_SYSSMU4_168502732$";
SQL>drop rollback segment "_SYSSMU3_1987193959$";
SQL>drop rollback segment "_SYSSMU2_3908286755$";
SQL>drop rollback segment "_SYSSMU1_3281912951$";
手动删除旧的undo表空间：
SQL> drop tablespace undo1 including contents;
重建新的undo表空间：
SQL> create undo tablespace undo2 datafile ‘I:INTEL_DATAO06DMS0UNDO2.O06DMS0‘ size 100m;
创建新的spfile，覆盖旧的spfile：
SQL> create spfile from pfile=‘H:initO06DMS0.ora‘;
关闭数据库：
SQL> shutdown immediate;

Step 4.
以原来的spfile启动数据库：
SQL> startup;
还原undo表空间管理为自动：
SQL> alter system set undo_management=‘auto‘ scope=spfile;
取消隐藏参数的设置：
SQL> alter system reset "_offline_rollback_segments" scope=spfile;
重启使其生效：
SQL> shutdown immediate;
SQL> startup
SQL> show parameter undo

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------------------
undo_management                      string      AUTO
undo_retention                       integer     900
undo_tablespace                      string      undo2

最终检查一下：
SQL> select segment_name,status from dba_rollback_segs;

SEGMENT_NAME                   STATUS
------------------------------ ----------------
SYSTEM                         ONLINE
_SYSSMU40_1968985325$          ONLINE
_SYSSMU39_4040503138$          ONLINE
_SYSSMU38_4059847715$          ONLINE
_SYSSMU37_2692202156$          ONLINE
_SYSSMU36_2617425201$          ONLINE
_SYSSMU35_1133967719$          ONLINE
_SYSSMU34_1916939664$          ONLINE
_SYSSMU33_99444166$            ONLINE
_SYSSMU32_162619813$           ONLINE
_SYSSMU31_830375278$           ONLINE

https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5669213349582