Почему после миграции происходит сбой пакета SSIS с недопустимой подписью?
Мой офис только что перешел с SQL Server 2008R2 на SQL Server 2017. Мы преобразовали чуть менее 100 пакетов SSIS в формат 2017 года. Многие из них запускаются заданиями SQL. Подавляющее большинство из них работают нормально после миграции. Однако у нас есть несколько (возможно, 10), которые иногда не работают с ошибкой недопустимой подписи. Для тех, кто терпит неудачу, я даже не вижу стабильной 100% -ной скорости отказов.
Почему пакеты периодически выходят из строя с этой ошибкой?
Ниже приведен пример полного текста ошибки. Один из примеров пакетов был развернут на 4 разных серверах, и он нормально работает на 3 из них. Единственная разница между 4 версиями - это путь к файлу dtconfig. Мы ничего не меняли в заданиях, вызывающих пакеты.
Я попытался повторно развернуть отказавший пакет для этого примера, который я только что упомянул, но он все равно будет периодически выходить из строя с ошибкой недопустимой подписи. Кроме того, наш ИТ-отдел подтвердил, что пользователь, под которым выполняются задания, имеет права на чтение файла dtsx.
Executed as user: domain\username. Microsoft (R) SQL Server Execute Package Utility Version 14.0.3045.24 for 64-bit Copyright (C) 2017 Microsoft. All rights reserved. Started: 6:30:00 AM Error: 2018-12-18 06:30:00.82 Code: 0xC0011007 Source: {5576F0C1-D470-418D-8FAB-9700612AEF76} Description: Unable to load the package as XML because of package does not have a valid XML format. A specific XML parser error will be posted. End Error Error: 2018-12-18 06:30:00.82 Code: 0xC0011002 Source: {5576F0C1-D470-418D-8FAB-9700612AEF76} Description: Failed to open package file "\\servername\sharename\mypackage.dtsx" due to error 0x80090006 "Invalid Signature.". This occurs when loading a package and the file cannot be opened or loaded correctly into the XML document. This can be the result of specifying an incorrect file name when calling LoadPackage or the specified XML file has an incorrect format. End Error Could not load package "\\servername\sharename\mypackage.dtsx" because of error 0xC0011002. Description: Failed to open package file "\\servername\sharename\mypackage.dtsx" due to error 0x80090006 "Invalid Signature.". This occurs when loading a package and the file cannot be opened or loaded correctly into the XML document. This can be the result of specifying an incorrect file name when calling LoadPackage or the specified XML file has an incorrect format. Source: {5576F0C1-D470-418D-8FAB-9700612AEF76} Started: 6:30:00 AM Finished: 6:30:00 AM Elapsed: 0.016 seconds. The package could not be found. The step failed.
Пахнет разрешениями на вашем пути. Я часто вижу пакеты, хранящиеся в базе данных, а не в файловой системе. Если ваша среда позволяет, я могу попробовать этот подход. Работают ли они одновременно на этих 4 машинах, нацеленных на одну общую сеть dtsx?
Мы собрали пакеты в SSDT 2017 и подтвердили, что пакет xml показывает другую версию. Нам сказали использовать файловую систему для миграции, но я не знаю почему. Я должен проверить и посмотреть, можно ли рассмотреть этот вариант в будущем.
Упомянутый пример пакета развернут как 4 разных файла на 4 разных серверах.
Пакет разворачивается в 4-х частях на 4-х разных серверах? Звучит ужасно беспорядочно.
Просто чтобы уточнить ... это один и тот же файл dtsx, развернутый на 4 разных серверах. Он не разделен на 4 части.
Ответы 1
Сотрудник нашел решение, которое сработало для нас. Нам пришлось обновить задания SQL Server, которые вызывали пакеты SSIS. Вместо ссылки на UNC-пути эти задания теперь ссылаются на локальные пути. После внесения этого изменения мы больше не видим ошибок.
Те же определения заданий работали в SQL Server 2008R2. Однако в то же время мы обновили и версию нашей серверной ОС, так что, возможно, это тоже было важным фактором.
Возможно, вы преобразовали пакеты в SSDT 2017, но собирали ли вы пакеты как пакеты 2017? ошибка также означает, что вы используете метод развертывания файловой системы. По какой причине вы не используете SSISDB? Есть много преимуществ использования нового метода развертывания проекта, который также (начиная с SQL Server 2017) теперь поддерживает развертывание отдельных пакетов из проекта.