Назад | Перейти на главную страницу

Задание агента SQL-сервера для выполнения пакета SSIS завершается неудачно, пакет завершается успешно при запуске вручную

У меня установлен пакет SSIS на SQL-сервере (SQL Server 2012). Это довольно просто и просто извлекает данные из удаленного источника данных и добавляет их в локальную таблицу. Строка удаленного подключения использует аутентификацию SQL-сервера, а локальное соединение использует аутентификацию Windows. Пароль удаленного подключения защищен, и пакет был импортирован с установкой уровня защиты на Положитесь на серверное хранилище и роли для контроля доступа.

Если я запускаю пакет SSIS вручную, он работает. Если я запустил его из командной строки, используя dtexec, оно работает. Если я использую runas чтобы переключиться на учетную запись домена, под которой работает агент SQL-сервера, а затем запустить пакет, используя dtexec, оно работает. Если я создаю задание агента SQL с одним шагом для запуска пакета, оно терпит неудачу, предоставляя очень мало подробностей о том, что происходит. Я предполагаю, что он не может получить пароль для входа на удаленный SQL-сервер, потому что он очень быстро выходит из строя. Кроме того, если я поставлю галочку «записать в таблицу» и просмотрев полученный файл, я получу следующее:

Description: ADO NET Source has failed to acquire the connection {0D8F2CD4-A763-4AEB-8B52-B8FAE0621ED3} with the following error message: "Login failed for user 'username'.".

Если я попытаюсь добавить пароль в строку подключения вручную в data sources в диалоговом окне шага задания он отказывается сохранять его, всегда как бы удаляя бит «пароль» из строки подключения.

Я думал, что задания агента сервера SQL всегда выполняются в контексте учетной записи, под которой работает агент сервера SQL. Эта учетная запись sysadmin на локальном сервере SQL, и пакет работает с использованием dtexec под этой учетной записью, так почему бы ему не удалось выполнить задание в качестве агента?

У меня была такая же проблема. После некоторого исследования и убеждения сервера, над которым у меня не было контроля, чтобы добавить учетную запись с проверкой подлинности Windows в это место, и некоторого понимания из приведенного ниже URL-адреса, у меня все заработало:

http://social.msdn.microsoft.com/Forums/sqlserver/en-US/3f51de7b-52c2-471e-811b-d056f707f5bd/what-is-the-difference-between-job-owner-run-as-and- войти на-сервер-учетных записей? forum = sqlintegrationservices

Наше окружение

  • SQL Server 2012 размещает каталог служб интеграции, который объединяет данные из различных версий SQL Server из разных доменов.
  • Два домена, которые доверяют друг другу
    • Домен А
      • Каталог SSIS в домене A, задание агента SQL Server, на котором запущен пакет SSIS в домене A.
    • Домен B
      • Пакет SSIS извлекает данные из баз данных в домене B с помощью настройки соединений для проверки подлинности Windows в пакете SSIS. Пакет работает нормально.
      • Одна учетная запись службы, принадлежащая домену B, имеет доступ ко всем рассматриваемым источникам данных.

Решение

Это дало мне представление о различиях в том, как они выполняются для задания агента SQL Server. Учитывая тот факт, что мой пакет SSIS обращается к удаленному серверу в другом домене и что моя ошибка связана с учетной записью «Запуск от имени» на этом этапе, я решил создать еще одну учетную запись «Запуск от имени». Это также известно как прокси (Агент SQL Server> Прокси-серверы> Выполнение пакета SSIS).

Перед созданием прокси мне нужно было настроить учетные данные. Вот шаги, которые помогли мне решить эту проблему:

Все шаги предполагают, что ваш пакет SSIS загружен в каталог служб Integration Services, и создается задание агента SQL Server с шагом для запуска пакета из каталога SSIS (источник пакета).

  1. Создайте учетные данные (Безопасность> Учетные данные). Используйте идентификатор в учетных данных в качестве учетной записи службы, упомянутой выше.
  2. Создайте прокси-сервер выполнения пакета SSIS (Агент SQL Server> Прокси-серверы> Выполнение пакета SSIS). Чтобы все было легче понять, я дал ему то же имя, что и сервисный аккаунт.
  3. Перейдите к заданию агента SQL Server, а затем к шагу. Измените запуск от имени учетной записи службы агента SQL Server на вновь созданную учетную запись прокси. Нажмите ОК и ОК.
  4. Запустите задание для проверки.

Это сработало для нашей ситуации и позволило нашему пакету SSIS запускаться по расписанию, переходить через домен к другому серверу SQL Server и извлекать данные.

Обычно легче заставить их работать, если вы можете просто использовать аутентификацию Windows вместо аутентификации SQL.