SQL Server 2005 and 2008 are designed to be able to massively scale, enabling support for huge, highly concurrent workloads. Thousands of users hitting your database at the same time is no problem at all. But sometimes, due to business demands, we actually need to go the other way and put controls in place to limit concurrency. This session focuses on techniques for designing your databases and applications in order to satisfy the business requirements of concurrency, rather than just shooting for a high number of transactions per second. Considering the potential business impact of our concurrency decisions brings up numerous interesting questions; for example, what happens when you need to support business processes that may last hours or days, and how do you design data workflows into your database? The session starts with a discussion of some of the designs that can contribute to concurrency problems, as well as the categories of business requirements that should be used as drivers when considering how to fix concurrency issues. We will then take a look at how SQL Server handles concurrency at the transactional level, with a quick overview of isolation levels—including the newest member of the group, snapshot isolation. We will next move on to an analysis of how to use SQL Server's various features to help solve many of the problems that concurrency brings to the table: Database designs to support pessimistic and optimistic concurrency at the business process level, multivalue concurrency control to support versioning and snapshot views of data at the table level, and examples from a real-world project where SQL Service Broker was used as a vehicle to greatly drive up the concurrency potential of a mixed-workload application.
Register Now for PASS Community Summit 2008!