How Do I Measure My DBA Skills Part – 1

 

Career development and progression is a hot topic for everyone.  It starts really early in life like when some adult asked you, “What do you want to be when you grow up?” You might have said “firefighter”, “ballerina”, “ice skater”, or “gymnast”.  I’m certain you didn’t say “DBA”, but here you are anyway, at my blog, trying to figure out a career as a Database Administrator.

So, what does career progression look like for a Database Administrator?  How do you move forward in your career with SQL Server? What skills should you have at year 2? Year 5? Year 10? This post will help you answer those questions.

There are all kinds of DBA’s who do all kinds of different work.  That was the challenge of coming up with the information I’m going to share with you over the next several posts. I chose to create two separate career path skill lists.  One for a production DBA and one for a Development DBA. The primary reason for this is that people typically become a DBA through one of two paths – Systems Administration and Developer.

Were you a System Administrator or Network Engineer when you got your start? You will probably become a Production DBA.  Did you get your start as a .Net or Java Developer? You’ll likely be more of a Development DBA. Different specialties within those general paths can develop from there.

What Does a Production DBA Do?

Before we jump into skills a Production DBA needs, let’s answer what a Production DBA does. As an oversimplification, a Production DBA keeps the lights on. She makes sure that break/fix items are resolved for customer facing processes. As a Production DBA, you will be resolving performance issues in the production environment and at least occasionally these issues will be live issues affecting a large number of people, either internal or external to the company. You will often be either designing or assisting with the design of systems, answering questions like :

  • How will this system interact with other systems?
  • Does interaction with other systems need to be real time or can it be asynchronous?
  • How will we make sure this system is always available?
  • What technologies will be used once the above decisions are made?

These, of course, aren’t the only questions you’ll need to answer as a Production DBA. There will be others like:

  • Why did this system go down?
  • How do we prevent this outage in the future?
  • Who granted the permissions that allowed this to happen?

Sounds exhilarating and terrifying all at the same time, right?!

On that note, here is the first level of skills for a production DBA. Look it over, ponder it and see what you think about the list.  Keep in mind, this is level 1, the entry level Production DBA skillset. I’m trying to answer the question, “What does a beginner Production SQL Server Database Administrator do and what skills should they have?”

Production DBA Level 1

  1. Production DBA – 0-2 years of experience
  2. Handles level 1 triage for things like SQL Server Agent job failures, user issues, and reactive tickets.
  3. Installs SQL Server instances following a process designed by others.
  4. Manages most administrative aspects of non-prod environments with assistance from more experienced DBAs, including the application of patches to pre-production.
  5. Carries out defined tasks like managing new users, running established audit processes, restoring databases to non-prod environments as required.
  6. Basic T-SQL development. SELECT, INSERT, UPDATE, DELETE
  7. May participate in SQL Server migrations in a guided manner.
  8. Demonstrates understanding of backup/restore processes.
  9. Demonstrates values driven behaviors such as humility, integrity, teamwork and is teachable.

A beginner production DBA should at some point be handling break/fix triage work.  This will often comes in the form of SQL Server Agent job failures and requests from users that often say little more than, “It’s broken” whatever “It” is.  At this level, you may have a more senior level DBA hand you a guide and say, “We need a SQL Server installed. Here are the instructions for that. Please have this done by noon.”  You need to understand enough to get through that task successfully.

At least some beginner DBA’s maybe be given one or more non-production environments that they are the primary DBA for.  This provides a mostly safe place for mistakes to be made and for learning to occur. The environment isn’t production so you aren’t going to break anything that is used by external customers.  Now, you might break something that the Developers are using, but that’s less impactful than breaking external customer technology. Managing a non-prod environment gives you a place to learn the other skills in this list.  Developers will need new Logins and Users created as they build new applications.  They will need data refreshed from production and so at this level, you’ll get experience with restoring backups and you will have the opportunity to grow you skills with T- SQL.

People Skills for Information Technology

Now about that #9 you see in the list –  “Demonstrates values driven behaviors such as humility, integrity, teamwork and is teachable.”

If you thought you would get a job in technology so you didn’t have to deal with people or work on your people skills, I’m hear to tell you that you’re mostly wrong.  Sure, you can be that person who hides in their cubicle and pushes off the “people” part of their job to someone else.  But, it is unlikely your career is going to progress all that far with that approach.  You’re going to need to know how to interact appropriately with your direct co-workers on your team, Developers, DBA’s, end users, your boss, vendors, etc.  So, if you suck with your people skills, get a good book, or two or three, and incorporate that knowledge into your life.  Click here for a book I recommend and look at the other suggested reading at that bottom of the page. A primary reason I really recommend the book by Travis Bradberry and Jean Graves is that it gives you concrete examples not only of high and low emotional intelligence, but specific actions you can take to improve your people skills.

Next Steps to Take

  1. Write down the list above, or copy paste to a Word doc.  Think carefully about each one and whether or not you currently meet this criteria.  Put an “X” next to any item you need to work on.
  2. For each item you placed an “X” on, create a plan for improving skills related to that item. The internet is your friend here. If you’re not sure how to create Logins and Users, then open your favorite search engine and look around.  There will be people and tutorials that explain it.
  3. If you would like help with anything on this post, or with something else you’ve seen on the site, reach out to me here or on Twitter and I’ll be glad to offer assistance.

Lessons Learned Updating to SQL Server 2017 AlwaysOn Availability Groups

In late 2019, a project that had been in progress for well over a year finally came to a conclusion.  I had collaborated with a number of people to migrate a stand alone SQL Server 2008 and two stand alone SQL Server 2008 R2 instances.  Each stand alone SQL Server was migrated to a three node Availability Group. Here are a few things learned along the way.

Automatic Seeding

First, consider using automatic-seeding if you are migrating to AlwaysOn Availability Groups.  I hadn’t previously worked with anything newer than SQL Server 2014 so I was unaware of this feature.  It is new as of SQL Server 2016. In this case, the old SQL Servers were migrating up to SQL Server 2017, so this option was available to us.  For a couple of months leading up to the migration event there had been various tests involving the set up of the AGs.  One of those tests involved restoring a full backup followed by one or more log backups over on the secondary nodes.  As the migration date approached, we started experimenting with auto seeding.

The auto-seeding feature streams the database from the primary to one or more secondaries behind the scenes.  This is accomplished using the endpoints created during the Availability Group creation process. This feature can eliminate the need to create scripts to handle the restores of databases over to secondary nodes in the AG.  

There are four ways to monitor the process of the streaming of the databases to the secondary nodes.

  • First, the SQL Server Error Log makes entries about the process.
  • Second, various DMVs contain information about the status and progress of automatic seeding. 
  • Third, Backup history tables in MSDB can be queried.
  • Fourth, Extended Events can be used to monitor the progress.  We chose to query DMVs during the migration.

Handling Connection Names

Second, ponder how to handle the scenario where connection names for applications change. As it turns out, a lot of meaning and importance is attached to names.  The computer and SQL Server instance names we were dealing with were deeply ingrained in the business. The names had been around for years and were used everywhere in connection strings.  If we migrate to new SQL Server instances, how do we handle that? 

One option is to create an alias in DNS that points to another location. Several months before the actual migration, we changed the computer names for each of the stand alone SQL Servers. The Infrastructure team used the previous computer names as aliases that then pointed to the newly named computers. This does require a change inside SQL Server, by the way.  SQL Server is aware of the computer it is installed on, so if you do this, know that you have to make a change in SQL Server as well. 

