SQL Server Aktivitāšu monitors: pilnīgs ceļvedis datubāzes administratoriem [2026]

1. Ievads

1.1 Kas ir SQL Server ActivityMonitor?

SQL Server Aktivitāšu monitors ir iebūvēts diagnostikas rīks.ostic rīks iekšpusē SQL Server Vadības studija, kas parāda informāciju par SQL Server procesi un to ietekme uz servera veiktspēju. Tas ļauj izsekot SQL Server procesus, uzraudzīt resursu gaidīšanas, analizēt dārgus vaicājumus un novērot I/O modeļus — tas viss no viena interfeisa.

1.2 Kāpēc lietot SQL Server ActivityMonitor?

Aktivitāšu monitors kalpo kā jūsu pirmā aizsardzības līnija veiktspējas problēmu novēršanā. Tas nodrošina tūlītēju ieskatu jūsu ierīcē notiekošajā. SQL Server instancē, neprasot sarežģītus T-SQL vaicājumus vai trešo pušu rīkus.

Šis rīks lieliski palīdz ātri identificēt bieži sastopamas problēmas, piemēram, sesiju bloķēšanu, centrālā procesora ietilpīgus vaicājumus, pārmērīgu vaicājumu izpildi un ievades/izvades sastrēgumus. Kad lietotāji ziņo, ka lietojumprogramma darbojas lēni vai nereaģē, aktivitāšu monitors palīdz noteikt, vai vaininieks ir datubāzes serveris.

Datu bāzu administratoriem, kuri nestrādā ar SQL Server Katru dienu aktivitāšu monitors piedāvā pieejamu piekļuves punktu servera aktivitātes izpratnei. Pat pieredzējuši datubāzes administratori to izmanto kā savu risinājumu.tarveiktspējas pārbaužu punkts.

1.3 Aktivitāšu monitors salīdzinājumā ar citiem uzraudzības rīkiem

Lai gan aktivitāšu monitors ir vērtīgs, ir svarīgi saprast, kā tas salīdzināms ar citām uzraudzības iespējām:

Aktivitāšu monitors salīdzinājumā ar sp_WhoIsActive: Aktivitāšu monitors nodrošina grafisku saskarni ar vairākām rūtīm, savukārt sp_WhoIsActive ir visaptveroša saglabātā procedūra, kas piedāvā detalizētāku informāciju vienā rezultātu kopā. sp_WhoIsActive parāda konkrētus gaidīšanas veidus, ko Aktivitāšu monitors grupē kopā, un sniedz detalizētāku informāciju par bloķēšanu.

Aktivitāšu monitors salīdzinājumā ar sp_who2: Tradicionālā sp_who2 komanda parāda sesijas pamatinformāciju, bet Activity Monitor iet tālāk, attēlojot gaidīšanas statistiku, dārgus vaicājumus un I/O metriku organizētā, vizuālā formātā.

Aktivitāšu monitors salīdzinājumā ar trešo pušu rīkiem: Komerciāli uzraudzības risinājumi, piemēram, SolarWinds Database Performance Analyzer, piedāvā vēsturisko izsekošanu, brīdināšanu un uzlabotu analītiku, kas Activity Monitor nav pieejama. Tomēr Activity Monitor nav nepieciešama papildu palīdzība.ost vai uzstādīšana.

1.4 Galvenās priekšrocības datubāzu administratoriem

Aktivitāšu monitors piedāvā vairākas priekšrocības, kas padara to par būtisku DBA rīku:

• Nulle Cost: Kā iebūvēts SQL Server Management Studio funkcija — nav nepieciešama licencēšanas maksa vai izvietošanas piepūle.
• Reāllaika uzraudzība: Skatiet pašreizējo servera aktivitāti tās norises brīdī, izmantojot konfigurējamus atsvaidzināšanas intervālus no 1 sekundes līdz 1 stundai.
• Integrētās darbības: Ar peles labo pogu noklikšķiniet uz procesiem, lai pārtrauktu sesijas, skatītu vaicājuma informāciju vai palaistu SQL Server Profilētāja pēdas — visas no rīka iekšpuses.
• Vairākas perspektīvas: Skatiet servera stāvokli no dažādiem leņķiem, izmantojot piecas specializētas rūtis, katra no kurām koncentrējas uz konkrētiem veiktspējas aspektiem.
• Ātrā problēmu novēršana: Identificējiet most izplatītākās veiktspējas problēmas dažu minūšu laikā, paātrinot vidējo risināšanas laiku.
• Zema barjera ienākšanai: Lai sāktu efektīvi lietot rīku, nav nepieciešamas padziļinātas zināšanas, lai gan tās ir dziļākas SQL Server Ekspertīze palīdz interpretācijā.

2. S iegūšanatarar aktivitātes monitoru

Pirms Activity Monitor efektīvas izmantošanas jums ir jāsaprot priekšnosacījumi, nepieciešamās atļaujas un dažādas rīka palaišanas metodes.

2.1 Priekšnosacījumi un sistēmas prasības

Izmantot SQL Server Aktivitāšu monitors, kas jums nepieciešams SQL Server Management Studio (SSMS), kas instalēta jūsu lokālajā datorā vai pārejas serverī. Aktivitāšu uzraudzības rīks tika ievērojami pārveidots 2007. gadā. SQL Server 2008. gadā, tāpēc šajā rokasgrāmatā sniegtā informācija attiecas uz SQL Server 2008. gada un jaunākās versijas.

Jums ir jābūt tīkla savienojumam ar SQL Server instance, kuru vēlaties uzraudzīt. Cloud-h gadījumāostrediģētām datubāzēm, lai piekļūtu instancei, parasti būs nepieciešams VPN savienojums vai pareizi konfigurēti ugunsmūra noteikumi.

Aktivitāšu monitors darbojas ar visiem izdevumiem SQL Server, ieskaitot Express, Standard un Enterprise. Pats rīks darbojas jūsu klienta datorā SSMS ietvaros, tāpēc servera resursus ietekmē tikai tā izpildītie uzraudzības vaicājumi.

2.2 Nepieciešamās atļaujas

Lai aktivitāšu monitors darbotos pareizi, ir nepieciešamas atbilstošas ​​atļaujas. Bez atbilstošām tiesībām var tikt parādīts tukšs ekrāns vai saņemtas kļūdas par piekļuves liegšanu.

2.2.1 Servera stāvokļa skatīšanas atļauja

The SKATĪT SERVERA STĀVOKLĪ Atļauja ir galvenā prasība Aktivitāšu monitora lietošanai. Šī servera līmeņa atļauja ļauj skatīt visus aktīvos procesus un ar tiem saistītos rādītājus.

Lai piešķirtu šo atļauju, servera administrators var izpildīt:

GRANT VIEW SERVER STATE TO [YourLoginName];

Bez opcijas VIEW SERVER STATE (SKATĪT SERVERA STĀVOKLI) aktivitāšu monitors var tikt atvērts, bet nevienā no tā rūtīm nevar tikt parādīti dati.

2.2.2 Datu bāzes līmeņa atļaujas

Lai skatītu informāciju datu faila ievades/izvades rūtī, ir nepieciešamas papildu atļaujas. Konkrēti, jums ir jābūt vienai no šīm kombinācijām:

• IZVEIDOT DATU BĀZI atļauja vai
• MAINĪT JEBKURU DATUBĀZI atļauja vai
• SKATĪT JEBKURU DEFINĪCIJU atļauja

Šīs atļaujas ir jāapvieno ar SKATĪT SERVERA STĀVOKLĪ lai iegūtu pilnu aktivitāšu monitora funkcionalitāti.

2.2.3 Atļauju problēmu novēršana

Ja aktivitāšu monitors atveras, bet neuzrāda datus, atļaujas ir most bieži sastopams iemesls. Pārbaudiet, vai jūsu pieteikšanās informācijai servera līmenī ir piešķirta atļauja SKATĪT SERVERA STĀVOKLĪ. Savas atļaujas varat pārbaudīt, palaižot:

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

Kolonnā permission_name meklējiet “VIEW SERVER STATE”. Ja tā trūkst, sazinieties ar datubāzes administratoru, lai to piešķirtu.

2.3 Kā atvērt aktivitāšu monitoru SSMS

SQL Server Management Studio piedāvā četras dažādas metodes Activity Monitor palaišanai, sniedzot jums elastību atkarībā no jūsu darbplūsmas preferencēm.

2.3.1 1. metode: no rīkjoslas

Ātrākais veids, kā atvērt Aktivitāšu monitoru, ir izmantot rīkjoslas ikonu:

1. Pievienojieties savam SQL Server piemēram, SQL Server Vadības studija.
2. Standarta rīkjoslā atrodiet aktivitāšu monitora ikonu (tā atgādina joslu diagrammu ar zaļu atskaņošanas pogu).
3. Noklikšķiniet uz ikonas, lai palaistu Aktivitāšu monitoru.

Šī metode ir ātrākā, ja jau strādājat SSMS un jums ir ātri jāpārbauda servera aktivitāte.

2.3.2 2. metode: no objektu pārlūka

Aktivitāšu monitoru var palaist arī tieši no objektu pārlūka:

1. Objektu pārlūkā atrodiet SQL Server instance, kuru vēlaties uzraudzīt.
2. Ar peles labo pogu noklikšķiniet uz instances nosaukuma.
3. Izvēlēties Activity Monitor no konteksta izvēlnes.

Šī metode ir noderīga, izveidojot savienojumu ar vairākiem serveriem, jo ​​tā nodrošina pareizās instances uzraudzību.

2.3.3 3. metode: īsinājumtaustiņu izmantošana

Lietotājiem, kas koncentrējas uz tastatūru, SQL Server Management Studio nodrošina īpašu saīsni:

1. Pārliecinieties, vai SSMS ir aktīvais logs un vai esat izveidojis savienojumu ar instanci.
2. prese Ctrl + cits + A.
3. Objektu pārlūkā tiks atvērts aktivitāšu monitors pašlaik atlasītajai instancei.

Ņemiet vērā, ka aktivitāšu monitors izveidos savienojumu ar jebkuru servera instanci, ko esat atlasījis objektu pārlūkā, tāpēc pirms šīs saīsnes izmantošanas pārliecinieties, vai esat atlasījis pareizo instanci.

2.3.4 4. metode: no opciju izvēlnes (Star(iespējamā konfigurācija)

Ja bieži izmantojat aktivitāšu monitoru, varat konfigurēt SSMS, lai tas tiktu automātiski palaists ikreiz, kad to izmantojat.tart pieteikumu:

1. In SQL Server Vadības studijā dodieties uz darbarīki -> opcijas.
2. Dialoglodziņā Opcijas izvērsiet videUn pēc tam izvēlieties Starcaurule.
3. No Pie starcaurule nolaižamajā sarakstā atlasiet Atvērt objektu pārlūku un aktivitāšu monitoru.
4. Izvēlēties OK.

Nākamajā reizē, kad palaidīsiet SSMS un izveidosiet savienojumu ar serveri, aktivitāšu monitors tiks atvērts automātiski līdzās objektu pārlūkam.

3. Aktivitāšu monitora rūšu izpratne

Aktivitāšu monitors sakārto informāciju piecās izvēršamās rūtīs, katra no kurām sniedz atšķirīgu perspektīvu par servera aktivitātēm. Lai efektīvi novērstu problēmas, ir ļoti svarīgi izprast, kas tiek parādīts katrā rūtī.

3.1 Pārskata rūts

Pārskata rūtī ir redzamas četras reāllaika diagrammas, kas sniedz ātru ieskatu jūsu veselības stāvoklī. SQL Server piemērs. Šie grafiki tiek atjaunināti ar konfigurējamu intervālu un palīdz uzreiz noteikt neparastas tendences.

3.1.1 % procesora laiks

Šajā grafikā ir parādīts laika procents, ko procesors pavada, izpildot pavedienus, kas nav dīkstāvē. SQL Server instance visos procesoros. Vērtība apzīmē SQL Serverprocesora noslodze, nevis visa servera centrālā procesora noslodze.

Ja procesora laiks pastāvīgi ir 100% vai tuvu tam, jūsu serveris ir noslogots ar centrālo procesoru. Tas varētu liecināt par neefektīviem vaicājumiem, trūkstošiem indeksiem vai nepietiekamu aparatūras jaudu. Izmantojiet rūti “Nesen veiktie dārgie vaicājumi”, lai noteiktu, kuri vaicājumi patērē visvairāk laika.ost PROCESORS.

3.1.2 Gaidīšanas uzdevumi

Šis rādītājs parāda to uzdevumu skaitu, kas gaida resursu atbrīvošanu, pirms tos var turpināt. Uzdevumi var gaidīt centrālā procesora, ievades/izvades, atmiņas vai bloķēšanas brīvas vietas.

Pastāvīgi liels gaidošo uzdevumu skaits norāda uz resursu konkurētspēju. Rūtī “Resursu gaidīšanas” ir sniegta sīkāka informācija par to, kāda veida resursi izraisa gaidīšanu.

3.1.3 Datu bāzes I/O (MB/s)

Šajā grafikā ir parādīts datu pārsūtīšanas ātrums starp atmiņu un disku. Tas apvieno gan lasīšanas, gan rakstīšanas ātrumu, mērot megabaitos sekundē.

Datu bāzes I/O palielināšanās var norādīt uz vaicājumiem, kas veic lielu tabulu skenēšanu, pārmērīgu reģistrēšanas aktivitāti vai kontrolpunktu operācijas. Datu faila I/O rūtī I/O aktivitāte tiek sadalīta pa datu bāzēm un failiem.

3.1.4 Pakešu pieprasījumi/sekundē

Šis rādītājs atspoguļo to skaitu, SQL Server Partijas, ko instance saņem sekundē. Partija var būt viens paziņojums vai vairāki kopā iesniegti paziņojumi.

Šī vērtība sniedz priekšstatu par kopējo servera aktivitāti. Pēkšņs partijas pieprasījumu skaita kritums parastajā darba laikā var norādīt uz lietojumprogrammu savienojamības problēmām vai problēmām, ar kurām saskaras lietotāji.

3.1.5 Atsvaidzināšanas intervālu iestatīšana

Varat pielāgot, cik bieži Aktivitāšu monitors atjaunina datus:

1. Ar peles labo pogu noklikšķiniet jebkurā vietā pārskata rūtī.
2. Izvēlēties Atsvaidzināšanas intervāls.
3. Izvēlieties intervālu no iepriekš definētajām vērtībām: 1 sekunde, 5 sekundes, 10 sekundes (pēc noklusējuma), 30 sekundes, 1 minūte vai 1 stunda.

Atsvaidzināšanas intervālu iestatīšana, kas ir mazāka par 10 sekundēm, palielina servera uzraudzības slodzi. Ražošanas sistēmām ar lielu noslodzi apsveriet iespēju izmantot 30 sekunžu vai ilgākus intervālus, lai samazinātu ietekmi.

3.2 Procesu rūts

Procesu rūtī tiek parādīta informācija par pašlaik notiekošajām sesijām jūsu ierīcē. SQL Server piemērs. Šī rūts ir būtiska, lai noteiktu, kas ko dara, un atklātu bloķēšanas problēmas.

3.2.1 Procesa informācijas izpratne

Katra rinda rūtī Procesi attēlo aktīvu sesiju serverī. Rūtī tiek parādītas sesijas no visām datubāzēm un visiem lietotājiem, sniedzot visaptverošu ieskatu servera aktivitātēs.

Parādītajā informācijā ir iekļauts pieteikšanās vārds, lietojumprogrammas nosaukums, hostnosaukums, piekļūstamā datubāze un pašreizējā komanda. Tas palīdz korelēt datubāzes aktivitātes ar konkrētiem lietotājiem vai lietojumprogrammām.

3.2.2 Galveno kolonnu skaidrojums

Izpratne par galvenajām kolonnām palīdz efektīvi interpretēt procesa informāciju:

• Sesijas ID: Unikāls katra savienojuma identifikators. Sistēmas procesi izmanto negatīvus sesijas ID.
• Lietotāja process: Norāda, vai šī ir lietotāja sesija (Jā) vai sistēmas process (Nē).
• Ielogojaties: The SQL Server ar sesiju saistītais pieteikšanās vārds vai Windows konts.
• Datu bāze: Pašreizējā sesijas datubāzes konteksts.
• Uzdevuma stāvoklis: Parāda, ko sesija pašlaik dara (DARBOJAS, APTURĒTA, MIEGA REŽĪMĀ utt.).
• komandu: Izpildāmās komandas veids (SELECT, INSERT, UPDATE utt.).
• Uzklāšana: Lietojumprogrammas nosaukums, kas izveidoja savienojumu.
• Gaidīšanas laiks: Cik ilgi (milisekundēs) sesija ir gaidījusi resursus.
• Gaidīšanas veids: Konkrētais resursa veids, kuru sesija gaida.
• CPU laiks: Kopējais šīs sesijas patērētais centrālā procesora laiks kopš savienojuma izveides.
• Atmiņas izmantošana: Sesijai pašlaik piešķirtā atmiņas apjoms (KB).

3.2.3 Filtrēšanas un kārtošanas procesi

Procesu rūtī ir iekļautas jaudīgas filtrēšanas iespējas, kas palīdz koncentrēties uz atbilstošām sesijām:

1. Noklikšķiniet uz nolaižamās bultiņas jebkuras kolonnas galvenē.
2. Filtrs parāda šai kolonnai pieejamās vērtības, tostarp visi, Blankes, un NonBlanks.
3. Atlasiet noteiktas vērtības, lai filtrētu attēlošanu tikai uz šīm sesijām.

Piemēram, varat filtrēt Uzdevuma stāvoklis lai rādītu tikai AKTĪVĀS sesijas vai filtrētu Datubāze lai skatītu aktivitātes konkrētā datubāzē.

Varat arī kārtot pēc jebkuras kolonnas, noklikšķinot uz tās galvenes. Noklikšķiniet vienreiz, lai kārtotu augošā secībā, divreiz, lai kārtotu dilstošā secībā.

3.2.4 Bloķējošu un bloķētu sesiju identificēšana

Procesu rūts palīdz identificēt bloķēšanas scenārijus, kuros viena sesija neļauj citām turpināt:

• Bloķēja: Parāda sesijas ID, kas bloķē šo sesiju. Ja šajā kolonnā ir vērtība, sesija gaida bloķēšanu, ko veic cita sesija.
• Galvas bloķētājs: Rāda “1”, ja šī sesija bloķē citus, bet pati nav bloķēta. Šis ir bloķēšanas ķēdes pamatcēlonis.

Lai izpētītu bloķēšanas problēmu, vispirms identificējiet galveno bloķētāju (sesiju, kas atzīmēta ar “1” kolonnā “Galvenais bloķētājs”), pēc tam pārbaudiet tā darbību un izlemiet, vai ļaut tam pabeigt darbību vai pārtraukt to.

3.2.5 Procesa darbības (apturēšana, detalizēta informācija, izsekošana)

Aktivitāšu monitors ļauj veikt darbības atsevišķās sesijās:

1. Ar peles labo pogu noklikšķiniet uz jebkuras sesijas rūtī Procesi.
2. Jūs redzēsiet vairākas iespējas:
   • Detaļas: Parāda pēdējo šajā sesijā izpildīto komandu.
   • Nogalināšanas process: Pārtrauc sesiju (lietojiet piesardzīgi).
   • Izsekošanas process SQL Server Profilētājs: Uzsāk SQL Server Profils un automātiski filtrē, lai rādītu tikai šīs sesijas aktivitātes.

Opcija “Detaļas” parāda komandas tekstu, taču ņemiet vērā, ka tas ir pēdējais komanda izpildīta — tā, iespējams, vēl nedarbojas. Izsekošanas opcija ir īpaši noderīga, ja ir jāredz pilna komandu secība, ko izpilda sesija.

3.3 Resursu gaidīšanas rūts

Resursu gaidīšanas rūts apkopo gaidīšanas statistiku, parādot, kāda veida resursu sesijas gaida most bieži. Šī informācija ir ļoti svarīga, lai diagnosticētu veiktspējas problēmas.

3.3.1 Gaidīšanas statistikas izpratne

Kad SQL Server nevar nekavējoties apstiprināt resursa pieprasījumu (piemēram, bloķēšanu, centrālā procesora laiku vai atmiņu), pieprasošais uzdevums nonāk gaidīšanas stāvoklī. Gaidīšanas statistika izseko šos gaidīšanas periodus un palīdz saprast, kur serveris pavada laiku gaidot, nevis strādājot.

Resursu gaidīšanas rūts apkopo datus no sistēmas dinamiskās pārvaldības skatiem, piemēram, sys.dm_os_wait_stats un sys.dm_exec_requests. Katrā atsvaidzināšanas intervālā tā aprēķina starpību starp pašreizējo un iepriekšējo momentuzņēmumu, parādot katra gaidīšanas veida uzkrāšanās ātrumu.

3.3.2 Gaidīšanas kategorijas

Aktivitāšu monitors simtiem atsevišķu gaidīšanas veidu sagrupē plašākās kategorijās, lai vienkāršotu interpretāciju:

• CPU: Uzdevumi, kas gaida, kad kļūs pieejams procesora laiks.
• Bufera aizbīdnis: Gaida īstermiņa sinhronizācijas objektus, kas aizsargā piekļuvi datu lapām atmiņā. Šajā kategorijā ietilpst lapu fiksēšanas gaidīšanas (PAGELATCH_*).
• Lock: Gaidīšanas laiki, ko izraisa sesijas, kurās ir bloķējumi, kas nepieciešami citām sesijām.
• atmiņa: Gaida atmiņas piešķiršanu, kas nepieciešama tādām darbībām kā kārtošana un jaukšana.
• Tīkla ieeja/izeja: Gaida datu nosūtīšanu klientiem vai datu saņemšanu no tiem.
• SQL CLR: Ar Common Language Runtime izpildi saistītie gaidīšanas laiki.

Lai gan šī grupēšana vienkāršo skatu, tā arī aizsedz svarīgas detaļas. Piemēram, “Buffer Latch” var grupēt kopā PAGELATCH_SH, PAGELATCH_UP un PAGELATCH_EX gaidīšanas, kam ir atšķirīga ietekme uz veiktspēju.

3.3.3 Gaidīšanas laika un gaidīšanas uzdevumu interpretācija

Resursu gaidīšanas rūts katrai gaidīšanas kategorijai parāda divus galvenos rādītājus:

• Kopējais gaidīšanas laiks (ms): Kopējais milisekundes, kas uzkrātas pašreizējā atsvaidzināšanas intervālā šai gaidīšanas kategorijai.
• Gaidīšanas uzdevumi: Uzdevumu skaits, kas pašlaik gaida resursus šajā kategorijā.

Īpaši interesanta ir gaidīšanas laika vērtība. Ja atsvaidzināšanas intervāls ir 10 sekunžu un redzat 20 000 ms gaidīšanas laiku kategorijai, tas norāda uz vairākām vienlaicīgām gaidīšanas reizēm (20 000 ms / 10 000 ms = divu vienlaicīgu gaidīšanas reižu vidējais rādītājs intervāla laikā).

3.3.4 Veiktspējas vājo vietu noteikšana

Izmantojiet resursu gaidīšanas rūti, lai noteiktu, kur jūsu serveris tērē most gaidīšanas laiks:

1. Izvērsiet rūti Resursu gaidīšanas.
2. Ievērojiet gaidīšanas kategorijas, kurās uzkrājas vislielākais gaidīšanas laiks.
3. Kārtot pēc Kopējais gaidīšanas laiks lai redzētu, kuri resursi ir most ierobežots.

Augsta bufera fiksācijas gaidīšanas vērtība bieži norāda uz datu lapu konkurenci atmiņā, kas var liecināt par I/O sastrēgumiem vai pagaidu datubāzes konkurenci. Augsta bloķēšanas gaidīšanas vērtība norāda uz bloķēšanas problēmām. Augsta atmiņas gaidīšanas vērtība liecina par nepietiekamu atmiņas apjomu vaicājumu operācijām.

3.4 Datu failu I/O rūts

Datu faila I/O rūtī tiek parādīta katra servera datubāzes faila diska aktivitāte, palīdzot noteikt I/O sastrēgumus un izprast diska izmantošanas modeļus.

3.4.1 I/O metrikas izpratne

Datu faila I/O rūtī tiek parādīti vairāki katra datubāzes faila rādītāji:

• Datu bāze: Datu bāzes nosaukums.
• Faila tips: Vai nu dati (ieskaitot tabulas un indeksus), vai žurnāls (darījumu žurnāls).
• Loģiskais nosaukums: Loģiskais faila nosaukums, kā definēts SQL Server.
• MB/sek. nolasīšana: No šī faila nolasāmo datu ātrums.
• Rakstīts MB/sek.: Datu ierakstīšanas ātrums šajā failā.
• Reakcijas laiks (ms): Vidējais atbildes laiks I/O operācijām šajā failā.

Šie rādītāji tiek atsvaidzināti ar tādu pašu intervālu kā pārskata rūts, sniedzot jums reāllaika pārskatu par diska aktivitātēm.

3.4.2 I/O sastrēgumu identificēšana

Pievērsiet uzmanību šiem modeļiem, kas norāda uz I/O veiktspējas problēmām:

• Augsts reakcijas laiks: Reakcijas laiki pastāvīgi virs 15–20 ms liecina par lēnām disku apakšsistēmām. Reakcijas laiki virs 50 ms norāda uz nopietnām I/O sastrēgumiem.
• Nesabalansēta slodze: Ja vienam datu failam ir ievērojami augstāki I/O ātrumi nekā citiem tajā pašā datubāzē, slodzes sadalīšanai varētu būt noderīgi pievienot papildu failus.
• Pārmērīga Tempdb aktivitāte: Augsts ievades/izvades ātrums tempdb failos bieži norāda uz vaicājumiem, kas rada lielus starprezultātu kopumus vai izmanto neefektīvus izpildes plānus.

3.4.3 Datu bāzes failu analīze

Izmantojiet datu faila ievades/izvades rūti, lai saprastu, kā jūsu datubāzes izmanto diska resursus:

1. Izvērsiet rūti Datu faila ievadizvade.
2. Kārtot pēc MB/s lasīšana or MB/sek. ierakstīts lai identificētu most aktīvie faili.
3. Pievērsiet uzmanību visiem failiem ar pastāvīgi augstu aktivitāti vai ilgu atbildes laiku.
4. Salīdziniet šo informāciju ar rūti Nesenie dārgie vaicājumi, lai noteiktu, kuri vaicājumi rada ievadizvades slodzi.

3.5 Nesen veikto dārgo vaicājumu rūts

Rūts “Nesenie dārgie vaicājumi” bieži vien ir most vērtīga rūts lietojumprogrammu veiktspējas problēmu novēršanai. Tajā tiek parādīti vaicājumi, kas patērē ievērojamus servera resursus, palīdzot noteikt optimizācijas iespējas.

3.5.1 Vaicājumu metrikas izpratne

Aktivitāšu monitors katram dārgajam vaicājumam parāda vairākus rādītājus:

• Izpildes/minūtē: Cik reižu vaicājums tika izpildīts pēdējā minūtē.
• Centrālais procesors (ms/sek.): Šī vaicājuma patērētais centrālā procesora laiks sekundē.
• Fiziskās nolasīšanas/sekundē: Fiziskā diska nolasījumu skaits sekundē šim vaicājumam.
• Loģiskā rakstīšana sekundē: Loģisko ierakstu skaits (kešatmiņas buferizēšanai) sekundē.
• Loģiskā lasīšana sekundē: Loģisko nolasījumu skaits (no bufera kešatmiņas) sekundē.
• Vidējais ilgums (ms): Šī vaicājuma vidējais izpildes laiks.
• Plānu skaits: Šī vaicājuma izpildes plānu skaits kešatmiņā.

Šie rādītāji palīdz ne tikai saprast, kuri vaicājumi ir dārgi, bet arī kāpēc tie ir dārgi un cik bieži tie kursē.

3.5.2 Kārtošanas opcijas

Varat kārtot rūti Nesenie dārgie vaicājumi pēc dažādiem rādītājiem, lai atrastu dažāda veida problēmas:

1. Noklikšķiniet uz jebkuras kolonnas galvenes, lai kārtotu pēc šīs metrikas.
2. Izplatītākās šķirošanas stratēģijas ietver:
   • Kārtot pēc centrālā procesora: Atrodiet vaicājumus, kas patērē most procesora laiks.
   • Kārtot pēc izpildes/minūtē: Identificējiet vaicājumus, kas tiek izpildīti pārāk bieži.
   • Kārtot pēc fiziskās lasīšanas: Atrodiet vaicājumus, kas izraisa most diska I/O.
   • Kārtot pēc vidējā ilguma: Atrodiet ilgstoši darbojošos vaicājumus.

Risinot veiktspējas problēmas, mēģiniet kārtot pēc vairākām kolonnām, lai iegūtu dažādus skatījumus. Vaicājums ar mērenu centrālā procesora noslodzi, bet ārkārtīgi augstu izpildes biežumu minūtē, iespējams, ir jūsu īstā problēma.

3.5.3 Vaicājuma teksta skatīšana

Lai redzētu faktisko SQL priekšrakstu aiz dārga vaicājuma:

1. Ar peles labo pogu noklikšķiniet uz vaicājuma rindas rūtī Nesenie dārgie vaicājumi.
2. Izvēlēties Rediģēt vaicājuma tekstu.
   
3. Atveras jauns vaicājuma logs, kurā redzams pilns SQL priekšraksts.
   

Tas ļauj jums pārbaudīt vaicājuma loģiku un noteikt potenciālās optimizācijas iespējas. Pēc tam varat kopēt vaicājuma tekstu, lai testētu modificētas versijas.

3.5.4 Izpildes plānu analīze

Izpildes plāni parāda, kā SQL Server izpilda vaicājumu, atklājot neefektivitāti, piemēram, trūkstošus indeksus vai nepiemērotus savienojuma veidus:

1. Ar peles labo pogu noklikšķiniet uz vaicājuma rindas rūtī Nesenie dārgie vaicājumi.
2. Izvēlēties Rādīt izpildes plānu.
   
3. SQL Server Management Studio parāda vaicājuma izpildes grafisko attēlojumu.
   

Meklējiet darbības, kas patērē lielu daļu no vaicājuma laika (c)ost, brīdinājumus par trūkstošu statistiku vai indeksiem un negaidītām tabulu skenēšanas darbībām. Tie bieži norāda, uz kurām jomām jākoncentrējas optimizācijas centieniem.

3.5.5 Problemātisku vaicājumu identificēšana

Pievērsiet uzmanību šīm tendencēm rūtī Nesenie dārgie vaicājumi:

• Pārmērīgas nāvessoda izpildes: Vaicājums, kas tiek izpildīts tūkstošiem reižu minūtē, var norādīt uz N+1 vaicājuma problēmu, kur lietojumprogrammas kods izsauc datubāzi cikla ietvaros.
• Augsta fiziskā lasīšanas jauda: Vaicājumi ar augstu fiziskās lasīšanas ātrumu bieži nonāk diskā, kas liecina par trūkstošiem indeksiem vai slikti uzrakstītiem vaicājumiem.
• Augsts CPU jauda ar zemu ilgumu: Daudzi ātri vaicājumi, kas kopumā patērē daudz centrālā procesora jaudas, var ietekmēt servera veiktspēju tikpat lielā mērā kā daži lēni vaicājumi.
• Vairāku plānu skaits: Vaicājumiem ar daudziem izpildes plāniem var rasties parametru pārtveršanas problēmas vai neparametrizēti vaicājumi, kas izraisa plāna kešatmiņas uzpūšanos.

4. Aktivitāšu monitora izmantošana veiktspējas problēmu novēršanai

Aktivitāšu monitors patiesi izceļas, ja to sistemātiski izmantojat, lai diagnosticētu un novērstu veiktspējas problēmas. Šajā sadaļā ir aplūkoti bieži sastopami problēmu novēršanas scenāriji un to, kā tos risināt.

4.1 Pārmērīgas vaicājumu izpildes diagnostika

Viens no viņiemost Bieži sastopama veiktspējas problēma ir vaicājumu izpilde daudz biežāk nekā nepieciešams, bieži vien lietojumprogrammu dizaina problēmu dēļ.

4.1.1 Atkārtotu vaicājumu identificēšana

Lai noteiktu pārāk bieži izpildītos vaicājumus:

1. Atveriet Aktivitāšu monitoru un izvērsiet Nesenie dārgie vaicājumi rūts
2. Kārtot pēc Izpildes/minūtē (izpildes minūtē).
3. Meklējiet vaicājumus augšpusē ar izpildes skaitu, kas šķiet nepamatoti augsts.
4. Ar peles labo pogu noklikšķiniet uz aizdomīgā vaicājuma un atlasiet Rediģēt vaicājuma tekstu lai pārbaudītu SQL paziņojumu.

Piemēram, ja redzat, ka vienkāršs SELECT priekšraksts tiek izpildīts 37 000 reižu minūtē, apšaubiet, vai lietojumprogrammai tiešām ir nepieciešams izsaukt šo vaicājumu tik bieži.ost Vaicājumi, kas tiek izpildīti vairāk nekā dažus tūkstošus reižu minūtē, garantē izmeklēšanu.

4.1.2 Cēloņu analīze

Pārmērīga vaicājumu izpilde parasti rodas šādu problēmu dēļ:

• N+1 vaicājuma problēma: Lietojumprogrammas kods izgūst vienumu sarakstu un pēc tam katram vienumam izpilda atsevišķu vaicājumu, lai izgūtu saistītos datus. Tas izveido N papildu vaicājumus, kur N ir vienumu skaits.
• Trūkstoša kešatmiņa: Lietojumprogramma vaicā datubāzē datus, kas rarizmaiņas, nevis kešatmiņā saglabā tās lietojumprogrammas atmiņā.
• Aptaujas cikli: Kods atkārtoti vaicā datubāzei, pārbaudot stāvokļa izmaiņas, nevis izmantojot izmaiņu paziņojumus vai ziņojumu rindas.
• ORM neefektivitāte: Entity Framework un līdzīgi rīki dažreiz ģenerē neefektīvus vaicājumu modeļus, ja izstrādātāji nesaprot, kā viņu kods tiek tulkots uz SQL.

Lai noteiktu pamatcēloni, izsekojiet vaicājuma cēloni līdz lietojumprogrammas kodam. Ņemiet vērā iesniegums un Ieiet kolonnas rūtī Procesi, kad vaicājums tiek izpildīts. Varat arī ar peles labo pogu noklikšķināt uz procesa un atlasīt Izsekošanas process SQL Server Profils lai redzētu zvanīšanas modeli.

4.1.3. Risinājumi un labākā prakse

Kad esat identificējis pārmērīgu vaicājumu izpildes biežumu, apsveriet šādus risinājumus:

• Pakešu apstrāde: Modificējiet lietojumprogrammas kodu, lai vienā vaicājumā izgūtu vairākus vienumus, izmantojot apvienojumus vai IN klauzulas, nevis atsevišķus vaicājumus izpildot cilpā.
• Rezultātu kešatmiņa: Kešatmiņa, kurai bieži piekļūt, reti mainot datus lietojumprogrammas atmiņā ar atbilstošu derīguma termiņu.
• Dedzīga iekraušana: Konfigurējiet ORM, lai tie izmantotu ātras ielādes stratēģijas, kas ielādē saistītus datus mazākā skaitā, bet efektīvākos vaicājumos.
• Vaicājuma parametrizācija: Nodrošiniet, lai vaicājumi izmantotu parametrus, nevis apvienotu vērtības, kas uzlabo plāna kešatmiņas atkārtotu izmantošanu un samazina kompilācijas izmaksas.

4.2 Bloķēšanas problēmu izpēte

Bloķēšana notiek, ja vienā sesijā ir bloķētas darbības, kas neļauj turpināt citas sesijas. Tas izpaužas kā lēns lietojumprogrammu reakcijas laiks un neapmierināti lietotāji.

4.2.1 Bloķējošo ķēžu identificēšana

Lai atklātu un analizētu bloķēšanu:

1. Atveriet Aktivitāšu monitoru un izvērsiet Procesi rūts
2. Meklējiet sesijas ar vērtībām, kas norādītas sadaļā Bloķēja kolonna — tās gaida citu sesiju bloķējumus.
3. Atrast sesijas ar vērtību “1” Galvas bloķētājs kolonna — tie ir bloķējošo ķēžu pamatcēlonis.
4. Piezīme Sesijas ID galvas bloķētāja.
5. Ar peles labo pogu noklikšķiniet uz galvas bloķētāja sesijas un atlasiet Sīkāka informācija lai redzētu, kādu komandu tas izpilda.

Bloķējošās ķēdes izpratne ir ļoti svarīga. Galvenais bloķētājs ir sesija, kas jums jāizpēta, nevis bloķētās sesijas, kas seko šai ķēdei.

4.2.2 Slēdzeņu veidu izpratne

The Gaidīšanas veids Kolonna Procesu rūtī norāda, kāda veida bloķēšanas bloķēšanas sesijas gaida:

• LCK_M_X: Ekskluzīvas bloķēšanas gaidīšana, ko parasti izraisa UPDATE, DELETE vai INSERT darbības.
• LCK_M_S: Koplietotas bloķēšanas gaidīšana, parasti SELECT paziņojumi, kas gaida, kamēr tiks atbrīvotas ekskluzīvās bloķēšanas.
• LCK_M_U: Atjaunināšanas bloķēšanas gaidīšana — starpposma bloķēšanas veids, ko izmanto atjauninājumu laikā.
• LCK_M_IX: Nolūka ekskluzīvas bloķēšanas gaidīšana, kas norāda uz lapas vai rindas līmeņa bloķēšanas strīdu.

The Gaidīšanas resurss kolonnā ir parādīts, kurš datubāzes objekts tiek bloķēts, tādējādi palīdzot saprast, kura tabula vai indekss ir iesaistīts strīdā.

4.2.3 Bloķēšanas problēmu risināšana

Kad esat identificējis bloķējošo sesiju un tās darbības iemeslu, jums ir vairākas iespējas:

1. Gaidiet pabeigšanu: Ja galveno vaicājumu bloķētājs veic derīgu vaicājumu, kas drīz tiks pabeigts, iespējams, vislabāk ir ļaut tam pabeigties dabiski.
2. Nogalināt sesiju: Ja galveno failu bloķētājs ir iestrēdzis vai izpilda vaicājumu, kas būtu jāatceļ:
   • Ar peles labo pogu noklikšķiniet uz sesijas rūtī Procesi.
   • Izvēlēties Nogalināšanas process.
   • Apstipriniet darbību dialoglodziņā.
3. Vaicājumu optimizēšana: Ja bloķēšana atkārtojas ar tiem pašiem vaicājumiem, optimizējiet tos, lai samazinātu bloķēšanas ilgumu.
4. Pielāgojiet izolācijas līmeņus: Apsveriet iespēju izmantot READ COMMITTED SNAPSHOT ISOLATION, lai samazinātu bloķēšanu lasīšanas slodzes apstākļos.
5. Indeksa regulēšana: Pievienojiet indeksus, lai paātrinātu vaicājumus, samazinot to bloķēšanas laiku.

4.3 Augstas centrālā procesora noslodzes analīze

Ja pārskata rūtī procesora laiks pastāvīgi ir 100% vai tuvu tam, ir jānosaka, kuri vaicājumi ir atbildīgi, un jānosaka, vai tos var optimizēt.

4.3.1 CPU ietilpīgu vaicājumu identificēšana

Lai atrastu vaicājumus, kas patērē pārāk daudz centrālā procesora jaudas:

1. Atveriet Nesenie dārgie vaicājumi rūts
2. Kārtot pēc CPU (ms/sek.) lai parādītu vaicājumus, izmantojot most CPU laiks.
3. Apskatiet sarakstā visbiežāk sastopamos vaicājumus.
4. Ar peles labo pogu noklikšķiniet uz vaicājumiem ar augstu CPU jaudu un atlasiet Rediģēt vaicājuma tekstu lai skatītu SQL priekšrakstu.
5. Izvēlēties Rādīt izpildes plānu lai saprastu, kā vaicājums tiek izpildīts.

Pievērsiet uzmanību ne tikai atsevišķu vaicājumu centrālā procesora noslodzei, bet arī Izpildes/minūtē kolonna. Vaicājums, kas izmanto mērenu centrālā procesora jaudu uz izpildi, bet darbojas tūkstošiem reižu minūtē, var būt lielākais centrālā procesora patērētājs.

4.3.2 Vaicājumu optimizācijas metodes

Izplatītākās metodes centrālā procesora (CPU) patēriņa samazināšanai ir šādas:

• Pievienot trūkstošos indeksus: Indeksa meklēšana izmanto daudz mazāk centrālā procesora (CPU) nekā tabulu skenēšana. Izpildes plānos meklējiet trūkstošos indeksa ieteikumus.
• Pārrakstīt neefektīvus vaicājumus: Aizvietojiet kursorus ar uz kopām balstītām darbībām, likvidējiet nevajadzīgās funkcijas WHERE klauzulās un noņemiet liekos savienojumus.
• Atjaunināt statistiku: Novecojusi statistika izraisa SQL Server lai izvēlētos neefektīvus izpildes plānus. Palaidiet UPDATE STATISTICS attiecīgajās tabulās.
• Samaziniet datu apjomu: Pievienojiet WHERE klauzulas, lai filtrētu datus agrāk, lappušu numerācijai izmantojiet TOP vai OFFSET/FETCH un izvairieties no SELECT *.
• Labot parametru šifrēšanu: Ja parametru pārmeklēšana rada problēmas, izmantojiet OPTION (RECOMPILE), vaicājuma ieteikumus vai plāna ceļvežus.

4.4 Atmiņas problēmu izpēte

Atmiņas trūkums var izraisīt vaicājumu pārsūtīšanu uz disku, ievērojami pazeminot veiktspēju. Aktivitāšu monitors palīdz identificēt atmiņas ietilpīgās darbības.

4.4.1 Atmiņas metrikas izpratne

The Atmiņas izmantošana Procesu rūts kolonnā ir redzama katrai sesijai piešķirtā atmiņa kilobaitos. Liels atmiņas izmantojums vienā sesijā bieži norāda:

• Lielas kārtošanas vai jaucējkoda operācijas, kas neietilpa sākotnēji piešķirtajā atmiņā
• Vaicājumi, kas izgūst milzīgus rezultātu kopumus
• Pārmērīga paralēlisma dēļ tiek radītas daudzas izpildes plāna operatoru kopijas.
• Atmiņas noplūdes CLR saglabātajās procedūrās vai funkcijās

Rūtī Resursu gaidīšanas var tikt rādītas atmiņas gaidīšanas, ja vaicājumi nevar iegūt pietiekami daudz atmiņas piešķīrumu un tiem jāgaida, līdz atmiņa kļūst pieejama.

4.4.2 Atmiņu intensīvi patērējošu vaicājumu identificēšana

Lai atrastu vaicājumus, kas rada atmiņas noslodzi:

1. Iekš Procesi rūts, kārtot pēc Atmiņas izmantošana lai redzētu sesijas, kas patērē most atmiņa.
2. Ar peles labo pogu noklikšķiniet uz sesijām ar lielu atmiņas izmantošanu un atlasiet Sīkāka informācija lai skatītu viņu vaicājumus.
3. Iekš Nesenie dārgie vaicājumi rūtiņā meklējiet vaicājumus ar augstu Loģiskā lasīšana or Loģiskā rakstīšana, jo tie bieži korelē ar atmiņas izmantošanu.
4. Izpētiet kārtošanas un jaucējkodes atbilstības operatoru izpildes plānus, kas izmanto atmiņas piešķiršanu.

Vaicājumi, kuros izpildes plānos tiek rādīti brīdinājumi par “Memory Grant” (Atmiņas piešķiršana) vai noplūdes brīdinājumi, norāda uz atmiņas noslodzes problēmām.

4.5 Lietojumprogrammu veiktspējas problēmu noteikšana

Kad lietotāji ziņo par lēnu lietojumprogrammu reakcijas laiku, aktivitāšu monitors palīdz noteikt, vai datubāze ir sašaurinājums.

4.5.1 Aktivitāšu monitora korelācija ar lietojumprogrammu problēmām

Lai izpētītu lietojumprogrammas lēnumu:

1. Ņemiet vērā precīzu laiku, kad lietotāji ziņo par problēmām, un skartās lietojumprogrammas.
2. Atveriet Aktivitāšu monitoru un pārbaudiet Pārskats rūts resursu pieaugumam tajā laikā.
3. Iekš Procesi rūts, filtrēt pēc iesniegums lai rādītu tikai savienojumus no attiecīgās lietojumprogrammas.
4. Meklējiet augstu Pagaidiet laiku vērtības, kas norāda datubāzes kavējumus.
5. Pārbaudīt Nesenie dārgie vaicājumi rūts vaicājumiem no šīs lietojumprogrammas, kas patērē ievērojamus resursus.

Ja datubāzē netiek novērota neparasta aktivitāte, bet lietotāji saskaras ar lēnu darbību, problēma, visticamāk, ir saistīta ar lietojumprogrammas kodu, tīkla latentumu vai klienta puses veiktspēju.

4.5.2 Neefektīvu lietošanas modeļu identificēšana

Aktivitāšu monitors atklāj vairākus lietojumprogrammu dizaina trūkumus:

• Pļāpīgās lietojumprogrammas: Daudzi mazi vaicājumi, nevis mazāk, efektīvāki vaicājumi. To raksturo liels savienojumu skaits un daudzi vienkārši vaicājumi sadaļā Nesenie dārgie vaicājumi.
• N+1 vaicājumi: Viens vaicājums, kam seko N papildu vaicājumi saistītiem datiem. Tiek rādīts kā vienkāršs vaicājums ar ārkārtīgi augstu izpildes biežumu minūtē.
• Lielas rezultātu kopas: Lietojumprogrammas izgūst daudz vairāk datu nekā nepieciešams. Meklējiet augstu Loģiskā lasīšana apvienojumā ar vienkāršiem SELECT * vaicājumiem.
• Trūkstošie taimauti: Lietojumprogrammas, kas neiestata komandu taimautus, var atstāt savienojumus atvērtus uz nenoteiktu laiku, kas ir redzami kā ilgstošas ​​sesijas rūtī Procesi.

5. Alternatīvas metodes: aktivitāšu monitora datu iegūšana, izmantojot T-SQL

Lai gan aktivitāšu monitors nodrošina ērtu grafisko saskarni, dažreiz jums ir nepieciešams iegūt līdzvērtīgu informāciju programmiski vai izveidot pielāgotus uzraudzības risinājumus.

5.1 Dinamisko pārvaldības skatu (DMV) izmantošana

SQL Server atklāj aktivitāšu informāciju, izmantojot dinamiskus pārvaldības skatus, kurus aktivitāšu monitors veic vaicājumus fonā.

5.1.1 Galvenie DMV aktivitāšu uzraudzībai

Most Svarīgākie DMV aktivitāšu monitora funkcionalitātes replicēšanai ir šādi:

• sys.dm_exec_pieprasījumi: Parāda pašlaik izpildāmos pieprasījumus ar centrālā procesora, ievades/izvades un gaidīšanas informāciju.
• sys.dm_exec_sessions: Satur sesijas līmeņa informāciju, piemēram, pieteikšanās vārdu, host nosaukums un programmas nosaukums.
• sys.dm_os_wait_stats: Nodrošina kumulatīvo gaidīšanas statistiku visai instancei.
• sys.dm_exec_query_stats: Satur apkopotu veiktspējas statistiku kešatmiņā saglabātajiem vaicājumiem.
• sys.dm_io_virtual_file_stats: Atgriež datu un žurnālfailu I/O statistiku.
• sys.dm_exec_sql_text: Izgūst SQL tekstu dotajam sql_handle vai plan_handle.
• sys.dm_exec_query_plan: Atgriež kešatmiņā saglabāta vaicājuma izpildes plānu.

5.1.2 Procesa informācijas vaicājumu paraugi

Lai replicētu procesu rūts funkcionalitāti, varat veikt vaicājumu:

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 Gaidīšanas statistikas vaicājumu paraugi

Lai skatītu gaidīšanas statistiku, kas ir līdzīga rūtij Resursu gaidīšanas:

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 Izmantojot sp_WhoIsActive

sp_WhoIsActive ir jaudīga kopienas izveidota saglabātā procedūra, kas vienā rezultātu kopā sniedz detalizētāku informāciju nekā Activity Monitor.

5.2.1 sp_WhoIsActive instalēšana

Lai instalētu sp_WhoIsActive:

1. Lejupielādējiet jaunāko versiju no http://whoisactive.com.
2. Lejupielādējamais fails ir SQL skripts, kas satur procedūras definīciju.
3. Atveriet skriptu programmā SQL Server Vadības studija.
4. Pievienojieties savam SQL Server piemērs
5. Izpildiet skriptu, lai izveidotu procedūru galvenajā datubāzē.
6. Piešķirt izpildes atļaujas atbilstošajiem lietotājiem.

Tā kā sp_WhoIsActive ir instalēts galvenajā datubāzē, tam var piekļūt no jebkura datubāzes konteksta.

5.2.2 Pamatlietošanas piemēri

Vienkāršākais veids, kā izmantot sp_WhoIsActive, ir:

EXEC sp_WhoIsActive;

Tas atgriež rezultātu kopu, kurā redzamas visas aktīvās sesijas ar to vaicājumiem, gaidīšanas veidiem, bloķēšanas informāciju un resursu izmantošanu.

10 sekunžu paraugs, kas parāda aktivitāti šajā periodā:

EXEC sp_WhoIsActive @delta_interval = 10;

Tas aprēķina tādu rādītāju kā centrālā procesora jaudas un nolasījumu delta vērtības, parādot, kas notika šo 10 sekunžu laikā.

5.2.3 Paplašinātie parametri

sp_WhoIsActive atbalsta daudzus pielāgošanas parametrus:

• @filtrs: Filtrējiet rezultātus pēc konkrētām sesijām, datubāzēm vai pieteikšanās datiem.
• @filtra_tips: Norādiet, uz ko filtrs attiecas (sesiju, datubāzi, pieteikšanos utt.).
• @get_plans: Rezultātos iekļaut izpildes plānus (iestatīt vērtību 1).
• @get_locks: Rādīt detalizētu informāciju par bloķēšanu (iestatīt vērtību 1).
• @get_transaction_info: Rādīt darījuma informāciju (iestatīt vērtību 1).
• @kārtošanas_kārtība: Sakārtot rezultātus pēc dažādiem rādītājiem (CPU, nolasīšanas reižu skaits, ilgums utt.).
• @galamērķa_table: Ievietojiet rezultātus tabulā vēsturiskai izsekošanai.

Piemērs, kurā redzami plāni, sakārtoti pēc centrālā procesora:

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

5.3 Sistēmā saglabāto procedūru izmantošana

SQL Server ietver tradicionālās saglabātās procedūras aktivitāšu uzraudzībai, lai gan tās sniedz mazāk informācijas nekā DMV vai aktivitāšu monitors.

5.3.1 sp_who un sp_who2

Procedūra sp_who parāda sesijas pamatinformāciju:

EXEC sp_who;

Procedūra sp_who2 sniedz nedaudz sīkāku informāciju:

EXEC sp_who2;

Abas procedūras parāda sesijas ID, pieteikšanās vārdus, centrālā procesora laiku un bloķēšanas informāciju. Tomēr tām trūkst bagātīgās informācijas, kas pieejama, izmantojot DMV vai aktivitāšu monitoru. Tās ir most noderīgi ātrām pārbaudēm, kad ātri nepieciešama minimāla informācija.

5.3.2 Citas noderīgas sistēmas procedūras

Papildu sistēmas procedūras uzraudzībai ietver:

• sp_bloķēšana: Parāda bloķēšanas informāciju (novecojis; tā vietā izmantojiet sys.dm_tran_locks).
• sp_monitors: Parāda statistiku par SQL Server darbību.
• sp_help: Parāda objektu definīcijas un metadatus.
• DBCC SQLPERF: Parāda darījumu žurnāla vietas izmantošanu un gaidīšanas statistiku.

5.4 Pielāgotu uzraudzības skriptu izveide

Vidēm, kurām nepieciešama īpaša uzraudzība, kas pārsniedz Activity Monitor piedāvāto, varat izveidot pielāgotus risinājumus, izmantojot DMV.

5.4.1 Pilnīgs aktivitāšu monitora ekvivalents skripts

Šeit ir visaptverošs skripts, kas atkārto most Aktivitāšu monitora funkcionalitāte:

-- 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 Uzraudzības automatizācija ar SQL aģenta uzdevumiem

Varat ieplānot pielāgotus uzraudzības skriptus, izmantojot SQL Server Aģents:

1. Izveidojiet tabulu, lai saglabātu uzraudzības rezultātus.
2. Modificējiet savu uzraudzības skriptu, lai ievietotu rezultātus šajā tabulā.
3. In SQL Server Vadības studija, izvērst SQL Server Aģents objektu pārlūkā.
4. Right-click Darbs un izvēlieties Jauns darbs.
5. Konfigurējiet uzdevumu, lai uzraudzības skripts tiktu palaists regulāri.
6. Iestatiet brīdinājumus vai pārskatus, pamatojoties uz apkopotajiem datiem.

Šī pieeja nodrošina vēsturisku izsekošanu un tendenču analīzi, ko Activity Monitor nenodrošina.

6. Aktivitāšu monitora ierobežojumi un apsvērumi

Lai gan Aktivitāšu monitors ir vērtīgs, izpratne par tā ierobežojumiem palīdz to pareizi izmantot un nepieciešamības gadījumā papildināt ar citiem rīkiem.

6.1 Aktivitāšu monitora virsizdevumu izpratne

Aktivitāšu monitors nav bezmaksas — tas patērē servera resursus, lai apkopotu un parādītu informāciju. Izpratne par šīm papildu izmaksām palīdzēs jums to izmantot atbildīgi.

6.1.1 Ietekme uz servera resursiem

Aktivitāšu monitors (Activity Monitor) katru reizi, kad tas tiek atsvaidzināts, veic vaicājumus pret sistēmas DMV. Šie vaicājumi patērē procesora jaudu, ģenerē loģiskus lasījumus un var īslaicīgi turēt bloķētus sistēmas tabulas. Noslogotos serveros šī papildu slodze var ietekmēt veiktspēju.

Rūtis “Procesi” un “Nesen veiktie dārgie vaicājumi” ir īpaši dārgas, jo tām ir jāpārbauda potenciāli lieli DMV un kešatmiņas tabulas. Serveros ar tūkstošiem kešatmiņā saglabātu vaicājumu plānu nesen veikto dārgo vaicājumu atsvaidzināšana var ilgt vairākas sekundes.

Microsoft dokumentācija brīdina, ka atsvaidzināšanas intervāli, kas ir mazāki par 10 sekundēm, var ievērojami ietekmēt servera veiktspēju, īpaši jau ielādētās sistēmās.

6.1.2 Atsvaidzināšanas intervāla labākā prakse

Izvēlieties savai situācijai atbilstošus atsvaidzināšanas intervālus:

• 1–5 sekundes: Tikai kritisku problēmu tūlītējai novēršanai serveros ar mazu noslodzi. Neatstājiet aktivitāšu monitoru ieslēgtu šādos intervālos.
• 10 sekundes (pēc noklusējuma): Saprātīgs most problēmu novēršanas scenāriji un vispārēja uzraudzība.
• 30–60 sekundes: Labāka izvēle ražošanas serveriem ar lielu slodzi vai ilgstošai uzraudzībai.
• Tikai manuāla atsvaidzināšana: Situācijām, kad vēlaties laiku pa laikam pārbaudīt pašreizējo stāvokli, neizmantojot nepārtrauktu aptauju.

Vienmēr aizveriet Aktivitāšu monitoru, kad esat pabeidzis izmeklēšanu. Neatstājiet to nepārtraukti darbojamies, it īpaši, ja tas darbojas vairākos gadījumos no dažādiem lietotājiem.

6.2 Gaidīšanas veidu grupēšanas problēmas

Aktivitāšu monitora pieeja gaidīšanas kategorizēšanai, lai gan vienkāršo skatu, var aizsegt svarīgas diagnozes.ostic informācija.

6.2.1 Kā aktivitāšu monitora grupas gaida

SQL Server izseko simtiem dažādu gaidīšanas veidu, katrs no kuriem norāda uz konkrētu resursu vai stāvokli. Aktivitāšu monitors tos sagrupē plašās kategorijās, piemēram, “Bufera aizture”, “Bloķēšana” un “Atmiņa”.

Piemēram, kategorijā “Bufera aizture” ietilpst PAGELATCH_SH, PAGELATCH_UP, PAGELATCH_EX un vairāki citi specifiski gaidīšanas veidi. Lai gan tie visi ir saistīti ar piekļuvi lapai, tiem ir atšķirīgi cēloņi un risinājumi.

Microsoft nedokumentē precīzi, kuri gaidīšanas veidi atbilst kurām kategorijām, tāpēc ir grūti saprast, ko jūs patiesībā redzat.

6.2.2 Trūkstošie gaidīšanas veidi

Aktivitāšu monitors neuzrāda visus gaidīšanas veidus. Most Jāatzīmē, ka tajā bieži netiek norādītas CXPACKET gaidīšanas, kas norāda uz paralēlu vaicājumu izpildi. CXPACKET gaidīšanas ir izplatītas un parasti nerada problēmas, taču, zinot, ka tās ir klātesošas, var izprast darba slodzes raksturlielumus.

Ja Activity Monitor kā galveno gaidīšanas laiku rāda “Buffer Latch”, bet citi rīki dominē CXPACKET, neatbilstība rodas Activity Monitor filtrēšanas un grupēšanas loģikas dēļ.

6.2.3 Kāpēc konkrēti gaidīšanas veidi ir svarīgi

Problēmu novēršanai ir svarīgi zināt konkrēto gaidīšanas veidu:

• PAGELATCH_EX: Bieži norāda uz tempdb konfliktu sadales lapās. Risinājums ietver vairāk tempdb datu failu pievienošanu.
• PAGELATCH_SH: Varētu norādīt uz karstām lapām lietotāju tabulās. Risinājums ietver sadalīšanu vai indeksu reorganizāciju.
• PAGELATCH_UP: Bieži sastopama atjauninājumu laikā. Var liecināt par normālu darbību, nevis problēmu.

Aktivitāšu monitors visus šos elementus grupē sadaļā “Bufera aizture”, kas apgrūtina diagnostiku. Tādi rīki kā sp_WhoIsActive un DMV vaicājumi rāda konkrētus gaidīšanas veidus.

6.3 Datu precizitāte un savlaicīgums

Aktivitāšu monitors nodrošina gandrīz reāllaika skatu, taču galvenais vārds ir “gandrīz”. Izpratne par tā datu vākšanas metodi palīdz pareizi interpretēt rezultātus.

6.3.1 Momentuzņēmums salīdzinājumā ar nepārtrauktu uzraudzību

Aktivitāšu monitors rāda laika momentuzņēmumus, kas uzņemti katrā atsvaidzināšanas intervālā. Notikumi, kas notiek starp momentuzņēmumiem, netiek tverti. Ja vaicājums darbojas 2 sekundes un jūs atsvaidzināt ik pēc 10 sekundēm, jūs to varat redzēt vienreiz vai nemaz atkarībā no laika.

Tas nozīmē, ka Aktivitāšu monitors izceļas ar pastāvīgu problēmu atrašanu (ilgstošas ​​minūtes bloķēšana, pastāvīgi augsta centrālā procesora slodze), bet var nepamanīt īslaicīgas problēmas (īslaicīgas strupceļa problēmas, neregulāri vaicājumu pieaugumi).

6.3.2 Apkopošana un izlase

Rūtī “Nesen veiktie dārgie vaicājumi” tiek rādīti dati, kas apkopoti kopš vaicājumu plānu ievadīšanas kešatmiņā. Divi identiski vaicājumi ar atšķirīgām parametru vērtībām tiek parādīti kā viena rinda, ja tiem ir kopīgs plāns. Šī apkopošana var maskēt problēmas ar noteiktām parametru kombinācijām (parametru pārmeklēšanas problēmas).

Resursu gaidīšanas rūts aprēķina ātrumus, salīdzinot momentuzņēmumus. Ja gaidīšanas statistika tiek atiestatīta starp momentuzņēmumiem (rare, bet iespējams), aprēķinātās likmes var būt nepareizas.

6.4 Kad NAV jāizmanto aktivitātes monitors

Aktivitāšu monitors nav piemērots visiem uzraudzības scenārijiem. Atpazīstiet, kad alternatīvi rīki ir labāka izvēle.

6.4.1 Vēsturiskās analīzes prasības

Aktivitāšu monitors rāda tikai pašreizējās vai nesenās aktivitātes. Tas neuzglabā vēsturiskos datus. Ja jums ir jāanalizē tendences vairāku dienu vai nedēļu laikā, jāsalīdzina pašreizējā veiktspēja ar sākotnējām vērtībām vai jāģenerē pārskati par veiktspējas modeļiem, Aktivitāšu monitors nav pietiekams.

Vēsturiskai analīzei izmantojiet SQL Serveriebūvētais veiktspējas informācijas panelis, paplašinātie notikumi ar failu tarsaņem vai trešo pušu uzraudzības risinājumus.

6.4.2 Detalizētas gaidīšanas statistikas vajadzības

Ja nepieciešama precīza informācija par gaidīšanas veidu papildu regulēšanai, aktivitāšu monitora grupēšana un filtrēšana to padara nepietiekamu. Tā vietā izmantojiet tieši DMV vaicājumus vai sp_WhoIsActive.

Lai veiktu visaptverošu gaidīšanas statistikas analīzi, veiciet vaicājumu sys.dm_os_wait_stats tieši un manuāli filtrējiet nekaitīgas gaidīšanas.

6.4.3 Ražošanas servera apsvērumi

Ražošanas serveros ar lielu noslodzi Activity Monitor pieskaitāmās slodzes var radīt problēmas. Vairākiem datubāzes administratoriem nevajadzētu vienlaikus palaist Activity Monitor vienā serverī.

Ražošanas uzraudzībai apsveriet vieglas alternatīvas, piemēram, ieplānotus DMV momentuzņēmumus, kas tiek glabāti uzraudzības datubāzē, vai izmantojiet tikai lasīšanas maršrutēšanu, lai uzraudzītu sekundārās kopijas Always On konfigurācijās.

7. Aktivitāšu monitora lietošanas paraugprakse

Ievērojot labāko praksi, jūs varat gūt maksimālu labumu no Activity Monitor, vienlaikus samazinot negatīvo ietekmi uz saviem serveriem.

7.1 Kad lietot aktivitātes monitoru

Aktivitāšu monitors izceļas noteiktos scenārijos. Izmantojiet to, kad tā stiprās puses atbilst jūsu vajadzībām.

7.1.1 Reāllaika veiktspējas problēmas

Aktivitāšu monitors ir ideāli piemērots, ja lietotājiem pašlaik rodas problēmas un jums ir nekavējoties jādiagnosticē problēma. Reāllaika skats palīdz redzēt, kas notiek tieši tagad.

Kad saņemat ziņojumu, ka “lietojumprogramma darbojas lēni”, vienam no pirmajiem soļiem vajadzētu būt aktivitāšu monitora atvēršanai. Varat ātri noteikt, vai datubāze ir aizņemta, bloķēta vai dīkstāvē.

7.1.2 Lietojumprogrammas palēninājuma izmeklēšana

Kad konkrēta lietojumprogramma pārstāj reaģēt, aktivitāšu monitors palīdz noteikt, vai iemesls ir datubāzes problēmas. Filtrējiet procesu rūti pēc lietojumprogrammas nosaukuma, lai skatītu tikai šīs lietojumprogrammas datubāzes aktivitāti.

Ja lietojumprogrammā netiek rādīta nekāda datubāzes aktivitāte, kamēr lietotāji ziņo par problēmām, problēma meklējama citur stekā. Ja redzat plašu bloķēšanu vai dārgus vaicājumus, esat atradis vainīgo.

7.1.3 Ātrās veselības pārbaudes

Aktivitāšu monitors nodrošina lielisku informācijas paneli ātrām veselības pārbaudēm ikdienas administrēšanas laikā. Atveriet to, apskatiet pārskata grafikus un pārliecinieties, vai nekas neizskatās neparasts.

Šī paviršā pārbaude aizņem dažas sekundes un var atklāt problēmas, pirms tās kļūst kritiskas. Padariet to par daļu no savas ikdienas rutīnas.

7.2 Optimālie konfigurācijas iestatījumi

Aktivitāšu monitora atbilstoša konfigurēšana uzlabo gan tā lietderību, gan resursu patēriņu.

7.2.1 Ieteicamie atsvaidzināšanas intervāli

Pielāgojiet atsvaidzināšanas intervālu savam mērķim:

• Aktīva problēmu novēršana: 10 sekundes nodrošina labu reaģētspēju ar pieņemamām papildu izmaksām.
• Paplašināta uzraudzība: 30–60 sekundes samazina servera ietekmi ilgākos novērošanas periodos.
• Kritiskas problēmas diagnoze: 5 sekundes nodrošina augstu detalizācijas pakāpi, kad katra sekunde ir svarīga, bet izmantojiet īslaicīgi.
• Regulāras veselības pārbaudes: Manuāla atsvaidzināšana (1 stundas intervāls), ja aktīvi neskatāties.

Kad esat pabeidzis, atcerieties aizvērt Aktivitāšu monitoru. Iestatot tam ilgu intervālu un aizmirstot par to, tiek tērēti servera resursi.

7.2.2 Filtrēšanas stratēģijas

Izmantojiet filtrus, lai koncentrētos uz atbilstošu informāciju un samazinātu kognitīvo slodzi:

• Filtrēt procesus pēc Datubāze lai skatītu tikai aktivitātes konkrētās datubāzēs.
• Atlasīt pēc Ieiet lai izsekotu konkrēta lietotāja aktivitātes.
• Atlasīt pēc Uzdevuma stāvoklis = RUNNING, lai paslēptu dīkstāves sesijas.
• Atlasīt pēc iesniegums lai izolētu datplūsmu no konkrētām programmām.
• Rādīt tikai NonBlanks Bloķēja lai redzētu tikai bloķējošas situācijas.

7.2.3 Kolonnu atlase un kārtošana

Izstrādāt sistemātisku pieeju aktivitāšu monitora datu pārskatīšanai:

1. Start ar pārskatu: Pārbaudiet grafikus, vai tajos nav acīmredzamu svārstību vai anomāliju.
2. Pārbaudiet procesus bloķēšanai: Kārtojiet pēc sesijas ID un pēc tam meklējiet vērtības sadaļā “Bloķējis”.
3. Resursu gaidīšanas pārskatīšana: Kārtot pēc kopējā gaidīšanas laika, lai noteiktu resursu sastrēgumus.
4. Analizēt dārgus vaicājumus: Kārtojiet pēc dažādiem rādītājiem (CPU, izpildes, nolasīšanas), lai atrastu dažādus problēmu veidus.
5. Pārbaudiet, izmantojot I/O rūti: Apstipriniet, vai ievades/izvades intensīvie vaicājumi korelē ar augstu diska aktivitāti.

7.3 Integrācija ar citiem rīkiem

Aktivitāšu monitors vislabāk darbojas kā daļa no plašāka rīku komplekta, nevis kā atsevišķs risinājums.

7.3.1 Lietošana ar SQL Server Profils

Aktivitāšu monitors un SQL Server Profileri viens otru labi papildina. Kad aktivitāšu monitorā identificējat problemātisku sesiju, ar peles labo pogu noklikšķiniet uz tās un atlasiet Izsekošanas process SQL Server Profils.

Tas palaiž Profiler ar filtriem, kas jau ir konfigurēti, lai uztvertu tikai šīs sesijas aktivitātes. Jūs redzat visu izpildīto paziņojumu secību, laika informāciju un kļūdu ziņojumus — informāciju, ko aktivitāšu monitors nesniedz.

Lai uzzinātu vairāk par SQL Server Profilētāja iespējas un uzlabotas izsekošanas metodes skatiet mūsu visaptverošs SQL Server Profilētāja ceļvedis.

7.3.2 Papildināšana ar paplašinātiem pasākumiem

Paplašinātie notikumi piedāvā detalizētu uzraudzību ar zemu resursu patēriņu, kas uztver informāciju, ko aktivitāšu monitors nepamana. Izveidojiet paplašināto notikumu sesijas, lai izsekotu konkrētus notikumus, piemēram, strupceļus, ilgstošus vaicājumus vai pārmērīgu atkārtotu kompilāciju.

Izmantojiet Activity Monitor tūlītējai izmeklēšanai un Extended Events pastāvīgai uzraudzībai un vēsturiskai analīzei. Šie divi rīki atbilst dažādām vajadzībām.

Lai uzzinātu vairāk par SQL Server Paplašinātas notikumu iespējas un uzlabotas uzraudzības metodes skatiet mūsu visaptverošs SQL Server Paplašināts pasākumu ceļvedis.

7.3.3 Trešo pušu uzraudzības risinājumi

Komerciāli rīki, piemēram, SolarWinds Database Performance Analyzer, Redgate SQL Monitor un Quest Spotlight, nodrošina funkcijas, kuru trūkst Activity Monitor: brīdināšana, vēsturisko tendenču veidošana, noslodzes plānošana un automatizēta diagnostika.ostics.

Šie rīki ir vērtīgi papildinājumi Activity Monitor, nevis tā aizstājēji. Activity Monitor joprojām ir noderīgs ātrām pārbaudēm un izmeklēšanai pat tad, ja ir pieejami sarežģīti uzraudzības rīki.

7.4 izplatītas kļūdas, no kurām jāizvairās

Izpratne par bieži pieļautajām Activity Monitor kļūdām palīdz to izmantot efektīvāk.

7.4.1 Aktivitāšu monitora nepārtrauktas darbības atstāšana

Most Bieži pieļauta kļūda ir atvērt Aktivitāšu monitoru un atstāt to darbojamies bezgalīgi. Tas izšķiež servera resursus un sniedz mazu vērtību, jo jūs aktīvi neuzraugāt notiekošo.

Aizveriet aktivitāšu monitoru, kad to aktīvi nelietojat. Ja nepieciešama nepārtraukta uzraudzība, tā vietā ieviesiet atbilstošu uzraudzības risinājumu ar plānotu datu vākšanu.

7.4.2 Pārāk liela paļaušanās tikai uz aktivitātes monitoru

Aktivitāšu monitors sniedz vienu perspektīvu par servera veselību. Nepaļaujieties tikai uz to. Papildiniet to ar Windows veiktspējas monitoru operētājsistēmas līmeņa metrikai, paplašinātiem notikumiem detalizētai izsekošanai un izpildes plāna analīzi vaicājumu regulēšanai.

Aktivitāšu monitors palīdz identificēt problēmas, taču to risināšanai bieži vien ir nepieciešami papildu rīki un padziļināta analīze.

Uzziniet vairāk par SQL Server veiktspējas monitors mūsu Pilnīga rokasgrāmata.

7.4.3 Vēsturisko tendenču ignorēšana

Aktivitāšu monitors rāda pašreizējo stāvokli, taču veiktspējas problēmām bieži vien ir redzamas tendences tikai laika gaitā. Ieviesiet vēsturisko datu vākšanu, lai varētu salīdzināt pašreizējos rādītājus ar sākotnējiem rādītājiem un noteikt tendences.

Bez vēsturiskā konteksta jūs, iespējams, neapzināties, ka šodienas “normālā” centrālā procesora noslodze ir par 30 % augstāka nekā pagājušā mēneša sākotnējā vērtība, kas norāda uz pakāpenisku degradāciju.

8. Aktivitāšu monitora problēmu novēršana

Arī pašam Aktivitāšu monitoram dažreiz rodas problēmas. Zinot, kā novērst šīs problēmas, var izvairīties no vilšanās.

8.1 Aktivitāšu monitors neatveras vai nerāda datus

Ja Aktivitāšu monitors atveras, bet rāda tukšas rūtis vai neatveras vispār, tam var būt vairāki iemesli.

8.1.1 Atļauju problēmas

Most Biežākais aktivitāšu monitora problēmu cēlonis ir nepietiekamas atļaujas. Lai pārbaudītu un novērstu:

1. Pārbaudiet servera līmeņa atļaujas:

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

2. Ja netiek atgriezta neviena rinda, jums nav atļaujas SKATĪT SERVERA STĀVOKLĪ.
3. Lūdziet servera administratoram to piešķirt:

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

4. Pēc atļauju piešķiršanas aizveriet un atveriet Aktivitāšu monitoru.

8.1.2 Versiju saderības problēmas

Izmantojot veco versiju SQL Server Management Studio, lai izveidotu savienojumu ar jaunāku SQL Server versija var izraisīt aktivitāšu monitora kļūmes. Rīks, iespējams, neatpazīst jaunus gaidīšanas veidus vai sistēmas skata kolonnas.

Vienmēr izmantojiet SSMS versiju, kas atbilst jūsu versijai vai ir jaunāka par to. SQL Server versiju. Microsoft nodrošina jaunāko SSMS kā bezmaksas lejupielādi atsevišķi no SQL Server pati.

8.1.3 Ugunsmūra un tīkla problēmas

Aktivitāšu monitoram ir nepieciešams savienojums ar SQL Server instance standarta portos (pēc noklusējuma 1433). Ja varat izveidot savienojumu, izmantojot Objektu pārlūku, bet Aktivitāšu monitors neizdodas, iespējams, ugunsmūra noteikumi bloķē konkrētus savienojumus.

Pārliecinieties, vai jūsu klients var sasniegt SQL Server ierīce visās nepieciešamajās pieslēgvietās. Pārbaudiet gan Windows ugunsmūri, gan visus tīkla ugunsmūrus starp klientu un serveri.

8.2 Aktivitāšu monitors ir pastāvīgi apturēts

Bieži sastopama problēma, īpaši SQL Server 2019. gadā Aktivitāšu monitors tiek atvērts apturētā stāvoklī un atsakās atsākt darbību.

8.2.1 Pauzes stāvokļa izpratne

Kad aktivitāšu monitors ir apturēts, visās rūtīs tiek rādīts statuss “Pauzēts” ar atsākšanas pogu, kas var nedarboties. Tas neļauj redzēt nekādu servera aktivitāti.

Pauzes stāvoklis parasti rodas atļauju problēmu, attālā savienojuma ierobežojumu vai SSMS versijas kļūdu dēļ, nevis apzinātas pauzes darbības dēļ.

8.2.2 Biežākie cēloņi

Aktivitāšu monitors var pāriet pastāvīgi apturētā stāvoklī šādu iemeslu dēļ:

• Trūkst atļaujas SKATĪT SERVERA STĀVOKLĪ jaunākajās rūtīs, kas nesen pievienotas. SQL Server versijas
• Attālie savienojumi ir atspējoti ierīcē SQL Server piemērs
• Autentifikācijas kļūmes konkrētiem sistēmas vaicājumiem
• Kļūdas noteiktās SSMS versijās, īpaši no 18.0 līdz 18.3
• Savienojamības problēmas starp klientu un serveri

8.2.3 Risināšanas soļi

Lai novērstu Aktivitāšu monitora apturētā stāvokļa problēmas:

1. Atjaunināt SSMS: Lejupielādējiet un instalējiet jaunāko SQL Server Management Studio versija no Microsoft vietnes. Vēlākajās versijās tika izlabotas daudzas apturētā stāvokļa kļūdas.
2. Pārbaudiet atļaujas: Pārliecinieties, vai jums ir atļaujas SKATĪT SERVERA STĀVOKLĪ un SKATĪT JEBKURU DEFINĪCIJU.
3. Pārbaudiet attālos savienojumus: Pārbaudiet, vai SQL Server instance atļauj attālinātus savienojumus:

   EXEC sp_configure 'remote access';
   

   Ja vērtība ir 0, lūdziet administratoram to iespējot.

4. Restart SSMS: Dažreiz vienkārši aizverot visus logus un rezervestarTing SQL Server Management Studio atrisina problēmu.
5. Savienojuma izveide, izmantojot Windows autentifikāciju: Ja izmantojat SQL autentifikāciju, izmēģiniet Windows autentifikāciju, jo tā dažreiz apiet ar autentifikāciju saistītās pauzes problēmas.

8.3 Veiktspējas problēmas, izmantojot aktivitāšu monitoru

Ja aktivitāšu monitors pats par sevi kļūst lēns vai izraisa servera veiktspējas pasliktināšanos, ir nepieciešama pielāgošana.

8.3.1 Uzraudzības izmaksu samazināšana

Lai samazinātu Aktivitāšu monitora ietekmi:

1. Palieliniet atsvaidzināšanas intervālu līdz 30 sekundēm vai 1 minūtei.
2. Aizveriet rūtis, kuras aktīvi neizmantojat, noklikšķinot uz sakļaušanas pogas.
3. Kad rūtis ir sakļautas, Aktivitāšu monitors neveic vaicājumus par tām.
4. Izvairieties no vairāku aktivitāšu monitora instanču vienlaicīgas palaišanas.
5. Pilnībā aizveriet Aktivitāšu monitoru, kad aktīvi neizmeklējat problēmas.

8.3.2 Alternatīvas vieglas uzraudzības metodes

Ja Aktivitāšu monitors jūsu videi ir pārāk resursu ietilpīgs, apsveriet alternatīvas:

• Vaicājiet DMV tieši: Rakstiet specifiskus T-SQL vaicājumus, kas izgūst tikai nepieciešamo informāciju.
• Izmantojiet sp_WhoIsActive: Šī saglabātā procedūra ir ļoti optimizēta un parasti tai ir zemākas izmaksas nekā aktivitāšu monitoram.
• Ieviest paraugu ņemšanu: Ieplānojiet SQL aģenta darbus, kas regulāri uztver DMV datu momentuzņēmumus, saglabājot rezultātus tabulās vēlākai analīzei.
• Sekundāro repliku uzraudzība: In Vienmēr ieslēgtas pieejamības grupas, palaidiet aktivitāšu monitoru pret nolasāmu sekundāro, nevis primāro.

8.4 Neprecīza vai trūkstoša informācija

Dažreiz Aktivitāšu monitors parāda informāciju, kas šķiet nepareiza vai nepilnīga.

8.4.1 Datu pārbaude ar DMV

Ja aktivitāšu monitora rezultāti šķiet aizdomīgi, pārbaudiet tos, tieši vaicājot pamatā esošos DMV. Piemēram, ja rūtī Procesi netiek rādīta bloķēšana, bet lietotāji par to ziņo, vaicājiet:

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

Ja šajā vaicājumā tiek parādīta bloķēšana, ko Aktivitāšu monitors nav palaidis garām, esat apstiprinājis displeja problēmu.

8.4.2 Datu atsvaidzināšanas laika izpratne

Atcerieties, ka aktivitāšu monitors rāda momentuzņēmumus. Vaicājums, kas tika izpildīts starp atsvaidzināšanas intervāliem, netiks parādīts sadaļā Nesenie dārgie vaicājumi, ja vien tā izpildes plāns nepaliek kešatmiņā.

Līdzīgi gaidīšanas statistika resursu gaidīšanas rūtī atspoguļo uzkrāšanos kopš pēdējā momentuzņēmuma. Strauji mainīgas darba slodzes var parādīt atšķirīgus modeļus katrā atsvaidzināšanā.

9. Uzlabotas aktivitātes monitora metodes

Pieredzējuši datubāzu administratori izmanto aktivitāšu monitoru sarežģītos veidos, lai iegūtu maksimālu diagnostikas rezultātu.ostic vērtība.

9.1 Vairāku rūšu apvienošana pamatcēloņu analīzei

Aktivitāšu monitora patiesā jauda izpaužas, kad korelē informāciju vairākās rūtīs, lai izprastu sarežģītas veiktspējas problēmas.

9.1.1 Gaidīšanas laika korelācija ar procesiem

Ja resursu gaidīšanas rūtī kādā kategorijā tiek rādīts ilgs gaidīšanas laiks, izmantojiet procesu rūti, lai noteiktu, kurās sesijās rodas šī gaidīšana:

1. Ņemiet vērā gaidīšanas kategoriju ar lielu kopējo gaidīšanas laiku (piemēram, “Bloķēt”).
2. Pārslēdzieties uz rūti Procesi.
3. Kārtot pēc Gaidīšanas veids grupēt sesijas pēc to pašreizējās gaidīšanas laika.
4. Meklējiet sesijas, kurās problemātiskajā kategorijā ir redzami gaidīšanas veidi.
5. Šajās sesijās pārbaudiet Gaidīšanas resurss kolonnu, lai redzētu, kuri datubāzes objekti ir iesaistīti.
6. Ar peles labo pogu noklikšķiniet uz un izvēlieties Sīkāka informācija lai skatītu vaicājuma tekstu.

Šī korelācija palīdz pāriet no “mums ir bloķēšanas gaidīšanas” uz “šis konkrētais vaicājums gaida bloķēšanu šajā tabulā”.

9.1.2 Dārgu vaicājumu saistīšana ar I/O problēmām

Kad datu faila ievades/izvades rūtī tiek parādīta augsta diska aktivitāte noteiktā datubāzē:

1. Ņemiet vērā, kuriem datubāzes failiem ir augsts lasīšanas vai rakstīšanas ātrums MB/sekundē.
2. Pārslēgties uz nesenajiem dārgajiem vaicājumiem.
3. Kārtot pēc Fiziskās nolasīšanas/sekundē lai identificētu vaicājumus, kas intensīvi lasa no diska.
4. Filtrējiet vai vizuāli identificējiet vaicājumus, kas darbojas datubāzē ar augstu ievades/izvades jaudu.
5. Pārbaudiet šo vaicājumu izpildes plānus, lai pārbaudītu tabulas vai trūkstošos indeksus, kas izraisa pārmērīgu ievadizvadi.

Šī vairāku rūšu analīze savieno simptomus (liela diska I/O) ar cēloņiem (konkrēti neefektīvi vaicājumi).

9.2 Aktivitāšu monitora izmantošana noslodzes plānošanai

Lai gan aktivitāšu monitors neuzglabā vēsturiskos datus, to var stratēģiski izmantot noslodzes plānošanas novērojumiem.

9.2.1 Maksimālās lietošanas modeļu noteikšana

Uzraugiet servera aktivitāti dažādos diennakts laikos, lai noteiktu lietošanas modeļus:

1. Atveriet Aktivitāšu monitoru zināmajās maksimālās darba stundās.
2. Ievērojiet procesora laika (%) grafika maksimālās vērtības.
3. Reģistrējiet maksimālo gaidīšanas uzdevumu skaitu.
4. Ievērojiet partijas pieprasījumu skaitu sekundē pīķa stundās.
5. Dokumentējiet noslogotākās datubāzes rūtī Procesi.
6. Salīdzināšanas nolūkos atkārtojiet ārpus pīķa stundām.

Ja procesora noslodze sastrēgumstundās pastāvīgi pārsniedz 80%, jūs tuvojaties centrālā procesora jaudas ierobežojumiem. Līdzīgi, pieaugošs gaidīšanas laiks norāda uz pieaugošu resursu pieprasījumu.

9.2.2 Resursu tendenču analīze

Lai gan aktivitāšu monitors rāda pašreizējo stāvokli, to var izmantot tendenču pārbaudei, laika gaitā reģistrējot galvenos rādītājus:

• Katru dienu vienā un tajā pašā laikā uzņemiet pārskata rūts ekrānuzņēmumus
• Ierakstiet maksimālās vērtības no katra grafika
• Salīdziniet nedēļas nogales, lai noteiktu izaugsmes tendences
• Vērojiet pakāpenisku vidējā procesora laika vai I/O ātruma pieaugumu

Šī manuālā tendenču veidošana papildina sarežģītākus uzraudzības risinājumus un palīdz pamatot jaudas paplašināšanu.

9.3 Veiktspējas bāzes rādītāju dokumentēšana

Pamatrādītāju veiktspējas rādītāju noteikšana palīdz atpazīt, kad veiktspēja pasliktinās.

9.3.1 Pamatrādītāju iegūšana

Periodos, kad ir zināma laba veiktspēja, dokumentējiet aktivitāšu monitora rādītājus:

1. Atveriet Aktivitāšu monitoru parastās darba laikā (nevis pīķa vai ārpus pīķa stundām).
2. Ierakstu pārskata rūts vērtības:
   • Tipisks procesora laika diapazons (%)
   • Vidējais gaidīšanas uzdevumu skaits
   • Normāls datubāzes I/O ātrums
   • Tipiski partijas pieprasījumi/sekundē
3. Piezīme. Resursu gaidīšanas rūts kategorijas, kurās tiek rādīts most gaidīšanas laiks.
4. Dokumentējiet aktīvo procesu skaitu, kas parasti ir iekļauts rūtī Procesi.
5. Ierakstiet reprezentatīvus vaicājumu izpildes rādītājus no nesenajiem dārgajiem vaicājumiem.

Saglabājiet šo pamata dokumentāciju turpmākai uzziņai, izmeklējot veiktspējas problēmas.

9.3.2 Pašreizējās un sākotnējās veiktspējas salīdzinājums

Ja rodas veiktspējas problēmas, salīdziniet pašreizējos aktivitāšu monitora rādījumus ar dokumentēto sākotnējo vērtību:

• Vai procesora laiks ir ievērojami ilgāks nekā bāzes laiks? Koncentrējieties uz vaicājumiem, kas intensīvi izmanto centrālo procesoru (CPU).
• Vai gaidīšanas uzdevumi ir 2–3 reizes lielāki nekā bāzes līmenis? Izpētiet resursu gaidīšanas laiku.
• Vai I/O ir ievērojami augstāks? Pārbaudiet datu faila I/O rūti un dārgos vaicājumus.
• Vai partijas pieprasījumu skaits sastrēgumstundās ir zemāks par sākotnējo līmeni? Meklējiet bloķēšanas vai savienojamības problēmas.

Šis salīdzinājums palīdz noteikt izmaiņas un atbilstoši koncentrēt problēmu novēršanas centienus.

9.4 Pielāgotu uzraudzības darbplūsmu izveide

Izstrādāt sistemātiskas darbplūsmas bieži sastopamiem izmeklēšanas scenārijiem, lai nodrošinātu rūpīgu un atkārtojamu analīzi.

9.4.1 Soli pa solim veikts izmeklēšanas process

Kad lietotāji ziņo par veiktspējas problēmām, ievērojiet konsekventu darbplūsmu:

1. Ātra veselības pārbaude: Atveriet aktivitāšu monitoru un skenējiet pārskata rūts grafikus, lai atrastu acīmredzamas anomālijas.
2. Pārbaudiet bloķēšanu: Izvērsiet rūti Procesi, filtrējiet pēc NonBlanks kolonnā Bloķējis.
3. Identificējiet resursu konfliktu: Resursu gaidīšanas pārskatīšanas rūts, kas sakārtota pēc gaidīšanas laika.
4. Atrodiet dārgus vaicājumus: Izpētiet nesenos dārgos vaicājumus, kas sakārtoti pēc centrālā procesora, pēc tam izpildes un pēc tam nolasīšanas.
5. Korelēt I/O modeļus: Savstarpēji atsaucieties uz dārgiem vaicājumiem, izmantojot datu faila ievades/izvades rūts aktivitātes.
6. Dokumenta konstatējumi: Uzņemiet ekrānuzņēmumus un ierakstiet atbilstošos sesiju ID, gaidīšanas veidus un vaicājuma informāciju.
7. Dziļa niršana: Izmantojiet Profiler izsekošanas datus, izpildes plāna analīzi un DMV vaicājumus, lai veiktu detalizētu identificēto problēmu izpēti.

9.4.2 Eskalācijas kritēriji

Nosakiet kritērijus, kad problēmas ir jāeskalē, nevis jāturpina izmeklēšana:

• Nekavējoties eskalēt: Bloķētas ķēdes, kas ilgst >5 minūtes, procesora laiks 100% ilgāk par >2 minūtēm, kritiski sistēmas procesi ir APTURĒTI.
• Eskalēt ar analīzi: Atkārtoti dārgi vaicājumi, kas patērē >50% centrālā procesora jaudas, pastāvīgi augsti I/O atbildes laiki >50 ms, atmiņas piešķiršanas kļūmes atkārtoti.
• Izpētiet tālāk: Laiksrary gaida atrisināšanu dažu minūšu laikā, vaicājumi ar neoptimāliem plāniem, bet pieņemamu veiktspēju, neliela bloķēšana <30 sekundes.

10. Aktivitāšu monitors dažādos veidos SQL Server versijas

Aktivitāšu monitors ir attīstījies visā SQL Server versijas, un katrā laidienā ir uzlabojumi un reizēm arī jaunas problēmas.

10.1 Aktivitāšu monitors SQL Server 2008. gadā un vēlāk

SQL Server 2008. gadā tika ieviests modernais aktivitāšu monitora dizains, kas mūsdienās lielākoties nav mainījies.

10.1.1 Jaunas funkcijas, kas ieviestas SQL Server 2008

The SQL Server 2008. gada Aktivitāšu monitora pārveidošana ieviesa ievērojamus uzlabojumus:

• Grafisks informācijas panelis ar reāllaika diagrammām pārskata rūtī
• Izvēršama/saliekama rūts saskarne, kas aizstāj veco tikai režģa skatu
• Nesen veikto dārgo vaicājumu rūts, kurā redzami apkopoti vaicājumu veiktspējas dati.
• Datu failu I/O rūts diska aktivitāšu uzraudzībai katrā failā
• Uzlabotā resursu gaidīšanas rūts ar gaidīšanas kategorizāciju
• Ar peles labo pogu noklikšķiniet uz konteksta izvēlnēm procesa darbībām, piemēram, sesiju pārtraukšanai un Profiler palaišanai
• Konfigurējami atsvaidzināšanas intervāli no 1 sekundes līdz 1 stundai

Šīs izmaiņas pārveidoja Aktivitāšu monitoru no vienkārša procesu saraksta par visaptverošu uzraudzības informācijas paneli.

10.1.2 Izmaiņas no SQL Server 2005

SQL Server 2005. gada aktivitāšu monitors bija daudz ierobežotāks:

• Piekļūstams, izmantojot objektu pārlūka pārvaldības mapi, nevis rīkjoslu
• Viens režģis, kurā redzams procesu saraksts ar pamatinformāciju
• Nav grafisku diagrammu vai vairāku rūšu
• Nav dārgu vaicājumu vai I/O uzraudzības
• Ierobežota gaidīšanas statistikas informācija

2008. gada pārprojektēšana bija pilnīga pārdomāšana, nevis pakāpenisks uzlabojums.

10.2 Aktivitāšu monitors SQL Server 2014/2016

SQL Server 2014. un 2016. gadā tika veikti pakāpeniski uzlabojumi Activity Monitor pamatā esošajā datu vākšanā, taču vizuālas izmaiņas bija nelielas.

10.2.1 Uzlabojumi un papildinājumi

Galvenie uzlabojumi šajās versijās ietvēra:

• Labāka veiktspēja, uzraugot serverus ar tūkstošiem kešatmiņā saglabātu plānu
• Uzlabotas filtrēšanas iespējas rūtī Procesi
• Uzlabota gaidīšanas statistikas apkopošanas precizitāte
• Labāka kolonnu kārtošanas un filtrēšanas apstrāde ar lieliem rezultātu kopumiem
• Efektīvāki DMV vaicājumi, samazinot uzraudzības izmaksas

Galvenā saskarne palika nemainīga SQL Server 2008. gadā, saglabājot administratoru zināšanas.

10.3 Aktivitāšu monitors SQL Server 2019/2022

nesens SQL Server versijas turpina Activity Monitor attīstību, koncentrējoties uz veiktspēju un stabilitāti.

10.3.1 Jaunākās funkcijas un iespējas

SQL Server 2019. un 2022. gada aktivitāšu monitorā ir iekļauts:

• Atbalsts jauniem gaidīšanas veidiem, kas ieviesti šajās versijās
• Uzlabota renderēšanas veiktspēja SSMS, izmantojot WPF tehnoloģiju
• Labāka liela skaita aktīvu sesiju apstrāde
• Uzlabota saderība ar mākoņa SQL platformām
• Precīzāki centrālā procesora un ieejas/izejas rādītāji

10.3.2 Zināmas problēmas jaunākajās versijās

SQL Server 2019. gadā tika ieviestas vairākas Activity Monitor kļūdas:

• Pastāvīga apturēta darbība: Aktivitāšu monitors bieži pāriet apturētā stāvoklī un neatsāk darbību, īpaši SSMS 18.0–18.3 versijās. Izlabots jaunākās SSMS versijās.
• Attālā savienojuma kļūmes: Dažas konfigurācijas neļauj atvērt aktivitāšu monitoru attālās instancēs. Risinājumi ietver noteiktu izsekošanas karodziņu iespējošanu vai jaunāku SSMS versiju izmantošanu.
• Atļauju problēmas: Jauniem sistēmas skatiem ir nepieciešamas papildu atļaujas, kas nav skaidri dokumentētas, kā rezultātā tiek rādīti tukši attēli pat ar VIEW SERVER STATE.

Strādājot ar, vienmēr izmantojiet jaunāko SSMS versiju. SQL Server 2019. un 2022. gadā, lai izvairītos no šīm problēmām.

11. Praktiski lietošanas gadījumi un piemēri

Reālās pasaules piemēri demonstrē, kā efektīvi lietot Activity Monitor bieži sastopamās problēmu novēršanas situācijās.

11.1 Gadījuma izpēte: lēnas tīmekļa lietojumprogrammas diagnostika

Izstrādātāju komanda ziņo, ka viņu tīmekļa lietojumprogramma ir kļuvusi nepieņemami lēna, lapu ielādei aizņemot 20–30 sekundes ierasto 2–3 sekunžu vietā.

11.1.1 Sākotnējā izmeklēšana ar pārskata rūti

Atveriet aktivitāšu monitoru un pārbaudiet pārskata rūti:

1. Grafikā “Procesora laiks (%)” ir redzams 85–95 % centrālā procesora noslodze, kas ir ievērojami vairāk nekā parastais 30–40 % bāzes rādītājs.
2. Gaidīšanas uzdevumu skaits svārstās no 10 līdz 20 uzdevumiem, salīdzinot ar normālu sākotnējo rādītāju 0–3.
3. Datu bāzes I/O uzrāda mērenu aktivitāti aptuveni 50 MB/s.
4. Pakešu pieprasījumu skaits sekundē ir mazāks nekā paredzēts — 100 pieprasījumi sekundē, salīdzinot ar tipisku 300–400 pieprasījumu sekundē darba laikā.

Šī tendence norāda uz centrālā procesora sastrēgumu ar resursu pārslodzi, kas izraisa samazinātu caurlaidspēju. Serveris strādā intensīvi, bet neapstrādā daudz pieprasījumu.

11.1.2 Problemātiskā vaicājuma identificēšana

Izvērsiet rūti Nesenie dārgie vaicājumi un kārtojiet pēc izpildes/minūtē:

1. Augšējā vaicājumā tiek rādīti 15 000 izpildes minūtē.
2. Ar peles labo pogu noklikšķiniet uz un izvēlieties Rediģēt vaicājuma tekstu lai izskatītu vaicājumu.
3. Vaicājums ir vienkāršs SELECT priekšraksts, kas izgūst viena lietotāja ierakstu: SELECT * FROM Users WHERE UserId = @UserId.
4. Šim vaicājumam nevajadzētu tikt izpildītam 15 000 reižu minūtē normālas lietojumprogrammas lietošanas laikā.

Ar peles labo pogu noklikšķiniet uz vaicājuma un atlasiet Rādīt izpildes plānuPlānā ir redzama tabulas skenēšana lietotāju tabulā ar brīdinājumu par trūkstošu indeksu lietotāja ID kolonnā.

Filtrējiet procesu rūti pēc lietojumprogrammas, lai tiktu rādīti tikai tīmekļa lietojumprogrammas savienojumi. Vairākās sesijās šis pats vaicājums tiek rādīts atkārtoti.

11.1.3 Risinājums un pārbaude

Problēma rodas divu iemeslu dēļ: pārmērīga vaicājumu izpilde un trūkstošs indekss. Risināšanas soļi:

1. Izveidojiet trūkstošo indeksu:

   CREATE NONCLUSTERED INDEX IX_Users_UserId 
   ON Users (UserId);
   

2. Sazinieties ar izstrādes komandu par pārmērīgo izpildes biežumu. Izmeklēšana atklāj N+1 vaicājuma problēmu lietojumprogrammas kodā, kur cikls izgūst lietotāja datus par katru saraksta elementu.
3. Modificēt lietojumprogrammu lai lietotāju meklējumus apvienotu vienā vaicājumā, izmantojot IN klauzulu vai tabulas vērtības parametru.
4. Pārbaudiet labojumu uzraugot aktivitāšu monitoru pēc izvietošanas. Centrālā procesora noslodze samazinās līdz 35–40 %, izpildes reižu skaits minūtē samazinās līdz 200–300, un lietojumprogrammu atbildes laiki atgriežas normālā stāvoklī.

11.2 Gadījuma izpēte: bloķēšanas problēmas risināšana

Lietotāji ziņo, ka pasūtījumu ievadīšanas sistēma periodiski uz 30–60 sekundēm uzkarst, pirms atsāk normālu darbību.

11.2.1 Bloķējošās ķēdes noteikšana

Atveriet aktivitāšu monitoru viena no šiem iesaldēšanas notikumiem laikā un izvērsiet rūti Procesi:

1. Kārtot pēc Sesijas ID lai skatītu visas organizētās sesijas.
2. Vairākas sesijas parāda vērtības Bloķēja kolonna, kas visas norāda uz sesijas ID 73.
3. 73. sesijā ir redzams '1' Galvas bloķētājs kolonnā, apstiprinot, ka tas ir galvenais cēlonis.
4. The Gaidīšanas veids bloķētām sesijām tiek rādīts LCK_M_X, kas norāda, ka tās gaida ekskluzīvas bloķēšanas.
5. The Gaidīšanas resurss kolonnā redzams, ka bloķēšana ir pasūtījumu tabulā.

11.2.2 Cēloņa analīze

Ar peles labo pogu noklikšķiniet uz 73. sesija un atlasiet Sīkāka informācija lai skatītu komandu:

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

Šis atjauninājums ir daļa no partijas apstrādes uzdevuma, kas tiek izpildīts katru stundu. Pārbauda Ieiet kolonna apstiprina, ka sesija pieder pakešapstrādes pakalpojuma kontam.

Vaicājums apstrādā tūkstošiem pasūtījumu, turot slēdzenes tabulā “Pasūtījumi”. Pagaidiet laiku bloķēto sesiju skaits nepārtraukti pieaug, apstiprinot, ka problēma ir šajā ilgstošajā darbībā.

11.2.3 Labojuma ieviešana

Īstermiņa risinājums:

1. Dokumentējiet 73. sesijas informāciju, tostarp vaicājuma tekstu un ilgumu.
2. Ļaujiet atjauninājumam pabeigties dabiski, jo tā ir likumīga partijas apstrāde.
3. Pēc pabeigšanas pārliecinieties, vai bloķētās sesijas ir noņemtas un vai darbība ir atsākta.

Īstenotie ilgtermiņa risinājumi:

1. Pārplānot partijas darbu lai darbotos ārpus sastrēgumstundām (no plkst. 2–4, nevis darba laikā).
2. Modificēt partijas apstrādi atjaunināt pasūtījumus mazākās partijās pa 100 ierakstiem vienlaikus, atbrīvojot bloķējumus starp partijām.
3. Pievienot indeksu kolonnā “Pasūtījuma ID”, lai paātrinātu atjaunināšanas darbību.
4. Apsveriet SNAPSHOT izolāciju lasīšanas darbībām, lai samazinātu bloķēšanas ietekmi.

11.3 Gadījuma izpēte: pārmērīgas vaicājumu izpildes identificēšana

Datu bāzes uzraudzība liecina, ka centrālā procesora noslodze pēdējā mēneša laikā ir pakāpeniski palielinājusies, taču lietojumprogrammas kodā nav notikušas acīmredzamas izmaiņas.

11.3.1 Nenormālu izpildes reižu skaita noteikšana

Atveriet aktivitāšu monitoru un pārbaudiet rūti Nesenie dārgie vaicājumi:

1. Kārtot pēc Izpildes/minūtē lai redzētu most bieži izpildīti vaicājumi.
2. Populārākais vaicājums uzrāda 37 000 izpildes minūtē — daudz vairāk nekā jebkurš cits vaicājums.
3. Ar peles labo pogu noklikšķiniet uz un izvēlieties Rediģēt vaicājuma tekstu.
4. Vaicājums izgūst informāciju par produktu kategoriju:

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

5. Šim vienkāršajam vaicājumam vajadzētu būt ātram un kešatmiņā saglabājamam, tomēr tas tiek izpildīts desmitiem tūkstošu reižu minūtē.

11.3.2 Izsekošana līdz lietojumprogrammas kodam

Procesu rūtī atrodiet sesijas, kas izpilda šo vaicājumu:

1. Piezīme iesniegums kolonnā ir redzams “ProductCatalogService”.
2. Ar peles labo pogu noklikšķiniet uz vienas no šīm sesijām un atlasiet Izsekošanas process SQL Server Profils.
3. SQL Profiler atklāj, ka vaicājums tiek izpildīts atkārtoti ātrā secībā ar dažādām CategoryId vērtībām.
4. Lai pārskatītu kodu, sazinieties ar ProductCatalogService pārvaldošo izstrādes komandu.

Koda pārskatīšana atklāj problēmu: nesen veiktas izmaiņas izgūst produktu sarakstus ar kategorijām. Katram produktam rezultātu kopā (bieži vien vairāk nekā 1,000 produktu) kods veic atsevišķu datubāzes izsaukumu, lai izgūtu kategorijas informāciju — klasiska N+1 vaicājuma problēma.

11.3.3 Lietojumprogrammas optimizācija

Ieviesiet atbilstošu labojumu:

1. Modificēt lietojumprogrammas vaicājumu Lai izmantotu JOIN, kas izgūst produktus un to kategorijas vienā datubāzes izsaukumā:

   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. Izvietot atjaunināto kodu un uzraudzīt aktivitātes monitoru.
3. Pārbaudiet labojumu: Izpildes skaits minūtē kategorijas vaicājumam samazinās no 37 000 līdz mazāk nekā 100, un kopējais centrālā procesora noslodze samazinās par 40 %.
4. Dokumentējiet gūto mācību un kopīgojiet to ar izstrādes komandu, lai novērstu līdzīgas problēmas turpmākajās koda izmaiņās.

12. Iespējamu datubāzes bojājumu noteikšana

Lai gan aktivitāšu monitors nav īpaši izstrādāts datubāzes bojājumu noteikšanai, noteikti tā attēlojuma modeļi var liecināt par pamatā esošām bojājumu problēmām, kurām nepieciešama turpmāka izmeklēšana.

12.1 Iespējamas datubāzes bojājuma simptomi

Ja datubāze ir bojāta un tai piekļūst, laiku pa laikam varat redzēt:

1. Procesu rūtī:

• Sesijas iestrēgušas APTURĒTĀ stāvoklī ar neparastiem gaidīšanas veidiem
• Procesi, kas rāda kļūdu stāvokļus
• Vaicājumi atkārtoti neizdodas

2. Resursu gaidīšanas rūtī:

• Neparasti ar I/O saistīti gaidīšanas veidi, kas varētu liecināt par diska problēmām (lai gan tas, visticamāk, norāda uz aparatūras problēmām, nevis loģikas bojājumiem)

3. Neseno dārgo vaicājumu sadaļā:

• Vaicājumi ar neparasti augstu fizisko nolasījumu skaitu, ja tie atkārtoti mēģina nolasīt bojātas lapas

12.2 Papildu pārbaude ar DBCC CHECKDB

Kad aktivitāšu monitors parāda simptomus, kas liecina par iespējamu bojājumu, nekavējoties jāpalaiž komanda DBCC CHECKDB, lai pārbaudītu datubāzes integritāti. Šī komanda skenē visas datubāzes lapas, validē kontrolsummas un pārbauda, ​​vai nav loģiskās konsekvences kļūdu.

Lai uzzinātu vairāk par to, kā izmantot DBCC CHECKDB, lai pārbaudītu un labotu datubāzes bojājumus, skatiet mūsu visaptveroša DBCC CHECKDB rokasgrāmata.

12.3 Remonts ar profesionāliem instrumentiem

Ja DBCC CHECKDB apstiprina datubāzes bojājumus, jums ir vairākas labošanas iespējas:

• Ieteicamā pieeja ir atjaunošana no zināmas, drošas dublējuma. Skatiet sadaļu “Atjaunošana”. mūsu visaptverošais ceļvedis par dublēšanu un atjaunošanu SQL Server datu bāzes.
• Nelielu bojājumu gadījumā problēmas var atrisināt, izmantojot DBCC CHECKDB ar REPAIR_REBUILD.
• Kritiskām datubāzēm, kurām nav nesen veiktu dublējumu, profesionālis SQL atkopšanas programmatūra un pakalpojumi bieži vien var atgūt datus, ko iebūvētās labošanas iespējas nevar atgūt.

13. secinājums

SQL Server Aktivitāšu monitors ir nenovērtējams rīks datubāzu administratoriem, kas sniedz tūlītēju ieskatu servera veiktspējā un palīdz ātri un efektīvi diagnosticēt problēmas.

13.1. Galveno punktu kopsavilkums

Šajā rokasgrāmatā esam izpētījuši, kā Aktivitāšu monitors palīdz izprast un novērst problēmas SQL Server izpildījums:

• Aktivitāšu monitors nodrošina reāllaika pārskatāmību procesos, gaidīšanas laikos, vaicājumos un ievadizvadē, izmantojot organizētu, grafisku saskarni.
• Piecas rūtis — Pārskats, Procesi, Resursu gaidīšanas, Datu failu I/O un Nesenie dārgie vaicājumi — katra piedāvā unikālu perspektīvu par servera darbību.
• Bieži sastopamas problēmu novēršanas situācijas, piemēram, pārmērīga vaicājumu izpilde, bloķējošas ķēdes un augsta centrālā procesora noslodze, kļūst pārvaldāmas ar sistemātisku aktivitāšu monitora izmeklēšanu.
• Lai gan aktivitāšu monitors ir jaudīgs, tam ir ierobežojumi, tostarp vēsturisko datu trūkums, gaidīšanas tipa grupēšana un uzraudzības izmaksas, kas ietekmē tā piemērošanu.cabspēju.
• Papildinot Aktivitāšu monitoru ar DMV vaicājumiem, sp_WhoIsActive, paplašinātiem notikumiem un, iespējams, trešo pušu rīkiem, tiek izveidota visaptveroša uzraudzības stratēģija.
• Ievērojot labāko praksi attiecībā uz atsvaidzināšanas intervāliem, Aktivitāšu monitora aizvēršana, kad tas netiek lietots, un vairāku rūšu apvienošana korelācijas nolūkos palielina tā vērtību, vienlaikus samazinot ietekmi.

13.2 Aktivitāšu monitors kā daļa no jūsu rīku komplekta

Aktivitāšu monitoram vajadzētu kalpot kā jūsu pirmajam reaģēšanas rīkam veiktspējas pārbaudēm, nevis vienīgajam rīkam. Tā stiprā puse ir tūlītējas redzamības nodrošināšana aktīvas problēmu novēršanas laikā, palīdzot ātri noteikt, vai datubāze ir vājā vieta, un identificēt konkrētus aspektus, kuriem nepieciešama padziļināta izpēte.

Iedomājieties Activity Monitor kā analoģisku instrumentu jūsu automašīnas informācijas panelim — tas nekavējoties paziņo, ja kaut kas nav kārtībā, un palīdz noteikt vispārējo problēmu zonu. Tāpat kā jūsu automašīnas informācijas panelis nepasaka precīzu iemeslu, kāpēc iedegas Check Engine lampiņa, Activity Monitor norāda uz problēmām, ne vienmēr atklājot to pilnīgo cēloni. Šādai padziļinātai analīzei ir nepieciešami papildu rīki un zināšanas.

Integrējiet aktivitāšu monitoru plašākā rīku komplektā, kas ietver izpildes plāna analīzi, gaidīšanas statistikas izsekošanu, vēsturiskās uzraudzības risinājumus un veiktspējas paraugpraksi. Izmantojiet to kopā ar atbilstošām indeksēšanas stratēģijām, vaicājumu optimizācijas metodēm un noslodzes plānošanu.

13.3 Mācību ceļojuma turpināšana

Aktivitāšu monitora apgūšana ir tikai viens solis ceļā uz efektīva datubāzes administratora kļūšanu. Turpiniet pilnveidot savas prasmes, veicot tālāk norādītās darbības.

• Mācīšanās interpretēt izpildes plānus un identificēt neefektīvas darbības
• Izpratne SQL Server gaidīšanas statistika un tās ietekme
• Indeksu dizaina un optimizācijas metožu izpēte
• Izpētīt SQL Serverarhitektūra un vaicājumu apstrāde
• Sistemātisku problēmu novēršanas metožu praktizēšana
• Pieredzes veidošana ar paplašinātiem notikumiem detalizētai izsekošanai
• Transakciju izolācijas līmeņu un to ietekmes uz veiktspēju izpratne

Katra veiktspējas pārbaude ar Aktivitāšu monitoru iemāca kaut ko jaunu par to, kā SQL Server darbojas un kā lietojumprogrammas mijiedarbojas ar datubāzēm. Dokumentējiet savus atklājumus, dalieties zināšanās ar kolēģiem un izveidojiet bibliotēkurarrisinājumu y bieži sastopamām problēmām.

13.4 Papildu resursi

Paplašiniet savas zināšanas ar šiem vērtīgajiem resursiem:

• Atveriet aktivitāšu monitoru SQL Server Management Studio (SSMS) : Oficiāls SQL Server dokumentācija par to, kā atvērt aktivitāšu monitoru SQL Server Vadības studija (SSMS).
• Activity Monitor : Oficiālā SQL Server dokuments par aktivitāšu monitora lietošanu.

14. Bieži uzdotie jautājumi (BUJ)

J: Kas ir SQL Server ActivityMonitor?

A: SQL Server Aktivitāšu monitors ir iebūvēts rīks SQL Server Vadības studija, kas reāllaikā parāda informāciju par procesiem, kas darbojas ierīcē SQL Server instanci un to ietekmi uz servera resursiem. Tas nodrošina grafisku informācijas paneli ar piecām rūtīm, kurās redzami dažādi servera darbības aspekti, tostarp procesora izmantošana, gaidīšanas uzdevumi, ievades/izvades ātrumi, aktīvās sesijas un dārgi vaicājumi.

J: Kā atvērt aktivitāšu monitoru pakalpojumā SSMS?

A: Aktivitāšu monitoru var atvērt, izmantojot četras metodes: (1) SSMS rīkjoslā noklikšķiniet uz Aktivitāšu monitora ikonas, (2) ar peles labo pogu noklikšķiniet uz SQL Server instances nosaukums objektu pārlūkā un atlasiet Activity Monitor, (3) Nospiediet Ctrl + cits + Avai (4) konfigurējiet SSMS, lai tā tiktu palaista automātiski, izmantojot darbarīki -> opcijas -> vide -> Starcaurule.

J: Kādas atļaujas man ir nepieciešamas, lai izmantotu Aktivitāšu monitoru?

A: Jums ir nepieciešams SKATĪT SERVERA STĀVOKLĪ atļauja mani redzētost Aktivitāšu monitora informācija. Datu faila ievades/izvades rūtij ir nepieciešams arī IZVEIDOT DATU BĀZI, MAINĪT JEBKURU DATUBĀZI, vai SKATĪT JEBKURU DEFINĪCIJU atļaujas. Bez šīm atļaujām Aktivitāšu monitors var tikt atvērts, bet tajā var tikt parādītas tukšas rūtis.

J: Kāpēc mans Aktivitāšu monitors ir apturēts vai nedarbojas?

A: Aktivitāšu monitors parasti pārtrauc darbību atļauju problēmu, novecojušu SSMS versiju vai atspējotu attālo savienojumu dēļ. Lai novērstu problēmu: (1) atjauniniet uz jaunāko SSMS versiju, (2) pārliecinieties, vai jums ir atļauja SKATĪT SERVERA STĀVOKLĪ, (3) pārbaudiet, vai ierīcē ir iespējoti attālie savienojumi. SQL Server piemēram, (4) Rez.tart SSMS un (5) Ja piemērojams, mēģiniet izveidot savienojumu ar Windows autentifikāciju SQL autentifikācijas vietā.cabviņiem.

J: Kāda ir atšķirība starp aktivitāšu monitoru un sp_WhoIsActive?

A: Aktivitāšu monitors ir grafisks rīks, kas iebūvēts SSMS un nodrošina organizētas rūtis dažādiem uzraudzības aspektiem. sp_WhoIsActive ir bezmaksas kopienas izveidota saglabātā procedūra, kas atgriež detalizētu sesijas informāciju vienā rezultātu kopā ar specifiskākiem gaidīšanas veidiem, bloķēšanas informāciju un pielāgošanas iespējām nekā Aktivitāšu monitors. Aktivitāšu monitors ir labāk piemērots vizuālai izpētei, savukārt sp_WhoIsActive izceļas ar skriptētu uzraudzību un sniedz detalizētāku informāciju.

J: Vai aktivitāšu monitors ietekmē servera veiktspēju?

A: Jā, aktivitāšu monitoram ir izmērāmas papildu izmaksas, jo tas vaicā sistēmas DMV katrā atsvaidzināšanas intervālā. Ietekme palielinās, samazinoties atsvaidzināšanas frekvencēm — Microsoft brīdina, ka intervāli, kas mazāki par 10 sekundēm, var ietekmēt servera veiktspēju. Vienmēr aizveriet aktivitāšu monitoru, kad to aktīvi nelietojat, un ņemiet vērā 30–60 sekunžu atsvaidzināšanas intervālus ražošanas serveros ar lielu slodzi.

J: Vai varu iegūt aktivitāšu monitora datus, izmantojot T-SQL?

A: Jā, aktivitāšu monitors vaicā sistēmas dinamiskās pārvaldības skatus, piemēram, sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_wait_stats un sys.dm_exec_query_stats. Šos DMV var vaicāt tieši, izmantojot T-SQL, lai programmiski izgūtu līdzvērtīgu informāciju, iespējojot pielāgotus uzraudzības skriptus un automatizētu datu vākšanu.

J: Kāds ir noklusējuma atsvaidzināšanas intervāls?

A: Noklusējuma atsvaidzināšanas intervāls ir 10 sekundes. To var mainīt, ar peles labo pogu noklikšķinot jebkur pārskata rūtī un atlasot Atsvaidzināšanas intervālsun izvēloties no iepriekš definētām opcijām: 1 sekunde, 5 sekundes, 10 sekundes, 30 sekundes, 1 minūte vai 1 stunda. Īsāki intervāli nodrošina vairāk reāllaika skatu, bet palielina uzraudzības izmaksas.

J: Kā es varu automātiski atvērt aktivitāšu monitoru SSMS?tartup?

A: Konfigurējiet automātisko palaišanu, izmantojot SSMS opcijas: dodieties uz darbarīki -> opcijas -> vide -> Starcaurule, Pēc tam izvēlieties Atvērt objektu pārlūku un aktivitāšu monitoru no Pie starcaurule nolaižamā izvēlne. Aktivitāšu monitors tiks automātiski atvērts katru reizi, kad izveidosiet savienojumu ar serveri SSMS.

J: Kādi ir Aktivitāšu monitora ierobežojumi?

A: Galvenie ierobežojumi ir šādi: (1) Nav vēsturisku datu glabāšanas vai tendenču veidošanas iespēju, (2) Gaidīšanas veidi ir grupēti kategorijās, nevis parādīti konkrēti, (3) Daži gaidīšanas veidi, piemēram, CXPACKET, var netikt parādīti, (4) Noteikta laika momentuzņēmumi var nepamanīt īslaicīgas problēmas, (5) Uzraudzības izmaksas var ietekmēt noslogotus serverus, (6) Nav brīdināšanas mehānisma proaktīvai uzraudzībai un (7) Nevar apkopot datus vairākos serveros SQL Server instances. Šīm vajadzībām papildiniet aktivitāšu monitoru ar paplašinātiem notikumiem, datu vākšanas kopām vai trešo pušu uzraudzības rīkiem.

---

par autoru

Juaņs Šens ir vecākais datubāzes administrators (DBA) ar vairāk nekā 10 gadu pieredzi SQL Server vides un uzņēmumu datubāzu pārvaldību. Viņš ir veiksmīgi atrisinājis simtiem datubāzu atkopšanas scenāriju finanšu pakalpojumu, veselības aprūpes un ražošanas organizācijās.

Juaņa specializējas SQL Server datubāzes atgūšana, augstas pieejamības risinājumi, un veiktspējas optimizāciju. Viņa plašā praktiskā pieredze ietver vairāku terabaitu datubāzu pārvaldību, Always On pieejamības grupu ieviešanu un automatizētu dublēšanas un atkopšanas stratēģiju izstrādi kritiski svarīgām biznesa sistēmām.

Izmantojot savu tehnisko pieredzi un praktisko pieeju, Juans koncentrējas uz visaptverošu rokasgrāmatu izveidi, kas palīdz datubāzu administratoriem un IT speciālistiem risināt sarežģītus jautājumus SQL Server efektīvi izaicina. Viņš seko līdzi jaunākajām tendencēm SQL Server laidieniem un Microsoft attīstītajām datubāzu tehnoloģijām, regulāri testējot atkopšanas scenārijus, lai nodrošinātu, ka viņa ieteikumi atspoguļo labāko praksi reālajā pasaulē.

Ir jautājumi par SQL Server atkopšanai vai nepieciešama papildu palīdzība datubāzes problēmu novēršanā? Juans laipni aicina atsauksmes un ieteikumi lai uzlabotu šos tehniskos resursus.