ASMFDやASMLib未使用の環境で、ASMが使用するディスクを以下のように構成しているとする。
SQL> select name, path from v$asm_disk order by path;
NAME PATH
--------------- ---------------
OCR_0000 /dev/sdb
DATA_0000 /dev/sdc
DATA2_0000 /dev/sdd
DATA3_0000 /dev/sdeDATA2_0000 は OS上のデバイスとして /dev/sdd、DATA3_0000 は /dev/sde に紐づいている。
ところで、Linuxでは物理的なディスクと、OSが認識するデバイス名が毎回必ずしも一致するわけではない。あるディスクが /dev/sdd として認識されることもあれば、/dev/sde として認識されることもある。
Virtual Boxなどの仮想マシンの場合、仮想ディスクの接続先ポートを入れ替えることでこのような挙動を試すことができる。
例えば、SATA ポート3に接続されている「VBRAC19_DATA2.vdi」と、SATA ポート4に接続されている「VBRAC19_DATA3.vdi」を入れ替えてみるとする。これは、冒頭に記載したASMディスクの「DATA2_0000」と「DATA3_0000」に対応しているディスクである。
こんなことをすると、ASMが認識しているディスクのパスと、実際のパスに齟齬が生じて起動できなくなるのではないか？と思うかもしれないが、実際のところ問題なく起動する。
SQL> select name, path from v$asm_disk order by path;
NAME PATH
--------------- ---------------
OCR_0000 /dev/sdb
DATA_0000 /dev/sdc
DATA3_0000 /dev/sdd
DATA2_0000 /dev/sde
見てわかる通り、DATA2_0000 は /dev/sde、DATA3_0000 は /dev/sdd と、入れ替わったことを認識してくれている。
この挙動を見る限り、ディスクグループにはOS上のデバイス名までは紐づいていないということになる。おそらく、ディスクグループマウント時に初期化パラメータの asm_diskstring に指定されたディスクのヘッダを一旦全て走査し、ディスクグループに紐づくディスクを自動的に判別してマウントしている、ということなのだろう。
SQL> show parameter asm_diskstring
NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
asm_diskstring string /dev/sd*, AFD:*ではなぜOracleはストレージパスの永続化のための仕組みとしてASMLibやASMFDといった機能を提供しているのかという疑問が出てくるのだが、正直純粋にOracleを使う上での必要性については解が出ていない。
ASMFDにはOracle以外のプロセスがディスクにデータを書き込むことを防ぐ役割もあり、どちらかというとその用途が重要になってくるのだろうと思う。
コメント