oracle文章收藏
生活随笔
收集整理的這篇文章主要介紹了
oracle文章收藏
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
DBA 麻煩終結者之路 轉載
oracle技術 ) ::閱讀:(392次) :: 評論 (0) silRIver 發表于:2005.01.19 14:50 ::分類: ( =========================================================== Oracle常用數據字典. ===========================================================
?
?????? 或許你厭倦了朝五晚六的開發工作，開始考ocp；或許你剛走出象牙塔，立志在數據庫管理方面大干一場？經過一翻努力，終于有了份dba的工作，忐忑不安地坐在電腦旁，激動得手心冒汗，卻不知如何去調整、優化數據庫；面對突如其來的故障，電話響個不停，老板虎視耽耽地站在身旁，不知你些時是否能靜下心來？ ?????? 可能讀了許多數據庫管理、調優、備份與恢復、pl/sql開發方面的書，也可能做了很多故障排除的實驗，可當故障真正降臨時，卻顯得那么可怕，通常正在運轉的生產數據庫一直處于性能惡化趨勢，麻煩總是從你意想不到的地方出現，阿門。 數據庫系統本身永遠是的值得注意的麻煩制造者：數不清的bug、對象失效、磁片碎片、索引重建以及很多沒有顧及到的突發事件等；沒有sql經驗的程序員也是很歷害的麻煩制造者：編寫性能不佳的sql以及創建一些性能較差的存儲對象；最可怕的麻煩制造者是誰呢？吼吼，正是來源于dba本身，對數據庫一個微小的修改，或許就導致一場災難。 做為一個新手dba來講,有關oracle體系統結構的概念非常重要，如果想比較透徹地理解這些概念，必須做大量的實驗，書上得來終覺少，絕知些事要躬行，呵呵，千萬不要在生產庫上進行哦；如果想從麻煩制造者成長為一個麻煩終結者，只顧自己埋頭苦學是不夠的，畢竟你的生產環境與學習環境產生的故障很有限，通過在相關論壇上閱讀貼子，從網友的經驗與教訓中汲取營養，拓展發現與解決問題的技巧。 獨立學習與思考是dba快速成長的關鍵。許多新手發現系統出現問題或未知的現象，第一時間總是去咨詢資深dba，其實這是壞習慣，盡量對問題進行分析與推理，如果實在沒有頭緒的話，可以在google或相關的論壇上發貼求助，網絡上總會有許多意相不到的驚喜，相信90%的問題已經有了答案，關鍵是如何找到它。 不要對internal的東西費心費神，打好基礎才是主要的，要有一定的pl/sql編程技術，牢牢掌握數據庫備份與恢復，然后提高系統調優及SQL優化的能力，當技術累積到一定的層次時，對于許多internal的東西自然自然就領會啦。 良好的溝通能力有助于更快地解決問題。很多時間，可能已經解決了問題，卻不知為什么會產生這種問題，這時可以咨詢一下項目負責人或相關程序員，盡量把問題的根源搞清楚，如果問題沒能根本解決，問題必然卷土重來。 作為dba，需要為項目組的程序員提供統一的《數據庫開發規范》，如果可能，也可做為程序員做sql編寫及sql優化技巧方面的培訓，盡量讓性能不佳的sql胎死腹中，新手dba，更要融入項目組，理解業務系統的需求，并掌握一定的數據庫建模知識，通過對數據庫結構的掌握，為數據庫結構優化與sql優化打下基礎。 努力學習對dba是必不可少的，需要注意的是：并不是方方面面的知識都需要熟記硬背。有選擇地去深入研究某個方面的技能，才能突破泛泛之境；不要太在意研究配置dataguard、安裝rac等瑣事，雕蟲小技而已；（http://www.cnoug.org/viewthread.php?tid=2226）這是piner網友收集整理的oracle faq，相信無論新手熟手，都是可以翻翻的。 “工欲善其事，必先利其器”，做為dba來講，必須為自己及程序員搭建順手的工作環境（本文以linux平臺為例）。在linux平臺上，sqlplus是不具有回調功能的，如何搭建具有回調環境的sqlplus呢？（http://www.dbanotes.net/Oracle/uniread-howto.htm）大家可以參考fenng網友的貼子。還有就是安裝sqlplus的help及sql語法的help，具體方法大家可以參考下面這個貼子(http://www.cnoug.org/viewthread.php?tid=1710)。在9i以后的版本中sqlplus的help默認是安裝的，sql語法的help就必須自己安裝啦。 ??
最需要新手注意的網址：http://tahiti.oracle.com? http://metalink.oracle.com 關于操作系統 / 網絡參數的調整?
做為dba，對linux/unix應該有相當的基礎。理解raid、raw、lvm、ocfs、asm等與存儲相關的概念；能夠安裝oracle軟件及打補丁；理解linux/unix常用的命令rpm、cpio、tar、ftp、top、vmstat、iostat、sar、netstat、crontab等；應用服務器的調整有一定的了解；關于linux/unix的問題，可以到http://www.chinaunix.com http://www.puschitz.com/去尋找答案。 關于初始化參數（ sga ）的調整?
深刻理解oracle的初始化參數是dba必不可少的功課，卻不能把調整參數做為提高性能的救命稻草，不合適的參數必將帶來性能上的下降，甚至數據丟失的危險；不要以為使用隱藏參數為榮，做事要有未雨調繆的打算，在系統故障時可以坦然對之。 沒有任何工式可以滿足sga調整的需要，通常都是經過多次調整，才能達到比較合諧的效果， http://blog.csdn.net/biti_rainy/archive/2004/07/03/learn_oracle_20040703_7.aspx 這個貼子是biti_rainy關于sga調整的總結，基本可以適合大多數情況。 在32bit的操作系統中，sga有1.7g的限制，如果相在32bit的操作系統上突破1.7g的限制，就需要使用特殊的手段， （http://www.itpub.net/showthread.php?s=&threadid=124424）這個貼子是coolyl網友針對各個平臺sga突破1.7g的限制的總結。 在64bit的操作系統中，sga不需要特殊方法可以上到3.9g，如果想突破4g的話，方法與32bit系統中突破1.7g的方法類似，也就是說必須使參數use_indirect_data_buffers=true，然后使用db_block_buffers來設置buffer cache的大小。 關于 statspack 的若干建議?
不要對statspack報太大希望，它只能告訴你過去某段時間數據庫的運行狀態，以及預測將來一段時間的性能趨勢（初始化參數沒能重大調整及業務沒能巨劇變化的情況下），通過statspack的報表，dba可以對初始化參數進一步進行微調。 statspack可以告訴你性能瓶頸所在，僅此而已，引起性能瓶頸的根本原因必須dba親自動手查；當然引起性能瓶頸的原因也可能已經收集到啦，在眾多收集到的sql中需要仔細斟別哦，如果sql語句太長，就比較麻煩，因為在statspack中，過長的sql會被截斷的；無論如何，statspack都是dba不可卻少的助手，（http://www.eygle.com/more/statspack_list.htm）這是eygle網友關于statspack的系列研究貼子，希望對你有用。 如果你需要經常制做statspack的性能趨勢報表，一般可以用excel來做，就是麻煩了一些，偶寫了一款專門制做statspack報表的工具，不僅可以更快更方便地制作出漂亮的報表，而且可以對知識進行管理。（http://www.cnoug.org/viewthread.php?tid=20115） 關于 logmnr 在調優中的運用?
一直以來，logmnr都不是調優所推薦的工具，主要用于安全審計方面，其實在追究系統瓶頸上logmnr可是得天獨厚，通過對日志的審查（需要dba有足夠的耐心哦），可以更清楚地知道oracle在某段時間內做了什么，這樣做是不是合理？當然logmnr并不能告訴你什么合理，你必須自己判斷。 在b/s結構的應用中，在session連接時用dbms_application_info.set_client_info設置session的client_info，這樣在用logmnr進行日志挖掘時，就知道是那個頁面執行了這個操作，范圍就比較小；在c/s結構的應用中，那是通常每個client連接后，都可能需要很久才斷開session，客戶每打開某個業務模塊，最好用dbms_application_info.set_client_info設置該session的client_info信息。 關于 materialized view 在調優中的運用?
在olap環境中，mview是以空間換時間的一種有效手段，更少的物理讀/寫，更少的cpu時間，更快的響應速度，所以它不適合高端的oltp環境；在oltp環境中，規模較大的報表適合使用mview來提高查詢性能。（http://www.itpub.net/224536.html）這個貼子可以下載到《expert one on one oracle》中文掃描版，該書的第13章專門講述mview的運用。 關于 stored outlines 在 sql 優化中的運用?
stored outlines是為了維持sql執行計劃穩定性而推出的功能，主要適用于測試環境到產品數據庫環境的遷移、當搜集統計信息以采樣方式運行、搜集統計信息可能給某些特定SQL帶來危害、無法對源代碼進行修改等情況下，為了保證產品數據庫的良好運行，我們需要穩定執行計劃。人為的調整某些特定的sql，我們可以使用sql謹慎的確定某個sql所需要的outlines。（摘自biti_rainy原話,原url如下。） http://blog.csdn.net/biti_rainy/archive/2004/06/29/biti_rainy_learn_oracle_20040629_1.aspx （單擊此處的url將不能打開相關鏈接，拷貝到ie地址欄中即可）關于stored outlines的使用， http://blog.itpub.net/post/96/1548 也可以參考本人拙作。曾對stored outlines抱有厚望，但在實際運用中卻發現outlines并不是那么很好伺候，一般當sql使用bind variable的情況下用outlines來穩定計劃會更合適一些。?
當初始化參數cursor_sharing=EXACT時，如果查詢條件不同，就沒有辦法使用stored?
outlined；如果把業務邏輯封裝在stored procedure中，procedure中的變量將以bind variable的形式出現，這時可以用stored outlines來穩定執行計劃，具體操作見本人拙作；如果sql中沒有文本變量（常數），則可以用stored outlines。?
?? 如何用dbms_profiler測試stored procedure?
??? 關于dbms_profiler package主要用于pl/sql block與stored procedure的性能測試，在開發階段程序員或dba需要對開發的各種存儲對象進行性能測試，通過dbms_profiler package可以找出存儲對象中性能不佳的地方，然后進行改行；可以看出dbms_profile與outline的區別是：一個用于開發階段，需要修改程序，一個用于正式運行階段，不必去修改程序，只改變sql的執行計劃而已。關于dbms_profiler package的兩個貼子：?
??? http://www.samoratech.com/PLSQLProfiler.htm ??? http://pages.videotron.com/orautils/pages/dbms_profile.htm ?? 如何對sql進行調整及優化?
??? 優化sql是最能體現dba智慧與價值的地方。通常在statspack的top 5的wati event主要由性能不佳的sql引起的；磁盤排序及temp tablespace瀑漲等大多與sql有關，不排除創建與重建索引這方面，但這方面的原因應該是dba負責，大表在創建或重建索引必須在系統空閑時。?
性能不佳的sql是如何產生的呢？這里面問題就比較復雜一些：不良的數據庫結構必將導致不良的sql；還有就是程序員的sql編寫技能引起的；不要奢望程序員是sql編寫方面的專家，根據偶自己做開發的經歷，最快時間完成項目才是最重要的，所以程序員不會太關心sql的性能，即是關心，也是很有限的。?
對程序員進行合適的關于sql優化的培訓，提高他們的責任感，針對系統中出現的案例進行講解，程序員潛意識中就會努力避免很多低級的錯誤；要多與程序員交流，盡量引導程序員描述他在數據庫方面感到困難的地方，并提出指導性意見及解決方案。?
對新手dba而言，通常都很有興趣對系統參數或sql進行調優，卻不知如何動手。在系統參數方面本身要有一定的理解，也可以請教與資深dba進行探討，性能提高上奉勸不要抱太大的希望，也可以根據statspack的報表進行分析，對系統參數進行微調；在sql調優方面，必須能夠勘別出性能不佳的sql。?
如何勘別出性能不佳的sql呢？通常要綜合以下性能指標（response time/consistent gets/physical reads）進行判斷；要根據自己的情況從v$sql或v$sqltext_new_withlines字典表中把符合條件的sql查詢出來：?
set lines 99?
col sql_text format a81?
col bgets_per format 99999999.9?
set long 99999999999?
set pagesize 9999?
select address,hash_value,disk_reads,elapsed_time/1000000 as?
"elapsd_time(s)",cpu_time/1000000 as "cpu_time(s)",?
?????? buffer_gets/executions bgets_per,first_load_time,sql_text?
?from v$sql?
where disk_reads > 1000 or (executions > 0 and buffer_gets/executions > 50000);?
??? 上面的這個查詢主要將physical reads > 1000及consistent gets > 50000的sql語句找了出來，當然你也可以將響應時間也進行限制,通常onsistent gets較大或physical reads較大的sql，它的response time也必然會比較大。?
??? 如何在sql執行時產生執行計劃呢？在sqlplus上輸入set autot on就可以產生比較詳細的執行計劃；set autot off是讓sqlplus取消產生執行計劃；set autot traceonly只顯示sql影響的行數、執行計劃、執行的統計信息、不輸出結果集；set autot on exp輸出執行后的結果集及執行計劃；set autot on stat輸出執行后的結果集及統計信息。explain plan只對sql進行分析，產生執行樹，用select * from table(dbms_xplan.display)輸出explain plan產生執行計劃。?
set autot[race] {off|on|trace[only]}[exp[lain]] [stat[istics]]?
explain plan [set statement_id = &item_id] for &sql;???
select * from table(dbms_xplan.display);?
??? 如何對性能不佳的sql進行優化，想來對任何一個dba都有挑戰性。在這個環節上，dba必須掌握如何查看sql的執行計劃，并對返回的結果有一定的了解；如果是新手，可以借助一些sql優化工具進行調優,可借用的工具有lecco sql expert及quest toad,鑒與新手對工具的理解有些難度，本人為lecco sql expert寫了中文圖解。?
??? sql expert 教程 http://www.cnoug.org/viewthread.php?tid=22327?
??? quest toad 教程 http://www.cnoug.org/viewthread.php?tid=3242（向原作者致謝）?
??? 任何工具都是比較低智能的，如果你覺得lecco或toad比較順手，千萬勿沉溺其中，它們只是一個拐杖而已，你必須超越它，否則你的價值就值得懷疑；針對sql的優化，必須自己多動手測試，而且也要閱覽眾書，從別人的經驗中激發靈感。?
??? 在優化sql時，需要一層層地對sql進行分析。首先對sql的語法進行分析，剔除冗余的或錯誤的查詢條件（有可能是程序員手誤），花得工夫不是很多，性能可得到極大的提高，不要太相信程序員，他們寫得必未正確；其次對sql涉及表的結構進行分析，特別是復雜的sql，要檢查是否有更佳的連接路線，連接字段是否有索引，索引的選擇性如何等；第三償試用不同的hints改變表的的驅動次序。http://www.adp-gmbh.ch/ora/sql/hints.html 這個貼子是oracle hints的一個列表,hints具體用法可查http://tahiti.oracle.com。?
??? 關于sql調優的細節很多，不可能一一列舉，具體環境必須以執行計劃為準，通過對sql的理解，提升到對數據庫結構的合理性進行揣測，合理的數據庫結構，將對sql的性能有較大的提高；有些情況下，修改了數據庫結構，并不需要在程序上進行相應的改動，比如將大表進行分區、創建mview等。關于sql優化大家也可以好好研究一下網友 black_snail 的系列貼子 ，有詳細的示例： http://www.dbonline.cn/source/oracle/20031218/oracle%20SQL%20performance%20tuning1.html ?? 如何對session進行跟蹤及tkprof的使用?
??? 跟蹤session的活動，oracle提供了很多種手段，不僅可以對當前連接的session進行跟蹤，也可以對其它用戶的session進行跟蹤；通過對trace文件的分析，不僅可以掌握該session的活動，也可以找出這個session中的瓶頸所在，對session的跟蹤是dba進行系統調優、故障診斷的常用方法。?
??? alter session set sql_trace=true/false?
??? 對當前會話的活動進行跟蹤及停止跟蹤?
exec dbms_system.set_sql_trace_in_session(sid,serial#,&sql_trace);?
??? 可以對當前session、其它用戶的session進行跟蹤及停止跟蹤?
alter session set events '&event trace name context forever,level &level';?
alter session set events '&event trace name context off';?
exec dbms_system.set_ev(&sid,&serial#,&event_10046,&level_12,'');?
oradebug event 10046 trace name context forever,level 12?
關于event跟蹤的詳細論述大家可以參考hrb_qiuyb的貼子：?
http://blog.csdn.net/hrb_qiuyb/archive/2004/06/30/30559.aspx event、sql trace等工具收集正在執行的sql的性能狀態數據并記錄到跟蹤文件中. 這個跟蹤文件提供了許多有用的信息,例如解析次數.執行次數,CPU使用時間、物理讀、邏輯讀等.這些數據將可以用來優化你的系統.user_dump_dest參數說明了生成跟蹤文件的目錄，設置sql trace首先要在init&sid.ora中設定timed_statistics為true, 這樣才能得到那些重要的時間狀態. 由于sql trace生成的trace文件讀起來很困難,所以要用tkprof對其進行轉換,TKPROF有許多執行參數，可以參考http://tahiti.oracle.oracle技術 ) ::閱讀:(392次) :: 評論 (0) silRIver 發表于:2005.01.19 14:50 ::分類: ( =========================================================== Oracle常用數據字典. ===========================================================
| 作者：佚名 來源：InterNet 加入時間：2003-7-20 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
總結
以上是生活随笔為你收集整理的oracle文章收藏的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Linux--进程与任务管理
- 下一篇： WHQL认证最新申请流程