Google Search » Database Underground | Sean McCown » September 2007

September 28, 2007 | Comments: (0)

Happier Wars

TAGS: General Database

All of you who follow me, know that I've kept pretty good tabs on the backup wars as I was there not only from the beginning, I appear to have been a major player. And while I haven't kept you all up to date with what's going on now, I will soon.

What I want to talk about now is a new war that's about to be waged. This is completely uncharted territory just like backups were when LiteSpeed came onto the scene.

What I'm talking about is SQL accelerators. This is one of the perks of being in the media is I'm always getting first looks at new technology. Well, at PASS last week I spent some time with the SQL Nitro guys and they showed me what they had to offer. Frankly, it was even hard for them to get me to take a look because I've seen these products before and they just didn't work. However, when they pulled me into the booth it only took them about 30secs to peak my interest.

I not only saw a quite impressive demo, they let me get on the box myself and play around a little and it worked with the stuff I threw at it. But that was just a demo box and nowhere near a real environment. So they gave me a handful of licenses to put in my lab and I've been playing with it for about a week now, and so far the results look good. It's still way too early for me to give it an honest blessing, but I'm liking what I see.

For those of you who don't know, SQL accelerators are something the network guys have enjoyed for a long time now. They compress the network packets so you're actually sending less information across the wire. This is a completely untapped area for DBAs to tune. I mean, let's face it... you can only go so far tuning your queries and your box. If the network doesn't keep up then you can't exactly strip it out as easily as you can get a new server or just increase your memory. So this will allow DBAs to finally conquer the network layer of their performance problems as well.

I call this the Happier Wars because once this product gets battle-proven, everyone will follow with their own version. You'll start seeing accelerators pop up all over the place, and then we'll see the SQL Accelerator Wars. I only hope they'll be happier and more civil than the backup wars were.

But whatever you do just remember... you heard it from me first.

Posted by Sean McCown on September 28, 2007 11:43 AM

September 27, 2007 | Comments: (0)

The Password NIghtmare

TAGS: Microsoft

There are several best practices for dealing with passwords, but one that gets overlooked a LOT is the one that says never use your personal account for services or processes. The reason usually given is because when you change your password, the processes will stop working. That's nice, but so often people don't care about that. They prefer the ease of being able to use their account because they know it has the rights they need, and they can control the credentials and not have to get any other groups involved.

Well, the other side of that is that these processes running under your account will get you locked out if you're not careful. If you change your password, and these processes are still running, you'll get locked out for sure. And just try to track down what's locking you out when you can't stay on the network longer than a few minutes at a time. Now you've got to involve someone else in your hunt.

I don't care how bad you want to... never use your personal account for anything other than logging in. Now with Yukon, you've got even more reasons not to do that since you can setup proxies under your account.

So if you reset your personal password one day and you find yourself suddenly getting locked out, here are some common places to look.

Services: Quite often just to get things going, a DBA will run some of the SQL services under his account. Don't do it. But if you do, start here for troubleshooting.

Reporting Services: Reports take credentials to connect to the DB. It's very common for DBAs to setup his reporting environment to just connect with his account. Bad idea.

VBS: It's also not that unheard of to see OS-level scripts running under someone's account. A lot of these things will use WMI to connect to different machines to be used as collectors for stats. That's fine, just have an account created for that.

Scheduled Windows Jobs: Here's another place you have to hardcode your password. You have to tell the job to run as somebody... just don't make it you and you'll be fine.

Stored Procedures: It's not all that out of whack to see SPs with openrowset and xp_cmdshell commands in them, and quite often these will have your account and password hardcoded in them as well. The most common place I see that is in mapping drives in cmdshell.

TS: Terminal Services sessions can be a big culprit too. A good best practice to get into is always logging out of your TS sessions when you're done. This is because if you have open sessions, TS will use your previous credentials and lock you out eventually. I used to do this all the time at my old gig. Our network guy was constantly having to search the network for servers carrying my rogue TS sessions. And they can be tough to track down, so just log out when you're done.

OK, those are the biggest ones. I'm sure there are some I forgot, but this isn't meant to be a comprehensive list, just a few ideas. But think about it. If something's locking you out, how hard would it be to track it down if you manage dozens of boxes and have processes running all over the place. It's next to impossible. especially since you get very little information from AD on the event. And if it's a .vbs that's hidden in a folder somewhere, or being called from another program like MOM or NetIQ you're just screwed. You'll be lucky if you ever find it.

So if you don't care about this best practice because your environment is safe and you're not in much danger of your account being used for evil, then at least consider this point and set yourself for success the next time you change your password.

Anyway, that's all I got.

Posted by Sean McCown on September 27, 2007 09:57 AM

September 24, 2007 | Comments: (0)

PASS Disappointment

TAGS: SQL Server

PASS last week was just a little disappointing. I heard somewhere through the grapevine that attendance was down by around 15%, but as it turns out, that was the lucky part. The Denvery convention center turned out to be inadequate for our crowd anyway because many of the good sessions were standing room only, and they wouldn't let anyone stand during the sessions. More on that in a minute.

That wasn't the disappointing part though. What I found disappointing was the inconsistent quality of the content. PASS is making more of an effort to expand its speaker base, so they're getting some people who either aren't experienced speakers, or who have other agendas (like promoting themselves). Anyway, I took a 400-level session that spent most of the time explaining the basics to us. Things like, here's what tempdb is, and don't forget to split data and log files. And I found that to be the norm with the sessions that I didn't like. They advertised themselves at a much higher level than they turned out to be. Needless to say next year I really hope they have someone checking content so they set these sessions at the right level. I don't mind them teaching that stuff because someone will always need it, but at least be honest about your audience.

OK, now about standing in the rooms. Nobody ever gave me a reason, but it appears to be something that the convention center folks insist on. I'm sure if they were pressed, they would say it was a fire regulation to not have people sitting in the back. You couldn't even sit on the floor or on a table. So I'm having a hard time here not talking about how pointless and moronic that is, but I will refrain. However... if I were to talk about it, I would point out that that would be the stupidest fire code I've ever seen. If you say that you can't have anyone there because of a fire during a presentation, then you have to account for fires before the presentation while everyone is still standing around and the room is crowded. At that point everyone is blocking the door. So what you're telling me is that it's ok to block all the exits before and after sessions, but not during. So evidently, it's the fact that someone is talking in the front of the room that determines the fire laws. That kind of rule was clearly made by idiots. Seriously, if you don't stop to consider the actual logic of your rules, then you end up with crap like this. And what would the other reason be then? The convention center people just think it's disrespectful to not be in an actual chair while someone is talking? That's even dumber than the other one. So I don't know exactly what's up with that, but I would hope that PASS would stop that kind of mindless, moronic garbage next time.

Anyway, that's what I would say IF I were going to talk about it.

Posted by Sean McCown on September 24, 2007 11:08 AM

September 14, 2007 | Comments: (0)

Going to PASS

TAGS: SQL Server

This is going to be a quick post. I just wanted to say to all of you who are going to PASS in Denver next week, don't forget to go over the coference survival guide. Instead of reprinting it, I'll just link to it.
Sean's Conference Survival Guide

And you guys feel free to come up and say hi if you catch me next week. I like meeting the little people (j/k).

Posted by Sean McCown on September 14, 2007 09:54 AM

September 12, 2007 | Comments: (0)

The Multi-Tier Storage Solution

TAGS: SQL Server

For many DBAs performance is a huge problem. I know I've currently got systems that have their bottlenecks. One of the bottlenecks in a lot of SQL Server systems is in tempdb. There were a lot of things in SQL2K that relied on tempdb and Yukon increased that dependency by several fold (or made it worse depending on how you want to look at it). And while I don't really know yet if Katmai is actually going to increase it even more, it certainly isn't going to decrease it.
So in a way, Microsoft is actually working to create a bottleneck by not giving us multiple tempdb areas that we can use to segregate our users into. This really is one of those areas where Oracle beats SQL hands down because anyone who's ever tried to manage tons of users or tried to manage a large job in the middle of normal processing knows the advantage of having a separate tempdb area.

Enter tiered storage... I think that these new tempdb requirements are going to drive more and more DBAs to consider tiered storage for their servers. The simple truth is that tempdb needs to be as fast as possible, and it doesn't get backed up, so you've got some wiggle room when it comes to configuring your tempdb area. And to that end, you should start considering SSDs (solid state disks) for your tempdb area. SSDs are magnitudes faster than spindles so performance should go through the roof. And since tempdb services every DB on the server, then it needs to be as fast as possible. And with SSDs you can pretty much guarantee that the bottleneck won't be tempdb.

Don't get me wrong though. MS isn't the only one driving this need. Pretty much any DB could really take advantage of SSDs. The problem with SSDs though is that they're very Very VERY expensive. But look at the difference in raw hardware cost vs maintenance and power consumption. SSDs use considerably less power than hard disks so you'll be saving money on that side. It also takes far fewer SSDs to get good performance than it does hard disks. I can't count the number of times we had to build an array of several dozen spindles just to get the performance of tempdb to where it could actually support the load on the system. That's the perfect application for SSDs. Instead of buying a couple hundred SCSIs, you might be able to get away with just a few SSDs. Of course that's only if you're doing it for performance.

