Opções de recuperação de desastres para cargas de trabalho de bases de dados Oracle
Este guia descreve as opções de recuperação de desastres disponíveis para os utilizadores que executam cargas de trabalho de bases de dados Oracle de missão crítica num ambiente da Solução Bare Metal.
Este guia pressupõe que está a usar o Oracle Enterprise Edition. Algumas das funcionalidades descritas neste guia são licenciadas separadamente fora de uma licença da Enterprise Edition. Algumas destas funcionalidades incluem, entre outras:
- Oracle Real Application Clusters
- Oracle Active Data Guard
- Oracle Advanced Compression
- Oracle GoldenGate
Consulte os seus contratos de licença da Oracle para determinar que funcionalidades tem autorização para usar quando planear a recuperação de desastres e a alta disponibilidade.
OTR e PDR da aplicação
A recuperação de desastres para tecnologias de base de dados Oracle tem de ser determinada com base no objetivo de tempo de recuperação (RTO) e no objetivo de ponto de recuperação (RPO) de uma aplicação. Em geral, o RTO descreve a quantidade de tempo de inatividade aceitável para um sistema e o RPO descreve a quantidade de perda de dados aceitável. O custo e a complexidade de um sistema aumentam à medida que cada um destes valores diminui. Para mais informações sobre o RTO e o RPO, consulte o artigo Noções básicas do planeamento de recuperação de desastres.
As arquiteturas etiquetadas como "RPO = 0" ou "zero perda de dados" requerem que os dados sejam escritos em várias localizações antes de serem considerados "confirmados" na base de dados. A latência torna-se um problema à medida que o RPO se aproxima de zero.
A menos que sejam devidamente contabilizadas durante a fase de conceção, a implementação de uma arquitetura sem perda de dados pode ter efeitos adversos no desempenho geral da aplicação.
Alta disponibilidade versus recuperação de desastres
A alta disponibilidade e a recuperação de desastres são conceitos complementares quando cria arquiteturas de bases de dados fiáveis. No contexto deste guia, a alta disponibilidade refere-se à capacidade de um sistema recuperar automaticamente de falhas individuais ou em cascata no sistema. Por outro lado, a recuperação de desastres faz parte de um plano geral de continuidade da empresa e aplica-se a falhas maiores que podem tornar grupos inteiros de sistemas indisponíveis. A recuperação de desastres abrange um âmbito mais vasto devido ao número de componentes integrados que têm de ser recuperados em caso de desastre.
A alta disponibilidade tem de ser considerada a "primeira linha de defesa" ao criar um sistema fiável. Uma arquitetura de base de dados de elevada disponibilidade tem de conseguir suportar falhas individuais e continuar a ser executada sem causar tempo de inatividade para a aplicação. Os componentes de alta disponibilidade de um sistema têm de incluir, entre outros, o seguinte:
- Alimentação redundante no hardware do servidor, da rede ou de armazenamento
- Várias interfaces de rede, comutadores e cabos
- Tecidos de armazenamento, controladores e dispositivos de disco redundantes
- Interconexões de parceiros tolerantes a falhas entre o Google Cloud e a extensão da região da solução Bare Metal
- Oracle RAC para impedir que falhas do servidor desativem uma base de dados
Um design de recuperação de desastres tem de incluir processos para recuperar de várias falhas em cascata que tornam os componentes indisponíveis. O planeamento de recuperação de desastres tem de considerar o seguinte:
- Indisponibilidades regionais
- Desastres naturais
- Incidentes que resultam na indisponibilidade total de um ou mais componentes de uma aplicação
Ferramentas de recuperação de desastres e alta disponibilidade da Oracle
Seguem-se algumas ferramentas de recuperação de desastres e alta disponibilidade da Oracle:
- Oracle Real Application Clusters
- Oracle Recovery Manager
- Oracle Data Guard
- Base de dados de reversão
- Oracle GoldenGate
Oracle Real Application Clusters
O Oracle Real Application Clusters (RAC) é usado para dimensionar horizontalmente as cargas de trabalho da base de dados para serem processadas por vários servidores de bases de dados. As bases de dados que usam o RAC permitem uma configuração ativa/ativa entre servidores numa extensão de região.
Normalmente, o RAC é usado para oferecer elevada disponibilidade para sistemas que precisam de proteção contra uma única falha do servidor. Devido à abordagem de "tudo partilhado" (armazenamento partilhado e redes partilhadas) à criação de clusters, tem de existir um cluster RAC num ambiente de Solução Bare Metal num único pod da Solução Bare Metal. Isto torna o RAC uma solução para preocupações de elevada disponibilidade, mas não resolve o requisito de recuperação de desastres.
Para saber como configurar o RAC para a Solução Bare Metal, consulte o artigo Instale o Oracle RAC na Solução Bare Metal.
Oracle Recovery Manager
O Oracle Recovery Manager (RMAN) é a ferramenta principal para a cópia de segurança e a recuperação de bases de dados Oracle devido à sua capacidade de ler o formato de ficheiro de dados proprietário da Oracle. Pode ser usado para fazer clones de bases de dados, recuperação num determinado momento ou até mesmo recuperação de uma única tabela numa base de dados Oracle.
O RMAN é a única ferramenta que pode ser usada para fazer cópias de segurança enquanto a base de dados está aberta. Também é usado para manter o catálogo de ficheiros de cópia de segurança que estão disponíveis para utilização na recuperação.
Oracle Data Guard
O Oracle Data Guard realiza a replicação da base de dados para clusters RAC remotos ou outras instalações de bases de dados. O Data Guard suporta bases de dados em espera numa configuração física ou lógica.
As bases de dados de standby físicas são cópias bloco a bloco que permitem que uma cópia da base de dados esteja aberta para escrita. Todas as outras estão montadas (mas não abertas) para aplicar alterações ou abertas apenas para leitura para suportar aplicações de relatórios.
Para saber como configurar o Data Guard na Solução Bare Metal, consulte o artigo Implemente o Oracle Data Guard na Solução Bare Metal.
FLASHBACK DATABASE
A funcionalidade FLASHBACK DATABASE da Oracle Enterprise Edition permite que os administradores
revertam rapidamente uma base de dados para um ponto específico no tempo sem terem de
fazer restauros de bases de dados demorados.
No contexto da recuperação de desastres, o FLASHBACK DATABASE é usado frequentemente em conjunto com o Data Guard durante as operações de comutação por falha para um restabelecimento mais rápido da base de dados. A base de dados com falhas é revertida para um ponto específico no tempo
que é consistente com os registos no novo servidor principal, e a repetição é enviada para que
possa ser totalmente ressincronizada.
Oracle GoldenGate
O Oracle GoldenGate é uma ferramenta de replicação lógica que é usada frequentemente para
ativar implementações ativas/ativas em vários sites ou mover dados entre plataformas de hardware. Quando usa o GoldenGate, um processo extract na base de dados de origem captura as alterações nos registos de refazer online e escreve-as em ficheiros de registo de alterações, que são transportados para a base de dados de destino. Um processo replicat na base de dados de destino converte as transações dos ficheiros finais em SQL e executa o SQL na base de dados de destino.
Esta arquitetura torna o GoldenGate uma ferramenta poderosa para mover dados entre plataformas de bases de dados ou transformar dados à medida que são replicados. Ao contrário do Data Guard, o GoldenGate requer a instalação e a manutenção de software separado nos sistemas de origem e de destino. Não é possível usar o GoldenGate para replicação síncrona devido ao facto de as transações serem traduzidas e aplicadas como SQL na base de dados de destino. Embora o GoldenGate possa fornecer um atraso mínimo para a replicação, o GoldenGate sozinho não pode garantir um RPO de zero.
Modelos de implementação de recuperação de desastres (apenas base de dados)
A Oracle criou a arquitetura de disponibilidade máxima (MAA) para lhe fornecer modelos de recuperação de desastres recomendados para implementar as suas aplicações e bases de dados.
Cada um dos seguintes modelos fornece objetivos de RTO e RPO específicos:
Os modelos são mapeados para padrões de implementação específicos que cumprem o RPO e o RTO em eventos de indisponibilidades planeadas e não planeadas. Cada carga de trabalho da base de dados tem de ser avaliada quanto aos respetivos requisitos de disponibilidade e concebida com um modelo correspondente. É comum as bases de dados de desenvolvimento usarem um modelo com um nível de proteção inferior ao dos seus equivalentes de produção e controlo de qualidade.
O modelo Bronze destina-se a bases de dados que não precisam de um RTO medido em minutos. Os modelos de nível Prata e superior incluem bases de dados em espera executadas num site remoto. Cada modelo incorpora a funcionalidade dos modelos de nível inferior. Por exemplo, o modelo Bronze usa conceitos de cópia de segurança e recuperação que têm de ser seguidos mesmo que seja implementada uma base de dados em espera.
Modelo de cobre
O modelo de cobre oferece uma implementação mínima para fazer cópias de segurança de bases de dados para armazenamento local de multimédia e copiar para armazenamento que reside fora da extensão da região. Esta implementação requer uma abordagem de duas fases, mas pode ser programada para usar o Google Cloud SDK para automatizar a transmissão de cópias de segurança.
A utilização desta implementação também aumenta o RTO devido à recuperação em duas fases necessária. O RMAN não pode aceder diretamente às cópias de segurança, pelo que têm de ser movidas para uma localização disponível para o RMAN antes de a recuperação poder começar.
| Indisponível | Tipo de indisponibilidade | RPO | RTO |
|---|---|---|---|
| Não planeado | Falha recuperável do nó ou da instância | 0 | Tempo necessário para reiniciar a instância |
| Desastres: corrupções | Última cópia de segurança de registo de arquivo, incremental ou completa que foi transferida para fora do RE | Horas, consoante o tamanho da base de dados e a largura de banda atribuída à Interligação de parceiros | |
| Desastres: falhas de extensão de regiões | Última cópia de segurança de registo de arquivo, incremental ou completa que foi transferida para fora do RE | Dias / semanas, consoante o tempo necessário para voltar a colocar a extensão de região online | |
| Planeado | Patches de bases de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância |
| Atualização importante da base de dados | 0 | 1 a 2 horas |
Modelo Bronze
O modelo Bronze oferece duas opções de implementação. Ambos usam o armazenamento nativo doGoogle Cloudpara reter cópias de segurança de bases de dados.
Implementação Bronze 1: cópia de segurança no armazenamento regional
Nesta implementação, as cópias de segurança são escritas diretamente em suportes externos. Na maioria dos casos, o destino de cópia de segurança preferencial é o Cloud Storage com o Cloud Storage FUSE, que apresenta um contentor do Cloud Storage como um sistema de ficheiros.
Pode encontrar as recomendações para usar o Cloud Storage FUSE em Cópias de segurança da Oracle com NFS e Cloud Storage. Google Cloud Também pode usar o Filestore, que apresenta partilhas NFS às instâncias da solução Bare Metal.
O diagrama seguinte mostra uma implementação de exemplo.
| Indisponível | Tipo de indisponibilidade | RPO | RTO |
|---|---|---|---|
| Não planeado | Falha recuperável do nó ou da instância | 0 | Tempo necessário para reiniciar a instância |
| Desastres: corrupções | Última cópia de segurança de registo de arquivo, incremental ou completa | Horas, consoante o tamanho da base de dados e a largura de banda atribuída à Interligação de parceiros | |
| Desastres: falhas de extensão de regiões | Última cópia de segurança de registo de arquivo, incremental ou completa | Dias / semanas, consoante o tempo necessário para voltar a colocar a extensão de região online | |
| Planeado | Patches de bases de dados, atualizações do SO/FW | 0 | Tempo necessário para atualizar e reiniciar a instância |
| Atualização importante da base de dados | 0 | 1 a 2 horas |
Implementação Bronze 2: cópia de segurança com o serviço de cópias de segurança e RD
Nesta implementação, o serviço de cópias de segurança e RD é usado para armazenar cópias de segurança noGoogle Cloud. A solução de cópia de segurança e recuperação de desastres oferece uma abordagem de cópias de segurança incrementais para sempre, que são armazenadas em suportes de dados de elevado desempenho com tecnologia do Cloud Storage para retenção a longo prazo.
A cópia de segurança e a recuperação de desastres também oferecem um RTO mais rápido do que o armazenamento de cópias de segurança no Filestore ou no Cloud Storage, uma vez que podem disponibilizar imediatamente imagens de ficheiros de base de dados à instância do Oracle. A funcionalidade de montagem e migração coloca uma base de dados online rapidamente enquanto copia para o suporte de dados de produção, reduzindo drasticamente o RTO.
O diagrama seguinte mostra uma implementação de exemplo.
| Indisponível | Tipo de indisponibilidade | RPO | RTO |
|---|---|---|---|
| Não planeado | Falha recuperável do nó ou da instância | 0 | Tempo necessário para reiniciar a instância
Segundos, se usar o RAC |
| Desastres: corrupções | Última cópia de segurança de registo de arquivo, incremental ou completa | Minutos a horas, consoante os requisitos de desempenho, o tamanho da base de dados e a largura de banda atribuída ao Partner Interconnect | |
| Desastres: falhas de extensão de regiões | Última cópia de segurança de registo de arquivo, incremental ou completa | Dias / semanas, consoante o tempo necessário para repor a extensão de região online ou a capacidade do cliente de mudar para outra extensão de região. | |
| Planeado | Patches de bases de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância |
| Atualização importante da base de dados | 0 | 1 a 2 horas |
Silver
O modelo Silver introduz a replicação de bases de dados através do Oracle Data Guard. O Data Guard oferece replicação da base de dados em tempo real com uma ou mais bases de dados que atuam como uma base de dados de reserva. Uma vez que o Data Guard se baseia no transporte e na aplicação de alterações à base de dados à medida que ocorrem, o RPO pode ser quase zero. O modelo Silver baseia-se na replicação assíncrona. A utilização da replicação síncrona garante a ausência de perda de dados, mas o tempo necessário para enviar dados entre regiões normalmente aumenta o tempo de resposta da aplicação para além dos limites aceitáveis.
A funcionalidade de comutação por falha de início rápido do Data Guard tem a capacidade de realizar operações de comutação por falha automáticas se uma base de dados principal ficar indisponível durante um período definido pelo utilizador. A configuração é monitorizada por um processo de observação do Data Guard, que pode ser executado.
O modelo Silver tem a vantagem de garantir que a base de dados está disponível no caso de uma falha regional total, mas as operações de comutação por falha e comutação podem afetar o desempenho da aplicação à medida que a latência da rede entre os servidores de aplicações e a base de dados aumenta. Raramente é recomendado executar aplicações e bases de dados de apoio em regiões diferentes. Embora o RTO da base de dados possa ser inferior a 1 minuto, os casos de comutação por falha da aplicação podem demorar minutos a horas antes de os serviços estarem totalmente funcionais. Na maioria dos casos, a execução de planos de comutação por falha de recuperação de desastres entre regiões envolve normalmente processos manuais devido ao número de componentes que estão a ser movidos.
No modelo Silver, ainda pode ter períodos de inatividade ou janelas de manutenção durante as atividades de aplicação de patches trimestrais. A introdução do Oracle RAC pode reduzir o tempo de inatividade para a aplicação de patches ou falhas do servidor.
O diagrama seguinte mostra uma configuração de exemplo.
A configuração de exemplo no diagrama mostra bases de dados RAC em execução nas regiões us-west2 e us-east4. A replicação é configurada através do Data Guard assíncrono. Todo o tráfego entre a Bare Metal Solution e Google Cloud
transita por uma Partner Interconnect, e o tráfego entre regiões viaja
através da rede principal da Google. Os servidores de aplicações são configurados em cada região, mas são normalmente encerrados na região de recuperação de desastres até ser declarado um evento de comutação por falha.
| Indisponível | Tipo de indisponibilidade | RPO | RTO |
|---|---|---|---|
| Não planeado | Falha recuperável do nó ou da instância | 0 | Tempo necessário para reiniciar a instância
Segundos, se usar o RAC |
| Desastres: corrupções | < 60s | Minutos a horas, consoante a comutação por falha da aplicação. | |
| Desastres: falhas de extensão de regiões | < 60s | Minutos a horas, consoante a comutação por falha da aplicação. | |
| Planeado | Patches de bases de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância.
Segundos, se usar o RAC |
| Atualização importante da base de dados | 0 | 1 a 2 horas
Minutos se usar o |
Modelo dourado
Se tiver preocupações com a perda de dados no modelo Silver, pode optar pelo modelo Gold, que usa uma instância de sincronização remota para fornecer replicação síncrona a uma instância em execução no Google CloudCompute Engine.
Uma instância de sincronização remota inclui um ficheiro de controlo da base de dados e um conjunto de registos de refazimento em espera que são executados geograficamente perto da base de dados principal. Esta instância está configurada para receber repetições de forma síncrona com baixa latência, o que permite que todas as alterações sejam registadas fora da extensão da região da base de dados principal. A instância de sincronização remota encaminha a repetição para a base de dados em espera na região remota para aplicação assíncrona.
Uma instância de sincronização remota não é uma cópia completa da base de dados e, por isso, não pode processar o tráfego de aplicações. A instância de sincronização remota é usada para fornecer uma localização tolerante a falhas para as alterações à base de dados serem escritas de forma síncrona, o que permite uma solução sem perda de dados. Quando realiza a replicação síncrona para a instância de sincronização remota, as transações não são confirmadas na base de dados principal até que as alterações sejam recebidas e confirmadas na instância de sincronização remota.
Normalmente, as instâncias do Compute Engine são selecionadas como candidatas para alojar uma instância de sincronização remota. A colocação da instância de sincronização remota numa zona do Compute Engine muito próxima da base de dados principal adiciona uma latência mínima (normalmente, inferior a 1,5 ms) e protege contra falhas na extensão da região.
O diagrama seguinte mostra uma implementação de exemplo.
A configuração de exemplo no diagrama mostra uma base de dados RAC principal em execução em
us-west2 com aplicações em execução no Compute Engine. Uma instância do Compute Engine em us-west2 está a executar uma instância de sincronização remota, recebendo repetição síncrona. A instância de sincronização remota está configurada para enviar a repetição de forma assíncrona para uma base de dados RAC
em execução na região us-east4. As instâncias da aplicação estão configuradas na região us-east4 no Compute Engine para processar o tráfego da aplicação em caso de desastre.
| Indisponível | Tipo de indisponibilidade | RPO | RTO |
|---|---|---|---|
| Não planeado | Falha recuperável do nó ou da instância | 0 | Tempo necessário para reiniciar a instância
Segundos, se usar o RAC |
| Desastres: corrupções | 0 | Minutos a horas, consoante a comutação por falha regional da aplicação. | |
| Desastres: falhas de extensão de regiões | 0 | Minutos a horas, consoante a comutação por falha regional da aplicação. | |
| Planeado | Patches de bases de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância.
Segundos, se usar o RAC |
| Atualização importante da base de dados | 0 | 1 a 2 horas
Minutos se usar o |
Modelo Platinum
O modelo Platinum oferece duas opções de implementação. Cada opção de implementação oferece proteção através de uma tecnologia diferente e tem características de RTO e RPO diferentes.
Implementação Platinum 1: Data Guard com comutação por falha de início rápido
A implementação Platinum 1 baseia-se na implementação do modelo Gold, adicionando uma segunda base de dados de reserva do Data Guard na região local que é executada numa instância do Compute Engine. Esta configuração usa a replicação síncrona entre a base de dados principal e a base de dados em espera em execução no Compute Engine, o que garante a ausência de perda de dados na região principal.
A criação de uma base de dados em espera na região permite que as operações de comutação por falha e comutação da base de dados ocorram sem afetar as aplicações. Durante as alterações de funções da base de dados, as aplicações configuradas de acordo com as considerações do cliente da Oracle voltam a ligar-se automaticamente à nova base de dados principal sem necessidade de intervenção manual. As aplicações configuradas corretamente têm menos de 2 minutos de inatividade durante um evento de comutação por falha.
Embora a base de dados em espera no Compute Engine não execute o RAC, tem de ter o tamanho adequado para suportar o tráfego normal da aplicação quando estiver a ser executada como a base de dados principal. Esta instância pode ser executada com um formato mais pequeno enquanto funciona como um formato em espera e ser dimensionada durante eventos de comutação por falha ou ser executada com a capacidade total em todos os momentos. A alteração do tamanho da instância durante um evento de comutação por falha afeta negativamente o RTO, uma vez que a instância tem de ser reiniciada durante a operação de alteração do tamanho.
A comutação por falha de início rápido está configurada numa instância do Compute Engine que executa o agente do Data Guard com um observador. O observador executa um cliente Oracle básico com ligações a todas as bases de dados principais e de reserva. Se o observador detetar uma falha na base de dados principal, inicia uma comutação por falha para uma das bases de dados em espera. A base de dados em espera executada no Compute Engine tem de ser configurada como o destino de comutação por falha preferencial quando usar a implementação do nível Gold.
A Oracle recomenda que o observador seja colocado numa região separada das bases de dados primárias e de reserva. Isto oferece a melhor proteção contra falhas regionais e eventos de partição de rede. Se não for possível uma terceira região, o observador tem de ser instalado na região principal, sendo executado numa zona diferente da região de reserva em proximidade.
O diagrama seguinte mostra uma implementação de exemplo.
A implementação de exemplo apresentada no diagrama consiste no seguinte:
- Uma base de dados principal que executa o RAC no servidor da Solução Bare Metal na
us-west2região. - Uma base de dados de standby quase no local em execução numa instância do Compute Engine na região
us-west2. - Uma base de dados de reserva remota executada no servidor da Solução Bare Metal na região
us-east4. - O observador do Data Guard em execução na instância do Compute Engine na região
us-central1.
A replicação síncrona está configurada para a base de dados em espera na região em execução na instância do Compute Engine, e a replicação assíncrona está configurada para a região remota. Em cada caso, a repetição é enviada da base de dados principal para a base de dados de reserva. A repetição não é encaminhada de uma base de dados de reserva para a outra. O observador está configurado numa terceira região e mantém a conetividade com todas as bases de dados na configuração. As instâncias da aplicação são configuradas na região principal e ligam-se à base de dados principal no servidor da Bare Metal Solution (ou à base de dados na instância do Compute Engine durante as operações de comutação por falha e comutação). As instâncias de aplicações estão configuradas na região us-east4 no Compute Engine para processar o tráfego de aplicações em caso de desastre.
| Indisponível | Tipo de indisponibilidade | RPO | RTO |
|---|---|---|---|
| Não planeado | Falha recuperável do nó ou da instância | 0 | Tempo necessário para reiniciar a instância
Segundos, se usar o RAC |
| Desastres: corrupções | 0 | < 60s | |
| Desastres: falhas de extensão de regiões | 0 | < 60s | |
| Planeado | Patches de bases de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância.
Segundos, se usar o RAC |
| Atualização importante da base de dados | 0 | 1 a 2 horas
Minutos se usar o |
Implementação do nível Platina 2: GoldenGate para replicação
A implementação Platina 2 baseia-se na utilização do Oracle GoldenGate para replicação. Uma vez que o GoldenGate não faz a replicação ao nível do bloco. Permite que cada base de dados sirva sessões de leitura e escrita de aplicações de forma independente. Replica as alterações bidirecionalmente, o que permite uma configuração de base de dados ativa/ativa.
As aplicações têm de ser validadas minuciosamente antes de se comprometer com uma implementação ativa/ativa, e tem de ter em conta a deteção e a resolução de conflitos.
Ao contrário do Data Guard, o GoldenGate requer a instalação e a manutenção de software adicional nos servidores da base de dados Oracle. As implementações ativas/ativas requerem normalmente um esquema sofisticado e um design de aplicação para tirar partido de uma implementação de base de dados em vários sites. Muitas aplicações pré-criadas não suportam este tipo de arquitetura.
As implementações que dependem do GoldenGate para toda a replicação não podem suportar um RPO de zero perdas de dados devido à natureza assíncrona da replicação lógica. As bases de dados de espera locais executadas no Compute Engine com o Data Guard podem ser implementadas para fornecer um RPO de zero com replicação síncrona.
O diagrama seguinte mostra uma implementação de exemplo.
| Indisponível | Tipo de indisponibilidade | RPO | RTO |
|---|---|---|---|
| Não planeado | Falha recuperável do nó ou da instância | 0 | Tempo necessário para reiniciar a instância |
| Desastres: corrupções | Segundos para minutos
0 se usar o Data Guard em cada localização |
0 | |
| Desastres: falhas de extensão de regiões | Segundos para minutos
0 se usar o Data Guard em cada localização |
0 | |
| Planeado | Patches de bases de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância.
Segundos, se usar o RAC |
| Atualização importante da base de dados | 0 | 0 |