重庆思庄Oracle、Redhat认证学习论坛

 找回密码
 注册

QQ登录

只需一步,快速开始

搜索
查看: 963|回复: 0
打印 上一主题 下一主题

[Oracle] RMAN Table Recovery Fails With ORA-16000 Error

[复制链接]
跳转到指定楼层
楼主
发表于 2023-6-11 18:03:54 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
SYMPTOMS
Running RMAN Table Recovery in 19.16 version fails with below errors after the automatic auxiliary instance got opened in READ ONLY mode:

RMAN> recover table OWNER.TABLE_NAME until time "to_date('2022-11-01 10:00:00','yyyy-mm-dd hh24:mi:ss')" auxiliary destination '/location' datapump destination '/location';

sql statement: create spfile from memory
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00601: fatal error in recovery manager
RMAN-03004: fatal error during execution of command
RMAN-10039: error encountered while polling for RPC completion on channel clone_default
RMAN-10006: error running SQL statement: select action from gv$session where sid=:1 and serial#=:2 and inst_id=:3
RMAN-10002: Oracle error: ORA-16000: database or pluggable database open for read-only access


CAUSE
During table recovery, RMAN restores SYSTEM, SYSAUX and UNDO tablespaces in an auxiliary instance till the specified point-in-time and then opens the auxiliary instance in READ ONLY mode. After this, the next action is to query the dictionary for the table being recovered. However, as we can see from the log, after the auxiliary instance opened in READ ONLY mode, an internal RMAN select on GV$SESSION failed with ORA-16000.

ORA-16000 for a SELECT query on read only instance is caused by below bug when the sql has a SQL plan baseline associated with it:

Doc ID 34491739.8 Bug 34491739 - sql with sql plan baseline fails with ORA-16000 on physical standby

SOLUTION
Bug 34491739 is fixed in 19.17 Database Release Update (RU). So, we can either apply the one-off patch for this bug on top of existing 19.16 RU or instead update to 19.17 RU to get the fix.

If patching cannot be performed immediately, but you need the table recovery to work, below workaround can be used:

+ Create a parameter file for the automatic auxiliary instance with just one parameter:

$ cat /tmp/init_aux.ora

optimizer_use_sql_plan_baselines=false

+ Run table recovery using above parameter file:

run {
SET AUXILIARY INSTANCE PARAMETER FILE TO '/tmp/init_aux.ora';
recover table OWNER.TABLE_NAME until time "to_date('2022-11-01 10:00:00','yyyy-mm-dd hh24:mi:ss')" auxiliary destination '/location' datapump destination '/location';
}

分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 支持支持 反对反对
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|手机版|小黑屋|重庆思庄Oracle、Redhat认证学习论坛 ( 渝ICP备12004239号-4 )

GMT+8, 2024-6-1 11:10 , Processed in 0.092992 second(s), 20 queries .

重庆思庄学习中心论坛-重庆思庄科技有限公司论坛

© 2001-2020

快速回复 返回顶部 返回列表