SQL Server Ակտիվության մոնիթոր. Տվյալների բազաների համար ամբողջական ուղեցույց [2026]

1: ներածություն

1.1 Ինչ է SQL Server Ակտիվության մոնիտոր՞

SQL Server Ակտիվության մոնիտորը ներկառուցված ախտորոշիչ գործիք է SQL Server Կառավարման ստուդիա, որը ցուցադրում է տեղեկատվություն SQL Server գործընթացները և դրանց ազդեցությունը սերվերի աշխատանքի վրա: Այն թույլ է տալիս հետևել SQL Server գործընթացներ, վերահսկել ռեսուրսների սպասումները, վերլուծել թանկարժեք հարցումները և դիտարկել մուտքի/ելքի օրինաչափությունները՝ այս ամենը մեկ ինտերֆեյսից։

1.2 Ինչու՞ օգտագործել SQL Server Ակտիվության մոնիտոր՞

Ակտիվության մոնիտորը ծառայում է որպես ձեր պաշտպանության առաջին գիծ՝ կատարողականի հետ կապված խնդիրների լուծման ժամանակ։ Այն անմիջապես տեսանելիություն է տալիս ձեր համակարգչում կատարվողի վերաբերյալ։ SQL Server օրինակ՝ առանց բարդ T-SQL հարցումների կամ երրորդ կողմի գործիքների կարիք ունենալու։

Այս գործիքը գերազանց է օգնում ձեզ արագորեն հայտնաբերել այնպիսի տարածված խնդիրներ, ինչպիսիք են սեսիաների արգելափակումը, պրոցեսորի վրա ծանրաբեռնված հարցումները, հարցումների չափազանց մեծ կատարումը և մուտքի/ելքի խցանումները: Երբ օգտատերերը հայտնում են, որ որևէ ծրագիր դանդաղ է կամ չի արձագանքում, Activity Monitor-ը օգնում է ձեզ որոշել, թե արդյոք տվյալների բազայի սերվերն է մեղավորը:

Տվյալների բազայի ադմինիստրատորների համար, ովքեր չեն աշխատում SQL Server Ամեն օր Activity Monitor-ը հասանելի մուտքի կետ է սերվերի գործունեությունը հասկանալու համար: Նույնիսկ փորձառու տվյալների բազային կառավարիչներն այն օգտագործում են որպես իրենց մեկնարկային կետ՝ կատարողականության հետազոտությունների համար:

1.3 Ակտիվության մոնիթորինգ ընդդեմ այլ մոնիթորինգի գործիքների

Թեև Activity Monitor-ը արժեքավոր է, կարևոր է հասկանալ, թե ինչպես է այն համեմատվում այլ մոնիթորինգի տարբերակների հետ։

Ակտիվության մոնիտոր ընդդեմ sp_WhoIsActive-ի՝ Activity Monitor-ը տրամադրում է գրաֆիկական ինտերֆեյս՝ բազմաթիվ վահանակներով, մինչդեռ sp_WhoIsActive-ը համապարփակ պահեստավորված պրոցեդուրա է, որն առաջարկում է ավելի մանրամասն տեղեկատվություն մեկ արդյունքների հավաքածուում: sp_WhoIsActive-ը ցույց է տալիս սպասման որոշակի տեսակներ, որոնք Activity Monitor-ը խմբավորում է միասին, և տրամադրում է ավելի մանրամասն արգելափակման տեղեկատվություն:

Ակտիվության մոնիտոր ընդդեմ sp_who2-ի՝ Ավանդական sp_who2 հրամանը ցույց է տալիս սեսիայի հիմնական տեղեկատվությունը, սակայն Activity Monitor-ը ավելի հեռուն է գնում՝ ցուցադրելով սպասման վիճակագրությունը, թանկարժեք հարցումները և I/O չափանիշները կազմակերպված, տեսողական ձևաչափով։

Ակտիվության մոնիթորինգ ընդդեմ երրորդ կողմի գործիքների. SolarWinds Database Performance Analyzer-ի նման առևտրային մոնիթորինգի լուծումները առաջարկում են պատմական հետևում, ահազանգեր և առաջադեմ վերլուծություններ, որոնք բացակայում են Activity Monitor-ում: Այնուամենայնիվ, Activity Monitor-ը չի պահանջում լրացուցիչ ծախսեր կամ տեղադրում:

1.4 Հիմնական առավելություններ տվյալների բազայի ադմինիստրատորների համար

Activity Monitor-ը առաջարկում է մի քանի առավելություններ, որոնք այն դարձնում են կարևոր DBA գործիք.

• Զրոյական արժեք. Որպես ներկառուցված SQL Server Management Studio-ի առանձնահատկության շնորհիվ լիցենզավորման վճար կամ տեղակայման ջանքեր չեն պահանջվում։
• Իրական ժամանակի մոնիտորինգ. Դիտեք սերվերի ընթացիկ ակտիվությունը՝ կարգավորելի թարմացման ընդմիջումներով՝ 1 վայրկյանից մինչև 1 ժամ։
• Ինտեգրված գործողություններ՝ Սեսիաները փակելու, հարցման մանրամասները դիտելու կամ գործարկելու համար աջ սեղմեք գործընթացների վրա SQL Server Պրոֆիլերի հետքեր՝ բոլորը գործիքի ներսից։
• Բազմաթիվ հեռանկարներ. Դիտեք սերվերի առողջությունը տարբեր անկյուններից՝ հինգ մասնագիտացված վահանակների միջոցով, որոնցից յուրաքանչյուրը կենտրոնանում է կատարողականության որոշակի ասպեկտների վրա։
• Արագ անսարքությունների վերացում. Հայտնաբերեք ամենատարածված կատարողականի խնդիրները րոպեների ընթացքում՝ արագացնելով դրանց լուծման միջին ժամանակը։
• Մուտքի ցածր խոչընդոտ. Գործիքն արդյունավետ օգտագործել սկսելու համար առաջադեմ գիտելիքներ անհրաժեշտ չեն, թեև ավելի խորը SQL Server Մասնագիտությունը օգնում է մեկնաբանությանը։

2. Սկսեք Activity Monitor-ի հետ

Նախքան Activity Monitor-ը արդյունավետորեն օգտագործելը, դուք պետք է հասկանաք գործիքը գործարկելու նախապայմանները, պահանջվող թույլտվությունները և տարբեր մեթոդները:

2.1 Նախապայմաններ և համակարգային պահանջներ

Է օգտագործել SQL Server Ակտիվության մոնիտոր, ձեզ անհրաժեշտ է SQL Server Management Studio (SSMS)-ը տեղադրվել է ձեր տեղական համակարգչի կամ jump սերվերի վրա: Activity Monitor գործիքը զգալիորեն վերաձևավորվել է 2010 թվականին: SQL Server 2008թ., ուստի այս ուղեցույցում ներկայացված տեղեկատվությունը վերաբերում է SQL Server 2008 և ավելի ուշ տարբերակները։

Դուք պետք է ունենաք ցանցային միացում SQL Server օրինակը, որը ցանկանում եք վերահսկել: Ամպային հոսթինգով տվյալների բազաների համար, օրինակին մուտք գործելու համար սովորաբար անհրաժեշտ կլինի VPN կապ կամ պատշաճ կերպով կարգավորված firewall կանոններ:

Activity Monitor-ը աշխատում է բոլոր հրատարակությունների հետ SQL Server, ներառյալ Express, Standard և Enterprise: Գործիքն ինքնին աշխատում է ձեր հաճախորդի մեքենայի վրա SSMS-ի ներսում, ուստի սերվերի ռեսուրսների վրա ազդում են միայն դրա կողմից կատարվող մոնիթորինգի հարցումները:

2.2 Պահանջվող թույլտվություններ

Համապատասխան թույլտվությունները կարևոր են Activity Monitor-ի ճիշտ աշխատանքի համար: Առանց համապատասխան իրավունքների, դուք կարող եք տեսնել դատարկ էկրան կամ ստանալ մուտքի մերժման սխալներ:

2.2.1 Սերվերի վիճակի դիտման թույլտվություն

  Դիտել սերվերի վիճակը Թույլտվությունը Activity Monitor-ն օգտագործելու հիմնական պահանջն է: Այս սերվերի մակարդակի թույլտվությունը թույլ է տալիս տեսնել բոլոր ակտիվ գործընթացները և դրանց հետ կապված չափանիշները:

Այս թույլտվությունը տրամադրելու համար սերվերի ադմինիստրատորը կարող է կատարել հետևյալը.

GRANT VIEW SERVER STATE TO [YourLoginName];

Առանց VIEW SERVER STATE-ի, Activity Monitor-ը կարող է բացվել, բայց իր որևէ վահանակում տվյալներ չցուցադրել։

2.2.2 Տվյալների բազայի մակարդակի թույլտվություններ

Տվյալների ֆայլի մուտք/ելք վահանակում տեղեկատվությունը դիտելու համար ձեզ անհրաժեշտ են լրացուցիչ թույլտվություններ: Մասնավորապես, դուք պետք է ունենաք հետևյալ համադրություններից մեկը՝

• Ստեղծեք տվյալների շտեմարան թույլտվություն, կամ
• ՓՈՓՈԽԵԼ ՑԱՆԿԱՑԱԾ ՏՎՅԱԼՆԵՐԻ ԲԱԶԱ թույլտվություն, կամ
• ԴԻՏԵԼ ՑԱՆԿԱՑԱԾ ՍԱՀՄԱՆՈՒՄ թույլտվություն

Այս թույլտվությունները պետք է համակցվեն Դիտել սերվերի վիճակը Ակտիվության մոնիտորի լիարժեք ֆունկցիոնալության համար։

2.2.3 Թույլտվությունների խնդիրների լուծում

Եթե ​​Activity Monitor-ը բացվում է, բայց տվյալներ չի ցուցադրում, ապա ամենատարածված պատճառը թույլտվություններն են: Ստուգեք, որ ձեր մուտքի մոտ սերվերի մակարդակում տրված է VIEW SERVER STATE: Դուք կարող եք ստուգել ձեր թույլտվությունները՝ կատարելով հետևյալը.

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

Փնտրեք «VIEW SERVER STATE»-ը permission_name սյունակում: Եթե այն բացակայում է, կապվեք ձեր տվյալների բազայի ադմինիստրատորի հետ՝ այն տրամադրելու համար:

2.3 Ինչպես բացել Activity Monitor-ը SSMS-ում

SQL Server Management Studio-ն առաջարկում է Activity Monitor-ը գործարկելու չորս տարբեր մեթոդ՝ ձեզ տալով ճկունություն՝ հիմնվելով ձեր աշխատանքային հոսքի նախասիրությունների վրա։

2.3.1 Մեթոդ 1. Գործիքների վահանակից

Ակտիվության մոնիտորը բացելու ամենաարագ ճանապարհը գործիքագոտու պատկերակի օգտագործումն է։

1. Միացեք ձեր SQL Server օրինակ SQL Server Կառավարման ստուդիա.
2. Գտեք «Ակտիվության մոնիթոր» պատկերակը ստանդարտ գործիքագոտում (այն նման է կանաչ նվագարկման կոճակով սյունակային դիագրամի):
3. Սեղմեք պատկերակը՝ Activity Monitor-ը գործարկելու համար։

Այս մեթոդը ամենաարագն է, երբ դուք արդեն աշխատում եք SSMS-ում և անհրաժեշտ է արագ ստուգել սերվերի ակտիվությունը։

2.3.2 Մեթոդ 2. Օբյեկտների հետազոտիչից

Կարող եք նաև գործարկել Activity Monitor-ը անմիջապես Object Explorer-ից։

1. Object Explorer-ում գտեք SQL Server օրինակ, որը դուք ցանկանում եք վերահսկել։
2. Աջ սեղմեք օրինակի անվան վրա։
3. ընտրել Գործունեության մոնիտոր համատեքստի ընտրացանկից:

Այս մեթոդը օգտակար է մի քանի սերվերների միանալու ժամանակ, քանի որ այն ապահովում է, որ դուք վերահսկում եք ճիշտ օրինակը։

2.3.3 Մեթոդ 3. Ստեղնաշարի կարճ ստեղների օգտագործում

Ստեղնաշարի վրա կենտրոնացած օգտատերերի համար, SQL Server Management Studio-ն տրամադրում է հատուկ կարճ ճանապարհ՝

1. Համոզվեք, որ SSMS-ը ակտիվ պատուհանն է, և դուք միացված եք օրինակին։
2. մամուլ Ctrl + ալտ + A.
3. Ակտիվության մոնիտորը կբացվի Object Explorer-ում ներկայումս ընտրված օրինակի համար։

Նկատի ունեցեք, որ Activity Monitor-ը կմիանա Object Explorer-ում ձեր ընտրած սերվերի օրինակին, ուստի համոզվեք, որ ընտրել եք ճիշտ օրինակը, նախքան այս կարճուղի օգտագործելը։

2.3.4 Մեթոդ 4. Ընտրանքների ցանկից (Գործարկման կարգավորում)

Եթե ​​հաճախ եք օգտագործում Activity Monitor-ը, կարող եք կարգավորել SSMS-ը այնպես, որ այն ավտոմատ կերպով գործարկվի հավելվածը գործարկելիս։

1. In SQL Server Կառավարման ստուդիա, անցեք դեպի Գործիքներ -> Ընտրանքներ.
2. «Ընտրանքներ» երկխոսության պատուհանում ընդարձակեք միջավայր, Եւ ապա ընտրել Startup.
3. - Ից Սկսվում է բացվող ցուցակ, ընտրեք Բացեք օբյեկտների դիտարկիչը և ակտիվության մոնիտորը.
4. ընտրել OK.

Հաջորդ անգամ, երբ դուք գործարկեք SSMS-ը և միանաք սերվերին, Activity Monitor-ը կբացվի ավտոմատ կերպով՝ Object Explorer-ի հետ միասին։

3. Գործունեության մոնիթորինգի վահանակների հասկացումը

Ակտիվության մոնիթորինգը տեղեկատվությունը կազմակերպում է հինգ ընդարձակվող վահանակների մեջ, որոնցից յուրաքանչյուրը տարբեր տեսանկյուն է տրամադրում սերվերի գործունեության վերաբերյալ: Արդյունավետ խնդիրների լուծման համար կարևոր է հասկանալ, թե ինչ է ցուցադրում յուրաքանչյուր վահանակը:

3.1 Ընդհանուր տեսքի վահանակ

Ընդհանուր տեսքի վահանակը ներկայացնում է չորս իրական ժամանակի գրաֆիկ, որոնք ձեզ տալիս են ձեր առողջության արագ պատկերացում։ SQL Server օրինակ։ Այս գրաֆիկները թարմացվում են կարգավորելի ժամանակահատվածում և օգնում են ձեզ մեկ հայացքով բացահայտել աննորմալ օրինաչափությունները։

3.1.1% պրոցեսորի ժամանակ

Այս գրաֆիկը ցույց է տալիս, թե պրոցեսորը որքան ժամանակ է ծախսում ոչ պարապ թելերի կատարման վրա SQL Server օրինակ բոլոր պրոցեսորների համար։ Արժեքը ներկայացնում է SQL Server-ի պրոցեսորի օգտագործումը, այլ ոչ թե սերվերի ամբողջ CPU-ի օգտագործումը։

Եթե ​​պրոցեսորի ժամանակը մշտապես 100% կամ դրան մոտ է, ապա ձեր սերվերը կապված է պրոցեսորի հետ։ Սա կարող է վկայել անարդյունավետ հարցումների, բացակայող ինդեքսների կամ անբավարար սարքային հզորության մասին։ Օգտագործեք «Վերջին թանկ հարցումներ» վահանակը՝ որոշելու համար, թե որ հարցումներն են ամենաշատը սպառում պրոցեսորը։

3.1.2 Սպասող առաջադրանքներ

Այս չափանիշը ցույց է տալիս այն առաջադրանքների քանակը, որոնք սպասում են ռեսուրսների ազատմանը, նախքան դրանց շարունակությունը։ Առաջադրանքները կարող են սպասել CPU-ի, I/O-ի, հիշողության կամ կողպեքների։

Սպասող առաջադրանքների կայուն բարձր թիվը ցույց է տալիս ռեսուրսների հետ կապված վիճարկում: «Ռեսուրսների սպասումներ» վահանակը ավելի մանրամասն տեղեկություններ է տրամադրում այն ​​մասին, թե որ տեսակի ռեսուրսներն են սպասումներ առաջացնում:

3.1.3 Տվյալների բազայի մուտք/ելք (ՄԲ/վ)

Այս գրաֆիկը ցույց է տալիս հիշողության և սկավառակի միջև տվյալների փոխանցման արագությունը։ Այն ներառում է և՛ ընթերցման, և՛ գրառման արագությունը, չափված մեգաբայթերով վայրկյանում։

Տվյալների բազայի մուտքի/ելքի կտրուկ աճը կարող է ցույց տալ մեծ աղյուսակների սկանավորում կատարող հարցումներ, չափազանց մեծ ակտիվություն գրանցման կետերում կամ ստուգիչ կետերում գործողություններ: «Տվյալների ֆայլերի մուտքի/ելքի» վահանակը մուտքի/ելքի ակտիվությունը բաժանում է տվյալների բազայի և ֆայլի:

3.1.4 Խմբային հարցումներ/վայրկյան

Այս չափանիշը ներկայացնում է քանակը SQL Server Մեկ վայրկյանում օրինակի կողմից ստացված խմբաքանակներ։ Խմբաքանակը կարող է լինել մեկ հայտարարություն կամ մի քանի հայտարարություններ, որոնք ներկայացվել են միասին։

Այս արժեքը ձեզ պատկերացում է տալիս սերվերի ընդհանուր ակտիվության մասին: Աշխատանքային ժամերի ընթացքում խմբաքանակային հարցումների կտրուկ անկումները կարող են վկայել հավելվածի միացման կամ օգտատիրոջ հետ կապված խնդիրների մասին:

3.1.5 Թարմացման միջակայքերի սահմանում

Դուք կարող եք կարգավորել, թե որքան հաճախ է Activity Monitor-ը թարմացնում իր տվյալները՝

1. Սեղմեք աջ կոճակով «Ընդհանուր տեսք» վահանակի ցանկացած մասում։
2. ընտրել Թարմացման միջակայք.
3. Ընտրեք միջակայք նախապես սահմանված արժեքներից՝ 1 վայրկյան, 5 վայրկյան, 10 վայրկյան (լռելյայն), 30 վայրկյան, 1 րոպե կամ 1 ժամ։

Թարմացման ինտերվալները 10 վայրկյանից պակաս սահմանելը մեծացնում է ձեր սերվերի մոնիթորինգի ծանրաբեռնվածությունը: Արտադրական համակարգերի ծանրաբեռնվածության դեպքում խորհուրդ է տրվում օգտագործել 30 վայրկյան կամ ավելի երկար ինտերվալներ՝ ազդեցությունը նվազագույնի հասցնելու համար:

3.2 Գործընթացների վահանակ

«Գործընթացներ» վահանակը ցուցադրում է տեղեկատվություն ձեր համակարգչում ներկայումս աշխատող նիստերի մասին։ SQL Server օրինակ։ Այս վահանակը կարևոր է պարզելու համար, թե ով ինչ է անում և հայտնաբերելու արգելափակող խնդիրները։

3.2.1 Գործընթացի տեղեկատվության ըմբռնում

«Գործընթացներ» վահանակի յուրաքանչյուր տող ներկայացնում է սերվերի ակտիվ սեսիա։ Վահանակը ցույց է տալիս բոլոր տվյալների բազաների և բոլոր օգտատերերի սեսիաները՝ ձեզ տալով սերվերի գործունեության համապարփակ պատկեր։

Ցուցադրվող տեղեկատվությունը ներառում է մուտքանունը, ծրագրի անվանումը, հոսթի անունը, մուտք գործվող տվյալների բազան և ընթացիկ հրամանը: Սա օգնում է ձեզ կապել տվյալների բազայի գործունեությունը որոշակի օգտատերերի կամ ծրագրերի հետ:

3.2.2 Հիմնական սյուների բացատրություն

Հիմնական սյուների ըմբռնումը կօգնի ձեզ արդյունավետորեն մեկնաբանել գործընթացի տեղեկատվությունը.

• Սեսիայի ID: Յուրաքանչյուր կապի համար եզակի նույնականացուցիչ։ Համակարգային գործընթացները օգտագործում են բացասական սեսիայի նույնականացուցիչներ։
• Օգտագործողի գործընթաց. Ցույց է տալիս, թե սա օգտատիրոջ սեսիա է (Այո), թե՞ համակարգային գործընթաց (Ոչ):
• Օգնություն   SQL Server մուտք կամ սեսիային կապված Windows հաշիվ։
• Տվյալների բազա: Սեսիայի համար տվյալների բազայի ընթացիկ համատեքստը։
• Առաջադրանքի վիճակը՝ Ցույց է տալիս, թե ինչ է կատարվում սեանսի ընթացքում (ՎԱԶՈՒՄ, ԿԱԽՎԱԾ Է, ՔՆՈՒՄ Է և այլն):
• Հրաման. Կատարվող հրամանի տեսակը (SELECT, INSERT, UPDATE և այլն):
• Application: Կապը ստեղծած ծրագրի անունը։
• Սպասեք ժամանակը Որքա՞ն ժամանակ (միլիվայրկյաններով) է սեսիան սպասում ռեսուրսների։
• Սպասման տեսակը՝ Ռեսուրսի կոնկրետ տեսակը, որին սեսիան սպասում է։
• CPU-ի ժամանակը։ Այս սեսիայի կողմից միանալուց ի վեր սպառված CPU-ի ընդհանուր ժամանակը։
• Հիշողության օգտագործումը՝ Սեսիային ներկայումս հատկացված հիշողության քանակը (KB-ով):

3.2.3 Ֆիլտրման և տեսակավորման գործընթացներ

«Գործընթացներ» վահանակը ներառում է հզոր զտման հնարավորություններ, որոնք կօգնեն ձեզ կենտրոնանալ համապատասխան նիստերի վրա.

1. Սեղմեք ցանկացած սյունակի վերնագրում գտնվող ցանկի սլաքի վրա։
2. Ֆիլտրը ցույց է տալիս այդ սյունակի համար հասանելի արժեքները, ներառյալ՝ բոլորը, Բլիթներ, եւ Ոչ դատարկ.
3. Ընտրեք որոշակի արժեքներ՝ ցուցադրումը միայն այդ սեսիաներին համապատասխան զտելու համար։

Օրինակ, կարող եք զտել Առաջադրանքի վիճակ միայն ԳՈՐԾՈՂ սեսիաները ցուցադրելու կամ զտելու համար Database որոշակի տվյալների բազայի նկատմամբ ակտիվությունը տեսնելու համար։

Կարող եք նաև տեսակավորել ցանկացած սյունակի համաձայն՝ սեղմելով դրա վերնագրի վրա։ Սեղմեք մեկ անգամ՝ աճման կարգով դասավորելու համար, երկու անգամ՝ նվազման կարգով դասավորելու համար։

3.2.4 Արգելափակված և արգելափակված սեսիաների նույնականացում

«Գործընթացներ» վահանակը օգնում է ձեզ բացահայտել արգելափակման սցենարներ, որոնց դեպքում մեկ նիստը խանգարում է մյուսների շարունակմանը.

• Արգելափակված է՝ Ցույց է տալիս այն սեսիայի ID-ն, որը արգելափակում է այս սեսիան։ Եթե այս սյունակը պարունակում է արժեք, ապա սեսիան սպասում է մեկ այլ սեսիայի կողմից պահված կողպեքի։
• Գլխի արգելափակիչ. Ցուցադրում է «1», եթե այս սեսիան արգելափակում է մյուսներին, բայց ինքնին արգելափակված չէ։ Սա արգելափակման շղթայի հիմնական պատճառն է։

Արգելափակման խնդիրը հետաքննելու համար նախ նույնականացրեք գլխավոր արգելափակողին (Գլխավոր արգելափակող սյունակում «1» նշանով նշված սեսիան), այնուհետև ուսումնասիրեք, թե ինչ է այն անում և որոշեք՝ թողեք, որ այն ավարտի, թե՞ դադարեցնի այն։

3.2.5 Գործընթացի գործողություններ (փակել, մանրամասներ, հետևել)

Ակտիվության մոնիթորը թույլ է տալիս գործողություններ ձեռնարկել առանձին նիստերի ընթացքում.

1. Սեղմեք աջ կոճակով «Գործընթացներ» վահանակում գտնվող ցանկացած սեսիայի վրա։
2. Դուք կտեսնեք մի քանի տարբերակ՝
   • Մանրամասներ: Ցույց է տալիս այս սեսիայի կողմից կատարված վերջին հրամանը։
   • Սպանել գործընթացը՝ Ավարտում է նիստը (օգտագործեք զգուշությամբ):
   • Հետևման գործընթաց SQL Server Պրոֆիլավորող: Մեկնարկում SQL Server Պրոֆիլավոր և ավտոմատ կերպով զտում է՝ ցույց տալու միայն այս նստաշրջանի ակտիվությունը։

«Մանրամասներ» տարբերակը ցույց է տալիս հրամանի տեքստը, սակայն նկատի ունեցեք, որ սա է անցյալ Հրամանը կատարված է. այն կարող է դեռ չաշխատել: Հետևելու տարբերակը հատկապես օգտակար է, երբ անհրաժեշտ է տեսնել սեսիայի կողմից կատարվող հրամանների ամբողջական հաջորդականությունը:

3.3 Ռեսուրսների սպասման վահանակ

«Ռեսուրսների սպասման» վահանակը ամփոփում է սպասման վիճակագրությունը՝ ցույց տալով, թե որ տեսակի ռեսուրսների սեսիաներն են ամենից հաճախ սպասում։ Այս տեղեկատվությունը կարևոր է կատարողականի խցանումները ախտորոշելու համար։

3.3.1 Սպասման վիճակագրության ըմբռնումը

Երբ SQL Server Եթե ​​սերվերը չի կարող անմիջապես բավարարել ռեսուրսի հարցումը (օրինակ՝ կողպեք, CPU ժամանակ կամ հիշողություն), հարցնող առաջադրանքը մտնում է սպասման վիճակ: Սպասման վիճակագրությունը հետևում է այս սպասման ժամանակահատվածներին և օգնում է ձեզ հասկանալ, թե որտեղ է սերվերը ժամանակ ծախսում սպասելու, այլ ոչ թե աշխատելու վրա:

«Ռեսուրսների սպասումներ» վահանակը հավաքում է տվյալներ համակարգի դինամիկ կառավարման այնպիսի դիտումներից, ինչպիսիք են sys.dm_os_wait_stats-ը և sys.dm_exec_requests-ը: Յուրաքանչյուր թարմացման միջակայքում այն ​​հաշվարկում է ընթացիկ և նախորդ լուսանկարների միջև եղած տարբերությունը՝ ցույց տալով յուրաքանչյուր սպասման տեսակի համար կուտակման տեմպը:

3.3.2 Սպասման կատեգորիաներ

Activity Monitor-ը հարյուրավոր անհատական ​​սպասման տեսակներ խմբավորում է ավելի լայն կատեգորիաների մեջ՝ մեկնաբանությունը պարզեցնելու համար։

• CPU: Առաջադրանքները սպասում են, մինչև CPU-ի ժամանակը հասանելի դառնա։
• Բուֆերային փակիչ՝ Սպասում է կարճաժամկետ համաժամացման օբյեկտների, որոնք պաշտպանում են հիշողության մեջ գտնվող տվյալների էջերին մուտքը: Այս կատեգորիան ներառում է էջի կողպեքի սպասումներ (PAGELATCH_*):
• Կողպեք: Սպասումներ, որոնք առաջանում են այն սեսիաների կողմից արգելափակված կողպեքների առկայության պատճառով, որոնք անհրաժեշտ են այլ սեսիաներին։
• Հիշողությունը Սպասում է հիշողության տրամադրման համար, որն անհրաժեշտ է տեսակավորման և հեշավորման նման գործողությունների համար։
• Ցանցի մուտք/ելք՝ Սպասում է հաճախորդներին տվյալներ ուղարկելուն կամ հաճախորդներից տվյալներ ստանալուն։
• SQL CLR: Common Language Runtime-ի կատարման հետ կապված սպասումներ։

Թեև այս խմբավորումը պարզեցնում է դիտումը, այն նաև թաքցնում է կարևոր մանրամասները: Օրինակ, «Buffer Latch»-ը կարող է խմբավորել PAGELATCH_SH, PAGELATCH_UP և PAGELATCH_EX սպասման ժամանակահատվածները, որոնք տարբեր հետևանքներ ունեն կատարողականի համար:

3.3.3 Սպասման ժամանակի և սպասման առաջադրանքների մեկնաբանություն

«Ռեսուրսների սպասումներ» վահանակը ցուցադրում է երկու հիմնական չափանիշ յուրաքանչյուր սպասման կատեգորիայի համար.

• Կուտակային սպասման ժամանակ (մվ): Այս սպասման կատեգորիայի համար ընթացիկ թարմացման միջակայքի ընթացքում կուտակված միլիվայրկյանների ընդհանուր քանակը։
• Սպասման առաջադրանքներ. Այս կատեգորիայում ներկայումս ռեսուրսների սպասող առաջադրանքների քանակը։

Հատկապես հետաքրքիր է սպասման ժամանակի արժեքը։ Եթե ունեք 10 վայրկյան թարմացման միջակայք և տեսնում եք 20,000 մվ սպասման ժամանակ որևէ կատեգորիայի համար, դա նշանակում է մի քանի միաժամանակյա սպասումներ (20,000 մվ / 10,000 մվ = միջակայքի ընթացքում 2 միաժամանակյա սպասումների միջինը):

3.3.4 Արդյունավետության խոչընդոտների բացահայտում

Օգտագործեք «Ռեսուրսների սպասում» վահանակը՝ որոշելու համար, թե որտեղ է ձեր սերվերն ամենաշատ ժամանակն անցկացնում սպասելով։

1. Ընդարձակեք «Ռեսուրսների սպասումներ» վահանակը։
2. Դիտարկեք սպասման կատեգորիաները, որոնք կուտակում են ամենաշատ սպասման ժամանակները։
3. Դասավորել ըստ Կուտակային սպասման ժամանակը տեսնելու համար, թե որ ռեսուրսներն են առավել սահմանափակ։

Բարձր բուֆերային լաթչերի սպասումները հաճախ ցույց են տալիս հիշողության մեջ տվյալների էջերի համար մրցակցություն, ինչը կարող է ենթադրել մուտքի/ելքի խցանումներ կամ tempdb-ի մրցակցություն: Բարձր կողպեքի սպասումները ցույց են տալիս արգելափակման խնդիրներ: Հիշողության բարձր սպասումները ցույց են տալիս հարցման գործողությունների համար հիշողության անբավարար տրամադրում:

3.4 Տվյալների ֆայլերի մուտքի/ելքի վահանակ

«Տվյալների ֆայլի մուտք/ելք» վահանակը ցույց է տալիս ձեր սերվերի վրա գտնվող յուրաքանչյուր տվյալների բազայի ֆայլի սկավառակի ակտիվությունը, ինչը կօգնի ձեզ բացահայտել մուտք/ելքի խցանումները և հասկանալ սկավառակի օգտագործման օրինաչափությունները։

3.4.1 Մուտքի/ելքի չափանիշների հասկացում

«Տվյալների ֆայլի մուտք/ելք» վահանակը ցուցադրում է մի քանի չափանիշներ յուրաքանչյուր տվյալների բազայի ֆայլի համար.

• Տվյալների բազա: Տվյալների բազայի անվանումը։
• Ֆայլի տեսակը. Կամ տվյալներ (ներառյալ աղյուսակները և ինդեքսները), կամ գրանցամատյան (գործարքների գրանցամատյան):
• Լոգիկական անուն՝ Լոգիկական ֆայլի անունը, ինչպես սահմանված է SQL Server.
• ՄԲ/վրկ ընթերցում: Այս ֆայլից տվյալների ընթերցման արագությունը։
• ՄԲ/վրկ Գրված է. Այս ֆայլում տվյալների գրառման արագությունը։
• Արձագանքի ժամանակը (մվ): Այս ֆայլի վրա I/O գործողությունների միջին արձագանքման ժամանակը։

Այս չափանիշները թարմացվում են «Ընդհանուր տեսք» վահանակի հետ նույն ժամանակահատվածում՝ ձեզ հնարավորություն տալով իրական ժամանակում տեսնել սկավառակի ակտիվությունը։

3.4.2 Մուտքի/ելքի խոչընդոտների բացահայտում

Ուշադրություն դարձրեք այս օրինաչափություններին, որոնք ցույց են տալիս I/O կատարողականի հետ կապված խնդիրներ.

• Բարձր արձագանքման ժամանակ՝ 15-20 մվ-ից բարձր արձագանքման ժամանակը վկայում է դանդաղ սկավառակային ենթահամակարգերի մասին: 50 մվ-ից բարձր արձագանքման ժամանակը վկայում է լուրջ մուտքի/ելքի խցանումների մասին:
• Անհավասարակշռված բեռ. Եթե ​​մեկ տվյալների ֆայլը ցույց է տալիս զգալիորեն ավելի բարձր մուտք/ելք արագություն, քան նույն տվյալների բազայի մյուս ֆայլերը, ապա կարող եք օգտվել լրացուցիչ ֆայլեր ավելացնելուց՝ բեռը բաշխելու համար։
• Tempdb-ի չափազանց մեծ ակտիվություն. Tempdb ֆայլերի բարձր մուտքի/ելքի արագությունը հաճախ ցույց է տալիս հարցումներ, որոնք ստեղծում են մեծ միջանկյալ արդյունքների հավաքածուներ կամ օգտագործում են անարդյունավետ կատարման պլաններ։

3.4.3 Տվյալների բազայի ֆայլերի վերլուծություն

Օգտագործեք «Տվյալների ֆայլի մուտք/ելք» վահանակը՝ հասկանալու համար, թե ինչպես են ձեր տվյալների բազաները օգտագործում սկավառակի ռեսուրսները։

1. Ընդարձակեք «Տվյալների ֆայլի մուտք/ելք» վահանակը։
2. Դասավորել ըստ ՄԲ/վրկ ընթերցում or ՄԲ/վրկ գրված ամենաակտիվ ֆայլերը նույնականացնելու համար։
3. Ուշադրություն դարձրեք բոլոր ֆայլերին, որոնք ունեն կայուն բարձր ակտիվություն կամ երկար արձագանքման ժամանակ։
4. Խաչաձև համեմատեք այս տեղեկատվությունը «Վերջին թանկարժեք հարցումներ» վահանակի հետ՝ պարզելու համար, թե որ հարցումներն են խթանում մուտքի/ելքի բեռը։

3.5 Վերջին թանկարժեք հարցումների վահանակ

«Վերջին թանկարժեք հարցումներ» վահանակը հաճախ ամենաարժեքավոր վահանակն է ծրագրերի կատարողականի հետ կապված խնդիրների լուծման համար: Այն ցույց է տալիս հարցումները, որոնք սպառում են զգալի սերվերի ռեսուրսներ, օգնելով ձեզ բացահայտել օպտիմալացման հնարավորությունները:

3.5.1 Հարցման չափանիշների հասկացումը

Activity Monitor-ը յուրաքանչյուր թանկարժեք հարցման համար ցուցադրում է մի քանի չափանիշներ՝

• Կատարումներ/րոպե: Քանի անգամ է հարցումը կատարվել վերջին րոպեի ընթացքում։
• CPU (մվ/վրկ): Այս հարցման կողմից վայրկյանում սպառված CPU ժամանակը։
• Ֆիզիկական ընթերցումներ/վրկ: Այս հարցման համար վայրկյանում ֆիզիկական սկավառակի ընթերցումների քանակը։
• Լոգիկական գրառումներ/վրկ: Լոգիկական գրառումների քանակը (բուֆերային քեշում) վայրկյանում։
• Լոգիկական ընթերցումներ/վրկ: Լոգիկական ընթերցումների քանակը (բուֆերային քեշից) վայրկյանում։
• Միջին տևողությունը (մվ): Այս հարցման միջին կատարման ժամանակը։
• Պլանի քանակը՝ Այս հարցման համար քեշում կատարման պլանների քանակը։

Այս չափանիշները կօգնեն ձեզ հասկանալ ոչ միայն, թե որ հարցումներն են թանկ, այլև ինչու դրանք թանկ են և որքան հաճախ են աշխատում։

3.5.2 Դասակարգման տարբերակներ

Դուք կարող եք տեսակավորել «Վերջին թանկ հարցումներ» վահանակը տարբեր չափանիշներով՝ տարբեր տեսակի խնդիրներ գտնելու համար։

1. Սեղմեք ցանկացած սյունակի վերնագրի վրա՝ այդ չափանիշով տեսակավորելու համար։
2. Ընդհանուր տեսակավորման ռազմավարությունները ներառում են.
   • Դասավորել ըստ պրոցեսորի՝ Գտեք ամենաշատ պրոցեսորի ժամանակը սպառող հարցումները։
   • Դասավորել ըստ Կատարումների/րոպե: Նույնականացրեք չափազանց հաճախակի կատարվող հարցումները։
   • Դասավորել ըստ ֆիզիկական ընթերցումների՝ Գտեք հարցումները, որոնք առաջացնում են սկավառակի ամենաշատ մուտք/ելքները։
   • Դասավորել ըստ միջին տևողության՝ Գտեք երկարատև հարցումներ։

Արդյունավետության հետ կապված խնդիր լուծելիս փորձեք տեսակավորել մի քանի սյուներով՝ տարբեր տեսանկյուններ ստանալու համար: Ձեր իրական խնդիրը կարող է լինել հարցումը, որն ունի միջին CPU ծանրաբեռնվածություն, բայց րոպեում չափազանց բարձր կատարողականություն:

3.5.3 Հարցման տեքստի դիտում

Թանկարժեք հարցման հետևում թաքնված իրական SQL հրամանը տեսնելու համար՝

1. Վերջին թանկարժեք հարցումներ վահանակում աջ սեղմեք հարցման տողի վրա։
2. ընտրել Խմբագրել հարցման տեքստը.
   
3. Բացվում է նոր հարցման պատուհան, որը ցուցադրում է SQL հրամանի ամբողջական տեքստը։
   

Սա թույլ է տալիս ուսումնասիրել հարցման տրամաբանությունը և բացահայտել օպտիմալացման հնարավոր հնարավորությունները: Այնուհետև կարող եք պատճենել հարցման տեքստը՝ փոփոխված տարբերակները փորձարկելու համար:

3.5.4 Կատարման ծրագրերի վերլուծություն

Կատարման պլանները ցույց են տալիս, թե ինչպես SQL Server կատարում է հարցում՝ բացահայտելով անարդյունավետություններ, ինչպիսիք են բացակայող ինդեքսները կամ անհամապատասխան միացման տեսակները։

1. Վերջին թանկարժեք հարցումներ վահանակում աջ սեղմեք հարցման տողի վրա։
2. ընտրել Ցուցադրել կատարման պլանը.
   
3. SQL Server Management Studio-ն ցուցադրում է հարցման կատարման գրաֆիկական պատկերը։
   

Ուշադրություն դարձրեք այնպիսի գործողությունների, որոնք մեծ տոկոս են կազմում հարցման արժեքի, բացակայող վիճակագրության կամ ինդեքսների վերաբերյալ նախազգուշացումների և աղյուսակների անսպասելի սկանավորման գործողությունների: Սրանք հաճախ ցույց են տալիս, թե որտեղ պետք է կենտրոնանան օպտիմալացման ջանքերը:

3.5.5 Խնդրահարույց հարցումների բացահայտում

Հետևեք այս օրինաչափություններին «Վերջին թանկարժեք հարցումներ» վահանակում։

• Չափազանց մեծ կատարողականներ. Րոպեում հազարավոր անգամ կատարվող հարցումը կարող է ցույց տալ N+1 հարցման խնդիր, որտեղ ծրագրի կոդը կանչում է տվյալների բազան ցիկլի ներսում։
• Բարձր ֆիզիկական ցուցանիշներ. Բարձր ֆիզիկական ընթերցման արագությամբ հարցումները հաճախակի են հայտնվում սկավառակի վրա, ինչը ենթադրում է բացակայող ինդեքսներ կամ վատ գրված հարցումներ։
• Բարձր CPU՝ ցածր տևողությամբ. Շատ արագ հարցումներ, որոնք ընդհանուր առմամբ մեծ քանակությամբ CPU են սպառում, կարող են ազդել սերվերի աշխատանքի վրա նույնքան, որքան մի քանի դանդաղ հարցումները։
• Բազմակի պլանների քանակը՝ Շատ կատարման պլաններ ունեցող հարցումները կարող են տառապել պարամետրերի սնիֆինգի խնդիրներից կամ ոչ պարամետրացված հարցումներից, որոնք առաջացնում են պլանի քեշի գերբեռնվածություն։

4. Activity Monitor-ի օգտագործումը կատարողականի խնդիրների լուծման համար

Activity Monitor-ը իսկապես հիանալի է, երբ այն օգտագործում եք համակարգված կերպով՝ կատարողականի խնդիրները ախտորոշելու և լուծելու համար: Այս բաժինը ներառում է խնդիրների լուծման տարածված սցենարներ և դրանց լուծման եղանակներ:

4.1 Հարցումների չափազանց մեծ ծավալի կատարումների ախտորոշում

Արդյունավետության ամենատարածված խնդիրներից մեկը հարցումների կատարումն է անհրաժեշտից շատ ավելի հաճախ, հաճախ՝ հավելվածի դիզայնի հետ կապված խնդիրների պատճառով։

4.1.1 Կրկնվող հարցումների նույնականացում

Չափազանց հաճախ կատարվող հարցումները հայտնաբերելու համար՝

1. Բացեք Ակտիվության մոնիտորը և ընդարձակեք Վերջին թանկարժեք հարցումները հաց.
2. Դասավորել ըստ Կատարումներ/րոպե (կատարումների քանակը րոպեում):
3. Վերևում փնտրեք հարցումներ, որոնց կատարման թվերը անհիմն բարձր են թվում։
4. Աջ սեղմեք կասկածելի հարցման վրա և ընտրեք Խմբագրել հարցման տեքստը SQL հրամանը ուսումնասիրելու համար։

Օրինակ, եթե տեսնում եք պարզ SELECT հրաման, որը կատարվում է րոպեում 37,000 անգամ, հարցրեք, թե արդյոք ծրագիրը իսկապես պետք է այդքան հաճախ կանչի այս հարցումը: Հարցումների մեծ մասը, որոնք կատարվում են րոպեում մի քանի հազարից ավելի անգամ, պահանջում է հետաքննություն:

4.1.2 Արմատական ​​պատճառի վերլուծություն

Հարցումների չափազանց մեծ կատարումները սովորաբար առաջանում են հետևյալ խնդիրներից.

• N+1 հարցման խնդիր՝ Ծրագրի կոդը վերցնում է տարրերի ցանկ, այնուհետև կատարում է առանձին հարցում յուրաքանչյուր տարրի համար՝ համապատասխան տվյալներ ստանալու համար: Սա ստեղծում է N լրացուցիչ հարցումներ, որտեղ N-ը տարրերի քանակն է:
• Քեշավորումը բացակայում է. Ծրագիրը տվյալների բազային հարցում է անում հազվադեպ փոփոխվող տվյալների համար՝ դրանք ծրագրի հիշողության մեջ քեշավորելու փոխարեն։
• Հարցման ցիկլեր՝ Կոդը բազմիցս հարցումներ է ուղարկում տվյալների բազային՝ ստուգելով վիճակի փոփոխությունները, այլ ոչ թե օգտագործում է փոփոխությունների ծանուցումներ կամ հաղորդագրությունների հերթեր։
• ORM անարդյունավետություն. Entity Framework-ը և նմանատիպ գործիքները երբեմն ստեղծում են անարդյունավետ հարցման ձևանմուշներ, երբ մշակողները չեն հասկանում, թե ինչպես է իրենց կոդը թարգմանվում SQL-ի։

Հիմնական պատճառը որոշելու համար հետադարձեք հարցումը մինչև ծրագրի կոդը։ Ուշադրություն դարձրեք հետևյալին. դիմում և Մուտք սյուները «Գործընթացներ» վահանակում, երբ հարցումը կատարվում է: Կարող եք նաև աջ սեղմել գործընթացի վրա և ընտրել Հետևման գործընթաց SQL Server Պրոֆիլավոր զանգերի ձևը տեսնելու համար։

4.1.3 Լուծումներ և լավագույն պրակտիկա

Երբ հայտնաբերեք չափազանց շատ հարցումների կատարումներ, դիտարկեք հետևյալ լուծումները.

• Խմբաքանակի մշակում. Փոփոխեք ծրագրի կոդը՝ մեկ հարցման մեջ մի քանի տարրեր ստանալու համար՝ օգտագործելով միացումներ կամ IN կետեր՝ առանձին հարցումներ մեկ ցիկլում կատարելու փոխարեն։
• Արդյունքների քեշավորում՝ Քեշին հաճախակի մուտք են գործում, հավելվածի հիշողության մեջ տվյալները հազվադեպ են փոխվում՝ համապատասխան ժամկետանցության ժամկետներով։
• Անհամբեր բեռնում. Կարգավորեք ORM-ները՝ օգտագործելու արագ բեռնման ռազմավարություններ, որոնք կբերեն համապատասխան տվյալներ ավելի քիչ և ավելի արդյունավետ հարցումներով։
• Հարցման պարամետրացում՝ Համոզվեք, որ հարցումներն օգտագործում են պարամետրեր՝ արժեքները միացնելու փոխարեն, ինչը բարելավում է պլանի քեշի վերօգտագործումը և նվազեցնում կոմպիլյացիայի վրա ծախսված ժամանակը։

4.2 Արգելափակման խնդիրների ուսումնասիրություն

Կողպումը տեղի է ունենում, երբ մեկ սեսիան արգելափակումներ է պահում, որոնք կանխում են մյուս սեսիաների շարունակությունը: Սա դրսևորվում է որպես ծրագրի դանդաղ արձագանքման ժամանակ և օգտատերերի հիասթափություն:

4.2.1 Խոչընդոտող շղթաների նույնականացում

Արգելափակումը հայտնաբերելու և վերլուծելու համար՝

1. Բացեք Ակտիվության մոնիտորը և ընդարձակեք Գործընթացները հաց.
2. Փնտրեք սեսիաներ, որոնց արժեքները գտնվում են Արգելափակված է սյունակ—սրանք սպասում են այլ սեսիաների կողմից պահված կողպեքներին։
3. Գտնել սեսիաներ, որոնցում «1» է Գլխի արգելափակիչ սյունակ—սրանք շղթաների խցանման հիմնական պատճառն են։
4. Նշենք Նստաշրջանի ID գլխի արգելափակիչի։
5. Սեղմեք աջ կոճակով գլխի արգելափակման սեսիայի վրա և ընտրեք Մանրամասներ տեսնելու համար, թե ինչ հրաման է այն կատարում։

Բլոկավորման շղթան հասկանալը կարևոր է։ Գլխավոր արգելափակողը այն սեսիան է, որը դուք պետք է ուսումնասիրեք, այլ ոչ թե հաջորդող արգելափակված սեսիաները։

4.2.2 Կողպեքների տեսակների հասկացումը

  Սպասման տեսակը «Գործընթացներ» վահանակի սյունակը ցույց է տալիս, թե արգելափակված նիստերը ինչ տեսակի կողպեքի են սպասում։

• LCK_M_X: Բացառիկ կողպման սպասում, որը սովորաբար առաջանում է UPDATE, DELETE կամ INSERT գործողությունների պատճառով։
• LCK_M_S: Համօգտագործվող կողպեքի սպասում, սովորաբար SELECT հրամանները սպասում են բացառիկ կողպեքների ազատմանը։
• LCK_M_U: Թարմացման կողպեքի սպասման ժամանակ, միջանկյալ կողպեքի տեսակ, որն օգտագործվում է թարմացումների ընթացքում։
• LCK_M_IX: Մտադրության բացառիկ կողպեքի սպասում, որը ցույց է տալիս էջի կամ տողի մակարդակի կողպեքի վիճարկումը։

  Սպասման ռեսուրս սյունակը ցույց է տալիս, թե տվյալների բազայի որ օբյեկտն է կողպվում, ինչը օգնում է ձեզ հասկանալ, թե որ աղյուսակը կամ ինդեքսն է ներգրավված մրցակցության մեջ։

4.2.3 Արգելափակման խնդիրների լուծում

Երբ դուք որոշեք արգելափակող սեսիան և դրա գործողությունները, դուք ունեք մի քանի տարբերակ.

1. Սպասեք ավարտին. Եթե ​​գլխավոր արգելափակողը կատարում է օրինական հարցում, որը շուտով կավարտվի, ապա լավագույնը կլինի թողնել, որ այն բնականաբար ավարտվի։
2. Փակեք նիստը. Եթե ​​գլխի արգելափակիչը խրված է կամ կատարում է հարցում, որը պետք է չեղարկվի.
   • «Գործընթացներ» վահանակում աջ սեղմեք սեսիայի վրա։
   • ընտրել Փակել գործընթացը.
   • Հաստատեք գործողությունը երկխոսության պատուհանում։
3. Հարցումների օպտիմալացում. Եթե ​​արգելափակումը կրկնվում է նույն հարցումներով, օպտիմալացրեք դրանք՝ արգելափակման տևողությունը կրճատելու համար։
4. Կարգավորեք մեկուսացման մակարդակները. Դիտարկեք READ COMMITTED SNAPSHOT ISOLATION-ի օգտագործումը՝ ընթերցման ծանրաբեռնված աշխատանքային բեռների դեպքում արգելափակումները նվազեցնելու համար։
5. Index Tuning: Ավելացրեք ինդեքսներ՝ հարցումները արագացնելու և կողպեքների պահպանման տևողությունը կրճատելու համար։

4.3 Բարձր պրոցեսորի օգտագործման վերլուծություն

Երբ «Ընդհանուր տեսք» վահանակում պրոցեսորի ժամանակը մշտապես ցույց է տալիս 100% կամ դրան մոտ, դուք պետք է որոշեք, թե որ հարցումներն են պատասխանատու և որոշեք, թե արդյոք դրանք կարող են օպտիմալացվել։

4.3.1 CPU-ինտենսիվ հարցումների նույնականացում

Չափից շատ CPU սպառող հարցումներ գտնելու համար՝

1. Բացել Վերջին թանկարժեք հարցումները հաց.
2. Դասավորել ըստ CPU (մվ/վրկ) ցույց տալ հարցումները, որոնք օգտագործում են ամենաշատ CPU ժամանակը։
3. Ուսումնասիրեք ցանկի մեջ ամենաշատ քննարկվող հարցումները։
4. Բարձր CPU հարցումների վրա սեղմեք աջ կոճակը և ընտրեք Խմբագրել հարցման տեքստը SQL հրամանը դիտելու համար։
5. ընտրել Ցուցադրել կատարման պլանը հասկանալու համար, թե ինչպես է կատարվում հարցումը։

Ուշադրություն դարձրեք ոչ միայն անհատական ​​​​հարցումների CPU-ի ծանրաբեռնվածությանը, այլև Կատարումներ/րոպե սյունակ։ Հարցումը, որն օգտագործում է միջին CPU մեկ կատարման համար, բայց րոպեում հազարավոր անգամներ է աշխատում, կարող է լինել ձեր ամենամեծ CPU սպառողը։

4.3.2 Հարցումների օպտիմալացման տեխնիկաներ

CPU-ի սպառումը նվազեցնելու ընդհանուր մոտեցումները ներառում են.

• Ավելացնել բացակայող ինդեքսները՝ Ինդեքսը փորձում է օգտագործել շատ ավելի քիչ CPU, քան աղյուսակների սկանավորումը։ Ուշադրություն դարձրեք ինդեքսի բացակայող առաջարկություններին կատարման պլաններում։
• Վերաշարադրել անարդյունավետ հարցումները՝ Փոխարինեք կուրսորները բազմությունների վրա հիմնված գործողություններով, վերացրեք WHERE դրույթներում ավելորդ ֆունկցիաները և հեռացրեք ավելորդ միացումները։
• Թարմացնել վիճակագրությունը. Հնացած վիճակագրությունը պատճառ է հանդիսանում SQL Server անարդյունավետ կատարման պլաններ ընտրելու համար: Գործարկեք UPDATE STATISTICS-ը տուժած աղյուսակների վրա:
• Նվազեցնել տվյալների ծավալը. Ավելացրեք WHERE դրույթներ՝ տվյալները ավելի վաղ զտելու համար, օգտագործեք TOP կամ OFFSET/FETCH՝ էջերի համար, և խուսափեք SELECT *-ից։
• Պարամետրերի հոտոտման շտկում. Օգտագործեք OPTION (RECOMPILE), հարցման հուշումներ կամ պլանավորման ուղեցույցներ, երբ պարամետրերի սնոբիտը խնդիրներ է առաջացնում։

4.4 Հիշողության հետ կապված խնդիրների ուսումնասիրություն

Հիշողության ծանրաբեռնվածությունը կարող է հանգեցնել հարցումների արտահոսքի սկավառակի վրա, ինչը զգալիորեն վատթարացնում է աշխատանքի արդյունավետությունը: Activity Monitor-ը օգնում է ձեզ նույնականացնել հիշողությունը մեծ քանակությամբ օգտագործող գործողությունները:

4.4.1 Հիշողության չափանիշների հասկացումը

  Հիշողության օգտագործումը «Գործընթացներ» վահանակի սյունակը ցույց է տալիս յուրաքանչյուր սեսիային հատկացված հիշողությունը կիլոբայթերով: Մեկ սեսիայի կողմից հիշողության բարձր օգտագործումը հաճախ ցույց է տալիս.

• Մեծ տեսակավորման կամ հեշավորման գործողություններ, որոնք չէին կարող տեղավորվել սկզբնապես տրամադրված հիշողության մեջ
• Հարցումներ, որոնք վերցնում են հսկայական արդյունքների հավաքածուներ
• Չափազանց զուգահեռականություն, որը ստեղծում է կատարման պլանի օպերատորների բազմաթիվ պատճեններ
• Հիշողության արտահոսք CLR-ում պահված պրոցեդուրաներում կամ ֆունկցիաներում

«Ռեսուրսների սպասումներ» վահանակը կարող է ցուցադրել հիշողության սպասումներ, երբ հարցումները չեն կարողանում ստանալ բավարար հիշողության տրամադրում և պետք է սպասեն, մինչև հիշողությունը ազատ դառնա։

4.4.2 Հիշողության ինտենսիվ հարցումների նույնականացում

Հիշողության ճնշում առաջացնող հարցումներ գտնելու համար՝

1. Է Գործընթացները վահանակ, տեսակավորել ըստ Հիշողության օգտագործումը տեսնելու համար, թե որոնք են ամենաշատ հիշողությունը սպառող սեսիաները։
2. Աջ սեղմեք հիշողության մեծ սպառմամբ նիստերի վրա և ընտրեք Մանրամասներ նրանց հարցումները դիտելու համար։
3. Է Վերջին թանկարժեք հարցումները վահանակ, փնտրեք բարձր մակարդակով հարցումներ Տրամաբանական ընթերցումներ or Լոգիկական գրառումներ, քանի որ սրանք հաճախ կապված են հիշողության օգտագործման հետ։
4. Ուսումնասիրեք հիշողության շնորհումներ օգտագործող Sort և Hash Match օպերատորների կատարման պլանները։

Կատարման պլաններում «Հիշողության դրամաշնորհ» նախազգուշացումներ ցուցադրող կամ թափվելու նախազգուշացումներ ցուցադրող հարցումները վկայում են հիշողության ճնշման խնդիրների մասին։

4.5 Ծրագրի աշխատանքի հետ կապված խնդիրների հայտնաբերում

Երբ օգտատերերը հայտնում են հավելվածի դանդաղ արձագանքման մասին, Activity Monitor-ը օգնում է ձեզ որոշել, թե արդյոք տվյալների բազան է խոչընդոտը։

4.5.1 Գործունեության մոնիտորի կապը կիրառական խնդիրների հետ

Ծրագրի դանդաղությունը ստուգելու համար՝

1. Նշեք օգտատերերի կողմից խնդիրների մասին հաղորդելու ճշգրիտ ժամանակը և տուժած հավելվածները։
2. Բացեք Activity Monitor-ը և ստուգեք Overview այդ պահին ռեսուրսների կտրուկ աճի վահանակ։
3. Է Գործընթացները վահանակ, զտել ըստ դիմում ցուցադրելու միայն ազդակիր ծրագրի միացումները։
4. Փնտրեք բարձր Սպասման ժամանակ արժեքներ, որոնք ցույց են տալիս տվյալների բազայի ուշացումները։
5. Ստուգել Վերջին թանկարժեք հարցումները վահանակ՝ զգալի ռեսուրսներ սպառող այդ ծրագրի հարցումների համար։

Եթե ​​տվյալների բազան անսովոր գործունեություն չի ցուցաբերում, մինչդեռ օգտատերերը դանդաղ են աշխատում, խնդիրը, հավանաբար, ծրագրի կոդի, ցանցի լատենտության կամ հաճախորդի կողմից կատարողականի մեջ է։

4.5.2 Անարդյունավետ կիրառման մոդելների բացահայտում

Activity Monitor-ը բացահայտում է հավելվածի դիզայնի մի քանի հակաօրինաչափություններ.

• Զրուցասեր հավելվածներ՝ Շատ փոքր հարցումներ՝ ավելի քիչ, ավելի արդյունավետ հարցումների փոխարեն։ Տարբերակվում է մեծ թվով միացումներով և բազմաթիվ պարզ հարցումներով «Վերջին թանկ հարցումներ» բաժնում։
• N+1 հարցումներ՝ Մեկ հարցում, որին հաջորդում են N լրացուցիչ հարցումներ՝ կապված տվյալների համար։ Ցուցադրվում է որպես պարզ հարցում՝ րոպեում չափազանց բարձր կատարողականությամբ։
• Մեծ արդյունքների հավաքածուներ՝ Ծրագրերը վերցնում են անհրաժեշտից շատ ավելի տվյալներ։ Փնտրեք բարձր Տրամաբանական ընթերցումներ համակցված պարզ SELECT * հարցումների հետ։
• Բացակայող ժամանակի սպառումներ՝ Հրամանների ժամկետ չսահմանող հավելվածները կարող են անորոշ ժամանակով բաց թողնել միացումները, որոնք տեսանելի կլինեն որպես երկարատև սեսիաներ «Գործընթացներ» վահանակում։

5. Այլընտրանքային մեթոդներ. Ակտիվության մոնիտորի տվյալների ստացում T-SQL-ի միջոցով

Թեև Activity Monitor-ը տրամադրում է հարմար գրաֆիկական ինտերֆեյս, երբեմն անհրաժեշտ է ծրագրային եղանակով ստանալ համարժեք տեղեկատվություն կամ ստեղծել անհատական ​​մոնիթորինգի լուծումներ։

5.1 Դինամիկ կառավարման տեսարանների (DMV) օգտագործումը

SQL Server բացահայտում է գործունեության տեղեկատվությունը դինամիկ կառավարման տեսքերի միջոցով, որոնք Activity Monitor-ը հարցումներ է կատարում կուլիսներից դուրս։

5.1.1 Գործունեության մոնիթորինգի հիմնական DMV-ները

Activity Monitor ֆունկցիոնալությունը կրկնօրինակելու ամենակարևոր DMV-ներն են՝

• sys.dm_exec_requests: Ցույց է տալիս CPU-ի, I/O-ի և սպասման տեղեկատվության միջոցով ներկայումս կատարվող հարցումները։
• sys.dm_exec_sessions: Պարունակում է սեսիայի մակարդակի տեղեկատվություն, ինչպիսիք են մուտքանունը, հոսթի անունը և ծրագրի անվանումը։
• sys.dm_os_wait_stats: Տրամադրում է ամբողջ օրինակի համար կուտակային սպասման վիճակագրություն։
• sys.dm_exec_query_stats: Պարունակում է քեշավորված հարցումների ամփոփ արդյունավետության վիճակագրություն։
• sys.dm_io_virtual_file_stats: Վերադարձնում է տվյալների և գրանցամատյանների ֆայլերի մուտքի/ելքի վիճակագրությունը։
• sys.dm_exec_sql_text: Վերցնում է տրված sql_handle-ի կամ plan_handle-ի SQL տեքստը։
• sys.dm_exec_query_plan: Վերադարձնում է քեշավորված հարցման կատարման պլանը։

5.1.2 Գործընթացի տեղեկատվության նմուշային հարցումներ

Գործընթացների վահանակի ֆունկցիոնալությունը կրկնօրինակելու համար կարող եք հարցում կատարել՝

SELECT 
    s.session_id AS [Session ID],
    CASE WHEN s.is_user_process = 1 THEN 'Yes' ELSE 'No' END AS [User Process],
    s.login_name AS [Login],
    ISNULL(CAST(r.blocking_session_id AS VARCHAR), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), '') AS [Database],
    ISNULL(t.task_state, '') AS [Task State],
    ISNULL(r.command, '') AS [Command],
    r.cpu_time AS [CPU Time],
    r.total_elapsed_time AS [Elapsed Time],
    r.wait_time AS [Wait Time],
    r.wait_type AS [Wait Type],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

5.1.3 Սպասման վիճակագրության համար հարցումների նմուշներ

«Ռեսուրսների սպասումներ» վահանակին նման սպասման վիճակագրությունը տեսնելու համար՝

SELECT TOP 10
    wait_type AS [Wait Type],
    wait_time_ms / 1000.0 AS [Wait Time (sec)],
    waiting_tasks_count AS [Waiting Tasks],
    wait_time_ms / NULLIF(waiting_tasks_count, 0) AS [Avg Wait Time (ms)]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
    AND wait_type NOT LIKE '%IDLE%'
    AND wait_type NOT LIKE '%QUEUE%'
ORDER BY wait_time_ms DESC;

5.2 sp_WhoIsActive-ի օգտագործումը

sp_WhoIsActive-ը համայնքի կողմից ստեղծված հզոր պահեստավորված պրոցեդուրա է, որը մեկ արդյունքների հավաքածուում տրամադրում է ավելի մանրամասն տեղեկատվություն, քան Activity Monitor-ը։

5.2.1 sp_WhoIsActive-ի տեղադրում

sp_WhoIsActive-ը տեղադրելու համար՝

1. Ներբեռնեք վերջին տարբերակը ՝ http://whoisactive.com.
2. Ներբեռնումը SQL սկրիպտ է, որը պարունակում է ընթացակարգի սահմանումը։
3. Բացեք սկրիպտը SQL Server Կառավարման ստուդիա.
4. Միացեք ձեր SQL Server օրինակ:
5. Կատարեք սկրիպտը՝ հիմնական տվյալների բազայում պրոցեդուրան ստեղծելու համար։
6. Տրամադրեք կատարման թույլտվություններ համապատասխան օգտատերերին։

Քանի որ sp_WhoIsActive-ը տեղադրված է master ֆայլում, այն հասանելի է ցանկացած տվյալների բազայի համատեքստից։

5.2.2 Հիմնական օգտագործման օրինակներ

sp_WhoIsActive-ն օգտագործելու ամենապարզ ձևը հետևյալն է.

EXEC sp_WhoIsActive;

Սա վերադարձնում է արդյունքների հավաքածու, որը ցույց է տալիս բոլոր ակտիվ սեսիաները՝ իրենց հարցումներով, սպասման տեսակներով, արգելափակման տեղեկատվությամբ և ռեսուրսների օգտագործմամբ։

Այդ ժամանակահատվածում ակտիվությունը ցույց տվող 10 վայրկյանանոց նմուշի համար՝

EXEC sp_WhoIsActive @delta_interval = 10;

Սա հաշվարկում է CPU-ի և կարդացած ցուցանիշների դելտաները՝ ցույց տալով, թե ինչ է տեղի ունեցել այդ 10 վայրկյանների ընթացքում։

5.2.3 Լրացուցիչ պարամետրեր

sp_WhoIsActive-ը աջակցում է բազմաթիվ պարամետրերի անհատականացման համար.

• @ֆիլտր: Զտեք արդյունքները ըստ որոշակի սեսիաների, տվյալների բազաների կամ մուտքերի։
• @filter_type: Նշեք, թե ինչի վրա է կիրառվում ֆիլտրը (սեսիա, տվյալների բազա, մուտք և այլն):
• @get_plans: Արդյունքներում ներառեք կատարման պլանները (սահմանեք 1):
• @get_locks: Ցուցադրել կողպեքի մանրամասն տեղեկատվությունը (սահմանված է 1-ի վրա):
• @get_transaction_info: Ցուցադրել գործարքի մանրամասները (սահմանված է 1-ի վրա):
• @sort_order: Դասավորեք արդյունքները տարբեր չափանիշներով (CPU, ընթերցումներ, տևողություն և այլն):
• @destination_table: Արդյունքները տեղադրեք աղյուսակում՝ պատմական հետևման համար։

Օրինակ՝ ցույց է տալիս CPU-ի կողմից տեսակավորված պլանները.

EXEC sp_WhoIsActive 
    @get_plans = 1,
    @sort_order = '[CPU] DESC';

5.3 Համակարգում պահված ընթացակարգերի օգտագործումը

SQL Server ներառում է գործունեության մոնիթորինգի ավանդական պահեստավորված ընթացակարգեր, չնայած դրանք ավելի քիչ տեղեկատվություն են տրամադրում, քան DMV-ները կամ Activity Monitor-ը։

5.3.1 sp_who և sp_who2

sp_who պրոցեդուրան ցույց է տալիս սեսիայի հիմնական տեղեկատվությունը.

EXEC sp_who;

sp_who2 պրոցեդուրան մի փոքր ավելի մանրամասն տեղեկություններ է տրամադրում.

EXEC sp_who2;

Երկու ընթացակարգերն էլ ցույց են տալիս սեսիայի ID-ները, մուտքի անունները, CPU-ի ժամանակը և արգելափակման մասին տեղեկությունները: Այնուամենայնիվ, դրանք չունեն DMV-ների կամ Activity Monitor-ի միջոցով հասանելի հարուստ մանրամասները: Դրանք առավել օգտակար են արագ ստուգումների համար, երբ ձեզ անհրաժեշտ է նվազագույն տեղեկատվություն:

5.3.2 Համակարգի այլ օգտակար ընթացակարգեր

Մոնիտորինգի համար նախատեսված լրացուցիչ համակարգային ընթացակարգերը ներառում են.

• sp_lock: Ցուցադրում է կողպեքի տեղեկատվությունը (հնացած է, փոխարենը օգտագործեք sys.dm_tran_locks-ը):
• sp_մոնիթոր: Ցուցադրում է վիճակագրությունը SQL Server գործունեությունը:
• sp_help: Ցույց է տալիս օբյեկտների սահմանումները և մետատվյալները։
• DBCC SQLPERF: Ցուցադրում է գործարքների գրանցամատյանի տարածքի օգտագործումը և սպասման վիճակագրությունը։

5.4 Պատվերով մոնիթորինգի սկրիպտների ստեղծում

Activity Monitor-ի կողմից տրամադրվողից բացի հատուկ մոնիթորինգ պահանջող միջավայրերի համար կարող եք ստեղծել հատուկ լուծումներ՝ օգտագործելով DMV-ներ։

5.4.1 Ամբողջական ակտիվության մոնիտորի համարժեք սկրիպտ

Ահա համապարփակ սկրիպտ, որը կրկնօրինակում է Activity Monitor-ի գործառույթների մեծ մասը.

-- Processes Information
SELECT 
    s.session_id AS [Session ID],
    CONVERT(CHAR(1), s.is_user_process) AS [User Process],
    s.login_name AS [Login],
    ISNULL(CONVERT(VARCHAR, w.blocking_session_id), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), N'') AS [Database],
    ISNULL(t.task_state, N'') AS [Task State],
    ISNULL(r.command, N'') AS [Command],
    SUBSTRING(st.text, (r.statement_start_offset/2) + 1,
        ((CASE r.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE r.statement_end_offset 
        END - r.statement_start_offset) / 2) + 1) AS [Statement],
    st.text AS [Command Text],
    r.cpu_time AS [CPU Time (ms)],
    r.total_elapsed_time / 1000 AS [Elapsed Time (sec)],
    r.wait_time AS [Wait Time (ms)],
    r.wait_type AS [Wait Type],
    r.wait_resource AS [Wait Resource],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    c.client_net_address AS [Net Address],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests w ON r.session_id = w.blocking_session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id 
    AND r.request_id = t.request_id
LEFT JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

-- Recent Expensive Queries
SELECT TOP 20
    qs.execution_count / 
        DATEDIFF(MINUTE, qs.creation_time, GETDATE()) AS [Executions/min],
    qs.total_worker_time / 1000 AS [CPU Time (ms)],
    qs.total_physical_reads AS [Physical Reads],
    qs.total_logical_writes AS [Logical Writes],
    qs.total_logical_reads AS [Logical Reads],
    qs.total_elapsed_time / qs.execution_count / 1000 AS [Avg Duration (ms)],
    SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
        ((CASE qs.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE qs.statement_end_offset 
        END - qs.statement_start_offset) / 2) + 1) AS [Query Text]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE qs.execution_count > 0
ORDER BY qs.total_worker_time DESC;

5.4.2 SQL Agent Jobs-ի միջոցով մոնիթորինգի ավտոմատացում

Դուք կարող եք պլանավորել հատուկ մոնիթորինգի սկրիպտներ՝ օգտագործելով SQL Server Գործակալ:

1. Ստեղծեք աղյուսակ՝ մոնիտորինգի արդյունքները պահելու համար։
2. Փոփոխեք ձեր մոնիթորինգի սկրիպտը՝ արդյունքները այս աղյուսակում ներմուծելու համար։
3. In SQL Server Կառավարման ստուդիա, ընդլայնել SQL Server Գործակալ օբյեկտների հետազոտիչում։
4. Աջ - կտտացրեք Աշխատանք եւ ընտրել Նոր աշխատանք.
5. Կարգավորեք աշխատանքը՝ ձեր մոնիթորինգի սկրիպտը կանոնավոր ժամանակահատվածներում գործարկելու համար։
6. Ստեղծեք ահազանգեր կամ հաշվետվություններ՝ հիմնված հավաքված տվյալների վրա։

Այս մոտեցումը հնարավորություն է տալիս իրականացնել պատմական հետևում և միտումների վերլուծություն, որը Activity Monitor-ը չի տրամադրում։

6. Գործունեության մոնիտորի սահմանափակումներ և նկատառումներ

Թեև Activity Monitor-ը արժեքավոր է, դրա սահմանափակումները հասկանալը կօգնի ձեզ այն ճիշտ օգտագործել և անհրաժեշտության դեպքում լրացնել այլ գործիքներով։

6.1 Գործունեության մոնիտորի ծախսերի ըմբռնումը

Activity Monitor-ը անվճար չէ. այն սպառում է սերվերի ռեսուրսներ՝ տեղեկատվություն հավաքելու և ցուցադրելու համար: Այս ծախսի ըմբռնումը կօգնի ձեզ այն պատասխանատու կերպով օգտագործել:

6.1.1 Ազդեցությունը սերվերի ռեսուրսների վրա

Ակտիվության մոնիթորը ամեն անգամ թարմացնելիս հարցումներ է կատարում համակարգի DMV-ների նկատմամբ: Այս հարցումները սպառում են CPU, առաջացնում են տրամաբանական ընթերցումներ և կարող են կարճ ժամանակով արգելափակել համակարգի աղյուսակները: Ծանրաբեռնված սերվերների վրա այս ծանրաբեռնվածությունը կարող է ազդել աշխատանքի արդյունավետության վրա:

«Գործընթացներ» և «Վերջին թանկարժեք հարցումներ» վահանակները հատկապես թանկ են, քանի որ դրանք պետք է սկանավորեն պոտենցիալ մեծ DMV-ներ և քեշի աղյուսակներ: Հազարավոր քեշավորված հարցումների պլաններ ունեցող սերվերների վրա «Վերջին թանկարժեք հարցումների» թարմացումը կարող է տևել մի քանի վայրկյան:

Microsoft-ի փաստաթղթերը զգուշացնում են, որ 10 վայրկյանից պակաս թարմացման միջակայքերը կարող են զգալիորեն ազդել սերվերի աշխատանքի վրա, հատկապես արդեն բեռնված համակարգերի վրա։

6.1.2 Թարմացման միջակայքի լավագույն փորձը

Ընտրեք ձեր իրավիճակին համապատասխանող թարմացման ժամանակահատվածները՝

• 1-5 վայրկյան: Միայն թեթև ծանրաբեռնված սերվերների վրա կրիտիկական խնդիրների անհապաղ լուծման համար: Մի թողեք Activity Monitor-ը միացված այս ժամանակահատվածներում:
• 10 վայրկյան (լռելյայն): Հիմնավոր է խնդիրների լուծման և ընդհանուր մոնիթորինգի մեծ մասի համար։
• 30-60 վայրկյան: Ավելի լավ ընտրություն արտադրական սերվերների համար, որոնք գտնվում են ծանրաբեռնվածության տակ կամ երկար ժամանակահատվածում մոնիթորինգի են ենթարկվում։
• Միայն ձեռքով թարմացում՝ Այն դեպքերի համար, երբ դուք ցանկանում եք պարբերաբար ստուգել ընթացիկ վիճակը՝ առանց շարունակական հարցումների։

Հետաքննությունն ավարտելուց հետո միշտ փակեք Activity Monitor-ը։ Մի թողեք այն անընդհատ աշխատած, հատկապես տարբեր օգտատերերի կողմից մի քանի օրինակների դեպքում։

6.2 Սպասման տիպի խմբավորման խնդիրներ

Activity Monitor-ի սպասման դասակարգման մոտեցումը, միաժամանակ պարզեցնելով դիտումը, կարող է թաքցնել կարևոր ախտորոշիչ տեղեկատվությունը։

6.2.1 Ինչպես է Ակտիվության մոնիթորինգի խմբերը սպասում

SQL Server Հետևում է հարյուրավոր տարբեր սպասման տեսակների, որոնցից յուրաքանչյուրը ցույց է տալիս որոշակի ռեսուրս կամ պայման: Activity Monitor-ը դրանք խմբավորում է լայն կատեգորիաների, ինչպիսիք են՝ «Բուֆերի փակում», «Կողպում» և «Հիշողություն»:

Օրինակ, «Buffer Latch» կատեգորիան ներառում է PAGELATCH_SH, PAGELATCH_UP, PAGELATCH_EX և մի քանի այլ հատուկ սպասման տեսակներ։ Չնայած դրանք բոլորը կապված են էջին մուտք գործելու հետ, դրանք ունեն տարբեր պատճառներ և լուծումներ։

Microsoft-ը չի փաստաթղթավորում, թե որ սպասման տեսակները որ կատեգորիաներին են համապատասխանում, ինչը դժվարացնում է հասկանալը, թե իրականում ինչ եք տեսնում։

6.2.2 Բացակայող սպասման տեսակներ

Activity Monitor-ը չի ցուցադրում բոլոր սպասման տեսակները։ Առավել նկատելի է, որ այն հաճախ բաց է թողնում CXPACKET սպասման տվյալները, որոնք ցույց են տալիս զուգահեռ հարցումների կատարումը։ CXPACKET սպասման տվյալները տարածված են և սովորաբար խնդրահարույց չեն, բայց դրանց առկայությունը իմանալը կօգնի ձեզ հասկանալ աշխատանքային բեռնվածության բնութագրերը։

Երբ Activity Monitor-ը ցույց է տալիս «Buffer Latch»-ը որպես ձեր գլխավոր սպասման կետ, բայց մյուս գործիքները ցույց են տալիս CXPACKET-ի գերակշռությունը, անհամապատասխանությունը գալիս է Activity Monitor-ի ֆիլտրման և խմբավորման տրամաբանությունից։

6.2.3 Ինչու են սպասման որոշակի տեսակները կարևոր

Խնդիրների լուծման համար կարևոր է իմանալ սպասման կոնկրետ տեսակը.

• PAGELATCH_EX: Հաճախ ցույց է տալիս tempdb-ի վիճարկումը բաշխման էջերում: Լուծումը ներառում է ավելի շատ tempdb տվյալների ֆայլեր ավելացնելը:
• PAGELATCH_SH: Կարող է ցույց տալ օգտատերերի աղյուսակներում առկա թեժ էջեր։ Լուծումը ներառում է բաժանում կամ ինդեքսի վերակազմավորում։
• PAGELATCH_UP: Հաճախ է պատահում թարմացումների ժամանակ։ Կարող է ցույց տալ բնականոն աշխատանք, այլ ոչ թե խնդիր։

Activity Monitor-ը այս բոլորը խմբավորում է «Buffer Latch» տակ, ինչը դժվարացնում է ախտորոշումը: sp_WhoIsActive-ի և DMV հարցումների նման գործիքները ցույց են տալիս սպասման որոշակի տեսակներ:

6.3 Տվյալների ճշգրտություն և արդիականություն

Activity Monitor-ը տրամադրում է գրեթե իրական ժամանակի պատկեր, բայց «մոտ» բառն է գործառնական բառը։ Տվյալների հավաքագրման դրա մեթոդի ըմբռնումը կօգնի ձեզ ճիշտ մեկնաբանել արդյունքները։

6.3.1 Լուսանկար ընդդեմ շարունակական մոնիթորինգի

Ակտիվության մոնիտորը ցույց է տալիս յուրաքանչյուր թարմացման ժամանակահատվածում արված ժամանակային պատկերները: Պատկերների միջև տեղի ունեցող իրադարձությունները չեն գրանցվում: Եթե հարցումը կատարվում է 2 վայրկյան, և դուք թարմացնում եք յուրաքանչյուր 10 վայրկյանը մեկ, կարող եք այն տեսնել մեկ անգամ կամ ընդհանրապես չտեսնել՝ կախված ժամանակից:

Սա նշանակում է, որ Activity Monitor-ը գերազանց է կայուն խնդիրները գտնելու հարցում (երկարատև արգելափակում, մշտապես բարձր CPU), բայց կարող է բաց թողնել անցողիկ խնդիրները (կարճատև փակուղիներ, պարբերաբար հարցումների կտրուկ աճ):

6.3.2 Ագրեգացիա և նմուշառում

«Վերջին թանկարժեք հարցումներ» վահանակը ցույց է տալիս տվյալների ամփոփումը, որը ստացվել է քեշում հարցման պլանների մուտքագրման պահից։ Երկու նույնական հարցումներ՝ տարբեր պարամետրերի արժեքներով, հայտնվում են որպես մեկ տող, եթե դրանք կիսում են նույն պլանը։ Այս ամփոփումը կարող է քողարկել որոշակի պարամետրերի համակցությունների հետ կապված խնդիրները (պարամետրերի ընկալման խնդիրներ):

«Ռեսուրսների սպասման» վահանակը հաշվարկում է գները՝ համեմատելով լուսանկարները։ Եթե սպասման վիճակագրությունը վերակայվում է լուսանկարների միջև (հազվադեպ է, բայց հնարավոր է), հաշվարկված գները կարող են սխալ լինել։

6.4 Երբ չի կարելի օգտագործել ակտիվության մոնիթորինգը

Activity Monitor-ը հարմար չէ բոլոր մոնիթորինգի սցենարների համար: Ճանաչեք, թե երբ են այլընտրանքային գործիքներն ավելի լավ ընտրություններ:

6.4.1 Պատմական վերլուծության պահանջներ

Ակտիվության մոնիթորինգը ցույց է տալիս միայն ընթացիկ կամ վերջին ակտիվությունը։ Այն չի պահպանում պատմական տվյալները։ Եթե անհրաժեշտ է վերլուծել միտումները օրերի կամ շաբաթների ընթացքում, համեմատել ընթացիկ կատարողականը բազային ցուցանիշների հետ կամ ստեղծել հաշվետվություններ կատարողականի օրինաչափությունների վերաբերյալ, Ակտիվության մոնիթորինգը բավարար չէ։

Պատմական վերլուծության համար օգտագործեք SQL Server-ի ներկառուցված կատարողականի վահանակ, ֆայլերի թիրախներով ընդլայնված իրադարձություններ կամ երրորդ կողմի մոնիթորինգի լուծումներ։

6.4.2 Մանրամասն սպասման վիճակագրության կարիքներ

Երբ ձեզ անհրաժեշտ է ճշգրիտ սպասման տեսակի տեղեկատվություն առաջադեմ կարգավորման համար, Activity Monitor-ի խմբավորումը և զտումը այն դարձնում են անբավարար: Օգտագործեք DMV հարցումները անմիջապես կամ sp_WhoIsActive-ը փոխարենը:

Համապարփակ սպասման վիճակագրության վերլուծության համար ուղղակիորեն հարցում ուղարկեք sys.dm_os_wait_stats ֆայլին և ձեռքով զտեք անբարենպաստ սպասումները։

6.4.3 Արտադրական սերվերի նկատառումներ

Արտադրական սերվերների վրա, որոնք ծանրաբեռնված են մեծ ծանրաբեռնվածությամբ, Activity Monitor-ի վերադիր ծախսերը կարող են խնդրահարույց լինել: Մի քանի տվյալների բազայի ադմինիստրատորներ չպետք է միաժամանակ աշխատեցնեն Activity Monitor-ը նույն սերվերի վրա:

Արտադրության մոնիթորինգի համար դիտարկեք թեթև այլընտրանքներ, ինչպիսիք են մոնիթորինգի տվյալների բազայում պահվող DMV-ի պլանավորված լուսանկարները, կամ օգտագործեք միայն ընթերցման երթուղին՝ Always On կոնֆիգուրացիաներում երկրորդական պատճենները մոնիթորինգի ենթարկելու համար։

7. Ակտիվության մոնիթորինգի օգտագործման լավագույն մեթոդները

Լավագույն փորձին հետևելը ապահովում է, որ դուք առավելագույն օգուտ ստանաք Activity Monitor-ից՝ միաժամանակ նվազագույնի հասցնելով ձեր սերվերների վրա բացասական ազդեցությունը։

7.1 Ե՞րբ օգտագործել Ակտիվության մոնիթորինգը

Activity Monitor-ը հիանալի է որոշակի իրավիճակներում: Օգտագործեք այն, երբ դրա ուժեղ կողմերը համընկնում են ձեր կարիքների հետ:

7.1.1 Իրական ժամանակի կատարողականի խնդիրներ

Ակտիվության մոնիթորինգը իդեալական է, երբ օգտատերերը ներկայումս խնդիրներ են ունենում, և դուք պետք է անմիջապես ախտորոշեք խնդիրը: Իրական ժամանակի դիտումը օգնում է ձեզ տեսնել, թե ինչ է կատարվում հենց հիմա:

Երբ զանգ եք ստանում, որ «հավելվածը դանդաղ է», Activity Monitor-ը բացելը պետք է լինի ձեր առաջին քայլերից մեկը: Դուք կարող եք արագ որոշել, թե արդյոք տվյալների բազան զբաղված է, արգելափակված է, թե անգործուն է:

7.1.2 Դիմումի դանդաղեցման հետաքննություն

Երբ որևէ կոնկրետ ծրագիր չի արձագանքում, Activity Monitor-ը օգնում է ձեզ որոշել, թե արդյոք տվյալների բազայի հետ կապված խնդիրներն են պատճառը։ Զտեք «Գործընթացներ» վահանակը ծրագրի անվանմամբ՝ տեսնելու միայն այդ ծրագրի տվյալների բազայի ակտիվությունը։

Եթե ​​օգտատերերի կողմից խնդիրների մասին հաղորդելու ընթացքում հավելվածը տվյալների բազայի ակտիվություն չի ցուցաբերում, ապա խնդիրը գտնվում է այլ տեղում։ Եթե տեսնում եք լայնածավալ արգելափակումներ կամ թանկարժեք հարցումներ, ապա գտել եք ձեր մեղավորին։

7.1.3 Արագ առողջության ստուգումներ

Ակտիվության մոնիթորը հիանալի վահանակ է տրամադրում արագ առողջության ստուգման համար՝ ռեժիմային կառավարման ընթացքում: Բացեք այն, նայեք ընդհանուր գրաֆիկներին և համոզվեք, որ ոչինչ աննորմալ չի թվում:

Այս մակերեսային ստուգումը տևում է վայրկյաններ և կարող է բացահայտել խնդիրները, նախքան դրանք լուրջ դառնան։ Դարձրեք այն ձեր առօրյայի մաս։

7.2 Օպտիմալ կոնֆիգուրացիայի կարգավորումներ

Activity Monitor-ի պատշաճ կերպով կարգաբերումը բարելավում է ինչպես դրա օգտակարությունը, այնպես էլ ռեսուրսային հետքը։

7.2.1 Առաջարկվող թարմացման միջակայքեր

Համապատասխանեցրեք թարմացման միջակայքը ձեր նպատակին.

• Ակտիվ խնդիրների լուծում. 10 վայրկյանը ապահովում է լավ արձագանքունակություն՝ ողջամիտ ծանրաբեռնվածությամբ։
• Ընդլայնված մոնիթորինգ. 30-60 վայրկյանը նվազեցնում է սերվերի ազդեցությունը երկար դիտարկման ժամանակահատվածներում։
• Կրիտիկական խնդրի ախտորոշում. 5 վայրկյանը տալիս է բարձր ճշգրտություն, երբ յուրաքանչյուր վայրկյանը հաշվվում է, բայց օգտագործեք կարճ ժամանակով։
• Կանոնավոր առողջական ստուգումներ. Ձեռքով թարմացում (1 ժամյա ընդմիջումով), երբ ակտիվորեն չեք դիտում։

Ավարտելուց հետո մի մոռացեք փակել Activity Monitor-ը: Այն երկար ժամանակահատվածում սահմանելը և դրա մասին մոռանալը վատնում է սերվերի ռեսուրսները:

7.2.2 Ֆիլտրացման ռազմավարություններ

Օգտագործեք ֆիլտրեր՝ համապատասխան տեղեկատվության վրա կենտրոնանալու և ճանաչողական բեռը նվազեցնելու համար։

• Ֆիլտրել գործընթացները ըստ Database տեսնելու միայն որոշակի տվյալների բազաների նկատմամբ գործունեությունը։
• Զտել ըստ Մուտք որոշակի օգտատիրոջ գործունեությունը հետևելու համար։
• Զտել ըստ Առաջադրանքի վիճակ = Գործարկվում է՝ չգործող նիստերը թաքցնելու համար։
• Զտել ըստ դիմում երթևեկությունը որոշակի ծրագրերից մեկուսացնելու համար։
• Ցուցադրել միայն ոչ դատարկները Արգելափակված է տեսնել միայն խոչընդոտող իրավիճակները։

7.2.3 Սյունակների ընտրություն և տեսակավորում

Մշակեք Activity Monitor-ի տվյալների վերանայման համակարգված մոտեցում.

1. Սկսեք ակնարկից. Ստուգեք գրաֆիկները՝ ակնհայտ թռիչքների կամ անոմալիաների առկայության համար։
2. Ստուգեք արգելափակման գործընթացները. Դասավորեք ըստ սեսիայի ID-ի, այնուհետև փնտրեք «Blocked By» արժեքները։
3. Վերանայեք ռեսուրսների սպասման ժամանակը. Դասավորեք կուտակային սպասման ժամանակով՝ ռեսուրսների խցանումները բացահայտելու համար։
4. Վերլուծեք թանկարժեք հարցումները. Դասավորեք տարբեր չափանիշներով (CPU, կատարումներ, ընթերցումներ)՝ տարբեր տեսակի խնդիրներ գտնելու համար։
5. Հաստատել I/O վահանակի միջոցով՝ Հաստատեք, թե արդյոք I/O ինտենսիվ հարցումները կապված են սկավառակի բարձր ակտիվության հետ։

7.3 Ինտեգրացիա այլ գործիքների հետ

Activity Monitor-ը լավագույնս աշխատում է որպես ավելի լայն գործիքակազմի մաս, քան որպես առանձին լուծում։

7.3.1 Օգտագործումը SQL Server Պրոֆիլավոր

Ակտիվության մոնիտոր և SQL Server Profiler-ները լավ են լրացնում միմյանց։ Երբ Activity Monitor-ում խնդրահարույց սեսիա եք նկատում, սեղմեք դրա վրա աջ կոճակով և ընտրեք Հետևման գործընթաց SQL Server Պրոֆիլավոր.

Սա գործարկում է Profiler-ը՝ արդեն կարգավորված ֆիլտրերով, որոնք գրանցում են միայն այդ սեսիայի ակտիվությունը: Դուք տեսնում եք կատարված հրամանների ամբողջական հաջորդականությունը, ժամանակի տեղեկատվությունը և սխալի հաղորդագրությունները՝ մանրամասներ, որոնք Activity Monitor-ը չի տրամադրում:

Ավելին իմանալ այն մասին SQL Server Պրոֆիլերի հնարավորություններ և առաջադեմ հետևողականության տեխնիկա, տե՛ս մեր համապարփակ SQL Server Պրոֆիլերի ուղեցույց.

7.3.2 Լրացում ընդլայնված իրադարձություններով

«Ընդլայնված իրադարձություններ» գործառույթը առաջարկում է ցածր ծախսերով, մանրամասն մոնիթորինգ, որը գրանցում է Activity Monitor-ի կողմից բաց թողնված տեղեկատվությունը: Ստեղծեք «Ընդլայնված իրադարձություններ» աշխատաշրջաններ՝ հետևելու որոշակի իրադարձությունների, ինչպիսիք են փակուղիները, երկարատև հարցումները կամ չափազանց շատ վերակազմակերպումները, հետևելու համար:

Օգտագործեք Activity Monitor-ը անհապաղ հետաքննության համար, իսկ Extended Events-ը՝ շարունակական մոնիթորինգի և պատմական վերլուծության համար: Երկու գործիքներն էլ լուծում են տարբեր կարիքներ:

Ավելին իմանալ այն մասին SQL Server Միջոցառումների ընդլայնված հնարավորություններ և առաջադեմ մոնիթորինգի տեխնիկա, տե՛ս մեր համապարփակ SQL Server Ընդլայնված միջոցառումների ուղեցույց.

7.3.3 Երրորդ կողմի մոնիթորինգի լուծումներ

SolarWinds Database Performance Analyzer-ի, Redgate SQL Monitor-ի և Quest Spotlight-ի նման առևտրային գործիքները տրամադրում են այնպիսի հնարավորություններ, որոնք Activity Monitor-ին բացակայում են՝ ահազանգում, պատմական միտումներ, հզորությունների պլանավորում և ավտոմատացված ախտորոշում։

Այս գործիքները Activity Monitor-ի արժեքավոր լրացումներ են, այլ ոչ թե փոխարինողներ: Activity Monitor-ը շարունակում է օգտակար լինել արագ ստուգումների և հետաքննությունների համար, նույնիսկ երբ հասանելի են բարդ մոնիթորինգի գործիքներ:

7.4 սովորական սխալներ, որոնցից պետք է խուսափել

Գործունեության մոնիտորի տարածված սխալների ըմբռնումը կօգնի ձեզ այն ավելի արդյունավետ օգտագործել։

7.4.1 Ակտիվության մոնիտորի անընդհատ աշխատեցում

Ամենատարածված սխալը Activity Monitor-ը բացելն ու անորոշ ժամանակով աշխատեցնելը թողնելն է։ Սա վատնում է սերվերի ռեսուրսները և քիչ արժեք է տալիս, քանի որ դուք ակտիվորեն չեք հետևում։

Փակեք Activity Monitor-ը, երբ այն ակտիվորեն չեք օգտագործում: Եթե ձեզ անհրաժեշտ է շարունակական մոնիթորինգ, փոխարենը կիրառեք համապատասխան մոնիթորինգի լուծում՝ տվյալների հավաքագրման ժամանակացույցով:

7.4.2 Միայն Activity Monitor-ի վրա չափազանց մեծ հույս դնելը

Activity Monitor-ը սերվերի վիճակի վերաբերյալ մեկ տեսանկյուն է տրամադրում: Մի՛ հույսը դրեք միայն դրա վրա: Լրացրեք Windows Performance Monitor-ով՝ օպերացիոն համակարգի մակարդակի չափանիշների համար, Extended Events-ով՝ մանրամասն հետևման համար, և կատարման պլանի վերլուծության համար՝ հարցումների կարգավորման համար:

Activity Monitor-ը օգնում է ձեզ բացահայտել խնդիրները, սակայն դրանց լուծումը հաճախ պահանջում է լրացուցիչ գործիքներ և ավելի խորը վերլուծություն։

Իմացեք ավելին SQL Server կատարողականի մոնիտոր մեր մեջ ամբողջական ուղեցույց.

7.4.3 Պատմական միտումների անտեսում

Ակտիվության մոնիթորը ցույց է տալիս ընթացիկ վիճակը, սակայն կատարողականի հետ կապված խնդիրները հաճախ ունենում են օրինաչափություններ, որոնք տեսանելի են միայն ժամանակի ընթացքում: Կիրառեք պատմական տվյալների հավաքագրում, որպեսզի կարողանաք համեմատել ընթացիկ չափանիշները բազային ցուցանիշների հետ և բացահայտել միտումները:

Առանց պատմական համատեքստի, դուք կարող է չնկատեք, որ այսօրվա «նորմալ» պրոցեսորի օգտագործումը 30%-ով ավելի բարձր է, քան անցյալ ամսվա սկզբնական ցուցանիշը, ինչը վկայում է աստիճանական վատթարացման մասին։

8. Ակտիվության մոնիտորի խնդիրների լուծում

Activity Monitor-ը երբեմն խնդիրներ է ունենում։ Այս խնդիրները լուծելու եղանակները իմանալը կանխում է հիասթափությունը։

8.1 Ակտիվության մոնիտորը չի բացվում կամ տվյալներ չի ցուցադրում

Երբ Activity Monitor-ը բացվում է, բայց ցուցադրում է դատարկ վահանակներ կամ ընդհանրապես չի բացվում, դրա պատճառը կարող են լինել մի քանի գործոններ։

8.1.1 Թույլտվությունների հետ կապված խնդիրներ

Ակտիվության մոնիտորի խնդիրների ամենատարածված պատճառը անբավարար թույլտվություններն են: Ստուգելու և լուծելու համար՝

1. Ստուգեք ձեր սերվերի մակարդակի թույլտվությունները.

   SELECT * FROM fn_my_permissions(NULL, 'SERVER')
   WHERE permission_name = 'VIEW SERVER STATE';
   

2. Եթե ​​տողեր չեն վերադարձվում, ապա դուք չունեք VIEW SERVER STATE թույլտվությունը։
3. Խնդրեք սերվերի ադմինիստրատորին թույլատրել այն՝

   USE master;
   GRANT VIEW SERVER STATE TO [YourLogin];
   

4. Թույլտվություններ տրամադրելուց հետո փակեք և վերաբացեք Activity Monitor-ը։

8.1.2 Տարբերակների համատեղելիության խնդիրներ

Օգտագործելով հին տարբերակը SQL Server Management Studio-ն՝ ավելի նորին միանալու համար SQL Server տարբերակը կարող է առաջացնել Activity Monitor-ի խափանումներ: Գործիքը կարող է չհասկանալ նոր սպասման տեսակները կամ համակարգի դիտման սյուները:

