Sales Reps–Please Don’t BS Me, Alright?

Today is my morning of big data storage events, I’m attending two from two different vendors in about four hours. One down so far, and it was pretty good, until…

I’ve bashed sales reps before (on twitter and on this blog), I’ve even offered lists of things not to do. Well today’s presentation was on par with some of the best I’ve seen. I was engaged, and we had a good discussion of the architecture of Hadoop, and the kind of data applications where it really sense. I was engaged, and wasn’t bashing the vendor on twitter like I sometimes do.

But Then,

The vendor had a slide with the Hadoop ecosystem up–there are a lot of components there. And they aren’t all needed. I though a really good comparison would be to SQL Server, we don’t always need replication or analysis services installed, but if we want to have a database we need the engine. Hadoop is a lot like that–you can get by with just a few components out of the total stack.

At that moment the presenter mentioned SQL Server, and I thought, great this will be a really great example. Then he asked “What is the core engine to SQL Server?” (The right answer I think is Sybase, then it was rewritten for 2005, iirc, someone correct me if I’m way off) He eventually responded with “Jet Database” using the example that you can install SQL Server without installing Jet. As far as I can tell and from my twitter queries, SQL has never run on jet, but Jet may run on SQL Server now.

Anyway, the trivia isn’t the point–if you are quoting a fact in your presentation, be certain of it, and if you aren’t either don’t use that fact, or clarify, saying “I think this to be the truth, but I’m open to facts”. After this, A) I didn’t trust the speaker’s credibility and B) I was distracted trying to confirm the fact the Jet was never a part of SQL Server.

I guess I can add one more thing for sales reps not to do–don’t make $&%# up, you may have a subject matter expert in the room, and you will look like an idiot.

SQL Server Clustering — Why you should use mount points

I’m in the process of developing a presentation entitled “Building Your First SQL Server Cluster” for some upcoming SQL Saturdays, and some inspiration for a few blog posts have come out of it. This one is short and fairly simple.

Windows, as we all know and love, has us use drive letters as the root of file systems. As there are only 26 letters in our alphabet, combined with the fact that A, B, and C generally aren’t available, leaves us with only 23 or 22 available for a given cluster. While this may seem like a lot, if you are splitting out tempdb, transaction logs and backups, you can chew up a lot of letters in a hurry.  If you are using multiple instances in your cluster, the problem is compounded. And remember–the cluster can only see drives that are attached to it–you can’t restore a backup from a UNC path.

So what is the solution to this conundrum? Mount points–mount points allow you to mount multiple physical devices under one drive letters, where they look similar to directories.  This does prevent a bit of a monitoring challenge, but that’s best left for another post.

I’ve posted before on how to add a disk to a SQL Server cluster here. Using mount points is really straightforward–assuming you have 3 “disks” (could be SAN luns or Windows volumes (well not in a cluster), designate one of the drives to be the root (the drive letter S:\ in this case).

*Note–it doesn’t really matter which disk you choose to be the root–in my case I select the backup lun, but I discussed this with a couple of others, and no one knows of  any impact to system performance.

When you are assigning a drive letter to the next device, stop–select the option to “add to empty NTFS folder”, make sure you have the root drive highlighted (Windows likes to default to C:\) and name your folder (you can easily rename through explorer later).

One note–when you go to add the disks to your cluster (if newly creating), you will only see the root disk as available, the other drives won’t be selectable. This is expected behavior and fine. Good luck and happy clustering.

%d bloggers like this: