打破oracle資料庫神話

來自：TechTarget  Mike Ault

    “神話”這個詞指的是Oracle的那些從未是真的或者曾經是真的，但是現在不是真的的行為的基本情況。大多數的Oracle神話的起源都是技更換術產生的結果。

　　大多數的人都認為今天的許多Oracle神話在他們那個年代都是真實的(例如，“磁碟Server Load Balancer對於效能非常重要”)，但是當硬體和Oracle軟體都改進了之後卻發現它們都變成了神話。

　　我們不要忘記Oracle的技術已經超過了15年了，1989年的技術也與今天的技術大相徑庭。幸運的是，大多數Oracle的專業人員都充分理解了Oracle神話的不斷改變，曾經正確的建議今天是如何變得不再正確，並且成為了具有神話色彩的謊言。

　　古老的Oracle神話

　　有許多古老的Oracle技術在過去都是非常有用的，但是當技術改變的時候，成為了神話。問題的混亂是上千家運行在古老的硬體並且不支援發布的Oracle 軟體的Oracle店鋪帶來的。讓我們看一些比較古老的神話。

　　神話:對象在單地區內執行得更好

　　Oracle大學在20世紀90年代的早期教授了compress=y 輸出選項會到達改善結果表的效能。今天，本地管理的資料表空間(LMT)讓這個建議不再有效。

　　神話:資料緩衝命中率應該保持在超過90%的機率

　　這個神話也是Oracle在90年代早期宣傳的，當時幾乎全部的Oracle資料庫的I/O成為了瓶頸，並且SGA的尺寸也被32位的伺服器技術所限制了。基於Oracle的產品，例如SAP，也都在他們的手冊中指出了資料緩衝命中率應該超過90%。Oracle的作者Robert Freeman 提示到:

　　很多的情況都證明了要證明任何事情都是很簡單的。假設有一個基本的證據，我可以證明緩衝區命中率毫無意義，或者我可以證明它是世界上最重要的事情了。

　　我知道有一些指令碼可以運行在你的資料庫上，從而產生任何你想要的資料緩衝命中率。這看上去是不是像一個神話?Oracle看起來並不這麼認為，基於比率的建議形成了Oracle 10g自動記憶體管理工具的基礎，還有v$db_cache_advice 的建議。

　　現在也還是存在一些Oracle神話——讓我們看一下。

　　現在的Oracle神話

　　現代的Oracle神話在很大程度上都是由於Oracle技術的更換，還有一些Oracle專業人員無法調整以適應改變導致的。

　　神話:索引和表不需要分開

　　這個神話的產生根據Oracle在90年代早期提出的建議，當時有關磁碟的爭論是一個主要的話題。直到不久之前，資料庫中索引和表的分離才被認為是好的辦法，並且作為改善效能的方法被接受。

　　當然，還有一部分原因是因為他們在同一個磁碟上，如果他們不分離的話，會互相衝突。將索引移動到一塊獨立磁碟上的資料表空間上，與表相分離，而不僅僅是分隔到獨立的資料表空間上，這通常都會帶來效能上的提高。

　　主要的論據，由對單使用者系統的10046個追蹤所支援，就是在一個查詢中訪問表和索引的操作在本質上不是非同步，而是線性過程。然而，然而，即使是在單使用者的系統中，也沒有考慮到被請求的頭移動和與讀取索引以及表有關的磁碟延遲。在多使用者的環境中，也沒有考慮到以上所有的因素，以及多使用者訪問協同定位的表和索引產生的影響。

　　現在，當合理地放置了RAID之後，許多有關協同定位的問題的爭論都沒有了或者轉移了。然而，將表和索引分割到幾個資料表空間中仍然使得維護更加簡單了。分隔到離散的資料表空間中使得追蹤I/O速率和特定對象或者物件類型成為可能，並且允許使用者使用多塊尺寸。

　　神話:頻繁更新的表和索引幾乎不需要重新組織

　　這個神話是由於Oracle的專家發表的聲明引起的，他宣稱Oracle的索引總是保持平衡的，重新構建並不會給索引帶來多大的好處。下面我們看一下這個聲明，在某種程度上可以協助我們理解片段是如何產生的:

　　除非你想陷入無休止的組織、再組織、組織、再組織……的迴圈中去，你最好找一下原因。

　　在完美的世界中，你只要使用絕對正確的參數構建一次即可，永遠都不用再重新構建，我恐怕這種情況永遠都不會在現實世界中出現。就像期望只清掃你的房間一次，而這個房間裡面裝滿了吵吵鬧鬧的10幾歲的孩子——這是毫無意義的。

　　今天，能夠理解表和索引具有很高頻率的並發插入、更新和刪除動作是一件好事情，它可以很快地獲得次佳的結構並需要重新組織以便位多塊掃描操作減少I/O操作(使用Oracle的dbms_redefinition包，更改索引移動/重新構建，更改索引接合，或者甚至是根據可用性需求更改表移動)。索引平衡的概念是分兩個叉的，B樹總是高度平衡的，它也可以變得稀疏或者向右旋轉的，所以就變得更寬或者負載不平衡。

　　神話:多個塊尺寸不會改善效能

　　這個神話是不朽的，因為多個塊尺寸最初是為了支援可傳輸的資料表空間而設計的，同時一些人還不能看到多個塊尺寸帶來的另一方面很重要的好處。不同的塊尺寸帶來的最大的好處就是更加有效地利用了受到限制的記憶體地區(db_cache_size, db_32k_cache_size等)以及能夠減少多塊掃描讀取的邏輯I/O次數的對象智能隔離。

　　今天，Metalink 提示說多個塊尺寸參數是Oracle效能調整中最重要的部分了，並且還說Robin Schumacher 等專家們都證明了Oracle的索引可以在較大的塊尺寸中構建更加最佳化的B樹結構。還有，重新組織高DML 索引，或者對隨機單行讀取(唯一索引訪問)小行資料的時候使用小的塊尺寸，可以減少db_cache_size 的尺寸，並且會因為更多的塊適合了緩衝區的大小而減少PIO。

　　例如，一些實驗試圖用小的、人造的單使用者實驗來證明這個斷言，並且提出多個塊尺寸並不能給現實世界的資料庫帶來任何好處。然而，現實生活中的店鋪卻報告了一個有關多個塊尺寸和索引用的32k塊尺寸的截然不同的結果:

　　“我最近比較喜歡關注的問題就是有關32KB索引的問題:我們的用戶端(200GB+)從這個簡單的變化中看到I/O縮減了20%……”，EMEA的技術服務經理Steve Taylor 說。

　　所以，在這裡我們看到了技術的改變是如何將一項15年前本來有效方式轉換為一個“神話”的，並最終得到了一個有關單使用者測試指令碼的錯誤結論，同樣，由於技術的改變它們還會繼續建立新的現代神話。

　　Oracle神話正在形成

　　當Oracle的專業人員觀察了不同的資料庫行為之後得到了不一致的結論之後，神話還在繼續。

　　我們還可以看到Oracle公司大力推薦了一些提出觀點的先進人物，但是他們卻針對Oracle的效能公開了誤導他人的言論，從而製造了新的神話:

　　“一致是不可能的，也不會被任何的最佳化人員的設定所影響。”他們影響了最佳化人員處理事物的方式;但是他們卻沒有影響事物真正進行的方式。

　　當然，改變optimizer_mode, optimizer_index_cost_adj和 optimizer_index_caching 的值可以改變最佳化人員對於是否應該做一個完全的掃描或者索引訪問執行計畫的判斷，這也會對所有查詢的一致性數量產生直接的影響。

　　目前Oracle的專業人員分成兩個截然不同的群體，每個群體都會Oracle的效能調整有著完全不同的看法，每個群體都認為對方是造成持續不斷的Oracle神話的罪魁禍首。

　　“經驗法則”神話——許多Oracle專業人員都相信“經驗法則”(ROT)是非常危險的，並且都瞭解如果經驗法則可以被證明是錯誤的，即使是在單個的人為的測試中，經驗法則在科學上來說都不再是正確的，因此也就是毫無用處了。

　　“指令碼小子”神話——這個神話說的是運行單使用者的SQL*Plus 指令碼來“證明”的Oracle的運行方式，在多使用者的資料庫中幾乎總是錯誤的。

　　結論

　　這是我的由兩部分組成的文章中的第一部分，陳述了理解Oracle神話的基礎，並展示了我們如何知曉Oracle神話隨著時間改變。