SQL Server lyssnar ju som bekant by default på port 1433 om man installerar en…
Ett företag inom forskningsbranschen får problem med en fråga som tog > 5 minuter att köra och kontaktar oss för att kunna få en analys om var problemet ligger. Vi konstaterade relativt snabbt att det var i SQL Server som felet låg – frågan fick olika exekveringsplaner ,beroende på antal rader (som förväntades) i resultatet. När frågan gav 40 rader tillbaka tog den 1 sekund, När frågan gav mer än 40 rader tillbaka tog den mer än 5 minuter. Det tog lite längre tid att utröna själva orsaken.
Genom att använda den exekveringsplan som tog 1 sekund på en variant av frågan som gav mer än 40 rader tillbaka, kunde vi fastställa att exekveringsplanen var del av orsaken då den då tog endast 1 sekund för mer än 40 rader med samma exekveringsplan, som för frågan som gav 40 rader tillbaka. Några försök med “Create statistics” (utan att ha med exekveringsplantipset) flyttade gränsen en bit, till 60 rader, men det var inte tillräckligt. Olika index tillägg och -borttagande förvärrade eller gav status quo. Nästa steg blev att skriva om frågan. Det var inte företaget själv som hade källkoden och ingick inte i vårat uppdrag (den gången), så det lämnades över till vederbörande. Frågan var dock hyfsat komplicerad med många subselects och joins samt att den var dynamiskt skapad av en stored procedure, och det blir inte helt enkelt att skriva om den, men nödvändigt i det här fallet.
Det är skönt att finna orsakens riktning först och främst, så att man snabbt kan ta tag i det roliga: att skriva om sin T-SQL. Några länkar som kan hjälpa till: Plan Caching in 2008 Execution Plan Caching and Reuse (2005)