Nu este un secret faptul că atunci când se gândesc la problemele de configurare a unui server SQL asociate cu creșterea productivității, specialiștii IT fac în cea mai mare parte o alegere în favoarea creșterii hardware-ului. Dar este întotdeauna justificat? Ați folosit deja toate metodele de configurare a serverului? Se știe că lucrul cu parametrii de configurare și modificarea valorilor implicite ale acestora poate îmbunătăți performanța și alte caracteristici ale unui sistem dat. Printre aceste opțiuni de configurare SQL, există o opțiune care are multe întrebări și aceasta este opțiunea - Gradul maxim de paralelism (DOP) - despre asta vom vorbi.
Opțiunea Gradul maxim de paralelism (DOP) determină numărul de fire în care SQL Server poate paralela o interogare și indică numărul de procesoare de server utilizate. Acest parametru este setat la 0 în mod implicit, care este gradul maxim de paralelism. De exemplu, dacă aveți 24 de nuclee, atunci valoarea „gradului maxim de paralelism” va fi 24, iar optimizatorul, dacă consideră necesar, poate utiliza toate procesoarele pentru a executa o instrucțiune, adică interogarea va fi paralelizată în 24 fire. Acest lucru este bun pentru majoritatea cazurilor, dar nu pentru toată lumea. De asemenea, nu este întotdeauna bine să utilizați valoarea implicită pentru acest parametru. Configurarea acestui parametru poate fi necesară, de exemplu, în următoarea situație: să presupunem că avem o aplicație în care toți angajații introduc informații despre operațiunile zilnice și, la o anumită perioadă de timp, fiecare dintre utilizatori execută o cerere care creează un raportează toate operațiunile utilizatorilor pentru o anumită perioadă de timp. Bineînțeles, dacă intervalul de timp este lung, această solicitare va dura mult timp și, cu DOP implicit instalat, va prelua toate procesoarele disponibile, ceea ce, desigur, va afecta munca altor utilizatori. Prin urmare, modificând valoarea DOP, putem crește timpul de răspuns al serverului SQL pentru alți utilizatori fără a schimba interogarea în sine.
MS recomandă setarea valorii după cum urmează:
Setarea parametrului la TSQL în întregime pentru server:
EXEC sp_configure "grad maxim de paralelism", 4; reconfigura
De asemenea, puteți seta această valoare pentru o anumită interogare TSQL:
UTILIZAȚI AdventureWorks2008R2; GO SELECT ProductID, OrderQty, SUM (LineTotal) AS TotalFROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00 GROUP BY ProductID, OrderQty ORDER BY ProductID, OrderQty OPTION (MAXDOP 2); GO
În acest exemplu, sugestia maxdop modifică valoarea implicită a parametrului de grad maxim de paralelism la 2. Puteți vizualiza setarea curentă astfel:
EXEC sp_configure "Show Advanced", 1; RECONFIGURĂ; EXEC sp_configure "grad maxim de paralelism"
Acum să vedem cum afectează această valoare viteza de execuție a interogării. Pentru ca interogarea de test scrisă mai sus să fie executată mai mult timp, vom adăuga o altă selecție la aceasta. Solicitarea va arăta astfel:
< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty
Pe mașina mea de test, „gradul maxim de paralelism” este setat la 0. MSSQL rulează pe o mașină cu un procesor cu 4 nuclee. Am realizat o serie de experimente cu valori MAXDOP diferite: egale cu 1 - fără a paralela interogarea; egal cu 2 - folosind doar 2 nuclee; egal cu 4 - folosind toate și fără indicii pentru a determina varianta care folosește continuarea implicită. Pentru a obține statistici de execuție, trebuie să includeți opțiunea SET STATISTICS TIME ON în interogare și, de asemenea, să activați butonul pentru a afișa planul de interogare în Management studio. Pentru a medie rezultatele obținute, am rulat fiecare interogare într-o buclă de 3 ori. Rezultatele pot fi văzute mai jos:
SELECTați dt.ProductID, dt.OrderQty, SUM (dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 1); SQL Server Execution Times: CPU time = 45942 ms, elapsed time = 46118 ms. SQL Server Execution Times: CPU time = 45926 ms, elapsed time = 46006 ms. SQL Server Execution Times: CPU time = 45506 ms, elapsed time = 45653 ms.
Planul de interogare arată că atunci când a fost instalat indiciul (MAXDOP 1), interogarea a fost executată fără paralelizare. Timp mediu de executare a interogării 45925,66 ms
SELECTați dt.ProductID, dt.OrderQty, SUM (dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 2); SQL Server Execution Times: CPU time = 51684 ms, elapsed time = 28983 ms. SQL Server Execution Times: CPU time = 51060 ms, elapsed time = 26165 ms. SQL Server Execution Times: CPU time = 50903 ms, elapsed time = 26015 ms.
Când a fost instalat indiciul (MAXDOP 2), interogarea a fost executată în paralel pe 2 cpu, puteți vedea acest lucru în Numărul de execuție din planul de execuție a interogării. Timp mediu de executare a interogării 27054,33 ms
SELECTați dt.ProductID, dt.OrderQty, SUM (dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 4); SQL Server Execution Times: CPU time = 82275 ms, elapsed time = 23133 ms. SQL Server Execution Times: CPU time = 83788 ms, elapsed time = 23846 ms. SQL Server Execution Times: CPU time = 53571 ms, elapsed time = 27227 ms.
La instalarea indiciului (MAXDOP 4), cererea a fost executată în paralel pe 4 cpu. Timp mediu de executare a interogării 24735,33 ms
SELECTați dt.ProductID, dt.OrderQty, SUM (dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty SQL Server Execution Times: CPU time = 85816 ms, elapsed time = 23190 ms. SQL Server Execution Times: CPU time = 85800 ms, elapsed time = 23307 ms. SQL Server Execution Times: CPU time = 58515 ms, elapsed time = 26575 ms.
cererea a fost executată în paralel, de asemenea, 4 cpu. Timp mediu de executare a interogării 24357,33ms
link-uri: http://support.microsoft.com/kb/2023536
Ţintă: studiați impactul paralelismului SQL asupra lucrării cu interogări 1C
Literatură:
Mediu de testare:
Windows Server 2008 R2 Enterprise
MS SQL server 2008 R2
1C Enterprise 8.2.19.90
Figura 1. Proprietăți SQL „General”
Figura 2. Proprietăți SQL „Avansate”
Instrumente:
Profiler server SQL
Consola de interogare 1C
Cerere de testare:
ALEGE
Denumirea AK Denumirea AS
DIN
Registrul de informații. AdresăClasificator AS AK
CONEXIUNE INTERNA Registrul de informații. AdressClassifier AS AK1
Software AK.code = AK1.code
Instruire:
Lansăm SQL Server Profiler, stabilim o conexiune, marcăm evenimente și coloane așa cum se arată în Figura 3.
Figura 3. Proprietăți de urmărire
Am setat selecția pentru baza noastră de date
Figura 4. Filtrare după bază
Abrevieri:
Grad maxim de paralelism - MDOP
Prag de cost pentru paralelism - cost
Testarea planului de interogare secvențială (MDOP = 1)
Figura 5. Consolă de interogare - timp de execuție 20 sec.
Parametrul SQL Server „Grad maxim de paralelism” este setat la 1 (fără paralelism). Vedeți rezultatul în profiler (Fig. 6)
Figura 6. Plan de interogare secvențială
Serverul SQL a generat un plan de interogare secvențial, în timp ce: încărcarea totală a procesorului = 6.750 (sec) și timpul pentru executarea interogării = 7.097 (sec)
Testarea planului de interogare paralelă (MDOP = 0, cost = 5)
Am pus serverul SQL în modul paralelism (în interogarea SQL):
USE master;
EXEC sp_configure "arată opțiunea avansată", 1;
RECONFIGURAȚI CU SUPRAVEGHERE
USE master;
exec sp_configure "grad maxim de paralelism", 0;
RECONFIGURAȚI CU SUPRAVEGHERE
Executăm aceeași solicitare (Figura 7)
Figura 7. Consolă de interogare - timp de execuție 16 sec.
Verificarea rezultatului în profiler (Figura 8)
Figura 8. Plan de interogare paralel
De data aceasta, serverul SQL a generat un plan de interogare paralel, cu încărcarea totală a procesorului = 7.905 secunde, iar durata execuției interogării = 3.458 secunde
Testarea planului de interogare secvențială (MDOP = 0, cost = 150)
Să încercăm să scăpăm de planul paralel folosind parametrul „Prag de cost pentru paralelism”. În mod implicit, parametrul este setat la 5. În cazul nostru, am reușit să scăpăm de formarea unui plan paralel la o valoare de 150 (în SQL Query):
USE master;
exec sp_configure „prag de cost pentru paralelism”, 150 ;
Verificăm executarea cererii în aceste condiții (Fig. 9)
Figura 9. Consolă de interogare - timp de execuție 20 sec.
Verificarea rezultatului în profiler (Fig. 10)
Figura 10. Plan de interogare secvențială.
SQL Server a generat un plan de interogare secvențial. Încărcare totală CPU = 7.171 sec, timp de execuție a interogării = 7.864 sec.
Concluzii:
Executarea unei interogări de testare într-un mediu 1C Enterprise folosind un server SQL al unui plan de interogare paralel oferă o creștere semnificativă a performanței în comparație cu un plan secvențial (16 secunde versus 20 de secunde - un câștig de 4 secunde)
· Executarea unei interogări de testare de către serverul SQL însuși atunci când se utilizează un plan de interogare paralel este de două ori mai rapidă decât atunci când se utilizează un plan de interogare secvențială (3,5 secunde față de 7,1 secunde)
· Paralelismul serverului SQL poate fi ajustat nu numai utilizând parametrul MDOP, ci și parametrul „Pragul de cost pentru paralelism”
- Tutorial
Această instrucțiune este destinată începătorilor care caută un ghid simplu în limba rusă de instalat versiune în limba engleză SQL Server 2012, care va fi utilizat în continuare pentru SharePoint 2013.
Acest articol nu este destinat profesioniștilor.
Toate lucrările sunt împărțite în 3 etape:
- Instalarea SQL Server 2012
- Configurarea gradului maxim de paralelism Opțiunea de configurare a serverului
- Stabilirea drepturilor cont pentru instalarea SharePoint 2013
Atenție: există multe imagini sub tăietură!
Instalarea SQL Server 2012
1. Înainte de instalare, asigurați-vă că există suficient spațiu liber pe hard disk (în cazul meu, a fost nevoie de 2,7 GB).După lansarea kitului de distribuție, selectați elementul „ Instalare„în meniul din stânga, apoi„ faceți clic pe „element” Noul SQL Server autonom sau adăugați caracteristici la o instalare existentă":
2. Vor începe programul de instalare. El va verifica. Puteți face clic pe butonul „Afișați detaliile” și puteți vedea un raport detaliat: 
3. Raport detaliat. Apăsați butonul „OK”: 
4. Introduceți cheia de produs și faceți clic pe butonul Următor: 
5. Suntem de acord cu termenii contractului de licență.
Pentru aceasta, bifați caseta „ Accept termenii licenței
6. La pasul „Setup Role”, selectați primul element „ Instalarea caracteristicii SQL Server". Apăsați butonul Următor: 
7. La pasul „Selecție caracteristică”, bifați „ Servicii pentru motor de baze de date", "Instrumente de gestionare - de bază" și " Instrumente de gestionare - complete Apoi apăsați butonul Următor: 
8. Instalatorul va efectua apoi o altă verificare. Puteți face clic pe butonul „Afișați detaliile” și puteți vedea un raport detaliat: 
9. Raport detaliat. (În acest stadiu, am primit o eroare la regula „Microsoft .NET Framework 3.5 este instalat ...”. Mai multe despre asta mai jos). Apăsați butonul „Următorul”: 
10. La pasul „Configurare instanță”, trebuie să configurați o instanță a serviciului SQL Server.
Din nou, acest articol este destinat începătorilor. Prin urmare, vom presupune că SQL Server nu a fost instalat anterior pe serverul dvs., ceea ce înseamnă că vom lăsa toate setările implicite. Apăsați butonul „Următorul”: 
11. La acest pas, expertul de instalare va afișa cerințele de spațiu pe disc. Apăsați butonul „Următorul”: 
12. La pasul "Configurare server", trebuie să specificați un cont de domeniu pentru serviciu " Motor de baze de date SQL Server". După completarea câmpurilor" Numele contului "și" Parola "apăsați butonul" Următorul ": 
13. La pasul „Configurarea motorului bazei de date”, este suficient să adăugați utilizatorul curent la administratorii serverului SQL. Pentru aceasta, faceți clic pe butonul „Adăugați un utilizator curent”, apoi faceți clic pe butonul „Următorul”: 
14. La pasul următor, faceți clic pe butonul Următor: 
15. Apoi, expertul de instalare va rula din nou verificarea și va afișa rezultatele. Apăsați butonul „Următorul”: 
16. La pasul „Ready to Install”, expertul va afișa un rezumat al informațiilor. Aici trebuie să faceți clic pe butonul „Instalare”: 
17. După finalizarea instalării, vor fi afișate informații despre operațiile efectuate: 
18. Vă recomand cu tărie să reporniți computerul în această etapă. În unele cazuri (de exemplu, la instalarea Microsoft .NET Framework 3.5), expertul de instalare în sine va afișa o fereastră care vă solicită să reporniți computerul. Nu refuza.
Configurarea gradului maxim de paralelism Opțiunea de configurare a serverului
Valoarea implicită pentru gradul maxim de paralelism este 0.SharePoint 2013 necesită ca acest parametru să fie 1.
Este ușor de remediat!
1. Aleargă Microsoft SQL Server Management Studio(Start - Toate programele - Microsoft SQL Server 2012 - SQL Server Management Studio).
2. În ecranul de conectare la server, faceți clic pe butonul „Conectare”.
3. Faceți clic dreapta pe serverul dvs. în „ Explorator de obiecte„și selectați elementul” Proprietăți":
4. În fereastra de proprietăți a serverului care se deschide, în meniul din stânga selectați pagina " Avansat"și derulați lista de proprietăți până în partea de jos a ecranului. Setați valoarea parametrului" Grad maxim de paralelism"în 1
și faceți clic pe butonul „OK”: 
5. Nu închideți SQL Server Management Studio, va fi util pentru noi.
Configurarea drepturilor contului pentru instalarea SharePoint 2013
Contul sub care se va efectua instalarea SharePoint 2013 trebuie să aibă drepturi ridicate în serverul SQL.Se recomandă ca acestui cont să i se acorde următoarele roluri:
- dbcreator
- securityadmin
- public
2. În câmpul „Nume autentificare”, introduceți Numele domeniului contul din care intenționați să instalați și să configurați SharePoint 2013.
3. În meniul din stânga, selectați pagina " Roluri de server"și verificați rolurile" dbcreator "și" securityadmin "și asigurați-vă, de asemenea, că rolul" public "este deja bifat. Apoi faceți clic pe butonul" OK ": 
SQL Server este acum gata să instaleze SharePoint 2013.
Instalarea Microsoft .NET Framework 3.5 în MS Windows Server 2012 R2 Standart
La pasul numărul 9 al paragrafului " Instalarea SQL Server 2012"Am primit o eroare: .NET Framework 3.5 nu a fost instalat.Pentru a rezolva această problemă, urmați acești pași:
1. Trebuie să deschideți consola " Manager server".
2. În meniul din stânga, selectați elementul „Tablou de bord”.
3. În centrul ferestrei, faceți clic pe elementul „Adăugați roluri și caracteristici”.
4. În expertul care se deschide, săriți pasul „Înainte de a începe”.
5. La pasul „Tipul de instalare”, selectați „ Instalare bazată pe roluri sau bazată pe caracteristici Apăsați butonul „Următorul”.
6. La pasul următor, lăsați totul în mod implicit și faceți clic pe butonul „Următorul”.
7. Omiteți pasul „Roluri server” făcând clic pe butonul „Următorul”.
8. La pasul „Caracteristici”, bifați caseta de selectare „Caracteristici .NET Framework 3.5”. Apăsați butonul „Următorul”.
9. După finalizarea procesului de instalare, puteți închide Expertul Adăugare roluri și caracteristici.
10. Gata!
Toate bunătățile și cerul liniștit deasupra capului tău!
P.S. Ziua fericită a cosmonauticii!
Gradul maxim de paralelism (DOP) este o opțiune avansată de configurare SQL Server care are multe întrebări și a fost acoperită în multe publicații. În această postare pe blog, autorul speră să ofere o anumită claritate cu privire la ceea ce face această opțiune și la modul de utilizare.
În primul rând, autorul ar dori să îndepărteze orice îndoială că opțiunea de mai sus stabilește cât de multe procesoare SQL Server poate folosi atunci când servește mai multe conexiuni (sau utilizatori) - nu este! Dacă SQL Server are acces la patru procesoare inactive și este configurat să utilizeze toate cele patru procesoare, acesta va utiliza toate cele patru procesoare, indiferent de gradul maxim de paralelism.
Deci, ce face această opțiune? Această opțiune stabilește numărul maxim de procesoare pe care SQL Server le poate utiliza pentru o singură interogare. Dacă interogarea către SQL Server ar trebui să revină volum mare date (multe înregistrări), uneori are sens să o paralelizăm, împărțindu-le în mai multe interogări mici, fiecare dintre acestea returnând propriul său subgrup de rânduri. Astfel, SQL Server poate folosi mai multe procesoare și, prin urmare, pe sistemele multiprocesor, un număr mare de înregistrări întregi de interogare pot fi returnate mai repede decât pe un sistem uniprocesor.
Există multe criterii care trebuie îndeplinite înainte ca SQL Server să apeleze „Paralelism de interogare interioară” și nu are rost să le detaliați aici. Le puteți găsi în BOL căutând sintagma „Grad de paralelism”. Se spune că decizia privind paralelizarea se bazează pe disponibilitatea memoriei către procesor și, în special, pe disponibilitatea procesorelor în sine.
Deci, de ce ar trebui să luăm în considerare utilizarea acestei opțiuni - deoarece lăsând-o la valoarea implicită (SQL Server însuși decide să se paralelizeze), uneori se pot obține efecte nedorite. Aceste efecte arată cam așa:
Interogările paralelizate sunt mai lente.
Timpul de execuție al cererilor poate deveni nedeterminist și acest lucru poate deranja utilizatorii. Timpii de execuție se pot modifica deoarece:
Interogarea poate fi uneori paralelizată și alteori nu.
O cerere poate fi blocată de o cerere paralelă în cazul în care procesoarele au fost supraîncărcate cu muncă.
Înainte de a continua, autorul ar dori să sublinieze că nu este nevoie specială de a se arunca în interiorul paralelismului. Dacă sunteți interesat de acest lucru, puteți citi articolul „Prelucrare paralelă a interogărilor” din Cărți on-line, care oferă aceste informații mai detaliat. Autorul consideră că există doar două lucruri importante de știut despre organizarea internă a paralelismului:
Interogările paralele pot genera mai multe fire decât cele specificate în opțiunea „Grad maxim de paralelism”. DOP 4 poate genera mai mult de douăsprezece fire, patru pentru o interogare și fire suplimentare utilizate pentru sortări, fire, agregate și ansambluri etc.
Solicitările paralelizate pot determina așteptarea diferitelor SPID-uri cu tipul de așteptare CXPACKET sau 0X0200. Acest lucru poate fi folosit pentru a găsi acele SPID-uri care sunt în așteptare în operațiuni paralele și au waittype: CXPACKET în sysprocesses. Pentru a facilita această sarcină, autorul sugerează utilizarea procedurii stocate în blogul său: track_waitstats.
Deci, „interogarea poate rula mai lent atunci când este paralelizată”
Dacă sistemul este foarte slab debit subsistemele de disc, atunci când se analizează o cerere, descompunerea acesteia poate dura mai mult decât fără paralelism.
Posibila înclinare a datelor sau blocarea intervalelor de date pentru procesor, cauzată de un alt proces utilizat în paralel și început mai târziu etc.
Dacă nu există un index pentru predicat, ceea ce duce la o scanare a tabelului. Operațiunea paralelă într-o interogare poate ascunde faptul că interogarea ar rula mult mai repede cu un plan de execuție secvențial și cu indexul corect.
Din toate acestea urmează recomandarea de a verifica execuția cererii fără paralelism (DOP = 1), acest lucru va ajuta la identificarea posibilelor probleme.
Efectele paralelismului menționate mai sus ar trebui, prin ele însele, să vă conducă la ideea că mecanica internă a interogărilor de paralelizare nu este adecvată pentru utilizare în aplicațiile OLTP. Acestea sunt aplicații pentru care modificarea timpilor de execuție a interogării poate fi deranjantă pentru utilizatori și pentru care este puțin probabil ca un server care deservește mai mulți utilizatori să aleagă un plan de execuție paralel datorită profilului inerent al sarcinii de lucru a procesorului acestor aplicații.
Prin urmare, dacă aveți de gând să folosiți paralelismul, atunci cel mai probabil va fi necesar pentru activități de extragere a datelor (depozit de date), suport de decizie sau sisteme de raportare, unde nu există multe cereri, dar acestea sunt destul de grele și rulează pe un server puternic cu o cantitate mare de memorie operațională.
Dacă decideți să utilizați concurența, ce valoare ar trebui să setați pentru DOP? Este o bună practică pentru acest mecanism că, dacă aveți 8 procesoare, setați DOP = 4 și acesta este cel mai probabil setarea optimă. Cu toate acestea, nu există nicio garanție că va funcționa astfel. Singura modalitate de a fi sigur de acest lucru este de a testa diferite valori pentru DOP. În plus, autorul a dorit să ofere sfaturile sale empirice pentru a nu stabili niciodată acest număr mai mult de jumătate din numărul de procesoare disponibile. Dacă autorul ar avea mai puțin de șase procesoare, el ar fi setat DOP la 1, ceea ce pur și simplu nu permite paralelizarea. Ar putea face o excepție dacă ar avea o bază de date care acceptă un singur proces de utilizator (unele tehnologii de extragere a datelor sau sarcini de raportare), în acest caz, ca excepție, va fi posibil să setați DOP la 0 (valoarea implicită), care permite Depinde de SQL Server să decidă asupra necesității de a paralela o interogare.
Înainte de a încheia articolul, autorul a dorit să vă avertizeze că crearea paralelă a indexurilor depinde de numărul setat pentru DOP. Acest lucru înseamnă că este posibil să doriți să îl modificați în momentul creării sau recreării indexului pentru a îmbunătăți performanța acestei operații și, bineînțeles, puteți utiliza sugestia MAXDOP în interogare, care vă permite să ignorați setul de valori în configurație și poate fi utilizat în timpul orelor de vârf ....
În cele din urmă, solicitarea dvs. poate încetini atunci când se paralelizează din cauza erorilor, deci asigurați-vă că aveți cel mai recent service pack instalat pe server.
| CREATE proc track_waitstats (@num_samples int = 10 , @ delaynum int = 1 , @ delaytype nvarchar ( 10 ) = "minute") AS - T. Davidson - Această procedură stocată este furnizată = CA ESTE = fără garanții,- și nu conferă drepturi. - Utilizarea eșantioanelor de script incluse este supusă termenilor - specificat la http://www.microsoft.com/info/cpyright.htm - @num_samples este de câte ori se captează statistici de așteptare, - implicit este de 10 ori. intervalul de întârziere implicit este de 1 minut - delaynum este intervalul de întârziere. delaytype specifică dacă - intervalul de întârziere este de minute sau secunde - creați tabelul cu stări de așteptare dacă nu există, altfel trunchiați set nocount on dacă nu există (selectați 1 din sysobjects unde name = "waitstats") creează tabele waitstats (varchar ( 80 ), solicită numeric ( 20 ,1 ), numeric ( 20 ,1 ), numeric ( 20 ,1 ), acum datetime implicit getdate ()) altfel trunchiază tabele de așteptare dbcc sqlperf (așteptați, ștergeți) - ștergeți statisticile de așteptare declar @i int, @ delay varchar ( 8 ), @ dt varchar ( 3 ), @ now datetime, @ totalwait numeric ( 20 ,1 ), @ endtime datetime, @ begintime datetime, @ hr int, @ min int, @ sec int select @i = 1 selectați @dt = minuscule (@delaytype) când „minute” apoi „m” când „minut” apoi „m” când „min” apoi „m” când „mm” apoi „m” când „mi” apoi „m” când „m” apoi „m” când „secunde” apoi „s” când „al doilea” apoi „s” când „sec” apoi „s” când „ss” atunci „s” când „s” apoi „s” altfel @ tip de întârziere se termină dacă @dt nu este în ("s", "m") începe imprimarea „vă rugăm să furnizați tip de întârziere, de exemplu, secunde sau minute” returnează sfârșitul dacă @dt = "s" începe selectează @sec = @ delaynum% 60 selectați @min = cast ((@delaynum / 60 ) ca int) selectați @hr = cast ((@min / 60 ) ca int) selectați @min = @ min% 60 încheie dacă @dt = "m" începe selectează @sec = 0 selectați @min = @ delaynum% 60 selectați @hr = cast ((@delaynum / 60 ) ca int) final selectați @delay = dreapta („0” + convert (varchar ( 2 ), @ HR), 2 2 ), @ min), 2 ) + ":" + + dreapta ("0" + convert (varchar ( 2 ), @ sec), 2 ) dacă @hr> 23 sau @min> 59 sau @sec> 59 începe selectați "hh: mm: ss timpul de întârziere nu poate> 23:59:59" selectați „interval de întârziere și tastați:” + convertiți (varchar ( 10 ), @ delaynum) + "," + @delaytype + "convertește în" + @delay return end în timp ce (@i<= @num_samples) begin insert into waitstats (, requests, ,) exec ("dbcc sqlperf(waitstats)" ) select @i = @i + 1 waitfor delay @delay End --- create waitstats report execute get_waitstats --//--//--//--//--//--//--//--//--//-//--//--//--//--//--//--//--//--/ CREAȚI proc get_waitstats AS - Această procedură stocată este furnizată = CA ESTE = fără garanții și- nu conferă drepturi. - Utilizarea eșantioanelor de script incluse este supusă condițiilor specificate - la http://www.microsoft.com/info/cpyright.htm -- - acest proc va crea un raport privind statisticile de așteptare listând tipurile de așteptare după- procent - poate fi rulat când se execută track_waitstats set nocount on declare @now datetime, @ totalwait numeric ( 20 ,1 ), @ endtime datetime, @ begintime datetime, @ hr int, @ min int, @ sec int select @ now = max (now), @ begintime = min (now), @ endtime = max (now) from waitstats where = " Total " --- scădeți waitfor, sleep și resource_queue din Total selectați @totalwait = sum () + 1 de la statisticile de așteptare unde nu se află („WAITFOR”, „SLEEP”, „RESOURCE_QUEUE”, „Total”, „*** total ***”) și acum = @now - introduceți totalurile ajustate, clasificate în procente descrescătoareștergeți waitstats where = "*** total ***" și acum = @now insert in waitstats selectați "*** total ***", 0 , @ totalwait, @ totalwait, @ acum selectați ,, procent = distribuit ( 100 * / @ totalwait ca numeric ( 20 ,1 . |
Această postare va vorbi numai despre MS SQL Server. Dacă veți „încerca norocul” în utilizarea 1C cu Oracle, DB2, Postrgre, aceste informații vă vor fi inutile. Dar trebuie să înțelegeți că în 1C există, în primul rând, specialiști în serverele MS SQL. Specialiștii DB2 apar, de asemenea, datorită eforturilor IBM. Este posibil să argumentăm mult timp dacă este un SGBD bun sau rău, un lucru este important, cel mai „lin” 1C funcționează cu serverul MS SQL. Judecând după ultimele mesaje din „front”, lucrul cu DB2 a devenit mai mult sau mai puțin decent. Deși personal am avut experiență în configurarea 1C pentru a lucra cu DB2 înapoi în versiunea 8.1, totul nu a fost cumva foarte bun acolo. În orice caz, alegerea unui alt SGBD ar trebui să fie clar motivată - fie prin caracteristici care nu se află în MS SQL (un cluster cu echilibrare a sarcinii, Grid etc.), fie prin finanțare (Oracle a fost deja achiziționat), fie de către platformă (totul este pe Linux).
Deci, în ordine, ce trebuie făcut cu MS SQL Server:
1) Configurați dimensiunea minimă și maximă a memoriei. Minimul este jumătate din memoria sistemului. Maxim - memorie de sistem fără 2 GB. Acest lucru se face prin Management Studio - în proprietățile serverului:
2) Dacă prioritatea nu este setată în fila „Procesoare” - trebuie să o setați
3) Setați gradul maxim de paralelism la 1.
4) Pornim agentul SQL Server, configurăm Mail Mail - nu este nimic dificil acolo, nu voi descrie în detaliu.
5) Configurați planuri de servicii:
General:
a) Actualizarea statisticilor - la fiecare 2 ore
b) DBCC FREEPROCCACHE - la fiecare 2 ore
Pentru fiecare bază:
a) Backup complet
b) Backup diferențial
c) Indici de defragmentare - în fiecare zi
d) Reconstituirea indexului - seara de weekend
e) Verificarea integrității bazei - o dată pe lună noaptea în weekend
6) Vă recomandăm să setați modelul de recuperare ca simplu pentru fiecare bază de date (în proprietăți). Dacă nu aveți un sistem 24/7 și mai puțin de 1000 de utilizatori pe bază, nu există un cluster de failover și nu ați semnat un SLA în care vă angajați în caz de eșec al vreunui echipament pentru a restabili datele în cea mai apropiată secundă (și nu din momentul ultimei copii de rezervă) această recomandare ar fi rezonabilă. În caz contrar, veți gândi foarte curând mult timp și frenetic ce să faceți cu jurnalul Tranzaction crescut
7) Mutați baza de date tempdb din bazele de date obișnuite pe un alt disc - chiar dacă trebuie să reconfigurați matricea RAID și să reduceți performanța acesteia. În caz contrar, 1 utilizator va putea paraliza munca tuturor celorlalți. Dacă aveți Hardware Accelereator în loc de un hard disk, atunci, desigur, puteți lăsa tempdb pe el și pune tempdb pe el, dar acest lucru este doar dacă există unul.
8) instalați un instrument de monitorizare - de exemplu, îmi place spotlight http://www.quest.com/spotlight-on-sql-server-enterprise/
9) Testați-vă cu analizatorul de bune practici Microsoft - http://www.microsoft.com/download/en/details.aspx?id=15289 - un instrument excelent care vă ajută nu numai cu setările, ci și cu rezolvarea multor probleme.
Acum, pe scurt, de ce am făcut toate acestea:
1) Memorie. Valoarea minimă vă va salva pur și simplu de „erori” atunci când serverul SQL, dintr-un anumit motiv cunoscut doar de el, nu folosește toată memoria disponibilă. Trebuie să mănânce totul! Valoarea maximă vă va salva de la schimb în cazul în care același optimizator de memorie al serverului SQL decide ce altceva ar fi în cale ...
3) Un punct foarte important - IHMO trebuie setat la 1 în toate sistemele tranzacționale. În primul rând, previne unele blocări între diferite procese care încearcă să execute o cerere și, în consecință, ne scutește de unele erori „ciudate”. În al doilea rând ... 1 cerere „ucigașă” va putea extrage toate resursele serverului, ceea ce este oarecum nedrept în raport cu restul utilizatorilor de sistem. Parametrul în sine determină câte nuclee de procesor 1 cerere poate fi procesată.
5) Statisticile și ștergerea memoriei cache procedurale sunt „după ureche”, dar uităm adesea despre reindexare. Între timp, această procedură este destul de importantă, mai ales că volumul bazei de date crește, importanța acesteia crește. Uneori, până la 60% din performanță se pierde din cauza fragmentării indexurilor.
7) Dacă aveți un Accelerator Hardware sau doar 2 discuri cu viteze de acces diferite, aș recomanda, de asemenea, să vă gândiți la alocarea grupurilor de fișiere în bazele de date și la împărțirea tabelelor separate în diferite matrice de discuri cu timpi de acces diferiți. Trebuie să fiți de acord că PH-ul „mărfuri în depozite” și cartea de referință „Depozitarea informațiilor suplimentare” sunt 2 obiecte, ale căror cerințe de depozitare sunt fundamental diferite. Nu este necesar să stocați toate fișierele și imaginile în baza de date pe o matrice rapidă - o puteți selecta ca una separată, nu atât de rapidă, dar acolo unde există mult spațiu (și nu vă fie teamă să încărcați o grămadă de fișiere la baza de date mai târziu, apropo).
