oracle資料庫對高併發有著非常好的支援。高併發的系統必然產生大量讀寫操作（dml），進而產生大量事務，也就會消耗大量的鎖資源，特別是行鎖。oracle行鎖物理上是在資料塊上面實現的，因此oracle鎖資源幾乎是無限的，而其他資料庫是通過記憶體實現的鎖機制（比如db2），如果記憶體不足行鎖就會公升級為表鎖，造成鎖公升級。而且，oracle的讀寫操作不互相阻塞，對高併發操作也有很大好處。
oracle資料庫在高併發環境下還是要注意以下問題，以提高系統效能，防止造成效能瓶頸：
一、oltp資料表（不同於olap資料表）一般都要有主鍵，對於大併發系統，不要用sequence作為主鍵。這是因為，索引是有序儲存的，預設是按公升序儲存。在大併發情況下，很多程序進行insert操作，索引要進行更新，如果用sequence作為主鍵，索引更新就會集中在最大的那個索引塊。索引塊更新是排它的而不是共享的，很多程序同時更新，同一時間只能有乙個程序執行更新，這就造成了排隊，從而效能下降。解決方法可以使用uuid等方式，只要不是遞增的就行，使更新分散在多索引塊上。
二、經常有這樣的場景，一條sql查詢語句在系統比較空閒時，反應很快，但在業務繁忙被很多個程序同時更新時，反應速度急劇下降，檢視執行計畫會發現邏輯讀大幅上公升，邏輯讀增加會消耗大量資源，特別是cpu。造成這種現象是因為oracle為了維護資料的一致性，當查詢某些資料的時候，發現資料塊的版本比我們要查詢的新，例如session1執行了dml操作並沒有提交，session2此時查詢跟session1相關的dml操作的資料資訊，此時查詢的資料卻是原來的資料資訊。查詢的過程會在undo段中查詢該資料塊的前映像後，然後把前映像和current塊合併形成了乙個cr block，通過查詢cr block就可以滿足資料的一致性了。當系統繁忙時，可能有大量未提交事物，也就造成邏輯讀增加，也就是要解析的塊增加，cpu就吃不消了。
解決方法是：
1.優化查詢sql，使它的查詢速度盡可能達到可接受程度；
2.優化dml sql(或者業務流程)，使它盡快的提交，釋放掉undo段中的資料。
3.如果優化達不到目的，可以從系統設計上解決，分庫，分表，分業務，資料切割，記憶體資料庫，快取經常執行的sql等等，但是成本太高了。
三、乙個高併發系統，要保證sql執行計畫穩定，也就需要統計資訊準確，可以選擇每天晚上在資料庫不繁忙的時候執行指令碼，收集統計資訊。但是高併發系統不能隨便進行動態取樣。動態取樣會根據取樣級別掃瞄資料塊，並且還會隱式的執行sql（乙個sql會隱含出發多個sql），進行統計資訊收集，特別是如果搞個全庫動態取樣（ alter system set optimizer_dynamic_sampling=6;）。這樣系統會造成效能急劇下降，造成宕機。
一 Oracle的OLTP和OLAP模式
oracle屬於傳統的關係型資料庫，在建庫應用時，大致可以分為oltp和olap兩種模式，針對這兩種不同模式，oracle都有的不同的技術應用和優化技巧。先簡單介紹這一下這兩種模式 olap on line analytical processing 聯機分析處理，用於做複雜的sql關聯和資料分析，...
對於大併發的思考
一般如果是壟斷組織,用佇列就行了,讓客人慢慢等,不過如果不是的話,在技術上就沒有了競爭力 現在一般來講,大併發的瓶頸都在資料庫上現在一般是走兩條路 1.分庫,把主要資料按照一定規則的劃分,再分布在不同的伺服器上,這樣來分散伺服器的寫操作.2,存記憶體,用memerydb等工具把資料分布式存在不同的伺...
併發程式設計的三大特性
1 原子性 對於成員變數a來說，如果執行緒a執行以下操作 a 此時需要分三步執行 1 讀取a的值 2 將a的值加1 3 將加1後的值賦給a 在執行以上三步過程中，如果另乙個執行緒b對a進行了操作，那麼就不能保證原子性了。要保證原子性，可以加鎖，如synchronized 2 可見性 要理解可見性，需...