We have a table A which has an Id column of type INT. There are currently about 900 million rows in the table and growing at 100,000,000 rows a month. We will hit the limits of INT pretty soon at this rate. So I was asked to study the different options to convert the INT to BIGINT for the table. Conditions: (1) The downtime should be the least (2) the method should be 100% reliable and no unknown factors going into the rollout. I did my research and came up with a couple of methods:
(1) ALTER table ALTER COLUMN
Notes: this has been tried and we had a huge server outage. it was awful)
(2) create a new column in the same table. repopulate the column with existing data using a job. modify all the stored procs/business objects to update/insert the new column instead of the old one. Drop the old column. rename the new column back to what it was ( or leave it as is). Recreate the indexes/FK constraints with the new column instead of the old column.
Notes: Requires lot of Space and consumes time. Also, drop column will take lot o ftime.
(3) create a new table B with BIGINT datatype. BCP the data from A into B. create all the indexes. drop the old tables. rename the new table to the old one.
I am suggesting method 3 as it requires least number of operations => less changes (and less places to) of screw up and less complicated.
If anyone else who has done this before can provide some feedback/do's and dont's etc I would apprecaite it. Please keep the table size in mind.
our PROD server env:
Windows 2003 Data Center Edition, 32 64 bit processors, SQL 2000 x64 edition, 64 GB RAM and DB size = 4 TB. The 2 tables in question about couple of gigs each.
***********************
Dinakar Nethi
Life is short. Enjoy it.
***********************
***********************
Dinakar Nethi
Life is short. Enjoy it.
***********************
http://weblogs.sqlteam.com/dinakar/