My general question is, say you have a SQL Server 2005 database that's 20G in size and a log file that is empty. If you run a series of updates that touch each table and each row exactly once, will the log file grow to the same size as the database? Or will this depend on other factors?
I'm asking this question because of a database update I'm performing. I have a database used by some proprietary software. Updates are made to every table and every field. The software does not have a verbose output, just a checkbox for "not done"/"done". Because there's no descriptive output, I'm trying to figure out how to tell if it's close to the end.
So, is the log file likely to be the same size as the database when everything has been touched? Or does the log file contain different information that doesn't depend on the database size in this way?
As a rule of thumb the size of log generated for any update is about 1.5x the size of the update. So if you update 20Gb worth of data, you generate 30Gb worth of log.
But there are some things to consider:
Size of log generated does not need necessarily translates to log file size. Under SIMPLE recovery model the log file used can be automatically recycled as soon as the transaction commits (I'm omitting some details for brevity) so 30gb log size can fit in a 1gb file, by continuously recycling the used log. Under FULL and BULK recovery model the log gets similarly recycled when a database log backup is performed. So if you don't update everything in one transaction, your log should recycle and not grow.
Some operations can be minimally logged. TRUNCATE, INSERT BULK being the typical examples. Minimal logging takes a tiny fraction of normal logging.
Right now you should be looking at the log percent used (
DBCC SQLPERF(logspace)) and also monitor if any log growth events are occurring.