SQL Server 2008

SQL Server 2008
Administration
Jérôme GABILLAUD
Résumé
Ce livre sur SQL Server 2008 s’adresse à toute personne désireuse d’administrer une base de données (administrateur de base de données,
développeur...).
Il présente les différents éléments nécessaires à cette administration ainsi que l’ensemble des manipulations à réaliser par l’administrateur,
depuis l’installation jusqu’aux opérations de sauvegarde et de restauration, en passant par la gestion de l’espace disque, la gestion des
utilisateurs, la gestion de la réplication.
Les différents outils permettant une optimisation du serveur sont présentés ainsi que ceux permettant la mise en place d’une solution de haute
disponibilité.
Les nouveaux concepts liés à la version de SQL Server 2008 sont également traités, tels l’administration par les règles, l’intégration avec le
Power Shell, la compression et le cryptage des données.
Les différentes opérations sont réalisées depuis SQL Server Management Studio et en Transact SQL.
Des éléments sont en téléchargement sur cette page.
L'auteur
Ingénieur en Informatique pour l'Industrie, consultant, Jérôme Gabillaud est également responsable pédagogique dans un grand centre de
formation informatique. Spécialiste des systèmes d'accès aux données Microsoft ou Oracle, il est déjà auteur de nombreux ouvrages sur ce
sujet, reconnus pour leurs qualités techniques et pédagogiques.
Ce livre numérique a été conçu et est diffusé dans le respect des droits d’auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11 Mars
1957 n’autorisant aux termes des alinéas 2 et 3 de l’article 41, d’une part, que les “copies ou reproductions strictement réservées à l’usage privé du copiste et non destinées
à une utilisation collective”, et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration, “toute représentation ou reproduction intégrale,
ou partielle, faite sans le consentement de l’auteur ou de ses ayants droit ou ayant cause, est illicite” (alinéa 1er de l’article 40). Cette représentation ou reproduction, par
quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal. Copyright Editions ENI
© ENI Editions - All rigths reserved - 1-

Introduction
La version 2008 de SQL Server apporte de nombreuses nouveautés que ce soit pour l’administrateur de bases de
données ou bien pour le développeur d’applications. La gestion des données dans le cadre de l’analyse décisionnelle
(Business Intelligence) n’est pas abordée dans cet ouvrage mais SQL Server 2008 propose également sur ce domaine
de nombreuses améliorations.
SQL Server est disponible pour les platesformes Windows Server en version 32 et 64 bits, mono ou multiprocesseur,
et il exploite les différents cœ urs de façon native. Le moteur de base de données est robuste et possède des capacités
remarquables de gestion des données lors des montées en charge.
Parmi les nombreux apports de SQL Server 2008, il est possible de citer l’intégration au PowerShell, le cryptage des
données, la compression des données et des sauvegardes, les déclencheurs de connexion, l’audit.
SQL Server 2008 intègre de façon native de nombreux outils qui font que SQL Server est plus qu’un simple serveur de
bases de données relationnelles.
Aussi l’administrateur de bases de données doitil posséder une bonne vue d’ensemble des possibilités offertes par les
différents composants de SQL Server afin de faire les bons choix en terme d’évolution. Ces éléments complémentaires
sont rarement installés par défaut et doivent l’être à la demande. En effet, il ne sert à rien d’installer des programmes
et/ou services sur le serveur si ces derniers ne sont pas utilisés. De même l’acquisition et l’utilisation d’un outil tiers
pour effectuer une tâche qui peut être réalisé par l’un des composants de SQL Server peut s’avérer ne pas être
judicieux tant au niveau des performances que de l’investissement.
SQL Server Management Studio reste l’outil principal de travail que ce soit pour l’administrateur ou bien pour le
développeur d’applications. Il est possible de faire l’administration de façon graphique, mais toutes les tâches peuvent
également l’être en utilisant des scripts Transact SQL. Chaque solution possède ses avantages et ses inconvénients.
C’est pourquoi les deux solutions sont exposées de façon quasisystématique dans ce livre. Pour les syntaxes Transact
SQL, seules les options les plus courantes seront précisées. L’objectif n’est pas de refaire la documentation mais de
présenter au mieux les différentes instructions.
SQL Server utilise sa propre structure de base de données pour stocker toutes les informations relatives à sa propre
gestion. Ces informations sont conservées dans les tables dites système. Toutefois comme la structure de ces tables
est amenée à être modifiée lors d’un changement de version, il est recommandé de ne pas interroger directement ces
tables mais d’utiliser les vues disponibles dans le schéma sys ou bien INFORMATION_SCHEMA. L’utilisation de ces vues
dans des requêtes d’extraction permettra de lire les informations conservées dans le dictionnaire des données.

Présentation de SQL Server
Le but de ce chapitre est de présenter SQL Server dans sa globalité et d’acquérir un aperçu de SQL Server dans son
ensemble, à savoir :
● comprendre la notion de SGBDR et le mode de fonctionnement client/serveur,
● présenter les composants de SQL Server et les platesformes d’exécution,
● présenter l’architecture d’administration et de programmation,
● présenter la notion de base de données et les bases installées sur le serveur SQL.
SQL Server est un SGBDR (Système de Gestion de Base de données Relationnelle) entièrement intégré à Windows, ce
qui autorise de nombreuses simplifications au niveau de l’administration, tout en offrant un maximum de possibilités.
1. Qu’estce qu’un SGBDR ?
SQL Server est un Système de Gestion de Base de Données Relationnelle (SGBDR), ce qui lui confère une très grande
capacité à gérer les données tout en conservant leur intégrité et leur cohérence.
SQL Server est chargé de :
● stocker les données,
● vérifier les contraintes d’intégrité définies,
● garantir la cohérence des données qu’il stocke, même en cas de panne (arrêt brutal) du système,
● assurer les relations entre les données définies par les utilisateurs.
Ce produit est complètement intégré à Windows et ce à plusieurs niveaux :
● Observateur des événements : le journal des applications est utilisé pour consigner les erreurs générées par
SQL Server. La gestion des erreurs est centralisée par Windows, ce qui facilite le diagnostic.
● Analyseur de performances : par l’ajout de nouveaux compteurs, il est facile de détecter les goulots
d’étranglement et de mieux réagir, pour éviter ces problèmes. On utilise toute la puissance de l’analyseur de
performances, et il est possible au sein du même outil de poser des compteurs sur SQL Server et sur
Windows et ainsi d’être à même de détecter le vrai problème.
● Traitements parallèles : SQL Server est capable de tirer profit des architectures mutiprocesseurs. Chaque
instance SQL Server dispose de son propre processus d’exécution et des threads Windows ou bien des fibres
(si l’option est activée) sont exécutés afin d’exploiter au mieux l’architecture matérielle disponible. Chaque
instance SQL Server exécute toujours plusieurs threads Windows. Pour prendre en charge tous les
processeurs présents sur le système, le paramètre de configuration max degree of parallelism doit
conserver la valeur 0. Il s’agit de la valeur par défaut. Pour empêcher la génération de plan d’exécution
parallèle, il suffit d’affecter la valeur 1 à ce paramètre. Enfin en lui affectant une valeur comprise entre 1 et le
nombre de processeurs, il est possible de limiter le degré de parallélisme. La valeur maximale supportée par
ce paramètre est 64.
● Sécurité : SQL Server est capable de s’appuyer intégralement sur la sécurité gérée par Windows, afin de
permettre aux utilisateurs finaux de ne posséder qu’un nom d’utilisateur et un seul mot de passe. Néanmoins
SQL Server gère son propre système de sécurité pour tous les clients non Microsoft.
● Les services Windows sont mis à contribution pour exécuter les composants logiciels correspondant au
serveur. La gestion du serveur (arrêt, démarrage et suspension) est facilitée et il est possible de profiter de
toutes les fonctionnalités associées aux services de Windows (démarrage automatique, exécution dans le
contexte d’un compte d’utilisateur du domaine...).

● Active Directory : les serveurs SQL 2008 et leurs propriétés sont automatiquement enregistrés dans le service
d’annuaire Active Directory. Il est ainsi possible d’effectuer des recherches dans Active Directory pour localiser
les instances SQL Server qui fonctionnent.
SQL Server peut gérer deux types de bases de données différentes :
● les bases OLTP (OnLine Transactional Processing) qui correspondent à des bases dans lesquelles les
informations sont stockées de façon directe afin de réutiliser plus tard ces informations telles qu’elles ont été
stockées.
● les bases OLAP (OnLine Analytical Processing) qui contiennent des informations statistiques afin d’être capable
d’extraire les informations sous forme de cube multidimensionnel dans un but d’aide à la décision par
exemple. Les statistiques contenues dans des bases OLAP s’appuient sur des informations contenues dans
une base OLTP.
2. Mode de fonctionnement Client/Serveur
Toutes les applications qui utilisent SQL Server pour gérer les données, s’appuient sur une architecture
client/serveur. L’application cliente est chargée de la mise en place de l’interface utilisateur. Cette application
s’exécute généralement sur plusieurs postes clients simultanément. Le serveur, quant à lui, est chargé de la gestion
des données, et répartit les ressources du serveur entre les différentes demandes (requêtes) des clients. Les règles
de gestion de l’entreprise se répartissent entre le client et le serveur.
Mode de fonctionnement Client/Serveur
On peut distinguer trois cas :
● les règles sont entièrement implémentées sur le client, appelé alors client lourd. Cette solution permet de
libérer des ressources au niveau du serveur, mais les problèmes de mise à jour des clients et de
développement d’autres applications se posent.
● les règles sont entièrement définies sur le serveur, le client est alors un client léger. Cette solution permet
d’obtenir des clients qui possèdent peu de ressources matérielles, et autorise une centralisation des règles
ce qui rend plus souples les mises à jour. Cependant de nombreuses ressources sont consommées sur le
serveur et l’interaction avec l’utilisateur risque d’être faible, puisque l’ensemble des contraintes est vérifié
lorsque l’utilisateur soumet sa demande (requête) au serveur.
● les règles d’entreprises sont définies sur une tierce machine, appelée Middle Ware, afin de soulager les
ressources du client et du serveur, tout en conservant la centralisation des règles.
- 2- © ENI Editions - All rigths reserved

L’architecture client/serveur permet un déploiement optimum des applications clientes sur de nombreux postes tout
en conservant une gestion centralisée des données (le serveur), ce qui rend possible le partage d’informations à
l’intérieur de l’entreprise.
Il est bien sûr possible d’avoir plusieurs applications clientes sur le même serveur de base de données. Cette
possibilité offre de nombreuses fonctionnalités, mais il faut toutefois veiller à ce que la charge de travail sur le serveur
ne soit pas trop importante au regard des capacités de la machine. Cette architecture client/serveur est respectée
par tous les outils permettant d’accéder à des informations contenues par le serveur SQL, donc les outils
d’administration, même s’ils sont installés sur le serveur.
Toutes les demandes en provenance des clients vers le serveur, doivent être écrites en TransactSQL. Ce langage de
requête de base de données respecte la norme ANSI SQL92. Le SQL fournit un ensemble de commandes pour gérer
les objets et manipuler les données dans les bases. Le Transact SQL est enrichi de nombreuses fonctionnalités, non
normalisées, afin d’étendre les possibilités du serveur. Il est ainsi possible de définir des procédures stockées sur le
serveur.
3. Les platesformes possibles
Il est important de distinguer deux cas : d’un côté les platesformes possibles pour le client et de l’autre les plates
formes pour le serveur.
Les platesformes clientes présentées ici sont les postes sur lesquels les outils d’administration SQL Server peuvent
être installés. Il ne s’agit pas des postes qui hébergent une application qui se connecte à une instance SQL Server
pour gérer les données.
D’une façon synthétique, les outils clients d’administrations peuvent être installés sur tous systèmes d’exploitation
Windows 2003, Windows XP Pro ou tout système plus récent.
Par contre, pour la partie serveur, les disponibilités en termes de platesformes sont fonctions de l’édition SQL Server
choisie. Néanmoins pour héberger une instance de base de données en production, il est nécessaire de disposer d’un
serveur performant et fiable. Une plateforme Windows 2003 est donc recommandée. L’édition de Windows 2003
sera choisie en fonction des contraintes imposées par l’édition SQL Server sélectionnée et des contraintes liées à
l’environnement technique. L’installation d’une instance sous Windows XP sera réservée à des postes nomades.

Dans le cas où le client héberge une application spécifique, la gamme des platesformes est considérablement élargie
grâce, en particulier, au pilote jdbc qui permet d’accéder à une instance SQL Server depuis une application écrite en
java. La gamme est encore élargie dans les cas d’une application ASPX qui propose une interface Internet. Un simple
navigateur Internet permet alors de lancer l’application.
4. Les composants de SQL Server
Le moteur de base de données de SQL Server ou Database Engine est composé de plusieurs logiciels. Certains
s’exécutent sous forme de services alors que d’autres possèdent une interface utilisateur graphique ou en ligne de
commande.
Composants Serveur
SQL Server s’exécute sous forme de services Windows. Suivant les options d’installation choisies, il peut y avoir plus
de services. Les principaux services sont :
● SQL Server : c’est le serveur de base de données à proprement parlé. Si ce service n’est pas démarré, il n’est
pas possible d’accéder aux informations. C’est par l’intermédiaire de ce service que SQL Server assure la
gestion des requêtes utilisateurs. Ce service est référencé sous le nom MSSQLSERVER pour l’instance par
défaut et MSSQLSERVER $nomInstance dans le cas d’une instance nommée.
● SQL Server Agent : ce service prend en charge l’exécution de tâches planifiées, la surveillance de SQL Server
et le suivi des alertes. Il est directement lié à une instance de SQL Server. Il est référencé dans le
gestionnaire de service sous le nom SQL Server Agent(MSSQLSERVER) pour l’instance par défaut et SQL
Server Agent(nomInstance) dans le cas d’une instance nommée.
● Microsoft Full Text Search : ce service propose de gérer l’indexation des documents de type texte stockés
dans SQL Server et gère également les recherches par rapport aux mots clés.

Il est possible d’installer plusieurs instances de SQL Server sur le même poste.
Connectivité Client
L’installation des composants de connectivité sur les postes clients permet de prendre en charge la gestion du
réseau, la DB Library pour les programmes en accès natif, le support OLEDB et ODBC.
Outils de gestion
Les réalisations des tâches d’administration sont possibles par l’utilisation d’outils. Ces outils possèdent pour la
plupart une interface graphique conviviale et d’utilisation intuitive. Cependant, les tâches administratives doivent être
réfléchies avant leur réalisation. L’utilisation de certains outils suppose que le composant serveur correspondant est
installé.
Ces outils sont :
● SQL Server Management Studio pour réaliser toutes les opérations au niveau du serveur de base de
données.
● SQL Server Configuration Manager pour gérer les services liés à SQL Server.
● SQL Server Profiler pour suivre et analyser la charge de travail d’une instance SQL Server.
● Database Engine Tuning Advisor pour permettre une optimisation du fonctionnement du serveur de base de
données.
En plus de ces outils, SQL Server propose Business Intelligence Development Studio pour la programmation de
travaux qui vont s’inscrire dans un cadre d’analyse multidimensionnelle des données.
Enfin, tous les outils et le fonctionnement de SQL Server sont richement documentés.
Les composants
Les différentes briques logicielles fournies par SQL Server s’articulent toujours autour du moteur de base de données
relationnelles qui traite de façon performante les informations stockées au format relationnel et au format xml.
● SQL Server Analysis Service permet une analyse poussée des cubes de données définis par l’intermédiaire du
Business Intelligence Development Studio.
● SQL Server Integration Service (SSIS) est un outil d’importation et d’exportation de données facile à mettre
en place tout en étant fortement paramétrable.
● Reporting Services permet de mettre en place des rapports d’analyse des données.
● La réplication des données sur différentes instances permet de positionner les données au plus près des
utilisateurs et de réduire les temps de traitement.
● Service Broker permet un travail en mode asynchrone et facilite ainsi la gestion des pics de forte activité en
stockant les demandes de travail avant de les traiter.
● L’intégration du CLR dans SQL Server permet de développer procédures et fonctions en utilisant les langages

VB.Net et C#. L’intégration du CLR ne vient pas se substituer au Transact SQL mais se présente comme un
complément afin de pouvoir réaliser un codage simple et performant pour l’ensemble des fonctionnalités qui
doivent être présentes sur le serveur.
● Les points de terminaison http permettent à SQL Server d’héberger ses propres services et de faciliter ainsi
l’intégration du serveur dans un contexte hétérogène.
Mémoire AWE
Une meilleure gestion de la mémoire est proposée avec la mise en place de l’API AWE qui permet de gérer, sur des
systèmes 32 bits, plus de 4 Go de mémoire. L’édition entreprise est ainsi capable de gérer jusqu’à 64 Go de mémoire.
La prise en charge de AWE est possible en activant l’option de configuration awe enabled avec sp_configure.
awe enabled est une option de configuration avancée.
Dans le cas où la gestion de la mémoire AWE est activée, SQL Server peut, par l’intermédiaire de Windows 2003,
prendre en charge un ajout de mémoire à chaud. Ceci est possible uniquement si la plateforme matérielle permet de
réaliser une telle opération.
Dans le cas où SQL Server s’exécute sur une plateforme Windows Server 2003 ou 2008 la gestion de la
mémoire AWE est dynamique. Par contre, dans le cas d’une exécution sous Windows 2000 la gestion de
cette mémoire est statique.
Reporting Services
Reporting Services permet la création de rapports pour présenter au mieux les informations contenues dans SQL
Server. Ces rapports, hébergés sur un serveur IIS, peuvent être conçus par l’intermédiaire du générateur de rapport
du Business Intelligence Development Studio.
Les rapports sont disponibles au format HTML mais ils peuvent exister au format pdf. La gestion de ces rapports au
niveau sécurité, planification des régénérations... est assurée par Reporting Services.
Analysis Services
Analysis Services est un outil permettant la construction des cubes multidimensionnels d’analyse des données.
Quelques fonctionnalités OLAP étaient déjà présentes dans les versions précédentes de SQL Server mais avec
Analysis Services, SQL Server permet de réaliser des analyses complètes des cubes d’analyses qui peuvent être
définis.
Pour améliorer les performances de traitement des cubes il est possible d’installer plusieurs instances du moteur
Analysis Service sur le même serveur.
Analysis Service s’appuie intégralement sur l’interface Business Intelligence Development Studio.
Terminaisons http
Les terminaisons http permettent à SQL Server de répondre de façon directe à des requêtes http, c’estàdire sans
passer par l’intermédiaire d’un serveur IIS. SQL Server offre ainsi la possibilité d’exposer des procédures et des
fonctions au travers de services Web.
Les points de terminaisons http ne sont disponibles que si SQL Server s’exécute sur une plateforme
Windows 2003 ou Windows 2008.
Service Broker
Service Broker permet une gestion asynchrone des requêtes. Plus exactement, Service Broker permet à une
application cliente d’envoyer de nombreuses demandes de services et SQL Server peut traiter ces demandes
(message) les unes après les autres. La mise en attente des messages permet de réguler la charge de travail sur le
serveur et d’absorber certaines pointes d’activités ponctuelles.
Service Broker dispose d’un mécanisme sécurisé qui lui permet de garantir le traitement des messages. Service
Broker utilise SQL Server pour conserver la file d’attente des messages non encore traités.
CLR
L’intégration du CLR (Common Language Runtime) à SQL Server, permet d’augmenter considérablement les
possibilités offertes en terme de programmation. La présence du CLR ne remet pas en cause le Transact SQL. Chacun

est complémentaire. Le Transact SQL est parfait pour écrire des procédures ou fonctions pour lesquelles il y a un
traitement intensif des données. Au contraire, dans le cas où le volume des données manipulées est faible, le CLR
permet d’écrire simplement des traitements complexes, car il bénéficie de toute la richesse du CLR.
Le CLR permet également de définir ses propres types de données ou bien de nouvelles fonctions de calcul
d’agrégat.
Enfin, le CLR permet aux développeurs d’applications de développer des procédures et fonctions sur SQL Server tout
en conservant leurs langages favoris (VB.Net ou C# par exemple), et donc sans avoir besoin de maitriser le Transact
SQL.
Dans le cas où le code est écrit depuis Visual Studio, l’intégration de la version compilée dans SQL Server et le
mappage CLRTransact SQL est réalisé de façon automatique. Il est possible de réaliser le développement en dehors
du Visual Studio mais l’intégration à SQL Server sera faite de façon manuelle, ce qui est une tâche fastidieuse.

Architecture
1. Administration
Le langage naturel de SQL Server est le Transact SQL. Il est donc nécessaire de lui transmettre les instructions dans
ce langage. Comme ce langage n’est pas forcément naturel pour l’utilisateur, il est possible de composer l’instruction
de façon graphique par SQL Server Management Studio, puis de provoquer son exécution sur le serveur à l’aide des
boutons OK, Appliquer... Les outils graphiques utilisent la bibliothèque SMO (SQL Server Management Object) pour
établir un dialogue efficace avec le serveur.
SQL SMO englobe et étend SQL DMO. La bibliothèque SMO est donc compatible avec SQL Server 7, SQL Server 2000,
2005 et 2008.
Il est donc possible d’écrire des scripts Transact SQL pour exécuter des opérations administratives sous forme de
traitement batch.
Administration de SQL Server
2. Programmation
Le développement d’applications clientes pour visualiser les données contenues dans le serveur peut s’appuyer sur
différentes technologies.
La DLL SQL Native Client est une méthode d’accès aux données qui est disponible aussi bien en utilisant la

technologie OLEDB ou bien ODBC pour accéder aux données. Avec cette nouvelle API, il est possible d’utiliser
l’ensemble des fonctionnalités de SQL Server comme les types personnalisés définis avec les CLR (UDT : User Defined
Type), MARS ou bien encore le type xml.
SQL Native Client est une API qui permet de tirer pleinement profit des fonctionnalités de SQL Server et de posséder
un programme qui accède de façon optimum au serveur.
Il est toujours possible d’utiliser les objets ADO pour accéder à l’information. Ce choix est plus standard car un
programme accédant à une source de données ADO peut travailler aussi bien avec une base Oracle que SQL Server,
mais ne permet pas la même gestion de toutes les fonctionnalités offertes par SQL Server. L’API SQL Native Client
permet l’écriture de programmes clients optimisés mais uniquement capables d’accéder à des données hébergées par
un serveur SQL Server.
SQL Native Client sera adopté comme modèle d’accès aux données dans les nouveaux programmes écrits en VB.Net
ou C# qui souhaitent travailler avec SQL Server mais aussi dans les programmes existants lorsque ces derniers
souhaitent travailler avec des éléments spécifiques à SQL Server, comme le type XML, par exemple.
Ce modèle de programmation correspond à une application client qui souhaite gérer les données. Dans le cas où
l’application souhaite être capable de faire des opérations d’administration, il est alors nécessaire d’utiliser la
bibliothèque SMO.

Base de données SQL Server
1. Objets de base de données
Les bases de données contiennent un certain nombre d’objets logiques. Il est possible de regrouper ces objets en
trois grandes catégories :
● Gestion et stockage des données : tables, type de données, contraintes d’intégrité, valeur par défaut, règles
et index.
● Accès aux données : vues et procédures stockées.
● Gestion de l’intégrité complexe : déclencheur (procédure stockée s’exécutant automatiquement lors de

l’exécution d’un ordre SQL modifiant le contenu d’une table : INSERT, UPDATE et DELETE). Le déclencheur est
toujours associé à une table et à une instruction SQL. Il permet de mettre en place des règles d’intégrité
complexes à cheval sur plusieurs tables ou de maintenir des données non normalisées.
Objet de base de données
Nom complet des objets
La règle appliquée pour nommer les objets permet une parfaite identification. Le nom complet est composé comme
suit : serveur.nomBase.propriétaire.objet. Par défaut, seul le nom de l’objet est précisé. Cette notion sera détaillée au
cours du chapitre Gestion de la base de données.
2. Bases de données système et tables système
Pour gérer l’ensemble des données stockées, SQL Server s’utilise luimême. Il existe donc des bases de données
système et sur chaque base utilisateur, quelques tables système. L’insertion et la mise à jour de données dans ces
tables ne s’effectuent jamais directement, mais via des commandes Transact SQL ou des procédures stockées.

Organigramme des bases de données
Les noms des bases de données et des tables systèmes sont fixés et connus par SQL Server. Il ne faut donc
pas renommer une table ou une base système.
Master
C’est la base de données principale de SQL Server. L’ensemble des données stratégiques pour le bon
fonctionnement du serveur y est stocké (comptes de connexion, options de configuration, l’existence des bases de
données utilisateurs et les références vers les fichiers qui composent ces bases...).
Model
Cette base contient l’ensemble des éléments inscrits dans toute nouvelle base utilisateur. Par défaut, il n’y a que les
tables système, mais il est possible de rajouter des éléments.
Tempdb
La base Tempdb est un espace temporaire de stockage partagé. Il permet de gérer les tables temporaires locales ou
globales, les tables de travail intermédiaires pour faire des tris par exemple, mais aussi les jeux de résultats des
curseurs. La base Tempdb est recréée, avec sa taille initiale, lors de chaque démarrage de l’instance. Ainsi, aucune
information ne peut être conservée de façon persistante à l’intérieur de la base Tempdb. Les objets temporaires
sont, quant à eux, supprimés lors de la déconnexion de leur propriétaire.
Msdb
Elle contient les informations utilisées par le service SQL Server Agent pour déclencher une alerte, prévenir un
opérateur ou exécuter une tâche planifiée. Msdb contient également l’historique de l’exécution des tâches.
Ressource
Cette base en lecture seule contient la définition de tous les nouveaux éléments définis à partir de SQL Server 2005.
Les objets systèmes y sont définis bien que logiquement ils apparaissent dans le schéma de l’utilisateur sys. Avec
cette base, la migration de SQL Server 2000 vers SQL Server 200x est facilitée, car l’ajout simple de la base ressource
permet d’obtenir l’ensemble des objets définis dans SQL Server 2005 sans qu’il soit nécessaire de toucher à la base

master.
Bases de données utilisateur
Les bases de données utilisateurs vont héberger les données fournies par les utilisateurs. Les bases présentes sur
le schéma précédent (AdventureWorks et Gescom) sont les bases d’exemples utilisées dans la documentation
officielle de SQL Server et dans cet ouvrage.
3. Les tables système
Les tables système sont toujours présentes dans SQL Server. Cependant, il est recommandé de ne pas travailler
directement avec ces tables. Pour rechercher l’information, il faut passer par le schéma d’information et plus
exactement les vues définies sous le schéma de l’utilisateur sys lorsque cela est possible.
Dans le tableau cidessous, quelques tables système sont référencées.
Catalogue système (présent uniquement dans la base Master)
Table système Fonction
syslogins Une ligne pour chaque utilisateur ou groupe Windows autorisé à

se connecter au serveur SQL.
sysmessages Une ligne pour chaque message d’erreur défini et pour chaque
langue.
sysdatabases Une ligne par base de données utilisateur.
sysconfigures Une ligne pour chaque option de configuration du serveur.
sysusers Une ligne pour chaque utilisateur défini dans la base.
syscolumns Une ligne pour chaque colonne des tables, vues et pour chaque
paramètre des procédures stockées.
sysobjects Une ligne pour chaque objet de la base de données.
Les tables système sont utilisées directement par le moteur de SQL Server. Les applications qui utilisent SQL Server
ne doivent en aucun cas accéder directement à ces tables, même en lecture. En effet, comme la structure de ces
tables évolue avec les versions de SQL Server, si certaines applications accèdent de façon directe aux tables
système, on peut se trouver dans l’impossibilité de migrer vers une nouvelle version de SQL Server tant que
l’application n’a pas été réécrite.
SQL Server ne prend pas en compte les déclencheurs qui pourraient être définis sur les tables système car ils
peuvent gêner le bon déroulement de certaines opérations.
4. Extraction de métadonnées
Pour interroger les données contenues dans les tables système, il est déconseillé de le faire directement par une
requête de type SELECT. Il est préférable de passer par l’utilisation de procédures stockées, de fonctions système et
de vues du schéma d’information.
En tant qu’administrateur, il est possible de modifier le contenu des tables système. Cette opération est à
proscrire car elle peut avoir des conséquences irréversibles et dramatiques. Le seul moyen de remédier à un
tel problème sera alors de restaurer une sauvegarde.
Procédures stockées système
Les procédures stockées système sont maintenues, pour la plupart, pour des raisons de compatibilité ascendante.
Leur utilisation est donc à déconseiller.
Pour interroger les tables système, il existe de nombreuses procédures stockées. Elles commencent toutes par sp_.

Parmi toutes les procédures stockées, citons :
Procédure stockée Description
sp_help [nom_objet] Informations sur l’objet indiqué.
sp_helpdb [nom_base_données] Informations sur la base de données indiquée.
sp_helpindex [nom_table] Informations sur les index de la table indiquée.
sp_helplogins [nom_connexion] Informations sur la connexion indiquée.
sp_who Liste des utilisateurs actuellement connectés.
Le catalogue
SQL Server propose des vues système qui permettent d’obtenir des informations système. Toutes ces vues sont
présentes dans le schéma sys.
Afin de naviguer au mieux dans ces vues, elles sont regroupées par thèmes :
● Objets, types et index
● Serveurs liés
● CLR
● Mise en miroir
● Service Broker
● Sécurité
● Transactions

● Configuration du serveur
● Information sur le serveur
● Environnement d’exécution
● Stockage
● Point de terminaisons
● Partitionnement
● Traces et évènements
Fonctions système
Les fonctions système sont utilisables avec des commandes Transact SQL. Il est ainsi possible de récupérer des
valeurs concernant la base de données sur laquelle on travaille, sur le serveur ou sur les utilisateurs.
Citonsen quelquesunes :
Fonctions système Paramètre Description
DB_ID Nom Retrouve l’identificateur de la base de données.
USER_NAME ID Retrouve le nom de l’utilisateur à partir de son

identifiant.
COL_LENGTH Colonne Longueur de la colonne.
STATS_DATE Index Date de dernière mise à jour des statistiques.
DATALENGTH Type de données Longueur de l’expression.
Schéma d’information

Il s’agit d’un ensemble de vues qui proposent une visualisation des paramètres de façon indépendante des tables
système. En ne faisant pas directement référence aux tables système, on se préserve des modifications qui peuvent
intervenir sur leurs structures lors des prochaines versions. De plus, ces vues sont conformes à la définition du
standard ANSI SQL pour les schémas d’information. Chaque vue présente des métadonnées pour l’ensemble des
objets contenus dans la base de données.
Les vues du schéma d’information :
CHECK_CONSTRAINTS
Visualise l’ensemble des contraintes de type CHECK définies dans la base de données.
COLUMN_DOMAIN_USAGE
Visualise l’ensemble des colonnes définies sur un type de données utilisateur.
COLUMN_PRIVILEGE
Visualise l’ensemble des privilèges accordés, au niveau colonne, pour l’utilisateur courant ou pour un utilisateur de la
base de données.
COLUMNS
Visualise la définition de l’ensemble des colonnes accessibles, dans la base de données courante, à l’utilisateur
actuel.
CONSTRAINT_COLUMN_USAGE
Visualise l’ensemble des colonnes pour lesquelles il existe une contrainte.
CONSTRAINT_TABLE_USAGE
Visualise l’ensemble des tables pour lesquelles au moins une contrainte est définie.
DOMAIN_CONSTRAINTS
Visualise l’ensemble des types de données utilisateurs, qui sont accessibles par l’utilisateur courant et qui sont liés à
une règle.
DOMAINS
Visualise l’ensemble des types de données utilisateurs, qui sont accessibles par l’utilisateur courant.
KEY_COLUMN_USAGE
Visualise l’ensemble des colonnes pour lesquelles une contrainte de clé est définie.
PARAMETERS
Visualise les propriétés des paramètres des fonctions définies par l’utilisateur et des procédures stockées accessibles
à l’utilisateur courant. Pour les fonctions, les informations relatives à la valeur de retour sont également visualisées.
REFERENTIAL_CONSTRAINTS
Visualise l’ensemble des contraintes de clés étrangères définies dans la base de données courante.
ROUTINES
Visualise l’ensemble des procédures stockées et des fonctions accessibles à l’utilisateur courant.
ROUTINE_COLUMNS
Visualise les propriétés de chaque colonne renvoyées par les fonctions accessibles à l’utilisateur courant.
SCHEMATA

Visualise les bases de données pour lesquelles l’utilisateur courant possède des autorisations.
TABLE_CONSTRAINTS
Visualise les contraintes de niveau table, posées dans la base de données courante.
TABLE_PRIVILEGES
Visualise l’ensemble des privilèges accordés à l’utilisateur actuel dans la base de données courante et l’ensemble des
privilèges accordés par l’utilisateur actuel à d’autres utilisateurs de la base de données courante.
TABLES
Visualise l’ensemble des tables de la base de données courante pour lesquelles l’utilisateur actuel dispose de droits.
VIEW_COLUMN_USAGE
Visualise l’ensemble des colonnes de tables qui sont utilisées dans la définition d’une ou plusieurs vues.
VIEW_TABLE_USAGE
Visualise l’ensemble des tables de la base de données courante qui sont utilisées lors de la définition de vues.
VIEWS
Visualise l’ensemble des vues accessibles à l’utilisateur actuel dans la base de données courante.
5. Les tâches de l’administrateur
L’administrateur de bases de données a pour objectif principal d’améliorer le fonctionnement de la base de données.
Bien que SQL Server possède de nombreux outils et algorithmes d’autooptimisation, il reste de nombreuses tâches à
l’administrateur.
Les principales tâches de l’administrateur sont :
● Gérer les services SQL Server ;

● Gérer les instances SQL Server ;
● Mettre en place le processus de sauvegarde et de restauration ;
● Configurer une disponibilité des données en accord avec la politique d’entreprise ;
● Gérer les configurations réseaux ;
● Importer et exporter des données.
En plus des compétences système que doit posséder l’administrateur pour être capable de gérer au mieux l’instance
SQL Server, il est important pour lui de connaître les possibilités offertes par SQL Server pour l’automatisation des
tâches avec SQL Agent.
Pour mesurer le résultat de son travail et comparer les différents choix de configuration qu’il peut être amené à faire,
l’administrateur doit être en mesure d’utiliser les outils et méthodes liés à SQL Server.
Enfin et c’est sans doute un point crucial, l’administration de la base doit être inscrite dans un processus plus global
qui intègre l’administrateur dès la conception de la base, de façon à effectuer les meilleurs choix en terme
d’architecture dès la conception. L’administrateur pourra ainsi intervenir sur la création de la base et les choix faits
comme, par exemple, le nombre de groupe de fichiers à utiliser, les index, les vues, les procédures stockées à définir
de façon à optimiser le trafic réseau mais aussi pour simplifier la gestion des droits d’accès. C’est également
l’administrateur qui va pouvoir conseiller sur le partitionnement ou non d’une table.

Installer SQL Server
L’installation de SQL Server permet de présenter les différentes éditions de SQL Server ainsi que de détailler les options
d’installation possibles. Un point tout particulier sera mis en place pour détailler l’exécution des services associés à SQL
Server (logiciels serveur). Une fois le serveur installé, il faut s’assurer que l’installation s’est déroulée correctement puis
il faut configurer le serveur et certains outils clients pour réaliser les différentes étapes d’administration.
Bien que facile à réaliser, l’installation de SQL Server doit être une opération réfléchie. En effet, de nombreuses options
d’installation existent et leur choix doit correspondre à un réel besoin, ou permettre de couvrir une évolution future du
système.
1. Les éditions de SQL Server
SQL Server est disponible sous la forme de plusieurs éditions. Chaque édition se distingue par des caractéristiques
spécifiques. En fonction des possibilités souhaitées, le choix se portera sur une édition ou bien une autre.
Certaines éditions (standard et entreprise) sont plus destinées à la gestion des données d’une entreprise tandis que
certaines éditions (developer, workgroup, web, express) ont pour objectif de satisfaire des besoins bien particuliers.
Toutes ces éditions de SQL Server sont disponibles pour des platesformes 32 et 64 bits. Enfin, l’édition compact est
quant à elle destinée aux périphériques mobiles.
Entreprise
L’édition Entreprise est la plus complète. Elle propose l’ensemble des fonctionnalités disponibles avec SQL Server.
Cette édition est conçue pour être capable de gérer des volumes très importants en termes de données et de
transactions avec de nombreux utilisateurs connectés.
Cette édition est disponible pour les platesformes 32 et 64 bits (x86, x64 et IA64).
Cette édition dispose également des fonctionnalités avancées en ce qui concerne les opérations de business
intelligence.
L’édition entreprise se distingue des autres éditions sur les points suivants :
● Supporte jusqu’à 50 instances de SQL Server ;
● Prise en charge du partitionnement et de la parallélisation ;
● Supporte la compression des données ;
● Dispose du gouverneur de ressources ;
● Propose la mise en miroir de bases de données et une récupération automatique à partir du miroir ;
● Permet de gérer des clusters ;
● Autorise la création d’index en ligne ;
● Permet la restauration en ligne des fichiers et des pages altérés ;
● Autorise la création de sauvegardes compressées ;
● Propose un haut niveau de sécurité (chiffrement transparent des données) et d’audit ;
● Prend en charge les différents types de réplication y compris vers des clients Oracle.
Standard
Cette édition, plus simple que l’édition entreprise, a pour objectif de répondre aux besoins d’une entreprise qui
cherche un moteur de base de données performant et qui n’a pas besoin des fonctionnalités spécifiques de l’édition
entreprise.
C’est également une édition standard qui est mise à disposition dans SBS (Small Business Server) afin de travailler

dans un environnement de moins de 75 postes.
Les principaux points forts de cette édition sont :
● La possibilité d’avoir 16 instances maximum ;
● La prise de compte des bases de données miroir ;
● La possibilité de définir des réplications ;
● La gestion par les stratégies ;
● Importation de données via SSIS (SQL Server Integration Services).
Express
L’édition Express de SQL Server 2008 possède la particularité d’être utilisable en production sans qu’il soit nécessaire
de s’acquitter d’une licence de SQL Server. Cette version n’est pas une version dégradée de SQL Server, mais il s’agit
bien du moteur SQL Server pleinement fonctionnel. Il n’existe pas de limite quant au nombre d’utilisateurs connectés.
Les seules limitations qui existent concernent le volume de données : 4 Go et le fait que le moteur ne puisse pas
exploiter plus d’un gigaoctets de mémoire. Il est toutefois raisonnable de penser que lorsqu’une application atteint ces
limites, l’entreprise possède les moyens nécessaires pour acquérir une version complète de SQL Server.
Cette édition express est à conseiller sans modération auprès des développeurs d’applications car il sera possible de
migrer très simplement vers une édition supérieure de SQL Server.
Ce type d’édition est également bien adapté pour les applications autonomes. En effet, l’édition express peut être
installée sur une plateforme Windows utilisateur, comme par exemple l’ordinateur portable d’un commercial qui
emmène avec lui la base de tous les articles de l’entreprise. Cette base peut être mise à jour par le processus de
réplication de SQL Server qui permet de synchroniser les données au niveau du catalogue et de les injecter dans le
Système d’Information de l’entreprise.
Cette édition est également utile dans la cadre d’une application monoposte qui nécessite une gestion robuste et
fiable des données. Choisir d’utiliser SQL Server pour ce type d’application permet de laisser ouvert le passage vers
une gestion multiutilisateur.
SQL Server 2008 propose également une édition Express Advanced qui propose les mêmes fonctionnalités que
l’édition express enrichie de la possibilité d’effectuer des rapports.
Developer
En plus de toutes ces éditions de production, SQL Server propose également une édition Developer. Cette édition
Developer comprend l’ensemble des fonctionnalités proposées par l’édition Entreprise. Toutefois, avec une édition
Developer, la mise en production n’est pas légale. Comme son nom l’indique, la version Developer permet à l’équipe de
développement d’application de faire ses tests sur une base pleinement fonctionnelle sans pour autant être dans
l’obligation d’acquérir une licence de production.
Compact 3.5
Il s’agit de l’édition de SQL Server destinée à être installée sur des terminaux mobiles. Il s’agit d’une base de données
gratuite et parfaitement adaptée pour le développement d’applications autonomes. Il est possible de faire participer
cette édition à un processus de réplication afin de synchroniser efficacement les données de l’entreprise avec celles
présentes sur le terminal.
Workgroup
Cette édition est destinée à la gestion des données à destination d’un groupe de travail ou bien d’un service de
l’entreprise. Les processus relatifs à l’analyse décisionnelle ne sont pas présents, toutefois cette édition permet de
définir des rapports. Avec cette édition, il n’est pas possible d’exploiter plus de 4 Go de mémoire vive.
Web
Centrée sur la gestion de données, cette édition permet d’offrir un moteur de base de données à destination des sites
web à faible coût. Les possibilités en termes d’administration sont réduites. Les fonctionnalités décisionnelles et la
création de rapports ne sont pas disponibles sur cette édition. Cette édition peut participer à un processus de
réplication, uniquement en tant qu’abonné.
2. Déroulement de l’installation

Comme pour de nombreux produits le processus d’installation se déroule en trois temps bien distincts :
● L’analyse de l’environnement et l’installation de composants nécessaires à la bonne exécution du processus

d’installation.
● Le paramétrage des différents composants à installer.
● L’installation des composants sélectionnés au préalable.
Le processus d’installation commence par s’assurer que la version 3.5 du Framework .Net est bien présente sur le
système et lance son installation si ce n’est pas le cas.
Par la suite, le premier écran permet de planifier au mieux l’installation de SQL Server 2008 en consultant la
documentation relative aux différents cas possibles d’installation/migration de données et en s’assurant que la plate
forme choisie est prête pour une installation de SQL Server 2008. Ce dernier point est assuré par l’outil d’analyse de
configuration système. Lors du processus d’installation d’une nouvelle instance de SQL Server 2008, l’outil d’analyse
de configuration système est également exécuté. Après saisie de la clé du produit et acceptation du contrat de licence,
les fichiers de support du programme d’installation de SQL Server sont installés.
Le processus d’installation de SQL Server 2008 commence par exécuter un certain nombre de règles afin de valider la
configuration de la plateforme.
Si ces règles ne sont pas parfaitement respectées il en ressort soit des avertissements, soit des erreurs. Un
avertissement permet de préciser que bien qu’il soit possible d’installer une instance SQL Server, certains composants
ne pourront pas être installés.
a. Choix des composants
Avant de procéder au paramétrage de l’installation, SQL Server demande de sélectionner les composants qui vont
être installés sur le poste local. C’est à ce niveau qu’il est possible de définir que seuls les outils doivent être
installés, ou bien le moteur de base de données.
Il s’agit de sélectionner finement les composants à installer. Il ne s’agit pas de cocher toutes les options, mais bien
de sélectionner les composants (client ou serveur) qui vont être effectivement utilisés. En limitant le nombre de
composant installés, la surface d’attaque du système est réduite et l’on évite également une surcharge du système
par des composants non utilisés. Bien entendu, si certains composants n’ont pas été sélectionné lors de l’installation
initiale et que le besoin s’en fait sentir par la suite, il est possible de les ajouter.

Pour chacun des composants, il est possible de définir son emplacement physique sur le disque dur. Pour accéder à
cet écran de configuration, il faut sélectionner le bouton .
b. Nom de l’instance
MS SQL Server offre la possibilité d’installer une ou plusieurs instances du moteur de base de données sur le même
serveur. Chaque instance est complètement indépendante des autres installées sur le même serveur et elles sont
gérées de façon autonome. Lorsque plusieurs instances sont présentes sur le même serveur, il est nécessaire
d’utiliser le nom de chacune d’entreelles pour les distinguer. La première instance installée est généralement
l’instance par défaut et elle porte le même nom que le serveur sur lequel elle est installée.

Les autres instances porteront alors un nom. Après le choix du nom de l’instance à installer, le processus
d’installation vérifie les capacités disque du système.
Un même serveur ne peut héberger qu’une seule instance par défaut.
Chaque instance est parfaitement identifiée par son nom. Le nom de l’instance respecte les règles suivantes :
● le nom de l’instance est limité à 16 caractères ;
● les majuscules et les minuscules ne sont pas différenciées ;
● le nom de l’instance ne peut pas contenir les mots DEFAULT et MSSQLSERVER, ainsi que tout autre mot
réservé ;
● le premier caractère du nom de l’instance doit être une lettre (A à Z) ou bien le trait de soulignement (_) ;
● les autres caractères peuvent être des lettres, des chiffres ou bien le trait de soulignement (_) ;
● les caractères spéciaux tels que l’espace, l’anti slash (\), la virgule, les deux points, le pointvirgule, la simple
cote, le "et" commercial (&) et l’arobase (@) ne sont pas autorisés dans le nom d’une instance.
c. Les services SQL Server
En fonction des choix faits lors de l’installation, il peut y avoir jusqu’à 10 services de créés :
● SQL Server Database Services ;
● Agent SQL Server ;
● Analysis Services ;
● Reporting Services ;

● Integration Services ;
● Recherche de texte intégral ;
● Navigateur SQL Server ;
● SQL Server Active Directory Helper ;
● SQL Writer.
Certains de ces services sont liés à l’instance SQL Server installée. C’est par exemple le cas pour SQL Server
Database Services et l’Agent SQL Server. Certains services comme Reporting Services sont directement liés à des
utilisations particulières de SQL Server, ici c’est le cas de la Business Intelligence.
Dans le cadre de cet ouvrage, ce sont principalement les services SQL Server Database Services et l’Agent SQL
Server qui vont être étudiés.
Service Nom pour l’instance par défaut Nom pour une instance nommée
Microsoft SQL Server MSSQLSERVER MSSQL$NomInstance
Agent SQL Server SQLSERVERAGENT SQLAgent$NomInstance
Compte Local Système et compte d’utilisateur
Les logiciels côté serveur s’exécutent sous forme de services. Comme tous les services, pour accéder aux ressources
de la machine, ils utilisent le contexte d’un compte d’utilisateur du domaine. Par défaut les services s’exécutent dans
le contexte du compte Local System. Ce compte permet d’obtenir toutes les ressources de la machine locale, mais il
ne permet pas d’accéder à des ressources du domaine.
Les deux services, que sont MS SQL Server et SQL Server Agent doivent être capables d’accéder à des ressources du
domaine, afin de pouvoir utiliser toutes les fonctionnalités proposées par SQL Server (gestion des tâches planifiées,
réplication...). Lors de l’installation il est possible de préciser le compte d’utilisateur du domaine qui sera utilisé pour
les deux services.
Pour simplifier les opérations de gestion, il est recommandé d’utiliser le même compte Windows pour les deux
services.
Le même compte pourra également être utilisé pour le service de Recherche de texte intégral.
Si l’entreprise comporte plusieurs serveurs SQL dans plusieurs domaines, il est préférable que tous les services SQL
Server s’exécutent en utilisant un compte d’utilisateur de domaine portant le même nom et avec le même mot de
passe.

Compte d’ouverture de session
Démarrage automatique des services
Il est possible de paramétrer les services de SQL Server de façon à ce qu’ils démarrent automatiquement lors du
démarrage de Windows. L’avantage de cette option est qu’il n’est pas nécessaire d’ouvrir une session sur le poste
en tant qu’administrateur, pour lancer les services du SGBDR. Lors de chaque démarrage de Windows, les bases
gérées par le SGBDR sont immédiatement accessibles.
Ces deux options : Comptes de services et Démarrage automatique de service peuvent être fixées lors de
l’installation de SQL Server ou bien une fois que SQL Server est installé au travers des outils d’administration.

d. Paramètres de classement
La langue par défaut de l’instance de SQL Server va avoir une incidence directe sur le classement sélectionné.
Il est possible d’installer SQL Server quelle que soit la langue définie au niveau du système d’exploitation.
Il faut veiller à ne pas confondre la page de code et le classement.
La page de code est le système de codage des caractères retenus. La page de code permet d’identifier 256
caractères différents. Compte tenu de la diversité des caractères utilisés d’une langue à l’autre, il existe de
nombreuses pages de code. Pour pouvoir prendre en compte des données exprimées dans différentes langues, il est
possible d’utiliser le système UNICODE. Ce système de codage des caractères permet d’utiliser deux octets pour
coder chaque caractère. Le système Unicode permet donc de coder 65536 caractères différents ce qui est suffisant
pour coder la totalité des caractères utilisés par les différentes langues occidentales.
Cette solution avec les pages de codes n’est acceptable que si l’on stocke dans la base de données uniquement des
données en provenance d’une seule langue. Or, avec la montée en puissance des applications de commerce
électronique, les bases de données vont de plus en plus souvent contenir des informations (comme les nom, prénom
et adresse des clients) en provenance de différentes langues. Pour pouvoir supporter les caractères spécifiques à
chaque langue, il faut utiliser le type de données Unicode. Les données de type Unicode sont conservées dans les
types nchar et nvarchar. Au niveau de l’application cliente, qui permet la saisie et l’affichage des informations, le
type de données Unicode doit également être supporté.
L’espace réclamé par le type de données Unicode est deux fois plus important que pour les données non
Unicode. Mais, ce léger désavantage est largement compensé par le temps gagné lors de l’affichage des
données sur le poste client. En effet, avec le type de données Unicode, il n’est plus nécessaire de réaliser un
mappage entre la page de code utilisée dans la base de données pour stocker l’information, et la page de code
utilisée sur le poste client pour afficher l’information.
Le classement correspond à un modèle binaire de représentation des données et qui permet de définir des règles de
comparaisons ainsi que des règles de tris. Par exemple, le classement permet de définir sur la langue française
comment les caractères accentués doivent être pris en compte lors d’opération de comparaison et de tris.
Il existe par défaut trois types de classements :
● les classements Windows qui s’appuient sur les paramètres de langues définies au niveau Windows. En
s’appuyant sur ce type de classement, les ordres de tris, de comparaisons s’adaptent automatiquement à la
langue du serveur.

● Les classements binaires sont réputés pour leur rapidité de traitement. Ils sont basés sur le code binaire
utilisé pour enregistrer chaque caractère d’information au format unicode ou non.
● Les classements SQL Server sont présents pour assurer une compatibilité ascendante avec les versions
précédentes de SQL Server. Il est donc préférable de ne pas faire ce choix dans le cadre d’une nouvelle
installation.
Un classement doit nécessairement être précisé lors de la création de l’instance, il deviendra le classement par
défaut de l’instance et sera utilisé par les bases de données master, msdb, tempdb, model et distribution.
Lors de la création des bases de données utilisateurs, il sera possible de préciser un autre classement par
l’intermédiaire de la clause COLLATE.
Comme les classements contrôlent l’ordre de tri des données Unicode et non Unicode, il n’est pas possible
de définir des ordres de classement incompatibles.
Fixer les paramètres de classement
Il est possible de connaître le classement adopté au niveau du serveur par l’intermédiaire de la fonction
SERVERPROPERTY, comme illustré dans l’exemple cidessous :

Il est également possible de connaître l’ensemble des classements disponibles sur le serveur en utilisant la fonction :
fn_helpcollations().
ATTENTION : le respect de la casse s’applique aussi bien aux identificateurs qu’aux données. Si l’on choisit
l’ordre de tri binaire avec le respect de la casse, alors toutes les références aux objets doivent être réalisées
en utilisant la même casse que celle spécifiée lors de la création de ces objets.
e. Mode d’authentification
La gestion des comptes d’utilisateur peut s’appuyer intégralement sur les comptes des utilisateurs Windows mais il
est aussi possible de définir des comptes d’utilisateur et de les gérer intégralement au sein de SQL Server. Dans ce
cas, il est nécessaire de spécifier le mot de passe de l’utilisateur SQL Server qui possèdera les privilèges
d’administrateur SQL Server. Lorsque cela est possible, il est préférable de s’appuyer sur la sécurité Windows.
- 10 - © ENI Editions - All rigths reserved

f. Configuration du moteur de base de données
La configuration du moteur de base de données permet de spécifier le mode sécurité choisi, l’emplacement des
fichiers de données, ainsi que l’activation ou non de l’option FILESTREAM.
Depuis l’onglet FILESTREAM, il est possible d’activer cette fonctionnalité.
Ces différents choix peuvent être modifiés/outrepassés par la suite lors de la configuration du serveur ou bien lors
de la gestion des fichiers relatifs à une base de données.
© ENI Editions - All rigths reserved - 11 -

Pour une sécurité plus élevée au niveau des utilisateurs, il est recommandé de s’appuyer sur le contexte de sécurité
Windows et d’interdire la sécurité SQL Server. Cela évitera, par exemple, que des développeurs codent en dur un
nom et un mot de passe dans une application ou bien dans un fichier de configuration.
g. Synthèse du processus d’installation
Le processus d’installation propose ensuite la création de rapport d’erreur qui est automatiquement envoyé à
Microsoft.
Les règles d’installation sont vérifiées afin de s’assurer que rien ne viendra bloquer le processus d’installation.

3. Gestion du réseau
SQL Server utilise des bibliothèques réseau afin d’assurer la gestion de la transmission des paquets entre le serveur
et le client. Ces bibliothèques réseau, existant sous forme de DLL (Dynamic Link Library), procurent toutes les
opérations nécessaires pour établir le dialogue entre le serveur et le client même si ces deux processus se trouvent
sur le même poste.
Ces bibliothèques réseau sont utilisées par l’application via le mécanisme IPC ou Communication Inter Processus.
Un serveur peut être à l’écoute, simultanément, de plusieurs bibliothèques et accepte donc des demandes provenant
de clients dialoguant avec des protocoles réseau différents. La seule obligation pour que le serveur puisse répondre
au client est que la bibliothèque réseau correspondant à celle du client doit être installée sur le serveur.
Un fois que les bibliothèques réseau sont installées sur le serveur, il faut encore configurer les net library afin que le
serveur puisse les prendre en compte.
La gestion du réseau entre le poste client et le serveur passe principalement par TCP/IP. C’est pourquoi la gestion de
ce protocole est incluse par défaut lors de l’installation du serveur ou bien des utilitaires clients.

Bibliothèques disponibles :
Canaux nommés
Les canaux nommés sont désactivés pour toutes les éditions de SQL Server. Leur utilisation se limite au dialogue
entre les outils graphiques et le service SQL Server sur le poste serveur.
Sockets TCP/IP (par défaut)
Cette net library permet d’utiliser les sockets Windows traditionnels.

Pour pouvoir utiliser correctement la net library TCP/IP, il est important de préciser le numéro de port auquel SQL
Server répond. Par défaut, il s’agit du port 1433, numéro officiel attribué par l’IANA (Internet Assigned Number
Authority) à Microsoft. Il est également possible d’utiliser un proxy. Dans ce cas c’est l’adresse du proxy qui sera
précisée lors de la configuration de la net library TCP/IP.
Le port 1433 est utilisable par SQL Server si aucune autre application ou processus ne tente de l’utiliser
simultanément.
Dans certains cas, comme l’accès au serveur au travers d’un pare feu, il est conseillé d’utiliser un port libre portant un
numéro inférieur à 1024.
Dans le cas où SQL Server est configuré pour utiliser un port dynamique, le numéro du port est susceptible de
changer à chaque démarrage de SQL Server.
4. Mode de licence
Avec l’apparition des nouveaux outils de communication et des possibilités nouvelles en termes de virtualisation de
serveur ainsi que les processeurs multicœ urs, la gestion des licences a dû évoluer pour s’adapter à cette nouvelle
répartition.
Il existe trois modes de gestion des licences :
● Par utilisateur ;
● Par poste utilisé pour établir la connexion (PC, Agenda électronique...) ;
● Par processeur.
L’utilisation des modes de licence par poste ou bien par utilisateur nécessite une licence d’utilisation du moteur SQL
Server.
Le mode de gestion de licence exposé ici s’applique aux éditions Standard, Entreprise, Web et Workgroup de SQL
Server, c’estàdire aux éditions de SQL Server destinées à une mise en production.
La gestion des licences est un élément sensible, et il convient de s’assurer que la solution retenue est
conforme aux règles édictées par Microsoft. Seule une synthèse de ces règles est présentée cidessous.
Pour des raisons de sécurité, il est recommandé d’avoir un serveur de secours. Ce serveur de secours peut être
synchronisé avec le serveur actif soit par l’intermédiaire des journaux de transaction, soit parce qu’il fait partie du
processus de mise en miroir, soit c’est un membre non actif du cluster. À partir du moment où le serveur de secours
est non actif, c’estàdire qu’aucune connexion utilisateur n’est faite dessus (même à des fins d’édition de rapport),
alors ce serveur de secours ne nécessite pas de licence SQL Server. Si le serveur principal tombe en panne, le serveur
de secours peut devenir actif pendant trente jours en toute légalité.
Licence par processeur
Avec ce mode de gestion des licences, c’est chaque processeur du serveur qui se voit attribué une licence d’utilisation
de SQL Server. Ainsi, un nombre illimité d’utilisateurs peuvent se connecter au serveur sans qu’il soit nécessaire pour
eux de posséder une licence SQL Server. Mis au point au départ pour les applications de type Internet/intranet, ce
mode de licence est également utilisable avec n’importe quel type d’application. Son principal avantage réside dans
une gestion simplifiée des droits d’utilisation.
Exemple : Une entreprise dispose d’un serveur SQL et 10 stations de travail doivent accéder à ce serveur. Les stations
de travail se répartissent en 2 groupes de 5 postes : travail de jour et travail de nuit. Les postes de ces groupes ne
peuvent se connecter au server que pendant les horaires précisés et il ne peut pas y avoir de chevauchement.
Combien de licences d’accès à SQL Server sont nécessaires en mode de licence par processeur ?
Réponse : une licence d’accès est nécessaire. Elle est gérée par le serveur et autorise les stations de travail à venir se

connecter simultanément sur le serveur SQL.
Mode de licence par processeur
Dans le cas d’un processeur multicœ urs, SQL Server ne nécessite qu’une seule licence par processeur quel que soit le
nombre de cœ urs du processeur.
Licence par utilisateur
Avec ce mode de gestion des licences, chaque utilisateur doit disposer d’une licence pour travailler avec SQL Server.
Ce mode de gestion va être intéressant si les utilisateurs peuvent se connecter à SQL Server par l’intermédiaire de
différents outils.
L’utilisation d’un serveur d’application qui gère éventuellement un pool de connexions ne réduit pas le nombre de
licences nécessaires. C’est chaque utilisateur physique qui a nécessité une licence d’accès.
Une même licence d’accès client ou CAL (Client Access License) permet d’accéder à de multiples serveurs. Le niveau de
licence du client doit correspondre au serveur le plus exigeant.
Dans le mode de gestion des licences par utilisateur, il est, en plus, nécessaire d’acquérir une licence de type serveur
pour la machine sur laquelle l’instance SQL Server est installée.
Les utilisateurs exprimés ici sont des utilisateurs physiques. Ils peuvent, même si cela n’est pas
recommandable, utiliser tous le même utilisateur de base de données.
Exemple
Dans l’exemple suivant, trois utilisateurs différents se connectent au serveur. Cette solution nécessite donc trois licences
d’accès client.

Attention, pour l’édition Workgroup, il est possible d’acquérir des licences d’accès qui n’autorisent que la connexion à
des éditions Workgroup de SQL Server.
Licence par poste
Avec la licence par poste (ou par siège), c’est chaque périphérique qui établit une connexion à un serveur SQL Server
qui possède une licence. Cette licence n’est pas liée au nombre d’utilisateurs qui peuvent être amenés à utiliser le
poste. Ainsi, si plusieurs utilisateurs se partagent le même poste de travail, ils peuvent utiliser la même licence
d’accès.
Muni de cette licence, un poste peut se connecter à plusieurs instances SQL Server. La licence doit être compatible
avec l’instance SQL Server la plus exigeante.
Dans le mode de gestion des licences par poste, il est, en plus, nécessaire d’acquérir une licence de type serveur pour
la machine sur laquelle l’instance SQL Server est installée.
Exemple
Dans l’exemple suivant, deux utilisateurs se partagent le même périphérique. Il est donc nécessaire de disposer de trois
licences d’accès par poste.

5. Exécuter le programme d’installation
Le programme d’installation situé sur le CDRom de SQL Server s’exécute automatiquement dès que le CDRom est
inséré dans la machine. Si la procédure d’installation ne démarre pas automatiquement, il convient de demander
l’exécution du programme SETUP.EXE situé à la racine du CDRom.
Installation automatique
Il est possible de réaliser une installation automatique. L’avantage de cette procédure est de saisir les options à
installer une seule fois en mode interactif puis de pouvoir exécuter cette installation sur plusieurs autres postes sans
avoir à ressaisir les options choisies.
Toutes les options relatives à l’installation sont enregistrées dans un fichier qui porte l’extension ini. Ce fichier est
composé uniquement de la section [Options].
Pour définir son propre fichier d’installation, il faut prendre comme modèle le fichier template.ini fourni sur le disque
d’installation de SQL Server.
Pour exécuter une installation automatique, il faut exécuter le programme setup.exe en lui passant en paramètre le
nom complet du fichier ini à utiliser.
Syntaxe
setup.exe /settings nomCompletFichier.ini [/qn] [/qb]
nomCompletFichier.ini
Chemin absolu et nom du fichier de paramétrage.
/qn
Commutateur à utiliser pour faire une installation complètement silencieuse (sans aucune boîte de dialogue).
/qb
Commutateur à utiliser pour effectuer une installation en affichant uniquement les boîtes de dialogue qui permettent
de suivre la progression de l’installation.
Même si cette solution est hautement performante dans le cas où des installations multiples sont à prévoir, la
définition du fichier de configuration n’est pas intuitive et il est donc nécessaire d’investir un peu de temps pour

optimiser son utilisation.
Toutes les installations automatiques sont composées de deux fichiers : un fichier de commande et un fichier
d’initialisation et d’installation.
6. Les bases d’exemples
Lors de l’installation du moteur de base de données, aucune base d’exemple n’est mise en place par défaut. En effet,
sur un serveur de production, les bases d’exemples ne sont pas nécessaires et ne peuvent qu’introduire des failles de
sécurité. Toutefois sur un serveur de test ou bien de formation, ces mêmes exemples prennent tout leur sens.
La documentation en ligne s’appuie sur la base AdventureWorks et ses diverses déclinaisons pour proposer des
exemples illustrant les différentes instructions Transact SQL. Tous les exemples de code et de bases de donnés
fournis par Microsoft sont disponibles sur codeplex (http://codeplex.com/SqlServerSamples). Ces exemples permettent
d’illustrer de façon précise les différentes fonctionnalités offertes par SQL Server.
La base de données Northwind présente dans les versions précédentes de SQL Server est toujours disponible et peut
ainsi être mise en place sur SQL Server 2008.
En fait, SQL Server 2008 ne propose pas une seule base d’exemple mais plusieurs en fonction de l’usage que l’on
souhaite en faire. La base AdventureWorks2008 correspond à une base OLTP (OnLine Transactional Processing)
classique et cette base illustre les utilisations classiques d’une base de données. La base AdventureWorksDW2008
est quant à elle une base qui illustre le datawarehouse (l’entreprot de données) et sera utile lors de tests sur la
réalisation, la gestion et la maintenance d’un entrepot de données dans le cadre d’une analyse décisionnelle. La base
AdventureWorksAS2008 est quant à elle axée sur Analysis Services. Enfin, une version allégée de la base OLTP est
disponible sur la base AdventureWorkLT2008.
Lors du téléchargement de la base d’exemple souhaitée, ce n’est pas un script Transact SQL qui est enregistré sur le
disque mais un fichier msi (SQL2008.AdventureWorks_OLTP_DB_v2008.x86.msi pour une plateforme 32 bits).
L’exécution de fichier permet une mise en place aisée de la base d’exemple.
Par défaut, et pour permettre un niveau de sécurité le plus élevé possible, le compte invité (guest) n’est pas défini,
ceci afin d’empêcher les connexions anonymes. Dans le cadre d’un serveur de test, il peut parfois être intéressant
d’autoriser ces connexions anonymes afin de permettre aux utilisateurs d’accéder librement à cette base d’exemple.

Vérifier l’installation et configurer
1. Vérifier l’installation
Comme pour tout produit, il est important de s’assurer que l’installation s’est correctement exécutée et que le
serveur est maintenant opérationnel.
a. Vérifier les éléments installés
Par l’intermédiaire de l’explorateur de fichier, il est possible de vérifier que l’arborescence qui regroupe tous les
fichiers nécessaires au bon fonctionnement du moteur de base de données est bien définie. Si l’installation est
exécutée avec les paramètres par défaut, alors cette arborescence est c:\Program Files\Microsoft SQL Server\100.
Les fichiers de données se trouvent quant à eux dans le dossier c:\Program Files\Microsoft SQL Server\
MSSQL10.MSSQLSERVER\MSSQL\DATA sauf si un chemin autre a été défini lors de l’installation.
Au niveau des fichiers, il est possible de consulter le journal d’installation (summary.txt) qui est présent dans le
dossier c:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\LOG. La lecture de document s’avère
principalement utile lorsque le processus d’exécution se termine en échec pour mieux cerner l’origine du problème.
Ce fichier summary est généré par chaque exécution du programme d’installation. Une nouvelle exécution du
programme d’installation va renommer (avec horodatage) le fichier summary existant afin de conserver la trace de
toutes les installations.

Dans le cas où ce fichier summary.txt ne vous fournit pas suffisamment d’information, il est possible de consulter le
fichier SQLSetupxxx.cab situé dans le même dossier.
b. Vérifier le démarrage des services
Pour un usage classique de la base, les deux services MS SQL Server et SQL Server Agent doivent être démarrés et
positionnés en démarrage automatique. Le service MS SQL Server représente le moteur de la base de données et
tant que ce service n’est pas démarré il est impossible de se connecter au serveur et de travailler avec les données
qu’il héberge. Le service SQL Server Agent prend à sa charge, entre autres, l’exécution et la gestion de toutes les
tâches planifiées. Pour gérer les services, il est bien sûr possible de le faire avec les outils proposés en standard
par Windows, mais SQL Server propose également ses propres outils.

Les outils
SQL Server dispose de nombreux outils. Ces outils sont complémentaires et chacun d’entre eux est adapté à un type
de problème ou d’action. Il est important de posséder une vue d’ensemble sur l’objectif visé par chacun de ces outils
afin de savoir lequel employer pour résoudre un problème bien précis. Il est possible de faire ici une analogie avec le
bricolage, si vous ne possédez qu’un tournevis vous allez essayer de tout faire avec, alors qu’au contraire, si votre
caisse à outils est bien garnie il y a de forte chance d’y trouver l’outil qui répond exactement au problème rencontré.
Pour SQL Server l’approche est similaire. Il est bien entendu possible de faire quasiment tout en Transact SQL, mais
SQL Server propose des outils graphiques autres pour permettre de solutionner des problèmes bien précis. L’utilisation
de la plupart d’entres eux va être détaillée tout au long de cet ouvrage. Un regard global permet cependant d’avoir
une meilleure vision de l’intérêt présenté par chacun.
L’outil de configuration de la surface d’exposition présent dans SQL Server 2005 disparaît avec SQL Server
2008 mais les règles gérées par cet outil se retrouvent dans les règles proposées par SQL Server 2008. En
effet, SQL Server 2008 propose une administration basée sur les règles. Ce point est détaillé plus loin dans cet
ouvrage.
SQL Server Management Studio
Il s’agit de l’outil principal de SQL Server et il est destiné aussi bien aux développeurs qu’aux administrateurs.
SQL Server Management Studio (SSMS) est la console graphique d’administration des instances SQL Server. Il est
possible d’administrer plusieurs instances locales et/ou distantes depuis cet outil. SQL Server Management Studio est
également l’outil principal des développeurs de bases de données qui vont l’utiliser pour définir les scripts de création
des tables, des vues, des procédures, des fonctions, des déclencheurs de base de données…
Cet utilitaire peut être démarré depuis la ligne de commande par l’intermédiaire de l’application ssms.
Avec SQL Server 2008, SSMS intègre son lot de nouveautés dont la très attendue autocomplétion qui permet le
complément automatique des mots clés lors de l’écriture de requête. Cette autocomplétion est activée avec le
traditionnel appui sur les touches [Ctrl][Espace]. En plus des mots clés, les références aux tables, colonnes, nom de
procédures, fonctions sont disponibles au travers de l’autocomplétion. Cette fonctionnalité permet de gagner un temps
précieux lors de l’écriture des scripts en limitant les erreurs de saisie.
Afin de faciliter la bonne gestion des bases de données, SQL Server Management Studio propose la génération de
rapports. Ces rapports permettent d’avoir une vue globale et synthétique d’un ou de plusieurs éléments de la base ou
du serveur. SQL Server 2008 propose un certain nombre de rapports prédéfinis mais il est possible de définir ses
propres rapports en complément.
Gestionnaire de Configuration SQL Server

Le gestionnaire de configuration de SQL Server permet de gérer l’ensemble des éléments relatifs à la configuration des
services et du réseau côté client et côté server.
La configuration des services
Les différents services relatifs à SQL Server peuvent être administrés directement depuis cet outil. En plus des
opérations classiques d’arrêt et de démarrage, il est possible de configurer le type de démarrage (automatique,
manuel, désactivé) ainsi que le compte de sécurité au sein duquel le service doit s’exécuter.
Configuration de réseau SQL Server
Le gestionnaire de configuration permet également de gérer quels sont les protocoles pris en charge au niveau du
serveur. Il est également possible à ce niveau de modifier les propriétés spécifiques à chaque protocole comme le
numéro du port d’écoute du protocole TCP/IP.

Configuration de SQL Native Client 10.0
Cette foisci la configuration porte sur les outils client installés localement et plus exactement de définir précisément les
protocoles à leur disposition pour entrer en contact avec le serveur, mais aussi, lorsque cela s’avère nécessaire, la
possibilité de définir des alias. Cette fonctionnalité est particulièrement intéressante lorsque le nom du serveur est
enregistré dans une application et qu’il n’est pas possible ou bien facile de modifier cet enregistrement. La définition
d’un alias permet de rediriger toutes les demandes vers un serveur distinct.
SQL Server Profiler
La capture de trace au niveau du moteur de base de données permet de tirer au clair de nombreux problèmes de
fonctionnement en comprenant mieux comment les applicatifs client travaillent avec la base.
Assistant Paramétrage de base de données
Cet assistant permet, entre autres, à partir d’une charge de travail capturée avec SQL Profiler de valider ou non la
structure de la base de données. En fin d’analyse, l’assistant va conseiller la création/suppression d’index ou bien le
partitionnement de tables afin d’obtenir des gains de performances.
SQLCmd
SQLCmd est un utilitaire en ligne de commande qui permet d’exécuter des scripts SQL. Cet outil va être mis à
contribution lors de la demande d’exécution de tâches administratives concernant SQL Server à partir de Windows.
Cet outil permet de se connecter à une instance locale ou non de SQL Server. L’authentification à cette instance peut
être effectuée en s’appuyant sur le mode de sécurité Windows ou bien SQL server.
SQLCmd permet d’exécuter des scripts SQL que ce soit des instructions du DML (Data Manipulation Language) ou du DDL
(Data Definition Language).
osql

Autre outil en ligne de commande pour exécuter des scripts. Cet outil est maintenu pour des raisons de compatibilité
mais étant donné qu’il s’appuie sur la technologie odbc, il est amené à disparaître.
bcp
Il s’agit d’un utilitaire en ligne de commande qui permet d’extraire facilement et rapidement des données depuis la
base vers un fichier ou bien de faire l’opération inverse.
sqlps
Permet d’exécuter l’environnement PowerShell spécifique à SQL server.
sqldiag
Cet utilitaire de diagnostic peut être exécuté afin de fournir des informations au service support.
sqllogship
Cette application permet de préparer un fichier journal par sauvegarde ou copie avant de l’envoyer vers une autre
instance SQL server.
Tablediff
Comme son nom l’indique, cet utilitaire permet de comparer le contenu de deux tables. Il s’avère particulièrement utile
pour résoudre les problèmes de synchronisation qui peuvent apparaître dans le cadre d’une réplication de fusion.
Utiliser un outil client pour se connecter à SQL Server
Pour établir la première connexion au serveur, plusieurs outils sont disponibles. En mode graphique, il convient de
lancer SQL Server Management Studio. Au lancement de l’outil, la fenêtre suivante de connexion est présentée.
Il est possible d’établir la connexion depuis un outil en ligne de commande comme sqlcmd. L’écran suivant permet de se
connecter au serveur en utilisant le mode de sécurité Windows.

La configuration
Avant de mettre en service le serveur SQL, en le rendant accessible par tous les utilisateurs, il est important de réaliser
un certain nombre d’opérations de configuration du serveur et des outils d’administration client afin de se prémunir
contre toute opération sensible.
1. Les services
Les différents composants serveur s’exécutent sous forme de service. Il est donc nécessaire que ces services soient
démarrés afin de pouvoir travailler avec le serveur. Ces services peuvent être gérés avec le gestionnaire de
configuration de SQL Server mais ils peuvent également être gérés comme tous les services Windows.
Depuis le gestionnaire de configuration, il est simple de visualiser l’état du service ainsi que de modifier ses propriétés.
Comme tous les services Windows, ils peuvent être gérés de façon centrale au niveau du serveur Windows.
Enfin, il est possible d’agir sur ces services directement en ligne de commandes par l’intermédiaire des commandes net
start et net stop. Lors d’un démarrage en ligne de commande, il est possible d’outrepasser la configuration par défaut
du service en spécifiant la configuration à utiliser sous forme de paramètres. Par exemple, l’option m (net start
mssqlserver m) permet de démarrer le serveur en mode mono utilisateur.
En cas de problème de démarrage, il est possible de démarrer le serveur SQL Server en tant qu’application à l’aide de
l’exécutable sqlservr.exe. L’utilisation de cet exécutable permet de démarrer l’instance en ne tenant pas compte de
toutes les options de configuration définies.
Les différents états des services
Démarré
Lorsque le service MSSQL Server est démarré, les utilisateurs peuvent établir de nouvelles connexions et travailler
avec les données hébergées en base. Lorsque le service SQL Server Agent est démarré, l’ensemble des tâches
planifiées, des alertes et de la réplication est actif.
Suspendu

Si le service MSSQL Server est suspendu, alors plus aucun nouvel utilisateur ne peut établir une connexion avec le
serveur. Les utilisateurs en cours ne sont pas concernés par une telle mesure. La suspension du service SQL Server
Agent désactive la planification de toutes les tâches ainsi que les alertes.
Arrêté
L’arrêt du service MSSQL Server désactive toutes les connexions utilisateur et déclenche un processus de
CHECKPOINT (l’ensemble des données validées présentes en mémoire sont redescendues sur le disque dur et le point
de synchronisation est inscrit dans le journal). Un tel mécanisme permet d’assurer que le prochain démarrage du
serveur sera optimal. Cependant le service attend que toutes les instructions en cours soient terminées avant
d’arrêter le serveur. L’arrêt du service SQL Server Agent désactive l’exécution planifiée de toutes les tâches ainsi que
la gestion des alertes.
2. SQL Server Management Studio
SQL Server Management Studio est l’outil de gestion graphique de SQL Server qui permet de réaliser les tâches
administratives et toutes les opérations de développement. L’utilisation du même outil permet de réduire la distinction
entre les deux groupes d’utilisateurs que sont les administrateurs et les développeurs. En partageant le même outil, il
est plus facile de connaître ce qu’il est possible de faire d’une autre façon.
Pour pouvoir naviguer d’une instance à l’autre de SQL Server, éventuellement sur des serveurs différents, il est
nécessaire d’enregistrer chaque serveur dans la console d’administration. Cette inscription n’est pas nécessaire pour
l’instance locale de SQL Server, car lors de la création de l’instance, les informations relatives à cette instance ont été
ajoutées dans SQL Server Management Studio.
Inscrire un serveur
La fenêtre Serveurs Inscrits permet de connaître la liste des serveurs inscrits dans SQL Server Management Studio.
Si cette fenêtre n’est pas visible, il est possible de demander son affichage par le menu Affichage Serveurs inscrits
ou par le raccourci clavier [Ctrl][Alt] G.
Les serveurs sont regroupés par type. Pour chaque type il est possible de définir des groupes de serveurs afin de les
regrouper sur un autre critère, par exemple l’emplacement physique. Les groupes de serveurs n’ont aucune influence
sur l’inscription du serveur. Il est possible de déplacer un serveur vers un groupe en sélectionnant l’option Tâches
Déplacer vers depuis le menu contextuel associé au serveur. Par analogie, il est possible de comparer les groupes de
serveurs à des dossiers et les serveurs inscrits à des fichiers. Les fichiers ne sont pas affectés lorsqu’ils sont déplacés
d’un dossier à un autre. Il en est de même pour les inscriptions de serveur. Les dossiers sont définis pour regrouper
les fichiers suivant une certaine logique, c’est exactement le rôle que jouent les groupes de serveurs.
Pour inscrire un nouveau serveur depuis SQL Server Management Studio, il faut sélectionner l’option Nouvelle
inscription de serveur depuis le menu contextuel associé au nœ ud Local Server Groups dans la fenêtre Serveurs
inscrits.

La boîte de dialogue qui permet de réaliser l’inscription est composée de deux onglets. Le premier onglet permet de
compléter toutes les informations générales de l’inscription comme le nom du serveur, mais également le type
d’authentification utilisé pour établir la connexion sur le serveur.
Depuis SSMS il est possible d’inscrire des serveurs SQL Server, Analysis Services, SQL Server Compact Edition,
Reporting Services et Integration Services.

Le bouton Tester permet de s’assurer que la connexion choisie permet bien de travailler sur le serveur sélectionné.
Il est possible d’enregistrer un serveur avec un nom différent de celui du serveur.
Le second onglet permet, quant à lui, de fixer des options plus avancées comme la base de données par défaut ou
bien le type de protocole réseau utilisé pour établir la connexion avec le serveur.
Pour des raisons de sécurité, il est préférable de choisir lorsque cela est possible le mode d’authentification
Windows.
Lors de l’inscription du serveur, il possible de sélectionner certaines options comme le délai d’expiration de la
connexion.
Pour faciliter le travail de l’administrateur, les bases de données système sont regroupées dans un dossier. Ainsi, ce
sont les bases de données des utilisateurs qui sont visibles au premier plan. Cette séparation permet de ne pas
encombrer la console par les bases système qui n’ont d’importance que pour SQL Server.

Le même type de séparation est effectué sur les bases entre les tables système et les tables créées par les
utilisateurs. Ce sont ces dernières qui contiennent les informations et sur lesquelles tous les efforts d’administration
vont porter.
3. Configuration du serveur
Avant d’ouvrir plus librement l’accès au serveur et de permettre aux utilisateurs de venir travailler sur le serveur, il
convient de surveiller attentivement les deux points suivants :
Mot de passe de l’administrateur
Cette préoccupation concerne uniquement les serveurs qui sont configurés en mode de sécurité mixte. Si ce choix a
été fait au cours de l’installation, il faut s’assurer que le mot de passe de l’administrateur SQL Server (sa) est
suffisamment fort. Si ce n’est pas le cas, il est alors nécessaire de le modifier.
Lors de l’installation de SQL Server deux utilisateurs sont prédéfinis. Le premier est le groupe local des
administrateurs (utilisé avec la sécurité Windows), le second est l’utilisateur sa. Ces deux utilisateurs présentent des
droits d’administrateur du serveur SQL. L’utilisateur sa s’appuie sur le sécurité SQL Server et son mot de passe a été
demandé durant la procédure d’installation.
Si lors de l’installation, seul le mode de sécurité Windows a été activé, alors la connexion sa est non active. Il est
nécessaire de définir un mot de passe fort avant d’activer la connexion. Cependant la connexion ne pourra être
utilisée que si le serveur est configuré en mode de sécurité mixte.
Deux possibilités se présentent.
Par SQL Server Management Studio

Par le transact SQL
Gestion des ressources
Les ressources de la machine sont gérées dynamiquement. Cette gestion automatique des ressources permet d’offrir
les meilleures fonctionnalités possibles du serveur tout en réalisant un minimum de tâches administratives. Toutefois, il

peut parfois être intéressant de gérer manuellement certaines ressources afin de réaliser une optimisation de
l’utilisation des ressources du serveur. Quelquesuns de ces réglages peuvent être réalisés au moyen de SQL Server
Management Studio.
Pour accéder à la totalité des paramètres du serveur, il faut utiliser la procédure stockée sp_configure.
Si une option est modifiée à l’aide de la procédure sp_configure, elle ne prendra effet que lors du prochain

redémarrage du serveur SQL. Il est possible d’appliquer la modification de façon immédiate en exécutant la commande
RECONFIGURE WITH OVERRIDE.
4. La gestion du processus SQL Server
Pour le système d’exploitation, chaque application s’exécute sous forme de processus. Chaque processus dispose de
ces propres threads qui correspondent aux unités de travail que le système d’exploitation doit soumettre au
processeur. A un processus correspond toujours au moins un thread.
Chaque instance SQL Server gère ellemême ses propres threads et gère leur synchronisation sans passer par le
noyau Windows. L’objectif de SQL Server est de répondre efficacement et rapidement à des demandes de montées en
charge brusque et soudaine. Afin d’être toujours disponible, SQL Server gère son propre pool de threads dont le
nombre maximal est contrôlé par le paramètre max worker threads. Avec la valeur par défaut (0) SQL Server se
charge de gérer luimême ce nombre de threads mais il est également possible de fixer le nombre maximum de
threads. Ces threads vont avoir pour objectif de traiter les requêtes des utilisateurs. Etant donné qu’un utilisateur ne
travaille pas 100 % de son temps sur le serveur, il doit lire ou bien modifier les données avant de soumettre une
nouvelle requête, il est préférable pour SQL Server de partager un même thread entre plusieurs utilisateurs.
La valeur maximale de ce paramètre était de 255 avec SQL Server 2000. Aussi dans le cadre d’une migration
de serveur est il recommandé de positionner cette valeur à 0.
Windows propose également de gérer des fibres qui représentent une unité de travail plus légère qu’un thread. Il est
possible de demander à SQL Server de travailler avec ces fibres en lieu et place des threads. Ce paramétrage
s’effectue avec l’option de configuration light weight pooling. Cependant, l’activation de cette option rend impossible
l’utilisation de code CLR dans SQL Server. D’autre part, l’activation de cette option se traduira par un gain significatif
de performance uniquement sur des serveurs massivement multiprocesseurs avec un taux d’utilisation des
processeurs important.
Dans le cadre d’une architecture multiprocesseurs et souvent multiinstance, il est possible à l’aide de l’option de
configuration affinity de spécifier les processeurs à utiliser pour chaque instance. Cette option contient une valeur
binaire ou chaque bit représente l’autorisation (1) ou non (0) d’utiliser un processeur.
Enfin pour ordonnancer l’exécution des différents threads, Windows affecte à chaque processus une priorité variant de
1 (le moins prioritaire) à 31 (le plus prioritaire). Cette gestion de priorité ne concerne pas les processus système. Par
défaut, le processus SQL Server reçoit un niveau de priorité égal à 7, c’estàdire un processus normal. Il est possible
de donner une priorité supérieure par l’intermédiaire de l’option de configuration priority boost. Cette option peut
s’avérer particulièrement intéressante lorsque plusieurs instances SQL Server s’exécutent sur le même poste et que
l’on souhaite en favoriser une.
5. La gestion de la mémoire

Par défaut, SQL Server gère dynamiquement la quantité de mémoire dont il a besoin. Il est d’ailleurs recommandé de
conserver une gestion dynamique de la mémoire qui permet une répartition optimale de la mémoire entre les
différents processus s’exécutant sur le serveur.
Sur plateforme 32 bits, SQL Server est capable d’exploiter les extensions AWE (Address Windowing Extensions) afin
d’adresser jusqu’à 64 Go de RAM.
Il est important que le serveur dispose d’une quantité de mémoire suffisante car cela permet de minimiser le nombre
de lectures physique et de favoriser les lectures logiques. Plus ces dernières sont nombreuses, meilleurs sont les
temps de réponse du serveur. Le ratio entre ces deux types de lectures peut être obtenu au travers de l’analyseur de
performances. Ce point est abordé au chapitre Optimisation Analyseur de performances (Moniteur Système).
Pour permettre la gestion dynamique de la quantité de mémoire utilisée, SQL Server s’appuie sur l’API (Application
Programming Interface) de gestion de la mémoire de Windows afin d’acquérir le maximum de mémoire sans pour autant
privé le système de la quantité de mémoire qui lui est nécessaire.
Cette gestion dynamique peut être limitée en utilisant les paramètres min server memory et max server memory.
L’instance SQL Server, même si elle est peu utilisée, conservera toujours la quantité de mémoire spécifiée par min
server memory. En cas de charge de travail, il est possible d’acquérir de la mémoire, sans jamais dépasser la valeur
spécifiée par max server memory.
La prise en charge de la mémoire AWE est possible en configurant le paramètre awe enabled de la façon suivante :

Le service de texte intégral
Le service de recherche de texte intégral a pour objectif d’améliorer la pertinence et la vitesse des requêtes menées sur
les champs qui contiennent des textes de grandes dimensions, c’estàdire sur des colonnes de type char, nchar,
varchar, nvarchar, varbinary et xml. Dans le cas où la table possède de nombreuses lignes, une requête avec
l’opérateur like peut prendre plusieurs minutes pour s’exécuter. Si la colonne dispose d’un index de texte intégral, alors
l’extraction des lignes demande quelques instants.
La mise en place d’un tel service, utilisé pour l’indexation, l’interrogation et la synchronisation nécessite la présence
d’une clé unique (ou clé primaire) sur toutes les tables qui sont inscrites en vue d’une recherche de texte intégral.
L’index de texte intégral conserve une trace de tous les mots significatifs qui sont employés ainsi que leur emplacement.
Pour que la recherche soit pertinente et rapide, seuls les mots chargés de sens doivent être indexés. Pour identifier les
mots dénués de sens, SQL Server va utiliser une liste des mots vides. Cette liste est conservée directement dans la
base de données. Toutefois, comme cette incorporation de la liste est une spécificité de SQL Server 2008, dans le cas
d’une migration depuis SQL Server 2005, cette liste est conservée sous la forme de fichier externe.
Cette liste des mots vides peut être modifiée librement afin d’y ajouter les mots vides spécifiques à une entreprise ou
bien un contexte de travail. Par exemple, le nom de la société peut être considéré comme un mot vide car il y a de fortes
chances qu’il apparaisse très fréquemment.
Le service de recherche de texte intégral s’appuie sur quelques termes bien précis pour décrire sa mise en place et son
fonctionnement :
● Index de texte intégral : stocke les informations relatives aux mots significatifs. C’est à partir de ces
informations que les recherches sont effectuées.
● Catalogue de texte intégral : associé à une instance de SQL Server, le catalogue peut contenir de 0 à n index.
● Analyseur lexical : en fonction de la langue et des ses règles lexicales, l’analyseur lexical va définir les jetons.
● Jeton : il s’agit d’une chaîne de caractères (bien souvent des mots) repéré par l’analyseur lexical.
● Générateur de formes dérivées : en fonction de la langue, le générateur de formes dérivées permet de gérer les
différentes formes que peut prendre un terme, comme par exemple sa conjugaison pour un verbe ou bien son
accord pour un nom ou un adjectif.
● Filtre : cet élément permet d’extraire le texte à partir d’un fichier spécifique (.doc par exemple) et d’enregistrer
ce texte dans une colonne de type varbinary(max) par exemple.
● Analyse ou Alimentation : il s’agit du processus qui permet d’initialiser et de maintenir à jour l’index.
● Mots vides : il s’agit d’une liste de mots qui ne sont pas porteurs de sens pour les recherches en mode texte.
Cette liste de mots est spécifique à chaque langue. L’objectif recherché est de réduire le nombre de mots à
traiter en éliminant tous les mots de liaison, les articles ou des termes dénués de sens par rapport au contexte,
par exemple le nom de l’entreprise ou bien un acronyme couramment utilisé.
Avec SQL Server 2008, le service de recherche de texte intégral est entièrement supporté par le service MSSQLServer.
Ce service est également disponible pour toutes les bases hébergées sur le serveur.
L’activation de la prise en charge de service au niveau de la base n’est plus d’actualité avec SQL Server 2008.
Implémentation
La recherche linguistique sur des données texte, n’est possible que sur les tables activées pour la recherche de texte
intégral. La recherche linguistique, contrairement à l’opérateur LIKE qui agit sur les caractères, effectue une
comparaison sur les mots et sur les expressions.
La mise en place d’une recherche de texte intégral dans une base de données impose d’effectuer les opérations
suivantes :
● préciser les tables et les colonnes qui doivent être inscrites dans la recherche de texte intégral.
● réaliser l’indexation des données des colonnes inscrites et remplir les index de texte intégral avec les mots

porteurs de sens.
● exécuter les requêtes sur les colonnes inscrites pour la recherche de texte intégral.
● s’assurer que toutes les modifications effectuées sur ces colonnes ont été propagées jusqu’aux index.
Ces index ne sont pas remplis en temps réel mais plutôt de façon asynchrone car :
● le temps d’indexation est généralement beaucoup plus long.
● les recherches de texte intégral sont, en règle générale, beaucoup moins précises que les recherches en mode
standard.
Mise en place
La mise en place sur service de texte intégral peut être effectuée depuis SQL Server Management Studio sous forme de
scripts Transact SQL.
Les étapes de travail à réaliser sont :
● créer un catalogue ;
● créer un ou plusieurs index qui utilisent ce catalogue ;
● définir la liste des mots vides.
La mise en place du service de texte intégral peut être réalisée soit en mode graphique depuis SQL Server Management
Studio, soit par l’intermédiaire de scripts Transact SQL, soit par l’intermédiaire de l’assistant Indexation de texte
intégral. Compte tenu du fait que la création de ce type d’index est une opération ponctuelle, l’utilisation de l’assistant
peut s’avérer fort utile. Cet assistant est accessible depuis le menu contextuel associé à la table sur laquelle l’index va
être défini.
Cette mise en place peut également être réalisée étape par étape par l’intermédiaire de commandes Transact SQL.

1. Le catalogue
Lors de sa création initiale l’index de texte intégral va être un consommateur important au niveau des lectures et
écritures sur le disque dur. Il est donc nécessaire que l’index soit défini sur un système de fichier performant. L’index
de texte intégral va donc être défini sur un catalogue qui lui est propre. Le catalogue est obligatoirement défini sur la
même base que l’index. Si un index est toujours défini sur un catalogue, un catalogue peut contenir un ou plusieurs
index. Lorsque la table indexée contient de très nombreuses lignes, il est souhaitable que l’index de texte intégral soit
défini sur son propre catalogue. Par contre, si les tables possèdent un nombre raisonnable de lignes, alors il est
possible de définir un nombre raisonnable d’index sur un même catalogue. Afin que le catalogue soit optimisé, il est
souhaitable de regrouper sur un même catalogue des index qui possèdent une fréquence de mise à jour semblable.
Le catalogue va être géré avec les instructions Transact SQL CREATE FULLTEXT CATALOG, ALTER FULLTEXT CATALOG et
DROP FULLTEXTCATALOG. Seule la création d’un catalogue avec l’instruction CREATE FULLTEXT CATALOG est détaillée
ici.
Il n’est pas possible de définir des catalogues sur les bases master, model et tempdb.
CREATE FULLTEXT CATALOG nomCatalogue

WITH ACCENT_SENSITIVITY = {ON|OFF}]
[AS DEFAULT]
[AUTHORIZATION nomPropriétaire ]
nomCatalogue
Nom du catalogue. Chaque catalogue porte un nom unique. Le nom est limité à 120 caractères et respecte les règles
de nommage des identifiants dans SQL Server. Le nom du catalogue sera utilisé pour nommer le fichier. Le nom du
fichier doit également être unique.
groupeDeFichiers
Nom du groupe de fichiers auquel le catalogue va appartenir.
racineChemin
Permet de préciser le dossier qui va contenir le fichier sysft_nomCatalogue associé au catalogue.
ACCENT_SENSITIVITY
Permet de préciser si le catalogue doit distinguer ou non les caractères accentués.
AS DEFAULT
Le catalogue devient le catalogue par défaut pour les index de texte intégral qui peuvent être définis par la suite.
nomPropriétaire
Dans le cas où le créateur du catalogue n’est pas le propriétaire, il est possible de deviner le nom du propriétaire.
Exemple
Dans l’exemple suivant, un catalogue de texte intégral est défini sur la base Gescom avec comme répertoire racine le dossier
C:\Program Files\Microsoft SQL Server\MSSQLIO. MSSQLCSERVER\ MSSQL\FTData.

Les options ON FILEGROUP et IN PATH sont encore présentes au niveau de l’instruction, mais sont sans effet
lorsque l’on travaille sur une instance SQL Server 2008.
Pour effectuer les opérations de modification et de suppression, il faut utiliser les instructions ALTER FULLTEXT
CATALOG et DROP FULLTEXT CATALOG.
Il est également possible de réaliser ces opérations depuis la console SQL Server Management Studio en
sélectionnant l’option Nouveau catalogue de texte intégral depuis le menu contextuel associé au nœ ud Stockage
Catalogue de texte intégral dans l’explorateur d’objets.
L’index de texte intégral
L’index unique utilisé par l’index de texte intégral pour référencer les lignes d’informations devra être le plus compact
possible afin de limiter la charge de travail. Une donnée de type entière (int) convient parfaitement.
L’index de texte intégral va pouvoir être défini avec l’instruction CREATE FULLTEXT INDEX.
Ce type d’index peut bien sûr être défini sur des colonnes qui contiennent des données de type texte mais également
des colonnes de type varbinary(max) qui stockent des textes directement dans un format de données spécifique (par
exemple .doc). Ce type d’index peut également être défini sur des colonnes de type xml.
CREATE FULLTEXT INDEX ON nomTable

[(nomColonne [TYPE COLUMN typeDocument]

[LANGUAGE indicateurDelangue] [,...])]
KEY INDEX nomIndex
[ON nomCatalogue]
[WITH CHANGE_TRACKING
{MANUAL | AUTO | OFF [, NO POPULATION]}]
[,STOPLIST={OFF|SYSTEM|nomListeMotsVides}]
nomTable
Il s’agit du nom de la table sur laquelle l’index de texte intégral est défini.
nomColonne
Nom de la colonne ou des colonnes qui participent à l’index.
typeDocument
Lorsque la colonne indexée contient un document, cette colonne permet de connaître le type du document.
indicateurDelangue
Permet de spécifier la langue dans laquelle les informations sont enregistrées dans la colonne indexée. Cet indicateur
n’est utile que dans le cas où la langue utilisée pour stocker les informations est différente de la langue par défaut
définie au niveau de SQL Server. Par exemple, pour indexer une colonne qui contient des textes en anglais alors que
SQL Server est configuré avec le français comme langue par défaut.
nomIndex
Nom de l’index unique qui sera utilisé pour référencer les lignes d’informations dans la table.
nomCatalogue
Nom du catalogue utilisé par l’index. Si aucun nom de catalogue n’est spécifié, alors c’est le catalogue par défaut qui
est utilisé (celui créé avec la clause AS DEFAULT).
WITH CHANGE_TRACKING
Cette clause permet de spécifier comment les modifications apportées aux colonnes indexées sont reportées dans
l’index.
STOPLIST
Cette option permet de préciser la liste de mots vides associés à l’index, soit aucune (OFF), soit la liste par défaut
(SYSTEM), soit une liste personnalisée dont il faut donner le nom.
Exemple
Dans l’exemple présenté cidessous la colonne désignation de la table des articles est indexée. Cet index utilise le catalogue
catalogueLivre et suit les modifications de façon automatique.

Depuis SQL Server Management Studio, il est possible d’afficher les détails de cet index par l’intermédiaire des
propriétés du catalogue.
Les propriétés du catalogue sont accessibles en sélectionnant Propriétés depuis le menu contextuel associé au
catalogue.
2. La liste de mots vides

Cette liste permet de définir quels sont les mots vides de sens et donc à ne pas prendre en compte au niveau de
l’index.
Cette liste de mots vides est disponible uniquement à partir de SQL Server 2008. Donc la base de données doit être
en niveau de compatibilité 100 pour être en mesure de l’utiliser.
Syntaxe
CREATE FULLTEXT STOPLIST nomListeMotsVides

[FROM {nomListeMotsVidesSource|SYSTEM STOPLIST}]
[AUTHORIZATION propriétaire];
nomListeMotsVides
Il s’agit du nom affecté à la liste de mots vides en cours de création.
nomListeMotsVidesSources
Il s’agit de l’identifiant d’une liste de mots vides dont le contenu va être copiée dans la liste de mots en cours de
création.
SYSTEM STOPLIST
Avec cette option, la liste des mots vides est définie à partir de la liste située dans la base resource.
propriétaire
Il s’agit cette fois de spécifier explicitement qui va être le propriétaire de cette liste. Cette option n’est nécessaire que
dans le cas où l’exécutant de la commande n’est pas le propriétaire de l’index.
Exemple :
L’exemple suivant montre la création d’une liste de mots vides depuis un script Transact SQL.
Cette liste peut également être gérée depuis SQL Server Management Studio à partir du nœ ud Stockage Liste des
mots vides de texte intégral.
Exemple
Le mot Livre est ajouté à la liste.

Une fois définie, cette liste de mots vides peut être modifiée à l’aide de l’instruction ALTER FULLTEST STOPLIST et
supprimée avec DROP FULLTEXT STOPLIST. La commande ALTER permet de modifier la liste aussi bien en ajoutant
qu’en supprimant des mots dénués de sens.
Syntaxe
ALTER FULLTEXT STOPLIST listeMotsVides

ADD ’nouveauMot’ LANGUAGE langue;
listeMotsVides
Représente l’identifiant de la liste à modifier.
nouveauMot
Correspond au nouveau terme dénué de sens. Les termes ajoutés ainsi représentent des mots spécifiques à un
vocabulaire métier qui est présent trop souvent pour rendre sont indexation efficace.
langue
Représente la langue pour laquelle ce mot est défini. Le codage des différentes langues enregistrées dans SQL Server
est disponible en interrogeant la table sys.syslanguages.
Exemple
Dans l’exemple suivant le mot livre est considéré comme dénué de sens pour la langue française.

Initialiser l’index
Après la création de l’index, il est nécessaire de planifier la valorisation de l’index avec les données. Cette opération
n’est pas faite de façon instantanée, car elle peut nécessiter une forte charge de travail pour le serveur. Il est donc
préférable de planifier le remplissage de l’index à une période de moindre activité.
Il existe trois façons différentes d’initialiser et de tenir à jour l’index complet, basé sur les modifications ou sur une
base de temps régulière.
L’initialisation complète de l’index est sans doute la façon la plus naturelle de travailler avec les index car tous les
termes sont indexés de façon globale, soit lors de la création de l’index, soit basé sur l’horodatage incrémentiel.
Avec le mode de remplissage basé sur les modifications, SQL Server garde une trace de toutes les données ajoutées
ou bien modifiées. Le report de ces modifications vers l’index de texte intégral peut être effectué de façon manuelle,
sous la forme de script avec une exécution planifiée, ou bien de façon continue.
Enfin, le remplissage basé sur l’horodatage incrémentiel, s’appuie quant à lui sur une valeur de type timestamp. Lors
de l’ajout d’information dans la table, la colonne de type timestamp est valorisée. Si la table ne possède pas de
colonne de type timestamp, il n’est pas possible de mettre en action ce type de remplissage. Á la fin du processus de
remplissage la valeur timestamp courante est conservée dans les métadonnées ainsi lors du prochain processus de
remplissage, il sera possible de prendre en compte uniquement les données les plus récentes.
Il est possible de définir cette opération à partir de la fenêtre des propriétés du catalogue comme illustré avec l’écran
suivant.

Cette opération peut également être faite en Transact SQL avec l’instruction ALTER FULLTEXT INDEX ON nomTable
START FULL POPULATION pour une initialisation complète. Cette instruction possède différentes options qui permettent,
par exemple, d’activer ou de désactiver l’index.
Utilisation au sein des requêtes
L’utilisation des index de texte intégral s’effectue au moyen de deux prédicats : CONTAINS et FREETEXT qui peuvent
être utilisés dans n’importe quelle clause WHERE. Il existe également deux fonctions Transact SQL qui ramènent un
ensemble de lignes et peuvent être utilisées dans une clause FROM d’une requête SELECT, à savoir, CONTAINSTABLE
et FREETEXTTABLE.
3. Retrouver les informations relatives aux index de texte intégral
Toutes les informations relatives à ces index peuvent être retrouvées en interrogeant les différentes vues du

catalogue système.
Parmi toutes ces vues, les trois présentées cidessous sont fréquemment utilisées.
sys.fulltext_index_catalog_usages
permet d’obtenir la liste des catalogues définis.
sys.fulltext_index_column
permet d’identifier les colonnes qui participent à un index de texte intégral.
sys_dm_fts_index_population
permet de recueillir les informations de remplissage sur les index actifs de type texte intégral.

Installer un composant
Il est possible de modifier les choix initiaux réalisés lors de l’installation de SQL Server pour demander l’installation de
nouveaux composants non sélectionnés initialement.
La procédure consiste à passer par le Panneau de configuration Ajout/Suppression de programmes, puis à

sélectionner l’instance SQL Server à modifier.
L’assistant d’installation est alors relancé.

Notions générales
L’installation du serveur SQL réalisée, il convient de définir des espaces logiques de stockage afin de regrouper sous un
même nom l’ensemble des données correspondant à un même projet. Cet ensemble est la base de données, elle va
nous permettre de travailler logiquement avec des objets tels que les tables sans jamais avoir à se soucier du stockage
physique. SQL Server permet de réaliser des associations entre les fichiers physiques et les bases de données. Dans ce
chapitre, la création et la gestion des fichiers physiques seront abordées en même temps que les bases de données.
1. Liens entre base de données et organisation physique
Lors de la création d’une base de données, il est nécessaire de préciser au moins deux fichiers. Le premier servira à
stocker les données, le deuxième sera utilisé par le journal afin de stocker les images avant et après modification des
données.
Ces deux fichiers sont obligatoires et sont propres à chaque base. Dans SQL Server, il n’est pas possible de partager
un fichier de données ou le journal entre plusieurs bases.
Séparation entre les schémas logique et physique
2. La notion de transaction
a. Qu’estce qu’une transaction ?
Une transaction est un ensemble indivisible d’ordres Transact SQL. Soit la totalité peut s’exécuter, soit aucun ordre
ne peut s’exécuter. Le moteur SQL doit être capable, tant que la transaction n’est pas terminée, de remettre les
données dans l’état initial. Si la transaction n’est pas terminée, aucun autre utilisateur ne peut intervenir sur les
données, tant en lecture qu’en écriture. Il est dangereux de s’appuyer sur des données, dont on ignore si les
modifications en cours vont persister dans le temps ou non. Afin de garantir la cohérence des données, toutes les
lignes qui sont modifiées à l’intérieur d’une transaction sont verrouillées pour qu’aucun autre utilisateur ne puisse
intervenir sur ces lignes. Le verrouillage est effectué automatiquement, et les verrous sont relâchés lorsque
l’utilisateur indique la fin de la transaction, soit en succès, soit en échec. Le verrouillage des données est géré de
façon optimale par SQL Server de façon à minimiser le nombre de lignes de données verrouillées (verrouillage au
niveau de la ligne possible) ainsi que le nombre de verrous posés (verrous de ligne, de blocs ou de table).
Lorsqu’une donnée est verrouillée et qu’une transaction autre que celle qui a posé le verrou la réclame, elle doit
attendre la libération du verrou pour accéder à l’information. Les files d’attente pour l’accès aux données sont
gérées par des listes FIFO (Premier Entré Premier Sorti).
Exemple de transaction : Un exemple connu mais représentatif de la notion de transaction est celui du retrait
d’argent auprès d’un distributeur automatique. La transaction est alors constituée de deux opérations : le débit du
compte et la distribution d’argent. S’il n’est pas possible de réaliser l’une des deux opérations, c’est l’ensemble des
opérations qui devra être annulé. Il paraît déraisonnable de débiter le compte si la somme correspondante n’a pas

été distribuée à l’utilisateur.
b. Les ordres Transact SQL
Ils sont au nombre de quatre, BEGIN TRAN, COMMIT TRAN, ROLLBACK TRAN, SAVE TRAN qui indiquent respectivement
le début de la transaction, la fin avec succès, la fin avec échec et la définition des points d’arrêt.
BEGIN TRAN[SACTION]
Cette instruction permet de démarrer de façon explicite une transaction. En l’absence de cette commande, toute
instruction SQL est une transaction implicite qui est validée (COMMIT) aussitôt la modification effectuée sur les
données. On parle alors de mode autocommit. Lors du début de la transaction, il est possible de nommer la
transaction, mais aussi de marquer le début de la transaction dans le journal de la base de données. Cette marque
pourra être exploitée lors d’un processus de restauration des données pour restaurer la transaction.
BEGIN { TRAN | TRANSACTION } [nomTransaction]

[ WITH MARK [ ’description’ ] ]
[;]
Exemple
Dans l’exemple suivant, une nouvelle transaction est démarrée.
SAVE TRAN
Cette instruction permet de définir des points d’arrêt et donc donne la possibilité d’annuler une partie de la
transaction en cours. Il est possible de définir plusieurs points d’arrêt sur une même transaction. De façon à
permettre l’annulation jusqu’à un point d’arrêt précis, ils sont généralement identifiés par un nom.
SAVE { TRAN | TRANSACTION } {nomPointArret}[;]
Exemple
Dans l’exemple suivant, le point d’arrêt P1 est défini, après l’ajout d’un nouveau client.

ROLLBACK TRAN[SACTION]
L’instruction ROLLBACK permet d’annuler une partie ou la totalité de la transaction, c’estàdire des modifications
intervenues sur les données. L’annulation partielle d’une transaction n’est possible que si des points d’arrêt ont été
définis à l’aide de l’instruction SAVE TRAN. Il n’est pas possible d’arrêter l’annulation entre deux points d’arrêt.
ROLLBACK { TRAN | TRANSACTION }

[nomTransaction|nomPointArret][;]
Exemple
Dans l’exemple cidessous, les clients sans commande sont supprimés, puis une requête compte le nombre de clients
définis dans la base. Enfin, la suppression est annulée par l’intermédiaire de l’instruction ROLLBACK qui annule toutes les
modifications effectuées sur les données depuis la définition du point d’arrêt P1.

COMMIT
Cette instruction permet de mettre fin avec succès à une transaction, c’estàdire de conserver l’ensemble des
modifications effectuées dans la transaction. C’est simplement à l’issue de la transaction que les modifications sont
visibles par les autres utilisateurs de la base de données.
COMMIT { TRAN | TRANSACTION } [nomTransaction] [;]
Exemple
Les modifications sont validées et la transaction prend fin.

Pour SQL Server, si la transaction n’est pas commencée explicitement par la commande BEGIN TRAN, alors toute
instruction SQL constitue une transaction qui est comitée (validée) automatiquement.
Si au cours d’une transaction explicite, le client à l’origine de la transaction rompt brutalement sa connexion
avec le serveur, alors la transaction est annulée (ROLLBACK) automatiquement.
3. Les fichiers journaux
a. Le rôle
Les fichiers journaux permettent de stocker les images avant et après modification des données contenues dans la
base. Seules les opérations du DML (Langage de Manipulation de Données), soit les ordres SQL INSERT, UPDATE et
DELETE, provoquent une journalisation des opérations qu’elles effectuent sur les données de la base. Les
opérations de grande envergure, comme la création d’un index, sont mentionnées dans le journal. Le journal sera
utilisé principalement lors des opérations de restauration automatique suite à un arrêt brutal du serveur, ou bien
lors des opérations de sauvegardes lorsque ces dernières s’appuient sur le journal. Il sera également utilisé lorsque
la base participe à la réplication.
Le but du journal est de permettre au serveur de toujours garantir la cohérence des données, c’estàdire que
toutes les transactions validées (COMMIT) persistent même s’il arrive un gros problème causant l’arrêt brutal du
serveur.
Lors de chaque redémarrage du serveur, SQL Server vérifie que la dernière instruction du journal est un point de
synchronisation Si tel n’est pas le cas, toutes les transactions validées (COMMIT) sont rejouées tandis que toutes les
transactions non validées sont annulées (ROLLBACK).
b. Le fonctionnement
Fonctionnement du journal
Lorsqu’un ordre SQL est transmis au serveur SQL, ce dernier va chercher à l’exécuter le plus rapidement possible.
Après analyse de l’ordre et mise en place du plan d’exécution, si les données concernées par l’ordre ne sont pas
déjà présentes en mémoire, alors le moteur SQL va lire les fichiers sur le disque dur afin d’y trouver les informations
nécessaires. Une fois présentes en mémoire, les modifications peuvent être apportées aux données. La modification
est toujours enregistrée dans le journal avant d’être réellement effectuée sur les données de la base. Un tel journal
est appelé journal à écriture anticipée.

D’une façon logique toutes les informations sont enregistrées les unes à la suite des autres dans le journal. Chaque
information est parfaitement identifiée par son LSN (Log Sequence Number) ou numéro séquentiel d’enregistrement
dans le journal. Chaque enregistrement dans le journal contient également l’identifiant de la transaction à l’origine
de la modification des données. Tous les enregistrements d’une même transaction ne sont donc pas enregistrés de
façon contiguë.
Les fichiers journaux sont situés, par défaut, dans le répertoire C:\Program Files\ Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\Data, et portent l’extension *.ldf. Il s’agit d’une extension
recommandée qui n’est nullement obligatoire. Le journal peut être constitué d’un ou plusieurs fichiers, la taille de
ces derniers pouvant être fixe ou variable automatiquement ou de façon manuelle. La gestion des fichiers sera
abordée dans ce chapitre dans la partie B Créer, gérer et supprimer une base de données.
Le journal des transactions peut être constitué de plusieurs fichiers physiques. La gestion du journal est faite de
façon indépendante de celle des données. SQL Server gère un cache d’écriture spécifique au journal.
En fonction de l’utilisation faite des informations présentes dans le journal, il est possible de tronquer régulièrement
le journal de façon à toujours utiliser les mêmes fichiers physiques, tout en contrôlant l’espace disque occupé.
c. Les points de synchronisation
Régulièrement, SQL Server va déclencher un point de synchronisation. Il consiste à faire redescendre sur fichier
toutes les données stockées en mémoire qui correspondent à des données validées. Les points de synchronisation
sont également appelés CHECKPOINT. Le nombre de données touchées entre deux points de synchronisation va
déterminer le temps de restauration automatique suite à un arrêt brutal du serveur.

Principe de fonctionnement d’un point de synchronisation
SQL Server optimise les points de synchronisation de façon à garantir la meilleure gestion des données sans
détériorer les temps de réponse du serveur. Il est toutefois possible d’intervenir sur cette optimisation par
l’intermédiaire de l’instruction CHECKPOINT.
CHECKPOINT [tempsRealisation]
tempsRealisation
Permet de préciser le temps accordé en seconde pour terminer le point de synchronisation. C’est SQL Server qui se
charge de déclencher le point de synchronisation de façon à avoir terminé dans les temps.

Seul un arrêt de l’instance par l’intermédiaire de l’instruction Transact SQL SHUTDOWNWITH NOWAIT permet
d’arrêter l’instance sans déclenchement d’un point de synchronisation.
4. Les fichiers de données
a. Leur rôle
Chaque base de données possède au moins un fichier de données. Ce fichier va contenir l’ensemble des données
stockées dans la base. Chaque fichier de données ne peut contenir que des données en provenance d’une seule
base, il y a donc spécialisation des fichiers par rapport à la base de données.
b. La structure des fichiers de données
Les fichiers de données sont structurés pour répondre de manière optimum à toutes les sollicitations de la part du
moteur et surtout pour être capables de stocker plus de données en optimisant l’espace disque utilisé.
Pour optimiser l’espace dont il dispose, le serveur va formater les fichiers de données de façon à maitriser leur
structure.
Le travail réalisé par SQL Server sur ces fichiers de données est semblable au travail fait par le système
d’exploitation sur les disques disponibles sur la machine. Il est tout à fait admis que le système d’exploitation
formate l’espace disque dont il dispose afin de le diviser en blocs. Par la suite ce sont ces blocs qui vont être
accordés aux fichiers. SQL Server réalise le même type de travail sur les fichiers de données, puis accorde l’espace
disponible aux différentes tables et index.
Les pages
Avant de pouvoir travailler avec un fichier de données, SQL Server va structurer le fichier en le découpant en bloc ou
page de 8 Ko. La taille de 8 Ko est fixée par SQL Server, de façon à réduire les pertes d’espace tout en simplifiant les
opérations d’allocation, mais aussi de lecture et d’écriture. La page représente l’unité de travail de SQL Server. C’est
toujours une page entière de données qui est remontée en mémoire et c’est toujours une page qui est écrite sur le
disque. Il n’est pas possible de remonter en mémoire cache, une partie d’une page. Bien entendu, une page peut
contenir plusieurs lignes d’une table ou bien plusieurs entrées d’index et toutes les informations sont remontées en
une seule lecture disque.
Cette taille de 8 Ko permet également de gérer des bases de données de plus grande taille avec un nombre de blocs
moindre.
Enfin, pour éviter la fragmentation des lignes de données sur plusieurs blocs, une ligne doit toujours être
entièrement contenue (hors type text et image) dans un bloc. La taille maximale d’une ligne est donc de 8060 octets.
Cette valeur de 8060 octets est légèrement inférieure à 8 Ko car SQL Server réserve quelques octets pour gérer l’en
tête de la page afin d’en maitriser la gestion.
Si plusieurs lignes sont stockées dans la même page, elles le sont de façon séquentielle. En cas de changement de
taille des lignes, SQL Server gère dynamiquement le déplacement des lignes dans la page ou bien la mise en place
d’un pointeur vers une autre page afin de lire la fin de la ligne de données.
Étant donné que la page est l’unité de travail de SQL Server, chaque page contient un type bien précis de données.
Il est possible de distinguer les types de page suivants :
● données : ces pages contiennent des informations au format numérique, texte ou bien date.
● Texte/image : ces pages contiennent soit des textes volumineux, soit des objets au format binaire.
● Index : ces pages contiennent les entrées des index.
● GAM/SGAM : ou Global Allocation Map et Shared Global Allocation Map. Ces pages contiennent des informations
relatives à l’allocation des extensions.
● PFS : ou Page Free Space. Ces pages contiennent les informations relatives à l’allocation des pages et
l’espace disponible sur ces pages.
● IAM : ou Index Allocation Map. Ces pages contiennent les informations relatives à l’utilisation de pages par les
tables et les index.

● BCM : ou Bulk Change Map. Ces pages contiennent la liste des extensions modifiées par des opérations de
copie en bloc depuis la dernière sauvegarde du journal.
● DCM : ou Différentiel Change Map. Ces pages contiennent la liste de toutes les extensions modifiées depuis la
dernière sauvegarde de la base.
Le découpage en bloc des fichiers de données
Les extensions
Les extensions sont des regroupements logiques de 8 blocs contigus, elles ont donc une taille de 64 Ko (8 x 8 Ko).
Le rôle des extensions est d’éviter une trop grande dispersion des données pour un même objet au sein des fichiers
de données.
Il existe deux types d’extension : les extensions mixtes et les extensions propres ou uniformes. Ces deux types
d’extension permettent de limiter au mieux la consommation d’espace disque par une table en fonction du volume de
données à stocker.
Les extensions mixtes
Au départ, les extensions sont communes à plusieurs tables ou plusieurs index. Lorsqu’un des objets définis sur
l’extension demande la place, SQL Server octroie de la place bloc par bloc tant que l’objet n’utilise pas 8 blocs. Dès
qu’un objet franchit cette barrière, SQL Server lui octroie de la place extension par extension. L’avantage de cette
méthode est d’éviter de perdre de la place inutilement avec les tables ou index contenant peu de données.
Les extensions uniformes
Si un objet occupe plus de 64 Ko d’information, alors la place lui sera accordée extension par extension. Chacune des
extensions étant spécialisée pour un objet, les lectures disque seront d’autant plus rapides car toutes les données
sont stockées de façon contiguë par paquets de 64 Ko.

L’allocation des extensions
c. Le fonctionnement
Chaque base possède au moins un fichier de données, ce fichier est spécifique à une base. Son chemin par défaut
est C:\Program Files\Microsoft SQL Server\MSSQL10. MSSQLSERVER\MSSQL\Data. Le premier fichier de données
d’une base porte l’extension mdf, tous les suivants portent l’extension ndf. Ces extensions sont recommandées mais
ne sont pas obligatoires.

Créer, gérer et supprimer une base de données
Une base de données gère un ensemble de tables système et des tables utilisateurs. Les informations contenues dans
ces tables système représentent, entre autres, la définition des vues, des index, des procédures, des fonctions, des
utilisateurs et des privilèges. Les tables utilisateurs vont contenir les informations saisies par les utilisateurs.
Une instance SQL Server ne peut pas contenir plus de 32767 bases de données.
1. Créer une base de données
La création d’une base de données est une étape ponctuelle, réalisée par un administrateur SQL Server. Avant de
tenter de créer une base de données, il est important de définir un certain nombre d’éléments de façon précise :
● le nom de la base de données qui doit être unique sur le serveur SQL,
● la taille de la base de données,
● les fichiers utilisés pour le stockage des données.
Pour créer une nouvelle base de données, SQL Server s’appuie sur la base Model. Cette base Model contient tous les
éléments qui vont être définis dans les bases utilisateurs. Par défaut, cette base Model contient les tables système. Il
est cependant tout à fait possible d’ajouter des éléments dans cette base. Toutes les bases utilisateurs créées par la
suite disposeront de ces éléments supplémentaires.
Une base peut être créée de deux façons différentes :
● par l’intermédiaire de l’instruction Transact SQL CREATE DATABASE ;
● par l’intermédiaire de SQL Server Management Studio.
Une base de données est toujours composée au minimum d’un fichier de données principal (extension mdf) et d’un
fichier journal (extension ldf). Des fichiers de données secondaires (ndf) peuvent être définis lors de la création de la
base ou bien ultérieurement.
Cette opération de création de base de données affecte la base Master. Une sauvegarde de cette base système
s’avère donc nécessaire pour être en mesure de travailler avec la nouvelle base suite à une restauration.
Les informations concernant les fichiers de données sont enregistrées dans la base Master ainsi que dans le fichier
primaire de la base de données.
a. La syntaxe Transact SQL
CREATE DATABASE nomBaseDeDonnées

[ ON
[PRIMARY] [ <spécificationFichier> [,n]]
[LOG ON < spécificationFichier > [,n]]
]
[ COLLATE classement ]
[;]
Avec pour spécificationFichier les éléments de syntaxe suivants :
(NAME = nomLogique,
FILENAME = ’cheminEtNomFichier’
[,SIZE = taille [KB|MB|GB|TB]]
[,MAXSIZE={tailleMaximum[KB|MB|GB|TB]|UNLIMITED}]
[,FILEGROWTH = pasIncrement [KB|MB|GB|TB|%]]
) [,n]
PRIMARY

Permet de préciser le premier groupe de fichiers de la base. Ce groupe est obligatoire, car l’ensemble des tables
système est obligatoirement créé dans le groupe primary. Si le mot clé PRIMARY est omis, le premier fichier de
données précisé dans la commande CREATE DATABASE correspond obligatoirement au fichier primaire, il porte
normalement l’extension mdf.
NAME
Cet attribut, obligatoire, permet de préciser le nom logique du fichier. Ce nom sera utilisé pour faire des
manipulations sur le fichier via des commandes Transact SQL ; on pense notamment aux commandes DBCC ou à la
gestion de la taille des fichiers.
FILENAME
Spécification du nom et emplacement physique du fichier sur le disque dur. Le fichier de données est toujours créé
sur un disque local du serveur.
SIZE
Attribut optionnel qui permet de préciser la taille du fichier de données. La taille par défaut est de 1 Mo et la taille
minimale d’un fichier est 512 Ko aussi bien pour le journal que pour les fichiers de données. La taille peut être
précisée en kilooctets (Kb) ou en mégaoctets (Mb, par défaut). La taille du premier fichier de données doit être au
moins égale à celle de la base Model.
MAXSIZE
Cet attribut optionnel, permet de préciser la taille maximale en Méga octets (par défaut) ou en kilo octets que peut
prendre le fichier. Si rien n’est précisé, le fichier grossira jusqu’à saturation du disque dur.
FILEGROWTH
Il s’agit de préciser le facteur d’extension du fichier. La taille de chacune des extensions peut correspondre à un
pourcentage (%), à une taille en Méga octets (par défaut) ou en Kilo octets. Si on précise la valeur zéro, le facteur
d’extension automatique du fichier est nul et donc la taille du fichier ne change pas automatiquement. Si le critère
FILEGROWTH est omis, la valeur par défaut est de 1 Mo pour les fichiers de données et de 10 % pour les fichier
journaux. La taille des extensions est toujours arrondie au multiple de 64 Ko (8 blocs) le plus proche.
Toutes les options de l’instruction CREATE DATABASE ne sont pas exposées ici. Seules les options les plus
couramment utilisées lors de la création d’une nouvelle base le sont.

b. Utilisation de SQL Server Management Studio
Il est également possible de créer une base de données de façon graphique depuis SQL Server Management
Studio. Il faut alors sélectionner Nouvelle base de données depuis le menu contextuel associé au nœ ud Bases de
données depuis l’explorateur d’objets, comme illustré cidessous.
SQL Server Management Studio présente alors la boîte de dialogue des propriétés de la base en mode création.
Après avoir complété les options comme le nom de la base et le nom et l’emplacement des fichiers, il est possible de
demander la création de la base.

Cette boîte de dialogue permet à un utilisateur averti de créer rapidement et simplement une base de données,
tout en conservant la maîtrise de tous les paramètres.
Il est possible de créer des fichiers sur des partitions brutes. Cependant, cette technique n’offre qu’un faible gain de
performance par rapport à la création de fichiers sur des partitions formatées NTFS. De plus, les fichiers créés sur
des partitions brutes ne peuvent pas être manipulés par le système de fichiers (notamment dans le cadre des
sauvegardes base arrêtée) et il ne peut y avoir, bien sûr, qu’un seul fichier par partition.
Les fichiers de base de données ne doivent pas être créés sur des partitions compressées. Dans certains cas
extrêmes, il est possible de placer les fichiers secondaires sur des partitions compressées. Les fichiers doivent alors
être en lecture seule. Par contre, les fichiers journaux ne doivent en aucun cas être définis sur une partition
compressée.
2. Gérer une base de données
Lors de la gestion d’une base de données, plusieurs critères sont à prendre en compte. Dans cette section, la gestion
de l’espace utilisé par les fichiers physiques qui constituent la base de données est abordée. Les points principaux
qui concernent la gestion des fichiers sont : l’accroissement dynamique ou manuel des fichiers, l’ajout de nouveaux
fichiers, la réduction de la taille des fichiers.
a. Augmenter l’espace disque disponible pour une base de données
Les fichiers de données et les fichiers journaux stockent de l’information. Comme la base contient normalement de
plus en plus d’informations, à un moment donné ces fichiers seront complets. Il se posera alors le problème de
savoir où prendre la place.
Les différentes méthodes exposées cidessous pour augmenter l’espace de stockage dont dispose la base sont
complémentaires car chaque méthode possède ses avantages et ses inconvénients.
Fichier à accroissement dynamique
Lors de la création de la base, il est possible de fixer un certain nombre de critères concernant la taille maximale de

fichiers (MAXSIZE) et le taux d’accroissement (FILEGROWTH). Si ces options sont omises la taille maximale est infinie
et le taux d’accroissement est de 10 % pour les journaux et 1 Mo pour les fichiers de données.
En utilisant des fichiers à croissance dynamique, le serveur ne sera jamais bloqué par la taille du fichier sauf
saturation du disque ou taille maximale atteinte.
Le facteur d’accroissement permet de fixer la taille de tous les ajouts. Cette taille doit être fixée de façon optimale,
en prenant en compte le fait qu’un facteur d’accroissement trop petit introduit beaucoup de fragmentations
physiques du fichier et les demandes d’extension du fichier sont fréquentes, tandis qu’un facteur d’accroissement
trop grand nécessite une charge de travail importante de la part du serveur lorsque celuici met en place la
structure de blocs de 8 Ko à l’intérieur du fichier.
Si le taux d’accroissement est fixé à zéro, le fichier ne pourra pas grandir dynamiquement.
L’accroissement du fichier possède toujours une taille qui est multiple de 64 Ko (taille d’une extension).
Si le paramétrage des fichiers permet de gérer automatiquement la croissance des fichiers, cette solution présente
tout de même le désavantage du fait qu’il n’est pas possible de maîtriser quand cet accroissement aura lieu. Si cette
opération intervient en pleine charge de travail, elle risque de ralentir le serveur.
Par contre, si le paramétrage de l’accroissement automatique des fichiers est réalisé, cela permet en cas de
problème, que les fichiers adaptent leur taille en fonction du volume de données, sans bloquer les utilisateurs.
Fichier à accroissement manuel
La croissance manuelle des fichiers permet de maîtriser le moment où le fichier va grossir et donc le moment où le
serveur va subir une charge de travail supplémentaire pour mettre en forme le fichier s’il s’agit d’un fichier de
données.
Ajout de fichiers
Pour permettre à une base de données d’obtenir plus de place, il est enfin possible de rajouter des fichiers. Cette
solution présente le double avantage de maîtriser l’instant où le serveur va subir une surcharge de travail, ainsi que
de ne pas fragmenter physiquement les fichiers surtout si ces derniers sont stockés sur une partition NTFS.
Cependant cette solution nécessite que l’administrateur observe de près l’utilisation des fichiers journaux et de
données afin de toujours intervenir avant que le système ne se bloque pour un manque d’espace disque.
Le journal des transactions
Le journal des transactions est composé de un à plusieurs journaux. Afin que le serveur fonctionne correctement, il
est indispensable que le journal ne soit jamais saturé. Le journal est vidé lors des sauvegardes et éventuellement à
chaque point de synchronisation si la base est configurée en mode de restauration simple.
Pour assurer une place suffisante au journal, la solution la plus facile consiste à positionner le ou les fichiers qui le
composent avec une croissance automatique.
Modifier un fichier en Transact SQL
C’est l’instruction ALTER DATABASE qui permet d’effectuer toutes les opérations relatives aux manipulations des
fichiers de base de données, aussi bien pour les fichiers de données que les fichiers du journal de transaction.
Toutes les caractéristiques des fichiers peuvent être modifiées, mais les modifications apportées doivent suivre
certaines règles comme, par exemple, la nouvelle taille du fichier qui doit être supérieure à la taille initiale.
ALTER DATABASE nomBaseDeDonnées

MODIFY FILE (spécificationFichier)[;]
Avec pour spécificationFichier les éléments de syntaxe suivants :
(NAME = nomLogique,
NEWNAME = nouveauNomlogique,
FILENAME = ’cheminEtNomFichier’
[,SIZE = taille [KB|MB|GB|TB]]
[,MAXSIZE={tailleMaximum[KB|MB|GB|TB]|UNLIMITED}]
[,FILEGROWTH = pasIncrement [KB|MB|GB|TB|%]]
)

Ajouter un fichier en Transact SQL
C’est la commande ALTER DATABASE associée à l’option ADD FILE qui va permettre de rajouter un fichier de données
ou un fichier journal.
Syntaxe :

ADD FILE spécificationFichier[;]
Modifier et ajouter des fichiers depuis SQL Server Management Studio

C’est par l’intermédiaire de la boîte de dialogue qui indique les propriétés de la base de données, qu’il est possible
de gérer les opérations sur la taille des fichiers et sur leur taille.

Les fichiers du journal
Comme pour les fichiers de données, il est possible de redimensionner le fichier journal ainsi que d’ajouter un fichier
au journal des transactions. Si la modification peut s’effectuer comme pour les fichiers de données par
l’intermédiaire de la commande ALTER DATABASE nomBaseDonnées MODIFY FILE…, l’ajout quant à lui nécessite
l’utilisation de l’option ADD LOG FILE. Bien entendu comme pour les fichiers de données, toutes ces opérations
peuvent être effectuées depuis SQL Server Management Studio.

b. Libérer de l’espace disque utilisé par des fichiers de données vides.
Lorsque les tables sont vidées de leurs données à l’aide des commandes DELETE ou TRUNCATE TABLE, les
extensions occupées par les tables et index sont alors libérées. Par contre, la taille des fichiers n’est pas réduite.
Pour réaliser une telle opération il est important de s’assurer que la totalité de l’espace libre est regroupée en fin
de fichier. Une fois cette opération réalisée, il est possible de tronquer le fichier sans jamais redescendre en
dessous de la taille initiale.
La mise en place de la réduction des fichiers se fait au moyen de deux commandes DBCC.
SHRINKDATABASE
Cette instruction permet de compacter l’ensemble des fichiers constituant la base de données (journaux et
données). Pour les fichiers de données toutes les extensions utilisées sont stockées de façon contiguë en haut du
fichier. Pour les fichiers journaux, cette opération de compactage intervient en différé et SQL Server essaie de
rendre aux fichiers journaux une taille aussi proche possible que celle de la taille cible lorsque les journaux sont
tronqués.
Syntaxe :
DBCC SHRINKDATABASE {nom_base_données|id_base_données|0}

[,pourcentage_cible]
[,{NOTRUNCATE|TRUNCATEONLY}])
nom_base_données
Nom de la base de données sur laquelle va porter l’exécution de la commande
id_base_données
Identifiant de la base de données. Cet identifiant peut être connu en exécutant la fonction db_id() ou bien en
interrogeant la vue sys.databases depuis la base master.
Permet de préciser que l’exécution portera sur la base courante.

pourcentage_cible
Permet de préciser en pourcentage l’espace libre souhaité dans le fichier après compactage.
NOTRUNCATE
Permet de ne pas rendre au système d’exploitation l’espace libre obtenu après compactage. Par défaut, l’espace
ainsi obtenu est libéré.
TRUNCATEONLY
Permet de libérer l’espace inutilisé dans les fichiers de données et compacte le fichier à la dernière extension
allouée. Aucune réorganisation physique des données n’est envisagée : déplacement des lignes de données afin de
compléter au mieux les extensions utilisées par l’objet. Dans un tel cas, le paramètre pourcentage_cible est ignoré.
SHRINKFILE
Cette instruction, semblable à DBCC SHRINKDATABASE permet de réaliser les opérations de compactage et
réduction de fichier de données par fichier.
Syntaxe :
DBCC SHRINKFILE ([nom_fichier|id_fichier]

{[[,taille_cible]
[,{NOTRUNCATE|TRUNCATEONLY}]]|EMPTYFILE}
taille_cible
Permet de préciser la taille finale souhaitée exprimée en méga octets sous forme de nombre entier. Si aucune taille
n’est spécifiée, la taille du fichier est réduite à son maximum.
EMPTYFILE
Cette commande permet de réaliser la migration de toutes les données contenues dans le fichier vers les autres
fichiers du même groupe. De plus, SQL Server n’utilise plus ce fichier. Il est alors possible de le supprimer de la base
de données à l’aide d’une commande ALTER DATABASE.
NOTRUNCATE
Permet de ne pas rendre au système d’exploitation l’espace libre obtenu après compactage. Par défaut, l’espace
ainsi obtenu est libéré.
TRUNCATEONLY
Permet de libérer l’espace inutilisé dans les fichiers de données et compacte le fichier à la dernière extension
allouée. Aucune réorganisation physique des données n’est envisagée : déplacement des lignes de données afin de
compléter au mieux les extensions utilisées par l’objet. Dans un tel cas le paramètre taille_cible est ignoré.
Exemple :

La taille finale doit être supérieure à la taille de la base Model plus la taille des données.
Avant de réaliser une opération de compactage, il est prudent de réaliser une sauvegarde complète de la
base de données à compacter ainsi que de la base Master.
Les instructions DBCC SHRINKDATABASE et DBCC SHRINKFILE s’exécutent en mode différé, il est donc possible que
la taille des fichiers ne diminue pas de façon instantanée.
Seule l’instruction DBCC SHRINKFILE permet de réduire la taille d’un fichier à une taille inférieure à celle précisée lors
de la création du fichier. Evidemment, il n’est pas possible de descendre en dessous de la taille occupée par les
données.
c. Configuration de la base de données
Il est possible de paramétrer de nombreuses options au niveau de la base de données. Ce paramétrage est
possible soit avec l’instruction ALTER DATABASE en Transact SQL, soit depuis la fenêtre des propriétés de la base
dans SQL Server Management Studio. Tous les paramètres listés cidessous sont à fixer pour chaque base de
données. Il n’est donc pas possible de fixer des options sur plusieurs bases de données en une seule commande,
tandis qu’il est possible de préciser plusieurs options d’une base en une commande.
Si certains choix doivent être adoptés par toutes les bases utilisateur, il est préférable de changer les options de la
base Model, ainsi toute nouvelle base utilisateur, fonctionnera avec les paramètres définis dans Model.
ALTER DATABASE nomBaseDeDonnees

SET option [;]
Parmi toutes les options disponibles, il est possible d’en isoler quelquesunes :
Option Descriptif
AUTO_SHRINK {ON|OFF} Si cette option est activée les fichiers sont réduits dès qu’ils disposent de plus
de 25 % d’espace libre.
READ_ONLY Permet de positionner la base de données en mode lecture seule.

READ_WRITE La base de données est positionnée en mode lecture/ écriture.
SINGLE_USER Seul un utilisateur peut travailler sur la base de données.
RESTRICTED_USER Seuls les utilisateurs membres des rôles db_owner, db creator et sysadmin
peuvent se connecter à la base de données.
MULTI_USER C’est le mode de fonctionnement standard d’une base, en autorisant plusieurs

utilisateurs à travailler simultanément.
AUTO_CREATE_STATISTICS Lorsque cette option est positionnée à ON les statistiques manquantes lors de
{ ON | OFF } l’optimisation de la requête, sont calculées de façon automatique.
AUTO_UPDATE_STATISTICS Lorsque cette option est positionnée à ON, les statistiques obsolètes sont
{ ON | OFF} calculées de façon automatique
Les options AUTO_CREATE_STATISTICS et AUTO_UPDATE_STATISTICS ne concernent pas les tables système

ou bien à usage interne à SQL Server comme par exemple les index XML, les index de texte intégral, les
files d’attentes Service Broker. Pour toutes ces tables les statistiques sont créées et mises à jour quelle que soit
la valeur des options AUTO_CREATE_STATISTICS et AUTO_UPDATE_STATISTICS.
La fonction DATABASEPROPERTYEX permet de connaître la valeur actuelle de l’option qui lui est passée en
paramètre.
Pour régler les paramètres de la base il est possible de passer par :
Pour connaître et éventuellement modifier les paramètres d’une base de données, il faut afficher la fenêtre
présentant les propriétés de la base. Cette fenêtre est affichée en sélectionnant Propriétés depuis le menu
contextuel associé à la base de données.

ALTER DATABASE

Options actuellement gérées
Avant de fixer un nouveau paramétrage de la base de données, il est important de connaître le paramétrage actuel.
La connaissance de ce paramétrage peut également aider à la compréhension du fonctionnement de la base. Il est
possible de lire les valeurs des différentes options depuis SQL Server Management Studio, mais la connaissance du
paramétrage de la base peut également être faite sous la forme de script Transact SQL.
Databasepropertyex
Pour connaître la valeur d’un paramètre.

sp_helpdb
Si aucun paramètre n’est passé, cette procédure permet de connaître l’ensemble des bases qui existent sur le
serveur. Les renseignement fournis sont le nom, la taille, le propriétaire, l’identificateur, la date de création et les
options.
Si un nom de base est passé en paramètre, la procédure permet de connaître les informations générales de la base
ainsi que les nom et emplacement des fichiers de données et des fichiers journaux.
La procédure sp_helpdb utilise la table sys.databases pour établir la liste des bases et les différentes options de
chacune d’elles.

sp_spaceused [nom_objet]
Permet de connaître l’espace de stockage utilisé par une base de données, un journal ou des objets de la base
(table...).
Il est possible au niveau de SQL Server Management Studio d’obtenir un rapport sur l’utilisation de l’espace disque
par les différentes tables de la base de données en cours. Pour cela, après s’être positionné sur la base de
données cible, il faut sélectionner l’option Rapports Rapports standards. À ce niveau, trois choix sont disponibles
en fonction que l’on souhaite un rapport global sur l’espace disque utilisé, un rapport détaillé de la consommation
d’espace disque pour chaque table ou bien un rapport ne détaillant que les principales tables du serveur.

3. Supprimer une base de données
La suppression d’une base de données utilisateur est une opération ponctuelle qui peut être réalisée, comme la
plupart des opérations d’administration soit par SQL Server Management Studio, soit en Transact SQL. La
suppression de la base de données a pour conséquence de supprimer tous les fichiers qui correspondent à cette
base ainsi que toutes les données contenues dans cette base. Cette opération est irréversible et en cas de
mauvaise manipulation il est nécessaire de remonter une sauvegarde.
Après suppression d’une base de données, chaque connexion qui utilisait cette base par défaut se retrouve
sans base par défaut.
Afin de pouvoir réaliser d’éventuelles restaurations du serveur, il est important d’effectuer une sauvegarde
de la base Master après suppression d’une ou plusieurs bases utilisateur.
Les limites
Il n’est bien sûr pas toujours possible de supprimer une base, les principales limites sont :
● lorsqu’elle est en cours de restauration,
● lorsqu’elle est ouverte par un utilisateur, en lecture ou en écriture,
● lorsqu’elle participe à une publication dans le cadre de la réplication.
Il n’est pas possible de supprimer les bases de données système.
a. Transact SQL
C’est par l’intermédiaire de la commande DROP DATABASE que seront supprimées les bases de données.
b. SQL Server Management Studio
Par un simple clic droit sur la base de données, vous avez accès au menu Supprimer dans le menu contextuel. Par
cette méthode, il n’est possible de supprimer les bases qu’une par une.

Pour supprimer une base depuis SQL Server Management Studio, il est nécessaire de réaliser les opérations
suivantes :
● Se positionner dans l’explorateur d’objets.
● Sélectionner le nœ ud relatif à la base de données à supprimer.
● Sélectionner l’option Supprimer depuis le menu contextuel associé à la base.

Mise en place de groupes de fichiers
Il est possible de préciser les fichiers de données utilisés par la base, mais il est malheureusement impossible de
préciser sur quel fichier est créé un objet particulier. Pour résoudre ce problème, il existe la possibilité de créer une
table ou un index sur un ensemble de fichiers. Cet ensemble de fichiers, également appelé Groupe de fichiers, est
géré assez simplement.
Pourquoi estil nécessaire de travailler avec plusieurs groupes de fichiers? Parce qu’il est normal sur un système
d’exploitation de séparer les fichiers système, des programmes et des données utilisateur ; pourquoi en seraitil
autrement dans une base de données ? Il convient donc de regrouper sur un même groupe de fichiers des données de
même type. Par exemple, les données stables (comme par exemple les clients, les articles) des données de type
mouvement (comme par exemple les commandes, les factures…) tout simplement parce que les volumes ne sont pas
les mêmes, la façon de travailler avec non plus. Il peut être également intéressant de définir les index et les tables sur
des groupes de fichiers distincts afin de réduire les temps de mise à jour des données et des index. Dans le cas de
données sensibles, la répartition par groupe de fichiers peut également être conduite par la politique de sauvegarde
adoptée.
1. Création d’un groupe de fichiers
Avant de pouvoir utiliser les groupes de fichiers, il faut les créer. Lors de la création de la base, le groupe de fichiers
PRIMARY a été créé.
C’est par l’intermédiaire d’une commande ALTER DATABASE que l’on va créer un groupe de fichiers. Et cette
commande va permettre d’ajouter des fichiers à l’intérieur du groupe.
Syntaxe :
ALTER DATABASE nom_base_données

ADD FILEGROUP nom_groupe_fichier[;]
Exemple :
Depuis SQL Server Management Studio, la gestion des groupes de fichiers est réalisée par l’intermédiaire de la
fenêtre des propriétés de la base.

2. Ajout de fichiers
L’ajout de fichiers est réalisé par la commande ALTER DATABASE.
Un fichier ne peut appartenir qu’à un seul groupe de fichiers. Par défaut, si aucun groupe de fichiers n’est précisé lors
de l’ajout du fichier à la base, il est ajouté au groupe PRIMARY.
Syntaxe :
ALTER DATABASEnom_base_données
ADD FILE spécification fichier
TO FILEGROUP nom_groupe_fichier
Exemple :

Les fichiers qui participent à un groupe de fichiers sont gérés de la même façon que ceux qui participent au groupe de
fichiers Primary.
Depuis SQL Server Management Studio, la gestion des fichiers est possible depuis la fenêtre des propriétés de la
base.

3. Utilisation d’un groupe de fichiers
L’utilisation d’un groupe de fichiers par un objet doit être précisée dès la création de ce dernier. Seuls les objets
contenant de l’information sont concernés, soit les tables et les index. L’instruction ON nom_groupe_fichiers est
simplement ajoutée à la fin de la commande SQL et avant son exécution. Un fichier ne peut appartenir qu’à un et un
seul groupe de fichiers.
Par défaut, les objets sont créés sur le groupe PRIMARY.

Instructions Insert, Select... into
L’instruction SELECT INTO permet de projeter le résultat d’une commande SELECT dans une table. La table est créée
spécialement et de façon dynamique pour contenir le résultat du SELECT.
La table créée de la sorte ne dispose d’aucune contrainte d’intégrité.
La commande INSERT est également capable de prendre en charge le résultat d’une commande SELECT afin de le
projeter dans une table qui a été créée auparavant à l’aide de l’instruction SQL DDL CREATE TABLE.
Cette foisci, il est tout à fait possible d’inclure la définition de contraintes d’intégrité lors de la création de la table.

Structure des index
SQL Server propose deux types d’index :
● Les index organisés ou cluster ;
● Les index non organisés ou non cluster.
Etant donné que l’index est organisé (ou ordonné) organise physiquement les données stockées dans la table, il bien
souvent associé à la clé primaire de la table car il s’agit d’une données stable et peu volumineuse. Il n’est pourtant pas
obligatoire. Il peut parfois être utile d’organiser selon un autre critère, par exemple lorsque la clé primaire est dénuée
de sens. Chaque table possède au plus un index organisé.Les index non organisés, quant à eux n’affectent pas la
structure physique de la table. Par contre, comme ils reposent sur l’organisation physique des données, il est
nécessaire de les définir dans un second temps.
1. Les index ordonnés
Ces index qui organisent physiquement la table sont constitués d’un arbre dans lequel les pages de niveau feuille
contiennent les données de la table sousjacente. Les niveaux supérieurs de l’arbre permettent d’ordonner les
informations par rapport à la valeur indexée. Lors de l’ajout d’une ligne d’information, cette ligne est insérée en
fonction de la valeur de sa clé.
Etant donné que la clé de l’index organise physiquement la table, il est nécessaire de baser cet index sur une valeur
stable et c’est pourquoi la clé primaire est traditionnellement retenue.
Le schéma cidessous illustre de façon synthétique la structure d’un index ordonné. En plus des chaînages permettant
de parcourir l’arbre de bas en haut (depuis la racine vers les feuilles), il existe un double chaînage permettant de
parcourir toutes les pages d’un même niveau.
L’index ordonné est créé par défaut lorsqu’une contrainte de clé primaire est définie sur une table. Si l’administrateur
souhaite que la définition de la contrainte ne s’accompagne pas de la création d’un tel index il lui est nécessaire de
spécifier le mot clé NONCLUSTERED lors de la définition de la contrainte.
Syntaxe :
ALTER TABLE nomTable

ADD CONSTRAINT nomContrainte PRIMARY KEY
[CLUSTERED|NONCLUSTERED] (listeColonnes);
La seconde possibilité est de définir un index avec l’option CLUSTERED
Syntaxe :
CREATE [UNIQUE] [CLUSTERED|NONCLUSTERED] INDEX nomIndex

ON nomTable (listeColonnes)
[ON groupeDeFichiers];
2. Les index non ordonnés
L’autre type d’index qu’il est possible de définir au niveau de SQL Server concerne les index dits NONCLUSTERED,
c’estàdire que la définition de ces index ne réorganise pas physiquement la table. De ce fait, il est possible de définir
plusieurs index de ce type sur une même table.
Il n’est pas possible de définir plus de 249 index non ordonnés sur une même table.
Si la création d’un index ordonné (CLUSTERED) est planifiée pour une table, il est souhaitable que cette définition
intervienne avant la définition des index non ordonnés (NONCLUSTERED).
Comme pour les index ordonnés, ces index peuvent contenir une ou plusieurs colonnes, avec soit un tri ascendant
(par défaut), soit descendant pour chaque colonne. L’ordre de tri est spécifié à l’aide des caractères ASC pour
ascendant ou bien DESC pour descendant derrière le nom de chaque colonne.
Contrairement à l’index ordonné qui doit être posé sur des données relativement stables, l’index non ordonné peut
être défini sans prendre en compte la stabilité de valeurs indexées. C’est plutôt l’utilisation qui est faite des données
qui va permettre de définir ces index. Les opérations de tri et de jointure peuvent être très nettement accélérées
grâce à la définition de d’index.
Si un index ordonné est défini sur une table qui possède des index non ordonnés, alors les index non ordonnés sont
reconstruits.
Les critères permettant de définir ou non les index peuvent être définis au travers de l’assistant paramétrage
de base de données. L’utilisation de cet outil est détaillée au chapitre Optimisation.
Exemple :
L’exemple suivant illustre la définition d’un index sur la colonne ville de la table des clients.
Il est également possible de définir ce type d’index directement depuis SQL Server Management Studio.

3. Les index couvrants
Il s’agit cette fois d’une particularité de SQL Server, qui consiste à définir des index qui vont contenir au niveau feuille
la clé de l’index ainsi que les valeurs issues d’une ou de plusieurs colonnes. L’objectif de ces index est de permettre au
moteur SQL Server de ne parcourir que l’index, sans qu’il soit nécessaire d’accéder à la table pour répondre aux
besoins de données d’une requête.
En terme de volume de données manipulées le gain peut être conséquent, toutefois il est à pondéré par rapport au
volume disque occupé mais aussi par le temps supplémentaire nécessaire pour mener à bien les actions de mise à jour
(INSERT, UPDATE et DELETE).
De tels index sont définis à l’aide de l’instruction CREATE INDEX suivi du mot clé INCLUDE afin de préciser la ou les
colonnes à inclure au niveau colonne.
Syntaxe :
CREATE [UNIQUE] [CLUSTERED|NONCLUSTERED] INDEX nomIndex

ON nomTable (listeColonnes)
INCLUDE (listeColonnes)
[ON groupeDeFichiers];
Exemple :
Dans l’exemple suivant, un index est défini sur le prénom du client et le nom est inclus au niveau feuille.

4. Indexer des colonnes calculées
Toujours dans l’objectif de répondre rapidement aux utilisateurs, il est possible de définir des colonnes calculées dans
une table. Toutefois pour pouvoir être défini, le calcul devra être élémentaire, c’estàdire portant sur chaque ligne de
données et non pas issu d’un regroupement. Les données doivent toutes provenir de la même table et la fonction de
calcul doit être déterministe.
Dans ce cas, il est possible de définir un index sur ces colonnes calculées.
Exemple :
5. Indexer les vues
Les vues sont fréquemment utilisées dans les requêtes d’extraction car elles permettent, entre autres, de simplifier
l’écriture des requêtes. Pour améliorer les performances des requêtes qui utilisent les vues, il est possible de définir
un ou plusieurs index sur les vues.
Le point de départ consiste à définir un index ordonné (CLUSTERED) unique afin de matérialiser la vue. Par la suite des
index non ordonnés peuvent être définis sur la vue. Même les colonnes présentant le résultat d’un calcul peuvent être
indexées.

La syntaxe de définition d’un index sur une table ou bien sur une vue est exactement identique.
Exemple :
6. Les index XML
Comme pour les autres colonnes il est possible d’indexer les colonnes de type XML. Cependant, l’indexation des
données XML est particulière en fonction de la structure même des données. Lors du traitement d’une requête, les
informations XML sont analysées au niveau de chaque ligne, ce qui peut entraîner des traitements longs et couteux
lorsque le nombre de lignes est important et/ou quand les informations au format XML sont nombreuses.
Le mécanisme habituel d’indexation qui repose sur un arbre balancé va être utilisé pour définir l’index dit principal sur
la colonne de type XML. Mais les index qui vont effectivement permettre d’accélérer le traitement des requêtes sont les
index qui vont reposer sur cet index principal. Ces index secondaires sont définis par rapport aux types de requêtes
fréquemment exécutées :
● index PATH pour des requêtes portant sur le chemin d’accès;
● index PROPERTY pour des requêtes portant sur les propriétés;
● index VALUE pour des requêtes portant sur des valeurs.
Il est également possible de définir un index de type texte intégral sur les colonnes de type XML.
a. Index Principal
L’index principal représente le point de départ à toute indexation de la colonne de type XML. Il ne peut être défini
que sur une table qui possède une contrainte de clé primaire associée à un index qui organise physiquement la
table. Ce qui est fréquemment le cas.
Syntaxe :
CREATE PRIMARY XML INDEX nomIndex ON table(colonneXML)[;]
Exemple :

Un index principal est défini sur la colonne page de la table catalogue.
b. Index secondaire
La définition d’un index secondaire n’est possible que si et seulement si un index primaire est déjà défini sur la
colonne.
Le document XML ne peut contenir que 128 niveaux au maximum. Les documents qui possèdent une hiérarchie plus
complexe sont rejetés lors de l’insertion ou de la modification des colonnes.
L’indexation, quant à elle, porte sur les 128 premiers octets du nœ ud. Les valeurs plus longues ne sont pas prises
en compte dans l’index.
Syntaxe :
CREATE XML INDEX nomIndex ON table(colonneXML)

USING XML INDEX nomIndexXMLPrincipal
FOR {PATH|PROPERTY|VALUE}[;]
PATH
Permet de construire un index sur les colonnes path et value (chemin et valeur) de l’index XML principal. Un tel index
peut participer à améliorer sensiblement les temps de réponses lors de l’utilisation de la méthode exist(), dans une
clause where par exemple.
PROPERTY
Permet de construire un index sur les colonnes PK, path et value de l’index XML principal. Le symbole PK correspond
à la clé primaire de la table. Ce type d’index est donc utile lors de l’utilisation de la méthode value() dans les
requêtes SQL de manipulation de données.
VALUE
Permet de construire un index sur les colonnes value et path de l’index XML principal. Ce type d’index est utilisé dans
les requêtes pour lesquelles la valeur du nœ ud est connue indépendamment du chemin d’accès, ce qui peut être le
cas lors de l’utilisation de la méthode exist() par exemple.
Exemple :
Dans l’exemple présenté ciaprès, les trois types d’index sont créés par rapport à l’index XML principal défini sur la colonne

page de type XML de la table Catalogue.
7. Les index spatiaux
SQL Server 2008 permet de stocker des données spatiales de type geometry ou geography. Comme pour toutes les
informations conservées pas SQL Server, le moteur se doit de fournir un accès rapide aux informations. Dans cet
objectif les index jouent un rôle crucial. Il est donc tout à fait logique que SQL Server propose d’indexer les colonnes
de type spatial.
La structure de ces index diffère des index classiques. Pour ce type d’index, SQL Server définit une structure
compatible avec les données spatiales en définissant un maillage sur quatre niveaux afin d’accéder rapidement à la
cellule souhaitée. Chaque niveau correspond à un maillage défini sur 16, 64 ou 256 cellules. Chaque cellule d’un
niveau est détaillée par une grille de niveau inférieur. Par exemple, si le choix est fait de travailler avec une grille de 16
cellules au niveau 1 alors le niveau 4 (le plus détaillé) comportera 65536 cellules. Le nombre de cellules définies dans
les grilles des différents niveaux représente la densité de l’index. Cette densité peut prendre les valeurs LOW (16
cellules), MEDIUM (64 cellules) ou bien HIGH (256 cellules).
Les zones géographiques contenues dans la table sont ainsi indexées et le parcours des différents niveaux de l’index
permet de localiser rapidement la ou les cellules qui contiennent la zone cible de la recherche.
Afin de limiter l’étendue des grilles d’index, lors de la définition de l’index, la zone géographique à prendre en compte
pour l’indexation est définie à l’aide de l’option BOUNDING BOX.
Syntaxe :
CREATE SPATIAL INDEX nomIndex

ON nomTable(nomColonne)
WITH (
BOUNDING_BOX=(xMin, yMin, xMax, yMAX),
GRIDS(LEVEL_1=densité1, LEVEL_2=densité2, LEVEL_3=densité3, LEVEL_4=densité4)
);
Ou
CREATE SPATIAL INDEX nomIndex

ON nomTable(nomColonne)
USING {GEOMETRY_GRID|GEOGRAPHY_GRID}
WITH (
BOUNDING_BOX=(xMin, yMin, xMax, yMAX),
GRIDS(densité)
);

L’option USING permet de spécifier lors de la création de l’index si les données indexées sont de type géométrique ou
bien géographique.
Comme précisé précédemment, la densité peut prendre les valeurs LOW, MEDIUM ou HIGH. Si le niveau de densité
n’est pas spécifié lors de la création de l’index alors un index est défini avec une densité de type MEDIUM par défaut.
Exemple :
Les index de types spatiaux peuvent être définis sur un groupe de fichiers différents de celui qui contient la
table indexée.

Le partitionnement des tables et des index
L’objectif du partitionnement est d’offrir une meilleure montée en charge sur les tables très volumineuses en termes de
données et accédées par de nombreux utilisateurs.
Le partitionnement peut être utile pour diviser la méthode d’accès aux données. Par exemple, sur la table des
commandes, il n’est possible de modifier (update) que les commandes de l’année comptable en cours. Les commandes
des années précédentes doivent être en lecture seule.
Le partitionnement d’une table permet de diviser une table de grande dimension en plusieurs tables. Chacune de ces
soustables est plus petite que la table initiale et donc plus facile à gérer pour SQL Server. C’est l’union des données
présentes dans toutes ces soustables qui correspond à la table d’origine.
Chacune de ces soustables peut être créée sur un groupe de fichiers différent, ce qui rend possible la gestion de
paramètres de stockage différents pour chaque partition de la table initiale et adapter ainsi les conditions de stockage
des données en fonction de leur utilisation.
La table partitionnée permet d’optimiser le stockage des informations, sans que le nombre de tâches administratives
supplémentaires soit important. En effet, des éléments tels les contraintes d’intégrités, les déclencheurs sont définis au
niveau de la table sans tenir compte de l’espace de stockage physique utilisé.
La répartition des données entre les différentes partitions de la table sera effectuée automatiquement en fonction des
critères de répartition définis lors de la création de la table.
Il est également possible de laisser SQL Server répartir automatiquement les données entre les différents groupes de
fichiers. Bien que cette solution soit simple à mettre en place, elle ne présente que peu d’intérêt car les données ne
sont pas regroupées suivant des critères logiques. Les extractions sont donc rarement centrées sur un seul groupe de
fichiers.
Pour partitionner la table, il est donc nécessaire de définir une fonction de partitionnement. Cette fonction va retourner
une clé de partitionnement qui va être utilisée pour sélectionner la partition à utiliser en fonction du plan de partition
défini.
Si deux tables utilisent la même fonction de partitionnement et le même schéma de partitionnement, alors les données
en relations seront stockées sur le même groupe de fichiers. Dans un tel cas de figure, les données sont dites alignées.
Il est possible de créer des index sur une table partitionnée. L’index créé est alors partitionné. Comme sur toute table, il
est possible de définir un index organisé (CLUSTERED). Si le choix de définir un tel type d’index est fait, alors
l’organisation physique des données doit être en relation avec les éléments passés à la fonction de partitionnement.
C’estàdire que les colonnes passées en paramètre à la fonction de partitionnement doivent être présentes dans la

définition de l’index. Ainsi, l’organisation physique de la table suit la répartition des données entre les différents
groupes de fichiers.
1. La fonction de partitionnement
C’est la fonction de partitionnement qui va permettre d’orienter les données sur un groupe de fichiers ou bien un
autre. Pour répartir les données entre les différentes partitions, la fonction utilise des plages de valeur. Chaque plage
est bornée par des valeurs. Seules les valeurs frontières sont indiquées dans la fonction de partitionnement. Dans le
cas où la valeur frontière doit être incluse dans la plage de valeur inférieure, il faut utiliser le mot clé LEFT. Le mot clé
RIGHT permet d’inclure la valeur frontière dans l’espace suivant.
SQL trie toujours les données de façon ascendante.
Syntaxe
CREATE PARTITION FUNCTION nomfonction ( parametre)

AS RANGE [ LEFT | RIGHT ] FOR VALUES ( [ valeurLimite [ ,... ] ] )
parametre
Colonne de tous types sauf timestamp, varchar(max), nvarchar(max) et varbinary utilisé pour calculer la clé de
partitionnement.
valeurLimite
Valeur marquant la frontière de chaque partition.
Exemple
Dans l’exemple suivant, une fonction de partitionnement est définie sur une valeur de type entière. Cette fonction définie
quatre partitions différentes :
● 1ère partition pour les valeurs inférieures ou égale à 10 000.
● 2ème partition pour les valeurs strictement supérieures à 10 000 et inférieures ou égale à 20 000.
● 3ème partition pour les valeurs strictement supérieures à 20 000 et inférieures ou égale à 30 000.
● 4ème partition pour les valeurs strictement supérieures à 30 000.

2. Le schéma de partitionnement
Le schéma de partitionnement va permettre d’établir une table de correspondance entre les valeurs retournées par la
fonction de partitionnement et l’utilisation d’une partition ou bien d’une autre. Chaque partition va être affectée à un
groupe de fichiers. Il est possible, bien que non recommandé, d’utiliser le même groupe de fichiers pour toutes les
partitions.
Il est également possible de préciser plus de groupes de fichiers que ne réclame la fonction de partitionnement. Dans
ce cas, le premier groupe de fichiers supplémentaire sera marqué NEXT USED, c’estàdire comme le prochain groupe
de fichiers à utiliser si la fonction de partitionnement définit une nouvelle partition.
Syntaxe
CREATE PARTITION SCHEME nomSchemaPartition

AS PARTITION nomFonctionPartition
[ ALL ] TO ( { groupeDeFichier | [ PRIMARY ] } [,_] )
[ ; ]
nomSchemaPartition
Identifiant du schéma de partitionnement.
nomFonctionPartition
Nom de la fonction de partitionnement relative au schéma. Un schéma ne peut faire relation qu’à une et une seule
fonction. Par contre, une même fonction peut être utilisée par plusieurs schémas.
groupeDeFichier
Nom du ou des groupes de fichiers utilisés par les différentes partitions.
Exemple
Dans l’exemple cidessous, un schéma de partitionnement est défini par rapport à la fonction de partitionnement définie lors
de l’exemple précédent.

3. La table partitionnée
La répartition des données entre les différentes partitions de la table va être une opération transparente pour les
utilisateurs de la table. Par contre, lors de la création de la table, il faut indiquer le schéma de partitionnement à
utiliser ainsi que la colonne qui sera utilisée par la fonction de partitionnement, pour décider de l’affectation de la
partition à chaque ligne d’information. Le type de cette colonne doit parfaitement correspondre à celui du paramètre
de la fonction. Dans le cas où la colonne utilisée pour le calcul du partitionnement est une colonne calculée, alors elle
doit être de type PERSISTED.
Syntaxe
CREATE TABLE nomTable(

definitionColonne [,...]
) ON
nomSchemaPartition(colonneUtiliséePourCalculerLaPartition)[;]
Les informations données ici pour les tables sont également valables pour les index.
Exemple
Dans l’exemple suivant, la table TCLIENTS est définie en utilisant le schéma de partitionnement défini lors de l’exemple
précédent.

4. Les index partitionnés
Comme pour les tables, il est tout à fait possible de partitionner les index. Le processus de partitionnement est le
même, c’estàdire qu’il s’appuie sur un schéma et une fonction de partitionnement. Il est toutefois fortement
recommandé que l’index partitionné soit défini sur une table déjà partitionnée et qu’il s’appuie sur les mêmes schémas
et fonctions de partitionnement.
Si la colonne de partitionnement ne fait pas partie des colonnes indexées alors elle est incluse dans l’index comme une
colonne incluse qui permet de définir des index couvrants.
Syntaxe
CREATE INDEX nomIndex

ON nomTable(colonne1,...)
ON nomSchemaPartition(colonneDePartition);
Exemple
Un index est défini sur la colonne nom la table partitionné TCLIENTS

La compression des données
SQL Server 2008 donne la possibilité pour les éditions Entreprise et Developer d’activer la compression au niveau des
tables et des index. Si la compression peut être définie sur des tables et index existants, il ne sera pris en compte
qu’après la reconstruction de la table (ALTER TABLE nomTable REBUILD) ou bien de l’index concerné. Si la compression
de la table entraîne la compression de l’index organisé (CLUSTERED), les index non organisés ne sont pas affectés, et il
est nécessaire d’activer la compression sur chacun d’eux un par un. Dans le cas des tables partitionnées, la
compression peut être mise en place partition par partition.
La compression n’est possible que sur les données utilisateur. Les tables système ne peuvent pas être
compressées.
L’objectif de la compression est de réduire l’espace disque utilisé par les données de la table. La compression des
données va permettre de stocker plus de lignes d’informations sur le même bloc de 8 Ko. La compression ne permet
pas d’augmenter la taille maximale des lignes. En effet, le mécanisme doit être réversible.
Sur des tables valorisées, il est possible de connaître l’impact de la compression des données en exécutant la
procédure stockée sp_estimate_data_compression_savings.
La mise en place de la compression est une opération ponctuelle. Aussi, estil préférable de passer par l’assistant
proposé par SQL Server Management Studio. Au niveau Transact SQL, la compression est mise en place avec les
instructions CREATE TABLE/CREATE INDEX et ALTER TABLE/ALTER INDEX.
L’assistant de compression des données est lancé depuis le menu contextuel associé à la table en sélectionnant
l’option Stockage Gérer la compression.

L’encryptage des données
SQL Server 2008 propose de crypter les fichiers de données et les journaux. Ce cryptage est dynamique et est effectué
lors de chaque écriture sur le disque. Il est en est de même pour l’opération de décryptage. Cette fonctionnalité de
cryptage/décryptage transparent est identifiée sous le nom TDE ou Transparent Data Encryption.
Cette opération de cryptage ne concerne pas les données de type FILESTREAM.
La mise en place de cette opération de cryptage permet de garantir une opacité plus grande des fichiers de données
et journaux face aux différents outils système d’analyse des fichiers, ou bien pour éviter un détachement/attachement
de base de données non autorisé. Cependant cette opération de cryptage n’apporte aucune garantie supplémentaire
en ce qui concerne la communication entre le processus client et le serveur. Lorsque le cryptage de la base de données
est actif, les sauvegardes sont également cryptées avec la même clé. Il est donc nécessaire de posséder cette clé pour
être en mesure de restaurer les données.
Le cryptage des données s’appuie sur une clé de cryptage (DEK : Database Encryption Key) qui est enregistrée dans la
base master par exemple sous la forme d’un certificat.
Avant de pouvoir mettre en place le cryptage sur une base, il faut commencer par définir une clé principale afin
d’obtenir un certificat valide. Le certificat est alors utilisé pour définir la clé de cryptage. La génération de cette clé peut
être réalisée par différents algorithmes. Le nom de l’algorithme choisi est passé en paramètre à l’instruction CREATE
DATABASE ENCRYPTION KEY.
Exemple
Dans l’exemple ci dessous, le cryptage est défini sur la base Gescom.
À partir de SQL Server Management Studio, il est possible d’activer ou non la prise en charge du cryptage au niveau de
la base de données depuis la page options des propriétés de la base de données.

L’activation du cryptage sur une base de données affecte tous les fichiers de données et si un groupe de fichiers est
positionné en lecture seule alors cette activation échoue.

Planification
1. Dimensionner les fichiers
Afin d’évaluer la taille des fichiers nécessaires au stockage des informations contenues dans la base il faut prendre
en compte de nombreux critères.
Pour les fichiers de données
● distinguer les tables système et utilisateur,
● prendre en compte le nombre de lignes dans les tables,
● recenser les valeur indexées (clé, nombre de ligne, facteur de remplissage).
C’est après une fine évaluation de la quantité d’espace occupée qu’il est possible de fixer la taille initiale des fichiers
de données. La méthode la plus simple est d’évaluer la longueur moyenne d’une ligne, de calculer combien de lignes
peuvent être stockées dans un bloc de 8 Ko, et enfin de trouver le nombre de blocs nécessaires pour stocker toutes
les lignes de la table. À partir de ce nombre de blocs utilisés par la table, il convient de prendre le multiple de 8
immédiatement supérieur puis de diviser par 8 pour obtenir le nombre d’extensions.
Pour les fichiers journaux
● l’activité,
● la fréquence,
● la taille des transactions,
● les sauvegardes.
C’est la prise en compte de ces critères, ainsi que la consultation des options de la base, qui vont permettre de fixer
une taille optimale pour le fichier journal. Au départ il peut être utile de fixer la taille du journal entre 10 % et 25 % de
la taille des données dans la base. Ce pourcentage est à diminuer si la base supporte principalement des requêtes
de sélection SELECT, qui n’utilisent pas le journal.
2. Nommer la base et les fichiers de façon explicite
Il est important de prévoir le nom de la base, les noms logiques, physiques et la taille des fichiers ainsi que la gestion
dynamique ou non de l’accroissement.
3. Emplacement des fichiers
L’emplacement des fichiers données et journaux doit être spécifié avec précision afin de réduire au maximum les
conflits d’accès au disque, et de faire travailler tous les disques de la machine de façon équitable.
4. Utilisation des groupes de fichiers
Il peut être intéressant, afin de limiter les conflits d’accès disque, de créer plusieurs groupes de fichiers sur le serveur
et de spécialiser chacun d’eux. Un bon exemple consiste à laisser sur le groupe de fichiers PRIMARY, l’ensemble des
tables système de la base et de créer un deuxième groupe pour les tables utilisateur. Une telle méthode permet de
séparer les données et les tables système. Il est parfois envisageable de créer un troisième groupe pour les index.

Introduction
Le contrôle d’accès représente une opération importante au niveau de la gestion de la sécurité sur un serveur de
bases de données. La sécurisation des données nécessite une organisation des objets de façon indépendante des
utilisateurs, ce qui est possible par les schémas. La sécurité passe également par un meilleur contrôle des
autorisations et la possibilité d’accorder juste les privilèges nécessaires à chaque utilisateur pour qu’il puisse travailler
de façon autonome.
Pour l’organisation de cette politique de sécurité, il faut prendre en compte l’organisation hiérarchique des éléments de
sécurité, de façon à rendre la gestion des droits d’accès simple et efficace.
SQL Server s’appuie sur trois éléments clés qui sont :
● les entités de sécurité ;
● les sécurisables ;
● les autorisations.
Les entités de sécurité sont des comptes de sécurité qui disposent d’un accès au serveur SQL.
Les sécurisables représentent les objets gérés par le serveur. Ici, un objet peut être une table, un schéma ou une
base de données par exemple.
Les autorisations sont accordées aux entités de sécurité afin qu’elles puissent travailler avec les sécurisables.
L’organisation hiérarchique permet d’accorder une autorisation (par exemple SELECT) sur un sécurisable de niveau
élevé (par exemple le schéma) pour permettre à l’entité de sécurité qui reçoit l’autorisation d’exécuter l’instruction
SELECT sur toutes les tables contenues dans le schéma.
Les vues du catalogue système permettent d’obtenir un rapport complet et détaillé sur les connexions existantes, les
utilisateurs de base de données définis et les privilèges accordés. Quelquesunes de ces vues sont présentées ci
dessous :
● sys.server_permissions : liste des permissions de niveau serveur et de leurs bénéficiaires.
● sys.sql_logins : liste des connexions
● sys.server_principals : entité de sécurité définie au niveau serveur
● sys.server_role_members : liste des bénéficiaires d’un rôle de serveur.
● sys.database_permissions : liste des permissions et de leur bénéficiaire au niveau base de données.
● sys.database_princpals : entité de sécurité de niveau base de données.
● sys.database_role_members : liste des bénéficiaires d’un rôle de base de données.
Pour simplifier la gestion des droits d’accès, il est possible d’utiliser trois types de rôles. Les rôles de serveur qui
regroupent des autorisations au niveau du serveur, ces autorisations sont valables pour toutes les bases installées.
Les rôles de base de données, regroupent quant à eux des droits au niveau de la base de données sur laquelle ils
sont définis. Et enfin les rôles d’applications, définis sur les bases de données utilisateur, permettent de regrouper les
droits nécessaires à la bonne exécution d’une application cliente.

Gestion des accès Serveur
Avant de pouvoir travailler avec les données gérées par les bases, il faut dans un premier temps se connecter au
serveur SQL. Cette étape permet de se faire identifier par le serveur SQL et d’utiliser par la suite tous les droits qui sont
accordés à notre connexion. Il existe dans SQL Server deux modes de gestion des accès au serveur de base de
données.
Attention, dans cette section, seule la partie connexion au serveur est abordée. Il est important de bien distinguer la
connexion au serveur et l’utilisation de bases de données. La connexion au serveur permet de se faire identifier par le
serveur SQL comme un utilisateur valide, pour utiliser, par la suite, une base de données : les données et les objets.
L’ensemble de ces droits seront définis ultérieurement. Ces droits sont associés à un utilisateur de base de données,
pour lequel correspond une connexion.
On parlera de connexion au serveur ou de logins.
1. Mode de sécurité Windows
Ce type de gestion de la sécurité permet de s’appuyer sur les utilisateurs et les groupes Windows pour le domaine et
le poste local. SQL Server utilise la gestion des utilisateurs de Windows (gestion des mots de passe...) et récupère
uniquement les noms pour créer des connexions au serveur.
Une fonctionnalité très importante de SQL Server est de pouvoir autoriser des groupes Windows à venir se connecter.
La gestion des groupes permet de réaliser une administration plus souple que celle des utilisateurs. La méthode la
plus simple pour gérer les connexions est de passer par la création d’un groupe local. Ce groupe local est autorisé à
se connecter au serveur SQL et est utilisé par des utilisateurs ou des groupes globaux.
Avec une telle méthode de fonctionnement, comme un utilisateur Windows peut appartenir à plusieurs groupes, il peut
posséder plusieurs droits de connexion à SQL Server.
Authentification Windows
En mode sécurité Windows, seuls les noms d’utilisateurs sont stockés. La gestion des mots de passe et de
l’appartenance aux différents groupes est laissée à Windows. Ce mode de fonctionnement permet de bien discerner
les tâches de chacun et de spécialiser SQL Server sur la gestion des données en laissant Windows gérer les
utilisateurs, ce qu’il sait bien faire. De plus avec un tel schéma de fonctionnement, il est possible d’appliquer la
politique suivante : un utilisateur = un mot de passe. L’accès au serveur SQL est transparent pour les utilisateurs
approuvés par Windows.
SQL Server s’appuie sur les groupes auxquels appartient l’utilisateur lors de la connexion au serveur. Si des
modifications d’appartenance aux groupes sont effectuées depuis Windows, ces modifications ne seront
prises en compte que lors de la prochaine connexion de l’utilisateur au serveur SQL.
SQL Server s’appuie sur le SID de Windows pour identifier le groupe. Si un groupe est supprimé puis recréé
dans Windows, il est important de réaliser la même opération en ce qui concerne la connexion du groupe dans
SQL Server.
2. Mode de sécurité Mixte
Le mode de sécurité Mixte repose sur une authentification Windows puis sur une authentification SQL Server. C’est ce
mode d’authentification qui va être détaillé ici.

a. Définition
Il s’agit du fonctionnement le plus connu pour la sécurité des serveurs de bases de données. Dans un tel mode de
fonctionnement, c’est SQL Server qui se charge de vérifier que l’utilisateur qui demande à se connecter est bien
défini puis il se charge également de vérifier le mot de passe.
Mode de sécurité mixte
Tous les utilisateurs sont entièrement gérés par SQL Server (nom et mot de passe). Ce type de gestion des
connexions est bien adapté pour des clients qui ne s’identifient pas auprès de Windows.
b. Principe de fonctionnement
Il est trompeur de croire qu’en mode de fonctionnement Mixte seul le serveur se charge de la vérification des noms
d’utilisateur et des mots de passe. Dans un premier temps, lorsqu’un utilisateur du réseau tente de se connecter au
serveur SQL, un test est fait en utilisant la sécurité Windows. Si l’utilisateur du réseau est approuvé dans SQL
Server, ou s’il appartient à un groupe qui est approuvé dans SQL Server, alors l’utilisateur sera connecté au serveur
SQL. Dans le cas contraire (échec de la connexion en utilisant la sécurité Windows), SQL Server se charge de
demander un nom de connexion et un mot de passe.
3. Base de données par défaut
Après la définition des connexions (logins) au serveur, il est important de définir dans les différentes bases de
données utilisateur, des utilisateurs qui correspondent à ces connexions. Les droits d’utilisation à l’intérieur de la base
seront attribués aux utilisateurs de la base. Il est important également de définir pour chaque connexion ou login, une
base de données par défaut. C’est sur cette base que sera positionné tout utilisateur qui utilise cette connexion.
Attention à bien prendre en compte le fait que définir une base de données par défaut ne donne pas de droits
d’utilisation sur cette base.

4. Comment choisir un mode de sécurité ?
Il est possible de modifier le mode de sécurité utilisé par le serveur SQL directement depuis SQL Server Management
Studio en allant modifier les propriétés de l’instance comme ciaprès.

Lors de l’installation du serveur SQL, deux connexions sont prédéfinies, en mode Windows, le groupe local des
Administrateurs est autorisé à se connecter, et en mode de sécurité SQL Server, l’utilisateur sa peut se connecter au
serveur. Ces deux utilisateurs possèdent des privilèges d’administrateur du serveur SQL.
Il est recommandé d’utiliser la sécurité Windows qui offre une plus grande souplesse au niveau de la gestion
des utilisateurs.
5. Gérer une connexion à SQL Server
Étant donné qu’un utilisateur Windows peut appartenir à plusieurs groupes, il peut se voir accorder plusieurs fois le
droit de connexion au serveur SQL. Ceci peut poser un problème lorsqu’un utilisateur ou un groupe d’utilisateurs ne
doit jamais pouvoir se connecter au serveur SQL. Afin de remédier à ce souci, Microsoft fournit, parmi les ordres
Transact SQL pour la gestion des connexions, l’ordre DENY qui permet de refuser explicitement un utilisateur ou un
groupe Windows. Le DENY constitue un refus explicite et est prioritaire par rapport aux différentes autorisations de
connexion.

Création d’une connexion
Dans le schéma cidessus, il y a trois utilisateurs Windows et deux groupes. Une connexion a été mise en place pour le
groupe Acces2, le groupe Acces1 ne possède pas de connexion et l’utilisateur Jean est interdit de connexion.
Il faut posséder une permission d’administrateur (sysadmin) ou une permission de gestionnaire de sécurité
(securityadmin) pour pouvoir réaliser les différentes opérations relatives à la gestion des connexions.
Les connexions, qu’elles soient de type SQL Server ou bien Windows, doivent être définies au niveau de l’instance SQL
Server pour permettre aux utilisateurs de se connecter.
La gestion des connexions peut être réalisée de façon graphique par l’intermédiaire de l’explorateur d’objets depuis
SQL Server Management Studio ou bien sous forme de script Transact SQL. Toutes les opérations de gestion des
connexions sont réalisables en Transact SQL avec l’aide des instructions CREATE LOGIN, ALTER LOGIN et DROP LOGIN.
Chaque solution possède ses avantages et ses inconvénients.
Les procédures sp_addlogin et sp_grantlogin ne doivent plus être utilisées. Elles sont encore présentes dans
SQL Server 2008 pour assurer la compatibilité des scripts.
Les comptes de connexion sont nécessaires pour permettre l’accès au serveur de base de données. Toutefois, ils sont
insuffisants pour permettre de travailler sur une base de données. Il faut en effet leur associer une base de données
par défaut, c’estàdire la base de travail par défaut sur laquelle ils seront positionnés après ouverture de la
connexion. Pour accéder à cette base de données, un compte d’utilisateur de base de données doit être défini pour la
connexion sur la base de données.
a. En mode de sécurité Windows
Les noms des groupes ou des utilisateurs devront correspondre à ceux définis dans Windows.
Il est possible de créer les connexions depuis l’interface graphique de SQL Server Management Studio, en procédant
de la sorte :
● Depuis l’explorateur d’objets, se placer sur le nœ ud SécuritéConnexion.

● Depuis le menu contextuel associé au nœ ud connexion, faire le choix nouvelle connexion.
L’écran suivant apparaît alors. Il ne reste plus qu’à sélectionner le compte d’utilisateur Windows ou bien le groupe
qui est autorisé à se connecter.
L’interface graphique de SQL Server Management Studio permet également de modifier simplement un compte de
connexion à partir de la fenêtre des propriétés ou bien de supprimer une connexion.
Transact SQL
CREATE LOGIN nom_connexion

FROM WINDOWS
[WITH DEFAULT_DATABASE=baseDeDonnées|DEFAULT_LANGUAGE=langue]
nom_connexion
Nom de l’utilisateur ou du groupe Windows à ajouter. Il doit être donné sous la forme domaine\utilisateur.
baseDeDonnées
Précise la base de données qui sera utilisée par défaut. Si aucune base de données n’est précisée, alors la base de
données par défaut est la base Master.
langue
Langue de travail par défaut pour cette connexion. Cette option n’est à préciser que si la langue relative à cette
connexion est distincte de celle définie par défaut sur le serveur SQL.
Exemple :

b. En mode de sécurité Mixte
Comme pour la sécurité en mode Windows, il existe deux moyens pour gérer les connexions.
Mis à part l’ensemble des règles de gestion des mots de passe, la gestion d’une connexion en mode de sécurité SQL
Server est en tout point semblable à celui d’une connexion en mode de sécurité Windows.
Une fois créés, les deux types de connexion sont en tout point identiques. Il n’y a pas une solution qui présente plus
de fonctionnalités que l’autre.
Pour les connexions utilisant une sécurité SQL Server, il est possible de définir des règles de gestion des mots de
passe.
Pour les connexions utilisant une sécurité Windows, c’est le système d’exploitation qui gère les règles de sécurité
relatives au mot de passe.
Il est possible de créer les connexions depuis l’interface graphique de SQL Server Management Studio, en procédant
de la sorte :
● Depuis l’explorateur d’objets, se placer sur le nœ ud SécuritéConnexion.
● Depuis le menu contextuel associé au nœ ud de connexion, faire le choix nouvelle connexion.
L’écran suivant apparaît alors. Il ne reste plus qu’à définir le nom de la nouvelle connexion ainsi que le mot de passe
associé. C’est également à ce niveau que peut être précisée la politique de gestion des passes à mettre en place.
Les règles de gestion des mots de passe sont héritées de celles mise en place sur Windows.

L’interface graphique de SQL Server Management Studio permet également de modifier simplement un compte de
connexion à partir de la fenêtre des propriétés ou bien de supprimer une connexion.
Transact SQL
CREATE LOGIN nom_connexion

WITH {PASSWORD=’motDePasse’ |motDePasseHaché HASHED}[MUST_CHANGED]
[,SID=sid |
,DEFAULT_DATABASE=baseDeDonnées |
,DEFAULT_LANGUAGE=langue |
,CHECK_EXPIRATION={ON | OFF} |
,CHECK_POLICY={ON | OFF}
,[CREDENTIAL=nom_credit]]
nom_connexion
Nom de la connexion qui sera définie dans SQL Server.
motDepasse
Mot de passe associé à la connexion. Ce mot de passe est stocké de façon cryptée dans la base Master et il est
vérifié lors de chaque nouvelle connexion au serveur. Il est obligatoire de définir un mot de passe pour chaque
connexion.
motDePasseHaché
Il s’agit ici de préciser que la chaîne fournie correspond à la version hachée du mot de passe. Ce n’est donc pas le
mot de passe tel que l’utilisateur le saisit, mais le mot de passe tel que SQL le stocke qui est fourni.
MUST_CHANGED

Avec cette option SQL Server demande à l’utilisateur de saisir un nouveau mot de passe lors de sa première
connexion au serveur. Cette option n’est possible que si CHECK_ESPIRATION et CHECK_POLICY sont activées
(positionnées à ON).
baseDeDonnées
Précise la base de données qui sera utilisée par défaut. Si aucune base de données n’est précisée alors la base de
données par défaut est la base Master.
langue
Langue de travail par défaut pour cette connexion. Cette option n’est à préciser que si la langue relative à cette
connexion est distincte de celle définie par défaut sur le serveur SQL.
CHECK_EXPIRATION
Si cette option est positionnée à ON (OFF par défaut), elle indique que le compte de connexion va suivre la règle
relative à l’expiration des mots de passe définie sur le serveur SQL. L’activation de cette option n’est possible que si
CHECK_POLICY est également activée.
CHECK_POLICY
Activée par défaut, cette option permet de répercuter au niveau de SQL Server les règles de gestion des mots de
passe définies au niveau de Windows sur le poste qui héberge l’instance SQL Server.
CREDENTIAL
Permet de relier la connexion à un credential créé précédemment par l’intermédiaire de l’instruction CREATE
CREDENTIAL.
Exemple
Dans l’exemple suivant, la connexion PIERRE est créée avec le mot de passe secret. L’utilisateur ne devra pas changer son
mot de passe et sa base de données par défaut est configurée.
En utilisant un certificat
SQL Server donne la possibilité de créer des connexions au serveur basées sur des certificats (CERTIFICATE). Ces
certificats permettent d’identifier de façon sûre un utilisateur en se basant sur différentes informations telles que :
● une clé publique ;

● une identification telle que le nom et l’adresse email ;
● une période de validité.
Pour être tout à fait précis, les certificats de SQL Server sont conformes au standard X.509.
La création d’un certificat dans SQL Server peut s’appuyer sur un certificat défini dans un fichier ou un assembly ou
bien demander à SQL Server de générer les clés publiques et privées.
Les certificats de sécurité vont permettre à des applications et/ou des services, d’ouvrir une session sécurisée sur le
serveur. Ce type d’ouverture de session par un service est utilisé par le service Service Broker (détaillé chapitre
Service Broker de cet ouvrage) qui utilise un certificat pour poster un message sur une base distante.
6. Informations d’identification
Ces objets permettent à des connexions en mode de sécurité SQL Server d’accéder à des ressources externes au
serveur de base de données. Les informations d’identification (credentials) vont donc contenir un nom de compte
Windows et un mot de passe. Les connexions SQL Server sont reliées à un credential par l’intermédiaire de
l’instruction CREATE LOGIN ou bien ALTER LOGIN.
La modification et la suppression sont possibles par l’intermédiaire des instructions ALTER CREDENTIAL et DROP
CREDENTIAL.
Syntaxe
CREATE CREDENTIAL nomDuCredit

WITH IDENTITY = ’identité’ [, SECRET = ’secret’];
nomDuCredit
Permet d’identifier le credential de façon unique au niveau du serveur. Cet identifiant ne peut pas commencer par le
caractère #. Les credentials systèmes commencent toujours par les caractères ##.
identité
Nom du compte Windows qui sera associé au credential et permettra l’accès à des ressources en dehors de SQL
Server.
secret
Optionnel, ce paramètre permet de spécifier un mot de passe pour pouvoir accéder à des ressources externes.
Exemple
Un credential est créé et il correspond au compte d’utilisateur Antoine défini au niveau de Windows.

Il est possible d’avoir toutes les informations relatives aux credentials déjà définis sur le serveur en
interrogeant la vue sys.credential.
La gestion d’un credential de façon graphique est possible en procédant de la façon suivante :
● Depuis l’explorateur d’objets, se positionner sur le nœ ud Securité Informations d’identification.
● Depuis le menu contextuel associé au nœ ud Informations d’identification, demander la création d’un

credential en choisissant l’option Nouvelles informations d’identification...
Exemple
Fenêtre de création d’un nouveau credential

7. Activer et désactiver une connexion
Sur une connexion définie, il est possible de la désactiver afin de désactiver temporairement son utilisation. Si toutes
les informations et propriétés de la connexion sont conservées, il n’est pas possible d’utiliser la connexion désactivée
pour se connecter à SQL Server. La désactivation de connexion est utile pour renforcer la sécurité sur des comptes de
connexion qui, bien que définis, ne sont pas utilisés ou bien lorsque l’administrateur définit au préalable des
connexions. Il ne lui restera plus qu’à activer la ou les connexions lorsque le besoin sera présent.
Depuis la fenêtre des propriétés de la connexion sur la page Etat, il est possible d’activer, de désactiver la connexion.

Transact SQL
L’activation et la désactivation d’une connexion s’effectuent par l’intermédiaire de l’instruction ALTER LOGIN.
Syntaxe
ALTER LOGIN nomConnexion {ENABLE|DISABLE}[;]
Exemple
La connexion Pierre est désactivée.

Gestion des utilisateurs de base de données
Après la définition des connexions (login) au niveau du serveur, il est nécessaire de définir des utilisateurs dans les
différentes bases de données.
C’est au niveau des utilisateurs de base de données que seront attribués les droits d’utilisation des objets définis
dans la base de données. Lors de la définition d’une connexion, la base de données par défaut permet de positionner
le compte de connexion sur une base de données pour commencer à travailler. Cependant, la connexion ne pourra
réellement travailler sur la base que s’il existe un compte d’utilisateur défini au niveau base et associé à la connexion.
C’est un point de passage obligatoire, sauf si la connexion s’est vue attribuée des privilèges de haut niveau.
Si aucune base de données par défaut n’est définie au niveau de la connexion, alors c’est la base Master qui
est considérée comme base par défaut, ce qui n’est pas un bon choix.
Les utilisateurs de base de données sont associés à une connexion au niveau du serveur. Cependant, certains
utilisateurs tels que guest, sys et INFORMATION_SCHEMA ne sont mappés à aucune connexion.
Si un utilisateur dispose d’une connexion à SQL Server mais s’il n’existe pas d’utilisateur de base de données lui
permettant d’intervenir sur les bases, l’utilisateur ne peut réaliser que quelques opérations très limitées :
● sélectionner les informations contenues dans les tables système et exécuter certaines procédures stockées,
● accéder à toutes les bases de données utilisateur munies d’un compte d’utilisateur guest,
● exécuter les instructions qui ne nécessitent pas d’autorisation telles que la fonction PRINT.
Il existe deux types de droits : les droits d’utilisation des objets définis dans une base de données et les droits
d’exécuter des instructions SQL qui vont rajouter de nouveaux objets à l’intérieur de la base.
Les utilisateurs de base de données correspondent à une connexion. Ce sont les utilisateurs de base de données qui
reçoivent les différents droits qui permettent d’utiliser les bases.
Pour être capable de gérer les accès à la base, il faut posséder des droits de propriétaire de base (db_owner) ou de
gestionnaire des accès (db_accessadmin).
Les utilisateurs de base de données sont stockés dans la table système sysusers de la base de données sur
laquelle l’utilisateur est défini.
Á sa création un utilisateur de base de données ne dispose d’aucun privilège. Il est nécessaire d’accorder tous
les droits dont l’utilisateur a besoin.
L’utilisateur guest (invité) est un utilisateur particulier qui peut être défini sur les bases de données utilisateur. Ce nom
d’utilisateur sera utilisé par les connexions au serveur qui ne sont pas mappées avec un utilisateur de base de
données. La gestion de cet utilisateur est la même que celle d’un utilisateur quelconque de la base de données.
1. Création
La création d’un utilisateur de base de données va permettre de lier une connexion avec un utilisateur, et donc
autoriser l’utilisation de cette base.
Pour créer un utilisateur de base de données, il faut se positionner sur la base de données concernée par l’ajout
depuis l’explorateur d’objets et réaliser la manipulation suivante :
● Développer le nœ ud Sécurité et se positionner sur le nœ ud Utilisateurs.
● Depuis le menu contextuel associé au nœ ud Utilisateurs, sélectionner Nouvel utilisateur.
● Sélectionner la connexion associée à l’utilisateur, puis définir le nom de ce dernier.

● Enfin, il est possible de préciser les rôles de base de données accordés à cet utilisateur.
Dans l’exemple précédent, l’utilisateur Adrien est créé dans la base de données GESCOM. Cet utilisateur est mappé à
la connexion Adrien.
Transact SQL
C’est par l’intermédiaire de l’instruction CREATE USER qu’il est possible de définir des comptes utilisateurs au niveau
de la base de données.
Syntaxe
CREATE USER nomUtilisateur

[ FOR {LOGIN nomConnexion |
CERTIFICATE nomCertificat|
ASYMMETRIC KEY nomCléAsymétrique}]
[ WITH DEFAULT_SCHEMA = nomSchema ]
nomUtilisateur
Nom du nouvel utilisateur de base de données.
nomConnexion
Nom de la connexion à laquelle l’utilisateur de Base de données est associé. Si aucun nom de connexion n’est
précisé, alors SQL Server résout le problème de la façon suivante :
● 1 : SQL Server tente d’associer le compte d’utilisateur de base de données à une connexion qui porte le
même nom.

● 2 : si l’étape précédente échoue, si le nom d’utilisateur est guest et s’il n’existe pas encore de compte de
guest sur la base de données, alors le compte d’utilisateur guest (invité) est créé.
● 3 : dans tous les autres cas l’instruction échoue.
nomCertificat
Nom du certificat à associer à l’utilisateur de base de données.
nomCléAsymétrique
Nom de la clé asymétrique associée à l’utilisateur de base de données.
nomSchema
Nom du schéma associé à cet utilisateur de base de données. Il est possible d’associer plusieurs utilisateurs au
même schéma.
Exemple
Les procédures sp_grantdbaccess et sp_adduser sont maintenues dans SQL Server uniquement pour des
raisons de compatibilité. Il est recommandé de ne plus l’utiliser.
2. Information
Pour obtenir l’ensemble des informations relatives à un utilisateur de base de données, il faut procéder de la façon
suivante :
● Depuis l’explorateur d’objets, se positionner sur la base de données.
● Développer les nœ uds Sécurité Utilisateurs.
● Se positionner sur l’utilisateur pour lequel on souhaite obtenir les informations et demander l’affichage des
propriétés à partir du menu contextuel associé.

Transact SQL
Il est possible d’obtenir l’ensemble des informations relatives aux utilisateurs de base de données en interrogeant la
vue sys.database_principals.
La procédure stockée sp_helpuser est maintenue pour des raisons de compatibilité mais il faut lui préférer la
vue sys.database_principals.

La procédure sp_who permet de connaître les utilisateurs actuellement connectés et les processus en cours.
Pour chaque connexion, la procédure sp_who permet, entre autres, de connaître :
● le nom de connexion utilisé (loginame) ;
● le nom de l’ordinateur à partir duquel la connexion est établie (hostname) ;
● le nom de la base de données courante (dbname).
3. Modification
Il est possible de modifier un utilisateur de base de données afin de modifier son nom ou bien le schéma associé à
cet utilisateur.
Il faut se positionner depuis l’explorateur d’objets sur la base de données concernée par la modification du compte
d’utilisateur et réaliser les manipulations suivantes :
● Développer le nœ ud Sécurité puis Utilisateurs.
● Se positionner sur le compte d’utilisateur à modifier.
● Afficher la boîte de propriétés depuis l’option Propriétés disponible dans le menu contextuel associé à
l’utilisateur.

Transact SQL
L’instruction ALTER USER permet de réaliser cette opération.
Syntaxe:
ALTER USER nomUtilisateur

WITH NAME=nouveauNomUtilisateur,
DEFAULT_SCHEMA = nomNouveauSchema
Exemple

4. Suppression
Compte tenu que les utilisateurs ne possèdent pas d’objets, leur suppression est toujours possible et sans aucun
risque de perte de données. La suppression d’un utilisateur n’entraîne pas la suppression du schéma associé à
l’utilisateur.
Il faut se positionner depuis l’explorateur d’objets sur la base de données concernée par la suppression du compte
d’utilisateur et réaliser les manipulations suivantes :
● Développer le nœ ud Sécurité puis Utilisateurs.
● Se positionner sur le compte d’utilisateur à supprimer.
● Sélectionner le choix Supprimer depuis le menu contextuel associé au compte d’utilisateur.
La suppression n’est pas possible sur les comptes d’utilisateur prédéfinis à savoir : dbo, guest,
INFORMATION_SCHEMA et sys.

Transact SQL
L’instruction DROP USER permet de réaliser cette opération.
Les procédures sp_dropuser et sp_revokedbaccess sont maintenues dans SQL Server uniquement pour
des raisons de compatibilité.
Syntaxe
DROP USER nomUtilisateur
Exemple:

Gestion des schémas
L’objectif des schémas est de dissocier les utilisateurs de base de données des objets qu’ils vont être amenés à créer.
Toutefois, les objets ne sont pas laissés tels quels, ils sont regroupés logiquement en schéma. Il est ainsi possible de
définir un schéma comme un ensemble logique d’objets à l’intérieur d’une base de données.
Les schémas facilitent le partage d’information entre plusieurs utilisateurs sans pour autant perdre au niveau de la
sécurité. Par exemple, si plusieurs développeurs travaillent ensemble sur un même projet, ils vont tous se connecter en
utilisant leur propre connexion et utilisateur de base de données, ce qui ne les empêche pas de travailler sur le même
schéma et de partager ainsi les tables, vues, procédures, fonctions... qui sont définies sur la base dans le cadre du
projet.
Les schémas permettent une gestion plus aisée des privilèges d’utilisation des objets.
Le schéma est associé à un utilisateur de base de données lors de la création ou de la modification de l’utilisateur de la
base de données. Si aucun nom de schéma n’est précisé, alors l’utilisateur de base de données va travailler par défaut
sur le schéma dbo.
Pour accéder à des objets situés en dehors de son schéma par défaut, un utilisateur de base de données doit utiliser
le nom complet d’un objet c’estàdire nomSchema.nomObjet. Lors de l’utilisation d’un nom court (simplement le nom de
l’objet sans le préfixer par le nom du schéma), SQL Server recherche l’existence de l’objet uniquement dans le schéma
courant de l’utilisateur.
1. Création
a. SQL Server Management Studio
Pour créer un schéma de base de données, il faut se positionner sur la base de données concernée par l’ajout et
depuis l’explorateur d’objets réaliser la manipulation suivante :
● Développer le nœ ud Sécurité et se positionner sur le nœ ud Schémas.
● Depuis le menu contextuel associé au nœ ud Schémas, sélectionner Nouveau schéma.

b. Transact SQL
CREATE SCHEMA nomSchema

AUTHORIZATION nomPropriétaire|
[defitionDesTables |
definitionDesVues |
gestionDePrivilèges]
Plus simplement, il est possible de dire qu’un schéma est caractérisé par son nom. L’option AUTHORIZATION permet
de définir l’utilisateur de base de données qui est propriétaire du schéma. Un même utilisateur de base de données
peut être le propriétaire de plusieurs schémas. Le propriétaire d’un schéma ne doit pas nécessairement avoir
comme schéma par défaut un schéma dont il est propriétaire. Il est également possible de créer les tables et les
vues d’un schéma dès la construction du schéma.
Exemple
Dans l’exemple suivant, le schéma RI est créé.

Dans ce second exemple, le schéma livre est défini ainsi que des tables et des vues spécifique à ce schéma.
CREATE SCHEMA livre AUTHORIZATION dbo

CREATE TABLE articles(reference nvarchar(8) constraint pk_articles
primary key, designation nvarchar(200), prixht money, tva numeric(4,2))
CREATE VIEW catalogue AS select reference, designation, prixht,
tva ttc=prix*(1+tva)/100 FROM articles;
2. Modification
La modification d’un schéma consiste à modifier les objets contenus dans ce schéma. Lorsqu’un objet est transféré
d’un schéma à un autre, les autorisations relatives à cet objet sont perdues. Le transfert d’un objet entre deux
schémas est possible à l’intérieur d’une même base de données.
Pour modifier un schéma de base de données, il faut se positionner sur la base de données concernée par la
modification et depuis l’explorateur d’objets réaliser la manipulation suivante :
● Développer le nœ ud Sécurité et se positionner sur le nœ ud Schémas.
● Se positionner sur le schéma à modifier.
● Afficher la boîte de propriétés depuis l’option Propriétés disponible dans le menu contextuel associé au
schéma.

b. Transact SQL
ALTER SCHEMA nomSchema TRANSFER nomObjet
nomObjet
Représente le nom de l’objet qui va être transféré dans le schéma courant. Le nom de cet objet est au format
suivant nomSchema.nomCourtObjet.
Exemple
Dans l’exemple suivant, la tabe catégories présente dans le schéma dbo est transférée vers le schéma livre.

3. Suppression
La suppression d’un schéma est possible pour les schémas qui ne contiennent pas d’objet. Par exemple, si le schéma
contient des tables ou des vues, il est nécessaire de supprimer ou de transférer vers un autre schéma l’ensemble des
tables et des vues avant de pouvoir supprimer le schéma courant.
Pour supprimer un schéma de base de données, il faut se positionner sur la base de données concernée par la
suppression et depuis l’explorateur d’objets réaliser la manipulation suivante :
● Développer le nœ ud Sécurité et se positionner sur le nœ ud Schéma.
● Se positionner sur le schéma à supprimer.
● Sélectionner le choix Supprimer depuis le menu contextuel associé au schéma.

b. Transact SQL
DROP SCHEMA nomSchema
Exemple

Gestion des droits
Tous les utilisateurs de base de données, y compris guest, appartiennent au groupe public. Les droits qui vont être
détaillés cidessous peuvent bien sûr être accordés directement à public.
Les droits sont organisés de façon hiérarchique par rapport aux éléments sécurisables du serveur.
Il est possible de gérer l’attribution de privilèges au niveau du serveur, de la base de données, du schéma ou bien
directement de l’objet. Ainsi, les privilèges peuvent être accordés soit à un utilisateur de base de données, soit à une
connexion.
SQL Server gère les privilèges avec trois types de mots clés :
● GRANT
● REVOKE
● DENY
C’estàdire qu’un privilège peut être accordé (GRANT) ou bien retiré (REVOKE) s’il a été accordé. L’instruction DENY
permet d’interdire l’utilisation d’un privilège particulier même si le privilège en question a été accordé soit directement,
soit par l’intermédiaire d’un rôle.

1. Droits d’utilisation d’instructions
Les droits d’utilisation des instructions SQL pour créer de nouveaux objets au sein de la base sont des autorisations
pour réaliser l’exécution de certains ordres SQL. Un utilisateur qui dispose de tels droits est capable par exemple de
créer ses propres tables, ses procédures... L’accord de ces droits peut être dangereux et comme pour tous les droits,
doivent être accordés uniquement lorsque cela est nécessaire.
Les droits principaux d’instructions disponibles sont :
● CREATE DATABASE
● CREATE PROCEDURE
● CREATE FUNCTION
● CREATE TABLE
● BACKUP DATABASE
● CREATE VIEW
● BACKUP LOG
a. Autoriser
Ces droits sont administrés au niveau de la base de données par l’intermédiaire de la fenêtre des propriétés.
Exemple
Le privilège CREATE TABLE est accordé à l’utilisateur de base de données Adrien par l’intermédiaire de la boîte de propriétés
de la base GESCOM.

Transact SQL
L’accord de privilèges s’effectue en utilisant l’instruction GRANT dont la syntaxe est détaillée cidessous.
GRANT permission [,...]

TO utilisateur[,...]
[ WITH GRANT OPTION ]
permission
Nom de la ou des permissions concernées par cette autorisation. Il est également possible d’utiliser le mot clé ALL à
la place de citer explicitement la ou les permissions accordées. Toutefois ce terme ALL ne permet pas d’accorder des
privilèges d’exécution de toutes les instructions mais simplement sur les instructions pour créer des bases de
données, des tables, des procédures, des fonctions, des tables vues ainsi que d’effectuer des sauvegardes de la
base et du journal.
utilisateur
Nom de l’utilisateur ou des utilisateurs de base de données qui reçoivent les permissions.
WITH GRANT OPTION
Si la permission est reçue avec ce privilège, alors l’utilisateur peut accorder la permission à d’autres utilisateurs de
base de données.
Exemple
Dans l’exemple suivant, le privilège CREATE VIEW est accordé à l’utilisateur de base de données Adrien.

b. Retirer
Il est possible de retirer un privilège qui a été accordé à une entité de sécurité. Si le privilège n’a pas été accordé à
l’entité de sécurité, l’instruction est sans effet.
La gestion des privilèges s’effectue au niveau des propriétés de la base de données.
Exemple
La permission CREATE TABLE est retirée à l’utilisateur ADRIEN.

Transact SQL
REVOKE [GRANT OPTION FOR]

permission [,...]
FROM utilisateur [,...]
[CASCADE]
GRANT OPTION FOR
Si la permission a été accordée avec le privilège d’administration GRANT OPTION, il est possible par l’intermédiaire de
cette option de retirer simplement le paramètre d’administration.
permission
Liste des permissions à retirer.
utilisateur
Liste des utilisateurs concernés par cette suppression.
CASCADE
Si la permission retirée a été accordée avec le privilège d’administration WITH GRANT OPTION, l’option CASCADE
permet de retirer le privilège aux utilisateurs qui l’ont reçu par l’intermédiaire de l’utilisateur qui est concerné par la
suppression initiale de privilège.
Exemple
Exemple
Le privilège CREATE VIEW est retiré à l’utilisateur Adrien.

c. Interdire
L’instruction DENY permet d’interdire à un utilisateur l’utilisation d’un privilège, même s’il en reçoit la permission soit
directement, soit par son appartenance à un groupe.
Comme pour l’accord et la suppression, ce type de privilège est géré de façon centralisée au niveau des propriétés
Exemple
Par l’intermédiaire des propriétés de la base de données, l’utilisateur Adrien se voit interdire le fait de créer une table.

Transact SQL
DENY permission [,...]

TO utilisateur [,...]
[CASCADE]
Exemple
L’utilisateur Adrien se voit interdire la possibilité de créer des vues.

2. Droits d’utilisation des objets
Ces droits permettent de fixer quelles opérations (lecture, modification, ajout ou suppression) l’utilisateur peut réaliser
sur des données contenues dans une table, ou bien donner le droit d’exécution d’une procédure stockée. Ces droits
sont en général gérés par le propriétaire de l’objet.
En ce qui concerne le droit de lecture des données contenues dans une table (utilisation de l’instruction SELECT), il est
possible de préciser quelles colonnes l’utilisateur peut visualiser. Par défaut, il s’agit de toutes les colonnes.
Les principaux droits d’utilisation des objets concernant les tables, vues, procédures stockées correspondent aux
ordres :
● INSERT
● UPDATE
● DELETE
● SELECT
● EXECUTE : qui ne s’utilise que pour les procédures stockées.
Les instructions SELECT et UPDATE peuvent être limitées à certaines colonnes de la table ou de la vue. Il est
cependant préférable de ne pas trop explorer cette possibilité car il en résulte un plus grand travail administratif au
niveau de la gestion des droits. Il est préférable de passer par une vue ou bien une procédure stockée pour limiter
l’usage de la table.
Principe de fonctionnement des autorisations
a. Autoriser
Les privilèges d’utilisation des objets peuvent être gérés à deux niveaux dans SQL Server Management Studio :
● au niveau utilisateur, ce qui permet de connaître les possibilités de travail que possède chaque utilisateur.

● au niveau des objets, afin de connaître quels sont les utilisateurs qui peuvent utiliser l’objet en question et
comment ils peuvent l’utiliser.
Dans chacun des deux cas, les autorisations sont gérées par l’intermédiaire de la fenêtre des propriétés.
Exemple
Dans l’exemple suivant, l’utilisateur Adrien se voit accorder la possibilité d’exécuter les instructions INSERT, UPDATE et
SELECT sur la table des CLIENTS du schéma dbo.
Transact SQL
GRANT {ALL [PRIVILEGES]|permission[(colonne,[,...])] [,...]}

ON objet[,...]
[WITH GRANT OPTION ]
ALL
Permet d’accorder tous les privilèges d’utilisation de l’objet. Les privilèges accordés sont toujours fonction du type de
l’objet concerné par cet accord de privilège.
PRIVILEGES
Le mot clé a été ajouté pour le respect de la norme ANSI92. Il n’apporte aucune modification quant à l’utilisation du
mot clé ALL.
permission
Permet de spécifier la ou les opérations qui seront accordées aux utilisateurs.

objet
Correspond au nom complet de l’objet ou des objets sur lesquels porte l’accord de privilège d’utilisation.
utilisateur
Correspond à l’utilisateur, ou plus exactement à l’entité de sécurité qui va pouvoir bénéficier du ou des privilèges.
WITH GRANT OPTION
Le privilège est accordé avec une option d’administration qui autorise le bénéficiaire du privilège à accorder ce même
privilège à d’autres utilisateurs de la base de données.
Exemple
Dans l’exemple cidessous, l’utilisateur Adrien reçoit tous les privilèges d’utilisation sur la table des commandes ainsi que
la possibilité de mener des requêtes d’interrogation sur la table des articles.
b. Retirer
Lorsqu’une permission a été accordée, il est possible de retirer cet accord. Il n’est pas possible de retirer l’utilisation
d’une permission à une entité de sécurité si cette permission n’a pas été accordée à cette même entité de sécurité.
C’est par l’intermédiaire de la fenêtre des propriétés de l’entité de sécurité ou bien de l’objet, qu’il est possible de
retirer une permission qui a été accordée précédemment.
Exemple
À partir des propriétés de la table dbo.CLIENTS, l’utilisateur ADRIEN se voit retirer la possibilité d’effectuer des requêtes de
type UPDATE sur cette table.

Transact SQL
REVOKE [GRANT OPTION FOR ]

{ALL [PRIVILEGES]|permission[(colonne,[,...])] [,...]}
ON object [(colonne [,...])]
{FROM | TO} utilisateur [,...]
[ CASCADE ]
GRANT OPTION FOR
Avec cette option, il est possible de retirer simplement le privilège d’administration du privilège.
permission
Permet de préciser la ou les permissions concernées par le retrait. Comme pour l’accord, il est possible de préciser
les colonnes concernées par le retrait, mais la gestion d’un tel niveau de droit est lourde.
objet
Il faut préciser le nom complet de l’objet au sein de la base de données, c’estàdire nomSchema.nomObjet.
FROM, TO
Ces deux termes sont synonymes. L’usage habituel consiste à utiliser TO lors de l’accord d’un privilège et FROM lors
du retrait d’un privilège.
utilisateur
Il s’agit très exactement de l’entité de sécurité à qui le privilège est retiré. Cette entité de sécurité est le plus
souvent un utilisateur, mais il peut s’agir d’un rôle par exemple.

CASCADE
Lors du retrait d’une permission accordée avec le privilège d’administration, cette option permet de cascader le
retrait, c’estàdire d’effectuer le retrait de la permission à toutes les entités de sécurité qui l’ont reçue de la part de
celle qui est concernée initialement par le retrait.
Exemple
Dans l’exemple suivant, l’utilisateur Adrien se voit retirer la possibilité de supprimer des COMMANDES.
c. Interdire
L’interdiction d’utiliser une permission d’utilisation d’un objet est une instruction plus forte que la suppression car elle
peut être appliquée à une entité de sécurité, même si cette dernière n’a pas encore reçu de privilège d’utilisation de
l’objet de façon directe ou non.
Comme pour l’ajout ou bien le retrait, l’interdiction va être gérée par les fenêtres de propriétés, soit celle de l’entité
de sécurité, soit par celle de l’objet. Le choix d’une solution par rapport à l’autre dépend du type de vue que l’on
souhaite adopter et du type d’opération que l’on souhaite faire. Estce que l’on souhaite, par exemple, mieux
contrôler l’utilisation d’une table, ou bien les actions que peut mener un utilisateur de base de données ?
Exemple
Dans l’exemple suivant, l’utilisateur ADRIEN se voit interdire la possibilité de supprimer des informations sur la table
dbo.CLIENTS, par l’intermédiaire de la fenêtre de propriétés de la table.

Transact SQL
DENY {ALL [PRIVILEGES]|permission[(colonne,[,...])] [,...]}

ON object [(colonne [,...])]
[CASCADE]
colonne
L’interdiction au niveau colonne est sans effet sur une autorisation accordée au niveau de la table. Cette
inconsistance de sécurité est maintenue dans SQL Server 2005 pour des raisons de compatibilité antérieure.
CASCADE
L’interdiction est transmise aux entités de sécurité qui ont reçu la permission d’utiliser ce privilège par l’intermédiaire
de l’entité de sécurité à qui l’utilisation de ce privilège est interdite.
Exemple
Dans l’exemple suivant, l’utilisateur de base de données ADRIEN se voit interdire la possibilité de supprimer des
informations depuis la table dbo.COMMANDES.

3. Droits au niveau base de données
Les privilèges accordés au niveau base de données donnent la possibilité à l’utilisateur qui reçoit ce privilège de
réaliser des actions qui ont une portée sur l’ensemble de la base de données. Par exemple, le privilège ALTER ANY
USER permet à un utilisateur de créer, supprimer et modifier n’importe quel compte de la base de données.
Au niveau base de données, il est possible d’accorder des privilèges à un utilisateur mais également à un schéma, un
assembly et à un objet service broker.
La gestion de ces privilèges utilise soit les instructions Transact SQL GRANT, REVOKE et DENY, soit peut être effectuée
de façon graphique à partir des propriétés de la base de données.
Seules les méthodes pour accorder des privilèges sont illustrées ici, les opérations de suppression et
d’interdiction sont très semblables à celles illustrées lors des deux points précédents.
Les droits relatifs à l’utilisation peuvent être attribués de la façon suivante depuis SQL Server Management Studio :
● Depuis l’explorateur d’objets, développer le nœ ud représentant la base de données concernée par la

modification de privilège.
● Afficher les propriétés de la base en effectuant le choix Propriétés depuis le menu contextuel.

Il est également possible d’accorder ces permissions de façon graphique en allant modifier les propriétés des
utilisateurs de base de données.
Transact SQL
La même opération peut être réalisée en Transact SQL à l’aide de l’instruction GRANT.
GRANT permissionBaseDeDonnées [ ,... ]

TO utilisateur [ ,...n ]
[ WITH GRANT OPTION ]
[ AS { group | role } ]
permissionBaseDeDonnées
La ou les permissions de base de données accordées.
Utilisateur
Compte d’utilisateur de base de données qui reçoit le privilège.
AS {group|role}
Contexte de sécurité utilisé pour pouvoir accorder le privilège.
Exemple
Dans l’exemple suivant, le privilège CREATE PROCEDURE est accordé à l’utilisateur Pierre.

Les privilèges qu’il est possible d’accorder à ce niveau sont :
ALTER CREATE DATABASE
ALTER ANY APPLICATION ROLE CREATE DATABASE DDL EVENT NOTIFICATION
ALTER ANY ASSEMBLY CREATE DEFAULT
ALTER ANY ASYMMETRIC KEY CREATE FULLTEXT CATALOG
ALTER ANY CERTIFICATE CREATE FUNCTION
ALTER ANY CONTRACT CREATE MESSAGE TYPE
ALTER ANY DATABASE DDL TRIGGER CREATE PROCEDURE
ALTER ANY DATABASE EVENT NOTIFICATION CREATE QUEUE
ALTER ANY DATASPACE CREATE REMOTE SERVICE BINDING
ALTER ANY FULLTEXT CATALOG CREATE ROLE
ALTER ANY MESSAGE TYPE CREATE ROUTE
ALTER ANY REMOTE SERVICE BINDING CREATE RULE
ALTER ANY ROLE CREATE SCHEMA
ALTER ANY ROUTE CREATE SERVICE
ALTER ANY SCHEMA CREATE SYMMETRIC KEY
ALTER ANY SERVICE CREATE SYNONYM
ALTER ANY SYMMETRIC KEY CREATE TABLE
ALTER ANY USER CREATE TYPE

AUTHENTICATE CREATE VIEW
BACKUP DATABASE CREATE XML SCHEMA COLLECTION
BACKUP LOG DELETE
CHECKPOINT EXECUTE
CONNECT INSERT
CONNECT REPLICATION REFERENCES
CONTROL SELECT
CREATE AGGREGATE SHOWPLAN
CREATE ASSEMBLY SUBSCRIBE QUERY NOTIFICATIONS
CREATE ASYMMETRIC KEY TAKE OWNERSHIP
CREATE CERTIFICATE UPDATE
CREATE CONTRACT VIEW DATABASE STATE
VIEW DEFINITION
4. Droits au niveau du serveur
SQL Server permet d’attribuer des privilèges au niveau du serveur. Ces privilèges ne sont pas accordés à un
utilisateur de base de données mais à une connexion.
Comme pour les droits d’utilisation des objets et des instructions, il est possible d’accorder ces privilèges avec une
option d’administration. Ainsi, la connexion qui possède ce droit peut accorder ce même droit à une ou plusieurs autres
connexions.
Les différents droits qu’il est possible d’accorder au niveau serveur sont :
ADMINISTER BULK OPERATIONS CONNECT SQL
ALTER ANY CONNECTION CONTROL SERVER
ALTER ANY CREDENTIAL CREATE ANY DATABASE
ALTER ANY DATABASE CREATE DDL EVENT NOTIFICATION
ALTER ANY ENDPOINT CREATE ENDPOINT
ALTER ANY EVENT NOTIFICATION CREATE TRACE EVENT NOTIFICATION
ALTER ANY LINKED SERVER EXTERNAL ACCESS ASSEMBLY
ALTER ANY LOGIN SHUTDOWN
ALTER RESOURCES UNSAFE ASSEMBLY
ALTER SERVER STATE VIEW ANY DATABASE
ALTER SETTINGS VIEW ANY DEFINITION
ALTER TRACE VIEW SERVER STATE

AUTHENTICATE SERVER
Toutes les informations relatives aux privilèges accordés au niveau du serveur sont visibles au travers de la
vue sys.server_permissions.
Il est également possible d’attribuer des droits d’utilisation d’objets définis au niveau du serveur telles que les
terminaisons http ou http endpoint.
Pour pouvoir accorder de tels privilèges, il faut travailler sur la base Master.
5. Interroger les vues systèmes
Il est possible, en interrogeant les vues système du dictionnaire et plus exactement celles traitant de la sécurité, de
connaître les différentes autorisations et interdictions relatives aux différentes entités de sécurité.
Les principales vues sont :
● sys.database_permissions qui permet de lister les différentes autorisations d’utilisation des privilèges.
● sys.database_principals qui permet de lister les différents comptes de sécurité.
sys.database_principals
Cette vue recense toutes les entités de sécurité définies localement à la base de données. Les principales colonnes
de cette vue sont :
● name nom de l’entité de sécurité. Ce nom est unique à l’intérieur de la base de données.
● principal_id identifiant numérique qui permet d’identifier de façon unique une entité de sécurité dans la base
de données.
● type code relatif au type du contexte de sécurité : utilisateur SQL, utilisateur Windows, rôle, groupe
Windows...
● type_desc description en toute lettre pour comprendre le type mentionné à la colonne précédente.
● default_schema_name nom du schéma associé par défaut à l’entité de sécurité.
● create_date date de création de l’entité de sécurité.
● modify_date date de la dernière modification sur l’entité de sécurité.
● owning_principal_id identifiant du contexte de sécurité qui possède le compte en question. Tous, à

l’exception des rôles de base de données, doivent être possédés par dbo.
● sid ou Security Identifier. Ce champ est renseigné si l’entité de sécurité est liée à un external.
● is_fixed_role cet attribut est à 1 lorsque l’entité de sécurité est liée à un rôle fixe prédéfini sur le serveur.
Exemple
La requête suivante permet de connaître les comptes d’utilisateurs définis dans la base GESCOM.

sys.database_permissions
Cette vue permet d’obtenir l’ensemble des informations relatives aux différentes permissions accordées dans la base.
Il existe une ligne d’information pour chaque permission accordée à chaque entité de sécurité. Dans le cas de la
gestion des permissions au niveau de la colonne, il existe une ligne d’information pour chaque colonne concernée par
la permission.
Les principales colonnes de cette vue sont :
● class code relatif à la classification du privilège. Estce un privilège de niveau base, qui porte sur l’utilisation
d’un objet ou d’une colonne...
● class_desc description de la classification du privilège.
● major_id identifiant de l’objet sur lequel porte la permission.
● minor_id identifiant de la colonne sur laquelle porte la permission.
● grantee_principal_id identifiant du contexte de sécurité concerné par la permission.
● grantor_principal_id identifiant du contexte de sécurité à l’origine de la permission.
● type type du privilège.
● permission_name nom du privilège concerné par la permission.
● state code relatif à l’état de la permission.
● state_desc description de l’état actuel de la permission : GRANT, REVOKE, DENY ou bien

GRANT_WITH_GRANT_OPTION.
Exemple
À l’aide de la requête suivante, il est facile de connaître les permissions que possède l’utilisateur de base de données
ADRIEN.

Contexte d’exécution
Le contexte d’exécution correspond à l’ensemble des autorisations actives lors de l’exécution d’une requête, d’un script
Transact SQL, d’une procédure, d’une fonction ou d’un trigger. Par défaut, ce sont les privilèges accordés au contexte
de sécurité qui exécutent la requête, le script, la procédure, la fonction ou le trigger qui sont utilisés pour exécuter les
instructions sousjacentes. Ce mode de fonctionnement par défaut est, la plupart du temps, le plus adapté et il ne
convient pas de le changer. Toutefois, dans certains cas bien précis, il est nécessaire d’assurer la bonne exécution
quels que soient les privilèges accordés à l’utilisateur qui est à l’origine de l’exécution. Ce cas se produit par exemple,
lorsque personne ne reçoit le privilège d’ajouter (insert) des données dans une table et qu’au contraire une procédure
permet de réaliser ce travail. Dans ce cas, la clause EXECUTE AS permet de préciser le contexte d’exécution à utiliser.
Le contexte d’exécution ainsi défini peut correspondre à celui d’un utilisateur nommé expressément, à celui de
l’appelant (choix par défaut) ou bien à celui du propriétaire.
Syntaxe
CREATE PROCEDURE nomProcedure

WITH EXECUTE AS {CALLER|SELF|OWNER|’nomUtilisateur’}
AS corpsDeLaProcedure
CALLER
Le contexte d’exécution est celui de l’utilisateur qui appelle la procédure ou bien la fonction.
SELF
Le contexte d’exécution est celui du créateur de la procédure ou la fonction.
OWNER
Le contexte d’exécution de la procédure est celui du propriétaire de la procédure ou de la fonction.
’nomUtilisateur’
Le contexte d’exécution de la procédure est celui de l’utilisateur de base de données nommé.
Il est également possible de définir le contexte d’exécution sur les déclencheurs de base de données (DML et
DDL) ainsi que sur les queues.

Dans le cas d’un script, l’instruction EXECUTE AS permet de modifier le contexte d’exécution courant.

Les rôles
Les rôles sont des ensembles de permissions. Ces ensembles existent à trois niveaux distincts : serveur, base de
données et application. Les rôles permettent de regrouper les droits et de gérer plus facilement les différents
utilisateurs et les connexions. Il est en effet toujours préférable d’attribuer des droits à des rôles puis d’accorder les
rôles aux utilisateurs. Avec une telle structure, l’ajout et la modification de droits ou d’utilisateur sont beaucoup plus
simples.
Il est possible de définir un rôle comme un ensemble nommé de privilèges. Pour faciliter la gestion des droits, SQL
Server propose des rôles prédéfinis aussi appelés fixes car il n’est pas possible d’ajouter ou bien de supprimer des
privilèges dans ces rôles. Ces rôles fixes sont définis à deux niveaux :
● serveur
● base de données
En plus de ces rôles fixes, il est possible de gérer des rôles. Il convient alors de définir un nom unique pour définir un
rôle, puis d’accorder un ou plusieurs privilèges en respectant une procédure en tout point similaire à celle utilisée pour
accorder des permissions à des utilisateurs. Ces rôles peuvent être définis à deux niveaux :
● base de données
● application
Les rôles permettent une gestion simplifiée des privilèges puisqu’il est possible ainsi de définir des profils types de
privilèges, puis d’accorder à chaque utilisateur de base de données, un ou plusieurs profils de façon à lui fournir toutes
les autorisations dont il a besoin pour travailler sur la base.
L’utilisateur dispose au final de l’ensemble des privilèges qui sont accordés :
● directement à la connexion utilisée ;
● indirectement par l’intermédiaire d’un rôle fixe de serveur accordé à la connexion ;
● indirectement par l’intermédiaire des rôles accordés à l’utilisateur de base de données ;
● directement à l’utilisateur de base de données.
En complément de ces différents rôles, il existe le rôle public. Ce rôle est à part car tous les utilisateurs reçoivent le
rôle public et ils ne peuvent pas s’y soustraire. Ce rôle est également particulier car il est possible de lui accorder,
retirer ou bien interdire des permissions. Toutes modifications au niveau des permissions faites sur le rôle public sont
valables pour tous les utilisateurs. Il n’est donc pas recommandé de travailler avec ce rôle mais, dans certains cas, il

apporte une souplesse de gestion des permissions qui est intéressante.
1. Rôles de serveur
Ce sont des rôles prédéfinis qui donnent aux connexions un certain nombre de fonctionnalités. Il n’est pas possible
de définir des rôles de serveur, par contre leur utilisation facilite la gestion en cas de nombreux utilisateurs.
Les rôles de serveur sont au nombre de huit :
sysadmin
Exécute n’importe quelle opération sur le serveur, c’est l’administrateur du serveur.
serveradmin
Permet de configurer les paramètres au niveau du serveur.
setupadmin
Permet d’ajouter/supprimer des serveurs liés et d’exécuter certaines procédures stockées système telles que
sp_serveroptions.
securityadmin
Permet de gérer les connexions d’accès au serveur.
processadmin
Permet de gérer les traitements s’exécutant sur SQL Server.
dbcreator
Permet de créer et modifier les bases de données.
diskadmin
Permet de gérer les fichiers sur le disque.
bulkadmin
Peut exécuter l’instruction BULK INSERT pour une insertion des données par blocs. L’intérêt de ce type d’insertion
réside dans le fait que l’opération n’est pas journalisée et donc les temps d’insertion sont beaucoup plus rapides.
Seuls les membres du rôle sysadmin peuvent accorder un rôle de serveur à une connexion.
Le rôle public reçoit le privilège VIEW ANY DATABASE. Ainsi, les utilisateurs qui se connectent à SQL peuvent lister les
bases définies sur l’instance. Ils ne pourront y accéder que si un compte d’utilisateur de base de données est mappé
à leur connexion ou bien si l’utilisateur guest (invité) est défini au niveau de la base.
Les procéduressp_helpsrvrole et sp_helpsrvrolemenberpermettent d’obtenir toutes les informations nécessaires
sur les différents rôles fixes de serveur et leur attribution.

Exécution de sp_helpsrvrole pour connaître les rôles de serveurs fixes
La gestion des rôles fixes de serveur et plus exactement la gestion des connexions au sein du rôle est gérée depuis
la fenêtre des propriétés du rôle.

Transact SQL
C’est par l’intermédiaire de deux procédures stockées que s’effectuent toutes les opérations.
Ajouter un membre
Syntaxe :
sp_addsrvrolemember ’nom_connexion’, ’nom_rôle’
Exemple :
La connexion Pierre devient administrateur, c’estàdire membre du rôle de serveur sysadmin.
Retirer un membre
Syntaxe :
sp_dropsrvrolemember ’nom_connexion’, ’nom_rôle’
Exemple :

2. Rôles de base de données
Les rôles de bases de données permettent toujours de regrouper les différentes autorisations ou refus d’instructions
ou d’objets et ainsi de faciliter la gestion des droits. Il existe des rôles prédéfinis et il est possible de définir ses
propres rôles.
Les modifications sur les rôles sont dynamiques et les utilisateurs n’ont pas besoin de se déconnecter/reconnecter de
la base pour bénéficier des changements.
Les rôles prédéfinis ne peuvent pas être supprimés.
Seuls les membres des rôles fixes de base de données db_owner et db_securityadmin sont à même de gérer
l’appartenance des utilisateurs à un rôle fixe ou non de la base de données.
a. Le rôle public
Il s’agit d’un rôle prédéfini, bien particulier, car tous les utilisateurs de la base possèdent ce rôle. Ainsi, lorsque
qu’une autorisation d’instruction ou d’objet est accordée, supprimée ou interdite à public, instantanément tous les
utilisateurs de la base bénéficient des modifications.
Le rôle public contient toutes les autorisations par défaut dont bénéficient les utilisateurs de la base.
Il n’est pas possible d’attribuer des membres à ce rôle puisque tout le monde le possède implicitement. Ce rôle est
présent dans toutes les bases du serveur, aussi bien les bases système que les bases utilisateur.
À sa création, un utilisateur ne dispose d’aucune autorisation sauf celles accordées à public.
b. Les rôles prédéfinis

Mis à part le rôle public, il existe des rôles prédéfinis dans la base de données.
db_owner
Ensemble de droits équivalents au propriétaire de la base. Ce rôle contient toutes les activités possibles dans les
autres rôles de la base de données, ainsi que la possibilité d’exécuter certaines tâches de maintenance et de
configuration de la base. Tous les membres de ce groupe vont créer des objets dont le propriétaire est dbo. Il s’agit
du propriétaire par défaut de tous les objets et il n’est pas nécessaire de le préciser pour manipuler ses objets.
db_accessadmin
Permet d’ajouter ou de supprimer des utilisateurs dans la base de données. Ces utilisateurs correspondent à des
connexions SQL Server ou bien à des groupes ou utilisateurs Windows.
db_datareader
Permet de consulter (SELECT) le contenu de toutes les tables de la base de données.
db_datawriter
Permet d’ajouter (INSERT), modifier (UPDATE) ou supprimer (DELETE) des données dans toutes les tables utilisateur
db_ddladmin
Permet d’ajouter (CREATE), modifier (ALTER) ou supprimer (DELETE) des objets de la base de données.
db_securityadmin
Permet de gérer les rôles, les membres des rôles, et les autorisations sur les instructions et les objets de la base
de données.
db_backupoperator
Permet d’effectuer une sauvegarde de la base de données.
db_denydatareader
Interdit la visualisation des données de la base.
db_denydatawriter
Interdit la modification des données contenues dans la base.
Tous les rôles prédéfinis sont présents dans toutes les bases système.

c. Les rôles définis par les utilisateurs
Il est possible de définir ses propres rôles afin de faciliter l’administration des droits à l’intérieur de la base.
Le rôle SQL Server va être mis en place lorsque plusieurs utilisateurs Windows souhaitent effectuer les mêmes
opérations dans la base et qu’il n’existe pas de groupe Windows correspondant ou bien lorsque des utilisateurs
authentifiés par SQL Server et des utilisateurs authentifiés par Windows doivent partager les mêmes droits.
Pour les rôles définis au niveau base de données, il est possible de savoir quels utilisateurs en bénéficient, en
demandant l’affichage de la fenêtre des propriétés du rôle depuis SQL Server Management Studio.
Les rôles peuvent être accordés soit directement à un utilisateur, soit à un autre rôle. Cependant, l’imbrication
répétée des rôles peut nuire à la performance. De plus, il n’est pas possible de créer des rôles récursifs.
L’utilisation de rôles peut paraître parfois lourde lors de la création mais facilite grandement les évolutions
qui peuvent intervenir (modification des autorisations, des utilisateurs).
Pour définir un rôle il faut être membre du rôle sysadmin, ou bien membre de db_owner ou
db_securityadmin.
L’interrogation des tables système sys.database_principals et sys.database_role_member permet de connaître la

liste des utilisateurs qui appartiennent à chaque rôle de base de données. L’exemple suivant illustre ce propos :

Comme l’ensemble des opérations d’administration, il est possible de gérer les rôles de deux façons différentes :
La création des rôles de base de données est possible en réalisant les opérations suivantes :
● Depuis l’explorateur d’objets, se positionner sur la base de données utilisateur concernée par cet ajout.
● Se positionner sur le nœ ud Sécurité Rôles Rôles de base de données.
● Depuis le menu contextuel associé au nœ ud Rôles de base de données, faire le choix Nouveau rôle de
base de données.
Exemple
Dans l’écran suivant, le rôle RoleTest est créé.

C’est par l’intermédiaire de la fenêtre présentant les propriétés du rôle qu’il est possible de le modifier.
L’option de suppression est également disponible depuis le menu contextuel associé au rôle à supprimer.
Transact SQL
Création
Syntaxe :
CREATE ROLE nomRole

[ AUTHORIZATION propriétaire ]
nomRole
Nom du rôle qui vient d’être créé.
propriétaire
Il est possible de préciser un propriétaire pour le rôle.
Exemple :

Gestion des utilisateurs
La gestion des membres du rôle se réalise en utilisant la procédure stockée sp_addrolemember pour ajouter un
utilisateur.
Syntaxe :
sp_addrolemember ’nom_rôle’,
’compte_sécurité’
Nom_rôle
Nom du rôle auquel le compte d’utilisateur doit être ajouté.
Compte_sécurité
Nom d’un utilisateur de base de données ou bien d’un rôle SQL Server.
Exemple :

L’opération inverse s’effectue au moyen de la procédure sp_droprolemember.
Syntaxe :
sp_droprolemember ’nom_role’, ’compte_

sécurité’
Suppression
Syntaxe :
DROP ROLE nomRole
Exemple :
3. Rôles d’application

Les rôles d’application sont des rôles définis au niveau de la base de données sur laquelle ils portent. Comme tous
les rôles, les rôles d’application permettent de regrouper des autorisations d’objets et d’instructions. Cependant les
rôles d’application se distinguent car ils ne possèdent aucun utilisateur et ils sont protégés par un mot de passe.
La logique d’un rôle d’application est de permettre à tous les utilisateurs d’une application de posséder suffisamment
de droits pour le bon déroulement de l’application où les opérations qui peuvent être réalisées sur la base de
données sont contrôlées par le programme client. Cependant les utilisateurs euxmêmes ne disposent pas de
suffisamment de privilèges pour réaliser l’ensemble des opérations directement en SQL.
Lorsqu’un rôle d’application est activé depuis un applicatif client ou bien un script, les autorisations contenues dans
ce rôle prennent le pas sur toutes les autorisations accordées directement ou par l’intermédiaire de rôles à
l’utilisateur de la base de données.
Les rôles d’application permettent d’obtenir un comportement standard de l’application quel que soit l’utilisateur
Windows qui lance l’application.
Comme les rôles d’application sont définis au niveau base de données, il n’est pas possible de leur accorder des
privilèges sur d’autres bases. En effet, la connexion aux autres bases n’est possible que par l’intermédiaire du
compte guest.
Les rôles d’application sont gérés de façon similaire à celle des rôles de base de données.
● Depuis l’explorateur d’objets, se positionner sur la base de données utilisateur concernée par cet ajout.
● Se positionner sur le nœ ud Sécurité Rôles Rôles d’application.
● Depuis le menu contextuel associé au nœ ud Rôles d’application, faire le choix Nouveau rôle d’application.
Exemple
Le rôle d’application RoleTestAppli est créé.

C’est par l’intermédiaire des Propriétés du rôle qu’il est possible de modifier le mot de passe du rôle.
L’ajout de permission sur des instructions ou des objets se réalise avec les mêmes étapes que la gestion des droits
au niveau des utilisateurs.
La suppression d’un rôle de serveur se fait par l’intermédiaire du menu contextuel associé au rôle, en sélectionnant
le choix Supprimer.
b. Transact SQL
Créer un rôle d’application
Syntaxe
CREATE APPLICATION ROLE nomRoleApplication

WITH PASSWORD = ’motDePasse’
[, DEFAULT_SCHEMA = schéma ]
Exemple :

Supprimer un rôle d’application
Syntaxe
DROP APPLICATION ROLE nomRoleApplication
Exemple :
Modifier le rôle
L’instruction ALTER permet de modifier le mot de passe mais également le schéma par défaut et le nom du rôle.
ALTER APPLICATION ROLE nomRoleApplication

WITH {NAME = nouveauNom|
PASSWORD = ’nouveauMotDePasse’|
DEFAULT_SCHEMA = nouveauNomSchéma}

Exemple :
c. L’utilisation
L’activation d’un rôle d’application se fait au moyen de la procédure stockée sp_setapprole. Dès qu’un rôle de
serveur est activé, les droits de l’utilisateur sont ignorés et seules comptent les autorisations attribuées au rôle
d’application.
Syntaxe :
sp_setapprole ’rôle’,
[Encrypt N] ’mot-passe’
[, ’style_cryptage’]
rôle
Nom du rôle d’application qui va être activé.
mot_passe
L’activation d’un rôle d’application est conditionnée par le mot de passe. Le mot de passe peut être crypté par
l’intermédiaire de la fonction canonique ODBC Encrypt. L’option N permet de convertir le mot de passe au format
unicode.
style_cryptage
Permet de spécifier un style de cryptage pour le mot de passe. Deux styles sont disponibles :
none : Le mot de passe est transmis à SQL Server sans codage préalable. C’est l’option par défaut.
odbc : Le mot de passe est codé à l’aide de la fonction Encrypt d’ODBC. Cette fonctionnalité n’est possible que sur
un client ODBC communiquant avec le serveur OLE DB de SQL Server.
Exemple :

Introduction
SQL Server donne la possibilité d’automatiser les tâches administratives. Il n’est bien sûr pas possible d’automatiser
toutes les tâches mais les tâches planifiées représentent un bon complément à l’optimisation faite par défaut par SQL
Server. De plus, avec ces tâches prédéfinies, l’administrateur possède un rôle d’anticipateur, ce qui lui donne plus de
possibilités pour en tirer le meilleur tant au niveau des performances que de la fiabilité.
La gestion des tâches planifiées, des alertes et des opérateurs sont des services rendus par l’agent SQL Server. Ce
service doit être démarré afin que ces éléments soit gérés. L’agent SQL Server travaille avec l’Observateur des
événements pour la gestion des erreurs SQL Server, l’Analyseur de performances pour la gestion des alertes sur des
conditions de performances, et la base MSDB afin de connaître la réponse à appliquer face à une alerte, ou bien les
tâches planifiées à exécuter.
Principe de fonctionnement
Face à une alerte, l’agent peut réagir en exécutant un travail et/ou en prévenant un opérateur afin que ce dernier soit
au courant du problème qui vient de surgir. Bien entendu, l’exécution d’une tâche peut conduire au déclenchement de
nouvelles alertes et ainsi de suite.
D’autres tâches planifiées vont être exécutées par le service SQL Server Agent, non pas en réponse à une erreur mais
sur une base de temps. Par exemple, une reconstruction des index peut être planifiée une fois par semaine dans la
nuit du samedi au dimanche.
L’agent SQL Server permet de réaliser une administration préventive des problèmes qui peuvent se poser lors de
l’exploitation courante d’un serveur de bases de données.

Configuration des services
Comme l’exécution automatique de travaux administratifs repose sur le service SQL Server Agent, il est important que
ce dernier soit correctement configuré.
La configuration du service MSSQL Server a été abordée lors de l’installation.
Exceptionnellement, il est possible de démarrer ce service sous la forme d’application à l’aide de sqlagent90.exe.
1. Compte de démarrage pour SQL Server Agent
Le service SQL Server Agent s’exécute dans le contexte d’un compte d’utilisateur. Ce compte peut être Système
Local, Service Réseau ou bien un compte d’utilisateur (local ou sur le domaine). Les deux premiers cas correspondent
à des comptes prédéfinis qui permettent de faire un certain nombre d’actions. Si le service SQL Server Agent est
amené à accéder à des ressources disponibles sur le réseau, il est préférable qu’il s’exécute dans le contexte d’un
compte d’utilisateur du domaine. Ce choix est fixé initialement lors de l’installation, toutefois il est possible de le
modifier par la suite. Dans le cas de l’utilisation d’un compte d’utilisateur, aucun privilège n’est attribué directement à
l’utilisateur mais le groupe SQLServer AgentUser$nomOrdinateur$MSSQLServer (pour l’instance par défaut) est créé.
Ce groupe va se voir attribuer les privilèges suivants :
● Ouvrir une session en tant que service,
● Ouvrir une session en tant que programme de traitement de lots,
● Remplacer un jeton au niveau processus,
● Outrepasser le contrôle de parcours,
● Changer les quotas de mémoire d’un processus,
Le fait de passer par un groupe simplifie la gestion des privilèges lors d’un changement du compte utilisé.
Il est possible de configurer ce service à démarrage automatique. Cette option permet une plus grande
souplesse dans l’utilisation de l’agent SQL Server.
a. Configuration du service dans Windows
Pour configurer les services relatifs à MSSQLServer et SQL Server Agent, il est possible de passer par la console de
gestion des services de Windows. Cependant, il est préférable de configurer les services à s’exécuter dans le
contexte d’un compte d’utilisateur du domaine dès l’installation de SQL Server.

Après avoir sélectionné le service SQLSERVERAGENT, il faut appeler la boîte de dialogue affichant les propriétés du
service afin de pouvoir les connaître et les modifier. Les propriétés peuvent être affichées en utilisant l’icône dans la
barre d’outils, en passant par le menu Action Propriétés ou par le choix Propriétés dans le menu contextuel.

b. Configuration du service dans SQL Server Configuration Manager
Il est possible de gérer la configuration du service depuis SQL Server Configuration Manager. Cet utilitaire permet
de visualiser les seuls services de SQL Server.
Pour afficher et modifier les propriétés, il faut double cliquer sur le service ou bien sélectionner Propriétés dans le
menu contextuel associé au service.
Afin de faciliter la gestion des services, il est préférable que les services MSSQL Server et SQLServerAgent
s’exécutent dans le contexte du même compte d’utilisateur du domaine, mais cela n’est pas obligatoire. De
même, si plusieurs serveurs SQL doivent communiquer sur un ou plusieurs domaines, tous les services
s’exécuteront dans un compte d’utilisateur qui possède même nom et même mot de passe.
Il est également possible de connaître le statut du service (démarré ou non) depuis SQL Server Management
Studio. Il est possible d’y démarrer, d’arrêter ou bien de suspendre le service.

c. La sécurité de SQL Server Agent
Le service SQL Server Agent permet la gestion de nombreux éléments. Si le service doit posséder des droits élevés
sur le serveur pour être capable de réaliser correctement toutes les tâches qui lui sont assignées, l’utilisation de ce
service doit être contrôlé au plus juste. Ce contrôle est assuré par les trois rôles de base de données
SQLAgentUserRole, SQLAgentReaderRole etSQLAgentOperatorRole définis sur la base msdb. L’appartenance à
ces rôles n’est nécessaire que pour les utilisateurs nonmembres du rôle de serveur sysadmin.
Par exemple, si un utilisateur se connecte à la console graphique SQL Server Management Studio sans être membre
de l’un de ces trois rôles, alors l’outil ne présentera tout simplement pas le nœ ud relatif à SQL Server Agent. Ainsi,
l’utilisateur n’est pas capable de modifier, ni même de connaître le travail réalisé au niveau de l’automatisation de
tâches. Le même niveau de sécurité est défini au niveau Transact SQL.
En plus des rôles de base de données, le service dispose des soussystèmes et des proxies pour gérer au mieux
tous les éléments de sécurité.
Le soussystème permet de présenter la fonctionnalité disponible pour une étape de travail.
Un proxy pour SQL Server Agent permet de gérer la sécurité relative à plusieurs soussystèmes ainsi que les
connexions associées.
Ainsi, le propriétaire d’une étape de travail ne pourra préciser un proxy pour cette étape, si et seulement s’il
appartient à ce proxy.
2. La configuration de la messagerie
La gestion des mails avec SQL Server passe par le service de mail de base de données. Ce service permet une
meilleure gestion des mails au sein de l’entreprise car il offre à la fois plus de souplesse en terme de mise en œ uvre
et de performance mais aussi il garantit une sécurité plus importante que le service SQLMail présent dans les
versions antérieures de SQL Server.
SQLMail est maintenu dans SQL Server pour des raisons de compatibilité. Il ne faut pas l’utiliser pour de
nouveaux développements.
Le service de mail de base de données utilise le protocole standard SMTP pour envoyer les mails. Il ne repose pas sur
MAPI, ce qui rend facultatif l’installation d’un client de messagerie comme Outlook. Au travers de ce protocole, le
service de mail de base de données prend en charge l’envoi de mails au format HTML.
Le service des mails est exécuté dans un processus distinct de celui de SQL Server. Ainsi, si ce service est défaillant,
cela ne va pas perturber le bon fonctionnement de la base de données. Les mails iront se placer dans la file d’attente
du processus lié au service des mails de base de données.
Le service de messagerie de base de données n’est pas actif par défaut, aussi l’assistant de configuration se charge

de l’activer avant de le paramétrer. Cette activation est obligatoire pour le bon fonctionnement du service.
a. Configuration depuis SQL Management Studio
L’assistant de configuration de la messagerie de base de données va permettre de réaliser simplement et en étant

guidé l’une des actions suivantes :
● configurer la messagerie de base de données,
● gérer les comptes de la messagerie de base de données,
● gérer les profils de sécurité,
● gérer les paramètres système.
L’assistant est lancé depuis SQL Server Management Studio en sélectionnant Configurer la messagerie de base de
données dans le menu contextuel associé au nœ ud Gestion Messagerie de base de données de l’instance SQL
Server sur laquelle la configuration doit être faite.
Le premier écran de l’assistant (après l’écran d’accueil) permet de sélectionner l’action que l’on souhaite réaliser
avec l’assistant.
Dans le cas où le choix se porte sur la configuration du service, l’assistant se charge de démarrer le service.
Pour que le service de messagerie de base de données puisse fonctionner, il doit disposer d’un compte mail à
utiliser. Ce compte est défini au sein d’un profil. Les profils permettent de regrouper logiquement les différents
comptes de courriels.

Définition d’un premier profil
En utilisant le bouton Ajouter, il est possible de définir un ou plusieurs comptes de courrier.

Définition d’un compte mail
Par la suite, l’assistant propose simplement de rendre public le profil, c’estàdire accessible à l’ensemble des
utilisateurs du serveur. Enfin, l’assistant se termine par un écran de synthèse qui résume les différentes opérations
demandées. La validation de cette synthèse entraîne la création du profil.
b. Tester le service
Seuls les utilisateurs membres du rôle de serveur sysadmin ou bien du rôle de base de
donnéesdatabaseMailUserRole défini sur la base msbd, peuvent envoyer des mails.
Il est facile de tester le profil, en sélectionnantEnvoyer un message électronique de test depuis le menu contextuel
associé au nœ ud Messagerie de base de données depuis l’explorateur d’objets de SQL Server Management Studio.

Un écran permet alors de préciser le profil à utiliser ainsi que le destinataire du message de test.

Les opérateurs
Un opérateur peut correspondre à une personne physique ou bien à un rôle joué dans l’entreprise. Ainsi, en fonction
de la taille de l’entreprise, une même personne physique peut jouer le rôle de plusieurs opérateurs, ou bien un même
opérateur peut correspondre à plusieurs personnes physiques.
Les opérateurs seront utilisés par l’agent SQL Server pour prévenir de la fin d’exécution d’un travail ou bien lors du
déclenchement d’une alerte pour les informer de la gravité de la situation.
Pour établir la communication avec les opérateurs, l’agent SQL Server dispose de trois canaux de communication : le
mail, la radiomessagerie et le message via le réseau (net send).
La remise d’un email à l’opérateur passe par le service de messagerie et c’est le serveur de messagerie qui se charge
d’acheminer le mail jusqu’à son destinataire.
Pour les messages de type radiomessagerie, là aussi l’agent SQL Server s’appuie sur le service de messagerie : c’est le
serveur de messagerie qui se chargera de transmettre le message vers le destinataire en fonction de la passerelle
configurée sur le serveur. Le message initial fourni par l’agent SQL Server devra bien entendu respecter les contraintes
imposées par cette passerelle.
Enfin les messages via le réseau, qui correspondaient auparavant à la commande net send, s’appuient maintenant sur
les services de messagerie instantanée Windows Messenger. Ce service doit donc s’exécuter sur le serveur ainsi que
sur le poste de l’opérateur.
La définition de tous les opérateurs est stockée dans la base msdb.
1. Création
La définition des opérateurs avant celle des alertes et des travaux est préférable car les opérations administratives
s’enchaînent alors dans un ordre logique.
Considérations générales
Avant de créer les opérateurs, il est important de tenir compte de certains points importants :
● Si plusieurs personnes sont concernées par le même problème, il faut utiliser un alias de groupe pour le
courrier électronique. Cette méthode est plus souple que de définir autant d’opérateurs que de personnes à
prévenir.
● Tester toutes les méthodes de notification d’opérateurs.
● La commande net send ne peut être utilisée que pour prévenir des opérateurs et serveurs exécutant
Windows.
La gestion des noms de messagerie présente quelques limitations et afin d’éviter les problèmes, il convient
de donner le nom complet de l’adresse de messagerie (exemple : livre@eni.fr) pour éviter les conflits si des
opérateurs portent le même nom.
Les principales caractéristiques d’un opérateur sont :
● son nom,
● les informations le décrivant,
● les moyens dont SQL Server Agent dispose pour le prévenir.
L’opérateur suppléant
Il est possible de définir un opérateur suppléant. Ce dernier recevra le message uniquement si l’opérateur initial est
injoignable.
Cet opérateur est également nommé opérateur de prévention de défaillance. L’opérateur de prévention de
défaillance n’est disponible que pour les alertes délivrées par radiomessagerie.

Pour créer un nouvel opérateur, il faut sélectionner Nouvel Opérateur depuis le menu contextuel associé au nœ ud
SQL Server Agent Opérateurs de l’explorateur d’objets de SQL Server Management Studio.
Transact SQL
Il est possible de créer un nouvel opérateur par l’intermédiaire de la procédure stockée sp_add_operator.
Exemple :

Toutes les procédures stockées sont dans la base msdb, la première instruction du script doit donc être use
msdb.
2. Modification
C’est par l’intermédiaire de la boîte de dialogue Propriétés de l’opérateur qu’il est possible de connaître les
informations le concernant et de modifier certains paramètres.

Transact SQL
La procédure stockée sp_help_operator, permet de connaître les paramètres actuels de l’opérateur.
Pour réaliser des modifications sur les opérateurs déjà définis, il suffit d’exécuter la procédure sp_update_operator.

3. Suppression
La suppression d’un opérateur n’est possible que si ce dernier n’est pas opérateur de défaillance.
Dans le menu contextuel lié à l’opérateur, sélectionnez le choix Supprimer.
Transact SQL
Il suffit d’exécuter la procéduresp_delete_operator.

Les travaux
L’automatisation de certaines tâches d’administration répétitives est possible par l’intermédiaire d’un travail et de la
planification de son exécution. Il est toutefois possible de lancer manuellement l’exécution d’un travail.
Les travaux sont constitués d’un ensemble de tâches. À la fin de chaque tâche deux cas se présentent : soit la tâche a
été exécutée avec succès, soit la tâche a échoué.
Le travail, qui est un enchaînement de tâches doit définir toutes les solutions possibles afin qu’il se déroule
correctement.
Tous les travaux sont stockés au sein de la table sysjobs dans la base msdb.
1. Mise en place
Les principales caractéristiques d’un travail sont :
● le nom : il doit être unique sur le serveur et limité à 128 caractères,
● la catégorie : elle permet d’organiser les travaux en fonction des opérations qu’ils réalisent. Il existe, dès
l’installation du serveur, des catégories prédéfinies telles que : Texte intégral, Maintenance de la base de
données...
● le propriétaire : celuici peut être différent de l’utilisateur qui l’a créé,
● la description,
● les étapes du travail,
● la planification,
● la notification.
Chaque travail peut être lié à une catégorie. Le regroupement par catégorie permet un regroupement logique des
différents travaux et donc une présentation de meilleure qualité dans SQL Server Management Studio.
La création d’un travail n’est possible que pour un administrateur du système (sysdamin) ou bien pour un utilisateur
membre de l’un des trois rôles de base de données liés à SQL Server Agent.
La modification et la suppression d’un travail n’est possible que par le propriétaire ou bien un administrateur du
système.
La définition d’un travail peut être réalisée soit par SQL Server Management Studio, soit au moyen de la procédure
stockée sp_add_job.

Lors de la création d’un travail, il faut :
● vérifier que le travail est activé,
● déterminer à quels endroits le travail s’exécute dans le cas de travaux multiserveurs.
Les travaux ne peuvent s’exécuter que si le service SQLServerAgent est lancé.

2. Définition des étapes d’un travail
Il est possible de définir les étapes d’un travail soit par l’intermédiaire de SQL Server Management Studio, soit par
l’utilisation de la procédure stockéesp_add_jobstep.
Toutes les étapes sont stockées dans la base msdb et la tablesys_add_jobstep.

Les étapes de travail sont typées ce qui permet de sélectionner le soussystème approprié à l’exécution de l’étape. Il
existe sept types d’étapes différents. Quatre d’entre eux sont détaillés par la suite. Les autres types de tâches
concernent des scripts Microsoft ActiveX, des tâches Analysis Services et des tâches Integration Services.
Les comptes rendus de l’exécution des différentes étapes sont conservés dans la table sysjobstepslogs de la base
msdb.
a. Transact SQL (TSQL)
C’est le type par défaut d’une étape de travail.
Il est possible d’exécuter des instructions Transact SQL, des procédures stockées, des procédures stockées
étendues. Il faut tenir compte des points suivants :
● lors de l’exécution d’une procédure, tous les paramètres requis doivent être fournis.
● un jeu de résultats peut être envoyé dans un fichier de sortie. Cependant il n’est pas possible d’utiliser le
jeu de résultats en sortie d’une étape comme entrée pour une étape suivante.
b. Commande du système d’exploitation (CMDEXEC)
Il est possible dans une étape d’exécuter une commande du système d’exploitation ou de demander l’exécution
d’un programme ou d’un fichier de commande. Il faut néanmoins :
● identifier un code de sortie pour indiquer que la commande a réussi,
● indiquer le chemin complet du programme ou du fichier de commande.
L’étape de travail doit référencer un élément exécutable du système, c’estàdire un fichier portant l’extension cmd,
bat ou exe. Le chemin d’accès à ce fichier doit être un chemin complet.
c. Scripts PowerShell
Avec Windows Server 2008 est apparu un nouveau langage de Scripting : le PowerShell. Tous les serveurs Microsoft
proposent des bibliothèques spécifiques afin de pouvoir administrer le serveur sous forme de script. Avec ce type
d’étape, il est possible de réaliser des tâches de gestion du serveur ou bien de gestion du moteur de base de
données. Chaque étape de ce type exécute un processus sqlps qui consomme 20 Mo de mémoire vive. Si un grand
nombre de tâches de ce type sont exécutées de façon simultanée, cela peut avoir une incidence non négligeable
sur les performances globales du serveur.
d. Réplication
Les processus de réplication sont appelés par des agents et sont mis en œ uvre sous forme de travaux.
Les tâches relatives à la réplication sont représentées par des types d’étapes bien distincts tels SNAPSHOT ou bien
DISTRIBUTION qui correspondent, respectivement, aux tâches de capture instantanée ou de distribution.
3. Enchaînements entre les étapes
À la fin de chaque étape, deux situations sont possibles : soit l’étape est un succès, soit l’étape est un échec.

Par défaut, en cas de succès, SQL tente d’exécuter l’étape suivante. Pour chaque étape on peut préciser un nombre
de tentatives d’exécution ainsi que le délai d’attente entre chaque reprise.
Par défaut également, le travail prend fin en cas d’échec d’une étape. Lors de l’échec d’une étape il est possible de
notifier un opérateur et/ou d’inscrire un message dans l’observateur des événements, ou encore de chaîner sur une
étape quelconque du travail.
Une autre possibilité consiste à configurer le travail pour qu’il soit supprimé automatiquement après son exécution.
4. La planification
L’exécution des travaux peut être planifiée. Cette planification sera importante pour toutes les opérations de
maintenance de bases de données, qui pourront être lancées à des moments de faible activité du serveur.
Les planifications sont mises en place par SQL Server Management Studio ou bien par la procédure stockée
sp_add_jobschedule.

Les travaux seront exécutés soit en réponse à des alertes, soit selon les planifications définies. Si on travaille dans
un environnement mutiserveur, il est possible de préciser plusieurs serveurs cibles pour un même travail.
La planification d’un travail n’est prise en compte que si elle est active, et le travail ne sera exécuté que si l’agent SQL
Server est démarré.
La planification peut demander l’exécution du travail :
● à une date et heure précise (une seule exécution),
● de façon régulière : toutes les minutes, heures, jours, semaines, mois... ou une combinaison de ces différents
critères (exemple : exécution du travail toutes les 2 heures du lundi au vendredi et de 8 h 00 à 19 h 00),
● lorsque le processus est inactif. Cette option n’est disponible que si le contexte du compte d’utilisateur utilisé
par SQLServerAgent est membre du groupe local Administrateurs.
Si la planification d’un travail est réalisée avec réflexion, l’exécution des travaux n’entraînera aucune surcharge de
travail pour le serveur lorsqu’il sera lourdement sollicité par les utilisateurs. La planification de l’ensemble de tous les
travaux administratifs permet d’optimiser les temps de réponses du serveur.
5. Exemple de travail
Le travail suivant réalise la création d’une base, d’une table et d’un utilisateur de base de données. Il a été planifié
pour s’exécuter une seule fois et un opérateur sera averti en fin d’exécution du travail.

Il est bien sûr possible de définir plusieurs planifications pour un même travail.

Les alertes
Les alertes vont être définies afin de déclencher un traitement automatique pour corriger le problème et/ou avertir un
opérateur qui sera en mesure d’agir rapidement afin de résoudre le problème.
1. Présentation
Lors du fonctionnement du serveur, des erreurs, des messages ou des événements générés par SQL Server sont
inscrits dans l’observateur des événements de Windows. L’agent SQL Server va lire le journal application à la
recherche des informations qu’il est en mesure de traiter en les comparant aux alertes qui sont définies dans la table
sysalerts de la base msdb.
Une alerte peut également être déclenchée suite au dépassement d’une valeur limite (fixée) par un compteur de
performance. Enfin une alerte peut être déclenchée suite à un évènement WMI (Windows Management
Instrumentation) particulier. Dans ce dernier cas, l’agent SQL Server est un client de l’espace de noms WMI et lors de
la définition de l’alerte, il est nécessaire de spécifier l’évènement WMI qui va déclencher l’alerte.
Les alertes associées à une erreur SQL Server sont les plus fréquentes.
a. Comment inscrire une information dans le journal application ?
Trois types d’événement sont inscrits dans l’observateur des événements :
● les messages dont le niveau de gravité et supérieur à 19. Les messages sont stockés dans la table
sysmessages de la base Master. Pour forcer un message dont le niveau de gravité est inférieur à 19 à
s’inscrire dans le journal, il faut exécuter la procédure sp_altermessage.
● toutes les instructions RAISERROR avec l’option WITH LOG.
● tout événement consigné avec xp_logevent.
La taille du journal application de l’observateur des événements de Windows doit être suffisante pour
contenir tous les messages.
b. Comment réagit l’agent SQL Server ?
L’agent SQL parcourt le journal application à la recherche des messages provenant de SQL Server. Il compare alors
l’erreur avec les alertes définies dans la table sysalerts qui est conservée dans le cache pour améliorer les
performances.
Cette alerte déclenche l’exécution d’une tâche planifiée et/ou la notification d’opérateur.
2. Gestion des alertes
Chaque alerte possède un nom qui est unique. Ce nom est limité à 128 caractères.
Seuls les messages inscrits dans l’observateur des événements peuvent déclencher une alerte.
a. En réponse à des erreurs SQL Server
Sur des erreurs SQL Server il est possible de lier une alerte soit au numéro de l’erreur, soit à la gravité.
Si pour un événement donné (n° d’erreur et niveau de gravité), deux alertes peuvent se déclencher, alors l’agent
SQL Server exécutera l’erreur la plus spécifique possible, dans ce cas celle liée au numéro d’erreur. En réponse à un
événement une seule alerte au plus peut être déclenchée.
Avant de créer une alerte, il faut prendre en considération les critères suivants :

● le numéro d’erreur doit être inscrit dans l’observateur des événements si on souhaite le déclenchement
d’une alerte.
● le niveau de gravité peut être le facteur qui déclenche l’alerte. Seules les erreurs disposant d’un niveau de
gravité situé entre 19 et 25 sont inscrites automatiquement dans l’observateur des événements. Les
niveaux 20 à 25 correspondent à des erreurs irrécupérables, il faut donc toujours définir l’opérateur à
prévenir en cas d’erreur de ce type. Les alertes fournies en exemple par SQL Server correspondent à la
gestion de ces niveaux de gravité.
● la base de données : il est possible de préciser la base à l’origine de l’événement afin de spécialiser les
alertes. On peut ainsi créer plusieurs alertes pour un même numéro d’erreur.
● texte de l’événement : toujours dans le but de limiter les déclenchements d’alertes il est possible de préciser
le texte que doit contenir le message de l’événement.
b. Le transfert d’événements
Il est possible, en se basant sur un niveau de gravité, de transférer tous les messages qui possèdent un niveau de
gravité supérieur ou égal vers un autre serveur SQL 2008. Le transfert d’événements peut être utilisé afin de
centraliser le traitement des alertes pour un groupe de serveurs exécutant SQL Server 2008.
Avantages
● La centralisation permet une gestion simplifiée des alertes.
● L’administration d’un serveur SQL supplémentaire demande une charge de travail moindre pour
l’administrateur.
● Le temps de mise en œ uvre est réduit car toutes les alertes ne sont définies qu’une seule fois.
Inconvénients
● Le transfert d’événements augmente le trafic réseau.
● Point de défaillance unique.
● Le serveur qui traite toutes les alertes subit une charge de travail importante et est moins disponible pour le
traitement des données qu’il gère.
Mise en œuvre
La désignation d’un serveur de transfert peut se faire uniquement au moyen de SQL Server Management Studio,
depuis la fenêtre des propriétés du service SQL Server Agent.

c. Mise en place
Pour définir une nouvelle alerte, il faut sélectionner Nouvelle alerte depuis le menu contextuel associé au nœ ud
Agent SQL Server Alertes de l’explorateur d’objets.

Il reste à compléter cette boîte de dialogue en y précisant le nom de l’alerte, son attachement à un numéro d’erreur
ou un niveau de gravité. Il est possible de restreindre la portée de l’alerte en spécifiant une base de données ou le
texte que doit contenir l’événement.

La page Réponse permet de préciser ce que doit faire l’alerte.
Il est possible de préciser un travail à exécuter et les opérateurs à prévenir. Pour chaque opérateur, il convient de
préciser le moyen utilisé pour le prévenir. Les notifications aux opérateurs comportent le texte qui est précisé au
niveau de l’alerte.
Activation/Désactivation de l’alerte
C’est par l’intermédiaire des Propriétés de l’alerte qu’il sera possible de la désactiver ou de la réactiver.

Transact SQL
La procéduresp_add_alert permet de définir de nouvelles alertes liées soit à un numéro d’erreur, soit à une gravité.
Cette procédure doit être utilisée en étant positionné sur la base msdb.
Activation/Désactivation de l’alerte

Cette opération se déroule par l’intermédiaire de la procéduresp_update_alert.
Suppression
Il faut cette fois utiliser la procédure sp_delete_alert.
d. En réponse à des erreurs utilisateur
Il est possible de définir des messages propres à une application. Ces messages peuvent s’ajouter aux messages
déjà définis dans SQL Server. La gestion de ces messages se fait au travers de trois procédures stockées :
sp_addmessage, sp_altermessage et sp_dropmessage pour créer, modifier ou supprimer un message.
Par exemple, la procédure sp_addmessage est exécutée pour définir le message d’erreur qui portera le n°50001,
car tous les messages définis par l’utilisateur portent un numéro supérieur à 50000. Lors de la définition du
message, il faut également définir une gravité, une langue et un message d’erreur. C’est également à ce niveau qu’il
est possible de préciser si le message sera inscrit ou non dans le journal des évènements.

Pour pouvoir définir le message en français, il est nécessaire de créer un message avec le même numéro d’erreur
mais en anglais.
Pour déclencher l’erreur à partir de l’application de base de données, il suffit d’exécuter la commande RAISERROR.
La gestion des alertes utilise les mêmes méthodes que celles abordées lors de la gestion des alertes en réponse à
des alertes SQL Server.
e. En réponse à des seuils de performance
Il est possible de définir des alertes sur des seuils de performance. Ces alertes sont liées aux compteurs SQL Server
disponibles dans l’analyseur de performances de Windows.
Des alertes peuvent être créées sur les éléments suivants :
● méthode d’accès,

● gestionnaire de tampon,
● gestionnaire de cache,
● base de données,
● verrou,
● statistiques SQL Server.
Il n’est pas nécessaire que l’analyseur de performances soit exécuté sur le poste où est installé le serveur
SQL.
La définition des alertes est presque identique mais au lieu de lier l’alerte à un numéro d’erreur ou un niveau de
gravité, l’alerte est liée à un objet, un compteur, une instance (éventuellement) et une valeur audelà ou en deça de
laquelle l’alerte est levée (les compteurs SQL Server sont détaillés au chapitre Optimisation).
Exemple :
Définition à l’aide de SQL Server Management Studio d’une alerte sur un taux de remplissage du journal. Cette alerte
notifiera un opérateur, afin que ce dernier réalise une sauvegarde puis tronque le journal.

L’importation et l’exportation de données
1. Présentation
L’importation des données consiste à récupérer des données depuis une source extérieure à SQL Server (fichier
ASCII, base Access...) et à stocker ces données dans une ou plusieurs tables d’une base SQL Server. L’exportation
représente l’opération inverse, le contenu d’une table, ou le résultat d’une requête est projeté dans un fichier ASCII,
ou directement dans une base Access par exemple.
L’importation est en général une opération ponctuelle qui intervient entre la création et la conception de base et la
mise en service de la base. Lors de cette étape d’importation, toutes les données, provenant d’un système de
gestion de données ancien, sont intégrées dans SQL Server. Une fois la migration terminée, il est possible de
travailler avec les données contenues dans SQL Server.
Cependant, l’importation peut parfois être une opération réalisée régulièrement. C’est le cas notamment lorsque la
base SQL sert à éditer des analyses sur des données stockées sur des systèmes différents.
Les opérations d’exportation sont normalement moins fréquentes. En effet si les données doivent être manipulées
depuis des outils comme Microsoft Access ou Excel, il est préférable de travailler directement sur les données
stockées dans SQL Server plutôt que de réaliser une exportation pour travailler avec une copie locale des données.
L’exportation reste la solution idéale lorsqu’un utilisateur souhaite établir des calculs sur les données en travaillant
en mode déconnecté (sur ordinateur portable par exemple).
SQL Server fournit plusieurs outils d’importation et d’exportation, afin de pouvoir réaliser ces opérations entre des
sources ODBC, OLE DB, feuilles de calcul Excel, fichiers textes ASCII.
Si les données stockées par SQL Server doivent être distribuées sur d’autres serveurs SQL de l’entreprise, il est
préférable de mettre en place la réplication de données qui offre plus de souplesse et qui se charge de synchroniser
les bases répliquées.
La réplication sera abordée au chapitre Réplication.
Présentation des transferts de données
2. Les outils
Le transfert d’informations d’une base vers une autre est une opération courante qui doit être réalisée rapidement et
de façon sûre. Pour répondre aux différents cas d’utilisation qui peuvent se présenter, SQL Server propose
différentes options. Toutes ne présentent pas les mêmes caractéristiques, mais elles ont en commun le fait de
transférer un volume important d’informations d’une source de données vers une autre.

a. SSIS (SQL Server Integration Service)
Avec SSIS, SQL Server propose beaucoup plus qu’un simple outil d’importation et d’exportation de données. SSIS
permet également de définir des transformations plus ou moins complexes sur les données manipulées. Cet ETL
(Extract Transforl and Load) permet de travailler avec des sources de données externes accessibles par un pilote
OLEDB/ODBC, afin d’importer les données dans une base SQL Server tout en réalisant des opérations de mise en
forme des données, comme par exemple un travail sur les dates.
SSIS est également un outil parfaitement adapté pour l’alimentation en données d’une base OLAP. L’opération sera
alors définie sous forme de travail planifié.
b. Réplication
La réplication de données autorise la copie de données et la synchronisation afin que toutes les copies contiennent
les mêmes valeurs de données. Il est possible de mettre en place la réplication entre SGBDR fonctionnant sur le
même réseau, LAN ou WAN, mais la réplication peut aussi être réalisée via Internet.
La mise en place des différents types de réplications sera détaillée au chapitre Réplication.
c. BCP
Cet utilitaire en ligne de commande, permet d’importer et d’exporter des données entre un fichier et SQL Server. Il
s’agit d’un utilitaire de base qui permet de réaliser rapidement de nombreuses opérations.
d. SELECT INTO et INSERT
Ces instructions SQL permettent, respectivement, de créer une nouvelle table qui contient le résultat d’une requête,
dans la base et d’insérer des données dans une table de la base. L’utilisation de ces commandes a été détaillée au
chapitre Gestion de la base de données.
Les données peuvent provenir d’un autre serveur que celui où s’exécute l’opération, on donnera alors le nom
complet de l’objet sous la forme : Serveur.base.schéma.objet.
Par défaut les valeurs suivantes sont utilisées :
● Serveur : celui où s’exécute la requête.
● Base : celle indiquée par la dernière commande use ou bien la base de données par défaut de l’utilisateur si
aucune commande use n’a encore été exécutée.
● Schéma : par défaut c’est dbo.
Exemple :

e. Les critères de choix
Le choix d’un outil dépend d’un certain nombre de critères, les plus courants étant :
● le format des données,
● l’emplacement des données,
● la fréquence de l’opération : s’agitil d’une opération ponctuelle ou qui va se dérouler régulièrement ?
● utilisation d’un outil en ligne de commande ou qui possède une interface graphique ?
● les performances.
Fonctionnalités SSIS Réplication BCP SELECT INTO INSERT
Importation
de données texte Oui Oui Oui
source de données ODBC Oui Oui
source de données OLEDB Oui Oui Oui
Exportation
de données texte Oui Oui
source de données ODBC Oui Oui
source de données OLEDB Oui Oui Oui
Interface

graphique Oui Oui Oui
ligne de commande Oui Oui
Planification possible Oui Oui Oui
Transformation de données Oui
Performances maximales Oui Oui
Opération ponctuelle Oui Oui Oui
Opération régulière Oui Oui Oui

L’utilitaire BCP
BCP (Bulk Copy Program) est un puissant utilitaire en ligne de commande. Il est bien connu des utilisateurs des versions
précédentes de SQL Server. Il est utilisé lorsque le volume des transferts entre fichiers texte et base SQL Server est
important.
BCP permet d’exporter les données d’une table ou d’une requête SQL vers un fichier texte ou bien d’importer un fichier
texte dans une table. Lors de l’utilisation il est donc nécessaire de préciser la source et la destination des données,
ainsi qu’un nom d’utilisateur et un mot de passe pour se connecter au serveur.
L’utilisation de BCP ne nécessite pas de connaissance particulière en Transact SQL, sauf dans le cas où l’exportation
s’appuie sur une requête SQL. Par contre, la description du fichier de données est un point de passage obligatoire.
1. La syntaxe
Elle peut paraître lourde dans un premier temps mais il est possible de fixer un grand nombre d’options, ce qui donne
beaucoup de souplesse lors de l’utilisation de bcp.
b c p {nom_complet_objet|" requête" }
{i n | o u t | q u e r y o u t | f o r m a t } fichier_de_données
[- m maximum_d’erreurs] [- f fichier_de_format] [- x ]
[- e fichier_d’erreurs]
[- F première_ligne] [- L dernière_ligne]
[- b taille_de_lot_d’instructions]
[- n ] [- c ] [- w ] [- N ] [- V { 7 0 | 8 0 | 9 0 } ] [- q ]
[- C page_de_code]
[- t fin_de_champ] [- r fin_de_ligne]
[- i fichier_d’entrée] [- o fichier_de_sortie]
[- a taille_de_paquet]
[- S nom_du_serveur] [- U id_de_connexion]
[- P mot_de_passe]
[- T ] [- v ] [- R ] [- k ] [- E ] [- h " option [,...n]" ]
n o m _ c o m p l e t _ o b j e t |" r e q u ê t e "
Il s’agit de donner le nom complet de l’objet (table ou vue) ou bien de préciser une requête dont le résultat sera
exporté dans un fichier.
Dans le cadre d’une exportation, il est possible de prendre comme objet une table, une vue ou bien de demander
l’exécution d’une requête. L’utilisateur doit posséder les droits de sélection appropriés.
Dans le cas d’une importation de données, elle ne peut bien sûr être réalisée au travers d’une requête. Il est parfois
possible de réaliser des insertions au travers d’une vue si certaines précautions ont été prises lors de la définition de
cette dernière. Lors de l’étape d’importation il faut que l’utilisateur soit membre du rôle db_owner.
{ i n | o u t | q u e r y o u t | f o r m a t } fichier_de_données
Les options indiquent s’il s’agit d’une opération d’export (out) ou d’importation (in) de données. Si une requête a été
spécifiée au lieu d’un nom d’objet, il faudra utiliser queryout. Enfin format permet de créer un fichier de format suivant
les options spécifiées, l’option f pourra être utilisée.
Les autres options permettent de régler le type du fichier (texte...), les délimiteurs de champs et de lignes...
S, U ,P et T
Ces quatre options sont retrouvées dans de nombreux utilitaires en ligne de commande tel que isql. Ces options
permettent de se connecter à un serveur SQL et d’ouvrir une connexion. Le nom du serveur est précisé par l’option
S. Par la suite, il est possible d’ouvrir une session soit en utilisant une authentification Windows (T), soit en
utilisation une authentification SQL Server, il faut alors fournir le nom de connexion (U) et le mot de passe (P).
2. L’utilisation de bcp en mode interactif
Si lors de l’exécution de la commande bcp, l’une des options suivantes est manquante (n, c, w ou N), alors
l’utilitaire pose les questions de façon interactive à l’utilisateur.

Dans l’exemple précédent les données contenues dans la table articles de la base Gescom sont exportées vers le
fichier articles.txt. Grâce à l’option c les données sont exportées en mode caractère. La base est stockée sur le
serveur Aravis et c’est une authentification Windows (option T) qui a été utilisée pour se connecter au serveur.
Dans l’exemple cidessus c’est le résultat d’une requête qui est exporté dans un fichier de données.

Utilisation de bcp en mode interactif
Lors de l’importation de données avec les utilitaires de copie par blocs que sont bcp et bulk copy, les déclencheurs de
type instead of et insert sont désactivés. Il est possible de demander leur exécution en levant l’option FIRE
TRIGGERS. Dans ce cas, il faut s’assurer que les déclencheurs sont capables de traiter un ensemble de lignes car ils
ne sont activés qu’une fois par bloc.
Pour faciliter la description des données, il est possible d’utiliser un fichier de format. S’il n’en existe pas lors de la
première importation, bcp pose les questions afin de générer le fichier de format bcp.fmt.

SSIS
1. Présentation
De plus en plus, le besoin se fait sentir de consolider les données réparties en un point central, puis de les déployer
sous un format ou bien un autre. Le principal problème rencontré lors de ce type d’opération de centralisation de
données est le format des données. En effet, lorsque les informations sont réparties sur différents systèmes et sur
différents serveurs, il y a très peu de chance que ce soit toujours au même format. Avec SQL Server Integration
Services, il est possible d’importer, d’exporter et de transformer des données entre plusieurs sources hétérogènes.
SSIS peut également être utilisée pour exporter les données depuis la base vers un outil d’analyse. Par exemple, les
données intégrées par l’intermédiaire de SSIS peuvent être consolidées au niveau de la base, puis il est possible de
faire de nouveau appel à SSIS pour les exporter vers un fichier Excel.
Les packages SSIS peuvent être définis dans SQL Server Management Studio ou bien dans Business Intelligence
Development Studio. Ce dernier outil concerne les packages SSIS orientés sur l’intégration des données dans une
base OLAP. Au contraire, les possibilités offertes dans SQL Server Management Studio permettent de concevoir des
packages en vue d’une intégration sur une base OLTP. Il est possible de définir et de mettre au point un package
dans Business Intelligence Development Studio puis de lancer son exécution depuis SQL Server Management Studio.
Pour pouvoir réaliser des opérations de transfert de données, il faut posséder le droit de lecture (SELECT)
sur la source de données et être propriétaire de la base de données de destination.
2. Les packages
L’utilisation de SSIS est toujours associée à un package. Le package représente le programme qui va être exécuté
par SSIS. Le package est comparable à une feuille de route dont dispose SSIS pour savoir dans quel ordre exécuter
les différentes tâches. Le package contient donc les flux de contrôle, les flux de données, le gestionnaire
d’évènements, de variables, des connexions...
Le schéma suivant illustre le cas d’un package constitué d’une simple tâche de transformation de données et d’une
tâche de type flux de contrôle.

Les tâches sont également dénommées étapes. Elles constituent l’unité de travail du processus d’intégration. Un
même package peut contenir des tâches de différentes natures.
a. Les flux de contrôle
Le flux de contrôle permet de contrôler l’enchaînement des tâches du package. Pour pouvoir définir le déroulement
exact du package, SSIS dispose de trois types d’éléments dans le flux de contrôle :
● les tâches, qui représentent les fonctionnalités ou unités de travail ;
● les conteneurs, qui permettent d’organiser logiquement le package ;
● les contraintes de précédence afin de fixer le chemin d’exécution des tâches. Les contraintes de précédence
peuvent s’appuyer sur le succès ou l’échec de la tâche précédente et/ou sur une fonction d’évaluation afin
de sélectionner la tâche suivante à exécuter.
Conteneur
Les conteneurs représentent les éléments de haut niveau disponibles dans les flux de contrôles. Les conteneurs
permettent de définir des tâches répétitives à l’aide d’une structure de boucle. Chaque conteneur est typé de la
façon suivante :
● conteneur FOREACH : ce conteneur permet d’exécuter un ensemble de tâches pour chaque élément renvoyé
par une énumération. Le conteur FOREACH doit s’appuyer sur une énumération connue comme, par
exemple, le FOREACH ADO Enumerator qui permet de parcourir l’ensemble des lignes d’une table.
● conteneur FOR : ce conteneur est semblable à une boucle FOR définie dans un langage de programmation.

Pour définir le conteneur de boucle FOR, il faut préciser la condition d’initialisation, le test qui doit être
réalisé de façon positive pour exécuter les tâches définies dans le conteneur, et la condition
d’incrémentation.
● conteneur de séquences : ce type de conteneur représente un sousensemble du flux de contrôle et permet

de gérer de façon commune un ensemble de tâches liées.
Le conteneur hôte de tâche est un conteneur particulier car il ne contient qu’une seule tâche. Il est configuré en
même temps que la tâche et ne peut pas être dissocié de celleci.
Tâche
Une tâche représente une unité de travail dans SSIS. Il existe différents types de tâche en fonction de l’action
demandée. Les tâches les plus courantes sont les tâches de flux de données, de préparation des données, SQL
Server et de script.
Pour compléter l’ensemble des tâches proposées en standard, il est possible de définir des tâches personnalisées
en C# ou bien VB.Net par exemple.
b. Les flux de données
Un flux de données dans SSIS est traditionnellement composé de trois éléments qui sont :
● la source,
● la transformation,
● la destination.
Tous ces éléments ont pour objectif de fournir les données à l’étape suivante. Au cas où une erreur se produit, la
ligne d’information concernée sort de l’étape, non pas par la sortie normale, mais par une sortie d’erreur.

La source
La source représente l’origine des informations. Les données peuvent provenir, par exemple, d’une base de
données (via OLE DB) ou bien d’un fichier plat (format csv ou bien XML).
La source va permettre de mettre à disposition les informations pour l’étape suivante c’estàdire la transformation.
La transformation
L’étape de transformation permet de mettre en forme les données avant de les fournir à la destination. Si cette
mise en forme échoue, alors les données sont redirigées vers un flux d’erreur.
Il existe des étapes de transformations prédéfinies, mais il est également possible de définir des transformations
personnalisées.
La destination
La destination représente l’endroit où le flux de données va stocker les informations. La destination peut
correspondre à une source de données OLE DB ou bien à un DataSet pour stocker le résultat à destination d’un
nouveau traitement.
c. Connexions
Pour pouvoir travailler avec la source et la destination, SSIS doit établir une connexion avec les différentes sources

de données référencées. Il existe plusieurs types de connexion comme des connexions au travers d’ADO, d’ADO.Net
mais aussi des connexions vers des fichiers Excel ou bien encore vers SAP.
d. Variables
Les variables définies au niveau du package permettent de rendre le package plus souple en terme de paramétrage
et de faciliter ainsi sa mise au point et son adaptation à différents cas d’utilisation similaire. Par exemple, la borne
maximale utilisée par un conteneur de type FOR peut être contenue dans une variable. La simple modification de la
valeur affectée à cette variable, permet de modifier le comportement des conteneurs FOR qui lui font référence.
En complément des variables définies par le concepteur, SSIS propose des variables dites système c’estàdire qui
font référence à des éléments du système. Là aussi, une utilisation systématique de ces variables à la place d’un
codage direct de la valeur permet de définir un package plus souple, car il saura mieux s’adapter aux différentes
configurations présentes.
La liste cidessous illustre quelquesunes des variables système :
● InteractiveMode : variable de type booléenne qui possède la valeur True si le package est exécuté depuis
le concepteur SSIS. Si le package est exécuté avec DTExec, la valeur est à False.
● MachineName : variable de type chaîne de caractères (String) qui permet de connaître le nom du poste sur
lequel s’exécute le package SSIS.
● PackageName : variable de type chaîne de caractères (String) qui représente le nom du package en cours
d’exécution.
● UserName : variable de type chaîne de caractères (String) qui contient le nom de l’utilisateur qui a lancé
l’exécution du package.
e. La sauvegarde des packages
Les packages SSIS peuvent être enregistrés soit dans la base msdb de SQL Server, soit sous forme de fichier.

Quel que soit le type de sauvegarde choisi, il est possible de crypter les données par rapport à la clé de l’utilisateur
ou bien par un mot de passe.
Système de fichiers
En choisissant ce type de sauvegarde, l’intégralité de la définition du package et de son paramétrage est conservée
sous forme de fichiers en dehors de toute instance SQL Server. Cette solution offre beaucoup de souplesse en
terme de déploiement des packages. Au niveau de la sauvegarde, il est nécessaire de consulter le fichier
MsDtsSrvr.ini.xml de configuration du service SSIS afin de connaître la liste des dossiers contrôlés par SSIS.
Base msdb
En utilisant cette base de données système pour stocker la définition des différents packages, il est possible de
s’appuyer sur la politique de sauvegarde définie au niveau du serveur pour conserver une copie de sécurité des
packages. Cependant, le paramétrage des lots est conservé sous forme de fichiers externes à la base.
3. La gestion des packages
Quel que soit le moyen utilisé pour définir les packages SSIS, ceuxci sont administrables depuis SQL Server
Management Studio.
L’administration du service SSIS n’est pas activée par défaut dans SQL Server Management Studio, il est donc
nécessaire de demander la connexion à un service SSIS particulier, comme cela est illustré par l’écran suivant.

SQL Server Management Studio propose alors une interface complète de gestion des différents packages, qu’ils
soient enregistrés dans la base MSDB ou bien sur le système de fichiers.
Les différents packages sont protégés par des rôles afin de ne pas rendre possible leur exécution et leur modification
par n’importe quel utilisateur. Il est possible de connaître et de modifier cette liste de rôles en sélectionnant Rôles du
package depuis le menu contextuel associé au package depuis l’explorateur d’objets.

4. Exécuter un package
Un package peut être exécuté soit en ligne de commande, soit depuis un outil de conception graphique. Il est
également possible de définir un travail planifié chargé d’exécuter le package SSIS.
Bien qu’il soit possible d’exécuter un package depuis SQL Server Business Intelligence Development Studio, c’est
depuis SQL Server Management Studio que le package va être géré.
Pour lancer l’exécution d’un package, il suffit de sélectionner Exécuter le package depuis le menu contextuel associé
au package.
SQL Server Management Studio propose alors une fenêtre de configuration du package.
Dtexec
Cet utilitaire permet de demander l’exécution d’un package stocké sous forme de fichier ou bien dans la base MSDB.

L’utilitaire DTexecUI permet de générer la liste des paramètres nécessaires à la bonne exécution du package. Cet
utilitaire est lancé de façon automatique par SQL Server Management Studio.
Il est possible de s’appuyer sur un fichier de commande pour lancer l’exécution du lot en saisissant le nom d’un fichier
de commande depuis la zone Fichiers de commandes.
Depuis cette même fenêtre, il est possible de consulter la ligne de commande qui va être générée en sélectionnant la
zone Ligne de commande.

Planification du package
La planification de l’exécution du package passe par un travail planifié qui va être géré par l’Agent SQL Server. Ce
travail possède une tâche qui va exécuter le lot en utilisant dtexec.
5. Assistants d’importation et d’exportation
SQL Server Management Studio dispose d’assistants d’importation et d’exportation de données afin de définir des
packages SSIS simples. Ces packages répondent à la plupart des opérations de transfert de données souhaitées sur
une base de données OLTP, car ils rendent possible aussi bien l’extraction que l’intégration de données externes.
Les principales fonctions proposées par l’assistant sont :
● le transfert de données entre des bases hétérogènes,
● le transfert d’objets entre deux bases SQL Server,
● la création dynamique de la destination du transfert,
● la transformation des données.

L’assistant va, dans un premier temps, demander la source et la destination des données.
Dans l’exemple présenté cidessous, la source correspond à la base GESCOM et la destination est un fichier texte.

L’assistant demande par la suite de sélectionner la table ou bien de saisir la requête qui va fournir les informations à
stocker dans le fichier. Il est également possible à ce niveau de définir des transformations et de spécifier le format
exact du fichier texte.

Enfin, l’assistant propose de stocker le lot soit dans SQL Server, soit sous forme de fichier.
6. Le concepteur SSIS
Le concepteur SSIS, disponible dans Business Inteligence Development Studio est l’outil graphique de conception et
de mise au point des packages SSIS. Pour accéder au concepteur, il faut tout d’abord créer un projet de type
Integration Services comme illustré par l’écran ciaprès.
Par défaut Business Intelligence Development Studio n’est pas installé même si le service Integration Services est
présent. Aussi, il est nécessaire de passer par l’ajout/suppression de programmes afin de modifier l’installation
courante pour ajouter le composant manquant.

Lors de l’exécution de Business Intelligence Studio, il est nécessaire de demander la création d’un projet de type
Integration Services.
L’écran de travail est composé des onglets suivants :
● Flux de contrôle : permet de définir l’enchaînement logique des étapes de travail.
● Flux de données : permet de définir, à l’aide de la boîte à outils, les éléments liés aux sources de données.

● Gestionnaire d’événements : permet de gérer les événements sur les différentes étapes du package.
● Explorateur de package : il permet d’avoir une vision globale de tous les éléments définis dans le package,
que ce soit des variables, des connexions à des sources de données, des étapes de transformation...
Le concepteur dispose de sa boîte à outils afin de concevoir graphiquement les différentes tâches qui composent le
package.
L’écran cidessous illustre l’environnement du concepteur SSIS.
a. Modifier un package existant
Le concepteur SSIS peut être utilisé pour modifier un package déjà défini et enregistré sous forme de fichier ou bien
dans la base msdb.
Pour ouvrir un package existant, il faut sélectionner Ajouter un package existant dans le menu contextuel associé
au nœ ud Packages SSIS depuis l’explorateur de solutions.

Il est alors possible de sélectionner l’instance SQL Server sur laquelle le package va être recherché puis, après avoir
établi la connexion, de sélectionner le package à ouvrir.
Le concepteur SSIS permet alors de modifier simplement le package en ajoutant des tâches, par exemple, en amont
ou bien en aval.
b. Définir un nouveau package
Le concepteur SSIS peut également être utilisé pour bâtir un nouveau package. La boîte à outil mise à disposition
permet de concevoir graphiquement le lot SSIS.
Dans l’exemple présenté cidessous le package SSIS est composé de deux tâches avant d’exécuter le transfert de

données. Le flux de contrôle permet de définir que la tâche de création de table n’est exécutée qu’en cas de succès
de la tâche de suppression de table. La tâche de flux de données est exécutée soit après la création de la table,
soit après l’échec de la suppression.
7. Plan de maintenance
Les packages SSIS permettent de définir l’enchaînement logique de plusieurs tâches sur les bases de données. La
boîte à outil du concepteur SSIS dispose d’une section dédiée aux différentes tâches présentes dans un plan de
maintenance.
Pour planifier l’exécution du plan de maintenance de façon régulière, la méthode adoptée sera la même que celle
relative à la planification de l’exécution d’un package SSIS, c’estàdire en définissant un travail qui va exécuter
l’utilitaire DTEXEC.
Dans l’exemple suivant, le package SSIS contient plusieurs opérations d’un plan de maintenance. En cas d’échec de
l’une des tâches du plan de maintenance, un opérateur est notifié. Un opérateur est également notifié du bon
déroulement de l’exécution de l’ensemble des tâches.

Dans les versions précédentes de SQL Server, c’est l’utilitaire en ligne de commande sqlmaint ou bien son assistant
graphique qui permettait de définir les plans de maintenance. Bien que sqlmaint soit toujours présent dans SQL
Server 2008, il va être amené à disparaître dans les versions futures de SQL Server. Il ne faut donc pas faire appel à
cet utilitaire pour définir de nouveau plan de maintenance.

Service Broker
Service Broker est une nouvelle fonctionnalité offerte par SQL Server 2005 avec pour objectif de faciliter le
développement d’applications sécurisées qui supportent une forte montée en charge.
Service Broker est une fonctionnalité pour les applications de type SOA (Service Oriented Architecture). Une telle
application est composée d’éléments logiciels faiblement couplés, c’estàdire que le changement de la logique de
fonctionnement de l’un des composants ne va pas remettre en cause les autres composants. Les applications de
messagerie sont un bon exemple d’application SOA. En effet, dans ce type d’application, l’outil de gestion des
messages est indépendant du serveur SMTP de gestion des courriers. Il est possible de gérer les courriers avec un
outil tel qu’Outlook, sans qu’il soit nécessaire de connaître le type de serveur qui gère les messages. L’utilisateur final
peut librement choisir un autre outil de gestion des messages, cela ne remettra pas en cause la messagerie. Il en est
de même pour le serveur de gestion des messages. Son changement n’oblige en aucun cas à forcer les utilisateurs à
changer d’outil client.
Service Broker prend en charge les messages de demande de services adressés par les applicatifs clients. Ces
messages sont organisés et regroupés dans une file d’attente (une par applicatif demandeur), puis une fois le travail
effectué sur la base de données, Service Broker se charge d’adresser un message à l’application qui avait effectué la
demande de service. Pour un applicatif demandeur, les messages sont traités suivant leur ordre d’émission et pour
chaque message demandeur, Service Broker adresse un message relatif au traitement fait.
En fournissant tous les éléments pour des opérations asynchrones sur la base de données, ce qui est nécessaire dans
le cadre des applications distribuées, Service Broker est un support indispensable à la programmation sous forme de
service.
1. La structure de Service Broker
Il est important de comprendre comment est structuré Service Broker avant de travailler avec.
Service Broker est organisé autour de cinq éléments clés :
● le type de message ;
● le contrat ;
● la file d’attente ;
● le programme de service ;
● le service.

Le dialogue s’établit entre le demandeur et le fournisseur. Le transport des messages entre les deux parties
s’effectue au travers du protocole http, car elles utilisent un point de terminaison http (http endpoint) pour envoyer
les messages au destinataire. Comme pour tous points de terminaison http définis dans SQL Server, il est possible de
les sécuriser par l’intermédiaire d’un processus d’authentification. Ce paramètre de gestion d’authentification peut
prendre les valeurs suivantes :
● None : les accès anonymes au service sont possibles.
● Enabled : le consommateur peut s’authentifier, s’il en est capable. Sinon l’accès anonyme au service est
possible.
● Required : le consommateur à obligation de s’authentifier.
Service Broker chiffre les messages circulant entre le demandeur et le consommateur. La complexité de la méthode de
chiffrement varie selon que l’accès au service soit fait de façon anonyme ou non.
2. Le type de message
Le consommateur de service (l’application demandeuse) va adresser un ou plusieurs messages de demande de

services au fournisseur de services. Pour que le dialogue puisse s’établir entre le consommateur et le fournisseur, le
type des messages doit être connu des deux parties.
Les types de messages doivent donc être définis à l’identique sur le serveur et le consommateur.
Un type de message est parfaitement identifié par son nom et il indique le type de données contenues dans le
message.

3. Le contrat
Le contrat Service Broker est un contrat SOA générique. Le contrat précise les types de messages qui permettent
d’accomplir une tâche. Le contrat spécifie également les expéditeurs possibles pour chaque type de message. Le
contrat doit être établi avant tout travail commun et il doit être connu du consommateur et du fournisseur de service.
Il est possible de faire une analogie avec la vie de tous les jours. Dans ce cas, le type de message représente les
règles de savoirvivre et le contrat fixe, quant à lui, dans quel ordre il faut adopter ces règles et qui fait quoi. Par
exemple, lorsque l’on entame une conversation les différents types de messages peuvent être :
● Puisje poser une question ?
● Oui,
● Quelle heure estil ?
● Il est 08h05.
Le contrat permet de définir que la conservation se fait sous la forme une question une réponse. L’initiateur de la
conversation pose les questions tandis que la cible envoie les réponses.
4. La file d’attente
Le fournisseur et le consommateur possèdent leur propre file d’attente. Le consommateur utilise cette file d’attente
afin de ne pas être bloqué par l’envoi d’un message surtout si le fournisseur n’est pas capable d’accepter
immédiatement le message et qu’il doit être réexpédié un certain nombre de fois. Le fournisseur utilise une file
d’attente afin de traiter les messages en fonction de sa propre disponibilité, par exemple, lorsque la charge de travail
est moindre sur le serveur.
Service Broker gère la liste d’attente sous forme de tableau. Chaque ligne du tableau contient le message mais

également le contrat et l’identifiant de la conversation.
5. Le service
Un service au sens Service Broker correspond à une ou plusieurs tâches. C’est entre les services que les
conversations ont lieu.
Le programme de service représente le programme qui va prendre en charge la gestion des messages et fournir la
logique du service.
C’est le programme de service qui se charge de rédiger le message à destination du demandeur.
Service Broker est capable de démarrer le programme de service qui va gérer le message reçu. Il est également
possible de planifier une exécution régulière du programme de service afin qu’il traite les éventuels messages qui le
concernent.
L’objet de service représente la partie visible du fournisseur de service. C’est à l’objet de service que le
consommateur va adresser sa demande. L’objet de service possède les contrats et gère la file d’attente. Un objet de
service qui ne gère pas de contrat correspond à un consommateur.

6. La conversation
Lorsqu’il existe deux services avec les mêmes caractéristiques, il est possible d’établir une conversation ou dialogue
entre l’initiateur (le demandeur) et la cible (fournisseur).
Au cours de cette conversation, les messages sont expédiés une seule fois et traités dans l’ordre d’émission. En
effet, chaque message contient un numéro de séquence et l’identifiant de son émetteur de façon à garantir le
traitement des messages dans le bon ordre.

Mise en place
Après avoir présenté les éléments constitutifs de Service Broker et leur imbrication les uns avec les autres, il est
important de visualiser comment il est possible de les mettre en place de façon concrète dans SQL Server.
Comme cela a été exposé au niveau de la structure, les éléments suivants doivent être définis :
● Type de messages et contrats ;
● File d’attente ;
● Service.
Ensuite, il est possible d’envoyer et de recevoir des messages et donc de définir une application utilisant Service Broker.
1. Activer Service Broker
À la création d’une base de données, le service Service Broker est activé par défaut. Il est tout à fait possible de
désactiver le service. Si des messages arrivent alors que le service est désactivé, alors ils sont stockés dans la file
d’attente. Ils seront traités lorsque le service sera de nouveau activé.
Depuis SQL Server Management Studio, il est possible de connaître l’état d’activation ou non de Service Broker en
interrogeant la valeur de la colonneis_broker_enabled de la table sys.databases.
L’activation et la désactivation du service sont possibles par l’intermédiaire de l’instruction ALTER DATABASE.
Syntaxe
ALTER DATABASE nomBaseDeDonnees

SET option;
Il existe quatre options pour gérer l’état de Service Broker :
● ENABLE_BROKER pour activer la remise des messages.
● DISABLE_BROKER pour désactiver la remise de messages.
● NEW_BROKER pour activer la remise de message avec un nouvel identifiant de base de données. Ce nouvel

identifiant provoque la fin en erreur de toutes les conversations existantes.
● ERROR_BROKER_CONVERSATIONS pour activer la remise des messages tout en mettant fin aux autres
conversations sous forme d’erreur. L’identificateur de base de données est inchangé.
Exemple
L’exemple cidessous illustre comment activer le service sur la base Gescom :
2. Type de messages
Les types de messages et les contrats sont les premiers éléments à définir dans la mise en place d’une solution
utilisant Service Broker. Les types de messages doivent être définis sur toutes les bases concernées par Service
Broker.
Il est nécessaire de définir au moins un type de message dans une application utilisant Service Broker.
Syntaxe
CREATE MESSAGE TYPE nomDuTypeDeMessage

[AUTHORIZATION nomPropriétaire]
[VALIDATION ={NONE | EMPTY | WELL_FORMED_XML |
VALID_XML WITH SCHEMA COLLECTION nomSchemaCollection}]
AUTHORIZATION
Permet de spécifier le rôle ou l’utilisateur de base de données qui est propriétaire du type de message.
VALIDATION
Cette clause permet de définir le type de données présentes dans le message.
● NONE : le message n’est pas validé.
● EMPTY : aucune donnée n’est présente dans le message.
● WELL_FORMED_XML : ces données présentes dans le message le sont sous forme de chaîne XML bien formée.
Dans le cas contraire, Service Broker retourne une erreur.

● VALID_XML : la chaîne XML doit respecter le schéma passé en paramètre.
Exemple
Sur la base GESCOM, les types de messages GescomQuestion et GescomReponse sont définis.
3. Contrats
Les contrats permettent de définir dans quel ordre et par qui les différents types de messages peuvent être envoyés.
Tous les participants à une conversation se doivent de travailler avec le même contrat.
Sans contrat, aucune conversation n’est possible car le contrat fixe les règles de conversation et régit la forme que le
dialogue peut prendre. Avec le contrat, chaque participant à la conversation sait quel type de message il peut utiliser.
Syntaxe
CREATE CONTRACT nomContrat

[ AUTHORIZATION nomPropriétaire ]
(nomDuTypeDeMessage SENT BY { INITIATOR | TARGET | ANY }[,n] )
SENT BY
Cette option précise le sens dans lequel le message peut être transmis.
● INITIATOR : celui qui est à l’origine de la conversation.
● TARGET : celui qui est l’interlocuteur.
● ANY : les deux participants à la conversation.
Exemple
Dans l’exemple suivant, le contrat définit que l’initiateur pose les questions et que la cible peut simplement émettre des
messages de type réponse.

4. Files d’attente
Service Broker conserve les messages à traiter par le programme de service dans une file d’attente. Les files d’attente
doivent être définies avant la mise en place de la solution globale Service Broker. Chaque file d’attente est
caractérisée par un nom, une disponibilité et des paramètres d’activation.
Une file d’attente est perçue par SQL Server comme une table, aussi estil possible d’y effectuer une requête de type
SELECT pour en visualiser son contenu. Cette requête peut également contenir des critères de restriction.
Les différentes colonnes de la file d’attente sont :
● status : représente l’état du message
● queing_order : numéro d’ordre du message dans la file d’attente
● conversation_group_id : identifiant du groupe de conversations
● conversation_handle : identifiant de la conversation
● message_sequence_number : numéro d’ordre du message dans la conversation
● service_name : nom du service
● service_id : identifiant du service
● service_contract_name : nom du contrat
● service_contract_id : identifiant du contrat
● message_type_name : nom du type de message
● message_type_id : identifiant du type de message
● validation : type de validation du message
● message_body : le message à proprement parlé

● message_id : identifiant du message
Syntaxe
CREATE QUEUE nomFile

[ WITH
[ STATUS = { ON | OFF },]
[ RETENTION = { ON | OFF },]
[ ACTIVATION ([ STATUS = { ON | OFF } , ]
PROCEDURE_NAME = nomProcédure ,
MAX_QUEUE_READERS = nombreMaximumInstanceProcédure ,
EXECUTE AS { SELF | ’utilisateur’ | OWNER } ) ] ]
[ ON { groupeDeFichiers | [ DEFAULT ] } ]
STATUS
Le statut actif (ON) permet de positionner de nouveaux messages dans la file d’attente et le programme de service
peut supprimer de la file les messages traités. En statut inactif (OFF) la file d’attente est en lecture seule, il n’est pas
possible d’ajouter ni de supprimer des messages.
RETENTION
Cette option, non active par défaut, permet, si elle est activée (ON), de conserver une trace de tous les messages qui
transitent via la file d’attente. L’activation de ce paramètre peut avoir des conséquences directes sur les performances
compte tenu de la taille de la file d’attente.
ACTIVATION
Ce paramètre permet de préciser le comportement de la file d’attente lorsqu’un nouveau message arrive. Si ce
paramètre est à ON (file d’attente activée), alors la procédure stockée dont le nom est spécifié dans l’option
PROCEDURE_NAME est considérée comme le programme de service et elle est activée. Au contraire, si la file d’attente est
désactivée (OFF), alors les messages sont simplement stockés dans la file d’attente.
MAX_QUEUE_READERS
Ce paramètre permet de spécifier le nombre maximum d’instances de la procédure stockée qui peuvent être lancées
de façon simultanée par Service Broker. Si cette valeur est grande, la capacité de traitement est importante et les
messages vont rester peu de temps dans la file d’attente. Au contraire, avec une valeur faible, les messages
possèdent une probabilité supérieure de rester plus longtemps dans la file d’attente. Il n’existe pas de valeur optimale
par défaut, tout est fonction du nombre de messages à traiter.
EXECUTE AS
Ce paramètre permet d’exécuter la procédure stockée dans un contexte de sécurité différent de celui du propriétaire
de la file d’attente.
ON
La file d’attente est gérée par SQL Server. Ce paramètre permet de préciser le groupe de fichier mis à contribution
pour obtenir de l’espace disque afin de conserver tous les messages présents dans la file d’attente.
Exemple
Dans l’exemple suivant, deux files d’attentes sont créées, une pour l’initiateur et une autre pour la cible de la conversation.

5. Service
Le service sert de support à la conversation entre le consommateur et le fournisseur. La définition du service va

permettre de définir les contrats disponibles, la file d’attente dans laquelle les messages vont être stockés et si les
messages doivent ou non être conservés jusqu’à la fin de la conversation.
Le service est identifié par son nom.
Syntaxe
CREATE SERVICE nom service

ON QUEUE nominalement
[(nom contrat[,...])];
ON QUEUE
Permet de spécifier le nom de la file d’attente qui va servir de support à la conversation définie par le service.
nomContrat
Permet de stipuler le ou les contrats pour lesquels le service peut être la cible. Les contrats ne sont spécifiés que sur
le service cible.
Exemple
Dans l’exemple suivant, un service est défini sur la base Gescom en utilisant le contrat et la file d’attente préalablement
définis. Un second service est défini. Ce second service à pour objectif d’initier la conversation.

Utiliser Service Broker
1. Envoyer un message
Les messages sont au centre du fonctionnement de Service Broker. L’envoi d’un message par le consommateur de
service à destination du fournisseur est donc une opération régulière et courante.
Les messages s’inscrivent toujours dans le cadre d’une conversation et donc les éléments vus cidessus doivent être
définis avant l’émission du premier message.
L’envoi du premier message s’effectue en trois étapes :
● La définition d’une variable permettant d’identifier la conversation,
● Marquer le début de la conversation (BEGIN DIALOG),
● Envoyer le message (SEND).
Syntaxe
DECLARE @identifiantConversation UNIQUEIDENTIFIER
BEGIN DIALOG [CONVERSATION] @identifiantConversation

FROM SERVICE nomService
TO SERVICE ’ nomService’ [ , identifiantBase ]
ON CONTRACT nomContrat
[ WITH
[ { RELATED_CONVERSATION = identifiantConversation
| RELATED_CONVERSATION_GROUP = idGroupeConversation } ]
[ [ , ] LIFETIME = dureeDialogue ]
[ [ , ] ENCRYPTION = { ON | OFF } ] ]
FROM SERVICE
Permet de spécifier le nom du service qui possède l’initiative du dialogue. C’est donc ce service qui émettra le premier
message. La file d’attente de ce service contiendra les messages émis par le fournisseur.
TO SERVICE
Permet de préciser le service avec lequel la conversation est établie. La file d’attente de ce service va recevoir les
messages à traiter. Le nom du service distant doit être spécifié en respectant la casse car Service Broker effectue une
comparaison octet par octet afin d’identifier le bon service. Si le service ne s’exécute pas sur la base courante, il est
nécessaire d’y ajouter l’identifiant du service. Il est possible de connaître cet identifiant en interrogeant la colonne
service_broker_guid de la table sys.databases.
ON CONTRACT
Indique le nom du contrat qui est utilisé par la conversation.
WITH
Permet d’inclure le dialogue en cours de définition dans une conversation déjà établie. L’identifiant de la conversation
permet de connaître précisément la conversation à rejoindre.
LIFETIME
Une durée maximale de conversation peut être définie en secondes. Dans le cas où la durée de vie de la conversation
n’est pas définie, la conversation prend fin lorsque les deux services y mettent fin de façon explicite.
ENCRYPTION
Permet de coder les messages en deux services. Service Broker code automatiquement les messages lorsque le

dialogue est établi entre deux instances SQL Server distinctes. Dans le cas contraire, Service Broker ne crypte pas les
messages par défaut.
Exemple
L’exemple suivant utilise les deux services créés dans les exemples précédents pour établir une conversation au sens
Service Broker.
Après avoir initié la conversation, il est possible d’envoyer un message à la cible.
Syntaxe
SEND ON CONVERSATION identifiantConversation

MESSAGE TYPE nomTypeDeMessage
[ ( corpsDuMessage) ]
L’identifiant de la conversation est la variable de type uniqueidentifier qui a été valorisée par BEGIN DIALOG. Elle
permet d’identifier le dialogue.
MESSAGE TYPE
Cette option permet de spécifier le type du message qui est envoyé. Ce type de message doit correspondre à l’un des
types de messages définis par le contrat auquel fait référence la conversation.
Le corps du message contient des informations spécifiques aux messages. Sa structure est fonction du type de
message.
Exemple

Après l’envoi du message, il est possible de consulter la file d’attente du destinataire pour y vérifier la présence du message.
2. Lire un message
Si l’envoi du message est une opération importante dans l’élaboration d’un dialogue, elle ne sert à rien si le récepteur
ne prend pas la peine de lire le message. C’est le programme de service qui se charge de lire le message depuis la file
d’attente. Pour cela, il va utiliser l’instruction RECEIVE. Mais comme pour l’envoi de message, il est nécessaire de
préparer l’environnement afin de pouvoir lire le message.
La première étape consiste à déclarer les variables nécessaires à la réception du message et le traitement des
informations localement à la procédure stockée. En règle générale, il est nécessaire de déclarer trois variables pour
l’identifiant de la fonction, le type du message et le corps du message.
Puis le message est extrait de la file d’attente par l’intermédiaire de l’instruction RECEIVE. Cette instruction permet de
réceptionner un ou plusieurs messages présents dans la file d’attente et relatif à la même conversation. Les
messages sont lus et supprimés dans l’ordre spécifié par le paramètre message_sequence_order.
Syntaxe

[ WAITFOR ( ]
RECEIVE [ TOP (n) ] listeDeColonnes
FROM nomFileAttente
[ INTO tableDeStockageMessages ]
[ WHERE {conversation_handle = identifiantConversation
| conversation_group_id = idGroupeConversation } ]
[ ), TIMEOUT délai ]
WAITFOR
Permet de forcer la procédure à attendre la présence d’un message dans la file d’attente, ou bien un certains laps de
temps, spécifié par TIMEOUT, avant de poursuivre son trai tement. Sans l’instruction WAITFOR, si la procédure ne
trouve aucun message dans la file d’attente, alors elle s’arrête de travailler. C’est pour cette raison, qu’il est très
fortement recommandé d’inclure la procédure de réception des messages (RECEIVE) dans une boucle WAITFOR.
TOP
Compte tenu que l’instruction RECEIVE permet de ramener un ensemble de messages, il est possible de traiter
seulement les n premiers. En spécifiant la valeur 1, les messages peuvent être traités un par un.
listeDeColonnes
En utilisant le caractère générique *, toutes les colonnes présentes dans la file d’attente sont retournées. Il est
possible de sélectionner les colonnes pour lesquelles la valeur souhaite être connue. Il est également possible
d’utiliser ces colonnes pour effectuer une restriction à l’aide de la clause WHERE.
FROM
Permet de fournir le nom de la file d’attente depuis laquelle les messages seront lus.
INTO
Les informations de chaque message peuvent être stockées dans une table. Il est alors nécessaire de traiter les
messages un par un. Il est possible de stocker les informations, uniquement dans une variable de type table.
WHERE
La clause where permet de ne pas lire tous les messages mais uniquement ceux répondant à certains critères, comme
l’identifiant d’une conversation par exemple.
TIMEOUT
Utilisé conjointement avec WAITFOR, TIMEOUT permet de spécifier en millisecondes, le temps d’attente de la procédure
avant de poursuivre son traitement. Avec la valeur 1, la procédure va être suspendue jusqu’à l’arrivée d’un message
dans la file d’attente.
Exemple
Dans l’exemple suivant, la boucle de lecture des messages va patienter pendant 30 secondes avant de s’achever de façon
définitive si aucun message n’est présent dans la file d’attente.

a. Vérifier le type de message et mettre fin à la conversation
Avant le traitement proprement dit, la procédure vérifie le type du message afin de s’assurer qu’elle est capable de
la traiter.
Enfin, si la procédure a lu et traité le dernier message d’une conversation, elle va mettre fin à la conversation par
l’intermédiaire de l’instruction END CONVERSATION.
Syntaxe
END CONVERSATION identifiantConversation

[ WITH ERROR = codeErreur DESCRIPTION = messageErreur ]
[ WITH CLEANUP ]
WITH ERROR
Lorsque la conversation est achevée suite un dysfonctionnement, il est possible de lever une erreur par
l’intermédiaire de cette option.
WITH CLEANUP
Avec cette option, tous les messages et métadonnées présents dans les files d’attente sont supprimés.
Exemple
La conversation est terminée.

Les certificats
Lors de l’échange d’informations entre utilisateurs, les principaux problèmes de sécurité qui se posent sont :
● Comment être sûr que les informations ne vont pas pouvoir être lues par un autre utilisateur ?
● Comment être sûr de l’identité de la personne ?
Pour pouvoir répondre positivement à ces deux questions et donc être sûr de la validité des informations transmises,
SQL Server propose d’utiliser les certificats.
Les certificats reposent sur le principe des clés publiques et privées. L’émetteur d’un message peut utiliser sa clé
privée pour coder le message et seuls les utilisateurs disposant de la clé publique peuvent lire le message. Ce premier
codage permet de garantir l’origine du message.
Maintenant, si le destinataire transmet sa clé publique à l’émetteur, celuici peut utiliser la clé publique du destinataire
pour coder le message. Seul le destinataire pourra décoder le message à l’aide de sa clé privée. Ce second codage
permet de garantir le fait que le message ne pourra pas être lu par une personne autre que le destinataire.
SQL Server utilise les certificats comme moyen de cryptage et d’authentification entre deux instances Services Broker.
Ces opérations de codage/décodage de l’information prenant du temps et une présence trop marquée des certificats
va alourdir la consommation de temps processeur et donc rendre le serveur moins réactif aux demandes des
utilisateurs.
SQL Server est capable de générer et de gérer des certificats. Les certificats créés par SQL Server sont conformes à la
norme X.509v3. Les certificats créés par SQL Server depuis une instruction Transact SQL ou bien SQL Server
Management Studio, sont conservés dans la base de données courante de l’utilisateur lors de la création du certificat.
Ainsi, si la base de données est transférée d’un serveur à un autre, les certificats le sont également.
Service Broker peut utiliser les certificats pour établir une communication sécurisée. Si tel est le cas, il faut au préalable
configurer le point de terminaison http (HTTP ENDPOINT) de façon à rendre obligatoire l’authentification et
éventuellement à utiliser l’authentification basée sur les certificats.
Le certificat peut également être utilisé pour garantir la conformité du code, créé dans la base de données, en
garantissant sa nonmodification.
Enfin, les informations peuvent être codées à l’aide d’un certificat.
Créer un certificat
Un certificat peut être créé de façon simple à partir de l’instruction suivante :
CREATE CERTIFICATE nomCertificat

ENCRYPTION BY PASSWORD=’motDePasse’
WITH SUBJECT =’nomSujetCertificat’
Exemple

Supprimer un certificat
Il n’est possible de supprimer un certificat que s’il n’est pas utilisé.
DROP CERTIFICATE nomCertificat;
Exemple

Service Broker entre deux bases distinctes
Cette foisci la mise en place est un peu plus complexe. En effet, Service Broker doit être capable d’accéder au service
distant avec un certain contexte de sécurité. Pour cela, il lui est nécessaire de se connecter au serveur. Il n’est pas
possible, ni même envisageable, de coder en "dur" le mot de passe à utiliser pour se connecter au serveur. C’est
pourquoi la connexion utilisée par Service Broker sera basée sur un certificat.
Il est également nécessaire de définir une route au niveau de Service Broker afin que le service initiateur soit capable
de localiser le service cible. Ces routes sont tout à fait comparables aux routes qui peuvent être mises en place au
niveau du réseau.
La mise en place de ce dialogue entre deux bases distinctes de la même instance SQL Server est illustrée tout au long
des étapes suivantes. Cette mise en place permet d’illustrer de façon concrète l’utilisation de certificats.
Pour mettre en place le dialogue Service Broker entre deux bases, il est nécessaire de respecter les étapes suivantes :
● Créer les objets spécifiques à Service Broker : type de messages, contrat, file d’attente, service.
● Définir les routes pour que chaque service puisse localiser le service distant.
Rechercher les identifiants Service Broker.

Mettre en place les routes.
● Définir les éléments nécessaires à sécuriser le transport (les étapes sont à répéter sur chaque instance).
Créer une Master Key sur la base master.

Créer le certificat et le point de terminaison qui accepte une authentification basée sur les certificats.
Accorder la permission d’utiliser le point de terminaison.

● Définir les éléments pour sécuriser le dialogue (les étapes sont à répéter sur chaque instance).
Créer une Master Key sur la base locale.
Créer les certificats.

Sauvegarder les certificats.
Créer les utilisateurs de base de données (sans connexion) et les certificats à partir de la sauvegarde.

Accorder la permission de se connecter à l’utilisateur.
Accorder la permission d’envoyer un message.

Créer un service distant.
● Envoyer et recevoir des messages.
Il ne reste plus maintenant qu’à tester le fonctionnement de l’architecture Service Broker ainsi mise en place. Ainsi,
depuis la base bd1 le dialogue est initié.

● Depuis la base de données cible, il est possible de lire et de traiter le message reçu de la façon suivante :

Présentation
La réplication est une puissante fonctionnalité de SQL Server qui permet de distribuer les données et d’exécuter les
procédures stockées sur plusieurs serveurs de l’entreprise. La technologie de réplication a considérablement évolué et
permet maintenant de copier, déplacer les données à différents endroits et de synchroniser automatiquement les
données. La réplication peut être mise en œ uvre entre des bases de données résidant sur le même serveur ou sur des
serveurs différents. Les serveurs peuvent être sur un réseau local (LAN), réseau global (WAN) ou sur Internet.
SQL Server distingue deux grandes catégories de réplication :
● la réplication de serveur à serveur,
● la réplication de serveur à clients.
Dans le cas de la réplication de serveur à serveur, la réplication permet une meilleure intégration ou rapprochement
des données entre plusieurs serveurs de base de données. L’objectif de ce type de réplication est d’effectuer un
échange d’informations entre des serveurs de base de données. Les utilisateurs qui travaillent sur les bases qui
participent à la réplication peuvent ainsi consulter des données de meilleure qualité.
La réplication de serveur à clients concerne principalement les utilisateurs déconnectés du réseau de l’entreprise et qui
souhaitent travailler avec tout ou partie des données de l’entreprise. Les utilisateurs travaillent avec une application
spécifique et utilisent SQL Server comme serveur de base de données local. Lorsqu’il se connecte sur le réseau, la
synchronisation des données entre leur poste et l’instance SQL Server centrale est prise en compte par le mécanisme
de réplication de SQL Server.
La gestion de la réplication a été simplifiée pour permettre une mise en place et une maintenance plus facile. Pour les
solutions les plus complexes et qui nécessitent une intégration complète à un logiciel, SQL Server propose l’API RMO
(Replication Management Object). Cette API permet de manipuler par programmation tous les éléments de la réplication.
L’API RMO est disponible pour les langages s’appuyant sur le framework.Net.
La notion de schéma qui permet un regroupement logique des objets dans la base est prise en compte par la
réplication avec la possibilité de réaliser des changements de schémas.

Les besoins pour la réplication
La réplication est une technologie complexe et il ne peut exister une solution unique pour couvrir tous les besoins. SQL
Server propose différentes technologies de réplication qu’il est possible d’adapter et de combiner pour répondre le plus
exactement possible aux besoins des applications. Chaque technologie présente ses avantages et ses inconvénients.
Les trois critères principaux pour sélectionner une technologie de réplication sont :
● la cohérence des données répliquées,
● l’autonomie des sites,
● le partitionnement des données pour éviter les conflits.
Il n’est pas possible d’optimiser les trois critères simultanément. Ainsi une solution qui favorisera la cohérence des
données devra laisser une faible autonomie aux sites afin de connaître à chaque instant l’ensemble des modifications
qui ont lieu sur les données.
1. Cohérence des données répliquées
Il existe deux principaux types de cohérence :
● l’homogénéité des transactions
● la convergence des données.
La cohérence des opérations distribuées telle que la réplication est beaucoup plus difficile à maintenir comparée à la
cohérence des transactions locales dont il suffit de respecter le test ACID (Atomicité, Cohérence, Isolement et
Durabilité).
L’homogénéité des transactions dans la réplication impose que les données soient identiques sur tous les sites
participant à la réplication, comme si la transaction avait été exécutée sur tous les sites.
La convergence des données quant à elle signifie que tous les sites participant aux réplications tendent à posséder le
même jeu de données qui n’est pas nécessairement celui obtenu si toutes les réplications s’étaient déroulées sur le
même serveur.
a. Cohérence des transactions
Dans tous les cas, les sites contiennent un jeu de valeurs identique à celui sur lequel toutes les opérations de
modification ont été ou auraient pu être effectuées.
Cohérence transactionnelle immédiate
Avec une telle cohérence tous les sites participant à la réplication ont la garantie de toujours voir les mêmes valeurs
au même moment. Pour assurer la cohérence transactionnelle, SQL Server dispose d’un protocole de validation à
deux phases avec tous les sites participants. Les modifications sont effectuées sur tous les sites ou sur aucun. Une
telle solution est bien sûr limitée dans la réalité, car les problèmes du réseau interdisent toute validation de
transaction tant que le serveur n’est pas reconnecté au réseau.

Dans l’exemple cidessus, le client effectue une transaction sur le serveur auquel il est connecté. Cette transaction
ne sera validée que si elle a pu être exécutée avec succès sur tous les serveurs qui participent à la réplication.
Cohérence transactionnelle latente
La cohérence latente des transactions garantit que tous les participants obtiendront les mêmes valeurs que celles
contenues sur le site de publication à un instant donné. Un délai peut s’écouler entre l’instant où la transaction est
jouée sur le serveur de publication et l’instant où les modifications sont réfléchies sur les autres sites.
Dans cet exemple, le client envoie une transaction au serveur, elle est immédiatement exécutée localement. Puis sur
une base de temps régulière, les serveurs participant à la réplication, rejouent localement l’ensemble des
transactions effectuées sur le serveur principal.

b. Convergence des données
Avec un tel processus, tous les sites finissent par obtenir le même jeu de données, ce qui n’aurait peutêtre pas pu
être obtenu si toutes les modifications avaient été jouées sur un seul serveur. Tous les sites évoluent librement et
indépendamment les uns des autres. La convergence des données est mise en place à l’aide de la réplication de
fusion qui tend à amener tous les sites qui y participent vers la gestion du même jeu de données.
Tous les serveurs sont accessibles en lecture/écriture, les transactions sont exécutées localement, puis le processus
de réplication rejoue les transactions sur les autres serveurs en tenant compte des modifications qui ont pu
intervenir localement.
2. Autonomies des sites
L’autonomie des sites est mesurée par l’impact que possède une opération effectuée sur un site sur les autres sites.
L’autonomie est parfaite lorsqu’un site peut évoluer totalement librement. Le site autonome ne se soucie pas des
opérations qui peuvent intervenir sur les autres sites. Par exemple, lorsque la réplication garantit la convergence des
données, l’autonomie des sites est à son maximum, car chaque serveur SQL peut évoluer librement par rapport aux
autres sites. À l’inverse, la cohérence transactionnelle immédiate impose une autonomie quasiment nulle des sites qui
y participent car une transaction doit être approuvée par tout le monde avant d’être validée. Si un seul serveur ne
peut pas alors la transaction n’est validée nulle part.
3. Partitionnement des données
Il est possible de répartir les données sur plusieurs sites afin que chaque site travaille avec son propre jeu de
données, rigoureusement distincts les uns des autres. Ainsi, les transactions intervenant sur chaque site ne mettent
en jeu que les données du site et la cohérence globale est conservée. Si par exemple, chaque agence possède un
fichier client sur une zone géographique bien déterminée, un client ne peut alors être géré que par une seule agence
et toute source de conflit est alors exclue.
Le partitionnement des données permet d’éviter tout conflit de données, ce qui est préférable car la résolution des
conflits est un processus lourd, qui demande beaucoup de temps machine. Plus les conflits sont nombreux, plus la
situation est difficile à gérer.
Le partitionnement des données permet de fonctionner avec une cohérence des données latente car chaque site ne
modifie que son propre jeu de données. L’application de cette cohérence est moins lourde à mettre en œ uvre que la
cohérence transactionnelle immédiate qui repose sur un processus de validation à deux phases.

Ce type de partitionnement n’est pas à confondre avec le partitionnement de tables. Dans le cadre de la
réplication, c’est une partition logique qui est définie, alors que dans le cadre d’une table partitionnée, c’est
une partition physique de la table qui est définie.
Exemples :
Exemple de partitionnement horizontal
Des billets de spectacles sont vendus en plusieurs points de vente. Afin que la même place ne soit pas vendue deux
fois, l’opération la plus simple à mettre en œ uvre consiste à attribuer pour chaque point de vente un certain nombre
de places. La salle est donc partitionnée en fonction des points de vente. Par la suite chaque point de vente gère de
façon autonome les places qui lui ont été attribuées. Par contre chaque point de vente peut connaître les places non
encore vendues par les autres, ici la cohérence transactionnelle latente suffit amplement.

Exemple de partitionnement vertical
Chaque point de vente d’une chaîne de magasins de réparation automobile gère son propre stock de marchandises et
par le biais de l’informatique connaît le stock des points de vente qui lui sont le plus proches. La connaissance de ce
stock sera utilisée lorsqu’une pièce est manquante et qu’il faut satisfaire le client au plus vite. Ici encore, la cohérence
transactionnelle immédiate n’est pas nécessaire car c’est une connaissance générale du stock voisin (accessible
uniquement en lecture) qui est demandée.
4. Types de réplication
Il existe trois types de réplication fournis par SQL Server :
● Capture instantanée,
● Transactionnelle : capture instantanée puis mise à jour immédiate des abonnés,
● Fusion.
Chacun des types de réplication répond à un besoin bien précis. Suivant la méthode choisie, soit les données
convergent, soit la cohérence des transactions est garantie.

Toutes les méthodes de réplication fournissent des fonctions et des attributs pour gérer aussi bien la cohérence des
données que l’autonomie des sites. La gestion du partitionnement est laissée sous l’entière responsabilité du
programmeur et aucune méthode de réplication ne touche à ce critère.
Il est important de signaler qu’une même application peut mettre en œ uvre simultanément, mais sur des données
différentes plusieurs modes de réplication. Toutes les données ne nécessitent sans doute pas la cohérence
transactionnelle immédiate, parfois une cohérence transactionnelle latente suffit largement, et pour certaines valeurs il
peut être opportun de mettre en place une réplication de fusion afin que les bases tendent à gérer le même jeu de
données.
Le type de réplication choisi sera fonction des exigences en terme de cohérence des données, d’autonomie des sites
mais aussi en tenant compte des ressources matérielles telles que la capacité du réseau, ce dernier étant fortement
utilisé lors d’une cohérence transactionnelle immédiate.

Les modèles de la réplication
Dans SQL Server, les différents modèles de réplication utilisent la métaphore "EditeurAbonné" afin de concevoir au
mieux les modèles de réplication.
1. Les principaux composants
a. L’Editeur
Comme un éditeur de livres ou de journaux, un serveur Editeur met à la disposition des autres serveurs des
données pour mettre en œ uvre la réplication. L’éditeur conserve toute les données publiées (celles qui participent à
la réplication) et tient à jour les modifications intervenues sur ces données. Pour les données publiées, l’éditeur est
toujours unique.
b. Le Distributeur
Il s’agit du serveur SQL qui contient la base de distribution, c’estàdire celle qui contient toutes les informations
utilisées par les abonnés pour tenir à jour les données qu’ils contiennent.
Ces deux rôles peuvent être tenus par la même machine.
c. Les Abonnés
Ce sont les serveurs SQL qui stockent une copie des informations publiées puis reçoivent les mises à jour de ces
données. Dans les versions 6.x de SQL Server, il n’était pas possible de modifier les données sur les abonnés. Il est
maintenant possible de modifier les données publiées sur l’abonné. Un abonné peut devenir éditeur pour d’autres
abonnés.
Comme pour un magazine, les abonnés doivent passer des abonnements pour recevoir des données publiées. Il
existe deux types d’abonnement :

Abonnement envoyé
Dans un tel cas, c’est le distributeur qui se charge d’envoyer la mise à jour des données distribuées à tous les
abonnés. Ce type d’abonnement est particulièrement bien adapté lorsque le temps de mise à jour des abonnés doit
être réduit au minimum.
Avec les abonnements envoyés, les abonnés peuvent ne pas être des bases SQL Server mais Oracle par
exemple.
Abonnement extrait
C’est l’abonné qui décide de souscrire ou non un abonnement. C’est par la suite l’abonné qui va demander
régulièrement des mises à jour. Ce type d’abonnement convient bien lorsque les abonnés sont très nombreux, car
la charge de travail serait trop importante pour le serveur Distributeur. Les abonnements extraits sont également
bien adaptés aux utilisateurs nomades, car lorsque l’utilisateur vient se reconnecter au réseau de l’entreprise, c’est
son propre serveur qui demande la mise à jour de ses données.
d. Les Agents
Pour fonctionner correctement, la réplication nécessite que certains programmes s’exécutent de façon récurrente.
Ces programmes portent le nom d’agent et leur exécution répétitive est possible car ils apparaissent sous forme de
tâche planifiée. Les agents de réplication fonctionnent donc sous le contrôle de SQL Server Agent.
Les agents de réplication sont :
● L’agent de capture instantanée : son rôle est de fournir une image exacte de la base répliquée à un
instant précis. Cette image prend en compte les structures et les données. La totalité de cette capture est
stockée dans des fichiers de capture instantanée et des informations de synchronisation sont stockées
dans la base de distribution. Cet agent s’exécute sur le distributeur.
● L’agent de lecture du journal : cet agent, actif uniquement dans le cadre de la réplication transactionnelle,
scrute le journal de base de données à laquelle il est attaché et copie les transactions qui concernent la
réplication vers la base de distribution. Si des réplications transactionnelles sont définies sur plusieurs
bases, alors chacune d’entre elle possède son propre agent de lecture du journal. Cet agent s’exécute sur
le distributeur.
● L’agent de distribution : exécuté sur le serveur de distribution (abonnement poussé) ou bien sur l’abonné
(abonnement extrait), l’agent de distribution a en charge d’appliquer la capture instantanée et les
transactions enregistrées dans la base de distribution. Chaque abonné dispose d’une instance spécifique
de l’agent de distribution.

● L’agent de fusion : spécifique à la réplication de fusion, il se charge tout d’abord d’appliquer la capture
instantanée sur l’abonné. Par la suite, il se connecte au serveur de publication et à l’abonné pour
rapprocher les informations. Par défaut, il télécharge les modifications de l’abonné sur le serveur de
publication, puis il reporte sur l’abonné les modifications intervenues sur le serveur de publication. Chaque
abonné à une réplication de fusion possède son propre agent de fusion.
● L’agent de lecture de la file d’attente : spécifique à la réplication transactionnelle avec l’option de mise à
jour en attente, cet agent s’exécute sur le serveur de distribution. Il n’en existe qu’une seule instance quel
que soit le nombre d’abonnés. L’agent de lecture de la file d’attente, va reporter les modifications
effectuées au niveau des abonnés sur le serveur de publication.
Les agents de réplications sont gérés soit par SQL Server Management Studio, soit par le moniteur de réplication de
SQL Server.
2. Réplication de capture instantanée
Cette réplication consiste à prendre une image instantanée des données publiées dans la base. Ce type de
réplication demande une surcharge de travail peu importante pour le serveur éditeur car l’opération est ponctuelle.
Les abonnés sont mis à jour en recopiant la totalité des données publiées plutôt que d’effectuer uniquement les
modifications (INSERT, UPDATE et DELETE) qui sont intervenues. Cette réplication convient bien pour des publications
de petit volume sinon les mises à jours des abonnés peuvent nécessiter des ressources réseau importantes.
Cette réplication est également bien adaptée dans le cas de diffusion d’un grand volume d’informations mises à jour
de façon ponctuelle et globale. C’est par exemple le cas d’un catalogue de produits édité par un fournisseur. Ce
catalogue est important et il est mis à jour (changement de tarifs, modification de description, ajouts de nouveaux
produits, suppression d’anciens produits) de façon globale et ponctuelle (par exemple deux fois par an). La diffusion
de ces nombreux changements est plus rapide par une capture instantanée.
Cette réplication est la plus simple et elle garantit une cohérence transactionnelle latente.
La réplication de capture instantanée est souvent utilisée lorsque les abonnés ont besoin d’accéder aux informations
uniquement en lecture et qu’ils n’ont pas besoin de connaître les informations en temps réel.
C’est l’agent de capture instantané qui se charge d’effectuer le travail pour préparer les fichiers contenant les
schémas et les données des tables publiées. Ces fichiers sont stockés sur le distributeur.
Chaque fois que l’agent de capture instantané s’exécute, il commence par vérifier s’il existe de nouveaux
abonnements. Si ce n’est pas le cas, alors aucun script, ni aucun fichier de données, n’est généré.
Si la publication est créée avec l’option de création immédiate d’une première capture instantanée, alors de nouveaux
fichiers de données et de nouveaux schémas sont créés chaque fois que l’agent de capture instantané s’exécute.

Tous les fichiers et les schémas sont stockés dans le dossier de capture instantanée, puis l’agent de distribution ou
de fusion transfert vers l’abonné, à moins de décider de réaliser cette étape manuellement.
L’agent de capture instantanée ajoute des informations dans la tableMSrepl_commands pour indiquer
l’emplacement du jeu de synchronisation, et dans la table MSrepl_transactionspour préciser la tâche de
synchronisation de l’abonné. Ces deux tables se situent dans la base de données de distribution.
La procédure sp_replcmds permet de connaître la liste des commandes pour les transactions marquées pour
la réplication.
La capture instantanée est le point de départ de la réplication.

Les scripts correspondant à cette capture instantanée sont normalement stockés sur le distributeur. Il est possible
de définir un autre emplacement en plus ou à la place de l’emplacement par défaut afin de réduire la charge de travail
du distributeur. Cet autre emplacement peut correspondre à un répertoire partagé sur un autre serveur ou bien à un
support amovible tel qu’un CDRom. Ce dernier type de support peut être très appréciable dans le cas de la
réplication d’une base de données volumineuse, afin de ne pas surcharger le réseau. Cet autre emplacement est
conservé comme une propriété de la publication.
Avec ce type de réplication, la base de données de distribution n’est pas utilisée et ne contient aucune donnée
utilisateur.
Selon la configuration de la réplication pour laquelle la capture instantanée est effectuée, les fichiers générés ne
seront pas les mêmes.
Si la capture instantanée concerne une réplication transactionnelle ou une réplication de fusion sans publication avec
filtre paramétré, alors la capture instantanée contient la structure et les données dans des fichiers au format bcp
(copie par bloc).
Dans le cas contraire (réplication de fusion avec une publication qui possède un filtre paramétré), alors la capture
instantanée est réalisée en deux temps. Tout d’abord, la structure est capturée, puis les données sont capturées
pour chaque abonné à la fusion afin de tenir compte du filtrage particulier des données.
3. Réplication transactionnelle
Elle peut être utilisée pour répliquer des tables (intégralement ou partiellement) et des procédures stockées.
Les réplications transactionnelles utilisent le journal pour connaître les modifications apportées aux données
publiées. Ces modifications sont stockées tout d’abord sur la base de distribution avant d’être envoyées sur les
abonnés.
Toutes les publications possèdent un éditeur. Les modifications apportées à l’éditeur sont recopiées dans la base de
distribution avec un laps de temps plus ou moins long. Dans un environnement où les connexions sont optimales, le
temps de latence entre l’éditeur et les abonnés peut être très faible.
Cette réplication fonctionne aussi bien avec des abonnements envoyés que des abonnements extraits.

La réplication transactionnelle est toujours mise en œ uvre suite à une capture instantanée afin que tous les
abonnés partent sur la même base d’information.
En fonction du type de publication, la réplication transactionnelle peut permettre la mise à jour des informations
directement sur les abonnés avec un report de la transaction sur le serveur afin de la diffuser vers les autres
abonnés dans le cadre classique de la réplication transactionnelle.
4. Réplication de fusion
Il s’agit ici de surveiller les modifications d’une base de données source et de synchroniser les valeurs entre l’éditeur
et les abonnés. Ces derniers peuvent tous effectuer des opérations de mise à jour sur les données distribuées. Si
l’éditeur conserve la maîtrise de la publication, ce n’est pas toujours les opérations effectuées sur l’éditeur qui
prennent le pas sur celles effectuées sur l’abonné. Toutes les modifications apportées à la base cible sont reportées
dans la base source.
Toutes les tables qui participent à une publication de fusion possèdent une colonne unique identifier avec la propriété
ROWGUIDCOL. Dans le cas contraire, une colonne rowguid est ajoutée automatiquement.
La réplication de fusion ne commence pas toujours par une capture instantanée.

5. Les modèles physiques de réplication
Tous les modèles physiques présentés ciaprès sont indépendants du type de réplication choisi. De plus leur
présentation repose entièrement sur la métaphore "éditeur/distributeur/ abonné".
a. Editeur centralabonnés multiples
C’est le modèle par défaut dans SQL Server. Le serveur éditeur joue également le rôle de distributeur. L’éditeur et
le distributeur peuvent s’exécuter sur deux serveurs différents. Il est également possible d’utiliser le même
distributeur pour plusieurs éditeurs.
Le serveur de publication (l’éditeur) est le propriétaire de toutes les données répliquées. Le serveur de distribution
stocke les données en attendant qu’elles soient envoyées sur les abonnés. Les données reçues sur les abonnés
doivent être accessibles en lecture seule : tous les utilisateurs ne possèdent que la permission SELECT.

Si le serveur et le distributeur sont sur deux machines distinctes, la plus grosse partie du travail de
réplication est prise en charge par le distributeur.
b. Abonné centraléditeurs multiples
Dans ce cas, plusieurs éditeurs répliquent les données vers un abonné central. L’abonné centralise les informations
de tous les éditeurs. Il possède une vue globale de la situation tandis que chaque éditeur possède une vue locale
de l’information. Étant donné que plusieurs éditeurs vont inscrire de l’information dans la même table
d’abonnement, afin d’éviter la perte d’information, il est important que chaque donnée soit clairement possédée par
un seul éditeur. Le moyen le plus simple à mettre en œ uvre est un filtrage horizontal des données.
Exemple :
Ce mode de réplication peut être mis en œ uvre par une entreprise qui souhaite être au courant des opérations
menées sur tous les points de vente.

c. Éditeurs multiplesabonnés multiples
Dans ce cas, les éditeurs sont également des abonnés multiples. Ce cas pourrait se produire par exemple entre
plusieurs points de vente travaillant indépendamment les uns des autres mais souhaitant connaître les différents
stocks des points de ventes.
Tous les modèles physiques de réplication peuvent être associés aux différents types de réplication qui existent.
Exemple :
Un loueur de ski dispose de sept magasins répartis comme suit :
● trois magasins dans la station A altitude 1800,
● deux magasins dans la station A altitude 1600,

● deux magasins dans la station B.
Le loueur habite dans le village V et souhaite connaître tous les soirs les résultats de ses différents magasins.
Afin de répondre le mieux possible aux exigences des clients, les magasins situés dans une même station et à une
même altitude connaissent tous les stocks concernant ce village et cette altitude. Quel modèle et type de réplication
fautil mettre en place ?
Une réplication transactionnelle sans autoriser les mises à jour sur les abonnés va être mise en place dans chaque
station, puis chaque magasin va mettre en place une réplication transactionnelle vers le serveur utilisé par le
loueur.

Planification
La mise en place de la réplication nécessite une planification rigoureuse des tâches à mener afin d’utiliser au mieux les
ressources fournies par SQL Server tout en réduisant les ressources matérielles (temps UC, réseau) utilisées par la
réplication.
1. Options générales de planification
a. Option NOT FOR REPLICATION
L’option NOT FOR REPLICATION permet de définir un comportement différent des options lorsque le traitement est
fait dans le cadre de la réplication. Cette option est positionnable sur :
● les colonnes de types identity,
● les contraintes de validation (CHECK),
● les contraintes de clé étrangère (FOREIGN KEY),
● les déclencheurs de base de données.
b. Type de données uniqueidentifier
Le type de données uniqueidentifier est utilisé avec la colonne ID et avec la fonction NEWID() qui permet de
générer un nouvel ID pour chaque nouvelle ligne.
Avantages du GUID :
● le GUID est toujours unique et ainsi de nombreux conflits sont évités,
● le nombre de GUID n’est pas limité contrairement aux identités.
Cependant, cette option n’est pas intéressante lorsque les utilisateurs ne voient pas ou n’utilisent pas les valeurs
du GUID. En effet les valeurs de type uniqueidentifier présentent des inconvénients qu’il ne faut pas négliger lors
de la mise en place d’une application.
● la manipulation par un utilisateur est difficile (format trop long),
● les valeurs sont aléatoires et ne possèdent aucune signification,
● les valeurs uniqueidentifier ne sont pas nécessairement disponibles pour les applications existantes qui
sont construites à partir de valeurs d’identificateurs incrémentielles.
En résumé, il est possible de préciser que les valeurs de type uniqueidentifier sont bien adaptées lorsqu’elles sont
utilisées directement par SQL Server ou bien par l’application, car elles permettent de manipuler un identifiant
unique mais leur manipulation par l’utilisateur final est malaisée. Ces valeurs sont notamment utilisées dans le
processus de réplication pour le stockage interne d’informations.
c. Filtrage des données
Par défaut lorsqu’une table participe à une publication, l’intégralité des données qu’elle contient est répliquée sur
les postes distants. Cependant, les postes distants n’ont pas forcément besoin de connaître l’intégralité des
valeurs, ils ne sont parfois intéressés que par un sousensemble de lignes et ou de colonnes. On parlera alors de
filtrage.
La filtrage permet de réduire le volume des données publiées et par ce fait, la réplication réclame moins de
ressources au niveau des serveurs la mettant en œ uvre (temps UC, espace disque...) et au niveau du réseau car le
volume d’information à transmettre à chaque abonné est moindre.

Filtrage horizontal
Il s’agit dans ce cas de publier un sousensemble des lignes contenues dans la table publiée. L’abonné ne recevra
que les lignes de la table de l’éditeur qui contiennent de l’information le concernant.
Cependant le filtrage horizontal présente quelques inconvénients. Dans le cas d’une réplication transactionnelle, la
clause de filtrage doit être évaluée pour chaque ligne journalisée concernant la publication. Si l’évaluation est
positive, alors l’information est transmise au distributeur, sinon il ne se passe rien. Cette surcharge de travail est
assurée par l’éditeur. Le coût de cette charge supplémentaire de travail sur le serveur doit être largement
compensé par les gains sur les abonnés et l’allègement du trafic réseau. Si ce n’est pas le cas, il est préférable
d’éviter un filtrage horizontal.
Filtrage vertical
Il s’agit dans ce cas de publier uniquement certaines colonnes de la table qui participe à la publication. Ce filtrage
possède une influence directe sur la structure de la table générée sur l’abonné qui est différente de la table sur
l’éditeur.
Contrairement au filtrage horizontal, le filtrage vertical ne va pas affecter de façon significative les performances de
l’éditeur car la charge supplémentaire de travail est très faible.
Filtrage mixte
Il est bien sûr possible de combiner un filtrage horizontal et un filtrage vertical sur une même table.
2. Réplication de capture instantanée
Il existe deux critères à prendre en compte afin que cette réplication se déroule correctement.
Planification rigoureuse des captures instantanées
C’est l’agent de capture instantanée qui se charge de mener à bien la capture instantanée de la publication. Lors de
l’exécution de son travail, l’agent verrouille la table et effectue une copie en bloc des données. Tant que la table est
verrouillée par l’agent, aucun autre utilisateur ne peut accéder en modification (INSERT, UPDATE, DELETE) aux
données qu’elle contient. Afin de réduire la nondisponibilité de la table visàvis des utilisateurs, la capture
instantanée doit s’exécuter à un moment où les utilisateurs ne cherchent pas à modifier les valeurs de la table.
Pour planifier au mieux l’exécution de la capture instantanée, il faut connaître la durée approximative du temps
nécessaire pour réaliser la capture. Comme l’agent de capture utilise bcp, le plus simple est de faire une copie par
blocs des tables publiées afin d’estimer le temps requis. Si le jeu de données est très volumineux, il est plus simple
de faire un bcp sur un échantillon puis d’évaluer le temps global.
Espace disque pour le dossier de capture
Le résultat de la capture instantanée est stocké, sous forme de fichiers, sur le distributeur dans un répertoire
partagé. Comme les fichiers contiennent toutes les données présentes dans la table, sa taille sera proche de celle de
la table et il est ainsi facile de connaître l’espace disque réclamé par les fichiers de capture instantanée.
Les fichiers de capture instantanée sont stockés par défaut dans un dossier local, généralement dédié à
l’hébergement des fichiers de capture installés, du type : C:\Program Files\Microsoft SQL
Server\MSSQL1O.MSSQLSERVER\MSSQL\ReplData
L’agent de capture instantanée doit disposer des privilèges suffisant pour écrire dans ce dossier. Par contre, le
compte Windows associé à l’agent de fusion et de réplication doit disposer des privilèges de lecture.
3. Réplication transactionnelle
Cette foisci quatre éléments sont à prendre en compte.
Il ne faut pas oublier que la mise en route d’une réplication transactionnelle commence toujours par une
capture instantanée.
Espace du journal
L’agent de lecture du journal scrute le journal de la base publiée et transfère toutes les transactions sur les données
publiées vers la base de distribution. La taille réclamée par le journal est en règle générale légèrement supérieure à
celle d’une base ne supportant pas la réplication. En effet si la base de distribution n’est pas accessible ou si l’agent

de lecture du journal est désactivé, le journal ne peut pas être vidé tant que la transaction la plus ancienne
concernant la réplication n’a pas été transférée vers la base de distribution.
La base de données Distribution
Sur le distributeur, la base de distribution permet de stocker et de transmettre aux abonnés toutes les informations
nécessaires afin de mettre à jour les données répliquées. La première opération réalisée sur l’abonné est la capture
instantanée de la publication. Cette opération de capture instantanée est toujours gérée sous forme de fichiers
stockés en dehors de la base de distribution.
La base de données de distribution va conserver toutes les opérations de modifications des données répliquées
depuis la dernière capture instantanée. Ainsi, si un nouvel abonné arrive, il sera possible de mettre à jour les tables
contenant les données publiées à partir de la capture instantanée présente sur les serveurs de distribution puis en
rejouant toutes les transactions dont la base de distribution conserve une trace.
Afin que la base de distribution conserve une taille raisonnable, il est prudent de planifier régulièrement une nouvelle
capture instantanée. Le travail de nettoyage de la base de distribution commence dès que la nouvelle capture
instantanée est terminée.
Les clés primaires
La gestion des clés primaires est assurée si toutes les tables participant à la réplication en possèdent une. Il est
possible de mettre en place une clé primaire sur une table existante à l’aide de la commande ALTER TABLE ou bien en
utilisant SQL Server Management Studio.
Les types text et image
Les données de texte de grande dimension et d’image sont prises en charge par la réplication transactionnelle.
Pour se prémunir de tous problèmes, il est important de se rappeler que la réplication transactionnelle s’appuie sur le
journal des transactions par l’intermédiaire de l’agent de surveillance du journal et donc seules les opérations
journalisées peuvent être prises en compte dans le processus de réplication.
Le paramètre du serveur max text repl size permet de spécifier la taille maximale (en octets) des données
text ou image pouvant être répliquées. Si une commande dépasse cette limite alors l’opération échoue.
4. Réplication de fusion
Colonnes timestamp
La réplication de fusion ne prend pas en charge les colonnes de type timestamp (estampille de temps), car ces
colonnes sont générées automatiquement par le serveur local et ne garantissent l’unicité qu’au sein d’une base de
données spécifique. Il n’est donc pas possible qu’une modification de la valeur timestamp sur un serveur soit
appliquée à la colonne timestamp d’un autre serveur. C’est pourquoi les colonnes de type timestamp doivent être
supprimées de toutes les tables participant à la réplication de fusion.
Intégrité des données
Comme la réplication de fusion publie les modifications intervenues sur l’abonné, la base de ce dernier doit permettre
de garantir l’intégrité des données et donc la totalité des tables nécessaires pour garantir l’intégrité des données
doit être présente sur l’abonné.
Références de clé primaire
Si les tables qui participent à la réplication comportent des contraintes de références, alors les tables référencées
doivent également participer à la publication. Ce serait par exemple la cas d’une table commandes qui référence la
clé primaire de la table clients. Cette dernière table ne doit participer à la réplication de fusion que pour autoriser la
création de commandes sur l’abonné. Si l’abonné se contente de modifier des renseignements contenus dans la table
commandes sans toucher la colonne qui référence le client, alors la présence de la table clients n’est pas nécessaire.
Dans une réplication de fusion, il est possible de rajouter manuellement de nouvelles tables à tout moment.

L’accès au réseau
Afin que le processus de réplication se déroule sans encombre, certaines conditions élémentaires doivent être
satisfaites sur l’accès au réseau :
● si les serveurs SQL participant à la réplication se situent dans des domaines différents, des relations
d’approbation doivent être établies entre ces domaines.
● l’agent SQL Server doit s’exécuter dans le contexte d’un compte d’utilisateur du domaine. Si possible, l’agent
SQL Server des différents serveurs SQL participant à la réplication utilise toujours le même compte d’utilisateur.
Ce compte d’utilisateur du domaine doit être membre du groupe local Administrateurs afin de faire profiter des
privilèges administratifs au service SQLServerAgent.
Il est possible de connaître et de modifier la configuration de ce service par SQL Server Configuration Manager.
Vérification des propriétés de l’agent SQL Server
L’agent SQL Server ne doit utiliser ni un compte local system ni un compte d’utilisateur local, car ces deux
comptes ne permettent pas d’accéder aux ressources du réseau.

Mise en œuvre
Quels que soient le modèle et le type de réplication choisis, la mise en œ uvre doit toujours respecter les même
étapes :
● la mise en œ uvre du distributeur,
● la mise en œ uvre de l’éditeur,
● la mise en œ uvre des abonnés,
● la définition des publications.
Comme SQL Server considère par défaut que l’éditeur et le distributeur résident sur le même serveur, l’installation de
ces deux états est confondue.
Pour pouvoir mettre en œ uvre la réplication à partir de SQL Server Management Studio, tous les serveurs SQL qui y
participent doivent y être inscrits.
SQL Server Management Studio propose différents assistants graphiques pour mettre en place, surveiller et
paramétrer l’environnement de réplication. Tous ces éléments sont accessibles depuis le nœ ud Réplication de
l’explorateur d’objets de SQL Server Managemment Studio.
1. Le distributeur
Il s’agit du poste qui va gérer le répertoire partagé pour la capture instantanée ainsi que la base de distribution. Le
distributeur stocke les modifications effectuées sur les données puis les transmet aux abonnés.
a. Les concepts
Le distributeur doit être installé avant de mettre en place les éditeurs qui l’utilisent. Pour créer un distributeur, il
faut être administrateur du système (membre du groupe local Administrateurs et par le biais des connexions
approuvées se connecter à SQL Server en tant qu’administrateur). Lorsque le distributeur est installé, il est possible
de connaître ses propriétés locales et distantes.
La base distribution

Elle contient toutes les transactions qui sont en attente d’envoi vers les abonnés. Dans le cadre d’une réplication
transactionnelle elle est alimentée par l’agent de surveillance du journal qui y transfère toutes les transactions qui
interviennent sur des données répliquées. Cette base est automatiquement créée lors de la configuration du
distributeur, mais il est possible de :
● spécifier un serveur de distribution distant lors de l’installation de l’éditeur,
● définir plusieurs bases de distribution pour un même éditeur.
Accès au répertoire partagé
Le répertoire de distribution, utilisé par la réplication de capture instantanée, doit être disponible pour tous les
agents de distribution qui sont susceptibles de l’utiliser. Cette utilisation est fonction du type de réplication mis en
œ uvre et ne se pose que lors de l’utilisation d’un serveur de distribution distant.
La mémoire
La mémoire vive présente sur le distributeur doit être en quantité suffisante afin de répondre promptement aux
différentes demandes des abonnés. La quantité de mémoire nécessaire est fonction du volume des données
répliquées et du nombre d’abonnés.
La désinstallation
Il est possible de désinstaller un distributeur par le biais de l’assistant Réplication, Désactiver l’assistant
Publication et Distribution. Les effets sont les suivants :
● les bases de données distribution du serveur sont supprimées,
● tous les éditeurs qui utilisent ce distributeur sont désactivés et toutes les publications sont supprimées,
● tous les abonnements sont supprimés, mais les données d’abonnement restent sur les abonnés.
b. La mise en place
La mise en place d’un distributeur demande des privilèges d’administrateur, c’estàdire être membre du rôle de
serveur sysadmin. La création du distributeur se fera soit par le biais des procédures stockées, soit par le biais de
SQL Server Management Studio.
La configuration du distributeur est accessible par deux chemins différents dans SQL Server Management Studio.
● Soit en sélectionnant explicitement le choixConfigurer la distribution dans le menu contextuel associé au

nœ ud Réplication depuis l’explorateur d’objets.
● Soit en demandant la création d’une nouvelle publication (choix Nouveau Publication) depuis le menu
contextuel associé au nœ ud Réplication. L’assistant de création d’une publication est alors exécuté et cet
assistant permet de sélectionner/configurer un distributeur pour la réplication.

L’assistant de publication se propose de créer un distributeur
Dans le cas où la demande porte sur la configuration de la distribution, l’assistant de configuration de la distribution
est exécuté. Cet assistant va tout d’abord demander de préciser le serveur qui va jouer le rôle de distributeur. Il est
alors possible de sélectionner le serveur qui hébergera également les publications (éditeur/distributeur) ou bien de
sélectionner un distributeur distant.
À l’étape suivante, l’assistant permet de spécifier le dossier utilisé pour les fichiers de capture instantanée. Un
dossier local est proposé par défaut. Si la réplication de capture instantanée doit être accessible depuis le réseau, il
est nécessaire de préciser un nom de chemin réseau. L’avertissement situé en bas de la fenêtre porte précisément
sur ce point.

Puis l’assistant permet de préciser le nom de la base de distribution ainsi que l’emplacement physique du fichier de
données et du journal. Comme le montre l’écran cidessous, la base se nomme par défaut distribution et les
dossiers proposés sont ceux spécifiés par défaut.
Ensuite, l’assistant demande de préciser quels sont les éditeurs autorisés à travailler avec ce distributeur.
Enfin, l’assistant offre la possibilité soit de réaliser la paramétrage immédiatement, soit de générer les scripts
Transact SQL correspondant aux différents choix spécifiés avec l’assistant, pour une exécution ultérieure de la mise
en place du distributeur.

Tant que l’assistant n’est pas terminé, aucune modification n’est effectuée sur le serveur.
Apparition de la base de donnée distribution
Les options accessibles depuis SQL Server Management Studio sont légèrement différentes afin de pourvoir réaliser
toutes les opérations liées à l’administration du serveur de distribution. Ces nouvelles fonctionnalités sont
principalement accessibles par le menu contextuel associé au nœ ud Réplication de l’explorateur d’objets.

Le menu contextuel propose de visualiser les propriétés du serveur de distribution. Les propriétés du serveur de
distribution permettent de paramétrer la distribution en ellemême comme la durée de rétention des transactions et
celle de l’historique. Il est également possible de modifier la liste des éditeurs autorisés à utiliser ce serveur de
distribution.
Il est également possible de lancer le moniteur de réplication afin de suivre le travail effectué par chaque agent qui
participe à la réplication. Le moniteur de réplication permet de connaître l’état de chaque abonné et de suivre les
opérations de synchronisation.
Le menu contextuel offre également la possibilité de désactiver la distribution.

Toujours depuis l’explorateur d’objets, il est possible de visualiser la base de données système distribution qui a
été créée à l’aide de l’assistant.

2. L’éditeur
Après la création du distributeur, il est possible de créer un éditeur qui utilisera ce distributeur.
Un distributeur peut être commun à plusieurs éditeurs et un éditeur peut utiliser plusieurs distributeurs.
Lors de l’ajout d’un éditeur on peut :
● activer l’éditeur et l’autoriser à utiliser le distributeur.
● afficher ou modifier les options de l’éditeur.
L’ajout, la suppression et la modification d’un éditeur peuvent être réalisés de différentes façons :
C’est à partir des propriétés du distributeur qu’il est possible de gérer (ajouter/supprimer) les serveurs de publication
(éditeur) qui sont autorisés à utiliser ce distributeur.
Il est possible d’ajouter un distributeur SQL Server ou Oracle. Les procédures d’inscription étant différentes, le
bouton Ajouter propose le choix entre les deux types d’éditeur avant de les autoriser à utiliser le distributeur.
Pour supprimer l’autorisation accordée à un distributeur, il faut désactiver le serveur de publication depuis les
propriétés du serveur de distribution.
Transact SQL
Les opérations relatives à l’ajout et au retrait d’un éditeur sur le distributeur sont possibles par l’intermédiaire des
procédures :
● sp_adddistpublisher pour ajouter un nouveau serveur de publication sur le distributeur. L’utilisation de cette
procédure réclame l’exécution de la procédure sp_get_distributor afin de déterminer si l’instance de SQL
Server est configurée ou non en tant que distributeur.

● sp_dropdistpublisher pour supprimer le serveur de publication du distributeur.
Modification de la base de données de distribution
Si un éditeur change de base de distribution, cela revient à tout recommencer depuis le début soit : désactiver
l’éditeur, le supprimer de la base de données de distribution initiale, activer l’éditeur avec une autre base de données
de distribution. Sur l’éditeur, il convient de créer les publications et les articles et d’activer les abonnés qui peuvent
recevoir des données en provenance de l’éditeur via le distributeur.
3. Les publications
Il existe deux sortes de publications, celles de données et celles de procédures stockées.
Une publication, dans le cadre de la réplication SQL Server, correspond à un ensemble d’éléments (articles) qui
participent à la réplication. Suivant le type de réplication choisi, ces articles peuvent être des tables, des tables
partitionnées, des procédures stockées, des fonctions, des vues, des vues indexées, des types de données définis
par l’utilisateur.
Lorsqu’une table participe à une publication, elle est nommée article. L’article correspond à la totalité de la table ou
bien à un sousensemble de lignes ou de colonnes. Un article peut également correspondre à l’exécution d’une
procédure stockée, cependant cette fonctionnalité n’est pas disponible dans la cadre d’une réplication de fusion.
C’est lors de la création d’une publication que l’éditeur va utiliser les ressources mises à sa disposition par le
distributeur pour héberger les fichiers de capture instantanée ainsi que la copie des transactions sur la base de
distribution.
Au moment de la création d’une publication, les éléments suivants doivent donc être résolus :
● le nom de la publication et sa description,
● le serveur de distribution à utiliser,
● le type de réplication (capture instantanée, transactionnelle ou fusion) à laquelle la publication va participer,
● les articles.
Tous ces éléments vont devoir être spécifiés lors de l’exécution de l’assistant de création d’une publication.
Création et modification
La création d’une publication par le propriétaire de la base de données (ou un utilisateur membre du rôle db_owner)
n’est possible que si l’administrateur du serveur a activé la base pour participer à une réplication. Lors de cette
activation, l’administrateur précise si les publications définies sur la base peuvent s’inscrire dans une réplication
transactionnelle ou de fusion.
L’activation de la publication sur les bases est possible depuis la fenêtre présentant les propriétés du serveur de
publication. Le choix Propriétés du serveur de publication depuis le menu contextuel associé au nœ ud Réplication
de l’explorateur d’objets permet d’afficher cette fenêtre.

La base Gescom est activée pour la réplication transactionnelle
La création d’une publication est également réalisée par l’intermédiaire d’un assistant sous SQL Server Management
Studio. Pour créer une nouvelle publication, il faut sélectionner Nouvelle publication dans le menu contextuel associé
au nœ ud Réplication Publications locales de l’explorateur d’objets.
La première étape de l’assistant consiste à sélectionner la base de données qui contient le ou les objets qui vont
participer à la publication. Cette boîte de dialogue montre toutes les bases de données utilisateurs, qu’elles soient ou
non activées pour la réplication.
Dans l’exemple cidessous, seule la base Gescom est activée pour la réplication, alors que toutes les bases sont
présentes dans la fenêtre.

L’assistant demande alors de préciser le type de réplication à laquelle cette publication va participer.
Dans l’exemple cidessous, la publication est définie dans le cadre d’une réplication transactionnelle, c’estàdire que
les données sont modifiées sur l’éditeur et que ces modifications sont reportées sur les abonnés par le processus de
réplication.
Le choix se porte sur une capture instantanée

Après que le type de réplication est défini, il est possible de sélectionner les éléments de la base qui participent à
cette publication, c’estàdire définir les articles.
Dans l’exemple cidessous, la publication va compter un seul article : la table des clients.
Choix des articles à publier
Seules les tables qui possèdent une clé primaire peuvent participer à une publication en tant qu’article.
Pour chaque article publié, il est intéressant d’afficher ses propriétés afin de saisir une description pour chaque article
et fixer le schéma et le nom de la table de destination.

Fixer les propriétés générales de chaque article
Les propriétés de l’article publié permettent de définir le comportement à adopter sur les index, les index XML, les
valeurs par défaut, les autorisations.
L’assistant offre ensuite la possibilité de définir des filtres pour limiter le volume de données publiées. Par exemple,
estil nécessaire de publier la totalité de la table clients ou bien fautil limiter la réplication aux seuls clients d’une
zone géographique bien définie ?

L’étape suivante permet de définir s’il est nécessaire ou non de réaliser une capture instantanée et éventuellement
de planifier la création régulière de nouvelles captures instantanées. Ce dernier point est particulièrement
intéressant lorsque le volume de données modifiées est important ou bien quand les abonnements ne sont pas tous
souscrits à la même période.
Dans l’exemple ciaprès, la création d’une capture instantanée est demandée et cette capture sera effectuée une fois
par mois.

Par la suite, l’assistant demande de spécifier les comptes de sécurité qui vont être utilisés par les agents de capture
instantanée et de lecture du journal pour se connecter au serveur.
Avant de cliquer sur Terminer pour créer la publication, l’assistant offre la possibilité de créer les scripts Transact SQL
relatifs à la création de cette nouvelle publication.
La dernière étape de l’assistant permet de nommer la publication, puis de demander sa création.
Après leur création, il est possible de visualiser et de modifier les publications depuis SQL Server Management Studio.
Il est possible par l’intermédiaire des propriétés de la publication, de modifier les choix définis lors de l’exécution de
l’assistant de création de la publication.

Les différentes publications dans Enterprise Manager
Les articles
Les articles d’une publication peuvent être de différents types. Il est possible de modifier les articles participant à une
publication par l’intermédiaire des propriétés de la publication. À ce niveau, il est facile d’ajouter, de modifier ou bien
de supprimer des articles.

4. Les abonnements
S’abonner à une publication signifie que l’abonné accepte les données répliquées sur une base de destination.
Lors de la mise en place de l’abonnement, il est nécessaire de définir le type de l’abonnement, c’estàdire poussé ou
tiré.
L’abonnement poussé signifie que l’agent de distribution est exécuté sur le serveur de distribution. Les informations
sont donc poussées depuis le serveur de distribution vers l’abonné par l’agent de distribution.
Dans le cadre de l’abonnement tiré, chaque abonné exécute son propre agent de distribution. C’est donc l’abonné qui
supporte cette charge de travail supplémentaire. L’agent de distribution va tirer les informations depuis le serveur de
distribution vers l’abonné.
Les abonnements anonymes ne sont plus disponibles depuis SQL Server 2005.
Lorsque les abonnements sont mis en place, alors intervient une étape de synchronisation afin de mettre au même
niveau l’éditeur et l’abonné, sa base de destination va recevoir le schéma et les données publiées. La base de
destination peut contenir d’autres tables.
Un abonnement ne pourra être créé que si la publication et la base de données de destination existent.
a. Utilisation des assistants
SQL Server Management Studio propose un assistant pour créer de nouveau abonnements. Il est possible de lancer
cet assistant en sélectionnant l’option Nouveaux abonnements dans le menu contextuel attache soit depuis le
nœ ud Réplication Abonnements locaux, soit associé une publication. C’est d’ailleurs cette dernière possibilité qui
est illustrée par l’écran cidessous :
Après un écran d’accueil, l’assistant demande de sélectionner la publication concernée par ce nouvel abonnement.
Dans l’exemple suivant, c’est la publication créée précédemment qui est concernée par le nouvel abonnement.

Ensuite, l’assistant demande de préciser le type de l’abonnement c’estàdire si l’abonnement sera de type poussé
(avec exécution de l’agent sur le distributeur) ou bien tiré (avec exécution de l’agent sur l’abonné). Dans l’exemple
présenté, c’est un abonnement de type poussé qui est sélectionné.
L’assistant permet ensuite de sélectionner l’abonné. Si l’abonné n’apparaît pas dans la liste proposée, il faut utiliser
le bouton Ajouter un abonné pour inscrire le serveur et ainsi avoir la possibilité de le sélectionner en tant
qu’abonné. Lors de la sélection d’un serveur abonné, il faut également spécifier la base de données destinatrice de
l’abonnement. Si la base n’existe pas, il est possible de la créer à ce niveau. Dans l’exemple cidessous, c’est une
instance différente de SQL Server qui est sélectionnée en tant qu’abonné.

Ensuite, l’assistant demande de préciser les comptes de sécurité qui seront utilisés par l’agent de distribution pour
se connecter au serveur de distribution et sur l’abonné.
Par la suite, l’assistant demande de préciser le mode d’exécution de l’agent de distribution. Dans l’exemple
présenté cidessous, l’agent est exécuté en continu de façon à reporter le plus rapidement possible les
modifications intervenues sur le serveur de publication vers les abonnés. Cependant, à l’aide d’une planification,
l’agent peut s’exécuter à une période identifiée comme étant moins chargée, comme la nuit par exemple.

Le même type de question est posé par l’assistant pour l’exécution de la capture instantanée, qui peut être
exécutée soit immédiatement, soit lors de la première synchronisation.
Comme pour la création de la publication, l’assistant donne la possibilité de générer les scripts Transact SQL
correspondants.

Puis l’assistant présente un écran de synthèse avant de terminer la création de l’abonnement.
Depuis SQL Server Management Studio, il est possible de visualiser l’ensemble des abonnements définis par rapport
à une publication mais aussi les abonnements souscrits localement par le serveur.
b. Surveiller la réplication
Le moniteur de réplication peut être lancé depuis le distributeur pour suivre le déroulement et l’exécution des
différents agents de la réplication. Ce moniteur est accessible en sélectionnant Lancer le moniteur de réplication
depuis le menu contextuel associé au nœ ud Réplication de l’explorateur d’objets de SQL Server Management
Studio.

Le menu contextuel associé à la publication permet également d’obtenir les comptes rendus d’exécution des agents
de capture instantanée et de lecture du journal.
c. Suppression
La suppression d’un abonnement empêche les nouvelles mises à jour de la base de destination, mais pour autant
cette dernière n’est pas supprimée, ni même nettoyée. Il reviendra à un administrateur du serveur de destination
de supprimer le schéma créé par la mise en place de la publication.

L’accès aux données distantes
SQL Server permet à un utilisateur connecté localement, d’exécuter une requête sur un serveur distant. Ce processus
s’appuie sur la liaison entre les serveurs. Lorsque la liaison est établie entre deux serveurs, le serveur qui réceptionne
de la part de l’un de ses utilisateurs une demande d’exécution d’une requête sur un autre serveur, transmet la requête
au serveur distant.
Dans le schéma suivant, un utilisateur connecté sur serveur1 peut demander l’exécution d’une requête sur serveur2
sans avoir à se connecter sur serveur2. En effet, comme les deux serveurs sont liés, c’est serveur1 qui se charge
d’exécuter la requête sur serveur2.
L’avantage des serveurs liés est que c’est le serveur qui prend en charge la connexion sur le serveur distant. Cette
opération est transparente pour l’utilisateur final.
Avant de pouvoir travailler avec un serveur lié, il faut l’inscrire sur le serveur local puis définir une politique de gestion
des connexions établies sur le serveur lié.
La notion de serveurs liés permet à SQL Server d’établir une relation de confiance avec des sources OLE DB qui offrent
l’avantage d’accéder aux serveurs distants, d’émettre des requêtes, des opérations de mises à jour, des commandes
et des transactions partagées sur des sources de données hétérogènes.
1. Ajouter un serveur lié
Depuis SQL Server Management Studio, il est facile de définir une nouvelle liaison avec un serveur distant en
sélectionnant l’option Nouveau serveur lié dans le menu contextuel associé au nœ ud Objets serveur Serveurs
liés de l’explorateur d’objets.
La boîte de dialogue relative à l’inscription d’un nouveau serveur lié est alors exécutée. Les trois pages de la fenêtre

permettent de configurer complètement cette liaison. Si une erreur ou un oubli est fait à cette étape, il est possible
d’y remédier en modifiant les propriétés du serveur lié.
Il est également possible de réaliser ces opérations en Transact SQL avec l’aide des procédures sp_addlinkedserver
pour ajouter un nouveau serveur lié, et sp_dropserver pour supprimer la liaison avec un serveur.
2. Gérer les utilisateurs distants
Le serveur source ne peut ouvrir une session sur le serveur cible que si ce dernier autorise les connexions distantes.
Pour ouvrir la session sur le serveur distant, le serveur source utilisera les informations de sécurité renseignées au
niveau de la liaison des serveurs.
Pour configurer le serveur cible à accepter les connexions réalisées depuis un autre serveur, il faut activer la propriété
Autoriser les accès distants à ce serveur au niveau du serveur. Cette opération est réalisée depuis la fenêtre
d’affichage des propriétés du serveur, page Connexions dans la zone Connexions au serveur distant.

Pour que le serveur d’origine puisse ouvrir une connexion sur le serveur lié, il est nécessaire de définir un mappage
entre les utilisateurs locaux et les utilisateurs distants. Ainsi, seuls certains utilisateurs locaux ont la possibilité
d’accéder aux données distantes. De plus, les opérations réalisées sur le serveur lié restent dans le contexte de
sécurité utilisé pour établir la connexion distante. Plusieurs utilisateurs locaux peuvent accéder au serveur lié en se
servant du même compte de connexion.
Depuis SQL Server Management Studio, ce mappage de compte est réalisable à partir de la fenêtre des propriétés du
serveur lié, sur la page Sécurité.
Dans l’exemple suivant, les connexions locales Adrien et Pierre sont associées à la connexion distante AccesNiveau1.
Les autres utilisateurs locaux ne peuvent pas accéder au serveur lié.

Toutes ces opérations peuvent également être réalisées en Transact SQL à l’aide des procédures stockées
sp_addlinkedsrvlogin et sp_droplinkedsrvlogin.
3. Exécution d’une requête distribuée
Les clients qui sont connectés au serveur SQL sur lequel les serveurs liés sont définis, peuvent exécuter des
requêtes qui vont interroger les différentes sources de données gérées directement par le serveur ou accessibles par
l’intermédiaire d’un serveur lié. À l’intérieur d’une même requête, il est bien sûr possible de faire appel à des données
provenant indifféremment de multiples sources de données.
Pour accéder à des données stockées sur un serveur lié, il faudra donner le nom complet des objets auxquels on
souhaite accéder.
L’accès aux données n’est possible que si le serveur lié est configuré pour permettre cet accès.

Dès que ce paramétrage est effectué, il est possible d’accéder aux informations à l’aide du nom complet des objets
c’estàdire serveur.base.schéma.objet.
Exemple de requête utilisant des données sur des serveurs liés

Les fonctions OPENQUERY et OPENROWSET permettent d’accéder à des sources de données OLE DB sans
avoir à lier les serveurs.

Introduction
La gestion des sauvegardes reste une des tâches les plus importantes qui doit être réalisée par l’administrateur de
bases de données. Si les opérations de sauvegardes sont planifiées avec exactitude et rigueur, il est tout à fait
envisageable de réaliser les sauvegardes sous forme de travaux automatisés et le responsable sera prévenu par e
mail du bon déroulement des opérations.
Les sauvegardes sont réalisées pour se prémunir des pertes de données suite à :
● une panne de support,
● des erreurs utilisateur,
● une perte permanente du serveur.
Les sauvegardes SQL Server permettent de sauvegarder la base de données alors que des utilisateurs y sont
connectés. Cette sauvegarde va prendre en compte tous les fichiers constituant la base de données et va enregistrer
leur emplacement. Le processus de sauvegarde assure la cohérence des données et des journaux en capturant toutes
les activités survenant durant le processus de sauvegarde.
Bien que la base reste accessible durant la sauvegarde, certaines opérations sont impossibles, à savoir :
● la création ou la modification d’une base de données (notamment l’extension automatique du journal des
transactions),
● la création d’un index,
● l’exécution d’opérations non journalisées car le processus de sauvegarde utilise le journal pour garantir la
cohérence des données.

Planification
La planification des opérations de sauvegarde entraîne également celle de la restauration, en effet l’une ne va pas
sans l’autre. Ce sont les exigences en matière de disponibilité des données qui vont constituer le critère déterminant
pour la mise en place des sauvegardes. Pour réaliser cette planification il faut réfléchir à tous les incidents qui peuvent
survenir et connaître quels seront les besoins en sauvegarde pour restaurer au mieux l’information. Il sera ensuite
possible d’automatiser tous ces travaux de sauvegarde, et des tests de restauration valideront le bon déroulement
des procédures de sauvegarde.
1. Les questions
Les principales questions qu’il faut se poser pour planifier au mieux les sauvegardes sont :
● Quelle est la taille de chacune des bases de données ?
● Quel est le volume des modifications de données ?
● Certaines tables sontelles plus sujettes que d’autres aux modifications ?
● Combien de temps la base de données peutelle rester indisponible ?
● La perte de modifications estelle cruciale ?
● Estil facile de recréer les données perdues ?
● Quelles sont les périodes importantes d’utilisation de la base de données ?
● La base subitelle des surcharges de travail ponctuelles pendant lesquelles il n’est pas envisageable de
lancer une sauvegarde ?
● Les utilisateurs doiventils continuer à accéder aux données pendant les opérations de sauvegarde ?
● Quel est le laps de temps entre les troncatures (suppression de la partie inactive) du journal des
transactions ?
● Les sauvegardes sontelles conservées de façon cyclique ?
● Le serveur SQL estil en cluster ?
● Le serveur SQL estil dans un environnement multiserveur avec une administration centralisée ?
La durée des opérations de sauvegarde va dépendre principalement du support sur lequel les sauvegardes sont
effectuées. Deux supports sont possibles : les bandes (à condition que le lecteur de bande soit installé sur le serveur
SQL) et les fichiers.
2. Choisir une stratégie de sauvegarde
Pour chaque base de données, il faut choisir une stratégie de sauvegarde qui va être une combinaison de
sauvegardes complètes de bases de données et de sauvegardes du journal des transactions. Pour améliorer les
performances de sauvegardes, SQL Server propose des sauvegardes différentielles. De plus, toutes ces opérations
peuvent être réalisées sur la totalité de la base ou sur un groupe de fichiers uniquement.
Une bonne connaissance des différentes méthodes de sauvegarde, permet de mettre en œ uvre le plan de
sauvegarde qui répond au mieux face aux exigences constatées lors de la planification.
La stratégie de sauvegarde doit être fixée base par base en fonction des besoins et des évolutions de
chacune d’entre elles.

a. Sauvegarde d’une base de données
La sauvegarde totale d’une base de données permet de fournir un point de départ pour les restaurations. Si
uniquement des sauvegardes complètes de base de données sont effectuées, en cas de problème, les transactions
validées depuis la dernière sauvegarde complète seront perdues.
Les sauvegardes complètes nécessitent un temps relativement long et occupent sur le support de sauvegarde un
espace conséquent. C’est pourquoi, même si elles constituent un point de départ obligatoire à toute stratégie de
sauvegarde, les sauvegardes complètes de base de données restent bien adaptées aux bases de faibles volumes
et pour lesquelles il est possible de reproduire facilement toutes les transactions qui ont eu lieu depuis la dernière
sauvegarde complète.
b. Sauvegarde du journal des transactions
En complément des sauvegardes complètes, il est toujours possible de mettre en place une politique de
sauvegarde des journaux de transactions. La sauvegarde des journaux présente deux avantages majeurs.
Il est possible de récupérer la totalité ou une grande partie des transactions validées depuis la dernière
sauvegarde complète de la base.
La taille du fichier journal ne risque pas de grandir de façon anarchique car lors de chaque sauvegarde du journal, il
est possible de demander de le tronquer. Le risque de saturer le disque suite à l’extension du fichier journal est
ainsi diminué. La sauvegarde des journaux peut être réalisée par un travail qui est planifié pour une exécution
régulière.
SQL Server génère des points de contrôle synchronisation (CHECKPOINT) automatiques. Le but de ces points de
synchronisation est de stocker sur disque l’ensemble des transactions validées pour lesquelles les modifications
sont encore en mémoire. Ainsi en cas de restauration automatique suite à un arrêt brutal du serveur le volume des
données à restaurer sera faible car il ne concernera que les données appartenant à des transactions validées
depuis le dernier point de synchronisation.
Le point de synchronisation peut être déclenché ponctuellement par l’intermédiaire de l’instruction Transact SQL
CHECKPOINT.
Syntaxe
CHECKPOINT [valeur][;]

Valeur
Précise le nombre de secondes dont dispose SQL Server pour terminer le point de synchronisation.
Exemple
Dans l’exemple suivant le point de synchronisation est réalisé dans les 5 secondes.
Le point de synchronisation peut également être réalisé de façon automatique en fonction de certains critères :
● le respect des paramètres fixés à l’aide de l’option recovery interval,
● le journal est rempli à plus de 70 % alors que la base est configurée pour tronquer le journal lors de
l’exécution des points de synchronisation,
● le moteur de base de données est arrêté, sauf si cet arrêt est demandé avec l’instruction SHUTDOWN WITH
NOWAIT.
L’option RECOVERY INTERVAL permet de définir au niveau du serveur le nombre maximal de minutes que peut
prendre une restauration automatique de la base depuis le dernier point de synchronisation. La fréquence des
points de synchronisation est fixée par SQL Server en fonction de l’activité de mise à jour sur la base. Par défaut, la
valeur de ce paramètre est 0, ce qui signifie que SQL Server gère automatiquement la fréquence des points de
synchronisation. Il est recommandé de conserver cette valeur. Cependant, si les points de synchronisation sont mal
adaptés par rapport à l’activité du serveur, il est possible de modifier la valeur de ce paramètre soit avec la
procédure sp_configure, soit depuis la fenêtre des propriétés du serveur depuis SQL Server Management Studio.
Comme l’illustre l’écran suivant, l’intervalle de récupération est fixé sur la page Paramètres de base de données.

Si la base de données utilise le mode de récupération simple, le journal n’est utilisé que lors des récupérations
automatiques, il est donc inutile de conserver les informations sur les transactions qui ont pris fin avant le dernier
point de synchronisation. Pour éviter que la taille du journal croisse de façon illimitée, SQL Server élimine la partie
inactive du journal lors de chaque point de synchronisation.
c. Les sauvegardes différentielles
Si les sauvegardes du journal sont des opérations lourdes car le volume des journaux peut rapidement devenir très
important, une alternative intéressante peut être mise en place avec les sauvegardes différentielles. Les
sauvegardes différentielles ne vont prendre en compte que les données modifiées depuis la dernière sauvegarde
complète.
Les sauvegardes différentielles sont plus rapides et moins volumineuses que les sauvegardes complètes, et
associées aux sauvegardes du journal des transactions, elles peuvent constituer une solution de sauvegarde à la
fois rapide et performante.
d. Les sauvegardes par groupe de fichiers
Si la base de données représente un volume important de données, les sauvegardes complètes et différentielles

peuvent demander un temps d’exécution très long. Pour réduire ce temps, il est possible de sauvegarder les
données par groupes de fichier. Une telle opération est bien sûr possible si lors de la création de la base, des
groupes de fichiers ont été définis.
e. Les combinaisons possibles
La bonne solution pour réaliser des sauvegardes passe par une combinaison des différentes méthodes de
sauvegarde.
Par exemple, il est possible de combiner les sauvegardes complètes, les sauvegardes du journal des transactions et
les sauvegardes différentielles pour minimiser à la fois le volume et le temps des sauvegardes, et la perte des
transactions validées. En mettant en place ces opérations sous forme de travaux planifiés avec notification en fin
d’exécution, les opérations de sauvegardes peuvent se dérouler automatiquement sans effort de la part de
l’administrateur.

Si une base s’étend sur plusieurs groupes de fichiers (primary, données...), il est alors possible de réaliser les
sauvegardes par groupes de fichiers. Pour chaque groupe de fichiers, il faut appliquer une stratégie de sauvegarde
(complète, différentielle et journaux de transactions). Il n’est pas nécessaire d’effectuer simultanément le même
type de sauvegarde sur tous les groupes de fichiers.
Dans la combinaison présentée cidessus, les trois types de sauvegarde sont utilisés. La sauvegarde complète
constitue le point de départ obligatoire. Par la suite, les journaux sont sauvegardés régulièrement afin de perdre le
minimum de données. Pour minimiser les temps de restauration, une sauvegarde différentielle est effectuée afin d’y
conserver toutes les modifications qui sont intervenues depuis la dernière sauvegarde complète.
Toutes les stratégies de sauvegarde commencent toujours par une sauvegarde complète de la base.

La mise en œuvre des sauvegardes
Les opérations de sauvegarde peuvent être mises en place soit à partir de SQL Server Management Studio, soit à l’aide
de procédures stockées en Transact SQL. Comme toujours, la solution graphique propose la facilité de mise en œ uvre
mais les commandes Transact SQL permettent quant à elles d’accéder à la totalité des options proposées.
1. Les modes de récupération
Les possibilités offertes au niveau de la sauvegarde et donc de la restauration sont directement liées au mode de
configuration défini au niveau de chaque base de données. Les trois modes de récupération qu’il est possible de
configurer sont :
● le mode de récupération simple : le journal est utilisé uniquement pour garantir la persistance des opérations
apportées sur les données. Il est tronqué lors de chaque point de synchronisation.
● le mode de récupération complet : dans ce mode, toutes les transactions sont consignées dans le journal et
y restent enregistrées même après le point de synchronisation. En cas d’échec, la perte de données est
réduite car l’opération de restauration est possible jusqu’au point de défaillance (sous réserve d’avoir adopté
la bonne politique de sauvegarde). Il s’agit du mode de récupération par défaut défini au niveau des bases de
données utilisateur.
● le mode de récupération journalisé en bloc : dans ce mode de récupération avancé, non seulement les
informations relatives aux transactions sont enregistrées dans le journal, mais également certaines opérations
affectant les données, comme la création d’index.
Pour configurer le mode de récupération, il est possible d’exécuter l’instruction ALTER DATABASE.
Syntaxe

SET RECOVERY { FULL | BULK_LOGGED | SIMPLE }
Il est également possible de modifier les propriétés de la base depuis SQL Server Management Studio. Ce dernier cas
est illustré cidessous pour configurer la base Gescom en mode de récupération complet.

2. La destination des sauvegardes
Les sauvegardes peuvent être dirigées sur différents supports : bande, disque dur.
a. Disque dur
Les sauvegardes sur disques sont réalisées à l’intérieur de fichier du système d’exploitation. La sauvegarde peut
être réalisée sur un disque local ou sur un disque distant. Pour que SQL Server puisse accéder à un partage réseau,
celuici doit être mappé à un lecteur réseau au niveau de l’utilisateur Windows dans le contexte duquel, le service
s’exécute. Il est possible d’utiliser la procédure xp_cmdshell pour définir ce lecteur réseau.

Il est préférable de réaliser les sauvegardes sur un disque autre que celui qui contient les fichiers journaux
et de données de la base afin de se prémunir des pannes disque.
Lorsque la sauvegarde sur fichier est terminée, il est prudent de sauvegarder ce fichier sur un support amovible
(bande, disquette de type zip...) afin de stocker les sauvegardes dans un lieu distinct de celui où est le serveur.
b. Bandes
Les bandes représentent un moyen économique et efficace pour conserver les sauvegardes. De plus elles possèdent
un volume important de stockage. Il est facile de les conserver en dehors du site de production pour une meilleure
qualité des sauvegardes.
La gestion des bandes pour les sauvegardes n’est envisageable que si le lecteur de bande est local au serveur SQL.
Lors d’une sauvegarde sur bande, SQL Server enregistre automatiquement : le nom de la base de données, la date,
l’heure et le type de sauvegarde.
Il existe des instructions Transact SQL :
● UNLOAD : rembobine et éjecte la bande.
● NOUNLOAD : pas de rembobinage et pas d’éjection.
● BLOCKSIZE : taille des blocs physiques en octets.
● FORMAT : écrit un entête dans les fichiers utilisés.
● SKIP : ignorer les étiquettes de bande ANSI.
● NOSKIP : lire les étiquettes de bande ANSI.
● RESTART : reprendre l’opération de sauvegarde à partir du point d’interruption.
● REWIND : rembobine et libère la bande.
● NOREWIND : SQL conserve la bande après la fin de l’opération de sauvegarde.
Les bandes peuvent contenir aussi bien des sauvegardes SQL Server que des sauvegardes Windows.
3. Les principaux paramètres
La mise en place des sauvegardes peut être réalisée soit par des procédures stockées, soit par SQL Server
Management Studio. Lorsque les étapes constituant une opération de sauvegarde sont validées, il est possible de les
réunir pour constituer un travail planifié et donc géré par l’Agent SQL Server.
a. Les permissions
Pour réaliser une opération de sauvegarde, l’utilisateur doit posséder certains droits. Trois rôles prédéfinis
contiennent les autorisations suffisantes pour sauvegarder une base de données. Il est bien sûr possible de définir
ses propres rôles et d’y accorder les autorisations nécessaires.
Les utilisateurs membres d’un des rôles suivants sont capables de réaliser une sauvegarde de base de données :
● rôle de serveur sysadmin,
● rôle de base de données db_owner,
● rôle de base de données db_backupoperator.

b. La sauvegarde des bases de données système
La base de données système qui contient toutes les informations relatives au bon fonctionnement du serveur est la
base Master. Cette base doit être sauvegardée après chaque modification, surtout après la création de base de
données utilisateur. En effet si la base n’est pas référencée dans Master, il est impossible d’y accéder. Il ne faut pas
oublier non plus que la base Master contient la définition de toutes les connexions, ainsi que toutes les références
vers les serveurs liés.
Pour reconstruire les bases de données système, il faut passer par le programme d’installation et choisir
l’option REBUILDDATABASE.
La base MSDB contient tous les travaux planifiés, les lots SSIS et les opérations de réplication ainsi que la définition
des alertes et des opérateurs.
La base MODEL sert de base de départ pour toutes les bases de données utilisateur.
Ces bases de données système sont à sauvegarder après chaque modification. En période de fonctionnement, les
modifications apportées sur ces bases sont normalement assez rares et il n’est donc pas utile de les sauvegarder si
la base n’a pas évolué. Il est ainsi possible de réduire les temps de sauvegarde.
c. La sauvegarde des bases de données utilisateur
Ce sont les bases qui sont le plus concernées par les sauvegardes car elles contiennent toutes les informations de
l’entreprise. Selon l’importance des données qui y sont stockées et le nombre de modifications qui y sont apportées
un plan de sauvegarde va être déployé. Il est tout de même intéressant de noter quelques étapes qui nécessitent
une sauvegarde totale de la base :
● Après la création de la base.
● Après la création d’un index : en effet le journal des transactions mémorise la création de l’index, mais
parfois la création d’un index peut demander plus de temps que de restaurer la totalité de la base.
● Après la suppression du contenu du journal des transactions, une sauvegarde totale permet de ne pas
perdre de données.
● Après l’exécution d’une commande non journalisée.
d. Les fichiers de sauvegarde
SQL Server ne travaille pas avec la notion de fichiers de sauvegarde, mais plus exactement des unités de
sauvegarde. Il existe deux catégories d’unité de sauvegarde :
● les unités de sauvegarde logique,
● les unités de sauvegarde physique.
La distinction entre fichier et unité de sauvegarde provient du fait qu’une unité de sauvegarde peut être composée
de plusieurs fichiers.
Une unité de sauvegarde peut contenir plusieurs sauvegardes d’une ou de plusieurs bases de données.
Les unités physiques
Une unité de sauvegarde physique correspond au nom complet du fichier sous Windows. Une unité de sauvegarde
physique correspond le plus souvent à une utilisation ponctuelle d’un support de sauvegarde. Par exemple avant de
réaliser une opération sensible sur la base, une sauvegarde complète de la base peut être réalisée dans une unité
de sauvegarde physique.
L’unité physique est référencée directement dans les options de l’instruction BACKUP, ou bien le nom de l’unité
physique est précisé sur la fenêtre Sauvegarder la base de données de SQL Server Management Studio.

En Transact SQL, l’unité physique est référencée directement par l’instruction BACKUP.
Si la durée de validité de la sauvegarde, que ce soit en nombre de jours ou en date de fin de validité, n’est pas
spécifiée, alors SQL Server utilise la valeur définie au niveau du serveur par l’intermédiaire du paramètre de
configuration media retention. Cette propriété est une propriété avancée et n’est donc accessible qu’après
l’exécution de l’instruction show advanced option.

Les unités logiques
Derrière une unité de sauvegarde logique, il se cache une unité physique. Les unités de sauvegarde logique
permettent de référencer logiquement les différents supports de sauvegarde qui peuvent être utilisés au niveau de
la base. Par exemple, dans une politique de sauvegarde qui contient une sauvegarde complète chaque jour et une
sauvegarde différentielle toutes les 4 heures, il est possible de définir les unités de sauvegarde completLundi,
diffLundi, completMardi, diffMardi... de façon à utiliser des unités différentes chaque jour de la semaine. Les
opérations de sauvegarde utilisent un nom logique, c’estàdire qu’il ne leur est pas nécessaire de connaître
l’emplacement physique des fichiers.
Depuis SQL Server Management Studio, il est possible de créer une unité logique de sauvegarde en sélectionnant
l’option Nouvelle unité de sauvegarde depuis le menu contextuel associé au nœ ud Objets serveur Unités de
sauvegardes de l’explorateur d’objets.
Dans l’exemple suivant, l’unité Test est créée en s’appuyant sur un fichier physique.

La fenêtre des propriétés de l’unité de sauvegarde permet de connaître le contenu d’une unité.
Le même type d’opération peut être réalisé en Transact SQL.
C’est la procédure sp_addumpdevice qui permet de définir de nouvelles unités logiques.
Les unités logiques permettent une gestion simplifiée des sauvegardes au travers de SQL Server Management
Studio. Elles permettent également de réutiliser plus efficacement l’espace disque des anciennes sauvegardes, tout
en facilitant la mise en place de procédures automatiques sur les opérations de sauvegarde.
4. L’instruction BACKUP
L’instruction BACKUP permet de sauvegarder aussi bien la base de données que le journal de transaction. Les
opérations de sauvegarde peuvent être réalisées en Transact SQL par l’intermédiaire de cette instruction, mais il est
possible de passer par l’interface graphique de SQL Server Management Studio.
L’écran cidessous illustre comment demander l’exécution d’une sauvegarde depuis SQL Server Management Studio.

La fenêtre de création d’une nouvelle sauvegarde permet de définir toutes les options relatives à l’exécution de cette
sauvegarde.

Toutes les options de l’opération de sauvegarde sont disponibles par l’intermédiaire de la page options.
Dans le cadre de la réutilisation d’un fichier existant, il est possible, soit d’ajouter la sauvegarde à celles déjà
contenues dans le fichier, soit au contraire d’effacer toutes les données présentes dans le fichier.
Dans le cas où l’instruction BACKUP est utilisée directement, la réutilisation d’un fichier entraîne trois options
possibles :
● INIT : pour remplacer le contenu d’un fichier permanent, à condition que la date d’expiration de la sauvegarde
soit dépassée (option EXPIRATE) et que le fichier ne soit pas membre d’un jeu de sauvegarde.
● NOINIT : pour ajouter la sauvegarde à celles déjà présentes dans le fichier.
● FORMAT : pour pouvoir réutiliser un fichier qui a participé à une sauvegarde sur plusieurs fichiers.
a. Sauvegarde complète
C’est le point de départ pour toute stratégie de sauvegarde.
Demande de sauvegarde complète

Sauvegarde complète de Gescom en Transact SQL
b. Sauvegarde différentielle
Ce type de sauvegarde n’est possible que si une sauvegarde complète a été préalablement effectuée. Seules les
pages modifiées depuis la dernière sauvegarde complète sont sauvegardées. Pour connaître ces pages, SQL Server
utilise le numéro de séquence du journal (LSN : Log Sequence Number) de la page qu’il compare avec celui de la
synchronisation de la dernière sauvegarde complète.

Sauvegarde différentielle depuis SQL Server Management Studio
Sauvegarde différentielle en Transact SQL
c. Sauvegarde du journal des transactions
Le journal des transactions peut être sauvegardé. C’est l’instruction BACKUP LOG qui est utilisée. Après sa
sauvegarde, la partie inactive du journal est automatiquement tronquée. L’option NO_TRUNCATE permet de ne pas
tronquer le journal. Cette option est particulièrement utile dans le cadre d’une opération de restauration.

Sauvegarde du journal des transactions depuis SQL Server Management Studio
Sauvegarde du journal des transactions en Transact SQL
d. Sauvegarde de fichier ou de groupe de fichiers

Ce type de sauvegarde est particulièrement intéressant pour des bases de très grand volume (VLDB : Very Large
Database) lorsque les temps de sauvegarde sont longs. Si les objets sont créés sur des groupes de fichiers bien
spécialisés, les sauvegardes peuvent être optimales au niveau du temps. Les politiques de sauvegarde possibles
sont les mêmes que celles au niveau de la base.
Demande de sauvegarde d’un fichier ou d’un groupe de fichiers
e. La sauvegarde sur plusieurs fichiers
Toujours dans le souci d’accélérer les sauvegardes, il est possible de réaliser des sauvegardes en utilisant plusieurs
fichiers simultanément. Les écritures sont effectuées de façon parallèle. C’est l’ensemble des fichiers qui constitue la
sauvegarde. Bien que cette méthode permette d’accélérer considérablement les temps, les sauvegardes sont
nettement plus fragiles car la perte d’un seul des fichiers empêche l’utilisation de la totalité de la sauvegarde. Les
fichiers sont indifféremment des fichiers temporaires ou permanents.
Quelques limites apparaissent :
● tous les fichiers doivent être sur le même type de support (bande, disque),
● si un fichier est membre d’un jeu de sauvegarde, il ne peut l’être que dans le cadre de ce jeu de sauvegarde.
L’instruction BACKUP possède l’option MEDIANAME permettant de nommer un jeu de sauvegarde. Il est ainsi plus
aisé de le manipuler. Le nom est limité à 128 caractères.

5. La mise en miroir des sauvegardes
Posséder une seule version du fichier de sauvegarde peut s’avérer dangereux. Il est préférable d’en avoir plusieurs.
Ainsi, si lors de la restauration de la base, un fichier se trouve illisible, il est possible de s’appuyer sur un autre fichier
avec le même contenu. La mise en miroir des sauvegardes propose de mettre en place ce multiplexage des fichiers.

La mise en miroir des fichiers de sauvegarde est un réel gain dans la fiabilité des unités de sauvegarde. En effet, une
unité de sauvegarde permet de répartir la sauvegarde sur plusieurs fichiers. Mais c’est l’ensemble des fichiers qui
constitue la sauvegarde. Un problème sur un seul fichier empêche la restauration de la base.
La mise en miroir des fichiers de sauvegarde est mise en place par l’option MIRROR TO de l’instruction de sauvegarde
BACKUP, comme l’illustre l’exemple cidessous :
La mise en miroir est disponible quel que soit le support choisi pour les fichiers de sauvegarde (disque ou bande).
6. Vérifier l’intégrité de sauvegarde
Si l’option TORN_PAGE_DETECTION ou CHECKSUM est activée au niveau de la base de données, les sauvegardes
réalisées à partir de cette base intègrent la validation de l’intégrité des pages de données dans la sauvegarde. Cette
option est définie au niveau de la base.

Lors de la définition d’une sauvegarde, il est possible de demander la vérification de la cohérence de cette sauvegarde
depuis la page options.

Il est également possible de vérifier la cohérence du jeu de sauvegardes à l’aide de l’instruction RESTORE VERIFYONLY.
7. Compresser les sauvegardes
Afin de réduire l’espace occupé par les sauvegardes, que ce soit sur disque ou bien sur bande, SQL Server propose de
compresser les sauvegardes. Cette possibilité n’est offerte que par l’édition entreprise de SQL Server 2008, toutefois
toutes les éditions de SQL Server 2008 sont en mesure d’effectuer une restauration à partir d’une sauvegarde
compressée. Le fait de compresser la sauvegarde va entraîner une charge de travail plus importante au niveau
serveur. Heureusement, il est possible de définir cette option de compression sauvegarde par sauvegarde. De plus, la
consommation au niveau processeur peut être limitée par le gouverneur de ressources.
Lors de la création d’une sauvegarde en mode graphique, il s’agit d’un simple choix dans une liste déroulante à
sélectionner depuis la page Options.

Au niveau Transact SQL, il est nécessaire d’utiliser les paramètres WITH COMPRESSION ou WITH NO_COMPRESSION pour
activer ou non la compression de la sauvegarde.

Vue d’ensemble du processus de restauration
La restauration représente l’opération inverse d’une sauvegarde. Le processus de restauration ne peut pas être utilisé
pour réaliser des migrations de base de données.
Cette opération peut être réalisée soit à l’aide des commandes Transact SQL (RESTORE) soit par l’intermédiaire de la
console d’administration SQL Server Management Studio. Quelle que soit la base à restaurer, il est indispensable
d’installer SQL Server pour remonter les données sur la machine.
Le simple fait de replacer les fichiers constituant les données et le journal ne constitue en aucun cas une restauration,
puisque SQL Server n’est pas capable d’accéder à ces fichiers tant qu’ils ne sont pas référencés dans la base Master.
Le processus de restauration peut intervenir dans deux cas :
● suite à une demande explicite de la part d’un utilisateur,
● lors d’un redémarrage du serveur qui fait suite à un arrêt brutal, on parlera alors de restauration automatique.
1. La restauration automatique
Ce processus intervient lors de chaque démarrage du serveur. Il s’assure que la dernière opération inscrite dans le
journal est un point de synchronisation. Si ce n’est pas le cas, alors le journal est relu depuis le dernier point de
synchronisation et toutes les transactions validées sont rejouées tandis que toutes les autres modifications sont
annulées. Cette opération est nécessaire afin de garantir la cohérence des données.
2. Opérations exécutées automatiquement par SQL Server
SQL Server réalise automatiquement un certain nombre d’opérations afin d’accélérer le processus de restauration et
de réduire au maximum le temps d’indisponibilité du serveur.
Le contrôle de sécurité
L’intérêt principal de ce contrôle de sécurité est de se prémunir des restaurations accidentelles, qui peuvent écraser
une base existante pour remonter une version précédente de la base. De même, le contrôle de sécurité va s’assurer
qu’il possède tous les fichiers participant à un jeu de sauvegarde.
Le contrôle de sécurité interdira également la restauration de la base si le jeu des fichiers constituant la base est
différent de celui enregistré par le jeu de sauvegarde.
Reconstruction de la base de données et des fichiers associés
Dans le cadre d’une restauration à partir d’une sauvegarde complète de la base, SQL Server se charge de recréer la
base et les fichiers qui la composent. Les objets sont créés et les données sont transférées. Le schéma de la base de
données est donc reconstruit automatiquement durant la procédure de restauration et ne nécessite pas d’opérations
manuelles.
3. Opérations préliminaires
Avant de réaliser une restauration, il est important de réaliser quelques opérations préliminaires afin de s’assurer du
bon déroulement du processus.
a. La vérification des sauvegardes
Cette opération devrait normalement intervenir à la fin de chaque sauvegarde. Ici, le but est de retrouver la ou les
sauvegardes qui vont être nécessaires pour restaurer la base en réduisant au maximum les temps de restauration
et le volume des données perdues.
Il existe quatre instructions, qui sont détaillés ciaprès mais il est également possible de passer par SQL Server
Management Studio.
RESTORE HEADERONLY

Permet de connaître les informations contenues dans l’entête d’un fichier ou d’un jeu de sauvegarde :
● le nom et la description du fichier ou du jeu de sauvegarde,
● le support utilisé (disque ou bande),
● la date et l’heure de la sauvegarde,
● la méthode de sauvegarde utilisée (complète, différentielle, journal par groupe de fichiers ou complet),
● la taille de la sauvegarde,
● le numéro séquentiel de la sauvegarde dans une chaîne de fichiers de sauvegarde.
RESTORE FILELISTONLY
Cette instruction permet d’obtenir des renseignements sur les fichiers de données et journaux constituant la base
de données utilisant ce fichier de sauvegarde. Les informations retournées sont :
● les noms logique et physique des fichiers de données et des fichiers journaux,
● le type de chaque fichier (données ou journal),
● le groupe de fichiers auquel le fichier appartient,
● la taille maximale de chaque fichier exprimée en MégaOctet,
● la taille du jeu de sauvegarde exprimée en MégaOctet.
RESTORE LABELONLY
Permet d’obtenir quelques informations sur le fichier de sauvegarde.
RESTORE VERIFYONLY
Cette instruction, qui ne vérifie pas la cohérence des sauvegardes, n’est utilisée que dans le cadre de jeu de
sauvegarde pour s’assurer que tous les fichiers qui constituent ce jeu sont présents.
Ces quatre instructions permettent de visualiser le contenu d’un jeu de sauvegarde et fournissent donc beaucoup
d’information sur la structure la base de données à restaurer. Seuls les utilisateurs disposant du privilège CREATE
DATABASE sont en mesure d’exécuter ces instructions. Ce niveau de privilège est nécessaire à partir de SQL Server
2008.
b. Les tâches spécifiques
Avant de lancer une opération de restauration sur une base de données, il faut s’assurer, si la base existe déjà que
personne ne travaille dessus, puis dans un deuxième temps, sauvegarder la partie du journal des transactions pour
laquelle on ne possède pas de sauvegarde afin de minimiser la perte de données.
S’assurer qu’aucun utilisateur ne travaille sur la base
Il est possible en interrogeant la vue système sys.dm_exec_sessions d’établir la liste des utilisateurs actuellement
connectés à la base. L’exemple cidessous permet de connaître la connexion, le nom du programme et le poste
utilisé pour établir les connexions utilisateur (is_user_process=1).

Après s’être assuré qu’il ne reste plus d’utilisateurs connectés à la base, il est nécessaire de garantir le fait que de
nouvelles connexions ne peuvent pas être établies en plaçant la base en mode monoutilisateur.
C’est un administrateur de la base de données qui peut en restreindre l’accès, soit à un seul utilisateur, soit aux
seuls utilisateurs qui possèdent le privilège d’ouvrir une session lorsque la base se trouve en mode restreint.
Changement du mode d’accès en Transact SQL
L’instruction ALTER DATABASE GESCOM SET MULTI_USER permet de revenir en mode d’accès normal.

Changement du mode d’accès depuis SQL Server Management Studio
Sauvegarde du journal des transactions
Lorsque cette opération est possible, elle est faite par l’intermédiaire d’une instruction BACKUP LOG.
Sauvegarde du journal des transactions en cours

Restauration des sauvegardes
Suivant la sauvegarde effectuée, la méthode de restauration va être légèrement différente.
1. L’instruction RESTORE
En mode Transact SQL, c’est l’instruction RESTORE qui permet de remonter une sauvegarde faite par SQL Server.
Syntaxe
RESTORE DATABASE {nom_base |@var_nom_base }

[FROM unite_de_sauvegarde [,...n ] ]
[WITH
[{CHECKSUM | NO_CHECKSUM }]
[[,] { CONTINUE_AFTER_ERROR | STOP_ON_ERROR } ]
[[,] FILE = numéro_fichier]
[[,] KEEP_REPLICATION]
[[,] MEDIANAME = nom_support]
[[,] MEDIAPASSWORD = mot_de_passe_media]
[[,] MOVE ’nom_logique’ TO ’nom_physique’] [,...n]
[[,] PASSWORD = mot_de_passe]
[[,] PARCIAL]
[[,] {RECOVERY|NORECOVERY|STANDBY = nom_fichier_annulation}]
[[,] REPLACE]
[[,] RESTRICTED_USER]
[[,] {REWIND|NOREWIND}]
[[,] STATS [ = pourcentage]]
[[,] {STOPAT = date_heure |
STOPATMARK = {’marque’|’lsn:numéro_lsn’ }
[ AFTER date_heure] |
STOPBEFOREMARK = { ’marque’ | ’lsn:numéro_lsn’ }
[ AFTER date_heure]}]
[[,] {UNLOAD|NOUNLOAD}]
]
[;]
La commande RESTORE doit toujours être lancée depuis la base Master.

Pour restaurer le journal des transactions, il est nécessaire d’utiliser l’instruction RESTORE LOG qui possède un
paramétrage similaire à celui de RESTORE DATABASE.
Sur une base de données endommagée, la restauration permet de retrouver un ensemble cohérent de données.
L’étape de restauration se charge de recréer automatiquement les fichiers et les objets de la base, sans pour autant
qu’il soit nécessaire de supprimer la base de données auparavant.
2. Les options de l’instruction RESTORE
Il existe de nombreuses options sur l’instruction RESTORE, seules certaines sont détaillées ici.
Tout d’abord lorsque la restauration utilise plusieurs sauvegardes (une complète puis une différentielle et enfin celle
des journaux de transactions) il est important que SQL Server ne rende pas la base accessible aux utilisateurs tant
que la dernière restauration n’a pas été effectuée. Pour cela, l’instruction RESTORE propose les options RECOVERY et
NORECOVERY.
RECOVERY
C’est l’option pas défaut qui est utilisée par SQL Server. Avec cette option, à la fin de la restauration, SQL Server
passe en revue le journal de transactions afin d’annuler toutes les transactions non validées depuis le dernier point
de synchronisation et de confirmer toutes les transactions validées. Une fois ces opérations terminées, la base est
accessible par les utilisateurs.
NORECOVERY
Cette option doit être spécifiée pour toutes les étapes de la restauration sauf la dernière. SQL Server ne touche pas
au journal des transactions et la base de données ne peut pas être utilisée.
FILE
Cette option est utilisée uniquement lorsque le fichier de sauvegarde contient plusieurs sauvegardes. Elle permet de
préciser le numéro de la sauvegarde que l’on souhaite restaurer.
MOVE... TO
Par défaut les fichiers de la base de données sont restaurés au même endroit que celui défini lors de la sauvegarde.
Si l’on souhaite préciser un chemin différent il faut utiliser cette option.
REPLACE
Cette option permet de restaurer une base en écrasant la base existant préalablement sur le serveur. Cette option
est désactivée par défaut.
STOPAT
Cette option, disponible uniquement si la base est configurée en mode de restauration complète, permet de rejouer
les transactions enregistrées dans le journal jusqu’à une date et heure spécifiées au format varchar, char,
smalldatetime ou datetime.
STOPATMARK, STOPBEFOREMARK
Ces options sont disponibles uniquement si la base est configurée en mode de restauration complet. Elles permettent
de restaurer les transactions jusqu’à une transaction marquée ou bien un numéro d’enregistrement (Log Sequence
Number).
3. La restauration des différents types de sauvegarde
Toutes les politiques de restauration commencent nécessairement par la récupération d’une sauvegarde complète de
la base. Une fois ce point de départ établi, il est possible de cumuler les différentes restaurations.
a. À partir d’une sauvegarde complète
La restauration à partir d’une base complète est une opération simple à réaliser et rapide. S’il est possible de
réaliser une sauvegarde complète tous les jours, il faudra le faire car c’est cette méthode qui permet d’obtenir les
temps d’indisponibilité du serveur les plus courts.

SQL Server replace tous les fichiers de données et les fichiers associés à leurs emplacements d’origine. De même,
l’ensemble du schéma de la base est récupéré automatiquement.
Une telle opération de restauration est réalisée lorsque le disque physique contenant les fichiers de la base de
données est endommagé, ou bien lorsqu’une partie des fichiers est corrompue ou perdue. La restauration d’une
sauvegarde complète est également envisageable lorsque l’on souhaite restaurer les données sur un deuxième
serveur (ce serveur peut devenir un serveur de secours par exemple).
Restauration depuis SQL Server Management Studio

Restauration sans mise en ligne de la base
Les options de récupération RECOVERY ou NORECOVERY devront être précisées surtout si d’autres restaurations
suivent.
b. À partir d’une sauvegarde différentielle
Ce type de restauration ne peut intervenir que suite à celle d’une sauvegarde complète.
Si plusieurs sauvegardes différentielles existent pour la même base de données, il suffit de restaurer la plus récente
car une sauvegarde différentielle contient toutes les modifications intervenues sur les données depuis la dernière
sauvegarde complète.
La restauration ramène la base de données à l’état dans lequel elle était lorsque la sauvegarde a été effectuée.
La restauration d’une telle sauvegarde est bien sûr beaucoup plus rapide que celle de tous les journaux de
transactions.
Restauration d’une sauvegarde différentielle

Restauration différentielle à partir d’une unité de sauvegarde. On utilise ici la première sauvegarde réalisée dans
cette unité.
Encore une fois, si la sauvegarde différentielle est la dernière dont on dispose pour la base de données, il faudra
exécuter l’ordre RESTORE avec RECOVERY. Dans tous les autres cas (on dispose de sauvegardes du journal des
transactions), il faut utiliser l’option NORECOVERY pour être à même de restaurer la base au mieux.
c. À partir d’une sauvegarde du journal des transactions
Le journal des transactions est le dernier élément à restaurer. Il va permettre de limiter la perte des informations
modifiées dans la base depuis la dernière sauvegarde complète ou différentielle.
Il peut éventuellement y avoir plusieurs fichiers journaux à restaurer, dans ce cas ils doivent l’être dans l’ordre
chronologique.
Tous les ordres de restauration des journaux doivent comprendre l’option NORECOVERY, à l’exception de celle du
dernier journal où l’option sera soit omise, soit RECOVERY.

Demande de restauration du journal depuis SQL Server Management Studio
Lors de la restauration des journaux, il est possible de rejouer les transactions jusqu’à une date et heure bien
précises. Pour bénéficier de cette fonctionnalité il faut utiliser l’option STOPAT en association avec l’option
RECOVERY.
Cette fonctionnalité permet de restaurer une base en s’arrêtant à un instant bien précis et donc de ne pas rejouer
des transactions désastreuses.

Depuis SQL Server Management Studio, il est possible lors de la restauration d’un journal de spécifier la limite dans
le temps depuis la fenêtre Limite de restauration dans le temps.
d. À partir d’une sauvegarde de fichier ou d’un groupe de fichiers
Les opérations à mener et leur ordre sont les mêmes que dans le cadre d’une restauration totale de la base de
données. L’instruction RESTORE se complète après le nom de la base avec le nom du groupe de fichiers qui est
concerné par la restauration.
4. Restauration des bases de données système endommagées
Suivant la gravité des événement qui sont survenus, plusieurs possibilités sont envisageables.
a. Restauration à partir d’une sauvegarde
Si le serveur peut être démarré, il est possible de restaurer les bases de données système à l’aide d’une commande
RESTORE DATABASE.

b. Reconstruction de bases de données système
La reconstruction des bases de données système est possible en lançant de nouveau le processus d’installation de
l’instance SQL Server.
La reconstruction des bases sytème écrase les bases master, msdb et model existantes.
Lorsque les bases système sont reconstruites, il est alors possible de redémarrer les services et de procéder à la
restauration depuis une sauvegarde valide.
5. Restauration en ligne
La possibilité de restauration en ligne n’est disponible que dans l’édition Entreprise de SQL Server.
La restauration en ligne, c’estàdire effectuer une procédure de restauration de la base alors que des utilisateurs
continuent de travailler sur la base, n’est possible que si le groupe de fichiers primaire est intact, c’estàdire que
l’opération de restauration va concerner d’autres groupes de fichiers.
Comme tout processus de restauration, il se déroule en deux temps :
● restaurer les informations à partir de la dernière sauvegarde complète,
● rejouer les transactions présentes dans le journal et restaurer le dernier journal avec l’option RECOVERY.
Le processus de restauration en ligne peut engendrer des transactions dites différées, ce type de transaction peut
apparaître lorsque certaines informations ne sont pas accessibles lors du démarrage de la base. La transaction ne
peut donc par être rejouée de façon automatique. Le moteur SQL Server essayera d’exécuter cette transaction, qui
manipule les données affectées par l’opération de restauration, lorsque le processus de restauration sera finalisé.
C’est, en fait, suite à un démarrage de la base de données sans erreur d’entrée/sortie que les transactions différées
peuvent être éliminées.
Mise en place d’une restauration en ligne
Dans le cas où un fichier est endommagé sur une base, il est possible de restaurer ce fichier uniquement, puis il faut
sauvegarder le journal des transactions courant. Et enfin, restaurer les différents journaux de transaction pour
mettre à niveau les informations contenues dans le fichier.
Ce type de processus va être illustré sur la base GESCOM en simulant la perte d’un fichier n’appartenant pas au
groupe PRIMARY.
La première étape consiste à restaurer le fichier fichier1 à partir de la dernière sauvegarde complète.
L’unité de sauvegarde doit se trouver dans le répertoire par défaut des fichiers de sauvegarde, sinon l’opération de
restauration en ligne n’est pas possible.

Ensuite, il est nécessaire de sauvegarder le journal des transactions en cours afin de ne perdre aucune transaction.
Enfin, il est possible de restaurer les journaux et rendre la base pleinement fonctionnelle.

Serveur de secours
Un serveur de secours présente un double avantage. Tout d’abord, il offre une solution de dépannage extrêmement
rapide en cas de défaillance du serveur principal tout en minimisant la perte des données. Ensuite, le serveur de
secours étant alimenté par les sauvegardes réalisées sur le serveur principal, il permet donc de valider toutes les
sauvegardes, ce qui est un point important. En contrepartie, le serveur de secours représente un investissement non
négligeable, car cette machine ne peut pas servir dans le cadre de l’exploitation si l’on souhaite obtenir une solution de
remplacement très rapide à mettre en œ uvre.
1. Installation du serveur de secours
Le serveur de secours est un deuxième serveur SQL qui contient une image miroir du serveur de production. Le
serveur de secours peut être utilisé en lecture seule pour réduire la charge de travail du serveur de production, ou
bien pour remplacer le serveur de production lorsque ce dernier est défectueux. Le serveur de secours peut être
également utilisé pour exécuter des instructions DBCC, ce qui permet de vérifier la cohérence de la base sans ajouter
une charge de travail supplémentaire sur le serveur de production.
Initialement, il faut restaurer une sauvegarde de toutes les bases du serveur de production. Si les répertoires sont
différents, il faut utiliser l’option MOVE TO de la commande RESTORE pour changer le chemin des fichiers de la base.
Toutes les restaurations doivent comporter l’option NORECOVERY ou STANDBY. Cette dernière option est détaillée par
la suite.
Le serveur de secours sera mis à jour par l’intermédiaire des sauvegardes du journal des transactions.
2. Utilisation du serveur de secours en lecture seule
Etant donné que le serveur de secours est une image du serveur de production, il est possible d’utiliser ce serveur
pour les clients qui réalisent uniquement des requêtes de lecture (SELECT). Cela va permettre de décharger le
serveur de production de la gestion des requêtes d’interrogations, qui peut être très lourde, notamment dans le cas
d’analyse.
Dans ce cas, il est nécessaire que l’instance SQL Server de secours dispose d’une licence d’exploitation. À l’inverse, si
aucun utilisateur n’est connecté sur le serveur de secours, l’instance SQL Server est couverte avec l’utilisation de la
licence du serveur principal.
Le problème qui se pose est de celui de la restauration. En effet l’option NORECOVERY, qui permet de restaurer les
journaux, n’autorise personne à utiliser la base. Pour éviter ce problème, il existe l’option STANDBY qui autorise
uniquement les opérations de lecture sur la base de données. Cette option nécessite l’utilisation d’un fichier qui
servira à annuler les modifications apportées par la restauration d’autres journaux de transactions.
3. Mise en place d’un serveur de secours
Le point de départ de la mise en place d’un serveur de secours est, comme cela est souvent le cas, une sauvegarde
complète de la base d’origine.
Dans l’exemple ciaprès, la sauvegarde de la base Gescom est faite à destination d’une unité physique.

Dans un deuxième temps, cette sauvegarde doit être restaurée sur le serveur de secours. Étant donné que les
emplacements des fichiers physiques ne sont pas nécessairement les mêmes, l’option MOVE TO est utilisée lors du
processus de restauration.
Dans l’exemple suivant, c’est une autre instance SQL Server qui sert de serveur de secours.
Afin de simplifier les éléments de syntaxe, la base Gescom initiale ne contient pas de catalogue de texte
intégral.
Ensuite, les sauvegardes des journaux de la base principale sont restaurées sur le serveur de secours avec l’option
STANDBY ou NORECOVERY.
Ce processus d’envoi des fichiers journaux peut être automatisé avec SQL Server 2008 en configurant le serveur
principal pour qu’il place une sauvegarde du journal dans un dossier accessible par le serveur de secours.
Depuis SQL Server Management Studio, la configuration de l’envoi automatique des journaux s’effectue de la façon
suivante.

Il faut alors définir la base de données en tant que base de données primaire, puis définir le chemin local et réseau
d’accès à la sauvegarde du journal. Il est ensuite possible de définir le ou les serveurs à qui la copie du journal va
être envoyée ainsi que le mode de restauration souhaité du journal. Les opérations de sauvegarde et de
restauration sont planifiées.

Toutes les opérations relatives à l’envoi des journaux peuvent être suivies par une base de données témoin qui va
consigner tous les évènements relatifs à cette opération.
La procédure d’envoi automatique des journaux est mise en place pour des bases dont la structure physique reste
raisonnable en terme de complexité (quelques fichiers).
Bien évidemment, ce processus s’appuie sur des travaux planifiés, et SQL Server Agent doit être actif.
4. Mise en route du serveur de secours
Si le serveur de production tombe en panne, le serveur de secours doit prendre le relais au plus vite. Une démarche
rigoureuse est indispensable afin de perdre le minimum de données.
a. Connexion
Serveur de production
Sauvegarde du journal de transactions
Si l’opération est possible, le journal des transactions doit être sauvegardé afin que les transactions validées
depuis la dernière sauvegarde ne soient pas perdues.
Déconnexion
Afin d’éviter tout conflit, le serveur de production doit être physiquement déconnecté du réseau.
Serveur de secours
Nom du serveur

Afin de pas perturber les clients qui utilisent le serveur, le changement de nom permet une relative transparence
visàvis des applications.
Restauration du journal
Le journal qui a été sauvegardé sur le serveur de production doit être restauré avec l’option RECOVERY afin de
rendre la base accessible en lecture et en écriture.
b. Restauration du serveur de production
Lorsque le problème est résolu sur le serveur de production, il doit reprendre son rôle initial.
Serveur de secours
● Réaliser une sauvegarde de la base de données et de tous les journaux de transactions.
● Déconnecter physiquement le serveur du réseau.
Serveur de production
● Restaurer les sauvegardes de la base de données et des journaux de transactions, puis reconnecter le
serveur au réseau.
c. Rétablissement de l’ordinateur SQL Server de secours
Le serveur de secours doit changer de nom avant sa connexion au réseau. Pour qu’il devienne une image du
serveur de production, le plus simple est de réaliser une sauvegarde complète de la base de données et de la
restaurer avec l’option STANDBY ou NORECOVERY.

Audit de l’activité de SQL Server
SQL Server dispose de nombreux outils de suivi des performances du serveur et de l’activité des utilisateurs. Cette
surveillance est importante car elle permet de détecter les goulets d’étranglement et d’améliorer au plus vite les temps
de réponse du serveur.
Avant de lancer la surveillance, il convient de définir clairement :
● les objectifs recherchés.
● l’outil le mieux approprié. Les plus souples sont SQL Profiler et l’Analyseur de Performances Windows.
● s’il faut surveiller SQL Server ou son environnement pour atteindre les objectifs.
SQL Server 2008, dans son édition entreprise, propose l’outil SQL Server Audit afin d’être en mesure de définir son
propre processus d’audit.
Cet audit peut être défini soit au niveau de l’instance SQL Server, soit au niveau d’une ou de plusieurs bases de
données. L’audit va pouvoir suivre des évènements et enregistrer la survenue de ces évènements dans le journal
d’audit. Ce journal d’audit peut être un fichier, le journal des évènements de sécurité ou bien le journal des
évènements d’applications Windows. Quelle que soit la cible de l’audit, le fichier doit être sauvegardé de façon
régulière afin de garantir l’espace nécessaire au journal pour enregistrer les évènements.
L’écriture dans le journal de sécurité n’est possible que si le contexte de sécurité dans lequel s’exécute le service SQL
Server dispose de ce privilège. C’est le cas par défaut des comptes système local, service local et service réseau. Pour
les autres comptes, il est nécessaire d’appliquer la règle Générer des audits de sécurité.
Pour pouvoir réaliser, ou modifier, un audit, il faut être membre du rôle sysadmin. Il est également possible d’auditer
chaque modification de l’audit.
Il est à noter que la mise en place d’un audit peut avoir un effet négatif sur les performances, car l’activation des
compteurs d’audit consomme des ressources sur le serveur et il y a donc moins de ressources disponibles pour
répondre aux demandes des utilisateurs.
1. Définir un audit au niveau serveur
La mise en place de ce type type d’audit passe tout d’abord par la création et la configuration d’un objet de type SQL
Server Audit. Cet objet va pouvoir être utilisé par la suite pour définir que la spécification de cet audit est de niveau
serveur.
La création d’un objet de type SQL Server Audit est possible depuis le nœ ud Sécurité Audit de l’explorateur
d’objets. Il est bien sûr nécessaire de sélectionner l’option Nouvel Audit depuis le menu contextuel associé au nœ ud.
La boîte de dialogue de définition d’un nouvel audit est alors affichée.

C’est à ce niveau que la destination de l’audit est spécifiée ainsi que le comportement de l’audit sur l’instance s’il
vient à manquer de l’espace dans le journal.
Il est alors possible de définir une spécification d’audit de niveau serveur par l’intermédiaire du choix Nouvelle
Spécification de l’audit du serveur depuis le menu contextuel du nœ ud Sécurité Spécifications d’audit du
serveur.

La définition de la spécification permet la sélection des évènements audités, ainsi que de préciser l’audit utilisé.
2. Définir un audit au niveau base de données
Au niveau de la base de données, comme au niveau serveur, la définition d’un nouvel audit repose sur les objets SQL
Server Audit ainsi que les spécifications. Si les objets SQL Server Audit sont définis au niveau du serveur, les
spécifications sont quant à elles définies au niveau de la base de données. La boîte de dialogue qui permet de créer
une nouvelle spécification d’audit de base de données est accessible depuis le nœ ud Sécurité Spécification d’audit
de base de données.
Après avoir associé la spécification à un objet SQL Server Audit, il est possible de sélectionner un ou plusieurs

évènements à auditer.
3. Afficher le journal d’audit
Les journaux d’audit sont accessibles depuis le nœ ud Sécurité Audit de l’explorateur d’objets. Il est ensuite
nécessaire de sélectionner l’audit dont on souhaite visualiser le journal puis de sélectionner l’option Afficher les
journaux d’audit depuis le menu contextuel associé.
La visionneuse est alors exécutée et il est ainsi possible de parcourir le journal d’audit.
4. Audit c2
Le générateur de profils stocke l’ensemble des données auditées dans des fichiers journaux. La taille maximale d’un
fichier journal est de 200 Mo. Lorsque cette limite est atteinte, le fichier est fermé et un nouveau fichier est
automatiquement créé et ouvert. Lorsqu’il n’y a plus d’espace libre sur le disque l’instance SQL Server est arrêtée. Il
faudra donc par la suite libérer de l’espace sur le disque où les fichiers d’audit sont stockés avant de redémarrer
Il est possible dans SQL Server d’utiliser l’option Mode audit c2 pour auditer les tentatives en succès ou en échec
d’utilisation d’ordres DML ou bien d’objets de la base. L’analyse des informations ainsi collectées permet de mettre en
place une stratégie de sécurité empêchant toutes les violations. Ce mode d’audit est également un bon moyen pour
connaître l’activité de la base.

Les informations sont stockées dans des fichiers de 200 Mo maximum à l’intérieur des répertoires mssql
($nom_instance)\data. Si l’audit reste en activité un certain temps, les informations seront réparties
automatiquement dans plusieurs fichiers (création d’un nouveau fichier dès que le fichier courant atteint les 200 Mo).
L’audit de niveau c2 reste activé tant que l’on ne demande pas sa désactivation ou bien tant que l’on n’arrête pas
SQL Server. Seuls les membres du rôle sysadmin possèdent le pouvoir d’activer/désactiver l’audit de niveau c2.
La mise en place de l’audit de niveau c2 est réalisée avec la procédure sp_configure. La commande RECONFIGURE
permet de prendre en compte les modifications de configuration de façon immédiate sans avoir à arrêter et démarrer
le service.
La mise en place de l’audit niveau c2
Il est également possible d’activer cette option au niveau de la page Sécurité de la fenêtre des propriétés du
serveur, en cochant la case Activer le suivi d’audit C2.

La mise en place d’un audit de niveau c2 peut dégrader les performances du serveur tant que l’audit est
activé.
Si le répertoire de stockage des fichiers d’audit est plein, alors SQL Server s’arrête automatiquement. Si l’audit n’est
pas configuré en démarrage automatique, il est alors possible de redémarrer SQL Server. Dans le cas contraire, il est
nécessaire de libérer de la place sur le disque dur afin que l’audit puisse enregistrer ses informations dès le
démarrage de SQL Server. Il est toutefois possible de démarrer SQL Server en ligne de commande avec l’option f
pour empêcher le démarrage automatique de l’audit.
Si l’audit empêche le bon démarrage de l’instance SQL Server (évènement MSG_AUDIT_ FORCED_SHUTDOWN inscrit
dans le journal) alors il est nécessaire de démarrer l’instance en mode monoutilisateur avec l’option m. En effet, en
mode monoutilisateur, l’audit ne peut pas bloquer le démarrage, toutefois l’évènement
MSG_AUDIT_SHUTDOWN_BYPASS sera inscrit dans le journal.

Générateur de profils
Le générateur de profils proposé par SQL Server est un outil qui permet de capturer les instructions soumises au
serveur. Cette capture est enregistrée dans un fichier appelé fichier de trace. C’est l’outil SQL Server Profiler qui permet
de définir les options de cette capture et d’enregistrer le fichier de trace. Il est également possible de capturer un flux
d’événements dans un fichier de trace à l’aide de procédures stockées.
SQL Server Profiler permet également d’analyser une trace capturée.
La capture du flux de travail soumis à SQL Server peut être mise en place pour plusieurs raisons :
● Analyser la charge de travail du serveur,
● Valider la structure physique de la base par rapport à la charge de travail,
● Identifier les requêtes longues et/ou bloquantes,
● Servir de base à un audit de sécurité.
Lors de la mise en place d’une capture, il est nécessaire de préciser les éléments qui doivent être enregistrés dans le
fichier de trace : sur quels critères sontils sélectionnés ? Quelles informations fautil conserver...? Pour définir
précisément les options de capture, SQL Server Profiler utilise ses propres termes :
● Evénement : il s’agit d’une action produite sur l’instance SQL Server. Cette action correspond à une instruction
Transact SQL simple comme INSERT, UPDATE, DELETE par exemple. Pour chaque événement, une ligne
d’information est produite et enregistrée dans la trace.
● Classe d’événements : il s’agit d’un regroupement logique d’événements qui peuvent être enregistrés dans la
trace. Par exemple, la classe Audit : Login regroupe tous les événements relatifs à l’ouverture de session sur
● Catégorie d’événements : représente l’organisation logique des classes d’événements telle qu’elle est mise en
place dans SQL Server Profiler.
● Colonne de données : représente un attribut de la classe d’événements présent dans la trace.
● Modèle : correspond à la configuration par défaut d’une capture. Le modèle regroupe les éléments à surveiller
et le type des informations à enregistrer.
● Trace : représente l’ensemble des informations capturées. Une trace peut être définie localement ou bien à
partir d’un modèle.
● Filtre : lors de la définition d’un modèle ou bien d’une trace, il est possible de filtrer les informations liées à
l’événement qui seront gardées, afin d’éviter que le fichier de trace ne grossisse trop vite.

Le générateur de profils
1. Capturer l’activité courante du serveur
Pour capturer l’activité, il faut créer une nouvelle trace. La trace doit être totalement définie avant de commencer la
capture.
Pour créer une nouvelle trace, il est possible de s’appuyer sur un modèle de trace déjà défini. Les différents modèles
de trace sont :
● Standard : il s’agit du modèle par défaut.
● Sp_counts : trace le comportement des procédures stockées.
● TSQL : pour suivre les instructions Transact SQL envoyées au serveur.
● TSQL_Duration : enregistre en plus le temps d’exécution de chaque instruction.
● TSQL_Grouped : permet de suivre les instructions Transact SQL et de les regrouper par demandeur.
● TSQL_Replay : capture des informations détaillées sur les instructions Transact SQL.
● TSQL_SPs : capture les informations détaillées sur les procédures stockées exécutées.
● Tuning : capture les éléments en vue d’une analyse ultérieure par l’Assistant de paramétrage de base de
données.
Chaque trace est parfaitement identifiée par son nom.

L’écran suivant illustre la fenêtre qui apparaît lorsque la création d’une nouvelle trace est effectuée par Fichier
Nouvelle trace.

Il faut en plus préciser le mode de stockage de la trace et sa taille maximale ainsi qu’une éventuelle heure d’arrêt. Il
n’est pas nécessaire de définir une heure de début car la capture commence aussitôt après avoir validé la définition
de la trace.
Avant de commencer à définir des traces, il est possible de définir des valeurs par défaut par l’intermédiaire des
options du générateur du profil accessibles depuis le menu Outils.
La seconde étape consiste à sélectionner les événements à tracer et pour chaque événement quelles sont les
informations à conserver. Ce paramétrage est défini depuis l’onglet Sélection des événements de la boîte de
dialogue des Propriétés de la trace.

Dans cet écran, les événements sont regroupés par classe et, lors du survol avec le curseur de la souris des
différents événements, une brève description est affichée dans la zone basse de la fenêtre. Le même type de
description est réalisé lors du survol des différentes colonnes.
Par défaut, seuls les événements présents dans la trace sont affichés, mais il est possible de connaître les autres
événements et d’en ajouter d’autres en activant la case à cocher Afficher tous les événements. La case à cocher
Afficher toutes les colonnes permet d’obtenir le même type de comportement mais au niveau des colonnes de
données.
Pour définir un comportement commun pour tous les événements au niveau des colonnes, il suffit de définir un
nouveau filtre en cliquant sur le bouton Filtres de colonnes.
À la fin de sa création, la trace est démarrée automatiquement.

Il est possible d’arrêter et de démarrer une trace depuis la barre d’outils.
Définition d’une trace en Transact SQL
Il est possible de définir une trace en Transact SQL, il faut alors s’appuyer sur quatre procédures stockées distinctes
et travailler en 4 étapes qui sont :
■ Créer la trace avec sp_trace_create.
■ Ajouter les événements par l’intermédiaire de sp_trace_setevents.
■ Éventuellement définir un filtre en exécutant sp_trace_setfilter.
■ Utiliser sp_trace_setstatus pour démarrer, arrêter et fermer la trace.
L’exemple suivant illustre la définition d’une trace en Transact SQL.

2. Utiliser les données capturées
Après avoir capturé les événements, il faut posséder un puissant outil d’analyse afin d’en retirer toute l’information
nécessaire.
La relecture des traces est possible dans le générateur de profils. Il possède un modèle de relecture multithread
permettant de simuler les connexions et permet à l’utilisateur de reproduire l’activité capturée dans la trace.
Cette relecture de trace prend en charge le débogage à l’aide de point de rupture et d’exécution ce qui facilite
particulièrement l’analyse de scripts longs.
Le chargement d’une capture s’effectue par le menu Fichier Ouvrir. Il faut ensuite sélectionner le support qui
contient la capture, puis indiquer le fichier ou la table en question.
Demande d’ouverture d’une trace

Choix de la trace
Avant d’en réaliser l’analyse, il faut demander la relecture de la capture.
Lecture d’une trace

Analyseur de performances (Moniteur Système)
Il s’agit de l’analyseur de performances de Windows auquel de nombreux compteurs ont été ajoutés lors de
l’installation de SQL Server.
En plus des nombreux compteurs fournis en standard, il est possible de définir dix compteurs utilisateur afin de pouvoir
adapter l’utilisation de l’analyseur de performances à la demande.
Les principaux objets spécifiques à SQL Server sont :
● Agent de réplication : surveiller les agents de réplication en cours d’exécution.
● Base de données : surveiller l’utilisation de la base de données, comme la quantité d’espace journal disponible
ou le nombre de transactions actives.
● Capture instantanée : surveiller la capture instantanée des réplications.
● Distribution de réplication : surveiller le nombre de commandes et de transactions lues à partir de la base de

données distribution.
● Fusion de réplication : surveiller l’exécution de chaque fusion qui déplace les modifications de données, soit de
l’abonné vers l’éditeur, soit l’inverse.
● Gestionnaire de cache : permet de surveiller la façon dont SQL Server utilise la mémoire pour stocker des
objets (procédures stockées...).
● Gestionnaire de tampon : permet de surveiller la façon dont SQL Server utilise la mémoire pour stocker des
pages de données.
● Gestionnaire mémoire : surveiller l’utilisation globale de la mémoire.
● Lecteur du journal des transactions : surveiller l’agent de lecture du journal des transactions.

● Méthodes d’accès : surveiller l’accès aux pages logiques.
● Réservé à l’utilisateur : la définition des compteurs (10 au maximum) est à la charge de l’utilisateur.
● Statistiques générales : surveiller l’activité générale du serveur.
● Statistiques SQL : surveiller la compilation et le type de requêtes transmises à SQL Server.
● Unité de sauvegarde : surveiller les unités de sauvegarde utilisées dans les opérations de sauvegarde et de
restauration.
● Verrous : un nombre minimal de verrous favorise la concurrence d’accès, ce qui améliore les performances.
● Verrous internes : cet objet permet de connaître le temps moyen d’obtention d’un verrou sur une ressource,
ainsi que le nombre de demandes de verrous ne pouvant être satisfaites immédiatement.
Les procédures stockées réservées à la définition des compteurs utilisateur sont sp_user_counter1 à
sp_user_counter10. Les requêtes définies dans ces procédures stockées doivent être aussi simples que possible pour
ne pas alourdir la charge de travail exécutée par le serveur. Il est possible de demander l’exécution de ces procédures
n’importe où (déclencheur, autres procédures...).
Les compteurs personnalisés sont disponibles dans l’objet User Settable de l’analyseur de performances.
Pour modifier la valeur du premier compteur de performances, il faut exécuter la procédure sp_user_counter1 qui
accepte en paramètre un et un seul entier.
Exemple :
Dans l’exemple suivant, une procédure stockée est créée pour surveiller le nombre de lignes dans la table des clients.
Dans le cadre d’un serveur de production, il est plus judicieux de placer l’appel à cette procédure dans les
déclencheurs de type INSERT et DELETE associés à cette table. Ainsi, la procédure n’est exécutée que lorsque
le nombre de lignes présentes dans la table évolue.
Définition de la procédure MonCompteur
Si le compteur doit être mis à jour de façon continue, il faut intégrer son exécution dans une boucle infinie.
Dans le moniteur système on surveille le premier compteur utilisateur.

Évolution du compteur
SQL Server introduit en plus des compteurs de performances pour suivre la bonne application des nouvelles syntaxes
de commandes et éviter de continuer à utiliser des fonctionnalités ou éléments de syntaxe marqués comme étant
maintenus pour des raisons de compatibilité antérieure mais étant amenés à disparaître. Il s’agit des compteurs SQL
Server : Deprecated Features ou Fonctionnalités désapprouvées.

Optimisation de la mémoire et de l’unité centrale
Par défaut, SQL Server gère automatiquement et dynamiquement la quantité de mémoire qui lui est nécessaire. Cette
option doit être conservée dans la majorité des cas. Il est pourtant possible de figer les quantités de mémoire
minimum, maximum et la taille du jeu de travail.
L’analyseur de performances va permettre de surveiller l’utilisation de la mémoire afin de s’assurer que la
consommation reste dans des limites raisonnables et qu’aucun processus, y compris SQL Server, ne manque de
mémoire. Ces critères correspondent aux compteurs Page/s et Octets disponibles de l’objet Mémoire.
Le compteur Page/s indique le nombre de pages mémoire qui sont extraites ou bien écrites sur le disque pour des
raisons de défaut de pagination. Une valeur élevée peut indiquer un manque de mémoire vive.
Le compteur Mémoire : Défaut de pages/s permet de s’assurer que l’activité du disque n’est pas liée au processus de
pagination mémoire.
Surveillance de la mémoire du système
Pour connaître la quantité de mémoire utilisée par SQL Server, il faut surveiller les compteurs suivants dans l’analyseur
de performances :
● Processus\Plage de travail.
● SQL Server : Gestionnaire de tampons\Taux d’accès au cache des tampons. Indique un pourcentage
représentant le nombre de fois où les pages de données demandées sont trouvées dans le cache.
● SQL Server : Gestionnaire de tampons\nombre total de pages. Nombre total de pages pour SQL Server.
● SQL Server : Gestionnaire de tampons\pages libres. Nombre total de pages SQL Server non utilisées.
● SQL Server : Gestionnaire de mémoire\mémoire totale du serveur (Ko). Cette valeur doit être en
correspondance avec le volume de mémoire attribué à SQL Server.
Pour les compteurs Taux d’accès au cache des tampons de l’objet Gestionnaire des tampons ainsi que Mémoire
totale du serveur de l’objet Gestionnaire de mémoire, les valeurs significatives sont :

● Taux de présence dans le cache : 90 % est un taux normal en cours d’utilisation, qui assure peu de lecture
physique des données.
● Mémoire totale du serveur : si la mémoire utilisée par SQL Server représente une partie importante de la
mémoire du poste, il se peut que le poste manque de mémoire.
La taille de la mémoire du serveur peut être fixée de façon statique soit par l’intermédiaire de SQL Server Management
Studio soit par la procédure stockée sp_configure avec l’option set working set size.

Configuration de la mémoire de SQL Server

Limitation des ressources utilisées par une requête
Le coût d’une requête correspond à la durée estimée (en secondes) pour l’exécution. L’option query gouvernor cost
limit permet de spécifier une limite supérieure pour l’exécution d’une requête.
Par défaut cette option reçoit la valeur 0, ce qui autorise l’exécution de toutes les requêtes. Si une valeur positive,
différente de 0 est indiquée, alors l’administrateur de requête n’autorise pas l’exécution de toutes les requêtes dont le
coût estimé d’exécution dépasse cette valeur.
Cette limitation est positionnable sur le serveur par l’intermédiaire de sp_configure ou bien sur chaque base de
données avec SET QUERY_GOUVERNOR_COST_LIMIT.
Le paramétrage avec l’option SET n’est valable que pour la période actuelle d’activité de l’instance. Ce paramètre ne
sera pas conservé au prochain démarrage de l’instance. Pour conserver cette valeur, il est nécessaire de configurer
l’option par sp_configure ou bien par les propriétés du serveur.

L’instruction RECONFIGURE permet de prendre en compte les nouvelles valeurs des options de configuration
sans avoir à redémarrer le serveur.
Depuis SQL Server Management Studio, cette option est paramétrable à partir de la fenêtre des propriétés du serveur,
sur la page Connexions en activant la case à cocher Utiliser l’Administrateur de requêtes pour empêcher les
requêtes longues et en précisant le coût maximum autorisé dans la zone de saisie associée.

Le plan d’exécution d’une requête
Les requêtes, procédures et déclencheurs sont analysés par SQL Server et l’optimiseur de requête va stocker le plan
d’exécution dans la mémoire de SQL Server. Plus exactement dans la zone mémoire intitulée mémoire cache du plan. Il
est possible d’analyser cette version compilée de la requête pour mieux comprendre les choix faits par l’optimiseur de
requête et réagir pour permettre une exécution plus rapide de la requête. Ce qui peut se traduire par une nouvelle
écriture de la requête, l’ajout d’index, la mise à jour des statistiques...
L’optimisation des requêtes n’est pas le seul point à prendre en compte pour résoudre les problèmes de performances,
mais ce n’est pas non plus un élément à négliger. En effet, se focaliser sur des problèmes mémoires lorsque la requête
est mal écrite peut masquer momentanément les mauvais temps de réponse, mais le problème se produira de nouveau
lorsque le volume de données augmentera.
Il n’est pas possible d’afficher le plan d’exécution d’un déclencheur ou d’une procédure stockée.
Pour visualiser le plan d’exécution sous SQL Server Management Studio, il existe deux options :
● Afficher le plan d’exécution estimé, le script Transact SQL n’est pas exécuté, le plan d’exécution affiché est issu
de l’analyse de la requête par l’optimiseur de requête.
● Inclure le plan d’exécution réel, le script Transact SQL est exécuté et le plan d’exécution utilisé est affiché.
La lecture du plan d’exécution n’est possible que pour les utilisateurs qui disposent des privilèges suffisants.
Dans un cas comme dans l’autre, il faut cliquer sur l’onglet Plan d’exécution pour visualiser le plan d’exécution.

Pour être capable de lire correctement le plan d’exécution, il est nécessaire de connaître les éléments suivants :
● La lecture se fait de gauche à droite.
● Le coût de chaque requête est exprimé sous forme de pourcentage par rapport au coût total du lot analysé.
● L’icône présente sur chaque nœ ud symbolise l’opérateur physique et/ou logique utilisé.
● Un plan d’exécution est affiché pour chaque requête du lot Transact SQL analysé.
En faisant glisser le curseur de la souris sur les nœ uds, des informations relatives à l’opération réalisée sont affichées
sous forme d’infobulles. Ces infosbulles peuvent contenir les informations suivantes :
● Opération physique : affiche l’opérateur physique utilisé.
● Opération logique : présente l’opérateur logique associé à l’opérateur physique.
● Estimated Row Size : estimation de la taille en octets de la ligne produite par l’opérateur.
● Estimated I/O Cost : estimation des coûts de lecture/écriture.
● Estimated CPU Cost : estimation du coût processeur pour cette opération.
● Estimated Operator Cost : estimation du coût pour l’optimiseur de requêtes.
● Estimated Subtree Cost : somme des coûts des opérations précédents et de cette opération.
● Estimated Number of Rows : disponible uniquement lorsque la requête est exécutée, cet élément permet de
connaître le nombre de lignes traitées.

Il est possible d’afficher le plan d’exécution de façon textuelle avec SET SHOWPLAN_ TEXT ou bien sous forme
de fichier XML avec SET SHOWPLAN_XML.
Certaines requêtes, plus complexes vont avoir des temps de réponse plus longs que les autres requêtes car le volume
de données manipulées est plus important et les traitements sont nombreux. Pour optimiser de telles requêtes, il est
nécessaire d’explorer les voies suivantes :
● Ajouter de la mémoire de façon à être sûr que toutes les données se trouvent en mémoire lors de l’exécution
de la requête. L’objectif recherché est d’avoir le maximum de lecture logique avec très peu de lecture physique.
● Si le serveur dispose de plusieurs processeurs, le système doit autoriser SQL Server à les utiliser afin d’obtenir
une parallélisation de la requête.
● Écrire la requête sous une nouvelle forme en limitant au maximum l’utilisation d’éléments qui rendent
l’exécution plus complexe comme les curseurs, l’exécution d’une requête paramétrée dans une boucle,
l’utilisation de plusieurs alias pour une même colonne, l’utilisation de fonctions qui ne sont pas absolument
nécessaires.
● Modifier la valeur de l’option de configuration query gouvernor de façon à limiter le temps d’exécution accordé
à chaque requête.

Le plan de maintenance
Pour les opérations classiques de l’administrateur comme des sauvegardes régulières de la base de données et des
journaux de transaction, ou bien les opérations de maintenance des index, il est possible de définir des plans de
maintenance. L’exécution de ces différentes tâches va être planifiée lors de la définition du plan de maintenance.
Les plans de maintenance peuvent être définis à l’aide d’un assistant mais la création manuelle d’un plan de
maintenance offre une plus grande richesse de paramétrage. C’est donc cette dernière possibilité qu’il faut privilégier.
Les plans de maintenance sont définis sous forme de package SSIS et c’est bien entendu SQL Server Agent qui se
charge d’exécuter le travail qui lance ce package. Les plans de maintenance ne peuvent être définis que sur des bases
qui proposent un niveau de compatibilité supérieur ou égal à 80.
L’utilitaire en ligne de commande sqlmaint est maintenu pour des raisons de compatibilité antérieure mais il est
recommandé de ne pas l’utiliser.
La définition d’un nouveau plan de maintenance peut aisément être définie en faisant appel à l’assistant de définition
d’un nouveau plan. Cet assistant peut être exécuté depuis le menu contextuel associé au nœ ud Gestion Plan de
maintenance depuis l’explorateur d’objets.
Le résultat de l’exécution des différentes tâches relatives au plan de maintenance peut être écrit dans un fichier au
format texte ou bien directement dans la base msdb. Dans ce dernier cas, ce sont les tables sysmaintplan_log et
sysmaintplan_logdetail qui stockent le détail du plan de maintenance. Les informations peuvent être facilement lues
en consultant l’historique depuis SQL Server Management Studio.

Assistant Paramétrage Moteur de base de données
L’assistant paramétrage du moteur de base de données a pour objectif de proposer la structure physique optimum en
confrontant l’organisation actuelle avec une charge de travail.
Il est possible de demander l’exécution de cet outil en ligne de commande avec dta.exe.
La charge de travail correspond soit à une trace capturée au préalable par le générateur de profil de SQL Server, soit à
un script Transact SQL.
À partir de cette charge de travail, l’outil va éventuellement proposer une réorganisation du schéma logique en
ajoutant des index supplémentaires, en partitionnant certaines tables ou bien encore en proposant la création de vues
indexées. Les propositions faites par l’assistant ont pour objectif de réduire le coût estimé par l’optimiseur de requête
pour la charge de travail analysée.
Lors de l’analyse d’une charge de travail, il est nécessaire de paramétrer trois éléments :
● nommer de façon unique l’analyse,
● référencer vers un fichier ou une table contenant une charge de travail,
● sélectionner la ou les bases qui vont être concernées par cette analyse.
1. Initialisation de l’assistant de paramétrage
Toutes les informations relatives au paramétrage vont être stockées dans la base msdb. Pour cela, lors de la
première exécution de l’assistant de paramétrage, une structure va être définie dans msdb. Seul un utilisateur
disposant des droits d’administrateur du système (sysdamin) peut mener à bien cette tâche. Par la suite, l’utilisateur
devra au moins être membre du rôle db_owner pour analyser et mettre en place les propositions sur une base de
données.
L’assistant de paramétrage utilise la procédure stockée étendue xp_msver.
L’assistant peut être lancé directement depuis le menu Microsoft SQL Server 2008 Outils de performance ou bien
depuis SQL Server Management par Outils Assistant paramétrage du moteur de base de données.
Mais la façon la plus simple de lancer l’outil est sans doute de sélectionner une requête ou bien un lot d’instructions
dans l’éditeur de requête de SQL Server Management Studio et de sélectionner Analyser la requête dans l’Assistant
Paramétrage de base de données depuis le menu contextuel.

Il est également possible de demander l’exécution de cet assistant depuis le générateur de profil par Outils
Assistant Paramétrage de base de données. Cette possibilité est pratique pour analyser une trace capturée à cette
intention (modèle Tuning).
2. Analyse d’une charge de travail
Lors du lancement de l’outil, il est nécessaire d’identifier la session en précisant son nom, l’origine de la charge de
travail et sur quelle base l’analyse doit porter.

L’onglet Options de paramétrage permet de sélectionner plus finement le type de structure qui va faire partie de
l’analyse et la marge de manœ uvre laissée à l’outil pour bâtir sa réponse. Pour lancer l’analyse, il faut cliquer sur le
bouton Démarrer l’analyse de la barre d’outils. Un nouvel onglet est alors affiché afin de suivre la progression de
l’analyse.
À la fin de l’analyse, les onglets Recommandation et Rapports sont ajoutés. Il est possible d’appliquer les
recommandations de façon immédiate ou planifiée par l’intermédiaire du menu Actions Appliquer les
recommandations.
Depuis l’onglet Rapports, il est possible d’afficher un certain nombre de rapports pour connaître la pertinence des
choix actuels et de ceux recommandés.

Les déclencheurs DDL
SQL Server propose les déclencheurs de type DDL. Ces déclencheurs (trigger) de base de données fonctionnent
comme les déclencheurs associés à une action insert, update ou delete qui peut se produire sur une table donnée.
L’exécution du déclencheur DDL est associée à l’exécution d’une instruction CREATE, ALTER, DROP, GRANT, REVOKE,
DENY et UPDATE STATITICS.
Les déclencheurs DDL sont exécutés après l’instruction DDL à laquelle ils sont associés. Les déclencheurs DDL
permettent de suivre les modifications apportées au schéma ou bien d’interdire certaines modifications qui peuvent
être apportées au schéma.
Pour interdire une instruction DDL dans le déclencheur associé, il faut annuler la transaction grâce à l’instruction
ROLLBACK.
Lors de la définition d’un déclencheur DDL, il faut préciser l’instruction DDL qui permet son exécution, ainsi que sa
portée, c’estàdire l’endroit il va être actif. La portée peut correspondre à une base de données particulière ou bien
correspondre à la totalité de l’instance.
Pour permettre de suivre au mieux les différentes exécutions des instructions DDL, il est possible d’utiliser la fonction
EVENTDATA dans les déclencheurs DDL. Cette fonction permet de capturer les informations relatives à l’exécution du
déclencheur. Cette fonction retourne un flux XML. Il est possible d’extraire des informations de ce flux XML, en utilisant
une requête XQuery.
Il n’est pas possible de définir des déclencheurs DDL de type instead of.
Les informations relatives à l’exécution en cours du déclencheur DDL sont disponibles au travers de EVENTDATA. Il
n’existe pas de table inserted ou deleted.
Les déclencheurs de type DDL peuvent être définis sur une base de données ou bien sur le serveur. Dans le cas des
déclencheurs définis sur une base, la définition du déclencheur est stockée dans cette même base. La définition des
déclencheurs de niveau serveur est enregistrée dans la base master. Dans tous les cas, il est possible d’obtenir des
informations concernant ces déclencheurs en interrogeant la vue sys.server_triggers.
Syntaxe
CREATE TRIGGER nomDéclencheur

ON { ALL SERVER | DATABASE }
[ WITH ENCRYPTION, [EXECUTE AS clause] ]
{ FOR | AFTER } {typeInstruction|groupeInstruction }[ ,...]
AS instructions;
nomDéclencheur
Correspond au nom du déclencheur. Chaque déclencheur est parfaitement identifié par son nom.
ALL SERVER
Avec cette option, le déclencheur est actif sur toute l’instance SQL Server dans laquelle il est défini.
DATABASE
Avec cette option, le déclencheur est déclenché uniquement sur la base sur laquelle il est défini.
typeInstruction
Type de l’instruction qui va déclencher l’exécution du déclencheur. Le déclencheur est toujours exécuté après
l’instruction qui le déclenche. Le type d’instruction correspond généralement à l’instruction DDL d’origine. Par exemple,
pour associer un déclencheur à l’instruction qui permet de créer une table (CREATE TABLE), le type de l’instruction est
CREATE_TABLE.
groupeInstruction
Groupe d’instructions qui provoque l’exécution du déclencheur.
instructions

Représente l’ensemble des instructions Transact SQL qui vont être exécutées. C’est la logique applicative du
déclencheur.
Plus généralement, la portée du déclencheur base ou bien instance va décider des éléments ou des groupes
d’éléments qui peuvent provoquer l’exécution du déclencheur. Le tableau avec la description des groupes d’instructions
est présent en annexe.
Exemple
Les écrans suivants illustrent la mise en place d’un déclencheur DDL qui permet de suivre les connexions des
utilisateurs.
La première étape consiste à définir la table qui va contenir toutes les informations de suivi des événements. Cette
table correspond au journal des actions DDL exécutées.
La seconde étape consiste à créer un déclencheur DDL qui sera actif au niveau de l’instance et qui va être déclenché
par les opérations de création, modification ou suppression de table sur la base de données GESCOM. Les informations
sont consignées dans la table journal.
Après quelques temps de fonctionnement, il est possible d’interroger la table journal pour suivre l’activité de la base.

Les déclencheurs de connexion
Les déclencheurs de connexion permettent d’exécuter une ou plusieurs instructions Transact SQL lors de la connexion
d’un utilisateur sur le serveur. Ce type de déclencheur peut être considéré comme un déclencheur DDL particulier. Ce
déclencheur s’exécute après la validation de l’authentification utilisateur sur le serveur et avant que le serveur donne la
main à l’utilisateur. La connexion utilisateur est donc établie et ouverte lorsque le déclencheur s’exécute. Etant donné
que l’exécution a lieu avant que l’utilisateur n’obtienne la main sur la console, les messages qui peuvent être produits
(erreur, print) sont redirigés directement vers le journal des erreurs de SQL Server.
Les déclencheurs de connexion peuvent être utilisés pour suivre ou limiter les connexions utilisateur. C’est par exemple
à ce niveau, qu’il sera possible de limiter le nombre de sessions ouvertes simultanément par un même utilisateur. C’est
également à ce niveau qu’il est possible d’enregistrer dans une table la date et l’heure d’établissement de la connexion.
Dans tous les cas, la fonction EVENTDATA permet d’obtenir toutes les informations relatives à la connexion qui vient de
s’établir.
Il est possible de définir plusieurs déclencheurs de connexion. Dans ce cas, la procédure stockée sp_settriggerorder
permet de définir quel déclencheur s’exécutera en premier et en dernier. Il n’est pas possible de fixer l’ordre d’exécution
des autres déclencheurs.
SQL Server met en place une transaction implicite avant d’exécuter le premier déclencheur de connexion. Cette
transaction est validée après l’exécution du dernier déclencheur. Toutefois si au cours de l’exécution des déclencheurs
de connexion, la transaction est achevée ou bien une erreur avec une gravité supérieure ou égale à 20 est levée, alors
l’établissement de la connexion utilisateur est impossible.
Syntaxe
CREATE TRIGGER nomDéclencheur

ON ALL SERVER [WITH EXECUTE AS contexteExecution]
FOR LOGON
AS
BEGIN
...
END;
Exemple :
Le déclencheur suivant permet de limiter à 3 le nombre de connexions ouvertes par un l’utilisateur nommé Pierre.
Attention toutefois à ne pas définir ce déclencheur afin qu’il s’exécute pour tous les utilisateurs, y compris les
administrateurs. En effet pour ces derniers, la limite des 3 connexions est trop juste car la réalisation de certaines tâches
administratives en mode graphique est plus confortable avec un nombre supérieur de connexions.
Les déclencheurs peuvent être supprimés à l’aide de l’instruction DROP TRIGGER nom Déclencheur ON {DATABASE | ALL
SERVER}[;]

Le PowerShell
Ce shell, introduit avec Windows Server 2008, permet de définir de puissants scripts d’administration. Cette version de
PowerShell vient s’enrichir d’outils spécifiques à chaque application serveur éditée par Microsoft.
Ce shell permet d’exécuter des instructions de façon directe ou bien sous forme de script.
SQL Server 2008 n’échappe pas à la règle et apporte son PowerShell qui intègre toutes les bibliothèques nécessaires
pour définir des scripts d’administration efficaces, fiables et condensés. Les apports de SQL Server 2008 au PowerShell
sont :
● L’intégration d’un fournisseur d’accès, ceci afin de pouvoir naviguer dans l’arborescence du serveur aussi
simplement qu’il est possible de le faire dans un système de fichiers, c’estàdire principalement avec les
instructions cd et dir. Ce fournisseur permet de se connecter à des instances SQL Server 2008 ou bien SQL
Server 2005 à condition que le Service Pack 2 soit installé. Il est également possible de se connecter à une
instance SQL Server 2000 munie du Service Pack 4. Bien entendu les instructions spécifiques à SQL Server 2008
ne sont pas applicables sur les versions antérieures.
● L’ajout d’applets de commande afin de pouvoir intégrer et exécuter une action SQL, notamment des scripts
Transact SQL. Toutes ces applets reposent sur la technologie SMO, aussi seules les instructions prises en
charge par SMO peuvent l’être au niveau du PowerShell. Ces applets de commande sont également dénommées
commandlet (CmdLet). Comme pour les autres instructions du PowerShell, elles ne sont pas sensibles à la
casse. Toutefois le respect de la casse permet de faciliter la lecture des instructions.
Si SQL Server 2008 est installé sur une plateforme Windows Server 2003, il est possible de télécharger et de
procéder à l’installation manuelle du PowerShell 1.0.
La console PowerShell est lancée par l’outil sqlps. Il est alors possible d’exécuter directement les scripts PowerShell.
L’applet GetHelp permet, comme toujours, de trouver toutes les informations relatives aux applets de commandes.
Pour SQL Server, il est possible de mettre en avant deux applets InvokeSqlcmd et InvokePolicyEvaluation.
Par exemple, pour obtenir de l’aide sur le fournisseur SQL Server, il est nécessaire d’exécuter l’instruction GetHelp
SQLServer et plus généralement pour obtenir de l’aide sur l’ensemble des fournisseurs : Get-Help-category provider.
Sur les applets de commande, il est possible d’utiliser les commutateurs Full, -Paramaters * et Examples pour afficher
différents niveaux d’aide.
Exemple
Lors du démarrage de sqlps un message concernant la version de SQL Server est affiché. Ces trois lignes de
messages peuvent être supprimées en exécutant sqlps-nologo.
L’utilitaire sqlps exécute la console PowerShell en mode restreint par défaut, ce qui interdit l’exécution de scripts
enregistrés sous la forme de fichiers. Il est possible de modifier ce niveau d’exécution en faisant appel à l’applet de
commande Set ExecutionPolicy.

Enfin, il est possible de démarrer la console PowerShell directement depuis SQL Server Management Studio en
sélectionnant l’option Démarrer PowerShell depuis le menu contextuel d’un nœ ud quelconque de l’explorateur
d’objets.
1. Le fournisseur PowerShell SQL Server
Avec le fournisseur PowerShell SQL Server, il est possible de naviguer à l’intérieur de la hiérarchie du serveur aussi
simplement que sur un système de fichiers.
Pour permettre cela, le fournisseur PowerShell SQL Server propose le lecteur SQLSERVER:. Ce lecteur est comparable
au lecteur C: que l’on rencontre habituellement sur le système de fichiers.
Le lecteur SQLSERVER est composé des quatre dossiers suivants :
SQL
Représente les objets de base de données. La navigation dans ces objets sera toujours de la forme :
SQLSERVER:SQL\nomServer\nomInstance, ce qui donne par exemple pour travailler sur la base gescom présente sur
l’instance par défaut du poste ARAVIS : SQLSERVER:SQL\ARAVIS\DEFAULT\Databases\Gescom
SQLPolicy
Pour gérer l’administration par les règles.
SQLRegistration
Pour l’inscription des serveurs et la gestion des groupes.
DataCollection
Pour représenter les objets du collecteur de données, naviguer dans cette arborescence les applets de commandes
PowerShell ou bien leurs alias vont être mis à contribution. Les principales applets de commande sont :
GetLocation
Afficher le nœ ud actuel.
SetLocation

Se positionner sur le nœ ud dont le chemin est passé en paramètre.
GetChildItem
Parcourir les enfants du nœ ud courant. Les objets système ne sont pas répertoriés par défaut, sauf si l’option force
est activée.
GetItem
Obtenir les informations relatives au nœ ud courant.
RenameItem
Renommer le nœ ud courant.
RemoveItem
Supprimer le nœ ud courant.
Exemple
Il est ainsi possible de faire de nombreuses opérations d’administration en combinant les ressources SQL Server avec
les éléments de syntaxe PowerShell. Par exemple, en se positionnant sur le nœ ud views, qui représente la collection
des vues, il est possible de parcourir chaque vue afin de générer le script de création.
foreach ($Item in Get-ChildItem){

$Item.Script()|Out-File - FilePath c:\test\creerVues.sql -append}
Les actions sous la forme de scripts vont fréquemment avoir la même base cible, aussi afin de limiter la longueur et la
complexité de l’applet de commande SetLocation, il est possible de définir des lecteurs qui accèdent directement à

une partie l’arborescence du serveur. Par exemple, il est possible de définir le lecteur Gescom comme étant l’accès
direct à la base Gescom.
Exemple :
New-PSDrive -Name GESCOM -Root SQLSERVER:\SQL\ARAVIS\DEFAULT\Databases\ Gescom
Pour faciliter la saisie des chemins, souvent longs, il est possible d’utiliser la touche [Tab] afin de compléter de façon
automatique la fin du chemin en sélectionnant la bonne option dans la liste proposée par PowerShell. Sur certaines
bases qui comportent de nombreux objets, la liste proposée peut être longue, aussi il est possible de réduire la liste
des propositions en configurant les variables suivantes :
$SqlServerMaximumTabCompletion, $SqlServerMaximumChildItems
et $SqlServerIncludeSystemObjects
Toutes ces connexions à l’instance SQL Server utilisent par défaut la sécurité Windows intégrée. Cela n’est pas
obligatoire et il est tout à fait possible de travailler avec la sécurité SQL Server pour se connecter à une instance SQL
Server. La fonction dont le script est présenté cidessous permet de définir un lecteur qui se connecte par
l’intermédiaire d’une authentification SQL Server (connexion u) à l’instance par défaut de l’ordinateur local (ARAVIS). Le
mot de passe est demandé lors de l’établissement du lecteur.
Function lecteurSQL{
Param([string]$nomLecteur,[string]$cnx="u",[string]
$chemin="SQLServer:\SQL\ARAVIS\DEFAULT")
$motDePasse= read-host -AsSecureString -Prompt "MotDePasse"
$credit=new-object System.Management.Automation.PSCredential
argumentlist $cnx,$motDePasse
New-PSDrive $nomLecteur -PSProvider SqlServer -Root $chemin
-Credential $credit -Scope 1
}
lecteurSQL SecuriteSQL
2. Les applets de commandes
Les applets de commandes PowerShell sont toutes formées d’un verbe et d’un nom. Cette construction permet de
trouver simplement et rapidement la bonne applet.
En complément des applets fournies en standard par le PowerShell, SQL Server n’apporte que peu d’applet de
commandes qui lui sont spécifiques. Il est toutefois possible de mettre en avant InvokeSqlcmd, Invoke
PolicyEvalution, EncodeSqlName, DecodeSqlName.
a. EncodeSqlName, DecodeSqlName
Ces deux applets ont pour objectif de traduire les caractères spéciaux qui peuvent être présents dans certains
identifiants d’objets SQL Server (bien que cela ne soit pas recommandé) et qui ne sont pas pris en charge par le
PowerShell ou bien mal interprétés.
Exemple

La chaîne passée en paramètre à l’applet EncodeSqlName retourne stocks%3Adepots et celle passée à decodeSqlName
retourne stock:depot.
b. InvokePolicyEvaluation
Cette applet de commande a pour objectif premier de s’assurer que la cible passée en paramètre est bien conforme
aux règles d’administration définies. En plus de cette vérification, il est possible de faire appel à cette même applet
pour configurer les différentes options des objets cibles afin qu’ils respectent les règles d’administration définies.
c. InvokeSqlcmd
Cette applet de commande qui permet d’exécuter des scripts Transact SQL ou bien XQuery fait appel à sqlcmd pour
les exécuter. Cette applet possède ses propres paramètres qui ne sont pas ceux de sqlcmd. Il est possible de fixer
les paramètres de sqlcmd en les passant sous la forme de chaîne de caractères à l’applet de commande.
Exemple

La gestion des règles
SQL Server 2008 introduit la notion de gestion par les règles. Ce type de gestion permet de définir des règles
d’administration et de les appliquer à une ou plusieurs instances SQL Server. En effet avec la multiplication des
instances SQL Server, parfois sur un même poste, il devient nécessaire d’avoir un outil pour simplifier l’administration
individuelle des différentes instances. Les règles peuvent également servir à administrer les bases de données
utilisateur.
Les règles vont permettre de définir un comportement commun à toutes les bases, instances et serveurs SQL Server
en rendant obligatoire ou non l’activation de certains services ou bien en forçant explicitement des règles de nommage
par exemple. Les règles vont permettre, entre autres, d’adopter une structure similaire sur des bases distincts ce qui
permet une compréhension plus facile des différentes bases et facilite ainsi l’administration car un socle commun est
défini.
La gestion par les règles peut être décomposée en trois composants importants :
● La définition et la gestion des règles ;
● Le mode d’exécution des règles ;
● L’administration directe.
Le terme règle peut être précisé en utilisant la notion de stratégie et de condition.
Une condition va permettre de s’assurer qu’un ou plusieurs critères de configuration sont respectés. L’application des
conditions ainsi définies est confiée aux stratégies. Chaque stratégie permet de vérifier une seule condition mais une
condition peut être référencée par plusieurs stratégies. En effet, une stratégie permet de définir les critères
d’application de la condition comme les cibles et le mode d’application de la stratégie.
La définition des conditions et des stratégies est enregistrée. Bien qu’il soit plus facile d’examiner les propriétés des
conditions et des stratégies depuis SQL Server Management Studio, il est possible d’interroger les vues système afin
de travailler sous forme de scripts.
1. Les conditions
Chaque condition est composée d’un ou de plusieurs critères combinés entre eux par les opérateurs logiques ET et
OU afin de pouvoir évaluer si la condition est respectée.
Les différents critères d’évaluation sont regroupés logiquement sous forme de facette. Ainsi, les différents
paramètres d’administration du serveur et des bases sont logiquement organisés et il est plus facile de trouver le ou
bien les critères à tester.
Chaque facette regroupe donc plusieurs conditions.

SQL Server propose des facettes prédéfinies. Chaque facette correspond à un domaine bien particulier de
l’administration de SQL Server.
2. Les stratégies
Une stratégie permet de mettre en place une facette (c’estàdire un ensemble de conditions) et de s’assurer du bon
respect de cellesci. Chaque stratégie est parfaitement identifiée par son nom. Une stratégie peut être active ou non
et possède quatre modes différents d’application:
● À la demande : la stratégie n’est pas active et c’est l’administrateur de bases de données qui décide quand il
est nécessaire de l’évaluer et de l’appliquer ;
● Selon planification ;
● Sur modification Journal ;
● Sur modification Evènement.
Afin de mieux identifier les différentes stratégies, il est possible de les organiser en catégories et de saisir une

description pour chacune d’entre elles. Il est également possible de saisir l’URL d’une page web d’aide ou bien
d’explication afin de permettre l’explication de la stratégie.
3. Mise en place
La mise en place des règles est facilitée depuis SQL Server Management Studio et s’opère depuis le nœ ud Gestion
Gestion de la stratégie de l’explorateur d’objets. À ce niveau, trois dossiers apparaissent représentant les facettes,
les conditions et les stratégies.
Il est alors possible au travers d’assistants de définir une ou plusieurs conditions. Pour créer une nouvelle condition, il
est nécessaire de sélectionner l’option Nouvelle condition depuis le menu contextuel du nœ ud Conditions.
Exemple
La condition MaCondition est définie.

Lorsque les conditions sont définies, il est possible de créer sa propre stratégie en sélectionnant l’option Nouvelle
stratégie depuis le menu contextuel du nœ ud Stratégies. Chaque stratégie permet de vérifier une condition. Lors de
la définition de la stratégie, le mode d’application est sélectionné ainsi que le paramétrage de la condition.
Exemple
Une stratégie d’application de la condition définie au préalable est établie.

La mise en miroir
1. Principes de fonctionnement
La mise en miroir des bases de données permet de garantir une solution de haute disponibilité tout en conservant un
investissement matériel raisonnable. En effet, dans ce type de haute disponibilité, une base est mise en miroir avec
une autre instance SQL Server. La base de données initiale porte le qualificatif de principal tandis que la base de
données cible porte le qualificatif miroir. Le rôle joué par chaque base est spécifique à chaque relation de mise en
miroir. Ce n’est pas parce qu’une instance héberge des bases qui jouent le rôle de principale dans une mise en miroir,
qu’elle ne peut pas héberger des bases miroir dans d’autres relations de mise en miroir.
Cette solution de haute disponibilité ne permet pas de se passer des opérations de sauvegarde. Il est préférable de
voir cette mise en miroir comme une solution complémentaire afin de garantir la meilleure disponibilité possible des
données.
La mise en miroir des bases s’effectue au travers du journal des transactions. Toutes les transactions effectuées sur
la base principale sont enregistrées dans le journal des transactions. Ces informations sont d’abord enregistrées en
mémoire puis, aussi rapidement que possible elles sont enregistrées sur disque. C’est lors de cette écriture sur
disque que les informations sont envoyées sur les miroirs. La base miroir enregistre alors ses informations sur
disque. Les transactions seront rejouées par la suite. Les deux bases (principale et miroir) contiennent ainsi les
mêmes informations.
La mise en miroir peut également être utilisée afin de garantir une forte protection des données face à un
dysfonctionnement du serveur principal. La différence entre haute protection et haute disponibilité tient au fait que
dans le premier cas ce sera une opération manuelle de l’administrateur qui permettra de promouvoir la base cible en
tant que base principale alors que dans la cas d’une solution de haute disponibilité le basculement doit être
automatique.
Une même instance SQL Server peut héberger des bases qui ne participent à une mise en miroir, des bases qui
possèdent le rôle principal, et des bases qui possèdent le rôle miroir.
Conjointement à cette relation, il peut exister un témoin qui va permettre d’automatiser le basculement vers la base
miroir en cas de défaillance de la base principale. En effet, le témoin va aider la base principale et/ou miroir à former
un quorum. Pour ce quorum les cas suivants peuvent être distingués :
● Le principal ne peut contacter la base miroir, mais le témoin reste accessible donc le quorum est formé du
principal et du témoin.
● Le principal peut contacter le miroir mais pas le témoin alors le quorum est formé du principal et du témoin.
● Le témoin et le miroir ne peuvent contacter le principal mais se voient entre eux. Alors le quorum est formé du
témoin et du miroir. Le miroir promeut le miroir en tant que principal.

Avec l’utilisation d’un témoin, la solution de haute disponibilité est garantie et transparente pour les applications
client, car il est possible de préciser l’instance de secours directement dans la chaîne de connexion. Ainsi les
développeurs d’applications, n’ont pas à prendre en charge le basculement vers le miroir car c’est le pilote SQL Server
qui se charge de cette opération.
Exemple
Exemple de chaîne de connexion :
Data Source=aravis;Failover Partner=tournette;Initial

Catalog=gescom;Integrated Security=SSPI
La mise en miroir nécessite quelques contraintes au niveau de la configuration dont les principales sont :
● Les deux instances SQL Server exécutent SQL Server 2008. Les éditions Workgroup et Express ne peuvent
que jouer le rôle de témoin.
● La base principale doit être configurée en mode de restauration complet afin de pouvoir suivre le journal des
transactions. Les importations en blocs (bulk logged) ne peuvent pas être reproduites de façon automatique
sur le miroir.
● La base miroir va être initialisée à partir d’une sauvegarde de la base principale. Afin de pouvoir rejouer les
journaux issus de la base principale cette restauration doit laisser la base miroir dans un état NOREVERY. La
base miroir, ne sera donc pas accessible directement aux utilisateurs qui auront alors l’obligation de toujours
travailler sur la base principale.
● La base miroir doit posséder exactement le même nom que la base principale.
● La mise en miroir va nécessairement affecter un peu les performances de la base principale car l’envoi des
journaux sur la base miroir est fait de façon synchrone. C’estàdire que la base principale s’assure que la
base miroir a bien reçu et enregistré le journal avant de poursuivre son travail. Ce transfert sur des journaux
(car celui de la base miroir est synchrone avec celui de la base principale) est configuré de la façon suivante
sur la base principale.
ALTER DATABASE basePrincipale SET SAFETY FULL;
Le témoin va permettre de déclencher le basculement automatique vers la base miroir en cas de défaillance de la
base principale.
La mise en miroir d’une base de données est toujours réalisée dans le contexte d’une session de mise en miroir. Au
cours de cette session, les deux bases partenaires possèdent un état afin de connaître le niveau de synchronisation.
Ces états sont :
SYNCHRONIZING
Les deux partenaires ne contiennent pas les mêmes informations. La base de données principale communique les
enregistrements du journal des transactions à la base de données miroir afin de reproduire les modifications.
SYNCHRONIZED
Les deux partenaires contiennent les mêmes informations.
SUSPENDED
La base principale travaille sans envoyer la copie du journal à la base miroir car cette dernière est déconnectée.
PENDING_FAILOVER
Une demande manuelle de basculement a été faite mais pas encore acceptée par les partenaires.
DISCONNECTED
Le contact avec le partenaire est perdu ainsi qu’éventuellement celui avec le témoin.
2. La mise en place

La mise en place d’une solution de mise en miroir est composée des principales étapes suivantes :
● Identifier l’instance principale et celle miroir ainsi que celle qui va jouer le rôle de témoin si cela est possible
dans votre solution de mise en miroir.
● Effectuer une sauvegarde complète de la base principale. La base principale aura été configurée en mode de
restauration complet avant d’effectuer la sauvegarde (ALTER DATABASEnomBase SET RECOVERY FULL). Cette
sauvegarde va être restaurée sur le miroir mais la base ne basculera pas en mode recovery, ceci afin de
permettre la restauration de fichiers journaux à venir. Les fichiers de la base miroir doivent pouvoir s’étendre
de la même façon que ceux de la base principale, car les deux bases vont occuper la même quantité d’espace
disque.
● L’instance principale et l’instance miroir vont communiquer dans ce processus de réplication. Il est donc
nécessaire de résoudre tous les problèmes de sécurité afin de permettre une connexion à l’instance distante.
Si les instances se situent dans le même domaine ou bien des domaines approuvés, il est possible de définir
une connexion (LOGIN) sur chaque serveur puis d’accorder le droit à cette connexion de se connecter au
travers d’un point de terminaison (GRANT CONNECT ON ENDPOINT). Dans le cas où les instances se situent
dans des domaines distincts sans relation d’approbation entre les deux, alors la connexion s’appuiera sur un
certificat au lieu de s’appuyer sur un compte Windows.
● Des points de terminaison (ENDPOINT) doivent être définis sur les deux serveurs. Ces points de terminaison
seront exclusivement dédiés à la mise en miroir de la base.
● Bien que toutes ces opérations puissent être définies à l’aide de script Transact SQL, étant donné que la mise
en miroir est une opération ponctuelle, il peut être intéressant de s’appuyer sur l’assistant de mise en place
proposé à partir du choix Tâches Miroir depuis le menu contextuel de la base de données à mettre en
miroir. Cette option permet d’afficher la page Mise en miroir des propriétés de la base. Au niveau de cette
page, il est possible d’exécuter l’assistant de configuration de sécurité mais il est également possible de
spécifier le serveur témoin (s’il existe) ainsi que le miroir.
Lorsque que cette étape de mise en place est réalisée, il est possible de suivre la bonne exécution de ce processus

et le basculement éventuel vers un miroir à l’aide du moniteur de mise en miroir de base de données. Il est
nécessaire d’inscrire toutes les mises en miroir que l’on souhaite suivre au travers de cet outil.

Ressource sur le Web
Adresse Description
http://www.apsql.com Informations diverses sur SQL Server
http://www.guss.fr Groupe des utilisateurs de SQL Server
http://www.microsoft.com/france/sql Site Web Français de SQL Server
http://www.microsoft.com/sql Site Web de SQL Server
http://msdn.microsoft.com MSDN
http://msdn.microsoft.com/frfr/SQL Centre de ressources SQL Server sur MSDN
http://www.microsoft.com/frfr/default.aspx Technet
http://microsoft.com/express/sql/default.aspx SQL Express
http://support.microsoft.com Support technique de Microsoft

Glossaire
ACL : Access Control List
ADF : Application Definition File
ADO : ActiveX Data Object

API : Application Programming Interface
AWE : Address Windowing Extensions
B2B : Business To Business

BCM : Bulk Change Map
BLOB : Binary Large Object

CLR : Common Language Runtime
COM : Component Object Model

CTE : Common Table Expression
DCM : Differential Change Map
DDL : Data Definition Language

DEK : Database Encryption Key
DML : Data Manipulation Language
DMV : Dynamic Management View
DTA : Database Tuning Advisor
DSS : Decision Support System
ETL : Extraction Transformation and Load

GC : Garbage Collector
GAC : Global Assembly Cache
GAM : Global Allocation Map
IAM : Index Allocation Map
ICF : Instance Configuration File

LCID : LocaleID
MARS : Multiple Active Result Set
MDAC : Microsoft Data Access Component
ODS : Open Data Services

OLTP : On Line Transaction Processing
OLAP : On Line Analytical Processing

PFS : Page Free Space
RID : Row Identifier

RMO : Replication Management Object
SCC : Setup Consistency Checker
SGAM : Shared Global Allocation Map

SMO : SQL Management Objects
SMTP : Simple Mail Transfer Protocol

SOA : Service Oriented Architecture
SOAP : Simple Object Access Protocol
SQL : Structure Query Language

TDE : Transparent Data Encryption

TSQL : Transact SQL
TVF : Table Valued Functions
UDF : User Defined aggregate Function
UDT : User Defined Types

WMI : Windows Management Instrumentation
XML : eXtensible Markup Language

SQL Server 2008 - Administration - 021101

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SQL Server 2008 - Administration - 021101

Transféré par

Droits d'auteur :

Formats disponibles

© ENI Editions - All rigths reserved - 1-

© ENI Editions - All rigths reserved - 1-

● comprendre la notion de SGBDR et le mode de fonctionnement client/serveur,

● présenter les composants de SQL Server et les plates­formes d’exécution,

● présenter l’architecture d’administration et de programmation,

1. Qu’est­ce qu’un SGBDR ?

● stocker les données,

● vérifier les contraintes d’intégrité définies,

Ce produit est complètement intégré à Windows et ce à plusieurs niveaux :

© ENI Editions - All rigths reserved - 1-

SQL Server peut gérer deux types de bases de données différentes :

2. Mode de fonctionnement Client/Serveur

Mode de fonctionnement Client/Serveur

On peut distinguer trois cas :

- 2- © ENI Editions - All rigths reserved

3. Les plates­formes possibles

© ENI Editions - All rigths reserved - 3-

4. Les composants de SQL Server

- 4- © ENI Editions - All rigths reserved

Ces outils sont :

© ENI Editions - All rigths reserved - 5-

awe enabled est une option de configuration avancée.

- 6- © ENI Editions - All rigths reserved

© ENI Editions - All rigths reserved - 7-

Administration de SQL Server

© ENI Editions - All rigths reserved - 1-

- 2- © ENI Editions - All rigths reserved

1. Objets de base de données

● Accès aux données : vues et procédures stockées.

● Gestion de l’intégrité complexe : déclencheur (procédure stockée s’exécutant automatiquement lors de

Objet de base de données

Nom complet des objets

2. Bases de données système et tables système

© ENI Editions - All rigths reserved - 1-

- 2- © ENI Editions - All rigths reserved

Bases de données utilisateur

3. Les tables système

Catalogue système (présent uniquement dans la base Master)

Table système Fonction

syslogins Une ligne pour chaque utilisateur ou groupe Windows autorisé à

sysdatabases Une ligne par base de données utilisateur.

sysconfigures Une ligne pour chaque option de configuration du serveur.

sysusers Une ligne pour chaque utilisateur défini dans la base.

sysobjects Une ligne pour chaque objet de la base de données.

Procédures stockées système

© ENI Editions - All rigths reserved - 3-

Procédure stockée Description

sp_help [nom_objet] Informations sur l’objet indiqué.

sp_helpdb [nom_base_données] Informations sur la base de données indiquée.

sp_helpindex [nom_table] Informations sur les index de la table indiquée.

sp_helplogins [nom_connexion] Informations sur la connexion indiquée.

sp_who Liste des utilisateurs actuellement connectés.

● Objets, types et index

- 4- © ENI Editions - All rigths reserved

● Information sur le serveur

Fonctions système Paramètre Description

DB_ID Nom Retrouve l’identificateur de la base de données.

USER_NAME ID Retrouve le nom de l’utilisateur à partir de son

COL_LENGTH Colonne Longueur de la colonne.

STATS_DATE Index Date de dernière mise à jour des statistiques.

DATALENGTH Type de données Longueur de l’expression.

© ENI Editions - All rigths reserved - 5-

● présenter les composants de SQL Server et les platesformes d’exécution,

1. Qu’estce qu’un SGBDR ?

3. Les platesformes possibles