Question

I have tables A, B and C in database. I have to put the result obtained from A and B into table C.

Currently, I have an SP that returns the result of the A and B to the C# application. This result will be copied into table C using “System.Data.SqlClient.SqlBulkCopy”. The advanatge is during the insert using bulkcopy, log files are not created.

I want to avoid this extra traffic, by handling the insert in the SP itself. However, it should not be using any log files. Any way to achieve this?

Please share your thoughts.

Volume Of Data: 150,000

Database : SQL Server 2005

The database is in full recovery model; it cannot be changed.. Is SELECT INTO usefull in such scenario?

EDIT: When I use System.Data.SqlClient.SqlBulkCopy, the operation is getting completed in 3 mnutes; in normal insert it takes 30 minutes… This particular operation need not be recovered; however other operations in the database has to be recoveed – hence I cannot change the recovery mode of the whole database.

Thanks

Lijo

Answer 1

You can use SELECT INTO with the BULK_LOGGED recovery model in order minimise the number of records written to the transaction log as described in Example B of the INTO Clause documentation (MSDN):

ALTER DATABASE AdventureWorks2008R2 SET RECOVERY BULK_LOGGED;
GO
-- Put your SELECT INTO statement here
GO
ALTER DATABASE AdventureWorks2008R2 SET RECOVERY FULL;

This is also required for bulk inserts if you wish to have minimal impact on the transaction log as described in Optimizing Bulk Import Performance (MSDN):

For a database under the full recovery model, all row-insert operations that are performed during bulk import are fully logged in the transaction log. For large data imports, this can cause the transaction log to fill rapidly. For bulk-import operations, minimal logging is more efficient than full logging and reduces the possibility that a bulk-import operation will fill the log space. To minimally log a bulk-import operation on a database that normally uses the full recovery model, you can first switch the database to the bulk-logged recovery model. After bulk importing the data, switch the recovery model back to the full recovery model.

(emphasis mine)

I.e. if you don’t already set the database recovery model to BULK_LOGGED before performing a bulk insert then you won’t currently be getting the benefit of minimal transaction logging with bulk insers either and so the transaction log won’t be source of your slowdown. (The SqlBulkCopy class doesn’t do this for you automatically or anything)