{"id":735,"date":"2025-12-21T11:07:44","date_gmt":"2025-12-21T11:07:44","guid":{"rendered":"https:\/\/datacrazyworld.com\/?p=735"},"modified":"2025-12-21T11:10:38","modified_gmt":"2025-12-21T11:10:38","slug":"cuando-los-planes-de-mantenimiento-tambien-necesitan-mantenimiento","status":"publish","type":"post","link":"https:\/\/datacrazyworld.com\/index.php\/2025\/12\/21\/cuando-los-planes-de-mantenimiento-tambien-necesitan-mantenimiento\/","title":{"rendered":"Cuando los planes de mantenimiento tambi\u00e9n necesitan mantenimiento"},"content":{"rendered":"\n

\u00bfUtilizas los planes de mantenimiento de SQL Server? Si es as\u00ed, d\u00e9jame hacerte una pregunta m\u00e1s: \u00bfrealizas alg\u00fan tipo de limpieza o mantenimiento sobre su tabla de logs?<\/p>\n\n\n\n

Si tu respuesta es no (o no lo sabes), no te preocupes: no eres el \u00fanico. Yo mismo descubr\u00ed este detalle casi por casualidad\u2026 y las consecuencias. En este art\u00edculo te cuento qu\u00e9 ocurri\u00f3, por qu\u00e9 sucede y c\u00f3mo lo solucion\u00e9.<\/p>\n\n\n\n

El problema: picos peri\u00f3dicos de CPU<\/strong><\/h3>\n\n\n\n

Hace unas semanas, mientras revisaba el estado general del sistema, empec\u00e9 a notar picos de CPU que se repet\u00edan de forma peri\u00f3dica. No era algo puntual: el patr\u00f3n se repet\u00eda desde hac\u00eda varios d\u00edas.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Al profundizar en el an\u00e1lisis, observ\u00e9 que estos picos coincid\u00edan con lecturas intensivas sobre la tabla: msbd.dbo.sysmaintplan_logdetail<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Esto ya llam\u00f3 mi atenci\u00f3n, ya que se trata de una tabla asociada a los planes de mantenimiento de SQL Server.<\/p>\n\n\n\n

Investigando la causa<\/h3>\n\n\n\n

Buscando informaci\u00f3n, encontr\u00e9 un art\u00edculo muy esclarecedor de Steve Stedman donde se analizaba precisamente esta tabla y su crecimiento descontrolado https:\/\/stevestedman.com\/2016\/03\/sql-server-sysmaintplan_logdetail<\/a><\/p>\n\n\n\n

Tras ejecutar algunas de las consultas recomendadas…<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

…la situaci\u00f3n qued\u00f3 bastante clara:<\/p>\n\n\n\n

    \n
  • Total de registros: 4.325.471<\/strong><\/li>\n\n\n\n
  • Registros con m\u00e1s de un a\u00f1o de antig\u00fcedad: 2.418.255<\/strong><\/li>\n\n\n\n
  • Registros del \u00faltimo a\u00f1o: 1.907.510<\/strong><\/li>\n<\/ul>\n\n\n\n

    Es decir, m\u00e1s de la mitad de la tabla conten\u00eda informaci\u00f3n antigua que ya no aportaba valor.<\/p>\n\n\n\n

    \u00bfPor qu\u00e9 afecta al rendimiento?<\/strong><\/h3>\n\n\n\n

    Para entender los picos de CPU, analic\u00e9 el comportamiento de una consulta ad hoc que acced\u00eda a esta tabla.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    El resultado fue revelador: en determinados momentos, el consumo de CPU se disparaba de forma abrupta. El plan de ejecuci\u00f3n antes y despu\u00e9s no variaba, lo que indicaba que el problema no era el plan en s\u00ed, sino el volumen de datos que deb\u00eda procesar.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Voy a intentar resumir qu\u00e9 es lo que est\u00e1 pasando para luego poder hablar de c\u00f3mo lo voy a solucionar.<\/p>\n\n\n\n

    \u00bfQu\u00e9 es dbo.sysmaintplan_logdetail<\/strong>?<\/h3>\n\n\n\n

    Es la tabla donde SQL Server registra todas las ejecuciones de los planes de mantenimiento (los que se configuran donde indica la imagen de abajo). Cada vez que se ejecuta un plan, su resultado queda almacenado aqu\u00ed.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Si utilizas los planes de mantenimiento que ofrece SQL Server de forma nativa, el motor siempre<\/strong> registra informaci\u00f3n en esta tabla. No existe ninguna opci\u00f3n para desactivar este comportamiento.<\/p>\n\n\n\n

    Las opciones, por tanto, son b\u00e1sicamente dos:<\/p>\n\n\n\n

      \n
    1. Limpiar peri\u00f3dicamente esta tabla.<\/li>\n\n\n\n
    2. Crear planes de mantenimiento personalizados, sin utilizar los asistentes de SQL Server.<\/li>\n<\/ol>\n\n\n\n

      Ambas alternativas son v\u00e1lidas, pero en mi caso opt\u00e9 por la primera.<\/p>\n\n\n\n

      Un detalle curioso (y peligroso)<\/strong><\/h3>\n\n\n\n

      Esta tabla, al tratarse de un log, est\u00e1 definida como un HEAP<\/strong> (sin \u00edndice clustered).<\/p>\n\n\n\n

      \"\"<\/figure>\n\n\n\n

      Esto tiene sentido desde el punto de vista de escritura: las inserciones son r\u00e1pidas. El problema aparece cuando el sistema necesita leerla, especialmente cuando el volumen de datos es elevado. Ah\u00ed es donde comienzan los escaneos costosos y, con ellos, los picos de CPU.<\/p>\n\n\n\n

      La soluci\u00f3n: limpieza peri\u00f3dica<\/h3>\n\n\n\n

      La soluci\u00f3n fue sencilla en concepto, pero muy efectiva en resultados:<\/p>\n\n\n\n

        \n
      • Limpiar la tabla de registros antiguos.<\/li>\n\n\n\n
      • Programar un Job que realice esta limpieza de forma peri\u00f3dica.<\/li>\n<\/ul>\n\n\n\n

        Antes de implementar la soluci\u00f3n, analizamos cu\u00e1nto tiempo ten\u00eda realmente valor conservar esta informaci\u00f3n. Finalmente, decidimos mantener un hist\u00f3rico de 6 semanas<\/strong>, m\u00e1s que suficiente para nuestras necesidades.<\/p>\n\n\n\n

        El c\u00f3digo utilizado para el borrado fue el siguiente:<\/p>\n\n\n\n

        declare @f datetime = '20241118'\n\nWHILE @f < dateadd(WEEK,-6,GETUTCDATE() )\nBEGIN\n\tprint @f\n\tEXEC msdb.dbo.sp_maintplan_delete_log @oldest_time=@f\n\n\tset @f = DATEADD(day,1,@f)\nEND<\/code><\/pre>\n\n\n\n
        Este proceso se program\u00f3 como un Job para que se ejecute de manera autom\u00e1tica.<\/p>\n\n\n\n
        El resultado<\/h3>\n\n\n\n
        Tras aplicar estos cambios, los picos de CPU desaparecieron por completo. El sistema volvi\u00f3 a comportarse de forma estable y, adem\u00e1s, se redujo notablemente el tama\u00f1o de la base de datos msdb.<\/p>\n\n\n\n
        \"\"<\/figure>\n\n\n\n
        Conclusi\u00f3n<\/h3>\n\n\n\n
        Aunque muchas veces lo pasamos por alto, los propios planes de mantenimiento de SQL Server tambi\u00e9n necesitan mantenimiento. No gestionar adecuadamente el crecimiento de la tabla sysmaintplan_logdetail puede derivar en problemas de rendimiento dif\u00edciles de identificar.<\/p>\n\n\n\n
        Mi recomendaci\u00f3n es clara: define una pol\u00edtica de limpieza acorde a tus necesidades y automat\u00edzala. Te evitar\u00e1 m\u00e1s de una sorpresa desagradable \ud83d\ude0a<\/p>\n","protected":false},"excerpt":{"rendered":"
        Los planes de mantenimiento de SQL Server almacenan sus ejecuciones en la tabla msdb.dbo.sysmaintplan_logdetail. Cuando esta tabla crece sin control, puede provocar picos de CPU y problemas de rendimiento. En este art\u00edculo se explica un caso real, la causa del problema y c\u00f3mo solucionarlo mediante la limpieza peri\u00f3dica de los logs.<\/p>\n","protected":false},"author":2,"featured_media":614,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[8],"tags":[21,13],"class_list":["post-735","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sqlserver","tag-sqlserver","tag-ssms"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t