A lekérdezés egyetlen választó, amely sok csoportosítási szintet és súlyosbító műveleteket tartalmaz. A BEÁLLÍTOTT ARITÁRMAZÁS bekapcsolása kevesebb, mint egy másodpercig tart, különben több percig tart. Láttuk ezt a viselkedést az SQL Server 2000 és 2008 rendszereken.
Válasz
Kicsit kelt, de bárkinek, aki itt végez hasonló probléma …
Ugyanez volt a problémám. Számomra ez a paraméter szippantás volt, amit először nem értettem eléggé ahhoz, hogy érdekeljen. Hozzáadtam egy “set arithabort on” -ot, amely megoldotta a problémát, de aztán visszajött. Aztán olvastam:
http://www.sommarskog.se/query-plan-mysteries.html
Minden mindent kitisztított. Mivel a Linq-et használtam a SQL és korlátozott lehetőségeim voltak a probléma megoldására, végül egy lekérdezési terv útmutatót (lásd a link végét) használva kényszerítettem a kívánt lekérdezési tervet.
Megjegyzések
- Több mint hat évvel később az ebben a válaszban megadott link még mindig ” kötelező olvasmány ” … és még mindig aktuális is, a legújabb verzió december ‘ 17.
Válasz
A .NET-alkalmazások alapértelmezés szerint kikapcsolt opcióval kapcsolódnak, de alapértelmezés szerint engedélyezve van a Management Studio alkalmazásban. Ennek eredményeként a kiszolgáló valójában 2 külön végrehajtási tervet tárol a legtöbb / összes eljárás számára. Ez befolyásolja, hogy a kiszolgáló hogyan végez számszerű számításokat, és mint ilyen, az eljárástól függően rendkívül eltérő eredményeket érhet el. Ez valójában csak egyike annak a két általános módnak, amelyekkel a proc szörnyű végrehajtási tervet kaphat, a másik pedig a paraméterek szippantása.
Vessen egy pillantást az https://web.archive.org/web/20150315031719/http://sqladvice.com/blogs/gstark/archive/2008/02/12/Arithabort-Option-Effects-Stored-Procedure-Performance.aspx , hogy még egy kis beszélgetést folytassunk róla.
Megjegyzések
Válasz
Azt állítom, hogy ez szinte biztosan a paraméterek szippantása volt.
Gyakran elhangzik, hogy SET OPTIONS ilyen módon befolyásolhatja a teljesítményt, de még nem láttam egyetlen hiteles forrást ehhez az állításhoz, az Ön esetét kivéve indexelt nézetek / tartósan kiszámított oszlopok használata.
Ebben az esetben (SQL2005 + és esetén, kivéve, ha az adatbázisa SQL2000 kompatibilitási módban van ). Ha van ARITHABORT és ANSI_WARNINGS OFF is, akkor az indexet nem használják így lehet, hogy a keresés helyett a keresés lesz (és némi rezsi, mivel a kitartó számítási eredmény nem használható). Úgy tűnik, hogy az ADO.NET alapértelmezés szerint ANSI_WARNINGS ON az imént elvégzett gyors tesztből.
A állítás Ben válasza , miszerint “a kiszolgáló számszerűsítésének módja” perceket adhat az eredményhez, amely egyébként kevesebb, mint egy másodpercet vesz igénybe, számomra nem tűnik hitelesnek. Azt hiszem, ami általában megtörténik, az az, hogy egy teljesítmény-teljesítményprobléma kivizsgálásakor a Profilert használják a jogsértő lekérdezés azonosítására. Ezt beillesztik a menedzsment stúdióba, és futtatják, és azonnal visszaadja az eredményeket. Az egyetlen látható különbség a kapcsolatok között az ARITH_ABORT opció.
A felügyeleti stúdió ablakának gyors tesztje azt mutatja, hogy amikor a SET ARITHABORT OFF be van kapcsolva, és a lekérdezés futtatásakor a teljesítményprobléma megismétlődik, ez látszólag lezárt. Úgy tűnik, hogy ez a Gregg Stark linkben használt hibaelhárítási módszer.
Ez azonban figyelmen kívül hagyja azt a tényt, hogy ezzel az opciókészlettel végül ugyanazt a rossz tervet kapja a gyorsítótárból .
Ez a terv újrafelhasználása akkor is megtörténhet, ha más felhasználóként van bejelentkezve, mint az alkalmazáskapcsolat.
Ezt úgy teszteltem, hogy először tesztlekérdezést hajtottam végre egy webalkalmazásból, majd a menedzsment stúdióból a SET ARITHABORT OFF segítségével, és láthattam, hogy az alábbi lekérdezésből felfelé haladnak-e a felhasználói számlák. / p>
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) Ahhoz, hogy ez a megosztási pf-tervek valóban megvalósulhassanak, az összes terv-gyorsítótár kulcsának meg kell egyeznie. Amellett, hogy maga a arithabort is van néhány más példa, a végrehajtó felhasználóknak ugyanarra az alapértelmezett sémára van szükségük (ha a lekérdezés implicit névfeloldásra támaszkodik), és a kapcsolatoknak is ugyanazra a language készlet.
Válasz
Tudom, hogy elkéstem erről a buliról, de a jövőbeni látogatók számára Martinnak pontosan igaza van. Ugyanezzel a kérdéssel futottunk össze – egy SP nagyon lassan futott a .NET ügyfelek számára, miközben az SSMS-nél gyors volt. A probléma feltárása és megoldása során elvégeztük a szisztematikus tesztelést, amelyről Kenny Evitt kérdezi Martin kérdéséhez fűzött megjegyzésében.
Az Martin lekérdezésével az eljárás gyorsítótárában kerestem az SP-t, és kettőt találtam. A terveket nézve valójában az volt az egyik, hogy ARITHABORT be van kapcsolva, és egy ARITHABORT ki van kapcsolva. Az ARITHABORT OFF verzió indexet keres míg az ARITHABORT ON verzió indexkeresést használt ugyanaz a kimenet. Tekintettel az érintett paraméterekre, az indexkereséshez több tízmillió rekord keresése kellett volna a kimenethez.
Töröltem a két eljárást a gyorsítótárból, és a .NET klienst újra futtattam az SP-vel, a ugyanazok a paraméterek (amelyek széles dátumtartományt tartalmaztak a sok tevékenységet folytató ügyfél számára). Az SP azonnal visszatért. A gyorsítótárazott terv ugyanazt az indexszkennelést használta, amely korábban szerepelt az ARITHABORT ON tervben – de ezúttal a terv az ARITHABORT OFF volt. Futtattuk az SP-t ugyanazokkal a paraméterekkel az SSMS-ben, és ismét azonnal eredményeket kaptunk. Most azt láttuk, hogy egy második terv lett tárolva az ARITHABORT ON számára az index szkenneléssel.
Ezután töröltük a gyorsítótárat, szűk dátumtartománnyal futtattuk az SP-t SSMS-ben, és azonnali eredményt kaptunk. Megállapítottuk, hogy a kapott gyorsítótárazott index indexkereséssel rendelkezik, mert ugyanazt a kimenetet korábban szkenneléssel kezelték (ami szintén az eredeti tervben volt keresés ARITHABORT OFF esetén). Ismét SSMS-ből futtattuk az SP-t, ezúttal ugyanolyan széles dátumtartományban, és ugyanazt a szörnyű teljesítményt láttuk, mint az eredeti .NET-kérésben.
Röviden, a különbségnek semmi köze nem volt az ARITHABORT tényleges értéke – be- vagy kikapcsolva bármelyik klienstől elfogadható vagy szörnyű teljesítményt kaphatunk: Csak a terv összeállításakor és gyorsítótárában használt paraméterértékek voltak fontosak.
Míg Az MSDN azt jelzi, hogy maga az ARITHABORT OFF negatív hatással lehet a lekérdezések optimalizálására, tesztjeink megerősítik, hogy Martin igaza van – az ok a paraméterek szippantása volt, és az ebből következő terv nem volt optimális az összes paramétertartományhoz.
Megjegyzések
- Kíváncsi, mit jelent ez a kifejezés
Setting ARITHABORT to OFF can negatively impact query optimization leading to performance issues.. Akár csak arról beszélnek, hogy nem lehet indexeket használni a számított oszlopokon és nézeteken (ha aANSI_WARNINGSszintén ki van kapcsolva), vagy valóban van-e valamilyen más hatása. - ‘ nem vagyok biztos benne. Kíváncsi vagyok, vajon ‘ egyszerűen arról van-e szó, hogy az MSDN-nél valaki hasonló helyzetbe került, az ARTIHABORT-ot ON állásba kapcsolta, látta a teljesítmény javulását és ugyanazokra a következtetésekre ugrott-e. Az indexelt nézetek és a kiszámított oszlopok tekintetében I ‘ m nem világos. Egy ponton kijelenti, hogy a SET opcióknak konkrét értékekkel kell rendelkezniük, ha egy INSERT, UPDATE vagy DELETE művelet módosítja a bennük tárolt adatértékeket. Másutt azt állítják, hogy az optimalizáló figyelmen kívül hagyja a ” indexeket, ha bármilyen lekérdezés “, amely hivatkozik az indexelt nézetre vagy a kiszámított oszlopra. Mindkettő igaz, vagy valóban ” bármilyen lekérdezés módosítja az adatokat “?
Válasz
Éppen ez a probléma merült fel. Amint az emberek itt elmondták, a kiváltó ok több lekérdezési terv, amelyek közül az egyik nem optimális. Csak azt szerettem volna ellenőrizni, hogy az ARITHABORT valóban maga okozhatja-e a problémát (mivel a lekérdezésnek, amellyel problémáim voltak, nem voltak paraméterei, ami kiveszi a paraméterek szippantását az egyenletből).
Válasz
Ez pontosan ugyanazt a problémát juttatja eszembe, amelyet az SQL Server 2008 napjaiban tapasztaltam. Esetünkben hirtelen azt találtuk, hogy egy sql munka hirtelen lelassult (általában néhány másodperc, és most több mint 9 perc), a munkának hozzáférnie kell egy összekapcsolt szerverhez, a munka lépésében felvettük az ARITHABORT funkciót, és úgy tűnt a problémát néhány napra megoldották, majd visszatértünk.
Később megnyitottunk egy jegyet az MS támogatásával, és kezdetben ők sem tudják megtudni, és a jegyet egy nagyon magas rangú PFE csapat felé terjesztették, és kettőt támogatást nyújtó PFE-k megpróbálták kideríteni ezt a kérdést.
A végső ok az, hogy a felhasználói hitelesítő adatok (a feladat futtatásához) nem férhetnek hozzá az alapul szolgáló táblák statisztikáihoz (a kapcsolt szerver oldalon), és így a végrehajtási terv nincs optimalizálva.
Részletesen: a felhasználónak nincs engedélye a DBCC SHOW_STATISTICS címre (bár a felhasználó kiválaszthat az asztal). Az MSDN szerint ez az engedélyszabály az sql 2012 SP1 után megváltozik
Engedélyek az SQL Server és az SQL Database számára
A statisztikai objektum megtekintéséhez a felhasználónak rendelkeznie kell a táblával vagy a felhasználónak tagnak kell lennie a sysadmin fix szerver szerepkörben, a db_owner fix adatbázis szerepkörben vagy a db_ddladmin rögzített adatbázis szerepkörben.
Az SQL Server 2012 SP1 módosítja az engedélykorlátozásokat és lehetővé teszi a SELECT jogosultsággal rendelkező felhasználók számára a parancs használatát. Ne feledje, hogy a következő engedélyek léteznek ahhoz, hogy a SELECT engedélyek elegendőek legyenek a parancs futtatásához:
A probléma ellenőrzéséhez csak a profilot kell futtatnunk a csatolt kiszolgálóoldali példányon, és be kell kapcsolnunk néhány eseményt a “Hibák” részben és figyelmeztetések “szakasz az alábbiak szerint.
Remélem, hogy ez az élmény valahogy segíteni tudja a közösséget.
SETopciót, ha jobb tervet akarsz kapni, és ezt hibásan diagnosztizálod, mivel ez maga az Opció a hibás. ‘ nem vagyok meggyőződve arról, hogy a linkedben lévő srác még ‘ nem tette ezt.