Interogarea se scurge de la aplicația web, dar rulează bine din studioul de management
Aceasta este o întrebare pe care am întrebat-o într-un alt forum care a primit câteva răspunsuri decente, dar am vrut să văd dacă cineva aici are mai multă înțelegere.
Problema este că aveți una dintre paginile dvs. într-o aplicație web care se dezactivează atunci când ajunge la un apel procedură stocată, deci utilizați Sql Profiler sau jurnalele de urmărire a aplicației pentru a găsi interogarea și o inserați în studio de management motivul pentru care rulează lent. Dar rulați-l de acolo și pur și simplu se aprind, întorcându-se în mai puțin de o secundă de fiecare dată.
Cazul meu special a fost utilizarea ASP.NET 2.0 si Sql Server 2005, dar cred ca problema ar putea fi aplicata oricarui sistem RDBMS.
Încercați să schimbați valoarea timeout-ului SelectCommand:
DataAdapter.SelectCommand.CommandTimeout = 120;
Aceasta este ceea ce am învățat până acum din cercetarea mea.
.NET trimite setările de conectare care nu sunt aceleași cu cele pe care le obțineți atunci când vă conectați la un studio de management. Iată ce vedeți dacă spulberați conexiunea cu profilul de șablon:
-- network protocol: TCP/IP
set quoted_identifier off
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls off
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
Acum încadrez setările de mai sus la fiecare interogare pe care o rulez când sunt conectat la serverul SQL, pentru a vă asigura că setările sunt identice.
În acest caz, am încercat fiecare setare individuală, după deconectare și reconectare, și am constatat că schimbarea arithabort-ului de la off to on a redus interogarea problemei de la 90 secunde la 1 secundă.
Explicația cea mai probabilă este legată de sniffing-ul parametrului, care este o tehnică pe care Sql Server o folosește pentru a alege ceea ce crede că este cel mai eficient plan de interogare. Când schimbați una dintre setările de conectare, optimizatorul de interogări ar putea alege un plan diferit și, în acest caz, se pare că a ales unul rău.
Dar nu sunt absolut convins de asta. Am încercat să comparăm planurile de interogare reale după ce am schimbat această setare și încă nu am văzut diferența afișând modificările.
Există altceva despre setarea arithabort care ar putea cauza o rulare înceată în unele cazuri?
Soluția părea simplă: puneți aritabortul setat în partea superioară a procedurii stocate. Dar acest lucru ar putea duce la problema opusă: schimbarea parametrilor interogării și brusc se execută mai repede cu "off" decât cu "on".
În prezent, execut procedura "recompilați" pentru a vă asigura că planul este regenerat de fiecare dată. Este bine pentru acest raport special, deoarece durează o secundă pentru a recompila, iar acest lucru nu este prea evident pentru un raport care durează 1-10 secunde pentru a reveni (este un monstru).
Dar nu este o opțiune pentru alte interogări care rulează mult mai frecvent și trebuie să se întoarcă cât mai repede posibil, în doar câteva milisecunde.
încercați acest lucru pe o casetă de așteptare în primul rând, schimbați-l la un nivel de server pentru serverul sql
declară @option int
setați @option = @@ opțiuni 64
exec sp_configure 'opțiuni utilizator', @option
reconfigureze
Ați activat încă urmărirea ASP.NET? Am avut un exemplu în care nu a fost procedeul stocat în sine SQL care a fost problema, a fost faptul că procedura a returnat 5000 de rânduri și aplicația a încercat să creeze databound ListItems cu cele 5000 de elemente care au cauzat problema.
S-ar putea să vă uitați în timpii de execuție între funcțiile aplicației web, precum și prin urmă, pentru a vă ajuta să urmăriți lucrurile în jos.
Puteți încerca să utilizați comanda sp_who2 pentru a vedea ce proces în cauză faceți. Acest lucru vă va arăta dacă este blocat de un alt proces sau dacă utilizați o cantitate excesivă de procesor și/sau timp.
Aceeași problemă pe care am avut-o și cu serviciile de raportare SQL. Încercați să verificați tipul de variabile, Am trimis un tip diferit de variabile la SQL, cum ar fi trimiterea lui varchar acolo unde ar trebui fie intreg, sau ceva de genul asta. După ce am sincronizat tipurile de variabile din serviciul de raportare și în procedura stocată pe SQL, am rezolvat problema.
Am avut probleme similare. Încercați să setați opțiunea "WITH RECOMPILE" de pe sproc create pentru a forța sistemul să recompute planul de execuție de fiecare dată când este apelat. Uneori, procesorul Query devine confuz în proceduri complexe stocate, cu o mulțime de declarații de ramificație sau caz și doar trage un plan de execuție cu adevărat sub-optim. Dacă aceasta pare să "repare" problema, probabil că va trebui să verificați statisticile actualizate și/sau să defalcați sprocul.
De asemenea, puteți confirma acest lucru prin profilarea sprocului. Când îl executați din SQL Managment Studio, cum se compară IO atunci când îl profilați din aplicația ASP.NET. Dacă ei foarte mult, el re-impune faptul că tragerea ei un plan de execuție rău.
Am avut aceeași problemă și iată ce am aflat.
mărimea jurnalului de bază de date a fost păstrată la valoarea implicită (814 MB), iar creșterea automată a fost de 10%. Pe server, memoria maximă a serverului a fost menținută la setarea implicită (2147483647 MB).
Când jurnalul nostru sa umplut și a trebuit să crească, a folosit toată memoria de la server și nu mai rămâne nimic pentru ca codul să fie rulat, așa că a expirat. Ceea ce am făcut a fost să setăm mărimea inițială a fișierului de bază de date la 1 MB și memoria maximă a serverului la 2048 MB. Aceasta ne-a rezolvat imediat problema. Desigur, aveți posibilitatea să schimbați aceste două proprietăți pentru a se potrivi cu nevoile dvs. dar aceasta este o idee pentru cineva care se execută în problema de sosire atunci când execută o procedură stocată prin cod, dar rulează foarte repede în SSMS și soluțiile de mai sus nu ajută.