Instead of working, I blog.

Just double posting for a while till everyone gets the hang of the new location. Don't forget that officially my blog has moved here and I won't be posting very much longer at this location.

I know Jen's already blogged on this, but this is my little contribution to the whole, how cool are we, theme.

Brad Mcgehee just came to speak at our user group and to my surprise he thought enough of what we're doing to write a blog about it.

So I thought I'd take this time just to explain a little more so maybe some more of you can start doing it at your user groups too.

I started doing this last year when it really started bothering me that the user group model is so limited. The problem is that you bring in a speaker to give a session on a topic, and next month you do the same thing with a different speaker and a different topic. The problem is that you don't have time to go deeper into any of the topics. You only get to barely touch on the subject and there's no time to really learn it. So I decided to start up a progressive class before the user group. I lasts like 6-8 mos and each session builds off of the previous ones. The downside however is that it takes you 6mos to complete the class, but it's better than nothing and it's a free class. I actually treat it like a real class that you would go to at a training center only I like to think I go into more depth sometimes.

It's a really good model because if you hold it before or after your main user group meeting the people are coming anyway so you've got a built-in audience. And you'd be surprised how many people show up to the group that never did before. So anyway, that's all I've got on that. I hope some more of you start doing this and if you do I'd like to hear how it works for you. And I'd like to also give a special shout-out to Brad for recognizing my genius.



Petri for us all

The Petri IT KnowledgeBase just opened up its SQL section and Jen and I are the authors. I know, Jen also wrote about this too... what can I say, I have nothing original so I have to steal others' material. Anyway, it's really a nice site they've put together for us so come check it out. Currently we've got some nice barebones "I know nothing about SQL" articles so if you're a complete newbie then you can start here and we'll explain what all this stuff actually means.

Hey everybody... after like 5yrs of blogging here, I've made the decision to move this blog over to MidnightDBA.com.

Jen and I are consolidating our blogs in the same location so she's moving too. I'm pretty much up and ready to go in the new location so update your RSS feeds to point to the new location because this'll probably be my last post at this address. Maybe I'll double-post for a while, I'm not sure.

Here are the links to our new blogs, and they're actually on a linux server so the URLs are case-sensitive.

http://www.midnightdba.com/DBARant/
http://www.midnightdba.com/Jen/

Hey everybody... it's been a while since I've blogged, but that's what starting a new gig will do to you. I've had so many new things to rant about here and I'm sure I'll be getting to those in the future, but right now I want to share a funny story with you.

We had a group of devs who were trying to run a fairly simple insert and it kept filling up the disk. And when I say it was filling up the disk, i mean like 50K rows were filling up like 200GB. So they came to me to see if I could fix it. This is where it gets fun.

It really didn't take me too long in my investigation to find that they had the data file set to autogrow by 131,000%. That's right, I said it! 131,000 percent. So now that I found the problem I was able to set it to something more reasonable, shrink the file and let them get on with their insert.

So it started me thinking about what other DBs in the place had similar issues because I've been hearing about disk space problems here and there. So I wrote a powershell to go out and check the file growth rates for every SQL box and I found a lot of the same type of stuff. There were a lot of them set for several thousand percent growth, several of them set for 1MB growth, and everything in between. In general, as a good generic setting to start from, I like to grow my files 1GB at a time. It's a good round number that works in a lot of cases and then you can snipe the ones that need something else. And then I altered the powershell to go out and change the growth rates of all the DB files out there to 1GB. Life is good again and we have the beginnings of a happy shiny environment.

Oh y, and in the same discovery I also found 110 DBs set to autoshrink and I also took care of those.