"It depends"
If you add a column that does not require adding data to the rows, then it can be quite quick.
For example, adding an int or char requires physical row movements. Adding a nullable varchar with no default shouldn't (unless the NULL bitmap needs to expand)
You need to try it on a restored copy of production to get an estimate
Creating a new table, copying, renaming may take longer if you have to re-add indexes and keys on a billion row table.
I have changed billion row tables that took a few second to add a nullable column.
Did I say to take a backup first?
I think the approach depends on whether the application(s) are live or if you are still testing.
For tables, the safest approach is to create a synonym using the new name. This way you can change the app(s) one at a time (or even one reference at a time), without having to change all of them at once. You don't have to drop the synonym and rename the table until you are confident you have all the changes in place.
CREATE SYNONYM dbo.NewName FOR dbo.OldName;
-- change app to point to dbo.NewName;
-- once all of your changes have been tested:
BEGIN TRANSACTION;
DROP SYNONYM dbo.NewName;
EXEC sp_rename N'dbo.OldName', N'NewName', N'OBJECT';
COMMIT TRANSACTION;
For columns, it is a little trickier. You can create synonyms that point to a view instead, but not all views will necessarily be updatable depending on the base table. As a simple example:
CREATE VIEW dbo.vNewName
AS
SELECT Column1, NewColumnName = OldColumnName
FROM dbo.OldName;
CREATE SYNONYM dbo.NewName FOR dbo.vNewName;
Then like above, when you have changed all references to columns and the new table name, simply:
BEGIN TRANSACTION;
DROP SYNONYM dbo.NewName;
DROP VIEW dbo.vNewName;
EXEC sp_rename N'dbo.OldName', N'NewName', N'OBJECT';
EXEC sp_rename N'dbo.NewName.OldColumnName', N'NewColumnName', N'COLUMN';
COMMIT TRANSACTION;
If the application is not live and is still going through testing, just rename the columns and fix what breaks after a global search and replace (or smart refactor using SSDT, RedGate, etc) through app code / procedures etc.
If the application is live, you will need to step a little more gingerly.
Best Answer
Turns out that if you alter a column it takes on the
ANSI_PADDING
setting as of theALTER
command. Here is a quick test I did.I also threw together a quick script to generate the alter commands (note I'm altering them to be the same data type and size as before). I am not however taking into account any type of constraints, indexes or keys that are going to get in the way. You will need to handle those columns on a one by one basis probably by dropping the index/constraint/key etc that is in the way, doing the alter, then re-creating the needed index/constraint/key etc. I also didn't have time to do a lot of testing on this so I suggest running the alters one or two at a time and making sure everything stays the same except the
ANSI_PADDING
setting.