Brad M. McGehee discussed SQL Server best practices for DBAs. He began by noting that DBAs can have varying levels of experience. The best practices presented are aimed at optimizing performance, availability, and reducing stress. Following the recommendations closely could boost SQL Server performance and availability by 20-50% or more. The presentation covered topics such as installation, configuration, backups, monitoring, and disaster recovery. McGehee emphasized that testing changes is critical and there may be exceptions to some rules depending on individual environments.

1. Brad M. McGehee
SQL Server MVP
Director of DBA Education
Red Gate Software

2.  You may be a part-time or full-time DBA
 You may be a DBA Administrator or DBA
Developer
 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.

3.  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
interests you

4.  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.

5.  Check &Verify
 One-time checks to verify proper SQL Server instance
configuration
 On-GoingTasks
 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.

6.  Installing & Upgrading SQL Server
 General Configuration
 Memory Configuration
 User Data and Log File Management
 Tempdb Management
 Database Configuration Settings
 Configuring Jobs—General
 Create Index Rebuilding/Reorganize Job
 Create Data Corruption Detection Job
 Set Up Alerts for Critical Errors
 Security Basics
 Implement a Backup Strategy
 Create a Disaster Recovery Plan
 Test Everything

7.  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.

8.  Is the OS configured to optimize background
applications?
 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.

9.  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
configured.

10.  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

11.  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.

12.  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
RECOVERY.

13.  Schedule jobs so they don’t interfere with
production.
 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).

14.  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.

15.  Run DBCCCHECKDB as often as you run full backups, which is
probably daily.
 Create an appropriate job to run this command:
DBCC CHECKDB (‘DATABASE_NAME') WITH
NO_INFOMSGS, ALL_ERRORMSGS;
Note: Use PHYSICAL_ONLY option for large or busy
production servers.
 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
problems.

16.  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.

17.  Don’t use the SA account for anything.
 UseWindows Authentication security whenever
possible.
 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.

18.  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.

19.  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
large.
 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.

20.  Before you make any change in a production SQL
Server, be sure you test it first in a test
environment.
 NO EXCEPTIONS! I mean it! Really!

21.  Monitor MDF and LDF file growth
 Monitor Free Space
 Monitor SQL Server and OS Logs
 Monitor Jobs
 Monitor Alerts
 Test Backups
 Monitor Performance
 Analyze Indexes
 Document All Changes

22.  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.

23.  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

24.  Daily, review SQL Server Event Logs
 Application
 System
 Security
 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

25.  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:
 Manually check
 Have SQL ServerAgent send you a message
 Use third-party tool
 Write your own tool

26.  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
ignore alerts.
 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.

27.  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
remove.

28.  Monitor performance regularly, daily if
necessary.
 Identify potential problems early before they
become critical problems.
 How to monitor:
 Performance Monitor
 Profiler
 SQL Server 2005 Performance Dashboard
 SQL Server 2008 Performance Data Collector
 Third-PartyTools

29.  Indexing needs of a database can change over time
as data changes, and as how data is queried
changes.
 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
sys.dm_db_index_usage_stats DMV
 Using correct indexes is one of the key ways to get
better SQL Server performance.

30.  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
organizations).
 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.

31.  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.

32.  Time for your questions

33.  CheckThese Out:
 www.SQLServerCentral.com
 www.Simple-Talk.com
 www.ExceptionalDBA.com
 www.SQL-Server-Performance.com
 Contact me at:
 bradmcgehee@hotmail.com