MYSQL网站制作之Oracle数据库诊断案例-redo log日记组处...

这些过程被存储和运行在数据库服务器上，以减少在客户端的处理过程，从而最大限度地提高了处理能力，因为通常情况下数据库服务器会运行地更快。存储过程并不是MySQL独有的功能，但是这个最近新增加的功能使得这个数据库比以前更具吸引力了。oracle|数据|数据库平台:SunOS5.8Generic_108528-23sun4usparcSUNW,Ultra-Enterprise
数据库:8.1.5.0.0
症状:呼应迟缓，使用哀求已没法前往
上岸数据库,发明redo日记组除current外都处于active形态
oracle:/oracle/oracle8>sqlplus"/assysdba"
SQL*Plus:Release8.1.5.0.0-ProductiononThuJun2318:56:062005
(c)Copyright1999OracleCorporation.Allrightsreserved.

Connectedto:
Oracle8iEnterpriseEditionRelease8.1.5.0.0-Production
WiththePartitioningandJavaoptions
PL/SQLRelease8.1.5.0.0-Production
SQL>select*fromv$log;
GROUP#THREAD#SEQUENCE#BYTESMEMBERSARCSTATUSFIRST_CHANGE#FIRST_TIM
-------------------------------------------------------------------------------------------
11520403314572801NOACTIVE1.3861E+1023-JUN-05
21520404314572801NOACTIVE1.3861E+1023-JUN-05
31520405314572801NOACTIVE1.3861E+1023-JUN-05
41520406314572801NOCURRENT1.3861E+1023-JUN-05
51520398314572801NOACTIVE1.3860E+1023-JUN-05
61520399314572801NOACTIVE1.3860E+1023-JUN-05
715204001048576001NOACTIVE1.3860E+1023-JUN-05
815204011048576001NOACTIVE1.3860E+1023-JUN-05
915204021048576001NOACTIVE1.3861E+1023-JUN-05
9rowsselected.
SQL>/
GROUP#THREAD#SEQUENCE#BYTESMEMBERSARCSTATUSFIRST_CHANGE#FIRST_TIM
-------------------------------------------------------------------------------------------
11520403314572801NOACTIVE1.3861E+1023-JUN-05
21520404314572801NOACTIVE1.3861E+1023-JUN-05
31520405314572801NOACTIVE1.3861E+1023-JUN-05
41520406314572801NOCURRENT1.3861E+1023-JUN-05
51520398314572801NOACTIVE1.3860E+1023-JUN-05
61520399314572801NOACTIVE1.3860E+1023-JUN-05
715204001048576001NOACTIVE1.3860E+1023-JUN-05
815204011048576001NOACTIVE1.3860E+1023-JUN-05
915204021048576001NOACTIVE1.3861E+1023-JUN-05
9rowsselected.
假如日记都处于active形态，那末明显DBWR的写已没法跟上logswitch触发的反省点。
接上去让我们反省一下DBWR的忙碌水平:
SQL>!
oracle:/oracle/oracle8>ps-ef|grepora_
oracle227310Mar31?57:40ora_smon_hysms02
oracle226610Mar31?811:42ora_dbw0_hysms02
oracle2264116Mar31?16999:57ora_pmon_hysms02
oracle226810Mar31?1649:07ora_lgwr_hysms02
oracle227910Mar31?8:09ora_snp1_hysms02
oracle228110Mar31?4:22ora_snp2_hysms02
oracle228510Mar31?9:40ora_snp4_hysms02
oracle227110Mar31?15:57ora_ckpt_hysms02
oracle228310Mar31?5:37ora_snp3_hysms02
oracle227710Mar31?5:58ora_snp0_hysms02
oracle228910Mar31?0:00ora_d000_hysms02
oracle228710Mar31?0:00ora_s000_hysms02
oracle227510Mar31?0:04ora_reco_hysms02
oracle2102321012018:52:59pts/650:00grepora_
DBWR的历程号是2266。
利用Top命令察看一下:
oracle:/oracle/oracle8>top
lastpid:21145;loadaverages:3.38,3.45,3.6718:53:38
725processes:711sleeping,1running,10zombie,3oncpu
CPUstates:35.2%idle,40.1%user,9.4%kernel,15.4%iowait,0.0%swap
Memory:3072Mreal,286Mfree,3120Mswapinuse,1146Mswapfree
PIDUSERNAMETHRPRINICESIZERESSTATETIMECPUCOMMAND
11855smspf15901355M1321Mcpu/019:3216.52%oracle
2264oracle1001358M1316Mrun283.3H16.36%oracle
11280oracle11301356M1321Msleep79.8H0.77%oracle
6957smspf15291063M14Msleep107.7H0.76%java
17393smspf13001356M1322Mcpu/1833:050.58%oracle
29299smspf55808688K5088Ksleep18.5H0.38%fee_ftp_get
21043oracle14303264K2056Kcpu/90:010.31%top
20919smspf17291063M17Msleep247:020.29%java
25124smspf158016M4688Ksleep0:350.25%smif_status_rec
8086smspf523021M13Msleep41.1H0.24%fee_file_in
16009root13504920K3160Ksleep0:030.21%sshd2
25126smspf15801355M1321Msleep0:260.20%oracle
2266oracle16001357M1317Msleep811:420.18%oracle
11628smspf75903440K2088Ksleep0:390.16%sgip_client_ltz
26257smspf82590447M178Msleep533:040.15%java
我们注重到，2266号历程损耗的CPU不外0.18%,明显其实不忙碌,那末瓶颈就极可能在IO上。
利用IOSTAT工具反省IO情况。
gqgai:/home/gqgai>iostat-xn3
extendeddevicestatistics
r/sw/skr/skw/swaitactvwsvc_tasvc_t%w%bdevice
......
0.00.00.00.00.00.00.00.000c0t6d0
1.838.432.4281.00.00.70.016.4029c0t10d0
1.838.432.4281.00.00.50.013.5027c0t11d0
24.861.31432.4880.10.00.50.05.4026c1t1d0
0.00.00.00.00.00.00.09.100hurraysms02:vold(pid238)
extendeddevicestatistics
r/sw/skr/skw/swaitactvwsvc_tasvc_t%w%bdevice
........
0.00.00.00.00.00.00.00.000c0t6d0
0.38.30.347.00.00.10.09.208c0t10d0
0.08.30.047.00.00.10.08.007c0t11d0
11.765.3197.2522.20.01.60.020.50100c1t1d0
0.00.00.00.00.00.00.00.000hurraysms02:vold(pid238)
extendeddevicestatistics
r/sw/skr/skw/swaitactvwsvc_tasvc_t%w%bdevice
........
0.00.00.00.00.00.00.00.000c0t6d0
0.313.72.768.20.00.20.010.9012c0t10d0
0.013.70.068.20.00.10.09.6011c0t11d0
11.365.390.7522.70.01.50.019.5099c1t1d0
0.00.00.00.00.00.00.00.000hurraysms02:vold(pid238)
extendeddevicestatistics
r/sw/skr/skw/swaitactvwsvc_tasvc_t%w%bdevice
........
0.00.00.00.00.00.00.00.000c0t6d0
0.08.00.042.70.00.10.09.307c0t10d0
0.08.00.042.70.00.10.09.107c0t11d0
11.065.7978.7525.30.01.40.017.7099c1t1d0
0.00.00.00.00.00.00.00.000hurraysms02:vold(pid238)
extendeddevicestatistics
r/sw/skr/skw/swaitactvwsvc_tasvc_t%w%bdevice
........
0.00.00.00.00.00.00.00.000c0t6d0
0.387.72.7433.70.02.20.024.9090c0t10d0
0.088.30.0436.50.01.80.019.9081c0t11d0
89.054.0725.4432.00.02.10.014.80100c1t1d0
0.00.00.00.00.00.00.00.000hurraysms02:vold(pid238)


我们注重到，寄存数据库的次要卷c1t1d0的忙碌水平一直处于99~100,而写速率却只要500K/s摆布，这个速率是极其迟缓的。
(%bpercentoftimethediskisbusy(transactionsinprogress)
Kw/skilobyteswrittenpersecond)
依据我们的知识T3盘阵一般按Char写速率能够到达10M/s摆布，之前测试过一些Tpcc目标，能够参考:UsebonnietoTestsystemIOspeed。
而一般情形下的数据库随机写一般都在1~2M摆布，明显此时的磁盘已处于不一般形态，经由确认切实其实是硬盘产生了破坏，Raid5的Group中破坏了一块硬盘。
经由改换今后体系渐渐恢复一般。
PostedbyeygleatJune26,2005
根据Evans的调查报告，“MySQL的使用在未来将继续呈成长趋势。”

对于微软系列的工具除了一遍遍尝试还真没有太好的办法

如果你是从“学习某一种数据库应用软件，从而获得应聘的资本和工作机会”的角度来问的话。

还不是性能有问题！否则面向对象的数据库早就实现了！建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法，并且用到了大量的指针和高级数据模型。

不过话说回来了，绝大多数的性能优化准则与对sqlserver存储的结构理解息息相关

也可谈一下你是怎么优化存储过程的?

其实可以做一下类比，Oracle等数据库产品老早就支持了java编程，而且提供了java池参数作为用户配置接口。但是现在有哪些系统大批使用了java存储过程？！连Oracle自己的应用都不用为什么？！

SQLServer的异构移植功能个人感觉最好了。（如果对比过SQLServer的链接服务器和Oracle的透明网关的朋友会发现SQLServer的sp_addlinkedserver(openquery)异构数据库系列比Oracle真是强太多了。）

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

其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQLServer2005的row_number比Oracle的更先进。因为它把Orderby集成到了一起，不用像Oracle那样还要用子查询进行封装。