Heap tables in SQL Server

tämän blogisarjan viimeisessä postauksessa keskustelin B-Tree-indeksistä ja selitin lyhyesti sen historiaa.

ennen kuin sukellamme SQL Serverin käyttämiin indekseihin, on tärkeää luoda tietorakenteiden perusta. Yksinkertaisin taulukko, että voit luoda on kasa. Kasa on lajittelematon rakenne sivuja, jotka eivät ole sidoksissa toisiinsa.

milloin kannattaa käyttää kasoja?

parhaan käytännön suositus on välttää SQL Server-kasoja useimmissa tapauksissa. Kimberly Tripp selittää joitakin syitä ja keskustelua täällä, mutta aion kattaa korkean tason. Kasoista, jotka ovat kaikkein perusvarastorakenne, puuttuu ominaisuuksia, jotka parantavat suorituskykyä normaaleille (OLTP) työkuormille. Jotkut väittävät, että kasat ovat parempia ote -, transformation-ja loading (ETL) – operaatioissa, koska kirjoitustoimintojen aikana ylläpidettäviä sivuja on vähemmän (UPDATE/INSERT/DELETE). Erityisesti kasat voivat olla nopeampia kuin B-puuindeksi, jos sivu halkeaa ja indeksin monia tasoja on päivitettävä. Lisäksi rivitunniste (rid), jota käsitellään tarkemmin alla, on vain 8 tavua. Tämä voi toimia paremmin kuin ryhmitelty indeksi, jossa on paljon keskeisiä sarakkeita, koska ei-ryhmitelty indeksit on säilytettävä ryhmitelty avain tai RID kunkin indeksoidun rivin. Tyypillisesti suosittelen ryhmitelty indeksi (enemmän ryhmitelty indeksit kuten jatkamme tätä sarjaa) sijaan kasaan, mutta jos et käytä niitä, käytä niitä vain, kun olet osoittanut, että ne ovat tehokkaampia kuin ryhmitelty indeksi. Keskusteltuani kasan rakenteesta hahmottelen kasojen käytön suorituskykyyn liittyviä huolenaiheita.

Kasarakenne

röykkiö on ryhmittymä, joka koostuu lajittelemattomista sivuista, joita ei ole liitetty toisiinsa. Sivun anatomia on tämän sarjan ulkopuolella, koska kaikki indeksoidut ja indeksoimattomat taulukot käyttävät samaa sivurakennetta, mutta kehotan teitä tutustumaan tähän ja tähän oppiaksenne lisää.

kasa koostuu yhdestä tai useammasta indeksin kohdentamiskarttasivusta (iam), jotka osoittavat kasan muodostavat tietosivut. Ainoa poikkeus tähän on, kun sinulla on rivi, joka on päivitetty eikä mahtunut sen sivulle enää. Siinä tapauksessa saat edelleenlähetysosoittimen riville, joka on siirretty olemassa olevalle sivulle, jossa on tilaa, tai uudelle sivulle. Voit tuottaa huolintatietojen ketjun, jos rivi tarvitsee edelleen siirtoa lisätoimintojen kautta.

heap-structure-1

Kuvaviite: MSDN

kasassa on yksi rivi sysissä.osiot osiota kohti ja sen indeksi_id on nolla. Tässä tietueessa ensimmäinen_iam_page osoittaa indeksin allokointikartan (iam) ensimmäisen sivun. IAM-sivu kartoittaa kunkin jakoyksikön sivuja ja hallinnoi 4 GB: n palasia taulukosta. Allokaatioyksiköitä ovat:

  1. IN_ROW_DATA allocation unit
  2. LOB_DATA allocation unit
  3. ROW_OVERFLOW_DATA allocation unit

IAM-sivu sisältää standardin mukaisen 96-tavuisen otsikon, jota seuraa IAM-otsikko. IAM: n otsikko alkaa kahdeksalla eri laajuusjaon lähtöalueella ja sen jälkeen 8000-tavuinen bittikartta, jolla voidaan paikantaa taulukkoon jaetut yhtenäiset laajennukset.

sekamuoto on sellainen, jossa on sivuja useammasta kuin yhdestä taulukosta. Tätä kutsutaan myös yhteiseksi laajuudeksi. Sekamitoituksen tarkoituksena on säästää tilaa alle 64 KB: n taulukoilla. Yhtenäinen laajuus on sellainen, jossa kaikki laajuudessa olevat sivut kuuluvat yhteen taulukkoon.

mixed-extent

Image Reference: the Extent

to investigate our iam page, first we must local it.

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

dbcc-ind

DBCC IND: llä meillä on 17 datasivua ja 1 IAM-sivu. IAM-sivut eivät ole itsestään viittaavia, joten iamfid (iam file Id) ja IAMPID (iam page Id) ovat NULL. Tämä tarkoittaa, että IAM-sivumme on tiedostotunnuksessa (PageFID) 1 ja sivutunnuksessa (PagePID) 297. DBCC-sivun avulla voimme tarkastella IAM-sivuamme.

DBCC-TRACEON(3604);

DBCC-sivu (”demo’,1,297,3);

dbcc-page-iam

keltaisessa on kahdeksan yhden sivun jakoa meidän kirjavassa laajuudessa. Oranssissa yhtenäiset pituudet näkyvät vaihteluväleinä.

Suoritusvaikutukset

erilaisten tietojen manipulointikielen (DML) operaatioiden suorittaminen kasassa vaikuttaa näihin vaikutuksiin.

  • lisää-uudet rivit voidaan sijoittaa ensimmäiselle saatavilla olevalle sivulle, jossa on riittävästi tilaa. Joten aina kun uusi rivi lisätään, se todennäköisesti lisätään viimeiselle sivulle.
  • päivitys-rivit voivat pysyä samalla sivulla, jos se mahtuu päivityksen jälkeen sivulle, jos ei, se poistetaan nykyiseltä sivulta ja sijoitetaan ensimmäiselle saatavilla olevalle sivulle, jossa on riittävästi tilaa ja sen alkuperäiselle sivulle kirjoitetaan edelleen osoitin.
  • poista-tietoja ei korvata, tila merkitään vain uudelleenkäytettäväksi. Tämä voi aiheuttaa taulukon kuluttaa huomattavasti enemmän levytilaa kuin on tarpeen.
  • valitse-useimpiin kyselyihin on luettava koko taulukon skannaus. Poikkeuksena on, jos saatavilla on sopiva ryhmittelemätön indeksi. Käsittelemme ei-ryhmiteltyjä hakemistoja myöhemmin tässä sarjassa.

lukee

ilman mitään tukihakemistoa, röykkiö vaatii täyden taulukon skannauksen jokaista kyselyä varten. Tämä johtuu siitä, että fyysinen rakenne on lajittelematon, eikä siinä ole sivua, joka linkittäisi tukialueen skannauksiin.

SET STATISTICS IO ON

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

valitse lukumäärä (*)
DBO: sta.demo

DBCC Ind-komennon toistaminen ylhäältä muistuttaa, että taulukkoa varten on 18 sivua. 17 tietosivua ja 1 IAM-sivu.

– poistettu DBCC IND-tulokset, koska se näkyy jo yllä.
-18 rivitulos, osoittaa 18 sivua.

(18 krs (s) vaikuttaa)
DBCC suoritus suoritettu. Jos DBCC tulostaa virheilmoituksia, ota yhteyttä järjestelmänvalvojaan.

rivimäärä
—-
5031
(1 rivi (t) vaikuttaa)

taulukko ”Demo”. Scan count 1, looginen lukee 17, fyysinen lukee 0, read-ahead lukee 0, lob looginen lukee 0, Lob fyysinen lukee 0, lob read-ahead lukee 0.
(1 rivi(s) vaikuttaa)

huomaa kyselystämme 17 loogista lukua. Tämä johtuu siitä, että IAM: n sivua ei lasketa loogiseen lukumetriin ja suoritimme 18-sivuisen taulukon täydellisen skannauksen.

kirjoittaa ja eteenpäin osoittimet

kuten edellä mainittiin, insertit ja poistot ovat melko suoraviivaisia. Ensimmäisellä sivulla on lisäys, jossa on tilaa, vaikka se tarkoittaisi uuden sivun luomista. Poistot suoritetaan de-allokoimalla tila rivi miehitti.

päivityksissä asiat menevät kasojen osalta alamäkeen. Kun kiinteä pituus tietotyyppi päivitetään, päivitys tapahtuu paikallaan. Jos muuttuvapituinen tietotyyppi päivittyy ja pituus on kasvanut, on mahdollista, että rivi ei enää mahdu samalle sivulle. Kun rivi ei enää mahdu, välitysosoitin laitetaan tilaan, jossa alkuperäinen rivi oli, ja rivi siirretään uudelle sivulle. Tällä prosessilla on negatiivinen vaikutus lukusuoritukseen. Demonstroidaan.

alun perin kaikki levymme dbo: ssa.demo taulukko sisälsi VARCHARs 9 merkkiä merkkijonoja.

valitse TOP 5 *
DBO: sta.demo

demotaulukon tiedot

joidenkin eteenpäin osoittimien luomiseksi päivitämme kaikki rivimme ja lisäämme varlen-sarakkeen pituutta.

Päivitä dbo.demo
set varLen = replikate (”a’,100)

kasassa on nyt 95 sivua, koska kaikki rivimme on siirretty uusille sivuille, joiden eteen on jätetty osoittimia.

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

dbcc-output-1

kuten voitte kuvitella, kasat vaativat täyden taulukon skannaa, meidän täytyy lukea paljon enemmän sivuja saman määrän tietueita nyt.

SET STATISTICS IO ON

SELECT COUNT (*)
FROM dbo.demo
(1 rivi (s) vaikuttaa)

taulukko ”Demo”. Scan count 1, looginen lukee 4405, fyysinen lukee 0, read-ahead lukee 0, lob looginen lukee 0, Lob fyysinen lukee 0, lob read-ahead lukee 0.

lukumme lisääntyi rajusti, koska ensin piti lukea alkuperäiset sivut ja sitten seurata eteenpäin meneviä osoittimia. Suorituskyvyn vaikutus ja tilan tuhlaus muistissa ja levyllä on syy, miksi tarvitsemme ryhmitettyjä indeksejä.

seuraavalla kerralla

Heapin tietorakenne ei ole indeksi, ja se on usein SQL Serverin taulukoiden huonoiten toimiva tietorakenne. Käsittelimme sitä tänään ymmärryksen perustana, joka on hyödyllinen, kun keskustelemme indekseistä. Sarjan seuraavassa osassa käsitellään taulukoiden B+-puurakennetta (clustered indexes).

Vastaa

Sähköpostiosoitettasi ei julkaista.