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.
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.
ASKER
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.
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.
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.
ASKER
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?
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Glad to hear I could help :)
ASKER
Expert told me how to find the answer. My response includes the results of that investigation.
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?