SQL Server 2008 - Administration

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 plates­formes 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 doit­il 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 quasi­systé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. 

© ENI Editions - All rigths reserved

- 1-

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 plates­formes 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’est­ce 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...). 

© ENI Editions - All rigths reserved

- 1-

●

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 : 

- 2-

●

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. 

© 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 Transact­SQL. Ce langage de  requête de base de données respecte la norme ANSI SQL­92. 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 plates­formes possibles  Il est important de distinguer deux cas : d’un côté les plates­formes possibles pour le client et de l’autre les plates­ formes pour le serveur.  Les plates­formes 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 plates­formes 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  plate­forme  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. 

© ENI Editions - All rigths reserved

- 3-

  Dans le cas où le client héberge une application spécifique, la gamme des plates­formes 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 : 

- 4-

●

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. 

© ENI Editions - All rigths reserved

  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 OLE­DB 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  © ENI Editions - All rigths reserved

- 5-

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 plate­forme matérielle permet de  réaliser une telle opération.  Dans  le  cas  où  SQL  Server  s’exécute  sur  une  plate­forme  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  plate­forme  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 

- 6-

© ENI Editions - All rigths reserved

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 CLR­Transact 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. 

© ENI Editions - All rigths reserved

- 7-

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  © ENI Editions - All rigths reserved

- 1-

technologie  OLE­DB  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. 

- 2-

© ENI Editions - All rigths reserved

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 lui­mê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. 

© ENI Editions - All rigths reserved

- 1-

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 

- 2-

© ENI Editions - All rigths reserved

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 ci­dessous, 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éta­donné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_. 

© ENI Editions - All rigths reserved

- 3-

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 : 

- 4-

●

Objets, types et index 

●

Serveurs liés 

●

CLR 

●

Mise en miroir 

●

Service Broker 

●

Sécurité 

●

Transactions 

© ENI Editions - All rigths reserved

●

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.  Citons­en quelques­unes :  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

© ENI Editions - All rigths reserved

- 5-

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éta­donné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 

- 6-

© ENI Editions - All rigths reserved

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’auto­optimisation, il reste de nombreuses tâches à  l’administrateur.  Les principales tâches de l’administrateur sont :  ●

Gérer les services SQL Server ;  © ENI Editions - All rigths reserved

- 7-

●

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. 

- 8-

© ENI Editions - All rigths reserved

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 plates­formes 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 plates­formes 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  © ENI Editions - All rigths reserved

- 1-

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  plate­forme  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 multi­utilisateur.  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  - 2-

© ENI Editions - All rigths reserved

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 plate­forme. 

  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. 

© ENI Editions - All rigths reserved

- 3-

  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’entre­elles  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. 

- 4-

© ENI Editions - All rigths reserved

  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 point­virgule, 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 ;  © ENI Editions - All rigths reserved

- 5-

●

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. 

- 6-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 7-

 

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 :  ●

- 8-

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. 

© ENI Editions - All rigths reserved

●

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 ci­dessous : 

© ENI Editions - All rigths reserved

- 9-

  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. 

- 12 -

© ENI Editions - All rigths reserved

 

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. 

 

© ENI Editions - All rigths reserved

- 13 -

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 ci­dessous.  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 

- 14 -

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 15 -

  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. 

- 16 -

© ENI Editions - All rigths reserved

 

5. Exécuter le programme d’installation  Le  programme  d’installation  situé  sur  le  CD­Rom  de  SQL  Server  s’exécute  automatiquement  dès  que  le  CD­Rom  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 CD­Rom.  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 

© ENI Editions - All rigths reserved

- 17 -

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  plate­forme  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. 

- 18 -

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 1-

  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. 

- 2-

© ENI Editions - All rigths reserved

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 © ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

  Configuration de SQL Native Client 10.0 Cette fois­ci 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

© ENI Editions - All rigths reserved

- 3-

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. 

- 4-

© ENI Editions - All rigths reserved

 

© ENI Editions - All rigths reserved

- 5-

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 

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

  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. 

 

© ENI Editions - All rigths reserved

- 3-

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. 

- 4-

© ENI Editions - All rigths reserved

  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

© ENI Editions - All rigths reserved

- 5-

  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  - 6-

© ENI Editions - All rigths reserved

