La query è lenta per alcuni utenti


11

Ho un paio di query chiamate da un'applicazione Web C # .NET che sono sempre veloci per me (sono un amministratore locale su SQL Server) ma per un gruppo di utenti (gruppo di dominio con le autorizzazioni richieste), la query è incredibilmente lenta per il punto in timeout nell'applicazione.

Cosa farebbe in modo che la stessa identica query funzionasse diversamente per utenti diversi?

Ulteriori informazioni:

  • La query è inline SQL nel codice C #, non una procedura memorizzata
  • L'app utilizza l'autenticazione del dominio e sia io che l'utente eseguiamo la query tramite l'app
  • Sembra che il problema riguardi piani diversi e uno sia stato memorizzato nella cache, ecco perché era diverso per utenti diversi. Qualcosa sta influenzando la cache perché ora la query è lenta per me tramite l'app e veloce in SQL Server Management Studio.

2
Controlla le seguenti domande . Potresti scoprire di essere nella stessa situazione. Diciamo prima di provare questo e quest'altro .
Marian,

3
Quali sono i tipi di attesa (sys.dm_os_waiting_tasks) nelle query lente, e anche quali sono i piani di esecuzione effettivi di ciascuno (il tuo veloce, il loro lento)?
Thomas Stringer

2
Concordo con i commenti precedenti. Il mio primo pensiero sarebbe anche il fiuto dei parametri. Controllare per vedere se i piani sono diversi dovrebbe essere il primo passo.
Martin Smith,

4
Se i parametri sono gli stessi (suppongo sia quello che significa exact same query), non dovrebbe essere lo sniffing dei parametri (gli utenti ottengono un piano errato per i parametri sbagliati), ma piuttosto gli utenti ottengono piani diversi per lo stesso parametro (S). Potrebbe essere a causa di impostazioni come quoted_identifiere arithabort, che puoi confrontare sys.dm_exec_sessionsper l'utente veloce e l'utente lento, oppure potrebbe essere perché hanno schemi predefiniti diversi e gli oggetti a cui viene fatto riferimento senza il prefisso dello schema. Lo sniffing dei parametri può essere ancora coinvolto (quindi perché uno di loro ha un piano negativo).
Aaron Bertrand

1
RE: La tua modifica hai lo stesso schema predefinito degli altri utenti? Hai già acquisito i piani di esecuzione per corse lente e veloci?
Martin Smith,

Risposte:


5

Se i parametri sono gli stessi (suppongo sia quello che significa exact same query), non dovrebbe essere lo sniffing dei parametri (gli utenti ottengono un piano errato per i parametri sbagliati), ma piuttosto gli utenti ottengono piani diversi per lo stesso parametro (S). Potrebbe essere a causa di impostazioni come quoted_identifiere arithabort, che puoi confrontare sys.dm_exec_sessionsper l'utente veloce e l'utente lento, oppure potrebbe essere perché hanno schemi predefiniti diversi e gli oggetti a cui viene fatto riferimento senza il prefisso dello schema. Lo sniffing dei parametri può essere ancora coinvolto (quindi perché uno di loro ha un piano negativo).


3

ho visto due motivi per questo: 1, parametro sniffing 2, le impostazioni di connessione sono diverse. Se esegui whoisactive , ti mostreranno le diverse proprietà di connessione. In realtà ho un post sul blog su questo, ma non ho ripulito le informazioni specifiche dell'azienda da esso. (né ho ancora abilitato il mio blog);)


0

Prova: specifica lo schema su ogni EXEC e riferimento alla tabella. Ad esempio, EXEC dbo.MyProc

Potrebbero esserci conflitti (come suggerisce Martin Smith - "stesso schema predefinito"?) O ricompilazioni


0

Questo sembra essere un bug in SQL Server. Ho riscontrato questo errore con SQL Server 2008. Non ho testato nuove versioni. Posso accedere come amministratore ed eseguire questa query e ottenere una risposta in 0 secondi:

select ROUTINE_NAME from INFORMATION_SCHEMA.ROUTINES ORDER BY ROUTINE_NAME

Quindi eseguo l'accesso come utente con meno autorizzazioni, eseguo esattamente la stessa query e la risposta richiede 45 secondi.

Questo è coerente ancora e ancora. Se rimbalzo avanti e indietro tra le mie due finestre di query, una per l'amministratore e una per il non amministratore, il non amministratore impiega sempre circa 45 secondi e l'amministratore impiega 0 secondi.


Come richiesto nei commenti alla domanda: entrambi gli utenti hanno lo stesso database predefinito e le query vengono eseguite nello stesso database? E puoi indicare una sorta di documentazione che afferma che si tratta di un bug o è la tua opinione? Non dire che ti sbagli, solo cercando qualcosa oltre un aneddoto.
RDFozz,

Il problema che hai identificato nella tua risposta sembra non essere ripetibile su SQL Server 2008. select ROUTINE_NAME from INFORMATION_SCHEMA.ROUTINES ORDER BY ROUTINE_NAMERestituisce costantemente i dati immediatamente per un accesso non SA che non ha alcun diritto esplicito.
Max Vernon,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.