Readme

# Oracle DBA Daily + Performance Tuning Toolkit

This pack gives you practical daily DBA checks and performance tuning queries in SQL*Plus-ready format (`SET` + `COLUMN FORMAT`).

## Prerequisites

- Run as a user with access to `V$`, `GV$`, and `DBA_HIST_*` views.
- For AWR/ASH-based scripts (`DBA_HIST_*`, `GV$ACTIVE_SESSION_HISTORY`), ensure Diagnostic/Tuning Pack licensing compliance in your environment.
- Best run from SQL*Plus or SQLcl.
- RAC-ready: dynamic performance scripts use `GV$` and include `INST_ID` where relevant, so you can see node-level behavior.

## How to run

- Daily checks: `@run_daily_dba.sql`
- Performance checks: `@run_performance_tuning.sql`
- Or run any single script directly.
- ADB-specific kit: see `adb_performance_tuning/README_ADB.md` and run `@adb_performance_tuning/run_adb_performance_tuning.sql`.
- Prometheus/Grafana snippets: see `monitoring_promql/01_node_cpu_iowait_and_iops.md`.
- Disk bottleneck narrow-down PromQL: `monitoring_promql/02_disk_bottleneck_narrowdown.md`.

## Where To Run (CDB Root vs PDB)

- Recommended default for this toolkit: run from `CDB$ROOT` for full RAC/global visibility.
- In PDB, some scripts will return partial/no data by design (especially `CDB_*`, `GV$TRANSACTION` when no active txn, and AWR-wide views).

### Run in `CDB$ROOT` (recommended)

- `daily_dba/01_instance_and_database_status.sql`
- `daily_dba/02_tablespace_usage.sql`
- `daily_dba/03_datafiles_autoextend_capacity.sql`
- `daily_dba/05_blocking_and_blocked_sessions.sql`
- `daily_dba/06_long_running_operations.sql`
- `daily_dba/08_archivelog_generation_last_24h.sql`
- `daily_dba/09_temp_usage_by_session.sql`
- `daily_dba/11_undo_tablespace_usage_and_retention_cdb_root_only.sql`
- `daily_dba/12_undo_active_transactions.sql`
- `daily_dba/13_temp_tablespace_usage_summary.sql`
- `performance_tuning/01_top_sql_by_elapsed_time_awr.sql`
- `performance_tuning/02_top_sql_by_cpu_awr.sql`
- `performance_tuning/03_top_sql_by_io_wait_awr.sql`
- `performance_tuning/04_ash_wait_profile_last_60m.sql`
- `performance_tuning/05_sql_with_plan_changes_awr.sql`
- `performance_tuning/06_high_parse_sql_shared_pool_pressure.sql`
- `performance_tuning/07_segment_hotspots_reads_writes.sql`
- `performance_tuning/08_system_waits_non_idle.sql`
- `performance_tuning/09_io_latency_by_datafile.sql`
- `performance_tuning/10_pga_temp_spill_candidates.sql`
- `performance_tuning/11_top_sessions_by_cpu_now.sql`
- `performance_tuning/12_sql_plan_history_for_sql_id.sql`
- `performance_tuning/13_undo_pressure_by_hour_awr_cdb_root_only.sql`
- `performance_tuning/14_temp_spill_workarea_histogram.sql`
- `performance_tuning/15_undo_temp_parameter_review.sql`
- `performance_tuning/16_current_running_sql_realtime.sql`
- `performance_tuning/17_ash_current_and_recent_sql.sql`
- `performance_tuning/18_awr_sql_regression_compare_cdb_root_only.sql`
- `performance_tuning/19_ash_sql_timeline_for_sql_id_cdb_root_only.sql`
- `performance_tuning/20_snapshot_too_old_incidents_from_alert_log_cdb_root_only.sql`
- `performance_tuning/21_snapshot_too_old_undo_timeline_cdb_root_only.sql`
- `performance_tuning/22_snapshot_too_old_sql_candidates_from_ash_cdb_root_only.sql`
- `performance_tuning/23_current_long_transactions_holding_undo.sql`
- `performance_tuning/24_snapshot_too_old_risk_long_queries_vs_retention.sql`
- `performance_tuning/25_snapshot_too_old_full_diagnostic_bundle.sql`
- `performance_tuning/30_share_pool_errors_from_alert_log_cdb_root_only.sql`
- `performance_tuning/34_deadlock_incidents_from_alert_log_cdb_root_only.sql`
- `performance_tuning/37_pga_sga_memory_errors_from_alert_log_cdb_root_only.sql`
- `performance_tuning/43_historical_db_time_wait_trend_cdb_root_only.sql`
- `performance_tuning/44_historical_db_response_metrics_cdb_root_only.sql`
- `performance_tuning/45_historical_sql_response_for_sql_id_cdb_root_only.sql`
- `performance_tuning/46_current_vs_baseline_response_compare_cdb_root_only.sql`
- `performance_tuning/55_iops_average_max_by_instance_cdb_root_only.sql`
- `performance_tuning/56_sqlplus_cpu_iowait_iops_narrowdown_cdb_root_only.sql`

### Can run in `PDB` (PDB-scoped view; results are local/partial)

- `daily_dba/04_invalid_objects_by_owner.sql`
- `daily_dba/07_failed_scheduler_jobs_last_24h.sql`
- `daily_dba/10_stale_optimizer_stats.sql`

### Container switch quick commands

```sql
SHOW CON_NAME;
ALTER SESSION SET CONTAINER = CDB$ROOT;
SHOW CON_NAME;
```

## Daily DBA Scripts (what they do and when to use)

### 1) `daily_dba/01_instance_and_database_status.sql`
- Purpose: Shows instance/database basics: instance status, startup time, DB role, open mode, log mode.
- Use it when: Starting your day, after restart/failover, or during incident triage.
- Watch for: Unexpected restart time, `MOUNTED` instead of `READ WRITE`, role mismatch in Data Guard.

### 2) `daily_dba/02_tablespace_usage.sql`
- Purpose: Tablespace used percent and used/total MB.
- Use it when: Checking storage pressure and planning growth.
- Watch for: Usage trending above 85-90%.

### 3) `daily_dba/03_datafiles_autoextend_capacity.sql`
- Purpose: Datafile current size, max size, autoextend status.
- Use it when: A tablespace is close to full and you need to verify extendability.
- Watch for: `AUTOEXTENSIBLE = NO`, `MAX_MB` near current size.

### 4) `daily_dba/04_invalid_objects_by_owner.sql`
- Purpose: Invalid objects grouped by owner and object type.
- Use it when: After deployments, upgrades, patching, or compilation failures.
- Watch for: Sudden increase in invalid counts in application schemas.

### 5) `daily_dba/05_blocking_and_blocked_sessions.sql`
- Purpose: Current blockers/blockees with wait time, event, SQL ID, and module.
- Use it when: Users report slowness/hangs.
- Watch for: Long blocking chains and high `seconds_in_wait`.

### 6) `daily_dba/06_long_running_operations.sql`
- Purpose: Active long operations with percent complete and ETA.
- Use it when: Data loads, index builds, stats jobs, RMAN, big maintenance tasks.
- Watch for: Very high remaining time or stalled progress.

### 7) `daily_dba/07_failed_scheduler_jobs_last_24h.sql`
- Purpose: Non-successful scheduler jobs in last 24 hours.
- Use it when: Validating batch health and automation reliability.
- Watch for: Repeated failures, long run durations, same error patterns.

### 8) `daily_dba/08_archivelog_generation_last_24h.sql`
- Purpose: Hourly archive log volume generated in MB.
- Use it when: Investigating redo spikes, FRA pressure, or heavy DML windows.
- Watch for: Abrupt volume spikes compared with normal baseline.

### 9) `daily_dba/09_temp_usage_by_session.sql`
- Purpose: Current TEMP consumers by session and SQL ID.
- Use it when: TEMP tablespace alerts or sort/hash spill issues.
- Watch for: One/few sessions consuming most TEMP.

### 10) `daily_dba/10_stale_optimizer_stats.sql`
- Purpose: Tables with stale optimizer stats.
- Use it when: Query plans changed, cardinality estimates seem wrong.
- Watch for: Large critical tables marked stale for long periods.

### 11) `daily_dba/11_undo_tablespace_usage_and_retention_cdb_root_only.sql`
- Purpose: Current UNDO tablespace capacity/usage and configured `UNDO_RETENTION`.
- Use it when: Investigating ORA-30036, ORA-01555, or undo growth pressure.
- Watch for: High used% with low free MB and retention set too low for workload.

### 12) `daily_dba/12_undo_active_transactions.sql`
- Purpose: Active transactions ranked by undo blocks/records consumed.
- Use it when: Need to identify sessions causing high undo usage.
- Watch for: One session with very high `USED_UBLK` and long-running transaction.

### 13) `daily_dba/13_temp_tablespace_usage_summary.sql`
- Purpose: TEMP total/used/free MB and usage percent by temp tablespace.
- Use it when: TEMP alerts fire or sorts/hashes are spilling heavily.
- Watch for: TEMP usage staying high for long periods, especially near 90%+.

## Performance Tuning Scripts (what they do and when to use)

### 1) `performance_tuning/01_top_sql_by_elapsed_time_awr.sql`
- Purpose: Top SQL by total elapsed time over a chosen period.
- Use it when: Overall DB is slow and you need top offenders first.
- Watch for: High elapsed time with low executions (slow single runs).

### 2) `performance_tuning/02_top_sql_by_cpu_awr.sql`
- Purpose: Top SQL by CPU consumption.
- Use it when: CPU bottleneck, high load average, low wait profile.
- Watch for: High total CPU and high avg CPU per execution.

### 3) `performance_tuning/03_top_sql_by_io_wait_awr.sql`
- Purpose: Top SQL by I/O wait time.
- Use it when: Storage latency or read-heavy slowdown suspected.
- Watch for: High I/O wait per execution.

### 4) `performance_tuning/04_ash_wait_profile_last_60m.sql`
- Purpose: ASH wait-class/event distribution for last 60 minutes.
- Use it when: Need near-real-time bottleneck direction.
- Watch for: Dominant wait class (`User I/O`, `Concurrency`, `Commit`, etc.).

### 5) `performance_tuning/05_sql_with_plan_changes_awr.sql`
- Purpose: SQL IDs with multiple plan hash values in period.
- Use it when: Performance became unstable after stats or environment changes.
- Watch for: High elapsed SQL with many plan versions.

### 6) `performance_tuning/06_high_parse_sql_shared_pool_pressure.sql`
- Purpose: SQL with high parse-to-execute ratio.
- Use it when: Excess hard/soft parse overhead suspected.
- Watch for: Ratio near or above 1.0 and high parse calls.

### 7) `performance_tuning/07_segment_hotspots_reads_writes.sql`
- Purpose: Objects with highest logical/physical reads and writes.
- Use it when: Need to identify hot tables/indexes for tuning/partitioning.
- Watch for: Objects dominating physical reads/writes.

### 8) `performance_tuning/08_system_waits_non_idle.sql`
- Purpose: Non-idle system waits ranked by total waited time.
- Use it when: Need system-level bottleneck category quickly.
- Watch for: One or two events consuming most wait time.

### 9) `performance_tuning/09_io_latency_by_datafile.sql`
- Purpose: Read/write latency by datafile.
- Use it when: Suspecting storage/file-level hotspots.
- Watch for: Files with consistently high avg read/write latency.

### 10) `performance_tuning/10_pga_temp_spill_candidates.sql`
- Purpose: Active workareas spilling to TEMP (`number_passes > 0`).
- Use it when: TEMP spikes and slow sorts/hashes.
- Watch for: High passes and high TEMP MB per session.

### 11) `performance_tuning/11_top_sessions_by_cpu_now.sql`
- Purpose: Current user sessions consuming most DB CPU.
- Use it when: Immediate CPU triage and session-level action needed.
- Watch for: Single session(s) dominating CPU usage.

### 12) `performance_tuning/12_sql_plan_history_for_sql_id.sql`
- Purpose: Detailed historical execution plans for one SQL ID.
- Use it when: Comparing good vs bad plans for same SQL.
- Watch for: Plan hash changes, join method differences, changed predicates.

### 13) `performance_tuning/13_undo_pressure_by_hour_awr_cdb_root_only.sql`
- Purpose: Historical undo pressure from `DBA_HIST_UNDOSTAT` (txn volume, ORA-01555/no-space counters, tuned retention).
- Use it when: Undo issues are periodic and you need time-window correlation.
- Watch for: Non-zero `SSOLDERRCNT` or `NOSPACEERRCNT`, and spikes in `UNDOBLKS`.

### 14) `performance_tuning/14_temp_spill_workarea_histogram.sql`
- Purpose: Workarea spill profile (optimal vs one-pass vs multipass execution).
- Use it when: Tuning PGA/workarea behavior for sort/hash operations.
- Watch for: High `spill_pct` and significant multipass executions.

### 15) `performance_tuning/15_undo_temp_parameter_review.sql`
- Purpose: Review key UNDO/TEMP/PGA parameters in one place.
- Use it when: Baseline/config review before making tuning changes.
- Watch for: `UNDO_RETENTION` too low, PGA settings too small, or unexpected `TEMP_UNDO_ENABLED`.

### 16) `performance_tuning/16_current_running_sql_realtime.sql`
- Purpose: Live view of currently running user SQL with wait event, TEMP MB, and undo blocks.
- Use it when: An issue is happening right now and you need immediate culprit sessions.
- Watch for: High TEMP MB, high undo blocks, long wait seconds.

### 17) `performance_tuning/17_ash_current_and_recent_sql.sql`
- Purpose: Recent ASH (GV$ASH) view by minute, SQL ID, wait class/event, ON CPU samples, TEMP MB.
- Use it when: You need short-term trend (last 60 minutes by default) during active incident.
- Watch for: Sudden jump in samples and TEMP allocation for one SQL ID.

### 18) `performance_tuning/18_awr_sql_regression_compare_cdb_root_only.sql`
- Purpose: Compare SQL performance in `LAST_24H` vs older baseline window from AWR.
- Use it when: SQL was historically fine but suddenly degraded.
- Watch for: `avg_elapsed_ms`, `avg_cpu_ms`, `avg_io_ms` sharply higher in `LAST_24H`.

### 19) `performance_tuning/19_ash_sql_timeline_for_sql_id_cdb_root_only.sql`
- Purpose: AWR ASH timeline by hour for one SQL ID (wait profile + TEMP usage).
- Use it when: Need to correlate exact slowdown start time and wait-class shift.
- Watch for: Change from ON CPU to waits, new wait events, TEMP MB spikes.

### 20) `performance_tuning/20_snapshot_too_old_incidents_from_alert_log_cdb_root_only.sql`
- Purpose: Pull ORA-01555 incidents from alert log with time/instance/container and extracted SQL ID when present.
- Use it when: Need direct evidence of snapshot-too-old failures and timestamps.
- Watch for: Repeated incidents on same instance/schema and SQL IDs.

### 21) `performance_tuning/21_snapshot_too_old_undo_timeline_cdb_root_only.sql`
- Purpose: Timeline of undo pressure counters (`SSOLDERRCNT`, `NOSPACEERRCNT`, `MAXQUERYLEN`, `TUNED_UNDORETENTION`).
- Use it when: Correlating ORA-01555 with undo pressure windows.
- Watch for: Non-zero `SSOLDERRCNT`, high `MAXQUERYLEN`, retention mismatch.

### 22) `performance_tuning/22_snapshot_too_old_sql_candidates_from_ash_cdb_root_only.sql`
- Purpose: Candidate SQL IDs active during AWR windows where ORA-01555 counter increased.
- Use it when: Need likely failing SQL list from historical ASH context.
- Watch for: SQL IDs with highest ASH sample concentration in error windows.

### 23) `performance_tuning/23_current_long_transactions_holding_undo.sql`
- Purpose: Current long/open transactions consuming undo blocks and records.
- Use it when: Finding sessions holding before-image data that increases ORA-01555 risk.
- Watch for: Old transaction age and high `USED_UBLK`.

### 24) `performance_tuning/24_snapshot_too_old_risk_long_queries_vs_retention.sql`
- Purpose: Active query runtime vs `UNDO_RETENTION` risk scoring (HIGH/MEDIUM/LOW).
- Use it when: Identifying currently running SQL likely to hit ORA-01555.
- Watch for: `elapsed_sec` exceeding instance `undo_retention_sec`.

### 25) `performance_tuning/25_snapshot_too_old_full_diagnostic_bundle.sql`
- Purpose: One-command bundle to run the full ORA-01555 diagnostics.
- Use it when: During incident bridge to collect all snapshot-too-old evidence quickly.
- Watch for: Consistent SQL IDs across alert log, ASH candidate list, and undo pressure windows.

## Scenario Playbook: SQL Was Fast, Then Suddenly Slow With UNDO/TEMP Errors

1. Run live culprit check: `16_current_running_sql_realtime.sql`.
2. Check current TEMP/UNDO pressure: `13_temp_tablespace_usage_summary.sql` and `11_undo_tablespace_usage_and_retention_cdb_root_only.sql`.
3. Identify heavy undo transactions: `12_undo_active_transactions.sql`.
4. Validate recent ASH behavior: `17_ash_current_and_recent_sql.sql`.
5. Compare with historical baseline in AWR: `18_awr_sql_regression_compare_cdb_root_only.sql`.
6. For one SQL ID, inspect detailed timeline: `19_ash_sql_timeline_for_sql_id_cdb_root_only.sql`.
7. If TEMP spills are high, validate PGA/workarea: `14_temp_spill_workarea_histogram.sql` and `15_undo_temp_parameter_review.sql`.
8. If plan changed, verify with: `12_sql_plan_history_for_sql_id.sql` and `05_sql_with_plan_changes_awr.sql`.

## Practical triage flow

1. Start with `08_system_waits_non_idle.sql` and `04_ash_wait_profile_last_60m.sql` to identify bottleneck type.
2. If CPU: run `02_top_sql_by_cpu_awr.sql` and `11_top_sessions_by_cpu_now.sql`.
3. If I/O: run `03_top_sql_by_io_wait_awr.sql`, `09_io_latency_by_datafile.sql`, and `07_segment_hotspots_reads_writes.sql`.
4. If plan instability: run `05_sql_with_plan_changes_awr.sql` and `12_sql_plan_history_for_sql_id.sql`.
5. If UNDO/TEMP pressure: run `11_undo_tablespace_usage_and_retention_cdb_root_only.sql`, `13_temp_tablespace_usage_summary.sql`, `13_undo_pressure_by_hour_awr_cdb_root_only.sql`, and `14_temp_spill_workarea_histogram.sql`.
6. During active incident: run `16_current_running_sql_realtime.sql` and `17_ash_current_and_recent_sql.sql`.
7. For regression proof: run `18_awr_sql_regression_compare_cdb_root_only.sql` and `19_ash_sql_timeline_for_sql_id_cdb_root_only.sql`.
8. For ongoing daily hygiene: run `@run_daily_dba.sql` every morning.

## Snapshot Too Old (ORA-01555) Troubleshooting Flow

1. Confirm incidents and times: `20_snapshot_too_old_incidents_from_alert_log_cdb_root_only.sql`.
2. Validate undo pressure at same times: `21_snapshot_too_old_undo_timeline_cdb_root_only.sql`.
3. Find likely failed SQL in those windows: `22_snapshot_too_old_sql_candidates_from_ash_cdb_root_only.sql`.
4. Check long undo-holding transactions now: `23_current_long_transactions_holding_undo.sql`.
5. Check active query risk vs retention: `24_snapshot_too_old_risk_long_queries_vs_retention.sql`.
6. Run all together: `25_snapshot_too_old_full_diagnostic_bundle.sql`.

## Additional Incident Kits

### Share Pool Kit

- Runner: `incident_kits/run_share_pool_kit.sql`
- Note: alert-log scripts currently use `V$DIAG_ALERT_EXT` for compatibility (no ORA-00942 on limited accounts). If your account has `GV$DIAG_ALERT_EXT`, switch to it for cluster-wide alert collection in one run.
- Scripts used:
- `30_share_pool_errors_from_alert_log_cdb_root_only.sql`: ORA-04031/shared pool incidents from alert log with SQL_ID extraction.
- `31_share_pool_pressure_indicators.sql`: library cache reload/invalidations pressure by instance/namespace.
- `32_shared_pool_reserved_diagnostics.sql`: shared pool reserved failures and free/used diagnostics.
- `33_share_pool_top_sql_hard_parse_pressure.sql`: top SQL driving parse/version/sharable memory pressure.

### Deadlock Kit

- Runner: `incident_kits/run_deadlock_kit.sql`
- Note: alert-log script uses `V$DIAG_ALERT_EXT` for compatibility; use `GV$DIAG_ALERT_EXT` if granted and you want all RAC nodes in one query.
- Scripts used:
- `34_deadlock_incidents_from_alert_log_cdb_root_only.sql`: ORA-00060/deadlock events from alert log.
- `35_deadlock_lock_wait_chains.sql`: current blocker/waiter chains with SQL/module context.
- `36_deadlock_locked_objects_and_sql.sql`: locked objects and current SQL per holder session.

### PGA/SGA Memory Kit

- Runner: `incident_kits/run_memory_kit.sql`
- Note: alert-log script uses `V$DIAG_ALERT_EXT` for compatibility; use `GV$DIAG_ALERT_EXT` if granted and you want all RAC nodes in one query.
- Scripts used:
- `37_pga_sga_memory_errors_from_alert_log_cdb_root_only.sql`: ORA-04030/ORA-04031 and memory errors from alert log.
- `38_pga_usage_and_limit_by_instance.sql`: PGA usage/limit indicators by instance.
- `39_sga_pool_usage_by_instance.sql`: SGA pool distribution by instance/pool/name.
- `40_process_memory_top_consumers.sql`: top process memory consumers across RAC.
- `31_share_pool_pressure_indicators.sql` + `32_shared_pool_reserved_diagnostics.sql`: shared pool pressure cross-check.

### Snapshot Too Old Kit

- Runner: `incident_kits/run_snapshot_too_old_kit.sql`
- Note: alert-log script uses `V$DIAG_ALERT_EXT` for compatibility; use `GV$DIAG_ALERT_EXT` if granted and you want all RAC nodes in one query.
- Scripts used:
- `20_snapshot_too_old_incidents_from_alert_log_cdb_root_only.sql`
- `21_snapshot_too_old_undo_timeline_cdb_root_only.sql`
- `22_snapshot_too_old_sql_candidates_from_ash_cdb_root_only.sql`
- `23_current_long_transactions_holding_undo.sql`
- `24_snapshot_too_old_risk_long_queries_vs_retention.sql`

### DB Response Time Kit

- Runner: `incident_kits/run_response_time_kit.sql`
- Scripts used:
- `41_current_db_response_metrics.sql`: current DB time/sec, wait ratio, CPU ratio, SQL response time, throughput.
- `42_current_sql_response_speed.sql`: current SQL-level average elapsed/cpu and rows-per-exec.
- `43_historical_db_time_wait_trend_cdb_root_only.sql`: historical DB time vs DB CPU vs DB wait trend by instance.
- `44_historical_db_response_metrics_cdb_root_only.sql`: historical response/throughput metric trend from AWR metric summary.
- `45_historical_sql_response_for_sql_id_cdb_root_only.sql`: historical per-snapshot SQL speed for one SQL_ID (elapsed/cpu/io/rows per exec).
- `46_current_vs_baseline_response_compare_cdb_root_only.sql`: current vs baseline comparison for key response metrics.

### Executive Summary (Quick Daily)

- Runner: `incident_kits/run_executive_summary.sql`
- Script:
- `47_executive_summary_daily_checks_cdb_root_only.sql`
- Output: ~10-15 key health lines with `GREEN / YELLOW / RED` status for fast daily review.

### AWR/ASH Bottleneck Analyzer

- Runner: `incident_kits/run_awr_ash_analyzer.sql`
- Script: `54_awr_ash_bottleneck_analyzer_cdb_root_only.sql`
- Output summary:
- Top wait classes and wait events in selected window
- Top SQL by DB time and top SQL by avg latency
- Undo risk indicators (`ORA-01555` count, undo no-space count, max query length)

### Exadata / Core Perf Kit

- Runner: `incident_kits/run_exadata_core_perf_kit.sql`
- Scripts:
- `48_os_pressure_by_instance.sql`: per-instance host pressure (load, CPU busy, free memory, physical read/write MB/s).
- `49_rac_gc_wait_profile.sql`: RAC global cache wait profile (`gc%` waits).
- `50_commit_redo_pressure.sql`: commit latency (`log file sync`) and redo pressure.
- `51_storage_latency_by_filetype.sql`: file-type latency snapshot (data/temp/log/control).
- `52_exadata_smart_scan_efficiency.sql`: smart scan/offload effectiveness and storage index savings.
- `53_exadata_top_cell_waits.sql`: top cell-related waits (`cell%` events).
- `55_iops_average_max_by_instance_cdb_root_only.sql`: historical per-instance and cluster-summed IOPS (average/max) from AWR metric summary.
- Plus current response scripts `41` and `42` for SQL-level speed context.