Oracle Globally Distributed Databaseのパッチ適用およびアップグレード

分散データベースのデプロイへのパッチ適用およびアップグレードには、特別な考慮事項があります。

Oracle Globally Distributed Databaseのパッチ適用およびアップグレード

分散データベース環境へのOracleパッチの適用は、単一のシャードまたはすべてのシャードに対して実行できます。ただし、使用する方法は、その環境で使用されているレプリケーション・オプションおよび適用されるパッチのタイプによって異なります。

Oracle Globally Distributed Databaseでは統合パッチ適用を使用してシャード・ディレクタ(GSM)のORACLE_HOMEを更新するため、Oracle Databaseリリース更新をORACLE_HOMEに適用してセキュリティおよびグローバル・データ・サービスの修正を取得する必要があります。

分散データベースへのパッチ適用

ほとんどのパッチは、単一のシャードに一度に適用できます。ただし、一部のパッチはすべてのシャードに適用する必要があります。分散データベースで使用されているレプリケーション方法に留意して、非分散データベースの場合と同様に、Oracleのベスト・プラクティスを使用して単一のシャードにパッチを適用します。Oracleのopatchautoは、複数のシャードに一度にパッチを適用するために使用でき、ローリング形式で行うことができます。Data Guard構成は1つずつ適用され、場合によっては(パッチによって異なります) Standby Firstパッチ適用を使用できます。

パッチがマルチシャード問合せ、レプリケーションまたはシャーディング・インフラストラクチャの問題に対処するものである場合は、分散データベース内のすべてのシャードに適用する必要があります。

ノート:

ロジカル・スタンバイはOracle Shardingではサポートされていないため、ローリング・アップグレードではDDLリカバリの問題が発生する可能性があります。これは、ローリング・アップグレード中にフィジカル・スタンバイ・データベースが'一時ロジカル・スタンバイ'になるためです。この問題を回避するには、「ローリング・アップグレードの実行」にある手順に従います。

分散データベースへのアップグレード

Oracle Globally Distributed Database環境のアップグレードは、他のOracle Databaseおよびグローバル・サービス・マネージャ環境のアップグレードと大きな違いはありません。ただし、コンポーネントを特定の順序(最初にシャード・カタログ、次にシャード・ディレクタ、最後にシャード)でアップグレードする必要があります。

ローリング・アップグレードの実行

ロジカル・スタンバイはOracle Shardingではサポートされていないため、ローリング・アップグレードではDDLリカバリの問題が発生する可能性があります。これは、ローリング・アップグレード中にフィジカル・スタンバイ・データベースが'一時ロジカル・スタンバイ'になるためです。

この問題を回避するには、次のステップを実行します。

シャード・カタログ・データベースを停止します。
シャード・カタログ・データベースを停止すると、シャード・ディレクタ(GSM)がマスターにならなくなります。この状態ではカタログによってDDLの適用は試みられませんが、シャード・ディレクタは安定した状態で続行され、本番アプリケーションの接続と実行は可能になります。
ローリング・アップグレードを実行します。
ローリング・アップグレードが完了したら、シャード・カタログ・データベースを起動します。

ノート:

ローリング・アップグレードの間の、シャード・カタログの停止中に、一部の操作(自動フェイルオーバーなど)を使用できない場合があります。

Oracle Globally Distributed Databaseコンポーネントのアップグレード

コンポーネントが停止してオンライン状態に戻る際の停止時間を制限し、エラーを回避するには、Oracle Globally Distributed Databaseコンポーネントをアップグレードする順序が重要です。

Oracle Globally Distributed Databaseコンポーネントをアップグレードする前に、次のことが必要です

保留中のMOVE CHUNK操作が進行中の場合は、完了してください。
新しいMOVE CHUNK操作を開始しないでください。
アップグレード・プロセス中に新しいシャードを追加しないでください。

次の点に注意しながら、シャードをアップグレードします。
- システム管理の分散データベースの場合: Data Guard Broker構成内のシャードの各セットをローリング方式でアップグレードします。
- ユーザー定義の分散データベースの場合: シャード領域内のシャードの各セットをローリング方式でアップグレードします。
- コンポジット分散データベースの場合: 特定のシャード領域で、Data Guard Broker構成内のシャードの各セットをローリング方式でアップグレードします。
- プラガブル・データベース(PDB)シャードを含むOracle Database 18c分散データベース構成をアップグレードする場合は、Oracle Database 18cからの互換性と移行のPDB固有のアップグレード手順に従います。
シャード・カタログ・データベースをアップグレードします。

