tech_memo / oracle_RAC / problem

tech_memo/oracle_RAC

RAC2(racserver2)がいつの間にかDown †

• 2014/8/7くらいからracserver2のRACノードが停止していた。かなり放置していたが、リカバリを試みる(2014/11/26 記述)
• 以下は試したがうまくいかなかったこと
  • サーバ再起動
  • Clusterwareの再起動($GRID_HOME/bin/crsctl <start|stop> crs : 起動も停止もエラーになる)

現象 †

• Clusterwareが正常起動完了しない
• 起動も、停止もできない状態

  [root@racserver2 bin]# ./crsctl  stop crs
  CRS-2796: The command may not proceed when Cluster Ready Services is not  running
  CRS-4687: Shutdown command has completed with errors.
  CRS-4000: Command Stop failed, or completed with errors.
  
  [root@racserver2 bin]# ./crsctl  start crs
  CRS-4640: Oracle High Availability Services is already active
  CRS-4000: Command Start failed, or completed with errors.

• Clusterwareで起動されるvip(eth0:1(racserver2-vip), eth1:1)は、起動されていない。

解析 †

• サーバ再起動後のログをたどる
  • $GRID_HOME/log/racserver2/alertracserver2.logから、以下の2つのERRORをpickup
    • A) ASMリソースエラー

      2014-11-26 13:20:50.154
      [/u01/app/11.2.0/grid/bin/oraagent.bin(3115)]CRS-5011:Check of resource "+ASM" failed: details at "(:CLSN00006:)" in "/u01/app/11.2.0/grid/log/racserver2/agent/ohasd/oraagent_grid/oraagent_grid.log"

• B) OCSS(Oracle Cluster Synchronized Service)のstartに失敗

  2014-11-26 13:31:10.539
  [/u01/app/11.2.0/grid/bin/cssdagent(3449)]CRS-5818:Aborted command 'start' for resource 'ora.cssd'. Details at (:CRSAGF00113:) {0:0:2} in /u01/app/11.2.0/grid/log/racserver2/agent/ohasd/oracssdagent_root/oracssdagent_root.log.
  2014-11-26 13:31:10.539
  [cssd(3462)]CRS-1656:The CSS daemon is terminating due to a fatal error; Details at (:CSSSC00012:) in /u01/app/11.2.0/grid/log/racserver2/cssd/ocssd.log

• A)のほうはoraagent_grid.logを見てもよくわからず。
• B)の、ocssd.logを調査

  2014-11-26 13:31:10.539: [    CSSD][1563055872]###################################
  2014-11-26 13:31:10.539: [    CSSD][1563055872]clssscExit: CSSD aborting from thread GMClientListener
  2014-11-26 13:31:10.539: [    CSSD][1563055872]###################################
  2014-11-26 13:31:10.539: [    CSSD][1563055872](:CSSSC00012:)clssscExit: A fatal error occurred and the CSS daemon is terminating abnormally
  2014-11-26 13:31:10.540: [    CSSD][1563055872]clssgmUpdateEventValue: CmInfo State  val 0, changes 1
  2014-11-26 13:31:10.778: [    CSSD][1547863808]clssnmPollingThread: state(1) clusterState(0) exit
  2014-11-26 13:31:10.778: [    CSSD][1547863808]clssscExit: abort already set 0
  2014-11-26 13:31:11.146: [    CSSD][1554196224]clssnmvDHBValidateNCopy: node 1, racserver1, has a disk HB, but no network HB, DHB has rcfg 253810092, wrtcnt, 53881108, LATS 4294689760, lastSeqNo 53881107, uniqueness 1406180021, timestamp 1416976270/2203792632

• 最後の行で、racserver1のdisk HB(heartbeat)はあるが、networkHB(racserver1, racserver2間のインターコネクタによるheartbeat)がないと出ている。
• RACノード同士のHBができなくなっているので、disk HBがのtimestampが一番新しい、racserver1だけ生かして、racserver2は停止扱いとしているっぽい。
• ただ、racserver1, racserver2間のインターコネクタ通信(eth1(192.168.112.<11|12>))はできている(by ping & ssh)。なぜ、NHB(network heart beat)になるのか不明

解決方法 †

• 推測だが、racserver1はすでに、racserver2に対してNHBを行っていない可能性が高い。
• racserver1のRACノードを再起動することによって、racserver1-->racserver2へのNHBが復活する可能性が高い。
• racserver1のRACノードを、Clusterwareレベルで停止(srvctlで、DBインスタンス, リソースの順に停止していくべきだが、ミスって、いきなりClusterwareを停止してしまった)

  [root@racserver1 ~]# /u01/app/11.2.0/grid/bin/crsctl stop crs

• racserver1停止後、自動でracserver2のClusterwareおよび、DBインスタンスが起動した。
• 続いて、racserver1のClusterwareを起動

  [root@racserver1 ~]# /u01/app/11.2.0/grid/bin/crsctl start crs

• racserver1も正常起動し、無事、racserver1とracserver2の両ノードが正常動作状態に復帰した。

RACサーバ再起動 †

• RACサーバを再起動すると、いつも二度とRACを起動できなくなる。これまで再インストールしていたが、時間ができたのでがんばってみる。

alertログからの調査 †

voting diskへのアクセス権 †

• RACはcluster管理系のgridユーザとDBインスタンス管理系のoracleユーザからなり、それぞれ個別のORACLE_HOMEを持つ。
• まずはgridのalertログをチェック。

  less /u01/app/11.2.0/grid/log/racserver2/alertracserver2.log
  
  [cssd(6902)]CRS-1714:Unable to discover any voting files, retrying discovery in 15 seconds; Details at (:CSSNM00070:) in /u01/app/11.2.0/grid/log/racserver2/cssd/ocssd.log

• istrageにアクセスできていないよう。/dev/rawの権限がrootに戻っていたので、gridにふる。かつ、再起動対策で、設定ファイルに記述。詳しくは下記
  • tech_memo/ORACLE/oracle_RAC/Install/HW-setup
• サーバ再起動後、votingディスクへのアクセスはできるようになった。

クラスタ系リソース起動 †

• アラーﾄログから以下の記述

  2012-06-11 23:29:14.162
  [/u01/app/11.2.0/grid/bin/oraagent.bin(6698)]CRS-5815:Agent '/u01/app/11.2.0/grid/bin/oraagent_grid' could not find any base type entry points for type 'ora.daemon.type'. Details at (:CRSAGF00108:) {0:2:2} in /u01/app/11.2.0/grid/log/racserver2/agent/ohasd/oraagent_grid/oraagent_grid.log.
  2012-06-11 23:29:14.190
  [/u01/app/11.2.0/grid/bin/oraagent.bin(6698)]CRS-5011:Check of resource "+ASM" failed: details at "(:CLSN00006:)" in "/u01/app/11.2.0/grid/log/racserver2/agent/ohasd/oraagent_grid/oraagent_grid.log"

• よくわからない。が、crsctlコマンドでOHASは起動していること、CSSは失敗していることはわかった。

  [grid@racserver2 ~]$ crsctl check has
  CRS-4638: Oracle High Availability Services is online
  
  [grid@racserver2 ~]$ crsctl check css
  CRS-4530: Communications failure contacting Cluster Synchronization Services daemon

• network周りが怪しいと推測。racserver1とracserver2の/etc/hostsを比べてみると、racserver2のracserver1のvipやprivateIp等のIPが間違っている（いつから？）。修正して、再起動。が、変わらず。

• racserver1とracserver2でeeth1(ノード間privateコネクション用)同士の通信ができないことがわかった。ethtoolを実行で見たときに、racserver1のeth1のSpeedがUnknownになっていた。
• 22Fへ。ケーブルは刺さっているが、光っていない。挿し直した。
• eth1同士の通信確認。
• CRS, CSS, ASMリソースがONLINEになったのを確認。

DBリソース起動 †

• 準備は整ったはずなので、DBインスタンスを起動してみる。

  [oracle@racserver2 ~]$ srvctl start instance -d rac -i rac2
  PRCR-1013 : Failed to start resource ora.rac.db
  PRCR-1064 : Failed to start resource ora.rac.db on node racserver2
  CRS-5017: The resource action "ora.DATA.dg start" encountered the following  error:
  ORA-15032: not all alterations performed
  ORA-15017: diskgroup "DATA" cannot be mounted
  ORA-15063: ASM discovered an insufficient number of disks for diskgroup "DATA"

• +DATAがmountできていない。不明。
• 下記ページの以下を試してみた。
  • http://oracletechidiscussion.blogspot.jp/2011/08/ora-15063-asm-discovered-insufficient.html

    /usr/sbin > ./oracleasm listdisks
    /usr/sbin > ./oracleasm scandisks

• racserver1,racserver2ともにcrsリソースが消えて、OCRディスクグループが見えなくなった。リソース起動中にやるのはまずかったぽい。
• racserver2だけASMインスタンスをshutdown abortで停止させて、サーバ再起動してみる。