手工管理的备份恢复解析.ppt

删除控制文件。 关闭数据库，对数据库进行全备份。 将数据库启动到nomount 控制文件建立成功。 数据库自动进入mount状态。 重建控制文件以后，所有的SCN信息都丢失了。 控制文件中的系统SCN从current日志文件中的firstchange取得。 数据文件SCN从数据文件头部取得。 数据都没有丢失。 上面建立控制文件的时候，没有包含临时表空间。 使用以前备份的控制文件，在丢失当前联机重做日志文件的情况下，进行不完全恢复 确认表位于这个当前的联机日志文件中 删除了联机重做日志文件和控制文件。 关闭数据库、备份数据库。 不完全恢复，需要控制文件和数据文件 恢复直接完成，如果报错，那么重新执行一次上面的命令，但是在输入的时候，输入cancel，不进行恢复，只是为了完成media recovery colplete。 显然数据丢失。 联机重做日志文件被重建 创建新的控制文件，在丢失当前联机重做日志文件的情况下，进行不完全恢复。 1、系统的checkpoint会从redo log的current的first_change中取 2、文件SCN会从数据文件头部中取 我们此前做过trace文件的创建，数据库的结构没有发生变化，因此可以继续使用。 关闭数据库，进行数据库的全备份 1、使用的是非abort模式关闭 2、备份数据库 在SQL中执行这一段代码 控制文件的文件SCN取自数据文件头部的SCN 因为联机重做日志文件不存在，因此系统SCN变成了0，需要归档日志来提升。 模拟了一种非常糟糕的情况 1、掉电、联机日志和控制文件都损坏 1、关闭数据库（abort），对数据库进行全备 省略，建立控制文件。 因为使用的是abort，出现上面的错误。 通过修改参数，强制打开数据库。 在pfile里面添加上面的三行。 数据库虽然打开，但是使用的是强制打开，因此存在数据库的不一致性。需要马上进行数据库的export全库导出，重建该数据库。 使用alter database open resetlogs打开数据库。 报了一个错误。 实验 掉电、控制文件和联机重做日志文件全部都损坏 归档日志还在、数据文件有备份。 使用normal选项使某个数据文件离线，离线以前，oracle会发出文件级别的检查点，从而唤醒DBWn将内存中属于该文件的所有脏数据块写入数据文件，并且控制文件中检查点SCN与数据文件一致。 即便是在不完全恢复期间该数据文件仍然保持离线状态的话，也可以在不完全恢复成功以后，再将该文件在线，由于该文件不需要介质恢复，所以oracle可以直接将数据文件头的SCN修改成当前SCN 关键是在数据文件online的时候，控制文件中记录的SCN和数据文件头部的SCN是一致的，那么说明数据文件不需要进行介质恢复，因此可以直接online 执行依次checkpoint，对数据文件头部和控制文件中的SCN和结束SCN进行了更新。 控制文件中记录的数据文件的检查点信息 数据文件头部的检查点一定是540159，而数据文件offline时的系统检查点分别是540282和540285，下一次数据文件online的时候，需要执行介质恢复。 备份数据文件 数据文件immediate offline Resetlogs打开数据库的点 文件在这个点online 重做记录一直到这个点 请问这个点的数据文件能够online吗？ 对新添加的数据文件进行了备份。 对temp表空间没有进行备份。 默认的永久表空间不能删除。 正在操作中，DBA做了一个错误的操作，将表空间删除了。我们需要将数据恢复到出问题的那个时刻。 需要进行不完全恢复。 表空间被删除以后，继续进行正常操作，产生了一些数据。 通过查看备份，我们确认所有数据文件都有备份，不是同一个时刻，而且temp没有备份，所有归档还都在。 通过日志，发现12：29：40发生了误删除，我们恢复到提前一秒钟 备份当前所有的数据文件、控制文件、联机重做日志文件 恢复所有的数据文件 这些数据文件都不是同一个时刻备份的。但都是出事前备份的。 发现已经没有6号文件了。 发现6号数据文件还是没有回来。 6号数据文件回来了。 发现6号数据文件的名字不对。 对文件名字进行修改。 数据文件需要校正。 数据回来了，但是因为是不完全恢复，还是丢失了部分数据。 基于SCN的恢复和基于时间的恢复一样，只不过基于SCN的恢复更加精确。 前提都是 1、控制文件没有损坏、联机文件没有损坏、归档日志文件没有损坏 我们有意识的将数据库恢复到过去的某个点，例如为了恢复误删除 对于联机重做日志文件和归档日志文件的丢失，我们通常使用基于cancel的不完全恢复，下面的实验就是删除联机重做日志文件后的恢复 2号日志文件组为当前的联机重做日志文件组，将它删除 数据库在进行