datavail health check

7/14/2014 1www.datavail.com

About Your Presenter

Andy McDermid, SQL Server DBA, Datavail

Andy is a MCITP certified MS SQL DBA who delivers and manages delivery of DBA services to many diverse clients. He enjoys helping his clients by finding and deploying pragmatic and practical solutions for their database issues. Andy is always working to improve and expand his DBA skills and he likes to share the experience via writing. You can read more about his

work here http://andrewmcdermid.net.

http://www.andrewmcdermid.net/

How Regular SQL Health Checks Keep Your Database in Shape

Andy McDermid

SQL Server DBA, Datavail

[email protected]

NWOSSUG, Toledo

mailto:[email protected]


Your Chance To Win!

Make sure you fill out our presentation evaluation for your chance to win a new Xbox!


About Me

Andy McDermid• Broomfield, CO

• Principal SQL DBA at Datavail

Blog: http://www.datavail.com/blog |

Twitter: @oldskipole


About Datavail

Datavail is a managed service provider for databases• OracleDB2

• MySQL

• MS SQL

• Oracle & Oracle EBS

• No SQL

24x7x365 Coverage• U.S.-based DBA team

• Offshore team

Datavail DBAs work with many SQL servers Health Checks used to expose the issues

Recurring health checks keep servers up to standards

Frees up time so you can be more strategic


About This Presentation

SQL Health Checks• Achieve and maintain a standard of health for each

instance

The most common misconfigurations and set up issues• After thousands of health checks for many servers, these

are the top issues

• Review the function

• What is the default and is it appropriate?

• What might be the best settings to work towards a standard configuration

* These are best practices and you should make the best decision for

your specific environment.


Three Parts of This Presentation

1. Easy Picking

Server and database configurations, backups

2. Best Bang

Server configuration, index topics

3. Long Road

DB file location, size and growth, tempdb

configuration

Easy Picking


Server Configuration (sp_configure options)

Priority boost• Sets the SQL service to run at the highest priority -13

• Default is 0 – which is priority of 7

• May starve other processes – network and OS

• Depreciated



Recovery Interval• Approximately how long to recover database after a restart

or crash

• Default setting is 0 which means ~ 1 minute recovery time

• Affects checkpoint frequency so may be adjusted to reduce IO spikes


CPU affinity mask• Designates a set of logical CPU to an instance

• Default is 0 – no specific association

• Typical use case – stacked instances

• Three methods to change

– SQL Server Management Studio

– sp_configure ‘affinity mask’ (and ‘affinity64 mask’ if >64 CPU)

– ALTER SERVER CONFIGURATION SET PROCESS AFFINITY

• Avoid hard binding – enable trace flag 8002



Database Options

Auto close• DB ‘closes’ when there are no users connections

• Default is disabled

• Databases migrated from SQL 2000 MSDE

• Unnecessary overhead, depreciated

Auto shrink• Free DB space automatically returned to OS

• Default is disabled

• Always … no wait … never a good idea

• Causes fragmentation

• Manage file size and growth manually


Page verify• Checks page for corruption on each read

• Default is CHECKSUM but databases migrated from older versions may be using Torn Page Detection, None

• CHECKSUM vs Torn Page Detection

• CHECKSUM – the more complete option

Database Options


Backups

Missing• Missing full backups

• Missing transaction log backups

Misconfigured• Destination

• Low or no retention days

Failing• Reduce duration with Striped files or BUFFERCOUNT

• Plan to accommodate X days and account for growth


Policy Based Management

Easy method to keep an instance up to standard1. Define configuration ‘template’

2. Build it as a set of policies

3. Evaluate regularly (e.g. monthly checkups)

Best Bang



Maximum Memory

• Default is 2147483647

• Sets the buffer pool size (includes plan cache)

• Reserve for OS - rule of thumb

– 1 GB of RAM for the OS

– 1 GB for each 4 GB of RAM installed from 4–16 GB,

– 1 GB for every 8 GB RAM installed above 16 GB RAM

Minimum Memory• Dedicated instance- consider setting Min = Max


Memory Pressure• If Target Server Memory depressed below Maximum

Memory = external pressure

• If Total Server Memory depressed below Target Server Memory = internal pressure



Max Degree of Parallelism• Default is 0 – as many degrees as logical CPU

• May not be optimal for instances with many CPUs

• Microsoft recommends a per NUMA node calculation: CPU/NUMA node

– E.g. 16 CPU with 4 NUMA nodes = MDOP 4



Cost Threshold for Parallelism– Controls when a plan goes parallel

– Default is 5 (query cost)

– Query the plan cache for typical query costs and set CTFP accordingly



Baselines

Adjust SQL Server for maximum throughput

1. Configure instance to best practice

2. Gather baseline metrics

3. Evaluate

4. Tweak as necessary

5. Repeat


Index fragmentation• Maintenance plans

• Custom scripts to

– Ignore unused low page count, low fragmentation

– Threshold to reorganize or rebuild

– Maximum duration

Out of date statistics• Maintenance plans

• Custom scripts

Indexes


Indexes

Duplicate, overlapping, and unused Indexes• Drop or disable

• Impacts of index sprawl

– Database size on disk

– Wasted buffer pool

– Transaction log

Missing indexes• Easy to find, easy to fix

• Careful… but not too careful

Long Road


System and user database files on same disk

• DR concern

Data and log files on same disk

• IO profile of Data and Log files

San or VM or both• Does it even matter? Organizationally, yes.

Database Files


File growth too low• Default is 1MB data file

• May result in continuous growth

• External file fragmentation

• Set growth and size appropriately, enable instant file initialization

File growth in percent• Default is 10% for log files

• Large file results in large grows

• Small files results in small grows (many VLFs)

• Set growth and size appropriately

Database Files


Database Files

High VLF count• Log file fragmentation

• Log growth creates VLFs

– chunks less than 64MB and up to 64MB = 4 VLFs

– chunks larger than 64MB and up to 1GB = 8 VLFs

– chunks larger than 1GB = 16 VLFs

• Slow recovery times - restores, reboots, failovers, ect

• Rule of thumb – 512MB per VLF


Reducing VLFs1. Before you shrink the log file take note of the current size in

MB – assuming this is the correct size –or whatever your new size is

2. Shrink, backup, repeat as necessary to minimize VLFs. Works best in a time of quiet so the log can clear easily – if there are many many vlfs, if not you may need to make quite a few transaction log backups between shrinks since the shrink clears unused VLF blocks.

3. Divide 8000MB into the original size, round up, grow the log back that many times in multiples of 8000MB.

Database Files


Temp DB Files

• Default is one file and one log file

• GAM\SGAM contention

• Trace Flag 1118

• Rule of thumb – multiple files

– 1 per core up to 8,

– then add 4 more at a time up to logical CPU


Datavail Health Check

Based on PBM style pass/fail evaluation

Includes everything we discussed here and many more

Easy to read summary page

Comprehensive detail pages

Compliance per category

Customizable

Automated

Don’t forget to fill out the evaluation form for a chance to win an Xbox!

Questions?

For a copy of today’s presentation email

[email protected]

datavail health check

Documents

best bang server configuration

target server memory

total server memory

sql service

instance default

standard configuration

os default

sql servers health checks