![](https://img-blog.csdnimg.cn/20201014180756928.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
Oracle Troubleshooting
文章平均质量分 80
出埃及
Oracle DBA’s Road!
展开
-
cursor:pin s wait x
cursor:pin s wait x最近在晚上3点左右账务d会报cursor:pin s wait x的性能问题,收集了awr和ash报告信息。ASH信息:时间从31-03-2012 02:57:40到31-03-2012 03:12:40,时间间隔为15分钟。AWR中信息:正常时的解析情况:出现cursor:pin s wait x时的解析情况:从会原创 2012-05-16 21:28:08 · 1476 阅读 · 0 评论 -
Bug:5407249
Thu Aug 23 08:27:30 2012Errors in file /u01/oracle/app/oracle/admin/dsjz/bdump/dsjz2_mmon_229852.trc:ORA-00600: internal error code, arguments: [ktte_append_file_info-1], [9], [9], [9], [9], [], [],原创 2012-08-23 10:31:46 · 523 阅读 · 0 评论 -
Cursor pin S wait on X,ORA-600
Alert信息:Cursor pin S wait ON X,ora-600Sat Aug 18 05:40:02 2012Errors in file /u01/oracle/app/oracle/admin/prdb/udump/prdb1_ora_3813910.trc:ORA-00600: internal error code, arguments: [kkshgnc-n原创 2012-08-21 09:05:49 · 997 阅读 · 0 评论 -
使用Logmnr发现那些操作产生归档
最近某套库2号节点的归档异常的多,660M的redo log,平均3分钟切换一次,产生大量归档。NBU调度归档备份也成为瓶颈,IO等待相当严重,通过日志挖掘,然后和应用沟通,解决了部分问题。开始查看,发现参数utl_file_dir没有设置,修改这个参数要重启数据库。很显然,我们繁忙的生产库没有合理的理由是不可能重启的。9i后可以使用数据字典在线分析。SELECT supplemental原创 2012-08-15 21:11:32 · 800 阅读 · 0 评论 -
使用ASH信息,发现高CPUsession
ASH信息是我们Troubleshooting一个很重要的信息来源,当然,我们也不一定要收集一个ASH报告来分析,一般从v$active_session_history可以得到想要的信息,如果前面视图里已经不存在,那么可以通过DBA_HIST_ACTIVE_SESS_HISTORY来获取需要的信息,看个小例子:昨天某套库的CPU使用一度达到99%,作为维护人员,我们肯定要去关注,查找原原创 2012-08-03 02:47:25 · 4380 阅读 · 0 评论 -
Bug 7462072(Cursor:pin S wait on X)
遇到的mutex的相关问题比较多了,某库出现间隔性的Cursor:pin s wait on x,先收集信息,看看如下ASH信息:SQL_ID SESS_STATE EVENT COUNT PERCENT ------------ --------- ------ ----- -------原创 2012-08-03 16:52:53 · 1270 阅读 · 1 评论 -
TNS-12520,TNS-12519,TNS-12516
告警短信:can't connect DB,maybe down!,TNS-12520,TNS-12519,TNS-12516在listener log里面发现如下信息:10-JUL-2012 14:14:27 * (CONNECT_DATA=(SID=xxx)(CID=(PROGRAM=oracle)(HOST=host1)(USER=oracle))) * (ADDRESS=(PR原创 2012-07-10 18:14:24 · 968 阅读 · 0 评论 -
ORA-07445: core dump kslgetl
昨晚一套核心库的一个节点宕掉,然后reboot了,在alert里面发现如下信息:Thu Jul 5 03:03:50 2012Errors in file /u01/oracle/app/oracle/admin/crm/bdump/crm1_dbw9_14426.trc:ORA-07445: exception encountered: core dump [kslgetl()原创 2012-07-05 14:21:25 · 1373 阅读 · 0 评论 -
用Partition Exchange(分区交换)卸载数据
我们有个应用每天操作相关的一张核心表t_ms_mdeia_task,此表是按天来做的List分区,分区键为monthday,列值类似于‘mmdd’,共有366个分区。每天的数据量在3千万以上,应用的要求是只保存31天,之前的全部迁移到历史表中,用于查询。也就是说每天要把31天前那一天的数据迁移到hist表里面,当然hist表也是分区的。应用侧原先通过存储过程来大批量的进行删除和inse原创 2012-06-12 20:56:21 · 814 阅读 · 0 评论 -
Hang with log file sync
昨天一套核心库出现故障,几百个session堵塞,最后宕机,由于数据库是客服库,很敏感,所以办公室顿时嘈杂起来。我们处理这类故障的原则是先恢复业务,其它的都随后在展开,在随后的分析工作中,走了点弯路,下面我把整个故障的情况展现给大家。首先,在alert里面发现了ora-01555,这个是从7点左右开始的,一直持续到下午2点都有这样的事件.Tue May 22 07:11:56 2012原创 2012-05-23 15:08:22 · 1882 阅读 · 0 评论 -
遭遇Cursor:pin s wait x and Ora-04031
从昨天晚上开始某核心库过十几分钟就会报出Cursor:pin s wait x的告警短信,而且很频繁,第二天到公司查了下原因:首先收集了下相应时间ASH报告和AWR报告,显示的信息如下:Top 5 Timed Events Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Cla原创 2012-05-21 11:07:14 · 1127 阅读 · 0 评论 -
latch:library cache
BBOSS库性能问题分析问题背景据反应BBOSS库响应比较慢,性能低下,需要查找原因。系统环境:HP UX 11.3Oracle RAC 10.2.0.3问题分析OS分析:通过采集主机CPU,I/O相关信息9:00- 14:00 CPU:Avg load: 20% High load: 25%IO:Avg load: 40% High load: 45%原创 2012-05-16 22:03:07 · 2062 阅读 · 0 评论 -
Fatal NI connect error 12170
11.2.0.2的库两个节点的alert里均频繁出现如下信息:***********************************************************************Fatal NI connect error 12170. VERSION INFORMATION: TNS for IBM/AIX RISC System/6000:原创 2012-11-16 15:34:01 · 2124 阅读 · 0 评论