By Raluca Marcu
Performance Tuning And Optimization Microsoft SQL Database
About me…
Education & Certifications
Experience - MSSQL DBA & Dev - 6+ years
Contact
Performance Issues
Logical Optimization
Administrative Optimization System Configurations Capacity Planning Monitoring & Maintenance – Indexes & Statistics Maintenance
DB Architecture DB Design Coding – Refactoring TSQL
Common Symptoms Common Causes Tools to use
Performance Issues - Common SymptomsCPU bottlenecks
– Identify occasional peaks in processor vs. processor is constantly under pressure
Memory bottlenecks– Can result in slow application responsiveness, overall
system slowdown, or even application crashingNetwork bottlenecks
– Hard to recognize and easy to confuseI/O bottlenecks
– Manifested through long response times, application slowdowns and tasks time-outs
Slow running queries
Performance Issues - Common CausesCPU bottlenecks
– Insufficient hardware resources– Badly designed processes -> Query tuning, improving execution
plans, and system reconfigurationMemory bottlenecks
– Limitations in available memory and memory pressure – Poor indexing (table scans)
Network bottlenecks– Overload on a server or network -> data cannot flow as expected
I/O bottlenecks– Caused by slow hardware used, bad storage solution design,
configuration– Unnecessary requests made by a database -> affects I/O traffic– Frequent index scans, inefficient queries, and out of date statistics
Slow running queries– Missing indexes, poor execution plans, bad application and schema
design
Performance Issues – Tools to use: DMVsProcessor Pressure -> sys.dm_os_performance_counters
• counter type -> values shown are cumulative since the last SQL Server start => re-run in about 10 seconds
• Batch Requests/sec -> depends on hardware used -> should be under 1000• SQL Compilations/sec -> less than 10% of Batch Requests/sec • SQL Re-Compilations/sec -> less than 10% of SQL Compilations/sec• Checkpoint pages/sec and Lazy writes/sec -> indicate whether dirty pages are flushed to disk too
often• Lazy Writes/sec -> value should be below 20; value is constantly above => check Page Life
Expectancy -> Values < 300 seconds => memory pressure
Performance Issues – Tools to use: DMVs
CPU performance bottlenecks -> sys.dm_os_wait_stats
Performance Issues – Tools to usePerformance MonitorCounters Description Reco
mmended value
Issue
Processor Time
CPU Time <80% constantly higher than 80% => processor is under pressure
Memory Available KB
Available Memory > 200 MB
< 100 MB for long time => insufficient memory on the server
Pages/sec shows the rate at which the pages are written from disk to RAM and read from RAM to disk
> 50 >50 => intensive memory activity and possible overhead and memory pressure
Buffer Cache Hit Ratio
shows the ratio of the data pages found and read from the SQL Server buffer cache and all data page requests
> 90 If a page doesn’t exist in the buffer cache, it has to be read disk, which downgrades performance
Average Disk Queue Length
the average number of I/O operations that are waiting to be written to or read from disk and the number of currently processed reads and writes
< 2 per individual disk
higher values => I/O bottlenecks
Average Disk Sec/Read
the average time in seconds needed to read data from disk
< 8ms > 20ms => serious I/O issue
Average Disk Sec/Write
the average time in seconds needed to write data to disk
< 1ms > 4ms => bad performance
Performance Issues – Tools to use
SQL Server Profiler– Which queries, functions and stored procedures were executed– Track deadlocks
Administration Optimization – System Configurations
■ Install SQL Server on a 64bit system (never 32bit)■ Max Server Memory – 80% -> 90%■ Cost Threshold for Parallelism – between 20 and
50■ Transactional Log -> VLFs, default value, default
auto-growth, maintenance, shrink
Administration Optimization – Capacity Planning
■Random I/O separated from Sequential I/O■Separate large indexes and/or specific
tables to separate disks■Data partitioning■Database auto-growth
Monitoring & Maintenance – Indexes & Statistics Maintenance
■Maintenance Solution – Ola Hallengren (Free Solution)
■Indexes■Statistics - DBCC SHOW_STATISTICS ■Backup & Recovery Strategies – RPO &
RTO– Always -> Create the recovery strategy and then work
towards the Backups
Logical Optimization – DB Architecture■Data access
– Proper indexing and defragmentation - Database Tuning Advisor's
– Move TSQL code from app into db – no ORMs– Identify inefficient TSQL, re-factor
■Scale-up vs scale-out:– https://www.youtube.com/watch?
v=kZOREEkYJKs
Logical Optimization – DB Design
1NF (first Normal Form)Eliminate duplicative columns from the same table.Create separate tables for each group of related data and identify each row with a unique column or set of columns (the primary key).
2NF (second Normal Form)Meet the requirements of 1NF.Remove subsets of data that apply to multiple rows of a table and place them in separate tables.Create relationships between these new tables and their predecessors through the use of foreign keys.
3NF (third Normal Form)Meet the requirements of 2NF.Remove columns that are not dependent upon the primary key.
Normalization • 5 (+1) normal forms, noted 1NF to 5NF (+ 3.5NF or BCNF)• 3NF – eliminate redundant data, ensure data integrity and
atomicity, eliminate data modification anomalies
Logical Optimization – DB Design
De-Normalize:– Performance – in practice a fully normalized database
may incur costly queries for assembling the required data.
– Complexity – fully normalizing a database may lead to a big number of tables, making the database difficult to understand and maintain.
– Project requirements – for some specific project types the effort of elaborating a good design is not justified.
Caution: when de-normalizing a database, extra care must be taken about data integrity.
Logical Optimization – Coding
■ Query Plan:– Actual Query Plan vs. Estimated Query Plan
– DBCC FREEPROCCACHE– Live example
Logical Optimization – Coding
■ Query Plan:– Statistics & Indexes
Logical Optimization – Coding
Logical Optimization – Coding Best PracticesTriggers
– Avoid using them– Never use the same trigger for different triggering events (Insert,
Update, Delete)Views
– Use SCHEMABINNDING option -> users will not modify the tables schema
– Use views for writing queries that access columns from multiple tablesTransactions
– Handle errors (Try-Catch Block)– Try to avoid nested transactions– Reduce the time period of resource locking (begin -> commit/rollback
fast)Stored procedures
– Do not use "SP_XXX" as a naming convention– Use "Set Nocount On" to eliminate extra network trip– Use WITH RECOMPILE clause (EXECUTE statement-first time) when the
index structure changes
Thank you…
Q & A Time!
Q&A…1. Big data SQL server2. How can get the best performing in .Net MVC3. The Cluster deployment model for SQL? Optimal model with a
hardware resources sufficient for the problems need large data storage, much access read-write – cluster failover
4. According to my experience there is a pretty common problem during removal must anticipate that retrieve data for a list such as a list of products. Here the problem is that we often have to run through a loop to get the data for each product and information relating to the product eg price, variant, size, images .... This will create numerous query. The usual way to do it will not always try to put away once all the data of all such products take the price of all products one by one, taking all the variant of a turn and when I need to show to get this data from memory without recall db This will limit the number of queries to the database. But to do so beautiful, are not a simple problem? Speakers said there are ways to do this are not you?
Top Related