※本ページは、”Exadata Exascale PDB Thin Clones“の翻訳です。

月曜の朝になると、依頼が届き始める。

ある開発者は新機能テスト用のデータベースを必要としている。別の開発者は、本番相当のデータ量でしか再現しない本番障害を調査している。QAテスト担当者は回帰テスト用のクリーンな環境を求めており、CI/CDパイプラインでは次の自動テストの実行が始まろうとしている。

それぞれが自分専用のデータベースのテスト用のコピーを必要としている。
こうしたテスト用のデータベースを作成するのは、始まりにすぎない。真の課題は、それらを素早く作成し、一貫性を保ち、更新・バックアップ・管理が必要な完全コピーの数が増え続けるのを避けることだ。

まさにその問題を解決するために設計されているのが、Exadata Exascale PDB thin cloneである。

この記事では、このシリーズの付属ラボを使った典型的な開発ワークフローをたどる。すべてのコマンドやオプションを網羅するのではなく、その途中で行う判断に焦点を当て、Exadata Exascaleがそれらをどのように簡素化するかを示す。

信頼できるデータソースから始める

開発用データベースが増え始める前に、ひとつの問いが重要になる。

どこから始めるべきか？

もし各開発者が少しずつ異なるデータベースから始めれば、問題の再現は難しくなり、テスト結果の比較も推測に頼ることになる。全員が同じ基準点から始める必要がある。

ここでは、運用環境がすでに開発環境へリフレッシュされ、機密データはセキュリティ要件およびプライバシー要件を満たすためにマスキングされている。リフレッシュされたPDBである SALES_MAIN PDB が、この開発サイクルにおける信頼できるソースだ。

誰も SALES_MAIN PDBには直接は接続しない。

それは、あらゆる開発・テスト環境のための、既知の正しい開始点としてのみ存在している。

［図1：本番 → リフレッシュとマスキング → SALES_MAIN］

付属ラボではまず環境を検証し、SALES_MAIN が利用可能であることを確認する。

信頼できる開始点が確立されたら、次の問いは、どうすれば全員に同じコピーを提供できるかだ。

開始点を取得する

ある開発者には今すぐデータベースが割り当てられ、次の開発者には30分後にプロビジョニングされる。問題は単純だ。両者は同じベースラインを必要としている。

すでに変更が加えられていれば、環境はもはや同じ開始点を共有していない。この課題に対処するには、誰も作業を始める前のある時点を先に取得し、すべてのクローンがそのベースラインを持てるようにする。

この手順では、開発環境が短命で再作成も容易であるため、通常のスナップショットを使用する。

ALTER PLUGGABLE DATABASE SNAPSHOT SALES_WEEKLY_SNAP;

スナップショットをより長く保持したり、クローン元として繰り返し再利用したりする場合は、CONSISTENT 句を追加する。ワークフロー自体は変わらない。

ALTER PLUGGABLE DATABASE SNAPSHOT SALES_WEEKLY_SNAP CONSISTENT;

通常のスナップショットは、その時点をすぐに取得する。CONSISTENT 句付きのスナップショットは、作成中に必要な redo を適用するため、長期間保持したり再利用したりするスナップショットにより適している。

［図2：SALES_MAIN → SALES_WEEKLY_SNAP］

開発チームにとっては何も変わっていない。開発用データベースは依然として1つだけだ。だが今では、すべての新しい環境が共有できる安定した時点が存在する。

ここから、個別のコピー要求に対応し始められる。

リクエストが届き始める

スナップショットの準備ができ、データベースコピーの依頼が届き始めている。

Alex は新機能用のデータベースを必要としている。Sarah は本番障害を調査している。QA 担当者はクリーンな回帰テスト環境を必要としており、CI/CD パイプラインは次の自動テスト実行を待っている。

少し前なら、これは4つの個別のデータベースコピーを意味していた。

Exadata Exascale では、SALES_MAIN の thin clone を4つプロビジョニングし、それぞれが SALES_WEEKLY_SNAP を時点ソースとして使用する。

CREATE PLUGGABLE DATABASE DEV_ALEX
    FROM SALES_MAIN
    USING SNAPSHOT SALES_WEEKLY_SNAP
    SNAPSHOT COPY;

同じコマンドを DEV_SARAH、QA、CI_PIPELINE のそれぞれのPDBに対して繰り返す。変更するのは PDB 名だけだ。

CON_ID  NAME          OPEN_MODE
------  ------------  ----------
5       DEV_ALEX      READ WRITE
6       DEV_SARAH     READ WRITE
7       QA            READ WRITE
8       CI_PIPELINE   READ WRITE

［図3：SALES_WEEKLY_SNAP から4つの thin clone をプロビジョニング］

開発者から見れば、これらは単なる Oracle データベースだ。通常の PDB と同じように接続し、オブジェクトを作成し、データをロードし、テストを実行できる。

その裏側では、Exadata Exascale は4つの完全コピーではなく、独立した thin clone をプロビジョニングしている。作成直後は実質的に追加ストレージを消費せず、各チームが変更を加えるにつれて、変更されたデータだけが追加の容量を消費する。

適切な開始点を選択する

複数の環境で同じ時点のデータベースが必要だったため、この手順では名前付きスナップショットを使用した。共通のベースラインが重要な場合には、これが適切なソースとなる。

これは一般的な選択肢だが、唯一のワークフローではない。

単一の環境であれば、その開始点としたい PDB から直接 thin clone を作成できる。

たとえば、SALES_MAIN から直接 thin clone を作成することもできる。

CREATE PLUGGABLE DATABASE DEV_SANDBOX
    FROM SALES_MAIN
    SNAPSHOT COPY;

あるいは数日後、Alex が追加のスキーマやアプリケーションソフトウェア、テストデータを構成したタイミングで、2人目の開発者がプロジェクトに参加したとする。

その場合は、同じ作業を繰り返す代わりに、DEV_ALEX を開始点として新しい thin clone を作成すればよい。

CREATE PLUGGABLE DATABASE DEV_BOB
    FROM DEV_ALEX
    SNAPSHOT COPY;

［図4：SALES_MAIN → SALES_WEEKLY_SNAP → DEV_ALEX → DEV_BOB］

どちらの場合もワークフローは同じだ。違うのはソースPDBだけである。

ソースが決まれば、次の運用上の問いは、クローンが本当に分離されているのかどうかだ。

本当に動くのか？

複数のクローンが同じ開始点を共有したあと、運用上の問題は、あるクローンへの変更が他のクローンに影響するかどうかである。

最も手早い答えは、実際に試してみることだ。

付属ラボでは、結果を問い合わせる前に、それぞれのクローンに固有のマーカー行を挿入する。

Results from DEV_SARAH

CLONE_NAME   MARKER_TEXT               CREATED_AT
-----------  ------------------------  --------------------------
DEV_SARAH    Sarah clone local change  12-JUL-26 06.21.12 PM


Results from DEV_ALEX

CLONE_NAME   MARKER_TEXT              CREATED_AT
-----------  -----------------------  --------------------------
DEV_ALEX     Alex clone local change  12-JUL-26 06.20.50 PM

各クローンは、自分自身のマーカー行だけを見る。どちらも同じスナップショットから始まったが、変更は分離されたままだ。

開発者にとっては、それは自分専用の Oracle データベースである。そしてそれこそが、Exadata Exascale が提供するよう設計されている体験だ。

1週間後…

週の終わりまでに、テストデータがロードされ、スキーマは進化し、オブジェクトやデータベースそのものが作成されたり消えたりし、単発の構成変更も積み重なっている。

そのとき、避けられない問いが来る。

「環境をそのままリフレッシュできない？」

Exadata Exascale なら、答えはイエスだ。

すべての変更を元に戻すよりも、同じスナップショットから環境を再作成したほうが速いことが多い。

付属ラボでは、DEV_ALEX を削除し、SALES_WEEKLY_SNAP から再プロビジョニングすることでこれを示している。

このリフレッシュは DEV_ALEX に対してローカルに行われる。DEV_ALEX から作成された下流の thin clone、たとえば DEV_BOB は、先に削除する必要がなく、DEV_ALEX の再作成中も利用可能なままだ。Bob や他の下流ユーザーは、中断なく作業を続けられる。

わずかな時間で、環境はスナップショット作成時とまったく同じ状態に戻る。

多くのチームでは、これが好ましいリフレッシュの運用になる。劣化した環境を修復するよりも、速く、簡単で、予測しやすいからだ。

次は何か？

典型的な開発週の流れは明らかだ。リフレッシュ済みでマスキングされたデータベースから始め、ある時点を取得し、thin clone をプロビジョニングし、適切なソースを選び、分離性を検証し、元のスナップショットから再作成してリフレッシュする。

付属の GitHub リポジトリには、この手順で使用した SQL スクリプトが含まれている。

次回の記事では、Exadata Exascale PDB Snapshot Carousels を取り上げ、継続的にリフレッシュされる開発環境のために、スナップショット作成と保持をどのように自動化するかを見ていく。

  1. Exadata Exascale ― なぜデータベースのクローン作成を再考する必要があったのか
  2. Exascaleスナップショットとクローン：基本概念
  3. Exadata Exascale PDBシンクローン（本記事）
  4. PDBスナップショット・カルーセル
  5. CDB間のクローニング
  6. gDBCloneによるフルCDBのクローニング
  7. スタンバイ・データベースをクローンソースとして使用する
  8. Exascaleクローニングのベストプラクティスとリファレンス・アーキテクチャ