Banco de Dados · FUNDATEC · 2025 | Questão sqc-qg468564

Tuning de operações UPDATE em lote e gerenciamento do log de transações

Gabarito: letra B. A técnica correta para comitar alterações em grupos menores, controlando o crescimento do log e permitindo rollback parcial é dividir a operação em lotes menores com COMMIT periódico. Isso evita que uma única transação enorme consuma todo o espaço do log e, em caso de falha, permite desfazer apenas o lote corrente, não a operação inteira – técnica clássica de tuning para operações em massa em bancos de dados.

A banca testa o conhecimento sobre como lidar com transações de grande volume que saturam o log. O problema é que uma transação longa retém registros de log até o COMMIT final; se o log estoura, a transação é abortada e todo o trabalho é perdido. A solução padrão é particionar a operação em lotes (batch) e executar COMMIT após cada lote.

Técnica	Efeito no log de transações	Permite rollback parcial?	Gerencia crescimento do log?	Adequada para UPDATE em lote?
B) Dividir em lotes com COMMIT periódico	Libera espaço do log a cada COMMIT	Sim – apenas o lote atual é desfeito	Sim – evita acúmulo excessivo	Sim – técnica clássica
A) Hint NOLOGGING	Reduz geração de log	Não – sem log, não há rollback	Parcialmente – menos log, mas sem segurança	Não – compromete recuperabilidade
C) Aumentar tamanho do log	Apenas adia o problema	Não – rollback continua total	Não – não gerencia, apenas expande	Não – não resolve a causa
D) Desabilitar recuperação	Elimina log	Não – impossível desfazer	Sim, mas perde durabilidade	Não – inviável em produção
E) Tabela temporária	Reduz log da transação principal	Parcial – depende da implementação	Parcial – pode ajudar, mas não é a técnica direta	Não – é uma abordagem indireta e menos eficiente

1Identificar operação massiva
2Particionar em lotes
3COMMIT após cada lote
4Rollback parcial em falha

LEVEL · soulevel.com.br

Alternativa A – ❌ Incorreta

A hint NOLOGGING (ou UNLOGGED em alguns SGBDs) evita que determinadas operações gerem registros de log, o que reduz o uso do log, mas não permite rollback parcial – pelo contrário, se a operação falhar, não será possível desfazê-la, pois não há log para rollback. Além disso, NOLOGGING é geralmente usada em operações de cargas iniciais ou reconstrução de índices, não em UPDATEs rotineiros que precisam de recuperabilidade.

Alternativa B – ✅ Correta ⟵ GABARITO

Dividir o UPDATE em lotes (ex.: de 10.000 linhas cada) e executar COMMIT após cada lote reduz o tamanho do log retido a cada instante, pois o log dos lotes já comitados pode ser liberado (dependendo do modo de recovery). Em caso de falha, apenas o lote atual precisa ser desfeito – os lotes anteriores já foram persistidos. Essa prática é amplamente recomendada para evitar estouro de log e melhorar a continuidade de operações massivas.

Alternativa C – ❌ Incorreta

Aumentar o tamanho do arquivo de log de transações pode aliviar temporariamente o sintoma, mas não resolve a causa – a transação ainda será uma única transação enorme. Se o log crescer excessivamente, a falha por espaço apenas será adiada, e o rollback continuará sendo total (abortando todo o trabalho). Além disso, logs muito grandes podem impactar a performance de recovery. A abordagem correta é estrutural (lotes), não apenas de capacidade.

Alternativa D – ❌ Incorreta

Desabilitar a recuperação do banco de dados (ex.: colocar o banco em modo SIMPLE recovery ou NO RECOVERY) compromete a capacidade de recuperação a falhas. Em um ambiente de produção, isso é inadmissível, pois qualquer falha entre COMMITs levaria à perda de dados. Além disso, essa opção não permite rollback parcial – um rollback exigiria restaurar um backup completo.

Alternativa E – ❌ Incorreta

Usar uma tabela temporária para armazenar resultados intermediários pode ser útil para outras finalidades (ex.: evitar repetição de consultas), mas não gerencia o crescimento do log da operação principal. O UPDATE ainda será uma única transação sobre a tabela-alvo, e todo o log será gerado do mesmo jeito. A tabela temporária não reduz o volume de log nem permite COMMITs intermediários.

PEGA ESSA DICA!

Em operações de UPDATE em lote, sempre considere dividir em lotes com COMMIT periódico. Defina um tamanho de lote que equilibre desempenho e consumo de log – por exemplo, 1.000 a 10.000 linhas por lote, dependendo do SGBD e do hardware. Teste o comportamento do log em ambiente de staging antes de executar em produção.

Gabarito: letra B