SQL Server DBA On-Boarding Checklist

By: Svetlana Golovko   |   Comments (4)   |   Related: More > Professional Development Management

Problem

Database Administrator (DBA) on-boarding is not always as efficient as it could be. Whether this is for new full time employees or contractors. We often have to wait for system access, computers to be setup, the right software to be installed, etc. How can we be sure that the new DBAs are productive a soon as possible? How can we use highly qualified contractors in the most effective way from day one?

Solution

In this tip we will provide a checklist for DBA on-boarding. This checklist has steps to make sure that the DBA is efficient from day one and has access to the necessary documentation. We will also outline a sample schedule for the knowledge transfer to make sure that the DBA can bring value to the company as soon as possible. And we will also provide a list of documentation that the DBA needs to have access to from the first days in the company.

Before the Start Date

Let the DBA know:

• What time to arrive.
• Exact address of the office. Some companies have several offices that could be in the different parts of the city.
• Which floor to arrive and what is the office/room number.
• What is the process for the building/office access (arrive at reception or directly to the office floor, etc.).
• Who to contact first (ask at the reception for a Manager, Project Manager, Human Resources (HR) representative etc.) and who will be giving the office tour.
• Who the DBA will be reporting to (direct reports).

Make sure the following is completed before the start date:

• Domain account is created.
• General mailbox is created.
• Access to documentation is granted.
• Office phone is setup.
• Make sure that access card is ready and notify reception about the new person arriving.
• Notify a mentor/buddy DBA about the new DBA start date (to make sure that the mentor/buddy has booked time for the mentoring/knowledge transfer/training).

The First Day

Make sure that on the first day the DBA has access at a minimum to the computer, e-mail, phone and documentation.

• Provide a tour around the office. Show where office supplies are stored (or stock the desk with office supplies in advance).
• Introduce the DBA to the Team members and key users.
• Present IT and Company organizational structure.
• Outline Department's/Company's goals.
• Provide the DBA's new office phone number and manual/documentation on how to use it (voice mail, phone integrated systems, etc.).
• Send welcome e-mail to the Team.
• Assign a person who will help with orientation (mentor or buddy).
• Provide information about position's duties and responsibilities. Make clear what the expectations are for this role. Provide information about after hours and on-call support if this has not been discussed during an interview.
• Discuss Service Level Agreements (SLAs).
• Schedule welcome lunch.
• Setup meetings with the new DBA (1-on-1) or include him/her to the existing meetings (team meetings, projects meetings, end-of-day meetings, etc.).
• Organize/schedule training for the software/equipment used in company/IT Department if required.

The DBA will most likely spend his/her first day on:

• Human Resources orientation and paperwork.
• IT general orientation.
• Getting familiar with DBA documentation.

If there is no additional training required and you want the DBA to start doing work from day one you will also need:

• Give access to shared mailboxes.
• Include the DBA in the distribution groups.
• Provide corporate cell phone for on-call and alerts.
• Make sure that the DBA gets alerts.
• Add the DBA to the appropriate Domain security groups that have access to the SQL Servers and/or databases. For example:
  • Add the DBA to the Domain group that is member of the "Local Administrator" group on SQL Servers (if applicable). This Domain group could be granted sysadmin server role on SQL Servers as well. This is usually for full time DBAs that will manage all SQL Servers in the company.
  • If you hire a junior DBA or a project DBA or if you have different DBAs responsible for the different SQL Servers or databases you may need to grant more granular access (for example, db_owner on specific databases or sysadmin on specific SQL Servers, permissions to backup and restore the databases, permissions to specific environments only, etc.).

Access to the Tools

This includes membership to the Domain groups that have access to the tools. The tools could be installed on the DBA's computer or included as a part of the DBA's computer image or accessed through the URL.

• A password management tool installation and access.
• The latest version of SQL Server Management Studio and other versions if required/used.
• Tools and drivers for other database systems administration if required (for example, Oracle SQL Developer, Oracle Database client, etc.).
• Visual Studio and/or other development tools used by the DBAs.
• Source control access. For example, Team Explorer for Visual Studio installation and Team Foundation Server access.
• Performance Monitoring and other Monitoring tools (for example, third party tools, Windows Performance Monitor, etc.). 
• Database modeling tools (for example, Microsoft Visio).
• Microsoft Assessment and Planning (MAP) tool and other Asset Management tools (if applicable).
• FTP or other file transfer tools access (to send backups, files to vendors if required).
• VSphere (or other virtualization management tool) access for the virtual SQL Servers with specific access level (depending on your company's practices).
• Incident Management tool access (if applicable).
• Change Management tool access (if applicable).
• Auditing and security tools (if third party tools are used).
• Capacity planning tools (if applicable).
• Remote connectivity tools/access (VPN, Citrix etc.).
• Some type of database comparison tool.

Optional tools:

• Notepad++.
• Project Management tools (for example, Microsoft Project).
• See the list of other DBA tools here.

Other users (non-DBA) tools:

• Timesheet tools (if applicable).
• Performance evaluation tools (if applicable).
• Messaging and/or collaboration tools.

Other Access for DBA

• Dedicated Management Workstation or Server with pre-installed tools (if applicable).
• SharePoint or other web sites/portals access (Intranet, IT Web Site, DBA Web Site, Dashboards, etc.).
• External SQL Servers access (SQL Servers that are not in domain, are on different network segments or at a different geographic location).
• Installation Media and patches location access.
• Access to the folders (or source control) with DBA scripts (T-SQL, CMD, PowerShell, etc.).
• Administrative access on SQL Server Reporting Services SSRS. Read this tip to learn about SSRS permissions.
• Administrative access on Master Data Services (MDS). Read this tip to find out how to assign MDS administrator permissions.
• Administrative access on SQL Server Analysis Services (SSAS). Here is a tip about assigning administrative permissions to SSAS.
• Central Management Server access.

Access to the Following Documentation

• Company policies.
• HR on-boarding documentation.
• IT Security and Compliance Documentation (DBA may need to sign them first in order to get access to any tools).
• Approvers list (IT and Business).
• Important contacts list (key users, vendors, contractors etc.).
• Service Level Agreements (SLAs).
• Licensing information. 
• DBA Knowledge Base - common issues and solutions.
• Company DBA Best Practices. Read tips about the best practices here.
• Databases diagrams.
• DBA checklists, standards, policies and processes. For example:
  • Database Servers patching, cumulative updates and upgrade processes and standards (including separate documentation for patching Availability Groups).
  • Maintenance windows and outage procedures.
  • SQL Server installation standards (there could be several standards for different tiers, locations, editions, etc.).
  • Disaster Recovery (DR) and High Availability (HA) requirements and standards.
  • Backup and recovery procedures.
  • Performance troubleshooting checklist.
  • Configuration standards  (jobs, tempDB, recovery modes, hardware, trace flags, network configuration, security, memory, etc.).
  • Database (T-SQL) coding standards and naming conventions.
• T-SQL code deployment process.
• Database security practices (including service accounts setup standards, separation of duties, etc.).
• Access request forms.
• New Database (or Database Server) request form.
• Change request form.
• Report request form.
• Automations documentation.
• Templates.
• Audit requirements and scripts documentation.
• Roles and responsibilities of each team member, separation of duties if applicable.
• SSRS, SSAS and MDS documentation and standards.

First Tasks

Ideally we want to make sure that the DBA can perform some tasks the first or second day. Giving some simple cleanup tasks to the DBA will help him/her to get familiar with the environment faster. For example:

• Review alerts and operators.
• Review job owners.
• Review databases owners.
• Setup and validate connections to all SQL Servers.
• Run Policy Based Management checks.
• Perform SQL Server and databases Inventory review.
• Perform security review.
• Work on or review outstanding tickets.

Knowledge Transfer

Here is an example of the knowledge transfer schedule. You may spend a couple of hours a day or several full days if you want to speed up the knowledge transfer (if you can afford spending full day on it):

• Day 1:
  • As we mentioned above this will be mostly HR and other orientations, training, etc.
• Day 2:
  • General introduction to environment
  • SQL Servers - names, versions, how to access, etc.
  • Database inventory - what applications use the databases; how to use the inventory, when to update, etc.
  • Documentation - where to find, how often to update, etc.
  • Ticketing system training
• Day 3:
  • Backups - scripts, jobs, documentation, backups testing schedule and procedures, SLAs etc.
  • Ola Hallengren scripts or other custom scripts intro and implementation on a Sandbox
  • Applications specific jobs and alerts. Other jobs and alerts
• Day 4:
  • Change Management procedures and training
  • Due Dates, meetings, repeatable tasks (databases archival, performance and security reviews, etc.)
  • Outage windows; outage and patching procedures; on-call procedures
  • Security; separation of duties (application support/developers/DBAs/end users); security reviews and audit processes
• Day 5:
  • Procedures for the databases changes and code promotion from one environment to another
  • Test/Development/QA databases refresh scripts/documentation; applications specific post-refresh scripts
  • Databases migrations/upgrades procedures - general process (including planning, setting up test environment); approvals from business for planned dates; backups changes; monitoring changes; firewall changes; documentation/inventory updates after migrations/upgrades
• Day 6:
  • Policy Based Management overview and follow-up steps
  • Monitoring tools and scripts review
  • Performance monitoring practices
  • Common issues walk through
• Day 7:
  • Questions and answers
  • Vendors high level introduction
  • Other training (tools, third party monitoring processes, etc.)
• Day 8 and going forward:
  • Day-to-day tasks, tickets
  • Daily/weekly/monthly reviews (end-of-day meetings, one-on-one, etc.)

It may take some time, up to 3-4 weeks (or even more) to bring a new DBA up to speed. But if we think about on-boarding as a long-term investment and provide all required tools, access and training in the shortest time then a company can see benefits from hiring the new DBA resource in a very short time.

If you spend a week on knowledge transfer, in return you will have a productive DBA much earlier. This will definitely depend on the new DBAs experience, ability to adapt, environment' complexity, etc., but you will have a good start in any case. And moreover the new DBA will appreciate this too - he/she will feel more welcomed and needed.

Next Steps

• Find the list of free tools for managing, comparing, administering and developing databases here.
• Here is another SQL Server DBA's toolkit list.
• Read this article about employee on-boarding importance.
• Another great on-boarding checklist could be found here.
• Read more tips about SQL Server Professional Development here.

About the author

Svetlana Golovko is a DBA with 13 years of the IT experience (including SQL Server and Oracle) with main focus on performance.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips