Oracle服务端和客户端版本补丁不一致造成Tuxedo应用程序出core案例

简介: 这是一个CU**系统调用的查询天气预报的Tuxedo服务,Oracle Pro*C程序,连接的是Oracle 10.2.0.4库,出现问题的现象是不定时的产生core,服务down,触发Tuxedo服务的自动重启机制,但一般MAXGEN配置是100,即1天内若重启100次后服务就不会自动重启了,只能人工干预,每次重启后会好一阵,且该服务已经由被同步调用改为异步调用,因此实际业务上影响不大,只是几乎每天都会有自动重启的报警。

这是一个CU**系统调用的查询天气预报的Tuxedo服务,Oracle Pro*C程序,连接的是Oracle 10.2.0.4库,出现问题的现象是不定时的产生core,服务down,触发Tuxedo服务的自动重启机制,但一般MAXGEN配置是100,即1天内若重启100次后服务就不会自动重启了,只能人工干预,每次重启后会好一阵,且该服务已经由被同步调用改为异步调用,因此实际业务上影响不大,只是几乎每天都会有自动重启的报警。

查看产生的core文件,如下是其堆栈信息,
这里写图片描述

根据提示的应用程序行,找到应用生成的中间.c文件,
这里写图片描述
这里写图片描述

这是其中一个core,对应于select sysdate into:sysdate from sys.dual;这条SQL语句,再查看其他core,还有针对于其他一些SQL语句的情况,很随机,单独执行这些SQL均正常。

查下MOS,发现有一篇文章和这很像,Core dump - Access Violation in Client Applications After Upgrade to 9.2.0.8, 10.1.0.5 , 10.2.0.x 11.1 and the client or server is still a prior version (文档 ID 455832.1)。描述信息是:

Existing applications (and new applications) encounter a core dump after a database or client-side patch up to versions 9.2.0.8, 10.1.0.5 or 10.2 is applied. This is because these versions contain a patch for Bug 3396162(not a published bug), a patch which must be applied to both client and server for it to be effective, and when mismatched to a client or server that does not contain the patch, causes a core dump/ Access Violation.

强调如果数据库端或客户端打了patch到9.2.0.8,10.1.0.5或10.2版本,才会碰见这种core。原因是这些版本包含了bug3396162的patch,这个patch需要在客户端和服务端同时应用,一旦出现两端只有一边打了patch,就会可能产生core。

而且有一段说明,这个问题的错误栈并不是每次都会碰见,再次强调只要客户端或服务端只有一边打了这个patch,则就会碰见这个bug。

This issue is intermittent and the error stack is not seen 100% of the time. However, if there is a client / server mismatch where the patch for bug 3396162 has been applied to either client or server, but not to both environments, this bug will be encountered.

如下堆栈信息的描述和上面core的堆栈基本一致,
这里写图片描述

给出的wrokaround,

The client and server versions must both contain the fix for bug 3396162. This patch is automatically included in 9.2.0.8, 10.1.0.5 and 10.2.0.x or higher releases. The fix is to ensure the patch is applied to both client and server environments.

客户端和服务端必须包含3396162这个bug的补丁,这个补丁自动包含于9.2.0.8,10.1.0.5和10.2.0.x或更高版本中。

其他版本可以下载patch:3396162,

There exists some patches for 9.2.0.7, 10.1.0.3 and 10.1.0.4 for some platforms, downloadable as Patch :3396162.

这里写图片描述

再次检查应用程序,发现makefile中使用的Oracle客户端库的版本是9.2.0.7,很符合这篇文章的描述,即客户端应用使用的Oracle版本是9.2.0.7,数据库服务端的版本是10.2.0.4,接着推进一些佐证。

1.和DBA确认9.2.0.7库并未应用这个补丁3396162。
2.测试环境中,让开发人员使用原始9.2.0.7编译的应用程序跑一个一天的持续性测试,发现确实会出现core,而且出现问题的SQL是很随机,和生产环境的现象一致。
3.让开发人员使用9.2.0.8以上的客户端库来重新编译应用程序,再次做持续性测试,发现不会再产生core了。

解决方案
使用9.2.0.8以上的Oracle客户端重新编译应用程序,替换生产环境的二进制文件,重启应用。

总结
C程序出现core dump,跟踪core的信息,往往可以进一步定位问题的出处。

目录
相关文章
|
11月前
|
存储 Oracle 关系型数据库
服务器数据恢复—光纤存储上oracle数据库数据恢复案例
一台光纤服务器存储上有16块FC硬盘,上层部署了Oracle数据库。服务器存储前面板2个硬盘指示灯显示异常,存储映射到linux操作系统上的卷挂载不上,业务中断。 通过storage manager查看存储状态,发现逻辑卷状态失败。再查看物理磁盘状态,发现其中一块盘报告“警告”,硬盘指示灯显示异常的2块盘报告“失败”。 将当前存储的完整日志状态备份下来,解析备份出来的存储日志并获得了关于逻辑卷结构的部分信息。
|
存储 Oracle 关系型数据库
Oracle数据库的应用场景有哪些?
【10月更文挑战第15天】Oracle数据库的应用场景有哪些?
1354 64
|
存储 Oracle 关系型数据库
关系型数据库Oracle应用场景
【7月更文挑战第5天】
696 3
|
12月前
|
存储 Oracle 关系型数据库
oracle数据恢复—oracle数据库执行错误truncate命令的数据恢复案例
oracle数据库误执行truncate命令导致数据丢失是一种常见情况。通常情况下,oracle数据库误操作删除数据只需要通过备份恢复数据即可。也会碰到一些特殊情况,例如数据库备份无法使用或者还原报错等。下面和大家分享一例oracle数据库误执行truncate命令导致数据丢失的数据库数据恢复过程。
|
Oracle 关系型数据库 数据库
【赵渝强老师】Oracle的闪回版本查询
本文介绍了Oracle数据库的闪回版本查询(Flashback Version Query)功能,通过示例详细讲解了其使用方法。闪回版本查询可获取指定时间区间内行的不同版本,利用`versions between`子句实现。文中包含视频讲解,并通过创建测试表、插入数据及执行查询等步骤,演示如何获取历史版本信息和伪列详情,帮助用户深入了解该功能的实际应用。
396 13
|
SQL Oracle 关系型数据库
解决大小写、保留字与特殊字符问题!Oracle双引号在SQL中的特殊应用
在Oracle数据库开发中,双引号的使用是一个重要但易被忽视的细节。本文全面解析了双引号在SQL中的特殊应用场景,包括解决标识符与保留字冲突、强制保留大小写、支持特殊字符和数字开头标识符等。同时提供了最佳实践建议,帮助开发者规避常见错误,提高代码可维护性和效率。
601 6
|
DataWorks Oracle 关系型数据库
DataWorks操作报错合集之尝试从Oracle数据库同步数据到TDSQL的PG版本,并遇到了与RAW字段相关的语法错误,该怎么处理
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
380 0
|
Oracle 关系型数据库 数据库
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。 数据库没有备份,无法通过备份去恢复数据库。用户方联系北亚企安数据恢复中心并提供Oracle_Home目录中的所有文件,急需恢复zxfg用户下的数据。 出现“system01.dbf需要更多的恢复来保持一致性”这个报错的原因可能是控制文件损坏、数据文件损坏,数据文件与控制文件的SCN不一致等。数据库恢复工程师对数据库文件进一步检测、分析后,发现sysaux01.dbf文件损坏,有坏块。 修复并启动数据库后仍然有许多查询报错,export和data pump工具使用报错。从数据库层面无法修复数据库。
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。

热门文章

最新文章

推荐镜像

更多