1Z0-060 · Question #231
The workload on your database remains the same between 9 AM and 6 PM on all days of the week. However, you notice performance degradation between 3 PM and 5 PM on some days. You want to identify…
The correct answer is A. 1 and 3. Identifying regressed SQL statements between two time periods requires capturing workload in SQL Tuning Sets and running SQL Performance Analyzer to compare execution plans and statistics.
Question
Options
- A1 and 3
- B1 and 5
- C1 and 2
- Donly 6
- E1 and 4
- Fonly 2
How the community answered
(36 responses)- A83% (30)
- C3% (1)
- D6% (2)
- E8% (3)
Why each option
Identifying regressed SQL statements between two time periods requires capturing workload in SQL Tuning Sets and running SQL Performance Analyzer to compare execution plans and statistics.
Step 1 captures the SQL statements and their execution context from the library cache into a SQL Tuning Set (STS) for each of the two periods (9-11 AM baseline and 3-5 PM degraded). Step 3, SQL Performance Analyzer (SPA), then executes those statements in both contexts and produces a comparison report that highlights specific regressed statements with before-and-after execution plan and performance metric details.
SQL Access Advisor recommends schema-level changes such as new indexes or materialized views to improve access paths; it does not compare SQL execution performance between two time periods to identify regression.
A Compare Period AWR report shows aggregate database-wide metrics such as wait events and throughput between two snapshots but does not drill down to identify which individual SQL statements regressed.
Compare Period ADDM diagnoses overall database performance differences between two ADDM periods at a high level; it does not provide statement-level SQL regression analysis the way SPA does.
SQL Tuning Analyzer is not a standard Oracle tool name; the correct Oracle feature for comparing SQL workload performance between two periods is SQL Performance Analyzer (SPA), not a tuning advisor.
A Compare Period AWR report alone cannot identify specific regressed SQL statements because it aggregates workload statistics across the entire database without linking degradation to individual SQL statement execution changes.
Concept tested: SQL Performance Analyzer for period comparison and regression
Source: https://docs.oracle.com/en/database/oracle/oracle-database/19/tgsql/sql-performance-analyzer.html
Topics
Community Discussion
9
Lena V.Apr 4, 2026Answer is A, steps 1 and 3. You need an STS first because SPA requires a workload input, and capturing library cache statements for both the baseline window and the degraded window gives SPA the raw material it needs to do the comparison. SPA is the correct tool here because it is specifically built to compare SQL execution plans and statistics across two periods and flag regressions at the individual statement level, which is exactly what the question is asking for. The AWR Compare Period report in step 2 and the Compare Period ADDM in step 6 are aggregate, system-level tools that tell you something changed but will not pinpoint regressed statements the way SPA does. SQL Access Advisor in step 5 recommends structural changes like indexes and materialized views, so it is solving a different problem entirely.
Luis F.Dec 24, 2025The correct answer is A, steps 1 and 3. You first create a SQL Tuning Set to capture the actual SQL statements and their execution statistics from the library cache during both the normal period and the degraded 3-5 PM window, because SPA needs that captured workload as its input. Then you run the SQL Performance Analyzer against those two STSs to directly compare execution plans and performance metrics, which is exactly what flags regressed statements. The other options miss the mark because Compare Period AWR (step 2) and Compare Period ADDM (step 6) give you system-level and ADDM finding comparisons but do not pinpoint individual regressed SQL statements the way SPA does, and SQL Tuning Advisor plus SQL Access Advisor are remediation tools, not regression detection tools.
Ola B.Dec 15, 2025Took the 1Z0-060 back in 2019 and this exact scenario tripped me up for a minute because I almost circled C thinking the Compare Period AWR report alone would point me at the regressed SQL, but that report gives you a high-level workload diff, not statement-level regression analysis. The move is A, capture your STS from the library cache for both windows then feed it into SPA, which compares execution plans and stats per statement so you can pinpoint exactly what regressed between 3 and 5 PM.
Marisol N.Jan 9, 2026F, Compare Period AWR was built exactly for this scenario.
Luis F.Jan 12, 2026Hey Marisol, actually the answer is A on this one. Compare Period AWR is great but it needs two snapshot periods to diff against each other, and the question is asking about a single time window, so a standard AWR report is the right fit here.
Grace U.Apr 9, 2026D, because Compare Period ADDM already handles both periods together.
Lena V.Apr 9, 2026Grace, Compare Period ADDM actually generates separate ADDM reports for each period rather than one unified analysis, so it does not handle both periods together the way you're describing. Option A is correct because it directly compares the two AWR snapshots in a single diff-style report.
Yusuf A.Dec 12, 2025Only 6 makes sense here, Compare Period ADDM covers both periods in one shot.
Ola B.Dec 15, 2025Yusuf, Compare Period ADDM is great for comparing two snapshots but it does not give you the granular, single-period analysis that the question is asking about, so A is your answer here. Spin up a practice DB and run both reports back to back and you will see the difference in the output right away.