0% found this document useful (0 votes)
76 views

Healthy SQL Server

The document provides guidance on assessing the health of SQL Servers by checking backups, reviewing error logs and performance metrics, managing disk space and file growth, configuring server and database settings including recovery models, using SQL Agent for jobs and alerts, and performing basic index maintenance. It outlines various tasks and tools for evaluating server health and identifies issues to prioritize for resolution.

Uploaded by

CarlosDuPivato
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
76 views

Healthy SQL Server

The document provides guidance on assessing the health of SQL Servers by checking backups, reviewing error logs and performance metrics, managing disk space and file growth, configuring server and database settings including recovery models, using SQL Agent for jobs and alerts, and performing basic index maintenance. It outlines various tasks and tools for evaluating server health and identifies issues to prioritize for resolution.

Uploaded by

CarlosDuPivato
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 26

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

You might also like