Heap tables in SQL Server

a blogsorozat utolsó bejegyzésében megvitattam, mi az A B-Tree index, és röviden elmagyaráztam annak történetét.

mielőtt belemerülnénk az SQL Server által használt indexekbe, fontos meghatározni az adatstruktúrák alapjait. A legalapvetőbb táblázat, amelyet létrehozhat, egy halom. A kupac olyan oldalak rendezetlen szerkezete, amelyek nem kapcsolódnak egymáshoz.

mikor kell halmokat használni?

a legjobb gyakorlat az SQL Server halmok elkerülése, a legtöbb esetben. Kimberly Tripp elmagyarázza néhány okot és vitát itt, de a magas szintet lefedem. A Heaps, amely a legalapvetőbb tárolási struktúra, hiányzik olyan funkciók, amelyek javítják a normál (OLTP) munkaterhelések teljesítményét. Egyesek azzal érvelnek, hogy a halmok jobbak az extract, transformation and loading (ETL) műveletekhez, mert kevesebb oldalt kell fenntartani az írási műveletek során (frissítés/beszúrás/törlés). Pontosabban, a halmok gyorsabbak lehetnek, mint egy B-fa index, ha oldalmegszakadások fordulnak elő, és az index több szintjét frissíteni kell. Ezenkívül az alábbiakban részletesebben tárgyalt sorazonosító (RID) csak 8 bájt. Ez jobban teljesíthet, mint a sok kulcsoszlopot tartalmazó fürtözött index, mert a nem fürtözött indexeknek minden indexelt sorhoz tárolniuk kell a fürtözött kulcsot vagy a RID-et. Általában azt javaslom, hogy fürtözött indexet használjon (többet a fürtözött indexekről, amikor folytatjuk ezt a sorozatot), nem pedig kupacot, de ha mégis használja őket, akkor csak akkor használja őket, ha bebizonyította, hogy hatékonyabbak lesznek, mint egy fürtözött index. Miután megvitattuk a kupac szerkezetét, felvázolom a halmok használatának teljesítményével kapcsolatos aggályokat.

Kupacszerkezet

a kupac nem rendezett oldalak csoportosítása, amelyek nem kapcsolódnak egymáshoz. Az oldal anatómiája nem tartozik ebbe a sorozatba, mivel az indexelt és nem indexelt táblázatok minden típusa ugyanazt az oldalszerkezetet használja, de azt javaslom, hogy nézze meg itt és itt, hogy többet megtudjon.

a kupac egy vagy több index allokációs térkép (iam) oldalból áll, amelyek a kupacot alkotó adatoldalakra mutatnak. Az egyetlen kivétel ez alól, ha van egy sor, amely frissült, és már nem fér el az oldalán. Ebben az esetben egy átirányítási mutatót kap arra a sorra, amelyet áthelyeztek egy meglévő oldalra szóközzel vagy egy új oldallal. Lehetőség van arra, hogy készítsen egy lánc forwarding rekordok, ha a sor továbbra is szükség áthelyezés további műveleteket.

heap-structure-1

Image reference: MSDN

egy halom egy sor sys.partíciónkénti partíciók és index_id értéke nulla lesz. Ebben a rekordban a first_iam_page az index allocation map (iam) első oldalára mutat. Az IAM-oldal leképezi az egyes kiosztási egységek oldalait, és kezeli a táblázat 4 GB-os darabjait. Az elosztási egységek a következők:

  1. IN_ROW_DATA allokációs egység
  2. LOB_DATA allokációs egység
  3. ROW_OVERFLOW_DATA allokációs egység

az IAM oldal tartalmazza a szabványos 96 bájtos fejlécet, amelyet az IAM fejléc követ. Az IAM fejléc nyolc résszel kezdődik a vegyes kiterjedésű allokációkhoz, majd egy 8000 bájtos bittérképpel, hogy megtalálja az asztalhoz rendelt egységes kiterjedéseket.

vegyes kiterjedésű az, amely egynél több táblázat oldalait tartalmazza. Ezt közös mértéknek is nevezik. A vegyes mértékű cél a helytakarékosság a 64 KB-nál kisebb táblákkal. Az egységes kiterjedés az, ahol a kiterjedés összes oldala ehhez az egyetlen táblázathoz tartozik.

mixed-extent

kép hivatkozás: a

terjedelem az IAM oldalunk vizsgálatához először meg kell találnunk.

DBCC IND (‘demo’,’dbo.demo’,1)

dbcc-ind

a DBCC IND-vel 17 adatoldalunk és 1 IAM oldalunk van. Az IAM oldalak nem önhivatkozóak, ezért az IAMFID (iam file Id) és az IAMPID (IAM page Id) NULL. Ez azt jelenti, hogy az IAM oldalunk fájlazonosítója (PageFID) 1, oldalazonosítója (PagePID) 297. A DBCC oldal lehetővé teszi számunkra az IAM oldal megtekintését.

DBCC TRACEON(3604);

DBCC oldal (‘demo’,1,297,3);

dbcc-page-iam

sárga színben nyolc egyoldalas allokáció van vegyes mértékben. Narancssárga színben az egyenletes kiterjedések tartományokban jelennek meg.

Teljesítménykövetkezmények

