シャード・データベースのデプロイ

シャード・データベースのデプロイの概要

Oracle Shardingには、シャード・データベースを自動的にデプロイする機能があり、これにはシャードとレプリカの両方が含まれます。

シャード・データベース管理者は、トポロジ(リージョン、シャード・ホスト、レプリケーション・テクノロジ)を定義し、GDSCTLコマンドライン・インタフェースを使用して宣言的に指定することでDEPLOYコマンドを起動します。

始める前に

シャード・データベースには、多種多様な構成とトポロジが使用できる点に注意してください。目的とするシャード・データベースには、多様なOracleソフトウェア・コンポーネント(Oracle Data Guard、Oracle GoldenGate、Oracle Real Application Clusters (Oracle RAC)など)と、各種のシャーディング手法(システム管理シャーディング、コンポジット・シャーディング、ユーザー定義シャーディング)を採用することがあります。

アプリケーションに特有のアーキテクチャとシステム要件に応じて、システムの設計時に複数の選択肢から選択できることもあります。様々なシャーディング手法と障害回復および高可用性のオプションの詳細は、「シャーディング方法」と「シャード・レベルの高可用性」を参照してください。

シャード・データベースのデプロイのロードマップ

大まかなデプロイメント・ステップは次のとおりです。

コンポーネントを設定します。
- 選択したシャーディング構成およびトポロジに必要になるホストをプロビジョニングおよび構成します(「ホストおよびオペレーティング・システムのプロビジョニングと構成」を参照)。
- 選択したカタログとシャード・ノードにOracle Databaseソフトウェアをインストールします(「Oracle Databaseソフトウェアのインストール」を参照)。
- シャード・ディレクタ・ノードにグローバル・サービス・マネージャ(GSM)ソフトウェアをインストールします(「シャード・ディレクタ・ソフトウェアのインストール」を参照)。
シャーディング・メタデータとアプリケーション・データの保管に必要なデータベースを作成します。
- シャード・カタログにするデータベースと、障害回復(DR)と高可用性(HA)に必要なレプリカを作成します(「シャード・カタログ・データベースの作成」を参照)。
- 構成内でシャードにするデータベースとDRおよびHAに必要なスタンバイ・データベースを作成します(「シャード・データベースの作成」を参照)。
GDSCTLコマンドライン・ユーティリティから、次のコマンドの一部またはすべてを使用してシャーディング・トポロジを指定します(「シャード・データベース・トポロジの構成」を参照)。
- CREATE SHARDCATALOG
- ADD GSM
- START GSM
- ADD SHARDSPACE
- ADD SHARDGROUP
- ADD SHARD
- ADD INVITEDNODE
DEPLOYを実行して、シャーディング・トポロジ構成をデプロイします(「シャーディング構成のデプロイ」を参照)。
シャード・データベース内のシャードへのアクセスに必要なグローバル・サービスを追加します(「グローバル・データベース・サービスの作成と開始」を参照)。
各シャードのステータスを確認します(「シャード・ステータスの確認」)。

シャード・データベース構成のデプロイが正常に完了すると、アプリケーションに必要なシャード・スキーマ・オブジェクトを作成できます。「シャード・データベース・スキーマの設計」を参照してください。

次のトピックでは、それぞれのデプロイメント・タスクについて、システムの各種コンポーネントに固有の要件とともに詳細に説明します。これらのトピックは、プロセスの各ステップごとの設定と構成についてのリファレンスとして利用できます。ただし、それらのみでは完全に機能するシャーディング構成は生成されません。これは、完全なシャーディング・シナリオを実装するのではなく、各ステップの要件のみを示しているためです。

「シャード・データベースのデプロイの例」では、典型的な参照構成の具体的なデプロイメント・シナリオについて説明しています。この項では、すべてのステップの完了後に、完全に機能するシャード・データベースを生成するために必要なすべてのコマンドの例を示します。

親トピック: シャード・データベースのデプロイ

シャード・データベースのデプロイの計画

シャード・データベース・トポロジ、レプリケーション方法、シャーディング手法など、シャード・データベースのデプロイを計画する際には、様々な決定を行う必要があります。

シャード・データベースには、多種多様な構成とトポロジが使用できます。目的とするシャード・データベースには、多様なOracleソフトウェア・コンポーネント(Oracle Data Guard、Oracle GoldenGate、Oracle Real Application Clusters (Oracle RAC)など)と、各種のシャーディング手法(システム管理シャーディング、コンポジット・シャーディング、ユーザー定義シャーディング)を採用することがあります。

選択したシャーディング方法(システム・シャーディング、コンポジット・シャーディングまたはユーザー定義シャーディング)に応じて、チャンクの数、シャードグループまたはシャード領域、リージョン、スタンバイ、マウント済データベースに対するオープン・データベースなどの考慮事項に関する決定によってトポロジ計画をさらに練り上げることができます。

シャード・データベース構成の計画
Oracle Sharding構成を計画するには、シャード・データベース構成を構成するオブジェクトを理解し、要件にあわせて最適に構成してデプロイできるようにする必要があります。
ホストおよびオペレーティング・システムのプロビジョニングと構成
ソフトウェアをインストールする前に、Oracle Shardingのハードウェア、ネットワークおよびオペレーティング・システムの要件を確認してください。
マルチシャード問合せコーディネータの可用性とスケーラビリティ
シャード・カタログのコンポーネントであるマルチシャード問合せコーディネータは、これらの推奨事項を使用してワークロードに対処するように高可用性を維持し、スケーリングできます。

親トピック: シャード・データベースのデプロイ

シャード・データベース構成の計画

Oracle Sharding構成を計画するには、シャード・データベース構成を構成するオブジェクトを理解し、要件にあわせて最適に構成してデプロイできるようにする必要があります。

シャード・データベース構成は、シャーディング方法、レプリケーション(高可用性)テクノロジ、シャード・データベースに用意するチャンクのデフォルト数、シャード・ディレクタの場所と数、シャード・データベース内のシャードグループ、シャード領域、リージョンおよびシャードの数、およびシャード・データベースへの接続に使用するグローバル・サービスで構成されます。これらのオブジェクトおよび概念は、シャード・データベース・スキーマの設計、シャーディング方法およびシャード・レベルの高可用性を参照してください。

Oracle Database Global Data Servicesのアーキテクチャ

