本節書摘來自華章出版社《高并發oracle資料庫系統的架構與設計》一書中的第1章，第1.3節，作者 侯松，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視
如果你是一位oracle資料庫的使用者，那麼我們說你将是立足在oracle的世界裡的。本書的主旨也是以此為出發點，立足oracle的世界，以海納百川的胸懷選擇性吸收各種資料庫的使用。
立足點的不同，同樣會影響到我們視角不同，那麼在oracle的世界裡的高并發資料庫系統架構設計将會是怎麼樣的呢？這也将是本書需要給讀者們介紹的。
相信在每一個oracle資料庫使用者的眼中都有其獨特的風景，對oracle的了解可以是技術的，更可以是藝術的。在讨論中，我經常提及的一個觀點：“将技術的東西當成一種藝術去做，那你将不再是簡單的技術者，而是更富創造力的藝術家。”
在這裡，我們也不妨東施效颦一回，模仿經濟學裡的“布林頓森林體系”，架構一個屬于資料庫領域的“資料庫森林體系”。
資料庫森林體系，是指以oracle資料庫為核心的多種資料庫叢集工作的生态體系。該體系的特點應該是：
應用系統核心内容和性能直接與oracle資料庫挂鈎；
其他類别和功能的資料庫與oracle核心庫挂鈎；
其他類别和功能的資料庫與oracle資料庫按業務需求實作資料同步與互動；
其他類别和功能的資料庫作為oracle核心庫的擴充，分攤前端或外圍業務支援。
圖1-5所示為一套比較完備的資料庫森林體系架構圖。秉承以oracle核心庫為中心，從業務邏輯層面、資料庫功能層面兩個次元展開縱橫方向的擴充。
oracle核心庫與oracle子系統庫、mysql子系統庫之間，使用goldengate實作即時的資料同步，mysql子系統庫是單向同步，它的角色更像是一隻伸出去的手，處理前置業務。
oracle核心庫與災備庫之間通過data guard功能實作異步同步，起到災難備份的作用，特殊情況下，也是可以臨時打開使用的。
同樣，在核心庫與adg庫、t-1交易庫之間也是通過data guard功能實作資料同步。adg庫可以看成是核心庫即時的映像，服務于隻讀業務；t-1交易庫則可視為過期的核心庫映像，可以給時效要求不高的業務提供讀寫服務。如果必要的話，通過adg庫衍生出一些開源資料庫的業務應用，就像伸出去的另一隻手，處理前置業務。
對于前面提到的oracle核心庫的高并發熱點争用問題，可以将這部分業務分離到前置的timesten記憶體資料庫中，提高高并發會話的響應速度，其可通過timesten提供的方法和接口實作與oracle核心庫的即時資料同步。
當然，資料庫森林體系也可以視為一種高并發熱點争用問題的解決方法論，不要求全盤實作，可以選擇性地搭建，滿足了需求就是最佳的架構設計。
說到高并發處理能力的提升，就會不隻一次地被問及oracle資料庫的rac架構。我隻能說rac隻是一種高可用的解決方案，對于高并發問題，它未必擅長。高并發熱點問題，往往成了它的短闆，rac環境甚至會加劇問題的影響程度。舉個例子來說，我們将會在高效索引設計章節提到的高并發會話導緻主鍵索引分裂的等待事件——“enq：tx-index contention”，如果這個問題不先解決掉，從單節點到rac的遷移後，問題将更加顯著。
從曆史來看，國人好像都很喜好rac資料庫架構，并無形中誇大了rac資料庫的作用，集高可用、高可靠、高并發、高性能的光環于一身。rac一度風行的時候，技術人員如果不會rac都不好意思說自己是oracle資料庫的dba，公司如果沒有rac資料庫都不好意思說自己的業務量大。這和前面提到的盲目誇大去ioe的現象是一樣的，光環效應是要不得的。
然而，rac确實也是一個不錯的東西，如果在節點應用之間盡可能地實作了業務的獨立，也就是說按節點完全區分業務應用，其處理并發的能力是有一定的優勢的，但是是在解決了資料庫結構分散的前提下。
為什麼這麼說呢？我們知道不論是rac資料庫還是單節點資料庫，實體存在的資料庫隻有一套，如果資料庫内部實作了業務邏輯上的必要隔離，各節點就能各行其道，反之，各節點的争用會更加劇烈。與其糾結在這個問題上，不如跳出來看問題，為什麼不幹脆将其按業務邏輯拆成多個庫呢？必要的共享資料，可以通過即時同步來實作。
如圖1-6所示，在左邊rac架構中，執行個體1對應業務1，有其獨有的資料部分，執行個體2對應業務2，也有其獨有的資料部分，兩種業務有一定的關聯性，是以還存在共享資料部分。演變成右邊的架構，将其拆分成兩個獨立的單節點資料庫，其中資料共享時效要求較低的進行資料庫間即時同步，時效要求很高的備援到各自業務資料庫中。這樣做雖然資料庫的總容量大了，但是架構簡單了，少了記憶體的即時同步，業務并發處理能力也提高了。回過頭再來看一下我們的資料庫森林體系，核心庫、子系統庫以及各種功能庫，不就是資料庫按業務邏輯拆分的結果嗎？
近年來，大家也能更加理性地看待rac資料庫架構了，與其面對額外的采購成本和運維成本，不如幹脆拆開來，用簡單的架構來取而代之，這也正是大道至簡的精神。
我們說高并發處理未必是rac的強項，但高可用就一定是了。當一套資料庫應用系統提出如下需求的時候，我們将毋庸置疑地給出rac的解決方案：
業務7×24小時線上；
盡可能短的故障停機修複時間，10分鐘以内、5分鐘以内，甚至更短。
在此我們不得不先提到一個概念，就是資料庫架構師的“術”與“道”。業内很多資料庫架構師往往是技術水準比較高的dba的更新版，這是一個比較典型的以“術”為導向的結果，一切以技術說話，這往往造就了架構的局限性，甚至凡事唯技術論。好比很多項目在制定目标的時候，會把某項新技術的實作作為目标之一，造成驢唇不對馬嘴的後果。一個成功的資料庫架構師應該是以“道”為導向，那何為資料庫架構師的“道”呢？在這裡我先賣一個關子，将在本書的第9章中展開讨論。
我曾經在一次技術沙龍上跟幾位朋友讨論過一個話題：如何看待資料庫五花八門的新特性呢？當說起需求是高并發處理的資料庫的時候，大家達成一種共識，就是架構需要設計得充分簡單，簡單了才能靈活地擴充，對于一些不熟悉或者沒有實戰經驗的新特性，可以不用就不要用。
然而，設計簡單的架構并不意味着架構簡單的設計，越是簡單的東西越是考驗設計者的思想，需要對簡單的東西充分細化。立足在oracle的世界裡，有哪些是至簡而至要的東西呢？就是資料庫森林體系中蘊藏的設計的大道。
資料庫森林體系看似複雜的架構背後，至簡的大道無外乎就是對表、索引、優化器設計的把握，以及以核心庫為中心的功能資料庫與前置資料庫的縱橫擴充。本書将分作兩個部分，對這兩項内容具體展開闡述，其目的不在于幫助讀者解決某個具體的高并發問題，而是旨在分享一種方法論，開辟一種思路。或許你在閱讀的時候能夠得到一點啟發，演化出更高明的觀點，那麼我寫作本書的目的也就達到了，也正是我的大道。