How Do I Measure My DBA Skills Part 7

Over the past few weeks I have been writing about DBA skills for various career levels and, so far, for a couple of different DBA types – the Production DBA and the Development DBA. Today, we’re examining the Lead Development DBA. You’ll discover what this person needs to know

DEV DBA III/Lead Dev DBA – 5 to 7 Years

  1. All competencies from previous level.
  2. Manages most administrative aspects of non-prod environments without assistance from other DBAs.
  3. Participate in T-SQL development and database design of advanced complexity.
  4. Investigates potentially complex data issues within SQL Server.
  5. May have several years of progressive experience with SSIS, SSRS or SSAS.
  6. Administers source control systems for the environment.
  7. Regularly automates tasks. This should include the use of T-SQL, SQL Server Agent, and PowerShell.  May include the use of other languages like Python or C#.
  8. Creates and manage design documentation related to development work.
  9. Regularly explores, learns and implements new SQL Server development features. Examples would include new T-SQL enhancements and new feature sets like Temporal Tables for SQL Server 2016 and Data Virtualization for SQL Serer 2019..
  10. Advanced understanding of execution plans, indexes, and query tuning.
  11. Investigate complex data integrity/repair issues within SQL Server.
  12. Leads in knowledge sharing in two or more areas from levels I, II, or III.
  13. Assists with SQL Server migrations and upgrades in DEV/QA or production.
  14. Mentors Junior DBA’s and Developers.
  15. Participates in code reviews.
  16. May contain competencies from Production DBA levels up to level 1 or 2.
  17. Demonstrates emotional intelligence and may take an interest in leadership roles.

Managing Non-Prod SQL Servers

As a Lead Development DBA, you are managing your company’s non-prod SQL Servers without the regular input of other DBAs.. That doesn’t mean you know everything about managing the environment, but it does mean you are no longer asking any basic questions. You’re managing new SQL Server installations and post-install configuration, managing access to the SQL Servers, and SQL Server maintenance (backups/restores, index and statistics maintenance, CHECK DB, etc).

You Have T-SQL Skills

You know how to use views for inserting, updating or deleting data. You know when to use a temporary table, a table variable or a derived table. You also know when dynamic SQL is appropriate, and no the answer isn’t “never.” Your stored procedures have error handling using TRY… CATCH and/or THROW and they do data validation for inputs. You know and avoid the problems associated with scalar user defined functions. You consume development material from people like Itzik Ben Gan and Gail Shaw without your eyes glazing over.

SQL Server Performance Tuning and Optimization

Performance Tuning and optimization is your bread and butter. You’ve probably read the various editions of books on execution plans by Grant Fritchey. You know who Brent Ozar and Hugo Kornelis are and you have frequented their websites to learn about execution plans and making SQL Server go fast. You know how to leverage the Query Store. MAXDOP and Cost Threshold of Parallelism are things you understand and know what to do with at the server level and how it affects queries running on the SQL Server. You also know that MAXDOP can be set at the database level in newer versions of SQL Server. If you didn’t know that, see this.

Working With Other SQL Server Components and Features

Depending on the needs of your employers, you are likely fairly comfortable with SSIS, SSRS or SSAS. You can develop solutions with those tools that go beyond basic things. SSRS Administration using the Report Manager and Report Server URLs is familiar to you, for example. Complex SSIS packages are something you’re not afraid of at this point.

Mentoring and Knowledge Sharing

At this stage of your career you will be expected to be a leader in your group and share knowledge with others. You will be skilled enough to share your growing expertise in 2 or more areas. You may be the go to person for execution plan analysis, Query Store and T-SQL.  Share that knowledge with others. Make someone else’s professional life better by sharing your experience. This will not only benefit the other person, but you as well.  Nothing solidifies learning like trying to teach something to someone else!

As part of your leadership among other people, you should demonstrate a fair amount of emotional intelligence. You are able to manage your own emotions and the emotions of others during your interactions. You’re also taking on more and ore the role of a leader at this phase of your career. People will be looking to you for guidance and decision making.

Next Steps To Take

  1. Look at the criteria in this post and make a training plan for the things you know you need to work on and put that plan somewhere that you will see on a regular basis.
  2. Contact me here for questions about this post or the skills listed in it. You can also reach out to me via Twitter using the handle @leemarkum.

 

Introduction To PowerShell For The DBA Part 2

In Part 1 of this series we began to look at how you can leverage PowerShell as a DBA and there was a brief discussion about automation. Today you will experiment with the DBATools command Copy-DbaLogin and learn about Out-Gridview and the -whatif switch.

Let’s suppose you have one, or more logins you need to get from one SQL instance to another.  Perhaps you are setting up a new test environment for SQL Server 2019 and you need  to move this login to that environment. Maybe this is one node of a SQL Server AlawaysOn Availability Group and you need to get this login, with its SID, on each node of the AG. Below you see I have a screenshot of a login called mysqltestlogin. It’s on a SQL Server 2017 instance.

 

How would we copy this with PowerShell? First, let’s use the Get-Help command to see what commands are available related to logins.

Get-Command *login* -module DBATools, sqlserver

From that output you see a command called Copy-DBAlogin in the DBATools module.

So now run the first command to see the syntax and run the second one to see all the help data, including some examples of how the command works:

Help Copy-DBALogin

Help Copy-DBALogin -Full

The most common way you’re going to use this command is with a Source and Destination SQL Server name and one or more login names. See the example below.

These logins can be SQL logins or Active Directory Logins. One thing to note about this command is that the SID is copied with the login as well as the associated permissions. If you need to, you can use the -Force switch to re-copy an existing login. You might need to do this to ensure that logins, SIDs and permissions are the same between all nodes involved in a group of servers. Those SQL Servers could stand alone instances that are all servicing a particular application or they could be nodes in a Failover Cluster Instance or an Availability Group.

Copy-DBALogin -Source MySourceSQLServerIntanceName -Destination MyDestinationSQLServerInstanceName -Login Login1, Login2, Login3

Maybe you want to copy all the logins except a certain small list. In that case, use the -ExcludeLogin parameter and pass in the logins to omit from the copy operation.

For my scenario from above, my command looks like this.

Copy-DbaLogin -Source MyPCName\Kronos2017 -Destination MyPCName\Romulus2014 -Login mytestsqllogin

And the output is this.

DBATools Copy-DBALogin Output

 

What Is Out-GridView?

You can also use a cmdlet called Out-GridView to pass the objects of the pipeline into a GUI where you can then select the items you want to have PowerShell do the action against.

Get-DBALogin -Sqlinstance MySourceSQLInstance | Out-GridView -PassThru | Copy-DBALogin -Destination MyDestinationSQLInstance

Here are the results of that Out-GridView. Click to enlarge.

Out-GridView Example

To use this for selecting only the rows of output that you want to do something with, left click the row you want to actually copy and then click the OK button in the bottom right. That will copy the selected row. You can use Shift + Click or Control + Click to do a multi-select. There is a Filter option at the top of the Out-GridView screen that also allows you to trim down the results you want to copy.

Of course, using Out-GridView re-introduces the human element to the process and so isn’t great when the goal is to completely automate a process. However, it is great if you want to see the output before you do something you don’t want to do. As a consequence, if you see results in Out-GridView that don’t match what you expect, then you can simply click on Cancel in the lower right hand corner and the PowerShell will do nothing.

Using the -WhatIf Switch In PowerShell

This brings me to another switch that helps in this scenario where you want to see what a command is going to do before you actually executing it. There is a switch called -WhatIf that will stream output showing you what a command would do if it were actually executed. This is a great tool for testing your commands. Often there will be errors or other unexpected results from a command. Using -WhatIf is a great way to catch this before you actually execute the command for real.

So far in this article, you have reviewed what you can do for a very specific object, logins. Let me suggest that you also look at what can be done at the wider scope of the SQL Server level by running the below. You may remember from the previous post that GCM is an alias for the Get-Command cmdlet.

GCM *instance* -Module DBATools, SQLServer

Here is my output for the above. Click to enlarge.

Get-Command Instance :evel Commands

As you see, there are a lot of things you can do with commands related to the SQL Server Instance.

If you want to consider automating the scripting out of your SQL Server instance objects without buying software to do it, then check out the Help for Export-DBAInstance, which is one of the commands that is in the above list.

Help Export-DbaInstance -Full

 

Next Steps To Take

  1. Try out Copy-DBALogin in a test environment. Use it with the -WhatIf switch, or pipe it to a file by using the Out-File command to see what the command does when it runs.
  2. Experiment with various commands and Out-GridView in your test SQL Server environment.
  3. Don’t have a test SQL Server environment? Consider learning what Export-DBAInstance does and using it as part of an “Easy button” for creating a test environment on a fresh install of SQL Server. Or, look up Start-DBAMigration for this task as well.
  4. 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.

Introduction To PowerShell for the DBA Part 1

Automating Tasks With PowerShell

What we’re really talking about in this series is automation, specifically by using PowerShell. Now, in simple terms, automation is about removing the human, manual element in doing tasks. This will produce time savings for you as a DBA in the long run and provide better consistency in your environment than doing things manually. Better consistency means reduced or easier troubleshooting because your SQL Server environment will be more consistent with automation. All of this will make your SQL Servers easier to manage.

Imagine being able to migrate an entire SQL Server instance with a single command! You can do this with PowerShell. You want to copy logins from one server to another without installing sp_help_revlogin and  working through the scripting process involved? You can do that with PowerShell.  You want to copy DatabaseMail settings from one server to other servers without writing out all the T-SQL? You can do that with PowerShell!

With PowerShell you can get information faster than from a GUI, especially when that task needs to be done on multiple computers. These tasks include things like like search event logs, search the SQL Server Error Log,  get the status of services, see sp_configure information and more.

You can also do things like copy SQL Server jobs from one server to another or export the results of sp_configure to a file. When doing an action like backing up a database, PowerShell also enables you to output the actions of the script itself and thereby create a self-documenting log that you can look at afterward to see exactly what the script did.  With a module called DBATools, you can migrate an entire instance to a new SQL Server with a single, short command.

Getting Set Up for Using PowerShell

PowerShell is already installed on Windows. Different OS versions have different versions of PowerShell. There is a process to use for updating your PowerShell version. I’ll not be showing that process in this series though.

Also, in order to follow along in the series. You will need to get the DBATools module for PowerShell. Instructions for doing that are located at DBATools.io. The simple answer is to open PowerShell as an Administrator and run the below command. There are some things to consider and so that’s why the link to DBATools instructions on installation.

Install-module DBAtools

 

You will want the SQLServer module in order for some of these commands to work properly, and you may want to explore the more “native” way to use PowerShell with SQL Server, without the aid of the DBATools module. I think DBATools simplifies things so immensely that it is indispensable. However, you may be curious about what is in the SQLServer module for PowerShell. If so, you can add the module to your PowerShell by opening  PowerShell as an administrator and running the following.

Install-Module -Name SqlServer

 

Once you have DBATools and the SQLServer module installed, you are ready to get started.

Finding Available PowerShell Commands

Get-Command: This cmdlet enables you to explore what is available to do in PowerShell.  For instance, you might run the below to see what commands are available in PowerShell related to backups. Notice you can use asterisks as wildcards as well as specify a PowerShell module to look in for commands. If you don’t have the DBATools module, I urge you to get it installed and start using it, if for no other reason than that you will need it if you’re going to follow along with the examples!

Get-Command *Backup* -Module DBATools, SqlServer

The above command will output a long list of things.  You can backup computer certificates, database certificates, find information about backup history and throughput, as well as a lot of other things beyond simply using PowerShell to make a database backup.

Maybe you’re interested in what is available for Logins or Database Mail. If so, try the below commands.  Notice that the second command says “gcm”.  What is that? Well, that is a shortened version, or alias, for Get-Command.  Most, maybe all commands, have an alias you can use.  Aliases provide a shorter way to write a command, but when someone else is looking at your code, then they have to know what your alias is for. Otherwise it will be harder to figure out what you’re code is doing.

Get-Command *Login*  -Module DBATools, SqlServer

gcm *mail*

Getting Help with PowerShell Commands

From the above example where you are looking for commands containing the word “Login”, you should see something similar to the below if you have DBATools and the SQLServer module installed.

 

Let’s start simple and review Get-DbaLogin.  In your PowerShell window run the command  below.

Get-Help Get-DBALogin -Detailed

From this code you will get an output that provides a summary of what the cmdlet does, the syntax options it can be used with and a text description of what those syntax options do.

Let’s say that you’re interested in finding information about the Logins on your SQL Servers. If you just pass this command to PowerShell you will get a list of all the logins on the SQL instance with some properties. Of course, you will want to substitute your own valid SQL Server instance name.

Get-DbaLogin -SqlInstance MySQLInstanceName

The output will list the computer name, SQL Server instance name, name of the login, the login type, create date, the last login timestamp and some other useful properties.

Let’s suppose we only cared about the logins that weren’t system logins so we want to exclude logins like NT Service\SQLWriter and the ones whose name starts with ##. How do we do that? Well, look at the help output again and notice the -ExcludeFilter option. Add that to the earlier command, like so:

Get-DbaLogin -SqlInstance MYSQLServerInsstane -ExcludeFilter '##*', 'NT*'

PowerShell Piping

Now let’s suppose that you are only interested in a couple of the properties that are output from this command.  You’re interested in the login name and the last time that login accessed this SQL Server.

To get only those properties we can do what is called “piping”.  This is where the “|” symbol is used to move PowerShell output from the left over to the right side of the script objects.  This is often done for filtering or to pass along PowerShell output for further processing by other commands.  PowerShell output looks like text, but it’s really .Net objects.

In the first example below, you’re passing all the objects left from Get-DbaLogin when the ones with ‘##*’ or ‘NT*’ are eliminated and then telling PowerShell to display only the Name and LastLogin objects.

In the second example, you will be sending the output of the command to a file.

Get-DbaLogin -SqlInstance MySQLServerInstance -ExcludeFilter '##*', 'NT*' | SELECT Name, LastLogin

Get-DbaLogin -SqlInstance Skolarlee-PC\KRONOS2017 -ExcludeFilter '##*', 'NT*' | SELECT Name, LastLogin | Out-File 'C:\DBATools\LoginsOutput.txt'

On my local PC this returns the sa account and my local Windows account along with the last time these accounts accessed the SQL Server. This sort of information is useful, probably in a number of scenarios, but let’s suppose that you’re doing an audit of SQL Server logins because you suspect you have a lot of left over, unused logins.  You might want to examine them to see if you can drop users and logins that are no longer being used.  This sort of thing makes your SQL Server easier to manage because you don’t have unused Logins and database users cluttering up your SSMS when you’re connected to a SQL Server.

Let’s suppose you don’t want or need to do something with this information right now, but you want to review it later, or provide it to someone else for review. What can you do? The simplest thing is to use the second command above to send the PowerShell objects to a text file by using the piping technique I mentioned earlier.  The directory in the Out-File command needs to exist already but the command will create the text file for you.  This information can be written to a share for your team to access later.  You can also do things like email this output to the team using a PowerShell command for email. If you run GCM *mail* in PowerShell, you will find a command that lets you do this.

How To Script Out SQL Server Logins With PowerShell

Another powerful thing that can be done with a one line PowerShell script is scripting out your logins and users.  This cmdlet from the DBATools module will create a script of your logins at the server level and their corresponding database users and all associated permissions. Look at the help for this command.

#Start by getting the help for the command
Help Export-DbaLogin -Detailed

Now that you have reviewed the help content, let’s try something.

Export-Dbalogin -SqlInstance MySQLServerInstanceNameHere -Path 'C:\DBATools\'

Now go to the C:\DBATools\ directory and double click the .sql file.  SQL Server Management Studio will launch and prompt you to connect to a SQL instance. Once you do that, the script will load. Review the output and take a look at the Help output from PowerShell to see what else you can do with this.  This command gives a DBA a great way to script out login and user information, and this can be helpful for migrations or for providing a history of changes to logins, users, and their permissions.

Next Steps To Take

  1. Explore more commands and the possibilities that they offer. Here is a place to start.
GCM *export* -Module DBATools

Help Export-DbaInstance -Detailed

Export-DbaInstance -SqlInstance MySQLServerInsanceNameHere -Path C:\DBATools\

2. Find a book or video series on PowerShell and consume that material.

3. Read some of the documentation and blogs over at dbatools.io .

4. 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.

How Do I Measure My DBA Skills Part 6

With the last post, we began talking about the Development DBA and the skills needed at the beginning of this career path. Now it’s time for you to ponder what the next level looks like.

Dev DBA II – 2 to 4 Years of Experience

  1. All competencies from level 1
  2. Develop basic to intermediately complex stored procedures, triggers, views and other database objects.
  3. Will have some experience with SSRS, SSIS, and/or SSAS development, deployment and possibly administration.
  4. May administer source control systems for the environment.
  5. Promotes SQL changes from Dev up through all environments, including production.
  6. Contributes to automation, particularly using native SQL Server methods, but could also leverage PowerShell or other languages for automating tasks (Python, C#, etc.)
  7. Designs pre-prod testing of SQL code prior to production upgrades or migrations. This includes performance and regression testing.
  8. Basic to mid-level understanding of execution plans, indexes, SQL Server statistics, and query tuning.
  9. Investigate basic to moderately complex data integrity/repair issues within SQL Server
  10. May begin leading in knowledge sharing in some capacity in one or more areas from level I or II.
  11. May take an active interest in leadership and in development of leadership skills, including emotional intelligence.

In years 2 through 4 the Dev DBA will work with more complex T-SQL such as recursive CTE’s, and error handling with TRY CATCH or the THROW syntax will likely be introduced at this stage. You may begin writing database views during this part of your career and leveraging them to make query writing a bit simpler for yourself and others. You are likely to be exposed to T-SQL Triggers and you’ll need to understand them and even maybe write a few triggers of your own.

You will likely start to get some sort of regular exposure to SSRS, SSIS or SSAS at this point. This will of course be based partly on your own interest in learning the tools of the trade and what is in use already at your employer.

Source control and the process of promoting changes from source control up into QA, and even production, may be something that begins at this level. After all, as a person who is writing a fair amount of code, you will have an interest in ways to manage code changes.

Automation

 

automation example

Let me ask you a question. Would you rather wash clothes manually with a washboard and tub or use a washing machine? It seems like a silly question. You would want to use a washing machine. You probably can’t imagine washing clothes without one.

In a similar thought process, there are things that you and others at your job will not want to do over and over in a manual way.  Accordingly, you will make more significant contributions to automation of tasks at this level in your career. SQL Agent will become your friend and learning to script out processes to make them easily repeatable, rather than doing everything in the SSMS GUI by hand, will occur more frequently. You may automate tasks with PowerShell for sure, especially using DBATools, but Python may also be an option. In case you didn’t know, Python does integrate with SQL Server via a specific driver.

An important part of the Dev DBA’s work is testing SQL code. You’re going to be doing more of that at this level in your career. You will need to verify query results and probably automate repeated testing of code as well so that you can test not only results but performance. Maybe the query returned the results you expected but it took too long to do it. This is where learning how to read execution plans will come in.  Execution plan operators will give you clues about what is happening with your T-SQL and those clues can help you with re-writes or with indexing.

Aaah yes. Indexes.  You’ll need to begin understanding indexes as well.  You’ll need to know what they are, the different types of indexes and when to use each type. There are clustered indexes. Indexes made as a result of creating a primary key. These may be clustered or non-clustered primary keys. There are non-clustered indexes. There are filtered indexes. There are non-clustered columnstore indexes. There are clustered columnstore indexes.  As a corollary, you’ll need to look into the concept of SQL Server statistics as well.

Next Steps to Take

  1. If you’ve read the other parts of this series, then you know I’m going to tell you to copy the skills list above to a Word doc and place an “X” next to the things you need to work on.
  2. Use those “X” marks to build a training plan. Put the training plan somewhere that you will see every day. One thing that should be on your training plan at this stage is learning more T-SQL.
  3. Work the plan. I have a post that will help you find resources for your learning plan.
  4. Contact me here for questions about this post or the skills listed in it. You can also reach out to me via Twitter using the handle @leemarkum.

How Do I Measure My DBA Skills Part 5

We’ve been on a journey recently in this series as we discuss measuring your DBA skills. Previous posts have been intriguing to you. You like where this is going and yet, your skills are different from what we’ve been discussing in this initial part of the series. Maybe you are a Developer who works with databases and you find SQL Server very interesting. You build some tables and write some queries as part of your work and you really like doing it. You like trying to figure out how to make your initial draft query for your project run faster. You have conversations about this with other Developers or maybe even a DBA or two at your company. What you hear resonates with you and deepens the interest in SQL Server. You wonder, “Is there a place for me in the SQL Server world? What would I do if I did a career pivot to work with SQL Server almost exclusively?” Enter the Development Database Administrator.

 

What Does a Development DBA Do?

Before we jump into a discussion of skills, we need to try to answer the question, “What does a Development DBA do?” After all, if you think you’re interested in this, what are you signing up for?

A Development DBA will often be responsible for the management of the non-prod SQL Servers, SQL development work for applications and processes, task automation and perhaps source control and the change deployment process. Non-prod SQL environments need care and maintenance. The Dev DBA role can assume this responsibility. This isn’t because the Dev DBA is a “Junior” role, but because this non-prod environment plays the critical role of testing grounds for development work. This non-prod environment will be where the Dev DBA works and experiments with new SQL Server development such as stored procedures, SSIS work SQL Agent job development etc., often in tandem with Developers from other areas of the company, to produce new products and applications. The Dev DBA spends most of their time in non-prod so there is familiarity and as a result it makes sense to have the Dev DBA manage the environment.

Related to the experimental nature of the work, and the need to promote that work to production, the Dev DBA will often participate in or wholly manage source control and change processes such as source control software and the design of the process of promoting code through the various developmental levels of the environment. Once deployments are tested, scripts are then often handed off to Production DBAs for deployment of new code in production, but even this could be automated by the Dev DBA with control over when the deployment happens being wielded by the Production DBA.

At higher levels, the Dev DBA role may begin to overlap some with the Production DBA role and skillset. Let’s dive into the skills of a Development DBA.

The Development DBA Role

DEV DBA – 0 to 2 Years Experience

  1. Design tables utilizing basic normalization techniques.
  2. Basic T-SQL development. SELECT, INSERT, UPDATE, DELETE. Stored procedure development with guidance from more experienced DBAs.
  3. Manages most administrative aspects of non-prod environments with assistance from more experienced DBAs, including the application of patches to pre-production.
  4. May participate in pre-prod testing of SQL code prior to production upgrades or migrations.
  5. May have some exposure to SSIS, SSAS or SSRS.
  6. Demonstrates understanding of basic backup/restore processes.
  7. Demonstrates values driven behaviors such as humility, integrity, teamwork and is teachable.

T-SQL Skills

Now that you’ve looked over the list, let’s talk about it. T-SQL skills and overall development skills are at the heart of this role. The Dev DBA will spending a lot of time manipulating data and the first and foundational way that will happen will be with the core skills of SELECT, INSERT, UPDATE and DELETE. Introductory and basic T-SQL skills will be learned, practiced and built upon as you spend time in this role. A corollary to that will be learning all about the relational database table. At this phase of the career the Dev DBA will be learning what a good relational table should look like. Even if you can’t quote them, the principles of first, second and third normal form will become familiar as you design more and more tables.

Stored procedure development will be learned in this part of your career. You’ll be exposed to what a stored procedure is, why it should be used, advantages to it, the basic form of a stored procedure and so on. Of course, you’ll begin to write some of your own stored procedures as well. After all, there’s no point in learning about them, but not actually writing them!

In this phase of your career you maybe be asked to make some logins and users as part of your development work. You’ll need to learn what those database objects are, how they are different and how they work together to provide authentication and permissions. You will, I hope, be doing this with the help of other DBAs who have walked this path before you so that you’re not scratching and clawing to figure it out on your own. My point is, other people will be guiding your work at this phase.

You will be testing code, a lot. After all, in this role you are creating things in non-prod that have to be reliable. You will be making sure that result sets make sense.

Depending upon the technologies in use at your company, you may be exposed to things beyond the T-SQL and basic security that we’ve already mentioned. SQL Server Integration Services (SSIS) may be  important at your work, and as a result, you will need to have some basic understanding of it. Maybe your employer has invested heavily in SQL Server Reporting Services (SSRS). In which case, you will be exposed to report development and deployment.

What Happens When I Lose Some Data?!

At this point in your career, you probably aren’t taking backups or restoring backups. But you should begin learning backup and restore concepts. You’re going to need that understanding as your career grows. Trust me!

You are going to make a mistake in a non-prod environment and wipe out a small, or large, amount of data. Please accept that this is going to happen. You’re going to make a mistake. You’re going to freak out and think, “I’m going to be fired!” I hope that you won’t be fired over it, especially since you’re not working in production. If you introduce me to a person who says that they’ve never messed up or lost any data, I will have met either a liar or a person who hasn’t worked with data nearly long enough!

When this happens, and it will happen, relax, and ask for help. If the other people on the DBA team have done their first and most important job, you’ll be able to get the data back. If they haven’t done their first and most important job, then maybe they are the ones who should be worried!

Do I Really Need People Skills?

Just like the other posts in the series, the last thing on the list is about people skills. Yes, you’re going to need them.  You have to interact with other people on your team, people on other teams and maybe even external customers. You need to be teachable, develop good listening skills and be willing to help other people. All of these things will help you lean your craft. You need the other people around you because they know things and have experience that you need. Remember that example above where you’ve deleted data you need to get back? If you don’t work on your people skills and have good relationships with co-workers, then that conversation where you have to ask for help is going to be reeeaaallllly awkward!

Particularly at this level of your career, other people can help you avoid pitfalls in your code as well as help you get your next promotion. So, be humble and willing to ask questions. When someone answers your question, don’t argue. If you don’t like the answer or you think the person is wrong, ask more questions to get clarification. Say something like, “I’m not sure I follow. Can you try explaining that another way?” Or you might say, “I hear what you’re saying. Would there be anything wrong with doing it like ‘X’? Is there a reason that wouldn’t work?”

Next Steps To Take

  1. Copy/paste the skills list into a Word doc and place an “X” next to anything you need to work on.
  2. Pick two or three things to focus on and build yourself a training plan. Put that training plan somewhere that you will see it every day.
  3. Ask a person on your team how to do a task that is important in your environment, but that you don’t know anything about yet.
  4. Talk to me. Contact me here if you would like specific help with anything in this post or other things related to SQL Server. If there is an issue with the form, you can reach me at leem@leemarkum.com. I will be glad to help.

How Do I Measure My DBA Skills Part 4

Dear reader, we’ve been on a bit of a journey recently so that you can discover what skills are needed at various levels or phases of your career.  The first three phases have been covered in previous blog posts and you have now come to the Senior level for the Production DBA. So, how do you measure the skills a Senior Production DBA should have?

Senior Production DBA – 7+ years of experience

  1. Most competencies from the previous levels.
  2. Advanced analysis of SQL Server issues using native tools such as Extended Events, Perfmon, Query Store and 3rd party monitoring tools.
  3. Makes decisions regarding SQL Server architecture, hardware, virtualization and storage, often in tandem with an infrastructure team.
  4. Designs high availability and DR solutions and may provide guidance to other team members during implementation.
  5. Plans SQL Server migrations.
  6. Leads knowledge sharing in four or more areas.
  7. May possess some competencies from DEV DBA levels up to level 2 or 3.
  8. Regularly demonstrates good self-awareness, self-management, social awareness and relationship management skills (emotional intelligence)

You will notice that in previous lists of skills, I have listed skill 1 as “All competencies from the previous level.” However, I have not done that in this case, why? There are at least two reasons that I will detail.

Varying Experiences

You will notice that in previous posts I started listing skills and saying that the person “may” have a certain skill. Maybe you were asked to do a small project that you decided to use SSIS to complete, and SSIS was a new skill at that point. Afterward, you never really needed to use that again or it was used very infrequently. As a result, you have a little exposure but you’re not particularly skilled at it. Consequently, at years 7 and beyond where you are either a Senior DBA or you’re approaching that phase of your career, you may have some skills with SSIS, but maybe you don’t because your job roles never required that. In some roles, you maybe needed to do a fair amount of table design and stored procedure development. This might have been due to the fact that you were the only DBA so you had to do at least some development work. At other employers, those skills weren’t needed. Based on your employer’s needs, you may have used SSRS quite heavily up to this point in your career, but maybe not.

SQL Server Specialization

And then there is the matter of specialization.

The various parts of SQL Server are careers unto themselves. The database engine, SSIS, SSRS, SSAS are all so deep that a person could specialize in any of those areas. Even within some of those areas there are places of focus and skill that can be developed.

For a Production DBA, you will primarily be specializing in the database engine in some way. That could mean you’re really good with HA and DR technologies such as AlwaysOn Failover Clusters or Availability Groups. Maybe you love digging in to the various kinds of replication and leveraging those for business needs. Maybe you love performance tuning and you have found that the Query Store and Extended Events are things you love to use for that. You’re knowledge and skill with those things may be fairly deep as a result. Perhaps the SQL Server environments you have worked in have been heavily virtualized and you took a deep interest in that.

As a result,  if you have 7 + years as a DBA, you may have touched on a wide variety of things, but fell in love with a few select things that you’re now really good at.  This also means, there are things, you’re not that great at.  That’s ok. No one can do everything.

Designing SQL Server Solutions

So, let’s move on to discuss some of the other things in the list. At this point in your career, you’re dong things at a more advanced level, obviously, since this is a Senior phase to your career.

You are most likely collaborating frequently with other Infrastructure people like SysAdmins/VMWare specialists and storage folks at your company in order to design SQL Server solutions. Virtualization for SQL Server is another specialty I previously mentioned and you might be getting into some minutiae about that by this point.

You are the person who is analyzing HA/DR needs for when a new application is being brought on board from a vendor or from your own company’s Dev team. Decisions being made about how to ensure the application always has a back end connection, even when that river next to your building overflows its banks, are things you’re heavily involved in. You might be the person implementing the solution, or you may be simply assisting other people in your company with the implementation.

Knowledge Sharing

Knowledge sharing is definitely prevalent at this point. You regularly share what you know and what you’re learning.  That knowledge should be in several different areas at the Senior level and not just one or two. Your knowledge and skills may also include things of a more Development DBA nature. As previously discussed, this is heavily dependent on employer needs and your own interests.

Native SQL Server Tools

For a Senior Production DBA, native tools like Extended Events, Query Store and Perfmon counters are likely skills and knowledge that you’re comfortable with. You can use them easily in a wide variety of situations, but especially to analyze SQL Server issues that perhaps can’t be solved in other ways or can’t be solved as easily using other methods. Some places want their DBAs to be well-versed in native tools. Some are concerned so much with that because they have invested heavily in monitoring software of some kind.

SQL Server Monitoring Software

You should be comfortable and familiar with using monitoring tools at this point in your career. Platforms like SolarWinds have full environment monitoring like in Server and Application Monitor, that also include templates for monitoring SQL Server. SolarWinds also has Database Performance Analyzer. Sentry One has a full suite of monitoring tools as do Idera,  RedGate, and Quest. There are other options I’m sure.  These are just the one I know about right now that might be of use to you and that you are likely to encounter at your job.

Being able to use these types of platforms to find things like deadlocks, issues indicated by changes in Perfmon counters, and to do query analysis is going to be essential at this point in your career. Software like Brent Ozar’s First Responder Kit may also be something that you’re familiar with and can use easily to diagnose and resolve issues in your SQL Server environment.

Next Steps to Take

  1. Copy/paste the skills list into a Word doc and place an “X” next to any skill that you need to develop.
  2. Create a training plan to learn those skills.
  3. Buy a book on emotional intelligence and read it this month.
  4. Stay tuned because in the next part of the series we will introduce the skills for a Development DBA.
  5. If you would like help with anything in this post or other things related to SQL Server, reach out to me here and I’ll be happy to talk to you.