Միշտ օգտագործեք SSMS տարբերակը, որը համապատասխանում է կամ ավելի նոր է, քան ձեր տարբերակը։ SQL Server տարբերակ։ Microsoft-ը տրամադրում է SSMS-ի վերջին տարբերակը որպես անվճար ներբեռնում՝ առանձին SQL Server ինքն իրեն.

8.1.3 Firewall-ի և ցանցի խնդիրներ

Ակտիվության մոնիթորը պահանջում է միացում SQL Server օրինակ ստանդարտ միացքների վրա (1433 ըստ լռելյայնի): Եթե կարող եք միանալ Object Explorer-ի միջոցով, բայց Activity Monitor-ը չի աշխատում, ապա firewall-ի կանոնները կարող են արգելափակել որոշակի միացումներ:

Ստուգեք, որ ձեր հաճախորդը կարող է կապ հաստատել SQL Server Միացրեք մեքենան բոլոր անհրաժեշտ միացքների վրա: Ստուգեք և՛ Windows Firewall-ը, և՛ ձեր հաճախորդի և սերվերի միջև առկա ցանցային firewall-ները:

8.2 Ակտիվության մոնիթորը մշտապես դադարեցված է

Տարածված խնդիր, մասնավորապես՝ SQL Server 2019 թվական, Ակտիվության մոնիտորը բացվում է դադարեցված վիճակում և հրաժարվում է վերսկսել։

8.2.1 Դադարեցված վիճակի հասկացումը

Երբ Ակտիվության մոնիտորը դադարեցվում է, բոլոր վահանակները ցուցադրում են «Դադարեցված» կարգավիճակը՝ վերսկսման կոճակով, որը կարող է չաշխատել: Սա թույլ չի տալիս տեսնել սերվերի որևէ գործունեություն:

Դադարեցված վիճակը սովորաբար տեղի է ունենում թույլտվության խնդիրների, հեռակա կապի սահմանափակումների կամ SSMS տարբերակի սխալների պատճառով, այլ ոչ թե միտումնավոր դադարեցման գործողության։

8.2.2 Ընդհանուր պատճառներ

Ակտիվության մոնիտորը կարող է մտնել մշտական ​​​​դադարի վիճակի հետևյալ պատճառներով՝

• Վերջերս ավելացված նոր վահանակներում բացակայում է VIEW SERVER STATE թույլտվությունը SQL Server տարբերակները
• Հեռակա կապերը անջատված են SQL Server օրինակ
• Համակարգի որոշակի հարցումների համար նույնականացման ձախողումներ
• Սխալներ SSMS-ի որոշակի տարբերակներում, մասնավորապես 18.0-ից մինչև 18.3
• Հաճախորդի և սերվերի միջև կապի խնդիրներ

8.2.3 Լուծման քայլեր

Ակտիվության մոնիտորի դադարեցված վիճակի հետ կապված խնդիրները լուծելու համար՝

1. SSMS-ի թարմացում՝ Ներբեռնեք եւ տեղադրել վերջինը SQL Server Management Studio-ի տարբերակը Microsoft-ի կայքից։ Կասեցված վիճակի բազմաթիվ սխալներ շտկվել են հետագա թողարկումներում։
2. Հաստատեք թույլտվությունները՝ Համոզվեք, որ ունեք VIEW SERVER STATE և VIEW ANY DEFINITION թույլտվությունները:
3. Ստուգեք հեռակա կապերը. Ստուգեք, որ SQL Server օրինակը թույլ է տալիս հեռակա կապեր՝

   EXEC sp_configure 'remote access';
   

   Եթե ​​արժեքը 0 է, խնդրեք ադմինիստրատորին միացնել այն։

4. Վերագործարկեք SSMS-ը։ Երբեմն պարզապես փակեք բոլոր պատուհանները և վերագործարկեք SQL Server Management Studio-ն լուծում է խնդիրը։
5. Միացեք Windows Authentication-ի միջոցով՝ Եթե ​​օգտագործում եք SQL նույնականացում, փորձեք Windows նույնականացումը, քանի որ այն երբեմն շրջանցում է նույնականացման հետ կապված դադարեցման խնդիրները։

8.3 Արդյունավետության խնդիրներ Ակտիվության մոնիթորինգի օգտագործման ժամանակ

Եթե ​​Activity Monitor-ը ինքնին դանդաղում է կամ հանգեցնում է սերվերի աշխատանքի վատթարացման, անհրաժեշտ է կատարել կարգավորումներ։

8.3.1 Մոնիթորինգի ծախսերի կրճատում

Ակտիվության մոնիտորի ազդեցությունը նվազագույնի հասցնելու համար՝

1. Թարմացման միջակայքը մեծացրեք մինչև 30 վայրկյան կամ 1 րոպե։
2. Փակեք այն վահանակները, որոնք ակտիվորեն չեք օգտագործում՝ սեղմելով «փակել» կոճակը։
3. Երբ վահանակները ծալված են, Activity Monitor-ը տվյալներ չի հարցնում դրանց համար։
4. Խուսափեք միաժամանակ մի քանի Activity Monitor օրինակներ աշխատեցնելուց։
5. Ամբողջությամբ փակեք Activity Monitor-ը, երբ ակտիվորեն չեք ուսումնասիրում խնդիրները։

8.3.2 Թեթև քաշի մոնիթորինգի այլընտրանքային մեթոդներ

Եթե ​​Activity Monitor-ը չափազանց ռեսուրսատար է ձեր միջավայրի համար, դիտարկեք այլընտրանքային տարբերակները.

• Հարցում ուղարկեք DMV-ներին անմիջապես՝ Գրեք T-SQL հարցումներ, որոնք կստանան միայն ձեզ անհրաժեշտ տեղեկատվությունը։
• Օգտագործեք sp_WhoIsActive-ը։ Այս պահված պրոցեդուրան բարձր օպտիմիզացված է և սովորաբար ավելի քիչ ծախսեր ունի, քան Activity Monitor-ը։
• Նմուշառման իրականացում՝ Պլանավորեք SQL Agent-ի աշխատանքներ, որոնք կանոնավոր ժամանակահատվածներում գրանցում են DMV տվյալների ակնթարթային պատկերներ, պահպանելով արդյունքները աղյուսակներում՝ հետագա վերլուծության համար։
• Հետևեք երկրորդական կրկնօրինակներին՝ In Միշտ հասանելի խմբեր, գործարկեք Activity Monitor-ը ընթեռնելի երկրորդայինի նկատմամբ, այլ ոչ թե հիմնականի։

8.4 Անճշտ կամ բացակայող տեղեկատվություն

Երբեմն Activity Monitor-ը ցուցադրում է սխալ կամ թերի տեղեկատվություն։

8.4.1 Տվյալների ստուգում DMV-ների հետ

Երբ Activity Monitor-ի արդյունքները կասկածելի են թվում, ստուգեք դրանք՝ ուղղակիորեն հարցում ուղարկելով հիմքում ընկած DMV-ներին: Օրինակ, եթե «Գործընթացներ» վահանակը ցույց է տալիս, որ արգելափակում չկա, բայց օգտատերերը հայտնում են դրա մասին, հարցում կատարեք՝

SELECT 
    blocking_session_id,
    session_id,
    wait_type,
    wait_time,
    wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id != 0;

Եթե ​​այս հարցումը ցույց է տալիս արգելափակում, որը բաց է թողել Activity Monitor-ը, ապա դուք հաստատել եք էկրանի խնդիր։

8.4.2 Տվյալների թարմացման ժամանակի հասկացումը

Հիշե՛ք, որ Activity Monitor-ը ցույց է տալիս snapshot-ներ: Թարմացման միջակայքերում կատարված հարցումը չի հայտնվի «Վերջին թանկարժեք հարցումներ»-ում, եթե դրա կատարման պլանը չի մնում քեշում:

Նմանապես, «Ռեսուրսների սպասումներ» վահանակում սպասման վիճակագրությունը արտացոլում է վերջին լուսանկարից ի վեր կուտակված տվյալները: Արագ փոփոխվող աշխատանքային բեռները կարող են տարբեր օրինաչափություններ ցույց տալ յուրաքանչյուր թարմացման ժամանակ:

9. Ակտիվության մոնիթորինգի առաջադեմ մեթոդներ

Փորձառու տվյալների բազայի ադմինիստրատորները Activity Monitor-ը օգտագործում են բարդ եղանակներով՝ ախտորոշիչ առավելագույն արժեք ստանալու համար։

9.1 Արմատական ​​պատճառի վերլուծության համար մի քանի վահանակների համադրություն

Activity Monitor-ի իրական հզորությունը ի հայտ է գալիս, երբ դուք համադրում եք տեղեկատվությունը բազմաթիվ վահանակների միջև՝ բարդ կատարողականության խնդիրները հասկանալու համար։

9.1.1 Սպասումների և գործընթացների փոխկապակցումը

Երբ «Ռեսուրսների սպասումներ» վահանակը որևէ կատեգորիայում ցույց է տալիս մեծ սպասման ժամանակ, օգտագործեք «Գործընթացներ» վահանակը՝ որոշելու համար, թե որ նիստերն են ունենում այդ սպասման ժամանակը։

1. Ուշադրություն դարձրեք սպասման կատեգորիային, որն ունի բարձր կուտակային սպասման ժամանակ (օրինակ՝ «Կողպել»):
2. Անցնել «Գործընթացներ» վահանակին։
3. Դասավորել ըստ Սպասման տեսակը խմբավորել նիստերը ըստ իրենց ընթացիկ սպասման ժամանակի։
4. Փնտրեք խնդրահարույց կատեգորիայի սպասման տեսակները ցուցադրող սեսիաներ։
5. Այդ նիստերի համար ուսումնասիրեք՝ Սպասման ռեսուրս սյունակ՝ տեսնելու համար, թե որ տվյալների բազայի օբյեկտներն են ներգրավված։
6. Աջ սեղմեք և ընտրեք Մանրամասներ հարցման տեքստը տեսնելու համար։

Այս համադրությունը օգնում է ձեզ անցնել «մենք ունենք կողպեքի սպասումներ» տարբերակից դեպի «այս կոնկրետ հարցումը սպասում է կողպեքների այս աղյուսակում»։

9.1.2 Թանկարժեք հարցումների կապը մուտքի/ելքի խնդիրների հետ

Երբ «Տվյալների ֆայլի մուտք/ելք» վահանակը ցույց է տալիս սկավառակի բարձր ակտիվություն որոշակի տվյալների բազայում՝

1. Ուշադրություն դարձրեք, թե որ տվյալների բազայի ֆայլերն ունեն բարձր ՄԲ/վրկ ընթերցման կամ գրելու արագություն։
2. Անցնել վերջին թանկարժեք հարցումներին։
3. Դասավորել ըստ Ֆիզիկական ընթերցումներ/վրկ սկավառակից մեծ քանակությամբ կարդացվող հարցումները նույնականացնելու համար։
4. Զտեք կամ տեսողականորեն նույնականացրեք բարձր մուտք/ելք ունեցող տվյալների բազայի հետ աշխատող հարցումները։
5. Ուսումնասիրեք այդ հարցումների կատարման պլանները՝ աղյուսակների սկանավորման կամ բացակայող ինդեքսների առկայության համար, որոնք առաջացնում են չափազանց շատ մուտք/ելք։

Այս բազմա-վահանակային վերլուծությունը կապում է ախտանիշները (սկավառակի բարձր մուտք/ելք) պատճառների հետ (կոնկրետ անարդյունավետ հարցումներ):

9.2 Գործունեության մոնիթորինգի օգտագործումը կարողությունների պլանավորման համար

Չնայած Activity Monitor-ը չի պահպանում պատմական տվյալներ, դուք կարող եք այն ռազմավարականորեն օգտագործել կարողությունների պլանավորման դիտարկումների համար։

9.2.1 Պիկ օգտագործման օրինաչափությունների բացահայտում

Վերահսկեք սերվերի ակտիվությունը օրվա տարբեր ժամերին՝ օգտագործման օրինաչափությունները բացահայտելու համար.

1. Բացեք Ակտիվության մոնիտորը հայտնի գագաթնակետային աշխատանքային ժամերին։
2. Ուշադրություն դարձրեք պրոցեսորի ժամանակի տոկոսային գրաֆիկի գագաթնակետային արժեքներին։
3. Գրանցեք սպասող առաջադրանքների առավելագույն քանակը։
4. Դիտարկեք խմբաքանակի հարցումները/վրկ գագաթնակետային ժամերին։
5. Փաստաթղթավորեք ամենածանրաբեռնված տվյալների բազաները «Գործընթացներ» վահանակում։
6. Կրկնեք ոչ գագաթնակետային ժամերին համեմատության համար։

Եթե ​​գագաթնակետային ժամերին պրոցեսորի աշխատանքային ժամանակը մշտապես գերազանցում է 80%-ը, ապա դուք մոտենում եք պրոցեսորի հզորության սահմաններին: Նմանապես, սպասման քանակի աճը վկայում է ռեսուրսների նկատմամբ աճող պահանջարկի մասին:

9.2.2 Ռեսուրսների միտումների վերլուծություն

Թեև Activity Monitor-ը ցույց է տալիս ընթացիկ վիճակը, դուք կարող եք այն օգտագործել միտումները ստուգելու համար՝ ժամանակի ընթացքում գրանցելով հիմնական չափանիշները.

• Ամեն օր նույն ժամին արեք «Ընդհանուր տեսք» վահանակի էկրանի լուսանկարներ
• Գրանցեք գագաթնակետային արժեքները յուրաքանչյուր գրաֆիկից
• Համեմատեք շաբաթական ցուցանիշները՝ աճի միտումները բացահայտելու համար
• Հետևեք պրոցեսորի միջին ժամանակի կամ մուտքի/ելքի արագության աստիճանական աճին

Այս ձեռքով միտումների սահմանումը լրացնում է ավելի բարդ մոնիթորինգի լուծումները և օգնում է արդարացնել հզորությունների ընդլայնումը։

9.3 Արդյունավետության բազային ցուցանիշների փաստաթղթավորում

Հիմնական կատարողականի չափանիշների սահմանումը կօգնի ձեզ հասկանալ, թե երբ է կատարողականը վատանում։

9.3.1 Հիմնական չափանիշների գրանցում

Լավ ցուցանիշների հայտնի ժամանակահատվածներում փաստաթղթավորեք Activity Monitor-ի չափանիշները.

1. Բացեք Activity Monitor-ը սովորական գործունեության ընթացքում (ոչ թե գագաթնակետային կամ ոչ գագաթնակետային ժամերին):
2. Գրառումների ընդհանուր տեսքի վահանակի արժեքները՝
   • Պրոցեսորի ժամանակի տիպիկ % միջակայք
   • Սպասող առաջադրանքների միջին քանակը
   • Տվյալների բազայի մուտքի/ելքի նորմալ արագություն
   • Տիպիկ խմբաքանակային հարցումներ/վայրկյան
3. Ուշադրություն դարձրեք «Ռեսուրսների սպասման ժամանակ» վահանակի կատեգորիաներին, որոնք ցույց են տալիս ամենաշատ սպասման ժամանակը։
4. Փաստաթղթավորեք «Գործընթացներ» վահանակում սովորաբար ակտիվ գործընթացների քանակը։
5. Գրանցեք վերջին թանկարժեք հարցումների ներկայացուցչական հարցումների կատարման չափանիշները։

Պահպանեք այս բազային փաստաթղթերը ապագա հղումների համար՝ կատարողականի հետ կապված խնդիրները ուսումնասիրելիս։

9.3.2 Ընթացիկ և բազային ցուցանիշների համեմատություն

Երբ առաջանում են կատարողականության հետ կապված խնդիրներ, համեմատեք Activity Monitor-ի ընթացիկ ցուցանիշները ձեր փաստաթղթավորված բազային տվյալների հետ։

• Պրոցեսորի ժամանակը զգալիորեն ավելի՞ մեծ է, քան բազայինը։ Կենտրոնացեք պրոցեսորի վրա ինտենսիվորեն աշխատող հարցումների վրա։
• Սպասման առաջադրանքները բազային մակարդակից 2-3 անգամ ավելի՞ են։ Ուսումնասիրեք ռեսուրսների սպասման ժամանակը։
• Մուտք/ելք զգալիորեն բարձր է՞։ Ստուգեք տվյալների ֆայլի մուտք/ելք վահանակը և թանկարժեք հարցումները։
• Փաթեթային հարցումները պիկ ժամերին բազայինից ցածր են՞: Ուշադրություն դարձրեք արգելափակման կամ կապի խնդիրներին:

Այս համեմատությունը կօգնի ձեզ պարզել, թե ինչ է փոխվել և համապատասխանաբար կենտրոնացնել խնդիրների լուծման ջանքերը։

9.4 Անհատական ​​​​մոնիթորինգի աշխատանքային հոսքերի ստեղծում

Մշակել համակարգված աշխատանքային հոսքեր ընդհանուր հետաքննության սցենարների համար՝ մանրակրկիտ, կրկնվող վերլուծություն ապահովելու համար։

9.4.1 Քայլ առ քայլ հետաքննության գործընթաց

Երբ օգտատերերը հայտնում են կատարողականի հետ կապված խնդիրների մասին, հետևեք հետևողական աշխատանքային հոսքին.

1. Արագ առողջական ստուգում. Բացեք «Գործունեության մոնիտորը» և սկանավորեք «Ընդհանուր տեսք» վահանակի գրաֆիկները՝ ակնհայտ անոմալիաներ հայտնաբերելու համար։
2. Ստուգեք արգելափակման համար. Ընդարձակեք «Գործընթացներ» վահանակը, զտեք «Ոչ դատարկ» ֆայլերը «Արգելափակված է» սյունակում։
3. Ռեսուրսների միջև վեճի նույնականացում. Վերանայեք «Ռեսուրսների սպասման» վահանակը՝ տեսակավորված ըստ սպասման ժամանակի։
4. Գտեք թանկարժեք հարցումներ՝ Ուսումնասիրեք վերջին թանկարժեք հարցումները՝ տեսակավորված ըստ պրոցեսորի, ապա կատարումների, ապա ընթերցումների։
5. Կապակցեք մուտքի/ելքի օրինաչափությունները՝ Թանկարժեք հարցումների խաչաձև հղումներ տվյալների ֆայլերի մուտք/ելք վահանակի գործունեության հետ։
6. Փաստաթղթի եզրակացություններ. Կատարեք էկրանի լուսանկարներ և գրանցեք համապատասխան սեսիայի ID-ները, սպասման տեսակները և հարցման մանրամասները։
7. Խորը սուզվել: Օգտագործեք Profiler-ի հետքերը, կատարման պլանի վերլուծությունը և DMV հարցումները՝ հայտնաբերված խնդիրների մանրամասն ուսումնասիրության համար։

9.4.2 Էսկալացիայի չափանիշներ

Սահմանեք չափանիշներ, թե երբ է պետք խնդիրը սրել, թե երբ է պետք հետաքննությունը շարունակել.

• Անմիջապես սրեք իրավիճակը. Բլոկավորման շղթաները տևում են >5 րոպե, պրոցեսորի աշխատանքային ժամանակը 100%-ով աշխատում է >2 րոպե, համակարգի կրիտիկական պրոցեսները ցույց են տալիս ԿԱՍԵՑՎԱԾ վիճակ։
• Վերլուծության միջոցով արագացնել. Կրկնվող թանկարժեք հարցումներ, որոնք սպառում են >50% CPU, հաստատուն բարձր մուտքի/ելքի արձագանքման ժամանակներ՝ >50 մվ, հիշողության տրամադրման բազմիցս ձախողումներ։
• Հետաքննել ավելի մանրամասն. Ժամանակավոր սպասումներ, որոնք լուծվում են րոպեների ընթացքում, հարցումներ՝ ոչ օպտիմալ պլաններով, բայց ընդունելի արդյունավետությամբ, աննշան արգելափակումներ՝ <30 վայրկյան տևողությամբ։

10. Ակտիվության մոնիտոր տարբեր ձևերով SQL Server Versions

Ակտիվության մոնիտորը զարգացել է SQL Server տարբերակներ, որոնցից յուրաքանչյուրը բերում էր բարելավումներ և երբեմն նոր խնդիրներ։

10.1 Ակտիվության մոնիթոր SQL Server 2008 և ավելի ուշ

SQL Server 2008 թվականին ներկայացվեց ժամանակակից Activity Monitor դիզայնը, որը մեծ մասամբ անփոփոխ է մնում մինչ օրս։

10.1.1 Նոր հնարավորություններ, որոնք ներկայացվել են SQL Server 2008

  SQL Server 2008 թվականի Activity Monitor-ի վերաձևավորումը բերեց զգալի բարելավումներ.

• Գրաֆիկական վահանակ՝ իրական ժամանակի գրաֆիկներով «Ընդհանուր տեսք» վահանակում
• Ընդարձակվող/ծալվող վահանակի ինտերֆեյս, որը փոխարինում է հին միայն ցանցային տեսքը
• Վերջին թանկարժեք հարցումների վահանակը, որը ցույց է տալիս հարցումների ամփոփ կատարողականության տվյալները
• Տվյալների ֆայլերի մուտքի/ելքի վահանակ՝ սկավառակի ակտիվության մոնիթորինգի համար յուրաքանչյուր ֆայլի համար
• Բարելավված ռեսուրսների սպասման վահանակ՝ սպասման դասակարգմամբ
• Աջ սեղմեք համատեքստային մենյուների վրա՝ գործընթացային գործողությունների համար, ինչպիսիք են նիստերի փակումը և Profiler-ի գործարկումը
• Կարգավորելի թարմացման միջակայքեր 1 վայրկյանից մինչև 1 ժամ

Այս փոփոխությունները Activity Monitor-ը պարզ գործընթացների ցանկից վերածեցին համապարփակ մոնիթորինգի վահանակի։

10.1.2 Փոփոխություններ SQL Server 2005

SQL Server 2005 թվականի Activity Monitor-ը շատ ավելի սահմանափակ էր։

• Մուտքը կատարվում է Object Explorer-ի կառավարման թղթապանակի միջոցով, այլ ոչ թե գործիքագոտու միջոցով։
• Միակ ցանցը ցույց է տալիս գործընթացների ցանկը՝ հիմնական տեղեկատվությամբ
• Գրաֆիկական գծապատկերներ կամ բազմակի վահանակներ չկան
• Առանց թանկարժեք հարցումների կամ մուտքի/ելքի մոնիթորինգի
• Սահմանափակ սպասման վիճակագրության տեղեկատվություն

2008 թվականի վերաձևավորումը ներկայացնում էր ամբողջական վերաիմաստավորում, այլ ոչ թե աստիճանական բարելավում:

10.2 Ակտիվության մոնիթոր SQL Server 2014/2016

SQL Server 2014 և 2016 թվականներին Activity Monitor-ի տվյալների հավաքագրման մեջ կատարվեցին աստիճանական բարելավումներ, սակայն տեսողականորեն քիչ փոփոխություններ։

10.2.1 Բարելավումներ և բարելավումներ

Այս տարբերակների հիմնական բարելավումները ներառում էին.

• Ավելի լավ կատարողականություն՝ հազարավոր քեշավորված պլաններով սերվերների մոնիթորինգի ժամանակ
• Բարելավված ֆիլտրման հնարավորություններ «Գործընթացներ» վահանակում
• Սպասման վիճակագրության ագրեգացման ճշգրտության բարելավում
• Սյունակների տեսակավորման և զտման ավելի լավ կառավարում՝ մեծ արդյունքների հավաքածուներով
• Ավելի արդյունավետ DMV հարցումներ, որոնք նվազեցնում են մոնիթորինգի ծախսերը

Հիմնական ինտերֆեյսը մնաց համապատասխան SQL Server 2008 թվական՝ ադմինիստրատորների համար ծանոթության պահպանումը։

10.3 Ակտիվության մոնիթոր SQL Server 2019/2022

նոր SQL Server տարբերակները շարունակում են Activity Monitor-ի էվոլյուցիան՝ կենտրոնանալով կատարողականության և կայունության վրա։

10.3.1 Վերջին հնարավորություններն ու հնարավորությունները

SQL Server 2019 և 2022 թվականների գործունեության մոնիթորը ներառում է.

• Աջակցություն այս տարբերակներում ներկայացված նոր սպասման տեսակների համար
• WPF տեխնոլոգիայի միջոցով SSMS-ում բարելավված մատուցման արդյունավետություն
• Ակտիվ նստաշրջանների մեծ թվի ավելի լավ կառավարում
• Բարելավված համատեղելիություն ամպային SQL հարթակների հետ
• Ավելի ճշգրիտ CPU և I/O չափանիշներ

10.3.2 Վերջին տարբերակների հայտնի խնդիրներ

SQL Server 2019 թվականին Activity Monitor-ում մի քանի սխալներ հայտնվեցին.

• Մշտական ​​​​դադարի վիճակ՝ Ակտիվության մոնիտորը հաճախակի մտնում է դադարեցված վիճակի մեջ և չի վերսկսվում, մասնավորապես SSMS 18.0-18.3-ում: Ուղղվել է SSMS-ի հետագա տարբերակներում:
• Հեռակա կապի խափանումներ՝ Որոշ կարգավորումներ թույլ չեն տալիս Activity Monitor-ը բացել հեռակա օրինակներում: Շրջանցիկ լուծումներից են որոշակի հետագծման դրոշների միացումը կամ SSMS-ի ավելի նոր կառուցվածքների օգտագործումը:
• Թույլտվության հետ կապված խնդիրներ. Նոր համակարգի տեսքերը պահանջում են լրացուցիչ թույլտվություններ, որոնք հստակորեն չեն փաստաթղթավորվել, ինչի պատճառով էկրանները դատարկ են նույնիսկ VIEW SERVER STATE-ի դեպքում։

Աշխատելիս միշտ օգտագործեք SSMS-ի վերջին տարբերակը։ SQL Server 2019 և 2022 թվականներին՝ այս խնդիրներից խուսափելու համար։

11. Գործնական օգտագործման դեպքեր և օրինակներ

Իրական աշխարհի օրինակները ցույց են տալիս, թե ինչպես արդյունավետորեն կիրառել Activity Monitor-ը խնդիրների լուծման տարածված սցենարներում։

11.1 Ուսումնասիրություն. Դանդաղ վեբ հավելվածի ախտորոշում

Մշակողների թիմը հայտնում է, որ իրենց վեբ հավելվածը դարձել է անընդունելիորեն դանդաղ, էջերի բեռնումը տևում է 20-30 վայրկյան՝ սովորական 2-3 վայրկյանի փոխարեն։

11.1.1 Սկզբնական հետազոտություն՝ ընդհանուր պատկերի վահանակով

Բացեք Activity Monitor-ը և ուսումնասիրեք Overview վահանակը։

1. «Պրոցեսորի ժամանակի տոկոս» գրաֆիկը ցույց է տալիս պրոցեսորի ծանրաբեռնվածության 85-95% ցուցանիշ, ինչը զգալիորեն ավելի բարձր է, քան սովորական 30-40% սկզբնական ցուցանիշը։
2. Սպասման առաջադրանքների քանակը տատանվում է 10-20 առաջադրանքի միջև՝ ի տարբերություն 0-3 սովորական բազային ցուցանիշի։
3. Տվյալների բազայի մուտք/ելք գործելու արագությունը մոտ 50 ՄԲ/վ է։
4. Փաթեթային հարցումների քանակը վայրկյանում սպասվածից ցածր է՝ 100/վրկ, աշխատանքային ժամերին բնորոշ 300-400/վրկ-ի համեմատ։

Այս օրինաչափությունը ենթադրում է CPU-ի խցանում՝ ռեսուրսների մրցակցությամբ, որը նվազեցնում է թողունակությունը: Սերվերը աշխատում է ինտենսիվ, բայց շատ հարցումներ չի մշակում:

11.1.2 Խնդրահարույց հարցման նույնականացում

Ընդարձակեք «Վերջին թանկարժեք հարցումներ» վահանակը և տեսակավորեք ըստ «Կատարումներ/րոպե»-ի։

1. Ամենավերին հարցումը ցույց է տալիս րոպեում 15,000 կատարում։
2. Աջ սեղմեք և ընտրեք Խմբագրել հարցման տեքստը հարցումը ուսումնասիրելու համար։
3. Հարցումը պարզ SELECT հրաման է, որը վերականգնում է մեկ օգտատիրոջ գրառում։ SELECT * FROM Users WHERE UserId = @UserId.
4. Այս հարցումը չպետք է կատարվի րոպեում 15,000 անգամ՝ ծրագրի սովորական օգտագործման դեպքում։

Հարցման վրա սեղմեք աջ կոճակը և ընտրեք Ցուցադրել կատարման պլանըՊլանը ցույց է տալիս «Օգտատերեր» աղյուսակի աղյուսակի սկանավորում՝ «ՕգտատերԻդենտ» սյունակում բացակայող ինդեքսի մասին նախազգուշացմամբ։

Զտեք «Գործընթացներ» վահանակը ըստ ծրագրի՝ միայն վեբ ծրագրի կապերը ցուցադրելու համար: Բազմակի սեսիաները ցույց են տալիս, որ նույն հարցումը կրկնվում է:

11.1.3 Լուծում և ստուգում

Խնդիրը բխում է երկու խնդրից՝ հարցումների չափազանց շատ կատարումներից և ինդեքսի բացակայությունից։ Լուծման քայլերը՝

1. Ստեղծեք բացակայող ինդեքսը՝

   CREATE NONCLUSTERED INDEX IX_Users_UserId 
   ON Users (UserId);
   

2. Կապվեք մշակողների թիմի հետ չափազանց մեծ կատարողականների մասին։ Հետաքննությունը բացահայտում է N+1 հարցման խնդիր ծրագրի կոդում, որտեղ ցիկլը վերականգնում է օգտատիրոջ տվյալները ցուցակի յուրաքանչյուր տարրի համար։
3. Փոփոխել ծրագիրը օգտատիրոջ որոնումները խմբավորել մեկ հարցման մեջ՝ օգտագործելով IN կետ կամ աղյուսակային արժեքավոր պարամետր։
4. Հաստատեք ուղղումը Տեղակայումից հետո Activity Monitor-ի մոնիթորինգի միջոցով։ CPU-ի ծանրաբեռնվածությունը նվազում է մինչև 35-40%, րոպեում կատարվող ծրագրերի քանակը նվազում է մինչև 200-300, իսկ ծրագրերի արձագանքման ժամանակը վերադառնում է նորմալ։

11.2 Ուսումնասիրություն. Խոչընդոտման խնդրի լուծում

Օգտատերերը հաղորդում են, որ պատվերների մուտքագրման համակարգը պարբերաբար կախվում է 30-60 վայրկյանով, նախքան բնականոն աշխատանքը վերսկսելը։

11.2.1 Արգելափակման շղթայի հայտնաբերում

Բացեք Activity Monitor-ը այս սառեցման իրադարձություններից մեկի ժամանակ և ընդարձակեք «Գործընթացներ» վահանակը։

1. Դասավորել ըստ Նստաշրջանի ID կազմակերպված բոլոր նիստերը տեսնելու համար։
2. Բազմակի սեսիաները ցույց են տալիս արժեքները Արգելափակված է սյունակ, բոլորը մատնացույց են անում Session ID 73-ին։
3. 73-րդ սեսիան ցույց է տալիս «1»-ը Գլխի արգելափակիչ սյունակում՝ հաստատելով, որ դա հիմնական պատճառն է։
4.   Սպասման տեսակը Բլոկավորված սեսիաների համար ցուցադրվում է LCK_M_X, ինչը նշանակում է, որ նրանք սպասում են բացառիկ կողպեքների։
5.   Սպասման ռեսուրս սյունակը ցույց է տալիս, որ արգելափակումը գտնվում է «Պատվերներ» աղյուսակում։

11.2.2 Պատճառի վերլուծություն

Սեղմեք աջ կոճակով «Սեսիա 73» կոճակը և ընտրեք Մանրամասներ հրամանը դիտելու համար՝

UPDATE Orders 
SET Status = 'Processing', 
    LastModified = GETDATE()
WHERE OrderId IN (SELECT OrderId FROM #TempOrders);

Այս թարմացումը ժամային խմբաքանակով մշակման աշխատանքի մի մասն է։ Ստուգվում է Մուտք սյունակը հաստատում է, որ սեսիան պատկանում է խմբաքանակի մշակման ծառայության հաշվին։

Հարցումը կողպեքներ է պահում Պատվերների աղյուսակում՝ հազարավոր պատվերներ մշակելիս։ Սպասման ժամանակ արգելափակված սեսիաների թիվը կայուն աճում է, ինչը հաստատում է, որ խնդիրը այս երկարատև գործողությունն է։

11.2.3 Լուծման իրականացում

Կարճաժամկետ լուծում.

1. Փաստաթղթավորեք 73-րդ նստաշրջանի մանրամասները, ներառյալ հարցման տեքստը և տևողությունը։
2. Թույլ տվեք թարմացմանն ավարտվել բնականաբար, քանի որ դա օրինական խմբաքանակային մշակում է։
3. Ավարտից հետո ստուգեք, որ արգելափակված նիստերը մաքրված են, և բնականոն գործունեությունը վերսկսվում է։

Երկարաժամկետ լուծումների իրականացում.

1. Վերանշանակեք խմբային աշխատանքը աշխատել ոչ գագաթնակետային ժամերին (2-4-ը՝ աշխատանքային ժամերի փոխարեն):
2. Փոփոխել խմբաքանակի մշակումը թարմացնել պատվերները միաժամանակ 100 գրառումից բաղկացած փոքր խմբաքանակներով՝ վերացնելով արգելափակումները խմբաքանակների միջև։
3. Ավելացնել ինդեքս OrderId սյունակում՝ թարմացման գործողությունը արագացնելու համար։
4. Դիտարկեք SNAPSHOT մեկուսացումը ընթերցման գործողությունների համար՝ արգելափակման ազդեցությունը նվազեցնելու համար։

11.3 Ուսումնասիրություն. Հարցումների չափազանց մեծ ծավալի կատարումների բացահայտում

Տվյալների բազայի մոնիթորինգը ցույց է տալիս, որ CPU-ի օգտագործումը աստիճանաբար աճել է վերջին մեկ ամսվա ընթացքում, սակայն ծրագրի կոդում որևէ ակնհայտ փոփոխություն տեղի չի ունեցել։

11.3.1 Աննորմալ կատարողական հաշվարկների հայտնաբերում

Բացեք Activity Monitor-ը և ուսումնասիրեք «Վերջին թանկարժեք հարցումներ» վահանակը։

1. Դասավորել ըստ Կատարումներ/րոպե տեսնելու համար ամենահաճախ կատարված հարցումները։
2. Ամենաառաջին հարցումը ցույց է տալիս րոպեում 37,000 կատարում, ինչը շատ ավելի բարձր է, քան որևէ այլ հարցում։
3. Աջ սեղմեք և ընտրեք Խմբագրել հարցման տեքստը.
4. Հարցումը ստանում է ապրանքի կատեգորիայի տեղեկատվություն՝

   SELECT CategoryId, CategoryName 
   FROM ProductCategories 
   WHERE CategoryId = @CategoryId;
   

5. Այս պարզ հարցումը պետք է լինի արագ և քեշավորվող, բայց այն կատարվում է րոպեում տասնյակ հազարավոր անգամներ։

11.3.2 Հավելվածի կոդի հետևում

«Գործընթացներ» վահանակում գտեք այս հարցումը կատարող նիստերը՝

1. Նշենք դիմում սյունակը ցույց է տալիս «ProductCatalogService»-ը։
2. Սեղմեք այս սեսիաներից մեկի վրա աջ կոճակով և ընտրեք Հետևման գործընթաց SQL Server Պրոֆիլավոր.
3. SQL Profiler-ը ցույց է տալիս, որ հարցումը կատարվում է բազմիցս և արագ հաջորդականությամբ՝ տարբեր CategoryId արժեքներով։
4. Կապվեք ProductCatalogService-ը կառավարող մշակողների թիմի հետ՝ կոդի վերանայման համար։

Կոդի վերանայումը բացահայտում է խնդիրը. վերջին փոփոխությունը վերցնում է ապրանքների ցուցակները կատեգորիաներով: Արդյունքների հավաքածուի յուրաքանչյուր ապրանքի համար (հաճախ 1,000+ ապրանք), կոդը կատարում է առանձին տվյալների բազայի կանչ՝ կատեգորիայի տեղեկատվությունը ստանալու համար՝ դասական N+1 հարցման խնդիր:

11.3.3 Հավելվածի օպտիմալացում

Կիրառեք համապատասխան լուծում՝

1. Փոփոխել ծրագրի հարցումը օգտագործել JOIN-ը, որը վերականգնում է ապրանքները և դրանց կատեգորիաները մեկ տվյալների բազայի կանչում.

   SELECT p.ProductId, p.ProductName, c.CategoryId, c.CategoryName
   FROM Products p
   INNER JOIN ProductCategories c ON p.CategoryId = c.CategoryId
   WHERE p.Active = 1;
   

2. Տեղակայեք թարմացված կոդը և վերահսկել գործունեության մոնիտորը։
3. Հաստատեք ուղղումը. Կատեգորիայի հարցման համար րոպեում կատարվող կատարումները 37,000-ից նվազում են մինչև 100-ից պակաս, իսկ CPU-ի ընդհանուր օգտագործումը նվազում է 40%-ով։
4. Փաստաթղթավորեք սովորած դասը և կիսվել մշակողների թիմի հետ՝ ապագա կոդի փոփոխություններում նմանատիպ խնդիրներից խուսափելու համար։

12. Տվյալների բազայի հնարավոր վնասման հայտնաբերում

Թեև Activity Monitor-ը հատուկ նախատեսված չէ տվյալների բազայի վնասվածությունը հայտնաբերելու համար, դրա ցուցադրման որոշակի օրինաչափություններ կարող են վկայել թաքնված վնասվածության խնդիրների մասին, որոնք պահանջում են հետագա ուսումնասիրություն։

12.1 Տվյալների բազայի հնարավոր վնասման ախտանիշներ

Եթե ​​տվյալների բազայի վնասումը գոյություն ունի և այն հասանելի է դառնում, երբեմն կարող եք տեսնել.

1. Գործընթացների վահանակում՝

• Սեսիաները խրված են ԿԱՍԵՑՎԱԾ վիճակում՝ անսովոր սպասման տեսակներով
• Սխալ վիճակներ ցուցադրող գործընթացներ
• Հարցումները բազմիցս ձախողվում են

2. Ռեսուրսների սպասման վահանակում՝

• Անսովոր մուտքի/ելքի հետ կապված սպասման տեսակներ, որոնք կարող են վկայել սկավառակի խնդիրների մասին (չնայած սա ավելի հավանական է, որ վկայում է սարքավորման խնդիրների մասին, քան տրամաբանական վնասի մասին):

3. Վերջին թանկարժեք հարցումներում՝

• Աննորմալ բարձր ֆիզիկական ընթերցումներով հարցումներ, եթե դրանք բազմիցս փորձում են կարդալ վնասված էջեր

12.2 Լրացուցիչ ստուգում DBCC CHECKDB-ի հետ

Երբ Activity Monitor-ը ցուցադրում է ախտանիշներ, որոնք վկայում են հնարավոր վնասման մասին, դուք պետք է անմիջապես գործարկեք DBCC CHECKDB-ը՝ տվյալների բազայի ամբողջականությունը ստուգելու համար: Այս հրամանը սկանավորում է տվյալների բազայի բոլոր էջերը, ստուգում է ստուգիչ գումարները և ստուգում տրամաբանական համապատասխանության սխալները:

Տվյալների բազայի վնասվածությունները ստուգելու և շտկելու համար DBCC CHECKDB-ի օգտագործման մասին ավելին իմանալու համար տե՛ս մեր համապարփակ DBCC CHECKDB ուղեցույց.

12.3 Վերանորոգում մասնագիտական ​​գործիքներով

Եթե ​​DBCC CHECKDB-ն հաստատում է տվյալների բազայի վնասումը, դուք ունեք մի քանի տարբերակ վերականգնման համար.

• Առավել նախընտրելի մոտեցումը վերականգնումն է հայտնի լավ պահուստային պատճենից։ Տես մեր համապարփակ ուղեցույցը՝ պահուստավորման և վերականգնման վերաբերյալ SQL Server Տվյալների բազաներ.
• Փոքր վնասների դեպքում, DBCC CHECKDB-ը REPAIR_REBUILD-ի միջոցով կարող է լուծել խնդիրները։
• Վերջին պահուստավորումներ չունեցող կարևորագույն տվյալների բազաների համար, մասնագիտական SQL վերականգնման ծրագիր և ծառայությունները հաճախ կարող են վերականգնել այնպիսի տվյալներ, որոնք ներկառուցված վերականգնման տարբերակները չեն կարող։

13: եզրափակում

SQL Server Activity Monitor-ը անգնահատելի գործիք է տվյալների բազայի ադմինիստրատորների համար, որը անմիջական պատկերացում է տալիս սերվերի աշխատանքի մասին և օգնում է արագ և արդյունավետորեն ախտորոշել խնդիրները։

13.1 Հիմնական կետերի ամփոփում

Այս ուղեցույցի ընթացքում մենք ուսումնասիրել ենք, թե ինչպես է Activity Monitor-ը օգնում ձեզ հասկանալ և լուծել խնդիրները SQL Server կատարումը:

• Activity Monitor-ը կազմակերպված, գրաֆիկական ինտերֆեյսի միջոցով ապահովում է իրական ժամանակում տեսանելիություն գործընթացների, սպասումների, հարցումների և մուտքի/ելքի վերաբերյալ։
• Հինգ վահանակները՝ Ընդհանուր տեսք, Գործընթացներ, Ռեսուրսների սպասումներ, Տվյալների ֆայլերի մուտք/ելք և Վերջին թանկարժեք հարցումներ, յուրաքանչյուրը յուրահատուկ տեսանկյուն է առաջարկում սերվերի գործունեության վերաբերյալ։
• Հաճախակի խնդիրների լուծման այնպիսի սցենարներ, ինչպիսիք են հարցումների չափազանց մեծ կատարումները, արգելափակման շղթաները և CPU-ի բարձր ծանրաբեռնվածությունը, կառավարելի են դառնում Activity Monitor-ի համակարգված հետազոտության միջոցով։
• Թեև հզոր է, Activity Monitor-ն ունի սահմանափակումներ, այդ թվում՝ պատմական տվյալների բացակայությունը, սպասման տեսակների խմբավորումը և մոնիթորինգի ծախսերը, որոնք ազդում են դրա կիրառելիության վրա։
• Activity Monitor-ը DMV հարցումներով, sp_WhoIsActive-ով, Extended Events-ով և հնարավոր է՝ երրորդ կողմի գործիքներով լրացնելը ստեղծում է համապարփակ մոնիթորինգի ռազմավարություն։
• Թարմացման միջակայքերի լավագույն փորձին հետևելը, չօգտագործման դեպքում Activity Monitor-ը փակելը և համադրման համար մի քանի վահանակներ համատեղելը մեծացնում են դրա արժեքը՝ միաժամանակ նվազագույնի հասցնելով ազդեցությունը։

13.2 Գործունեության մոնիտորը որպես ձեր գործիքակազմի մաս

Activity Monitor-ը պետք է ծառայի որպես ձեր առաջին արձագանքման գործիք՝ կատարողականի հետազոտությունների համար, այլ ոչ թե միակ գործիքը: Դրա ուժեղ կողմը կայանում է ակտիվ խնդիրների լուծման ժամանակ անհապաղ տեսանելիություն ապահովելու մեջ՝ օգնելով ձեզ արագ որոշել, թե արդյոք տվյալների բազան խոչընդոտ է հանդիսանում, և բացահայտել, թե որ կոնկրետ ասպեկտներն են պահանջում ավելի խորը հետազոտություն:

Մտածեք Activity Monitor-ի մասին որպես ձեր մեքենայի վահանակի. այն անմիջապես կասի ձեզ, եթե ինչ-որ բան այն չէ, և կօգնի ձեզ բացահայտել մտահոգության ընդհանուր ոլորտը: Ճիշտ այնպես, ինչպես ձեր մեքենայի վահանակը չի ասում, թե ինչու է վառվել ստուգման շարժիչի լույսը, Activity Monitor-ը ձեզ կուղղորդի խնդիրների վրա՝ միշտ չբացահայտելով դրանց ամբողջական արմատական ​​պատճառը: Այդ ավելի խորը վերլուծությունը պահանջում է լրացուցիչ գործիքներ և փորձագիտություն:

Ինտեգրեք Activity Monitor-ը ավելի լայն գործիքակազմի մեջ, որը ներառում է կատարման պլանի վերլուծություն, սպասման վիճակագրության հետևում, պատմական մոնիթորինգի լուծումներ և կատարողականի լավագույն փորձ: Օգտագործեք այն համապատասխան ինդեքսավորման ռազմավարությունների, հարցումների օպտիմալացման տեխնիկայի և կարողությունների պլանավորման հետ համատեղ:

13.3 Ձեր ուսումնական ճանապարհորդության շարունակությունը

Activity Monitor-ի յուրացումը արդյունավետ տվյալների բազայի ադմինիստրատոր դառնալու ընդամենը մեկ քայլ է: Շարունակեք զարգացնել ձեր հմտությունները՝

• Սովորել մեկնաբանել կատարման պլանները և բացահայտել անարդյունավետ գործողությունները
• Understanding SQL Server սպասման վիճակագրությունը և դրա հետևանքները
• Ինդեքսի նախագծման և օպտիմալացման տեխնիկայի ուսումնասիրություն
• Հետազոտելով SQL Server-ի ճարտարապետությունը և ինչպես է այն մշակում հարցումները
• Համակարգված խնդիրների լուծման մեթոդաբանությունների կիրառում
• Մանրամասն հետևման համար ընդլայնված միջոցառումների հետ փորձի ձևավորում
• Գործարքների մեկուսացման մակարդակների և դրանց կատարողականի վրա ազդեցության ըմբռնումը

Activity Monitor-ի միջոցով կատարողականի յուրաքանչյուր հետազոտություն ձեզ ինչ-որ նոր բան է սովորեցնում այն ​​մասին, թե ինչպես SQL Server աշխատում է և թե ինչպես են հավելվածները փոխազդում տվյալների բազաների հետ: Փաստաթղթավորեք ձեր արդյունքները, կիսվեք գիտելիքներով գործընկերների հետ և կառուցեք լուծումների գրադարան տարածված խնդիրների համար:

13.4 Լրացուցիչ ռեսուրսներ

Ընդարձակեք ձեր գիտելիքները այս արժեքավոր ռեսուրսների միջոցով՝

• Բացեք Ակտիվության մոնիտորը SQL Server Կառավարման ստուդիա (SSMS) : Պաշտոնյա SQL Server փաստաթղթեր, թե ինչպես բացել Activity Monitor-ը SQL Server Կառավարման ստուդիա (SSMS):
• Գործունեության մոնիտոր Պաշտոնական SQL Server փաստաթուղթ, որը նկարագրում է, թե ինչպես օգտագործել Activity Monitor-ը։

14. Հաճախակի տրվող հարցեր (ՀՏՀ)

Հ. Ինչ է SQL Server Ակտիվության մոնիտոր՞

A: SQL Server Ակտիվության մոնիտորը ներկառուցված գործիք է SQL Server Կառավարման ստուդիա, որը ցուցադրում է իրական ժամանակի տեղեկատվություն համակարգչում աշխատող գործընթացների մասին։ SQL Server օրինակը և դրանց ազդեցությունը սերվերի ռեսուրսների վրա: Այն տրամադրում է գրաֆիկական վահանակ հինգ վահանակով, որոնք ցույց են տալիս սերվերի գործունեության տարբեր ասպեկտներ, ներառյալ պրոցեսորի օգտագործումը, սպասման առաջադրանքները, մուտքի/ելքի արագությունը, ակտիվ սեսիաները և թանկարժեք հարցումները:

Հարց. Ինչպե՞ս բացել Activity Monitor-ը SSMS-ում:

Ա. Դուք կարող եք բացել Activity Monitor-ը՝ օգտագործելով չորս եղանակ. (1) Սեղմեք Activity Monitor պատկերակը SSMS գործիքագոտում, (2) Սեղմեք աջ մկնիկի կոճակը ձեր SQL Server օրինակի անունը Object Explorer-ում և ընտրեք Գործունեության մոնիտոր, (3) Սեղմեք Ctrl + ալտ + A, կամ (4) Կարգավորեք SSMS-ը՝ այն ավտոմատ կերպով գործարկելու համար՝ Գործիքներ -> Ընտրանքներ -> միջավայր -> Startup.

Հարց. Ի՞նչ թույլտվություններ են անհրաժեշտ Activity Monitor-ն օգտագործելու համար։

Ա: Ձեզ անհրաժեշտ է Դիտել սերվերի վիճակը թույլտվություն՝ տեսնելու Activity Monitor-ի տեղեկատվության մեծ մասը: Տվյալների ֆայլի մուտք/ելք վահանակի համար ձեզ նաև անհրաժեշտ է կամ Ստեղծեք տվյալների շտեմարան, ՓՈՓՈԽԵԼ ՑԱՆԿԱՑԱԾ ՏՎՅԱԼՆԵՐԻ ԲԱԶԱԿամ ԴԻՏԵԼ ՑԱՆԿԱՑԱԾ ՍԱՀՄԱՆՈՒՄ թույլտվություններ։ Առանց այս թույլտվությունների, Activity Monitor-ը կարող է բացվել, բայց ցուցադրել դատարկ վահանակներ։

Հարց. Ինչո՞ւ է իմ ակտիվության մոնիտորը դադարեցված կամ չի աշխատում:

Ա. Ակտիվության մոնիտորը սովորաբար դադարում է թույլտվությունների խնդիրների, SSMS-ի հնացած տարբերակների կամ հեռակա կապերի անջատման պատճառով: Լուծման համար. (1) թարմացրեք SSMS-ի վերջին տարբերակին, (2) համոզվեք, որ ունեք VIEW SERVER STATE թույլտվություն, (3) ստուգեք, որ հեռակա կապերը միացված են: SQL Server օրինակ՝ (4) Վերագործարկեք SSMS-ը, և (5) Փորձեք միանալ Windows-ի նույնականացման միջոցով՝ SQL նույնականացման փոխարեն, եթե կիրառելի է։

Հարց. Ի՞նչ տարբերություն կա Activity Monitor-ի և sp_WhoIsActive-ի միջև։

Ա. Activity Monitor-ը SSMS-ի մեջ ներկառուցված գրաֆիկական գործիք է, որը տրամադրում է կազմակերպված վահանակներ տարբեր մոնիթորինգի ասպեկտների համար: sp_WhoIsActive-ը համայնքի կողմից ստեղծված անվճար պահեստավորված պրոցեդուրա է, որը վերադարձնում է մանրամասն նիստի տեղեկատվությունը մեկ արդյունքների հավաքածուում՝ ավելի կոնկրետ սպասման տեսակներով, արգելափակման մանրամասներով և հարմարեցման տարբերակներով, քան Activity Monitor-ը: Activity Monitor-ն ավելի լավ է տեսողական ուսումնասիրության համար, մինչդեռ sp_WhoIsActive-ը գերազանցում է սկրիպտային մոնիթորինգի մեջ և տրամադրում է ավելի մանրամասն տեղեկատվություն:

Հարց. Արդյո՞ք Activity Monitor-ը ազդում է սերվերի աշխատանքի վրա:

Ա. Այո, Activity Monitor-ը ունի չափելի վերադիր ծախս, քանի որ այն հարցում է ուղարկում համակարգի DMV-ներին յուրաքանչյուր թարմացման միջակայքում: Ազդեցությունն աճում է թարմացման ցածր հաճախականությամբ. Microsoft-ը զգուշացնում է, որ 10 վայրկյանից պակաս միջակայքերը կարող են ազդել սերվերի աշխատանքի վրա: Միշտ փակեք Activity Monitor-ը, երբ այն ակտիվորեն չեք օգտագործում, և հաշվի առեք 30-60 վայրկյան թարմացման միջակայքերը արտադրական սերվերների վրա՝ ծանրաբեռնվածության դեպքում:

Հարց. Կարո՞ղ եմ ստանալ Activity Monitor-ի տվյալներ T-SQL-ի միջոցով:

Ա. Այո, Activity Monitor-ը հարցումներ է ուղարկում համակարգի դինամիկ կառավարման այնպիսի դիտումներին, ինչպիսիք են sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_wait_stats և sys.dm_exec_query_stats: Դուք կարող եք հարցումներ ուղարկել այս DMV-ներին անմիջապես՝ օգտագործելով T-SQL՝ ծրագրային եղանակով համարժեք տեղեկատվություն ստանալու համար, որը հնարավորություն է տալիս ստեղծել հատուկ մոնիթորինգի սկրիպտներ և ավտոմատացված տվյալների հավաքագրում:

Հարց. Ո՞րն է թարմացման լռելյայն միջակայքը։

Ա. Թարմացման լռելյայն միջակայքը 10 վայրկյան է: Դուք կարող եք փոխել սա՝ աջ սեղմելով Ընդհանուր տեսքի վահանակի ցանկացած մասում, ընտրելով Թարմացման միջակայքև նախապես սահմանված տարբերակներից ընտրելով՝ 1 վայրկյան, 5 վայրկյան, 10 վայրկյան, 30 վայրկյան, 1 րոպե կամ 1 ժամ: Ավելի ցածր ինտերվալները ապահովում են ավելի շատ իրական ժամանակի դիտումներ, բայց մեծացնում են մոնիթորինգի ծախսերը:

Հարց. Ինչպե՞ս կարող եմ ավտոմատ կերպով բացել Activity Monitor-ը SSMS-ի գործարկման ժամանակ։

Ա. Կարգավորեք ավտոմատ մեկնարկը SSMS տարբերակների միջոցով. Նայեք դեպի Գործիքներ -> Ընտրանքներ -> միջավայր -> Startup, Ապա ընտրեք Բացեք օբյեկտների դիտարկիչը և ակտիվության մոնիտորը - ից Սկսվում է իջնող ցանկ։ Ակտիվության մոնիտորը ավտոմատ կերպով կբացվի ամեն անգամ, երբ դուք միանաք սերվերի SSMS-ում։

Հարց. Որո՞նք են Activity Monitor-ի սահմանափակումները:

Ա. Հիմնական սահմանափակումներն են՝ (1) Պատմական տվյալների պահպանման կամ միտումների դիտարկման հնարավորությունների բացակայությունը, (2) Սպասման տեսակները խմբավորված են կատեգորիաների մեջ, այլ ոչ թե կոնկրետ ցուցադրվում են, (3) Որոշ սպասման տեսակներ, ինչպիսին է CXPACKET-ը, կարող են չհայտնվել, (4) Ժամանակային կտրվածքները կարող են բաց թողնել անցողիկ խնդիրները, (5) Վերահսկող ծանրաբեռնվածության մոնիթորինգը կարող է ազդել զբաղված սերվերների վրա, (6) Նախազգուշացման մեխանիզմի բացակայությունը կանխարգելիչ մոնիթորինգի համար, և (7) Հնարավոր չէ համախմբել տվյալները բազմաթիվ սերվերների միջև։ SQL Server օրինակներ: Այս կարիքների համար լրացրեք Activity Monitor-ը Extended Events-ով, տվյալների հավաքագրման հավաքածուներով կամ երրորդ կողմի մոնիթորինգի գործիքներով:

---

Հեղինակի մասին

Յուան Շենգ տվյալների բազայի ավագ ադմինիստրատոր (DBA) է՝ ավելի քան 10 տարվա փորձով։ SQL Server միջավայրերի և ձեռնարկությունների տվյալների բազայի կառավարման ոլորտում: Նա հաջողությամբ լուծել է տվյալների բազայի վերականգնման հարյուրավոր սցենարներ ֆինանսական ծառայությունների, առողջապահության և արտադրական կազմակերպություններում:

Յուանը մասնագիտանում է SQL Server տվյալների բազայի վերականգնում, բարձր մատչելիության լուծումներև աշխատանքի օպտիմալացում: Նրա լայնածավալ գործնական փորձը ներառում է բազմաբայթ ծավալով տվյալների բազաների կառավարում, միշտ ակտիվ հասանելիության խմբերի ներդրում և կարևորագույն բիզնես համակարգերի համար ավտոմատացված պահուստավորման և վերականգնման ռազմավարությունների մշակում:

Իր տեխնիկական փորձագիտության և գործնական մոտեցման միջոցով Յուանը կենտրոնանում է համապարփակ ուղեցույցներ ստեղծելու վրա, որոնք կօգնեն տվյալների բազայի ադմինիստրատորներին և ՏՏ մասնագետներին լուծել բարդ խնդիրներ։ SQL Server արդյունավետորեն մարտահրավերներ է նետում։ Նա տեղեկացված է մնում վերջին նորություններից SQL Server թողարկումները և Microsoft-ի զարգացող տվյալների բազայի տեխնոլոգիաները, պարբերաբար փորձարկելով վերականգնման սցենարները՝ համոզվելու համար, որ նրա առաջարկությունները արտացոլում են իրական աշխարհի լավագույն փորձը։

Հարցեր ունեք SQL Server Վերականգնո՞ւմ, թե՞ անհրաժեշտ է տվյալների բազայի խնդիրների լուծման լրացուցիչ ուղեցույց: Յուանը ողջունում է ձեզ: արձագանքներ և առաջարկություններ այս տեխնիկական ռեսուրսները բարելավելու համար։