前半生

公衆號有 Oracle  技術文章,  MySQL 的, Linux  系統的,也有投資方面的. 還有養身方面的. 
歡迎訂閱, 歡迎分享朋友圈,歡迎留言,歡迎打賞. 

祖仙教一小凡仙 公衆號: 

經過公衆號查看本書的圖片

第一章 前言

1.1 做者簡介

  本人小凡仙，真姓爲曾凡坤,一個很普通的人。

於2004年去了東莞工做，在一家臺灣工廠幹程序員活。主要是用C++BUILDER工具和微軟SQL SERVER數據庫，開發工廠的信息系統。其實就是簡化各個車間文員的工做，以及比較好的讓各部門領導查看數據而已。雖然叫ERP系統，實際就是個MIS信息管理系統！2005年來到了深圳，開始在一家軟件公司爲證券信息公司開發個信息發佈系統，使用C++BUILDER開發ORACLE數據庫。後來再去了工廠裏開發ERP系統，其實是維護ERP系統，用的是DELPHI開發ORACLE。在這裏主要是學到了PL/SQL，已經對ORACLE和LINUX系統有個基本瞭解，原本想學ERP總體思想，可時運不佳。ERP隨着經濟而萎縮，招聘職位愈來愈少。2007年轉向了ORACLE管理，得到一份DBA工做，其實就是個運維DBA。2008年的金融危機使我失去了該DBA職位。而後3年內從事的數據庫開發的工做，主要是ORACLE開發，開發什麼經營分析系統和移動139郵箱的報表系統。所以對SQL寫法，SQL執行，SQL優化是有深入的體會的。

  2013年再度回到了DBA崗位，雖然從事運維DBA，負責多個系統的集羣和災備數據庫。

幹了多年，或多或少遇到過性能問題，也盡力去優化了。感受數據庫最後端優化的空間是不大的！後來去了家物流公司，聽說這家公司在淘寶物流的單量排在第10位，不過壓力也挺大的，常常CPU飆高，負載指數達到500！

 

1.2數據庫發展史

 

 計算機的起源相信大部分大學計算機課本都有介紹，無論是科班和非科班以及職業中學都有介紹。

衆所周知的第一臺計算機是美國軍方定製，專門爲了計算彈道和射擊特性表面而研製的，承擔開發任務的「莫爾小組」由四位科學家和工程師埃克特、莫克利、戈爾斯坦、博克斯組成。1946年這臺計算機主要元器件採用的是電子管。該機使用了1500

ENIAC

個繼電器，18800個電子管，佔地170m²，重量重達30多噸，耗電150KW，造價48萬美圓。開機時讓周圍居民暫時停電。這臺計算機每秒能完成5000次加法運算，400次乘法運算，比當時最快的計算工具快300倍，是繼電器計算機的1000倍、手工計算的20萬倍。用今天的標準看，它是那樣的「笨拙」和「低級」，其功能遠不如一隻掌上可編程計算器，但它使科學家們從複雜的計算中解脫出來，它的誕生標誌着人類進入了一個嶄新的信息革命時代。

然而，英國在二戰期間研製的用於破解密電的電子計算機巨人（Colossus）卻要比ENIAC早兩年（1943年12 ），巨人計算機是第一部全然電子化的電腦器件，使用了數量龐大的真空管，以紙帶做爲輸入器件，可以執行各類布林邏輯的運算，但仍未具有圖靈徹底的標準。巨人計算機建造到第9部「馬克二號」4，可是其實體器件、設計圖樣和操做方法，直到1970年代都仍是一個謎。後來溫斯頓·丘吉爾親自下達一項銷燬命令，將巨人計算機全都拆解成巴掌大小的廢鐵，巨人計算機才所以在許多計算機歷史裏都未留下一紙紀錄。英國布萊切利園目前展有巨人計算機的重建機種。

 

 有專家說算盤也是計算機，若是從算數來講，這點不能否認！ 當算盤依舊是算盤，不是計算機。計算機是用機器來計算， 算什麼呢？天然是算古代應用數學。我國對數學的應用算盤就夠了，沒有繼續發展下去。而在歐洲應用數學就有不斷的提出高難度要求，促進了對計算數字的工具發展。計算機是從加密機和破密機發展而來的！

 英國拍了部二戰題材的電影叫《模擬遊戲》

 

講的是圖靈用機器去破譯密碼的故事。圖靈何許人？

艾倫·麥席森·圖靈（Alan Mathison Turing，1912年6月23日－1954年6月7日），英國數學家、邏輯學家，被稱爲計算機科學之父，人工智能之父。^[1] 

1931年圖靈進入劍橋大學國王學院，畢業後到美國普林斯頓大學攻讀博士學位，二戰爆發後回到劍橋，後曾協助軍方破解德國的著名密碼系統Enigma，幫助盟軍取得了二戰的勝利。

  另外我的是馮·諾依曼^[1]  （John von Neumann，1903~1957），20世紀最重要的數學家之一，在現代計算機、博弈論、核武器和生化武器等諸多領域內有傑出建樹的最偉大的科學全才之一，被後人稱爲「計算機之父」和「博弈論之父（涯傑）」。第二次世界大戰期間爲第一顆原子彈的研製做出了貢獻。爲研製電子數字計算機提供了基礎性的方案。

 

這兩我的奠基了現代計算機的基礎，尤爲是可存儲的程序！

 

開始的第一代的計算機採用的是紙帶串孔來表示01，表示程序和數據。要求計算機提供計算的結果。這樣爲第一代原子彈的誕生提升了速度。後來的發展就是把紙帶編程了磁盤，裏面不在存的是01，而是ASM編碼，俗稱彙編語言。由於你們認爲每次人工在紙帶上打孔，自定和修改都很不方便，並且學習0101也很費力和費時。天然也不多人用得起！後期計算機發展迅猛，計算速度越快，而人類編制計算任務相對來講很耗時間，計算機的計算能力被閒置了不少。這樣一來一邊硬件的發展，一邊是編程的發展。硬件從大型機，到小型機，再到臺式機，以及目前的手機！並且編程發展從彙編語言到C語言 後面就是DELPHI, JAVA，PYTHON語言。

  而數據庫是怎麼來的呀？除了語言的發明外，還發明瞭操做系統這個東西，它是中介而已。

說白了就是社會分工，由操做系統負責硬件的交道和協調工做。既然有能夠存儲的程序，天然會有能夠存儲的數據。程序是二進制編碼 10101這樣的內容，後綴名字通常都是.EXE，linux通常都是bin 。而數據以文本文編碼而保存，通常是TXT命名，天然還有其餘結構的。

  計算機除了科學計算外，還有一個用途是數據處理。程序操做數據文件，程序代碼不多，而數據文件確不少，或者很大。程序操做這樣的數據文件，就是咱們的數據庫初型！

這就是數據庫的雛形，程序和文件！你也能夠編寫這樣的數據庫。我用C++BUILDER 使用結構數據類型把股票信息，在套個一維數組使用流化類保存在文件當中。能夠新增，保存，查找，刪除等操做。

 這樣的雛形數據庫就大部分開始應用在企業領域當中，也就是企業請人來編程，據說是用的COBOL。

COBOL（CommonBusinessOrientedLanguage）是數據處理領域最爲普遍的程序設計語言，是第一個普遍使用的高級編程語言。在企業管理中，數值計算並不複雜，但數據處理信息量卻很大。爲專門解決經企管理問題，美國的一些計算機用戶於1959年組織設計了專用於商務處理的計算機語言COBOL,並於1961年美國數據系統語言協會公佈。經不斷修改、豐富完善和標準化，目前COBOL已發展爲多種版本。

 

後來出現了商業軟件，好比咱們學校教過的基於DOS操做系統的FOXBASE,FOXPRO和基於WINDOWS系統的VISUAL FOXPRO 。這就是第一代數據庫 是商業化的軟件！你們是用的ACCESS也是這一類

 

第一代桌面數據庫 在這本講性能優化的書中，我重點看到的是它是個桌面型數據庫，只供一我的操做，用戶併發數是一！固然商業化第一代數據庫提供了統計功能和數據文件的管理功能。

 

第二代是服務型數據庫 主要表明是微軟公司的SQLSERVER 和甲骨文公司的ORACLE 以及IBM 公司的DB2。 這代數據庫完成了SQL統一接口，雖然在各家數據庫當中有特點的SQL，好比微軟的T-SQL，甲骨文公司的PL-SQL。同時也定義了關係理論，並在這代數據庫獲得了實現！ 這代主要是C/S架構，能夠同時接500個客戶同時操做！ 使用不一樣的鎖解決用戶併發問題。基於地第二代數據庫有大量的ERP系統，包括SAP和EBS！

 

第三代是WEB集羣據庫，由於WEB的發展刺激了數據庫的發展，表明是MYSQL。在工廠裏SAP系統使用小型機作爲數據庫平臺，由於它穩定，可靠，性能卓越。沒有必要搞集羣，沒那個動力，支持百兒千的用戶量沒問題。而後在WEB世界裏，萬，百萬，千萬的用戶量是一件很常見的量，而且是老闆很開心的事情，是技術大牛值得追求的事情。爲此IT技術再次出現了分層，出來了個應用服務器，好比說TOMCAT等。從C/S架構兩層變成了三層，既是瀏覽器+應用服務器+數據庫服務器。除了分層還有就是集羣，應用服務器TOMCAT也集羣，數據庫MYSQL也集羣，天然ORACLE也集羣了！

 

第四代是集團化數據庫。 由於互聯網+和移動互聯網出現！用戶量從萬的級別變成了億的級別。淘寶平日PV量（頁面瀏覽量）16億到25億之間，並且12306.cn也有10億的量，而真實的UV量(用戶量)也過億。象如此大的用戶,靠集羣已經沒法支撐了,須要各類不一樣特性的數據庫組團打怪,造成集團化做戰。列如使用 上千臺MYSQL服務器承擔查詢任務，使用上百臺ORACLE集羣服務器來承擔，庫存，支付，結算的工做。 再用NOSQL數據庫現在火爆的REDIS和MONGODB集羣來完成非結構的查詢.使用內存數據庫完成緩存查詢，列入memcache，用列式數據庫完成消費帳單的統計功能。

 

   數據庫的發展解決數據的共享和用戶併發的控制！

 

1.3性能爲何會慢？

   性能爲何會慢？緣由有1，2，3，4，5等。主要是慢是個趨勢，無可逆轉，如同人總要衰老的！

也就是說當你的系統哪怕是上線後未曾修改，隨着時間和業務的發展必然達到硬件上限能力！而現實有不少緣由致使系統未必達到那個境界就開始慢起來了，如同咱們但願人沒有病沒有痛的老化而死去！

 

慢的第一個緣由是用戶量多了！

  這個緣由是個開心的事，說明用的人多啊，只有增長硬件的投入

 

慢的第二個緣由是數據量變多了！

  這個或許也是開心的緣由，除了追加硬件投入外，還能夠減小數據來提升性能

 

慢的第三個緣由是功能愈來愈多！

  很顯然這也是個開心的緣由，除了硬件追加外，沒別的法子

 

慢的第四個緣由是設計師設計得很差！

  這是個很重要的緣由，由於設計的很差或致使不少不少問題出來，並且設計很差的緣由會被深度掩藏起來。解決辦法是從新設計新版本。

 

慢的第五個緣由是開發人員SQL寫的很差！

  這個是目前市場上性能優化的重點，可開發人員都是充忙地加班加點趕忙度呢！解決之道是制定個規範，並且這個規範易用，而後再SQL審計把關下。後期只好請DBA參加優化。

 

慢的第六個緣由是數據庫和系統的參數配置很差！

  這個也是目前市場優化的重點。招個有經驗的DBA來配置。不要讓開發人員去管理數據庫！

 

慢的第七個緣由是硬件問題

 可能硬件某個環節壞掉了。

 

 

1.4性能優化新常態

 新常態 就是說優化的重點不是在SQL的化和參數的配置。雖然這兩項比較能立杆見影，性能突進。好像是個倚天劍和屠龍刀！採用SQL和參數兩項優化外，時間過了仍是會出現性能問題，只不過是其它方面的性能問題。

 常態是 咱們該從設計領域着手，從數據庫發展史和計算機發展史得到靈感，就是分工和分層！依據JAVA編程的思想高內聚 低耦合！根據業務特性來配置硬件，設計系統，是系統各個子系統高內聚，低耦合。相互獨立自主，又不互相影響！

   本書主要談的是ORACLE性能優化，主要是講ORACLE在服務型數據庫和WEB集羣數據庫領域的優化，好比工廠裏的SAP，EBS和基於WEB的金融，雲ERP，進銷存等系統。在互聯網+，移動互聯網領域ORACLE基本上屬於集團化中的子數據庫系統，跟2,3代數據庫差很少，再也不是優化的重點，並且優化的方法依舊如此，沒有特殊之處。

第二章強拆

如下強拆是基於WEB化的數據庫應用系統，若是是工廠的ERP ORACLE EBS就飄過吧！

  2.1 爲何要強拆？

    本章讀者羣是，技術總監，系統架構師，數據庫架構師，系統設計師，高級程序員。只有這樣的角色才能起到強拆做用！沒有領導的號召，城管纔不去搞拆遷活動啊！

由於咱們的數據庫大部分基本上，幾乎是，90%都是混合型數據庫。全部的系統，該系統全部的業務都在一個數據庫裏面實現。也就是說全部的表都同在一個用戶下，集羣多也是100%克隆式的擴展而已！爲何要混合在一塊兒呢？那是由於數據庫設計課程當中沒有講過，講的是3N方式和冗餘措施，講的是邏輯關係ER圖。而應用開發人員還有ROSE的時間圖，狀態圖。

  通常來講一個系統上線要2-3年的時間纔出現數據庫性能的問題。而此時留守來的只有高級開發人員和技術總監，以及招來少許的低級開發人員作維護性開發。慢起來就是突發的事件，要承擔巨大的精神壓力，輕則業務緩慢運行，重則業務中斷。好比12306每到節假日不可開機！作爲留守或者是半路而來接手的技術總監幸福指數直接降低！頂多都是臨時優化，頭疼吃感冒藥，腳疼打麻醉藥，應付過去了事。實在沒辦法當即採購硬件來頂。和尚敲鐘，能頂一天算一天。假如你要在這家公司長期幹下去，不想蹦來蹦去的，或許你接手這個系統已經優化不少次了，已經買了屢次硬件來頂，到你手上已經沒有了優化空間和餘地了。

那麼怎麼辦？老闆會怎麼看你？老闆會會相信前幾任把優化空間用完了嗎？他只會認爲前幾任有本事，並且你是廢物！

 2.2 第一次拆按業務來拆

   一個系統，能夠細分多個子系統，或者說子業務，不一樣的業務。好比說我所在的第三方支付公司，公司業務主要流程以下，商戶開戶-，商戶發來交易，過風控，發給銀行，走銀行通道，結算，劃款，退款，拒付。那麼大體來講有以下幾個業務：

1  管理業務主要是商戶管理，商戶自身管理。

2  風空業務  這個業務涉及到不少規則。

3  交易業務  處理交易，接受銀行交易返回信息，覈對交易。

4  銀行通道管理，銀行通道有不少限制，好比說交易量，拒付指數

5  財務業務  涉及到結算，劃款，退款。

 

 那麼就說能夠分紅5種業務

 這裏主要是根據業務來劃分，也能夠叫系統。接下來若是須要能夠深度拆分，系統-》子系統-》模塊

或者是業務-》子業務--》模塊。這就根據用戶數量級別，公司經濟實力，以及開發實力來定。

作爲技術總監，高級開發人員應該說是熟透業務，按業務來拆分是輕而一舉的事情！

  第一按業務來拆分的話，當其中一個業務發生了性能問題，不會影響到其它業務的正常運行。而後混合型數據庫，當每個月月底或者月初的時候，都要給商戶作結算，有的是30天，有的60天，有的是90天，還有的是180天。另外還要給銷售人員算提成，提成都是根據商戶的交易量來算的。這將是個巨大的IO運算量，每到這個時候數據庫就要卡好幾回對嗎？並且會影響到其餘業務正常運行，好比通道不行了，很慢啊！商戶打來電話抱怨很慢了。這要承受巨大的壓力！

 有了業務拆分，它好！你也好，何樂而不爲呢？採用JAVA思想高內聚，低耦合，經過接口來完成業務之間的數據共享。那麼設計接口呢？有如下幾種方式

   1  後端數據庫DBLINK模式，沒個業務都用一個用戶名概括子在一塊兒，包含，表啊，存儲過程啊，視圖和函數啦！這裏介紹下恆波手機賣場，用.NET開發的WEB進銷存系統就是採用該方式完成業務拆分。

  

2 採用多數據源方式，NET和JAVA都支持多數據方式。好比財務當中的結算業務就要調用商戶管理業務的數據庫。那麼財務業務要再多配個數據源就是商戶的數據源。咱們公司就採用這種方式

  3 採用MQ消息機制，JAVA經過內部服務對象發消息給另外個對象要求某些數據。

4 採用數據庫中間件 MYCAT ，經過數據庫中間件，mycat,myproxy,oneproxy等分析接手到的SQL語句來，分析用到的表名來路由具體的數據庫。

  

這四種方式最好的是第三種，在JAVA層完成數據接口。主要是清晰可控，併發能力也能提升，天然這涉及到了開發實力。不過一開始設計的時候考慮進去了的話，確實是一件不難的事情。其次是第二種採用多數據源方式，這方式NET會用得多。也比較容易實現。

 再者是第一種方式，這方式適合把業務放在數據庫端來實現的，而應用端只實現用戶友好方式。

最後一種就是第四種，這是一種偷懶的方式，基本上應用層代碼不用改，數據庫層表能夠不用分離。就靠數據庫中間件來路由。

 爲何這樣排序呢？由於有利於開發人員進行SQL的分離，目前的SQL不少是多表的聯合查詢，這些表不少是跨業務系統的。開發人員依舊把過去混合模型中的習慣延續下去，天然對後續的機器擴展帶來性能問題。

物理部署方案

1 單數據庫模式

2 單集羣模式

3 多集羣模式

2.3 第二次拆讀寫分離 OLSPOLTP OLAP

   。。。。。。。。。

SQL請求分離

2.3 第二次拆 SQL請求分離 

   分離這個詞組現在已經很是耳熟，熟到已經熟透了。在MYSQL領域常常據說到分庫分表，讀寫分離之類的架構思想，依舊是3-4年前的事。這裏分離要結合業務特性，就是SQL請求特性來分離。應用程序發往數據庫的SQL是有不一樣的類型，雖然能夠分爲INSERT,SELECT,UPDATE,DELETE等，雖然這些類型的SQL，當它們的請求是不同的。站在應用程序角度來看，它發日後臺數據庫的SQL頻繁度，要求的響應時間，以及SQL所涉及訪問數據的多少來劃分，OLQP， OLTP，OLAP，OLHP  這四個類型就是小仙個人劃分。什麼是OLTP和OLAP呢？ 

OLTP是在線業務處理；

OLAP是在線分析（統計）；

OLQP是在線業務查詢；

OLHP是在線業務（大數據，分析，統計，挖掘）；

詳細介紹以下：

當今的數據處理大體能夠分紅兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。
OLTP是傳統的關係型數據庫的主要應用，主要是基本的、平常的事務處理，例如銀行交易。
OLAP是數據倉庫系統的主要應用，支持複雜的分析操做，側重決策支持，而且提供直觀易懂的查詢結果.
OLTP:
也稱爲面向交易的處理系統，其基本特徵是顧客的原始數據能夠當即傳送到計算中心進行處理，並在很短的時間內給出處理結果。
這樣作的最大優勢是能夠即時地處理輸入的數據，及時地回答。也稱爲實時系統(Real time System)。衡量聯機事務處理系統的一個重要性能指標是系統性能，具體體現爲實時響應時間(Response Time)，即用戶在終端上送入數據以後，到計算機對這個請求給出答覆所須要的時間。OLTP是由數據庫引擎負責完成的。
OLTP 數據庫旨在使事務應用程序僅寫入所需的數據，以便儘快處理單個事務。

OLAP:
   簡寫爲OLAP,隨着數據庫技術的發展和應用，數據庫存儲的數據量從20世紀80年代的兆（MB）字節及千兆（GB）字節過渡到如今的兆兆（TB）字節和千兆兆（PB）字節，同時，用戶的查詢需求也愈來愈複雜，涉及的已不只是查詢或操縱一張關係表中的一條或幾條記錄，並且要對多張表中千萬條記錄的數據進行數據分析和信息綜合，關係數據庫系統已不能所有知足這一要求。在國外，很多軟件廠商採起了發展其前端產品來彌補關係數據庫管理系統支持的不足，力圖統一分散的公共應用邏輯，在短期內響應非數據處理專業人員的複雜查詢要求。

聯機分析處理（OLAP）系統是數據倉庫系統最主要的應用，專門設計用於支持複雜的分析操做，側重對決策人員和高層管理人員的決策支持，能夠根據分析人員的要求快速、靈活地進行大數據量的複雜查詢處理，而且以一種直觀而易懂的形式將查詢結果提供給決策人員，以便他們準確掌握企業（公司）的經營情況，瞭解對象的需求，制定正確的方案。

不過在小仙這裏明肯定義爲在線分析，相似於SELECT SUM() 之類的統計功能。

 

OLHP

真正的數據庫倉庫，咱們使用大數據HADOOP 爲操做系統平臺，用HIVEHBASE作數據庫。用SPARK來作分析。

 

OLQP的定義是讀寫分離中的讀操做，在線查詢功能！由於MYSQL來支持互聯網，互聯網有大量的查詢簡稱QPS。而在通常數據庫SELECT查詢量也是不少的。

 

那麼第二次拆分是 OLTP,OLQP,OLAP,OLHP了

  目前來講OLHP是個獨立的系統，每每與常規的交易系統隔離開了。好比說經過ETL程序把交易數據遷移到數據倉庫中，同時通過清洗和轉化。小仙認爲未來可能每一個業務都有可能獨立的分析庫。好比我公司的風控數據倉庫，全球化的今天高官須要在線模式使用數據倉庫。將來不會跟正常系統混合在一塊兒，不過做爲拆分思想，這裏稍微預測下。

重點是OLTP,OLQP,OLAP

  由於這三個特性很是不同，OLTP是交易類型，是用戶併發量大，要求時間很是短，事務要求一致性很高，要求數據安全度很高，不允許數據丟失。並且涉及數據比較少，涉及的表也很是少。

 OLAP 在線統計用戶量或許少，主要是查詢的數據比較多，涉及多張表聯合查詢，主要消耗IO和內存。

而OLTP是消耗CPU和鎖資源。完成一個付款交易,貨架減庫存的交易

OLQP 把它獨立開來，從OLTP中分離出來，目的是不影響高併發OLTP. 由於用戶查詢量是很是大的。

好比物流當中,用戶常常要查本身的快遞,運輸的狀況,到達了哪一個站點,以方便本身安排接貨.

 

 也就是說把INSETDELTET UPDATE語句放進指向OLTP數據源中；

把經過索引訪問的SELECT 語句指向OLQP數據源中。好比說SELECT NAME FORM STUDENTS WHERE ID=? 這樣根據ID查到學生的姓名可能要放進OLQP中。

簡單來DML操做放進OLTP中，而把單索引訪問的SELECT放進OLQP中，

把大數量的統計的SELECT 放進OLAP中。

  

  這樣拆分有利用ORACLE衆多的參數調整。最明顯的一點就是 OLAP能夠建立好多好多的索引，並且不影響交易的速度，由於每次的數據插入，更新都有同步維護索引，若是索引多了話，維護索引的時間會更長，每一個索引可能會發生索引分裂，從而致使每筆交易時間拉長，進而會形成更多的鎖資源爭用。並且OLTP中的表只須要兩個索引。同時兩種類型的表能夠不一樣的形態，從而兩種都獲得了性能上的提升。

好比說OLTP除了設計到3N範式外，還能夠進步提升到4-5N範式，而不用考慮什麼數據冗餘的問題。

數據冗餘所有交給OLAP當中去設計。OLAP能夠採用大數據塊和壓縮技術以及列式存儲，ORACLE 11G 的結果集緩存，12C的IMO。什麼是IMO呢？

2014年6月，在Oracle 12c的12.1.0.2版本中，Oracle正式發佈和引入了基於內存和列式計算的In-Memory Option 簡稱IMO。這個特性有利統計單列。好比說統計整年的交易額，只涉及一個字段,

SELECTSUM(TR_AUMOUNT)

FORMTR_TRADE

WHERE TR_DATIME BETWEEN XXXX AND XXX;

在過去它要訪問全部行的每一個字段，要把每一個字段讀取到內存而後在篩選出來。而這個特性就是列轉行地存儲在數據塊中。也就是說數據塊只存一個字段的內容，相對行來講所須要的數據塊數量很是少。而平時是經過聯合索引方式達到該目的，好比建個(TR_DATIME,TR_AUMOUNT)

所以 OLTP,OLQP,OLAP 分別是事務量(TPS),查詢量(QPS),吞吐量(OPS).  而OLHP 就是挖掘量!! 

 2.4 第三次拆數據的水平拆分

 

 這個拆分已經接近了技術層面了，固然這個技術拆分必須結合第二層拆分才能發揮到最大性能。

 一方面根據數據冷熱程度，拆成熱，溫，涼，冷。把熱的和溫的放進OLTP當中，把溫的，涼的，冷的放進OLAP中，把冷的放進OLHP當中。 這中間有個交叉重複，這主要考慮數據同步問題。另外市面上常有個叫法是叫當前表和歷史表。差很少是以冷熱程度來拆分的。 那麼依據什麼來判斷冷熱的程度呢？

 小仙我認爲根據修改頻繁度來決定，好比說insert delete 和短期內發生的UPDATE操做，以及實時查詢單筆要求的數據，能夠作爲熱表。而溫表是查詢比較多，同時只會發生UPDATE 一條或多條數據。涼表是數據不在發生變化了，再也不發生UPDATE，更不能發生DELETE了。並且查詢量大，主要是統計類型。所謂冷表就是基本沒有什麼查詢了。這個要看業務界面上的設計了。我在工行能夠查過去好幾年前的美圓購買記錄。

  爲此每一個表都必須帶有兩個必要的字段(建立時間,更改時間)

另外根據OLTP和OLAP的特性使用不一樣的分區技術，好比說OLTP經常使用是散列分區，而OLAP經常使用的是時間分區，數據量大的話用到雙層分區，先時間分區，而後列舉分區，好比說移動公司的時間加省份。

