The Evolution of the SQL Server DBA

What Will You Be Doing 10 Years From Now?

written by
Tom Sager,
DBA Team Leader,
E.ON U.S.
© Copyright Quest® Software, Inc. 2008. All rights reserved.

This guide contains proprietary information, which is protected by copyright. The

software described in this guide is furnished under a software license or
nondisclosure agreement. This software may be used or copied only in accordance
with the terms of the applicable agreement. No part of this guide may be reproduced
or transmitted in any form or by any means, electronic or mechanical, including
photocopying and recording for any purpose other than the purchaser's personal use
without the written permission of Quest Software, Inc.

WARRANTY

The information contained in this document is subject to change without notice.

Quest Software makes no warranty of any kind with respect to this information.
QUEST SOFTWARE SPECIFICALLY DISCLAIMS THE IMPLIED WARRANTY OF THE
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Quest Software
shall not be liable for any direct, indirect, incidental, consequential, or other
damage alleged in connection with the furnishing or use of this information.

TRADEMARKS

All trademarks and registered trademarks used in this guide are property of their
respective owners.

World Headquarters
5 Polaris Way
Aliso Viejo, CA 92656
www.quest.com
e-mail: info@quest.com

Please refer to our Web site for regional and international office information.

Updated—January 2008
CONTENTS
INTRODUCTION .......................................................................................... 1
HISTORY ..................................................................................................... 2
1998: SQL SERVER GROWING PAINS ................................................................. 2
2008: A HOST OF BROADER ISSUES ................................................................... 2
2018: A NEW BATCH OF PROBLEMS.................................................................... 3
TECHNOLOGICAL TRENDS ........................................................................... 4
HINTS IN SQL 2008 ...................................................................................... 4
WHAT TO LOOK FOR IN SQL SERVER 2011 ........................................................... 4
THE LONGER VIEW ........................................................................................ 5
VIRTUALIZATION ........................................................................................... 5
AUTOMATION ............................................................................................... 6
HIGH-AVAILABILITY AND DISASTER RECOVERY ....................................................... 6
INDUSTRY TRENDS ..................................................................................... 7
COMPLIANCE................................................................................................ 7
SECURITY ................................................................................................... 7
GLOBALIZATION ............................................................................................ 8
COMPETITION IN THE RELATIONAL DATABASE MANAGEMENT SYSTEM (RDBMS) MARKET...... 8 T

SHRINKING WORKFORCE ................................................................................. 9

EXPLODING DATA AND APPLICATIONS ................................................................ 10
SUMMARY ................................................................................................. 11
CONCLUSION ............................................................................................ 12
ABOUT THE AUTHOR ................................................................................. 13
ABOUT QUEST SOFTWARE, INC. ................................................................ 14
CONTACTING QUEST SOFTWARE ....................................................................... 14
CONTACTING QUEST SUPPORT ......................................................................... 14
T

i
 The Evolution of the SQL Server DBA

INTRODUCTION
What will the SQL Server database administrator’s (DBA) job be like 10 years from now?

This is a broad question. It also implies the answer to another question: will there
be such a thing as a SQL Server DBA in 10 years? By job title, I think the answer is
clearly yes, there will certainly be SQL Server DBAs in 2018. Much less clear,
however, is what exactly SQL Server DBAs will spend their time doing. This paper
offers some possible answers to this question based on current and foreseeable
industry and technological trends.

1
The Evolution of the SQL Server DBA

HISTORY
To look 10 years ahead, it is helpful to look 10 years back in the past. An old
aphorism goes something like: to know where you are going you must know where
you have been. This holds true much of the time. And not only does it apply to IT in
general, but it also applies to the SQL Server world particularly well.

1998: SQL Server Growing Pains

In 1998, I had been a SQL Server DBA for about four years, having started out with
version 4.21a in 1994. By ’98, we were well underway on migrating from version
6.5 to the newly rewritten SQL Server 7. In those days, the job of the DBA was
mostly about getting SQL Server to work because we were in a transition phase
from considering SQL Server as a departmental-only RDBMS to using it for
enterprise-wide applications. There were some growing pains. Sometimes plans
were too ambitious. And there were a few failures.

Also in 1998, expansion of server environments was well underway during a

population explosion. New application? No problem, fire up another NT server.
Viruses? Only on PCs, not on NT. Worms? Never heard of them; SQL Slammer was
still years in the future. About the only thing that really concerned us back then was
Y2K looming ahead.

2008: A Host of Broader Issues

Times have changed to be sure. Issues that were not even on our radar screens
back in 1998 are at the forefront today. Issues that were of paramount importance
back then have disappeared. The question of whether SQL Server will work for a
given application is now moot. We know it will.

Today’s issues are much broader and there are more of them. Security, for
example, has become multi-faceted in recent years, with the following, equally
important issues:

• Protection from viruses, worms, denial-of-service attacks

• Protection of data
• Auditing use of data
• Disposal of data

2
 The Evolution of the SQL Server DBA

Compliance requirements, such as Sarbanes-Oxley, while closely related to

security, goes much deeper and can have major implications for database resource
utilization. In some companies, e-discovery has eclipsed Sarbanes-Oxley as the
biggest non-productive resource consumer.

The data growth explosion continues at an accelerated pace. SQL Server DBAs are
finding it more difficult to get their databases backed up. Fortunately, there are
tools such as Quest Software’s LiteSpeed™ that can shrink database backup files to
a fraction of their normal size.

2018: A New Batch of Problems

Will the crucial issues we face today disappear by 2018? It’s possible. It’s not that
auditing, viruses, and security won’t matter. It’s that the way we handle those
things will have become so mundane that we will no longer spend much time
thinking about them. A standard SQL Server deployment will imply that all data is
encrypted, changes are logged, and patching is automatic and unattended.

Instead of these compliance and security issues, we will have a new batch of
problems to deal with. The rest of this paper explores some of the industry and
technological trends that are either already occurring or that are expected to occur
in the next 10 years. We will explore what those trends will mean for the SQL
Server DBA.

3
The Evolution of the SQL Server DBA

TECHNOLOGICAL TRENDS

Hints in SQL 2008

SQL Server 2008 will introduce new features that provide some insight into the
direction of database administration in the coming years. The new Declarative
Management Framework (DMF) for example—which is basically a means to define
policies and apply them across the enterprise on multiple instances—is a step away
from individual instance management.

Third-party vendors have already started down this path. For example, Quest
Software’s latest version of Change Director provides robust functionality to
manage an entire enterprise’s SQL Agent jobs from a single point. More and more,
tools and functionality will be geared towards managing the SQL Server farm rather
than the individual instances.

Another new SQL 2008 feature is the Resource Governor. This much-needed
feature allows DBAs to set priorities and resource limits on individual jobs, which is
key in preventing processes from getting starved for resources. Yet another is new
feature is the “Hot Add CPU” that will allow the addition of CPUs to supported
hardware without downtime.

These new features point to a future in which SQL Servers are managed at the
enterprise-level with dynamic resource allocation. As this trend continues, the SQL
Server DBA’s job will evolve with the changing landscape.

What to Look for in SQL Server 2011

If Microsoft is successful in releasing a new version every three years, we can
expect a SQL Server 2011. I expect this version to include “grid-like computing”. At
various public Microsoft events and user group meetings, I have heard Microsoft
representatives declare their dislike for Oracle’s shared-disk clustering (used in
their RAC technology). Instead, Microsoft has focused on things like Federated
Database Servers, which might be loosely thought of as grid-like computing.
Although this approach is not currently workable in a general-purpose sense, it is a
direction that Microsoft is likely to pursue until it is application-transparent.

Whether or not grid-like computing makes it into SQL Server 2011, we will probably
see SQL Server become—in the next 10 years—more “network-like”, where each
instance is part of a greater whole that is managed at a higher level . In the future,
SQL Server may become what we think of today as a software agent. It will be
deployed and managed as we might treat an antivirus agent in a server farm today.

4
 The Evolution of the SQL Server DBA

The Longer View

Other fundamental changes are occurring outside the realm of new features in
future versions of SQL Server. One of these changes is the database content. Ten
years ago, most SQL Server databases contained numbers, characters and dates.
Gradually, the capacity of the SQL Server’s hardware increased and SQL Server’s
abilities to store and retrieve data improved. Thus different types of data such as
documents, special data, and XML found their way into the database and are stored
in SQL Server. Many applications (e.g., SAP) store their executable code in the
database as well. Newer products like Microsoft’s SharePoint are poised to
completely replace traditional file and web server. Everything stored in the
database will be accessed in real time. In short, SQL Server databases are evolving
from “data stores” to “object stores”.

Thus, storage is becoming a greater challenge as the database size explosion

continues. Several things are happening to storage at the same time:

1. Storage is moving away from the servers. SAN and NAS technology has
replaced DAS (direct attached storage) on most SQL Servers of any
significant size. But further independence is developing, perhaps in the
form of clustered storage which may be poised to become the next
generation of storage.
2. Storage is increasingly devoted to databases only. As more of a company’s
content is moved into the database (e.g., SharePoint, SAP) there is less of
a need to store files, documents, etc.
3. The DBAs are getting a greater say in how the SAN is managed. In some
companies, DBAs and SAN administrators are merging into the same
group. This makes sense since DBAs know the nature of the data being
placed on the volumes and knows best how it should be distributed.

Virtualization
Virtualization has been a popular buzzword for several years now. Like many
popular IT buzzwords, this one has no clear meaning. Certainly one form of
virtualization is the VMware/MS Virtual Server technology, which appears to be
taking off in the small Windows Server space. However, even in this space, I still
see resistance to it from (a) software vendors who fear it and thus will not support
their applications on it, and (b) people like me who are suspicious of the added
layer of complexity and have not yet had positive experiences running SQL Servers
on virtual instances.

Despite this, I believe virtualization as a concept will play heavily in the future of the
SQL Server DBA. However, I think virtualization will play an opposite role for SQL
Server. DBAs will not be rushing out to install SQL Server on 20 different virtual
Windows instances running on a single piece of hardware. Instead, they will be defining
a virtual instance that runs on up to 20 different physical servers. This is more of the
5
The Evolution of the SQL Server DBA

“grid-like computing” idea discussed earlier. Virtualization will not be there for the sake
of consolidating hardware (although ultimately less hardware will be needed because of
the efficiencies gained in the grid model). Instead, it will be used for dynamic resource
management. If a particular database needs more resources, the DBAs will be able to
deploy it onto more servers in the “grid”. I am assuming that since Oracle has adopted
the ‘grid’ terminology for RAC, Microsoft will come up with a new word to refer to this
concept. ‘Grid’ will be used here in the generic sense from where it came: “utility
computing. This concept borrowed from how electric utilities manage their power.

Automation
Automation will continue to develop. The goal of all database vendors is to provide
a database management system (DBMS) that is self-managing, self-healing and
never-down. Database vendors are likely to market this as a fully-automated DBMS
(and have already done so from time to time) that would not require DBA support.
However, we know this claim is rubbish. What automation really does is “move the
cheese,” which is really the point of this paper: the DBA’s job is changing and it will
continue to change significantly 10 years from now.

Automation may mean that SQL Server DBAs don’t need to worry about database
reorganizations, updating table and index statistics, or maybe even patches
someday. However, it doesn’t mean they won’t have an even longer list of new stuff
to worry about. They will. Count on it. Technology does not keep pace with our
appetite for using it. Can you imagine how easy your job would have been in 1998
if you had the technology available today?

High-Availability and Disaster Recovery

High-availability and disaster recovery are usually considered two distinct things.
Mostly, this is due to limitations in the technology supporting both. As the technology
around them improves, they will merge into one thing: an always-up, geographically
distributed database infrastructure. The DBA’s job will be to manage this
infrastructure, and it won’t be a ‘SQL Server-only’ kind of job. A big component of
the infrastructure will be the clustered storage housing all the terabytes of data, and
it will need to operate in conjunction with the SQL Server grid. Thus, as suggested
earlier, the SQL Server DBA is likely to wear a storage administration hat as well.

6
 The Evolution of the SQL Server DBA

INDUSTRY TRENDS
Compliance
Sarbanes-Oxley is a big deal to many companies today. There is a good chance that
many of these compliance requirements, particularly Section 404 which applies to
IT, will be relaxed somewhat. That’s because it is generally understood that the
value of these requirements is far exceeded by the cost of meeting them. Many
companies that have figured this out have gone so far as delisting themselves from
the stock exchanges to avoid this compliance burden.
A much bigger issue that has risen to the forefront in recent years is “e-discovery”.
This will turn out to be a much more onerous burden than Sarbanes-Oxley. The
biggest reason behind this is the source. Sarbanes-Oxley basically dictates that a
company’s compliance to the law is verified by an accounting firm. But e-discovery
is really the venue of lawyers. Yes, there are various laws and regulations dealing
with e-discovery requirements, but they are vague and inconsistent. And since e-
discovery isn’t about financial statement compliance but rather about litigation—it’s
really all about the lawyers.
So, unless Congress passes some law that makes it extremely clear what companies
must keep, and for how long, companies will be forced to keep everything—for a long
time. And of course they are going to keep this data in the database. That means SQL
Server DBAs will need to learn what comes after terabyte (it’s petabyte).
Emails are a big part of e-discovery today. And now instant messaging (IM) has
followed suit, despite the fact that communication via IM is supposed to be
analogous to a spoken conversation. Will phone conversations be next? After all,
VoIP (voice over IP) is technically an electronic digital communication. If we
continue down this path, even verbal office conversations will be recorded and
stored for legal discovery purposes. How would it be to work in an office where
every single piece of communication is recorded and stored in a database? I’m not
predicting SQL Server DBAs will be dealing with microphones in the restrooms in 10
years, but I am suggesting that e-discovery could become a huge consumer of
database resources and DBA management efforts.

Security
Of course security is always a big deal, but it is starting to take on new twists. This
trend will continue (probably indefinitely) and will certainly affect SQL Server DBAs
in different ways over the next 10 years.
Security (from a DBA’s perspective) used to be all about protecting the data from
unwanted users. It was about who could see what data and—more importantly—who
could change the data. This kind of security is still of paramount importance, but now
there are new risks and issues to deal with. One that is getting the most press
(negative, of course) is privacy. Most companies have customer information of some
sort stored in their databases. Customers expect their personal information to remain
confidential. The days of implicit trust of the IT employees (and, gasp, even DBAs!)
are pretty much gone, and will probably be completely gone 10 years from now.
7
The Evolution of the SQL Server DBA

Globalization
The globalization trend may be one of the more fascinating aspects of how the role
of SQL Server DBAs will change. It has certainly been interesting to watch during
these past 10 years or more. When I started out in IT, working with someone
overseas was almost unheard of. Today, it is quite common and the chances of
working with someone or even needing to travel overseas are increasingly great.

Our current global economy has prompted some obvious changes such as the need
to use unicode datatypes to support multilingual application databases. It has also
prompted some not so obvious changes: software contracts, licensing, and
exchange rates can all become complicated issues for a multinational company.

Finally, globalization is increasing the scale of our distributed computing efforts. As

the bandwidth between continents and around the world increases, the likelihood of
treating the whole planet like a local network increases. As a SQL Server DBA
today, you may find yourself with mirror or standby databases on the opposite side
of the world from your primary. Ten years from now, you may find yourself
managing a “grid” of SQL Servers spanning the globe.

Competition in the Relational Database

Management System (RDBMS) Market
Since this is always fodder for the trade publications, perhaps it is worth a mention.
The great “database war” will undoubtedly continue for the next 10 years. As a DBA
and an RDBMS customer, I benefit greatly from struggle for market share among
the big three (Microsoft, Oracle and IBM). They pretty much have the whole pie to
themselves, and they should be wary of newcomers from the open-source world.
However, their position as leaders in the RDBMS marketplace seems to be secure
for the next 10 years.

A note on the nature of the RDBMS war: installed databases almost never get
converted. If an application goes live with Oracle, there is a very slim chance it will
ever get converted to SQL Server. However, when that application’s lifespan runs
out and its replacement is being considered, that’s when the battle is fought. It’s
always about the new implementations, not the installed base. The installed base
provides some momentum (or drag, depending on your point of view) but each new
implementation is an opportunity for change.

Even though the war will continue, the nature of the battle is already changing. Ten
years ago, Microsoft was winning battles based on cost. Conventional wisdom at the
time was that Microsoft’s licensing costs were much lower than those of its
competitors. As a solution, Microsoft was even more economical because it was
deployed on commodity Intel hardware. And this was largely true. Oracle was
mostly a Unix database, and DB2 was mostly mainframe as well as Unix—both
high-cost platforms.

8
 The Evolution of the SQL Server DBA

Just like the mainframe, Unix appears to be headed the same place the mainframe
went: restricted to the ever-shrinking minority of organizations that need the
additional capabilities of those expensive architectures. Commodity-hardware
solutions are dominant now. As a result, the playing field in the RDBMS market is
leveling with regards to hardware architecture.

