This is not a direct answer to your question, but there are some articles that you would benefit from reading them (in case you didn't find them first :-) ). They are about loading lots of data using bcp/bulk copy. I've read them all and I didn't find anything detailed regarding KILOBYTES_PER_BATCH, they're all using ROWS_PER_BATCH, but I'm sure you will find other useful information. - [Load 1TB in less than 1 hour][1] (from SQL CAT team) - list of advices from here (quote): - Run as many load processes as you have available CPUs. If you have 32 CPUs, run 32 parallel loads. If you have 8 CPUs, run 8 parallel loads. - If you have control over the creation of your input files, make them of a size that is evenly divisible by the number of load threads you want to run in parallel. Also make sure all records belong to one partition if you want to use the switch partition strategy. - Use BULK insert instead of BCP if you are running the process on the SQL Server machine. - Use table partitioning to gain another 8-10%, but only if your input files are GUARANTEED to match your partitioning function, meaning that all records in one file must be in the same partition. - Use TABLOCK to avoid row at a time locking. - Use ROWS PER BATCH = 2500, or something near this if you are importing multiple streams into one table. - [Top 10 Best Practices for Building a Large Scale Relational Data Warehouse][2] (from SQL CAT team) - advices (quote): - Use SIMPLE or BULK LOGGED recovery model during the initial data load. - Create the partitioned fact table with the Clustered index. - Create non-indexed staging tables for each partition, and separate source data files for populating each partition. - Populate the staging tables in parallel (Use multiple BULK INSERT, BCP or SSIS tasks) - Build a clustered index on each staging table, then create appropriate CHECK constraints. - SWITCH all partitions into the partitioned table. - Build non-clustered indexes on the partitioned table. - [The Data Loading Performance Guide][3] (from SQL CAT team) - [Loading Bulk Data into a Partitioned Table - SQL Server Best Practices Article ][4] (Technet article) - [SQL Server 2000 Incremental Bulk Load Case Study][5] (Technet article) - [Lessons Learned and Findings from a Large Fast-Track POC][6] (from SQL CAT team) - [Performance Tuning Tips for SQL Server BCP][7] (By Brad McGehee) - [Performance Impact: Finding the Most Optimal Batch Size ][8] (By Linchi Shea) and the obvious MSDN references: - [Managing Batches for Bulk Import][9] - [Managing Bulk Copy Batch Sizes][10] - [Bulk Copy Performance Considerations][11] - [Guidelines for Optimizing Bulk Import][12] - [Optimizing Bulk Import Performance][13] In my personal experience, I succeeded to make a fast data load using parallel load and testing with several batch sizes. I guess that only personal testing will suit you. Hopefully you will find some good advices in the references. [1]: http://blogs.msdn.com/b/sqlcat/archive/2006/05/19/602142.aspx [2]: http://sqlcat.com/sqlcat/b/top10lists/archive/2008/02/06/top-10-best-practices-for-building-a-large-scale-relational-data-warehouse.aspx [3]: http://technet.microsoft.com/en-us/library/dd425070%28SQL.100%29.aspx [4]: http://technet.microsoft.com/en-us/library/cc966380.aspx [5]: http://technet.microsoft.com/en-us/library/cc917716.aspx [6]: http://sqlcat.com/sqlcat/b/technicalnotes/archive/2011/01/27/lessons-learned-and-findings-from-a-large-fast-track-poc.aspx [7]: http://www.sql-server-performance.com/2007/bcp/ [8]: http://sqlblog.com/blogs/linchi_shea/archive/2007/08/23/performance-impact-finding-the-most-optimal-batch-size.aspx [9]: http://msdn.microsoft.com/en-us/library/ms188267.aspx [10]: http://msdn.microsoft.com/en-us/library/ms130771.aspx [11]: http://msdn.microsoft.com/en-us/library/aa173843 [12]: http://msdn.microsoft.com/en-us/library/ms177445.aspx [13]: http://msdn.microsoft.com/en-us/library/ms190421.aspx