Blog

I’m returning to the land of great cars, superb beer, and friendly database administrators.  In June, I’m visiting four cities in four days to do eight presentations.  Ready, set, go!

Monday 21.6 – Munich, Germany
Expert Campus on SQL Server

I’m presenting, “SQL Server Storage: Files, Filegroups, Partitioning, & More.”

It’s hard to find good information about SQL Server storage.  Should you put data and log files on different drives when they’re on a SAN?  How do you know when to add more data files?  Is there an advantage to using multiple filegroups?  Brent’s a former SAN administrator and wrote the storage chapter of Professional SQL Server 2008 Internals and Troubleshooting.  He’s got the answers you’re looking for, and he’ll help demystify what SQL Server’s doing inside the black box.

Attendees will learn:

• Why you shouldn’t add files to an existing filegroup
• How to get faster performance from TempDB
• How to check your file performance using DMVs

Other speakers at the event include George Urban and Michael Sass.  You can register for the Munich event here.

Tuesday 22.6 – Cologne, Germany
Wednesday 23.6 – Berlin, Germany
Meet the Experts with Brent Ozar

Gorgeous German

I’m presenting a few sessions at these:

Performance Tuning for Race Car Drivers

Times are tough even for the best drivers: Helio Castroneves is dancing for money and Danica Patrick is doing ads for what appears to be an adult services company.  Maybe it’s time to switch careers, and Brent has just the thing.  Use your hard-earned knowledge of high speeds, million-dollar hardware and surviving disastrous crashes to become a SQL Server performance tuner!

In this session, Brent will show you:

• Why Colin Chapman would check for indexes before adding new ones
• The importance of well-tested safety gear to performance tuning
• Why not monitoring your servers is like overdriving your headlights
• Just like races are lost in the pits, uptime records are lost during maintenance windows

The Top 10 Developer Mistakes That Won’t Scale

You’ve heard it before: “It worked fine on my machine, but the users say it’s too slow.” Don’t blame the developers: they’re using SQL Server features that look great on paper, but in reality, they won’t scale up to production loads. Learn to recognize these common mistakes before they go into production, and be armed with easy fixes for:

• User-defined functions that go through too much data
• Triggers that perform business logic
• Cursors that process data row by row

Virtualization and SAN Basics for DBAs

Brilliant Bavarian

These two technologies can make a very big – and very bad – difference in how your SQL Server performs. Wouldn’t it be great if you could get the real, honest lowdown from a virtualization administrator, a SAN administrator, and a DBA? Wouldn’t it be even better if one person had done all three, and could give you the pros and cons of each point of view? That person is Brent Ozar, a Microsoft Certified Master who’s been there and done that.

• Three things you should NEVER do when virtualizing SQL Server
• Three things you should ALWAYS do when using SQL on a SAN
• Three metrics you should always capture on virtual & SAN-connected SQL Servers

You can register for the free Cologne and Berlin events here.

Thursday 24.6 – Vienna, Austria
Solid Quality Summit

Adorable Austrian

I’m heading to the home of PEZ to present “Virtualization and SAN Basics for DBAs.”

These two technologies can make a very big – and very bad – difference in how your SQL Server performs. Wouldn’t it be great if you could get the real, honest lowdown from a virtualization administrator, a SAN administrator, and a DBA? Wouldn’t it be even better if one person had done all three, and could give you the pros and cons of each point of view? That person is Brent Ozar, a Microsoft Certified Master who’s been there and done that.

• Three things you should NEVER do when virtualizing SQL Server
• Three things you should ALWAYS do when using SQL on a SAN
• Three metrics you should always capture on virtual & SAN-connected SQL Servers

You can register for the Solid Quality Summit Vienna here and hear sessions by Itzik Ben-Gan, Rushabh Mehta, Thomas Grohser, and more.

My fingers are crossed that this will be my first good European trip for Quest.  I’m batting 0 for 3 so far – my 2008 trip was rough, my 2009 trip was a mess, and my spring 2010 trip got canceled when the volcano erupted.  My personal vacations to Europe are always great, but my work trips, not so much.  Wish me luck!

I don’t usually get involved with issues like this, but I think it’s time I step in to help.

SQL injection caught on film

Your SQL Server environment is a disaster.  There’s data spilling out all over the place.  Users are writing bad queries, developers are throwing triggers in all over the place, and your BI team is about to give every mid-level manager a PowerPivot spreadsheet with umpteen gazillion rows in it.

The KILL command in T-SQL just isn’t getting the job done, so I’m working with Microsoft to implement a new command: TOPKILL.

Q: What does it do? A: It puts a stop to runaway queries that are destroying your environment.

Q: How does it work? A: By using dirty reads.

Q: Why doesn’t anything change when I run it? A: You have to wait two days to see results.

Q: Aren’t you the guy who wrote the JUNKSHOT command? A: This one will be better.  Promise.

Most SQL Server DBAs don’t even like MySQL, let alone NoSQL.  They cringe when they hear people say things like, “I don’t need transactions” or “The data will eventually be consistent” or “Indexes will be supported in the next version.” SQL Server and Oracle people are constantly trying to out-feature each other, and the abject lack of features in the NoSQL world comes as a complete shock to both parties.

Thing is, NoSQL and cloud databases do fill some very real business needs.  Today, I’m going to give you a peek into the NoSQL/cloud-database world. You can be a better database professional if you understand what these tools are trying to achieve, who wants to use them, and how your database compares with theirs.

Let’s start at the beginning: who needs this stuff? To answer the question, let’s look at a few common projects that are probably happening right now in your company with conventional databases.

Use Case #1: Logging High-Volume, Low-Value Data

Most companies have a web filtering system that makes sure employees aren’t surfing dangerous sites during business hours. They want to reduce their Internet connection needs by eliminating streamed music or video, and they want to avoid sexual harassment lawsuits caused by employees surfing for porn at work. The filtering system maintains two databases: configuration data such as employees, departments, and blacklisted web sites, and monitoring data that covers who surfed for what, and when. The config data has to be perfect – we can’t have our configuration data disappearing, but that isn’t too big of a problem because it’s a fairly small amount of records.

I can always tell who surfs the dirty sites.

The monitoring data is important, but not all that important. We want to capture as much history as possible, and we’re going to be inserting data fast and furious, but it wouldn’t kill us if we missed a few rows. Odds are someone won’t surf for illicit material just once – they’ll do it repeatedly over time. We don’t make money on this data (although we could make an argument that it helps us avoid risk) so the CIO isn’t prepared to spend a fortune archiving Johnny’s Google searches. The only time we query this data is when HR wants to check Johnny’s web activity – we don’t need to run fancy reports to see the average web use by department.

This system could live without fancy transactional backups. We just need to do a full backup periodically – even once a week or per month would be fine if it saved us a lot of money. When it goes down, we don’t need to restore it quickly – or maybe not even at all, if HR doesn’t ask for a report. We just need to set up a new database to start taking inserts again.

What if we had a way to store multiple terabytes of this data on commodity hardware that would have a very low cost, pretty high availability, but might not give us very good reporting options or transactional consistency?

Use Case #2: One-Time, One-Way, Big-Load Analysis

When a company’s data gets large enough, they start asking questions about what the data might reveal. I’ve worked with PhD’s and analysts who say things like, “I need a copy of the data warehouse to solve a problem I’m working on. I’ve got a hunch about the numbers, and I’ll need to do a week or two of slicing and dicing to figure things out.” It’s just one or two rocket scientists working on the data for a relatively short amount of time.

They don’t want to synchronize the company’s incoming data with this research dataset, and they don’t need to back it up. They just want you to hand over the data, and then you won’t hear from them again. If it goes down, that’s okay – it doesn’t affect sales. Sometimes they use their own SQL Servers, sometimes analytic tools, sometimes its plain old Excel or Access. They won’t write production reports on this data – they’re just going to dive into specific queries and analytics, and then write PowerPoint decks or white papers on the results.

They might do similar projects like this over and over with different datasets from different areas in the company, but they use fresh sets of data every time. They could use a completely different toolset each time without training worries – these are rocket scientists, after all.

What if you could give them a tool that could handle rapid loads of completely different data each time, perform wild and crazy queries, but it might not use traditional query tools or database languages? These users aren’t proficient with SQL queries or RDBMS technologies anyway – they could use anything as long as it’s cheap and scales well.

Why Not Use SQL Server or Oracle?

Mozilla Labs Test Pilot Project

I bet you’ve run into projects just like these in your career, and until now, you’ve solved them with the only tool you really know well – relational databases like SQL Server.  SQL Server, when properly configured and managed, doesn’t blink at the requirements of most NoSQL projects.  Take the Mozilla Test Pilot experiment:

• Expected amount of data stored per experiment: 1.2 TB
• Expected peak traffic: approximately 75 GB per hour for two 8 hour periods following the conclusion of an experiment window.  This two day period will result in collection of approximately 90% of the total data.
• Remain highly available under load
• Provide necessary validation and security constraints to prevent bad data from polluting the experiment or damaging the application

Here’s my personal take on it – NoSQL doesn’t mean NoSQLServer, but rather NoMySQL.  MySQL doesn’t scale as easily to these levels, whereas it’s not much of an event anymore for a single-node SQL Server to scale to multiple terabytes.  I’ve worked with plenty of SQL Server data warehouse systems that have much larger volumes and loads of data than this.  In the last month, I’ve worked with two in particular that ran on less than $50k of commodity hardware.

It’s not that SQL Server or Oracle can’t scale to these levels.

It’s that NoSQL and cloud databases have a few crucial differences about how they scale.

NoSQL Has a Different Cost Model

If you’re doing multi-terabyte databases, you probably need SQL Server Enterprise Edition, which is licensed in one of two ways:

• $27,495 per CPU socket for unlimited users, or
• $8,592 per server plus $164 per user (unless the user already has a SQL CAL)

When you start a SQL Server project, you need to have an accurate CPU count and stick to it.  If you decide halfway into the project that you need a lot more power to get the job done, you have to buy more licenses.  These licenses stick around, and that long-term overhead becomes a business problem.  Businesses don’t like to see expensive software licenses not in use when a project isn’t doing number-crunching.

In addition, even just four sockets of Enterprise at $35-120k is a lot of money that could be spent on hardware – and therefore performance – instead.  Even if SQL Server was 50% faster than a competing solution, that advantage is negated when the user spends 50% more on hardware instead to get the same speed at a lower overall cost.  Tough sell.

The advantage of buying an industry standard database with a long history (whether it be DB2, Oracle, SQL Server, or Sybase) is that it’s relatively easy to find staff and software that interact with that database.  NoSQL and cloud databases, on the other hand, come with no up-front licensing – but because there’s no established industry standard, it’s very tough to find experienced staff off the street.

An early build of MulletDB

How do I hire experienced NoSQL-savvy-staff when the very NoSQL databases out there keep changing?  Here’s a sampling of announcements from one 24-hour period:

• New Type of Database Gets High-Profile Funding (FluidDB)
• Postgres and Ingres Father Announces VoltDB
• Announcing MulletDB (SQL in the front, NoSQL in the back)

NoSQL solutions have different costs.  Immature platforms suffer from a lack of documentation, tooling, and commonly-needed features, thereby driving implementation costs up.

But is that really a problem?  There’s an abundance of documentation, tools, and features for Microsoft SQL Server, but I almost never see it implemented correctly. Just because there’s a manual doesn’t mean anybody’s going to read it or heed it, and just because there’s a tool doesn’t mean users will use it appropriately.  It’s easy for me to hire SQL Server people off the street, but that doesn’t mean that they’re good, either.

The best NoSQL solutions solve the human cost problem by building in the things you need in order to scale, store data, and consume data.  It’s not all that hard, either – the scenarios I described in the beginning of the post had one thing in common: a very limited number of features.  Some NoSQL and cloud database users need to insert a lot, and they need to run very specific queries, but that’s about it. This is where open source products can really shine – they need even less features than MySQL has.

NoSQL Makes Smart Compromises to Achieve Scale

Right from the start, cloud databases and NoSQL projects aimed to scale out. Whether you’re using pizza boxes or virtual servers in the cloud, you can get more capacity by throwing more of them into your resource pool and letting the platform spread the load around.  The Visual Guide to NoSQL Systems illustrates the compromises – between consistency, availability, and partition tolerance, you can pick any two. If every client needs to see an identical copy of the data, there’s an app for that. If you can tolerate different query results in exchange for higher availability, there’s plenty of choices for that too.

MongoDB’s feature set is a good example.  They tout:

• Auto-Sharding – Scale horizontally without compromising functionality.
• Replication & High Availability – Mirror across LANs and WANs for scale and peace of mind.
• GridFS – Store files of any size without complicating your stack.

If I was a business manager, I’d take those bullet points straight to my database team and ask, “Can our database do this?  If not, why don’t we try MongoDB for our next project?”  If the use case matches one of the two I described earlier, it might be a better fit than SQL Server.

No, you can’t have your cake and eat it too, and NoSQL systems don’t support anything even remotely near SQL Server’s feature set.  Forget things like joins, stored procedures, triggers, spatial indexes, CLR in the database, foreign keys, and so on.  As a performance tuner, though, that list makes me grin – because for years, I’ve been telling programmers to keep their CPU-intensive work out of the database server if you want to scale.  The NoSQL camp understands the importance of that.  These systems are about storing data – period.

No Licensing Revenue Means No Buzzword Features

From my SQL Server 2008 R2 review

In my SQL Server 2008 R2 review, I lamented that the last couple of versions of SQL Server have focused heavily on Business Intelligence because it’s a sexy buzz-phrase that sells licenses. I imagine Microsoft marketing thinks of customers as saying, “We’re a business and we need intelligence – get me some of that SQL Server!” Don’t get me wrong – I’m all for BI – but sometimes it feels like buzzwords get emphasized over basics, like working IntelliSense for all versions of SQL.

Since NoSQL tools are built by the users, they’re fat-free. If nobody needs it, it doesn’t get built. On the other hand, if one very determined person needs it badly, that person builds it or pays someone else to build it.

This leads to some interesting design decisions. Many of the NoSQL tools have abandoned any sense of schema – they want to store chunks of data, but that data layout can change at any time with no rhyme or reason. Take our web filtering example – if we design our application to suddenly start saving more information, like the browser agent or the remote site’s web server type, we can do that without a problem. When we pull the data back out, we need to handle whatever kind of data we find, but we’re not worried about joining this data to another table. It’s just flat web history data without relationships.

No Licensing Revenue Means Different Development Models

Five years ago, Microsoft wanted to conquer the VLDB market, so they poured money into making SQL Server scale better.  SQL Server 2005 took on the “SQL Server can’t scale” challenge and knocked it out of the park.  We got things like partitions for fast data loads, DMVs for easy management, and online piecemeal restore for quicker disaster recovery.  Microsoft’s business decision to go after large databases paid off for SQL Server DBAs everywhere because we could use our skills on progressively larger databases.

When you pick a NoSQL or cloud database provider, the first question to ask yourself is, “Who will be developing this thing next year?”  If the platform doesn’t have a really strong developer infrastructure, and your company runs into a data storage problem, the answer might be you.  I dunno about you, but I’m pretty good at administering databases – but absolutely useless at coding them.

That means long-term customers should either:

• Choose a database with a commercial company supporting the development
• Have coders on staff who start getting familiar with the project’s source code
• Consider sponsoring development of the database.  Sponsored open source development is a foreign concept to most businesses, but I’ve seen it work well even in small dollar amounts.

On the other hand, short-term customers have a completely different decisionmaking process.  Consider the second use case I described – repeated one-time, one-way analysis projects.  In that case, who cares if the database platform is still being developed a year from now?  Your database team is probably already used to repeatedly learning new systems for data import/export, and they’re skilled at techniques, not just technologies.  They’ll be comfortable switching to another platform if development dies off or if another more attractive platform comes out.  So how do you pick the most attractive platform?

How I Would Choose a NoSQL or Cloud Database

Ignore throughput performance benchmarks. The market and the tools are changing way too fast.  By the time a well-written benchmark comes out, it’s outdated in this rapidly evolving environment.  Poorly-done benchmarks can come out much quicker – but they’re not good for making decisions.

Focus on developer performance. How fast can you get started deploying and storing data in it?  Shaving days off the development time will probably outweigh the computing gains, especially since you’re going to be throwing your most skilled people at these problems.

Ask the team who will do the work. If you’re a manager on the project rather than a hands-on coder, let the hands-on people decide.  If they have personal connections to someone else using a particular tool, they might be able to get faster answers or code help.

Prioritize difficult-to-code features that work right now. If you need your reporting team to be able to write SQL-style queries against the data, only pick platforms that offer that support today.  If transaction support is important to you, rule out any solutions without it.  Don’t gamble on these challenging features possibly coming out later, because it’s tough to adapt these into existing databases.

Prefer systems that tolerate a node failure. If the database is stored across a dozen cheap pizza box servers, one of the servers is going to go down.  Your data loads and queries should still run while you provision a new pizza box and add it to the system.  Ideally, you want this systems management function to be performed by your infrastructure team, not the database people.  The closer this system comes to being an invisible managed appliance, the lower it will keep your manpower costs.  This feature is extremely difficult to add to a database system – just ask Microsoft, who still haven’t done it yet for SQL Server, and believe me, we’ve all been asking.

I want to end this with a recommendation for a specific NoSQL or cloud database solution, but I can’t bring myself to do it.  After all, the market is still evolving so fast, and I just told you to ask your team who will do the work.  If you’re looking to play around with one, though, I’d recommend trying MongoDB.  It’s the closest to a conventional database while still meeting most of the criteria I’d want for a scaling solution, and there’s even an easy-to-play-with online tutorial so you don’t have to install anything.

But don’t do it from your work computer.

You don’t want SQL Server to know you were cheating on her.

This week we’ve added a BI blogger to the mix, Davy Knuysen.  Davy is a BI consultant for Ordina Belgium and Vice-President of the Belgian SQL Server User Group (SQLUG.BE). He’s been working with SQL since SQL 2000, and these days he focuses on designing & implementing BI solutions.  Some of his recent posts include:

• SSAS Parent-Child hierarchies in Reporting Services – start-to-finish tutorial using AdventureWorks.
• Reporting Services Timeouts in Sharepoint – which timeout should you set?  Davy shows where the Sharepoint timeouts are.
• SSAS custom format strings for “duration” – using MDX.

Most of this stuff goes flying over my head because I’m not a BI guy.  Every time I read blogs like this, I’m reminded of how different BI work is from SQL Server engine work!

If you’re interested in syndicating your blog at SQLServerPedia, drop us a line at ask@sqlserverpedia.com.

In high school, my dad’s side of the family had a restaurant and bar in Whitehall, Michigan.  The Galleon was a high-end (well, for the local price range, anyway) seafood and steak restaurant on the shores of White Lake, and we catered to the tourists and well-off locals with a taste for the finer things.  Between the restaurant’s target market and my family’s penchant for alcohol, I just bypassed the whole beer thing and went straight for the hard stuff.

Ayinger Celebrator and The Beer Trials

I never tasted a beer until the ripe old age of eighteen; I went to the University of Houston and someone handed me a Shiner Bock.  I said to myself, “Hey, this beer thing isn’t bad at all!  I’ve been missing out.”

So I tried a few other beers, and … wow, was I disappointed.  In the early 90s, everybody in Houston drank Corona, and more often than not, that beer left a really bad taste in my mouth.  Literally.  I couldn’t understand why sometimes it was great, but most of the time it tasted skunky.  How could there really be so much variation in the same brand of beer?

For a decade, I stuck with Shiner Bock, venturing out only when a restaurant didn’t have it or when they offered a flight of beers.  I discovered a few other good beers in different styles, and I built up a little repertoire of favorites.  I enjoyed Dogfish Head 90 Minute IPA (thanks to Houston beer guru, IT guru, and all around nice guy Sean Stoner, aka @MaslowBeer), Guinness, a few hefeweizens, and preferred Kirin Ichiban with my sushi.

When Alexis Herschkowitsch, one of the authors of The Wine Trials (see my review), shipped me a review copy of their new book, I gotta confess that I wasn’t expecting much.  I figured they did a file-save-as, called it The Beer Trials, and had tried – and failed – to reproduce the awesome parts of The Wine Trials.  I was very, very, very pleasantly surprised to be wrong.

Thanks to page 52 of The Beer Trials, I now know why Corona is usually skunky. The clear glass lets in unfiltered light in a way that harms the beer.  If I want to find better Corona, it’s just a matter of finding places that know how to store beer properly.  Even better, I can simply glance at a beer bottle and rule it out because it’s got clear or green glass, thereby making it more likely to be skunky.  Presto – book price saved.

Thanks to the categories on page 59, I discovered that Ayinger Celebrator is even better than Dogfish Head 90 Minute IPA.  I’d been trying to figure out what kinds of beers were most like 90minIPA, and I hadn’t been very successful.  I never would have gambled on Ayinger because of its fancypants packaging – I mean, really, a plastic thingamabob hanging around the beer’s neck?  What kind of jerkface drinks something like that?  Well, now, I do, because it’s unbelievably smooth, very rich and complex, and it tastes like I’m drinking warm brown velvet.  That may not sound appetizing, I admit, but that’s why I write about databases instead of beer.

I tried several 9-rated beers out of the book before etching the pixels in stone for this review.  I wanted to know that the book was more reliable than a typical bartender.  I can report that I’m completely satisfied, and the only complaint I have is that the book doesn’t come with a companion iPhone app – at least, not yet.  In the meantime, I’ve typed the list of 9 and 8 rated beers into RememberTheMilk by category so I can access ‘em from anywhere.

Authors Seamus Campbell and Robin Goldstein have pulled off a winner.  Thanks to them, I’ve found several new beers that have surprised me in a good way and made me interested in trying new beers again.  I would wholeheartedly recommend trying any beer rated highly in their trials, and because of that, the book is a downright steal at under $15.  The $15 you spend on this book will pay for itself in the first beer you try.

A few links:

• Buy The Beer Trials at Amazon
• @TheBeerTrials on Twitter
• Seamus Campbell’s blog and his other blog The Daily Wort
• Robin Goldstein’s blog BlindTaste.com and @RobinGoldstein on Twitter
• FearlessCritic.com – where I eagerly look forward to seeing Alexis & Robin’s next work.

Every year, the Professional Association for SQL Server (PASS) holds an international Summit.  This year it’s Monday, November 8th through Thursday, November 11th in Seattle, Washington.

Anyone can submit sessions to present.  If your session is accepted, you get a free registration, saving you around $2,000.  Even if you’re not planning on going to the Summit, you should consider submitting a session if you’ve ever done presentations at the local level.  If your submissions are accepted, you get a free PASS (ha ha ho ho), and your employer is much more likely to send you to Seattle.  It’s cheaper for them, and there’s some prestige for them if their staff speak at national events.  You can submit your PASS Summit sessions here.

Hey Ma, Watch This!

Here’s what I’ve submitted for this year:

Hey Ma, Watch This: Useless and Dangerous Stunts

If you want useful stuff, go to another session. If you’re looking for things to do on your production server, you’re in the wrong place. In this presentation, Brent will be running around with scissors, doing all kinds of oddball T-SQL stunts that have no business in the business world. If you’re the kind of person who loves using a number after the GO statement (like GO 10), then you’ll love this session.

(This is an all-new session that I’ve submitted to SQLSaturday South Florida and SQLSaturday Columbus OH.  I want to present it at smaller events before I try it at the Summit.)

You’re Not Attractive – But Your Presentations Can Be

Come hear Buck Woody (Microsoft’s Real World DBA) and Brent Ozar (SQL Server Certified Master) explain how they make high scores at presentations. It’s not luck, charm or (surprisingly) good looks – there are tips and tricks you can use to make your own presentations rock. With Buck and Brent in the same room it’s much like Forest’s Box of Chocolates, but you’re sure to learn more about presentation techniques that you can extract into your own style.

(If this one doesn’t get accepted, I’ll be seriously bummed. Buck and I have been swapping notes, laughing our rears off as we plan it out.)

Performance Tuning for Race Car Drivers

F1 - Old School

Times are tough even for the best drivers: Helio Castroneves is dancing for money and Danica Patrick is doing ads for what appears to be an adult services company. Maybe it’s time to switch careers, and Brent has just the thing. Use your hard-earned knowledge of high speeds, million-dollar hardware and surviving disastrous crashes to become a SQL Server performance tuner! In this session, Brent will show you why Colin Chapman and Enzo Ferrari would have used index tuning, database mirroring, and other tools that can give you an edge.

(This is one of my favorite presentations.  I originally gave it at SQLbits in the UK and I’ve given it at a couple of smaller online events, but never at a national event in the US.)

Virtualization and SAN Basics for DBAs

These two technologies can make a very big – and very bad – difference in how your SQL Server performs. Wouldn’t it be great if you could get the real, honest lowdown from a virtualization administrator, a SAN administrator, and a DBA? Wouldn’t it be even better if one person had done all three, and could give you the pros and cons of each point of view? That person is Brent Ozar, a Microsoft Certified Master who’s been there and done that.

(I’ve done a few virtualization and SAN presentations over the last couple of years, and I’m trying to distill them into a single “basics” presentation.  I did a webcast on this, and I got feedback that some of the topics were too advanced, so I’m still refining this one.  I’ll probably put an “advanced” one into my rotation for next year.)

My presentation style is really interactive.  I try to write my presentations so that I can go off on wild tangents when it’s a great question that pertains to the presentation.

It slaps! It chops!

