Na administração do Oracle 21c em um Ministério Público, que mantém sistemas de tramitação processual e consultas públicas, a prática mais adequada relacionada à instalação de correções, ao gerenciamento de versões e à administração de sessões, proces-sos e conexões é:
AUtilizar o AutoUpgrade Patching para realizar out-of-place patching de múltiplos bancos de dados com um único comando, aplicando Release Updates, Monthly Recommended Patches e one-off patches, de forma mais simples e com melhor capacidade de recuperação em caso de falhas durante o processo.
BRealizar upgrades diretamente em ambiente de produção, utilizando o Database Upgrade Assistant (DBUA) quando os ambientes Oracle de origem e de destino pertencem a usuários diferentes, já que o DBUA realiza automaticamente a checagem de compatibilidade e corrige possíveis inconsistências de forma transparente.
CAdotar a estratégia de downgrade para versões imediatamente anteriores por meio do uso do datapump (expdp/impdp), preservando as funcionalidades introduzidas pela versão superior e garantindo compatibilidade plena de objetos de dicionário de dados.
DUtilizar a reinstalação completa do Oracle como prática padrão de manutenção preventiva para garantir que todos os binários estejam atualizados, evitando a aplicação incremental de patches e reduzindo a complexidade da administração.
EControlar o número de conexões simultâneas por meio de session profiles, sem necessidade de parametrização no nível de processes ou sessions no arquivo de inicialização, pois o Oracle ajusta automaticamente esses limites de acordo com a carga.
Revelar gabarito e comentário▾
GabaritoA — Utilizar o AutoUpgrade Patching para realizar out-of-place patching de múltiplos bancos de dados com um único comando, aplicando Release Updates, Monthly Recommended Patches e one-off patches, de forma mais simples e com melhor capacidade de recuperação em caso de falhas durante o processo.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Administração do Oracle: patching, upgrades e controle de conexões
Gabarito: letra A. A prática mais adequada é utilizar o AutoUpgrade Patching para realizar out-of-place patching de múltiplos bancos de dados com um único comando, aplicando Release Updates, Monthly Recommended Patches e one-off patches, de forma mais simples e com melhor capacidade de recuperação em caso de falhas. As demais alternativas apresentam práticas incorretas ou mitos sobre a administração do Oracle.
O enunciado aborda três frentes da administração de um banco Oracle: a instalação de correções (patching), o gerenciamento de versões (upgrade/downgrade) e a administração de sessões, processos e conexões. Vamos entender cada uma delas para depois julgar as alternativas com precisão.
Patching no Oracle: A Oracle disponibiliza correções de software de diversas formas. Os principais tipos são os Interim Patches (correções pontuais de bugs), os Bundle Patch Updates (BPUs, coleções cumulativas de correções para um componente), os Patch Set Updates (PSUs, coleções cumulativas de correções de alto impacto e baixo risco) e os Security Patch Updates (SPUs, coleções de correções de segurança, antes chamados de Critical Patch Updates). A ferramenta tradicional para aplicar esses patches é o OPatch, que atua em um único Oracle home. Já o AutoUpgrade Patching é uma funcionalidade mais recente que permite aplicar patches em múltiplos bancos de dados de uma só vez, de forma out-of-place — ou seja, criando um novo Oracle home e copiando os binários, sem alterar o home original. Isso traz vantagens como a possibilidade de reverter facilmente em caso de falha (basta voltar a apontar para o home antigo) e a simplificação do processo em ambientes com muitos bancos.
Upgrade e downgrade: O upgrade de versão do Oracle pode ser feito com o Database Upgrade Assistant (DBUA), que automatiza o processo, ou com o AutoUpgrade, que é a ferramenta recomendada para upgrades em massa. O downgrade, por sua vez, é um procedimento que reverte o banco para uma versão anterior, mas não preserva as funcionalidades introduzidas pela versão superior — ele apenas torna o banco compatível com a versão antiga, e muitas vezes exige a conversão de objetos e a perda de recursos novos. O Data Pump (expdp/impdp) é uma ferramenta de exportação e importação lógica de dados, que não é o mecanismo adequado para downgrade de versão, pois não lida com a compatibilidade de binários e dicionário de dados.
Sessões, processos e conexões: No Oracle, os limites de conexões simultâneas são controlados por parâmetros de inicialização no arquivo de parâmetros (PFILE ou SPFILE). O parâmetro PROCESSES define o número máximo de processos do sistema operacional que podem se conectar ao Oracle, e o parâmetro SESSIONS define o número máximo de sessões simultâneas. Esses parâmetros não são ajustados automaticamente pelo Oracle; o DBA deve configurá-los de acordo com a capacidade do servidor e a demanda da aplicação. Não existe o conceito de "session profiles" para controlar o número de conexões — perfis de usuário (profiles) são usados para limitar recursos como CPU, I/O e tempo de sessão, mas não o número de conexões simultâneas.
Agora, vamos analisar cada alternativa, identificando o erro específico de cada uma.
Critério
AutoUpgrade Patching (A)
DBUA (B)
Data Pump p/ downgrade (C)
Reinstalação completa (D)
Session profiles (E)
Tipo de operação
Patching out-of-place em múltiplos bancos
Upgrade gráfico de versão
Exportação/importação lógica de dados
Reinstalação total do software
Controle de conexões (inexistente)
Ferramenta real?
Sim
Sim
Sim, mas para backup/migração, não downgrade
Sim, mas inadequada como manutenção
Não — conceito inventado
Uso recomendado
Aplicar RUs, MRPs e one-off patches em massa
Upgrade pontual, com planejamento prévio
Migração de dados entre bancos
Nunca como prática padrão
Nunca — limites são via PROCESSES/SESSIONS
Risco/Recuperação
Baixo risco; rollback fácil (home antigo)
Alto risco se feito direto em produção
Não preserva funcionalidades novas
Altíssimo risco e indisponibilidade
Não se aplica
Adequação ao enunciado
✅ Correta — atende patching, versões e múltiplos bancos
❌ Errada — upgrade sem teste em produção
❌ Errada — downgrade não preserva recursos
❌ Errada — invasiva e desnecessária
❌ Errada — mito sobre ajuste automático
Alternativa A — ✅ Correta ⟵ GABARITO
A alternativa A descreve corretamente o AutoUpgrade Patching. Essa ferramenta permite realizar out-of-place patching de múltiplos bancos de dados com um único comando, aplicando Release Updates (RUs), Monthly Recommended Patches (MRPs) e one-off patches. A abordagem out-of-place cria um novo Oracle home, copia os binários e aplica os patches nesse novo home, o que oferece melhor capacidade de recuperação: se algo der errado, o banco pode ser facilmente revertido para o home original. Isso é exatamente o que a alternativa afirma, e é a prática mais adequada para um ambiente corporativo como o de um Ministério Público, que precisa de alta disponibilidade e baixo risco em manutenções.
Alternativa B — ❌ Incorreta
A alternativa B afirma que se deve realizar upgrades diretamente em produção com o DBUA quando os ambientes de origem e destino pertencem a usuários diferentes. Isso está errado por dois motivos. Primeiro, upgrades em produção devem ser planejados e testados em ambientes de homologação, nunca realizados "diretamente" sem preparação. Segundo, o DBUA não é a ferramenta indicada para upgrades em massa ou para lidar com a questão de usuários diferentes — essa é uma função do AutoUpgrade, que é a ferramenta recomendada pela Oracle para upgrades, especialmente em ambientes com múltiplos bancos. O DBUA é uma ferramenta gráfica que automatiza o upgrade, mas a afirmação de que ele "corrige possíveis inconsistências de forma transparente" é uma simplificação incorreta e perigosa.
Alternativa C — ❌ Incorreta
A alternativa C propõe usar o Data Pump (expdp/impdp) para downgrade de versão, preservando funcionalidades da versão superior. Isso é incorreto por dois motivos. Primeiro, o Data Pump é uma ferramenta de exportação/importação lógica de dados, não um mecanismo de downgrade de versão. O downgrade de versão do Oracle é feito com utilitários específicos (como o downgrade script ou o próprio DBUA em modo downgrade), que revertem o dicionário de dados e os binários para a versão anterior. Segundo, o downgrade não preserva funcionalidades da versão superior — ao contrário, ele remove ou converte objetos que usam recursos novos, e pode haver perda de funcionalidades. A afirmação de que o Data Pump garante "compatibilidade plena de objetos de dicionário de dados" é falsa.
Alternativa D — ❌ Incorreta
A alternativa D sugere a reinstalação completa do Oracle como prática padrão de manutenção preventiva, evitando a aplicação incremental de patches. Isso é totalmente incorreto e vai contra as boas práticas de administração. A reinstalação completa é um procedimento invasivo, que exige parada do banco, recriação do Oracle home, reconfiguração de parâmetros e reaplicação de todas as customizações. A prática recomendada é justamente a aplicação incremental de patches (PSUs, SPUs, RUs) usando ferramentas como OPatch ou AutoUpgrade, que são menos invasivas, mais rápidas e permitem rollback. A reinstalação completa não "reduz a complexidade", ela aumenta drasticamente o risco e o tempo de indisponibilidade.
Alternativa E — ❌ Incorreta
A alternativa E afirma que se pode controlar o número de conexões simultâneas por meio de "session profiles", sem necessidade de parametrização nos níveis PROCESSES ou SESSIONS. Isso é incorreto. No Oracle, o controle de conexões simultâneas é feito exclusivamente pelos parâmetros de inicialização PROCESSES e SESSIONS, definidos no arquivo de parâmetros (PFILE/SPFILE). Esses parâmetros não são ajustados automaticamente pelo Oracle; o DBA deve configurá-los manualmente. Os perfis de usuário (profiles) são usados para limitar recursos como CPU, I/O, tempo de sessão e senhas, mas não controlam o número de conexões. A afirmação de que o Oracle ajusta automaticamente esses limites é um mito.
NÃO CAIA NESSA!
A banca explora a confusão entre ferramentas e conceitos. A alternativa B troca o AutoUpgrade pelo DBUA, a C troca o downgrade por Data Pump, e a E inventa o conceito de "session profiles" para controle de conexões. A pegadinha central é que o candidato pode se lembrar de que o DBUA é uma ferramenta de upgrade e marcar a B, mas a B está errada porque o DBUA não é a ferramenta recomendada para upgrades em massa e não deve ser usado "diretamente em produção" sem planejamento. A alternativa A é a única que descreve corretamente uma ferramenta real (AutoUpgrade Patching) com suas características corretas.
PEGA ESSA DICA!
Para questões de administração Oracle, foque em memorizar as ferramentas e suas finalidades: OPatch (aplicar patches em um home), AutoUpgrade (upgrade e patching em massa, out-of-place), DBUA (upgrade gráfico), Data Pump (export/import lógico). E lembre-se: PROCESSES e SESSIONS são parâmetros de inicialização que devem ser configurados manualmente, não são automáticos.