SQL Server - Alter table vs drop and create

Question

Our database is SQL Server 2008 R2. We have some tables that have some varchar(500) columns that I want to switch to datetime2 or bigint. I can guarantee all the data in the columns to be switched are valid for the proper type. The column changes do affect indexes, but not keys.

While discussing with colleagues, we have come to two ways to approach the problem. Both these would be done through T-Sql scripts.

1. Create a temp table via select into, drop the old table and recreate the table with the proper datatypes. Recreate the indexes.
2. Alter the current table/data types via ALTER TABLE x ALTER COLUMN Y datetime2 and then rebuild or recreate the indexes.

Because I am confident the data will convert cleanly, I am leaning towards #2. My colleague and a DBA friend prefer #1 but my colleague can't remember why they trained him that way. The DBA friend is on vacation so I didn't ask him why.

Can someone provide insight on which option they think is better and why? Ultimately it is my decision and I am wondering why #1 would be preferred over #2?

Answer 1

I recently did this in my organization wherein we wanted to handle a table with billion + rows.

All the credit for the idea goes to Aaron Bertrand and is from his blog post Trick Shots : Schema Switch-A-Roo

Test below process on a small table and get your self comfortable before doing it in PROD.

1. create 2 schemas fake and shadow with authorization dbo.
2. Create a table with the columns and data types you want in shadow schema e.g. create table shadow.Correct_Table ...
3. Insert the data and create all the indexes that the original table has in the shadow schema table.
4. This way you have identical copies of table with data and indexes but they are in different schemas (logically separated).
5. Once done update stats on the table with shadow schema.

6. Switch the schemas (This is a metadata operation and is extremely fast)

   --- ALTER SCHEMA TargetSchema TRANSFER SourceSchema.TableName; 
   
   BEGIN TRANSACTION;
   
     ALTER SCHEMA fake TRANSFER     dbo.original_table;
     ALTER SCHEMA dbo  TRANSFER  shadow.Correct_Table;
   
   COMMIT TRANSACTION;
   
   ALTER SCHEMA shadow TRANSFER fake.Lookup;
   

7. Do a final check to see if everything went as planned. You should do a select count(1) from dbo.Correct_table

8. Once step 7 is confirmed and you are happy, drop the shadow.table, shadow schema and fake schema as clean up.

Answer 2

Here is the way I see it.

Pros for #1

• Because you are using a separate table your production table stays in use until you are done. No locks on it (beyond those needed to read the data).
• This also goes with what @AaronBertrand said: you can do it piecemeal, test etc
• You can change column order at need

Pros for #2

• It is an all or nothing operation. There is no chance you are going to lose data that got inserted/modified in the original table while you weren't looking.
• Any permissions that are specifically assigned to the object are kept. If you use #1 you have to make sure you script and apply these.

All of that being said I will typically use #2 for small tables or when I can get an outage (always take a backup before hand though) and #1 if I can't get as large an outage or I have to re-arrange the column order etc. If I'm going to do #1 I'll typically generate the script through the GUI and then review it carefully before running it.

Answer 3

Be careful with the drop and recreate option: this can leave sys.depends in an odd state and cause problems for cached plans where the ordering or type of columns is changing.

You will also need to take steps to maintain any object level permissions, as these will be lost in the DROP and not automatically recreated with the subsequent CREATE.

ALTER TABLE is the cleaner option IMO, but make sure you test thoroughly before doing it in production both to make sure all is well afterwards and to make sure you know how long the operations will take (over a table with many rows this could be quite a time).

Answer 4

My colleague ended up finding an article about what he was referring to: http://www.nigelrivett.net/SQLAdmin/AlterTableProblems.html. After reading this and realizing our year end reporting was coming up, we decided to not make the alterations to the column types and will revisit this in the next couple months. I think after reading the article, I may just go with the Drop/Create method.

Thanks to everyone for their feedback on this. Many interesting approaches to consider when we decide to move forward.