peut  parfois  être  intéressant  de  gérer  manuellement  certaines  ressources  afin  de  réaliser  une  optimisation  de  l’utilisation des ressources du serveur. Quelques­uns 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 

© ENI Editions - All rigths reserved

- 7-

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  elle­mê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  lui­mê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  multi­instance,  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  - 8-

© ENI Editions - All rigths reserved

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  plate­forme  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 : 

© ENI Editions - All rigths reserved

- 9-

 

- 10 -

© ENI Editions - All rigths reserved

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 

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 3-

  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]

- 4-

© ENI Editions - All rigths reserved

[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é ci­dessous 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. 

© ENI Editions - All rigths reserved

- 5-

  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 

- 6-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 7-

  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. 

- 8-

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 9-

  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 

- 10 -

© ENI Editions - All rigths reserved

catalogue système.  Parmi toutes ces vues, les trois présentées ci­dessous 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. 

© ENI Editions - All rigths reserved

- 11 -

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é. 

 

© ENI Editions - All rigths reserved

- 1-

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’est­ce 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  © ENI Editions - All rigths reserved

- 1-

é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. 

- 2-

© ENI Editions - All rigths reserved

  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  ci­dessous,  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. 

© ENI Editions - All rigths reserved

- 3-

  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. 

 

- 4-

© ENI Editions - All rigths reserved

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.  © ENI Editions - All rigths reserved

- 5-

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. 

- 6-

© ENI Editions - All rigths reserved

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. 

 

© ENI Editions - All rigths reserved

- 7-

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 : 

- 8-

●

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. 

© ENI Editions - All rigths reserved

●

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. 

© ENI Editions - All rigths reserved

- 9-

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. 

 

- 10 -

© ENI Editions - All rigths reserved

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] [ [,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 

© ENI Editions - All rigths reserved

- 1-

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 kilo­octets (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. 

- 2-

© ENI Editions - All rigths reserved

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é ci­dessous. 

  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. 

© ENI Editions - All rigths reserved

- 3-

  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  ci­dessous  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  - 4-

© ENI Editions - All rigths reserved

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  celui­ci  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|%]] )

© ENI Editions - All rigths reserved

- 5-

  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 :  ALTER DATABASE nomBaseDeDonnées ADD FILE spécificationFichier[;]

  Modifier et ajouter des fichiers depuis SQL Server Management Studio

- 6-

© ENI Editions - All rigths reserved

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. 

 

© ENI Editions - All rigths reserved

- 7-

  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. 

- 8-

© ENI Editions - All rigths reserved

 

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.  0  Permet de préciser que l’exécution portera sur la base courante. 

© ENI Editions - All rigths reserved

- 9-

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 : 

- 10 -

© ENI Editions - All rigths reserved

  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  ci­dessous  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 quelques­unes :  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. 

© ENI Editions - All rigths reserved

- 11 -

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 :  SQL Server Management Studio 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. 

- 12 -

© ENI Editions - All rigths reserved

  ALTER DATABASE

© ENI Editions - All rigths reserved

- 13 -

  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. 

- 14 -

© ENI Editions - All rigths reserved

  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. 

  © ENI Editions - All rigths reserved

- 15 -

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. 

 

- 16 -

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 17 -

  Pour  supprimer  une  base  depuis  SQL  Server  Management  Studio,  il  est  nécessaire  de  réaliser  les  opérations  suivantes : 

- 18 -

●

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. 

© ENI Editions - All rigths reserved

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  est­il  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  serait­il  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. 

© ENI Editions - All rigths reserved

- 1-

 

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 : 

- 2-

© ENI Editions - All rigths reserved

  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. 

 

© ENI Editions - All rigths reserved

- 3-

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.

- 4-

© ENI Editions - All rigths reserved

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 fois­ci, il est tout à fait possible d’inclure la définition de contraintes d’intégrité lors de la création de la table. 

 

© ENI Editions - All rigths reserved

- 1-

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  sous­jacente.  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 ci­dessous 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

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

 

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. 

© ENI Editions - All rigths reserved

- 3-

 

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. 

- 4-

© ENI Editions - All rigths reserved

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 : 

© ENI Editions - All rigths reserved

- 5-

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é ci­après, les trois types d’index sont créés par rapport à l’index XML principal défini sur la colonne 

