Can I Kick It? Yes I Can!

Well, I spent a day or three building a SQL Server Automatic Failover Cluster with two nodes, each one hosted on a Windows 2008 VM running in Hyper-V with an iSCSI SAN shared between them. 

 

Each VM is the main node of one SQL instance, and each is set to failover SQL Services to the other node.

Well, today, we got a real-life test when HV-07 (which hosts SQL-03) gave up the Blue Ghost.  And, within 30 seconds, HV-08 assumed services from HV-07 and SQL-04 picked right up without a missing a beat. 

It was so transparent that I was working in the database the whole time and didn’t even know HV-07 had BSOD’d until one of the network admins came in and said “Hey, HV-07 is sitting there with a blue screen”. 

A quick check on SQL-04, and….. Yep, both instances are now running on SQL04.  We fixed the BSOD problem on HV-07/SQL-03, and migrated the one instance back to SQL-03, and everything resumed as normal.

Now, I’m back to working on the Java program that imports flight crews and photos from our last remaining Pervasive SQL server into our latest SQL 2008R2 server.  This program is used by the TSA, Homeland Security, and many airlines (of which we are one) to vet flight crews who are jumpseating (hitching rides on other carriers aircraft).  It will also replace a Rube Goldberg solution that consists of a half dozen or so DTS packages, scripts, stored procedures and chron/task scheduler jobs.

And when I look outside, there’s still always one or two of our Learjets parked on the tarmac, twenty feet from my window.

I guess you could say I like the work. 😉

 

Lessons Learned from a Cheese Curd maker

This is not an article about technology.  This is an article about how to properly use technology, or at least how to not use it.  Wise words I learned from a wise man.

So, to be honest the guy was not a cheese curd maker.  He sold equipment used for that purpose.  But thats not an interesting title, is it?  Used Dairy Equipment.  Google it, and they are number one in the rankings, and had been for a long time.  So when they approached me about updating their site, I went full bore.

I developed a prototype website that kept all their existing keywords and metadata, and all the front page text and verbiage, but cleaned it up and modernized it.  And (and this is the salient part) I added a lot of new features by integrating their internal equipment database with their website so that visitors could search their inventory and find anything they had to offer.  A complete search engine, with keyword querying, sorting, filtering… everything.

I went back to them with my prototype.  It was beautiful.  It was functional.  It was exhaustive.

It was a disaster.

What I had done was technically cool.  It would allow anyone to determine if the company had in stock ANY item that they wanted. But it was business savvy lacking.  Why?

Let his words explain.  “I don’t want them to find out that I have what they need.  Because they could also find out that I do NOT have what they need.  I want to give them just enough information that they will think, ‘They have a lot of stuff’.  But not so much that they think ‘They don’t have what I need.’  If they think that, they won’t CALL ME.  And what I want is for them to call me.  If they don’t call me, I can’t sell them what they DO need if they don’t know what they need.  A lot of times, they think they need one thing when what they need is another.  I can’t help them if they don’t call.”

The goal with technology, in this guy’s case, was to give them just enough reason to CALL, not to BUY online.  Too much technology in this case works against him being able to actually help people.

I learned a lot about business from that guy.  In fact, I altered my own website taking into account what I had learned from him.  Ultimately, we did not implement my new site and they kept their existing site.  They did the right thing. 

Sometimes, the coolest technology and the best “features” are not what’s really needed.  It takes a good bit of business sense to know not if technology is worthwhile, but which technology, and specifically how much is worth while.

I think we could all learn a good bit from a guy named Gary Schier.  And hey, if you wanna learn how to make 500 gallons of cheese, visit www.schiercompany.com.  And no, I did not develop that site.  And a good thing, too. 

Thanks Gary.

I’ll just leave this here….

An excellent discussion on manipulating Excel Spreadsheets directly from SQL Server TSQL!

http://www.simple-talk.com/sql/t-sql-programming/sql-server-excel-workbench/

So You Want To Be An Air Traffic Controller?

Excuse me while I take a brief detour from the DBA fare. This is my new DBA blog, and prior to this, all I ran was a personal blog. So I posted all my tech stuff on that personal blog. Now I have a venue for my purely technical scribbles.

On that personal blog, I occasionally answered questions from people who find out that I used to be an Air Traffic Controller (lo!, now, many years ago) about what that job is like. And with the CombatDBA blog, I now have a venue more fitting for such questions, even if it has nothing, really, to do with Database Administration and Programming.  It’s at least about technical issues.

In my particular case, I worked for the United States Air Force, and (to be quite honest) I did not CHOOSE Air Traffic Control. I was chosen for it based upon my test scores. I had absolutely no idea when I enlisted that ATC is what I would end up doing. I ASKED for computer programming. What I GOT was Air Traffic Control.

The most common question that I get is something like “I want to be an air traffic controller. What can I do to prepare?” The answer is, really, nothing. The skills needed to do the job are something that you either have, or do not have. And they are not really skills that you can get training for. If you “have”, good. If not, there’s not a whole lot that you can do to prepare. We’re talking things like “being observant”. Having a good memory.  Being able to “see” and estimate distances and closing speeds accurately.  The ability to keep a picture of something (something that’s moving) in your head.

As an example, one skill that would be really useful to you is to count how many time the letter “e” appears in this article, so far.  No, really, that was actually one of the questions on the one of the tests the Air Force put me through.

