Brad M. McGehee
SQL Server MVP
Director of DBA Education
Red Gate Software
You may be a part-time or full-time DBA
You may be a DBA Administrator or DBA
You may have less than one year’s experience as
a SQL Server DBA
You may be an experienced DBA, but don’t mind
spending a little time reviewing DBA
fundamentals, because you may learn something
new, or remind you of something you forgot.
Helps to optimize SQL Server performance
Helps to maximum SQL Server availability
Helps you to be proactive, not reactive
Helps you to reduce being in “crisis” mode
Reduces your stress levels
Makes your manager happier
Give you more time to focus on what really
While each best practice I discuss today might
seem small, the total effect of following each and
every recommendation can be huge.
By closely following each of these best practices,
SQL Server performance and availability can be
boosted by 20%, 50%, or even more.
One-time checks to verify proper SQL Server instance
Daily, weekly, monthly tasks that need on-going attention
1. Our focus today is on what to do, not how to do it.
2. Best practices are based on the biggest mistakes I see DBAs make.
3. These best practices are just the basics, there are a lot more to learn.
4. There are always exceptions to every rule, and not every recommendation
discussed here may fit your environment.
Installing & Upgrading SQL Server
User Data and Log File Management
Database Configuration Settings
Create Index Rebuilding/Reorganize Job
Create Data Corruption Detection Job
Set Up Alerts for Critical Errors
Implement a Backup Strategy
Create a Disaster Recovery Plan
When installing a new SQL Server instance:
Use the newest OS version with latest SP
Use the newest SQL Server version with latest SP
Use the 64-bit version of the OS and SQL Server
When upgrading, it is always safer to upgrade to
a new server with a fresh installation of the OS
and SQL Server than to upgrade in place.This
allows you to test more effectively, and also
gives you a backout option.
Is the OS configured to optimize background
Need to have at least 20% free disk space on all
disk drives. Important for NTFS performance.
SQL Server instance should be a stand-alone
server with no other apps running on it.
Unnecessary services should be turned off.
Don’t run antivirus software locally.
Ideally, use 64-bit hardware and the 64-bit
version of SQL Server.
If using 32-bit version, and if using 4 GB or more
of RAM, ensure than AWE memory is correctly
Remove physical file fragmentation before
adding new MDF or LDF files
The OS and SQL Server binaries should be on
their own volume
MDF files should be located on their own volume
LDF files should be located on their own volume
Pre-size MDFs and LDFs to minimize autogrowth
Use Instant File Initialization
Locate on its own volume
Keep recovery model to SIMPLE
Pre-size so autogrowth doesn’t have to happen
Set autogrowth to avoid many growth spurts,
use fixed amount.
Divide the tempdb into multiple files, so that the
number of files is about 50% to 100% of the
number of CPU cores your server has. Each file
should be the same size.
Auto Create Statistics: On
Auto Update Statistics: On
Auto Shrink: Off
PageVerify: Checksum (2005/2008)
Autogrowth: Use mainly for catching mistakes.
File growth should be managed manually. Use
fixed amount, not percentage growth.
Production databases should be set to FULL
Schedule jobs so they don’t interfere with
Ensure that jobs don’t overlap.
Don’t ever schedule automatic shrinking of
databases. If you must shrink a file, do it manually
and off hours, then rebuild indexes.
Don’t schedule an UPDATE STATISTICS job before or
after an INDEX REBUILD/REORGANIZE job. It is
redundant, and can actually reduce the quality of the
statistics (if run after).
Rebuild an index if it is heavily fragmented (>30%). In Enterprise
Edition, can perform online. If Standard Edition, can cause
blocking, and should ideally be done during slow/down times.
Reorganize an index if it is not heavily fragmented (>5% and <=
30%).This is an online operation and doesn’t use a lot of resources.
Use a fill factor large enough to prevent page splitting, but small
enough to prevent wasted space on disk and in memory. Use 100
for read-only tables, try 95 as a starting point for OLTP tables.
Ideally, you should only rebuild or reorganize indexes that need
rebuilding, especially for very large databases. Use
sys.dm_db_index_physical_stats to identify fragmentation.
If databases are small, or you don’t know how to identify which
indexes are fragmented, then consider running a nightly or weekly
job to rebuild or reorganize indexes in all of your user databases.
Run DBCCCHECKDB as often as you run full backups, which is
Create an appropriate job to run this command:
DBCC CHECKDB (‘DATABASE_NAME') WITH
Note: Use PHYSICAL_ONLY option for large or busy
Review results to look for problems. If you have a problem, you
want to find it as soon as possible to reduce the risk of data loss.
A restore is often the only way to fix many data corruption
Create a SQL Server Event Alert for all events
with a severity of 11 and higher (or at least 19
[fatal] and higher).
Have alert sent to e-mail address, or to your
texting e-mail address.
Don’t use the SA account for anything.
UseWindows Authentication security whenever
Don’t give users more permissions than they
need to perform their job.
Only log onto a SQL Server as a sysadmin if you
need to perform sysadmin tasks, otherwise use a
different account to log onto SQL Server.
Log off your SQL Server when done.
Create a job to perform full backups daily on all
system and user production databases, plus log
backups hourly (or similar variation).
Always backup using RESTORE WITHVERIFYONLY
to help verify backup integrity.
Keep full backup for at least several days, 7 or more
days is ideal.
Store backups securely and off-site.
If you have a limited backup window, or have limited
disk space, consider a third-party backup program
that does compression. Can be a big time saver.
You must create a document that outlines, step-
by-step, in great detail, how you will recover your
SQL Servers in the case of any problem, small or
You need to practice using the plan so you are
familiar with it and can implement it without
requiring any further research.
Keep Microsoft SQL Server’s Product Support
phone number handily available.
Before you make any change in a production SQL
Server, be sure you test it first in a test
NO EXCEPTIONS! I mean it! Really!
Monitor MDF and LDF file growth
Monitor Free Space
Monitor SQL Server and OS Logs
Document All Changes
MDF and LDF files should be managed manually.
To do this well, you must monitor file growth and
be aware of how much data is being added.
Be proactive. Plan early to add more space if
needed, don’t wait until it’s too late.
In SQL Server 2005, use “Standard Reports” to
help you monitor this.
In SQL Server 2008, use Performance Data
Collector to monitor this.
No disk should ever exceed 80% capacity.When
it does, performance drops, and you risk running
out of disk space.
Check this manually and record results
Use Performance Monitor and setup an alert
Use a third-party tool
Write your own tool
Daily, review SQL Server Event Logs
Daily, review SQL Server Logs
How to perform:
Manual check using EventViewer or SSMS
Have “Errors” e-mailed to you from EventViewer
Use third-party tool
Write your own tool
Daily, verify that all jobs have run successfully.
Keep in mind that sometimes, a job may claim to
be successful, but it failed in part or whole.
How to perform:
Have SQL ServerAgent send you a message
Use third-party tool
Write your own tool
If you do set up any of the many available alerts,
be sure you look at them.
Sometimes, it is easy to be complacent and to
The secret is to keep alerts to a minimum by
carefully creating the alerts, setting them up so
that only the most critical alerts are sent.
At the very minimum, perform a test restore on
at least one key production database, per SQL
Server instance, weekly.
The restore is best done on a test server, but if
not available, restore on production server using
different name. When restore is done, then
Monitor performance regularly, daily if
Identify potential problems early before they
become critical problems.
How to monitor:
SQL Server 2005 Performance Dashboard
SQL Server 2008 Performance Data Collector
Indexing needs of a database can change over time
as data changes, and as how data is queried
Every 1-3 months, perform a default Profiler trace on
your production servers, then use the trace as the
source for the Database EngineTuning Advisor to
help you identify missing indexes.
Remove unused indexes. Identify by using the
Using correct indexes is one of the key ways to get
better SQL Server performance.
Whether you are the only DBA, or one of many,
all SQL Server changes needs to be documented.
Acts as an audit trail (often required by many
Documentation helps you to troubleshoot
problems, and also acts as a repository of
information for future use.
Ideally, put documentation where is can be easily
accessed by all interested parties.
By focusing on the basics, you gain the following:
Better SQL Server performance
Higher SQL Server availability
Being proactive helps to you prevent being in a “crisis”
mode all the time
More time to focus on what is important to you
You become a better, more professional DBA
The total effect of following each and every
recommendation made today can be huge.