4 Oracle Globally Distributed Databaseのデプロイ
シャード・データベースを作成および構成します。まずホストをプロビジョニングし、ソフトウェアの構成、データベースの設定、シャーディング・メタデータの作成、スキーマの作成の順に作業を進めます。このプロセスはデプロイと呼ばれます。
シャード・データベースのデプロイの概要
Oracle Globally Distributed Databaseには、シャード・データベースを自動的にデプロイする機能があり、これにはシャードとレプリカの両方が含まれます。
シャード・データベース管理者は、トポロジ(リージョン、シャード・ホスト、レプリケーション・テクノロジ)を定義し、GDSCTL
コマンドライン・インタフェースを使用して宣言的に指定することでDEPLOY
コマンドを起動します。
始める前に
シャード・データベースには、多種多様な構成とトポロジが使用できます。アプリケーションに特有のアーキテクチャとシステム要件に応じて、システムの設計時に複数の選択肢から選択できることもあります。デプロイを続行する前に、シャード・データベースのデプロイの計画について理解してください。
シャード・データベース・デプロイ・ロード・マップ
大まかなデプロイメント・ステップは次のとおりです。
- コンポーネントを設定します。
- 選択したシャーディング構成およびトポロジに必要になるホストをプロビジョニングおよび構成します(「ホストおよびオペレーティング・システムのプロビジョニングと構成」を参照)。
- 選択したカタログとシャード・ノードにOracle Databaseソフトウェアをインストールします(「Oracle Databaseソフトウェアのインストール」を参照)。
- シャード・ディレクタ・ノードにグローバル・サービス・マネージャ(GSM)ソフトウェアをインストールします(「シャード・ディレクタ・ソフトウェアのインストール」を参照)。
- シャーディング・メタデータとアプリケーション・データの保管に必要なデータベースを作成します。
- シャード・カタログにするデータベースと、障害回復(DR)と高可用性(HA)に必要なレプリカを作成します(「シャード・カタログ・データベースの作成」を参照)。
- 構成内でシャードにするデータベースとDRおよびHAに必要なスタンバイ・データベースを作成します(「シャード・データベースの作成」を参照)。
GDSCTL
コマンドライン・ユーティリティから、次のコマンドの一部またはすべてのコマンドを使用してシャーディング・トポロジを指定します(Oracle Globally Distributed Databaseトポロジの構成を参照)。CREATE SHARDCATALOG
ADD GSM
START GSM
ADD SHARDGROUP
ADD SHARD
ADD INVITEDNODE
DEPLOY
を実行して、シャーディング・トポロジ構成をデプロイします(構成のデプロイを参照)。- シャード・データベース内のシャードへのアクセスに必要なグローバル・サービスを追加します(「グローバル・データベース・サービスの作成と開始」を参照)。
- 各シャードのステータスを確認します(「シャード・ステータスの確認」)。
シャード・データベース構成のデプロイが正常に完了すると、アプリケーションに必要なシャード・スキーマ・オブジェクトを作成できます。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 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
コマンドなどのイベントに応じてシャーディング・システムの監視や、バックグラウンド・タスクを実行します。
次のコマンドは、シャード・ディレクタのプロセスを実行するホストで実行する必要があります。これは、シャード・カタログ・ホストまたはシャード・ディレクタ・プロセスの専用ホストのどちらかになります。
今後のGDSCTL
セッションでは、管理するシャード・ディレクタの明示的な指定が必要になることがあります。デフォルトのGSMORAシャード・ディレクタを示すエラー・メッセージが表示され場合は、次に示すように、GDSCTL SET GSM
を実行してから作業を進めてください。
GDSCTL> set gsm -gsm sharddirector1
シャード領域の追加(必要な場合)
コンポジット・シャーディングまたはユーザー定義シャーディングを使用するときに、目的のシャーディング・トポロジの達成にシャード領域の追加が必要な場合は、ADD SHARDSPACE
コマンドを使用してシャード領域を追加します
必要に応じたシャードグループの追加
シャード・データベース・トポロジにシステム管理またはコンポジットのシャーディング方法を使用する場合は、アプリケーション用に必要な追加のシャードグループを追加することもできます。
それぞれのシャード領域には、少なくとも1つのプライマリ・シャードグループを含める必要があり、任意の数またはタイプのスタンバイ・シャードグループを含めることができます。シャードグループは、ユーザー定義のシャーディング方法では使用しません。
シャーディング・トポロジの検証
シャード・データベースに関する情報をカタログに追加する前に、シャーディング・トポロジが適切なことを確認します。その後で、各種のGDSCTL CONFIG
コマンドを使用して作業を進めてください。
シャードを追加してデプロイした後では、シャード・カタログ・メタデータの大部分が変更できなくなります。そのため、この時点で構成を検証することが重要なタスクになります。
ホスト・メタデータの追加
すべてのシャード・ホストのホスト名とIPアドレスをシャード・カタログに追加します。
デプロイメント・プロセスの一環として、シャード・ディレクタはシャードと通信して、シャード・ディレクタのTNSリスナー・プロセスに登録するように指示します。このリスナー・プロセスは、信頼できるソースからの着信登録リクエストのみを受け入れ、不明なホストからの登録リクエストを拒否します。
シャード・ホストに複数のホスト名またはネットワーク・インタフェースが割り当てられている場合、シャード・ディレクタへの着信登録リクエストは、ADD SHARD
の実行時に自動的に追加されていなかったホストから送信される可能性があります。この場合、その登録リクエストは拒否され、シャードは正常にデプロイされなくなります。この問題について目視できる現象は、DEPLOY
の完了後に、CONFIG SHARD
がシャードの「Availability」にPENDING
を示すことです。
この問題を回避するために、GDSCTL ADD INVITEDNODE
コマンドを使用して、シャード・ホストのすべてのホスト名とIPアドレスをシャード・カタログ・メタデータに手動で追加します。
チェック・フリー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デプロイの例
この例では、高可用性のために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のレプリカは未オープンのマウント済データベースだと仮定します。
表4-1 サンプルのシステム管理トポロジのホスト名
トポロジ・オブジェクト | 説明 |
---|---|
シャード・カタログ・データベース |
すべてのシャード・データベース・トポロジに、シャード・カタログが必要です。この例では、シャード・カタログ・データベースに2つのスタンバイがあります(データ・センターごとに1つ)。 プライマリ
アクティブ・スタンバイ
スタンバイ
|
リージョン |
この構成には2つのデータ・センターが関与しているため、対応する2つのリージョンがシャード・カタログ・データベースに作成されています。 データ・センター1
データ・センター2
|
シャード・ディレクタ(グローバル・サービス・マネージャ) |
それぞれのリージョンには、そのデータ・センター内のホストで実行するシャード・ディレクタが必要です。 データ・センター1
データ・センター2
|
シャードグループ |
データ・センター1
データ・センター2
|
シャード |
|