oracle案例
文章平均质量分 73
汪灵骅
资深DBA,oracle ACE
展开
-
ORA-15196: invalid ASM block header [kfc.c:26383] [endian_kfbh] [1] [5137] [255 != 1]
由于xx库在2024年5月31日上午出现归档日志异常增长现象,导致asm磁盘组空间被撑满。应急处理删除部分归档,后续规划进行磁盘组扩容,计划晚上添加两块1T磁盘。由此导致了DATA磁盘组的状态异常。本次故障由于添加磁盘组沟通检查不到位,误将原有rman备份磁盘(双节点共享盘,二节点mount)newdata03作为新增扩容磁盘添加进磁盘组导致。2024年5月31日22:38客户反馈,业务在2024年5月31日22:33左右无法连接。2024年5月31日7:59,反馈磁盘划分完成同步挂载2块1T磁盘。原创 2024-06-05 10:07:24 · 449 阅读 · 0 评论 -
ORA-04031 unable to allocate bytes of shared memory(无法分配xxxxx共享内存)(shared pool)
针对该次shared pool的问题进行的记录。XXX集团2024-05-09前经常受到ORA-04031报错困扰,一直报的是shared pool,所以客户自己将shared pool手动配置了20g,还是报错,再配40g,还是报错,找我司来进行排查。发现7个sub pool都是SQLA和KGLH0过高,加起来占6成左右。发现 SQLA和KGLH0过高,确认方向。在不同版本为不同bug.删除pdb级SHARED_POOL_SIZE和/或SGA_MIN_SIZE初始化参数。原创 2024-05-28 17:44:43 · 1160 阅读 · 0 评论 -
oracle rac节点重构(增删节点)的常见报错
跑addNode.sh过程中一般会碰到2个常见报错。PRKC-1025 : Failed to create a file under the filepath /oracle because the filepath is not executable or writable 。Exception java.lang.OutOfMemoryError: Java heap space occurred.. java.lang.OutOfMemoryError: Java heap space原创 2024-04-18 15:11:49 · 464 阅读 · 0 评论 -
oracle control file sequential read处理
从异常时间点和正常时间点AWR中对比control file 相关evvent waits和IOStat by Filetype summary, 发现正常时1小时也有800多万次wait,但是平时AWR 控制文件读avg time为300 us, 所以判断问题时是I/O 比平时慢了。(block#) 40 * (confile file block size) 16k/ (_asm_stripewidth) 128k=5. 第1条带的第5个AU 上,第1个128k.原创 2024-04-16 09:00:00 · 571 阅读 · 0 评论 -
ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O(添加asm磁盘,rebalance)
添加磁盘的时候碰到的,rebalance到最后,时间0,但是就没成功,asm日志报错了。等待,大约20+分钟才成功。不需要重启集群和实例。原创 2024-04-12 12:05:42 · 363 阅读 · 0 评论 -
ORA-00445:backaround process “w000“ did not start after 120 seconds
在oracle中,多个进程共享相同地址的共享内存,特别是父进程派生出子进程的时候,父进程告诉子进程的内存对象地址,应该是一致的。启用了ASLR,如果是不同的进程读取,就会给随机的offset偏移量,导致不同的进程,即使是同一个对象,得到的地址是不同的。linux系统有个内核新特性ASLR,是一种针对缓冲区溢出的安全保护技术, 内存地址随机化机制,当内存不足的时候就会出现预警,查看数据库服务器发现64G内存紧张时只剩几百兆,结论为数据库内存不足时导致数据库hang住,无法处理新的进程,导致卡住。原创 2024-04-12 11:50:53 · 814 阅读 · 0 评论 -
oracle gipcmodNetworkProcessBind: slos dep : Address already in use (98)
gipcmodNetworkProcessBind: slos dep : Address already in use (98) gipcEndpoint : localAddr 'mcast://224.0.0.251:42424/192.168.0.1 --> 42424 is the port原创 2024-04-07 10:12:08 · 540 阅读 · 0 评论 -
oracle 19c添加磁盘报错 ORA-15137
添加asm磁盘的时候报错,ORA-15032 ORA-15137,主要的是后面的这个ORA-15137,asm在rolling状态。前面的可能性很多,但是结果都是asm状态的问题,可能为打补丁的时候有问题导致。刷了一下OCR补丁信息,可以添加磁盘了。原创 2024-03-27 09:03:35 · 385 阅读 · 0 评论 -
oracle 添加多个scan ip方式以及问题处理
默认是multi on的(可多个scan ip),如果off的话会导致该问题。原创 2024-03-22 10:15:47 · 512 阅读 · 0 评论 -
oracle ORA-01591锁被未决分布式事务处理
此种情况就是在本地执行commit以后,此时远端库还没有完全commit,此时网络中断,导致本地库该表是commit状态,但是远端库还是prepare状态,一般来讲,此时如果源端得到的事务信息是全的,那么数据库不需要人为干预,能够自动根据事务信息进行提交操作,但是出现这个问题的时候,基本就表示提交的事务信息不足以让远端库执行提交操作,所以此时这种事务就需要人为干预了。– 可根据异步transaction的状况决定使用方法。这种情况,commit force还是rollback force都会报。原创 2024-01-26 10:54:19 · 1744 阅读 · 0 评论 -
oracle一次truncate慢处理案例
truncate的实质是在不修改数据块的情况下,通过修改segment header的data_object_id,hwm,extent map,aux map等信息来实现清空表的目的,其中还涉及数据字典基表以及L1、L2位图块的修改,所以说truncate操作只是存储数据的数据块没有产生任何redo和undo,但是segment header,位图块,数据字典基表还是会产生redo和undo。当我们排查问题没有思路的时候,不妨尝试下10046跟踪去细细查看执行此语句的会话全过程,或许就会明朗了。原创 2024-01-26 10:08:47 · 712 阅读 · 0 评论 -
oracle一次卡顿案例(七)-swap
内存都是以页的形式划分的,默认情况下每页是4K,这就意味着如果物理内存很大,则映射表的条目将会非常多,会影响CPU的检索效率。因为内存大小是固定的,为了减少映射表的条目,可采取的办法只有增加页的尺寸。2021年8月30日9点15分客户反映统一号源库卡顿,楼下自助挂号机异常等待,经查证为his的故障,his库内存满载,导致其他库到his库的dblink查询出现故障。此时可以判断出结果,因udisks-daemon的bug占用部分内存(100+G),且大页配置非最佳,导致内存满负荷,导致业务崩溃。原创 2024-01-25 11:28:02 · 878 阅读 · 0 评论 -
oracle一次卡顿案例(六)-latch free
XX客户生产数据库2021年1月22日上午排查故障,客户提供高峰期卡顿时间发生在月结。由于报告保存时间为7天,无法查找到月初的报告,通过增加业务模拟环境,经过仔细诊断,发现业务产生时间段操作系统整体资源使用率较低,数据库latch争用较为严重。原创 2024-01-25 10:38:32 · 389 阅读 · 0 评论 -
oracle 透明网关,oracle到sql server的dblink
在C:\product\11.2.0\tg_1\dg4msql\admin目录下,默认有一个initdg4msql.ora,此文件命名格式为:init.ora,可以使用initdg4msql.ora默认参数文件,也可以自己创建。(SID_NAME = HINAMIIS_Domain) #此处为配置文件SID,要与前面创建的init HINAMIIS_Domain.ora中的名字对应。设置windows里的TNS_ADMIN=C:\product\11.2.0\tg_1\network\admin。原创 2024-01-22 10:25:36 · 1856 阅读 · 0 评论 -
oracle ORA-01157 ORA-01110 ORA-27048(被勒索的情况)
数据文件的0号块(OS块信息)被更改导致。原创 2024-01-16 16:43:25 · 388 阅读 · 0 评论 -
oracle rac节点重构
使用root用户登录,并执行下面的命令(所有节点,但最后一个节点除外) (踢出当前节点)(perl失败,见4)原创 2024-01-15 15:12:53 · 987 阅读 · 0 评论 -
oracle一次卡顿案例(五)-绑定变量
本次故障是由于上述sql没有进行绑定变量,在执行时产生了大量的硬解析,并且数据库定时收集统计信息的job任务在22点也开始了运行,两类事件都在不断申请library cache lock,导致互相堵死,产生大量的等待记录,最后造成二代支付系统在22点出现插入卡顿的现象。通过分析22点的历史等待事件发现,所有的会话都被931、以及859的会话锁住,产生了library cache lock的等待事件。工程师分析在22点的数据库等待事件,发现有1000多条的library cache lock等待事件。原创 2024-01-15 14:33:59 · 396 阅读 · 0 评论 -
oracle一次看门狗(watchdog)导致的卡顿案例
查看2022年12月19日2节点的主机日志,发现报大量的内核死锁故障,从而导致后面主机卡死,即使显示器直连服务器也是连接不上。在12月19日晚19点半左右,客户收到内部告警信息,二节点集群无法连接服务器,并且通过显示器直连服务器时,任然无法直接连接。12月19日故障,工程师分析故障时间点集群日志,在17点53分到18点50分之前,都存在大量线程未分配的报错。6、BIOS开启了超频,导致超频时电压不稳,容易出现CPU死锁。4、虚机所在的宿主机的CPU太忙或磁盘IO太高。5、虚机机的CPU太忙或磁盘IO太高。原创 2024-01-15 11:45:39 · 556 阅读 · 0 评论 -
oracle ORA-00603 ORA-27504 ORA-27300 ORA-27301 ORA-27302处理
修改lo网卡(网络回环网卡)MTU参数为16436(MTU参数限制了网络通讯中每次传输IP包的大小,当发送UDP报文长度大于MTU时,IP层会对报文进行分片和重组),无需修改交换机mtu参数。12月27日故障,工程师分析故障时间点数据库alert日志发现大量缓冲区不足的报错,从12月27日00:54分开始一直报错到早上6点半重启数据库。在12月27日凌晨5点左右,客户收到业务告警业务无法正常运行,6点半左右将service name服务移到2节点,并且重启1节点主机,恢复业务。原创 2024-01-15 11:13:53 · 568 阅读 · 0 评论 -
oracle一次无法登陆案例
通过检查awr报告的Mutex Sleep Summary部分,可以发现是在增加子游标的时候,导致cursor: mutex X等待事件,增加子游标慢可能是由于sql版本数太高导致的。总结:通过上面分析可以看出,此次数据库cursor: mutex X问题是由于sql的版本数太高触发oracle 的bug导致的。通过上面可以看出,大部分的会话的等待事件cursor: mutex X,产生cursor: mutex X等待事件的原因有很多。2023年06月30号,客户应用反馈imagedb数据库无法登录。原创 2024-01-12 13:59:41 · 938 阅读 · 0 评论 -
oracle一次卡顿案例(四)-latch: shared pool
关于latch: shared pool等待事件:oracle为了分配共享池,多个会话执行sql解析需要分配到chunk时,为了获得唯一的shared pool latch发生争用,常见于并发会话比较高或者硬解析比较多的场景,也就是说在获得shared poollatch过程中发生争用,则等待latch: shared pool事件。检查会话发现,这些会话执行的sql同row cache lock等待事件会话的sql基本一样,也就是说,一个会话交替出现,所以这个2个等待事件可以看成是一个问题。原创 2024-01-10 15:48:33 · 1574 阅读 · 0 评论 -
oracle一次卡顿案例(三)-library cache lock
2022-07-16 09:14:53这个时间点,本次所有的library cache lock会话都被Memory: Reg/Dereg等待事件会话阻塞,可以判断这些library cache lock会话是登录会话,等待更新登录时间,也就是说上面70多个会话都是登录会话。上面都是应用用户,由于多个应用用户的阻塞会话正在执行update 登录时间,导致后面这些用户登录会话无法更新底层表的登录时间,所以无法连接数据库,而其他用户登录没问题。让客户杀掉会话,杀掉之后,随后又发起300多个会话。原创 2024-01-10 15:36:21 · 1231 阅读 · 0 评论 -
oracle一次卡顿案例(二)-row cache lock
另外一个等待事件cusor: pin S wait on X,这个等待事件是某个会话需要申请S模式的mutex,而mutex被其他会话以X模式占有了,当前会话会处于cusor: pin S wait on X等待事件,结合这些会话的阻塞会话发现,阻塞会话全部是row cache lock等待事件的会话,所以说根本原因是row cache lock导致的。可以看出,早上10:02这个表刚刚收集过统计信息,不到20分钟,统计信息已经过期了,说明这个表数据变化特别快。原创 2024-01-09 11:38:24 · 1179 阅读 · 0 评论 -
oracle RFS[16]: No standby redo logfiles available for thread 1
要开实时应用的话,备库需要blocksize 4096、512的standby redo 都有才行,不然会报错。standby redo 同个thread,最少2个,可以轮换。如果主库同个thread,既有512,又有4096。blocksize正常是512。影响的因素:系统、存储物理扇区。原创 2024-01-08 11:42:28 · 1097 阅读 · 0 评论 -
oracle一次卡顿案例(一)
这个等待事件是由热链争用导致,本次问题预估由于大量逻辑读的SQL语句有可能产生非常严重的latch:cache buffers chains等待,因为每次要访问一个block,就需要获得该latch,由于有大量的逻辑读(buffer get),那么就增加了latch:cache buffers chains争用的机率。这条sql没处理前,走的是recorddt这个列的索引,很慢要几十秒,使用hint medicalrecordid这个列的索引后,仅需一秒就能完成查询,经过诊断排查后给出两个解决方案。原创 2024-01-08 10:48:51 · 459 阅读 · 0 评论 -
oracle 一次undo坏块案例
工程师接到客户电话,数据库delete数据一直卡住。客户提供堡垒机远程方式,美创工程师登录操作系统,发现数据库异常卡顿,后台有大量等待事件,磁盘io已经达到峰值数据库重新起停时间需要2小时以上,且磁盘io一直处于写满状态,且再最后一次启动数据库后,undo出现坏块,需要客户进行排查磁盘是否损坏接到客户通知,磁盘修复成功。美创工程师重新连入数据库,修复坏块,重新打开数据库1 、确认数据库存储存在故障后,最好不要再对数据库进行读写或者启停操作,避免发生数据文件损坏。原创 2024-01-04 17:20:12 · 1174 阅读 · 1 评论 -
oracle aix平台19c rac互信不通案例
在给某客户AIX7.2上安装19c的集群软件时,报错[INS-06006]Passwordless SSH connectivity not set up between the following…INS-06006 GI RunInstaller Fails If OpenSSH Is Upgraded to 8.x (文档 ID 2555697.1)安装前,以root用户身份:(如果您的“scp”的位置与以下不同,请更改路径)将以下行添加到新创建的文件。原创 2023-12-29 11:35:16 · 425 阅读 · 0 评论 -
oracle 一次row cache lock跑批等待案例
该行缓冲队列锁会在段分配的时候发生,观察持有这个队列锁的会话在做什么。当内存中的序列号用完时,系统再生成一组新的序列号,并保存在缓存中,这样可以提高生成序列号的效率。在RAC情况下,可以将使用频繁的序列Cache值增加到10000,或者更高到50000,这些值在客户的环境中都有采用。在RAC环境中,序列的Cache问题可能会对性能有着决定性的影响,缺省的序列Cache值为20,这对RAC环境远远不够。我的理解:每次读取下个序列,都要更改数据字典,如果cache 20,就是每20个序列,更改一次数据字典。原创 2023-12-26 16:03:29 · 1218 阅读 · 0 评论 -
oracle 一次ORA-00600:[krrfro_cachedscn]案例
表象体现为dg备库新生成的归档全部存在坏块应用归档报错ORA-00600:[krrfro_cachedscn]原创 2023-12-28 14:20:55 · 361 阅读 · 0 评论 -
oracle rac asm磁盘头损坏案例
这个ASM Disk header的作用是当真的KFBTYP_DISKHEAD被意外覆盖或损坏时可以使用Oracle 工具 KFED使用repair选项来修复Disk header。根据报错 found 0 disks 怀疑 是磁盘组里的磁盘有问题,没有启动。此时检查 磁盘头状态正常,显示为KFBTYP_DISKHEAD。集群宕机以后,重启报错,DATADG1磁盘组无法启动。修复磁盘头以后,磁盘能够正常挂起,并且数据库能够拉起。发现磁盘都在,但是磁盘组没法跟磁盘对应起来。设置完成后,一节点能够正常运行。原创 2023-12-29 10:59:53 · 383 阅读 · 0 评论