I’m trying to improve.

That’s at just about everything too. I know I don’t know enough or have enough skills to always get things done in an efficient manner, so I’m trying to learn more. One way is by reading, a lot. I’ve read a number of management and leadership books, many of them reviewed on this web site. I just finished the book Business in the Trenches. I really enjoyed it. It combined two of my passions, self-improvement and history, specifically history of World War I. Now, this is a tech, community and business blog, so I won’t go on & on about the Great War (although I could if you wanted). Instead, I simply want to provide you a link to my review of this book. It really is a worthy read that teaches important lessons in a fun and interesting way. That made me want to be sure that you all had the opportunity to learn about it.

The very concept of the Windows Azure SQL Database (WASD) is predicated on the up-time created by having three active copies of your database. Should there be a hardware or software failure that would cause the primary replica to go down, your database gets moved to one of the secondary replicas which has been maintaining a copy of the data from the primary replica. In theory, the worst thing that happens is that you have to retry a query. In fact, building that sort of resilience into your code is a pretty fundamental aspect of working with WASD.

I was asked the question, how do you tell if your database has been moved between replicas. I didn’t have a complete answer, so I set out to find one. The first, more obvious part of the answer, is that you’ll receive a connection error to your app while this event is occurring. Microsoft has a very solid white paper on how to deal with your connections, Windows Azure SQL Database Connection Management. Scrolling down you can see that you’ll receive a very specific error number depending on why you lost your connection. These errors include 40197, which is the number you’ll receive during any of the events that trigger a failover to the secondary replicas. Answer done, right? Well, not exactly.

I knew about the error code, but the real question is, how do you tell if the move occurred while you weren’t connected? Is there a dynamic management object or system view that shows this information? The first thing I thought of is sys.event_log. That’s because it stores aggregated information about connectivity and errors such as deadlocks and throttling. Surely, if you were moved it would be there. But, reading through the documentation there’s no indication of it. And, it looks like that information is stored within the database and is therefore going to be moved (unlike all the information in cache which just goes away).

Speaking of cache, you could try running queries against sys.dm_exec_query_stats to see when the oldest compile time of any given query might be. But, remember, we’re on a shared server with a hundred other databases. Cache is highly volatile. I don’t think I’ve ever seen more than about one day’s worth of information within the cache dependent set of DMOs. In fact, I seldom see more than about an hours worth there and sometimes quite a bit less. So that’s not a possibility unless you set up a mechanism for monitoring your servers and can see a massive delta in what’s in cache between one look at the query stats to the next. But that could still be cache volatility.

Looking through the rest of the DMOs and system views I couldn’t identify anything that definitively answers this question. So, at this point, I’d say, if you don’t get the error, there is no real indication that you’ve moved from a primary to a replica. On the one hand, it concerns me that I don’t know. On the other, who cares. The whole idea behind this approach to development is that the guts of the things are handled by others allowing you to concentrate on building the database and the app code appropriately.

For lots more about Windows Azure SQL Database, sign up for the pre-conference seminar, How to be a Successful DBA in the Changing World of Cloud and On-Premise Data, at Tech Ed 2013 in New Orleans or Tech Ed Europe in Madrid.

You can get backups of your WASD databases. But, if you want them to be transactionally consistent, you need to do a little extra work. This video (with bad lighting at the start) shows how to get the job done.

Microsoft has stated pretty clearly that they’re putting code on Azure first, ahead of the desktop. Which makes one wonder when we’re going to start to see some of this cool stuff within SSMS. What cool stuff you ask? Well, let me explain. Let’s start with a query:

SELECT	m.MovieName,
		msd.MovieStageName,
		st.StageTypeDesc
FROM	dbo.Movie AS m
		JOIN dbo.MovieStage AS ms
		ON m.MovieId = ms.MovieID
		JOIN dbo.MovieStageDefinition AS msd
		ON ms.MovieStageDefinitionId = msd.MovieStageDefinitionId
		JOIN dbo.StageType AS st
		ON msd.StageTypeId = st.StageTypeId
WHERE	m.MovieId = 42;

When I run this on Windows Azure SQL Database (WASD) I get the following execution plan:

Kind of weird, kind of useful, right? First thing new that I can do is zoom in using that slider bar you seen in the lower left and then graphical part of the plan looks like this:

The icons have shifted into the corner and you get the costs of every operator. You also get text describing what the operator does. You can scroll around to see the other operators. Pretty cool stuff. Yeah, I know you can zoom in & out on SSMS, but it doesn’t modify the icons in any way, making viewing it zoomed out all but useless. WASD gets better. Notice the tool bar on the left. I have it here in full size so you can see everything:

Now things get fun. First, at the top, there is a little arrow pointing to the left. You can hide this tool bar by clicking anywhere within it that’s not on one of the icons. The arrow is indicating the possibility of hiding the toolbar. Once hidden, the arrow changes to pointing to the right. Clicking again expands the toolbar. Immediately below that arrow, you see the really fun stuff: Sort by:. You’ll notice that Total is currently selected. This shows me the total estimated cost for each operator within the plan. But, I can modify the display of the plan so that I only see estimated CPU cost or estimated IO cost. The following graphic shows the same plan with CPU selected. See how the estimated cost percentages have all shifted to show the different highlights?

This is a great way to rearrange the view of the plan, bringing out different information. The only beef I have with it is that it doesn’t really sort the operators so much as change the display. I understand what they mean, but I think it’s misleading. Anyway, useful, but I’ve got more. Moving down the tool bar we find the great part: Find by:. Currently on the plans above you can see that None is selected. But what if I select a different operator such as Seek:

Now, each instance of the operator type I selected is highlighted in blue, but, the sort totals for estimated costs are still displaying the numbers in red, so I haven’t lost any of the display that I’ve set up so far. This is wonderful stuff. As you can see, you only get a few operator types, Warnings, Scan, Seek, Merge Join, Hash Match, Nested Loops and Sort. But it’s a great way to begin to explore the plan in ways that we can’t currently within SSMS.

Let’s also note the little icons in the upper right of the plan, displayed to the left in full size. Clicking on these completely changes what’s represented to us from the execution plan. First the little grid looking icon results in this execution plan:

You can click on the graphic to make it bigger so you can see everything. What we have are the operator nodes, listed by Node ID order, showing some of the interesting information from the properties in a grid format. And yeah, because it’s a grid, I can click on any of the column headers and get different sort order for the data. For large plans, this can be a quick and easy way to find the highest estimated cost, or the largest number of actual rows. The grid isn’t a text plan. The grid is just the same XML data that makes up the execution plan laid out slightly differently. Great stuff indeed. What if we click on the little bullet list looking icon?

Now we have a sort of nested display, almost like a human-readable XML. And the little blue icons next to the operator names do allow you to expand and collapse the layout. I haven’t decided how excited I am by this layout because I’m just not sure how I would use it. You can’t resort on the columns even though this looks like a grid. It’s just a way to simplify the display with the collapsible nesting. Still, another tool in the toolbox.

Microsoft is doing some really cool stuff out there on WASD, making the portal there functional and useful.Let’s hope that some of this translates down to the core product.

If you’re interested in learning more about this kind of thing, you should take a look at the pre-conference seminar at TechEd 2013 that I’ll be putting on with Thomas LaRock (b|t) and Dandy Weyn (b|t) in New Orleans and Madrid, Spain. It’s called How to be a Successful DBA in the Changing World of Cloud and On-Premise Data. We’ll spend all day getting you deep into the guts of Azure SQL Database showing how to administer it, tune it, grow it, and make it work. You don’t want to miss it. Click here for New Orleans or here for Madrid to register for this and TechEd 2013.

I promise you, with Tom, Dandy and I all talking at once, this will be informative and entertaining.

Laws of Thermodynamics

TANSTAAFL

Gods of the Copybook Headings

All magic comes with a price

Winter Is Coming

My adult years started with a pretty thorough education in physics thanks to Uncle Sugar and the Navy Nuclear Power School. The laws of thermodynamics were carved into our brains (along with Baumgart’s Law*). Experience has taught me that all these other statements are more or less riffs on the concepts put forward by the fundamentals of the laws of thermodynamics. They’re just applications of the same within social spheres. In short, if you have a physical engineering background, you tend to be a realist. But note, I’m not a pessimist. I just recognize a simple thing. No matter how positive my thoughts are, no matter my belief in the righteousness of our application or business, no matter the utterly sublime nature of our offerings, I can’t make an electron travel more than about 18 inches in one millisecond.

Sorry.

What am I talking about? I’m talking about trade-offs. I’m talking about the fact that you really can’t get a free lunch, that you have to be prepared to pay the piper, that water is wet and fire does burn, that preparations for winter are not crazy. I’m talking about dealing with physical reality as it is, not how we’d wish it to be.

I was talking to a group of people about checking the consistency of your database. I made the suggestion that you should be checking that consistency as frequently as is practical within your system. If it wasn’t problematic for a whole slew of reasons, I’d probably run the check 3-5 times a day. Why? Because, when you get database inconsistencies, it almost always leads to data loss. So, the more frequently you can check, the better. I acknowledge, for most of us, that means we’re probably only checking once a day or once a week. Some of us are checking even less than that, for, debatable, but, probably, sound reasons relating to the nature of the business, the size of the database and the type of data. And, it’s worth noting, I’ve only had about five instances of corrupt databases over a long career.

But, one person from the audience disagreed. This person had systems that required up-time above everything. While he did run consistency checks, he would try to fix errors by deleting & modifying data rather than going to a restore. Up-time was everything. And, while he had more frequent inconsistencies in his databases, by and large he worked around the problems rather than taking the system offline and he saw zero problem with that.

You know what, I’m not going to argue. That may be an acceptable approach for that person, their data and the business they support. But, you need to make that kind of decision with all those sayings above in your mind. Because if you leave a corrupted page in your database, you’re right, it’s no big deal. Until that page gets split or rearranged or something else happens that your corruption suddenly grows. And now it’s not one page (remember, up to 8k worth of rows) but several (all with 8k worth of rows) and the likelihood of additional splits along with additional corruption grows. You can take risks, but you better be prepared for what might follow on to those risks.

You don’t think you’ll ever need to recover to a point in time, so you think log backups are crazy. Cool. Until you need it. Winter is coming. Doing data loads to your system is taking too long, so you turn off automated statistics updates. Saves you time, but you might notice a change in how queries run. TANSTAAFL. No need to run backups because your system is running a on a RAID 5 set of disks. Excellent until your database is corrupted. All magic comes with a price. You think all this crazy talk about storing relational data in a relational fashion is just job insurance for the lazy and incompetent you can force any kind of behavior you need into your SQL Server instance.  And it works great with one row:

And that after this is accomplished, and the brave new world begins
When all men are paid for existing and no man must pay for his sins,
As surely as Water will wet us, as surely as Fire will burn,
The Gods of the Copybook Headings with terror and slaughter return!

In short, you can ignore stuff only so long. Sooner or later, entropy wins. Because of that, you need to make active decisions that bring order out of chaos, not lead to more and more chaos. And, no matter what, you can’t wish stuff into being. You have to do the work to prepare your systems, repair your systems, or maintain your systems.

* Lt. Baumgart was one of our instructors (Heat Transfer and Fluid Flow) and a total geek on horror films. Time permitting, we could get a good horror film conversation started. During those conversations, Baumgart’s Law was created. Baumgart’s Law states: In every horror film, there’s at least one incredibly stupid person. To explain, they usually announce themselves, “I don’t want to go up into the attic where I’ve heard all those horrific noises,” just before they do their incredibly stupid maneuver. This doesn’t always lead to their demise, but they are always there. It holds fairly true.

GAAAAAAAHHHHH!!!!

I feel slightly better, but only slightly.

I started watching Star Trek: The Next Generation on Netflix just to unwind my brain and relax a little. Instead of relaxation I found myself pacing back and forth in front of the television, gesticulating wildly, with a string expletives coming out of my mouth in a torrential flood (yeah, my kids loved it). What happened in the 24th century? Did the entire race of IT Pros die out in the 23rd? Because there sure as heck is no evidence that they are ANYWHERE to be found. Episode after episode there are computer problems. And episode after episode my blood pressure is rising. I can’t believe what I’m seeing.

For example, in one episode they get an alien computer virus (firewall, checksums, anti-virus, hell, common communication protocols, nah) that’s going to cause the ship to run into a star or something. OK. No big deal right. Shut everything down, format the system, reinstall the OS, restore the last good backup, open the Romulan Ale. No, we go through the episode basically ringing our hands and running around in circles, and that’s the engineering crew. The bridge crew just sat there slack-jawed. Then finally some magic is injected into the computer or something and everything is fixed. WHAT!!!??!!ELEVENTY!!!???! Come on. Where was the 19 hour meeting after the episode where the captain goes on and on at the engineering staff about how “We can never let this happen again.”

Nope. That didn’t occur. Instead, in the next episode (or maybe it was a previous one, I really don’t care at this point), a couple of verbal commands from within the holodeck (and what military in history… scratch that, just been reading about the Austro-Hungarian army in WWI… what COMPETENT military anywhere in history would allow that horror device to remain on board ship past the first time it kidnapped a crew member or whatever other tortures it inflicted, but I digress) allows a piece of one of the programs from the holodeck to take over the entire ship. Everything. Everywhere. Oh, they notice that there’s a lot of memory & cpu power going to the holodeck, but evidently the on-call rotation is in the hands of a junior ensign or something because they don’t DO anything about it. Nope, one program is allowed to rewrite all the other programs. And then, it somehow goes away because they ask it to. Again, no one had to restore any of the memory or storage that was wiped because this thing took over everything.

Look, I get it. It’s fiction. Not only that, it’s fantasy (no, it’s not science fiction, not with all the magical crap injected into the show, sorry, you lose there) so anything can happen. But please, can’t we at least have some internal consistency? Can’t we have a little logic. Couldn’t just one of the screenwriters talk to someone in IT, or barring that, someone in the military. Because, funny thing about the military, and IT, it only takes one serious slip-up before the competent do a review to determine what went wrong, why, and fix it. So, no more insane computer breaches. No more trainees, however smart they are, being given full admin privileges to production (just because their mom once slept with the Captain/CEO, oh, shut up, she did too). We’re going to start running backups. We’re going to test them. We’ll keep an owner’s manual around. We’ll put new programs through a thorough test environment before we plug them into the ship and wind up flying to the far side of the universe (oops, sorry). We’ll keep an original copy of the OS somewhere we can get at it because clearly, the 24th century has more viruses flying around than most free porn sites. We’ll start doing reviews of the ever-lovin engineering staff so that maybe, just maybe, we can make it so the holodeck can’t do ANYTHING to the rest of the ship, EVER. And if we can’t do that, great, we’re getting a squash-ball court or something where the holodeck used to be and I’m ejecting that thing out the nearest airlock (because I wouldn’t trust the thrice-damned transporter to move it successfully off the ship without beaming it inside someone’s head, to another dimension, or creating an evil holodeck with a cool beard).

The 24th century knows more about the evils of the 20th than most of us knows about the evils of the 15th (Crusades & Burning Times for those who aren’t history nerds) but somehow, all we can get are hectoring lectures about how morally backward we all are. Well, I’m here to tell you, maybe we are morally backward, but I sure as heck could revamp your IT department and turn the Federation into a force to be reckoned with, because you don’t want to get me started on just how bad the competing organizations IT work seems to be.

