Oracle ASMのディスクが見えない・マウント失敗の対処

ディスクグループがマウントできない、追加したLUNがV$ASM_DISKに出てこない、ORA-15041で書けない。ASM関連の問い合わせはこの3つでほぼ占められる。ここではアーキテクチャ解説を省き、確認が軽い順に切り分け手順を並べる。そのあとエラー番号別の対処、リバランスの見方、恒久対策を書く。

結論：ASMのトラブルは「ディスクの見え方」と「容量」でほぼ決まる

ASMはファイルシステムを持たず、ブロックデバイスを直接扱う。ASMインスタンスが起動時・マウント時にやっているのは、ざっくり次の3つだけだ。

1. ASM_DISKSTRING（asm_diskstring）のパターンに一致するデバイスを列挙する（ディスカバリ）
2. 各デバイスの先頭アロケーションユニットにあるディスクヘッダを読み、どのディスクグループの何番のディスクかを判定する
3. ディスクグループを構成するディスクが揃っていて、整合が取れていればマウントする

失敗するのはほぼこの範囲だ。OS側でデバイスが見えていない（LUNのスキャン漏れ、マルチパス未反映、パーティション未認識）。デバイスの所有者やパーミッションが違う（再起動で/dev/sd*がroot:disk 0660に戻った、udevルール未適用）。asm_diskstringがデバイスパスに一致していない。ディスクヘッダが上書きされ、HEADER_STATUSがCANDIDATEやFORMERに戻っている。空き容量またはリバランス用の予備領域が足りない。

ASMインスタンス自体のバグや内部破損を疑う前に、上記を順に確認するのが最短ルートだ。クラスタ環境ならASMはGrid Infrastructureの管理下にあるので、crsctlで見えるCSS層も対象に入る。

原因を切り分ける手順（確認が軽い順）

手順1：ASMインスタンスとディスクグループの状態を確認する

まずASMインスタンスにSYSASMで接続する。接続自体ができない場合は後述のCSS確認へ飛ぶ。

export ORACLE_SID=+ASM          # クラスタなら +ASM1 など
export ORACLE_HOME=/u01/app/19.0.0/grid
$ORACLE_HOME/bin/sqlplus / as sysasm

-- インスタンスとディスクグループの状態
SELECT instance_name, status FROM v$instance;

SELECT group_number, name, state, type, total_mb, free_mb,
       required_mirror_free_mb, usable_file_mb, offline_disks
  FROM v$asm_diskgroup ORDER BY group_number;

STATEがDISMOUNTEDなら未マウント、MOUNTEDなら正常、RESTRICTEDはリバランス用の制限モードだ。GROUP_NUMBERが0のディスクグループは、名前だけ見えてマウントされていない状態で、構成ディスクの一部が見つかっていないことが多い。

次はディスク単位で見る。見るべきはMOUNT_STATUS、HEADER_STATUS、MODE_STATUSの3列だ。

SELECT group_number, disk_number, name, path,
       mount_status, header_status, mode_status, state,
       total_mb, free_mb
  FROM v$asm_disk ORDER BY group_number, disk_number;

各列の読み方は次のとおり。

列	値	意味・判断
MOUNT_STATUS	CACHED	正常にマウント済み
	MISSING	ディスクグループのメタデータ上は存在するが、ディスカバリで見つからない → 手順2・3へ
	CLOSED / IGNORED	見えているが使われていない。ヘッダ内容や重複パスを確認
HEADER_STATUS	MEMBER	既にディスクグループの構成メンバー
	CANDIDATE / PROVISIONED	未使用で追加可能
	FORMER	以前メンバーだったがDROP済み。意図せずこの状態ならヘッダが巻き戻っている
	FOREIGN / CONFLICT	他用途・他クラスタのデータが乗っている可能性。安易にFORCEで追加しない
MODE_STATUS	OFFLINE	ディスクがオフライン化。DISK_REPAIR_TIMEを超えると自動DROPされる

V$ASM_DISKは参照のたびにディスカバリが走る。PATHが空のMISSINGレコードが出たら、メタデータは残っているがデバイスが見えていないということだ。この時点で原因はOS側かディスカバリ文字列側に絞られる。

ASMインスタンスに接続できない、ORA-29701（Cluster Synchronization Serviceへの接続失敗）が出る場合は、ASMより下のレイヤを先に見る。

crsctl check css
crsctl stat res -t          # ora.asm, ora.<DG>.dg の状態
srvctl status asm -detail
tail -100 $ORACLE_BASE/diag/asm/+asm/+ASM1/trace/alert_+ASM1.log

手順2：OS側でデバイスが見えているか・権限が正しいかを確認する

MISSINGやPATHが空なら、OSからたどる。

# マルチパス構成ならまずこれ
multipath -ll

# 新規LUNが見えていない場合のスキャン（ホストバスごと）
for h in /sys/class/scsi_host/host*/scan; do echo "- - -" > $h; done
# パーティションテーブルの再読み込み
partprobe /dev/mapper/asm_data01

# ASMが使う想定のパスを権限込みで確認
ls -l /dev/mapper/asm_*
ls -l /dev/oracleasm/disks/        # ASMLib利用時

期待する所有者とモードは、Grid Infrastructureのインストールユーザーとasmadminグループ、0660だ。

brw-rw---- 1 grid asmadmin 252, 3 Nov  9 10:12 /dev/mapper/asm_data01

root:diskや0640になっているとASMはデバイスを開けず、ORA-15025: could not open diskやORA-27041で失敗する。サーバ再起動後だけマウントに失敗する症状はほぼこれで、udevルールが適用されていないか、ルールのENV{DM_UUID}などのマッチ条件が環境変更でずれている。

udevルールは適用し直して確認する。

# ルールの記述例（19c / OL8想定、マルチパス配下のデバイス）
cat /etc/udev/rules.d/99-oracle-asmdevices.rules
# KERNEL=="dm-*", ENV{DM_UUID}=="mpath-3600a0980...", OWNER="grid", GROUP="asmadmin", MODE="0660"

udevadm control --reload-rules
udevadm trigger --subsystem-match=block
udevadm info --query=all --name=/dev/dm-3 | head -20   # ルールのマッチ確認

ASMLib（oracleasm）を使っている場合は、スキャンとリスト表示で認識状況を見る。

oracleasm scandisks
oracleasm listdisks
oracleasm querydisk -d DATA01          # ラベルとデバイスの対応
oracleasm querydisk -p /dev/mapper/asm_data01

ノード追加やLUN追加後に1ノードだけマウントできない場合は、ノード間でデバイス名・権限・ディスカバリ文字列が揃っているかを先に比較する。ASMのディスクヘッダは共有ストレージ側にあるので、片方のノードだけ見えないならノード固有のOS設定が原因だ。

手順3：asm_diskstringとディスクヘッダ（ASMCMD lsdsk / kfed）を確認する

OS側で見えて権限も正しいのにV$ASM_DISKに出ないなら、ディスカバリ文字列の不一致を疑う。

SHOW PARAMETER asm_diskstring
-- 変更はメモリ＋SPFILEへ（クラスタは全ノードに効く）
ALTER SYSTEM SET asm_diskstring = '/dev/mapper/asm_*' SCOPE=BOTH;

