Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Comment puis-je nettoyer la SSISDB ?

Phil Brammer a rencontré cela et une foule d'autres choses liées à l'entretien et à l'alimentation du catalogue SSIS, qu'il couvre sur son post Recommandations d'indexation de catalogue .

Problème racine

Le problème fondamental est que MS a tenté de concevoir le SSIS avec RI à l'esprit, mais ils étaient paresseux et ont autorisé les suppressions en cascade au lieu de les gérer explicitement.

Résolution

Jusqu'à ce que MS change la façon dont les choses fonctionnent, l'option prise en charge est

Je sais que chez mon client actuel, nous ne chargeons les données qu'aux petites heures, de sorte que la SSISDB est silencieuse pendant les heures ouvrables.

Si l'exécution de la tâche de maintenance pendant une période calme n'est pas une option, vous envisagez de créer vos propres instructions de suppression pour essayer de faire en sorte que les suppressions en cascade soient moindres. .

Chez mon client actuel, nous avons exécuté environ 200 packages par nuit au cours des 10 derniers mois et nous sommes également à 365 jours d'historique. Nos plus grandes tables, par ordre de grandeur, le sont.

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

Le pilote de toutes ces données, internal.operations ne contient que 3 300 lignes, ce qui correspond au commentaire de Phil sur la croissance exponentielle de ces données.

Donc, identifiez le operation_id à purger et à supprimer des tables feuilles en remontant vers le noyau, internal.operations tableau.

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;

Les mises en garde habituelles s'appliquent

  • ne faites pas confiance au code aléatoire sur Internet
  • utilisez les diagrammes de ssistalk et/ou des tables système pour identifier toutes les dépendances
  • vous devrez peut-être uniquement segmenter vos opérations de suppression en opérations plus petites
  • vous pourriez bénéficier de la suppression de l'IR pour les opérations, mais assurez-vous de les réactiver avec l'option de vérification afin qu'elles soient fiables.
  • consultez votre dba si les opérations durent plus de 4 heures

Modification de juillet 2020

Tim Mitchell a une bonne série d'articles sur Nettoyage automatique du catalogue SSIS et Une meilleure façon de nettoyer le Base de données du catalogue SSIS et son nouveau livre de fantaisie Le catalogue SSIS :installer, gérer , sécurisez et surveillez votre infrastructure ETL d'entreprise

@Yong Jun Kim noté dans les commentaires

C'est certainement le cas si vous utilisez un IR SSIS dans Azure Data Factory. Vous retrouverez les tables "normales" toujours présentes mais vides, avec le *_scaleout versions contenant toutes les données.

Références