As for what the job is like, it can be, like any other job, exciting or dull.  In my case, I’d say I was somewhere in the middle.  If you are working in a very busy, high traffic environment – say, RAPCON or Approach Control at a large, very busy International Airport, then you can expect the job to be busy and exciting… and very, very stressful.  If you are working (as I did) in an enroute center, then you can expect a day to be routine and relatively relaxed.   And if you are working a municiple approach tower, the job might even be boring.

Approach means working in a tower.  This is the “high visibility” aspect of ATC.  When most people think of ATC, they imagine an Airport Control Tower.  It is also the job that requires the highest amount of skill.  There are also Enroute Traffic Control centers who handle aircraft while enroute between airports.  These guys handle “the long stretch” of the route.  Your job is basically to accept aircraft coming into your airspace and monitor verticle and lateral separation of them until they pass out of your airspace, or “radar handoff” them to an approach control center.

 There are other jobs involved in ATC that have nothing to do with “A” at all.  For instance, there are an entire class of controllers who actually only control planes while they are on the ground.  Ground Controllers help assure safety while planes maneuver around the tarmac on their way from the terminal to the runway.  And that can be every bit as busy as “Air” control at a busy airport.

There are “Flight Service” positions where personnel offer in-flight assistance and guidance to aircrews on subjects ranging from weather conditions to emergency procedures to use during a mechanical malfunction.

It’s a very diverse field.  But it remains that all ATC positions require a certain amount of natural skill and all involve a higher than normal amount of daily stress.  This is the reason for the (relatively speaking) young mandatory retirement age, which at my time was 51.

One thing to keep in mind is that the FAA ATC Academy has changed in recent years.  The washout rate in Academy used to be more than half.   The job is “high stress” and has high safety requirements.  The job of the Academy is to weed out people who are not a good fit for the lifestyle or who are, frankly, not cut out for it.  But in recent years, with the “ATC shortage”, the Academy taken a purely (in my opinion) political tact and is passing almost everyone who makes it to the Academy and is instead letting them “washout” in the field on their first duty assignment.

It can be a rewarding job.  In my case, at the critical moment when I left the A.F., while the normal route of us military controllers was to switch over to FAA, I decided instead to switch over to computer software development and database work.  And that’s what I have been doing ever since.

A Toast to Brent!

I owe this to Brent Ozar.

I’ve been a “dba” for a long, long time.  But not an “official” DBA.  It was always an adjunct function to my regular developer duties.  I’ve been a long time “Development DBA”.

In 2008, I started reading Brent’s blog.  It was Brent who lit the fire in me to become a REAL, production DBA.

I started as an ASP/Java/DBA, and then took Brent’s encouragement to quit a full time developer job to pursue (and land) a position as a Production DBA managing the Dept. of Housing and Urban Development’s SQL Servers.

And now, I am happy to announce, that experience has brought me to the level where I was bold enough to pursue (and land, as of today) the Production DBA position for the Tulsa Technology Center.

I’ve gone from managing much larger databases to (probably) much smaller databases; but much more of them and in a much more diversified environment.  Whereas I currently manage three large (VERY large – terabyte class SQL 2005) servers, I will now be managing 20+ production servers spanning SQL Server 2000, 2005, 2008 and 2008 R2.

Ladies, and Gentlemen, I propose a Toast to my esteemed, and yet unknown mentor:

Brent Ozar!

Thank you Brent for inspiring and motivating me!

Does “Denali” portend the end of OLAP?

Question for you guys:  Will Denali be the end of OLAP?  Or perhaps OLAP as an adjunct or “tack on” technology? 

Microsoft claims Denali will “dramatically increase query performance ~10x and reduce performance tuning through interactive experiences with data for near instant response times and streamlined setup which removes the need to build summary aggregates.”

All these are the very selling points of OLAP.  So, what do you think the future holds for OLAP either as a technology at all, or at least a technology distinct from the core technology services of SQL Server?

It sounds to me like they are either making it unnecessary, or folding it into the native services.

Anti-Oopsie Tip of the Day

We’ve all done this. You know you have. Here’s the problem:

When scripting a Stored Procedure, you don’t save the script. You execute the script to create the stored procedure. Then you throw the script away, and execute the stored procedure.  However, quite the opposite is true when you are scripting a query or task in a query window. In this case, to run the thing you do in fact have to execute the script to run it.

This causes me no end of “oopsie opportunities”. I work a lot in stored procedures, so I’m very accustomed to thinking “Execute to Save”. But when I start writing a script to do a lengthy ad-hoc update, or a mass delete, or to kick off a lengthy backup procedure, hitting “Execute to Save” will give me a nasty suprise: the script starts doing it’s nefarious deed – immediately!

Here’s a tip:

At the top of your ad-hoc, one-off scripts, make the very first line “RETURN”. And be sure to code the rest of it using NO “GO” Statements (explained in a moment).

That way, if you inadvertently hit the “Execute” button, all it does is run and then immediately end. Then, to actually run the script, you highlight everything EXCEPT the first line, and execute that. And off it goes, doing what you want, but most importantly, doing it as planned.

The reason you need to NOT insert any GO statements is that each “GO” creates a seperate “batch” in your script. If there is a GO statement, anywhere in the script, then the “RETURN” on the top line will only make it jump to the first line after the very first GO statement and start executing there. That could be even worse than what you are trying to avoid, so use this tip with caution.