Oracle [AIX]ノード停止によりブロック破損が発生

[起こりうる現象]
AIX5L上に構築しているRAC環境で、インスタンスが起動したまま"halt -q"でノードを停止
させた場合に、反対ノードでのReconfig処理後のデータブロックリカバリ時にORA-1578
(ブロック破損)が発生する可能性があります。


[対象リリース]
 問題が発生するリリース  ：全てのリリース
問題を修正したリリース  ：Oracle Database 10g (10.1.0) *
問題を修正予定のリリース：なし
問題を修正したPSR       ：9.2.0.3 *

  * 注意: 上記の修正リリース、修正PSR は Oracle側の対応(修正)が行われた
　　バージョンとなります。本問題の対応を行う場合には、Oracle側の対応(修正)
　　に加えて、以下の対応も必要となることに注意して下さい。
    詳細は、[回避策]の項目を確認して下さい。

    - AIX側の修正(APAR IY36656(5.1)、IY38077(5.2))を適用する
    - 論理ボリューム作成時に新しいデバイスのサブタイプを使用してオフセット0
　　　オプションを指定する (-T O )


[対象プラットフォーム]
AIX 5L (5.x)、AIX 4.3.x


[起こりうる条件]
以下の条件を全て満たす場合に、本現象が発生する可能性があります。
 - データファイルに論理ボリューム(LVM)が使用されている。
 - 論理ボリュームがストライピングされている。
　 もしくは、
　 複数ディスクを用いてボリュームグループが作成されている。
 - 初期化パラメータdb_block_sizeが4k(4192)より大きな値に設定されている。
 - インスタンスが起動している状態で"halt -q"でノードを停止させた。
   （または、FC障害が発生した場合）


[原因]
本問題の根本の原因は、AIXの論理ボリューム上にOracleのデータが格納される際に上書き
できない領域としてLVCB(Logical Volume Control Block)という領域が存在していることです。
Oracleは、LVCBを上書きすることを避けるために、論理ボリューム上のOracleのデータの
格納位置を4KB後ろにずらしています。
つまり、db_block_sizeが16KBで論理ボリュームのストライプサイズが64KBであった場合、
最初のストライプのデータ配置は以下のようになっています。

LV offset USE 
from byte 0 
================================= 
0-4K LVCB 
4k-20K 1st Oracle block 
20k-36K 2nd Oracle block 
36k-52K 3rd Oracle block 
52k-64K *1st 12K of the 4th Oracle block 

4番目のOracleブロックの最初の12KBは1つ目のストライプに格納されますが、残りの4KBは
次のストライプに格納されることになります。
つまり、4つ毎のOracleブロックがそれぞれ2つのストライプにまたがって格納されることと
なります。これにより、Oracleからの16KB(ブロック単位)の書き込みが、2つの書き込みに
分割されることとなります。
ここで、"halt -q"でノードが停止された場合("halt -q"はPending I/Osが完了するのを
待たずにシステムを停止する方法と定義されています)に、一つの書き込みは完了するかも
しれませんがもう一つの書き込みが完了せずに、結果としてブロック破壊に繋がる場合が
あります。

ストライピングを行なっていない場合であっても、ボリュームグループ(VG)に複数の
ディスク(PV)を収容し、PVまたがりのある論理ボリューム(LV)を構築する場合には、
PV境界でブロック分割が発生し、ブロック破損が発生する可能性があります。


[現象発生時の対処方法]
ORA-1578(ブロック破損)が発生するため、バックアップをリストアしてメディア・リカバリ
を実施する必要があります。


[回避策]
以下のいずれかの方法で現象を回避することが可能です。
結果として、Oracleのブロックが2つのストライプ(2つのディスク)に分割されなければ
問題は発生しません。

1. AIX側の修正およびOracleの個別パッチを適用する。

   この問題に対応するため、データをオフセット0の位置から格納可能な新しいデバイスの
   サブタイプがIBM側で作成されました。Oracle側では、この新しいデバイスのサブタイプ
   を認識してオフセット0の位置からデータを格納するための修正が作成されています。
   この対処を実施する方法は以下の通りです。

    Step1. APAR IY36656(5.1)、IY38077(5.2)を適用する。
           ※ AIX 5.3, 6.1 では AIX 側のパッチ適用(Step1.の処理)は不要です。
    Step2. AIXの新しいデバイスのサブタイプを使用して論理ボリュームを作成する。
           # mklv -y lvname -T O VGname NumberOfLPs
 　        ※ ここで、引数-Tの後ろはアルファベットの大文字のオーです。
    Step3. Oracleの修正を適用する。
           PSR9.2.0.3を適用することで対応可能です。
           9.2.0.1及び9.2.0.2の場合は、個別パッチでの対応となります。
    Step4. Step2.で作成した論理ボリューム上にデータベースを再作成する。

2. db_block_sizeを2k(2048)もしくは4k(4096)にする。
　 (データベースの再作成が必要となります)

3. 論理ボリュームのストライピングを実施しないようにする。
　 もしくは、
　 ボリュームグループに複数のディスクを収容しないようにする。
 　(データの再配置が必要となります)


[FAQ]
Q. この問題はシングルインスタンス環境でも発生しますか？
A. シングルインスタンス環境でも発生する可能性はあります。
     
Q. この問題はファイルシステムにデータファイルを作成している場合にも発生しますか？
A. この問題はローデバイス(RAW DEVICE)にデータファイルを作成している場合にのみ発生
   する可能性があり、ファイルシステムの場合には発生しません。

Q. 再作成するボリューム・グループは、BigVGである必要がありますか？
A. LVCBを上書きした状態でもより安全にご利用いただくために、ボリューム・グループを
   BigVGで作成してください。(BigVGでの作成が必須となります)。BigVG作成時には、
   予め IY64691 を適用して下さい。

Q. IBMもしくはOracleのいずれかのパッチのみしか適用しなかった場合に影響はありますか？
A. 今回の問題を対処するためには、IBM及びOracle双方の修正が必要です。
   よって必ずIBM及びOracle両方のパッチを適用してください。
   なお、IBM側のみパッチを適用した場合にはデータベースの再作成時にエラーが発生し、
   データベースを再作成することができません。
   また、Oracle側のみパッチを適用した場合には別問題は発生しませんが、本Krownに対する
   修正は行われません。なぜならIBM側の修正が必要であるためです。

Q. "halt -q"でノードを停止した場合に必ずブロック破損が発生するのですか？
A. 必ずブロック破損が発生するわけではありません。
　 2つのストライプにまたがって格納されているOracleブロックがディスクに書き込
　 まれるタイミングで、"halt -q"によりノードが停止した場合に発生する可能性が
　 あります。
　 また、ノードを正常に停止(shutdown)した場合には本問題は発生しません。

Q.個別パッチ適用後(回避策1による対処後)、UFSからRaw Deviceへのコピーがうまく
　いきません。 
A.個別パッチ適用後のUFSからRaw Deviceへのコピー方法は以下の通りで、
　seek=1オプションは必要ありません。(LVCBの領域をseekする必要がないためです)
　EBSでRACを構築中の場合は注意してください。 

　dd if=<UFSのパス名> of=<Raw Deviceのパス名> bs=4096