Dit is wat ik tot nu toe heb geleerd van mijn onderzoek.
.NET verzendt verbindingsinstellingen die niet hetzelfde zijn als wat je krijgt als je inlogt bij management studio. Dit is wat je ziet als je de verbinding met Sql Profiler snuift:
-- 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
Ik plak die instellingen nu boven elke query die ik uitvoer wanneer ik ben ingelogd op de sql-server, om er zeker van te zijn dat de instellingen hetzelfde zijn.
In dit geval heb ik elke instelling afzonderlijk geprobeerd, na het loskoppelen en opnieuw verbinden, en ontdekte dat het wijzigen van arithabort van uit naar aan de probleemquery verminderde van 90 seconden naar 1 seconde.
De meest waarschijnlijke verklaring heeft te maken met het snuiven van parameters, een techniek die Sql Server gebruikt om te kiezen wat volgens haar het meest effectieve queryplan is. Wanneer u een van de verbindingsinstellingen wijzigt, kan de query-optimizer een ander plan kiezen, en in dit geval blijkbaar een slecht plan.
Maar ik ben hier niet helemaal van overtuigd. Ik heb geprobeerd de daadwerkelijke queryplannen te vergelijken na het wijzigen van deze instelling en ik heb nog geen wijzigingen kunnen zien in de diff.
Is er iets anders aan de arithabort-instelling waardoor een zoekopdracht in sommige gevallen traag kan verlopen?
De oplossing leek eenvoudig:zet gewoon set arithabort bovenaan de opgeslagen procedure. Maar dit zou tot het tegenovergestelde probleem kunnen leiden:verander de queryparameters en plotseling werkt het sneller met 'uit' dan 'aan'.
Voorlopig voer ik de procedure 'met opnieuw compileren' uit om ervoor te zorgen dat het plan elke keer opnieuw wordt gegenereerd. Het is oké voor dit specifieke rapport, aangezien het misschien een seconde duurt om het opnieuw te compileren, en dit is niet zo merkbaar in een rapport dat 1-10 seconden nodig heeft om terug te keren (het is een monster).
Maar het is geen optie voor andere zoekopdrachten die veel vaker worden uitgevoerd en zo snel mogelijk moeten worden geretourneerd, in slechts een paar milliseconden.