Migre Aplicativos Essenciais aos Negócios para o Oracle Database@Azure Usando uma Estratégia em Fases

Migre um banco de dados e aplicativo on-premises para a nuvem, minimizando o tempo de inatividade com estratégias em fases ou híbridas, garantindo conectividade perfeita para aplicativos baseados em nuvem para bancos de dados on-premises. Um plano bem estruturado acelera a saída do data center, mitiga riscos e mantém a confiabilidade. Uma abordagem híbrida de duas fases permite uma transição suave, mantendo a estabilidade.

Ao mover um banco de dados e aplicativo on-premises para a nuvem, você deve enfrentar vários desafios para garantir uma transição perfeita. Escolha uma estratégia de migração que minimize o tempo de inatividade, como migração em fases ou soluções de nuvem híbrida, para manter o tempo de atividade do aplicativo, especialmente para cargas de trabalho de negócios críticas. Certifique-se de que os aplicativos que já estão na nuvem, que se conectam a bancos de dados on-premises, também sejam considerados no plano de migração para evitar problemas de conectividade. Para aplicativos SaaS, em que o aplicativo reside na nuvem, mas o banco de dados está on-premises, garanta uma estratégia abrangente que inclua os dois componentes. Aborde esses desafios proativamente para garantir uma transição tranquila e manter a confiabilidade de seus aplicativos de negócios essenciais. Uma estratégia bem estruturada também ajuda a agilizar a saída do data center e reduzir os riscos de migração, garantindo a confiabilidade de seus aplicativos de negócios essenciais.

O Oracle Database@Azure elimina a dependência do Exadata on-premises ou do Oracle Real Application Clusters (Oracle RAC), aproximando o banco de dados das cargas de trabalho da aplicação no Microsoft Azure. Essa integração permite que o banco de dados e os aplicativos sejam hospedados no mesmo data center, reduzindo a latência e minimizando a dependência da infraestrutura física.

A implementação dessa configuração geralmente requer uma solução cuidadosamente projetada para estabelecer a arquitetura de destino sem interromper as operações comerciais críticas. Muitas cargas de trabalho de missão crítica são implantadas em várias regiões para garantir a continuidade dos negócios por meio de recuperação de desastres ou ambientes em espera. Essa abordagem suporta uma estratégia de migração híbrida de duas fases, permitindo transições contínuas, mantendo a estabilidade operacional.

Antes de Começar

Antes de começar, certifique-se de considerar o seguinte:

  • Desative o Failover Fast-Start no Oracle Data Guard para garantir uma transição suave e controlada entre as regiões principal e stand-by durante a migração.
  • O OCI Database Migration fornece migrações validadas, de versão cruzada, tolerantes a falhas e incrementais do Oracle Database e MySQL para casos de uso on-line e off-line, como ZDM e OCI Migration.
  • Essa arquitetura de referência segue o modelo Oracle Gold Maximum Availability Architecture (MAA) em uma configuração em espera ativa com implantação entre regiões para maior resiliência. Essa arquitetura de referência pode ser estendida para usar o MAA platinum, em que a alta disponibilidade local é obtida por meio de replicação síncrona usando o Oracle Data Guard entre zonas de disponibilidade, enquanto a recuperação de desastres entre regiões é implementada com replicação assíncrona.

Arquitetura

Essa arquitetura descreve uma abordagem em fases para migrar o Oracle Database on-premises para o Oracle Exadata Database Service no Oracle Database@Azure com tempo de inatividade mínimo.

Para simplificar essa estratégia, dividimos em três aspectos principais: estado atual, estado futuro e fases de migração.

Essa arquitetura de referência tem quatro componentes principais (marcados com números azuis no diagrama).
Número Componente Descrição
1 Data center principal local Hospeda o banco de dados e o aplicativo como o sistema principal antes da migração.
2 Data center stand-by on-premises Mantém um sistema stand-by, replicando o banco de dados principal local.
3 Região principal do Azure Executa o aplicativo e o banco de dados no Oracle Database@Azure, tornando-se o sistema principal pós-migração.
4 Região stand-by do Azure Um site de recuperação de desastres replicando a região principal usando o Oracle Data Guard.

Veja a seguir a descrição da arquitetura lógica diagram.png
Descrição da ilustração logical-architecture-diagram.png

diagrama de arquitetura lógica-oracle.zip

Estado atual

Na configuração existente, tanto o data center principal (1) quanto o data center stand-by (2) são hospedados on-premises, oferecendo suporte a cargas de trabalho e bancos de dados de aplicativos. O data center principal trata todas as solicitações, enquanto o data center stand-by mantém a replicação assíncrona usando o Oracle Data Guard. Isso garante alta disponibilidade, com o sistema stand-by pronto para failover em caso de falhas inesperadas.

Estado futuro

A arquitetura futura espelha a configuração atual, mas está totalmente hospedada na nuvem, abrangendo duas regiões do Azure: a região principal (3) e a região stand-by (4). O banco de dados é migrado para os serviços Exadata do Oracle Database@Azure, com replicação assíncrona entre os bancos de dados principal e stand-by gerenciados pelo Oracle Data Guard por meio da rede do OCI (Oracle Cloud Infrastructure).

Para conectividade segura entre o data center local e o Azure, um Firewall do Azure é implantado em um Hub Virtual WAN (vWAN) seguro no Azure.

Fases de migração

A migração segue uma abordagem de duas fases para garantir uma transição controlada e confiável.

Fase 1 – Transição do stand-by on-premises para o Azure e switchover

Nesta fase, o sistema stand-by local (2) é migrado para o Azure (3). Uma vez concluídas, as atribuições principal (1) e stand-by (3) são trocadas, tornando o Azure a nova região principal.

  1. Estabeleça a conectividade entre o local e o Azure usando o Azure ExpressRoute.
  2. Configure o hub seguro do Azure, o Firewall do Azure e o vWAN para segurança (se ainda não estiver em vigor).
  3. Provisione o Oracle Exadata Cloud Infrastructure na região principal do Azure e, em seguida:
    1. Configure um cluster de máquina virtual (VM) do Oracle Exadata e crie o banco de dados de destino.
    2. Ative logs de arquivamento e log forçado no banco de dados principal (se ainda não estiver ativado).
  4. Configure o Oracle Net para nomes de listener e TNS para descoberta.
  5. Restaure do serviço para configurar um banco de dados stand-by na região principal (3) do Azure.
  6. Execute um switchover, tornando o banco de dados do Azure (3) o novo principal.
  7. Migre aplicativos para a região principal do Azure (3) e atualize rotas de DNS.
  8. Verifique a configuração do Data Guard e monitore o status da replicação.

Fase 2 – Estabelecimento de stand-by no Azure e desativação on-premises

Nesta fase, um sistema stand-by (4) é configurado no Azure e os recursos locais (1 e 2) são desativados.

  1. Provisione o Oracle Exadata Cloud Infrastructure na região stand-by (4) com o Oracle Database@Azure.
  2. Configure um cluster de VMs do Oracle Exadata e crie o banco de dados stand-by.
  3. Ative o Oracle Data Guard para associar o banco de dados da região principal (3) ao banco de dados stand-by (4).
  4. Use a rede da OCI para replicação de alto throughput, aproveitando o pareamento local e remoto em uma topologia de hub e spoke entre os bancos de dados principal e stand-by.
  5. Migre cargas de trabalho de aplicativos para a região stand-by (4) do Azure.
  6. Interrompa a sincronização com os recursos locais e, em seguida, encerre a aplicação local e os recursos de banco de dados dos data centers principal (1) e stand-by (2).

O diagrama a seguir ilustra essa arquitetura de referência.


Veja a seguir a descrição da arquitetura física de diagram.png
Descrição da ilustração physical-architecture-diagram.png

diagrama de arquitetura física-oracle.zip

O Microsoft Azure fornece os seguintes componentes:

  • Região do Azure

    Uma região do Azure é uma área geográfica na qual um ou mais data centers físicos do Azure, chamados zonas de disponibilidade, residem. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).

    As regiões do Azure e da OCI são áreas geográficas localizadas. Para o Oracle Database@Azure, uma região do Azure é conectada a uma região da OCI, com zonas de disponibilidade (AZs) no Azure conectadas a domínios de disponibilidade (ADs) na OCI. Os pares de regiões do Azure e OCI são selecionados para minimizar a distância e a latência.

  • Zona de Disponibilidade do Azure

    As zonas de disponibilidade do Azure são locais fisicamente separados dentro de uma região do Azure, projetados para garantir alta disponibilidade e resiliência, fornecendo energia, refrigeração e rede independentes.

  • Azure VNet

    A Rede Virtual do Microsoft Azure (VNet) é o bloco de construção fundamental da sua rede privada no Azure. O VNet permite que muitos tipos de recursos do Azure, como máquinas virtuais (VM) do Azure, se comuniquem com segurança entre si, com a Internet e com as redes locais.

  • Sub-rede Delegada do Azure

    A delegação de sub-rede é a capacidade da Microsoft de injetar um serviço gerenciado, especificamente um serviço de plataforma como serviço (PaaS), diretamente na sua rede virtual. Isso permite designar ou delegar uma sub-rede para ser um home de um serviço gerenciado externo dentro da sua rede virtual, de forma que o serviço externo atue como um recurso de rede virtual, mesmo que seja um serviço PaaS externo.

  • VNIC do Azure

    Os serviços nos data centers do Azure têm placas físicas de interface de rede (NICs). As instâncias de máquina virtual se comunicam usando NICs virtuais (VNICs) associadas às NICs físicas. Cada instância tem uma VNIC principal que é criada e anexada automaticamente durante a inicialização e está disponível durante a vida útil da instância.

  • Gateway de Rede Virtual do Azure

    O Gateway de Rede Virtual do Azure estabelece conectividade segura entre locais entre uma rede virtual do Azure e uma rede local. Ele permite que você crie uma rede híbrida que abrange seu data center e o Azure.

  • WAN Virtual do Azure

    O Microsoft Azure Virtual WAN (VWAN) é um serviço de rede que reúne muitas funcionalidades de rede, segurança e roteamento para fornecer uma única interface operacional.

  • Hub Seguro do Azure

    Um hub seguro do Azure, também conhecido como hub virtual seguro, é um hub WAN Virtual do Azure aprimorado com políticas de segurança e roteamento gerenciadas pelo Gerenciador de Firewall do Azure. Ele simplifica a criação de arquiteturas de rede hub e spoke e transitivas, integrando serviços de segurança nativos para governança e proteção do tráfego. Essa configuração automatiza o roteamento de tráfego, eliminando a necessidade de rotas definidas pelo usuário (UDRs). As organizações podem usar um hub seguro para filtrar e proteger o tráfego entre redes virtuais, filiais e a internet, garantindo segurança robusta e gerenciamento de rede simplificado.

  • Gerenciador de Firewall do Azure

    O Azure Firewall Manager é um serviço de gerenciamento de segurança centralizado que simplifica a implantação e a configuração do Azure Firewall em várias regiões e assinaturas. Ele permite o gerenciamento de políticas hierárquicas, permitindo que políticas de firewall globais e locais sejam aplicadas de forma consistente. Quando integrado com o Azure Virtual WAN (vWAN) e um hub seguro, o Azure Firewall Manager aumenta a segurança automatizando o roteamento e a filtragem de tráfego sem a necessidade de rotas definidas pelo usuário (UDRs). Essa integração garante que o tráfego entre redes virtuais, filiais e internet seja gerenciado e monitorado com segurança, fornecendo uma solução de segurança de rede robusta e simplificada.

  • Azure ExpressRoute

    O Azure ExpressRoute é um serviço que permite conexões privadas entre data centers locais e o Microsoft Azure, ignorando a internet pública. Isso resulta em maior segurança, confiabilidade e velocidades mais rápidas com latências consistentes. As conexões ExpressRoute podem ser estabelecidas por meio de um provedor de conectividade usando vários métodos, como Ethernet ponto-a-ponto, qualquer-para-qualquer (VPN IP) ou conexões cruzadas virtuais. Ao integrar-se com data centers locais, o ExpressRoute permite a extensão perfeita da sua rede para a nuvem, facilitando cenários de nuvem híbrida, recuperação de desastres e migração de dados com desempenho e segurança aprimorados.

O Oracle Cloud Infrastructure fornece os seguintes componentes:

  • Região

    Uma região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, hospedando domínios de disponibilidade. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).

  • Domínio de disponibilidade

    Domínios de disponibilidade são data centers stand-alone e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, o que oferece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia ou refrigeração ou a rede interna do domínio de disponibilidade. Portanto, uma falha em um domínio de disponibilidade não deve afetar os outros domínios de disponibilidade na região.

  • Rede virtual na nuvem (VCN) e sub-rede

    Uma VCN é uma rede personalizável definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs oferecem controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após a criação da VCN. Você pode segmentar uma VCN em sub-redes, com escopo definido para uma região ou para um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobrepõem a outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.

  • Tabela de roteamento

    As tabelas de roteamento virtual contêm regras para rotear o tráfego de sub-redes para destinos fora de uma VCN, geralmente por meio de gateways.

  • Lista de segurança

    Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego permitido dentro e fora da sub-rede.

  • Grupo de segurança de rede (NSG)

    Os NSGs atuam como firewalls virtuais para os seus recursos de nuvem. Com o modelo de segurança de confiança zero do Oracle Cloud Infrastructure, você controla o tráfego de rede dentro de uma VCN. Um NSG consiste em um conjunto de regras de segurança de entrada e saída que se aplicam a apenas um conjunto especificado de VNICs em uma única VCN.

  • Oracle Database Autonomous Recovery Service

    O Oracle Database Autonomous Recovery Service é um serviço do Oracle Cloud que protege bancos de dados Oracle. A automação de backup e os recursos aprimorados de proteção de dados para bancos de dados da OCI permitem que você descarregue todos os requisitos de processamento e armazenamento de backup para o Oracle Database Autonomous Recovery Service, o que reduz os custos de infraestrutura de backup e a sobrecarga de administração manual.

  • do Exadata Database Service

    permite aproveitar o potencial do Exadata na nuvem. O Oracle Exadata Database Service oferece recursos comprovados do Oracle Database em uma infraestrutura otimizada e específica do Oracle Exadata na nuvem pública. A automação da nuvem integrada, o dimensionamento elástico de recursos, a segurança e o desempenho rápido para todas as cargas de trabalho do Oracle Database ajudam a simplificar o gerenciamento e reduzir custos.

  • Oracle Database@Azure

    O Oracle Database@Azure é o serviço Oracle Database (Oracle Exadata Database Service on Dedicated Infrastructure e Oracle Autonomous Database Serverless) executado na Oracle Cloud Infrastructure (OCI), implantado nos data centers do Microsoft Azure. O serviço oferece recursos e paridade de preços com a OCI. Compre o serviço no Azure Marketplace.

    O Oracle Database@Azure integra as tecnologias Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC) e Oracle Data Guard à plataforma Azure. Os usuários gerenciam o serviço na console do Azure e com ferramentas de automação do Azure. O serviço é implantado na Rede Virtual do Azure (VNet) e integrado ao sistema de gerenciamento de identidade e acesso do Azure. As métricas genéricas e os logs de auditoria do OCI e do Oracle Database estão disponíveis nativamente no Azure. O serviço exige que os usuários tenham uma assinatura do Azure e uma tenancy do OCI.

    O Autonomous Database foi desenvolvido na infraestrutura do Oracle Exadata, é autogerenciado, autoprotegido e autorreparável, ajudando a eliminar o gerenciamento manual do banco de dados e erros humanos. O Autonomous Database permite o desenvolvimento de aplicativos escaláveis com tecnologia de IA com qualquer dado usando recursos integrados de IA usando sua escolha de modelo de linguagem grande (LLM) e local de implantação.

    O Oracle Exadata Database Service e o Oracle Autonomous Database Serverless são facilmente provisionados por meio do Portal nativo do Azure, permitindo o acesso ao ecossistema mais amplo do Azure.

  • Data Guard

    O Oracle Data Guard e o Oracle Active Data Guard fornecem um conjunto abrangente de serviços que criam, mantêm, gerenciam e monitoram um ou mais bancos de dados standby e permitem a manutenção de bancos de dados Oracle de produção sem interrupção. O Oracle Data Guard mantém esses bancos de dados stand-by como cópias do banco de dados de produção usando replicação na memória. Se o banco de dados de produção ficar indisponível devido a uma interrupção planejada ou não planejada, o Oracle Data Guard poderá alternar qualquer banco de dados stand-by para a atribuição de produção, minimizando o tempo de inatividade associado à interrupção. O Oracle Active Data Guard fornece a capacidade adicional de descarregar cargas de trabalho de leitura principalmente para bancos de dados stand-by e também fornece recursos avançados de proteção de dados.

  • Pareamento local

    O pareamento local permite que você pareie uma VCN com outra VCN na mesma região. Pareamento significa que as VCNs se comunicam usando endereços IP privados, sem o tráfego que passa pela internet ou que é roteado pela sua rede local.

  • Pareamento remoto

    O pareamento remoto permite que recursos de diferentes VCNs se comuniquem usando endereços IP privados. O pareamento remoto elimina a necessidade de um gateway de internet ou de endereços IP públicos para instâncias que precisam se comunicar com outra VCN em outra região.

  • Rede virtual na nuvem da Hub

    Uma rede virtual na nuvem (VCN) hub atua como um ponto central para gerenciar e rotear o tráfego entre várias VCNs, tanto na mesma região quanto em diferentes regiões. Usando LPGs (Local Peering Gateways), a VCN hub se conecta a várias VCNs spoke dentro da mesma região, facilitando a comunicação eficiente e o gerenciamento centralizado. Para conectividade entre regiões, são usados grupos de pareamento remoto (RPGs), em que cada VCN é anexada a um Gateway de Roteamento Dinâmico (DRG) e estabelece conexões de pareamento remoto (RPCs). Essa configuração é particularmente útil para rotear o tráfego do Oracle Data Guard, garantindo que redo logs e outros dados de sincronização sejam transmitidos com eficiência do banco de dados principal de uma região para o banco de dados stand-by de outra região, mantendo assim a consistência dos dados e a alta disponibilidade.

O sistema local tem os seguintes componentes:

  • Data center principal

    Um data center on-premises que hospeda aplicativos e um banco de dados Oracle serve como o site principal para operações de negócios, garantindo alto desempenho e disponibilidade de dados. Para aprimorar a recuperação de desastres e a continuidade dos negócios, esse data center principal está associado a um data center em espera, geralmente localizado em uma região geográfica diferente. O data center stand-by mantém uma cópia sincronizada do banco de dados Oracle usando o Oracle Data Guard, que replica continuamente as alterações do banco de dados principal para o banco de dados stand-by. Em caso de falha ou desastre no local principal, o data center em espera pode assumir rapidamente o controle, minimizando o tempo de inatividade e a perda de dados, garantindo assim operações comerciais ininterruptas.

  • Data center stand-by

    Um data center em espera é um componente crítico de uma estratégia de recuperação de desastres, projetada para garantir a continuidade dos negócios em condições imprevistas. Ele hospeda uma réplica dos aplicativos principais e do Oracle Database, mantidos em sincronia por meio de tecnologias como o Oracle Data Guard. No caso de uma falha ou desastre no data center principal, o data center stand-by pode assumir perfeitamente as operações, minimizando o tempo de inatividade e a perda de dados. Essa configuração garante que os processos de negócios continuem funcionando sem problemas, fornecendo resiliência contra interrupções e mantendo a disponibilidade do serviço para usuários e clientes.

  • Banco de Dados

    Um banco de dados Oracle hospedado em um data center local desempenha um papel crucial no armazenamento e no gerenciamento de dados de negócios. Ele fornece um ambiente seguro e de alto desempenho para lidar com operações comerciais críticas, garantindo a integridade e a disponibilidade dos dados. Essa configuração permite que as organizações mantenham controle total sobre sua infraestrutura de dados, personalizem configurações para atender a necessidades específicas e atendam aos requisitos regulatórios. Ao aproveitar os recursos robustos de banco de dados da Oracle, as empresas podem processar transações com eficiência, gerar relatórios e dar suporte a processos de tomada de decisões.

  • Aplicativos

    Os aplicativos executados em um data center on-premises sobre um banco de dados Oracle são parte integrante das operações de negócios. Essas aplicações aproveitam o banco de dados Oracle robusto e confiável para processar transações, gerenciar dados do cliente e gerar insights críticos de negócios. Operando em um ambiente seguro e controlado, eles garantem alto desempenho, integridade de dados e conformidade com os padrões regulatórios. Essa configuração permite que as empresas personalizem sua infraestrutura para atender a necessidades específicas, fornecendo uma base estável para operações diárias e tomada de decisões estratégicas.