- 6-

© ENI Editions - All rigths reserved

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é) );

© ENI Editions - All rigths reserved

- 7-

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. 

- 8-

© ENI Editions - All rigths reserved

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  sous­tables 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 sous­tables qui correspond à la table d’origine.  Chacune  de  ces  sous­tables  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  © ENI Editions - All rigths reserved

- 1-

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 : 

- 2-

●

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. 

© ENI Editions - All rigths reserved

 

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 ci­dessous, un schéma de partitionnement est défini par rapport à la fonction de partitionnement définie lors  de l’exemple précédent. 

© ENI Editions - All rigths reserved

- 3-

 

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-

© ENI Editions - All rigths reserved

 

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 

© ENI Editions - All rigths reserved

- 5-

 

- 6-

© ENI Editions - All rigths reserved

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,  est­il  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. 

 

© ENI Editions - All rigths reserved

- 1-

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. 

© ENI Editions - All rigths reserved

- 1-

  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. 

- 2-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 1-

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.  Quelques­unes  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. 

© ENI Editions - All rigths reserved

- 1-

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. 

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

 

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 ci­après. 

© ENI Editions - All rigths reserved

- 3-

  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. 

- 4-

© ENI Editions - All rigths reserved

Création d’une connexion  Dans le schéma ci­dessus, 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.  SQL Server Management Studio 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. 

© ENI Editions - All rigths reserved

- 5-

●

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 : 

- 6-

© ENI Editions - All rigths reserved

 

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.  SQL Server Management Studio 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. 

© ENI Editions - All rigths reserved

- 7-

  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 

- 8-

© ENI Editions - All rigths reserved

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 ; 

© ENI Editions - All rigths reserved

- 9-

●

une identification telle que le nom et l’adresse e­mail ; 

●

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. 

- 10 -

© ENI Editions - All rigths reserved

  Il  est  possible  d’avoir  toutes  les  informations  relatives  aux  credentials  déjà  définis  sur  le  serveur  en  interrogeant la vue sys.credential. 

SQL Server Management Studio 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 

© ENI Editions - All rigths reserved

- 11 -

 

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.  SQL Server Management Studio 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. 

- 12 -

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 13 -

 

- 14 -

© ENI Editions - All rigths reserved

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.  SQL Server Management Studio 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. 

© ENI Editions - All rigths reserved

- 1-

●

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 :  ●

- 2-

1  :  SQL  Server  tente  d’associer  le  compte  d’utilisateur  de  base  de  données  à  une  connexion  qui  porte  le  même nom. 

© ENI Editions - All rigths reserved

●

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  SQL Server Management Studio 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é. 

© ENI Editions - All rigths reserved

- 3-

  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. 

- 4-

© ENI Editions - All rigths reserved

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.  SQL Server Management Studio 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. 

© ENI Editions - All rigths reserved

- 5-

  Transact SQL L’instruction ALTER USER permet de réaliser cette opération.  Syntaxe:  ALTER USER nomUtilisateur WITH NAME=nouveauNomUtilisateur, DEFAULT_SCHEMA = nomNouveauSchema Exemple 

- 6-

© ENI Editions - All rigths reserved

 

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.  SQL Server Management Studio 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. 

© ENI Editions - All rigths reserved

- 7-

  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: 

 

- 8-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 1-

 

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éé. 

- 2-

© ENI Editions - All rigths reserved

  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. 

a. SQL Server Management Studio  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. 

© ENI Editions - All rigths reserved

- 3-

 

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. 

- 4-

© ENI Editions - All rigths reserved

 

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. 

a. SQL Server Management Studio  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. 

© ENI Editions - All rigths reserved

- 5-

 

b. Transact SQL  DROP SCHEMA nomSchema Exemple 

 

- 6-

© ENI Editions - All rigths reserved

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 ci­dessous 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. 

© ENI Editions - All rigths reserved

- 1-

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  SQL Server Management Studio 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. 

- 2-

© ENI Editions - All rigths reserved

  Transact SQL L’accord de privilèges s’effectue en utilisant l’instruction GRANT dont la syntaxe est détaillée ci­dessous.  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. 

© ENI Editions - All rigths reserved

- 3-

 

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.  SQL Server Management Studio 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. 

- 4-

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 5-

 

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.  SQL Server Management Studio 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  de la base de données.  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. 

- 6-

© ENI Editions - All rigths reserved

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

 

© ENI Editions - All rigths reserved

- 7-

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  SQL Server Management Studio Les privilèges d’utilisation des objets peuvent être gérés à deux niveaux dans SQL Server Management Studio :  ●

- 8-

au niveau utilisateur, ce qui permet de connaître les possibilités de travail que possède chaque utilisateur. 

© ENI Editions - All rigths reserved

●

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[,...] TO utilisateur [,...] [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 ANSI­92. 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.    © ENI Editions - All rigths reserved

- 9-

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 ci­dessous, 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é.  SQL Server Management Studio 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. 

- 10 -

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 11 -

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.  SQL Server Management Studio 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.  Est­ce  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. 

- 12 -

© ENI Editions - All rigths reserved

  Transact SQL DENY {ALL [PRIVILEGES]|permission[(colonne,[,...])] [,...]} ON object [(colonne [,...])] TO utilisateur [,...] [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. 

© ENI Editions - All rigths reserved

- 13 -

 

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. 

SQL Server Management Studio Les droits relatifs à l’utilisation peuvent être attribués de la façon suivante depuis SQL Server Management Studio : 

- 14 -

●

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. 

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 15 -

  Les privilèges qu’il est possible d’accorder à ce niveau sont : 

- 16 -

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 

© ENI Editions - All rigths reserved

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 

© ENI Editions - All rigths reserved

- 17 -

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. 

- 18 -

© ENI Editions - All rigths reserved

  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. Est­ce 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. 

© ENI Editions - All rigths reserved

- 19 -

 

- 20 -

© ENI Editions - All rigths reserved

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  sous­jacentes.  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. 

   

© ENI Editions - All rigths reserved

- 1-

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

- 2-

© ENI Editions - All rigths reserved

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 

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

Exécution de sp_helpsrvrole pour connaître les rôles de serveurs fixes 

SQL Server Management Studio 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. 

 

© ENI Editions - All rigths reserved

- 3-

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 : 

- 4-

© ENI Editions - All rigths reserved

 

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 

© ENI Editions - All rigths reserved

- 5-

  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  de la base de données.  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.

- 6-

© ENI Editions - All rigths reserved

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 : 

© ENI Editions - All rigths reserved

- 7-

  Comme l’ensemble des opérations d’administration, il est possible de gérer les rôles de deux façons différentes :  SQL Server Management Studio 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éé. 

- 8-

© ENI Editions - All rigths reserved

  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 : 

© ENI Editions - All rigths reserved

- 9-

  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 : 

- 10 -

© ENI Editions - All rigths reserved

  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  © ENI Editions - All rigths reserved

- 11 -

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  eux­mê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. 

a. SQL Server Management Studio  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éé. 

- 12 -

© ENI Editions - All rigths reserved

  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 : 

© ENI Editions - All rigths reserved

- 13 -

  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}

- 14 -

© ENI Editions - All rigths reserved

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 : 

© ENI Editions - All rigths reserved

- 15 -

 

- 16 -

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 1-

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. 

© ENI Editions - All rigths reserved

- 1-

  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. 

 

- 2-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 3-

 

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 non­membres 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 sous­systèmes et des proxies pour gérer au mieux  tous les éléments de sécurité.  Le sous­systè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  sous­systè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 

- 4-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 5-

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

- 6-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 7-

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

 

- 8-

© ENI Editions - All rigths reserved

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 e­mail à 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 : [email protected]) 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 radio­messagerie. 

© ENI Editions - All rigths reserved

- 1-

SQL Server Management Studio 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 : 

- 2-

© ENI Editions - All rigths reserved

  Toutes les procédures stockées sont dans la base msdb, la première instruction du script doit donc être use  msdb. 

2. Modification  SQL Server Management Studio 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. 

 

© ENI Editions - All rigths reserved

- 3-

  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. 

- 4-

© ENI Editions - All rigths reserved

 

3. Suppression  La suppression d’un opérateur n’est possible que si ce dernier n’est pas opérateur de défaillance.  SQL Server Management Studio 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. 

© ENI Editions - All rigths reserved

- 5-

 

- 6-

© ENI Editions - All rigths reserved

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 : celui­ci 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. 

© ENI Editions - All rigths reserved

- 1-

 

  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-

© ENI Editions - All rigths reserved

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 sous­systè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. 

© ENI Editions - All rigths reserved

- 3-

  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. 

- 4-

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 5-

 

- 6-

© ENI Editions - All rigths reserved

 

© ENI Editions - All rigths reserved

- 7-

 

- 8-

© ENI Editions - All rigths reserved

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

© ENI Editions - All rigths reserved

- 9-

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 : 

© ENI Editions - All rigths reserved

- 1-

●

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. 

- 2-

© ENI Editions - All rigths reserved

 

c. Mise en place  SQL Server Management Studio 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. 

© ENI Editions - All rigths reserved

- 3-

  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. 

- 4-

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 5-

  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

- 6-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 7-

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 :  ●

- 8-

méthode d’accès, 

© ENI Editions - All rigths reserved

●

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 au­delà 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. 

 

© ENI Editions - All rigths reserved

- 9-

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.  © ENI Editions - All rigths reserved

- 1-

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 : 

- 2-

© ENI Editions - All rigths reserved

 

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’agit­il 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 

­ source de données ODBC 

Oui 

Oui 

­ source de données OLEDB 

Oui 

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  

© ENI Editions - All rigths reserved

- 3-

­ graphique 

Oui 

Oui 

­ ligne de commande 

Oui 

Planification possible 

Oui 

Transformation de données 

Oui 

Performances maximales 

- 4-

Oui 

Opération ponctuelle 

Oui 

Opération régulière 

Oui 

Oui 

Oui 

Oui 

Oui  Oui 

Oui 

Oui 

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 1-

  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 ci­dessus c’est le résultat d’une requête qui est exporté dans un fichier de données. 

- 2-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 3-

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. 

© ENI Editions - All rigths reserved

- 1-

  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 : 

- 2-

●

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. 

© ENI Editions - All rigths reserved

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 sous­ensemble 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 celle­ci.  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. 

© ENI Editions - All rigths reserved

- 3-

  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  - 4-

© ENI Editions - All rigths reserved

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 ci­dessous illustre quelques­unes 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. 

© ENI Editions - All rigths reserved

- 5-

  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,  ceux­ci  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. 

- 6-

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 7-

 

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.  SQL Server Management Studio 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.  - 8-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 9-

  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 : 

- 10 -

●

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. 

© ENI Editions - All rigths reserved

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

© ENI Editions - All rigths reserved

- 11 -

  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. 

- 12 -

© ENI Editions - All rigths reserved

  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 ci­aprè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. 

© ENI Editions - All rigths reserved

- 13 -

  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 : 

- 14 -

●

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. 

© ENI Editions - All rigths reserved

●

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 ci­dessous 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. 

© ENI Editions - All rigths reserved

- 15 -

  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é ci­dessous le package SSIS est composé de deux tâches avant d’exécuter le transfert de 

- 16 -

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 17 -

  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. 

- 18 -

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 1-

  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. 

- 2-

© ENI Editions - All rigths reserved

 

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  savoir­vivre  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 :  ●

Puis­je poser une question ? 

●

Oui, 

●

Quelle heure est­il ? 

●

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 

© ENI Editions - All rigths reserved

- 3-

é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. 

- 4-

© ENI Editions - All rigths reserved

 

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. 

 

© ENI Editions - All rigths reserved

- 5-

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 

© ENI Editions - All rigths reserved

- 1-

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 ci­dessous 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. 

- 2-

●

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. 

© ENI Editions - All rigths reserved

●

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. 

© ENI Editions - All rigths reserved

- 3-

 

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 est­il 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 : 

- 4-

●

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é 

© ENI Editions - All rigths reserved

●

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. 

© ENI Editions - All rigths reserved

- 5-

 

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. 

- 6-

© ENI Editions - All rigths reserved

 

© ENI Editions - All rigths reserved

- 7-

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 ci­dessus 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 

© ENI Editions - All rigths reserved

- 1-

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 

- 2-

© ENI Editions - All rigths reserved

  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

© ENI Editions - All rigths reserved

- 3-

[ 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. 

- 4-

© ENI Editions - All rigths reserved

 

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. 

© ENI Editions - All rigths reserved

- 5-

 

- 6-

© ENI Editions - All rigths reserved

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, celui­ci 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 non­modification.  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 

© ENI Editions - All rigths reserved

- 1-

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

 

- 2-

© ENI Editions - All rigths reserved

Service Broker entre deux bases distinctes  Cette fois­ci 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. 

© ENI Editions - All rigths reserved

- 1-

  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. 

- 2-

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 3-

 

●

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. 

- 4-

© ENI Editions - All rigths reserved

  Sauvegarder les certificats. 

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

© ENI Editions - All rigths reserved

- 5-

  Accorder la permission de se connecter à l’utilisateur. 

  Accorder la permission d’envoyer un message. 

- 6-

© ENI Editions - All rigths reserved

  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é. 

© ENI Editions - All rigths reserved

- 7-

 

●

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

 

- 8-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 1-

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. 

© ENI Editions - All rigths reserved

- 1-

  Dans l’exemple ci­dessus, 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. 

- 2-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 3-

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. 

- 4-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 5-

  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. 

- 6-

© ENI Editions - All rigths reserved

Les modèles de la réplication  Dans  SQL  Server,  les  différents  modèles  de  réplication  utilisent  la  métaphore  "Editeur­Abonné"  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 :  © ENI Editions - All rigths reserved

- 1-

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 : 

- 2-

●

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. 

© ENI Editions - All rigths reserved

●

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. 

© ENI Editions - All rigths reserved

- 3-

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  CD­Rom.  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. 

- 4-

© ENI Editions - All rigths reserved

  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.

© ENI Editions - All rigths reserved

- 5-

5. Les modèles physiques de réplication  Tous  les  modèles  physiques  présentés  ci­aprè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 central­abonné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. 

 

 

- 6-

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 7-

 

c. Éditeurs multiples­abonné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 : 

- 8-

●

trois magasins dans la station A altitude 1800, 

●

deux magasins dans la station A altitude 1600, 

© ENI Editions - All rigths reserved

●

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  faut­il 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. 

© ENI Editions - All rigths reserved

- 9-

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 sous­ensemble 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. 

© ENI Editions - All rigths reserved

- 1-

Filtrage horizontal Il s’agit dans ce cas de publier un sous­ensemble 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  non­disponibilité  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 fois­ci 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  - 2-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 3-

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. 

© ENI Editions - All rigths reserved

- 1-

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

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

●

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. 

© ENI Editions - All rigths reserved

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. 

 

© ENI Editions - All rigths reserved

- 3-

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  ci­dessous,  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. 

- 4-

© ENI Editions - All rigths reserved

    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. 

© ENI Editions - All rigths reserved

- 5-

  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 elle­mê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. 

- 6-

© ENI Editions - All rigths reserved

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 :  SQL Server Management Studio 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. 

© ENI Editions - All rigths reserved

- 7-

●

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  sous­ensemble  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. 

- 8-

© ENI Editions - All rigths reserved

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  ci­dessous,  seule  la  base  Gescom  est  activée  pour  la  réplication,  alors  que  toutes  les  bases  sont  présentes dans la fenêtre. 

© ENI Editions - All rigths reserved

- 9-

  L’assistant demande alors de préciser le type de réplication à laquelle cette publication va participer.  Dans l’exemple ci­dessous, 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 

- 10 -

© ENI Editions - All rigths reserved

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 ci­dessous, 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. 

© ENI Editions - All rigths reserved

- 11 -

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,  est­il  nécessaire  de  publier  la  totalité  de  la  table  clients  ou  bien  faut­il  limiter  la  réplication  aux  seuls  clients  d’une  zone géographique bien définie ? 

- 12 -

© ENI Editions - All rigths reserved

  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 ci­après, la création d’une capture instantanée est demandée et cette capture sera effectuée une fois  par mois. 

 

© ENI Editions - All rigths reserved

- 13 -

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. 

- 14 -

© ENI Editions - All rigths reserved

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. 

 

© ENI Editions - All rigths reserved

- 15 -

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 ci­dessous : 

  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. 

- 16 -

© ENI Editions - All rigths reserved

  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 ci­dessous, c’est une  instance différente de SQL Server qui est sélectionnée en tant qu’abonné. 

© ENI Editions - All rigths reserved

- 17 -

  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é  ci­dessous,  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. 

- 18 -

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 19 -

  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. 

- 20 -

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 21 -

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 

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

  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é. 

© ENI Editions - All rigths reserved

- 3-

  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. 

- 4-

© ENI Editions - All rigths reserved

  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 

© ENI Editions - All rigths reserved

- 5-

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

- 6-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 1-

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 sont­elles plus sujettes que d’autres aux modifications ? 

●

Combien de temps la base de données peut­elle rester indisponible ? 

●

La perte de modifications est­elle cruciale ? 

●

Est­il facile de recréer les données perdues ? 

●

Quelles sont les périodes importantes d’utilisation de la base de données ? 

●

La  base  subit­elle  des  surcharges  de  travail  ponctuelles  pendant  lesquelles  il  n’est  pas  envisageable  de  lancer une sauvegarde ? 

●

Les utilisateurs doivent­ils 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 sont­elles conservées de façon cyclique ? 

●

Le serveur SQL est­il en cluster ? 

●

Le serveur SQL est­il 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. 

© ENI Editions - All rigths reserved

- 1-

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][;]   - 2-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 3-

  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  - 4-

© ENI Editions - All rigths reserved

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. 

  © ENI Editions - All rigths reserved

- 5-

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  ci­dessus,  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.

- 6-

© ENI Editions - All rigths reserved

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 ALTER DATABASE nomBaseDeDonnées 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é ci­dessous pour configurer la base Gescom en mode de récupération complet. 

© ENI Editions - All rigths reserved

- 1-

 

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,  celui­ci 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. 

- 2-

© ENI Editions - All rigths reserved

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 en­tê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. 

© ENI Editions - All rigths reserved

- 3-

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. 

- 4-

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 5-

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. 

 

- 6-

© ENI Editions - All rigths reserved

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 ci­dessous illustre comment demander l’exécution d’une sauvegarde depuis SQL Server Management Studio. 

© ENI Editions - All rigths reserved

- 7-

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

 

- 8-

© ENI Editions - All rigths reserved

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 

© ENI Editions - All rigths reserved

- 9-

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. 

- 10 -

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 11 -

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 

- 12 -

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 13 -

 

 

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. 

- 14 -

© ENI Editions - All rigths reserved

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 ci­dessous : 

  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. 

© ENI Editions - All rigths reserved

- 15 -

  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. 

- 16 -

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 17 -

  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. 

 

- 18 -

© ENI Editions - All rigths reserved

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  ci­après  mais  il  est  également  possible  de  passer  par  SQL  Server  Management Studio.  RESTORE HEADERONLY

© ENI Editions - All rigths reserved

- 1-

Permet de connaître les informations contenues dans l’en­tê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  ci­dessous  permet  de  connaître  la  connexion,  le  nom  du  programme  et  le  poste  utilisé pour établir les connexions utilisateur (is_user_process=1). 

- 2-

© ENI Editions - All rigths reserved

  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 mono­utilisateur.  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.

© ENI Editions - All rigths reserved

- 3-

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 

- 4-

© ENI Editions - All rigths reserved

© ENI Editions - All rigths reserved

- 5-

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.

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

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 

© ENI Editions - All rigths reserved

- 3-

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 

- 4-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 5-

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.  - 6-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 7-

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. 

- 8-

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 9-

 

- 10 -

© ENI Editions - All rigths reserved

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 ci­après, la sauvegarde de la base Gescom est faite à destination d’une unité physique. 

© ENI Editions - All rigths reserved

- 1-

  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. 

- 2-

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 3-

  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 

- 4-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 5-

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. 

© ENI Editions - All rigths reserved

- 1-

  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. 

- 2-

© ENI Editions - All rigths reserved

  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 

© ENI Editions - All rigths reserved

- 3-

é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  l’instance SQL Server.  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. 

- 4-

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 5-

  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 mono­utilisateur avec l’option ­m. En effet, en  mode  mono­utilisateur,  l’audit  ne  peut  pas  bloquer  le  démarrage,  toutefois  l’évènement  MSG_AUDIT_SHUTDOWN_BYPASS sera inscrit dans le journal. 

- 6-

© ENI Editions - All rigths reserved

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  sont­ils  sélectionnés  ?  Quelles  informations  faut­il  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  l’instance SQL Server. 

