March 2012

#TSQL2sDay 28–Jack of All Trades, Master of None

This month’s topic was chosen by Argenis Fernandez (blog | twitter): "Jack of All Trades, Master of None?".  It’s interesting to me lately because I seem to keep encountering blog posts and articles that ask some variant of this question.  I’m not sure if it’s spurred in part by the recent release of SQL Server 2012 (which is going to change a lot of the ways we manage data), or if it’s something in the collective waters bubbling under the Internet.  Or perhaps, it’s just the fact that I’m trying to define myself in a new role at my work.  Don’t know. 

I’ve always been a data person; one of my first jobs in IT was working for a forestry agent doing data entry; my job was to take the handwritten note cards from the tree counter, translate their coding system into digits, and enter it into an old Macintosh computer (this was the late 80’s, and Macs were super sophisticated at the time).  These numbers were important; they represented an estimate of how much timber (and what kind) was on a property, so that the value of that property could be accurately assessed.  It had nothing to do with SQL; wasn’t really even any sort of programming.  Just look at a card, mentally transform the code into a number and tree type, and punch it in.

Later, in college, I got involved in doing social science research; this eventually led to a position as in public health & communication research.  Still digging on numbers; I was using SPSS at the time.  I went to bed at night dreaming of statistical relationships and discovering new stuff.  When our department encountered resistance from the IT department for managing one our studies, I started hacking into Microsoft Access to build a contact management platform.  This was a transition point for me; I went from entering numbers to evaluating numbers to finally programming.  However, it was always data.

I made a career change and dove into true IT work shortly after that; my job title said “Access Report Developer”, but I became the DBA (because there wasn’t one).  I loved SQL 2000, but when the IT department at that company shrank, I became not only a programmer, a report developer, and the DBA, but also the guy that fixed printers.  When I had an opportunity to jump ship to another company to become strictly a DBA, I took it.

I’ve been here for 9 years, now.  In that 9 years, I’ve been the DBA, a database developer, a data architect, and now a manager.  Although I’ve primarily worked with SQL Server, I’ve dabbled in mySQL, XML and Visual Basic.  I’ve looked at backup jobs and maintenance plans, DTS and SSIS (and other solutions); my T-SQL is strong.  I used to think I was a specialist in database development, but I’ve come to realize that there’s people that are a lot more specialized than me.  I’ve also come to realize that data without context is meaningless.

I guess I’m growing up a little; when I was kid counting trees, I didn’t really care about how efficient the system was.  I was just earning spending money at a job that was better than mowing the lawn.   When I was doing research, I realized how important my work was, but even then there was little that I could do to change long-term outcomes; I was just an analyst.  In IT, I could finally get to a point where I could take the numbers that I saw and do something about it.  I’m just not collecting data for a reason; I’m using that data to help make decisions that make my company more profitable (which ultimately leads to more money in my pocket). I collect, I analyze, I interpret, and I react.

So what does this little trip down my history mean in terms of the post topic? For me it means that I’ve got a niche, but it’s a pretty big one.  Most of work is done with a certain tool, but the skills I’ve learned along the way don’t restrict me to that tool.  I’ve worked with people who get the specifics of the platform a lot better than I do, but miss the big picture; I’ve also worked with visionaries who get lost when I discuss normalization and efficiencies.   I’m neither a Jack of All Trades, nor a Master of just One.  I’m just a data guy, and I like it.

Agile Database Administration

Last night, I had the pleasure of presenting at the Greenville SSIG; my topic was Agile Database Administration, and it was a presentation that I had pulled together at the last minute.  It still needs some refinement, but overall I thought it went pretty well.  However, I was surprised at a couple of things:

1.  Out of my (admittedly) small sample of attendees, only about 2% had encountered Agile methodologies (like Scrum) in their work, and

2.  Even fewer of them understood the challenges that Agile is supposed to solve.

I decided that in order to improve the presentation, I would try to do a little more research; since I own a blog, this seems like the perfect place to synthesize some of my thoughts on the subject.  As I did in my presentation, I’ll try to skew the discussion toward data people, but there may be some challenges along the way (since much of Agile focuses on management of development tasks, not administration or service-oriented tasks).

Begin at the beginning….

The Agile movement begins with the Agile Manifesto, a short statement of belief written by 17 software developers during a weekend at a resort in Utah.  The entire manifesto reads as follows:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

There are twelve basic principles associated with the manifesto; I’ll tackle those at a later post.  The concept of the manifesto is clear, however, in that the goal is to manage tasks through a focus on relationships and the business environment as opposed to strictly moving from point A to point B.

As a sidebar, I do find it quite funny that the Agile Manifesto webpage appears as if it was thrown together after a weekend of drinking and philosophical conversations at a ski resort; it hasn’t changed in 12 years.  I’m not sure if that’s intended as a silent testament to the longevity of agile code or not.

It should be noted that many agile methods actually began before the manifesto; the manifesto was not intended to spawn new methodologies, but rather to provide a common framework for several existing methods.  It’s a philosophy, not a method; you have to think agile before you can be agile (I’ll pause for a minute to let that sink in… ready to move on?)

Let me try to define the agile movement by what it is not:

  • Agile does not mean a particular method of development; rather, it’s an umbrella for several different methods.
  • Agile is not represented by a set of tools; but you should use tools in an agile way.
  • Agile is not an excuse for sloppy work; instead, it’s an attempt to focus on quality throughout development.
  • Agile is not a solution for every organization; the agile philosophy represents a change in process which must be endorsed by the organization in order for it to be successful.

Jumping the candlestick…

The term agile means “nimble”; it’s the ability to quickly respond to a changing environment.  Most agile adherents recognize that processes such as lengthy requirement gathering sessions can cripple the development process; if your organization spends a lot of time defining what it needs up front, the business environment can change before you get it developed.

But what about database administrators?  Most admins I know have mild cases of ADHD; database professionals are the master of change.  Need a query to see what’s happened over the last year?  No problem.  Backups not working? We’ll look into it.  Server overloaded?  We’ll deal with it.  Printer not working?  Not my department, but sure.  Developers too slow in getting a report to you?  I can do it.   We’re already agile, right?

Wrong. To be agile doesn’t mean you leap over one flame to another; it’s finding a method of getting things done that is responsive to business changes while solving business problems.  If you’re constantly hopping from one issue to the next without figuring out how to keep the fires from occurring, you’re eventually going to get burned (see what I did there?).  If your servers can’t handle the queries your users are throwing at it, you can tune the queries but you may need to look at a hardware solution.  If your boss keeps asking you for the latest numbers, it may be faster to run the query for her, but writing a report (or showing her how to write a report) will minimize the long-term problem.

Thinking agile means thinking strategically; be nimble (solve the immediate problem), but be clever (address the root cause).

Where do we go from here?

I hope to start pulling together a few blog posts on various agile methods and how they relate to the agile philosophy over the next few weeks; specifically, I hope to talk about how the agile philosophy is influencing my database administration management style.  Until then, here’s some links for you to consider:

http://en.wikipedia.org/wiki/Agile_software_development

http://www.agilemanifesto.org/ (Be sure to read the principles on the next page).

http://www.agiledata.org/essays/dbaSkills.html (lots of material here; I need to revisit it

Presenting at Greenville SSIG on Tuesday, March 6, 2012

Just a quick note: I’m presenting next Tuesday at the Greenville SSIG. Kind of a last minute deal, I’m still writing the presentation in fact. Details below:

Please register at http://ssig201203.eventbrite.com/ . If you forget to register, and want to come to the meeting, please do.

6:00 – 6:30 Food and Networking Sponsored by FGP
6:30 – 6:45 Announcements
6:45 – 8:15 Stuart R Ainsworth: Agile Database Administration
8:15 – 8:30 Closing remarks and give-a-ways.

Agile Database Administration
Agile development is all the rage, but how do the principles apply to database administrators? This presentation will introduce the basics of the Agile Manifesto, and explain how they can be applied to non-development IT work, such as database administration, maintenance, and support. We’ll cover scrum (one of the most popular development methodologies) and kanban, and identify some of the common struggles with implementing them in an organization. This is an interactive discussion; please bring your tales of success and your horror stories.

Stuart R. Ainsworth is a database architect and a manager of database administration for a financial security company. He’s also a chapter leader for AtlantaMDF (the Atlanta SQL Server User Group), and blogs (infrequently, but hopes to do better) at http://codegumbo.com/.

Stuff in the FROM Clause: Interfaces

IMG_0323[1]Finally wrapping up this blog series (while standing at my mobile office waiting on my daughter to finish track practice); I’ve previously discussed four different categories of database objects that can be used as the source of various SQL statements:

Base Structures

Virtual Structures

Temporary & Semi-Temporary structures

I want to wrap up with the following category: Interfaces.  Interfaces are methods by which queries can be executed on a remote server (and I use that term to mean remote to SQL Server, not necessarily remote to the host). and the results returned for consumption by a SQL statement.   There are basically three interfaces supported by SQL Server.

OPENDATASOURCE

OPENDATASOURCE is an ad-hoc method of connecting to any OLEDB provider; below is a bit of sample code from MSDN:

SELECT *
FROM OPENDATASOURCE(‘SQLNCLI’, ‘Data Source=London\Payroll;Integrated Security=SSPI’) .AdventureWorks2008R2.HumanResources.Employee

If you’re familiar at all with server naming notations for SQL Server, you can easily identify the four-part schema above (Server.Database.Schema.Object).  Note that OPENDATASOURCE is intended for limited use; heavy connections should consider using linked servers to take advantage of security management (particularly in the case of SQL Authentication).

OPENROWSET

OPENROWSET is similar to OPENDATASOURCE; it’s an ad-hoc method of calling data from an OLEDB provider.  The primary difference is that OPENROWSET supports a querystring, as well as pulling data from a single object.  This allows you a great deal of flexibility because you execute complicated queries using remote resources, and then only return the data that you need.  OPENROWSET can also be used for BULK insertion of data

OPENQUERY

OPENQUERY is intended for use with linked servers; the purpose is to allow code to be executed on a remote server first, and then the affected result sets being used on the local server.  In order to use the OPENQUERY method, you must first define a linked server, and then use a query string to do the actual heavy lifting on the other box.

Interfaces are relatively easy to understand and use, but they need to be carefully evaluated for each situation.  For example, OPENDATASOURCE allows you to quickly retrieve data from a single object on a remote server, but that means that all of the data is retrieved to the local instance.  If the remote server is across a network, then you have to deal with network latency.  OPENROWSET and OPENQUERY provide a work-around (through the use of a querystring), but the querystring can not be parameterized, so it’s a bit clunky to work with.  However, for quick and dirty movement of data from within T-SQL, interfaces can be a valuable tool at the right time.