ITPub博客

跑批是串行进行的，同时伴随着在线业务，整个跑批过程中只卡在SQL（6hqva0h4awrxh）执行环节上，相关等待事件为gc current grant 2-way，其他环节及在线业务都不受影响，主机整体资源较为空闲。最后通过重建问题SQL涉及对象的索引解决。故障时间段的awr、ash性能报告和数据库hanganalyze全局dump信息：如截图所示并没有出现异常指标及全局的性能问题，种种迹象表明

数据库不能正常启动，检查alert日志如下异常告警：Mon Feb 14 13:17:38 EAT 2023Errors in file /app/oracle/admin/orcl/bdump/orcl1_lgwr_18609.trc:ORA-01110: data file 8012: '/dev/vg21/orcl_VG21_10368_080.dbf'ORA-01115:

同样一个sql查询视图，第一次查询很快，1s内就查询出来，第二次再查需要1分多钟才能出来。sql语句如下：select *   from vEISWorksService where StudiesDoneDate >= '20230628'    and&nbs

业务不能连接，检查集群状态，发现节点二处于“stuck archive”状态：[grid@rac1 /home/grid]$crsctl stat res -t -------------------------------------------------------------------------------- NAME  

服务器上ping报错ping: socket: Too many open files in system[root@rac1 ~]# ping 192.168.238.254ping: socket: Too many open files in system正常情况下“Too many open files in system”报错都是open files参数设置过小导致。root用户和ora

问题描述数据库节点1查询比节点2查询慢。现场操作应用发现发现同一sql语句在节点2上只要2分钟左右，在节点1，该条sql执行要超过30分钟。处理过程根据问题，初步判断是由于错误的执行计划，导致性能问题，但实际上对两个节点做trace跟踪发现执行计划都一致，后续通过awr报告和10046事件跟踪发现由于“gc cr multi block”耗时造成节点一慢，这是oracle RAC大事务处理特性，两

问题描述数据库和监听都能正常起来，但是应用不能连接，使用“lsnrctl status”超时报错。 出现问题过程是：做了虚拟机迁移，对存储进行扩容，迁移后应用不能正常访问数据库。重启监听操作，监听不能正常停止，通过杀进程然后再启动，能正常起来，但不能查看监听状态。查看数据库连接情况，并没有连接进来，客户端直接访问不能连接上，看后台alert日志发现有很多终止监听进程ora-609的报错，这种情况一

情况描述OA数据库，在启动应用后，远程执行select语句特别慢，比如查询“select id,form_id from CAP_FORM_RESOURCE where PROPERTY_TYPE = 104”语句没启动应用时1内秒就能出结果，启动应用后需要60多秒，在远程机子上ping数据库服务器包延迟比较高，当应用停止后查询变快，ping数据库服务器也恢复。虚拟化环境：怀疑CPU不能充分利用问

查看事件，归档等待达到20多分钟检查节点alert日志发现，最早12点53分49秒就有归档失败报错，如下：到13:19:39的时候，发生了所有online logs需要归档，导致数据库等待归档事件，如下：查看最早发生归档异常时间段的trace日志，如下图：在告警中，报asynch I/O内核限制，主要是由于异步IO请求达到AIO-MAX-NR的上限。查看当前内核参数配置，cat /etc/sysc

问题描述：生产环境相同的inser语句在别的非.NET程序相应明显快于.NET程序，执行时间相差比较大，影响正常业务运行，测试环境反而正常。问题详细诊断过程问题初步判断诊断过程：    查询插入慢的sql_id    检查对应的执行计划，未发现异常，SQL A-TIME实际内部执行时间为1毫秒     使

一节点正常运行，二节点通过crsctl start crs启动，发现alert日志及所有日志都没生成，oracle用户下连一个相关进程都没有清理缓存：rm -rf /tmp/.oracle/*服务挨个启动也无效：/etc/init.evmd run >/dev/null 2>&1 & /etc/init.cssd fatal >/dev/null 2>&am

oracle版本11.2.0.3，数据库alert日志报ora-07445 [opiaba()+635] ora-00600 [17147]，然后实例宕机，alert日志如下：从oracle mos上查看到bug：Bug 12578873  ORA-7445 [opiaba] when using more than 65535 bind variables解决方式：这主要还是变量过多，

sysman登录oem页面报错如下：查看oms状态：cd /bin emctl status oms -details2022-09-14 09:22:23,886 [[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)'] ERRO

[grid@rac1 ~]$ lsnrctl statusLSNRCTL for Linux: Version 12.2.0.1.0 - Production on 19-SEP-2022 13:46:50Copyright (c) 1991, 2016, Oracle.  All rights reserved.Connecting to (DESCRIPTION=(ADDRESS=(

客户端连接报ORA-12516错误监听日志报TNS-12514、TNS-12516错误27-SEP-2022 08:00:16 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=jdbc)(USER=SYSTEM))(SERVICE_NAME=orc1)(FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(RETIRES=20)(DE LAY

INP_BILL_DETAIL表数据被误删，只确定是由于job任务调用发起的删除。通过查询job任务select * from all_scheduler_jobs; select * from dba_jobs;由于job任务比较多，查询的what列并没有直接的delete表数据，那么需要确认是由哪个存储过程和函数发起的，查询存储过程：select * from dba_source where

查询慢的sql_id的执行计划：@?/rdbms/admin/awrsqrptSpecify the Begin and End Snapshot IdsEnter value for begin_snap: 114616 Begin Snapshot Id specified: 114616 Enter&nb

表数据量不大，但数据不能删除或者更新，删除和更新时hang住删除时，新开查询查堵塞源，发现blocking_session是825杀掉堵塞会话再次删除终于成功。

数据库版本12c，操作系统连接数达到上限，导致所有job任务均不执行，手工执行报job now runningSQL> show parameter job_queue_processesNAME                            

后台"sqlplus / as sysdba"去连接，不能正常连接alter日志报错：Errors in file /opt/app/oracle/admin/gc/bdump/gc_pmon_14178.trc:ORA-00471: Message 471 not found; No message file for product=RDBMS, facility=ORATu