Thread: Dbcc Loginfo
04-28-08, 12:31 #1Registered User
- Join Date
- Oct 2007
- Chicago, IL
Unanswered: Dbcc Loginfo
According to this article: http://www.sqlskills.com/blogs/kimbe...hroughput.aspx
8) Check/fix your internal fragmentation. OK, so this is the one that really helped the customer in Turkey. Often, when transaction logs are not pre-allocated and/or when there's been a lot of autogrowths, the transaction log can become internally fragmented. Internally your transaction logs are broken down into smaller more granular chunks called VLFs (Virtual Log Files). The size and number of VLFs you'll have depends largely on the size that the chunk is when it's added to you transaction log. If you add a new chunk to the transaction log which is 20MB (through autogrowth or through manual growth) then the number of VLFs that are added is 4. If you add a chunk which is greater than 64MB but less than or equal to 1GB, you'll add 8 VLFs. If you add more than 1GB then you'll add 16VLFs. In general, most transaction logs will only have 20 or 30 VLFs - even 50 could be reasonable depending on the total size of the transaction log. However, in many cases what happens is that excessive autogrowths can cause an excessive number of VLFs to be added - sometimes resulting in hundreds of VLFs. Having an excessive number of VLFs can negatively impact all transaction log related activities and you may even see degradation in performance when transaction log backups occur. To see how many VLFs you have solely look at the number of rows returned by DBCC LOGINFO. The number of rows returned equals the number of VLFs your transaction log file has. If you have more than 50, I would recommend fixing it and adjusting your autogrowth so that it doesn't occur as fequently.
04-28-08, 23:23 #2Registered User
- Join Date
- Jul 2003
- San Antonio, TX
The number does play a role, because the more VLF's you have, the longer the shrink operation may take place. This affects everybody because it's a physical IO, which is done by kernel threads."The data in a record depends on the Key to the record, the Whole Key, and
nothing but the Key, so help me Codd."