Effective Oracle by Design筆記

last updated 2006-04-29

Effective Oracle by Design
第一章 構建應用程式的正確方法
1.以資料庫獨立的名義,拒絕利用特定資料庫的特性,拒絕擴充套件其功能.這實際是選擇了取消而不是利用公司為之付出了金錢的大多數功能.
2.設計出效能而不是調整出效能.
3.知道一個系統是否調整好的唯一辦法是規定某種指標.如果滿足或超過該指標,系統就算調整好了.
4.沒有適用於任何情形的普遍規律.事實上,如果你讀到關於比率的內容時,就應該引起警覺.並不是比率沒有用,而是它們獨自沒有用,它們必須與其他因素結合才有意義.
5.支援你成功的正是基礎知識,而不是某些神奇的引數.

第二章 效能工具包
1.dbms_xplan:?/rdbms/admin/utlxpls
2.AUTOTRACE輸出中感興趣的內容
1)Recursive Calls:由於需要執行其他SQL語句而必須執行的SQL.
2)Db Block Gets和Consistent Gets:當前方式的讀取是當該塊存在時檢索它.可以看到這種方式在update語句中最常見.一致性讀取是以"讀一致性"方式從高速緩衝中檢索塊並且可能會包括讀取UNDO.
客戶機和伺服器需要的RAM數量會隨著ARRAY SIZE的增加而增加.
3)Physical Reads:表或索引資料的一個物理讀取把某塊放入緩衝快取記憶體中,然後我們執行一個邏輯I/O檢索該塊.因為大多數的物理讀取後都直接跟著一個邏輯I/O.(臨時表空間除外)
4)Redo Size:
直接路徑插入只在兩種情形下繞過重做日誌的生成.a)資料庫為NOARCHIVELOG方式 b)標記為NOLOGGING的表上執行操作
對資料倉儲的批次裝載a)設定索引為UNUSABLE b)設定會話跳過UNUSABLE索引並進行批次裝載 c)重新啟用索引
5)SQL*NET統計:
應只選擇解決問題所需要的列--不多,也不少.
3.TKPROF
將跟蹤檔案轉換為容易使用的格式.
當花費的時間大於CPU時間時,就意味著為某些事情耗費了等待時間
CPU時間怎麼會大於佔用的時間?這個誤差是由於收集各定時資料並試圖記錄最快的操作或許多操作的時間而引起的.
4.Runstat
關注Latch的爭用.
5.Stackpack
擁有好時段的歷史記錄就如同擁有壞時段的歷史記錄一樣重要.
報告中的重要部分:Hard parse/Executes/Transactions/Library Hit %/Soft parse %/Execute to Parse %
CPU Time不是一個真正的等待事件而是該會話使用的CPU的總和,在擁有大量裝載的系統中,若CPU事件事件是最大的事件,則意味著某些CPU密集型的處理可能是導致瓶頸的願意
6.DBMS_PROFILER

第三章 體系結構的選擇
1.瞭解共享伺服器與專用伺服器連線
2.叢集
1)橫向擴充套件--新增更多的機器增強系統功能的能力
2)高可用性
一個資料庫可同時被許多例項安裝和開啟,這就是關於RAC的所有內容了
例項--邏輯概念
資料庫--物理概念
一個例項在其生存期間只能安裝和開啟一個資料庫
SID標識一個例項,而服務標識一個或多個例項的集合
3.瞭解何時使用分割槽
最佳化程式排除分割槽不予考慮極為有用,從效能的角度來看,是使用分割槽的主要原因
如果在非分割槽鍵上建立本地分割槽索引,在使用該索引的時候反而會影響效能(需要訪問全部分割槽),但管理上會有所方便.
一個邏輯I/O意味著一個Latch,一個Latch為一個Lock,Lock會降低應用系統的可伸縮性.
為何使用分割槽?1)提供可用性 2)易於管理 3)提高效能
在應用分割槽之前,應該明白使用分割槽的目的是什麼?想使用分割槽降低管理開銷?提高可用性?提高效能?
4.何時使用並行操作
並行+分而治之是提高速度的可行性方法
並行操作是針對量大,時間長的操作,它會使這些操作更快.
CTAS/CREATE INDEX/ALTER INDEX REBUILD/ALTER TABLE MOVE/ALTER TABLE SPLIT PARTITION/ALTER INDEX COALESCE
這些操作通常可以使用並行.
-- 關注外部表(裝載資料)
為了在oracle中使用PDML,需要對錶進行分割槽,設定並行度為基礎分割槽的數目.V$PX_PROCESS
PERCENTILE_DISC函式(9i or higher)
在一開始設計時使用這種方法作用最大.
DBMS_PCLXUIL程式包.