Oracle OCP 1Z0-050（101-110题）解析
QUESTION 101:
View the Exhibit for some of the parameter settings.
You start a session and issue the following command:
SQL>CREATE INDEX emp_ename ON emp(ename)
TABLESPACE users INVISIBLE;
What is the outcome of the above command?
A. The index is used by the optimizer only if a hint is specified in the query statement and is maintained during DML operations.
B. The index is not used by the optimizer but is maintained during DML operations.
C. The index is not used by the optimizer and is not maintained during DML operations.
D. The index is used by the optimizer only if a hint is specified in the query statement but is not maintained during DML operations.
Answer: B
解析：
参考Oracle官方文档：
https://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams173.htm#REFRN10301
Optimizer_use_invisible_indexes
OPTIMIZER_USE_INVISIBLE_INDEXES enables or disables the use of invisible indexes.
Values:
- true：Invisible indexes are treated as visible (normal) indexes.
- false：Invisible indexes will not be considered by the optimizer but will still be maintained by DML operations.
QUESTION 102:
You executed the following commands:
SQL> ALTER SESSION SET OPTIMIZER_USE_PENDING_STATISTICS = false;
SQL> EXECUTE DBMS_STATS.SET_TABLE_PREFS('SH', 'CUSTOMERS',
'PUBLISH','false');
SQL> EXECUTE DBMS_STATS.GATHER_TABLE_STATS('SH', 'CUSTOMERS');
Which statement is correct regarding the above statistics collection on the SH.CUSTOMERS table in the above session?
A. The statistics are stored in the pending statistics table in the data dictionary.
B. The statistics are treated as the current statistics by the optimizer for the current sessions only.
C. The statistics are treated as the current statistics by the optimizer for all sessions.
D. The statistics are temporary and used by the optimizer for all sessions until this session terminates.
Answer: A
解析：
参考Oracle官方文档：
https://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams174.htm#REFRN10288
https://docs.oracle.com/cd/E11882_01/server.112/e41573/stats.htm#PFGRF94751
OPTIMIZER_USE_PENDING_STATISTICS specifies whether or not the optimizer uses pending statistics when compiling SQL statements.
OPTIMIZER_USE_PENDING_STATISTICS 指定在SQL语句编译时是否使用未决定（pending）的统计信息。
Starting with Oracle Database 11g Release 2 (11.2), you have the following options when gathering statistics:
- Publish the statistics automatically at the end of the gather operation (default behavior)
- Save the new statistics saved as pending
Saving the new statistics as pending allows you to validate the new statistics and publish them only if they are satisfactory.
To check whether the statistics will be automatically published as soon as they are gathered, use the DBMS_STATS package as follows:
SELECT DBMS_STATS.GET_PREFS('PUBLISH') PUBLISH FROM DUAL;
The preceding query returns either TRUE or FALSE. TRUE indicates that the statistics will be published as and when they are gathered, while FALSE indicates that the statistics will be kept pending.
Note:
The database stores published statistics in data dictionary views such as USER_TAB_STATISTICS and USER_IND_STATISTICS. The database stores pending statistics in views such as USER_TAB_PENDING_STATS and USER_IND_PENDING_STATS.
You can change the PUBLISH setting at either the schema or the table level. For example, to change the PUBLISH setting for the customers table in the SH schema, execute the statement:
EXEC DBMS_STATS.SET_TABLE_PREFS('SH', 'CUSTOMERS', 'PUBLISH', 'false');
Subsequently, when you gather statistics on the customers table, the statistics will not be automatically published when the gather job completes. Instead, the database stores the newly gathered statistics in the USER_TAB_PENDING_STATS table.
By default, the optimizer uses the published statistics stored in the data dictionary views. If you want the optimizer to use the newly collected pending statistics, then set the initialization parameter OPTIMIZER_USE_PENDING_STATISTICS to TRUE (the default value is FALSE), and run a workload against the table or schema:
ALTER SESSION SET OPTIMIZER_USE_PENDING_STATISTICS = TRUE;
The optimizer will use the pending statistics instead of the published statistics when compiling SQL statements. If the pending statistics are valid, then you can make them public by executing the following statement:
EXEC DBMS_STATS.PUBLISH_PENDING_STATS(null, null);
You can also publish the pending statistics for a specific database object. For example, by using the following statement:
EXEC DBMS_STATS.PUBLISH_PENDING_STATS('SH','CUSTOMERS');
If you do not want to publish the pending statistics, delete them by executing the following statement:
EXEC DBMS_STATS.DELETE_PENDING_STATS('SH','CUSTOMERS');
You can export pending statistics using DBMS_STATS.EXPORT_PENDING_STATS function. Exporting pending statistics to a test system enables you to run a full workload against the new statistics.
QUESTION 103:
You plan to set up the Automatic Workload Repository (AWR) baseline metric thresholds for a moving window baseline. Which action would you take before
A. Take an immediate AWR snapshot.
B. Decrease the window size for the baseline.
C. Decrease the expiration time for the baseline.
D. Compute the baseline statistics.
Answer: D
解析：
参考Oracle官方文档：
https://docs.oracle.com/cd/E11882_01/server.112/e41573/autostat.htm#PFGRF94181
A moving window baseline corresponds to all AWR data that exists within the AWR retention period. This is useful when using adaptive thresholds because the database can use AWR data in the entire AWR retention period to compute metric threshold values.
Oracle Database automatically maintains a system-defined moving window baseline. The default window size for the system-defined moving window baseline is the current AWR retention period, which by default is 8 days. If you are planning to use adaptive thresholds, consider using a larger moving window—such as 30 days—to accurately compute threshold values. You can resize the moving window baseline by changing the number of days in the moving window to a value that is equal to or less than the number of days in the AWR retention period. Therefore, to increase the size of a moving window, you must first increase the AWR retention period accordingly.
QUESTION 104:
You are managing the APPPROD database as a DBA. You plan to duplicate this database in the same system with the name DUPDB.
You issued the following RMAN commands to create a duplicate database:
RMAN> CONNECT target sys/sys@APPPROD
RMAN> DUPLICATE TARGET DATABASE TO dupdb FROM ACTIVE DATABASE
DB_FILE_NAME_CONVERT '/oracle/oradata/prod/',
'/scratch/oracle/oradata/dupdb/'
SPILE
PARAMETER_VALUE_CONVERT '/oracle/oradata/prod/',
'/scratch/oracle/oradata/dupdb/'
SET SGA_MAX_SIZE = '300M'
SET SGA_TARGET = '250M'
SET LOG_FILE_NAME_CONVERT '/oracle/oradata/prod/redo/',
'/scratch/oracle/oradata/dupdb/redo/';
Which three are the prerequisites for the successful execution of the above command?
(Choose three.)
A. RMAN should be connected to both the instances as SYSDBA.
B. The target database backups should be copied to the source database backup directories.
C. The password file must exist for the source database and have the same SYS user password as the target.
D. The target database should be in ARCHIVELOG mode if it is open.
E. The source database should be open.
Answer: A,C,D
解析：
参考Oracle官方文档：
https://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmdupdb.htm#BRADV89929
根据题目的描述需要使用create a duplicate database技术创建一个名字为DUPDB的数据库。使用RMAN可以完成这个操作。RMAN支持两种基本类型的duplication操作：Active Database Duplication和Backup-based Duplication。
RMAN can perform backup-based duplication with or without either of the following connections:
- Target
- Recovery catalog
A connection to both is required for active database duplication.
Figure 24-1 Duplication Techniques
Active Database Duplication
In active database duplication, RMAN connects as TARGET to the source database instance and as AUXILIARY to the auxiliary instance. RMAN copies the live source database over the network to the auxiliary instance, thereby creating the duplicate database. No backups of the source database are required. Figure 24-2 illustrates active database duplication.
Backup-Based Duplication
In backup-based duplication, RMAN creates the duplicate database by using pre-existing RMAN backups and copies. This technique of duplication uses one of the following mutually exclusive subtechniques:
- Duplication without a target database connection, RMAN obtains metadata about backups from a recovery catalog.
- Duplication without a target database connection and without a recovery catalog. RMAN obtains metadata about where backups and copies reside from
BACKUP LOCATION. - Duplication with a target database connection. RMAN obtains metadata about backups from the target database control file or from the recovery catalog.
Figure 24-3 illustrates backup-based duplication without a target connection. RMAN connects to a recovery catalog database instance and the auxiliary instance. The destination host must have access to the RMAN backups required to create the duplicate database.
Figure 24-4 illustrates backup-based duplication without connections to the target or to the recovery catalog database instance. RMAN connects to the auxiliary instance of the duplicate database on the destination host. A disk backup location containing all the backups or copies for duplication must be available to the destination host.
Figure 24-4 Backup-Based Duplication Without a Target Connection or Recovery Catalog Connection
Figure 24-5 illustrates backup-based duplication with a target connection. RMAN connects to the source database instance and the auxiliary instance. Optionally, RMAN can connect to a recovery catalog database (not shown in the figure). The destination host must have access to the RMAN backups required to create the duplicate database.
Figure 24-5 Backup-Based Duplication with a Target Connection
Purpose of Database Duplication
A duplicate database is useful for a variety of purposes, most of which involve testing. You can perform the following tasks in a duplicate database:
- Test backup and recovery procedures
- Test an upgrade to a new release of Oracle Database
- Test the effect of applications on database performance
- Create a standby database
- Generate reports
For example, you can duplicate the production database on host1 to host2, and then use the duplicate database on host2 to practice restoring and recovering this database while the production database on host1 operates as usual.
If you copy a database with operating system utilities instead of the DUPLICATE command, then the DBID of the copied database remains the same as the original database. To register the copy database in the same recovery catalog with the original, you must change the DBID with the DBNEWID utility (see Oracle Database Utilities). In contrast, the DUPLICATE command automatically assigns the duplicate database a different DBID so that it can be registered in the same recovery catalog as the source database.
The DUPLICATE command can create a fully functional copy of your database or a physical standby database, which serves a very different purpose. A standby database is a copy of the primary database that you update continually with archived log files from the primary database. If the primary database is inaccessible, then you can fail over to the standby database, which becomes the new primary database. A database copy, however, cannot be used in this way: it is not intended for failover scenarios and does not support the various standby recovery and failover options.
Basic Steps of Database Duplication
This section describes the basic steps of database duplication. Follow the link in each step for further instructions.
To duplicate a database:
- Prepare for database duplication.
- Start RMAN and connect to the necessary database instances.
- Place the source database in the proper state (if necessary).
- Configure RMAN channels (if necessary).
- Perform the duplication.
Preparing to Duplicate a Database
Before duplicating the database, you must decide how to perform the duplication and then prepare the database environment, including the auxiliary database instance.
To prepare for duplication:
A. Choose a duplication technique.
While duplicating an Oracle Real Application Clusters (Oracle RAC) database, set the CLUSTER_DATABASE initialization parameter on the auxiliary database to FALSE. This parameter can be reset to TRUE after the duplication completes.
B. Choose a strategy for naming the duplicate database files.
C. For a backup-based strategy, make the backups accessible to the auxiliary instance; otherwise, skip this step.
D. Prepare remote access to databases.
E. Prepare the auxiliary instance.
QUESTION 105:
You performed the RMAN database backup with the KEEP option. Which two statements are true regarding this backup? (Choose two.)
A. The backup contains data files, the server parameter file, and the control file even if the control file autobackup is disabled.
B. The KEEP option overrides the configured retention policy.
C. The backup contains only data files and archived redo log files.
D. The KEEP option is an attribute of an individual backup piece.
Answer: A,B
解析：
参考Oracle官方文档：
https://docs.oracle.com/cd/E11882_01/backup.112/e10643/rcmsubcl011.htm
RMAN does not consider backup pieces with the KEEP option when computing the backup retention policy. If available, RMAN uses these backups for disaster recovery restore operations, but their purpose is to produce a snapshot of the database that can be restored on another system for testing or historical usage.
When creating archival backups with KEEP, RMAN only considers KEEP backups with the same tag. Thus, when using keepOption with notBackedUpSpec, RMAN only skips a backup if it finds the specified maximum number of KEEP backups with the same tag. Other backups are not counted.
Specifies the backup as an archival backup, which is a self-contained backup that is exempt from the configured retention policy.
An archival backup is self-contained because is contains all files necessary to restore the backup and recover it to a consistent state. If the database is open during the backup, then RMAN automatically generates and backs up the archived redo log files needed to make the database backup consistent (see Example 2-26).
RMAN does not consider backup pieces with the KEEP option when computing the retention policy. If available, RMAN uses these backups for disaster recovery restore operations, but their purpose is to produce a snapshot of the database that can be restored on another system for testing or historical usage.
Note: You cannot use KEEP to override the retention policy for files stored in the fast recovery area. If you specify KEEP when backing up to the recovery area, then RMAN issues an error.
When KEEP is specified, RMAN creates multiple backup sets. RMAN backs up data files, archived redo log files, the control file, and the server parameter file with the options specified in the first backupOperand. Since a backup of the control file is already created, an autobackup of the control file is not created. RMAN uses the FORMAT, POOL, and TAG parameters for all the backups. For this reason, the FORMAT string must allow for the creation of multiple backup pieces. Specifying %U is the easiest way to meet this requirement.
See Also: CONFIGURE and Oracle Database Backup and Recovery User's Guide to learn more about autobackup of the control file.
When KEEP is specified with INCREMENTAL LEVEL, the parent backup must be a KEEP backup and have the same TAG string. Unless both these criteria are met, the backup cannot be created. Backups that meet these criteria do not interfere with other nightly or archival backup tasks.
Note: A recovery catalog is only required for KEEP FOREVER. No other KEEP options require a catalog.
QUESTION 106:
You set the following parameters in the parameter file and restarted the database:
MEMORY_MAX_TARGET=0
MEMORY_TARGET=500M
PGA_AGGREGATE_TARGET=90M
SGA_TARGET=270M
Which two statements are true regarding these parameters after the database instance is restarted? (Choose two.)
A. The lower bounds of PGA_AGGREGATE_TARGET and SGA_TARGET parameters are set to 90 MB and 270 MB, respectively.
B. The value of the MEMORY_MAX_TARGET parameter remains zero till it is changed manually.
C. The MEMORY_MAX_TARGET parameter is automatically set to 500 MB.
D. The PGA_AGGREGATE_TARGET and SGA_TARGET parameters are automatically set to zero.
Answer: A,C
解析：
参考Oracle官方文档：
https://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams142.htm#REFRN10284
MEMORY_MAX_TARGET specifies the maximum value to which a DBA can set the MEMORY_TARGET initialization parameter. See the description of MEMORY_TARGET for more information about how the settings of MEMORY_MAX_TARGET and MEMORY_TARGET affect each other.
MEMORY_MAX_TARGET = integer [K | M | G]
0 to the physical memory size available to the Oracle Database
https://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams236.htm#REFRN10256
SGA_TARGET specifies the total size of all SGA components. If SGA_TARGET is specified, then the following memory pools are automatically sized:
- Buffer cache (DB_CACHE_SIZE)
- Shared pool (SHARED_POOL_SIZE)
- Large pool (LARGE_POOL_SIZE)
- Java pool (JAVA_POOL_SIZE)
- Streams pool (STREAMS_POOL_SIZE)
If these automatically tuned memory pools are set to nonzero values, then those values are used as minimum levels by Automatic Shared Memory Management. You would set minimum values if an application component needs a minimum amount of memory to function properly.
The following pools are manually sized components and are not affected by Automatic Shared Memory Management:
- Log buffer
- Other buffer caches, such as KEEP, RECYCLE, and other block sizes
- Fixed SGA and other internal allocations
The memory allocated to these pools is deducted from the total available for SGA_TARGET when Automatic Shared Memory Management computes the values of the automatically tuned memory pools.
In the Default value field, IMMEDIATE mode autotuning requests are necessary to avoid ORA-04031 errors. The DEFERRED and IMMEDIATE modes are reflected in the OPER_MODE column of the V$MEMORY_RESIZE_OPS view.
If Automatic Memory Management is enabled (MEMORY_TARGET is set to a positive value) and SGA_TARGET is also set to a positive value, the SGA_TARGET value acts as the minimum value for the size of the SGA.
https://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams193.htm#REFRN10165
PGA_AGGREGATE_TARGET specifies the target aggregate PGA memory available to all server processes attached to the instance.
Setting PGA_AGGREGATE_TARGET to a nonzero value has the effect of automatically setting the WORKAREA_SIZE_POLICY parameter to AUTO. This means that SQL working areas used by memory-intensive SQL operators (such as sort, group-by, hash-join, bitmap merge, and bitmap create) will be automatically sized. A nonzero value for this parameter is the default since, unless you specify otherwise, Oracle sets it to 20% of the SGA or 10 MB, whichever is greater.
Setting PGA_AGGREGATE_TARGET to 0 automatically sets the WORKAREA_SIZE_POLICY parameter to MANUAL. This means that SQL workareas are sized using the *_AREA_SIZE parameters.
Oracle attempts to keep the amount of private memory below the target specified by this parameter by adapting the size of the work areas to private memory. When increasing the value of this parameter, you indirectly increase the memory allotted to work areas. Consequently, more memory-intensive operations are able to run fully in memory and less will work their way over to disk.
If Automatic Memory Management is enabled (MEMORY_TARGET is set to a positive value) and PGA_AGGREGATE_TARGET is also set to a positive value, the PGA_AGGREGATE_TARGET value acts as the minimum value for the size of the instance PGA.
QUESTION 107:
You are managing an Oracle Database 11g database. You want to take a backup on tape drives of the USERS tablespace that has a single data file of 900 MB. You have tape drives of 300 MB each. To accomplish the backup, you issued the following RMAN
command:
RMAN>BACKUP SECTION SIZE 300M TABLESPACE users;
What configuration should be affected to accomplish faster and optimized backups by using the above command?
A. The SBT channel must be configured, with the default parallelism setting for the SBT device set to 1.
B. The COMPATIBLE initialization parameter for the database instance must be set to at least 10.0.
C. The SBT channel must be configured, with the parallelism setting for the SBT device set to 3.
D. The SBT channel must be configured, with the MAXPIECESIZE set to 300 MB.
Answer: C
QUESTION 108:
Exhibit:
View the Exhibit to examine the error while executing the REPAIR FAILURE command in an RMAN session.
What is the reason for this error?
A. Another repair session is running concurrently.
B. The failure ID has not been mentioned in the command for data file 5.
C. There are new failures recorded in the Automatic Diagnostic Repository (ADR).
D. The ADVISE FAILURE command has not been issued before the REPAIR FAILURE command.
Answer: A
QUESTION 109:
To control the execution of a server process when it is receiving bad packets from a potentially malicious client, you set the SEC_PROTOCOL_ERROR_FURTHER_ACTION initialization parameter as follows:
SQL> ALTER SYSTEM SET SEC_PROTOCOL_ERROR_FURTHER_ACTION =
Drop,10;
What is the significance of this setting?
A. It terminates the client connection after receiving a bad packet and the client can reconnect to the same instance after 10 minutes.
B. It terminates the client connection after 10 bad packets but the client can still reconnect, and attempt the same operation again.
C. It terminates the client connection after 10 bad packets and the client cannot reconnect to the same instance.
D. It terminates the client connection 10 seconds after receiving a bad packet and the client cannot reconnect to the same instance.
Answer: B
解析：参考Oracle官方文档：
https://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams227.htm#REFRN10282
SEC_PROTOCOL_ERROR_FURTHER_ACTION specifies the further execution of a server process when receiving bad packets from a possibly malicious client.
Values:
- CONTINUE
The server process continues execution. The database server may be subject to a Denial of Service (DoS) if bad packets continue to be sent by a malicious client.
- (DELAY,integer)
The client experiences a delay of integer seconds before the server process accepts the next request from the same client connection. Malicious clients are prevented from excessive consumption of server resources while legitimate clients experience a degradation in performance but can continue to function.
- (DROP,integer)
The server forcefully terminates the client connection after integer cumulative bad packets. The server protects itself at the expense of the client (for example, a client transaction may be lost). The client may reconnect and attempt the same operation.
QUESTION 110:
You want to analyze a SQL Tuning Set (STS) using SQL Performance Analyzer in a test database. Which two statements are true regarding the activities performed during the test execution of SQLs in a SQL Tuning Set? (Choose two.)
A. The execution plan and execution statistics are computed for each SQL statement in the STS.
B. The effects of DDL and DML are considered to produce the execution plan and execution statistics.
C. Every SQL statement in the STS is considered only once for execution.
D. The SQL statements in the STS are executed concurrently to produce the execution plan and execution statistics.
Answer: A,C
解析：
SQL Performance Analyzer翻译成中文就是SQL性能分析器，它与数据库重演特性一起构成Oracle提供的Total Replay特性，能测试重大系统更改的影响，如测试数据库升级的SQL工作负荷响应时间。SQL性能分析器分析比较系统更改前后的SQL性能，提出阻止性能退化的建议。可以在数据库、应用、操作系统或硬件升级等系统更改之后，或者在初始化参数设置更改、SQL调优活动和统计数据收集与模式更改等之后，用SQL性能分析器来分析可能的SQL性能变化。
SQL性能分析器是Oracle Database 11g的一个组成部分，它可以充分利用SQL Tuning Advisor等工具以及SQL Plan Management等特性来很好地调优数据库性能。
具体内容，参考Oracle官方文档：
https://docs.oracle.com/cd/E11882_01/server.112/e41481/spa_intro.htm#RATUG166
https://docs.oracle.com/cd/B28359_01/server.111/e12159/spa.htm#RATAD101
SQL Performance Analyzer enables you to assess the performance impact of any system change resulting in changes to SQL execution plans and performance characteristics. Examples of common system changes for which you can use SQL Performance Analyzer include:
- Database upgrade
- Configuration changes to the operating system, hardware, or database
- Database initialization parameter changes
- Schema changes, for example, adding new indexes or materialized views
- Gathering optimizer statistics
- Validating SQL tuning actions, for example, creating SQL profiles or implementing partitioning
You can run SQL Performance Analyzer on a production system or a test system that closely resembles the production system. Testing a system change on a production system will impact the system's throughput because SQL Performance Analyzer must execute the SQL statements that you are testing. Any global changes made on the system to test the performance effect may also affect other users of the system. If the system change does not impact many sessions or SQL statements, then running SQL Performance Analyzer on the production system may be acceptable. However, for systemwide changes—such as a database upgrade—using a production system is not recommended. Instead, consider running SQL Performance Analyzer on a separate test system so that you can test the effects of the system change without affecting the production system. Using a test system also ensures that other workloads running on the production system will not affect the analysis performed by SQL Performance Analyzer. Running SQL Performance Analyzer on a test system is the recommended approach and the methodology described here. If you choose to run the SQL Performance Analyzer on the production system, then substitute the production system for the test system where applicable.
Analyzing the SQL performance effect of system changes using SQL Performance Analyzer involves the following steps, as illustrated in Figure 2-1:
Figure 2-1 SQL Performance Analyzer Workflow
You can use the following APIs to manage an STS:
- Updating the attributes of SQL statements in an STS
The UPDATE_SQLSET procedure updates the attributes of SQL statements (such as PRIORITY or OTHER) in an existing STS identified by STS name and SQL ID.
- Capturing the full system workload
The CAPTURE_CURSOR_CACHE_SQLSET function enables the capture of the full system workload by repeatedly polling the shared SQL area over a specified interval. This function more efficient than repeatedly using the SELECT_CURSOR_CACHE and LOAD_SQLSET procedures to capture the shared SQL area over an extended period. This function effectively captures the entire workload, as opposed to the AWR—which only captures the workload of high-load SQL statements—or the LOAD_SQLSET procedure, which accesses the data source only once.
- Adding and removing a reference to an STS
The ADD_SQLSET_REFERENCE function adds a new reference to an existing STS to indicate its use by a client. The function returns the identifier of the added reference. The REMOVE_SQLSET_REFERENCE procedure deactivates an STS to indicate it is no longer used by the client.
https://docs.oracle.com/cd/B28359_01/server.111/b28274/sql_tune.htm#PFGRF02604
A SQL Tuning Set (STS) is a database object that includes one or more SQL statements along with their execution statistics and execution context, and could include a user priority ranking. The SQL statements can be loaded into a SQL Tuning Set from different SQL sources, such as the Automatic Workload Repository, the cursor cache, or custom SQL provided by the user. An STS includes:
- A set of SQL statements
- Associated execution context, such as user schema, application module name and action, list of bind values, and the cursor compilation environment
- Associated basic execution statistics, such as elapsed time, CPU time, buffer gets, disk reads, rows processed, cursor fetches, the number of executions, the number of complete executions, optimizer cost, and the command type
- Associated execution plans and row source statistics for each SQL statement (optional)
SQL statements can be filtered using the application module name and action, or any of the execution statistics. In addition, the SQL statements can be ranked based on any combination of execution statistics.
A SQL Tuning Set can be used as input to the SQL Tuning Advisor, which performs automatic tuning of the SQL statements based on other input parameters specified by the user. SQL Tuning Sets are transportable across databases and can be exported from one system to another, allowing for the transfer of SQL workloads between databases for remote performance diagnostics and tuning. When poorly performing SQL statements are encountered on a production system, it may not be desirable for developers to perform their investigation and tuning activities on the production system directly. This feature allows the DBA to transport the problematic SQL statements to a test system where the developers can safely analyze and tune them. To transport SQL Tuning Sets, use the DBMS_SQLTUNE package procedures.