June 2, 2011 at 8:54 am
Comments posted to this topic are about the item Stairway to Transaction Log Management in SQL Server, Level 2: A Brief Overview of Transaction Log Architecture
August 17, 2011 at 1:00 am
good article ...
August 17, 2011 at 6:21 am
Where's the link to the next level?
I felt the same disappointment as getting to the end of an hour-long episode of a serial TV show: "Aw man, gotta wait till next week? I want more now!"
I'll be anticipating your next article. 🙂
August 17, 2011 at 6:29 am
If you do find that you have too many vlogs in your tlog how can you reduce the number of vlogs.What comes to mind is set the database to simple, shrink the tlog, set to full and then resize the tlog appropriately. Is there a more direct way and if not, does the way i outlined work?
I support a lot of systems that have databases for our software but we do not manage the databases. Many database start out with the default 1MB default log size with 10% auto growth. I would expect these sites would be susceptible to the problems described with large numbers of vlogs.
Jimmy
"I'm still learning the things i thought i knew!"August 17, 2011 at 7:00 am
Excellent Article Tony.
Thank you.
August 17, 2011 at 7:03 am
Mike - it's great to hear you're looking forward to the rest of the articles. I hope you enjoy them! The first five levels can be found here[/url]. Bear in mind that if you get through these quickly, then you really will have a bit of a wait to read more ;-).
imSQrLy - yes, that should work, though it might not be necessary to switch to SIMPLE, rather than just taking a log backup in FULL. Anyway, it's basically the way I'd do it, and is also the way Kimberly Tripp recommends: see Tip 8 in her "8 Steps to better Transaction Log throughput" article.
Cheers,
Tony.
August 17, 2011 at 7:48 am
Excellent Article! and very well explained. still I have very simple question.
I may be sounding asking a basic question but wanted to make some things clear here.
what happens when the last lets say n'th VLF(VLFn) is full with the logs and logs between VLF3 to VLFn are all active and full with logs. where will be the next LSN generated? will it be in VLF1 and VLF2 if they are inactive/reusable state? if yes what will be the LSN for those new logs? highest/lowest?
Thanks,
Alpesh Pradhan
August 17, 2011 at 9:59 am
Hi Alpesh,
I should stress that I'm giving a simplified view of what actually happens, but yes the active log will "wrap around" so that that MaxLSN is now in VLF 1.
Tony.
August 17, 2011 at 6:08 pm
Thanks for the article Tony.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 25, 2011 at 10:46 am
imSQrLy (8/17/2011)
If you do find that you have too many vlogs in your tlog how can you reduce the number of vlogs.What comes to mind is set the database to simple, shrink the tlog, set to full and then resize the tlog appropriately. Is there a more direct way and if not, does the way i outlined work?I support a lot of systems that have databases for our software but we do not manage the databases. Many database start out with the default 1MB default log size with 10% auto growth. I would expect these sites would be susceptible to the problems described with large numbers of vlogs.
Don't set the db to simple or you'll break the log chain. If your db is full or bulk, take a tran backup and then shrink/resize the log.
September 16, 2011 at 1:53 pm
Great series. Read the first 5. Are these levels to follow?
Level 6, Managing the Transaction Log in Bulk Logged Mode.
Level 7 – Sizing and Growing the Transaction Log
Level 8 – Help, my log is full
Jeff Langdon
@jlangdon
November 30, 2012 at 9:00 am
It's well-written and I thought I understood, but when I tried to apply what I learned, I found something that didn't make sense. We have a 1.8G database with a 1.5G log - which sounds way too big, except I remember when it was up to a 3.5G log.
I ran the command, DBCC Loginfo, which showed 399 rows, all with status 0. I assumed that meant there'd been no activity since I ran the log backup, so I went in and updated some of my timesheet, checked the LogInfo again - and there was no change.
Of course, the transactions would have been committed, so it's not like they're required for a rollback, but they haven't been backed up. The space they're using shouldn't be reusable at this point, should it? That should make it state 2, which should make the status on one of those record = 2.
Am I missing something? And anticipating the first question, yes I made sure that I was doing the command on the correct database.
November 30, 2012 at 9:20 am
Hi Bev,
Have you treble-checked :-). I'm pretty sure one of those 399 rows must have a value of 2 (active). As soon as you create a database, some info gets written to its log file and one of the VLFs will be active.
USE master;
go
CREATE DATABASE NewTest;
USE NewTest;
go
DBCC LogInfo;
As for space resue - this does require a log backup if the database is in FULL recovery model, but not in SIMPLE.
November 30, 2012 at 12:13 pm
Damn if you weren't right. I ran it again, and then, just to humor you of course, I began moving through 399 records one at time. At the 294th click of the down arrow, I found myself staring at a 2.
This series has helped me in another way. I think the reason the log file is so huge and at the same time so empty is that I was asked to rebuild all indexes about a month ago. I will be adding to the job some code to switch it to bulk insert recovery and then back to full after the rebuild is done. After I finish the Level 7 article and hopefully find the best code to shrink it.
April 6, 2013 at 10:36 pm
Is level 8 published anywhere?
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply