Like minimal logging for heap, the database must be set to bulk-logged or simple recovery model
The input data must be sorted in the index key order. Note, it does not require X tablelock or the btree to be empty. SQL Server accomplishes this by acquiring a X range lock. So for example, if you have a btree with values 1, 100, 1001, 100 and now you want to insert 500 rows with the key range from 110 thru 610, the SQL Server does that by acquiring a X range lock between 100 and 1001 and accomplishes the load. The other transactions can access any data that is outside the range (100, 1001)
Here is one example:
Insert into empty BTREE without TABLOCK is minimally logged except for the rows inserted on the first page.
-- minimally logged except for the first page worth of rows
-- Order BY is not necessary. You will only get minimal logging if
-- Optimizer chose to sort the rows before inserting.
-- LOCK: IX at table level
insert into t_ci select * from t_source order by c1
Here is the query plan. Please note that SQL Server chose a SORT operator
Here are logged records. You will notice, that first 7 are fully logged but after that it is minimally logged. When inserting rows into the btree, the page where the first row is to be inserted may have some rows so for this reason each insert is fully logged. Only once it is done with this page, a new page needs to be allocated, it is minimally logged
When I insert data into new range into a non-empty btree from the previous example, I get minimal logging except for the last page. Again, this works with/without TABLOCK
insert into t_newrange values (@i, @i+10000, 'indexkey', 'hello')
select @i= @i + 1
-- minimally logged except for the rows inserted on to the last page.
-- Note, this inserting the data in a new data range.
-- LOCK: X lock on the table.
-- Same logging behavior with/without TABLOCK
insert into t_ci with (TABLOCK) select * from t_newrange order by c1
Here are the log records. You will notice that the first 2 inserts are fully logged. Again, there are fully logged because the two rows go to the existing page and from that point onwards, the rows go to new page and hence minimally logged
In fact, I can load data into this btree concurrently as follows