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-ს რამდენიმე უპირატესობა აქვს, რაც მას აუცილებელ მონაცემთა ბაზის ინსტრუმენტად აქცევს:

• ნულოვანი ღირებულება: როგორც ჩაშენებული SQL Server Management Studio-ს ფუნქციის წყალობით, ლიცენზირების საფასური ან განლაგების ძალისხმევა არ არის საჭირო.
• რეალურ დროში მონიტორინგი: იხილეთ სერვერის მიმდინარე აქტივობა, როგორც კი ის მოხდება, კონფიგურირებადი განახლების ინტერვალებით 1 წამიდან 1 საათამდე.
• ინტეგრირებული მოქმედებები: სესიების დასასრულებლად, შეკითხვის დეტალების სანახავად ან გასაშვებად დააწკაპუნეთ მაუსის მარჯვენა ღილაკით პროცესებზე SQL Server პროფილიერის კვალი — ყველაფერი ხელსაწყოდან.
• მრავალი პერსპექტივა: სერვერის მდგომარეობის ნახვა სხვადასხვა კუთხიდან ხუთი სპეციალიზებული პანელის მეშვეობით შეგიძლიათ, რომელთაგან თითოეული შესრულების კონკრეტულ ასპექტებზეა ფოკუსირებული.
• სწრაფი პრობლემების მოგვარება: რამდენიმე წუთში ამოიცანით ყველაზე გავრცელებული პრობლემები, რაც დააჩქარებს მათი გადაჭრის საშუალო დროს.
• შესვლის დაბალი ბარიერი: ინსტრუმენტის ეფექტურად გამოყენების დასაწყებად არ არის საჭირო მოწინავე ცოდნა, თუმცა უფრო ღრმა SQL Server ექსპერტიზა ინტერპრეტაციაში გვეხმარება.

2. აქტივობის მონიტორის გამოყენების დაწყება

სანამ Activity Monitor-ის ეფექტურად გამოყენებას დაიწყებთ, უნდა გესმოდეთ წინაპირობები, საჭირო ნებართვები და ინსტრუმენტის გაშვების სხვადასხვა მეთოდი.

2.1 წინაპირობები და სისტემის მოთხოვნები

იმისათვის, რომ გამოიყენოთ SQL Server აქტივობის მონიტორი, რომელიც გჭირდებათ SQL Server Management Studio (SSMS) დაინსტალირებული თქვენს ლოკალურ მოწყობილობაზე ან jump სერვერზე. Activity Monitor-ის ინსტრუმენტი მნიშვნელოვნად გადაკეთდა 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');

permission_name სვეტში მოძებნეთ „VIEW SERVER STATE“. თუ ის არ არის, დაუკავშირდით თქვენი მონაცემთა ბაზის ადმინისტრატორს მისი მინიჭების მოთხოვნისთვის.

2.3 როგორ გავხსნათ Activity Monitor SSMS-ში

SQL Server Management Studio გთავაზობთ Activity Monitor-ის გაშვების ოთხ განსხვავებულ მეთოდს, რაც გაძლევთ მოქნილობას თქვენი სამუშაო პროცესის პარამეტრების მიხედვით.

2.3.1 მეთოდი 1: ხელსაწყოთა პანელიდან

Activity Monitor-ის გასახსნელად ყველაზე სწრაფი გზა ხელსაწყოთა პანელის ხატულის გამოყენებაა:

1. დაუკავშირდით თქვენს SQL Server მაგალითად SQL Server მენეჯმენტის სტუდია.
2. იპოვეთ Activity Monitor-ის ხატულა სტანდარტულ ხელსაწყოთა პანელზე (ის წააგავს სვეტოვან დიაგრამას მწვანე დაკვრის ღილაკით).
3. დააწკაპუნეთ ხატულაზე აქტივობის მონიტორის გასაშვებად.

ეს მეთოდი ყველაზე სწრაფია, როდესაც უკვე SSMS-ში მუშაობთ და გჭირდებათ სერვერის აქტივობის სწრაფად შემოწმება.

2.3.2 მეთოდი 2: ობიექტის მკვლევარიდან

ასევე შეგიძლიათ Activity Monitor-ის გაშვება პირდაპირ Object Explorer-დან:

1. ობიექტის მკვლევარში იპოვეთ SQL Server შემთხვევა, რომლის მონიტორინგიც გსურთ.
2. დააწკაპუნეთ მაუსის მარჯვენა ღილაკით ეგზემპლარის სახელზე.
3. აირჩიეთ საქმიანობის მონიტორი კონტექსტური მენიუდან.

ეს მეთოდი სასარგებლოა მრავალ სერვერთან დაკავშირებისას, რადგან ის უზრუნველყოფს სწორი ეგზემპლარის მონიტორინგს.

2.3.3 მეთოდი 3: კლავიატურის მალსახმობის გამოყენება

კლავიატურაზე ორიენტირებული მომხმარებლებისთვის, SQL Server Management Studio გთავაზობთ სპეციალურ მალსახმობს:

1. დარწმუნდით, რომ SSMS აქტიური ფანჯარაა და თქვენ დაკავშირებული ხართ ინსტანციასთან.
2. პრეს Ctrl + Alt + A.
3. ობიექტის მკვლევარში ამჟამად არჩეული ეგზემპლარისთვის აქტივობის მონიტორი გაიხსნება.

გაითვალისწინეთ, რომ 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. აქტივობის მონიტორინგის პანელების გაგება

Activity Monitor ინფორმაციას ხუთ გაფართოებად პანელში აწყობს, რომელთაგან თითოეული სერვერის აქტივობის განსხვავებულ პერსპექტივას გვთავაზობს. ეფექტური პრობლემების მოგვარებისთვის უმნიშვნელოვანესია იმის გაგება, თუ რას აჩვენებს თითოეული პანელი.

3.1 მიმოხილვის პანელი

მიმოხილვის პანელი წარმოადგენს ოთხ რეალურ დროში გრაფიკს, რომლებიც თქვენი მდგომარეობის სწრაფ მიმოხილვას გაძლევთ. SQL Server მაგალითად. ეს გრაფიკები განახლდება კონფიგურირებადი ინტერვალით და დაგეხმარებათ ერთი შეხედვით არანორმალური ნიმუშების იდენტიფიცირებაში.

3.1.1% პროცესორის დრო

ეს გრაფიკი აჩვენებს პროცესორის მიერ არა-უმოქმედო ნაკადების შესრულების დროის პროცენტულ მაჩვენებელს. SQL Server ეგზემპლარად ყველა CPU-ზე. მნიშვნელობა წარმოადგენს 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: თითოეული კავშირისთვის უნიკალური იდენტიფიკატორი. სისტემის პროცესები იყენებენ უარყოფით სესიის ID-ებს.
• მომხმარებლის პროცესი: მიუთითებს, ეს მომხმარებლის სესია (დიახ) თუ სისტემური პროცესი (არა).
• შესვლა: ის SQL Server შესვლა ან სესიასთან დაკავშირებული Windows ანგარიში.
• Მონაცემთა ბაზა: სესიისთვის მიმდინარე მონაცემთა ბაზის კონტექსტი.
• დავალების მდგომარეობა: აჩვენებს, თუ რას აკეთებს სესია ამჟამად (სირბილი, გაჩერება, ძილი და ა.შ.).
• ბრძანება: შესრულებული ბრძანების ტიპი (SELECT, INSERT, UPDATE და ა.შ.).
• განაცხადის: აპლიკაციის სახელი, რომელმაც შექმნა კავშირი.
• Ლოდინის დრო: რამდენ ხანს (მილიწამებში) ელოდება სესია რესურსებს.
• ლოდინის ტიპი: რესურსის კონკრეტული ტიპი, რომელსაც სესია ელოდება.
• პროცესორის დრო: ამ სესიის მიერ დაკავშირების შემდეგ დახარჯული CPU-ს საერთო დრო.
• მეხსიერების გამოყენება: სესიისთვის ამჟამად გამოყოფილი მეხსიერების რაოდენობა (კბ-ში).

3.2.3 ფილტრაციისა და დახარისხების პროცესები

პროცესების პანელი მოიცავს ფილტრაციის მძლავრ შესაძლებლობებს, რაც დაგეხმარებათ შესაბამის სესიებზე ფოკუსირებაში:

1. დააწკაპუნეთ ნებისმიერი სვეტის სათაურში ჩამოსაშლელი სიის ისარზე.
2. ფილტრი აჩვენებს ამ სვეტისთვის ხელმისაწვდომ მნიშვნელობებს, მათ შორის ყველა, ბლანკებიდა არა-ცარიელი.
3. აირჩიეთ კონკრეტული მნიშვნელობები, რათა ეკრანი მხოლოდ ამ სესიებზე გაფილტროთ.

მაგალითად, შეგიძლიათ გაფილტროთ დავალების მდგომარეობა მხოლოდ მიმდინარე სესიების საჩვენებლად, ან გაფილტრეთ მონაცემთა ბაზა კონკრეტულ მონაცემთა ბაზასთან აქტივობის სანახავად.

ასევე შეგიძლიათ დაალაგოთ ნებისმიერი სვეტის მიხედვით მის სათაურზე დაწკაპუნებით. ზრდადი თანმიმდევრობისთვის დააწკაპუნეთ ერთხელ, კლებადობით - ორჯერ.

3.2.4 დაბლოკილი და დაბლოკილი სესიების იდენტიფიცირება

პროცესების პანელი დაგეხმარებათ იმ დაბლოკვის სცენარების იდენტიფიცირებაში, სადაც ერთი სესია ხელს უშლის სხვების გაგრძელებას:

• დაბლოკილია: აჩვენებს იმ სესიის ID-ს, რომელიც ბლოკავს ამ სესიას. თუ ეს სვეტი შეიცავს მნიშვნელობას, სესია ელოდება სხვა სესიის მიერ შეკავებულ დაბლოკვას.
• თავის ბლოკატორი: აჩვენებს '1'-ს, თუ ეს სესია ბლოკავს სხვებს, მაგრამ თავად არ არის დაბლოკილი. ეს არის ბლოკირების ჯაჭვის ძირითადი მიზეზი.

დაბლოკვის პრობლემის გამოსაკვლევად, ჯერ დაადგინეთ მთავარი ბლოკერი (სესია, რომელიც მონიშნულია „1“-ით „მთავარი ბლოკერის“ სვეტში), შემდეგ შეამოწმეთ, რას აკეთებს ის და გადაწყვიტეთ, მისცეთ მას უფლება, დაასრულოს თუ შეწყვიტოს იგი.

3.2.5 პროცესის მოქმედებები (დასრულება, დეტალები, კვალი)

აქტივობის მონიტორი საშუალებას გაძლევთ განახორციელოთ შემდეგი ქმედებები ინდივიდუალურ სესიებზე:

1. დააწკაპუნეთ მაუსის მარჯვენა ღილაკით ნებისმიერ სესიაზე პროცესების პანელში.
2. თქვენ ნახავთ რამდენიმე ვარიანტს:
   • დეტალები: აჩვენებს ამ სესიის მიერ შესრულებულ ბოლო ბრძანებას.
   • პროცესის მოკვლა: წყვეტს სესიას (გამოიყენეთ სიფრთხილით).
   • კვალის დამუშავება SQL Server პროფილერი: იწყებს SQL Server პროფილი და ავტომატურად ფილტრავს მხოლოდ ამ სესიის აქტივობის საჩვენებლად.

დეტალების ოფცია გიჩვენებთ ბრძანების ტექსტს, მაგრამ გაითვალისწინეთ, რომ ეს არის ბოლო ბრძანება შესრულებულია — შესაძლოა, ის ჯერ კიდევ არ მუშაობდეს. კვალის ოფცია განსაკუთრებით სასარგებლოა, როდესაც გჭირდებათ სესიის მიერ შესრულებული ბრძანებების სრული თანმიმდევრობის ნახვა.

3.3 რესურსების ლოდინის პანელი

რესურსების მოლოდინის პანელი აჯამებს მოლოდინის სტატისტიკას და აჩვენებს, თუ რა ტიპის რესურსების სესიებს ელოდებიან ყველაზე ხშირად. ეს ინფორმაცია გადამწყვეტია შესრულების შეფერხებების დიაგნოსტიკისთვის.

3.3.1 ლოდინის სტატისტიკის გაგება

როდესაც SQL Server თუ რესურსის მოთხოვნა (მაგალითად, დაბლოკვა, პროცესორის დრო ან მეხსიერება) დაუყოვნებლივ ვერ დაკმაყოფილდება, მოთხოვნის გამგზავნი დავალება ლოდინის რეჟიმში გადავა. ლოდინის სტატისტიკა აკონტროლებს ამ ლოდინის პერიოდებს და დაგეხმარებათ გაიგოთ, თუ სად ხარჯავს სერვერი დროს ლოდინში მუშაობის ნაცვლად.

რესურსების მოლოდინის პანელი აგროვებს მონაცემებს სისტემის დინამიური მართვის ხედებიდან, როგორიცაა 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 ms ლოდინის დროს კატეგორიისთვის, ეს მიუთითებს რამდენიმე ერთდროულ ლოდინზე (20,000 ms / 10,000 ms = საშუალოდ 2 ერთდროული ლოდინი ინტერვალის განმავლობაში).

3.3.4 შესრულების შემაფერხებელი ფაქტორების იდენტიფიცირება

გამოიყენეთ რესურსების მოლოდინის პანელი, რათა დაადგინოთ, თუ სად ხარჯავს თქვენი სერვერი ყველაზე მეტ დროს ლოდინის დროს:

1. გაშალეთ რესურსების მოლოდინის პანელი.
2. დააკვირდით ლოდინის კატეგორიებს, რომლებიც ყველაზე მეტ ლოდინის დროს აგროვებენ.
3. დალაგება კუმულაციური ლოდინის დრო იმის სანახავად, თუ რომელი რესურსებია ყველაზე შეზღუდული.

მაღალი ბუფერული ჩამკეტის ლოდინი ხშირად მიუთითებს მეხსიერებაში მონაცემთა გვერდების დაბრკოლებაზე, რაც შეიძლება მიუთითებდეს შეყვანის/გამოყვანის შეფერხებებზე ან tempdb-ის დაბრკოლებაზე. მაღალი ჩაკეტვის ლოდინი მიუთითებს ბლოკირების პრობლემებზე. მაღალი მეხსიერების ლოდინი მიუთითებს შეკითხვის ოპერაციებისთვის მეხსიერების არასაკმარის მინიჭებაზე.

3.4 მონაცემთა ფაილის შეყვანის/გამოყვანის პანელი

მონაცემთა ფაილის შეყვანა/გამოყვანის პანელი აჩვენებს დისკის აქტივობას თქვენს სერვერზე არსებული თითოეული მონაცემთა ბაზის ფაილისთვის, რაც დაგეხმარებათ შეყვანა/გამოყვანის შეფერხებების იდენტიფიცირებასა და დისკის გამოყენების ნიმუშების გაგებაში.

3.4.1 შეყვანის/გამოყვანის მეტრიკის გაგება

მონაცემთა ფაილის შეყვანის/გამოყვანის პანელი აჩვენებს რამდენიმე მეტრიკას თითოეული მონაცემთა ბაზის ფაილისთვის:

• Მონაცემთა ბაზა: მონაცემთა ბაზის სახელი.
• ფაილის ტიპი: ან მონაცემები (ცხრილების და ინდექსების ჩათვლით) ან ჟურნალი (ტრანზაქციების ჟურნალი).
• ლოგიკური სახელი: ლოგიკური ფაილის სახელი, როგორც განსაზღვრულია SQL Server.
• მბ/წმ წაკითხვა: ამ ფაილიდან მონაცემების წაკითხვის სიჩქარე.
• მბ/წმ ჩაწერილი: ამ ფაილში მონაცემების ჩაწერის სიჩქარე.
• რეაგირების დრო (მწმ): ამ ფაილზე შემავალი/გამომავალი ოპერაციების საშუალო რეაგირების დრო.

ეს მეტრიკები განახლდება იმავე ინტერვალში, როგორც მიმოხილვის პანელი, რაც დისკის აქტივობის რეალურ დროში ხილვადობას გაძლევთ.

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 დრო.
• ფიზიკური წაკითხვები/წმ: ამ მოთხოვნისთვის ფიზიკური დისკის წამში წაკითხვის რაოდენობა.
• ლოგიკური ჩაწერები/წმ: ლოგიკური ჩაწერების რაოდენობა (ქეშის ბუფერში) წამში.
• ლოგიკური წაკითხვები/წმ: ლოგიკური წაკითხვების რაოდენობა (ბუფერული ქეშიდან) წამში.
• საშუალო ხანგრძლივობა (მწმ): ამ მოთხოვნის საშუალო შესრულების დრო.
• გეგმის რაოდენობა: ამ მოთხოვნისთვის ქეშში შესრულების გეგმების რაოდენობა.

ეს მეტრიკები დაგეხმარებათ არა მხოლოდ იმის გაგებაში, თუ რომელი მოთხოვნებია ძვირი, არამედ რატომ ისინი ძვირია და რამდენად ხშირად დადიან.

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 შეკითხვის პრობლემაზე, სადაც აპლიკაციის კოდი იძახებს მონაცემთა ბაზას ციკლის შიგნით.
• მაღალი ფიზიკური მაჩვენებლები: მაღალი ფიზიკური წაკითხვის სიჩქარით შეკითხვები ხშირად ხვდება დისკზე, რაც მიუთითებს ინდექსების არარსებობაზე ან ცუდად დაწერილ შეკითხვებზე.
• მაღალი პროცესორი დაბალი ხანგრძლივობით: ბევრმა სწრაფმა მოთხოვნამ, რომელიც ჯამში დიდ დატვირთვას მოიხმარს, შეიძლება ისევე იმოქმედოს სერვერის მუშაობაზე, როგორც რამდენიმე ნელმა მოთხოვნამ.
• მრავალი გეგმის რაოდენობა: მრავალი შესრულების გეგმის მქონე მოთხოვნებს შეიძლება ჰქონდეს პარამეტრების შემოწმების პრობლემები ან არაპარამეტრიზებული მოთხოვნები, რაც გეგმის ქეშის გადატვირთვას იწვევს.

4. აქტივობის მონიტორის გამოყენება შესრულების პრობლემების გადასაჭრელად

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. დააწკაპუნეთ მარჯვენა ღილაკით Head blocker სესიაზე და აირჩიეთ დაწვრილებით რომ ნახოთ, რა ბრძანებას ასრულებს.

ბლოკირების ჯაჭვის გაგება უმნიშვნელოვანესია. მთავარი ბლოკატორი არის სესია, რომლის გამოკვლევაც გჭირდებათ და არა შემდგომი დაბლოკილი სესიები.

4.2.2 საკეტების ტიპების გაგება

ის ლოდინის ტიპი პროცესების პანელში სვეტი მიუთითებს, თუ რა ტიპის დაბლოკვას ელოდებიან დაბლოკილი სესიები:

• LCK_M_X: ექსკლუზიური დაბლოკვის ლოდინი, რომელიც ჩვეულებრივ გამოწვეულია UPDATE, DELETE ან INSERT ოპერაციებით.
• LCK_M_S: გაზიარებული საკეტის ლოდინი, როგორც წესი, SELECT ოპერატორები ელოდებიან ექსკლუზიური საკეტების გამოშვებას.
• LCK_M_U: განახლების დაბლოკვის ლოდინი, შუალედური დაბლოკვის ტიპი, რომელიც გამოიყენება განახლების დროს.
• LCK_M_IX: განზრახ ექსკლუზიური დაბლოკვის ლოდინი, რაც მიუთითებს გვერდის ან რიგის დონის დაბლოკვის დავას.

ის მოლოდინის რესურსი სვეტი აჩვენებს, თუ რომელი მონაცემთა ბაზის ობიექტი იბლოკება, რაც დაგეხმარებათ გაიგოთ, თუ რომელი ცხრილი ან ინდექსია ჩართული კონკურენციაში.

4.2.3 დაბლოკვის პრობლემების მოგვარება

მას შემდეგ, რაც დაადგენთ დაბლოკვის სესიას და მის ქმედებებს, რამდენიმე ვარიანტი გექნებათ:

1. დაელოდეთ დასრულებას: თუ მთავარი ბლოკატორი ლეგიტიმურ მოთხოვნას ასრულებს, რომელიც მალე დასრულდება, შესაძლოა უმჯობესი იყოს, მისი ბუნებრივად დასრულების საშუალება მისცეთ.
2. სესიის შეწყვეტა: თუ Head blocker ჩიხშია ან ასრულებს მოთხოვნას, რომელიც უნდა გაუქმდეს:
   • დააწკაპუნეთ მაუსის მარჯვენა ღილაკით სესიაზე პროცესების პანელში.
   • აირჩიეთ პროცესის მოკვლა.
   • დაადასტურეთ მოქმედება დიალოგურ ფანჯარაში.
3. მოთხოვნების ოპტიმიზაცია: თუ დაბლოკვა ერთი და იგივე მოთხოვნებით განმეორდება, ოპტიმიზაცია გაუკეთეთ მათ დაბლოკვის ხანგრძლივობის შესამცირებლად.
4. იზოლაციის დონის რეგულირება: წაკითხვის დიდი რაოდენობით დატვირთვებში დაბლოკვის შესამცირებლად, განიხილეთ READ COMMITTED SNAPSHOT ISOLATION-ის გამოყენება.
5. ინდექსის დარეგულირება: დაამატეთ ინდექსები მოთხოვნების დასაჩქარებლად, რაც შეამცირებს მათში დაბლოკვების შენახვის ხანგრძლივობას.

4.3 პროცესორის მაღალი დატვირთვის ანალიზი

როდესაც „მიმოხილვის“ პანელში პროცესორის დრო მუდმივად 100%-ზე ან მის მახლობლად ჩანს, თქვენ უნდა დაადგინოთ, რომელი მოთხოვნებია პასუხისმგებელი და დაადგინოთ, შესაძლებელია თუ არა მათი ოპტიმიზაცია.

4.3.1 პროცესორის ინტენსიური დატვირთვის მქონე მოთხოვნების იდენტიფიცირება

CPU-ს ჭარბი მოხმარების მოთხოვნების მოსაძებნად:

1. გახსნა ბოლო ძვირადღირებული შეკითხვები პანელი.
2. დალაგება ცენტრალური პროცესორი (მილიწამი/წმ) ყველაზე მეტი CPU დროის გამოყენებით მოთხოვნების საჩვენებლად.
3. გადახედეთ სიაში ყველაზე ხშირად დასმულ შეკითხვებს.
4. დააწკაპუნეთ მაუსის მარჯვენა ღილაკით მაღალი CPU-ს მოთხოვნებზე და აირჩიეთ მოთხოვნის ტექსტის რედაქტირება SQL განცხადების სანახავად.
5. აირჩიეთ შესრულების გეგმის ჩვენება იმის გასაგებად, თუ როგორ სრულდება მოთხოვნა.

ყურადღება მიაქციეთ არა მხოლოდ ინდივიდუალური შეკითხვის CPU-ს დატვირთვას, არამედ შესრულება/წთ სვეტი. მოთხოვნა, რომელიც საშუალო CPU-ს იყენებს თითო შესრულებაზე, მაგრამ წუთში ათასობითჯერ მუშაობს, შეიძლება თქვენი CPU-ს ყველაზე დიდი მომხმარებელი იყოს.

4.3.2 შეკითხვის ოპტიმიზაციის ტექნიკები

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. გახსენით აქტივობის მონიტორი და შეამოწმეთ მიმოხილვა პანელი რესურსების პიკებისთვის იმ დროს.
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 დაინსტალირებულია მთავარ ფაილში, მასზე წვდომა შესაძლებელია ნებისმიერი მონაცემთა ბაზის კონტექსტიდან.

5.2.2 ძირითადი გამოყენების მაგალითები

sp_WhoIsActive-ის გამოყენების უმარტივესი გზაა:

EXEC sp_WhoIsActive;

ეს აბრუნებს შედეგების ნაკრებს, რომელიც აჩვენებს ყველა აქტიურ სესიას მათი მოთხოვნებით, ლოდინის ტიპებით, დაბლოკვის ინფორმაციით და რესურსების გამოყენებით.

ამ პერიოდის განმავლობაში აქტივობის ამსახველი 10-წამიანი ნიმუშისთვის:

EXEC sp_WhoIsActive @delta_interval = 10;

ეს ითვლის დელტას ისეთი მეტრიკებისთვის, როგორიცაა CPU და წაკითხული მონაცემები, და აჩვენებს, თუ რა მოხდა ამ 10 წამის განმავლობაში.

5.2.3 გაფართოებული პარამეტრები

sp_WhoIsActive მხარს უჭერს პერსონალიზაციის მრავალ პარამეტრს:

• @ფილტრი: შედეგების გაფილტვრა კონკრეტული სესიების, მონაცემთა ბაზების ან შესვლების მიხედვით.
• @ფილტრის_ტიპი: მიუთითეთ, თუ რას ეხება ფილტრი (სესია, მონაცემთა ბაზა, შესვლა და ა.შ.).
• @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_monitor: აჩვენებს სტატისტიკას 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-ის დავალებების გამოყენებით

შეგიძლიათ დაგეგმოთ მორგებული მონიტორინგის სკრიპტები გამოყენებით 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 გავლენა სერვერის რესურსებზე

Activity Monitor სისტემის 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 მოკლე მიმოხილვა vs უწყვეტი მონიტორინგი

აქტივობის მონიტორი აჩვენებს თითოეული განახლების ინტერვალის დროს გადაღებულ დროის სნეპშოტებს. სნეპშოტებს შორის მომხდარი მოვლენები არ აღირიცხება. თუ მოთხოვნა 2 წამის განმავლობაში მუშაობს და თქვენ ყოველ 10 წამში აახლებთ, შესაძლოა, ის ერთხელ ან საერთოდ არ ნახოთ, დროის მიხედვით.

ეს ნიშნავს, რომ Activity Monitor შესანიშნავად ახერხებს მუდმივი პრობლემების (ხანგრძლივი ბლოკირება, მუდმივად მაღალი CPU დატვირთვა) აღმოჩენას, მაგრამ შეიძლება გამოტოვოს დროებითი პრობლემები (ხანმოკლე ჩიხები, ხანდახან მოთხოვნის პიკები).

6.3.2 აგრეგაცია და შერჩევა

ბოლო ძვირადღირებული მოთხოვნების პანელი აჩვენებს ქეში შესული შეკითხვის გეგმების შემდეგ აგრეგირებულ მონაცემებს. ორი იდენტური მოთხოვნა სხვადასხვა პარამეტრის მნიშვნელობებით ერთ რიგში გამოჩნდება, თუ ისინი იზიარებენ გეგმას. ამ აგრეგაციას შეუძლია შენიღბოს პრობლემები კონკრეტული პარამეტრების კომბინაციებთან (პარამეტრების სნიფიკაციის პრობლემები).

რესურსების მოლოდინის პანელი ითვლის მაჩვენებლებს სნეპშოტების შედარებით. თუ მოლოდინის სტატისტიკა გადაყენდება სნეპშოტებს შორის (იშვიათად, მაგრამ შესაძლებელია), გამოთვლილი მაჩვენებლები შეიძლება არასწორი იყოს.

6.4 როდის არ უნდა გამოიყენოთ აქტივობის მონიტორი

Activity Monitor ყველა მონიტორინგის სცენარისთვის შესაფერისი არ არის. გაარკვიეთ, როდის არის ალტერნატიული ინსტრუმენტები უკეთესი არჩევანი.

6.4.1 ისტორიული ანალიზის მოთხოვნები

Activity Monitor აჩვენებს მხოლოდ მიმდინარე ან ბოლო აქტივობას. ის არ ინახავს ისტორიულ მონაცემებს. თუ გჭირდებათ დღეების ან კვირების ტენდენციების ანალიზი, მიმდინარე შესრულების საბაზისო მაჩვენებლებთან შედარება ან შესრულების ნიმუშების შესახებ ანგარიშების გენერირება, Activity Monitor საკმარისი არ არის.

ისტორიული ანალიზისთვის გამოიყენეთ 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 სწრაფი ჯანმრთელობის შემოწმება

Activity Monitor გთავაზობთ შესანიშნავ დაფას რუტინული გამოყენების დროს სწრაფი ჯანმრთელობის შემოწმებისთვის. გახსენით ის, გადახედეთ მიმოხილვის გრაფიკებს და დარწმუნდით, რომ არაფერი არ არის უჩვეულო.

ეს ზედაპირული შემოწმება წამებს გრძელდება და პრობლემების გამოვლენას კრიტიკულ ფორმაში გადასვლამდეც კი შეძლებს. ეს თქვენი ყოველდღიური რუტინის ნაწილად აქციეთ.

7.2 ოპტიმალური კონფიგურაციის პარამეტრები

Activity Monitor-ის სათანადოდ კონფიგურაცია აუმჯობესებს როგორც მის სარგებლიანობას, ასევე რესურსების მოხმარებას.

7.2.1 რეკომენდებული განახლების ინტერვალები

შეუსაბამეთ განახლების ინტერვალი თქვენს მიზანს:

• აქტიური პრობლემების მოგვარება: 10 წამი უზრუნველყოფს კარგ რეაგირებას გონივრული დატვირთვით.
• გაფართოებული მონიტორინგი: 30-60 წამი ამცირებს სერვერზე ზემოქმედებას ხანგრძლივი დაკვირვების პერიოდების დროს.
• კრიტიკული პრობლემის დიაგნოზი: 5 წამი იძლევა მაღალ დეტალიზაციას, როდესაც ყოველი წამი ითვლება, მაგრამ გამოიყენეთ ხანმოკლედ.
• რეგულარული ჯანმრთელობის შემოწმებები: ხელით განახლება (1 საათიანი ინტერვალი), როდესაც აქტიურად არ უყურებთ.

არ დაგავიწყდეთ აქტივობის მონიტორის დახურვა დასრულების შემდეგ. მისი ხანგრძლივი ინტერვალით დაყენება და მისი დავიწყება სერვერის რესურსებს კარგავს.

7.2.2 ფილტრაციის სტრატეგიები

გამოიყენეთ ფილტრები შესაბამის ინფორმაციაზე ფოკუსირებისა და კოგნიტური დატვირთვის შესამცირებლად:

• პროცესების გაფილტვრა მონაცემთა ბაზა მხოლოდ კონკრეტულ მონაცემთა ბაზებთან დაკავშირებული აქტივობის სანახავად.
• გაფილტრე შესვლა კონკრეტული მომხმარებლის აქტივობის თვალყურის დევნებისთვის.
• გაფილტრე დავალების მდგომარეობა = RUNNING უმოქმედო სესიების დასამალად.
• გაფილტრე განაცხადის კონკრეტული პროგრამებიდან ტრაფიკის იზოლირებისთვის.
• მხოლოდ არა-ცარიელი ფაილების ჩვენება დაბლოკილია მხოლოდ ბლოკირების სიტუაციების სანახავად.

7.2.3 სვეტების შერჩევა და დახარისხება

შეიმუშავეთ სისტემატური მიდგომა Activity Monitor-ის მონაცემების განხილვისთვის:

1. დაიწყეთ მიმოხილვით: შეამოწმეთ გრაფიკები აშკარა პიკების ან ანომალიების აღმოსაჩენად.
2. შეამოწმეთ დაბლოკვის პროცესები: დაალაგეთ სესიის ID-ის მიხედვით, შემდეგ მოძებნეთ დაბლოკილის მნიშვნელობები.
3. რესურსების განხილვის ლოდინის დრო: დაალაგეთ კუმულაციური ლოდინის დროის მიხედვით, რესურსების შეფერხების დასადგენად.
4. ძვირადღირებული შეკითხვების ანალიზი: სხვადასხვა ტიპის პრობლემების მოსაძებნად დაალაგეთ სხვადასხვა მეტრიკის (CPU, შესრულებები, წაკითხვები) მიხედვით.
5. გადამოწმება I/O პანელით: დაადასტურეთ, კორელაციაშია თუ არა შეყვანა/გამოყვანის ინტენსიური მოთხოვნები დისკის მაღალ აქტივობასთან.

7.3 სხვა ინსტრუმენტებთან ინტეგრაცია

Activity Monitor საუკეთესოდ მუშაობს უფრო ფართო ინსტრუმენტარიუმის ნაწილად, ვიდრე დამოუკიდებელი გადაწყვეტის სახით.

7.3.1 გამოყენება SQL Server პროფილი

აქტივობის მონიტორი და SQL Server პროფილირები ერთმანეთს კარგად ავსებენ. როდესაც 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 სერვერის მდგომარეობის შესახებ ერთ პერსპექტივას გვთავაზობს. ნუ დაეყრდნობით მხოლოდ მას. დაამატეთ Windows Performance Monitor ოპერაციული სისტემის დონის მეტრიკისთვის, Extended Events დეტალური თვალყურის დევნებისთვის და შესრულების გეგმის ანალიზი მოთხოვნების რეგულირებისთვის.

Activity Monitor დაგეხმარებათ პრობლემების იდენტიფიცირებაში, თუმცა მათი გადაჭრა ხშირად დამატებით ინსტრუმენტებს და უფრო ღრმა ანალიზს მოითხოვს.

შეიტყვეთ უფრო მეტი SQL Server შესრულების მონიტორი ჩვენს სრული გზამკვლევი.

7.4.3 ისტორიული ტენდენციების იგნორირება

აქტივობის მონიტორი აჩვენებს მიმდინარე მდგომარეობას, თუმცა შესრულების პრობლემები ხშირად მხოლოდ დროთა განმავლობაში ჩანს. დანერგეთ ისტორიული მონაცემების შეგროვება, რათა შეძლოთ მიმდინარე მეტრიკების შედარება საბაზისო მაჩვენებლებთან და ტენდენციების იდენტიფიცირება.

ისტორიული კონტექსტის გარეშე, შეიძლება ვერ მიხვდეთ, რომ დღევანდელი „ნორმალური“ პროცესორის გამოყენება გასული თვის საბაზისო მაჩვენებელთან შედარებით 30%-ით მეტია, რაც თანდათანობით გაუარესებაზე მიუთითებს.

8. აქტივობის მონიტორის პრობლემების მოგვარება

Activity Monitor-ს ხანდახან პრობლემები ექმნება. ამ პრობლემების მოგვარების ცოდნა იმედგაცრუებას აგარიდებთ.

8.1 აქტივობის მონიტორი არ იხსნება ან მონაცემებს არ აჩვენებს

როდესაც აქტივობის მონიტორი იხსნება, მაგრამ აჩვენებს ცარიელ პანელებს ან საერთოდ არ იხსნება, შესაძლოა, რამდენიმე ფაქტორი იყოს პასუხისმგებელი.

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 ვერსიამ შეიძლება გამოიწვიოს აქტივობის მონიტორის გაუმართაობა. ინსტრუმენტმა შეიძლება ვერ გაიგოს ახალი ლოდინის ტიპები ან სისტემის ხედვის სვეტები.

ყოველთვის გამოიყენეთ SSMS ვერსია, რომელიც ემთხვევა ან უფრო ახალია, ვიდრე თქვენი SQL Server ვერსია. Microsoft გთავაზობთ უახლეს SSMS-ს უფასოდ ჩამოსატვირთად, ცალკე SQL Server თავად.

8.1.3 ფაირვოლისა და ქსელის პრობლემები

აქტივობის მონიტორს სჭირდება კავშირი 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-ის ავთენტიფიკაციასთან დაკავშირება: თუ 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 არაზუსტი ან დაკარგული ინფორმაცია

ზოგჯერ აქტივობის მონიტორი აჩვენებს ინფორმაციას, რომელიც არასწორი ან არასრულია.

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 მონაცემთა განახლების დროის გაგება

გახსოვდეთ, რომ აქტივობის მონიტორი აჩვენებს სნეპშოტებს. განახლების ინტერვალებს შორის შესრულებული მოთხოვნა არ გამოჩნდება ბოლო ძვირადღირებული მოთხოვნების სიაში, თუ მისი შესრულების გეგმა ქეშში არ დარჩება.

ანალოგიურად, რესურსების მოლოდინის პანელში ლოდინის სტატისტიკა ასახავს ბოლო სურათის შემდეგ დაგროვებას. სწრაფად ცვალებად სამუშაო დატვირთვებმა შეიძლება თითოეული განახლებისას განსხვავებული ნიმუშები აჩვენოს.

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 რესურსების ტენდენციის ანალიზი

მიუხედავად იმისა, რომ აქტივობის მონიტორი აჩვენებს მიმდინარე მდგომარეობას, მისი გამოყენება შეგიძლიათ ტენდენციების შესამოწმებლად, ძირითადი მეტრიკების დროთა განმავლობაში ჩაწერით:

• გადაიღეთ მიმოხილვის პანელის ეკრანის ანაბეჭდები ყოველდღე ერთსა და იმავე დროს
• ჩაწერეთ პიკური მნიშვნელობები თითოეული გრაფიკიდან
• შეადარეთ კვირები ერთმანეთს ზრდის ტენდენციების დასადგენად
• დააკვირდით საშუალო პროცესორის დროის ან შეყვანის/გამოყვანის სიჩქარის თანდათანობით ზრდას

ეს სახელმძღვანელო ტენდენციები ავსებს უფრო დახვეწილ მონიტორინგის გადაწყვეტილებებს და ხელს უწყობს სიმძლავრის გაფართოების გამართლებას.

9.3 შესრულების საბაზისო მაჩვენებლების დოკუმენტირება

საბაზისო შესრულების მეტრიკის დადგენა დაგეხმარებათ იმის ამოცნობაში, თუ როდის უარესდება შესრულება.

9.3.1 საბაზისო მეტრიკების აღრიცხვა

ცნობილი კარგი შესრულების პერიოდებში, აქტივობის მონიტორის მეტრიკების დოკუმენტირება:

1. გახსენით აქტივობის მონიტორი ჩვეულებრივი ბიზნეს ოპერაციების დროს (არა პიკის ან არაპიკის საათებში).
2. ჩანაწერების მიმოხილვის პანელის მნიშვნელობები:
   • ტიპიური % პროცესორის დროის დიაპაზონი
   • ლოდინის საშუალო დავალებების რაოდენობა
   • მონაცემთა ბაზის შეყვანის/გამოყვანის ნორმალური სიჩქარე
   • ტიპური პარტიული მოთხოვნები/წმ
3. გაითვალისწინეთ რესურსების ლოდინის პანელის კატეგორიები, რომლებიც ყველაზე მეტ ლოდინის დროს აჩვენებს.
4. როგორც წესი, პროცესების პანელში დააფიქსირეთ აქტიური პროცესების რაოდენობა.
5. ჩაწერეთ წარმომადგენლობითი შეკითხვის შესრულების მეტრიკა ბოლო ძვირადღირებული შეკითხვებიდან.

შეინახეთ ეს საბაზისო დოკუმენტაცია მომავალი მითითებისთვის, როდესაც მუშაობთ მუშაობის პრობლემებზე.

9.3.2 მიმდინარე და საბაზისო მაჩვენებლების შედარება

როდესაც მუშაობის პრობლემები წარმოიქმნება, შეადარეთ აქტივობის მონიტორის მიმდინარე მაჩვენებლები თქვენს მიერ დოკუმენტირებულ საწყის მაჩვენებელს:

• პროცესორის დრო მნიშვნელოვნად აღემატება საბაზისო მაჩვენებელს? ყურადღება გაამახვილეთ პროცესორის ინტენსიურად მომთხოვნ მოთხოვნებზე.
• ლოდინის დავალებები საბაზისო დონესთან შედარებით 2-3-ჯერ მეტია? გამოიკვლიეთ რესურსების ლოდინის დრო.
• შეყვანა/გამოსვლა მნიშვნელოვნად მაღალია? შეამოწმეთ მონაცემთა ფაილის შეყვანა/გამოყვანის პანელი და ძვირადღირებული მოთხოვნები.
• პიკის საათებში პაკეტური მოთხოვნები საბაზისო მაჩვენებელზე დაბალია? მოძებნეთ დაბლოკვის ან კავშირის პრობლემები.

ეს შედარება დაგეხმარებათ იმის დადგენაში, თუ რა შეიცვალა და შესაბამისად, პრობლემების მოგვარების მცდელობებს მიმართოთ.

9.4 მონიტორინგის სამუშაო პროცესების შექმნა

შეიმუშავეთ სისტემატური სამუშაო პროცესები საერთო საგამოძიებო სცენარებისთვის, რათა უზრუნველყოთ საფუძვლიანი და განმეორებადი ანალიზი.

9.4.1 ეტაპობრივი გამოძიების პროცესი

როდესაც მომხმარებლები მუშაობის პრობლემებს აფიქსირებენ, დაიცავით თანმიმდევრული სამუშაო პროცესი:

1. სწრაფი ჯანმრთელობის შემოწმება: გახსენით აქტივობის მონიტორი და დაასკანირეთ მიმოხილვის პანელის გრაფიკები აშკარა ანომალიების აღმოსაჩენად.
2. შეამოწმეთ დაბლოკვა: გაშალეთ პროცესების პანელი, გაფილტრეთ არაცარიელი ფაილები დაბლოკილი სვეტში.
3. რესურსებს შორის დაპირისპირების იდენტიფიცირება: გადახედეთ რესურსების ლოდინის პანელს, რომელიც დალაგებულია ლოდინის დროის მიხედვით.
4. ძვირადღირებული შეკითხვების მოძიება: შეამოწმეთ ბოლო ძვირადღირებული მოთხოვნები, დალაგებული CPU-ს, შემდეგ შესრულების და შემდეგ წაკითხვის მიხედვით.
5. შეყვანის/გამოყვანის შაბლონების კორელაცია: ძვირადღირებული მოთხოვნების ჯვარედინი მითითება მონაცემთა ფაილის შეყვანის/გამოყვანის პანელის აქტივობასთან.
6. დოკუმენტის დასკვნები: გადაიღეთ ეკრანის ანაბეჭდები და ჩაიწერეთ შესაბამისი სესიის ID-ები, ლოდინის ტიპები და შეკითხვის დეტალები.
7. ღრმა ჩაყვინთვა: გამოვლენილი პრობლემების დეტალური გამოკვლევისთვის გამოიყენეთ Profiler-ის კვალი, შესრულების გეგმის ანალიზი და DMV მოთხოვნები.

9.4.2 ესკალაციის კრიტერიუმები

დაადგინეთ კრიტერიუმები, თუ როდის უნდა მოხდეს საკითხების ესკალაცია გამოძიების გაგრძელების ნაცვლად:

• დაუყოვნებლივ გააძლიერეთ სიტუაცია: ბლოკირების ჯაჭვები 5 წუთზე მეტხანს გრძელდება, პროცესორის მუშაობის დრო 100%-ზე 2 წუთზე მეტხანს, კრიტიკული სისტემური პროცესები შეჩერებულ მდგომარეობაშია.
• ანალიზით ესკალაცია: განმეორებადი ძვირადღირებული მოთხოვნები, რომლებიც მოიხმარენ >50%-ს პროცესორისთვის, მუდმივად მაღალი შეყვანა/გამოყვანის რეაგირების დრო >50 მილიწამი, მეხსიერების მინიჭების განმეორებითი შეუსრულებლობა.
• დამატებითი გამოკვლევა: დროებითი ლოდინი რამდენიმე წუთში წყდება, მოთხოვნები არაოპტიმალური გეგმებით, მაგრამ მისაღები შესრულებით, მცირე ბლოკირება <30 წამის ხანგრძლივობით.

10. აქტივობის მონიტორი სხვადასხვა SQL Server ვერსიები

აქტივობის მონიტორი განვითარდა SQL Server ვერსიები, სადაც თითოეული გამოშვება გაუმჯობესებებსა და ზოგჯერ ახალ საკითხებსაც მოაქვს.

10.1 აქტივობის მონიტორი SQL Server 2008 და შემდგომი

SQL Server 2008 წელს წარმოდგენილი იყო თანამედროვე Activity Monitor-ის დიზაინი, რომელიც დღესაც დიდწილად უცვლელია.

10.1.1 ახალი ფუნქციები, რომლებიც წარმოდგენილია SQL Server 2008

ის SQL Server 2008 წლის აქტივობის მონიტორის რედიზაინმა მნიშვნელოვანი გაუმჯობესებები მოიტანა:

• გრაფიკული დაფა რეალურ დროში დიაგრამებით მიმოხილვის პანელში
• გაფართოებადი/დასაკეცი პანელის ინტერფეისი, რომელიც ცვლის ძველ, მხოლოდ ბადისებრ ხედს
• ბოლო ძვირადღირებული მოთხოვნების პანელი, რომელიც აჩვენებს შეკითხვის შესრულების ჯამურ მონაცემებს
• მონაცემთა ფაილის შეყვანის/გამოყვანის პანელი დისკის აქტივობის მონიტორინგისთვის თითოეული ფაილისთვის
• გაუმჯობესებული რესურსების მოლოდინის პანელი მოლოდინის კატეგორიზაციით
• პროცესის ისეთი მოქმედებებისთვის, როგორიცაა სესიების შეწყვეტა და Profiler-ის გაშვება, დააწკაპუნეთ მარჯვენა ღილაკით კონტექსტურ მენიუში.
• კონფიგურირებადი განახლების ინტერვალები 1 წამიდან 1 საათამდე

ამ ცვლილებებმა Activity Monitor მარტივი პროცესების სიიდან ყოვლისმომცველ მონიტორინგის დაფად გარდაქმნა.

10.1.2 ცვლილებები SQL Server 2005

SQL Server 2005 წლის Activity Monitor გაცილებით შეზღუდული იყო:

• წვდომა შესაძლებელია ობიექტების მკვლევარის მართვის საქაღალდის მეშვეობით, ხელსაწყოთა ზოლის ნაცვლად.
• ერთიანი ბადე, რომელიც აჩვენებს პროცესების სიას ძირითადი ინფორმაციით
• გრაფიკული დიაგრამები ან მრავალი პანელი არ არის
• ძვირადღირებული შეკითხვების ან შეყვანის/გამოყვანის მონიტორინგის გარეშე
• შეზღუდული ლოდინის სტატისტიკის ინფორმაცია

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 წლების აქტივობის მონიტორი მოიცავს:

• ამ ვერსიებში დანერგილი ახალი ლოდინის ტიპების მხარდაჭერა
• გაუმჯობესებული რენდერინგის შესრულება SSMS-ში WPF ტექნოლოგიის გამოყენებით
• აქტიური სესიების დიდი რაოდენობის უკეთ დამუშავება
• გაუმჯობესებული თავსებადობა ღრუბლოვან 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 და დაათვალიერეთ მიმოხილვის პანელი:

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-ჯერ არ უნდა შესრულდეს.

დააწკაპუნეთ მაუსის მარჯვენა ღილაკით მოთხოვნაზე და აირჩიეთ შესრულების გეგმის ჩვენებაგეგმა აჩვენებს მომხმარებლების ცხრილის სკანირებას UserId სვეტში ინდექსის დაკარგვის შესახებ გაფრთხილებით.

გაფილტრეთ „პროცესების“ პანელი აპლიკაციის მიხედვით, რათა მხოლოდ ვებ აპლიკაციის კავშირები აჩვენოთ. მრავალი სესია აჩვენებს, რომ ერთი და იგივე მოთხოვნა განმეორებით მუშაობს.

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 ბლოკირების ჯაჭვის აღმოჩენა

გახსენით აქტივობის მონიტორი ამ გაყინვის მოვლენებიდან ერთ-ერთის დროს და გაშალეთ პროცესების პანელი:

1. დალაგება სხდომის ID ყველა ორგანიზებული სესიის სანახავად.
2. მრავალი სესია აჩვენებს მნიშვნელობებს დაბლოკილია სვეტი, ყველა მიუთითებს სესიის 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-ით და პოტენციურად მესამე მხარის ინსტრუმენტებით დამატება ქმნის ყოვლისმომცველ მონიტორინგის სტრატეგიას.
• განახლების ინტერვალების საუკეთესო პრაქტიკის დაცვა, აქტივობის მონიტორის გამოუყენებლობის შემთხვევაში დახურვა და კორელაციისთვის მრავალი პანელის გაერთიანება მაქსიმალურად ზრდის მის ღირებულებას და ამავდროულად ამცირებს მის გავლენას.

13.2 აქტივობის მონიტორი, როგორც თქვენი ინსტრუმენტების ნაკრების ნაწილი

Activity Monitor უნდა იყოს თქვენი პირველი რეაგირების ინსტრუმენტი შესრულების შესწავლისთვის და არა ერთადერთი. მისი ძლიერი მხარე მდგომარეობს იმაში, რომ აქტიური პრობლემების გადაჭრისას დაუყოვნებლივ უზრუნველყოფს ხილვადობას, რაც დაგეხმარებათ სწრაფად განსაზღვროთ, წარმოადგენს თუ არა მონაცემთა ბაზა შეფერხების ადგილს და განსაზღვროთ, რომელი კონკრეტული ასპექტები საჭიროებს უფრო ღრმა კვლევას.

წარმოიდგინეთ აქტივობის მონიტორი, როგორც თქვენი მანქანის დაფის ანალოგი - ის დაუყოვნებლივ გაჩვენებთ, თუ რამე არ არის რიგზე და დაგეხმარებათ პრობლემის ზოგადი არეალის იდენტიფიცირებაში. ისევე, როგორც თქვენი მანქანის დაფა არ გეუბნებათ ზუსტად, თუ რატომ ანათებდა ძრავის შემოწმების ინდიკატორი, აქტივობის მონიტორი მიგითითებთ პრობლემებზე, მათი სრული გამომწვევი მიზეზის გამოვლენის გარეშე. უფრო ღრმა ანალიზისთვის საჭიროა დამატებითი ინსტრუმენტები და ექსპერტიზა.

ინტეგრირეთ Activity Monitor უფრო ფართო ინსტრუმენტარიუმის ნაკრებში, რომელიც მოიცავს შესრულების გეგმის ანალიზს, ლოდინის სტატისტიკის თვალყურის დევნებას, ისტორიული მონიტორინგის გადაწყვეტილებებს და შესრულების საუკეთესო პრაქტიკას. გამოიყენეთ ის შესაბამის ინდექსირების სტრატეგიებთან, შეკითხვის ოპტიმიზაციის ტექნიკასთან და შესაძლებლობების დაგეგმვასთან ერთად.

13.3 სწავლის გაგრძელება

Activity Monitor-ის დაუფლება მხოლოდ ერთი ნაბიჯია მონაცემთა ბაზის ეფექტური ადმინისტრატორის გახდომის გზაზე. გააგრძელეთ თქვენი უნარების განვითარება შემდეგი გზით:

• შესრულების გეგმების ინტერპრეტაციის სწავლა და არაეფექტური ოპერაციების იდენტიფიცირება
• გაგება SQL Server ლოდინის სტატისტიკა და მათი შედეგები
• ინდექსის დიზაინისა და ოპტიმიზაციის ტექნიკის შესწავლა
• შეისწავლის SQL Server-ის არქიტექტურა და როგორ ამუშავებს ის შეკითხვებს
• პრობლემების მოგვარების სისტემატური მეთოდოლოგიების პრაქტიკა
• გამოცდილების მიღება გაფართოებული ღონისძიებებით დეტალური თვალყურის დევნებისთვის
• ტრანზაქციების იზოლაციის დონეების და მათი შესრულების გავლენის გაგება

Activity Monitor-ის თითოეული შესრულების კვლევა გასწავლით რაიმე ახალს იმის შესახებ, თუ როგორ SQL Server აპლიკაციების მუშაობა და მონაცემთა ბაზებთან ურთიერთქმედება. დააფიქსირეთ თქვენი დასკვნები, გაუზიარეთ ცოდნა კოლეგებს და შექმენით საერთო პრობლემების გადაჭრის ბიბლიოთეკა.

13.4 დამატებითი რესურსები

გააფართოვეთ თქვენი ცოდნა ამ ღირებული რესურსების დახმარებით:

• გახსენით აქტივობის მონიტორი SQL Server მართვის სტუდია (SSMS) : ოფიციალური SQL Server დოკუმენტაცია, თუ როგორ გახსნათ Activity Monitor-ში SQL Server მენეჯმენტის სტუდია (SSMS).
• საქმიანობის მონიტორი ოფიციალური SQL Server დოკუმენტი, თუ როგორ გამოიყენოთ აქტივობის მონიტორი.

14. ხშირად დასმული კითხვები (FAQ)

_ რა არის SQL Server აქტივობის მონიტორი?

A: SQL Server აქტივობის მონიტორი არის ჩაშენებული ინსტრუმენტი SQL Server მენეჯმენტის სტუდია, რომელიც აჩვენებს რეალურ დროში ინფორმაციას მასზე გაშვებული პროცესების შესახებ. SQL Server ინსტანცია და მათი გავლენა სერვერის რესურსებზე. ის გთავაზობთ გრაფიკულ დაფას ხუთი პანელით, რომლებიც აჩვენებს სერვერის აქტივობის სხვადასხვა ასპექტს, მათ შორის პროცესორის გამოყენებას, ლოდინის დავალებებს, შეყვანა/გამოყვანის სიჩქარეს, აქტიურ სესიებს და ძვირადღირებულ შეკითხვებს.

კითხვა: როგორ გავხსნა Activity Monitor SSMS-ში?

A: Activity Monitor-ის გახსნა შეგიძლიათ ოთხი მეთოდის გამოყენებით: (1) დააწკაპუნეთ Activity Monitor-ის ხატულაზე SSMS ხელსაწყოთა პანელზე, (2) დააწკაპუნეთ მაუსის მარჯვენა ღილაკით SQL Server ინსტანციის სახელი ობიექტის მკვლევარში და აირჩიეთ საქმიანობის მონიტორი, (3) დააჭირეთ Ctrl + Alt + A, ან (4) დააკონფიგურირეთ SSMS ავტომატურად გასაშვებად ინსტრუმენტები -> პარამეტრები -> გარემოს -> Startup.

კითხვა: რა ნებართვები მჭირდება Activity Monitor-ის გამოსაყენებლად?

ა: თქვენ გჭირდებათ სერვერის მდგომარეობის ნახვა აქტივობის მონიტორის ინფორმაციის უმეტესობის ნახვის ნებართვა. მონაცემთა ფაილის შეყვანის/გამოყვანის პანელისთვის ასევე დაგჭირდებათ: შექმენით მონაცემთა ბაზა, ნებისმიერი მონაცემთა ბაზის შეცვლა, ან იხილეთ ნებისმიერი განმარტება ნებართვები. ამ ნებართვების გარეშე, Activity Monitor-მა შეიძლება გახსნას, მაგრამ ცარიელი პანელები აჩვენოს.

კითხვა: რატომ არის ჩემი აქტივობის მონიტორი შეჩერებული ან არ მუშაობს?

A: Activity Monitor, როგორც წესი, ჩერდება ნებართვებთან დაკავშირებული პრობლემების, SSMS-ის მოძველებული ვერსიების ან დისტანციური კავშირების გამორთვის გამო. პრობლემის გადასაჭრელად: (1) განაახლეთ SSMS-ის უახლეს ვერსიამდე, (2) დარწმუნდით, რომ გაქვთ VIEW SERVER STATE-ის ნებართვა, (3) შეამოწმეთ, რომ დისტანციური კავშირები ჩართულია SQL Server მაგალითად, (4) გადატვირთეთ SSMS და (5) თუ შესაძლებელია, სცადეთ Windows-ის ავთენტიფიკაციით დაკავშირება SQL ავთენტიფიკაციის ნაცვლად.

კითხვა: რა განსხვავებაა Activity Monitor-სა და sp_WhoIsActive-ს შორის?

A: 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-ის გამოყენებით?

A: დიახ, Activity Monitor აგზავნის მოთხოვნას სისტემის დინამიური მართვის ხედებზე, როგორიცაა sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_wait_stats და sys.dm_exec_query_stats. თქვენ შეგიძლიათ პირდაპირ გაუგზავნოთ მოთხოვნა ამ DMV-ებს T-SQL-ის გამოყენებით, პროგრამულად მიიღოთ ექვივალენტური ინფორმაცია, რაც საშუალებას მოგცემთ შექმნათ მორგებული მონიტორინგის სკრიპტები და ავტომატიზირებული მონაცემთა შეგროვება.

კითხვა: რა არის ნაგულისხმევი განახლების ინტერვალი?

A: ნაგულისხმევი განახლების ინტერვალი 10 წამია. ამის შეცვლა შეგიძლიათ მიმოხილვის პანელში ნებისმიერ ადგილას მაუსის მარჯვენა ღილაკით დაწკაპუნებით და არჩევით განახლების ინტერვალიდა წინასწარ განსაზღვრული ვარიანტებიდან არჩევანის გაკეთება: 1 წამი, 5 წამი, 10 წამი, 30 წამი, 1 წუთი ან 1 საათი. უფრო დაბალი ინტერვალები უზრუნველყოფს რეალურ დროში ხედების მეტ რაოდენობას, მაგრამ ზრდის მონიტორინგის ხარჯებს.

კითხვა: როგორ შემიძლია ავტომატურად გავხსნა Activity Monitor SSMS-ის გაშვებისას?

A: ავტომატური გაშვების კონფიგურაცია SSMS პარამეტრების მეშვეობით: გადადით ინსტრუმენტები -> პარამეტრები -> გარემოს -> Startup, მაშინ აირჩიეთ გახსენით ობიექტის მკვლევარი და აქტივობის მონიტორი დან გაშვების დროს ჩამოსაშლელი სია. Activity Monitor ავტომატურად გაიხსნება ყოველ ჯერზე, როდესაც SSMS-ში სერვერს დაუკავშირდებით.

კითხვა: რა შეზღუდვები აქვს Activity Monitor-ს?

A: ძირითადი შეზღუდვები მოიცავს: (1) ისტორიული მონაცემების შენახვის ან ტენდენციების თვალყურის დევნების შესაძლებლობების არარსებობა, (2) ლოდინის ტიპები დაჯგუფებულია კატეგორიებად და არა კონკრეტულად ნაჩვენები, (3) ზოგიერთი ლოდინის ტიპი, როგორიცაა CXPACKET, შეიძლება არ გამოჩნდეს, (4) დროის სნეპშოთებმა შეიძლება გამოტოვოს გარდამავალი პრობლემები, (5) ზედაპირული ხარჯების მონიტორინგმა შეიძლება გავლენა მოახდინოს დატვირთულ სერვერებზე, (6) პროაქტიული მონიტორინგის გამაფრთხილებელი მექანიზმის არარსებობა და (7) მონაცემების რამდენიმე მონაკვეთზე აგრეგირება შეუძლებელია. SQL Server შემთხვევები. ამ საჭიროებებისთვის, შეავსეთ Activity Monitor გაფართოებული მოვლენებით, მონაცემთა შეგროვების ნაკრებებით ან მესამე მხარის მონიტორინგის ინსტრუმენტებით.

---

ავტორის შესახებ

იუან შენგი არის მონაცემთა ბაზის უფროსი ადმინისტრატორი (DBA) 10 წელზე მეტი გამოცდილებით SQL Server გარემოსა და საწარმოს მონაცემთა ბაზის მართვაში. მან წარმატებით გადაჭრა მონაცემთა ბაზის აღდგენის ასობით სცენარი ფინანსურ სერვისებში, ჯანდაცვისა და წარმოების ორგანიზაციებში.

იუანი სპეციალიზირებულია SQL Server მონაცემთა ბაზის აღდგენა, მაღალი ხელმისაწვდომობის გადაწყვეტილებებიდა მუშაობის ოპტიმიზაცია. მისი ფართო პრაქტიკული გამოცდილება მოიცავს მრავალტერაბაიტიანი მონაცემთა ბაზების მართვას, Always On Availability Groups-ის დანერგვას და კრიტიკულად მნიშვნელოვანი ბიზნეს სისტემებისთვის ავტომატური სარეზერვო ასლისა და აღდგენის სტრატეგიების შემუშავებას.

თავისი ტექნიკური ექსპერტიზისა და პრაქტიკული მიდგომის წყალობით, იუანი ფოკუსირებულია ყოვლისმომცველი სახელმძღვანელოების შექმნაზე, რომლებიც მონაცემთა ბაზის ადმინისტრატორებსა და IT სპეციალისტებს დაეხმარება რთული საკითხების გადაჭრაში. SQL Server ეფექტურად უწევს გამოწვევებს. ის მუდმივად ადევნებს თვალყურს უახლეს ამბებს SQL Server რელიზები და Microsoft-ის განვითარებადი მონაცემთა ბაზის ტექნოლოგიები, რეგულარულად ამოწმებს აღდგენის სცენარებს იმის უზრუნველსაყოფად, რომ მისი რეკომენდაციები ასახავდეს რეალურ სამყაროს საუკეთესო პრაქტიკას.

გაქვთ შეკითხვები SQL Server აღდგენა ან გჭირდებათ დამატებითი რჩევები მონაცემთა ბაზის პრობლემების მოგვარებაში? იუანი სიამოვნებით მოგმართავთ. გამოხმაურება და წინადადებები ამ ტექნიკური რესურსების გასაუმჯობესებლად.