SQL Server: Top 10 Secrets of a SQL Server Expert

Many companies have downsized their IT
departments over the last few years. Many database administrators (DBAs)
have ended up with responsibility for large numbers of SQL Server
databases. Worse yet, often there’s no actual DBA. Someone is tagged as
the involuntary or de facto DBA. In some cases, the DBA ends up in pure
fire-fighting mode, moving from one crisis to the next. This sort of
environment is difficult, toxic and unsustainable. No one likes being
under constant stress and interruption.
One way out of this type
of situation is to invest a little bit of time streamlining your SQL
Server environment to make it easier to understand and manage. Based on
my SQL Server consulting practice, here are the top 10 ways a SQL Server
DBA can take control of his environment and reduce the overall
potential for crises to occur. This list is presented in roughly
increasing order of importance.
[b]10. Take Inventory[/b]How
many times have you been requested to restore damaged data on a
database you had no idea even existed? It’s easy for SQL Server
databases to sprawl across an enterprise. The DBA team can lose track of
what’s out there, resulting in unmanaged instances of SQL Server. This
results in databases that aren’t backed up, aren’t patched, aren’t
properly secured and missing out on a host of other necessary management
tasks.
It’s critical to have an up-to-date inventory of what
instances and databases you have in your enterprise and under your
control. This is the only way you can properly manage them, consolidate
where necessary, and correctly scope and plan projects and upgrades. It
also helps you establish limits to your responsibilities by publishing a
list of known instances for which you accept responsibility, with
agreement from the various teams in your organization. You can define
support policies for known instances and insist that new instances
adhere to your configuration guidelines before you support them.
There
are a number of tools to help you create a SQL Server inventory―from
simple tools such as SQLPing3 and SQLRecon to the Microsoft Assessment
and Planning Toolkit and the Quest Discovery Wizard.
[b]9. Standardize Configurations[/b]If
the number of databases and SQL instances for which you’re responsible
is growing all the time, you’ll know that the number of different
configurations grows in a similar fashion. It’s extremely hard to work
efficiently when moving from instance to instance if you have to
constantly remember the configuration details for different instances.
The
solution is to standardize your configuration to the greatest extent
possible in terms of drive letters, server configuration options,
database settings, database maintenance, security settings and so on.
SQL Server 2008 introduced the Policy-Based Management feature to help
define and enforce policies. Lara Rubbelke, a SQL Server technology
specialist at Microsoft, has also produced the Enterprise Policy
Management (EPM) Framework, which easily extends the capabilities to SQL
Server 2005 and SQL Server 2000 instances. You can find the EPM
Framework on CodePlex. Figure 1 shows a sample EPM Framework report.



Figure 1 The Enterprise Policy Management Framework report
[b]8. Understand the I/O Subsystem[/b]There
are several factors related to the I/O subsystem that can affect your
SQL Server instances. You need to be aware of these and their potential
impact:
The capacity of the I/O subsystem in terms of
read/write throughput and disk space. It must be able to cope with
workload peak demands and still provide space for the data volume to
grow before you have to purchase more capacity. By identifying I/O
bottlenecks and moving data and/or log files to other portions of the
I/O subsystem, you can more evenly balance the load.

The
redundancy capabilities of the I/O subsystem in terms of RAID level and
whether it can do things like split-mirror backups and any form of
mirroring/replication (at the I/O subsystem level, not the SQL Server
level). It’s important to protect your data and log files from drive
failures and other potential problems. This is often a trade-off―RAID-10
offers better redundancy than RAID-5, but is more expensive. Read the
white paper, “Physical Database Storage Design” for more guidance.

The
I/O subsystem is configured correctly in terms of RAID stripe size,
NTFS allocation unit/cluster size and partition alignment. Check out
this blog post, “Are your disk partition offsets, RAID stripe sizes, and NTFS allocation units set correctly?” for more details.

[b]7. Create a Customized Maintenance Plan[/b]Whenever
I teach database maintenance classes I always start off by saying, “You
can’t just put a database into production and walk away.” Indexes
become fragmented over time, which leads to performance degradation.
Statistics become out-of-date, which leads to bad query plans and poor
performance. I/O subsystems can get corrupted, and there’s the
ever-present need for backups.
You can tackle all these problems
by having a comprehensive maintenance plan tailored for your databases. A
customized plan is far better than a generic plan that doesn’t
adequately address your needs. My August 2008 TechNet Magazine feature, “Top Tips for Effective SQL Server Database Maintenance,”
tells you how to construct a good maintenance plan. The best starting
point for building your own maintenance plan is the comprehensive and
free script from Ola Hallengren. That’s what I recommend to my clients.
[b]6. Ensure the Security of Your System[/b]Investing
time in proactively discovering security problems is essential to
preventing incidents and not having to deal with them later. Another one
of my TechNet Magazine features, “Common SQL Server Security Issues and Solutions,”
lists the 10 most common security problems and how to avoid them. Also,
don’t forget to stay on top of patching your systems as you discover
vulnerabilities.
[b]5. Get on Good Terms with Your Developers[/b]One
of the major tension points in any IT department is often between the
DBA team and the development team. The two groups typically don’t
understand each others’ priorities and concerns―from development
deadlines to SQL Server design decisions. Differing opinions about
behavior and performance issues and responsibilities around deployment
and support are relatively common.
You can make your job a lot
smoother by engaging proactively and productively with the development
team. Organizing mutual education sessions works well, especially when
done in a non-accusatory manner. Conduct design reviews with someone
from the DBA team present, and test code adequately before being put
into production―hopefully avoiding damaging errors that can further
erode inter-team relationships.
[b]4. Develop a Comprehensive Disaster Recovery Strategy[/b]No
matter how bullet-proof your infrastructure may be, you must have a
contingency plan for when disaster strikes. You can’t predict
corruption, power outages, fires, accidental data loss or a host of
other potential problems. You need a plan to cope with and recover from
these problems.
Work with management to define down-time and
data-loss software license agreements for your databases, plan how to
recover data from various kinds of data loss, determine how your
databases and all SQL instances figure into your company’s
business-continuity plan. Work out the relative importance of all the
databases and instances so you can prioritize disaster recovery.
You’ll
also need to implement technologies to help you know when problems
occur, such as page checksums, consistency checks, SQL Agent alerts and
System Center Operations Manager alerts. This disaster recovery
infrastructure will help you protect data with backups, log shipping,
replication and database mirroring; and potentially failover to a
redundant system with database mirroring or failover clustering. There
are two Microsoft white papers that can help you with this: “High Availability with SQL Server 2008” and “Proven SQL Server Architectures for High Availability and Disaster Recovery.”
[b]3. Take and Test Regular Backups[/b]No
matter how good your high availability and disaster recovery planning
is, you cannot avoid taking regular backups of your databases. If your
database is destroyed or fatally corrupted, your only recourse may be to
restore from your last set of backups, so if you don’t have any backups
your company could suffer major consequences. Not only do you need to
take backups, you also need to regularly practice restoring from them so
you know they’ll work when needed.
You can find more information in two of the articles I wrote for TechNet Magazine in 2009: “Understanding SQL Server Backups” and “SQL Server: Recovering From Disasters Using Backups.”
[b]2. Monitor and Maintain Performance[/b]Performance tuning takes up the majority of a DBA’s time, but there are plenty of ways to streamline the process:
Establish a performance baseline so you can see whether performance has really changed.

Break the system up into primitives you can measure in isolation without the uncertainty of external factors.

Use the waits-and-queues methodology to quickly pinpoint performance problems.

Monitor
performance with system primitives, performance counters and wait
statistics. This way you’ll know when performance starts to degrade. Use
the performance Data Collector feature in SQL Server 2008 and the
Performance Dashboard for SQL Server 2005.

Establish a maintenance plan.

Carefully
plan and execute your indexing strategy with tools such as the Database
Engine Tuning Advisor, or DTA, missing index Dynamic Management Views
(DMVs) and index usage DMV.

[b]1. Know Where to Find Information[/b]With
a never-ending to-do list, it’s vital that you know when to call it
quits and look for help. You have to know your limitations and accept
that you can’t know everything about SQL Server. There’s no point in
beating your head against a wall and wasting precious time when someone
out there can help with your task or problem.
Your No. 1 source of information about SQL Server is SQL Server Books Online,
which you can download and install locally or search online on MSDN.
SQL Server Books Online is great for looking up syntax, but if you have a
more involved how-to question, or are trying to troubleshoot a problem,
the best thing to do is post a question on an online forum. There are
lots of SQL Server forums on MSDN and popular community sites like SQL Server Central.
Another
fast way to find help is to tap into the SQL Server community on
Twitter. Post your question with the #sqlhelp hash-tag, which many SQL
experts (including me) monitor.
Attend a SQL Server-specific
conference such as the annual PASS Community Summit, the bi-annual SQL
Server Connections or more frequent SQL Saturdays. Follow some of the
many blogs run by SQL Server experts in the community. You can get a
good idea of which blogs are active and worth following from the blog
rankings maintained by fellow-MVP Thomas LaRock.
You may be
overloaded and overwhelmed, but if you can put in some extra effort to
work through these suggestions, you should find you get huge benefits.
Your systems will run smoother, you’ll be better organized, you’ll have
more peace of mind―and you’ll be a more proficient DBA.
-------------------------------------
作者：Joe.TJ