Sometimes ( on average once every two weeks ) I am getting the following error message: Code BlockError: 2008-01-15 06:51:02.91 Code: 0xC0047024 Source: DF FACT SC 1 DTS.Pipeline Description: The number of threads required for this pipeline is 98, which is more than the system limit of 64. The pipeline requires too many threads as configured. There are either too many asynchronous outputs, or EngineThreads property is set too high. Split the pipeline into multiple packages, or reduce the value of the EngineThreads property.End Error This is one of the final stages of the ETL, so several other packages are finishing correctly before this package is run. When we restart the complete ETLall other packages are automaticly skipped, and when the ETL arrives to this package it runs without any problems. So my questions are: What does this error message mean? Is this "64"a SSIS settingor a SQL Server setting or a server setting? Can we increase this setting? The number of engine threads is set to 5 ( default ), what is the relation between the engine thread setting and the system limit of 64? Can we safely reduce the engine threads property? What is causing the SSIS package to need 98 engine threads?

Look at the following: http://blogs.conchango.com/jamiethomson/archive/2005/10/02/2227.aspx '...What is causing the SSIS package to need 98 engine threads?...' One could write an essay here, laying out the various possibilities...but no one's gonna do that for you Basically you're running out of memory. Increase it (if you can) or re-arrange your package (probably a particularly resource-hungry dataflow) to be more efficient.

Actually I have the same problem, but every time on 64-bit SQL Server 2005 running on 64-bit Windows Server 2003 R2: "The number of threads required for this pipeline is 419, which is more than the system limit of 64".Where can I change this limit? I have the default EngineThreads equal to 5. I have no problem with 32-bit SQL Server 2005 running on 32-bit Windows Vista. The package in the 32-bit enviroment is executed successfully, I can see in Task Manager that during the package execution about 90-100 threads are running (not 419 as it is in the error message in the 64-bit enviroment), i.e. more than 64. Where can this limit be specified? As far as know a 64-bit Windows does not have the limit of 64 threads. Anysuggestions will be appreciated.

Also, I have noticed in Task Manager that when the package is executed (by DTExec.exe started via aSQL Agent job)the number of threads is at some moment quicklyincreased to some value more than 64 (e.g 70, 80), and then it is terminated. I don't know what sets this weird limit (SQL Agent, some job limitations, etc.) and what terminates the execution, but it seems to benot a problem of the package execution application (DTExec.exe)and I thinkit will have executed if not beingterminated. I found ina SQL Agentjob step properties on the ExecutionOptions tab the option "Maximum concurrent executables" with thevalue '-1' and just tried it and in vain. Any suggestions please?

Did anyone come up with a solution for this problem. I'm getting the same error. The etl package that raises this error has been running on 3 different environments (32bit old and 64bit newer machines) for months. But I'm seeing this error on new 64bit machines. Error: The number of threads required for this pipeline is 76, which is more than the system limit of 64. The pipeline requires too many threads as configured. There are either too many asynchronous outputs, or EngineThreads property is set too high. Split the pipeline into multiple packages, or reduce the value of the EngineThreads property.

InMicrosoft support, wehave had only a handful of customers ever report this issue. Currently it appears a by design limitation, based on the way our threading works on a Dataflow task level, but no one has take the time to fully investigate the details to challenge that.I understand the reason the limitation is imposed on SSIS Dataflow tasks, is because the Dataflow threading model utilized the API WaitForMultipleObjects, and the API itselfhas a hard limit of 64 things that it can wait for (the constant MAXIMUM_WAIT_OBJECTS as noted in the MSDN documentation) I suspect this error is raised for one particular complex dataflow. You can try to get the Execution Plan for that dataflow using the Custom log event called PipelineExecutionPlan to see the execution plan of the failing packages. You have to check the event for that on the suspect dataflow tasks, since the event cannot be inherited from the Package log event level in the logging dialogue.From some emperical testing looking at Execution Plan logs before, there are two kinds of threads used in the Dataflow Task threading model1. Source Threads (connections to source databases)2. Worker Threads (transforms in between asychronous components (Blocking transforms) and connections to destinations)During PreExecute Phase the graph (nodes) in the dataflow are optimized and eachlogical component is designated to a physical thread which will service that designlogic.During this thread planning, if the threads are exceeded, the error will be raised.This error can be raised in PreExecute before the Dataflow beings to execute, during the calculation of how many threads will be needed to accomplish the data flow task design.The only things we found as solutions so far is these three posibilities:{1. If you have set a high EngineThreads set in your Dataflow Task properties - simply low it2. If your design in your dataflow design surface is so complex that it reallyneeds more than 64 thread, you will have to divide the design into smaller units. You could put two dataflows on your control flow, and put half the work in each one. Use a staging table in the RDBMS, or use a Raw destination in the first dataflow to cache the data to disk temporarily, and a Raw Source in the second dataflow to get the cached data in memory again.3. We had a couple customers reports that switching x86 (32-bit) DTExec resolved the problem temporarily for them. Later they redesigned the dataflows (per suggestion 2) but used 32-bit to get it back up and running.}As a side note, I don't think this is related to Memory consumption of SSIS or DTExec.exe. If that were the case, I suspectSSIS would be raising a different error "DTS_E_SCHEDULERTHREADMEMORY = The Data Flow engine scheduler failed to create a thread object because not enough memory is available. This is caused by an out-of-memory condition. "If you find that x64 doesn't work but x86 does work, then if you have a repro of this problem and are willing to call Microsoft support for full investigation, we might be able to pinpoint why 64-bit is different than 32-bit, but it will take some time and patience to debug this further which is expensive I understand.Thanks, JasonHDidn't get enough help here? Submit a case with the Microsoft Customer Support team for deeper investigation - http://support.microsoft.com/select/default.aspx?target=assistance

Same error here. We have a C# procedure that dynamically builds a package to copy the contents of a SQL2008 database to a blank SQL2005 database, for clients that need it. (Also for SQL2005 to SQL2000). This works flawlessly 95% of the time, and fails with this error the rest of the time. The databases that fail are not significantly different in terms of size or schema from those that succeed. Sometimes, waiting a day after getting the error and then re-running the procedure will succeed.