转:ORA-600(kole_t2u)错误

文章记录了一次Oracle 10203 RAC环境中遇到的ORA-600内部错误,该错误由特定SQL语句触发并影响了MMON进程。文中详细介绍了错误发生的情景,并给出了通过Metalink查询到的解决方案,包括受影响的具体版本及修复补丁。

 

 

转杨兄的bug帖子:http://space.itpub.net/4227/viewspace-69265

才将系统升级到10203 RAC环境,就碰到了Oraclebug

alert文件中看到了ORA-600错误。


Rl6qf NJ9P12778571

详细错误信息如下:

ksedmp: internal or fatal errorITPUB个人空间K%D"~!a1lUO6Y
ORA-00600: internal error code, arguments: [kole_t2u], [34], [], [], [], [], [], []
h9a;kU"yG#XL12778571Current SQL statement for this session:
&uK yV$?h4S7K/y12778571INSERT INTO wrh$_sqltext (sql_id, dbid, sql_text, command_type, snap_id, ref_count) SELECT sqlid_kewrstx, :dbid, sqlfulltext_kewrstx, cmdtype_kewrstx, :lah_snap_id, 0 ref_count FROM x$kewrtsqltext

通过metalink查询,发现很多个和这个问题类似的bug,可惜这些问题都没有明确问题的产生原因。一些和当前问题类似的情况,被认为是重复的bug,可是BASE BUG却指向一个似乎和当前问题没有关系的bug

总之Oracle没有给出一个汇总的描述,同时也没有说明这个bug fixed的版本。

好在这个问题对用户的影响不大,只是会导致后台的MMON启动的SLAVE进程失败。

 

今天又在后台发现了这个错误,不过不是相同的SQL造成的,错误SQL如下:

ORA-00600: internal error code, arguments: [kole_t2u], [34], [], [], [], [], [], []
_)O&e?:v_7V12778571Current SQL statement for this session:ITPUB个人空间c!a+Q/Ode'j4X
 SELECT vst.sql_id, vst.sql_fulltext FROM  V$SQLSTATS vst  WHERE  vst.sql_id IN (:1,:2,:3,:4,:5,:6,:7,:8,:9,:10)    AND  vst.plan_ha
K2mb,nE8n*o12778571sh_value = :phv
"}d7n;ND&Y$u[ \12778571----- PL/SQL Call Stack -----
/q/k.k%Z%YtM12778571  object      line  objectITPUB个人空间IJpU2x1CqFt
  handle    number  name
2U1N5v%fr J*W%V1?:a127785713d3832ee0        10  package body SYS.PRVT_HDM
z3HN9[1J{0_127785713d331a4b0        16  SYS.WRI$_ADV_HDM_T
X[Ep'Ql]K127785713d2ea1f60      1535  package body SYS.PRVT_ADVISORITPUB个人空间]v8Q^9J(o'l
3d2ea1f60      1618  package body SYS.PRVT_ADVISORITPUB个人空间!LN!b%n'[ u+D!w
3d3832ee0       106  package body SYS.PRVT_HDMITPUB个人空间'O5DE.P5L]
485496948         1  anonymous block

再次查询metalink,发现Oracle终于更新了这个bug的描述,在文档Doc ID: Note:553528.1中,Oracle详细描述了这个bug:当使用多字节字符集时,视图V$SQLAREASQL_FULLTEXT列或V$SQLSQL_FULLTEXT列包含了不正确的SQL语句,从而导致问题的产生,而一般引发这个问题都是后台的MMON进程,也就是说,几个常见的bugBug 5970258Bug 6066506Bug 6367143等等都是这个问题所引起的。

Oracle10.2.0.411.1.0.6fix这个bug,或者可以选择单独的补丁Patch 5017909来解决这个问题。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12778571/viewspace-510043/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/12778571/viewspace-510043/

<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]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值