Knowing that SQL Server was built to run on Windows means that there must have been some changes made to the architecture to support Linux. SQL Server was originally designed to control its resource requirements largely on its own—CPU scheduling, Memory Management, and Storage Access were controlled for the most part by the SQL Server Operating System (SOS). This deep control allows SQL Server to circumvent many operating system overheads and ensure that database engine activities perform at the highest performance levels while ensuring secure system access is adhered to. Naturally a system that was built over decades on one platform will tend towards using certain access methods of the operating system to achieve these goals. Some of this access on Windows is extremely low level in the operating system and creates dependencies on certain system level functionalities.
A move to allow a different operating system means that the symbiosis between SQL Server and Windows needed a separation layer to deal with these specialized system calls.
Microsoft Research had already invested a great deal of time into the virtualization space and had a project named Drawbridge which was designed to allow application sandboxing, where an application runs in a virtualized process and is provided with access to the Windows functionality via an abstraction layer. The work done in this project was then combined into a new project called the SQL Platform Abstraction Layer (SQLPAL). This abstraction layer was built to align operating-system-specific code together with all other operations and allow a platform-agnostic coding approach with the SQL Server engine code. The stated goal within Microsoft was to provide a full SQL Server experience on Linux with security and performance levels comparable to the current Windows version of SQL Server.
This change will also affect the Windows variant of SQL Server, in that all previous operating-system-specific calls that went directly to Windows are now directed through the SQLPAL, to avoid any future re-engineering requirements for the SQL on Linux variants. Through forcing the SQLPAL association and processing, any performance or security concerns are addressed centrally and affect all variants of SQL Server from this point onward. The advantage here is that SQL on Linux cannot be pushed along as a second class citizen, but rather it enjoys the benefits of improvements across the board.
The goals of the SQL on Linux project were publicly stated as follows:
- Quality and security must be the same for SQL Server on Windows
- To provide identical functionality, performance, and scale
- Support application compatibility on both platforms
- To ensure that fixes and updates are supplied for both platforms at the same time
- To provide a path to support future SQL Server services on Linux (for example Integration Services)
These goals basically mean re-engineering the aforementioned dependencies on Windows and pushing these calls into the SQLPAL. The efforts in this area span tens of millions of lines of code in the SQL Server codebase, covering three main areas:
- Win32 (user32.dll)
- The NT Kernel (nrdll.dll)
- Windows Application libraries (for example MSXML)
The first two areas are more common Windows kernel functionalities; the third section is where the main work in re-engineering will be found. This area covers features such as XML support (parsing XML and so on) as well as more core functionality within SQL Server such as SQLCLR (the common language runtime integration), COM and VDI interfaces for backups, Microsoft Distributed Transaction Coordinator as well as the SQL Server Agent integrations with the Windows Event Log, SMTP, and shell execution.
These features are all core to SQL Server and cannot be simply removed from the SQL Server with any Linux release—otherwise, a greatly crippled variant would be delivered and the goals of full support on any platform would not be met.