这里会讨论令Oracle停机时间最小化的步骤各种形式的停机计划的或者是非计划的总是不断地发生一个DBA应该有正确的备份策略这样在数据库出现问题时就可以更快地恢复
以下是假定的备份策略和数据库的运作条件
控制文件是镜像的
数据库运行在archivelog模式
每个星期都进行冷备份
每日都进行热备份
每日都进行一次全数据库导出
事件完整的数据库重构
在这种情形下你可以使用全数据库导出或者冷热备份结合的方式来重构数据库要注意的是无论你选择哪种方式在线redo log中的事务都会丢失
事件恢复部分的表空间
可以使用以下的步骤来恢复
以restrict模式启动数据库
重新创建表空间
使用最新的全数据库导出来导入并且使用ignore=y的选项;
关闭并且重新以normal的模式启动数据库实例
事件丢失一般的数据文件
丢失一般数据文件的恢复步骤根据所丢失的数据文件包含的表空间类型而定;例如回滚段用户表空间索引表空间或者是只读的表空间你可能会遇到以下的错误
尝试启动数据库并且碰到错误的信息ORA ORA可能还有一个操作系统的错误
尝试以normal或者immediate的模式关闭数据库可能会碰到ORA ORA的错误信息还有一个系统错误
以下的步骤可以用作恢复
关闭数据库
由热备份中恢复丢失的数据文件
Startup mount数据库
执行以下的查询来得到所有你的在线redo log文件和它们相应的次序和首次修改号
SELECTXGROUP#MEMBERSEQUENCE#FIRST_CHANGE#
FROMV$LOGXV$LOGILEY
WHEREXGROUP#=YGROUP#;
如果得到的CHANGE#比在线redo log最小的FIRST_CHANGE# 还小那么该文件不能被完全恢复你可以有两个选择
如果可以接受丢失最近一次冷备份以来的数据库修改装入备份并且继续恢复
如果不能接受丢失数据库的修改那么必须重新创建表空间
通过使用存档和在线的redo log来恢复数据文件
打开数据库
事件恢复一个特别的表
可以采用以下的步骤恢复
使用最近的一次全数据库导出来导入表并且使用owner=和tables=的选项
考虑到性能的原因可能需要重建表索引
事件丢失控制文件
在数据库起来并且运行时通常都不能检测到控制文件的问题如果控制文件丢失或者损坏了Oracle将不会了解下次数据库的启动时将会导致ORA错误(标识控制文件%s的错误)还有一个系统级的错误
如果只是丢失了其中的一个控制文件可以采用下面的步骤来恢复
如果它正在运行的话先关闭它
查找丢失控制文件的原因是由于硬件的问题吗(磁盘还是控制器)?
如果不是硬件的问题将控制文件的一个好的拷贝复制到丢失的位置并且跳到步骤
如果是硬件的问题复制一个好的控制文件拷贝到一个可靠的位置
编辑initsidora 或者 configsidora更新CONTROL_FILES以反映最新的控制文件位置
启动数据库
事件丢失全部的控制文件
可以采用以下的步骤恢复
关闭数据库
进行一次全数据库备份包括全部的数据文件和redo log文件
以NOMOUNT的状态启动数据库
使用CREATE CONTROLFILE重新创建控制文件你也可以备份控制文件到一个trace文件然后执行该文件
在数据库上进行媒体恢复
打开数据库
使用shutdown normal关闭数据库
对数据库进行一次冷备份
事件丢失一个索引
最简单的方法就是重新创建丢失的索引
事件丢失一个非活动的redo log
如果丢失redo数据恢复将是不完全的必须重新创建涉及的表空间要重新创建表空间可以使用全的数据库导出这样就可以很容易的导入数据并且重新创建该表空间的对象可以使用以下的步骤来恢复
通过Alter system来切换redo log文件
关闭数据库
startup mount数据库
离线删除涉及的数据文件
打开数据库
删除用户的表空间包括其中的内容
通过全数据库备份重新创建表空间和其中的对象
事件丢失活动的Redo log
如事件讨论的一样如果丢失了redo数据恢复将是不完全的必须重新创建涉及的表空间可以采用以下的步骤恢复
关闭数据库
startup mount数据库
离线删除涉及的数据文件
打开数据库
删除用户的表空间包括其中的内容
通过全数据库备份重新创建表空间和其中的对象
要注意的是活动的事务将会丢失
事件丢失存档的Redo log文件
如果存档的redo log文件丢失应该马上进行一次冷备份最好也进行一次全数据库导出没有丢失的存档redo log文件的任何恢复都将是不完全的
事件丢失活动的回滚段
这里指的是丢失一个回滚段的一个数据文件这是一个危急的恢复过程它主要是在于保存活动的事务这里假定数据库已经起来而你想保存当前运行的事务要使用以下的恢复过程数据库必须运行在archivelog模式下
可以使用以下步骤恢复
不要关闭数据库对于这种事件数据库启动比关闭更容易解决问题
令属于该数据文件中的全部回滚段离线
删除全部离线的回滚段
在上面的第步中如果回滚段中有活动的事务你将不能令它离线可运行以下的查询来查看哪些事物是活动的
SELECTSEGMENT_NAMEXACTSACTIVE_TXVSTATUS
FROMV$ROLLSTATVDBA_ROLLBACK_SEGS
WHERETABLESPACE_NAME=tablespace_nameAND
SEGMENT_ID=USN;
如果上面的查询没有结果那么所有的回滚段都是离线的但是如果上面的查询返回一行或者多行并且其状态为PENDING OFFLINE那么可检查这些回滚段的ACTIVE_TX列带有值的回滚段将很快会离线;但是非的值表示上面有活动的事务它们需要被提交或者回滚
处理活动的事务执行以下的查询来查看哪些用户的事务被指派到该回滚段
SELECTSSIDSSERIAL#SUSERNAMERNAMEROLLBACK
FROMV$SESSIONSV$TRANSACTIONTV$ROLLNAMER
WHERERNAMEIN(pending_rollbackpending_rollbackpending_rollbackN)AND
STADDR=TADDRAND
TXIDUSN=RUSN;
在知道哪些用户在pending offline的回滚段上有活动的事务后可以要求他们提交或者回滚他们的事务或者可以使用以下的命令杀掉它们的进程
ALTER SYSTEM KILL SESSION sid serial#;
在你处理完所有活动的事务后执行以下的步骤
丢弃表空间及其中的全部内容
重新创建回滚表空间
重新创建回滚段并且令它们在线
事件丢失全部的回滚段
在这种事件下将丢失全部活动的事务并且需要重新创建回滚段这样大的问题可能是由于一个硬件问题造成的可以采用以下的步骤恢复
关闭数据库
使用DBVERIFY验证全部的数据文件
解决其它的硬件问题或者数据文件损坏
以startup mount的方式启动数据库实例
在数据库上执行媒体恢复
打开数据库
按需要创建新的回滚段
事件导出文件损坏
如果导出文件不能用了那么应该冷备份数据库并且进行一个全的数据库导出这是假定数据库自身没有问题如果数据库也损坏了那么应该执行以下的步骤
ORA错误信息通常都表示一个或者多个的数据文件损坏了查明哪些表受到影响它们应该是错误信息中指明的数据文件中的表格
跳过坏的数据块将数据由表格中选择到临时表格中
丢弃损坏的表
将临时表重命名为丢弃的表
重新建立受影响表上的全部索引
使用VALIDATE STRUCTURE CASCADE的选项来分析全部损坏的表
要注意的是损坏块中数据将会丢失并且不能恢复
事件在热备份时关机
如果在热备份正在进行的时候突然关机其中的一些表空间将可能处在备份模式当你尝试打开数据库时它将只能mount并且指示某些表空间处于热备份模式由于数据库不能打开你将不能让表空间脱离热备份模式你可以使用以下的步骤恢复
startup mount数据库
查询v$backup以查看哪些数据文件处于ACTIVE状态
通过使用命令ALTER DATABASE DATAFILE END BACKUP来将这些数据文件脱离备份模式
打开数据库
事件恢复到某个特别的时间点
以下的步骤可用来执行pointintime恢复
关闭数据库实例
以NOMOUNT的状态启动数据库实例
使用UNTIL的选项来恢复数据库
打开数据库
Shutdown NORMAL
启动数据库实例
事件恢复到一个特别的事件或者活动
可以使用以下的步骤来恢复
关闭数据库实例
以NOMOUNT状态启动数据库实例;
使用UNTIL CANCEL来恢复数据库提供存档的redo log文件请求直到该活动/事件为止
输入CANCEL来取消恢复
打开数据库;
使用NORMAL的模式来关闭数据库
启动数据库实例
结论
高可用性对于任何的商业都是很重要的ORACLE DBA可以通过一些计划以确保停机时间最小化这篇文章讨论了不同的策略可以达到这个目的