különböző Adatkezelési nyelv (DML) műveletek végrehajtása egy halomban ezek a hatások.

  • Beszúrás – Új sorok helyezhetők el az első rendelkezésre álló oldalon elegendő hely mellett. Tehát amikor egy új sor kerül beillesztésre, valószínűleg hozzáadódik az utolsó oldalhoz.
  • frissítés – a sorok ugyanazon az oldalon maradhatnak, ha a frissítés után beleférnek az oldalba, ha nem, akkor az aktuális oldalról eltávolításra kerül, és az első rendelkezésre álló oldalra elegendő hely áll rendelkezésre, és az eredeti oldalra egy továbbítási mutató kerül.
  • törlés – az adatok nem kerülnek felülírásra, a hely csak megjelölve van, mint újrafelhasználható. Ez azt eredményezheti,hogy a tábla a szükségesnél lényegesen több lemezterületet fogyaszt.
  • kiválasztás – a legtöbb lekérdezéshez a teljes táblán lévő táblázatvizsgálatot el kell olvasni. Ez alól kivételt képez, ha rendelkezésre áll egy megfelelő, nem fürtözött index. A nem fürtözött indexeket ebben a sorozatban később tárgyaljuk.

olvas

nélkül támogató index, egy halom igényel teljes tábla scan minden lekérdezést. Ez azért van, mert a fizikai struktúra nincs rendezve, és nincs oldalhivatkozás a tartomány-vizsgálatok támogatására.

állítsa be a statisztikai IO-t

DBCC IND (‘demo’, ‘ dbo.demo’,1)

válassza a COUNT(*)
lehetőséget a dbo-ból.demo

a DBCC IND parancs felülről történő megismétlése emlékeztet minket arra, hogy 18 oldalunk van ehhez a táblázathoz. 17 adatoldal és 1 IAM oldal.

-18 sor eredmény, 18 oldalt jelöl.

(18 sor érintett)
a DBCC végrehajtása befejeződött. Ha DBCC nyomtatott hibaüzenetek, forduljon a rendszergazdához.

sorszám
—-
5031
(1 érintett sor(ok))

táblázat ‘Demo’. Szkennelési szám 1, logikai olvasás 17, fizikai Olvasás 0, előre olvas 0, lob logikai Olvasás 0, lob fizikai Olvasás 0, lob előre olvas 0.
(1 sor érintett)

vegye figyelembe a lekérdezésünk 17 logikai olvasatát. Ennek az az oka, hogy az IAM-oldal nem számít bele a logikai olvasás metrikába, és 18 oldalas teljes szkennelést végeztünk a táblán.

írások és előremutatók

mint már említettük, a Beszúrások és törlések meglehetősen egyenes előre. A Beszúrás az első oldalon történik, ahol rendelkezésre áll hely, még akkor is, ha ez új oldal létrehozását jelenti. A törléseket úgy hajtjuk végre, hogy a sor által elfoglalt helyet elosztjuk.

a frissítések azok, ahol a dolgok lefelé haladnak a halmok számára. Rögzített hosszúságú adattípus frissítésekor a frissítés helyben történik. Ha egy változó hosszúságú adattípus frissül, és a hossza nőtt, akkor fennáll annak a lehetősége, hogy a sor már nem fér el ugyanazon az oldalon. Amikor a sor már nem fér el, egy átirányítási mutató kerül arra a helyre, ahol az eredeti sor volt, és a sor áthelyezésre kerül egy új oldalra. Ez a folyamat negatív hatással van az olvasási teljesítményre. Mutassuk be.

eredetileg az összes rekordot a dbo.a demo táblázat Varcharokat tartalmazott 9 karakterlánccal.

válassza ki a TOP 5 *
elemet a dbo-ból.demo

demo táblázat adatai

néhány előre mutató mutató létrehozásához frissítjük az összes sort, és növeljük a varLen oszlop hosszát.

a dbo frissítése.demo
set varLen = replikáció (‘a’,100)

most már 95 oldalunk van a kupacunkban, mert minden sorunkat új oldalakra helyezték át, előre mutató mutatókkal.

DBCC IND (‘demo’,’dbo.demo’,1)

dbcc-output-1

ahogy el tudod képzelni, a halmok igénylő teljes tábla vizsgál, meg kell olvasni sokkal több oldalt az azonos mennyiségű rekordok most.

állítsa be az IO statisztikákat

válassza ki a grófot(*)
a dbo-ból.bemutató
(1 sor érintett)

táblázat ‘bemutató’. Szkennelési szám 1, logikai olvasás 4405, fizikai Olvasás 0, előre Olvasás 0, lob logikai Olvasás 0, lob fizikai Olvasás 0, lob előre Olvasás 0.

olvasásunk drasztikusan megnőtt, mert az eredeti oldalakat el kellett olvasni, majd az előre mutató mutatókat kellett követni. A teljesítmény hatása és a memória és a lemezen lévő hely pazarlása miatt van szükségünk fürtözött indexekre.

legközelebb

a kupac adatstruktúra nem index, és gyakran a legrosszabbul teljesítő adatstruktúra az SQL Server tábláihoz. Ma a megértés alapjaként fedeztük fel, amely hasznos lesz az indexek megvitatásakor. A sorozat következő részében fürtözött indexek, a táblázatadatok B+-fa szerkezete lesz lefedve.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.