SSIS Data Flow Task hangs on excecution of Pre-excecute phase

Question

I have a Data Flow Task that is hanging on excecution.
The flow is simple, makes two queries to different tables (Both with a couple of joins), then sorts and merges th

Answer 1

I know this is old, but i just found a link about this that may help. I personally am using a view to just export data to an external data base, and the data validation is taking an excessive amount of time validating the view.

https://connect.microsoft.com/SQLServer/feedback/details/258901/ssis-views-as-data-source-very-poor-performance-or-ssis-hangs

the important part of this is Microsoft's answer

Posted by Microsoft on 4/28/2008 at 2:45 PM

This is a know issue and the result of the current design.

There are 2 ways to pull data from a view in OLE DB source:

1. Use "Table or view" access method

2. Use "SQL command" access method, and enter a query "select * from ***"

A different execution plan is generated in the two approaches.

The one used in the former is not as efficient as the latter.

If you hit the performance issue when going with the first approach, you can switch to the second approach as a work around.

We have also blogged this issue - >http://blogs.msdn.com/sqlperf/archive/2007/04/29/set-up-ole-db-source-to-read-from-view-efficiently.aspx.

Since this is a 'By Design' item and we believe that there is a work around we will not be providing any change at this time. As a result we are closing the case associated with your submission. If you disagree, please feel free to re-submit.

We appreciate your time, effort, and support of SSIS.

Answer 2

I finally got it. It turns out there is an issue with the validation, but not only SSIS elements go through that validation, as stated in the fourth failed solution of the question. The CONNECTIONS also get validated and have their own Delay Validation property, which needs to be set to true. After that the excecution time went from 40+ mins or no running to less than a minute for the full process (This is just one step of a much bigger process) I hope people with this same problem can find this solution easily because there's a lot of people running into this problem and nearly no solutions posted online.

In a nutshell: Check that all your elements involved in the task, including the DB connections have Delay Verification Property set to True.

Answer 3

Fixed my problem by changing the Data access mode to SQL Command and pasting my view into the SQL command text in the OLE DB Source.

Answer 4

Hope this helps someone. I was trying to use this OLE DB Source to execute a SP with a param. I didn't need it to return anything, so I left that part out. But it wouldn't let me, it yelled 'no column information was returned by the sql '. So configured a dummy sql statement in my SP, which I set to never true. But it never got that column as output and the job just hung on pre-execution phase. So I changed that test to always be true, it returned the column, and presto. I do nothing with the column, but I guess it's needed there.

Answer 5

I ran into the same issue a few minutes ago and the suggestions above didn't work for me (delay validation = true seems to be the go to answer). We've recently discovered some issues with parameter sniffing and once I remedied that in my stored procedures, my package ran in < 1 min. Consider checking your stored procedures to see if this might be the cause.

Answer 6

This problem is still active with SQL Server 2012/2014.

None of the solutions mentioned above helped. In fact, nothing changed delaying validation, changing the configuration of the OLD DB Destination or OLE DB Connection.

Reading the thread from this link: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/35a484c7-4850-4f86-b14a-5dfb50491ab2/long-duration-preexecute-phase?forum=sqlintegrationservices

it is suggested that the problem is with the execution plan.

This was true for my case and adding a condition 1=1 to my OLE DB Source configuration forced SQL server to generate a new execution plan that fixed the issue for me.