Megosztás a következőn keresztül:

Mintaadatbázis a memóriabeli OLTP-hez

A következőkre vonatkozik:SQL ServerAzure SQL Database

Áttekintés

Ez a minta a memórián belüli OLTP funkciót mutatja be. Megjeleníti a memóriaoptimalizált táblákat és a natívan lefordított tárolt eljárásokat, és a memóriabeli OLTP teljesítménybeli előnyeinek bemutatására használható.

Jegyzet

Az SQL Server 2014 (12.x) számára készült cikk megtekintéséhez lásd a AdventureWorks kiterjesztéseit, az In-Memory OLTP demonstrálására.

A minta az AdventureWorks2025 adatbázis öt tábláját migrálja memóriaoptimalizáltra, és tartalmaz egy bemutató számítási feladatot az értékesítési rendelések feldolgozásához. Ezzel a bemutató számítási feladattal megtekintheti a memóriabeli OLTP kiszolgálón való használatának teljesítménybeli előnyeit.

A minta leírásában a táblák memóriabeli OLTP-re való migrálásának kompromisszumait tárgyaljuk, hogy figyelembe vegyék a memóriaoptimalizált táblákhoz (még) nem támogatott funkciókat.

A minta dokumentációja a következőképpen van strukturálva:

Előfeltételek

  • SQL Server 2016 (13.x)

  • A teljesítményteszteléshez használjon egy olyan kiszolgálót, amely specifikációiban hasonló az éles környezethez. Ebben a példában legalább 16 GB memóriával kell rendelkeznie az SQL Server számára. A memóriabeli OLTP hardverével kapcsolatos általános irányelvekért tekintse meg a következő blogbejegyzést: Hardveres megfontolások az SQL Server In-Memory OLTP-hez

A memóriában lévő OLTP-minta telepítése az AdventureWorks alapján

A minta telepítéséhez kövesse az alábbi lépéseket:

  1. Töltse le AdventureWorks2016_EXT.bak és SQLServer2016Samples.zip a következő fájlból: https://github.com/microsoft/sql-server-samples/releases/tag/adventureworks egy helyi mappába, például C:\Temp.

  2. Állítsa vissza az adatbázis biztonsági mentését a Transact-SQL vagy az SQL Server Management Studióval:

    1. Azonosítsa az adatfájl célmappájának és fájlnevét, például:

      H:\DATA\AdventureWorks2022_Data.mdf

    2. Azonosítsa a naplófájl célmappát és fájlnevét, például:

      I:\DATA\AdventureWorks2022_log.ldf
      1. A naplófájlt az adatfájltól eltérő meghajtóra kell helyezni, ideális esetben alacsony késleltetésű meghajtóra, például SSD- vagy PCIe-tárolóra a maximális teljesítmény érdekében.

    Példa T-SQL-szkriptre:

    RESTORE DATABASE [AdventureWorks2022]
  FROM DISK = N'C:\temp\AdventureWorks2022.bak'
    WITH FILE = 1,
  MOVE N'AdventureWorks2022_Data' TO N'h:\DATA\AdventureWorks2022_Data.mdf',
  MOVE N'AdventureWorks2022_Log' TO N'i:\DATA\AdventureWorks2022_log.ldf',
  MOVE N'AdventureWorks2022_mod' TO N'h:\data\AdventureWorks2022_mod'
 GO

  3. A mintaszkriptek és számítási feladatok megtekintéséhez csomagolja ki a fájlt SQLServer2016Samples.zip egy helyi mappába. A számítási feladat futtatásával kapcsolatos utasításokért tekintse meg a fájlt In-Memory OLTP\readme.txt .

A mintatáblák és eljárások leírása

A minta új táblákat hoz létre a termékekhez és az értékesítési rendelésekhez a AdventureWorks2025meglévő táblái alapján. Az új táblák sémája hasonló a meglévő táblákhoz, néhány különbséggel, amint azt a szakasz későbbi részében ismertetik.

Az új memóriaoptimalizált táblák az utótagot _inmemtartalmazzák. A minta tartalmazza az utótagot _ondisk tartalmazó megfelelő táblákat is – ezekkel a táblák használatával egy-az-egyhez összehasonlítani lehet a memóriaoptimalizált táblák és a lemezalapú táblák teljesítményét a rendszeren.

A számítási feladatban a teljesítmény-összehasonlításhoz használt memóriaoptimalizált táblák teljes mértékben tartósak és teljes mértékben naplózhatók. Nem feláldozzák a tartósságot vagy a megbízhatóságot a teljesítménynövekedés eléréséhez.

Minta célfeladata az értékesítési rendelések feldolgozása, ahol figyelembe vesszük a termékekre és kedvezményekre vonatkozó információkat is. Ennek érdekében a SalesOrderHeader, SalesOrderDetail, Product, SpecialOfferés SpecialOfferProducttáblákat használjuk.

Két új tárolt eljárás, Sales.usp_InsertSalesOrder_inmem és Sales.usp_UpdateSalesOrderShipInfo_inmemhasználatával szúrhat be értékesítési rendeléseket, és frissítheti egy adott értékesítési rendelés szállítási adatait.

Az új séma Demo segédtáblákat és tárolt eljárásokat tartalmaz a bemutató számítási feladatok végrehajtásához.

Az In-Memory OLTP-minta a következő objektumokat adja hozzá AdventureWorks2025:

A minta által hozzáadott táblák

Az új táblák

Sales.SalesOrderHeader_inmem

  • Az értékesítési rendelések fejlécadatai. Minden értékesítési rendelésnek egy sora van ebben a táblában.

Sales.SalesOrderDetail_inmem

  • Az értékesítési rendelések részletei. Egy értékesítési rendelés minden sortétele egy sort tartalmaz ebben a táblában.

Sales.SpecialOffer_inmem

  • Információk a különleges ajánlatokról, beleértve az egyes különleges ajánlatokhoz társított kedvezmény százalékos arányát.

Sales.SpecialOfferProduct_inmem

  • Referenciatábla a különleges ajánlatok és a termékek között. Minden különleges ajánlatban nulla vagy több termék szerepelhet, és minden termék nulla vagy több különleges ajánlatban is szerepelhet.

Production.Product_inmem

  • A termékekre vonatkozó információk, beleértve a listaárukat is.

Demo.DemoSalesOrderDetailSeed

  • A bemutató számítási feladatban értékesítési mintarendelések létrehozásához használható.

A táblák lemezalapú változatai:

  • Sales.SalesOrderHeader_ondisk

  • Sales.SalesOrderDetail_ondisk

  • Sales.SpecialOffer_ondisk

  • Sales.SpecialOfferProduct_ondisk

  • Production.Product_ondisk

Különbségek az eredeti lemezalapú és az új memóriaoptimalizált táblák között

A minta által bevezetett új táblák általában ugyanazokat az oszlopokat és adattípusokat használják, mint az eredeti táblák. Van azonban néhány különbség. Felsoroljuk az ebben a szakaszban szereplő különbségeket, valamint a változások indoklását.

Sales.SalesOrderHeader_inmem

  • Memóriaoptimalizált táblák esetében az alapértelmezett korlátozások támogatottak, és a legtöbb alapértelmezett korlátozást migráltuk. Az eredeti Sales.SalesOrderHeader tábla azonban két alapértelmezett korlátozást tartalmaz, amelyek lekérik az aktuális dátumot a OrderDate és a ModifiedDateoszlopra vonatkozóan. A nagy átviteli sebességű megrendelések nagy egyidejűséggel történő feldolgozása során minden globális erőforrás versengésgé válhat. A rendszeridő egy ilyen globális erőforrás, és megfigyeltük, hogy szűk keresztmetszetet jelenthet az értékesítési rendeléseket beszúró In-Memory OLTP számítási feladatok futtatásakor, különösen akkor, ha a rendszeridőt le kell kérni az értékesítési rendelés fejlécének több oszlopához és az értékesítési rendelés részleteihez. A probléma megoldásához a rendszeridőt csak egyszer kell beolvasni minden beszúrt értékesítési rendeléshez, és ezt az értéket a tárolt eljárás SalesOrderHeader_inmemSalesOrderDetail_inmem és Sales.usp_InsertSalesOrder_inmemdátum/idő oszlopaihoz kell használni.

  • Alias felhasználó által definiált adattípusok (UDT-k) – Az eredeti tábla két alias UDT-t dbo.OrderNumber és dbo.AccountNumberhasznál a PurchaseOrderNumber és AccountNumberoszlopokhoz. Az SQL Server 2016 (13.x) nem támogatja az alias UDT-t a memóriaoptimalizált táblákhoz, így az új táblák nvarchar(25) és nvarchar(15) rendszeradattípusokat használnak.

  • Null értékű oszlopok az indexkulcsokban – Az eredeti táblában az oszlop SalesPersonID null értékű, míg az új táblákban az oszlop nem null értékű, és alapértelmezett értékkorláttal rendelkezik (-1). Ennek a körülménynek az az oka, hogy a memóriaoptimalizált táblák indexei nem tartalmazhatnak null értékű oszlopokat az indexkulcsban; -1 ebben az esetben a NULL helyettesítője.

  • Számított oszlopok – A kiszámított oszlopok SalesOrderNumberTotalDue nincsenek megadva, mivel az SQL Server 2016 (13.x) nem támogatja a memóriaoptimalizált táblák számított oszlopait. Az új nézet Sales.vSalesOrderHeader_extended_inmem a SalesOrderNumber és a TotalDueoszlopokat tükrözi. Ezért ezt a nézetet akkor használhatja, ha ezekre az oszlopokra van szükség.

    • A következőkre vonatkozik: SQL Server 2017 (14.x). Az SQL Server 2017 -től (14.x) kezdődően a számított oszlopok memóriaoptimalizált táblákban és indexekben támogatottak.

  • az SQL Server 2016(13.x) memóriaoptimalizált tábláihoz idegenkulcs-korlátozások támogatottak, de csak akkor, ha a hivatkozott táblák memóriaoptimalizáltak is. A memóriaoptimalizált táblákra hivatkozó idegen kulcsok a migrált táblákban maradnak, míg a többi idegen kulcs hiányzik. Emellett a példában szereplő számítási feladat egy forró tábla, és az idegen kulcsokra vonatkozó megkötések további feldolgozást igényelnek az összes DML-művelethez, mivel kereséseket igényel az összes többi táblában, amelyekre ezek a megkötések hivatkoznak. Ezért a feltételezés az, hogy az alkalmazás biztosítja a Sales.SalesOrderHeader_inmem tábla hivatkozási integritását, és a hivatkozási integritás nem lesz érvényesítve sorok beszúrásakor.

  • Rowguid – A rowguid oszlop kihagyva van. Bár a uniqueidentifier memóriaoptimalizált táblák esetében támogatott, a ROWGUIDCOL beállítás nem támogatott az SQL Server 2016-ban (13.x). Az ilyen típusú oszlopokat általában egyesítési replikációhoz vagy fájlstream oszlopokkal rendelkező táblákhoz használják. Ez a minta egyiket sem tartalmazza.

Értékesítés.ÉrtékesítésiRészlet

  • Alapértelmezett kényszerek - a rendszerdátumot/időt igénylő alapértelmezett kényszer, hasonlóan SalesOrderHeader-hez, nem migrálódik. Ehelyett az értékesítési rendeléseket beszúró tárolt eljárás gondoskodik az aktuális rendszerdátum/idő beszúrásáról az első beszúráskor.

  • Számított oszlopok – a számított oszlop LineTotal nem lett migrálva, mivel a számítási oszlopok nem támogatottak memóriaoptimalizált táblákkal az SQL Server 2016-ban (13.x). Az oszlop eléréséhez használja a Sales.vSalesOrderDetail_extended_inmem nézetet.

  • Rowguid – A rowguid oszlop ki van hagyva. További részletekért tekintse meg a SalesOrderHeadertáblázat leírását.

Gyártás.Termék

  • Alias UDT-k – az eredeti tábla a felhasználó által definiált adattípust dbo.Flaghasználja, amely egyenértékű a rendszer adattípus-bitével. A migrált tábla ehelyett a bit adattípust használja.

  • Rowguid – A rowguid oszlop ki van hagyva. További részletekért tekintse meg a SalesOrderHeadertáblázat leírását.

Értékesítés.KülönlegesAjánlat

  • Rowguid – A rowguid oszlop ki van hagyva. További részletekért tekintse meg a SalesOrderHeadertáblázat leírását.

Értékesítés.KülönlegesAjánlatTermék

  • Rowguid – A rowguid oszlop ki van hagyva. További részletekért tekintse meg a SalesOrderHeadertáblázat leírását.

A memóriaoptimalizált táblák indexeinek szempontjai

A memóriaoptimalizált táblák alapindexe a NEMCLUSTERED index, amely támogatja a pontkereséseket (indexkeresés az egyenlőségi predikátumon), a tartományvizsgálatokat (az indexek egyenlőtlenségi predikátumban való keresését), a teljes indexvizsgálatokat és a rendezett vizsgálatokat. Emellett a NEMCLUSTERED indexek támogatják az indexkulcs vezető oszlopaiban való keresést. Valójában a memóriaoptimalizált NEMCLUSTERED indexek támogatják a lemezalapú NEMCLUSTERED indexek által támogatott összes műveletet, az egyetlen kivétel a visszamenőleges vizsgálat. Ezért a NEMCLUSTERED indexek használata biztonságos választás az indexekhez.

A HASH-indexek a számítási feladat további optimalizálására használhatók. Pontkeresésekhez és sorbeszúrásokhoz vannak optimalizálva. Figyelembe kell azonban venni, hogy nem támogatják a tartományvizsgálatokat, a rendezett vizsgálatokat és a vezető indexkulcs-oszlopokban való keresést. Ezért az indexek használatakor körültekintően kell eljárni. Emellett meg kell adni a bucket_count elemet a létrehozáskor. Általában az indexkulcsértékek számának 1-2-szeresét kell beállítani, de a túlbecsülés általában nem jelent problémát.

További információ:

A migrált táblák indexei a bemutató értékesítési rendelés feldolgozási terhelésre lettek hangolva. A számítási feladat a Sales.SalesOrderHeader_inmem és Salestáblák beszúrásaira és pontkereséseire támaszkodik.SalesOrderDetail_inmem, és a Production.Product_inmem és Sales.SpecialOffer_inmemtáblák elsődleges kulcsoszlopaira vonatkozó pontkeresésekre is támaszkodik.

Sales.SalesOrderHeader_inmem három indexe van, amelyek teljesítménybeli okokból mind hash-indexek, és mivel a számítási feladathoz nincs szükség rendezett vagy tartományvizsgálatra.

  • HASH-index (SalesOrderID): bucket_count mérete 10 millió (16 millióra kerekítve), mivel az értékesítési rendelések várható száma 10 millió

  • HASH index a (SalesPersonID): a bucket_count értéke 1 millió. A megadott adatkészletben nincs sok értékesítő. De ez a nagy bucket_count lehetővé teszi a jövőbeli növekedést. Emellett nem kell teljesítménybírságot fizetnie a pontkeresésekért, ha a bucket_count túlméretezett.

  • HASH index a (CustomerID): a bucket_count értéke 1 millió. A megadott adatkészletnek nincs sok ügyfele, de ez lehetővé teszi a jövőbeli növekedést.

Sales.SalesOrderDetail_inmem három indexe van, amelyek teljesítménybeli okokból mind hash-indexek, és mivel a számítási feladathoz nincs szükség rendezett vagy tartományvizsgálatra.

  • HASH-index bekapcsolva (SalesOrderID, SalesOrderDetailID): ez az elsődleges kulcsindex, és bár a (SalesOrderID, SalesOrderDetailID) keresések ritkák, kivonatindex használatával felgyorsítja a sorbeszúrásokat. A bucket_count mérete 50 millió (67 millióra kerekítve): az értékesítési rendelések várható száma 10 millió, és ez úgy van méretezve, hogy megrendelésenként átlagosan öt tételt tartalmaz

  • HASH-index a (SalesOrderID): az értékesítési rendelés szerinti keresések gyakoriak: az egyetlen rendelésnek megfelelő összes sorelemet meg szeretné keresni. bucket_count mérete 10 millió (16 millióra kerekítve), mivel az értékesítési rendelések várható száma 10 millió

  • HASH index a (ProductID): a bucket_count értéke 1 millió. A megadott adatkészlet nem rendelkezik sok termékkel, de ez lehetővé teszi a jövőbeli növekedést.

Production.Product_inmem három indexe van

  • HASH-index a (ProductID): a ProductID keresései a demó munkaterhelés kritikus útvonalán találhatók, ezért ez egy hash index.

  • A NEMKLASZTEREZETT index használata (Name): ez lehetővé teszi a terméknevek rendezett vizsgálatát

  • NEMCLUSTERED index bekapcsolva (ProductNumber): ez lehetővé teszi a termékszámok rendezett vizsgálatát

Sales.SpecialOffer_inmem egy HASH-indexe van (SpecialOfferID): a speciális ajánlatok pontkeresései a bemutató számítási feladat kritikus részében találhatók. A bucket_count mérete 1 millió, hogy lehetővé tegye a jövőbeli növekedést.

Sales.SpecialOfferProduct_inmem nem szerepel a bemutató terhelésben, ezért nincs nyilvánvaló szükség arra, hogy hash indexeket használjunk ezen a táblán a terhelés optimalizálásához – a (SpecialOfferID, ProductID) és (ProductID) indexek nem kluszterezettek.

Az előző példában a gyűjtési számlálók túlméretezettek, de az SalesOrderHeader_inmem és SalesOrderDetail_inmem indexekhez tartozó gyűjtési számlálók mindössze 10 millió értékesítési rendeléshez vannak méretezve. Ez lehetővé tette a minta telepítését alacsony memória rendelkezésre állású rendszerekre, bár ezekben az esetekben a demo számítási feladat memóriahiányos hibával meghiúsul. Ha 10 millió értékesítési rendelés fölé szeretne méretezni, nyugodtan növelje a gyűjtők számát ennek megfelelően.

A memóriakihasználtság szempontjai

A mintaadatbázis memóriakihasználtságát a bemutató számítási feladat futtatása előtt és után is a memóriaoptimalizált táblák memóriakihasználtságacímű szakasz ismerteti.

A minta által hozzáadott tárolt eljárások

Az értékesítési rendelés beszúrásának és a szállítási adatok frissítésének két legfontosabb tárolt eljárása a következő:

  • Sales.usp_InsertSalesOrder_inmem

    • Beszúr egy új értékesítési rendelést az adatbázisba, és az adott értékesítési rendeléshez tartozó SalesOrderID adja ki. Bemeneti paraméterekként az értékesítési rendelés fejlécének és a rendelés sortételeinek adatait veszi át.

    • Kimeneti paraméter:

      • @SalesOrderID int – az SalesOrderID imént beszúrt értékesítési rendelés

    • Bemeneti paraméterek (kötelező):

      • @DueDatedatetime2
      • @CustomerIDint
      • @BillToAddressIDint
      • @ShipToAddressIDint
      • @ShipMethodIDint
      • Sales.SalesOrderDetailType_inmem@SalesOrderDetails - táblaértékű paraméter (TVP), amely a rendelés sortételeit tartalmazza

    • Bemeneti paraméterek (nem kötelező):

      • @Statustinyint
      • @OnlineOrderFlagbit
      • @PurchaseOrderNumbernvarchar(25)
      • @AccountNumbernvarchar(15)
      • @SalesPersonIDint
      • @TerritoryIDint
      • @CreditCardIDint
      • @CreditCardApprovalCodevarchar(15)
      • @CurrencyRateIDint
      • @Commentnvarchar(128)

  • Sales.usp_UpdateSalesOrderShipInfo_inmem

    • Frissítse egy adott értékesítési rendelés szállítási adatait. Ez az értékesítési rendelés összes sortételének szállítási adatait is frissíti.

    • Ez egy burkoló eljárás a natívan lefordított tárolt eljárásokhoz, Sales.usp_UpdateSalesOrderShipInfo_native újrapróbálkozásos logikával, hogy kezelni lehessen a (váratlan) lehetséges ütközéseket az azonos sorrendet frissítő egyidejű tranzakciókkal. További információért lásd: újrapróbálkozási logika.

  • Sales.usp_UpdateSalesOrderShipInfo_native

    • Ez a natívan lefordított tárolt eljárás az, amely ténylegesen feldolgozza a szállítási információk frissítését. A Sales.usp_UpdateSalesOrderShipInfo_inmem burkoló tárolt eljárásból kell meghívni. Ha az ügyfél képes kezelni a hibákat, és újrapróbálkozó logikát implementál, ezt az eljárást közvetlenül hívhatja meg a burkoló tárolt eljárás használata helyett.

A demo számítási feladathoz az alábbi tárolt eljárást használja a rendszer.

  • Demo.usp_DemoReset

    • Alaphelyzetbe állítja a demót a SalesOrderHeader és a SalesOrderDetail táblák kiürítésével és újra feltöltésével.

Az alábbi tárolt eljárások a memóriaoptimalizált táblákba való beszúrásra és törlésre szolgálnak, miközben garantálják a tartomány és a hivatkozási integritást.

  • Production.usp_InsertProduct_inmem
  • Production.usp_DeleteProduct_inmem
  • Sales.usp_InsertSpecialOffer_inmem
  • Sales.usp_DeleteSpecialOffer_inmem
  • Sales.usp_InsertSpecialOfferProduct_inmem

Végül a következő tárolt eljárást használjuk a tartomány és a hivatkozási integritás ellenőrzéséhez.

  1. dbo.usp_ValidateIntegrity

    • Nem kötelező paraméter: @object_id – Az objektum azonosítója az integritás ellenőrzéséhez

    • Ez az eljárás az ellenőrizni kívánt integritási szabályok dbo.DomainIntegrity, dbo.ReferentialIntegrityés dbo.UniqueIntegrity tábláira támaszkodik, a minta ezeket a táblákat az ellenőrzés, az idegen kulcs és az AdventureWorks2025 adatbázis eredeti tábláira vonatkozó egyedi korlátozások alapján tölti ki.

    • A dbo.usp_GenerateCKCheck, dbo.usp_GenerateFKCheckés dbo.GenerateUQCheck segítő eljárásokra támaszkodik az integritás-ellenőrzések végrehajtásához szükséges T-SQL létrehozásához.

Teljesítménymérések a tesztterhelés használatával

Az ostress egy parancssori eszköz, amelyet a Microsoft CSS SQL Server támogatási csapata fejlesztett ki. Ez az eszköz lekérdezések végrehajtására vagy tárolt eljárások párhuzamos futtatására használható. Konfigurálhatja, hogy hány szál futtasson párhuzamosan egy adott T-SQL-utasítást, és megadhatja, hogy hányszor kell végrehajtani az utasítást ezen a szálon; az ostress felpörgeti a szálakat, és párhuzamosan hajtja végre az utasítást az összes szálon. Miután az összes szál végrehajtása befejeződött, az ostress az összes szál végrehajtásához szükséges időt jelenti.

Ostress telepítése

az ostress a Jelentésjelölő nyelv (RML) segédprogramok részeként van telepítve; Nincs különálló telepítés az ostress számára.

Telepítési lépések:

  1. Töltse le és futtassa az RML-segédprogramok x64-telepítőcsomagját a következő oldalról: AZ RML letöltése AZ SQL Serverhez

  2. Ha van egy párbeszédpanel, amely azt jelzi, hogy bizonyos fájlok használatban vannak, válassza a "Folytatás" lehetőséget

Futtasd az Ostress-t

Az Ostress parancs a parancssorból fut. Az eszközt az RML-segédprogramok részeként telepített RML cmd parancssorból lehet futtatni.

Az RML-parancsmag parancssorának megnyitásához kövesse az alábbi utasításokat:

Windows rendszerben nyissa meg a Start menüt a Windows billentyű kiválasztásával, és írja be a rml. Válassza az RML cmd prompt lehetőséget, amely szerepel a keresési eredmények listájában.

Győződjön meg arról, hogy a parancssor az RML-segédprogramok telepítési mappájában található.

Az ostress parancssori opciói láthatók, ha ostress.exe parancssori opciók nélkül fut. Az ostress ezzel a mintával való futtatásához a következő főbb lehetőségeket érdemes figyelembe venni:

Lehetőség Description
-S A csatlakozni kívánt SQL Server-példány neve.
-E Csatlakozás Windows-hitelesítés használatával (alapértelmezett); ha SQL Server-hitelesítést használ, a -U és -P opciókkal adhatja meg a felhasználónevet és a jelszót.
-d Az adatbázis neve, ebben a példában AdventureWorks2025.
-Q A végrehajtandó T-SQL-utasítás.
-n Az egyes bemeneti fájlokat/lekérdezéseket feldolgozó kapcsolatok száma.
-r Az egyes kapcsolatok iterációinak száma az egyes bemeneti fájlok/lekérdezések végrehajtásához.

Demo számítási feladat

A demo számítási feladatban használt fő tárolt eljárás a Sales.usp_InsertSalesOrder_inmem/ondisk. Az alábbi példában szereplő szkript egy táblaértékű paramétert (TVP) hoz létre mintaadatokkal, és meghívja az eljárást egy öt sorelemből álló értékesítési rendelés beszúrására.

Az ostress eszközzel párhuzamosan hajthatja végre a tárolt eljáráshívásokat, hogy egyidejűleg szimulálja az értékesítési rendeléseket beszúró ügyfeleket.

Az Demo.usp_DemoResetminden stresszteszt végrehajtása után állítsa vissza a bemutatót. Ez az eljárás törli a memóriaoptimalizált táblák sorait, csonkolja a lemezalapú táblákat, és végrehajt egy adatbázis-ellenőrzőpontot.

A következő szkript egyidejűleg fut egy értékesítési rendelés feldolgozási számítási feladatának szimulálásához:

DECLARE @i AS INT = 0, @od AS Sales.SalesOrderDetailType_inmem, @SalesOrderID AS INT, @DueDate AS DATETIME2 = sysdatetime(), @CustomerID AS INT = RAND() * 8000, @BillToAddressID AS INT = RAND() * 10000, @ShipToAddressID AS INT = RAND() * 10000, @ShipMethodID AS INT = (RAND() * 5) + 1;
INSERT INTO @od
SELECT OrderQty,
       ProductID,
       SpecialOfferID
FROM Demo.DemoSalesOrderDetailSeed
WHERE OrderID = CAST ((RAND() * 106) + 1 AS INT);
WHILE (@i < 20)
    BEGIN
        EXECUTE Sales.usp_InsertSalesOrder_inmem
            @SalesOrderID OUTPUT,
            @DueDate,
            @CustomerID,
            @BillToAddressID,
            @ShipToAddressID,
            @ShipMethodID,
            @od;
        SET @i + = 1;
    END

Ezzel a szkripttel minden létrehozott mintarendelés 20-szor lesz beszúrva, 20 tárolt eljáráson keresztül, amelyet egy WHILE ciklusban hajtanak végre. A hurok arra szolgál, hogy figyelembe vegye azt a tényt, miszerint az adatbázist a mintarend összeállítására használják. Tipikus produkciós környezetekben a középszintű alkalmazás létrehozza az értékesítési rendelés beszúrásához szükséges adatokat.

