SQL Server Administration. Résumé. Jérôme GABILLAUD. ENI Editions - All rigths reserved

Transcription

1

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

3 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

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

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

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

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

8 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 - 5 -

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

10 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

11 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 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 - 1 -

12 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

13 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

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

15 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 sysmessages sysdatabases sysconfigures sysusers syscolumns sysobjects Une ligne pour chaque utilisateur ou groupe Windows autorisé à se connecter au serveur SQL. Une ligne pour chaque message d erreur défini et pour chaque langue. Une ligne par base de données utilisateur. Une ligne pour chaque option de configuration du serveur. Une ligne pour chaque utilisateur défini dans la base. Une ligne pour chaque colonne des tables, vues et pour chaque paramètre des procédures stockées. 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_

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

17 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 - 5 -

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

19 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 ; - 7 -

20 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

21 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 - 1 -

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

23 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 plateforme choisie est prête pour une installation de SQL Server 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

24 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

25 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 ; - 5 -

26 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

27 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

28 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 caractères différents ce qui est suffisant pour coder la totalité des caractères utilisés par les différentes langues occidentales. Cette solution avec les pages de codes n est acceptable que si l on stocke dans la base de données uniquement des données en provenance d une seule langue. Or, avec la montée en puissance des applications de commerce électronique, les bases de données vont de plus en plus souvent contenir des informations (comme les nom, prénom et adresse des clients) en provenance de différentes langues. Pour pouvoir supporter les caractères spécifiques à chaque langue, il faut utiliser le type de données Unicode. Les données de type Unicode sont conservées dans les types nchar et nvarchar. Au niveau de l application cliente, qui permet la saisie et l affichage des informations, le type de données Unicode doit également être supporté. L espace réclamé par le type de données Unicode est deux fois plus important que pour les données non Unicode. Mais, ce léger désavantage est largement compensé par le temps gagné lors de l affichage des données sur le poste client. En effet, avec le type de données Unicode, il n est plus nécessaire de réaliser un mappage entre la page de code utilisée dans la base de données pour stocker l information, et la page de code utilisée sur le poste client pour afficher l information. Le classement correspond à un modèle binaire de représentation des données et qui permet de définir des règles de comparaisons ainsi que des règles de tris. Par exemple, le classement permet de définir sur la langue française comment les caractères accentués doivent être pris en compte lors d opération de comparaison et de tris. Il existe par défaut trois types de classements : les classements Windows qui s appuient sur les paramètres de langues définies au niveau Windows. En s appuyant sur ce type de classement, les ordres de tris, de comparaisons s adaptent automatiquement à la langue du serveur

29 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 : - 9 -

30 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

31 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

32 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

33 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

34 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 à 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

35 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

36 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

37 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

38 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 ( 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 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

39 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

40 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

41 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 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 - 1 -

42 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

43 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 - 3 -

44 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

45 - 5 -

46 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 - 1 -

47 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

48 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

49 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

50 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 - 5 -

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

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

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

54 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 : - 9 -

55 - 10 -

56 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 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 - 1 -

57 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

58 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

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

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

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

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

63 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

64 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

65 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

66 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

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

68 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 - 1 -

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

70 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 P

71 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

72 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

73 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

74 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

75 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 entête de la page afin d en maitriser la gestion. Si plusieurs lignes sont stockées dans la même page, elles le sont de façon séquentielle. En cas de changement de taille des lignes, SQL Server gère dynamiquement le déplacement des lignes dans la page ou bien la mise en place d un pointeur vers une autre page afin de lire la fin de la ligne de données. Étant donné que la page est l unité de travail de SQL Server, chaque page contient un type bien précis de données. Il est possible de distinguer les types de page suivants : données : ces pages contiennent des informations au format numérique, texte ou bien date. Texte/image : ces pages contiennent soit des textes volumineux, soit des objets au format binaire. Index : ces pages contiennent les entrées des index. GAM/SGAM : ou Global Allocation Map et Shared Global Allocation Map. Ces pages contiennent des informations relatives à l allocation des extensions. PFS : ou Page Free Space. Ces pages contiennent les informations relatives à l allocation des pages et l espace disponible sur ces pages. IAM : ou Index Allocation Map. Ces pages contiennent les informations relatives à l utilisation de pages par les tables et les index

76 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

77 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

78 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 bases de données. 1. Créer une base de données La création d une base de données est une étape ponctuelle, réalisée par un administrateur SQL Server. Avant de tenter de créer une base de données, il est important de définir un certain nombre d éléments de façon précise : le nom de la base de données qui doit être unique sur le serveur SQL, la taille de la base de données, les fichiers utilisés pour le stockage des données. Pour créer une nouvelle base de données, SQL Server s appuie sur la base Model. Cette base Model contient tous les éléments qui vont être définis dans les bases utilisateurs. Par défaut, cette base Model contient les tables système. Il est cependant tout à fait possible d ajouter des éléments dans cette base. Toutes les bases utilisateurs créées par la suite disposeront de ces éléments supplémentaires. Une base peut être créée de deux façons différentes : par l intermédiaire de l instruction Transact SQL CREATE DATABASE ; par l intermédiaire de SQL Server Management Studio. Une base de données est toujours composée au minimum d un fichier de données principal (extension mdf) et d un fichier journal (extension ldf). Des fichiers de données secondaires (ndf) peuvent être définis lors de la création de la base ou bien ultérieurement. Cette opération de création de base de données affecte la base Master. Une sauvegarde de cette base système s avère donc nécessaire pour être en mesure de travailler avec la nouvelle base suite à une restauration. Les informations concernant les fichiers de données sont enregistrées dans la base Master ainsi que dans le fichier primaire de la base de données. a. La syntaxe Transact SQL CREATE DATABASE nombasededonnées [ ON [PRIMARY] [ <spécificationfichier> [,n]] [LOG ON < spécificationfichier > [,n]] ] [ COLLATE classement ] [;] Avec pour spécificationfichier les éléments de syntaxe suivants : (NAME = nomlogique, FILENAME = cheminetnomfichier [,SIZE = taille [KB MB GB TB]] [,MAXSIZE={tailleMaximum[KB MB GB TB] UNLIMITED}] [,FILEGROWTH = pasincrement [KB MB GB TB %]] ) [,n] PRIMARY - 1 -

79 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

80 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

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

82 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 %]] ) - 5 -

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

84 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

85 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

86 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

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

88 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 AUTO_SHRINK {ON OFF} READ_ONLY Descriptif Si cette option est activée les fichiers sont réduits dès qu ils disposent de plus de 25 % d espace libre. Permet de positionner la base de données en mode lecture seule

89 READ_WRITE SINGLE_USER RESTRICTED_USER MULTI_USER AUTO_CREATE_STATISTICS { ON OFF } AUTO_UPDATE_STATISTICS { ON OFF} La base de données est positionnée en mode lecture/ écriture. Seul un utilisateur peut travailler sur la base de données. Seuls les utilisateurs membres des rôles db_owner, db creator et sysadmin peuvent se connecter à la base de données. C est le mode de fonctionnement standard d une base, en autorisant plusieurs utilisateurs à travailler simultanément. Lorsque cette option est positionnée à ON les statistiques manquantes lors de l optimisation de la requête, sont calculées de façon automatique. Lorsque cette option est positionnée à ON, les statistiques obsolètes sont 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

90 ALTER DATABASE

91 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

92 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

93 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

94 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

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

96 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

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

98 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

99 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

100 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

101 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 - 1 -

102 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

103 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

104 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

105 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 : - 5 -

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

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

108 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

109 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 - 1 -

110 définition de l index. Ainsi, l organisation physique de la table suit la répartition des données entre les différents groupes de fichiers. 1. La fonction de partitionnement C est la fonction de partitionnement qui va permettre d orienter les données sur un groupe de fichiers ou bien un autre. Pour répartir les données entre les différentes partitions, la fonction utilise des plages de valeur. Chaque plage est bornée par des valeurs. Seules les valeurs frontières sont indiquées dans la fonction de partitionnement. Dans le cas où la valeur frontière doit être incluse dans la plage de valeur inférieure, il faut utiliser le mot clé LEFT. Le mot clé RIGHT permet d inclure la valeur frontière dans l espace suivant. SQL trie toujours les données de façon ascendante. Syntaxe CREATE PARTITION FUNCTION nomfonction ( parametre) AS RANGE [ LEFT RIGHT ] FOR VALUES ( [ valeurlimite [,... ] ] ) parametre Colonne de tous types sauf timestamp, varchar(max), nvarchar(max) et varbinary utilisé pour calculer la clé de partitionnement. valeurlimite Valeur marquant la frontière de chaque partition. Exemple Dans l exemple suivant, une fonction de partitionnement est définie sur une valeur de type entière. Cette fonction définie quatre partitions différentes : 1ère partition pour les valeurs inférieures ou égale à ème partition pour les valeurs strictement supérieures à et inférieures ou égale à ème partition pour les valeurs strictement supérieures à et inférieures ou égale à ème partition pour les valeurs strictement supérieures à

111 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

112 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

113 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 - 5 -

114 - 6 -

115 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

116 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

117 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

118 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

119 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 cidessous : 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

120 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

121 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

122 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

123 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

124 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

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

126 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

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

128 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 ; - 9 -

129 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

130 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

131 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

132 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

133 - 14 -

134 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

135 Enfin, il est possible de préciser les rôles de base de données accordés à cet utilisateur. Dans l exemple précédent, l utilisateur Adrien est créé dans la base de données GESCOM. Cet utilisateur est mappé à la connexion Adrien. Transact SQL C est par l intermédiaire de l instruction CREATE USER qu il est possible de définir des comptes utilisateurs au niveau de la base de données. Syntaxe CREATE USER nomutilisateur [ FOR {LOGIN nomconnexion CERTIFICATE nomcertificat ASYMMETRIC KEY nomcléasymétrique}] [ WITH DEFAULT_SCHEMA = nomschema ] nomutilisateur Nom du nouvel utilisateur de base de données. nomconnexion Nom de la connexion à laquelle l utilisateur de Base de données est associé. Si aucun nom de connexion n est précisé, alors SQL Server résout le problème de la façon suivante : 1 : SQL Server tente d associer le compte d utilisateur de base de données à une connexion qui porte le même nom

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

137 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

138 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

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

140 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

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

142 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

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

144 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

145 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

146 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

147 b. Transact SQL DROP SCHEMA nomschema Exemple - 6 -

148 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

149 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

150 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

151 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

152 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

153 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

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

155 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 : au niveau utilisateur, ce qui permet de connaître les possibilités de travail que possède chaque utilisateur

156 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

157 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

158 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

159 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

160 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

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

162 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

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

164 AUTHENTICATE BACKUP DATABASE BACKUP LOG CHECKPOINT CONNECT CONNECT REPLICATION CONTROL CREATE AGGREGATE CREATE ASSEMBLY CREATE ASYMMETRIC KEY CREATE CERTIFICATE CREATE CONTRACT CREATE VIEW CREATE XML SCHEMA COLLECTION DELETE EXECUTE INSERT REFERENCES SELECT SHOWPLAN SUBSCRIBE QUERY NOTIFICATIONS TAKE OWNERSHIP UPDATE 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 ALTER ANY CONNECTION ALTER ANY CREDENTIAL ALTER ANY DATABASE ALTER ANY ENDPOINT ALTER ANY EVENT NOTIFICATION ALTER ANY LINKED SERVER ALTER ANY LOGIN ALTER RESOURCES ALTER SERVER STATE ALTER SETTINGS ALTER TRACE CONNECT SQL CONTROL SERVER CREATE ANY DATABASE CREATE DDL EVENT NOTIFICATION CREATE ENDPOINT CREATE TRACE EVENT NOTIFICATION EXTERNAL ACCESS ASSEMBLY SHUTDOWN UNSAFE ASSEMBLY VIEW ANY DATABASE VIEW ANY DEFINITION VIEW SERVER STATE

