ORA-16191: Primary log shipping client not logged on standby

最新推荐文章于 2021-04-16 07:10:03 发布
原创 最新推荐文章于 2021-04-16 07:10:03 发布 · 2.8k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文介绍了一次解决Oracle数据库Dataguard同步问题的经历。在遇到ORA-16191错误后，通过检查发现主备库之间的密码文件不一致。最终通过同步密码文件解决了同步问题。

早上检查数据库dataguard同步情况的时候，发现归档日志没有传送到备库

检查主库上的报错信息：

select dest_name,error from v$archive_dest;

发现ORA-16191: Primary log shipping client not logged on standby

查看了alert日志，发现报密码文件不一致的信息。

然后想起来主库上修改了sys的密码，但没有将密码文件同步到备库。

将主库上密码文件传送到备库，恢复正常

ORA-16191: Primary log shipping client not logged on standby解决方法
m0_37625564的博客
12-19 2465
Oracle DataGuard主备数据不同步，出现 ORA-16191: Primary log shipping client not logged on standby错误。 SQL> select dest_name,error from v$archive_dest; DEST_NAME ERROR ----------------------------------- ---------------------------------
[Dataguard]ORA-16191: Primary log shipping client not logged on standby问题解决
不忘初心、方得始终
01-20 1464
今天朋友Dataguard备库无法同步主库的问题，大概场景如下： 1.备库startup，日志同步语句执行都没问题，但是备库就是无法同步主库的内容 2.观察了下备库的归档同步情况，发现都是0表示未同步主库数据过来，然后看了下警告日志文件的内容，发现如下问题  client_id='' type='UNKNOWN' level='16'  host_id='testdg' host_ad
Data Guard 奇葩的 ORA-16191: Primary log shipping client not logged on standby 问题
369540808
07-19 378
搞了一个Data Gurad,switchover之后，检查配置情况： SQL> select dest_name,status,error from v$archive_dest where rownum<3; DEST_NAME STATUS ERROR -------------------- --------- -----------------------------...
连接Oracle数据库时报ORA-12541:TNS:无监听程序的图文解决教程
09-10
主要介绍了连接Oracle数据库时报ORA-12541:TNS:无监听程序的图文解决教程,非常不错，具有参考借鉴价值，需要的朋友可以参考下
ORA-01034: ORACLE not available ORA-27101: shared memory realm does not exist 如何解决
Jacky_Chan001的博客
07-30 2276
分析：这个问题主要是ORACLE的闪存和恢复区的文件太大导致起不来造成的 第一步：看oracle服务、监听是否启动 先看oracle的监听和oracle的服务是否都启动了。 启动oracle监听：cmd命令行窗口下，输入lsnrctl start，回车即启动监听 再看oracle服务：计算机-服务-ORACLEserviceXX， 均重启几遍 如果不行，第二步：将数据库重启 输入sq...
ORA-16191: Primary log shipping client not logged on standby---待测
about database article
05-09 1780
因为主库上的密码文件是错误的（名称中多了个d），导致搭建完成之后无法使用导致 ora-01031:insufficient privileges错误 详见：http://blog.youkuaiyun.com/aaaaaaaa2000/article/details/7549901  重建密码文件之后，在主库日志中报： ed May 09 14:53:26 2012 Error 1017 recei
oracle dg 重启 16191,Oracle DG ORA-16191: Primary log shipping client not logged on standby
weixin_28256233的博客
04-16 321
ORA-16191: Primary log shipping client not logged on standby一、客户巡检发现alert日志中有报错alert.log日志Mon Jan 28 07:17:15 2013Error 1017 received logging on to the standby-----------------------------------------...
转 ORA-16191 "Primary log shipping client not logged on standby
weixin_34329187的博客
05-13 191
###sample 0 原因未知： 解决办法，重建密码文件 primary db :alter system set log_archive_dest_state_2=defer sid='*' scope=both; standby db db:su - db ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CA...
ORA-31693: ORA-02354: e ORA-01555:ORA-22924: snapshot
最新发布
10-22
<think>嗯，用户这次询问的是Oracle数据库导出过程中的一系列错误代码解决方案。结合提供的三个引用资料来看，用户遇到的是expdp导出时常见的复合型错误：ORA-31693（表数据卸载失败）实际是结果性报错，核心问题在于ORA-02354（导出过程异常）和ORA-01555（快照过旧），偶尔伴随ORA-22924（快照过旧的特殊形态）。 用户可能正在执行数据库迁移或备份任务，从引用[3]提到的105GB大表导出失败来看，业务规模不小。ta连续遇到多个同类错误，说明不是偶发现象，需要系统化解决。尤其值得注意的是引用[1]和[3]都指向视图/同义词解析问题和大事务回滚段配置不足这两类根源。 深层需求其实是保证数据导出任务的可靠性。用户没有明说但可能隐含的痛点包括：生产环境停机时间有限、数据一致性要求高、以及对Oracle内部机制不熟悉带来的排查困难。 技术层面需要分三层处理： 首先是紧急应对措施，比如针对ORA-01555错误立即扩大UNDO表空间或调整参数，这类方案能在数分钟内生效； 其次要解决结构性问题，比如引用[1]提到的视图导出失败需要重建元数据； 最后是预防性优化，像引用[2][3]都提到的UNDO保留时间调整和大事务拆分策略。 特别要注意引用[3]揭示的陷阱——当导出大表时，如果存在并发DML操作，即使UNDO表空间总量足够，也可能因快照保留时间不足导致失败。这需要综合运用UNDO_RETENTION参数优化和导出时机的选择。 用户提供的错误代码组合很典型，正好构成完整的故障链条：ORA-02354是导出的通用异常包装器，ORA-31693是被跳过对象的报告，真正致命的底层错误是ORA-01555及其变种ORA-22924。这个诊断结论应该明确传达给用户。 </think>以下是针对Oracle数据库错误代码 **ORA-31693、ORA-02354、ORA-01555 和 ORA-22924** 的综合解决方案，结合引用内容和Oracle官方建议整理： --- ### **错误原因分析** 1. **ORA-31693 + ORA-02354** - 通常在`expdp`导出时发生，表示特定表（如 `YKSOFT.T_TEMP_U90915`）因元数据问题无法导出。 - **核心问题**：尝试导出**视图或同义词**（而非实际表），或对象元数据损坏（引用[1][^1]）。 2. **ORA-01555: snapshot too old** - 导出过程中查询的数据版本被覆盖，因UNDO表空间不足或事务保留时间过短（引用[2][^2][^3]）。 - 常见于导出超大表时（如引用[3]中105GB的表）。 3. **ORA-22924: snapshot too old** - 是ORA-01555的衍生错误，通常与LOB字段导出相关（引用[2][^2]）。 --- ### **解决方案步骤** #### **1. 修复元数据问题（针对ORA-31693 + ORA-02354）** ```sql -- 检查对象类型（确认是表/视图/同义词） SELECT object_name, object_type FROM dba_objects WHERE owner='YKSOFT' AND object_name='T_TEMP_U90915'; -- 若为视图/同义词：重建或替换为实体表 CREATE TABLE YKSOFT.T_TEMP_U90915_ACTUAL AS SELECT * FROM T_TEMP_U90915; -- 导出新表替代原对象 ``` #### **2. 解决ORA-01555 / ORA-22924（快照过旧）** - **增大UNDO表空间**： ```sql ALTER TABLESPACE UNDOTBS1 ADD DATAFILE '/path/undotbs02.dbf' SIZE 10G AUTOEXTEND ON; ``` - **延长UNDO保留时间**： ```sql ALTER SYSTEM SET UNDO_RETENTION = 1800; -- 单位：秒（建议≥导出耗时） ``` - **优化导出参数**： ```bash expdp user/pwd DIRECTORY=dpump_dir DUMPFILE=exp.dmp LOGFILE=exp.log FLASHBACK_TIME=SYSTIMESTAMP -- 使用闪回保证一致性 PARALLEL=4 -- 降低并行度减少UNDO压力 ``` #### **3. 分治策略导出大表** - **单独导出失败的表**（避免全局失败）： ```bash expdp user/pwd TABLES=SJTBK.INC_KETTLE_ETL_HIST, SJTBK.ECPS_EASY_LOGOUT DIRECTORY=dpump_dir DUMPFILE=large_tables.dmp ``` - **使用`QUERY`条件分批导出**： ```bash expdp ... QUERY="WHERE ROWNUM<=1000000" -- 分批导出 ``` #### **4. 预防性措施** - **监控UNDO使用**： ```sql SELECT BEGIN_TIME, TUNED_UNDORETENTION FROM V$UNDOSTAT; ``` - **避免导出高峰期操作**：减少并发DML对UNDO的争用。 - **改用物理备份**：对百GB级数据，RMAN比逻辑导出更可靠（引用[2][^2]）。 --- ### **关键要点总结** | 错误码 | 主因 | 解决方案 | |-----------------|-----------------------|-----------------------------| | ORA-31693+02354 | 视图/同义词元数据异常 | 重建对象或导出实体表 | | ORA-01555 | UNDO空间或保留时间不足| 增大UNDO、延长保留时间 | | ORA-22924 | LOB字段导出快照过旧 | 分批导出+优化UNDO参数 | > ⚠️ 若问题持续，检查`alert.log`获取更详细的堆栈信息，并考虑使用Oracle Support收集诊断数据（RDA工具）[^3]。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值