• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 592
  • Last Modified:

SSIS performance: SSMS Import Data vs BIDS Execute Package

I'm working on an ETL project from SQL 2005 to SQL 2012. I'm starting with a source table that has about 450,000 records. Using the SSMS Import Data Wizard, I specified the source SQL Query as
SELECT Contact_ID, Contact_TS, Sex, Date_Of_Birth FROM Contacts. Contact_TS is a timestamp column which is translated as binary(8) for the target table. The target table is created new with a name of Query. This package runs in just a few seconds.

I then created target tables on the target database for Contacts and other tables including some basic foreign keys, which I disabled using EXEC sp_msforeachtable "ALTER TABLE ? NOCHECK CONSTRAINT all". The target table does have a primary key on Contact_ID but it is not an IDENTITY.

I used BIDS to create a new package which uses the same source query but which inserts to the target Contacts table. When I use the Execute Package Utility to run this package, it takes over 6 minutes to process the exact same number of records. I run it from my development computer, not from the SQL Server machine.

Can someone explain why using Execute Package Utility in this way causes it to take more than 30 times as long? What are my options to make this run more quickly.

For production use, I don't expect to use the Execute Package Utility. I expect it to be scheduled or run from some .NET application or process. But I do need to know that I can get sufficient performance with my packages.

Thanks in advance.
0
ZekeLA
Asked:
ZekeLA
  • 4
  • 4
2 Solutions
 
ValentinoVBI ConsultantCommented:
" The target table is created new with a name of Query."

Where was that table created?  In the same database as the source?  On the same server? Or on the same target server as the one you're targeting with your BIDS package?
0
 
ZekeLAAuthor Commented:
The target table is created on the target database by the package as expected. Since my original post, I've learned how to create and deploy the package from SSDT (aka BIDS) to the target server's Integration Services Catalogs. When I run the package from there, It takes about 60 seconds which is acceptable. I've also eliminated all primary and foreign keys.

The sixty seconds is probably acceptable for my purposes but I still don't know what the Data Import wizard is doing (or not doing) that makes it an order or two faster than executing my deployed package project.
0
 
ValentinoVBI ConsultantCommented:
What you should take into consideration is that when you launch a package from your PC, either through BIDS or Execute Package Utility, it actually runs on your PC!  So if you've got a source and a destination server, data will travel over the network from the source server to your PC and back again to the destination server.  That probably explains some of the additional delay you've been seeing.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
ZekeLAAuthor Commented:
OK. That addresses the original problem and we can leave it at that.

But running a package from the target DB's Integration Services Catalog still takes an order of magnitude longer than using the Import Data Wizard:

Package = 92.985 seconds
Wizard = 5 seconds

Any thoughts as to what causes the extreme differences?
0
 
ValentinoVBI ConsultantCommented:
That's a bit difficult to say, too many possibilities.

Perhaps the following is interesting to try out: the last option screen in the Import Data Wizard has got a checkbox that allows you to save the SSIS package which gets generated.  You could save that and then execute it from BIDS or from the server and compare execution speed.  You can also have a closer look at it in BIDS to see how the generated package works, perhaps that explains some difference as well, compared to the one you've implemented?
0
 
ZekeLAAuthor Commented:
Thanks ValentinoV. I did as you suggested and found that the Wizard creates the package using the Fast Load Data Access Mode. Since that's a bulk insert, it is much faster. I'll have to see if I can use that option for my actual package. I'm only appending records from the source query to the target table so it may work. Even if it doesn't, I know why there's a performance difference.
0
 
ValentinoVBI ConsultantCommented:
Glad to hear I could help :)
0
 
ZekeLAAuthor Commented:
Expert told me how to find the answer. My response includes the results of that investigation.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now