ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 149
Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 4
Abonament PDF

Microsoft SQL Server Optimizarea performanței

Cosmin Cristea
CLD Head of Development
@Endava



PROGRAMARE

De câte ori v-ați pus problema de a îmbunătăți performanța interogărilor voastre pe SQL Server fără să știți de unde să vă apucați? Eu, cel puțin, mi-am suflecat mânecile de câteva ori până am ajuns să înțeleg o funcționalitate specifică SQL Server care îmi rezolvă problema.

Toți știm că în faza de dezvoltare problemele de performanță majore sunt rare, și asta se întâmplă din mai multe motive: date puține, mediul de dezvoltare perfect, scenarii principale de lucru fără variații, etc.

Soluția e bazată pe statisticile făcute de SQL Server. Cu ele puteți să vă dați seama de stresul aplicat serverului, însă necesită un ciclu de rulare a aplicației pe scenarii utilizator și nu cele de dezvoltare. Se pretează la aplicații care rulează într-un mediu de producție sau cât mai aproape de cel real.

Dacă vă întrebați ce înseamnă statisticile, răspunsul dat de wikipedia e: "Statistics is the study of the collection, organization, analysis, and interpretation of data". Mdah, nici mie nu mi-a plăcut statistica în facultate.

Specific însă pe o bază de date, de la creare se setează o opțiune care întreține statisticile de pe fiecare tabelă. Statisticile sunt folosite pentru a optimiza interogările pe SQL Server și a crea planurile de execuție. SQL Server creează câte o statistică pentru fiecare tabelă și stochează informații despre cum s-a folosit tabela respectivă, proces care se realizează automat prin opțiunile "auto create" și "auto update" pe baza de date.

Cum se folosesc? Se pornește de la un view de sistem, și anume

sys.dm_db_missing_index_group_stats

în care se adună statistici legate de, așa cum îi spune și titlul, indecși lipsă în baza de date. Informația se modifică la fiecare execuție de query, și se șterge când serverul e repornit. Deci atenție la ce date interpretați, fiind informații doar de la ultimul restart. Apoi e nevoie de încă două view-uri pentru a scoate informații relevante:

sys.dm_db_missing_index_details și sys.dm_db_missing_index_groups.

O interogare care oferă un set de date pertinent arată astfel:

select top 100

priority = s.user_seeks * s.avg_total_user_cost * s.avg_user_impact,

s.user_seeks,

s.avg_total_user_cost,

s.avg_user_impact,

d.statement,

d.equality_columns,

d.inequality_columns,

d.included_columns

from

sys.dm_db_missing_index_group_stats s

join sys.dm_db_missing_index_groups g on s.group_handle = g.index_group_handle

join sys.dm_db_missing_index_details d on g.index_handle = d.index_handle

order by priority desc

Un rezultat din viața reală se poate vedea în Figura 1.

img4_1.jpg

Figura 1. tabele si coloane anonimizate

După cum observați coloana "priority" e calculată având ca scop calcularea impactului total asupra performanței. Dar cel mai bine ar fi să le analizăm pe rând:

  • Rezultatul 1, sugerează planuri de execuție care iau in considerare coloana StatusID din tabela 1, care participă in condiții de filtrare cu egalitate pe coloană. Având în vedere că sunt ~30k căutari cu condiția respectivă cu un impact mare asupra utilizatorului (78.4%), merită studiată adăugarea indexului pe coloana respectivă.
  • Rezultatul 3, sugerează index pe aceeași coloană, precizând execuții care folosesc coloana pentru căutari pe diferențe (>,<, !=). Încă un motiv în plus să luăm în considerare un index pe StatusID.
  • Ultimul rezultat are unele caracteristici interesante. Impactul asupra utilizatorului e 98%. Dacă ar fi să ne uităm mai în detaliu sugestia afirmă că indexul ar trebui aplicat pe 3 coloane, din care una este probabil cheie primară. Sugestia ar fi de fapt un index compus, însă nu săriți în decizie până nu faceți o analiză atentă pe interogarile care cauzează înregistrarea.

Și de-aici incepe munca propriu-zisă. Trebuie analizată fiecare înregistrare în parte. După primele câteva zeci încep să se contureze cele pentru care e nevoie de atenție mărită și cele care nu intră in aria de interes imediat. E nevoie și de cineva care să cunoască bine regulile de business ale aplicației pentru a putea aplica regula 80/20.

Atenție foarte mare la câți indecși folosiți pentru o tabelă, având in vedere dezavantajele indecșilor multipli. Statisticile nu sunt destinate unui astfel de proces, însă pot fi folosite ca și informații de intrare. Mai jos prezentăm câteva dezavantaje ale funcționalității oferite:

  • Destinația principală nu este pentru optimizări.
  • Nu poate aduna statistici pentru mai mult de 500 grupuri de indecși lipsă.
  • Nu spune care să fie ordinea de indexare.
  • Pentru condiții de filtrare inegale rezultatele nu sunt precise.
  • Coloanele sugerate pentru incluziune nu sunt returnate consistent. Analize ulterioare sunt necesare.

 

Concluzie

Folosirea unor astfel de informații în optimizarea indecșilor și a interogărilor e utilă. Însă nu vă apucați să puneți indecși pe tot ce mișcă, acesta nefiind scopul statisticilor. Munca nu vi se simplifică, pentru că tot e nevoie de o analiză ulterioară. Rămâne la decizia voastră să hotarâți dacă folosiți sau nu informația. De exemplu: un index pe o coloană unde variația datelor e mica nu-și are rostul. Dar știți unde sunt coarnele taurului. Suflecări de mâneci plăcute!

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects