Oracle: ¿necesita calcular estadísticas después de crear un índice o agregar columnas?

Question

Usamos una base de datos Oracle 10.2.0.5 en producción.

El optimizador está en el modo "basado en el costo".

qué necesitamos para calcular estadísticas (paquete) después DBMS_STATS:

• la creación de un nuevo índice
• añadiendo una columna
• crear una nueva tabla

?

Gracias

Answer 1

No hay una respuesta corta. Depende totalmente de tus datos y de cómo los uses. Aquí hay algunas cosas a considerar:

Como se señaló @NullUserException, las estadísticas se recopilan automáticamente, por lo general todas las noches. Eso suele ser lo suficientemente bueno; en la mayoría de los entornos (OLTP), si acaba de agregar nuevos objetos, no contendrán una gran cantidad de datos antes de que las estadísticas se recopilen automáticamente. Los planes no serán tan malos, y si los objetos son nuevos, probablemente no se usen mucho de inmediato.

• la creación de un nuevo índice - No. "Oracle Database now automatically collects statistics during index creation and rebuild".
• añadiendo una columna - Tal vez. Si la columna se usará en uniones y predicados, es probable que desee estadísticas sobre ella. Si solo se usa para almacenar y mostrar datos, en realidad no afectará ningún plan. Pero, si la nueva columna ocupa mucho espacio, puede alterar significativamente la longitud promedio de la fila, el número de bloques, el encadenamiento de filas, etc., y el optimizador debe saberlo.
• creando una nueva tabla - Probablemente. Oracle puede compensar las estadísticas faltantes a través del dynamic sampling, aunque a menudo esto no es suficiente. Especialmente si la nueva tabla tiene una gran cantidad de datos; las malas estadísticas casi siempre conducen a una subestimación de la cardinalidad, lo que dará lugar a bucles anidados cuando desee combinaciones de hash. Además, incluso si los datos de la tabla no han cambiado, es posible que deba recopilar estadísticas una vez más para habilitar los histogramas. De forma predeterminada, Oracle crea histogramas para datos sesgados, pero no habilitará esos histogramas si esas columnas no se han usado como un predicado. (Así que esto se aplica a agregar una nueva columna también). Si suelta y vuelve a crear una tabla, incluso con el mismo nombre, Oracle no mantendrá ninguna de esas columnas y utilizará los datos, y no sabrá que necesita histogramas en ciertas columnas.

Reunir las estadísticas del optimizador es mucho más difícil de lo que la mayoría de la gente piensa. En mi trabajo actual, la mayoría de nuestros problemas de rendimiento se deben a malas estadísticas. Si intentas elaborar un plan para tu sistema, deberías leer el Managing Optimizer Statistics chapter.

---

Actualización:

No hay necesidad de reunir estadísticas de los objetos vacíos; El muestreo dinámico funcionará tan rápido como la lectura de estadísticas del diccionario de datos. (En base a una prueba rápida, se procesa un gran número de consultas con y sin estadísticas.) Si desactiva el muestreo dinámico, puede haber casos extraños en los que los valores predeterminados de Oracle conducen a planes imprecisos, y sería mejor con las estadísticas de una mesa vacía

Creo que la razón por la que Oracle reúne automáticamente estadísticas para los índices en el momento de la creación es porque no cuesta mucho más. Cuando crea un índice, debe leer todos los bloques en la tabla, de modo que Oracle también pueda calcular el número de niveles, bloques, claves, etc., al mismo tiempo.

Las estadísticas de la tabla pueden ser más complicadas y pueden requerir varias pasadas de los datos. Crear un índice es relativamente simple comparado con el SQL arbitrario que se puede usar como parte de una create-table-as-select. Puede que no sea posible, o eficiente, tomar esas declaraciones SQL arbitrarias y transformarlas en una consulta que también devuelva la información necesaria para recopilar estadísticas.

Por supuesto que no le costaría nada extra reunir las estadísticas de una tabla vacía. Pero tampoco le gana nada, y sería engañoso para cualquiera que mire USER_TABLES.LAST_ANALYZED: parece que se analiza la tabla, pero no con datos significativos.