database - respaldos - ¿Con qué frecuencia deben ejecutarse las estadísticas de la base de datos Oracle?

respaldo y recuperación de base de datos oracle con rman

Question

En su experiencia, ¿con qué frecuencia deben ejecutarse las estadísticas de la base de datos Oracle? Nuestro equipo de desarrolladores descubrió recientemente que las estadísticas no se habían ejecutado en nuestra caja de producción en más de 2 meses y medio. Eso me parece mucho tiempo, pero no soy un DBA.

Answer 1

¿Qué versión de Oracle estás usando? Compruebe esta página que se refiere a Oracle 10:

http://www.acs.ilstu.edu/docs/Oracle/server.101/b10752/stats.htm

Dice:

El enfoque recomendado para recopilar estadísticas es permitir que Oracle reúna automáticamente las estadísticas. Oracle recopila estadísticas sobre todos los objetos de la base de datos automáticamente y mantiene esas estadísticas en un trabajo de mantenimiento programado regularmente.

Answer 2

Asegúrese de equilibrar el riesgo de que las nuevas estadísticas provoquen cambios no deseados en los planes de consulta frente al riesgo de que las estadísticas obsoletas puedan provocar que los planes de consulta cambien.

Imagine que tiene una base de datos de errores con una tabla ISSUE y una columna CREATE_DATE donde los valores en la columna aumentan más o menos monótonamente. Ahora, suponga que hay un histograma en esta columna que le dice a Oracle que los valores de esta columna se distribuyen de manera uniforme entre el 1 de enero de 2008 y el 17 de septiembre de 2008. Esto permite que el optimizador calcule razonablemente el número de filas que ser devuelto si estaba buscando todos los problemas creados la semana pasada (es decir, del 7 al 13 de septiembre). Sin embargo, si la aplicación continúa utilizándose y las estadísticas nunca se actualizan, este histograma será cada vez menos preciso. Por lo tanto, el optimizador esperará que las consultas para "problemas creados la semana pasada" sean cada vez menos precisas con el tiempo y eventualmente puede hacer que Oracle cambie el plan de consulta de forma negativa.

Answer 3

Cada vez que los datos cambian "significativamente".

Si una tabla va de 1 fila a 200 filas, eso es un cambio significativo. Cuando una tabla va de 100,000 filas a 150,000 filas, no es un cambio terriblemente significativo. Cuando una tabla va de 1000 filas, todas con valores idénticos en la columna de consulta común X a 1000 filas con valores casi únicos en la columna X, eso es un cambio significativo.

Las estadísticas almacenan información sobre recuentos de elementos y frecuencias relativas, cosas que le permitirán "adivinar" cuántas filas coincidirán con un criterio determinado. Cuando adivina mal, el optimizador puede elegir un plan de consulta muy poco óptimo.

Answer 4

Cuando gestionaba un gran sistema de planificación multiusuario respaldado por Oracle, nuestro DBA tenía un trabajo semanal que recopilaba estadísticas. Además, cuando lanzamos un cambio significativo que podría afectar o ser afectado por las estadísticas, obligaríamos al trabajo a quedarse sin ciclo para que las cosas se pongan al día.

Answer 5

En mi último trabajo, realizamos estadísticas una vez a la semana. Si mal no recuerdo, los programamos un jueves por la noche y el viernes los DBA fueron muy cuidadosos de monitorear las consultas de más larga duración para cualquier cosa inesperada. (El viernes fue elegido porque a menudo era justo después del lanzamiento del código, y tendía a ser un día de poco tráfico). Cuando veían una mala consulta, encontraban un mejor plan de consulta y guardaban ese para que no cambiara inesperadamente. . (Oracle tiene herramientas para hacer esto automáticamente, le dice a la consulta que optimice y lo hace).

Muchas organizaciones evitan la ejecución de estadísticas por temor a que surjan inesperadamente planes de mala consulta. Pero esto generalmente significa que sus planes de consulta empeoran y empeoran con el tiempo. Y cuando sí ejecutan estadísticas, se encuentran con una serie de problemas. La lucha resultante para solucionar esos problemas confirma sus temores sobre los peligros de la ejecución de estadísticas. Pero si ejecutaran estadísticas regularmente, utilizaran las herramientas de supervisión como se supone que debían hacerlo, y corrigieran los problemas a medida que aparecían, entonces tendrían menos dolores de cabeza y no los encontrarían todos a la vez.

Answer 6

En el caso de un sistema tipo depósito de datos, puede considerar no recopilar ninguna estadística y confiar en el muestreo dinámico (configuración optimizer_dynamic_sampling al nivel 2 o superior).

Answer 7

Con una versión 10g y superior de Oracle, el optimizador necesita estadísticas actualizadas sobre tablas e índices para tomar una decisión "buena" sobre el plan de ejecución. La frecuencia con la que recopile estadísticas es una llamada complicada. Depende de su aplicación, esquema, velocidad de datos y práctica comercial. Algunas aplicaciones de terceros que están escritas para ser compatibles con versiones anteriores de Oracle no funcionan bien con el nuevo optimizador. Esas aplicaciones requieren que las tablas no tengan estadísticas para que el db recurra al plan de ejecución de la base de reglas. Pero en promedio, Oracle recomienda que las estadísticas se recopilen en tablas con estadísticas obsoletas. Puede configurar tablas para monitorear y verificar su estado y hacer que analicen si están obsoletas. A menudo eso es suficiente, algunas veces no lo es. Realmente depende de tu base de datos. Para mi base de datos, tenemos un conjunto de tablas OLTP que necesitan recopilación de estadísticas nocturnas para mantener el rendimiento. Otras tablas se analizan una vez a la semana. En nuestra gran base de datos dw, analizamos según sea necesario, ya que las tablas son demasiado grandes para un análisis regular sin afectar la carga y el rendimiento general de la base de datos. Entonces, la respuesta correcta es que depende de la aplicación, el cambio de datos y las necesidades comerciales.

Answer 8

Dado que las estadísticas de Oracle 11g se recopilan automáticamente de manera predeterminada.

Dos ventanas de Scheduler están predefinidas en la instalación de Oracle Database:

• WEEKNIGHT_WINDOW comienza a las 10 p. M. Y termina a las 6 a.m. todos los lunes a viernes.
• WEEKEND_WINDOW cubre sábados y domingos todos los días.

¿Cuándo se recopilaron las estadísticas por última vez?

SELECT owner, table_name, last_analyzed FROM all_tables ORDER BY last_analyzed DESC NULLS LAST; --Tables.
SELECT owner, index_name, last_analyzed FROM all_indexes ORDER BY last_analyzed DESC NULLS LAST; -- Indexes.

Estado de la recopilación automatizada de estadísticas

SELECT * FROM dba_autotask_client WHERE client_name = ''auto optimizer stats collection'';

Grupos de Windows?

SELECT window_group_name, window_name FROM dba_scheduler_wingroup_members;

Horarios de ventanas?

SELECT window_name, start_time, duration FROM dba_autotask_schedule;

Reunir manualmente las estadísticas de la base de datos en este esquema:

EXEC dbms_stats.gather_schema_stats(ownname=>NULL, cascade=>TRUE); -- cascade=>TRUE means include Table Indexes too.

Reunir manualmente las estadísticas de la base de datos en todos los esquemas.

-- Probably need to CONNECT / AS SYSDBA
EXEC dbms_stats.gather_database_stats;

Answer 9

En general, no se recomienda recopilar estadísticas tan frecuentes en toda la base de datos a menos que tenga una sólida justificación para eso, como una inserción masiva o un cambio de big data que suceda con frecuencia en la base de datos. reunir estadísticas en la base de datos en esta frecuencia PUEDE cambiar el plan de ejecución de consultas a un nuevo plan de ejecución deficiente, la cosa puede costarle mucho tiempo tratando de ajustar cada consulta afectada por los nuevos planes deficientes, es por eso que debe probar el impacto de la recopilación nuevas estadísticas en una base de datos de prueba, o en caso de que no tenga el tiempo o el poder humano para eso, al menos debe mantener un plan alternativo haciendo una copia de seguridad de la estática original antes de recopilar nuevas, de modo que en caso de que obtenga una nuevas estadísticas y luego las consultas no funcionaron como se esperaba, puede restaurar fácilmente las estadísticas originales.

Hay una secuencia de comandos muy útil que puede ayudarlo a hacer una copia de seguridad de las estadísticas originales y a recopilar nuevas y proporcionarle un comando SQL que puede usar para restablecer las estadísticas estáticas originales en caso de que la situación no sea la esperada después de recopilar nuevas estadísticas. Puede encontrar la secuencia de comandos en este enlace: http://dba-tips.blogspot.com/2014/09/script-to-ease-gathering-statistics-on.html