MYSQL教程之Oracle诊断案例-SGA与Swap之二

人力成本上的节省，MySQL的用户Spacemonkey实验室的首席执行官MitchPirtle如此表示：“维护MySQL使得你不需要一个年薪15万美元的DBA。oracle




link:

http://www.eygle.com/case/sga2.htm

案例形貌:

这是一个年夜型临盆体系
成绩呈现时体系累计大批用户历程
用户哀求得不到实时呼应，新的历程不休实验创建毗连
毗连数很快被用完

数据库版本:9.2.0.3
操纵体系:Solaris8



1.反省alert文件

日记中纪录以下毛病信息，申明磁盘异步IO呈现成绩:





WARNING:aiowaittimedout2times
TueAug2615:33:322003
WARNING:aiowaittimedout2times
TueAug2615:33:342003
WARNING:aiowaittimedout2times
TueAug2615:33:362003
WARNING:aiowaittimedout2times
TueAug2615:33:382003
WARNING:aiowaittimedout2times
TueAug2615:33:432003
WARNING:aiowaittimedout1times
TueAug2615:33:462003
WARNING:aiowaittimedout1times
TueAug2615:33:492003
WARNING:aiowaittimedout1times
TueAug2615:33:512003
WARNING:aiowaittimedout1times
TueAug2615:33:522003
WARNING:aiowaittimedout1times
TueAug2615:33:532003
WARNING:aiowaittimedout1times
.............


我们晓得在SUN的某些版本上异步IO存在成绩
而异步IO缺省是翻开的





SQL>showparameterdisk_a

NAMETYPEVALUE
-----------------------------------------------------------------------------
disk_asynch_iobooleanTRUE



针对此成绩，我们停用了数据库的异步IO写进。

2.共享内存成绩

alert文件中还纪录了以下毛病信息:




TueAug2621:37:402003
WARNING:EINVALcreatingsegmentofsize0x0000000190400000
fixshmparametersin/etc/systemorequivalent





该信息申明内核参数设置太小大概和SGA不婚配

我们反省system设置文件





$cat/etc/system
.......................
setshmsys:shminfo_shmmax=4096000000
setshmsys:shminfo_shmmin=1
setshmsys:shminfo_shmmni=200
setshmsys:shminfo_shmseg=200
setsemsys:seminfo_semmap=1024
setsemsys:seminfo_semmni=2048
setsemsys:seminfo_semmns=2048
setsemsys:seminfo_semmnu=2048
setsemsys:seminfo_semume=200
setsemsys:seminfo_semmsl=2048





我们发明最年夜共享内存设置唯一4G



3.反省SGA设置




SQL*Plus:Release9.2.0.3.0-Productionon礼拜二8月2621:46:352003

Copyright(c)1982,2002,OracleCorporation.Allrightsreserved.


Connectedto:
Oracle9iEnterpriseEditionRelease9.2.0.3.0-64bitProduction
WiththePartitioning,OLAPandOracleDataMiningoptions
JServerRelease9.2.0.3.0-Production

SQL>showsga

TotalSystemGlobalArea6695660272bytes
FixedSize740080bytes
VariableSize2399141888bytes
DatabaseBuffers4294967296bytes
RedoBuffers811008bytes






我们发明SGA设置靠近7G，这也就是步骤2中毛病提醒呈现的缘故原由


4.互换区成绩

我们用top工具反省体系运转情况





#/usr/local/bin/top

lastpid:16899;loadaverages:0.82,0.81,0.8321:49:05
1230processes:1228sleeping,1running,1oncpu
CPUstates:50.1%idle,7.4%user,8.6%kernel,33.9%iowait,0.0%swap
Memory:8192Mreal,118Mfree,12Gswapinuse,11Gswapfree

PIDUSERNAMETHRPRINICESIZERESSTATETIMECPUCOMMAND
15751oracle114406456M6408Msleep0:020.49%oracle
15725oracle115806458M6410Msleep0:020.46%oracle
251root124807096K1944Ksleep126:000.45%picld
16540oracle115806458M6411Msleep0:010.45%oracle
16766root14303744K2248Kcpu/10:010.41%top
16408oracle115806457M6410Msleep0:010.34%oracle
15989oracle115806458M6409Msleep0:010.34%oracle
15919oracle115806457M6409Msleep0:020.30%oracle
16404oracle115806457M6409Msleep0:000.28%oracle
16327oracle115506457M6410Msleep0:000.27%oracle
14870oracle115806457M6412Msleep0:050.24%oracle
16851oracle113506457M6411Msleep0:000.22%oracle
16467oracle115806457M6409Msleep0:000.21%oracle
16163oracle115806457M6408Msleep0:030.21%oracle
15159oracle115806457M6408Msleep0:050.21%oracle





Memory:8192Mreal,118Mfree,12Gswapinuse,11Gswapfree

我们发明体系唯一8GRAM,物理内存唯一118M可用
如今SWAP区利用了12G

我们开端作出以下判别:

SGA设置过年夜(快要7G)招致运转时发生大批互换

大批SWAP互换进而激发磁查询题
这也就应当是我们第一步看到
WARNING:aiowaittimedout1times
的缘故原由

大批互换招致数据库功能急剧下落
进而招致用户哀求得不到疾速呼应，梗塞、积累，直至数据库得到呼应





5.办理计划

此成绩次要是因为SGA设置不妥引发，我们即刻减少了SGA设置:

SQL>showsga

TotalSystemGlobalArea3591870848bytes
FixedSize735616bytes
VariableSize1442840576bytes
DatabaseBuffers2147483648bytes
RedoBuffers811008bytes

此时，数据库削减了互换,到达了不乱运转,用户哀求能够失掉疾速呼应。

成绩办理完成.



6.体系形态

调剂后体系运转情况:






$toplastpid:12745;loadaverages:0.46,0.79,0.6522:22:49228processes:227sleeping,1oncpuCPUstates:92.3%idle,5.0%user,1.6%kernel,1.1%iowait,0.0%swapMemory:8192Mreal,3817Mfree,4015Mswapinuse,15GswapfreePIDUSERNAMETHRPRINICESIZERESSTATETIMECPUCOMMAND12610oracle15103511M22Msleep0:041.96%oracle12595oracle14803511M22Msleep0:030.92%oracle12630oracle13803511M21Msleep0:010.84%oracle12614oracle14603511M22Msleep0:010.64%oracle12620oracle15803511M22Msleep0:010.53%oracle12709oracle14803511M21Msleep0:000.45%oracle265root113807032K1920Ksleep3:160.42%picld12729oracle1003511M20Msleep0:000.26%oracle12741oracle15802768K1760Kcpu/30:000.19%top12745oracle14403506M16Msleep0:000.17%oracle12711oracle14803506M16Msleep0:000.11%oracle12738oracle14303506M16Msleep0:000.06%oracle7606oracle145017M6928Ksleep0:070.05%tnslsnr12721oracle13403506M16Msleep0:000.05%oracle12723oracle15303506M16Msleep0:000.05%oracle

该体系调剂完今后，一向不乱运转至今.



一点总结:

这个案例和后面我提到的别的一个极为类似
一样都是SGA设置不妥引发的数据库成绩

自己其实不庞大
这一类成绩应当在数据库计划和建立阶段就制止失落.

当时，该成绩对我更像是个心思测试
当一切老板都站在你面前的时分，你可否冷清疾速的找到并办理成绩.

关于SUN上的aiowaittimedout有良多总情形及诱因
我前面另有响应的案例申明.

-Eygle




任何规模的组织都可能受益于外包服务，并在一个标准化和优化的平台上统一其数据库管理任务。基于其本身的特性，DBaaS提供了敏捷和高效的数据库服务，它可以支持多变的需求。

我个人认为就是孜孜不懈的学习

这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高，但是相对映射到数据表中效率还是提高了很多。我做过试验，在我的实验环境中会比映射到表中提高30%左右的效率。

对递归类的树遍历很有帮助。个人感觉这个真是太棒了！阅读清晰，非常有时代感。

我是一个ERP初学者，对于前台运用基本熟悉，但对于后台SQLServer的运用一点也不懂，特想学习下相关资料。至少懂得一些基本的运用。希望各位能给于建议，小弟再谢过！

是否碎片会引发效率问题？这都是需要进一步探讨的东西。varbinary(max)代替image也让SQLServer的字段类型更加简洁统一。

对一张百万级别的表建游标，同时又没有什么过滤条件，取得游标效率是如果直接SQL查询百万条数据；如果再对每条记录做处理，耗时将更长。

我们学到了什么？思考问题的时候从表的角度来思考问

每天坚持做不一样的是，认真做笔录，定时复习。一个月你就可以有一定的收获。当然如果你想在sql方面有一定的造诣，你少不了需要看很多很多的书籍了。