最高の結果を得るには、ローリング・データベース・アップグレードを使用してカタログをアップグレードする必要があります(ただし、カタログが使用できない場合、アップグレード中にグローバル・サービスは引き続き使用可能ですが、サービス・フェイルオーバーは発生しません)。
グローバル・サービス・マネージャを実行しているシャード・ディレクタを更新する前に、GDSCTLクライアントの実行に使用され、グローバル・サービス・マネージャ・サーバーを実行しないシャード・ディレクタをアップグレードします。
グローバル・サービス・マネージャを実行するシャード・ディレクタの場合、一度に1つのグローバル・サービス・マネージャで次のステップを実行します。
停止時間をゼロにするには、1つ以上のシャード・ディレクタ・サーバーが常に稼働している必要があります。カタログより前のバージョンのシャード・ディレクタ・サーバーは、カタログに変更が発生するまで完全に動作し続けます。
1. アップグレードするグローバル・サービス・マネージャの1つを停止します。
2. 23cグローバル・サービス・マネージャ・キットをインストールします
3. 前のバージョンから新しいバージョンにtnsnames.ora,gsm.ora,gsm_observer_1.dat,gsmwalletディレクトリをコピーします。
  
  gsm.oraファイルをコピーした後、編集する必要があります。WALLET_LOCATION DIRECTORYパスは古いホームであるgsmwalletディレクトリを指しているため、新しいOracleホームの場所を指すように更新する必要があります。
  
  理想的には、Oracleベース・ディレクトリのadminなど、Oracleホームの外部にあるディレクトリにウォレットを格納してください。
4. GDSCTLを使用して新しいバージョンに接続し、古いバージョンで停止されたグローバル・サービス・マネージャを起動します。
5. 古いグローバル・サービス・マネージャを停止してから、新しいグローバル・サービス・マネージャを起動します。

Oracle Globally Distributed Database 21cのアップグレード後のステップ

完全に運用可能なOracle Globally Distributed Database環境が21cより前のリリースに存在する場合、ウォレットは存在せず、21cへのアップグレード後にOracle Globally Distributed Databaseによってデプロイは実行されず、それらは作成されません。手動ステップを実行してウォレットを作成する必要があります。

ノート:

ステップはこの順序どおりに実行する必要があります。

ALTER USERを使用して、シャード・カタログ・データベースのGSMCATUSERパスワードを変更します。これにより、プライマリ・シャード・カタログにウォレットが自動的に作成されます。
```
SQL> alter user gsmcatuser identified by gsmcatuser_password;
```
この文では、シャード・ウォレット・ファイルが存在しない場合にファイルを作成しますが、以前のパスワードが再使用される場合にパスワードを変更しません。

両方のGSMCATUSERアカウントに同じパスワードを保持できますが、ALTER USERを実行してウォレットを作成する必要があります。
GSMCATUSERパスワードが変更された場合は、GDSCTL modify catalogを実行して、新しいGSMCATUSERパスワードでシステムを更新します。

GSMCATUSERパスワードが変更されなかった場合、このステップは必要ありません。
GSMCATUSERパスワードが変更された場合は、各シャード・ディレクタ(GSM)に対してGDSCTL modify gsmも実行し、新しいパスワードをシャード・ディレクタに通知します。

ここでも、GSMCATUSERパスワードが変更されなかった場合、このステップは必要ありません。
ALTER USERを使用して、各プライマリ・シャードのGSMUSERパスワードを変更します。これにより、そのシャードにウォレットが自動的に作成されます。
```
SQL> alter user gsmuser identified by gsmuser_password;
```
この文では、シャード・ウォレット・ファイルが存在しない場合にファイルを作成しますが、以前のパスワードが再使用される場合にパスワードを変更しません。

両方のGSMCATUSERアカウントに同じパスワードを保持できますが、ALTER USERを実行してウォレットを作成する必要があります。
GSMUSERパスワードが変更された場合は、各プライマリ・シャードでGDSCTL modify shardを実行して、そのシャードの新しいGSMUSERパスワードでシステムを更新します。

GSMUSERパスワードが変更されなかった場合、このステップは必要ありません。
各シャードでGDSCTL sync databaseを実行して、必要な情報をシャード・ウォレット・ファイルに移入します。
前述のステップをすべて完了した後、次に示す方法を使用してプライマリ・ウォレット・ファイルを探し、そのファイルをスタンバイ・データベースのwallet_rootの場所にコピーします。
すべてのスタンバイ・データベースには、そのプライマリに対応するウォレット・ファイルの同一のコピーが必要です。

これは、スタンバイ・シャード・カタログ(ある場合)にも適用されます。

ウォレットをコピーする前に、wallet_rootがスタンバイ・データベースに設定されていることを確認する必要があり、設定されていない場合は、ウォレット・ファイルをコピーする前に設定しておく必要があります。

wallet_rootは、コンテナ・データベース(CDB)にのみ設定できるグローバル・パラメータです。

ウォレット自体は、GDSCTL create shardcatalogコマンドではシャード・カタログとすべてのシャード・カタログ・レプリカに、GDSCTL deployコマンドではシャードに作成されます。

すべてのプライマリ・データベースとそのレプリカには、適切な動作を保証するために、シャーディング固有のウォレット・ファイルが存在する必要があります。ウォレット・ファイルの場所は、wallet_rootデータベース初期化パラメータで指定されたディレクトリ下です。create shardcatalogまたはdeployを実行する前に設定されていない場合、wallet_rootは、シャード・カタログまたはシャードでそれぞれ$ORACLE_BASE/admin/db_unique_nameに設定されます。

たとえば、シャード・カタログまたはシャードにログインした後は、次のとおりとします。
```
SQL> select guid from v$pdbs where con_id = sys_context('userenv','con_id');

GUID
--------------------------------
C23E7C78D5B77D50E0537517C40ACE4A

SQL> select value from v$parameter where name='wallet_root';

VALUE
--------------------------------------------------------------------------------
your-path-to-keystore
```
これらの値を指定すると、シャーディング固有のウォレット・ファイル名は次のようになります。

your-path-to-keystore/C23E7C78D5B77D50E0537517C40ACE4A/shard/cwallet.sso

Oracle Database 18cからの互換性と移行

特定のCDBに単一のPDBシャードを含むOracle Database 18cインストールからアップグレードする場合、PDBのシャード・カタログ・メタデータを更新する必要があります。

具体的には、18cのPDBシャードの名前はCDBのDB_UNIQUE_NAMEですが、それより後のOracle Databaseリリースのシャード名はdb_unique_name_of_CDB_pdb_nameです。

カタログ・メタデータを更新してこの新しいネーミング方法を反映し、GSMROOTUSERアカウントについての説明に従って新しいGSMROOTUSERアカウントもサポートするには、Oracle Globally Distributed Databaseコンポーネントのアップグレードの説明に従って、アップグレード・プロセス中に次のステップを実行します。

PDBシャードを含むCDBをアップグレードした後、GSMROOTUSERアカウントが存在し、ロック解除され、パスワードが割り当てられ、SYSDG、SYSBACKUPおよびgsmrootuser_role権限が付与されていることを確認します。
SQL*Plusの次のSQL文は、CDBのルート・コンテナ(CDB$ROOT)への接続中にGSMROOTUSERを正常に設定します。
```
SQL> alter session set "_oracle_script"=true;
Session altered.
     
SQL> create user gsmrootuser;
User created.

SQL> alter user gsmrootuser identified by new_GSMROOTUSER_password
  account unlock;
User altered.

SQL> grant sysdg, sysbackup, gsmrootuser_role to gsmrootuser container=current;
Grant succeeded.

SQL> alter session set "_oracle_script"=false;
Session altered.
```
カタログ・データベースを目的のOracle Databaseバージョンにアップグレードした後、次のPL/SQLプロシージャを実行して、構成に存在するPDBシャードの新しい名前を反映するようにカタログ・メタデータを更新します。
このプロシージャは、Oracle Database 18cのPDBシャードごとに実行する必要があります。

pdb_fixupの最初のパラメータは、PDBシャードを含むCDBのdb_unique_nameの値です。Oracle Database 18cでは、gdsctl config shardで示されるシャード名と同じです。

2番目のパラメータはシャードPDBのPDB名で、シャードPDBへの接続時にSQL*Plusのshow con_nameによって示されます。

pdb_fixupプロシージャは、カタログ・メタデータを更新して、PDBシャードの新しいネーミング・メソッドに対応させます。
```
SQL> connect sys/password as sysdba
Connected.
SQL> set serveroutput on
SQL> execute gsmadmin_internal.dbms_gsm_pooladmin.pdb_fixup('cdb1', 'pdb1');
```
すべてのシャード・ディレクタを目的のバージョンにアップグレードした後、構成内の各CDBに対して次のGDSCTLコマンドを実行し、各CDBのGSMROOTUSERのパスワードをシャード・ディレクタに通知します。
```
GDSCTL> modify cdb -cdb CDB_name -pwd new_GSMROOTUSER_password
```

Oracle Globally Distributed Databaseのダウングレード

Oracle Globally Distributed Databaseでは、ダウングレードはサポートされていません。

シャード・カタログおよびシャードはダウングレードできません。