Antes de Começar
Antes de começar a migrar recursos e aplicativos, considere as opções de migração e provisione e migre quaisquer bancos de dados de aplicativos necessários.
Você pode provisionar bancos de dados de aplicativos como bancos de dados separados ou como bancos de dados plugáveis (PDBs) no banco de dados de container (CDB) de um único sistema de banco de dados.
Tanto o Oracle Grid Infrastructure (que suporta DBs com vários nós) quanto o Logical Volume Manager são suportados.
Observação:
Para usar ferramentas de migração do banco de dados como ZDM (Zero Downtime Migration), a senha SYS do banco de dados de destino deve ser igual à senha SYS do banco de dados de origem a ser migrado.Existem diversas estratégias de migração que você pode usar, dependendo da complexidade da carga de trabalho e dos requisitos de tempo de inatividade.
Para obter informações sobre o provisionamento de um banco de dados, consulte Provisionar um Banco de Dados de Máquina Virtual anteriormente neste documento.
Sobre a Migração de Cargas de Trabalho
Esta seção apresenta vários cenários comuns de migração.
Um conjunto de opções migra cargas de trabalho locais para um domínio recém-criado no Oracle Cloud Infrastructure:
- Migre cargas de trabalho manualmente usando o WebLogic Administrator Console para implantar recursos e um dos seguintes métodos para implantar aplicativos:
- Console do Administrador do WebLogic
- Ferramentas de implantação do JDeveloper
- Migre cargas de trabalho usando o WLDT (WebLogic Deploy Tooling).
- Migre cargas de trabalho usando a Ferramenta de Script do WebLogic destinando scripts de implantação de aplicativo existentes para o novo domínio.
Outra opção é atualizar a ferramenta do WebLogic Server que você usa para implantar domínios no local (como Scripts WebLogic ou arquivos de modelo WebLogic Deploy Tooling) e direcioná-los para o Oracle Cloud Infrastructure a fim de criar um novo domínio e reimplantar aplicativos.
Migrar Bancos de Dados do Oracle para o Oracle Cloud Infrastructure
Antes de migrar bancos de dados Oracle ou não-Oracle de um data center local para o Oracle Cloud Infrastructure, verifique as considerações, os pré-requisitos e o processo de avaliação a seguir.
Considerações
Esta seção se aplica à migração de Bancos de Dados Oracle on-premises para o Oracle Cloud Infrastructure, que inclui as plataformas de banco de dados listadas na seção anterior. Antes de iniciar qualquer esforço de migração, compreenda a carga de trabalho individual do banco de dados, as restrições e quaisquer dependências.
- Qual é a versão atual deste banco de dados?
- Quantos bancos de dados desta versão serão migrados?
- Quantos bancos de dados estão ligados a uma linha específica de negócios (LOB)?
- Os bancos de dados estão em plataformas que não são Linux; ou seja, haverá qualquer migração de cross-endianness?
- Há bancos de dados dependentes que podem precisar ser migrados juntos?
- Há algum banco de dados de terceiros (não-Oracle) para migrar e quais versões (por exemplo, SQL Server 2016)?
- Para o banco de dados de teste e desenvolvimento, todas as cópias serão migradas ou apenas a cópia mestre?
- Qual o tamanho grande dos bancos de dados - espaço total em disco e espaço para os próprios dados em GB/TB?
- Você usará o FastConnect ou VPN para conectividade de rede com o Oracle Cloud? A largura de banda e o tamanho do banco de dados conduzirá principalmente a solução de migração.
Opções de Migração
Há muitos métodos para migrar Oracle Databases do on-premises para o Oracle Cloud Infrastructure. Cada método depende do objetivo do ponto de recuperação de negócios (RPO), do objetivo do tempo de recuperação (RTO) e do contrato de nível de serviço de disponibilidade geral (SLA). Os administradores de migração devem avaliar e mapear esses acordos de negócios com os métodos apropriados.
O Oracle Maximum Availability Architecture (MAA) trata especificamente essas opções e métodos. A tabela a seguir descreve brevemente.
| Solução | Complexidade | Granularidade da migração | Tipo de migração (físico ou lógico) | Esforço de implantação geral | Modelo de migração | Casos de uso de migração de chave |
|---|---|---|---|---|---|---|
| Exportação e Importação Convencional do Data Pump | Baixa | Médio (a) | Lógica | Alta | On-line/ponto no tempo |
|
| Data Pump Completo Transportável | Médio (a) | Baixa | Físico | Médio (a) | On-line/Contínuo
Requer que a origem seja somente leitura durante a exportação |
Banco de dados completo com o mesmo formato endian (requer a versão 11.2.0.3 do Oracle Database de origem) |
| Tablespace Transportável do Data Pump | Médio (a) | Baixa | Físico | Médio (a) | On-line/Contínuo | Conjunto de tablespaces de esquema (requer a versão 11.2.0.3 do Oracle Database de origem) |
| SQL*Loader | Baixa | Alta | Lógica | Alta | Off-line | Migrar tabelas ou esquemas específicos |
| GoldenGate | Alta | Alta | Lógica | Alta | Off-line/Contínuo |
|
| Backup e Restauração do RMAN | Baixa | Baixa | Físico | Baixa | Off-line/Contínuo | Banco de dados completo ou conjunto de tablespaces |
| Data Guard | Baixa | Baixa | Físico | Baixa | On-line/Contínuo | Banco de dados completo com tempo de indisponibilidade zero ou próximo a zero |
|
Clonagem Remota do PDB Clonagem Remota Realocação de PDB Migração do PDB |
Baixa | Baixa | Físico | Baixa | On-line/Contínuo |
|
Observação:
Muitas das soluções podem ser combinadas para criar a estratégia de migração mais eficiente. Alguns aplicativos empacotados podem ter restrições às ferramentas suportadas para migração.Dimensionamento e Planejamento de Implantação
Observação:
O esforço de dimensionamento de capacidade para o banco de dados e VM é igual ao local.- Requisitos de desempenho da carga de trabalho
- Transações por segundo
- Número de conexões do usuário
- Alterações de carga de trabalho futuras esperadas
- Requisitos de capacidade
- vCPUs
- Memória
- Capacidade de Armazenamento e E/S
- Crescimento futuro
- Requisitos de capacidade de gerenciamento
- Serviços nativos e acessibilidade da Oracle Cloud Infrastructure
- Ferramentas de monitoramento
- Soluções de backup
- Recursos de escalabilidade
- Escala do banco de dados
- Escala da VM
- Escala de cluster
- Requisitos de disponibilidade
- Soluções de alta disponibilidade do Oracle
- vMotion, DRS
- Requisitos do aplicativo
- Dependências entre componentes locais
- Fluxo de rede entre aplicativos e serviços Oracle Cloud Infrastructure
Racionalização, Padronização e Consolidação
Como parte do esforço de migração, recomendamos que a equipe de migração use essa oportunidade para padronizar a versão do banco de dados e consolidar os sistemas de banco de dados, quando apropriado. O Oracle Database 19c deve ser a versão mínima padronizada do banco de dados porque fornece a release de suporte a longo prazo.
Consolidação é uma das principais estratégias em que as organizações estão buscando maior eficiência em suas operações. A consolidação permite que as organizações aumente a utilização dos recursos de TI, o que reduz os custos porque menos recursos são necessários para obter o mesmo resultado. Os custos operacionais também são reduzidos porque menos componentes e objetos precisam ser monitorados, gerenciados e mantidos.
Os DBAs e Admins devem procurar a melhor oportunidade para consolidar o máximo de bancos de dados possível. Com o Oracle 19c, você tem a oportunidade de usar a opção multitenant do Oracle com um máximo de três bancos de dados plugáveis (PDBs). Isso oferece maior economias de escala e maior densidades de consolidação podem ser percebidas com modernização de aplicativo e banco de dados. Portanto, você deve determinar quais bancos de dados se ajustariam ao modelo de banco de dados de container (CDB) da implantação.
Junto com a consolidação, considere o gerenciamento de isolamento. Os requisitos de isolamento podem influenciar o método ou o grau de consolidação possível. O nível de isolamento que o sistema demanda determina se você consolida vários PDBs em um único banco de dados, hospedar vários bancos de dados em uma única plataforma ou usar alguma combinação de ambos os métodos. O isolamento pode ser categorizado em quatro áreas: falha, recurso, segurança e operacional. Cada modelo de nuvem trata um pouco diferente, usando recursos integrados ao SO ou ao banco de dados, geralmente combinados com recursos ou produtos avançados para fornecer uma solução completa, começando pelo risco.