Organizarea optimă a stocării datelor pe serverul SQL, ferestrele it pro

Fără îndoială, depozitarea datelor este una dintre componentele principale care determină performanța și disponibilitatea instanțelor mari și mici ale serverului SQL. În fața creșterii puterii de calcul a serverelor și serverelor virtuale și a suportului pentru memoria volumetrică, stocarea datelor și subsistemul I / O pot fi blocaje care reduc viteza globală







ARUBA INSTANT WI-FI: SIMPLĂ, PUTERNICĂ, DISPONIBILĂ

Asigurați disponibilitatea și performanța depozitelor de date

Fără îndoială, depozitarea datelor este una dintre componentele principale care determină performanța și disponibilitatea instanțelor mari și mici ale serverului SQL. În fața creșterii puterii de calcul a serverelor și a serverelor virtuale și a suportului pentru memoria volumetrică, stocarea datelor și subsistemul I / O pot fi blocaje care reduc viteza globală. Puteți evita problemele dacă aveți o idee generală despre modul în care SQL Server folosește depozitele de date și cunoaște tehnicile de bază pentru optimizarea organizării stocării SQL Server.

Fișiere de date și jurnal

Principiul de bază care sta la baza muncii serverului SQL cu depozitele de date este că bazele de date constau în două tipuri de fișiere:

  • Fișiere de date. Aceste fișiere stochează informații despre baza de date. Fișierele de date SQL Server sunt fișiere NTFS cu extensia. MDF. Cea mai simplă bază de date constă, de obicei, dintr-un fișier de date, dar poate consta din mai multe fișiere de date de pe unul sau mai multe discuri.
  • Fișierele jurnal. Aceste fișiere stochează tranzacțiile bazei de date, ceea ce vă permite să restaurați baza de date la un moment dat. Fișierele jurnal de tranzacție SQL Server sunt fișiere NTFS cu extensia. LDF. O bază de date poate avea mai multe fișiere log pe unul sau mai multe discuri.

Este recomandat să introduceți fișiere de date și jurnal pe discuri diferite. SQL Server scrie toate tranzacțiile bazei de date în jurnalul de tranzacții, astfel încât fișierele jurnal sunt localizate convenabil pe discuri de mare viteză. Fișierele de date sunt utilizate pentru a satisface cererile și de multe ori trebuie să efectueze multe operații de citire. Atunci când creați o bază de date, puteți specifica locația fișierelor de date și jurnal folosind comanda TREBLE CREATE DATABASE T-SQL. Pentru a modifica locația fișierelor de date și a jurnalelor existente, puteți executa comanda ALTER DATABASE cu parametrul MODIFY FILE. Listarea 1 arată un exemplu de mutare a unui fișier de date baze de date într-o altă locație.

Nu toată lumea este de acord cu recomandarea de a activa modul AutoGrow pentru bazele de date SQL Server. Dacă activați această funcție pentru baza de date, fișierele de date și jurnal sunt incrementate automat dacă este necesar un spațiu mai mare. Acest parametru nu permite sistemului să se oprească dacă nu există suficient spațiu.

Și totuși, AutoGrow ar trebui văzută ca mecanismul ultimei linii de apărare. Acesta nu ar trebui să fie utilizat ca principală metodă pentru gestionarea creșterii unei baze de date. Creșterea tuturor fișierelor de date și a jurnalelor ar trebui să fie gestionată manual. Activitatea bazei de date se încheie atunci când apar operațiuni AutoGrow. Evenimentele frecvente din AutoGrow sunt un bun indicator al creșterii datelor neprevăzute. Următoarea comandă arată modul de setare a setării AutoGrow pentru fișierele de date și jurnal:

Este aproape niciodată recomandabil să activați funcția AutoShrink pentru baza de date. Ca și operațiile AutoGrow, operațiile AutoShrink opresc toate acțiunile bazei de date. În plus, administratorul nu poate controla timpul de începere al AutoShrink. Utilizarea AutoShrink poate duce la o spirală a operațiilor AutoGrow, urmată de AutoShrink, iar rezultatul va fi o scădere a performanței bazei de date și fragmentarea excesivă a fișierelor. Puteți începe AutoShrink folosind comanda:

O altă tehnică utilă pentru lucrul cu magazinele de date este inițializarea imediată a fișierelor Instant File Initiation. Spre deosebire de majoritatea opțiunilor discutate în acest articol, Inițializarea fișierului Instant este controlată de politica Windows Server. Inițializarea inițială a fișierului nu resetează spațiul alocat fișierului, ci doar alocă spațiul dorit. SQL Server folosește Inițializarea fișierului Instant în timpul creării bazei de date, a operațiilor de recuperare și de recuperare a bazei de date. Puteți activa modul Inițializare fișiere instantanee pe server prin meniul Administrare pentru a deschide politica locală de securitate. Extindeți apoi politicile locale și faceți dublu clic pe sarcinile de întreținere a volumului de performanță, după cum se arată pe ecran.

Organizarea optimă a stocării datelor pe serverul SQL, ferestrele it pro

Ecranul. Activarea inițializării fișierului instant

Aceasta deschide caseta de dialog Proprietăți pentru întreținerea volumului de performanță, în care puteți introduce numele contului SQL Server Service.

Stocarea datelor și nivelurile RAID

După ce ați stăpânit depozitele SQL Server, puteți începe să explorați următorul concept critic - nivelurile RAID pe care le puteți utiliza pentru discurile din subsistemul de stocare. Nivelurile RAID afectează foarte mult performanța și disponibilitatea. După cum s-ar putea aștepta, opțiunile mai scumpe au tendința de a oferi performanțe și disponibilități mai bune. Cele mai comune niveluri RAID sunt următoarele:

  • RAID 0 (uneori denumite discuri alternative). La acest nivel RAID, datele sunt distribuite între toate discurile disponibile. Este adesea folosit în diverse teste de performanță a bazelor de date. RAID 0 oferă performanțe bune, dar nu ar trebui să fie folosit niciodată pe un server de producție, deoarece eșecul unei unități duce la pierderea datelor.
  • RAID 1 (denumit uneori oglindire a discurilor). În configurația RAID 1, datele sunt reflectate pe discuri. Viteza operațiilor de citire și scriere este bună, însă capacitatea totală a discurilor este redusă la jumătate. RAID 1 este adesea folosit pentru fișierele jurnal SQL Server. În cazul unei defecțiuni a unui singur disc, datele nu se pierd.
  • RAID 5 (uneori numite discuri alternative cu control al parității). Într-o configurație RAID 5, datele sunt distribuite pe mai multe discuri pentru a furniza redundanță de date. Deseori folosit pentru fișiere de date. Acest nivel RAID oferă o performanță bună de citire și este rezistent la o singură defecțiune a discului. Cu toate acestea, viteza de înregistrare este scăzută.
  • RAID 10 (uneori denumite discuri cu oglindire cu stripe). RAID 10 combină viteza opțiunilor alternative și protecția prin oglindire. RAID 10 oferă cele mai înalte niveluri de performanță și disponibilitate între toate nivelurile RAID. RAID 10 necesită două ori mai multe discuri ca RAID 5, dar configurația este rezistentă la defecțiuni multiple de discuri. Matricea RAID 10 continuă să funcționeze cu succes dacă jumătate din discurile din set nu reușesc. RAID 10 este potrivit atât pentru fișiere de date, cât și pentru jurnal.






O altă componentă importantă a sistemului de stocare a datelor SQL Server este tempdb. Aceasta este o bază de date a sistemului SQL Server, care este o resursă globală accesibilă tuturor utilizatorilor. Tempdb este folosit pentru obiectele temporare ale utilizatorilor și pentru operațiile interne ale nucleului sistemului de gestionare a bazelor de date, incluzând conexiunile, procesarea statistică, cursorii, sortarea, hashing-ul și versiunea stringurilor. Spre deosebire de datele dintr-o bază de date tipică pentru utilizatori, datele din tempdb nu sunt păstrate după ce instanța serverului SQL este dezactivată.

În mod tipic, tempdb este una dintre cele mai active baze de date dintr-o instanță de lucru a serverului SQL, astfel încât următoarele recomandări vor contribui la asigurarea unei performanțe bune a bazei de date SQL Server. În primul rând, datele tempdb și fișierele de jurnal ar trebui să fie plasate pe alte discuri fizice decât fișierele jurnal și datele bazei de date de lucru. Datorită utilizării foarte active a tempdb este util să protejăm discurile organizând o matrice RAID 1 sau o serie de RAID 10 cu interlace. Experții echipei de consultanță pentru clienți Microsoft SQL Server (SQLCAT) recomandă ca tempdb să aibă un fișier de date pentru fiecare nucleu de procesor. Dar această recomandare este eficientă pentru încărcări foarte mari. Este adesea recomandat ca raportul fișierelor de date la nucleul procesorului să fie 1: 2 sau 1: 4. În majoritatea cazurilor, acestea sunt recomandări generale; Abordările optime pentru un anumit sistem pot fi diferite. Dacă nu știți exact câte fișiere să utilizați pentru tempdb, puteți începe cu patru fișiere de date. De obicei, un fișier log este suficient pentru tempdb. Recomandări mai detaliate tempdb veți găsi în materialele afișate în bara laterală "Literatură educațională".

În plus, dimensiunea tempdb ar trebui să fie suficientă pentru a evita operațiile AutoGrow. Ca baze de date personalizate, tempdb va avea întârzieri datorate operațiunilor AutoGrow. Implicit, tempdb conține un fișier de date de 8 MB, un fișier log de 1 MB și 10% din spațiul pentru AutoGrow, care este prea mic pentru majoritatea sarcinilor de producție. De asemenea, este important să rețineți că atunci când reporniți SQL Server, dimensiunea tempdb revine la ultima valoare specificată.

Mărimea și mișcarea fișierelor de date tempdb și a jurnalelor pot fi determinate utilizând codul din secțiunea "Date și fișiere log". Interogarea din listare 2 (de pe site-ul MSDN) arată cum se determină dimensiunea și creșterea procentuală a fișierelor de date tempdb și a jurnalelor.

Drivere de stat solid

Datorită mai multor nuclee, puterea de procesare a crescut și multe sisteme moderne suportă o cantitate foarte mare de memorie RAM, motiv pentru care subsistemul I / O a devenit un obstacol pentru multe sarcini de lucru. Unitățile hard drive tradiționale au devenit mai capabile, dar performanța nu a crescut prea mult. Problema poate fi rezolvată cu ajutorul discurilor SSD. Discurile solid-state reprezintă o tehnologie relativ nouă pentru stocarea datelor, care a început să crească în greutate pe piața serverului SQL în ultimul an. În trecut, costul dispozitivelor SSD era prea mare, iar capacitatea de informare este prea mică pentru multe baze de date de lucru. Unul dintre motivele pentru popularitatea crescândă a unităților SSD este avantajul de performanță față de unitățile tradiționale de discuri cu un arbore rotativ. De exemplu, un disc SCSI atașat Serial (SAS) cu o viteză a arborelui de 15.000 rpm poate oferi o viteză de transfer de 200 MB / s. Pentru comparație, un SSD Serial ATA (SATA) cu o conexiune de 6 GB poate oferi o viteză de transfer de aproximativ 550 MB / s. Principalul motiv pentru superioritatea SSD în performanță este reducerea bruscă a timpului de căutare. Când trebuie să obțineți date de pe un hard disk rotativ, capul trebuie să se deplaseze într-o locație nouă. SSD-ul nu are componente în mișcare, deci deplasarea la o nouă locație de stocare este determinată de viteza celulelor de memorie.

Stocarea cu bliț în stare solidă și rapidă poate fi implementată în mai multe moduri. Aplicațiile tipice sunt SSD-uri de 2,5 inch. Aceste dispozitive sunt conectate direct ca spațiu de stocare DAS, iar interfața electronică este aceeași ca și pentru un hard disk standard. O altă implementare obișnuită a SSD este sub forma plăcilor PCI Express (PCIe) care sunt conectate direct la magistrala de sistem. Această abordare are avantajul de autobuz PCIe rapid, pentru a crește numărul de operațiuni de intrare-ieșire pe secundă (IOPS) și lățimea de bandă, comparativ cu o interfață standard de disc. În plus, multe partiții de stocare SAN un SSD și funcția de distribuție automată a partiții de date, care vă permite să mutați sarcini de lucru critice pe partiția SSD de înaltă performanță, lăsând încărcări de lucru mai puțin critice de pe hard disk-uri mai lent și mai puțin costisitoare.

Există diferite tipuri de SSD-uri. Printre acestea - SSD bazate pe stocare și stocare DRAM SSD bazat pe o tehnologie de memorie flash, cum ar fi celula cu un singur nivel (SLC) și celule cu mai multe nivele (MLC). Fiecare tip are avantajele și dezavantajele sale.

  • DRAM. Ca de obicei RAM pentru un computer, DRAM-ul este foarte rapid, dar fiabil. Pentru DRAM, este necesară o baterie permanentă pentru stocarea datelor pe durata opririi datelor. Astfel de depozite sunt adesea emise sub formă de carduri PCIe instalate pe placa de servere a serverului.
  • SLC. Viteza și ciclul de viață al spațiului de stocare pe SLC sunt mai mari decât cele ale MLC, astfel încât SLC este utilizat în spațiul de stocare SSD la nivel corporativ. Cu toate acestea, prețul dispozitivelor SLC este semnificativ mai mare decât cel al MLC.
  • MLC. De obicei, memoria flash de tipul MLC este utilizată în dispozitivele de consum și este mai ieftină decât SLC. Cu toate acestea, MLC are o viteză mai mică de înregistrare și uzură semnificativ mai mare decât SLC.

