Primary DBA Responsibilities

http://blogs.technet.com/b/fort_sql/archive/2010/10/01/primary-dba-responsibilities.aspx

SQL Server is so well-behaved it's often installed by 3rd party applications in an organization or department
without a professional Database administrator (DBA). When such implementations need attention (e.g.
backups), system administrators often get involved as acting-DBAs, and some of them discover they enjoy it
and start spending more and more time with SQL Server. Or someone starts moving from a coding job to a
junior DBA position. These are a couple of examples of how people can become DBA's without formal
training, and some of these folks occasionally start to wonder, "What are the main priorities I should pay
attention to as a DBA?" Even when these guys and gals get training, it may not point out exactly what a
DBA's primary duties should be, so here's a list I've compiled over the years as the top areas (categories) of
DBA responsibilities, followed by a breakdown of some of the major tasks in each area. Obviously, DBA
tasks will vary from day-to-day and from organization-to-organization, depending on how large the databases
are, how many users they have, how many other people are involved in the organization's data management,
and what their skills are, but all of the tasks listed below should be covered by someone. I'll also mention that
this arrangement of categories and tasks has some matrix characteristics, for example, documentation is a task
in multiple areas, but it's also a major category because there are documentation requirements that are outside
of the other categories. If you think of something I've left out, please let me know.

The Primary Areas of Responsibility (AOR) of Database Administrators

1. Configuration
2. Data Management

3. Documentation

4. Education

5. Maintenance

6. Performance

7. Planning

8. Reporting

9. Security

The Primary DBA Tasks by Area of Responsibility

Configuration

 Adding features
 Installation

 Patching

 Upgrading
  Reconfigurations

Data Management

 Data extractions, transformations, and loading (ETL)

Documentation

 Centralized storage of Data Element Dictionaries (DED) and Data Models

 Configuration changes

 Current configurations

 DBA activities

 Future plans

 Server activities

 Standards

o Server configurations

o Maintenance

o Security

o Operations

Education

 Assisting and teaching

o Data analysts

o Coders/Programmers (including pre-production code reviews)

o Data modelers

o Managers

o Others

 Increasing your own knowledge

Maintenance

 Alerts (e.g., job failures, capacity shortages, etc.)

 Backups (this is the single most important DBA task)

 Clean up of out-of-date files and records

 Database integrity checks

 Index defragmentation
  Reviewing error logs

 Sizing files

 Trial recoveries of backups (the 2nd most important DBA task)

 Updating stats

Performance

 Auditing
 Baselining

 Enhancing / Optimizing / Tuning (especially index tuning and custom statistics)

 Monitoring

 Troubleshooting

Planning

 Configuration changes
 Future workloads

 Future system resources

Reporting

 Informing I.T. management of system conditions and future needs

Security

 Auditing
 Configuring

 Documenting
http://thomaslarock.com/2010/09/a-better-dba-job-description-for-everyone/

09 Sep 2010 A Better DBA Job Description For Everyone

Posted at 08:26h in Featured, MSSQL, Professional Development, SQL MVP, SQLServerPedia Wiki by Thomas LaRock 49
Comments

Share




Here is a typical job description that you can find online just about anywhere. It lists almost everything
possible and imaginable. And it, well…I’ll just let you read it all for yourself and make up your own mind.
Enjoy.

Position Summary:

This is a MS SQL Server DBA role largely responsible for providing operational database services to
the organization. Some of the primary responsibilities of this role would include owning, tracking and
resolving database related incidents and requests, fulfilling requests and resolving incidents within SLAs,
reviewing service related reports (e.g: database backups, maintenance, monitoring) on a daily basis to ensure
service related issues are identified and resolved within established SLAs, responding to database related
alerts and escalations and working with database engineering to come up with strategic solutions to recurring
problems.

This MS SQL Server DBA role requires a service oriented mentality, high sense of ownership of the problems
and requests assigned, focus on managing and resolving issues in alignment with the SLAs, establishing and
maintaining communication with technology customers to keep them updated with status of their requests,
initiating and performing changes on production systems and proactively escalating any issues that cannot be
resolved within the established timeframes.

Position Requirements:

We are looking for a person who:

 Has 8+ years of experience in database development and support in MS SQL Server environments.
 Strong experience in Database Administration in SQL Server ( 2005 and 2008 )

 Experience in troubleshooting and resolving database integrity issues, performance issues, blocking and
deadlocking issues, replication issues, log shipping issues, connectivity issues, security issues etc.

 Experience in Performance Tuning, Query Optimization, using Performance Monitor, SQL Profiler and other
related monitoring and troubleshooting tools.

 Ability to detect and troubleshoot SQL Server related CPU,memory,I/O, disk space and other resource
contention.

 Strong knowledge of backups, restores, recovery models, database shrink operations, DBCC commands,
Clustering, Database mirroring, Replication.

 Expert experience in implementing operational automation.

 Strong knowledge of how indexes, index management, integrity checks, configuration, patching. How statistics
work, how indexes are stored, how they can be created and managed effectively.

 Knowledge of SQL Server tools ( Profiler, DTA, SSMS, SAC, SSCM, PerfMon, DMVs, system sprocs)

 SQL Development – ability to write and troubleshoot SQL Code and design ( stored procs, functions, tables,
views, triggers, indexes, constraints )

 Solid acquaintance with windows server, security delegation, SPNs, storage components.

 Documentation skills for processes and procedures ( creating KBs, runbooks, topology etc )

 SQL Database Operational support to tech users

Preferred candidates would also meet the following criteria:

 Solid acquaintance with windows server, security delegation, SPNs, storage components.
 Documentation skills for processes and procedures ( creating KBs, runbooks, topology etc )

 Knowledge of 3rd party DBA tools and applications ( e.g redgate, idera, SCOM, Erwin )

 MCDBA / MCT certification

  Knowledge in a scripting language like Powershell, VBScript, WSH

OK, now let’s break this thing down. My comments are inline to the original:

Position Summary:

This is a MS SQL Server DBA role largely responsible for providing operational database services to
the organization. Some of the primary responsibilities of this role would include owning, tracking and
resolving database related incidents and requests, fulfilling requests and resolving incidents within SLAs,
reviewing service related reports (e.g: database backups, maintenance, monitoring) on a daily basis to ensure
service related issues are identified and resolved within established SLAs, responding to database related
alerts and escalations and working with database engineering to come up with strategic solutions to recurring
problems. Nothing wrong with this paragraph, sounds good so far.

This MS SQL Server DBA role requires a service oriented mentality, high sense of ownership of the problems
and requests assigned, focus on managing and resolving issues in alignment with the SLAs, establishing and
maintaining communication with technology customers to keep them updated with status of their requests,
initiating and performing changes on production systems and proactively escalating any issues that cannot be
resolved within the established timeframes. Again, this sounds great, I am ready to hit the apply button
myself.

Position Requirements: OK, that means everything here is required.

We are looking for a person who:

 Has 8+ years of experience in database development and support in MS SQL Server environments. OK, first
warning shot. They say they want a DBA, but here they mention database development. That’s OK, we’ll keep
reading, but it warrants mentioning.
 Strong experience in Database Administration in SQL Server ( 2005 and 2008 ) Um, I hope they are not
expecting 8+ years of experience with either of those versions, but we’ll press on.

 Experience in troubleshooting and resolving database integrity issues, performance issues, blocking and
deadlocking issues, replication issues, log shipping issues, connectivity issues, security issues etc. OK, seems
fine, but I am curious as to why they are using both log shipping and replication. Must be a really big shop or
they have very specific needs. But this is all standard troubleshooting skills.

 Experience in Performance Tuning, Query Optimization, using Performance Monitor, SQL Profiler and other
related monitoring and troubleshooting tools. Fair enough, I wonder what tools they may have purchased from
a third party.

 Ability to detect and troubleshoot SQL Server related CPU,memory,I/O, disk space and other resource
contention. Ability to detect? What am I, a basset hound? What if I didn’t detect the fact that a developer fills
up a disk with a long running transaction? Is that going to reflect poorly on me because I couldn’t detect that
the user was a moron, or that they were about to make a mistake?

 Strong knowledge of backups, restores, recovery models, database shrink operations, DBCC commands,
Clustering, Database mirroring, Replication. What, no mention of log shipping here? But they tossed in
clustering, so I guess they are doing all three. Must be an even bigger shop than I thought. Or more paranoid
than I can imagine. How many people have strong knowledge of all three, anyway?
  Expert experience in implementing operational automation. This seems rather vague, but nothing to really
worry about yet, I suppose. But I am wondering what it means to have ‘expert experience’. How would I show
that I have expert experience?

 Strong knowledge of how indexes, index management, integrity checks, configuration, patching. How statistics
work, how indexes are stored, how they can be created and managed effectively. Why would they mention
patching here? It seems rather out of place, almost as if they are just tossing around buzzwords. Now I am
wondering if they are really doing clustering, log shipping, and replication or if they just want to weed out
people from applying. The rest seems fine, but mentioning integrity checks is redundant since they already said
DBCC earlier. So, yeah, I think they are cramming in words here.

 Knowledge of SQL Server tools ( Profiler, DTA, SSMS, SAC, SSCM, PerfMon, DMVs, system sprocs) Well, yeah.
Seems silly to mention these things here, unless you wanted to cram more buzzwords and acronyms into the
description.

 SQL Development – ability to write and troubleshoot SQL Code and design ( stored procs, functions, tables,
views, triggers, indexes, constraints ) OK, just out of curiosity, when would I be doing this? At night and on
weekends? The first two paragraphs talked about a slightly different role, more administrative, but now it
sounds like they also want a developer. That’s two jobs, really. And the bullet points up until now only talked
about experience, this one talks about actions, and those actions are not in line with what was mentioned
above. I am going to consider this a serious red flag.

 Solid acquaintance with windows server, security delegation, SPNs, storage components. This seems quite
vague. Will I be building the servers as well? Handling Active Directory duties too? After the red flag above I
will consider this another red flag, because this could be a casual mention of a third or fourth role. That’s a lot
of work to be done in any one day or week. And what is a ‘solid acquaintance’ anyway? Is that like my old
friend from High School?

 Documentation skills for processes and procedures ( creating KBs, runbooks, topology etc ). The hell? When is
this supposed to happen? I can’t spend all day writing, racking servers, configuring Active Directory,
troubleshooting performance problems, answering the phone, building clusters, fixing replication after it
breaks, and writing code. This job description went downhill in a hurry. I’m not sure I would even bother
applying to this ad, I really don’t think these people know what they are asking for. Consider this a fifth job, at
least, and another red flag.

 SQL Database Operational support to tech users Of course. Now, I’m not sure what these users are doing all
day, since I am doing everything else apparently. I’ll just assume this means the end users who will complain
about performance and then complain about my performance because I can’t do five jobs at once. I mean, not
even if they paid me for five jobs could I do all five well enough to please anyone.

Preferred candidates would also meet the following criteria:

 Solid acquaintance with windows server, security delegation, SPNs, storage components. Wasn’t this a
requirement?
 Documentation skills for processes and procedures ( creating KBs, runbooks, topology etc ) The hell? Wasn’t
this also a requirement? Seems strange to list it here as well, either every applicant needs this skill or not.

 Knowledge of 3rd party DBA tools and applications ( e.g redgate, idera, SCOM, Erwin ) Interesting. It would
appear they use a variety of tools, and they consider SCOM to be a DBA tool. I wonder how they are using it as
such. Wait a minute, I am now wondering if I will also be the SCOM admin.
  MCDBA / MCT certification Well, MCDBA is for SQL 2000, but they want me to be focused on SQL 2005/8,
which would be MCITP. So, which version did they want me to be certified in? And does being an MCT really
qualify you to do everything that is listed above?

 Knowledge in a scripting language like Powershell, VBScript, WSH I will assume this is for the automation
requirement, but I can’t imagine that they would be using all three, or expect me to know all three well
enough.

So, there you go, that’s how I read a job ad before I decide to not apply. There are a possible five jobs listed
above and what would appear to be roughly 60 hours or more a week worth of work. Unless the job starts at
about $400k a year, it is not even worth my time. So I will pass. I am also curious to know how many of you
would pass on this particular job as well. If you want to apply I will give you the link to the actual job. Feel
free to make yourself miserable.

So what would be a better job description for a DBA? Let’s assume that you needed everything that was listed
in the above description. If your goal is to entice as many SQL Server Experts to apply then how should you
present the same information? I am glad you asked. Here is what I would do:

Position Summary:

This is a MS SQL Server DBA role largely responsible for providing operational database services to
the organization. We are looking to fill a need to have a highly competent and highly motivated individual in
this role. This is a production DBA role, as such it will require a commitment on your part as well as ours.
Some of the primary responsibilities of this role would include owning, tracking and resolving database
related incidents and requests, fulfilling requests and resolving incidents within SLAs, reviewing service
related reports (e.g: database backups, maintenance, monitoring) on a daily basis to ensure service related
issues are identified and resolved within established SLAs, responding to database related alerts and
escalations and working with database engineering to come up with strategic solutions to recurring problems.

This MS SQL Server DBA role requires a service oriented mentality, high sense of ownership of the problems
and requests assigned, focus on managing and resolving issues in alignment with the SLAs, establishing and
maintaining communication with technology customers to keep them updated with status of their requests,
initiating and performing changes on production systems and proactively escalating any issues that cannot be
resolved within the established timeframes.

During your interview you will be asked to discuss a project or particular piece of technology that excites you.
We will ask you questions on that project or piece of technology in order to get a better understanding of the
depth of your knowledge.

This role requires good communication skills. If you have a blog then please pass along the URL so we can
review your work. If you do not actively blog that is fine, but you should be prepared to show us an example
of something you have written previously if we should happen to ask.

Position Requirements:

We are looking for a person that has:

 Experience with Database Administration for MSSQL Server.

 Experience in troubleshooting and resolving database problems.
  Experience in Performance Tuning and Optimization (PTO), using native monitoring and troubleshooting tools.

 Experience with backups, restores and recovery models.

 Knowledge of High Availability (HA) and Disaster Recovery (DR) options for MSSQL Server.

 Experience in implementing operational automation using scripts.

 Knowledge of indexes, index management, and statistics.

 Experience working with Windows server, including Active Directory and proper disk configurations.

 Good communication and documentation skills.

Preferred candidates would also meet the following criteria:

 Involvement with the MSSQL Server Community; membership in PASS, active in forums or newsgroups.
 Certification is a plus; MCTS, MCITP, MVP

 Previous experience in either a teaching or volunteer role.

Which One Would You Apply For?

Be honest. I can handle the truth. If you believe the first job description is better, that’s fine.

The reason I like my version (and I hope others would as well) is that it is not overloaded with buzzwords and
phrases. It also doesn’t list five different jobs explicitly. That means you are more likely to get one of those
elusive SQL Server Experts to actually be interested in applying. Lastly it stresses the importance of
communication. Every successful DBA I have met is always a good communicator to some degree.

Not everyone blogs, but most everyone uses email. Certification is a preference, as that shows you can
communicate some technical aptitude. And the teaching or volunteering is a way to display that you have an
idea as to what to expect in the DBA role. Every DBA I know needs to take time to explain things to others, or
to take on some extra work for little to no benefit (just like a volunteer). All of those traits help to define what
I would consider a SQL Server expert (or at least someone on their way to becoming an expert).

Now, I understand that the original job description is supposed to be the starting point for a conversation. You
will often hear people say “just apply anyway”, because we all know the job description is loaded with
buzzwords. So people will build a resume to match the description so that they can have a chance at having
the conversation. How, exactly, is this not the same thing that happens on Match.com when people fill out
their profiles? You put in information about yourself (which is embellished to a degree) and then you put in
information about the person you are looking for. And then you are shocked (SHOCKED!) that you don’t get
a match?

The same thing is happening with the standard hiring practice. That’s why we need better job descriptions. If
you want a SQL Server Expert to be interested in your open position then you need to change how you are
advertising for them.

Oh, one last thing. Look again at that original job description. They are looking for a top notch SQL Server
expert. Everyone else is as well. But how much do you think they are willing to pay for that expert? That’s the
other problem. Companies want the very best talent for the very lowest cost. And then they are shocked
(SHOCKED!) that they can’t find someone good enough.

This ain’t rocket surgery, it’s quite simple. Scale back on the job descriptions. Focus on people with good
technical skills (not great, but good), are trainable, have good communication skills, and a willingness to serve
others. You’ll be happier with the results.
03 Jun 2014 Upgrading to SQL Server 2014: A Dozen Things to Check
Posted at 17:18h in Featured, MSSQL, SQL MCM, SQL MVP, SQL Server Performance, SQLServerPedia Wiki by Thomas
LaRock 18 Comments

Share




Here we go again! It seems that it was only yesterday we were talking about all the things you want to look
out for when upgrading to SQL Server 2012. Now, just two years since SQL Server 2012 was released, we
have a shiny new version with SQL Server 2014. And that means, of course, people will be thinking about
upgrading to SQL Server 2014. So I’ve put together a list of items that you will want to have handy when
upgrading or migrating your databases from those dusty old versions to the brand new SQL Server 2014
engine.

I’ve witnessed many novice administrators make the common mistake of believing that the upgrade process
for a database server is as easy as pressing a few buttons. While you can certainly click “Next, Next, Finish”
and consider your task to be complete the truth is that the upgrade process is often considerably more
complex. A proper upgrade process involves detailed research, planning, and execution.

Failing to prepare a proper upgrade process for your database server is likely to result in your end users seeing
diminished performance after the upgrade is complete. Since your goal is to increase performance and
stability as a result of the upgrade you can understand that your users are likely to be upset if things were to
get worse!
Since it can be a daunting task to put together everything you need in a pre-upgrade checklist, I’ve compiled
this list of items that you need to include in any checklist you put together for migrating your database server
to SQL Server 2014. Including these items into your checklist is likely to help you avoid 98% of any potential
upgrade issues.

Please note that these steps are specific for an upgrade to the database schema and data. They do not include
anything regarding the upgrading or testing of an application that is going to be accessing the upgraded
database. You will want to remember to test your application and not just assume it will work perfectly even
after the database has been upgraded. I would also advise that you perform these steps in a non-production
environment first because I often find that common sense isn’t so common after all.

Also please note that this list is meant to serve as a guide for you to use when doing either an in-place upgrade
or when migrating from a previous version. However, I always recommend doing a migration whenever
possible as opposed to the in-place upgrades. Migrations (typically done by restoring a database backup from
the current instance) just make me feel more comfortable should I need to troubleshoot issues later. I like
knowing I started with a clean slate, but that’s just how I roll. You should do what works best for you.

1. Using the SQL 2014 Upgrade Advisor

The SQL Server 2014 Upgrade Advisor (UA) is just that: an advisor. Much like a consultant, it doesn’t fix
everything that is wrong, it merely advises you on what actions you should take when upgrading to SQL 2014.
The actions the UA recommends will come in two forms: those actions to be done prior to a migration, and
those actions to be completed post-migration. The UA is really good at finding what I call the “stub-your-big-
toe” things that need fixing prior to a migration. But it is not foolproof, it will not identify every last detail.
You will need to play the role of an actual DBA when migrating to a new version. Many of the items below
will help you to do just that.

2. Reviewing the “breaking changes” section in the Books Online

Did you know that Microsoft publishes a list of breaking changes for each version of SQL Server? Well, you
do now. You should review them to the point that they are familiar to you. You don’t have to memorize them
all, just be familiar with them so that if something odd happens you can think to yourself “…hey, is this odd
behavior listed in the breaking changes section of the Books Online (BOL)”? I would like to believe that the
UA will alert you to many of these breaking changes but the truth is the UA is not as dynamic as the BOL.
That means the BOL may have an entry or two that doesn’t make it into the UA checklist, and that is why you
should review this section.

Currently (as of this post in June of 2014) the link above lists the breaking changes for SQL Server 2014
simple as “no new issues”. I believe this is simply because this BOL entry has yet to be updated, so check
back on this page often and I am certain you will find content listed.

3. Reviewing the “behavioral changes” section in the Books Online

Similar to the breaking changes, the behavioral changes are changes that could still affect you in an adverse
way. They are definitely worth reviewing, and they are also things that the UA is likely to never report back to
you about because they aren’t things that *will* break, but merely things that *could* break. Also worth
noting is that the BOL appears to have two entries for behavioral changes, one for SQL Server features, and
one specific for the database engine. I’d advise you keep your eye on both going forward.
4. Executing DBCC CHECKDB WITH DATA_PURITY

One of your post-migration or upgrade tasks should be to run the following statement:

DBCC CHECKDB WITH DATA_PURITY;

This statement will check your data for values that are no longer valid for the column datatype. For databases
created prior to SQL 2005 (and you *know* they are still out there), this step is rather important to take. For
databases created in SQL 2005 and later, the DATA_PURITY check is supposed to be done automatically
with a regular CHECKDB.

But what about a database that was created in SQL 2000, migrated (poorly) to a SQL 2008 instance, and left
in the SQL 2000 (80) backward compatibility mode? What about that little feller? Do you want to assume that
the DATA_PURITY check has been getting done? Here’s a thought: just go run it yourself anyway. That way
you know it is getting done.

5. Executing DBCC UPDATEUSAGE command

While not as critical as the DATA_PURITY command noted previously, this one still has a place in any
migration or upgrade process:

DBCC UPDATEUSAGE(db_name);

This command will help fix any page count inaccuracies that are resulting in the sp_spaceused stored
procedure returning wrong results. For SQL Server 2012, this check was recommended for databases created
prior to SQL Server 2005. However, in SQL Server 2014, the BOL entry link lists this command as being
applicable for databases created in SQL Server 2008 and later. That seems odd to me, since this command is
valid for SQL Server 2005. I’m not certain why the SQL Server 2014 documentation states this as a command
for SQL Server 2008 and later. I’d recommend you run this for SQL Server 2005 databases being migrated to
SQL Server 2014 anyway. [If I can get an answer from someone at Microsoft regarding this documentation
issue I will update this post accordingly. In fact, I see this message for a handful of SQL Server 2014 entries,
and I think that it’s usage is slightly misleading.]

6. Updating statistics

This one is not to be skipped and is simply a MUST for any migration or upgrade checklist:

USE db_name;
GO
EXEC sp_updatestats;

This command will update the statistics for all the tables in your database. It issues the UPDATE
STATISTICS command, which warrants mentioning because you *may* want to use that command with the
FULLSCAN option. I’m the type of person that would rather be safe than sorry and therefore would end up
running something like this:

USE db_name;
GO
EXEC sp_MSforeachtable @command1='UPDATE STATISTICS ? WITH FULLSCAN';
Bottom line: don’t forget to update the statistics after an upgrade. Failure to do so could result in your queries
running slowly as you start your testing and may end up wasting your time while you try to troubleshoot the
possible bottlenecks. With SQL Server 2014 there is also a new Cardinality Estimator (CE), and I’ll talk more
about this later, but you are going to want to make certain your statistics are as accurate as possible before you
begin any testing. So, take care of the stats now, and you don’t have to worry about it later.

7. Refreshing your views using sp_refreshview

Believe it or not, every now and then someone will build a view that spans into another database on the same
instance. And, in what may be a complete surprise to many, sometimes these views will go across a linked
server as well. The point here is that your view may not be of data that is contained in just the database on that
single instance. In what could be the most dramatic twist of all, sometimes these views are created using a
SELECT * syntax.

I know, I know…what are the odds that you could have such code in your shop? But it happens. And when
you have bad code on top of views that go to other databases (or views of views of views of whatever else
some sadistic person built) you are going to want to use sp_refreshview to refresh those views.

So, if you are migrating a database in your environment to a new server then it would be a good idea to
refresh your views using sp_refreshview. Most of the time it won’t do anything for you, just like a burger
topped with veggie bacon. But there is that one chance where it will dramatically improve performance and
your customer will be happy as a result. Using sp_refreshview is a lot like like flossing: it doesn’t take much
effort, and the end result is usually worth it.

8. Taking backups

You’re a DBA. Backups should be in your DNA. You should have taken one prior to the start of any upgrade
or migration, and you had better take one right before you turn that database over to your end users. Also, you
should save any output from the items listed here, as it could prove helpful should something go awry later.
(bonus item – make sure your backups are good!)

9. Upgrading your hardware

Microsoft lists the minimum requirements for installing SQL Server 2014 on this page. However, those are the
*minimums* there. Chances are if your servers don’t already meet those requirements then you aren’t looking
to upgrade anytime soon anyway. But if you are upgrading, then it might be time to upgrade your hardware as
well. Heck, you may even consider going virtual (if you aren’t already), which will still require you to
examine your hardware requirements.

But here’s the real reason you will want to upgrade your hardware: new features. Let’s say that you are
thinking of upgrading to SQL Server 2014 in order to take advantage of In-Memory OLTP Hekaton. I can’t
find any MSDN article that states if there are minimum hardware requirements for Hekaton, but I did find this
blog post from the SQL Server team that suggests some guidelines. Considering there is a lot of shiny new
things in SQL Server 2014, chances are you’ll need to do some extra legwork here to scope out what hardware
you’ll need in order to leverage many of these new features.

10. Knowing the right upgrade path

For those folks running SQL Server 2000 instances (yes we KNOW you still exist) you are not able to
upgrade directly to SQL Server 2014 without first upgrading to an intermediary version. You have two options
to choose from when going from pre-SQL Server 2005 versions. The first option is to do an upgrade in place
to SQL Server 2005, SQL Server 2008, or SQL Server 2008 R2. The second option is to do a backup (or even
detach) your database and restore/attach to an instance running SQL Server 2005, SQL Server 2008, or SQL
Server 2008 R2. At that point you will be able to complete the upgrade to SQL 2014.

And like I said at the beginning, I prefer to do migrations rather than upgrades in place. It’s just a preference.
For something like a SQL Server 2000 database, I’d need to do a backup, restore it to an intermediary version
(like SQL Server 2008 R2), then do another backup and restore that to SQL Server 2014. At that point you
should run through this checklist before turning it over for testing.

11. Check your compatibility levels

If you have been going through SQL Server upgrades for the past ten years then you are likely to have noticed
that the compatibility level does not get set to the newest version after the migration is complete. You need to
manually set the compatibility level yourself. With SQL Server 2014 this becomes more important than in
previous versions due to the new Cardinality Estimator (CE).

I delivered a session at TechEd this year on the new CE, Jimmy May has a short summary blog post regarding
the new CE, and there’s also what I consider to be the “Gold Standard” on the new CE in a great whitepaper
from Joe Sack that details the good, the bad, and the ugly with the new CE.

The TL;DR version of the whitepaper is this: you’ll want to take advantage of the new CE except for the times
when you won’t. Part of this is knowing which compatibility level you are using. I’d recommend you update
every database on the SQL Server 2014 instance to compatibility mode 120 and test, test, test. [This assumes
that you have baselined performance for your critical queries prior to the migration, so that you can verify if
the new CE is working for or against you.]

12. Read the release notes

Because you’re a geek, that’s why. Take a few minutes and read the release notes. No, they aren’t as funny as
the release notes for apps on your phone, but they can be useful for you to review anyway. It’s good to have as
complete a picture as possible for the new version should something not work as expected, and there are
details in the release notes you may not find elsewhere.

Conclusion

Upgrades are a necessary part of any development lifecycle. The chances of having a successful upgrade
increases along with the amount of planning and preparation you invest in building a proper upgrade process.
If you are planning to upgrade to SQL 2014 you can use this post as a guide to help put together your
checklist.

If you haven’t started building up your SQL 2014 migration or upgrade checklist yet, now is the time, and get
these items included. They will save you pain, I promise.
DBA Responsibilities
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/96d6cc09-4ece-43cb-9bc5-c398ea454cbd/dba-
responsibilities?forum=sqlsetupandupgrade

Usuaully the SQL DBA functions are:

· Permissions needed by the SQL Server and SQL Server Agent startup
accounts.
· Starting and stopping SQL Server and SQL Server Agent services.
· Backing up and restoring databases.
· Running Database Consistency Checks (DBCC).
· Bulk copying data.
· Monitoring the SQL Server using Performance Monitor.
Permissions needed by the SQL Server and SQL Server Agent startup accounts
The SQL Server and SQL Server agent startup accounts can be members of the
Domain Users group. They do not necessarily have to be a member of the
server’s Local Administrator group. The account should have the following
rights:
· Logon as a service
· Act as part of the operating system
· Bypass traverse checking
· Increase quotas
· Lock pages in memory
· Logon as a batch job
· Replace a process level token
The account chosen should have full control over the following Registry
keys:
· HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLSERVER\MSSQLSERVER
· HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\MSSQLSERVER
· HKEY_LOCAL_MACHINE \Software\Microsoft\WindowsNT\CurrentVersion\Perflib
If it is a named instance, then the first two keys will be similar to the
following:
· HKEY_LOCAL_MACHINE \Software\Microsoft\Microsoft SQL Server\<Instance
name>
· HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\MSSQL$<Instance
name>
The account chosen should have full control over the following folder:
<SQL Server installation path>\mssql
If it is a named instance then the account should have full control over
the <SQL Server installation path>\mssql$<instance name> folder.
The account should also be added as a SQL Server login and added to the
sysadmin server role.
Starting and stopping SQL Server and SQL Server Agent services
To control a Windows service, the user must be a member of the Power Users
or Local Administrators group on the SQL Server.
Backing up and restoring databases
The user chosen to backup databases can be a member of the Domain Users
group. A SQL Server login should be defined for this account and that
account needs to be added to the db_backupoperators fixed database role.
This needs to be done in every
database that user will back up.
If the database backups will be done through Enterprise Manager, then the
user also needs to be given EXECUTE permission on
master.dbo.xp_availablemedia.
Additionally, the SQL Server startup account should have Read and Write
permissions to the backup file destination.
The user chosen to backup databases can also be a member of the Domain
Users group. A SQL Server login should be defined for this account and that
account needs to be added to the dbcreator fixed server role.
If the databases will be restored using Enterprise Manager, the user also
needs to be given EXECUTE permission on master.dbo.xp_availablemedia.
The SQL Server startup account should have Read and Write permissions to
the backup file.
Of course, the database owner can also perform backup and restore for their
database.
Running Database Consistency Checks (DBCC)
Only users that are members of the sysadmin server role or the database
owner can execute DBCC commands. Execution of DBCC commands cannot be
granted to non-sysadmin users.
Bulk copying data
The two methods for bulk copying data discussed in this document are BCP
and the BULK INSERT command.
In order to bulk copy data using the BCP command line utility, the user
running BCP should have Read & Execute permissions to bcp.exe. The user
should also have Read & Execute and Write permissions to the input and/or
output file. Of course a SQL
Server login should also be defined for this user. When importing data
using BCP into an existing table, BCP or SQL Server does not check if the
user running the BCP program is the owner of the table or the database
owner. Therefore any user can
use BCP to import data as long as they have access to the input file and is
has a login to the database. To guard against this, assign permissions to
the <sql server installation path>\ 80/90\Tools\Binn folder (where BCP.exe
is located) to only to
users who require access to the SQL Server tools.
Only members of the sysadmin and bulkadmin roles can execute the BULK
INSERT statement. If there will be users who need to run the BULK INSERT
command and do not need administrator level access to SQL Server, place the
user in the bulkadmin
server role. The user executing the command will need Read permission on
the input file. The user should either own the destination table or be the
database owner; else the BULK INSERT will fail.
Monitoring the SQL Server using Performance Monitor
To monitor SQL Server using Performance Monitor, the domain user should
have Read & Execute permission to <SQL Server installation path>\MSSQL
folder (<SQL Server installation path>\MSSQL$<instance name> folder for a
named instance) so that the SQL Server performance counters are available
to the user.
Another consideration is installing SQL hotfix etc, this usually needs
local admin right. If DBA is supposed to do this job, the account should be
in local admin group.

Roles and Responsibilities of SQL Server DBA

http://deepakdba.com/?p=225

Roles and Responsibilities of SQL Server DBA

1 Installation, Administration and Maintenance of SQL Server Instances. (Installatio of SQL Server)

2 Setup Test, Dev, Staging and Production Environments. (Installation of SQL Server)

3 Create Users and assign permissions based on the level of database access the user would need. (Security)

4 Create Linked Servers to SQL Servers. (General Administration)

5 Design database Backup and Restoration Strategy. (Database Backups and Restoration)

6 Once created the database Backups, monitor those backups are being performed regularly from SQl server
Agent Jobs. (SQL Server Agent)

7 Create Jobs and Monitor the jobs. (SQL Server Agent)

8 Recover the database as per the request. (Database Backups and Recovery)

9 Setup High-Availability as part Disaster Recovery Strategy for the Databases. (Failover Clustering,
Database Mirroring, Log Shipping, AlwaysOn and Replication)

10 Troubleshoot various problems that arise in a day-to-day work and fix the issues. (Monitoring SQL Server
Error Logs)

11 Monitoring and Performance Tuning; Physical Server Level, Database level (Database settings and
options) and query tuning. (Creating and maintaining those Indexes, not performing database shrinking,
memory settings, monitoring CPU usage and Disk I/O activity etc)

12 Documenting major changes to the SQL Servers. (General)

13 Apply Service Packs. (General)

14 Apply Cumulatiove Packs. (General)