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
    Commented Oct 21, 2013 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
    Commented Oct 21, 2013 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
    Commented Oct 22, 2013 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
    Commented Oct 23, 2013 at 1:44

1 Answer 1


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 and acknowledge you have read our privacy policy.

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