Oracle Shardingの機能はOracle Database Global Data Servicesの機能に基づいて構築されているため、Oracle Shardingトポロジを計画するのに、Global Data Servicesのアーキテクチャを理解することが助けとなる場合があります。Global Data Servicesの概念は、Global Data Servicesの概要を参照してください。

親トピック: シャード・データベースのデプロイの計画

ホストおよびオペレーティング・システムのプロビジョニングと構成

ソフトウェアをインストールする前に、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など)を使用する必要があり、すべてのシャード・データのレプリカを作成します。追加のホストは、こうしたレプリカまたはスタンバイ・データベースを実行するために必要になります。

ホストの数と各ホストの容量要件を決定したら、選択した手法を使用して環境に適したハードウェア・リソースをプロビジョニングします。

ソフトウェアをインストールする前に、それぞれのホストが前述したポートを通じて相互に通信できることを確認します。シャーディング構成は、本質的に分散システムであるため、デプロイメント・プロセスの次のステップに進む前に、このホスト間およびホスト全体の接続を確認しておくことが重要です。ポート・アクセスが適切に設定されていないと、今後のコマンドのエラーの原因になります。

親トピック: シャード・データベースのデプロイの計画

マルチシャード問合せコーディネータの可用性とスケーラビリティ

シャード・カタログのコンポーネントであるマルチシャード問合せコーディネータは、これらの推奨事項を使用してワークロードに対処するように高可用性を維持し、スケーリングできます。

マルチシャード・コーディネータの可用性はプロキシ・ルーティング・ベースのワークロードに影響するため、ファスト・スタート・フェイルオーバーを有効にして最大可用性保護モード(データ損失のないフェイルオーバー)でData Guardを使用してコーディネータを保護することをお薦めします。コーディネータはさらなる可用性およびスケーラビリティのためにオプションでOracle RAC対応にすることができます。

マルチシャード問合せワークロードのスケーラビリティおよび可用性を向上させるために、読取り専用モードのOracle Active Data Guardスタンバイ・シャード・カタログ・データベースをマルチシャード問合せコーディネータとして機能させることができます。カタログ・データベースのアクティブなレプリカごとに、特別なコーディネータ・サービスGDS$COORDINATOR.cloud_name(cloud_nameは、GDSCTL CREATE SHARDCATALOGコマンドのconfignameパラメータに指定した値であり、デフォルト値はoradbcloud)が実行され、すべてのシャード・ディレクトリに登録されます。

クライアントは、任意のレプリカでこのサービスに接続し、マルチシャード問合せを実行することで、ランタイム・ロード・バランシングについてはシャード・ディレクタでマルチシャード問合せワークロードを分散し、Oracle Shardingフレームワークの中心的なコンポーネントであるプライマリ・シャード・カタログの負荷を軽減できます。

また、データベースのリージョンが設定され、クライアントが接続文字列でリージョンを指定すると、シャード・ディレクタは地域アフィニティに関する接続をルーティングします。

マルチシャード問合せコーディネータの可用性は、直接ルーティングを使用したワークロードに影響を与えません。

親トピック: シャード・データベースのデプロイの計画

Oracle Databaseソフトウェアのインストール

シャード・カタログ、データベース・シャードまたはレプリカをホストする各システムにOracle Databaseをインストールします。

Oracle Sharding構成内のシャード・カタログとすべてのシャードにはOracle Database Enterprise Editionが必須という要件がありますが、インストールとすべてのインストール後スクリプトの実行が成功していれば、それ以外に必要になる特別なインストールの考慮事項はありません。

オペレーティング・システム・ユーザーの構成の詳細は、対象プラットフォームのインストール・ガイド(https://docs.oracle.com/en/database/oracle/oracle-database/)を参照してください。

親トピック: シャード・データベースのデプロイ

シャード・ディレクタ・ソフトウェアのインストール

シャード・ディレクタをホストする各システムにグローバル・サービス・マネージャ・ソフトウェアをインストールします。

このソフトウェアのインストールは、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> 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> 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> alter session set container=catalog_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> 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 
```
Oracle提供のGSMCATUSERという名前のユーザー・アカウントは、シャード・カタログに指定した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.

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> 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リスナーは、どのような方法で作成および構成してもかまいません。データベースの作成方法によっては、ALTER SESSION SET CONTAINERを使用する必要のない、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つ以上のスタンバイ・シャード・カタログ・データベースも作成するようにしてください。シャーディングの観点からは、前述の要件がスタンバイ・データベースでも満たされていて、プライマリ・シャード・カタログ・データベースに対するすべての変更がスタンバイに確実に適用されていれば、その他に必要なシャーディング固有の構成ステップはありません。

親トピック: シャード・データベースのデプロイ

シャード・データベースの作成

シャードとして使用するデータベースは、それぞれのホストで作成する必要があります。

シャード・カタログ・データベースと同様に、シャード・データベースの作成方法やプロビジョニング方法はシャーディングの観点からすると重要ではありません。このデータベースは、Database Configuration Assistant (DBCA)で作成することも、SQL*Plusを使用して手動で作成することも、クラウド・インフラストラクチャ・ツールからプロビジョニングすることもできます。

次の特性を備えた各シェード・ホストでOracle Database Enterprise Editionインスタンスを実行していれば、シャードとして使用できます。

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)プラガブル・データベースを作成します。コンテナ・データベース(CDB)のルート・コンテナ(CDB$ROOT)をシャードとして使用することは、サポートされていません。
シャード・データベースでは、サーバー・パラメータ・ファイル(SPFILE)を使用する必要があります。SPFILEが必要になる理由は、シャーディング・インフラストラクチャが内部データベース・パラメータを使用して構成メタデータを保存し、そのデータはデータベースの起動操作と停止操作の間で永続している必要があるためです。
```
$ sqlplus / as sysdba

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> 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> alter session set container=shard_pdb_name;
SQL> show parameter compatible

NAME                   TYPE        VALUE
---------------------- ----------- -----------------
compatible             string      20.0.0

フラッシュ・データベースは、シャード・データベースがスタンバイ・シャード・データベースを使用する場合に有効にします。
```
$ sqlplus / as sysdba

SQL> alter session set container=shard_pdb_name;
SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------
YES
```
FORCE LOGGINGモードは、シャード・データベースがスタンバイ・シャード・データベースを使用する場合に有効にする必要があります。
```
$ sqlplus / as sysdba

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> 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> 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というディレクトリ・オブジェクトをPDB内に作成して、GSMADMIN_INTERNALアカウントからアクセスできるようにする必要があります。

GSMADMIN_INTERNALは、すべてのシャーディング・メタデータ表とPL/SQLパッケージを所有するOracle提供のアカウントです。ロックしたままにして、対話的なログインに使用されないようにしてください。シャーディング・メタデータとPL/SQLを所有することと、それに対するアクセスを制御することのみを目的としたものです。
```
$ sqlplus / as sysdba	

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> 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/
```
Oracle提供のGSMUSERという名前のユーザー・アカウントは、シャード・データベースとして指定したPDB内でロック解除してパスワードを割り当てる必要があります。さらに、このユーザーには、システム権限SYSDGおよびSYSBACKUPを付与する必要があります。

GSMUSERは、コンテナ・データベースの共通ユーザーである点に注意してください。そのため、そのパスワードは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> alter session set container=shard_pdb_name;
SQL> alter user gsmuser account unlock;

User altered.

SQL> grant SYSDG, SYSBACKUP to gsmuser;

Grant succeeded.
```
Oracle Net TNSリスナーを設定して選択したポート(デフォルトは1521)で実行します。これにより、シャードPDBに対する着信接続リクエストを処理できます。

TNSリスナーは、どのような方法で作成および構成してもかまいません。データベースの作成方法によっては、ALTER SESSION SET CONTAINERを使用する必要のない、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> 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コマンドでシャーディング構成を追加することのみです。

親トピック: シャード・データベースのデプロイ

シャード・データベース・トポロジの構成

シャード・カタログ用のデータベースとすべてのシャードを対応するTNSリスナーとともに構成すると、GDSCTLを使用してシャード・カタログ・データベースにシャーディング・メタデータを追加できるようになります。シャーディング・メタデータには、シャード・データベースに使用するトポロジを記述します。

シャード・データベース・トポロジは、シャーディング方法、レプリケーション(高可用性)テクノロジ、シャード・データベースに用意するチャンクのデフォルト数、シャード・ディレクタの場所と数、シャード・データベース内のシャードグループ、シャード領域、リージョンおよびシャードの数、およびシャード・データベースへの接続に使用するグローバル・サービスで構成されます。

『Oracle Database Global Data Services概要および管理ガイド』のGlobal Data Services Control Utility (GDSCTL)コマンド・リファレンスを手元に用意して、構成手順で使用するGDSCTLコマンドの使用方法とオプションの詳細を調べてください。

次に示す手順に従って、シャード・データベース・トポロジの構成を完了してください。

GDSCTLコマンドライン・インタフェースは、シャード・ディレクタ(グローバル・サービス・マネージャ)インストールの一部としてインストールされるため、コマンドはシャード・ディレクタ・ホストから実行してください。

シャード・カタログの作成
GDSCTL CREATE SHARDCATALOGコマンドは、シャード・データベース・トポロジについての情報を示すメタデータをシャード・カタログ・データベースに作成するために使用します。
シャード・ディレクタの追加と起動
構成にシャード・ディレクタを追加して起動します。シャード・ディレクタでは、GDSCTLコマンドなどのイベントに応じてシャーディング・システムの監視や、バックグラウンド・タスクを実行します。
シャード領域の追加(必要な場合)
コンポジット・シャーディングまたはユーザー定義シャーディングを使用するときに、目的のシャーディング・トポロジの達成にシャード領域の追加が必要な場合は、ADD SHARDSPACEコマンドを使用してシャード領域を追加します
シャードグループの追加(必要な場合)
シャード・データベース・トポロジにシステム管理またはコンポジットのシャーディング方法を使用する場合は、アプリケーション用に必要な追加のシャードグループを追加することもできます。
シャーディング・トポロジの検証
シャード・データベースに関する情報をカタログに追加する前に、シャーディング・トポロジが適切なことを確認します。その後で、各種のGDSCTL CONFIGコマンドを使用して作業を進めてください。
シャードCDBの追加
シャードPDBを格納するCDBは、ADD CDBコマンドを使用してシャーディング構成に追加します。
シャードPDBの追加
ADD SHARDコマンドは、シャードPDBの情報をシャード・カタログに追加するために使用します。追加した情報は、CONFIG SHARDコマンドで検証します。
ホスト・メタデータの追加
すべてのシャード・ホストのホスト名とIPアドレスをシャード・カタログに追加します。

親トピック: シャード・データベースのデプロイ

シャード・カタログの作成

GDSCTL CREATE SHARDCATALOGコマンドは、シャード・データベース・トポロジについての情報を示すメタデータをシャード・カタログ・データベースに作成するために使用します。

CREATE SHARDCATALOGを実行して、残りのシャーディング・メタデータが作成されると、いくつかのメタデータのプロパティはシャード・データベース全体を最初から再作成しないと変更できなくなります。こうしたものには、シャーディング方法(システム管理、コンポジット、ユーザー定義)、レプリケーション・テクノロジ(Oracle Data Guard、Oracle GoldenGate)、データベース内のチャンクのデフォルト数などがあります。コマンドに使用可能なオプションとそのデフォルト値の完全なリストは、GDSCTLのリファレンス・ドキュメントを参照してください。

コマンドの使用方法は、GDSCTLのドキュメントを参照するか、GDSCTL HELP CREATE SHARDCATALOGを実行してください。

シャード・カタログ接続文字列

CREATE SHARDCATALOGコマンドを実行すると、GDSCTLは指定されたユーザー名と接続文字列でシャード・カタログ・データベースに接続します。

高可用性または障害回復のために、シャード・カタログ・データベースにスタンバイ・データベースが関連付けられているときには、接続文字列(次の例のcatalog_connect_string)で、すべてのプライマリ・データベースおよびスタンバイ・データベースを指定する必要があります。接続文字列にスタンバイ・データベースを含めていないと、シャード・ディレクタのプロセスはプライマリ・シャード・カタログが使用不可のときにスタンバイに接続できなくなります。

catalog_connect_stringでは、シャード・カタログ・データベースのPDBを指定します。CDB$ROOTは指定しないでください。

次に、簡潔な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)
    )
  )

計画したシャーディング・トポロジに適した設定で、CREATE SHARDCATALOGを実行します。
システム管理のシャーディング方法

