Your SlideShare is downloading. ×
Sql server troubleshooting
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Sql server troubleshooting


Published on

Stacy Hein

Stacy Hein

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. SQL Server Troubleshooting and Performance Monitoring
    And throw in some performance tuning for giggles
  • 2. Intro
    Stacy Hein
    Database Guy
  • 3. Start with the Basics
    Start with the tools you know
    Logs, Logs, Logs
    Performance Monitor
    Some tools you might not know
    Profiler Traces
    Execution plans
    Toad or other third party applications
  • 4. Why do performance monitoring?
    Goes hand-in-hand with troubleshooting
    Identify bottlenecks (CPU, Memory, SQL queries, etc.)
    Planning (capacity management, end-of-life, etc.)
    Identify server/instance configuration issues
    Base-lining your servers
    Should start troubleshooting the SQL Server before the client says there is an issue.
  • 5. The Usual Suspects
    Database instance configuration
  • 6. Performance Counters
    Remember that performance counters should not be taken individually. Get the whole story.
    Most thresholds are dependent on the system and application.
    Ignore spikes. Sustained thresholds are the only ones that count.
  • 7. Memory
    A good place to start generally.
    64 bit has helped with both memory and processor bottlenecks.
    More is good – always.
  • 8. Memory Performance Counters
    Memory: Available Bytes
    Key counter especially when used with others.
    Memory: Pages / sec
    Hard page faults – going to disk to get it.
    VMM goes to pagefile to retrieve.
    Above 20 suggests possible memory issue.
    Memory: Page Faults / Sec
    Sum of hard an soft page faults
  • 9. Memory Performance Counters
    Page File: % Usage
    Also useful with the other counters.
    Some rules for the pagefile
    Move from system disk
    Put on more than one drive if possible
    Make it 2 times the size of the physical RAM in the server
  • 10. Processor Performance Counters
    Processor:% Processor Time
    Total processing time for non-idle thread
    80-90% means need processor
    Processor: %User Time
    Total time used for executing user processes (e.g. SQL)
    System: Processor Queue
    Over 2 = bad
    Consider how many cores and divide total by number of cores
  • 11. Disk Performance Counters
    Physical disk
    PhysicalDisk: Avg. Read Queue Length  Should be less than  2
    PhysicalDisk: Avg. Write Queue Length  Should be less than 2
    PhysicalDisk: % Disk Time  more than 50% indicates a bottleneck
  • 12. Disk Performance Counters
    Logical Disk
    SQL Server:BufferManager:Page reads/sec
    SQL Server reading pages from disk. If you are near your hardware maximums for this counter tune your database by adding indexes, redesign queries, etc.
    SQL Server:BufferManager:Page writes/sec
    SQL Server writing pages to disk. If you are near your hardware maximums for this counter tune your database by adding indexes, redesign queries, etc.
  • 13. Networking Performance Counters
    Network Interface Bytes Total/sec
    Network Interface Bytes Sent/sec
    Network Interface Bytes Received/sec
    Network Interface Current Bandwidth5
    Don’t usually have a networking issue that is not the cable, the NIC, or route/rule issues.
  • 14. Dynamic Management Views and Functions
    Can get performance counter data from these.
    Is a snapshot not continuous
    Common ones used
    sys.dm_io_virtual_file_stats - function
  • 15. Trace Flags
    Used in determining deadlocks (in this case anyway)
    Reports deadlock information formatted by each node involved in the deadlock
    formats deadlock information, first by processes and then by resources
    Use DBCC TRACEON to set
  • 16. Profiler is your Friend
    Can execute and capture trace information for all transactions running on SQL server instance.
    Can isolate transactions you need to capture.
  • 17. Database Instance Configuration
    Can affect server performance
    Memory settings, processor affinity settings, affinity masks, AWE setting (for 32 bit instances), etc.
    If you are going to change your settings, understand the instances role
  • 18. Instance Roles
    High Write Instance
    The database and log disk should be RAID 10 and separated on different physical volumes.
    The logical and physical model of the database is important. High write tables should be on their own partitions. This is also be true for very large, clustered indexes.
    Tempdb should be on its own RAID 10 partition and should have one data file for each core dedicated to SQL Server.
    Although disk is usually the primary issue with a high write system, put as much RAM as you can in this system.
  • 19. Instance Roles
    High Read Instance (Reporting?)
    Memory, Memory, Memory is the most important component to a read-intensive system. The more you have the more that can be accessed in memory and not read from disk.
    Tempdb should be on its own RAID 10 partition and should have one data file for each core dedicated to SQL Server. If you are doing massive reads, you are probably doing calculations for reporting. This operations are handled in tempdb now in SQL Server 2005 and forward.
    Although memory is the key to a system that does massive read operations, if you can afford it, make the database and log file partitions RAID 10 for when you would need to access them.
  • 20. Instance Roles
    If your system is a hybrid the defaults should work for the server. If not, tweak design and system settings as necessary careful to consider what the instance might be processing (i.e. more reads or more writes).
  • 21. Other Keys to Troubleshooting
    Understand the data and applications on the instance
    The physical and logical design of the database coupled with the system setting will go far in establishing a high performing instance/server.
    Well designed queries are also
  • 22. Tuning Queries
    Execution Plans
    Third party apps
    Toad for SQL Server
  • 23. Tuning Queries
    Rules for code creation
    Use procedures for the repetitive queries
    Avoid cursors
    Reduces the use of temp tables
    Return only the rows an app needs
    Use the schema when naming the object
    Do all DDL at top of procedures
    Use ANSI JOIN language
    Look for ANSI SET commands in your code
  • 24. Maintenance
    Database maintenance is key to mitigating some performance problems.
    Backups for obvious reasons
    Index fragmentation can cause issues for the server.
    UPDATE STATISTICS - depends on your application.
    Be careful there is a performance trade off for recompiling queries.
    Maintenance is a key component to the preventative side of server support.