Are Your SQL Servers Healthy?

Derek Colley for www.mssqltips.com

Follow me: @dcolleySQL

http://uksqldba.blogspot.com
 Overview
• Your first day – welcome aboard!

• First steps –
– Check the backups
– What’s in the error log?
– Measuring performance here and now

• Dealing with disk space

– Disk space and file growths
– When to shrink your database files

Copy Right Information 2

 Overview Continued…
• Tuning your server settings
• Tuning your database settings
• Choosing your recovery model
• SQL Agent
– Who owns your jobs?
– Finding failed jobs
– Beat the NOC!
• Basic index maintenance
• Tidying up your security
• Q&A
Copy Right Information 3
 Check the Basics
• What to fix first?

• Backups –
– How are backups taken?
– Third-party, home-brew script, SQL Agent?
– How frequently?
– What about disaster recovery?

• DEMO – finding failed jobs

Copy Right Information 4

 Check the Basics
• Error logs
– Access in SSMS under Server -> Management -> SQL
Server Logs
– Typically the current log + 6 archive logs are kept. The
oldest log is overwritten.
– Logs will cycle when:
• - You tell them to.
(sp_cycle_errorlog / DBCC ERRORLOG)
• - You restart SQL Server / reboot the server
• Worth setting up a job specifically to do this

5
 Check the Basics
• Error logs
– Check logs for pressing matters
• Severity 16 + errors
– Login failures
• Severity 14
• Not always important BUT…
• Symptomatic of a problem elsewhere.
• Search and aggregate the error log…

– DEMO – Searching the error log

6
 Collecting Statistics
• Performance Monitor (perfmon)
– Use perfmon to get real-time stats
– Also use it to collect stats over time
– Has SQL Server-specific counters
– Data can be imported to SQL Server
– Data can be correlated with Profiler
– Data can be graphed in Excel

7
 Collecting Statistics
• Use perfmon to:
– Check CPU % pressure, check buffer cache hit ratio, get
throughput rate (batch requests/sec), get disk space, get
memory usage … etc.
– Hundreds of different counters to choose from
– Pick a set that suits you…
• I love performance tuning, so mine include some esoteric
ones like latch stats
• Build your own to suit your purposes – start with the basics (CPU, memory,
disk space) then include some specifics to suit your environment
• No right or wrong performance set – build your own, then save them as
templates.

8
 Disk Usage
• How large are your database files?
• Regular shrinking? If so, how often?
• WARNING:
– Shrinking data files is I/O intensive
(Especially for databases with LOB data)
– Shrinking data files mangles your indexes
(Rebuild them afterwards!)
– Sometimes it won’t work.
(Back up your database first!)

• DBCC LOGINFO shows your VLFs

9
 Disk Usage
• Check your file growth settings
• Too frequent – unnecessary I/O, heavy index
fragmentation
• Too infrequent – huge disk use in leaps and bounds,
gambling on free space
• One recent DB I checked had 250,000 batch
requests/sec and a growth event on average every
2.5 seconds (10MB) 
• If autogrow is disabled – good – however are you
sure you know how large your data will grow?

10
 Disk Usage
• What’s fastest?
• Ideal – NAND Flash or decent SSDs
• Have seen 24Gbps from local storage 
• Have also seen 100Kbps from iSCSI storage 
• Storing your data / log files –
– Now becoming redundant with new storage types
– SAN appliances available with hundreds of disks
– Fibre-attached storage and local Flash now normal
– However … principles remain solid…

11
 Disk Usage
• Ideal standard (YMMV)…
– Data files separated by filegroup on separate disks
– Transaction log file held separately, different disks
– TempDB files held separately, different disks
– Backup to NAS, backup server or tape/offsite storage
(Local retention of X days for quick access)
• Reality…
– Shared storage, VMs give virtual disks
– Bottlenecks on single NICs for attached storage
– Poor performance of misconfigured SANs
– Not enough disks or LUNs to go around

12
 Server Settings
• Turn on advanced settings:
EXEC sp_configure ‘show advanced options’, 1
RECONFIGURE WITH OVERRIDE
• Right click the server in SSMS -> Properties
• OR … EXEC sp_configure
• Many settings to customize
• Important: Max Server Memory
– You should cap this to suit your environment

– DEMO: Server Settings

13
 Database Settings
• From here, we can:
– Administer data files and filegroups
– Change settings in the database scope
• Language settings, page verify options, Service Broker options, etc.
– Configure database mirroring
– Configure transaction log shipping
– Change the recovery model
– Much more…
– Some settings require a restart of the instance

14
 Recovery Model
• Choose the right recovery model!
– Do you need full point-in-time recovery on your config DB?
– Are you backing up your transaction log regularly?
– If so, are you doing full database backups?
– How large is the transaction log getting?
– Consider using BULK LOGGED if many bulk operations
– Consider using SIMPLE if updates are infrequent and/or unimportant
– Easy to change – ALTER DATABASE x SET RECOVERY y

15
 SQL Agent
• Supplementary service to SQL Server
• Runs as a separate service for each instance
• Per instance, not per database
• Can do:
– Jobs – backups, recovery, SSIS packages, code block execution
– Alerting – lets you know when there’s a problem
– Inline SSIS through Maintenance Plans
– Has a separate log file and a set of system tables in msdb database
– Proxy configurations

16
 SQL Agent
• Use it to handle regular jobs
• Call stored procedures
• Execute data loads / purges / other DML activities
• Use it in conjunction with Database Mail for alerting

• DEMO – Setting up a purge job in SQL Agent

17
 SQL Agent
• Beat the NOC!
• Personal goal at every place I work …
– Can my SQL Server monitoring beat the Network Operations Center?
– If a database problem occurs – how quickly do I know about it?

• Easy solution – SQL Agent Alerts

• Uses Database Mail to alert when a high-severity incident occurs
• You can configure alerts based on severity or error number
• You can ‘chain’ your stored procedure error catching to raise alerts
designed to get your attention

18
 SQL Agent
• Basic concepts of alerting…
– Database Mail – this is the functionality that composes your emails including the
headers and sends them to the mail server
– Has callable procedures such as xp_sendmail (now deprecated in 2012) or
sp_send_dbmail
– Alert – single type of notification that flags when a particular event or class of event
occurs
– Operator – a recipient of a notification. Can be a real person, or a service email address,
or a pager number, or a net send address
– Hook your phone up to your email – and your phone will buzz before the NOC even call
you out!

19
 Basic Index Maintenance
• Indexes are like telephone directories
• Come in two main forms -
Clustered (data is organized in b-tree form)
Non-clustered (b-tree pointers to the data)
• Indexes can fragment –
When a new value is inserted causing a page split
As a result of certain operations, e.g. shrink file
With large index rows
• Natural process – indexes need care to work properly

20
 Basic Index Maintenance
• View fragmentation using DMVs
• Basic DMV is sys.dm_exec_index_physical_stats
– Takes 5 parameters
– Not particularly well-performing – single-threaded internal function
call, so be careful using on production
– Use the avg_fragmentation_in_percent and fragment_count columns
• Indexes can fragment –
– When a new value is inserted causing a page split
– As a result of certain operations, e.g. shrink file
– With large index rows
• Natural process – indexes need care to work properly

21
 Basic Index Maintenance
• Fix fragmentation using ALTER INDEX
 Also a component in the Maintenance Plan Toolbox
• Some creativity required here
– Don’t rebuild your indexes all at once
– Not every index needs rebuilding – try REORGANIZE
– Not every index is used
– Low fragmentation isn’t much to worry about
– Stagger your index rebuild job
– Keep an eye on long-term fragmentation stats

22
 Basic Index Maintenance
• Remove redundant indexes
 Why? Because they are considered by the query optimizer on
recompilation even if never used
 Why? Because they occupy valuable space that places a
burden on your backup, shrink and other admin ops
 Why? Because EVERY update to the base table causes an
update to the index (if the referenced columns are affected –
normally the case) – additional I/O
 HOWEVER – real world gotcha – some vendors/suppliers get
tetchy about this. Check with your supplier that schema
changes won’t invalidate your support agreement!
 DEMO – identifying redundant indexes

23
 Notes on Security
• Learn the basic ideas – server principals, database principals,
server roles, database roles, application roles, logins without
users, users without logins etc.
• Use role-based permissions wherever possible
• Do your developers have the sysadmin role?
• sa account – disable and rename
• Regularly review your recent failed logins
• Configure alerting to notify you if a login failure is recorded
from someone other than a ‘known offender’
• Ideally, use Windows logins, not SQL logins

24
 Notes on Security
• Ports – everyone knows SQL is on port 1433
• Enables hackers with access anywhere on your network to
launch DoS attacks on your SQL Server instance
• Open to brute force attacks on e.g. sa account
• Custom attacks such as buffer overflow by crafting strings of
disruptive packet data through this port
• Change the port number! SQL Server Configuration Manager
to do this
• Don’t forget to configure Windows Firewall
• Could be worth telling your network team!
• Configure client apps accordingly

25
 Q&A

Thank you for listening!

26