SQL Server : Tuning et Troubleshooting

Bases de données/Data management

Troubleshooting & Tuning SQLYanick Mezui

Senior PFEMicrosoft France

Frédéric PichautSenior Escalation Egineer

Microsoft France

#mstechdays Bases de données/ Data management

Depuis votre smartphone sur :http://notes.mstechdays.fr

De nombreux lots à gagner toute les heures !!!Claviers, souris et jeux Microsoft…

Merci de nous aider à améliorer les Techdays !

Donnez votre avis !

http://notes.mstechdays.fr/

Bases de données/ Data management

#mstechdays

METHODOLOGIE

Sous titre


• L’analyse de performance est un perpétuel recommencement

• Quand on pense en avoir fini, un changement survient

Méthodologie

Capture

Analyse

Reglages

Charge du

système


Comment aborder une requête longue


#mstechdays

OUTILS DE COLLECTE


• Dynamic Management Views (DMVs)– sys.dm_os_wait_stats– sys.dm_os_waiting_tasks

• Performance Monitor (perfmon)– Mémoire– Disques– Processeurs

• SQL Trace / SQL Server Profiler– Collecte des events SQL Server– La collecte peut s’effectuer côté client– La collecte peut s’effectuer côté serveur– La Trace Profiler rajoute un overhead sur le serveur

• Extended Events (Xevent ou XE)– Repose sur l’infrastructure de tracing Windows ETW– Flexibilité du schema des events– Collecte performante et non intrusive (overhead très

limité sur le serveur 5% CPU pour 20000 events/sec)• Automatisation de la collecte

– SQLDiag– PerfStatsScripts– PSSDiag

Les outils de collecteServer Level Component Level

dm_exec_* Execution of user code and associated connections

dm_os_* Memory, locking & scheduling

dm_tran_* Transactions & isolation

dm_io_* I/O on network and disks

dm_db_* Databases and database objects

dm_repl_* Replication

dm_broker_* SQL Service Broker

dm_fts_* Full Text Search

dm_qn_* Query Notifications

dm_clr_* Common Language Runtime


#mstechdays

OUTILS D’ANALYSE


• Performance Analysis of Logs (PAL)– Automatise l’analyse des compteurs de performance

Windows– Utilise un fichier avec des seuils de compteurs de

performance– Il existe des fichiers de seuils pour les grands produits

Serveurs Microsoft (ex: SQL Server, Exchange, SharePoint, etc.)

• RML Utilities– Automatise l’analyse de la Trace SQL– ReadTrace– Reporter

• SQLNexus– Automatise l’analyse des Waits, des blocages, de la trace

SQL– Utilise RML utilities pour l’analyse de la trace SQL– Fournit des rapports:

• Bottleneck Analysis• Blocking & Wait Statistics• Top Queries (Duration, CPU, Reads, Writes)

• Extended Events Viewer– En utilisant le query_hash, et les capacités d’aggrégation et

de tri du XE Viewer on peut arriver aux mêmes rapports Top Queries (Duration, CPU, Reads, Writes) que SQLNexus

Les outils d’analyse


• Formations chez Microsoft ou dans vos locaux – SQL Server 2008 Performance Tuning & Optimization– SQL Server 2012 Performance Tuning, Design, Internals &

Architecture– SQL Server Hands On Troubleshooting

• Transfert d’expertise et Analyse de Performance sur vos environnements– SQL server Performance Tuning & Optimization Clinics

SQL Premier Field Engineering & Performance

démo


COLLECTE & ANALYSE DE PERFORMANCE AVEC PERFSTATS SCRIPTS, PAL & SQLNEXUS


#mstechdays

LES STATISTIQUES


• L’optimiseur se sert des statistiques pour déterminer la cardinalité (#ligne) d’un résultat

• Une page de statistique par indexe, on peut en créer sur des colonnes

• Elles peuvent être – Crée/MaJ automatiquement ou manuellement, De façon synchrone ou asynchrone– Basée sur un échantillonnage ou un full scan– Filtrée : CREATE STATISTICS FSPoids ON Products(Weight) WHERE CatID IN (1,2,3);

• Elles sont mises à jour en fonction du taux de modification de la table

• Pas de statistiques sur les variables tables mais il peut y en avoir sur les tables temporaires

• Depuis SQL Server 2008 R2 SP2 et SQL Server 2012 Service Pack 1, DMV sys.dm_db_stats_Properties

LES STATISTIQUES


• Elles sont mise a jour en fonction du taux de modification de la table– Avant SQL 2008 R2 SP1

• Cardinality <= 500, update every 500 modifications.• Cardinality > 500, update every 500 + 20% Card modification

– Apres SQL 2008 R2 SP1 and SQL 2012 avec le TF 2371 (conseil, asynchronous stats)• Cardinality <= 500, update every 500 modifications.• Cardinality > 500, update every modifications• Min (new method, old method), environ 25 000 lignes• Pas actif par default

– Pour les statistiques filtrées• le colmodctr réglé en fonction de la sélectivité du filtre. Exemple: Si le prédicat

donne 50% des lignes, le colmodctr est multiplié par 0.5.• SQL regarde les modifications sur les colonnes de la statistique mais pas sur les

colonnes dans le prédicat.– TF 2389, TF 2390, Colonne détectée ascendante (“brand”) après 3 update statistics

• TF 2388, pour voir la notion des “banding” colonne dans le DBCC SHOW_STATISTICS

AUTO-UPDATE STATISTICS


• Objectif:– Mise à jour plus rapide/fréquente sur des tables avec de larges partitions– Des mises à jour automatiques plus fréquentes

• Uniquement sur les tables partitionnées• Une page de statistique par partition• Merge binaire des statistiques de chaque partition pour créer

une statistique globale• L’ensemble des pages sont persistante sur disque.• La mise à jour peut être globale ou indépendante par

partitions– (500 + 20% de la taille moyenne des partitions) pour la mise à jour de la stat

globale– 20% de modification dans une partition -> Auto Stat

Statistiques Incrémentales / Fast Statistics


Exemples• Sur une table avec 4 partitions

• Ajout d’une 5eme partition


#mstechdays

NEW CARDINALITY ESTIMATION


• Composent de plus en plus critique• L’optimisation des requêtes doit déterminer

le chemin le plus efficace avec des workloads très différents (OLTP, DW et DS)

• Avoir une performance prédictible• Tous va dépendre des estimations de

cardinalité (« Cardinality Estimation » ou CE)

Les bases du Query Optimization


• De Database Systems Lab, Indian Institute of Science

• Un outils de visualisation graphique• Visualiser et analyser le comportement des

optimiseurs• Operationel pour plusieurs moteurs

– Microsoft SQL Server– IBM DB2– Oracle– Sybase– PostgreSQL

Picasso Database Optimizer Visualizer


Estimation du coût pour requêtes à 2 variables

SQL Server 2008 R2 Prototype with new CE

Le cout ne doit pas diminuer alors que le nombre d’enregistrements retourné augmente


• Ils sont la cause des mauvais choix de plans

• On peut les détecter de plusieurs façons– SET STATICS PROFILE ON

• Rows, Executes VS EstimateRows, EstimateExecutions

– Actual Execution Plan– Xevents inaccurate_cardinality_estimate

Problèmes de cardinalités


Hypothèse d’uniformité:– Dans chaque palier d’histogramme les valeurs

distinctes sont équidistantes et ont la même fréquence.

Hypothèse de confinement:– Les requêtes concernent des données qui existent.

Hypothèse d’indépendance:– Les données de différentes colonnes sont

distribuées de façons indépendantes

Le Nouveau Model Mathématique


Prédicat column-equal-constant Select * from T where T.c1 = 50La valeur 50 existe dans l’histogramme (confinement)– La fréquence de 50 est la fréquence moyenne du palier dans l’histogramme

(uniformité)

Prédicat de type Range (interval)Select * from T where T.c1 > 35 and T.c1 < 50– Interpolation linéaire pour estimer le #lignes et #valeurs distinctes dans l’intervale

(35, 50) (uniformité)

Estimer le sélectivité d’un equijoin (indépendance)Select * from T1 join T2 on T1.c1 = T2.c2

=

On calcule la cardinalité de la jointure en combinant les histogrammes de T1.c1 et T2.c2:

Exemples


• Qu’est ce que le problème de clé ascendante?– Les données sont ascendantes– Les nouvelles donnés ne sont pas dans l’histogramme

• Comment le nouveau CE le solutionne?– Toujours supposer que les valeurs demandées existent– Estimer la cardinalité en utilisant la fréquence moyenne– Les mêmes suppositions sont prisent pour les « missing

values » dans des statistiques échantillonnées

Problème de clé ascendante


• Testé sur les benchmarks et workloads client• Choix des variations qui ont démontrées, en moyenne,

les meilleures performances• Essai de différentes variations du model

– Exponential back-off: Sélectivités des prédicats : .• Independence: • Exponential back-off:

• Deux versions du CE (Eviter les régressions)– TF 9481: Force l’ancien CE

– TF 2312: Force le nouveau CE (par default, database comp level 120)

• Xevent: Query_optimizer_estimate_cardinality

Qu’est-ce qui a été fait?


Division de Cardinality Estimation en deux étapes• Étapes 1: Planning

Trouver un « cardinality calculator » pour les paramètres

• Étapes 2: ExécutionExécution des « calculator »

Bénéfices– Meilleur supportabilité – Maintenance et extension plus facile à intégrer

Architecture

démo


Statistiques IncrémentalesNew ce


Sessions Data Insights pour les professionnels de l’IThttp://aka.ms/itprosql

Sessions Data Insights pour les décideurs informatiqueshttp://aka.ms/itdmsql

Business Accelerator, un programme sur mesure pour les éditeurs de logicielhttp://aka.ms/isvbusacc

Un client prêt à témoigner ? Une belle histoire à partager ? Un Nokia Lumia à gagner !http://aka.ms/cloudosref

Ressources

http://aka.ms/itprosql

http://aka.ms/itdmsql

http://aka.ms/isvbusacc



http://aka.ms/cloudosref



© 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Digital is business

Technology

SQL Server : Tuning et Troubleshooting