生产上数据库大量的latch free 导致的CPU资源耗尽的问题的解决，latchfree
中午的时候，我们生产上的某个数据库，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 GETS MISSES SLEEPS ---------------------------------------------------------------- ---------- ---------- ---------- simulator hash latch 4827860212 135426899 10890947 cache buffers chains 1619822817 2850976006 4747728 gc element 4660052091 25748270 175073 resmgr:schema config 91872524 153968 95708 ges resource hash list 174151449 1070556 55459 Real-time plan statistics latch 40953155 651496 44527 call allocation 3301878 265908 43501 row cache objects 336300485 4970324 19366
这个simulator hash latch已经是显著的latch部分
eagle在他的网站上有篇文章讲到了关于simulator这个
http://www.eygle.com/archives/2011/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的竞争：
Bug 5918642 Heavy latch contention with DB_CACHE_ADVICE on
This note gives a brief overview of bug 5918642.
The content was last updated on: 01-APR-2008
Click here for details of each of the sections below.
Affects:
Product (Component) Oracle Server (Rdbms) Range of versions believed to be affected Versions < 11.2 Versions confirmed as being affected
- 10.2.0.3
Platforms affected Generic (all / most platforms affected) Fixed:
This issue is fixed in
- 11.2 (Future Release)
- 10.2.0.4 (Server Patch Set)
- 11.1.0.7 (Server Patch Set)
Symptoms:
Related To:
- Latch Contention
- Waits for "latch free"
- Performance Monitoring
- DB_CACHE_ADVICE
Description
High simulator lru latch contention can occur when db_cache_advice is set to ON if there is a large buffer cache. Workaround: Set db_cache_advice to OFF
当然，这个只是治标不治本的做法，这个是显现的表象的问题，根源的问题还是这个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,
P935.ORGORDERID,
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 P936
WHERE P936.Ordercode = 936
and P936.Orderstatus = 0
AND <span style="color:#ff0000;">P936.Relatedsequenceid = P935.SEQUENCEID</span>) > 0 THEN
0
ELSE
1
END AS SHARINGRESULT,
CASE D935.Dealcode
WHEN 210 then
14
else
D935.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 PAYMENTORDER P935,
PAYMENTORDER P936,
DEAL D935,
GATEWAYORDER G935,
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 = :1
UNION
SELECT P938.SEQUENCEID,
P935.SEQUENCEID FA_SEQUENCEID,
P938.ORDERID,
P938.ORGORDERID,
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语句，问题解决
以下是方案1：
现象：机器正在调试或允许IIS时,被异常中断服务(比如停电)，然后再次IIS运行页面时，CPU资源占用100%，即使重新启动也无效。
原因：发生中断时，IIS会写异常日志，但是此时写入了乱码，造成IIS一直写日志的死循环，耗尽了系统资源。找到系统路径\System32\Logfiles\W3SVC1 下当天的错误日志文件，即可看到以上内容。
解决：删除 系统路径\System32\Logfiles\W3SVC1 下当天的错误日志文件，如：ex060904.log，然后重新启动IIS即可。以下是方案2：
环境：win2003server+IIs+ASP+MSSQL
现象：每隔一段时间（不定，有时几分钟，有时半小时）出现一次网站打开非常缓慢，甚至有时会出现超时打不开站点，此时查看服务器端的进程，CPU占用率达到100%，其中w3wp占用70~80%，SQL占用20~30%。所有服务器端的操作也变得缓慢
初期解决方法：每次现象出现时，立即登录服务器直接结束w3wp进程或重启IIS服务，平均每天约十次操作，由于服务器存放于远程机房，所有操作都是远程控制进行，有时会因此出现远程无法连接登录的情况，只能通过电话通知机房管理人员重启服务器解决，此过程导致用户抱怨不断
经过网上查阅资料，发现此类现象多数由于网页代码不合理所致，以下情况会导致此类现象发生：
1、代码中多处使用application、seesion等服务器缓存，导致服务器资料过度占用；
2、代码有不合理语法，死循环等；
3、数据库损坏，尤其是ACCESS数据库；
4、装过多第三方软件或插件，与IIS或网页功能代码冲突。
第一阶段排查：根据查阅到的参考资料逐项分析
1、服务器上所有站点代码均为公司设计人员自行编写，可证实并无过多调用服务器缓存语法（排除）
2、代码是否存在不合理语法（不确定）
3、根据情况来看，IIS进程占用率升高时，SQL占用率同时升高，应为SQL数据库的站点，根据现象判断，库或表应该正常，估计是数据方面可能有误；（不确定）
4、服务器端除了基本的系统服务，防杀毒及网站运作必备服务之外，并无多余第三方软件，机率不大（排除）。
经过以上分析判断，将不确定项连起来得出的结论是：某个采用了SQL数据库的网站网页代码存在不合理语法，导致IIS和SQL进程CPU占用率过高。
第二阶段排查：
确定范围，接着继续把范围缩小。
由于服务器上采用SQL数据库的站点并不多，便于建立独立进程ID来观察，将所有采用SQL数据库的站点在IIS管理器中分别建立独立的应用程序池，然后通过CMD界面输入：iisapp -a 命今查看并记录下各IIS池的进程ID号，通过多次现象重现时的观察，有个IIS进程ID是导致此次问题的罪魁祸首。
以下是方案3：
在IIS6下，经常出现w3wp.exe的内存及CPU占用不能及时释放，从而导致服务器响应速度很慢。
解决内存占用过多，可以做以下配置：
1、在IIS中对每个网站进行单独的应用程序池配置。即互相之间不影响。
2、设置应用程序池的回收时间，默认为1720小时，可以根据情况修改。再设置当内存占用超过多少（如500M），就自动回收内存。
解决CPU占用过多：
1、在IIS中对每个网站进行单独的应用程序池配置。即互相之间不影响。
2、设置应用程序池的CPU监视，不超过25%（服务器为4CPU），每分钟刷新，超过限制时关闭。
根据w3wp取得......余下全文>>
经常用电脑的朋友一定没有少碰到蓝屏，那张冰凉的蓝面孔真的很令人讨厌。那么蓝屏到底是怎么产生的呢？
我们可以从软、硬两方面来解释蓝屏现象产生的原因。从硬件方面来说，超频过度是导致蓝屏的一个主要原因。过度超频，由于进行了超载运算，造成内部运算过多，使CPU过热，从而导致系统运算错误。如果既想超频，又不想出现蓝屏，只有做好散热措施了，换个强力风扇，再加上一些硅胶之类的散热材料会好许多。另外，适量超频或干脆不超频也是解决的办法之一。要稳定还是要更高的速度就看你自己的抉择了。
如果内存条发生物理损坏或者内存与其它硬件不兼容，也会产生蓝屏。此时的解决办法只有换内存这一个方法了。
如果你留意过，你会发现光驱在读盘时被非正常打开也会导致蓝屏。这个问题不影响系统正常动作，只要再弹入光盘或按ESC键就可以。
由于硬件产生蓝屏的另外一个常见原因是系统硬件冲突所致。实践中经常遇到的是声卡或显示卡的设置冲突。在“控制面板”→“系统”→“设备管理”中检查是否存在带有黄色问号或感叹号的设备，如存在可试着先将其删除，并重新启动电脑，由Windows自动调整，一般可以解决问题。若还不行，可手工进行调整或升级相应的驱动程序。
劣质零部件是电脑出现蓝屏现象的另外一个罪魁祸首。少数不法商人在给顾客组装兼容机时，使用质量低劣的主板、内存，有的甚至出售冒牌主板和旧的CPU、内存，这样就会使机器在运行时很不稳定，发生死机也就在所难免。因此，用户购机时应该有这方面的戒心，可请比较熟悉的朋友帮助挑选，并可以用一些较新的工具软件测试电脑，长时间连续考机(如72小时)，以及争取尽量长的保修时间等。
从软件方面看，遭到病毒或黑客攻击、注册表中存在错误或损坏、启动时加载程序过多、版本冲突、虚拟内存不足造成系统多任务运算错误、动态链接库文件丢失、过多的字体文件、加载的计划任务过多、系统资源产生冲突或资源耗尽都会产生蓝屏。另外，产生软硬件冲突也很容易出现蓝屏。明白了蓝屏出现的“软”原因，就可对症下药了。
一、先来看看消灭蓝屏的怪招。
Windows出错时会出现蓝屏，大家对此可能都已经习以为常了，但可不可以不是“蓝”屏，比方说换为“红”屏、“绿”屏可以不？当然可以！方法如下：
1.首先要出现蓝屏错误画面：你只要从A盘或光驱复制一个文件到你的硬盘上（注意这个文件不能太小），在复制过程中将软盘或光盘取出来，Windows马上就会变脸——蓝屏立即就会出现，这时按Esc回到Windows状态。
2.点击“开始”→“运行”，在弹出的对话框中输入msconfig.exe，回车，就会调出系统配置实用程序。现在，点击其中的“System.ini”标签。
3.找到[386Enh]项，点击“新建”，在其下新增一字串“MessageBackColor=”（注意输入时没有引号），等号后面是16进制数字0～F，可以随意填，它是用来表示错误画面的背景颜色。
4.同样的方法，在[386Enh]下再新增一字串“MessageTextColor=”（注意输入时没有引号），等号后面是16进制数字0～F，可以随意填，它是用来表示错误画面的文字颜色。
5.现在，重新启动电脑，来做个试验看成功没有：重复步骤1，看看是不是已经告别蓝屏了？大功告成！
说明：本方法并没有真正改变脆弱地Windows的稳定性，只是通过我们的劳动，改变了Windows出错时画面的背景颜色和文字颜色。从这个角度来说，这也算是一种DIY行为哦。
二、及时关闭暂时不用的程序
一些程序即使过后要用，也可先关闭以节省资源。......余下全文>>