w





  
  w





2 You may be a part-time or full-time DBA
2 You may be a DBA Administrator or DBA
Developer
2 You may have less than one yearǯs experience as
a SQL Server DBA
2 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.
2 elps to optimize SQL Server performance
2 elps to maximum SQL Server availability
2 elps you to be proactive, not reactive
2 elps you to reduce being in Dzcrisisdz mode
2 Reduces your stress levels
2 Makes your manager happier
2 Give you more time to focus on what really
interests you
2 ðhile each best practice I discuss today might
seem small, the total effect of following each and
every recommendation can be huge.
2 By closely following each of these best practices,
SQL Server performance and availability can be
boosted by 20%, 50%, or even more.
2 Kheck & Verify
One-time checks to verify proper SQL Server instance
configuration
2 On-Going Tasks
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.
2 Installing & Upgrading SQL Server
2 General Konfiguration
2 Memory Konfiguration
2 User Data and Log File Management
2 Tempdb Management
2 Database Konfiguration Settings
2 Konfiguring JobsȄGeneral
2 Kreate Index Rebuilding/Reorganize Job
2 Kreate Data Korruption Detection Job
2 Set Up Alerts for Kritical Errors
2 Security Basics
2 Implement a Backup Strategy
2 Kreate a Disaster Recovery Plan
2 Test Everything
2 ðhen 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
2 ðhen 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.
2 Is the OS configured to optimize background
applications?
2 Need to have at least 20% free disk space on all
disk drives. Important for NTFS performance.
2 SQL Server instance should be a stand-alone
server with no other apps running on it.
2 Unnecessary services should be turned off.
2 Donǯt run antivirus software locally.
2 Ideally, use 64-bit hardware and the 64-bit
version of SQL Server.
2 If using 32-bit version, and if using 4 GB or more
of RAM, ensure than AðE memory is correctly
configured.
2 Remove physical file fragmentation before
adding new MDF or LDF files
2 The OS and SQL Server binaries should be on
their own volume
2 MDF files should be located on their own volume
2 LDF files should be located on their own volume
2 Pre-size MDFs and LDFs to minimize autogrowth
2 Use Instant File Initialization
2 Enable instant file initialization, prevents MDF files from
being zeroed out, saving time.
2 Speeds up KREATE DATABASE, ALTER DATABASE,
RESTORE DATABASE, Autogrowth.
2 Requires SQL Server 2005/2008, and ðindows Server
2003/2008
2 Instant file initialization is turned on if the the SQL
Server (MSSQLSERVER) service account has been
granted the SE_MANAGE_VOLUME_NAME permission.
Members of the ðindows Administrator group have this
right and can grant it to other users by adding them to
the Perform Volume Maintenance Tasks security policy.
2 Locate on its own volume
2 Keep recovery model to SIMPLE
2 Pre-size so autogrowth doesnǯt have to happen
2 Set autogrowth to avoid many growth spurts,
use fixed amount.
2 Divide the tempdb into multiple files, so that the
number of files is about 50% to 100% of the
number of KPU cores your server has. Each file
should be the same size.
2 Auto Kreate Statistics: On
2 Auto Update Statistics: On
2 Auto Shrink: Off
2 Page Verify: Khecksum (2005/2008)
2 Autogrowth: Use mainly for catching mistakes.
File growth should be managed manually. Use
fixed amount, not percentage growth.
2 Production databases should be set to FULL
REKOVERY.
2 Schedule jobs so they donǯt interfere with
production.
2 Ensure that jobs donǯt overlap.
2 Donǯt ever schedule automatic shrinking of
databases. If you must shrink a file, do it manually
and off hours, then rebuild indexes.
2 Donǯt schedule an UPDATE STATISTIKS job before or
after an INDEX REBUILD/REORGANIZE job. It is
redundant, and can actually reduce the quality of the
statistics (if run after).
2 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.
2 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.
2 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.
2 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.
2 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.
2 Run DBKK KEKKDB as often as you run full backups, which is
probably daily.
2 Kreate an appropriate job to run this command:

m



m m  
  








 !"#$%&'%(%)*+
!%,*-"#%.%/

2 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.
2 Kreate a SQL Server Event Alert for all events
with a severity of 11 and higher (or at least 19
[fatal] and higher).
2 ave alert sent to e-mail address, or to your
texting e-mail address.
2 Donǯt use the SA account for anything.
2 Use ðindows Authentication security whenever
possible.
2 Donǯt give users more permissions than they
need to perform their job.
2 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.
2 Log off your SQL Server when done.
2 Kreate a job to perform full backups daily on all
system and user production databases, plus log
backups hourly (or similar variation).
2 Always backup using RESTORE ðIT VERIFYONLY
to help verify backup integrity.
2 Keep full backup for at least several days, 7 or more
days is ideal.
2 Store backups securely and off-site.
2 If you have a limited backup window, or have limited
disk space, consider a third-party backup program
that does compression. Kan be a big time saver.
2 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.
2 You need to practice using the plan so you are
familiar with it and can implement it without
requiring any further research.
2 Keep Microsoft SQL Serverǯs Product Support
phone number handily available.
2 Before you make any change in a production SQL
Server, be sure you test it first in a test
environment.
2 NO EXKEPTIONS! I mean it! Really!
2 Monitor MDF and LDF file growth
2 Monitor Free Space
2 Monitor SQL Server and OS Logs
2 Monitor Jobs
2 Monitor Alerts
2 Test Backups
2 Monitor Performance
2 Analyze Indexes
2 Document All Khanges
2 MDF and LDF files should be managed manually.
2 To do this well, you must monitor file growth and
be aware of how much data is being added.
2 Be proactive. Plan early to add more space if
needed, donǯt wait until itǯs too late.
2 In SQL Server 2005, use DzStandard Reportsdz to
help you monitor this.
2 In SQL Server 2008, use Performance Data
Kollector to monitor this.
2 No disk should ever exceed 80% capacity. ðhen
it does, performance drops, and you risk running
out of disk space.
Kheck this manually and record results
Use Performance Monitor and setup an alert
Use a third-party tool
ðrite your own tool
2 Daily, review SQL Server Event Logs
Application
System
Security
2 Daily, review SQL Server Logs
2 ow to perform:
Manual check using Event Viewer or SSMS
ave DzErrorsdz e-mailed to you from Event Viewer
Use third-party tool
ðrite your own tool
2 Daily, verify that all jobs have run successfully.
2 Keep in mind that sometimes, a job may claim to
be successful, but it failed in part or whole.
2 ow to perform:
Manually check
ave SQL Server Agent send you a message
Use third-party tool
ðrite your own tool
2 If you do set up any of the many available alerts,
be sure you look at them.
2 Sometimes, it is easy to be complacent and to
ignore alerts.
2 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.
2 At the very minimum, perform a test restore on
at least one key production database, per SQL
Server instance, weekly.
2 The restore is best done on a test server, but if
not available, restore on production server using
different name. ðhen restore is done, then
remove.
2 Monitor performance regularly, daily if
necessary.
2 Identify potential problems early before they
become critical problems.
2 ow to monitor:
Performance Monitor
Profiler
SQL Server 2005 Performance Dashboard
SQL Server 2008 Performance Data Kollector
Third-Party Tools
2 Indexing needs of a database can change over time
as data changes, and as how data is queried
changes.
2 Every 1-3 months, perform a default Profiler trace on
your production servers, then use the trace as the
source for the Database Engine Tuning Advisor to
help you identify missing indexes.
2 Remove unused indexes. Identify by using the
sys.dm_db_index_usage_stats DMV
2 Using correct indexes is one of the key ways to get
better SQL Server performance.
m
0,)", 


0,)", 1m m,'')'#'2


)3-#'2 1 4
 "/)3-",

"#,5#'2 1"/#'2
"/"#,5",
 +/"#,5 "
+/)3- 
 4
 /)3-",% ')&16
m"/"#,5",  


/"#,5",
 +/,2,)"#,5*'(' 
/)3-", 1"/)3-",
m"/"#,5", 1/"#,5",
m,'')'", 10,)", 
m/)3-", 1"/)3-",
m )3-#'2
"/"#,5",
"#,5#'2 


2 ðhether you are the only DBA, or one of many,
all SQL Server changes needs to be documented.
2 Acts as an audit trail (often required by many
organizations).
2 Documentation helps you to troubleshoot
problems, and also acts as a repository of
information for future use.
2 Ideally, put documentation where is can be easily
accessed by all interested parties.
2 By focusing on the basics, you gain the following:
Better SQL Server performance
igher SQL Server availability
Being proactive helps to you prevent being in a Dzcrisisdz
mode all the time
More time to focus on what is important to you
You become a better, more professional DBA
2 The total effect of following each and every
recommendation made today can be huge.
2 Time for your questions
2 Kheck These Out:
www.SQLServerKentral.com
www.Simple-Talk.com
www.ExceptionalDBA.com
www.SQL-Server-Performance.com

2 Kontact me at:
bradmcgehee@hotmail.com