How to create more copies of Voting Disks in Oracle 11g RAC

You cannot simply add more copies of voting disks to increase redundancy because the number of voting disks is managed by Oracle ASM and determined by the redundancy of the disk group.

To increase the number of voting disks, you need to move them to a disk group with higher redundancy.

So, create the new disk group or identify one that meets your requirements and use the:

crsctl replace votedisk command to move your voting disks to the new disk group.

SQL performance analyzer in Oracle 11g

SQL Performance Analyzer
SQL Performance Analyzer

SQL performance analyzer performs a similar job to the SQL Tuning Advisor with one major difference, SQL performance analyser allows you to compare the performance of SQL statements before and after a change, allowing you to predict the impact of changes to the system on SQL performance as well as pre tuning your database before making changes.

So, The SQL Tuning Advisor is designed to help tune SQL in the system as it currently exists where as the SQL Performance Analyzer is designed to help determine the impact of system changes to SQL performance.

It allows you to compare a wide range of changes from operating system changes to database upgrades and down to the level of index changes.

The recommended approach would be to replecate your productoin system and run your tests on that system.

The basic procedure for using SQL Performance Analyzer is as follows:

  1. Capture SQL workload – Load the required SQL into a tuning set.
  2.  Set up test system – So that you do not need to make changes to the live system.
  3. Move SQL tuning set to new system.
  4. Create SQL Performance Analyzer task – by associating your SQL tuning set with a SQL performance analyzer task.
  5. Build trial by executing SQL – Get a baseline to compare the post change performance to.
  6. Make System Change
  7. Run Post change trial
  8. Compare changes
  9. Tune as necessary – The report generated includes guidance and suggestions on tuning the SQL for the new changes.


A SQL tuning set is a database object that includes one or more SQL statements , along with their execution statistics and execution context.

SQL statements can be loaded into a SQL tuning set from many different sources. It’s possible to use the cursor cache, Automatic Workload Repository (AWR), or existing SQL tuning sets.

Using a SQL tuning set enables you to:

  • Store the SQL text and any necessary auxiliary information in a single, persistent database object
  • Populate, update, delete, and select captured SQL statements in the SQL tuning set
  • Load and merge content from various data sources, such as the Automatic Workload Repository (AWR) or the cursor cache
  • Export the SQL tuning set from the system where the SQL workload is captured and import it into another system
  • Reuse the SQL workload as an input source for other advisers, such as the SQL Tuning Adviser and the SQL Access Adviser


Useful SQL Performance Adviser views:




A great article with examples can be found on Oracle Base















CREATE_SQLSET – creates tuning set object in DB

LOAD_SQLSET – populates tuning set

CREATE_SGTAB_SQLSET – creates staging table

PACK_SGTAB_SQLSET – copy tuning set from SYS schema to staging table

UNPACK_SGTAB_SQLSET – copy tuning set from staging table to sql tuning set schema





DBMS_SQLPA package:














Automatic SQL Tuning in Oracle 11g


The Automatic Database Diagnostic Monitor in Oracle 11g
The ADDM in Oracle 11g

The automated tuning process in Oracle 11g is implemented by a number of functions in the Oracle database:

Automatic Database Diagnostic Monitor (ADDM)

Takes input from the AWR reports which it analyses in order to identify potential bottlenecks. If the statistics level parameter is set to TYPICAL or ALL then the ADDM is ran every time an AWR snapshot is taken.

Reports can be vierwed through Enterprise manager but can also be generated with the addmrpt.sql script located at $ORACLE_HOME/rdbms/admin/addmrpt.sql

SQL Tuning Advisor

The optimizer can run in 2 modes, Normal and Tuning. In Normal mode, the optimizer must produce a plan in a very short timeframe and so has to accept the information that it has is up to date and accurate. The alternative is Tuning mode where the optimizer is given more time so that it can perform analysis and gather more information in rder to produce a more accurate and efficient plan.

The ADDM identifies SQL that could be improved and passes it to the SQL Tuning Advisor. This invokes the Automatic Tuning Optimizer and evaluates possibilities for improvement. The automatic Tuning Advisor performs a range of different types of analysis including statistics analysis (gathering stats), SQL profiling (creating new SQL profiles), Access path analysis (adding aindexes to allow faster access to data) and SQL structure analysis (actually rewriting or rather suggesting options for rewriting SQl statements).

From Version 11g, the Automatic SQL Tuning Advisor is ran (by default) during the nightly maintanance window. While it does not automatically implement suggestoins, it can be set up to do so.

You can use the ‘ENABLE‘ or ‘DISABLE‘ procedures of the DBMS_AUTO_TASK_ADMIN package to let the automatic tuning job run or not. Setting the STATISTICS_LEVEL to BASIC will also disable it because that stops stats gathering be the AWR.

— Enable



client_name => ‘sql tuning advisor’,

operation => NULL,

window_name => NULL);



When it does run, the procedure is as folows:

  1. Candidate SQL queries are identifed from the AWR. Only statements with execution plan that has a high potential for improvement and a high impact on the system are considered.
  2. Each statementnd is invidually tuned by calling the SQL Tuning Advisor. The only recommendation that can be automatically implemented are SQL profiles.
  3. SQL profiles are implemented when:
    • There is at least 3 fold improvement.
    • ACCEPT_SQL_PROFILES task parameter is TRUE

These profiles will have a type of AUTO in DBA_SQL_PROFILES

How to Setup and Configure Automatic SQL Tuning

Automatic SQL tuning task can be configured with the DBMS_SQLTUNE package. Only SYS can do this.

You can turn on or off the acceptance of automatically generated SQL profiles with the SET_TUNING_TASK_PARAMETER procedure.



parameter = > ‘ACCEPT_SQL_PROFILES’,

value = > ‘TRUE’);


 Additional parameters:

  • ACCEPT_SQL_PROFILE – automatically accept profiles?
  • MAX_SQL_PROFILES_PER_EXEC – maximum number of profiles to evaluate per execution (default 20).
  • MAX_AUTO_SQL_PROFILES – total auto profiles allowed on the system (default 1000).
  • EXECUTION_DAYS_TO_EXPIRE – default 30 days – how long to save task history

Viewing Automatic SQL Tuning Reports

You can view the Automatic SQL Tuning Reports through Enterprise Manager as well as via the DBMS_SQLTUNE package – DBMS_SQLTUNE.REPORT_AUTO_TUNING_TASK



:l_report := DBMS_SQLTUNE.report_auto_tuning_task(

begin_exec => NULL,

end_exec => NULL,

type => DBMS_SQLTUNE.type_text, — ‘TEXT’

level => DBMS_SQLTUNE.level_typical, — ‘TYPICAL’

section => DBMS_SQLTUNE.section_all, — ‘ALL’

object_id => NULL,

result_limit => NULL);




SET LONG 1000000

PRINT :l_report

There are several useful views that can be referred to and are worth exploring to gain more information on Automatic SQL Tuning.

  • DBA_ADVISOR_ACTIONS – Actions associated with recommendations
  • DBA_ADVISOR_EXECUTIONS – Metadata for task executions


Where to find Oracle clusterware log files.

To make administration and problem diagnosis easier in Oracle Clusterware, there is a single consolidated directory structure for the main clusterware log files.


This is found under $GRID_HOME/log/[hostname]/


The CRSD logfile – crsd.log is stored in the /crsd/ directory and is archived every 10mb.


The CSS logfiles – cssd.log is stored in the /cssd/ directory. This is archived every 20mb.


EVM logs are under /evmd/


SRVM (srvctl) is found along with the OCR logfiles under /client/ and also under $ORACLE_HOME/log/[hostname]/client/


How to enable Clusterware Resource Debugging in Oracle RAC

In order to enable clusterware resource debugging you need to set the resource attribute USR_ORA_DEBUG to 1 for the resource that you wish to debug.

$ crsctl set log res “”

When you are finished you issue almost the same command to disable the clusterware debugging (set USR_ORA_DEBUG to 0):

$ crsctl set log res “”

You can also use an initialization file to configure the debugging. This file is located at $GRID_HOME/log/hostname/admin/ and it is names after the process that you are debugging (process_name.ini).