※本ページは、”Exascale Snapshots and Clones: Core Concepts“の翻訳です。

最初の投稿では、なぜデータベースのクローン作成を再考する必要があったのかを見てきました。

エンタープライズチームは、これまで以上に頻繁に現実的なデータベース環境を必要としていますが、従来のフルコピー方式は時間がかかり、ストレージを大量に消費し、運用も複雑になりがちです。Exadata Exascaleは、スナップショットとシンクローンをストレージアーキテクチャの一部とし、それらをOracle Databaseの操作やユーティリティと統合することで、このモデルを変革します。

この記事では、そのモデルの背後にある基本概念について説明します。コマンドに焦点を当てるのではなく（これについては次回の記事で取り上げます）、Exascaleのスナップショットとクローンを支える概念を説明します。

「単にコピーを作成する」ことの問題点

データベースのコピーは、ソースデータベースが大規模で、稼働中で、ミッションクリティカルになるまでは簡単に聞こえます。

新しい開発環境やテスト環境を作成するたびに完全な物理複製が必要になる場合、チームはストレージ、データ移動、プロビジョニング時間、検証、ライフサイクル管理といったコストを最初に負担することになります。たまにコピーを作成する程度であれば許容できるかもしれません。しかし、多くのチームが同じソースから複数のコピーを必要とするようになると、問題になります。

主な非効率性は、多くのコピーが初日から完全な物理複製である必要はないという点です。

QAチームはデータの一部だけを変更するかもしれません。開発者は少数のスキーマや表だけを変更するかもしれません。トラブルシューティング用のクローンは短期間だけ存在し、その後破棄されるかもしれません。そのような場合、チームが作業を開始する前にすべてのブロックの完全な物理複製を作成することは、コストと遅延を増やします。

Exascaleのスナップショットとクローンは、論理コピーと変更データの物理的な複製を分離することで、この非効率性に対処します。

では、Exascaleのスナップショットとクローンの基本概念をいくつか見ていきましょう。

ポイント・イン・タイム・コピー

最初の概念は、ポイント・イン・タイム・コピーです。

ポイント・イン・タイム・コピーは、特定の時点におけるソースのビューを提供します。これは重要です。なぜなら、データベースは静的ではないからです。データは常に変化しています。ユーザーは行を挿入し、アプリケーションはレコードを更新し、バッチジョブが実行され、索引が保守され、メンテナンスタスクが行われます。

スナップショットやクローンを作成する場合、安定したベースラインが必要です。

時刻T1のソース
↓
T1に基づくポイント・イン・タイム・コピー

コピーは、その時点におけるソースの状態から開始されます。その後に何が起こるかは、そのコピーがスナップショットなのかクローンなのかによって異なります。

スナップショットとクローン

スナップショットは、読取り専用のポイント・イン・タイム・コピーです。コピーに変更を許可せず、特定の状態を保持または確認したい場合に役立ちます。安定した参照ポイントと考えることができます。読取り専用であるため、実験よりも一貫性や保存が重視されるワークフローで有用です。重要なのは、スナップショットは直接使用されないという点です。スナップショットが表すポイント・イン・タイムのデータにアクセスするには、そのスナップショットに基づいてクローンを作成する必要があります。

クローンは、読取りおよび書込みが可能なポイント・イン・タイム・コピーです。

クローンは、ソースのポイント・イン・タイム・スナップショットから開始されますが、作成後は独立して変更できます。そのため、開発、テスト、トラブルシューティング、検証に有用です。チームはソースを変更することなく、クローンを変更できます。クローン作成時にスナップショットが指定されていない場合、クローンは暗黙的にスナップショットを作成します。

例:

alter pluggable database pdb_clone from pdb1 snapshot copy;

SNAPSHOT COPY句は、pdb1のシンクローンを作成し、pdb1のデータファイルのスナップショットを暗黙的に作成します。

Exadata Exascaleのスナップショットとクローンの関係を示す図。最上部にある読取り/書込み可能なソースデータベースは、2つの読取り専用スナップショットを作成します。1つは午前10時、もう1つは午後2時です。午前10時のスナップショットは、Dev Clone、Test Clone、Analytics Cloneという3つの独立した読取り/書込み可能なクローンの親です。その後、Test Cloneは自身の読取り専用スナップショットを午前9時に作成するために使用され、そのスナップショットから読取り/書込み可能なRegression Cloneが作成されます。これは、クローンも追加のスナップショットやクローンのソースとして機能できることを示しています。午後2時のスナップショットは、別の読取り/書込み可能なReporting Cloneの親です。緑色のボックスは読取り専用スナップショット、青色のボックスは読取り/書込み可能なデータベースおよびクローンを表し、接続矢印は親子関係を示します。

実用上の違いは単純です。

概念読取り可能 書込み可能一般的な用途
スナップショット 間接的に可能不可ある時点を保持または参照
クローンはいはい独立した作業コピーを作成

開発およびテストのワークフローでは、チームが書込み可能な環境を必要とするため、通常はクローンのほうが目に見える機能になります。それでもスナップショットは重要です。スナップショットは、反復可能なリフレッシュ、スナップショット・カルーセル、クローン作成ワークフローに役立つ安定したポイント・イン・タイムを提供できるからです。

デフォルトの動作で作成されるスナップショットとCONSISTENTを使用したスナップショット

スナップショットには、作成時の重要な選択肢もあります。デフォルトの動作で作成されるスナップショットはポイント・イン・タイムを迅速に取得します。一方、CONSISTENTキーワードを指定して作成されるスナップショットは、スナップショット作成中にREDOを適用します。デフォルトの方法では、スナップショットの作成を可能な限り高速にします。CONSISTENTキーワードを使用すると、データベース・リカバリ作業をスナップショット作成時に移動することになり、後でクローンを作成する際に必要な作業が減り、長期保持により適したスナップショットになります。

違いは、データベース・リカバリ作業がいつ実行されるかです。

デフォルトでは、Exascaleスナップショットは非常に高速に作成されます。スナップショットはポイント・イン・タイムのファイル関係を即座に取得しますが、そのスナップショットからクローンを作成する際に、後でデータベースファイルへREDOを適用する必要がある場合があります。これは、最小限の遅延でポイント・イン・タイムを取得することが優先される場合に有用ですが、クローン作成時に一貫性を確保できるようにREDOを保持しておく必要があります。

例:

alter pluggable database pdb1 snapshot;

スナップショット作成時にCONSISTENT句を使用すると、REDOはスナップショット作成時に適用されます。必要なリカバリ処理が前もって実行されるため、スナップショットの作成にはより長い時間がかかります。その代わり、そのスナップショットから後で作成されるクローンは、クローン作成時に同じREDO適用処理を実行する必要がありません。REDOがスナップショット作成時に適用されるため、将来のクローンは元のREDOを保持する必要なく作成できます。そのため、CONSISTENT句付きのスナップショットは長期保持により適しています。

例: alter pluggable database pdb1 snapshot consistent;

実用上の選択は次のとおりです。

スナップショットの選択作成時の動作クローン作成時の動作最適な用途
snapshot句のデフォルト動作非常に高速に作成クローン作成時にREDOの適用が必要になる場合がある ポイント・イン・タイムを迅速に取得
snapshot consistent句の動作スナップショット作成時にREDOが適用され、クローン作成時の作業を回避非常に高速に作成すぐにクローン作成できるベースラインを準備

重要なのは、CONSISTENT句はスナップショットの論理的な目的を変えるものではないという点です。REDOが適用されるタイミングを変えるものです。

優先事項が高速なポイント・イン・タイム取得である場合は、デフォルトの動作のsnapshot句を使用します。スナップショットをすぐにクローン作成できるベースラインとして準備し、REDO処理を前もって実行するほうがよい場合は、CONSISTENT句付きのsnapshotを使用します。

