狗血記之RAC數據庫SQLPLUS啟庫

DBAplus社群夏海雁2018-04-13 11:25:33


轉載聲明:本文為DBA+社群原創文章,轉載必須連同本訂閱號二維碼全文轉載,並註明作者名字及來源:DBA+社群(dbaplus)。


目錄

  • 問題解決過程

  • 反思總結


1問題解決過程


ORACLE的RAC現在已經被廣泛應用,最近在數據集市項目中將原來AIX平臺10G單節點數據庫遷移升級至X86平臺11R2RAC集群數據庫,為了保證數據庫的高可用性和可擴展性,採用了RAC的GRID大集群和數據庫小集群方式(例如本次問題的環境是4節點ASM集群支撐2套2節點RAC數據庫,每個實例1臺主機)。部署好第一套2節點RAC數據庫之後,因項目進展的需要,再添加2節點給另一個地市使用。在將GRID和DB集群軟件、數據庫都創建完成之後,同事告訴我新添加的2節點RAC數據庫不能用SQLPLUS正常啟動,必須使用集群命令啟動。憑著以往的經驗,RAC節點的數據庫無論是用SQLPLUS還是集群命令都必須可以在任意節點進行任意順序啟動,不需要按照特定的順序啟動。


現在這套RAC節點數據庫還在安裝階段,還沒有投入使用,因此可以進行各種各樣的操作和測試。接到這個問題請求之後,首先進行測試,按照同事的說法,先啟動1節點,後啟動2節點,數據庫可以使用SQLPLUS正常啟動;先啟動2節點,後啟動1節點,發現2節點可以正常啟動,1節點連NOMOUNT狀態都未能進入,就報錯退出。退出之後,就查看數據庫的ALERT日誌,發現在退出前報錯集群無法進行通信。




根據報錯信息分析,是由於集群間無法通信,導致數據庫無法啟動,那麼根據這一點提示信息就拼命的從集群通信方面入手。因為這2個節點是後期採用添加節點的方式添加進去,第一懷疑是不是添加節點加出了問題,反覆詢問同事,明確回覆我在添加節點時無任何的報錯信息。那麼就只能從使用集群命令對整個集群進行檢查。使用了crsctl status resource –t ,crsctl check cluster –all,oifcfg,olsnodes,srvctl等命令進行檢查,檢查的結果都無異議,從中未能發現一點蛛絲馬跡。



再仔細對1節點的數據庫ALERT日誌向上查看,發現有打印私網通信地址為169.254.183.196,立即查看數據庫的私網通信地址發現是192.168.110.12。此時就有一個疑問,數據庫ALERT日誌中打印的私網IP地址與規劃的私網IP不一致。這個時候只好外事不決問百度,問了百度之後發現是ORACLE在11.2.0.2.0之後添加的新特性HAIP。




又因為項目趕進度,所以在內部進行商討,看看有無遇到相似或相同的案例,結果聽同事說過,他們遇到過,也是相同的問題,但沒有找到根本原因。後續申請協調各種資源進行分析 ,終於有了進一步的發現。發現在2節點使用SQLPLUS啟庫時,ALERT日誌中打印的集群IP有問題,集群間通信應該使用私網,怎麼使用SQPLUS啟庫打印為公網IP,這點就特別疑惑了。




172.31.0.116這個IP在此套RAC數據庫中定義為公網IP,那麼這個問題就初步歸結為2節點使用SQLPLUS啟庫會使用公網IP作為集群的通信網絡。又再次對集群的公網、私網等網絡進行核查和分析,並協調網絡廠家、操作系統廠家進行核查,都沒有發現問題。


到這裡之後,幾乎是山窮水盡,問題依然存在。再次百度,得到的答案是由於HAIP異常引起。於是分別獨立啟動單節點庫,查看其對就的HAIP,發現1節點為169.254.183.196,2節點為172.31.0.116。




再次對2個節點的數據庫ALERT日誌進行對比,發現其中存在一些不同的報錯信息。1節點獨立啟庫,能夠正常獲取公網、私網的IP信息。2節點則提示GPNP異常,未能獲取正常的私網、公網信息。後續緊接著查看GPNP的日誌,發現GPNP在正常工作,未有任何的報錯信息。



