We've noticed that since deploying Windows 2012/SQL Server 2012, the performance of DTUTIL has decreased. DTUTIL.exe consumes 50% on each of 2 cores on an 8 GB VM. The same syntax against Win 2008 R2/SQL Server 2008 R2 shows almost no impact on a VM with similar specs. Overall, it takes ~90-120 seconds to deploy a package.

We're using 64-bit SQL Server 2012 Enterprise Edition on SP1; the syntax of the command is:

"C:\Program Files\Microsoft SQL Server\110\DTS\Binn\dtutil.exe" /DestS COMPUTER1 /FILE "e:\folder\SSISPackage.dtsx" /COPY "SQL;FOO\BAR\SSISPackage" /QUIET 

We have not yet tried this using the new SSIS approach in 2012. We have validated that the behavior repros across multiple different packages. We've also looked at all of the post-SP1 cumulative updates; they do not appear to address this problem, but we also have not applied them either to rule that out.

Has anyone else encountered/resolved this? Granted, package deployment is not a high frequency action, but we do notice it during our automated deployments.

  • 1
    If you can consistently reproduce this with a small test, I would report the problem on Connect. – Jon Seigel Oct 21 '13 at 17:15
  • 1
    It might be interesting to see whether it's a DTUTIL issue or a change to the base library. I have a PS method, Copy-Package, which you could crib your own version to determine if the performance hit is there. billfellows.blogspot.com/2011/08/… – billinkc Oct 21 '13 at 18:14
  • 1
    Re-reading your question, You have a package created in the 2008 format. Calling the 2008 dtutil to write it into the msdb takes time N and negligible CPU. When you use the 2012 version of dtutil, time is much greater and CPU spikes. What format is the source SSIS package? Have you migrated it to 2012 or is still 2008 (it can remain in the package deployment model vs the new project deployment)? – billinkc Oct 22 '13 at 2:20
  • Thanks for the replies. The source package is in 2008 format; When the package is executed using dtexec, time to 'do nothing' in the package goes from 7 seconds to 90. Logging that package with verbose execution reveals many messages about the need to migrate - will try that out next. Hopefully it's just that, although tha tmeans we have to do dual maintenance of packages to support 2008 and 2012 environments. – JohnW Oct 23 '13 at 1:44

The answer to this is yes, we had to convert the package to SQL 2012 format. For now we keep our packages in SQL 2008 format in source control, and at deploy time migrate the page to 2012 format. Once done, the performance is on par.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.