Conceito e mecanismo
Uma application PDB pode consumir uma aplicação gerida num application root. Instalar ou atualizar nesse root não significa que todas as application PDBs tenham sido sincronizadas; planeia a versão pretendida e verifica o estado de cada uma. Clonar uma PDB também exige requisitos de consistência, espaço e acesso. No hot clone documentado, ARCHIVELOG e local undo permitem manter a origem operacional em READ WRITE; os logs necessários devem permanecer disponíveis durante a operação. Não generalizes este fluxo a qualquer modo de undo ou instalação antiga. Transporte entre ambientes precisa de validar compatibilidade, componentes, ficheiros e mecanismos de cifragem antes da abertura aos utilizadores.
Aplicação guiada
Num projeto fictício de migração, constrói uma matriz com origem, destino, versão, modo de cifragem, owners e critérios de validação. Uma cópia com avisos não deve ser aceite apenas porque abriu. Investiga incompatibilidades e testa operações representativas. Chaves e keystores precisam de proteção e de um caminho de recuperação separado dos dados; um novo keystore vazio não decifra um backup anterior. Lockdown profiles podem restringir capacidades no âmbito configurado, mas não concedem privilégios em falta. Finalmente, compara a intervenção local com uma alteração no CDB root: a segunda pode afetar outros serviços e exigir coordenação mais ampla. A decisão deve registar o impacto e a via de retorno.
Migração fictícia: versão da application PDB, estado de sincronização, grants e serviço devem ser validados separadamente.
Armadilhas comuns
SYNC assumido; hot clone sem requisitos; ficheiros sem chaves; root como destino por defeito.
Tópicos relacionados: Containers, serviços e recursos · Backup e prova de recuperação · Recuperação seletiva e ensaios isolados
Aceita uma PDB pela compatibilidade e operação demonstradas.
Referência: Hot PDB cloning · 1Z0-183 public objectives inspected 2026-09-30; revision date not published