Enterprise DBAs—those who manage complex
environments with a mix of database products and versions—face a number
of challenges. In addition to keeping many systems up and running, they
need to provide a smooth path for the implementation of changes to
production databases. Before looking at policy-based management in
depth, let's spend some time covering the typical enterprise
environment and the tasks faced by an enterprise DBA.
1. Enterprise environments
In a typical enterprise environment (see figure 1
for a simple example), one of the first things that comes to mind is
the number of production server instances requiring support. A large
number of servers are usually accompanied by a mix of product versions,
and possibly even other DBMS products such as Oracle or MySQL. In such
environments, some degree of specialization usually exists, and DBAs
are often grouped into areas of product expertise.
In
addition to the production server instances, test and development
servers, some or all of which may be provided using virtualization
products, exist for the purposes of developing and testing new
databases or making changes to existing production systems.
Accompanying such systems are various development tools and change
management processes to ensure changes are version controlled and
implemented in accordance with an appropriate deployment process.
In
environments with critical systems, dedicated operations staff are
usually on hand 24/7, with DBAs typically on call on a rotation basis.
Products such as Systems Center Operations Manager (SCOM)
are typically used for monitoring disk space and event logs in an
attempt to identify and solve problems before they manifest themselves
as production outages.
In
complex environments such as these, successful database administration
must overcome a range of challenges, some of which are presented next.
2. Enterprise DBA challenges
Let's take a look at some of the tasks facing DBAs in administering an enterprise environment:
Production systems should be secured with the least privilege
principle. This is often in contrast with development environments in
which changes originate. When developed code reaches test and
production systems, certain functions often fail as a result of the
security differences between environments. DBAs must therefore
coordinate environment configuration across the enterprise,
particularly settings that may cause certain functions to fail.
Databases in production environments (should) use the full recovery
model along with regular transaction log backups. In development and
test environments that don't perform transaction log backups, the full
recovery model may cause the transaction log to consume all available
disk space. DBAs must match environments with backup profiles and
recovery model settings.
In
sites where different DBAs manage different environments—for example,
development, test, and production—systems must be in place to ensure
that both common and environment-specific settings are applied where
appropriate. Where many DBAs are involved, each of whom has his or her
own preferences and skills, this becomes a difficult and time-consuming
process.
In sites with a range of DBMS
products that require support, it's often the case that the requirement
for a broad range of skills prevents expertise in any one area, making
correct and consistent configuration even more difficult.
In
poorly configured environments, the time taken to troubleshoot highly
visible production problems often prevents important proactive
maintenance required for ongoing environment performance, security, and
stability.
Without strong proactive maintenance routines, mismanagement is a real danger, presenting a number of organizational risks.
3. The risks of mismanagement
Even
with the best intentions and a good grasp of best practices, the sheer
size of some deployments creates a challenging environment for even the
most experienced DBA. Poorly configured servers pose a number of risks:
Security weak points
Unexpected performance problems due to different configuration settings between environments
Scripts working in one environment but failing in another, again due to configuration differences
Without
the use of third-party or custom-developed tools, ensuring consistent
server configuration across the enterprise is a difficult and
time-consuming process. This process often requires manual inspection
or development of PowerShell and/or SMO scripts, a skill possessed by
only a small percentage of DBAs.
Discovering
incorrect configurations is more often than not a result of
investigating script failures, poor performance, or worse, a security
breach. Such a process is commonly known as exception-based management.
What's needed is a way of defining and applying standard configurations
to groups of server instances, and either preventing or alerting on
deviations from the standard. This is typically called intent-based management,
and as you've probably guessed, that's exactly what we can now achieve
using the new policy-based management feature in SQL Server 2008.
