SQL Server Performance Forum – Threads Archive
Indices Agrupados en DWH
Hola, He estado mirando el forum y me ha parecido muy bueno. Asà que me he unido a él y voy a hacer mi primera pregunta. La BBDD es un DWH que realiza cargas masivas diariamente de los dos últimos meses y de los dos últimos años el domingo.En todas las tablas hay un Ãndice agrupado por Mes (la información esta agregada a Mes). Adicionalmente, en algunas tablas hay Ãndices para mejorar el rendimiento de las consultas.
Cuando se realizan las cargas se borran los Ãndices no agrupados al inicio y se vuelven a crear al final de la inserción masiva. De los Ãndices agrupados no se hace nada ya que son ordenados fÃsicamente y entiendo que no se degradan.
Pero las cargas cada vez van más lentas y tengo la impresión que estos Ãndices estan afectando al rendimiento.
He leido en otras preguntas que recomendais hacer un plan de mantenimento para rehacer los Ãndices, entiendo que si en la carga los creamos de nuevo no hace falta este plan de mantenimiento. Pero ¿es necesario para los Ãndices agrupados? ¿deberÃa borrar y volver a crear estos Ãndices en las cargas?
Tambien he leido que no se marque la opción de actualizar las estadÃsticas automaticamente. En cargas masivas como las del DWH ¿tambien se debe desmarcar? y ¿se tendrÃa que hacer un plan de mantenimiento para actualizarlas? ¿en que momento?
Os agradeceria cualquier comentario para mejorar el rendimiento del DWH, ya sea en cargas como en consultas.
Vaya charla os he soltado! gracias de antemano por la ayuda. Saludos.
Para agilizar la carga de tablas como las que tu describes, siempre es mejor eliminar todos los Ãndices antes de la carga y luego volverlos a crear. Con respecto a que las estadÃsticas se actualicen automáticamente hay diferentes opiniones al respecto. Mi idea es no marcarla como automática y hacer un trabajo de mantenimiento nocturno que actualize todas las estadÃsticas. Para el caso de las tablas en cuestión, en resumen, eliminarÃa todos los Ãndices, cargarÃa, los volverÃa a crear y luego le correrÃa un update statistics en forma individual a cada una de esas tablas pesadas. Por otro lado revisarÃa el plan de ejecución de los queries que usan esas tablas de tanto en tanto. El optimizador puede utilizar un plan para una tabla de cierto tamaño pero luego no servirle si la tabla creció demasiado.
Luis Martin
Moderator
SQL-Server-Performance.com All in Love is Fair
Stevie Wonder
All postings are provided “AS IS†with no warranties for accuracy.
El problema que tengo es que las consultas suben el consumo de la CPU al 100%
He estado mirando un plan de ejecución y me ha sorprendido que para las tablas que tienen Ãndice agrupado por "Mes" dan como "recuento estimado de filas" 1, me ha parecido increible y he actualizado las estadÃsticas de la tabla y sigue igual. El caso es que el recuento es de 1.274.237 registros aunque solo se coge un mes porque se filtra por el mes de Agosto 2006 , ¿es correcto? a mi me parece que no es correcto. He estado leyendo una artÃculo de la Web en el que dice que se creen los Ãndices agrupados cuando son la clave de la tabla. No es mi caso, pero el hecho de ordenar fÃsicamente por Mes ayuda a mejorar las ejecuciones ya que siempre se filtra por Mes.
Ya que las consultas suben el consumo del CPU, te sugiero que para cada consulta ejecutes el Index Tuning Wizard. De esta forma podrás ver si los Ãndices que se utilizan son los adecuados o hay que generar otros. Luis Martin
Moderator
SQL-Server-Performance.com All in Love is Fair
Stevie Wonder
All postings are provided “AS IS†with no warranties for accuracy.
Luis, Estoy despistado. Ayer acabe de trabajar preocupado por el rendimiento de la BBDD. Pues hoy parece que no deba preocuparme del rendimiento. Las consultas que ayer me tardaban 55 minutos hoy tardan 5 segundos ?????????
Tengo una teoria que me gustarÃa tu opinión: El domingo se realiza una carga de los dos últimos años, lo cual es un volumen muy grande de información que se borra y luego se inserta. El tamaño de la BBDD es de 36 GB y solo hay 3 años, asà que deben ser unos 24 GB. Como te comenté esta marcado la actualización de estadÃsticas automática.
Posterior a acabar la carga que duró hasta el Lunes, el SQL Server consumÃa el 50% de la CPU sin consultas en ejecución. El martes se reinició la máquina y el consumo directamente fue de 50% de CPU. Adicionalmente como ya te comenté el plan de ejecución de las consultas sobre las tablas de más registros (36 millones) decÃa que el recuento estimado de filas era de 1.
Hoy he probado el Index Tuning Wizard y no entiende que se deba crear ningún Ãndice, pero la sorpresa más grande me la he llevado cuando he mirado el plan de ejecución y he visto que el recuento de filas daba el número de filas correctas!!!!!!
La teoria es que el SQLServer hasta el dÃa de ayer estaba actualizando las estadÃsticas ya que consumÃa CPU sin motivo aparente y el recuento de filas de las tablas no era correcto. Además hoy el consumo de CPU esta a cero sin consultas en ejecución y las consultas tienen un rendimiento infinitamente mejor.
Espero tus comentarios. Gracias y saludos.
Estoy de acuerdo con tu análisis.
Por eso te suguiero que no deje que el SQL actualize las estadÃsticas automáticamente. Genera un job que se ejecute dÃa por medio y los fines de semana en horarios sin uso para actualizar las estadÃsticas. Luis Martin
Moderator
SQL-Server-Performance.com All in Love is Fair
Stevie Wonder
All postings are provided “AS IS†with no warranties for accuracy.
Luis, He hecho un job para desactivar y otro para activar las estadÃsticas automáticamente además el job que me comentabas. Cuando inicio las cargas desmarco la opción y cuando acabo las cargas actualizo estadÃsticas y vuelvo a activar la opción.
El resultado ha sido muy bueno, la semana pasada el proceso llevaba 16 horas de ejecución y lo tuve que parar. Ayer el proceso tardo menos de 7 horas. Muchas gracias por vuestra ayuda!!!
Bienvenido Nequs!! Luis Martin
Moderator
SQL-Server-Performance.com All in Love is Fair
Stevie Wonder
All postings are provided “AS IS†with no warranties for accuracy.
]]>