Oracle Database / SQL Performance & Memory
Inspect SQL with high physical-read totals
Slow read-heavy work may reflect a large intended scan, poor access path or storage latency. Start by identifying the cached statements involved.
Environment and inputs: Oracle Database 19c baseline · SQL*Plus-compatible SQL unless RMAN, DGMGRL, ADRCI or a host shell is specified. Check release, patch level, edition and container first.
Start with this diagnostic
Use the stated SQL, RMAN, DGMGRL or host shell and replace sample names with approved targets. DBA and V$ views need authorized catalog access in the correct container. Do not grant broad privileges for an example.
SELECT sql_id, child_number, executions, disk_reads, rows_processed FROM v$sql ORDER BY disk_reads DESC FETCH FIRST 20 ROWS ONLY;Read the result
DISK_READS is a cumulative cursor statistic. It does not measure individual I/O latency or prove that every block came from physical media rather than storage cache.
Resolve and verify
Measure the affected interval, inspect the access path and correlate database waits with storage metrics. Optimize unnecessary work before requesting faster storage.
Operational precautions
A single ranking after a long uptime can reflect an old batch rather than the current incident.