还不算晕的专栏

仔细一想，REDO损坏但是数据库系统没宕机，仔细分析日志，发现CURRENT状态的日志正常，需要切换日志，而此时发现需要重用的REDOLOG损坏（也未归档）所以报错，相当于没有可用的REDO LOG了；后续此系统还出现过类似问题，数据库运行在虚拟机环境的，综合考虑建议新建服务器做了迁移，目前运行稳定，算是解决了~~心里蓦然一惊，以为REDO损坏，那可是大麻烦了，这个小系统是个很古老的ORACLE 10G，没有有效备份的；远程连接查看，发现报错是显示归档空间满了，以为磁盘空间不足。

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

======>>>>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请求。

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

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

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

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

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

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

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

根据报错信息，查询一通，互联网上基本没信息，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年前的文章。此时可以正常查询表中数据。

/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服务异常，其它集群资源正常，所以数据库没有宕机。

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

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

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

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

客户的一套老系统，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 来进行对应。

参考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补丁包安装修复后，数据库运行正常。

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

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，无法根本性解决问题。字节的共享内存 ("","","","")

直到节点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，加剧了节点一的性能问题。

通过对相关日志的分析，首先出现的GIPC worker thread non-responsive，GIPC本身是与通讯有关的进程，反复报出一些警告信息，可能说明当时通讯当时可能受到一些影响。通过对相关日志的分析，首先出现的GIPC worker thread non-responsive，GIPC本身是与通讯有关的进程，反复报出一些警告信息，可能说明当时通讯当时可能受到一些影响。节点2 开始关闭的时间是13:41:19，实际完成关闭的时间是13:44:25，再次重启的时间是13:52:40。

按Exadata一体机的冗余设计，单个存储节点重启是不影响集群及数据库运行的，本次存储节点故障却导致了CSSD进程异常、数据库实例 crash宕机，属于较为严重的故障。近期，有客户的Exadata一体机遇到存储节点重启，导致集群状态异常、Database crash。可以发现出现了IO异常，ASM中磁盘数据不一致，之后CKPT进程KILL了数据库实例。1.数据库实例crash宕机时信息分析。

近期，在数据库巡检时，发现某用户的ORACLE 19C RAC数据库系统，后台alert日志出现大量的ORA-00600 [qosdExpStatRead: expcnt mismatch]错误，同时产生了很多的cdmp文件，导致TRACE目录的磁盘空间不足问题。2.设置隐含参数 "_fix_control"='31143146:on' （可以动态设置）。本次使用设置隐含参数方式，设置后报错问题得到解决。

近期，某客户在进行从linux环境ORACLE数据库，将数据导入到WINDOWS环境的ORACLE时，遇到报错，无法导入。根据MOS文档ORA-7445 [kpodpals] During DataPump Import (Doc ID 1096837.1)描述，问题为导出的数据中，存在表的字段有空格的问题（ A no-name column "" is included in the table definition.）2.找到问题表，重新导出，导入。1.排除问题表，重新导入。

