❶ 2020-01-20 oracle中sql如何執行，什麼是硬解析和軟解析
1.語法檢查：檢查 SQL 拼寫是否正確，如果不正確，Oracle 會報語法錯誤。
2.語義檢查：檢查 SQL 中的訪問對象是否存在。比如我們在寫 SELECT 語句的時候，列名寫錯了，系統就會提示錯誤。語法檢查和語義侍槐察檢查的作用是保證 SQL 語句沒有錯誤。
3.許可權檢查：看用戶是否具備訪問該數據的許可權。
4.共享池檢查：共享池（Shared Pool）是一塊內存池，最主要的作用是緩存 SQL 語句和該語句的執行計劃。Oracle 通過檢查共享池是否存在 SQL 語句的執行計劃，來判斷進行軟解析，還是硬解析。那軟解析和硬解析又該怎麼理解呢？在共享池中，Oracle 首先對 SQL 語句進行 Hash 運算，然後根據 Hash 值在庫緩存（Library Cache）中查找，如果存在 SQL 語句的執行計劃，就直接拿來執行，直接進入「執行器」的環節，這就是軟解析。如果沒有找到 SQL 語句和執行計劃，Oracle 就需要創建解析樹進行解析明羨，生成執行計劃，進入「優化器」這個步驟，這就是硬解析。
5.優化器：優化器中就是要進行硬解析，也就老茄是決定怎麼做，比如創建解析樹，生成執行計劃。
6.執行器：當有了解析樹和執行計劃之後，就知道了 SQL 該怎麼被執行，這樣就可以在執行器中執行語句了。
共享池是 Oracle 中的術語，包括了庫緩存，數據字典緩沖區等。我們上面已經講到了庫緩存區，它主要緩存 SQL 語句和執行計劃。而數據字典緩沖區存儲的是 Oracle 中的對象定義，比如表、視圖、索引等對象。當對 SQL 語句進行解析的時候，如果需要相關的數據，會從數據字典緩沖區中提取。
如何避免硬解析，盡量使用軟解析呢？在 Oracle 中，綁定變數是它的一大特色。綁定變數就是在 SQL 語句中使用變數，通過不同的變數取值來改變 SQL 的執行結果。
❷ 影響資料庫性能的主要因素有哪些
1、1、調整數據結構的設計。這一部分在開發信息系統之前完成，程序員需要考慮是否使用ORACLE資料庫的分區功能，對於經常訪問的資料庫表是否需要建立索引等。 x0dx0ax0dx0a2、2、調整應用程序結構設計。這一部分也是在開發信息系統之前完成，程序員在這一步需要考慮應用程序使用什麼樣的體系結構，是使用傳統的Client/Server兩層體系結構，還是使用Browser/Web/Database的三層體系結構。不同的應用程序體系結構要求的資料庫資源是不同的。 x0dx0ax0dx0a3、3、調整資料庫SQL語句。應用程序的執行最終將歸結為資料庫中的SQL語句執行，因此SQL語句的執行效率最終決定了ORACLE資料庫的性能。ORACLE公司推薦使用ORACLE語句優化器（Oracle Optimizer）和行鎖管理器（row-level manager）來調整優化SQL語句。 x0dx0ax0dx0a4、4、調整伺服器內存分銷和段配。內存分配是在信息系統運行過程中優化配置的，資料庫管理員可以根據資料庫運行狀況調整資料庫系統全局區（SGA區）的數據緩沖區、日誌緩沖區和共享池的大小；還可以調整程序全局區（PGA區）的大小。需要注意的是，SGA區不是越大越好，SGA區過大會佔用操作系統使用的內存而引起虛擬內存的頁面交換，這樣反而會降低系統。 x0dx0ax0dx0a5、5、調整硬碟I/O，這一步是在信息系統開發之前完成的。資料庫管理員可以將組成同一個表空間的數據文件放在不同的硬碟上，做到硬碟之間I/O負載均衡。 x0dx0ax0dx0a6、6、調整操作系統參數，例如：運行在UNIX操作系統上的ORACLE資料庫，可以調整UNIX數據緩沖池的大小，每個進程所能使用的內存大小等參數。 x0dx0ax0dx0a實際上，上述資料庫優化措施之間是相互聯系的。ORACLE資料庫性能惡化表現基本上都是用戶響應時間比較長，需要用戶長時間的等待。但性能惡化的原因卻是多種多樣的，有時是多個因素共同造成了性能惡化的結果，這就需要資料庫管理員有比較全面的計算機知識，能夠敏感地察覺到影響資料庫性能的主要原因所在。另外，良好的資料庫管理工具對於優化資料庫性能也是很重要的。 x0dx0ax0dx0aORACLE資料庫性能優化工具 x0dx0ax0dx0a常用的資料庫性能優化工具有： x0dx0ax0dx0a1、1、ORACLE資料庫在線數據字典，ORACLE在線數據字典能夠反映出ORACLE動態運行情況，對於調整資料庫性能是很有幫助的。 x0dx0ax0dx0a2、2、操作系統工具，例如UNIX操作系統的vmstat，iostat等命令可以查看到系統系統級內存和硬碟I/O的使用情況，這些工具對於管理員弄清出系統瓶頸出現棚行在什麼地方有時候很有用。 x0dx0ax0dx0a3、3、SQL語言跟蹤工具（SQL TRACE FACILITY），SQL語言跟蹤工具可以記錄SQL語句的執行情況，管理員可以使用虛擬表來調整實例，使用SQL語句跟蹤文件調整應用程序性能。SQL語言跟蹤工具將結果輸出成一個操作系統的文虧譽件，管理員可以使用TKPROF工具查看這些文件。 x0dx0ax0dx0a4、4、ORACLE Enterprise Manager（OEM），這是一個圖形的用戶管理界面，用戶可以使用它方便地進行資料庫管理而不必記住復雜的ORACLE資料庫管理的命令。 x0dx0ax0dx0a5、5、EXPLAIN PLAN——SQL語言優化命令，使用這個命令可以幫助程序員寫出高效的SQL語言。 x0dx0ax0dx0aORACLE資料庫的系統性能評估 x0dx0ax0dx0a信息系統的類型不同，需要關注的資料庫參數也是不同的。資料庫管理員需要根據自己的信息系統的類型著重考慮不同的資料庫參數。 x0dx0ax0dx0a1、1、在線事務處理信息系統（OLTP），這種類型的信息系統一般需要有大量的Insert、Update操作，典型的系統包括民航機票發售系統、銀行儲蓄系統等。OLTP系統需要保證資料庫的並發性、可靠性和最終用戶的速度，這類系統使用的ORACLE資料庫需要主要考慮下述參數： x0dx0ax0dx0al l 資料庫回滾段是否足夠？ x0dx0ax0dx0al l 是否需要建立ORACLE資料庫索引、聚集、散列？ x0dx0ax0dx0al l 系統全局區（SGA）大小是否足夠？ x0dx0ax0dx0al l SQL語句是否高效？ x0dx0ax0dx0a2、2、數據倉庫系統（Data Warehousing），這種信息系統的主要任務是從ORACLE的海量數據中進行查詢，得到數據之間的某些規律。資料庫管理員需要為這種類型的ORACLE資料庫著重考慮下述參數： x0dx0ax0dx0al l 是否採用B*-索引或者bitmap索引？ x0dx0ax0dx0al l 是否採用並行SQL查詢以提高查詢效率？ x0dx0ax0dx0al l 是否採用PL/SQL函數編寫存儲過程？ x0dx0ax0dx0al l 有必要的話，需要建立並行資料庫提高資料庫的查詢效率 x0dx0ax0dx0aSQL語句的調整原則 x0dx0ax0dx0aSQL語言是一種靈活的語言，相同的功能可以使用不同的語句來實現，但是語句的執行效率是很不相同的。程序員可以使用EXPLAIN PLAN語句來比較各種實現方案，並選出最優的實現方案。總得來講，程序員寫SQL語句需要滿足考慮如下規則： x0dx0ax0dx0a1、1、盡量使用索引。試比較下面兩條SQL語句： x0dx0ax0dx0a語句A：SELECT dname, deptno FROM dept WHERE deptno NOT IN x0dx0ax0dx0a(SELECT deptno FROM emp); x0dx0ax0dx0a語句B：SELECT dname, deptno FROM dept WHERE NOT EXISTS x0dx0ax0dx0a(SELECT deptno FROM emp WHERE dept.deptno = emp.deptno); x0dx0ax0dx0a這兩條查詢語句實現的結果是相同的，但是執行語句A的時候，ORACLE會對整個emp表進行掃描，沒有使用建立在emp表上的deptno索引，執行語句B的時候，由於在子查詢中使用了聯合查詢，ORACLE只是對emp表進行的部分數據掃描，並利用了deptno列的索引，所以語句B的效率要比語句A的效率高一些。 x0dx0ax0dx0a2、2、選擇聯合查詢的聯合次序。考慮下面的例子： x0dx0ax0dx0aSELECT stuff FROM taba a, tabb b, tabc c x0dx0ax0dx0aWHERE a.acol between :alow and :ahigh x0dx0ax0dx0aAND b.bcol between :blow and :bhigh x0dx0ax0dx0aAND c.ccol between :clow and :chigh x0dx0ax0dx0aAND a.key1 = b.key1 x0dx0ax0dx0aAMD a.key2 = c.key2; x0dx0ax0dx0a這個SQL例子中，程序員首先需要選擇要查詢的主表，因為主表要進行整個表數據的掃描，所以主表應該數據量最小，所以例子中表A的acol列的范圍應該比表B和表C相應列的范圍小。 x0dx0ax0dx0a3、3、在子查詢中慎重使用IN或者NOT IN語句，使用where (NOT) exists的效果要好的多。 x0dx0ax0dx0a4、4、慎重使用視圖的聯合查詢，尤其是比較復雜的視圖之間的聯合查詢。一般對視圖的查詢最好都分解為對數據表的直接查詢效果要好一些。 x0dx0ax0dx0a5、5、可以在參數文件中設置SHARED_POOL_RESERVED_SIZE參數，這個參數在SGA共享池中保留一個連續的內存空間，連續的內存空間有益於存放大的SQL程序包。 x0dx0ax0dx0a6、6、ORACLE公司提供的DBMS_SHARED_POOL程序可以幫助程序員將某些經常使用的存儲過程「釘」在SQL區中而不被換出內存，程序員對於經常使用並且佔用內存很多的存儲過程「釘」到內存中有利於提高最終用戶的響應時間。 x0dx0ax0dx0aCPU參數的調整 x0dx0ax0dx0aCPU是伺服器的一項重要資源，伺服器良好的工作狀態是在工作高峰時CPU的使用率在90％以上。如果空閑時間CPU使用率就在90％以上，說明伺服器缺乏CPU資源，如果工作高峰時CPU使用率仍然很低，說明伺服器CPU資源還比較富餘。 x0dx0ax0dx0a使用操作相同命令可以看到CPU的使用情況，一般UNIX操作系統的伺服器，可以使用sar _u命令查看CPU的使用率，NT操作系統的伺服器，可以使用NT的性能管理器來查看CPU的使用率。 x0dx0ax0dx0a資料庫管理員可以通過查看v$sysstat數據字典中「CPU used by this session」統計項得知ORACLE資料庫使用的CPU時間，查看「OS User level CPU time」統計項得知操作系統用戶態下的CPU時間，查看「OS System call CPU time」統計項得知操作系統系統態下的CPU時間，操作系統總的CPU時間就是用戶態和系統態時間之和，如果ORACLE資料庫使用的CPU時間占操作系統總的CPU時間90％以上，說明伺服器CPU基本上被ORACLE資料庫使用著，這是合理，反之，說明伺服器CPU被其它程序佔用過多，ORACLE資料庫無法得到更多的CPU時間。 x0dx0ax0dx0a資料庫管理員還可以通過查看v$sesstat數據字典來獲得當前連接ORACLE資料庫各個會話佔用的CPU時間，從而得知什麼會話耗用伺服器CPU比較多。 x0dx0ax0dx0a出現CPU資源不足的情況是很多的：SQL語句的重解析、低效率的SQL語句、鎖沖突都會引起CPU資源不足。 x0dx0ax0dx0a1、資料庫管理員可以執行下述語句來查看SQL語句的解析情況： x0dx0ax0dx0aSELECT * FROM V$SYSSTAT x0dx0ax0dx0aWHERE NAME IN x0dx0ax0dx0a('parse time cpu', 'parse time elapsed', 'parse count (hard)'); x0dx0ax0dx0a這里parse time cpu是系統服務時間，parse time elapsed是響應時間，用戶等待時間 x0dx0ax0dx0awaite time = parse time elapsed _ parse time cpu x0dx0ax0dx0a由此可以得到用戶SQL語句平均解析等待時間＝waite time / parse count。這個平均等待時間應該接近於0，如果平均解析等待時間過長，資料庫管理員可以通過下述語句 x0dx0ax0dx0aSELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS FROM V$SQLAREA x0dx0ax0dx0aORDER BY PARSE_CALLS; x0dx0ax0dx0a來發現是什麼SQL語句解析效率比較低。程序員可以優化這些語句，或者增加ORACLE參數SESSION_CACHED_CURSORS的值。 x0dx0ax0dx0a2、資料庫管理員還可以通過下述語句： x0dx0ax0dx0aSELECT BUFFER_GETS, EXECUTIONS, SQL_TEXT FROM V$SQLAREA; x0dx0ax0dx0a查看低效率的SQL語句，優化這些語句也有助於提高CPU的利用率。 x0dx0ax0dx0a3、3、資料庫管理員可以通過v$system_event數據字典中的「latch free」統計項查看ORACLE資料庫的沖突情況，如果沒有沖突的話，latch free查詢出來沒有結果。如果沖突太大的話，資料庫管理員可以降低spin_count參數值，來消除高的CPU使用率。 x0dx0ax0dx0a內存參數的調整 x0dx0ax0dx0a內存參數的調整主要是指ORACLE資料庫的系統全局區（SGA）的調整。SGA主要由三部分構成：共享池、數據緩沖區、日誌緩沖區。 x0dx0ax0dx0a1、 1、 共享池由兩部分構成：共享SQL區和數據字典緩沖區，共享SQL區是存放用戶SQL命令的區域，數據字典緩沖區存放資料庫運行的動態信息。資料庫管理員通過執行下述語句： x0dx0ax0dx0aselect (sum(pins - reloads)) / sum(pins) "Lib Cache" from v$librarycache; x0dx0ax0dx0a來查看共享SQL區的使用率。這個使用率應該在90％以上，否則需要增加共享池的大小。資料庫管理員還可以執行下述語句： x0dx0ax0dx0aselect (sum(gets - getmisses - usage - fixed)) / sum(gets) "Row Cache" from v$rowcache; x0dx0ax0dx0a查看數據字典緩沖區的使用率，這個使用率也應該在90％以上，否則需要增加共享池的大小。 x0dx0ax0dx0a2、 2、 數據緩沖區。資料庫管理員可以通過下述語句： x0dx0ax0dx0aSELECT name, value FROM v$sysstat WHERE name IN ('db block gets', 'consistent gets','physical reads'); x0dx0ax0dx0a來查看資料庫數據緩沖區的使用情況。查詢出來的結果可以計算出來數據緩沖區的使用命中率＝1 - ( physical reads / (db block gets + consistent gets) )。 x0dx0ax0dx0a這個命中率應該在90％以上，否則需要增加數據緩沖區的大小。 x0dx0ax0dx0a3、 3、 日誌緩沖區。資料庫管理員可以通過執行下述語句： x0dx0ax0dx0aselect name,value from v$sysstat where name in ('redo entries','redo log space requests');查看日誌緩沖區的使用情況。查詢出的結果可以計算出日誌緩沖區的申請失敗率： x0dx0ax0dx0a申請失敗率＝requests/entries，申請失敗率應該接近於0，否則說明日誌緩沖區開設太小，需要增加ORACLE資料庫的日誌緩沖區。
❸ 怎樣保持Oracle資料庫SQL性能的穩定性
有客戶遇到SQL性能不穩定 突然變差導致系統性能出現嚴重問題的情況 對於大型的系統來說 SQL性能不穩定 有時突然變差 這是常常遇到的問題 這也是一些DBA的挑戰
對於使用Oracle資料庫的應用系統 有時會出現運行得好好的SQL 性能突然變差 特別是對於OLTP類型系統執行頻繁的核心SQL 如果出現性能問題 通常會影響整個資料庫的性能 進而影響整個系統的正常運行 對於個別的SQL 比如較少使用的查詢報表之類的SQL 如果出現問題 通常隻影響少部分功能模塊 而不會影響整個系統
那麼應該怎麼樣保持SQL性能的穩定性？
SQL的性能變差 通常是在SQL語句重新進行了解析 解析時使用了錯誤的執行計劃出現的 下列情況是SQL會重新解析的原因
SQL語句沒有使用綁定變數 這樣SQL每次執行都要解析
SQL長時間沒有執行 被刷出SHARED POOL 再次執行時需要重新解析
在SQL引用的對象（表 視圖等）上執行了DDL操作 甚至是結構發生了變化 比如建了一個索引
對SQL引用的對象進行了許可權更改森拿
重新分析（收集統計信息）了SQL引用的表和索引 或者表和索引統計信息被刪除
修改了與性能相關的部分參數
刷新了共享池
當然重啟資料庫也會使所有SQL全部重新解析
SQL重新解析後 跟以前相比 性能突然變差 通常是下列原因
表和索引的優化統計信息被刪除 或者重新收集後統計信息不準確 重新收集統計信息通常是由於收集策略（方法）不正確引起 比如對分區表使用 *** yze命令而不是用dbms_stats包 收集統計信息時采樣比例過小等等 Oracle優化器嚴重依賴於統計信息 如果統計信息有問題 則很容易導致SQL不能使用正確的執行計劃
SQL綁定變數窺螞祥探(bind peeking) 同時綁定變數對應的列上有直方圖 或者綁定變數的值變化范圍過大 分區數據分布極不均勻
） 綁定變數的列上有悶春搏直方圖
假如表orders存儲所有的訂單 state列有 種不同的值 表示未處理 表示處理成功完成 表示處理失敗 State列上有一個索引 表中絕大部分數據的state列為 和 佔少數 有下面的SQL
select * from orders where state=:b
這里:b 是變數 在大多數情況下這個值為 則應該使用索引 但是如果SQL被重新解析 而第一次執行時應用傳給變數b 值為 則不會使用索引 採用全表掃描的方式來訪問表 對於綁定變數的SQL 只在第一次執行時才會進行綁定變數窺探 並以此確定執行計劃 該SQL後續執行時全部按這個執行計劃 這樣在後續執行時 b 變數傳入的值為 的時候 仍然是第一次執行時產生的執行計劃 即使用的是全表掃描 這樣會導致性能很差
） 綁定變數的值變化范圍過大
同樣假如orders表有一列created_date表示一筆訂單的下單時間 orders表裡面存儲了最近 年的數據 有如下的SQL
Select * from orders where created_date >=:b ;
假如大多數情況下 應用傳入的b 變數值為最近幾天內的日期值 那麼SQL使用的是created_date列上的索引 而如果b 變數值為 個月之前的一個值 那麼就會使用全表掃描 與上面描述的直方圖引起的問題一樣 如果SQL第 次執行時傳入的變數值引起的是全表掃描 那麼將該SQL後續執行時都使用了全表掃描 從而影響了性能
） 分區數據量不均勻
對於范圍和列表分區 可能存在各個分區之間數據量極不均勻的情況下 比如分區表orders按地區area進行了分區 P 分區只有幾千行 而P 分區有 萬行數據 同時假如有一列proct_id 其上有一個本地分區索引 有如下的SQL
select * from orders where area=:b and proct_id =:b
這條SQL由於有area條件 因此會使用分區排除 如果第 次執行時應用傳給b 變數的值正好落在P 分區上 很可能導致SQL採用全表掃描訪問 如前面所描述的 導致SQL後續執行時全部使用了全表掃描
其他原因 比如表做了類似於MOVE操作之後 索引不可用 對索引進行了更改 當然這種情況是屬於維護不當引起的問題 不在本文討論的范圍
綜上所述 SQL語句性能突然變差 主要是因為綁定變數和統計信息的原因 注意這里只討論了突然變差的情況 而對於由於數據量和業務量的增加性能逐步變差的情況不討論
為保持SQL性能或者說是執行計劃的穩定性 需要從以下幾個方面著手
規劃好優化統計信息的收集策略 對於Oracle g來說 默認的策略能夠滿足大部分需求 但是默認的收集策略會過多地收集列上的直方圖 由於綁定變數與直方圖固有的矛盾 為保持性能穩定 對使用綁定變數的列 不收集列上的直方圖 對的確需要收集直方圖的列 在SQL中該列上的條件就不要用綁定變數 統計信息收集策略 可以考慮對大部分表 使用系統默認的收集策略 而對於有問題的 可以用DBMS_STATS LOCK_STATS鎖定表的統計信息 避免系統自動收集該表的統計信息 然後編寫腳本來定製地收集表的統計信息 腳本中類似如下
exec dbms_stats unlock_table_stats…
exec dbms_stats gather_table_stats…
exec dbms_stats lock_table_stats…
修改SQL語句 使用HINT 使SQL語句按HINT指定的執行計劃進行執行 這需要修改應用 同時需要逐條SQL語句進行 加上測試和發布 時間較長 成本較高 風險也較大
修改隱含參數 _optim_peek_user_binds 為FALSE 修改這個參數可能會引起性能問題（這里討論的是穩定性問題）
使用OUTLINE 對於曾經出現過執行計劃突然變差的SQL語句 可以使用OUTLINE來加固其執行計劃 在 g中DBMS_OUTLN CREATE_OUTLINE可以根據已有的執行正常的SQL游標來創建OUTLINE 如果事先對所有頻繁執行的核心SQL使用OUTLINE加固執行計劃 將最大可能地避免SQL語句性能突然變差
注 DBMS_OUTLN可以通過$ORACLE_HOME/rdbms/admin/dbmsol sql腳本來安裝
使用SQL Profile SQL Profile是Oracle g之後的新功能 此處不再介紹 請參考相應的文檔
除此之外 可以調整一些參數避免潛在的問題 比如將 _btree_bitmap_plans 參數設置為FALSE（這個參數請參考互聯網上的文章或Oracle文檔）
lishixin/Article/program/Oracle/201311/18054
❹ Oracle資料庫強制索引
當where子句對某一列使用函數時 除非利用這個簡單的技術強制索引 否則Oracle優化器不能在查詢中使用索引
通常情況下 如果在WHERE子句中不使用諸如UPPER REPLACE 或SUBSTRD等函數 就不能對指定列建立特定的條件 但如果使用了這些函數 則會出現一粗鬧個問題 這些函數會阻礙Oracle優化器對列使用索引 因而與採用索引的情況相比較 查詢會花費更多的時間
慶幸的是 如果在使用函數的這些列中包含了字元型數據 可以用這樣一種方法修改查詢語句 以達到強制性使用索引 更有效地運行查詢 這篇文章介紹了涉及的技術 並說明了在兩種典型情況下怎樣實現
大小寫混合情況在討論由於函數修改了列的內容 如何強制使用索引前 讓我們首先看看為什麼Oracle優化器在這種情況下不能使用索引 假定我們要搜尋包含了大小寫混合的數據 如在表 中ADDRESS表的NAME列 因為數據是用戶輸入的 我們無法使用已經統一改為大寫的數據 為了找到每一個名為john的地址 我們使用包含了UPPER子句的查詢語句 如下所示
SQL> select address from address where upper(name) like JOHN ;
在運行這個查詢語句前 如果我們運行了命令 set autotrace on 將會得到下列結果 其中包含了執行過程
ADDRESS cleveland row selected Execution Plan SELECT STATEMENT TABLE ACCESS FULL ADDRESS
可以看到 在這種情況下 Oracle優化器對ADDRESS 表作了一次完整的掃描 而沒有使用NAME 列的索引 這是因為索引是根據列中數據的實際值建立的 而UPPER 函數已經將字元轉換成大寫 即修改了這些值 因此該查詢不能使用這列的索引 優化器不能與索引項比較 JOHN 沒有索引項對應於 JOHN 只有 john
值得慶幸的是 如果在這種情況下想要強制使用索引 有一種簡便的方法 只要在WHERE 子句中增加一個或多個特定友凳扮的條件 用於測試索引值 並減少需要掃描的行 但這並沒有修改原來SOL 編碼中的條件 以下列查詢語句為例
SQL> select address from address where upper(name) like JO% AND (name like J% or name like j% );
使用這種查詢語句（已設置AUTOTRACE） 可得到下列結果
ADDRESS cleveland row selected Execution Plan SELECT STATEMENT CONCATENATION TABLE ACCESS BY INDEX ROWID ADDRESS INDEX RANGE SCAN ADDRESS_I TABLE ACCESS BY INDEX ROWID ADDRESS INDEX RANGE SCAN ADDRESS_I
現在 優化器為WHERE 子句中AND 聯結的兩個語句中每一個語句確定的范圍進行掃描 第二個語句沒有引用函數 因而使用了索引 在兩個范圍掃描後 將運行結果合並
在這個例子中 如果資料庫有成百上千行 可以用下列方法擴充WHERE 子句 進一步縮小掃描范圍
select address from address where upper(name) like JOHN AND (name like JO% or name like jo% or name like Jo or name like jO );
得到的結果與以前相同 但是 其執行過程如好灶下所示 表明有 個掃描范圍
Execution Plan SELECT STATEMENT CONCATENATION TABLE ACCESS BY INDEX ROWID ADDRESS INDEX RANGE SCAN ADDRESS_I TABLE ACCESS BY INDEX ROWID ADDRESS INDEX RANGE SCAN ADDRESS_I TABLE ACCESS BY INDEX ROWID ADDRESS INDEX RANGE SCAN ADDRESS_I TABLE ACCESS BY INDEX ROWID ADDRESS INDEX RANGE SCAN ADDRESS_I
如果試圖進一步提高查詢速度 我們可以在特定的 name like 條件中指明 個或更多的字元 然而 這樣做會使得WHERE子句十分笨重 因為需要大小寫字元所有可能的組合 joh Joh jOh joH等等 除此之外 指定一個或兩個字元已足以加快查詢的運行速度了
現在讓我們看看 當我們引用不同的函數時 怎樣運用這個基本技術
使用REPLACE的情況正如名字不總是以大寫輸入一樣 電話號碼也會以許多格式出現 如 （ ） 等等
如果在列名為 PHONE_NUMBER中搜尋上述號碼時 可能需要使用函數REPLACE以保證統一的格式 如果在PHONE_NUMBER列中只包含空格 連字元和數字 where 子句可以如下所示
WHERE replace(replace(phone_number ) ) =
WHERE子句兩次使用REPLACE 函數去掉了連字元和空格 保證了電話號碼是簡單的數字串 然而 該函數阻止了優化器在該列使用索引 因此 我們按如下方法修改WHERE子句 以強制執行索引
WHERE replace(replace(phone_number ) ) = AND phone_number like %
如果我們知道數據中可能包含圓括弧 WHERE 子句會稍微復雜一點 我們可以再增加REPLACE 函數（去掉圓括弧 連字元和空格） 按如下所示擴充增加的條件
WHERE replace(replace(replace(replace(phone_number ) ) ( ) ) ) = AND (phone number like % or phone_number like ( % )
該例強調了巧妙地選用WHERE 子句條件的重要性 而且 這些條件不會改變查詢結果 你的選擇應基於完全了解該列中存在的信息類型 在該例中 我們需要知道 PHONE_NUMBER 數據中存在幾種不同的格式 這樣 我們能夠修改WHERE 子句而不會影響查詢結果
正確的條件 lishixin/Article/program/Oracle/201311/18519
❺ ORACLE索引提高效率
用索引漏氏提高效率
索引是表的一個概念部分 用來提高檢索數據的效率 實際上 ORACLE使用了一個復雜的自平衡B tree結構 通常 通過索引查詢數據比全表掃描要快 當ORACLE找出執行查詢和Update語句的最佳路徑時 ORACLE優化器將使用索引 同樣在聯結多個表時使用索引也可以提高效率 另一個使用索引的好處是 它提供了主鍵(primary key)的唯一性驗證
除了那些LONG或LONG RAW數據類型 你可以索引幾乎所有的列 通常 在大型表中使用索引特別有效 當然 你也會發現 在掃描小表時 使用索引同樣能提高效率
雖然使用索引能得到查詢效率的提高 但是我們也必須注意到它的代價 索引需要空間來
存儲 也辯搜辯需要定期維護 每當有記錄在表中增減或索引列被修改時 索引本身也會被修改 這意味著每條記錄的INSERT DELETE UPDATE將為此多付出 次的磁碟I/O 因為索引需要額外的存儲空間和處理 那些不必要的索引反而會使查詢反應時間變慢
定期的重構索引是有必要的
ALTER INDEX <INDEXNAME> REBUILD <TABLESPACENAME>
索引的操作
ORACLE對索引有兩種訪問模式
索引唯一掃描 ( INDEX UNIQUE SCAN)
大多數情況下 優化器通過WHERE子句訪問INDEX
例如:
表LODGING有兩個索引 : 建立在LODGING列上的唯一性索引LODGING_PK和建立在MANAGER列上的非唯一性索引LODGING$MANAGER
SELECT * FROM LODGING
WHERE LODGING = ROSE HILL ;
在內部 上述SQL將被分成兩步執行 首先 LODGING_PK 索引將通過索引唯一掃描的方式被訪問 獲得相對應的ROWID 通過ROWID訪問表的方式 執行下一步檢索
如果被檢索返回的列包括在INDEX列中 ORACLE將不執行第二步的處理(通過ROWID訪問表) 因為檢索數據保存在索引中 單單訪問索引就可以完全滿足查詢結果
下面SQL只需要INDEX UNIQUE SCAN 操作
SELECT LODGING FROM LODGING WHERE LODGING = ROSE HILL ;
索引范圍查詢(INDEX RANGE SCAN)
適用於兩種情況:
基於一個范圍攜缺的檢索
基於非唯一性索引的檢索
例 :
SELECT LODGING FROM LODGING WHERE LODGING LIKE M% ;
WHERE子句條件包括一系列值 ORACLE將通過索引范圍查詢的方式查詢LODGING_PK 由於索引范圍查詢將返回一組值 它的效率就要比索引唯一掃描低一些
例 :
SELECT LODGING FROM LODGING WHERE MANAGER = BILL GATES ;
這個SQL的執行分兩步 LODGING$MANAGER的索引范圍查詢(得到所有符合條件記錄的ROWID) 和下一步同過ROWID訪問表得到LODGING列的值 由於LODGING$MANAGER是一個非唯一性的索引 資料庫不能對它執行索引唯一掃描
由於SQL返回LODGING列 而它並不存在於LODGING$MANAGER索引中 所以在索引范圍查詢後會執行一個通過ROWID訪問表的操作
WHERE子句中 如果索引列所對應的值的第一個字元由通配符(WILDCARD)開始 索引將不被採用
SELECT LODGING FROM LODGING WHERE MANAGER LIKE ％HANMAN ;
在這種情況下 ORACLE將使用全表掃描
基礎表的選擇
基礎表(Driving Table)是指被最先訪問的表(通常以全表掃描的方式被訪問) 根據優化器的不同 SQL語句中基礎表的選擇是不一樣的
如果你使用的是CBO (COST BASED OPTIMIZER) 優化器會檢查SQL語句中的每個表的物理大小 索引的狀態 然後選用花費最低的執行路徑
如果你用RBO (RULE BASED OPTIMIZER) 並且所有的連接條件都有索引對應 在這種情況下 基礎表就是FROM 子句中列在最後的那個表
舉例:
SELECT A NAME B MANAGER FROMWORKER A LODGING B
WHEREA LODGING = B LODING;
由於LODGING表的LODING列上有一個索引 而且WORKER表中沒有相比較的索引 WORKER表將被作為查詢中的基礎表
多個平等的索引
當SQL語句的執行路徑可以使用分布在多個表上的多個索引時 ORACLE會同時使用多個索引並在運行時對它們的記錄進行合並 檢索出僅對全部索引有效的記錄
在ORACLE選擇執行路徑時 唯一性索引的等級高於非唯一性索引 然而這個規則只有
當WHERE子句中索引列和常量比較才有效 如果索引列和其他表的索引類相比較 這種子句在優化器中的等級是非常低的
如果不同表中兩個想同等級的索引將被引用 FROM子句中表的順序將決定哪個會被率先使用 FROM子句中最後的表的索引將有最高的優先順序
如果相同表中兩個想同等級的索引將被引用 WHERE子句中最先被引用的索引將有最高的優先順序
舉例:
DEPTNO上有一個非唯一性索引 EMP_CAT也有一個非唯一性索引
SELECT ENAME FROM EMP WHERE DEPT_NO = AND EMP_CAT = A ;
這里 DEPTNO索引將被最先檢索 然後同EMP_CAT索引檢索出的記錄進行合並 執行路徑如下:
TABLE ACCESS BY ROWID ON EMP AND EQUAL INDEX RANGE SCAN ON DEPT_IDX
INDEX RANGE SCAN ON CAT_IDX
等式比較和范圍比較
當WHERE子句中有索引列 ORACLE不能合並它們 ORACLE將用范圍比較
舉例:
DEPTNO上有一個非唯一性索引 EMP_CAT也有一個非唯一性索引
SELECT ENAME FROM EMP WHERE DEPTNO > AND EMP_CAT = A ;
這里只有EMP_CAT索引被用到 然後所有的記錄將逐條與DEPTNO條件進行比較 執行路徑如下:
TABLE ACCESS BY ROWID ON EMP
INDEX RANGE SCAN ON CAT_IDX
不明確的索引等級
當ORACLE無法判斷索引的等級高低差別 優化器將只使用一個索引 它就是在WHERE子句中被列在最前面的
舉例:
DEPTNO上有一個非唯一性索引 EMP_CAT也有一個非唯一性索引
SELECT ENAME FROM EMP WHERE DEPTNO > AND EMP_CAT > A ;
這里 ORACLE只用到了DEPT_NO索引 執行路徑如下:
TABLE ACCESS BY ROWID ON EMP
INDEX RANGE SCAN ON DEPT_IDX
我們來試一下以下這種情況:
SQL> select index_name uniqueness from user_indexes where table_name = EMP ;
INDEX_NAME UNIQUENES
EMPNO UNIQUE
EMPTYPE NONUNIQUE
SQL> select * from emp where empno >= and emp_type = A ;
no rows selected
Execution Plan
SELECT STATEMENT Optimizer=CHOOSE
TABLE ACCESS (BY INDEX ROWID) OF EMP
INDEX (RANGE SCAN) OF EMPTYPE (NON UNIQUE)
雖然EMPNO是唯一性索引 但是由於它所做的是范圍比較 等級要比非唯一性索引的等式比較低!
強制索引失效
如果兩個或以上索引具有相同的等級 你可以強制命令ORACLE優化器使用其中的一個(通過它 檢索出的記錄數量少)
舉例:
SELECT ENAME FROM EMP WHERE EMPNO =
AND DEPTNO + = /*DEPTNO上的索引將失效*/
AND EMP_TYPE || = A /*EMP_TYPE上的索引將失效*/
這是一種相當直接的提高查詢效率的辦法 但是你必須謹慎考慮這種策略 一般來說 只有在你希望單獨優化幾個SQL時才能採用它
這里有一個例子關於何時採用這種策略
假設在EMP表的EMP_TYPE列上有一個非唯一性的索引而EMP_CLASS上沒有索引
SELECT ENAME FROM EMP WHERE EMP_TYPE = A AND EMP_CLASS = X ;
優化器會注意到EMP_TYPE上的索引並使用它 這是目前唯一的選擇 如果 一段時間以後 另一個非唯一性建立在EMP_CLASS上 優化器必須對兩個索引進行選擇 在通常情況下 優化器將使用兩個索引並在他們的結果集合上執行排序及合並 然而 如果其中一個索引（EMP_TYPE）接近於唯一性而另一個索引（EMP_CLASS）上有幾千個重復的值 排序及合並就會成為一種不必要的負擔 在這種情況下 你希望使優化器屏蔽掉EMP_CLASS索引
用下面的方案就可以解決問題
SELECT ENAME FROM EMP WHERE EMP_TYPE = A AND EMP_CLASS|| = X ;
避免在索引列上使用計算．
WHERE子句中 如果索引列是函數的一部分．優化器將不使用索引而使用全表掃描．
舉例:
低效
SELECT … FROM DEPT WHERE SAL * > ;
高效:
SELECT … FROM DEPT WHERE SAL > / ;
自動選擇索引
如果表中有兩個以上（包括兩個）索引 其中有一個唯一性索引 而其他是非唯一性．
在這種情況下 ORACLE將使用唯一性索引而完全忽略非唯一性索引．
舉例:
SELECT ENAME FROM EMP WHERE EMPNO =
AND DEPTNO = ;
這里 只有EMPNO上的索引是唯一性的 所以EMPNO索引將用來檢索記錄．
TABLE ACCESS BY ROWID ON EMP
INDEX UNIQUE SCAN ON EMP_NO_IDX
避免在索引列上使用NOT
通常 我們要避免在索引列上使用NOT NOT會產生在和在索引列上使用函數相同的
影響 當ORACLE 遇到 NOT 他就會停止使用索引轉而執行全表掃描
舉例:
低效: (這里 不使用索引)
SELECT … FROM DEPT WHERE DEPT_CODE NOT = ;
高效: (這里 使用了索引)
SELECT … FROM DEPT WHERE DEPT_CODE > ;
需要注意的是 在某些時候 ORACLE優化器會自動將NOT轉化成相對應的關系操作符
NOT > to <=
NOT >= to <
NOT < to >=
NOT <= to >
SQL> select * from emp where NOT empno > ;
no rows selected
Execution Plan
SELECT STATEMENT Optimizer=CHOOSE
TABLE ACCESS (BY INDEX ROWID) OF EMP
INDEX (RANGE SCAN) OF EMPNO (UNIQUE)
SQL> select * from emp where empno <= ;
no rows selected
Execution Plan
SELECT STATEMENT Optimizer=CHOOSE
TABLE ACCESS (BY INDEX ROWID) OF EMP
INDEX (RANGE SCAN) OF EMPNO (UNIQUE)
兩者的效率完全一樣 也許這符合作者關於 在某些時候 ORACLE優化器會自動將NOT轉化成相對應的關系操作符 的觀點．
用>=替代>
如果DEPTNO上有一個索引
高效:
SELECT * FROM EMP WHERE DEPTNO >=
低效:
SELECT * FROM EMP WHERE DEPTNO >
lishixin/Article/program/Oracle/201311/17710
❻ 資料庫性能優化有哪些措施
1、調整數據結構的設計
這一部分在開發信息系統之前完成，程序員需要考慮是否使用ORACLE資料庫的分區功能，對於經常訪問的資料庫表是否需要建立索引等。
2、調整應用程序結構設計
這一部分也是在開發信息系統之前完成，程序員在這一步需要考慮應用程序使用什麼樣的體系結構，是使用傳統的Client/Server兩層體系結構，還是使用Browser/Web/Database的三層體系結構。不同的應用程序體系結構要求的資料庫資源是不同的。
3、調整資料庫SQL語句
應用程序的執行最終將歸結為資料庫中的SQL語句執行，因此SQL語句的執行效率最終決定了ORACLE資料庫的性能。ORACLE公司推薦使用ORACLE語句優化器(OracleOptimizer)和行鎖管理器(row-levelmanager)來調整優化SQL語句。
4、調整伺服器內存分配
內存分配是在信息系統運行過程中優化配置的，資料庫管理員可以根據資料庫運行狀況調整資料庫系統全局區(SGA區)的數據緩沖區、日誌緩沖區和共享池的大小;還可以調整程序全局區(PGA區)的大小。需要注意的是，SGA區不是越大越好，SGA區過大會佔用操作系統使用的內存而引起虛擬內存的頁面交換，這樣反而會降低系統。
5、調整硬碟I/O
這一步是在信息系統開發之前完成的。資料庫管理員可以將組成同一個表空間的數據文件放在不同的硬碟上，做到硬碟之間I/O負載均衡。
6、調整操作系統參數
例如：運行在UNIX操作系統上的ORACLE資料庫，可以調整UNIX數據緩沖池的大小，每個進程所能使用的內存大小等參數。
實際上，上述資料庫優化措施之間是相互聯系的。ORACLE資料庫性能惡化表現基本上都是用戶響應時間比較長，需要用戶長時間的等待。但性能惡化的原因卻是多種多樣的，有時是多個因素共同造成了性能惡化的結果，這就需要資料庫管理員有比較全面的計算機知識，能夠敏感地察覺到影響資料庫性能的主要原因所在。另外，良好的資料庫管理工具對於優化資料庫性能也是很重要的。
一、ORACLE資料庫性能優化工具
常用的資料庫性能優化工具有：
ORACLE資料庫在線數據字典，ORACLE在線數據字典能夠反映出ORACLE動態運行情況，對於調整資料庫性能是很有幫助的。
操作系統工具，例如UNIX操作系統的vmstat，iostat等命令可以查看到系統系統級內存和硬碟I/O的使用情況，這些工具對於管理員弄清出系統瓶頸出現在什麼地方有時候很有用。
SQL語言跟蹤工具(SQLTRACEFACILITY)，SQL語言跟蹤工具可以記錄SQL語句的執行情況，管理員可以使用虛擬表來調整實例，使用SQL語句跟蹤文件調整應用程序性能。SQL語言跟蹤工具將結果輸出成一個操作系統的文件，管理員可以使用TKPROF工具查看這些文件。
ORACLEEnterpriseManager(OEM)，這是一個圖形的用戶管理界面，用戶可以使用它方便地進行資料庫管理而不必記住復雜的ORACLE資料庫管理的命令。
EXPLAINPLAN——SQL語言優化命令，使用這個命令可以幫助程序員寫出高效的SQL語言。
二、ORACLE資料庫的系統性能評估
信息系統的類型不同，需要關注的資料庫參數也是不同的。資料庫管理員需要根據自己的信息系統的類型著重考慮不同的資料庫參數。
1、在線事務處理信息系統(OLTP)，這種類型的信息系統一般需要有大量的Insert、Update操作，典型的系統包括民航機票發售系統、銀行儲蓄系統等。OLTP系統需要保證資料庫的並發性、可靠性和最終用戶的速度，這類系統使用的ORACLE資料庫需要主要考慮下述參數：
資料庫回滾段是否足夠?
是否需要建立ORACLE資料庫索引、聚集、散列?
系統全局區(SGA)大小是否足夠?
SQL語句是否高效?
2、數據倉庫系統(DataWarehousing)，這種信息系統的主要任務是從ORACLE的海量數據中進行查詢，得到數據之間的某些規律。資料庫管理員需要為這種類型的ORACLE資料庫著重考慮下述參數：
是否採用B*-索引或者bitmap索引?
是否採用並行SQL查詢以提高查詢效率?
是否採用PL/SQL函數編寫存儲過程?
有必要的話，需要建立並行資料庫提高資料庫的查詢效率
三、SQL語句的調整原則
SQL語言是一種靈活的語言，相同的功能可以使用不同的語句來實現，但是語句的執行效率是很不相同的。程序員可以使用EXPLAINPLAN語句來比較各種實現方案，並選出最優的實現方案。總得來講，程序員寫SQL語句需要滿足考慮如下規則：
1、盡量使用索引。試比較下面兩條SQL語句：
語句A：SELECTdname,
(SELECTdeptnoFROMemp);
語句B：SELECTdname,deptnoFROMdeptWHERENOTEXISTS
(SELECTdeptnoFROMempWHEREdept.deptno=emp.deptno);
這兩條查詢語句實現的結果是相同的，但是執行語句A的時候，ORACLE會對整個emp表進行掃描，沒有使用建立在emp表上的deptno索引，執行語句B的時候，由於在子查詢中使用了聯合查詢，ORACLE只是對emp表進行的部分數據掃描，並利用了deptno列的索引，所以語句B的效率要比語句A的效率高一些。
2、選擇聯合查詢的聯合次序。考慮下面的例子：
SELECTstuffFROMtabaa,tabbb,tabcc
WHEREa.acolbetween:alowand:ahigh
ANDb.bcolbetween:blowand:bhigh
ANDc.ccolbetween:clowand:chigh
ANDa.key1=b.key1
AMDa.key2=c.key2;
這個SQL例子中，程序員首先需要選擇要查詢的主表，因為主表要進行整個表數據的掃描，所以主表應該數據量最小，所以例子中表A的acol列的范圍應該比表B和表C相應列的范圍小。
3、在子查詢中慎重使用IN或者NOTIN語句，使用where(NOT)exists的效果要好的多。
4、慎重使用視圖的聯合查詢，尤其是比較復雜的視圖之間的聯合查詢。一般對視圖的查詢最好都分解為對數據表的直接查詢效果要好一些。
5、可以在參數文件中設置SHARED_POOL_RESERVED_SIZE參數，這個參數在SGA共享池中保留一個連續的內存空間，連續的內存空間有益於存放大的SQL程序包。
6、ORACLE公司提供的DBMS_SHARED_POOL程序可以幫助程序員將某些經常使用的存儲過程「釘」在SQL區中而不被換出內存，程序員對於經常使用並且佔用內存很多的存儲過程「釘」到內存中有利於提高最終用戶的響應時間。
四、CPU參數的調整
CPU是伺服器的一項重要資源，伺服器良好的工作狀態是在工作高峰時CPU的使用率在90%以上。如果空閑時間CPU使用率就在90%以上，說明伺服器缺乏CPU資源，如果工作高峰時CPU使用率仍然很低，說明伺服器CPU資源還比較富餘。
使用操作相同命令可以看到CPU的使用情況，一般UNIX操作系統的伺服器，可以使用sar_u命令查看CPU的使用率，NT操作系統的伺服器，可以使用NT的性能管理器來查看CPU的使用率。
資料庫管理員可以通過查看v$sysstat數據字典中「CPUusedbythissession」統計項得知ORACLE資料庫使用的CPU時間，查看「OSUserlevelCPUtime」統計項得知操作系統用戶態下的CPU時間，查看「OSSystemcallCPUtime」統計項得知操作系統系統態下的CPU時間，操作系統總的CPU時間就是用戶態和系統態時間之和，如果ORACLE資料庫使用的CPU時間占操作系統總的CPU時間90%以上，說明伺服器CPU基本上被ORACLE資料庫使用著，這是合理，反之，說明伺服器CPU被其它程序佔用過多，ORACLE資料庫無法得到更多的CPU時間。
資料庫管理員還可以通過查看v$sesstat數據字典來獲得當前連接ORACLE資料庫各個會話佔用的CPU時間，從而得知什麼會話耗用伺服器CPU比較多。
出現CPU資源不足的情況是很多的：SQL語句的重解析、低效率的SQL語句、鎖沖突都會引起CPU資源不足。
1、資料庫管理員可以執行下述語句來查看SQL語句的解析情況：
SELECT*FROMV$SYSSTATWHERENAMEIN
('parsetimecpu','parsetimeelapsed','parsecount(hard)');
這里parsetimecpu是系統服務時間，parsetimeelapsed是響應時間，用戶等待時間，waitetime=parsetimeelapsed_parsetimecpu
由此可以得到用戶SQL語句平均解析等待時間=waitetime/parsecount。這個平均等待時間應該接近於0，如果平均解析等待時間過長，資料庫管理員可以通過下述語句
SELECTSQL_TEXT,PARSE_CALLS,EXECUTIONSFROMV$SQLAREA
ORDERBYPARSE_CALLS;
來發現是什麼SQL語句解析效率比較低。程序員可以優化這些語句，或者增加ORACLE參數SESSION_CACHED_CURSORS的值。
2、資料庫管理員還可以通過下述語句：
SELECTBUFFER_GETS,EXECUTIONS,SQL_TEXTFROMV$SQLAREA;
查看低效率的SQL語句，優化這些語句也有助於提高CPU的利用率。
3、資料庫管理員可以通過v$system_event數據字典中的「latchfree」統計項查看ORACLE資料庫的沖突情況，如果沒有沖突的話，latchfree查詢出來沒有結果。如果沖突太大的話，資料庫管理員可以降低spin_count參數值，來消除高的CPU使用率。
五、內存參數的調整
內存參數的調整主要是指ORACLE資料庫的系統全局區(SGA)的調整。SGA主要由三部分構成：共享池、數據緩沖區、日誌緩沖區。
1、共享池由兩部分構成：共享SQL區和數據字典緩沖區，共享SQL區是存放用戶SQL命令的區域，數據字典緩沖區存放資料庫運行的動態信息。資料庫管理員通過執行下述語句：
select(sum(pins-reloads))/sum(pins)"LibCache"fromv$librarycache;
來查看共享SQL區的使用率。這個使用率應該在90%以上，否則需要增加共享池的大小。資料庫管理員還可以執行下述語句：
select(sum(gets-getmisses-usage-fixed))/sum(gets)"RowCache"fromv$rowcache;
查看數據字典緩沖區的使用率，這個使用率也應該在90%以上，否則需要增加共享池的大小。
2、數據緩沖區。資料庫管理員可以通過下述語句：
SELECTname,valueFROMv$sysstatWHEREnameIN('dbblockgets','consistentgets','physicalreads');
來查看資料庫數據緩沖區的使用情況。查詢出來的結果可以計算出來數據緩沖區的使用命中率=1-(physicalreads/(dbblockgets+consistentgets))。
這個命中率應該在90%以上，否則需要增加數據緩沖區的大小。
3、日誌緩沖區。資料庫管理員可以通過執行下述語句：
selectname,valuefromv$sysstatwherenamein('redoentries','redologspacerequests');
查看日誌緩沖區的使用情況。查詢出的結果可以計算出日誌緩沖區的申請失敗率：
申請失敗率=requests/entries，申請失敗率應該接近於0，否則說明日誌緩沖區開設太小，需要增加ORACLE資料庫的日誌緩沖區。
昆明北大青鳥java培訓班轉載自網路如有侵權請聯系我們感謝您的關注謝謝支持
❼ 在oracle資料庫中，影響優化器生成執行計劃的因素有哪些
9i前的RBO不熟，也就不敢妄言。
關於10g後的CBO，談下我的理解。
首先，影響優化器執行計劃最主要的因素是統計信息。優化器根據統計信息情況，單表上選擇全表掃描還是索引。表聯接方式上選擇嵌套，哈希還是合並排序。不同的統計信息將會生成不同的執行計劃。很多時候發現之前跑的好好的sql，突然變慢了，多數情況下重新收集下統計信息便解決了。統計信息這一塊需要關注直方圖這一塊，很多生產環境都存在數據傾斜的情況，如若未准確收集直方圖，那麼生成的執行計劃便有失偏頗。
--------------------------------------------------------------------------------------------------------------------
第二點，sql語句的寫法問題。比如欄位上有索引，但謂詞條件寫成like '%xxx%'方式，將導致該欄位上索引不可用。比如表連接方式用<>之類，將無法使用hash join。其實這些與其說是寫法問題，倒不如說是oracle自身有一定的編碼規則，符合該規則條件，方可用到index之類。
--------------------------------------------------------------------------------------------------------------------
第三點，也是最無奈的一點，CBO的自身缺陷問題。很多時候，統計信息是最新的，也符合寫法規范，但CBO就是不生成我們所期待的執行計劃。這個時候，通常要改變sql語句的邏輯寫法，比如標量子查詢可否換成左連接，用with as替換一些子查詢等，以期待oracle生成更高效率的執行計劃。另外，就是使用hint來迫使CBO生成你所期待的執行計劃，但CBO不一定就範。
談及缺陷，也不算不上缺陷，尤其是表越多，將會出現更多排列的可能性，oracle不可能將所有執行計劃都生成出來然後選擇一個最優的，定是按照一定比例擇取，但具體多少，我不詳。也就是說，DBA完全可以憑借自身對你所管理的oracle了解程度，給sql語句指定一個最優的執行計劃。
--------------------------------------------------------------------------------------------------------------------
其他還有一些細節問題，可在日常工作中慢慢體會，cbo還是相當強大的。
❽ 如何修改oracle優化器模式
ALTERSYSTEMSETOPTIMIZER_MODE=ALL_ROWSscope=both;
其他可以選擇的脊猛模式還有RULE/CHOOSE/FIRST_ROWS/ALL_ROWS。
應用系統優化最好對大查皮野簡詢單獨調優，修改優燃褲化器模式之後，有可能別的查詢又會變慢。
❾ cbo是什麼意思
一、CBO （基於代價的優化方式）
CBO是Cost-Based Optimization的縮寫，中文叫做「基於成本的優化。」
Oracle的優化器有兩種優化方式,即基於規則的優化方式(Rule-Based Optimization，簡稱為RBO)和基於代價的優化方式(Cost-Based Optimization，簡稱為CBO)，在Oracle8及以後的版本,Oracle強烈推薦用CBO的方式。
二、CBO（首席品牌官）
CBO（Chief Brand Officer）首席品牌官，是現代組織（包括企業、政府或其他組織）中設置的專門負責品牌戰略管理與運營的高級官員歲褲，代表CEO就企業形象、品牌以及文化進行內外部溝通。
三、CBO（國會預算辦公室）
CBO是美國 國會預算辦公室國會下設的一個專業的、非黨派的機構，成立於1975年，沒有審批權游漏。
四、CBO （ORACLE提供的一種SQL優化器）
ORACLE提供的一種SQL優化器。
ORACLE提供了CBO、RBO兩種SQL優化器。CBO在ORACLE7 引入，但在ORACLE8i 中才成熟。ORACLE 已經明確聲明在ORACLE9i之後的版本中(ORACLE 10G )，RBO將不再支持。
五、CBO（市場流通債券的再證券化）
Collateralised Bond Obligation，即市場流通債券的再證券化，是CDO（擔神雀爛保債務權證）的一個分支。
❿ 如何進行oracle資料庫性能優化
你最好買一本專門講ORACLE性能優化的書，好好看看\x0d\x0a1、調整資料庫伺服器的性能\x0d\x0aOracle資料庫伺服器是整個系統的核心，它的性能高低直接影響整個系統的性能，為了調整Oracle資料庫伺服器的性能，主要從以下幾個方面考慮： \x0d\x0a1.1、調整操作系統以適合Oracle資料庫伺服器運行\x0d\x0aOracle資料庫伺服器很大程度上依賴於運行伺服器的操作系統，如果操作系統不能提供最好性能，那麼無論如何調整，Oracle資料庫伺服器也無法發揮其應有的性能。 \x0d\x0a1.1.1、為Oracle資料庫伺服器規劃系統資源 \x0d\x0a據已有計算機可用資源, 規劃分配給Oracle伺服器資源原則是：盡可能使Oracle伺服器使用資源最大化,特別在Client/Server中盡量讓伺服器上所有資源都來運行Oracle服務。 \x0d\x0a1.1.2、調整計算機系統中的內存配置 \x0d\x0a多數操作系統都用虛存來模擬計算機上更大的內存，它實際上是硬碟上的一定的磁碟空間。當實際的內存空間不能滿足應用軟體的要求時，操作系統就將用這部分的磁碟空間對內存中的信息進行頁面替換，這將引起大量的磁碟I/O操作，使整個伺服器的性能下降。為了避免過多地使用虛存，應加大計算機的內存。 \x0d\x0a1.1.3、為Oracle資料庫伺服器設置操作系統進程優先順序 \x0d\x0a不要在操作系統中調整Oracle進程的優先順序，因為在Oracle資料庫系統中，所有的後台和前台資料庫伺服器進程執行的是同等重要的工作，需要同等的優先順序。所以在安裝時，讓所有的資料庫伺服器進程都使用預設的優先順序運行。 \x0d\x0a1.2、調整內存分配\x0d\x0aOracle資料庫伺服器保留3個基本的內存高速緩存，分別對應3種不同類型的數據：庫高速緩存，字典高速緩存和緩沖區高速緩存。庫高速緩存和字典高速緩存一起構成共享池，共享池再加上緩沖區高速緩存便構成了系統全程區(SGA)。SGA是對資料庫數據進行快速訪問的一個系統全程區，若SGA本身需要頻繁地進行釋放、分配，則不能達到快速訪問數據的目的，因此應把SGA放在主存中，不要放在虛擬內存中。內存的調整主要是指調整組成SGA的內存結構的大小來提高系統性能，由於Oracle資料庫伺服器的內存結構需求與應用密切相關，所以內存結構的調整應在磁碟I/O調整之前進行。 \x0d\x0a1.2.1、庫緩沖區的調整 \x0d\x0a庫緩沖區中包含私用和共享SQL和PL/SQL區，通過比較庫緩沖區的命中率決定它的大小。要調整庫緩沖區，必須首先了解該庫緩沖區的活動情況，庫緩沖區的活動統計信息保留在動態性能表v$librarycache數據字典中，可通過查詢該表來了解其活動情況，以決定如何調整。 \x0d\x0a \x0d\x0aSelect sum(pins),sum(reloads) from v$librarycache; \x0d\x0a \x0d\x0aPins列給出SQL語句，PL/SQL塊及被訪問對象定義的總次數；Reloads列給出SQL 和PL/SQL塊的隱式分析或對象定義重裝載時在庫程序緩沖區中發生的錯誤。如果sum(pins)/sum(reloads) ≈0，則庫緩沖區的命中率合適；若sum(pins)/sum(reloads)>1, 則需調整初始化參數 shared_pool_size來重新調整分配給共享池的內存量。 \x0d\x0a1.2.2、數據字典緩沖區的調整 \x0d\x0a數據字典緩沖區包含了有關資料庫的結構、用戶、實體信息。數據字典的命中率，對系統性能影響極大。數據字典緩沖區的使用情況記錄在動態性能表v$librarycache中，可通過查詢該表來了解其活動情況，以決定如何調整。 \x0d\x0a \x0d\x0aSelect sum(gets),sum(getmisses) from v$rowcache; \x0d\x0a \x0d\x0aGets列是對相應項請求次數的統計；Getmisses 列是引起緩沖區出錯的數據的請求次數。對於頻繁訪問的數據字典緩沖區，sum(getmisses)/sum(gets)<10%～15%。若大於此百分數，則應考慮增加數據字典緩沖區的容量，即需調整初始化參數shared_pool_size來重新調整分配給共享池的內存量。 \x0d\x0a1.2.3、緩沖區高速緩存的調整 \x0d\x0a用戶進程所存取的所有數據都是經過緩沖區高速緩存來存取，所以該部分的命中率，對性能至關重要。緩沖區高速緩存的使用情況記錄在動態性能表v$sysstat中，可通過查詢該表來了解其活動情況，以決定如何調整。 \x0d\x0a \x0d\x0aSelect name,value from v$sysstat where name in ('dbblock gets','consistent gets','physical reads'); \x0d\x0a \x0d\x0adbblock gets和consistent gets的值是請求數據緩沖區中讀的總次數。physical reads的值是請求數據時引起從盤中讀文件的次數。從緩沖區高速緩存中讀的可能性的高低稱為緩沖區的命中率，計算公式： \x0d\x0a \x0d\x0aHit Ratio=1-(physical reds/(dbblock gets+consistent gets)) \x0d\x0a \x0d\x0a如果Hit Ratio<60%～70%，則應增大db_block_buffers的參數值。db_block_buffers可以調整分配給緩沖區高速緩存的內存量，即db_block_buffers可設置分配緩沖區高速緩存的數據塊的個數。緩沖區高速緩存的總位元組數=db_block_buffers的值*db_block_size的值。db_block_size 的值表示數據塊大小的位元組數，可查詢 v$parameter 表： \x0d\x0a \x0d\x0aselect name,value from v$parameter where name='db_block_size'; \x0d\x0a \x0d\x0a在修改了上述資料庫的初始化參數以後，必須先關閉資料庫，在重新啟動資料庫後才能使新的設置起作用。