PERFORMANCE TUNING ORACLE — DESDE 1990

    ORACLE LENTO NO ES DESTINO.

    Cuando el reporte que corría en 3 minutos pasa a tardar 40, el problema rara vez es hardware. Es plan instability, estadística desactualizada, índice equivocado o un wait event escondido en el AWR. Lo encontramos.

    70%
    Reducción media de CPU en queries críticas
    AWR/ASH
    Análisis profundo de bottlenecks
    Oracle AMEC
    Única en Brasil — dos veces
    11g→21c
    Cobertura completa de versiones en producción

    DBAs Oracle Certificados confiados por

    Ejército Brasileño·SAAB / SISFRON·Banco BMG·DataPrev·Porto Seguro·TRF-4·Qualicorp

    EL DIAGNÓSTICO FÁCIL

    "COMPRA MÁS CPU". ¿Y DESPUÉS?

    El proveedor dice: aumente la licencia

    Cada core adicional en Oracle Enterprise cuesta una fortuna. Si la query sigue haciendo full table scan en una tabla de 200M registros, más CPU solo quema más dinero más rápido.

    DBA interno se enfoca en lo visible

    Top SQL by CPU, top SQL by elapsed. Pero el cuello de botella real está en latch: cache buffers chains, en bloque caliente que serializa toda la aplicación. Sin ASH histórico de 30 días, nadie lo ve.

    Plan flipping en producción

    La query corrió rápido por 3 meses. Recolectó estadística en mala ventana, el CBO cambió el plan, y ahora tira la base a las 8 AM. Bind peeking, adaptive cursor sharing, plan baselines — ¿quién domina?

    HTI lee el AWR antes de terminar la reunión

    Usted envía el AWR y el ASH report. En 24h devolvemos root cause, fix propuesto y estimación de ganancia. Sin necesidad de mover su ambiente para descubrir el problema.

    ALCANCE TÉCNICO

    TUNING ORACLE REAL.

    No es "rebuild de índice y revisar parámetro init". Es análisis cuantitativo de wait events, segmentación de carga por servicio, y fix con prueba de reducción medida en AWR comparativo.

    01

    AWR & ADDM DEEP DIVE

    Lectura de AWR snapshot a snapshot, comparación baseline vs incident, segmentación por wait class (User I/O, Concurrency, Cluster). Identificamos lo que ADDM ignora.

    AWRADDMStatspack
    02

    SQL PLAN BASELINES

    Captura, evolución y fijación de planes estables con SPM. Acabamos con plan flipping causado por bind peeking o estadísticas volátiles. Adaptive features bajo control.

    SPMSQL ProfilesHints
    03

    RAC TUNING

    Diagnóstico de gc current block busy, gc cr block lost, cross-instance enqueues. Rebalanceamiento de servicios por instancia. Cache fusion bajo carga real, no whitepaper.

    RACCache FusionServices
    04

    ASM & STORAGE

    Diskgroups con hot spots, redo log multiplex mal configurado, ASMM vs AMM. Optimización de I/O sin cambiar storage — solo usando lo que ya está pagado.

    ASMRedoTempfile
    05

    PARTITIONING & INDEX

    Estrategia de partition pruning, local vs global indexes, bitmap en DW, IOT en lookup. Cuándo partition exchange salva el ETL y cuándo perjudica el OLTP.

    RangeHashListComposite
    06

    MIGRACIÓN DE VERSIÓN

    11g→19c sin regresión de plan. Optimizer_features_enable, SQL Plan Baselines pre-migración, captura del workload con SQL Tuning Sets. Upgrade sin trasnochar.

    11g→19c19c→21cSPA

    ORACLE AMEC — ÚNICA EN BRASIL

    ¿QUIÉN VA A TOCAR SU ORACLE?

    No es un analista que aprendió Oracle en la cuarentena. Es un equipo que forma DBAs Oracle desde antes del 9i, en sala física controlada en el PIT/SP.

    • Único MySQL AMEC de Oracle University en Brasil — dos veces
    • DBAs con track record en Ejército, BMG, DataPrev, Porto Seguro
    • Sala física con acceso biométrico — sin freelancer remoto
    • Historial de incidentes Oracle preservado desde 8i

    35 años leyendo AWR. El patrón de wait event que le parece nuevo, para nosotros es variación de lo que vimos en 2008.

    RESULTADOS MEDIDOS

    ANTES Y DESPUÉS.

    GRAN MINORISTA

    40min 90s

    Cierre mensual

    Query de cierre contable en Oracle 19c reducida de 40 minutos a 90 segundos con SQL Plan Baseline + reescritura de subquery correlacionada.

    INSTITUCIÓN FINANCIERA

    -70% CPU

    RAC 4 nodos

    Eliminación de gc current block busy en RAC de 4 nodos vía rebalance de servicios y particionamiento por hash. CPU media bajó de 85% a 25%.

    SECTOR PÚBLICO

    ZERO ROLLBACK

    Upgrade 11g → 19c

    Migración de Oracle 11.2.0.4 a 19c en ambiente de 12TB sin rollback y sin regresión de plan, usando SPA + SPM + STS pre-captura.

    METODOLOGÍA

    DEL AWR AL FIX EN 7 DÍAS.

    Día 1

    Recolección de AWR/ASH

    Usted envía AWR (1 semana, intervalo 1h) + ASH report de la ventana del problema + alert.log de los últimos 30 días. Sin necesidad de dar acceso al ambiente.

    Días 2–3

    Diagnóstico técnico

    Segmentación por wait class, análisis de top SQL por tiempo de DB, identificación de plan flips, latches y enqueues. Informe con root cause documentado.

    Días 4–5

    Plan de fix priorizado

    Fixes ordenados por ROI: lo que devuelve 80% de la ganancia con 20% del riesgo. Estimación de impacto basada en medición, no en opinión.

    Días 6–7

    Aplicación supervisada

    Implementación en homologación con SPA comparativo, validación, deploy en producción con plan de rollback. AWR post-fix probando la ganancia.

    FAQ

    Preguntas frecuentes.

    ¿Necesitan acceso a mi ambiente Oracle para empezar?

    +

    No. El diagnóstico inicial se hace con AWR report, ASH report y alert.log que usted genera y envía. Solo pedimos acceso cuando el fix entra en homologación — y aun así con usuario restringido, auditado y revocado al fin del proyecto.

    ¿Atienden Oracle Standard Edition o solo Enterprise?

    +

    Ambos. En Standard Edition el conjunto de herramientas es menor (sin AWR nativo, sin partitioning), así que usamos Statspack, V$ views y estrategias compatibles. La ganancia suele ser aún mayor, porque la mayoría de los ambientes SE están subóptimos.

    ¿Cómo evitan que el plan de la query cambie después del fix?

    +

    Con SQL Plan Management (SPM). Capturamos el plan optimizado, lo fijamos como baseline aceptado, y cualquier plan nuevo solo entra en producción si es comprobadamente mejor. Inmune a recolección de estadística mala o cambio de bind peeking.

    ¿Garantía de reducción?

    +

    Garantizamos diagnóstico con root cause documentado. En 95% de los casos con AWR enviado en los últimos 5 años, devolvemos al menos 30% de reducción en CPU o elapsed time de la query objetivo. Cuando no es posible, lo decimos antes — no cobramos el fix.

    ¿Atienden Oracle on Cloud (OCI, AWS RDS for Oracle, Azure)?

    +

    Sí. OCI Autonomous, OCI Base Database, AWS RDS for Oracle y Azure Database for Oracle. Las herramientas cambian (OEM vs Performance Insights vs CloudWatch), los principios de diagnóstico son los mismos.

    ENVÍE EL AWR.

    20 minutos con un DBA Senior Oracle. Usted manda el AWR, devolvemos el diagnóstico técnico. Sin formulario comercial, sin propuesta de 30 páginas.

    Versiones y ediciones atendidas

    Oracle 11g R2Oracle 12cOracle 19cOracle 21cOracle RACOracle ASMOracle Standard EditionOracle EnterpriseOCI AutonomousAWS RDS for OracleAzure OracleOracle Exadata

    POR QUÉ HTI

    AUTORIDAD
    EN BASE
    DE DATOS.

    Sustentando ambientes críticos en Brasil desde 1990. No somos una consultoría genérica que aprendió base de datos — somos The Database Company.

    01

    35+ AÑOS EN EL MERCADO

    Operando ininterrumpidamente desde 1990. Más de 25.000 horas de consultoría entregadas y 596+ incidentes críticos resueltos en producción. Pattern recognition que solo viene con décadas de operación real.

    02

    ORACLE AMEC — ÚNICA EN BRASIL

    Único MySQL Authorized Education Center (AMEC) de Oracle University en Brasil — logro obtenido dos veces. Más de 1.000 DBAs formados en cursos oficiales HTI.

    03

    SALA FÍSICA CONTROLADA

    DBAs en sala de acceso restringido en PIT São José dos Campos: cámaras 24h, acceso biométrico, rack dedicado. Sin freelancer remoto, sin estación improvisada. Compliance que va más allá de la política interna.

    04

    DBSNOOP — HERRAMIENTA PROPIA

    Monitoreo comportamental desarrollado internamente. Detecta patrones anómalos de ingestión y accesos a objetos protegidos — sin dependencia de herramienta de terceros.