UPDATE更新分区表的分区字段，使一条数据发生变化，按分区规划使此行数据需要放在其它分区时，需要打开row movement,才可以继续。示例如下：源端更新语句：SQL> update t1 set id=22 where id=2;1 row updated.SQL> commit;Commit complete.目标端原有分区规则： CREATE TABLE "BYST1"."T1" ( "ID" NUMBER, "NAME" VARCH

近期，一个用户数据库出现无法创建主键约束的情况，分析报错为ORA-00600: [12807]；原因为大量的创建、删除表动作（把表当做临时表用），导致CON$值达到4294967294，之后触发Bug 13781691 ORA-600 [12807] if CON$.CON# very high due to bug 13784384。

巡检发现一个ORACLE 19C环境WRI$_ADV_OBJECTS占用很大空间。在ORACLE 11G时，一般默认会关闭AUTO_SQL_TUNING_PROG、auto_space_advisor_prog这两个自动任务，来避免自动任务执行带来的问题。---参照MOS文档可以先备份数据、TRNCATE后可以数据INSERT回来。

一个客户的老数据库环境ORACLE 8I在重启时出现问题，报ORA_01599，这是以前人工管理回滚段时的问题，即超过了MAX_ROLLBACK_SEGMENTS参数的值，参要改大此参数即可。MOS文档ORA-01599 Error on Startup of Database After Recovery (Doc ID 107415.1)对此有解释：处理方法及原理如下：cause: The number of rollback segments created for this database

近期，某用户的DATAGUARD备机，在只读查询模式，隔一段时间就出现ORA-01555错误。在ADG备机中，ORA-01555错误有几个相关的BUG，本次为典型的SQL执行Query Duration=0 sec时报错，可以参考文档ORA-01555 on Active Data Guard Standby Database (文档 ID 1273808.1)来进行排查。一般建议就是安装最新的PSU来规避这些问题，有些可以通过重启或刷共享池等方式解决，也可以在ADG备机上写成定时脚本每天执行来处理此问

有个用户系统异常，需要临时将一个业务表改名，改的时候报错：SQL> alter table RADTS.TEST_HISTORY rename to RADTS.TEST_HISTORYbak; *ERROR at line 1:ORA-14047: ALTER TABLE|INDEX RENAME may not be combined with other operations...

近期，在一个客户的ORACLE 18C安装时，遇到一个奇怪问题，在安装过程中报错libodm18.so: file format not recognized; treating as linker script；尝试多种解决方法未解决。后按数据库正常安装流程逻辑来分析，发现数据库安装包为源文件其它地方解压后再压缩过来使用的。初步怀疑是安装源文件损坏问题。在MOS上进行查询，也有类似情况，后续通过重新下载软件安装，即解决。确认为源文件安装包损坏。相关MOS文档：19c Installatio

近期，某用户在进行SQL优化时，通过sqlplus的set autotrace on命令跟踪SQL执行情况时，发现这条SELECT命令竟然也产生了REDO日志；与我们通常理解的DML/DDL语句才产生REDO日志的认识存在差异~对ORACLE数据库的特性了解比较清楚的话，特别是数据块、事务处理方面有较深入学习理解，会知道ORACLE数据库的事务、数据块中ITL事务槽的一些原理、结构信息；会知道一个概念叫“延迟块清除”--delayed block cleanout，在约9年前我在学习了解这一块知识时，对

近期，某用户在重启RAC一个节点的数据库实例时，发现启动速度非常慢。同时业务部门反馈连接RAC存活节点的业务也受影响。通过对日志的分析，在启动数据库时，Reconfiguration速度慢，Reconfiguration后报错IPC Send timeout detected. Sender: ospid 53884 [oracle@test2 (LMD0)]，从而出现了数据库实例组的节点驱逐；Wed Apr 13 19:28:02 2022Instance termination initiated

近期，遇到一个ORACLE 10G数据库环境，用户将数据库迁移到新的硬件服务器上后，新服务器配置较高；分配了200G内存，数据库在运行一段时间后异常；经分析为数据库使用大内存的问题，在10G版本当内存大于168G后，会出现问题。SQL> startupORA-27123: unable to attach to shared memory segmentLinux-x86_64 Error: 22: Invalid argumentAdditional information: 1A

某系统的业务表重建后，次日用户反映业务系统缓慢，检查性能数据，发现业务SQL的执行效率下降，深入分析发现是timestamp数据列，未使用到列上的索引；通过对执行计划的分析，可以发现是发生了隐式转换；即使用idtime > systimestamp;时，实际执行的是filter(SYS_EXTRACT_UTC(INTERNAL_FUNCTION("CREATION_DATE"))>TIMESTAMP' 2022-03-14 00:17:35.520486000')；MOS文档上Index o

近期，某用户的数据库环境遇到报错ORA-00600: internal error code, arguments: [qkacon:FJswrwo], [3]。对于ORA-00600报错，在MOS上查询与一个BUG描述较为符合。ORA-600 [qkacon:FJswrwo] Using CONNECT BY (Doc ID 1070636.1)。文档中提到了打补丁或修改隐含参数的方式来处理；打补丁需要停业务，影响较大；尝试了修改隐含参数的方式，此种不再报错，应用系统恢复正常。相关信息如下：O

某用户遇到RAC数据库的一个节点，应用程序无法连接上数据库的问题。排查发现是数据库监听程序异常，无法建立连接。经一系列排查，发现为数据库安装时的一些参数设置不够合理，在系统长时间运行后，出现了些问题。[grid@rac-a ~]$ uptime --节点1启动时间长11:55:12 up 263 days, 2:38, 2 users, load average: 1.53, 1.73, 1.85[oracle@rac-b ~]$ uptime11:55:37 up 95 days, ...

近期，遇到在某用户AIX环境安装RAC集群数据库时，出现SSH互信创建出错的问题。一开始按照正常分析思路，分析OUI安装时的日志信息，报SSH的密钥不匹配；此时先通过在/etc/ssh/sshd_config文件中追加相应加密算法，仍然无法解决。后续排查发现是SSH版本太高（aix 7.1上安装的openssh 8版本）；回退到openssh 6版本解决问题。这也再次提醒我们，安装ORACLE数据库时，要在MOS上对相应的操作系统版本、数据库版本认证匹配核对好。[INS-06006] Pas

近期，某用户环境出现集群数据库一个节点无法启动、加入集群的问题。集群版本为11.2版本，检查集群日志，问题比较明显，集群alert日志中让看CSSD进程日志，CSSD中显示无心跳网络:has a disk HB, but no network HB;按如下步骤排查处理：1.首先通过hosts文件确认了数据库心跳网络IP，并在操作系统层面确认心跳网卡状态正常并且可以互相PING通、SSH联通。2.通过gpnptool get确认集群使用的心跳网络即为上一步检查的。3.根据11.2集群组件功能，GI