SEAS06 - SQL Server 2005 OLTP Best Practices 1 SEAS 2006 SQL Server 2005 OLTP Best Practices.
-
Upload
karin-kennedy -
Category
Documents
-
view
224 -
download
0
Transcript of SEAS06 - SQL Server 2005 OLTP Best Practices 1 SEAS 2006 SQL Server 2005 OLTP Best Practices.
SEAS06 - SQL Server 2005 OLTP Best Practices 1
SEAS 2006SQL Server 2005OLTP Best Practices
SEAS06 - SQL Server 2005 OLTP Best Practices 2
AgendaAgenda
Overview performance objectives of OLTPDesign, Techniques and Best practices
TransactionsConcurrency Index maintenance issues
SQL Server 2005 OLTP Implementation findingsIdentifying Performance issues
Resource utilizationOptimization
Estimation and query plan selectionPlan re-use & Recompilation
Useful countersOLTP Performance Blueprint
Summary
SEAS06 - SQL Server 2005 OLTP Best Practices 3
OverviewOLTP GoalsOverviewOLTP Goals
OLTP performance objectives Fast transactions
Set operations preferable over CursorsIndexes allow granular data access and locking
Maximizing CPU resourcesHigh plan re-useLow re-compilation
Maximizing IO resourcesMinimize joinsFast transaction log (writelog)Small IOs for Data (io_completion)See SEAS06PT (Performance Tuning) deck
Exploit L2 Cache – SQL Server 2005 loves L2/L3 cache
SEAS06 - SQL Server 2005 OLTP Best Practices 4
AgendaAgenda
Overview performance objectives of OLTPDesign, Techniques and Best practices
TransactionsConcurrencyIndex maintenance issues
SQL Server 2005 OLTP implementation findingsIdentifying Performance issues
Resource utilizationOptimization
Estimation and query plan selectionPlan re-use & Recompilation
Useful countersOLTP Performance Blueprint
Summary
SEAS06 - SQL Server 2005 OLTP Best Practices 5
Design, Techniques, Best Practices Impact on Performance
Design, Techniques, Best Practices Impact on Performance
Application & Database Design and T-SQL have major impact on performance‘Typical’ performance tuning plays smaller rolePerformance monitoring can point out some deficiencies (or opportunities for improvement!) throughout application life cycle.
App Design
DB Design SQL Hardware tuning
PerformanceMonitoring workload changes
25% 25% 20% 10% 20%
SEAS06 - SQL Server 2005 OLTP Best Practices 6
Design: TransactionsDesign: TransactionsConsistency and Concurrency
Consider new Isolation levels RCSI and SI to improve SQL Server 2000 behavior of readers blocking writers and writers blocking readers.Short transactions are key for high concurrency in OLTP. SQL Server will err towards row level locking and improve concurrency
PerformanceSQL Server is great at inserts, very good at updates and not as good at deletes
Can use partitioning to avoid deletesSQL Server 2005 zero costs plans can help
SEAS06 - SQL Server 2005 OLTP Best Practices 7
Design: Indexes 4 RecommendationsDesign: Indexes 4 Recommendations
Avoid long (or wide) clustered index key if table has nonclustered (N/C) indexes
Leaf of Nonclustered index uses the clustered index key (primary key) to locate the data row
Since a wide clustered index key increases size of N/C, (covered) nonclustered range scans results in more IO
Avoid high volume Clustered index seeks & RID lookups (N/C)Clustered index benefits
high volume lookups (avoids RID lookups)Range scans – access to entire data row
Non-clustered index benefitsQuery coveringCan be used to avoids sorts
SEAS06 - SQL Server 2005 OLTP Best Practices 8
Index DMVs & DMFsSee details in SEAS06PT: SQL 2005 Perf TuningIndex DMVs & DMFsSee details in SEAS06PT: SQL 2005 Perf Tuning
Missing indexesSys.dm_db_missing_index_group_statsSys.dm_db_missing_index_groupsSys.dm_db_missing_index_detailsSys.dm_exec_query_plan(plan_handle) - Look for <MissingIndexes>
Unused indexesSys.dm_db_index_usage_stats
Index Access, Blocks, Contention e.g. waits
Sys.dm_db_index_operational_stats()Sys.dm_db_index_physical_stats()
SEAS06 - SQL Server 2005 OLTP Best Practices 9
Example: Are my indexes being used?Example: Are my indexes being used?
Declare @dbid intSelect @dbid = db_id('Northwind')
Select objectname=object_name(i.object_id), indexname=i.name, i.index_id
from sys.indexes i, sys.objects o where
objectproperty(o.object_id,'IsUserTable') = 1 and i.index_id NOT IN (select s.index_id from sys.dm_db_index_usage_stats s where s.object_id=i.object_id and i.index_id=s.index_id and database_id = @dbid )
and o.object_id = i.object_id order by objectname,i.index_id,indexname asc
SEAS06 - SQL Server 2005 OLTP Best Practices 10
AgendaAgenda
Overview performance objectives of OLTPDesign, Techniques and Best practices
TransactionsConcurrencyIndex maintenance issues
SQL Server 2005 OLTP Implementation findingsIdentifying Performance issues
Resource utilizationOptimization
Estimation and query plan selectionPlan re-use & Recompilation
Useful countersOLTP Performance Blueprint
Summary
SEAS06 - SQL Server 2005 OLTP Best Practices 11
SQL Server 2005 OLTP Implementation findings:SQL Server 2005 OLTP
Implementation findings:
Procedure Cache GrowthZero costs plans can fill up cache quickly with high volume dynamic transactionsSQL 2005 plan cache changes resulting in
Out of Memory errorsWorse performance on 64-bit vs. 32-bit platformWorse performance on SQL 2005 vs. SQL 2000
Resolution/WorkaroundSP2 addresses 4 main areas:
We evict plans much fasterWe cap the procedure cache much more aggressively on high-end machines leaving more memory for data pagesCertain zero cost plans do not get cached at all
SEAS06 - SQL Server 2005 OLTP Best Practices 12
SQL Server 2005 OLTP Implementation findings:SQL Server 2005 OLTP
Implementation findings:
Parameter Sniffing/Forced parameterization
Many workloads generate generic SQL based on application end-user inputParameterized queries are generally used to aviod excessive compilation against all database platformsFirst invocation with non-representive parameter values can cause major problems
Resolution/WorkaroundRun the workload with most popular plan on startup
SEAS06 - SQL Server 2005 OLTP Best Practices 1313
SQL Server 2005 OLTP Implementation findings:SQL Server 2005 OLTP
Implementation findings:
SQL Server 2005 can use more CPUIn-place application upgrades from SS2K to SS2K5 (same hardware) often result in 20-30% more CPU utilizationEspecially noticeable with batch or serialized operationsThe problem is primarily attributed to:
Higher query plan compilation costsMore code/larger working set
Resolution/WorkaroundIn some cases enabling ‘Forced Parameterization’ helpsTrue mostly with older Hardware with small L2/L3 cache
SEAS06 - SQL Server 2005 OLTP Best Practices 14
SQL Server 2005 OLTP Implementation findings:SQL Server 2005 OLTP
Implementation findings:
Data manipulation of partition table can be more costly than non-partition table
Partitioned tables keep a separate rowmodctr for every partitionThis costs a lot of CPU cycles for checking the value, which increases with each additional partition
Resolution/WorkaroundTurn auto statistics off Add statistics updates to maintenance schedule
SEAS06 - SQL Server 2005 OLTP Best Practices 1515
SQL Server 2005 OLTP Implementation findings:SQL Server 2005 OLTP
Implementation findings:
Excessive files in a databaseFiles are opened serially after recovery restartAdversely impacts large system availabilityBackup of a database containing lots of files/filegroups can be slower
Resolution/WorkaroundMore files for TempDB and Log is okReasonable amount of files for data and indexes (depending on size of file group)
SEAS06 - SQL Server 2005 OLTP Best Practices 16
AgendaAgenda
Overview performance objectives of OLTPDesign, Techniques and Best practices
TransactionsConcurrencyDatabase design
Normalization, Denormalization, Index maintenance issues
SQL Server OLTP implementation findingsIdentifying Performance issues
Resource utilizationOptimization
Estimation and query plan selectionPlan re-use & Recompilation
Useful countersOLTP Performance Blueprint
Summary
SEAS06 - SQL Server 2005 OLTP Best Practices 17
Performance issuesWhat hinders Performance?Performance issuesWhat hinders Performance?
QueuingMultiple types of queues (memory, CPU, IO)
Resource limitationsBad configuration
Hardware & Software
Bad Queries & DesignBadly written, poorly designed
Poor indexingNot relevant to workload or lack of
Inappropriate optimizer plansToo many round trips from client
SEAS06 - SQL Server 2005 OLTP Best Practices 18
Performance issuesShared Resources, Scalability LimitsPerformance issuesShared Resources, Scalability Limits
Database shared resourcesDatabase performance is limited by maximum Transaction Log throughput, only ONE possible transaction log per database!Can be resolved by
adding multiple spindlesIncreasing number of databases to provide multiple transaction logs
Server shared resourcesTEMPDB
Tempdb in memory vs. less memory for buffer cacheMemory (64-bit) flat (see SEAS06 SQLOS & VLDB)Memory (32-bit)
Only data cache can live in 32-bit AWEProc cache, locks, user connections, sorting restricted to lower 2-3GB of address space
Can be resolved by partitioning over multiple instances
Machine/node shared resourcesCPU and networkingCan be resolved by partitioning over multiple servers
SEAS06 - SQL Server 2005 OLTP Best Practices 19
Performance IssuesScalability RulesPerformance IssuesScalability Rules
Database scalability is limited by the maximum throughput of the transaction log
Disk I/OInstance scalability is limited by shared “process” level resources
MemoryServer scalability is limited by shared “server”/”machine” level resources
CPU (incl. L1 & L2 cache)Network bandwidth
SEAS06 - SQL Server 2005 OLTP Best Practices 20
Performance IssuesDisk I/OPerformance IssuesDisk I/O
Determine I/O patternWrites
Transaction Log (~100% sequential)Lazy Writer (random)
ReadRandom vs. Sequential
Establish disk I/O baseline or SLA outside SQL Server, using:
SQLIO or IOMeter (Intel, public domain)Special cases:
Transaction log1 Tempdb file for each cpuMax Parallel BCP load = 1 BCP / CPU
Into SQL Server 2005 partitioned tables
SEAS06 - SQL Server 2005 OLTP Best Practices 21
Performance IssuesI/O Bottlenecks 1
Performance IssuesI/O Bottlenecks 1
I/O bottlenecks are typically easy to findBe very careful with the transaction log
Beyond 12 to 15 spindles doesn’t buy muchKeep on separate physical disks for recoveryMake RAID 10
Beware of write cost on RAID5: In RAID 5 each write has to logically read old data + old parity (to compute parity) and write new data and new parityEach RAID5 write = 2 READS + 2 WRITES !
However: Disk guys work real hard to optimize this
Recent bulk load tests showed >50% degradation comparing RAID 0+1 vs. RAID 5
SEAS06 - SQL Server 2005 OLTP Best Practices 22
Performance IssuesI/O Bottlenecks 2
Performance IssuesI/O Bottlenecks 2
Disk subsystem based on I/O throughput required, not size of DB
E.g. 1TB data / 72GB per drive = 14 drives.Will 14 drives provide sufficient IO throughput?Recommend more smaller drivesRandom (OLTP) vs. sequential (Reporting) IO/secCache on controller – tuned for % read or write
Consider all workloadsOLTP (typically random IOs)Batch (could be random or sequential depending on the type of work done)
Use SQLIO to measure your max throughput rating for your subsystem.
SEAS06 - SQL Server 2005 OLTP Best Practices 23
Performance IssuesOptimizing for the logPerformance IssuesOptimizing for the log
Profile the log diskHow many writes / second can your disk sustain?
Keep the log disk purely for the logKeeps the disk heads writing sequentially minimizing seeks
Beware of unprotected write back caches
If power fails, you could lose the entire database – not just the last couple of transactions!Check with your SAN / Disk controller vendor
SEAS06 - SQL Server 2005 OLTP Best Practices 24
Performance IssuesBlockingPerformance IssuesBlocking
Blocking between sessions can occur due to a combination of incompatible locks and waits on resourcesTools
Use Profiler block process report and other tools to find blocking processesDMVs
New blocking solutionsSnapshot Isolation - Row Versioning
See SEAS06PT for locking discussion
SEAS06 - SQL Server 2005 OLTP Best Practices 25
Performance IssuesHow to Evaluate BlockingPerformance IssuesHow to Evaluate Blocking
DMF sys.dm_db_index_operational_stats() identifies the contention points
Row locks countsRow lock waits countsTotal wait time for blocksCompute blocking percentage and average wait timesSee SEAS06PT Indexes & Row Lock Waits.sql
Sys.dm_os_waiting_tasks
SEAS06 - SQL Server 2005 OLTP Best Practices 26
Finding Resource Bottlenecks Identifying Blocking & Concurrency issuesFinding Resource Bottlenecks Identifying Blocking & Concurrency issues
Sp_block_info – lists real time blocksTrace – for historical analysis Capture long blocks using the Trace
Event “Block Process Report” Sp_configure “blocked process threshold”,15
(seconds) This is covered in SEAS06PT
If blocking is still an issue, Consider row versioning to minimize read / write contention
SEAS06 - SQL Server 2005 OLTP Best Practices 27
Performance Issuesrow versioning: new blocking solutionsPerformance Issuesrow versioning: new blocking solutions
Row versioning-based isolation levelsAlways read a committed value (as compared with dirty reads)Reads do not acquire shared (S) locksimprove concurrency by eliminating blocks for read / write operations. Tempdb overhead
Stores versions of previously committed row data
RCSIAdvantage: NO APPLICATION CHANGES !Transaction Isolation Level Read Committed & Read_Committed_Snapshot ON database optionStatement level read consistency
Transaction Isolation Level SnapshotTransaction level read consistency
Database Snapshot
SEAS06 - SQL Server 2005 OLTP Best Practices 28
Performance & ResourcesTempDB UsagePerformance & ResourcesTempDB Usage
Tempdb usage is much more common in SS2005
Tempdb management must be a configuration priority for DBAs
The following uses Tempdb w/ SS20051 DBCC CHECKDB - small change2 Internal objects: work file (hash join, SORT_IN_TEMPDB) - CTEs 3 Internal objects: work table (cursor, spool) - small changes4 Large object (LOB) variables 5 Service Broker 6 Temporary objects: global/local temp table, table variables 7 Temporary objects: SPs and cursors - small changes8 Version store: General 9 Version store: MARS 10 Version store: Online index 11 Version store: Row version based isolation levels 12 Version store: Triggers 13 XML
SEAS06 - SQL Server 2005 OLTP Best Practices 29
Performance IssuesTempDB capacity planningPerformance IssuesTempDB capacity planning
On line index: 2x-3x size of index – Sort size, temp index and rollback
Versioning: [Size of Version Store] = 2 *[Version store data generated per minute] *[Longest running time (minutes) of your transaction] * number of concurrent transactions/usersNote: Version store data generated per minute and version store size are now perfmon parameters
Recommendation repeated: Be sure to tune TempDB for proper sizing as well as performance
SEAS06 - SQL Server 2005 OLTP Best Practices 30
Performance IssuesTempdb – Trace Flag 1118Performance IssuesTempdb – Trace Flag 1118
Reduces sgam contentionStill needed in 2005 if you have DDL statements for Create Table and Create Index in stored procedures that are called many times (high volume).
SEAS06 - SQL Server 2005 OLTP Best Practices 31
Performance & ResourcesTempdb – Space UsedPerformance & ResourcesTempdb – Space Used
select
sum(user_object_reserved_page_count)*8 as user_objects_kb,
sum(internal_object_reserved_page_count)*8 as internal_objects_kb,
sum(version_store_reserved_page_count)*8 as version_store_kb,sum(unallocated_extent_page_count)*8 as freespace_kb
from sys.dm_db_file_space_usagewhere database_id = 2
SEAS06 - SQL Server 2005 OLTP Best Practices 32
Performance & ResourcesTempdb usage: by sql_handle & plan_handlePerformance & ResourcesTempdb usage: by sql_handle & plan_handle
SELECT t1.session_id,(t1.internal_objects_alloc_page_count + task_alloc) as allocated,(t1.internal_objects_dealloc_page_count + task_dealloc) as deallocated
, t3.sql_handle, t3.statement_start_offset, t3.statement_end_offset, t3.plan_handle
from sys.dm_db_session_space_usage as t1, sys.dm_exec_requests t3,
(select session_id, sum(internal_objects_alloc_page_count) as task_alloc, sum (internal_objects_dealloc_page_count) as task_dealloc from sys.dm_db_task_space_usage group by session_id) as t2where t1.session_id = t2.session_id and t1.session_id >50and t1.database_id = 2 --- tempdb is database_id=2and t1.session_id = t3.session_idorder by allocated DESC
SEAS06 - SQL Server 2005 OLTP Best Practices 33
Performance & ResourcesDatabase SnapshotPerformance & ResourcesDatabase Snapshot
• Database snapshots do consume resources on your server. • Example: Buffer Pool
• Tested – TPC-C workload had 15% performance loss with single Database snapshot
• The more database snapshots, the more performance will be impacted.
SEAS06 - SQL Server 2005 OLTP Best Practices 34
Performance Issues3rd Party Performance ToolsPerformance Issues3rd Party Performance Tools
Veritas (formerly Precise) InDepth for SQL Server
Excellent tool for identifying Resource bottlenecksResources consumed by statementWaits by statementPerformance history
Quest SoftwareGreat tools for monitoringPartition managementBackup with compression (Litespeed)
SEAS06 - SQL Server 2005 OLTP Best Practices 36
Performance IssuesLanguage vs. RPC EventsPerformance IssuesLanguage vs. RPC Events
Server has two distinct and optimized code paths
Goal is to utilize the correct code path!Language event
Every statement not being a (stored) procedureextra parsing required to figure out what is in the stringAdhoc query plans for string (in addition to Stored Proc plans)Generic code which executes procedures via a language event, for example OSQL, Query Analyzer etc.
RPC eventStored procedure invocations using {call} syntaxIncreases performance
eliminates parameter processing and statement parsing
SEAS06 - SQL Server 2005 OLTP Best Practices 37
Performance IssuesAPI - Benchmark lessons Performance IssuesAPI - Benchmark lessons
OLTP Benchmark lessons Big performance gains from best practices
Use efficient row length and data typesEvery byte counts, use correct types
Match packet size and batch sizePerf of ‘Bind’ on client proportional to batch size
For large batches, avoid ODBC Parameter binding with ?
ODBC {Call Proc} better than execute proc syntax
{call dbo.qi ('M01', 'M01.0407040000000002')} exec dbo.qi @v1='M01', @v2='M01.0407040000000002' –adds ADHOC query plans due to SQL string parsing
Net gain using above - 7x
SEAS06 - SQL Server 2005 OLTP Best Practices 38
Performance IssuesResults Handling / Round tripsPerformance IssuesResults Handling / Round trips
You always fetch all results and all result sets!Un-fetched results and result sets can cause concurrency issues on the serverUn-fetched results and result sets will cause an attention signal to be send to the server to cancel the pending streamSET NOCOUNT ON
Avoid unnecessary round trips of sending empty result sets for INSERT, UPDATE and DELETE statements
SEAS06 - SQL Server 2005 OLTP Best Practices 39
Performance IssuesCached Objects & plan re-usePerformance IssuesCached Objects & plan re-use
Master..Sys.dm_exec_cached_plansProcedure or batch nameSet options for plansRef counts, Use countsCompiled plan
Single copy (serial and parallel)Re-entrant and re-usableStatement level recompilation
Executable planData structure for user context, not re-entrantLook for plan reuse: usecounts > 1
Plan re-use ofProcs, Triggers, ViewsDefaults, Check constraints, rulesadhoc SQL, sp_executesql
SEAS06 - SQL Server 2005 OLTP Best Practices 40
Performance IssuesCached Objects & plan re-usePerformance IssuesCached Objects & plan re-use
SQL Batch requests/secCompare to initial SQL Compilations/sec
SQL Compilations/secIncludes initial compiles AND re-compilesEliminate re-compilations to get initial compilesLook for identical SQL statements with low usecounts in Sys.dm_exec_cached_plans
See SEAS06PT:Worst plan re-use by statement.sql
SQL Re-compilations/secStatement Level RecompilesSys.dm_exec_query_stats (plan_generation_num)
when incremented indicates recompilationCheck profiler for sp:recompile event to identify SQL statement.
http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx
SEAS06 - SQL Server 2005 OLTP Best Practices 41
Performance & ResourcesCPU UtilizationPerformance & ResourcesCPU Utilization
Waiting to runRunnable queue – pure CPU waitsCPU pressure measured by signal waits
Plan compilation & requestsPerfmon: SQLServer:SQL Statistics
Batch requests / sec { >1000’s/sec server is busy}SQL Compilations / sec {>10s/sec could be problem}SQL Recompilations / sec {OLTP should avoid high recomps}
Ratio of compiles / requests is importantCompiles – recompiles = initial compiles Plan re-use = (Batch requests – initial compiles) / Batch requests
(compared with batch requests, low initial compiles indicates plan re-use)
Recompile reasons:Change in schema state – schema altered, etc.Previously parallelized plan needs to run seriallyStatistics recomputedRows changed threshold – sys.sysindexes.rowmodctr
SEAS06 - SQL Server 2005 OLTP Best Practices 42
Performance IssuesPlan re-use vs. CPU usagePerformance IssuesPlan re-use vs. CPU usage
CPU used for plan determinationOLTP characterized by high numbers of identical small transactions
Plan re-use desirableSee usecounts in Sys.dm_exec_cached_plans
Stored procedure estimates are based on initial parameter values
Re-use is generally good for OLTP, re-use can be bad when when results sets can significantly vary in size.
SEAS06 - SQL Server 2005 OLTP Best Practices 43
Performance IssuesPlan estimation & re-use issuesPerformance IssuesPlan estimation & re-use issues
Set Statistics Profile on
Shows estimates vs. actualsLook for huge differences (examples)
OverEstimates are 100x actualsUnderEstimates are 1% actuals
Plan selection is based on estimatesOverestimation
Favors fixed cost (hash) strategyExtreme cases can improve
with LOOP JOIN hintExecute P1 with recompile
UnderestimationFavors variable cost (e.g. nested loops) strategyExtreme cases can improve with HASH option
SEAS06 - SQL Server 2005 OLTP Best Practices 44
Performance IssuesProfiler eventsPerformance IssuesProfiler events
Plan re-use (or lack of)Compare batch requests to SQL compiles/sec
IOReads and writes
RecompilationCache hit, insert, miss, removeIndex usage (or lack of)Object access
SEAS06 - SQL Server 2005 OLTP Best Practices 45
Performance IssuesProfiler events for query plansPerformance IssuesProfiler events for query plans
The Profiler events that track cache management include:
SP:CacheMiss (event ID 34 in Profiler)SP:CacheInsert (event ID 35 in Profiler)SP:CacheRemove (event ID 36 in Profiler)SP:Recompile (event ID 37 in Profiler)SP:CacheHit (event ID 38 in Profiler)
SP:Starting lists stored procedure executionSP:StmtStarting will show corresponding SQL statement
Example: sequence is SP:StmtStartingSP:CacheMiss (no plan found)SP:CacheInsert (plan created)
Watch out: Heavy profiler use will affect performance !Add Eventsubclass data column to display recompilation reason
SEAS06 - SQL Server 2005 OLTP Best Practices 46
Performance IssuesCPU: RecompilationPerformance IssuesCPU: Recompilation
Plan determination is CPU Intensive Recomp good if benefit of new plan > CPU cost
ProfilerLists recomp events and statementsData column for reason: EventSubClass
locks on system tables Re-compiling stored procedure plans serialize other users during high concurrency
places lock on single compile plan
Re-compilation based onRows changed thresholds (rowmodctr)DDL placement, schema changesCode practice & temp tables (P1 & P2)
SEAS06 - SQL Server 2005 OLTP Best Practices 47
Performance IssuesEventSubClass: Reasons for recompilation Performance IssuesEventSubClass: Reasons for recompilation EventSubClass Description
1 Schema changed.
2 Statistics changed.
3 Deferred compile.
4 SET option changed.
5 Temporary table changed.
6 Remote rowset changed.
7 FOR BROWSE permission changed.
8 Query notification environment changed.
9 Partitioned view changed.
10 Cursor options changed.
11 OPTION (RECOMPILE) requested.
SEAS06 - SQL Server 2005 OLTP Best Practices 48
Performance IssuesUseful Performance CountersPerformance IssuesUseful Performance Counters
Memory: Page faults/secMemory: pages/secPhysical Disk: Avg. Disk Queue LengthPhysical Disk: Avg. Disk sec/TransferPhysical Disk: Avg. Disk sec/ReadPhysical Disk: Avg. Disk sec/WritePhysical Disk: Current Disk Queue
LengthProcessor: %Processor TimeSS Access Methods: Forwarded
Records/secSS Access Methods: Full Scans/secSS Access Methods: Index
Searches/secSS Access Methods: Page Splits/secSS Access Methods: Range Scans/secSS Access Methods: Table Lock
escalations/secSS Buffer Manager: Checkpoint
pages/secSS Buffer Manager: Lazy writes/secSS Buffer Manager: Page Life
expectancySS Buffer Node:Foreign PagesSS Buffer Node:Page Life expectancySS Buffer Node:Stolen Pages
SS Databases: Log Flush Wait timeSS Databases: Log Flush Waits/secSS General Statistics: User
ConnectionsSS Latches: Average Latch Wait
Time(ms)SS Latches: Latch Waits/secSS Latches: Total Latch Wait Time
(ms)SS Locks: Average Wait Time(ms)SS Locks: Lock requests/secSS Locks: Lock Wait Time (ms)SS Locks: Lock Waits/secSS Memory Manager: Memory grants
pendingSS SQL Statistics: Auto-Params
attempts/secSS SQL Statistics: Batch requests/secSS SQL Statistics: Safe
Auto-Params/secSS SQL Statistics: SQL
Compilations/secSS SQL Statistics: SQL Re-
Compilations/secSystem: Processor Queue Length
SEAS06 - SQL Server 2005 OLTP Best Practices 49
AgendaAgendaOverview
What are the characteristics of OLTP?What are the goals of OLTP?
Design, Techniques and Best practicesTransactionsConcurrencyDatabase design
Normalization, Denormalization, Index maintenance issues
Identifying Performance issuesResource utilizationOptimization
Estimation and query plan selectionPlan re-use & Recompilation
Useful countersOLTP Performance Blueprint
Summary
SEAS06 - SQL Server 2005 OLTP Best Practices 50
OLTP Performance BlueprintDB Design (values can be debated)OLTP Performance BlueprintDB Design (values can be debated)
Resource Issue
Rule
Description Value Source Problem
Description
DB
Desig
n
1 High Frequency queries having # table joins
>4
Sys.dm_exec_sql_textSys.dm_exec_cached_plans
High Frequency queries with lots of joins may be too normalized for high OLTP scalability
2 Frequently updated tables having # indexes
>3
Sys.indexessys.dm_db_operational_index_stats
Excessive index maintenance for OLTP
3 Big IOsrange scanstable scans
>1
Perfmon objectSQL Server Access
Methods
Sys.dm_exec_query_stats
Missing index, flushes cache
4 Unused Indexes index not in*
* Sys.dm_db_index_usage_stats
Index maintenance for unused indexes
SEAS06 - SQL Server 2005 OLTP Best Practices 51
OLTP Performance BlueprintIO Utilization (values can be debated)OLTP Performance BlueprintIO Utilization (values can be debated)
Resource
IssueRule
Description Value
Source Problem Description
IO
1 Avg Disk seconds / read
> 10 ms
Perfmon objectPhysical Disk
Reads should take 4-8ms with NO IO pressure
2 Avg Disk seconds / write
> 10 ms
Perfmon objectPhysical Disk
Writes (sequential) can be as fast as 1ms for transaction log.
3 Big IOsrange scanstable scans
>1
Perfmon objectSQL Server Access
Methods
Missing index, flushes cache
4 If Top 2 values for
Wait stats includes:
ASYNCH_IO_COMPLETION
IO_COMPLETIONLOGMGRWRITELOGPAGEIOLATCH_x
To
p 2 Sys.dm_os_wait_stats
If top 2 wait_stats values include IO, there is an IO bottleneck
SEAS06 - SQL Server 2005 OLTP Best Practices 52
OLTP Performance BlueprintBlocking (values can be debated)OLTP Performance BlueprintBlocking (values can be debated)
Resource Issue
Rule Description Value Source Problem
Description
Blo
cking
1 Block percentage
>2%
Sys.dm_db_index_operational_stats
Frequency of blocks
2 Block process report
30 sec
Sp_configure “blocked process threshold”
profiler “blocked process report”
Report of long blocks e.g. statements
3 Avg Row Lock Waits
> 100ms
Sys.dm_db_index_operational_stats
Duration of blocks
4 If Top 2 values forwait stats are any of the following:
1. LCK_x
Top 2
Sys.dm_os_wait_stats
If top 2 wait_stats values include locking, there is a blocking bottleneck
SEAS06 - SQL Server 2005 OLTP Best Practices 53
OLTP Performance BlueprintCPU Utilization (values can be debated)OLTP Performance BlueprintCPU Utilization (values can be debated)
Resource Issue
Rule Description Value Source Problem
Description
CPU
1 Signal Waits
>25%
Sys.dm_os_wait_stats
Time in runnable queue is pure CPU wait.
2 Plan Re-use < 90
% Sys.dm_os_wait_stats
Perfmon objectSQL Server
Statistics
OLTP identical transactions should ideally have >95% plan re-use
3 Parallelism: CXPACKET waits
> 5%
Sys.dm_os_wait_stats
Parallelism reduces OLTP throughput
SEAS06 - SQL Server 2005 OLTP Best Practices 54
OLTP Performance BlueprintMemory Utilization (values can be debated)OLTP Performance BlueprintMemory Utilization (values can be debated)
Resource Issue Rul
eDescription Val
ueSource Problem
Description
Mem
ory
1 Average Page Life Expectancy
< 3
00
sec
Perfmon objectSQL Server
Buffer MgrSQL Server
Buffer Nodes
1. Cache flush,due to big read
2. Possible missing index
2 Average Page Life Expectancy
Dro
ps b
y 5
0%
Perfmon objectSQL Server
Buffer MgrSQL Server
Buffer Nodes
1. Cache flush,due to big read
2. Possible missing index
3 Memory Grants Pending
> 1 Perfmon objectSQL Server
Memory Manager
Current number of processes waiting for a workspace memory grant
SEAS06 - SQL Server 2005 OLTP Best Practices 55
AgendaAgenda
Overview performance objectives of OLTPDesign, Techniques and Best practices
TransactionsConcurrencyDatabase design
Normalization, Denormalization, Index maintenance issues
High End implementation findingsIdentifying Performance issues
Resource utilizationOptimization
Estimation and query plan selectionPlan re-use & Recompilation
Useful countersOLTP Performance Blueprint
Summary
SEAS06 - SQL Server 2005 OLTP Best Practices 56
OLTP SummaryLessons learnedOLTP SummaryLessons learned
Challenge: Scheduling a mix workload evenly across SchedulersDatabase Log to handle 60,000+ database tx/secReal time reporting and loading data
Indexes are both good and badOLTP general goal: limit recompilesMultiple database logs for scalabilityRead-only queries: consider another database via replication, log shipping or Shared Scalable Database
SEAS06 - SQL Server 2005 OLTP Best Practices 57
OLTP SummaryGotchasOLTP SummaryGotchas
Database design driven by workload requirements
IndexesDenormalization decisionsTransactions
Maximizing resourcesPlan re-use – normally desirable for OLTPRecompilation – generally try to avoid with OLTPSet based operations more efficient than cursorsReduce parallel queries to improve concurrency
Sp_configure “max degree of parallelism”,1 -- turns off
Check for good query plans – set statistics profile onGood data access – see Benchmark lessons
SEAS06 - SQL Server 2005 OLTP Best Practices 58
OLTP SummaryOLTP SummaryOLTP applications require appropriate
database designIndex usage
Transaction usageHigh concurrency - must minimize blocking
Application designUse code coding techniques for plan re-use, minimize recompiles
API Maximize performance with most efficient calls
Access methodsEfficient query plans for OLTP
SEAS06 - SQL Server 2005 OLTP Best Practices 59
Other ResourcesOther Resources
SQL Server 2005 Batch Compilation, Recompilation, and Plan Caching Issues
http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx
SQL Customer Advisory Team internal sitehttp://sqlserver/sites/sqlcat
SQL Customer Advisory Team bloghttp://blogs.msdn.com/sqlcat
SQL Server Webcastshttp://www.microsoft.com/technet/prodtechnol/sql/webcasts/default.mspx
SEAS06 - SQL Server 2005 OLTP Best Practices 60
© 2003 Microsoft Corporation. All rights reserved.© 2003 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.