ssis package stuk after 1000 row

Question

ssis package stuk after 1000 row

srikant maurya

Hall of Fame

Points: 3293
More actions
May 3, 2011 at 12:53 am

#239400

Hi All,
I have an SSIS package to import the data from SQL SERVER TABLE . Iworking fine for 900 row(it's take less than 1 min) but when i put more 900 row in table its not processing any row in table even after 10 min.
Log :
Progress: Pre-Execute - 98 percent complete
Progress: Pre-Execute - 100 percent complete
[DTS.Pipeline] Information: Execute phase is beginning.
[Load into Profile [24181]] Information: The final commit for the data insertion has started.
Thanks
Srikant

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply

Phil Parkin SSC Guru Points: 247037 More actions · Answer 1

srikant maurya (5/3/2011)
Hi All,
I have an SSIS package to import the data from SQL SERVER TABLE . Iworking fine for 900 row(it's take less than 1 min) but when i put more 900 row in table its not processing any row in table even after 10 min.
Log :
Progress: Pre-Execute - 98 percent complete
Progress: Pre-Execute - 100 percent complete
[DTS.Pipeline] Information: Execute phase is beginning.
[Load into Profile [24181]] Information: The final commit for the data insertion has started.
Thanks
Srikant

Import from SQL Server ... to what? Another SQL Server table? Why use SSIS for this?

srikant maurya Hall of Fame Points: 3293 More actions · Answer 2

We have many validation rule like phone format, SSN/TIN ,email ...etc. We have done all validation through script task.

Phil Parkin SSC Guru Points: 247037 More actions · Answer 3

Script Task or Script Component?

Does this validation happen as part of the data flow or before it?

srikant maurya Hall of Fame Points: 3293 More actions · Answer 4

Sorry, Script component.

Thanks ,any way i have change the default fastloadmaxinsert property 0 to some value.Now its working with unexpected speed.

chris.stuart SSCarpal Tunnel Points: 4965 More actions · Answer 5

Thats correct:-), check on the destination table on the commit size and rows per batch. This I have found makes a huge difference on the time it takes to complete the loading of data into the destination table.