熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Oracle >> 正文

優化策略

2013-11-13 16:00:19  來源: Oracle 

  性能調試的一般問題
  
   Introduction 介紹
  
  本文檔包括了最一般的調優策略關於各部分的更專門的信息可以通過提供的鏈接得到
  
   Shared Pool and Library Cache Performance Tuning 共享池和Library Cache的調優
  
  Oracle將SQL語句存儲包對象信息和很多其他的項目保存在SGA中一個叫共享池(shared pool)的地方這個可共享的區域由一個成熟的高速緩存和堆管理器管理它有個基本的問題要克服
  
  ) 內存分配的單元不是個常量從池中分配的內存單元可能是從幾個字節到幾千個字節
  
  ) 在用戶完成工作時不是所有的內存都能夠釋放出來因為共享池的目標是使信息最大程度的共享
  
  ) 沒有一個象其他常規的高速緩存的文件做後備的存儲那樣磁盤空間供整頁的導出
  
  只有可重新創建的信息可以從Cache中丟棄在他被再次需要的時候再重新創建
  
  共享池調優的技巧有
  
  刷( Flush)共享池可以使小塊的內存合並為大塊的內存當共享池的碎片過多時這能夠暫時恢復性能刷共享池可以使用語句alter system flush shared_pool;
   注意執行這個語句將會造成性能的暫時尖峰因為對象都要重新加載所以應當在數據庫的負載不是很大的情況下進行
  
   確保聯機事務處理( OLTP)應用使用綁定變量 (bind variables) 這一點對於決策支持系統(DSS)並不重要
  
   確保library cache 的命中率 > %
  
   增大共享池並不總能解決命中率過多的問題
  
   Buffer Cache Performance Tuning 數據庫緩存調優
  
  數據庫緩存保持了從磁盤上讀去的數據塊的備份
  
  因為緩存通常受到內存約束的限制不是磁盤上所有的數據都可以放到緩存裡當緩存滿了的時候後來的緩存不中使得Oracle將已經在緩存中的數據寫到磁盤上後續的對寫到磁盤上的數據的訪問還會造成緩存不中
  
  數據庫緩存調優的技巧如下
  
  避免以下的問題
  
   緩存的最近最少使用(LRN)鏈cache buffers LRU chain )的加鎖競爭
  
   平均寫隊列Average Write Queue )長度過大
  
   過多時間花在等待寫完畢等待上write complete waits
  
   過多時間花在等待緩沖釋放等待上 (free buffer waits
  
   Latch Contention 加鎖(插銷)競爭
  
  插銷加鎖是SGA中保護共享數據結構的低層的串行化機制插銷latch是一類可以非常快的獲得和釋放的鎖插銷鎖的實現是依賴於操作系統的尤其在關於一個進程是否會等待一個鎖和等多久方面
  
  有如下的鎖(插銷)需要調優:
  
   Redo Copy/Allocation Latch 重寫日志的復制/分配插銷
  
   Shared Pool Latch 共享池的插銷
  
   Library Cache Latch Library Cache插銷
  
  
  
   Redo Log Buffer Performance Tuning 重寫日志緩沖的調優
  
  LGWR 將重寫日志緩沖中的重寫項寫到重寫日志文件中
  
  一旦LGWR將這些項復制到重寫日志文件中用戶進程就可以重寫這些項統計項目redo log space requests反映了用戶進程等待重寫日志緩沖中空間的時間的數字
  
  設置重寫日志大小的一些提示:
  
   redo log space requests的值應該接近
  
   設定合適的重寫日志的大小建議每分鐘進行一次重寫日志的切換
  
   Query Performance Tuning 查詢效率的調優
  
  如果查詢運行得很慢請考慮這些方面:
  
   你希望這個查詢運行的有多快以及有理由這樣要求嗎?
  
   優化模式OPTIMIZER_MODE 設為何值?
  
   查詢涉及的索引都是有效的嗎?
  
   在數據庫中有沒有其他的長時間運行的查詢(大查詢)
  
  對於CBO(基於成本的優化)In case of CBO:
  
   表和索引上有統計信息嗎?
  
   統計信息是被計算出來的還是被估計出來的?
  
  對於查詢的性能調整由兩個主要的調試工具
  
   TKPROF
  
   AUTOTRACE
  
  
  
   Rollback Segment Performance Tuning 回滾段的調優
  
  Oracle數據庫提供了任何數據庫對象上的SELECT INSERT UPDATE 和DELETE 操作的讀一致性回滾段用於保存由那些要回滾的動作或系統需要產生一個和前面某一時間讀一致的影像所產生的可取消事務
  
  設置回滾段大小的技巧如下
  
   建議最少每個事務一個回滾段
  
   建議為長時間運行的大查詢提供一個大回滾段
  
   v$rollstat中的wrap數接近否則增大擴展大小(extent size)
  
   SELECT bname awraps FROM V$ROLLSTAT a V$ROLLNAME b;
  
  
  
   Temporary Tablespace Performance Tuning 臨時表空間的調優
  
  從RDBMS release 開始Oracle引入了臨時表空間的概念這個表空間用於保存臨時對象如排序段排序段采用它所在的表空間的缺省存儲參數(DEFAULT STORAGE (NEXT) 子句)作為自己的存儲參數
  
  臨時表空間的調優的技巧如下:
  
   如果即使在穩定的狀態下也存在很多的排序擴展鎖(Sort Extent Pool latch)的競爭你應該通過修改臨時表空間的DEFAULT STORAGE 子句的NEXT值來增大擴展塊的大小
  
   如果存在很多的排序擴展鎖(Sort Extent Pool latch)的競爭並且這種等待是由於過多的並發的排序造成的你應該增大SORT_AREA_SIZE參數的大小以使更多的排序能保存在內存中
  
   建議讓擴展塊的大小和SORT_AREA_SIZE參數相同
  
   以此例說明為什麼 假設你的 extent size = K 而 sort_area_size = Mg
  
  現在如果有個到磁盤的排序每次都要做K的擴展這會導致性能的降低
  
   Utlbstat/Utlestat Performance Tuning Utlbstat/Utlestat調優
  
  Bstat/Estat 是一堆存放在你的$ORACLE_HOME/rdbms/admin目錄下的SQL腳本他們對於捕獲系統范圍的數據庫性能統計的快照非常有用UTLESTAT 創建這些視圖的第二個快照並將兩個快照之間的差異報告到文件 reporttxt
  
  Bstatsql 在你的sys用戶下創建一系列的表和視圖其中包括開始時數據庫性能統計的快照
  
  Estatsql在你的sys用戶下創建一系列的表其中包括結束時數據庫性能統計的快照和一個叫 reporttxt的文件
  
  一些技巧:
  
   確保你已經將TIMED_STATSTICS設為TRUE (這僅僅給數據庫操作增加了一點非常小的開銷)
  
   確保數據庫在運行utlbstat前已經啟動並且運行了一段時間
  
   從svrmgrl 中而不是sql*plus中運行utbstatsql和utlestatsql
  
   確保在腳本utlbstat/estat運行時數據庫不被Down掉否則產生的統計就不正確
  
   至少運行utlbstat/estat 個小時才好調試你的數據庫
  
  
  
   Checkpoint Performance Tuning 檢查點性能調優
  
  檢查點( Checkpoint)是一個數據庫事件用來同步內存和磁盤上的數據文件中的數據塊檢查點的目的有兩個
  
  () 建立數據的一致性
  () 是數據庫恢復更快
  
  調優檢查點進程有如下的技巧
  
   CKPT進程能夠明顯的提高效率來降低用戶等待一個檢查點操作完畢所需的時間
  
   如果LOG_CHECKPOINT_INTERVAL的值比重寫日志( redo log)的大小大那麼 checkpoint只在ORACLE進行日志從一個組到另一組切換的時候才發生這正是我們希望的這個行為在 Oracle i中有了變化
  
  當把LOG_CHECKPOINTS_TO_ALERT設為TRUE時將把checkpoint啟動和停止的時間記錄在alert log日志裡這對於你確定checkpoint是否正以最佳的頻率發生很有幫助
  
   理想的情況是checkpoint在僅在日志切換時發生
  
   Import Performance Tuning 數據載入性能調優
  
  沒有什麼固定的信息是關於如何加速那些慢得讓人難以忍受的import的顯然import要花費它完成所需要的時間但是作一些事情可以縮短他們所花的時間

From:http://tw.wingwit.com/Article/program/Oracle/201311/17655.html
  • 上一篇文章:

  • 下一篇文章:
  • 推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.