Work placement bachelor's degree computer science_2009

C
har
te
Bachelor's IT
20 Rue de l’Arcade 75008 Paris
E-mail : contact@demos.fr
www.demos.fr
Administration et
Développement SQL
Au sein d’un
Environnement de Production
Ecole : CNAM
Auteur : Manuel RAMOS SALAS
Tuteur : François BRAMBATTI
Cadre : Licence Informatique d'entreprise
Date de stage : juillet 2008 à juin 2009

Administration et développement SQL au sein d’un environnement de Production
Direction des Systèmes d’Information
P
A
Présentation du groupe Demos 3
A propos du groupe 3
- Organisation de la DSI du groupe Demos 2
- Mes actions de supervision quotidienne dans le service Production 4
Maintenance SQL 5
- Pourquoi un plan de maintenance ? 5
- Quelles sont les 3 plans de maintenance SQL ? 5
- La politique de sauvegarde 6
- Le dossier de maintenance SQL 7
Surveillance et dépannage des performances du SGBD 9
- Les outils SQL SERVER 9
- Les compteurs 10
- Résolution des interblocages 11
- Contrôler l'évolution de la taille des journaux de transactions 12
- Réplications en erreur 13
Développement SQL 17
- Les applications Demos 18
- Préambule 20
- Généralités 20
- Nature et champ d’application 20
- Définitions 20
Dispositions générales 20
Précisions particulières 20
- Messagerie électronique 20
- Navigation sur le web – Utilisation d’Internet 20
- Stockage des fichiers 20
- Intranet 20
- Téléphonie 21
- Vidéosurveillance 21
- Emplacement du matériel et matériel nomade 21
- Place du comité d’entreprise dans le Système d’Information 21
Surveillance et audits 22
Conclusion 29

P
A
Présentation du groupe Demos
A PROPOS DU GROUPE
Un acteur de référence au cœur de l’économie du savoir opérationnel
Le groupe Demos, crée en 1972, est un des leaders en France de la formation professionnelle continue, en
B2B. S’appuyant sur son cœur de métier, Demos a développé des modes de formation innovants et
complémentaires comme le E-Learning.
Le métier principal qu’est la formation représente 94% du chiffre d’affaire en 2007 sous 3 modes :
o La formation interentreprises, représentant 48% du chiffre d’affaire en 2007 : Ce sont des stages
de 1 à 5 jours dans les locaux de Demos, proposés sur catalogue et rassemblant les salariés de
différentes sociétés. Une fore récurrence de l’activité est constatée en France car chaque année,
66% des clients actifs sont d’anciens clients.
o La formation intra-entreprise, représentant 28% du chiffre d’affaire en 2007 : Ce sont les
formations sur mesure, déployées parfois sur plusieurs pays, conçue pour des entreprises, des
organisations ou des grands projets internationaux.
o E-Learning, représentant 8% du chiffre d’affaire en 2007 : Ce sont les formations à distance à la
fois comme outil de suivi individuel de la prestation évaluation/validation et aussi outil de formation
multimédia.
A ces 3 modes existants, nous pouvons ajouter le conseil en gestion des compétences et la diffusion des
savoirs du groupe Demos, considérés comme 2 actions synergiques qui sont génératrices de valeur
ajoutée :
o Le conseil : Il consiste à aider les dirigeants des grands groupes à gérer leurs ressources humaines
et le recrutement de leurs collaborateurs dans un environnement complexe et évolutif.
o La diffusion : Dernier élément de l’activité de Demos.
Exemple : En 1999, l’accès à la première base de données dans le domaine bancaire est qualifié
en permanence par une équipe de 10 personnes et suivi par 50000 utilisateurs. Aussi, une centaine
d’ouvrages professionnels sont publiés par les Editions Demos depuis 1993.
Un modèle d’activité réussi et réplicable à l’international
Implanté dans 13 pays et dans les principales villes en France. Demos a su mener une politique efficace de
croissance externe qui lui permet aujourd’hui d’accompagner ses clients à l’international et de développer
une clientèle locale. Sur un marché porteur, la diversité de son offre, sa haute exigence de qualité certifiée
ISO 9001en 2003 par l’AFAQ, une recherche continue d’innovation et un business model souple et
performant ont fait de ce groupe le deuxième acteur français de la formation.
Une croissance régulière et rentable
Au premier semestre 2007, le groupe Demos a réalisé un chiffre d’affaires de 36,1 millions d’euros, pour un
résultat d’exploitation de 1,8 millions d’euros et un résultat net part du groupe de 0 ,35 millions d’euros.
Le marketing explique cette croissance et une notoriété forte avec le catalogue des stages, des livres
thématiques, des emails, des fax mailing (6000000 de messages par an).
ORGANISATION DE LA DSI DU GROUPE DEMOS
La Direction des Systèmes d’Information (DSI) du groupe Demos est organisée de la façon suivante :
 En France : Au sein de 3 cellules spécialisées
 Etudes & développement :
Développement de logiciels métiers, intégration de progiciels. La cellule est organisée en
mode projet (la taille de l’équipe et l’affectation des développeurs aux projets peut varier
dans le temps) et dotée d’une fonction d’assistance à maîtrise d’ouvrage (rédaction de
spécifications, formation,….)
 Support utilisateurs : Assistance de niveau 1 (Hotline, Helpdesk) avec une organisation
s’approchant de la Norme ITIL puis l’installation de matériel et logiciel.
 Production : Se charge de la gestion proactive des serveurs et du réseau informatique et
téléphonique, de l’Exploitation, de la Supervision et de la Sécurité du système d’information.
Par ailleurs, la cellule ‘Connaissance partagée est également rattachée à la DSI.

P
A

P
A
MES ACTIONS DE SUPERVISION QUOTIDIENNE DANS LE SERVICE PRODUCTION
Cette feuille de travail AMS (Analyse systémique) permet de mieux comprendre l’ensemble du service
Production, son fonctionnement. Pour l’entreprise, elle permet de connaître les finalités du service en
question. Pour le responsable Production, elle permet de détecter les failles du service afin de lui apporter
des améliorations.
Module technologique
.R.Réécupcupéérer la taille de tousrer la taille de tous
les logs sur tous les serveursles logs sur tous les serveurs
SQL et les intSQL et les intéégrergrer
au fichier Excel de suivi.au fichier Excel de suivi.
.Surveiller la taille de tous.Surveiller la taille de tous
les disques sur tous lesles disques sur tous les
serveurs.serveurs.
.Se connecter sur les.Se connecter sur les
Serveurs et consulterServeurs et consulter
LL’’historique des jobs.historique des jobs.
Directives
. 90% de. 90% de
DisponibilitDisponibilitééss
des donndes donnééeses..
. Anticiper. Anticiper
avant lavant l’’arrivarrivééee
du probldu problèème.me.
Mission
Assurer leAssurer le
fonctionfonction
nementnement
dudu
SystSystèèmeme
dd’’informinform
ationation..
Informations
Projet
Évolution
Des besoins
Clients.
Pilotage
..VVéérifier larifier la
tailletaille
des journauxdes journaux
.Taille libre.Taille libre
Restant surRestant sur
les disques.les disques.
.Ex.Exéécution descution des
Jobs (travaux).Jobs (travaux).
Informations
CommunicationCommunication
sur la santsur la santéé
du projet.du projet.
Réglages
du pilote
.Recrutement.Recrutement
en cours.en cours.
.Achat de.Achat de
matmatéériel.riel.
.Formation.Formation
personnel.personnel.
Informations
Compte renduCompte rendu
de rde réésolutionsolution
DD’’anomaliesanomalies
Informations
RRééceptionception
dd’’anomaliesanomalies
éémisesmises
Par lesPar les
Utilisateurs.Utilisateurs.
La mission explique la raison d’être du service Production.
Les directives sont les objectifs à atteindre ainsi que les règles et contraintes pour l’ensemble (Module
technologique + Pilotage). Elles évoluent dans le temps.
Le pilotage correspond à l’activité de décision, de planification et d’organisation du responsable Production.
Les activités de réalisation de son équipe constituent le module technologique c'est-à-dire le journal de bord.
Les entrées du module technologique sont celles qui ont subit de la transformation (logiciels, plans,…).
Les sorties du module technologique correspondent aux flux transformés des entrées c'est-à-dire la
réalisation de la transformation.

P
A
Maintenance SQL
Le plan de maintenance permet de créer un flux de travail des tâches nécessaires à l’optimisation de votre
BD, à la création d’une sauvegarde régulière et à la recherche des incohérences c’est-à-dire qu’il est
composé de plusieurs tâches. La création d’un job dans le plan de maintenance génère automatiquement le
job dans le service de SQL Server Agent.
POURQUOI UN PLAN DE MAINTENANCE ?
Les données stockées chez Demos sont diverses (texte, données chiffrées, comptabilité, facturation,
production mais aussi e-mails, pages web, bases de données). Leur volume ne cesse d’augmenter. Ces
données sont vitales et leur perte peut entraîner de graves problèmes. C’est pour cette raison que le
système de sauvegarde est aujourd’hui un outil incontournable pour toute entreprise. Pouvoir effectuer des
sauvegardes de serveurs, récupérer rapidement et ponctuellement ses données, gérer ces sauvegardes de
manière centralisée devient une fonction fondamentale dans les sociétés.
QUELLES SONT LES 3 PLANS DE MAINTENANCE SQL ?
o La sauvegarde quotidienne comporte 5 étapes :
 Vérifier l’intégrité des bases (incluant les index) c'est-à-dire l’ensemble des
règles que les données de la base de données doivent respecter (pour cela,
toujours se référer à la spécification technique). Exemple : Les clés primaires et
étrangères puis les valeurs légales.
 Sauvegarder les bases.
 Réorganiser les index : Nécessaire lorsque le taux de fragmentation est trop
important. La fragmentation d’une table est visualisable via la commande ‘DBCC
SHOWCONTIG’. Dans une grande base de données, ils sont essentiels car ils
diminuent le temps nécessaire à la recherche des enregistrements. Par contre,
dans la petite base de données il finit par pénaliser la performance.
 Mettre à jour les statistiques soit sur les colonnes, soit sur les index, permet
d’optimiser le temps de réponse des requêtes. Pour cela utiliser la procédure
stockée ‘SP_UPDATESTATS’.
 Optimiser les bases.
o La sauvegarde des journaux comporte 3 étapes :
 Sauvegarder les journaux de transactions dont l’extension est LDF.
 Optimiser les bases.
 Nettoyer les anciennes sauvegardes de journaux.
o La sauvegarde du dimanche comporte 6 étapes :
 Réorganiser les index.
 Sauvegarder les bases.
 Vérifier l’intégrité des bases (inclut les index) : Le script ‘ DBCC CHECKDB
nom_base de données’ permet de vérifier les contraintes d’intégrités de la
base.
 Reconstruire les index : Ils occupent de l’espace disque, doivent être mis à
jour chaque fois que les données correspondantes dans la base de données
sont mises à jour.
 Mettre à jour les statistiques
 Optimiser les index : Il est fortement recommandé de défragmenter les index
dont le taux de fragmentation dépasse 20%.Il est conseillé de défragmenter de
manière hebdomadaire si possible sachant que l’opération peut prendre un
temps important.

P
A
LA POLITIQUE DE SAUVEGARDE
Elle dépend de la volumétrie des bases. Pour mettre au point une bonne politique, il faut passer une phase
de tests pour connaître les durées de sauvegarde/restauration de quelques bases et déterminer ainsi la
meilleure fréquence. Il existe principalement 3 types :
 La sauvegarde complète : L’ensemble des fichiers, répertoires, systèmes de
fichiers ou disques sélectionnés est sauvegardé sans restriction. Ce type reste
bien adapté aux petites bases.
 La sauvegarde incrémentielle : Tous les fichiers modifiés depuis la dernière
sauvegarde complète sont sauvegardés.
 La sauvegarde différentielle : Elle sauvegarde tous les fichiers nouveaux et
modifiés depuis la première sauvegarde. Pour restaurer tous les dossiers que
vous avez l’habitude de sauvegarder, vous devez utiliser la première
sauvegarde complète et la dernière sauvegarde différentielle. Ce type est plus
rapide et moins volumineux que la sauvegarde complète.
Le niveau de rapidité de la restauration des données va dépendre du type de sauvegarde effectuée.
La politique suivante est rencontrée chez Demos :
Une sauvegarde totale dans la nuit du vendredi au samedi.
Une sauvegarde incrémentielle les autres nuits
Une sauvegarde système une fois par mois.
La bande du vendredi est conservée 1 mois comme sauvegarde hebdomadaire. La bande du dernier
vendredi du mois est conservée 1 an comme sauvegarde mensuelle.
La bande du dernier vendredi de l’année est conservée sans limitation dans la durée comme sauvegarde
annuelle.
On aura ainsi besoin de 5 bandes hebdomadaires + 11 bandes supplémentaires pour chaque mois soit 16
bandes. Il faudra fixer un lieu de stockage pour ces bandes, les conserver dans un endroit à l’abri du feu et
des inondations. L’idéal étant de les conserver dans un coffre ignifugé ainsi qu’une copie de ces bandes sur
un site distant (ce qui porte à 32 le nombre de bandes).
Une fois la politique de sauvegarde choisie, le choix de l’outil dépendra de l’affinité avec tel ou tel éditeur.
Tous les logiciels de sauvegarde (Acronis, Veritas Backup Exec 10.0) ont à peu près les mêmes
caractéristiques et possibilités.

P
A
LE DOSSIER DE MAINTENANCE SQL
1) Objet du document
Il présente l’activité des serveurs de bases de données SQL SERVER du groupe Demos. Il recense en
particulier les traitements qui s’y connectent, ainsi que les opérations de maintenance existantes ou les
nouvelles à mettre en place.
De ce fait, je vais recenser tous les scripts des serveurs concernés afin de mettre en place la maintenance
de ceux-ci. Il est destiné aux personnes en charge de l’exploitation de ces serveurs, permettant une prise de
connaissance rapide de l’environnement.
Enfin, ce document doit être tenu à jour, au fil des modifications qui seront apportées sur ces serveurs.
2) Analyse de L’infrastructure existante sur SQL SERVER
a) Matériel : Le serveur hébergeant la base de données possède les
caractéristiques matérielles suivantes. La taille fichier de pagination initiale
en Mo est égale à 1,5 X RAM de taille fixe.
b) Système : (Nom OS | langue OS | version SGBDR + Service Pack).
c) Configuration Windows (Paramètre vitesse carte réseau | optimisation et
priorités serveur).
d) Configuration des disques.
e) Configuration de SQL SERVER
3) Contexte d’utilisation
Le serveur de Base de données SQLSERVER est utilisé en journée par tous les services (marketing,
communication, Etude, DAF…), à travers les différentes applications ACCESS.
Dans le même temps, des batchs tournent de manière régulière (entre 30 mn et 90 mn d’intervalle) pour
mettre à jour les informations des différents catalogues, des inscriptions stagiaires, des formateurs… La
nuit, des traitements plus importants sont lancés sur ce serveur.
Il est cependant assez aisé de définir une plage d’intervention sur ces serveurs, la nuit ou le week-end.
4) Présentation des bases de données sur SQL SERVER
Catalogue : reflète le catalogue imprimé classé par domaine, rubrique et sous rubrique. Tables relatives à
l’élaboration du catalogue chaque année.
DEMOS : Contient tous les acteurs du métier de la formation. C’est vraiment le cœur de DEMOS.
Disque physique Disque logique Taille Utilisation
Disque0 (2 x 34 Go
RAID 1)
C: Système (Admin, Scripts SQL, Batch).
L:BaseSQL Logs
J:Sauvegardes Sauvegardes (BAK, TRN)
Disque 1 (3 x 36 Go,
RAID 5)
K:BaseSQL Données (MDF)

P
A
Prn_Ga_Demos : contient toutes les données comptables, fournisseurs et devis.
Intra : Recense les formations spécifiques (particulier) à un client avec un coût plus élevé que la base Inter
qui concerne tout type de public et il peut y avoir plusieurs clients.
Qualité : Regroupe toutes les données du service qualité : Le logiciel QUBES (sur le serveur SFRAPP2)
écrit dans les tables de cette base. Elles contiennent des informations du formulaire d’évaluation de fin de
stage dont le but est d’améliorer la qualité client.
5) Les traitements
a) Jobs SQL : Le tableau ci-dessous liste les traitements actifs sur le serveur
SQL SERVER susceptibles d’être optimisés.
Nom du job Description Fréquence Jour Intervalle
d’exécution
Heure
Exemple : Sauvegarde quotidienne, des journaux et du dimanche, contrôle des agents de réplication, alerte
mail sur la taille des fichiers de logs, nettoyage de l'historique de l'Agent de distribution, nettoyage de
l’abonnement expiré, sauvegarde des bases Master et Msdb, optimisation des index de la base Msdb,
défragmentation des bases DEMOS, QUALITE, CHARGEMENT, GC et Prn_Ga_Demos.
Il m’a également été demandé de faire aussi un tableau avec la répartition des planifications quotidiennes en
grisant la partie horaire correspondante.
6) Maintenance / Configuration des bases
a) Le mode de recouvrement :
Appliquer le mode SIMPLE a FULL selon les types de transactions dans les bases.
SQL SERVER héberge l’application ‘Traitement Demos’ qui se compose des bases Catalogue, Chargement,
Qualité et Demos.
Avec Le mode SIMPLE, la base de données est exposée à des pertes de travaux potentielles en cas de
sinistre après chaque sauvegarde. Le risque de perte de travail augmente après chaque Mise à jour, et ce,
jusqu’à la prochaine sauvegarde complète, après laquelle le risque redevient nul et un nouveau cycle de
risque de perte de travail commence. Avec ce mode, il est donc pas possible de sauvegarder les journaux
car le SGBD tronque le journal régulièrement.
Avec le mode FULL, on peut recréer une base de données dans son intégralité en la restaurant à n’importe
quel emplacement, en une seule étape, à partir d’une sauvegarde FULL de base de données.
La sauvegarde contient une partie suffisante du journal des transactions pour vous permettre de récupérer la
base de données à l'issue de l'opération de sauvegarde. Une fois la base de données récupérée, les
transactions non validées sont restaurées (rollback). La base de données restaurée retrouve l'état qui était le
sien à l'issue de l'opération de restauration, sans les transactions non validées.
b) Les sauvegardes :
C’est un récapitulatif des sauvegardes des bases de données sur :
c) La sauvegarde des bases systèmes :
Il s’agit des bases Master & Msdb, la première contient toutes les informations nécessaires au bon
déroulement du moteur SQL ainsi que tous les utilisateurs crées et il est donc impératif de la sauvegarder
régulièrement.
La base Msdb contient tous les jobs et lots SQL SERVER, c’est la base d’informations de SQL SERVER
AGENT pour faire les travaux sans problème.

P
A
Surveillance et dépannage des performances du SGBD
Tout d’abord, il faut rassembler le maximum de faits pour apporter des améliorations de performance. Le
DBA possède plusieurs outils d’analyse à sa disposition qui lui donneront les éléments indispensables à la
compréhension du problème et à sa résolution.
LES OUTILS SQL SERVER
 Le générateur de profils (Profiler) :
Cet outil capture les traces de l’activité de la base de données pour résoudre des problèmes de
performance. Il ne capture que des évènements SQL Server et non des conditions propres à L’OS ou au
réseau qui sont également susceptibles d’affecter les performances de la base de données.
Il propose plusieurs modèles de traces déjà définis ne spécifiant pas de filtres, possible de personnaliser soi-
même pour focaliser la surveillance sur une base de données particulière par exemple, de l’enregistrer dans
un fichier ou dans une table pour le réutiliser ultérieurement.
Evitons d’enregistrer les données de trace dans une table car cela peut entraîner une sévère baisse des
performances du SGBD et saturer le traitement des transactions de SQL Server.
N’oubliez pas de préciser le mode de stockage de la trace, sa taille maximale et une éventuelle heure
d’arrêt. Il est préférable de tracer l’activité de la base à un moment de forte utilisation, lorsqu’elle travaille
vraiment sur un serveur de production afin d’être le plus proche possible du réel.
La trace doit être totalement définie avant de commencer la capture. Pour pouvoir réaliser un audit, il faut
être membre du rôle sysadmin.
 Le moniteur système :
C’est l’utilitaire de supervision intégré à Windows qui correspond au processus ‘Perfmon’ permettant de
suivre en temps réel tous les compteurs indiquant le comportement du serveur. Il est donc possible dans la
même interface suivre ceux de Windows et de SQL Server. Les journaux de compteurs se trouvent dans le
dossier C:perflogs. Il permet également de programmer des alertes comme l’agent SQL Server envoyant
une notification lorsqu’un compteur atteint un certain seuil.
Une fois que vous disposez des 2 fichiers enregistrés, le journal de compteurs et le fichier de trace, il est
possible d’importer les données de performance c'est-à-dire du journal de compteurs dans le Profiler, ce que
l’on appelle une corrélation des 2 fichiers.
 SQL Server Performance Dashboard Reports :
C’est l’équivalent des rapports basés sur des vues de gestion dynamique (DMV) sous forme graphique.
Regroupe une collection de rapports Reporting Services qui proviennent du Datawarehouse. Pour cela, il
suffit de faire un clic droit sur l’objet (la base de données), choisir « Reports » et sélectionner le rapport
désiré.
 L’assistant paramétrage du moteur de base de données (DTA) :
C’est le remplaçant de l’Assistant optimisation d’index (ITW) présent dans la version SQL Server 2000. Il
joue un rôle important dans l’optimisation de requêtes SQL, cet outil graphique se base sur une charge de
travail de la base de données qui correspond au fichier de trace capturé par le Profiler, pour fournir
automatiquement des recommandations destinées à améliorer les performances :
 Une meilleure combinaison d’index (ajout et suppression) en fonction de l’analyse
effectuée car ils perdent de leur efficacité au fil du temps s’ils ne sont pas
correctement entretenus.
 Analyser les effets des modifications suggérées
 Envisager une solution d’optimisation de la base de données pour un petit ensemble
de requêtes.

P
A
L’analyse d’une charge de travail par le DTA se divise en trois étapes : Le lancement du DTA, la sélection du
fichier de charge à analyser et la configuration des options de paramétrage en indiquant la liste des index
conservés.
Pour réaliser une analyse sans conséquence sur le serveur de production, le DTA permet de déplacer la
charge de travail sur un serveur de test.
 Les vues de gestion dynamique (DMV) :
L’emploi des DMV permet aux administrateurs de gérer efficacement leurs bases de données SQL Server.
En tirant profit des informations détaillées, les DBA peuvent très rapidement diagnostiquer les problèmes et
prendre les actions nécessaires avant l’apparition de tout problème. Ce processus est un gain de temps car
cela ne nécessite pas la génération de trace avec le Profiler puis d’analyser la sortie de la trace pour
déterminer les améliorations. Les DMV se classent en 4 catégories :
- Statistiques de base de données, de requête, d’entrée-sortie puis les matérielles.
Les statistiques de base de données concernent les informations d’utilisation des index d’une base. Sachant
qu’un index inutilisé est donc pénalisant pour les performances que pour l’espace de stockage, la DMV
sys. Dm_db_index_usage_stats identifie tout index non employé par l’optimiseur de requête ainsi que la
date de sa dernière utilisation. Il est également possible de rechercher les index manquants sur une base à
l’aide de la DMV sys.dm_db_missing_index_details pour optimiser une requête SQL.
Si le ratio entre le nombre de lignes répondant au critère recherché et le nombre total de ligne est faible
alors SQL Server décide de choisir l’utilisation de l’index sinon il va plutôt parcourir la table jusqu’à la fin.
Les statistiques de requête donnent des informations sur les requêtes et les procédures stockées les plus
consommatrices (temps, CPU) dans le moteur de la base. Par exemple, La DMV sys.dm_exec_query_stats
permet de déterminer le nombre de lectures et écritures, les ressources consommées et le temps
d’exécution de la requête.
Les statistiques d’I/O permettent de résoudre les problèmes de lecture/écriture disque.
Les statistiques matérielles donnent le même résultat qu’avec le moniteur système, l’ensemble des
compteurs liés à une instance SQL, mais avec des données plus facile à manipuler. Citons la DMV
employée est sys.dm_os_performance_counters qui renvoie tous les compteurs de performance SQL
Server dans une table de résultats.
J’espère que vous voyez l’importance des DMV qui vous offre toutes les informations nécessaires pour
anticiper les problèmes.
LES COMPTEURS
Il existe des compteurs fournis par le système et des autres propres à SQL Server. Ici, nous allons plutôt
nous intéresser à ceux liés à SQL.
A. Les compteurs SQL
1) MSQL : Buffer Manager/Buffer cache hit ratio
Indique le pourcentage de pages lues par le moteur, depuis le cache de données (buffer), sans
accéder au disque. Moins SQL Server accédera au disque, plus il sera rapide. Un bon chiffre doit
être au dessus de 99,7% sinon il se peut que vous observiez une file d’attente sur le disque, pensez
y donc à rajouter de la mémoire vive à votre système.
2) MSQL : Databases/Transactions/sec
Indique le nombre de transactions par seconde, permet de connaître l’activité moyenne du serveur
pendant la journée et détecter ainsi les augmentations de charge. Une valeur élevée indique que le
serveur fonctionne très bien c'est-à-dire que le nombre de transactions a augmenté avec une
diminution de la charge des processeurs.
3) MSQL : Access Methods/Full scans/sec
Indique le nombre de scans de stable (index clustered) par seconde, utile pour détecter un manque
d’index ou des requêtes mal écrites. Il est très pénalisant sur les petites tables avec des colonnes
très grandes.
4) MSQL : Buffer Manager/Databases pages
Indique le nombre de pages de données caches dans le buffer, permet de savoir s’il faut libérer des
pages du buffer si la valeur évolue rapidement.

P
A
5) MSQL : Buffer Manager/Page life expectancy
Indique le nombre de secondes pendant lesquelles une page de données va rester dans le buffer
c’est à dire sans qu’un processus n’accède à cette page. Moins il y’a de mémoire, plus la durée de
vie est courte pour libérer de la place dans le buffer pour des données plus utiles.
6) MSQL : Databases/Percent Log Used
Indique le pourcentage du journal en utilisation. Il est aussi possible d’automatiser cette tâche
d’administration en créant une alerte de l’agent SQL Server qui vous notifie par mail lorsque cette
valeur dépasse les 80% ou plus.
RESOLUTION DES INTERBLOCAGES
Si toutes les bases de données étaient en lecture seule, il n’y aurait pas de problèmes de concurrence
d’accès mais c’est rarement le cas. Pour gérer donc le travail à plusieurs sur une base, tout en maintenant la
cohérence de celle-ci, SQL Server va donc protéger l’accès aux données avec des verrous.
Lorsque le processus qui a crée un blocage (le bloquant) libère le verrou, le processus bloqué peut
reprendre son exécution. Toutefois, il existe des blocages qui ne seront jamais résolue, on les nomme
« Interblocage ».
Voici les différentes façons de résoudre ce problème :
La colonne ‘blocking_session_id’ des vues de gestion dynamique (DMV) sys.dm_os_waiting_tasks
et sys.dm_exec_requests indique le processus SPID qui bloque la requête en cours.
Vous pouvez également consulter les interblocages à partir du moniteur d’activité de la console
graphique SQL Server, se référer seulement aux colonnes ‘Blocked by’ qui correspond au processus
du bloquant,’Database’,’User’ et ‘Blocking’ qui me donne le nombre de transactions ouvertes.
Premièrement, vérifier que la colonne « Blocked by » est à 0 pour toutes les lignes sinon rechercher
la ligne de l’id du processus bloquant, faire un click droit «kill Process».C’est plutôt le mode manuel.
Aussi, le générateur de profils fournit des informations détaillées sur ce problème en sélectionnant
l’évènement LocksDeadlock Graph identifiant la cause exacte du Deadlock sous forme graphique
avec les processus impliqués.
Afin d’être averti des blocages survenant sur le serveur principal de Demos : SQL Server, j’ai mis en place
un script qui consiste à créer une procédure stockée « sp_VerificationInfosBlocage » dans la base DEMOS,
permettant de détecter les processus bloqués de plus de 2 minutes (120 secondes), loguer les informations
(heure, utilisateur, application…) dans une table nommée « Processus Bloque », envoyer un email au
bloquant pour le prévenir que sa session va être tuée. Ensuite, je l’ai placé dans un job dans SQL Agent qui
exécute la commande EXEC sp_VerificationInfosBlocage toutes les 2 minutes dans la base de données
DEMOS.
Avec ces paramètres par défaut dans la procédure stockée « sp_VerificationInfosBlocage » et un schedule
toutes les 2 minutes, le temps maximum d’un processus sera donc de 4 minutes.
A savoir : Ce script a été testé sur un serveur de test avant mise en production.
Une machine virtuelle a été préparée par le service Exploitation, correspondant à un PC, doté d’1 mémoire
vive minimale de 2 Go et d’un espace disque de taille minimale de 100Go. Cet environnement a permis de
procéder à certains tests dont l’exécution de la procédure stockée ci-dessus :
1. Tests de montée en charge sur la plateforme de test pour les procédures les plus
coûteuses.
2. Analyser des procédures stockées (plan d’exécution, code SQL)
3. Analyse des index
4. Optimisations sur le code SQL et index
5. La gestion des interblocages
6. Tests de montée en charge et évaluation du gain de performance
7. Mise en production des optimisations.
CONTROLER L’EVOLUTION DE LA TAILLE DES JOURNAUX DE TRANSACTIONS
Le journal de transactions respecte une des propriétés ACID (Atomicité, Cohérence, Isolation et Durabilité)
c'est-à-dire la cohérence des opérations de modification (lecture+écriture) des données. Chaque transaction
(suite de lecture et d’écriture) se compose d’un bloc délimitée par ‘BEGIN TRANSACTION’ et ‘END
TRANSACTION’, est donc enregistrée dans ce journal avant même d’être inscrite dans les fichiers de
données.

P
A
Le fait d’ajouter et supprimer plusieurs lignes dans une table, et cela plusieurs fois, fera que la taille du
journal des transactions augmentera anormalement. J’ai donc mis en place une action programmée de
dépannage et de suivi spécifique de ce problème en créant une alerte (voir la capture ci-dessous) qui
consiste à automatiser le travail de réduction du journal de transaction pour chaque base du serveur si la
valeur ‘percent log used’ atteint les 80% sur le serveur. Pour voir le pourcentage d’utilisation du journal de
transaction pour chaque base, il suffit d’exécuter la commande ‘DBCC SQLPERF(LOGSPACE)’ sur SQL
Server dont le résultat sert à alimenter les colonnes du fichier excel « Surveillance de la taille des fichiers
journaux » (Voir Annexes).
Le travail se compose des étapes suivantes pour aboutir à la diminution du fichier journal qui augmentent en
permanence :
Sauvegarde de la base complète en mode FULL : Conseillé avant chaque opération
sensible sur la base.
Voir si des transactions sont encore ouvertes à l’aide de ‘DBCC OPENTRAN (base)’
c'est-à-dire des transactions non répliquées sur les serveurs éditeur/distributeur.
Sauvegarde du journal de transaction évitant le risque de saturer le disque suite au
grossissement du fichier journal.
BACKUP LOG [nom_de_la_base] WITH TRUNCATE ONLY
Forcer la diminution de la taille du journal de la base de données :
DBCC SHRINKFILE (nom logique du fichier log, 10)
La commande ‘ EXEC sp_helpfile’ donne le nom logique du fichier log indispensable
pour exécuter l’instruction ci-dessus.
Vous pouvez être alerté avec un message, envoyé dans la boîte DSI Production à propos de l’échec du job
et dans le journal d’événements (eventvwr.msc).
Les colonnes ‘log_reuse_wait’ et ‘log_reuse_wait_desc’ de la vue sys.databases détermine les raisons pour
lesquelles l’espace du journal des transactions n’est pas réutilisé et le journal ne peut pas être tronqué.
Enfin, nous pouvons affirmer que les vues de gestion dynamique favorisent la résolution de la majeure partie
des problèmes de performance.

P
A
Développement SQL
Afin de mettre en place une nouvelle fonctionnalité pour les reprographes, j’ai eu besoin de créer une base
de données SQL Server 2005 dont l’utilité est de stocker les historiques des demandes de reprographie afin
d’assurer une planification et facturation interne des reprographes.
Lors de la création d’une base de données, SQL SERVER génère 2 fichiers, soit un fichier de données avec
l’extension .mdf et un fichier journal (log) avec l’extension .ldf. Le premier étant relativement petit mais le
second peut représenter plusieurs gigaoctets qu’on appelle le journal de transaction. Ce sont des fichiers en
croissance forte qui peuvent parfaitement dépasser de beaucoup la taille des données. L’emplacement par
défaut est le suivant sur le disque dur : D:Microsoft SQL ServerMSSQL.1MSSQLData.
On s’appuie sur la base Model qui contient les tables systèmes.
Le chef de projet a donc défini un certain nombre d’éléments :
Le nom de la base de données et l’espace alloué (taille) pour les datas
Le taux d’accroissement (Filegrowth) des 2 fichiers cités ci dessus. Par défaut, le
taux est de 10% pour les journaux et de 1 Mo pour les fichiers de données. En
utilisant des fichiers à croissance dynamique, le serveur ne sera jamais bloqué par
la taille sauf si le disque atteint sa taille maximale.
Le serveur souhaité
Le propriétaire doit être dbo.
La sécurité : Accès pour le compte x, rôles « datareader » et « datawriter »
Les permissions au niveau du serveur et de la base (sysadmin, dbcreator,
datareader, datawriter,…..).
Au départ, il est conseillé de fixer la taille du journal entre 10% et 25% de la taille des données dans la base
puis baisser ce pourcentage si la base supporte que des requêtes SELECT qui n’utilisent pas le journal.
Aussi, veuillez utiliser des groupes de fichiers c'est-à-dire séparer les tables systèmes, les tables utilisateurs
et les index pour réduire les conflits d’accès disque.
Après ce travail, il faut l’ajouter au plan de maintenance (les 3 plans cités dans la première partie
‘Maintenance SQL’) ainsi que renseigner le fichier ‘Liste des bases et applications’ qui liste les bases de
données.

P
A
ANNEXES
Surveillance de la taille des fichiers journaux

P
A
Etat des plans de sauvegarde

P
A
Architecture des serveurs SQL
sfrdb1 sfrdb4
sfrdb2 sfrdb3
sfrdbc2
sfrweb
12
sqlserver
sfrtfs1
Titre
SERVEURS SQL DE PRODUCTION
Affinium V7
DataWarehouse
Intranet Intervenants
Experts
Snapshot DWH
SFRMKTG1
Altisys
Cartesis
Sage Ligne 1000
Star Form
SSIS
Sage – Magnitude
Réplications
Sharepoint
Revue d’études
Oasys
Editions DEMOS
Intranet
Sharepoint
Base de
contenu filiale
Etranger
Team
Foundation
Server
(Codes sources
Projets)
sfrweb
11
MindOnSite (formation
elearning)
Snapshot MOSS
MindOnSite (formation
elearning)
sfrdbc1
Transactionnelles
Les répertoires communs sur chaque serveur figurant ci-dessus sont les suivants:
o C:ADMIN : Contient les traitements manuels (Batchs et exécutables schedulés) et les fichiers
des admins intervenant sur le serveur (Documentation internes, batchs lancés en interactif, les
fichiers techniques, les logs, les traces et les captures d’écrans).
o C:ADMINOLD : Contient les anciennes versions.
o C:BATCHS : Contient les traitements automatisés.
o L:BaseSQL : Contient les fichiers journaux (logs) dont l’extension est LDF.
o D ou K:BaseSQL : Contient les fichiers de données dont l’extension est MDF et NDF.
o E:Sauvegardes : Contient les 3 plans de maintenance SQL (quotidienne, journaux et dimanche).

P
A
Remerciements
Je tenais à remercier Julien WEYRECH, Mickael DOS SANTOS et Thomas BOUQUET
DECHAUX avec lesquels j’ai travaillé et qui m’ont permis énormément sur le plan organisationnel
et au niveau de l’aspect fonctionnel de mon travail.
Je remercie également François BRAMBATTI, mon tuteur, Responsable Infrastructure chez
Demos, qui m’a pris sous son aile dés mon arrivée et qui m’a aidé tout au long de mon stage en
m’orientant dans la rédaction de ce rapport d’activité et qui m’a permis d’avoir un regarde critique
et constructif sur mon travail pendant le stage.
Merci à Alain BUHLER, développeur sénior pour son apport technique et humain, me permettant
d’appréhender le concept de réplication sous un angle nouveau.
Je remercie également Jean-Christophe DESIRE, directeur DSI pour son encadrement, son
professionnalisme et son soutien.
D’une manière générale, je tiens à remercier tous les membres des équipes Production,
Support et Développement. Leur convivialité, leur bonne humeur et leur niveau de compétence
m’ont permis de travailler dans un cadre agréable qui m’a permis d’exploiter mon potentiel
théorique afin d’acquérir au mieux mes compétences.
Fait à Paris, le 30 Juin 2009
Manuel RAMOS SALAS
Stagiaire DBA junior

Work placement bachelor's degree computer science_2009

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (7)

Semelhante a Work placement bachelor's degree computer science_2009

Semelhante a Work placement bachelor's degree computer science_2009 (20)

Mais de MRamo2s

Mais de MRamo2s (11)

Work placement bachelor's degree computer science_2009