Recomendações

Use as recomendações a seguir como ponto de partida. Seus requisitos podem ser diferentes da arquitetura descrita aqui.

Desempenho

Uma rede OCI é altamente recomendada para replicação de recuperação de desastres (DR). A infraestrutura de rede de alto desempenho da OCI garante conectividade de baixa latência e alta largura de banda, o que é essencial para replicação e sincronização eficientes de dados entre os bancos de dados principal e stand-by. Aproveitar a rede da OCI para o Oracle Data Guard com o Oracle Database@Azure oferece vantagens significativas em desempenho, segurança e confiabilidade.

Essa configuração fortalece a DR ao permitir a transmissão rápida e segura de redo logs e dados críticos, minimizando a perda de dados e o tempo de inatividade durante cenários de failover. Além disso, os recursos de segurança integrados da OCI, incluindo criptografia de rede e controles de acesso avançados, fornecem proteção robusta para dados confidenciais.

Ao integrar a rede da OCI ao Oracle Database@Azure, as organizações podem obter uma arquitetura de banco de dados integrada, resiliente e altamente disponível que aprimora a continuidade dos negócios e a eficiência operacional.

Considerações

Considere os pontos a seguir ao implantar essa arquitetura de referência.

  • Continuidade dos negócios

    A integração do Oracle Database Autonomous Recovery Service com o Oracle Data Guard cria uma estratégia de proteção de dados abrangente e resiliente para configurações de banco de dados principal e stand-by. O Oracle Data Guard garante alta disponibilidade e recuperação de desastres, mantendo um banco de dados stand-by sincronizado que pode assumir o controle no caso de uma falha no banco de dados principal, minimizando assim o tempo de inatividade e a perda de dados.

    Complementando isso, o Oracle Database Autonomous Recovery Service fornece uma solução de backup totalmente gerenciada e centralizada com proteção contra perda de dados zero e recursos de recuperação em tempo real. Essa combinação garante proteção contínua de dados por meio de replicação em tempo real e mecanismos de backup robustos, aprimorando a integridade dos dados e a continuidade dos negócios.

  • Disponibilidade

    A implantação de várias instâncias do Oracle Database em diferentes zonas de disponibilidade (AZs) dentro de uma região, juntamente com o Active Data Guard, melhora significativamente os recursos de alta disponibilidade e recuperação de desastres. Os AZs são isolados uns dos outros, garantindo que as falhas em um não impactem os outros. Ao distribuir instâncias de banco de dados entre várias AZs, as organizações podem mitigar os riscos associados a falhas localizadas, como interrupções de energia ou problemas de hardware.

    O Active Data Guard fortalece ainda mais essa configuração, mantendo uma réplica sincronizada em tempo real do banco de dados principal, permitindo failover contínuo em caso de falha de uma instância principal. Essa abordagem garante proteção contínua de dados, tempo de inatividade mínimo e uma estratégia robusta de recuperação de desastres, fornecendo uma infraestrutura resiliente para aplicativos de missão crítica.

  • Throughput

    Ao migrar bancos de dados do local para o Azure, é crucial considerar a largura de banda do Azure ExpressRoute para garantir uma transferência suave e eficiente. Por exemplo, se você estiver migrando um pequeno banco de dados de 100 GB, um circuito ExpressRoute de 200 Mbps poderá lidar com a transferência em aproximadamente 1 hora e 10 minutos, assumindo condições ideais e sem sobrecarga. No entanto, para um banco de dados maior de 1 TB, o mesmo circuito de 200 Mbps levaria cerca de 11 horas e 40 minutos. A atualização para um circuito de 1 Gbps reduziria significativamente esse tempo para cerca de 2 horas e 20 minutos. Planeje de acordo para que toda a largura de banda não seja consumida; caso contrário, outros aplicativos que se comunicam entre o local e a nuvem poderão ser afetados.

Explorar Mais

Para saber mais sobre o Oracle Database e as ferramentas relacionadas, consulte os recursos a seguir.

Revise estes recursos de implantação para implementar esta arquitetura de referência:

Revise estes recursos adicionais:

Confirmações

  • Autors: Neeraj Tyagi, Thomas Van Buggenhout
  • Contribuintes: Emiel Ramakers, John Sulyok