【发布时间】:2015-10-07 01:13:31
【问题描述】:
我在我们的 SQL Server“9”上运行了以下批处理文件。它是一个没有连接、没有任务、没有代码的 SSIS 2012 包。这是一个空包。
ECHO before dtexe!
REM "DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
"D:\SQL2012\110\DTS\Binn\DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
SET RESULT=%errorlevel%
ECHO RESULT AFTER DTEXEC=%RESULT%
exit /B %RESULT%
这是我的输出:
----------------------------------------------------------------
Output of messages for workload object TEST/GHG1990R.28/MAIN
Start date Tue Oct 06 20:45:38 2015
----------------------------------------------------------------
C:\Users\MyServerId>ECHO before dtexe!
before dtexe!
C:\Users\MyServerId>REM "DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
C:\Users\MyServerId>"D:\SQL2012\110\DTS\Binn\DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
Microsoft (R) SQL Server Execute Package Utility
Version 11.0.5058.0 for 64-bit
Copyright (C) Microsoft Corporation. All rights reserved.
Started: 8:45:39 PM
Could not load package "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx" because of error 0x80131534.
Description: The package failed to load due to error 0x80131534 "(null)". This occurs when CPackage::LoadFromXML fails.
Source: {BA581388-EFF5-4BC7-89E7-48E11D6DF0AE}
Started: 8:45:39 PM
Finished: 8:45:39 PM
Elapsed: 0.094 seconds
C:\Users\MyServerId>SET RESULT=5
C:\Users\MyServerId>ECHO RESULT AFTER DTEXEC=5
RESULT AFTER DTEXEC=5
C:\Users\MyServerId>exit /B 5
无论我使用 32 位还是 64 位 DTEXEC 实用程序运行,我都会遇到相同的错误。当我在另一个 SQL Server 服务器“80”上针对同一个包运行同一个批处理文件时,我没有收到任何错误。
所有的包都在服务器 80 上工作,没有一个在 9 上工作。我每次在服务器 9 上都会收到上述错误。
当我在 80 和 9 上执行此操作时,
select @@version
我得到相同的结果
Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
May 14 2014 18:34:29
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)
我能够在 9 上成功使用 sqlcmd 和 bcp 实用程序,但不能使用 dtexec 实用程序。
我得到的错误似乎表明我正在使用旧版本的 dtexec 打开一个更新的包,例如,尝试使用 SQL 2008 dtexec util 来执行一个新的 SQL 2012 包。
显然这些包没有损坏,因为所有的包都在 80 上工作,而在 9 上的 exct 文件的副本都不起作用。
我唯一能想到的是 SQL Server 的安装问题,例如,损坏的安装或未注册的 dll。
据我所知,这是安装在这些机器上的第一个也是唯一一个 SQL Server 版本,所以我不应该用较新的 2012 包运行旧版本的 DTEXEC。
这是完整的 Empty2012Package.dtsx 文件:
<?xml version="1.0"?>
<DTS:Executable
DTS:refId="Package" xmlns:DTS="www.microsoft.com/SqlServer/Dts"
DTS:ExecutableType="SSIS.Package.3"
DTS:CreatorName="MyDOMAIN\MyLanId"
DTS:CreatorComputerName="MYCPTR"
DTS:CreationDate="7/2/2015 8:26:52 AM"
DTS:PackageType="5"
DTS:VersionBuild="2"
DTS:VersionGUID="{00FD1F37-6375-4942-91D3-9ECA0B131FFD}"
DTS:LastModifiedProductVersion="11.0.2100.60"
DTS:LocaleID="1033"
DTS:ObjectName="Empty2012Package"
DTS:DTSID="{1539BA56-F17B-438E-A874-A2151F2F79C5}"
DTS:CreationName="SSIS.Package.3">
<DTS:Property
DTS:Name="PackageFormatVersion">6</DTS:Property>
<DTS:Variables />
<DTS:Executables />
<DTS:DesignTimeProperties><![CDATA[<?xml version="1.0"?>
<!--This CDATA section contains the layout information of the package. The section includes information such as (x,y) coordinates, width, and height.-->
<!--If you manually edit this section and make a mistake, you can delete it. -->
<!--The package will still be able to load normally but the previous layout information will be lost and the designer will automatically re-arrange the elements on the design surface.-->
<Objects
Version="sql11">
<!--Each node below will contain properties that do not affect runtime behavior.-->
</Objects>]]></DTS:DesignTimeProperties>
</DTS:Executable>
由于我使用 SQL 2012 创建 dtsx 文件,我知道这是一个 2012 包。但是,根据这个网页,
http://www.techbrothersit.com/2014/09/ssis-how-to-find-version-of-ssis.html
PackageFormatVersion 为 6 表示 2012 包。
我无权访问服务器以查看每个 dtexec.exe 文件的版本。我希望尽快得到这些信息。
如上所述,当我在 80 上使用相同的包运行相同的批处理文件时,它可以工作:
----------------------------------------------------------------
Output of messages for workload object C1_GHG1_TEST/GHG1999I.11/MAIN
Start date Tue Oct 06 22:21:08 2015
----------------------------------------------------------------
C:\Users\MyServerId>ECHO before dtexe!
before dtexe!
C:\Users\MyServerId>REM "DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
C:\Users\MyServerId>"D:\SQL2012\110\DTS\Binn\DTExec.exe" /FILE "E:\SSIS\MyAppName\Packages\Empty2012Package.dtsx"
Microsoft (R) SQL Server Execute Package Utility
Version 11.0.5058.0 for 64-bit
Copyright (C) Microsoft Corporation. All rights reserved.
Started: 10:21:08 PM
DTExec: The package execution returned DTSER_SUCCESS (0).
Started: 10:21:08 PM
Finished: 10:21:08 PM
Elapsed: 0.203 seconds
C:\Users\MyServerId>SET RESULT=0
C:\Users\MyServerId>ECHO RESULT AFTER DTEXEC=0
RESULT AFTER DTEXEC=0
C:\Users\MyServerId>exit /B 0
关于可能导致此错误的任何想法?我认为这是服务器 SQL Server 设置问题,而不是我可以控制的问题。
你的想法?
更新
问题与安全权限有关。当我们尝试在 CA Scheduler udner MyServiceID 中运行作业时,有权访问该框的管理员随后检查了事件日志并发现了此错误:
用户在这台机器上没有被授予请求的登录类型。
此外,当本地管理员组中的用户远程访问此服务器并启动相同的批处理文件时,作业会成功运行。
根据这个链接,
https://technet.microsoft.com/en-us/library/cc732593(v=ws.10).aspx
可以通过授予“允许用户本地登录”权限来解决该错误。用户已被授予“允许批量登录”权限。当我从命令行执行“net user MyServiceId”命令时,我还看到该 ID 一直处于活动状态,并且始终允许在所有工作站上使用。
当我请求授予“允许用户本地登录”权限时,显然即使是“管理员”也无法授予此权限,因为组策略不允许这样做。因为这是发生这种情况的唯一服务器,所以我想知道假设所有服务器共享相同的组策略,这台服务器有什么不同。我们注意到的一件事是 dtsx 文件上的 OWNER 属性不是 MyServiceId 并且在环境中。我无权改变这一点,但我不认为就是这样。 MyServiceAccount 可以完全控制批处理文件和包所在的文件夹。
更新 2 由于现在这显然是一个安全问题,如果我在陈述已知事实后尝试陈述问题,也许会有所帮助:
- MyServiceId 对 SSIS 包所在的本地文件夹 E:\SSIS\MyAppName\Packages\ 具有执行权限
- MyServiceId 对 DTEXEC 所在的本地文件夹 D:\SQL2012\110\DTS\Binn\ 具有执行权限
- MyServiceId 在服务器上具有 LogOn As Batch 权限。
- MyServiceId 是所有服务器和工作站都允许的活动帐户
问题: 鉴于调用 DTEXEC 将包路径作为参数传递的简单的一行批处理文件,是什么导致了我得到的错误?我可以寻找哪些额外的东西? Sicne“允许用户在本地登录”从未在其他服务器上设置,这台服务器上可能会导致此错误的不同之处:
The user has not been granted the requested logon type at this machine.
dtsx 文件的 OWNER 属性的值是否相关?
更新 3 调用进程名称:C:\Windows\System32\LSASS.exe
这是提示吗?
更新 4
在生产环境中,服务 ID 以网络登录类型 3 执行,这是交互式的。在 9 上,它给了我们这个错误,它以 2 的登录类型执行,它是交互式的。 (我们没有为 9 上的 uyser 开启“允许本地登录”的选项。这是禁止的。
在同一域的两台不同机器上运行相同 ID 以作为不同用户类型运行的原因是什么?
【问题讨论】:
-
80服务器(成功)和9(失败)服务器上调用批处理文件的是什么用户?您究竟是如何调用这些批处理脚本的?我的猜测是权限,顺便说一句
-
在这两种情况下都使用了相同的服务。我使用 CA WA Scheduler (ESP) 来调用作业。
-
lsass 是登录和身份验证的一部分。我看到你对
assuming that all serevrs (sic) share the same Group Policy不了解你的组织的评论,但这闻起来很像它不是同一个 GPO -
好吧,我们确实在生产服务器上验证了,在与混乱的服务器 9 位于同一域的生产服务器上,未授予“允许本地登录”权限。谢谢
-
据我了解,有全球/企业范围的政策,但也有特定于机器的政策
标签: ssis sql-server-2012