第1章 效能調整綜述
oracle資料庫是高度可調的資料庫產品。本章描述調整的過程和那些人員應與oracle伺服器的調整有關，以及與調整相關聯的作業系統硬體和軟體。本章包括以下方面:
l 誰來調整系統?
l 什麼時候調整?
l 建立有效調整的目標
l 在設計和開發時的調整
l 調整產品系統
l 監控產品系統
誰來調整系統:
為了有效地調整系統，若干類人員必須交換資訊並牽涉到系統調整中，例如:
l 應用設計人員必須傳達應用系統的設計，使得每個人都清楚應用中的資料流動.
l 應用開發人員必須傳達他們選擇的實現策略，使得語句調整的過程中能快速、容易地識別有問題的應用模組和可疑的sql語句.
l 資料庫管理人員必須仔細地監控系統活動並提供它們的資料，使得異常的系統效能可被快速得識別和糾正.
l 硬體/軟體管理人員必須傳達系統的硬體、軟體配置並提供它們的資料，使得相關人員能有效地設計和管理系統。
簡而言之，與系統涉及的每個人都在調整過程中起某些作用，當上面提及的那些人員傳達了系統的特性並提供了它們的資料，調整就能相對的容易和更快一些。
不幸的是，事實上的結果是：資料庫管理員對調整負有全部或主要的責任。但是，資料庫管理員很少有合適的系統方面的資料，而且，在很多情況下，資料庫管理員往往是在實施階段才介入資料庫，這就給調整工作帶來許多負面的影響，因為在設計階段的缺陷是不能通過dba的調整而得以解決，而設計階段的缺陷往往對資料庫效能造成極大的影響。
其實，在真正成熟的開發環境下，開發人員作為純**編寫人員時，對效能的影響最小，此時大部分的工作應由應用設計人員完成，而且資料庫管理員往往在前期的需求管理階段就介入，為設計人員提供必要的技術支援。調整並不是資料庫管理員的專利，相反大部分應該是設計人員和開發人員的工作，這就需要設計人員和開發人員具體必要的資料庫知識，這樣才能組成乙個高效的團隊，然而事實上往往並非如此。
什麼時候作調整？
多數人認為當使用者感覺效能差時才進行調整，這對調整過程中使用某些最有效的調整策略來說往往是太遲了。此時，如果你不願意重新設計應用的話，你只能通過重新分配記憶體(調整sga)和調整i/o的辦法或多或少地提高效能。oracle提供了許多特性，這些特性只有應用到正確地設計的系統中時才能夠很大地提高效能。
應用設計人員需要在設計階段設定應用的效能期望值。然後在設計和開發期間，應用設計人員應考慮哪些oracle 特性可以對系統有好處，並使用這些特性。
通過良好的系統設計，你就可以在應用的生命週期中消除效能調整的代價和挫折。圖1-1圖1-2說明在應用的生命週期中調整的相對代價和收益，正如你見到的，最有效的調整時間是在設計階段。在設計期間的調整能以最低的代價給你最大的收益。
圖1-1 在應用生命週期中調整的代價
圖1-2 在應用生命週期中調整的收益
當然，即使在設計很好的系統中，也可能有效能降低。但這些效能降低應該是可控的和可以預見的。
調整目標
不管你正在設計或維護系統，你應該建立專門的效能目標，它使你知道何時要作調整。如果你試圖胡亂地改動初始化引數或sql 語句，你可能會浪費調整系統的時間，而且無什麼大的收益。調整你的系統的最有效方法如下：
l 當設計系統時考慮效能
l 調整作業系統的硬體和軟體
l 識別效能瓶頸
l 確定問題的原因
l 採取糾正的動作
當你設計系統時，制定專門的目標；例如，響應時間小於３秒。當應用不能滿足此目標時，識別造成變慢的瓶頸（例如，i/o競爭），確定原因，採取糾正動作。在開發期間，你應測試應用研究，確定在採取應用之前是否滿足設計的效能目標。
當你正在維護生產庫系統時，有多種快速有效的方法來識別效能瓶頸。不管怎樣，調整通常是一系列開銷。一旦你已確定了瓶頸，你可能要犧牲一些其它方面的指標來達到所要的結果。例如，如果i/o有問題，你可能需要更多記憶體或磁碟。如果不可能買，你可能要限制系統的併發性，來獲取所需的效能。然而，如果你已經明確地定義了效能的目標，那用什麼來交換高效能的決策就變的很容易的，因為你已經確定了哪些方面是最重要的，如過我的目標為高效能，可能犧牲一些空間資源。
隨著應用的越來越龐大，硬體效能的提高，全面的調整應用逐漸變成代價高昂的行為，在這樣情況下，要取得最大的投入/效率之比，較好的辦法是調整應用的關鍵部分，使其達到比較高的效能，這樣從總體上來說，整個系統的效能也是比較高的。這也就是有名的20/80原則，調整應用的20%(關鍵部分)，能解決80%的問題。
在設計和開發系統時作調整
良好設計的系統可以防止在應用生命週期中產生效能問題。系統設計人員和應用開發人員必須了解oracle的查詢處理機制以便寫出高效的sql語句。「第2章 有效的應用設計」討論了你的系統中各種可用的配置，以及每種配置更適合哪種型別的應用。「第5章 優化器」討論了oracle的查詢優化器，以及如何寫語句以獲取最快的結果。
當設計你的系統時，使用下列優化效能的準則：
l 消除客戶機／伺服器應用中不必要的網路傳輸。-- 使用儲存過程。
l 使用適合你系統的相應oracle伺服器選件（例如，並行查詢或分布式資料庫）。
l 除非你的應用有特殊的需要，否則使用預設的oracle鎖。
l 利用資料庫記住應用模組，以便你能以每個模組為基礎來追蹤效能。
l 選擇你的資料塊的最佳大小。 -- 原則上來說大一些的效能較好。
l 分布你的資料，使得乙個節點使用的資料本地存貯在該節點中。
調整產品系統
本節描述對應用系統快速、容易地找出效能瓶頸，並決定糾正動作的方法。這種方法依賴於對oracle伺服器體系結構和特性的了解程度。在試圖調整你的系統前，你應熟悉oracle調整的內容。
為調整你已有的系統，遵從下列步驟：
l 調整作業系統的硬體和軟體
l 通過查詢v $session_wait檢視，識別效能的瓶頸，這個動態效能檢視列出了造成會話(session)等待的事件。
l 通過分析v $session_wait中的資料，決定瓶頸的原因。
l 糾正存在的問題。
監控應用系統
這主要是通過監控oracle的動態檢視來完成。各種有用的動態檢視：如v$session_wait, v$session_event等。
第2章 有效的應用設計
我們通常將最常用的應用分為2種型別：聯機事務處理型別(oltp)，決策支援系統(dss)。
聯機事務處理(oltp)
該型別的應用是高吞吐量，插入、更新、刪除操作比較多的系統，這些系統以不斷增長的大容量資料為特徵，它們提供給成百使用者同時訪問，典型的oltp系統是訂票系統，銀行的業務系統，訂單系統。otlp的主要目標是可用性、速度、併發性和可恢復性。當設計這類系統時，必須確保大量的併發使用者不能干擾系統的效能。還需要避免使用過量的索引與cluster 表，因為這些結構會使插入和更新操作變慢。
決策支援(dss)
該型別的應用將大量資訊進行提取形成報告，協助決策者作出正確的判斷。典型的情況是：決策支援系統將oltp應用收集的大量資料進行查詢。典型的應用為客戶行為分析系統(超市，保險等)。決策支援的關鍵目標是速度、精確性和可用性。該種型別的設計往往與oltp設計的理念背道而馳，一般建議使用資料冗餘、大量索引、cluster table、並行查詢等。近年來，該型別的應用逐漸與olap、資料倉儲緊密的聯絡在一起，形成的乙個新的應用方向。
通過分析SQL語句的執行計畫優化SQL 四
五 oracle的執行計畫 背景知識 為了更好的進行下面的內容我們必須了解一些概念性的術語 共享sql語句 為了不重複解析相同的sql語句 因為解析操作比較費資源，會導致效能下降 在第一次解析之後，oracle將sql語句及解析後得到的執行計畫存放在記憶體中。這塊位於系統全域性區域sga syste...
通過分析SQL語句的執行計畫優化SQL 三
四 oracle的優化器 優化器有時也被稱為查詢優化器，這是因為查詢是影響資料庫效能最主要的部分，不要以為只有select語句是查詢。實際上，帶有任何where條件的dml insert update delete 語句中都包含查詢要求，在後面的文章中，當說到查詢時，不一定只是指select語句，也...
通過分析SQL語句的執行計畫優化SQL 五
rowid的概念 rowid是乙個偽列，既然是偽列，那麼這個列就不是使用者定義，而是系統自己給加上的。對每個表都有乙個rowid的偽列，但是表中並不物理儲存rowid列的值。不過你可以像使用其它列那樣使用它，但是不能刪除改列，也不能對該列的值進行修改 插入。一旦一行資料插入資料庫，則rowid在該行...