Phil Brammer stødte på dette og en lang række andre ting relateret til pleje og fodring af SSIS-kataloget, som han dækker i sit indlæg Anbefalinger til katalogindeksering .
Rodproblem
Grundproblemet er, at MS forsøgte at designe SSIS med RI i tankerne, men de var dovne og tillod de kaskadende sletninger at ske i modsætning til eksplicit håndtering af dem.
Opløsning
Indtil MS ændrer, hvordan tingene fungerer, er den understøttede mulighed
Jeg ved, hos min nuværende klient, at vi kun indlæser data i de små timer, så SSISDB er stille i åbningstiden.
Hvis det ikke er en mulighed at køre vedligeholdelsesjobbet i en stille periode, så overvejer du at lave dine egne delete-sætninger for at prøve at få de kaskadende sletninger til at suge mindre .
Hos min nuværende klient har vi kørt omkring 200 pakker om natten i de sidste 10 måneder og har også 365 dages historie. Vores største borde i en størrelsesorden er.
Schema Table RowCount
internal event_message_context 1,869,028
internal operation_messages 1,500,811
internal event_messages 1,500,803
Driveren for alle disse data, internal.operations
har kun 3300 rækker i sig, hvilket stemmer overens med Phils kommentar om, hvor eksponentielt disse data vokser.
Så identificer operation_id
skal renses, og sletningen fra bladtabellerne arbejder tilbage til kernen, internal.operations
tabel.
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;
Sædvanlige forbehold gælder
- stol ikke på kode fra tilfældige på internettet
- brug diagrammerne fra ssistalk og/eller systemtabeller til at identificere alle afhængigheder
- du skal muligvis kun segmentere dine slettehandlinger i mindre operationer
- du kan drage fordel af at droppe RI til operationer, men sørg for at genaktivere dem med afkrydsningsmuligheden, så de er tillid til.
- Konsulter din dba, hvis operationer varer længere end 4 timer
Redigering af juli 2020
Tim Mitchell har et godt sæt artikler om Automatisk oprydning i SSIS-kataloget og En bedre måde at rydde op i SSIS-katalogdatabase og hans fancy nye bog SSIS Catalog:Install, Manage , Sikre og overvåg din virksomheds ETL-infrastruktur
@Yong Jun Kim noteret i kommentarerne
Dette er bestemt tilfældet, hvis du bruger en SSIS IR i Azure Data Factory. Du vil finde de "normale" tabeller stadig til stede, men tomme, med *_scaleout
versioner, der indeholder alle data.
Referencer
- Katalogindekseringsanbefalinger
- Pas på SSIS-servervedligeholdelsesopgaven
- Langsom ydeevne, når du kører SSIS Server Maintenance Job for at fjerne gamle data i SQL Server 2012