APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um diagnóstico começa pela operação que piorou, a janela afetada e uma baseline comparável. DB time agrega CPU e esperas não idle das sessões foreground e pode exceder o tempo de relógio quando há concorrência. Não é a duração completa do pedido entre browser e utilizador. Compara volume, throughput, tempos e classes de espera antes de atribuir causa. AWR, ASH e SQL Monitoring podem oferecer evidência detalhada, mas a utilização depende da oferta e dos packs aplicáveis. Um botão visível ou parâmetro habilitado não concede entitlement. A equipa deve saber quais os mecanismos autorizados para o ambiente, incluindo acesso por SQL direto.
Aplicação guiada
Num relatório fictício, uma consulta estima poucas linhas e processa milhões. Examina predicados, estatísticas e distribuição dos dados, usando observações reais quando disponíveis. Um plan hash igual não garante tempo igual: binds, volume, recursos e concorrência podem mudar. Binds para valores favorecem reutilização de cursores, mas não substituem avaliação dos planos para distribuições diferentes. Quando há spill para TEMP, analisa memória de trabalho e consumo agregado antes de aumentar limites. Para consultas longas, RETENTION GUARANTEE pode preservar undo não expirado à custa de falhas de DML se o espaço acabar. Cada mitigação deve registar o benefício esperado, o risco transferido e a medição que demonstrará melhoria.
Dez minutos de relógio e trinta de DB time representam três sessões ativas em média nessa janela.
Armadilhas comuns
CPU média como diagnóstico completo; custo como tempo; plano igual como desempenho igual; memória sem limite global.
Tópicos relacionados: Containers, serviços e recursos · Ciclo de vida e isolamento de PDBs · Backup e prova de recuperação
Compara trabalho equivalente e interpreta as métricas no seu âmbito.
Referência: Time model and wait events · 1Z0-183 public objectives inspected 2026-09-30; revision date not published