●

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. 

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 3-

  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. 

- 4-

© ENI Editions - All rigths reserved

  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. 

 

© ENI Editions - All rigths reserved

- 5-

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 

- 6-

© ENI Editions - All rigths reserved

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

Lecture d’une trace 

© ENI Editions - All rigths reserved

- 7-

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. 

© ENI Editions - All rigths reserved

- 1-

●

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.  - 2-

© ENI Editions - All rigths reserved

É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. 

© ENI Editions - All rigths reserved

- 3-

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 : 

© ENI Editions - All rigths reserved

- 1-

●

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. 

- 2-

© ENI Editions - All rigths reserved

Configuration de la mémoire de SQL Server 

© ENI Editions - All rigths reserved

- 3-

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. 

© ENI Editions - All rigths reserved

- 1-

  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. 

- 2-

© ENI Editions - All rigths reserved

 

© ENI Editions - All rigths reserved

- 3-

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. 

© ENI Editions - All rigths reserved

- 1-

  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’info­bulles. Ces infos­bulles peuvent contenir les informations suivantes : 

- 2-

●

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. 

© ENI Editions - All rigths reserved

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. 

© ENI Editions - All rigths reserved

- 3-

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. 

© ENI Editions - All rigths reserved

- 1-

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. 

© ENI Editions - All rigths reserved

- 1-

  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. 

- 2-

© ENI Editions - All rigths reserved

  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. 

© ENI Editions - All rigths reserved

- 3-

 

- 4-

© ENI Editions - All rigths reserved

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 

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

 

© ENI Editions - All rigths reserved

- 3-

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}[;] 

© ENI Editions - All rigths reserved

- 1-

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 plate­forme 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  Get­Help  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 Invoke­Sqlcmd et Invoke­PolicyEvaluation.  Par  exemple,  pour  obtenir  de  l’aide  sur  le  fournisseur  SQL  Server,  il  est  nécessaire  d’exécuter  l’instruction  Get­Help  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. 

© ENI Editions - All rigths reserved

- 1-

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 :  Get­Location  Afficher le nœ ud actuel.  Set­Location 

- 2-

© ENI Editions - All rigths reserved

Se positionner sur le nœ ud dont le chemin est passé en paramètre.  Get­ChildItem  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.  Get­Item  Obtenir les informations relatives au nœ ud courant.  Rename­Item  Renommer le nœ ud courant.  Remove­Item  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  Set­Location, il est possible de définir des lecteurs qui accèdent directement à  © ENI Editions - All rigths reserved

- 3-

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é  ci­dessous  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  Invoke­Sqlcmd,  Invoke­ PolicyEvalution, Encode­SqlName, Decode­SqlName. 

a. Encode­SqlName, Decode­SqlName  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 

- 4-

© ENI Editions - All rigths reserved

La chaîne passée en paramètre à l’applet  Encode­SqlName retourne stocks%3Adepots et celle passée à decode­SqlName  retourne stock:depot. 

 

b. Invoke­PolicyEvaluation  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. Invoke­Sqlcmd  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 

 

© ENI Editions - All rigths reserved

- 5-

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 celles­ci. 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 

© ENI Editions - All rigths reserved

- 1-

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. 

- 2-

© ENI Editions - All rigths reserved

  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. 

 

© ENI Editions - All rigths reserved

- 3-

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. 

© ENI Editions - All rigths reserved

- 1-

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  - 2-

© ENI Editions - All rigths reserved

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 

© ENI Editions - All rigths reserved

- 3-

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. 

- 4-

© ENI Editions - All rigths reserved

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/fr­fr/SQL 

Centre de ressources SQL Server sur MSDN 

http://www.microsoft.com/fr­fr/default.aspx 

Technet 

http://microsoft.com/express/sql/default.aspx 

SQL Express 

http://support.microsoft.com 

Support technique de Microsoft 

© ENI Editions - All rigths reserved

- 1-

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 

© ENI Editions - All rigths reserved

- 1-

TSQL : Transact SQL  TVF : Table Valued Functions  UDF : User Defined aggregate Function  UDT : User Defined Types  WMI : Windows Management Instrumentation  XML : eXtensible Markup Language 

- 2-

© ENI Editions - All rigths reserved