oracle不完全恢复

木一

　　在特定的情况下，丢失的数据没有备份或者业务需要（如误删除）则必须采用DBPITR（数据库时间点不完全恢复）或TSPITR（表空间时间点不完全恢复），比如我们误删除了数据，当然我们有更好的恢复方式，比如FLASHBACK TABLE.如果采用介质恢复模式，可以基于时间，也可以基于SCN来实现不完全恢复
　　 
　　不完全恢复能够重建数据库，使之恢复到以前的某个时间点（发生故障之前）。
　　注释：该情况会导致恢复操作完成redo应用后，恢复时间点后的提交事务处理的数据将丢失。
　　如果恢复时间点后的数据也要救回来，可能需要手动重新输入业务数据
　　不完全恢复操作可能比较困难而且耗费时间较长。
　　不完全恢复的条件：
　　1）必须有恢复时间点之前所有数据文件的完整备份，可以是脱机或联机备份，要注意备份的有效性检查（可以通过DBV）
　　2）必须有备份后到指定的恢复时间截止点的所有归档日志，通常在完全恢复操作失败的情况下进行不完全恢复。
　　造成不完全恢复的原因：
　　1）丢失归档，数据库只能恢复到最后没有断开的归档日志，这样数据库将恢复到过去的某一时间的状态。
　　2）丢失重做日志（未镜像重做日志，并且重做日志在归档之前丢失，数据文件也丢失。
　　；未镜像重做日志，并且当前和活动重做日志损坏，有数据文件备份。例如：SHUTDOWN ABORT，然后在线日志坏了）
　　崩溃恢复会应用ACTIVE和CURRENT的日志文件，ACTIVE和CURRENT的日志文件如果损坏了，那就惨了
　　如果第1个需要应用的在线日志损坏就更惨，连打开都难，需要设置隐含参数，可能就丢失个别在线日志的数据
　　如果能应用到1个在线日志，还算幸运，因为恢复是，至少需要应用一个日志，才能达到一致性状态
　　3）用户错误
　　用户错误的删除了某个表，提交了用错误的where更新的数据，可以采取flashback的技术，或者TSPITR,DBPITR
　　我们看可以DB的时间点恢复，或者基于表空间的时间点恢复，
　　4）丢失控制文件
　　未镜像控制文件，不知道数据库的结构，但是有旧的二进制的控制文件的备份
　　恢复策略：
　　1.基于时间的恢复
　　恢复截止指定时间点之前的所有更改提交后，该恢复终止，语法是RECOVER DATABASE UNTIL TIME 'xxxx'；
　　注意，引号的时间格式必须与数据库匹配，或者通脱自定义时间格式，nls_date_format必须匹配。
　　 1)对数据作出了错误的更改，或者删除了重要的表，并且知道错误发生的大概时间。比如有日期字段信息，或者日志，也可以用LOGMGR。如果您立即得到通知，恢复时间最短、数据损失最少。需要对程序在测试和预演环境进行严格的测试,保证程序的安全性应当可以避免此类恢复。
　　 2） 知道未镜像的联机重做日志损坏的大概时间，镜像日志可以避免该情况。
　　2.基于CANCEL的恢复
　　 1)在恢复提示符下输入CANCEL（而不是日志文件名），即可终止该恢复。在以下情况下使用此方法：
　　当前重做日志文件或组被破坏，并且不可用于恢复。镜像可以避免此类恢复。
　　注意，至少要应用完一个日志后才可以CANCEL.
　　 2)进行恢复所需的归档重做日志文件丢失。
　　3.基于SCN（systemchange number）的恢复
　　 1）我们基于SCN的恢复的语法是RECOVERDATABASE UNTIL CHANGE.....
　　 2)使用备份控制文件恢复,我们说了，使用备份控制文件恢复是没有终点的,所以我们理解成不完全恢复
　　使用备份控制文件表示控制文件的（数据文件、日志文件）物理结构信息不是最新的,实际的数据文件可能是备份的，也可以是最新的，使得采用备份控制文件恢复最终会以实际的日志文件为恢复的终点,只要在REDO不断开的情况下顺序应用日志序列到最后。实际的日志文件有多少就可以恢复多少
　　该恢复使用场景：
　　 1）所有控制文件都已丢失，并且无法重新创建，但存在控制文件的二进制备份。
　　预防措施：镜像控制文件（至不同磁盘）并保留CREATE CONTROLFILE 　的TRACE语句文本将减少使用该方法的几率。
　　ALTER DATABASE BACKUP CONTROLFILE TO ‘二进制文件’;
　　ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
　　 2）将某个结构与当前数据库不同的数据库还原到先前的某个时间点。
　　比如新建数据文件会将初试的信息，如创建时的SCN等信息会存储在控制文件中，并将该控制文件备份下来。
　　如果后来将该数据文件删除，当前控制文件失去这个文件的信息。
　　如果要恢复前面新建的数据文件，就需要用原来包含有该数据文件初试信息的备份控制文件进行恢复。
　　注意事项：
　　1、认真按照恢复步骤进行操作很重要，不完全恢复中的大都数问题都是dba恢复过程中的错误造成的
　　需要DBA深入了解不完全恢复的机制，以最准确的获得尽量精准的数据
　　2、事务活动只能前滚值期望的时间，而不能回退值期望的时间
　　这就是对要及时恢复的数据库必须还原所有数据文件的原因。如果没能还原所有数据文件，将无法打开（非同步）数据库。所以，整个数据库是一个不完全恢复的整体，甚至整个表空间作为不完全恢复的整体
　　3、开始不完全恢复之前应执行整体关闭数据库备份（包括控制文件和重做日志），需要做个冷备，以防止恢复失败后无法继续进行恢复，造成无法承受的后果。这样做的好处：
　　a.运行从错误中恢复，如果恢复失败（如超出了期望的恢复点）重做日志和控制文件将无法用于下一次恢复，除非存在这些文件的备份。所以，我们DBA碰到故障的时候，如果有时间保护现场，最好先做备份(最好的保护自己)
　　b.恢复成功后，执行关闭的数据库的整体备份。
　　因为不完全恢复RESETLOGS打开数据库后涉及数据库版本的问题，导致之前的所有备份将无效
　　要从RESETLOGS前一个版本恢复会有很大麻烦，所以建议在不完全恢复生成新的版本后做一个整体备份。