Mostrando las entradas con la etiqueta performance. Mostrar todas las entradas
Mostrando las entradas con la etiqueta performance. Mostrar todas las entradas

miércoles, 26 de febrero de 2014

Analizando sentencias con SQL Profile activo en Oracle

Si queremos analizar la performance de una sentencia SQL que tiene un SQL profile habilitado (Oracle 10g o posterior) sin afectar al resto de los usuarios del sistema, ¿cómo hacemos para ver el plan de ejecución original de la sentencia si no se usara el SQL profile?.
Asumiendo que lo vamos a hacer un tiempo después de tener el SQL profile activo y por lo tanto no está presente en la SGA (V$SQL) ni en el repositorio de AWR.

No es necesario deshabilitar ni borrar el SQL profile existente, se puede cambiar el parámetro SQLTUNE_CATEGORY a nivel de sesión para que no se use el SQL profile activo:
SQL> alter session set sqltune_category='OTRA';
Los SQL profile se crean en una categoría (por defecto 'default'), y se usan si la categoría de la sesión (este parámetro) coincide con la del SQL profile creado. Para ver el plan de ejecución original de la sentencia sin usar el SQL profile activo, alcanza con asignar un string cualquiera a la categoría de la sesión actual.

A continuación vemos un ejemplo completo de este comportamiento, incluyendo la creación de un SQL profile sobre una sentencia para forzar el uso de un índice, y luego cambiar este parámetro para ver el plan original, usando Oracle Enterprise Edition 11.2.0.2.

Uso el script coe_xfr_sql_profile.sql provisto por Oracle en el utilitario SQLT (ver nota de soporte 215187.1)  para crear un SQL profile a partir de los hints de una sentencia previamente ejecutada. Esta es la forma más simple de crear un SQL profile para ilustrar con un ejemplo reproducible el cambio de parámetro, aunque el caso queda un tanto artificial. Hay mucha documentación sobre las formas de crear SQL Profiles, pero no es el foco de este post.
De todas formas, este procedimiento es muy útil para troubleshooting de performance, por lo que es interesante tenerlo presente, aunque en este caso solo sea para ilustrar.

Primero creo una tabla, un índice, y ejecuto una consulta que lo usa:
oracle@oraculo:~> sqlplus / as sysdba SQL*Plus: Release 11.2.0.2.0 Production on Mié Feb 26 14:55:15 2014 Copyright (c) 1982, 2010, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production With the Partitioning, Real Application Clusters and Automatic Storage Management options 14:56:08 SQL> alter session set current_schema=PRU; Session altered. 14:56:46 SQL> create table pp(n number, c varchar2(100)); Table created. 14:57:03 SQL> insert into pp select rownum, object_id from dba_objects where rownum < 100; 99 rows created. 14:57:33 SQL> create index pp_idx on pp(n); Index created. 14:57:52 SQL> select * from pp where n=1; N C ---------- --------------------------------------------------------------------------------- 1 28 14:59:17 SQL> select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------- SQL_ID 86svufrd72xqg, child number 0 ------------------------------------- select * from pp where n=1 Plan hash value: 2830885032 -------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 1 (100)| | | 1 | TABLE ACCESS BY INDEX ROWID| PP | 1 | 65 | 1 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | PP_IDX | 1 | | 1 (0)| 00:00:01 | -------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("N"=1) Note ----- - dynamic sampling used for this statement (level=2) 23 rows selected.
Ya tenemos nuestra tabla PP con un índice sobre la columna N, y la consulta que lo usa.
Ahora creamos otra consulta que hace un full scan sobre la tabla, y es a la que luego vamos a asignarle un SQL profile para que use el índice:
14:59:22 SQL> select /*+ full(pp)*/ * from pp where n=1; N C ---------- ----------------------------------------------------------------------------------- 1 28 14:59:37 SQL> select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------- SQL_ID btpjqgv0u0stb, child number 0 ------------------------------------- select /*+ full(pp)*/ * from pp where n=1 Plan hash value: 2338859486 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 3 (100)| | |* 1 | TABLE ACCESS FULL| PP | 1 | 65 | 3 (0)| 00:00:01 | -------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("N"=1) Note ----- - dynamic sampling used for this statement (level=2) 22 rows selected. 15:02:10 SQL> col sql_text for a45 15:02:10 SQL> select sql_id, plan_hash_value, executions, sql_text from v$sql where sql_id in ('btpjqgv0u0stb','86svufrd72xqg'); SQL_ID PLAN_HASH_VALUE EXECUTIONS SQL_TEXT ------------- --------------- ---------- --------------------------------------------- btpjqgv0u0stb 2338859486 1 select /*+ full(pp)*/ * from pp where n=1 86svufrd72xqg 2830885032 1 select * from pp where n=1
Vemos los SQL_ID de ambas consultas, junto con el plan de ejecución usado.
Ahora usamos el script coe_xfr_sql_profile.sql para crear un SQL profile a la consulta lenta (btpjqgv0u0stb) y que use el plan de la otra (2830885032). Estos son los parámetros que se le deben ingresar al script:
SQL> sta coe_xfr_sql_profile.sql Parameter 1: SQL_ID (required) Enter value for 1: btpjqgv0u0stb PLAN_HASH_VALUE AVG_ET_SECS --------------- ----------- 2338859486 ,004 Parameter 2: PLAN_HASH_VALUE (required) Enter value for 2: 2830885032 Values passed to coe_xfr_sql_profile: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SQL_ID : "btpjqgv0u0stb" PLAN_HASH_VALUE: "2830885032" SQL>BEGIN 2 IF :sql_text IS NULL THEN 3 RAISE_APPLICATION_ERROR(-20100, 'SQL_TEXT for SQL_ID &&sql_id. was not found in memory (gv$sqltext_with_newlines) or AWR (dba_hist_sqltext).'); 4 END IF; 5 END; 6 / SQL>SET TERM OFF; SQL>BEGIN 2 IF :other_xml IS NULL THEN 3 RAISE_APPLICATION_ERROR(-20101, 'PLAN for SQL_ID &&sql_id. and PHV &&plan_hash_value. was not found in memory (gv$sql_plan) or AWR (dba_hist_sql_plan).'); 4 END IF; 5 END; 6 / SQL>SET TERM OFF; Execute coe_xfr_sql_profile_btpjqgv0u0stb_2830885032.sql on TARGET system in order to create a custom SQL Profile with plan 2830885032 linked to adjusted sql_text. COE_XFR_SQL_PROFILE completed.
Vemos que se ejecutó de forma exitosa, así que nos generó un script que crea el SQL profile.
Lo ejecutamos:
SQL> sta coe_xfr_sql_profile_btpjqgv0u0stb_2830885032.sql SQL> REM SQL> REM $Header: 215187.1 coe_xfr_sql_profile_btpjqgv0u0stb_2830885032.sql 11.4.4.4 2014/02/26 carlos.sierra $ SQL> REM SQL> REM Copyright (c) 2000-2012, Oracle Corporation. All rights reserved. SQL> REM SQL> REM AUTHOR SQL> REM carlos.sierra@oracle.com SQL> REM SQL> REM SCRIPT SQL> REM coe_xfr_sql_profile_btpjqgv0u0stb_2830885032.sql SQL> REM SQL> REM DESCRIPTION SQL> REM This script is generated by coe_xfr_sql_profile.sql SQL> REM It contains the SQL*Plus commands to create a custom SQL> REM SQL Profile for SQL_ID btpjqgv0u0stb based on plan hash SQL> REM value 2830885032. SQL> REM The custom SQL Profile to be created by this script SQL> REM will affect plans for SQL commands with signature SQL> REM matching the one for SQL Text below. SQL> REM Review SQL Text and adjust accordingly. SQL> REM SQL> REM PARAMETERS SQL> REM None. SQL> REM SQL> REM EXAMPLE SQL> REM SQL> START coe_xfr_sql_profile_btpjqgv0u0stb_2830885032.sql; SQL> REM SQL> REM NOTES SQL> REM 1. Should be run as SYSTEM or SYSDBA. SQL> REM 2. User must have CREATE ANY SQL PROFILE privilege. SQL> REM 3. SOURCE and TARGET systems can be the same or similar. SQL> REM 4. To drop this custom SQL Profile after it has been created: SQL> REM EXEC DBMS_SQLTUNE.DROP_SQL_PROFILE('coe_btpjqgv0u0stb_2830885032'); SQL> REM 5. Be aware that using DBMS_SQLTUNE requires a license SQL> REM for the Oracle Tuning Pack. SQL> REM 6. If you modified a SQL putting Hints in order to produce a desired SQL> REM Plan, you can remove the artifical Hints from SQL Text pieces below. SQL> REM By doing so you can create a custom SQL Profile for the original SQL> REM SQL but with the Plan captured from the modified SQL (with Hints). SQL> REM SQL> WHENEVER SQLERROR EXIT SQL.SQLCODE; SQL> REM SQL> VAR signature NUMBER; SQL> VAR signaturef NUMBER; SQL> REM SQL> DECLARE 2 sql_txt CLOB; 3 h SYS.SQLPROF_ATTR; 4 PROCEDURE wa (p_line IN VARCHAR2) IS 5 BEGIN 6 DBMS_LOB.WRITEAPPEND(sql_txt, LENGTH(p_line), p_line); 7 END wa; 8 BEGIN 9 DBMS_LOB.CREATETEMPORARY(sql_txt, TRUE); 10 DBMS_LOB.OPEN(sql_txt, DBMS_LOB.LOB_READWRITE); 11 -- SQL Text pieces below do not have to be of same length. 12 -- So if you edit SQL Text (i.e. removing temporary Hints), 13 -- there is no need to edit or re-align unmodified pieces. 14 wa(q'[select /*+ full(pp)*/ * from pp where n=1]'); 15 DBMS_LOB.CLOSE(sql_txt); 16 h := SYS.SQLPROF_ATTR( 17 q'[BEGIN_OUTLINE_DATA]', 18 q'[IGNORE_OPTIM_EMBEDDED_HINTS]', 19 q'[OPTIMIZER_FEATURES_ENABLE('11.2.0.2')]', 20 q'[DB_VERSION('11.2.0.2')]', 21 q'[OPT_PARAM('optimizer_index_cost_adj' 1)]', 22 q'[OPT_PARAM('optimizer_index_caching' 100)]', 23 q'[ALL_ROWS]', 24 q'[OUTLINE_LEAF(@"SEL$1")]', 25 q'[INDEX_RS_ASC(@"SEL$1" "PP"@"SEL$1" ("PP"."N"))]', 26 q'[END_OUTLINE_DATA]'); 27 :signature := DBMS_SQLTUNE.SQLTEXT_TO_SIGNATURE(sql_txt); 28 :signaturef := DBMS_SQLTUNE.SQLTEXT_TO_SIGNATURE(sql_txt, TRUE); 29 DBMS_SQLTUNE.IMPORT_SQL_PROFILE ( 30 sql_text => sql_txt, 31 profile => h, 32 name => 'coe_btpjqgv0u0stb_2830885032', 33 description => 'coe btpjqgv0u0stb 2830885032 '||:signature||' '||:signaturef||'', 34 category => 'DEFAULT', 35 validate => TRUE, 36 replace => TRUE, 37 force_match => FALSE /* TRUE:FORCE (match even when different literals in SQL). FALSE:EXACT (similar to CURSOR_SHARING) */ ); 38 DBMS_LOB.FREETEMPORARY(sql_txt); 39 END; 40 / PL/SQL procedure successfully completed. SQL> WHENEVER SQLERROR CONTINUE SQL> SET ECHO OFF; SIGNATURE --------------------- 613978514929328923 SIGNATUREF --------------------- 16370312570377067161 ... manual custom SQL Profile has been created COE_XFR_SQL_PROFILE_btpjqgv0u0stb_2830885032 completed
El SQL profile se creó, así que validamos si la consulta que antes hacía un acceso full sobre la tabla ahora toma el índice:
15:14:08 SQL> select /*+ full(pp)*/ * from pp where n=1; N C ---------- --------------------------------------------------------------------- 1 28 15:14:09 SQL> select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------------------- SQL_ID btpjqgv0u0stb, child number 1 ------------------------------------- select /*+ full(pp)*/ * from pp where n=1 Plan hash value: 2830885032 -------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 1 (100)| | | 1 | TABLE ACCESS BY INDEX ROWID| PP | 1 | 65 | 1 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | PP_IDX | 1 | | 1 (0)| 00:00:01 | -------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("N"=1) Note ----- - SQL profile coe_btpjqgv0u0stb_2830885032 used for this statement 23 rows selected. 15:14:50 SQL> select category, status 15:15:04 2 from dba_sql_profiles 15:15:09 3 where name='coe_btpjqgv0u0stb_2830885032'; CATEGORY STATUS ------------------------------ -------- DEFAULT ENABLED
Perfecto, el SQL profile está haciendo lo que esperamos y está activo.
Recién ahora estamos en la situación que me interesaba mostrar: ¿cómo hacemos para ver el plan de ejecución original de esta sentencia?. Uso el string OTRA, pero podría ser cualquier string distinto de DEFAULT:
15:15:50 SQL> alter session set sqltune_category='OTRA'; Session altered. 15:16:02 SQL> select /*+ full(pp)*/ * from pp where n=1; N C ---------- --------------------------------------------------------------------------------- 1 28 15:16:12 SQL> select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------- SQL_ID btpjqgv0u0stb, child number 2 ------------------------------------- select /*+ full(pp)*/ * from pp where n=1 Plan hash value: 2338859486 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 3 (100)| | |* 1 | TABLE ACCESS FULL| PP | 1 | 65 | 3 (0)| 00:00:01 | -------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("N"=1) Note ----- - dynamic sampling used for this statement (level=2) 22 rows selected.
Vemos que al ejecutar la sentencia se vuelve a comportar como antes, sin usar el SQL profile.

Espero les sea útil.

martes, 31 de diciembre de 2013

Particiones, datos y optimización

Tenemos una tabla particionada y una consulta que anda lento porque la condición de where no incluye la columna de partición y usa columnas que no están indexadas.

¿Podemos hacer algo más que dar la recomendación obvia de crear un nuevo índice global?

Seguro!, por lo menos hacer estas dos revisiones rápidas.

Lo primero es ver si se usa la columna de particionamento en la condición del where.
Si se usa, la consulta solo leerá datos de esa partición (el optimizador aplica partition pruning), por lo tanto un nuevo índice podría ser útil siempre que las particiones tengan un volumen de datos que lo justifique (muchas particiones con pocos registros no se van a beneficiar de un nuevo índice).

Si no se usa la columna de particionamento en el where, todavía queda algo más a analizar: ¿el criterio de búsqueda tiene alguna correlación con el criterio de particionamiento? Esto es una relación funcional sobre los datos y que no podemos inferir a partir del texto de la consulta.

Podemos analizar los datos buscando este vínculo, y si se llega a confirmar podríamos hacer que la consulta sea más eficiente (recorra menos registros) modificandola, agregando una simple condición columna_partición=valor.

¿Cómo podemos hacer este análisis? Con la ayuda de la función DBMS_MVIEW.PMARKER, que dado un registro (rowid) retorna el nombre de la partición donde está almacenado.

Todo esto se puede ver mejor con un ejemplo. Usé Oracle 11.2.0.2 Enterprise Edition


Tenemos la tabla bigtbl_part particionada por rangos de la columna tipo, y un índice global:

12:40:43 PRU@ent11g> create table bigtbl_part (id, estado, tipo, clase, dato)
partition by range(tipo) (
     partition p0 values less than (1),
     partition p1 values less than (2),
     partition p2 values less than (3),
     partition p3 values less than (4),
     partition p4 values less than (5)
) as
select  rownum               id,
        floor(dbms_random.value(1,20)) estado,
        mod(rownum,5)        tipo,
        mod(rownum,10)       clase,
        'relleno'            dato
from  all_objects, all_objects

Table created.

Elapsed: 00:00:53.14

12:41:37 PRU@ent11g> create index idx1 on bigtbl_part(id) local;

Index created.

Elapsed: 00:00:15.90

12:42:20 PRU@ent11g> execute dbms_stats.gather_table_stats(user,'bigtbl_part')

PL/SQL procedure successfully completed.

Elapsed: 00:00:02.99



Vemos cómo quedaron generados los datos. Nos vamos a enfocar en las clases y tipos:

12:42:40 PRU@ent11g>select count(*), clase from bigtbl_part group by clase order by clase;

  COUNT(*)      CLASE
