Considere que a SEMCONGER implementou um procedimento armazenado (Stored Procedure) para atualizar valores de contratos públicos, garantindo, assim, maior controle sobre as transações no banco de dados. A seguir está o código da Stored Procedure utilizada: CREATE OR REPLACE PROCEDURE atualizar_valor_contrato( p_id_contrato IN NUMBER, p_novo_valor IN NUMBER ) AS BEGIN UPDATE contratos SET valor = p_novo_valor WHERE id = p_id_contrato; COMMIT; END atualizar_valor_contrato; Porém, um analista de banco de dados apontou um problema grave na implementação que poderá comprometer a consistência transacional do sistema. Com base na análise do código apresentado, qual é a principal falha no procedimento armazenado?
- A)A falta de um ROLLBACK, após a execução do UPDATE, pode levar a inconsistências nos contratos.
Errada: a ausência de ROLLBACK não é a principal falha aqui, porque o problema central está no encerramento prematuro da transação com COMMIT.
- B)O uso de COMMIT, dentro da Stored Procedure, pode comprometer o controle transacional do sistema.
Certa: o COMMIT dentro da stored procedure pode quebrar o controle transacional e comprometer a atomicidade do processamento.
- C)O procedimento deveria utilizar uma subquery com SELECT para validar se o contrato existe antes de atualizar.
Errada: validar a existência do contrato pode ser boa prática, mas não é a principal inconsistência transacional apontada no código.
- D)O uso de IN NUMBER, como tipo dos parâmetros, pode causar erros em bancos de dados que utilizam tipos de dados dinâmicos.
Errada: o uso de IN NUMBER não é o defeito grave do procedimento, além de a questão não tratar de “tipos dinâmicos”.
Gabarito: B
Em procedimentos armazenados, a regra de ouro é simples: a lógica de transação não deve ser controlada de forma precipitada dentro da própria rotina, salvo quando isso for uma decisão muito bem planejada. Quando o procedimento faz um UPDATE e já encerra com COMMIT, ele “fecha a conta” sozinho, independentemente de como essa operação se encaixa na transação maior do sistema. Isso pode ser um problema porque a aplicação perde flexibilidade para decidir se confirma tudo ou desfaz tudo em bloco. Na prática, o principal risco é quebrar a atomicidade e o controle transacional. Se esse procedimento fizer parte de um conjunto de operações, o COMMIT interno pode gravar alterações antes da hora, dificultando rollback externo e comprometendo a consistência. Em termos de boa prática, a confirmação da transação costuma ser responsabilidade da camada que orquestra o processo, e não de cada rotina isolada. Essa orientação aparece tanto na doutrina de banco de dados quanto nas recomendações tradicionais de projetos transacionais. Por isso, o gabarito é a letra B: o problema central não é a ausência de ROLLBACK, nem a necessidade de uma subquery de validação, nem o tipo dos parâmetros. O ponto crítico é justamente o uso de COMMIT dentro da stored procedure, porque isso reduz o controle transacional do sistema e pode gerar efeitos colaterais indesejados. Em prova, quando aparecer procedure com COMMIT “solto”, acenda o alerta: o banco pode até agradecer, mas a transação chora.