Recently, I was discussing a problem I had with Merge Replication and the underlying replrec.dll at the time a service pack was applied to a SQL Server Instance. In order to prevent you from having to (re)read the article on the problem I uncovered and resolved, I’ll sum up that it required a deep look into the DLL coding and differences based on the versions that were released. Without getting excited and going on about how that problem was resolved, I’ll stay on track to why I’m writing this. The problem isn’t really the key; it’s the discussion itself.
This discussion was with several senior-level administrative and higher individuals. During the conversation, I saw the distinct deer in the headlights expression. I’m throwing out lack of experience with technology as a factor in the fear right now. That article usually sparks the question, “How the hell did you figure that out?“ I like to think that most of us in IT – database administrators, developers, UX and so on – all had to make our way up through the ranks, if you will, the jobs that form the solid foundation we all should have of computing. Coming from a Windows background with about ten minutes of looking at a UNIX screen and a little over a year of dreading the AS400 green screen, I see the value in a structured career and staged promotional path in which skills are the key valued commodity. This means roles in help desk, systems administration, business analytics, data visualization, leadership roles and so on. These are not meant to throw an inexperienced individual into a job simply because they cannot perform a higher-skill position. I’ve known many DBAs that weren’t trained as DBAs but could out-skill a lot of seasoned DBAs because they spent the time to build focused skills on that one technology. We can all gain a focused skill by reading, trying things on the side, and simply following mentors in the community. What we cannot obtain by these methods are the fundamental foundation of skills that allow us, IT Professionals, to completely embrace the troubleshooting methodology and underlying computing structure we are working on.
Moving back to the conversation regarding the replrec.dll problem; in order to fully investigate the problem with replication in that particular situation, there was a need to understand SQL Server Replication, but more so, the underlying communication between the entire structure and path that was taken from start to finish. Understanding how this functions, understanding how the entire system works together, was important. Something equally important was knowing and understanding the tools and methods that were needed in order to investigate at a level of depth that would either find the problem or rule objects out as the problem.
In this case, I used Process Monitor, a tool I’ve relied on for many years. Without a question, it was a tool that I learned to utilize from my earlier years as an administrator and systems engineer. (Note: the foundation being built.) After identifying certain files that were part of the overall process, the need to look into those files came up. Pulling from the same skills of building in stages, turning to tlbimp and ildasm was the obvious next step in order to review the coding and make an absolute decision of the builds of the DLL had been altered through each build.
The merge replication and replrec.dll situation was one of hundreds of situations where I, an IT Professional, pulled from the foundation I built over the years. The foundation was built only by acting in roles that exposed me to computing from a troubleshooting, developing, and building perspective. Knowing how, when, and why a system functions is critical to being capable in our positions. The way we learn this is through a combination of education (be it formal schooling or self-training), skills compounding from a career based on movement among roles (with a focused path), and then applying all the skills compounded to the problem in front of us.
SQL Server is no different when it comes to the need, or I’ll go as far as saying requirement, to have a solid foundation of knowledge of how the systems SQL Server live on work. We all see and look up to people like Jonathan Kehayias (b|t), Erin Stellato (b|t), Paul Randal (b|t), Paul White (b|t), and so on. I’m willing to bet that all of those leaders and IT Professionals have the solid foundation I’ve written about today. That is what makes them leaders and at the top of their specialty.
Last Words
The entire point this article is; don’t be in such a rush to get to the level of “seasoned professional” in your career. It will happen if you put the work in. Each position we hold over our careers and the paths we’ve chosen should be there for much more than a paycheck. Each role should build your skills so you become the IT Professional that can hold conversations about troubleshooting steps like the one discussed in the replrec.dll article, and perform those steps yourself. Remember, we’re more than DBAs or Developers, we’re IT Professionals. We need to instill the fact that we are where we are because we went through the same trials and professional development that someone asking for our help may be going through now. Help them understand the reasoning and why they should embrace what they are learning, not just throwing it to the side and flushing it from their memory. Even more so, don’t be so keen on needing to be the seasoned professional that you see in some others right now. Trust me, you’ll only hurt yourself by trying to get through to the end before you’ve put the work in the middle.
Last, Last Words
One of my favorite parts of the book, “Troubleshooting SQL Server: A Guide for the Accidental DBA” was the first chapter, “Defining a Troubleshooting Methodology”. Jonathan and I agree that knowing where to start, determine the underlying medium objects involved and how to end a troubleshooting task, is absolutely critical to our success. This goes with understanding the full depth of the complete surroundings and internals that are around SQL Server.
