3 シャード・データベースのデプロイ
シャード・データベースのデプロイでは、必要なソフトウェア・コンポーネントのインストール、カタログ、ロール、シャード・データベースの作成、高可用性のためのレプリケーションの構成、およびシャード・データベースのスキーマの作成のための前提条件と手順について説明します。
次の各項で、シャード・データベースのデプロイに必要な概念とタスクについて説明します。
シャード・データベースのデプロイの概要
Oracle Shardingには、シャード・データベースを自動的にデプロイする機能があり、これにはシャードとレプリカの両方が含まれます。
シャード・データベース管理者は、トポロジ(リージョン、シャード・ホスト、レプリケーション・テクノロジ)を定義し、GDSCTLコマンドライン・インタフェースを使用して宣言的に指定することでDEPLOYコマンドを起動します。
始める前に
シャード・データベースには、多種多様な構成とトポロジが使用できる点に注意してください。目的とするシャード・データベースには、多様なOracleソフトウェア・コンポーネント(Oracle Data Guard、Oracle GoldenGate、Oracle Real Application Clusters (Oracle RAC)など)と、各種のシャーディング手法(システム管理シャーディング、コンポジット・シャーディング、ユーザー定義シャーディング)を採用することがあります。
アプリケーションに特有のアーキテクチャとシステム要件に応じて、システムの設計時に複数の選択肢から選択できることもあります。様々なシャーディング手法と障害回復および高可用性のオプションの詳細は、「シャーディング方法」と「シャード・レベルの高可用性」を参照してください。
シャード作成メソッドの選択
シャード構成をデプロイするとき、シャードの追加に使用できる2つの異なるGDSCTLコマンド(ADD SHARDおよびCREATE SHARD)があります。
シャーディング・トポロジの構成を開始する前に、使用するシャード作成メソッドを決定します。これはこの決定が構成ステップの一部に影響するためです。
ADD SHARDメソッドとCREATE SHARDメソッドの違いは、構成手順で必要に応じて説明します。
ADD SHARDメソッド
GDSCTL ADD SHARDコマンドは、Oracle Sharding構成にシャードを追加する場合に使用できます。このコマンドを使用する場合、デプロイメント時にシャードになるOracleデータベースを作成するのはユーザーの役割です。データベースがOracle Sharding構成に含めるための前提条件を満たすかぎり、どのメソッドを使用してデータベースを作成しても構いません。
ADD SHARDメソッドを使用する利点のいくつかを次に示します。
- データベースの作成に使用するプロセスを完全に制御できます。
- データベース・パラメータ、ネーミングおよび記憶域の場所は簡単にカスタマイズできます。
- PDBシャードと非CDBシャードの両方がサポートされます。
- シャード・ホストで構成するOracleソフトウェアが少なくなります。
GDSCTLコマンドを実行する前にシャード・データベースが作成されるため、デプロイメント・プロセスはそれほど複雑ではありません。
CREATE SHARDメソッド
GDSCTL CREATE SHARDコマンドは、Oracle Sharding構成でシャードを作成する場合に使用できます。CREATE SHARDを使用すると、シャード・カタログはOracleリモート・スケジューラ・エージェントを利用して、各シャード・ホスト上でDatabase Configuration Assistant (DBCA)をリモートで実行し、データベースを作成します。このメソッドではPDBがサポートされないため、追加されるシャード・データベースは非CDBである必要があります。
CREATE SHARDメソッドを使用する利点のいくつかを次に示します。
- データベース管理者以外のためのシャード・データベースを作成しやすくなります。
- 現行方式で標準がない場合、新しいデータベースをプロビジョニングする標準的な方法が提供されます。
CREATE SHARDで作成されたデータベースは、データベースに対してSQL文を実行したり、データベース・パラメータを調整しなくても、Oracle Sharding用に自動的に正しく構成されます。- スタンバイ・データベースを自動的に作成できます。
シャード・データベースのデプロイのロードマップ
このロードマップに従って、ホストの設定、必要なソフトウェアのインストールおよびシャード・データベースの構成とデプロイを行います。
大まかなデプロイメント・ステップは次のとおりです。
- コンポーネントを設定します。
- 選択したシャーディング構成およびトポロジに必要になるホストをプロビジョニングおよび構成します(「ホストおよびオペレーティング・システムのプロビジョニングと構成」を参照)。
- 選択したカタログとシャード・ノードにOracle Databaseソフトウェアをインストールします(「Oracle Databaseソフトウェアのインストール」を参照)。
- シャード・ディレクタ・ノードにグローバル・サービス・マネージャ(GSM)ソフトウェアをインストールします(「シャード・ディレクタ・ソフトウェアのインストール」を参照)。
- シャーディング・メタデータとアプリケーション・データの保管に必要なデータベースを作成します。
- シャード・カタログにするデータベースと、障害回復(DR)と高可用性(HA)に必要なレプリカを作成します(「シャード・カタログ・データベースの作成」を参照)。
ADD SHARDメソッドを使用してシャードをデプロイする場合は、DRおよびHAに必要なスタンバイ・データベースが含まれる構成で、シャードになるデータベースを作成します(「シャード・データベースの作成」を参照)。
GDSCTLコマンドライン・ユーティリティから、次のコマンドの一部またはすべてを使用してシャーディング・トポロジを指定します(「シャード・データベース・トポロジの構成」を参照)。CREATE SHARDCATALOGADD GSMSTART GSMADD SHARDSPACEADD SHARDGROUPADD CDBADD SHARDADD CREDENTIALADD FILECREATE SHARDADD INVITEDNODE
DEPLOYを実行して、シャーディング・トポロジ構成をデプロイします(「シャーディング構成のデプロイ」を参照)。- シャード・データベース内のシャードへのアクセスに必要なグローバル・サービスを追加します(「グローバル・データベース・サービスの作成と開始」を参照)。
- 各シャードのステータスを確認します(「シャード・ステータスの確認」)。
シャード・データベース構成のデプロイが正常に完了すると、アプリケーションに必要なシャード・スキーマ・オブジェクトを作成できます。シャード・データベースのスキーマ・オブジェクトを参照してください。
次のトピックでは、それぞれのデプロイメント・タスクについて、システムの各種コンポーネントに固有の要件とともに詳細に説明します。これらのトピックは、プロセスの各ステップごとの設定と構成についてのリファレンスとして利用できます。ただし、それらのみでは完全に機能するシャーディング構成は生成されません。これは、完全なシャーディング・シナリオを実装するのではなく、各ステップの要件のみを示しているためです。
「シャード・データベースのデプロイの例」では、典型的な参照構成の具体的なデプロイメント・シナリオについて説明しています。この項では、すべてのステップの完了後に、完全に機能するシャード・データベースを生成するために必要なすべてのコマンド例を示します。
ホストおよびオペレーティング・システムのプロビジョニングと構成
ソフトウェアをインストールする前に、Oracle Shardingのハードウェア、ネットワークおよびオペレーティング・システムの要件を確認してください。
-
Oracle Database Enterprise Editionは、Oracleシャード・データベースの実行時に必要になります。
-
シャードのハードウェア要件とオペレーティング・システム要件は、Oracle Databaseの要件と同じです。これらの要件の詳細は、Oracle Databaseのインストール・ドキュメントを参照してください。
-
シャード・カタログおよびシャード・ディレクタのハードウェア要件とオペレーティング・システム要件は、グローバル・データ・サービス・カタログおよびグローバル・サービス・マネージャの要件と同じです。これらの要件の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください。
-
ネットワーク要件は低遅延GigEです。
-
ポート通信の要件は次のとおりです。
-
すべてのシャードがすべてのシャード・ディレクタのリスナーとONSポートに到達できる必要があります。シャード・ディレクタのリスナー・ポートおよびONSポートが、アプリケーション/クライアント層、すべてのシャード、シャード・カタログおよび他のすべてのシャード・ディレクタに対して開かれている必要があります。
シャード・ディレクタのデフォルトのリスナー・ポートは、1522です。デフォルトのONSポートは、ほとんどのプラットフォームで6123 (ローカルONS)および6234 (リモートONS)です。
-
すべてのシャードがシャード・カタログ(プライマリとスタンバイの両方)のTNSリスナー・ポート(デフォルトは1521)に到達できる必要があります。
-
各シャードのTNSリスナー・ポートがすべてのシャード・ディレクタおよびシャード・カタログに対して開かれている必要があります。
-
前述したポート番号のすべては、デプロイメント構成時に変更できます。ただし、使用するポート番号は、ホスト・ソフトウェアの設定前に決定しておく必要があります。
-
-
ホスト名の解決は、すべてのシャード・カタログ、シャード、およびシャード・ディレクタ・ホストで成功する必要があります。オペレーティング・システムのコマンド(pingなど)は、シャード・データベース構成コマンドで提示されたホスト名の指定時に、特定のホストから別のホストに向けて成功する必要があります。
ホスト・システムの数とサイズ設定
目的とする構成によっては、次のホストも必要になることがあります。
-
シャード・カタログ・ホスト。シャード・カタログ・ホストでは、シャード・カタログとして機能するOracle Databaseを実行します。このデータベースには、少量のシャーディング・トポロジ・メタデータと、アプリケーション用に作成した重複表を格納します。また、このデータベースは、シャーディングに対応していないアプリケーションのクロスシャード問合せおよびサービスの接続のための問合せコーディネータとしても機能します。一般に、このデータベースのトランザクション・ワークロードとサイズは、特に大きなものにはなりません。
-
シャード・カタログ・データベースのスタンバイ(レプリカ)。プライマリ・シャード・カタログ・データベースのレプリカまたはスタンバイは、少なくとも1つ以上のホストに格納することをお薦めします。このホストは、プライマリ・カタログ・ホストの障害発生時に必要になります。また、このホストは、スタンバイ・データベースとして機能すると同時に、クロスシャード問合せの問合せコーディネータになるように構成することもできます。
-
シャード・ディレクタ・ホスト。シャード・ディレクタ(グローバル・サービス・マネージャ)ソフトウェアは、個別のホストに配置することも、シャード・カタログと同じホストに配置することもできます。このシャーディング・システムのコンポーネントは、シャード構成の監視と構成に使用するネットワーク・リスナーと複数のバックグラウンド・プロセスで構成されます。シャード・ディレクタをカタログ・データベースと同じホストに配置する場合は、カタログ・データベースとは別のOracleホームにインストールする必要があります。これは、インストール・パッケージがOracle Databaseに使用するものと異なるためです。
-
複数のシャード・ディレクタ。高可用性のために、シャード・システム内で複数のシャード・ディレクタを実行することをお薦めします。追加のシャード・ディレクタは、専用のホストで実行することも、スタンバイ・シャード・カタログ・データベースを実行するホストで実行することもできます。
-
シャード。前述のホストに加えて、システム内で構成される各シャードは、それぞれ個別のホストで実行することも必要になります。このタスク用に選択したホストとその構成では、一般的なOracle Databaseホストと同じ方法で、それぞれのシャードにかかる負荷に応じたサイズを設定する必要があります。
-
シャード・スタンバイ(レプリカ)。前述したように、高可用性と障害回復のために、レプリケーション・テクノロジ(Oracle Data GuardやOracle Golden Gateなど)を使用する必要があり、すべてのシャード・データのレプリカを作成します。追加のホストは、こうしたレプリカまたはスタンバイ・データベースを実行するために必要になります。
ノート:
Oracle ShardingのOracle GoldenGateレプリケーション・サポート高可用性は、Oracle Database 21cでは非推奨です。
ホストの数と各ホストの容量要件を決定したら、選択した手法を使用して環境に適したハードウェア・リソースをプロビジョニングします。ソフトウェアをインストールする前に、それぞれのホストが前述したポートを通じて相互に通信できることを確認します。シャーディング構成は、本質的に分散システムであるため、デプロイメント・プロセスの次のステップに進む前に、このホスト間およびホスト全体の接続を確認しておくことが重要です。ポート・アクセスが適切に設定されていないと、今後のコマンドのエラーの原因になります。
Oracle Databaseソフトウェアのインストール
シャード・カタログ、データベース・シャードまたはレプリカをホストする各システムにOracle Databaseをインストールします。
Oracle Sharding構成内のシャード・カタログとすべてのシャードにはOracle Database Enterprise Editionが必須という要件がありますが、インストールとすべてのインストール後スクリプトの実行が成功していれば、それ以外に必要になる特別なインストールの考慮事項はありません。
オペレーティング・システム・ユーザーの構成の詳細は、対象プラットフォームのインストレーション・ガイド(https://docs.oracle.com/en/database/oracle/oracle-database/)を参照してください。
CREATE SHARDメソッドを使用してシャードを構成に追加する場合は、各シャード・ホストにリモート・スケジューラ・エージェント・ソフトウェアもインストールする必要があります。エージェントは、シャード・カタログ・ホストにインストールする必要はありません。手順は、リモート・ホストでのスケジューラ・エージェントのインストールと構成に関する項を参照してください。
また、CREATE SHARDメソッドでは、各シャード・ホストに2つのディレクトリ($ORACLE_BASE/oradataおよび$ORACLE_BASE/fast_recovery_area)を作成する必要があります。Oracle Databaseソフトウェアの所有者としてシャード・ホストにログインしている間に、これら2つのディレクトリを作成します。権限は、シャード・データベースのデータ・ファイルを保持するディレクトリと同じに設定する必要があり、通常、ソフトウェア所有者のみがフル・アクセスできます。
シャード・ディレクタ・ソフトウェアのインストール
シャード・ディレクタをホストする各システムにグローバル・サービス・マネージャ・ソフトウェアをインストールします。
このソフトウェアのインストールは、Oracle Databaseインストールとは異なる点に注意してください。シャード・ディレクタ・ソフトウェアをシャード・カタログ・データベースと同じホストに配置することにした場合は、個別のOracleホームにインストールする必要があります。
グローバル・サービス・マネージャ・ソフトウェアのインストールの詳細は、『Oracle Database Global Data Services概要および管理ガイド』を参照してください。
シャード・カタログ・データベースの作成
次の情報とガイドラインを使用して、シャード・カタログ・データベースを作成してください。
シャード・カタログ・データベースには、少量のシャーディング・トポロジ・メタデータと、シャード・アプリケーションで使用するために作成するすべての重複表を格納します。カタログ・データベースは、複数のシャードからデータを選択して集計するクロスシャード問合せを実行するための問合せコーディネータとしても機能します。
シャーディングの観点では、カタログ・データベースの作成方法やプロビジョニング方法は重要ではありません。このデータベースは、Database Configuration Assistant (DBCA)で作成することも、SQL*Plusを使用して手動で作成することも、クラウド・インフラストラクチャ・ツールからプロビジョニングすることもできます。
次の特性を備えたシャード・カタログ・ホストでOracle Database Enterprise Editionインスタンスを実行していれば、シャード・カタログとして使用できます。
-
シャード・カタログ・データベースとして使用するレガシー・データベースまたはプラガブル・データベース(PDB)を作成します。コンテナ・データベース(CDB)のルート・コンテナ(
CDB$ROOT)をシャード・カタログ・データベースとして使用することは、サポートされていません。 -
シャード・カタログ・データベースでは、サーバー・パラメータ・ファイル(
SPFILE)を使用する必要があります。これが必要になる理由は、シャーディング・インフラストラクチャが内部データベース・パラメータを使用して構成メタデータを保存し、そのデータはデータベースの起動操作と停止操作の間で永続している必要があるためです。$ sqlplus / as sysdba SQL> show parameter spfile NAME TYPE VALUE -------- --------- ------------------------------------ spfile string /u01/app/oracle/dbs/spfilecat.ora -
データベース文字セットと各国語文字セットは、すべてのシャード・データベースで使用されるため、同じにする必要があります。つまり、シャード・カタログまたはシャードのいずれかに挿入される可能性のあるすべての文字が含まれている文字セットを選択する必要があるということです。
この要件は、
MOVE CHUNKコマンドのシャーディング時に、トランスポータブル表領域をシャード間で移動するためにOracle Data Pumpが内部的に使用されることから発生します。このメカニズムの要件は、ソースと宛先で文字セットが一致していることです。$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=catalog_pdb_name; SQL> select * from nls_database_parameters 2 where parameter like '%CHARACTERSET'; PARAMETER VALUE ---------------------------------------- -------------------- NLS_NCHAR_CHARACTERSET AL16UTF16 NLS_CHARACTERSET WE8DEC -
シャード・カタログ・データベースは、データベース・リンクによってシャードに接続するマルチシャード問合せを実行できるため、データベース初期化パラメータ
OPEN_LINKSおよびOPEN_LINKS_PER_INSTANCEの値は、シャード・データベース構成に含まれるシャードの数以上にする必要があります。$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=catalog_pdb_name; SQL> show parameter open_links NAME TYPE VALUE ------------------------------------ ----------- ------------ open_links integer 20 open_links_per_instance integer 20 -
データベース初期化パラメータ
DB_FILESは、システム内のチャンクや表領域の合計数以上に設定します。シャーディング構成内の各データ・チャンクは、表領域パーティションとして実装され、専用のオペレーティング・システム・データ・ファイル内に存在します。そのため、データベース初期化パラメータ
DB_FILESは、システム内のチャンク数(CREATE SHARDCATALOGまたはADD SHARDSPACEコマンドで指定)や表領域数の合計以上にする必要があります。$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=catalog_pdb_name; SQL> show parameter db_files NAME TYPE VALUE ------------------------------------ ----------- ------------ db_files integer 1024 -
CREATE SHARDを使用してシャードをシャーディング構成に追加する場合は、SHARED_SERVERSおよびDISPATCHERSデータベース初期化パラメータを設定して、リモート・スケジューラ・エージェントがXDB接続を介してカタログに接続できるようにする必要があります。ADD SHARDを使用する場合、これは必要ありません。具体的には、シャード・ホストで実行されているリモート・スケジューラ・エージェント・プロセスからシャード・カタログへの共有サーバー接続を許可するには、
SHARED_SERVERSを0 (ゼロ)より大きくする必要があります。また、DISPATCHERSの値には、Oracle SIDの値に基づいてXDBのサービスが含まれている必要があります。$ sqlplus / as sysdba SQL> show parameter shared_servers NAME TYPE VALUE ------------------------------------ ----------- ------------ shared_servers integer 5 SQL> show parameter dispatchers NAME TYPE VALUE ------------------------------------ ----------- ---------------------- Dispatchers string (PROTOCOL=TCP), (PROTO COL=TCP)(SERVICE=mysid XDB)パラメータ値を適切に設定したら、
ALTER SYSTEM REGISTERコマンドを実行して、XDBサービスが着信接続リクエストで使用できることを確認します。 -
シャーディング・チャンク管理インフラストラクチャで使用されるOracle Managed Filesをサポートするには、データベース・パラメータ
DB_CREATE_FILE_DESTに有効な値が設定されている必要があります。この場所は、チャンクの移動操作(
MOVE CHUNKや自動リバランスなど)の実行中に、チャンク・データを保持するトランスポータブル表領域を保存するために使用されます。さらに、『Oracle Database管理者ガイド』のOracle Managed Filesの使用に関する項で説明されているファイルも、Oracle Managed Filesを使用するOracleデータベースの慣例に従って、この場所に保存されます。$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=catalog_pdb_name; SQL> show parameter db_create_file_dest NAME TYPE VALUE --------------------- --------- ----------------------------- db_create_file_dest string /u01/app/oracle/oradata -
スタンバイ・カタログ・データベースがシャーディング構成の一部である場合、スタンバイ・カタログ・データベースに新しいデータベース・ファイルを自動的に作成するために、
STANDBY_FILE_MANAGEMENTデータベース・パラメータを設定する必要があります。このパラメータが
MANUAL(デフォルト)に設定されている場合、たとえばCREATE TABLESPACEコマンドで作成される新しいデータベース・ファイルは、スタンバイには作成されません。これにより、スタンバイがプライマリ・データベースになると、データが使用できなくなり、アプリケーション・エラーが発生します。$ sqlplus / as sysdba SQL> alter session set container=catalog_pdb_name; SQL> show parameter standby_file_management NAME TYPE VALUE ------------------------------------ ----------- ------------ standby_file_management stirng AUTO -
Oracle提供の
GSMCATUSERという名前のユーザー・アカウントは、シャード・カタログに指定したレガシー・データベースまたはPDB内でロック解除してパスワードを割り当てる必要があります。このアカウントは、シャード・ディレクタのプロセスがシャード・カタログ・データベースに接続して、シャーディング・コマンドに応じて管理タスクを実行するために使用されます。PDBをシャード・カタログとして使用している場合、
GSMCATUSERはコンテナ・データベースの共通ユーザーであることに注意してください。そのため、そのパスワードはCDB$ROOTおよびCDB内のすべてのPDBで同じになります。単一のCDB内にある複数のPDBが別々のシャーディング構成のカタログ・データベースとして使用されていると、それらすべてが同じGSMCATUSERのパスワードを共有するようなりセキュリティ上の問題が発生することがあります。これを回避するために、CDBごとにシャード・カタログPDBを1つのみホストして、それ以外のPDBではGSMCATUSERアカウントのロックを解除しないようにします。指定したパスワードは、この後のシャーディング・トポロジの作成時に発行する
ADD GSMコマンドで使用します。これは、シャード・ディレクタによってOracleウォレットに安全に保管され、必要なときにのみ復号化されるため、再指定が必要になることはありません。MODIFY GSMコマンドは、その後にシャード・カタログ・データベースでパスワードが変更されたときに、保管したパスワードを更新するために使用できます。$ sqlplus / as sysdba SQL> alter user gsmcatuser account unlock; User altered. SQL> alter user gsmcatuser identified by gsmcatuser_password; User altered.PDBをシャード・カタログとして使用している場合、次のコマンドも実行します。
SQL> alter session set container=catalog_pdb_name; SQL> alter user gsmcatuser account unlock; User altered. -
シャード・カタログの管理者アカウントは、シャード・カタログとして指定したレガシー・データベースまたはPDB内で作成し、パスワードを割り当てて、権限を付与する必要があります。
このアカウントは、シャード・カタログ・データベース内のシャーディング・メタデータに対する管理者アカウントです。管理者がシャード・データベース・トポロジに変更を加えるなどの管理タスクを実行する必要があるときに、
GDSCTLユーティリティを使用してシャード・カタログにアクセスするために使用します。GDSCTLは、GDSCTLコマンドの実行時に、このユーザーとしてシャード・カタログ・データベースに接続します。指定したユーザー名とパスワードは、この後のCREATE SHARDCATALOGコマンドで使用します。前述したGSMCATUSERと同様に、ユーザー名とパスワードは今後の使用に備えてOracleウォレットに安全に保存されます。保存された資格証明は、GDSCTLから明示的にCONNECTコマンドを発行してウォレット内の値をリセットすることで更新できます。$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=catalog_pdb_name; SQL> create user mysdbadmin identified by mysdbadmin_password; User created. SQL> grant gsmadmin_role to mysdbadmin; Grant succeeded. -
Oracle Net TNSリスナーを設定して選択したポート(デフォルトは1521)で実行します。これにより、シャード・カタログのレガシー・データベースまたはPDBに対する着信接続リクエストを処理できます。
TNSリスナーは、どのような方法で作成および構成してもかまいません。シャード・カタログがPDBの場合、データベースの作成方法によっては、
ALTER SESSION SET CONTAINERを使用する必要のない、PDBへの直接接続リクエストを許可できるデータベース・サービスを明示的に作成することが必要になる場合もあります。シャード・カタログにPDBを使用している場合、リスナーが正しく構成されていることを確認するには、前の手順で新しく作成したmysdbadminアカウントと適切な接続文字列を使用して、次の操作を実行します。
LSNRCTL SERVICESを実行すると、このリスナーを使用して現在利用可能なすべてのサービスが示されます。$ sqlplus mysdbadmin/mysdbadmin_password@catalog_connect_string SQL> show con_name CON_NAME ----------------------- catalog_pdb_name接続を確認したら、前述のcatalog_connect_stringを記録しておきます。これは、この後の構成プロセスの
GDSCTL CREATE SHARDCATALOGコマンドで使用します。一般に、これはhost:port/service_nameの形式になります(たとえば、cathost.example.com:1521/catalog_pdb.example.com)。
前述の要件がすべて満たされていると、新しく作成したデータベースはGDSCTL CREATE SHARDCATALOGコマンドの実行可能対象になります。
高可用性と障害回復のために、1つ以上のスタンバイ・シャード・カタログ・データベースも作成するようにしてください。シャーディングの観点からは、前述の要件がスタンバイ・データベースでも満たされていて、プライマリ・シャード・カタログ・データベースに対するすべての変更がスタンバイに確実に適用されていれば、その他に必要なシャーディング固有の構成ステップはありません。
シャード・データベースの作成
CREATE SHARDメソッドを使用してシャードを構成に追加する場合、このトピックはCREATE SHARDに適用されないためスキップします。それ以外の場合は、シャードとして使用するデータベースをそれぞれのホストで作成する必要があります。
シャード・カタログ・データベースと同様に、シャード・データベースの作成方法やプロビジョニング方法はシャーディングの観点からすると重要ではありません。このデータベースは、Database Configuration Assistant (DBCA)で作成することも、SQL*Plusを使用して手動で作成することも、クラウド・インフラストラクチャ・ツールからプロビジョニングすることもできます。
次の特性を備えた各シェード・ホストでOracle Database Enterprise Editionインスタンスを実行していれば、シャードとして使用できます。
-
シャードがCDB内のPDBである場合、Oracle提供の
GSMROOTUSERという名前のユーザー・アカウントは、シャードに指定したデータベースのCDB$ROOT内でロック解除してパスワードを割り当てる必要があります。さらに、このユーザーには、システム権限SYSDGおよびSYSBACKUPを付与する必要があります。GSMROOTUSERアカウントは、GDSCTLおよびシャード・ディレクタのプロセスがシャード・データベースに接続して、シャーディング・コマンドに応じて管理タスクを実行するするために使用されます。指定したパスワードは、シャーディング・トポロジの作成時にGDSCTLによって発行されるADD CDBコマンドで使用されます。また、シャード・ディレクタでシャード・データベースにOracle Data Guardを構成するためにDEPLOYコマンドを実行するときにも使用されます(必要な場合)。ユーザーによる再指定が必要なることはありません。GDSCTLとシャード・ディレクタによってOracleウォレット内に安全に保管され、必要なときにのみ復号化されます。MODIFY CDBコマンドは、その後にシャード・データベースでパスワードが変更されたときに、保管したパスワードを更新するために使用できます。$ sqlplus / as sysdba SQL> alter user gsmrootuser account unlock; User altered. SQL> alter user gsmrootuser identified by gsmrootuser_password; User altered. SQL> grant SYSDG, SYSBACKUP to gsmrootuser; Grant succeeded. -
シャードがPDBである場合、シャード・データベースとして使用するPDBを作成します。CDBのルート・コンテナ(
CDB$ROOT)をシャードとして使用することは、サポートされていません。 -
シャード・データベースでは、サーバー・パラメータ・ファイル(
SPFILE)を使用する必要があります。SPFILEが必要になる理由は、シャーディング・インフラストラクチャが内部データベース・パラメータを使用して構成メタデータを保存し、そのデータはデータベースの起動操作と停止操作の間で永続している必要があるためです。$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=shard_pdb_name; SQL> show parameter spfile NAME TYPE VALUE -------- --------- ------------------------------------ spfile string /u01/app/oracle/dbs/spfileshard.ora -
シャード・データベースのデータベース文字セットと各国語文字セットは、シャード・カタログ・データベースとその他のすべてのシャード・データベースで使用されているものと同じにする必要があります。つまり、シャード・カタログまたはシャードのいずれかに挿入される可能性のある文字がすべて含まれている文字セットを選択する必要があるということです。
この要件は、
MOVE CHUNKコマンドのシャーディング時に、トランスポータブル表領域をシャード間で移動するためにOracle Data Pumpが内部的に使用されることから発生します。このメカニズムの要件は、ソースと宛先で文字セットが一致していることです。$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=shard_pdb_name; SQL> select * from nls_database_parameters 2 where parameter like '%CHARACTERSET'; PARAMETER VALUE ---------------------------------------- -------------------- NLS_NCHAR_CHARACTERSET AL16UTF16 NLS_CHARACTERSET WE8DEC -
COMPATIBLE初期化パラメータを少なくとも12.2.0に設定する必要があります。$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=shard_pdb_name; SQL> show parameter compatible NAME TYPE VALUE ---------------------- ----------- ----------------- compatible string 19.0.0 -
フラッシュ・データベースは、シャード・データベースがスタンバイ・シャード・データベースを使用する場合に有効にします。
$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=shard_pdb_name; SQL> select flashback_on from v$database; FLASHBACK_ON ------------------ YES -
FORCE LOGGINGモードは、シャード・データベースがスタンバイ・シャード・データベースを使用する場合に有効にする必要があります。$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=shard_pdb_name; SQL> select force_logging from v$database; FORCE_LOGGING --------------------------------------- YES -
データベース初期化パラメータ
DB_FILESは、システム内のチャンクや表領域の合計数以上に設定します。シャーディング構成内の各データ・チャンクは、表領域パーティションとして実装され、専用のオペレーティング・システム・データファイル内に存在します。そのため、データベース初期化パラメータ
DB_FILESは、システム内のチャンク数(CREATE SHARDCATALOGコマンドまたはADD SHARDSPACEコマンドで指定)や表領域数の合計以上にする必要があります。$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=shard_pdb_name; SQL> show parameter db_files NAME TYPE VALUE ------------------------------------ ----------- ------------ db_files integer 1024 -
シャーディング・チャンク管理インフラストラクチャで使用されるOracle Managed Filesをサポートするには、データベース・パラメータの
DB_CREATE_FILE_DESTに有効な値が設定されている必要があります。この場所は、チャンクの移動操作(
MOVE CHUNKや自動リバランスなど)の実行中に、チャンク・データを保持するトランスポータブル表領域を保存するために使用されます。さらに、『Oracle Database管理者ガイド』のOracle Managed Filesの使用に関する項で説明されているファイルも、Oracle Managed Filesを使用するOracleデータベースの慣例に従って、この場所に保存されます。$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=shard_pdb_name; SQL> show parameter db_create_file_dest NAME TYPE VALUE --------------------- --------- ----------------------------- db_create_file_dest string /u01/app/oracle/oradata -
DATA_PUMP_DIRというディレクトリ・オブジェクトをシャード・データベース内に作成して、GSMADMIN_INTERNALアカウントからアクセスできるようにする必要があります。GSMADMIN_INTERNALは、すべてのシャーディング・メタデータ表とPL/SQLパッケージを所有するOracle提供のアカウントです。ロックしたままにして、対話的なログインに使用されないようにしてください。シャーディング・メタデータとPL/SQLを所有することと、それに対するアクセスを制御することのみを目的としたものです。$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=shard_pdb_name; SQL> create or replace directory DATA_PUMP_DIR as ‘/u01/app/oracle/oradata’; Directory created. SQL> grant read, write on directory DATA_PUMP_DIR to gsmadmin_internal; Grant succeeded. -
シャード間のファイル移動をサポートするには、データベース・パラメータの
DB_FILE_NAME_CONVERTに有効な値が設定されている必要があります。この場所は、一般的な非シャーディング・データベースのように、スタンバイ・データベースが使用中のときに使用され、チャンク移動操作中にも使用できます。通常のファイル・システムの場所の場合は、このパラメータの末尾をスラッシュ(/)にすることをお薦めします。$ sqlplus / as sysdba SQL> REM run the following command if using a CDB SQL> alter session set container=shard_pdb_name; SQL> show parameter db_file_name_convert NAME TYPE VALUE ---------------------- --------- ----------------------------- db_file_name_convert string /dbs/SHARD1/, /dbs/SHARD1S/ -
スタンバイ・シャード・データベースがシャーディング構成の一部である場合、
STANDBY_FILE_MANAGEMENTデータベース・パラメータをAUTOに設定して、スタンバイ・シャード・データベースに新しいデータベース・ファイルを自動的に作成する必要があります。このパラメータが
MANUAL(デフォルト)に設定されている場合、たとえばCREATE TABLESPACEコマンドで作成される新しいデータベース・ファイルは、スタンバイには作成されません。これにより、スタンバイがプライマリ・データベースになると、データが使用できなくなり、アプリケーション・エラーが発生します。$ sqlplus / as sysdba SQL> alter session set container=shard_pdb_name; SQL> show parameter standby_file_management NAME TYPE VALUE ------------------------------------ ----------- ------------ standby_file_management string AUTO -
Oracle提供の
GSMUSERという名前のユーザー・アカウントは、シャード・データベースとして指定したPDBまたはレガシー・データベース内でロック解除してパスワードを割り当てる必要があります。さらに、このユーザーには、システム権限SYSDGおよびSYSBACKUPを付与する必要があります。シャードがPDBの場合、
GSMUSERはCDBの共通ユーザーであることに注意してください。そのため、そのパスワードはCDB$ROOTおよびCDB内のすべてのPDBで同じになります。これは、セキュリティ上の問題につながります。これを回避するために、CDBごとにシャードPDBを1つのみホストして、それ以外のPDBではGSMUSERアカウントのロックを解除しないようにします。このアカウントは、シャード・ディレクタのプロセスがシャード・データベースに接続して、シャーディング・コマンドに応じて管理タスクを実行するために使用されます。指定したパスワードは、この後のシャーディング・トポロジの作成時に発行する
ADD SHARDコマンドで使用します。このパスワードは、シャード・ディレクタによってOracleウォレットに安全に保管され、必要なときにのみ復号化されるため、再指定が必要になることはありません。その後、シャード・データベースでパスワードが変更された場合、保管したパスワードはMODIFY SHARDコマンドを使用して更新できます。$ sqlplus / as sysdba SQL> alter user gsmuser account unlock; User altered. SQL> alter user gsmuser identified by gsmuser_password; User altered. SQL> REM run the following commands if using a CDB SQL> alter session set container=shard_pdb_name; SQL> alter user gsmuser account unlock; User altered. SQL> REM all cases run the following command SQL> grant SYSDG, SYSBACKUP to gsmuser; Grant succeeded. -
Oracle Net TNSリスナーを設定して選択したポート(デフォルトは1521)で実行します。これにより、シャードPDBに対する着信接続リクエストを処理できます。
TNSリスナーは、どのような方法で作成および構成してもかまいません。シャードがPDBの場合、データベースの作成方法によっては、
ALTER SESSION SET CONTAINERを使用する必要のない、PDBへの直接接続リクエストを許可できるデータベース・サービスを明示的に作成することが必要になる場合もあります。シャードにPDBを使用している場合、リスナーが正しく構成されていることを確認するには、新しくロック解除した
GSMUSERアカウントと適切な接続文字列を使用して、次の操作を実行します。LSNRCTL SERVICESを実行すると、このリスナーを使用して現在利用可能なすべてのサービスが示されます。$ sqlplus gsmuser/gsmuser_password@shard_connect_string SQL> show con_name CON_NAME ----------------------- shard_pdb_name接続を確認したら、前述のshard_connect_stringを記録しておきます。これは、この後の構成プロセスの
GDSCTL ADD SHARDコマンドで使用します。一般に、この接続文字列はhost:port/service_nameの形式になります(たとえば、shardhost.example.com:1521/shard_pdb.example.com)。
シャード・データベースの検証
前述の要件がすべて満たされていることを確認するには、Oracle提供のプロシージャ validateShardを実行します。これにより、シャード・データベースを検査して、発生した問題があるときに報告します。このプロシージャは、読取り専用であり、データベース構成に変更を加えることはありません。
validateShardプロシージャは、シャード・データベース構成に含まれるプライマリ、マウント済(未オープン)スタンバイ、およびActive Data Guardスタンバイのデータベースに対して実行する必要があります。validateShardは、シャード・データベースのライフサイクル期間中に、アップグレード後やパッチ適用後など、いつでも何度でも実行できます。
validateShardパッケージを実行するには、次のように操作します。
$ sqlplus / as sysdba
SQL> REM run the following command if using a CDB
SQL> alter session set container=shard_pdb_name;
SQL> set serveroutput on
SQL> execute dbms_gsm_fix.validateShard
このプロシージャでは、次のような出力が生成されます。
INFO: Data Guard shard validation requested.
INFO: Database role is PRIMARY.
INFO: Database name is SHARD1.
INFO: Database unique name is shard1.
INFO: Database ID is 4183411430.
INFO: Database open mode is READ WRITE.
INFO: Database in archivelog mode.
INFO: Flashback is on.
INFO: Force logging is on.
INFO: Database platform is Linux x86 64-bit.
INFO: Database character set is WE8DEC. This value must match the character set of the catalog database.
INFO: 'compatible' initialization parameter validated successfully.
INFO: Database is a multitenant container database.
INFO: Current container is SHARD1_PDB1.
INFO: Database is using a server parameter file (spfile).
INFO: db_create_file_dest set to: '/u01/app/oracle/dbs'
INFO: db_recovery_file_dest set to: '/u01/app/oracle/dbs'
INFO: db_files=1000. Must be greater than the number of chunks and/or
tablespaces to be created in the shard.
INFO: dg_broker_start set to TRUE.
INFO: remote_login_passwordfile set to EXCLUSIVE.
INFO: db_file_name_convert set to: '/dbs/SHARD1/, /dbs/SHARD1S/'
INFO: GSMUSER account validated successfully.
INFO: DATA_PUMP_DIR is '/u01/app/oracle/dbs/9830571348DFEBA8E0537517C40AF64B'.
INFOのマークが付いているすべての出力行は、情報の提示を目的としています。この行の情報が目的の構成に適っていることを確認する必要があります。
ERRORのマークが付いているすべての行は、デプロイメントの次のステップに進む前に修正する必要があります。こうした問題が解決されていないと、シャーディング作成操作のエラーの原因になります。
WARNINGのマークが付いているすべての出力行は、目的の構成に適していることも、適していないこともあります。たとえば、このデプロイメントにはスタンバイ・データベースを使用しないことにしていた場合、スタンバイ・データベースやリカバリに関連する警告は無視できます。特に、本番以外のデプロイ、概念実証のデプロイ、アプリケーション開発のデプロイなどの場合に当てはまります。すべての警告を確認して、必要に応じて解決してください。
ここまでのすべてのステップを完了すると、新しく作成したデータベースはGDSCTL ADD SHARDコマンドの実行可能対象になります。
高可用性と障害回復のために、1つ以上のスタンバイ・シャード・データベースも作成するようにしてください。シャーディングの観点からは、前述の要件がスタンバイ・データベースでも満たされていて、プライマリ・シャード・データベースに対するすべての変更がスタンバイに確実に適用されていれば、スタンバイ・データベースに必要な作業は、ADD SHARDコマンドでシャーディング構成を追加することのみです。
シャード・データベース・トポロジの構成
シャード・データベース・トポロジは、シャード・カタログ・データベースのシャーディング・メタデータによって記述されます。GDSCTLを使用して、シャード・データベース・トポロジを構成します。
シャード・データベース・トポロジは、シャーディング方法、レプリケーション(高可用性)テクノロジ、シャード・データベースに用意するチャンクのデフォルト数、シャード・ディレクタの場所と数、シャード・データベース内のシャードグループ、シャード領域、リージョンおよびシャードの数、およびシャード・データベースへの接続に使用するグローバル・サービスで構成されます。
『Oracle Database Global Data Services概要および管理ガイド』のGlobal Data Services Control Utility (GDSCTL)コマンド・リファレンスを手元に用意して、構成手順で使用するGDSCTLコマンドの使用方法とオプションの詳細を調べてください。
シャード・カタログの作成
GDSCTL CREATE SHARDCATALOGコマンドは、シャード・データベース・トポロジについての情報を示すメタデータをシャード・カタログ・データベースに作成するために使用します。
CREATE SHARDCATALOGを実行して、残りのシャーディング・メタデータが作成されると、いくつかのメタデータのプロパティはシャード・データベース全体を最初から再作成しないと変更できなくなります。こうしたものには、シャーディング方法(システム管理、コンポジット、ユーザー定義)、レプリケーション・テクノロジ(Oracle Data Guard、Oracle GoldenGate)、データベース内のチャンクのデフォルト数などがあります。コマンドに使用可能なオプションとそのデフォルト値の完全なリストは、GDSCTLのリファレンス・ドキュメントを参照してください。
コマンドの使用方法は、GDSCTLのドキュメントを参照するか、GDSCTL HELP CREATE SHARDCATALOGを実行してください。
シャード・カタログ接続文字列
CREATE SHARDCATALOGコマンドを実行すると、GDSCTLは指定されたユーザー名と接続文字列でシャード・カタログ・データベースに接続します。
高可用性または障害回復のために、シャード・カタログ・データベースにスタンバイ・データベースが関連付けられている場合は、接続文字列(次の例のcatalog_connect_string)で、すべてのプライマリ・データベースおよびスタンバイ・データベースを指定する必要があります。接続文字列にスタンバイ・データベースを含めていないと、シャード・ディレクタのプロセスはプライマリ・シャード・カタログが使用不可のときにスタンバイに接続できなくなります。
シャード・カタログ・データベースがPDBの場合、catalog_connect_stringでは、CDB$ROOTではなく、シャード・カタログ・データベースのPDBを指定する必要があります。
次に、簡潔なtnsnames.oraのエントリを示します。
CATALOG_CONNECT_STRING=
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = tcp)(HOST = primary_catalog)(PORT = 1521))
(ADDRESS = (PROTOCOL = tcp)(HOST = standby_catalog)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = catpdb.example.com)
)
)ADD SHARDメソッドを使用してシャードを作成する場合は、最初のステップのみを実行します。CREATE SHARDメソッドを使用する場合は、両方のステップを実行します。
-
計画したシャーディング・トポロジに適した設定で、
CREATE SHARDCATALOGを実行します。CREATE SHARDメソッドに必要な追加パラメータ
CREATE SHARDメソッドを使用してシャードを構成に追加する場合は、CREATE SHARDCATALOGを実行するときに、次の追加パラメータを設定する必要があります。これは、次のステップでリモート・スケジューラ・エージェント登録に必要です。–agent_passwordでは、リモート・スケジューラ・エージェントがシャード・カタログへの登録に使用するパスワードを指定します。–agent_portでは、エージェントがシャード・カタログへのXDB接続の作成に使用するポート番号を指定します。このパラメータのデフォルト値は8080です。
システム管理のシャーディング方法
次の例では、システム管理シャーディング構成用のシャード・データベース・メタデータが作成されます。この構成には、region1およびregion2という2つのリージョンがあります。システム管理はデフォルトのシャーディング方法であるため、
-shardingパラメータで指定する必要はありません。GDSCTL> create shardcatalog -database catalog_connect_string -user mysdbadmin/mysdbadmin_password -repl DG -region region1,region2-shardspaceの指定も省略すると、shardspaceoraというデフォルトのシャード領域が作成されます。-regionの指定を省略すると、regionoraというデフォルトのリージョンが作成されます。単一のデフォルト・リージョンがデフォルト・シャード領域とともに作成されると、そのシャード領域にshardspaceora_regionoraというデフォルトのシャードグループも作成されます。コンポジット・シャーディング方法
次の例は、コンポジット・シャード・データベース用のシャード・カタログ・メタデータの作成方法を示しています。ここでは、
MaxAvailability保護モードのData Guardレプリケーション、シャード領域ごとに60チャンク、および2つのシャード領域を設定します。GDSCTL> create shardcatalog -database catalog_connect_string -user mysdbadmin/mysdbadmin_password -sharding composite -chunks 60 -protectmode maxavailability -shardspace shardspace1,shardspace2ユーザー定義のシャーディング方法
次の例は、ユーザー定義のシャード・データベース用のシャード・カタログ・メタデータの作成方法を示しています。ここでは、Data Guardレプリケーションを設定しています。
GDSCTL> create shardcatalog -database catalog_connect_string -user mysdbadmin/mysdbadmin_password -sharding user -protectmode maxperformance -
CREATE SHARDメソッドのみの場合: リモート・スケジューラ・エージェントをシャード・カタログに登録し、各シャード・ホストでエージェントを起動します。
各シャード・ホストに移動して、Oracleソフトウェア・インストールの所有者としてログインし、シャード・データベースの実行元となるOracleホームで次の
schagentコマンドを実行します。schagent –registerdatabase catalog_hostname agent_port schagent -start前述の
schagentコマンドで、catalog_hostnameをシャード・カタログ・ホストの名前に置き換え、agent_portを前述のCREATE SHARDCATALOGで構成したポート番号に置き換えます。たとえば:
$ $ORACLE_HOME/bin/schagent –registerdatabase cathost.example.com 8080 $ $ORACLE_HOME/bin/schagent -start正常にエージェントを登録すると、シャード・ホストは
GDSCTL DEPLOY中にシャード・カタログからリモート・ジョブ・リクエストを受信できます。特定のホストに正常にデプロイされると、リモート・スケジューラ・エージェントは、シャード・データベースのライフ・サイクルでは使用されなくなり、次のコマンドを使用して安全に停止できます。$ $ORACLE_HOME/bin/schagent –stop
シャード・カタログへの今後の接続
GDSCTLは、シャード・カタログ管理者の資格証明をローカル・ホストのウォレットに保管します。ただし、次回以降の別のホストでのGDSCTLセッションでは、次に示すようにGDSCTL CONNECTコマンドを使用して、管理タスクを実行するために明示的にシャード・カタログに接続することが必要になる場合があります。
GDSCTL> connect mysdbadmin/mysdbadmin_password@catalog_connect_stringシャード・ディレクタの追加と起動
構成にシャード・ディレクタを追加して起動します。シャード・ディレクタでは、GDSCTLコマンドなどのイベントに応じてシャーディング・システムの監視や、バックグラウンド・タスクを実行します。
次のコマンドは、シャード・ディレクタのプロセスを実行するホストで実行する必要があります。これは、シャード・カタログ・ホストまたはシャード・ディレクタ・プロセスの専用ホストのどちらかになります。
今後のGDSCTLセッションでは、管理するシャード・ディレクタの明示的な指定が必要になることがあります。デフォルトのGSMORAシャード・ディレクタを示すエラー・メッセージが表示され場合は、次に示すように、GDSCTL SET GSMを実行してから作業を進めてください。
GDSCTL> set gsm -gsm sharddirector1シャード領域の追加(必要な場合)
コンポジット・シャーディングまたはユーザー定義シャーディングを使用するときに、目的のシャーディング・トポロジの達成にシャード領域の追加が必要な場合は、ADD SHARDSPACEコマンドを使用してシャード領域を追加します
シャードグループの追加(必要な場合)
シャード・データベース・トポロジにシステム管理またはコンポジットのシャーディング方法を使用する場合は、アプリケーション用に必要な追加のシャードグループを追加することもできます。
それぞれのシャード領域には、少なくとも1つのプライマリ・シャードグループを含める必要があり、任意の数またはタイプのスタンバイ・シャードグループを含めることができます。シャードグループは、ユーザー定義のシャーディング方法では使用しません。
シャーディング・トポロジの検証
シャード・データベースに関する情報をカタログに追加する前に、シャーディング・トポロジが適切なことを確認します。その後で、各種のGDSCTL CONFIGコマンドを使用して作業を進めてください。
シャードを追加してデプロイした後では、シャード・カタログ・メタデータの大部分が変更できなくなります。そのため、この時点で構成を検証することが重要なタスクになります。
シャードCDBの追加
シャードがCDB内のPDBである場合、ADD CDBコマンドを使用して、シャードPDBを格納するCDBをシャーディング構成に追加します。シャードとして非CDBを使用するか、またはCREATE SHARDを使用してシャードを追加する場合は、次の項へスキップします。
シャードの追加
シャードを構成に追加するのにADD SHARDとCREATE SHARDのどちらを使用するかに応じて、次の適切な手順に従います。
GDSCTL CREATE SHARDを使用したシャードの追加
GDSCTL CREATE SHARDコマンドを使用して、シャード・データベースを作成し、シャード情報をシャード・カタログに追加します。
次の例で示すように、対象のシャーディング方法に適したパラメータを使用してCREATE SHARDを実行します。
システム管理またはコンポジットのシャーディングの場合は、次に示すパラメータでCREATE SHARDを実行します。
GDSCTL> create shard -shardgroup shardgroup_name –destination shard_hostname
–osaccount account_name –ospassword account_passwordユーザー定義のシャーディングの場合は、わずかにコマンドの使用方法が異なります。
GDSCTL> create shard -shardspace shardspace_name –deploy_as db_mode
–destination shard_hostname –osaccount account_name –ospassword account_password-shardgroupまたは-shardspaceパラメータではシャーディング・トポロジ内のシャードの場所を指定し、-deploy_asではシャードの目的のオープン・モード(primary、standby、active_standby)を指定します。
–destinationパラメータでは、NETCAおよびDBCAを生成してシャード・データベースを作成するために、シャード・カタログがやり取りするリモート・スケジューラ・エージェントを指定します。この値は通常、シャード・ホストのホスト名です。使用可能な宛先のリストを表示するには、シャード・カタログ・データベースのALL_SCHEDULER_EXTERNAL_DESTSビューから選択します。
–osaccountおよび–ospasswordパラメータでは、シャード・ホストでNETCAおよびDBCAプロセスを生成するときに使用されるオペレーティング・システムのユーザー名およびパスワードを指定します。通常、ユーザー名はOracle Databaseソフトウェアの所有者です。
パスワードの暗号化
各CREATE SHARDコマンドでアカウントのクリアテキスト・パスワードを指定しないようにするには、後で使用するために、GDSCTL ADD CREDENTIALコマンドを使用して、暗号化されたパスワードをシャード・カタログに格納できます。CREATE SHARDコマンドで、次に示すように–osaccountおよび–ospasswordではなくコマンド・パラメータに資格証明名を指定します。
GDSCTL> add credential –credential credential_name
–osaccount account_name –ospassword account_password
GDSCTL> create shard -shardgroup shardgroup_name –destination shard_hostname
–credential credential_nameCREATE SHARDの実行時の処理
CREATE SHARDを実行すると、GDSCTLによって入力パラメータおよびシャード・ホスト設定が検証され、シャード・メタデータがシャード・カタログに追加され、その結果、GDSCTL DEPLOY中に次の操作が実行されます。
-
ポート1521で、リスナー名"LISTENER" (デフォルト)を使用して、TNSリスナー・プロセスをシャード・ホストに作成して起動します
-
プライマリ・シャードの場合、
$ORACLE_HOME/assistants/dbca/templates/General_Purpose.dbc(デフォルト)のシャード・ホストにあるデフォルトのDBCAテンプレートを使用して、シャード・データベースを作成します。プライマリ・シャードには、デフォルトで次の特性があります。
SYS、SYSTEMおよびGSMUSERに対してランダム生成されるパスワードdb_unique_name、db_nameおよび'shNN'形式のSID (NNは、追加されたシャードを一意に識別するための順序ベースの番号)db_domain値: 指定した宛先に対応するALL_SCHEDULER_EXTERNAL_DESTS.HOSTNAME列にあるドメインと同じ。ドメインが見つからない場合、db_domainはシャード・カタログ・データベースのdb_domainに設定されます。NLS_CHARACTERSET値およびNLS_NCHAR_CHARACTERSET値: シャード・カタログ・データベースの値と同じdb_file_name_convertパラメータ:'*','$ORACLE_BASE/oradata/'に設定db_create_file_destパラメータ:$ORACLE_BASE/oradataに設定remote_login_passwordfileパラメータ:EXCLUSIVEに設定- データベース: アーカイブ・ログ・モード
- 強制ロギング: 有効
- データベース・フラッシュバック: オン
- Oracle Data Guardレプリケーションが
CREATE SHARDCATALOGに指定されている場合は、次のパラメータが設定されます。dg_broker_start:TRUEに設定db_recovery_file_dest:$ORACLE_BASE/fast_recovery_areaに設定db_recovery_file_dest_size:51200 MBに設定standby_file_management:AUTOに設定db_flashback_retention_target:60に設定
- スタンバイ・シャードの場合、DBCAおよびRMANを使用して、既存のプライマリに基づいてスタンバイ・データベースを作成します。一般に、すべてのプライマリ・データベース・パラメータはスタンバイによって継承されます。
データベースのカスタマイズに関するCREATE SHARDの使用上のヒント
GDSCTL CREATE SHARDコマンドには、シャード・データベースをカスタマイズできるパラメータがいくつかあります。
-
–sys_passwordおよび–system_passwordパラメータを使用すると、SYSおよびSYSTEMアカウントのパスワードを新しいシャードに指定できます。このアカウントは対話型ログインで使用されるものではないため、
GSMUSERパスワードは常にランダムに作成されます。デプロイメント後にGSMUSERパスワードを変更するには、ALTER USERを使用してデータベース上のパスワードを変更し、GDSCTL MODIFY SHARDコマンドを使用して新しいパスワードでシャーディング・メタデータを更新します。 -
–netparamおよび–netparamfileパラメータを使用すると、TNSリスナーの名前およびポート番号をシャード・ホストで作成する際にカスタマイズできます。これらのパラメータに指定する値は、NETCAレスポンス・ファイルのファイル名です。レスポンス・ファイルの例は、シャード・ホストの
$ORACLE_HOME/assistants/netcaにあります。 -
同様に、
-dbtemplateおよび-dbtemplatefileパラメータを使用して、シャード・データベースの作成時に使用されるDBCAテンプレート・ファイルを指定できます。デフォルト・テンプレートは、シャード・ホスト上の
$ORACLE_HOME/assistants/dbca/templates/General_Purpose.dbcです。 -
コマンドラインからDBCAを実行するときに入力するのと同様に、
-dbparamおよび-dbparamfileパラメータを使用して、DBCAコマンドライン・パラメータをシャード・ホストのDBCAプロセスに直接渡すことができます。プライマリ・データベースの作成に使用可能なパラメータをすべて表示するには、
dbca -help -createDatabaseを実行します。スタンバイ・データベースを作成するためのパラメータを表示するには、dbca -help -createDuplicateDBを実行します。たとえば、プライマリ・シャードのグローバル・データベース名およびSIDを変更するには、次に示すように1行のファイルを作成し、そのファイル名を-dbparamまたは-dbparamfileに指定します。-gdbName mydb.example.com -sid mysid -
これらのパラメータのいずれかを指定する場合は、
GDSCTLのように、-netparamfile、-dbtemplatefileまたは-dbparamfileをオペレーティング・システム・ファイル名とともに使用できます。あるいは、
ADD FILEコマンドを使用して、ファイルの内容をシャード・カタログ・データベースに保存してから、CREATE SHARDコマンドで-netparam、-dbtemplateまたは-dbparamを使用することもできます。GDSCTL> create shard -dbtemplatefile /home/user/mytemplate.dbc -netparamfile /home/user/mynetca.rsp ...または
GDSCTL> add file –file mytemplate –source /home/user/mytemplate.dbc GDSCTL> add file –file mynetca –source /home/user/mynetca.rsp GDSCTL> create shard –dbtemplate mytemplate –netparam mynetca ...
特定のホストのスタンバイ・シャードが特定のプライマリ・シャードと同じData Guard構成にあることを保証する場合は、まずプライマリ・シャードを作成し、次にCREATE SHARDで目的の–destination値を使用してスタンバイ・シャードを作成することをお薦めします。複数のプライマリ・シャードを順次作成してから、複数のスタンバイ・シャードを作成する場合、Data Guard構成ではプライマリとスタンバイは非決定的な方法で一致します。
シャード構成の確認
GDSCTL CONFIG SHARDを実行して、シャード・カタログのシャード・メタデータが想定どおりであることを確認します。
GDSCTL> config shard
Name Shard Group Status State Region Availability
--------- ------------------- ------ ----- ------ ------------
sh1 shardgroup_primary U none region1 -
sh2 shardgroup_primary U none region1 -
sh3 shardgroup_standby U none region2 -
sh4 shardgroup_standby U none region2 -
「Status」の値は、"アンデプロイ"のUになります。「State」と「Availability」は、GDSCTL DEPLOYコマンドの実行が正常に完了するまではnoneと-になります。
ホスト・メタデータの追加
すべてのシャード・ホストのホスト名とIPアドレスをシャード・カタログに追加します。
デプロイメント・プロセスの一環として、シャード・ディレクタはシャードと通信して、シャード・ディレクタのTNSリスナー・プロセスに登録するように指示します。このリスナー・プロセスは、信頼できるソースからの着信登録リクエストのみを受け入れ、不明なホストからの登録リクエストを拒否します。
シャード・ホストに複数のホスト名またはネットワーク・インタフェースが割り当てられている場合、シャード・ディレクタへの着信登録リクエストは、ADD SHARDまたはCREATE SHARDの実行時に自動的に追加されていなかったホストから送信される可能性があります。この場合、その登録リクエストは拒否され、シャードは正常にデプロイされなくなります。この問題について目視できる現象は、DEPLOYの完了後に、CONFIG SHARDがシャードの「Availability」にPENDINGを示すことです。
この問題を回避するために、GDSCTL ADD INVITEDNODEコマンドを使用して、シャード・ホストのすべてのホスト名とIPアドレスをシャード・カタログ・メタデータに手動で追加します。
シャーディング構成のデプロイ
GDSCTLコマンドでシャード・データベース・トポロジの構成を完了したら、GDSCTL DEPLOYコマンドを実行してシャード・データベース構成をデプロイします。
GDSCTL DEPLOYコマンドを実行すると、ADD SHARDコマンドを使用してシャードを構成した場合、出力は次のようになります。
GDSCTL> deploy
deploy: examining configuration...
deploy: requesting Data Guard configuration on shards via GSM
deploy: shards configured successfully
The operation completed successfullyCREATE SHARDを使用してシャードを構成した場合、GDSCTL DEPLOYコマンドの出力は次のようになります。
GDSCTL> deploy
deploy: examining configuration...
deploy: deploying primary shard 'sh1' ...
deploy: network listener configuration successful at destination 'shard1'
deploy: starting DBCA at destination 'shard1' to create primary shard 'sh1' ...
deploy: deploying primary shard 'sh2' ...
deploy: network listener configuration successful at destination 'shard2'
deploy: starting DBCA at destination 'shard2' to create primary shard 'sh2' ...
deploy: waiting for 2 DBCA primary creation job(s) to complete...
deploy: waiting for 2 DBCA primary creation job(s) to complete...
deploy: DBCA primary creation job succeeded at destination 'shard1' for shard 'sh1'
deploy: DBCA primary creation job succeeded at destination 'shard2' for shard 'sh2'
deploy: deploying standby shard 'sh3' ...
deploy: network listener configuration successful at destination 'shard3'
deploy: starting DBCA at destination 'shard3' to create standby shard 'sh3' ...
deploy: deploying standby shard 'sh4' ...
deploy: network listener configuration successful at destination 'shard4'
deploy: starting DBCA at destination 'shard4' to create primary shard 'sh4' ...
deploy: waiting for 2 DBCA standby creation job(s) to complete...
deploy: waiting for 2 DBCA standby creation job(s) to complete...
deploy: DBCA standby creation job succeeded at destination 'shard3' for shard 'sh3'
deploy: DBCA standby creation job succeeded at destination 'shard4' for shard 'sh4'
deploy: requesting Data Guard configuration on shards via GSM
deploy: shards configured successfully
The operation completed successfullyデプロイ時の処理
DEPLOYを実行すると、いくつかの処理が発生します。
- GDSCTLは、シャード・カタログでシャード・データベース・トポロジ構成を調べるPL/SQLプロシージャをコールして、デプロイ可能なアンデプロイ状態のシャードが存在するかどうかを確認します。
CREATE SHARDメソッドを使用してシャードを作成する場合、シャード・カタログのPL/SQLコードによって、NETCAを実行する各シャード・ホストでリモート・スケジューラ・エージェント・ジョブがスケジュールされ、TNSリスナーが作成および起動されます。その後、2つ目のジョブがシャード・ホストでDBCAを実行するようにスケジュールされ、シャード・データベースが作成されます。スタンバイをデプロイする場合は、別の一連のNETCAジョブとDBCAジョブが実行され、プライマリ・データベースが正常に作成された後、それぞれのホストでスタンバイ・データベースが作成されます。- デプロイされるシャードについては、シャードのデータベース・パラメータを更新してシャードのトポロジ・メタデータを移入し、シャード・ディレクタに登録するためにシャードを送信するよう、シャード・カタログがシャード・ディレクタに向けてリクエストを送信します。
- Oracle Data Guardレプリケーションを使用しているときに、デプロイにスタンバイ・データベースが存在している場合、シャード・ディレクタは、プライマリ・シャードでPL/SQL APIをコールしてData Guard構成を作成するか、プライマリとスタンバイのセットに既存の構成を検証します。ファスト・スタート・フェイルオーバー機能が、すべてのシャードで有効化されます。さらに、シャード・ディレクタは、そのホストでData Guardオブザーバ・プロセスを起動して、Data Guard構成を監視します。
- すでにデプロイされたシャードが含まれている既存のシャード・データベースに新しいシャードを追加する場合(増分デプロイメント)は、以前に実行されたDDL文が新しいシャードで実行され、すべてのシャード間でアプリケーション・スキーマが同じになるようにします。
- 最後に、システム管理またはコンポジットのシャーディング方法を使用しているシャード・データベースに増分デプロイメントを実施する場合は、バックグラウンドでの自動チャンク移動がスケジュールされます。これは、現在の構成でチャンクの数がシャード間に均等に分散されるようにするためです。このプロセスは、
DEPLOYコマンドがGDSCTLに制御を戻した後で、GDSCTL CONFIG CHUNKSコマンドを使用することで監視できます。
デプロイメント成功時の表示
PDBおよびADD SHARDメソッドを使用したデプロイメントが正常に完了すると、Data Guardアクティブ・スタンバイ・シャードが使用されているときのCONFIG SHARDからの出力は、次のようになります。
GDSCTL> config shard
Name Shard Group Status State Region Availability
--------- ------------------- ------- -------- ------- ------------
cdb1_pdb1 shardgroup_primary Ok Deployed region1 ONLINE
cdb2_pdb1 shardgroup_standby Ok Deployed region2 READ ONLY
cdb3_pdb2 shardgroup_primary Ok Deployed region1 ONLINE
cdb4_pdb2 shardgroup_standby Ok Deployed region2 READ ONLY
CREATE SHARDメソッドを使用した場合、またはADD SHARDを非CDBとともに使用した場合、シャード名はシャード・データベースのdb_unique_name値になります。
マウント済で未オープンのスタンバイが使用されていると、シャード・ディレクタはマウント済データベースのステータスをチェックするためにログインできないため、出力は次のようになります。
GDSCTL> config shard
Name Shard Group Status State Region Availability
--------- ------------------ ------------- -------- ------- ------------
cdb1_pdb1 shardgroup_primary Ok Deployed region1 ONLINE
cdb2_pdb1 shardgroup_standby Uninitialized Deployed region2 -
cdb3_pdb2 shardgroup_primary Ok Deployed region1 ONLINE
cdb4_pdb2 shardgroup_standby Uninitialized Deployed region2 -
問題の修正方法
シャードの可用性にPENDINGが示されている場合は、トポロジ構成のADD INVITEDNODEおよびCONFIG VNCRに関連するすべてのステップが完了していることを確認します。完了していない場合は、そのステップを今すぐ完了してから、GDSCTL SYNC DATABASE -database shard_nameを実行することでシャードのデプロイメントを完了します。
CREATE SHARDメソッドを使用してシャードを構成に追加し、リモート・スケジューラ・エージェント・ジョブからGDSCTL DEPLOY中にNETCAまたはDBCAからのエラーが戻された場合は、次のステップを実行してエラーを解決し、デプロイメントを再試行します。
-
問題を解決します。
GDSCTL DEPLOYによって戻されたエラー・メッセージには、シャード・ホストで失敗したジョブの出力を表示するための十分な情報が含まれています。通常、シャード・ホストの
$ORACLE_BASE/cfgtoollogsに、NETCAまたはDBCA実行からのトレース・ファイルおよびログ・ファイルがあります。失敗の原因となった根本的な問題(不正なパラメータ、ホスト上のリソースの問題など)を解決します。 -
シャード・ホストをリセットします。
- デプロイの試行中に作成された実行中のTNSリスナーを停止します。
- デプロイの試行中に起動された実行中のシャード・データベースを停止します。
$ORACLE_HOME/network/admin/listener.oraを削除します- 失敗したシャード作成に関連付けられているすべてのファイルを
$ORACLE_BASE/oradataおよび$ORACLE_BASE/fast_recovery_areaから削除します
-
GDSCTL DEPLOYを再度実行します。
グローバル・データベース・サービスの作成と開始
シャードのデプロイが正常に完了して、適切なステータスであることを確認したら、アプリケーションからの着信接続リクエストを処理するためにシャードにグローバル・データベース・サービスを作成して、そのサービスを開始します。
たとえば、次の例のコマンドでは、構成内のプライマリ・シャードに読取り/書込みサービスが作成され、スタンバイ・シャードに読取り専用サービスが作成されます。これらのサービス名は、接続文字列で使用することで、アプリケーションから正しいシャードに適切にリクエストをルーティングできるようになります。
サービスが開始されたら、シャード・データベースはアプリケーション・スキーマの作成および着信クライアント接続リクエストの準備ができました。
例3-1 すべてのプライマリ・シャードで実行されるグローバル・サービスの追加と開始
次のコマンドでは、oltp_rw_srvcというグローバル・サービスを作成して開始します。このサービスは、クライアントがシャード・データベースに接続するために使用できます。oltp_rw_srvcサービスはプライマリ・シャードで読取り/書込みトランザクションを実行します。
GDSCTL> add service -service oltp_rw_srvc -role primary
GDSCTL> start service -service oltp_rw_srvc
例3-2 スタンバイ・シャードで実行する読取り専用のワークロードのためのグローバル・サービスの追加と開始
スタンバイ・シャードで読取り専用のワークロードを実行するために、oltp_ro_srvcグローバル・サービスが作成および開始されます。これは、スタンバイ・シャードが、読取り専用アクセスでオープンされるOracle Active Data Guardスタンバイ・シャードであることを前提としています。マウント済で未オープンのスタンバイは読取り専用接続に対応できません。そのようなスタンバイは、障害回復と高可用性のためにのみ存在します。
GDSCTL> add service -service oltp_ro_srvc -role physical_standby
GDSCTL> start service -service oltp_ro_srvc
例3-3 グローバル・サービスのステータスの確認
GDSCTL> config service
Name Network name Pool Started Preferred all
---- ------------ ---- ------- -------------
oltp_rw_srvc oltp_rw_srvc.orasdb.oracdbcloud orasdb Yes Yes
oltp_ro_srvc oltp_ro_srvc.orasdb.oracdbcloud orasdb Yes Yes
GDSCTL> status service
Service "oltp_rw_srvc.orasdb.oradbcloud" has 2 instance(s). Affinity: ANYWHERE
Instance "orasdb%1", name: "cdb1_pdb1", db: "cdb1_pdb1", region: "region1", status: ready.
Instance "orasdb%21", name: "cdb3_pdb2", db: "cdb3_pdb2", region: "region1", status: ready.
Service "oltp_ro_srvc.orasdb.oradbcloud" has 2 instance(s). Affinity: ANYWHERE
Instance "orasdb%11", name: "cdb2_pdb1", db: "cdb2_pdb1", region: "region2", status: ready.
Instance "orasdb%31", name: "cdb4_pdb2", db: "cdb4_pdb2", region: "region2", status: ready.
シャード・ステータスの確認
シャーディング構成のデプロイでDEPLOYステップを完了したら、各シャードの詳細なステータスを確認します。
GDSCTL CONFIG SHARDを実行して、各シャードの詳細なステータスを表示します。
GDSCTL> config shard -shard cdb1_pdb1
Name: cdb1_pdb1
Shard Group: shardgroup_primary
Status: Ok
State: Deployed
Region: region1
Connection string:shard_connect_string
SCAN address:
ONS remote port: 0
Disk Threshold, ms: 20
CPU Threshold, %: 75
Version: 19.0.0.0
Failed DDL:
DDL Error: ---
Management error:
Failed DDL id:
Availability: ONLINE
Rack:
Supported services
------------------------
Name Preferred Status
---- --------- ------
oltp_ro_srvc Yes Enabled
oltp_rw_srvc Yes Enabled シャード・データベースのデプロイの例
この例では、複数のレプリカを備えた一般的なシステム管理シャード・データベースのデプロイ方法を示します。このデプロイでは、高可用性のためにOracle Data Guardを使用します。この例のシャード・カタログおよびシャードはPDBであり、シャードはADD SHARDコマンドで構成に追加されます。
システム管理のシャード・データベースをデプロイするには、シャードグループおよびシャードを作成し、シャードとして使用するデータベースを作成および構成し、DEPLOYコマンドを実行してロールベースのグローバル・サービスを作成します。
システム管理のシャーディングでは、シャードにデータをマップする必要はありません。これは、コンシステント・ハッシュによるパーティション化を使用して、データがシャード間に自動的に分散されるためです。パーティション化アルゴリズムにより、データがシャード間に均一およびランダムに分散されます。システム管理のシャード・データベースの概念に関する詳細は、システム管理のシャーディングを参照してください。
シャード・データベース・トポロジの例
次に示すシステム管理シャード・データベース構成について検討します。この構成では、シャードグループ1にプライマリ・シャードが格納され、シャードグループ2と3にスタンバイ・レプリカが格納されます。
さらに、シャードグループ2のレプリカはOracle Active Data Guardのスタンバイ(読取り専用アクセスでオープンされたデータベース)であり、シャードグループ3のレプリカは未オープンのマウント済データベースだと仮定します。
表3-1 サンプルのシステム管理トポロジのホスト名
| トポロジ・オブジェクト | 説明 |
|---|---|
| シャード・カタログ・データベース |
すべてのシャード・データベース・トポロジに、シャード・カタログが必要です。この例では、シャード・カタログ・データベースに2つのスタンバイがあります(データ・センターごとに1つ)。 プライマリ
アクティブ・スタンバイ
スタンバイ
|
| リージョン |
この構成には2つのデータ・センターが関与しているため、それに対応する2つのリージョンがシャード・カタログ・データベースに作成されています。 データ・センター1
データ・センター2
|
| シャード・ディレクタ(グローバル・サービス・マネージャ) |
それぞれのリージョンには、そのデータ・センター内のホストで実行するシャード・ディレクタが必要です。この例は、リージョンごとに2つのシャード・ディレクタを使用する方法を示しており、これがベスト・プラクティスの推奨です。 データ・センター1
データ・センター2
|
| シャードグループ |
データ・センター1
データ・センター2
|
| シャード |
|
Oracle Shardingでの透過的データ暗号化の使用
Oracle Shardingでは透過的データ暗号化(TDE)がサポートされますが、TDEを有効にした状態でシャード・データベース内のチャンクを正常に移行できるように、すべてのシャードが暗号化された表領域に対する同じ暗号化キーを共有して使用する必要があります。
シャード・データベースは、複数の独立したデータベースと1つのカタログ・データベースで構成されます。特にシャード間でデータを移動するときにTDEが正しく機能するように、一定の制限が適用されます。データが暗号化されているときにシャード間のチャンク移動が正常に機能するためには、すべてのシャードで同じ暗号化キーを使用する必要があります。
これを実現するには、次の2つの方法があります。
-
シャード・カタログから暗号化キーを作成してエクスポートし、すべてのシャードに個々にキーをインポートしてアクティブ化します。
-
ウォレットを共有の場所に格納し、シャード・カタログおよびすべてのシャードで同じウォレットを使用します。
シャードDDLを有効にしたシャード・カタログで次のTDE文を実行すると、その操作がシャードに自動的に伝播されます。
-
alter system set encryption wallet open/close identified by password
-
alter system set encryption key
-
administer key management set keystore [open|close] identified by password
-
administer key management set key identified by password
-
administer key management use key identified by password
-
administer key management create key store identified by password
制限事項
Oracle ShardingでのTDEの使用には、次の制限事項が適用されます。
-
MOVE CHUNKが正常に機能するには、すべてのシャード・データベース・ホストが同じプラットフォームに存在する必要があります。 -
MOVE CHUNKでは、データ転送中にパフォーマンスに影響を及ぼす可能性がある圧縮を使用できません。 -
表領域レベルでの暗号化のみがサポートされます。特定の列に対する暗号化はサポートされません。
関連項目:
TDEの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
すべてのシャードに対する単一の暗号化キーの作成
シャード・データベース構成内のすべてのデータベースに単一の暗号化キーを伝播するには、シャード・カタログでマスター暗号化キーを作成し、ウォレットをエクスポートしてシャードにインポートし、キーをアクティブ化する必要があります。
ノート:
この手順は、キーストア・パスワードとウォレット・ディレクトリ・パスがシャード・カタログおよびすべてのシャードで同じであることを前提としています。異なるパスワードとディレクトリ・パスが必要な場合は、各シャードとシャード・カタログで、シャードDDLを無効化し、シャードの独自のパスワードとパスを使用して、すべてのコマンドを個別に発行する必要があります。
次のステップは、データの暗号化を実行する前に行う必要があります。
これで、すべてのシャードとシャード・カタログ・データベースで同じ暗号化キーがアクティブ化され、データの暗号化に使用する準備が完了しました。シャード・カタログで、(シャードDDLを有効にして)次のようなTDE DDLを発行できます。
-
暗号化された表領域および表領域セットを作成します。
-
暗号化された表領域を使用してシャード表を作成します。
-
暗号化された列を含むシャード表を作成します(制限があります)。
すべてのシャード上のキーIDがシャード・カタログ上のIDと一致していることを検証します。
SELECT KEY_ID FROM V$ENCRYPTION_KEYS
WHERE ACTIVATION_TIME =
(SELECT MAX(ACTIVATION_TIME) FROM V$ENCRYPTION_KEYS
WHERE ACTIVATING_DBID = (SELECT DBID FROM V$DATABASE));