sql >> Database teknologi >  >> RDS >> Sqlserver

Forespørgsel timeout fra webapp, men kører fint fra management studio

Dette er, hvad jeg indtil videre har lært af min forskning.

.NET indsender forbindelsesindstillinger, der ikke er de samme, som du får, når du logger ind på ledelsesstudiet. Her er hvad du ser, hvis du sniffer forbindelsen med SQL Profiler:

-- 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  

Jeg indsætter nu disse indstillinger over hver forespørgsel, som jeg kører, når jeg er logget ind på sql-serveren, for at sikre, at indstillingerne er de samme.

I dette tilfælde prøvede jeg hver indstilling individuelt, efter at have afbrudt og oprettet forbindelse igen, og fandt ud af, at ændring af arithabort fra off til on reducerede problemforespørgslen fra 90 sekunder til 1 sekund.

Den mest sandsynlige forklaring er relateret til parametersniffing, som er en teknik Sql Server bruger til at vælge, hvad den mener er den mest effektive forespørgselsplan. Når du ændrer en af ​​forbindelsesindstillingerne, kan forespørgselsoptimeringsværktøjet vælge en anden plan, og i dette tilfælde valgte den tilsyneladende en dårlig.

Men jeg er ikke helt overbevist om dette. Jeg har prøvet at sammenligne de faktiske forespørgselsplaner efter at have ændret denne indstilling, og jeg har endnu ikke set forskellen vise nogen ændringer.

Er der noget andet ved arithabort-indstillingen, der kan få en forespørgsel til at køre langsomt i nogle tilfælde?

Løsningen virkede enkel:Sæt bare set arithabort på i toppen af ​​den lagrede procedure. Men dette kan føre til det modsatte problem:ændre forespørgselsparametrene, og pludselig kører den hurtigere med 'off' end 'on'.

For øjeblikket kører jeg proceduren 'med omkompiler' for at sikre, at planen bliver regenereret hver gang. Det er ok for netop denne rapport, da det måske tager et sekund at kompilere, og det er ikke så mærkbart på en rapport, der tager 1-10 sekunder at vende tilbage (det er et monster).

Men det er ikke en mulighed for andre forespørgsler, der kører meget hyppigere og skal vende tilbage så hurtigt som muligt på blot et par millisekunder.



  1. SQL Server Database Snapshots -4

  2. Postgresql - backup af database og gendannelse på anden ejer?

  3. Forespørg to tabeller fra forskellige skemaer

  4. Kan ikke oprette enhedsdatamodel - ved hjælp af MySql og EF6