Tài liệu SQL Server MVP Deep Dives- P10 docx

316
C
HAPTER
23
Mobile data strategies
Unlike
svcutil.exe
, this process will not generate a .config file to store the endpoint
information. This information is stored in the client proxy code.
To use this tool:
1
Open a Visual Studio command window.
2
Change the directory to your mobile application directory.
3
Enter this command:
NETCFsvcutil.exe http://<machinename>/yourservice/service.svc
The preceding command should generate two source files. The one named
after your service will contain the proxy class you will use to consume the
WCF
service you created. Add these classes to your project and compile the code.
The code can be found at this book’s website, http:
//www.manning.com/
SQLServerMVPDeepDives.
Comparison
Much thought has been given to creating solutions to ensure that data remains in sync
during periods of connectivity. All of the techniques—
RDA
,
MR
, and

MSF
—allow data
synchronization and replication; however, each has its own strengths and disadvan-
tages, as shown in table 6.
Summary
Which replication strategy you use is up to you, but if you are looking for a robust,
developer-centric, scalable solution, the
MSF
should be your choice. Notice the com-
parison in table 6.
MSF
replaces the functionality in
RDA
with an enhanced plan and
Table 6 Key feature comparison of the three synchronization methodologies
Key feature RDA MR MSF
Synchronize by using services No No Yes
Supports heterogeneous databases No No Yes
Incremental change tracking No Yes Yes
Conflict detection and resolution No Yes Yes
Easily create data views on the client No No Yes
Automatically initialize schema and data Yes Yes Yes
Supports large data sets Yes Yes Yes
Query processor is locally available Yes Yes Yes
Automatically propagate schema changes No Yes No
Automatically repartition data No Yes No
Use on devices Yes Yes Yes
Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
317

Summary
copies the functionality of
MR
. If you require a
DBA
-centric approach with little code
to set up the process, then
MR
is your choice. Both
MSF
and
MR
will keep your data in
sync. With the techniques and code samples we have shown in this chapter, you will be
able to take advantage of these methodologies to transfer, create, modify, and repli-
cate your data from your mobile device to your desktop server.
About the author
John Baird began his computer programming career while in the
US
Navy. In 1982, he helped form and direct the first
PC
-based
computer processing department for training and manpower in
the Department of Defense. After leaving the military in 1988,
John began a varied career as a consultant developing business
applications ranging from computer-based training to vertical
market software for resellers.
Today, John is working for the industry leader in financial soft-
ware for fund administration. John was awarded his
MVP

status for
device application development beginning in 2008.
Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
P
ART
3
Database Administration
Edited by Paul S. Randal
and Kimberly L. Tripp
A database administrator (
DBA
) has a tiresome and sometimes thankless
job—until things go wrong. It’s then that a
DBA
’s skills are most apparent. But
the less frequently anyone has to visit their
DBA
, the better that
DBA
is doing! So
how does a good
DBA
do it?
A good
DBA
works with actions rather than words: automating, monitoring,
tuning, but above all learning and constantly realizing what they don’t know. No

one can know everything, and a good
DBA
recognizes that—even embraces it. A
good
DBA
is always looking to improve their systems, learn tips and tricks, and
prototype new configurations. A good
DBA
sets up alerts to be notified of errors
and problems as soon as they begin to happen, possibly solving them before they
turn into disasters. Just as in life, the sooner you know there’s a problem, the eas-
ier it may be to fix! (Did you know that you can set up
SQL
Server Alerts based on
error severity levels—not just specific error numbers? For severity levels 19 and
higher, a generic alert should notify you that an error has occurred.)
So, how does a
DBA
make this happen? Not only does a good
DBA
proactively
look for faults before they become catastrophic but, when something does go
wrong, a good
DBA
takes the time to do a root-cause analysis to make sure the risk
is avoided in the future. Leveraging the
SQL
Server toolkit is imperative in mak-
ing this happen. Auditing, leveraging the Dynamic Management Views (
DMV

s),
using PowerShell, knowing the ins and outs of backup and restore, understand-
ing security, understanding availability; there are a lot of areas to understand, and
Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
a good
DBA
must be a jack of all trades and a master of at least some! It’s not easy, and
it’s more than just a job for a good
DBA
.
SQL
Server is a passion for these
DBA
s—a
hobby in addition to their job—and they’re constantly learning and expanding on
what they know to improve their uptime, minimize data loss, and even allow them to
take a vacation once in a while...
This book won’t teach you everything you need to know to be a good
DBA
, but it’s
one important part in the lifelong quest to get you there. Specifically, this section con-
sists of tips and tricks from some of the many
MVP
s who are either full-time
DBA
s (or
used to be) or who consult with
DBA
s who are constantly improving their systems and

skills. Many of these topics are the particular passions of the authors, and they’ve
donated their time and experiences to help us all become better
DBA
s. We truly want
to thank them for their time and especially their passion.

SQL
Server is a passion for both of us and we’ve enjoyed reading and learning from
these chapters and experiences. Whether you’re a seasoned
DBA
or a newcomer to
SQL
Server, we know you’ll find material in this section that will help you learn, grow, and
become a better
DBA
.
About the editors
Paul S. Randal and Kimberly L. Tripp are a hus-
band-and-wife team who own and run SQL-
skills.com, a world-renowned
SQL
Server consulting
and training company. They are both
SQL
Server
MVP
s and Microsoft Regional Directors, with over
30 years of combined experience on
SQL
Server.

Paul worked on the
SQL
Server team for nine
years in development and management roles, writ-
ing many of the
DBCC
commands, with responsibil-
ity for core Storage Engine for
SQL
Server 2008.
Paul writes extensively on his blog (SQLskills.com/blogs/Paul) and for TechNet Maga-
zine, where he is a Contributing Editor.
Kimberly worked on the
SQL
Server team in the early 1990s as a tester and writer
before leaving to found SQLskills and embrace her passion for teaching and consult-
ing. Kimberly has been a regular at worldwide conferences since she first presented at
TechEd in 1996, and she blogs at SQLskills.com/blogs/Kimberly.
Paul and Kimberly have written Microsoft white papers and books for
SQL
Server
2000, 2005, and 2008, and are regular, top-rated presenters worldwide on database
maintenance, high availability, disaster recovery, performance tuning, and SQL Server
internals. Together they teach the
SQL

MCM
certification throughout Microsoft.
In their spare time they like to find frogfish in remote corners of the world.
Licensed to Kerri Ross <>

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
321
24 What does it mean
to be a DBA?
Brad M. McGehee
If you ask ten database administrators (
DBA
s) what their job roles are, you’ll get
ten different answers. For example, one organization may need a
DBA
to manage
the day-to-day administration of
SQL
Server instances, whereas another organiza-
tion may want a
DBA
to write both Transact-
SQL
(
T-SQL
) and
C#
code. Another
organization might want a
DBA
who specializes in
SQL
Server Integration Services
(
SSIS

) packages, whereas another organization may want a
DBA
who specializes in
database design.
The job of
DBA
encompasses many different roles (and often job titles), and
these vary widely from one organization to the next. In short, there is no standard
job description for a
DBA
. This is partly because the job title doesn’t have a long his-
tory (relational databases were first used in the 1970s, and Microsoft
SQL
Server Ver-
sion 4.21 was released in 1993) and partly because the
DBA
role is quickly evolving as
new technologies are released.
Because there is no commonly-accepted definition of a
DBA
, the goal of this
chapter is to describe the types of tasks and roles that
DBA
s commonly perform, with
the aim of explaining to those new to the profession what
DBA
s do day-in and day-
out.
The first section of this chapter describes many of the tasks
DBA

s commonly per-
form. The second section classifies these tasks into specialty roles, as you will rarely
find a
DBA
who performs all of these tasks all the time. Throughout this chapter, I try
to answer the question: “What does it mean to be a
DBA
?”
Typical DBA tasks: A to Z
DBA
s perform so many different tasks that it is hard to categorize them all. The
alphabetized list that follows outlines the common
DBA
tasks. This list is by no
means comprehensive, and some of the tasks overlap.
Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
322
C
HAPTER
24
What does it mean to be a DBA?
APPLICATION INTEGRATION
Most organizations use some combination of in-house and third-party applications;
and few of these applications work in isolation. Therefore,
DBA
s often have to make
disparate applications talk to one another, using a database as the means of sharing
data.
DBA

s commonly get involved in figuring out the best way to integrate applica-
tions, and often perform the integration themselves.
ARCHIVING DATA
Data grows over time and can become costly to store and difficult to manage. In addi-
tion, increased data tends to exacerbate performance problems.
DBA
s are often
responsible for monitoring data size and growth, and determining the best way to
store it. In some cases, this may include archiving seldom-used data in another data-
base, or it might mean purging data that is no longer needed. Often, choices are lim-
ited, as company policy and government regulations can restrict how and where data
is stored.
ATTENDING MEETINGS
Most
DBA
s hate attending meetings because it detracts from work time. Meetings are a
fact of working life and, if used wisely, aren’t necessarily a waste of time. With correct
planning and preparation, meetings are great opportunities for improving communi-
cations. The responsibilities of the
DBA
are often unknown or misunderstood by co-
workers, so
DBA
s should always take advantage of opportunities, such as meetings, to
share with others what they do.
AUDITING
An emerging task of the
DBA
is to identify which users are accessing, inserting, updat-
ing, or deleting data, and when. Auditing might only be necessary for limited time

periods, for specific data, or it might be required 24/7 for all data.
DBA
s often work
with people outside their organization, such as external auditors, to perform this task.
And to further complicate the lives of
DBA
s, many industries are subject to specific
regulations on how data is accessed and protected, which means that
DBA
s have to
comply with some specific rules, with the potential for significant penalties, should
they not fully comply.
BACKUP AND RECOVERY
One of the most fundamental aspects of the
DBA
’s job is to protect the organization’s
data. This includes making periodic backups of data and keeping it safe from acciden-
tal or intentional destruction. In addition, a well-developed recovery plan needs to be
implemented and tested so that when problems arise, data and access to critical sys-
tems can be restored quickly.
BUSINESS INTELLIGENCE AND DATA WAREHOUSING
Another emerging trend is for
DBA
s to be tasked with the creation and maintenance
of data warehouses and business intelligence applications, so organizations can better
use their data to make more effective business decisions. Increasingly,
DBA
s are spe-
cializing in this fast-growing area.
Licensed to Kerri Ross <>

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
323
Typical DBA tasks: A to Z
CAPACITY PLANNING
In most organizations, the number and size of databases grow rapidly. It is the respon-
sibility of the
DBA
to monitor data growth, and plan how best to deal with it. This may
include archiving it, compressing it, increasing the size of current hardware, or add-
ing new hardware.
CHANGE MANAGEMENT
SQL
Server configurations, database schema,
T-SQL
code, and many other facets of the
application ecosystem change over time. It is often the responsibility of the
DBA
to
perform impact analysis before changes are made, implement changes, test changes,
and document them.
DATA MODELING AND DATABASE DESIGN
The foundation of all efficient and scalable databases is good design.
DBA
s often cre-
ate database designs by performing needs and requirements analysis, creating a logi-
cal model, and then implementing the physical model. Larger organizations may have
DBA
s who specialize in database design.
DATABASE APPLICATION DEVELOPMENT
Many

DBA
s are application developers who specialize in writing code to access data
stored in
SQL
Server databases. Although this is most commonly done using
T-SQL
, it
can include writing code that is used to access
SQL
Server data. Many
DBA
s decide to
make this their area of specialty, because of the depth of knowledge required to be a
good database applications developer.
DEVELOPING AND MAINTAINING BEST PRACTICES
Successful
DBA
s are proactive in their work, and one of the best ways to be proactive is
to develop sound database best practices, and to implement them in a consistent man-
ner. The better organized and managed the database operations, the more efficient
they will be. One of the many ways that
DBA
s can perform this task is to create a run-
book that describes the organization’s best practices and internal procedures. This
document is the
DBA
’s bible for performing all
DBA
-related functions.
DISASTER RECOVERY

At some point in their careers,
DBA
s will have to recover lost data. This may be as sim-
ple as restoring a database and its log files, or it may be as complex as moving a
weather-damaged data center from one city to another. To make dealing with disasters
easier (small or big), it’s the
DBA
’s responsibility to plan, implement, and regularly
test disaster recovery scenarios.
HARDWARE SETUP AND CONFIGURATION
In some organizations, hardware is handled by dedicated hardware technicians. In
others, the
DBA
is responsible for building, installing, and configuring their own hard-
ware, including servers and storage area networks (
SAN
s). In addition,
DBA
s may also
perform regular hardware troubleshooting and maintenance.
HIGH AVAILABILITY
A
DBA
needs to ensure that the databases are available to users when they need access
to data. You can help ensure high availability in many different ways, including use of
Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
324
C
HAPTER

24
What does it mean to be a DBA?
log shipping, clustering, database mirroring, and other technologies. Because of the
specialized knowledge required for high availability techniques, many
DBA
s choose
this as their main area of focus.
INSTALLING, CONFIGURING, AND UPGRADING SQL SERVER SOFTWARE
One of the most time-consuming of all database tasks is installing, configuring, patch-
ing, and upgrading
SQL
Server instances. Although it might sound like an easy task, it
usually isn’t. One of the difficulties is finding a good time to perform such work, espe-
cially in 24/7 shops. In addition, each time
SQL
Server is patched or upgraded, there
is the risk that after the patch or upgrade the applications that access the database, or
the databases themselves, might not work properly. On top of this,
DBA
s often have to
battle third-party vendors who are unwilling to certify that their application will work
after you have made the changes. This requires the completion of planning, testing,
and backout preparation before implementing major changes.
LOAD BALANCING
Over time, the load put on individual databases changes.
DBA
s are responsible for
monitoring workloads and figuring out how to maximize hardware resources to get
the best
SQL

Server performance. This may involve moving a database from a heavily
loaded server to a server with a lighter load.
SQL
Server virtualization, and how it can
benefit load balancing, is becoming a hot topic for many
DBA
s. For more information
on
SQL
Server virtualization, see chapter 39, “Running
SQL
Server on Hyper-V,” by
John Paul Cook.
MAINTAINING DOCUMENTATION
Writing and maintaining documentation is probably the most boring and loathed task
that a
DBA
will encounter. However boring, it is a critical part of the
DBA
’s job. If you
don’t document, then there is no easy way to rebuild the current infrastructure
should major problems arise.
MANAGING PEOPLE
Many
DBA
s find themselves in management positions, such as a senior
DBA
in charge
of junior
DBA

s. Some
DBA
s at large organizations do this full time, whereas others
combine people management with other DBA duties. On the other hand, when some
DBA
s get a taste of management, they give it up to get back to more technical work.
Managing people is not for everyone.
MANAGING SQL SERVER–BASED APPLICATIONS
A surprise for many new
DBA
s is the realization that they are responsible not only for
managing
SQL
Server and its databases, but in many organizations, they are also
responsible for managing any applications that access the database. In some organiza-
tions, the
DBA
spends more time managing applications than
SQL
Server itself.
MANAGING TEST ENVIRONMENTS
In many organizations,
DBA
s manage test environments that not only include test
SQL
Servers and test databases, but also test applications. The purpose of this is to allow
applications (both in-house and third-party) to be tested before new versions of either
the application or
SQL
Server are rolled out into production.

Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
325
Typical DBA tasks: A to Z
MENTORING
Oftentimes,
DBA
s have to share their knowledge with other
DBA
s, developers, or end
users. This might be informal one-on-one tutoring, or it might include classroom
training.
MONITORING
This is a wide-ranging task that includes multiple subtasks, such as performance mon-
itoring, monitoring server disk space, viewing logs, ensuring jobs have run successfully,
and scrutinizing for errors. Although a variety of third-party tools are available to per-
form these tasks,
DBA
s commonly spend a lot of time performing monitoring manually
because they don’t have a budget for such tools, or they are not familiar with them.
NEEDS AND REQUIREMENTS ANALYSIS
Whether
DBA
s are involved in development, or just supporting third-party applica-
tions, they often get involved in needs and requirements analysis. This can include
talking to users, finding out their needs and requirements, and determining the best
way to meet them. This often includes researching available third-party solutions and
determining if it’s best to develop the application in-house, or to invest in a third-party
application.
NEGOTIATING SERVICE LEVEL AGREEMENTS

In many organizations,
DBA
s become involved in negotiating service level agreements
(
SLA
s). An
SLA
is an agreement between parties in which one is the customer and the
other is the service provider. The customer (the owner of the business application
accessing
SQL
Server databases) and the
DBA
(the service provider), must agree on
acceptable levels of service, such as defining what is an acceptable response time for a
specific type of transaction. Part of the negotiating process often requires the
DBA
to
set expectations and educate the customer on what is feasible given the resource con-
straints of the organization.
OPERATING SYSTEM SETUP, CONFIGURATION, AND ADMINISTRATION
Just as many
DBA
s manage their own hardware, many
DBA
s also manage the operating
system on their
SQL
Server instances. Not only must
SQL

Server be configured opti-
mally, the operating system it is running on must also be configured optimally, and be
properly maintained.
PERFORMANCE TUNING
Everyone wants their data right now. It is the job of the
DBA
to monitor performance
and to determine ways to optimize database performance. This can be complex, and
many
DBA
s specialize in this area.
PROJECT MANAGEMENT
Oftentimes,
DBA
s find themselves in charge of a large project involving many other
people. This could entail writing a new in-house application, or managing the migra-
tion of a data center from one location to another.
DBA
s with good project manage-
ment skills are in high demand.
Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
326
C
HAPTER
24
What does it mean to be a DBA?
REPLICATION
Data is often moved from one server to another, and one of the most popular ways to
perform this task is to use

SQL
Server replication.
DBA
s often research various ways
data can be replicated from server to server, decide on the most appropriate method,
implement replication, and then manage it after it is up and running.
REPORT WRITING
With the advent of
SQL
Server Reporting Services, many
DBA
s find themselves writing
reports against databases. This might include writing the
T-SQL
code to extract the
data, or it could include the creation and formatting of physical reports. This is a new
and growing area, and some
DBA
s are specializing in it.
RUNNING JOBS
Virtually every
SQL
Server has jobs that run periodically. They might include backups,
data imports or exports, index rebuild jobs, and data integrity checks.
DBA
s are respon-
sible for determining what jobs are needed, creating the jobs, and scheduling them.
SCRIPTING
DBAs often write their own
T-SQL

scripts to perform a wide range of tasks, including
monitoring and maintenance. With the advent of PowerShell, many
DBA
s are writing
PowerShell scripts to enhance their productivity.
SECURITY
DBAs control who can access data and what they can do with it. This has many aspects,
including creating
SQL
Server logins and users, assigning permissions, moving secu-
rity between servers, and implementing data encryption.
SSIS AND ETL
DBA
s often move data in and out of databases, and at the same time, perform transfor-
mations on the data as it is moved. This is often done for data warehouses and applica-
tion integration. This process is often referred to as extract, transform, and load
(
ETL
), and in
SQL
Server this is commonly performed using
SQL
Server Integration
Services (
SSIS
).
TESTING
DBA
s frequently perform all sorts of testing. This can include testing of the following:
databases, applications, management tools, and disaster recovery plans.

DBA
s test
because they want to ensure the high availability and integrity of their data.
TROUBLESHOOTING
Virtually every day,
DBA
s troubleshoot one problem or another. Often when a prob-
lem occurs, the
DBA
is expected to drop everything and focus on resolving the prob-
lem at hand. This can result in long hours and high levels of stress. As with many
technical positions, effective
DBA
s are good problem solvers.
WORKING WITH TEAMMATES
DBA
s rarely work alone. In most cases,
DBA
s interact with many people, including
other
DBA
s, developers, end users, product-knowledge specialists, vendors, accoun-
tants, hardware experts, and networking experts. Because of this,
DBA
s need good
people skills.
Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
327
DBA specialties

DBA specialties
As you can see,
DBA
s perform many different tasks and take on a wide variety of roles.
Usually,
DBA
s are generalists because they need to know a little about many different
areas. On the other hand, you seldom find a
DBA
who is a master of all the previously
described tasks. This is for two reasons. First, most people don’t have the time to mas-
ter every
DBA
-related subject. Second, there is the added burden of having to keep up
with rapidly changing technology. For most people, it’s impossible to carry out all
aspects of the
DBA
role. To become a successful
DBA
, you don’t have to know
everything there is to know about
SQL
Server. In fact, you have a much better chance
of becoming a successful
DBA
if you narrow your focus and specialize in a handful of
SQL
Server subjects.
In this section, we take a look at some of the common areas in which
DBA

s specialize.
DBA SYSTEM ADMINISTRATOR
The
DBA
system administrator is a generalist who knows a little about many different
subjects. Also known as a production
DBA
, the
DBA
system administrator is generally
in charge of setting up, configuring, and maintaining test and production
SQL
Server
instances. This can include such routine tasks as monitoring, performance tuning,
backups and restores, security, creating jobs, and so on. In medical terms, think of the
DBA
system administrator as the general practitioner. All of the other
DBA
specialists
are more like medical specialists.
DBA DATABASE ARCHITECT
Think of a
DBA
database architect as the employee who sees the big picture of data
storage and access in an organization, and whose job it is to research the organiza-
tion’s data needs, research the available options, and then recommend policies the
organization should implement. In many organizations, the title of database architect
is another name for the lead
DBA
,

DBA
manager, or
DBA
project manager.
DBA DATABASE DESIGNER
DBA
database designers focus on creating new database schemas. They define user
needs and requirements, develop logical database designs, create physical databases,
and so on. In most cases, the
DBA
database designer works with
DBA
developers, or
other developers, to develop and maintain applications.
DBA DEVELOPER
The
DBA
developer writes code, be it
T-SQL
scripts, stored procedures, functions,
Common Language Runtime (
CLR
) objects, or any other kind of code that is used to
access
SQL
Server data. Often, the
DBA
developer works with
DBA
system administra-

tors,
DBA
database designers, project managers, and other developers to develop and
maintain applications.
DBA HIGH AVAILABILITY AND DISASTER RECOVERY SPECIALIST
For many of today’s online businesses, it is more critical than ever that
SQL
Server is
available around the clock. Therefore,
DBA
s often need to specialize in high availabil-
ity. Their job is to determine what high availability methods are best for their environ-
ment, and then to implement and maintain them, helping to prevent the loss of data
Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
328
C
HAPTER
24
What does it mean to be a DBA?
in the first place. Other
DBA
s specialize in disaster recovery, after the fact. In other
words, they are brought in to try to recover data from corrupted databases because
existing high availability and disaster recovery procedures failed.
DBA BUSINESS INTELLIGENCE SPECIALIST
DBA

BI
(business intelligence) specialists design, create, and maintain data ware-

houses and online analytical processing (
OLAP
) cubes, so that data can more easily be
retrieved and analyzed by organizations. This often involves developing
BI
-based
applications written using Multidimensional Expressions (
MDX
) queries. In most
cases, they are also heavily involved in extract, transform, and load (
ETL
) and design-
ing and implementing
SSIS
packages.
DBA REPORT WRITER
In the past, the
DBA
report writer has often been lumped in with the business intelli-
gence specialist.
SQL
Server Reporting Services has evolved to a point that many
DBA
s
are now specializing in designing and creating reports to extract data from databases
in meaningful ways.
Summary
Given that the
DBA
job description is so varied and constantly changing, it is hard to

list all the possible
DBA
specialties on which you might want to focus, so don’t con-
sider the list in this chapter to be anything more than an informal guide.
You may find that you want to develop your own specialty, one that is even more
focused than the broad specializations I’ve listed. For example, you might want to focus
on performance tuning, clustering,
SSIS
, or replication only. Nothing prevents you
from specializing as much as you like, other than the fact that the more narrow your
specialty, the fewer jobs available.
As we have seen, being a
DBA
means many different things. It is not a single job title
with a single skill set. Instead, the job title of
DBA
encompasses a wide range of job tasks
and roles that are tied together with a single common denominator—
DBA
s are the
guardians of the organization’s data. As
DBA
s, it is our job not only to protect an orga-
nization’s data, but also to make it available to everyone in the organization who needs
it to perform their jobs effectively. How well we fulfill this responsibility determines
how successful we are as
DBA
s.
Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

329
Summary
About the author
Brad M. McGehee is an
MCSE+I
,
MCSD
, and
MCT
(former) with
a bachelor's degree in Economics and a master's in Business
Administration. Involved in the industry since 1982, Brad is cur-
rently the Director of
DBA
Education for Red Gate Software,
and is an accomplished Microsoft
SQL
Server
MVP
with over 14
years of experience with
SQL
Server and over 6 years of training
experience. Brad is a frequent speaker at
SQL

PASS
, European
PASS
,

SQL
Connections, SQLTeach, SQLBits,
SQL
Saturdays,
TechFests, Code Camps,
SQL
Server user groups, and other
industry seminars. He blogs at www.bradmcgehee.com
.
Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
330
25 Working with
maintenance plans
Tibor Karaszi
Just like a car or a house, you want to maintain your databases so that they run
smoothly and safely over time. You probably have actions you want to perform that
are specific to your application and data, but some actions are common to most
databases, like backups and defragmentation. This is why Microsoft created mainte-
nance plans that make the implementation of standard actions easy. We specify
which of these standard actions we want to perform, for which databases, and at
what intervals—no
T-SQL
coding required. Of course, some
DBA
s want more con-
trol over the actions than the maintenance plans allow for, but for those who are
not full-time
DBA
s, maintenance plans are a good solution.

What is a maintenance plan,
and how do I create one?
The implementation of maintenance plans (
MP
s) has changed over time. From
SQL
Server 6.5 to 2000, an
MP
was executed by sqlmaint.exe through a
SQL
Server
Agent (Agent) job. As of
SQL
Server 2005, an
MP
is a
SQL
Server Integration Ser-
vice (
SSIS
) package, executed by an Agent job.
You create a plan using
SQL
Server Management Studio (
SSMS
) and right-
clicking the Maintenance Plans folder under the Management folder. You can use
either a wizard or a trimmed-down version of the
SSIS
package Designer, available

inside
SSMS
. For beginners, I recommend using the wizard, and, as you get more
comfortable using
MP
s, you can dive into the Designer.
The
SSIS
package is saved directly to the msdb database (not out in the filesystem
as a .dtsx file) along with some metadata in the msdb database, indicating that the
plan exists. This metadata allows
SSMS
to list your plans in the Maintenance Plans
folder, where you can right-click and edit them. If you choose to schedule the plan,
which you typically will want to do, then one or more Agent jobs will be created.
Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
331
What is a maintenance plan, and how do I create one?
Versions and service packs
If you are using
SQL
Server 2005, I strongly encourage you to be at least on Service
Pack 2 (
SP2
) on both the server and the client (
SSMS
).
SP2
added some functionality,

like a separate schedule per task, and it also added the Maintenance Cleanup Task to
the wizard. In fact, if you are using
SQL
Server 2005, you want to be at least slightly
higher than the original
SP2
release because of some bugs in that original release.
TIP
What build number you want to be using, and how to check it, is slightly
complicated and depends on whether you have applied a hotfix or not. I
suggest you check out http:
//blogs.msdn.com/psssql/archive/2007/04/
06/post-sql-server-2005-service-pack-2-sp2-fixes-explained.aspx and verify
that you aren’t using the original SP2.
I will assume
SQL
Server 2008 in this section. An
MP
in
SQL
Server 2005 with SP2 looks
the same and has the same functionality as in 2008 (with the addition that for
SQL
Server 2008 you can compress a backup if you are using Enterprise Edition).
One or several schedules per plan?
You might not be familiar with some of the terms I use here; therefore, it’s time for
some explanations. A maintenance plan (plan) is what is created by the Designer or wiz-
ard. It’s implemented as an
SSIS
package, which is saved directly to the msdb database.

An
SSIS
package consists of several
SSIS
tasks, where each task is of a certain type
(backup database, check integrity, and so on). You decide whether to schedule the plan
(typically you will want to do this), which will create one or several Agent jobs, where
each job has one Agent schedule.
As of
SP2
, you can decide whether you want to have one schedule per task or one
schedule for the entire plan (the latter was the only option prior to
SQL
Server 2005
SP2
). Having several schedules will result in several Agent jobs—one per schedule.
There are advantages with both alternatives; therefore, think a few minutes about how
you want to do this. As an example, say you want to perform these tasks:

Weekly defragmentation and removal of backup history

Daily database backup, removal of old backup files, and checking of database
integrity

Transaction log backup every 15 minutes
If you have one schedule per task, you can have only one plan, but you will end up
with six Agent jobs (called subplans), each scheduled separately. This means you have
to decide for each job when it is to be executed. If you don’t want the jobs to overlap
each other, you’ll have to plan out the timing.
On the other hand, if you want only one schedule for the plan, you will end up

with several plans—three plans in the preceding example. You would have one plan
for the weekly tasks, another for the daily tasks, and yet another for the log backup
task. For each plan, you can decide in what order the tasks are to be performed.
Licensed to Kerri Ross <>
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.