视窗
loading...
您现在的位置:首页 > IT认证 > oracle认证 >

OracleDBA优化数据库性能心得体会


  很多的时侯,做Oracle DBA的我们,当应用管理员向我们通告现在应用很慢、数据库很慢的时侯,我们到数据库时做几个示例的Select也发现同样的问题时,有些时侯我们会无从下手,因为我们认为数据库的各种命种率都是满足Oracle文档的建议。

实际上如今的优化己经向优化等待(waits)转型了,实际中性能优化最根本的出现点也都集中在IO,这是影响性能最主要的方面,由系统中的等待去发现Oracle库中的不足、操作系统某些资源利用的不合理是一个比较好的办法,下面把我的一点实践经验与大家分享一下,本文测重于Unix环境。

  一、通过操作系统的一些工具检查系统的状态,比如CPU、内存、交换、磁盘的利用率,根据经验或与系统正常时的状态相比对,有时系统表面上看起来看空闲这也可能不是一个正常的状态,因为cpu可能正等待IO的完成。除此之外我们还应观注那些占用系统资源(cpu、内存)的进程。

  1、如何检查操作系统是否存在IO的问题?使用的工具有sar,这是一个比较通用的工具。

  Rp1#sar -u 2 10

  即每隔2秒检察一次,共执行20次,当然这些都由你决定了。

  示例返回:

  HP-UX hpn2 B.11.00 U 9000/800 08/05/03

  18:26:32 %usr %sys %wio %idle

  注:我在redhat下查看是这种结果,不知%system就是所谓的%wio。

  Linux 2.4.21-20.ELsmp (YY075) 05/19/2005

  10:36:07 AM CPU %user %nice %system %idle

  10:36:09 AM all 0.00 0.00 0.13 99.87

  10:36:11 AM all 0.00 0.00 0.00 100.00

  10:36:13 AM all 0.25 0.00 0.25 99.49

  10:36:15 AM all 0.13 0.00 0.13 99.75

  10:36:17 AM all 0.00 0.00 0.00 100.00

  10:36:17 AM CPU %user %nice %system %idle

  10:36:19 AM all 0.00 0.00 0.00 100.00

  10:36:21 AM all 0.00 0.00 0.00 100.00

  10:36:23 AM all 0.00 0.00 0.00 100.00

  10:36:25 AM all 0.00 0.00 0.00 100.00

  其中的%usr指的是用户进程使用的cpu资源的百分比,%sys指的是系统资源使用cpu资源的百分比,%wio指的是等待io完成的百分比,这是值得我们观注的一项,%idle即空闲的百分比。如果wio列的值很大,如在35%以上,说明你的系统的IO存在瓶颈,你的CPU花费了很大的时间去等待IO的完成。Idle很小说明系统CPU很忙。像我的这个示例,可以看到wio平均值为11说明io没什么特别的问题,而我的idle值为零,说明我的cpu已经满负荷运行了。

  当你的系统存在IO的问题,可以从以下几个方面解决:

  *联系相应的操作系统的技术支持对这方面进行优化,比如hp-ux在划定卷组时的条带化等方面。

  *查找Oracle中不合理的sql语句,对其进行优。

  *对Oracle中访问量频繁的表除合理建索引外,再就是把这些表分表空间存放以免访问上产生热点,再有就是对表合理分区。

  常用的工具便是vmstat,对于hp-unix来说可以用glance,Aix来说可以用topas,当你发现vmstat中pi列非零,memory中的free列的值很小,glance,topas中内存的利用率多于80%时,这时说明你的内存方面应该调节一下了,方法大体有以下几项。

  *划给Oracle使用的内存不要超过系统内存的1/2,一般保在系统内存的40%为益。

  *为系统增加内存。

  *如果你的连接特别多,可以使用MTS的方式。

  *打全补丁,防止内存漏洞。

  3、如何找到点用系用资源特别大的Oracle的session及其执行的语句。

  Hp-unix可以用glance,top,IBM AIX可以用topas,此外可以使用ps的命令。通过这些程序我们可以找到点用系统资源特别大的这些进程的进程号,我们就可以通过以下的sql语句发现这个pid正在执行哪个sql,这个sql最好在pl/sql developer,toad等软件中执行, 把<>中的spid换成你的spid就可以了。

  SELECT a.username,a.machine,a.program,a.sid,a.serial#,

  a.status,c.piece,c.sql_text from v$session a,v$process b,

  v$sqltext c WHERE b.spid='ORCL' AND b.addr=a.paddr AND

  a.sql_address=c.address(+)order BY c.piece

  我们就可以把得到的这个sql分析一下,看一下它的执行计划是否走索引,对其优化避免全表扫描,以减少IO等待,从而加快语句的执行速度。

  提示:我在做优化sql时,经常碰到使用in的语句,这时我们一定要用exists把它给换掉,因为Oracle在处理In时是按Or的方式做的,即使使用了索引也会很慢。

  比如:

  SELECT col1,col2,col3 FROM table1 a
  WHERE a.col1 not in (SELECT col1 FROM table2)

  可以换成:

  SELECT col1,col2,col3 FROM table1 a
  WHERE not exists
  (SELECT 'x' FROM table2 b
  WHERE a.col1=b.col1)

  4、另一个有用的脚本:查找前十条性能差的sql。

  SELECT * FROM (select PARSING_USER_ID,EXECUTIONS,SORTS,
  COMMAND_TYPE,DISK_READS,sql_text FROM v$sqlarea
  order BY disk_reads DESC )where ROWNUM<10 ;

  二、迅速发现Oracle Server的性能问题的成因,我们可以求助于v$session_wait这个视图,看系统的这些session在等什么,使用了多少的IO。以下是我提供的参考脚本:

  脚本说明:查看占io较大的正在运行的session。

  SELECT se.sid,se.serial#,pr.SPID,se.username,se.status,
  se.terminal,se.program,se.MODULE,、se.sql_address,st.event,st.
  p1text,si.physical_reads,
  si.block_changes FROM v$session se,v$session_wait st,
  v$sess_io si,v$process pr WHERE st.sid=se.sid AND st.
  sid=si.sid AND se.PADDR=pr.ADDR AND se.sid>6 AND st.
  wait_time=0 AND st.event NOT LIKE '%SQL%' ORDER BY physical_reads DESC

  对检索出的结果的几点说明:

  1、我是按每个正在等待的session已经发生的物理读排的序,因为它与实际的IO相关。

  2、你可以看一下这些等待的进程都在忙什么,语句是否合理?

  Select sql_address from v$session where sid=;

  Select * from v$sqltext where address=;

  执行以上两个语句便可以得到这个session的语句。你也以用alter system kill session 'sid,serial#';把这个session杀掉。

  3、应观注一下event这列,这是我们调优的关键一列,下面对常出现的event做以简要的说明:

  a、buffer busy waits,free buffer waits这两个参数所标识是dbwr是否够用的问题,与IO很大相关的,当v$session_wait中的free buffer wait的条目很小或没有的时侯,说明你的系统的dbwr进程决对够用,不用调整;free buffer wait的条目很多,你的系统感觉起来一定很慢,这时说明你的dbwr已经不够用了,它产生的wio已经成为你的数据库性能的瓶颈,这时的解决办法如下:

  a.1增加写进程,同时要调整db_block_lru_latches参数。

  示例:修改或添加如下两个参数

  db_writer_processes=4

  db_block_lru_latches=8

  a、2开异步IO,IBM这方面简单得多,hp则麻烦一些,可以与Hp工程师联系。

  b、db file sequential read,指的是顺序读,即全表扫描,这也是我们应该尽量减少的部分,解决方法就是使用索引、sql调优,同时可以增大db_file_multiblock_read_count这个参数。

  c、db file scattered read,这个参数指的是通过索引来读取,同样可以通过增加db_file_multiblock_read_count这个参数来提高性能。

  d、latch free,与栓相关的了,需要专门调节。

  e、其他参数可以不特别观注。

  其他的优化手段似乎主要集中在SQL查询语句上面,Oracle本身也提供了优化器。看来DBA的学问不少啊。

闂傚倸鍊风欢姘缚瑜嶈灋鐎光偓閸曨偆锛涢梺璺ㄥ櫐閹凤拷

闂傚倸鍊风欢姘缚瑜嶈灋鐎光偓閸曨偆锛涢梺璺ㄥ櫐閹凤拷

闂傚倸鍊风欢姘缚瑜嶈灋婵炲棙鎸哥粈澶愭煛閸ャ儱鐏╅柛灞诲姂閺屾洟宕煎┑鍥ь槱闁诲孩鑹鹃…鐑藉蓟閵娿儮鏀介柛鈩兠悵鏃傜磽娴g懓鏁剧紓宥勭窔瀵鏁撻悩鑼槹濡炪倖鍔х€靛矂鍩€椤掍緡娈滈柡宀€鍠栭幗搴ㄥ磼濮橆剛銈梻浣筋嚃閸燁偊宕惰閸炲爼姊虹紒妯荤叆闁硅姤绮庣划鏃堫敆閸曨剛鍘介梺缁樏鍫曞箹閹扮増鐓熼幒鎶藉礉鐏炶棄绁梻浣侯攰閹活亞绮婚幋锝囩闂傚倷娴囧▔鏇㈠闯閿曞倸绠柨鐕傛嫹
闂傚倸鍊风粈渚€骞栭锔藉亱婵犲﹤鐗嗙粈鍫熺箾閹存瑥鐏柛瀣枑閵囧嫰寮介顫勃闂佺粯甯$粻鏍蓟閺囩喓绠鹃柛顭戝枛婵酣姊虹拠鍙夊攭妞ゆ泦鍡楃倒闂備焦鎮堕崕鑽ゅ緤閼恒儲娅犻柟缁樺础瑜版帗鍋傞幖娣灩濞堟鎮楀▓鍨灈闁绘牕鍚嬫穱濠囨倻閼恒儲娅嗛梺鍛婃寙閸愵亜甯楀┑鐘垫暩閸嬫盯鎮洪妸褍鍨濈€光偓閳ь剟鎳為柆宥嗗殐闁冲搫瀚皬濠电偛顕崢褔鎮洪妸鈺佸惞闁稿瞼鍋為悡娑㈡煕閹扳晛濡奸柍褜鍓濆畷鐢靛垝閺冨洢浜归柟鐑樻尵閸欏棗鈹戦悙鏉戠伇婵炲懏娲滈埀顒佺啲閹凤拷闂傚倷娴囬褍霉閻戣棄鏋侀柟闂撮檷閳ь兛鐒︾换婵嬪磻椤栨氨绉虹€规洖宕灒閻犲洤妯婂ḿ顖炴⒒娴i涓茬紒韫矙瀵敻顢楅崟顒€浠奸梺鍛婎殘閸婃垶鎯旈妸銉у€為梺鎸庣箓閹冲酣鍩涙径瀣閻庣數枪鐢爼鏌熼搹顐€块柣娑卞枤閳ь剨缍嗛崰鏍不閿濆棛绡€濠电姴鍊搁顐︽煙閺嬵偄濮傛慨濠冩そ瀹曘劍绻濋崘锝嗗缂傚倷绀侀鍡欐暜閿熺姴绠氶柛銉e妼椤曢亶鏌℃径瀣仴闁哥偑鍔戝娲箹閻愭彃濮岄梺鍛婃煥缁夊綊鏁愰悙鍝勫唨妞ゎ兙鍎遍柊锝呯暦閸洘鏅查柛娑卞幐閹枫倕鈹戦悙宸殶闁告鍥х疇婵せ鍋撴鐐叉瀹曟﹢顢欓懖鈺婃Ч婵$偑鍊栭崝鎴﹀垂濞差亝鍎婇柡鍐e亾缂佺粯绻堟慨鈧柨婵嗘閵嗘劙鏌f惔銏e闁硅姤绮屽嵄闁规壆澧楅弲鎼佹煥閻曞倹瀚�闂傚倸鍊烽懗鍫曞箠閹剧粯鍋ら柕濞炬櫅閸ㄥ倿鏌涢幇顓犮偞闁割偒浜弻鐔衡偓鐢登瑰皬闂佺粯甯掗敃銈夊煘閹达附鍋愰柛娆忣槹閹瑥鈹戦悙鍙夊櫡闁搞劌缍婂﹢渚€姊洪幐搴g畵婵☆偅鐩幆灞炬償閵婏妇鍘撻悷婊勭矒瀹曟粌鈻庨幘宕囩枃闂佸綊鍋婇崗姗€寮搁弮鍫熺厵閺夊牓绠栧顕€鏌涚€n亶鍎旈柡灞剧洴椤㈡洟濡堕崨顔锯偓鍓х磽閸屾氨袦闁稿鎹囧缁樻媴閻熸壆浜伴梺缁樺釜缁犳挻淇婇悽鍛婂€烽柣銏㈡暩椤︻垶姊洪崫鍕殭闁绘妫涢惀顏囶樄闁哄本鐩獮鍥敍濞戞哎鈧﹦绱撴担鎻掍壕闂佽法鍣﹂幏锟�闂傚倷娴囬褏鑺遍懖鈺佺筏濠电姵鐔紞鏍ь熆閼搁潧濮囬柛銊ュ€圭换婵囩節閸屾凹浼€濡炪倐鏅犻弨閬嶅Φ閸曨垰绠抽柟瀛樼箖濞堣尙绱撴担椋庤窗闁革綇绲介锝夊醇閺囩喎鈧兘鏌涢…鎴濅簼闁绘繍浜滈埞鎴︽倷閼碱剙顤€闂佹悶鍔屾晶搴e垝濮樿埖鐒肩€广儱鎳愰崝鎾⒑閸涘﹤澹冮柛娑卞灱濡差剚绻濋悽闈浶ユい锝勭矙閸┾偓妞ゆ巻鍋撻柛鐔锋健閸┾偓妞ゆ帒鍊归崵鈧梺鎸庢磸閸ㄦ椽骞忛崨鏉戠闁圭粯甯楅鍧楁⒒娴e懙褰掑嫉椤掑倹宕茬€广儱顦懜褰掓煙缂併垹鏋熼柣鎾寸懇閹鈽夊▎瀣窗婵犫拃灞藉缂佺粯绻堥崺鈧い鎺嶇劍婵挳鏌涢敂璇插箻闁硅櫕绻堝娲礈閼碱剙甯ラ梺绋款儏閹虫劗妲愰悙鍝勭劦妞ゆ帒瀚埛鎴︽煟閻旂ǹ顥嬮柟鐣屽█閺岋絽螖閸愩劋鎴烽梺鐟扮畭閸ㄥ綊锝炲┑瀣垫晞闁兼亽鍎虫禍娆撴⒒娴e憡鎯堟繛璇х畵閹矂顢欓悙顒€搴婇梺绯曞墲缁嬫帡鎮″▎鎰╀簻闁圭偓顨呴崯鐗堢閺夋埈娓婚柕鍫濇婢跺嫰鏌涢幘璺烘瀻闁伙絿鍏橀弫鎰板幢濞嗘垹妲囬梻浣告啞閸斿繘寮查埡浣勶綁顢涢悙绮规嫼闂佸ジ鈧稑宓嗛柛婵堝劋閹便劍绻濋崒銈囧悑闂佸搫鑻悧鎾荤嵁濮椻偓椤㈡瑩鎳栭埡濠傛倛闂傚倷鑳堕幊鎾绘偤閵娧冨灊鐎广儱娲ら崹婵嬫煥閺囩偛鈧綊鎮¢妷锔剧闁瑰鍊栭幋婵撹€块柣妤€鐗忕弧鈧梺閫炲苯澧存鐐茬Ч椤㈡瑩骞嗚鐟欙附绻濋悽闈涗粶婵☆偅顨呴湁濡炲娴烽悳缁樹繆閵堝懎鏆熺痪鎯с偢閺岋繝宕掑☉鍗炲妼闂佺ǹ楠哥换鎺楀焵椤掑喚娼愰柟鍝デ硅灋婵犻潧妫涢弳锔芥叏濡灝鐓愰柛瀣姉缁辨挻鎷呯拹顖滅窗閻熸粎澧楅崹鍨潖濞差亜绠伴幖绮光偓铏亞闂備胶鎳撻崵鏍箯閿燂拷闂傚倷娴囬褍霉閻戣棄鏋侀柟闂寸缁犵娀鏌熼幑鎰厫闁哄棙绮嶉妵鍕箛閸撲胶鏆犵紓浣插亾闁糕剝岣跨粻楣冩煙鐎甸晲绱虫い蹇撶墕閺嬩線鏌涢锝嗙闁稿﹦鏁搁惀顏堫敇閻愭潙顎涘┑鐐插悑閸旀瑩寮诲☉銏犖╅柨鏂垮⒔閻撲胶绱撴担绋库偓鍦暜閿熺姰鈧礁螖娴g懓顎撶紓浣割儏閺呮繈顢曢敂瑙f嫼闁荤喐鐟ョ€氼厾娆㈤懠顒傜<缂備焦锚閻忓鈧鍣崑濠囥€佸▎鎾村仼鐎光偓婵犲啰銈┑鐘愁問閸犳濡靛☉銏犵;闁瑰墽绮悡鍐喐濠婂牆绀堟繛鍡樻尭绾惧綊鏌涘┑鍕姢缂佲偓婵犲洦鍊甸柨婵嗛閺嬬喖鏌涙惔锛勑ч柡灞剧洴瀵挳濡搁妷銉х憿闁荤喐绮庢晶妤冩暜濡ゅ懏鍋傞柍褜鍓欓—鍐Χ閸℃鐟ㄩ梺鎸庢穿婵″洨鍒掗崼銉︽櫢闁跨噦鎷�闂傚倸鍊峰ù鍥ㄧ珶閸喆浠堢紒瀣儥濞兼牕鈹戦悩宕囶暡闁绘帡绠栭弻鐔虹磼閵忕姵鐏堝┑鈽嗗亝閿曘垽寮婚敐澶嬪亜缂佸顑欏Λ鍡欑磼缂併垹骞愰柛瀣崌濮婄粯鎷呴悷閭﹀殝缂備礁顑嗙敮鎺楁偩濠靛绠瑰ù锝呮憸閿涙盯姊洪崫鍕犻柛鏂块叄閵嗗懘鎮滈懞銉у弳闂佺粯娲栭崐鍦偓姘炬嫹:webmaster@jscj.com闂傚倸鍊风欢姘缚瑜嶈灋鐎光偓閸曨偆锛涢梺鐟板⒔缁垶鎮¢悢鎼炰簻妞ゆ劦鍋勯獮妯肩磼娴e搫鍘撮柡宀嬬秮閺佸倻鎹勯妸褏鍘梻浣芥〃缁€浣虹矓瑜版帒鏋侀柟鍓х帛閺呮悂鏌ㄩ悤鍌涘4008816886

相关文章

无相关信息
更新时间2022-03-13 10:53:44【至顶部↑】
联系我们 | 邮件: webmaster@jscj.com | 客服热线电话:4008816886(QQ同号) |  婵犵數濮烽弫鎼佸磿閹寸姷绀婇柍褜鍓氶妵鍕即閸℃顏柛娆忕箻閺岋綁骞囬鍛瘜闂佺ǹ顑嗛幑鍥偘椤曗偓瀹曞綊顢欓崣銉ф/濠电姷鏁告慨顓㈠磻閹剧粯鐓曢柕澶嬪灥閼活垰鈻撻銏╂富闁靛牆妫欓ˉ鍡樸亜閺傚尅鍔熼柟骞垮灲閺佹捇鏁撻敓锟�

付款方式留言簿投诉中心网站纠错二维码手机版

客服电话: