1. State the obvious:  SQLSATURDAY 111  ROCKED!!!!
2. Thank a whole bunch of people: Audrey Hammonds, Aaron Nelson, Tim Radney, Julie Smith, Rob Volk, Kristina Mishra, Erin Hicks, Lorra Newton, the AtlantaMDF leadership team, and a whole bunch of speakers and volunteers who helped make this show work (far too many to thank here; it was inspiring to see the people who gave their time to make this work). 

This was the second year that I served as a member of the team, rather than trying to pull it off.  Audrey did an amazing job of pulling everything together.   We may have had a few bumpy spots along the way, but from all of the feedback we got, the event ran extremely smoothly for the attendees (all 460 out of the 650 registered).  However, as I was reviewing the twitter feed, one tweet in particular stood out for me:

This is what it’s all about; an attendee at our event left wanting more.  It made me think about the nature of this post; I usually write up some practical advice on HOW to do something (and lessons learned).  This time I wanted to focus on WHY you should do something.  I guess this is my attempt at inspirational writing, so breathe deep, assume the lotus position, and read on.

First, it’s the people.

SQLSaturday’s are a big party, and there’s enough of them going on around the country world now that we’re starting to become a traveling band of gypsies.  Many of the people who speak at these events speak at a whole bunch of events, and this becomes a little family reunion at every event.  I love that, but what I loved even more was the fact that I got to see a bunch of my local database people “get their learn on”.  It’s really easy to get caught up in the moment of working at the event, but at the end of the day, the point of this event was that you should inspire somebody to learn something new, to change the way they approach a problem.

Second, you are people.

If you’re hosting a SQLSaturday, don’t neglect yourself.  I went into this event tired, grumpy, and a little worried because I knew there were some last minute issues that I had neglected.  Guess what; nobody cared.  The party rolled on.  I spent a great deal of time running around trying to make sure that I touched base with people, and I didn’t attend a single session (other than my own).  That was a mistake.  I should have totally taken advantage of the great training opportunities that were there, and learned something myself.

I’m pointing the finger square at myself on this: I need to invest more in me.  Not that I should neglect others, but I’ve neglected studying and learning because I’ve let other things take away my time.  When I was a kid, I used to always hear the mantra of “Faith, Family, and Work”; I still believe that, and for the most part, I’ve done that.  What I’ve forgotten is that Learning=Work!  If I’m not investing in my own education, and not investing in putting my own ideas to digital paper, I’m starving the creative process, and thus starving my own career.

To that end, I guess the person that left this event the most inspired was me.   If you’re thinking about hosting one of these events, don’t forget to learn something yourself.

However, if you attend my session, you’ll get a free koozie!

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.

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

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.

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.

Stuff in the FROM clause: Base Structures

Stuff in the FROM clause: Virtual Structures

Today’s post is touching on two different categories of database objects used in the FROM clause: temporary and semi-temporary structures.  Temporary structures are database objects which are used within the context of a single scope or session in SQL Server; after their use, they are destroyed.  Semi-temporary structures can be used across multiple scopes or sessions, but they are destroyed when the server is restarted.

TEMPORARY STRUCTURES

INLINE SUBQUERIES

An inline subquery is much like a view; it’s a method of encapsulating a SELECT statement inside another piece of SQL code for performance gains or simplification of the outer SQL statement.  Inline subqueries exist only within the context of the outer SQL statement; they are not reusable from one statement to the next.

SELECT columnlist
FROM (SELECT columnlist
           FROM table) a

Inline subqueries must have be referenced by an alias (in the above example, “a” is the alias).  They can be used like any other object in the FROM clause.

COMMON TABLE EXPRESSIONS

A common table expression (CTE) is similar to an inline subquery; it’s a method of encapsulating a SELECT statement for reuse within another SQL statement; they are not reusable from one statement to the next.

; WITH a AS (SELECT columnlist FROM table)
SELECT columnlist
FROM a

CTE’s are very powerful piece of coding logic that deserves far more attention than this brief write-up; below are a couple of examples for additional reading (including how to do recursion in a CTE):

http://datachix.com/2010/02/10/use-a-common-table-expression-and-the-row_number-function-to-eliminate-duplicate-rows-3/

http://msdn.microsoft.com/en-us/library/ms186243.aspx

TABLE VARIABLES

Table Variables are another powerful temporary structure for managing data in SQL Server; a table variable is destroyed when it falls out of scope, which is more limited than the session of a temp table.  Although there might be some slight performance gains associated with using small table variables (since they are created in memory first), the real benefit stems form their use as building blocks inside user-defined functions and table valued parameters (both to be introduced soon).  The syntax for building a table variable is as follows:

DECLARE @t TABLE (ID int)

A note of caution: table variables are expected to be small (limited rows) by the SQL Server optimizer; execution plans may be negatively impacted if the amount of data being stored in a table variable is larger than x rows (and estimates for x varies greatly from 10 rows to 1000 rows).  Note that table variables can only have one index; a clustered primary key that is created on request during the declaration.

TABLE-VALUED PARAMETERS

Table-valued parameters are related to table variables; they are primarily used to pass entire result sets from one stored procedure to the next.  To be honest, I find the syntax a bit clunky, so I’m borrowing the sample code from Books Online to explain it:


USE AdventureWorks2008R2;
GO

/* Pass the table variable data to a stored procedure. */
EXEC usp_InsertProductionLocation @LocationTVP;
GO


Basically, you declare a type to hold your result set, and then create a variable to reference that result set; since types are scope- and session-safe, you can then move data around as a variable (as opposed to using a global temporary table).

LOCAL TEMP TABLEs

