專用 Exadata 基礎架構上 Autonomous Database 的可用性服務層次協議 (SLA)

本主題描述 Oracle Autonomous Database on Dedicated Exadata Infrastructure 的服務層級協議 (SLA) 和服務層級目標 (SLO)。

Oracle Autonomous Database 運用 Oracle 的最高可用性架構 (MAA),在 Oracle Exadata Cloud infrastructure (Oracle Public Cloud多重雲端Oracle Exadata Cloud@Customer) 上執行。專用 Exadata 基礎架構上的 Autonomous Database 經過非計畫性停機或計畫性維護活動,可在單一位數秒內完成,設計為讓應用程式上線。

Oracle Maximum Availability Architecture (MAA) 是由 Oracle 工程師多年來開發的一組最佳實務,旨在整合使用 Oracle 高可用性、資料保護及災難復原技術。Oracle MAA 的主要目標是要符合使用 Oracle Cloud MAA 架構和解決方案在系統和資料庫平台上執行之 Oracle 資料庫和應用程式的復原時間目標 (RTO) 和復原點目標 (RPO)。Autonomous Database on Dedicated Exadata Infrastructure 已通過 MAA 白金級驗證並認證。請參閱 Oracle Database 19c High Availability Overview and Best Practices 中的 Maximum Availability Architecture and Autonomous Database CloudOracle Database 23ai High Availability Overview and Best Practices ,瞭解 Oracle MAA 的詳細資訊。

正常執行時間

下表簡要說明 Oracle Autonomous Database on Dedicated Exadata Infrastructure 的服務層級協議 (SLA) 和服務層級目標 (SLO)。

表格 - 正常運作時間 SLA/SLO

服務 Type 正常運作時間 (不含自治式資料保全) 正常運作時間 (使用自治式資料保全)

專用 Exadata 基礎架構上的 Autonomous Database (Oracle Public Cloud 部署)

服務層次協議 (SLA)

99.95%

每月停機時間最長為 22 分鐘。

99.995%

每月最多 132 秒的停止工作時間。

Autonomous Database on Exadata Cloud@Customer, Autonomous Database on Oracle Database@AWS 服務層級目標 (SLO)

99.95%

每月停機時間最長為 22 分鐘。

99.995%

每月最多 132 秒的停止工作時間。

開發人員自治式資料庫

(Oracle Public CloudExadata Cloud@Customer 部署兩者)

服務層級目標 (SLO)

99.5%

不適用

Autonomous Data Guard 不支援 Autonomous Database for Developers

附註:

就上表「正常運作時間」欄下的「可用性服務等級協定 (SLA)」而言,Oracle 將採取商業上合理的努力,讓每個此類服務在任何日曆月內都能享有指定的「每月正常運作時間百分比」(以下稱「服務承諾」)。如果不符合此服務承諾,您將有資格獲得此類不符合服務 (含服務積點百分比) 的服務積點。如需「服務積點百分比」值和其他詳細資料,請參考 Oracle PaaS 和 IaaS Public Cloud Services 重要文件

復原時間目標 (RTO) 與復原點目標 (RPO)

下表簡要說明沒有 Autonomous Data Guard 和 Autonomous Data Guard 的 Autonomous Database on Dedicated Exadata Infrastructure 之不同失敗事件的目標復原時間目標 (RTO) 和復原點目標 (RPO) SLA/SLO。

表格 - 預設高可用性原則復原時間和復原點 SLA/SLO

失敗和維護事件 服務層級停機時間 (SLO) 可行資料遺失上限
在地化事件,包含:
  • Exadata 叢集網路拓樸失敗
  • 儲存體 (磁碟和快閃) 失敗
  • 資料庫執行處理失敗數
  • 資料庫伺服器失敗
  • 定期軟體與硬體維護更新

接近零

因待命資料庫不存在而需要從備份回復的事件:
  • 資料損毀
  • 完整資料庫失敗數
  • 完整儲存失敗
  • 多 AD 區域的可用性網域 (AD)

分鐘至小時

(不含自治式資料保全)

15 分鐘

(不含自治式資料保全)

需要非輪流軟體更新或資料庫升級的事件

直到非輪流軟體更新或資料庫升級事件完成為止。

對於包含時區檔案更新的升級,服務層次的停止工作時間取決於升級期間修改的時區資料量。

表格 - 自治式資料保全復原時間與復原點 SLA/SLO

失敗和維護事件 服務層次停止工作時間 (RTO) 潛在服務層級資料遺失 (RPO)
在地化事件,包含:
  • Exadata 叢集網路結構失敗
  • 儲存體 (磁碟和快閃) 失敗
  • 資料庫執行處理失敗數
  • 資料庫伺服器失敗
  • 定期軟體與硬體維護更新

零或接近零

需要使用自治式資料保全容錯移轉至待命資料庫的事件,包括:
  • 資料損毀 (因為資料保全針對實體損毀自動進行區塊修復,所以只有在邏輯損毀或大量資料損毀時,才需要進行容錯移轉作業)
  • 完整資料庫失敗數
  • 完整儲存失敗
  • 可用性網域或區域失敗 (只有待命資料庫位於多個區域時,才能提供區域性失敗保護。)

幾秒鐘到兩分鐘

  • 零,最大可用性保護模式 (使用同步重做傳輸)。最常用於區域內待命資料庫。
  • 接近零以取得最大效能保護模式 (使用非同步重做傳輸)。最常用於跨區域待命資料庫。