Yukon and Katmai aren't the only ones that can benefit from SSDs either. SQL2K still uses tempdb and while it doesn't use it as heavily as the newer versions do, it's still quite often the bottleneck. So don't be afraid to pop some of those expensive boys in your SAN.

This isn't anything all that new. We're already tiering storage configuration. We don't use the same RAID configuration for every DB or for every file type. You don't use RAID5 for tempdb, and you don't use RAID0 for your logs. So now all we're gonna have to start doing is mixing up the types of disks we use for different purposes. Use your SCSI for your main DB app. Use SSDs for your tempdb and some of your lesser log files. Use SATAs for your backups before they get pushed to tape. You know, start tiering your storage to fit the requirement of the intended application.

So anyway... this is just food for thought. The next time you've got a tempdb bottleneck just consider all of your options before buying 100 more spindles to get the performance you need. And I think as SSD technology gets better, and as the price comes down a little, you'll start to see this being the norm. Of course, I don't think it's the solution for every aspect of your DB server. I still have serious reservations against putting my main data files on SSDs, but I'm sure that too in time will pass.

Posted by Sean McCown on September 12, 2007 09:48 AM

September 11, 2007 | Comments: (0)

The Best Kept Secret

TAGS: Microsoft

For a year or more now I've been seeing promises of Microsoft's new wireless keyboard dubbed, the ultimate keyboard. You can find a couple sites with pics and a nice demo on MS's site, but I have yet to actually see the keyboard. There's next to no news online anywhere about it, and even on the official site, it doesn't say when it's supposed to hit. Originally it was supposed to be out last Feb. Then I heard July. Now, I actually assumed it had been out for some time now and I just went online to see what kind of reviews it's getting, and I'm not seeing anything out there that wasn't there a few months ago when I checked. So either the project is taking much longer than expected, or nobody is carrying it or even talking about it.
I'm not going to go over any specific features, but with the hefty pricetag of over $200 I'm very curious to see what it comes with. Personally, I've been trying to get a hold of one for quite some time now so I could get away from this piece of keyboard I use every day.

I also can't wait to see if they've put anything in especially to capture the programmer market. I think there are some keys that could be placed much better for programmers of all kinds and it would be nice to see a keyboard actually take those kinds of things into account for a change.

Anyway though, if I can ever get one I'll let you guys know if it's worth what they're asking. But for now, I guess I'll just wait to hear something because the only thing harder than finding the keyboard itself, is finding info on it.

OK, I just got off of the press site for this product, and it appears as though now they're saying that it'll be generally available sometime this month. The pricetag is now $299 for the keyboard/mouse combo. Man, I sure hope they can come to the table with something that makes it worth that much.

Posted by Sean McCown on September 11, 2007 03:22 PM

September 05, 2007 | Comments: (0)

Linux is Alright

TAGS: General Database

There comes a time in every DBA's life when he has to admit defeat in one area or another. Personally, I've done it so much it's old hat for me, so here's another one.

For years now I've been ribbing my friend for being a Linuxhead. Then I bought a Buffalo Terastation NAS for my house. Well, to make a long story much shorter, I lost my array and all of my data along with it. After poking around for a little while my friend discovered that it was Linux-based. So he asked me if he could have a crack at recovering it. I said sure... I wasn't really looking forward to the $3K it would take to have it recovered elsewhere. And did I mention this array had all my SQL backups and other important docs on it? I really couldn't afford to lose everything on it.

Well, after messing with it off and on for a couple weeks, he came over last night with a solid game plan and got the array back up and I was able to pull pretty much everything off of it.

I don't know if something like this would've been possible on a Windows system. He had uncovered an entire world of guys who had hacked the firmware to do one thing or another and that's what allowed him to do his thing. So with things in the Windows world always being so much more formal, that type of hacking isn't as ubiquitous and I might not have been able to get my data back this easily.

Needless to say I'm now rethinking my backup strategies at home. I've got a few DBs that I can't afford to lose, but it's tough. I'm not a corporation so I can't afford fancy tape libraries and the like. Nor are any of the home solutions suitable for the amount of data I backup. I'm basically between a rock and a hard place. I'm not entirely sure what I'm going to do yet, but I can't take a chance on losing that stuff again.

And of course, it's times like these when I bring my new-found paranoia to work and see whether my enterprise backup strategy has any holes in it or not. This type of near disaster is good for you. It's like almost getting in a wreck for doing something stupid. You get to be reminded to be more careful without the hassle and pain of an actual wreck... good stuff that.

So Linux is pretty cool, and my friend Jim rocks!

Posted by Sean McCown on September 5, 2007 10:50 AM