Acordos de Nível de Serviço (SLAs) de Disponibilidade para o Autonomous AI Database na Infraestrutura Dedicada do Exadata

Este tópico descreve os Acordos de Nível de Serviço (SLAs) e os Objetivos de Nível de Serviço (SLOs) do Oracle Autonomous AI Database on Dedicated Exadata Infrastructure.

O Oracle Autonomous AI Database é executado na infraestrutura do Oracle Exadata Cloud (Oracle Public Cloud, Multicloud e Oracle Exadata Cloud@Customer), aproveitando a Arquitetura de Disponibilidade Máxima (MAA) da Oracle. O Autonomous AI Database on Dedicated Exadata Infrastructure foi projetado para retornar um aplicativo on-line após uma interrupção não programada ou uma atividade de manutenção planejada em segundos de um único dígito.

O MAA (Maximum Availability Architecture) da Oracle é um conjunto de melhores práticas desenvolvidas por engenheiros da Oracle ao longo dos anos para o uso integrado de tecnologias de alta disponibilidade do Oracle, proteção a dados e descoberta de desastres. O principal objetivo do Oracle MAA é atender ao RTO (Recovery Time Objective) e ao RPO (Recovery Point Objective) de bancos de dados e aplicativos Oracle executados em nosso sistema e plataformas de banco de dados usando arquiteturas e soluções do Oracle Cloud MAA. O Autonomous AI Database on Dedicated Exadata Infrastructure foi validado e certificado pela MAA Platinum.

Consulte Arquitetura de Disponibilidade Máxima e Autonomous AI Database Cloud em Visão Geral e Melhores Práticas de Alta Disponibilidade do Oracle Database 19c ou Visão Geral e Melhores Práticas de Alta Disponibilidade do Oracle Database 26ai para obter mais detalhes sobre o Oracle MAA.

Tempo de funcionamento

A tabela a seguir descreve o SLA (Service Level Agreement) e o SLO (Service Level Objective) do Oracle Autonomous AI Database on Dedicated Exadata Infrastructure.

Serviço	Tipo	Tempo de Atividade (sem o Autonomous Data Guard)	Tempo de atividade (com o Autonomous Data Guard)
Autonomous AI Database on Dedicated Exadata Infrastructure (implementações de Nuvem Pública), OCI, @AWS e @Azure	SLA (Service Level Agreement, Acordo de Nível de Serviço)	99,95% Um máximo de 22 minutos de tempo de inatividade por mês.	99,995% Um máximo de 132 segundos de tempo de inatividade por mês.
Autonomous AI Database on Exadata Cloud@Customer	Objetivo do Nível de Serviço (SLO)	99,95% Um máximo de 22 minutos de tempo de inatividade por mês.	99,995% Um máximo de 132 segundos de tempo de inatividade por mês.
Autonomous AI Database para desenvolvedores (Implantações do Public Cloud e do Exadata Cloud@Customer)	Objetivo do Nível de Serviço (SLO)	99,5%	Não se aplica Não há suporte para o Autonomous AI Database for Developers com o Autonomous Data Guard.

Observação: Para o Contrato de Nível de Serviço de Disponibilidade (SLA) sob as colunas de Tempo de Atividade na tabela acima, a Oracle envidará esforços comercialmente razoáveis para ter cada Serviço disponível com a Porcentagem de Tempo de Atividade Mensal indicada durante qualquer mês calendário (o "Compromisso de Serviço"). Se este Compromisso de Serviço não for atendido, você será elegível para receber Créditos de Serviço para tal Serviço Não Compatível, com uma Porcentagem de Crédito de Serviço. Consulte o Documento do Pilar do Oracle PaaS and IaaS Public Cloud Services para obter os valores da Porcentagem de Crédito de Serviço e outros detalhes.

RTO (Recovery Time Objective ) e RPO (Recovery Point Objective)

As tabelas a seguir descrevem os SLAs/SLOs RTO (Recovery Time Objective) e RPO (Recovery Point Objective) de destino para diferentes eventos de falha no Autonomous AI Database on Dedicated Exadata Infrastructure sem o Autonomous Data Guard e com o Autonomous Data Guard.

Eventos de Falha e Manutenção	SLO (Service-Level Downtime, Tempo de inatividade no nível do serviço)	Perda Máxima de Dados Viáveis
Eventos localizados, incluindo: Falhas na topologia da rede de clusters Exadata Falhas de armazenamento (disco e flash) Falhas na instância do banco de dados Falhas no servidor de banco de dados Atualizações periódicas de manutenção de software e hardware	Quase zero	Zero
Eventos que exigem restauração do backup porque o banco de dados stand-by não existe: Corrompimento de dados Falhas completas no banco de dados Falhas completas de armazenamento Domínio de disponibilidade (AD) para regiões com vários ADs	Minutos a horas (sem o Autonomous Data Guard)	15 minutos (sem o Autonomous Data Guard)
Eventos que exigem atualizações de software não incrementais ou upgrades de banco de dados	Até que a atualização de software não incremental ou o evento de upgrade do banco de dados seja concluído. Para os upgrades que incluem uma atualização de arquivo de fuso horário, o tempo de inatividade no nível do serviço depende da quantidade de dados de fuso horário que é modificada durante o upgrade.	Zero

Eventos de Falha e Manutenção	Tempo de Inatividade no nível do serviço (RTO)	Perda Potencial de Dados em Nível de Serviço (RPO)
Eventos localizados, incluindo: Falhas da malha de rede de clusters do Exadata Falhas de armazenamento (disco e flash) Falhas na instância do banco de dados Falhas no servidor de banco de dados Atualizações periódicas de manutenção de software e hardware	Zero ou Quase Zero	Zero
Eventos que exigem failover para o banco de dados stand-by usando o Autonomous Data Guard, incluindo: Corrupção de dados (como o Data Guard tem reparo de bloqueio automático para danos físicos, uma operação de failover só é necessária em caso de danos lógicos ou uma grande corrupção de dados) Falhas completas no banco de dados Falhas completas de armazenamento Falhas no domínio de disponibilidade ou na região (A proteção contra falhas regionais só estará disponível se o stand-by estiver localizado entre regiões.)	De alguns segundos a dois minutos	Zero com modo máximo de proteção contra disponibilidade (usa transporte síncrono de redo). Mais comumente usado para banco de dados stand-by intra-região. Quase zero para modo de proteção de desempenho máximo (usa transporte de redo assíncrono). Mais comumente usado para banco de dados stand-by de região cruzada.