Healthy SQL Server
Healthy SQL Server
• First steps –
– Check the backups
– What’s in the error log?
– Measuring performance here and now
• Backups –
– How are backups taken?
– Third-party, home-brew script, SQL Agent?
– How frequently?
– What about disaster recovery?
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…
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!)
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
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
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?
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
26