探索ORACLE不完全恢复之--基于SCN恢复 第一篇

探索ORACLE不完全恢复之--基于时间恢复

作者:吴伟龙   Name:Prodence Woo

QQ:286507175  msn:hapy-wuweilong@hotmail.com


基于SCN恢复 第一篇

1、在删除数据之前,察看下SCN号是多少:

SQL> col name format a45

SQL> set line 300

SQL> select name,checkpoint_change# from v$datafile_header;

 

NAME                                         CHECKPOINT_CHANGE#

---------------------------------------------------------------

/DBBak2/oradata/WWL/system01.dbf                         1487389

/DBBak2/oradata/WWL/undotbs01.dbf                        1487389

/DBBak2/oradata/WWL/sysaux01.dbf                         1487389

/DBBak2/oradata/WWL/users01.dbf                          1487389

/DBBak2/oradata/WWL/wwl01.dbf                            1487389

/DBBak2/oradata/WWL/wwl02.dbf                            1487389

/DBBak2/oradata/WWL/wwl03.dbf                            1487389

 

7 rows selected.

 

SQL> select file#,checkpoint_change#from v$datafile;

 

    FILE# CHECKPOINT_CHANGE#

---------- ------------------

        1            1487389

        2            1487389

        3            1487389

        4            1487389

        5            1487389

        6            1487389

        7            1487389

 

7 rows selected.

 

SQL>

 

 

2、删除测试用表:

SQL> drop table wwl002 purge;

 

Table dropped.

 

SQL> drop table wwl003 purge;

 

Table dropped.

 

SQL> drop table wwl004 purge;

 

Table dropped.

 

SQL> drop table wwl005 purge;

 

Table dropped.

 

 

3、开始做基于SCN的恢复:

SQL> recover database until change1487389;

ORA-00279: change 1436429 generated at07/12/2012 09:54:38 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_3_788372282.dbf

ORA-00280: change 1436429 for thread 1 isin sequence #3

 

 

Specify log: {<RET>=suggested |filename | AUTO | CANCEL}

auto

ORA-00279: change 1440657 generated at07/12/2012 14:00:52 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788450452.dbf

ORA-00280: change 1440657 for thread 1 isin sequence #1

 

 

ORA-00279: change 1440855 generated at07/12/2012 15:08:58 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788454538.dbf

ORA-00280: change 1440855 for thread 1 isin sequence #1

 

 

ORA-00279: change 1441316 generated at07/12/2012 15:19:50 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788455190.dbf

ORA-00280: change 1441316 for thread 1 isin sequence #1

 

 

ORA-00279: change 1442275 generated at07/12/2012 15:52:01 needed for thread 1

ORA-00289: suggestion : /DBSoft/product/10.2.0/db_1/dbs/arch1_1_788457121.dbf

ORA-00280: change 1442275 for thread 1 isin sequence #1

 

 

ORA-00279: change 1442953 generated at07/12/2012 16:25:06 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788459106.dbf

ORA-00280: change 1442953 for thread 1 isin sequence #1

 

 

ORA-00279: change 1462958 generated at07/12/2012 16:28:16 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_2_788459106.dbf

ORA-00280: change 1462958 for thread 1 isin sequence #2

ORA-00278: log file'/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788459106.dbf' no longer needed forthis recovery

 

 

ORA-00279: change 1462963 generated at07/12/2012 17:17:59 needed for thread 1

ORA-00289: suggestion : /DBSoft/product/10.2.0/db_1/dbs/arch1_1_788462279.dbf

ORA-00280: change 1462963 for thread 1 isin sequence #1

 

 

ORA-00279: change 1483784 generated at07/12/2012 17:54:25 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_2_788462279.dbf

ORA-00280: change 1483784 for thread 1 isin sequence #2

ORA-00278: log file'/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788462279.dbf' no longer needed forthis recovery

 

 

ORA-00279: change 1486119 generated at07/12/2012 20:35:27 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788474127.dbf

ORA-00280: change 1486119 for thread 1 isin sequence #1

 

 

Log applied.

Media recovery complete.

SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01589: must use RESETLOGS orNORESETLOGS option for database open

 

 

SQL> alter database open resetlogs;

 

Database altered.

 

SQL>    

 

4、至此,数据已经恢复完成:

SQL> select * from tab;

 

TNAME                          TABTYPE  CLUSTERID

------------------------------ -----------------

WWL001                         TABLE

WWL002                         TABLE

WWL003                         TABLE

WWL004                         TABLE

WWL005                         TABLE

 

 

SQL> select * from wwl005;

 

       ID NAME

---------- ---------------------------------------------

        1 wwl

        2 prodence

        3 woo

        4 xgx

        5 cms

 

SQL>

 

 

时间: 2024-10-25 07:47:18

探索ORACLE不完全恢复之--基于SCN恢复 第一篇的相关文章

探索ORACLE不完全恢复之--基于cancel恢复 第一篇

探索ORACLE不完全恢复之--基于cancel恢复 第一篇 作者:吴伟龙   Name:Prodence Woo QQ:286507175  msn:hapy-wuweilong@hotmail.com 基于cancel的不一致性恢复(归档存在) 第一篇                 基于取消的恢复只适用于以下情况:归档日志丢失导致完全恢复失败:丢失了数据文件和未归档的重做日志(联机重做日志):   1.先关闭数据库,执行一次全库冷备份.   SQL> selectfile_name fro

探索ORACLE不完全恢复之--基于备份控制文件恢复

探索ORACLE不完全恢复之--基于备份控制文件恢复 作者:吴伟龙   Name:Prodence Woo QQ:286507175  msn:hapy-wuweilong@hotmail.com 基于备份控制文件(unsing backup controlfile)的恢复 主要适用于:基于备份控制文件的恢复只要适用于以下情况:表空间被意外删除:所有控制文件全部损坏.   1.关闭数据库执行一次全库冷备份: SQL> select file_name from dba_data_files;  

不完全恢复之--基于时间恢复

探索ORACLE不完全恢复之--基于时间恢复 作者:吴伟龙   Name:Prodence Woo QQ:286507175  msn:hapy-wuweilong@hotmail.com 基于时间(time)恢复 基于时间的恢复将数据库恢复到备份点与失败点之间的某个时间点.基于时间的恢复不仅在介质失败的时候使用,也可以在数据库正常运行的时候使用.例如:某个用户误删除了某个表的数据,这个时候我们可以通过基于时间的恢复来将删除的数据恢复出来,示例如下:   1.查看当前用户下的表,只有一张WWL0

探索ORACLE之RMAN_07控制文件丢失恢复

探索ORACLE之RMAN_07控制文件丢失恢复 作者:吴伟龙   Name:Prodence Woo QQ:286507175  msn:hapy-wuweilong@hotmail.com 1.     控制文件(controlfile)丢失恢复 基于控制文件的复合多路径性,它的丢失分为两种,一种是其中某个控制文件的损坏或丢失,另外一种是所有控制文件均丢失.基于第一种情况,只需把好的控制文件复制一份在损坏或丢失的那个控制文件路径下即可.第二种情况下则需要通过备份信息来对控制文件进行恢复或手工

探索ORACLE之RMAN_07 磁盘损坏数据丢失恢复

探索ORACLE之RMAN_07 磁盘损坏数据丢失恢复 作者:吴伟龙   Name:Prodence Woo QQ:286507175  msn:hapy-wuweilong@hotmail.com             有的时候在企业里面难免会出现由于磁盘损坏而导致数据库的故障乃至数据的丢失,那么这个时候,那么这个时候数据的备份就显得尤为的重要.在这一节我们重点讨论下由于装载数据文件,redo日志文件,controlfile控制文件的磁盘损坏的数据恢复.   6.1 通过强制卸载磁盘模拟数据

探索ORACLE之RMAN_07 参数文件丢失恢复

探索ORACLE之RMAN_07 参数文件丢失恢复 作者:吴伟龙   Name:Prodence Woo QQ:286507175  msn:hapy-wuweilong@hotmail.com   Oracle数据库的参数文件有两种一种是pfile(初始化参数文件),还有一种是spfile(服务器初始化参数文件):实际上spfile是pfile衍生过来的一新参数文件,应用9i以后的版本,在9i之前的版本都不支持,只支持pfile:而且pfile是不能通过oracle命令来进行备份的,只有spf

MySQL备份恢复第一篇

今天学习了下MySQL的备份恢复内容,也算是对之前的 数据导入导出的一个细化内容.备份恢复的内容其实还是蛮复杂的,一般网站上提到的备份恢复也基本都是逻辑备份恢复的内容.对于更为高效的备份mysqlbackup和恢复的内容提到的很少,mysqlbackup是需要Licence,需要单独收费的,这也算是向oracle产品线的一个靠拢了. 首先我们还是走走老路,来看看最基本的逻辑备份恢复吧.我们模拟了3万多条的数据.然后尝试恢复回来. mysql> use test; Reading table in

探索ORACLE之RMAN_07整个业务表空间丢失恢复

探索ORACLE之RMAN_07整个业务表空间丢失恢复 作者:吴伟龙   Name:Prodence Woo QQ:286507175  msn:hapy-wuweilong@hotmail.com   1.     整个业务表空间丢失恢复 注意:以下的所有实验,都是基于上面的全库备份来做的恢复. 2.1 删除wwl表空间的所有数据文件 [root@wwldb ~]# cd /DBData/WWL/ [root@wwldb WWL]# rm -rf wwl* [root@wwldb WWL]#

探索ORACLE之RMAN_07恢复

探索ORACLE之RMAN_07恢复 作者:吴伟龙   Name:Prodence Woo QQ:286507175  msn:hapy-wuweilong@hotmail.com   备份的终极目的是为了更好的将数据恢复和还原过来,在前面的章节中我们已经重点谈完了RMAN的备份,实际上也穿插的谈了些复杂的完整恢复.当然在这节我们将会由浅入深的详细谈谈在几种不同情况下的数据库恢复. 1.     数据文件的丢失恢复 1.1    在wwl表空间上创建5张表,并添加数据. SQL> create