爆款云主机2核4G限时秒杀,88元/年起!
查看详情

活动

天翼云最新优惠活动,涵盖免费试用,产品折扣等,助您降本增效!
热门活动
  • 618智算钜惠季 爆款云主机2核4G限时秒杀,88元/年起!
  • 免费体验DeepSeek,上天翼云息壤 NEW 新老用户均可免费体验2500万Tokens,限时两周
  • 云上钜惠 HOT 爆款云主机全场特惠,更有万元锦鲤券等你来领!
  • 算力套餐 HOT 让算力触手可及
  • 天翼云脑AOne NEW 连接、保护、办公,All-in-One!
  • 中小企业应用上云专场 产品组合下单即享折上9折起,助力企业快速上云
  • 息壤高校钜惠活动 NEW 天翼云息壤杯高校AI大赛,数款产品享受线上订购超值特惠
  • 天翼云电脑专场 HOT 移动办公新选择,爆款4核8G畅享1年3.5折起,快来抢购!
  • 天翼云奖励推广计划 加入成为云推官,推荐新用户注册下单得现金奖励
免费活动
  • 免费试用中心 HOT 多款云产品免费试用,快来开启云上之旅
  • 天翼云用户体验官 NEW 您的洞察,重塑科技边界

智算服务

打造统一的产品能力,实现算网调度、训练推理、技术架构、资源管理一体化智算服务
智算云(DeepSeek专区)
科研助手
  • 算力商城
  • 应用商城
  • 开发机
  • 并行计算
算力互联调度平台
  • 应用市场
  • 算力市场
  • 算力调度推荐
一站式智算服务平台
  • 模型广场
  • 体验中心
  • 服务接入
智算一体机
  • 智算一体机
大模型
  • DeepSeek-R1-昇腾版(671B)
  • DeepSeek-R1-英伟达版(671B)
  • DeepSeek-V3-昇腾版(671B)
  • DeepSeek-R1-Distill-Llama-70B
  • DeepSeek-R1-Distill-Qwen-32B
  • Qwen2-72B-Instruct
  • StableDiffusion-V2.1
  • TeleChat-12B

应用商城

天翼云精选行业优秀合作伙伴及千余款商品,提供一站式云上应用服务
进入甄选商城进入云市场创新解决方案
办公协同
  • WPS云文档
  • 安全邮箱
  • EMM手机管家
  • 智能商业平台
财务管理
  • 工资条
  • 税务风控云
企业应用
  • 翼信息化运维服务
  • 翼视频云归档解决方案
工业能源
  • 智慧工厂_生产流程管理解决方案
  • 智慧工地
建站工具
  • SSL证书
  • 新域名服务
网络工具
  • 翼云加速
灾备迁移
  • 云管家2.0
  • 翼备份
资源管理
  • 全栈混合云敏捷版(软件)
  • 全栈混合云敏捷版(一体机)
行业应用
  • 翼电子教室
  • 翼智慧显示一体化解决方案

合作伙伴

天翼云携手合作伙伴,共创云上生态,合作共赢
天翼云生态合作中心
  • 天翼云生态合作中心
天翼云渠道合作伙伴
  • 天翼云代理渠道合作伙伴
天翼云服务合作伙伴
  • 天翼云集成商交付能力认证
天翼云应用合作伙伴
  • 天翼云云市场合作伙伴
  • 天翼云甄选商城合作伙伴
天翼云技术合作伙伴
  • 天翼云OpenAPI中心
  • 天翼云EasyCoding平台
天翼云培训认证
  • 天翼云学堂
  • 天翼云市场商学院
天翼云合作计划
  • 云汇计划
天翼云东升计划
  • 适配中心
  • 东升计划
  • 适配互认证

开发者

开发者相关功能入口汇聚
技术社区
  • 专栏文章
  • 互动问答
  • 技术视频
资源与工具
  • OpenAPI中心
开放能力
  • EasyCoding敏捷开发平台
培训与认证
  • 天翼云学堂
  • 天翼云认证
魔乐社区
  • 魔乐社区

支持与服务

为您提供全方位支持与服务,全流程技术保障,助您轻松上云,安全无忧
文档与工具
  • 文档中心
  • 新手上云
  • 自助服务
  • OpenAPI中心
定价
  • 价格计算器
  • 定价策略
基础服务
  • 售前咨询
  • 在线支持
  • 在线支持
  • 工单服务
  • 建议与反馈
  • 用户体验官
  • 服务保障
  • 客户公告
  • 会员中心
增值服务
  • 红心服务
  • 首保服务
  • 客户支持计划
  • 专家技术服务
  • 备案管家

了解天翼云

天翼云秉承央企使命,致力于成为数字经济主力军,投身科技强国伟大事业,为用户提供安全、普惠云服务
品牌介绍
  • 关于天翼云
  • 智算云
  • 天翼云4.0
  • 新闻资讯
  • 天翼云APP
基础设施
  • 全球基础设施
  • 信任中心
最佳实践
  • 精选案例
  • 超级探访
  • 云杂志
  • 分析师和白皮书
  • 天翼云·创新直播间
市场活动
  • 2025智能云生态大会
  • 2024智算云生态大会
  • 2023云生态大会
  • 2022云生态大会
  • 天翼云中国行
天翼云
  • 活动
  • 智算服务
  • 产品
  • 解决方案
  • 应用商城
  • 合作伙伴
  • 开发者
  • 支持与服务
  • 了解天翼云
      • 文档
      • 控制中心
      • 备案
      • 管理中心

      数据库按时间点恢复

      首页 知识中心 数据库 文章详情页

      数据库按时间点恢复

      2023-05-23 01:22:27 阅读次数:135

      数据库

      按时间点恢复


      数据库按时间点恢复,可以从要恢复的目标时间之前的备份中还的数据库,然后使用增量备份和重做日志来将数据库前滚到目标时间点,按时间点恢复也叫不完全恢复因为不使用所有的日志或者不完全恢复对数据库的所有改变。

      数据库按时间点恢复所要满足的条件
      1.数据库必须运行在archivelog模式下
      2.必须要有恢复目标时间点之前所有数据文件的备份和在备份SCN与目标SCN之间所有的归档重做日志

      每次以resetlogs选项打开数据库时一个新的数据库incarnation就会被创建。执行open resetlogs操作时就会对当前的联机重做日志文件进行归档。incarnation会将重做日志序列号设置为1,并且指联机重做日志一个新的时间戳。它也会增加incarnation的序号,它被用来唯一标记和识另重做日志流。

      incarnation可能存在的几种关系
      1.current incarnation是由那个incarnation执行open resetlog操作产生的,那个incarnation就是current incarnation的parent incarnation

      2.parent incarnation和它parent incarnation的incarnation就叫作current incarnation的ancestor incarnations

      3.如果两个incarnation共享相同的ancestor那么它们就是sibling incarnations

      SQL> select * from v$database_incarnation;
      
      INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TI PRIOR_RESETLOGS_CHANGE# PRIOR_RESETL STATUS  RESETLOGS_ID PRIOR_INCARNATION# FLASHBACK_DATABASE_ALLOWED
      ------------ ----------------- ------------ ----------------------- ------------ ------- ------------ ------------------ --------------------------
                 1                 1 30-JUN-05                          0              PARENT     562360180                  0 NO
                 2            446075 05-SEP-14                          1 30-JUN-05    PARENT     857466832                  1 NO
                 3           2849317 27-JAN-15                     446075 05-SEP-14    PARENT     870102602                  2 NO
                 4           2880152 27-JAN-15                    2849317 27-JAN-15    PARENT     870133266                  3 NO
                 5           3017109 01-FEB-15                    2880152 27-JAN-15    PARENT     870550288                  4 NO
                 6           3041066 01-FEB-15                    3017109 01-FEB-15    PARENT     870563157                  5 NO
                 7           3041350 01-FEB-15                    3041066 01-FEB-15    PARENT     870564201                  6 YES
                 8           3111834 03-FEB-15                    3041350 01-FEB-15    ORPHAN     870724654                  7 YES
                 9           3111834 03-FEB-15                    3041350 01-FEB-15    ORPHAN     870726369                  7 YES
                10           3114665 03-FEB-15                    3041350 01-FEB-15    ORPHAN     870726883                  7 YES
                11           3114664 03-FEB-15                    3041350 01-FEB-15    CURRENT    870729934                  7 YES
      
      11 rows selected.
      
      RMAN> list incarnation;
      
      
      List of Database Incarnations
      DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
      ------- ------- -------- ---------------- --- ---------- ----------
      1       1       TEST     2155613261       PARENT  1          30-JUN-05
      2       2       TEST     2155613261       PARENT  446075     05-SEP-14
      3       3       TEST     2155613261       PARENT  2849317    27-JAN-15
      4       4       TEST     2155613261       PARENT  2880152    27-JAN-15
      5       5       TEST     2155613261       PARENT  3017109    01-FEB-15
      6       6       TEST     2155613261       PARENT  3041066    01-FEB-15
      7       7       TEST     2155613261       PARENT  3041350    01-FEB-15
      8       8       TEST     2155613261       ORPHAN  3111834    03-FEB-15
      9       9       TEST     2155613261       ORPHAN  3111834    03-FEB-15
      11      11      TEST     2155613261       CURRENT 3114664    03-FEB-15
      10      10      TEST     2155613261       ORPHAN  3114665    03-FEB-15

      要执行按时间点恢复需要准备好以下两个条件:
      1.决定要恢复到的目标时间,SCN,还原点或者日志序列号。闪回查询,闪回版本查询和闪回事务查询可能帮助你来识别逻辑错误。也可以检查alert.log的信息来帮助你判断恢复的目标时间点。另外也可以判断包含目标SCN的日志序列号然后通过日志进行恢复。例如,查询v$log_history来查看已经归档的日志信息。

      SQL> select * from v$log_history;
      
           RECID      STAMP    THREAD#  SEQUENCE# FIRST_CHANGE# FIRST_TIME   NEXT_CHANGE# RESETLOGS_CHANGE# RESETLOGS_TI
      ---------- ---------- ---------- ---------- ------------- ------------ ------------ ----------------- ------------
             231  870563592          1          2       3041294 01-FEB-15         3041343           3041066 01-FEB-15
             232  870564201          1          3       3041343 01-FEB-15         3041349           3041066 01-FEB-15
             233  870597597          1          1       3041350 01-FEB-15         3063719           3041350 01-FEB-15
             234  870684680          1          2       3063719 02-FEB-15         3097923           3041350 01-FEB-15
             235  870724659          1          3       3097923 03-FEB-15         3114664           3041350 01-FEB-15
             236  870726371          1          1       3111834 03-FEB-15         3112739           3111834 03-FEB-15
             237  870726883          1          1       3111834 03-FEB-15         3114664           3111834 03-FEB-15
             238  870729935          1          1       3114665 03-FEB-15         3116367           3114665 03-FEB-15
             239  870769788          1          1       3114664 03-FEB-15         3135728           3114664 03-FEB-15

      例如,如果你发在上午10点1分一个用户意外删除了一个表空间,那么可以将数据库恢复到上午10点,就是在删除表空间前的时间点。在恢复之后在上午10点之后的所有改变都会丢失.

      2.如果使用目标时间表达式代替目标SCN,那么在使用RMAN之前要确保时间格式的环境变量设置合适。
      NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
      NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'

      使用current incarnation来执行按时间点恢复
      使用current incarnation执行按时间点恢复时是使用的当前版本的控制文件。当执行按时间点恢复时,可以使用set until命令来设置恢复的目标时间,而不用对restotre和recover命令单独设置until子句从而避免出错。这能确保从备份中还原的数据文件的时间戳早于后续的recover操作。

      按时间点恢复的过程如下:
      我们把scott用户下的表emp中的所有记录删除,并且在删除之前记录了当前系统的SCN,然后执行按时间点恢复来恢复表中的记录。

      SQL> select current_scn from v$database;
      
      CURRENT_SCN
      -----------
          3142264
      
      SQL> select to_char(scn_to_timestamp(3142264),'yyyy-mm-dd hh24:mi:ss') from dual;
      
      TO_CHAR(SCN_TO_TIME
      -------------------
      2015-02-04 11:22:29
      
      SQL>  select * from v$log;
      
          GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME
      ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------
               1          1          4   52428800          1 NO  CURRENT                3142228 04-FEB-15
               3          1          3   52428800          1 YES INACTIVE               3142176 04-FEB-15
               2          1          2   52428800          1 YES INACTIVE               3135728 04-FEB-15
      
      
      SQL> select * from emp;
      
           EMPNO ENAME      JOB              MGR HIREDATE            SAL       COMM     DEPTNO
      ---------- ---------- --------- ---------- ------------ ---------- ---------- ----------
            7369 SMITH      CLERK           7902 17-DEC-80           800                    20
            7499 ALLEN      SALESMAN        7698 20-FEB-81          1600        300         30
            7521 WARD       SALESMAN        7698 22-FEB-81          1250        500         30
            7566 JONES      MANAGER         7839 02-APR-81          2975                    20
            7654 MARTIN     SALESMAN        7698 28-SEP-81          1250       1400         30
            7698 BLAKE      MANAGER         7839 01-MAY-81          2850                    30
            7782 CLARK      MANAGER         7839 09-JUN-81          2450                    10
            7788 SCOTT      ANALYST         7566 19-APR-87          3000                    20
            7839 KING       PRESIDENT            17-NOV-81          5000                    10
            7844 TURNER     SALESMAN        7698 08-SEP-81          1500          0         30
            7876 ADAMS      CLERK           7788 23-MAY-87          1100                    20
            7900 JAMES      CLERK           7698 03-DEC-81           950                    30
            7902 FORD       ANALYST         7566 03-DEC-81          3000                    20
            7934 MILLER     CLERK           7782 23-JAN-82          1300                    10
      
      14 rows selected.
      
      SQL> delete from emp;
      
      14 rows deleted.
      
      SQL> commit;
      
      Commit complete.
      
      SQL> select * from emp;
      
      no rows selected

      1.连接到目标数据库或恢复目录(如果有),将数据库启动到mount状态:

      [oracle@oracle11g ~]$ rman target/
      
      Recovery Manager: Release 10.2.0.5.0 - Production on Wed Feb 4 10:25:34 2015
      
      Copyright (c) 1982, 2007, Oracle.  All rights reserved.
      
      connected to target database (not started)
      
      RMAN> startup mount
      
      Oracle instance started
      database mounted
      
      Total System Global Area     327155712 bytes
      
      Fixed Size                     1273516 bytes
      Variable Size                138412372 bytes
      Database Buffers             184549376 bytes
      Redo Buffers                   2920448 bytes

      2.运行RUN块来执行按时间点恢复。在RUN块中使用set until来指定恢复的目标时间,还原点,SCN或日志序列号。如果指定的是目标时间,那么使用NLS_LANG和NLS_DATE_FORMAT环境变量所指定的格式。如果自动通道没有配置,那么要为访问的磁盘或磁带分配通道。

      RMAN> run
      2> {
      3>  set until scn 3142264;
      4>  restore database;
      5>  recover database;
      6> }
      
      executing command: SET until clause
      
      Starting restore at 04-FEB-15
      allocated channel: ORA_DISK_1
      channel ORA_DISK_1: sid=157 devtype=DISK
      
      channel ORA_DISK_1: starting datafile backupset restore
      channel ORA_DISK_1: specifying datafile(s) to restore from backup set
      restoring datafile 00001 to /u01/app/oracle/oradata/test/system01.dbf
      restoring datafile 00002 to /u01/app/oracle/oradata/test/undotbs01.dbf
      restoring datafile 00003 to /u01/app/oracle/oradata/test/sysaux01.dbf
      restoring datafile 00004 to /u01/app/oracle/oradata/test/users01.dbf
      restoring datafile 00005 to /u01/app/oracle/oradata/test/example01.dbf
      restoring datafile 00006 to /u01/app/oracle/oradata/test/test01.dbf
      restoring datafile 00007 to /u01/app/oracle/oradata/test/testbak.dbf
      channel ORA_DISK_1: reading from backup piece /u02/test_df870779983_s135_s1
      channel ORA_DISK_1: restored backup piece 1
      piece handle=/u02/test_df870779983_s135_s1 tag=TAG20150204T111943
      channel ORA_DISK_1: restore complete, elapsed time: 00:02:29
      Finished restore at 04-FEB-15
      
      Starting recover at 04-FEB-15
      using channel ORA_DISK_1
      
      starting media recovery
      media recovery complete, elapsed time: 00:00:02
      
      Finished recover at 04-FEB-15

      从alert日志文件中可以看到如下信息:

      The input backup piece /u02/test_df870779983_s135_s1 is in compressed format.
      Full restore complete of datafile 6 /u01/app/oracle/oradata/test/test01.dbf.  Elapsed time: 0:00:01
        checkpoint is 3142189
      Full restore complete of datafile 7 /u01/app/oracle/oradata/test/testbak.dbf.  Elapsed time: 0:00:06
        checkpoint is 3142189
      Full restore complete of datafile 4 /u01/app/oracle/oradata/test/users01.dbf.  Elapsed time: 0:00:09
        checkpoint is 3142189
        last deallocation scn is 3111848
      Wed Feb 04 11:25:47 CST 2015
      Full restore complete of datafile 2 /u01/app/oracle/oradata/test/undotbs01.dbf.  Elapsed time: 0:00:37
        checkpoint is 3142189
        last deallocation scn is 3106509
      Wed Feb 04 11:25:58 CST 2015
      Full restore complete of datafile 5 /u01/app/oracle/oradata/test/example01.dbf.  Elapsed time: 0:00:46
        checkpoint is 3142189
        last deallocation scn is 2526488
      Wed Feb 04 11:26:57 CST 2015
      Full restore complete of datafile 3 /u01/app/oracle/oradata/test/sysaux01.dbf.  Elapsed time: 0:01:47
        checkpoint is 3142189
        last deallocation scn is 3099893
      Wed Feb 04 11:27:32 CST 2015
      Full restore complete of datafile 1 /u01/app/oracle/oradata/test/system01.dbf.  Elapsed time: 0:02:20
        checkpoint is 3142189
        last deallocation scn is 3101877
      Wed Feb 04 11:27:39 CST 2015
      alter database recover datafile list clear
      Wed Feb 04 11:27:39 CST 2015
      Completed: alter database recover datafile list clear
      Wed Feb 04 11:27:39 CST 2015
      alter database recover datafile list
       1 , 2 , 3 , 4 , 5 , 6 , 7
      Completed: alter database recover datafile list
       1 , 2 , 3 , 4 , 5 , 6 , 7
      Wed Feb 04 11:27:39 CST 2015
      alter database recover if needed
       start until change 3142264
      Media Recovery Start
      Wed Feb 04 11:27:40 CST 2015
      Recovery of Online Redo Log: Thread 1 Group 3 Seq 3 Reading mem 0
        Mem# 0: /u01/app/oracle/oradata/test/redo03.log
      Wed Feb 04 11:27:40 CST 2015
      Recovery of Online Redo Log: Thread 1 Group 1 Seq 4 Reading mem 0
        Mem# 0: /u01/app/oracle/oradata/test/redo01.log
      Wed Feb 04 11:27:40 CST 2015
      Incomplete Recovery applied until change 3142277
      Wed Feb 04 11:27:40 CST 2015
      Media Recovery Complete (test)
      Completed: alter database recover if needed
       start until change 3142264

      从上面的恢复过程可以看到,首先从备份中还原数据文件,各个数据文件的checkpoint scn是3142189比我们的恢复目标SCN小,然后应用重做日志文件将数据库恢复到目标SCN所对应的时间点。

      set until还可以使用时间表达式,还原点或者日志序列事情作为它的恢复目标时间点
      set until time '2015-02-04 11:22:29';
      set until sequence 4;
      set until restore point before_delete;

      如果按时间点恢复成功。可以以只读方式打开数据库来检查表emp的数据是否恢复回来了。如果表emp的记录没有恢复回来,可能我们选错了恢复目标SCN。在这种情况下,可以使用新的恢复目标SCN然后重新执行按时间点恢复。

      RMAN> sql 'alter database open read only';
      
      sql statement: alter database open read only
      
      SQL> select * from emp;
      
           EMPNO ENAME      JOB              MGR HIREDATE            SAL       COMM     DEPTNO
      ---------- ---------- --------- ---------- ------------ ---------- ---------- ----------
            7369 SMITH      CLERK           7902 17-DEC-80           800                    20
            7499 ALLEN      SALESMAN        7698 20-FEB-81          1600        300         30
            7521 WARD       SALESMAN        7698 22-FEB-81          1250        500         30
            7566 JONES      MANAGER         7839 02-APR-81          2975                    20
            7654 MARTIN     SALESMAN        7698 28-SEP-81          1250       1400         30
            7698 BLAKE      MANAGER         7839 01-MAY-81          2850                    30
            7782 CLARK      MANAGER         7839 09-JUN-81          2450                    10
            7788 SCOTT      ANALYST         7566 19-APR-87          3000                    20
            7839 KING       PRESIDENT            17-NOV-81          5000                    10
            7844 TURNER     SALESMAN        7698 08-SEP-81          1500          0         30
            7876 ADAMS      CLERK           7788 23-MAY-87          1100                    20
            7900 JAMES      CLERK           7698 03-DEC-81           950                    30
            7902 FORD       ANALYST         7566 03-DEC-81          3000                    20
            7934 MILLER     CLERK           7782 23-JAN-82          1300                    10
      
      14 rows selected.

      从上面的结果可知表emp的记录通过按时间点恢复已经找回来了。

      如果按时间点恢复经过验证后达到了恢复目标,可以有如下选择:
      1.使用oracle导出工具将恢复的表emp进行逻辑导出。然后将数据库恢复到当前时间点后,再导入导出的数据。这样在不会丢失数据库的其它改变而又恢复了表emp的数据。

      2.以读写方式打开数据库,这样在恢复目标SCN之后的所有改变将会丢失。当前的联机重做日志文件会被归档,日志序列号会被设置为1,并且所有的联机重做日志会被指定新的时间戳和SCN。

      RMAN> alter database open resetlogs;
      
      database opened

      使用ancestor incarnation执行按时间点恢复
      使用ancestor incarnation执行按时间点恢复与使用current incarnation的不同之处在于需要设置数据库的incarnation.并且必须从包含恢复目标SCN的incarnation中还原控制文件。

      不使用recover catalog的情况
      比如我们要将数据库恢复到scott用户的emp表被删除之后的时间点,对older incarnation执行按时间点恢复的过程如下:

      1.判断要使用的incarnation。可以使用list incarnation命令来找到恢复目标时间所对应的incarnation

      RMAN> list incarnation;
      
      
      List of Database Incarnations
      DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
      ------- ------- -------- ---------------- --- ---------- ----------
      1       1       TEST     2155613261       PARENT  1          2005-06-30 19:09:40
      2       2       TEST     2155613261       PARENT  446075     2014-09-05 09:13:52
      3       3       TEST     2155613261       PARENT  2849317    2015-01-27 15:10:02
      4       4       TEST     2155613261       PARENT  2880152    2015-01-27 23:41:06
      5       5       TEST     2155613261       PARENT  3017109    2015-02-01 19:31:28
      6       6       TEST     2155613261       PARENT  3041066    2015-02-01 23:05:57
      7       7       TEST     2155613261       PARENT  3041350    2015-02-01 23:23:21
      8       8       TEST     2155613261       ORPHAN  3111834    2015-02-03 19:57:34
      9       9       TEST     2155613261       ORPHAN  3111834    2015-02-03 20:26:09
      11      11      TEST     2155613261       PARENT  3114664    2015-02-03 21:25:34
      10      10      TEST     2155613261       ORPHAN  3114665    2015-02-03 20:34:43
      12      12      TEST     2155613261       PARENT  3142278    2015-02-04 11:40:02
      13      13      TEST     2155613261       PARENT  3144077    2015-02-04 13:09:03
      14      14      TEST     2155613261       CURRENT 3144537    2015-02-04 13:32:41

      当前的incarnation的Inc Key为14.通过下面的查询可以找到它之前的incarnation的Inc Key为13:

      SQL> select prior_incarnation# from v$database_incarnation where status ='CURRENT';
      
      PRIOR_INCARNATION#
      ------------------
                      13

      2.将数据库启动到mount状态

      RMAN> startup  mount
      
      Oracle instance started
      database mounted
      
      Total System Global Area     327155712 bytes
      
      Fixed Size                     1273516 bytes
      Variable Size                138412372 bytes
      Database Buffers             184549376 bytes
      Redo Buffers                   2920448 bytes

      3.将数据库test的incarnation设置为incarnation号为13,也就是current incarnation的parent incarnation。

      RMAN> reset database to incarnation 13;
      
      database reset to incarnation 13

      4.执行还原与恢复,设置恢复目标时间,如果没有配置相关通道设置通道。将数据库恢复到表emp删除之后的时间点(2015-02-04 13:30:01):

      RMAN> run
      2> {
      3> set until time '2015-02-04 13:30:01';
      4> restore database;
      5> recover database;
      6> }
      
      executing command: SET until clause
      
      Starting restore at 2015-02-04 13:54:37
      using channel ORA_DISK_1
      
      channel ORA_DISK_1: starting datafile backupset restore
      channel ORA_DISK_1: specifying datafile(s) to restore from backup set
      restoring datafile 00001 to /u01/app/oracle/oradata/test/system01.dbf
      restoring datafile 00002 to /u01/app/oracle/oradata/test/undotbs01.dbf
      restoring datafile 00003 to /u01/app/oracle/oradata/test/sysaux01.dbf
      restoring datafile 00004 to /u01/app/oracle/oradata/test/users01.dbf
      restoring datafile 00005 to /u01/app/oracle/oradata/test/example01.dbf
      restoring datafile 00006 to /u01/app/oracle/oradata/test/test01.dbf
      restoring datafile 00007 to /u01/app/oracle/oradata/test/testbak.dbf
      channel ORA_DISK_1: reading from backup piece /u02/test_df870779983_s135_s1
      channel ORA_DISK_1: restored backup piece 1
      piece handle=/u02/test_df870779983_s135_s1 tag=TAG20150204T111943
      channel ORA_DISK_1: restore complete, elapsed time: 00:02:37
      Finished restore at 2015-02-04 13:57:14
      
      Starting recover at 2015-02-04 13:57:14
      using channel ORA_DISK_1
      
      starting media recovery
      
      archive log thread 1 sequence 3 is already on disk as file /u02/1_3_870729934.dbf
      archive log thread 1 sequence 4 is already on disk as file /u02/1_4_870729934.dbf
      archive log thread 1 sequence 1 is already on disk as file /u02/1_1_870781202.dbf
      archive log filename=/u02/1_3_870729934.dbf thread=1 sequence=3
      archive log filename=/u02/1_4_870729934.dbf thread=1 sequence=4
      archive log filename=/u02/1_1_870781202.dbf thread=1 sequence=1
      archive log filename=/u02/1_1_870786543.dbf thread=1 sequence=1
      media recovery complete, elapsed time: 00:00:03
      Finished recover at 2015-02-04 13:57:18
      
      RMAN> alter database open resetlogs;
      
      database opened
      
      
      RMAN> list incarnation;
      
      
      List of Database Incarnations
      DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
      ------- ------- -------- ---------------- --- ---------- ----------
      1       1       TEST     2155613261       PARENT  1          2005-06-30 19:09:40
      2       2       TEST     2155613261       PARENT  446075     2014-09-05 09:13:52
      3       3       TEST     2155613261       PARENT  2849317    2015-01-27 15:10:02
      4       4       TEST     2155613261       PARENT  2880152    2015-01-27 23:41:06
      5       5       TEST     2155613261       PARENT  3017109    2015-02-01 19:31:28
      6       6       TEST     2155613261       PARENT  3041066    2015-02-01 23:05:57
      7       7       TEST     2155613261       PARENT  3041350    2015-02-01 23:23:21
      8       8       TEST     2155613261       ORPHAN  3111834    2015-02-03 19:57:34
      9       9       TEST     2155613261       ORPHAN  3111834    2015-02-03 20:26:09
      11      11      TEST     2155613261       PARENT  3114664    2015-02-03 21:25:34
      10      10      TEST     2155613261       ORPHAN  3114665    2015-02-03 20:34:43
      12      12      TEST     2155613261       PARENT  3142278    2015-02-04 11:40:02
      13      13      TEST     2155613261       PARENT  3144077    2015-02-04 13:09:03
      14      14      TEST     2155613261       ORPHAN  3144537    2015-02-04 13:32:41
      15      15      TEST     2155613261       CURRENT 3144674    2015-02-04 13:58:43

      使用recover catalog的情况
      比如我们要将数据库恢复到scott用户的emp表被删除之后的时间点,对older incarnation执行按时间点恢复的过程如下:

      1.判断要使用的incarnation。可以使用list incarnation命令来找到恢复目标时间所对应的incarnation

      RMAN> list incarnation;
      
      
      List of Database Incarnations
      DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
      ------- ------- -------- ---------------- --- ---------- ----------
      1       8       TEST     2168949517       PARENT  1          2010-04-19 10:22:46
      1       2       TEST     2168949517       PARENT  383537     2015-02-04 17:44:49
      1       102     TEST     2168949517       PARENT  415176     2015-02-04 18:22:16
      1       188     TEST     2168949517       CURRENT 415481     2015-02-04 18:33:17

      当前的incarnation的Inc Key为188.通过下面的查询可以找到它之前的incarnation的Inc Key为102:我们将数据库恢复到2015-02-04 18:22:30,也就是在SCN:415176和SCN:415481之间。

      RMAN> list backup of controlfile;
      
      
      List of Backup Sets
      ===================
      
      BS Key  Type LV Size       Device Type Elapsed Time Completion Time
      ------- ---- -- ---------- ----------- ------------ -------------------
      75      Full    6.80M      DISK        00:00:01     2015-02-04 18:11:38
              BP Key: 77   Status: AVAILABLE  Compressed: NO  Tag: TAG20150204T181137
              Piece Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870804697_bf3w2t62_.bkp
        Control File Included: Ckp SCN: 415111       Ckp time: 2015-02-04 18:11:37
      
      BS Key  Type LV Size       Device Type Elapsed Time Completion Time
      ------- ---- -- ---------- ----------- ------------ -------------------
      139     Full    6.80M      DISK        00:00:02     2015-02-04 18:22:45
              BP Key: 144   Status: AVAILABLE  Compressed: NO  Tag: TAG20150204T182243
              Piece Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870805363_bf3wqnyv_.bkp
        Control File Included: Ckp SCN: 415288       Ckp time: 2015-02-04 18:22:43
      
      BS Key  Type LV Size       Device Type Elapsed Time Completion Time
      ------- ---- -- ---------- ----------- ------------ -------------------
      236     Full    6.80M      DISK        00:00:03     2015-02-04 18:33:39
              BP Key: 242   Status: AVAILABLE  Compressed: NO  Tag: TAG20150204T183336
              Piece Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870806016_bf3xd2wl_.bkp
        Control File Included: Ckp SCN: 415765       Ckp time: 2015-02-04 18:33:36

      从上面的控制文件备份信息可以看到要恢复到2015-02-04 18:22:30这个时间点应该使用控制文件备份是o1_mf_s_870805363_bf3wqnyv_.bkp

      2.将数据库强制启动到nomount状态

      RMAN> startup force nomount
      
      Oracle instance started
      
      Total System Global Area     327155712 bytes
      
      Fixed Size                     1273516 bytes
      Variable Size                138412372 bytes
      Database Buffers             184549376 bytes
      Redo Buffers                   2920448 bytes

      3.将数据库test的incarnation设置为incarnation号为102,也就是current incarnation的parent incarnation。

      RMAN> reset database to incarnation 102;
      
      database reset to incarnation 102
      
      RMAN> list incarnation;
      
      
      List of Database Incarnations
      DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
      ------- ------- -------- ---------------- --- ---------- ----------
      1       8       TEST     2168949517       PARENT  1          2010-04-19 10:22:46
      1       2       TEST     2168949517       PARENT  383537     2015-02-04 17:44:49
      1       102     TEST     2168949517       CURRENT 415176     2015-02-04 18:22:16
      1       188     TEST     2168949517       ORPHAN  415481     2015-02-04 18:33:17

      4.执行还原与恢复,设置恢复目标时间,如果没有配置相关通道设置通道。还原控制文件,将数据库恢复到表emp删除之后的时间点(2015-02-04 18:22:30):

      RMAN> restore controlfile;
      
      Starting restore at 2015-02-04 18:44:23
      allocated channel: ORA_DISK_1
      channel ORA_DISK_1: sid=156 devtype=DISK
      
      channel ORA_DISK_1: starting datafile backupset restore
      channel ORA_DISK_1: restoring control file
      channel ORA_DISK_1: reading from backup piece /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870805363_bf3wqnyv_.bkp
      channel ORA_DISK_1: restored backup piece 1
      piece handle=/u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870805363_bf3wqnyv_.bkp tag=TAG20150204T182243
      channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
      output filename=/u01/app/oracle/oradata/test/control01.ctl
      output filename=/u01/app/oracle/oradata/test/control02.ctl
      output filename=/u01/app/oracle/oradata/test/control03.ctl
      Finished restore at 2015-02-04 18:44:29
      
      RMAN> alter database mount;
      
      database mounted
      released channel: ORA_DISK_1
      
      RMAN> restore database until time '2015-02-04 18:22:30';
      
      Starting restore at 2015-02-04 18:47:15
      Starting implicit crosscheck backup at 2015-02-04 18:47:15
      allocated channel: ORA_DISK_1
      channel ORA_DISK_1: sid=156 devtype=DISK
      Crosschecked 4 objects
      Finished implicit crosscheck backup at 2015-02-04 18:47:17
      
      Starting implicit crosscheck copy at 2015-02-04 18:47:17
      using channel ORA_DISK_1
      Finished implicit crosscheck copy at 2015-02-04 18:47:17
      
      searching for all files in the recovery area
      cataloging files...
      cataloging done
      
      List of Cataloged Files
      =======================
      File Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870805363_bf3wqnyv_.bkp
      File Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870806016_bf3xd2wl_.bkp
      
      using channel ORA_DISK_1
      
      channel ORA_DISK_1: starting datafile backupset restore
      channel ORA_DISK_1: specifying datafile(s) to restore from backup set
      restoring datafile 00001 to /u01/app/oracle/oradata/test/system01.dbf
      restoring datafile 00002 to /u01/app/oracle/oradata/test/undotbs01.dbf
      restoring datafile 00003 to /u01/app/oracle/oradata/test/sysaux01.dbf
      restoring datafile 00004 to /u01/app/oracle/oradata/test/users01.dbf
      restoring datafile 00005 to /u01/app/oracle/oradata/test/example01.dbf
      channel ORA_DISK_1: reading from backup piece /u01/app/oracle/flash_recovery_area/TEST/backupset/2015_02_04/o1_mf_nnndf_TAG20150204T181037_bf3w0y1f_.bkp
      channel ORA_DISK_1: restored backup piece 1
      piece handle=/u01/app/oracle/flash_recovery_area/TEST/backupset/2015_02_04/o1_mf_nnndf_TAG20150204T181037_bf3w0y1f_.bkp tag=TAG20150204T181037
      channel ORA_DISK_1: restore complete, elapsed time: 00:01:15
      Finished restore at 2015-02-04 18:48:32

      将数据文件还原到2015-02-04 18:22:30这个时间点,下面执行恢复,要注意的是在执行恢复操作之前还需要执行reset database to incarnation 102否则会报错:

      RMAN> recover database until time '2015-02-04 18:22:30';
      
      Starting recover at 2015-02-04 18:49:05
      using channel ORA_DISK_1
      RMAN-00571: ===========================================================
      RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
      RMAN-00571: ===========================================================
      RMAN-03002: failure of recover command at 02/04/2015 18:49:05
      RMAN-06004: ORACLE error from recovery catalog database: RMAN-20011: target database incarnation is not current in recovery catalog

      再次执行 reset database to incarnation 102;

      RMAN> reset database to incarnation 102;
      
      database reset to incarnation 102
      
      RMAN> recover database until time '2015-02-04 18:22:30';
      
      Starting recover at 2015-02-04 18:49:21
      using channel ORA_DISK_1
      
      starting media recovery
      
      archive log thread 1 sequence 3 is already on disk as file /u02/1_3_870803089.dbf
      archive log thread 1 sequence 4 is already on disk as file /u02/1_4_870803089.dbf
      archive log thread 1 sequence 1 is already on disk as file /u02/1_1_870805336.dbf
      archive log filename=/u02/1_3_870803089.dbf thread=1 sequence=3
      archive log filename=/u02/1_4_870803089.dbf thread=1 sequence=4
      archive log filename=/u02/1_1_870805336.dbf thread=1 sequence=1
      media recovery complete, elapsed time: 00:00:01
      Finished recover at 2015-02-04 18:49:24
      
      RMAN> alter database open resetlogs;
      
      database opened
      new incarnation of database registered in recovery catalog
      starting full resync of recovery catalog
      full resync complete
      
      RMAN> list incarnation;
      
      
      List of Database Incarnations
      DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
      ------- ------- -------- ---------------- --- ---------- ----------
      1       8       TEST     2168949517       PARENT  1          2010-04-19 10:22:46
      1       2       TEST     2168949517       PARENT  383537     2015-02-04 17:44:49
      1       102     TEST     2168949517       PARENT  415176     2015-02-04 18:22:16
      1       308     TEST     2168949517       CURRENT 415183     2015-02-04 18:49:41
      1       188     TEST     2168949517       ORPHAN  415481     2015-02-04 18:33:17

      可以看到恢复完成之后当前的incarnation对应的reset scn号在415176与415481之间,达到了我们所期待的结果。

      版权声明:本文内容来自第三方投稿或授权转载,原文地址:https://blog.51cto.com/lhrbest/2712752,作者:小麦苗DB宝,版权归原作者所有。本网站转在其作品的目的在于传递更多信息,不拥有版权,亦不承担相应法律责任。如因作品内容、版权等问题需要同本网站联系,请发邮件至ctyunbbs@chinatelecom.cn沟通。

      上一篇:MySQL执行安装“rpm -ivh mysql-community-server-5.7.34-1.el6.i686.rpm“报错“error:Failed dependencies“

      下一篇:Oracle 数据库实例启动关闭过程

      相关文章

      2025-05-19 09:05:01

      项目更新到公网服务器的操作步骤

      项目更新到公网服务器的操作步骤

      2025-05-19 09:05:01
      公网 , 数据库 , 文件 , 更新 , 服务器
      2025-05-19 09:04:53

      Django rest froamwork-ModelSerializer

      Django rest froamwork-ModelSerializer

      2025-05-19 09:04:53
      django , sqlite , 数据库
      2025-05-19 09:04:38

      mysql只有在任务处于完成状态才能运行

      mysql只有在任务处于完成状态才能运行

      2025-05-19 09:04:38
      MySQL , 任务 , 数据库 , 查询 , 状态
      2025-05-19 09:04:30

      设置28401事件后启动数据库时报错ORA-49100

      设置28401事件后启动数据库时报错ORA-49100

      2025-05-19 09:04:30
      ORA , 数据库 , 时报
      2025-05-14 10:03:13

      MySQL 索引优化以及慢查询优化

      MySQL 是一种广泛使用的关系型数据库管理系统,因其性能优异和使用便捷而备受欢迎。然而,随着数据量的增长和查询复杂度的增加,性能瓶颈也变得越来越明显。

      2025-05-14 10:03:13
      MySQL , 优化 , 使用 , 性能 , 数据库 , 查询 , 索引
      2025-05-14 10:03:05

      Oracle数据库用户权限分析

      Oracle数据库用户权限分析

      2025-05-14 10:03:05
      Oracle , 分析 , 数据库 , 权限 , 用户
      2025-05-14 10:02:48

      互斥锁解决redis缓存击穿

      在高并发系统中,Redis 缓存是一种常见的性能优化方式。然而,缓存击穿问题也伴随着高并发访问而来。

      2025-05-14 10:02:48
      Redis , 互斥 , 数据库 , 线程 , 缓存 , 请求
      2025-05-14 10:02:48

      SQL Server 事务日志体系结构1--基本术语

      事务包括对数据库的一次更改或一系列更改。它有一个明确开始和明确结束。开始时使用BEGIN TRANSACTION语句,或者SQL Server会自动为您开始一个事务。

      2025-05-14 10:02:48
      Server , SQL , 事务 , 数据库 , 日志 , 磁盘
      2025-05-14 10:02:48

      SQL Server 账号管理1

      SQL Server 账号管理主要包含登录名、用户、架构、角色等管理。通过对账号的管理可以有效的提高数据库系统的安全性,规范运维及使用。

      2025-05-14 10:02:48
      Server , SQL , 对象 , 数据库 , 权限 , 用户
      2025-05-13 09:51:17

      dblogin登陆数据库时报错ORA-04060

      dblogin登陆数据库时报错ORA-04060

      2025-05-13 09:51:17
      ORA , 数据库 , 时报
      查看更多
      推荐标签

      作者介绍

      天翼云小翼
      天翼云用户

      文章

      33561

      阅读量

      5264534

      查看更多

      最新文章

      Django rest froamwork-ModelSerializer

      2025-05-19 09:04:53

      mysql只有在任务处于完成状态才能运行

      2025-05-19 09:04:38

      设置28401事件后启动数据库时报错ORA-49100

      2025-05-19 09:04:30

      MySQL 索引优化以及慢查询优化

      2025-05-14 10:03:13

      Oracle数据库用户权限分析

      2025-05-14 10:03:05

      SQL Server 账号管理1

      2025-05-14 10:02:48

      查看更多

      热门文章

      Nacos数据持久化到MySQL

      2023-05-12 07:20:56

      MySQL的间隙锁

      2023-05-12 07:20:56

      ​云原生微服务K8s容器编排第七章之ETCD的使用及备份

      2023-03-16 07:45:55

      oracle 数据库 中 如何将不带汉字的日期格式转换成带“年月日时分秒”格式的日期

      2023-04-06 06:11:29

      【Error】kettle连接MySQL

      2023-05-17 06:58:39

      JSP之 MySQL 插入数据时,中文乱码问题的解决

      2022-11-14 02:56:39

      查看更多

      热门标签

      数据库 mysql 字符串 数据结构 MySQL 算法 redis oracle java sql python 数据 索引 SQL 查询
      查看更多

      相关产品

      弹性云主机

      随时自助获取、弹性伸缩的云服务器资源

      天翼云电脑(公众版)

      便捷、安全、高效的云电脑服务

      对象存储

      高品质、低成本的云上存储服务

      云硬盘

      为云上计算资源提供持久性块存储

      查看更多

      随机文章

      oracle学习43-oracle导出空表

      MySQL数据库04——索引

      mysql-innodb-自定义函数-函数参数赋值-记录

      解决Mongodb认证auth error: sasl conversation error: unable to authenticate using mechanism “SCRAM-SHA-1“

      浅析 Redis 事务(三)

      【MySQL】mysqldump备份与恢复

      • 7*24小时售后
      • 无忧退款
      • 免费备案
      • 专家服务
      售前咨询热线
      400-810-9889转1
      关注天翼云
      • 旗舰店
      • 天翼云APP
      • 天翼云微信公众号
      服务与支持
      • 备案中心
      • 售前咨询
      • 智能客服
      • 自助服务
      • 工单管理
      • 客户公告
      • 涉诈举报
      账户管理
      • 管理中心
      • 订单管理
      • 余额管理
      • 发票管理
      • 充值汇款
      • 续费管理
      快速入口
      • 天翼云旗舰店
      • 文档中心
      • 最新活动
      • 免费试用
      • 信任中心
      • 天翼云学堂
      云网生态
      • 甄选商城
      • 渠道合作
      • 云市场合作
      了解天翼云
      • 关于天翼云
      • 天翼云APP
      • 服务案例
      • 新闻资讯
      • 联系我们
      热门产品
      • 云电脑
      • 弹性云主机
      • 云电脑政企版
      • 天翼云手机
      • 云数据库
      • 对象存储
      • 云硬盘
      • Web应用防火墙
      • 服务器安全卫士
      • CDN加速
      热门推荐
      • 云服务备份
      • 边缘安全加速平台
      • 全站加速
      • 安全加速
      • 云服务器
      • 云主机
      • 智能边缘云
      • 应用编排服务
      • 微服务引擎
      • 共享流量包
      更多推荐
      • web应用防火墙
      • 密钥管理
      • 等保咨询
      • 安全专区
      • 应用运维管理
      • 云日志服务
      • 文档数据库服务
      • 云搜索服务
      • 数据湖探索
      • 数据仓库服务
      友情链接
      • 中国电信集团
      • 189邮箱
      • 天翼企业云盘
      • 天翼云盘
      ©2025 天翼云科技有限公司版权所有 增值电信业务经营许可证A2.B1.B2-20090001
      公司地址:北京市东城区青龙胡同甲1号、3号2幢2层205-32室
      • 用户协议
      • 隐私政策
      • 个人信息保护
      • 法律声明
      备案 京公网安备11010802043424号 京ICP备 2021034386号