ITPub博客

通过查看数据库告警日志、以及css日志。但是数据库日志并没有相关记录信息，操作系统日志也未记录，日志状况类似服务器断电情况，突然中断均未生成。由于发生多次，查看last reboot：检查/etc/kdump.conf，在/var/crash目录下也未发现crash记录生成。这是应该在当时系统hang住了，没有panic，正常来说hang不会产生coredump所以为了后续排查问题，修改系统pan

数据库日志，磁盘组突然被dismount掉：Tue Apr 02 10:39:15 2024Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_lgwr_150319.trc:ORA-00345: redo log write error block 222293 count 1ORA-00312: online log

数据库连接的时候发现连接异常：ERROR:ORA-00257: archiver error. Connect internal only, until freed.检查数据库日志：检查发现ASM实例shared pool空间不足，数据库无法连接ASM实例。检查ASM SGA配置SQL> show parameter ta

获取卡时间段的堵塞事件，发现大部分事件是“cursor: pin S wait on X”，“log file parallel write”，“LGWR-LNS wait on channel”等根据blocking_session的堵塞源进行查询，最终查到源头，发现堵塞在文件号为2，块号2的源头上：文件号2为“SYSAUX”表空间SYSAUX表空间主要是awr、ash、基表等信息，而当时堵塞

数据库每天晚上10点后业务性能很卡，大量的insert被堵塞，查询等待事件发现有大量的“library cache lock”和“cursor: pin S wait on X”。22:00数据库的统计信息开始收集， Sql Tuning Advisor堵塞了统计信息的收集，等待事件是“library cache lock”，Sql Tuning Advisor的等待事件是ON CUP。后续导致i

数据库rac集群由于做bond未关闭NetworkManager，网卡发生切换导致集群自动发生重启故障。检查集群alert日志，发现三个节点相互被驱逐：检查gipc日志，发现节点2和节点2心跳网络bond1存在”rank 0”现象：根据文档HAIP Fails to Start as GIPC Has Rank 0 or -1 for Interconnect (Doc ID 1374360.1

业务无法正常进行，查看数据库后台进程，发现有大量阻塞QL_ID        WAIT_CLASS      EVENT                     ------------- ----------

共享磁盘均损坏：  /dev/rhdisk22  /dev/rhdisk23  /dev/rhdisk24不能正常dd去读写。临时本地nfs共享做仲裁盘，配置nfs服务端root@ptdb2:/# vi /etc/exports/grid/ocr -rwexportfs  -a# more /etc/exports /grid/ocr -rw如果没有/etc

方式一、做hanganalyze单机：sqlplus -prelim /nologconnect / as sysdbaoradebug setmypidoradebug hanganalyze 3oradebug dump systemstate 266oradebug tracefile_name RAC：#sqlplus  / as sysdbaSQL> oradebug s

首先可以比较一下rac心跳正常情况和发生心跳延迟时的awr情况：先比较心跳流量正常情况：在正常情况下，心跳网络每秒流量基本上很小，这里才580k。异常情况：发生异常时，一般流量较大，这里每秒流量达到了24M，如果带宽比较小或者MTU大小为默认的1500，可能造成较大的影响。比较消息队列平均发生时间正常情况：正常小于1ms。异常情况：发生异常情况，这里延迟就达到了20多毫秒。心跳延迟会导致rac数据

增加temp表空间数据文件报错：SQL> alter tablespace temp add tempfile '+DATADG';alter tablespace temp add tempfile '+DATADG'*ERROR at line 1:ORA-01119: error in creating database file '+DATAD

补丁打完之后发现数据库不能正常起来，报错磁盘组不存在或者不能mount，如下图：从报错看：ORA-00313:open failed for members of log group 6 of thread 10RA-00312:online log 6 thread 1:'+DATA/YLTHIS/ONLINELOG/redo06.log'0RA-17503:ksfdopn:2

源库19.8，dg库19.20，切换dg库刷视图升级补丁报错：./datapatch -verboseError: prereg checks failed!patch 31281355: Error reading descriptor from registry: Couldn't open encmap gbk.enc:such file or directoryat /oracle

撤销drop磁盘SYS@+ASM1> alter diskgroup crs drop disk '/dev/asmdata16' rebalance power 0; alter diskgroup crs drop disk '/dev/asmdata16' rebalance power 0 * ERROR at line 1: ORA-15032: n

二节点在重启后操作系统损坏，需要重构，下面将描述重构方法一、清除集群上二节点的节点信息1、删除实例dbca或静默：[oracle@rac1 ~]$ dbca -silent -deleteinstance -nodelist rac2 -gdbname orcl -instancename orcl2 -sysdbausername sys -sysdbapassword oracledbca-实

一、问题描述及分析应用业务反馈应用响应缓慢。登录数据库检查，发现数据库响应慢，有大量enq:HW–contention等待事件。结合awr报告和ash报告，发现整体等待时间消耗在推高水位线征用上，如下awr top事件：Ash消耗也是enq:HW–contention检查enq:HW–contention的sql语句，发现集中在三条语句上，如下：这三条语句是：INSERT INTO&nb

业务报错：检查process配置及连接数均正常，没有达到上限。监听日志查看，发现既有专用模式连接，又有共享模式连接：专用模式正常，查看资源使用情况，没有达到上限，select * from v$resource_limit;那么检查共享模式连接，使用情况查看SQL> set linesize 180SQL> select s.name,s.paddr,s.status,p.addr,p

有客户通过delete误删了sys.seg$表的数据，重启数据库，发现数据库不能正常启动。删除命令：delete from sys.seg$ t where ts#=2;通过dump删除标识tab 2, row 21, @0x151btl: 4 fb: -CHDFL-- lb: 0x2  cc: 0 cki: 21tab 2, row 22, @0x14e9tl: 4 fb: -CHDF

查询条件超过一个月就不走索引：检查表的block数和数据行数：select blocks,num_rows from dba_tables where table_name='MS_MZXX';blocks:618687 num_rows:20335462查看聚簇因子clustering_factor的数：select clustering_factor from dba_inde

数据库版本为11.2.0.4，数据库alert不不时抛出异常告警：ORA-07445: 出现异常错误: 核心转储 [opixguid()+13] [SIGSEGV] [ADDR:0x7F67B7F4EBC0] [PC:0x648BB7D] [Address not mapped to object] []Dump file /oracle/app/oracle/diag/rdbms/orcl/or