Until that day, I had never heard of VLFs, and to this day, a lot of DBAs don’t know what they are. But before I get too far into this, let me state that I’m hardly the expert on this. Kimberly Tripp from SQL Skills  has written several really good articles on transaction log throughput where she talks about VLFs.

VLFs are a construct within the SQL Server transaction log file that breaks the transaction log file into chunks. Those are the segements that get marked for being in use or ready to be reused.

The bottom line is that if you have lots of really small VLFs in your log file, you probably have a performance problem and you may not even know it. The best way to avoid this is to avoid the default settings on a new database for the transaction log file size and growth. If you start with a 1 MB transaction log file that grows by 10%, you’re going to have lots of little VLFs before you know what hit you.

My suggestion for a good practice is to start with a larger transaction log file and grow in larger increments. In my environment, for our datamart environments, we start with an 8 GB transaction log file and grow them in 8 GB increments. For smaller databases with smaller throughput, we set a minimum of a 256 MB transaction log file with a growth of 256 MB.

In this session, I talk about how this can be a Goldilocks problem. You might have too many or too few. Or they might be too big or too small. The real way to know is to baseline and test for your environment. The one thing I would suggest is that you don’t want to grow your transaction log file by more then 8 GB at a time. This will lead to 16 VLFs created per growth. And that would mean VLFs greater than 512 MB.

The real value in this session is the demo. The first script creates a database and starts stuffing it with data. It’s absolutely not a model of good design. In fact, it’s far from it. I have multiple columns that contain GUIDs. Worse yet, I have those columns indexed. The reason I’m doing this is because I want to create a ton of transaction log volume. Kick this thing off and let it run. It’ll grow your transaction log to about 12 GB.

The second script will show the VLFs in your database. This script executes

DBCC LOGINFO WITH TABLERESULTS

Notice that as the first script is running, the number of VLFs will continue to grow on each execution.

There are some cool details on this output, including the size of each VLF and the LSN of when it was created. Lets do a little analysis on it. What I’m doing is pumping that data into a temp tble and then grouping on the LSN. I can then see how much the log file was grown each time and the number of VLFs it created. What you see can be quite staggering.

CREATE TABLE #VLFS
(recoveryunit int, --remove this column for SQL 2005/2008 environments
fileid int,
filesize bigint,
startoffset bigint,
fseqno bigint,
status int,
parity int,
createlsn varchar(1000))

use miketest
go
INSERT INTO #VLFS EXEC('DBCC LOGINFO WITH TABLERESULTS')

select createlsn, sum(cast(filesize as float))/1024/1024 [size], count(startoffset) [count]
from #vlfs
where createlsn <> '0'
group by createlsn
order by 3, 2, 1

drop table #vlfs
go
use master
go

Look at all of those growths. And they’re tiny. That can’t be good. You can see that we’re we’re growing our transaction log file by less than 1 MB several times.  But look at what happens closer to the end of the output. We’re growing our transaction log file in much larger increments. And the bigger the growth, the more VLFs.

Here is what I’ve been able to prove. If your growth is less than 512 KB,  you create one VLF. from 512 KB to 768 KB, you create two VLFs. 768 KB to 1 MB creates three VLFs. 1 MB to 64 MB creates four VLFs. Until you reach 1 GB, it’s eight VLFs. Anything over 1 GB is 16 VLFs.

If you poke around your environment, you probably have databases that look just like this. The question is How do I fix it?  The answer is simple. It depends. If you’re not seeing a noticable performance impact, you may want to leave it alone. This is where If it isn’t broken, don’t fix it could apply. If you are facing a performance problem from too many VLFs, I’d suggest doing this  during a quiet period for your database.

First, note how big your transaction log file is. Because I know how my files grow, I’m going to put it back to the size it was before.  Then I use DBCC SHRINKFILE to shrink the transaction log file and then grow it back to the original size, making sure I only grow it in 8 GB increments.

The real lesson here is something that I talk about in other posts: Defy the Defaults! If you’re creating databases with 1 MB transaction files and allowing them to grow in 10% increments, you’re probably doing it wrong.

• Remember which Dunkin Donuts you ordered your breakfast from.
• Use the schedule builder on the SQL Saturday website to get a better idea of which sessions need to be in bigger rooms.
• Most attendees aren’t as in tune with which speakers are bigger names. They care more about the topic and less about the speaker. That’s how we should have determined which speakers go in which rooms.
• No two sponsors are alike. Some are great to work with, others need a little TLC.
• Take care of your speakers and volunteers so they can take care of your event.
• Our venue is split up across two floors. Putting registration on the floor where people enter the venue will eliminate a lot of confusion.
• Stuff the attendee bags well in advance, but don’t put a schedule in the bag. The moment you print that schedule, it’s out of date.
• Know what to farm out.
• Start communicating with speakers directly immediately after speaker selection and not just via the sqlsaturday.com website. Some of our speakers had their e-mails caught in spam filters.
• Having a small cache of gift cards was really helpful. Many of our volunteers paid for their own lunch, so the least I could do was give them a $10 or $15 gift card to offset that.
• I was entirely way too conservative setting the max registration number. Our drop-out rate was a bit higher than average, meaning we turned away people who could have attended our event.
• Don’t drink too much at the speaker dinner the night before your own event.
• Make sure you give your PASS Regional Mentor a speaking spot. I was “that guy” who didn’t do that.
• Having a porter to keep up with the trash was one of the best things our Microsoft event coordinator suggested for us.
• Thanking our Microsoft event coordinator and the porter with small gifts went a long way.
• Parking. Parking. Parking. Our venue was in Cambridge and we tried to encourage everyone to take the T. Many people from the suburbs and places outside the city had to drive and needed a place to work. This something we can address for next year.

That’s when we started kicking around the idea of doing an “Ask the Experts” session. It became our ATE Lunch idea.

One of the things I strongly believe is that people often come to any type of a training event with one particular problem they want to solve or one particular question they want to have answered. THIS would be that opportunity to do so. We took our three big multi-purpose rooms and split them up by topic. We had one room for Application Development, Database Administration, and Business Intelligence  And we asked our speakers to field questions for their particular area of expertise.

I poked my head into each of the rooms over the course of the hour, and people were talking. I heard questions being answered, and that was the goal. Was it the best use of our time? Maybe not. But it was an effective use, especially considering that we didn’t have to move any chairs around.

We were just kicking off our event. People were coming in the doors, they were visiting sponsors, they were getting coffee, and my stress level was starting to subside just a bit.

That’s when I heard the shouting. Someone was yelling for security. It seems that someone had crashed our party. He was shouting, flashing his badge around, telling us that he was from the Department of the Navy and that he had just compromised our event. I grabbed my cell phone and called the facility manager for Microsoft.The shouting continued. That’s when I confronted him, keeping my hands in my pockets to ensure I didn’t appear to be physically threatening, which isn’t much of a problem anyway at 5’8″ and about 30 pounds overweight.

What was really impressive is that this guy somehow got into our venue, picked up an attendee bag, lanyard and all, helped himself to coffee and donuts, and mingling with our participants. I verbally confronted him and started leading him to the door. That’s when the facility team took over the situation and escorted him out of the building.

The guy’s “badge” was really an ID card from the Department of Veterans Affairs. He was probably a patient at a VNA hospital, and we should honor his service to the nation. And he was probably just happy that he got coffee and a donut.

This is probably one for the SQL Saturday record books.

As someone who likes to speak at these events, one of my top priorities was to take care of our speakers. Sure, we had a dinner the night before, and we had a little gift for them in addition to the event shirts. But I wanted to let them know that I appreciated them. Speakers give up a good chunk of their weekend to volunteer at these events. Often times, they do it on their own dime. So I wanted a little treat. I called on the good folks at Sweet Cupcake Bakery in Boston. The cupcakes are both delicious and beautiful. As the day progressed, I spoke to our sponsors and told them that we had cupcakes in the speaker room. I don’t think we threw away any cupcakes.

Don’t be surprised if we do that again next year.

The backbone of a successful SQL Saturday event is the volunteers. They do everything from picking up the coffee to staffing the registration tables to helping people find the restrooms. And we had an amazing group of volunteers.

Being completely honest here, I’m not sure what Paresh did or how he did this.  I just know that he had the list of things that needed to be done, the list of people willing to volunteer, and he made the rest happen. Paresh is a natural leader, and he’s incredibly organized and process driven. Getting him to lead our volunteers is something I hope to do again next year.

There is one thing that I did that I will never regret. I enlisted the help of one of my closest friends, Andrew Mannone. He’s not part of the SQL Server community. That also means he didn’t care about seeing certain speakers, and it meant that he could stay close to the registration desk all day. I introduced him to Paresh, handed him my credit card, some cash and said “Whatever you guys need, just take care of it. Don’t ask. Just do. And get me a receipt.”  Those are the friends you know you can count on. And it worked well.  Next year, I’d like to get a few more volunteers from outside the community for the registration desk. That will mean our volunteers can sit in on sessions as well.

We had an incredible list of sessions from a very amazing pool of speakers. We had locals, MVPs, sponsors, and Microsoftees. How did we narrow several sessions down to the few that would make the final list? How did we strike the right balance of celebrity DBAs with local gems? And how did we get the right mix of beginner sessions and really advanced topics? How did we avoid speakers who might cancel? How do we match the demand of the session with the size of the room? It wasn’t easy.

Our goal was to give our user community the best day of training we could give them. And how do you do that? You turn to your friends. I knew we could count on Tom LaRock (blog|twitter), Adam Machanic (blog|twitter) Grant Fritchey (blog|twitter), and Allan Hirt (blog|twitter). They’re all local, and they’re all MVPs.  And I asked Adam Machanic to do our keynote. By starting there, we had a recipe for success.

There were some speakers who submitted that were going to have to travel, and that could conflict with a late season snowstorm, either here in Boston or in Chicago. It seems that every connecting flight goes through Chicago. That made me nervous. So we limited the number of speakers coming in from distant places, which would make it easier to fill in gaps.

And to be honest, we got really lucky. Our event was the weekend before the PASS Business Analytics conference. That meant Peter Myers was flying into the US and offered to speak at our event. We also had Stacia Misner (blog) doing a session with Joey D’Antoni (twitter). We also got lucky that Christina Leo (blog|twitter) had recently just moved to Boston.

We also have an amazing group of local speakers like John Miner, Michael Corey, Paresh Motiwala, and Brandon Leach. They’re what make SQL Saturday events great, being able to use your local talent. These guys give some great sessions! We were also fortunate that the folks at Pragmatic Works, one of our Gold sponsors, submitted in force. We got some great content from Chad Churchwell, Bradley Ball (twitter), and Dan Clark.

I know that I offended a few MVPs who wanted to speak in Boston when we didn’t accept their sessions. It really sucks to turn away an MVP, but we have a ton of them locally. I told them that we were trying to focus on local talent where we could. Most of them understood. Most, but not all.

How did we get it right? I’m not sure we did. We had some big names that didn’t fill big rooms, and we had some local speakers who had standing room only in smaller rooms. I think the lessons learned here are to put sessions in rooms based on the content and not the speaker. And next year, we need to make better use of the schedule builder tool on the SQL Saturday website.

The one thing I KNOW we got right was asking a local big name to do the keynote. Adam Machanic is an amazing speaker, and if he were doing a session on tying your shoes, I would go, just to hear him present. He’s just that good. He gave a killer presentation on the future of database careers, and the feedback we got says that he was one of the best sessions of the day.

A few days before our event, I called the Dunkin’ Donuts nearest our venue and ordered 20 boxes of Joe and 15 dozen donuts. That was supposed to be enough for our event.

Saturday morning rolled around, and I walked into that Dunkin Donuts to make sure everything was in order. Needless to say, I was beyond shocked and horrified when I learned they didn’t have our order. I called a few more Dunkin’ Donuts locations in the area only to realize that nobody had our order.  And to make matters worse, the number of the location I called wasn’t on my phone–I had called in the order from my office phone. With the belief that someone had lost our coffee order, we ordered another 20 boxes of Joe and another 15 dozen donuts.

The whole order wouldn’t be ready for another 30 minutes, so we had our volunteers retrieve what was ready. That’s when my phone rang. It was the Dunkin’ Donuts in Harvard Square, telling me that our coffee and donuts were ready. It turns out I had ordered our coffee from the wrong location! We now had twice the coffee and donuts we needed. We sent another set of volunteers to Harvard Square to get the coffee and donuts.

