日本語PDF

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

シャード・データベースのデプロイでは、必要なソフトウェア・コンポーネントのインストール、カタログ、ロール、シャード・データベースの作成、高可用性のためのレプリケーションの構成、およびシャード・データベースのスキーマの作成のための前提条件と手順について説明します。

次の各項で、シャード・データベースのデプロイに必要な概念とタスクについて説明します。

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

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

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

始める前に

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

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

シャード作成メソッドの選択

シャード構成をデプロイするとき、シャードの追加に使用できる2つの異なるGDSCTLコマンド(ADD SHARDおよびCREATE SHARD)があります。

シャーディング・トポロジの構成を開始する前に、使用するシャード作成メソッドを決定します。これはこの決定が構成ステップの一部に影響するためです。

ADD SHARDメソッドとCREATE SHARDメソッドの違いは、構成手順で必要に応じて説明します。

ADD SHARDメソッド

GDSCTL ADD SHARDコマンドは、Oracle Sharding構成にシャードを追加する場合に使用できます。このコマンドを使用する場合、デプロイメント時にシャードになるOracleデータベースを作成するのはユーザーの役割です。データベースがOracle Sharding構成に含めるための前提条件を満たすかぎり、どのメソッドを使用してデータベースを作成しても構いません。

ADD SHARDメソッドを使用する利点のいくつかを次に示します。

  • データベースの作成に使用するプロセスを完全に制御できます。
  • データベース・パラメータ、ネーミングおよび記憶域の場所は簡単にカスタマイズできます。
  • PDBシャードと非CDBシャードの両方がサポートされます。
  • シャード・ホストで構成するOracleソフトウェアが少なくなります。
  • GDSCTLコマンドを実行する前にシャード・データベースが作成されるため、デプロイメント・プロセスはそれほど複雑ではありません。

CREATE SHARDメソッド

GDSCTL CREATE SHARDコマンドは、Oracle Sharding構成でシャードを作成する場合に使用できます。CREATE SHARDを使用すると、シャード・カタログはOracleリモート・スケジューラ・エージェントを利用して、各シャード・ホスト上でDatabase Configuration Assistant (DBCA)をリモートで実行し、データベースを作成します。このメソッドではPDBがサポートされないため、追加されるシャード・データベースは非CDBである必要があります。

CREATE SHARDメソッドを使用する利点のいくつかを次に示します。

  • データベース管理者以外のためのシャード・データベースを作成しやすくなります。
  • 現行方式で標準がない場合、新しいデータベースをプロビジョニングする標準的な方法が提供されます。
  • CREATE SHARDで作成されたデータベースは、データベースに対してSQL文を実行したり、データベース・パラメータを調整しなくても、Oracle Sharding用に自動的に正しく構成されます。
  • スタンバイ・データベースを自動的に作成できます。

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

このロードマップに従って、ホストの設定、必要なソフトウェアのインストールおよびシャード・データベースの構成とデプロイを行います。

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

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

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

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

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

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

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

  • Oracle Database Enterprise Editionは、Oracleシャード・データベースの実行時に必要になります。

  • シャードのハードウェア要件とオペレーティング・システム要件は、Oracle Databaseの要件と同じです。これらの要件の詳細は、Oracle Databaseのインストール・ドキュメントを参照してください。

  • シャード・カタログおよびシャード・ディレクタのハードウェア要件とオペレーティング・システム要件は、グローバル・データ・サービス・カタログおよびグローバル・サービス・マネージャの要件と同じです。これらの要件の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください。

  • ネットワーク要件は低遅延GigEです。

  • ポート通信の要件は次のとおりです。

    • すべてのシャードがすべてのシャード・ディレクタのリスナーとONSポートに到達できる必要があります。シャード・ディレクタのリスナー・ポートおよびONSポートが、アプリケーション/クライアント層、すべてのシャード、シャード・カタログおよび他のすべてのシャード・ディレクタに対して開かれている必要があります。

      シャード・ディレクタのデフォルトのリスナー・ポートは、1522です。デフォルトのONSポートは、ほとんどのプラットフォームで6123 (ローカルONS)および6234 (リモートONS)です。

    • すべてのシャードがシャード・カタログ(プライマリとスタンバイの両方)のTNSリスナー・ポート(デフォルトは1521)に到達できる必要があります。

    • 各シャードのTNSリスナー・ポートがすべてのシャード・ディレクタおよびシャード・カタログに対して開かれている必要があります。

    • 前述したポート番号のすべては、デプロイメント構成時に変更できます。ただし、使用するポート番号は、ホスト・ソフトウェアの設定前に決定しておく必要があります。

  • ホスト名の解決は、すべてのシャード・カタログ、シャード、およびシャード・ディレクタ・ホストで成功する必要があります。オペレーティング・システムのコマンド(pingなど)は、シャード・データベース構成コマンドで提示されたホスト名の指定時に、特定のホストから別のホストに向けて成功する必要があります。

ホスト・システムの数とサイズ設定

目的とする構成によっては、次のホストも必要になることがあります。

  • シャード・カタログ・ホスト。シャード・カタログ・ホストでは、シャード・カタログとして機能するOracle Databaseを実行します。このデータベースには、少量のシャーディング・トポロジ・メタデータと、アプリケーション用に作成した重複表を格納します。また、このデータベースは、シャーディングに対応していないアプリケーションのクロスシャード問合せおよびサービスの接続のための問合せコーディネータとしても機能します。一般に、このデータベースのトランザクション・ワークロードとサイズは、特に大きなものにはなりません。

  • シャード・カタログ・データベースのスタンバイ(レプリカ)。プライマリ・シャード・カタログ・データベースのレプリカまたはスタンバイは、少なくとも1つ以上のホストに格納することをお薦めします。このホストは、プライマリ・カタログ・ホストの障害発生時に必要になります。また、このホストは、スタンバイ・データベースとして機能すると同時に、クロスシャード問合せの問合せコーディネータになるように構成することもできます。

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

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

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

  • シャード・スタンバイ(レプリカ)。前述したように、高可用性と障害回復のために、レプリケーション・テクノロジ(Oracle Data GuardやOracle Golden Gateなど)を使用する必要があり、すべてのシャード・データのレプリカを作成します。追加のホストは、こうしたレプリカまたはスタンバイ・データベースを実行するために必要になります。

    ノート:

    Oracle ShardingのOracle GoldenGateレプリケーション・サポート高可用性は、Oracle Database 21cでは非推奨です。

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

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

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

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

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

CREATE SHARDメソッドを使用してシャードを構成に追加する場合は、各シャード・ホストにリモート・スケジューラ・エージェント・ソフトウェアもインストールする必要があります。エージェントは、シャード・カタログ・ホストにインストールする必要はありません。手順は、リモート・ホストでのスケジューラ・エージェントのインストールと構成に関する項を参照してください。

また、CREATE SHARDメソッドでは、各シャード・ホストに2つのディレクトリ($ORACLE_BASE/oradataおよび$ORACLE_BASE/fast_recovery_area)を作成する必要があります。Oracle Databaseソフトウェアの所有者としてシャード・ホストにログインしている間に、これら2つのディレクトリを作成します。権限は、シャード・データベースのデータ・ファイルを保持するディレクトリと同じに設定する必要があり、通常、ソフトウェア所有者のみがフル・アクセスできます。

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

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

このソフトウェアのインストールは、Oracle Databaseインストールとは異なる点に注意してください。シャード・ディレクタ・ソフトウェアをシャード・カタログ・データベースと同じホストに配置することにした場合は、個別のOracleホームにインストールする必要があります。

グローバル・サービス・マネージャ・ソフトウェアのインストールの詳細は、『Oracle Database Global Data Services概要および管理ガイド』を参照してください。

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

次の情報とガイドラインを使用して、シャード・カタログ・データベースを作成してください。

シャード・カタログ・データベースには、少量のシャーディング・トポロジ・メタデータと、シャード・アプリケーションで使用するために作成するすべての重複表を格納します。カタログ・データベースは、複数のシャードからデータを選択して集計するクロスシャード問合せを実行するための問合せコーディネータとしても機能します。

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

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

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

  • シャード・カタログ・データベースでは、サーバー・パラメータ・ファイル(SPFILE)を使用する必要があります。これが必要になる理由は、シャーディング・インフラストラクチャが内部データベース・パラメータを使用して構成メタデータを保存し、そのデータはデータベースの起動操作と停止操作の間で永続している必要があるためです。

    $ sqlplus / as sysdba
    
    SQL> show parameter spfile
    
    NAME     TYPE      VALUE
    -------- --------- ------------------------------------
    spfile   string    /u01/app/oracle/dbs/spfilecat.ora 
  • データベース文字セットと各国語文字セットは、すべてのシャード・データベースで使用されるため、同じにする必要があります。つまり、シャード・カタログまたはシャードのいずれかに挿入される可能性のあるすべての文字が含まれている文字セットを選択する必要があるということです。

    この要件は、MOVE CHUNKコマンドのシャーディング時に、トランスポータブル表領域をシャード間で移動するためにOracle Data Pumpが内部的に使用されることから発生します。このメカニズムの要件は、ソースと宛先で文字セットが一致していることです。

    $ sqlplus / as sysdba
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=catalog_pdb_name;
    
    SQL> select * from nls_database_parameters 
      2  where parameter like '%CHARACTERSET';
    
    PARAMETER                                VALUE
    ---------------------------------------- --------------------
    NLS_NCHAR_CHARACTERSET                   AL16UTF16
    NLS_CHARACTERSET                         WE8DEC
    
  • シャード・カタログ・データベースは、データベース・リンクによってシャードに接続するマルチシャード問合せを実行できるため、データベース初期化パラメータ OPEN_LINKSおよびOPEN_LINKS_PER_INSTANCEの値は、シャード・データベース構成に含まれるシャードの数以上にする必要があります。

    $ sqlplus / as sysdba	
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=catalog_pdb_name;
    
    SQL> show parameter open_links
    
    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- ------------
    open_links                           integer     20
    open_links_per_instance              integer     20
    
  • データベース初期化パラメータDB_FILESは、システム内のチャンクや表領域の合計数以上に設定します。

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

    $ sqlplus / as sysdba	
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=catalog_pdb_name;
    
    SQL> show parameter db_files
    
    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- ------------
    db_files                             integer     1024
    
  • CREATE SHARDを使用してシャードをシャーディング構成に追加する場合は、SHARED_SERVERSおよびDISPATCHERSデータベース初期化パラメータを設定して、リモート・スケジューラ・エージェントがXDB接続を介してカタログに接続できるようにする必要があります。ADD SHARDを使用する場合、これは必要ありません。

    具体的には、シャード・ホストで実行されているリモート・スケジューラ・エージェント・プロセスからシャード・カタログへの共有サーバー接続を許可するには、SHARED_SERVERSを0 (ゼロ)より大きくする必要があります。また、DISPATCHERSの値には、Oracle SIDの値に基づいてXDBのサービスが含まれている必要があります。

    $ sqlplus / as sysdba	
    
    SQL> show parameter shared_servers
    
    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- ------------
    shared_servers                       integer     5
    
    SQL> show parameter dispatchers
    
    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- ----------------------
    Dispatchers                          string      (PROTOCOL=TCP), (PROTO
                                                     COL=TCP)(SERVICE=mysid
                                                     XDB)
    

    パラメータ値を適切に設定したら、ALTER SYSTEM REGISTERコマンドを実行して、XDBサービスが着信接続リクエストで使用できることを確認します。

  • シャーディング・チャンク管理インフラストラクチャで使用されるOracle Managed Filesをサポートするには、データベース・パラメータDB_CREATE_FILE_DESTに有効な値が設定されている必要があります。

    この場所は、チャンクの移動操作(MOVE CHUNKや自動リバランスなど)の実行中に、チャンク・データを保持するトランスポータブル表領域を保存するために使用されます。さらに、『Oracle Database管理者ガイド』Oracle Managed Filesの使用に関する項で説明されているファイルも、Oracle Managed Filesを使用するOracleデータベースの慣例に従って、この場所に保存されます。

    $ sqlplus / as sysdba	
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=catalog_pdb_name;
    
    SQL> show parameter db_create_file_dest
    
    NAME                  TYPE      VALUE
    --------------------- --------- -----------------------------
    db_create_file_dest   string    /u01/app/oracle/oradata 
  • Oracle提供のGSMCATUSERという名前のユーザー・アカウントは、シャード・カタログに指定したレガシー・データベースまたはPDB内でロック解除してパスワードを割り当てる必要があります。このアカウントは、シャード・ディレクタのプロセスがシャード・カタログ・データベースに接続して、シャーディング・コマンドに応じて管理タスクを実行するために使用されます。

    PDBをシャード・カタログとして使用している場合、GSMCATUSERはコンテナ・データベースの共通ユーザーであることに注意してください。そのため、そのパスワードはCDB$ROOTおよびCDB内のすべてのPDBで同じになります。単一のCDB内にある複数のPDBが別々のシャーディング構成のカタログ・データベースとして使用されていると、それらすべてが同じGSMCATUSERのパスワードを共有するようなりセキュリティ上の問題が発生することがあります。これを回避するために、CDBごとにシャード・カタログPDBを1つのみホストして、それ以外のPDBではGSMCATUSERアカウントのロックを解除しないようにします。

    指定したパスワードは、この後のシャーディング・トポロジの作成時に発行するADD GSMコマンドで使用します。これは、シャード・ディレクタによってOracleウォレットに安全に保管され、必要なときにのみ復号化されるため、再指定が必要になることはありません。

    MODIFY GSMコマンドは、その後にシャード・カタログ・データベースでパスワードが変更されたときに、保管したパスワードを更新するために使用できます。

    $ sqlplus / as sysdba
    
    SQL> alter user gsmcatuser account unlock;
    
    User altered.
    
    SQL> alter user gsmcatuser identified by gsmcatuser_password;
    
    User altered.

    PDBをシャード・カタログとして使用している場合、次のコマンドも実行します。

    SQL> alter session set container=catalog_pdb_name;
    SQL> alter user gsmcatuser account unlock;
    
    User altered.
  • シャード・カタログの管理者アカウントは、シャード・カタログとして指定したレガシー・データベースまたはPDB内で作成し、パスワードを割り当てて、権限を付与する必要があります。

    このアカウントは、シャード・カタログ・データベース内のシャーディング・メタデータに対する管理者アカウントです。管理者がシャード・データベース・トポロジに変更を加えるなどの管理タスクを実行する必要があるときに、GDSCTLユーティリティを使用してシャード・カタログにアクセスするために使用します。

    GDSCTLは、GDSCTLコマンドの実行時に、このユーザーとしてシャード・カタログ・データベースに接続します。指定したユーザー名とパスワードは、この後のCREATE SHARDCATALOGコマンドで使用します。前述したGSMCATUSERと同様に、ユーザー名とパスワードは今後の使用に備えてOracleウォレットに安全に保存されます。保存された資格証明は、GDSCTLから明示的にCONNECTコマンドを発行してウォレット内の値をリセットすることで更新できます。

    $ sqlplus / as sysdba
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=catalog_pdb_name;
    
    SQL> create user mysdbadmin identified by mysdbadmin_password;
    
    User created.
    
    SQL> grant gsmadmin_role to mysdbadmin;
    
    Grant succeeded.
    
  • Oracle Net TNSリスナーを設定して選択したポート(デフォルトは1521)で実行します。これにより、シャード・カタログのレガシー・データベースまたはPDBに対する着信接続リクエストを処理できます。

    TNSリスナーは、どのような方法で作成および構成してもかまいません。シャード・カタログがPDBの場合、データベースの作成方法によっては、ALTER SESSION SET CONTAINERを使用する必要のない、PDBへの直接接続リクエストを許可できるデータベース・サービスを明示的に作成することが必要になる場合もあります。

    シャード・カタログにPDBを使用している場合、リスナーが正しく構成されていることを確認するには、前の手順で新しく作成したmysdbadminアカウントと適切な接続文字列を使用して、次の操作を実行します。LSNRCTL SERVICESを実行すると、このリスナーを使用して現在利用可能なすべてのサービスが示されます。

    $ sqlplus mysdbadmin/mysdbadmin_password@catalog_connect_string
    
    SQL> show con_name
    
    CON_NAME
    -----------------------
    catalog_pdb_name
    

    接続を確認したら、前述のcatalog_connect_stringを記録しておきます。これは、この後の構成プロセスのGDSCTL CREATE SHARDCATALOGコマンドで使用します。一般に、これはhost:port/service_nameの形式になります(例: cathost.example.com:1521/catalog_pdb.example.com)。

前述の要件がすべて満たされていると、新しく作成したデータベースはGDSCTL CREATE SHARDCATALOGコマンドの実行可能対象になります。

高可用性と障害回復のために、1つ以上のスタンバイ・シャード・カタログ・データベースも作成するようにしてください。シャーディングの観点からは、前述の要件がスタンバイ・データベースでも満たされていて、プライマリ・シャード・カタログ・データベースに対するすべての変更がスタンバイに確実に適用されていれば、その他に必要なシャーディング固有の構成ステップはありません。

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

CREATE SHARDメソッドを使用してシャードを構成に追加する場合、このトピックはCREATE SHARDに適用されないためスキップします。それ以外の場合は、シャードとして使用するデータベースをそれぞれのホストで作成する必要があります。

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

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

  • シャードがCDB内のPDBである場合、Oracle提供のGSMROOTUSERという名前のユーザー・アカウントは、シャードに指定したデータベースのCDB$ROOT内でロック解除してパスワードを割り当てる必要があります。さらに、このユーザーには、システム権限SYSDGおよびSYSBACKUPを付与する必要があります。

    GSMROOTUSERアカウントは、GDSCTLおよびシャード・ディレクタのプロセスがシャード・データベースに接続して、シャーディング・コマンドに応じて管理タスクを実行するするために使用されます。指定したパスワードは、シャーディング・トポロジの作成時にGDSCTLによって発行されるADD CDBコマンドで使用されます。また、シャード・ディレクタでシャード・データベースにOracle Data Guardを構成するためにDEPLOYコマンドを実行するときにも使用されます(必要な場合)。ユーザーによる再指定が必要なることはありません。GDSCTLとシャード・ディレクタによってOracleウォレット内に安全に保管され、必要なときにのみ復号化されます。MODIFY CDBコマンドは、その後にシャード・データベースでパスワードが変更されたときに、保管したパスワードを更新するために使用できます。

    $ sqlplus / as sysdba
    
    SQL> alter user gsmrootuser account unlock;
    
    User altered.
    
    SQL> alter user gsmrootuser identified by gsmrootuser_password;
    
    User altered.
    
    SQL> grant SYSDG, SYSBACKUP to gsmrootuser;
    
    Grant succeeded.
    
  • シャードがPDBである場合、シャード・データベースとして使用するPDBを作成します。CDBのルート・コンテナ(CDB$ROOT)をシャードとして使用することは、サポートされていません。

  • シャード・データベースでは、サーバー・パラメータ・ファイル(SPFILE)を使用する必要があります。SPFILEが必要になる理由は、シャーディング・インフラストラクチャが内部データベース・パラメータを使用して構成メタデータを保存し、そのデータはデータベースの起動操作と停止操作の間で永続している必要があるためです。

    $ sqlplus / as sysdba
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=shard_pdb_name;
    
    SQL> show parameter spfile
    
    NAME     TYPE      VALUE
    -------- --------- ------------------------------------
    spfile   string    /u01/app/oracle/dbs/spfileshard.ora
    
  • シャード・データベースのデータベース文字セットと各国語文字セットは、シャード・カタログ・データベースとその他のすべてのシャード・データベースで使用されているものと同じにする必要があります。つまり、シャード・カタログまたはシャードのいずれかに挿入される可能性のある文字がすべて含まれている文字セットを選択する必要があるということです。

    この要件は、MOVE CHUNKコマンドのシャーディング時に、トランスポータブル表領域をシャード間で移動するためにOracle Data Pumpが内部的に使用されることから発生します。このメカニズムの要件は、ソースと宛先で文字セットが一致していることです。

    $ sqlplus / as sysdba
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=shard_pdb_name;
    
    SQL> select * from nls_database_parameters 
      2  where parameter like '%CHARACTERSET';
    
    PARAMETER                                VALUE
    ---------------------------------------- --------------------
    NLS_NCHAR_CHARACTERSET                   AL16UTF16
    NLS_CHARACTERSET                         WE8DEC
    
  • COMPATIBLE初期化パラメータを少なくとも12.2.0に設定する必要があります。

    $ sqlplus / as sysdba
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=shard_pdb_name;
    
    SQL> show parameter compatible
    
    NAME                   TYPE        VALUE
    ---------------------- ----------- -----------------
    compatible             string      20.0.0
    
  • フラッシュ・データベースは、シャード・データベースがスタンバイ・シャード・データベースを使用する場合に有効にします。

    $ sqlplus / as sysdba
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=shard_pdb_name;
    
    SQL> select flashback_on from v$database;
    
    FLASHBACK_ON
    ------------------
    YES
    
  • FORCE LOGGINGモードは、シャード・データベースがスタンバイ・シャード・データベースを使用する場合に有効にする必要があります。

    $ sqlplus / as sysdba
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=shard_pdb_name;
    
    SQL> select force_logging from v$database;
    
    FORCE_LOGGING
    ---------------------------------------
    YES
    
  • データベース初期化パラメータDB_FILESは、システム内のチャンクや表領域の合計数以上に設定します。

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

    $ sqlplus / as sysdba	
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=shard_pdb_name;
    
    SQL> show parameter db_files
    
    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- ------------
    db_files                             integer     1024
    
  • シャーディング・チャンク管理インフラストラクチャで使用されるOracle Managed Filesをサポートするには、データベース・パラメータのDB_CREATE_FILE_DESTに有効な値が設定されている必要があります。

    この場所は、チャンクの移動操作(MOVE CHUNKや自動リバランスなど)の実行中に、チャンク・データを保持するトランスポータブル表領域を保存するために使用されます。さらに、『Oracle Database管理者ガイド』のOracle Managed Filesの使用に関する項で説明されているファイルも、Oracle Managed Filesを使用するOracleデータベースの慣例に従って、この場所に保存されます。

    $ sqlplus / as sysdba	
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=shard_pdb_name;
    
    SQL> show parameter db_create_file_dest
    
    NAME                  TYPE      VALUE
    --------------------- --------- -----------------------------
    db_create_file_dest   string    /u01/app/oracle/oradata
    
  • DATA_PUMP_DIRというディレクトリ・オブジェクトをシャード・データベース内に作成して、GSMADMIN_INTERNALアカウントからアクセスできるようにする必要があります。

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

    $ sqlplus / as sysdba	
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=shard_pdb_name;
    
    SQL> create or replace directory DATA_PUMP_DIR as ‘/u01/app/oracle/oradata’;
    
    Directory created.
    
    SQL> grant read, write on directory DATA_PUMP_DIR to gsmadmin_internal;
    
    Grant succeeded.
    
  • シャード間のファイル移動をサポートするには、データベース・パラメータのDB_FILE_NAME_CONVERTに有効な値が設定されている必要があります。この場所は、一般的な非シャーディング・データベースのように、スタンバイ・データベースが使用中のときに使用され、チャンク移動操作中にも使用できます。通常のファイル・システムの場所の場合は、このパラメータの末尾をスラッシュ(/)にすることをお薦めします。

    $ sqlplus / as sysdba
    
    SQL> REM run the following command if using a CDB
    SQL> alter session set container=shard_pdb_name;
    
    SQL> show parameter db_file_name_convert
    
    NAME TYPE VALUE
    ---------------------- --------- -----------------------------
    db_file_name_convert   string    /dbs/SHARD1/, /dbs/SHARD1S/
  • Oracle提供のGSMUSERという名前のユーザー・アカウントは、シャード・データベースとして指定したPDBまたはレガシー・データベース内でロック解除してパスワードを割り当てる必要があります。さらに、このユーザーには、システム権限SYSDGおよびSYSBACKUPを付与する必要があります。

    シャードがPDBの場合、GSMUSERはCDBの共通ユーザーであることに注意してください。そのため、そのパスワードはCDB$ROOTおよびCDB内のすべてのPDBで同じになります。これは、セキュリティ上の問題につながります。これを回避するために、CDBごとにシャードPDBを1つのみホストして、それ以外のPDBではGSMUSERアカウントのロックを解除しないようにします。

    このアカウントは、シャード・ディレクタのプロセスがシャード・データベースに接続して、シャーディング・コマンドに応じて管理タスクを実行するために使用されます。指定したパスワードは、この後のシャーディング・トポロジの作成時に発行するADD SHARDコマンドで使用します。このパスワードは、シャード・ディレクタによってOracleウォレットに安全に保管され、必要なときにのみ復号化されるため、再指定が必要になることはありません。その後、シャード・データベースでパスワードが変更された場合、保管したパスワードはMODIFY SHARDコマンドを使用して更新できます。

    $ sqlplus / as sysdba
    
    SQL> alter user gsmuser account unlock;
    
    User altered.
    
    SQL> alter user gsmuser identified by gsmuser_password;
    
    User altered.
    
    SQL> REM run the following commands if using a CDB
    SQL> alter session set container=shard_pdb_name;
    
    SQL> alter user gsmuser account unlock;
    
    User altered.
    
    SQL> REM all cases run the following command
    
    SQL> grant SYSDG, SYSBACKUP to gsmuser;
    
    Grant succeeded.
    
  • Oracle Net TNSリスナーを設定して選択したポート(デフォルトは1521)で実行します。これにより、シャードPDBに対する着信接続リクエストを処理できます。

    TNSリスナーは、どのような方法で作成および構成してもかまいません。シャードがPDBの場合、データベースの作成方法によっては、ALTER SESSION SET CONTAINERを使用する必要のない、PDBへの直接接続リクエストを許可できるデータベース・サービスを明示的に作成することが必要になる場合もあります。

    シャードにPDBを使用している場合、リスナーが正しく構成されていることを確認するには、新しくロック解除したGSMUSERアカウントと適切な接続文字列を使用して、次の操作を実行します。LSNRCTL SERVICESを実行すると、このリスナーを使用して現在利用可能なすべてのサービスが示されます。

    $ sqlplus gsmuser/gsmuser_password@shard_connect_string
    
    SQL> show con_name
    
    CON_NAME
    -----------------------
    shard_pdb_name
    

    接続を確認したら、前述のshard_connect_stringを記録しておきます。これは、この後の構成プロセスのGDSCTL ADD SHARDコマンドで使用します。一般に、この接続文字列はhost:port/service_nameの形式になります(例: shardhost.example.com:1521/shard_pdb.example.com)。

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

前述の要件がすべて満たされていることを確認するには、Oracle提供のプロシージャ validateShardを実行します。これにより、シャード・データベースを検査して、発生した問題があるときに報告します。このプロシージャは、読取り専用であり、データベース構成に変更を加えることはありません。

validateShardプロシージャは、シャード・データベース構成に含まれるプライマリ、マウント済(未オープン)スタンバイ、およびActive Data Guardスタンバイのデータベースに対して実行する必要があります。validateShardは、シャード・データベースのライフサイクル期間中に、アップグレード後やパッチ適用後など、いつでも何度でも実行できます。

validateShardパッケージを実行するには、次のように操作します。

$ sqlplus / as sysdba

SQL> REM run the following command if using a CDB
SQL> alter session set container=shard_pdb_name;

SQL> set serveroutput on
SQL> execute dbms_gsm_fix.validateShard

このプロシージャでは、次のような出力が生成されます。

INFO: Data Guard shard validation requested.
INFO: Database role is PRIMARY.
INFO: Database name is SHARD1.
INFO: Database unique name is shard1.
INFO: Database ID is 4183411430.
INFO: Database open mode is READ WRITE.
INFO: Database in archivelog mode.
INFO: Flashback is on.
INFO: Force logging is on.
INFO: Database platform is Linux x86 64-bit.
INFO: Database character set is WE8DEC. This value must match the character set of the catalog database.
INFO: 'compatible' initialization parameter validated successfully.
INFO: Database is a multitenant container database.
INFO: Current container is SHARD1_PDB1.
INFO: Database is using a server parameter file (spfile).
INFO: db_create_file_dest set to: '/u01/app/oracle/dbs'
INFO: db_recovery_file_dest set to: '/u01/app/oracle/dbs'
INFO: db_files=1000. Must be greater than the number of chunks and/or
tablespaces to be created in the shard.
INFO: dg_broker_start set to TRUE.
INFO: remote_login_passwordfile set to EXCLUSIVE.
INFO: db_file_name_convert set to: '/dbs/SHARD1/, /dbs/SHARD1S/'
INFO: GSMUSER account validated successfully.
INFO: DATA_PUMP_DIR is '/u01/app/oracle/dbs/9830571348DFEBA8E0537517C40AF64B'.

INFOのマークが付いているすべての出力行は、情報の提示を目的としています。この行の情報が目的の構成に適っていることを確認する必要があります。

ERRORのマークが付いているすべての行は、デプロイメントの次のステップに進む前に修正する必要があります。こうした問題が解決されていないと、シャーディング作成操作のエラーの原因になります。

WARNINGのマークが付いているすべての出力行は、目的の構成に適していることも、適していないこともあります。たとえば、このデプロイメントにはスタンバイ・データベースを使用しないことにしていた場合、スタンバイ・データベースやリカバリに関連する警告は無視できます。特に、本番以外のデプロイ、概念実証のデプロイ、アプリケーション開発のデプロイなどの場合に当てはまります。すべての警告を確認して、必要に応じて解決してください。

ここまでのすべてのステップを完了すると、新しく作成したデータベースはGDSCTL ADD SHARDコマンドの実行可能対象になります。

高可用性と障害回復のために、1つ以上のスタンバイ・シャード・データベースも作成するようにしてください。シャーディングの観点からは、前述の要件がスタンバイ・データベースでも満たされていて、プライマリ・シャード・データベースに対するすべての変更がスタンバイに確実に適用されていれば、スタンバイ・データベースに必要な作業は、ADD SHARDコマンドでシャーディング構成を追加することのみです。

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

シャード・データベース・トポロジは、シャード・カタログ・データベースのシャーディング・メタデータによって記述されます。GDSCTLを使用して、シャード・データベース・トポロジを構成します。

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

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

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

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

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

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

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

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

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

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

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

シャード・カタログ・データベースがPDBの場合、catalog_connect_stringでは、CDB$ROOTではなく、シャード・カタログ・データベースのPDBを指定する必要があります。

次に、簡潔なtnsnames.oraのエントリを示します。

CATALOG_CONNECT_STRING=
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = tcp)(HOST = primary_catalog)(PORT = 1521))
      (ADDRESS = (PROTOCOL = tcp)(HOST = standby_catalog)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = catpdb.example.com)
    )
  )

ADD SHARDメソッドを使用してシャードを作成する場合は、最初のステップのみを実行します。CREATE SHARDメソッドを使用する場合は、両方のステップを実行します。

  1. 計画したシャーディング・トポロジに適した設定で、CREATE SHARDCATALOGを実行します。

    CREATE SHARDメソッドに必要な追加パラメータ

    CREATE SHARDメソッドを使用してシャードを構成に追加する場合は、CREATE SHARDCATALOGを実行するときに、次の追加パラメータを設定する必要があります。これは、次のステップでリモート・スケジューラ・エージェント登録に必要です。

    • –agent_passwordでは、リモート・スケジューラ・エージェントがシャード・カタログへの登録に使用するパスワードを指定します。
    • –agent_portでは、エージェントがシャード・カタログへのXDB接続の作成に使用するポート番号を指定します。このパラメータのデフォルト値は8080です。

    システム管理のシャーディング方法

    次の例では、システム管理シャーディング構成用のシャード・データベース・メタデータが作成されます。この構成には、region1およびregion2という2つのリージョンがあります。システム管理はデフォルトのシャーディング方法であるため、-shardingパラメータで指定する必要はありません。

    GDSCTL> create shardcatalog -database catalog_connect_string
     -user mysdbadmin/mysdbadmin_password -repl DG -region region1,region2
    

    -shardspaceの指定も省略すると、shardspaceoraというデフォルトのシャード領域が作成されます。-regionの指定を省略すると、regionoraというデフォルトのリージョンが作成されます。単一のデフォルト・リージョンがデフォルト・シャード領域とともに作成されると、そのシャード領域にshardspaceora_regionoraというデフォルトのシャードグループも作成されます。

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

    次の例は、コンポジット・シャード・データベース用のシャード・カタログ・メタデータの作成方法を示しています。ここでは、MaxAvailability保護モードのData Guardレプリケーション、シャード領域ごとに60チャンク、および2つのシャード領域を設定します。

    GDSCTL> create shardcatalog -database catalog_connect_string
     -user mysdbadmin/mysdbadmin_password -sharding composite -chunks 60 
     -protectmode maxavailability -shardspace shardspace1,shardspace2
    

    ユーザー定義のシャーディング方法

    次の例は、ユーザー定義のシャード・データベース用のシャード・カタログ・メタデータの作成方法を示しています。ここでは、Data Guardレプリケーションを設定しています。

    GDSCTL> create shardcatalog -database catalog_connect_string
     -user mysdbadmin/mysdbadmin_password -sharding user
     -protectmode maxperformance 
    
  2. CREATE SHARDメソッドのみの場合: リモート・スケジューラ・エージェントをシャード・カタログに登録し、各シャード・ホストでエージェントを起動します。

    各シャード・ホストに移動して、Oracleソフトウェア・インストールの所有者としてログインし、シャード・データベースの実行元となるOracleホームで次のschagentコマンドを実行します。

    schagent –registerdatabase catalog_hostname agent_port
    schagent -start

    前述のschagentコマンドで、catalog_hostnameをシャード・カタログ・ホストの名前に置き換え、agent_portを前述のCREATE SHARDCATALOGで構成したポート番号に置き換えます。

    次に例を示します。

    $ $ORACLE_HOME/bin/schagent –registerdatabase cathost.example.com 8080
    $ $ORACLE_HOME/bin/schagent -start

    正常にエージェントを登録すると、シャード・ホストはGDSCTL DEPLOY中にシャード・カタログからリモート・ジョブ・リクエストを受信できます。特定のホストに正常にデプロイされると、リモート・スケジューラ・エージェントは、シャード・データベースのライフ・サイクルでは使用されなくなり、次のコマンドを使用して安全に停止できます。

    $ $ORACLE_HOME/bin/schagent –stop

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

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

GDSCTL> connect mysdbadmin/mysdbadmin_password@catalog_connect_string

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

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

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

  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つのタイプprimarystandby (マウント済、未オープン)、および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の追加

シャードがCDB内のPDBである場合、ADD CDBコマンドを使用して、シャードPDBを格納するCDBをシャーディング構成に追加します。シャードとして非CDBを使用するか、またはCREATE SHARDを使用してシャードを追加する場合は、次の項へスキップします。

  1. 次に示すように、ADD CDBコマンドを実行します。
    GDSCTL> add cdb -connect cdb_connect_string -pwd gsmrootuser_password

    このコマンドにより、GDSCTLSYSDGとして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

シャードの追加

シャードを構成に追加するのにADD SHARDCREATE SHARDのどちらを使用するかに応じて、次の適切な手順に従います。

GDSCTL ADD SHARDを使用したシャードの追加

GDSCTL ADD 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
    

    PDBをシャードとして使用しない場合は、–cdbパラメータを指定しないでください。

    前述の例で、-cdbパラメータでは、シャードPDBが存在しているCDBの名前を指定します。-shardgroupまたは-shardspaceでは、シャーディング・トポロジでのシャードの場所を指定します。また、-deploy_asでは、シャードのオープン・モード(primarystandbyactive_standby)を指定します。

    ADD SHARDを実行すると、GDSCTLはSYSDGとしてGSMUSER/gsmuser_password@shard_connect_stringに接続してシャードの設定を検証し、dbms_gsm_fix.validateShardを再実行してエラーがないか確認します。その後、GDSCTLは、次の規則を使用してシャード名を構成します。

    • PDBシャードの場合: db_unique_name_of_CDB_PDB_name (例: cdb1_pdb1)
    • レガシー・データベース・シャードの場合: db_unique_name_of_DB (単純にdb_unique_nameです)

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

  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-になります。

GDSCTL CREATE SHARDを使用したシャードの追加

GDSCTL CREATE SHARDコマンドを使用して、シャード・データベースを作成し、シャード情報をシャード・カタログに追加します。

次の例で示すように、対象のシャーディング方法に適したパラメータを使用してCREATE SHARDを実行します。

システム管理またはコンポジットのシャーディングの場合は、次に示すパラメータでCREATE SHARDを実行します。


GDSCTL> create shard -shardgroup shardgroup_name –destination shard_hostname
 –osaccount account_name –ospassword account_password

ユーザー定義のシャーディングの場合は、わずかにコマンドの使用方法が異なります。

GDSCTL> create shard -shardspace shardspace_name –deploy_as db_mode
 –destination shard_hostname –osaccount account_name –ospassword account_password

-shardgroupまたは-shardspaceパラメータではシャーディング・トポロジ内のシャードの場所を指定し、-deploy_asではシャードの目的のオープン・モード(primarystandbyactive_standby)を指定します。

–destinationパラメータでは、NETCAおよびDBCAを生成してシャード・データベースを作成するために、シャード・カタログがやり取りするリモート・スケジューラ・エージェントを指定します。この値は通常、シャード・ホストのホスト名です。使用可能な宛先のリストを表示するには、シャード・カタログ・データベースのALL_SCHEDULER_EXTERNAL_DESTSビューから選択します。

–osaccountおよび–ospasswordパラメータでは、シャード・ホストでNETCAおよびDBCAプロセスを生成するときに使用されるオペレーティング・システムのユーザー名およびパスワードを指定します。通常、ユーザー名はOracle Databaseソフトウェアの所有者です。

パスワードの暗号化

CREATE SHARDコマンドでアカウントのクリアテキスト・パスワードを指定しないようにするには、後で使用するために、GDSCTL ADD CREDENTIALコマンドを使用して、暗号化されたパスワードをシャード・カタログに格納できます。CREATE SHARDコマンドで、次に示すように–osaccountおよび–ospasswordではなくコマンド・パラメータに資格証明名を指定します。

GDSCTL> add credential –credential credential_name
 –osaccount account_name –ospassword account_password

GDSCTL> create shard -shardgroup shardgroup_name –destination shard_hostname
 –credential credential_name

CREATE SHARDの実行時の処理

CREATE SHARDを実行すると、GDSCTLによって入力パラメータおよびシャード・ホスト設定が検証され、シャード・メタデータがシャード・カタログに追加され、その結果、GDSCTL DEPLOY中に次の操作が実行されます。

  • ポート1521で、リスナー名"LISTENER" (デフォルト)を使用して、TNSリスナー・プロセスをシャード・ホストに作成して起動します

  • プライマリ・シャードの場合、$ORACLE_HOME/assistants/dbca/templates/General_Purpose.dbc (デフォルト)のシャード・ホストにあるデフォルトのDBCAテンプレートを使用して、シャード・データベースを作成します。

    プライマリ・シャードには、デフォルトで次の特性があります。

    • SYSSYSTEMおよびGSMUSERに対してランダム生成されるパスワード
    • db_unique_namedb_nameおよび'shNN'形式のSID (NNは、追加されたシャードを一意に識別するための順序ベースの番号)
    • db_domain値: 指定した宛先に対応するALL_SCHEDULER_EXTERNAL_DESTS.HOSTNAME列にあるドメインと同じ。ドメインが見つからない場合、db_domainはシャード・カタログ・データベースのdb_domainに設定されます。
    • NLS_CHARACTERSET値およびNLS_NCHAR_CHARACTERSET値: シャード・カタログ・データベースの値と同じ
    • db_file_name_convertパラメータ: '*','$ORACLE_BASE/oradata/'に設定
    • db_create_file_destパラメータ: $ORACLE_BASE/oradataに設定
    • remote_login_passwordfileパラメータ: EXCLUSIVEに設定
    • データベース: アーカイブ・ログ・モード
    • 強制ロギング: 有効
    • データベース・フラッシュバック: オン
    • Oracle Data GuardレプリケーションがCREATE SHARDCATALOGに指定されている場合は、次のパラメータが設定されます。
      • dg_broker_start: TRUEに設定
      • db_recovery_file_dest: $ORACLE_BASE/fast_recovery_areaに設定
      • db_recovery_file_dest_size: 51200 MBに設定
      • standby_file_management: AUTOに設定
      • db_flashback_retention_target: 60に設定
  • スタンバイ・シャードの場合、DBCAおよびRMANを使用して、既存のプライマリに基づいてスタンバイ・データベースを作成します。一般に、すべてのプライマリ・データベース・パラメータはスタンバイによって継承されます。

データベースのカスタマイズに関するCREATE SHARDの使用上のヒント

GDSCTL CREATE SHARDコマンドには、シャード・データベースをカスタマイズできるパラメータがいくつかあります。

  • –sys_passwordおよび–system_passwordパラメータを使用すると、SYSおよびSYSTEMアカウントのパスワードを新しいシャードに指定できます。

    このアカウントは対話型ログインで使用されるものではないため、GSMUSERパスワードは常にランダムに作成されます。デプロイメント後にGSMUSERパスワードを変更するには、ALTER USERを使用してデータベース上のパスワードを変更し、GDSCTL MODIFY SHARDコマンドを使用して新しいパスワードでシャーディング・メタデータを更新します。

  • –netparamおよび–netparamfileパラメータを使用すると、TNSリスナーの名前およびポート番号をシャード・ホストで作成する際にカスタマイズできます。

    これらのパラメータに指定する値は、NETCAレスポンス・ファイルのファイル名です。レスポンス・ファイルの例は、シャード・ホストの$ORACLE_HOME/assistants/netcaにあります。

  • 同様に、-dbtemplateおよび-dbtemplatefileパラメータを使用して、シャード・データベースの作成時に使用されるDBCAテンプレート・ファイルを指定できます。

    デフォルト・テンプレートは、シャード・ホスト上の$ORACLE_HOME/assistants/dbca/templates/General_Purpose.dbcです。

  • コマンドラインからDBCAを実行するときに入力するのと同様に、-dbparamおよび-dbparamfileパラメータを使用して、DBCAコマンドライン・パラメータをシャード・ホストのDBCAプロセスに直接渡すことができます。

    プライマリ・データベースの作成に使用可能なパラメータをすべて表示するには、dbca -help -createDatabaseを実行します。スタンバイ・データベースを作成するためのパラメータを表示するには、dbca -help -createDuplicateDBを実行します。たとえば、プライマリ・シャードのグローバル・データベース名およびSIDを変更するには、次に示すように1行のファイルを作成し、そのファイル名を-dbparamまたは-dbparamfileに指定します。

    -gdbName mydb.example.com -sid mysid 
  • これらのパラメータのいずれかを指定する場合は、GDSCTLのように、-netparamfile-dbtemplatefileまたは-dbparamfileをオペレーティング・システム・ファイル名とともに使用できます。

    あるいは、ADD FILEコマンドを使用して、ファイルの内容をシャード・カタログ・データベースに保存してから、CREATE SHARDコマンドで-netparam-dbtemplateまたは-dbparamを使用することもできます。

    GDSCTL> create shard -dbtemplatefile /home/user/mytemplate.dbc -netparamfile /home/user/mynetca.rsp ...

    または

    GDSCTL> add file –file mytemplate –source /home/user/mytemplate.dbc
    GDSCTL> add file –file mynetca –source /home/user/mynetca.rsp
    GDSCTL> create shard –dbtemplate mytemplate –netparam mynetca ...

特定のホストのスタンバイ・シャードが特定のプライマリ・シャードと同じData Guard構成にあることを保証する場合は、まずプライマリ・シャードを作成し、次にCREATE SHARDで目的の–destination値を使用してスタンバイ・シャードを作成することをお薦めします。複数のプライマリ・シャードを順次作成してから、複数のスタンバイ・シャードを作成する場合、Data Guard構成ではプライマリとスタンバイは非決定的な方法で一致します。

シャード構成の確認

GDSCTL CONFIG SHARDを実行して、シャード・カタログのシャード・メタデータが想定どおりであることを確認します。

GDSCTL> config shard
Name      Shard Group          Status    State    Region    Availability
--------- -------------------  ------    -----    ------    ------------
sh1       shardgroup_primary   U         none     region1   -
sh2       shardgroup_primary   U         none     region1   -
sh3       shardgroup_standby   U         none     region2   -
sh4       shardgroup_standby   U         none     region2   -

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

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

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

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

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

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

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

    デフォルトでは、ADD SHARDおよびCREATE 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

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

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

GDSCTL DEPLOYコマンドを実行すると、ADD SHARDコマンドを使用してシャードを構成した場合、出力は次のようになります。

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

CREATE SHARDを使用してシャードを構成した場合、GDSCTL DEPLOYコマンドの出力は次のようになります。

GDSCTL> deploy
deploy: examining configuration...
deploy: deploying primary shard 'sh1' ...
deploy: network listener configuration successful at destination 'shard1'
deploy: starting DBCA at destination 'shard1' to create primary shard 'sh1' ...
deploy: deploying primary shard 'sh2' ...
deploy: network listener configuration successful at destination 'shard2'
deploy: starting DBCA at destination 'shard2' to create primary shard 'sh2' ...
deploy: waiting for 2 DBCA primary creation job(s) to complete...
deploy: waiting for 2 DBCA primary creation job(s) to complete...
deploy: DBCA primary creation job succeeded at destination 'shard1' for shard 'sh1'
deploy: DBCA primary creation job succeeded at destination 'shard2' for shard 'sh2'
deploy: deploying standby shard 'sh3' ...
deploy: network listener configuration successful at destination 'shard3'
deploy: starting DBCA at destination 'shard3' to create standby shard 'sh3' ...
deploy: deploying standby shard 'sh4' ...
deploy: network listener configuration successful at destination 'shard4'
deploy: starting DBCA at destination 'shard4' to create primary shard 'sh4' ...
deploy: waiting for 2 DBCA standby creation job(s) to complete...
deploy: waiting for 2 DBCA standby creation job(s) to complete...
deploy: DBCA standby creation job succeeded at destination 'shard3' for shard 'sh3'
deploy: DBCA standby creation job succeeded at destination 'shard4' for shard 'sh4'
deploy: requesting Data Guard configuration on shards via GSM
deploy: shards configured successfully
The operation completed successfully

デプロイ時の処理

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

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

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

PDBおよびADD SHARDメソッドを使用したデプロイメントが正常に完了すると、Data Guardアクティブ・スタンバイ・シャードが使用されているときのCONFIG SHARDからの出力は、次のようになります。

GDSCTL> config shard
Name      Shard Group          Status   State     Region   Availability
--------- -------------------  -------  --------  -------  ------------
cdb1_pdb1 shardgroup_primary   Ok       Deployed  region1  ONLINE
cdb2_pdb1 shardgroup_standby   Ok       Deployed  region2  READ ONLY
cdb3_pdb2 shardgroup_primary   Ok       Deployed  region1  ONLINE
cdb4_pdb2 shardgroup_standby   Ok       Deployed  region2  READ ONLY

CREATE SHARDメソッドを使用した場合、またはADD SHARDを非CDBとともに使用した場合、シャード名はシャード・データベースのdb_unique_name値になります。

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

GDSCTL> config shard
Name      Shard Group         Status        State     Region   Availability
--------- ------------------  ------------- --------  -------  ------------
cdb1_pdb1 shardgroup_primary  Ok            Deployed  region1  ONLINE
cdb2_pdb1 shardgroup_standby  Uninitialized Deployed  region2  -
cdb3_pdb2 shardgroup_primary  Ok            Deployed  region1  ONLINE
cdb4_pdb2 shardgroup_standby  Uninitialized Deployed  region2  -

問題の修正方法

シャードの可用性にPENDINGが示されている場合は、トポロジ構成のADD INVITEDNODEおよびCONFIG VNCRに関連するすべてのステップが完了していることを確認します。完了していない場合は、そのステップを今すぐ完了してから、GDSCTL SYNC DATABASE -database shard_nameを実行することでシャードのデプロイメントを完了します。

CREATE SHARDメソッドを使用してシャードを構成に追加し、リモート・スケジューラ・エージェント・ジョブからGDSCTL DEPLOY中にNETCAまたはDBCAからのエラーが戻された場合は、次のステップを実行してエラーを解決し、デプロイメントを再試行します。

  1. 問題を解決します。

    GDSCTL DEPLOYによって戻されたエラー・メッセージには、シャード・ホストで失敗したジョブの出力を表示するための十分な情報が含まれています。

    通常、シャード・ホストの$ORACLE_BASE/cfgtoollogsに、NETCAまたはDBCA実行からのトレース・ファイルおよびログ・ファイルがあります。失敗の原因となった根本的な問題(不正なパラメータ、ホスト上のリソースの問題など)を解決します。

  2. シャード・ホストをリセットします。

    1. デプロイの試行中に作成された実行中のTNSリスナーを停止します。
    2. デプロイの試行中に起動された実行中のシャード・データベースを停止します。
    3. $ORACLE_HOME/network/admin/listener.oraを削除します
    4. 失敗したシャード作成に関連付けられているすべてのファイルを$ORACLE_BASE/oradataおよび$ORACLE_BASE/fast_recovery_areaから削除します
  3. GDSCTL DEPLOYを再度実行します。

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

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

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

サービスが開始されたら、シャード・データベースはアプリケーション・スキーマの作成および着信クライアント接続リクエストの準備ができました。

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

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

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

例3-2 スタンバイ・シャードで実行する読取り専用のワークロードのためのグローバル・サービスの追加と開始

スタンバイ・シャードで読取り専用のワークロードを実行するために、oltp_ro_srvcグローバル・サービスが作成および開始されます。これは、スタンバイ・シャードが、読取り専用アクセスでオープンされるOracle Active Data Guardスタンバイ・シャードであることを前提としています。マウント済で未オープンのスタンバイは読取り専用接続に対応できません。そのようなスタンバイは、障害回復と高可用性のためにのみ存在します。

GDSCTL> add service -service oltp_ro_srvc -role physical_standby
GDSCTL> start service -service oltp_ro_srvc

例3-3 グローバル・サービスのステータスの確認

GDSCTL> config service 

Name         Network name                    Pool    Started Preferred all
----         ------------                    ----    ------- -------------
oltp_rw_srvc oltp_rw_srvc.orasdb.oracdbcloud orasdb  Yes     Yes
oltp_ro_srvc oltp_ro_srvc.orasdb.oracdbcloud orasdb  Yes     Yes


GDSCTL> status service
Service "oltp_rw_srvc.orasdb.oradbcloud" has 2 instance(s). Affinity: ANYWHERE
   Instance "orasdb%1", name: "cdb1_pdb1", db: "cdb1_pdb1", region: "region1", status: ready.
   Instance "orasdb%21", name: "cdb3_pdb2", db: "cdb3_pdb2", region: "region1", status: ready.
Service "oltp_ro_srvc.orasdb.oradbcloud" has 2 instance(s). Affinity: ANYWHERE
   Instance "orasdb%11", name: "cdb2_pdb1", db: "cdb2_pdb1", region: "region2", status: ready.
   Instance "orasdb%31", name: "cdb4_pdb2", db: "cdb4_pdb2", region: "region2", status: ready.

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

シャーディング構成のデプロイでDEPLOYステップを完了したら、各シャードの詳細なステータスを確認します。

GDSCTL CONFIG SHARDを実行して、各シャードの詳細なステータスを表示します。

GDSCTL> config shard -shard cdb1_pdb1
Name: cdb1_pdb1
Shard Group: shardgroup_primary
Status: Ok
State: Deployed
Region: region1
Connection string:shard_connect_string
SCAN address:
ONS remote port: 0
Disk Threshold, ms: 20
CPU Threshold, %: 75
Version: 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を使用します。この例のシャード・カタログおよびシャードはPDBであり、シャードはADD SHARDコマンドで構成に追加されます。

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

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

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

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

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



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

トポロジ・オブジェクト 説明
シャード・カタログ・データベース

すべてのシャード・データベース・トポロジに、シャード・カタログが必要です。この例では、シャード・カタログ・データベースに2つのスタンバイがあります(データ・センターごとに1つ)。

プライマリ

  • データ・センター= 1
  • ホスト名= cathost
  • DB_UNIQUE_NAME = catcdb
  • PDB名= catpdb
  • 接続サービス名= catpdb

アクティブ・スタンバイ

  • データ・センター= 1
  • ホスト名= cathost1

スタンバイ

  • データ・センター= 2
  • ホスト名= cathost2
リージョン

この構成には2つのデータ・センターが関与しているため、それに対応する2つのリージョンがシャード・カタログ・データベースに作成されています。

データ・センター1

  • リージョン名= dc1

データ・センター2

  • リージョン名= dc2
シャード・ディレクタ(グローバル・サービス・マネージャ)

それぞれのリージョンには、そのデータ・センター内のホストで実行するシャード・ディレクタが必要です。この例は、リージョンごとに2つのシャード・ディレクタを使用する方法を示しており、これがベスト・プラクティスの推奨です。

データ・センター1

  • シャード・ディレクタ・ホスト名= gsmhost1およびgsmhost1b
  • シャード・ディレクタ名= gsm1およびgsm1b

データ・センター2

  • シャード・ディレクタ・ホスト名= gsmhost2およびgsmhost2b
  • シャード・ディレクタ名= gsm2およびgsm2b
シャードグループ

データ・センター1

  • sg1
  • sg2

データ・センター2

  • sg3
シャード
  • ホスト名= shardhost1, …, shardhost9
  • DB_UNIQUE_NAME = cdb1、…、cdb9
  • PDB名= pdb1, pdb2, pdb3

    スタンバイ・レプリカのPDB名は、それらに対応するプライマリのPDB名と同じになります

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

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

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

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

  3. ホストgsmhost1、gsmhost1b、gsmhost2およびgsmhost2bにシャード・ディレクタ・ソフトウェアをインストールします。

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

  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. ホストgsmhost1bで、GDSCTLから次のコマンドを実行します。

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

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

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

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

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

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

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

    5. ホスト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の追加」および「GDSCTL ADD SHARDを使用したシャードの追加」を参照してください。

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

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

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

      詳細は、「シャーディング構成のデプロイ」を参照してください。

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

      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 CONFIGCONFIG SHARD、およびCONFIG SERVICEを使用すると、シャードとサービスのすべてがオンラインになっていて実行されていることを確認できます。

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

Oracle Shardingでの透過的データ暗号化の使用

Oracle Shardingでは透過的データ暗号化(TDE)がサポートされますが、TDEを有効にした状態でシャード・データベース内のチャンクを正常に移行できるように、すべてのシャードが暗号化された表領域に対する同じ暗号化キーを共有して使用する必要があります。

シャード・データベースは、複数の独立したデータベースと1つのカタログ・データベースで構成されます。特にシャード間でデータを移動するときにTDEが正しく機能するように、一定の制限が適用されます。データが暗号化されているときにシャード間のチャンク移動が正常に機能するためには、すべてのシャードで同じ暗号化キーを使用する必要があります。

これを実現するには、次の2つの方法があります。

  • シャード・カタログから暗号化キーを作成してエクスポートし、すべてのシャードに個々にキーをインポートしてアクティブ化します。

  • ウォレットを共有の場所に格納し、シャード・カタログおよびすべてのシャードで同じウォレットを使用します。

シャードDDLを有効にしたシャード・カタログで次のTDE文を実行すると、その操作がシャードに自動的に伝播されます。

  • alter system set encryption wallet open/close identified by password

  • alter system set encryption key

  • administer key management set keystore [open|close] identified by password

  • administer key management set key identified by password

  • administer key management use key identified by password

  • administer key management create key store identified by password

制限事項

Oracle ShardingでのTDEの使用には、次の制限事項が適用されます。

  • MOVE CHUNKが正常に機能するには、すべてのシャード・データベース・ホストが同じプラットフォームに存在する必要があります。

  • MOVE CHUNKでは、データ転送中にパフォーマンスに影響を及ぼす可能性がある圧縮を使用できません。

  • 表領域レベルでの暗号化のみがサポートされます。特定の列に対する暗号化はサポートされません。

関連項目:

TDEの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

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

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

ノート:

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

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

  1. シャード・カタログで暗号化キーを作成します。

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

  2. シャード・カタログのキーストアからマスター・キーの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));
  3. シャードDDLを無効にして、カタログの暗号化キーを含むウォレットをエクスポートします。
    ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET secret_phrase TO
     wallet_export_file IDENTIFIED BY keystore_password;
    (オプション)ここでステップの結果を入力します。
  4. ウォレット・ファイルを各シャード・ホストの対応するウォレット・エクスポート・ファイルの場所に物理的にコピーするか、すべてのシャードがアクセスできる共有ディスクに格納します。
  5. シャード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;
  6. シャード・データベースを再起動します。
  7. すべてのシャード上のキーをアクティブ化します。

    カタログでシャード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));