none
PROBLEMAS PARA DESFRAGMENTAR UN PERO SOLO EN UN INDEX LEVEL, DE MI INDICE CLUSTERED RRS feed

  • Pregunta

  • HOLA COMUNIDAD

    ,primero que nada gracias por tomarse el tiempo de leer mi pregunta,

    pues miren estoy programando y haciendo los mantenimientos para una base de datos de mas de un tera de tamaño, entonces cuando saco mi reporte con sys.dm_db_index_physical_stats en modo detailed el siguiente es el resultado,,

    ya intente reorganizar, reconstruir, borrar indice y volver a generar y siempre me sigue dando el mismo nivel de fragmentacion en el index level 2, 

    esto me pasa en varias otras tablas  si saco un reporte en modo sampled ma da resultados de solo el primer index_level y esos se ven muy bien pero los otros niveles no siempre corresponden ,  alguien me puede ayudar a explicar y a saber si es posible como reducir esta fragmentación en todos los index levels? no solo en algunos??

    Saludos

    domingo, 22 de septiembre de 2013 17:10

Respuestas

  • Aunque no se me ocurre cómo podrías reducir esa fragmentación del level 2, lo que sí te puedo decir es que no deberías preocuparte mucho por ello. Fíjate en que solo tienes cuatro páginas en ese nivel (en cuatro fragmentos, es decir, las cuatro páginas no son contiguas). Esas cuatro páginas se te van a quedar en el caché de buffers la primera vez que se usen, y como además se usarán continuamente al hacer búsquedas en el índice, permanecerán dentro del caché. Ahí no hay problemas de que sean o no sean contiguas (están en memoria y el "seek" es instantaneo). Pero incluso aunque estuvieran en disco, no tiene importancia que no sean contiguas. Piensa en cómo funciona el ínidice: Se empieza por el nodo raíz, que en función del valor de la clave indica cuál es la página del siguiente nivel que contiene el dato buscado. Con ese dato se saca una y solo una página del siguiente nivel, la cuál tiene un puntero al siguiente nivel, etc. En consecuencia, nunca es necesario recorrer consecutivamente las páginas de un nivel del índice, por lo que no tiene importancia que se encuentren fragmentadas (es decir, en posiciones no contiguas en el archivo de datos). El único sitio donde importa la fragmentación es en el nivel cero, porque ahí sí que sería necesario recorrer todas las páginas secuencialmente en los casos en los que se haga un "index scan". Pero ese nivel sí que lo has defragmentado, así que no tienes problema.

    • Marcado como respuesta alfred_magno lunes, 23 de septiembre de 2013 14:30
    lunes, 23 de septiembre de 2013 6:26

Todas las respuestas

  • Aunque no se me ocurre cómo podrías reducir esa fragmentación del level 2, lo que sí te puedo decir es que no deberías preocuparte mucho por ello. Fíjate en que solo tienes cuatro páginas en ese nivel (en cuatro fragmentos, es decir, las cuatro páginas no son contiguas). Esas cuatro páginas se te van a quedar en el caché de buffers la primera vez que se usen, y como además se usarán continuamente al hacer búsquedas en el índice, permanecerán dentro del caché. Ahí no hay problemas de que sean o no sean contiguas (están en memoria y el "seek" es instantaneo). Pero incluso aunque estuvieran en disco, no tiene importancia que no sean contiguas. Piensa en cómo funciona el ínidice: Se empieza por el nodo raíz, que en función del valor de la clave indica cuál es la página del siguiente nivel que contiene el dato buscado. Con ese dato se saca una y solo una página del siguiente nivel, la cuál tiene un puntero al siguiente nivel, etc. En consecuencia, nunca es necesario recorrer consecutivamente las páginas de un nivel del índice, por lo que no tiene importancia que se encuentren fragmentadas (es decir, en posiciones no contiguas en el archivo de datos). El único sitio donde importa la fragmentación es en el nivel cero, porque ahí sí que sería necesario recorrer todas las páginas secuencialmente en los casos en los que se haga un "index scan". Pero ese nivel sí que lo has defragmentado, así que no tienes problema.

    • Marcado como respuesta alfred_magno lunes, 23 de septiembre de 2013 14:30
    lunes, 23 de septiembre de 2013 6:26
  • excelente respuesta,
    lunes, 23 de septiembre de 2013 14:30