|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
MySQL数据库归MySQLAB公司所有,但是这个软件是开源的,有一个MySQL学习教程可以免费下载。稍俱常识的新入门者都可以轻松实现在一个常见硬件上安装和配置MySQL。oracle
link:
http://www.eygle.com/case/sql_trace_1.htm
成绩形貌:
这是匡助一个公司的诊断案例.
使用是一个背景旧事公布体系.
症状是,经由过程毗连会见旧事页是极为迟缓
一般必要十数秒才干前往.
这类功能是用户不克不及忍耐的.
操纵体系:SunOS5.8
数据库版本:8.1.7
1.反省并跟踪数据库历程
诊断时是早晨,无用户会见
在前台点击相干页面,同时举行历程跟踪
查询v$session视图,猎取历程信息
SQL>selectsid,serial#,usernamefromv$session;SIDSERIAL#USERNAME--------------------------------------------------1121314151617284IFLOW11214IFLOW12164SYS161042IFLOW10rowsselected.
启用相干历程sql_trace
SQL>execdbms_system.set_sql_trace_in_session(7,284,true)PL/SQLproceduresuccessfullycompleted.SQL>execdbms_system.set_sql_trace_in_session(11,214,true)PL/SQLproceduresuccessfullycompleted.SQL>execdbms_system.set_sql_trace_in_session(16,1042,true)PL/SQLproceduresuccessfullycompleted.SQL>selectsid,serial#,usernamefromv$session;SIDSERIAL#USERNAME--------------------------------------------------1121314151617284IFLOW11214IFLOW12164SYS161042IFLOW10rowsselected.
期待一段工夫,封闭sql_trace
SQL>execdbms_system.set_sql_trace_in_session(7,284,false)PL/SQLproceduresuccessfullycompleted.SQL>execdbms_system.set_sql_trace_in_session(11,214,false)PL/SQLproceduresuccessfullycompleted.SQL>execdbms_system.set_sql_trace_in_session(16,1042,false)PL/SQLproceduresuccessfullycompleted.
2.反省trace文件
反省发明以下语句是可疑的
********************************************************************************selectauditstatus,categoryid,auditlevelfromcategoryarticleassigna,categorybwhereb.id=a.categoryidandarticleId=20030700400141andauditstatus>0callcountcpuelapseddiskquerycurrentrows-----------------------------------------------------------------------Parse10.000.000000Execute10.000.000000Fetch10.810.810389201-----------------------------------------------------------------------total30.810.810389201********************************************************************************
这里明显是依据articleId举行旧事读取的.
很可疑的是query读取有3892
这个内容引发了我的注重.
假如碰到过相似的成绩,人人在这里就应当晓得是怎样回事变了.
假如没有碰到过的伴侣,能够在这里思索一下再往下看.
Missesinlibrarycacheduringparse:1Optimizergoal:CHOOSEParsinguserid:41RowsRowSourceOperation----------------------------------------------------------1NESTEDLOOPS2INDEXRANGESCAN(objectid25062)1TABLEACCESSBYINDEXROWIDCATEGORY2INDEXUNIQUESCAN(objectid25057)********************************************************************************selectauditstatus,categoryidfromcategoryarticleassignwherearticleId=20030700400138andcategoryIdin(63,138,139,140,141,142,143,144,168,213,292,341,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,383,460,461,462,463,621,622,626,629,631,634,636,643,802,837,838,849,850,851,852,853,854,858,859,860,861,862,863,-1)callcountcpuelapseddiskquerycurrentrows-----------------------------------------------------------------------Parse10.000.000000Execute10.000.000000Fetch14.914.910283571-----------------------------------------------------------------------total34.914.910283571Missesinlibrarycacheduringparse:1Optimizergoal:CHOOSEParsinguserid:41RowsRowSourceOperation----------------------------------------------------------1TABLEACCESSFULLCATEGORYARTICLEASSIGN我们注重到,这里有一个全表扫描存在********************************************************************************
3.上岸数据库,反省响应表布局
SQL>selectindex_name,table_name,column_namefromuser_ind_columns2wheretable_name=upper(categoryarticleassign);INDEX_NAMETABLE_NAMECOLUMN_NAME--------------------------------------------------------------------------------IDX_ARTICLEIDCATEGORYARTICLEASSIGNARTICLEIDIND_ARTICLEID_CATEGCATEGORYARTICLEASSIGNARTICLEIDIND_ARTICLEID_CATEGCATEGORYARTICLEASSIGNCATEGORYIDIDX_SORTIDCATEGORYARTICLEASSIGNSORTIDPK_CATEGORYARTICLEASSIGNCATEGORYARTICLEASSIGNARTICLEIDPK_CATEGORYARTICLEASSIGNCATEGORYARTICLEASSIGNCATEGORYIDPK_CATEGORYARTICLEASSIGNCATEGORYARTICLEASSIGNASSIGNTYPEIDX_CAT_ARTICLECATEGORYARTICLEASSIGNAUDITSTATUSIDX_CAT_ARTICLECATEGORYARTICLEASSIGNARTICLEIDIDX_CAT_ARTICLECATEGORYARTICLEASSIGNCATEGORYIDIDX_CAT_ARTICLECATEGORYARTICLEASSIGNASSIGNTYPE11rowsselected.
我们注重到,IDX_ARTICLEID索引在以上查询中都没有被用到.
反省表布局:
SQL>desccategoryarticleassignNameNull?Type-----------------------------------------------------------------------------CATEGORYIDNOTNULLNUMBERARTICLEIDNOTNULLVARCHAR2(14)ASSIGNTYPENOTNULLVARCHAR2(1)AUDITSTATUSNOTNULLNUMBERSORTIDNOTNULLNUMBERUNPASSVARCHAR2(255)
成绩发明:
由于ARTICLEID是个字符型数据,查询中给进的articleId=20030700400141是一个数字值
Oracle产生潜伏的数据范例转换,从而招致了索引生效
SQL>selectauditstatus,categoryid2from3categoryarticleassignwherearticleId=20030700400132;AUDITSTATUSCATEGORYID---------------------99403830695Elapsed:00:00:02.62ExecutionPlan----------------------------------------------------------0SELECTSTATEMENTOptimizer=CHOOSE(Cost=110Card=2Bytes=38)10TABLEACCESS(FULL)OFCATEGORYARTICLEASSIGN(Cost=110Card=2Bytes=38)
4.办理办法
复杂的在参数两侧各增添一个,既可办理这个成绩.
关于相似的查询,我们发明Query形式读取下降为2
几近不必要消费CPU工夫了
********************************************************************************selectunpassfromcategoryarticleassignwherearticleid=20030320000682andcategoryid=113callcountcpuelapseddiskquerycurrentrows-----------------------------------------------------------------------Parse10.000.000000Execute10.000.000000Fetch10.000.000200-----------------------------------------------------------------------total30.000.000200Missesinlibrarycacheduringparse:1Optimizergoal:CHOOSEParsinguserid:20RowsRowSourceOperation----------------------------------------------------------0TABLEACCESSBYINDEXROWIDCATEGORYARTICLEASSIGN1INDEXRANGESCAN(objectid3080)********************************************************************************
至此,这个成绩失掉了完美的办理.
RDBMS并非没有局限性。它们难以扩展,需要大量的资源来配置和维护,比如时间、硬件和人力。同样,它们往往遵循峰值性能模型,这就要求系统按照峰值容量来配置可用性,而不考虑典型的数据使用情况。 |
|