4 GDS管理

GDSCTLユーティリティを使用して、Global Data Services構成およびそのすべてのコンポーネントを作成、管理および監視します。このユーティリティは、Oracle Real Application Cluster (Oracle RAC)を管理するために使用されるSRVCTLユーティリティとよく似ています。次のトピックでは、GDS構成を管理する方法を説明します。

4.1 Global Data Servicesの管理の概要

Global Data Servicesは、次のタスクを担当するGlobal Data Services管理者によって管理されます。

  • グローバル・サービス・マネージャ・ソフトウェアのインストールとアップグレード

  • Global Data Servicesカタログの作成と保守

  • グローバル・サービス・マネージャの起動、停止および構成

  • Global Data Servicesリージョンとプールの作成と管理

  • グローバル・サービスの管理

  • Global Data Servicesフレームワーク・コンポーネントの監視

各Global Data Services構成には、少なくとも1人のGlobal Data Services管理者が必要です。小規模な構成は、すべての管理作業を実行する1人のユーザーによって管理できます。多くのリージョンおよびプールを含む大規模な構成の場合、状況によっては、職務を共有するGlobal Data Services管理者のグループが必要になります。すべてのGlobal Data Services管理者は、特定のGlobal Data Services構成についてリストされたすべての管理タスクを実行する権限を持ちます。

グローバル・サービス・マネージャが実行されるすべてのコンピュータに、Global Data Services管理者用のオペレーティング・システム・アカウントがあります。アカウント・ユーザーは、グローバル・サービス・マネージャ・ソフトウェアをインストールおよび実行する権限を持ちます。Global Data Services管理者のみがこれらの権限を付与されます。

Global Data Services管理者は、Global Data Servicesカタログ・データベースにユーザーとして追加し、GSMADMIN_ROLEロールを付与する必要もあります。Global Data Services管理者のデータベース・アカウントは、カタログ・データベースのデータベース管理者によって作成されます。このデータベースに対するローカル・データベース管理者権限を持っている場合、Global Data Services管理者は自分でこのアカウントを作成することができます。

Global Data Services構成に複数のプールが含まれる場合、構成全体を管理するGlobal Data Services管理者以外に、各プールに1人以上のGlobal Data Servicesプール管理者を指定できます。プール管理者の職務は特定のプールの管理に限定され、次のようなタスクがあります。

  • プール内のデータベースの追加と削除

  • プール内のグローバル・サービスの管理

これらのタスクを実行するには、Global Data Servicesプール管理者は、適切な権限を持つGlobal Data Servicesカタログ・データベースのユーザーである必要があります。プール管理者用のデータベース・ユーザーの作成と権限の付与は、Global Data Servicesプールを-USERオプションを使用して作成すると、自動的に行われます。作成後、gdsctl modify gdspoolコマンドを使用してプールの管理者をプールに追加できます。Global Data Services管理者は、常に、データベース構成のすべてのプールを管理する権限を持ちます。

すべての管理操作は、適切なGDSCTLコマンドを使用して行います。ほとんどのGDSCTLコマンドの実行には、Global Data Servicesカタログへのアクセスが必要です。そのようなコマンドでは、適切なコマンド・オプションを使用してカタログ・データベースに対する資格証明を指定する必要があります。

Global Data Servicesプールへのデータベースの追加や、グローバル・サービスの有効化などの多くの管理操作では、Global Data Servicesカタログを変更するのみでなく、Global Data Services構成のデータベースも変更する必要があります。そのようなコマンドの一般的なワークフローは次のとおりです。

  • GDSCTLは、管理者が指定した資格証明を使用してカタログ・データベースに接続し、カタログに適切な変更を加えます。

  • カタログ・データベースは、この変更について、Global Data Services構成のすべてのグローバル・サービス・マネージャに通知します。通知は、各グローバル・サービス・マネージャがカタログ・データベースで管理しているOracle Net Services接続を使用して送信されます。

  • 通知の受信後、いずれかのグローバル・サービス・マネージャが、構成を必要とする構成データベースに接続して適切な変更を加えます。

このワークフローをサポートするため、グローバル・サービス・マネージャは、カタログおよび構成データベースに接続できる必要があります。カタログ・データベースへの接続は、GSMCATUSERアカウントを使用して確立されます。このアカウントは、Oracleデータベースのインストール時にデータベースにデフォルトで作成されます。アカウントは、カタログ・データベースのデータベース管理者によってロックが解除され、パスワードがGlobal Data Services管理者に付与される必要があります。新しいグローバル・サービス・マネージャがGDS構成に追加されるたびに、Global Data Services管理者は、GSMCATUSERアカウントのパスワードを指定する必要があります。パスワードは暗号化され、グローバル・サービス・マネージャで今後使用するためにグローバル・サービス・マネージャ・ウォレットに格納されます。

グローバル・サービス・マネージャは、どのOracleデータベースにもデフォルトで存在するGSMUSERアカウントを使用してプール・データベースに接続します。アカウントは、データベースのインストール後にロックされます。データベースをGlobal Data Servicesプールに追加する前に、ローカル・データベース管理者によってロックが解除される必要があります。GSMUSERアカウントのパスワードは、データベースをGlobal Data Servicesプールに追加するプールまたはGlobal Data Servicesの管理者に付与され、gdsctl add databaseコマンドで指定される必要があります。パスワードは暗号化され、すべてのグローバル・サービス・マネージャで今後使用するためにGlobal Data Serviceカタログに格納されます。

4.2 GDSスタックの管理

この項では、グローバル・データ・サービス・フレームワーク内のコンポーネントの起動および停止について説明します。

4.2.1 GDSスタックの起動

GDSスタックは、次の順序で起動することをお薦めします。

  • Global Data Servicesカタログ・データベースおよびローカル・リスナーを起動します。

  • グローバル・サービス・マネージャを起動します。

  • GDSプール・データベースおよびローカル・リスナーを起動します。

  • グローバル・サービスを起動します。

  • アプリケーション層およびクライアントを起動します。

4.2.2 GDSスタックの停止

GDSスタックは、次の順序で停止することをお薦めします。

  • アプリケーション層およびクライアントを停止します。

  • グローバル・サービスを停止します。

  • GDSプール・データベースおよびローカル・リスナーを停止します。

  • グローバル・サービス・マネージャを停止します。

  • Global Data Servicesカタログ・データベースおよびローカル・リスナーを停止します。

4.3 GDS環境の監視

Oracle Global Data Services (GDS)は、Global Data Services構成と呼ばれる一連のレプリケート・データベース全体にOracle Databaseサービス・モデルを実装します。

グローバル・サービス構成を監視するには:

GDSCTL> services
Service "sales_sb.sales.oradbcloud" has 2 instance(s). Affinity: ANYWHERE
Instance "sales%1", name: "mts1", db: "mts", region: "slc", status: ready.
Instance "sales%2", name: "mts2", db: "mts", region: "slc", status: ready.

メンバー・データベースの監視:

GDSCTL> databases
Database: "mts" Registered: Y State: Ok ONS: Y. Role: PRIMARY
Instances: 1 Region: slc
Registered instances:
sales%1

グローバル・サービス・マネージャ構成を監視するには:

GDSCTL> status
Alias GSM1
Version 19.17.0.3.0
Start Date 13-APR-2023 09:40:59
Trace Level off
Listener Log File
/u01/app/oracle/diag/gsm/hostname/gsm1/alert/log.xml
Listener Trace File
/u01/app/oracle/diag/gsm/hostname/gsm1/trace/ora_64863_139739749930432.trc
Endpoint summary
(ADDRESS=(HOST=hostname.example.com)(PORT=1522)(PROTOCOL=tcp))
GSMOCI Version 0.6.11
Mastership Y
Connected to GDS catalog Y
Process Id 64883
Number of reconnections 0
Pending tasks. Total 0
Tasks in process. Total 0
Regional Mastership TRUE
Total messages published 0
Time Zone -04:00
Orphaned Buddy Regions: None
GDS region regionora

4.4 Global Data Servicesの管理

この項では、Global Data Servicesに関連する管理タスクについて説明します。

4.4.1 GDSリージョンの管理

Global Data Servicesリージョンの追加に関する必知事項

必要なGlobal Data Servicesリージョンが1つのみの場合、この手順を使用して追加する必要はありません。Global Data Servicesカタログを作成すると、デフォルトのGlobal Data ServicesリージョンREGIONORAが作成されます。

たとえば:

GDSCTL> add region –region west,east

前述の例では、2つのリージョンeastおよびwestをGlobal Data Servicesフレームワークに追加します。

Global Data Servicesリージョンの名前は、対応するGlobal Data Services構成内で一意である必要があります。最初のリージョンの作成時に名前を指定しない場合、そのリージョンにはoraregionというデフォルト名が付けられます。リージョン名の長さは最大30文字で、任意の有効な識別子(先頭は英字でその後に0個以上のASCII英数字または「_」を続ける)を使用できます。

既存のリージョンの構成パラメータを変更するには、modify regionコマンドを使用します: 

GDSCTL> modify region -region west -buddy east

ここで、-buddyは"バディ"リージョンを示します。

グローバル・サービス管理フレームワークから指定されたリージョンを削除するには、remove regionコマンドを使用します: 

GDSCTL> GDSCTL> remove region -region south

4.4.2 GDSプールの管理

Global Data Servicesプールの追加

Global Data Servicesカタログに接続していることを確認し、次のようにして特定のユーザーによって管理されるプールを追加します。 

GDSCTL> add gdspool -gdspool database_pool_list [-users user_list]

必要なGlobal Data Servicesプールが1つのみの場合、この例を使用して追加する必要はありません。Global Data Servicesカタログを作成すると、デフォルトのGlobal Data ServicesプールDBPOOLORAが作成されます。

Global Data Services管理者は、GDSCTLコマンドを実行してGlobal Data Servicesプールを管理する権限を持ち、プールが1つのみの場合、Global Data Services管理者がプールも管理します。

gdsctl add gdspoolコマンドの実行時にユーザーを指定する場合、Global Data Servicesカタログが配置されている場所のローカルDBAは、まずカタログ・データベースにユーザーを追加する必要があります。

大規模データベース・クラウドでは、異なる管理者が管理する複数のGlobal Data Servicesプールが必要になることがあります。

たとえば:

GDSCTL> add gdspool -gdspool hr -users rjones

前述の例では、hrという名前のGlobal Data Servicesプールを追加し、ユーザーrjonesを追加します。このユーザーにはhrプールを管理する権限が割り当てられます。権限によって、プールの管理者は、データベースをプールに追加したり、プール内のデータベースでグローバル・サービスを管理したりできます。

Global Data Servicesプールには、そのGDS構成内で一意の名前を付ける必要があります。作成時にプールの名前を指定しない場合、その名前はデフォルトでoradbpoolになります。プール名の長さは最大30バイトで、任意の有効な識別子(先頭は英字でその後に0個以上のASCII英数字またはアンダースコア(_)を続ける)を使用できます。

modify gdspoolコマンドを使用して、GDSプールの構成パラメータを変更します: 

GDSCTL> modify gdspool -gdspool hr -adduser psmith

remove gdspoolコマンドを使用して、現在の構成からGDSプールを削除します: 

GDSCTL> remove gdspool -gdspool tempreaders,myfarm

4.4.3 メンバー・データベースの管理

グローバル・サービスを提供するには、データベースがGlobal Data Servicesプールに追加されている必要があります。

データベースをプールに追加する前に、次の例に示すように、データベース管理者はGSMUSERアカウントのロックを解除し、Global Data Servicesプール管理者にパスワードを付与する必要があります。 

ALTER USER gsmuser ACCOUNT UNLOCK;
ALTER USER gsmuser IDENTIFIED BY password;

Global Data Servicesプールに含めるには、データベースでサーバー・パラメータ・ファイル(SPFILE)が使用される必要があります。Oracle RACデータベースにはSCAN設定も必要です。

データベースを追加をするには:

  1. 次のようにGlobal Data ServicesプールまたはGlobal Data Services管理者の資格証明を使用してGlobal Data Servicesカタログに接続します。
    GDSCTL> connect rjones@catalog
  2. gdsctl add databaseコマンドを実行します。
    GDSCTL>add database -connect edc007:1521/db14.east.example.com -region east
 -gdspool hr

    この例では、edc007:1521/db14.east.example.comがデータベースの接続識別子であり、このデータベースのGSMUSERアカウント・パスワードを求めるプロンプトが表示されます。

ノート:

プールにすでにデータベースが含まれ、プールにグローバル・サービスが関連付けられている場合、サービスは新しいデータベースで自動的に作成されます。

modify databaseコマンドを使用して、GDSプールのデータベースの構成パラメータ(リージョン、接続識別子、グローバル・サービス・マネージャのパスワード、SCANアドレス、ONSポートなど)を変更します: 

GDSCTL> modify database -database db1,db3 -region east

remove databaseコマンドを使用して、GDSプールからデータベースを削除します: 

GDSCTL> remove database -database db1 -gdspool pool1
4.4.3.1 登録用有効ノード・チェック

登録用有効ノード・チェック(VNCR)機能では、グローバル・サービス・マネージャによって許可された登録リクエストのIPアドレス、ホスト名またはサブネットのセットの構成や動的な更新が可能になります。データベース・インスタンスのグローバル・サービス・マネージャでの登録は、リクエストが有効なノードからの場合にのみ成功します。

デフォルトでは、gdsctl add databaseコマンドが実行されるたびに、Global Data Servicesフレームワークは、リモート・データベースが実行されているホストのVNCRエントリを自動的に追加します。この自動化機能(自動VNCR)では、ホスト名エントリがローカルhostsファイルまたはネーム・サーバーのいずれかに存在する必要があります。グローバル・サービス・マネージャが実行されるいずれかのノードでリモート・ホストが異なる名前で識別される場合、Global Data Services管理者は、gdsctl add invitednodeコマンドを実行してGlobal Data Servicesカタログに手動でVNCRエントリを追加する必要があります。

関連項目:

使用方法の詳細は、「add invitednode (add invitedsubnet)」を参照してください

4.4.3.2 データベース・プールへのOracle Data Guard Broker管理データベースの追加

Global Data Services構成にOracle Data Guard Broker構成を含める場合、ブローカ構成は一体として管理します。Oracle Data Guard Broker構成全体でのみデータベース・プールに追加(または削除)できます。構成は複数のプールにまたがることができません。ブローカ構成に属する個々のデータベースをプールに追加または削除しようとすると、エラーになります。

データベースをプールに追加する唯一の方法は、データベースを(DGMGRLユーティリティを使用して)ブローカ構成に追加することです。データベースをブローカ構成に追加すると、この構成が属するデータベース・プールに自動的に追加されます。データベースをブローカ構成から削除すると、構成が含まれるプールから削除されます。これが、ブローカ構成を含むプールからデータベースを削除する唯一の方法です。

また、次の制限に注意してください。

  • データベース・プール内のデータベースのセットは次のいずれかです。

    • 1つのブローカ構成に属するデータベースのセット

    • ブローカ構成に属さないデータベースのセット

    ブローカ構成は空のデータベース・プールにのみ追加できます。プールにすでにブローカ構成が含まれている場合、データベースをデータベース・プールに追加するには、データベース・プールに含まれているブローカ構成にデータベースを追加する必要があります。

  • ロールベースのグローバル・サービスは、ブローカ構成を含むデータベース・プールについてのみサポートされます。

関連項目:

DGMGRLユーティリティの詳細は、『Oracle Data Guard Broker』を参照してください

4.5 グローバル・サービスの管理

この項では、グローバル・サービスに関連する管理タスクについて説明します。次の項目が含まれます。

4.5.1 グローバル・サービスの作成

グローバル・サービスは、add serviceコマンドを実行して作成します。このコマンドは、グローバル・サービスをGlobal Data Servicesプールに関連付け、サービスの属性をGlobal Data Servicesカタログに格納します。—preferredオプションまたは—availableオプションを使用してデータベースが指定された場合、サービスは指定されたそれらのデータベースで作成されます。—preferred_allオプションが使用された場合、サービスはGlobal Data Servicesプール内のすべてのデータベースで作成されます。たとえば: 

GDSCTL>add service -service sales_sb -preferred_all -gdspool sales -
notification TRUE

次の場合、Global Data Servicesプールにすでに存在するサービスはデータベースで自動的に作成されます。

  • サービスが変更され、プールの一部であるデータベースを追加します。

  • サービスが—preferred_all属性を持ち、新規データベースがプールに追加されます。

これが、複数のインスタンスとともに追加されるOracle RACデータベースである場合は、サービスを変更してそれらのデータベース・インスタンスを追加する必要があります。

GDSCTL>modify service -gdspool sales -service sales_sb -database mts -
add_instances -preferred mts1,mts2
GDSCTL>modify service -gdspool sales -service sales_sb -database stm -
add_instances -preferred stm1,stm2
GDSCTL>start service -service sales_sb -gdspool sales

関連項目:

add service

4.5.2 グローバル・サービスの起動

gdsctl start serviceコマンドを使用して、Global Data Servicesプール・データベースで既存のサービスを起動します。 

GDSCTL>start service -service emp_report1 -gdspool hr

サービスに-roleパラメータが指定されている場合、サービスは、指定された値にロールが適合するデータベースでのみ起動します。サービスに-lagパラメータが指定されている場合、サービスは、レプリケーション・ラグが指定された値を超えないデータベースでのみ起動します。サービスに-preferred_allが指定されていない場合、サービスは、サービスの優先データベースとしてリストされているデータベースでのみ起動します。

関連項目:

start service

modify service

グローバル・サービスは、作成後すぐに自動的に有効化されます。有効化とは、データベースがサービスの実行に適している(つまり、次の条件に合う)場合にデータベースでサービスを起動できるということです。

  • データベースがオープンしており、グローバル・サービス・マネージャに登録されています。

  • サービスがそのデータベースで無効になっていません。

  • データベース・ロールがサービスのロール属性に適合します。

  • データベースのレプリケーション・ラグがサービスに指定された最大値を超えていません。

  • サービスが優先データベースの数によって定義されるカーディナリティに達していません。

  • サービスの起動により適したデータベースがプール内に他にありません。たとえば、適切な優先データベースがない場合にのみ使用可能なデータベースでサービスが起動されます。

新たに作成されたグローバル・サービスは、ユーザーによってstart serviceコマンドが実行される前に自動的に起動されることはありません。これは、プール管理者がサービスの最初の起動を制御できるということです。このことは、複数のサービスがプールに追加され、サービスを特定の順序で起動する必要がある場合に重要です。

自動管理ポリシー(デフォルト・オプション)のサービスは、最初は-databaseオプションなしでstart serviceコマンドを実行して起動される必要があります。このコマンドはプール内のすべての適切なデータベースでサービスを起動するだけでなく、次の場合のサービスの自動起動を有効にします。

  • サービスの実行に適したデータベースでサービスが自動的に作成された後。(サービスが自動的に作成される2つの場合については前述の項にリストされています。)

  • 停止していたデータベースが再起動され、サービスに適しています。

  • データベースがサービスの実行に適するようになりました。これは、データベースのレプリケーション・ラグが許容可能な値に下がった場合やサービス・カーディナリティをユーザーが増やした場合などに起こります。

「グローバル・サービスの停止」で説明されているstop serviceコマンドを使用してサービスが停止されていた場合、-databaseオプションを使用したstart serviceコマンドで、自動管理ポリシーを持つサービスをそのデータベースで起動できます。

手動ポリシーを持つサービスは、データベースが再起動された場合やサービスの実行に適するようになった場合を含め、各データベースで手動で起動される必要があります。手動ポリシーを持つサービスに対して実行される場合、-databaseオプションなしのstart serviceコマンドは、プール内に現在存在するすべての適切なデータベースでサービスを起動します。-databaseオプション付きで使用すると、このコマンドは、指定したデータベースでのみサービスを起動します(それらが実行に適している場合)。

ノート:

この項に示されたサービスの自動起動が説明しているのは、start serviceコマンドが自動管理ポリシーを持つサービスに対して実行された場合の処理についてのみです。別のデータベースからのフェイルオーバーによってサービスがデータベースで自動的に起動される場合は含まれていません。サービスのフェイルオーバーはstart serviceコマンドと関連性はなく、自動管理ポリシーを持つサービスと手動管理ポリシーを持つサービスで同じように動作します。

4.5.3 グローバル・サービスの停止

Global Data Servicesプール内のデータベースで実行されているグローバル・サービスは、stop serviceコマンドで停止できます。-databaseオプションを指定してstop serviceコマンドを実行すると、指定したデータベースのサービスが停止します。指定しない場合は、プール内のすべてのデータベースのサービスが停止します。たとえば: 

GDSCTL>stop service -gdspool readerfarm -service sales_report

ノート:

停止したサービスのポリシーが自動管理の場合、サービスが実行されていたデータベースが再起動され、サービスの実行に適している場合は、サービスが再起動されます。また、Global Data Servicesプール内のすべてのデータベースで自動管理ポリシーを持つサービスを停止しても、新規データベースでサービスが作成されると、そのサービスは自動起動されます。サービスの自動起動を完全に無効にするには、管理ポリシーを手動に変更します。

サービスがユーザーによって停止された場合、Global Data Servicesフレームワークではデータベースがこのサービスに対して一時的に使用できなくなっているとみなされます。グローバル・サービスの停止によってサービスがフェイルオーバーされることはありません。サービス・カーディナリティが一時的に下げられ、グローバル・サービス・マネージャはプール内の別のデータベースでサービスを起動しようとしません。

ただし、停止されたサービスを含むデータベースは、依然としてこのサービスのフェイルオーバー・ターゲットとみなされます。別のデータベースでサービスに障害が発生した場合、このデータベースがサービスの実行に適していれば、このデータベースでサービスが起動されます。サービスがあるデータベースにフェイルオーバーすると、そのデータベースのサービスはユーザーによって停止されたとみなされなくなります。

停止されたサービスは、start serviceコマンドを実行して手動で再起動できます。

関連項目:

stop service

4.5.4 グローバル・サービスの有効化

無効になったグローバル・サービスは、enable serviceコマンドを実行してデータベースで再度有効化できます。サービス管理ポリシーがAUTOMATICで、データベースがサービスの実行に適している場合、サービスは有効化されると自動的に起動されます。管理ポリシーがMANUALであるサービスは手動で起動する必要があります。サービスが有効になると、データベースがフェイルオーバー・ターゲットになります。

たとえば、データベース・プールREADERFARM内のデータベースDB1でサービスG_SALES_REPORTを有効にするには:

GDSCTL> enable service -gdspool readerfarm -service g_sales_report -database db1

関連項目:

add service

4.5.5 グローバル・サービスの無効化

グローバル・サービスはデータベースまたはデータベースのセットでdisable serviceコマンドを実行して無効にできます。無効になったサービスは、再度有効化されるまで起動できません。これには、別のデータベースからのサービス・フェイルオーバーも含まれます。無効になったサービスを含むデータベースはフェイルオーバー・ターゲットとみなされません。

サービスを無効にするには、サービスを停止する必要があります。サービスが実行されているデータベースに対してdisable serviceが実行されると、エラーになります。

データベース・プールREADERFARM内のすべてのデータベースでサービスG_SALES_REPORTを無効にして停止するには:

GDSCTL> disable service -gdspool readerfarm -service g_sales_report -database db1

関連項目:

enable service

4.5.6 グローバル・サービスの属性の変更

modify serviceコマンドを使用してグローバル・サービスの属性を変更します。サービスのプロパティ(ロール、最大ラグ、ロード・バランシングの方法など)の指定に加え、サービスの属性によって、サービスを実行するデータベースを定義します。したがって、modify serviceを使用して、データベースをサービスに追加したり、サービスから削除したり、あるデータベースから別のデータベースへサービスを移動したりできます。コマンドの実行の結果、Global Data Servicesプール内の1つ以上のデータベースでサービスの作成、削除、起動または停止が行われることがあります。

ほとんどのグローバル・サービスの属性は、サービスの作成時にadd serviceコマンドで指定され、変更の必要がある場合にのみ変更します。ただし、Oracle RACデータベースに関連するいくつかのサービス属性は、add serviceコマンドの実行直後にmodify serviceコマンドを実行して設定する必要があります。これらの属性には、サービス・プールの名前、インスタンス・カーディナリティ(UNIFORM/)や特定のOracle RACデータベースに固有の他のパラメータなどがあります。そのような属性はadd serviceコマンドで設定できません。このコマンドはGlobal Data Servicesプール内のすべてのデータベースに対して同じ値を持つ属性の指定のみに使用できるためです。

関連項目:

modify service

4.5.7 グローバル・サービスの削除

remove serviceコマンドは、Global Data Servicesカタログおよび作成されたすべてのデータベースからサービスを削除することで、Global Data Servicesプールからグローバル・サービスを削除します。サービスを削除にするには、サービスを停止する必要があります。

関連項目:

remove service

4.5.8 Global Data Servicesプールへのサービスの追加

gdsctl add serviceコマンドを使用して、Global Data Servicesプール・データベースでサービスを作成します。コマンドの単純な例を次に示します。 

GDSCTL> add service -gdspool hr -service emp_report1 -preferred_all

この例で、emp_report1はサービス名で、-preferred_allオプションはサービスがプール内のすべてのデータベースで通常実行されることを示します。

add serviceコマンドで指定するサービス名は、ドメイン修飾することも(sales.example.comなど)、しないことも(salesなど)可能です。指定した名前がドメイン修飾されていない場合、サービスはデフォルトのドメイン名である<GDS_pool_name>.<GDS_configuration_name>を使用して作成されますが、サービスを管理する後続のGDSCTLコマンドでは、より短いドメイン修飾なしの名前を使用できます。指定した名前がドメイン修飾されている場合、サービスを管理するために使用する後続のすべてのGDSCTLコマンドで、完全修飾ドメイン・サービス名を使用する必要があります。

Oracle RACが有効なプール・データベースの場合は、サービスが追加された後に、次の例に示すようにGDSCTL modify serviceを実行して、特定のグローバル・サービスを実行するOracle RACインスタンスを指定します。 

GDSCTL> modify service -service emp_report1 -gdspool hr - database db14
 -modify_instances -preferred db14_n1, db14_n2

グローバル・サービス名は、GDSプール内で一意である必要があり、ドメイン修飾されている場合はGDS構成内でも一意である必要があります。グローバル・サービスは、データベースに同じ名前のローカル・サービスまたはグローバル・サービスがすでに存在する場合、そのデータベースで作成できません。

グローバル・サービス名には、英数字、「_」および「.」を含めることができます。最初の文字は英数字にする必要があります。グローバル・サービス名の長さは最大64文字です。ドメイン修飾されたグローバル・サービス名の長さは、最大250文字です。

グローバル・サービスに接続するために使用されるOracle Net接続記述子には、ドメイン修飾されたサービス名を含める必要があります。

関連項目:

使用方法の詳細は、add serviceおよびmodify serviceを参照してください

4.5.9 リージョン間のグローバル・データ・サービス・フェイルオーバーのフロー

  1. 管理者が、本番データベースをセカンダリ・サイトにフェイルオーバーまたはスイッチオーバーしました。この操作は、Data Guardファスト・スタート・フェイルオーバーを使用している場合は自動的に処理されます。
  2. 管理者が、セカンダリ・サイトにある中間層アプリケーション・サーバーを起動します(まだ実行されていない場合)。
  3. セカンダリ・サイトのワイドエリア・トラフィック・マネージャの選択は、サイト全体の障害が発生した場合に自動的に実行できます。セカンダリ・サイトにあるワイドエリア・トラフィック・マネージャによって、セカンダリ・サイトにあるロード・バランサの仮想IPアドレスが返され、後続の再接続でクライアントが自動的に方向付けされます。このシナリオでは、サイト・フェイルオーバーは自動ドメイン・ネーム・システム(DNS)フェイルオーバーによって実行されます。
  4. 別の方法として、DNS管理者が、ワイドエリア・トラフィック・マネージャの選択をサイト全体または特定のアプリケーションのセカンダリ・サイトに手動で変更することもできます。

    次に、手動DNSフェイルオーバーの例を示します。

    • DNSをセカンダリ・サイトのロード・バランサを指すように変更します: プライマリ(プライマリ)DNSサーバーは新しいゾーン情報で更新され、この変更がDNS NOTIFYで通知されます。
    • セカンダリDNSサーバーにDNS NOTIFY通知によってゾーンの更新が通知され、セカンダリDNSサーバーで、新しいゾーン情報が取得されます。
    • キャッシュDNSサーバーから関連するレコードをクリアします。

      キャッシュDNSサーバーは、主にパフォーマンスとレスポンス速度を向上するために使用します。キャッシュ・サーバーは、ホスト問合せに応答して権威DNSサーバーから情報を取得し、そのデータをローカルに保存(キャッシュ)します。同じデータに対する2回目のリクエストや後続のリクエストがあると、キャッシュDNSサーバーは、レスポンスの存続時間(TTL)値が期限切れになるまで、ローカルに保存したデータ(キャッシュ)を使用して応答します。期限切れになると、ゾーン・マスターからのデータはリフレッシュされます。DNSレコードがプライマリDNSサーバーで変更される場合、キャッシュDNSサーバーは、TTLが期限切れになるまでキャッシュされたレコードの変更を取得しません。キャッシュをフラッシュすることでキャッシュDNSサーバーを強制的に権威DNSサーバーに再接続し、更新されたDNS情報を取得します。

    • キャッシュのフラッシュは、使用中のDNSサーバーがフラッシュ機能をサポートしている場合に実行します。標準DNS BINDバージョンのフラッシュ機能は、次のとおりです:
      • BIND 9.3.0: コマンドrndc flushname nameにより、キャッシュから個々のエントリをフラッシュします。
      • BIND 9.2.0および9.2.1: コマンドrndc flushにより、キャッシュをフラッシュできます。
      • BIND 8およびBIND 9(9.1.3以下): ネーム・サーバーを再起動してキャッシュをクリアします。
  5. ローカルDNSサービス・キャッシュをリフレッシュします。

    一部のオペレーティング・システムでは、DNS情報がローカル・ネーム・サービス・キャッシュにローカルにキャッシュされることがあります。その場合、DNSの更新を迅速に認識するには、このキャッシュもクリアする必要があります。

  6. セカンダリ・サイトのロード・バランサで、セカンダリ・サイトの中間層アプリケーション・サーバーにトラフィックを転送します。

4.5.10 正常なアプリケーション・スイッチオーバー

データベース・サービスは、計画済停止の間にワークロードを適切に管理するために使用されます。サービスを適切に作成する必要があり、アプリケーションでサービスから接続を取得する必要があります。

これらの推奨事項では、Oracle Universal Connection Pool (UCP)などのFAN対応接続プールを使用して、停止したサービスからアプリケーションの中断なく接続を正常に排出することを想定しています。アプリケーションでは、FAN対応接続プールをサポートしていない、長時間実行されているトランザクションがない他の接続タイプを使用できます。このようなアプリケーションは、メンテナンス・ウィンドウの前に接続を切断することをお薦めします。

次の推奨事項では、適切な時間にトランザクションが終了したときや最終的にインスタンスがメンテナンスのために停止されたときに一部のセッションを切断する方法について説明します。

アプリケーションの接続構成を理解し最適化するためのお薦めの検証された方法については、次の項で説明します。一部のアプリケーションには、従う必要がある特定のガイドラインがある場合があります。

アプリケーションによる接続の使用についての理解

どのようにアプリケーションで接続が取得され解放されるかを理解することは、それでクラスタ内の他のインスタンスに正常に切り替えることができるかどうかを判断するために重要です。

アプリケーションについて次の情報を特定します:

  • 計画済停止の間にどのようなワークロードがあったか(OLTP/短期またはバッチ/長期トランザクション)?

    • UCPやODP.NETなどの接続プールを使用する短期トランザクションは、迅速に静止できます。

    • 長期トランザクションでは、静止のためにさらに時間が必要であるか、または適切なタイミングで事前にバッチ・ジョブを停止またはキューに入れる必要があります。

  • どのタイプの接続を取得したか(Java、OCI、C#を使用したODP、またはOCIを使用したODP)?

    • UCP、ICC、ODP.NETおよびOCIセッション・プールでは、高速アプリケーション通知(FAN)を使用してプールが迅速に排出されます。他の接続では、接続がクローズ(または、アプリケーションで許可されている場合は終了)されるまで待つ必要があります。

  • 接続プールでサービスが静止されるまでの待機時間はどれくらいか?

    • 接続の切断が実行されるまでに適切な時間が与えられていることを把握するのに役立ちます

  • トランザクションの完了(バッチ・ワークロードへの適用)後にアプリケーションで接続の切断に対応できるか?

    • アプリケーションで正常に接続の切断に対応できない場合は、計画メンテナンスの前にそれを停止する必要があります。つまり、アプリケーション・コンティニュイティが中断を回避するためのオプションになります。

サービスおよびアプリケーション構成のベスト・プラクティス

正常なスイッチオーバーを実行するには、サービスおよびアプリケーションの属性を適切に構成しておく必要があります。検証済のドライバおよびアプリケーション・クライアントのマトリックスについては、My Oracle SupportのドキュメントID 1617163.1を参照してください。

ノート:

本番環境で構成を使用する前に、その構成をテストして、それが設定されておりスイッチオーバーが正しく実行されることを確認する必要があります。

4.6 GDSのパッチ適用とアップグレード

Global Data Servicesのアップグレードに関する必知事項

分散Global Data Servicesインフラストラクチャを構成するコンポーネントは4つあり、各コンポーネントは個別のインストール環境に存在し、通常のアップグレード手順を使用して単体でアップグレードできますが、コンポーネントのバージョニングに関して準拠する必要のある一定のルールがあります。各コンポーネントとそのルールは次のとおりです。

  • カタログ・データベース: カタログ・データベースは、GDSメタデータの中央リポジトリで、標準的なOracle Databaseインストールです。カタログ・データベースのバージョンは、常にそれに接続する任意のGDSCTLセッションのバージョン以上であり、それに接続する任意のグローバル・サービス・マネージャ・サーバーのバージョンと正確に一致する必要がありますが、これには1つ例外があり、移行の簡略化のため、カタログは、それが変更されるまで、一時的にそれに接続しているグローバル・サービス・マネージャ・サーバーより大きいバージョンになることが可能で、変更があると、同じバージョンではない接続済のグローバル・サービス・マネージャは切断され、同じバージョンではない停止済のグローバル・サービス・マネージャは接続を禁止されます。

  • GDSCTLクライアント: このコンポーネントは、グローバル・サービス・マネージャ・インストールを含む任意のシステム上のターミナル・セッションからアドホック形式で実行されます。GDSCTLクライアントのバージョンは、その実行元のグローバル・サービス・マネージャ・インストールのバージョンです。

  • グローバル・サービス・マネージャ・サーバー: グローバル・サービス・マネージャ・サーバーのバージョンは、そのサーバーの実行元のグローバル・サービス・マネージャ・インストールのバージョンです。グローバル・サービス・マネージャ・サーバーは、自身より小さいバージョンのカタログ・データベースに接続できません。グローバル・サービス・マネージャ・サーバーは、自身より大きいバージョンでカタログがすでに変更されている場合、そのバージョンのカタログ・データベースに接続できません。

  • プール・データベース: プール・データベースは、グローバル・サービスを実行するGDSプールに追加された任意のデータベースです。プール・データベースは、いつでもアップグレードまたはダウングレードできます。

これらのルールに従うことで、サービス停止時間なしで分散GDSインフラストラクチャのローリング・アップグレードを実行できます。

ノート:

アップグレードおよびパッチ適用に関する一般情報は、『Oracle Databaseアップグレード・ガイド』を参照してください。

ノート:

Oracle Databaseプロアクティブ・パッチ情報については、Oracleサポート(MOS)ノート2521164.1を参照してください

4.6.1 Global Data Servicesのアップグレード

推奨されるアップグレード順序は次のとおりです。

  1. カタログ・データベースをアップグレードします。最高の結果を得るには、ローリング・データベース・アップグレードを使用してこれを実行する必要があります(ただし、カタログが使用できない場合、アップグレード中にグローバル・サービスは引き続き使用可能ですが、サービス・フェイルオーバーは発生しません)。
  2. GDSCTLクライアントを実行するために使用されるグローバル・サービス・マネージャ・インストールをアップグレードします(存在する場合でも、グローバル・サービス・マネージャ・サーバーは実行しません)。

    ノート:

    グローバル・サービス・マネージャのアップグレードはインプレースで実行する必要がありますが、次のプラットフォームの各ファイルに対するアクセス権が755に更新されていない場合、インプレース・アップグレードによって間違ったエラー・メッセージが表示されます。

    Linux/Solaris64/Solaris Sparc64の場合:

    $ORACLE_HOME/QOpatch/qopiprep.bat

    $ORACLE_HOME/jdk/bin/jcontrol

    $ORACLE_HOME/jdk/jre/bin/jcontrol

    AIXの場合:

    $ORACLE_HOME/QOpatch/qopiprep.bat

    $ORACLE_HOME/jdk/jre/bin/classic/libjvm.a

    $ORACLE_HOME/jdk/bin/policytool

    HPIの場合:

    $ORACLE_HOME/jdk/jre/lib/IA64N/server/Xusage.txt

    $ORACLE_HOME/jdk/jre/bin/jcontrol

    $ORACLE_HOME/QOpatch/qopiprep.bat

    Windowsでは、エラー・メッセージは予期されません。

  3. すべてのグローバル・サービス・マネージャ・サーバーの停止、アップグレードおよび再起動を1つずつ行います。停止時間をなくすには、必ず1つ以上のグローバル・サービス・マネージャ・サーバーが実行されている必要があります。カタログより前のバージョンのグローバル・サービス・マネージャ・サーバーは、カタログに変更が発生するまで完全に動作し続けます。
  4. プール・データベース管理者の判断で、グローバル・サービス・マネージャとカタログ・データベースのアップグレードの前か後に、任意の順序でプール・データベースをアップグレードします。

4.6.2 GSMのホーム外更新/パッチ適用の例

この例では、19.18 Database Realease Update (DBRU)を19.3 Oracle環境に適用するために必要な手順を示します。前提は次のとおりです。
  • ホストAに1つの19.3.0.0.0 GDSカタログ・データベースが存在すること
  • ホストBに2つの19.3.0.0.0 GSM (GSM1およびGSM2)が存在すること。GSM1がORACLE_HOME1にインストールされており、GSM2がORACLE_HOME2にインストールされていること
  • 19.3.0.0.0 Oracleプール・データベースのペアがそれぞれホストCとホストDに存在すること。

GDSカタログ、GSM 2つおよびプール・データベース2つに19.18.0.0.0 DBRUを

  1. GDSカタログ・データベースを停止し、19.18.0.0.0DBRUを適用してから、GDSカタログ・データベースを起動します。
    $ORACLE_HOME/OPatch/opatch lspatches
34765931;DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)

OPatch succeeded.
    SQL> select PATCH_ID, PATCH_UID, INSTALL_ID, STATUS, ACTION, DESCRIPTION from DBA_REGISTRY_SQLPATCH;

  PATCH_ID  PATCH_UID INSTALL_ID STATUS                    ACTION
---------- ---------- ---------- ------------------------- ---------------
DESCRIPTION
--------------------------------------------------------------------------------
  29517242   22862832          1 SUCCESS                   APPLY
Database Release Update : 19.3.0.0.190416 (29517242)

  34765931   25098466          2 SUCCESS                   APPLY
DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)


SQL>
  2. 続行する前に、GSM設定が正しく機能していることを確認します(GDSカタログは19.18になり、GSMおよびプール・データベースはバージョン19.3です)。
  3. 次に、GSM1を停止し、GSM2が新しいマスターになるようにします。GSM1に19.18.0.0.0 DBRUを適用します。
    $ORACLE_HOME1/OPatch/opatch lspatches
34765931;DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)

OPatch succeeded.
    GDSCTL> config

Regions
------------------------
east                          
west                          

GSMs
------------------------
gsm1                          
gsm2                          

GDS pools
------------------------
sdbpool                       

Databases
------------------------
cloud                         
clouddb                       

Services
------------------------
srv1                          

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

Global properties
------------------------
Name: orasampl
Master GSM: gsm2
DDL sequence #: 0


GDSCTL>
  4. 次に、GSM1を起動し、GSM2を停止し(GSM1が新しいマスターになるようにします)、GSM2に19.18.0.0.0 DBRUを適用してから、GSM2を起動します。
    $ORACLE_HOME2/OPatch/opatch lspatches
34765931;DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)

OPatch succeeded.


GDSCTL> config

Regions
------------------------
east                          
west                          

GSMs
------------------------
gsm1                          
gsm2                          

GDS pools
------------------------
sdbpool                       

Databases
------------------------
cloud                         
clouddb                       

Services
------------------------
srv1                          

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

Global properties
------------------------
Name: orasampl
Master GSM: gsm1
DDL sequence #: 0

GDSCTL>
  5. GSM環境が正しく機能することを確認します。GDSカタログおよびGSMのバージョンは19.18になり、プール・データベースのバージョンは19.3のままです)。
  6. 1つ目のプール・データベースを停止し、19.18.0.0.0 DBRUを適用します。完了したら、そのデータベースを起動します。
    $ORACLE_HOME/OPatch/opatch lspatches
34765931;DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)

OPatch succeeded.

SQL> select PATCH_ID, PATCH_UID, INSTALL_ID, STATUS, ACTION, DESCRIPTION from DBA_REGISTRY_SQLPATCH;

  PATCH_ID  PATCH_UID INSTALL_ID STATUS                    ACTION
---------- ---------- ---------- ------------------------- ---------------
DESCRIPTION
--------------------------------------------------------------------------------
  29517242   22862832          1 SUCCESS                   APPLY
Database Release Update : 19.3.0.0.190416 (29517242)

  34765931   25098466          2 SUCCESS                   APPLY
DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)

SQL>
  7. 2つ目のプール・データベースを停止し、19.18.0.0.0 DBRUを適用してから、そのデータベースを再起動します。
    $ORACLE_HOME/OPatch/opatch lspatches
34765931;DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)

OPatch succeeded.

SQL> select PATCH_ID, PATCH_UID, INSTALL_ID, STATUS, ACTION, DESCRIPTION from DBA_REGISTRY_SQLPATCH;

  PATCH_ID  PATCH_UID INSTALL_ID STATUS                    ACTION
---------- ---------- ---------- ------------------------- ---------------
DESCRIPTION
--------------------------------------------------------------------------------
  29517242   22862832          1 SUCCESS                   APPLY
Database Release Update : 19.3.0.0.190416 (29517242)

  34765931   25098466          2 SUCCESS                   APPLY
DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)

SQL>
  8. GSM設定が正しく機能することを確認します。これで、GDSカタログ、GSMおよびプール・データベースのバージョンが19.18.0.0.0になりました
    GDSCTL> config

Regions
------------------------
east                          
west                          

GSMs
------------------------
gsm1                          
gsm2                          

GDS pools
------------------------
sdbpool                       

Databases
------------------------
cloud                         
clouddb                       

Services
------------------------
srv1                          

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

Global properties
------------------------
Name: orasampl
Master GSM: gsm1
DDL sequence #: 0


GDSCTL> 


GDSCTL> databases;
Database: "cloud" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: east
   Service: "srv1" Globally started: Y Started: Y
            Scan: N Enabled: Y Preferred: Y
   Registered instances:
     sdbpool%1
Database: "clouddb" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: west
   Service: "srv1" Globally started: Y Started: N
            Scan: N Enabled: Y Preferred: N
   Registered instances:
     sdbpool%11

GDSCTL> 


GDSCTL> status database;
Database: "cloud" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: east
   Service: "srv1" Globally started: Y Started: Y
            Scan: N Enabled: Y Preferred: Y
   Registered instances:
     sdbpool%1
Database: "clouddb" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: west
   Service: "srv1" Globally started: Y Started: N
            Scan: N Enabled: Y Preferred: N
   Registered instances:
     sdbpool%11

GDSCTL> 


GDSCTL> status service;
Service "srv1.sdbpool.orasampl" has 1 instance(s). Affinity: ANYWHERE
   Instance "sdbpool%1", name: "cloud", db: "cloud", region: "east", status: ready.

GDSCTL>
4.6.2.1 GSM_HOMEを19.18.0.0.0 DBRUにし、既存のGSMを同じホスト上の新しいホームに移動
  1. 19.3.0.0.0 GSM (GSM3)をORACLE_HOME3にインストールし、19.18.0.0.0 DBRUを適用します。
    $ORACLE_HOME3/OPatch/opatch lspatches
34765931;DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)

OPatch succeeded.
  2. gsm.ora、tnsnames.oraおよびgsmwalletディレクトリを古い$TNS_ADMINフォルダから新しいフォルダにコピーします。
  3. 古いGSM1ホームからGSM1を停止します。
    GDSCTL> stop gsm -gsm gsm1;
GSM is stopped successfully
GDSCTL>
  4. gsm.oraの下の新しいGSM_HOMEを指すようにWALLET_LOCATIONディレクトリを変更します。
  5. 新しいGSM3ホームからGSM3を起動します
    GDSCTL> start gsm -gsm gsm1;
GSM is started successfully
GDSCTL>
  6. 新しいホームからmodify gsm -gsm <gsm name>を実行します。
    GDSCTL> modify gsm -gsm gsm1
GSM modified
GDSCTL>
  7. 19.3.0.0.0 GSM4をORACLE_HOME4にインストールし、19.18.0.0.0 DBRUを適用します。
    $ORACLE_HOME4/OPatch/opatch lspatches
34765931;DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)
OPatch succeeded.
  8. gsm.ora、tnsnames.oraおよびgsmwalletディレクトリを古い$TNS_ADMINフォルダから新しいフォルダにコピーします。
  9. 古いGSM2ホームからGSM2を停止します。
    GDSCTL> stop gsm -gsm gsm2;
GSM is stopped successfully
GDSCTL>
  10. gsm.oraの下の新しいGSM_HOMEを指すようにWALLET_LOCATIONディレクトリを変更します。
  11. 新しいGSM4ホームからGSM4を起動します。
    GDSCTL> start gsm -gsm gsm2;
GSM is started successfully
GDSCTL>
  12. 新しいホームからmodify gsm -gsm <gsm name>を実行します。
    GDSCTL> modify gsm -gsm gsm2
GSM modified
GDSCTL>
  13. 新しいGSM環境を確認します。
    GDSCTL> config

Regions
------------------------
east                          
west                          

GSMs
------------------------
gsm1                          
gsm2                          

GDS pools
------------------------
sdbpool                       

Databases
------------------------
cloud                         
clouddb                       

Services
------------------------
srv1                          

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

Global properties
------------------------
Name: orasubbu
Master GSM: gsm1
DDL sequence #: 0


GDSCTL> 


GDSCTL> databases;
Database: "cloud" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: east
   Service: "srv1" Globally started: Y Started: Y
            Scan: N Enabled: Y Preferred: Y
   Registered instances:
     sdbpool%1
Database: "clouddb" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: west
   Service: "srv1" Globally started: Y Started: N
            Scan: N Enabled: Y Preferred: N
   Registered instances:
     sdbpool%11

GDSCTL>


GDSCTL> status database;
Database: "cloud" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: east
   Service: "srv1" Globally started: Y Started: Y
            Scan: N Enabled: Y Preferred: Y
   Registered instances:
     sdbpool%1
Database: "clouddb" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: west
   Service: "srv1" Globally started: Y Started: N
            Scan: N Enabled: Y Preferred: N
   Registered instances:
     sdbpool%11

GDSCTL> 


GDSCTL> status service;
Service "srv1.sdbpool.orasubbu" has 1 instance(s). Affinity: ANYWHERE
   Instance "sdbpool%1", name: "cloud", db: "cloud", region: "east", status: ready.

GDSCTL>
4.6.2.2 GSM_HOMEを別のホスト上の19.18.0.0.0 DBRUに
  1. 19.3.0.0.0 GSM1をORACLE_HOME1にインストールし、19.18.0.0.0 DBRUを適用します。
    $ORACLE_HOME1/OPatch/opatch lspatches
34765931;DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)

OPatch succeeded.
  2. gsm.ora、tnsnames.oraおよびgsmwalletディレクトリをソース・ホストからターゲット・ホスト($GSM_HOME/network/admin)にコピーします。
  3. ソース・ホストでGSM1を停止します。
  4. gsm.oraファイルでターゲット・ホスト、およびターゲット・ホストのウォレット・ディレクトリに変更し、GSM1エントリについてtnsnames.oraファイル内のターゲット・ホストを変更します。
  5. そのGSM構成でそのエンドポイント・エントリに変更し、config gsmで正しいターゲット・ホスト詳細が指し示されることを確認します。たとえば:
    GDSCTL> modify gsm -gsm gsm1 -endpoint (ADDRESS=(HOST=myhost.example.com)(PORT=1587)(PROTOCOL=tcp))
GSM modified
GDSCTL> 


GDSCTL> config gsm
Name      Region    ENDPOINT                                                    
----      ------    --------                                                    
gsm1      east      (address=(host=myhost.example.com)(port=1587)(protocol=tcp))                       
gsm2      west      (ADDRESS=(HOST=myhost.example.com)(PORT=1787)(PROTOCOL=tcp))                       

GDSCTL>
  6. 新しいGSM1ホームからGSM1を起動します。
    GDSCTL> start gsm -gsm gsm1;
GSM is started successfully
GDSCTL>
  7. 次の例のようにmodify gsm -gsm <gsm name> -pwd <GSMCATUSER password>コマンドを実行します:
    GDSCTL> modify gsm -gsm gsm1 -pwd <GSMCATUSER secret_password>
GSM modified
GDSCTL>
GSM2で次の手順を実行します。
  1. 19.3.0.0.0 GSM2をORACLE_HOME2にインストールし、19.18.0.0.0 DBRUを適用します。
    /$ORACLE_HOME2/OPatch/opatch lspatches
34765931;DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)

OPatch succeeded.
  2. gsm.ora、tnsnames.oraおよびgsmwalletディレクトリをソース・ホストからターゲット・ホスト($GSM_HOME/network/admin)にコピーします。
  3. ソース・ホストでGSM2を停止します。
  4. gsm.oraファイルでターゲット・ホスト、およびターゲット・ホストのウォレット・ディレクトリに変更し、GSM2エントリについてtnsnames.oraファイル内のターゲット・ホストを変更します。
  5. そのGSM構成でそのエンドポイント・エントリに変更し、config gsmを使用して、それに正しいターゲット・ホスト詳細が含まれていることを確認します。
    GDSCTL> modify gsm -gsm gsm2 -endpoint (ADDRESS=(HOST=myhost.example.com)(PORT=1787)(PROTOCOL=tcp))
GSM modified
GDSCTL> 


GDSCTL> config gsm
Name      Region    ENDPOINT                                                    
----      ------    --------                                                    
gsm1      east      (address=(host=myhost.example.com)(port=1587)(protocol=tcp))                       
gsm2      west      (address=(host=myhost.example.com)(port=1787)(protocol=tcp))                       

GDSCTL>
  6. ターゲット・ホストでGSM2を起動します。
    GDSCTL> start gsm -gsm gsm2;

GSM is started successfully

GDSCTL>
  7. modify gsm -gsm <gsm name> -pwd <GSMCATUSER password>コマンドを実行します:
    GDSCTL> modify gsm -gsm gsm2 -pwd <GSMCATUSER secret_password>
GSM modified
GDSCTL>
  8. 新しいGSM環境を確認します。
    GDSCTL> config database;
Name                Pool                Status    State       Region    Availability 
----                ----                ------    -----       ------    ------------ 
cloud               sdbpool             Ok        none        east      ONLINE       
clouddb             sdbpool             Ok        none        west      ONLINE       

GDSCTL>


GDSCTL> config

Regions
------------------------
east                          
west                          

GSMs
------------------------
gsm1                          
gsm2                          

GDS pools
------------------------
sdbpool                       

Databases
------------------------
cloud                         
clouddb                       

Services
------------------------
srv1                          

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

Global properties
------------------------
Name: orasubbu
Master GSM: gsm1
DDL sequence #: 0


GDSCTL


GDSCTL> status database;
Database: "cloud" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: east
   Service: "srv1" Globally started: Y Started: Y
            Scan: Y Enabled: Y Preferred: Y
   Registered instances:
     sdbpool%1
Database: "clouddb" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: west
   Service: "srv1" Globally started: Y Started: N
            Scan: Y Enabled: Y Preferred: N
   Registered instances:
     sdbpool%11

GDSCTL>


GDSCTL> databases;
Database: "cloud" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: east
   Service: "srv1" Globally started: Y Started: Y
            Scan: Y Enabled: Y Preferred: Y
   Registered instances:
     sdbpool%1
Database: "clouddb" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: west
   Service: "srv1" Globally started: Y Started: N
            Scan: Y Enabled: Y Preferred: N
   Registered instances:
     sdbpool%11

GDSCTL>


GDSCTL> status service;
Service "srv1.sdbpool.orasubbu" has 1 instance(s). Affinity: ANYWHERE
   Instance "sdbpool%1", name: "cloud", db: "cloud", region: "east", status: ready.

GDSCTL>


GDSCTL> config gsm
Name      Region    ENDPOINT                                                    
----      ------    --------                                                    
gsm1      east      (address=(host=myhost.example.com)(port=1587)(protocol=tcp))                       
gsm2      west      (address=(host=myhost.example.com)(port=1787)(protocol=tcp))                       

GDSCTL>

4.7 GDS環境でのパスワード管理

GSMCATUSERのパスワードの変更

GSMCATUSERパスワードを変更するには、次のようにします。

  1. GDSカタログに接続した状態で、SQL*Plusで次のコマンドを実行します。
    ALTER USER gsmcatuser IDENTIFIED BY ****
  2. その後、GDSCTLで次のコマンドを実行します。
    GDSCTL> modify catalog -oldpwd oldpassword -newpwd newpassword

GSMUSRのパスワードは、PKCS 1暗号化/復号化スキーマを使用した暗号化形式でGDSカタログに格納されます。modify catalogコマンドを実行することで、GDSカタログに格納されたGSMUSRのパスワードを新しく生成されたキーによって暗号化できます。たとえば: 

GDSCTL> modify catalog -newkeys

GSMCATUSERアカウントとGSMUSERアカウントは、Global Data Servicesフレームワークのすべてのグローバル・サービス・マネージャによって共有され、グローバル・サービス・マネージャによって行われるすべての管理操作(サービス・フェイルオーバーなどの自動操作も含む)に使用されます。通常のユーザーはこれらのアカウントを使用してデータベースに接続しないでください。

GSMCATUSERアカウントおよびGSMUSERアカウントに加えて、GSMADMIN_INTERNALアカウントはGDS構成でも使用されます(カタログ・データベースとプール・データベースの両方で)。このアカウントの唯一の目的は、GDSインストールをサポートするために必要な表、パッケージおよびその他のオブジェクトを所有することです。ロック解除、パスワードの割当て、または対話型ログインには使用できません。

シャード環境では、GSMUSER、GSMCATUSERおよびGSMROOTUSERユーザーのパスワード・ローテーションを管理することが重要です。この管理タスクの実行方法の詳細は、Oracleサポートに移動し、ドキュメントID 3052933.1を参照してください。