Performance Tuning with SQL Server Dynamic Management Views

More documents

Recommendations

Info

Chapter 4: Transactions Simply by un-commenting the calculation of the transaction duration in Listing 4.14, and swapping the ORDER BY clause, we can investigate the activity of long-running transactions that may be bloating the transaction log file, or preventing it from being truncated. Snapshot Isolation and the tempdb Version Store The snapshot isolation level was introduced in SQL Server 2005 and eliminates blocking and deadlocking by using row versioning in the tempdb database to maintain concurrency, rather than establishing locks on database objects. As such, the goal of snapshot isolation is increased performance through greater concurrency. Snapshot isolation is a huge topic and we can do little more than provide a brief overview here. Please see Microsoft Books Online or MSDN for further details on isolation levels, concurrency, and locking models. Each time a row is modified in a database running under snapshot isolation, a version of the row from prior to the modification is stored within tempdb in a version store. In other words, this version store is populated with versions of data rows as they existed before the initialization of an explicit transaction. The version store is shared by all databases that are running under snapshot isolation on the SQL Server instance. Read transactions targeting the affected rows will use the row version(s) from the tempdb, while the writing transaction will modify the actual table data. Update locks are issued for writes, and when a read transaction encounters such a lock, it is diverted to the version store. This row-versioning mechanism ensures that write transactions do not block reads. It is no longer necessary to take exclusive locks on data being modified, to prevent dirty reads, because the reads are made against versions of the rows that were in a committed state from prior to the transaction or statement initialization. It also means that readers do not block writers, since read transactions will no longer take shared read locks. 148
149 Chapter 4: Transactions Any DML queries will continue to block other DML queries as is necessary to maintain data integrity. SNAPSHOT and READ_COMMITTED_SNAPSHOT modes Snapshot isolation introduces two new modes of operation: • SNAPSHOT mode isolates read transactions from modifications that committed after the transaction began • READ_COMMITTED_SNAPSHOT mode isolates read transactions from modifications which committed after the current statement began. SNAPSHOT mode is initiated at the database level using Listing 4.15. ALTER DATABASE Test SET ALLOW_SNAPSHOT_ISOLATION ON; Listing 4.15: Enabling snapshot isolation at the database level. Note that this command only instructs the database to begin using a version store within tempdb. It does not affect the behavior of any sessions running against the database. Any session using the default READ COMMITTED level will continue to operate as normal, unless to use the version store and take advantage of snapshot isolation, by issuing the command in Listing 4.16, from within the session. SET TRANSACTION ISOLATION LEVEL SNAPSHOT; Listing 4.16: Enabling SNAPSHOT isolation mode for a given session.
Page 1 and 2:
High Performance SQL Server Perform
Page 3 and 4:
Copyright Louis Davidson and Tim Fo
Page 5 and 6:
Dissecting user activity ..........
Page 7 and 8:
Getting Stats about tempdb Usage ..
Page 9 and 10:
Server (PASS) since 2002. He has al
Page 11 and 12:
Tim Ford I dedicate this book to Am
Page 13 and 14:
13 Introduction on those objects th
Page 15 and 16:
Code Examples 15 Introduction Throu
Page 17 and 18:
Chapter 1: Using Dynamic Management
Page 19 and 20:
Page 21 and 22:
DMO Security and Permissions Chapte
Page 23 and 24:
Page 25 and 26:
We can find out, for example: Chapt
Page 27 and 28:
Page 29 and 30:
Beware of the watcher effect Chapte
Page 31 and 32:
Page 33 and 34:
Chapter 2: Connections, Sessions an
Page 35 and 36:
Sysprocesses versus DMOs Chapter 2:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Listing 2.3: Who is connected? Chap
Page 45 and 46:
Listing 2.4: Who is executing what
Page 47 and 48:
Logins with more than one session C
Page 49 and 50:
DECLARE @days_old SMALLINT SELECT @
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
• dbcc shrinkdatabase / shrinkfil
Page 59 and 60:
Page 61 and 62:
This will return (with a different
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Who is running what, right now? Cha
Page 69 and 70:
Page 71 and 72:
Summary Chapter 2: Connections, Ses
Page 73 and 74:
73 Chapter 3: Query Plan Metadata P
Page 75 and 76:
75 Chapter 3: Query Plan Metadata P
Page 77 and 78:
77 Chapter 3: Query Plan Metadata t
Page 79 and 80:
79 Chapter 3: Query Plan Metadata U
Page 81 and 82:
SELECT TOP 10 object_id , name FROM
Page 83 and 84:
Dissecting the SQL text 83 Chapter
Page 85 and 86:
Figure 3.2: Three queries returned
Page 87 and 88:
87 Chapter 3: Query Plan Metadata T
Page 89 and 90:
89 Chapter 3: Query Plan Metadata
Page 91 and 92:
Criteria in determing plan reuse 91
Page 93 and 94:
For a server that had been up for t
Page 95 and 96:
Listing 3.9: Investigating the most
Page 97 and 98: SELECT FirstName , LastName FROM db
Page 99 and 100: 99 Chapter 3: Query Plan Metadata C
Page 101 and 102: 101 Chapter 3: Query Plan Metadata
Page 105 and 106: Listing 3.14: Finding the CPU-inten
Page 107 and 108: WHERE execText.text like '%account%
Page 115 and 116: 115 Chapter 4: Transactions We'll a
Page 117 and 118: 117 Chapter 4: Transactions unique
Page 119 and 120: Snapshot isolation level 119 Chapte
Page 121 and 122: 121 Chapter 4: Transactions • res
Page 123 and 124: Lock types 123 Chapter 4: Transacti
Page 125 and 126: 125 Chapter 4: Transactions • Sha
Page 127 and 128: 127 Chapter 4: Transactions SELECT
Page 129 and 130: 129 Chapter 4: Transactions If, fro
Page 131 and 132: 131 Chapter 4: Transactions The LEF
Page 133 and 134: 133 Chapter 4: Transactions When in
Page 135 and 136: 135 Chapter 4: Transactions column.
Page 137 and 138: 137 Chapter 4: Transactions some po
Page 139 and 140: 139 Chapter 4: Transactions OPENTRA
Page 141 and 142: 141 Chapter 4: Transactions In this
Page 143 and 144: 143 Chapter 4: Transactions time on
Page 145 and 146: 145 Chapter 4: Transactions process
Page 147: INNER JOIN sys.dm_tran_session_tran
Page 151 and 152: SELECT SD.[name] , SD.snapshot_isol
Page 153 and 154: 153 Chapter 4: Transactions In othe
Page 155 and 156: 155 Chapter 4: Transactions just th
Page 157 and 158: 157 Chapter 4: Transactions Open a
Page 159 and 160: FROM dbo.Culture ; -- COMMIT; Listi
Page 161 and 162: 161 Chapter 4: Transactions In orde
Page 163 and 164: 163 Chapter 4: Transactions In shor
Page 165 and 166: Using sys.dm_tran_version_store 165
Page 167 and 168: 167 Chapter 4: Transactions In List
Page 169 and 170: sys.dm_tran_top_version_generators
Page 171 and 172: 171 Chapter 4: Transactions Via que
Page 173 and 174: Chapter 5: Indexing Strategy and Ma
Page 181 and 182: High selectivity Chapter 5: Indexin
Page 189 and 190: Identify inefficient indexes Chapte
Page 195 and 196: Listing 5.9: Retrieving locking and
Page 199 and 200:
Chapter 5: Indexing Strategy and Ma
Page 201 and 202:
Page 203 and 204:
Missing index groups Chapter 5: Ind
Page 205 and 206:
Page 207 and 208:
Listing 5.13: Finding beneficial mi
Page 209 and 210:
Page 211 and 212:
Page 213 and 214:
ORDER BY ddips.[avg_fragmentation_i
Page 215 and 216:
Summary Chapter 5: Indexing Strateg
Page 217 and 218:
Chapter 6: Physical Disk Statistics
Page 219 and 220:
Page 221 and 222:
Tuning the Disk I/O Subsystem Chapt
Page 223 and 224:
Page 225 and 226:
The view returns the statistical co
Page 227 and 228:
Page 229 and 230:
Page 231 and 232:
The sys.dm_db_index_physical_stats
Page 233 and 234:
Page 235 and 236:
The NEWSEQUENTIALID() function Chap
Page 237 and 238:
CREATE TABLE testHeap ( testHeapId
Page 239 and 240:
Page 241 and 242:
Page 243 and 244:
Page 245 and 246:
Page 247 and 248:
Viewing pending I/O requests Chapte
Page 249 and 250:
Page 251 and 252:
Amount of data read versus written
Page 253 and 254:
The results are as follows: Chapter
Page 255 and 256:
Page 257 and 258:
Page 259 and 260:
Page 261 and 262:
Page 263 and 264:
263 Chapter 7: OS and Hardware Inte
Page 265 and 266:
Page 267 and 268:
Finding the most common waits 267 C
Page 269 and 270:
Page 271 and 272:
Page 273 and 274:
Page 275 and 276:
Page 277 and 278:
Page 279 and 280:
WHERE cntr_type = @PERF_COUNTER_LAR
Page 281 and 282:
DECLARE @PERF_LARGE_RAW_FRACTION IN
Page 283 and 284:
ORDER BY dopc_fraction.object_name
Page 285 and 286:
) time DATETIME DEFAULT ( GETDATE()
Page 287 and 288:
DECLARE @PERF_AVERAGE_BULK INT , @P
Page 289 and 290:
• cpu_count - number of logical p
Page 291 and 292:
Page 293 and 294:
The max worker threads option. 293
Page 295 and 296:
• work_queue_count - number of ta
Page 297 and 298:
WHERE scheduler_id < 255 AND runnab
Page 299 and 300:
Page 301 and 302:
Page 303 and 304:
System-wide memory use 303 Chapter
Page 305 and 306:
Page 307 and 308:
As stated by Books Online: 307 Chap
Page 309 and 310:
Page 311 and 312:
• name - the descriptive name giv
Page 313 and 314:
Page 315 and 316:
Page 317 and 318:
Page 319 and 320:
Summary 319 Chapter 7: OS and Hardw
Page 321 and 322:
Index A ACID test 116 Activity and
Page 323 and 324:
P Performance counters 277-291 aver
Page 325 and 326:
sys.dm_tran_database_transactions 1
Page 327 and 328:
SQL Compare ® Pro Compare and sync
Page 329 and 330:
Deployment Manager Automated deploy
Page 331 and 332:
SQL Monitor from $795 SQL Server pe
Page 333 and 334:
You can buy our acclaimed SQL Serve
Page 335 and 336:
.NET Reflector Decompile, debug, an
Page 337:
The Red Gate Guides SQL Server Back
show all

Performance Tuning with SQL Server Dynamic Management Views

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?