基于Oracle 11g rac運行中案例分析研究

董李艷

（上海大學信息化工作辦公室，上海 200444）

1 Oracle RAC

Oracle real applicantion server真正應用集群簡稱Oracle RAC，是Oracle的并行集群，位于不同服務器系統(tǒng)的Oracle實例同時訪問同一個Oracle數(shù)據(jù)庫，節(jié)點之間通過私有網(wǎng)絡進行通信，所有的控制文件、聯(lián)機日志和數(shù)據(jù)文件存放在共享設備上，能夠被集群中的所有結點同時讀寫。Rac的優(yōu)點主要在于高可用性和負載均衡，一臺機器有故障不影響業(yè)務系統(tǒng)訪問數(shù)據(jù)庫[1]。圖1是由兩臺服務器搭建的一個Oracle集群的框架圖。

圖1 由兩臺服務器搭建Oracle集群框架圖

2 實際運行中遇到的故障實例

下面分析幾個在實際運行過程中的遇到的故障實例：

2.1 故障一

現(xiàn)象：業(yè)務庫運行時候發(fā)現(xiàn)鏈接數(shù)據(jù)庫比較慢，平均慢2-3s，有時候會有超時的現(xiàn)象。

分析：在得到業(yè)務系統(tǒng)的發(fā)反饋之后，首先個人使用Navicat鏈接數(shù)據(jù)庫，使用Scan Ip和兩個VipIP均可以鏈接，遠程登陸服務器在服務器上登陸數(shù)據(jù)庫也是一切正常，這種情況比較難處理，考慮從網(wǎng)絡層出發(fā)看下情況，查看兩臺服務器的網(wǎng)絡情況，發(fā)現(xiàn)鏈接慢的那一臺服務器有丟包現(xiàn)象。

圖2 故障一

知道可能是丟包造成的問題，首先查看是否是硬件問題：網(wǎng)線是否有問題，是否插拔不穩(wěn)定，網(wǎng)絡層查看網(wǎng)絡包到交換機都是沒有丟包現(xiàn)象的，現(xiàn)在這個問題可能出在Oracle集群本身，通過查找各種資源，發(fā)現(xiàn)使用的Linux下的雙網(wǎng)卡綁定的balance-rr（Round-robin policy負載均衡方式，雖然效率比較高，但是對網(wǎng)絡要求也很高，網(wǎng)絡波動可能會對rac有輕微的影響，從而影響rac的性能，需要對負載均衡的方式進行修改。選擇使用balance-alb（Adaptive load balancing）模式，該模式包含了balance-tlb模式，同時加上針對IPV4流量的接收負載均衡（receive load balance， rlb），而且不需要任何switch（交換機）的支持。接收負載均衡是通過ARP協(xié)商實現(xiàn)的。

解決方法，修改雙網(wǎng)卡綁定方式為balance-alb（Adaptive load balancing）的負載均衡模式：

#vi /etc/modprobe.conf （低版本的linux可能是/etc/modules.conf）

alias bond0 bonding

options bond0 mode=6 miimon=100 downdelay=200 primary=eth1 primary_reselect=1

再測試發(fā)現(xiàn)不再丟包，故障不復存在。

2.2 故障二

現(xiàn)象：業(yè)務系統(tǒng)發(fā)現(xiàn)會有鏈接服務器失敗的情況。分析：在發(fā)現(xiàn)外部系統(tǒng)無法正常鏈接Oracle Rac數(shù)據(jù)庫之后，登錄服務器端測試發(fā)現(xiàn)如下情況。

圖3 故障二測試情況

這種情況是審計日志太大，導致空間滿了，無法登錄，對于審計日志，如果數(shù)據(jù)庫業(yè)務庫很多很大的話，審計日志增長很快，空間很容易滿，而審計日志關閉又不能對數(shù)據(jù)庫審計，不符合維保要求，這時候考慮關閉數(shù)據(jù)庫的審計功能，開啟專門的審計服務器對數(shù)據(jù)庫進行外部審計。

解決方案：關閉數(shù)據(jù)庫內部審計功能，開啟專門的審計服務器對Oracle數(shù)據(jù)庫進行外審計的方案。

第一步查看審計功能是否開啟：

第2步：關閉審計功能

SQL> conn /as sysdba

SQL> show parameter audit

SQL> alter system set audit_trail = none scope=spfile；

第3步，將數(shù)據(jù)庫審計加入外聯(lián)審計服務器。

2.3 故障三

表現(xiàn)：日常巡查中發(fā)現(xiàn)業(yè)務系統(tǒng)最近一段時間一直都固定使用其中一臺服務器，另外一臺一直沒有正常啟用。

分析：由于是rac的運行機制，一臺機器有問題并不影響數(shù)據(jù)庫的業(yè)務運行，所以問題沒有第一時間發(fā)現(xiàn)，登錄數(shù)據(jù)庫之后發(fā)現(xiàn)，出現(xiàn)如圖4的問題：

圖4 故障三

看故障圖顯示Connected to an idle instance的意思是成功鏈接到了數(shù)據(jù)庫，但是這時候實例是沒有成功啟動的，對于登錄到一個空實例的情況，首先嘗試重啟這臺服務器的Oracle服務，重啟無效，然后嘗試對數(shù)據(jù)庫進行關閉（shutdown），啟動（startup）然后還是無效，通過查看多路徑發(fā)現(xiàn)多路徑的序列有點問題，兩臺服務器的多路徑不一致導致的。

解決方案：重做多路徑，在此過程總發(fā)現(xiàn)導致多路徑問題的是兩臺機器的心跳不一致導致的，然后將兩條心跳重新鏈接到交換機，多路徑重新做如下：

再次測試，實例正常啟動。

3 結束語

本文分析了Oracle 11g RAC運維日常中遇到的幾個問題以及解決過程，并由此認為Oracle 11g RAC日常工作中遇到問題可以嘗試以下幾個方面解決：一是登錄服務器查看服務器數(shù)據(jù)庫是否正常登錄進一步確認問題；二是查看Rac的多路徑（如果使用多路徑安裝的Rac集群）是否一致，確認是否是Rac本身導致的問題；三是登錄存儲服務器查看存儲服務器是否正常。以上給出Oracle日常運維中的幾點建議。