3 Octobre 2013 
Les Communautés MS
Management d’infrastructures IT hétérogènes 
www.osmozium.com 
 Support Management 
 Technical Management 
 Data Manage...
Points clés du monitoring SQL Server 
1. Définir le besoin de monitoring 
2. La disponibilité de SQL Server 
3. La volumét...
Pourquoi faire 
 Criticité des données d’entreprise 
 Réactivité par rapport aux incidents 
 Parfois même proactivité 
...
Définir le besoin de monitoring 
 Trop ou trop peu ? 
 Capacité de filtrage 
 Automatiser la collecte 
 Historiser les...
Disponibilité de SQL Server 
 Garantir l’accès aux données dans les meilleures 
conditions de performance. 
 Tester la p...
Présence des processus 
 Permet de détecter l’indisponibilité le plus tôt possible 
Connexion OK / KO 
+ SELECT @@SERVERN...
Remontée d’erreur 
 ERRORLOG, journaux d’évènement 
 Ring buffers, trace par défaut, system_health (Xevents) 
 Alertes ...
Volumétrie bases et file systems 
 Capacity planning 
 Proactivité grâce aux seuils 
 Profil transactionnel 
 Alertes ...
Tâches de maintenance 
 Backup, rebuild index, dbcc checkdb, autre… 
 Contrôler la sortie des jobs: DB mail, 
xp_sqlagen...
Performances 1/4 
• Historiser les compteurs clés. 
• Alertes SQL Agent, Xevents, Data Collector. 
COMPTEUR SEUIL 
Buffer ...
Performances 2/4 
• Surveiller les attentes 
• Là où l’instance perd son temps 
• La base de l’analyse de perf 
• Data Col...
Performances 3/4 
 Surveiller la concurrence (verrous) 
 Activity Monitor ! 
 sys.dm_os_waiting_tasks, sys.dm_tran_lock...
Performances 4/4 
 Tracer les requêtes consommatrices 
 Souvent à l’origine de nombreux problèmes sur 
l’instance (mémoi...
La sécurité 
 Identifier les risques: 
(mots de passe, connexions SSL, etc. 
Authentification ..) 
Permissions système ...
L’environnement immédiat 
• Système d’exploitation, host: mémoire, 
programmes concurrents, antivirus, ressources 
matérie...
(Et) Les outils (dans tout ça) 
 Intégrés à SQL Server: SQL agent, SQLDIAG, vues 
dynamiques, SQL Trace , Xevents, Data C...
Des questions ?
Merci à Nos Sponsors
Merci à nos partenaires et 
membres
Pour adhérer à l’association : 
http://www.rebuild.f/adhesions 
Ou 
contact@communautes.ms 
Nous suivre sur Facebook : 
ht...
Prochain SlideShare
Chargement dans…5
×

Re build Nantes 2013 SQL Server monitoring

371 vues

Publié le

Présentation au ReBUILD Nantes 2013 : points clés du monitoring sur SQL Server

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
371
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
3
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Permet de détecter l’indisponibilité le plus tôt possible
    sqlservr, sqlagent, sqlwriter, fdhost, logread, distrib, etc...
    Tester la présence du processus seul ne suffit pas. Il faut aussi tester si la connexion peut être établie.
    Mesurer la qualité de la réponse avec une requête fonctionnelle significative.
    Utiliser un outil indépendant (pas de job sql agent...).
    Plus l’empreinte sur le système est faible, plus la fréquence d’exécution peut être élevée pour permettre de réduire le délai de réaction.
  • Sources multiples : ERRORLOG, journal Application, ring buffers, trace par défaut, session XE system_health...
    Utiliser les alertes SQL Agent et DB Mail:
    Severity 17 (oom conditions, erreurs 1105 / 9002), et severity de 20 à 25.
    Inclure l’erreur 825 (read-retry) en utilisant le n° d’erreur.
    Attention aux parsers ‘maison’ pour l’ERRORLOG (unicode)
    xp_readerrorlog (Attention bug CPU 100% http://support.microsoft.com/kb/973524)
    Utilisation de Log Parser pour les *.evt (http://www.microsoft.com/en-us/download/details.aspx?id=24659)
    Attention aux erreurs non formalisées:
    a significant part of sql server memory has been paged out...
    SQL Server has encountered xxx occurrence(s) of IO requests taking longer than 15 seconds...
  • Connaître l’état de remplissage des enveloppes données / journaux et des filesystems...

    Permet de faire du capacity planning.
    Permet de voir ce que l’on récupère suite à une purge / un rebuild index.
    Permet d’établir un profil d’utilisation, notamment au niveau du journal de transactions.
    Avec des seuils correctement paramétrés, permet d’être très proactif.
    Problème: seuils en % et volumétries très élevées.
    Autre problème: solution intégrée dans l’agent SQL pour les journaux de transactions (Percent Log Used) mais pas pour les fichiers de données.
    Data Collector / xp_fixeddrives / SQLCLR
  • Connaître l’état des tâches de maintenance: backup, rebuild index, statistiques, dbcc checkdb...

    Contrôler la sortie des jobs: DB mail, xp_sqlagent_enum_jobs, sysjobhistory...
    Contrôler aussi si la tâche n’a pas du tout été exécutée.
    Donc il faut en plus une logique de test indépendante de l’exécution.
    Avec un plan de plus de 100 jobs à contrôler, le mail atteint ses limites en termes de lisibilité et d’exploitation (SCOM ?)

  • Etre averti d’un problème de performance en constitution avant qu’il ne soit trop tard.

    Là aussi permet une certaine proactivité.
    Alertes SQL Agent, Xevents
    Page Life Expectancy (max server memory / 4Gb) / * 300. Ex: BP = 30Gb, PLE = 2250 secs)
    Percent Log Used ( >= 90%)
    Processed Blocked ( > 5)
    Number of Deadlocks / sec ( > 0)
    Free Space in Tempdb (<=10%)
  • Savoir où l’instance passe le plus de temps à attendre (donc à ne rien faire d’utile)

    Le point de départ d’une recherche d’un problème global de performance.
    sys.dm_os_wait_stats, session XE system_health.
    Nécessite que l’instance ait une disponibilité élevée (flush des infos non persistées en cas de restart: DMV, ring buffers, etc...)
    Heureusement system_health persiste ces informations dans un fichier ( >= SQL Server 2012)
  • Détecter les attentes sur verrous:

    Souvent facile à diagnostiquer.
    sys.dm_os_waiting_tasks, sys.dm_tran_locks.
    Utiliser le Blocked Process Report avec Service Broker ou SQL Trace.
    Utiliser le Blocked Process Report avec Xevents.
    Utiliser une alerte SQL Agent avec le compteur Perfmon Blocked Processes (mais pas de durée de seuil).
  • Avoir une visibilité sur les requêtes qui pénalisent le plus l’instance en termes d’entrées / sorties, temps CPU.

    Souvent à l’origine de nombreux problèmes sur l’instance (mémoire, CPU, entrées / sorties, attentes, etc...)
    Data Collector, SQL Trace, Xevents.
    DMV / DMF, sys.dm_exec_%
    Données brutes à agréger et classer par Reads / CPU time / Elapsed / nb executions.
  • Qui peut se connecter, qui fait quoi.

    Server Audits.
    Utiliser les rôles prédéfinis, ou le CREATE SERVER ROLE à partir de SQL Server 2012.
    Identifier les risques:
    Authentification (mots de passe, connexions SSL, etc...)
    Permissions système et permissions sur les objets.
    Encryption des données (certs, TDE)
    Vol de données / vol de sauvegardes.
    Comptes de service.
    ...
    -> !! SQL Injection !!
  • Problème externe ou corolaire à SQL Server (stockage, host, hyperviseur, réseau...)
    Mesurer l’activité depuis un point de vue SQL Server seul ne suffit pas, il faut élargir les observations à l’environnement immédiat.
    Système d’exploitation, host: mémoire, programmes concurrents, antivirus, ressources matérielles insuffisantes, etc...
    Stockage: cache baie sous dimensionné en écriture, mauvais choix de RAID, nombre de disques insuffisants dans le groupe, IO queue depth par défaut, etc...
    Hyperviseur: problème de paramétrage, cpu ready, entrées / sorties, sur-mutualisation, etc...
  • Connaître l’état des tâches de maintenance: backup, rebuild index, statistiques, dbcc checkdb...

    Contrôler la sortie des jobs: DB mail, xp_sqlagent_enum_jobs, sysjobhistory...
    Contrôler aussi si la tâche n’a pas du tout été exécutée.
    Donc il faut en plus une logique de test indépendante de l’exécution.
    Avec un plan de plus de 100 jobs à contrôler, le mail atteint ses limites en termes de lisibilité et d’exploitation (SCOM ?)

  • Re build Nantes 2013 SQL Server monitoring

    1. 1. 3 Octobre 2013 Les Communautés MS
    2. 2. Management d’infrastructures IT hétérogènes www.osmozium.com  Support Management  Technical Management  Data Management David Baffaleuf http://blog.capdata.fr dbaffaleuf@capdata.fr @dbaffaleuf AllDB © DBA à distance  Production Management infogérance www.capdata.fr  Conseil  Service  Formation
    3. 3. Points clés du monitoring SQL Server 1. Définir le besoin de monitoring 2. La disponibilité de SQL Server 3. La volumétrie des bases et file systems 4. Les tâches de maintenance 5. La performance 6. La sécurité 7. L’environnement immédiat 8. Et les outils dans tout ça ?
    4. 4. Pourquoi faire  Criticité des données d’entreprise  Réactivité par rapport aux incidents  Parfois même proactivité  Connaître ses instances:  Charge  Profil d’utilisation  = BASELINE !!  Prendre des décisions avec la connaissance de l’environnement.
    5. 5. Définir le besoin de monitoring  Trop ou trop peu ?  Capacité de filtrage  Automatiser la collecte  Historiser les données  Définir la rétention  Faire des stats incidentogènes  Postmortem / analyse à postériori
    6. 6. Disponibilité de SQL Server  Garantir l’accès aux données dans les meilleures conditions de performance.  Tester la présence des processus associés à SQL Server  Scruter les sources d’information sur les erreurs rencontrées.
    7. 7. Présence des processus  Permet de détecter l’indisponibilité le plus tôt possible Connexion OK / KO + SELECT @@SERVERNAME ou requête fonctionnelle ?  Outil indépendant  Empreinte faible
    8. 8. Remontée d’erreur  ERRORLOG, journaux d’évènement  Ring buffers, trace par défaut, system_health (Xevents)  Alertes SQL Agent  Severity 17 (pb mémoire) et de 20 à 25.  Inclure l’erreur 825  xp_readerrorlog / logparser.  Attention aux erreurs non formalisées: • a significant part of sql server memory has been paged out... • SQL Server has encountered xxx occurrence(s) of IO requests taking longer than 15 seconds…
    9. 9. Volumétrie bases et file systems  Capacity planning  Proactivité grâce aux seuils  Profil transactionnel  Alertes SQL Agent, xp_fixeddrives, SQLCLR…  Data Collector
    10. 10. Tâches de maintenance  Backup, rebuild index, dbcc checkdb, autre…  Contrôler la sortie des jobs: DB mail, xp_sqlagent_enum_jobs, sysjobhistory...  Mais aussi lorsque la tâche n’a pas été exécutée ? => une logique de test indépendante de l’exécution  +100 jobs, le mail n’est plus adapté =>
    11. 11. Performances 1/4 • Historiser les compteurs clés. • Alertes SQL Agent, Xevents, Data Collector. COMPTEUR SEUIL Buffer cache: Page Life Expectancy > (max server memory / 4Gb) * 300 Ex: BP = 30Gb, PLE = 2250 secs Percent Log Used (base) < 60% Process Blocked < 5 Free space in Tempdb > 40% Processor % < 90% Average Disk sec/read, sec/write < 10ms PageFile % Usage < 10%
    12. 12. Performances 2/4 • Surveiller les attentes • Là où l’instance perd son temps • La base de l’analyse de perf • Data Collector • System_health (Xevents) RUNNABLE RUNNING SUSPENDED
    13. 13. Performances 3/4  Surveiller la concurrence (verrous)  Activity Monitor !  sys.dm_os_waiting_tasks, sys.dm_tran_locks.  Utiliser le Blocked Process Report avec SQL Trace ou Xevents.  Débrayer le mode d’isolation en utilisant Read Committed Snapshot.
    14. 14. Performances 4/4  Tracer les requêtes consommatrices  Souvent à l’origine de nombreux problèmes sur l’instance (mémoire, CPU, entrées / sorties, attentes, etc...)  Data Collector, SQL Trace, Xevents.  Vues dynamiques de gestion: sys.dm_exec_query_stats sys.dm_exec_sql_text() sys.dm_exec_query_plan()  Outils tiers (Plan explorer)
    15. 15. La sécurité  Identifier les risques: (mots de passe, connexions SSL, etc. Authentification ..) Permissions système et permissions sur les objets. Encryption des données (certs, TDE) Vol de données / vol de sauvegardes. Comptes de service. -> !! SQL Injection !!
    16. 16. L’environnement immédiat • Système d’exploitation, host: mémoire, programmes concurrents, antivirus, ressources matérielles insuffisantes, etc... • Stockage: cache baie sous dimensionné en écriture, mauvais choix de RAID, nombre de disques insuffisants dans le groupe, IO queue depth par défaut, etc... • Hyperviseur: problème de paramétrage, cpu ready, entrées / sorties, sur-mutualisation, etc...
    17. 17. (Et) Les outils (dans tout ça)  Intégrés à SQL Server: SQL agent, SQLDIAG, vues dynamiques, SQL Trace , Xevents, Data Collector …  Fournis par MSFT (gratuits): logparser, SCOM, Perfmon, ETW, Powershell, SQL-DMO, SQL Nexus, RML utilities, etc…  Fournis par des éditeurs tiers (Gratuits/payants): SQL Sentry, Quest, Red Gate, etc…  Fournis par la communauté: CODEPLEX http://www.codeplex.com/
    18. 18. Des questions ?
    19. 19. Merci à Nos Sponsors
    20. 20. Merci à nos partenaires et membres
    21. 21. Pour adhérer à l’association : http://www.rebuild.f/adhesions Ou contact@communautes.ms Nous suivre sur Facebook : https://www.facebook.com/lescommunautesms Nous suivre sur Twitter : https://twitter.com/CommunautesMS

    ×