In every session, though, I get at least a couple of questions that are good, but don’t quite relate to the topic.  They’re just enough off-topic that it would take me more than 5 minutes to answer.  When that happens, I either point people to a webcast or a book.  Sometimes the book is Grant Fritchey’s excellent Query Performance Tuning Distilled, and sometimes – many times – it’s Professional SQL Server 2008 Internals and Troubleshooting, and my name’s on the cover of that one.

Inevitably somebody groans and says, “Here he goes promoting his book again.”  Wanna know why I do it?

Because nobody else will, and I think it’s worth the money.

When you write a book for a publisher, that publisher has a team of marketing people who want to help promote your work.  One of their tricks is to give free copies out to encourage bloggers to write reviews. They ask the authors who should get review copies of the book.  Rather than guess, I just tweeted, “Who wants a free copy of our book to review it on their blog?”  I got dozens of responses, so Wiley shipped them out back in January.

We got exactly one blog review.  Pinal Dave (Blog – @PinalDave) wrote in his review:

“There is no doubt that this book is by far one of the best books available for anybody who is interested in SQL Server Internals and applying its knowledge to real world troubleshooting scenarios. I think this is one of the must-have books for understanding SQL Server, and believe me, you will find yourself flipping the pages of the book when you are facing a trouble with the SQL Server instead of using search engine!”

So at least it was a good review, so I wanna thank him for that.  We’ve also gotten 8 5-star reviews on the book’s Amazon page, all glowing.  (Granted, a couple of them are from my family, who share my wacko sense of humor.)  But that’s it on the blog front.  I’m not upset with the people who got free review copies and didn’t write reviews.  I know people are busy, and they’ve got real jobs, and it’s a massive book to try to digest.  This post isn’t about them.

This post is about what it takes to have a successful book go out the door.  You can’t bang away on a word processor for months, throw your baby out into the wild, and expect it to fend for itself.  You have to get in front of people and say, “The answer to your question is in here.  I know, because I either wrote it, or I read the work of my coauthors, and I give it My Seal of Approval.”  Chapter 6 on Locking & Latches alone by James Rowland-Jones is one of the best chapters I’ve ever read in a technical book.

I don’t make money off the book royalties.  To put things in perspective, I would have a bigger impact on my money if I changed my health plan from PPO to HMO.  I flack this book because it solves real problems, and I know because I hear the same questions over and over when I present.  How do I troubleshoot deadlocks?  Page 216.  How do AWE, PAE, and /3GB interact?  Page 36.  How should you configure MAXDOP?  Page 163.  How many TempDB data and log files should I have?  That’s page 300.  I could go on and on.

It’s a good book, and if you’re struggling with how SQL Server works, you should buy it.  If you buy it and read it, you should review it, whether you liked it or not, because there’s some really crappy books out there, and your fellow SQL Server professionals need your help to pick the right one.

The ever-insightful Buck Woody (Blog – @BuckWoody) wrote a post telling you to use database schemas.  He writes:

“But I still see a lot of applications, developed by shops I know as well as vendors, that don’t make use of a Schema. Everything is piled under dbo…. But if you’ll use them properly you can make your application more understandable and portable.”

I disagree – and Buck and I started a conversation on Twitter which quickly turned into a group discussion.  It merits more than 140-character comments, but since Buck’s blog temporarily has comments turned off, I wanted to give people a place to discuss.

My thoughts: schemas are naming conventions in lipstick.  When I look at somebody’s code, the last thing I ever think is, “Man, if these tables just had schemas, I could understand everything better.”  In fact, when I see objects broken up into different schemas, I usually end up asking questions like, “Why are we writing user reports against something in the ETL schema?”  The answer comes back, “Well, it used to be an ETL table, but then our needs changed, and we couldn’t rewrite all our code, so it just turned into a production table.”  Great.

If they’re used right, they let you segregate permissions by groups of objects.  But here’s the thing – almost nobody ever does that.  It’s more work than it’s worth except in the largest of databases.  When we’re talking about a vendor app that gets sold to third parties, you usually don’t want anybody jury rigging permissions together – just query through the app like you’re supposed to, and keep your filthy hands out of my database.

Thoughts?

Not going to TechEd, but you wish you could pick up some of those cool vendor freebies?  I got your hookup right here.

Register for a free Quest t-shirt and you’re also entered into a drawing for a $200 AmEx gift card.  Rules and restrictions apply.  Drawing not open to my family members, people who live in other countries, or people who dilly-dally – time limited….