Oracle报错及解决(持续更新)

本文汇总了Oracle数据库常见的错误及其解决方法,包括ORA-12505(监听器拒绝连接)、ORA-28001(密码过期)、ORA-00904(无效标识符)、ORU-10027(缓冲区溢出)、ORA-00060(死锁)和ORA-12519(无适当的服务处理器)。对于每个错误,详细解释了报错原因并提供了相应的解决策略,如检查和修改SID、更新密码策略、优化程序设计以及调整数据库连接数等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1. ORA-12505

完整报错:

Listener refused the connection with the following error: ORA-12505, 
TNS:listener does not currently know of SID given in connect descriptor

报错原因:
连接数据库时, 服务名/SID填写错误!
解决方法:
查询自己的真实SID, 修改连接时的SID定义, 重新连接即可 !

2. ORA-28001

完整报错:

[99999][28001] ORA-28001: the password has expired.

报错原因:
密码长时间未修改, 超过密码更新过期策略设置的过期时间
解决方法:
方法一: 使用sysdba 修改密码
方法二: 将密码过期策略中的过期时间设置为永不过期

  1. 查看当前的过期时长 :180天
select * from dba_profiles where profile='DEFAULT' and resource_name='PASSWORD_LIFE_TIME';

expiretime

  1. 修改过期策略
alter profile default limit password_life_time unlimited;
  1. 再次查看过期时长, 现在为永不失效
select * from dba_profiles where profile='DEFAULT' and resource_name='PASSWORD_LIFE_TIME';

unlimited
4. 重新为用户设置密码, 如scott用户

alter user scott identified by tiger

3. ORA-00904

ORA-00904: invalid identifier标识符无效
一般是字段不存在, 或者是字段名写错了 !

4. ORU-10027

ORU-10027: buffer overflow, limit of 1000000 bytes
存储过程中打印输出的字符串过多, 导致内存缓存被占满!

5. ORA-00060

【死锁】ORA-00060: deadlock detected while waiting for resource
死锁存在的两个必要条件,一个是多任务工作的并发,另一个是共享资源的独占性需求。只要一个系统(广义系统)中存在这两个前提,我们就认为可能出现死锁的情况。
死锁描述的是一种状态。当两个或两个以上的任务单元在执行过程中,因为请求资源出现等待,因资源永远不能获得而相互等待的状态。如果没有外力的作用,死锁状态是会一直持续下去。死锁是伴随着多任务、并行操作产生的,在单任务情况下,一个任务单元可以使用并且独占所有资源,不存在资源等待的情况,所以也没有死锁的情况。在进入多任务系统环境下,多个任务之间存在资源共享和独占的需求,才可能出现死锁。
死锁最简单的例子:任务A,B,资源1,2。任务A独占了资源1,任务B独占了资源2。此时,任务A要资源2,向任务B提出请求并等待。任务B要求资源1,并且也等待。AB两者均不释放所占有的资源,就造成了死锁。
Oracle的锁机制是建立在行锁一级,在插入、更新行一级信息的时候,会加入独占锁内容。死锁是数据库经常发生的问题,数据库一般不会无缘无故产生死锁,死锁通常都是由于我们应用程序的设计本身造成的。
解决办法:

-- 方式1: 查询等待任务和提交
select * from dba_waiters;
commit;

-- 方式2: 查询死锁的会话进程,杀死死锁会话
select sid, serial#, username, command, lockwait, osuser from v$session where lockwait is not null;
-- 从查询结果中, 获取sid, 和 serial , 进行拼接, 在下面删除, 如果sid 为, 586, serial 为 19649, 拼接成  '586,19649' 
alter system kill session '586,19649' ;

6. ORA-12519

ORA-12519: TNS:no appropriate service handler found
当前数据库连接数已满,没有可以提供的数据库连接服务。

--当前的连接数 
select count(*) from v$process 
--数据库允许的最大连接数 
select value from v$parameter where name = 'processes' 

解决方案:

  • 1.修改数据库连接数,增加数据库允许连接服务的个数【不推荐】
  • 2.修改程序,降低连接数的使用,如增大切片时的分片数据量的大小。【推荐】

持续更新中…!
欢迎大家留言一起讨论学习!

<think>我们正在处理一个Oracle RAC集群环境中的ORA-00600 [kcratr]错误。根据错误代码,这通常实例恢复(Instance Recovery)过程有关。结合引用内容,我们注意到用户提供的引用中提到了其他ORA-00600错误(如kfmdPriRegRclient04)可能是由于BUG导致,并且给出了在特定版本(19.22)中的几个已知BUG。虽然当前错误参数不同,但同样属于内部错误,因此我们应首先考虑软件BUG的可能性。 此外,引用[2]提到了集群密码文件不一致导致的问题,引用[3]提到了认证协议问题,引用[4]提到了文件属性问题。这些虽然当前错误没有直接关联,但提醒我们在集群环境中需要检查共享资源的一致性和权限。 处理步骤: 1. **收集错误详细信息**: - 检查`alert_<sid>.log`和跟踪文件,确定完整的错误参数。例如:`ORA-00600: internal error code, arguments: [kcratr_1], [2], [3], ...`。这些参数对于诊断至关重要。 -Oracle MOS(My Oracle Support)上根据完整的错误参数和数据库版本(包括补丁级别)搜索已知BUG。 2. **检查控制文件和Redo日志**: - 在RAC环境中,控制文件必须是共享且所有节点一致访问的。确保控制文件位于共享存储(如ASM)中,并且所有节点都能正常访问。 - 使用RMAN验证控制文件的完整性:`RMAN> VALIDATE CURRENT CONTROLFILE;` - 检查Redo日志文件的状态和完整性,确保没有损坏。可以尝试使用`ALTER DATABASE CLEAR LOGFILE GROUP <group#>`来重建损坏的日志组(注意:如果日志组未归档且需要恢复,则不能清除)。 3. **检查实例恢复状态**: - 由于错误发生在实例恢复过程中,检查其他节点是否正常。如果另一个节点正常,尝试从正常节点启动数据库,然后恢复故障节点。 - 如果故障节点无法启动,尝试在单节点模式下启动数据库(使用`CLUSTER_DATABASE=NO`参数),然后进行恢复操作。 4. **考虑软件BUG**: - 根据引用[1]中的思路,在MOS上搜索当前数据库版本(例如19c)中`kcratr`相关的BUG。例如,已知BUG可能存在于特定版本中,需要应用补丁。 - 如果存在相关BUG,按照MOS文档建议应用补丁或升级。 5. **检查集群同步和共享资源**: - 确保OCR、Voting Disk等集群资源状态正常(使用`crsctl check cluster`等命令)。 - 检查ASM磁盘组状态,确保所有文件(数据文件、控制文件、日志文件)都可用且未损坏。 6. **尝试恢复**: - 如果控制文件或数据文件头损坏,可能需要使用备份进行恢复。使用RMAN执行恢复操作。 - 如果无法确定恢复点,可以尝试不完全恢复(基于时间或SCN)。 7. **联系Oracle支持**: - 如果以上步骤无法解决,收集完整的诊断信息(包括alert日志、跟踪文件、RMAN验证结果、集群状态等)并联系Oracle支持。 示例操作(根据情况调整): ```sql -- 尝试在单节点模式下启动(在其中一个节点执行): SQL> startup mount; SQL> alter system set cluster_database=false scope=spfile; SQL> shutdown immediate; SQL> startup mount; -- 尝试恢复 SQL> recover database; -- 如果恢复成功,打开数据库(会重置日志) SQL> alter database open resetlogs; -- 然后重新启用集群模式 SQL> alter system set cluster_database=true scope=spfile; SQL> shutdown immediate; -- 重新以集群模式启动各节点 ``` 注意:`resetlogs`操作会重置日志序列号,必须备份数据库。 ### 相关问题 1. 如何判断Oracle RAC集群中的控制文件是否损坏? 2. 在Oracle 19c中如何应用补丁修复已知的ORA-00600错误? 3. 如何在Oracle RAC环境下执行不完全恢复? 4. 如何收集ORA-00600错误的诊断信息提供给Oracle支持?</think>针对 Oracle RAC 集群环境中出现的 **ORA-00600 [kcratr]** 错误,以下是结合引用内容的系统化解决方案--- ### 一、核心解决步骤 #### 1. **确认错误根源**(关键) - 检查 `alert_<SID>.log` 日志,定位完整错误参数(如 `kcratr_n` 中的 `n` 值) - 示例:若错误为 `ORA-00600 [kfmdPriRegRclient04]`,需验证是否为已知 Bug(引用[1]): ```bash # 查看数据库版本 sqlplus / as sysdba SELECT * FROM v$version; ``` - 若版本为 **19.22**,检查以下 Bug: - Bug 34345080 (`ORA-600 [kfmdpriregrclient04]`) - Bug 35469192 (`Instance Crashes With ORA-600 [kfmdpriregrclient04]`) > 解决方案:应用补丁或升级到修复版本(参考 MOS Doc ID 2795196.1)[^1] #### 2. **检查集群资源一致性** - **密码文件同步问题**(引用[2]): ```bash # 检查所有节点密码文件一致性 ls -l $ORACLE_HOME/dbs/orapw* ``` - 若不一致,重新创建并分发共享密码文件: ```bash orapwd file=orapw<SID> password=<sys_pwd> entries=10 scp orapw<SID> node2:$ORACLE_HOME/dbs/ ``` #### 3. **验证存储层完整性** - **控制文件 Redo 日志**: ```sql -- 检查控制文件状态 SELECT name, status FROM v$controlfile; -- 检查 Redo 日志状态 SELECT group#, status FROM v$log; ``` - 若状态异常,使用 RMAN 修复: ```bash rman target / VALIDATE CHECKLOGICAL DATABASE; ``` #### 4. **修复认证协议问题**(引用[3]) - 修改 `sqlnet.ora` 解决兼容性问题: ```bash # 所有节点执行 echo "SQLNET.ALLOWED_LOGON_VERSION_SERVER=12" >> $ORACLE_HOME/network/admin/sqlnet.ora echo "SQLNET.ALLOWED_LOGON_VERSION_CLIENT=12" >> $ORACLE_HOME/network/admin/sqlnet.ora ``` #### 5. **检查文件权限**(引用[4]) - 验证关键文件属性: ```bash # 检查 oracle 和 grid 用户文件权限 ls -l $ORACLE_HOME/bin/oracle ``` - 权限应为 `6751`(`-rwsr-s--x`),异常时修复: ```bash chmod 6751 $ORACLE_HOME/bin/oracle ``` --- ### 二、高级恢复方案 #### 场景 1:控制文件损坏 ```sql -- 重建控制文件(需提前备份) STARTUP NOMOUNT; CREATE CONTROLFILE REUSE DATABASE "<DB_NAME>" RESETLOGS MAXLOGFILES 16 MAXLOGMEMBERS 3 DATAFILE '<path>/system01.dbf', ... ; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; ``` #### 场景 2:Redo 日志损坏 ```sql -- 清除损坏的日志组 ALTER DATABASE CLEAR LOGFILE GROUP <group#>; ``` #### 场景 3:使用 RMAN 不完全恢复 ```bash rman target / RUN { SET UNTIL SCN <last_good_scn>; -- 从日志获取有效 SCN RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; } ``` --- ### 三、预防措施 1. **定期验证集群配置**: ```bash crsctl check cluster -all ``` 2. **启用 RMAN 验证任务**: ```bash rman target / CONFIGURE VALIDATION DEVICE TYPE DISK PARALLELISM 4; SCHEDULE VALIDATION DATABASE; ``` 3. **补丁管理**: - 定期检查 MOS 关键补丁更新(CPU),尤其针对 ORA-00600 的修复 > ⚠️ 若问题持续,收集以下信息并联系 Oracle 支持: > - `alert_<SID>.log` > - 跟踪文件(`trace/<SID>_ora_*.trc`) > - `crsctl status res -t` 输出 --- ### 相关问题 1. 如何从 Oracle 告警日志中识别 ORA-00600 的具体原因? 2. 在 RAC 环境中如何安全地重建控制文件? 3. 如何验证 Oracle 集群中共享存储(ASM)的完整性? 4. ORA-00600 错误数据库补丁版本的关联性分析方法? 5. 如何配置 Oracle RAC 的自动化日志监控告警? [^1]: Oracle 19C RAC 实例异常崩溃分析 [^2]: 集群密码文件同步问题解决方案 [^3]: 认证协议兼容性配置方法 [^4]: 关键文件权限修复步骤
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

真香IT

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值