Let me explain the concept by way of example. Let’s suppose you have a computer called MyServerABC and it has a default instance of SQL Server on it.  This means that database connections also use the name MyServerABC to talk to the databases.  That connection name might be used in a lot of applications.  So that tens, or maybe even hundreds, of connection strings don’t need to change when the SQL Server is migrated, here is what you can do. During a maintenance window, change the name of the computer and make a change to SQL Server so it knows the new computer name it is on. Here is a link to describe how to do that in SQL Server and it has a discussion of other considerations when doing this sort of thing.

Let’s suppose the new computer name is MyServerXYZ. After the previous actions are taken, in DNS a new record is made called “MyServerABC”.  That alias is then “pointed” or directed to the computer name “MyServerXYZ”.  Now, applications that use MyServerABC as a connection name can continue using that connection name.  When the application makes a call to MyServerABC, that call is simply re-routed to MyServerXYZ and the application is none the wiser.

This exact change process worked for us early on.  Later, once we migrated the first stand alone SQL Server to an Availability Group, a person on the Infrastructure team changed the alias so that it pointed to the AG Listener instead of the old server we just migrated from.  Connections were then instantly routed to the new SQL Server 2017 AG. 

Database Migration Assistant

Third, the Database Migration Assistant is software from Microsoft that evaluates a SQL instance and the databases on that SQL Server for readiness to be migrated to a new platform. This tool can help migrate databases to Azure, but we were executing a migration involving on-prem to on-prem.  The tool provides an assessment of and information regarding scenarios in use in your environment that might block a successful migration as well as offering information on new features to leverage in the new SQL Server. 

We were able to find several things in our environment that had to be changed prior to the migration using this software.  Without the assessment, we would have migrated only to experience failures of various kinds in the new environment.  

Planning Software

planning

Fourth, use planning software of some kind so the migration steps are known and progress can be tracked.  One of the things I chose to do was plan out each step and create an electronic project board for all the things that needed to happen the day of the migration.  I had been using Office 365’s Planner at that time, so I created my steps there.  One of the Developers converted that to Trello because that is what the Dev teams were using at the time, and the Devs were at the office with us to help with testing applications post-migration.  The Trello board was made visible on a couple of large, wall mounted TV’s for everyone to see.  This allowed everyone to know what had been done, what was being worked on and what was next.

Communication

Fifth, think carefully about how the migration team will communicate during the migration.  (All in the same physical room? Company conference bridge while working remote? Conference call with a support vendor? Remote work platform like Teams or Slack? Some combination of these things?)

If you have a big room that will hold everyone, that might be a great option. Remember, this happened back in early December 2019, pre-covid. So, having a dozen or so of your favorite co-workers all in a room made sense.

Meeting together allows for easy, fast communication by simply turning to the person in the room to discuss something or ask a question. Collaboration is smooth and convenient in that scenario.  As I mentioned earlier, we leveraged a Trello board that was displayed on a couple of large TVs so everyone can see what has been worked on, what is currently being worked on and what is next.  

Be aware and mindful of the human tendency to talk when idle though.  If you get a dozen people in a room and only a few of them are busy at the moment, there could be a significant amount of chatter to block out for the people who are busy at that moment.

These days, now that the U.S. is experiencing an explosion of work from home due to the pandemic, you would probably set up something like Teams or Slack and use that as your collaboration platform so people can collaborate from home on migration day.  Platforms that allow for phone calls, screen sharing and quick collaboration among large groups of people would be essential in a large scale, high impact IT project. In those scenarios, the people collaborating still need to think carefully about communication so that people aren’t talking over each other while addressing the migration work. 

Well, that’s it for now.  I hope these points help you consider some things that maybe need to be included or discussed as part of your next IT project.  

Next Steps To Take

  1. Download and try out the Database Migration Assistant. 
  2. Check out Office 365’s Planner/Tasks app or something like Trello or Jira to help you not only with migration planning, but stayong on top of your every day workflow..
  3. If you would like help with anything in this post, or with something else related to SQL Server, reach out to me here, or on Twitter, and I’ll be glad to offer assistance.