Az Intelligens Elemzések – Azure SQL Database és felügyelt Azure SQL-példány teljesítményproblémáinak elhárítása

A következőre vonatkozik: Azure SQL DatabaseFelügyelt Azure SQL-példány

Ez a lap az Intelligens Elemzések erőforrásnaplóban észlelt Azure SQL Database-ről és az Azure SQL Managed Instance teljesítményproblémáiról nyújt tájékoztatást. A metrikák és erőforrásnaplók streamelhetők az Azure Monitor-naplókba, az Azure Event Hubsba, az Azure Storage-ba vagy egy külső megoldásba egyéni DevOps-riasztási és jelentéskészítési képességekhez.

Megjegyzés:

Az Intelligens Elemzések használatával végzett gyors teljesítmény hibaelhárítási útmutatóért tekintse meg a dokumentumban található ajánlott hibaelhárítási folyamatábrát.

Az intelligens elemzések előzetes verziójú funkciók, amelyek nem érhetők el a következő régiókban: Nyugat-Európa, Észak-Európa, USA 1. nyugati régiója és USA 1. keleti régiója.

Észlelhető adatbázis-teljesítményminták

Az intelligens Elemzések automatikusan észleli a teljesítményproblémákat a lekérdezés végrehajtásának várakozási ideje, hibái vagy időtúllépései alapján. Az intelligens Elemzések az erőforrásnapló teljesítménymintáit észlelte. Az észlelhető teljesítménymintákat az alábbi táblázat foglalja össze.

Észlelhető teljesítményminták	Azure SQL Database	Azure SQL Managed Instance
Erőforráskorlátok elérése	A monitorozott előfizetésben elérhető erőforrások (DTU-k), adatbázis-feldolgozói szálak vagy adatbázis-bejelentkezési munkamenetek használata elérte az erőforráskorlátokat. Ez hatással van a teljesítményre.	A CPU-erőforrások felhasználása eléri az erőforráskorlátokat. Ez hatással van az adatbázis teljesítményére.
Számítási feladatok növelése	A számítási feladatok növekedése vagy folyamatos felhalmozódása észlelhető az adatbázisban. Ez hatással van a teljesítményre.	A számítási feladatok növekedése észlelhető. Ez hatással van az adatbázis teljesítményére.
Memóriaterhelés	A memóriakiosztást kérő munkavállalóknak statisztikailag jelentős ideig kell várniuk a memóriakiosztásokra, vagy meg kell növelni a memóriakiosztást igénylő dolgozók megnövekedett halmozódását. Ez hatással van a teljesítményre.	Azok a dolgozók, akik memóriatámogatást kértek, statisztikailag jelentős ideig várják a memóriafoglalásokat. Ez hatással van az adatbázis teljesítményére.
Zár	A rendszer túlzott mértékű adatbázis-zárolást észlelt, ami hatással van a teljesítményre.	A rendszer túlzott adatbázis-zárolást észlelt, ami hatással van az adatbázis teljesítményére.
Megnövelt MAXDOP	A párhuzamossági beállítás (MAXDOP) maximális mértéke megváltozott, ami hatással van a lekérdezések végrehajtásának hatékonyságára. Ez hatással van a teljesítményre.	A párhuzamossági beállítás (MAXDOP) maximális mértéke megváltozott, ami hatással van a lekérdezések végrehajtásának hatékonyságára. Ez hatással van a teljesítményre.
Pagelatch-versengés	Egyszerre több szál is megpróbál hozzáférni ugyanahhoz a memóriabeli adatpufferoldalhoz, ami megnöveli a várakozási időt, és pagelatch-versengést okoz. Ez hatással van a teljesítményre.	Egyszerre több szál is megpróbál hozzáférni ugyanahhoz a memóriabeli adatpufferoldalhoz, ami megnöveli a várakozási időt, és pagelatch-versengést okoz. Ez hatással van az adatbázis teljesítményére.
Hiányzó index	A rendszer hiányzó indexet észlelt, amely hatással van a teljesítményre.	A rendszer hiányzó indexet észlelt, amely hatással volt az adatbázis teljesítményére.
Új lekérdezés	A rendszer új lekérdezést észlelt, amely hatással van a teljes teljesítményre.	A rendszer új lekérdezést észlelt, amely hatással volt az adatbázis teljes teljesítményére.
Megnövekedett várakozási statisztika	A rendszer megnövekedett adatbázis-várakozási időt észlelt, ami hatással van a teljesítményre.	Az adatbázis teljesítményét befolyásoló megnövekedett adatbázis-várakozási idő észlelhető.
TempDB-versengés	Több szál próbál hozzáférni ugyanahhoz tempdb az erőforráshoz, ami szűk keresztmetszetet okoz. Ez hatással van a teljesítményre.	Több szál próbál hozzáférni ugyanahhoz tempdb az erőforráshoz, ami szűk keresztmetszetet okoz. Ez hatással van az adatbázis teljesítményére.
Rugalmas készlet DTU-hiánya	A rugalmas készletben rendelkezésre álló eDTU-k hiánya hatással van a teljesítményre.	A felügyelt Azure SQL-példányhoz nem érhető el, mivel a virtuálismag-modellt használja.
Regresszió megtervezése	A rendszer új tervet vagy egy meglévő terv számítási feladatának módosítását észlelte. Ez hatással van a teljesítményre.	A rendszer új tervet vagy egy meglévő terv számítási feladatának módosítását észlelte. Ez hatással van az adatbázis teljesítményére.
Adatbázis-hatókörű konfigurációs érték módosítása	Az adatbázis konfigurációváltozása hatással volt az adatbázis teljesítményére.	Az adatbázis konfigurációváltozása hatással volt az adatbázis teljesítményére.
Lassú ügyfél	A lassú alkalmazásügyfél nem tudja elég gyorsan felhasználni az adatbázis kimenetét. Ez hatással van a teljesítményre.	A lassú alkalmazásügyfél nem tudja elég gyorsan felhasználni az adatbázis kimenetét. Ez hatással van az adatbázis teljesítményére.
Tarifacsomagok leminősítése	A tarifacsomag-csökkentési művelet csökkentette az elérhető erőforrásokat. Ez hatással van a teljesítményre.	A tarifacsomag-csökkentési művelet csökkentette az elérhető erőforrásokat. Ez hatással van az adatbázis teljesítményére.

Tipp.

Az adatbázisok folyamatos teljesítményoptimalizálásához engedélyezze az automatikus hangolást. Ez a beépített intelligencia funkció folyamatosan figyeli az adatbázist, automatikusan hangolja az indexeket, és alkalmazza a lekérdezés-végrehajtási terv korrekcióit.

Az alábbi szakasz részletesebben ismerteti az észlelhető teljesítménymintákat.

Erőforráskorlátok elérése

Mi történik

Ez az észlelhető teljesítményminta egyesíti a rendelkezésre álló erőforráskorlátok, feldolgozói korlátok és munkamenetkorlátok eléréséhez kapcsolódó teljesítményproblémákat. A teljesítményproblémát észlelve a diagnosztikai napló leírási mezője jelzi, hogy a teljesítményprobam erőforrás-, feldolgozó- vagy munkamenetkorlátokkal kapcsolatos-e.

Az Azure SQL Database erőforrásait általában DTU- vagy vCore-erőforrásoknak, a felügyelt Azure SQL-példány erőforrásait pedig virtuálismag-erőforrásoknak nevezzük. Az erőforráskorlátok elérésének mintázata akkor lesz felismerve, ha a lekérdezési teljesítmény romlását a mért erőforráskorlátok bármelyikének elérése okozza.

A munkamenet korlátozza az erőforrást, amely az adatbázishoz elérhető egyidejű bejelentkezések számát jelöli. Ezt a teljesítménymintát akkor ismeri fel a rendszer, ha az adatbázisokhoz csatlakoztatott alkalmazások elérik az adatbázisba való egyidejű bejelentkezések számát. Ha az alkalmazások több munkamenetet próbálnak használni, mint amennyi elérhető az adatbázisban, a lekérdezési teljesítmény is befolyásolja.

A feldolgozói korlátok elérése az erőforráskorlátok elérésének egy konkrét esete, mivel az elérhető feldolgozók nem számítanak bele a DTU vagy a virtuális mag használatába. Az adatbázis feldolgozói korlátainak elérése erőforrás-specifikus várakozási idők emelkedését okozhatja, ami a lekérdezési teljesítmény romlását eredményezheti.

Hibaelhárítás

A diagnosztikai napló olyan lekérdezések lekérdezési kivonatait adja ki, amelyek befolyásolták a teljesítményt és az erőforrás-felhasználás százalékos arányát. Ezeket az információkat kiindulási pontként használhatja az adatbázis-számítási feladatok optimalizálásához. Az indexek hozzáadásával optimalizálhatja a teljesítménycsökkenést befolyásoló lekérdezéseket. Vagy optimalizálhatja az alkalmazásokat egyenletesebb számítási feladatok elosztásával. Ha nem tudja csökkenteni a számítási feladatokat vagy optimalizálni, érdemes lehet növelni az adatbázis-előfizetés tarifacsomagját az elérhető erőforrások mennyiségének növelése érdekében.

Ha elérte a rendelkezésre álló munkamenetkorlátokat, optimalizálhatja az alkalmazásokat az adatbázisba bejelentkezett bejelentkezések számának csökkentésével. Ha nem tudja csökkenteni az alkalmazásokból az adatbázisba történő bejelentkezések számát, fontolja meg az adatbázis-előfizetés tarifacsomagjának növelését. Vagy feloszthatja és áthelyezheti az adatbázist több adatbázisba a kiegyensúlyozottabb számítási feladatok elosztása érdekében.

A munkamenetkorlátok feloldásával kapcsolatos további javaslatokért tekintse meg a maximális bejelentkezések korlátainak kezelését ismertető témakört. A kiszolgáló és az előfizetési szintek korlátaival kapcsolatos információkért tekintse meg a kiszolgálók erőforráskorlátainak áttekintését.

A számítási feladatok mennyiségének növekedése

Mi történik

Ez a teljesítményminta azonosítja a számítási feladatok növekedése vagy súlyosabb formájában a számítási feladatok halmozódása által okozott problémákat.

Ez az észlelés több metrika kombinációján keresztül történik. A mért alapmetrika a számítási feladatok számának növekedését észleli a korábbi számítási feladatok alapkonfigurációjával összehasonlítva. Az észlelés másik formája az aktív munkaszálak nagy számának mérésén alapul, amely elég nagy ahhoz, hogy befolyásolja a lekérdezés teljesítményét.

Súlyosabb formájában a számítási feladat folyamatosan halmozódhat fel, mivel az adatbázis nem tudja kezelni a számítási feladatot. Az eredmény egy folyamatosan növekvő számítási feladatméret, amely a számítási feladatok halmozása. Ennek a feltételnek köszönhetően a számítási feladat végrehajtási várakozási ideje nő. Ez a feltétel az adatbázis egyik legsúlyosabb teljesítményproblémáját jelenti. Ezt a problémát a megszakított munkaszálak számának növekedésének figyelésével észleli a rendszer.

Hibaelhárítás

A diagnosztikai napló azoknak a lekérdezéseknek a számát adja ki, amelyeknek a végrehajtása növekedett, és a lekérdezés lekérdezési kivonata a legnagyobb mértékben hozzájárul a számítási feladatok növekedéséhez. Ezeket az információkat kiindulópontként használhatja a számítási feladatok optimalizálásához. A számítási feladat növelésének legnagyobb közreműködőjeként azonosított lekérdezés különösen hasznos kiindulópontként.

Érdemes lehet egyenletesebben szétosztani a számítási feladatokat az adatbázisba. Érdemes lehet optimalizálni a teljesítményt befolyásoló lekérdezést indexek hozzáadásával. A számítási feladatot több adatbázis között is eloszthatja. Ha ezek a megoldások nem lehetségesek, fontolja meg az adatbázis-előfizetés tarifacsomagjának növelését az elérhető erőforrások számának növeléséhez.

Memory pressure

Mi történik

Ez a teljesítményminta az adatbázis jelenlegi teljesítményében a memóriaterhelés miatti romlást jelzi, vagy súlyosabb formájában memória halmozódási állapotot jelez az elmúlt hét napos teljesítménykonfigurációhoz képest.

A memóriaterhelés olyan teljesítményállapotot jelöl, amelyben nagy számú munkavégző szál igényel memóriát. A nagy kötet magas memóriakihasználtsági állapotot okoz, amelyben az adatbázis nem tudja hatékonyan lefoglalni a memóriát az azt kérő összes feldolgozó számára. A probléma egyik leggyakoribb oka egyrészt az adatbázis számára rendelkezésre álló memória mennyiségével kapcsolatos. Másrészt a számítási feladatok számának növekedése a munkaszálak növekedését és a memóriaterhelést okozza.

A memóriaterhelés súlyosabb formája a memória halmozódási állapota. Ez a feltétel azt jelzi, hogy a feldolgozói szálak nagyobb számban kérnek memória-támogatást, mint amennyi lekérdezés felszabadítja a memóriát. A memóriakiosztást kérő feldolgozói szálak száma is folyamatosan növekedhet (felfelé), mivel az adatbázismotor nem tud elég hatékonyan lefoglalni memóriát az igények kielégítéséhez. A memória halmozódási állapota az adatbázis egyik legsúlyosabb teljesítményproblémáját jelenti.

Hibaelhárítás

A diagnosztikai napló a memóriaobjektum-tároló adatait a magas memóriahasználat és a releváns időbélyegek legfőbb okaként megjelölt feldolgozói szállal adja ki. Ezeket az információkat használhatja a hibaelhárítás alapjaként.

Optimalizálhatja vagy eltávolíthatja a legnagyobb memóriahasználattal rendelkező írnokokkal kapcsolatos lekérdezéseket. Emellett meggyőződhet arról is, hogy nem olyan adatokat kérdez le, amelyeket nem kíván használni. Az ajánlott eljárás az, hogy mindig használjon WHERE záradékot a lekérdezésekben. Emellett azt is javasoljuk, hogy a keresés helyett hozzon létre nem kizárólagos indexeket az adatok kereséséhez.

A számítási feladatokat úgy is csökkentheti, hogy optimalizálja vagy terjeszti azt több adatbázison. A számítási feladatokat több adatbázis között is eloszthatja. Ha ezek a megoldások nem lehetségesek, fontolja meg az adatbázis tarifacsomagjának növelését az adatbázis számára elérhető memóriaerőforrások számának növeléséhez.

További hibaelhárítási javaslatokért tekintse meg a Memory grants meditációt: A titokzatos SQL Server-memóriafogyó sok névvel. Az Azure SQL Database memóriakihasználtságával kapcsolatos hibákkal kapcsolatos további információkért lásd : Az Azure SQL Database memóriakihasználtságával kapcsolatos hibák elhárítása.

Zárolás

Mi történik

Ez a teljesítményminta az adatbázis jelenlegi teljesítményének romlását jelzi, amelyben a rendszer túlzott adatbázis-zárolást észlel az elmúlt hét napos teljesítménykonfigurációhoz képest.

A modern RDBMS-ben a zárolás elengedhetetlen a többszálú rendszerek megvalósításához, amelyekben a teljesítmény maximalizálható több egyidejű feldolgozó és párhuzamos adatbázis-tranzakciók futtatásával, ahol lehetséges. Ebben a kontextusban a zárolás azt a beépített hozzáférési mechanizmust jelenti, amelyben csak egyetlen tranzakció férhet hozzá kizárólag a szükséges sorokhoz, lapokhoz, táblákhoz és fájlokhoz, és nem versenyezhet egy másik erőforrás-tranzakcióval. Ha az erőforrásokat használat céljából zároló tranzakció velük történik, az erőforrások zárolása felszabadul, ami lehetővé teszi, hogy más tranzakciók hozzáférjenek a szükséges erőforrásokhoz. További információ a zárolásról: Zárolás az adatbázismotorban.

Ha az SQL-motor által végrehajtott tranzakciók hosszabb ideig várakoznak a használatra zárolt erőforrások eléréséhez, ez a várakozási idő a számítási feladatok végrehajtási teljesítményének lassulását okozza.

Hibaelhárítás

A diagnosztikai napló olyan zárolási adatokat ad ki, amelyeket a hibaelhárítás alapjául használhat. Elemezheti a jelentett blokkoló lekérdezéseket, vagyis a zárolási teljesítmény romlását okozó lekérdezéseket, és eltávolíthatja őket. Bizonyos esetekben sikeres lehet a blokkoló lekérdezések optimalizálása.

A probléma megoldásának legegyszerűbb és legbiztonságosabb módja a tranzakciók rövidsége és a legdrágább lekérdezések zárolási lábnyomának csökkentése. Nagy mennyiségű művelet kisebb műveletekre bontható. A legjobb eljárás a lekérdezés zárolási lábnyomának csökkentése a lekérdezés lehető leghatékonyabbá tételével. Csökkentse a nagy méretű vizsgálatokat, mert növelik a holtpontok esélyét, és hátrányosan befolyásolják az adatbázis általános teljesítményét. A zárolást okozó azonosított lekérdezések esetén létrehozhat új indexeket, vagy oszlopokat adhat hozzá a meglévő indexhez a táblavizsgálatok elkerülése érdekében.

További javaslatokért lásd:

• Az Azure SQL blokkolási problémáinak ismertetése és megoldása
• Az SQL Server zároláseszkalációja által okozott blokkolási problémák megoldása

Megnövelt MAXDOP

Mi történik

Ez az észlelhető teljesítményminta azt a feltételt jelzi, amelyben a kiválasztott lekérdezés-végrehajtási terv több párhuzamos volt, mint kellett volna. A lekérdezésoptimalizáló növelheti a számítási feladatok teljesítményét, ha a lekérdezéseket párhuzamosan hajtja végre, hogy ahol csak lehetséges, felgyorsítsa a dolgokat. Bizonyos esetekben a lekérdezést feldolgozó párhuzamos feldolgozók több időt töltenek azzal, hogy egymásra várva szinkronizálják és egyesítik az eredményeket ahhoz képest, hogy ugyanazt a lekérdezést kevesebb párhuzamos feldolgozóval hajtják végre, vagy akár néhány esetben egyetlen feldolgozószálhoz képest.

A szakértői rendszer az adatbázis aktuális teljesítményét elemzi az alapidőszakhoz képest. Meghatározza, hogy egy korábban futó lekérdezés lassabban fut-e, mint korábban, mert a lekérdezés-végrehajtási terv a vártnál párhuzamosabb.

A MAXDOP-kiszolgáló konfigurációs beállításával szabályozható, hogy hány processzormag használható ugyanazon lekérdezés párhuzamos végrehajtásához.

Hibaelhárítás

A diagnosztikai napló olyan lekérdezésekhez kapcsolódó lekérdezési kivonatokat ad ki, amelyek végrehajtásának időtartama nőtt, mert a párhuzamosságuk nagyobb volt, mint kellett volna. A napló a CXP várakozási idejét is kimeneteli. Ez az idő azt az időt jelöli, amikor egyetlen szervezői/koordinátori szál (0. szál) az összes többi szál befejezésére vár, mielőtt egyesítené az eredményeket, és továbblépne. Emellett a diagnosztikai napló azt a várakozási időt adja ki, amikor a rosszul teljesítő lekérdezések összességében a végrehajtás során várakoztak. Ezeket az információkat használhatja a hibaelhárítás alapjaként.

Először optimalizálja vagy egyszerűsítse le az összetett lekérdezéseket. Jó gyakorlat a hosszú kötegfeladatok kisebbekre bontása. Emellett győződjön meg arról, hogy indexeket hozott létre a lekérdezések támogatásához. Manuálisan is kikényszerítheti a párhuzamosság maximális fokát (MAXDOP) a gyenge teljesítményűként megjelölt lekérdezésekhez. A művelet T-SQL használatával történő konfigurálásához tekintse meg a MAXDOP-kiszolgáló konfigurációs beállításának konfigurálását.

Ha a MAXDOP-kiszolgáló konfigurációs beállítását alapértelmezett értékként nullára (0) állítja be, az azt jelzi, hogy az adatbázis az összes rendelkezésre álló processzormagot használhatja a szálak párhuzamosítására egyetlen lekérdezés végrehajtásához. A MAXDOP beállítása egy (1) értékre azt jelzi, hogy egyetlen lekérdezés végrehajtásához csak egy mag használható. Gyakorlati szempontból ez azt jelenti, hogy a párhuzamosság ki van kapcsolva. Az esetenkénti esetszámtól, az adatbázishoz elérhető magoktól és a diagnosztikai naplóadatoktól függően a MAXDOP beállítást a párhuzamos lekérdezések végrehajtásához használt magok számához hangolhatja, amelyek megoldhatják az ön esetében felmerülő problémát.

