Skip to Main Content
Feature Request FR-4656
Product Area Developer Experience
Status CLOSED

3 Voters

Integrated Suite for Performance Tuning and Application Monitoring

ld.diaz Public
· Sep 17 2025

Idea Summary
Introduce an integrated tool in Oracle APEX Builder for automated performance tuning and continuous monitoring. It detects costly patterns (e.g., high max_row_count queries, unindexed table growth, heavy Ajax processes), suggests fixes (pagination, materialized views, partitioning, indexes, caching), and provides real-time telemetry on latency, resource usage, and sessions. The goal is to cut response times, boost scalability, and improve governance.

Problem

  • Developers need to manually analyze multiple sources (AWR/ASH, logs, APEX Advisor) to identify performance bottlenecks.
  • Reports and interactive grids often use max_row_count with excessive row retrieval, causing load on DB and network.
  • Poor database design (missing indexes/partitions, frequent full table scans) degrades performance.
  • High-consumption processes, callbacks, or Ajax calls remain hidden until saturation occurs.
  • Runtime sometimes executes redundant conditions/validations, lacking internal metadata caching.

Objectives

  • Automatically detect bottlenecks and anti-patterns.
  • Recommend prioritized fixes with estimated impact.
  • Provide monitoring dashboards for live and historical performance.
  • Support governance with SLOs, alerts, and executive reporting.

Scope

  • Covers all regions (IR/IG, Classic Reports, Charts, Cards, Faceted Search), processes (PL/SQL, Ajax, REST), LOVs, and runtime assets.
  • Includes both SQL/DB layer and APEX runtime components (rendering, validations, conditions, dynamic actions).

Use Case
 

  1. Slow Interactive Reports/Grids at Peak Hours: IR/IG pages frequently hit high max_row_count and show long p95 render times. Suite flags the pages, shows offending SQL and full table scans, and recommends strict pagination + MV or index.
  2. Runaway Ajax on Search-as-You-Type: A text filter triggers many Ajax refreshes without debounce. Suite detects bursty calls, quantifies extra CPU/DB time, and offers a Quick Fix to add debounce/throttle and cap payload size.
  3. Hidden Hotspots in Page Processes/Callbacks: A page “Save” process occasionally spikes to multi-second p99. Profiler surfaces the PL/SQL block, shows bind sizes and plan, and suggests batching or refactoring.
  4. Tables Growing without Partitions/Indexes: Monthly growth makes reports degrade over time. Database Assistant alerts on growth trend + FTS, proposes partitioning and composite/functional indexes with sample DDL.
  5. Governance & SLO Breaches: Execs require p95 < 500 ms for core pages. Dashboard shows SLO status, emits alerts on breach, and links to the exact bottleneck (region/process/SQL).

Preferred Solution (Optional)
Goal: Provide a first-class, integrated Tuning & Monitoring experience in APEX that automatically detects bottlenecks, recommends fixes with impact estimates, and validates improvements via live telemetry—without breaking existing apps.

  • Built-in Suite in Builder: New Performance section: Scan → Findings → Fixes → Live Metrics.
  • Automated Scans & Rules: Detect high max_row_count, repeated FTS, missing/ineffective indexes, unpartitioned growth, redundant conditions/validations, excessive DA triggers, large binds, and heavy Ajax processes.
  • Actionable Recommendations (Quick Fix): One-click apply: strict pagination, required filters, MV binding, index/partition suggestions, debounce/throttle, enable caching (LOV/region/REST), and payload limits.
  • Profiler & Telemetry: Per region/process metrics (avg/p95/p99, rows/bytes, plan hash).Dev Toolbar mini-panel + APEX views for historical trends and SLO tracking.
  • Governance: Define SLOs per app/page, thresholds for alerts, exportable reports (PDF/CSV), and change logs for applied fixes.
  • Safe Rollout: Opt-in per app/workspace; scan-only mode first; configurable sampling to cap overhead.
We reviewed this idea carefully, and while it was interesting, we concluded that due to all the internal implications we need to take into account, it is unlikely to make its way into APEX.

Comments

Comments

  • fac586 OP 3 months ago

    Duplicate of FR-4051

  • vincent morneau Admin OP 2 months ago

    Hi @ld.diaz thanks for sharing several ideas recently. We’re noticing more proposals that appear to be AI-generated or AI-assisted, including this one. While that’s not necessarily a problem, it often makes the ideas harder to evaluate and turn into actionable steps. This particular idea of yours makes broad claims across multiple APEX components, which makes it unactionable at this stage. If you’d like, please consider refining and refocusing your idea in a human-written reply so we can better assess it.