oradebug/strace/pstack等分析数据库性能问题系列一
对于性能问题或者一些比较奇怪妖异的问题,有很多点可以着手去分析。
准备写一个系列关于用ash/dba_hist_active_sess_history,用oradebug,用linux命令strace,pstack或者用等等等等工具~~来归纳下一些思路,就是当目前为止所有分析的结果都没任何头绪的时候,接下来如何进行深入的troubleshooting。
比如当一个sql执行的很慢的时候,看看sql历史等待事件,看sql执行计划,但要是没什么特别明显的等待,或者执行计划看上去可以,感觉这个sql应该执行正常,为何执行的这么慢呢?那么可以用下oradebug来分析下进程的call stack,或者做这个session的state dump也看出点什么东西,从而分析出正确的结果以及root cause,当然对于session的历史等待时间ASH也是值得去深究的,执行计划更是一个很大的话题,所以这个系列也主要是为了自己在以后的工作中遇到类似的问题,或者没思路的时候,可以有些眉目~~
==============================================
首先写一个利用pstack和strace分析goldengate issue当做系列的第一篇~
这里就是数据库里没啥问题,goldengate也看不出什么毛病,感觉无从下手了~灵光一现bling bling的就解决问题了~
----------------------------------START--------------------------------------------------------
收到一个告警:
延迟了3hour+,登到ggsci里面去看
GGSCI (ora-bi-p-5.va2.b2c.nike.com) 2> !
info r4_ot
REPLICAT R4_OT Last Started 2016-11-02 05:23 Status RUNNING
INTEGRATED
Checkpoint Lag 00:00:00 (updated 00:00:04 ago)
Process ID 27164
Log Read Checkpoint File /gg/app/ggadmin/product/12.1.2.1.0/dirdat/replicate/pdot/r4000020
2016-11-02 05:15:15.156360 RBA 535238535
(lag r4_ot的输出也显示没lag)
没lag呀,但是数据库里面信息却说有lag,那会不是是进程hang住了,先去数据库里面看下apply process的状态
select apply_name,null delay_min from dba_apply where status<>'ENABLED'
union
select capture_name,null from dba_capture where status<>'ENABLED'
union
select ac.apply_name, round((sysdate-applied_message_create_time)*1440)
from dba_apply_progress ap,GV$STREAMS_APPLY_COORDINATOR ac
where ac.apply_name=ap.apply_name
;
APPLY_NAME DELAY_MIN
------------------------------ ----------
OGG$R4_OT 247
于是看看ggserr.log ,view report等等都没看出啥来,因为没有什么报错呀!!!
这个时候怎么办呢,数据库说是apply process已经lag三个小时了,但是goldengate里面没看到任何的error log,
当然自己尝试了多次的info r4_ot,rba并没有改变,或许源端没事务在跑所以r4_ot rba不变动也是有这可能的~
突然想到来分析下进程状态,是不是在wait什么。
先进到数据库里面没看到ggadmin user的等待事件啥的,但是没有啊,所以现在的状态就是ogg也没报错,也显示没lag,在数据库里也没有相应的事务在跑,那么从何下手呢?
~~~~~~~~~~~~~~~~~~~~~~~~~
于是接下来想到去做个pstack来追踪下ogg r4_ot spid的状态
ggadmin@ora-bi-p-5:DCBIPRD5:/gg/app/ggadmin/product/12.1.2.1.0/dirdat/replicate/pdot$pstack 27164
Thread 5 (Thread 0x7f716ae20700 (LWP 27165)):
#0 0x00000038c700b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x0000000000692e91 in ggs::gglib::MultiThreading::Event::Wait(unsigned int) ()
#2 0x00007f717105a69c in ggs::gglib::gglog::LoggingTime::TimeThread(void*) () from /gg/app/ggadmin/product/12.1.2.1.0/libgglog.so
#3 0x00000000006908e4 in ggs::gglib::MultiThreading::Thread::RunThread(ggs::gglib::MultiThreading::Thread::ThreadArgs*) ()
#4 0x00000038c7007aa1 in start_thread () from /lib64/libpthread.so.0
#5 0x00000038c6ce893d in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7f716a61f700 (LWP 27166)):
#0 0x00000038c700b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x0000000000692e91 in ggs::gglib::MultiThreading::Event::Wait(unsigned int) ()
#2 0x00007f71710c0f16 in ggs::gglib::gglog::LogBufferImpl::PublisherThread(void*) () from /gg/app/ggadmin/product/12.1.2.1.0/libgglog.so
#3 0x00000000006908e4 in ggs::gglib::MultiThreading::Thread::RunThread(ggs::gglib::MultiThreading::Thread::ThreadArgs*) ()
#4 0x00000038c7007aa1 in start_thread () from /lib64/libpthread.so.0
#5 0x00000038c6ce893d in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7f71694e3700 (LWP 27167)):
#0 0x00000038c700ba5e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x0000000000692e4d in ggs::gglib::MultiThreading::Event::Wait(unsigned int) ()
#2 0x00007f71710bcbaf in ggs::gglib::gglog::DOMConfiguratorImpl::watchThread(void*) () from /gg/app/ggadmin/product/12.1.2.1.0/libgglog.so
#3 0x00000000006908e4 in ggs::gglib::MultiThreading::Thread::RunThread(ggs::gglib::MultiThreading::Thread::ThreadArgs*) ()
#4 0x00000038c7007aa1 in start_thread () from /lib64/libpthread.so.0
#5 0x00000038c6ce893d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f7163fff700 (LWP 27168)):
#0 0x00000038c700ba5e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x0000000000692e4d in ggs::gglib::MultiThreading::Event::Wait(unsigned int) ()
#2 0x00007f71710a3e1a in CMessageFactoryImpl::RepetitionThread(void*) () from /gg/app/ggadmin/product/12.1.2.1.0/libgglog.so
#3 0x00000000006908e4 in ggs::gglib::MultiThreading::Thread::RunThread(ggs::gglib::MultiThreading::Thread::ThreadArgs*) ()
#4 0x00000038c7007aa1 in start_thread () from /lib64/libpthread.so.0
#5 0x00000038c6ce893d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f716ae23a20 (LWP 27164)):
#0 0x00000038c700f00d in nanosleep () from /lib64/libpthread.so.0
#1 0x0000000000638330 in ggDelayMsecs(long) ()
#2 0x000000000057110e in wait_for_more(short) ()
#3 0x00000000005a539d in process_replicat_loop() ()
#4 0x00000000005bd51a in replicat_main(int, char**) ()
#5 0x00000000006905af in ggs::gglib::MultiThreading::MainThread::ExecMain() ()
#6 0x00000000006908e4 in ggs::gglib::MultiThreading::Thread::RunThread(ggs::gglib::MultiThreading::Thread::ThreadArgs*) ()
#7 0x00000000006909eb in ggs::gglib::MultiThreading::MainThread::Run(int, char**) ()
#8 0x00000000005bc1af in main ()
很明显可以看到进程在wait!!!!
再做个strace深入看看
Process 27164 attached
restart_syscall(<... resuming interrupted call ...>) = 0
futex(0x281ca64, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x281ca60, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x281ca38, FUTEX_WAKE_PRIVATE, 1) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
select(7, [6], NULL, NULL, {0, 0}) = 0 (Timeout)
lseek(14, 534773760, SEEK_SET) = 534773760
read(14, "Details</b></p><li>Flybeam struc"..., 1048576) = 477287
read(14, "", 1048576) = 0
lseek(14, 0, SEEK_SET) = 0
read(14, "F\0\7f0\0\3\2430\0\0\10GG\r\nTL\n\r1\0\0\2\0\0042\0\0\4 \0"..., 1048576) = 1048576
lseek(14, 1048576, SEEK_SET) = 1048576
lseek(14, 534773760, SEEK_SET) = 534773760
read(14, "Details</b></p><li>Flybeam struc"..., 1048576) = 477287
stat("/gg/app/ggadmin/product/12.1.2.1.0/dirdat/replicate/pdot/r4000021", 0x7ffcac69c610) = -1 ENOENT (No such file or directory)
nanosleep({1, 0}, NULL) = 0
-------------------------------------------
看到了stat("/gg/app/ggadmin/product/12.1.2.1.0/dirdat/replicate/pdot/r4000021", 0x7ffcac69c610) = -1 ENOENT (No such file or directory)
一目了然,下一个r4_ot要读的trail没找到
看看trail有哪些
GGSCI (ora-bi-p-5.va2.b2c.nike.com) 2> info r4_ot
REPLICAT R4_OT Last Started 2016-11-02 08:43 Status RUNNING
INTEGRATED
Checkpoint Lag 00:00:00 (updated 00:00:02 ago)
Process ID 7212
Log Read Checkpoint File /gg/app/ggadmin/product/12.1.2.1.0/dirdat/replicate/pdot/r4000020
2016-11-02 08:51:11.956186 RBA 535238535
GGSCI (ora-bi-p-5.va2.b2c.nike.com) 3> sh ls -lrt /gg/app/ggadmin/product/12.1.2.1.0/dirdat/replicate/pdot/r4*
-rw-r-----. 1 ggadmin oinstall 1023999938 Oct 31 16:41 /gg/app/ggadmin/product/12.1.2.1.0/dirdat/replicate/pdot/r4000018
-rw-r-----. 1 ggadmin oinstall 1023999769 Nov 1 18:53 /gg/app/ggadmin/product/12.1.2.1.0/dirdat/replicate/pdot/r4000019
-rw-r-----. 1 ggadmin oinstall 535251047 Nov 2 03:57 /gg/app/ggadmin/product/12.1.2.1.0/dirdat/replicate/pdot/r4000020
-rw-r-----. 1 ggadmin oinstall 204917668 Nov 2 05:23 /gg/app/ggadmin/product/12.1.2.1.0/dirdat/replicate/pdot/r4000346
-rw-r-----. 1 ggadmin oinstall 1264 Nov 2 05:23 /gg/app/ggadmin/product/12.1.2.1.0/dirdat/replicate/pdot/r4000347
-rw-r-----. 1 ggadmin oinstall 59060543 Nov 2 08:49 /gg/app/ggadmin/product/12.1.2.1.0/dirdat/replicate/pdot/r4000348
很明显序号seqno就不连续了,为什么会出现这种状况(先不考虑了,先修好)
于是alter R4_OT extseqno 0346 extrba 0
当然后面ogg alter之后还出现了一些问题,也顺利解决了,这里就略过不谈了。
最主要的其实还是想分享下这个思考的过程:
收到告警-》ogg没看出问题-》数据库的ogg user也没在跑r4_ot相关的事务,但就是apply_process有lag-》通过strace/pstack顺利troubleshooting到问题原因,从而解决问题。
Keep thinking~~
=============ENDED============================
oradebug/strace/pstack等分析数据库性能问题系列一的更多相关文章
- 使用strace+pstack利器分析程序性能
引言 有时我们需要对程序进行优化.减少程序响应时间.除了一段段地对代码进行时间复杂度分析,我们还有更便捷的方法吗? 若能直接找到影响程序运行时间的函数调用,再有针对地对相关函数进行代码分析和优化,那相 ...
- 如何使用strace+pstack利器分析程序性能
http://www.cnblogs.com/bangerlee/archive/2012/04/30/2476190.html
- MSSql-SP_who分析数据库性能
https://blog.csdn.net/xiaoxu0123/article/details/5757640 https://www.cnblogs.com/kelelipeng/p/104959 ...
- linux 调试利器gdb, strace, pstack, pstree, lsof
1) 如何使用strace+pstack利器分析程序性能? http://www.cnblogs.com/bangerlee/archive/2012/04/30/2476190.html 此文有详细 ...
- 文献综述九:Oracle数据库性能模型的研究
一.基本信息 标题:Oracle数据库性能模型的研究 时间:2018 出版源:数字技术与应用 文件分类:对框架的研究 二.研究背景 帮助运维人员分析数据库性能,发现问题,指导调优. 三.具体内容 文献 ...
- SQL中利用DMV进行数据库性能分析
相信朋友对SQL Server性能调优相关的知识或多或少都有一些了解.虽然说现在NOSQL相关的技术非常的火热,但是RMDB(关系型数据库)与NOSQL是并存的,并且适用在各种的项目中.在一般的企业级 ...
- 使用pgstatspack分析PostgreSQL数据库性能
pgstatspack [root@test01 soft]# wget http://pgfoundry.org/frs/download.php/3151/pgstatspack_version_ ...
- SQLServer中的页如何影响数据库性能 (转)
无论是哪一个数据库,如果要对数据库的性能进行优化,那么必须要了解数据库内部的存储结构.否则的话,很多数据库的优化工作无法展开.对于对于数据库管理员来说,虽然学习数据库的内存存储结构比较单调,但是却是我 ...
- 转载:SqlServer数据库性能优化详解
本文转载自:http://blog.csdn.net/andylaudotnet/article/details/1763573 性能调节的目的是通过将网络流通.磁盘 I/O 和 CPU 时间减到最小 ...
随机推荐
- 附录A 编译安装Hadoop
A.1 编译Hadoop A.1.1 搭建环境 第一步安装并设置maven 1. 下载maven安装包 建议安装3.0以上版本(由于Spark2.0编译要求Maven3.3.9及以上版本),本次 ...
- javascript URL实现简易书签
简介 在HTML中,我们可以将js嵌入到script标签中,可以嵌入到行内代码中,也可以嵌入到src(href)中. 后者称作javascript URL.该方式的URL格式固定:javascript ...
- 【Java基础】并发
Num1:同步访问共享的可变数据 关键字Synchronized可以保证在同一时刻,只有一个线程可以执行某一个方法,或者某一个代码块.. 同步不仅仅理解为互斥的方式,如果没有同步,一个线程的变化就不能 ...
- effective java 读后感
think in java , effective java 这两本书一直都在java的生态圈中经久不衰.本来想着先翻过 think in java 这本大山,但是读到一半就放弃了.过长的篇幅,让 ...
- oracle实用sql之将逗号分割的字符串分割多个列
select regexp_substr('a,b,c,','[^,]+',1,rownum) from dual connect by rownum<=length(regexp_replac ...
- SharePoint创建web application出现“The password supplied with the username was not correct”错误的解决方法
平台环境 Windows Server 2012 R2 Standard, SharePoint Server 2010, Microsoft SQL Server 2012 (SP1) 问题描述 在 ...
- eclipse报错:Failed to load the JNI shared library
Eclipse运行时提示“Failed to load the JNI shared library /Java/jre6/bin/client/jvm.dll”的一个解决方案 因为 Eclipse ...
- 又一个半成品库 weblog rpc client
我基本上属于半成品专业户,去看我的github就知道. 下午又撸了一个weblog rpc client库,而这又一次证明了一个有技术但没有产品能力的程序员是没有卵用的. 因为当做好了库的雏形,但与具 ...
- SQL性能优化常见措施(Lock wait timeout exceeded)
SQL性能优化常见措施 目 录 1.mysql中explain命令使用 2.mysql中mysqldumpslow的使用 3.mysql中修改my.ini配置文件记录日志 4.mysql中如何加索引 ...
- JVM垃圾回收(GC)原理
一.基本垃圾回收算法 1.引用计数(Reference Counting) 比较古老的回收算法.原理是此对象有一个引用则增加一个引用计数,删除一个引用则较少一个引用计数.垃圾回收时,只回收引用计数为0 ...