数据库|mysql教程
生产上,数据库,大量,latchfree,导致,CPU,资源
数据库-mysql教程
c 数据库源码之家,ubuntu 电池不充电,tomcat部署服务器上,人人网爬虫登录,php网站外包收费标准教程,seo9800lzw
中午的时候，我们生产上的某个数据库，cpu一直居高不下 通过如下的sql语句，我们查看当时数据库的等待，争用的情况： select s.SID, s.SERIAL#, kill -9 || p.SPID, s.MACHINE, s.OSUSER, s.PROGRAM, s.USERNAME, s.last_call_et, a.SQL_ID, s.LOGON_TIME, a
互联网站源码,vscode有手机版汉化,ubuntu 开启ssh,iis 代理tomcat,yii sqlite,网页设计尺寸1440,php 读取数据库输出,国外服务器 备案,wp支付宝免签插件,前端hi框架,原地爬虫,cas php,株洲seo排名,springboot租房失败,phpwind 模板标签,网站后台添加不了图片,网页设计源码下载,discuz 发帖模板,zencart后台管理,js 定位页面底部,开源 仓库管理系统,建站小说采集程序上传教程lzw
vlc易语言源码,vscode的编译前端页面,Ubuntu的gui,tomcat管理界面登录,论文爬虫技术,百度网盘直链 php,井冈山页面seo优化,钻石交易网站源码,影视文化公司官网模板lzw
中午的时候，我们生产上的某个数据库，cpu一直居高不下
通过如下的sql语句，我们查看当时数据库的等待，争用的情况：
select s.SID, s.SERIAL#, kill -9 || p.SPID, s.MACHINE, s.OSUSER, s.PROGRAM, s.USERNAME, s.last_call_et, a.SQL_ID, s.LOGON_TIME, a.SQL_TEXT, a.SQL_FULLTEXT, w.EVENT, a.DISK_READS, a.BUFFER_GETS from v$process p, v$session s, v$sqlarea a, v$session_wait w where p.ADDR = s.PADDR and s.SQL_ID = a.sql_id and s.sid = w.SID and s.STATUS = ACTIVE order by s.last_call_et desc;
从event可以看到，是latch 的争用导致的原因
通过如果的sql，查看是什么样的latch
select * from v$session_wait where event like latch free;
P2就是 这个latch的name，通过v$latchname这个视图就可以知道哪个具体的latch
1:45:55 PM SQL> select * from v$latchname where latch#=164;LATCH# NAME HASH---------- ---------------------------------------------------------------- ---------- 164 simulator hash latch 2233208730
查看latch的历史情况
2:11:59 PM SQL> select name,gets,misses,sleeps from v$latch where sleeps >0 order by sleeps desc; NAME GETSMISSESSLEEPS---------------------------------------------------------------- ---------- ---------- ----------simulator hash latch 4827860212 135426899 10890947cache buffers chains 1619822817 2850976006 4747728gc element 4660052091 25748270175073resmgr:schema config9187252415396895708ges resource hash list 174151449 107055655459Real-time plan statistics latch 4095315565149644527call allocation330187826590843501row cache objects 336300485 497032419366
这个simulator hash latch已经是显著的latch部分
eagle在他的网站上有篇文章讲到了关于simulator这个
/archives//11/simulator_lru_latch.html
simulator意为模拟，也就是说当Oracle在内存中进行数据块处理时，实际上还会在预先分配的Buffer中进行相关信息记录，如DBA信息，当数据块被老化之后，下次读取时，如果请求的数据在Simulator内存中存在，则认为继续缓存该数据块是有意义的，通过监控并模拟统计这些操作，并对计算结果加权运算，就可以实现对于内存的调整建议。
在模拟过程中，也是通过Latch来实现的，相关的Latch就有 simulator lru latch 、 simulator hash latch等.
就Buffer Cache而言，如果系统中该类争用严重，则可以考虑关闭db_cache_advice，消除这部分内部操作对于性能的影响。
以下是一个相关BUG，在该Bug中，由于DB_CACHE_ADVICE的开启导致了严重的simulator lru latch的竞争：
Fixed:
当然，这个只是治标不治本的做法，这个是显现的表象的问题，根源的问题还是这个sql语句有问题
当一个数据块读入到sga中时，该块的块头(buffer header)会放置在一个hash bucket的链表(hash chain)中。该内存结构由一系列cache buffers chains子latch保护（又名hash latch或者cbc latch）。对Buffer cache中的块，要select或者update、insert,delete等，都得先获得cache buffers chains子latch，以保证对chain的排他访问。若在过程中发生争用，就会等待latch:cache buffers
chains事件。
产生原因： 1. 低效率的SQL语句（主要体现在逻辑读过高） 在某些环境中，应用程序打开执行相同的低效率SQL语句的多个并发会话，这些SQL语句都设法得到相同的数据集，每次执行都带有高 BUFFER_GETS(逻辑读取)的SQL语句是主要的原因。相反，较小的逻辑读意味着较少的latch get操作，从而减少锁存器争用并改善性能。注意v$sql中BUFFER_GETS/EXECUTIONS大的语句。 2.Hot block 当多个会话重复访问一个或多个由同一个子cache buffers chains锁存器保护的块时，热块就会产生。当多个会话争用cache
buffers chains子锁存器时，就会出现这个等待事件。有时就算调优了SQL，但多个会话同时执行此SQL，那怕只是扫描特定少数块，也是也会出现HOT BLOCK的。
SELECT P935.SEQUENCEID, null FA_SEQUENCEID, P935.ORDERID, ORDERID, P935.PRODUCTNAME, P935.PRODUCTNUM, P935.ORDERTIME, P935.LASTUPDATETIME, P935.ORDERSTATUS, P935.MEMO, 935 orderCode, P935.PAYERACCTCODE, P935.PAYERACCTTYPE, P935.PAYEEACCTCODE PLATACCTCODE, P935.PAYEEACCTTYPE PLATACCTTYPE, P936.PAYEEACCTCODE, P936.PAYEEACCTTYPE, EXT935.PAYER_DISPLAYNAME, EXT935.PAYER_NAME, EXT935.PAYER_IDC, EXT935.PAYER_MEMBERTYPE, EXT936.PAYER_DISPLAYNAME PLAT_DISPLAYNAME, EXT936.SUBMITNAME PLAT_NAME, EXT936.PAYER_IDC PLAT_IDC, EXT936.PAYER_MEMBERTYPE PLAT_MEMBERTYPE, EXT936.PAYEE_DISPLAYNAME, EXT936.PAYEE_NAME, EXT936.PAYEE_IDC, EXT936.PAYEE_MEMBERTYPE, P935.PAYEEDISPLAYNAME WEBSITENAME, CASE WHEN (SELECT count(*) FROM PAYMENTORDER P936WHERE P936.Ordercode = 936 and P936.Orderstatus = 0 AND P936.Relatedsequenceid = P935.SEQUENCEID) > 0 THEN0 ELSE1 END AS SHARINGRESULT, CASE D935.Dealcode WHEN 210 then14 elseD935.DEALTYPE end PAYMETHOD, D935.DEALAMOUNT, G935.EXT1, G935.Ext2, G935.PAYERCONTACTTYPE, G935.PAYERCONTACT, NVL(D935.PAYEEFEE, 0) PAYEEFEE, NVL(D935.PAYERFEE, 0) PAYERFEE, nvl(MS936.PAYEEFEE, 0) PLATFORMFEE, P935.VERSION FROM PAYMENTORDERP935, PAYMENTORDERP936, DEAL D935, GATEWAYORDERG935, MSGATEWAYSHARINGORDER MS936, PAYMENTORDEREXT EXT935, PAYMENTORDEREXT EXT936 WHERE P936.ORDERCODE = 936 AND P935.ORDERCODE = 935 AND P936.RELATEDSEQUENCEID = to_char(P935.SEQUENCEID) AND P935.SEQUENCEID = G935.SEQUENCEID(+) AND P935.SEQUENCEID = D935.ORDERSEQID(+) AND P935.SEQUENCEID = EXT935.ORDERSEQID(+) AND P936.SEQUENCEID = EXT936.ORDERSEQID(+) AND P936.SEQUENCEID = MS936.SEQUENCEID(+) AND MS936.SHARINGTYPE = 1 AND P935.SEQUENCEID = :1UNIONSELECT P938.SEQUENCEID, P935.SEQUENCEID FA_SEQUENCEID, P938.ORDERID, ORDERID, P935.PRODUCTNAME, P935.PRODUCTNUM, P938.ORDERTIME, P938.LASTUPDATETIME, P938.ORDERSTATUS, P938.MEMO, 938 orderCode, P938.PAYERACCTCODE, P938.PAYERACCTTYPE, P938.PAYEEACCTCODE PLATACCTCODE, P938.PAYEEACCTTYPE PLATACCTTYPE, P938.PAYEEACCTCODE, P938.PAYEEACCTTYPE, EXT938.PAYER_DISPLAYNAME, EXT938.PAYER_NAME, EXT938.PAYER_IDC, EXT938.PAYER_MEMBERTYPE, EXT938.PAYEE_DISPLAYNAME PLAT_DISPLAYNAME, EXT938.SUBMITNAME PLAT_NAME, EXT938.PAYEE_IDC PLAT_IDC, EXT938.PAYEE_MEMBERTYPE PLAT_MEMBERTYPE, EXT938.PAYEE_DISPLAYNAME, EXT938.PAYEE_NAME, EXT938.PAYEE_IDC, EXT938.PAYEE_MEMBERTYPE, P935.PAYEEDISPLAYNAME WEBSITENAME, null SHARINGRESULT, D938.DEALTYPE PAYMETHOD, D938.DEALAMOUNT, G935.EXT1, G935.Ext2, G935.PAYERCONTACTTYPE, G935.PAYERCONTACT, NVL(D938.PAYEEFEE, 0) PAYEEFEE, NVL(D938.PAYERFEE, 0) PAYERFEE, 0 PLATFORMFEE, P935.VERSION FROM PAYMENTORDER P935, PAYMENTORDER P938, DEAL D938, GATEWAYORDER G935, PAYMENTORDEREXT EXT938 WHERE P935.ORDERCODE = 935 AND P938.ORDERCODE = 938 AND P938.RELATEDSEQUENCEID = to_char(P935.SEQUENCEID) AND P935.SEQUENCEID = G935.SEQUENCEID(+) AND P938.SEQUENCEID = D938.ORDERSEQID(+) AND P938.SEQUENCEID = EXT938.ORDERSEQID(+) AND P935.SEQUENCEID = :2
分析上面的sql，上面标红的地方，等号左边是varchar2的数据类型，括号右边是number的数据类型，会导致数据类型的隐式转换，造成极大的性能影响
联系研发，修改了sql语句，问题解决
