Which three methods can you use to create a pre-change SQL trial to capture performance
data by using SQL Performance Analyzer?(Choose three.)
A.
executing SQLstatementsin anSQL Tuning Set (STS) on a test database by using
database links to the production database.
B.
generating only execution plans on a test database without actually running SQL
statements.
C.
generating an execution plan and statistics for selective SQL statements captured in an
STS
D.
loading performance data and execution plans from an STS.
E.
generating both execution plans and statistics for each SQL statement in an STS by
actually running the SQL statements on a test database.
Explanation:
https://docs.oracle.com/cd/E11882_01/server.112/e41481/spa_pre_change.htm
#RATUG181
A – ok
B – wrong, SQL statements must be executed in workload
C – …
D – ok
E – ok
I Agree ADE
You can build SQL trials using SQL Performance Analyzer by using one of the following methods:
Executing the SQL statements in the workload
Generating execution plans for the SQL statements in the workload
Loading performance data and execution plans from a SQL tuning set (APIs only)
A,B,E
ADE
A is wrong… because the SPA has only remote execution for SQL trial on remote system, not on test system!
imo C,D,E
C – we can filter SQLs using “basic_filter” in dbms_sqlpa.create_analysis_task
D,E – we need to capture performance
data!,
B is wrong. Please see note SQL Performance Analyzer Summary (Doc ID 1577290.1)
”
TEST EXECUTE
PARSE_TIME
ELAPSED_TIME
CPU_TIME
USER_IO_TIME
BUFFER_GETS
DISK_READS
DIRECT_WRITES
OPTIMIZER_COST
IO_INTERCONNECT_BYTES
EXPLAIN PLAN
PARSE_TIME
OPTIMIZER_COST
CONVERT SQLSET
PARSE_TIME
ELAPSED_TIME
USER_IO_TIME
IO_INTERCONNECT_BYTES
”
A is wrong. Impact on performance of production database!?