Ответ 1

Во-первых, @Nick.McDermaid предоставил очень полезную ссылку в комментариях, чтобы узнать больше о Какие учетные данные пользователя использует каталог служб Integration Services для выполнения пакетов?

Предлагаемые решения

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

При запуске пакета SSISDB

1. Разрешения учетной записи SQL Server

Добавить разрешения на чтение и запись в учетную запись, на которую вы вошли в систему по указанным путям

2. Добавить проверку подлинности Windows в учетную запись сети

Вы можете добавить учетную запись для проверки подлинности Windows для сетевой учетной записи (используемой как прокси-сервер в агенте sql-сервера) и запустить пакет, используя его.

При запуске пакета из агента SQL

Это не ваше дело, но эти сведения могут помочь

1. Разрешения учетной записи SQL Server

Добавить разрешения чтения и записи для следующих учетных записей по указанным путям:

• NT SERVICE\SQLSERVERAGENT
• NT SERVICE\MSSQLSERVER

2. Настройка прокси-сервера

Вы можете настроить прокси-сервер для пакета SSIS и запустить задание, используя эту учетную запись прокси.

Вы можете обратиться к одной из следующих ссылок, чтобы узнать больше:

• Запуск пакета SSIS от агента SQL Server с использованием учетной записи прокси
• Настройка учетной записи прокси для запуска пакетов служб интеграции SQL Server (SSIS)

3. Карта сетевых дисков для экземпляра SQL Server

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

• Сделать сетевой путь видимым для резервного копирования и восстановления SQL Server в SSMS
• Настройка сетевого диска, видимого для SQL Server во время резервного копирования и восстановления с использованием SSMS

4. Добавление роли SysAdmin

Добавить роль SysAdmin в следующие учетные записи:

• NT SERVICE\SQLSERVERAGENT
• NT SERVICE\MSSQLSERVER

Другие ссылки, имеющие аналогичную проблему

• Доступ запрещен при попытке запустить задание агента
• Как разрешить отказ службы SSIS в SQL Server Management Studio
• Не удается получить доступ к сетевому ресурсу при выполнении пакета из каталога SSIS.
• Ошибка доступа к пути запрещена в пакете SSIS
• Ошибка задачи файловой системы; Доступ к пути "" запрещен
• [Задача файловой системы] Ошибка: произошла ошибка со следующим сообщением об ошибке: "Доступ к пути запрещен" .
• Доступ к пути отклонен Ошибка
• Файловая система Задача - скопирована из одной папки в другую папку получить ошибку - Путь доступа запрещен

Ответ 2

Вы просматривали разрешения для MSDB для своей учетной записи домена. Я бы сделал следующие шаги. У меня была аналогичная проблема

1) развертывание пакета на сервере (как вы уже сделали)

2) Убедитесь, что пакеты загружены и доступны в каталогах служб Integration Services под SSISDB

3) Переустановите проект и попробуйте его.

Если все эти мелкие, все еще пакеты не работают в SSISDB, я бы поставил задачу планировщика Windows с помощью CMD (DTEXUI/File/'Path Path). Извиняюсь, если это не касается разговоров о планировщике окон.

Ответ 3

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

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

Я понял, что это проблема с локальными и учетными записями AD, сканируя через SQL-журналы и немного скриптов в Visual Studio.

Я решил эту проблему:

• создание неинтерактивной учетной записи пользователя, которую я предоставил достаточно на машине SSIS (более или менее sysadmin на SQL Server, очень мало доступа к папкам на сервере... соответствует вашим потребностям)
• предоставление этой учетной записи доступа к другой папке сервера (через ACL)
• обновление моей службы SQL Agent для использования этой "юридической" учетной записи AD
• сделано!

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

Ответ 4

В ответах и ​​комментариях есть много догадок и красных сельдей. Он не имеет ничего общего с прокси-серверами SQL Agent, подключенными дисками, MSDB или sysadmin. По мере того как вы в конце концов узнали о своем вопросе, выполнение в SQL-агенте прекрасное, это просто, когда вы запускаете его в интерактивном режиме, щелкнув правой кнопкой мыши в каталоге служб Integration Services, что проблема возникает.

В заключительной части вашего вопроса указывается, что первопричина здесь понятна:

В любом случае мы можем настроить пакет для прогона через учетную запись прокси.

Интерактивный пользователь (один щелчок правой кнопкой мыши по каталогу) не имеет прав, и вам нужен способ запуска из каталога как другой пользователь, который имеет права.

Просто для подтверждения: если вы нажмете "Просмотр контекста" в своем журнале SSIS, он покажет вам, с каким пользователем он работал, что будет отличаться от успешных выполнения пакета из SQL-агента.

Я выкопал меню исполнения и конфигурации в каталоге, а также create_execution sp, и я не вижу способа запустить его как другого пользователя.

У меня есть два предложения:

• Использовать Run As при запуске SSMS и запускаться как другой пользователь
• Просто оберните пакет в SQL-агент, который позволяет использовать другие учетные записи для запуска пакета (либо учетной записи службы SQL-агента, либо прокси-сервера).

Ответ 5

У меня была похожая ошибка. После того, как я последовал ответу Хади выше, я получил его частично работающим. Задача "Файловая система" работает из NT SERVICE\SQLSERVERAGENT в качестве вызывающей стороны, но не использует мою учетную запись пользователя. Так что я думаю, в любом случае это разрешение вопроса.

Одна не связанная с этим проблема, возможно, только у меня, заключается в том, что я случайно использую Projection.Connections вместо Package.Connections, но развертываю только пакет, а не весь проект. Исправлено, и работа агента SQL Server работала.