No escalation from Row to PageEach lock structure is 100 bytesNumber of locks acquired on a rowset > 5000 - Periodically after that
Self-explanatory. See Books Online for more details about partitioning. Also see http://msdn2.microsoft.com/en-us/library/ms345146.aspx
Query 1 is updating partition 1. It hits the escalation threshold and escalates to a TABLE X lock. Query 2 tries to update partition 3 and can’t because of the table X lock, even though nothing in partition 3 is being altered by query 1.
Instead of escalating to the table level and blocking all other queries on the table, you can now choose to have escalation to the partition level, which allows concurrent queries on different partitions.
3. Read Committed Snapshot• New “flavor” of read committed • Turn ON/OFF on a database• Readers see committed values as of beginning of statement • Writers do not block Readers • Readers do not block Writers • Writers do block writers• Can greatly reduce locking / deadlocking without changing applications
4. Demo: RCSI
5. Lock Escalation HOBT T1: IX T1: XPage Page Page T1: IX T1: X T1: X T1: X T1: XRow Row Row T1: X T1: X T1: X T1: X
6. Lock Escalation• Converting finer-grain locks to coarse grain locks. • Row to Table • Page to Table.• Benefits • Reduced locking overhead • Reduces Memory requirement• Triggered when • Number of locks acquired on a rowset > 5000 • Memory pressure
7. Partitioned Tables and Indexes• SQL Server 2005 introduced partitioning, which some customers use to scale a query workload • Another common use is to streamline maintenance and enable fast range inserts and removals from tables Partitioned Table FG1 FG2 FG3
8. Lock Escalation: The Problem• Lock escalation on partitioned tables reduces concurrency as the table lock locks ALL partitions Query 1 Partitioned Query 2 IX X Table update update Partition 1 Partition 2 Partition 3 FG1 FG2 FG3• Only way to solve this in SQL Server 2005 is to disable lock escalation
9. Lock Escalation: The Solution• SQL Server 2008 & up allows lock escalation to the partition level, allowing concurrent access to other partitions Query 1 Partitioned Query 2 IX Table update update Partition 1 X Partition 2 Partition 3 FG1 FG2 FG3• Escalation to partition level does not block queries on other partitions
10. Demo: PartitionLevel LockEscalation
11. Filtered Indexes• An index with a WHERE clause to specify a criteria• Essentially index only a subset of a the table • Query optimizer most likely to use when WHERE clause matches that of the filtered index
12. Using Filtered Indexes• Advantages of Filtered Indexes • Improve query performance, partly by enhancing execution plan quality • Smaller index maintenance costs • Less disk storage
13. Using Filtered Indexes• Scenarios for Filtered Indexes • Sparse columns, where most data is null • Columns with categories of values • Columns with distinct ranges of values
15. Optimize for ad hoc workloads• New server option in • SP_CONFIGURE show advanced SQL Server 2008 options,1 RECONFIGURE• Only a stub is cached GO • SP_CONFIGURE optimize for ad on first execution hoc workloads,1 RECONFIGURE• Full plan cached GO after second execution
16. How good is it?
17. Demo:Optimize for ad hoc workload
18. Configuration: Don’t get confused!
19. Configuratio n Cheats
20. Processor Funny Games
21. TempDB• Create a file per CPU that SQL Server uses• Not more than 8
22. Memory Configuration• X86? Really? • Microsoft Knowledge Base article 274750
23. Lock Pages in Memory• Yes/No?• Enterprise Edition only • Can be done on Standard using latest SPs for 2005/2008 and trace flag 845 for 2008 R2• AWE is ignored in 64 bit• The ‘Local System’ account has the ‘lock pages in memory’ privilege by default• Configure MaxServerMemory
24. Min/Max Memory• Yes/No?
25. Min/Max Memory
26. Min/Max Memory• Yes/No?• Keep an eye on Available MB counter
27. Reason and Solution?• Note the name Memory (Private Working Set) – • AWE APIs are used on 64bit to “lock” pages • That memory is not part of the working set• Only trust: • Perfmon SQL Server memory counters • sys.dm_os_process_memory DMV
28. Demo:Lock Pages in Memory
30. As data volume grows…• Large databases = • Storage Cost • Workload Performance • Manageability Cost • Backup/Recovery
31. Compression• Store data efficiently in the row/page • (+) More data can fit in memory • (+) Better Performance for I/O bound workload • (-) Performance degradation for CPU bound workload
32. Data Compression• SQL Server 2008 • ROW and PAGE compression • Backup Compression• SQL Server 2008 R2 • Unicode compression• SQL Server 2008 R2 • Spatial indexes compression
34. Should it be so complex?In real life – usually compress the entire large tables using page compression…
35. Summary – Compression• Can reduce size of database significantly• Lower total cost of ownership (TCO)• Easy to enable/disable• No application changes• Performance gains!