如何阻止 SSIS“打电话回家”
在维护大量 SQL Server Integration Services 2008 R2 包时，我遇到了一个奇怪的问题。
这些包经常使用脚本任务，每个脚本任务都包含用于与某些内部 Web 服务集成的 C# 代码。
编辑这些脚本之一涉及以下步骤：
- 在设计器中选择脚本任务
- 右键单击，选择编辑以显示脚本任务编辑器对话框
- 按编辑脚本按钮
- 等待（刚刚超过）15 秒
- 编辑脚本
- 关闭脚本编辑器
- 按“脚本任务编辑器”对话框上的确定按钮
- 等待（刚刚超过）30 秒
- 对话框消失了
这是等待，以粗体突出显示，这让我感到沮丧。
在此期间没有 CPU 活动、没有磁盘 IO、没有网络流量 - 编辑器似乎被冻结了。
顺便说一句 - 这些计时是可靠的 - 在过去的几天里我使用秒表来测量它们，它们的变化小于我按下秒表上的开始/停止按钮的准确性。
我能找到的唯一线索是 netstat 在暂停期间显示了额外的网络连接：
C:\>netstat -o -b
Active Connections
Proto Local Address Foreign Address State PID
TCP fsis-datam-dev2:3478 akamai-9.fx.net.nz:http SYN_SENT 700
[VSTA.exe]
我当前的假设是延迟是某种超时，如 SSIS（或者可能是 Visual Studio Tools）对于应用程序编辑器）由于某种原因“打电话回家”。相关机器没有互联网连接，因此请求是徒劳的。
Working on maintaining a substantial set of SQL Server Integration Services 2008 R2 packages, I've run into an oddball problem.
These packages make frequent use of Script Tasks, each containing C# code used to integrate with some internal Web Services.
Editing one of those scripts involves these steps:
- Select the Script Task in the designer
- Right click, select Edit to bring up the Script Task Editor dialog
- Press the Edit Script button
- Wait (just over) 15 seconds
- Edit the script
- Close the script editor
- Press the OK button on the Script Task Editor dialog
- Wait (just over) 30 seconds
- Dialog disappears
It's the waiting, highlighted in bold, that's getting me frustrated.
There's no CPU activity, no disk IO, no network traffic during those times - the editor appears to be just frozen.
BTW - those timings are reliable - I've used a stopwatch to measure them over the past couple of days and they vary by less than my accuracy in hitting the start/stop button on the stopwatch.
The only clue I've been able to find is that netstat shows an extra network connection during the pause:
C:\>netstat -o -b
Active Connections
Proto Local Address Foreign Address State PID
TCP fsis-datam-dev2:3478 akamai-9.fx.net.nz:http SYN_SENT 700
[VSTA.exe]
My current hypothesis is that the delays are some kind of timeout as SSIS (or perhaps the Visual Studio Tools for Applications editor) "phones home" for some reason. The machine in question doesn't have internet connectivity, so the requests are in vain.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，您的猜测是正确的，这是一个（相当）众所周知的问题。 .NET 运行时联系人crl.microsoft.com 检查已吊销的证书；如果您的计算机无法访问 Internet，则运行时会等待，直到连接尝试超时，这可能会导致 SSIS 包 启动非常慢，Visual Studio 显然已锁定 常见的修复方法
是仅允许 Internet 访问 crl.microsoft.com，或者使用本地 HOSTS 文件将名称重定向到 127.0.0.1。
Yes, your guess is correct and this is a (fairly) well-known issue. The .NET runtime contacts crl.microsoft.com to check for revoked certificates; if your machine has no internet access then the runtime waits until the connection attempt times out, which can result in SSIS packages starting very slowly, Visual Studio apparently locking up etc.
Common fixes are to allow internet access to crl.microsoft.com only, or to use the local HOSTS file to redirect the name to 127.0.0.1.