Գաղտնիք չէ, որ մտածում է SQL սերվերը կազմաձեւելու խնդիրների մասին, որոնք կապված են կատարման բարձրացման հետ, ապա դրա մասնագետները ընտրություն են կատարում հօգուտ ապարատի աճի: Բայց արդյոք դա միշտ արդարացված է: Արդյոք օգտագործված սերվերի տեղադրման բոլոր մեթոդներն են: Հայտնի է, որ կազմաձեւման պարամետրերով աշխատելը եւ դրանց լռելյայն արժեքները փոխելը ունակ է բարելավել այս համակարգի կատարողականը եւ այլ բնութագրերը: Կազմաձեւման այս տարբերակներից SQL կազմաձեւումը ունի մեկ տարբերակ, շատ հարցերով, սա տարբերակն է `զուգահեռության առավելագույն աստիճան (DOP) - ահա այդ մասին եւ խոսենք դրա մասին:
Զուգահեռության (DOP) տարբերակի առավելագույն աստիճանը որոշում է թելերի քանակը, որոնք SQL Server- ը կարող է զուգահեռեցնել հարցումը եւ նշանակում է օգտագործված սերվերի վերամշակողների քանակը: Լռելյայն պարամետրը 0-ն է `զուգահեռության առավելագույն աստիճան: Օրինակ, եթե ունեք 24 միջուկ, ապա «զուգահեռության առավելագույն աստիճանի» արժեքը հավասար կլինի 24-ի եւ օպտիմիզատորի, եթե այն անհրաժեշտ է համարում բոլոր պրոցեսորները, այսինքն, հարցումը կատարելու համար զուգահեռ լինել 24 հոսքով: Շատ դեպքերի համար սա լավ է, բայց ոչ բոլորի համար: Նաեւ միշտ չէ, որ լավ է, օգտագործելով այս կանխադրված պարամետրի արժեքը: Այս պարամետրը կարող է անհրաժեշտ լինել, օրինակ, անհրաժեշտ է հետեւյալ իրավիճակում. Օրինակ, մենք ունենք դիմում, որում բոլոր աշխատակիցները տեղեկատվություն են ներկայացնում ամենօրյա գործառնությունների մասին, յուրաքանչյուր օգտագործող Հաղորդում բոլոր օգտագործողների գործողությունների վերաբերյալ որոշ ժամանակի դադարեցման համար: Բնականաբար, եթե ժամանակի բացը մեծ է, այս հարցումը կկատարվի երկար ժամանակ, եւ դոպը լռելյայն տեղադրելիս կվերցնի բոլոր մատչելի վերամշակողները, որոնք, բնականաբար, կազդի այլ օգտագործողների գործունեության վրա: Հետեւաբար, փոխելով դոպի արժեքը, մենք կարող ենք առանց հարցման փոփոխության փոփոխության, այլ օգտվողների SQL սերվերի պատասխանը մեծացնելու համար:
MS- ը խորհուրդ է տալիս սահմանել արժեքը հետեւյալ կերպ.
Պարամետրը server server- ի համար դնելով պարամետրը.
Exec sp_configure «զուգահեռության առավելագույն աստիճան», 4; Վերափոխում:
Կարող եք նաեւ այս արժեքը դնել TSQL- ի հատուկ հարցման համար.
Օգտագործեք AdventureWorks2008R2; Գնացեք Ընտրեք ProductID, CORNALTY, SUM (TOINETAL) AS TOTALFROM Sales.SalesorderDetail, որտեղ միավորը< $5.00 GROUP BY ProductID, OrderQty ORDER BY ProductID, OrderQty OPTION (MAXDOP 2); GO
Այս օրինակում «ակնարկ» MaxDop- ը փոխում է զուգահեռության պարամետրի առավելագույն աստիճանի լռելյայն արժեքը 2. Դիտեք ներկայիս պարամետրը.
Exec sp_configure «Show ույց տալ առաջադեմ», 1; Վերափոխում; Exec sp_configure «զուգահեռության առավելագույն աստիճան»
Հիմա տեսնենք, թե ինչպես է այս արժեքը ազդում հարցման կատարման արագության վրա: Վերը նշված փորձարկման հարցման համար ավելի երկար ժամանակ գրված է, ավելացրեք եւս մեկ ընտրություն դրան: Հայցը ձեռք կբերի հետեւյալ ձեւը.
< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty
Իմ փորձարկման մեքենայի վրա ցուցադրվում է «Զուգահեռության առավելագույն աստիճանը» արժեքը 0. MSSQL- ը գործարկվում է 4 հիմնական պրոցեսորով մեքենայի միջոցով: Ես իրականացրեցի մի շարք փորձեր `տարբեր MaxDop արժեքներով. Հավասար է 1-ին` առանց հարցման զուգահեռացման. Հավասար է 2-ին `օգտագործելով ընդամենը 2 միջուկ; Հավասար 4 - Օգտագործելով բոլոր եւ առանց ակնարկի `որոշելու այն տարբերակը, որն օգտագործում է լռելյայն շարունակությունը: Կատարման վիճակագրությունը ձեռք բերելու համար հարցումը պետք է ներառվի սահմանված վիճակագրության ժամանակ տարբերակի ժամանակ, ինչպես նաեւ հնարավորություն ստացեք Management Studio- ում հարցման պլանի ցուցադրման կոճակը: Ստացված արդյունքների միջին հաշվով ես 3 անգամ կատարեցի ցիկլի յուրաքանչյուր հարցում: Արդյունքները կարելի է տեսնել ստորեւ.
Ընտրեք DT.Productid, DT.ORDERQTY, SUMSE (DT.LUETOTAL) AS MEDEST SALESS.SALESORDEDETAIL DT, (Ընտրեք * Sales.Salesordetail- ը< $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.
Հարցման առումով պարզ է, որ ակնարկը տեղադրելու ժամանակ (MaxDop 1) տեղադրելիս հարցումը կատարվում էր առանց զուգահեռացման: Հարցման կատարման միջին ժամանակը 45925.66 MS
Ընտրեք DT.Productid, DT.ORDERQTY, SUMSE (DT.LUETOTAL) AS MEDEST SALESS.SALESORDEDETAIL DT, (Ընտրեք * Sales.Salesordetail- ը< $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.
Ակնարկը (MaxDop 2) տեղադրելիս հարցումը կատարվել է 2 CPU- ի զուգահեռ, այն կարելի է տեսնել հարցման կատարման առումով կատարման քանակի վրա: Հարցման կատարման միջին ժամանակը 27054.33 MS
Ընտրեք DT.Productid, DT.ORDERQTY, SUMSE (DT.LUETOTAL) AS MEDEST SALESS.SALESORDEDETAIL DT, (Ընտրեք * Sales.Salesordetail- ը< $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.
Հուշում տեղադրելու ժամանակ (MaxDop 4) հարցումը կատարվել է 4 պրոցեսորի զուգահեռ: Հարցման միջին կատարման ժամանակը 24735.33 MS
Ընտրեք DT.Productid, DT.ORDERQTY, SUMSE (DT.LUETOTAL) AS MEDEST SALESS.SALESORDEDETAIL DT, (Ընտրեք * Sales.Salesordetail- ը< $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.
Հայցը կատարվել է զուգահեռ, ինչպես նաեւ 4 պրոցեսոր: Հարցման միջին ժամանակը 24357.33MMS
Հղումներ, http://support.microsoft.com/kb/2023536
Նպատակը. Քննեք SQL զուգահեռության ազդեցությունը `1C պահանջների հետ աշխատելու համար
Գրականություն:
Թեստային միջավայր.
· Windows Server 2008 R2 ձեռնարկություն
· MS SQL Server 2008 R2
· 1CC ձեռնարկություն 8.2.19.90
Նկար 1. SQL հատկություններ «General»
Գծապատկեր 2. SQL հատկություններ «ADVANSED»
Գործիքներ:
· SQL Server Profiler
· 1C- ի հարցումների վահանակ
Թեստի հարցում.
Ընտրել
Ak Անուն որպես անուն
ՀԱՅԱՍՏԱՆԻ
Գրանցում: Press նշման դասակարգիչ, որպես AK
Ներքին կապ Գրանցվել. Press նշման դասակարգիչ, ինչպես AK1
AC.KOD \u003d AK1.KOD
Պատրաստում.
Մենք գործարկում ենք SQL Server Profiler- ը, սահմանում ենք կապը, նշեք իրադարձությունները եւ սյուները, ինչպես ցույց է տրված Նկար 3-ում:
Գծապատկեր 3. Հետքի հատկություններ
Տեղադրեք ընտրությունը մեր տվյալների բազայի համար
Գծապատկեր 4. Հիմքի զտիչ
Կրճատում:
Զուգահեռության առավելագույն աստիճան - MDOP
· SOST շեմը զուգահեռության համար `արժեք
Թեստավորում հաջորդական հարցման պլանի (MDOP \u003d 1)
Նկար 5. Հայցեք վահանակ - կատարողականի ժամանակը 20 վրկ:
SQL սերվերը «Զուգահեռության առավելագույն աստիճան» սերվերը սահմանված է 1-ի (առանց զուգահեռության): Մենք նայում ենք արդյունքին պրոֆիլում (Նկար .6)
Նկար 6. Հաջորդական հարցման պլանը
SQL Server- ը ձեւավորել է հաջորդական հարցման պլան, մինչդեռ. Ընդհանուր բեռնման CPU \u003d 6,750 (ներ) եւ հարցման կատարման ժամանակը \u003d 7,097 (ներ)
Զուգահեռ հայցադիմումի պլան (MDOP \u003d 0, արժեք \u003d 5)
Տեղափոխեք SQL Server- ին զուգահեռության ռեժիմին (SQL հարցումում).
Օգտագործեք վարպետ;
Exec sp_configure «Show ույց տալ առաջադեմ տարբերակը», 1;
Վերափոխում է գերակշռել:
Օգտագործեք վարպետ;
exec sp_configure «զուգահեռության առավելագույն աստիճան», 0;
Վերափոխում է գերակշռել:
Կատարել նույն հարցումը (Նկար 7)
Գծապատկեր 7. Վահանակի հայցեր - կատարման ժամանակը 16 վրկ.
Ստուգեք արդյունքը պրոֆիլավորողի մեջ (Նկար 8)
Գծապատկեր 8. Զուգահեռ հայցի պլան
SQL Server- ի այս անգամ ձեւավորվել է զուգահեռ հարցման պլան, մինչդեռ CPU- ի ընդհանուր բեռնումը \u003d 7,905 վայրկյան է, իսկ հարցման տեւողությունը \u003d 3,458 վայրկյան
Թեստավորում հաջորդական հարցման պլանի (MDOP \u003d 0, արժեք \u003d 150)
Մենք կփորձենք ազատվել զուգահեռ ծրագրից `օգտագործելով« զուգահեռության համար »պարամետրը: Լռելյայն պարամետրը սահմանված է 5. Մեր դեպքում, զուգահեռ ծրագրի ձեւավորումից, հնարավոր էր ազատվել 150-ից (SQL հարցում).
Օգտագործեք վարպետ;
exec sp_configure. «Արժեքի շեմն զուգահեռների համար», 150 ;
Ստուգեք հարցման կատարումը այս պայմաններում (Նկար 9)
Գծապատկեր 9. Վահանակների հայցեր - կատարման ժամանակը 20 վրկ.
Ստուգեք արդյունքը պրոֆիլավորողի մեջ (Նկար 10)
Գծապատկեր 10. Հաջորդական հարցման պլանը:
SQL սերվերը ձեւավորել է հաջորդական հարցման պլան: Ընդհանուր բեռնման CPU \u003d 7.171 վայրկյան, հարցման կատարման ժամանակը \u003d 7, 864 վայրկյան:
Եզրակացություններ.
· 1C ձեռնարկության միջավայրում փորձարկման հարցման կատարումը SQL սերվերի զուգահեռ պլանի օգտագործմամբ սերվերը տալիս է զգալի կատարողականի շահույթ `համեմատած հաջորդական ծրագրի հետ (16 վայրկյան` 20 վայրկյանում `4 վրկ):
· Կատարել թեստային հարցումը SQL Server- ի կողմից զուգահեռ հարցման պլան օգտագործելիս երկու անգամ ավելի արագ է տեւում ավելի արագ, քան հաջորդական հարցման պլանը օգտագործելիս (3,5 վրկ):
· SQL Server- ի զուգահեռությունը չի կարող ճշգրտվել ոչ միայն օգտագործելով MDOP պարամետրը, այլեւ պարամետրը `« Արժեքի շեմն է զուգահեռության համար »
- Ուսուցողական
Այս ձեռնարկը նախատեսված է սկսնակների համար, որոնք փնտրում են ռուսերեն լեզվով պարզ ձեռնարկ, տեղադրման համար Անգլերեն տարբերակ SQL Server 2012, որը կօգտագործվի SharePoint 2013-ի համար:
Այս հոդվածը մասնագետների համար չէ:
Բոլոր աշխատանքները բաժանված են 3 փուլով.
- Տեղադրեք SQL Server 2012
- Պարապելի սերվերի կազմաձեւման պարամետրերի առավելագույն աստիճանի կարգավորում
- Right իշտ կարգավորում ՀաշիվՆախագծված է SharePoint 2013-ը տեղադրելու համար
Ուշադրություն. Կտրված շատ նկարների տակ:
Տեղադրեք SQL Server 2012
1. Տեղադրելուց առաջ համոզվեք, որ կոշտ սկավառակի վրա կա բավարար ազատ տարածք (իմ դեպքում այն \u200b\u200bտեւեց 2,7 ԳԲ):Բաշխումը սկսելուց հետո ընտրեք Նյութը » Տեղադրում«Ձախ մենյուում, ապա« Կտտացրեք «Նյութը» New SQL Server Stand-Money կամ ավելացրեք հատկություններ գոյություն ունեցող տեղադրման համար":
2. Սկսեք տեղադրման հրաշագործը: Դա ստուգելու է: Կարող եք սեղմել «Show ուցադրել մանրամասները» կոճակը եւ կտեսնեք մանրամասն զեկույց. 
3. Մանրամասն զեկույց: Սեղմեք «OK» կոճակը. 
4. Մուտքագրեք ապրանքի ստեղնը եւ սեղմեք «Հաջորդ» կոճակը. 
5. Համաձայնեք լիցենզիայի պայմանագրի պայմանների հետ:
Դա անելու համար տվեք տիզ » Ես ընդունում եմ լիցենզիայի պայմանները
6. Կարգավորվող դերակատարման փուլում ընտրեք առաջին կետը » SQL սերվերի հատկությունների տեղադրում". Սեղմեք« Հաջորդ »կոճակը. 
7. Քայլ «Խաղարկային ընտրություն» Տվյալների բազաների շարժիչների ծառայություններ", "Կառավարման գործիքներ - հիմնական«Եվ» Կառավարման գործիքներ - ամբողջական«Այնուհետեւ սեղմեք« Հաջորդ »կոճակը. 
8. Այնուհետեւ տեղադրիչը կկատարի մեկ այլ ստուգում: Կարող եք սեղմել «Show ուցադրել մանրամասները» կոճակը եւ կտեսնեք մանրամասն զեկույց. 
9. Մանրամասն զեկույց: (Այս փուլում ես սխալ եմ ունեցել «Microsoft. NET Framework 3.5-ը տեղադրված է ...» Կանոն. Այս մասին ստորեւ): Սեղմեք «Հաջորդ» կոճակը. 
10. «ԱՍՏՎԱԾ ԿԱՌԱՎԱՐՄԱՆ» ՔԱՅԼՈՒՄ, ՊԵՏՔ Է ԿԱԶՄԱԿԵՐՊԻ SQL SERVER SERVICE ծառայության օրինակ:
Կրկնում եմ, որ այս հոդվածը նախատեսված է սկսնակների համար: Հետեւաբար, մենք ենթադրում ենք, որ SQL սերվերը չի տեղադրվել ձեր սերվերի վրա, ինչը նշանակում է, որ դուք կթողնեք բոլոր լռելյայն պարամետրերը: Սեղմեք «Հաջորդ» կոճակը. 
11. Այս քայլում տեղադրման հրաշագործը ցուցադրում է սկավառակի տարածության պահանջները: Սեղմեք «Հաջորդ» կոճակը. 
12. Սերվերի կազմաձեւման քայլում դուք պետք է նշեք դոմեյնների հաշիվ ծառայության համար » SQL Server տվյալների շտեմարան«« Հաշվի անունը »եւ« գաղտնաբառ »դաշտերը լրացնելուց հետո սեղմեք« Հաջորդ »կոճակը. 
13. «Տվյալների բազայի շարժիչի կազմաձեւում» քայլում բավական է ներկայիս օգտագործողը ավելացնել SQL սերվերի ադմինիստրատորներին: Դա անելու համար կտտացրեք «Ավելացնել ներկայիս օգտագործողի» կոճակը, ապա կտտացրեք «Հաջորդ» կոճակը. 
14. Հաջորդ քայլում սեղմեք «Հաջորդ» կոճակը. 
15. Հաջորդը, տեղադրման հրաշագործը կրկին կատարում է ստուգումը եւ ցուցադրում դրա արդյունքները: Սեղմեք «Հաջորդ» կոճակը. 
16. «Պատրաստ է տեղադրելու» քայլը, հրաշագործը կցուցադրի ամփոփ տեղեկատվություն: Այստեղ դուք պետք է սեղմեք «Տեղադրեք» կոճակը. 
17. Տեղադրման ավարտից հետո ցուցադրվում են տեղեկատվություն առաջացած գործողությունների վերաբերյալ: 
18. Այս փուլում ներգրավված է համակարգիչը վերագործարկելու համար: Որոշ դեպքերում (օրինակ, Microsoft- ի տեղադրումիս. NET Framework 3.5), տեղադրման հրաշագործը ինքնին կցուցադրի պատուհան, համակարգիչը վերագործարկելու առաջարկով: Մի հրաժարվեք:
Պարապելի սերվերի կազմաձեւման պարամետրերի առավելագույն աստիճանի կարգավորում
Լռելյայն, «զուգահեռության առավելագույն աստիճանի» պարամետրը 0 է:SharePoint 2013-ը պահանջում է, որ այս պարամետրը հավասար լինի 1-ի:
Դա հեշտ է շտկել:
1. Գործարկել Microsoft SQL սերվերի կառավարման ստուդիա (Սկիզբ - Բոլոր ծրագրերը - Microsoft SQL Server 2012 - SQL Server Management Studio):
2. Միացման էկրանին սերվերին կտտացրեք «Միացեք» կոճակը:
3. Աջ սեղմեք ձեր սերվերին պատուհանում » Օբյեկտի Explorer.«Եւ ընտրեք» Հատկություններ:":
4. Սերվերի հատկությունների պատուհանում, որը բացվում է ձախ ցանկում, ընտրեք էջը » Առաջադեմ«Եվ կատարեք էկրանի ներքեւի հատկությունների ցուցակը: Սահմանեք պարամետրային արժեքը Զուգահեռության առավելագույն աստիճան«in 1
եւ կտտացրեք «OK». 
5. Մի փակեք SQL սերվերի կառավարման ստուդիան, այն օգտակար կլինի:
SharePoint 2013-ի կարգաբերման համար հաշվի իրավունքը սահմանելը
Հաշիվը, որի անունից SharePoint 2013-ի տեղադրումը պետք է ավելացնի իրավունքներ SQL Server- ում:Այս հաշիվը առաջարկվում է տալ հետեւյալ դերերը.
- dBCREATOR
- securityAdmin.
- Հանրակացարան
2. «Մուտքի անուն» դաշտում մուտքագրեք Տիրույթի անունը Հաշիվը, որից նախատեսում եք տեղադրել եւ կարգավորել SharePoint 2013-ը:
3. Ձախ ընտրացանկում ընտրեք էջը » Սերվերի դերեր:«Եվ ստուգեք« DBCreator »- ի եւ« SecurityAdmin »դերը, ինչպես նաեւ համոզվեք, որ« հանրային »դերն արդեն նշվում է: Այնուհետեւ կտտացրեք« OK ». 
Այժմ SQL սերվերը պատրաստ է SharePoint 2013-ի տեղադրման համար:
Microsoft- ի տեղադրումը. NET Framework 3.5 in MS Windows Server 2012 R2 Standart
Կետի 9-րդ քայլում » Տեղադրեք SQL Server 2012«Ես սխալ ունեի. Այն տեղադրված չէր. NET Framework 3.5.Այս խնդիրը լուծելու համար պետք է իրականացվեն հետեւյալ քայլերը.
1. Դուք պետք է բացեք վահանակը » Սերվերի կառավարիչ:".
2. Ձախ ընտրացանկում ընտրեք «Dashboard» կետը:
3. Պատուհանի կենտրոնում կտտացրեք «Ավելացնել դերերն ու առանձնահատկությունները» կետը:
4. Վարպետում, որը բացվում է, բաց թողեք «Նախքան սկսելը»:
5. «Տեղադրման տեսակը» քայլում, ընտրեք նյութը » Դերի վրա հիմնված կամ գեղարվեստական \u200b\u200bտեղադրում". Սեղմեք« Հաջորդ »կոճակը:
6. Հաջորդ քայլում ամեն ինչ լռելյայն թողեք եւ սեղմեք «Հաջորդ» կոճակը:
7. Բաց թողեք «սերվերի դերերը» քայլը `կտտացնելով« Հաջորդ »կոճակը:
8. «Հատկություններ», մենք նշում ենք «. NET Framework 3.5 առանձնահատկությունները» տուփը: Սեղմեք «Հաջորդ» կոճակը:
9. Տեղադրման գործընթացը կատարելուց հետո կարող եք փակել «Ավելացնել դերերը եւ պարունակում հրաշագործ հրաշագործ» հրաշագործը:
10. Պատրաստ:
Ձեր գլխից վերեւ լավ եւ խաղաղ երկինք:
Սիրված Շնորհավոր տիեզերագնացության օր:
Զուգահեռության առավելագույն աստիճան (DOP) - SQL սերվերի կազմաձեւման լրացուցիչ տարբերակ, որը կապված է բազմաթիվ հարցերի հետ, որոնք նվիրված են բազմաթիվ հրապարակումների: Իր բլոգի այս հոդվածում հեղինակը հույս ունի մի փոքր պարզաբանել, որ այս տարբերակը եւ ինչպես օգտագործել այն:
Նախ, հեղինակը կցանկանա ցրել ցանկացած կասկածի մասին, որ նշված տարբերակը սահմանում է, թե քանի պրոցեսորներ կարող են օգտագործել SQL սերվեր, երբ սպասարկվում է բազմաթիվ կապեր (կամ օգտագործողներ): Եթե \u200b\u200bSQL սերվերը մուտք ունի չորս ոչ ակտիվ պրոցեսոր, եւ այն կազմաձեւված է օգտագործել բոլոր չորս պրոցեսորները, այն կօգտագործի բոլոր չորս պրոցեսորները, անկախ զուգահեռության առավելագույն աստիճանից:
Այսպիսով, ինչ է տալիս այս տարբերակը: Այս տարբերակը սահմանում է վերամշակողների առավելագույն քանակը, որը SQL Server- ը կարող է օգտագործել մեկ խնդրանքի համար: Եթե \u200b\u200bSQL սերվերի խնդրանքը պետք է վերադառնա Մեծ ծավալը Տվյալներ (շատ գրառումներ), երբեմն իմաստ ունի զուգահեռ լինել, մի քանի փոքր խնդրանքներ ներխուժել, որոնցից յուրաքանչյուրը կվերադարձնի իրերի ենթաբազմությունը: Այսպիսով, SQL Server- ը կարող է օգտագործել բազմաթիվ պրոցեսորներ, եւ, հետեւաբար, բազմակողմանի համակարգերի վրա, ամբողջ հարցման մեծ թվով գրառումներ կարող են ավելի արագ վերադարձվել, քան մեկ պրոցեսորի համակարգում:
Կան բազմաթիվ չափանիշներ, որոնք պետք է հաշվի առնել նախքան SQL Server Triggers «Intra Query Paralelism- ը» (մի քանի հոսքերի համար դիմում է), եւ այստեղ մանրամասն չկա: Դուք կարող եք գտնել դրանք BOL- ում, որոնելով «զուգահեռության աստիճանը» արտահայտությունը: Այն ասում է, որ զուգահեռացման որոշումը հիմնված է հիշողության պրոցեսորի մատչելիության վրա եւ, հատկապես, հենց իրենք վերամշակողների առկայության վրա:
Այսպիսով, ինչու պետք է մտածենք այս տարբերակի օգտագործման միջոցով, քանի որ, թողնելով այն լռելյայն արժեքով (SQL Server- ն ինքն է որոշում կայացնել), երբեմն կարող եք անցկացնել անցանկալի էֆեկտներ: Այս հետեւանքները նման են.
Զուգահեռ հայցերը դանդաղ են:
Հարցումների կատարման ժամանակը կարող է դառնալ ոչ որոշիչ, եւ այն կարող է անկանոն օգտագործողներ: Կատարման ժամանակը կարող է փոխվել, քանի որ.
Հայցը կարող է երբեմն զուգահեռ, եւ երբեմն ոչ:
Հայցը կարող է արգելափակվել զուգահեռ խնդրանքով, եթե դրա առաջ պրոցեսորները ծանրաբեռնված են:
Նախքան մենք շարունակենք, հեղինակը կցանկանա նկատել, որ առանձնահատուկ կարիք չկա զուգահեռության ներքին կազմակերպման մեջ սուզվելու: Եթե \u200b\u200bդուք հետաքրքրված եք դրանով, ապա գծի մեջ կարող եք կարդալ «Զուգահեռ հարցման վերամշակում» հոդվածը, որում այս տեղեկատվությունը ավելի մանրամասն է: Հեղինակը կարծում է, որ կան ընդամենը երկու կարեւոր բան, որ դուք պետք է իմանաք զուգահեռության ներքին կազմակերպման մասին.
Զուգահեռ հայցերը կարող են ավելի շատ թելեր առաջացնել, քան նշված են «զուգահեռության առավելագույն աստիճանի» տարբերակի մեջ: DOP 4-ը կարող է առաջացնել ավելի քան տասներկու թել, չորսը `պահանջի եւ լրացուցիչ հոսքերի համար, որոնք օգտագործվում են տեսակավորման, հոսքերի, միավորների եւ հավաքների համար եւ այլն:
Հարցումների զուգահեռությունը կարող է ցուցաբերել տարբեր սարդեր, սպասելու համար CXPacket կամ 0x0200: Սա կարող է օգտագործվել այն սարդերը գտնելու համար, որոնք սպասման փուլում են, երբ զուգահեռ գործողություններ են գործում, եւ Sysprocesses- ում Waittype: CXPacket: Այս առաջադրանքը հեշտացնելու համար հեղինակը առաջարկում է օգտագործել պահված ընթացակարգը իր բլոգում. Track_waitstats.
Եվ այսպես, «Հայցը կարող է ավելի դանդաղ իրականացվել, երբ զուգահեռ լինեն»:
Եթե \u200b\u200bհամակարգը շատ թույլ ունի Թողունակություն Սկավառակի ենթահամակարգերը, ապա հարցումը վերլուծելիս դրա տարրալուծումը կարող է իրականացվել ավելի երկար, քան առանց զուգահեռության:
Տվյալների հնարավոր բլոկներ կամ արգելափակում տվյալների տեւողություններ `զուգահեռ օգտագործված մեկ ուրիշի կողմից ստեղծված պրոցեսորի համար եւ հետագայում գործարկվում է հետագա գործընթացը եւ այլն:
Եթե \u200b\u200bնախատրամադրման համար որեւէ ցուցանիշ չկա, ինչը հանգեցնում է սեղանի սկանավորմանը: Հայցի շրջանակներում զուգահեռ գործողությունը կարող է թաքցնել այն փաստը, որ հայցադիմումը կավարտվեր շատ ավելի արագ կատարման պլանով եւ ճիշտ ցուցանիշով:
Այս ամենից հետեւում է առաջարկությանը `առանց զուգահեռության կատարումը ստուգելու հարցման կատարումը (DOP \u003d 1), դա կօգնի բացահայտել հնարավոր խնդիրները:
Զուգահեռության վերը նշված հետեւանքները, իրենք, ձեզ պետք է դուրս գան, որ հարցումների զուգահեռական մեխանիզմը հարմար չէ Օլտրի դիմումներում օգտագործելու համար: Սրանք այնպիսի ծրագրեր են, որոնց համար կատարման ժամանակի փոփոխությունը կարող է նյարդայնացնել օգտագործողներին եւ որի համար սերվերը միաժամանակ սպասարկող շատ օգտվողներ ընտրելու համար անհրաժեշտ է ընտրել զուգահեռ կատարման պլանը:
Հետեւաբար, եթե դուք պատրաստվում եք զուգահեռականություն օգտագործել, ապա ամենայն հավանականությամբ, անհրաժեշտ կլինի տվյալների արդյունահանման առաջադրանքների (տվյալների պահեստ), որոշումների կայացման կամ հաշվետվության համակարգերի աջակցություն, բայց դրանք շատ են, բայց դրանք դժվար են եւ իրականացվում են Հզոր սերվեր `գործառնական հիշողության մեծ ծավալի միջոցով:
Եթե \u200b\u200bորոշեք օգտագործել զուգահեռականություն, ինչ արժեք պետք է տեղադրվի DOP- ի համար: Այս մեխանիզմի համար լավ պրակտիկան այն է, որ եթե ունեք 8 պրոցեսոր, ապա տեղադրեք DOP \u003d 4, եւ դա մեծ հավանականությամբ հավանական է լինելու օպտիմալ տեղադրումը: Այնուամենայնիվ, երաշխիք չկա, որ այն կաշխատի: Միակ ճանապարհը `համոզվելու համար, որ դա DOP- ի համար տարբեր արժեքներ փորձարկելը է: Դրանից բացի, հեղինակը ցանկանում էր առաջարկել իր, ելնելով Խորհրդի էմպիրիկ դիտարկումների վրա, երբեք մի տեղադրել այս քանակը պահեստավորված պրոցեսորների քանակի կեսից ավելին: Եթե \u200b\u200bհեղինակը վեցից պակաս պրոցեսորներ է ունեցել, ապա դա դոպ կներկայացնի 1-ում, ինչը պարզապես արգելում է զուգահեռացումը: Նա կարող էր բացառություն ունենալ, եթե ուներ տվյալների բազա, որն աջակցում է միայն մեկ օգտագործողի (տվյալների արդյունահանման որոշ տեխնոլոգիաների կամ հաշվետվության առաջադրանքների) գործընթացին, բացառության համար հնարավոր կլինի տեղադրել DOP- ը (լռելյայն արժեք) Թույլ է տալիս SQL Server- ին որոշում կայացնել հարցումը զուգահեռելու անհրաժեշտության մասին:
Հոդվածը լրացնելուց առաջ հեղինակը ցանկանում էր նախազգուշացնել ձեզ այն փաստի մասին, որ ցուցանիշների զուգահեռ ստեղծումը կախված է դոպի համար: Սա նշանակում է, որ դուք կարող եք դա փոխել, այս գործողության կատարողականի բարձրացման համար ցուցանիշներ ստեղծելու կամ վերստեղծելու պահին, եւ, իհարկե, կարող եք օգտագործել MaxDop ակնարկների հարցումը, որը թույլ է տալիս անտեսել սահմանված արժեքը Կազմաձեւում եւ կարող է օգտագործվել նվազագույն ծանրաբեռնված ժամացույցում:
Վերջապես, ձեր խնդրանքը կարող է դանդաղեցնել, երբ սխալ է առաջադրվում, սխալների պատճառով զուգահեռ, այնպես որ համոզվեք, որ վերջին սպասարկման փաթեթը տեղադրված է ձեր սերվերի վրա:
| Ստեղծեք Proc Track_waitstats (@num_samples Int \u003d 10 , @ Shondnum int \u003d 1 @ Ձգում Type nvarchar ( 10 ) \u003d «Րոպե») AS - T. Davidson - Այս պահված ընթացակարգը տրամադրվում է \u003d ինչպես \u003d երաշխիքներ, - եւ իրավունք չունի: - ներառված սցենարի նմուշների օգտագործումը ենթակա է պայմանների - նշված է http://www.microsoft.com/info/cpyright.htm - @num_samples- ը սպասելու պահոցների քանակն է, - Լռելյայն 10 անգամ է: Լռելյայն ձգձգման ընդմիջումը 1 րոպե է - հետաձգումը հետաձգման ընդմիջում է: Հետաձգումը սահմանում է, թե արդյոք: - հետաձգման ընդմիջումը րոպեներով կամ վայրկյան է - Ստեղծեք սպասքի սեղան, եթե այն գոյություն չունի, այլապես կտրեք Եթե \u200b\u200bոչ, եթե չլինի ոչ 1 Sysobjects- ից, որտեղ name \u003d «սպասողներ») Ստեղծեք սեղանի սպասասրահ (Varchar ( 80 ), Հարցում է համարում ( 20 ,1 ), Թվային ( 20 ,1 ), Թվային ( 20 ,1 ), Այժմ DateTime Default Getdate ()) այլ հյուսվածքների սպասասրահ DBCC SQLPERF (սպասականսեր, պարզ) - Մաքրել սպասարկումը @ i in intr, @ ձգում է varchar ( 8 ), @ Dt varchar ( 3 ), @ Այժմ DateTime, @ TotalWait թվային ( 20 ,1 ), @ Endtime DateTime, @ Begintime DateTime, @ HR INT, @ Min Int, @ SEC INT Ընտրել @i \u003d 1 Ընտրեք @DT \u003d Case Lower (@DelayType) Երբ «րոպեներ», երբ «րոպե», ապա «Մին», երբ «մմ» -ը «մ» է Երբ «մ» -ը «մ» է, երբ «վայրկյան», երբ «երկրորդը» «երկրորդը», երբ «վրկ», երբ «SS» - ը «s» - ը Հետաձգման ավարտը, եթե @ dt- ը չունի («S» - ում, «մ») Սկսեք տպել «Խնդրում ենք մատակարարել հետաձգման տեսակը e.g. Վայրկյաններ կամ րոպեներ» Վերադարձի ավարտը, եթե @ dt \u003d "s" սկսեք ընտրել @SEC \u003d @ հետաձգում% 60 Ընտրեք @min \u003d Cast ((@Delaynum / 60 ) Որպես int) ընտրեք @hr \u003d Cast ((@min / 60 ) Որպես int) ընտրեք @min \u003d @ min% 60 Վերջ, եթե @ dt \u003d "m" սկսեք ընտրել @SEC \u003d 0 Ընտրեք @min \u003d @ հետաձգում% 60 Ընտրեք @hr \u003d Cast ((@Delaynum / 60 ) Որպես INT) ENTELELECT @Delay \u003d Right («0» + փոխարկիչ (Varchar ( 2 ), @ HR), 2 2 ), @ min), 2 ) + ».« + + + Ճիշտ («0» + փոխարկիչ (Varchar ( 2 ), @ SEC), 2 ) եթե @hr\u003e 23 կամ @min\u003e 59 կամ @SEC\u003e 59 Սկսեք ընտրեք: «Հ., Մմ. SS հետաձգման ժամանակը չի կարող\u003e 23:59:59»: Ընտրեք «Հետաձգման ընդմիջում եւ տեսակը.« Փոխակերպում (Varchar ( 10 ), @ Shondnum) »», «+ @Delaytype +« Փոխադրումներ դեպի »+ @Delay վերադարձի ավարտը (@i)<= @num_samples) begin insert into waitstats (, requests, ,) exec ("dbcc sqlperf(waitstats)" ) select @i = @i + 1 Waitge @ Delay End --- Ստեղծել սպասարկման մասին զեկույցը կատարեք Get_waitstats- ը --//--//--//--//--//--//--//--//--//-//--//--//--//--//--//--//--//--/ Ստեղծեք proc get_waitstats as - Այս պահված ընթացակարգը տրամադրվում է \u003d is \u003d ոչ երաշխիքներ, եւ - Ոչ մի իրավունք չունի: - ներառված սցենարի նմուշների օգտագործումը ենթակա է նշված պայմանների - http://www.microsoft.com/info/cpyright.htm. -- - Այս Prog- ը կստեղծի սպասումների զեկույցների ցուցակման սպասման տեսակների կողմից - տոկոս - Կարող է գործարկել, երբ Track_waitstats- ը կատարում է Տեղադրեք NOCOUNT- ը հայտարարագրային @NOW DATETIME, @ TACKWAIT NUMERIC ( 20 ,1 ), @ Endtime DateTime, @ Begintime DateTime, @ HR INT, @ SEC INT Ընտրել @ հիմա \u003d Max (հիմա), @ begtime \u003d Max (հիմա), որտեղից \u003d " Ընդհանուր » --- հափշտակել սպասումը, քունը եւ ռեսուրս_queue- ն ընդհանուր առմամբ Ընտրեք @totalwait \u003d գումար () + 1 Սպասքի պահեստներից, որտեղ ոչ («LELFFOR», «Resource_queue», «Ընդհանուր», «*** Ընդհանուր ***») եւ հիմա \u003d @now - Տեղադրեք ճշգրտված ընդհանուր տոտալները, դասակարգեք տոկոսադրույքով Delete նջել սպասասրահները, որտեղ \u003d "*** Ընդհանուր ***" Եվ հիմա \u003d @now ներդիրը սպասել «*** Ընդհանուր ***», 0 , @ TotalQait, @ TotalQait, @ Այժմ ընտրեք, տոկոսային \u003d դերասան ( 100 * / @ Totalwait որպես թվային ( 20 ,1 )) սպասվող կետերից, որտեղ ոչ («սպասիր», «Քուն», «Resource_queue», «Ընդհանուր») եւ հիմա \u003d @now կարգը ըստ տոկոսային DESC- ի |
Այս գրառման մեջ մենք կխոսենք միայն MS SQL սերվերի մասին: Եթե \u200b\u200bդուք պատրաստվում եք «փորձել երջանկություն», Oracle- ի 1C օգտագործելու համար, DB2, Postrgre ձեզ համար այս տեղեկատվությունը անօգուտ կլինի: Բայց դուք պետք է հասկանաք, որ 1C- ում հիմնականում մասնագետներ կան MS SQL սերվերի վրա: DB2- ի փորձագետները երեւում են IBM- ի ջանքերը: Կարող եք երկար ժամանակ վիճել լավ կամ վատ, այս DBMS- ը կարեւոր է, մեկը, ամենաառաջնային 1C- ն աշխատում է MS SQL սերվերի հետ: Դատելով «Front» - ի վերջին հաղորդագրություններից քիչ թե շատ արժանապատիվ աշխատանք DB2- ի հետ: Չնայած ես անձամբ ունեի 1C- ի փորձը DB2- ի հետ ավելի շատ աշխատելու համար `8.1 տարբերակով. Ամեն ինչ ինչ-որ կերպ չէ: Ամեն դեպքում, մեկ այլ DBMS- ի ընտրությունը պետք է հստակ պատճառաբանվի, կամ այն \u200b\u200bտարբերակները, որոնք MS SQL- ում չեն (կլաստեր, բեռնվածքի հավասարակշռող, ցանցով եւ այլն) կամ պլատֆորմով (բոլորը Linux- ով) ,
Այսպիսով, այն, ինչ դուք պետք է անեք MS SQL Server- ի հետ.
1) Կազմաձեւեք հիշողության նվազագույն եւ առավելագույն քանակը: Նվազագույնը համակարգի հիշողության կեսն է: Առավելագույն - հիշողության համակարգ առանց 2 ԳԲ: Դա արվում է կառավարման ստուդիայի միջոցով `սերվերի հատկություններում.
2) Եթե պրոցեսորի ներդիրում առաջնահերթությունը տեղադրված չէ. Պետք է տեղադրել
3) 1-ին զուգահեռության առավելագույն աստիճան:
4) Ներառեք SQL Server Agent, հարմարեցրեք տվյալների բազայի փոստը. Այնտեղ դժվար բան չկա, ես մանրամասն նկարագրելու եմ:
5) Անհատականացրեք ծառայության ծրագրերը.
Ընդհանուր:
ա) Թարմացրեք վիճակագրությունը - յուրաքանչյուր 2 ժամ
բ) DBCC Freproccach - յուրաքանչյուր 2 ժամ
Յուրաքանչյուր տվյալների բազայի համար.
ա) ամբողջական կրկնօրինակում
բ) տարբերության կրկնօրինակում
գ) ինդեքսների դեֆրոգիտացիա - ամեն օր
դ) Perestroika ինդեքսներ - գիշերը հանգստյան օրերին
ե) բազայի ամբողջականությունը ստուգելը `շաբաթը մեկ անգամ գիշերը գիշերը
6) Ես խորհուրդ եմ տալիս տեղադրել վերականգնման մոդելը յուրաքանչյուր տվյալների բազայի համար (հատկություններում), ինչպես պարզ: Եթե \u200b\u200bհիմքի վրա չունեք 24/7 համակարգ եւ 1000-ից պակաս օգտվողներ, չկա մեղավոր հանդուրժող կլաստեր, եւ դուք չեք ստորագրել SLA- ն, որում մենք ենթադրում ենք ցանկացած սարքավորումների ելքի դեպքում, տվյալները վերականգնելու համար Մի վայրկյան (եւ ոչ թե վերջին կրկնօրինակումից հետո) Այս առաջարկությունը ողջամիտ կլինի: Հակառակ դեպքում, դուք շատ շուտով երկար ժամանակ եւ ցնցում եք արտացոլում, թե որտեղ է ծնվել տագնապի մատյան
7) Հեռացրեք TempDB տվյալների բազան սովորական տվյալների բազաներից մեկ այլ սկավառակ, նույնիսկ եթե դուք պետք է վերափոխեք Raid զանգվածը եւ նվազեցրեք դրա կատարումը: Հակառակ դեպքում, 1 օգտագործողը կկարողանա կաթվածահարել բոլորի աշխատանքը: Եթե \u200b\u200bունեք կոշտ սկավառակի փոխարեն ապարատային արագացուցիչ, ապա, իհարկե, դուք չեք կարող առանձնացնել եւ տեղադրել տեմպը դրա վրա, բայց դա միայն եթե կա
8) Սահմանեք մոնիտորինգի ցանկացած միջոց `օրինակ, ես սիրում եմ ուշադրության կենտրոնում http://www.quest.com/spotlight-s -sql-server-enterprise/
9) Ստուգեք ինքներդ ձեզ Microsoft- ի լավագույն պրակտիկայի վերլուծիչով - http://www.microsoft.com/download/endetail.aspx?id\u003d15289 - հիանալի գործիք, որը օգնում է ոչ միայն պարամետրերով, այլեւ բազմաթիվ խնդիրներ լուծելու:
Հիմա հակիրճ այն բանի համար, ինչ մենք արեցինք այս ամենը.
1) հիշողություն: Նվազագույն արժեքը պարզապես կփրկի ձեզ «սոսնձերից», երբ SQL սերվերը որոշ այլ հայտնի պատճառներով չի օգտագործում դրան: Պետք է ուտել բոլորը: Առավելագույն արժեքը ձեզ կփրկի փոխանակումից, եթե SQL սերվերի հիշողության օպտիմիզատորի նույն օպտիմիզատորը որոշի, որ այն դեռ կվնասի նրան ...
3) Շատ կարեւոր կետ. IMMO- ն պետք է դառնա 1 գործարքային համակարգերում 1-ին: Նախ եւ առաջ սա խանգարում է տարբեր գործընթացների կողպեքների մի մասը, որը փորձում է համապատասխանաբար կատարել 1 հարցում, այն պաշտպանում է մեզ որոշ «տարօրինակ» սխալներից: Երկրորդ ... 1 «Սպանելու» խնդրանքը կկարողանա հանել բոլոր սերվերի ռեսուրսները, ինչը մի փոքր ճիշտ չէ համակարգի մնացած օգտվողների հետ կապված:
5) Դատավարական քեշի վիճակագրության եւ մաքրման մասին. Սա «լսողության վրա է», եւ այստեղ մենք հաճախ մոռանում ենք Ռեյնդեկացիայի մասին: Մինչդեռ, այս ընթացակարգը բավականին կարեւոր է, հատկապես բազայի ծավալի աճով, դրա կարեւորությունը մեծանում է: Երբեմն կատարման մինչեւ 60% -ը կորչում է ինդեքսի մասնատման վրա:
7) Եթե կա ապարատային արագացուցիչ կամ պարզապես 2 սկավառակ, տարբեր մուտքի արագությամբ, ես կվերանայեի տվյալների շտեմարաններում ֆայլերի խմբերը կարեւորելու եւ անհատական \u200b\u200bսեղանների տարբեր ժամացույցների բաժանելու մասին: Ի վերջո, դուք համաձայն եք, որ «ապրանքներ պահեստներում ապրանքներ» եւ «Լրացուցիչ տեղեկությունների պահպանում» գրքույկը, որի պահպանման պահանջի օբյեկտի օբյեկտի համար արմատավորված է: Անհրաժեշտ չէ տվյալների բազայում արագ զանգվածի վրա պահել բոլոր ֆայլերը եւ նկարները. Դուք կարող եք ընտրել այն առանձին, ոչ այնքան արագ, բայց որտեղ շատ տեղեր կան (եւ չվախենան ներբեռնելու մի շարք ֆայլերի մի շարք) ճանապարհ):