シン・プロビジョニング

従来のフルコピーでは、ターゲット環境はソースデータの完全なコピーに必要なストレージを消費するところから始まります。ソースが大きければ、コピーも最初から大きくなります。

シンコピーでは、ターゲットがすべてのソースデータをただちに複製する必要はありません。共有されたソースデータから開始し、変更が発生した場合にのみ追加のストレージを割り当てます。

シン・プロビジョニングは、クローンがストレージをまったく使用しないという意味ではありません。不要な事前のデータ複製を回避するという意味です。変更されたデータは引き続きストレージを消費します。多くの変更が行われるクローンは、時間の経過とともにより多くのストレージを消費する可能性があります。変更が非常に少ないクローンは、高い容量効率を維持します。

リダイレクト・オン・ライト

容量効率を維持するために、Exascaleはリダイレクト・オン・ライト技術を使用します。大まかに言うと、リダイレクト・オン・ライトとは、データが変更されたときに、別のスナップショットやクローンなど、他のポイント・イン・タイム・ビューで必要とされるデータを上書きするのではなく、新しいバージョンを別の場所に書き込むことを意味します。これにより、不要な複製を回避しながら、各ビューの独立性を維持できます。

重要なのは、ブロック操作の内部メカニズムのすべてではなく、その動作です。

  • クローンは既知のポイント・イン・タイムから開始
  • クローンへの書込みはソースを変更しない
  • ソースへの書込みは既存のクローンを変更しない
  • 変更データが蓄積するにつれてストレージ消費量が増加
  • スナップショットとクローンは、時間の経過とともに独立したビューを保持

Exascaleがデータベースとネイティブに統合されていることが重要な理由

多くのプラットフォームがスナップショットとクローニング機能を提供しています。Exadataのお客様にとって重要な違いは、Exascaleがそれらの機能をプラットフォームおよびOracle Databaseのワークフローに直接統合している点です。

ExascaleのスナップショットとクローンはExadataアーキテクチャの一部であり、Oracle Databaseから直接使用されます。

この統合により、ストレージレベルのプロセスを組み合わせて、データベース環境のように動作するものを作り上げる必要がなくなります。データベースコピーは単なるファイルの集合ではありません。そこには、アイデンティティ、メタデータ、状態、サービス、アプリケーション接続、セキュリティ制御、運用およびパフォーマンス要件があります。

ネイティブ統合により、シンクローニングはより利用しやすくなります。

領域ネイティブな統合が重要な理由
データベース・ワークフロー サポートされている場合、DBAは使い慣れたOracle Database操作を使用可能
ストレージ効率Exascaleが容量効率の高いファイル管理を処理
運用の一貫性 クローンが単発のストレージ成果物になるのではなく、プラットフォームのワークフローに適合
パフォーマンスの現実性シンクローンは、Exadata上で実行され、Exadataの全能力を活用できる実際のデータベース環境
ライフサイクル管理スナップショットとクローンを管理対象リソースとして一覧表示、監視、クリーンアップ可能

これは、「いくつかのファイルをコピーした」ということと、「使用可能なデータベース環境をプロビジョニングした」ということの違いです。

簡単な例

従来のモデルでは、APP_TEST1を作成するにはAPP_PRODの完全な物理コピーが必要になり、ただちに大量のストレージを消費する可能性があります。

Exascaleのシンクローンモデルでは、APP_TEST1はAPP_PRODの書込み可能なポイント・イン・タイム・コピーとして開始されます。テストチームが変更を加えると、Exascaleはクローンに必要な追加データのみを格納します。

T1時点のAPP_PROD
↓
APP_TEST1シンクローン

APP_TEST1のビュー = T1時点のAPP_PROD + APP_TEST1の変更

T1時点以降もAPP_PRODは変更され続けますが、APP_TEST1が自動的に更新されることはありません。APP_TEST1は自身のポイント・イン・タイム・ベースラインに固定されたままになります。

この安定したベースラインはテストに有用です。テストチームは、どのバージョンのデータから開始したのかを把握できます。より新しいバージョンが必要な場合、DBAはより新しいポイント・イン・タイムから新しいクローンを作成できます。

お客様にとっての意味は？

すべてのコピー要求を大規模なプロビジョニング作業として扱う代わりに、開発チーム、DBAチーム、運用チームは再利用可能なパターンとして考えることができます。

  • ポイント・イン・タイム・コピーを作成
  • 定義された開発、テスト、または検証目的に使用
  • どれだけ変更されたかを監視
  • 作業が完了したら削除

クローンの作成と管理を簡素化することで、チームは現実的なデータベース環境をより速く、より少ない手作業でプロビジョニング可能になります。

開発チームは環境をより早く入手できます。QAチームはより現実的なデータに対してテストできます。DBAは反復的なコピー作業を削減できます。プラットフォームチームは、よりスケーラブルなデータベースコピーサービスを提供できます。

ExadataとExascaleは、チームが現実的なデータベース環境を作成できる速度と、それに必要な作業量を変えます。

この記事を締めくくる前に、いくつかの重要なポイントを振り返りましょう。

スナップショットとクローンは関連していますが、同じものではありません

スナップショットは読取り専用です。クローンは書込み可能です。クローンはスナップショットから作成できます。クローン作成時にスナップショットが使用されない場合、スナップショットは暗黙的に作成されます。

スナップショットはワークフロー内の異なる時点を最適化します

スナップショットは高速作成に最適化されています。一貫性のあるスナップショットは、スナップショット作成時にREDO処理を実行するため、REDOを継続的に保持しなくても、後でクローンを作成するための長期保持が可能になります。

シン・プロビジョニングは、すべてのストレージ使用量ではなく、事前の複製を削減します

変更されたデータは引き続きストレージを消費します。シンクローンは、変更データがソース全体よりも小さい場合に最も効率的です。

クローンはおもちゃの環境ではありません

シンクローンはExadata上で実行される実際のデータベースです。Exadataのすべてのパフォーマンス、可用性、セキュリティ、管理性の最適化と機能を使用し、お客様がExadataへの投資からさらに大きな価値を得られるようにします。

まとめ

Exascaleのスナップショットとクローンは単純な概念ですが、運用上は重要な意味を持ちます。

スナップショットは読取り専用のポイント・イン・タイム・ビューを提供します。クローンは読取りおよび書込みが可能なポイント・イン・タイム・コピーを提供します。スナップショット作成オプションにより、DBAは一貫性確保のためにREDOをいつ適用するかを選択できます。シン・プロビジョニングは、作成時に不要な完全複製を回避することでストレージモデルを変えます。リダイレクト・オン・ライトにより、ソースとクローンのタイムラインは分岐しながらも、各環境に対して正しいビューを保持できます。

これらの機能を組み合わせることで、データベースコピーの作成はより高速で、容量効率が高く、運用しやすくなります。

次回の記事では、PDBを使用したExascaleスナップショットとクローンの最初の具体的な利用方法を見ていきます。スナップショットとクローンを作成し、クローンまたはスナップショットのソースを削除しても下流のPDBに影響しないことを確認します。

  • Exadata Exascale ― なぜデータベースのクローン作成を再考する必要があったのか
  • Exascaleスナップショットとクローン：基本概念（この記事）
  • PDBシンクローン：開発およびテスト向けの高速コピー
  • PDBスナップショット・カルーセル
  • CDB間のクローニング
  • gDBCloneによるフルCDBのクローニング
  • スタンバイ・データベースをクローンソースとして使用する
  • Exascaleクローニングのベストプラクティスとリファレンス・アーキテクチャ