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.