asm_diskstringがNULLだと、プラットフォーム既定のパターンしか探索されない。既定がudevで付けた独自名や/dev/mapper配下を含むとは限らないため、独自デバイス名を使うなら明示的に設定する。複数パターンはカンマ区切りで指定できるが、/dev/sd*と/dev/mapper/*を同時に含めると同一ディスクが二重に見つかりORA-15020: discovered duplicate ASM diskになる。マルチパス環境では/dev/mapper側だけを指す。

マウント前でもASMCMDでディスカバリ結果を確認できる。

asmcmd lsdsk --discovery -p      # 未マウント含めてディスカバリ結果を表示
asmcmd lsdsk -k -G DATA          # ディスクグループ構成（マウント済み）
asmcmd lsdg                      # 空き容量とリバランス状況

ヘッダそのものはkfedで確認する。読み取り（read）は参照だけなので比較的安全に使える。

$ORACLE_HOME/bin/kfed read /dev/mapper/asm_data01 | head -30
# 着目点
#  kfbh.type       : 1 ; KFBTYP_DISKHEAD      ← ヘッダとして有効か
#  kfdhdb.grptyp   : 2 ; KFDGTP_NORMAL        ← 冗長性
#  kfdhdb.hdrsts   : 3 ; KFDHDR_MEMBER        ← メンバー状態
#  kfdhdb.grpname  : DATA
#  kfdhdb.dskname  : DATA_0001
#  kfdhdb.dsksize  :

kfbh.typeがKFBTYP_INVALID、hdrstsがKFDHDR_FORMERやKFDHDR_INVALIDなら、ヘッダが上書き・初期化された可能性が高い。ASMはディスクヘッダのバックアップコピーを先頭アロケーションユニット内に保持しており、kfed repairで復旧できる場合もある。ただし書き込み系の操作はヘッダ構造の理解が前提で、誤ると復旧できなくなる。本番で実施する前に対象デバイスをddで退避し、My Oracle Supportで自環境のバージョンに合う手順を確認してから実行する。

なお、kfedがGrid Homeに存在しない版ではmake -f ins_rdbms.mk ikfedでビルドしてから使う。

エラーメッセージ別の対処

ORA-15032／ORA-15063／ORA-15017：ディスクグループをマウントできない

この3つはセットで出ることが多い。

ORA-15032: not all alterations performed
ORA-15017: diskgroup "DATA" cannot be mounted
ORA-15063: ASM discovered an insufficient number of disks for diskgroup "DATA"

ORA-15032は複数の操作のうち一部が失敗したという総括メッセージで、原因は後続行にある。ORA-15063は必要な数のディスクが見つからなかったという意味で、ディスクが壊れているとは限らない。切り分けは次の順。

1. asmcmd lsdsk --discovery -pで、そのディスクグループに属すべきデバイスが何本見えているか数える
2. 足りない分について手順2（OS側の認識・権限）を確認する
3. 見えているのにHEADER_STATUSがFORMERやCANDIDATEになっていないか確認する（ヘッダ側の問題）
4. アラートログで、どのディスク番号が不足していると書かれているかを特定する（ORA-15042: ASM disk "N" is missing from group number "M"が併記されることが多い）

外部冗長（EXTERNAL REDUNDANCY）なら1本欠けただけでマウントできない。NORMAL/HIGH冗長なら、同一フェイルグループ内の欠落であればマウントできる可能性がある。FORCEで起動もできるが、強制マウントは欠落ディスクを恒久的にDROPする動作を伴い、データの冗長性が落ちる。まずデバイスを見えるようにするのが本筋で、FORCEは見えない原因がストレージ障害だと確定してからの最後の手段にする。

-- 原則：まず通常マウントを試す
ALTER DISKGROUP data MOUNT;

-- どうしても欠落ディスクが復旧できない場合（影響を理解した上で）
ALTER DISKGROUP data MOUNT FORCE;

ORA-15017だけが出てログにORA-15033（既に他インスタンスが別モードでマウント）やORA-15040が続く場合は原因が別なので、メッセージ全文をアラートログで追う。マウントできてもデータベース側が起動しないなら、ASM以外の層も含めて切り分ける。症状別の整理はOracle Database運用トラブルの切り分け｜障害と性能劣化にまとめている。

ORA-15041／ORA-15040：空き容量不足とリバランス中の領域不足

ORA-15041: diskgroup "DATA" space exhausted

ASMの空き容量判断で間違えやすいのは、V$ASM_DISKGROUP.FREE_MBをそのまま使ってしまうことだ。見るべきはUSABLE_FILE_MBである。

SELECT name, type, total_mb, free_mb,
       required_mirror_free_mb, usable_file_mb
  FROM v$asm_diskgroup;

REQUIRED_MIRROR_FREE_MBは、ディスク1本（HIGHなら構成に応じた本数）が障害で失われたときに冗長性を自動復旧するために確保しておく領域だ。USABLE_FILE_MBは冗長性を考慮したうえで、ユーザーデータとして実際に追加できる容量を表す。

USABLE_FILE_MBが負の値になっているディスクグループは、冗長性復旧の余力がない。FREE_MBが残っていても、リバランスやミラー再構成の途中で領域が尽きてORA-15041やORA-15040: diskgroup is incompleteに至る。

対処は原則としてディスク追加だ。

-- 既存ディスクと同容量を追加するのが基本
ALTER DISKGROUP data ADD DISK '/dev/mapper/asm_data05' NAME data_0005
  REBALANCE POWER 4 NOWAIT;

すぐに追加できない場合の緊急退避は、RMANでバックアップ済みを確認したうえでのアーカイブログ削除、古いバックアップセットの削除、ARCHIVELOG領域ならDB_RECOVERY_FILE_DEST_SIZE配下の整理、asmcmd ls -ls +DATA/...で確認したASM上の不要ファイルの削除がある。いずれも空けた直後にリバランスが走り、一時的にI/Oが増える点を見込んでおく。

ディスクごとの使用率が偏り、片方が先に埋まってORA-15041になるケースもある。各ディスクのFREE_MBを比較し、偏っていればリバランスを実行する。

SELECT disk_number, name, total_mb, free_mb,
       ROUND((total_mb-free_mb)/total_mb*100,1) AS used_pct
  FROM v$asm_disk WHERE group_number = 1 ORDER BY disk_number;

リバランスが終わらない・遅いときの確認ポイント

リバランスは、ディスク追加・削除・容量変更に伴ってエクステントを全ディスクへ均等に再配置する処理だ。進行状況はV$ASM_OPERATIONで見る。

SELECT group_number, operation, pass, state, power, actual,
       sofar, est_work, est_rate, est_minutes, error_code
  FROM v$asm_operation;

行が返らなければ、リバランスは完了している、あるいは起動していない。完了していないと思い込む前に、V$ASM_DISKのSTATEがNORMALか、DROPPINGのまま残っていないかを確認する。SOFARが増えずEST_MINUTESも減らないなら、I/OがボトルネックかPOWERが低い。ストレージ側のレイテンシと、同時に走っているバックアップやバッチを確認する。PASS列は12c以降、RESYNC→REBALANCE→COMPACT→REBUILDの順に進む。COMPACTパスが長引くことがあり、不要ならディスクグループ属性_rebalance_compact等での制御を検討するが、隠しパラメータの変更はサポートの指示に従う。ERROR_CODEに値が入っていればそのエラーを先に解決し、領域不足ならORA-15041系の対処へ進む。

速度はPOWERで調整する。ASM_POWER_LIMITが既定値1のままだと大規模なリバランスは長時間かかる。ディスクグループのCOMPATIBLE.ASMが11.2.0.2以降なら上限は大きく取れる（それ未満では上限11）。ただし上げるほど本番I/Oを消費するので、業務時間帯は低く、メンテナンス窓で上げる運用にする。

-- 実行中のリバランスの速度を変更する
ALTER DISKGROUP data REBALANCE POWER 8;

-- いったん止める（POWER 0）
ALTER DISKGROUP data REBALANCE POWER 0;

-- 既定値の変更
ALTER SYSTEM SET asm_power_limit = 4 SCOPE=BOTH;

DROP DISKを発行しても、リバランスが完了するまでディスクは実際には外れない。V$ASM_DISK.STATEからDROPPINGが消え、HEADER_STATUSがFORMERになるまで、物理的にLUNを取り外してはいけない。待たずに外すとORA-15063系のマウント失敗に直結する。

-- 削除は複数本をまとめて1回のリバランスで行う（分けると無駄に何度も再配置が走る）
ALTER DISKGROUP data DROP DISK data_0003, data_0004 REBALANCE POWER 6;

よくある質問

ASMのディスクを追加・削除するとき、サービスを停止する必要はある？

ディスク追加・削除はオンラインで実行でき、データベースの停止は不要だ。ただしリバランスで大量のI/Oが発生するため、性能影響は避けられない。レスポンス要件が厳しいシステムでは、POWERを低くして時間をかけるか、メンテナンス窓で実施する。複数本を扱う場合は1文にまとめ、リバランスを1回に抑えるのが定石だ。

ASMディスクに使うデバイスの推奨サイズや個数の目安は？

同一ディスクグループ内では、サイズと性能特性を揃えるのが基本方針だ。サイズが混在すると大きいディスクに多くのエクステントが割り当てられ、I/Oが偏る。本数は冗長性要件を満たす数（NORMALなら異なるフェイルグループに2つ以上）が最低で、並列性のためにはある程度分散させたほうがよい。1ディスクの最小・最大サイズやディスクグループあたりの上限本数はバージョンとCOMPATIBLE属性で変わるため、使用中バージョンのASM Administrator’s Guideで確認すること。

ASMLib・udev・AFDのどれを使えばいい？

udevは追加コンポーネントなしで所有者・権限・永続名を固定できる。ルールの書き方は環境依存だが、どのディストリビューションでも使える。ASMLib（oracleasm）はディスクにラベルを付けて管理する方式で、利用できるカーネルやディストリビューションの組み合わせに制約があるため、サポート対象かを事前に確認する。AFD（ASM Filter Driver）はGrid Infrastructure 12.1.0.2以降で提供され、デバイス名の永続化と権限管理に加え、ASMが管理するディスクへのOSからの不正な書き込みをフィルタする機能を持つ。

新規構築でGrid Infrastructureのバージョンが対応していればAFDが選択肢になるが、既存環境の移行には停止を伴う作業が必要だ。どれを使う場合でも、再起動後にデバイス名と権限が変わらないことを構築時に実機で確認しておく。マネージドサービスやExadataベースの環境ではASM層を直接操作しないことも多く、その場合は接続やネットワーク側の切り分けが中心になる（例：Oracle Database@AWSに接続できない原因と対処）。

ASMディスクグループのバックアップとメタデータの復旧はできる？

ディスクグループのメタデータはASMCMDのmd_backup／md_restoreでバックアップ・復元できる。

asmcmd md_backup /backup/asm_md_$(date +%Y%m%d).txt -G DATA
# 構成の復元（ディスクグループの再作成を伴う）
asmcmd md_restore /backup/asm_md_20261109.txt --full -G DATA

保存されるのはディスク構成、ALIASディレクトリ、属性などの構成情報で、データファイルの中身は含まれない。データの保護はRMANバックアップの責任範囲だ。md_restore --fullは空のディスクグループを作り直す動作になるため、既存データがある状態で実行してはいけない。ディスク追加・削除や属性変更のたびにmd_backupを取り、構成管理に残しておく。

再発防止：ASM運用で押さえておきたい設定と監視

デバイス名とgrid:asmadmin 0660はudev／ASMLib／AFDのいずれかで固定し、OS再起動を1回挟んでV$ASM_DISKが正常に見えることを確認する。asm_diskstringは明示設定し、マルチパス環境では/dev/mapper側だけを指して重複ディスカバリを防ぐ。クラスタでは全ノードでデバイス名・権限・asm_diskstringが同一であることを確認する。

容量の監視項目はFREE_MBではなくUSABLE_FILE_MBだ。閾値監視を入れ、負値に近づいた時点でディスク追加を計画する。追加時はディスクグループ内のサイズを揃え、フェイルグループの偏りを作らない。ASM_POWER_LIMITは平常時の値を決め、メンテナンス時だけ上げる運用にする。DISK_REPAIR_TIME属性は、一時的なパス障害でディスクが自動DROPされてフルリバランスになるのを防ぐためのもので、ストレージ側の復旧にかかる現実的な時間を踏まえて設定する。

構成の棚卸しには次のクエリを定期取得し、差分を見る。

-- 構成の棚卸しに使うクエリ（定期取得して差分を見る）
SELECT dg.name AS dg, d.disk_number, d.name, d.path, d.failgroup,
       d.mount_status, d.header_status, d.mode_status, d.state,
       d.total_mb, d.free_mb
  FROM v$asm_disk d LEFT JOIN v$asm_diskgroup dg
    ON d.group_number = dg.group_number
 ORDER BY dg.name, d.disk_number;

あわせてasmcmd md_backupの出力、udevルールとマルチパス設定（/etc/multipath.conf）、asm_diskstringの値を構成管理に残す。障害時にあるべき姿が分かっていれば、見えないディスクの特定は数分で終わる。

ASMの障害は単独で起きるとは限らない。ストレージ、OS、Grid Infrastructure、データベースのどの層の問題かを切り分けられるかで対応時間が変わる。待機イベントやREDO/UNDO、ロックといったデータベース内部の見方まで押さえておくと、どこまでがASMの話かを即断できる。

本記事に挙げたビューの列やエラー番号の意味、ディスクの上限値、COMPATIBLE属性による挙動差は、Oracle Databaseのバージョン（12c／19c／21c／23ai）とパッチレベルで変わる部分がある。実行前に自環境のバージョンの公式ドキュメントとMy Oracle Supportで確認し、kfed repairやMOUNT FORCEのような不可逆な操作は、デバイスの退避とバックアップの存在確認をセットで行うこと。