ORACLE数据库学习之备份与恢复
第一部分：数据库的备份
备份的必要性
因为各种人为或外界的因素可能会造成数据库中灾难性的数据丢失，为了保证数据库中数据的安全，必须采取备份措施保证RDBMS中包含的数据免遭破坏，而有效的备份是十分简单和普通的，是在数据库处于无法使用状态时用于重建数据库的重要信息拷贝。在重要的修改如删除段或者表空间以前或以后执行适当的备份是相当必要的。
备份的种类：
冷备份：
一种最简单直接的备份方式，也称为脱机备份，但是必须关闭数据库，这对于当前7×24的有效性并不可取；
联机热备：
正如名称所示，是在数据库打开时执行的备份方式，进行联机备份比进行脱机备份的进程复杂；
用导出exp应用程序备份：
是对于脱机备份和联机备份类型的补充，因为它无法回滚，所以不能替代数据库文件的备份。
各种备份的原理和步骤：
冷备份：
关闭数据库，采取操作系统拷贝命令来完成对数据库的备份，然后启动数据库。
例如：将名为lyj的数据库作一个冷备份，备份的文件放置在/mnt/backup_wy/目录下。
l 首先找出控制文件、数据文件和redo日志文件的存储位置
SQL> selectname from v$controlfile ;
NAME
----------------------------------------------------
/u3/oradata/lyj/control01.ctl
/u3/oradata/lyj/control02.ctl
/u3/oradata/lyj/control03.ctl
SQL> select status,name from v$datafile ;
STATUS NAME
---------- ----------------------------------------
SYSTEM /u3/oradata/lyj/system01.dbf
ONLINE /u3/oradata/lyj/tools01.dbf
ONLINE /u3/oradata/lyj/rbs01.dbf
ONLINE /u3/oradata/lyj/temp01.dbf
ONLINE /u3/oradata/lyj/users01.dbf
ONLINE /u3/oradata/lyj/indx01.dbf
SQL> select * from v$logfile ;
GROUP# STATUS MEMBER
--------------------------------------------------------------------------------
-
/u3/oradata/lyj/redo01.log
2 /u3/oradata/lyj/redo02.log
3 /u3/oradata/lyj/redo03.log
l 关闭数据库：
SQL> shutdown
数据库已经关闭。
已经卸载数据库。
ORACLE例程已经关闭。
l 将数据文件、控制文件和redo日志文件从上面查找出来的位置拷贝到/mnt/backup_wy/目录下作为备份：
[oracle|15:38:09|/u3/oradata/lyj]$ cp *.ctl /mnt/backup_wy/
[oracle|15:38:29|/u3/oradata/lyj]$ cp *.log /mnt/backup_wy/
[oracle|15:38:43|/u3/oradata/lyj]$ cp *.dbf /mnt/backup_wy/
l 重新开启数据库：startup
热备份
在联机状态下执行备份，这时数据库必须运行在ARCHIVELOG模式下，因为在日志书写器进程重新使用它之前，副本是由每一个redo日志文件组成的，日志书写器在循环方式中通过redo日志文件进行循环，只要数据库正在运行，它就写入一个，然后是另一个，依此类推。在ARCHIVELOG模式下运行时，直到redo日志文件的永久拷贝被建立，Oracle才覆盖redo日志文件。在ARCHIVELOG模式中运行数据库时，可以选择当每个redo日志文件写满时手工地生成备份或者启动可选的归档进程进行自动备份。只有通过sys身份或internal登录数据库，就有权利通过sqlplus或svrmgr查看数据库的归档状态；
SVRMGR> archive log list
数据库记录模式 存档模式
自动存档 已启用
存档路径 /u2/oratest/admin/lyj/arch
最旧的联机日志顺序 496
要存档的下一个记录顺序 498
当前记录顺序 498
在这种模式下，数据库运行在ARCHIVELOG模式下，并且能够进行自动归档，此时，可以进行联机备份了。
假设数据库运行在非存档模式下，就应该在参数文件中修改log_archive_start= true
log_archive_dest =指定的保存归档日志文件的目录
log_archive_format =“制定的归档日志文件的存储格式"
备份控制文件；
备份数据文件；
归档当前的联机日志文件；
备份归档日志文件。
下面以lyj为例说明如何热备一个数据库：
l 备份控制文件：
SVRMGR> alter databasebackup controlfile to '/mnt/backup_wy/controlfile' ;
语句已处理。
用完整的文件夹路径和文件的名称'/mnt/backup_wy/controlfile'将备份控制文件存储在此。
l 备份数据文件：
执行一个数据库的联机备份时，需要一次复制一个表空间的数据文件，在位一个表空间复制文件之前需要执行ALTER TABLESPACEtablespace_name BEGIN BACKUP；
为表空间复制完文件时，需要执行下列命令：
ALTER TABLESPACEtablespace_name END BACKUP；
使用这些BEGIN和END命令的理由是当它们被复制时，Oracle需要将数据文件头保持连贯状态，发出BEGIN命令时，Oracle停止更新受影响的数据文件的文件头上的检查点，在整个表空间备份模式中，Oracle通过将全部的数据块写入redo日志文件的方式来记录这个表空间中的数据的变化。
通过下面语句找出所有表空间的名字：
SVRMGR> select * fromv$tablespace;
TS# NAME
---------- ------------------------------
0 SYSTEM
1 TOOLS
2 RBS
3 TEMP
4 USERS
5 INDX
然后对这些表空间进行备份，将数据文件备份到/mnt/backup_wy/
目录下：
SVRMGR> alter tablespacesystem begin backup ;
语句已处理。
SVRMGR> alter tablespacetools begin backup ;
语句已处理。
SVRMGR> alter tablespacerbs begin backup;
语句已处理。
SVRMGR> alter tablespacetemp begin backup ;
语句已处理。
SVRMGR> alter tablespaceusers begin backup ;
语句已处理。
SVRMGR> alter tablespaceindx begin backup ;
语句已处理。
[oracle|17:01:53|/u3/oradata/lyj]$cp *.dbf /mnt/backup_wy/
SVRMGR> alter tablespacesystem end backup ;
语句已处理。
SVRMGR> alter tablespacetools end backup ;
语句已处理。
SVRMGR> alter tablespaceusers end backup ;
语句已处理。
SVRMGR> alter tablespacetemp end backup ;
语句已处理。
SVRMGR> alter tablespaceindx end backup ;
语句已处理。
SVRMGR> alter tablespacerbs end backup ;
语句已处理。
l 归档当前的联机redo日志文件：
备份完所有的数据文件后，需要归档当前的联机redo日志文件，因为恢复时需要它们。归档她们时允许和所有其他的归档日志文件一起进行备份。
SVRMGR> alter systemarchive log current;
语句已处理。
这条命令导致Oracle转换到一个新的日志文件。然后Oracle归档所有未被归档的日志文件，还可以使用另外两条命令达到相同的效果：
SVRMGR> alter systemswitch logfile ;
语句强制转换日志。
SVRMGR> alter systemarchive log all ;
语句导致Oracle所有已写满但仍未归档的redo日志文件归档。
l 备份归档日志文件
一旦已经归档了当前联机的日志文件，最后一步就是备份所有归档日志文件到/mnt/backup_wy/目录下，因为还原数据库时需要它们
[oracle|17:42:46|/u2/oratest/admin/lyj/arch]$ cp arch_*.*/mnt/backup_wy/
导出数据库作备份
数据库导出可以被看作备份的一种形式。Oracle实用工具Export利用SQL语句读出数据库数据，并在操作系统层将数据和定义存入二进制文件。导出对于还原一个意外删除的对象或还原这个对象的定义来说是很好的，因为脱机备份不能只还原一个对象，而联机备份还原一个对象必须得还原该对象存在的数据文件，相对于导出这种备份形式来说要繁琐很多，但是从导出中还原时，仅能得到导出文件中的内容，不能从中向前回滚，所以导出数据库这种备份方式只能作为联机备份和脱机备份的一种补充。
第二部分：数据库的恢复
请求恢复
数据库的恢复一般分为NOARCHIVELOG模式和ARCHIVELOG模式，实际情况中很少会丢失整个一个oracle数据库，通常只是一个驱动器损坏，使得仅仅丢失该驱动器上的文件。如何从这样的损失中恢复很大程度上取决于数据库是否正运行在ARCHIVELOG模式下。如果没有运行在ARCHIVELOG模式下而丢失了一个数据库文件，就只能从最近的一次备份中恢复整个数据库，备份之后的所有变化都丢失，而且在数据库被恢复时，必须关闭数据库。由于在一个产品中丢失数据或将数据库关闭一段时间是不可取的，所以大多数oracle产品数据库都运行在ARCHIVELOG模式下。
在oracle中，恢复指的是从归档和联机redo日志文件中读取redo日志记录并将这些变化应用到数据文件中并将其更新到最近状态的过程。
从备份中还原一个文件时，文件代表了数据库被备份时而不是丢失时的状态，通常情况下希望恢复过渡期即文件备份和文件丢失之间发生的所有变化，由于所有变化都被写入日志文件中，所以能够通过读取日志文件并且再次将这些变化应用于所还原的文件中。
还原NOARCHIVELOG模式下的数据库
还原一个运行于NOARCHIVELOG模式下的数据库代表了最简单的情况，由于不存在归档日志文件，也就不可能有介质恢复，全部的操作仅仅是操作系统级的复制过程。还原一个NOARCHIVELOG模式下运行的数据库由下列几步组成：
-
如果实例正在运行，关闭数据库；shutdown
-
从最近备份中还原控制文件和数据文件；
-
指定是否移动任何一个文件
在启动数据库时，oracle将根据参数文件指定的路径寻找这些文件。如果一个磁盘的丢失迫使将文件放回到与最初不同的位置，需要告诉oracle，否则，就会出现出错信息。
可以有两种方法告诉oracle已移动了一个数据库文件：
-
使用alterdatabase rename file‘original_filename’ to ‘new_filename’命令,其中，‘original_filename’是当前使用的完整的路径和文件名，而‘new_filename’是文件当前的路径和文件名。
为了改变数据库文件的名字，数据库必须被安装但没有打开，因为变化要在控制文件中被记录。
e.g: connectinternal;
startup mount;
alter database rename file ‘/u3/oradata/lyj/system01.dbf’to ‘/mnt/backup_wy/system01.dbf’ ;
-
如果正在移动全部或大部分的数据文件，重建控制文件会相对简单一些。而如果在备份控制文件时使用了alter database backup controlfile totrace这条语句，就会在admin/udump目录下找到重建控制文件的跟踪语句，该语句包括必须的create controlfile等命令，将该文件中的改变了的文件名代替原有的文件名和位置。
-
重新打开数据库
应该使用resetlogs选项打开数据库，这样复位日志文件是为了保证在新的记录和那些从先前的数据库中留下的记录之间不会产生任何冲突。
e.g:用备份的控制文件替换控制文件：
SVRMGR>connectinternal
SVRMGR>alter database backup controlfile to '/mnt/backup_wy/control.ctl' ;
Statementprocessed.
SVRMGR>alter database backup controlfile to trace ;
SVRMGR>exit
[oracle|15:41:32|/u3/oradata/lyj]$cp /mnt/backup_wy/control.ctl control01.ctl
[oracle|15:41:32|/u3/oradata/lyj]$cp /mnt/backup_wy/control.ctl control02.ctl
[oracle|15:41:32|/u3/oradata/lyj]$cp /mnt/backup_wy/control.ctl control03.ctl
SVRMGR>connectinternal
SVRMGR>startupmount
SVRMGR>alterdatabase open resetlogs;
请求介质恢复
介质恢复是指这样一种过程：从redo日志文件中读取变化并把这些变化应用于从备份中还原的一个或多个数据库文件中，最终结果是数据库文件被更新到当前日期并且它们反应了备份后所做的所有变化，因此进行介质恢复必须把redo日志放在第一位。
在ARCHIVELOG模式下运行数据库时，oracle在每个redo日志文件写满后都进行一次拷贝，这些拷贝同没有被复制的任何联机redo日志文件一起被称为是归档日志文件，形成对数据库所进行的变化的一条连续记录。如果丢失了一个数据文件并被迫从备份中还原它，那么归档日志文件中的信息将被用来将所有变化重新应用给备份发生后被建立的文件，最后的效果是没有遭受数据损失。
恢复控制文件
在进行介质恢复时，如果存在当前控制文件，就使用当前控制文件，如果当前控制文件在出现介质故障时丢失，那么可以用控制文件的备份拷贝，或者创建一个新的控制文件，创建控制文件的语法如下：
STARTUP NOMOUNT;
CREATECONTROLFILE REUSE DATABASE "LYJ" NORESETLOGS ARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 254
MAXINSTANCES 8
MAXLOGHISTORY 907
LOGFILE
GROUP 1 '/u3/oradata/lyj/redo01.log' SIZE 500K,
GROUP 2 '/u3/oradata/lyj/redo02.log' SIZE 500K,
GROUP 3 '/u3/oradata/lyj/redo03.log' SIZE 500K
DATAFILE
'/u3/oradata/lyj/system01.dbf',
'/u3/oradata/lyj/tools01.dbf',
'/u3/oradata/lyj/rbs01.dbf',
'/u3/oradata/lyj/temp01.dbf',
'/u3/oradata/lyj/users01.dbf',
'/u3/oradata/lyj/indx01.dbf'
CHARACTER SETUS7ASCII;
RECOVERDATABASE
ALTER SYSTEMARCHIVE LOG ALL;
ALTER DATABASEOPEN;
Createcontrolfile命令只能在nomount选项启动数据库后发出，执行该命令之前，创建一个新的控制文件并自动安装数据库，然后新的控制文件在需要时可以用于恢复。
从丢失的数据文件中恢复
通常由磁盘错误引起的数据文件的丢失，是用户经常遇到的情况。如果正在ARCHIVELOG模式下运行，那么可只还原丢失的文件，把它们还原到出错的那一刻，而进行这些操作时除非system表出错，其它的文件正在运行。
使丢失的数据文件脱机
如果驱动器错误导致丢失了一个数据文件，那么oracle已经将这个文件脱机，可以用下列查询检查数据库中文件的状态：
SQL> selectstatus,name from v$datafile ;
STATUS NAME
--------------------------------------------------
SYSTEM /u3/oradata/lyj/system01.dbf
ONLINE /u3/oradata/lyj/tools01.dbf
ONLINE /u3/oradata/lyj/rbs01.dbf
ONLINE /u3/oradata/lyj/temp01.dbf
ONLINE /u3/oradata/lyj/users01.dbf
OFFLINE /u3/oradata/lyj/indx01.dbf
在这种情况下，indx01.dbf文件是脱机的，如果已丢失的文件还没有脱机，可以通过下列命令使其脱机：
alter databasedatafile‘/u3/oradata/lyj/indx01.dbf’offline；
只有文件安全脱机后，才能继续还原并恢复它。其它未脱机的数据文件可以照常工作。
还原丢失的数据文件
在恢复文件前，使用操作系统级的复制命令还原数据文件，否则执行一条alter database rename file命令在数据库文件中记录新的位置。
1恢复丢失的数据文件（2种方法）
-
以sysdba或system或internal身份登录后，执行recover database命令使得oracle检查所有文件并对任何需要恢复的文件进行恢复。
-
recover datafile ‘/u3/oradata/lyj/indx01.dbf’
如果归档日志文件仍然联机，它们需要在archive_log_dest指向的文件夹中。
2将已恢复的文件重新重新联机
恢复完文件后是将文件重新联机，可以通过alter database命令实现。E.g:
SQL>alterdatabase datafile‘/u3/oradata/lyj/indx01.dbf’online ;
OK!文件已被恢复，已被重新联机，可以正常使用了。
执行一个不完全恢复
在介质故障恢复中，不丢失数据的数据库恢复称为完全恢复。如果在数据库恢复之后丢失某些数据，则称为不完全恢复。一般情况下，当所有需要的重作日志文件和备份数据文件以及当前有效的控制文件都可以使用时，应该采用完全恢复。只有当丢失了一个归档或联机重作日志文件和控制文件时采用不完全恢复。不完全恢复还可以恢复到过去的某个时间点。
不完全恢复并不总是代表一个从进程错误中恢复的理想办法，因为如果联机事务正在发生而同时一个批处理进程正在运行，如果用户运行一个不完全恢复来重新运行批处理进程，那些数据就将丢失。在不完全恢复前，需要将某一次文件的全备份进行还原，然后就可以进行不完全恢复了。
不完全恢复有几个选项可供选择：
-
until cancel指定一个基于取消的恢复；
-
until change指定恢复到一个指定的SCN；
-
until time指定恢复到某一时间；
-
datetime指定用户希望恢复数据库的日期和时间。
SVRMGR>connectinternal；
SVRMGR>startupmount
SVRMGR>recoverdatabase until time ‘2001－02－21：
10：30：00’；
SVRMGR>alterdatabase open resetlogs；
因为在打开数据库时始用了resetlogs选项，oracle抛弃恢复中没有运用的重作纪录，并且确保永远不再运用，同时重新初始化控制文件中有关联机日志文件和重作线程的信息，可以有效地预防使用一个已存在的归档和redo日志来再次恢复，所以最好在运行完不完全恢复后立即执行数据库的另一个脱机或联机的全备份。
从导出文件中还原数据库
可以使用imp应用程序从导出文件来还原一个数据库。
从导出文件中还原数据库比从一个文件系统的备份中还原数据库要容易，但是它具有以下一些不利因素：
-
还原进程时间长；
-
不能还原个别文件；
-
不能执行介质恢复，故不能恢复导出后所做的变化
例子：
数据文件恢复的一般过程是：
====================
做任何恢复之前，先备份目前的系统，以防恢复过程中，系统遭到更大的损坏
首先取得最后一次备份（脱机冷备份），并确保没有损坏，
然后判断系统是否运行在归档模式，
如果是非归档模式，则只能用最后一次全备份来恢复，
删除所有的数据文件、控制文件、联机日志文件，
将备份的数据文件、控制文件、联机日志文件全部拷回原目录。
重新启动数据库
====================
如果是归档模式，再判断是否可以shutdown
如果当前系统不可shutdown，则进行tablespace、datafile恢复
（前提是system表空间和包含活动回滚段的表空间不可损坏）
如果当前系统可以shutdown，则进行recover database恢复
====================
如果所有文件均有效、无损坏，则可进行全数据库恢复，过程如下：
connect internal
shutdown
将数据文件、已备份的归档日志拷贝回原目录（不可拷贝控制文件）
startup mount
set autorecovery on
recover database;
alter database open;
====================
如果某个归档日志文件损坏，则只能恢复到那个损坏的日志文件之前，
即不完全恢复
connect internal
shutdown
将数据文件、已备份的归档日志拷贝回原目录
startup mount
set autorecovery off
recover database until cancel;
alter database open resetlogs;
--将控制文件与数据文件同步，并将数据库启动至Open模式
在以resetlogs选项启动数据库后必须进行数据库全备份
============================
用exp工具导出的数据库则用imp工具导入来恢复
============================
如果只有归档日志，而没有数据文件的备份，
只要归档日志保存完整，则可通过重建数据文件来恢复
alter database create datafile '文件名';
recover datafile '文件名';