這個圖表明瞭三次拆分，也可說是拆了三層。若是業務複雜，或者用戶量超多。能夠在業務層再細分模塊成。若是使用JAVA對象MQ傳遞消息 完成數據共享的話，再採用多集羣部署。應該達到很是高的性能，同時也是高擴展，高可用的三高典範設計。哪怕是真的出現了數據庫性能慢的事，也是發生在局部當中，不影響全局整個系統運轉。並且每一個局部都是單純化，爲此針對該單純能夠很是個性的優化系統，數據庫以及SQL語句。而不會象混合數據庫樣，爲個SQL語句建立的索引，又致使其餘SQL語句改變了執行路徑，從而形成該SQL語句變慢的麻煩。

第三章 分庫分表

市面上流行的分庫分表的說法,其實都是來自MYSQL那夥人的.MYSQL DBA 太弱雞了,毛辦法,沒有分區表,數量那麼太,用戶那麼變態。什麼根據水平拆表，USER_ID= 分到其餘庫中。

MYSQL DBA 愛拆法

Sharding的基本思想就要把一個數據庫切分紅多個部分放到不一樣的數據庫(server)上，從而緩解單一數據庫的性能問題。不太嚴格的講，對於海量數據的數據庫，若是是由於表多而數據多，這時候適合使用垂直切分，即把關係緊密（好比同一模塊）的表切分出來放在一個server上。若是表並很少，但每張表的數據很是多，這時候適合水平切分，即把表的數據按某種規則（好比按ID散列）切分到多個數據庫(server)上。固然，現實中更可能是這兩種狀況混雜在一塊兒，這時候須要根據實際狀況作出選擇，也可能會綜合使用垂直與水平切分，從而將原有數據庫切分紅相似矩陣同樣能夠無限擴充的數據庫(server)陣列。下面分別詳細地介紹一下垂直切分和水平切分.

垂直切分的最大特色就是規則簡單，實施也更爲方便，尤爲適合各業務之間的耦合度很是低，相互影響很小，業務邏輯很是清晰的系統。在這種系統中，能夠很容易作到將不一樣業務模塊所使用的表分拆到不一樣的數據庫中。根據不一樣的表來進行拆分，對應用程序的影響也更小，拆分規則也會比較簡單清晰。（這也就是所謂的」share nothing」）。

水平切分於垂直切分相比，相對來講稍微複雜一些。由於要將同一個表中的不一樣數據拆分到不一樣的數據庫中，對於應用程序來講，拆分規則自己就較根據表名來拆分更爲複雜，後期的數據維護也會更爲複雜一些。

讓咱們從廣泛的狀況來考慮數據的切分：一方面，一個庫的全部表一般不可能由某一張表所有串聯起來，這句話暗含的意思是，水平切分幾乎都是針對一小搓一小搓（實際上就是垂直切分出來的塊）關係緊密的表進行的，而不多是針對全部表進行的。另外一方面，一些負載很是高的系統，即便僅僅只是單個表都沒法經過單臺數據庫主機來承擔其負載，這意味着單單是垂直切分也不能徹底解決問明。所以多數系統會將垂直切分和水平切分聯合使用，先對系統作垂直切分，再針對每一小搓表的狀況選擇性地作水平切分。從而將整個數據庫切分紅一個分佈式矩陣。

ORACLE DBA 愛拆法

第一 業務拆分法  也就是前面兩張講的按業務，按功能業務拆分法

第二 就是按 SQL請求特性 拆分法   ： OLAP OLTP OLQP OLHP

第三 分表法

3.0 在甲骨文公司沒有開發SHARDING產品前，咱們可採用以下方式，達到分庫分表的效果

   3.1 垂直拆分法： 

    根據字段使用頻率拆分， 就是有些經常使用的字段放在一個表中，其餘不經常使用的字段放在另外個表中。 垂直拆分叫法跟 MYSQL 不同了

  3.2  水平拆分法：

  通常使用分區技術。根據某個字段的值 把數據分在不一樣表中。 好比根據時間字段，狀態字段， ID值。     時間字段採用範圍分區，狀態字段採用列表分區，ID採用散列分區。

 3.3 根據生命週期拆分法：

   根據用戶對數據的使用頻繁度來把表拆成，熱表，溫表，冷表或者是說 當前表 歷史表。

第四  分表分庫

 這裏說的是如何把分出來的表，遷移到其它數據庫當中。使用其它數據庫的服務器能力一塊兒爲應用程序提供服務

 對於 按業務拆分的庫， 通常都是獨立的數據庫，數據庫之間的數據不作同步，減小耦合性。只是在應用程序上作個服務接口，爲其餘業務提供本庫的數據服務。

 對於 SQL請求特性拆庫的話，就須要完成數據同步服務了！

好比OLTP 通常採用集羣模式，或者是主備模式。小仙我通常建議RAC集羣模式，表採用散列分區，每一個數據庫實列分別承擔不一樣散列分區的SQL請求操做，這樣擴大了用戶的併發量，同時也提升了OLTP性能。

而OLAP 通常採用獨立的數據庫，經過OGG來或者簡單的DBLINK來從OLTP裏得到數據。

OLAP 主要是爲了統計而從新設計的，能夠在使用32KB空間，壓縮技術，結果集緩存，建立N多索引，而不用小心影響OLTP插入性能。採用RAC集羣模式多個分區表分別在多個數據庫實列上，並開啓並行操做。天然達到了MYSQL 多庫同時完成統計的功效！

OLQP   通常能夠同過 主備模式 從OLTP 及時同步數據到DG庫上。 主庫能夠單獨拿出一個實列完成DG的數據傳輸，使用LGWR +ASYNC 及時把數據傳給到DG庫上。log_archive_dest_30  能夠支持30個DG。這樣會對主數據庫帶來性能壓力。畢竟太多了，須要LGWR進程工做。支持4-5臺DG，仍是能夠的。 4-5臺ORACLE DG性能完勝MYSQL 100臺服務器。

應用程序能夠經過 TNSNAME.ORA裏面的配置進行負載均衡到不一樣的DG上。

說實在的MYSQL 分庫分表技術難度很高，實現很麻煩，還須要數據庫中間件來幫忙解決路由的問題，須要這個分區表是存在哪一個庫中。而ORACLE 就容易多了。只是數據冗餘了些！

通常經過DG 就能很好完成分庫分表的工做。20臺ORACLE服務器就能跟100臺MYSQL服務器同樣出色。能夠支持中小型電商網站的用戶請求量。

關於費用！ 基本上不少民營企業使用D版的，並且也沒人去查。若是要買正版能夠買一個CPU的LINCES 大約20-30萬。 至於你往後裝在多少臺服務器上，它也不那麼管。

分庫分表是總結了第二章的強拆,也就是ORACLE的分庫分表.與MYSQL的分庫分表的區別.

從我所瞭解到的MYSQL分庫分表,視野集中在表的身上,把不一樣的表放在不一樣的數據庫中,這種拆分法跟個人按業務和功能拆分法,基本上相似,不過MYSQL是從下往上看.思惟方式有點井底之蛙的感受。視野集中在性能上，可能沒法達到業務和功能上的隔離。

MYSQL拆表法，有兩種，一種按字段，經常使用和不經常使用分別存在不一樣表中。另一種是按某個字段的值，好比user_id=XXX 或者時間字段進行水平拆分。其實這個ORACLE分區技術是一個概念的。當這裏有個問題，那就是水平拆分的表，若是放在不一樣的數據庫中，就須要數據庫中間件來完成路由工做。光從技術角度來看是沒法理解這樣的拆分需求的，只有OLQP的大量查詢，把查詢分別負載到不一樣的水平數據庫中，好比登陸的時候根據用戶ID分散到不一樣的數據庫中。 好比電商查詢不一樣的商品，電腦和化妝品的查詢，就經過水平拆分表的方法，分散到不一樣的數據庫中。每一個數據庫就保存不一樣的數據。

    把表水平拆分到不一樣的數據庫後，再用MYCAT把請求同時分發到全部的數據庫，一塊兒完成工做。而後在MYCAT進行數據合併。這樣的操做需求應該是統計類型的，好比說SELECT SUM() FROM USER_ID .須要全表掃描的工做。可表已經拆散了，分佈在不一樣的數據庫當中，天然要向所有數據發出命令一塊兒合做完成工做。 這就是典型的OLAP。

說白了你們都差很少，只不過MYSQL是從技術角度由下往上進行拆。 而我提的ORACLE分庫分表是從業務角度由上而下地分。

  若是你作成到了兩級分庫,那麼往後的性能問題就比較單純了

有朋友質疑20臺ORACLE數據庫與100臺MYSQL數據庫 分庫分表性能是否同樣？ 其實這個嘛，主要是MYSQL是硬解析，不得不用機器來拼人力！ORACLE高效的共享池技術極大了下降了硬解析的CPU消耗。你說20臺拼不過100臺MYSQL服務器。假設一樣的配置，一樣的應用！

而電商WEB應用最大的是天量查詢請求，也就是OLQP。 QPS量大！

QPS能夠用多個備庫來完成。把大表水平拆分多個分區，也不須要路由MYCAT的了。由於每一個備庫都有全量的數據，經過TNSNAME.ORA來負載均衡完成。因此實現起來很是簡單明瞭！

物理實現的方式能夠多種多樣，考慮公司的經濟實力而已。重點是要完成兩級分庫。往後愛咋折騰都方便了，就不用鳥應用開發啥事了。後臺DBA根據性能輕鬆完成，數據庫的部署，架構的調整，數據的遷移等等操做。

你看我囉嗦裏八嗦的 好幾章了！ 不過我仍是認爲重要的事情說三遍！

第四章  三大配置

今天咱們將重要的三大配置，分別應用程序端，系統端，數據庫端。

由於這三大配置，常常致使性能問題，並且很重要的問題！

第一大配置 應用程序鏈接池配置

由於ORACLE連接是進程，每來個連接進來的話，ORACLE後臺要生成一個服務進程SERVER PROCESS 提供服務，而系統也要有個客戶端進程。

而在WEB應用的今天，大量的，並且是頻繁的短連接。就是發生一個WEB請求後，須要操做後臺數據庫，則須要連接一次數據庫。查詢完了，立馬翻臉不認人。下次要的時候，在狗臉乞討。

這個時候LINUX 系統須要FORK()函數生成一個進程出來，用完後就銷燬！

在之前工廠中這種狀況也有，只是比較少，無所謂而已。畢竟一個工廠頂多255臺連接，大部分都是長連接，並且就是在早上上班的時候發生登陸風暴！

可現在WEB天下，動不動就雲ERP，從工廠內部，擴展到全球其餘工廠，或者支持異地上班，好比說銷售人員，在家工做好比說老闆。這樣的話須要1千個連接。並且每次都是短期連一下，連完後就丟丟掉！

這樣的狀況很顯然對數據庫所在的LINUX服務器來講，鴨梨山大！AIX 和SORILAS，都跑不掉！ 你說升級小型機，仍是大型機也是給不了多少力的。

不用說雲ERP了，就是工行的WEB網銀都很累！工行的客戶遠遠多於全球化的工廠用戶。

因此就要配置應用連接池！

JAVA 應用有好多連接池能夠玩！ TOMCAT也有，。。。。

Proxool是一個Java SQL Driver驅動程序，提供了對你選擇的其它類型的驅動程序的鏈接池封裝。能夠很是簡單的移植到現存的代碼中。徹底可配置。快速，成熟，健壯。能夠透明地爲你現存的JDBC驅動程序增長鏈接池功能。

DBCP （Database Connection Pool）是一個依賴Jakarta commons-pool對象池機制的數據庫鏈接池，Tomcat的數據源使用的就是DBCP。目前 DBCP 有兩個版本分別是 1.3 和 1.4。1.3 版本對應的是 JDK 1.4-1.5 和 JDBC 3，而1.4 版本對應 JDK 1.6 和 JDBC 4。所以在選擇版本的時候要看看你用的是什麼 JDK 版本了，功能上卻是沒有什麼區別。

（主頁：http://commons.apache.org/dbcp/）

C3P0是一個開放源代碼的JDBC鏈接池，它在lib目錄中與Hibernate一塊兒發佈,包括了實現jdbc3和jdbc2擴展規範說明的Connection 和Statement 池的DataSources 對象。

（主頁：http://sourceforge.net/projects/c3p0/）

商業中間件鏈接池 weblogic的鏈接池 websphere的鏈接池

NET IIS 容器也有， 小仙就配過。

string cs =

    "server=.;uid=sa;pwd=tcaccp;database=pubs;pooling=true;min pool size=5;max pool size=10"

    其中 pooling 表示是否打開鏈接池，默認爲打開，關掉時須要 pooling = false；

    min pool size 表示鏈接池最少保存幾個鏈接對象；

    max pool size 表示鏈接池最多保存幾個鏈接對象。(最大值不能爲 0，也不能小於最小值)

    配置好之後，經過 SqlConnection con = new SqlConnection(cs); 便可獲得一個屬於鏈接池的鏈接對象。

在作 ASP.Net 程序時，咱們會發現，若是網站20分鐘不訪問，再次訪問就會比較慢，這是由於IIS默認的 idle timeout 是20分鐘，若是在20分鐘內沒有一個訪問，IIS 將回收應用程序池，回收應用程序池的結果就至關於應用程序被重啓，全部原來的全局變量，session, 物理鏈接都將清空。回收應用程序池後首次訪問，至關於前面咱們看到的程序啓動後第一次訪問數據庫，鏈接的創建時間將比較長。因此若是網站在某些時段訪問量不多的話，須要考慮 idle timeout 是否設置合理。

PHP 好像沒有現成的鏈接池能夠使用，不過PHP常常和MYSQL搭夥過日子，利用MYSQL的內置鏈接池功能。

連接池注意要點就是 最大連接數和最小連接數，不要太大的差距。並且不要很頻繁地釋放連接回操做系統！

目前來講連接池對ORACLE來講，有一項功能沒有實現，就是儘量地把同一條類似的語句，分配在同一個連接上。這樣就重複利用了SESSION_CURSOR_CACHE的參數。

第二大配置  系統大頁內存。

目前的PC服務器基本上都是4GB以上的64系統。AIX和SUNSOARLAS 基本上配置好了大頁內存，而LINUX6系列默認都是小頁內存。

關於內存能夠參考以下

Linux 64 頁表，進程內存，大頁

Linux_x86_64BIT內存管理與分佈

部分SWAP 內存知識

由於系統存在着程序邏輯內存和真實的物理內存的映射關係，而這個關係須要用部份內存來保存起來。

並且是每一個進程都須要一部份內存。內存的多少取決於程序使用的邏輯內存量。

雖然內存映射關係進行了4層以上的映射。不過也抵不住程序使用內存的野心。

最終致使內存表的變態的肥肥！

好比說 你有張100MB的數據庫表，通過一年的運行和積累達到了1GB。每一個回話，也就是每一個連接，有個語句，天然是SQL全表掃描該表的語句，掃描1GB。那麼該進程須要1GB邏輯內存地址和物理內存地址映射。

假設下，原來100MB須要1MB內存地址來保存映射關係，如今須要10MB了。

好比說咱們如今有1500個數據庫鏈接，加上鍊接池不重用鏈接線路的話，1500*10MB=14GB內存保存映射關係表！

有點誇張了！ 不過我如今有個11.2.0.1 JAVA開發高級人員，以爲本身很牛雞巴，本身搭建了ORACLE數據庫。

結果鏈接池也沒配，大頁內存也沒有配。 大約230個應用程序鏈接數，佔了3.2GB的映射表（內存表） 系統總共才32GB 。

默認狀況下LINUX是4K內存頁大小的。 也就是說3.2GB除以4KB，大約有多少個頁。我就不算，你能夠算算看！ 這麼多頁，CPU須要把它掉入到CPU寄存器中。因此CPU處理這活的話，累死了！

而LINUX 能夠開啓2MB的大頁內存。這樣的話CPU也輕鬆了，頁表大小也少了。

第三大配置 數據庫內存自動分配！

只從ORACLE開始人性化來，從ORACLE 9I開始，到目前的ORACLE 12C。基本上免除了你們辛苦，而有細緻調整各個功能池的大小。如今12C自動完成。

最小分配單位是64MB。

這樣的人性化工做，很是適合JAVA開發人員了使用，之前須要專職DBA來完成的工做，如今要麼JAVA開發人員搞，要麼運維工程師來搞。基本上連上網，照着網絡配置下，啓動了圖形界面後就一路向西去了！

終於不須要DBA了，老子天下第一！ 十八武藝樣樣精通！

很顯然作爲專業DBA來講，這話就咽不下去了！ 那也沒辦法，嚥下去，等你的數據庫慢了後，再高價請我吧！！ 哈哈。

專業DBA 一來 就PASS掉自動內存調整參數。

設置PGA多少，SGA多少。

SGA 中 DB_CACHE多少， SHARD_POOL多少，LARGE_pool多少，JAVA_POOL，STREAM_POOL多少。剩下的就交給SGA自動調整吧！

具體調多少，要參考上圖 OLTP,OLQP,OLAP類型！ 單機仍是RAC

通常來講OLAP 須要大大的DB_CACHE。 而OLTP SHARD_POOL 就要不少，起碼要跟DB_CACHE勢均力敵。RAC當中的SHARD_POOL要超過DB_CACHE。

至於PGA+SGA 在整個內存的分配，通常參考80%系統內存！ OLTP SGA>PGA 而OLAP PGA=SGA。

另外 數據庫系統內存除了裝監控代理好比說ZABBIX AGENT 外，禁止裝其餘應用程序！

好比說OEM或者說EM！

第四配置！ 超線程

通常我是禁用掉超線程的。 超線程在PC  BIOS 裏面禁止。

爲何呢？

由於超線程，不是真的CPU內核，是利用CPU暫時空閒時間，虛擬的內核。

也就是在CPU空閒當中。利用它的空閒作其餘的事情。並且當主活回來後，再還給它！ 這裏面涉及到了上下文切換。切換就須要時間，內存調度嘛！原本主活的數據保留在寄存器，一級緩存，二級緩存，乃至內存中。這下好了，被超線程給趕跑了，再把數據調回來就麻煩了。

因此超線程適合計算類型的應用。至於數據庫嘛！你們都懂的，密集型IO操做！

第五章  六大禁止

第一禁止 禁止外鍵

第二禁止 禁止視圖

第三禁止  禁止觸發器

第四禁止  禁止存儲過程

第五禁止  禁止JOB

第六禁止 索引

這六大禁止會帶來不少性能隱患的，其中觸發器就是特例，視圖也會影響性能的，你說能夠作成物化視圖。

自從應用程序從C/S架構發展到B/S架構，而後在是水平擴展成多機器分佈式集羣架構。而以上的外鍵，視圖，觸發器以及存儲過程都是C/S架構中的數據庫爲了實現企業業務邏輯的工具。之前企業和工廠數據庫服務器都採用的是小型機器，好比現在的AIX操做系統必須運行在IBM的小型機上。而ORACLE+AIX+小型機是標準搭配。現在的ORACLE EBS系統依舊運行上面平臺中。之前我的電腦性能不咋地，什麼586,686，奔騰1-5估計你都沒有據說過，都是單核CPU。因此當時就把大量的計算工做和業務邏輯也放在了數據庫服務器上跑。

現在的WEB，雲化的B/S架構，已經把業務邏輯移到了 TOMCAT容器或者是IIS上運行。使用的編程語言要麼JAVA，要麼是C#.NET。而數據庫就充當數據存儲的角色。數據對象就是表和索引，而對它們的操做就是SQL。除了這三樣外就別無其它了。

曾經面試被問到業務邏輯放在哪端？你怎麼看待存儲過程的？當初經驗缺少，不知道如何回答。雖而後來想了下，以爲業務邏輯放在JAVA層，而存儲過程只處理數據邏輯。也就是說存儲過程一點都不涉及業務邏輯，只是GROUP BY  WHERE  SUM 掉大量的數據，返回少許的數據給應用層。雖然一直以爲這是個完美的方案，各就其位，各盡所長，充分發揮各自的優勢。然而如今想起這方案比較理想，你沒法讓開發人員又寫JAVA中的業務邏輯，還要讓他們寫存儲過程。那開發人員會沒法區分業務邏輯寫在哪裏去了，或許那個實現方便，快捷就使用誰。或許兩邊都使用下，這樣來業務就被拆分在兩端了。

