ORACLE数据库的备份恢复(2)

ORACLE备份与恢复原理

数据库备份、还原、恢复的基本原理
备份可以分为逻辑备份与物理备份。简单的说，逻辑备份是按数据库中数据的备份，物理备份是按存储介质，数据文件的备份。

实例恢复：
当数据库实例发生故障而发生停机，或用户利用abort选项关闭实例后，数据库再启动后会自动执行实例恢复，实例恢复会回滚上次实例运行时未提交的事务以及一些其他的动作，
将数据库恢复到一致状态，这个过程对于用户来说是透明的，由实例自动进行，不需要人工干预。

检查点与CKPT进程
checkpoint是一个数据库事件，它将已修改的数据从高速缓存刷新到磁盘，并更新控制文件和数据文件。
巨大的i/o对系统性能带来很大影响。为了解决这个问题，oracle引入了checkpoint queue机制，每一个脏块会被移到检查点队列里面去，
按照low rdb（第一次对此块修改对应的redo block address）来排列，靠近检查点队列尾端的数据块的low rba值是最小的，
而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变，这样就保证了越早修改的块越早写入磁盘。
每隔3秒钟ckpt会去更新控制文件和数据文件，记录checkpoint执行的情况。
增量检查点并不去更新数据文件头，只是在控制文件中记录了checkpoint progress record这个区域，记下low rba,on-disk rba等信息。这些信息就可以用来快速恢复。
由于增量检查点和checkpoint queue 的原理，ckpt 进程每次只是告诉dbwr ，写dirty buffer将要一直写到最新这个位置，仅仅是告诉dbwr 一个checkpoint queue 中的结束点，
而ckpt 每3秒钟，在控制文件中报告一下dbwr 最新写入的位置。这样使得，比如数据库要做恢复的时候（instance recovery）可以从这个最新位置开始做恢复，
而不是从数据文件中的checkpoint scn 开始做恢复，这样将缩短恢复时间，尤其是instance crash 的情况下启动更快。
要注意的是，检查点发生的时候，ckpt 去更新数据文件头和控制文件，并不是把当前检查点发生时候的scn 更新进去，而是把上一次dbwr写入已经完成的检查点发生时候的 scn 更新进去，
也就是说，更新控制文件和数据文件头是 滞后于检查点的发生的，这个从恢复的原理也很容易理解，因为检查点发生的时候dirty buffer还没有写入，自然不能立即更新成当前的scn 了。
DBWn来写脏数据(SIGNALLING DBWn at CKPT)，完后会更新DATAFILE的HEADER和控制文件的HEADER.而HEADER中有同步所需要的信息,即CHECKPOINT的信息。
在ORACLE中，正常情况下，所有文件必须同期性地同步;靠CHECKPOINT来完成。

日志
oracle在记录日志的方式上，采用了逻辑和物理相结合的方式。
通过这种方式，oracle获得了物理记录方式的快速恢复的优点，同时又获得了逻辑记录方式的节省空间的优点。

一个日志文件写满以后转换到另外一个日志文件继续写的过程叫做日志切换（log switch）。
当一个联机日志文件写满时，可以选择将其归档为脱机日志文件，通常叫做归档日志文件。归档也就是拷贝，归档的过程也就是将写满的联机日志文件拷贝到预先指定的目录的过程。
只有当一个联机日志文件完成归档以后，该联机日志文件才能够被再次循环使用。
LGWR 承担了维护系统数据完整性的任务，它保证了数据在任何情况下都不会丢失。

Oracle环境中可能发现的故障类型：语句故障、用户进程故障、用户错误、网络故障、例程故障、介质故障。
语句故障
在Oracle 程序中处理语句时如果出现逻辑故障就会导致语句故障。语句故障的类型包括：
应用程序中出现逻辑错误。
用户试图向表中输入无效数据，可能破坏完整性约束。
用户权限不足却试图执行某个操作，例如只有SELECT 权限却在表中执行插入操作。
用户试图创建表，但超出了分配给该用户的限额限制。
用户试图对表执行INSERT 或UPDATE 操作，导致分配了一个区，但是表空间中的可用空间不足。
如果遇到语句故障，Oracle 服务器或操作系统将返回错误代码和错误消息。失败的SQL 语句将自动回退，然后控制权将返回给用户程序。应用程序开发人员或DBA 可使用Oracle 错误代码来诊断和帮助解决故障。

