Sql-server – SQL Server how to get around the transaction log filling up when updating a column to an int

sql serversql-server-2005transaction-log

I have a SQL Server 2005 table called BRITTNEY_SPEARS_MARRIAGES and it has the following columns:

MarrigeId tinyint, 
HusbandName varchar(500),
MarrigeLength int

Now I have another table BRITTNEY_SPEARS_MARRIAGE_STORIES

StoryId int, 
MarriageId tinyint, 
StoryText nvarchar(max)

The problem is we want to update MarrigeId column to an int from a tinyint. We just feel that Brittney is going to have lots of marriages before everything is said and done.

Now the BRITTNEY_SPEARS_MARRIAGE_STORIES table has 18 million rows in it (hey the girl has some issues) so when we go to do the update the transaction log fills up and our SQL Server box dies.

How can we get around this?

Is there anyway to say "Hey SQL Server I'm going to update this column and make it bigger. Trust me on this SQL Server. Please don't fill up the transaction log while you attempt to validate everything?"

Best Answer

There's no way to tell SQL Server not to use the transaction log.

What you can do is set the recovery model of the database to SIMPLE, which will overwrite old log entries as space is needed. You should not do this on your production server, however, because you won't be able to do certain types of restores, such as point-in-time restores.

Alternatively, you can set your transaction log file to be larger -- as an unscientific rule of thumb I'd make sure that either A) your transaction log has at least about 1.5x more free space than the size of your table or B) that your transaction log can auto-grow to a drive which has at least about this amount of disk space free.

You can free transaction log space by backing up the log. If you don't care about the log contents, throw the file away. A shortcut for this is BACKUP LOG <Your Database Name> TO DISK = 'NUL:'. Again, don't do this on a production server unless you are absolutely sure you understand the implications.

Another thing to be careful of (though it's not entirely germane to your question) is to make sure the table you're expanding has a clustered index defined on it. If it does not, the table could incur a very large amount of heap fragmentation, and potentially become needlessly large on a change like this.

Related Question