ORACLE PERFORMANCE TUNING — SINCE 1990

    SLOW ORACLE IS NOT FATE.

    When the report that used to run in 3 minutes takes 40, the problem is rarely hardware. It's plan instability, stale stats, the wrong index, or a wait event hidden inside the AWR. We find it.

    70%
    Average CPU reduction on critical queries
    AWR/ASH
    Deep bottleneck analysis
    Oracle AMEC
    Only one in Brazil — twice
    11g→21c
    Full coverage of production versions

    Certified Oracle DBAs trusted by

    Brazilian Army·SAAB / SISFRON·Banco BMG·DataPrev·Porto Seguro·TRF-4·Qualicorp

    THE EASY DIAGNOSIS

    "BUY MORE CPU". THEN WHAT?

    The vendor says: upgrade the license

    Each extra core on Oracle Enterprise costs a fortune. If the query is still doing a full table scan on 200M rows, more CPU just burns money faster.

    Internal DBA focuses on what's visible

    Top SQL by CPU, top SQL by elapsed. But the real bottleneck is in latch: cache buffers chains, in a hot block serializing the entire application. Without 30 days of historical ASH, no one sees it.

    Plan flipping in production

    Query ran fast for 3 months. Stats were gathered in a bad window, the CBO changed the plan, and now it takes the database down at 8 AM. Bind peeking, adaptive cursor sharing, plan baselines — who masters them?

    HTI reads the AWR before the meeting ends

    Send the AWR and ASH report. In 24h we return root cause, proposed fix and estimated gain. No need to give us access just to discover the problem.

    TECHNICAL SCOPE

    REAL ORACLE TUNING.

    Not "rebuild index and review init parameter". Quantitative wait-event analysis, workload segmentation by service, and a fix with proven reduction measured in comparative AWR.

    01

    AWR & ADDM DEEP DIVE

    AWR snapshot-by-snapshot reading, baseline vs incident comparison, wait-class segmentation (User I/O, Concurrency, Cluster). We catch what ADDM ignores.

    AWRADDMStatspack
    02

    SQL PLAN BASELINES

    Capture, evolution and lock-in of stable plans with SPM. We end plan flipping caused by bind peeking or volatile stats. Adaptive features under control.

    SPMSQL ProfilesHints
    03

    RAC TUNING

    Diagnosis of gc current block busy, gc cr block lost, cross-instance enqueues. Service rebalancing per instance. Cache fusion under real load, not a whitepaper.

    RACCache FusionServices
    04

    ASM & STORAGE

    Diskgroups with hot spots, badly multiplexed redo logs, ASMM vs AMM. I/O optimization without changing storage — using what's already paid for.

    ASMRedoTempfile
    05

    PARTITIONING & INDEX

    Partition pruning strategy, local vs global indexes, bitmap in DW, IOT in lookup. When partition exchange saves the ETL and when it hurts OLTP.

    RangeHashListComposite
    06

    VERSION UPGRADE

    11g→19c with no plan regression. Optimizer_features_enable, pre-migration SQL Plan Baselines, workload capture with SQL Tuning Sets. Upgrade without an all-nighter.

    11g→19c19c→21cSPA

    ORACLE AMEC — ONLY ONE IN BRAZIL

    WHO WILL TOUCH YOUR ORACLE?

    Not an analyst who learned Oracle during quarantine. A team that's been training Oracle DBAs since before 9i, in a controlled physical room at PIT/SP.

    • Only MySQL AMEC of Oracle University in Brazil — twice
    • DBAs with track record at Brazilian Army, BMG, DataPrev, Porto Seguro
    • Physical room with biometric access — no remote freelancers
    • Oracle incident history preserved since 8i

    35 years reading AWR. The wait-event pattern that looks new to you is, to us, a variant of something we saw in 2008.

    MEASURED RESULTS

    BEFORE AND AFTER.

    MAJOR RETAILER

    40min 90s

    Monthly close

    Accounting close query on Oracle 19c cut from 40 minutes to 90 seconds with SQL Plan Baseline + correlated subquery rewrite.

    FINANCIAL INSTITUTION

    -70% CPU

    4-node RAC

    Eliminated gc current block busy on a 4-node RAC via service rebalance and hash partitioning. Average CPU dropped from 85% to 25%.

    PUBLIC SECTOR

    ZERO ROLLBACK

    Upgrade 11g → 19c

    Migration from Oracle 11.2.0.4 to 19c on a 12TB environment with no rollback and no plan regression, using SPA + SPM + pre-captured STS.

    METHODOLOGY

    FROM AWR TO FIX IN 7 DAYS.

    Day 1

    AWR/ASH collection

    You send AWR (1 week, 1h interval) + ASH report from the problem window + alert.log from the last 30 days. No environment access required.

    Days 2–3

    Technical diagnosis

    Wait-class segmentation, top SQL by DB time analysis, plan-flip / latch / enqueue identification. Report with documented root cause.

    Days 4–5

    Prioritized fix plan

    Fixes ordered by ROI: what returns 80% of the gain with 20% of the risk. Impact estimate based on measurement, not opinion.

    Days 6–7

    Supervised rollout

    Staging implementation with comparative SPA, validation, production deploy with rollback plan. Post-fix AWR proves the gain.

    FAQ

    Frequently asked.

    Do you need access to my Oracle environment to start?

    +

    No. The initial diagnosis runs on AWR report, ASH report and alert.log that you generate and send. We only request access when the fix enters staging — and even then with a restricted, audited user revoked at project end.

    Do you support Oracle Standard Edition or only Enterprise?

    +

    Both. On Standard Edition the toolset is smaller (no native AWR, no partitioning), so we use Statspack, V$ views and compatible strategies. The gain is often larger because most SE environments are deeply under-optimized.

    How do you prevent the query plan from flipping after the fix?

    +

    With SQL Plan Management (SPM). We capture the optimized plan, lock it as an accepted baseline, and any new plan only reaches production if it's provably better. Immune to bad stats collection or bind peeking changes.

    Performance reduction guarantee?

    +

    We guarantee diagnosis with documented root cause. In 95% of AWRs submitted over the past 5 years, we delivered at least 30% reduction in CPU or elapsed time on the target query. When it's not possible, we say so upfront — no charge for the fix.

    Do you support Oracle on Cloud (OCI, AWS RDS for Oracle, Azure)?

    +

    Yes. OCI Autonomous, OCI Base Database, AWS RDS for Oracle and Azure Database for Oracle. Tools change (OEM vs Performance Insights vs CloudWatch); diagnosis principles do not.

    SEND THE AWR.

    20 minutes with a Senior Oracle DBA. You send the AWR, we return the technical diagnosis. No sales form, no 30-page proposal.

    Versions and editions covered

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

    WHY HTI

    DATABASE
    AUTHORITY
    SINCE 1990.

    Sustaining critical environments in Brazil since 1990. We're not a generic consultancy that learned databases — we are The Database Company.

    01

    35+ YEARS IN MARKET

    Continuously operating since 1990. 25,000+ consulting hours delivered and 596+ critical production incidents resolved. Pattern recognition only decades of real operation can build.

    02

    ORACLE AMEC — ONLY IN BRAZIL

    The only MySQL Authorized Education Center (AMEC) of Oracle University in Brazil — achieved twice. Over 1,000 DBAs trained in official HTI courses.

    03

    CONTROLLED PHYSICAL FACILITY

    DBAs operate from a restricted-access room at PIT São José dos Campos: 24h CCTV, biometric access, dedicated rack. No remote freelancers, no improvised workstations. Compliance that goes beyond internal policy.

    04

    DBSNOOP — PROPRIETARY TOOL

    Behavioral monitoring developed in-house. Detects anomalous ingestion patterns and access to protected objects — no third-party tool dependency.