---------- ----------
    100000          0
    100000          1
    100000          2
    100000          3
    100000          4
    100000          5
    100000          6
    100000          7
    100000          8
    100000          9

10 rows selected.


Los valores distintos de CLASE por cada partición (columna TIPO):

12:46:29 PRU@ent11g> select count(distinct clase), tipo
from bigtbl_part
group by tipo
order by tipo;

COUNT(DISTINCTCLASE)       TIPO
-------------------- ----------
                   2          0
                   2          1
                   2          2
                   2          3
                   2          4


Y cómo quedaron distribuidos los datos en cada partición:

12:47:40 PRU@ent11g> col partition_name for a10
12:47:41 PRU@ent11g> select partition_name, num_rows, high_value
from user_TAB_PARTITIONS
where table_name='BIGTBL_PART';

PARTITION_   NUM_ROWS HIGH_VALUE
---------- ---------- --------------------------------------------------------------------------------
P0             200000 1
P1             200000 2
P2             200000 3
P3             200000 4
P4             200000 5


Esta es la consulta que nos interesa mejorar:

  SELECT count(*)
  FROM bigtbl_part
  WHERE clase = :clase and estado = :estado;


Para fijar ideas usamos una combinación de valores cualquiera: buscamos registros de clase 3 y estado 15:

12:49:52 PRU@ent11g> var clase number;
12:49:52 PRU@ent11g> var estado number;

12:49:52 PRU@ent11g> exec :clase := 3;

PL/SQL procedure successfully completed.

12:49:52 PRU@ent11g> exec :estado := 15;

PL/SQL procedure successfully completed.

12:49:53 PRU@ent11g> set autotrace on explain

SELECT count(*)
FROM bigtbl_part
WHERE clase = :clase and estado = :estado;

  COUNT(*)
----------
      5265

Execution Plan
----------------------------------------------------------
Plan hash value: 1165574620

----------------------------------------------------------------------------------------------------
| Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |             |     1 |     6 |  1047   (2)| 00:00:13 |       |       |
|   1 |  SORT AGGREGATE      |             |     1 |     6 |            |          |       |       |
|   2 |   PARTITION RANGE ALL|             |  5263 | 31578 |  1047   (2)| 00:00:13 |     1 |     5 |
|*  3 |    TABLE ACCESS FULL | BIGTBL_PART |  5263 | 31578 |  1047   (2)| 00:00:13 |     1 |     5 |
----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("ESTADO"=TO_NUMBER(:ESTADO) AND "CLASE"=TO_NUMBER(:CLASE))


Vemos que para resolverla el optimizador tuvo que recorrer todas las particiones de la tabla, y cada una sin usar índice.

Podemos tener facilmente una idea de la cantidad máxima de registros que se necesitan analizar para responder esta consulta (peor caso):

