分类： Oracle
2008-04-28 20:32:27
|
在应用oracle数据过程中，数据库当机相信是每个人都会碰到的问题，而如何恢复备份使损失最小是每个 本文出自 51CTO.COM技术博客dba最应该关心的问题，无论什么情况都用imp恢复全备份是不现实和完全可用的，希望下面这个手册会对 大家恢复各种情况下的备份有所帮助。 要对Oracle数据库备份与恢复有清晰的认识，首先有必要对数据库的几种运行状态有充分的了解。Oracle 数据库的运行状态主要分为3种，他们依次为： l Nomount（非安装）Oracle只是读取ini文件中的配置信息，并初始化SGA区。 l Mount（安装）Oracle除了需要读取ini文件还要读取控制文件，并从中获取有关数据库的物理结构等信 息。 l Open（打开）数据库要检查所有文件处于同一时间点，对错误进行恢复对未完成事务回滚，并最终可以 允许用户访问。 数据库的备份主要分为三种类型：冷备份；热备份；逻辑备份； 数据库的备份不是本文讨论的重点，在这里只作一个概要的介绍，Oracle数据库备份主要有： l Cold Backup（冷备份） 主要指在关闭数据库的状态下进行的数据库完全备份，备份内容包括所有数据 文件、控制文件、联机日志文件、ini文件。 l Hot Backup（热备份） 指在数据库处于运行状态下，对数据文件和控制文件进行备份，要使用热备份 必须将数据库运行在(Archive Log)归档方式下。 l Export（逻辑备份）这是最简单的备份方法，可按数据库中某个表、某个用户或整个数据库来导出，并 且支持全部、累计、增量三种方式。使用这种方法，数据库必须处于打开状态，而且如果数据库不是在 restrict状态将不能保证导出数据的一致性。 数据库的恢复可分为两大类：完全恢复；不完全恢复； 完全恢复指将数据库恢复到发生故障的时间点，不丢失任何数据。不完全恢复指将数据库恢复到发生故障 前的某一个时间点，此时间点以后的所有改动将会丢失。如果没有特殊需求，我们建议应尽量使用完全恢 复。 Oracle数据库的恢复过程分两步进行，首先将把存放在重做日志文件中的所有重做运用到数据文件，之后 对重做中所有未提交的事务进行回滚，这样所有数据就恢复到发生灾难那一时刻了。数据库的恢复只能在 发生故障之前的数据文件上运用重做，将其恢复到故障时刻，而不能将数据文件反向回滚到之前的某一个 时刻。举个例子，我们有一个2001/1/1的数据库备份，当2001/5/1使我们发现数据库中数据发生混乱，希 望将数据库恢复到2001/4/30时的状态，我们只能先恢复2001/1/1的数据库备份然后在其上运用重做记录 使其前滚到2001/4/30时的状态，而不能将2001/5/1的数据库向后回滚到2001/4/30。 为了系统的设计数据库的恢复方案，我们先对可能遇到的错误进行分类，Oracle数据库错误主要分为5大 类： l SQL语句失败 l 线程失败 l 实例失败 l 用户操作失败 l 存储设备失败 如果发生前三种失败，不需要我们人为干涉，Oracle系统会自动进行恢复。对于用户操作型的失败（如误 删除数据），我们采取的补救措施主要有导入最新的逻辑备份或进行到某一时间点的不完全恢复。从 Oracle 8之后的新版本中引入了基于表空间的时间点恢复(TSPITR)，可以单独将包含错误操作的表空间恢 复到指定时间，而不必对整个数据库进行不完全恢复。当错误操作发现比较及时而且数据量不大的情况下 也可以考虑使用logminer生成反向SQL。 针对存储设备的失败的情况比较复杂也是本文讨论的重点，存储设备的失败必然会使放置在其上的文件 变为不可用，我们先将Oracle数据库所涉及到的文件进行一个划分，主要可分为： l Oracle的系统文件，指Oracle的运行文件，各种应用程序 l 数据库控制文件 l 数据库联机重做日志文件 l 数据文件 l 归档日志文件 避免第一种文件失败主要依赖系统管理员进行操作系统级的备份，当发生事故后只能依靠操作系统备份将 其恢复。 控制文件中记录着整个数据库的结构、每个数据文件的状况、系统SCN、检查点计数器等重要信息，在创 建数据库时会让用户指定三个位置来存放控制文件，他们之间互为镜像，当其中任何一个发生故障，只需 将其从ini文件中注释掉故障数据文件就可重新将数据启动。当所有控制全部失效时，可以在Nomount模式 下执行create controlfile来重新生成控制文件，但必须提供redo log，data file，文件名和地址以及 MAXLOGFILES，MAXDATAFILES，MAXINSTANCES等信息。如果失败之前运行过alter database backup controlfile to trace或alter database backup controlfile to ‘xxx’对控制文件作备份，恢复时可 使用生成的脚本来重建或用备份文件覆盖，如果使用了旧的控制文件在恢复时要使用recover xxx using backup controlfile选项来进行恢复，并使用resetlogs选项来打开数据库。 如果丢失的是联机日志文件，分两种情况处理1、丢失的是非活动的日志文件；2、丢失的是当前激活的日 志文件。 如果是第一种情况，而发生故障的日志文件组又具有多个成员，可以先将数据库shutdown，然后用操作系 统命令将损坏日志文件组中好的日志成员文件把损坏的成员文件覆盖（在同一个日志成员组中的所有日志 文件的各为镜象的），如果其物理位置不可用可将其拷贝到新的驱动器上，使用alter database rename file ‘xxxx’ to ‘xxxx’改变文件位置，之后启动数据库，如果正常马上进行一个冷备份。如果损坏 的日志组中只有一个日志成员，先mount上数据库，将其转换为noarchivelog模式，执行alter database add logfile member ‘xxx’ to group ‘x’给相关组增加一个成员，再执行alter database drop logfile member ‘bad_file’将损坏的日志文件删除，由于数据库的结构发生变动需要备份控制文件， 之后将数据库改回archivelog模式，做一个冷备份。 如果丢失的是当前激活的日志文件，数据库又没有镜像而且当前日志组中所有成员均变为不可用。首先将 数据库shutdown abort，从最近的一次全备份中恢复所有的数据文件，将数据库启动到mount状态。如果 原来的日志文件物理位置不可用，使用alter database rename file ‘xxx’ to ‘xxx’改变文件的存 放位置。然后，使用recover database until cancel命令来恢复数据库，直到提示最后一个归档日志运 用完之后，输入cancel。之后用alter database open resetlogs打开数据库，如果没有问题，立即进行 一个冷备份。注意！所有包含在损坏的redo log中的信息将会丢失，也就是说数据库崩溃前已经提交的数 据有可能会丢失。这对于某些要求很高的应用将会损失惨重，因此应尽量使每个日志组具有多个日志成员 ，并且放置在不同的驱动器上一防止发生介质故障。 数据文件发生故障的情况也分为多种情况，1、丢失包含在SYSTEM表空间的数据文件；2、丢失没有回滚段 的非SYSTEM数据文件；3、丢失有回滚段的非SYSTEM数据文件。 如果损坏的是系统表空间的数据文件。唯一的办法是从上一次备份中恢复受损的数据文件，（如果原位置 不可用使用alter database rename命令改变新文件的位置），之后在数据库mount的状态下执行recover database/datafile对数据库进行回复，才能将数据库打开。注意：当SYSTEM表空间或其中的数据文件脱 机，数据库是无法被打开的，因此必须在mount状态下将所有的恢复工作完成。 当丢失的数据文件不属于系统表空间而且也不包含回滚段时，有可选择在数据库的两种状态下进行恢复 ---在数据库open的状态或者在数据库mount的状态。如果用户急于访问数据库中未受损部分的数据或对损 坏的数据文件进行恢复需要很长时间，可以先使受损的数据文件脱机，将数据库打开给用户访问，再恢复 受损的数据文件最后将其联机。步骤如下：先在数据库mount时，将相关的数据文件或表空间进行脱机 alter database datafile xxx offline，然后将数据库open，这样就能使数据库未受损的部分先供用户 访问，之后再进行recover datafile/tablespace，完成后用alter database datafile/tablespace ‘ xxx’ online使其恢复联机就可被访问了。 当然用户也可以选择在数据库mount状态下，用recover database/datafile将所有的恢复工作做完，将所有数据文件一起打开供用户访问。 如果丢失的数据文件是最后一种情况，即包含有回滚段的非系统表空间数据文件。也可以选择是在数据库 先open的状态还是在mount状态下恢 |