In the confusion of where we were getting the coffee and donuts, we forgot to send our volunteers back to the Kendall Square location to get the rest of the coffee and donuts we (re)ordered.

In retrospect, it’s kind of funny. And we had a budget contingency for just such emergencies. Somehow, it was a hidden blessing. We had plenty of donuts, and we didn’t throw out a lot of coffee. Lesson learned: Make sure you document which location you get something from. That number will be important later.  If that’s the biggest thing we messed up that day, we must have done something right.

In the environment I manage, we started with about 20 SQL Server instances, and the day I started, I was sent a spreadsheet with instances, ip addresses, and passwords. When we built a new instance, someone would email the updated spreadsheet to the whole team. Clearly that doesn’t scale.

Today, with more than fifty instances and a much larger SQL Server team, we have a SQL Server database that we use to track machines, instances, credentials (now encrypted with certificates) and other critical information. This scales better than the spreadsheet. Our next step is to integrate it with the system we use for our Oracle environments and then integrate with our CMDB. Then we’re going to automate it to know SQL versions, builds, invalid passwords, product versions, etc. THAT will scale.

I’m looking at my own life and realizing that the Cranky DBA name isn’t going to scale for me, either. When I first started talking about SQL Server, nobody knew who I was. Cranky DBA was something people could remember. But will that work for me if I ever want to start my own consulting business? And what if I get my dream job, working as an evangelist for a technology company? Would they want me out there selling their products as the Cranky DBA. Probably not. What do I have that will scale? My name.

Over the past couple years, I’ve started getting my name out there in the SQL Server community, and people know me by name now. Mike Hillwig isn’t a stranger anymore.

If you look at my blog, you’ll see that references to Cranky DBA are starting to disappear. Instead, things are starting to live at mikehillwig.com. This comes along with a new WordPress theme. It needs a little more work, but I think it’s something that will scale better over the next few years.

I’m a DBA. Organizing things, stuff, and data is in my blood. What I’m not good at are printing, moving boxes, catering, and serving coffee. These are the things that we farmed out.

Printing? The folks at Fedex Office can do this way better than I can, and it’s a lot more cost effective to let them do it. All I needed to do was give them a PDF, specify the paper color, ink color, and how to cut the paper. They did the hard work. All I did was go into their location and pick it up. Next year, I WILL find a way for them to do our speaker/sponsor SpeedPASSes as well. If I ever have to cut up another SpeedPASS, it will be too soon.

Printing? I had a lot of our signs printed in advance at Vistaprint. I just printed the event logo on 11×17 paper, and then used those as templates to hand-print signs. It worked beautifully.

Shopping? I have an Amazon Prime membership. This thing paid for itself. We gave away lots of goodies, including books and gift cards. Most of those came from Amazon. All I did was order it online and had it shipped to my office.

Moving? Please. The folks at Michael’s Moving and Storage in Boston are amazing. I’ve used them for my personal moves several times. Having their guys coming to my house and schlep the 35 boxes to Microsoft was a no brainer. It was easier than renting a UHaul, and it meant that I didn’t throw out my back the day before our event. Since we only had a few boxes to move, we ran into their minimum move requirement. Still, $300 is really short money to ensure that I don’t have to do the lifting myself. And THEY dealt with driving in Cambridge, something I just refuse to do.

Catering? Wow. The folks at Cosi in Kendall Square were amazing to work with. They provided the lunches for our event, and they were delicious. The only thing we did was buy sodas. They had a box lunch for everyone, meaning nobody touched someone else’s food. It was fantastic. They even sent someone over to stack the boxes and make sure everything ran smoothly. I’ll go back there again in a heartbeat.

Catering? We had our speaker’s dinner at the Black Sheep restaurant inside the historic Kendall Hotel. They made it easy and delicious. All I had to do was pick out a menu, and they did the rest of the work. If I’m doing an event in the future, I’ll go back there in a heartbeat. Their catering manager, Santos, was fantastic, and I couldn’t thank him enough. He arranged a pre-dinner reception on their seventh-floor balcony that really set the tone for a great night.

Catering? We ordered coffee and donuts from the Dunkin Donuts in Kendall Square. That one didn’t go quite as expected, but it was totally my fault, and it’s a story that I’ll probably share next week.

Sure, I could have done some of these things myself. But honestly, there are some problems you throw money at. These are some good examples.