Как я могу очистить SSISDB?

Когда я установил это, я забыл о периоде хранения. Моя база данных стала довольно большой, поэтому я хочу уменьшить ее размер. Если я просто изменил период хранения (это было 365), это вызывает проблемы с запуском моих пакетов SSIS. Я даже изменил его с небольшими приращениями, но оператор удаления создавал блокировки, которые предотвратили бы запуск новых заданий.

Любые идеи, как обойти это? Я думал о создании нового SSISDB.

ОТВЕТЫ

Ответ 1

Фил Браммер столкнулся с этим и множеством других вещей, связанных с заботой и кормлением каталога SSIS, который он охватывает в своем сообщении Рекомендации по индексированию каталогов.

Проблема с корнем

Коренная проблема заключается в том, что MS пыталась спроектировать SSIS с RI в виду, но они были ленивы и разрешали каскадные удаления, чтобы их явно обрабатывать.

Из новой версии новая база данных каталога SSIS 2012 (SSISDB) имеет базовое индексирование, при этом ссылочная целостность настроена на выполнение каскадных удалений между большинством таблиц.

Введите задание агента SQL, "Обслуживание службы SSIS Server". Это задание по умолчанию запускается в полночь ежедневно и использует два параметра каталога для работы: "Периодически чистить журналы" и "Период хранения (дни)". Когда они установлены, работа по техническому обслуживанию очищает любые данные за пределами указанного периода хранения.

Это задание на техническое обслуживание удаляет, 10 записей за раз в цикле, из internal.operations и затем каскадируется во многие таблицы вниз по течению. В нашем случае у нас есть около 3000 записей операций, которые можно удалить ежедневно (по 10 за раз!), Что составляет 1,6 миллиона строк из internal.operation_messages. Это просто один стол вниз! Весь этот процесс полностью блокирует базу данных SSISDB из любых данных SELECT/INSERT.

Решение

Пока MS не изменит работу, поддерживаемая опция

переместите расписание работ по обслуживанию на более подходящее время для вашей среды

Я знаю, что у моего текущего клиента мы загружаем данные только в часы работы, поэтому SSISDB не работает в рабочее время.

Если выполнение задания на техническое обслуживание в течение спокойного периода не является вариантом, вы смотрите на создание собственных операторов удаления, чтобы попытаться уменьшить количество каскадных удалений.

На моем нынешнем клиенте мы проработали около 200 пакетов в течение последних 10 месяцев, а также в 365 дней истории. Наши самые большие таблицы на порядок.

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

Драйвер всех этих данных internal.operations имеет только 3300 строк, что согласуется с комментарием Фила о том, насколько экспоненциально эти данные растут.

Итак, идентифицируйте operation_id, который нужно очистить, и удаление из таблиц листа, возвращающихся в ядро, internal.operations.

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;

Применяются обычные оговорки - не доверяйте коду из рандомов в Интернете - использовать диаграммы из ssistalk и/или системных таблиц для определения всех зависимостей - вам может потребоваться только сегментировать операции удаления в более мелкие операции - вам может быть полезно сбросить RI для операций, но обязательно верните их с опцией проверки, чтобы они были доверенными. - проконсультируйтесь с вашей dba, если операция длится дольше 4 часов.

Ссылки