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

董李艷

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

1 Oracle RAC

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

圖1 由兩臺服務(wù)器搭建Oracle集群框架圖

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

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

2.1 故障一

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

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

圖2 故障一

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

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

#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)不再丟包，故障不復(fù)存在。

2.2 故障二

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

圖3 故障二測試情況

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

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

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

第2步：關(guān)閉審計功能

SQL> conn /as sysdba

SQL> show parameter audit

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

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

2.3 故障三

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

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

圖4 故障三

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

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

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

3 結(jié)束語

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