Hello SSIS Forum. I have been working on a performance problem for a few weeks now. Background: I am using BIDS 2005 and SQL Server 2005 (client requirement - no option to upgrade). In the past I built an ETL utility in MS Access 2003 (basically VB and SQL app which is "contained" in an Access "application". I am now replacing this Access based ETL with SSIS. The mission of this SSIS package is to connect to a series of Sybase ASE 15 databases (source data) iteratively and ETL data into a SQL Server 2005 reporting database. Overall my new SSIS package does a good job at replacing it's predecessor (the Access based ETL). As I would expect, SSIS is much faster than my Access based version (on my development machine anyway). The SSIS version completes it's job in about 5min 20sec when run on my development box. On the development box there is no "network" in that all parts of the solution are local except that instead of Sybase ASE 15 I have SQL Anywhere (now iAnywhere) emulating ASE 15. In the past 6 years of working with Sybase and SQL Anywhere I have found the latter a good development surrogate for the former though I note they are at times different. The problem I am having is that when my package is deployed to the customer's test environment performance is much slower. Run time is about 40min which, in and of itself is not a killer but I have since added the final data flows and performance has dropped to 18hrs run time!!!! which is totally unacceptable. Over the past 2 weeks I have done all sorts of troubleshooting. Here are some key notes: The customer servers are all VMs and are all hosted by the same VM host so there is in theory no "network" between the Sybase VM and the SQL Server/SSIS VM much as there is no network between the servers on my single development machine. The VMs are almost identical in performance spec to my dev box. My dev box is actually also a VM (Windows XP VM running in Fusion on MacBook Pro) and my dev environment is lightning fast (IMHO) no problem there... I recently isolated the major part of the 18hrs run time to the two new DFTs added to my package. Both of these (one in particular) retrieve very large amounts of data into staging tables in SQL Server. I have running these queries separate from SSIS and they do seem to be the problem. Literally I am retrieving 100,000 + rows of text data each row of which may be a description of up to 65K. The identical query is run from the old Access version of my ETL and the entire Access version runs on the exact same servers in the customer environment in only 38min (vs 18hrs for SSIS) The customer environment is locked down with lots of security policies that I do not have in my dev box but if that is the culprit I would expect the Access version to also be slow and it is not. Currently I am thinking that the problem may be in the difference between the ODBC driver used by Access vs the OLE-DB driver used by SSIS. Another possibility is that Access works by having a proxy table to the Sybase source and it simply does an "insert into target table A select from Sybase source table B" where table B is a proxy to the Sybase table. It seems to me that in SSIS all that data is being read into "the pipeline" before being written to the target staging table whereas with Access it is inserting to the target as it reads and perhaps uses up less buffer space of some sort. I am experimenting with emulating this by creating a loop in SSIS to read 5000 rows from Sybase and write them to SQL Server before proceeding with the next 5000, etc.. until done. I also thought about trying to create a proxy table in SQL Server and then using an Execute SQL Task making the approach more similar to what is in the Access version. The DFT in this case is very simple it is literally an OLE DB source and an OLE DB Destination with no slow lookups or merges or anything else inbetween. I know that SSIS packages can be slow when the "check publishers revocation certificate" is checked in internet options and I massively boosted performance on my dev box with this setting ages ago. I also tried this on the customer's servers but it made no difference. I have checked all the obvious things I could think of and would appreciate any other suggestions or ideas... Best Regards, - CharlesCharles