Ttdfjt

I recently added a NULL-able bit column to a table which has close to 500 million rows. There's not a default on the column, however all inserts are specifying a value of 0 or 1, and I ran a one-time routine to assign 0 or 1 to all existing rows (updating the rows in small batches). Every row should now have a 0 or 1 in that column.

I want to make the bit column non-nullable however when I tried doing so via ALTER TABLE t1 ALTER COLUMN c1 bit not null, it started running for 3 minutes and I stopped it because it was blocking all reads to the table and I suspected it was going to take a long time to complete. It's possible it wouldn't take too long but I couldn't risk too much unavailability. The rollback itself took 6 minutes.

Do you have any suggestions on how I can make the column non-nullable without it taking potentially hours to complete? Additionally is there any way to estimate how long the ALTER TABLE ALTER COLUMN statement I started and then cancelled would take to complete?

I am using SQL Server 2017 Web Edition.

Instead of changing the column definition you could add a CHECK CONSTRAINT that doesn't allow NULLs for that column. The table will still need to be scanned but it won't need to modify every single data page, so it should be a much faster operation. Regrettably, a Sch-M lock will still be held during the operation. One trick is to try to get as much of the table into the buffer pool as possible before attempting to add the constraint. That may reduce the amount of time the Sch-M lock is held.

You can then remove the constraint and change the column definition during your next maintenance window.

If you are on Enterprise Edition (EE) a better strategy might have been to add it as NOT NULL with a default of 0 or 1 (whichever is most common).

This is a metadata-only change in EE. Then update the ones needing to be flipped. This means fewer updates and no need to change the column nullability when finished. - martin-smith

Try copying the data to a new table, then rename it. You have to take care of any constraints and indexes. That's what SSMS table designer is doing when you want to reorder the columns (for example), but you should check the script to see if there is anything that doesn't look right.

During the copying, read access to the source table is not a problem, but if there are any writes they may be blocked or not copied, depending on the isolation level.