No your theory is wrong.
Dirty pages can be written to disc even if the transaction is not yet committed. However it is ensured that they cannot be written before the last transaction log entry that modified the page has been written to disc.
The transaction log records do contain sufficient information both for redo and undo (except for in tempdb
where only undo is necessary). If you decide to rollback the transaction then nothing is deleted from the log. Instead compensation log records are written to the log indicating this.
The mdf and ldf files display the last date and time the SQL Server opened the file in question. This is most likely to be the time SQL Server was last restarted.
There is no reason to force SQL Server to flush to disk, it does that automatically during its checkpoint mechanism.
Even if the entire machine crashed during the middle of a write-to-disk operation, when SQL Server is restarted it will run through the log file, rolling forward and backward any operations that were not fully committed to the .mdf file. This is one of the primary tenets of an atomic, consistent, isolated and durable database server.
If you want to manually force a checkpoint operation, you can execute the following command in SQL Server Management Studio, or SQLCMD, etc:
CHECKPOINT
For further information on the CHECKPOINT
command, see http://technet.microsoft.com/en-us/library/ms188748.aspx
Regarding your statement at the beginning of your question that you backup the database and not the log file, if your data is business-critical you should enable full recovery on the database, and ensure your log file is backed up several times a day (at least). Backing up the log file assures that you can restore the database to a given point-in-time (most likely the point at which you last performed a log backup). Depending on your business requirements for recovery point and recovery time, you may want to backup the log file as often as every 5 minutes!
For further information on how to correctly implement business-critical backup for SQL Server see http://technet.microsoft.com/en-us/library/hh393536.aspx
Best Answer
Unfortunately there are a number of errors in the answers so far with regard to how COMMIT works, so I'll add another one. See How It Works: Bob Dorr's SQL Server I/O Presentation for details and SQL Server 2000 I/O Basics. Here is how it works:
All fully logged data writes (changes) occur in the exactly following sequence (see Understanding How SQL Server executes a Query: Writing Data):
A COMMIT does the following
A CHECKPOINT does the following (simplified), see How do checkpoints work and what gets logged:
Writes work differently for minimally logged operations, see Operations That Can Be Minimally Logged. Roughly the minimally logged operations act as following (simplified):