Sqlserver
 sql >> Database >  >> RDS >> Sqlserver

Come posso pulire il SSISDB?

Phil Brammer si è imbattuto in questo e in una miriade di altri aspetti relativi alla cura e all'alimentazione del catalogo SSIS, di cui tratta nel suo post Suggerimenti per l'indicizzazione del catalogo .

Problema alla radice

Il problema principale è che gli Stati membri hanno tentato di progettare l'SSIS tenendo presente l'IR, ma erano pigri e hanno consentito che le eliminazioni a cascata avvenissero anziché gestirle in modo esplicito.

Risoluzione

Fino a quando MS non cambierà il modo in cui funzionano le cose, l'opzione supportata è

So che al mio attuale cliente carichiamo i dati solo nelle prime ore del mattino, quindi SSISDB è silenzioso durante l'orario lavorativo.

Se l'esecuzione del lavoro di manutenzione durante un periodo tranquillo non è un'opzione, allora stai cercando di creare le tue istruzioni di eliminazione per provare a far sì che le eliminazioni a cascata succhiano meno .

Al mio attuale cliente, abbiamo eseguito circa 200 pacchetti ogni notte negli ultimi 10 mesi e abbiamo anche 365 giorni di storia. Le nostre tabelle più grandi, di un ordine di grandezza lo sono.

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

Il driver di tutti quei dati, internal.operations contiene solo 3300 righe, il che è in linea con il commento di Phil su come crescono esponenzialmente questi dati.

Quindi, identifica il operation_id da eliminare e l'eliminazione dalle tabelle foglia torna al core, internal.operations tabella.

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;

Si applicano le solite avvertenze

  • non fidarti del codice casuale su Internet
  • usa i diagrammi di ssistalk e/o le tabelle di sistema per identificare tutte le dipendenze
  • potrebbe essere necessario segmentare le tue operazioni di eliminazione solo in operazioni più piccole
  • potresti trarre vantaggio dall'eliminazione delle RI per le operazioni, ma assicurati di riattivarle con l'opzione di controllo in modo che siano attendibili.
  • consulta il tuo dba se le operazioni durano più di 4 ore

Modifica luglio 2020

Tim Mitchell ha una buona serie di articoli su Pulizia automatica del catalogo SSIS e Un modo migliore per ripulire Database del catalogo SSIS e il suo nuovo fantastico libro Il catalogo SSIS:Installa, gestisci , proteggi e monitora la tua infrastruttura ETL aziendale

@Yong Jun Kim annotato nei commenti

Questo è sicuramente il caso se si usa un IR SSIS all'interno di Azure Data Factory. Troverai le tabelle "normali" ancora presenti ma vuote, con il *_scaleout versioni contenenti tutti i dati.

Riferimenti