Um sistema de controle de inquéritos possui um pacote PL/SQL que referencia estaticamente a tabela PROCESSO_SIGILO. Após a execução de "ALTER TABLE PROCESSO_SIGILO MODIFY (NUMERO VARCHAR2(50)) o pacote passa a apresentar status INVALID" no dicionário de dados. Em ambiente com dependências compiladas estaticamente, o comportamento do Oracle Database, nesse cenário, é que a DDL
Amantém o pacote válido se a modificação ocorrer dentro do mesmo schema do pacote.
Binvalida o pacote dependente que é recompilado na próxima execução, caso não haja inconsistência semântica.
Cpreserva a validade do pacote, pois modificações de tipo não afetam dependências previamente compiladas.
Dinvalida as triggers associadas, mantendo pacotes válidos até recompilação manual obrigatória.
Einvalida o pacote e impede qualquer tentativa de recompilação automática em tempo de execução.
Revelar gabarito e comentário▾
GabaritoB — invalida o pacote dependente que é recompilado na próxima execução, caso não haja inconsistência semântica.
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”.
Oracle Database: dependências de objetos e invalidação por DDL
Gabarito: letra B. No Oracle Database, quando uma DDL altera a estrutura de uma tabela referenciada estaticamente por um pacote PL/SQL, o pacote é marcado como INVALID no dicionário de dados e será recompilado automaticamente na próxima execução, desde que não haja inconsistência semântica. Esse é o comportamento padrão do mecanismo de dependências compiladas estaticamente do Oracle.
O Oracle Database gerencia dependências entre objetos de banco de dados de forma automática. Quando um objeto PL/SQL (como um pacote, procedimento, função ou trigger) referencia estaticamente uma tabela, o banco registra essa dependência no dicionário de dados. Se uma DDL alterar a estrutura da tabela — como o ALTER TABLE ... MODIFY que muda o tipo ou tamanho de uma coluna — o Oracle invalida todos os objetos dependentes, marcando-os com status INVALID. Isso acontece porque o código compilado do pacote contém informações sobre a estrutura da tabela no momento da compilação, e qualquer alteração pode tornar essas informações obsoletas.
A invalidação é uma medida de segurança: o Oracle não sabe se a alteração afetará a semântica do código até tentar recompilá-lo. Por isso, ao invés de arriscar executar um código potencialmente incompatível, ele invalida o objeto. Na próxima vez que o pacote for chamado, o Oracle tenta recompilá-lo automaticamente. Se a recompilação for bem-sucedida — ou seja, se o código ainda for semanticamente válido com a nova estrutura da tabela — o pacote volta ao status VALID e executa normalmente. Se houver erro de compilação (por exemplo, o código referencia uma coluna que foi removida), a execução falha com uma mensagem de erro.
Esse mecanismo é conhecido como recompilação automática em tempo de execução (ou automatic recompilation at runtime). Ele é uma característica fundamental do Oracle para manter a consistência entre objetos e seus dependentes, evitando que o desenvolvedor precise recompilar manualmente cada objeto após uma alteração de esquema. A alternativa B captura exatamente esse comportamento: a DDL invalida o pacote, e ele é recompilado na próxima execução, caso não haja inconsistência semântica.
A pegadinha da questão está em confundir esse comportamento com outras possibilidades: alguns candidatos podem achar que a DDL não afeta o pacote (alternativa C), que a invalidação é permanente (alternativa E), ou que apenas triggers são afetadas (alternativa D). A alternativa A também é um distrator, pois sugere que a invalidação depende do schema, o que não é verdade — a invalidação ocorre independentemente do schema.
NÃO CAIA NESSA!
A banca explora a confusão entre invalidação e recompilação. Muitos candidatos acham que, uma vez invalidado, o pacote precisa de recompilação manual obrigatória (alternativa E) ou que a DDL não afeta o pacote (alternativa C). Na verdade, o Oracle invalida automaticamente e recompila na próxima execução — esse é o ponto central da questão.
1DDL altera a tabela
2Pacote marcado INVALID
3Próxima execução
4Recompilação automática
5[+] Sem inconsistência → VALID
6[-] Com inconsistência → erro
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Afirma que o pacote permanece válido se a modificação ocorrer no mesmo schema. Isso é falso: a invalidação por DDL ocorre independentemente do schema. O Oracle invalida qualquer objeto que dependa estaticamente da tabela alterada, esteja ele no mesmo schema ou em outro. A dependência é registrada no dicionário de dados e a invalidação é automática, sem considerar a localização do objeto.
Alternativa B — ✅ Correta ⟵ GABARITO
Descreve corretamente o comportamento do Oracle: a DDL invalida o pacote dependente, e ele é recompilado automaticamente na próxima execução, desde que não haja inconsistência semântica. Esse é o mecanismo padrão de gerenciamento de dependências do Oracle, que garante que o código seja revalidado após alterações de esquema.
Alternativa C — ❌ Incorreta
Afirma que modificações de tipo não afetam dependências previamente compiladas. Isso é incorreto: qualquer alteração na estrutura da tabela — incluindo mudança de tipo ou tamanho de coluna — invalida os objetos dependentes. O Oracle não faz distinção entre alterações que afetam ou não a semântica; ele invalida por precaução e recompila depois.
Alternativa D — ❌ Incorreta
Diz que a DDL invalida triggers e mantém pacotes válidos até recompilação manual. Isso é falso: a DDL invalida todos os objetos dependentes, incluindo pacotes, não apenas triggers. Além disso, a recompilação é automática, não manual obrigatória.
Alternativa E — ❌ Incorreta
Afirma que a DDL impede qualquer tentativa de recompilação automática em tempo de execução. Isso é o oposto do comportamento real: o Oracle tenta recompilar automaticamente na próxima execução. A recompilação automática é uma característica central do mecanismo de dependências, não algo que a DDL impeça.