21
2.3 SQLOS
fonctionnalités d’accès et de partage des ressources système. Les recherches en bases
de données, un domaine actif depuis longtemps, montrent que les meilleures performances sont atteintes en laissant le soin au SGBDR de gérer certaines parties de ce
qui est traditionnellement de la responsabilité du système d’exploitation. Oracle, par
exemple, cherche depuis longtemps à minimiser le rôle de l’OS, en contournant les
systèmes de fichiers journalisés à l’aide de raw devices (Oracle directIO), en proposant
un outil comme ASM (Automatic Storage Manager) pour gérer directement le système de fichiers, ou en intégrant depuis peu sa propre couche de virtualisation, basée
sur Xen.
SQL Server n’échappe pas à cette règle. Il intègre sa couche de gestion de fonctionnalités bas niveau, nommée SQLOS (pour SQL Server Operating System). Elle
prend en charge des fonctionnalités d’ordonnancement des threads de travail, la gestion de la mémoire, la surveillance des ressources, les entrées/sorties, la synchronisation des threads, la détection des verrous mortels (deadlocks), etc. qui permettent de
gérer à l’intérieur même de SQL Server, proche des besoins du moteur, les éléments
essentiels à un travail efficace avec les ressources de la machine. Vous trouvez un
schéma des différents modules présents dans SQLOS en figure 2.3.
Figure 2.3 — Modules de SQLOS
Vous pouvez observer l’activité de SQLOS à l’aide de vues de gestion dynamique
préfixées par sys.dm_os_. Les vues de gestion dynamique (dynamic management views,
DMV) sont des vues qui retournent des informations sur l’état du système, et non sur
des données ou des métadonnées stockées dans une base.
SQLOS permet de gérer efficacement les systèmes à multiprocesseurs. Un ordonnanceur (scheduler) est lié à chaque processeur physique, qui gère à l’intérieur de
SQL Server, les threads, en mode utilisateur (user mode) (le système d’exploitation
sous-jacent gère les threads en mode noyau (kernel mode)). La raison en est que SQL
Server connaît mieux ses besoins de multitâche que le système d’exploitation. Windows gère les threads de façon dite préemptive, c’est-à-dire qu’il force les processus à
s’arrêter pour laisser du temps aux processus concurrents. Les ordonnanceurs de SQL
Server fonctionnent en mode non préemptif : à l’intérieur de SQLOS, les processus
2.3 SQLOS
fonctionnalités d’accès et de partage des ressources système. Les recherches en bases
de données, un domaine actif depuis longtemps, montrent que les meilleures performances sont atteintes en laissant le soin au SGBDR de gérer certaines parties de ce
qui est traditionnellement de la responsabilité du système d’exploitation. Oracle, par
exemple, cherche depuis longtemps à minimiser le rôle de l’OS, en contournant les
systèmes de fichiers journalisés à l’aide de raw devices (Oracle directIO), en proposant
un outil comme ASM (Automatic Storage Manager) pour gérer directement le système de fichiers, ou en intégrant depuis peu sa propre couche de virtualisation, basée
sur Xen.
SQL Server n’échappe pas à cette règle. Il intègre sa couche de gestion de fonctionnalités bas niveau, nommée SQLOS (pour SQL Server Operating System). Elle
prend en charge des fonctionnalités d’ordonnancement des threads de travail, la gestion de la mémoire, la surveillance des ressources, les entrées/sorties, la synchronisation des threads, la détection des verrous mortels (deadlocks), etc. qui permettent de
gérer à l’intérieur même de SQL Server, proche des besoins du moteur, les éléments
essentiels à un travail efficace avec les ressources de la machine. Vous trouvez un
schéma des différents modules présents dans SQLOS en figure 2.3.
Figure 2.3 — Modules de SQLOS
Vous pouvez observer l’activité de SQLOS à l’aide de vues de gestion dynamique
préfixées par sys.dm_os_. Les vues de gestion dynamique (dynamic management views,
DMV) sont des vues qui retournent des informations sur l’état du système, et non sur
des données ou des métadonnées stockées dans une base.
SQLOS permet de gérer efficacement les systèmes à multiprocesseurs. Un ordonnanceur (scheduler) est lié à chaque processeur physique, qui gère à l’intérieur de
SQL Server, les threads, en mode utilisateur (user mode) (le système d’exploitation
sous-jacent gère les threads en mode noyau (kernel mode)). La raison en est que SQL
Server connaît mieux ses besoins de multitâche que le système d’exploitation. Windows gère les threads de façon dite préemptive, c’est-à-dire qu’il force les processus à
s’arrêter pour laisser du temps aux processus concurrents. Les ordonnanceurs de SQL
Server fonctionnent en mode non préemptif : à l’intérieur de SQLOS, les processus