資料庫服務事件的修正

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

以下是可用的修正：

• HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE
• AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN
• AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION
• AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN
• AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN
• AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN
• HEALTH.DB_CLUSTER.CDB.CORRUPTION
• HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG
• HEALTH.DB_CLUSTER.CDB.DATABASE_HANG
• HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE
• HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

事件名稱

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

事件描述

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

• /
• /u01
• /u02
• /var
• /tmp

問題陳述

一或多個 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 事件。

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

事件名稱

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

事件描述

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

問題陳述

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

風險

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

動作 / 修復

CRS 節點收回可能是由 OCSSD (又稱為 CSS 協助程式)、CSSDAGENT 或 CSSDMONITOR 處理作業所造成。這需要判斷負責節點收回和複查相關日誌檔的處理作業。OCSSD 收回的一般原因包括網路失敗 / 延遲、CSS 仲裁磁碟發生 IO 問題、成員終止呈報。CSSDAGENT 或 CSSDMONITOR 撤回可能是 OS 排程器問題，或 CSS 協助程式中的停滯繫線。要複查的日誌檔包括叢集軟體警示日誌、cssdagent 日誌、cssdmonitor 日誌、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 監聽器因使用者動作而關閉時，事件的類型為 INFORMATION，例如使用「伺服器控制公用程式」(srvctl) 或「監聽器控制」(lsnrctl) 命令，或任何使用這些命令的 Oracle Cloud 維護動作 (例如執行 Grid Infrastructure 軟體更新)。當 SCAN 監聽器意外停止作用時，事件的類型為 CRITICAL。啟動 SCAN 監聽器時，會建立對應的 DOWN_CLEARED 事件。

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

問題陳述

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

風險

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

動作 / 修復

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

INFORMATION 類型的向下事件

1. 如果事件是由 Oracle Cloud 維護動作 (例如執行網格基礎架構軟體更新) 所造成，則不需要採取任何動作。受影響的 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 事件。當從屬端監聽器因使用者動作而關閉時，事件的類型為 INFORMATION，例如使用「伺服器控制公用程式」(srvctl) 或「監聽器控制」(lsnrctl) 命令，或任何使用這些命令的 Oracle Cloud 維護動作 (例如執行 Grid Infrastructure 軟體更新)。從屬端監聽器意外停止時，事件的類型為 CRITICAL。啟動從屬端監聽器時，會建立對應的 DOWN_CLEARED 事件。

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

問題陳述

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

風險

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

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

動作 / 修復

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

INFORMATION 型態的 DOWN 事件

1. 如果事件是由 Oracle Cloud 維護動作 (例如執行網格基礎架構軟體更新) 所造成，則不需要採取任何動作。當影響網格執行處理的維護完成後，受影響的從屬端監聽器將會自動重新啟動。
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 可收集日誌中指示之 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. 複查位於下列位置的監聽器日誌：

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

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

事件名稱

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

事件描述

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

HEALTH.DB_CLUSTER.CDB.CORRUPTION

事件名稱

HEALTH.DB_CLUSTER.CDB.CORRUPTION

事件描述

已在您的主要或待命資料庫上偵測到資料庫損毀。如果發生實體區塊損毀、邏輯區塊損毀或遺失寫入所造成的邏輯區塊損毀，則會剖析資料庫 alert.log。

問題陳述

損毀可能會導致應用程式或資料庫錯誤，更糟糕的情況下，如果未立即處理，會導致嚴重的資料遺失。

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

• 在實體區塊損毀 (亦稱為媒體損毀) 中，資料庫完全無法辨識區塊；總和檢查無效，或區塊包含所有零。較為複雜的區塊損毀範例是當區塊表頭與表尾不相符時。
• 在邏輯區塊損毀中，區塊的內容實際上是聲音的，並通過實體區塊檢查；不過，區塊在邏輯上可能不一致。邏輯區塊損毀的範例包括不正確的區塊類型、不正確的資料或重做區塊序號、資料列片段或索引項目損毀，或資料說明損毀。

區塊損毀也可以分成區塊中斷和區塊內損毀：

• 在區塊內部損毀中，損毀會發生在區塊本身，可以是實體或邏輯區塊損毀。
• 在區塊間損毀時，區塊之間會發生損毀，而且只能是邏輯區塊損毀。

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

• ORA-01578
• ORA-00752
• ORA-00753
• ORA-00600 [3020]
• ORA-00600 [kdsgrp1]
• ORA-00600 [kclchkblk_3]
• ORA-00600 [13013]
• ORA-00600 [5463]

風險

當硬體、軟體或網路元件導致讀取或寫入損毀的資料時，會發生資料損毀的中斷。資料損毀中斷的服務層次影響可能會有所不同，從應用程式或資料庫的小部分 (降至單一資料庫區塊) 到應用程式或資料庫的大部分 (基本上是無法使用的)。如果未立即採取修正動作，可能會發生停機時間和資料遺失的情形。

動作 / 修復

目前的事件通知目前在實體區塊損毀 (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 錯誤，下列注意事項將有助於：

• OERR：ORA-1578 「ORACLE 資料區塊損毀 (檔案編號 %s, 區塊編號 %s)」主要注意事項 (文件 ID 1578.1)
• 如何使用 RMAN 識別資料庫中所有損毀的物件 (文件 ID 472231.1)
• 如何識別 ORA-1578 / RMAN / DBVERIFY (文件 ID 819533.1) 報告的損毀物件
• 處理 Oracle Database 損毀問題的主要注意事項

附註：

RMAN 可以用來復原一或多個實體損毀的資料區塊。此外，如果要即時套用 Active Data Guard，實體資料損毀的自動區塊修復也會自動發生。

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

• 處理 Oracle Database 損毀問題的主要注意事項
• 如果主要或待命資料庫發生待命和遺失寫入損毀，請參閱解析待命復原期間的 ORA-00752 或 ORA-600 [3020] (文件 ID 1265884.1) 。

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

• 如需有關偵測到之錯誤的詳細資訊，請參閱處理 Oracle Database 損毀問題的主要注意事項。
• 如果主要資料庫有待命和邏輯損毀，請參閱解析實體待命資料庫中的邏輯區塊損毀錯誤 (文件 ID 2821699.1) 。

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

事件名稱

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

事件描述

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

問題陳述

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

風險

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

動作 / 修復

• 若要判斷每個繫線 / 執行處理的每小時頻率，請參閱尋找重做日誌切換歷史記錄的命令檔，以及尋找 RAC 中每個執行處理的存檔日誌大小 (文件 ID 2373477.1) 。
  • 如果任一小時的儲存桶大於 12，請考慮調整線上重做日誌的大小。請參閱下方的項目 2 以調整步驟大小。
• 如果資料庫暫時沒有回應，存檔器就可能無法跟上產生的重做日誌。
  • 請查看 alert.log，$ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log，瞭解「所有線上日誌都需要存檔」，短期內有多個事件可以指出 2 個可能的解決方案。
    1. 如果每個繫線的重做日誌群組數目少於 4 個，請考慮新增額外的日誌群組來達到 4 個，請參閱下方的 item1 以瞭解新增重做日誌步驟。
    2. 另一個可能的解決方案是調整重做日誌的大小，請參閱下方的項目 2 以調整步驟大小。
• 如需調整「資料保全」和非「資料保全」的準則大小，請參閱適當地設定線上重做日誌。
• 為每個執行緒新增一個重做日誌群組。額外的重做日誌應等於目前的日誌大小。
  1. 使用下列查詢：

     select max(group#) Ending_group_number, thread#, 
         count(*) number_of_groups_per_thread, 
         bytes redo_size_in_bytes from v$log group by thread#,bytes

  2. 使用與目前重做日誌相同的大小，為每個繫線新增一個新群組。

     alter database add logfile thread <thread_number> 
         group <max group + 1> ('<DATA_DISKGROUP>') size <redo_size_in_bytes>

• 新增較大的重做日誌並刪除目前較小的重做日誌，以調整線上重做日誌的大小。
  1. 使用下列查詢：

     select max(group#) Ending_group_number, thread#, 
         count(*) number_of_groups_per_thread, 
         bytes redo_size_in_bytes from v$log group by thread#,bytes

  2. 為目前存在的每個繫線 number_of_groups_per_thread 新增相同數目的重做日誌。new_redo_size_in_bytes 必須以適當地設定線上重做日誌為基礎。

     1. alter database add logfile thread <thread_number> 
            group <max group + 1> ('<DATA_DISKGROUP>') size <new_redo_size_in_bytes>

     2. 應刪除原始的較小重做日誌。重做日誌的狀態為非作用中時，才能將其刪除。若要判斷重做日誌的狀態，請選取下列項目。

        select group#, thread#, status, bytes from v$log order by bytes, group#, thread#;

        刪除原始的較小重做日誌：

        alter database drop logfile <group#>;

• 如果資料庫沒有回應，主要日誌存檔目的地和替代項目可能已滿。
  • 如需有關釋出 RECO 和 DATA 磁碟群組空間的詳細資訊，請參閱 HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE 。

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

事件名稱

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

事件描述

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

問題陳述

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

風險

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

動作 / 修復

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

• 複查下列對應事件日期 / 時間之訊息模式的資料庫 TFA 事件：ORA-32701、已封鎖 DIA0 重要資料庫處理作業或 DIA0 重要資料庫處理作業 (以根身分) 。

  tfactl events -database <dbName> -instance <instanceName>

• 複查下列位置的相關 alert.log：

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

• 對於 ORA-32701：超載系統可能會導致進度緩慢，這可以解譯為區塊。「阻斷器解析器」可能會嘗試透過終止最終阻斷器處理作業來解析區塊。
• 對於 DIA0 重要資料庫處理作業訊息：複查相關診斷行，指出處理作業和區塊的原因。

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

事件名稱

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

事件描述

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

問題陳述

CDB 的每日增量 BACKUP 失敗。

風險

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

動作 / 修復

複查與事件日期 / 時間對應的 RMAN 日誌。請注意，事件時戳 eventTime 為 UTC，請視需要針對 VM 的時區進行調整。

若為 Oracle 管理的備份：

• RMAN 輸出可在 /opt/oracle/dcs/log/<hostname>/rman 找到。
• 若有任何失敗，請複查日誌：
  • 如果失敗是因為 RMAN 以外的外部事件所造成，例如備份位置已滿或發生網路問題，請解決外部問題。
  • 如需其他 RMAN 命令檔錯誤，請收集診斷日誌並開啟「服務要求」。

    dbcli collect-diagnostics -h

    Usage: collect-diagnostics [options]
      Options:
        --components, -c
           Supported components: [all, dcs, crs, acfs, asm, db]
           all -- Collects diagnosis for all supported components [all, dcs, crs, acfs, asm, db]
           dcs -- Collects diagnosis for dcs
           crs -- Collects diagnosis for crs
           acfs -- Collects diagnosis for acfs
           asm -- Collects diagnosis for asm.
           db -- Collects diagnosis for db.
           For multiple parameter values, follow the example as "-c c1 c2"
           Default: [dcs]
        --dbNames, -d
           Comma separated database names. Valid only if 'db' or 'all' specified in Components list.
        --endTime, -et
           End time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format
        --help, -h
           get help
        --json, -j
           json output
        --objectstoreuri, -ou
           Pre Authenticated Request URI
        --redaction, -r
           Diagnostic logs redaction. Might take longer time with some components.
        --startTime, -st
        Start time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format

• 如果問題為暫時性或已解決，請進行新的增量備份。如需詳細資訊，請參閱使用主控台備份資料庫。

針對透過 RMAN 進行的客戶自有和管理的備份：

• 複查備份的 RMAN 日誌。

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

事件名稱

HEALTH.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)」外部備份的存檔重做日誌或資料庫備份。如需詳細資訊，請參閱維護快速復原區域。

---

標題與著作權資訊

Copyright ©2022,2025,

Oracle 和 (或) 其關係企業。