Yushan Bai-CSDN博客

原创关于我的介绍

关于我：姓白，常被称"白工"、"小白"；就职于国内某知名专业第三方数据库服务厂商，具有多年专职Oracle数据库相关技术支持经验，现居杭州；日常工作涉及对银行、保险、政府、电信、广电、医疗、大型制造业等行业客户提供Oracle技术支持；包括MAA高可用/容灾架构的咨询/规划/实施、基于OWI/SQL等方面的性能调优服务、Oracle数据库跨版本跨平台升级迁移等；持有10g ocm认证。在csd...

2017-05-03 12:47:36 1730 2

原创 Rejected the attempt to advance SCN问题的分析处理

在接到应用厂家的反馈并找到数据库异常关闭的原因后，我发迅速与局方负责人进行沟通，定位到本次故障的原因：应用人员在沃易管的数据库创建了一个新dblink，该dblink是连接总部的数据库，由此导致该库被感染，因该库与本地多个库也存在dblink连接，导致本地多个库被感染。需要使用数据库的厂家或应用人员，应该将自己的使用要求，涉及到的使用内容上报局方，局方与数据库的维护方对该使用要求，涉及内容进行风险评估，在进行合理的评估后，再将结果反馈给各个使用数据库的厂家或应用人员。5.目前，系统已完全恢复，并运行正常。

2024-05-27 16:36:23 516

原创通过集群及数据库日志分析RAC节点重启的案例

======>>>>30s后的16:47:26，Missing answers or immediate escalation，节点2的Member kill request到达阀值时没有应答，==================>>>>>>>实例2被实例1驱逐，在节点1实例的日志中16:41:55 2019 Reconfiguration started。========>>>>>>>16:46:56收到clssgmpProcessRequestMsg: Member kill request请求。

2024-05-22 15:11:43 661

原创 ORACLE 6节点组成的ACFS文件系统异常的分析思路

对于近期两次典型问题分析如下：6/24日中午12点附近出现ACFS文件系统访问异常，通过查看集群ALERT日志、CSSD进程日志及OSW监控软件的日志，可以发现OSW监控软件在11:55-12:40分时没有收集到主机的监控数据，同期数据库的CSSD进程也有与其它节点的私网信息已经丢失网络心跳，因此可以推断当时主机已经HANG住。从具体的问题来看，ORACLE集群软件做为操作系统上层的软件，会受到底层操作系统OS以及更底层的VMWARE虚拟机环境的影响；近期遇到多次6节点集群的ACFS文件系统环境异常问题；

2024-05-22 15:09:05 789

原创通过AWR结合SQLHC对性能变低的SQL进行分析的过程

其次对于此SQL，建议进行优化后再进行SQL执行计划的绑定，保持优化后的SQL执行效率高效、稳定。绑定执行的原理是使SQL在执行时比如访问A1索引再到B1表的这样的过程，但是两个用户下存在索引名称不一致问题，这时在绑定执行计划时就出现了AAA用户下绑定成功，BBB用户在执行时存在无法找到A1索引问题。绑定执行的原理是使SQL在执行时比如访问A1索引再到B1表的这样的过程，但是两个用户下存在索引名称不一致问题，这时在绑定执行计划时就出现了AAA用户下绑定成功，BBB用户在执行时存在无法找到A1索引问题。

2024-05-22 14:52:36 982

原创 oracle oda部署时报错OAK-10029:Fail to validate the correct number of disk partitions处理

近期，在一套ORACLE ODA部署时，安装正常流程进行前期的安装实施后，使用图形界面进行ODA部署时，正常提交部署任务；之后查看后台任务发现在Storage discovery 阶段报错Failure；检查物理连接，ODA存储的线路连接、状态指示灯均正常。处理步骤如下：1、在ODA的计算节点，使用命令查看磁盘状态，odaadmcli show enclosure、odaadmcli show storage存储节点整体状态正常，磁盘状态OFFLINE。如下：存储节点状态：查看存储状态2：2、查

2024-05-21 17:55:07 265

原创 ORACLE 19C RAC单节点环境asmca界面中ACFS菜单不显示问题的处理

近期，在安装一个单节点服务器，使用ORACLE 19C RAC的ASM功能进行磁盘的冗余配置（类似用ASM实现RAID卡的RAID功能），为了兼容低版本的数据库软件（数据库不升级），使用了ASM的ACFS文件系统，来提供一个挂载点目录，运行11G的数据库。重启服务器测试时，发现问题：ACFS的挂载点目录没自动挂载，数据库也就无从启动了。检查ASM的ALERT日志，磁盘组MOUNT后，没有操作 volume 的日志；1、加载ACFS文件模块（已经设置到/etc/rc.local）5、MOUNT挂载点。

2024-05-15 14:58:03 619

原创 ORACLE ODAX9-2的一个误告警Affects: /SYS/MB的分析处理

在运维的多套ORACLE ODAX9-2版本，都遇到了一个计算节点的告警：Description: The service Processor poweron selftest has deteced a problem. Probabity;此告警从描述上来看比较验证，但是事实是主机运行正常，对此告警进行分析认为就误报，ORACLE ODA的硬件管理平台ILOM上提供了清理告警的接口，按如下步骤进行清理后，告警消除，后续持续观察，系统运行正常。具体处理日志如下：（根据告警事件的UUID）

2024-05-11 12:13:33 787

原创 Oracle ODA X9-2心跳网络Mellanox Dual Port SFP28 CX5 25Gb Ethernet Adapter的FIREWARE固件BUG问题处理

考虑为新服务器，硬件损坏概率不高，有没有可能是软件类问题（如兼容性、固件版本等）；安装解决办法，可以升级网卡FIREWARE固件版本，来解决次问题。参照此方式进行处理，后续网卡恢复正常。近期，在实施一套Oracle ODA X9-2一体机时，遇到心跳网络不通的问题，表现的特征为心跳网线（25GB直连）线缆连接后，网卡的指示灯不亮，操作系统中也无法识别网卡状态，更换线缆排查法验证，确定为网卡问题。4、重启服务器，查看网卡硬件及主机系统内查看固件版本，恢复正常。1、无法使用网卡的情况。2、查看网卡固件信息。

2024-05-11 11:48:24 791

原创 ORACLE ODA一体机存储节点电源故障的分析处理

5、检查最终状态（注意次命令的输出，ODA 的2个计算节点的的输出是不一致的，简单说是检测到恢复正常是有时间差的，如节点1显示OK，节点2可能过几分钟才显示OK）对于ODA一体机（2个计算节点+1个存储节点），计算节点可以通过ilom管理界面登陆进行详细的硬件信息查看和管理，当然通过命令行也可以。对于存储节点，是没有图形界面可以看，可以通过ODA管理台（7093/mgmt/index.html）或者命令查看；本次问题查看为存储节点的1个电源故障，由于双电源配置，系统仍然可以正常工作；

2024-05-10 17:54:44 751

原创 ORACLE RAC ASM磁盘组OFFLINE后的处理步骤

对问题进行排查，可以发现问题是存储磁盘出现了IO问题后OFFLINE，从而导致磁盘组也OFFLINE。由于系统是备机，发现时已经过去了较长时间，多余NORMAL冗余（或者双活的存储配置）来说，超过REPAIR TIME的断开需要在加回ASM磁盘组时重新同步。3、检查当前的ASM磁盘情况（注意此命令是动态查看磁盘，如果磁盘现在丢失不显示，就不体现在输出，也就是看到的盘的数量，和正常运行时可能不一样，需要注意。6、查看磁盘并MOUNT磁盘组（此时可以看到全部ASM需要用的磁盘）2、尝试MOUNT磁盘组的报错。

2024-05-10 17:36:50 986

原创 ORACLE 19C RAC DIAG进程消耗大量内存的分析

问题分析：通过对DIAG进程TRACE分析，结合在ORACLE官方后台进行问题、BUG查询匹配，该进程占用内存的现象不是持续增大，而是突然增大。目前分析是心跳网络不稳定时DIAG进程产生大量TRACE时的内存泄漏，导致DIAG进程占用很多内存（mos:Database Ora_dia0_* Process Consumes High Memory Utilization (文档 ID 2787583.1),此问题一般为私网的性能较差导致）。2、分析DIAG进程的TRACE日志，大量的IPCLW开头的日志。

2024-05-08 16:09:10 1333

原创 oracle数据库升级过程中执行catupgrd.sql遇到ORA-01722: invalid number问题的处理

近期，在进行一个WINDOWS环境的oracle 11.2.0.1版本数据库迁移到LINUX环境的oracle 11.2.0.4版本并升级时，因为需要从oracle 11.2.0.1版本升级到oracle 11.2.0.4版本，使用手动运行catupgrd.sql脚本，此时报错：分析原因，为该数据库实例配置了Oracle Database Vault功能；需要关闭Oracle Database Vault功能后，重新执行升级操作。

2024-05-08 15:52:42 877

原创向表内INSERT数据出现ORA-00600 ktspgfb-inc2错误的分析处理

根据报错信息，查询一通，互联网上基本没信息，MOS文档（如Doc ID 10371288.8）勉强找到一些资料，结合报错信息分析，基本确定是表的段头管理出现了问题（ORA-600 [ktspgsb-inc] can occur using ASSM segments if the segment header block's inc# is not updated, while the inc# in L2 BMB has bumped up. 段头的分析可以参考N年前的文章。此时可以正常查询表中数据。

2024-04-25 17:43:35 312

原创 oracle 19c数据库W00n进程使用很多PGA内存资源的分析

今天，客户反馈测试环境的数据库PGA资源不足，报错ORA-04036: 实例使用的 PGA 内存超出 PGA_AGGREGATE_LIMIT；查看总的PGA分布：select sum(pga_alloc_mem)/(1024*1024) "Mbytes allocated", sum(pga_used_mem)/(1024*1024) "Mbytes used" from v$process;1、民间办法：KILL进程、或者定期重启数据库。查找占用内存多的进程：使用SQL；

2024-04-16 17:13:09 985

原创 ORACLE RAC集群CRSD服务异常后无需重启集群的处理方法

/crsctl start res ora.crsd -init)，不影响集群其它资源，数据库等均持续正常运行。3.集群日志排查发现OCR不能读导致CRSD资源异常；具体为5/26号12:19分时候asm日志显示OCR仲裁盘有问题，13:23分出现读写错误。监控软件连不上TEST集群节点1，发现监听中不存在IP 1.80.检查巡检数据发现5/18日正常。1.根据监控软件报错时间排查，监听日志无异常，监听状态中不存在IP 1.80物理IP。排查发现为CRSD服务异常，其它集群资源正常，所以数据库没有宕机。

2024-04-11 10:17:52 391

原创 ORACLE 19C版本PGA使用率告警问题分析处理

近期，某客户数据库告警平台经常发出告警“告警名称: PGA超限使用”，需要进行分析处理。在ORACLE 11G时代，PGA基本可以任务是不受参数限制的，因此对于老DBA来说，PGA参数随便设置的情况是存在的。因此，对于这个19C环境的告警，需要进行分析。最终判断，数据库进程数量稳定，PGA使用量稳定，偶尔的使用率偏高，最终调大PGA_AGGREGATE_LIMIT值来避免告警。3、查看数据库进程数量，使用PGA量大的进程信息。1、查看数据库进程数量，使用PGA量大的进程信息。4、查看PGA的历史使用量。

2024-04-11 10:10:25 714

原创 oracle切换ADG后JVM组件查询报错ORA-29516处理

此时，我们将X86 LINUX架构服务器上JAVA版本更新为一致的非OPENJDK版本的JAVA:java version "1.8.0_241"，使变量生效，之后重启数据库，仍然未能解决问题。结合实际情况分析对比，EXADATA上的JAVA版本为：java version "1.8.0_241"；DBCA在监控过程充安装组件会用到本地的一些环境、变量，而X86架构的LINUX环境存在一些差异导致无法正常运行JAVA组件；前面的人工安装JAVA来实现X86架构的LINUX环境一致的方式已经验证不可行；

