SSIS:Best Practices

Running SSIS packages from the Command Line

BP_XXSS_001
For more efficient memory usage, run your saved SSIS package from the command line instead of running directly from visual studio. Example: dtexec.exe /F "c:\fullpath\Package.dtsx" /Rep EWPD > "OptionalCreateLog.log" tests have shown memory usage to be up to 66% less. Running from visual studio will start devenv and DtsDebugHost processes in your Task Manager, whereas command line processing will start DTEXEC.

Update to the latest version.

BP_XXSS_002
We always recommend users use the most current build (version), which may contain new or improved features, code fixes, or updated functionality. Melissa data provides many ways to ensure you keep your components to the latest version. Update details here

MatchUp: Optimize Your Matchcode

BP_MUXX_001
Applying certain optimizations, or configuring the matchcode settings, can greatly reduce processing time without sacrificing accuracy. For a complete discussion see the Matchcodes > Optimization section of the MatchUp SSIS WebHelp Best Practices:MatchUp API#Optimizing Speed: Matchcodes

Leverage SSIS

BP_XXSS_003
One of the nice things about SSIS is that you can use a canned component (like Conditional split) to separate source records by zipcode into different streams and run the jobs separately. If you have the hardware, this may allow you to take advantage of multi-threading of the processor and multi-instance of the components.

Limit Pass Through Fields

BP_XXSS_004
The greater the number of Pass-through fields required will slow down the process. You should pass a unique record identifier as a passthru, then using the source record identifier, join the results with the source fields not used outside the component.

Run on a local instance

BP_XXSS_005
VERY IMPORTANT - We are not convinced that VM memory management can be replicated as well as a physical machine - at least not without advanced configuration on your part and high performance hardware hosting the VM - which is beyond the scope of our supporting the performance of the component. Below are some links to not unrelated concerns with VM performance...

http://www.sqlsolutions.com/articles/articles/SQL_Server_and_VMware-A_Potentially_Fatal_Combination.htm
http://stackoverflow.com/questions/149318/virtualized-sql-server-why-not
http://virtualization.info/en/news/2008/12/running-sql-server-in-virtual-machine.html
http://www.hanselman.com/blog/VirtualMachineCPUPerformance.aspx
http://stackoverflow.com/questions/2678119/is-there-a-reason-why-ssis-significantly-slows-down-after-a-few-minutes

These are not meant as a deterrent, only to point out the potential issue.

==