SQL Server Performance

Indices Agrupados en DWH

Discussion in 'Preguntas sobre SQL Server en Español.' started by Negus, Oct 3, 2006.

  1. Negus New Member

    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.
  2. Luis Martin Moderator

    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.



  3. Negus New Member

    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.
  4. Luis Martin Moderator

    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.



  5. Negus New Member

    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.
  6. Luis Martin Moderator

    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.



  7. Negus New Member

    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!!!
  8. Luis Martin Moderator

    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.



Share This Page