2011年7月21日木曜日

ASMインスタンスが使用するメモリサイズについて

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-4031が発生し
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月15日金曜日

SE環境で取得したコールドバックアップを EE環境にリストアする事は可能か?

モジュール入れ間違っちゃったり、
ライセンス変更になったりって、ありますよね。
(あるか?)

そんなときは、
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 にて日本語ナレッジ・ベースを利用する方法

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

1.現状の確認
[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: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 ~]# ifconfig

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を見ると色々やっているのが分かりますが、
メッセージ量が多いので割愛します。


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)その2の続き

実際設定してみます。

[環境]
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 iflist
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として追加されました。



なお、インストール時に設定することも可能です。

次回は実際に障害時の動作を見ていきます。

HAIP(Highly Available virtual IP)その2

高可用IP:HAIP(Highly Available virtual IP)その1の続き

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 アドレスが使用される


次回は実際に試してます。

HAIP(Highly Available virtual IP)その1

高可用IP:HAIP(Highly Available virtual IP)

11.2.0.2.0からの新機能で一言で言うと、冗長化可能なインターネクト用仮想IPかしら。

インターコネクトの仕様変更により、インターコネクト用に指定したインターフェースにHAIPである169.254.x.xをバインド。
DBやASMは169.254.x.xを使用して、キャッシュフュージョンとハートビートを行う※
※デフォルトだと

機能や動きは、クラスターインターコネクトを複数のインタフェースに設定しておくと、
169.254.x.xがバインドされているインタフェースが停止や疎通が出来なくなった場合に、
クラスターインターコネクトに指定した別のインタフェースに自動的に移動し、
インターコネクト障害を回避する



マニュアルより
Oracle® Clusterware管理およびデプロイメント・ガイド11gリリース2(11.2)

・oifcfg setifコマンドを使用して、インタフェースをプライベートで設定したインタフェースに対して、
1から4つの高可用性IP(HAIP)アドレスが作成される。
データベースやASMは「高可用性」かつ「ロード・バランスされたハートビートや
キャッシュフュージョンなどの通信を実現する。

・11.2.0.2以上のOracle RAC、Oracle ASMおよびOracle ACFSは、
デフォルトで、そのトラフィックすべてにこれらのHAIPアドレスを使用。
これにより、設定されたクラスタ・インターコネクト・インタフェースのセット全体で
ロード・バランシングが可能となる。
定義済クラスタ・インターコネクト・インタフェースの1つに障害が発生するか、
その通信が不能になると、Oracle Clusterwareは、該当するHAIPアドレスを機能している
残りのインタフェースの1つに透過的に移動する。

注意:
・Oracle Clusterwareが使用するインタフェースは定義されているインタフェースの数に関係なく、
常に最大で4つ。
あるインタフェースに障害が発生すると、HAIPアドレスは定義されたセット内の
別の構成済インタフェースに移動。

・HAIPアドレスが1つのみで、選択するインタフェースが複数ある場合、
HAIPアドレスの移動先のインタフェースは、そのアドレスが構成された元のインタフェースでは
なくなる。
Oracle Clusterwareは、HAIPアドレスの追加先として、数が最も小さいサブネットの
インタフェースを選択する。


長くなってきたので、次回にHAIP情報をもう少し続けます。

2011年7月9日土曜日

ASMとLOG_ARCHIVE_DEST

LOG_ARCHIVE_DESTにディスク・グループが指定されている場合
(例)LOG_ARCHIVE_DEST = +dgroup1
LOG_ARCHIVE_FORMATは無視されます。

LOG_ARCHIVE_DESTをディスク・グループ名に設定した場合、
LOG_ARCHIVE_FORMATは無視されます。
アーカイブ・ログには、Oracle Databaseによって一意の名前が自動的に作成されます。
LOG_ARCHIVE_DESTをディスク・グループ内のディレクトリに設定した場合、
LOG_ARCHIVE_FORMATには通常のセマンティクスが設定されます。


Oracle Database 管理者ガイド10gリリース2(10.2)


11gR2もルールは一緒。


ASMにおける、完全修飾されたASMファイル名のfile_typeとテンプレート、
別名ASMファイル名の関係、
不完全ASMファイル名と_DESTの関係は別途纏めよっと。

RDA4.24とダウンロードの話し

RDA(Remote Diagnostic Agent)
RDA とはオラクル導入環境のシステム構成やOracle関連情報、稼動状況、
ログ等の詳細な情報を収集することができる、オラクル社と保守契約結んでいる場合に
無料で使用できる便利なツール。

米国時間 6月14日 に RDA 4.24 がリリースされたそうです。
Grid Infrastructure 環境における /etc/oracle/olr.loc を使用した
ORA_CRS_HOME の検出処理への対応などなど。

[機能改良についての詳細]
RDA 4 Release Notes [ID 414970.1]

[ネタ元]
Oracle Support Japan
RDA 4.24 がリリースされました


ところで、「OiSCは、2011年6月30日を以てサービスを終了しました。」なわけで、
RDAのダウンロードサイトもMy Oracle Supportのみに↓

Remote Diagnostic Agent (RDA) 4 - Getting Started [ID 314422.1]


使い方とかのお勉強はココからがいいかも。
RDA (Remote Diagnostic Agent) の紹介

2011年7月5日火曜日

Oracleクラスタウェア(OIFCFG)からネットワーク・インターフェース リストを取得できませんエラー

Oracleクラスタウェア(OIFCFG)からネットワーク・インターフェース リストを取得できませんエラー

[環境]
OS:Linux Redhat Linux 5.6(2.6.18-238.el5) 64bit
Oracle:11.2.0.2.0 64bit
環境:RAC

[発生事象]
GRIDインストール後にOUIからデータベース製品インストール時に、
モジュールインストール直前のベリファイチェック開始直後に発生。
OKボタン押下後、OUI異常終了

[エラーメッセージ]
クラスタ検証フレームワークで内部エラーが発生しました
Oracleクラスタウェア(OIFCFG)からネットワーク・インターフェース
リストを取得できません。

or

NFO: Nodes are prepared for verification.
SEVERE: [FATAL] An internal error occurred within cluster verification framework
Unable to obtain network interface list from Oracle Clusterware (OIFCFG).
Refer associated stacktrace #oracle.install.commons.util.exception.DefaultErrorAdvisor:763※

※行は、OUIのログより。また、763は755のケースもあるかも

[解決策]
同様の事象と合致するログ情報等なし。
DOC ID:1050472.1のログとは一致しなかったが、
oifcfgが原因臭いので、ORA_NLS10を外して実行して回避


発生原因、解決策共に微妙な結果に。。。

ASMLIB+GRID11.2.0.2.0インストールでのエラー

[環境]
OS:Linux Redhat Linux 5.6(2.6.18-238.el5) 64bit
Oracle:11.2.0.2.0 64bit
環境:RAC

【GRIDインストール直前のベリファイで以下のエラーが発生】
----------------------------------------------------------------------------------------------------------------
失敗したノードの検証結果: test-01
 エラーのリスト
 
 - PRVF-5150: パスORCL:DISK1は、すべてのノードで有効なパスではありません
   - Cause:
   - Action:
  
失敗したノードの検証結果: test-02
 エラーのリスト
 
 - PRVF-5150: パスORCL:DISK1は、すべてのノードで有効なパスではありません
   - Cause:
   - Action:

----------------------------------------------------------------------------------------------------------------


英語のメッセージだと
PRVF-5150:Path ORCL:XXX is not a valid path


【原因】
バグ。。。
詳細は、DOC ID:1210863.1

【対処】
胸に手を当て心当たりがなければ、己を信じて、「全て無視」にチェックを入れ進む。

『この道をいけばどうなるものか危ぶむなかれ 危ぶめば道はなし踏み出せばその一歩が道となり その一足が道となる迷わず行けよ 行けばわかるさ』 一休宗純

ASMLIBメモ

ASMLIBに関するメモ

【ASMLIBダウンロードサイト】

Linuxであれば、「uname -rm」の実行結果で出力されるカーネルバージョンを確認して
以下の3種類のファイルをダウンロード



[Library and Tools]
oracleasm-support-version.arch.rpm
oracleasmlib-version.arch.rpm
oracleasm-kernel-version.arch.rpm

マニュアルは以下を参照


【ざっくり手順】
1.ダウンロードしたrpmのインストール
2.スクリプトの環境設定&作成(ユーザとかグループとかも設定します。)
3.oracleasmカーネル・モジュールをロード
4.ディスクをOracle ASMディスクとしてマークキング[どれか1ノードで実行]
5.マーキングされたASMディスクを他のノードで使用可能にする[残りのノードで実行]

【注意点】
4でマーキングするディスクは、
事前にfdiskとかでディスク・デバイスに、単一のディスク全体パーティションを作成しとく。
事前にやっとかないと失敗する。

/var/log/oracleasmというログファイルには、以下のメッセージが出力される。
 「devaice デバイス名 is not a partition」



実際の実行手順や結果はまた今度。