If you haven't had a chance to dig into the transaction log yet, allow me to get your feet wet. The following is a basic regurgitation of what I feel is important to know when dealing with the transaction log. Feel free to point out things that you feel I should have addressed and in my next rendition I will be sure to add them. If you think that something doesn't make sense or is inaccurate, please let me know so that I don't spread misconceptions and bad karma.
Every transaction that modifies a database is logged in the transaction log. This includes inserts, updates, deletes, and create/alter/drop tables. The transaction log stores a before and after copy of the data that was modified. When a transaction completes it is not guaranteed to be written to disk, instead it just means that the transaction has been completely logged to the transaction log. In order for data to be written to disk a checkpoint must occur. A checkpoint occurs where there are enough dirty pages in memory to reach the recovery interval. The recovery interval is the length in time in which it would take to roll all of the transactions forward which have not been written to the data file yet. By default SQL Server 2000 automatically manages the recovery interval and uses a small amount of time. When a checkpoint occurs it will write all of the dirty pages in memory to disk that are not currently taking part in an active transaction. On some systems you may incur a performance penalty if this happens too frequently.
If left unattended the transaction log can grow to be quite large, this is especially true on systems in which there are lots of writes. The ideal way to manage the transaction log is to make regular full backups as well as transaction log backups in between the full backups. During the backup the transaction log will get truncated except for all of the active portions (have not been written to the data file). It is also possibly to manually truncate the transaction log using BACKUP LOG [DATABASE NAME] WITH TRUNCATE_ONLY. When this happens you will only be able to restore from the last full backup. This is similar to using the Simple recovery model.
The transaction log has three modes of operation, Full, Bulk-Logged, and Simple. These are referred to as Recovery Models. When using Full Recovery you have the ability to restore the database to any point in time. This is because all transactions are logged to the transaction log. This also means that you need to make sure you perform regular backups. If you perform a lot of high volume statements then it may be beneficial for you to use the Bulk-Logged Recovery model. Using this model it won't log full details about the bulk operations. You will want to make sure you perform regular backups in order to minimize possible loss of data in case of system failure. The final option is Simple Recovery. Using this model once a checkpoint occurs the data that has been committed is removed from the transaction log. Using this option only allows us to restore up to the latest full backup.
References: