Для # 1 - в SSIS нет встроенного механизма «перезапуска», так как для начала нет встроенного механизма «запуска». Вам нужно взглянуть на процесс, которым вы управляете по расписанию выполнения ваших пакетов, который, как я предполагаю, может быть агентом SQL.
Учитывая это, вы можете определить, не удалось ли выполнить задание агента SQL, и / или перезапустить это задание, независимо от того, является ли содержимое задания пакетами служб SSIS или нет. Существует довольно много хранимых процедур для мониторинга и запроса выполнения задания и результатов. Вы также можете реализовать свой собственный механизм для записи статуса работы / пакета.
SSIS предлагает «контрольные точки», чтобы помочь вам перезапустить пакеты с определенных точек, но общее мнение об этой функции заключается в том, что она ограничена в своей применимости - ваш пробег может варьироваться.
Лично я всегда включаю маршрут сбоя в свою работу, чтобы отправить кому-нибудь письмо о сбое задания, и настраиваю мои задания и пакеты на идемпотентность, то есть их можно повторно запускать, не опасаясь неправильного выполнения одних и тех же операций дважды. Они либо «сбрасывают» среду (удаляют и перезагружают), либо могут точно определить, где они остановились.
Пункт № 2 - сложный вопрос, который сильно зависит от вашей среды и сценария. Вы можете использовать простые задачи, такие как задача «Выполнение SQL», для запуска «тестовых» команд, которые проверяются на сбой при наличии достаточных привилегий или блокировок. Или вы можете запросить напрямую через SP или другие механизмы, чтобы определить, нужно ли вам принимать меры по исправлению положения, прежде чем пытаться запустить мясо вашего пакета.
Использование ограничений прецедента «по ошибке» может помочь с такой логикой. Так могут обработчики событий.