❶ 企業為什麼要用甲骨文(Oracle)公司的資料庫，Oracle資料庫和企業之間到底是什麼關系，中國企業在用嗎
國內銀行系統用的資料庫很多，核心系統一般都用老牌的商業資料庫DB2、Oracle。其他系統也有用Mysql、MongoDB等其他資料庫。至於數據泄露嗎？銀行當然也怕。但是，就綜合考慮來看，目前Oracle等商業資料庫依然是最佳選擇，將來可能會一步一步提高安全等級。
1、穩定是首要選項
我們都知道，銀行是金融系統的重要機構。它們的系統不能夠隨便出問題，一出問題影響整個社會。所以，對銀行來說，穩定是擺在首要位置的。任何創新都必須以此為前提。而DB2、Oracle這些商業資料庫軟體，首先能夠滿足銀行的穩定性要求。
那該如何升級安全呢？除了系統過等級保護外，也一直在倡導用安全可靠的軟體。這就意味著需要逐步從Oracle、DB2等商業軟體走向開源、或者國產等資料庫軟體。不過，銀行的穩定性還是不能忽略的，所以，銀行也就只能逐步探索，逐步提升安全。同時，國產資料庫發展也還有很長一段路要走。
總結
總之，早些年銀行從穩定和安全出發，Oracle、DB2等商業資料庫是最佳選擇。這些年，隨著國際形勢的變化和技術的發展，銀行也在逐步提升安全等級。將來也會逐步替換Oracle、DB2等商業資料庫軟體。
❷ 如何使用服務來平衡Oracle RAC 資料庫工作負載
一些CRS的服務你可以，手工SHUTDOWN 每個實例然後CRS_STOP -ALL，關閉其他服務。啟動的時候可以通過CRS_START -ALL啟動
❸ 如何配置Oracle RAC負載均衡和故障轉移
Oracle負載均衡主要是指新會話連接到RAC資料庫時,如何判定這個新的連接要連到哪個節點進行工作?通常情況下，負載均衡分為客戶端負載
均衡與伺服器端負載均衡。客戶端負載均衡通常是在客戶端的tnsnames.ora中多添加一個鏈接地址以及LOAD_BALANCE與failover參數。而伺服器端的負載均衡則相對復雜，下面具體描述伺服器端負載均衡。
❹ Oracle資料庫 RAC負載均衡情況下（兩台資料庫）優化內存排序大小
通常情況都不需要修改這兩個參數，建議通過修改sga大小和增加索引的方法優化
❺ oracle資料庫負載不均衡怎麼辦
你是否做了資料庫的讀寫分離？如果沒做 沒辦法 如果做了通過負載均衡設備 可以做資料庫讀的負載均衡 寫的做不了
❻ Oracle的RAC做資料庫的負載均衡，有什麼優點和缺點
RAC編輯〔RAC提供的優缺點〕RAC，全稱realapplicationclusters，譯為「實時應用集群」，是Oracle新版資料庫中採用的一項新技術，是高可用性的一種，也是Oracle資料庫支持網格計算環境的核心技術。OracleRACRAC提供的優缺點優點OracleRAC主要支持Oracle9i、10g、11g版本，可以支持24x7有效的資料庫應用系統，在低成本伺服器上構建高可用性資料庫系統，並且自由部署應用，無需修改代碼。在OracleRAC環境下，Oracle集成提供了集群軟體和存儲管理軟體，為用戶降低了應用成本。當應用規模需要擴充時，用戶可以按需擴展系統，以保證系統的性能。(1)多節點負載均衡;(2)提供高可用：故障容錯和無縫切換功能，將硬體和軟體錯誤造成的影響最小化;(3)通過並行執行技術提高事務響應時間----通常用於數據分析系統;(4)通過橫向擴展提高每秒交易數和連接數----通常對於聯機事務系統;(5)節約硬體成本，可以用多個廉價PC伺服器代替昂貴的小型機或大型機，同時節約相應維護成本;(6)可擴展性好，可以方便添加刪除節點，擴展硬體資源。缺點(1)相對單機，管理更復雜，要求更高;(2)在系統規劃設計較差時性能甚至不如單節點;(3)可能會增加軟體成本(如果使用高配置的pc伺服器，Oracle一般按照CPU個數收費)。在Oracle9i之前，RAC的名稱是OPS(OracleparallelServer)。RAC與OPS之間的一個較大區別是，RAC採用了CacheFusion(高速緩存合並)技術。在OPS中，節點間的數據請求需要先將數據寫入磁碟，然後發出請求的節點才可以讀取該數據。使用Cachefusion時，RAC的各個節點的數據緩沖區通過高速、低延遲的內部網路進行數據塊的傳輸。
❼ 怎樣優化oracle資料庫
1
調整數據結構的設計。這一部分在開發信息系統之前完成，程序員需要考慮是否使用ORACLE資料庫的分區功能，對於經常訪問的資料庫表是否需要建立索引等。
2
調整應用程序結構設計。這一部分也是在開發信息系統之前完成，程序員在這一步需要考慮應用程序使用什麼樣的體系結構，是使用傳統的Client/Server兩層體系結構，還是使用Browser/Web/Database的三層體系結構。不同的應用程序體系結構要求的資料庫資源是不同的。
3
調整資料庫SQL語句。應用程序的執行最終將歸結為資料庫中的SQL語句執行，因此SQL語句的執行效率最終決定了ORACLE資料庫的性能。ORACLE公司推薦使用ORACLE語句優化器（Oracle Optimizer）和行鎖管理器（row-level manager）來調整優化SQL語句。
4
調整伺服器內存分配。內存分配是在信息系統運行過程中優化配置的，資料庫管理員可以根據資料庫運行狀況調整資料庫系統全局區（SGA區）的數據緩沖區、日誌緩沖區和共享池的大小；還可以調整程序全局區（PGA區）的大小。需要注意的是，SGA區不是越大越好，SGA區過大會佔用操作系統使用的內存而引起虛擬內存的頁面交換，這樣反而會降低系統。
5
調整硬碟I/O，這一步是在信息系統開發之前完成的。資料庫管理員可以將組成同一個表空間的數據文件放在不同的硬碟上，做到硬碟之間I/O負載均衡。
6
調整操作系統參數，例如：運行在UNIX操作系統上的ORACLE資料庫，可以調整UNIX數據緩沖池的大小，每個進程所能使用的內存大小等參數。 實際上，上述資料庫優化措施之間是相互聯系的。ORACLE資料庫性能惡化表現基本上都是用戶響應時間比較長，需要用戶長時間的等待。但性能惡化的原因卻是多種多樣的，有時是多個因素共同造成了性能惡化的結果，這就需要資料庫管理員有比較全面的計算機知識，能夠敏感地察覺到影響資料庫性能的主要原因所在。另外，良好的資料庫管理工具對於優化資料庫性能也是很重要的
❽ oracle 資料庫變慢怎麼分析
1、1、調整數據結構的設計。這一部分在開發信息系統之前完成，程序員需要考慮是否使用ORACLE資料庫的分區功能，對於經常訪問的資料庫表是否需要建立索引等。
2、2、調整應用程序結構設計。這一部分也是在開發信息系統之前完成，程序員在這一步需要考慮應用程序使用什麼樣的體系結構，是使用傳統的Client/Server兩層體系結構，還是使用Browser/Web/Database的三層體系結構。不同的應用程序體系結構要求的資料庫資源是不同的。
3、3、調整資料庫SQL語句。應用程序的執行最終將歸結為資料庫中的SQL語句執行，因此SQL語句的執行效率最終決定了ORACLE資料庫的性能。ORACLE公司推薦使用ORACLE語句優化器（Oracle Optimizer）和行鎖管理器（row-level manager）來調整優化SQL語句。
4、4、調整伺服器內存分配。內存分配是在信息系統運行過程中優化配置的，資料庫管理員可以根據資料庫運行狀況調整資料庫系統全局區（SGA區）的數據緩沖區、日誌緩沖區和共享池的大小；還可以調整程序全局區（PGA區）的大小。需要注意的是，SGA區不是越大越好，SGA區過大會佔用操作系統使用的內存而引起虛擬內存的頁面交換，這樣反而會降低系統。
5、5、調整硬碟I/O，這一步是在信息系統開發之前完成的。資料庫管理員可以將組成同一個表空間的數據文件放在不同的硬碟上，做到硬碟之間I/O負載均衡。
6、6、調整操作系統參數，例如：運行在UNIX操作系統上的ORACLE資料庫，可以調整UNIX數據緩沖池的大小，每個進程所能使用的內存大小等參數。
實際上，上述資料庫優化措施之間是相互聯系的。ORACLE資料庫性能惡化表現基本上都是用戶響應時間比較長，需要用戶長時間的等待。但性能惡化的原因卻是多種多樣的，有時是多個因素共同造成了性能惡化的結果，這就需要資料庫管理員有比較全面的計算機知識，能夠敏感地察覺到影響資料庫性能的主要原因所在。另外，良好的資料庫管理工具對於優化資料庫性能也是很重要的。
ORACLE資料庫性能優化工具
常用的資料庫性能優化工具有：
1、1、ORACLE資料庫在線數據字典，ORACLE在線數據字典能夠反映出ORACLE動態運行情況，對於調整資料庫性能是很有幫助的。
2、2、操作系統工具，例如UNIX操作系統的vmstat，iostat等命令可以查看到系統系統級內存和硬碟I/O的使用情況，這些工具對於管理員弄清出系統瓶頸出現在什麼地方有時候很有用。
3、3、SQL語言跟蹤工具（SQL TRACE FACILITY），SQL語言跟蹤工具可以記錄SQL語句的執行情況，管理員可以使用虛擬表來調整實例，使用SQL語句跟蹤文件調整應用程序性能。SQL語言跟蹤工具將結果輸出成一個操作系統的文件，管理員可以使用TKPROF工具查看這些文件。
4、4、ORACLE Enterprise Manager（OEM），這是一個圖形的用戶管理界面，用戶可以使用它方便地進行資料庫管理而不必記住復雜的ORACLE資料庫管理的命令。
5、5、EXPLAIN PLAN——SQL語言優化命令，使用這個命令可以幫助程序員寫出高效的SQL語言。
ORACLE資料庫的系統性能評估
信息系統的類型不同，需要關注的資料庫參數也是不同的。資料庫管理員需要根據自己的信息系統的類型著重考慮不同的資料庫參數。
1、1、在線事務處理信息系統（OLTP），這種類型的信息系統一般需要有大量的Insert、Update操作，典型的系統包括民航機票發售系統、銀行儲蓄系統等。OLTP系統需要保證資料庫的並發性、可靠性和最終用戶的速度，這類系統使用的ORACLE資料庫需要主要考慮下述參數：
l l 資料庫回滾段是否足夠？
l l 是否需要建立ORACLE資料庫索引、聚集、散列？
l l 系統全局區（SGA）大小是否足夠？
l l SQL語句是否高效？
2、2、數據倉庫系統（Data Warehousing），這種信息系統的主要任務是從ORACLE的海量數據中進行查詢，得到數據之間的某些規律。資料庫管理員需要為這種類型的ORACLE資料庫著重考慮下述參數：
l l 是否採用B*-索引或者bitmap索引？
l l 是否採用並行SQL查詢以提高查詢效率？
l l 是否採用PL/SQL函數編寫存儲過程？
l l 有必要的話，需要建立並行資料庫提高資料庫的查詢效率
SQL語句的調整原則
SQL語言是一種靈活的語言，相同的功能可以使用不同的語句來實現，但是語句的執行效率是很不相同的。程序員可以使用EXPLAIN PLAN語句來比較各種實現方案，並選出最優的實現方案。總得來講，程序員寫SQL語句需要滿足考慮如下規則：
1、1、盡量使用索引。試比較下面兩條SQL語句：
語句A：SELECT dname, deptno FROM dept WHERE deptno NOT IN
(SELECT deptno FROM emp);
語句B：SELECT dname, deptno FROM dept WHERE NOT EXISTS
(SELECT deptno FROM emp WHERE dept.deptno = emp.deptno);
這兩條查詢語句實現的結果是相同的，但是執行語句A的時候，ORACLE會對整個emp表進行掃描，沒有使用建立在emp表上的deptno索引，執行語句B的時候，由於在子查詢中使用了聯合查詢，ORACLE只是對emp表進行的部分數據掃描，並利用了deptno列的索引，所以語句B的效率要比語句A的效率高一些。
2、2、選擇聯合查詢的聯合次序。考慮下面的例子：
SELECT stuff FROM taba a, tabb b, tabc c
WHERE a.acol between :alow and :ahigh
AND b.bcol between :blow and :bhigh
AND c.ccol between :clow and :chigh
AND a.key1 = b.key1
AMD a.key2 = c.key2;
這個SQL例子中，程序員首先需要選擇要查詢的主表，因為主表要進行整個表數據的掃描，所以主表應該數據量最小，所以例子中表A的acol列的范圍應該比表B和表C相應列的范圍小。
3、3、在子查詢中慎重使用IN或者NOT IN語句，使用where (NOT) exists的效果要好的多。
4、4、慎重使用視圖的聯合查詢，尤其是比較復雜的視圖之間的聯合查詢。一般對視圖的查詢最好都分解為對數據表的直接查詢效果要好一些。
5、5、可以在參數文件中設置SHARED_POOL_RESERVED_SIZE參數，這個參數在SGA共享池中保留一個連續的內存空間，連續的內存空間有益於存放大的SQL程序包。
6、6、ORACLE公司提供的DBMS_SHARED_POOL程序可以幫助程序員將某些經常使用的存儲過程「釘」在SQL區中而不被換出內存，程序員對於經常使用並且佔用內存很多的存儲過程「釘」到內存中有利於提高最終用戶的響應時間。
CPU參數的調整
CPU是伺服器的一項重要資源，伺服器良好的工作狀態是在工作高峰時CPU的使用率在90％以上。如果空閑時間CPU使用率就在90％以上，說明伺服器缺乏CPU資源，如果工作高峰時CPU使用率仍然很低，說明伺服器CPU資源還比較富餘。
使用操作相同命令可以看到CPU的使用情況，一般UNIX操作系統的伺服器，可以使用sar –u命令查看CPU的使用率，NT操作系統的伺服器，可以使用NT的性能管理器來查看CPU的使用率。
資料庫管理員可以通過查看v$sysstat數據字典中「CPU used by this session」統計項得知ORACLE資料庫使用的CPU時間，查看「OS User level CPU time」統計項得知操作系統用戶態下的CPU時間，查看「OS System call CPU time」統計項得知操作系統系統態下的CPU時間，操作系統總的CPU時間就是用戶態和系統態時間之和，如果ORACLE資料庫使用的CPU時間占操作系統總的CPU時間90％以上，說明伺服器CPU基本上被ORACLE資料庫使用著，這是合理，反之，說明伺服器CPU被其它程序佔用過多，ORACLE資料庫無法得到更多的CPU時間。
資料庫管理員還可以通過查看v$sesstat數據字典來獲得當前連接ORACLE資料庫各個會話佔用的CPU時間，從而得知什麼會話耗用伺服器CPU比較多。
出現CPU資源不足的情況是很多的：SQL語句的重解析、低效率的SQL語句、鎖沖突都會引起CPU資源不足。
1、資料庫管理員可以執行下述語句來查看SQL語句的解析情況：
SELECT * FROM V$SYSSTAT
WHERE NAME IN
('parse time cpu', 'parse time elapsed', 'parse count (hard)');
這里parse time cpu是系統服務時間，parse time elapsed是響應時間，用戶等待時間
waite time = parse time elapsed – parse time cpu
由此可以得到用戶SQL語句平均解析等待時間＝waite time / parse count。這個平均等待時間應該接近於0，如果平均解析等待時間過長，資料庫管理員可以通過下述語句
SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS FROM V$SQLAREA
ORDER BY PARSE_CALLS;
來發現是什麼SQL語句解析效率比較低。程序員可以優化這些語句，或者增加ORACLE參數SESSION_CACHED_CURSORS的值。
2、資料庫管理員還可以通過下述語句：
SELECT BUFFER_GETS, EXECUTIONS, SQL_TEXT FROM V$SQLAREA;
查看低效率的SQL語句，優化這些語句也有助於提高CPU的利用率。
3、3、資料庫管理員可以通過v$system_event數據字典中的「latch free」統計項查看ORACLE資料庫的沖突情況，如果沒有沖突的話，latch free查詢出來沒有結果。如果沖突太大的話，資料庫管理員可以降低spin_count參數值，來消除高的CPU使用率。
內存參數的調整
內存參數的調整主要是指ORACLE資料庫的系統全局區（SGA）的調整。SGA主要由三部分構成：共享池、數據緩沖區、日誌緩沖區。
1、 1、 共享池由兩部分構成：共享SQL區和數據字典緩沖區，共享SQL區是存放用戶SQL命令的區域，數據字典緩沖區存放資料庫運行的動態信息。資料庫管理員通過執行下述語句：
select (sum(pins - reloads)) / sum(pins) "Lib Cache" from v$librarycache;
來查看共享SQL區的使用率。這個使用率應該在90％以上，否則需要增加共享池的大小。資料庫管理員還可以執行下述語句：
select (sum(gets - getmisses - usage - fixed)) / sum(gets) "Row Cache" from v$rowcache;
查看數據字典緩沖區的使用率，這個使用率也應該在90％以上，否則需要增加共享池的大小。
2、 2、 數據緩沖區。資料庫管理員可以通過下述語句：
SELECT name, value FROM v$sysstat WHERE name IN ('db block gets', 'consistent gets','physical reads');
來查看資料庫數據緩沖區的使用情況。查詢出來的結果可以計算出來數據緩沖區的使用命中率＝1 - ( physical reads / (db block gets + consistent gets) )。
這個命中率應該在90％以上，否則需要增加數據緩沖區的大小。
3、 3、 日誌緩沖區。資料庫管理員可以通過執行下述語句：
select name,value from v$sysstat where name in ('redo entries','redo log space requests');查看日誌緩沖區的使用情況。查詢出的結果可以計算出日誌緩沖區的申請失敗率：
申請失敗率＝requests/entries，申請失敗率應該接近於0，否則說明日誌緩沖區開設太小，需要增加ORACLE資料庫的日誌緩沖區。
❾ oracle資料庫的優勢有哪些
oracle 優勢很多，大部分銀行保險電信大部分是用oracle處理的
優勢主要 有
1、處理速度快，非常快
2、安全級別高。支持快閃以及完美的恢復，即使硬體壞了 也可以恢復到故障發前的1s
3、幾台資料庫做集群資料庫，可以做到幾秒s以內故障轉移，而且數據物理完全一致，現在集群一直是最優秀的解決方案，對於銀行保險沒有其他太多的選項{數據不丟，快速切換，負載均衡}
4、網格控制，以及 數據倉庫方面 也非常強大
對了免費 以及 開源的 言論 都是錯誤的。。。oracle產品及服務都是付費的，而且價格不菲。比其他資料庫要貴，物有所值。oracle不是開源的。不過可以在redhat 或者其他開源操作系統上安裝。
mysql在sun沒被oracle收購是開源的,免費的,之後oracle公司打算 把mysql打造成不開源，收費模式的。
❿ 硬體負載均衡支持oracle資料庫嗎
oracle的高可用與負載均衡
瀏覽了一下Oracle官方的網頁以及非官方的ppt，簡單了解了一下Oracle提供的高可用方案。
1. RAC
RAC, Real Application Clusters
多個Oracle伺服器組成一個共享的Cache，而這些Oracle伺服器共享一個基於網路的存儲。這個系統可以容忍單機/或是多機失敗。
不過系統內部的多個節點需要高速網路互連，基本上也就是要全部東西放在在一個機房內，或者說一個數據中心內。如果機房出故障，比如網路不通，那就壞了。所以僅僅用RAC還是滿足不了一般互聯網公司的重要業務的需要，重要業務需要多機房來容忍單個機房的事故。
2. Data Guard.
Data Guard這個方案就適合多機房的。某機房一個proction的資料庫，另外其他機房部署standby的資料庫。Standby資料庫分物理的和邏輯的。物理的standby資料庫主要用於proction失敗後做切換。而邏輯的standby資料庫則在平時可以分擔proction資料庫的讀負載。
3. MAA
MAA(Maximum Availability Architecture)其實不是獨立的第三種，而是前面兩種的結合，來提供最高的可用性。每個機房內部署RAC集群，多個機房間用Data Guard同步。
Oracle+Fusionio+Dataguard的高可用方案
傳統的Oracle的高可用方案必須基於共享存儲設備，不管是雙機主備模式，還是Oracle RAC，資料庫必須放在共享的SAN存儲上，通過HA或集群軟體實現高可用。Oracle DataGuard是很好的容災軟體，但是作為HA解決方案，功能有很多局限性，比如數據丟失，應用透明切換，只能讀無法寫(11g)等等，目前都沒有非常好的解決方案。
自從固態存儲技術出現後，單機的IO能力大幅度提升，比如採用PCIE介面的fusionio卡，單塊卡就可以提供數萬IOPS的能力，單機的IO能力已經超過了傳統的磁碟存儲。但是，一直困擾我們的是，如何解決無共享存儲環境下Oracle資料庫的高可用問題？我們團隊設計了一種架構，提供簡單可靠的高可用功能。
雖然在Oracle的立場上，總是建議客戶能夠更好地規劃自己的應用，在有其它負載平衡方法的時候，盡量不要依賴於Oracle的Load Balance方法，但是往往在給客戶配置完Oracle RAC資料庫以後，客戶都會要求要測試負載平衡（Load Balance）和TAF（Transparent Application Failover），並且將這兩個測試作為RAC是否安裝成功的標准。
這是一件很無奈的事情，像把旁枝末節看作了主要功能，甚至有些買櫝還珠的感覺，但是畢竟這是客戶，更了解Oracle Load Balance（後文用LB表示），才可以更好滿足客戶需求。
RAC的負載均衡主要是指新會話連接到RAC資料庫時，如何判定這個新的連接要連到哪個節點進行工作。在RAC中，負載均衡分為兩種，一種是基於客戶端連接的，另外一種是基於伺服器端的。客戶端的負載均衡配置相對簡單，只需要在tnsnames.ora中添加LOAD_BALANCE=ON這么一個選項即可。
實現負載均衡(Load Balance)是Oracle RAC最重要的特性之一，主要是把負載平均分配到集群中的各個節點，以提高系統的整體吞吐能力。
通常情況下有兩種方式來實現負載均衡
一個是基於客戶端連接的負載均衡
客戶端的負載均衡主要是通過為tnsnames.ora增加load_balance=yes條目來實現
如果未開啟load_balance=yes時，Oracle Net會根據地址列表按順序來選擇一個進行連接，直到連接成功為止。 如果第一個host主機連接失敗，在有多個地址的情形下，接下來選擇第二個地址連接，依此類推，直到連接成功為止。當開啟了load_balance=yes時，則Oracle Net會從多個地址中隨機地選擇一個地址進行連接，直到連接成功為止。注意，此連接方式僅根據地址列表隨機選擇，並不考慮到各個實例上當前真正連接數量的多少，也即是沒有考慮各個節點真實的連接負載情況
二是基於伺服器端監聽器(Listener)收集到的信息來將新的連接請求分配到連接數較少實例上的實現方式。
Oracle RAC伺服器端的負載均衡是根據RAC中各節點的連接負荷數情況，將新的連接請求分配到負荷最小的節點上去。當資料庫處於運行時，RAC中各節點的PMON進程每3秒會將各自節點的連接負荷數更新到service_register。而對於節點中任意監聽器故障或監聽器意外失敗時，PMON進程會每1秒鍾檢查當前節點上的監聽是否重啟，以獲得最新的負載信息來及時調整負載均衡。
跨機房問題
跨機房問題一直都是一個老大難的問題，先看傳統資料庫的跨機房方案。
Master/Slave方案
這是最常用的方案，適用於大多數需求。Master將操作日誌實時地發送到Slave，Slave當成Master的一個Hot Backup。Master宕機時，服務切換到Slave，需要修改客戶端邏輯使得Master失效時自動尋找新的Master。
這個方案有一個問題就是資料庫的Master和Slave一般不是強同步的，所以，切換到Slave後可能丟失宕機前的少量更新。如果將 Master和Slave做成強同步的，即：所有的數據必須同時寫成功Master和Slave才成功返回客戶端，這樣又帶來了另外一個問 題：Master和Slave中任何一台機器宕機都不允許寫服務，可用性太差。因此，Oracle有一種折衷的模式：正常情況下Master和Slave 是強同步的，當Master檢測到Slave故障，比如Slave宕機或者Master與Slave之間網路不通時，Master本地寫成功就返回客戶 端。採用這種折衷的同步模式後，一般情況下Master和Slave之間是強同步的，Master宕機後切換到Slave是安全的。當然，為了確保數據安 全後，宕機的Master重啟後可以和新的Master(原有的Slave)對比最後更新的操作日誌，如果發現不一致可以提醒DBA手工介入，執行數據訂 正過程。
Master和Slave之間強同步還有一個問題就是跨機房延時，對於關鍵業務，同城的機房可以部署專用光纖，在硬體層面上解決這個問題；異地的機房一般用來做備份，與主機房之間的數據同步一般是非同步的，可能有秒級延時。
機房宕機切換自動化成本太高，但是對於很多單點服務，機房內部宕機切換的自動化很有必要。Oceanbase採用Linux的一個開源方 案：Pacemaker，通過heartbeat和虛IP漂移的方式實現機房內部宕機自動切換。由於主備切換本質上是一個選主問題，理論上只有Paxos 或者類似協議可以解決，而Pacemaker沒有採用復雜的Paxos協議，它對硬體是有依賴的，比如要求主備節點之間通過直連線保證網路不會發生故障， 而這在機房內部是可以做到的。機房之間採用前面提到的Master/Slave方案，可以寫一個腳本ping主機房的Master，當確認主機房 Master宕機時(比如一分鍾不通)將服務切換到備機房並報警。