La viteză, SSD-urile depășesc performanțele unităților de discuri cu un arbore rotativ, dar durata lor de viață este mult mai scăzută. Aplicațiile cu I / O intensivă, cum ar fi SQL Server, reduc durata de viață a unității SSD. În plus, partea mai utilizată a discului, cu cât speranța de viață este mai mică. Se recomandă să vă asigurați că cel puțin 20% din SSD nu este utilizat. Viteza de citire este stabilă în timpul întregii funcționări a dispozitivului. Cu toate acestea, performanța de scriere se degradează în timpul funcționării, adică timpul necesar înregistrării crește. De asemenea, este important să rețineți că nu este nevoie să defragmentați discurile SSD, deoarece metoda de accesare a datelor este diferită de cea a hard discurilor. De fapt, defragmentarea acestui tip de unitate va reduce doar ciclul lor de viață.

Dacă doriți să utilizați SSD-uri, nu utilizați o singură unitate SSD și fiți pregătit să înlocuiți SSD-urile pe toată durata de viață a serverului. Să enumerăm posibilitățile de utilizare a SSD în SQL Server.

  • Mutarea indecșilor pe SSD-uri. De regulă, indicii nu sunt foarte mari și sunt asociate cu operații intensive de citire aleatorie, deci sunt ideale pentru plasarea pe discuri SSD.
  • Mutarea fișierelor de date pe SSD-uri. Fișierele de date au de obicei mai multe citiri decât scrie, deci în majoritatea cazurilor sunt potrivite pentru SSD-uri.
  • Mutați fișierele jurnal la SSD-uri. Fișierele log sunt asociate cu un număr mare de operații de scriere. Prin urmare, dacă SSD-urile sunt utilizate pentru fișierele jurnal, utilizați SSD-uri de clasă de întreprindere și configurații RAID 1 sau RAID 10 cu oglindire.
  • Mutarea tempdb pe o unitate SSD. De obicei, tempdb are un nivel ridicat de operații de scriere neordonate, ceea ce poate duce la deteriorarea SSD-urilor. Prin urmare, în cazul în care unitățile SSD sunt utilizate pentru tempdb, atunci trebuie să fie din clasa enterprise SSD într-o oglindire RAID 1 sau RAID 10, și unități de stocare SSD au nevoie de plan de înlocuire. În plus, acordați atenție opțiunii cu DRAM PCIe pentru tempdb. Stocarea DRAM oferă o performanță de scriere mai mare și are o durată de viață nelimitată. Cu toate acestea, prețurile de stocare DRAM pot fi ridicate.

Nivelurile de performanță de bază

O altă abordare de bază este de a pregăti nivelurile de performanță de referință și de a compara periodic performanța sistemului cu aceste linii de bază. Acest lucru poate fi foarte util pentru depanarea problemelor, precum și pentru urmărirea creșterii bazei de date și a altor tendințe. Comparația cu linia de bază este una dintre cele mai bune modalități de gestionare proactivă a sistemelor. Subiectul măsurării performanței SQL Server depășește domeniul de aplicare al acestui articol, dar următoarea este o prezentare generală a celor mai importante valori măsurate ale depozitului de date.

Primul grup de contoare de performanță pe care doriți să îl monitorizați este contoarele legate de memoria din monitorul de sistem Windows. Din punct de vedere tehnic, acestea nu sunt contoare de depozite de date, dar dacă nu există suficientă memorie, restul contoarelor nu contează. Asigurați-vă că monitorizați contorul disponibil MBytes al obiectului Memorie. Acest contor arată cantitatea de memorie fizică disponibilă pentru alocare unui proces sau unui sistem. Dacă indicatorul este mai mic de 100 MB, este util să măriți dimensiunea memoriei. Un alt contor important este obiectul% Usage of the Paging File, care arată cantitatea utilizată a fișierului de paginare din Windows. Această valoare trebuie să fie mai mică de 70%. Dacă valoarea este mai mare, atunci sistemul probabil are nevoie de mai multă memorie.

În plus față de contoarele asociate cu memoria Windows, există mai mulți contoare de performanță pentru stocarea Windows Server. Cu toate acestea, citirile acestor contoare sunt utile numai dacă instanța serverului SQL lucrează cu un sistem de stocare DAS atașat direct. Dacă utilizați un SAN, trebuie să acordați atenție măsurătorilor de performanță SAN.

Dacă instanța serverului SQL utilizează DAS, mai întâi asigurați-vă că cel puțin 20% din spațiul de pe fiecare unitate NTFS este liberă. Mai târziu, puteți verifica contoarele de stocare Windows Server folosind monitorul de sistem. Tabelul 1 prezintă cele mai importante contoare; toate sunt asociate cu obiectul Logical Disk.

Organizarea optimă a stocării datelor pe serverul SQL, ferestrele it pro







Articole similare

Trimiteți-le prietenilor: