MYSQL网页编程之Redo log日记组妨碍剖析
使用DBaaS能让收入损失从其他业务上得到弥补，如软件更新和硬件管理。也许决定走DBaaS之路的客户可能会跳过解决方案提供商，尽管这个决策看起来有点短视。数据库平台：SunOS5.8Generic_108528-23sun4usparcSUNW,Ultra-Enterprise数据库版本：8.1.5.0.0
数据库症状：数据库呼应迟缓，使用哀求没法前往，营业操纵陷于停留，此时必要DBA参与并举行成绩诊断及妨碍处置。
1.登录数据库举行反省
<p> 起首我们登录数据库,反省妨碍征象。
经由反省发明，数据块的一切重做日记组除current外都处于active形态：
<p>oracle:/oracle/oracle8>sqlplus"/assysdba"SQL*Plus:Release8.1.5.0.0-ProductiononThuJun2318:56:062005(c)Copyright1999OracleCorporation.Allrightsreserved.Connectedto:Oracle8iEnterpriseEditionRelease8.1.5.0.0-ProductionWiththePartitioningandJavaoptionsPL/SQLRelease8.1.5.0.0-ProductionSQL>select*fromv$log;GROUP#THREAD#SEQUENCE#BYTESMEMBERSARCSTATUSFIRST_CHANGE#FIRST_TIM-------------------------------------------------------------------------------------------11520403314572801NOACTIVE1.3861E+1023-JUN-0521520404314572801NOACTIVE1.3861E+1023-JUN-0531520405314572801NOACTIVE1.3861E+1023-JUN-0541520406314572801NOCURRENT1.3861E+1023-JUN-0551520398314572801NOACTIVE1.3860E+1023-JUN-0561520399314572801NOACTIVE1.3860E+1023-JUN-05715204001048576001NOACTIVE1.3860E+1023-JUN-05815204011048576001NOACTIVE1.3860E+1023-JUN-05915204021048576001NOACTIVE1.3861E+1023-JUN-059rowsselected.SQL>/GROUP#THREAD#SEQUENCE#BYTESMEMBERSARCSTATUSFIRST_CHANGE#FIRST_TIM-------------------------------------------------------------------------------------------11520403314572801NOACTIVE1.3861E+1023-JUN-0521520404314572801NOACTIVE1.3861E+1023-JUN-0531520405314572801NOACTIVE1.3861E+1023-JUN-0541520406314572801NOCURRENT1.3861E+1023-JUN-0551520398314572801NOACTIVE1.3860E+1023-JUN-0561520399314572801NOACTIVE1.3860E+1023-JUN-05715204001048576001NOACTIVE1.3860E+1023-JUN-05815204011048576001NOACTIVE1.3860E+1023-JUN-05915204021048576001NOACTIVE1.3861E+1023-JUN-059rowsselected. 我们晓得，当数据库产生日记切换时（LogSwitch）,Oracle会触发一个反省点（Checkpoint），反省点历程（CheckpointProcess，CKPT）会关照DBWR（Database?Writer）历程往实行写操纵。在日记文件所回护的处于Buffercache中的脏数据（dirtybuffer）未写回磁盘之前，日记文件不克不及被掩盖或重用。
<p> 假如数据库非常忙碌，大概DBWR的写出过慢，便可能呈现反省点未完成，Oracle却已用完一切日记文件的情形。在这类情形下，数据库的日记没法天生，全部数据库将处于停留形态，此光阴志文件中会纪录相似以下信息：
MonJan2316:11:392006Thread1cannotallocatenewlog,sequence5871CheckpointnotcompleteCurrentlog#2seq#5870mem#0:+ORADG/danaly/onlinelog/group_2.260.600173851Currentlog#2seq#5870mem#1:+ORADG/danaly/onlinelog/group_2.261.600173853反省v$session_wait视图，我们能够从中看到良多session处于logfileswitch(checkpointincomplete)的守候。
<p> 2.反省DBWR历程
<p> 在本案例中，一切日记组都处于active形态，那末明显DBWR的写出存在成绩。 接上去让我们反省一下DBWR的忙碌水平:
<p>SQL>!oracle:/oracle/oracle8>ps-ef|grepora_oracle227310Mar31?57:40ora_smon_hysms02oracle226610Mar31?811:42ora_dbw0_hysms02oracle2264116Mar31?16999:57ora_pmon_hysms02oracle226810Mar31?1649:07ora_lgwr_hysms02oracle227910Mar31?8:09ora_snp1_hysms02oracle228110Mar31?4:22ora_snp2_hysms02oracle228510Mar31?9:40ora_snp4_hysms02oracle227110Mar31?15:57ora_ckpt_hysms02oracle228310Mar31?5:37ora_snp3_hysms02oracle227710Mar31?5:58ora_snp0_hysms02oracle228910Mar31?0:00ora_d000_hysms02oracle228710Mar31?0:00ora_s000_hysms02oracle227510Mar31?0:04ora_reco_hysms02oracle2102321012018:52:59pts/650:00grepora_ DBWR的历程号是2266。
<p> 利用Top命令察看一下该历程的CPU耗用:
<p>oracle:/oracle/oracle8>toplastpid:21145;loadaverages:3.38,3.45,3.6718:53:38725processes:711sleeping,1running,10zombie,3oncpuCPUstates:35.2%idle,40.1%user,9.4%kernel,15.4%iowait,0.0%swapMemory:3072Mreal,286Mfree,3120Mswapinuse,1146MswapfreePIDUSERNAMETHRPRINICESIZERESSTATETIMECPUCOMMAND11855smspf15901355M1321Mcpu/019:3216.52%oracle2264oracle1001358M1316Mrun283.3H16.36%oracle11280oracle11301356M1321Msleep79.8H0.77%oracle6957smspf15291063M14Msleep107.7H0.76%java17393smspf13001356M1322Mcpu/1833:050.58%oracle29299smspf55808688K5088Ksleep18.5H0.38%fee_ftp_get21043oracle14303264K2056Kcpu/90:010.31%top20919smspf17291063M17Msleep247:020.29%java25124smspf158016M4688Ksleep0:350.25%smif_status_rec8086smspf523021M13Msleep41.1H0.24%fee_file_in16009root13504920K3160Ksleep0:030.21%sshd225126smspf15801355M1321Msleep0:260.20%oracle2266oracle16001357M1317Msleep811:420.18%oracle11628smspf75903440K2088Ksleep0:390.16%sgip_client_ltz26257smspf82590447M178Msleep533:040.15%java
我们注重到，2266号历程损耗的CPU不外0.18%,明显其实不忙碌,DBWR其实不忙碌，可是反省点没法完成，那末我们能够判别，瓶颈就极可能呈现在IO上。
3.反省IO情况
<p> 我们可使用IOSTAT工具反省体系IO情况：gqgai:/home/gqgai>iostat-xn3extendeddevicestatisticsr/sw/skr/skw/swaitactvwsvc_tasvc_t%w%bdevice......0.00.00.00.00.00.00.00.000c0t6d01.838.432.4281.00.00.70.016.4029c0t10d01.838.432.4281.00.00.50.013.5027c0t11d024.861.31432.4880.10.00.50.05.4026c1t1d00.00.00.00.00.00.00.09.100hurraysms02:vold(pid238)extendeddevicestatisticsr/sw/skr/skw/swaitactvwsvc_tasvc_t%w%bdevice........0.00.00.00.00.00.00.00.000c0t6d00.38.30.347.00.00.10.09.208c0t10d00.08.30.047.00.00.10.08.007c0t11d011.765.3197.2522.20.01.60.020.50100c1t1d00.00.00.00.00.00.00.00.000hurraysms02:vold(pid238)extendeddevicestatisticsr/sw/skr/skw/swaitactvwsvc_tasvc_t%w%bdevice........0.00.00.00.00.00.00.00.000c0t6d00.313.72.768.20.00.20.010.9012c0t10d00.013.70.068.20.00.10.09.6011c0t11d011.365.390.7522.70.01.50.019.5099c1t1d00.00.00.00.00.00.00.00.000hurraysms02:vold(pid238)extendeddevicestatisticsr/sw/skr/skw/swaitactvwsvc_tasvc_t%w%bdevice........0.00.00.00.00.00.00.00.000c0t6d00.08.00.042.70.00.10.09.307c0t10d00.08.00.042.70.00.10.09.107c0t11d011.065.7978.7525.30.01.40.017.7099c1t1d00.00.00.00.00.00.00.00.000hurraysms02:vold(pid238)extendeddevicestatisticsr/sw/skr/skw/swaitactvwsvc_tasvc_t%w%bdevice........0.00.00.00.00.00.00.00.000c0t6d00.387.72.7433.70.02.20.024.9090c0t10d00.088.30.0436.50.01.80.019.9081c0t11d089.054.0725.4432.00.02.10.014.80100c1t1d00.00.00.00.00.00.00.00.000hurraysms02:vold(pid238) 在以上输入中，我们注重到，寄存数据库的次要卷c1t1d0的忙碌水平一直处于99~100,而写速率却只要500K/s摆布，这个速率是极其迟缓的。
<p> 依据IOSTAT的手册:(%bpercentoftimethediskisbusy(transactionsinprogress)Kw/skilobyteswrittenpersecond)
<p> 依据我们的知识，T3盘阵一般按Char写速率能够到达10M/s摆布，之前测试过一些Tpcc目标，能够参考：www.eygle.com/unix/Use.Bonnie.To.Test.IO.speed.htm。
<p> 而一般情形下的数据库随机写一般都在1~2M摆布，明显此时的磁盘已处于不一般形态，经由确认切实其实是硬盘产生了破坏，Raid5的Group中破坏了一块硬盘。
<p> 经由改换今后体系渐渐恢复一般。
RDBMS并非没有局限性。它们难以扩展，需要大量的资源来配置和维护，比如时间、硬件和人力。同样，它们往往遵循峰值性能模型，这就要求系统按照峰值容量来配置可用性，而不考虑典型的数据使用情况。 对递归类的树遍历很有帮助。个人感觉这个真是太棒了！阅读清晰，非常有时代感。 多走走一此相关论坛，多看一些实例开发，多交流0经验，没什么的，我也是刚学没多久!加油 我是新手，正在学习数据库和操作系统，深感理论的泛广，唯有一步一步来，但是又感觉时间不够，收集了很多资料却总是没能认真的看完，希望有一个讨论板块，大家共同解决，共同分享，共同努力 始终遗憾SQLServer的登陆无法分配CPU/内存占用等指标数。如果你的SQLServer给别人分配了一个只可以读几个表的权限，而这个家伙疯狂的死循环进行连接查询，会给你的系统带来很大的负担。 如果我们从集合论（关系代数）的角度来看，一张数据库的表就是一组数据元的关系，而每个SQL语句会改变一种或数种关系，从而产生出新的数据元的关系（即产生新的表）。 分区表是个亮点！从分区表也能看出微软要做大作强SQLServer的信心。资料很多，这里不详细说。但是重点了解的是：现在的SQLServer2005的表，都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性对历史数据和实时数据的处理是很有帮助的。
页:
[1]