本番環境と同じデータを持つクローンデータベースは、開発・テスト・検証・パフォーマンスチューニングに欠かせません。Oracle にはクローン作成の方法が複数あり、状況に応じて最適な方式が異なります。
本記事では、RMAN DUPLICATE、Data Pump、PDB Cloneの 3 方式を比較し、クローン後の DB 名変更やリスナー設定までカバーします。
・3 つのクローン方式の比較と選び方
・RMAN DUPLICATE による物理クローンの手順
・Data Pump による論理クローンの手順
・PDB Clone(12c 以降)によるプラガブル DB の複製
・クローン後の DB 名 / SID / リスナーの変更
・クローン後のデータマスキング
3 つのクローン方式の比較
| 方式 | 種類 | 前提条件 | クローンの範囲 | 適するケース |
|---|---|---|---|---|
| RMAN DUPLICATE | 物理クローン | RMAN バックアップ or ネットワーク接続 | DB 全体(データファイル単位) | 本番と完全に同じ構成を再現。大規模 DB に最適 |
| Data Pump | 論理クローン | expdp ダンプファイル | スキーマ / テーブル単位 | 部分的なクローン。異なるスキーマ名で作成可能 |
| PDB Clone | プラガブル DB 複製 | CDB 環境(12c 以降) | PDB 単位 | CDB 内での高速な PDB 複製 |
・本番 DB 全体を完全複製 → RMAN DUPLICATE
・特定スキーマだけ複製 / 別名で作成 → Data Pump
・CDB 環境で PDB を素早く複製 → PDB Clone
RMAN DUPLICATE による物理クローン
RMAN DUPLICATE は本番 DB の物理的な複製を作成します。データファイル・制御ファイル・REDO ログが全てコピーされ、完全に独立した DB が作成されます。
バックアップベースの DUPLICATE
# (1) クローン先で PFILE を作成
# initCLONE.ora の内容:
# db_name=CLONE
# control_files='/oracle/clone/control01.ctl'
# db_file_name_convert=('/oracle/prod/','/oracle/clone/')
# log_file_name_convert=('/oracle/prod/','/oracle/clone/')
# (2) クローン先を NOMOUNT で起動
export ORACLE_SID=CLONE
sqlplus / as sysdba
SQL> STARTUP NOMOUNT PFILE='/oracle/clone/initCLONE.ora';
# (3) RMAN DUPLICATE を実行
rman target sys/password@PRODDB auxiliary /
RMAN> DUPLICATE TARGET DATABASE TO CLONE
FROM ACTIVE DATABASE
DB_FILE_NAME_CONVERT ('/oracle/prod/', '/oracle/clone/')
LOG_FILE_NAME_CONVERT ('/oracle/prod/', '/oracle/clone/')
NOFILENAMECHECK;
# FROM ACTIVE DATABASE: ネットワーク経由で直接コピー(ダンプ不要)
# NOFILENAMECHECK: ファイル名の重複チェックをスキップ
# 本番のバックアップファイルをクローン先にコピー済みの場合
rman auxiliary /
RMAN> DUPLICATE DATABASE TO CLONE
BACKUP LOCATION '/oracle/backup/'
DB_FILE_NAME_CONVERT ('/oracle/prod/', '/oracle/clone/')
LOG_FILE_NAME_CONVERT ('/oracle/prod/', '/oracle/clone/')
NOFILENAMECHECK;
| オプション | 動作 |
|---|---|
| FROM ACTIVE DATABASE | 本番 DB にネットワーク接続して直接コピー(バックアップ不要だが本番に負荷) |
| BACKUP LOCATION | 事前にコピーしたバックアップからクローン(本番に負荷なし) |
| DB_FILE_NAME_CONVERT | データファイルのパスを変換 |
| LOG_FILE_NAME_CONVERT | REDO ログファイルのパスを変換 |
| NOFILENAMECHECK | ファイル名の一意性チェックをスキップ |
ネットワーク経由で全データファイルをコピーするため、本番の I/O とネットワーク帯域を消費します。業務時間外に実行するか、バックアップファイルを事前にコピーする方式を検討してください。
Data Pump による論理クローン
Data Pump は論理レベル(スキーマ / テーブル単位)でクローンを作成します。別名のスキーマとして作成できるため、同一サーバー上に本番と開発を共存させたい場合に便利です。
# (1) 本番からエクスポート
expdp system/password \
directory=DP_DIR \
dumpfile=prod_hr_%U.dmp \
schemas=HR \
parallel=4 \
compression=ALL
# (2) 別スキーマとしてインポート
impdp system/password \
directory=DP_DIR \
dumpfile=prod_hr_%U.dmp \
remap_schema=HR:DEV_HR \
remap_tablespace=USERS:DEV_TS \
table_exists_action=REPLACE \
parallel=4
・スキーマ名 / 表領域を変更してクローン可能
・テーブル単位の部分クローンも可能
・同一 DB インスタンス上に複数のクローンを共存できる
・RMAN DUPLICATE より手順がシンプル
Data Pump の詳細は「Data Pump の使い方完全ガイド」、スキーマ移行は「スキーマ単位にエクスポート・インポート」を参照してください。
PDB Clone(12c 以降: プラガブル DB の複製)
CDB(コンテナデータベース)環境では、PDB(プラガブルデータベース)をSQL 一発でクローンできます。
-- (1) クローン元の PDB を READ ONLY にする
ALTER PLUGGABLE DATABASE pdb_prod READ ONLY;
-- (2) PDB をクローン
CREATE PLUGGABLE DATABASE pdb_dev
FROM pdb_prod
FILE_NAME_CONVERT = ('/oracle/pdb_prod/', '/oracle/pdb_dev/');
-- (3) クローン元を READ WRITE に戻す
ALTER PLUGGABLE DATABASE pdb_prod READ WRITE;
-- (4) クローン先を OPEN
ALTER PLUGGABLE DATABASE pdb_dev OPEN;
-- 12c R2 以降: クローン元を READ WRITE のまま複製可能
-- ※ LOCAL UNDO モードが必要
CREATE PLUGGABLE DATABASE pdb_dev
FROM pdb_prod
FILE_NAME_CONVERT = ('/oracle/pdb_prod/', '/oracle/pdb_dev/');
ALTER PLUGGABLE DATABASE pdb_dev OPEN;
-- DB Link 経由で別サーバーの PDB をクローン
CREATE DATABASE LINK remote_cdb
CONNECT TO system IDENTIFIED BY password
USING '//remote-server:1521/remote_cdb';
CREATE PLUGGABLE DATABASE pdb_dev
FROM pdb_prod@remote_cdb
FILE_NAME_CONVERT = ('/oracle/remote_pdb/', '/oracle/local_pdb/');
ALTER PLUGGABLE DATABASE pdb_dev OPEN;
| PDB Clone の種類 | 要件 | 速度 |
|---|---|---|
| ローカルクローン(同一 CDB) | クローン元を READ ONLY にする | 高速(ファイルコピー) |
| ホットクローン(12c R2+) | LOCAL UNDO モード | 高速(READ ONLY 不要) |
| リモートクローン | DB Link + CDB 間のネットワーク | 中(ネットワーク依存) |
| スナップショットクローン(12c R2+) | ACFS / ASM スナップショット | 最速(秒単位、Copy-on-Write) |
SQL 一発で PDB を複製でき、RMAN や Data Pump の複雑な手順が不要です。12c R2 以降のホットクローンなら本番 PDB を停止する必要もありません。
クローン後のカスタマイズ
DB 名の変更(NID ユーティリティ)
# RMAN DUPLICATE でクローンすると元の DBID が引き継がれる # 同一サーバーで RMAN カタログを使う場合は DBID の重複を避ける # (1) DB を MOUNT モードで起動 sqlplus / as sysdba SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; # (2) NID で DB 名と DBID を変更 nid TARGET=/ DBNAME=CLONEDB # (3) PFILE の db_name を変更 # db_name=CLONEDB # (4) DB を RESETLOGS で OPEN sqlplus / as sysdba SQL> STARTUP MOUNT; SQL> ALTER DATABASE OPEN RESETLOGS;
リスナーの設定
# listener.ora にクローン DB のエントリを追加 # SID_LIST_LISTENER = # (SID_LIST = # (SID_DESC = # (SID_NAME = CLONEDB) # (ORACLE_HOME = /oracle/product/19c/dbhome_1) # ) # ) # リスナー再起動 lsnrctl stop lsnrctl start # tnsnames.ora にクローン DB のエントリを追加 # CLONEDB = # (DESCRIPTION = # (ADDRESS = (PROTOCOL = TCP)(HOST = clone-server)(PORT = 1521)) # (CONNECT_DATA = (SID = CLONEDB)) # )
データマスキング
-- クローン後にテストに不要な個人情報をマスキング
UPDATE employees SET
email = 'user' || employee_id || '@test.example.com',
phone_number = '000-0000-' || LPAD(employee_id, 4, '0');
UPDATE customers SET
credit_card = 'XXXX-XXXX-XXXX-' || SUBSTR(credit_card, -4);
COMMIT;
-- 統計情報の更新
EXEC DBMS_STATS.GATHER_SCHEMA_STATS(USER);
本番データをそのまま開発環境に持ち込むと個人情報保護法や GDPR に抵触する可能性があります。クローン後にメールアドレス・電話番号・クレジットカード番号等をマスキングしてください。
実務パターン集
パターン(1): RMAN で本番 DB を完全クローン
# 本番からアクティブ DUPLICATE(夜間に実行)
rman target sys/password@PRODDB auxiliary sys/password@CLONEDB
RMAN> DUPLICATE TARGET DATABASE TO CLONEDB
FROM ACTIVE DATABASE
DB_FILE_NAME_CONVERT ('/oracle/prod/', '/oracle/clone/')
LOG_FILE_NAME_CONVERT ('/oracle/prod/', '/oracle/clone/')
NOFILENAMECHECK;
# クローン後にマスキング + 統計収集
パターン(2): Data Pump で特定スキーマだけクローン
# 本番の HR スキーマを DEV_HR としてクローン
expdp system/password schemas=HR dumpfile=hr_%U.dmp \
directory=DP_DIR parallel=4 compression=ALL
impdp system/password dumpfile=hr_%U.dmp \
remap_schema=HR:DEV_HR remap_tablespace=USERS:DEV_TS \
directory=DP_DIR parallel=4
パターン(3): PDB Clone で開発用 PDB を即座に作成
-- ホットクローン(12c R2 以降: 本番 PDB 稼働中に複製)
CREATE PLUGGABLE DATABASE pdb_dev
FROM pdb_prod
FILE_NAME_CONVERT = ('/oracle/pdb_prod/', '/oracle/pdb_dev/');
ALTER PLUGGABLE DATABASE pdb_dev OPEN;
-- pdb_dev 内でマスキング
ALTER SESSION SET CONTAINER = pdb_dev;
UPDATE hr.employees SET email = 'test' || employee_id || '@dev.com';
COMMIT;
パターン(4): 定期クローンの自動化(Shell スクリプト)
#!/bin/bash
# 毎週日曜に本番スキーマをクローン
set -e
export ORACLE_HOME=/oracle/product/19c/dbhome_1
export ORACLE_SID=DEVDB
# (1) 既存のクローンスキーマを削除
sqlplus system/password <<EOF
DROP USER dev_hr CASCADE;
EOF
# (2) Data Pump でクローン
impdp system/password \
directory=DP_DIR \
dumpfile=prod_hr_latest_%U.dmp \
remap_schema=HR:DEV_HR \
remap_tablespace=USERS:DEV_TS
# (3) マスキング
sqlplus dev_hr/password <<EOF
UPDATE employees SET email = 'user' || employee_id || '@test.com';
COMMIT;
EXEC DBMS_STATS.GATHER_SCHEMA_STATS(USER);
EOF
echo "[$(date)] クローン完了"
クローン後のチェックリスト
| # | 確認項目 |
|---|---|
| 1 | DB が正常に OPEN していることを確認 |
| 2 | テーブル行数が本番と一致することを確認 |
| 3 | INVALID オブジェクトの再コンパイル(utlrp.sql) |
| 4 | データマスキングの実施(個人情報の保護) |
| 5 | 統計情報の更新(DBMS_STATS.GATHER_SCHEMA_STATS) |
| 6 | リスナー / tnsnames.ora の設定 |
| 7 | DB Link がある場合は接続先を開発用に変更 |
| 8 | バッチジョブ(DBMS_SCHEDULER)の無効化(本番ジョブの誤実行防止) |
本番 DB からクローンすると、DBMS_SCHEDULER や DBMS_JOB に登録されたジョブもコピーされます。クローン DB でメール通知やデータ更新のジョブが動くと本番に影響する可能性があります。クローン後に全ジョブを無効化してください。
-- DBMS_SCHEDULER ジョブを全て無効化
BEGIN
FOR rec IN (
SELECT owner, job_name FROM dba_scheduler_jobs
WHERE enabled = 'TRUE'
AND owner NOT IN ('SYS', 'SYSTEM')
) LOOP
DBMS_SCHEDULER.DISABLE(rec.owner || '.' || rec.job_name);
END LOOP;
END;
/
よくある質問
まとめ
クローンデータベースの作成方法をまとめます。
| やりたいこと | 推奨方式 |
|---|---|
| 本番 DB 全体を完全複製 | RMAN DUPLICATE(FROM ACTIVE DATABASE / BACKUP LOCATION) |
| 特定スキーマだけ別名でクローン | Data Pump(expdp → impdp remap_schema=A:B) |
| CDB 環境で PDB を素早く複製 | CREATE PLUGGABLE DATABASE … FROM … |
| 本番に負荷をかけずにクローン | RMAN BACKUP LOCATION(事前にバックアップをコピー) |
| 同一インスタンス内にクローン | Data Pump remap_schema(別スキーマとして作成) |
| クローン後の DB 名変更 | NID TARGET=/ DBNAME=新名 |
| クローン後のデータマスキング | UPDATE で個人情報を匿名化 |
別サーバーへの移行は「別サーバーへデータベースを移行する方法」、Data Pump の基本は「Data Pump の使い方完全ガイド」も併せて参照してください。

