Forespørgslen er en enkelt markering, der indeholder mange grupperingsniveauer og aggragate-operationer. Med SET ARITHABORT ON tager det mindre end et sekund, ellers tager det flere minutter. Vi har set denne adfærd på SQL Server 2000 og 2008.
Svar
Lidt dateret, men for enhver der ender her med et lignende problem …
Jeg havde det samme problem. For mig viste det sig at være parameter sniffing, som jeg først ikke forstod nok til at bekymre mig om. Jeg tilføjede en “sæt arithabort på”, som løste problemet, men så kom det tilbage. Så læste jeg:
http://www.sommarskog.se/query-plan-mysteries.html
Det blev ryddet – alting op. Fordi jeg brugte Linq til SQL og havde begrænsede muligheder for at løse problemet, jeg endte med at bruge en forespørgselsguide (se slutningen af linket) for at tvinge den forespørgselsplan, jeg ønskede.
Kommentarer
- Mere end seks år senere er linket i dette svar stadig ” krævet læsning ” … og stadig også aktuelt, den seneste revision er december ‘ 17.
Svar
.NET-applikationer forbinder med indstillingen deaktiveret som standard, men den er som standard aktiveret i Management Studio. Resultatet er, at serveren faktisk cachelagrer 2 separate udførelsesplaner for de fleste / alle procedurer. Dette påvirker, hvordan serveren udfører numeriske beregninger, og som sådan kan du få meget forskellige resultater afhængigt af proceduren. Dette er virkelig kun en af 2 almindelige måder, en proc kan få fodret på en forfærdelig udførelsesplan, hvor den anden er parameter sniffing.
Se på https://web.archive.org/web/20150315031719/http://sqladvice.com/blogs/gstark/archive/2008/02/12/Arithabort-Option-Effects-Stored-Procedure-Performance.aspx for lidt mere diskussion om det.
Kommentarer
Svar
Jeg vil hævde, at dette næsten helt sikkert var parameter sniffing.
Det anføres ofte, at SET OPTIONS kan påvirke ydeevnen på denne måde, men jeg har endnu ikke set en eneste autoritativ kilde til denne påstand bortset fra det tilfælde, hvor du er ved hjælp af indekserede visninger / vedvarende beregnede kolonner.
I dette tilfælde (for SQL2005 + og , medmindre din database er i SQL2000-kompatibilitetstilstand ). Hvis du har både ARITHABORT og ANSI_WARNINGS OFF, finder du indekset ikke bruges så kan have en scanning i stedet for den ønskede søgning (og noget overhead, da det vedvarende beregningsresultat ikke kan bruges). ADO.NET synes at være standard for at have ANSI_WARNINGS ON fra en hurtig test, jeg lige har gjort.
Påstanden i Bens svar at “den måde, serveren udfører numeriske beregninger på”, kan tilføje minutter til et resultat, der ellers ville tage mindre end et sekund, bare ikke synes at være troværdigt for mig. Jeg tror, at det, der har tendens til at ske, er, at Profiler bruges til at identificere den fornærmende forespørgsel efter at have undersøgt et performance performance problem. Dette indsættes i ledelsesstudiet og køres og returnerer resultater med det samme. Den eneste tilsyneladende forskel mellem forbindelser er indstillingen ARITH_ABORT.
En hurtig test i et managementstudiovindue viser, at når SET ARITHABORT OFF er slået til, og forespørgslen køres, at ydeevneproblemet gentages, så det tilsyneladende er lukket. Dette synes faktisk at være den fejlfindingsmetode, der er brugt i Gregg Stark -linket.
Men det ignorerer det faktum, at du med dette indstillingssæt kan ender med at få nøjagtig den samme dårlige plan fra cachen .
Denne plangenbrug kan ske, selvom du er logget ind som en anden bruger, end applikationsforbindelsen bruger.
Jeg testede dette ved først at udføre en testforespørgsel fra en webapplikation og derefter fra managementstudio med SET ARITHABORT OFF og kunne se brugen af konti gå op fra nedenstående forespørgsel.
SELECT usecounts, cacheobjtype, objtype, text ,query_plan FROM sys.dm_exec_cached_plans CROSS APPLY sys.dm_exec_sql_text(plan_handle) CROSS APPLY sys.dm_exec_query_plan(plan_handle) For at denne deling kan pf-planer rent faktisk forekomme, skal alle plan-cache-nøgler være de samme. Samt arithabort i sig selv er nogle andre eksempler, at de udførende brugere har brug for det samme standardskema (hvis forespørgslen er afhængig af implicit navneløsning) og forbindelserne har brug for det samme language sæt.
Svar
Jeg ved, at jeg kommer for sent til denne fest, men for fremtidige besøgende er Martin nøjagtigt korrekt. Vi løb ind i det samme problem – en SP kørte meget langsomt for .NET-klienter, mens det flammede hurtigt for SSMS. Når vi udforskede og løste problemet, foretog vi den systematiske test, som Kenny Evitt spørger om i sin kommentar til Martins spørgsmål.
Brug af en variant af Martins forespørgsel, jeg ledte efter SP i procedurens cache og fandt to af dem. Ser man på planerne, var det faktisk sådan, at man havde ARITHABORT ON og en havde ARITHABORT OFF. ARITHABORT OFF-versionen havde en indekssøgning mens ARITHABORT ON-versionen brugte en indeksskanning til det samme output. I betragtning af de involverede parametre ville indekssøgningen have krævet et opslag på titusindvis af poster for output.
Jeg ryddede de to procedurer fra cachen og havde .NET-klienten kørt SP igen ved hjælp af de samme parametre (som indeholdt et bredt datointerval for en kunde med masser af aktivitet). SP vendte straks tilbage. Den cachelagrede plan brugte den samme indeksskanning, som tidligere var omtalt i ARITHABORT ON-planen – men denne gang var planen for ARITHABORT OFF. Vi kørte SP med de samme parametre i SSMS, og fik igen resultater med det samme. Nu så vi, at en anden plan blev cachelagret for ARITHABORT ON med indeksskanningen.
Vi ryddede derefter cachen, kørte SP i SSMS med et snævert datointerval og fik et øjeblikkeligt resultat. Vi fandt ud af, at den resulterende cachelagrede plan havde en indekssøgning, for den samme output blev tidligere håndteret med en scanning (som også var et søgning i den oprindelige plan med ARITHABORT OFF). Igen fra SSMS kørte vi SP, denne gang med samme brede datointerval, og så den samme forfærdelige ydeevne, som vi havde i den originale .NET-anmodning.
Kort sagt havde forskellen intet at gøre med den faktiske værdi af ARITHABORT – med den til eller fra, fra begge klienter, kunne vi få acceptabel eller forfærdelig ydeevne: Alt, der betyder noget, var parameterværdierne, der blev brugt til at kompilere og cache planen. id = “540ca15827”>
MSDN indikerer, at selve ARITHABORT OFF kan have en negativ indvirkning på optimering af forespørgsler, vores test bekræfter, at Martin er korrekt – årsagen var parameter sniffing og den resulterende plan var ikke optimal til alle parametre.
Kommentarer
- Spekulerer på, hvad denne sætning
Setting ARITHABORT to OFF can negatively impact query optimization leading to performance issues.betyder. Uanset om de bare taler om manglende evne til at bruge indekser på beregnede kolonner og visninger (hvisANSI_WARNINGSogså er slået fra), eller om det faktisk har en anden effekt. - Jeg ‘ er ikke sikker. Jeg spekulerer på, om det ‘ simpelthen er tilfældet, at nogen på MSDN løb ind i en lignende situation, satte ARTIHABORT til ON, så forbedringen af præstationen og sprang til de samme konklusioner, som andre har. For så vidt angår indekserede visninger og beregnede kolonner, er jeg ‘ uklar. På et tidspunkt står det, at SET-indstillingerne skal have specifikke værdier, hvis en INSERT-, UPDATE- eller DELETE-handling ændrer dataværdier, der er gemt deri. Andetsteds siger de, at optimeringsprogrammet ignorerer indekser for ” enhver forespørgsel “, der henviser til den indekserede visning eller den beregnede kolonne. Er begge sande, eller er det virkelig ” nogen forespørgsel, der ændrer data “?
Svar
Har lige haft dette problem. Som folk sagde her, er grundårsagen flere forespørgselsplaner, hvoraf den ene er suboptimal. Jeg ville bare kontrollere, at ARITHABORT faktisk kan forårsage problemet i sig selv (da forespørgslen, jeg havde problemer med, ikke havde nogen parametre, hvilket tager parameter sniffing ud af ligningen).
Svar
Dette minder mig om det nøjagtigt samme problem, som jeg oplevede i SQL Server 2008 dage. I vores tilfælde fandt vi pludselig et sql-job pludselig bremset (normalt et par sekunder, og nu 9+ minutter), jobbet skal have adgang til en linket server, vi tilføjede indstillingen ARITHABORT til i jobtrinnet, og det så ud til problemet blev løst i et par dage og vendte derefter tilbage.
Vi åbnede senere en billet med MS-support, og oprindeligt kan de heller ikke finde ud af det, og billetten blev eskaleret til et meget højt PFE-hold og to support PFEer forsøgte at finde ud af dette problem.
Den endelige årsag er, at brugerlegitimationsoplysningerne (for at køre jobtrinnet) ikke kan få adgang til statistikken for de underliggende tabeller (på den linkede serverside), og eksekveringsplanen er således ikke optimeret.
I detaljer har brugeren ikke tilladelse til DBCC SHOW_STATISTICS (selvom brugeren kan vælge fra bordet). I henhold til MSDN ændres denne tilladelsesregel efter sql 2012 SP1
Tilladelser til SQL Server og SQL Database
For at se statistikobjektet skal brugeren eje tabellen eller brugeren skal være medlem af rollen sysadmin fast server, rollen db_owner fast database eller rollen db_ddladmin fast database.
SQL Server 2012 SP1 ændrer tilladelsesbegrænsningerne og tillader brugere med SELECT-tilladelse at bruge denne kommando. Bemærk, at følgende krav eksisterer for at SELECT-tilladelser skal være tilstrækkelige til at køre kommandoen:
For at bekræfte dette problem skal vi bare køre profilen på den linkede serversidesinstans og slå nogle begivenheder til i “Fejl” og advarsler “sektionen som vist nedenfor.
Håber, at denne oplevelse måske hjælper samfundet på en eller anden måde.
SETmulighed for at få en bedre plan og fejldiagnose dette som selve indstillingen, der er skyld. Jeg ‘ er ikke overbevist om, at fyren i dit link ikke har ‘ ikke gjort dette.