設定環境
程序檔可以自動化某些步驟。這些指令碼不會自動執行完整的設定,因此您必須完成任務,並在參考指令碼時使用指令碼。
請前往下載代碼以取得連結,以下載此文件中所參考的指令碼。
準備主要資料中心中的 WebLogic 資料來源
TNS 別名在主要和次要名稱相同;因此,資料來源會使用相同的資料庫連線字串。它會以未複製到待命資料庫的 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
中使用相同的資料庫連線字串,因此在從主要資料庫複製config
到待命資料庫之後,您不需要更改 WebLogic 組態。 - 由於每個網站都只指向本機資料庫,因此從中間層到遠端資料庫都沒有交叉連線的風險。
如果您尚未在主要 WebLogic Server 系統中使用此方法,請執行下列步驟,在資料來源中使用 TNS 別名。
設定網路
設定 Oracle Data Guard
關於資料庫版本和修正程式層次
內部部署資料庫中的 Oracle 本位目錄和 OCI 上的待命資料庫必須是相同版本且在相同修正程式層級。您可以使用下列方式達成此目標:
- 在 OCI 的資料庫系統佈建期間選擇資料庫軟體映像檔時,請選取顯示所有版本,並選取與內部部署資料庫相同的資料庫版本和修正程式集層級。
- 如果來源資料庫的 Oracle 本位目錄版本已無法在 OCI 中進行佈建,則您必須將來源環境修正為與雲端環境中的資料庫本位目錄相同的資料庫修正程式層級。
下列案例是參考的實際範例。內部部署資料庫本位目錄為 19.6,OCI 資料庫本位目錄為 19.11。
- 執行
$ORACLE_HOME/OPatch/opatch lspatches
命令,識別「來源」和「目標」環境中安裝的修正程式。$ORACLE_HOME/OPatch/opatch lspatches
以下是此範例的輸出結果:
資料庫 Oracle 本位目錄修正程式 - 內部部署 OCI 上的資料庫 Oracle HOME 修正程式 30676209;LNX64-20.1-RAC ASM HIT ORA-07445 發生異常狀況核心傾印 [KSXPOSDIFQRY()+556]
30613937;IPCOR TOPO SERVICE FIX IP TYPE BUG IN IP SELECTION
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;分區 STS_CHUNKS 在 GSMADMIN_INTERNAL.SHARD_TS 上報告的停用限制條件
32327201;RDBMS - DSTV36 更新 - TZDATA2020E
31335037;RDBMS - DSTV35 更新 - TZDATA2020A
30432118;對錯誤 28852325 29997937 對 19.0.0.0.0 的頂端合併要求
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 中修正的一次性修補程式 (否則會導致衝突)。在此範例中,on-off 修補程式是在 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 資料庫本位目錄在 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、硬體或儲存軟體,而且不會限制版本或時間。(文件 ID 1265700.1)
- 無論 Oracle Data Guard 為何,RAC 資料庫的 GI 和 RDBMS 版本都不需要相同:從 18c 開始,Oracle Grid Infrastructure (GI) /Clusterware (CRS) 版本在任何時候都必須等於或最高版本,直到可能的組合中的第一個數字為止。例如:Grid Infrastructure 可以位於 18.1.0.0,而 Database 可以位於 18.3.0.0。(文件 ID 33773737.1)
建議您在資料庫本位目錄的相同層次修正 GI。當您必須將資料庫本位目錄修正為較新的版本更新 (RU) 之後,資料庫與 GI 便可使用許多修正程式,並且同時可將 OPatchAuto
套用至本位目錄。