Buna ziua. Acum cateva saptamani am trecut de pe SQL Server 2000 pe 2005 Standard SP2, si tot de atunci au inceput problemele. Interogarile/tranzactiile in baza merg foarte greu. Am reindexat indecsi/tabele, am facut update la statistici - nu am rezolvat problema. Utilizatorii nu s-au inmultit, partea hardware e aceeasi (2 procesoare 3G, memorie 4G, Windows 2000 Server). Spre deosebire de SQL2000, nu mai am (sau nu mai vad !!!) blocaje intre utilizatori, dar timpul de asteptare pentru o interogare / tranzactie tinde spre infinit.

    Am o intrebare suplimentara: in master.dbo.sysprocesses am coloana memusage. In sql2000 vedeam cat consuma din memorie fiecare spid. In 2005 valoarea maxima pe care o vad in aceasta coloana e 2 (rar un 4), in timp ce in SQL2000 se ducea si la valori de ordinul sutelor. Am o setare pe server care limiteaza memoria per tranzactie sau sysprocesses e "deprecated" in 2005 ?

   Multumesc anticipat pentru orice idee. Cristin

Ai rulat sp_updatestats / UPDATE STATISTICS si DBCC UPDATEUSAGE? Uneori se pare ca e necesar un "rebuild" pentru indecsi. Care sunt query-urile lente? Poate ai probleme cu discul (---> perfmon ---> Avg. Disk Queue Length)?

Da, sysprocesses e "deprecated" in 2005. Incearca sys.dm_exec_sessions, sys.dm_exec_requests.

Daca sunt totusi blocaje, le poti vedea in management studio ---> management ---> Activity monitor. Vezi si http://blogs.msdn.com/slavao/archive/2006/11/14/sqlosdmv-s-continue.aspx si http://blogs.msdn.com/slavao/archive/2006/09/28/776437.aspx .

...si in afara de toate astea pot fi probleme care isi au originea in aplicatie...greu de spus acum...

Incearca sa forteti recompilarea / refacerea planului de executie:
sp_recompile
si eventual pe o baza de date TEST
DBCC FLUSHPROCINDB( db_id )
DBCC FREEPROCCACHE

porneste un sql profiler si investigheaza query-urile cu probleme.
intrebare: cum ai trecut de la 2000 la 2005 ? back-up si restore?

1. De la 2000 la 2005 am trecut prin attach ... nu am facut restore.

2. UPDATE STATISTICS si "rebuild" pentru indecsi rulez sapamanal, intr-un plan de maintenanta.

3. Si aplicatia e la o noua versiune, si pentru ca incepuse sa ruleze mai greu pe 2000, am "sarit" pe SQL 2005, in speranta ca o se "miste" mai repede. Nu s-a miscat ...

3. Pentru vizualizarea blocajelor foloseam o interogare pe care o rulam automat din 5 in 5 sec. Se uita in master.dbo.sysprocesses. In 2005, aceeasi interogare nu mai da aproape nici un blocaj... dar utilizatorii "rai" care imi dadeau bataie de cap si inainte (rapoarte rulate pe ani de zile, de doua-trei ori pe zi, care "omorau" facturarea ...) sigur mai ruleaza rapoartele respective si in prezent, dar nu ii mai "vad" in interogarea mea.

4. Profilerul nu prea ma ajuta, chiar daca identific selecturile cu probleme, nu am acces la ele (inglobate in aplicatie). Pot doar sa ma enervez de la prima ora !

Încearcă să foloseşti READ_COMMITTED_SNAPSHOT ON ( [1], [2] )  / FROM tabela WITH(NOLOCK) la acele interogări rulate pe mai multi ani dar atentie la situatiile de tipul acesta.

Duncan Bart blog [1], [2], [3]

Capitol Waiting and Blocking Issues (PDF)

Poate ajută şi Troubleshooting Performance Problems in SQL Server 2005

cristin:

3. Si aplicatia e la o noua versiune, si pentru ca incepuse sa ruleze mai greu pe 2000, am "sarit" pe SQL 2005, in speranta ca o se "miste" mai repede. Nu s-a miscat ...

[...]

4. Profilerul nu prea ma ajuta, chiar daca identific selecturile cu probleme, nu am acces la ele (inglobate in aplicatie). Pot doar sa ma enervez de la prima ora !

TARE !!!! Poti sa treci si la SQL Server 2008, si la ce mai vrei tu ... O aplicatie care e prost facuta ramine asa.
Ce pot sa iti sugerez este politica : documentezi ce Select-uri merg greu, documentezi de ce, in ciuda a orice index-uri, si trimiti la aia care au cumparat aplicatia...Sau le trimiti celor care au facut aplicatia sugestii pentru versiunea urmatoare ...

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

nu prea e "tare". Aplicatia e facuta in strainatate, si pana in prezent nu prea s-au "obosit" si raspunda la sugestiile mele, sa mai si rezolve din ele nici atat ... O utilizam de peste 6 ani, si am trecut prin cateva update-uri, care imbunatateau calitatea tranzactiilor. Daca aveau probleme cu ultima versiune a aplicatiei, scoteau un patch pe piata, sunt destule firme in Romania care folosesc aceasta aplicatie.

     Grija mea e sa nu fi uitat sa rulez vreun pas in trecerea de pe 2000 pe 2005, care sa afecteze baza de date.

cristin:

     Grija mea e sa nu fi uitat sa rulez vreun pas in trecerea de pe 2000 pe 2005, care sa afecteze baza de date.

Daca zici ca performanta e proasta pe SQL 2000, nu vad de ce ar fi (mult mai ) buna in 2005...
Pentru uzul managerilor, documenteaza care merg greu - si ce ai facut ca sa imbunatatesti performanta (indexi, ram, hard, etc). Apoi da-o mai departe ...
Dar utilizatorii se pling ? Nu ar fi pentru prima oara cind oamenii, mai flexibili, se adapteaza la soft in loc de invers..

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

cred ca am rezolvat problema. Asta dupa ce am observat ca o procedura ce rula f. rapid pe o baza de teste, se lungea la infinit dupa mutarea pe baza de productie, si in "Activity Monitor" am vazut ca se bloca pe sine insusi. Am modificat optiunea "Max degree of parallelism" din 0 (folosirea toturor procesoarelor de pe server in interogari - am 2 procesoare) in 1. Am observat o "linistire" rapida a tuturor problemelor din acest moment, si de atunci au trecut vreo 2 saptamani.  Nu imi explic totusi cauza, si pe SQL 2000 am avut activata optiunea sa foloseasca toate procesoarele, si nu am avut probleme acestea.

Oricum, va multumesc pentru sfaturi, m-au ajutat si cateva din ele le-am bagat in joburile de optimizare!

Poti incerca sa rulezi numai query-ul / query-urile cu probleme folosind OPTION (MAXDOP 1) - deci mai "granular", fara sa schimbi "max degree of parallelism" la nivel de server.