Blog

Microsoft SQL Server 2008 has been released, and the release date was Wednesday, August 6.  Awesome – less than three years since SQL 2005, thereby meeting their goals and keeping the whole Software Assurance benefits worth the money.

You can download it now if you’ve got an MSDN subscription – those are a great deal at around $300 per year.

SQL Server Performance has a good summary blog entry talking about what’s great with SQL 2008.

I’ve started rebuilding my machines & demos for my SQL 2008 presentations over the next couple of weeks.

This weekend, we changed our travel plans and headed back home to Houston instead of driving on out to California.  We probably should have checked the maps a little more carefully – particularly this map:

Tropical Storm Edaeiou(and sometimes y)rdo is heading right for Houston tomorrow.  Both Ed and I have conflicting reservations at the Houston airport tomorrow, and I have the feeling he’s going to win.

I’m worried about the effects of this storm.  My spell checker is already screaming in agony.  Sean Stoner suggested that this name was probably sitting on the shelf for years, and the hurricane planners pulled it off the shelf when they saw it was only going to be a short storm, figuring they’d lessen the damage.

Jason Massie (aka StatisticsIO.com) wrote a blog post this week called The Death of the DBA.  He talks about why the coming cloud computing craze creates career chaos.

I have the exact opposite opinion: I can’t wait for databases to move toward the cloud because it makes database administrators even more vital.

Reason #1: Cloud computing costs real money, and DBAs can help cut costs.

When you move your database into the cloud, your cloud vendor starts billing you on a per-month basis for CPU time, memory, and storage space.  Normally, when DBAs say they cut costs for a company, they’re talking about funny money: if we optimize indexes and cut storage space by 10%, we don’t suddenly get cash back.  When software is a service, though, we will see real savings, a real reduction in our next monthly cloud bill.

Cloud vendors won’t get involved in tuning indexes, cutting storage space, optimizing memory and cleaning up CPU cycles because they make money off bad application design and bad production decisions.  Want to make a bunch of duplicate indexes on your Amazon EC2-hosted MySQL server?  Knock yourself out – Amazon’s happy to let you do it, and they make more money off every bad decision.  Go long enough without a DBA, and the applications will start racking up big monthly bills.

Reason #2: Disaster recovery becomes even more important.

How many of us have been shafted when some kind of third party provider suddenly closed up shop in the middle of the night and disappeared?  Think back to the online storage craze in the initial dot-com boom: everybody and their brother was offering online storage space for free or for cheap.  Some of the providers are still around, but most of them folded up and died, taking user data along with them.

Disaster recovery no longer just means preparing for your own business failures: with cloud computing, it means preparing for the failures of your cloud vendor too.  No cloud vendor is too big to experience problems: check out the Amazon S3 outage in July 2008 and the Amazon S3 outage in February 2008.

Reason #3: Web hosting hasn’t killed the need for sysadmins.

Web sites have been hosted at third party hosting providers for more than a decade, but try calling your hosting company and getting good help with a problem.

I just recently chatted with a sysadmin who sat through a grueling contract renegotiation with their hosting provider.  They’re spending tens of thousands of dollars per month on hosting, and the hosting provider touted all kinds of advantages like redundant internet connections across multiple datacenters.  Come to find out – they only had a single datacenter, and were thinking about growing to another one.  The hosting provider also mentioned that they had the right to move machines between datacenters at any time without warning as part of planned maintenance windows.

Without a skilled sysadmin, these unfortunate problems wouldn’t have come to light, and the poor client would have only found out when their machines went down and came back up with new IP addresses.  This is a huge security risk for the client, who has to pay external security auditing firms to verify that their private data is in good hands.  They would have to redo their security audits and fork out big bucks.

Does third party hosting solve solutions and offer value?  Absolutely.  But does it eliminate the need for administration, security auditing, day to day maintenance, planning, and app design?  No way.

Reason #4: The economy of scale means it can be cheaper to manage your own servers.

Say three companies came out right now offering SQL Server hosting services:

• Company A offers no-frills hosting for $X per month
• Company B offers hosting with backups & restores for $X * 1.5 per month
• Company C offers managed hosting with backups, restores and performance tuning for $X * 3 per month

Your company has to evaluate each hosting option, and the larger you get, the more sense Company A makes.  At a certain number of databases, you’ll save money by doing the management yourself.

Company C can’t offer management features without paying for DBAs.  The DBAs have to work somewhere, and you can bet that Company C will heavily mark up their DBA costs because everybody has to make money somehow.

Reason #5: Security & SOX compliance.

I did a short stint at a major financial firm who wouldn’t even allow their employees to get their email over the web.  Imagine putting their financial data on databases in “the cloud” – no way.  Private companies might be able to get away with it, but after a couple of security scares (think lost tape backups) the paranoia will set in.

I can already visualize the ads for consulting companies.  “Think your data is safe in the cloud?  How do you know Mr. Hacker Guy isn’t connecting a USB drive to your server right now?  Pay us and we’ll find out.”

Reason #6: Do you stand next to your servers now?

The good DBAs I know don’t work in the datacenter (except when it’s time for OS reinstalls, and these days a lot of that is handled with imaging and deployment tools).  They work from a cubicle, office, or coffeeshop miles away from their servers.  We don’t have to put our hands on the servers, and they could be anywhere.  I’d love for my databases to move to the cloud, because it makes it easier to justify telecommuting.  Preferably from a beach.  With margaritas.  (Might be able to expense those during meetings, too.)

Bottom Line: The cloud is coming, but it’s not going to rain on the DBA party.

Now is a great time to be a DBA, and while I think there are disruptive computing forces on the horizon, I don’t think the cloud is going to put an end to the DBA career.

So what about the future is going to change the DBA career in say, five or ten years?  Well, as RAM and solid state disks get cheaper, I can foresee the day where databases run entirely in memory and just back up to disk.  Performance tuning becomes less of an issue, and we get to focus on functionality instead of the number of bytes an index will take.

Think back ten years ago in general computing & programming: people were still writing programs in assembly because they needed the speed.  Now, raw speed of an app isn’t as much of an issue for general programmers and they get to focus on which cool new language will make the programming faster, not the code execution.

To me, that’s really cool and exciting.  It means in a few years, we might be able to do more data mining and predictive analysis with even the most basic, everyday databases.  I might be able to say, “Man, remember when we had to worry about the number of indexes on a table?  Wow.  Yesterday sucked.”  That’s awesome!

We’ve packed up the Honda and we’re heading out this morning on a road trip of epic proportions: Just over 5,000 miles. Erika, Ernie (our miniature Schnauzer) and I are driving from Houston to Memphis today, overnighting there. On Sunday we’re continuing up to Muskegon, Michigan to spend some time with Dad and Caryl, my stepmom.

Next up on the itinerary: a slow drive across the country to Aliso Viejo, California to the Quest offices. I’ve got some meetings there in early August for the LiteSpeed v5 RTM party.

Finally, we’ll drive through Arizona and New Mexico to get back home to Houston.

Shortly after arriving back in Houston, I’ll fly back out to Michigan again, this time to speak at the West Michigan SQL User Group and Detroit SQL User Group.  (If only these meetings would have been two weeks prior, I might have been able to expense this whole thing!  Wouldn’t that be hilarious.)

This whole thing will take between two and a half to four weeks, depending on how we mix it up.  We have a couple of alternate plans in case we want to spend more time in a specific area.

Our only concern: we won’t be able to go to as many cool restaurants since we’ll have Ernie with us.  Ah, well – that’ll keep the road trip budget down, at least.  Speaking of budget, gas prices were enough of a concern to make us take the Honda instead of my beloved Jeep Wrangler.  33mpg versus 15, hmmm, lemme think about that – no.

You can track our progress on BrightKite or on Flickr, and I’ll blog periodically.  I’ll still be working (love ya, AT&T) so I’ll be doing work-related blog entries on here too as usual.

An important email just came out from the Microsoft SSDS team about this week’s upgrade.  The second bullet point in the impact alert is especially important, and everybody needs to take note.  Here’s a screenshot:

Got that?  Good.  To be a good DBA, it’s important to be able to read Wingdings.

A friend of mine is competing in the 100th annual Chicago-Mac race, a sailboat race up Lake Michigan from Chicago to Mackinac Island.  This year they gave out GPS tracking devices so you could follow your favorite boat’s progress during the race.

Now I’m not saying anybody cheated, but the route of the Hannah Frances is a little unorthodox:

Last night, the author & editor of The Wine Trials held a release party at the Caroline Collective, the Houston coworking office where I lay my weary laptop.  Robin Goldstein and Alexis Herschkowitsch talked vino, signed books and raised glasses.  I liked them, and I liked the book, and I’ll tell ya why.

I’m just a regular guy.  When I go to a restaurant or a wine shop, I don’t want to dazzle anybody with a deep knowledge of wine.  I just want to spend a reasonable amount of money (say, two or three glasses should cost less than an entree) and drink something that tastes as good as what I’m eating.

I don’t have a very sophisticated palate (mmm, donuts) and I gotta think there are some wines that basically taste good to everybody – like, well, donuts.  You don’t need a sophisticated palate to like donuts – you just like ’em.  Granted, there are a few wackos who don’t like donuts, and there are a few of us who have graduated to beignets, but walk into any office meeting in America with a box of donuts and you’ll win friends and influence people.

So how do we find wines that are the equivalent of donuts – beverages with a wide, almost universal appeal and reasonable donut-style pricetags?  The Wine Trials took the approach of a large quantity of blind tastings: hundreds of people sampling wine from brown paper bags.  (Sounds a lot like downtown Houston, only with feedback forms for each wine.)  Their tastings covered wines in all price ranges, but they focused the book on the top 100 wines under $15.

My test for any review book is to open it up and read their opinions about something I personally have tried and know well.  Erika and I are on a champagne kick at the moment, and Editor’s Pick in the book is Friexenet Cordon Negro Brut.  Sold – that’s our second favorite budget bubbly, and I can forgive them for not including our favorite (Francois Montand) because it’s nearly impossible to find.

You can buy The Wine Trials from Amazon.

In related news, today is Champagne Friday at Caroline, and in honor of Robin & Alexis, we’ll be serving Friexenet.  If you’re in the Houston downtown or museum district area, come join us for a glass.

And here’s a Craigslist ad to prove it:

I’m a DBA, not a programmer, but I subscribe to Jeff Atwood’s excellent Coding Horror blog because it’s well-written, funny and teaches good lessons.  In his latest post, he talks about database normalization – when to do it and when to avoid it.

Pay particular attention to the links to HighScalability.com – they have great stories about scalability problems and lessons-learned from really big sites like YouTube and Twitter.  Read those stories and know ’em well, because that’s the easiest way to learn some really expensive lessons.

Jason Massie tagged me, so it’s my turn to answer the questionnaire….

How old were you when you first started programming?

Dad and Mom upgraded us from an Atari 2600 to a Commodore 64 when those came out, so I must have been around 9-10.  I don’t remember much from those early attempts at programming, but I remember being really frustrated that there was so much typing involved to copy the stuff from magazines into my own computer.

See, I have this mental problem where I don’t want to do something unless I can be really successful at it in a short period of time.  That problem is often defined as laziness, but I’m not lazy – I don’t mind working really hard, but I don’t want to STRUGGLE really hard.  I will work 20-hour days, but I wanna know that I’m actually achieving great things, not trying to accomplish something basic.

Typing long, boring lines into a computer, especially lines that I didn’t think up, definitely fell into the category of time wasters.  It’s one thing to pour your ideas out into a keyboard, but it’s another thing to transcribe somebody else’s ideas, character for character, and then try to hunt down your typos without a debugger.

(That same mental problem is what kept me out of sports!  Practice for weeks just to be able to shoot a free throw?  You’re out of your mind….)

How did you get started in programming?

Lemme tell you how I didn’t get started: I vividly remember Mom forcing me to do piano lessons, and Dad forcing me to do soccer.  Neither of those hobbies stuck in any way, shape or form.  I don’t remember how I got started in programming, but I remember poking and peeking around on my own, so I bet I ran across it in a magazine.  I was a voracious reader.

What was your first language?

BASIC.  (Makes me chuckle because future generations will respond to that question so differently.)  I think my second language, if you can call it that, would have been DOS batch files, though.  I really, really enjoyed MS-DOS.

What was the first real program you wrote?

To me, it’s not a real program until the first user signs on.  That’s when you find the real bugs, the real shortcomings.  My first real program was a help desk front end written in classic ASP.

Our company was growing by leaps and bounds, and McAfee wanted absurd amounts of money for more user licenses for their help desk software.  That software sucked – I mean, reeeeeally sucked – and I said to myself, I could write something better using the same SQL Server back end, save the company a lot of money, and the users would love me because it’d be so much easier to use.  Plus, if I had any ugly bugs, they could use the old Windows console version while I sorted my bugs out.  The company still uses that system today, and it’s had over 100k help desk tickets.  Hooah!

That’s still my favorite rush in programming: walking past somebody’s computer and seeing my stuff on their screen as they interact with it.  I really love knowing that somebody could choose to use any piece of software out there, and they’re choosing to use mine.  That rocks.  It’s like being the cool kid in school.  (Only without the chicks.)

What languages have you used since you started programming?

Trying to think of these in the order of my career:

• BASIC on a Commodore 64
• DOS (yes, I consider batch files a language, especially when they’re hundreds of lines long)
• VBscript
• HTML
• Classic ASP
• Topspeed Clarion
• T-SQL
• Java (the language that made me decide to never learn another language again)

What was your first professional programming gig?

Telman (subsequently bought by UniFocus) hired me on the basis of personal relationships and my hospitality industry knowledge, and then sent me off to Clarion training.  I really liked Clarion, and I haven’t touched it in years.  Makes me want to go play with it now, come to think of it.  Clarion was a database-independent language: in theory, you could change your database back end with a couple of mouse clicks, recompile your program, and hook it up to a different database.

The problem is that when you’re using a particular database, you want to take advantage of the database-specific features that give you better performance or more capabilities.  If your code is generic enough, though, or if you’re willing to invest the time to debug it once, it does work, and I did manage to switch a few apps between Clarion’s proprietary flat files, to Microsoft Access, to SQL Server 7.0.

Telman was also my last professional programming gig.  Clarion was a dying language, so the company had to switch to a “new”, more maintained language – either Java or .NET.  I saw the writing on the wall; .NET would have short-term staying power because it has the Microsoft marketing power behind it, but something else would come along in 5-10 years and knock it over.  I could spend a few years becoming really proficient in Java or .NET – but then have to relearn a new language within a decade.  Why bother?  The ANSI SQL language lasts forever, even across different vendors.

If you knew then what you know now, would you have started programming?

Yeah, because I think it makes me a better database administrator.  No way in hell would I go back to programming, though – I hate finding bugs in my own code.  Stored procs are easy enough to unit test and be pretty certain that they’re correct, whereas code that faces end users – that’s another problem entirely.  Users are crazy.  They click everywhere, they do things that don’t make sense, and they expect everything to work flawlessly.  That is seriously hard work.  I really respect good programmers.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Languages come and go like fashion trends.  Don’t get stuck in a pair of baby blue bell bottom pants: choose a language based on how your resume will look 5 or 10 years from now, not based on what the cool kids are doing this week.

Really, really good programmers can pick up a new language in a heartbeat, but you may not be so lucky.  Spend your time focusing and getting really good at one language, and don’t listen to the siren song of whatever new language is sexy today.  Take database administration: learn to code ANSI SQL today, and you’ll still be using that same syntax in 20 years.  Learn the trendy new LINQ, and you may be relearning something else in a few years.  (I’m not sayin’, I’m just sayin’.)

What’s the most fun you’ve ever had … programming?

Embedding sounds in other people’s help desk tickets with hidden HTML code in the ticket notes.  I embedded the A-Team theme song in a note on somebody’s ticket, so whenever he pulled up his list of tickets, the A-Team song started playing, and he didn’t know why.  When I finally let out the secret, hoo boy, that triggered a flood of embedded sounds and graphics.

Who are you calling out?

Bert Scalzo because he talked me into this sweet job

Brian Knight because reading his stuff is almost as good as listening to his seminars

Conor Cunningham before he goes back to work for Microsoft

Jeremey Barrett because I bet he’s better at programming than he lets on

Linchi Shea because he’s a SAN genius

Rhonda Tipton because I’m seconding Jason’s call-out

Before me, the tag order was something like this: Jason Massie > Denis Gobo > Andy Leonard > Frank La Vigne > Pete Brown > Chad Campbell > Dan Rigsby > Michael Eaton > Sarah Dutkiewicz > Jeff Blankenburg > Josh Holmes >  Larry Clarkin

If you’re using AMD Phenom 3-core processors, SQL Server 2005 won’t install without going through some hoops first.  Microsoft just published a knowledge base article on SQL 2005 errors on 3 and 6 core servers.

I don’t usually blog about knowledge base articles, but I got such a laugh out of that one that I just had to share it.

Want to know about MS KB articles as soon as they’re published?  Subscribe to the Microsoft Knowledge Base RSS feed for SQL Server.  You DO use an RSS reader, don’t you?  Hint hint….

I’m spending a few days in St. Petersburg, Russia to visit Quest’s office.  Sure, I have the regular touristy photos, like myself in front of old buildings:

But what I really like about overseas travel is that everything looks and feels different, and it forces me to look at the design and user interface for everything.

Take toilets, for example.  American toilets have the button on the side, and Russian toilets have the buttons on the top.  That’s right, buttons – more than one:

My first thought when I saw this in my hotel room was, “Ah, that’s interesting.  Now what would be the advantages or disadvantages of putting the button on the top?”  I guess you can’t leave things on top of the toilet if the button is on the top.  With American toilets, you can just pull the lid off, and the button remains on the side, so it’s probably easier to design the lid.  This particular toilet lid doesn’t come off at all, which is an advantage in hotels – tourists hide all kinds of stuff in toilets.  I know this from my years of working in hotels.

My second thought was, “Two buttons?  I’m screwed.”  I’ve been in Europe just enough to have seen bidets, and heard about toilets with built-in bidet attachments.  I half expected water to come shooting up and hit me in the eye, so I stood to the side when I tested the buttons.  Turns out the two buttons have two different amounts of water: regular, and Niagara Falls.  I think I could flush a small cat down this toilet.  Now that’s cool.

Are American toilets better than Russian toilets?  No, they’re just different.  The differences continue throughout the bathroom, like the hooks on the wall:

These have a fun, playful design language, very mid-century-modern.  These would look awesome in an American 1950’s ranch-style house, but I’ve never seen anything like them before.  I certainly wouldn’t expect to see them in a traditional hotel like ours where the paintings on the wall are framed with mock gold leaf.  The hotel is very conservative, and then these bathroom hooks say BAM!  Bathroom fixtures seem to be more modern-looking in Europe and Russia, and more traditional in America.  Dunno why.  Not better, just different.

But wait – there’s more.  Check out the toiletries in my room, but look closely and see if anything looks odd:

In the white box, there’s a nail file.  A nail file!  Wow.  I’ve never seen that before.  I’d be curious to know how often people need a nail file when they travel.  Different.

Plus, the labels are all in English.  Not Russian, just English.  Know why?  Because only Americans are dumb enough to travel without all of their stuff.  And I should know – last week I went to California without any socks, and this week I came to Russia without my electric razors.  Which brings me to this:

It takes a big man to admit he’s scared, and I’m a mighty big man, so I don’t mind telling you: razor blades scare the hell out of me.  There must have been some terrifying experience in my childhood involving razor blades, because I never touch them.  When I was old enough to shave, I bought an electric razor, and I’ve always used them ever since.  Normally, if I forget my razor when I travel, I go buy another one.  But here I am in Russia, and if I bought an electric razor, it’d have their electric plugs, and I wouldn’t be able to use it at home without an adapter.

I said to myself, “You’re so interested in things that are different – why not give it a try?”  After all, I’ve seen Queer Eye for the Straight Guy.  I know how the concept works.  So with shaking hands, I lathered up my face and used a sharp piece of metal to scrape hairs off my face.  (Can you tell this concept bothers me?)

And you know what?  I liked it.  It gives a really nice, close shave, and as long as you lather up with warm water and use a sharp razor, it doesn’t cut your face.

That’s why I like travel.  Different can be better.  I might even stick with razor blades.

In today’s hiring market, DBAs get a lot of emails from recruiters that say things like:

“I am curious to know if you would be interested in (or know someone who is interested in) relocating to Big Falls East for the position discussed below….”

The job description never includes the salary range, and it rarely includes information about the industry – two things that should be important to a job candidate.  (If you don’t care about the industry, you should start caring – imagine going to work for Ford Motors, an airline, or a mortgage company in today’s economy.)

To handle these emails fast, go into your email program and create a new signature.  The signature should include a default reply text that is really generic, like this:

“Thanks for the email.  If you can forward on information about the salary range and the industry, I’ll pass it along to my peers.  After being repeatedly burned (hey, buddy, check out this job – oh, sorry, I didn’t know it only paid $X) I have a policy against forwarding jobs without salary & industry information.  Thanks, and have a great day.”

Most email programs will let you quickly change your signature for one specific email.  That way, when recruiter emails come in, just hit reply, insert your recruiter signature, and hit send.

When the next email comes in (either with the right info, or without it) you can handle it the right way.  If it includes good information, then it’s a good recruiter, and you should pass it on to your buddies.  If it doesn’t include any more information than the first email, just hit delete, because the recruiting process is off to a bad start.

I know recruiters will disagree, but here’s the deal: if a recruiter is desperate enough to send a blind email to a stranger without a resume, asking that stranger to pack up their house and move to another state, then there’s a reason.  They’ve already exhausted the local candidates – either because they’re not paying enough, the company has a bad reputation locally, or they need a hard-to-find skill set.  Think about that before replying with your resume, because the first two reasons will come back to haunt you, and the third reason means you’re worth a lot of money.

Sean McCown at Infoworld wrote a blog post today that said some negative things about Quest and LiteSpeed, and I had to respond. He’s switched away from using LiteSpeed, and he had an interesting set of reasons.

“I just don’t need the centralized repository in my lab, and I do enough demos that having native SQL syntax for my backups is worth something to me.”

Everybody has different needs.

Sean and I would totally agree that labs have a different set of needs than a typical enterprise or datacenter.

In fact, if I was just doing a lot of demos like Sean, and if I wanted native SQL syntax for my backups, I wouldn’t even use a third party product at all: I’d use SQL Server 2008’s new backup compression to make my life really easy. That way, you can stay purely native, and that makes for really easy demos.

Quest LiteSpeed, on the other hand, isn’t targeted just at labs and demos. It’s targeted at DBAs who need enterprise-ready backup solutions, complex needs like log shipping, centralized reporting, log reading with undo & redo for transactions, and so on. Not everybody needs the advanced features that LiteSpeed provides, and Sean doesn’t. We would both agree that LiteSpeed is not the right product for his lab.

“Even knowing any of the devs is hard these days, and getting anyone to make any changes is next to impossible.”

At smaller companies, especially startups with a minimum of customers, developers can work directly with end users. For better or worse, Quest has a lot of customers, and I’d like to think that’s because Quest has fantastic products. (It’s a pretty good problem to have.) Our product managers coordinate feature requests across all of our enterprise customers, large and small, which helps our developers focus on what they need to do: develop great software.

Just this week, in fact, Quest Software hosted a SQL Server Customer Advisory Board at the offices in Aliso Viejo. We flew out a dozen customers for two days of meetings about our road maps, upcoming features, and asking for their input on where we go next. I wish we could bring every Quest customer out there for the same input, but on the other hand, Steve Ballmer isn’t flying me up to Seattle anytime soon to ask me what SQL Server needs to do next.

We’re in a feature freeze for our new LiteSpeed v5.0. The management tools have been rewritten from the ground up, and I’m really impressed. But there comes a point where you have to stop adding new features and just focus on testing the code, and that’s where we’re at now. Heck, I have a long list of things I want to add, but even I can’t sneak ’em in – and I work for Quest! I’m already excited about the features I’m trying to cram into v5.1.

“Now, with the team being more corporate….”

If your main criteria for a backup product is easy access to the guy who wrote it, then Quest LiteSpeed is not the product for you.

Just a couple of months ago when I was a DBA instead of a Quest employee, though, that was not my main criteria for software selection. My main criteria included a global 24×7 support organization with experience across database technologies, a large QA team dedicated to testing mission-critical backup software on every possible platform and a product with an unbelievably strong track record. The fact that Quest was Microsoft’s 2007 Global ISV Partner of the Year again this year is proof that sometimes bigger is better.

Mark Garner came across a great list of free SQL Server tools & utilities.  I took one look at that page, bookmarked it, and realized it’s going to take me a week to go through that list!  Good stuff.