I checked the BOL and I found :
The amount of logging for SELECT...INTO depends on the recovery model in effect for the database. Under the simple recovery model or bulk-logged recovery model, bulk operations are minimally logged. With minimal logging, using the SELECT… INTO statement can be more efficient than creating a table and then populating the table with an INSERT statement.
So I think populating a new table and then truncating the other might be more efficient when log size is considered.
I agree. Just to be clear for folks that may think of doing it, don't ever shift from FULL recovery to SIMPLE recovery for the sake of archiving data because it will break the log chain for backups. It's ok to shift from FULL recovery to the BULK-LOGGED recovery, though.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is usually not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs