Andy Leonard : DBA

The Perfect Trap

andyleonard — Mon, 05 Mar 2012 12:00:00 GMT

Warning: I am about to express an opinion. * Introducing disruptive database technology is the perfect trap for database administrators. < …freak out here… > < … done? Good. Let’s continue… > Way back in 2007 – when Adam first emailed me about...(read more)

Presenting at SQL Saturday #46 Raleigh 18 Sep 2010!

andyleonard — Tue, 07 Sep 2010 11:00:00 GMT

I am honored to present at SQL Saturday #46 in Raleigh 18 Sep 2010! I get to deliver two talks: Building Your First SSIS Package (Beginner) Database Design for Developers (Intermediate) If you read this blog and will be attending SQL Saturday #46 , introduce...(read more)

Draft SQLRally Pre-Conference Seminar Proposal

andyleonard — Thu, 02 Sep 2010 11:00:00 GMT

Introduction Andy Waren ( Blog | @sqlAndy ), Jack Corbett ( Blog | @unclebiguns ), and Kendall Van Dyke ( Blog | @SQLDBA ) have been busy. They're working on SQLRally - a regional PASS event scheduled for May 2011 in Orlando. Andy does a good job explaining...(read more)

Interview with Andy Warren about SQL Saturday, PASS, and More

andyleonard — Fri, 05 Feb 2010 12:00:00 GMT

Introduction Andy Warren ( Blog - @sqlAndy ) is a DBA's DBA. He is a friend and mentor. He calls 'em like he sees 'em, and I haven't seen him pull a punch yet. I requested an interview with Andy before I learned of the transfer of SQL Saturday to PASS....(read more)

Tim Ford Present to RichmondSQL Thursday!

andyleonard — Wed, 07 Oct 2009 16:00:00 GMT

If you're going to be in the Richmond Virginia area Thursday afternoon / evening, drop by the RichmondSQL meeting and hear Tim Ford (aka SqlAgentMan ) present! Tim is awesome. He hosts and moderates the SQL Quiz Bowl at the PASS Summit every year, and...(read more)

Who Thinks Like Database Professionals?

andyleonard — Wed, 01 Apr 2009 01:30:00 GMT

Introduction

I was talking to my team this morning and we were wondering about some design decisions. One of the things that came out of the discussion was: Database professionals think differently.

Differently? How?

A little story: Before I was a database person I did web development. That's a little misleading because I wrote very little that made it onto the big web. Most of my work ran on enterprise intranets.

Back then, I started using Access first (and I admit it). After I crashed Access one weekend, I learned about SQL Server 6.5 and started working with it. After a year or so I started playing with SQL Server 7.0. About six months later I considered myself a DBA.

Were You a DBA?

No.

But You Considered Yourself a DBA?

Yes.

When Did You Learn You Weren't a DBA?

I learned I was not a DBA when I started working on my first Very Large Database (VLDB) project. I started doing database work and realized how little I actually knew. The gaps in my knowledge were readily identifiable, but that was nothing compared to my thinking. I didn't think like a database person.

I'm not going to mislead you: Sometimes, the ability to think differently than a database person adds value. But right then, it was a major liability.

Thinking about parallelism and thinking in sets is different. It's way different from the way I thought about web development. I don't think I'm alone in any of my experiences. I think lots of people have trouble thinking in sets, about parallelism; and quite a few developers think they're DBAs.

It's important to note that there are some developers who are DBAs. I believe they represent a subset of all the developers who think they are. Maybe I'm just biased because of my experience, I'm not sure.

One Last Thing

The most important thing I learned working with that VLDB: I was not a DBA when I started, and I really wasn't a DBA when I finished. I knew a lot more about SQL Server database administration, but that doesn't make a DBA - in my opinion. I learned I'm a database developer, which is a different animal from an application developer and from a DBA.

I can hear you thinking: "What makes a DBA, Andy?" I'm glad you asked. I don't think there's a formula, really. I know some really good DBAs (a couple of them are also really good developers), and they share some traits. One thing they all have in common is they're detail-oriented.

Conclusion

What do you think? What are the differences between the thinking of database professionals and other technology professionals?

:{> Andy

Things I Know Now

andyleonard — Tue, 17 Mar 2009 09:01:00 GMT

Introduction

I was tagged by Joe Webb for this question circulating through the inter-tubes.

Joe and I shared a cab to the airport after the PASS Summit 2008. If you've never had the opportunity to share a cab with Joe, I highly recommend it. He's one of those people. You know the type - they talk to you for a few minutes and impact the rest of your life in a positive way. A way that still has you thinking months later. Thanks Joe.

My List

Well, I have to admit I saw some good stuff when following the links to others who've answered this question. I'm going to repeat some of theirs here, but only because I've learned (usually the hard way) the same thing.

1. Learn constantly. There are fields out there where you can get trained and then do that work most of your life without having to learn much more. Database work is not one of those fields. Plan to spend some of your time - your own time - keeping up with what's new and on the horizon.

I'm not asking you to fall instantly in love with every new feature you encounter. That would be absurd. But equally absurd is dismissing every new feature - especially the stuff you don't understand or cannot think of a good use for at the moment. Features are added for a reason. Most of them are good reasons, at least to someone. It might not be for you, but will it kill you to learn something new? If I don't understand it, I can't use it - ever. If I do understand it, it becomes another tool in the toolbox.

2. Dream big. I was struggling with my new career as a DBA. I felt I was in over my head and, any minute, I was going to be discovered and fired. I am not making this up. About the time I attended the PASS Summit 2004 I got a few successes under my belt - enough to feel more secure in my job but not enough to convince me I knew anything about very large databases in SQL Server.

It was The Year of the Storms in Florida. Orlando looked like it had been bombed. It was ugly, but the conference went on. I stood in line at the hands-on labs to meet Ken Henderson. I was devouring The Guru's Guide to SQL Server Internals and Architecture along with Kalen Delaney's SQL Server 2000 Performance Tuning Technical Reference. I credit both authors with saving my career, incidentally.

I heard Ken dispensing no-nonsense advice to people. I think some thought to "teach him a thing or two," and he respectfully but firmly resisted this with the gentleman in line in front of me (poor guy). I was next, and was probably visibly shaking in my shoes. I explained to Ken that I was pretty new to large SQL Server databases and was a web developer that had been thrust into a new position at work. I told him about my approach - relying on my engineering training and testing heavily - and explained the symptoms I was seeing. Ken made a few excellent suggestions, which I wrote down and which, unsurprisingly, put me right on top of the issues I was describing. I thanked him profusely and started away. He said "Hey, you're approaching this like I would."

I felt like the kid on the old Coke commercial - the one where Mean Joe Greene throws him his jersey. I know it sounds cheesy, but I entered that room as a guy learning databases and left it a database professional. The difference for me was the confidence that I was approaching this problem like Ken Henderson would.

3. Live transparently. I blogged about this recently but it bears repeating. Treat others like you want to be treated, in public and private. Work hard. Admit your mistakes and do everything you can to correct them and mitigate the damage - all as soon as possible. Help as many people as you possibly can. Don't lie. When the honest answer is "I don't know," lead with that - you can tell folks your best guess after stating you don't know. It's ok, no one knows it all.

4. "If it was easy..." My Granny used to say "If it was easy, anyone could do it." (This was the same lady who told me "Son, God gave you a [backside] so you'd have somewhere to land when you fall.") I've experienced failure and I've watched others experience it. It ain't pretty and it's no fun to live through or deal with. Bad things happen when people fail. That's a fact. But you're not judged by how many times you fall down, in my opinion and estimation; you're judged by whether you get up or just stay there.

Get up.

If nothing else, you now know at least one thing that doesn't work. Use that. Leverage it. Build a way that will work from it's ashen rubble. Don't just sit there on your ash.

5. Take good advice. A good skill to cultivate is the ability to recognize good advice when you hear it. Note: You may not want to hear good advice. I can guarantee you it's unpleasant when you've messed up.

I'm blessed to be surrounded by people who care about me enough to tell me "Andy, that was a mistake." When they do, I usually don't want to hear that. But I recognize the motive and hear the heart, and know it's good advice.

Conclusion

That's all I can think of for now. There are no magic formulas or guarantees in life. These are the things I'd share with my younger self if I could write a letter to me and send it back in time.

:{> Andy

My 2008 PASS Summit Sessions

andyleonard — Sat, 13 Sep 2008 20:05:00 GMT

I am honored to be selected to present at the 2008 PASS Summit!

I'm presenting two sessions: Test-Driven Development For Database Professionals and SSIS Scripting. I've been working on the presentations recently and realize there will be a few minutes left in the SSIS Scripting talk unless I talk slow. (Some people say I talk slow enough already - and that I have a Southern accent. Can you believe it?)

Anyway, I open the floor to you good people - the readers of my blog: What cool (or useful, or challenging) SSIS Scripting demo would you like to see? We'll make it a contest. Leave a comment here (keep in mind I moderate comments so they will not appear automatically) and I'll pick one.

I'll have to come up with some cool gift to award the winner.

:{> Andy

Twitter Woes

andyleonard — Fri, 30 May 2008 13:42:00 GMT

"My name is Andy Leonard. I tweet."

"Hi Andy, we love you."

It's true, I am a bona fide Twitter-holic. If you use the service you may have noticed disruptions lately. Frank La Vigne (recently married - congratulations Frank!) blogged about it. The Twitter developers are blogging about it. And they have raised the ire of Mr. Scoble, who posted his feelings on the matter at FriendFeed - a competing service (if "competing" applies here...).

From the Twitter Dev blog:

The events that hit our system the hardest are generally when "popular" users - that is, users with large numbers of followers and people they're following - perform a number of actions in rapid succession. This usually results in a number of big queries that pile up in our database(s). Not running scripts to follow thousands of users at a time would be a help, but that's behavior we have to limit on our side.

The Twitter Dev comments have been interpreted by some as complaining about user load. This is not good for Twitter and they should take immediate steps to manage the buzz before this goes any farther.

I jokingly tell clients sometimes the problem with their application or database performance is a combination of their data and their clients. I only do this in person and after reaching a comfortable comfort level with the client, and even then it's sarcasm that I carefully throw out. Why? It's the technological equivalent of saying the word "bomb" while waiting in the security line at the airport - within earshot of the good people of the TSA.

In other words, it's a really dumb thing to say.

Let's look at why: First, Twitter is demonstrating that they made a mistake in architecture. I don't know what that mistake is, but it's obvious to everyone using or attempting to use the platform that an error has occurred. It's not the HTTP 500 error I saw last night or the on-again-off-again link to older tweets. It goes beyond that back to the design.

Part of the problem can be stated thus: "Twitter did not know we were going to grow so fast." Another way to say that is "Twitter doesn't scale."

As a database professional in the data warehousing field, I feel Twitter's pain.

We are often pressured to "just make it go!" - deliver something now and fix it later. And oh the temptation is strong, the logic sounds sound, the song so sweet... "you can circle around later and fix it" they say. When you hear these words and are so tempted you can be certain of one and only one thing: the person saying this to you is lying. Malice may or may not be present - they may simply be repeating what they heard or they may be utterly ignorant, but they speak not the truth.

Second - although I could be wrong about this - I would wager good money that Twitter doesn't need a DBA. I've seen / heard / experienced this before. They have a talented team of application developers who have built large applications in the past and never once paid a database professional. Look at the money they've saved! </sarcasm>

Why does this happen? Experienced database professionals slow down project development. We get in the way. We muck about with stress tests and bulky architectures and referential integrity and schemas and the like. Who needs us? We're an unnecessary expense.

Or are we?

From the quote above, the bottleneck is occuring in the database. It's those pesky queries. And the users causing them to be executed. It's <insert-your-favorite-excuse-here> - everyone and everything, except the designers and architects who built a non-scaling solution.

My lovely bride Christy has this saying: "Good judgment comes from experience, and experience comes from bad judgment." My hope is Twitter will discontinue offering excuses and blaming users, and instead fix the (apparently database-scaling-related) problem.

If this comes across as harsh, that is not my intention. I have been there and done that myself. These are learning experiences and growth opportunities. Hopefully Twitter will enjoy the fruits of this learning and growth in the future.

For now, I've created a FriendFeed account. Let's see how they scale...

:{> Andy

New Features Announced In SQL Server 2008

andyleonard — Thu, 13 Mar 2008 10:23:00 GMT

Buck Woody, Microsoft SQL Server Program Manager, recently posted a list of enhancements in the works for SQL Server 2008 RTM in the SQL Server MVP newsgroup. The usual suspects were included in the list: Policy-Based Management (formerly DMF), Resource Governor, Multi-Server Query, PowerShell, and IntelliSense - but there are also some interesting additions that I'd not heard about until reading his post.

The big addition: Activity Monitor, described in the post thus:

The new Activity Monitor was written from the ground up with the perspective of the DBA needing to chase down a performance problem in real time. Modeled after the new Windows Resource Monitor, DBAs can quickly see the active sessions, wait states, file I/O, and long running queries in a command console like UI.

I'm excited! I currently lug around a collection of scripts (... that I keep promising to add to an application one day) to check hither and yon for performance gotchas.

Another addition: Database Diagram / Table Designer Safety Additions which add safety checks "for operations that that would drop an object or cause data loss."

You will also be able to launch Profiler "from a Query Editor Results window to the SPID of the query." This sounds very interesting. If I'm reading this right I'll be able to execute sp_who2, obtain the SPID of a long-running query, right-click (or something) and start a Profiler trace pre-configured to capture activity of this SPID. You can also launch the SPID-centric Profiler from Activity Monitor. I will be using that a lot!

New right-click options in the Query Results Window will allow users to "select a range of rows in the Results Grid and copy the headings as well. Also, you can select individual cells and copy them with headers if you wish." This sounds like the copy functionality we have in SSIS Grid Data Viewers. I can tell you from expereience this is handy feature. It's very useful to be able to copy a few multi-selected rows - including row headers (especially when you're working with a couple hundred columns!) - and paste them into Excel for analysis.

A new "Info Bar" provides pre-validated navigation cues in many screens.

The Open Table feature limits the number of rows returned. Has this ever happened to you? You right-click a table in SSMS and select Open Table only to hog server resources just so you could take a peek at the data? It's happened to me... (Thank you, thank you, thank you!)

There are also a few changes to ShowPlan - mostly related to XML / graphics interchange. I remember seeing some of this in early SQL Server 2005 pre-releases but I believe it was cut from the 2005 RTM. Nice to see these options - they're great for documenting issues.

Performance Studio will contain a host of performance tuning reports - another exciting feature! The whole Data Collection database has me stoked - have you seen this feature in CTP6? It's pretty cool.

Last but not least, the team has decided to include - drum roll please - the T-SQL debugger in SSMS!

I can hardly wait to see these in action, and it's very cool of the SQL Server Team to give us visibility into these planned features along with permission to blog about them (thanks Buck!).

:{> Andy

A Follow-up to Database Professionals: An Enterprise Requirement

andyleonard — Sat, 14 Jul 2007 01:07:00 GMT

Eric Wise drew some heat from the developer community at CodeBetter.com with this post about the need for a DBA during development (see my post on the subject here).

I think Eric makes a couple good points, one explicit, one implied:

1. (Explicit) A DBA - or Database Developer, more accurately (and there is a difference) - adds value to development.

2. (Implicit) There are Software Developers out there who can step into the Database Developer role long enough to solve most database tuning issues. Eric demonstrates this with himself in profiling and addressing a missing or ill-defined index.

I find most of the comments - presumably by software developers - typical. One developer stated:

My current project didn't have a DBA for 2 years, until recently since we're now at the stage of optimizing for performance. It seems to me that as long as the database is intelligently structured in the first place, a DBA's role would be rather small in most cases.

I agree with the sentiment expressed here - as much as I agree that code-generation tools can replace application developers. It's true that you can utilize SQL Server or any database engine as a dumb file store. And it's equally true that you can build an enterprise application in C# that consists of thousands upon thousands of lines of nested If... Then... Else statements.

</sarcasm>

The question is: Why would you?

This goes beyond arguments over syntax, coding standards, methodology, and design philosophy. This is about putting competent professionals - at the height of their game - into the mix on a project.

You don't have to take my word for it - ask software developers who have worked (or are working) with competent database developers.

:{> Andy

Which "flavor" DBA are you?

andyleonard — Wed, 11 Jul 2007 01:25:00 GMT

This re-post from my Applied Team System blog (which was a repost from my old SQL Server Central blog) was inspired by James Luetkehoelter's Agile Development and the "DBA" post a few days back. I'll have more to say about database developers, agile methodologies, and the need for a DBA in posts to come. Enjoy!

I received a cool compliment today from a peer who's a developer. He said, "You know, I really like having a DBA on my team!" I have to tell you, it made my whole day!

It led to a discussion about past experiences and expectations, and I shared something I thought was pretty much common knowledge: there are three types of DBAs. My peer was shocked, so maybe the knowledge isn't so common after all.

The three "flavors" of DBAs I define are:

System, Operations, or Production Support DBAs - these DBAs write maintenance plans in notepad and have no qualms whatsoever about executing in command-line. They were DBAs in the old days, when we carved our own ICs out of wood. They will get your server and database back online fast - and with less data corruption than anyone else on the planet. They live for torn pages and I/O faults.
Application Support DBAs - these DBAs are familiar with one or more (usually complex) applications. I'm talking PeopleSoft, Seibel, and SAP here. If you want to customize a screen or write a one-off web application, you desperately need these folks.
Database Developers - these DBAs are ruthless bit-heads. They use bigint and byte fields for masking binary states. They can optimize a stored procedure in their sleep and wrap an API around a database so developers never have to consider writing SQL that directly hits tables. They are performance freaks that will work 18-hour days on weekends to test in Production - when it's "safe."

Do you think DBAs fall into these categories? Do you know any that do? Do you see yourself in there anywhere? Do you have more or less or different "flavors" for classifying DBAs?

:{> Andy

Technorati Profile