“神話”這個詞指的是Oracle的那些從未是真的或者曾經是真的，但是現在不是真的的行為的基本情況。大多數的Oracle神話的起源都是技更換術產生的結果。 大多數的人都認為今天的許多Oracle神話在他們那個年代都是真實的(例如，“磁盤負載平衡對于性能非常重要”)，但是當硬件和Oracle軟件都改進了之后卻發現它們都變成了神話。 我們不要忘記Oracle的技術已經超過了15年了，1989年的技術也與今天的技術大相徑庭。幸運的是，大多數Oracle的專業人員都充分理解了Oracle神話的不斷改變，曾經正確的建議今天是如何變得不再正確，并且成為了具有神話色彩的謊言。 古老的Oracle神話 有許多古老的Oracle技術在過去都是非常有用的，但是當技術改變的時候，成為了神話。問題的混亂是上千家運行在古老的硬件并且不支持發布的Oracle 軟件的Oracle店鋪帶來的。讓我們看一些比較古老的神話。 神話:對象在單區域內執行得更好 Oracle大學在20世紀90年代的早期教授了compress=y 輸出選項會到達改善結果表的性能。今天，本地治理的表空間(LMT)讓這個建議不再有效。 神話:數據緩沖命中率應該保持在超過90%的概率 這個神話也是Oracle在90年代早期宣傳的，當時幾乎全部的Oracle數據庫的I/O成為了瓶頸，并且SGA的尺寸也被32位的服務器技術所限制了?；贠racle的產品，例如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的性能公開了誤導他人的言論，從而制造了新的神話: “一致是不可能的，也不會被任何的優化人員的設置所影響?！彼麄冇绊懥藘灮藛T處理事物的方式;但是他們卻沒有影響事物真正進行的方式。 當然，改變optimizer_mode, optimizer_index_cost_adj和 optimizer_index_caching 的值可以改變優化人員對于是否應該做一個完全的掃描或者索引訪問執行計劃的判定，這也會對所有查詢的一致性數量產生直接的影響。 目前Oracle的專業人員分成兩個截然不同的群體，每個群體都會Oracle的性能調整有著完全不同的看法，每個群體都認為對方是造成持續不斷的Oracle神話的罪魁禍首。 “經驗法則”神話——許多Oracle專業人員都相信“經驗法則”(ROT)是非常危險的，并且都了解假如經驗法則可以被證實是錯誤的，即使是在單個的人為的測試中，經驗法則在科學上來說都不再是正確的，因此也就是毫無用處了。 “腳本小子”神話——這個神話說的是運行單用戶的SQL*Plus 腳本來“證實”的Oracle的運行方式，在多用戶的數據庫中幾乎總是錯誤的。