ORA-02019的处理(转载于kasaur的个人空间http://space.itpub.net/25618347)

本文记录了一次处理Oracle数据库中ORA-02019错误的经历,通过分析告警日志和trace文件,定位问题为RECOVER进程在尝试恢复一个事务时找不到正确的远程数据库连接描述。最终通过查询DBA_2PC_PENDING视图并执行purge_lost_db_entry过程解决了问题。

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

今天早上过来,查看测试库的告警日志发现,一直不断的报错:ORA-02019,具体如下:

alert输出如下:

Errors in file /oracle/admin/UAT/bdump/uat_reco_16233.trc:
ORA-02019: connection description for remote database not found
Mon Feb 13 10:18:46 CST 2012
Errors in file /oracle/admin/UAT/bdump/uat_reco_16233.trc:
ORA-02019: connection description for remote database not found
Mon Feb 13 10:19:34 CST 2012
Errors in file /oracle/admin/UAT/bdump/uat_reco_16233.trc:
ORA-02019: connection description for remote database not found
Mon Feb 13 10:20:47 CST 2012
Errors in file /oracle/admin/UAT/bdump/uat_reco_16233.trc:
ORA-02019: connection description for remote database not found
Mon Feb 13 10:22:35 CST 2012
Errors in file /oracle/admin/UAT/bdump/uat_reco_16233.trc:
ORA-02019: connection description for remote database not found
Mon Feb 13 10:25:17 CST 2012
Errors in file /oracle/admin/UAT/bdump/uat_reco_16233.trc:
ORA-02019: connection description for remote database not found

对应的trace文件内容如下:

[oracle@testdb ~]$ more /oracle/admin/UAT/bdump/uat_reco_16233.trc
/oracle/admin/UAT/bdump/uat_reco_16233.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/product/10.2.0/db_1
System name:    Linux
Node name:      testdb
Release:        2.6.18-128.el5
Version:        #1 SMP Wed Dec 17 11:41:38 EST 2008
Machine:        x86_64
Instance name: UAT
Redo thread mounted by this instance: 1
Oracle process number: 5
Unix process pid: 16233, image:oracle@testdb(RECO)

*** SERVICE NAME:(SYS$BACKGROUND) 2012-02-13 10:18:13.429
*** SESSION ID:(1096.3) 2012-02-13 10:18:13.429
*** 2012-02-13 10:18:13.429
ERROR, tran=7.27.49932, session#=1, se=0:
ORA-02019: connection description for remote database not found
*** 2012-02-13 10:18:46.453
初步判断以为是db-link问题,到数据库里查询,并没有这个db-link,仔细观察trace文件可以发现,这是个oracle的后台进程(RECOVER进程),会话ID是1096,进一步观察不难发现,应该是oracle的RECOVER进程要恢复一个transaction,其事务号:7.27.49932,而需要被恢复的数据库连接名不正确,只要数据库开启状态,该进程就会一直尝试进行恢复,所以alert中会不断的出现该错误,最后查询metalink,有如下解释:

When a failure occurs during commit processing, automatic recovery will

consistently resolve the results at all sites involved in the

transaction. However, if the remote database is destroyed or

recreated before recovery completes, then the entries used to

control recovery in DBA_2PC_PENDING and associated tables will never

be removed, and recovery will periodically retry. Procedure

purge_lost_db_entry allows removal of such transactions from the local site.

查询对应视图发现:

SELECT LOCAL_TRAN_ID,global_tran_id,STATE, MIXED,to_char(FAIL_TIME,'yyyy-mm-dd hh24:mi:ss')FAIL_TIME,
        to_char(RETRY_TIME,'yyyy-mm-dd hh24:mi:ss')Retry_Time
FROM DBA_2PC_PENDING;

7.27.49932 UAT.bb70863a.7.27.49932 collecting no 2011-09-29 18:23:40 2012-02-13 10:58:13

有问题的db-link 就是上面红色部分,该事务第1次失败时间是:2011-09-29 18:23:40

最近的尝试时间是:2012-02-13 10:58:13

此问题不影响测试数据库的正常运行,可以忽略。

如需要解决,不再报错,可以强制移掉此事务来解决。方法如下:

execute sys.dbms_transaction.purge_lost_db_entry('<local_tran_id>');

执行完上面的语句后再观察alert,这个错误终于消失了。

[oracle@testdb ~]$ tail -f /oracle/admin/UAT/bdump/alert_UAT.log
ORA-02019: connection description for remote database not found
Mon Feb 13 10:47:29 CST 2012
Thread 1 advanced to log sequence 9006 (LGWR switch)
  Current log# 3 seq# 9006 mem# 0: /oracle/oradata/UAT/redo03.log
Mon Feb 13 10:47:37 CST 2012
Thread 1 advanced to log sequence 9007 (LGWR switch)
  Current log# 1 seq# 9007 mem# 0: /oracle/oradata/UAT/redo01.log
Mon Feb 13 10:58:13 CST 2012
Errors in file /oracle/admin/UAT/bdump/uat_reco_16233.trc:
ORA-02019: connection description for remote database not found
Mon Feb 13 11:08:30 CST 2012
ALTER SYSTEM ARCHIVE LOG
Mon Feb 13 11:08:30 CST 2012
Thread 1 advanced to log sequence 9008 (LGWR switch)
  Current log# 5 seq# 9008 mem# 0: /oracle/oradata/UAT/redo05.log
Mon Feb 13 11:09:14 CST 2012
Thread 1 advanced to log sequence 9009 (LGWR switch)
  Current log# 6 seq# 9009 mem# 0: /oracle/oradata/UAT/redo06.log

<think>好的,我现在需要帮助用户解决ORA-12547: TNS:lost contact错误的问题。根据用户提供的引用内容,我需要整理出有效的解决方案。首先,我要回顾用户提供的引用信息,看看有哪些常见原因和解决方法被提到。 从引用中可以看到,用户遇到了在使用Oracle时出现ORA-12547错误,无论是在运行dbca还是使用sqlplus时。引用1和4提到在Oracle 11.2和12cR2中遇到这个问题,引用3提到可能与libaio有关,但用户已经排除了这一点。引用4还提到检查trace文件的位置,但没有生成trc文件,而是找到了其他路径下的日志。这可能暗示需要检查Oracle的日志文件来定位问题。 接下来,我需要归纳可能的原因。根据常见的Oracle错误处理经验,ORA-12547通常与权限问题、环境配置、文件缺失或损坏、Oracle二进制文件权限或安装问题有关。例如,libaio库确实在Oracle安装中是必须的,但引用3的用户已经检查过这一点,可能需要考虑其他权限问题,比如ORACLE_HOME目录的权限是否正确,或者Oracle执行文件(如oracle、tnslsnr)的权限设置是否正确。 用户提供的引用中提到了检查trace文件和日志,这说明需要引导用户查看相关日志来获取更多信息。另外,引用4提到在特定路径下找到了trc文件,这可能说明用户需要检查不同的日志位置,或者安装路径是否正确配置。 可能的解决方案包括: 1. 检查Oracle用户的环境变量,如ORACLE_HOME、ORACLE_SID是否正确设置。 2. 确认Oracle二进制文件的权限是否正确,通常应为6751,并且所有者是oracle用户和dba组。 3. 检查libaio是否安装,虽然引用3的用户已经排除了,但可能需要重新安装或确认版本。 4. 检查/tmp目录的权限,确保Oracle用户可以写入。 5. 验证网络配置,如listener.ora和tnsnames.ora是否正确配置,避免TNS问题。 6. 重新安装Oracle软件,如果之前的步骤无效,可能存在安装不完整的情况。 另外,引用中多次提到sqlplus / as sysdba失败,这可能意味着操作系统认证的问题,需要检查/etc/group中oracle用户的组成员身份是否正确,以及$ORACLE_HOME/bin/oracle文件的权限是否正确。 需要将这些步骤按优先级排序,可能先检查权限和环境变量,因为这些是常见且容易修复的问题。然后逐步深入,检查库文件和日志,最后考虑重新安装。 在整理步骤时,要确保逻辑清晰,用户能够一步步跟随操作。同时,需要提醒用户在修改关键文件前备份,避免操作失误导致更多问题。 最后,生成相关问题,帮助用户深入理解可能相关的其他问题,比如权限管理、环境变量配置、Oracle日志分析等。</think>### ORA-12547: TNS:lost contact 错误解决方案 #### 1. **检查环境变量与权限** - **确认`ORACLE_HOME`路径正确性** 确保环境变量`ORACLE_HOME`指向正确的Oracle安装目录,例如: ```bash echo $ORACLE_HOME # 应为类似/u01/app/oracle/product/11.2.0/db_1 ``` - **验证Oracle二进制文件权限** Oracle执行文件(如`$ORACLE_HOME/bin/oracle`)的权限应为`6751`,且所有者为`oracle`用户和`dba`组: ```bash ls -l $ORACLE_HOME/bin/oracle chmod 6751 $ORACLE_HOME/bin/oracle # 修复权限 chown oracle:dba $ORACLE_HOME/bin/oracle ``` 若权限错误会导致连接丢失[^3][^4]。 #### 2. **检查libaio与系统库依赖** - **安装libaio库** 部分案例因缺少`libaio`导致错误: ```bash sudo apt-get install libaio1 # Debian/Ubuntu sudo yum install libaio # CentOS/RHEL ``` - **验证库文件链接** 检查`$ORACLE_HOME/lib`目录下的库文件是否存在或损坏,例如: ```bash ldd $ORACLE_HOME/bin/oracle # 查看动态链接库状态 ``` #### 3. **检查网络配置与监听服务** - **验证监听器配置** 检查`listener.ora`和`tnsnames.ora`文件是否配置正确,例如监听地址是否为本机IP或`localhost`。 重启监听服务: ```bash lsnrctl stop lsnrctl start ``` - **排查防火墙干扰** 临时关闭防火墙测试是否解决问题: ```bash sudo ufw disable # Ubuntu sudo systemctl stop firewalld # CentOS ``` #### 4. **检查Oracle用户权限** - **确认操作系统认证权限** Oracle用户需属于`dba`组,且`/etc/group`中`dba`组包含`oracle`用户: ```bash groups oracle # 输出应包含dba ``` - **修复/tmp目录权限** Oracle需要写入`/tmp`目录,确保权限为`1777`: ```bash chmod 1777 /tmp ``` #### 5. **分析日志定位问题** - **查看跟踪文件(Trace Files)** 根据引用[4],日志可能位于: ```bash $ORACLE_HOME/rdbms/log/*.trc ``` 或`bdump`目录下的`alert_<SID>.log`文件,检查其中是否包含权限错误或库加载失败信息。 #### 6. **重新安装Oracle软件** 若以上步骤无效,可能是安装不完整或文件损坏,尝试重新安装Oracle并严格遵循官方文档的权限配置要求[^3][^4]。 --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值