On the OS front, Windows was once the low-cost solution. However, the rise of
Linux dethroned Microsoft in this area. So the OS field is leveling as well.

And today, the same is happening in the RDBMS market: SQL Server is not clearly
the lowest-cost solution that it was 10 years ago. It’s impossible to get accurate
data on actual licensing costs companies are paying; generally their license
agreements prohibit them from revealing those costs. However, it is widely known
throughout the industry that nobody pays list price. Unfortunately, the RDBMS
market resembles a little too closely the operation of an automobile dealership. So
when one of the trade publications compares the price of SQL Server at
$25,000/CPU with Oracle’s at $40,000/CPU, the reader can safely dismiss this
comparison. No one is paying those prices. Moreover, we should not assume that
because Oracle’s list price is significantly higher than SQL Server’s that Oracle’s
discount will be more than SQL Server’s discount.

The point of all this is that if you are a SQL Server DBA helping your company
decide which RDBMS to implement, be aware that the historical advantage of SQL
Server being the low-cost solution is pretty much gone. And that advantage will
probably continue to diminish over the next 10 years.

Therefore, as the steward of your company’s data, you will need to look at other
areas of value that Microsoft SQL Server brings to the table—and there are plenty!

Shrinking Workforce
The baby boomers are starting to retire. Young people are less often pursuing
degrees in computer technology. One can hardly blame them; IT is not the sure bet
it once was. So, as the IT elders exit the workplace and the next generation shuns
the field, the number of people available to do the work is shrinking. This change
alone will necessitate the evolution of the DBA from the technical guru to the
resource manager. There simply won’t be enough qualified gurus around to
continue operating in the old way.

9
The Evolution of the SQL Server DBA

Exploding Data and Applications

At the same time as the workforce is shrinking, the data and applications in need of
support are undergoing an explosion in scale. Even if the workforce were not
shrinking, this growth would require fundamental changes in how the DBA
approaches SQL Server administration.

Thinking back even before the days of SQL Server, to database administration in
general about 20 years ago, I recall that we scrutinized individual columns. Adding
a column to a table was a big deal. We considered its name to make sure we
preserved consistency across the database. Also we considered its datatype and
length to ensure we were being as efficient as possible, without wasting precious
disk space. Databases were measured in megabytes back then and were on the
order of a hundred tables.

Ten years later, the applications being implemented with SQL Server often had
thousands of tables and the databases were measured in gigabytes. As DBAs, we
still cared about columns (i.e. we watched for the occasional lazy developer who
wanted to make every column variable length 255 bytes), but we were forced to
give up scrutiny of every little change at that level. We relaxed our standards
because of circumstances.

Today, the average SQL Server DBAs have relaxed their standards even further.
There are just too many tables in the average enterprise-class application to worry
about. Instead, we tend to focus on the individual databases, which are now
frequently measured in terabytes. In some cases, even that is not feasible and we
tend to look at SQL Server at the instance level instead. Once again, the DBAs have
been forced up to a higher level of detail.

And so 10 years from now, the DBA’s focus is likely to be at an even higher level of
detail than it is today. Instead of looking at individual instances for tuning and
management, we will be looking at a collection of instances running in concert with
one another and at the infrastructure that ties them all together.

The flip-side of this trend of the DBAs moving away from the technical details of the
RDBMS is the move towards the business aspects of the applications they support.
DBAs have always been relatively close to the business applications (more so than
typical system administrators and network administrators). But as their focus
moves to an increasingly higher level, it will inevitably get closer to the business
area being supported. I am not suggesting that DBAs will all need to be MBAs, but
they will need to know what’s going on in considerable detail.

10
 The Evolution of the SQL Server DBA

SUMMARY
What do all of these trends and predictions mean for SQL Server DBAs 10 years
from now?

Perhaps this: that being a SQL Server DBA in the future will be much more like being
an Exchange Administrator today. In other words, yes, there is a database engine in
there somewhere, but you won’t get to tinker with it. Instead, your time will be spent
managing it at a higher level. And while this may not sound like a desirable turn of
events, in the end you would be thankful. That’s because you will not be managing at
the instance-level, you will be managing an entire enterprise. This enterprise will be
connected with a level of interdependency that requires it to be treated as one entity.

In particular, I see these changes and trends in store for SQL Server DBAs:

• The storage explosion will continue. Terabytes will increase to petabytes. It

is difficult to conceive of an exabyte-sized database, but on the other hand
Bill Gates couldn’t conceive of anyone needing more than 640K of RAM.
• Automation will relieve you of mundane tasks but will still not give you
enough hours in the day to do what needs to be done.
• Virtualization will not be synonymous with a single technology. Instead it
will mean that no one needs to know where anything is (other than the
DBA, of course). The term database will no longer imply a physical
structure on a SQL Server; it will be a logical entity distributed across the
infrastructure that DBAs manage.
• The emphasis on high availability diminish; “always up” will be implicit.
• DBAs will work with corporate attorneys and compliance specialists much
more frequently (whether they like it or not!).
• DBAs will no longer have the advantage of having the low-cost database.
Rather than an advantage in some case, SQL Server’s presumed low-cost
has been a hindrance to garnering respect, so the silver lining here is that
the big three RDBMS’s will be on equal footing regarding cost.
• DBAs will be called upon to provide solutions for business problems, not
just technical issues.
• DBAs will continue to be paid well.
• In some companies, a DBA’s official title may actually change, perhaps to
something like “Data Resource Manager”. But you will probably still call
yourself a DBA and so will everyone else.
• You will still have a lot of fun!

Thus, the traditional DBA role of the technical guru—who knows just what knobs to
turn to get a desired result on some esoteric query—will continue to evolve into a
manager of database resources. Having that in-depth technical knowledge will still
be valuable, but having the time to spend using it will be the struggle. More and
more, you will have to let go of the things that were once important when the job
was about “making it work” and instead concentrate on the bigger picture—making
sure it all works together.
11
The Evolution of the SQL Server DBA

CONCLUSION
The role of a SQL Server DBA has evolved over the past 10 years from a technician
role to a resource management role. It is likely to continue to evolve into a broader
management role, where DBAs will be responsible for managing much more than
just SQL Servers. They will also manage supporting technologies, such as storage,
and supportive technologies, such as SharePoint. DBAs will need broad business
knowledge and several soft skills to meet these new responsibilities. Technical skills
and knowledge will still be critical. However, it will be rare to find DBAs who have
deep knowledge of SQL Server internals yet little knowledge of the applications
their databases support or the business those applications support.

12
 The Evolution of the SQL Server DBA

ABOUT THE AUTHOR

Tom Sager is a DBA team leader at E.ON U.S, a diversified energy services
company. He has been with the company for 17 years, in application development,
database administration and leadership roles. Sager has technical expertise in
performance tuning, high availability and disaster recovery and his team also
specializes in managing diverse database environments with mixed SQL Server,
Oracle and DB2 environments. Tom is a prolific author, with more than 50
published articles on SQL Server, Oracle, DB2, mainframe, Windows and Unix. Tom
is a member of PASS and has served on its board. He is also a member of IOUG
and Quest’s Association of SQL Server Experts.

13
The Evolution of the SQL Server DBA

ABOUT QUEST SOFTWARE, INC.

Quest Software, Inc. delivers innovative products that help organizations get more
performance and productivity from their applications, databases and Windows
infrastructure. Through a deep expertise in IT operations and a continued focus on
what works best, Quest helps more than 50,000 customers worldwide meet higher
expectations for enterprise IT. Quest Software can be found in offices around the
globe and at www.quest.com.

Contacting Quest Software

Phone: 949.754.8000 (United States and Canada)
Email: info@quest.com
Mail: Quest Software, Inc.
World Headquarters
5 Polaris Way
Aliso Viejo, CA 92656
USA
Web site www.quest.com

Please refer to our Web site for regional and international office information.

Contacting Quest Support

Quest Support is available to customers who have a trial version of a Quest product
or who have purchased a commercial version and have a valid maintenance
contract. Quest Support provides around the clock coverage with SupportLink, our
web self-service. Visit SupportLink at http://support.quest.com

From SupportLink, you can do the following:

• Quickly find thousands of solutions (Knowledgebase articles/documents).

• Download patches and upgrades.
• Seek help from a Support engineer.
• Log and update your case, and check its status.

View the Global Support Guide for a detailed explanation of support programs,
online services, contact information, and policy and procedures. The guide is
available at: http://support.quest.com/pdfs/Global Support Guide.pdf

14