- 博客(623)
- 资源 (6)
- 收藏
- 关注
RSS订阅
原创 关于我的介绍
关于我：姓白，常被称"白工"、"小白"；就职于国内某知名专业第三方数据库服务厂商，具有多年专职Oracle数据库相关技术支持经验，现居杭州；日常工作涉及对银行、保险、政府、电信、广电、医疗、大型制造业等行业客户提供Oracle技术支持；包括MAA高可用/容灾架构的咨询/规划/实施、基于OWI/SQL等方面的性能调优服务、Oracle数据库跨版本跨平台升级迁移等；持有10g ocm认证。在csd...
2017-05-03 12:47:36
1774
1
原创 一次奇怪的enq: TX - row lock contention锁问题处理
按正常步骤，查询V$SESSION中BLOCKING_SESSION列不为空的，发现没有进程互相阻塞的情况；当时业务卡顿验证比较紧急，就采用了讲进程全部KILL，同时协调重启应用程序的方式，通过查杀锁反复进行，直至业务人员重启应用后，不再产生新锁。某天上午客户告知数据库库有锁导致数据库卡死，需排查出问题的原因，从根本上解决问题。登录服务器查看系统资源，CPU、内存、I/O均正常；登录数据库查看锁信息。查询导致TX锁的SQL_ID与sql语句。生成杀锁语句并持续杀锁。
2025-04-08 16:25:25
327
原创 ORACLE RAC ASM双存储架构下存储部分LUN异常的处理
对比日志和ASM磁盘状态，可以发现是出现了一些磁盘OFFLINE，结合ASM日志以及操作系统的MESSAGE日志，可以确定是存储当时异常，导致了ASM磁盘被OFFLINE/DROP。后续等待ASM磁盘数据再平衡完成，观察数据库性能正常，即可完成。存储检查和修复问题后，如何将这些磁盘再加回来呢？
2025-03-22 17:44:31
502
原创 EXADATA一体机新建数据库遇到的报错ORA-00603 AND ORA-27515
j近期在一个新的EXADATA环境19.25版本，创建了数据库后，观察到后台ALERT日志中出现有ORA-00603 AND ORA-27515报错，报错信息如下：Errors in file /u01/app/oracle/diag/rdbms/xxxx/xxxx1/trace/xxxx1_ora_9460.trc (incident=1737933) (PDBNAME=CDB$ROOT):ORA-00603: ORACLE server session terminated by fatal erro
2025-03-21 20:45:37
784
原创 ORACLE 19.8版本数据库环境EXPDP导数据的报错处理
在MOS上检查，可以发现这样一个文档：Data Pump Export Fails to Start, Raising 'ORA-31648: Timeout before master process DM00 finished initialization'Error (Doc ID 2677216.1)，各项报错基本匹配；里面的SQL数量很多，实际查看确实这样，但是RAC环境一个节点多一个少，后续提议在少的节点上做了导出，可以正常完成导出。
2025-03-20 10:29:40
351
原创 ORACLE 19.8版本遭遇ORA-600 [kqrHashTableRemove: X lock].宕机的问题分析
按600报错查询MOS文档，很快匹配到BUG: Bug 30417732 - Instance Crash After Hitting ORA-00600 [kqrHashTableRemove: X lock] (Doc ID 30417732.8)客户反馈单机环境的一个数据库半夜突然宕机了，这是一个比较重要的系统；600报错我简单的分为2类，一类不会导致宕机，一类导致宕机，这次的明显比较运气差。当天晚上申请停机窗口，安装了19.25版本补丁后，正常运行了近3个月，目前很稳定。
2025-03-14 18:52:31
555
原创 一次ORACLE 10G数据库REDO LOG损坏报错的解决办法ORA-00354: corrupt redo log block header
仔细一想，REDO损坏但是数据库系统没宕机，仔细分析日志，发现CURRENT状态的日志正常，需要切换日志，而此时发现需要重用的REDOLOG损坏（也未归档）所以报错，相当于没有可用的REDO LOG了；后续此系统还出现过类似问题，数据库运行在虚拟机环境的，综合考虑建议新建服务器做了迁移，目前运行稳定，算是解决了~~心里蓦然一惊，以为REDO损坏，那可是大麻烦了，这个小系统是个很古老的ORACLE 10G，没有有效备份的；远程连接查看，发现报错是显示归档空间满了，以为磁盘空间不足。
2025-03-13 20:31:35
416
原创 ORACLE EBS数据库RELINK方式搭建克隆环境
任何语言所预定义的函数都被定义在那种语言的库文件中，必须编译代码来创建一个二进制格式的文件（对象文件）。这个对象文件然后被连接到 OS 的库文件来创建一个可执行文件。成功的链接应使得所有的函数定义都能被找到，链接从它的组件中生成一个可执行文件。在这个语境中链接（linking）和 relinking 意义相同，可以互换。可执行文件都会从预编译组件中建立起来。
2025-03-11 21:34:07
1184
原创 Exadata环境ORA-00603 AND ORA-27515报错的分析处理
在近期的系统巡检检查中，发现一个最近新安装上线的EXADATA一体机环境的数据库后台ALERT日志中有报错ORA-00603: ORACLE server session terminated by fatal error ORA-27515: inadequate memlock limit or driver settings；初看起来是进程异常关闭，检查发现数据库未宕机，查看TRACE为普通的用户进程而不是数据库后台进程，业务使用正常。
2025-02-17 18:39:53
913
原创 oracle 19c安装DBRU补丁时报错CheckSystemSpace的处理
oracle 19c的补丁目前已经发布到19.26版本了，数据库补丁安装也是数据库运维中的一个常见工作；在实际安装时，发现用OPatch.SKIP_VERIFY_SPACE=true参数可以开始安装，但是安装过程中依然有报错，最终还是需要扩大空间的。查阅文档，是需要22GB以上的可用空间，同时可以用OPatch.SKIP_VERIFY_SPACE=true参数来跳过。查阅文档，是需要22GB以上的可用空间，同时可以用OPatch.SKIP_VERIFY_SPACE=true参数来跳过。
2025-02-14 09:52:21
530
原创 Rejected the attempt to advance SCN问题的分析处理
在接到应用厂家的反馈并找到数据库异常关闭的原因后，我发迅速与局方负责人进行沟通，定位到本次故障的原因：应用人员在沃易管的数据库创建了一个新dblink，该dblink是连接总部的数据库，由此导致该库被感染，因该库与本地多个库也存在dblink连接，导致本地多个库被感染。需要使用数据库的厂家或应用人员，应该将自己的使用要求，涉及到的使用内容上报局方，局方与数据库的维护方对该使用要求，涉及内容进行风险评估，在进行合理的评估后，再将结果反馈给各个使用数据库的厂家或应用人员。5.目前，系统已完全恢复，并运行正常。
2024-05-27 16:36:23
672
原创 通过集群及数据库日志分析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
886
原创 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
939
原创 通过AWR结合SQLHC对性能变低的SQL进行分析的过程
其次对于此SQL，建议进行优化后再进行SQL执行计划的绑定，保持优化后的SQL执行效率高效、稳定。绑定执行的原理是使SQL在执行时比如访问A1索引再到B1表的这样的过程，但是两个用户下存在索引名称不一致问题，这时在绑定执行计划时就出现了AAA用户下绑定成功，BBB用户在执行时存在无法找到A1索引问题。绑定执行的原理是使SQL在执行时比如访问A1索引再到B1表的这样的过程，但是两个用户下存在索引名称不一致问题，这时在绑定执行计划时就出现了AAA用户下绑定成功，BBB用户在执行时存在无法找到A1索引问题。
2024-05-22 14:52:36
1254
原创 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
440
原创 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
856
原创 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
1010
原创 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
1015
原创 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
1194
原创 ORACLE RAC ASM磁盘组OFFLINE后的处理步骤
对问题进行排查，可以发现问题是存储磁盘出现了IO问题后OFFLINE，从而导致磁盘组也OFFLINE。由于系统是备机，发现时已经过去了较长时间，多余NORMAL冗余（或者双活的存储配置）来说，超过REPAIR TIME的断开需要在加回ASM磁盘组时重新同步。3、检查当前的ASM磁盘情况（注意此命令是动态查看磁盘，如果磁盘现在丢失不显示，就不体现在输出，也就是看到的盘的数量，和正常运行时可能不一样，需要注意。6、查看磁盘并MOUNT磁盘组（此时可以看到全部ASM需要用的磁盘）2、尝试MOUNT磁盘组的报错。
2024-05-10 17:36:50
1617
原创 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
1721
原创 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
1026
原创 向表内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
525
原创 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
1714
原创 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
783
原创 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
1576
原创 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
620
原创 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
1094
原创 Oracle Exadata的SCAN监听程序异常重启问题分析
1、在这个Oracle Exadata环境，有多个数据库，未有人反馈问题，初步判断大部分系统是正常的。停止程序后，监听日志查看正常不再有高频连接，此后SCAN监听未发生过重启，系统恢复正常。2、SCAN监听问题，用了2、3个数据库的SERVICE_NAME去连，都有问题，判断为SCAN监听问题，不是个别数据库问题。常规思路下，遇到次问题，有一系列的排查、排除方向，去定位和处理问题。3、根据有问题的IP，找软件维护人员查看，关闭对应程序后，系统恢复。3、用VIP进行连接，连接、查询均正常。
2024-02-29 14:21:58
705
原创 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
670
原创 一次存储盘异常引起的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
1263
原创 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
1314
原创 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
688
原创 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
1217
原创 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
3538
4
原创 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
2822
原创 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
576
原创 一次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
1179
原创 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
570
原创 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
382
非IMU模式下一条update语句产生REDO RECORD条数的探究--日志打包
2014-01-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人