Salut,

am o problema legata de un job pe un SQL SERVER.
Acest job ruleaza la interval de un minut, pentru a prelucra datele primite. Pana acum jobul respectiv a functionat foarte bine,
dar de cateva zile a inceput sa consume prea mult din procesor (in jur de 99%).

Am oprit jobul respectiv, si am incercat sa rulez procedura pentru a vedea unde este problema.
Am remarcat ca problema apare la

select *
into ##tmpConsignorMobilePackages

Prima tendinta a fost sa repornesc serverul SQL, dar nu pot face acest lucru momentan.
Imi poate da cineva o directie in care sa sap?


Multumesc pentru timpul acordat,
Crysty POPESCU

 Poti da mai multe detalii despre investigatie, mediu de lucru si despre codul problematic?

Vezi si http://technet.microsoft.com/en-us/library/cc966540.aspx.

Din interogarea publicata de dvs. lipseste partea cea mai interesanta: where ... group by ... having ... order by ?!

Buna Ziua,

va multumesc pentru interesul acordat.
FOlosesc Microsoft SQL Server 2005 - 9.00.1406.00 (X64)   Standard Edition (64-bit) pe un server  Windows NT 5.2 (Build 3790: Service Pack 2)

Am mai facut niste teste si presupun ca problema provine de la codul urmator:

select top 1 *
from statushistory
where sth_number in
(select pac_parcelNumber
from package)
AND sth_fk_sge is null
AND sth_fk_sat = 27

unde tabela StatusHistory contine 5200000 inregistrari,
iar package contine 2300000 inregistrari.

Am sa incerc sa optimizez acest cod.

Cu stima,
Crysty POPESCU

SQL 2000, SQL 2005, SQL 2008? Express, Standard, Enterprise? Pe W2K, W2K3? OS Standard sau Enterprise? Cite procesoare? Cite discuri? Cita memorie? x86 sau amd64?

Daca jobul a functionat bine pina acuma citeva zile, ce sa schimbat acu' citeva zile?
A crescut baza de date? S-a instala un path de SQL sau de OS? Ruleaza si alt job acuma? Schimbari in configuratia hardware? Schimbari in structura datelor (index adaugat, schimbat, sters, coloane schimbate, etc etc).

Investigheaza Performance counter-ii de baza, in special Avg. Disk Queue Length pe fiecare disk si Page Faults. Asa, un raspuns complect pe ghicite si fara nefundamentat pe nici o data (hmm... in lipsa de date): a crescut baza de date si nu mai ai destula memorie RAM pentru un caching eficient.

---

http://rusanu.com

crystyp:

select top 1 *
from statushistory
where sth_number in
(select pac_parcelNumber
from package)
AND sth_fk_sge is null
AND sth_fk_sat = 27

Ruleaza asta cu SET STATISTICS IO ON; si vezi daca accesul e scan sau seek (cite logical reads pe fiecare rowset).
Altfel:
1) TOP 1 fara ORDER BY este incorect
2) sth_number IN (select) este inner join mascat, scoate-l afara explicit ca JOIN

---

http://rusanu.com

Multumesc pentru ajutor.

Am incercat sa fac acest lucru, si dupa o perioada CPU Usage a crescut la 100%.
Imi este teama ca acest lucru ar putea impiedica buna desfasurare a site-ului, din acest motiv am intrerupt executia procedurii.

Am sa copiez baza de date pe calculatorul meu, si am sa incerc si pe local codul.
Dupa ora 17:30 am sa incerc si pe serverul de productie codul respectiv.

Cus tima,
Crysty POPESCU

crystyp:

Multumesc pentru ajutor.

Am incercat sa fac acest lucru, si dupa o perioada CPU Usage a crescut la 100%.
Imi este teama ca acest lucru ar putea impiedica buna desfasurare a site-ului, din acest motiv am intrerupt executia procedurii.

Ce altceva s-a mai intamplat pe server in aceasta perioada?

Din pacate nu stiu exact.
Am avut o saptamana de concediu si nu stiu ce anume aparut in acest interval. In mod cert ca baza de date a crescut, dar cu max 200Mb.

Din cauza spatiului limitat pe server, nu tinem decat ultimul backup, si nu pot face o comparatie cu marimea bazei de date de acum o saptmana.


Cu stima,
Crysty POPESCU

Am executat sintaxa

SET STATISTICS IO ON

select *
from statushistory
where sth_number in
(select pac_parcelNumber
from package)
AND sth_fk_sge is null
AND sth_fk_sat = 27

Acum a durat doar 8 secunde.

Rezultatul este acesta:

(0 row(s) affected)
Table 'StatusHistory'. Scan count 3, logical reads 38899, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Package'. Scan count 3, logical reads 24920, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.


Este posibil ca in perioada aceasta clientii sa nu foloseasca prea mult site-ul; nu gasesc alta explicatie.

Cum arata planul de executie? Cum sunt indexate tabelele Package si StatusHistory? Dupa cum te-a sfatuit Remus - incearca sa inlocuiesti "IN" Cu un "INNER JOIN".

...si chiar ai nevoie de "SELECT *"?

crystyp:

Am executat sintaxa

Table 'StatusHistory'. Scan count 3, logical reads 38899, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Package'. Scan count 3, logical reads 24920, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Citest 39k pagini din StatusHistory si 25k pagini din Package ca sa produci 1 (unu) row. A durat doar 8 secunde ca totul era in memorie, cached (0 physical reads). Dureaza probabil mult cind cache-ul e cold si chiar trebuie sa citeasca.

Query-ul tau poate fi rescris sa faca seek, nu scan, daca schimbi inner-select-ul in join, adaugi un index pe pac_parcelNumber in package, si un index pe (sth_fk_sat, sth_number) cu include (sth_fk_sge) pe status_history. Evident, fara sa stiu ce face resytul aplicatiei nu pot sa spun daca asta e solutia corecta sau nu, dar absolut trebuie sa elimini SCAN-ul si sa se faca SEEK.

Rolul tau vis-a-vis aceasta baza de date si aplicatie care e? dba, admin, developer?

---

http://rusanu.com

Va multumesc pentru ajutor.

Am sa fac modificarile necesare.

Cu stima,
Crysty POPESCU

Salut.

Ar mai fi o idee, de fapt un tool. Desi nu poate fi considerat ca un panaceu universal, parerea mea este ca ToadXpert te poate ajuta (www.quest.com). Pe langa asta, poti folosi si DTA-ul din SQL Server, pentru missing indexes, asta dupa ce ai rescris selectul conform sugestiilor date deja de colegi.

toate cele bune,
calin