於是到這裡,突然靈光一閃,是不是可以用TRACE的方法跟蹤啟動過程,能否從TRACE中分析出2節點為什麼使用公網IP做為集群通信。由於是啟庫,只能重新啟動2節點至NOMOUNT狀態,然後創建PFILE,在PFILE中添加10046事件,然後使用PFILE啟動數據庫至NOMOUNT狀態。然後到TRACE目錄中去查看TRACE文件。對TRACE文件打開分析,發現TRACE文件中提示GPNP中某個文件無法訪問。




使用LS命令對文件進行查看,發現的確不存該文件,再仔細一看路徑,這個路徑不是GRID集群的安裝路徑。




仔細一看這個目錄,再結合操作系統為SUSE LINUX 11 SP2,初步確定為ORACLE用戶的環境變量問題。如果對2個節點ORACLE的環境變量進行對比,果然不同,2節點多了2行。




看到2節點多出來的2個環境變更ORA_CRS_HOME、ORA_ASM_HOME,立即找到SUSE LINUX為ORACLE特意準備的環境變量文件/etc/profile.d/oracle.sh,立即將這個文件重命名,然後退出會話,重新登陸,環境變量消失。於是使用2個會話窗口,1個查看數據庫ALERT日誌,另1個使用SQLPLUS啟庫,ALERT日誌中顯示數據庫正常能夠獲取私網、公網的IP網絡,而且HAIP也是使用169網段的。待2節點使用SQLPLUS啟庫完成之後,再在1節點使用SQLPLUS啟庫,一切正常。然後再核查其他3個節點的/etc/profile.d/oracle.sh發現該文件要麼被刪除、要麼被重命名。


2反思總結


至此為止,經過不斷的折騰,這個問題終於被解決,但是回想整個解決過程,其實很冗長,也走了很多的彎路。


  1. 檢查數據庫ALERT日誌,只檢查出問題節點,沒有立即檢查未出問題節點。


  2. 未對操作系統及其對應的環境變量熟悉,其實/etc/profile.d/oracle.sh是SUSE專門為ORACLE定製的環境變量,加上這是第1次使用SUSE安裝ORACLE數據庫,經驗不足,也是其一。


  3. 其實也曾想過是不是配置有問題,引起此次問題。在其中曾讓當初部署的同事按照ORACLE的官方文檔對操作系統配置進行一遍徹底的核查。但也未能核查出隱藏在/etc/profile.d/oracle.sh這個環境變量文件。這也正是SUSE為ORACLE定製的特色。


作者介紹:夏海雁


  • 新炬網絡公司高級技術專家,7年Oracle數據庫、TimesTen內存數據庫運維管理經驗。

  • 精通Oracle 10g、11g數據庫管理和Linux/Unix系統管理。

  • 擅長進行數據庫及集群的故障診斷與系統優化,並持續專注於故障診斷技術的研究與實踐。



小編精心為大家挑選了近日最受歡迎的幾篇熱文:

回覆001,看楊志洪《【職場心路】一個老DBA的自白》;

回覆002,看丁俊的《【重磅乾貨】看了此文,Oracle SQL優化文章不必再看!》;

回覆013,看呂海波《去不去O,誰說了算?》;

回覆014,看黎君原《扒一扒Oracle數據庫遷移中的各種坑》;

回覆015,看郭耀龍《假事務之名,深入研究UNDO與REDO》;

回覆016,看陳能技《基於Docker的開發模式驅動持續集成落地實施》;

回覆017,看朱賢文《數據庫與存儲系統》;

回覆018,看樓方鑫《數據庫中間層,這樣定製可能更好》;

回覆019,看王佩《基於Docker的mysql mha 的集群環境構建實踐》;

回覆020,看王津銀《互聯網運維的整體理念與最佳實踐》

關於DBA+社群

DBA+社群是中國最大的涵蓋各種架構師、數據庫、中間件的微信社群!線上分享2次/周、線下沙龍1次/月,頂級峰會6次/年,直接受眾10000+,間接影響50萬+ITer。DBA+社群致力於搭建一個學習交流、專業人脈、跨界合作的公益平臺,更多精彩請持續關注dbaplus微信訂閱號!


掃碼關注

DBAplus社群

超越DBA圈子,連接的不僅僅是DBA

閱讀原文

TAGS: