資料庫服務事件修正

本文說明使用「資料庫服務事件」時發生問題所需的修正。

以下是可用的修正：

健康。DB_GUEST.FILESYSTEM.FREE_SPACE

事件名稱：

健康。DB_GUEST.FILESYSTEM.FREE_SPACE

事件描述：

下列檔案系統的 VM 來賓檔案系統可用空間低於 10% 可用空間 (由作業系統 df(1) 命令決定) 時，會報告此事件：

問題陳述：

一或多個 VM 來賓檔案系統的可用空間低於 10%。

風險：

VM 來賓檔案系統的可用空間不足可能會導致磁碟空間配置失敗，這可能會導致 Oracle 軟體 (資料庫、叢集軟體、雲端工具) 發生廣泛的錯誤和失敗。

動作 / 修復：

Oracle Cloud 和 DCS 代理程式會自動執行，以永久清除雲端工具建立的舊日誌檔和追蹤檔，以回收檔案系統空間。

如果自動檔案系統空間回收公用程式無法充分清除舊檔案來清除此事件，請執行下列動作：

  1. 移除手動建立或由客戶安裝的應用程式或公用程式建立的不需要檔案和 (或) 目錄。由客戶安裝的軟體所建立的檔案不在 Oracle 的自動檔案系統空間回收公用程式範圍內。下列作業系統命令 (以 root 使用者身分執行) 可用於識別耗用過多磁碟空間的目錄：

    sudo du -hx <file system mount point> | sort -hr

    只能安全地移除您確定的檔案或目錄。

  2. 使用雲端工具設定自動永久清除原則。如需詳細資訊，請參閱 Autologcleanpolicy Commands 。
  3. 開啟服務要求，以取得減少檔案系統空間使用的其他指引。

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

事件名稱：

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

事件描述：

當偵測到 Cluster Ready Service (CRS) 停止運作時，就會建立 CRITICAL 類型的事件。

問題陳述：

Cluster Ready Stack 為離線狀態或失敗。

風險：

如果節點上的 CRS 離線，則節點無法為應用程式提供資料庫服務。

動作 / 修復：

  1. 檢查您的管理員是否已停止 CRS，作為計畫性維護事件的一部分，或是擴大或縮小本機儲存

    1. 下列修正事件將會停止 CRS

      1. GRID 更新
      2. 更新來賓
      3. 主機更新

  2. 如果 CRS 未預期停止，您可以發出 crsctl check crs 命令來檢查目前的狀態。

    1. 如果節點沒有回應，則 VM 節點可能會重新開機。等待節點重新啟動完成，CRS 一般會透過 init 處理作業啟動。
  3. 如果 CRS 仍然停止運作，請參考 /u01/app/grid/diag/crs/<node_name>/crs/trace 中的 alert.log 來調查失敗的原因。複查與停機事件日期 / 時間對應的日誌項目，並對任何潛在的修正採取動作。
  4. 發出 crsctl start crs 命令來重新啟動 CRS。
  5. 成功重新啟動 CRS 將會產生清除事件：AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

清算事件：

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

清算事件描述：

CRS 成功啟動後，就會建立 INFORMATION 事件。

可用性。DB_GUEST.CRS_INSTANCE.EVICTION

事件名稱：

可用性。DB_GUEST.CRS_INSTANCE.EVICTION

事件描述：

Cluster Ready Service (CRS) 從叢集撤回節點時，會建立 CRITICAL 類型的事件。CRS-1632 錯誤會剖析 CRS alert.log，指出正在從叢集中移除節點。

問題陳述：

Oracle Clusterware 的設計是在偵測到嚴重問題時，移除叢集中的一或多個節點來執行節點收回。嚴重的問題可能是節點未透過網路活動訊號回應、節點未透過磁碟活動訊號回應、停滯或嚴重降級的機器，或是停滯的 ocssd.bin 處理作業。此節點收回的目的是藉由移除不正常的成員來維護叢集的整體狀況。

風險：

在重新啟動收回的節點期間，節點無法為應用程式提供資料庫服務。

動作 / 修復：

撤回 CRS 節點可能是由 OCSSD (也稱為 CSS 協助程式)、CSSDAGENT 或 CSSDMONITOR 處理作業所造成。這需要判斷哪一個處理作業負責收回節點，以及複查相關的日誌檔。OCSSD 撤回的常見原因包括網路故障 / 延遲、CSS 仲裁磁碟的 IO 問題、成員終止呈報。CSSDAGENT 或 CSSDMONITOR 收回可能是作業系統排程器問題，或是 CSS 協助程式中的停滯繫線。要複查的日誌檔包括叢集軟體警示日誌、ssdagent 日誌、sssdmonitor 日誌、ocssd 日誌、lastgasp 日誌、/var/log/messages、CHM/OS 監看程式資料，以及 opatch lsinventory 詳細資訊。

如需有關一起收集檔案的詳細資訊，請參閱 Autonomous Health Framework (AHF) Trace File Analyzer (TFA) & ORAchk/EXAchk 。如需有關疑難排解 CRS 節點收回的詳細資訊，請參閱叢集軟體節點收回 (重新啟動) 疑難排解。

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

事件名稱：

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

事件描述：

SCAN 監聽器停止運作時會建立 DOWN 事件。當 SCAN 監聽器因使用者動作而關閉時 (例如使用伺服器控制公用程式 (srvctl) 或監聽器控制 (lsnrctl) 命令)，或任何使用這些命令的 Oracle Cloud 維護動作 (例如執行 Grid Infrastructure 軟體更新)，事件的類型為 INFORMATION。當 SCAN 監聽器意外停止運作時，事件的類型為 CRITICAL。啟動 SCAN 監聽器時，會建立對應的 DOWN_CLEARED 事件。

每個叢集有三個 SCAN 監聽器，稱為 LISTENER_SCAN[1,2,3]。

問題陳述：

SCAN 監聽器已停止，無法接受應用程式連線。

風險：

如果所有的 SCAN 監聽器都已關閉，透過 SCAN 監聽器連線至資料庫的應用程式將會失敗。

動作 / 修復：

啟動 SCAN 監聽器以接收 DOWN_CLEARED 事件。

INFORMATION 類型的 DOWN 事件：

  1. 如果事件是由 Oracle Cloud 維護動作所造成 (例如執行 Grid Infrastructure 軟體更新)，則不需要採取任何動作。受影響的 SCAN 監聽器將會自動容錯移轉至可用的執行處理。
  2. 如果事件是由使用者動作所造成，則在下一個機會啟動 SCAN 監聽器。

CRITICAL 類型的 DOWN 事件：

  1. 檢查 SCAN 狀態並重新啟動 SCAN 監聽器

    • 以 opc 使用者身分登入 VM 及 sudo 給 grid 使用者：

      [opc@vm ~] sudo su - grid

    • 檢查任何節點上的 SCAN 監聽器狀態：

      [grid@vm ~] srvctl status scan_listener

    • 啟動 SCAN 監聽器：

      [grid@vm ~] srvctl start scan_listener

    • 重新檢查任何節點上的 SCAN 監聽器狀態：如果 scan_listener 仍然停止運作，請檢查掃描監聽器失敗的原因：

      1. 針對日誌中指示的 <hostName>，同時收集 CRS 和作業系統日誌 30 分鐘之前和 10 分鐘。請注意，事件有效負載中的時間一律以 UTC 表示：對於 tfactl 收集，請將時間調整為 VM 叢集的時區。

        [grid@vm ~] tfactl diagcollect -crs -os -node <hostName>
    -from "<eventTime adjusted for local vm timezone> - 30 minute "
    -to "<eventTime adjusted for local vm timezone> + 10 minutes"

      2. 記錄 SCAN 監聽器問題：

        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

事件名稱：

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

事件描述：

當從屬端監聽器停止運作時，會建立 DOWN 事件。當從屬端監聽器因使用者動作而關閉時 (例如使用「伺服器控制公用程式」(srvctl) 或「監聽器控制」(lsnrctl) 命令)，或任何使用這些命令的 Oracle Cloud 維護動作 (例如執行 Grid Infrastructure 軟體更新)，事件的類型為 INFORMATION。當從屬端監聽器意外停止運作時，事件的類型為 CRITICAL。啟動從屬端監聽器時，會建立對應的 DOWN_CLEARED 事件。

每個節點都有一個從屬端監聽器，每個節點稱為 LISTENER。

問題陳述：

從屬端監聽器已停止，無法接受應用程式連線。

風險：

如果節點的從屬端監聽器已關閉，節點上的資料庫執行處理就無法為應用程式提供服務。

如果所有節點上的從屬端監聽器都已關閉，則任何使用 SCAN 或 VIP 連線至任何資料庫的應用程式都會失敗。

動作 / 修復：

啟動從屬端監聽器，以接收 DOWN_CLEARED 事件。

INFORMATION 類型的 DOWN 事件：

  1. 如果事件是由 Oracle Cloud 維護動作所造成 (例如執行 Grid Infrastructure 軟體更新)，則不需要採取任何動作。影響網格執行處理的維護完成時，受影響的從屬端監聽器將會自動重新啟動。
  2. 如果事件是由使用者動作所造成，則在下一個機會啟動用戶端監聽器。

CRITICAL 類型的 DOWN 事件：

  1. 檢查從屬端監聽器狀態，然後重新啟動從屬端監聽器：

    • 以 opc 使用者身分登入 VM 及 sudo 給 grid 使用者：

      [opc@vm ~] sudo su - grid

    • 檢查任一節點上的從屬端監聽器狀態：

      [grid@vm ~] srvctl status listener

    • 啟動從屬端監聽器：

      [grid@vm ~] srvctl start listener

    • 重新檢查任何節點上的從屬端監聽器狀態：如果從屬端監聽器仍然停止作用。調查從屬端監聽器失敗的原因：

      1. 使用 tfactl 在 30 分鐘之前收集 CRS 和作業系統日誌，在日誌中指示的 hostName 同時收集 10 分鐘。請注意，事件有效負載中的時間一律以 UTC 表示：對於 tfactl 收集，請將時間調整為 VM 叢集的時區。

        [grid@vm ~] tfactl diagcollect -crs -os -node <hostName>
    -from "<eventTime adjusted for local vm timezone> - 30 minute "
    -to "<eventTime adjusted for local vm timezone> + 10 minutes"

      2. 複查位於下列位置的監聽器日誌：

        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

事件名稱：

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

事件描述：

當資料庫執行處理停止運作時，就會建立 DOWN 事件。當資料庫執行處理因使用者動作而關閉時 (例如使用 SQL*Plus (sqlplus) 或「伺服器控制公用程式 (srvctl)」命令)，或任何使用這些命令的 Oracle Cloud 維護動作 (例如執行資料庫本位目錄軟體更新)，事件的類型是 INFORMATION。當資料庫執行處理意外停止運作時，事件的類型為 CRITICAL。當資料庫執行處理啟動時，就會建立對應的 DOWN_CLEARED 事件。

問題陳述：

資料庫執行處理已經停止。

風險：

資料庫執行處理已停止運作，如果叢集中的其他節點上有可用的資料庫執行處理，可能會導致效能降低；如果所有節點上的資料庫執行處理都停止運作，則會導致完全停止工作。

動作 / 修復：

啟動資料庫執行處理以接收 DOWN_CLEARED 事件。

INFORMATION 類型的 DOWN 事件：

  1. 如果事件是由 Oracle Cloud 維護動作所造成 (例如執行資料庫本位目錄軟體更新)，則不需要任何動作。受影響的資料庫執行處理會在影響執行處理的維護完成後自動重新啟動。
  2. 如果事件是由使用者動作所造成，則在下一個機會啟動受影響的資料庫執行處理。

CRITICAL 類型的 DOWN 事件：

  1. 檢查資料庫狀態，然後重新啟動關閉的資料庫執行處理。

    1. 以 oracle 使用者身分登入 VM：

    2. 設定環境：

      [oracle@vm ~] . <dbName>.env

    3. 檢查資料庫狀態：

      [oracle@vm ~] srvctl status database -db <dbName>

    4. 啟動資料庫執行處理：

      [oracle@vm ~] srvctl start instance -db <dbName> -instance <instanceName>

  2. 調查資料庫執行處理失敗的原因。

    1. 複查資料庫的 Trace File Analyzer (TFA) 事件：

      [oracle@vm ~] tfactl events -database <dbName> -instance <instanceName>

    2. 請複查位於下列位置的資料庫警示日誌：

      $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log

狀況。DB_CLUSTER.CDB. 損毀

事件名稱：

狀況。DB_CLUSTER.CDB. 損毀

事件描述：

在您的主要或待命的資料庫偵測到資料庫損毀。資料庫 alert.log 會針對任何特定錯誤進行剖析，這些錯誤代表實體區塊損毀、邏輯區塊損毀或遺失寫入所造成的邏輯區塊損毀。

問題陳述：

毀損可能會導致應用程式或資料庫錯誤，更糟糕的情況會導致大量資料遺失 (若未立即解決)。

損毀的區塊是指變更過的區塊，因此與 Oracle Database 預期尋找的區塊不同。區塊損毀可以分類為實體或邏輯：

區塊損毀也可以劃分為區塊間損毀和區塊內損毀：

Oracle 會檢查 alert.log 中的下列錯誤：

風險：

硬體、軟體或網路元件導致讀取或寫入損毀的資料時發生資料損毀中斷。資料損毀停機的服務層級影響可能會有所不同，從應用程式或資料庫的小部分 (向下至單一資料庫區塊) 到應用程式或資料庫的大部分 (基本上是無法使用)。如果未立即採取補救措施，可能會導致停機和資料遺失增加。

動作 / 修復：

目前的事件通知目前觸發實體區塊損毀 (ORA-01578)、遺失寫入 (ORA-00752、ORA-00753 和 ORA-00600，第一個引數為 3020) 以及邏輯損毀 (通常從 ORA-00600 偵測到，第一個引數為 kdsgrp1、kdsgrp1、kclchkblk_3、13013 或 5463)。

建議您執行下列步驟：

  1. 確認 alert.log 追蹤檔中已報告這些損毀。使用最新的 EXAchk 報表記錄服務要求 (SR)、alert.log 的摘錄以及包含損毀錯誤的追蹤檔、最近應用程式的所有歷史記錄、資料庫或軟體變更，以及同期的任何系統、叢集軟體和資料庫日誌。對於所有這類情況，都應該提供 TFA 集合，並附加到服務要求中。
  2. 如需修復建議的詳細資訊，請參閱處理 Oracle Database 損毀問題的主要注意事項。

對於實體毀損或 ORA-1578 錯誤，下列注意事項將有助於：

注意： RMAN 可以用來復原一或多個實體損毀的資料區塊。此外，在即時套用 Active Data Guard 時，會自動修復實體資料損毀。

對於主要或待命資料庫上遺失寫入 (ORA-00752、ORA-00753 和 ORA-00600，第一個引數為 3020) 所造成的邏輯損毀，系統會在主要或待命的重做套用處理作業上偵測它們。下列備註將有助於：

對於邏輯損毀 (通常從 ORA-00600 偵測到，且引數為 kdsgrp1、kclchkblk_3、13013 或 5463)

健康。DB_CLUSTER.CDB.ARCHIVER_HANG

事件名稱：

健康。DB_CLUSTER.CDB.ARCHIVER_HANG

事件描述：

如果容器資料庫 (CDB) 無法存檔作用中的線上重做日誌，或無法將作用中的線上重做日誌快速存檔到日誌存檔目的地，就會建立 CRITICAL 類型的事件。

問題陳述：

因為日誌寫入器 (LGWR) 無法將日誌緩衝區寫入線上重做日誌，所以 CDB RAC 執行處理可能會暫時或永久停滯。這是因為所有線上記錄都需要歸檔。存檔器 (ARC) 至少可以存檔一個線上重做日誌之後，LGWR 將能夠繼續將日誌緩衝區寫入至線上重做日誌，而且會降低應用程式影響。

風險：

如果存檔器暫時沒有回應，應用程式在嘗試確認資料庫變更時可能會發生短暫的部分中斷或延遲。如果存檔器未回復，應用程式處理作業在處理時可能會發生延長的延遲。

動作 / 修復：

健康。DB_CLUSTER.CDB.DATABASE_HANG

事件名稱：

健康。DB_CLUSTER.CDB.DATABASE_HANG

事件描述：

當容器資料庫 (CDB) 中的處理作業或階段作業沒有回應時，便會建立 CRITICAL 類型的事件。

問題陳述：

「阻斷器解析器」偵測到無回應的處理作業或區塊，並產生 ORA-32701 錯誤訊息。此外，如果「診斷處理作業」(DIA0) 偵測到關鍵資料庫處理作業沒有回應，則可能會引發此事件。

風險：

無回應的處理作業或區塊可能表示資源、作業系統或應用程式編碼相關問題。

動作 / 修復：

調查階段作業區塊的原因。

狀況。DB_CLUSTER.CDB.BACKUP_ 失敗

事件名稱：

狀況。DB_CLUSTER.CDB.BACKUP_ 失敗

事件描述：

如果 v$rman_status 視觀表中報告 CDB 備份的狀態為 FAILED，就會建立 CRITICAL 類型的事件。

問題陳述：

CDB 的每日增量備份失敗。

風險：

備份失敗可能會危害使用備份來回復 / 復原資料庫的能力。可復原性點物件 (RPO) 與可復原性時間物件 (RTO) 可能會受到影響。

動作 / 修復：

複查對應至事件日期 / 時間的 RMAN 日誌。請注意，事件時戳 eventTime 的 UTC 格式，請視需要調整 VM 的時區。

對於 Oracle 管理的備份：

針對透過 RMAN 進行的客戶擁有與受管理備份：

健康。DB_CLUSTER.DISK_GROUP.FREE_SPACE

事件名稱：

健康。DB_CLUSTER.DISK_GROUP.FREE_SPACE

事件描述：

當 ASM 磁碟群組達到 90% 或更高的空間使用量時，就會建立 CRITICAL 類型的事件。當 ASM 磁碟群組空間使用量低於 90% 時，就會建立類型為 INFORMATION 的事件。

問題陳述：

ASM 磁碟群組空間使用狀況等於或超過 90%。

風險：

ASM 磁碟群組空間不足可能會導致資料庫建立失敗、表格空間和資料檔建立失敗、自動資料檔擴充失敗或 ASM 重新平衡失敗。

動作 / 修復：

ASM 磁碟群組使用的空間是由在連線至 ASM 執行處理時執行下列查詢所決定。

sudo su - grid
sqlplus / as sysasm
select 'ora.'||name||'.dg', total_mb, free_mb,
    round ((1-(free_mb/total_mb))*100,2) pct_used from v$asm_diskgroup;
NAME             TOTAL_MB    FREE_MB   PCT_USED
---------------- ---------- ---------- ----------
ora.DATAC1.dg     75497472    7408292      90.19
ora.RECOC1.dg     18874368   17720208       6.11

ASM 磁碟群組容量可以透過下列方式增加：

  1. 調整 VM 叢集儲存以新增更多 ASM 磁碟群組容量。如需詳細資訊，請參閱調整資料庫系統規模。

DATA 磁碟群組空間使用可以透過下列方式減少：

  1. 從資料庫刪除未使用的資料檔和暫存檔。如需詳細資訊，請參閱刪除資料檔。

您可以使用下列方式減少 RECO 磁碟群組空間使用：

  1. 刪除不必要的保證回復點。如需詳細資訊，請參閱使用一般和保證的回復點。
  2. 刪除已經在「瞬間復原區域 (FRA)」外部備份的存檔重做日誌或資料庫備份。如需詳細資訊，請參閱維護快速復原區域。