October 23, 2017 at 11:33 am
I'm more curious as to whether it really matters or not. SQL 2005 was designed more than a decade ago, and the 2014 version of SQL Server made changes to the cardinality estimator, so I wouldn't be all that surprised that perhaps it simply over-allocated space because the execution plan that was generated by the newer version of SQL Server allocates more space under the right circumstances, which in your case appears to be a batch size in excess of 99. You might be running into some kind of cost threshold that the newer SSIS might be putting in play. Hard to know. Is a couple of hundred meg really a space issue in this day and age? It would eventually get used as more data comes into the database, so I'm not so sure that it will matter unless you are seriously short on disk space.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
October 23, 2017 at 11:47 am
I should have added that I tested this in SQL 2014 and it worked as expected. Little unused space.
It is not so much the space as my understanding.
It does not make sense to me that 3 tables all with different row sizes would all have 99 as the magic max batch size.
Thank you for looking and responding to this post.
October 24, 2017 at 12:13 pm
If you do come up with an answer, please post back. Ya never know what MS is up to at times, and strange things can and do occur, from time to time..
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
Viewing 3 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply