網站容錯移轉和復原
如果您的基礎架構發生非計畫性事件，導致主要站台無法使用，且在一段時間內完全無法存取，這將對業務造成負面影響，則需要站台容錯移轉。在此情況下，待命資料庫會擔任主要角色。
主要網站因各種原因而無法使用，包括但不限於：
- 可能導致主要資料庫執行處理無法啟動的問題，例如失敗或極度損毀的媒體，或有瑕疵的作業系統或韌體升級
- 基礎架構故障，例如 OCI 區域基礎架構內的全電源或冷卻系統中斷
- 完整的網路失敗
- 自然災害，例如地震、火災和洪水
雖然未計劃的事件很少，但它們可以並執行。
執行網站容錯移轉
真正的容錯移轉具有破壞性，並可能導致一小部分資料遺失，請在 TEST 環境中測試您的網站容錯移轉。
下列範例針對 Ashburn (
CDBHCM_iad1dx) 中的主要資料庫和 Phoenix 中的待命資料庫 (CDBHCM_phx5s) 使用測試環境中的名稱。
- 強制停止主要資料庫上的所有資料庫 Oracle Real Application Clusters (Oracle RAC) 執行處理。
附註：
請勿在生產環境中執行此測試。$ srvctl stop database -db CDBHCM_iad1dx -stopoption abort從此開始，我們的主要項目被假設 (模擬) 完全無法使用。我們將使我們的次要區域成為新的主要地點。下列步驟使用我們的測試實作，所有步驟都是在次要站台 (新主要) 執行。
- At the secondary site, log in to any one of the Oracle Exadata Database Service on Dedicated Infrastructure domUs, become the
oracleOS user, and invoke the Data Guard Broker command-line interface.- 節點：一個 Oracle Exadata Database Service on Dedicated Infrastructure domU
- 使用者：
oracle
$ dgmgrl sys/sys password DGMGRL> show configuration lag Configuration - fsc Protection Mode: MaxPerformance Members: CDBHCM_iad1dx - Primary database Error: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor CDBHCM_phx5s - Physical standby database Transport Lag: 0 seconds (computed 18 seconds ago) Apply Lag: 0 seconds (computed 18 seconds ago) Fast-Start Failover: Disabled Configuration Status: ERROR (status updated 0 seconds ago)請注意錯誤。 - 使用 Oracle Data Guard Broker 命令行介面執行容錯移轉。
- 節點：次要站台上的 Oracle Exadata Database Service on Dedicated Infrastructure domU
- 使用者：
oracle
DGMGRL> failover to CDBHCM_phx5s - 如果主要中間層 (包括共用檔案系統) 仍然不完整，請手動執行從失敗的主要站台到 DR 站台的「強制」
rsync。應用程式與 Web 層仍然可能正常運作，但應用程式與處理作業排程器處理作業會開始嘗試連線至失敗的資料庫失敗。這會導致
rsync命令檔停止執行rsync。- 節點：一個中間層，失敗的主要位置
- 使用者：
psadm2
- 執行強制
rsync。命令檔目錄中提供範例rsync_psft.sh命令檔。如果停用rsync命令檔，則-f參數將會提示您繼續執行強制rsync。強制的rsync不會查詢資料庫來判斷網站的角色，然後會執行要求的rsync。附註：
只有在網站容錯移轉期間強制進行最終重新整理時，才會執行此動作。系統會記錄使用FORCE選項。$ rsync_psft.sh path to file system/parameter file -f例如，$ rsync_psft.sh $SCRIPT_DIR/fs1 -f - 監督
rsync處理作業日誌，確認處理作業順利完成。
- 如果網站失敗且無法執行最終的
rsync處理作業，請執行disable_psft_rsync.sh命令檔，在新的主要處理作業停用rsync。- 節點：一個中間層，新的主要位置
- 使用者：
psadm2
disable_psft_rsync.sh - 如果您在設定主要和待命資料庫伺服器時設定了 Active Data Guard 支援，請確定 PeopleSoft (
PSQUERY) 的 Active Data Guard 服務已在新的主要資料庫上啟動。- 節點：次要站台上的 Oracle Exadata Database Service on Dedicated Infrastructure domU
- 使用者：
oracle
$ srvctl status service -db CDBHCM_phx5s -s PSQUERY Service PSQUERY is running on instance(s) CDBHCM1,CDBHCM2此服務應該在所有 Oracle Real Application Clusters (Oracle RAC) 執行處理上執行。附註：
啟動程序排程程式之前，必須先啟動此服務。否則，處理程序排程程式將會在啟動時失敗。 - 確認以角色為基礎的資料庫服務在新主要資料庫上啟動。
- 網站：網站 2
- 節點：所有 Oracle Exadata Database Service on Dedicated Infrastructure domUs
- 使用者：
oracle
例如，在每個代管 PeopleSoft Oracle RAC 資料庫執行處理的 domU 上發出下列命令：$ srvctl status service -db CDBHCM_phx5s -s HR92U033_BATCH Service HR92U033_BATCH is running on instance(s) CDBHCM1,CDBHCM2 $ srvctl status service -db CDBHCM_phx5s -s HR92U033_ONLINE Service HR92U033_ONLINE is running on instance(s) CDBHCM1,CDBHCM2此服務應該在所有 Oracle RAC 執行處理上執行。 - 啟動應用程式伺服器和處理作業排程器網域。
- 網站：網站 2
- 節點：應用程式和處理作業排程器伺服器運算執行處理
- 使用者：
psadm2
- 登入代管 PeopleSoft 應用程式伺服器和處理作業排程器的運算執行處理，並成為
psadm2。使用 GitHub 中 Wrapper 目錄的startPSFTAPP.sh命令檔。$ startPSFTAPP.sh - 監視啟動。 您可以使用來自 PeopleSoft 應用程式和處理程序排程程式網域的查詢。
col service_name format a20 select a.inst_id,a.instance_name,b.service_name, count(*) from gv$instance a, gv$session b where a.inst_id = b.inst_id and service_name not like 'SYS%' group by a.inst_id,a.instance_name,b.service_name order by 1 SQL> / INST_ID INSTANCE_NAME SERVICE_NAME COUNT(*) ---------- ---------------- ------------------- ---------- 1 CDBHCM1 CDBHCM_phx5s 2 SQL> / INST_ID INSTANCE_NAME SERVICE_NAME COUNT(*) ---------- ---------------- ------------------- ---------- 1 CDBHCM1 CDBHCM_phx5s 2 1 CDBHCM1 HR92U033_BATCH 8 1 CDBHCM1 HR92U033_ONLINE 52 2 CDBHCM2 HR92U033_BATCH 7 2 CDBHCM2 HR92U033_ONLINE 50
- 如果您沒有步驟 5 所述的完整網站失敗，請前往下一個步驟。如果您有完整的網站失敗，則必須再次執行
disable_psft_rsync.sh命令檔，因為startPSTAPP.sh命令檔會啟用rsync。附註：
在主要站台遺失或無法存取的實際故障事件中，您需要對範圍和影響進行評估。以下是一些需要考慮的項目：
- 可能的資料庫資料遺失
- 遺漏檔案系統使用者自建物件 (報表、日誌、內送和外送檔案等等)
視中斷情況而定，您不一定能夠復原在原始主要主要資料庫中確認的每個交易。如果可能的話，請要求使用者驗證他們最後處理的交易。
從寫入或傳輸原始主要使用者自建物件的輸出，可能會遺漏檔案系統使用者自建物件。使用資料庫中的報表記錄來識別在停機時間附近建立的檔案系統人工因素，然後針對遺失或不完整的檔案，決定需要執行哪些動作、個案。
- 啟動 Web 服務。
- 網站：網站 2
- 節點：所有 PeopleSoft 網際網路架構 (PIA) Web 伺服器運算執行處理
- 使用者：
psadm2
如果設定 Coherence*Web，您將先在代管 PIA Web 伺服器的所有運算執行處理上啟動快取叢集，然後啟動 PIA Web 伺服器。在此範例中，會使用一個命令檔以適當的順序啟動兩者。- 登入 PIA Web 伺服器並成為
psadm2。 - 使用來自
startPSFTAPP.sh的命令檔，啟動 Web 伺服器。$ startPSFTWEB.sh
- 檢查負載平衡器。
- 地點：地點 2 區域
- 節點： OCI 主控台
- 使用者： 租用戶管理員
- 登入 OCI 主控台，然後將區域變更為新的主要區域。
- 選取網路，然後從主功能表選取負載平衡器。
- 請選取適當的區間。
- 按一下後端集，然後按一下後端。每個後端都應該顯示確定。每部 PIA Web 伺服器啟動後可能需要幾分鐘的時間。
將失敗的主要資料庫恢復成為新的待命資料庫
您需要使用待命資料庫保護新的生產環境。理想狀況下，您可以藉由復原資料庫和檔案系統，將失敗的主要資料庫復原為新的待命資料庫。
將舊的主要資料庫復原為待命資料庫
Oracle Data Guard 會在主要網站發生失敗後，讓舊的主要資料庫無法再次開啟它。任何正常啟動資料庫的嘗試都會失敗，訊息會寫入其警示日誌，指出需要復原。如果在失敗之前在此資料庫上啟用「倒溯資料庫」，則您可以將舊的主要資料庫復原為新的待命資料庫。
執行下列作業以將舊的主要產品復原為目前生產的待命產品：
- 登入代管舊主要資料庫的其中一個 domUs，然後啟動資料庫：
$ srvctl start database -db CDBHCM_phx5s - 登入新主要區域的「資料保全中介」命令行介面，然後顯示組態。請注意下面以粗體顯示 ORA-16661 錯誤。
$ dgmgrl sys/sys password DGMGRL> show configuration configuration - fsc Protection Mode: MaxPerformance Members: CDBHCM_iad1dx - Primary database CDBHCM_phx5s - Physical standby database (disabled) ORA-16661: the standby database needs to be reinstated Fast-Start Failover: Disabled Configuration Status: SUCCESS (status updated 12 seconds ago) - 恢復待命資料庫。
DGMGRL> REINSTATE DATABASE CDBHCM_phx5s;附註：
復原失敗的資料庫並啟動有效的待命資料庫，可能需要一些時間才能完成。 - 使用「資料保全中介」命令行介面來檢查您環境的狀態。例如，
DGMGRL> show configuration lag Configuration - fsc Protection Mode: MaxPerformance Members: CDBHCM_iad1dx - Primary database CDBHCM_phx5s - Physical standby database Transport Lag: 0 seconds (computed 1 second ago) Apply Lag: 0 seconds (computed 1 second ago) Fast-Start Failover: Disabled Configuration Status: SUCCESS (status updated 35 seconds ago)恢復的資料庫現在作為待命資料庫，保護主要資料庫，並可用於切換和容錯移轉。
如果您在設定主要和待命資料庫伺服器時設定了作用中資料保全支援，則可以將 PeopleSoft (
PSQUERY) 的作用中資料保全服務從主要資料庫重新定位回待命資料庫。
將舊的主要中間層復原為待命
根據您的容錯移轉事件恢復舊的主要中間層。
- 如果在發生資料庫容錯移轉事件時，您的舊主要中間層伺服器仍維持可用狀態，則應在失敗時，完成最終強制
rsync從失敗的主要位置到待命位置，然後反轉rsync處理作業的方向，與切換時相同。應用程式與 Web 層仍然可能正常運作，但應用程式與處理作業排程器處理作業會開始嘗試連線至失敗的資料庫失敗。這會導致
rsync命令檔停止執行 rsync。- 如果主要中間層 (包括共用檔案系統) 仍然不完整，請手動執行從失敗的主要站台到 DR 站台的 "forced" rsync。 如果停用 rsync 程序檔，
-f參數將會提示您繼續執行強制的rsync。強制的 rsync 不會查詢資料庫以判斷網站的角色，然後執行要求的 rsync。附註：
只有在網站容錯移轉期間強制進行最終重新整理時，才會執行此動作。將記錄使用 FORCE 選項。您可以使用命令檔目錄rsync_psft.sh中的範例命令檔作為使用者psadm2：$ rsync_psft.sh path to file system/parameter file -f例如，$ rsync_psft.sh $SCRIPT_DIR/fs1 -f - 監督
rsync處理作業日誌，確認處理作業順利完成。
- 如果主要中間層 (包括共用檔案系統) 仍然不完整，請手動執行從失敗的主要站台到 DR 站台的 "forced" rsync。
- 如果即使是
rsync，仍無法完全存取舊的主要網站，請執行下列動作：- 針對要複製的所有檔案系統，在新的主要位置停用
disable_psft_rsync.sh的rsync程序檔。 - 如果您稍後可以繼續原始中間層上的活動，請重新啟用
rsync命令檔並讓它們趕上。
- 針對要複製的所有檔案系統，在新的主要位置停用
- 如果您需要重建中間層，請遵循先前所述的程序。