Database Underground | Sean McCown » Scattered Data

April 09, 2008 | Comments: (0)

Scattered Data

TAGS: General Database

I know someone right now who is splitting a database into separate instances for performance purposes. Now, this happens to be a SQL Server specific installation, but the concept holds true for all the vendors.
The problem is they're putting the 2nd instance on the same box, and leaving the DBs on the same disks. And not only that, they're doing double writes on some of their busiest tables (without using 2PC) to keep the instances in synch. This is just a disaster waiting to happen. But not only that, it completely defeats the original purpose for splitting it to begin with. If you want to increase performance you don't add the overhead of a 2nd instance without making other changes to compensate. And I can't think of a performance problem that would be solved by putting something on a 2nd instance. Maybe if you just wanted to make sure that one of the instances got the lion's share of the memory, but other than that, there's no real reason. If you're going to separate instances for those reasons, separate boxes too. It's that simple.

This ties in really well with a blog I've been meaning to write for a while. It's no wonder users hate coming to us most of the time. It seems like we're always making projects a bigger deal than they need to be and then we plan them wrong and mess it all up. And that's a valid concern from the user's perspective.
Look at how many times someone comes in with a simple request to move data from one place to the next... something that would take 10mins, and we drag it out with a project plan, data mappings, models, etc. It's enough to make them just do it themselves... if they only had the rights.

But you have to understand why we do this. And don't get me wrong, it gets to me sometimes too. There are so many times I want to just do the work and be done with it. Give me 30mins and I'll just bang this one out and move on. But you just can't do that. What you have to realize as an end user is that you have this small project for us to do and so do the other 70 groups in the building. And the next thing you know we're 6mos down the road with 200 extra processes going from one box to another and nothing that tells us who the business owner is, how often it goes, why it goes, who to charge for disk, how often to backup, etc. Sure, we're your only IT dept, but you're not our only customer. We need to have something that says where this data's going, where it's coming from, and who's in charge of it... and why. Maybe you're requesting something that we're already pulling and we can just give you access to that instead. There's no reason to pull it twice, right?

So anyway, I feel your pain. I really do. And I even share it with you sometimes. But this is how it has to be if you want us to know what you're talking about when you come to us and say, where's my data, or what's this process for, or do we have a process that does this?

Posted by Sean McCown on April 9, 2008 10:07 AM

RATE THIS ARTICLE: