sql >> Base de Datos >  >> RDS >> Sqlserver

¿Cómo puedo limpiar el SSISDB?

Phil Brammer se encontró con esto y muchas otras cosas relacionadas con el cuidado y la alimentación del catálogo de SSIS, que cubre en su publicación Recomendaciones de indexación de catálogos .

Problema de raíz

El problema principal es que MS intentó diseñar el SSIS teniendo en cuenta a RI, pero fueron perezosos y permitieron que ocurrieran las eliminaciones en cascada en lugar de manejarlas explícitamente.

Resolución

Hasta que MS cambie la forma en que funcionan las cosas, la opción admitida es

Sé que en mi cliente actual, solo cargamos datos en las primeras horas de la madrugada, por lo que SSISDB está inactivo durante el horario laboral.

Si ejecutar el trabajo de mantenimiento durante un período de inactividad no es una opción, entonces está pensando en crear sus propias declaraciones de eliminación para intentar que las eliminaciones en cascada apestan menos. .

En mi cliente actual, hemos estado ejecutando alrededor de 200 paquetes todas las noches durante los últimos 10 meses y también tenemos 365 días de historial. Nuestras mesas más grandes, por orden de magnitud, son.

Schema    Table                   RowCount
internal  event_message_context   1,869,028
internal  operation_messages      1,500,811
internal  event_messages          1,500,803

El controlador de todos esos datos, internal.operations solo tiene 3300 filas, lo que se alinea con el comentario de Phil sobre cuán exponencialmente crecen estos datos.

Entonces, identifique el operation_id para ser purgado y la eliminación de las tablas hoja trabajando de vuelta al núcleo, internal.operations mesa.

USE SSISDB;
SET NOCOUNT ON;
IF object_id('tempdb..#DELETE_CANDIDATES') IS NOT NULL
BEGIN
    DROP TABLE #DELETE_CANDIDATES;
END;

CREATE TABLE #DELETE_CANDIDATES
(
    operation_id bigint NOT NULL PRIMARY KEY
);

DECLARE @DaysRetention int = 100;
INSERT INTO
    #DELETE_CANDIDATES
(
    operation_id
)
SELECT
    IO.operation_id
FROM
    internal.operations AS IO
WHERE
    IO.start_time < DATEADD(day, [email protected], CURRENT_TIMESTAMP);

DELETE T
FROM
    internal.event_message_context AS T
    INNER JOIN
        #DELETE_CANDIDATES AS DC
        ON DC.operation_id = T.operation_id;

DELETE T
FROM
    internal.event_messages AS T
    INNER JOIN
        #DELETE_CANDIDATES AS DC
        ON DC.operation_id = T.operation_id;

DELETE T
FROM
    internal.operation_messages AS T
    INNER JOIN
        #DELETE_CANDIDATES AS DC
        ON DC.operation_id = T.operation_id;

-- etc
-- Finally, remove the entry from operations

DELETE T
FROM
    internal.operations AS T
    INNER JOIN
        #DELETE_CANDIDATES AS DC
        ON DC.operation_id = T.operation_id;

Se aplican las advertencias habituales

  • no confíes en el código de randoms en Internet
  • utilice los diagramas de ssistalk y/o las tablas del sistema para identificar todas las dependencias
  • es posible que solo necesite segmentar sus operaciones de eliminación en operaciones más pequeñas
  • podría beneficiarse eliminando RI para las operaciones, pero asegúrese de volver a habilitarlas con la opción de verificación para que sean de confianza.
  • consulte a su dba si las operaciones duran más de 4 horas

Edición de julio de 2020

Tim Mitchell tiene un buen conjunto de artículos sobre Limpieza automática del catálogo de SSIS y Una mejor manera de limpiar el Base de datos del catálogo de SSIS y su nuevo y elegante libro El catálogo de SSIS:instalar, administrar , proteja y supervise la infraestructura ETL de su empresa

@Yong Jun Kim anotado en los comentarios

Este es sin duda el caso si usa un SSIS IR dentro de Azure Data Factory. Encontrará las tablas "normales" aún presentes pero vacías, con el *_scaleout versiones que contienen todos los datos.

Referencias