Local Temp Tables are a temporary structure; they are stored in tempdb, and look and act very similarly to base tables.  You can create indexes on them, you can ALTER their structure after creation, and you can use them exactly like a standard base table.  The primary difference between a local temp table and a standard table is that the temp table is available only to the session in which it was created, and it’s destroyed after that session is over. 

Syntactically, the CREATE statement for a local temp table is nearly identical to the CREATE statement for a base table; the only difference is that temp tables must have a single hash mark at the beginning of their name, i.e.:

CREATE TABLE #temp (ID int)

or

SELECT 1 as ID
INTO #temp

SEMI-TEMPORARY STRUCTURES

GLOBAL TEMP TABLEs

Global Temp Tables are a variation of  the local temp table; the same basic rules apply, except that global temp tables are not automatically destroyed at the end of a session.  Thus, they can be reused across multiple scopes and sessions just like a base table; however, if the server is restarted, the global temp tables are destroyed. 

Syntactically, the CREATE statement for a local temp table is nearly identical to the CREATE statement for a base table; the only difference is that global temp tables must have two hash marks at the beginning of their name, i.e.:

CREATE TABLE ##temp (ID int)

or

SELECT 1 as ID
INTO ##temp

Alright; one more to go: Interfaces.

Talking to Andy is probably one of the easiest things to do in the world; there have been time throughout my association with the SQL community where I’ve bumped into him at some event or another, and he always seems to remember who I am, and what’s going on with me.  I’m nowhere near the prolific writer that he is, and neither am I as plugged in to what’s going on, but yet he always seems to slide into a conversation with me like an old friend.  Andy is just a good guy to know, and I’m glad he’s a friend of mine.

Now, we haven’t always agreed on things; during the PASS elections of 2010, Andy and I looked at the process from two very different perspectives.  Some of our discussions got heated online, and going back and reading those posts today makes me a little sad.  But then I have to pause and think about the face-to-face conversations Andy and I had regarding the same subject, and it’s clear that he really does have a heart for the SQL community; even though I don’t always agree with him, I know that he’s trying to encourage people to do the right thing.  Again, he’s a good guy.

Why do I bring this up? Well, it’s because I’m on the team to bring SQL Saturday 111 to Atlanta on April 14.  We’ve invited Andy Leonard to do a precon for us on April 13; $100 to spend a day with Andy (and Matt Masson).  I know that Andy brings that same outlook to his teaching that he does to his community activities; with a certain amount of encouragement, people can do better.  If you’re not already registered for his class, you should.  You’ll learn something about SSIS, and maybe a little bit about friendship.

Cursor in stored procedure

How to Comma separate multiple rows obtained from a SQL Query

Convert multiple rows into one with comma as separator

The basic challenge is to denormalize your resultset so that multiple rows get returned as a single delimited string; while there are several methods for solving this problem, the one that I like (as of SQL 2005) is to use FOR XML PATH, like so:

BEGIN TRAN

ROLLBACK


The multiple results sets are there to illustrate each step in the process; for example, the first output shows what happens when you specify FOR XML PATH with no indicators; SQL Server automatically assigns each row in the resultset to a node named <row>:

<row>,apple</row>
<row>,banana</row>
<row>,tomato</row>

If you specify a tag name in the PATH function, each row will be replaced with that tag name; in the above example, we want an empty tag (‘’).  The result is an XML fragment with no tags:

,apple,banana,tomato

That’s almost what we want, except we need to get rid of the leading comma.  The STUFF command basically replaces the characters in the string supplied (the first parameter; our query FOR XML PATH) starting at a certain position (1 in the example above) and moving forward the specified number of character places (1, the third parameter) with the value of the last parameter (an empty space; the fourth parameter).  The final output is a comma delimited string:

apple,banana,tomato

Straightforward; gotta return to writing.

November and December were a career-changing period for me; things happened that were good, but left me extremely busy at work.  I chose to spend my free time focusing on family time, and I let other things (like my blog and my contributions to the SQL Server community) slide.  Since it’s now a week into January, I thought I would start anew, and try to kick off the year on a good foot.   Instead of making specific resolutions (which I’ll probably break), let me pick a direction and head that way.

First, I want to continue to focus on my family. Last year was an amazing year for me; I got married during the summer, and I had to relearn some things about a healthy family structure.  The first rule is that it takes more than just time; it takes an effort to communicate about things, including those things that are not always easy to say.  If you’ve followed my blog at all, you know that this is my second marriage; my first marriage ended in part because I stopped participating.  Hopefully, I’ve learned from that.

However, I didn’t just bring me into this new union of souls; I have two teenage daughters that I’ve brought along with me.   They need time to get to know their new extended family as well (they now have 10 grandparents, and uncles, aunts, and cousins), and I need to make sure that I keep investing my time in them as well as my wife.   I love these three women very much, and I need to do everything I can to make sure that they know that.   I guess I’m just stating that to lay out the framework for the principles that are following.

Second, I need to focus on my new career.  I got promoted to a management position in mid-November.  I’ve worked for this company for 9 years, and although I’ve been the senior member of the development team for most of that time, this is my first management position ever; I’m now the manager of a newly-formed team of Database Administrators, which means it’s a strange new world for me.  I’ve got to learn to do things a little differently; my goal is not to solve problems, but rather to empower others to solve problems.

Third, I want to be more diligent about my contributions to the community.   This means that I need to lay out specific time for blogging, and other community activities (I’m the treasurer for AtlantaMDF, as well as the organizer for the Eleventy-First SQL Saturday).  I also need to be more focused in my activities; I’ve spent a lot of time recently on StackOverflow, and I probably need to be less obsessive about that; I need scheduled activities, not hit-or-miss.

So there you have it; my simple return to blogging and my New Year’s “resolutions” all wrapped up in a simple package.  I’m still going to have to find time to finish the last series I started, but I’m hoping to find some time in the next few days.  Take me back, just one more time. Please?