Az előző szkript az értékesítési rendeléseket memóriaoptimalizált táblákba szúrja be. Az értékesítési rendelések lemezalapú táblákba történő beszúrására szolgáló szkriptet úgy kapjuk meg, hogy a két előforduló _inmem helyébe _ondisk kerül.

Az ostress eszközzel több egyidejű kapcsolattal hajtjuk végre a szkripteket. A paramétert -n a kapcsolatok számának szabályozására, a paramétert r pedig arra használjuk, hogy a szkript hányszor legyen végrehajtva az egyes kapcsolatokon.

A számítási feladat futtatása

A nagy léptékű teszteléshez 10 millió értékesítési rendelést szúrunk be 100 kapcsolat használatával. Ez a teszt ésszerűen működik egy szerény kiszolgálón (például 8 fizikai, 16 logikai magon) és alapszintű SSD-tárolón a napló számára. Ha a teszt nem működik megfelelően a hardveren, tekintse meg a lassan futó tesztek hibaelhárítása című szakaszt. Ha csökkenteni szeretné a teszt terhelését, csökkentse a kapcsolatok számát a paraméter -nmódosításával. Ha például a kapcsolat számát 40-re szeretné csökkenteni, módosítsa a paramétert a következőre -n100-n40: .

A számítási feladat teljesítményméréseként a számítási feladat futtatása után jelentett ostress.exe eltelt időt használjuk.

Az alábbi utasítások és mérések olyan számítási feladatot használnak, amely 10 millió értékesítési rendelést szúr be. Ha egy 1 millió értékesítési rendelést beszúró leskálázott számítási feladat futtatására vonatkozó utasításokat szeretne, tekintse meg az In-Memory OLTP\readme.txt archívum részét képező utasításokatSQLServer2016Samples.zip.

Memóriaoptimalizált táblák

Először a számítási feladat memóriaoptimalizált táblákon való futtatásával kezdjük. Az alábbi parancs 100 szálat nyit meg, mindegyik 5000 iterációt futtat. Minden iteráció 20 értékesítési rendelést szúr be külön tranzakciókba. Iterációnként 20 beszúrás van, hogy kompenzálja azt a tényt, hogy az adatbázis a beszúrni kívánt adatok létrehozására szolgál. Ez összesen 20 * 5 000 * 100 = 10 000 000 értékesítési rendelések beszúrásával.

Nyissa meg az RML cmd parancssorát, és hajtsa végre a következő parancsot:

Kattintson a Másolás gombra a parancs másolásához, majd illessze be az RML-segédprogramok parancssorába.

ostress.exe -n100 -r5000 -S. -E -dAdventureWorks2022 -q -Q"DECLARE @i AS INT = 0, @od AS Sales.SalesOrderDetailType_inmem, @SalesOrderID AS INT, @DueDate AS DATETIME2 = SYSDATETIME(), @CustomerID AS INT = RAND() * 8000, @BillToAddressID AS INT = RAND() * 10000, @ShipToAddressID AS INT = RAND() * 10000, @ShipMethodID AS INT = (RAND() * 5) + 1; INSERT INTO @od SELECT OrderQty, ProductID, SpecialOfferID FROM Demo.DemoSalesOrderDetailSeed WHERE OrderID = CAST ((RAND() * 106) + 1 AS INT); WHILE (@i < 20) BEGIN EXECUTE Sales.usp_InsertSalesOrder_inmem @SalesOrderID OUTPUT, @DueDate, @CustomerID, @BillToAddressID, @ShipToAddressID, @ShipMethodID, @od; SET @i + = 1; END"

Egy 8 fizikai (16 logikai) magot tartalmazó tesztkiszolgálón ez 2 percet és 5 másodpercet vett igénybe. Egy 24 fizikai (48 logikai) maggal rendelkező második tesztkiszolgálón ez 1 perc 0 másodpercig tartott.

Figyelje meg a processzorkihasználtságot a számítási feladat futtatása közben, például a feladatkezelő használatával. Láthatja, hogy a cpu-kihasználtság közel 100%. Ha nem ez a helyzet, akkor a napló IO-szűk keresztmetszete van, lásd a lassú futtatású tesztek hibaelhárítását is.

Lemezalapú táblák

Az alábbi parancs lemezalapú táblákon futtatja a számítási feladatot. Ez a számítási feladat végrehajtása eltarthat egy ideig, ami nagyrészt a rendszerben fellépő reteszes versengésnek köszönhető. A memóriaoptimalizált táblák reteszmentesek, ezért nem okoznak problémát.

Nyissa meg az RML cmd parancssorát, és hajtsa végre a következő parancsot:

Kattintson a Másolás gombra a parancs másolásához, majd illessze be az RML-segédprogramok parancssorába.

ostress.exe -n100 -r5000 -S. -E -dAdventureWorks2022 -q -Q"DECLARE @i AS INT = 0, @od AS Sales.SalesOrderDetailType_ondisk, @SalesOrderID AS INT, @DueDate AS DATETIME2 = sysdatetime(), @CustomerID AS INT = RAND() * 8000, @BillToAddressID AS INT = RAND() * 10000, @ShipToAddressID AS INT = RAND() * 10000, @ShipMethodID AS INT = (RAND() * 5) + 1; INSERT INTO @od SELECT OrderQty, ProductID, SpecialOfferID FROM Demo.DemoSalesOrderDetailSeed WHERE OrderID = CAST ((RAND() * 106) + 1 AS INT); WHILE (@i < 20) BEGIN EXECUTE Sales.usp_InsertSalesOrder_ondisk @SalesOrderID OUTPUT, @DueDate, @CustomerID, @BillToAddressID, @ShipToAddressID, @ShipMethodID, @od; SET @i + = 1; END"

Egy 8 fizikai (16 logikai) maggal rendelkező tesztkiszolgálón ez 41 percet és 25 másodpercet vett igénybe. Egy 24 fizikai (48 logikai) maggal rendelkező második tesztkiszolgálón ez 52 percet és 16 másodpercet vett igénybe.

A memóriaoptimalizált táblák és a lemezalapú táblák közötti teljesítménybeli különbség fő tényezője ebben a tesztben az, hogy lemezalapú táblák használatakor az SQL Server nem tudja teljes mértékben kihasználni a processzort. Ennek oka a reteszelési versengés: az egyidejű tranzakciók ugyanahhoz az adatoldalhoz próbálnak írni; A reteszek használatával biztosítható, hogy egyszerre csak egy tranzakció írjon egy oldalra. Az In-Memory OLTP-motor zármentes, az adatsorok pedig nem lapokba rendezve. Így az egyidejű tranzakciók nem blokkolják egymás beszúrásait, így az SQL Server teljes mértékben kihasználhatja a processzort.

Megfigyelheti a processzorkihasználtságot, miközben a számítási feladat fut, például a feladatkezelő használatával. A lemezalapú táblákban látható, hogy a processzor kihasználtsága messze nem 100%. Egy 16 logikai processzorral rendelkező tesztkonfigurációban a kihasználtság körülbelül 24%mutatna.

Opcionálisan megtekintheti a Teljesítményfigyelővel a másodpercenkénti reteszes várakozások számát, a teljesítményszámláló \SQL Server:Latches\Latch Waits/secsegítségével.

A bemutató visszaállítása

A bemutató alaphelyzetbe állításához nyissa meg az RML cmd parancssort, és hajtsa végre a következő parancsot:

ostress.exe -S. -E -dAdventureWorks2022 -Q"EXEC Demo.usp_DemoReset"

A hardvertől függően ez eltarthat néhány percig.

Minden bemutató futtatása után javasoljuk az alaphelyzetbe állítást. Mivel ez a számítási feladat csak beszúrásokat végez, minden futtatás több memóriát fogyaszt, ezért a rendszer alaphelyzetbe állítása szükséges, hogy elkerüljük a memória kifogyását. A futtatás után felhasznált memória mennyiségét a számítási feladat futtatása után. szakasz ismerteti.

Lassan futó tesztek hibaelhárítása

A teszteredmények jellemzően hardvertől és a tesztfuttatásban használt egyidejűségi szinttől függően változnak. Néhány dolog, amit meg kell keresni, ha az eredmények nem a várt módon jelennek meg:

  • Egyidejű tranzakciók száma: Ha a számítási feladatot egyetlen szálon futtatja, a teljesítménynövekedés In-Memory OLTP-vel valószínűleg kevesebb, mint 2X. A retesz körüli versengés csak akkor jelent jelentős problémát, ha magas az egyidejűség szintje.

  • Kevés mag érhető el az SQL Server számára: Ez azt jelenti, hogy a rendszerben alacsony az egyidejűség szintje, mivel csak annyi egyidejűleg hajthat végre tranzakciókat, mint amennyi mag elérhető az SQL számára.

    • Hibajelenség: ha a processzor kihasználtsága magas, amikor a számítási feladatot lemezalapú táblákon futtatja, ez azt jelenti, hogy nincs sok versengés, ami az egyidejűség hiányára mutat.

  • A naplómeghajtó sebessége: Ha a naplómeghajtó nem tud lépést tartani a tranzakciós átviteli sebesség szintjével a rendszerben, a munkaterhelés szűk keresztmetszetet képez a napló IO-n. Bár a naplózás hatékonyabb In-Memory OLTP-vel, ha a napló IO a szűk keresztmetszet, a lehetséges teljesítménynövekedés korlátozott.

    • Tünet: ha a processzor kihasználtsága nem éri el a 100%-ot, vagy nagyon ingadozó a számítási feladat memóriaoptimalizált táblákon való futtatásakor, lehetséges, hogy napló IO szűk keresztmetszet van. Ezt a Resource Monitor megnyitásával és a naplómeghajtó üzenetsorhosszának megtekintésével lehet megerősíteni.

Memória- és lemezterület-kihasználtság a mintában

Az alábbi példában a mintaadatbázis memória- és lemezterület-kihasználtságát tekintve ismertetjük, hogy mire számíthatunk. Az eredményeket egy 16 logikai maggal rendelkező tesztkiszolgálón is megjelenítjük.

Memóriakihasználtság a memóriaoptimalizált táblákhoz

Az adatbázis általános kihasználtsága

Az alábbi lekérdezés a rendszerben In-Memory OLTP teljes memóriakihasználtságának lekérésére használható.

SELECT type,
       name,
       pages_kb / 1024 AS pages_MB
FROM sys.dm_os_memory_clerks
WHERE type LIKE '%xtp%';

Pillanatkép az adatbázis létrehozása után:

típus név lapok_MB
MEMORYCLERK_XTP Alapértelmezett 94
MEMORYCLERK_XTP DB_ID_5 877
MEMORYCLERK_XTP Alapértelmezett 0
MEMORYCLERK_XTP Alapértelmezett 0

Az alapértelmezett memóriajegyzők rendszerszintű memóriastruktúrákat tartalmaznak, és viszonylag kicsik. A felhasználói adatbázis memóriakezelője, ebben az esetben az 5-ös azonosítójú adatbázis (a database_id példányonként eltérhet), körülbelül 900 MB.

Memória kihasználtsága táblánként

Az alábbi lekérdezés segítségével részletezheti az egyes táblák és indexeik memóriahasználatát:

SELECT object_name(t.object_id) AS [Table name],
       memory_allocated_for_table_kb,
       memory_allocated_for_indexes_kb
FROM sys.dm_db_xtp_table_memory_stats AS dms
     INNER JOIN sys.tables AS t
         ON dms.object_id = t.object_id
WHERE t.type = 'U';

Az alábbi táblázat a minta friss telepítésére vonatkozó lekérdezés eredményeit jeleníti meg:

Table name (Táblázat neve) memory_allocated_for_table_kb memory_allocated_for_indexes_kb
SpecialOfferProduct_inmem 64 3840
DemoSalesOrderHeaderSeed 1984 5504
SalesOrderDetail_inmem 15316 663552
DemoSalesOrderDetailSeed 64 10432
SpecialOffer_inmem 3 8192
SalesOrderHeader_inmem 7168 147456
Product_inmem 124 12352

Mint látható, a táblák meglehetősen kicsik: SalesOrderHeader_inmem körülbelül 7 MB, és SalesOrderDetail_inmem körülbelül 15 MB méretű.

Ami itt szembetűnő, az az indexekhez lefoglalt memória mérete a táblaadatok méretéhez képest. Ennek az az oka, hogy a minta kivonatindexei előzetesen nagyobb adatmennyiséghez vannak méretezve. A kivonatindexek rögzített méretűek, így méretük nem nő a táblázatban lévő adatok méretével.

Memóriakihasználtság a számítási feladat futtatása után

10 millió értékesítési rendelés beszúrása után a teljes memória kihasználtsága az alábbi lekérdezéshez hasonlóan néz ki:

SELECT type,
       name,
       pages_kb / 1024 AS pages_MB
FROM sys.dm_os_memory_clerks
WHERE type LIKE '%xtp%';

Itt van az eredmények összessége.

type name pages_MB
MEMORYCLERK_XTP Alapértelmezett 146
MEMORYCLERK_XTP DB_ID_5 7374
MEMORYCLERK_XTP Alapértelmezett 0
MEMORYCLERK_XTP Alapértelmezett 0

Mint látható, az SQL Server egy kicsit 8 GB alatt használja a mintaadatbázis memóriaoptimalizált tábláit és indexeit.

Egy példafuttatás után a táblázatonkénti részletes memóriahasználatot tekintve:

SELECT object_name(t.object_id) AS [Table name],
       memory_allocated_for_table_kb,
       memory_allocated_for_indexes_kb
FROM sys.dm_db_xtp_table_memory_stats AS dms
     INNER JOIN sys.tables AS t
         ON dms.object_id = t.object_id
WHERE t.type = 'U';

Itt van az eredmények összessége.

