Bear with me here. I have far more experience with database development than I do administration.....Here's my understanding of transaction logs when a database is in full recovery mode:I know they record all transactions against and modifications to a database, and I know how they fit into a database recovery process. What I'm not grasping is the sizing.If the log is initially sized at 500MB then transactions will begin to fill the file and when I take a log backup, the log is truncated and the transactions are cleared. The file remains at 500MB, right?If log backups don't occur, the log file can fill up and even exceed the 500MB--and the file will grow to whatever size it needs to to accommodate the transactions--could be 50GB or more. In this situation, the log file should be backed up (and that backup be put on a schedule) because that's the right thing to do and it will truncate the log. However, since the file has grown to 50GB in this example, it's likely that a DBCC SHRINKFILE should be run against the log to get it back down in size. However, it can't be sized below what its initial size of 500MB was. Is my understanding correct, and is everything I've written accurate?If so, here's where I'm stuck:Why wouldn't you initially make the transaction log as small as possible and let it grow at its own rate and perform t-log backups, so that it's not backing up a 500MB file that's only partially populated each time? Why must it initially be sized so high?I know there are entire books on transaction log management and I will be reading them (e.g., the one Tony Davis and Gail Shaw wrote), but I was hoping to get an answer to this beforehand so that I had some understanding before getting into it.As always,Thanks!Mike
↧