はじめに

ある深夜、サポートチームにクライアントから緊急の連絡が入りました。彼らの基幹ERPシステムにまったくアクセスできず、すべての業務が完全に停止してしまったのです。このような24時間365日稼働のシステムにおいて、ダウンタイムの1分1秒が直接的なビジネス損失につながります。

私たちは迅速に対応しました。初期調査の結果、アプリケーションサーバー自体の負荷は正常でしたが、ログにはデータベースへの接続タイムアウトや拒否エラーが大量に記録されていました。すべての兆候が、問題の原因がバックエンドのOracle RACデータベースにあることを示していました。

要塞ホスト（Bastion Host）経由でデータベースへの接続を試みたところ、一般の業務ユーザーからの接続要求はハングしたままでしたが、DBAの特権ユーザーでログインすると即座に成功しました。

sqlplus / as sysdba

このように「特権ユーザーは入れるが、一般ユーザーは拒否される」という現象は、データベースが何らかの制限状態に陥っている典型的なシグナルです。時間を無駄にせず、私たちはすぐにalertログを確認しました。あるRACノードのalertログの末尾に、心臓が止まりそうになるエラーメッセージを発見しました。

Tue May 06 02:15:10 2025
Errors in file /u01/app/oracle/diag/rdbms/orcl/ORCL1/trace/ORCL1_arc2_23456.trc:
ORA-19504: failed to create file "+ARCH/orcl/archivelog/2025_05_06/thread_2_seq_12345.285.1167890123"
ORA-17502: ksfdcre:4 Failed to create file +ARCH/orcl/archivelog/2025_05_06/thread_2_seq_12345.285.1167890123
ORA-15041: diskgroup "ARCH" space exhausted
...
Tue May 06 02:18:20 2025
ARC0: Archival stopped, error all standby destinations.
...
Tue May 06 02:20:00 2025
All archiving processes stopped. Archiver error. Connect internal only, until freed.
...
Tue May 06 02:21:00 2025
ORA-00257: archiver error. Connect internal only, until freed.

ORA-15041: diskgroup "ARCH" space exhausted と ORA-00257！この2つのエラーコードが揃ったことで、原因は明確になりました。アーカイブ・ログの格納に使用される +ARCH のディスクグループが100%フルになっていたのです。これによりアーカイバ・プロセスが停止し、データベースはデータ整合性を保護するために自己防衛的にハングアップし、すべての新規トランザクション要求を拒否していました。

私たちは直ちにASMディスクグループの使用状況をを確認しました。

-- sysasm または 権限を持つsysdbaユーザーで実行
SELECT
    name,
    total_mb,
    free_mb,
    ROUND((1 - free_mb / total_mb) * 100, 2) AS "PCT_USED"
FROM
    v$asm_diskgroup
WHERE
    name = 'ARCH';

クエリ結果は私たちの診断を裏付けるものでした。

NAME	TOTAL_MB	FREE_MB	PCT_USED
ARCH	512000	128	99.98

500GBの+ARCHディスクグループはほぼ完全に使い果たされ、残りはわずか数十MBという微々たるものでした。

しかし、なぜこのような事態に陥ったのでしょうか？私たちは毎日RMANによるバックアップとクリーンアップのスクリプトを実行しています。バックアップサーバー上のRMANログを調査したところ、根本原因が判明しました。2日前、ネットワークの不安定さにより、バックアップセットの保存先であるNFSストレージのマウントが予期せず解除されていました。さらに、バックアップスクリプトには設計上の欠陥があり、実行失敗時に一切のアラートを通知しなかったのです。これにより、アーカイブログだけが一方的に溜まり続ける状態が48時間も続き、最終的に貴重なASM領域を圧迫してしまったのです。

緊急対応：ASM上でのピンポイントなクリーンアップ

状況は危機的でした。直ちに+ARCHディスクグループの領域を解放しなければなりません。ASM環境において、OSコマンドで直接ファイルを削除することは絶対に禁止されています。安全かつ正常なクリーンアップを行うには、Oracle自身の「執事」とも言えるRMANを使用する必要があります。

NFSのバックアップ先が利用できないため、新たなバックアップは実行できません。当面の最優先事項は、すでにアーカイブ済みだが未バックアップのログの一部を削除し、サービスを復旧させることでした。これはトレードオフを伴う判断でした。これらのログを削除するということは、その瞬間にデータベースの物理障害が発生した場合、この分のデータを失うことを意味します。 お客様にリスクを説明し、承認を得た上で（これは極めて重要なステップです）、私たちはNFS障害が発生する前（2日以上前）のアーカイブ・ログを削除することにしました。これらのログは、それより前の時点で既にテープライブラリへ正常にバックアップされていたためです。

復旧手順は以下の通りです。

RMANへの接続:

rman target /

ピンポイントなクリーンアップの実行: タイムスタンプを指定したDELETEコマンドを使用し、NFS障害発生前（つまり2日以上前）に生成されたすべてのアーカイブ・ログを正確に削除しました。これは、直近2日間の重要な未バックアップログには触れない、比較的安全な操作です。

RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-2';

RMANは削除対象となるアーカイブ・ログファイルの一覧を表示し、確認を求めてきます。確認後、ファイルはASMディスクグループから安全に削除され、制御ファイル内のメタデータも同期して更新されます。

コマンド完了後、再度v$asm_diskgroupを確認すると、PCT_USEDは約75%まで低下していました。ほぼ同時に、alertログにはアーカイブ・プロセスが正常に再開したことを示す新しいメッセージが現れました。数分後、アプリケーションチームからERPシステムが完全に復旧したとの確認が取れました。「サイレント障害」によって引き起こされた深夜の危機は、ひとまず解除しました。

アーカイブ領域フルの影響：「データベースが落ちた」以上のリスク

データベーストランザクションの凍結: 全てのDML操作（INSERT, UPDATE, DELETE）が保留され、データベースの「心臓」が停止します。
アプリケーションの全面的な麻痺: データベースに依存する全てのアプリケーションが接続失敗によりクラッシュします。
業務停止とデータリスク: 生産の停止、受注処理の遅延、財務決済の不能などを引き起こします。夜間バッチの失敗は翌日のデータ不整合の原因となります。
潜在的なデータ損失リスク: この状態でメディア障害が発生した場合、バックアップされていない最新のアーカイブ・ログが失われ、永続的なデータ損失につながります。

事後分析と再発防止：同じ障害を繰り返さないために

事後対応は受動的なものですが、私たちの目標は、自己警告・自己防衛能力を持つ「防火システム」を構築することです。

1. 監視：第一の防御線

ASMディスクグループの容量監視: これが最重要項目です。ZabbixやPrometheusのようなツールとカスタムスクリプトを使い、定期的にv$asm_diskgroupビューを監視し、PCT_USEDに対して多段階の閾値アラートを設定します。
- 警告 (Warning): 使用率 > 80%でDBAチームに通知。
- 深刻 (Critical): 使用率 > 90%で電話やSMSなど多チャネルでアラートを送信し、即時介入を要求。
バックアップタスクの状態監視: スクリプトが「実行されたか」だけでなく、「成功したか」まで見る必要があります。v$rman_backup_job_detailsビューを監視することで、RMANタスクごとの状態を正確に把握できます。

-- 過去24時間以内に失敗したRMANタスクを照会
SELECT
    session_key,
    status,
    to_char(start_time, 'YYYY-MM-DD HH24:MI:SS') as start_time,
    to_char(end_time, 'YYYY-MM-DD HH24:MI:SS') as end_time,
    input_bytes_display,
    output_bytes_display
FROM
    v$rman_backup_job_details
WHERE
    start_time > SYSDATE - 1
    AND status != 'COMPLETED';

このクエリがFAILEDステータスのレコードを1件でも返した場合、即座に最高レベルのアラートを発動させるべきです。

2. バックアップスクリプトの堅牢化

新しいスクリプトは不要ですが、既存のスクリプトを「堅牢化」する必要があります。堅牢なバックアップスクリプトは以下の特性を持つべきです。

明確なエラー捕捉: RMANコマンド実行後、その戻り値やログ出力を必ずチェックします。シェルスクリプトでは、ログ内の”ORA-“や”RMAN-“エラーをgrepすることで実現できます。
障害発生時の即時通報: 障害を検知した場合、スクリプトは「沈黙のまま終了」してはなりません。アラート用APIの呼び出し、メールやSMS送信などにより、直ちに運用チームへ障害情報を通知する必要があります。
非ゼロの終了コードを使用: 失敗したスクリプトは非ゼロのステータスコード（例: exit 1）で終了すべきです。これにより、cronのような上位のスケジューラがタスクの失敗を検知し、リトライやアラートのエスカレーションといった後続処理を行えます。
「ハートビート」通知の追加: 失敗時だけでなく、成功時にもログや通知を出すようにします。これにより、運用チームが予期した時間に「成功」通知を受け取らなかった場合、スクリプトのハングやサーバーダウンといった問題を逆算して推測できます。

3. キャパシティプランニング：バッファの確保

ログ増加率の評価: 業務のピーク時におけるアーカイブ・ログの生成レートを分析します。
安全マージンの確保: +ARCHディスクグループのサイズは、少なくとも「バックアップが2～3周期連続で失敗した場合」に蓄積されるログ量を格納できる大きさを確保し、さらに20%のバッファを追加します。
FRA（Fast Recovery Area）の活用: ASM上であっても、アーカイブ先はFRA内に構成すべきです。FRAの自動領域管理機能は、領域がひっ迫した際に、保存方針に基づいて削除可能な最も古いバックアップやアーカイブ・ログを自動的に削除してくれます。これは、突発的な領域枯渇を防ぐための最後の防衛線です。

まとめ

この深夜の緊急対応は、私たちにとって大きな教訓となりました。それは、自動化システムにおける「サイレント障害」は、明確にクラッシュするエラーよりもはるかに危険であるということです。データベース運用の価値は、危機的状況での対応だけでなく、包括的な監視、回復力のある自動化、そして先見性のあるキャパシティプランニングを構築することで、そもそも危機を発生させないことにあるのです。結局のところ、最も成功した緊急対応とは、実行する必要がなかった対応のことなのです。