OTNで以下の質問を見かけました。
ASMインスタンスが使用するメモリ（SGA等）サイズてMEMORY_TARGETのデフォルトで十分なものなのですか？
なんか質問の書き方があまり好きになれなかったので、
こちらに回答を書いてみようかと思います。
[環境]
OS:Linux Redhat Linux 5.6(2.6.18-238.el5) 64bit
Oracle:11.2.0.2.0 64bit SE
環境:2node RAC
経験的にはDiskGroup(DG)の数が大量に存在するorサイズが大きいとかがない限り、
標準のMEMORY_TARGETで良いと思います。
DGの数が大量orサイズが大き目の場合、
LARGE_POOLやMEMORY_TARGETの引き上げを検討するのも悪くないと思います。
過去の経験で、asmcmdからのDGリストア、DGのマウント時にORA-４０３１が発生し
ASMが起動しなかったことがあります。
数が大量orサイズが大き目と書きましたが、
なお、その時はDGが7つ合計サイズが1.5TB弱でした。
--------------------
本問題はORA-4031なので、正確にはMEMORY_TARGETではなく
LARGE_POOLが足りてないのが原因ですが。
その時の状況はこんな感じでした。
ASMによるDGのリカバリでORA-4031⇒ASMが正常に起動できない⇒
crsd.binが起動しない⇒CRSが正常に起動しない。
(CRSのDGを読み取れないからかな。と思った記憶があります。)
また、SPFILEがASM上に格納されており、
ASMインスタンスが起動しないためalter文で変更も出来ず、
悲惨な状況になりました。
その時は、素直にLARGE_POOLだけを100MBに引き上げましたが、
メモリに余裕があるのであれば、MEMORY_TARGETも
引き上げてもいいかもしれません。
(LARGE_POOLが少ないとDGの復旧時間や
CRS起動時の時間にも影響しそうな気もするし。 )
------------
(余談)
上記障害時にSPFILEがASM上に格納されており、
ASMインスタンスが起動しないためと書きましたが、
じゃあどうしたかというと
DOC ID:1062983.1
「How to restore ASM based OCR after complete loss of the CRS diskgroup」
を参考にCRSを制限モードで起動、ASM用のPFILEをALERT.logから手動で作成し
(LARGE_POOLを100MBにしたPFILE)で起動。
ALTER文でSPFILE作成。
あと、ASMのalert.logを見るとORA-20が出てたりもするので、
processesを引き上げたりもしてるかも。
(これもDGが多い場合に見られる気が。。)
------------
(個人的な結論)
基本的にそんなにでかいメモリ領域が必要なわけではないのでだから、
カットオーバー前にしっかりテストやalertを見て、
必要に応じて変更されたらどうなんでしょうかね？
どなたか他にご意見アドバイスがあれば、
コメントいただくかOTNに回答してみてください(笑)
2011年7月21日木曜日
2011年7月15日金曜日
SE環境で取得したコールドバックアップを EE環境にリストアする事は可能か？
モジュール入れ間違っちゃったり、
ライセンス変更になったりって、ありますよね。
(あるか？)
そんなときは、
KROWN#50822
もし、SE環境をEE環境に入れ直したいけど、
もうデータ入れちゃってんだよなぁ。。。
というときには、、
1. SE 環境のコールドバックアップを取得します。
2. SEをOUIから消します。
3. EEを入れ直します。
4.事前に取得したコールドバックアップをEE環境にリストアします。※別環境なら
* 各ファイルのパスは同一にします。
5. EE環境にてデータベースを起動します。
6. catalog.sql, catproc.sql を実行します。
逆に、Enterprise Edition (EE) 環境のデータベースを
Standard Edition (SE) 環境に変更(移行)するには、
Export/Import で対応。
ライセンス変更になったりって、ありますよね。
(あるか？)
そんなときは、
KROWN#50822
Standard EditionのコールドバックアップをEnterprise Editionへ
リストアするのはサポートされます。
もし、SE環境をEE環境に入れ直したいけど、
もうデータ入れちゃってんだよなぁ。。。
というときには、、
1. SE 環境のコールドバックアップを取得します。
2. SEをOUIから消します。
3. EEを入れ直します。
4.事前に取得したコールドバックアップをEE環境にリストアします。※別環境なら
* 各ファイルのパスは同一にします。
5. EE環境にてデータベースを起動します。
6. catalog.sql, catproc.sql を実行します。
逆に、Enterprise Edition (EE) 環境のデータベースを
Standard Edition (SE) 環境に変更(移行)するには、
Export/Import で対応。
EE 環境で取得したコールドバックアップを SE 環境にリストアする
ことはサポートされない。
My Oracle Support 5.3 とKROWN
さーて、Oracleの関係マニュアルも一通り読んだし
KROWNでバグやらマニュアルバグをチェックしよっかなー
！！！！
MOSのナレッジタブの中に日本語ナレッジ・ベースがない！！
KROWNがない！！
ない、ない、ない。
キョロ(・・ )( ・・)キョロ(.. )( ..)キョロ(¨ )( ¨)キョロ
なんて、
ちゃんと、Oracle Support Japanでアナウンスされてましたね。
(Twitterでなんとなく見たのを覚えていてよかったぁ)
ということで、詳細はこちら
Oracle Support Japan
My Oracle Support 5.3 にて日本語ナレッジ・ベースを利用する方法
KROWNでバグやらマニュアルバグをチェックしよっかなー
！！！！
MOSのナレッジタブの中に日本語ナレッジ・ベースがない！！
KROWNがない！！
ない、ない、ない。
キョロ(・・ )( ・・)キョロ(.. )( ..)キョロ(¨ )( ¨)キョロ
なんて、
ちゃんと、Oracle Support Japanでアナウンスされてましたね。
(Twitterでなんとなく見たのを覚えていてよかったぁ)
ということで、詳細はこちら
Oracle Support Japan
My Oracle Support 5.3 にて日本語ナレッジ・ベースを利用する方法
HAIP(Highly Available virtual IP)その5
HAIP(Highly Available virtual IP)その4のつづき
HAIPの話も最後、追記とその他よもや話
=================================
・oifcfg setifコマンドを使用して、インタフェースをプライベートで設定した
インタフェースに対して、1から4つの高可用性IP（HAIP）アドレスが作成される。
データベースやASMは「高可用性」かつ「ロード・バランスされたハートビートや
キャッシュフュージョンなどの通信を実現する。
=================================
実はさっきの検証でIPが一個しかないのはおかしいと思ってました(苦笑)
なのでcrsを再起動したところ、、、、
eth1 Link encap:Ethernet HWaddr 00:0C:29:EC:22:AE
inet addr:10.0.0.136 Bcast:255.255.255.255 Mask:254.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:445151 errors:0 dropped:0 overruns:0 frame:0
TX packets:522844 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:233173632 (222.3 MiB) TX bytes:345513311 (329.5 MiB)
eth1:1 Link encap:Ethernet HWaddr 00:0C:29:EC:22:AE
inet addr:169.254.2.227 Bcast:169.254.127.255 Mask:255.255.128.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth2 Link encap:Ethernet HWaddr 00:0C:29:EC:22:B8
inet addr:192.168.102.136 Bcast:192.168.102.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:86100 errors:0 dropped:0 overruns:0 frame:0
TX packets:84814 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:41051983 (39.1 MiB) TX bytes:37303876 (35.5 MiB)
eth2:1 Link encap:Ethernet HWaddr 00:0C:29:EC:22:B8
inet addr:169.254.252.248 Bcast:169.254.255.255 Mask:255.255.128.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
ですよね(笑)
ということで、設定後はcrsの再起動もお忘れなく。
その他 インターコネクト障害からの自動復旧時のおまじないな話
通常、インターコネクト障害発生後にNICやらケーブルやらの問題を解決すると、
障害時に落とされたノード(ノード番号が大きい方)は、
自動的にClusterに復帰しようとします。
この時、インターコネクト障害がノード2の際に発生するバグが。。。
Bug 11894981
1. IPC Send timeoutがASM、DBで発生。
2. ORA-29740を受けて、ノード2のASMが異常終了
つられて、ノード2のインスタンスがORA-15064でダウン
3. DBは再起動されるも、他ノードのインスタンスと通信できず、
lmonの異常終了により起動せず。
4. ノード2のASMも自動起動しようとするが、ノード1のASMからkillされてしまう。
この動作が繰り返し発生
IPC Sendタイムアウトによるものだが、ハートビートエラーが
ocssd.logに出てこない。。
うぅ。。カオス・・・
では、どうればいいか。
インターコネクトの障害復旧時にはノード2を止めておく。
0.ノード1 or ノード2のインターコネクト障害により、
ノード2のCRSリソースが停止される
1.ノード2の停止
2.インターコネクト障害の解消
3.ノード2を起動
おまじないかもしれないが、
インターコネクトの自動復旧は、HAIPが新しく追加されたこともあるので、
個人的にはおススメしない。
ちなみにひどいケースだと、
ノード2がclusterに復帰しようとして、
ノード1のCRSが異常終了したり、ASMが落ちたりというケースも・・・。
DB全停止の悪夢・・・
ちなみにBug 11894981、現時点ではバッチも修正バージョンも出てないようです。。
HAIP(Highly Available virtual IP)その4
高可用IP:HAIP(Highly Available virtual IP)その3の続き
障害時の動きを確認します。
[環境]
OS:Linux Redhat Linux 5.6(2.6.18-238.el5) 64bit
Oracle:11.2.0.2.0 64bit
環境:RAC
eth1 Link encap:Ethernet HWaddr 00:0C:29:EC:22:AE
inet addr:10.0.0.136 Bcast:255.255.255.255 Mask:254.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:67867 errors:0 dropped:0 overruns:0 frame:0
TX packets:58530 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:47764460 (45.5 MiB) TX bytes:36241394 (34.5 MiB)
eth1:1 Link encap:Ethernet HWaddr 00:0C:29:EC:22:AE
inet addr:169.254.166.30 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth2 Link encap:Ethernet HWaddr 00:0C:29:EC:22:B8
inet addr:192.168.102.136 Bcast:192.168.102.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13292 errors:0 dropped:0 overruns:0 frame:0
TX packets:17989 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6075352 (5.7 MiB) TX bytes:10999457 (10.4 MiB)
HAIP(169.254.166.30)がeth1にバインドされているのが分かります。
・・・・
通常なら、これでインターコネクト障害が発生し、
ノード番号の大きいzaku-2のCRSリソースの停止やVIPのフェイルオーバーが
発生するはず。
eth2 Link encap:Ethernet HWaddr 00:0C:29:EC:22:B8
inet addr:192.168.102.136 Bcast:192.168.102.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:17986 errors:0 dropped:0 overruns:0 frame:0
TX packets:20421 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10152673 (9.6 MiB) TX bytes:12136130 (11.5 MiB)
eth2:1 Link encap:Ethernet HWaddr 00:0C:29:EC:22:B8
inet addr:169.254.166.30 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
想定通り、eth2にHAIP(169.254.166.30)がフェイルオーバーしています。
[/var/log/messages]
avahi-daemon[3938]: Interface eth1.IPv4 no longer relevant for mDNS.
avahi-daemon[3938]: Leaving mDNS multicast group on interface eth1.IPv4 with address 10.0.0.136.
avahi-daemon[3938]: Withdrawing address record for 169.254.166.30 on eth1.
avahi-daemon[3938]: Withdrawing address record for 10.0.0.136 on eth1.
avahi-daemon[3938]: Registering new address record for 169.254.166.30 on eth2.
HAIPを移動させているのが分かります。
ocssd.logを見ると色々やっているのが分かりますが、
メッセージ量が多いので割愛します。
[root@zaku-2 ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:0C:29:EC:22:AE
inet addr:10.0.0.136 Bcast:255.255.255.255 Mask:254.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:198102 errors:0 dropped:0 overruns:0 frame:0
TX packets:217713 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:114094624 (108.8 MiB) TX bytes:143149783 (136.5 MiB)
eth1:1 Link encap:Ethernet HWaddr 00:0C:29:EC:22:AE
inet addr:169.254.166.30 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth2 Link encap:Ethernet HWaddr 00:0C:29:EC:22:B8
inet addr:192.168.102.136 Bcast:192.168.102.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:44973 errors:0 dropped:0 overruns:0 frame:0
TX packets:50754 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:21009571 (20.0 MiB) TX bytes:27365175 (26.0 MiB)
HAIPがeth1に自動的にフェイルバックしています。
なお、HAIPのethの移動は、両ノードで発生します。
---------
ということで、HAIPの動きは分かったわけですが、
通常ネットワーク機能で冗長化を図っているインターコネクトですが、
ソフト機能であるHAIPも使ってインターコネクトの可用性を高めるのは、
いささか冗長な気がします。
ネットワーク機能ではなく、HAIPを使えということなんだろうか・・・？
障害時の動きを確認します。
[環境]
OS:Linux Redhat Linux 5.6(2.6.18-238.el5) 64bit
Oracle:11.2.0.2.0 64bit
環境:RAC
1.現状の確認
[root@zaku-2 ~]# ifconfigeth1 Link encap:Ethernet HWaddr 00:0C:29:EC:22:AE
inet addr:10.0.0.136 Bcast:255.255.255.255 Mask:254.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:67867 errors:0 dropped:0 overruns:0 frame:0
TX packets:58530 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:47764460 (45.5 MiB) TX bytes:36241394 (34.5 MiB)
eth1:1 Link encap:Ethernet HWaddr 00:0C:29:EC:22:AE
inet addr:169.254.166.30 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth2 Link encap:Ethernet HWaddr 00:0C:29:EC:22:B8
inet addr:192.168.102.136 Bcast:192.168.102.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13292 errors:0 dropped:0 overruns:0 frame:0
TX packets:17989 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6075352 (5.7 MiB) TX bytes:10999457 (10.4 MiB)
HAIP(169.254.166.30)がeth1にバインドされているのが分かります。
2.eth1をリンクダウンします
[root@zaku-2 ~]# ifconfig eth1 down・・・・
通常なら、これでインターコネクト障害が発生し、
ノード番号の大きいzaku-2のCRSリソースの停止やVIPのフェイルオーバーが
発生するはず。
が、何も起きません。
HAIPがeth2にフェイルオーバーしたことにより、
継続稼働出来ていると思われます。
3.状況の確認
[root@zaku-2 ~]# ifconfigeth2 Link encap:Ethernet HWaddr 00:0C:29:EC:22:B8
inet addr:192.168.102.136 Bcast:192.168.102.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:17986 errors:0 dropped:0 overruns:0 frame:0
TX packets:20421 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10152673 (9.6 MiB) TX bytes:12136130 (11.5 MiB)
eth2:1 Link encap:Ethernet HWaddr 00:0C:29:EC:22:B8
inet addr:169.254.166.30 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
想定通り、eth2にHAIP(169.254.166.30)がフェイルオーバーしています。
[/var/log/messages]
avahi-daemon[3938]: Interface eth1.IPv4 no longer relevant for mDNS.
avahi-daemon[3938]: Leaving mDNS multicast group on interface eth1.IPv4 with address 10.0.0.136.
avahi-daemon[3938]: Withdrawing address record for 169.254.166.30 on eth1.
avahi-daemon[3938]: Withdrawing address record for 10.0.0.136 on eth1.
avahi-daemon[3938]: Registering new address record for 169.254.166.30 on eth2.
HAIPを移動させているのが分かります。
ocssd.logを見ると色々やっているのが分かりますが、
メッセージ量が多いので割愛します。
4.eth1のリンクアップ後の動き
[root@zaku-2 ~]# ifconfig eth1 up[root@zaku-2 ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:0C:29:EC:22:AE
inet addr:10.0.0.136 Bcast:255.255.255.255 Mask:254.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:198102 errors:0 dropped:0 overruns:0 frame:0
TX packets:217713 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:114094624 (108.8 MiB) TX bytes:143149783 (136.5 MiB)
eth1:1 Link encap:Ethernet HWaddr 00:0C:29:EC:22:AE
inet addr:169.254.166.30 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth2 Link encap:Ethernet HWaddr 00:0C:29:EC:22:B8
inet addr:192.168.102.136 Bcast:192.168.102.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:44973 errors:0 dropped:0 overruns:0 frame:0
TX packets:50754 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:21009571 (20.0 MiB) TX bytes:27365175 (26.0 MiB)
HAIPがeth1に自動的にフェイルバックしています。
なお、HAIPのethの移動は、両ノードで発生します。
---------
ということで、HAIPの動きは分かったわけですが、
通常ネットワーク機能で冗長化を図っているインターコネクトですが、
ソフト機能であるHAIPも使ってインターコネクトの可用性を高めるのは、
いささか冗長な気がします。
ネットワーク機能ではなく、HAIPを使えということなんだろうか・・・？
HAIP(Highly Available virtual IP)その3
高可用IP:HAIP(Highly Available virtual IP)その２の続き
実際設定してみます。
[環境]
OS:Linux Redhat Linux 5.6(2.6.18-238.el5) 64bit
Oracle:11.2.0.2.0 64bit
環境:RAC
eth1 10.0.0.0
eth1 169.254.0.0
eth2 192.168.102.0
virbr0 192.168.122.0
eth0 192.168.101.0
iflistコマンドは、オペレーティング・システムに問い合せ、
このノードに存在するネットワーク・インタフェースを検出します
インターフェイスが4つあることが分かります。
[grid@zaku-1 ~]$ oifcfg getif
eth1 10.0.0.0 global cluster_interconnect
eth0 192.168.101.0 global public
setifコマンドによってインタフェース・タイプが定義されているインタフェースを、
インタフェースのタイプとともに示します。
eth1がインターコネクト用、eth0がパブリック用であることが分かります。
Oracleとしては、eth2は使用していない状態です。
2.eth2にクラスターインターコネクトを設定します。[grid@zaku-1 ~]$ oifcfg setif -global eth2/192.168.102.0:cluster_interconnect
oifcfg setifは、インタフェースのインタフェース・タイプ
（パブリックまたはクラスタ・インターコネクト）を設定します。
[grid@zaku-1 ~]$ oifcfg getif
eth1 10.0.0.0 global cluster_interconnect
eth0 192.168.101.0 global public
eth2 192.168.102.0 global cluster_interconnect
eth2がcluster_interconnectとして追加されました。
なお、インストール時に設定することも可能です。
次回は実際に障害時の動作を見ていきます。
実際設定してみます。
[環境]
OS:Linux Redhat Linux 5.6(2.6.18-238.el5) 64bit
Oracle:11.2.0.2.0 64bit
環境:RAC
1.現状の確認
[grid@zaku-1 ~]$ oifcfg iflisteth1 10.0.0.0
eth1 169.254.0.0
eth2 192.168.102.0
virbr0 192.168.122.0
eth0 192.168.101.0
iflistコマンドは、オペレーティング・システムに問い合せ、
このノードに存在するネットワーク・インタフェースを検出します
インターフェイスが4つあることが分かります。
[grid@zaku-1 ~]$ oifcfg getif
eth1 10.0.0.0 global cluster_interconnect
eth0 192.168.101.0 global public
setifコマンドによってインタフェース・タイプが定義されているインタフェースを、
インタフェースのタイプとともに示します。
eth1がインターコネクト用、eth0がパブリック用であることが分かります。
Oracleとしては、eth2は使用していない状態です。
2.eth2にクラスターインターコネクトを設定します。
oifcfg setifは、インタフェースのインタフェース・タイプ
（パブリックまたはクラスタ・インターコネクト）を設定します。
[grid@zaku-1 ~]$ oifcfg getif
eth1 10.0.0.0 global cluster_interconnect
eth0 192.168.101.0 global public
eth2 192.168.102.0 global cluster_interconnect
eth2がcluster_interconnectとして追加されました。
なお、インストール時に設定することも可能です。
次回は実際に障害時の動作を見ていきます。
HAIP(Highly Available virtual IP)その2
高可用IP:HAIP(Highly Available virtual IP)その１の続き
11.2.0.2.0から、インターコネクトの仕様変更に関する情報
KROWN#152202より
※1)は正確にはHAIPの機能ではなく仕様変更
インターコネクト障害時には、CRSリソースの停止やVIPのフェイルオーバー、
残存ノードでのインスタンスリカバリーが発生。
でも、ノードは落ちない。
Voting Disk に対するアクセス障害が発生した場合も、CRS リソースの停止が行えれば、
リブートは発生しない。
自動的にフェイルオーバー。復旧時には自動的に元のインターフェイスにフェイルバック。
サブネットが違う可能性があるので、両ノードセットでHAIPが移動する。
4)11.2.0.2 以降の初期化パラメータcluster_interconnects設定時の動き
cluster_interconnectsを使用。
だが、Grid Infrastructure のプロセス(例：CSS)が使用するプライベート IP アドレスは、
OCR にcluster_interconnect として登録されている プライベート IP アドレスが使用されます。
つまり、ハートビートはHAIP のプライベート IP アドレスが使用される。
次回は実際に試してます。
11.2.0.2.0から、インターコネクトの仕様変更に関する情報
KROWN#152202より
※1)は正確にはHAIPの機能ではなく仕様変更
1)11.2.0.2 でインターコネクト障害時にOSリブートが発生しなくした
仕様変更の理由は、そのノード上で他のアプリが動いている可能性もあるしね。インターコネクト障害時には、CRSリソースの停止やVIPのフェイルオーバー、
残存ノードでのインスタンスリカバリーが発生。
でも、ノードは落ちない。
Voting Disk に対するアクセス障害が発生した場合も、CRS リソースの停止が行えれば、
リブートは発生しない。
2)HAIP は自動でフェイルバックする
障害時には、クラスターインターコネクトに指定された他のインターフェイスに自動的にフェイルオーバー。復旧時には自動的に元のインターフェイスにフェイルバック。
サブネットが違う可能性があるので、両ノードセットでHAIPが移動する。
3)11.2.0.2 よりマルチキャスト通信
HAIPで複数のネットワークアドレスを使用してノード間通信を行うためです。4)11.2.0.2 以降の初期化パラメータcluster_interconnects設定時の動き
DB同士のキャッシュフュージョンは、cluster_interconnectsに設定したプライベート IP
アドレスで通信が行われる。
たとえば、複数インスタンス環境で使用するインターコネクトを分ける場合等には、cluster_interconnectsを使用。
だが、Grid Infrastructure のプロセス(例：CSS)が使用するプライベート IP アドレスは、
OCR にcluster_interconnect として登録されている プライベート IP アドレスが使用されます。
つまり、ハートビートはHAIP のプライベート IP アドレスが使用される。
次回は実際に試してます。
登録:
投稿 (Atom)