環境の構成
スクリプトを使用して、いくつかのステップを自動化できます。これらのスクリプトは完全な設定を自動化しないため、タスクを完了し、参照時にスクリプトを使用できます。
リンクの「コードのダウンロード」に移動して、このドキュメントで参照されているスクリプトをダウンロードします。
プライマリ・データ・センターでのWebLogicデータ・ソースの準備
TNS別名がプライマリとセカンダリの同じ名前であるため、データソースで同じDB接続文字列が使用されます。これは、スタンバイにコピーされないtnsnames.oraファイルで解決されるため、サイトごとに異なるtnsnames.oraコンテンツを持つことができます。WebLogicドメイン構成とは別に、サイト間でレプリケートされないファイル・システムに配置できます。または、構成の一部である場合は、ドメイン構成の下のフォルダに格納することもできます。この場合、ドメイン構成をプライマリからスタンバイにコピーするときに、必ずそのフォルダを除外してください。各サイトでは、ローカル・データベースのみを指す、サイトごとに適切な接続文字列を使用して、TNS別名を解決します。例:
Connect string in data sources in primary site:
jdbc:oracle:thin:@mypdbservice
The tnsnames.ora file in primary contains:
MYPDBSERVICE =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=mypdbservice.example.com))
)
Connect string in data sources in secondary site:
jdbc:oracle:thin:@mypdbservice
The tnsnames.ora file in secondary:
MYPDBSERVICE =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=mypdbservice.example.com))
)TNS別名を使用する利点は次のとおりです。
- WebLogicドメインの
configで同じDB接続文字列を使用するため、configをプライマリからスタンバイにレプリケートした後にWebLogic構成を変更する必要はありません。 - 各サイトのみがローカル・データベースを指しているため、中間層からリモート・データベースへのクロス接続のリスクはありません。
プライマリWebLogicサーバー・システムでこのアプローチをまだ使用していない場合は、次のステップを実行してデータ・ソースでTNS別名を使用します。
ネットワークの構成
Oracle Data Guardを構成
データベースのバージョンとパッチ・レベルについて
オンプレミス・データベースとOCI上のスタンバイ・データベースのOracle Homeは同じバージョンで、同じパッチ・レベルである必要があります。次の方法で可能です。
- OCIでDB Systemのプロビジョニング中にデータベース・ソフトウェア・イメージを選択する場合は、「すべてのバージョンの表示」を選択し、オンプレミス・データベースと同じデータベース・バージョンおよびパッチ・セット・レベルを選択します。
- ソース・データベースのOracle Homeバージョンがプロビジョニング用にOCIで使用できなくなった場合、クラウド環境のデータベース・ホームと同じデータベース・パッチ・レベルにソース環境にパッチを適用する必要があります。
次のシナリオは参考例です。オンプレミスDBホームは19.6で、OCI DBホームは19.11です。
- コマンド
$ORACLE_HOME/OPatch/opatch lspatchesを実行して、ソース環境とターゲット環境の両方にインストールされているパッチを特定します。$ORACLE_HOME/OPatch/opatch lspatchesこの例の出力は次のとおりです。
DB Oracle Homeパッチ(オンプレミス) OCIでのDB Oracle HOMEパッチ 30676209; LNX64-20.1-RAC ASM HIT ORA-07445 EXCEPTION ENCOUNTERED CORE DUMP [KSXPOSDIFQRY()+556]
30613937; IPCOR TOPOサービス修正IPタイプバグIP選択
30484981; OJVMリリース更新: 19.6.0.0.200114 (30484981)
30489227; OCWリリース更新19.6.0.0.0 (30489227)
30557433; データベース・リリース更新: 19.6.0.0.200114 (30557433)
29780459; _LM_RES_HASH_BUCKETを増やし、バグ29416368修正から変更をバックアウト
30310195; DBSATがGSMADMIN_INTERNAL.SHARD_TSのシャーディングSTS_CHUNKSに対して無効化された制約を報告
32327201; RDBMS - DSTV36更新- TZDATA2020E
31335037; RDBMS - DSTV35更新- TZDATA2020A
30432118;19.0.0.0の上のバグ28852325 29997937のマージ要求
31732095;19CデータベースORACLEホームのPERLをV5.32に更新
32490416; JDKバンドル・パッチ19.0.0.0.210420
32399816; OJVMリリース更新: 19.11.0.0.210420 (32399816)
32579761; OCWリリース更新19.11.0.0.0 (32579761)
32545013; データベース・リリース更新: 19.11.0.0.210420 (32545013)
- 既存のパッチの分析: 個別パッチを決定し、新しいRUパッチですでに修正されているかどうか、または新しい重複パッチが必要かどうかを確認し、アンインストールする必要があるパッチを決定し、RUの適切なパッチ・ファイルを特定します。
- 分析に基づいて、RU更新をインストールする前に、新しいRUですでに修正されている個別パッチをアンインストールします(そうしないと、競合が発生します)。この例では、オンオフ・パッチは19.11で修正されているため、19.11 RUをインストールする前にパッチをロールバックする必要があります。
30676209;LNX64-20.1-RAC ASM HIT ORA-07445 EXCEPTION ENCOUNTERED CORE DUMP [KSXPOSDIFQRY()+556] 30613937;IPCOR TOPO SERVICE FIX IP TYPE BUG IN IP SELECTION - RUパッチの検索、ダウンロードおよびインストールを行います。この例では、19.11 RUパッチはコンボ・パッチ32578973: COMBO OF OJVM RU COMPONENT 19.11.0.0.210420 + GI RU 19.11.0.0.210420にあり、次のとおりです。
32399816;OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816) 32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761) 32545013;Database Release Update : 19.11.0.0.210420 (32545013) - OCI DBホームがRUの上にあるオーバーレイ、個別パッチおよびその他のパッチを検索、ダウンロードおよびインストールします。例:
29780459;INCREASE _LM_RES_HASH_BUCKET AND BACK OUT CHANGES FROM THE BUG 29416368 FIX 30310195;DBSAT REPORTED DISABLED CONSTRAINTS FOR SHARDING STS_CHUNKS ON GSMADMIN_INTERNAL.SHARD_TS 30432118;MERGE REQUEST ON TOP OF 19.0.0.0.0 FOR BUGS 28852325 (DSTV33 update) 29997937 (DSTV34 update) 31335037;RDBMS - DSTV35 UPDATE - TZDATA2020A 32327201;RDBMS - DSTV36 UPDATE - TZDATA2020E 32490416;JDK BUNDLE PATCH 19.0.0.0.210420 31732095;UPDATE PERL IN 19C DATABASE ORACLE HOME TO V5.32 - GIパッチに対して同様の分析を実行します。
ノート:
- Oracle Data Guardの観点からは、プライマリとスタンバイに同じGIバージョンを持つ必要はありません。Oracle Data Guardは、データベース内のどのバージョンからも完全に独立しているため、バージョンや時間に制限なく、異なるサイト間で異なるバージョンのオペレーティング・システム、Oracle Clusterware、ハードウェアまたはストレージ・ソフトウェアを実行できます。(Doc ID 1265700.1)
- Oracle Data Guardに関係なく、RAC DBのGIおよびRDBMSバージョンで同じバージョンを持つ必要はありません: 18c以降、Oracle Grid Infrastructure (GI) /Clusterware (CRS)のバージョンは、可能な組合せの最初の桁まで常に等しいか、最も高いバージョンである必要があります。たとえば、グリッド・インフラストラクチャは18.1.0.0、データベースは18.3.0.0です。(ドキュメントID 337737.1)
DBホームと同じレベルでGIにパッチを適用することをお薦めします。新しいリリース更新(RU)にDBホームにパッチを適用する必要がある場合、多くのパッチがDBおよびGIに共通であり、OPatchAutoを両方のホームに同時に使用できます。