兩週前，公司組織了一個社外培訓，不容易啊，工作了這麼久，第一次參加社外培訓，4天就4000多大洋
效果還不錯，我純粹是去掃盲了。。。哈哈，不過還是瞭解到了Oracle的一些原理，知道了原來軟件真的是一大抄。。。
鑑於培訓之前，衚衕學的要求，要把有用的東西分享給公司的各位。
我現在又這麼的無聊，就把這些學了的東西慢慢的一天天的寫出來吧。
第一篇就從前兩天的一個問題說起吧。
前兩天遇到一個shanze同學發的問題，說site1的預約受付都是6秒，其他site都是3秒，數據一樣，程序一樣，時間不同。
而且，一直如此。
既然這樣，可以判斷，不是GUI的問題
理由1:site1一直如此，在其他site就只有一半的時間，如果是GUI的問題雖然也是會要慢就會一直慢，但是，當環境不同的時候，應該也是一樣慢，不會有如此的特別
理由2:site1的數據正常，登陸一個預約記錄，會生成400個左右項目，數據很普通
那麼，可能的原因就應該是各個site的不同之比較了。
首先是數據量，衆所周知，基礎數據量會影響到性能，若基礎數據量相差的很大的話，也是可以理解比其他site慢的。
所以，爲了有理有據，我做了一個實驗，在現有數據量的基礎上，登陸一條預約，然後逐漸把數據量增大，判斷時間的增量。
這個基礎數據量的考量也是需要特殊判斷的，要抓住主要矛盾，才能找出主要的制約，因爲這樣的問題我早已有了相當的經驗，故，選用了the_d_exam_result_item表來作爲增長對象。
當這個表的數據量在不到2,000,000的時候，大概只有不到2秒的時間
當這個表的數據量在增長了一個數量級，20,000,000的時候，明顯的，同樣的數據登陸時，發現到了5秒之多。
所以，初步判定是因爲基礎數據量太大。
但是。。。不幸的是，後來shanze同學把我的結論給否定了。
因爲nanshusite的數據量更加大，達到了100,000,000，但他們的登陸卻不慢。
這個時候的我被逼，無語，不知爲何。但想到當時老師講的東西，想想終於有了用武之地了。
數據庫的配置，我以前是純屬蒙，這兒看一點那兒看一點。這回有了系統的知識，就不慌了。
首先，比較SGA區，SGA區是保存共享數據的，在我們的共享服務器式的Oracle數據庫裏，這個SGA區越大，每回能保存的東西就越多，這樣就能儘量多的把經常運行的SQL，數據等保存在內存裏，而不用頻繁的去做IO讀取，當時老師講過，讀硬盤和讀內存的區別有多大呢，沒有具體的數據，但可以給一個數據級的比較，1w倍。這樣，如果IO過多，產生熱點，大家都去瘋狂讀硬盤，肯定就需要大量的CPU，甚至造成等待。
比較的結果是，SGA區都是自動設定的，SIZE=0，沒戲。自動設定就是Oracle自己根據運行情況自動分配SGA區。故，排除
其次，比較Share_pool，雖然看上去都是自動分配的，但是，share_pool的大小卻是有了兩倍之差，site1的share_pool是160M，site2的share_pool是360M，這麼大的區別，肯定是會發生很大的差別的。雖然具體有多大我不好估計，但從這裏入手應該是正常的
接着，比較IO，site1的數據文件基本上都是區分的user空間的數據文件，site2的數據文件就不同了，有一個專門的數據文件用於保存D_kensa的數據，還有幾個文件是專門保存履歷信息的，因爲只讀的話，產生的爭用就比較少，而且，履歷數據的存在其實使用的頻度並不高，但如果跟當年的數據保存在一起的話，會造成基礎數據量大。
而且，site2的IO比site1的少了一個位數，看上去原因找到了，site1雖然有多個數據文件，但每個數據文件的IO都比較平均，site2有比site1更多的數據文件，但IO只集中在前幾個數據文件，履歷的數據文件基本不訪問。
這樣，IO爭用當然就少了，造成的CPU負擔也就少了很多了。這樣等待就少，等待少了肯定時間就短了。這個也是，理論，因無法真的去調試現場的DB，也就沒有實踐的數據了。。。。
這樣的兩個理由，讓shanze同學去確認現場DB了，果然，shanze同學從那以後就去確認，再也沒理我。。。
總結一下，其實調優，如果有的調，最好是調CPU，調內存，如果服務器的內存不夠多，CPU不夠強，可以直接先上好機器，上大內存，甚至上大型機，上RAC，上集羣，總之，調硬件是一個入手的方位
不過，在健診中，這個可不好，我們決定不了日本的服務器，就只能在現有的硬件基礎上，進行相應的優化，DB端的優化，無非也就是加大SGA區，一般建議將物理內存的一半設定爲SGA區，加大緩存區，將數據文件分開，減少IO
這個SGA區呢，健診一般都是自動的，所以數據文件這裏就值得研究一下了，數據庫的數據都保存在數據文件中，按照表空間-段-區-塊來存儲，其實每條數據的Rowid就標識出這個數據存儲於哪個區的哪個塊了，所以，如果經常被訪問的數據，放在同一個數據文件中，那麼這個數據文件被讀的可能性就會增高，加上還會往裏寫的話，就自然會發生IO問題，解決的話，把不同的數據分到不同的數據文件中，進行讀寫分離。
比如，健診的M表，一般都是讀，那麼適合把M表的數據放到一個數據文件中，其他寫入比較多的表放到另一個數據文件中，就會盡量減少讀寫的資源爭用了。
健診的D表呢，寫入多，讀取也多，這時候，如果把數據分離爲履歷和當時的數據，也可以減小數據文件的大小，使讀寫儘可能限制在小範圍內。
具體的建表SQL，稍後添付