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


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


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


AgendaAgenda


TransactionsConcurrencyIndex maintenance issues

SQL Server 2005 OLTP implementation findingsIdentifying Performance issues




Summary


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%


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


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


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()


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


AgendaAgenda


TransactionsConcurrencyIndex maintenance issues

SQL Server 2005 OLTP Implementation findingsIdentifying Performance issues




Summary


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




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




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




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




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)


AgendaAgenda


TransactionsConcurrencyDatabase design

Normalization, Denormalization, Index maintenance issues

SQL Server OLTP implementation findingsIdentifying Performance issues




Summary


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


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


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


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


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




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.


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


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


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


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


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


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


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


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).


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


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


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.


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)


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


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


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


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


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




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


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.


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


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


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


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)


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.


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


AgendaAgendaOverview

What are the characteristics of OLTP?What are the goals of OLTP?

Design, Techniques and Best practicesTransactionsConcurrencyDatabase design


Identifying Performance issuesResource utilizationOptimization



Summary


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


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


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


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%


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%


Parallelism reduces OLTP throughput


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


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%


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


AgendaAgenda


TransactionsConcurrencyDatabase design


High End implementation findingsIdentifying Performance issues




Summary


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


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


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


Other ResourcesOther Resources

SQL Server 2005 Batch Compilation, Recompilation, and Plan Caching Issues


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



http://sqlserver/sites/sqlcat

http://blogs.msdn.com/sqlcat

http://www.microsoft.com/technet/prodtechnol/sql/webcasts/default.mspx

http://www.microsoft.com/technet/prodtechnol/sql/webcasts/default.mspx


© 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.

Documents

SEAS06 - SQL Server 2005 OLTP Best Practices 1 SEAS 2006 SQL Server 2005 OLTP Best Practices