Phil Brammer stieß auf diese und eine Menge anderer Dinge im Zusammenhang mit der Pflege und Fütterung des SSIS-Katalogs, die er in seinem Beitrag behandelt Katalogindizierungsempfehlungen .
Root-Problem
Das Hauptproblem besteht darin, dass MS versucht hat, das SSIS mit Blick auf RI zu entwerfen, aber sie waren faul und haben die kaskadierenden Löschvorgänge zugelassen, anstatt sie explizit zu handhaben.
Auflösung
Bis MS die Funktionsweise ändert, ist die unterstützte Option
Ich weiß, dass wir bei meinem aktuellen Client Daten nur in den frühen Morgenstunden laden, damit die SSISDB während der Geschäftszeiten ruhig ist.
Wenn das Ausführen des Wartungsjobs während einer Ruhephase keine Option ist, versuchen Sie, Ihre eigenen Löschanweisungen zu erstellen, um zu versuchen, dass die kaskadierenden Löschvorgänge weniger saugen .
Bei meinem aktuellen Kunden haben wir in den letzten 10 Monaten jede Nacht etwa 200 Pakete ausgeführt und sind auch bei 365 Tagen Geschichte. Unsere um Größenordnungen größten Tabellen sind.
Schema Table RowCount
internal event_message_context 1,869,028
internal operation_messages 1,500,811
internal event_messages 1,500,803
Der Treiber all dieser Daten, internal.operations
enthält nur 3300 Zeilen, was mit Phils Kommentar darüber übereinstimmt, wie exponentiell diese Daten wachsen.
Identifizieren Sie also die operation_id
zu löschen und aus den Blatttabellen zu löschen, die zum Kern zurückarbeiten, internal.operations
Tabelle.
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;
Es gelten die üblichen Vorbehalte
- vertraue keinem Zufallscode aus dem Internet
- Verwenden Sie die Diagramme von ssistalk und/oder Systemtabellen, um alle Abhängigkeiten zu identifizieren
- Möglicherweise müssen Sie Ihre Löschvorgänge nur in kleinere Vorgänge unterteilen
- Sie könnten davon profitieren, RI für Operationen zu löschen, aber stellen Sie sicher, dass Sie sie mit der Check-Option wieder aktivieren, damit sie vertrauenswürdig sind.
- Wenden Sie sich an Ihren dba, wenn Vorgänge länger als 4 Stunden dauern
Juli 2020 bearbeiten
Tim Mitchell hat eine gute Reihe von Artikeln zu Automatische Bereinigung des SSIS-Katalogs und A better way to Clean up the SSIS-Katalogdatenbank und sein schickes neues Buch The SSIS Catalog:Install, Manage , Sichern und Überwachen Sie Ihre Unternehmens-ETL-Infrastruktur
@Yong Jun Kim in den Kommentaren vermerkt
Dies ist sicherlich der Fall, wenn Sie eine SSIS IR in Azure Data Factory verwenden. Sie finden die "normalen" Tabellen immer noch vorhanden, aber leer, mit dem *_scaleout
Versionen mit allen Daten.
Referenzen
- Katalogindexierungsempfehlungen
- Vorsicht den SSIS-Server-Wartungsauftrag
- Langsame Leistung beim Ausführen des SSIS-Serverwartungsauftrags zum Entfernen alter Daten in SQL Server 2012