用户进程故障
用户进程失败的原因可能有多种；但最常见的原因如下：
用户在会话中执行了异常断开操作。例如，用户在连接到客户机-服务器配置环境中的数据库的情况下，关闭了SQL*Plus 窗口。
用户会话被异常终止。一种可能的情况是用户在连接到客户机-服务器配置环境中的数据库时重新引导了客户机。
用户程序导致地址异常，从而终止会话。如果在发生异常时，应用程序未对这些异常进行正确处理，则通常会发生这种情况。
出现异常终止的用户进程后，PMON 后台进程通常足以清理该用户进程。PMON 进程检测到异常终止的服务器进程时，它将回退该异常终止进程的事务处理，并释放它所获得的任何资源和锁。

用户错误
用户错误通常包括以下几种：
用户意外地删除或截断表。用户删除表中的所有行。用户提交了数据，但在其中发现一个错误。
我们无法完全避免用户错误，只能尽可能减少用户错误，在任何数据库和应用程序环境中，一个关键的问题就是确保用户已经过适当培训，并且知道数据库可用性和完整性的含义。
DBA 应该了解应用程序和商业运作的类型，这可避免由于用户错误而导致数据丢失；
DBA 还应该了解在这些情况下如何采取恢复措施。
某些恢复情况涉及的范围可能很广，例如将数据库还原到出现错误之前的时间点、导出丢失的数据，然后将数据导入到丢失了该数据的数据库。
LogMiner 是一种关系工具，通过它，可以以使用SQL 来阅读、分析、解释联机和归档日志文件。使用LogMiner 分析日志文件可用来查明何时对数据库进行了错误的修改。这样，就可以在应用程序级（而不是在数据库级）执行逻辑恢复了。
Oracle9i 提供一种称为FlashBack 的新功能，可以以用它来查看和修复历史数据。
FlashBack 提供对截止某一特定时间或用户指定的系统提交号(SCN) 的数据库执行查询的功能。

数据库崩溃与实例恢复
数据库崩溃的原因可能有多种：
由于断电，导致服务器不可用。由于硬件问题（如CPU 故障或内存损坏）或操作系统崩溃而导致服务器不可用。某个Oracle 服务器后台进程（DBWn、LGWR、PMON、SMON 或CKPT）出现故障。
要从崩溃中恢复，DBA 可以使用“startup” 命令启动例程。Oracle 服务器将自动恢复，并执行前滚和回退阶段。通过阅读警报日志和在例程故障期间生成的其它所有跟踪文件来调查故障原因。
崩溃恢复和例程恢复将数据库恢复到发生例程故障之前的事务处理一致状态。
根据定义，崩溃恢复是对单例程配置中的数据库或Oracle Real Application Clusters 配置（其中的所有例程都已崩溃）中的数据库执行的恢复；
而例程恢复是通过Oracle Real Application Clusters 配置中的一个活动例程来恢复一个失败的例程。如果需要，可以在数据库打开时，由Oracle 服务器自动执行崩溃恢复。
您不必执行任何恢复操作。所有必需的重做信息都由SMON 来读取。要从这种类型的故障中进行恢复，请启动例程：
SQL> CONNECT / AS sysdba
SQL> STARTUP
数据库打开后，通知用户必须重新输入未提交的所有数据。
在启动数据库和出现“数据库已打开” (Database opened) 通知之间可能有一个时间延迟，这是数据库装载时发生的前滚阶段。
SMON 通过应用联机重做日志文件（来自最后一个检查点）中记录的更改来执行前滚进程。前滚可恢复尚未记录到数据库文件中、但已记录到联机重做日志中的数据，包括还原段的内容。
打开数据库时可能发生回退，原因是无论SMON 或是服务器进程都可以执行回退操作。这使数据库可以更快地供用户使用。

介质故障与介质恢复
介质故障包含对操作数据库所需的文件进行读写操作时产生的物理问题。介质故障是最严重的故障类型，原因是它通常需要DBA的干预。
与介质有关的问题的常见类型：
包含某一数据库文件的磁盘驱动器出现磁头损坏。
对实现正常数据库操作所需的文件进行读写操作时存在物理问题。
文件被意外删除。
经过测试的恢复策略是解决介质故障问题的关键要素。DBA 能够在多大程度上尽量减少由介质故障引起的停机时间和数据损失取决于可用备份的类型。因此，恢复策略取决于以下因素：
选择的备份方法以及受到影响的文件。
数据库操作的ARCHIVELOG 模式。如果采用归档，可以应用已归档的重做日志文件来恢复自上次备份以来所提交的数据；如果使用RMAN，还可以应用增量备份。

备份和恢复策略
典型的备份策略：
1、镜像拷贝重作日志文件；
2、镜像拷贝控制文件；
3、激活归档进程，即以ARCHIVELOG模式操作数据库；
4、每天进行数据库的部分联机备份（每天进行数据库的完全热备份将无畏地增加数据库的负担且没有必要，同时也增加了数据库恢复时的灵活性）；
5、每隔一周或几周进行一次数据库的逻辑备份；
6、定期检查备份是否正常，定期测试备份的可恢复性以及恢复时间。

DBWR进程总是比LGWR进程写的速度慢（DBWR进程是随机写，LGWR进程是顺序写，随机写比顺序写要慢）当DBWR进程要将缓存区中的信息写入到数据文件时，
会先通知LGWR进程将事务相关的redo信息写入到日志文件。SCN可以理解为一个标签，ORACLE对数据库中的每个操作都打上一个标签。这个标签是顺序增加的。
永远不会归0（除非数据库重建）CHECKPOINT是ORACLE为了记录哪些数据已经被写入到数据文件中。

Instance Recovery所需要的信息，就是最近一次checkpoint之后到日志文件结尾的这些redo信息。
因为checkpoint之前的数据都已经一致性地写入到数据文件中了，而之后的数据可能有一部分已经写进数据文件，而有一部分没有写进数据文件。
Instance Recovery所需要的时间，将数据文件从最近一次checkpoint开始，恢复到控制文件中记录的这个数据文件的最后一个SCN值为止，应用这两者之间redo信息的时间就是instance recovery所要花费的时间。

对于instance recovery花费时间的调优，就是对参数FAST_START_MTTR_TARGE的调整，单位“秒”，最大值为3600秒。
也就是说FAST_START_MTTR_TARGET这个参数的设置会直接影响到checkpoint发生的频率。
FAST_START_MTTR_TARGE所设置的时间就是用户希望数据库用在instance recovery的时间。也就是从应用最近一次checkpoint到日志信息最后这两个点之间redo信息所要花费的时间。
MTTR设置的时间过小的话，会造成系统checkpoint过于频繁，而发生checkpoint时就要DBWR，LGWR等进程写数据文件，产生物理IO，久而久之，数据库性能会越来越慢；
MTTR设置的时间过大的话，当实例失败时，instance recover所花费的时间就会过长。

++++++++++++++++++++++++++++++++++++++
用户管理的备份
整体数据库备份：备份数据库中每一个关键文件，包括所有数据文件、重做日志文件、控制文件和参数文件
表空间备份：只备份指定表空间下的所有数据文件
数据文件备份：只备份指定的数据文件
控制文件备份：只备份某一时候的控制文件

整体数据库备份：
整体数据库备份（也称为整体备份）是指对数据库的所有数据文件和控制文件进行备份。无论数据库是打开的还是关闭的，都可以执行整体备份。这是最常见的备份方法。
在数据库关闭（使用NORMAL、IMMEDIATE 或TRANSACTIONAL 选项关闭数据库）后进行的整体备份称为一致备份。
在这种备份中，所有数据库文件的标头均与控制文件一致，完全还原后，数据库不需任何恢复即可打开。数据库以NOARCHIVELOG 模式进行操作时，只有一致的整体数据库备份才可以用来还原和恢复。
如果数据库打开并且可操作，数据文件的标头将与控制文件不一致，除非数据库是以只读模式打开的。
如果使用ABORT 选项关闭数据库，这种不一致性将一直存在。这种状态下的数据库备份称为不一致备份。
不一致备份需要通过恢复才能使数据库进入一致状态。如果数据库需要每周7 天、每天24 小时都可用，则只能使用不一致备份，并且只能对以ARCHIVELOG 模式运行的数据库执行不一致备份。

表空间备份：
表空间备份是对组成表空间的数据文件进行的备份。只有当数据库处在ARCHIVELOG 模式下时表空间备份才有效，因为要使数据文件与数据库的其它部分保持一致，需要使用重做条目。
在NOARCHIVELOG 模式下，如果数据库为只读的或脱机正常的，可以以进行表空间备份。

数据文件备份：
如果数据库处在ARCHIVELOG 模式下，可以以对单个数据文件进行备份。在NOARCHIVELOG 模式下，可以以对只读或脱机正常的数据文件进行备份。

控制文件备份：
可以以对RMAN 进行配置，使之在发出BACKUP 或COPY 命令后自动备份控制文件。还可以通过SQL 命令备份控制文件。

用户管理的备份恢复，也就是在备份时由用户自己使用操作系统提供的复制命令，复制要备份的文件。
相关视图：V$DATAFILE、V$CONTROLFILE、V$LOGFILE 和V$TABLESPACE

冷备份
冷备份的概念：关闭数据库的备份
冷备份的优点：恢复后可以直接使用
冷备份的缺点：必须关闭数据库
冷备份的执行过程：先关闭数据库，再复制所有重要文件

进行数据库冷备份的优点：
冷备份在概念上简明易懂，您只需：关闭数据库，将所有需要的文件复制到备份位置，打开数据库要执行关闭的数据库的备份，只需使用数量极少的几个命令。
只要执行一个简单的脚本，而且只需很少的交互操作，就可以自动的数据库的冷备份，步骤如下：关闭数据库，复制控制文件和数据文件，打开数据库。
所有在冷备份过程中复制的文件都具有一致的时间点。在备份过程中，由于数据库不可用，因此不发生任何事务处理。
进行数据库冷备份的缺点：
对于数据库必须处于连续可用状态的那些业务经营活动，由于在一致的整体数据库备份期间数据库会关闭且不可用，所以不能采用这种备份方式。
数据库不可用的时间长短受数据库大小、数据文件的数量以及复制数据文件的速度的影响。如果这一时间超过了允许的关机时间，您必须选择其它备份类型。
只能恢复到上一次完全一致的整体数据库备份时的状态，丢失的事务处理必须在执行恢复操作之后手动输入。

热备份
热备份是在数据库运行时对数据库进行备份，应该注意：
联机表空间备份
只读表空间备份
备份控制文件和初始化参数文件
在联机备份失败后执行清除

执行所有表空间或各个数据文件的备份（无论它们处在联机状态还是脱机状态）。
将控制文件备份为一个二进制文件，或创建一个脚本以重新创建控制文件。联机重做日志文件不需要备份。这种备份称为热备份。
热备份的优点：
在备份过程中数据库可以正常使用。可以在表空间级（通过RMAN）或数据文件级执行备份。支持每天都全天候运作的业务。
热备份的条件：
只要符合以下两个标准，您就可以在使用数据库的同时，执行表空间或各个数据文件的备份：
数据库设置为ARCHIVELOG 模式。通过启用Oracle 自动归档(ARCn) 进程或手动归档重做日志文件，确保联机重做日志得到归档。
热备份的选项：
使用Oracle 服务器，我们既可以备份某一特定表空间的所有数据文件，也可以只备份某个表空间的一个数据文件。无论您选择哪个选项，在备份过程中，数据库都可以保持正常使用（事务处理）。
如果一个数据文件处于备份模式，则可能会生成多个重做日志条目，因为日志写入器将备份模式下的数据文件中已更改的块的块映像写入重做日志，而不仅仅是写入行信息。
这会对重做日志的大小和日志写入器的性能产生重大影响。

通过以下步骤可以进行联机表空间的备份：
1. 通过发出ALTER TABLESPACE...BEGIN BACKUP 命令，将数据文件或表空间设置为备份模式。这样可避免数据文件头中的序列号发生变化，以便恢复时可以从备份开始时间应用日志。
即使数据文件处于备份模式，仍可用于正常事务处理。
SQL> ALTER TABLESPACE users BEGIN BACKUP;
2. 使用操作系统备份实用程序将表空间中的所有数据文件复制到备份存储中。如果按顺序备份每个表空间，备份文件中的日志序列号可能不同。
UNIX:
cp /ORADATA/u03/users01.dbf /BACKUP/users01.dbf
Windows NT:
ocopy c:\users\disk1\user01.ora e:\users\backup\user01.ora
3. 备份表空间的各数据文件后，发出下面的命令将它们设置为正常模式：
SQL> ALTER TABLESPACE users END BACKUP;
4. 归档尚未归档的重做日志，以便归档恢复表空间备份所需的重做日志，
如下所示：
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
对所有表空间重复这些步骤，包括SYSTEM 和还原段表空间。
ALTER TABLESPACE BEGIN BACKUP 和ALTER TABLESPACE END
BACKUP 命令之间的间隔时间应尽量缩短，因为修改后的块写入重做日志文件
将导致生成更多的重做信息。因此建议您每次执行一个表空间的联机备份。
通过查询V$BACKUP 和V$DATAFILE_HEADER 视图，可以在执行打开的数据库的备份时获得关于数据文件状态的信息。
查询V$BACKUP 视图以确定哪些文件处于备份模式。发出ALTER
TABLESPACE BEGIN BACKUP 命令后，状态将更改为ACTIVE。

只读表空间可以通过下面的方法备份：
1 使用ALTER TABLESPACE SQL 命令将表空间的状态从读写更改为只读：
SQL> ALTER TABLESPACE query_data READ ONLY;
2 发出ALTER TABLESPACE 命令后，会对所有与表空间相关联的数据文件执行检查点。然后使用当前SCN 冻结文件头。
3 使表空间成为只读状态之后，您必须备份该表空间的所有数据文件。
4 DBW0 进程只写入其表空间处于读写模式的数据文件，正常的检查点也只对这些文件执行。
对只读表空间的说明：
由于不对只读表空间的数据文件执行任何写操作，因此，只有在这些文件损坏的情况下才必须进行恢复。
将表空间从只读状态更改为读写状态，其结果是导致DBW0 写入表空间文
件，并象通常一样产生检查点。这样，您就必须对与该表空间相关联的所有数据文件重新使用正常备份时间表。
使用ALTER TABLESPACE 命令将表空间更改为只读状态，会导致控制文
件更新。执行恢复操作时，控制文件必须能够正确地标识只读表空间；否则，您必须恢复该表空间。

备份控制文件和初始化参数
Oracle 服务器在进行例程或介质恢复时会用到控制文件中的某些状态信息（如当前联机重做日志文件以及数据库文件的名称）。每次对数据库配置进行更改后，您都需要保留控制文件的最新副本。
备份的原则：
对控制文件进行多元备份，并使用CONTROL_FILES 参数在init.ora 文件中为它们命名。
ALTER DATABASE BACKUP CONTROLFILE TO TRACE 命令创建一个用于重新创建控制文件的脚本。
该文件位于由初始化参数USER_DUMP_DEST 指定的目录下。此脚本不包含RMAN 元数据。此外，还应使用ALTER DATABASE BACKUP CONTROLFILE 命令来备份各个控制文件。
这样可以提供控制文件在该时间点的二进制副本。完全备份时，正常关闭例程，然后使用操作系统备份实用程序将控制文件复制到备份存储中。

可以以使用CREATE PFILE 语句来创建服务器参数文件的备份。服务器参数
文件的内容以文本格式导出到一个初始化参数文件中。CREATE PFILE 命令可以在缺省位置创建该文件，您也可以按示例指定文件名。
CREATE PFILE = '/backup/init.ora' FROM SPFILE;
CREATE PFILE FROM SPFILE;

在联机备份失败后执行清除
联机表空间备份过程中的故障处理：
在联机表空间备份的过程中，可能会发生系统崩溃、电源故障、数据库关闭等故障。一旦发生任何这些故障：如果操作系统未完成备份，则备份文件将不可用。
您需要重新备份这些文件。处在联机备份模式下的数据库文件不会与数据库同步，原因是备份开始时标头被冻结。
数据库将不会打开，因为Oracle 服务器认为文件已从备份中还原。可以以使用ALTER DATABASE …END BACKUP 命令使数据文件脱离备份模式。
只有在您确定这些文件处于备份模式、且未从备份中还原的情况下，才可使用此命令。
如果您不能确定某一文件是否需要恢复，或者该文件是否仍处于联机备份模式，可查询V$BACKUP 视图：
SQL> ALTER DATABASE datafile 2 END BACKUP;
SQL> ALTER DATABASE END BACKUP;
SQL> ALTER DATABASE OPEN;

使用DBVERIFY实用程序检测坏块
DBVERIFY程序的作用：检测数据文件是否有坏块
DBVERIFY 实用程序的可执行程序名称在不同操作系统中是不同的。它位于Oracle 主目录的bin 目录中。在UNIX 环境中，应执行dbv 可执行程序。
该实用程序主要用于以下两个目的：确保备份数据库（或数据文件）在还原之前是有效的；遇到数据损坏问题时用作诊断辅助工具。
要验证数据文件users01.dbf 的完整性（从块1 开始到块500 结束），可以以执行如下命令：
$ dbv file=/ORADATA/u03/users01.dbf start=1 end=500
参数的说明：
参数        说明
FILE        要验证的数据库文件的名称
START        验证的块的起始地址。块地址在Oracle 块中指定。如果不指定START，则假定起始地址为文件中的第一个块。
END            要验证的块的结束地址。如果不指定END，则假定结束地址为文件中的最后一个块。
BLOCKSIZE    仅在文件中有大于2KB 的块时才需要此参数
LOGFILE        指定事件记录信息写入的文件。缺省设置是将输出发送到终端显示器。
FEEDBACK    使DBVERIFY 为已验证的n 页显示单个‘.’
HELP        提供屏上帮助
PARFILE        指定要使用的参数文件的名称