Login or Sign Up to become a member!
LessThanDot Sit Logo

LessThanDot

IT Professionals

Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.

LTD Social Sitings

Lessthandot twitter Lessthandot Linkedin Lessthandot friendfeed Lessthandot facebook Lessthandot rss

Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.

Your profile

    Search

    XML Feeds

    Google Ads

    « The backup thingLearning how to program also means you have to try what you learned. »
    comments

    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.

    About the Author

    Ted Krueger is a SQL Server MVP and has been working in development and database administration for 13+ years. Specialties range from High Availability and Disaster / Recovery setup and testing methods down to custom assembly development for SQL Server Reporting Services. Ted blogs and is also one of the founders of LessThanDot.com technology community. Some of the articles focused on are Backup / Recovery, Security, SSIS and working on SQL Server and using all of the SQL Server features available to create stable and scalable database services. @onpnt Personal Blog over at http://onpnt.wordpress.com/
    Social SitingsTwitterLinkedInLTD RSS Feed
    1517 views
    InstapaperVote on HN

    6 comments

    Comment from: SQLDenis [Member] Email
    SQLDenis I agree fully, the same is the case with the myriad of libraries that web developers use nowadays, you have to be able to find the bug in the library that you are using, fix it in your environment and then submit the patch or bug details to the developers of the library so that they can patch it. You can't just say jQuery or ExtJS has a bug and that is why the page looks screwed up anymore.

    The same is of course true with stored procedures that you inherit/purchase, debug the code and fix it if the license permits it, otherwise contact the vendor and have them release new procs to you with the problem fixed



    11/13/12 @ 09:52
    Comment from: chopstik [Member]
    chopstik Why, surely you're not suggesting that the title makes the man (or woman)?! Sacrilege!

    Joking aside, I have more of a comfort level with people who've come up through the ranks and learned the hard way, so to speak, and can understand why things work the way they do sometimes and, more importantly, can come up with viable solutions to resolve them. Well put, Ted!
    11/13/12 @ 11:18
    Comment from: Ted Krueger (onpnt) [Member]
    Ted Krueger (onpnt) Thanks guys :)
    11/13/12 @ 11:20
    Comment from: Frank Gill [Visitor] · http://skreebydba.com
    Frank Gill Great post. I would say that stories like your tale of replication dlls and reading people like Paul Randal, Alan White, Jonathan and others inspires me to learn new stuff. Sometimes that is self-study, but more often it involves talking to a networking, Windows or storage guy to learn something new.
    11/13/12 @ 14:30
    Comment from: Ayyappan [Visitor] · http://SqlServerRider.wordpress.com
    Ayyappan I like this post and I believe that without understanding fundamentals, nobody can help or teach others. Self-learning and self motivation is the key to be successful in IT Industry.
    11/13/12 @ 21:01
    Comment from: Justin Dearing [Visitor] · http://justaprogrammer.net
    Justin Dearing Here's a perfect example of "deer in the headlights" fear of troubleshooting. I found on serverfault:

    http://serverfault.com/questions/448577/new-property-for-indexing-service-on-windows-server-2008-where-to-put-register/448623#448623

    The author didn't even bother to think: maybe I need to add that registry key. Maybe they're a complete novice and that's the first time he saw the registry editor.
    11/14/12 @ 06:57

    Leave a comment


    Your email address will not be revealed on this site.

    To mislead the spambots.

    Your URL will be displayed.
    (Line breaks become <br />)
    (Name, email & website)
    (Allow users to contact you through a message form (your email will not be revealed.)