次の例では、システム管理シャーディング構成用のシャード・データベース・メタデータが作成されます。この構成には、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 
```

シャード・カタログへの今後の接続

GDSCTLは、シャード・カタログ管理者の資格証明をローカル・ホストのウォレットに保管します。ただし、次回以降の別のホストでのGDSCTLセッションでは、次に示すようにGDSCTL CONNECTコマンドを使用して、管理タスクを実行するために明示的にシャード・カタログに接続することが必要になる場合があります。

GDSCTL> connect mysdbadmin/mysdbadmin_password@catalog_connect_string

親トピック: シャード・データベース・トポロジの構成

シャード・ディレクタの追加と起動

構成にシャード・ディレクタを追加して起動します。シャード・ディレクタでは、GDSCTLコマンドなどのイベントに応じてシャーディング・システムの監視や、バックグラウンド・タスクを実行します。

次のコマンドは、シャード・ディレクタのプロセスを実行するホストで実行する必要があります。これは、シャード・カタログ・ホストまたはシャード・ディレクタ・プロセスの専用ホストのどちらかになります。

次の例に示すように、シャード・ディレクタ(GSM)を追加して起動します。
```
GDSCTL> connect mysdbadmin/mysdbadmin_password@catalog_connect_string
GDSCTL> add gsm -gsm sharddirector1 -catalog catalog_connect_string -pwd gsmcatuser_password
GDSCTL> start gsm -gsm sharddirector1
```
-gsmパラメータの値は、今後のGDSCTLコマンドで、このシャード・ディレクタを参照するために使用する名前です。-catalogパラメータと-pwdパラメータの値は、シャード・カタログ・データベースの作成時に使用したものと同じにする必要があります。

パラメータの-listener、-localons、および-remoteonsは、GDSCTLのリファレンスで説明されているように、それぞれのポート番号1522、6123、および6234をオーバーライドするために使用します。使用するポート番号は、デフォルトかユーザー定義化にかかわらず、ホストで使用可能なことと、実行中の別のソフトウェアやOracleリスナーと競合していないことを必ず確認してください。
追加のシャード・ディレクタがある場合は、それぞれのシャード・ディレクタ・ホストでADD GSMコマンドとSTART GSMコマンドを繰り返します。
シャード・ディレクタの名前(この例では、sharddirector1)は、シャード・ディレクタごとに適切な名前に置き換えます。

複数のシャード・ディレクタを使用する場合は、CREATE SHARDCATALOGコマンドで、それらのための複数のリージョンを作成しておく必要があります。また、ADD REGIONを実行することで後からリージョンを追加することもできます。

シャード・ディレクタごとのリージョンは、次に示すように、ADD GSMごとの-regionパラメータで指定します。
```
GDSCTL> add gsm -gsm sharddirector2 -catalog catalog_connect_string -pwd gsmcatuser_password -region dc2
```

今後のGDSCTLセッションでは、管理するシャード・ディレクタの明示的な指定が必要になることがあります。デフォルトのGSMORAシャード・ディレクタを示すエラー・メッセージが表示され場合は、次に示すように、GDSCTL SET GSMを実行してから作業を進めてください。

GDSCTL> set gsm -gsm sharddirector1

親トピック: シャード・データベース・トポロジの構成

シャード領域の追加(必要な場合)

コンポジット・シャーディングまたはユーザー定義シャーディングを使用するときに、目的のシャーディング・トポロジの達成にシャード領域の追加が必要な場合は、ADD SHARDSPACEコマンドを使用してシャード領域を追加します

次に示すように、ADD SHARDSPACEを実行します。
```
GDSCTL> add shardspace -shardspace shardspace2 
```
デフォルトでは、ADD SHARDSPACEコマンドは、CREATE SHARDCATALOGコマンドで使用した-chunksと-protectmodeの値を継承します。チャンクの数とData Guardの保護モードは、ADD SHARDSPACEに-chunksパラメータと-protectmodeパラメータを使用することでシャード領域ごとに指定できます。

親トピック: シャード・データベース・トポロジの構成

シャードグループの追加(必要な場合)

シャード・データベース・トポロジにシステム管理またはコンポジットのシャーディング方法を使用する場合は、アプリケーション用に必要な追加のシャードグループを追加することもできます。

それぞれのシャード領域には、少なくとも1つのプライマリ・シャードグループを含める必要があり、任意の数またはタイプのスタンバイ・シャードグループを含めることができます。シャードグループは、ユーザー定義のシャーディング方法では使用しません。

ADD SHARDGROUPを実行して、構成にシャードグループを追加します。
```
GDSCTL> add shardgroup -shardgroup shardgroup_primary -shardspace shardspace1
 -deploy_as primary -region region1
GDSCTL> add shardgroup -shardgroup shardgroup_standby -shardspace shardspace1
 -deploy_as active_standby -region region2
```
ADD SHARDGROUPを実行するときに-deploy_asパラメータを使用すると、シャードグループの3つのタイプprimary、standby (マウント済、未オープン)、およびactive_standby (オープン、問合せに使用可能)を指定できます(デフォルトは、standbyです)。

この後でシャードグループに追加したシャードは、そのシャードグループの-deploy_as設定に対応するモードでオープンする必要があります。たとえば、プライマリ・シャードグループの場合は読取り/書込み、スタンバイ・シャードグループの場合はマウント済、またはアクティブ・スタンバイ・シャードグループの場合は読取り専用を適用します。

シャードのデプロイ後、シャードの現在のモードはシャード・ディレクタによって監視され、その後のスイッチオーバー操作やフェイルオーバー操作によっては同じシャードグループ内に異なるオープン・モードのシャードが存在する可能性や予測などがシャード・カタログに通知されます。

親トピック: シャード・データベース・トポロジの構成

シャーディング・トポロジの検証

シャード・データベースに関する情報をカタログに追加する前に、シャーディング・トポロジが適切なことを確認します。その後で、各種のGDSCTL CONFIGコマンドを使用して作業を進めてください。

シャードを追加してデプロイした後では、シャード・カタログ・メタデータの大部分が変更できなくなります。そのため、この時点で構成を検証することが重要なタスクになります。

GDSCTL CONFIGを実行して、全体的な構成情報を表示します。

GDSCTL> config

Regions
------------------------
region1                       
region2                       

GSMs
------------------------
sharddirector1                          
sharddirector2                          

Sharded Database
------------------------
orasdb                     

Databases
------------------------ 

Shard Groups
------------------------
shardgroup_primary                         
shardgroup_standby                         

Shard spaces
------------------------
shardspaceora                         

Services
------------------------

GDSCTL pending requests
------------------------
Command                   Object                  Status
-------                   ------                  ------

Global properties
------------------------
Name: oradbcloud
Master GSM: sharddirector1
DDL sequence #: 0

シャード領域やシャードグループなどのシャード・カタログ・オブジェクトに関する詳細な情報は、各種のGDSCTL CONFIGコマンドを使用して表示できます。様々なGDSCTL CONFIGコマンドの完全なリストについては、GDSCTLのリファレンス・ドキュメントを参照するか、GDSCTL HELPを実行してください。

親トピック: シャード・データベース・トポロジの構成

シャードCDBの追加

シャードPDBを格納するCDBは、ADD CDBコマンドを使用してシャーディング構成に追加します。

次に示すように、ADD CDBコマンドを実行します。
```
GDSCTL> add cdb -connect cdb_connect_string -pwd gsmrootuser_password
```
このコマンドにより、GDSCTLはSYSDGとしてGSMROOTUSER/gsmrootuser_password@cdb_connect_stringに接続し、設定を検証して、CDBのDB_UNIQUE_NAMEを取得します。これが、シャード・カタログでのCDB名になります。
構成内のシャードPDBを格納するすべてのCDBに対して、ADD CDBコマンドを繰り返します。
すべてのCDBを追加したら、GDSCTL CONFIG CDBを実行してカタログ内のCDBのリストを表示します。
```
GDSCTL> config cdb
```

親トピック: シャード・データベース・トポロジの構成

シャードPDBの追加

ADD SHARDコマンドは、シャードPDBの情報をシャード・カタログに追加するために使用します。追加した情報は、CONFIG SHARDコマンドで検証します。

次の例で示すように、対象のシャーディング方法に適した使用方法でADD SHARDを実行します。
システム管理またはコンポジットのシャーディングの場合は、次に示すパラメータでADD SHARDを実行します。
```
GDSCTL> add shard -connect shard_connect_string -pwd gsmuser_password 
-shardgroup shardgroup_name -cdb cdb_name
```
ユーザー定義のシャーディングの場合は、わずかにコマンドの使用方法が異なります。
```
GDSCTL> add shard -connect shard_connect_string -pwd gsmuser_password 
-shardspace shardspace_name -deploy_as db_mode -cdb cdb_name
```
-cdbパラメータでは、シャードPDBが存在しているCDBの名前を指定します。-shardgroupまたは-shardspaceでは、シャーディング・トポロジでのシャードの場所を指定します。また、-deploy_asでは、シャードのオープン・モード(primary、standby、active_standby)を指定します。
ADD SHARDを実行すると、GDSCTLはSYSDGとしてGSMUSER/gsmuser_password@shard_connect_stringに接続し、シャードの設定を検証します。さらに、エラー・チェックのためにdbms_gsm_fix.validateShardを再実行し、db_unique_name_of_CDB_PDB_nameという命名規則を使用してシャード名(例: cdb1_pdb1)を作成します。

最後に、シャードについての情報を示すメタデータがシャード・カタログに追加されます。

GDSCTL CONFIG SHARDを実行して、シャード・カタログにあるシャード・メタデータを表示します。

GDSCTL> config shard
Name      Shard Group          Status    State    Region    Availability
--------- -------------------  ------    -----    ------    ------------
cdb1_pdb1 shardgroup_primary   U         none     region1   -
cdb2_pdb1 shardgroup_standby   U         none     region2   -
cdb3_pdb2 shardgroup_primary   U         none     region1   -
cdb4_pdb2 shardgroup_standby   U         none     region2   -

「Status」の値は、"アンデプロイ"のUになります。「State」と「Availability」は、DEPLOYコマンドの実行が正常に完了するまではnoneと-になります。

親トピック: シャード・データベース・トポロジの構成

ホスト・メタデータの追加

すべてのシャード・ホストのホスト名とIPアドレスをシャード・カタログに追加します。

デプロイメント・プロセスの一環として、シャード・ディレクタはシャードと通信して、シャード・ディレクタのTNSリスナー・プロセスに登録するように指示します。このリスナー・プロセスは、信頼できるソースからの着信登録リクエストのみを受け入れ、不明なホストからの登録リクエストを拒否します。

シャード・ホストに複数のホスト名またはネットワーク・インタフェースが割り当てられている場合、シャード・ディレクタへの着信登録リクエストは、ADD SHARDの実行時に自動的に追加されていなかったホストから送信される可能性があります。この場合、その登録リクエストは拒否され、シャードは正常にデプロイされなくなります。この問題について目視できる現象は、DEPLOYの完了後に、CONFIG SHARDがシャードの「Availability」にPENDINGを示すことです。

この問題を回避するために、GDSCTL ADD INVITEDNODEコマンドを使用して、シャード・ホストのすべてのホスト名とIPアドレスをシャード・カタログ・メタデータに手動で追加します。

信頼できるホストのリストを表示します。
デフォルトでは、ADD SHARDコマンドは、シャード・カタログ・メタデータにシャード・ホストのデフォルト・ホスト名を追加します。そのため、そのホストからシャード・ディレクタへの登録リクエストがすべて受け入れられるようになります。信頼できるホストのリストは、GDSCTL CONFIG VNCRコマンドを実行することで表示できます。
```
GDSCTL> config vncr
```
構成内のすべてのホストからPingを実行して、ホスト名の解決が成功することを確認します。

CONFIG VNCRの出力にリストされたすべてのホストは、その他のトポロジ内のすべてのホストから名前でアクセスできる必要があります。シャード、シャード・カタログ、およびシャード・ディレクタのホストからpingコマンドを使用して、リストされているすべてのホスト名のホスト名解決が成功することを確認します。

問題を解決するには、オペレーティング・システムのコマンドや設定を使用して、すべてのホスト名を解決できることを確認します。
REMOVE INVITEDNODEコマンドを実行して、どのホストからも必要とされていないホスト名と解決できないホスト名を手動で削除します。
ADD INVITEDNODEコマンドを実行して、シャード・ホストのすべてのホスト名とIPアドレスをシャード・カタログ・メタデータに手動で追加します。
```
GDSCTL> add invitednode 127.0.0.1
```

親トピック: シャード・データベース・トポロジの構成

シャーディング構成のデプロイ

GDSCTLコマンドでシャード・データベース・トポロジの構成を完了したら、GDSCTL DEPLOYコマンドを実行してシャード・データベース構成をデプロイします。

GDSCTL DEPLOYコマンドを実行すると、出力は次のようになります。

GDSCTL> deploy
deploy: examining configuration...
deploy: requesting Data Guard configuration on shards via GSM
deploy: shards configured successfully
The operation completed successfully

デプロイ時の処理

DEPLOYを実行すると、いくつかの処理が発生します。

GDSCTLは、シャード・カタログでシャード・データベース・トポロジ構成を調べるPL/SQLプロシージャをコールして、デプロイ可能なアンデプロイ状態のシャードが存在するかどうかを確認します。
デプロイする必要があるシャードについては、シャード・カタログがシャード・ディレクタに向けてシャードのデータベース・パラメータを更新して、シャードのトポロジ・メタデータを移入するようにリクエストを送信します。また、シャード・ディレクタに登録するようにシャードに指示します。
Oracle Data Guardレプリケーションを使用しているときに、デプロイにスタンバイ・データベースが存在している場合、シャード・ディレクタは、プライマリ・シャードでPL/SQL APIをコールしてData Guard構成を作成するか、プライマリとスタンバイのセットに既存の構成を検証します。ファスト・スタート・フェイルオーバー機能が、すべてのシャードで有効化されます。さらに、シャード・ディレクタは、そのホストでData Guardオブザーバ・プロセスを起動して、Data Guard構成を監視します。
すでにデプロイされたシャードが含まれている既存のシャード・データベースに新しいシャードを追加する場合(増分デプロイメント)は、以前に実行されたDDL文が新しいシャードで実行され、すべてのシャード間でアプリケーション・スキーマが同じになるようにします。
最後に、システム管理またはコンポジットのシャーディング方法を使用しているシャード・データベースに増分デプロイメントを実施する場合は、バックグラウンドでの自動チャンク移動がスケジュールされます。これは、現在の構成でチャンクの数がシャード間に均等に分散されるようにするためです。このプロセスは、DEPLOYコマンドがGDSCTLに制御を戻した後で、GDSCTL CONFIG CHUNKSコマンドを使用することで監視できます。

デプロイメント成功時の表示

デプロイメントが正常に完了すると、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

マウント済で未オープンのスタンバイが使用されていると、シャード・ディレクタはマウント済データベースのステータスをチェックするためにログインできないため、出力は次のようになります。

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を実行することでシャードのデプロイメントを完了します。

親トピック: シャード・データベースのデプロイ

グローバル・データベース・サービスの作成と開始

シャードのデプロイが正常に完了して、適切なステータスになっていることを確認したら、アプリケーションからの着信接続リクエストを処理するためにシャードにグローバル・データベース・サービスを作成して、そのサービスを開始します。

たとえば、次の例のコマンドでは、構成内のプライマリ・シャードに読取り/書込みサービスが作成され、スタンバイ・シャードに読取り専用サービスが作成されます。これらのサービス名は、接続文字列で使用することで、アプリケーションから正しいシャードに適切にリクエストをルーティングできるようになります。

例6-1 すべてのプライマリ・シャードで実行されるグローバル・サービスの追加と開始

次のコマンドでは、oltp_rw_srvcというグローバル・サービスを作成して開始します。このサービスは、クライアントがシャード・データベースに接続するために使用できます。oltp_rw_srvcサービスはプライマリ・シャードで読取り/書込みトランザクションを実行します。

GDSCTL> add service -service oltp_rw_srvc -role primary
GDSCTL> start service -service oltp_rw_srvc

例6-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

例6-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: 20.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を使用します。

システム管理のシャード・データベースをデプロイするには、シャードグループおよびシャードを作成し、シャードとして使用するデータベースを作成および構成し、DEPLOYコマンドを実行してロールベースのグローバル・サービスを作成します。

システム管理のシャーディングでは、シャードにデータをマップする必要はありません。これは、コンシステント・ハッシュによるパーティション化を使用して、データがシャード間に自動的に分散されるためです。パーティション化アルゴリズムにより、データがシャード間に均一およびランダムに分散されます。システム管理のシャード・データベースの概念に関する詳細は、システム管理のシャーディングを参照してください。

シャード・データベース・トポロジの例
次に示すシステム管理シャード・データベース構成について検討します。この構成では、シャードグループ1にプライマリ・シャードが格納され、シャードグループ2と3にスタンバイ・レプリカが格納されます。
サンプル・シャード・データベースのデプロイ
次のステップを実行して、サンプルのシステム管理シャード・データベースをデプロイします。このデータベースは、高可用性のためにOracle Data Guardを使用して、複数のレプリカを備えています。

親トピック: シャード・データベースのデプロイ

シャード・データベース・トポロジの例

次に示すシステム管理シャード・データベース構成について検討します。この構成では、シャードグループ1にプライマリ・シャードが格納され、シャードグループ2と3にスタンバイ・レプリカが格納されます。

さらに、シャードグループ2のレプリカはOracle Active Data Guardのスタンバイ(読取り専用アクセスでオープンされたデータベース)であり、シャードグループ3のレプリカは未オープンのマウント済データベースだと仮定します。

図admin_3v_136a.epsの説明

表6-1 サンプルのシステム管理トポロジのホスト名

トポロジ・オブジェクト	説明
シャード・カタログ・データベース	すべてのシャード・データベース・トポロジに、シャード・カタログが必要です。この例では、シャード・カタログ・データベースに2つのスタンバイがあります(データ・センターごとに1つ)。プライマリデータ・センター= 1 ホスト名= cathost DB_UNIQUE_NAME = catcdb PDB名= catpdb 接続サービス名= catpdb アクティブ・スタンバイデータ・センター= 1 ホスト名= cathost1 スタンバイデータ・センター= 2 ホスト名= cathost2
リージョン	この構成には2つのデータ・センターが関与しているため、それに対応する2つのリージョンがシャード・カタログ・データベースに作成されています。データ・センター1 リージョン名= dc1 データ・センター2 リージョン名= dc2
シャード・ディレクタ(グローバル・サービス・マネージャ)	それぞれのリージョンには、そのデータ・センター内のホストで実行するシャード・ディレクタが必要です。データ・センター1 シャード・ディレクタ・ホスト名= gsmhost1 シャード・ディレクタ名= gsm1 データ・センター2 シャード・ディレクタ・ホスト名= gsmhost2 シャード・ディレクタ名= gsm2
シャードグループ	データ・センター1 sg1 sg2 データ・センター2 sg3
シャード	ホスト名= shardhost1, …, shardhost9 DB_UNIQUE_NAME = cdb1, …, cdb9 PDB名= pdb1, pdb2, pdb3 スタンバイ・レプリカのPDB名は、それらに対応するプライマリのPDB名と同じになります

親トピック: シャード・データベースのデプロイの例

サンプル・シャード・データベースのデプロイ

次のステップを実行して、サンプルのシステム管理シャード・データベースをデプロイします。このデータベースは、高可用性のためにOracle Data Guardを使用して、複数のレプリカを備えています。

ホストcathost、cathost1、cathost2、gsmhost1、gsmhost2、およびホストshardhost1からshardhost9をプロビジョニングして構成します。

詳細は、「ホストおよびオペレーティング・システムのプロビジョニングと構成」を参照してください。
ホストcathost、cathost1、cathost2およびshardhost1からshardhost9にOracle Databaseソフトウェアをインストールします。

詳細は、「Oracle Databaseソフトウェアのインストール」を参照してください。
ホストgsmhost1およびgsmhost2にシャード・ディレクタをインストールします。

詳細は、「シャード・ディレクタ・ソフトウェアのインストール」を参照してください。
シャード・カタログ・データベースを作成し、cathostでOracle TNSリスナーを起動します。

さらに、カタログのスタンバイ・レプリカをcathost1およびcathost2に作成して、それらのスタンバイにプライマリ・カタログへの変更が適用されていることを確認します。

詳細は、「シャード・カタログ・データベースの作成」を参照してください。
ホストshardhost1、shardhost2およびshardhost3に、シャード・データを格納する3つのプライマリ・データベースを作成します。
それに対応するレプリカを作成します。その場所と名前は、次のとおりです。
- shardhost4 (cdb4)およびshardhost7 (cdb7)に、shardhost1 (cdb1/pdb1)のレプリカ
- shardhost5 (cdb5)およびshardhost8 (cdb8)に、shardhost2 (cdb2/pdb2)のレプリカ
- shardhost6 (cdb6)およびshardhost9 (cdb9)に、shardhost3 (cdb3/pdb3)のレプリカ
9つのコンテナ・データベース(CDB)のdb_unique_nameは、cdb1からcdb9にする必要があります。そこにあるPDBの名前は、3つのプライマリおよびレプリカでpdb1、pdb2およびpdb3にする必要があります。

CDBのサービス名はcdb1からcdb9にする必要があり、そのPDBシャードのサービス名はpdb1、pdb2、およびpdb3です。

詳細は、「シャード・データベースの作成」を参照してください。

すべてのポート番号がデフォルトであるとすると、シャード・データベース・トポロジを構成するには、次のGDSCTLコマンドを発行します。このとき、ドメインとパスワードは適切な値に置き換えます。

ホストgsmhost1で、GDSCTLから次のコマンドを実行します。

create shardcatalog -database cathost.example.com:1521/catpdb.example.com -user mydbsadmin/mydbsadmin_password -region dc1,dc2

add gsm -gsm gsm1 -region dc1 -catalog cathost.example.com:1521/catpdb.example.com -pwd gsmcatuser_password
start gsm -gsm gsm1

詳細は、「シャード・カタログの作成」および「シャード・ディレクタの追加と起動」を参照してください。

ホストgsmhost2で、GDSCTLから次のコマンドを実行します。

connect mydbsadmin/mydbsadmin_password@cathost.example.com:1521/catpdb.example.com
add gsm -gsm gsm2 -region dc2 -catalog cathost.example.com:1521/catpdb.example.com -pwd gsmcatuser_password
start gsm -gsm gsm2

詳細は、「シャード・ディレクタの追加と起動」を参照してください。

ホストgsmhost1に戻って、GDSCTLから次のコマンドを実行して、シャード・データベースの設定を完了します。

add shardgroup -shardgroup sg1 -deploy_as primary -region dc1
add shardgroup -shardgroup sg2 -deploy_as active_standby -region dc1
add shardgroup -shardgroup sg3 -deploy_as standby -region dc2
add cdb -connect shardhost1.example.com:1521/cdb1.example.com -pwd gsmrootuser_password
add cdb -connect shardhost2.example.com:1521/cdb2.example.com -pwd gsmrootuser_password

shardhost3からshardhost9およびcdb3からcdb9でADD CDBコマンドを繰り返してから、次のコマンドを実行します。

add shard -connect shardhost1.example.com:1521/pdb1.example.com -pwd gsmuser_password -shardgroup sg1 -cdb cdb1
add shard -connect shardhost2.example.com:1521/pdb2.example.com -pwd gsmuser_password -shardgroup sg1 -cdb cdb2
add shard -connect shardhost3.example.com:1521/pdb3.example.com -pwd gsmuser_password -shardgroup sg1 -cdb cdb3
add shard -connect shardhost4.example.com:1521/pdb1.example.com -pwd gsmuser_password -shardgroup sg2 -cdb cdb4
add shard -connect shardhost5.example.com:1521/pdb2.example.com -pwd gsmuser_password -shardgroup sg2 -cdb cdb5
add shard -connect shardhost6.example.com:1521/pdb3.example.com -pwd gsmuser_password -shardgroup sg2 -cdb cdb6
add shard -connect shardhost7.example.com:1521/pdb1.example.com -pwd gsmuser_password -shardgroup sg3 -cdb cdb7
add shard -connect shardhost8.example.com:1521/pdb2.example.com -pwd gsmuser_password -shardgroup sg3 -cdb cdb8
add shard -connect shardhost9.example.com:1521/pdb3.example.com -pwd gsmuser_password -shardgroup sg3 -cdb cdb9

詳細は、「シャードグループの追加(必要な場合)」、「シャードCDBの追加」、および「シャードPDBの追加」を参照してください。

コマンドCONFIG VNCRとADD INVITEDNODEを使用して、VNCRエントリのすべてが有効でデプロイメントが成功するために不足がないことを確認します。

詳細は、「ホスト・メタデータの追加」を参照してください。
GDSCTLからDEPLOYを実行して、シャード・データベースの構成を完了します。

詳細は、「シャーディング構成のデプロイ」を参照してください。
読取り/書込みアクセスと読取り専用アクセスのサービスをシャード/データベースに追加して開始します。
```
add service -service oltp_rw_srvc -role primary
start service -service oltp_rw_srvc
add service -service oltp_ro_srvc -role physical_standby
start service -service oltp_ro_srvc
```
詳細は、「グローバル・データベース・サービスの作成と開始」を参照してください。

コマンドGDSCL CONFIG、CONFIG SHARD、およびCONFIG SERVICEを使用すると、シャードとサービスのすべてがオンラインになっていて実行されていることを確認できます。

詳細は、「シャード・ステータスの確認」を参照してください。

親トピック: シャード・データベースのデプロイの例

自動デプロイメント・スクリプト

Oracle Shardingのツールには、シャード・データベースのデプロイ操作を自動化し、さらに簡略化するためのTerraform、KubernetesおよびAnsibleのスクリプトが含まれています。

Terraformによるシャード・データベースのデプロイ
Oracle Shardingのツールには、Oracle Cloud Infrastructureとオンプレミスの両システムでシャード・データベースのデプロイを自動化するためのTerraformモジュールおよびスクリプトが含まれています。

親トピック: シャード・データベースのデプロイ

Terraformによるシャード・データベースのデプロイ

Oracle Shardingのツールには、Oracle Cloud Infrastructureとオンプレミスの両システムでシャード・データベースのデプロイを自動化するためのTerraformモジュールおよびスクリプトが含まれています。

Terraformモジュールおよびスクリプトでは、シャード・ディレクタ、シャード・カタログおよびシャードを含む完全なシャード・データベース・インフラストラクチャを作成して構成します。このスクリプトには、シャード・データの高可用性および障害時リカバリを実現するためにレプリケーションにOracle Data Guardを使用し、スタンバイ・シャードおよびシャード・カタログをデプロイするためのオプションも用意されています。

設定プロセスの一環として、Terraformバイナリをインストールし、Oracle Shardingシャード・ディレクタ・インストール・パッケージをダウンロードし、またオンプレミス・デプロイメントの場合には、Oracle Databaseインストール・ファイルをダウンロードします。

次の場所で、ターゲット・システムのTerraformベースのシャード・データベースのデプロイに関する手順およびダウンロードを参照してください。

Oracle Cloud Infrastructure: https://github.com/oracle/db-sharding/tree/master/deployment-with-terraform/sdb-terraform-oci。
オンプレミス: https://github.com/oracle/db-sharding/tree/master/deployment-with-terraform/sdb-terraform-onprem

親トピック: 自動デプロイメント・スクリプト

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では、データ転送中にパフォーマンスに影響を及ぼす可能性がある圧縮を使用できません。
表領域レベルでの暗号化のみがサポートされます。特定の列に対する暗号化はサポートされません。

すべてのシャードに対する単一の暗号化キーの作成
シャード・データベース構成内のすべてのデータベースに単一の暗号化キーを伝播するには、シャード・カタログでマスター暗号化キーを作成し、ウォレットをエクスポートしてシャードにインポートし、キーをアクティブ化する必要があります。

すべてのシャードに対する単一の暗号化キーの作成

シャード・データベース構成内のすべてのデータベースに単一の暗号化キーを伝播するには、シャード・カタログでマスター暗号化キーを作成し、ウォレットをエクスポートしてシャードにインポートし、キーをアクティブ化する必要があります。

ノート:

この手順は、キーストア・パスワードとウォレット・ディレクトリ・パスがシャード・カタログおよびすべてのシャードで同じであることを前提としています。異なるパスワードとディレクトリ・パスが必要な場合は、各シャードとシャード・カタログで、シャードDDLを無効化し、シャードの独自のパスワードとパスを使用して、すべてのコマンドを個別に発行する必要があります。

次のステップは、データの暗号化を実行する前に行う必要があります。

シャード・カタログで暗号化キーを作成します。
シャードDDLを有効にして、次の文を発行します。
```
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE wallet_directory_path IDENTIFIED BY
 keystore_password;
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password;
```
ウォレットのオープンおよびクローズ・コマンドをカタログから一元的に発行する場合は、keystore_passwordが同じである必要があります。

ノート:

ウォレット・ディレクトリ・パスは、対応するsqlnet.oraのENCRYPTION_WALLET_LOCATIONと一致する必要があります。

ENCRYPTION_WALLET_LOCATIONパラメータは非推奨です。かわりに、WALLET_ROOT静的初期化パラメータおよびTDE_CONFIGURATION動的初期化パラメータを使用することをお薦めします。

シャードDDLを無効にして、次の文を発行します。
```
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY keystore_password WITH BACKUP;
```
シャード・カタログ・データベースのウォレットに暗号化キーが作成され、アクティブ化されます。

DDLを有効にしてこの文を発行すると、各シャードのウォレットにもカタログのキーとは異なる暗号化キーが作成されます。データ移動を正常に実行するには、各シャード上の異なる暗号化キーを使用しないでください。

シャード・カタログのキーストアからマスター・キーの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));

シャードDDLを無効にして、カタログの暗号化キーを含むウォレットをエクスポートします。

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET secret_phrase TO
 wallet_export_file IDENTIFIED BY keystore_password;

ウォレット・ファイルを各シャード・ホストの対応するウォレット・エクスポート・ファイルの場所に物理的にコピーするか、すべてのシャードがアクセスできる共有ディスクに格納します。

シャードDDLを無効にして、各シャードにログオンし、キーを含むウォレットをインポートします。

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password;
ADMINISTER KEY MANAGEMENT IMPORT ENCRYPTION KEYS WITH SECRET secret_phrase FROM
 wallet_export_file IDENTIFIED BY keystore_password WITH BACKUP;

シャード・データベースを再起動します。

すべてのシャード上のキーをアクティブ化します。

カタログでシャードDDLを有効にして、次のコマンドを実行します。

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password;
ADMINISTER KEY MANAGEMENT USE KEY master_key_id IDENTIFIED BY keystore_password
 WITH BACKUP;

これで、すべてのシャードとシャード・カタログ・データベースで同じ暗号化キーがアクティブ化され、データの暗号化に使用する準備が完了しました。シャード・カタログで、(シャード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));

親トピック: Oracle Shardingでの透過的データ暗号化の使用