Table name memory_allocated_for_table_kb memory_allocated_for_indexes_kb
SalesOrderDetail_inmem 5113761 663552
DemoSalesOrderDetailSeed 64 10368
SpecialOffer_inmem 2 8192
SalesOrderHeader_inmem 1575679 147456
Product_inmem 111 12032
KülönlegesAjánlatTermék_inmem 64 3712
DemoSalesOrderHeaderSeed 1984 5504

Összesen körülbelül 6,5 GB adatot láthatunk. Az indexek mérete a táblában SalesOrderHeader_inmem , és SalesOrderDetail_inmem megegyezik az indexek méretével az értékesítési rendelések beszúrása előtt. Az index mérete nem változott, mert mindkét tábla kivonatindexeket használ, a kivonatindexek pedig statikusak.

A demo alaphelyzetbe állítása után

A tárolt eljárás Demo.usp_DemoReset használható a demó alaphelyzetbe állításához. Törli a táblákban SalesOrderHeader_inmem és SalesOrderDetail_inmem lévő adatokat, majd újra inicializálja az adatokat az eredeti táblák segítségével SalesOrderHeader és SalesOrderDetail.

Most, annak ellenére, hogy a táblák sorait törölték, ez nem jelenti azt, hogy a rendszer azonnal visszanyeri a memóriát. Az SQL Server szükség szerint helyreállítja a memóriát a memóriaoptimalizált táblák törölt soraiból a háttérben. Láthatja, hogy közvetlenül a demó alaphelyzetbe állítása után, a rendszeren nincs tranzakciós számítási feladat, a törölt sorok memóriája még nem lesz visszanyerve:

SELECT type,
       name,
       pages_kb / 1024 AS pages_MB
FROM sys.dm_os_memory_clerks
WHERE type LIKE '%xtp%';

Itt van az eredmények összessége.

type name pages_MB
MEMORYCLERK_XTP Alapértelmezett 2261
MEMORYCLERK_XTP DB_ID_5 7396
MEMORYCLERK_XTP Alapértelmezett 0
MEMORYCLERK_XTP Alapértelmezett 0

Ez várható: a rendszer a tranzakciós számítási feladat futtatásakor visszanyeri a memóriát.

Ha elindítja a demo számítási feladat második futtatását, a memória kihasználtsága kezdetben csökken, mivel a korábban törölt sorok törlődnek. Egy bizonyos ponton a memória mérete újra nő, amíg a számítási feladat be nem fejeződik. A demó alaphelyzetbe állítása után 10 millió sor beszúrása után a memória kihasználtsága nagyon hasonló az első futtatás utáni kihasználtsághoz. Például:

SELECT type,
       name,
       pages_kb / 1024 AS pages_MB
FROM sys.dm_os_memory_clerks
WHERE type LIKE '%xtp%';

Itt van az eredmények összessége.

type name pages_MB
MEMORYCLERK_XTP Alapértelmezett 1863
MEMORYCLERK_XTP DB_ID_5 7390
MEMORYCLERK_XTP Alapértelmezett 0
MEMORYCLERK_XTP Alapértelmezett 0

Lemezkihasználtság memóriaoptimalizált táblákhoz

Az adatbázis ellenőrzőpont-fájljainak lemezen lévő teljes mérete az alábbi lekérdezéssel található meg:

SELECT SUM(df.size) * 8 / 1024 AS [On-disk size in MB]
FROM sys.filegroups AS f
     INNER JOIN sys.database_files AS df
         ON f.data_space_id = df.data_space_id
WHERE f.type = N'FX';

Kezdeti állapot

Amikor a mintafájlcsoport és a memóriaoptimalizált mintatáblák kezdetben létrejönnek, több ellenőrzőpont-fájl jön létre, és a rendszer elkezdi betölteni a fájlokat – az előre létrehozott ellenőrzőpont-fájlok száma a rendszer logikai processzorainak számától függ. Mivel a minta kezdetben nagyon kicsi, az előre létrehozott fájlok többnyire üresek a kezdeti létrehozás után.

Az alábbi kód egy 16 logikai processzort tartalmazó gépen lévő minta kezdeti lemezméretét mutatja be:

SELECT SUM(df.size) * 8 / 1024 AS [On-disk size in MB]
FROM sys.filegroups AS f
     INNER JOIN sys.database_files AS df
         ON f.data_space_id = df.data_space_id
WHERE f.type = N'FX';

Itt van az eredmények összessége.

Lemezen lévő méret MB-ban
2312

Mint látható, nagy eltérés van az ellenőrzőpont-fájlok lemezen lévő mérete között, amely 2,3 GB, és a tényleges adatméret, amely közelebb van a 30 MB-hoz.

Ha közelebbről szeretné áttekinteni, hogy honnan származik a lemezterület kihasználtsága, az alábbi lekérdezést használhatja. A lekérdezés által visszaadott lemez mérete az 5 (BIZTONSÁGI MENTÉSHEZ/HA) állapotú fájlokhoz, a 6-os (TOMBSTONE-HOZ ÁTMENETBEN) vagy a 7 (TOMBSTONE) állapotú fájlokhoz közelítő.

SELECT state_desc,
       file_type_desc,
       COUNT(*) AS [count],
       SUM(CASE WHEN state = 5 AND file_type = 0 THEN 128 * 1024 * 1024
                WHEN state = 5 AND file_type = 1 THEN 8 * 1024 * 1024
                WHEN state IN (6, 7) THEN 68 * 1024 * 1024
           ELSE file_size_in_bytes END) / 1024 / 1024 AS [on-disk size MB]
FROM sys.dm_db_xtp_checkpoint_files
GROUP BY state, state_desc, file_type, file_type_desc
ORDER BY state, file_type;

A minta kezdeti állapotában az eredmény a következő táblázathoz hasonlóan néz ki egy 16 logikai processzorral rendelkező kiszolgáló esetében:

állapot_leírás fájltípus_leírás számol lemezen lévő MB méret
ELŐRE MEGALKOTOTT ADAT 16 2048
ELŐRE MEGALKOTOTT DELTA 16 128
ÉPÍTÉSI TERÜLET ADAT 1 128
ÉPÍTÉSI TERÜLET DELTA 1 8

Mint látható, a terület nagy részét előre létrehozott adatok és deltafájlok használják. Az SQL Server logikai processzoronként előre létrehozott egy pár (adat-, delta-) fájlt. Emellett az adatfájlok előre méretezve vannak 128 MB-ra, a deltafájlok pedig 8 MB-ra vannak méretezve, hogy hatékonyabbá tegyék az adatok beszúrását ezekbe a fájlokba.

A memóriaoptimalizált táblák tényleges adatai egyetlen adatfájlban találhatók.

A számítási feladat futtatása után

A 10 millió értékesítési rendelést beszúró egyetlen tesztfuttatás után a lemez teljes mérete így néz ki (egy 16 magos tesztkiszolgáló esetében):

SELECT SUM(df.size) * 8 / 1024 AS [On-disk size in MB]
FROM sys.filegroups AS f
     INNER JOIN sys.database_files AS df
         ON f.data_space_id = df.data_space_id