165 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

166 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

167 - 20 -

168 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

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

170 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 - 1 -

171 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

172 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

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

174 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 - 5 -

175 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

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

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

178 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 : - 9 -

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

180 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

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

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

183 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}

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

185 - 16 -

186 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

187 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

188 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

189 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

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

191 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

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

193 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éesdatabas userrole 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

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

195 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 : livre@eni.fr) pour éviter les conflits si des opérateurs portent le même nom. Les principales caractéristiques d un opérateur sont : son nom, les informations le décrivant, les moyens dont SQL Server Agent dispose pour le prévenir. L opérateur suppléant Il est possible de définir un opérateur suppléant. Ce dernier recevra le message uniquement si l opérateur initial est injoignable. Cet opérateur est également nommé opérateur de prévention de défaillance. L opérateur de prévention de défaillance n est disponible que pour les alertes délivrées par radio messagerie

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

197 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

198 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

199 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

200 - 6 -

201 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

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

203 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

204 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

205 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

206 - 6 -

207 - 7 -

208 - 8 -

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

210 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 : - 1 -

211 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 Le transfert d événements peut être utilisé afin de centraliser le traitement des alertes pour un groupe de serveurs exécutant SQL Server 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

212 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

213 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

214 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

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

216 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 à 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

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

218 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

219 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

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

221 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 Oui source de données ODBC Oui Oui source de données OLEDB Oui Oui Oui Exportation de données texte Oui Oui source de données ODBC Oui Oui source de données OLEDB Oui Oui Oui Interface - 3 -

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

223 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. bcp {nom_complet_objet "requête"} {in out queryout format} 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 { }] [-q] [-C page_de_code] [-t fin_de_champ] [-r fin_de_ligne] [-i fichier_d entrée] [-o fichier_de_sortie] [-ataille_de_paquet] [-Snom_du_serveur] [-Uid_de_connexion] [-Pmot_de_passe] [-T] [-v] [-R] [-k] [-E] [-h "option [,...n]"] nom_complet_objet "requête" 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. {in out queryout format}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

224 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

225 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

226 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

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

228 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

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

230 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

231 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

232 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

233 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

234 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

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

236 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

237 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

238 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

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

240 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

241 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

242 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

243 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

244 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

245 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

246 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 - 3 -

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

248 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

249 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 - 1 -

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

251 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

252 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 : 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é - 4 -

253 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

254 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

255 - 7 -

256 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 UNIQUEIDENTIFIER BEGIN DIALOG 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 - 1 -

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

258 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 - 3 -

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

260 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

261 - 6 -

262 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 - 1 -

263 Supprimer un certificat Il n est possible de supprimer un certificat que s il n est pas utilisé. DROP CERTIFICATE nomcertificat; Exemple - 2 -

264 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

265 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

266 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

267 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

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

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

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

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

272 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

273 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

274 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

275 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

276 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

277 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

278 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

279 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 : - 1 -

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

281 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

282 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

283 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

284 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

285 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

286 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 : trois magasins dans la station A altitude 1800, deux magasins dans la station A altitude 1600, - 8 -

287 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

288 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

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

290 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

291 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

292 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 - 1 -

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

294 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

295 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

296 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

297 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

298 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

299 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

300 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

301 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

302 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

303 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?

304 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

305 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

306 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

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

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

309 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

310 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

311 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

312 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

313 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 - 1 -

314 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

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

316 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

317 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 - 5 -

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

319 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

320 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

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

322 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

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

324 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

325 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

326 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

327 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