SQL Server Architecture - SQL Server 2012 Internals and Troubleshooting - page 25

The basic scheduler in Windows is known as a pre-emptive scheduler and it assigns slices of time
known as quantums to each task to be executed. The advantage of this is that application developers
don't have to worry about scheduling when creating applications; the downside is that execution can
be interrupted at any point as Windows balances execution requests from multiple processes.

All versions of SQL Server up to and including version 6.5 used the Windows scheduler to take
advantage of the work that the Windows team had done through a long history of optimizing
processor usage. There came a point, however, when SQL Server 6.5 could not scale any further and
it was limited by the general-purpose optimizations of the pre-emptive scheduler in Windows.

For SQL Server 7.0, Microsoft decided that SQL Server should handle its own scheduling, and
created the User Mode Scheduler (UMS) to do just that. The UMS was designed as a co-operative
scheduling model whereby threads aren't forcibly interrupted during execution but instead voluntarily
yield the processor when they need to wait for another resource. When a thread yields the processor,
a wait type is assigned to the task to help describe the wait and aid you in troubleshooting
performance issues.

The SQLOS
Prior to SQLOS (which was i rst implemented in SQL Server 2005), low-level operations such as
scheduling, I/O completion, memory management, and resource management were all handled by
different teams, which resulted in a lot of duplication of effort as the product evolved.

The idea for SQLOS was to consolidate all these efforts of the different internal SQL Server
development teams to provide performance improvements on Windows, putting them in a single
place with a single team that can continue to optimize these low-level functions. This enables the
other teams to concentrate on challenges more specii c to their own domain within SQL Server.

Another benei t to having everything in one place is that you now get better visibility of what's
happening at that level than was possible prior to SQLOS. You can access all this information
through dynamic management views (DMVs). Any DMV that starts with sys.dm_os_ provides an
insight into the workings of SQLOS, such as the following:
➤

sys.dm_os_schedulers — Returns one row per scheduler (remember, there is one user
scheduler per logical processor) and displays information about scheduler load and health.
See Chapter 5 for more information.

➤

sys.dm_os_waiting_tasks — Returns one row for every executing task that is currently
waiting for a resource, as well as the wait type

➤

sys.dm_os_memory_clerks — Memory clerks are used by SQL Server to allocate memory.
Signii cant components within SQL Server have their own memory clerk. This DMV shows
all the memory clerks and how much memory each one is using. See Chapter 3 for more
information.

Relating SQLOS back to the architecture diagrams shown earlier, many of the components make
calls to the SQLOS in order to fuli ll low-level functions required to support their roles.

Just to be clear, the SQLOS doesn't replace Windows. Ultimately, everything ends up using the
documented Windows system services; SQL Server just uses them in a way optimized for its own
specii c scenarios.