2024-03-25 16:43:27 387

原创 ORACLE RAC反应卡顿时enq: SV - contention和latch: row cache objects的分析

2、从基本信息来看，出现了很多异常等待数据，如典型的enq: SV - contention 、enq: TX - row lock contention、enq: SQ - contention、cursor: pin S wait on X、latch: row cache objects、enq: US - contention；4、看起来问题比较清楚，大量回滚端请求，查看对应UNDO表空间使用率，可以发现UNDO表空间使用率高，查看UNDO段状态，大量在UNEEXPIRED状态；

2024-03-06 16:52:04 825

原创 Oracle Exadata的SCAN监听程序异常重启问题分析

1、在这个Oracle Exadata环境，有多个数据库，未有人反馈问题，初步判断大部分系统是正常的。停止程序后，监听日志查看正常不再有高频连接，此后SCAN监听未发生过重启，系统恢复正常。2、SCAN监听问题，用了2、3个数据库的SERVICE_NAME去连，都有问题，判断为SCAN监听问题，不是个别数据库问题。常规思路下，遇到次问题，有一系列的排查、排除方向，去定位和处理问题。3、根据有问题的IP，找软件维护人员查看，关闭对应程序后，系统恢复。3、用VIP进行连接，连接、查询均正常。

2024-02-29 14:21:58 512

原创 12.2RAC环境从RAC转为单机模式的问题处理

一开始只是将数据库软件通过make -f ins_rdbms.mk rac_off 和 make -f ins_rdbms.mk ioracle关闭RAC模式；然后在启动数据库（sqlplus / as sysdba登录后startup时报错：ORA-00600: internal error code, arguments: [kgfz_getDiskAccessMode:ntyp], [0], [], [], [], [], [], [], [], [], [], []2.启动数据库实例时的报错。

2023-09-08 19:12:00 437

原创一次存储盘异常引起的ASM磁盘OFFLINE处理

4.尝试重新MOUNT磁盘组，以及修复OCR（NORMAL冗余）磁盘组中OFFLINE后超过REPAIR时间的DROP状态磁盘。2.检查操作系统的日志（linux /var/opt/message），确定出现了存储盘的IO报错（事后分析为链路问题）登陆系统查看，数据库实例异常关闭，日志指向ASM DISKGROUP异常；1.检查集群状态、ASM实例状态，发现ASM磁盘组已经DISMOUNT；3.目前检查测试，磁盘已经恢复；2.MOUNT 磁盘组报错的解决。3.处理DROP状态的ASM磁盘。

2023-07-26 16:38:24 893

原创 kernel.shmall 参数导致的Oracle数据库无法启动问题分析与测试

Oracle不再把sga放到共享段中，pmap工具诠释了进程相关共享内存的情况，可以看到许多个4MB的＂文件＂(此处的大小可能不是4M，可能是16M等)对应了Oracle服务进程的空间地址．这是linux上POSIX风格的共享内存管理模式，使用＂文件＂形式包含共享内存段．借助于将sga分割成许多块，Oracle可以很容易地把sga部分内存返回给OS，而服务器进程即可以利用到这些内存．（当memory_max_target>1024时，颗粒为16MB,否则为4MB)．。修改完成后 sysctl -p。

2023-05-31 23:49:33 1114

原创 oracle19c版本会导致数据库实例crash的bug32653669

近期，某客户的数据库系统出现运行时突然宕机，查看数据库后台alert日志，无明显的ORA-00600或ORA-07445等错误；深入分析后，问题原因为存放业务数据的表空间使用满后，业务数据的表使用了LOB字段，触发了BUG：Bug 32653669 - ORA-1652 ON GEN0 CRASHED INSTANCE，导致数据库实例宕机。分析此BUG的出发条件：1.表空间使用满 2.使用LOB字段(严格来说是securefile lob，11G后默认此种类型)。检查GEN0进程的TRACE文件，对。

2023-05-26 13:43:51 566

原创 oracle WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK问题分析

程在等待latch: row cache objects资源，根据故障时ALERT日志中systemstate dump prod2_ora_3191.trc信息来看，以典型的LCK0进程为例，此进程在等待和kghfrunp(释放shared pool中内存)有关的latch,此进程的历史等待事件中也大量存在'latch: shared pool'、latch: row cache objects；这2个参数是立即生效的，在所有的节点上设置这2个参数之后，系统不再进行DRM。具体值应结合历史AWR报告中。

2023-05-25 10:03:35 1047

原创 oracle数据库主机CPU使用率高问题的分析及SQL优化

因此建议改写SQL，使用绑定变量。对TOP SQL的SQL文本进行分析，这些SQL的文本事实上一致，因未使用绑定变量，只在一些WHERE条件中不同；对TOP SQL的SQL文本进行分析，这些SQL的文本基本一致，只在一些WHERE条件中不同；当前的应急解决方案是针对出现问题的SQL，进行相应的索引创建，从而降低逻辑读(逻辑读会消耗CPU资源)，提高SQL执行效率，缓解当前CPU使用率高的问题。对TOP SQL的SQL文本进行分析，这些SQL的文本事实上一致，因未使用绑定变量，只在一些WHERE条件中不同；

2023-05-23 12:00:20 2995 3

原创 oracle数据库大量产生trace文件导致空间不足问题原因的分析

运维人员发现备份出现问题，通过查看数据库日志及主机运行信息，发现遇到大量ORA-00060死锁报错，产生大量TRACE文件，导致ORACLE软件目录空间资源耗尽；通过数据库参数MAX_DUMP_FILE_SIZE限制单个TRACE文件的上限值，一定程序上会减少TRACE文件占用的空间，但是无法限制TRACE文件的个数。同时限制单个TRACE文件的上限值后，例如限制为10M，当问题进程对应的TRACE文件达到10M时，后续的TRACE信息无法写入TRACE文件；可以发现产生死锁进程涉及的SQL语句为。

2023-05-23 11:54:30 2377

原创 ORA-600 [17112]错误导致的数据库实例crash分析

客户的一套老系统，AIX环境的oracle 8i(8.1.7.4)版本，出现数据库宕机。分析ALERT日志，报错信息为ORA-00600: internal error code, arguments: [17112], [875767708]；从告警日志中，我们可以确认到数据库实例中断是由于 PMON 进程中报 ORA-600 [17112] 所导致的。然而，Oracle DB 8.1.7.4 上没有补丁修复，建议您将数据库升级到 Oracle DB 11.2.0.4 来进行对应。

2023-05-23 11:42:46 419

原创一次oracle环境 enq: TX - allocate ITL entry锁问题分析

默认情况下创建的表ITL槽数最小为1,pctfree为10，那么如果是这样一种情况，如果表中经常执行update语句，然后块中剩余的10%空间所剩无几，而且业务的并发量还很大，此时就很容易遇到enq: TX - allocate ITL entry等待。每当一个事务需要修改一个数据块时，需要在数据块头部获得一个可用的ITL槽，其中记录了当前事务的id，使用的undo数据块，还有对应的scn，事务是否提交等信息。此处遇到的问题即是ITL上发生的死锁，SQL同时对一个块进行操作时，对I。

2023-05-21 22:05:29 802

原创 ORACLE 12.2.0.1版本的BUG30403763 修复过程

参考MOS文档： ORA-600 [qkexrXCopn1] -OR- ORA-7445 [qerhnprobeinner] -OR- Other Internal Errors Followed By Instance Crash due to Memory Corruption (Doc ID 2899072.1)。BUG：30403763会导致数据库实例的宕机，本次用户就遇到了此问题并出现多次数据库实例宕机。参照ORACLE的解决方案，进行BUG对应的DBRU补丁包安装修复后，数据库运行正常。

2023-05-21 21:55:14 424

原创 ORA-07445 [qerhnFetch()+590] 及ORA-00600 [qkexrXCopn1]引起的数据库crash问题分析

应用程序出现报错显示为 ORA-01034 ORACLE not available，程序无法正常使用。接到数据库故障通知后，通过远程方式接入数据库环境进行故障排查，通过对相关日志等信息的深入分析，最终找到问题点并进行处理，数据库恢复正常，根据当时的问题处理情况整理汇总此文档。经过对数据库相关日志分析，数据库出现的故障和2023-05-10出现故障一致，问题SQL的执行计划没有改变，SQL无法进行优化的情况下，只能安装补丁解决BUG：30403763。

2023-05-21 21:50:43 294

原创 enq: TM - contention等待事件引起的数据库卡顿分析

因此结合ORACLE官方文档中（High 'enq: TM - contention' Wait Event Causing Session Hangs in an Oracle Streams Environment (Doc ID 740728.1)），对于OGG附加日志时执行的语句：BEGIN DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(table_name => '"AA"."BB"', supplemental_logging => 'none');

2023-05-21 21:40:14 830

原创中国南方ORACLE用户组会议：Oracle 19c 升级及关键特性的最佳实践

如何在灾难场景下实现零数据丢失的快速恢复是长久以来困扰Oracle DBA的问题，Oracle 19c的新特性有效解决了这一难题，显著提升了Oracle数据库稳定性，极致接近实现RTO

2023-05-21 21:32:58 151

原创 ORACLE 10G版本数据库系统产生大量归档日志问题的分析

ORACLE 11Gr2开始，数据库AWR中的segment部分的block change小节，可以显示块变更多的表或索引信息，依据此信息结合TOP SQL部分，可以很快速的确定导致产生很多归档日志的SQL语句、程序模块信息等。，当日采样人员过多，超过上限导致程序混乱，产生大量update，导致归档暴增，应用采取加模组方式暂时解决，后续修改采样编码上限。导致，正常的SQL在出现异常执行时，也会产生问题，出现大量的归档，应该对SQL执行次数进行监控，出现异常执行次数时，立即处理。秒取样时间内，sql。

2023-05-09 16:43:39 2804

原创一次业务系统无法使用对应的oracle数据库性能分析过程

(主机名WIN2008R2180409)连接到数据库的进程，有严重的TX行锁(enq: TX - row lock contention)等待，对应的SQL语句是SQL_ID:10y4yb0924b1p，SQL_TEXT: UPDATE GY_BINGRENXX SET NIANLINGDW = :B2 WHERE BINGRENID = :B1；排查，通过对相关日志等信息的深入分析，找出问题点并提出相应的解决建议，根据相关问题日志及分析处理情况整理汇总此文档。上午8-10点时有此SQL执行的记录。

2023-05-09 16:28:33 677

原创一次典型的ORA-04031问题的处理

2.检查数据库alert日志，发现后台日志不停报错ORA-04031: 无法分配 ORA-04031: 无法分配 4160 字节的共享内存 ("shared pool","unknown object","sga heap(1,0)","modification ")6.调整内存SGA参数，增大shared_pool_size=2048m scope=spfile，重启生效后解决问题。4.临时flush shared_pool，无法根本性解决问题。字节的共享内存 ("","","","")

2023-04-28 12:05:09 3390

原创 RAC集群节点2异常时节点1的database实例无法提供服务问题的分析

直到节点1完成了重配，节点1恢复正常。，持续到13:45:45分，节点1检查到节点2异常，开始进行实例的Reconfiguration，13:45:51时完成，系统即恢复正常。数据库alert日志显示，13:42:40秒开始出现LGWR进程无响应80秒，推算13:41:20秒出现问题，持续到13:45:45分，节点1检查到节点2异常，开始进行实例的Reconfiguration，13:45:51时完成，系统即恢复正常。3.在此期间，由于节点2异常，大量程序的进程都连接到节点1，加剧了节点一的性能问题。

2023-04-26 17:19:32 1045

非IMU模式下一条update语句产生REDO RECORD条数的探究--日志打包

实例恢复相关TRACE文件

LINUX 64位ORACLE 11G安装BBED所需文件

LINUX 32位ORACLE 11G安装BBED所需文件

VBOX+OEL5.7+ORACLE11G+RAC安装

XP 超级终端

空空如也