12:53:04 PRU@ent11g>
select count(*), min(count(*)), max(count(*))
from BIGTBL_part
group by clase, estado;

  COUNT(*) MIN(COUNT(*)) MAX(COUNT(*))
---------- ------------- -------------
       190          5071          5500


Pero si queremos además saber en qué particiones están estos datos, no alcanza con ver la cantidad de registros que tiene cada partición (columna num_rows de DBA_TAB_PARTITIONS), ya que no estamos buscando dentro de una sola partición.
Tenemos que agregar a la consulta original el uso de la función dbms_mview.pmarker, y así ver si hay afinidad de los datos buscados (de la condición de agrupación) con las particiones.

Esta es una primera versión simple de la consulta, donde podemos ver los distintos valores de CLASES almacenados en cada partición:

12:54:12 PRU@ent11g>
select count(*)                      registros
      ,dbms_mview.pmarker(rowid)     data_object_id
      ,count(distinct clase)         clase_x_tipo
FROM bigtbl_part
group by dbms_mview.pmarker(rowid);

 REGISTROS DATA_OBJECT_ID CLASE_X_TIPO
---------- -------------- ------------
    200000          75537            2
    200000          75539            2
    200000          75540            2
    200000          75538            2
    200000          75536            2

Elapsed: 00:00:05.93
 


Agregando la condición original, podemos ver en qué particiones están los datos obtenidos:

12:56:51 PRU@ent11g>
select count(*)                      registros
      ,dbms_mview.pmarker(rowid)     data_object_id
FROM bigtbl_part
WHERE clase = :clase and estado = :estado
12:56:51   5  group by dbms_mview.pmarker(rowid);

 REGISTROS DATA_OBJECT_ID
---------- --------------
      5265          75539


Los 5265 registros que retorna la consulta se obtienen de la partición 75539.
Podemos ver el nombre de la partición consultando USER_OBJECTS:

12:58:17 PRU@ent11g>
select subobject_name
from user_objects
WHERE data_object_id=75539;

SUBOBJECT_NAME
------------------------------------------------------------------------------------------
P3


En resumen, aunque los datos se obtienen todos de la misma partición, la consulta recorre todas las particiones porque no conoce la relación entre los datos (clase y tipo).

En este ejemplo los datos se generaron de esta forma para ilustrar el caso donde se puede mejorar la consulta con la ayuda de los programadores de la aplicación, quienes pueden agregar una condición más al where sobre la columna TIPO con el valor correspondiente (ya que la relación entre los valores de estas columnas pueden ser conocidos), y así mejorar la peformance de la misma.
La consulta modificada quedaría así:

12:59:28 PRU@ent11g>
SELECT count(*)
FROM bigtbl_part
WHERE clase = :clase and estado = :estado and tipo = :tipo;

Plan hash value: 4104149755

-------------------------------------------------------------------------------------------------------
| Id  | Operation               | Name        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |             |     1 |     9 |   211   (2)| 00:00:03 |       |       |
|   1 |  SORT AGGREGATE         |             |     1 |     9 |            |          |       |       |
|   2 |   PARTITION RANGE SINGLE|             |  1053 |  9477 |   211   (2)| 00:00:03 |   KEY |   KEY |
|*  3 |    TABLE ACCESS FULL    | BIGTBL_PART |  1053 |  9477 |   211   (2)| 00:00:03 |   KEY |   KEY |
-------------------------------------------------------------------------------------------------------

Si bien se mantiene el acceso sin índice, ahora es sobre la partición y no sobre todas las particiones.
Esto todavía puede mejorarse incluyendo un índice local por clase y estado si el volumen de las particiones lo amerita.
Si no se hubiera podido modificar la consulta, la recomendación clásica habría sido un índice global por clase y estado.

Otro tema relacionado a mejorar la performance de consultas sobre tablas particionadas, es la utilidad de tener índices que incluyan la columna de partición (conocidos como prefixed local index). Una buena discusión sobre el tema se puede encontrar en este thread de los foros de OTN

Espero les sea útil.

Un saludo y feliz comienzo de año!