視圖也是一段SQL代碼，當初是爲了屏蔽低下某些表給某些人看，或者是公共一段代碼做爲共享SQL。既然是SQL必然是業務邏輯的實現體，因此也要移植到應用層裏去。

外鍵和觸發器 現在JAVA開發人員已經取得了認識不在數據庫端實現了。

關於JOB的禁止， JOB JAVA應用開發已經實現定時調度的功能，而且調度什麼時候調度都是業務邏輯的考慮。

索引爲何也有要禁止呢？ 這是由於禁止開發人員去建索引，索引也歸DBA使用的。由DBA負責創建業務所須要的索引！

OK ！！ 我小仙並無說真的在數據庫上禁止這五個東西，而是說禁止開發人員去使用它們。這五個東西專屬咱們DBA的，咱們DBA就能夠使用這五個東西。由於咱們不會把業務邏輯寫在存儲過程，視圖裏面啊！ 

不少人看到這裏不少人就轉不過彎來，他們想的是不讓開發人員使用存儲過程，難道叫DBA去寫存儲過程嗎？這樣不是累死了DBA嗎？  有的人不認真仔細看上面的文字含義，或者他們大腦裏先入爲主的固有思惟限制了，看了也白看。纔會問這些愚蠢的問題！

在這裏我聲明下，本優化新常態是針對WEB性的數據庫應用，而不是第二代 服務型數據庫應用。是第三代的WEB型和第四代WEB集團化型數據庫應用系統。

在這裏沒有數據庫開發工程師這一個職位。WEB開發人員和DBA。 DBA不開發業務的存儲過程，視圖，觸發器，外鍵，物化視圖。這些東西歸DBA作運維方便而已，畢竟DBA不懂PHP,JAVA.C#等WEB開發語言。DBA懂PL/SQL語言，作些運維，作些統計，作些優化，天然使用PL/SQL語言和對應的工具，JOB，存儲過程，視圖，觸發器。

第六章 急診法

當咱們被數據庫忽然慢的時候，這個時候不應作AWR報表！比如你是醫院的急診科的值班醫生，當120拉來一名患者，而你要作的是當即判斷病情所在。AWR不太適合急診模式，閱讀完它就要花費30分鐘！因此咱們須要特殊的簡單明確的方法，進行快速診斷，快速恢復生產，讓用戶繼續完成業務，讓老闆有利潤。

第一從系統上開始 TOP命令 以下

TOP命令不少LINUX都有，並且比較重要哦！讀懂裏面的意思是DBA必備良藥。

第一 看第一行LOAD AVERAGE  超過1 就比較忙，越大越忙

第二 看第二行 TASKS 任務數 尤爲是 RUNNING的數，通常平時的時候都1-2.恐怖的時候達到1000，說明併發量大，排隊等候也大。

第三 看第三行 CPU 看目前的CPU消耗在哪一個領域。US表示應用，SY表示系統，WA表示等待（IO或者是網絡）。經過CPU消耗在什麼位置能夠肯定哪裏病了，是心臟仍是胃，還腦殼瓜子呢？

第四 看第四和第五行  大體講的是當前內存使用狀況和SWAP內存使用的狀況。

第五 下面的進程活動列表，動態變化的，通常都是按CPU使用率變化的。若是排在頂部的大部分是ORACLE進程，說明是數據庫發生了問題。

從TOP命令不能精確判斷出來， 不過能瞭解到是什麼消耗比較嚴重 是IO仍是CPU 尤爲是第三行。大體判斷出是系統出了問題仍是數據庫出了問題。

VMSTAT 命令

因爲CENTOS 6帶的VMSTA輸出格式對齊不咋地，看起來有點不舒服。

重點是看PROCS 的R B兩列和SWAP的SI SO兩列。

R B 表示運行隊列的進程數和阻塞的進程數。 R表明運行進程，B表明阻塞進程。SI SO表示交換內存的進出數量。

VMSTAT 主要用來判斷是非發生了交換內存的頻繁大量的交換。

下圖是ORACLE LINUX 6 的DSTAT命令 你們看下友好性特別的好。

第一組表明的是CPU；

第二組表明的是磁盤IO狀況；

第三組表明的是網絡狀況；

第四組表明交換內存狀況；

第五組表明系統狀況；Int 中斷，CSW上下文切換

到這裏咱們結束了系統方面的急症了。從上面兩個命令能夠肯定病情集中在CPU，內存仍是IO方面。假如CPU 內存 IO 都很正常那就是說系統是沒有問題的，問題在數據庫上面，起碼數據庫慢的問題沒有體如今系統指標上。說明病情不嚴重。

ORATOP命令 

這個命令是ORACLE公司開發的小工具，變化挺大的。

第一行和第二行，有些我也不懂，主要是變化太大了，每一個新版本都不同，另外仍是英文縮寫，沒有長格式的，都是80列的格式的。

重點看EVENT ，這個就是及時性的TOP五等待事件。這樣咱們就知道數據庫是否發生了嚴重的等待。好比上圖正常狀況下是DB CPU佔比較多的DBTIME。

若是是下面 LOG FILE SYNC和DB FILE SEQUENTIAL READ 等待事件排在第一或第二位 那就說明IO爭用很厲害。

關於小工具看下面連接 ==》ORATOP小工具

接下來就是TOP-SQL了 一眼望過去大部分列都懂，除了E/T STE W/T外。

經過TOP-SQL 你能夠內心有普了，知道這些傢伙了。你能夠KILL了它們。不過要在SQLPLUS裏面發不KILL SESSION命令 另外還有手動去查出來。雖然給了SID 和SPID。

也能夠在系統上KILL -9 命令，不過也要經過SQLPLUS查出系統ID來。仍是有點不方便。

視圖      V$SESSION_BLOCKERS

這是個回話阻塞視圖裏麪包含了以下字段

SID

SESS_SERIAL#

WAIT_ID

WAIT_EVENT

WAIT_EVENT_TEXT

BLOCKER_INSTANCE_ID

BLOCKER_SID

BLOCKER_SESS_SERIAL#

分別意思是 回話ID，回話序號，等待ID，等待事件，等待事件文本，阻塞實列ID，阻塞回話ID，阻塞回話序號。

這個視圖若是隻有一兩行還比較給力，若是是幾百行的話，就不像話了，一點都不給力。尤爲是急症下，上百行阻塞回話，它們之的上下級關係，阻塞連。我寫個START WITH相似的樹下結構的語句，發現也不行，反而產生更多的行，從原來幾百行變成了幾千行。也沒有機會去調試SQL，畢竟發生阻塞的時候，你必須幹掉它，因此就沒有機會了。只有截圖回來分析下。

另外該表只有這幾列字段，顯然信息量是不夠的，尤爲是在急症狀況下。必須有等待者的SQL語句，阻塞者的SQL語句，阻塞者的等待事件。

爲此我整了個大SQL，不過不太理想

SELECT LEVEL AS LEVEL_NUM,

B.SID AS "會話ID",