仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 634|回复: 8
打印 上一主题 下一主题

[学习教程] MYSQL教程之Oracle诊断案例-Sql_trace之一

[复制链接]
第二个灵魂 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 22:40:13 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

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并非没有局限性。它们难以扩展,需要大量的资源来配置和维护,比如时间、硬件和人力。同样,它们往往遵循峰值性能模型,这就要求系统按照峰值容量来配置可用性,而不考虑典型的数据使用情况。
再见西城 该用户已被删除
沙发
发表于 2015-1-19 21:07:52 | 只看该作者
这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。
乐观 该用户已被删除
板凳
发表于 2015-1-24 19:49:02 | 只看该作者
而写到本地,我又考虑到效率问题.大家来讨论讨论吧,分数不打紧,就给10分,十全十美,没啥对错,各抒己见,但是要有说服力的哦~
飘飘悠悠 该用户已被删除
地板
发表于 2015-2-2 12:57:10 | 只看该作者
在select语句中可以使用groupby子句将行划分成较小的组,然后,使用聚组函数返回每一个组的汇总信息,另外,可以使用having子句限制返回的结果集。
灵魂腐蚀 该用户已被删除
5#
发表于 2015-2-7 20:15:40 | 只看该作者
groupby子句可以将查询结果分组,并返回行的汇总信息Oracle按照groupby子句中指定的表达式的值分组查询结果。
简单生活 该用户已被删除
6#
发表于 2015-2-23 09:51:11 | 只看该作者
学习SQL语言的话如果要学会去做网站就不是很难!但是要做数据库管理的话就有难度了!
深爱那片海 该用户已被删除
7#
发表于 2015-3-7 07:12:10 | 只看该作者
无法深入到数据库系统层面去了解和探究
海妖 该用户已被删除
8#
发表于 2015-3-14 14:32:01 | 只看该作者
每天坚持做不一样的是,认真做笔录,定时复习。一个月你就可以有一定的收获。当然如果你想在sql方面有一定的造诣,你少不了需要看很多很多的书籍了。
只想知道 该用户已被删除
9#
发表于 2015-3-21 09:48:46 | 只看该作者
大侠们有推荐的书籍和学习方法写下吧。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-12-23 21:09

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表