1. Oracle Globally Distributed Databaseガイド
  2. Oracle Globally Distributed Databaseのデプロイ

4 Oracle Globally Distributed Databaseのデプロイ

シャード・データベースを作成および構成します。まずホストをプロビジョニングし、ソフトウェアの構成、データベースの設定、シャーディング・メタデータの作成、スキーマの作成の順に作業を進めます。このプロセスはデプロイと呼ばれます。

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

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

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

始める前に

シャード・データベースには、多種多様な構成とトポロジが使用できます。アプリケーションに特有のアーキテクチャとシステム要件に応じて、システムの設計時に複数の選択肢から選択できることもあります。デプロイを続行する前に、シャード・データベースのデプロイの計画について理解してください。

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

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

  1. コンポーネントを設定します。
  2. シャーディング・メタデータとアプリケーション・データの保管に必要なデータベースを作成します。
  3. GDSCTLコマンドライン・ユーティリティから、次のコマンドの一部またはすべてのコマンドを使用してシャーディング・トポロジを指定します(Oracle Globally Distributed Databaseトポロジの構成を参照)。
    • CREATE SHARDCATALOG
    • ADD GSM
    • START GSM
    • ADD SHARDGROUP
    • ADD SHARD
    • ADD INVITEDNODE
  4. DEPLOYを実行して、シャーディング・トポロジ構成をデプロイします(構成のデプロイを参照)。
  5. シャード・データベース内のシャードへのアクセスに必要なグローバル・サービスを追加します(「グローバル・データベース・サービスの作成と開始」を参照)。
  6. 各シャードのステータスを確認します(「シャード・ステータスの確認」)。

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

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

Oracle Globally Distributed Databaseデプロイの例では、一般的なリファレンス構成の具体的なデプロイ・シナリオについて説明しています。この項では、すべてのステップの完了後に、完全に機能するシャード・データベースを生成するために必要なすべてのコマンド例を示します。

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

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

特定のシャード・データベースには、様々なOracleソフトウェア・コンポーネント(Oracle Data Guard、Oracle Real Application Clusters (Oracle RAC)など)と、システム管理(自動)、ユーザー定義、コンポジット・シャーディングなどの様々なデータ分散方法を採用できます。

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

これらのトポロジ・オプションの詳細は、Oracle Globally Distributed Databaseのアーキテクチャと概念を参照してください。

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

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

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

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

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

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

ソフトウェアをインストールする前に、Oracle Globally Distributed Databaseのハードウェア、ネットワークおよびオペレーティング・システムの要件を確認してください。

  • Oracle Globally Distributed Databaseの実行時には、Oracle Database Enterprise Editionが必要です。

  • シャードのハードウェア要件とオペレーティング・システム要件は、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 Active Data Guardスタンバイ・シャード・カタログ・データベースをマルチシャード問合せコーディネータとして機能させることができます。マルチシャード問合せコーディネータの可用性とスケーラビリティを参照してください。

  • シャード・ディレクタ・ホスト。シャード・ディレクタ(グローバル・サービス・マネージャ)ソフトウェアは、個別のホストに配置することも、シャード・カタログと同じホストに配置することもできます。このシャーディング・システムのコンポーネントは、シャード構成の監視と構成に使用するネットワーク・リスナーと複数のバックグラウンド・プロセスで構成されます。カタログ・データベースと同じホストに配置する場合、シャード・ディレクタはカタログ・データベースとは別のOracleホームにインストールする必要があります。これは、インストール・パッケージがOracle Databaseに使用するものと異なるためです。

  • 複数のシャード・ディレクタ。高可用性のために、シャード・システム内で複数のシャード・ディレクタを実行することをお薦めします。追加のシャード・ディレクタは、専用のホストで実行することも、スタンバイ・シャード・カタログ・データベースを実行するホストで実行することもできます。

  • シャード。前述のホストに加えて、システム内で構成される各シャードは、それぞれ個別のホストで実行することも必要になります。このタスク用に選択したホストとその構成では、一般的なOracle Databaseホストと同じ方法で、それぞれのシャードにかかる負荷に応じたサイズを設定する必要があります。

  • シャード・スタンバイ(レプリカ)。ここでも、高可用性および障害時リカバリのために、Oracle Data Guardおよびすべてのシャード・データ用に作成されたレプリカを使用します。追加のホストは、こうしたレプリカまたはスタンバイ・データベースを実行するために必要になります。

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

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

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

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

Oracle Globally Distributed Database構成内のシャード・カタログとすべてのシャードには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

  • スタンバイ・カタログ・データベースがシャーディング構成の一部である場合、スタンバイ・カタログ・データベースに新しいデータベース・ファイルを自動的に作成するために、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内でロック解除してパスワードを割り当てる必要があります。このアカウントは、シャード・ディレクタのプロセスがシャード・カタログ・データベースに接続して、シャーディング・コマンドに応じて管理タスクを実行するために使用されます。

    GSMCATUSERは、コンテナ・データベースの共通ユーザーである点に注意してください。そのため、そのパスワードはCDB$ROOTおよびCDB内のすべてのPDBで同じになります。単一のCDB内にある複数のPDBが別々のシャーディング構成のカタログ・データベースとして使用されていると、それらすべてが同じGSMCATUSERのパスワードを共有するようなりセキュリティ上の問題が発生することがあります。この潜在的なセキュリティ上の問題を回避するには、各シャード・カタログをホストするように個別のCDBを構成します。CDB内の他のPDBが共通のGSMCATUSERパスワードを共有できないように、各CDBには単一のシャード・カタログPDBのみを含める必要があります。このようにして、複数のCDBにまたがって複数のシャード・カタログを構成し、それぞれに異なる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 Cloud Infrastructureツールからプロビジョニングできます。

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

GSMROOTUSERのロック解除

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.

GSMUSERのロック解除

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.

PDBの作成

シャード・データベースとして使用する(PDB)プラガブル・データベースを作成します。コンテナ・データベース(CDB)のルート・コンテナ(CDB$ROOT)をシャードとして使用することは、サポートされていません。

SPFILEの存在の確認

シャード・データベースでは、サーバー・パラメータ・ファイル(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

DB_FILESを適切に計算して設定

DB_FILESデータベース初期化パラメータは、シャード・データベースに必要なチャンクまたは表領域セット(あるいはその両方)の合計数以上に設定します。

シャーディング構成内の各データ・チャンクは、表領域パーティションとして実装され、専用のオペレーティング・システム・データ・ファイル内に存在します。そのため、データベース初期化パラメータDB_FILESは、システム内のチャンク数(CREATE SHARDCATALOGコマンドまたはADD SHARDSPACEコマンドで指定)や表領域セット数の合計以上にする必要があります。

Raftレプリケーション・シナリオのシャードに存在するチャンクの数は、シャードがリーダーまたはフォロワのいずれかであるすべてのチャンクの合計です。

特定のシャード上のシャーディング・オブジェクトに対して作成されたデータベース・ファイルの数を計算するには:

必要なシャード・データベース・ファイル = (SHARD DDLを使用して実行されたCREATE TABLESPACE SET SQL文の数) * (シャードに存在するチャンクの数+ 1)

DB_FILESは、シャーディング(前述)のPLUS非シャーディング・データベース・ファイル(system、sysauxなど)で使用されるファイル数以上に設定する必要があり、一般RDBMSコード(5)で必要とされる追加のPLUSです。したがって、次のようになります。

各シャードに必要なDB_FILES = (前述の計算で必要なシャード・データベース・ファイルの数) +デフォルト・データベース・ファイルの数(6) + 5

文字セットのチェック

シャード・データベースのデータベース文字セットと各国語文字セットは、シャード・カタログ・データベースとその他のすべてのシャード・データベースで使用されているものと同じにする必要があります。つまり、シャード・カタログまたはシャードのいずれかに挿入される可能性のある文字がすべて含まれている文字セットを選択する必要があるということです。

この要件は、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以上に設定

COMPATIBLE初期化パラメータを少なくとも12.2.0に設定する必要があります。 

$ sqlplus / as sysdba

SQL> alter session set container=shard_pdb_name;
SQL> show parameter compatible

NAME                   TYPE        VALUE
---------------------- ----------- -----------------
compatible             string      21.0.0

DB_CREATE_FILE_DESTの設定

シャーディング・チャンク管理インフラストラクチャで使用される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の作成

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

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

$ sqlplus / as sysdba	

SQL> create or replace directory DATA_PUMP_DIR as ‘/u01/app/oracle/oradata’;

Directory created.

SQL> alter session set container=shard_pdb_name;
SQL> grant read, write on directory DATA_PUMP_DIR to gsmadmin_internal;

Grant succeeded.

DB_FILE_NAME_CONVERTの設定

シャード間のファイル移動をサポートするには、データベース・パラメータの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 Net TNSリスナーの設定

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)。

