Kysely on yksittäinen valinta, joka sisältää paljon ryhmittelytasoja ja pahentavia operaatioita. SET ARITHABORT ON -asennossa kestää alle sekunnin, muuten kestää useita minuutteja. Olemme havainneet tämän käyttäytymisen SQL Server 2000: ssa ja 2008.
Vastaus
Hieman päivätty, mutta kaikille, jotka päätyvät tänne samanlainen ongelma …
Minulla oli sama ongelma. Minulle se osoittautui parametrin haistamiseksi, josta en aluksi ymmärtänyt tarpeeksi huolta. Lisäsin ”asetetun aritabortin päälle”, joka korjasi ongelman, mutta sitten se palasi takaisin. Sitten luin:
http://www.sommarskog.se/query-plan-mysteries.html
Se puhdisti kaiken – koska käytin Linqia SQL ja minulla oli rajalliset vaihtoehdot ongelman korjaamiseen, ja käytin kyselysuunnitelmaa (katso linkin loppu) pakottaakseni haluamasi kyselysuunnitelman.
Kommentit
- Yli kuusi vuotta myöhemmin tässä vastauksessa annettu linkki on edelleen ” vaadittu lukemaan ” … ja silti myös nykyinen, viimeisin versio on joulukuu ’ 17.
Vastaa
.NET-sovellukset muodostavat yhteyden oletusarvoisesti pois käytöstä asetettuun asetukseen, mutta se on oletusarvoisesti käytössä Management Studiossa. Tuloksena on, että palvelin tallentaa välimuistiin 2 erillistä suoritussuunnitelmaa useimmille / kaikille toimenpiteille. Tämä vaikuttaa siihen, kuinka palvelin suorittaa numeerisia laskutoimituksia, ja sinänsä voit saada erittäin erilaisia tuloksia menettelystä riippuen. Tämä on oikeastaan vain yksi kahdesta tavallisesta tapasta, jolla proc voi saada syötteen kauheasta suoritussuunnitelmasta, toinen on parametrin haistaminen.
Katso https://web.archive.org/web/20150315031719/http://sqladvice.com/blogs/gstark/archive/2008/02/12/Arithabort-Option-Effects-Stored-Procedure-Performance.aspx hieman enemmän keskustelua aiheesta.
Kommentit
Vastaa
Väitän, että tämä oli melkein varmasti parametrien haistamista.
Usein todetaan, että SET OPTIONS voi vaikuttaa suorituskykyyn tällä tavalla, mutta en ole vielä nähnyt tätä väitettä varten yhtä ainoaa arvovaltaista lähdettä paitsi siinä tapauksessa, että olet käyttämällä indeksoituja näkymiä / pysyviä laskettuja sarakkeita.
Tässä tapauksessa (SQL2005 + ja , ellei tietokanta ole SQL2000-yhteensopivuustilassa ). Jos sinulla on sekä ARITHABORT että ANSI_WARNINGS OFF, hakemistoa ei käytetä joten sillä voi olla skannaus mieluummin kuin haluttu haku (ja joitain yleiskustannuksia, koska pysyvää laskentatulosta ei voida käyttää). ADO.NET näyttää oletusarvoisesti olevan ANSI_WARNINGS ON äsken tekemästäni testistä.
Vaatimus Benin vastaus , että ”tapa, jolla palvelin suorittaa numeerisia laskutoimituksia”, voi lisätä minuutteja tulokseen, joka muuten vie alle sekunnin, ei vain näytä uskottavalta. Luulen, että sillä on tapana tapahtua, on se, että tutkittaessa suorituskykyongelmia Profileria käytetään loukkaavan kyselyn tunnistamiseen. Tämä liitetään hallintastudioon ja suoritetaan ja palauttaa tulokset heti. Ainoa ilmeinen ero yhteyksien välillä on vaihtoehto ARITH_ABORT.
Nopea testi hallintastudio-ikkunassa osoittaa, että kun SET ARITHABORT OFF otetaan käyttöön ja kysely suoritetaan, suorituskykyongelma toistuu niin, että se on ilmeisesti suljettu. Tämä näyttää todellakin olevan vianetsintämenetelmä, jota käytetään Gregg Stark -linkissä.
Siinä kuitenkin jätetään huomiotta se, että tällä asetussarjalla voit saat lopulta täsmälleen saman huonon suunnitelman välimuistista .
Tätä suunnitelman uudelleenkäyttöä voi tapahtua, vaikka olet kirjautunut sisään eri käyttäjänä kuin sovellusyhteys käyttää.
Testasin tämän suorittamalla testikyselyn ensin verkkosovelluksesta ja sitten hallintastudiosta SET ARITHABORT OFF -palvelun avulla ja voin nähdä käyttäjätilit nousevan alla olevasta kyselystä.
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) Jotta tämä pf-suunnitelma tosiasiallisesti tapahtuisi, kaikkien suunnitelman välimuistiavainten on oltava samat. Sen lisäksi, että itse arithabort, muutamat esimerkit ovat, että suorittavat käyttäjät tarvitsevat saman oletusmallin (jos kysely perustuu implisiittiseen nimen tarkkuuteen) ja yhteydet tarvitsevat saman language asetettu.
Täydellisempi luettelo suunnitelman välimuistiavaimista täällä
Vastaa
Tiedän, että olen myöhässä tälle juhlalle, mutta tuleville vierailijoille Martin on täsmälleen oikeassa. Me törmäsimme tähän samaan ongelmaan – SP kävi hyvin hitaasti .NET-asiakkaille, vaikka SSMS: ssä se räjähti nopeasti. Tutkiessamme ja ratkaistessamme ongelmaa teimme systemaattisen testauksen, josta Kenny Evitt kysyy kommentissaan Martinin kysymykseen.
Käyttämällä muunnosta Martinin kyselyllä etsin SP: tä menettelyvälimuistista ja löysin kaksi niistä. Suunnitelmia tarkasteltaessa itse asiassa oli, että yhdellä oli ARITHABORT päällä ja yhdellä ARITHABORT pois päältä. ARITHABORT OFF -versiolla oli hakemistohaku kun ARITHABORT ON -versio käytti hakemistoa sama lähtö. Asiaan liittyvien parametrien perusteella hakemistohaku olisi edellyttänyt etsintää kymmenistä miljoonista tietueista tuotokselle.
Tyhjensin molemmat menettelyt välimuistista ja pyysin .NET-asiakasta suorittamaan SP: n uudelleen käyttämällä samat parametrit (joissa oli laaja ajanjakso asiakkaalle, jolla oli paljon toimintaa). SP palasi heti. Välimuistissa oli sama indeksiskannaus, joka oli aiemmin esillä ARITHABORT ON -suunnitelmassa – mutta tällä kertaa suunnitelma oli ARITHABORT OFF. Suoritimme SP: n samoilla parametreilla SSMS: ssä ja saimme jälleen tuloksia heti. Nyt näimme, että toinen suunnitelma oli välimuistissa ARITHABORT ON -ohjelmassa hakemistoskannauksen avulla.
Sitten tyhjensimme välimuistin, suoritimme SP: n SSMS: ssä kapealla ajanjaksolla ja saimme välittömän tuloksen. Huomasimme, että tuloksena olevalla välimuistissa olevalla suunnitelmalla oli hakemistohaku, sillä sama tulos oli aiemmin käsitelty skannauksella (joka oli myös tavoite alkuperäisessä suunnitelmassa ARITHABORT OFF -tilassa). Jälleen SSMS: stä suoritimme SP: n, tällä kertaa samalla laajalla ajanjaksolla, ja näimme saman kauhean suorituskyvyn kuin alkuperäisessä .NET-pyynnössä.
Lyhyesti sanottuna eroilla ei ollut mitään tekemistä ARITHABORTin todellinen arvo – sen ollessa päällä tai pois päältä kummaltakin asiakkaalta, saisimme hyväksyttävän tai kauhean suorituskyvyn: Tärkeää oli vain suunnitelman kokoamisessa ja välimuistissa käytettävät parametriarvot.
Vaikka MSDN osoittaa, että ARITHABORT OFF -toiminnolla itsellään voi olla kielteinen vaikutus kyselyn optimointiin, testauksemme vahvistavat Martinin olevan oikeassa – syy oli parametrin haistaminen ja tuloksena oleva suunnitelma ei ollut optimaalinen kaikille parametrialueille.
Kommentit
- Mietitkö mitä lause
Setting ARITHABORT to OFF can negatively impact query optimization leading to performance issues.tarkoittaa. Puhuvatko he vain kyvyttömyydestä käyttää hakemistoja lasketuissa sarakkeissa ja näkymissä (josANSI_WARNINGSon myös pois päältä) vai onko sillä todellakin muuta vaikutusta. - En ’ ole varma. Ihmettelen, onko ’ yksinkertaisesti tapaus, että joku MSDN: stä joutui samanlaiseen tilanteeseen, asetti ARTIHABORTin päälle, näki suorituskyvyn parannuksen ja päätyikö samoihin johtopäätöksiin. Indeksoitujen näkymien ja laskettujen sarakkeiden osalta olen ’ m epäselvä. Yhdessä kohdassa se toteaa, että SET-asetuksilla on oltava erityiset arvot, jos INSERT-, UPDATE- tai DELETE-toiminto muuttaa sinne tallennettuja data-arvoja. Muualla he toteavat, että optimoija jättää huomiotta hakemistot ” kaikilla kyselyillä ”, jotka viittaavat mainittuun indeksoituun näkymään tai laskettuun sarakkeeseen. Ovatko molemmat totta, vai onko se todella ” mikä tahansa kysely, joka muokkaa tietoja ”?
Vastaa
Oli juuri tämä ongelma. Kuten ihmiset sanoivat täällä, perimmäinen syy on useita kyselysuunnitelmia, joista yksi on alle optimaalisen. Halusin vain varmistaa, että ARITHABORT voi itse aiheuttaa ongelman (koska kyselyllä, jolla minulla oli ongelmia, ei ollut parametreja, mikä poistaa parametrien haistamisen yhtälöstä).
Vastaus
Tämä muistuttaa minua täsmälleen samasta ongelmasta, jonka kokin SQL Server 2008 -päivinä. Meidän tapauksessamme yhtäkkiä havaitsimme yhden sql-työn äkillisen hidastuneen (yleensä muutama sekunti ja nyt yli 9 minuuttia), työn on käytettävä linkitettyä palvelinta, lisäsimme ARITHABORT-toiminnon käyttöön työn vaiheessa, ja näytti siltä ongelma ratkaistiin muutaman päivän ajan ja palasimme sitten.
Avasimme myöhemmin lipun MS-tuella, eikä heitä aluksi voida selvittää, ja lippu siirrettiin erittäin vanhalle PFE-tiimille ja kahdelle tukea PFE: t yrittivät selvittää tämän ongelman.
Viimeinen syy on se, että käyttäjän tunnistetiedot (tehtävän suorittamiseksi) eivät voi käyttää alla olevien taulukoiden tilastoja (linkitetyn palvelimen puolella), joten suoritussuunnitelmaa ei ole optimoitu.
Yksityiskohtaisesti käyttäjällä ei ole oikeuksia DBCC SHOW_STATISTICS (vaikka käyttäjä voi valita pöytä). MSDN : n mukaan tätä käyttöoikeussääntöä muutetaan SQL 2012 SP1: n jälkeen
SQL Serverin ja SQL-tietokannan käyttöoikeudet
Tilasto-objektin tarkastelemiseksi käyttäjän on omistettava taulukko tai käyttäjän on oltava kiinteän sysadmin-palvelinroolin, kiinteän db_owner-tietokantaroolin tai kiinteän db_ddladmin-tietokantaroolin jäsen.
SQL Server 2012 SP1 muuttaa käyttöoikeusrajoituksia ja antaa käyttäjille, joilla on SELECT-oikeus, käyttää tätä komentoa. Huomaa, että seuraavat oikeudet ovat voimassa, jotta SELECT-käyttöoikeudet riittäisivät komennon suorittamisen:
Tämän ongelman vahvistamiseksi meidän on vain suoritettava profilointilinkki linkitetyn palvelinpuolen ilmentymässä ja käynnistettävä joitakin tapahtumia Virheet ja varoitukset ”-osio alla olevan kuvan mukaisesti.
Toivottavasti tämä kokemus voi auttaa jotenkin yhteisöä.
SET-vaihtoehdon muuttaminen on erittäin helppoa, jotta saat paremman suunnitelman ja diagnosoitaan tämän väärin itse vaihtoehtona. En ’ en ole vakuuttunut linkissä olevan kaverin ole ’ ole tehnyt tätä.