sql >> Base de Datos >  >> RDS >> Oracle

¿Reunir estadísticas en un índice o soltar crear?

La diferencia es que la recopilación de estadísticas actualiza los metadatos sobre el índice actual, mientras que eliminar y volver a crear el índice es, er, eliminar y volver a crear el índice.

Quizás sea fácil entender la diferencia con un ejemplo resuelto. Así que vamos a crear una tabla y un índice:

SQL> create table t23 
  2  as select object_id as id, object_name as name from user_objects 
  3  /

Table created.

SQL> create index i23 on t23(id)
  2  /

Index created.

SQL> select o.object_id, i.last_analyzed, i.distinct_keys
  2  from user_objects o
  3       join user_indexes i
  4            on (i.index_name = o.object_name)
  5  where o.object_type = 'INDEX'
  6  and i.index_name = 'I23'
  7  /

 OBJECT_ID CREATED              LAST_ANALYZED        DISTINCT_KEYS
---------- -------------------- -------------------- -------------
    116353 23-NOV-2013 00:15:39 23-NOV-2013 00:15:39           167

1 row selected.

SQL> 

Desde 11g, Oracle recopila estadísticas automáticamente cuando creamos un índice. Entonces, la creación del índice y el último análisis muestran la misma fecha y hora. En versiones anteriores, teníamos que recopilar estadísticas explícitamente después de crear el índice. Más información .

A continuación, agregaremos algunos datos y actualizaremos las estadísticas:

SQL> insert into t23 values (9999, 'TEST1')
  2  /

1 row created.

SQL> insert into t23 values (-8888, 'TEST 2')
  2  /

1 row created.

SQL> exec dbms_stats.gather_index_stats(user, 'I23') 

PL/SQL procedure successfully completed.

SQL> select o.object_id, i.last_analyzed, i.distinct_keys
  2  from user_objects o
  3       join user_indexes i
  4            on (i.index_name = o.object_name)
  5  where o.object_type = 'INDEX'
  6  and i.index_name = 'I23'
  7  /

 OBJECT_ID CREATED              LAST_ANALYZED        DISTINCT_KEYS
---------- -------------------- -------------------- -------------
    116353 23-NOV-2013 00:15:39 23-NOV-2013 00:26:28           169

1 row selected.

SQL> 

Ahora los metadatos relacionados con las estadísticas han cambiado, pero el índice es el mismo objeto de la base de datos. Mientras que si soltamos y volvemos a crear el índice, obtenemos un nuevo objeto de base de datos:

SQL> drop index i23
  2  /

Index dropped.

SQL> create index i23 on t23(id) 
  2  /

Index created.

SQL> select o.object_id, i.last_analyzed, i.distinct_keys
  2  from user_objects o
  3       join user_indexes i
  4            on (i.index_name = o.object_name)
  5  where o.object_type = 'INDEX'
  6  and i.index_name = 'I23'
  7  /

 OBJECT_ID CREATED              LAST_ANALYZED        DISTINCT_KEYS
---------- -------------------- -------------------- -------------
    116354 23-NOV-2013 00:27:50 23-NOV-2013 00:27:50           169

1 row selected.

SQL> 

En las operaciones normales, casi nunca necesitamos eliminar y volver a crear un índice. Es una técnica que en algún momento es apropiada cuando se cargan cantidades muy grandes de datos y en casos muy raros de corrupción de índice. Las interwebs aún arrojan sitios que recomiendan la reconstrucción regular de índices por razones de rendimiento (supuestamente "reequilibra" los índices sesgados), pero estos sitios no producen los puntos de referencia para demostrar los beneficios a largo plazo, y ciertamente nunca incluyen el tiempo y Ciclos de CPU desperdiciados por el ejercicio de reconstrucción.

Reconstruir un índice requiere más trabajo que actualizar las estadísticas. Obviamente cierto, porque la reconstrucción incluye recopilar estadísticas como una subtarea. La pregunta es si es más eficiente realizar DML masivo en una tabla con sus índices en lugar de descartar los índices y volver a crearlos después. Puede ser más rápido cargar datos en una tabla sin índices y volver a crearlos después.

Aquí no hay una regla estricta:depende de cuántos índices tenga, la proporción de las filas afectadas en relación con el tamaño total de la tabla, si necesita los índices para hacer cumplir las restricciones de integridad relacional, etc. También hay una gran diferencia entre las operaciones:es posible que desee eliminar índices para inserciones masivas pero conservarlos para actualizaciones, según los índices que necesite para su cláusula WHERE y si la actualización afecta las columnas indexadas.

En resumen, debe comparar su propio escenario específico. Esta suele ser la respuesta cuando se trata de preguntas de rendimiento.