スタンバイ・シャード・データベースを使用する場合:

フラッシュバック・データベースの有効化

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

$ sqlplus / as sysdba

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

FLASHBACK_ON
------------------
YES

FORCE LOGGINGの有効化

FORCE LOGGINGモードは、シャード・データベースがスタンバイ・シャード・データベースを使用する場合に有効にする必要があります。 

$ sqlplus / as sysdba

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

FORCE_LOGGING
---------------------------------------
YES

STANDBY_FILE_MANAGEMENTの設定

スタンバイ・シャード・データベースがシャーディング構成の一部である場合、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

Raftレプリケーションを使用する場合:

次のデータベース初期化パラメータを設定します。

  • FILESYSTEMIO_OPTIONS=setall - 非同期I/Oの有効化

  • UNDO_RETENTION=900 - これはデフォルトであり、自動的にチューニングされますが、このパラメータを明示的に非常に低い値に設定しないことをお薦めします。

シャード・データベースの検証

シャード・データベースの要件がすべて満たされていることを確認するには、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コマンドでシャーディング構成を追加することのみです。

Oracle Globally Distributed Databaseトポロジの構成

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

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

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

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

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

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

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

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

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

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というデフォルトのシャードグループも作成されます。

システム管理シャーディングを使用するレプリケーション(-repl)の場合は、Oracle Data Guard (DG)またはRaftレプリケーション(native)のいずれかを選択できます。

コンポジット・シャーディング方法

次の例は、コンポジット・シャード・データベース用のシャード・カタログ・メタデータの作成方法を示しています。ここでは、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 HELP CREATE SHARDCATALOGを実行してください。

レプリケーション設定

Oracle Data Guardは、任意のシャーディング方法とともに使用でき、-repl DGを使用してCREATE SHARDCATALOGコマンドで構成されます。

Raftレプリケーションにはもう少し計画が必要ですが、CREATE SHARDCATALOGコマンドで-repl nativeを指定して有効にすることもできます。追加の構成可能な属性については、Raftレプリケーションの構成および管理を参照してください。

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

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

GDSCTL> connect mysdbadmin/mysdbadmin_password@catalog_connect_string

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

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

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

  1. 次の例に示すように、シャード・ディレクタ(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リスナーと競合していないことを必ず確認してください。

  2. 追加のシャード・ディレクタがある場合は、それぞれのシャード・ディレクタ・ホストで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コマンドを使用してシャーディング構成に追加します。

  1. 次に示すように、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名になります。

  2. 構成内のシャードPDBを格納するすべてのCDBに対して、ADD CDBコマンドを繰り返します。
  3. すべてのCDBを追加したら、GDSCTL CONFIG CDBを実行してカタログ内のCDBのリストを表示します。
    GDSCTL> config cdb

シャードPDBの追加

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

  1. 次の例で示すように、対象のシャーディング方法に適した使用方法で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)を指定します。

    ノート:

    接続文字列にserver=dedicatedを設定することをお薦めします。

    ADD SHARDを実行すると、GDSCTLはSYSDGとしてGSMUSER/gsmuser_password@shard_connect_stringに接続し、シャードの設定を検証します。さらに、エラー・チェックのためにdbms_gsm_fix.validateShardを再実行し、db_unique_name_of_CDB_PDB_nameという命名規則を使用してシャード名(たとえばcdb1_pdb1)を作成します。

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

  2. 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アドレスをシャード・カタログ・メタデータに手動で追加します。

  1. 信頼できるホストのリストを表示します。

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

    GDSCTL> config vncr
  2. 構成内のすべてのホストからPingを実行して、ホスト名の解決が成功することを確認します。

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

    問題を解決するには、オペレーティング・システムのコマンドや設定を使用して、すべてのホスト名を解決できることを確認します。

  3. REMOVE INVITEDNODEコマンドを実行して、どのホストからも必要とされていないホスト名と解決できないホスト名を手動で削除します。
  4. ADD INVITEDNODEコマンドを実行して、シャード・ホストのすべてのホスト名とIPアドレスをシャード・カタログ・メタデータに手動で追加します。
    GDSCTL> add invitednode 127.0.0.1

チェック・フリーDB_FILES

シャード・データベースに必要なチャンクおよび表領域セットの数を作成するための十分な容量があることを確認するために、各シャードに十分な空きデータ・ファイルがあることを確認します。

チェック・フリーDB_FILESおよびパラメータ設定を確認するには: 

SQL> select count(*) from v$datafile;

  COUNT(*)
----------
XxxXX

SQL> show parameter db_files

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
db_files			     integer	 200

DB_FILES設定を計算する式は、シャード・データベースの作成を参照してください。

構成のデプロイ

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

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

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

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

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

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

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

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

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

例4-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.

シャード・ステータスの確認

Oracle Globally Distributed Databaseの構成デプロイでDEPLOYステップを完了したら、シャードの詳細なステータスを確認します

  1. 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: 23.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 Globally Distributed Databaseデプロイの例

この例では、高可用性のためにOracle Data Guardを使用して、複数のレプリカを備えた一般的なシステム管理Oracle Globally Distributed Databaseをデプロイする方法を示します。

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

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

Oracle Globally Distributed Databaseトポロジの例

次のシステム管理Oracle Globally Distributed Database構成について検討します。この構成では、シャードグループsg1にプライマリ・シャードが格納され、シャードグループsg2およびsg3にスタンバイ・レプリカが格納されます。

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


sharding-topology-system-managed.epsの説明が続く
図sharding-topology-system-managed.epsの説明

表4-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 Globally Distributed Databaseの例のデプロイ

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

  1. ホストcathost、cathost1、cathost2、gsmhost1、gsmhost2、およびホストshardhost1からshardhost9をプロビジョニングして構成します。
  2. ホストcathost、cathost1、cathost2およびshardhost1からshardhost9にOracle Databaseソフトウェアをインストールします。

    詳細は、「Oracle Databaseソフトウェアのインストール」を参照してください。

  3. ホストgsmhost1およびgsmhost2にシャード・ディレクタをインストールします。

    詳細は、「シャード・ディレクタ・ソフトウェアのインストール」を参照してください。

  4. シャード・カタログ・データベースを作成し、cathostでOracle TNSリスナーを起動します。

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

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

  5. ホスト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です。

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

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

    1. ホスト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

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

    2. ホスト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

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

    3. ホスト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の追加を参照してください。

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

      詳細は、「ホスト・メタデータの追加」を参照してください。

    5. GDSCTLからDEPLOYを実行して、シャード・データベースの構成を完了します。

      詳細は、構成のデプロイを参照してください。

    6. 読取り/書込みアクセスと読取り専用アクセスのサービスをシャード/データベースに追加して開始します。

      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

      詳細は、「グローバル・データベース・サービスの作成と開始」を参照してください。

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

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