Oracleデータベースの運用において、特定の表領域で障害が発生した場合、データベース全体を停止させることなく、その表領域のみを復旧させることが可能です。本記事では、RMAN(Recovery Manager)を活用し、特定の表領域やデータファイルに障害が発生した際のリカバリ手順を解説します。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか?
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか?
1. 障害の特定と現状確認
障害が発生した際、まずはどの表領域に問題があるかを特定します。
表領域およびデータファイルの状態確認
以下のSQLを実行し、表領域およびデータファイルのステータスを確認してください。
-- 表領域のステータス確認
SELECT tablespace_name, status FROM dba_tablespaces;
-- データファイルのステータス確認(例:USERS表領域)
SELECT name, status FROM v$datafile WHERE tablespace_name = 'USERS';
ステータスが RECOVER や異常な値になっている場合、リカバリ操作が必要です。また、RMANで以下のように検証を行うことで、破損ブロックの有無を確実に特定できます。
RMAN> VALIDATE DATABASE;
2. 表領域のリカバリ手順(オンライン復旧)
表領域が破損している場合、対象の表領域をオフラインにしてからリストアとリカバリを行います。これにより、他の表領域を利用するサービスを停止せずに復旧可能です。
手順ステップ
- 表領域のオフライン化:
ALTER TABLESPACE <表領域名> OFFLINE; - リストア:
RESTORE TABLESPACE <表領域名>; - リカバリ:
RECOVER TABLESPACE <表領域名>; - オンライン化:
ALTER TABLESPACE <表領域名> ONLINE;
実行例(USERS表領域のリカバリ)
RMAN実行中にエラーが発生した場合は、先にSQLで表領域をオフラインにしてからリストアしてください。
# 1. USERS表領域をオフラインに変更
ALTER TABLESPACE USERS OFFLINE;
# 2. リストアを実行
RMAN> RESTORE TABLESPACE USERS;
# 3. リカバリを実行
RMAN> RECOVER TABLESPACE USERS;
# 4. オンラインに戻して復旧完了
ALTER TABLESPACE USERS ONLINE;
RMAN> select status from v$instance;
リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています
STATUS
------------
OPEN
RMAN> validate database;
validateを25-03-17で開始しています
チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: SID=74 デバイス・タイプ=DISK
チャネルORA_DISK_1: データファイルの検証を開始しています
チャネルORA_DISK_1: 検証のためのデータファイルを指定しています
入力データファイル ファイル番号=00001 名前=/u01/app/oracle/oradata/V19/system01.dbf
入力データファイル ファイル番号=00003 名前=/u01/app/oracle/oradata/V19/sysaux01.dbf
入力データファイル ファイル番号=00004 名前=/u01/app/oracle/oradata/V19/undotbs01.dbf
入力データファイル ファイル番号=00007 名前=/u01/app/oracle/oradata/V19/users01.dbf
チャネルORA_DISK_1: 検証が完了しました。経過時間: 00:00:07
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1 OK 0 18147 149764 2274304
ファイル名: /u01/app/oracle/oradata/V19/system01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 81289
Index 0 13395
Other 0 36929
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
3 OK 0 23966 93450 2274265
ファイル名: /u01/app/oracle/oradata/V19/sysaux01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 6626
Index 0 2677
Other 0 60171
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
4 OK 0 658 92800 2274304
ファイル名: /u01/app/oracle/oradata/V19/undotbs01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 0
Index 0 0
Other 0 92142
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
7 FAILED 0 725 9121 2274262
ファイル名: /u01/app/oracle/oradata/V19/users01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 7996
Index 0 15
Other 1 384
検証により1つ以上の破損したブロックが見つかりました
詳細はトレース・ファイル/u01/app/oracle/diag/rdbms/v19/v19/trace/v19_ora_3136.trcを参照してください
チャネルORA_DISK_1: データファイルの検証を開始しています
チャネルORA_DISK_1: 検証のためのデータファイルを指定しています
現行の制御ファイルを検証に組み込んでいます
バックアップ・セットに現行のSPFILEを組み込んでいます
チャネルORA_DISK_1: 検証が完了しました。経過時間: 00:00:01
List of Control File and SPFILE
===============================
File Type Status Blocks Failing Blocks Examined
------------ ------ -------------- ---------------
SPFILE OK 0 2
Control File OK 0 646
validateを25-03-17で終了しました
RMAN> restore tablespace users; ★エラーが発生
restoreを25-03-17で開始しています
チャネルORA_DISK_1の使用
チャネルORA_DISK_1: データファイル・バックアップ・セットのリストアを開始しています
チャネルORA_DISK_1: バックアップ・セットからリストアするデータファイルを指定しています
チャネルORA_DISK_1: データファイル00007を/u01/app/oracle/oradata/V19/users01.dbfにリストアしています
チャネルORA_DISK_1: バックアップ・ピース/u01/app/oracle/product/19.0.0/dbhome_1/dbs/013kjnp8_1_1_1から読取り中です
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: restoreコマンドが03/17/2025 20:54:37で失敗しました
ORA-19870: バックアップ・ピース/u01/app/oracle/product/19.0.0/dbhome_1/dbs/013kjnp8_1_1_1のリストア中にエラーが発生しました
ORA-19573: exclusiveエンキュー(データファイル7)を取得できません。
ORA-19890: データ・ファイルはすでに使用されています
RMAN> alter tablespace users offline; ★USERS表領域をOFFLINEに変更
文が処理されました
RMAN> SELECT tablespace_name, status FROM dba_tablespaces;
TABLESPACE_NAME STATUS
------------------------------ ---------
SYSTEM ONLINE
SYSAUX ONLINE
UNDOTBS1 ONLINE
TEMP ONLINE
USERS OFFLINE ★
RMAN> restore tablespace users; ★リストア
restoreを25-03-17で開始しています
チャネルORA_DISK_1の使用
チャネルORA_DISK_1: データファイル・バックアップ・セットのリストアを開始しています
チャネルORA_DISK_1: バックアップ・セットからリストアするデータファイルを指定しています
チャネルORA_DISK_1: データファイル00007を/u01/app/oracle/oradata/V19/users01.dbfにリストアしています
チャネルORA_DISK_1: バックアップ・ピース/u01/app/oracle/product/19.0.0/dbhome_1/dbs/013kjnp8_1_1_1から読取り中です
チャネルORA_DISK_1: ピース・ハンドル=/u01/app/oracle/product/19.0.0/dbhome_1/dbs/013kjnp8_1_1_1 タグ=TAG20250317T204632
チャネルORA_DISK_1: バックアップ・ピース1がリストアされました
チャネルORA_DISK_1: リストアが完了しました。経過時間: 00:00:01
restoreを25-03-17で終了しました
RMAN> recover tablespace users; ★リカバリ
recoverを25-03-17で開始しています
チャネルORA_DISK_1の使用
メディア・リカバリを開始しています
メディア・リカバリが完了しました。経過時間: 00:00:03
recoverを25-03-17で終了しました
RMAN> alter tablespace users online; ★ONLINEに変更
文が処理されました
RMAN> SELECT tablespace_name, status FROM dba_tablespaces;
TABLESPACE_NAME STATUS
------------------------------ ---------
SYSTEM ONLINE
SYSAUX ONLINE
UNDOTBS1 ONLINE
TEMP ONLINE
USERS ONLINE ★
3. データファイル単位の復旧
特定のデータファイルが破損している場合は、データファイル単位での復旧も可能です。
# データファイル単位でのリストア・リカバリ
RMAN> RESTORE DATAFILE '/u01/oradata/ORCL/users01.dbf';
RMAN> RECOVER DATAFILE '/u01/oradata/ORCL/users01.dbf';
# オンラインに戻す
ALTER DATABASE DATAFILE '/u01/oradata/ORCL/users01.dbf' ONLINE;
4. 特殊な領域(SYSTEM/UNDO)の障害対応
SYSTEM表領域の破損
データベース起動に直結するため、マウントモードでの復旧が必要です。
RMAN> STARTUP MOUNT;
RMAN> RESTORE TABLESPACE SYSTEM;
RMAN> RECOVER TABLESPACE SYSTEM;
RMAN> ALTER DATABASE OPEN;
UNDO表領域の破損
新しいUNDO表領域を作成して切り替えるのが最も迅速な復旧方法です。
-- 新しいUNDO表領域の作成
CREATE UNDO TABLESPACE UNDO_TBS2 DATAFILE '/u01/oradata/ORCL/undotbs02.dbf' SIZE 500M AUTOEXTEND ON;
-- 切り替え
ALTER SYSTEM SET UNDO_TABLESPACE = UNDO_TBS2;
5. 予防策とベストプラクティス
障害時に慌てないための運用ポイントです。
- 定期バックアップ:
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;を定期実行し、常に最新のバックアップを保持してください。 - 高速リカバリ領域(FRA)の設定: アーカイブログやバックアップの管理を自動化・効率化します。SQL
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 10G; ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/u02/fra'; - ログ監視: アラートログの定期チェックを自動化し、初期段階で障害を検知できるようにしましょう。
6. FAQ
Q1: 表領域のリカバリ中はデータベース全体が停止しますか? A1: いいえ。障害が発生した表領域のみをオフラインにすることで、他の表領域はオンラインのまま運用を継続可能です。
Q2: ORA-19890エラーが発生した場合はどうすべきですか? A2: データファイルが使用中であることを示しています。まず該当の表領域を ALTER TABLESPACE <名称> OFFLINE; でオフラインにしてからリストアを再試行してください。
Q3: SYSTEM表領域が壊れた場合のリカバリ手順は? A3: SYSTEM表領域は必須領域のため、マウントモードで起動し、RMANを使用してRESTOREおよびRECOVERコマンドを実行する必要があります。
7. まとめ
特定の表領域に障害が発生した場合、適切なリカバリ手順を実施することで迅速に復旧できます。
- 表領域単位のリカバリ: オフライン化によりサービス影響を最小化できる。
- RMANの活用: リストアとリカバリを効率的に実行可能。
- 日常の備え: 定期的なバックアップとログ監視が重要。
本記事の手順を参考に、万が一の障害時に備えてリカバリ手順の習熟と検証を行っておくことを強く推奨します。
本記事は Oracle Database 19c を対象に解説します(他バージョンは画面や既定値が異なる場合があります)。
[参考]
Oracle Database バックアップおよびリカバリ・ユーザーズ・ガイド 19c


💰 【PR】Oracleエンジニアの市場価値、調べてみませんか?
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか?


コメント