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

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

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.

Check & Verify One-time checks to verify proper SQL Server instance

configuration

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.

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

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

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.

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

Page Verify: 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.

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

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 DBCC CHECKDB 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.

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.

Use Windows 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.

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 WITH VERIFYONLY 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 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.

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!

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

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 Application

System

Security

Daily, review SQL Server Logs

How to perform: Manual check using Event Viewer or SSMS

Have “Errors” e-mailed to you from Event Viewer

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:

Manually check

Have SQL Server Agent 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 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.

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.

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-Party Tools

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 Engine Tuning 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.

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.

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.

Time for your questions

Check These Out:

www.SQLServerCentral.com

www.Simple-Talk.com

www.ExceptionalDBA.com

www.SQL-Server-Performance.com

Contact me at:

bradmcgehee@hotmail.com