Starting from version 2005, SQL Server has
introduced something called the SQLOS ( SQL Operating System).
Although the name suggests otherwise, it is neither an operating system, nor a
wrapper for the underlying OS APIs. It is not a bridge to other non-Windows
platforms or a development framework exposed as class libraries.
SQLOS is a piece of software that provides
vital services to SQL Server storage and database engine by optimally
interfacing with Windows. Windows is a general purpose OS: it is not
particularly optimised for SQL. SQLOS interfaces with Windows on behalf of SQL
Server and manages core system services. Some of the services provided by SQLOS
include:
·
Memory management
·
Resource management
·
Detecting deadlock and managing them
·
Exception handling
·
Hosting services for CLR components
·
Diagnostic capabilities including Dedicated
Administrator Connection (DAC) and Dynamic Management Views (DMVs)
·
Scheduler Management (discussed shortly)
Applications running under Windows are
allocated separate, protected memory space. These memory spaces are called Virtual
Address Spaces or VAS. Since each application’s VAS is different,
there is no way one application can write into another app’s address space. This
ensures applications do not fail with critical access violation errors. Now the
VAS assigned to an application can be coming from the server’s actual RAM or
the paging file, or a combination of both. A paging file or the swap
file is an operating system file that Windows memory manager uses to store
data that does not fit within the server’s physical memory. It writes out data
to the swap file and reads from it as applications request accesses to the
memory. The translation between virtual memory address and physical memory
address (in RAM and in page file) is done by the Windows memory manager. As far
as the application is concerned, it does not know where its memory actually
resides in. For 32 bit Windows, the maximum amount of VAS the OS can address is
4 GB. By default, 2 GB of it is used by the operating system kernel services
and the rest 2 GB is available for apps like SQL Server. However it is possible
to use a switch in the boot.ini file (called the /3GB switch)
which allocates 1 GB for Windows and 3 GB for apps. For 32 bit systems with
more than 4 GB of memory, SQL Server can address the extra RAM using the Address
Windowing Extension (AWE) mechanism. Memory addressing is not an
issue for 64 bit Windows because Windows can address 16 TB of VAS there.