Reactive Learning and Relevancy for the Accidental DBA

Each of us had our first month on the job as a Database Professional be it as a DBA, Developer, Business Analyst, or Engineer.  Some of us now have years or even decades between where we are now and that period in time.  Where would you begin if you had to start all over with today's data strategies and technologies?  How do you guide and train someone brand new to not just SQL Server but the data platform when you look back on it from a position of authority with thousands of hours of experience without drowning that person in information?  I'm facing that very situation as I mark the close of my 15th year in data.

1999

At the close of the last millennium I was about to be thrust into the world of SQL Server as an Accidental DBA.  I came to this crossroads with a background in Accounting, Graphic Design, Visual Basic for Applications (VBA), Microsoft Access and Curiosity; the last contributing the most to those formative first years as a DBA but surprisingly all coming into play since then in my roles as DBA, Manager, Business Owner and Instigator.  Over those early years I obtained knowledge wherever I could find it.  We take the Internet and connectivity as a global SQL Server Community through the likes of SQLSaturday and PASS for granted now, but back then the main source of knowledge still involved cracking open the spine of a book, picking up a highlighter and going to town followed by playing around the techniques and strategies afterwards on (hopefully) a test instance of SQL Server 6.5 or 7.  The first PASS Summit had just been held in Chicago, the first SQLSaturday was 10 years in the future; the first SQL Cruise was 11 years off, there was no such thing as a SQL Relay or SQL Rally and local user groups were fledgling at best.  Sure there were a few websites around that existed as sources-of-truth for SQL Server but they were few and far between.  Looking back with the clouded lenses of 15 years the only one that comes to mind that I visited regularly was sqlservercentral.  Other than that we went into battle with the words of Kalen Delaney, Itzik Ben-Gan, Kevin Kline and others - written down on the flesh of fallen trees and colored bright in shades of fluorescent yellow, orange and green.

There were, of course, also the instructor-led classes.  Online training didn't really exist yet.  The bandwidth for online streaming video just was not there yet.  I went through those Microsoft certification-based classes for SQL Server 2000 via a local training facility as well as a few "destination" crash courses in various locations and eventually my first data-based conference that covered Access, SQL, and development - an early precursor to what is now DEV/IT Connections produced by the owners of this website.

Anyone thrust into the role as a DBA for SQL Server in 1999 and the early 2000s probably faced that challenge in similar fashion:  cracking books, scraping together classes and instructor-led training as time and funding permitted and playing in their own little sandboxes.  Most were as I was - the sole steward of SQL Server in their company - as both the newly-minted and very green DBA and the subject matter expert (SME) all in one small and stressed package.  We learned things on-the-fly as we needed to in order to fix something broken in our environments.  Secondarily we dove into areas of interest as time permitted when we were not facing challenges immediately affecting our companies and customers.  I tend to call this style of training Reactionary Learning - learning new practices and skills under the pressure of fixing broken production processes as they arise and under the constraints of immediacy and the onus of getting the fix implemented quickly and "good enough".

Today

The environment for onboarding a Data Professional today is very different.  There are a large set of websites that cater to learning your technology-of-choice.  There are online recorded training sources, online instructor-led courses, virtual communities such as the PASS Virtual Chapters that meet regularly, webcasts from countless vendors serving their respective communities and the list goes on.  Books are still critical for basic and advance topics alike. 

However, just as the options for training have multiplied significantly in the last 15 years so has the complexity of Microsoft SQL Server: mirroring, clustering, Availability Groups, SSIS, SSAS, Dynamic Management Objects, Extended Events, Service Broker, In Memory OLTP... those are just some of the added technological advancements integral to just this single platform.  Virtualization and cloud computing didn't exist 15 years ago.  We're just starting down the pathways of the Internet of Things. 

The expansion of SQL Server - scaling out as it were technologically - only amplifies the number of possible answers to the question of where to begin. 

Bridging the Gap

The recent movie, "Interstellar" involves using wormholes and black holes to navigate time and space.  I now find myself needing to go backwards in time to those first days and years as a SQL DBA as I foster the training of a new hire into my team of SQL DBAs.  We posted (and filled) this position as an entry-level role.  No experience with SQL Server required.  We filled it with an excellent candidate who has a background in application development in C# and a history of solid data stewardship (but from the customer/application use angle). 

The question: Where do you point someone who is engaging with the SQL Server platform for the first time, in today's environment, when they're not under the gun of solving emergent business problems?

We have myself as the Lead and Architect to review requirements, assign resources, craft solutions for the correct level of service based upon needs for criticality and high availability.  We have a Senior and Junior DBA to implement solutions and ensure stability and integrity of the SQL Server environment.  Our new hire doesn't face those immediacies of fixing broken things without the underlying knowledge - Reactionary Learning - because unlike the typical Accidental DBA she has a support structure of a team.  So where do you point her and what technologies do you use to train her without boring her to tears?  Sitting in front of a book or computer screen for an endless series of days soaking up knowledge like a sponge.  A jail of tedium without walls or bars.

The first thing on the first day I told her one thing:

"You will make mistakes; you will run something against the wrong server.  This is a guarantee but this is also why we have a good backup and recovery strategy.  People make mistakes."

I then asked her a very important question:

"How do you like to learn?"

The statement was meant to put her at ease.  Starting something new is scary.  In our roles there are a lot of red buttons you can push (but don't).  It's easy to do wrong things and cause issues.  It comes with the level of ownership, responsibility and rights we are afforded to be able to do our jobs.  The question was meant as a way to help me guide her down the path for success without boring her and in providing a better method for learning that she's receptive towards.  Sure there will be stretches of time when she's in books or online training, but at the same time I can give her the tools and environments that allow her to succeed as she's gaining knowledge if I know how she likes to learn.

That leads to the next question that I find myself facing: What areas of the Microsoft SQL Server platform do you point the introductory DBA to first?

This is where experience can be crippling.  Think of this for a second... you've stumbled across a lamp in a cave.  Rubbing the lamp gives you one wish from a Genie that appear when you do so.  What do you wish for?  Sure, we all have fantasies of getting three wishes where there are no limits on what we wish for but being faced with that question we would probably go blank.  The sky is the limit... where to begin?  It's like that with this conundrum.  The path for learning SQL Server as defined by Microsoft Certification involves the Querying Microsoft SQL Server (461) class and the Administering SQL Server (462) class.  I've her enrolled in those two classes and she's currently navigating them in a preliminary mode through Pluralsight.  Her answer to the question of how she likes to learn was what I had expected through her interview process and through understanding those who gravitate towards the data sciences - she learns by doing.  Day one had us installing SQL Server 2014 Express Edition onto her laptop so she could have a sandbox to play in.  Now we're left with where to point her so that she can not only come up to speed with the fundamentals of SQL Server but at the same time be relevant.

Reactionary Learning and the Importance of Relevancy

Learning by itself is gratifying to a point.  It gives you a sense of accomplishment.  Relevancy to a team or organization is the missing piece of the training process if you're not solving problems affecting your environment.  Learning for the sake of eventually being productive is a long dark tunnel to navigate - seeing the light so far in the distance but not quite getting closer.  Relevancy is something that is a benefit of the Reactionary Learning process.  By being thrust into the role of both student and problem-solver you become relevant.  Your training has relevance that is immediately collectable.  It's not something that will be banked over years and eventually withdrawn like a bank transaction.  By shielding someone from the front line of engaging issues without knowledge and learning as you go protects the environment and maintains status quo for your team and customers but it dampens the sense of importance and relevancy for the student and jeopardizes their long-term success by negatively impacting their sense of worth and satisfaction.  Providing the knowledge alone doesn't make them a better resource or team member in the long run. 

Relvancy + Creative Disruption + Fundamentals = Success

We will soon be going down a path of modernizing our backup strategy by navigating to a de-duping appliance and writing backups directly to it from within SQL Server; replacing our current strategy of local SQL Server backups and then an agent-based system to pull those local backups off to long-term storage.  Recovery is probably the most-critical function for a DBA.  Others can argue it's uptime, consistency, or a host of other topics but in my opinion if you can't recover from a failure everything else is thrown to the wind.  Therefore, since backups are critical for the successful recovery of databases one can make the logical jump that backups are almost as critical.  It's one of the first things we learn as SQL Server DBAs for a reason.  It's also going to be where I point our new DBA first. 

Sure there is all the theory to learn and an argument can be made that without understanding the theory of how Microsoft SQL Server stores and retrieves data (pages, extents, etc.) and how transactions are logged and internals of the transaction log you can't make educated and correct choices in the backup and recovery strategy and that's true to a point.  However striking a balance between theory and practicality is critical.  Additionally the timing of this evolution to a new technology and process combined with the new hire of a fresh DBA resource gives us an edge:  no pre-conceived notions of how we do things now.

The mind of a human is a scary place to navigate.  The mind of a data technician is probably even scarier.  I picture an attic where half the room is organized by size, color, and hundreds of other metrics.  The other side looks like my teenager's bedroom or something you'd see from one of those reality television hoarding shows.  We like order but we live in chaos.  We like to create new things but we really like maintaining states and hardening processes.  Our current backup solution is hardened and works but it's a storage hog and recovery times could be better than they are.  But as the DBA it just works for us.  We have deployed hundreds of servers that all are configured the same and will be a pain to change. 

By enlisting a new DBA who wants relevancy and has no ties to the current system as I do she can provide the needed disruption and also gain relevancy while gaining knowledge.  In the end I assert that's what truly drives us to learn and evolve successfully.