Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Processi bloccanti
64 views
Skip to first unread message
Patrick
Oct 5, 2011, 6:34:13 AM10/5/11
to
Salve, dove lavoro gli utenti hanno una miriade di strumenti per
accedere ai dati (oltre al gestionale), soprattutto query Access (con
tabelle collegate a SQL Server) e Pivot Excel, oltre a tanti
programmini che assolvono a singoli compiti.
Sempre più spesso accade che troppe elaborazioni bloccano il server e
vengo subissato dalle richieste d'aiuto.
Fini ad oggi ho individuato il "colpevole" con un metodo tecnico-
empirico. Tecnico perchè lancio una query di mia fattura:
SELECT spid, loginame, hostname, program_name, cmd,DB_NAME(dbid) as
[DATABASE], status, last_batch, login_time, open_tran
from master.dbo.sysprocesses
WHERE status in ('suspended', 'runnable') and spid <>@@SPID
Empirico perchè cerco da capire dai risultati chi blocca (in genere è
ch ha il last_batch più lontano nel tempo, chi ha molte "istanze"
dello stesso SPID, chi ha lo status "runnable").
Vorrei sapere se esiste una query (o qualche altra cosa) che in modo
ineviquocabile individua lo SPID che sta creando problemi, così che
possa fornire uno strumento diretto agli utenti e si sincronizzino
meglio quando devono lanciare elaborazioni "pesanti".
Si può fare?
accedere ai dati (oltre al gestionale), soprattutto query Access (con
tabelle collegate a SQL Server) e Pivot Excel, oltre a tanti
programmini che assolvono a singoli compiti.
Sempre più spesso accade che troppe elaborazioni bloccano il server e
vengo subissato dalle richieste d'aiuto.
Fini ad oggi ho individuato il "colpevole" con un metodo tecnico-
empirico. Tecnico perchè lancio una query di mia fattura:
SELECT spid, loginame, hostname, program_name, cmd,DB_NAME(dbid) as
[DATABASE], status, last_batch, login_time, open_tran
from master.dbo.sysprocesses
WHERE status in ('suspended', 'runnable') and spid <>@@SPID
Empirico perchè cerco da capire dai risultati chi blocca (in genere è
ch ha il last_batch più lontano nel tempo, chi ha molte "istanze"
dello stesso SPID, chi ha lo status "runnable").
Vorrei sapere se esiste una query (o qualche altra cosa) che in modo
ineviquocabile individua lo SPID che sta creando problemi, così che
possa fornire uno strumento diretto agli utenti e si sincronizzino
meglio quando devono lanciare elaborazioni "pesanti".
Si può fare?
Albe V°
Oct 5, 2011, 6:47:12 AM10/5/11
to
Patrick ha detto questo mercoledì :
Non so aiutarti sullo specifico quesito.
Devo dire che anche noi, quando veniamo interpellati da clienti che
lamentano problemi di performance, partiamo da sp_who2 (che è poi la
stessa cosa che lanci tu, grossomodo), e poi se serve attiviamo un
profiler sui task che individuiamo come sospetti.
Posso però darti un suggerimento su come intervenire 'a monte': noi non
forniamo MAI ai clienti (tu vedili come i tool esterni che accedono ai
dati) l'accesso diretto alle tabelle.
E' chiaro che il cliente ha la password di sa e quindi può vedere
tutto, ma se ci chiede "mi date la query per estrarre quei dati
che...", noi realizziamo una stored procedure che, invocata passando i
parametri necessari, restituisce i dati richiesti.
Questo comporta che le query le scriviamo noi, usando i join, gli
indici, le strategie, che sappiamo funzionare meglio per quella
specifica estrazione.
E, parallelamente, se vediamo che una determinata estrazione va a
lavorare sulle tabelle in modo 'sfortunato', e questa estrazione sia
una cosa che accade con determinata frequenza, valutiamo se esiste un
indice che possa aiutare, che impatto abbia sulle scritture e sui lock,
ed eventualmente lo creiamo.
Ciao
Alberto
Patrick
Oct 5, 2011, 6:55:31 AM10/5/11
to
On 5 Ott, 12:47, Albe V° <vac-cariTOGL...@hotmail.com> wrote:
> Patrick ha detto questo mercoled :
> > ch ha il last_batch pi lontano nel tempo, chi ha molte "istanze"
corretto sulla carta. Ma quando intervieni in una situazione già
"incancrenita" e hai a disposizione minuti e non mesi, l'unica cosa da
fare, per quanto "toppa", è per il momento dare uno strumento agli
utenti per auto regolarsi, altrimenti passo la giornata al telefono a
chiedere a Tizio e a Caio di bloccare la loro elaborazione.
> Patrick ha detto questo mercoled :
>
>
>
>
>
>
>
>
>
> > Salve, dove lavoro gli utenti hanno una miriade di strumenti per
> > accedere ai dati (oltre al gestionale), soprattutto query Access (con
> > tabelle collegate a SQL Server) e Pivot Excel, oltre a tanti
> > programmini che assolvono a singoli compiti.
>
> > Sempre pi spesso accade che troppe elaborazioni bloccano il server e
>
>
>
>
>
>
>
>
> > Salve, dove lavoro gli utenti hanno una miriade di strumenti per
> > accedere ai dati (oltre al gestionale), soprattutto query Access (con
> > tabelle collegate a SQL Server) e Pivot Excel, oltre a tanti
> > programmini che assolvono a singoli compiti.
>
> > vengo subissato dalle richieste d'aiuto.
> > Fini ad oggi ho individuato il "colpevole" con un metodo tecnico-
> > empirico. Tecnico perch lancio una query di mia fattura:
> > Fini ad oggi ho individuato il "colpevole" con un metodo tecnico-
>
> > SELECT spid, loginame, hostname, program_name, cmd,DB_NAME(dbid) as
> > [DATABASE], status, last_batch, login_time, open_tran
> > from master.dbo.sysprocesses
> > WHERE status in ('suspended', 'runnable') and spid <>@@SPID
>
> > Empirico perch cerco da capire dai risultati chi blocca (in genere
> > SELECT spid, loginame, hostname, program_name, cmd,DB_NAME(dbid) as
> > [DATABASE], status, last_batch, login_time, open_tran
> > from master.dbo.sysprocesses
> > WHERE status in ('suspended', 'runnable') and spid <>@@SPID
>
> > ch ha il last_batch pi lontano nel tempo, chi ha molte "istanze"
> > dello stesso SPID, chi ha lo status "runnable").
>
> > Vorrei sapere se esiste una query (o qualche altra cosa) che in modo
> > ineviquocabile individua lo SPID che sta creando problemi, cos che
>
> > Vorrei sapere se esiste una query (o qualche altra cosa) che in modo
> > possa fornire uno strumento diretto agli utenti e si sincronizzino
> > meglio quando devono lanciare elaborazioni "pesanti".
>
> > Si pu fare?
> > meglio quando devono lanciare elaborazioni "pesanti".
>
>
> Non so aiutarti sullo specifico quesito.
> Devo dire che anche noi, quando veniamo interpellati da clienti che
> lamentano problemi di performance, partiamo da sp_who2 (che poi la
> Non so aiutarti sullo specifico quesito.
> Devo dire che anche noi, quando veniamo interpellati da clienti che
> stessa cosa che lanci tu, grossomodo), e poi se serve attiviamo un
> profiler sui task che individuiamo come sospetti.
>
> Posso per darti un suggerimento su come intervenire 'a monte': noi non
> profiler sui task che individuiamo come sospetti.
>
> forniamo MAI ai clienti (tu vedili come i tool esterni che accedono ai
> dati) l'accesso diretto alle tabelle.
> E' chiaro che il cliente ha la password di sa e quindi pu vedere
> dati) l'accesso diretto alle tabelle.
> tutto, ma se ci chiede "mi date la query per estrarre quei dati
> che...", noi realizziamo una stored procedure che, invocata passando i
> parametri necessari, restituisce i dati richiesti.
> Questo comporta che le query le scriviamo noi, usando i join, gli
> indici, le strategie, che sappiamo funzionare meglio per quella
> specifica estrazione.
> E, parallelamente, se vediamo che una determinata estrazione va a
> lavorare sulle tabelle in modo 'sfortunato', e questa estrazione sia
> una cosa che accade con determinata frequenza, valutiamo se esiste un
> indice che possa aiutare, che impatto abbia sulle scritture e sui lock,
> ed eventualmente lo creiamo.
>
> Ciao
>
> Alberto
Grazie della risposta "politicamente corretta", tutto giusto, tutto
> che...", noi realizziamo una stored procedure che, invocata passando i
> parametri necessari, restituisce i dati richiesti.
> Questo comporta che le query le scriviamo noi, usando i join, gli
> indici, le strategie, che sappiamo funzionare meglio per quella
> specifica estrazione.
> E, parallelamente, se vediamo che una determinata estrazione va a
> lavorare sulle tabelle in modo 'sfortunato', e questa estrazione sia
> una cosa che accade con determinata frequenza, valutiamo se esiste un
> indice che possa aiutare, che impatto abbia sulle scritture e sui lock,
> ed eventualmente lo creiamo.
>
> Ciao
>
> Alberto
corretto sulla carta. Ma quando intervieni in una situazione già
"incancrenita" e hai a disposizione minuti e non mesi, l'unica cosa da
fare, per quanto "toppa", è per il momento dare uno strumento agli
utenti per auto regolarsi, altrimenti passo la giornata al telefono a
chiedere a Tizio e a Caio di bloccare la loro elaborazione.
Albe V°
Oct 5, 2011, 7:03:14 AM10/5/11
to
Patrick ha spiegato il 05/10/2011 :
Diciamo che però ogni tanto tu individuerai il 'colpevole' di un
problema.
A questo punto, dopo averlo sbloccato, potresti andare a studiare il
perchè del problema.
Sai quante estrazioni passano da minuti a frazioni di secondo,
semplicemente mettendo loro a disposizione l'indice giusto?
Ecco, per quante possano essere le attività client sul database, sono
abbastanza convinto, per esperienza, che quelle veramente pesanti e
bloccanti siano alla fin fine sempre le solite.
Diciamo dieci tipologie, ma realisticamente potrebbero essere meno.
Se ne efficienti una, hai ridotto del 10% il problema.
Poi fra una settimana trovi la mezz'oretta per efficientarne un'altra.
Guarda, abbiamo un server presso un cliente che era letteralmente
sdraiato.
C'erano procedure che quando partivano succhiavano cpu per uno o due
minuti. Tutta roba scritta millemila anni fa, su versioni precedenti di
sql-server e poi migrate assieme al database, ma senza ristudiarle.
Con due giorni di lavoro cattivo mio e di un mio collega, adesso la
procedura più pesante lavora per 4-5 secondi al massimo.
Le stesse procedure, che fanno le stesse cose, estraggono gli stessi
dati, eseguono gli stessi inserimenti/aggiornamenti.
Però succhiano il 90% di cpu in meno.
Questo ha completamente azzerato, ma completamente, le lamentele di
performance, i deadlock, i conflitti, ecc...
Poi, capisco la tua non facile posizione.
Così, l'ho buttata lì...
Ciao
Alberto
> Grazie della risposta "politicamente corretta", tutto giusto, tutto
> corretto sulla carta. Ma quando intervieni in una situazione già
> "incancrenita" e hai a disposizione minuti e non mesi, l'unica cosa da
> fare, per quanto "toppa", è per il momento dare uno strumento agli
> utenti per auto regolarsi, altrimenti passo la giornata al telefono a
> chiedere a Tizio e a Caio di bloccare la loro elaborazione.
Certo, capisco la situazione.
> corretto sulla carta. Ma quando intervieni in una situazione già
> "incancrenita" e hai a disposizione minuti e non mesi, l'unica cosa da
> fare, per quanto "toppa", è per il momento dare uno strumento agli
> utenti per auto regolarsi, altrimenti passo la giornata al telefono a
> chiedere a Tizio e a Caio di bloccare la loro elaborazione.
Diciamo che però ogni tanto tu individuerai il 'colpevole' di un
problema.
A questo punto, dopo averlo sbloccato, potresti andare a studiare il
perchè del problema.
Sai quante estrazioni passano da minuti a frazioni di secondo,
semplicemente mettendo loro a disposizione l'indice giusto?
Ecco, per quante possano essere le attività client sul database, sono
abbastanza convinto, per esperienza, che quelle veramente pesanti e
bloccanti siano alla fin fine sempre le solite.
Diciamo dieci tipologie, ma realisticamente potrebbero essere meno.
Se ne efficienti una, hai ridotto del 10% il problema.
Poi fra una settimana trovi la mezz'oretta per efficientarne un'altra.
Guarda, abbiamo un server presso un cliente che era letteralmente
sdraiato.
C'erano procedure che quando partivano succhiavano cpu per uno o due
minuti. Tutta roba scritta millemila anni fa, su versioni precedenti di
sql-server e poi migrate assieme al database, ma senza ristudiarle.
Con due giorni di lavoro cattivo mio e di un mio collega, adesso la
procedura più pesante lavora per 4-5 secondi al massimo.
Le stesse procedure, che fanno le stesse cose, estraggono gli stessi
dati, eseguono gli stessi inserimenti/aggiornamenti.
Però succhiano il 90% di cpu in meno.
Questo ha completamente azzerato, ma completamente, le lamentele di
performance, i deadlock, i conflitti, ecc...
Poi, capisco la tua non facile posizione.
Così, l'ho buttata lì...
Ciao
Alberto
Patrick
Oct 5, 2011, 8:16:45 AM10/5/11
to
On 5 Ott, 13:03, Albe V° <vac-cariTOGL...@hotmail.com> wrote:
> Patrick ha spiegato il 05/10/2011 :
>
> > Grazie della risposta "politicamente corretta", tutto giusto, tutto
> > corretto sulla carta. Ma quando intervieni in una situazione gi
> Patrick ha spiegato il 05/10/2011 :
>
> > Grazie della risposta "politicamente corretta", tutto giusto, tutto
> > corretto sulla carta. Ma quando intervieni in una situazione gi
> > "incancrenita" e hai a disposizione minuti e non mesi, l'unica cosa da
> > fare, per quanto "toppa", per il momento dare uno strumento agli
> > utenti per auto regolarsi, altrimenti passo la giornata al telefono a
> > chiedere a Tizio e a Caio di bloccare la loro elaborazione.
>
> Certo, capisco la situazione.
>
> Diciamo che per ogni tanto tu individuerai il 'colpevole' di un
> > chiedere a Tizio e a Caio di bloccare la loro elaborazione.
>
> Certo, capisco la situazione.
>
> problema.
> A questo punto, dopo averlo sbloccato, potresti andare a studiare il
> perch del problema.
> A questo punto, dopo averlo sbloccato, potresti andare a studiare il
> Sai quante estrazioni passano da minuti a frazioni di secondo,
> semplicemente mettendo loro a disposizione l'indice giusto?
>
> Ecco, per quante possano essere le attivit client sul database, sono
> semplicemente mettendo loro a disposizione l'indice giusto?
>
> abbastanza convinto, per esperienza, che quelle veramente pesanti e
> bloccanti siano alla fin fine sempre le solite.
> Diciamo dieci tipologie, ma realisticamente potrebbero essere meno.
> Se ne efficienti una, hai ridotto del 10% il problema.
> Poi fra una settimana trovi la mezz'oretta per efficientarne un'altra.
>
> Guarda, abbiamo un server presso un cliente che era letteralmente
> sdraiato.
> C'erano procedure che quando partivano succhiavano cpu per uno o due
> minuti. Tutta roba scritta millemila anni fa, su versioni precedenti di
> sql-server e poi migrate assieme al database, ma senza ristudiarle.
> Con due giorni di lavoro cattivo mio e di un mio collega, adesso la
> procedura pi pesante lavora per 4-5 secondi al massimo.
> bloccanti siano alla fin fine sempre le solite.
> Diciamo dieci tipologie, ma realisticamente potrebbero essere meno.
> Se ne efficienti una, hai ridotto del 10% il problema.
> Poi fra una settimana trovi la mezz'oretta per efficientarne un'altra.
>
> Guarda, abbiamo un server presso un cliente che era letteralmente
> sdraiato.
> C'erano procedure che quando partivano succhiavano cpu per uno o due
> minuti. Tutta roba scritta millemila anni fa, su versioni precedenti di
> sql-server e poi migrate assieme al database, ma senza ristudiarle.
> Con due giorni di lavoro cattivo mio e di un mio collega, adesso la
> Le stesse procedure, che fanno le stesse cose, estraggono gli stessi
> dati, eseguono gli stessi inserimenti/aggiornamenti.
> Per succhiano il 90% di cpu in meno.
> dati, eseguono gli stessi inserimenti/aggiornamenti.
>
> Questo ha completamente azzerato, ma completamente, le lamentele di
> performance, i deadlock, i conflitti, ecc...
>
> Poi, capisco la tua non facile posizione.
>
> Cos , l'ho buttata l ...
> Questo ha completamente azzerato, ma completamente, le lamentele di
> performance, i deadlock, i conflitti, ecc...
>
> Poi, capisco la tua non facile posizione.
>
>
> Ciao
>
> Alberto
Si ripeto hai ragione, ma tanto per darti qualche ordine di grandezza
in quest'ufficio girano qualcosa come 3600 query, 890 Pivot, 61
programmi e programmini vari, più una serie di processi
"sonnolenti" (trigger, web service, ecc.) che aggiornano i dati
ridondanti per rendere le ricerche più veloci.
Spesso il problema non è "una" elaborazione, ma "quella" elaborazione
quando va in concorrenza con "quell'altra" e "quell'altra ancora".
Semplicemente lanciandole in sequenza ognuno avrebbe i suoi dati senza
darsi fastidio a vicenda.
Per non saper nè leggere nè scrivere dovrei ottimizzare tutte le query
esistenti, utilizzare un server replicato per le elaborazioni pesanti
(analizzando se la cura non sia peggiore della malattia, in termini
prestazionali), "uccidere" tutte quelle attività, settore per settore,
inutili o ridondanti. Insomma un pò troppo per le mie deboli forze e
il tempo di cui dispongo, considerato che la contabilità deve
fatturare ADESSO, il data entry deve importare ADESSO, il customer
service deve inviare i documenti statistici ADESSO ecc. ecc..
Certo mi sembra strano che un sistema così ben congegnato come SQL
Server non abbia delle strutture che, interrogate, estrapolano i
processi che intasano il server.
David Martin
Oct 5, 2011, 11:06:17 AM10/5/11
to
Patrick wrote:
> Vorrei sapere se esiste una query (o qualche altra cosa) che in modo
> ineviquocabile individua lo SPID che sta creando problemi, così che
> possa fornire uno strumento diretto agli utenti e si sincronizzino
> meglio quando devono lanciare elaborazioni "pesanti".
Prova a dare uno sguardo a questo pdf:
> Vorrei sapere se esiste una query (o qualche altra cosa) che in modo
> ineviquocabile individua lo SPID che sta creando problemi, così che
> possa fornire uno strumento diretto agli utenti e si sincronizzino
> meglio quando devono lanciare elaborazioni "pesanti".
http://www.bradmcgehee.com/2010/07/free-sql-server-dmv-starter-pack/
Fra i contenuti sono indicate istruzioni che potrebbero aiutarti:
DMV#3: Current expensive, or blocked, requests
DMV#4: Query Stats – Find the "top X" most expensive cached queries
--
David Martin
0 new messages