WHERE f.type = N'FX';

Itt van az eredmények összessége.

Lemezen lévő méret MB-ban
8828

A lemez mérete megközelíti a 9 GB-ot, ami közel esik az adatok memóriabeli méretéhez.

Az ellenőrzőpont-fájlok méretének részletesebb áttekintése a különböző állapotokban:

SELECT state_desc,
       file_type_desc,
       COUNT(*) AS [count],
       SUM(CASE WHEN state = 5 AND file_type = 0 THEN 128 * 1024 * 1024
                WHEN state = 5 AND file_type = 1 THEN 8 * 1024 * 1024
                WHEN state IN (6, 7) THEN 68 * 1024 * 1024
            ELSE file_size_in_bytes END) / 1024 / 1024 AS [on-disk size MB]
FROM sys.dm_db_xtp_checkpoint_files
GROUP BY state, state_desc, file_type, file_type_desc
ORDER BY state, file_type;

Itt van az eredmények összessége.

state_desc file_type_desc count on-disk size MB
ELŐRE MEGALKOTOTT ADAT 16 2048
ELŐRE MEGALKOTOTT DELTA 16 128
ÉPÍTÉSI TERÜLET ADAT 1 128
ÉPÍTÉSI TERÜLET DELTA 1 8

Még mindig van 16 pár előre létrehozott fájlunk, készen arra, hogy használjuk őket, amikor az ellenőrzőpontok bezárulnak.

Egy pár épül fel, amelyet az aktuális ellenőrzőpont bezárásáig használnak. Az aktív ellenőrzőpont-fájlok mellett ez körülbelül 6,5 GB lemezkihasználtságot biztosít 6,5 GB memóriában lévő adathoz. Ne feledje, hogy az indexek nem maradnak meg a lemezen, így a lemez teljes mérete kisebb, mint a memória mérete ebben az esetben.

A demo alaphelyzetbe állítása után

A demo visszaállítás után a lemezterület nem lesz azonnal visszanyerve, ha nincs tranzakciós számítási feladat a rendszeren, és nincsenek adatbázis-ellenőrzőpontok. Ahhoz, hogy az ellenőrzőpontok fájljai átkerüljenek a különböző fázisokon és végül el lehessen vetni őket, több ellenőrzőpontnak és naplócsonkolási eseménynek kell megtörténnie, hogy kezdeményeződjön az egyesítés, valamint a szemétgyűjtés. Ezek automatikusan történnek, ha tranzakciós számítási feladattal rendelkezik a rendszerben (és rendszeresen készít biztonsági másolatot a teljes helyreállítási modell használata esetén), de nem akkor, ha a rendszer tétlen, mint egy bemutató forgatókönyvben.

A példában a demó alaphelyzetbe állítása után a következőhöz hasonló jelenetet láthat:

SELECT SUM(df.size) * 8 / 1024 AS [On-disk size in MB]
FROM sys.filegroups AS f
     INNER JOIN sys.database_files AS df
         ON f.data_space_id = df.data_space_id
WHERE f.type = N'FX';

Itt van az eredmények összessége.

Lemezen lévő méret MB-ban
11839

Közel 12 GB-os, ez jelentősen több, mint a bemutató alaphelyzetbe állítása előtti 9 GB. Ennek az az oka, hogy néhány ellenőrzőpont-fájlegyesítés elindult, de néhány egyesítési cél még nem lett telepítve, és néhány egyesítési forrásfájl még nem lett megtisztítva, ahogy az alábbi példában látható:

SELECT state_desc,
       file_type_desc,
       COUNT(*) AS [count],
       SUM(CASE WHEN state = 5 AND file_type = 0 THEN 128 * 1024 * 1024
                WHEN state = 5 AND file_type = 1 THEN 8 * 1024 * 1024
                WHEN state IN (6, 7) THEN 68 * 1024 * 1024
           ELSE file_size_in_bytes END) / 1024 / 1024 AS [on-disk size MB]
FROM sys.dm_db_xtp_checkpoint_files
GROUP BY state, state_desc, file_type, file_type_desc
ORDER BY state, file_type;

Itt van az eredmények összessége.

state_desc file_type_desc count on-disk size MB
ELŐRE MEGALKOTOTT ADAT 16 2048
ELŐRE MEGALKOTOTT DELTA 16 128
AKTÍV ADAT 38 5152
AKTÍV DELTA 38 1331
EGYESÍTENDŐ CÉL ADAT 7 896
EGYESÍTENDŐ CÉL DELTA 7 56
EGYESÍTETT FORRÁS ADAT 13 1772
EGYESÍTETT FORRÁS DELTA 13 455

A rendszer telepíti az egyesítési célokat, és az egyesített forrás törlődik, amikor tranzakciós tevékenység történik a rendszerben.

A demo számítási feladat második futtatása után, a bemutató alaphelyzetbe állítása után 10 millió értékesítési rendelés beszúrásával láthatja, hogy a számítási feladat első futtatása során létrehozott fájlok törlődtek. Ha többször futtatja az előző lekérdezést, miközben a számítási feladat fut, láthatja, hogy az ellenőrzőpontfájlok végigvezetik magukat a különböző szakaszokon.

A terhelés második futtatása során 10 millió értékesítési rendelés kerül beszúrásra, a lemezhasználat nagyon hasonló lehet, bár nem feltétlenül ugyanaz, mint az első futtatás után, mivel a rendszer dinamikusan működik. Például:

SELECT state_desc,
       file_type_desc,
       COUNT(*) AS [count],
       SUM(CASE WHEN state = 5 AND file_type = 0 THEN 128 * 1024 * 1024
                WHEN state = 5 AND file_type = 1 THEN 8 * 1024 * 1024
                WHEN state IN (6, 7) THEN 68 * 1024 * 1024
           ELSE file_size_in_bytes END) / 1024 / 1024 AS [on-disk size MB]
FROM sys.dm_db_xtp_checkpoint_files
GROUP BY state, state_desc, file_type, file_type_desc
ORDER BY state, file_type;

Itt van az eredmények összessége.

state_desc file_type_desc count on-disk size MB
ELŐRE MEGALKOTOTT ADAT 16 2048
ELŐRE MEGALKOTOTT DELTA 16 128
ÉPÍTÉSI TERÜLET ADAT 2 268
ÉPÍTÉSI TERÜLET DELTA 2 16
AKTÍV ADAT 41 5608
AKTÍV DELTA 41 328

Ebben az esetben két ellenőrzőpont-fájlpár van az UNDER CONSTRUCTION állapotban, ami azt jelenti, hogy több fájlpár is át lett helyezve az UNDER CONSTRUCTION állapotba, valószínűleg a számítási feladat magas szintű egyidejűsége miatt. Több egyidejű szál egy új fájlpárra volt szüksége, és így egy párt áthelyezett a PRECREATED fájlból a UNDER CONSTRUCTION fájlba.

Kapcsolódó tartalom

  • Last updated on