Rant over, I feel a little better. Oh, but if your IT department resembles the one on Star Trek, time to get to work.

I’m going to go watch Babylon 5.

The greatest part of my job is that I get to travel all over the world to present different technical sessions. But, it’s not the presentations that make it cool. It’s the fact that I get to meet people. I get a chance to hang out with my #sqlfamily. I get a chance to make new friendships. Those contacts are amazing. I love the opportunity to sit down and talk to people about what they’re doing with technology, the challenges they face, what’s common with my own experience, what’s different. From all that, I get a chance to grow and learn. Sometimes I even get the chance to help people.

I’m going to be all over the place between now and June. I’d love to get the opportunity to talk with you. If you’d like the same, check out one of these spots.

In just three weeks time, April 6 2013, I’ll be at the Boston SQL Saturday event. I think they’re full on registrations, but you can always get on the waiting list.

Right after that, April 8-11 2013, I’ll be at a new event, SQL Intersection, in Las Vegas. This one is looking like an event you don’t want to miss. Some of the smartest and most helpful people I know will be there. That list includes, but isn’t limited to, Paul Randal, Joe Sack, Paul White, Kim Tripp. If that’s not enough incentive to get you there, then allow me to add a little more. If you register for the show package, you get a Microsoft Surface tablet. All right, let me sweeten the pot just a little, register with my code: ‘Fritc’, and you get $50 off. This is going to be one heck of a great event with the chance to learn from and network with some truly amazing people. And I’ll be there too. Don’t miss this. Register now and use my code, ‘Fritc’.

Don’t want to go to Vegas? Live on the other side of the pond somewhere in Europe. Fine. I’m on my way over there too. The first time this year will be at SQLBits in Nottingham, UK. It’s my first time at SQLBits and I’m really looking forward to it. That’s May 2-4 2013. I’m speaking on Saturday, but I’ll be there Friday too. Let’s talk.

After that, we’re back to this side of the pond and my side of the continent to SQL Saturday Rochester, May 11 2013. It was a simply amazing event last year, so I don’t think you want to miss it this year. If you’re anywhere close to the area, get registered. There are great people lining up to speak at this one. You will be happy you visited.

Then we’re going way down South to New Orleans for TechEd North America 2013. That’s June 3-6. But, before all the fun of TechEd really gets going, I’m helping Thomas LaRock and Dandy Weyn put on a pre-conference, all day long, seminar on How to be a Successful DBA in the Changing World of Cloud and On-Premises Data on June 2. This is going to be one heck of a great session. If you’re at all wondering what the fuss is about with all this Azure stuff, come to this event and we will absolutely let you know why you should be adding this tool to your toolbox and we’ll show you how. Remember, you don’t want to move everything you have to the cloud, you want to learn how to mix this in at the right points with your existing infrastructure in order to maximise the opportunities of both environments. Register here for this amazing opportunity. And then I’ll presenting during the rest of TechEd. Track me down in the teaming hords and say hello.

Then we’re going back across the Atlantic again. June 21st I’m going to have the great privilege to once again speak to you in London at Red Gate’s own SQL in the City event. I love that my company puts one one of the great events of the year. If you haven’t been to one yet, you need to find your way to this one. It’s going to be worth your time and trouble, guaranteed. Registration opens on March 21st.

Since I’m already over there, I guess I meander south to take part in TechEd Europe. This will be in Madrid, Spain, June 25-28. I’ll be presenting the same sessions as New Orleans. Register now to get early bird savings. They expire really soon. Tom, Dandy and I are working hard on putting together the best information and the best presentation. You’re going to love it and learn from it.

Boston, Las Vegas, Nottingham, Rochester, New Orleans, London, Madrid. Guys, I’m trying hard to get within reach of as many of you as I can. Find your way to an event and let’s have a chat.

I jumped at the opportunity to write a chapter for this book, Pro SQL Server 2012 Practices, because of all the fantastic people writing and the topics that were covered. I reviewed Chapter 12 a few weeks ago and I’ve been meaning to get this chapter, Big Data for the SQL Server DBA, read & reviewed but I’ve just been sidetracked. I finally noticed it on my Trello board, weeks out of date, and decided to finally get the job done.

Carlos Bossy (b|t) is a great guy and a part of my SQL Family. We run into each other all the time at SQL Saturday’s and other events. I’ve never listened to him present before, and now, after reading his chapter in the book, I’m very sorry. I’ll fix that at my first opportunity.

Carlos starts off nicely, getting a reasonable definition of “big data.” It’s not merely about size, although that has to play a part. He breaks it down to the three “Vs” volume, variety and velocity. It makes sense. Just having a big database is not the same thing as dealing with big data. He takes the time to differentiate between the structures of a relational system, that work just fine, and the needs of big data, which just don’t fit well in relational storage. It’s as clear a delineation as I’ve seen on this topic.

The big data management system that Carlos then focuses on is Hadoop. Which makes sense again. If you’re already working within the Microsoft stack, they’re moving on Hadoop with the HDInsight servers and stuff on Azure. So learning how the Hadoop File System (HDFS) and MapReduce work together to provide you with massive data movement and storage keeps you within the set of tools with which you’re already familiar (although there is a ton of learning to do here). Carlos covers MapReduce in quite a lot of detail because it really is the driving force behind Hadoop and how you’re going to get your big data into the system. He covers the topic by explaining in general terms how things will work, then walks you through an example with additional detail and then walks you through another example with a lot more detail. The accumulative effect works well. The core concepts generally start to stick.

I really like how Carlos addresses the technology from a business solution perspective. It’s not that any one technology is a glorious thing, let’s go use it. It’s that certain business problems require certain tools in order to solve them most efficiently. He makes an excellent case for DBAs understanding technologies like Hadoop in order to implement them where they are appropriate. It’s the kind of arguments I’ve always tried to support. The concepts for management of big data are both simple and really complex and Carlos attacks them both in order to educate. I’ve learned a lot from reading this chapter.

He then walks through different aspects of the type of work you’ll need to support as a DBA using a Hadoop server. There’s going to be some pretty major work around import/export of the data, into and out of Hadoop yes, but into and out of other types of storage, such as good old fashioned relational SQL Server, data warehouses, cubes, and Excel/Sharepoint. Carlos takes us through a detailed examination of the primary tool for this function within the HDInsight/Hadoop infrastructure in Azure, squoop. It’s a great way to learn how this stuff works.

Finally, Carlos goes over some pieces of the future of big data, again focusing primarily on the Microsoft/SQL Server stack and how it relates to Hadoop, but also SSRS and all the tools with which you’re already familiar.

Overall, it’s a great chapter. It’s very solid introduction to a topic that I’m just starting to really wrestle with myself, so I’m happy to have it as a reference.

I earned my nickname. I’m proud of it. I am the Scary DBA. I don’t really like to advertise my other nickname, Rant (get it, Grant shortened to another word). I earned that one too. I’m not proud of it at all. I got that one because I sometimes don’t listen as much as I should and, because I tend to be more than a little passionate about my job and my databases, I would go off on a rant. And yeah, I stood in the way of some development processes and approaches that I shouldn’t have. Instead of facilitating the development team and trying to understand their problems and issues, I just said “No.” Usually at length.

I just finished reading this post from Martin Fowler, whose work I’ve  enjoyed, about what he’s calling the NoDBA movement. It’s not so much a “movement” as it’s a by-product of the NoSQL movement, ORM tools, and other developer-centric/code-centric approaches to managing data. Some of these are natural, and appropriate, rejections of the relational storage engine. Let’s face it, it doesn’t work very well at all for some types of data collection. You should be using “pick your favorite” NoSQL storage engine for some types of code. But, there are two problems here. The first, Mr. Fowler mentions in passing, just because there are places where NoSQL works well doesn’t mean it works well in all places. Humans very much tend to fall into a mode where “I have a beautiful hammer. Look at all the lovely nails” becomes how we work. There are nails that need that NoSQL hammer, but there are screws and bolts and other types of fasteners out there that using the NoSQL hammer on will not work terribly well. Same as if you have a big data hammer or a structured storage hammer or a relational storage hammer or an object storage hammer or whatever kind of hammer you are currently enamored with. I am not casting aspersions on your very fine hammer to suggest that it’s probably not going to be efficient at pounding in screws. And, I’m telling you flat out, your ID value pair data collection engine which is great for pulling in “web scale” data is going to blow serious chunks when it comes to business reporting. It just will. That’s not questioning it’s utility for data collection, but just as the hammer-to-screw mechanism doesn’t work well, the collection-to-reporting mechanism doesn’t work well either.

The second thing that Mr. Fowler mentions is the social aspects of what’s going on here. It’s “Rant” that is causing the developer to try to find a way around the DBA team. In short, it’s my fault. It’s your fault. We have not been listening. We have not been communicating. We’ve been at war. And that’s just stupid. There are very sound, technical reasons for using an ORM. Standing in front of your developers with a furrowed brow and your arms crossed saying “no” without a full understanding of those reasons just gets you kicked out of the room. Then, of course, the development team goes off and makes some of the classic implementation errors that can be done with ORM tools. But, because you weren’t in the room because you became “Rant” instead of trying to engage and understand, those errors grew and were standardized within the app. It’s your fault. When the developers proposed changes to the structures of the database under development, instead of whining that it was going to take time and that they needed to fill out paperwork and get approval from fifty people, you could have listened and understood what they were proposing and why and then you could have either done the work, or showed them a better way to do the work, or proposed a different solution, or even suggested that maybe they’d be better off with a NoSQL solution. Instead, you became “Rant” and they bypassed you. That’s your fault too.

Now, the really fun part is, that even though you’ve been bypassed, in most organizations I’ve been in or worked with, inevitably the data has to be reported on and it has to be backed up and it has to go through a DR process. Then, suddenly, you get handed the mess. And it is a mess because no one even thought about reporting on the data collected or backups or the ability to get the site back on it’s feet in the event of a fire/flood/meteor strike. And this is not the mess that those nasty developers created. Oh no. It’s the mess you, “Rant,” created. Fault yours.

Yes, I’m off on a tear, a rant. Initially because after reading what Mr. Fowler wrote I was quite upset with him and his attitude. Then I recognized that at least half the problem lay at my own feet. And while I hope, to some degree, I’ve learned some lessons from being “Rant” a little too often, I feel I’m still seeing way too much of “Rant” in my peers. I see the outright rejection of Azure SQL Database. I see the scoffing at HDInsight. I watch people trying to block the adoption of ORM tools. I see data professionals unwilling to engage with their development teams in areas like source control, continuous integration, testing, agile processes, new deployment processes and more. All this is hurting our ability to influence, in a positive manner, the products delivered by development teams. Further, it’s hurting the businesses that we, data pro’s and developers alike, are supposed to support. Yes, the development teams are going to need to meet us halfway on this stuff, but I don’t see why we can’t be the first ones to offer a hand, to acknowledge our past misdeeds, to stop being “Rant” and get out there and help the people and the businesses we support. If you don’t, it’s your fault.

In just a couple of weeks I’ll be flying down to Richmond, VA to speak at SQL Saturday #187. I’ll be presenting two topics, Backups for the Accidental DBA and Query Tuning in the Clouds. It’s going to be a great event with a bunch of excellent speakers. If you’re in the area, come on down and say hello.

And, if you have some time on Friday before the event, Red Gate Software is hosting a special 1/2 day seminar targeting the database professional just getting started with their career. There are only a few seats left, so if you’re interested, sign up quick. Steve Jones and I will be presenting on several topics from monitoring to backups, database corruption and indexing. It’ll be great way to learn, network, see some Red Gate Software and then share a tasty beverage afterwards. Instruction and networking the Red Gate way.