Pagelatch-versengés

Mi történik

Ez a teljesítményminta az adatbázis számítási feladatainak aktuális teljesítménycsökkenését jelzi a pagelatch-versengés miatt az elmúlt hét napos számítási feladat alapkonfigurációhoz képest.

A rácsok egyszerűsített szinkronizálási mechanizmusok a többszálúság engedélyezéséhez. Garantálják az indexeket, adatlapokat és egyéb belső struktúrákat tartalmazó memóriabeli struktúrák konzisztenciáját.

Számos típusú retesz érhető el. Az egyszerűség kedvéért a pufferzárak a memóriabeli lapok védelmére szolgálnak a pufferkészletben. Az IO-reteszek a pufferkészletbe még nem betöltött lapok védelmére szolgálnak. Amikor a pufferkészlet egy lapjára ír vagy olvas be adatokat, a feldolgozó szálnak először pufferzárat kell beszereznie az oldalhoz. Amikor egy feldolgozó szál olyan laphoz próbál hozzáférni, amely még nem érhető el a memóriabeli pufferkészletben, A rendszer IO-kérést küld a szükséges információk betöltésére a tárolóból. Az események sorozata a teljesítménycsökkenés súlyosabb formáját jelzi.

Az oldalzárlatok közötti versengés akkor fordul elő, ha több szál egyidejűleg megpróbál rácsokat szerezni ugyanazon a memórián belüli struktúrán, ami megnöveli a lekérdezés végrehajtásának várakozási idejét. A pagelatch I/O-versengés esetében, amikor az adatokat tárolóból kell elérni, ez a várakozási idő még nagyobb. Ez jelentősen befolyásolhatja a számítási feladatok teljesítményét. A Pagelatch-versengés a leggyakoribb forgatókönyve annak, hogy a szálak egymásra várnak, és több CPU-rendszeren versengenek az erőforrásokért.

Hibaelhárítás

A diagnosztikai napló a pagelatch-versengés részleteit adja ki. Ezeket az információkat használhatja a hibaelhárítás alapjaként.

Mivel a pagelatch egy belső vezérlő mechanizmus, automatikusan meghatározza, hogy mikor érdemes használni őket. Az alkalmazás döntései, beleértve a sématervet is, a rácsok determinisztikus viselkedése miatt befolyásolhatják a pagelatch viselkedését.

A reteszelési versengés kezelésének egyik módszere, ha a szekvenciális indexkulcsot nem egymást követő kulccsal cseréli le, így egyenletesen elosztja a beszúrásokat egy indextartományon belül. Az index egyik vezető oszlopa általában arányosan osztja el a számítási feladatot. Egy másik megfontolandó módszer a táblaparticionálás. A hash particionálási séma létrehozása egy particionált tábla számított oszlopával a túlzott reteszelési versengés enyhítésének gyakori módszere. A pagelatch IO-versengés esetében az indexek bevezetése segít a teljesítményproblémák megoldásában.

További információ: A reteszes versengés diagnosztizálása és feloldása az SQL Serveren (PDF-letöltés).

Hiányzó index

Mi történik

Ez a teljesítményminta az adatbázis számítási feladatainak aktuális teljesítménycsökkenését jelzi az elmúlt hét napos alaptervhez képest egy hiányzó index miatt.

Az index a lekérdezések teljesítményének felgyorsítására szolgál. Gyors hozzáférést biztosít a táblázatadatokhoz a meglátogatandó vagy megvizsgálandó adathalmazlapok számának csökkentésével.

A teljesítménycsökkenést okozó konkrét lekérdezéseket az észlelés azonosítja, amelyek esetében az indexek létrehozása előnyös lenne a teljesítmény szempontjából.

Hibaelhárítás

A diagnosztikai napló lekérdezési kivonatokat ad ki azokról a lekérdezésekről, amelyekről megállapították, hogy hatással vannak a számítási feladatok teljesítményére. Ezekhez a lekérdezésekhez indexeket hozhat létre. Ezeket a lekérdezéseket optimalizálhatja vagy eltávolíthatja is, ha nincs rájuk szükség. Jó teljesítménybeli gyakorlat a nem használt adatok lekérdezésének elkerülése.

Tipp.

Tudta, hogy a beépített intelligencia képes automatikusan kezelni az adatbázisok legjobban teljesítő indexeit?

A folyamatos teljesítményoptimalizálás érdekében javasoljuk, hogy engedélyezze az automatikus hangolást. Ez az egyedi beépített intelligencia funkció folyamatosan figyeli az adatbázist, és automatikusan hangolja és indexeket hoz létre az adatbázisokhoz.

Új lekérdezés

Mi történik

Ez a teljesítményminta azt jelzi, hogy a rendszer egy olyan új lekérdezést észlel, amely rosszul teljesít, és hatással van a számítási feladatok teljesítményére a hétnapos teljesítménykonfigurációhoz képest.

A jól teljesítő lekérdezések írása néha kihívást jelenthet. A lekérdezések írásáról további információt az SQL-lekérdezések írása című témakörben talál. A meglévő lekérdezési teljesítmény optimalizálásához tekintse meg a lekérdezés finomhangolását.

Hibaelhárítás

A diagnosztikai napló legfeljebb két új, processzort használó lekérdezés adatait adja ki, beleértve a lekérdezés kivonatait is. Mivel az észlelt lekérdezés hatással van a számítási feladatok teljesítményére, optimalizálhatja a lekérdezést. Ajánlott eljárás csak a használni kívánt adatok lekérése. Azt is javasoljuk, hogy where záradékkal rendelkező lekérdezéseket használjon. Azt is javasoljuk, hogy egyszerűsítse le az összetett lekérdezéseket, és bontsa őket kisebb lekérdezésekre. Egy másik ajánlott eljárás a nagy köteges lekérdezések kisebb köteg-lekérdezésekre bontása. Az új lekérdezések indexeinek bevezetése általában ajánlott megoldás a teljesítményproblémák enyhítésére.

Az Azure SQL Database-ben fontolja meg a Lekérdezési teljesítményelemzés használatát.

Megnövekedett várakozási statisztika

Mi történik

Ez az észlelhető teljesítményminta a számítási feladatok teljesítménycsökkenését jelzi, amelyben a rendszer a gyenge teljesítményű lekérdezéseket azonosítja az elmúlt hét napos számítási feladat alapkonfigurációja alapján.

Ebben az esetben a rendszer nem tudja besorolni a gyenge teljesítményű lekérdezéseket más standard észlelhető teljesítménykategóriákba, de a regresszióért felelős várakozási statisztikát észlelte. Ezért úgy tekinti őket, mint a megnövekedett várakozási statisztikákkal rendelkező lekérdezéseket, ahol a regresszióért felelős várakozási statisztika is elérhető.

Hibaelhárítás

A diagnosztikai napló adatokat ad ki a megnövekedett várakozási idő részleteiről és az érintett lekérdezések lekérdezési kivonatáról.

Mivel a rendszer nem tudta azonosítani a gyenge teljesítményű lekérdezések alapvető okát, a diagnosztikai információk jó kiindulópontot jelentenek a manuális hibaelhárításhoz. A lekérdezések teljesítményét optimalizálhatja. Az ajánlott eljárás az, hogy csak a használni kívánt adatokat szeretné lekérni, és egyszerűbbé és kisebbre bontani az összetett lekérdezéseket.

A lekérdezési teljesítmény optimalizálásáról további információt a Lekérdezés finomhangolása című témakörben talál.

TempDB-versengés

Mi történik

Ez az észlelhető teljesítményminta egy adatbázis teljesítményfeltételét jelzi, amelyben szűk keresztmetszet áll fenn az erőforrások elérésére tempdb próbáló szálak közül. (Ez a feltétel nem IO-kapcsolattal kapcsolatos.) A teljesítményprobléma tipikus forgatókönyve több száz egyidejű lekérdezés, amelyek mindegyike létrehoz, használ, majd elvet kis tempdb táblákat. A rendszer azt észlelte, hogy az azonos tempdb táblákat használó egyidejű lekérdezések száma megfelelő statisztikai jelentőséggel nőtt ahhoz, hogy befolyásolja az adatbázis teljesítményét az elmúlt hét napos teljesítménykonfigurációhoz képest.

Hibaelhárítás

A diagnosztikai napló a versengés részleteit adja ki tempdb . A hibaelhárítás kiindulópontjaként használhatja az információkat. Az ilyen típusú versengés enyhítése és a teljes számítási feladat átviteli sebességének növelése érdekében két dolgot végezhet: az ideiglenes táblák használatát megszüntetheti. Memóriaoptimalizált táblákat is használhat.

További információ: Bevezetés a memóriaoptimalizált táblák használatába.

Rugalmas készlet DTU-hiánya

Mi történik

Ez az észlelhető teljesítményminta az adatbázis számítási feladatainak jelenlegi teljesítményében az elmúlt hét napos alapkonfigurációhoz képest romlást jelez. Ennek az az oka, hogy az előfizetés rugalmas készletében nem áll rendelkezésre rendelkezésre álló DTU-k.

Az Azure rugalmas készlet erőforrásai több adatbázis között skálázási célokra megosztott rendelkezésre álló erőforrások készleteként használhatók. Ha a rugalmas készletben rendelkezésre álló eDTU-erőforrások nem elegendőek a készlet összes adatbázisának támogatásához, a rendszer észleli a rugalmas készlet DTU-hiányának teljesítményproblémáját.

Hibaelhárítás

A diagnosztikai napló adatokat ad ki a rugalmas készletről, felsorolja a leggyakoribb DTU-használó adatbázisokat, és megadja a készlet DTU-jának százalékos arányát, amelyet a legfelső szintű adatbázis használ.

Mivel ez a teljesítményfeltétel több adatbázishoz kapcsolódik, amelyek ugyanazt az eDTU-készletet használják a rugalmas készletben, a hibaelhárítási lépések a legfelső DTU-használatú adatbázisokra összpontosítanak. Csökkentheti a munkaterhelést a legigényesebb adatbázisokon, ami magában foglalja az ezeken az adatbázisokon a legigényesebb lekérdezések optimalizálását. Azt is ellenőrizheti, hogy nem kérdezi le a nem használt adatokat. Egy másik megközelítés az alkalmazások optimalizálása a legjobb DTU-használatú adatbázisok használatával, és a számítási feladat több adatbázis közötti újraelosztása.

Ha nem lehetséges csökkenteni és optimalizálni az aktuális számítási feladatot a DTU-t használó adatbázisokon, fontolja meg a rugalmas készlet tarifacsomagjának növelését. Ez a növekedés a rugalmas készletben elérhető DTU-k növekedéséhez vezet.

Regresszió megtervezése

Mi történik

Ez az észlelhető teljesítményminta azt a feltételt jelöli, amelyben az adatbázis egy optimálisnál rosszabb lekérdezés-végrehajtási tervet használ. Az optimálisnál rosszabb terv általában megnöveli a lekérdezések végrehajtását, ami hosszabb várakozási időt eredményez az aktuális és más lekérdezések esetében.

Az adatbázismotor határozza meg a lekérdezés-végrehajtási tervet a lekérdezés végrehajtásának legkisebb költségével. A lekérdezések és számítási feladatok típusa megváltozik, néha a meglévő tervek már nem hatékonyak, vagy talán az adatbázismotor nem végzett megfelelő értékelést. Javításként a lekérdezés-végrehajtási tervek manuálisan kényszeríthetők.

Ez az észlelhető teljesítményminta a tervregresszió három különböző esetét egyesíti: az új tervregressziót, a régi tervregressziót és a meglévő tervek módosított számítási feladatait. A terv regressziójának konkrét típusa a diagnosztikai napló részletek tulajdonságában található.

Az új tervregressziós feltétel olyan állapotra utal, amelyben az adatbázismotor egy olyan új lekérdezés-végrehajtási tervet kezd végrehajtani, amely nem olyan hatékony, mint a régi terv. A régi tervregressziós feltétel azt az állapotot jelenti, amikor az adatbázismotor egy új, hatékonyabb tervről a régi tervre vált, ami nem olyan hatékony, mint az új terv. A meglévő tervek módosított számításifeladat-regressziója azt az állapotot jelenti, amelyben a régi és az új tervek folyamatosan váltakoznak, és az egyenleg inkább a rosszul teljesítő terv felé halad.

A tervregresszióval kapcsolatos további információkért lásd: Mi a tervregresszió az SQL Serverben?

Hibaelhárítás

A diagnosztikai napló a lekérdezési kivonatokat, a jó tervazonosítót, a rossz tervazonosítót és a lekérdezésazonosítókat adja ki. Ezeket az információkat használhatja a hibaelhárítás alapjaként.

Elemezheti, hogy melyik terv teljesít jobban az adott lekérdezésekhez, amelyeket a megadott lekérdezéskivonatokkal azonosíthat. Miután meghatározta, hogy melyik terv működik jobban a lekérdezésekhez, manuálisan kényszerítheti.

További információ: Tudnivalók az SQL Server tervregresszióinak megakadályozása érdekében.

Tipp.

Tudta, hogy a beépített intelligencia funkció képes automatikusan kezelni az adatbázisok legjobban teljesítő lekérdezés-végrehajtási terveit?

A folyamatos teljesítményoptimalizálás érdekében javasoljuk, hogy engedélyezze az automatikus hangolást. Ez a beépített intelligencia funkció folyamatosan figyeli az adatbázist, és automatikusan hangolja az adatbázisokat, és a legjobban teljesítő lekérdezés-végrehajtási terveket hozza létre az adatbázisokhoz.

Adatbázis-hatókörű konfigurációs érték módosítása

Mi történik

Ez az észlelhető teljesítményminta azt a feltételt jelzi, amelyben az adatbázis-hatókörű konfiguráció módosítása teljesítményregressziót okoz, amely az adatbázis elmúlt hét napos számítási feladatainak viselkedéséhez képest észlelhető. Ez a minta azt jelzi, hogy az adatbázis-hatókörű konfiguráció legutóbbi módosítása nem tűnik előnyösnek az adatbázis teljesítményének.

Az adatbázis-hatókörű konfigurációs módosítások minden egyes adatbázishoz beállíthatók. Ezt a konfigurációt eseti alapon használjuk az adatbázis egyéni teljesítményének optimalizálásához. Az egyes adatbázisokhoz a következő beállítások konfigurálhatók: MAXDOP, LEGACY_CARDINALITY_ESTIMATION, PARAMETER_SNIFFING, QUERY_OPTIMIZER_HOTFIXES és CLEAR PROCEDURE_CACHE.

Hibaelhárítás

A diagnosztikai napló olyan adatbázis-hatókörű konfigurációs módosításokat ad ki, amelyek a közelmúltban teljesítménycsökkenést okoztak az előző hétnapos számítási feladat viselkedéséhez képest. A konfiguráció módosításait visszaállíthatja az előző értékekre. Az értékeket érték szerint is hangolhatja, amíg el nem éri a kívánt teljesítményszintet. Az adatbázis-hatókör konfigurációs értékeit megfelelő teljesítménnyel másolhatja egy hasonló adatbázisból. Ha nem tudja elhárítani a teljesítményt, térjen vissza az alapértelmezett értékekre, és próbálja meg finomhangolni az alapkonfigurációtól kezdve.

Az adatbázis-hatókörű konfiguráció és a T-SQL-szintaxis módosításáról további információt az adatbázis-hatókörű konfiguráció módosítása (Transact-SQL) című témakörben talál.

Lassú ügyfél

Mi történik

Ez az észlelhető teljesítményminta azt a feltételt jelzi, amelyben az adatbázist használó ügyfél nem tudja olyan gyorsan felhasználni az adatbázis kimenetét, amikor az adatbázis elküldi az eredményeket. Mivel az adatbázis nem tárolja a végrehajtott lekérdezések eredményeit egy pufferben, lelassul, és megvárja, amíg az ügyfél felhasználja a továbbított lekérdezési kimeneteket a folytatás előtt. Ez a feltétel olyan hálózathoz is kapcsolódhat, amely nem elég gyors ahhoz, hogy kimeneteket továbbítson az adatbázisból a fogyasztó ügyfélnek.

Ez a feltétel csak akkor jön létre, ha a rendszer teljesítményregressziót észlel az adatbázis elmúlt hét napos számítási feladatainak viselkedéséhez képest. Ez a teljesítményprobléma csak akkor észlelhető, ha a korábbi teljesítményhez képest statisztikailag jelentős teljesítménycsökkenés történik.

Hibaelhárítás

Ez az észlelhető teljesítményminta egy ügyféloldali feltételt jelez. Hibaelhárításra van szükség az ügyféloldali alkalmazásban vagy az ügyféloldali hálózaton. A diagnosztikai napló olyan lekérdezési kivonatokat és várakozási időket ad ki, amelyek úgy tűnik, hogy a legtöbbet várják az ügyfél számára, hogy az elmúlt két órán belül felhasználja őket. Ezeket az információkat használhatja a hibaelhárítás alapjaként.

Az alkalmazás teljesítményét optimalizálhatja ezeknek a lekérdezéseknek a felhasználásához. Megfontolhatja a hálózati késés lehetséges problémáit is. Mivel a teljesítménycsökkenéssel kapcsolatos probléma az elmúlt hét napos teljesítménykonfiguráció változásán alapult, megvizsgálhatja, hogy a legutóbbi alkalmazás- vagy hálózati feltételváltozások okozták-e ezt a teljesítményregressziós eseményt.

Tarifacsomagok leminősítése

Mi történik

Ez az észlelhető teljesítményminta azt a feltételt jelzi, amelyben az adatbázis-előfizetés tarifacsomagja le lett csökkentve. Az adatbázis számára elérhető erőforrások (DTU-k) csökkentése miatt a rendszer az adatbázis jelenlegi teljesítményének csökkenését észlelte az elmúlt hét napos alapkonfigurációhoz képest.

Emellett előfordulhat, hogy az adatbázis-előfizetés tarifacsomagját leminősítették, majd rövid időn belül magasabb szintre frissítették. Ennek az ideiglenes teljesítménycsökkenésnek az észlelése a diagnosztikai napló részletes szakaszában jelenik meg tarifacsomag-visszalépésként és frissítésként.

Hibaelhárítás

Ha csökkentette a tarifacsomagot, és így az elérhető DTU-k, és elégedett a teljesítménnyel, semmit sem kell tennie. Ha csökkentette a tarifacsomagot, és nincs megelégedve az adatbázis teljesítményével, csökkentse az adatbázis számítási feladatait, vagy fontolja meg a tarifacsomag magasabb szintre való növelését.

Javasolt hibaelhárítási folyamat

Kövesse a folyamatábrát egy ajánlott megközelítéshez a teljesítményproblémák intelligens Elemzések használatával történő elhárításához.

Az Intelligens Elemzések az Azure Portalon keresztül érheti el az Azure SQL Analytics szolgáltatással. Próbálja meg megkeresni a bejövő teljesítményriasztást, és jelölje ki. Azonosítsa, mi történik az észlelési oldalon. Figyelje meg a probléma, a lekérdezés szövegének, a lekérdezési idő trendjeinek és az incidensek alakulásának alapvető okainak elemzését. Próbálja meg megoldani a problémát az Intelligens Elemzések javaslattal a teljesítményproblémák enyhítésére.

Tipp.

A PDF-verzió letöltéséhez válassza ki a folyamatábrát.

Az intelligens Elemzések általában egy órányi időre van szükség a teljesítményproblémák kiváltó okának elemzéséhez. Ha nem találja a problémát az Intelligens Elemzések, és kritikus fontosságú Önnek, a Lekérdezéstár használatával manuálisan azonosíthatja a teljesítményproblémának a kiváltó okát. (Ezek a problémák általában egy óránál rövidebbek.) További információ: Teljesítmény monitorozása a Lekérdezéstár használatával.

További lépések

• Ismerje meg az intelligens Elemzések fogalmait.
• Használja az Intelligens Elemzések teljesítménydiagnosztikai naplót.
• Monitorozás az Azure SQL Analytics használatával.
• Megtudhatja, hogyan gyűjthet és felhasználhat naplóadatokat az Azure-erőforrásokból.