zoukankan      html  css  js  c++  java
  • Oracle RMAN-06023 和ORA-19693错误

    在将一个0级备份的数据库还原到其它机器上时,首先遇到了RMAN-06023然后遇到ORA-19693错误,错误发生的环境和内容大致如下:
    数据库版本:

    SQL> select * from v$version;
    BANNER
    --------------------------------------------------------------------------------
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
    PL/SQL Release 11.2.0.1.0 - Production
    CORE    11.2.0.1.0      Production
    TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
    NLSRTL Version 11.2.0.1.0 - Production
    

     开始还原数据库: 

    startup nomount;
    RMAN> restore controlfile from 'I:ackupC-2711934557-20150401-02_NSOA_CONTROLFILE_20150401';
    启动 restore2015-04-10 15:09:01
    使用目标数据库控制文件替代恢复目录
    分配的通道: ORA_DISK_1
    通道 ORA_DISK_1: SID=129 设备类型=DISK
    
    通道 ORA_DISK_1: 正在还原控制文件
    通道 ORA_DISK_1: 还原完成, 用时: 00:00:08
    输出文件名=I:NSOADPCONTROL01.CTL
    完成 restore2015-04-10 15:09:10
    
    RMAN> alter database mount;
    RMAN>run
    {
    allocate channel dev type disk;
    allocate channel dev1 type disk;
    set newname for datafile 1 to 'd:
    soadpSYSTEM01.DBF';
    set newname for datafile 2 to 'd:
    soadpSYSAUX01.DBF';
    set newname for datafile 4 to 'd:
    soadpUSERS01.DBF';
    ……………
    restore database;
    switch datafile all;
    recover database;
    release channel dev;
    release channel dev1;
    }
    正在执行命令: SET NEWNAME
    
    正在执行命令: SET NEWNAME
    ………
    启动 restore2015-04-10 15:30:19
    通道 dev: 正在开始还原数据文件备份集
    通道 dev: 正在指定从备份集还原的数据文件
    RMAN-06026: 有些目标没有找到 - 终止还原
    RMAN-06023: 没有找到数据文件4的副本来还原
    RMAN-06023: 没有找到数据文件2的副本来还原
    RMAN-06023: 没有找到数据文件1的副本来还原

     但实际在0级备份中是包含这些数据文件的:

    RMAN> list backup of datafile 4,2,1;
    备份集列表
    ===================
    BS 关键字  类型 LV 大小       设备类型 经过时间 完成时间
    ------- ---- -- ---------- ----------- ------------ -------------------
    10071   Incr 0  30.29G     DISK        02:46:53     2015-04-01 13:29:12
            BP 关键字: 10071   状态: AVAILABLE  已压缩: YES  标记: NSOA_BACKUP_INCR0
    段名:I:BACKUPB_NSOA_10193_UHQ39J0B_20150401
      备份集 10071 中的数据文件列表
      文件 LV 类型 Ckp SCN    Ckp 时间            名称
      ---- -- ---- ---------- ------------------- ----
      4    0  Incr 13625590769939 2015-04-01 10:42:20 G:U09ORADATANSOAUSERS01.DBF
    
    BS 关键字  类型 LV 大小       设备类型 经过时间 完成时间
    ------- ---- -- ---------- ----------- ------------ -------------------
    10072   Incr 0  29.04G     DISK        02:47:11     2015-04-01 13:29:30
            BP 关键字: 10072   状态: AVAILABLE  已压缩: YES  标记: NSOA_BACKUP_INCR0
    段名:I:BACKUPB_NSOA_10192_UGQ39J0B_20150401
      备份集 10072 中的数据文件列表
      文件 LV 类型 Ckp SCN    Ckp 时间            名称
      ---- -- ---- ---------- ------------------- ----
      1    0  Incr 13625590769907 2015-04-01 10:42:19 G:U07ORADATANSOASYSTEM01.DBF
      2    0  Incr 13625590769907 2015-04-01 10:42:19 G:U08ORADATANSOASYSAUX01.DBF

     因此可以确定,备份文件本身是没有问题的,问题出在

    If we start a RESTORE database with a BACKUP controlfile and Flash Recovery Area is defined, RMAN execute and implicit crosscheck and catalog of all the objects in the Flash Recovery Area.
    RMAN will catalog any objects in the Flash Recovery Area that will not be registered in the controlfile and if any of this files belongs to an incarnation different from CURRENT incarnation in the controlfile then changes controlfile CURRENT incarnation to the one found in the file that is being cataloged.
    This prevents database from restoring backups that belong to old CURRENT incarnation
    RMAN considers backup availble for being restored if the backup incarnation and CURRENT incarnation in controlfile are the same.

    根据文档说明,我设置了db_recovery_file_destdb_recovery_file_dest_size参数并重新还原了控制文件,然后在还原时将catalog 指向我的备份文件所在目录:

    RMAN> restore controlfile from 'I:ackupC-2711934557-20150401-02_NSOA_CONTROLFILE_20150401';
    RMAN> alter database mount;
    RMAN> catalog start with 'I:ackup';
    
    启动 implicit crosscheck backup2015-04-10 15:09:40
    分配的通道: ORA_DISK_1
    通道 ORA_DISK_1: SID=129 设备类型=DISK
    已交叉检验的 29 对象
    完成 implicit crosscheck backup2015-04-10 15:10:37
    
    启动 implicit crosscheck copy 于 2015-04-10 15:10:37
    使用通道 ORA_DISK_1
    完成 implicit crosscheck copy 于 2015-04-10 15:10:37
    
    搜索恢复区中的所有文件
    正在编制文件目录...
    没有为文件编制目录
    
    搜索与样式 I:backup 匹配的所有文件
    
    数据库未知文件的列表
    =====================================
    文件名: I:backupARC_NSOA_10197_ULQ3A10I_20150401
    文件名: I:backupARC_NSOA_10198_UMQ3A10I_20150401
    ………
    是否确实要将上述文件列入目录 (输入 YES 或 NO)? yes
    正在编制文件目录...
    目录编制完毕

    目录编制完毕后我验证了还原, RMAN-06023 错误不在报了,但出现了另一个隐含的错误: 

    RMAN> restore database preview;
    
    启动 restore2015-04-10 15:45:41
    使用通道 ORA_DISK_1
    备份集列表
    ===================
    BS 关键字  类型 LV 大小
    ------- ---- -- ----------
    10072   Incr 0  29.04G
      备份集 10072 中的数据文件列表
      文件 LV 类型 Ckp SCN    Ckp 时间            名称
      ---- -- ---- ---------- ------------------- ----
      1    0  Incr 13625590769907 2015-04-01 10:42:19 G:U07ORADATANSOASYSTEM01.DBF
      2    0  Incr 13625590769907 2015-04-01 10:42:19 G:U08ORADATANSOASYSAUX01.DBF
      11   0  Incr 13625590769907 2015-04-01 10:42:19 G:U13ORADATANSOAFRDC_TABLESPACE.DBF
      15   0  Incr 13625590769907 2015-04-01 10:42:19 G:U10ORADATANSOATBS_ZG.DBF
    ………
    介质恢复启动 SCN 是 13625590769793
    恢复范围必须超出 SCN 13625591441474 才能清除数据文件模糊性
    完成 restore2015-04-10 15:46:27

     我当时并没有意识到什么错误,所以我便开始了还原,但不幸ORA-19693来了:

    RMAN>run
    {
    allocate channel dev type disk;
    allocate channel dev1 type disk;
    set newname for datafile 1 to 'd:
    soadpSYSTEM01.DBF';
    set newname for datafile 2 to 'd:
    soadpSYSAUX01.DBF';
    set newname for datafile 4 to 'd:
    soadpUSERS01.DBF';
    ……………
    restore database;
    switch datafile all;
    recover database;
    release channel dev;
    release channel dev1;
    }
    正在执行命令: SET NEWNAME
    
    正在执行命令: SET NEWNAME
    ………
    通道 dev: 将数据文件 00004 还原到  d:
    soadpUSERS01.DBF
    释放的通道: dev
    释放的通道: dev1
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: restore 命令 (在 04/10/2015 15:51:10 上) 失败
    ORA-19693: 已包括备份片段 I:BACKUPB_NSOA_10193_UHQ39J0B_20150401
    ORA-19693: backup piece string already included
    Cause: This backup piece was already specified for inclusion in the restore conversation. A restore conversation may process only a single instance of a backup piece.
    Action: Remove the specified duplicate backup piece in restore steps and restart the conversation.
    我顿时迷惑了,好端端的0级备份怎么就会有duplicate backup,so 我用list 查看了备份:
    RMAN> list backup;
      BS 关键字  类型 LV 大小
      ------- ---- -- ----------
      10071   Incr 0  30.29G
      备份集 10071 中的数据文件列表
      文件 LV 类型 Ckp SCN    Ckp 时间            名称
      ---- -- ---- ---------- ------------------- ----
      4    0  Incr 13625590769939 2015-04-01 10:42:20 G:U09ORADATANSOAUSERS01.DBF
    
    备份集 副本号 1 属于备份集 10071
      设备类型 经过时间 完成时间            压缩标记
      ----------- ------------ ------------------- ---------- ---
      DISK        02:46:53     2015-04-01 13:29:12 YES        NSOA_BACKUP_INCR0
    
        备份集 10071 副本号 1的备份片段列表
        BP 关键字  Pc# 状态      段名称
        ------- --- ----------- ----------
        10071   1   AVAILABLE   I:BACKUPB_NSOA_10193_UHQ39J0B_20150401
    
      备份集 副本号 2 属于备份集 10071
      设备类型 经过时间 完成时间            压缩标记
      ----------- ------------ ------------------- ---------- ---
      DISK        02:46:53     2015-04-10 18:00:58 YES        NSOA_BACKUP_INCR0
    
        备份集 10071 副本号 2的备份片段列表
        BP 关键字  Pc# 状态      段名称
        ------- --- ----------- ----------
        10123   1   AVAILABLE   I:BACKUPB_NSOA_10193_UHQ39J0B_20150401
    
      备份集 副本号 3 属于备份集 10071
      设备类型 经过时间 完成时间            压缩标记
      ----------- ------------ ------------------- ---------- ---
      DISK        02:46:53     2015-04-10 18:17:41 YES        NSOA_BACKUP_INCR0
    
        备份集 10071 副本号 3的备份片段列表
        BP 关键字  Pc# 状态      段名称
        ------- --- ----------- ----------
        10152   1   AVAILABLE   I:BACKUPB_NSOA_10193_UHQ39J0B_20150401

    What is backup piece?
     A backup set contains one or more binary files in an RMAN-specific format. This file is known as a backup piece. A backup set can contain multiple datafiles. For example, you can back up ten datafiles into a single backup set consisting of a single backup piece. In this case, RMAN creates one backup piece as output. The backup set contains only this backup piece.

     接着使用change 命令uncatalog 重复的piece: 

    RMAN> change backuppiece 'I:BACKUPB_NSOA_10193_UHQ39J0B_20150401' uncatalog;
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: uncatalog 命令 (在 04/10/2015 15:52:48 上) 失败
    RMAN-20261: 含糊的备份片段句柄
    RMAN-06092: 查找备份片段时出错
    
    RMAN> change backuppiece 10123 uncatalog;
    未将备份片段列入目录
    备份片段句柄=I:BACKUPB_NSOA_10193_UHQ39J0B_20150401 RECID=10123 STAMP=876669065
    未分类的 1 对象
    
    RMAN> change backuppiece 10152 uncatalog;
    未将备份片段列入目录
    备份片段句柄=I:BACKUPB_NSOA_10193_UHQ39J0B_20150401 RECID=10152 STAMP=876670068
    未分类的 1 对象

     Uncatalog 后还原正常了,但我有些糊涂了,便想起了备份通道的问题,也就有了如下的猜测,面对大的库,备份分配多个通道执行并行备份不是显著提高备份效率吗?为什么我的备份会产生duplicate pieces,是否和多通道有关系?以下是我的备份脚本:

    run{
        allocate channel dev type disk;
        allocate channel dev1 type disk;
        allocate channel dev2 type disk;
        backup incremental level 0  database
        format 'I:BackUpPRACTICEdb_%d_%s_%p_%T'
        tag 'WHOLE_INCL0';
        release channel dev;
        release channel dev1;
        release channel dev2;
    }

     欢迎知情人士指导,谢谢!

    --The end (2015-04-10)

  • 相关阅读:
    unityshader(属性)
    unity_实用小技巧(相机跟随两个主角移动)
    unity_实用小技巧(空指针错误)
    unity_实用小技巧(避免游戏对象被销毁时声音消失)
    php把网络图片转Base64编码。(php将图片链接直接转化为base64编码)
    TP5.0 where数组高级查询
    使用Guzzle执行HTTP请求
    JWT实战:使用axios+PHP实现登录认证
    有关JWT(Json Web Token)的那些事
    thinkphp5一键清除缓存
  • 原文地址:https://www.cnblogs.com/lanston/p/4415386.html
Copyright © 2011-2022 走看看