ORA-27300: OS system dependent operation:semget failed with status: 28 - 2

本文介绍了解决Linux环境下Oracle数据库启动时遇到ORA-27300错误的方法。该错误通常与系统可用信号量资源不足有关。文章详细分析了信号量配置与使用情况,并提供了解决方案,包括调整内核参数SEMMNI。
Database Startup Fails with ORA-27300: OS system dependent operation:semget failed with status: 28 (文档 ID 949468.1)  

Oracle Database - Enterprise Edition - Version 10.1.0.2 to 11.2.0.2 [Release 10.1 to 11.2]
Information in this document applies to any platform.

SYMPTOMS
On a linux server, when an additional database instance is brought up, getting errors: 
SQL> startup nomount 
ORA-27154: post/wait create failed 
ORA-27300: OS system dependent operation:semget failed with status: 28 
ORA-27301: OS failure message: No space left on device 
ORA-27302: failure occurred at: sskgpcreates

CHANGES
An additional database has been created on a linux server. 
PROCESSES parameter in init.ora set to the correct value, accordingly. 
Linux Kernel Parameter for Semaphore - Total 32000 semaphore are available in the system but still gets an error - ORA-27300. 
$ ipcs -ls 

------ Semaphore Limits -------- 
max number of arrays = 128 
max semaphores per array = 250 
max semaphores system wide = 32000 
max ops per semop call = 100 
semaphore max value = 32767

CAUSE
In theory, 32000 semaphores are available in the system and one semaphore identifier can accommodate a maximum of 250 semaphores with 
the configuration above. 
But ipcs command shows each semaphore identifier accomodates maximum of 156 semaphores by Oracle. 

$ ipcs << For this case, it has around 100 semaphore identifiers being used without bringing up the additional instance. 
.. 

------ Semaphore Arrays -------- 
key semid owner perms nsems 
0x450e15bd 0 root 666 1 
0x0000cace 32769 root 666 1 
0x358b172c 327683 oracle 660 104 
0x9053d038 11075588 oracle 660 156 
0x9053d039 11108357 oracle 660 156 
0x9053d03a 11141126 oracle 660 156 
0x9053d03b 11173895 oracle 660 156 
.. 
According to this figure, the maximum available semaphores in this server will be 156 x 128 = 19968, not 32000.

SOLUTION
SEMMNI should be increased to accomodate more semaphores. 

1. Query the current semaphore values in the kernel 
     # /sbin/sysctl -a | grep sem

2. Modify SEMMNI value in the /etc/sysctl.conf. 
From 
kernel.sem = 250 32000 100 128 
To 
kernel.sem = 250 32000 100 200

3. # /sbin/sysctl -p

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

转载于:http://blog.itpub.net/35489/viewspace-1827034/

<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、付费专栏及课程。

余额充值