Best practices in making schema changes to large production databases

Question

We occasionally have to make schema changes to mysql or mssql based production databases. I am struck by what an ordeal this usually is. The technicians make their changes using the browsers of the respective platforms (e.g. Sql server Management Studio) and I observer several problems with this process:

1. Each change to the database takes a considerable amount of time resulting in unhappy technicians and long database downtimes.
2. The technicians do not know the progress being made by the database engine in making the change. The problem arises because the technician doesn't know in the middle of the process if there has been some kind of failure when trying to make the change or its just that it takes a long time to execute this change.

Are there better ways to do this? Is the altering of tables via a command line script considered best practice? Are there ways to monitor progress when executing a schema change?

Thank you,

Elliott

Answer 1

Elliott, from your comments it looks like you are using Customer Support rather than Support Developers to make your changes to Database. Correct me if i am wrong. Incase you are using Support Developer they should be running scripts to do the changes it always is best way. And by reading your question it does look like your DB has hughe number of records. To get the script you can use Microsoft VisualStudio DB edition. It will compare the DB source project and the DB you want to deploy it to. YOu can then review the script created and run it on the server.

On the question of changes taking long time as i said depends on the amount of data and the schema change you are doing. To prevent the long down time you will need to find what is the time which is least affected to the customers and do it during that time. Incase you are 24x7 system you will have to schedule downtime. Also, try to study the pattern of your changes. Is there a possiblity that you can group all the changes to single relase so that you have less downtime. Also, see why you are having so many DB changes is there any thing you can do in design to mitigate the change. For ex. There might be Indexes which are being re-built every time you do a schema change. May be you can disable the index during the schema change. Finish the schema change and then schedule the Index rebuild using a db job

On your question about monitoring the schema change i dont think there is any visual indicator which says this much of that much finished. You just have to wait for the command to finish.

Answer 2

Actually, you can do schema change and keep the database online in production. 1. alter table to add the new column and set default value is null 2. create a SP to update the value in a small piece of chunk data, like 10K 3. alter the table with correct default value