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-４０３１が発生し
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に回答してみてください(笑)