1

Datu meklēšana (data search)

Informācijas meklēšana ir viena no vissvarīgākajām datoru funkcijām. Parasti tas nozīmē sniegt datoram daļu informācijas, ko sauc par atslēgu, un lūgt atrast ierakstu, kas satur citu saistīto informāciju. To panāk, vispirms pārskatot sarakstu, lai uzzinātu, vai dotā atslēga ir vai nav. Šo procesu sauc par meklēšanu. Datorsistēmas bieži tiek izmantotas liela apjoma datu glabāšanai, no kuriem saskaņā ar kādu meklēšanas kritēriju ir jāiegūst atsevišķi ieraksti. Meklēšanas process datu struktūrā var būt vienkāršs vai ļoti sarežģīts. Meklēšanu var veikt iekšējās datu struktūrās vai ārējās datu struktūrās. Informācijas iegūšana vajadzīgajā formātā ir galvenā darbība visās datorprogrammās.

Meklēšanas metodes ir izstrādātas, lai izmantotu failu organizācijas priekšrocības un optimizētu konkrēta ieraksta meklēšanu vai noteiktu tā neesamību. Izvēlētā failu organizācija un meklēšanas metode var būtiski mainīt lietojumprogrammas veiktspēju. Ja ir n elementu saraksts, kur katrs elements ir atslēga / skaitlis. Uzdevums ir pēc iespējas īsākā laikā atrast konkrētu atslēgu sarakstā. 1. Lineārā meklēšana. Sāciet saraksta sākumā un pārbaudiet visus saraksta elementus. Ļoti lēns [secība O (n)], bet darbojas nešķirotā sarakstā. Lasiet Lineārā meklēšana sīkāk.

2. Binārā meklēšana To izmanto meklēšanai sakārtotā masīvā. Pārbaudiet masīva vidējo elementu. Ja tas ir pārāk liels. Atkārtojiet procesu masīva kreisajā pusē un labajā pusē, ja tas ir pārāk mazs. Tādā veidā vietas daudzums, kas jāmeklē, katru reizi tiek samazināts uz pusi, tāpēc laiks ir O (log n). Plašāk lasiet bināro meklēšanu.

3. Hash meklēšana Jaucējtabulas meklēšana ir vienkārša un ārkārtīgi ātra, vienkārši atrodiet meklējamā vienuma jaukšanas vērtību, pēc tam dodieties uz šo indeksu un sāciet meklēt masīvu, līdz atrodat meklēto vai nonākat tukšā vietā. Pasūtījums ir diezgan tuvu o (1), atkarībā no tā, cik pilna ir jūsu hash tabula.

4. Bināra koka meklēšana Binārā koka meklēšana ir tikpat vienkārša kā hash tabulas meklēšana, taču parasti tā notiek lēnāk (īpaši, ja koks ir slikti līdzsvarots). Vienkārši sāciet no saknes. Pēc tam dodieties uz leju pa kreiso apakškoku, ja sakne ir pārāk liela, un labo apakškoku, ja tā ir par mazu. Atkārtojiet, līdz atrodat vēlamo, vai nav vēlamā apakškoka. Darbības laiks ir vidēji O (log n) un sliktākajā gadījumā O (n). Algoritmiskais apzīmējums Apskatīsim, cik ilgs laiks būs vajadzīgs, lai kolekcijās atrastu atslēgu, kas atbilst atslēgai. Mūs interesē: Vidējais laiks Sliktākajā gadījumā laiks un Labākais iespējamais laiks. Tomēr mūs visvairāk uztrauc vissliktākais laiks, jo aprēķini, kas balstīti uz sliktāko laiku, var radīt garantētas veiktspējas prognozes. Ērti sliktāko laiku parasti ir vieglāk aprēķināt nekā vidējo laiku. Ja mūsu kolekcijā ir n vienumu neatkarīgi no tā, vai tas tiek glabāts kā masīvs vai kā saistīts saraksts, ir acīmredzams, ka sliktākajā gadījumā, ja kolekcijā nav neviena vienuma ar vēlamo

2

atslēgu, tad n atslēgu salīdzina ar būs jāizgatavo kolekcijas priekšmetu atslēgas. Lai vienkāršotu algoritmu analīzi un salīdzināšanu, mēs meklējam dominējošu darbību un skaitām reižu skaitu, kad jāveic dominējošā darbība. Meklēšanas gadījumā dominējošā darbība ir salīdzinājums, jo meklēšanai sliktākajā gadījumā ir nepieciešami n salīdzinājumi, mēs sakām, ka tas ir O (n), (izrunāts kā liels-Oh-n vai Oh-n) algoritms. Labākais gadījums, kad pirmais salīdzinājums atgriež rezultātu, prasa vienu salīdzinājumu un ir O (1). Vidējais laiks ir atkarīgs no varbūtības, ka atslēga tiks atrasta kolekcijā - tas ir kaut kas, ko mēs lielākajā daļā gadījumu nevarētu zināt. Tādējādi šajā gadījumā, tāpat kā lielākajā daļā citu, vidējā laika aprēķināšana ir maz noderīga. Ja sistēmas veiktspēja ir vitāli svarīga, t.i., tā ir daļa no dzīvībai kritiskas sistēmas, tad projektēšanas aprēķinos jāizmanto vissliktākais gadījums, jo tas atspoguļo vislabāko garantēto veiktspēju.

3

Datu meklēšanas piemērs. Noteiktas kārts atrašana

4

Datu bāzes tabulas indekss

Indekss ir datu struktūra, kas uzlabo datu izgūšanas operāciju ātrumu. Indeksam papildus jāveido datu struktūra ar sakārtotiem datiem.

Datubāzes indekss ir tabulveida datu struktūra, kas:1) uzlabo datu izguves ātrumu no datu bāzes tabulām;2) palēnina datu ierakstīšanu datu bāzes tabulās;3) tabulas ar indeksiem aizņem vairāk vietas.

Indeksu var izveidot, izmantojot vienu vai vairākas datu bāzes tabulas kolonnas, kas paātrinās piekļuvi gan nejauši sakārtotiem datiem, gan arī sakārtotiem.

Relāciju datu bāzēs, indekss ir kopija no daļas tabulas datu. Dažas datubāzes paplašina šo funkcionalitāti, ļaujot izveidot indeksus, kas balstās uz funkcijām vai izteiksmēm.

Indeksu var definēt kā unikālu vai ne-unikālu. Unikālais indekss darbojas kā tabulas ierobežojums, neļaujot dublēt ierakstus indeksā un, līdz ar to, attiecīgajā tabulā.

5

Indekss

Indekss ir datu bāzes shēmas objekts, kas satur katru vērtību, kura ir tabulas vai klastera indeksētajā (- ās) kolonnā (- ās) un nodrošina tiešu un ātru piekļuvi rindām. Viena indeksa ieraksta maksimālais lielums ir atkarīgs no datu bāzes bloka lieluma.Oracle Database atbalsta vairākus indeksa tipus:

1) normālie indeksi, pēc noklusējuma Oracle datu bāze izveido B koka indeksus;2) bitkaršu indeksi (bitmap inexes), kas saglabā ROWIDS, kas asociēti ar atslēgas

vērtību kā bitkarti;3) partīciju indeksi, kas sastāv no nodalījumiem jeb partīcijām, kuros ir katra vērtība,

kas parādās tabulas indeksētajā (- s) kolonnā (- s);4) uz funkcijām balstīti indeksi, kuru pamatā ir izteiksmes. Tie ļauj izveidot

vaicājumus, kas novērtē izteiksmes atgriezto vērtību, kas savukārt var ietvert iebūvētas vai lietotāja definētas funkcijas.

5) domēna indeksi, kas ir lietojumprogrammai specifiska indeksa tipa indeksa gadījumi.

6

Kas ir indekss jeb indeksa tabula?

tabula STUDENTIUZV VAR DZIM KURSS GRUPA ROWIDZars Jūlijs vīrietis 5 DB5 rowid1Caune Anita sieviete 5 DB5 rowid2Roze Rasma sieviete 4 DB4 rowid3Liepa Inese sieviete 4 DB4 rowid4Celms Zane sieviete 3 DB3 rowid5Sakne Jānis vīrietis 3 DB3 rowid6Apse Juris vīrietis 1 DB1 rowid7Alksnis

Varis vīrietis 1 DB1 rowid8

Diska atmiņa

2. bloksZars Jūlijs vīrietis 5 DB5Caune Anita sieviete 5 DB5Roze Rasma sieviete 4 DB4Liepa Inese sieviete 4 DB4Celms Zane sieviete 3 DB3Sakne Jānis vīrietis 3 DB3Apse Juris vīrietis 1 DB1Alksnis

Varis vīrietis 1 DB1

1. bloks

3. bloks

indekss STUDENTIUZV ROWIDAlksnis

rowid8

Apse rowid7Caune rowid2Celms rowid5Liepa rowid4Roze rowid3Sakne rowid6Zars rowid1

1

2

3

7

Relāciju datu bāzes indeksa faila jeb indeksa darbība

8

Indeksa tabula jeb indekss

Indeksa tabula jeb vienkārši indekss (nejaukt ar tabulu ar indeksa organizāciju) ir neobligāta struktūra, kas saistīta ar tabulu vai tabulu klasteri un kas dažreiz var paātrināt piekļuvi datiem.Indeksi ir shēmas objekti, kas loģiski un fiziski ir neatkarīgi no datiem objektos, ar kuriem tie ir saistīti. Tādējādi indeksu var nodzēst vai izveidot, fiziski neietekmējot indeksēto tabulu. Ja tiek nodzēsts indekss, lietojumprogrammas joprojām darbojas. Tomēr piekļuve iepriekš indeksētiem datiem var būt lēnāka.Indeksi tiek izveidoti, izmantojot vairākas datu bāzes tabulas kolonnas:

1) pirmā kolonna ir meklēšanas atslēga, kas satur tabulas primārās atslēgas vai kandidātu atslēgas kopiju. Šīs vērtības tiek glabātas sakārtotā secībā, lai atbilstošajiem datiem varētu ātri piekļūt. Datus tabulās var saglabāt vai neglabāt sakārtotā secībā.

2) otra kolonna ir datu atsauce vai norāde (pointer), kurā ir norāžu kopa, kas satur diska bloka adresi, kur var atrast konkrēto atslēgas vērtību.

9

Indeksēšanas tipi

Primārais indekss ir sakārtots fails, kas ir ar fiksētu garuma un divām kolonām. Indeksa pamatā ir sakārtota vērtību secība. Pirmā kolona ir tāda pat kā tabulas primārā atslēga (tikai sakārtota). Otrā kolona ir norādes uz konkrēto datu bloku. Primārajā indeksā starp abām tabulas kolonām vienmēr ir saite viens ar vienu.Primārai indeksēšanai ir divi veidi:

1) blīvā (dense) indeksēšana. Katrā datu faila meklēšanas atslēgas vērtībai ir indeksa ieraksts. Ieraksts satur meklēšanas atslēgu un atsauci uz pirmo datu ierakstu ar šo meklēšanas atslēgas vērtību.

2) ne blīvā (sparse) jeb retinātā indeksēšana.

10

Blīvā indeksēšana

Blīvā (dense) indeksā tiek izveidots ieraksts katrai tabulas atslēgas vērtībai. Tas palīdz ātrāk meklēt, bet nepieciešams vairāk vietas, lai saglabātu indeksa ierakstus. Šajā indeksēšanā metodes ieraksti satur meklēšanas atslēgas vērtību un norāda uz reālo ierakstu diskā.

11

Ne blīvā jeb retinātā indeksēšana

Ne blīvajā (retinātajā) indeksēšanā indeksa ieraksts tiek veidots tikai dažām tabulas atslēgas vērtībām. Ne blīvais indekss palīdz atrisināt blīvās indeksēšanas problēmas. Šajā indeksēšanas metodē indeksa atslēgas noteiktā izmaiņu diapazonā tiek saglabāta viena un tā pati datu bloka adrese. Kad dati ir jāizgūst, tiek iegūta bloka adrese un vairāki tabulas raksti šajā blokā.Ne blīvajam indeksam vajag mazāk atmiņas, ir mazāk problēmu ar jaunu rakstu ievietošanu un dzēšanu, bet ir lēnāks, salīdzinot ar blīvo indeksu ierakstu izgūšanu.Retinātajā (sparse) indeksā:

1) indeksa ieraksts tiek parādīts tikai dažiem vienumiem datu failā. Katrs vienums norāda uz bloku, kā parādīts.

2) lai atrastu ierakstu, mēs atrodam indeksa ierakstu ar lielāko meklēšanas atslēgas vērtību, kas ir mazāka vai vienāda ar meklējamo meklēšanas atslēgas vērtību.

3) sākas ierakstu, uz kuru norāda indeksa ieraksts, un turpinās ar norādēm failā (tas ir, secīgi), līdz atrodam vajadzīgo ierakstu.

12

Sekundārais indekss

Sekundāro indeksu var ģenerēt:1) kolonai, kas ir kandidātatslēga un kurai katrā ierakstā ir unikāla vērtība;2) ne-kandidāta atslēgas kolonai ar vērtību dublikātiem.

Sekundāro (secondary) indeksu var izveidot kolonai, kurai katrā rakstā ir unikāla vērtība. Tā ir jābūt kandidāta atslēga (viena no pretendentēm uz primāro atslēgu). To sauc arī par neklastera indeksu (non-clustering index).Šī divu līmeņu datu bāzes tabulu indeksēšanas metode tiek izmantota, lai samazinātu pirmā līmeņa indeksēšanas apjomu. Pirmajam līmenim šī iemesla dēļ tiek atlasīti tikai lieli atslēgas vērtību diapazoni. Attēlošanas apjoms vienmēr paliek mazs.Piemēram, bankas kontu datu bāzē dati tiek glabāti secīgi pēc konta numuriem attiecīgās bankas filiālēs. Visus attīcīgās filiāles kontus var atrast norādot filiāli.Katram kontam ir sekundārais, kas nenorāda filiāli, bet konta glabāšanas vietu. sekundārais indekss.

13

Sekundārais indekss

Lietojumprogrammā var būt vairāki lietošanas gadījumi, kad datu bāze netiek pieprasīta ar primārās atslēgas vērtību. Ja nevar izmantot primāro atslēga, tad jāizvēlas cita kolona, kurai jāveido indekss papildus primārajam. Tie ir sekundārie indeksi.

Diagrammā sarkani taisnstūri attēlo sekundāros indeksa blokus. Sekundārais indekss tiek saglabāts arī B + kokā, un tas tiek kārtots pēc atslēgas, uz kuras tika izveidots indekss. Lapu mezgli satur primāro indeksu atbilstošo datu atslēgas kopiju.

Datu izgūšana, izmantojot sekundāro indeksu, nozīmē, ka jāšķērso divi B + koki — viens ir sekundārais indekss B + koks, bet otrs ir primārais indekss B + koks.

14

Sekundārā indeksa priekšrocības

Vara izveidot tik daudz sekundāro indeksu, cik vēlaties. Bet tas, cik daudz indeksu patiesībā ir nepieciešami, ir nopietni jāapsver, jo katram indeksam ir arī savas ēnas puses.

Sekundārā indeksa trūkumi

Izmantojot DML darbības, piemēram, DELETE un INSERT, ir jāatjaunina arī sekundārais indekss, lai primārās atslēgas kolonnas kopiju varētu dzēst vai ievietot. Šādos gadījumos sekundāro indeksu esamība var radīt problēmas.Tāpat, ja primārā atslēga ir ļoti liela kā URL, jo sekundārie indeksi satur primārās atslēgas kolonnas vērtības kopiju, krātuve var būt neefektīva. Papildu sekundārās atslēgas nozīmē lielāku primārās atslēgas kolonnas vērtības dublikātu skaitu, tātad lielāku krātuvi lielas primārās atslēgas gadījumā. Arī pati primārā atslēga saglabā atslēgas, tāpēc apvienotais efekts uz krātuvi būs ļoti liels.

15

Klasteru (salikts) indekss

Klasteru indekss ir definēts sakārtotam datu failam. Datu fails ir sakārtots pēc kolonas, kas nav atslēga, vērtībām.

Klasteru indeksā ieraksti arī tiek glabāti indeksā, nevis norādes uz bloku. Dažreiz indekss tiek izveidots kolonnām, kas nav primārās atslēgas un kas var nebūt unikālas katram ierakstam. Šādā gadījumā var grupēt divas vai vairāk kolonnas, lai iegūtu unikālās vērtības un izveidotu indeksu, ko sauc par klasterēto indeksu. Tas palīdz arī ātrāk identificēt ierakstu.

Piemērs. Pieņemsim, ka uzņēmums pieņēma darbā daudzus darbiniekus dažādās nodaļās. Šajā gadījumā klasteru indeksēšana ir jāizveido visiem darbiniekiem, kas pieder vienai un tai pašai nodaļai. Indeksa vērtība norāda uz klasteri kopumā.

16

Fails, kura datu organizāciju nosaka heš (hash) funkcija. Šādu failu organizāciju sauc arī par heš-failu organizāciju. Indeksu pamatā ir vērtības, kas vienmērīgi sadalītas starp rakstu buķetēm (buckets). Buķeti, kurai vērtība tiek piekārtota nosaka heš-funkcija, ko sauc arī par jaukšanas funkciju.Ir trīs indeksēšanas metodes:1) klaterēta indeksēšana;2) neklasterēta vai sekundāra indeksēšana;3) vairāklīmeņu indeksēšana.

17

Klasterēta indeksēšana

Ja vienā failā tiek glabāti vairāk nekā divi ieraksti, šie glabāšanas veidi ir pazīstami kā klasteru indeksēšana. Izmantojot klastera indeksēšanu, mēs varam samazināt meklēšanas izmaksas, jo vairāki ieraksti, kas saistīti ar vienu un to pašu lietu, tiek saglabāti vienā vietā. Tas arī nodrošina vairāku tabulu kopīgu ierakstu glabāšanu vienuviet.Klasteru noteikšanas indekss ir definēts sakārtotā datu failā. Datu fails ir sakārtots pēc lauka, kas nav atslēga. Dažos gadījumos indekss tiek veidots kolonnās, kas nav primārās atslēgas un var nebūt unikālas katram ierakstam. Šādos gadījumos, lai ātrāk identificētu ierakstus, tiek sagrupētas kopā divas vai vairākas kolonnas, lai iegūtu unikālās vērtības un no tām izveidotu indeksu. Šo metodi sauc par klasteru indeksu. Būtībā ieraksti ar līdzīgiem raksturlielumiem ir sagrupēti, un šīm grupām tiek izveidoti indeksi.Piemēram, studenti, kas studē katrā semestrī, ir sagrupēti kopā, t. i., 1. semestra studenti, 2. semestra studenti, 3. semestra studenti utt..Klāsterētais indeks šķiro pēc meklēšanas atslēgas.Primārā indeksēšana. Šis ir klāsterētās indeksēšanas tips, kurā dati tiek kārtoti atbilstoši meklēšanas atslēgai un indeksa izveidei tiek izmantota datu bāzes tabulas primārā atslēga. Tas ir indeksēšanas noklusējuma formāts, kur tas izraisa secīgu failu organizāciju. Tā kā primārās atslēgas ir unikālas un tiek glabātas sakārtotā veidā, meklēšanas operācijas veiktspēja ir diezgan efektīva.

18

19

Negrupēta (non-clustered) vai sekundāra indeksēšana

Negrupēts indekss tikai norāda, kur atrodas dati, t.i., tas sniedz virtuālu norāžu sarakstu vai atsauces uz atrašanās vietu, kur dati faktiski tiek glabāti. Dati netiek fiziski uzglabāti indeksa secībā. Tā vietā lapu zaros ir dati. Piemēram, grāmatas satura lappuse. Katrs ieraksts norāda saglabātās informācijas lapas numuru vai atrašanās vietu. Faktiskie dati šeit (informācija katrā grāmatas lappusē) nav organizēti, bet mums ir sakārtota atsauce (satura lapa) uz to, kur patiesībā atrodas datu punkti. Mums var būt tikai blīva pasūtīšana negrupētajā indeksā, jo neierobežota pasūtīšana nav iespējama, jo dati nav fiziski atbilstoši sakārtoti.Tas prasa vairāk laika salīdzinājumā ar sagrupēto indeksu, jo papildu darbs tiek veikts, lai iegūtu datus, turpinot sekot rādītājam. Sagrupētā indeksa gadījumā dati ir tieši priekšā indeksam.

20

Daudzlīmeņu indeksēšana

Pieaugot datu bāzes lielumam, aug arī indeksi. Tā kā indekss tiek glabāts galvenajā atmiņā, viena līmeņa indekss var kļūt par pārāk lielu lielumu, lai to saglabātu ar vairāku disku piekļuvi. Vairāklīmeņu indeksēšana nošķir galveno bloku dažādos mazākos blokos, lai tas pats varētu saglabāt vienā blokā. Ārējie bloki ir sadalīti iekšējos blokos, kas savukārt ir vērsti pret datu blokiem. To var viegli saglabāt galvenajā atmiņā ar mazāku pieskaitāmo izmaksu skaitu.

21

Indeksa veidi1

Nozīmīgākie indeksu veidi ir:1) B - koki, kas ir īsi jeb ar līdzsvarotu garumu. Tas ir visizplatītākais datu

bāzes indeksa veids;2) indeksa unikālā skenēšana atgriež ne vairāk kā 1 ROWID (rindas

identifikatoru);3) indeksa diapazona skenēšana ir sakārtota vērtību skenēšana;4) indeksa pilna skenēšana nolasa visu indeksu secībā. Indeksa pilna

skenēšana var likvidēt atsevišķu kārtošanas darbību, jo dati indeksā tiek sakārtoti pēc indeksa atslēgas.

5) indeksa ātrā pilnā skenēšana lasa indeksa blokus nešķirotā secībā, kā tie ir diskā. Šī skenēšana neizmanto indeksu, lai darbotos ar tabulu, bet lasa indeksu tabulas vietā, būtībā izmantojot pašu indeksu kā tabulu.

6) indekss izlaiž skenēšanu (index skip scan), ja saliktā indeksa sākotnējā kolonna ir “izlaista” vai nav norādīta vaicājumā;

7) indeksa savienotā skenēšana (index join scan) ir vairāku indeksu jaukts savienojums, kas kopā atgriež visas vaicājuma pieprasītās kolonnas. Datu bāzei nav nepieciešams piekļūt tabulai, jo visi dati tiek izgūti no indeksiem.

1 https://docs.oracle.com/en/database/oracle/oracle-database/18/tgsql/optimizer-access-paths.html#GUID-B33945C3-CCC0-4D35-AF62-DB80FD4256A6

22

B – koka indekss

Visizplatītākais datu bāzes indeksa veids ir b–koki (balansētie jeb līdzsvarotie koki). B koka indekss ir sakārtots vērtību saraksts, kas sadalīts diapazonos. Saistot atslēgu ar rindu vai diapazonu, B-koki nodrošina izcilu izgūšanas veiktspēju plašam vaicājumu klāstam, ieskaitot precīzu atbilstību un diapazona meklēšanu.B koka indeksam ir divu veidu bloki:

1)zaru bloki meklēšanai;2)lapu bloki, kas saglabā vērtības.

Attēls parāda B koka indeksa loģisko struktūru. Zaru bloki saglabā minimālo atslēgas prefiksu, kas nepieciešams, lai pieņemtu lēmumu par atzarošanu starp divām atslēgām. Lapu bloki satur katru indeksēto datu vērtību un atbilstošo rowid, ko izmanto, lai atrastu faktisko rindu. Katra indeksa ievadne tiek kārtota pēc (key, rowid). Lapu bloki ir divkārši saistīti.

23

B-koka indeksa piemērs

24

Indeksu skenējumi (index scan)

Indeksa skenēšanā datu bāze iegūst rindu, šķērsojot indeksu, izmantojot indeksētās kolonnas vērtības, kas norādītas priekšrakstā. Ja datu bāze skenē indeksu, lai iegūtu vērtību, tā atrod šo vērtību laukā n I/Os adresēs, kur n ir B koka indeksa augstums. Tas ir datu bāzes indeksu pamatprincips.Ja SQL priekšraksts piekļūst tikai indeksētām kolonnām, tad datu bāze nolasa vērtības tieši no indeksa, nevis no tabulas. Ja priekšraksts piekļūst neindeksētām kolonnām papildus indeksētajām kolonnām, tad datu bāze izmanto ROWIDs, lai atrastu tabulas rindas. Parasti datu bāze izgūst tabulas datus, pārmaiņus lasot indeksa bloku un pēc tam tabulas bloku.

25

Indeksa unikāls skenējums (unique scan)

Indeksa unikālā skenēšana atgriež ne vairāk kā 1 rindas identifikatoru ROWID. Indeksam unikālai skenēšanai ir nepieciešams vienādības predikāts.DBS veic unikālu skenēšanu tikai tad, ja ir spēkā šādi nosacījumi:

1) vaicājuma predikāts pārbauda uz visām unikālās indeksa atslēgas kolonnām, izmantojot vienlīdzības operatoru, piemēram, WHERE NUM = 15;

2) SQL priekšraksts satur vienādības predikātu kolonnā, uz kuru atsaucas indekss, kas izveidots ar CREATE UNIQUE INDEX priekšrakstu.

Unikāls vai primārās atslēgas ierobežojums pats par sevi nav pietiekams, lai radītu indeksu unikālu skenējumu. Piemērā izveidots primārās atslēgas ierobežojums kolonnai ar neunikālu indeksu, kā rezultātā notiek indeksa diapazona skenēšana, nevis indeksa unikāls skenējums:

create table TABULA(NUM int);create index IND_NUM on TABULA(NUM);alter table TABULA add constraint IER_PK primary key(NUM);select * from TABULA where NUM =1;

--------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |--------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 13 | 1 (0)| 00:00:01 ||* 1 | INDEX RANGE SCAN| IND_NUM | 1 | 13 | 1 (0)| 00:00:01 |-------------------------------------------------------------------------------- Lai norādītu izmantojamo indeksu, var izmantot INDEX (indeksa_nosaukums) ieteikumu (hint), bet ne konkrētu indeksa piekļuves ceļa tipu.Skenēšana meklē indeksu, lai iegūtu norādīto atslēgu. Indeksa unikālā skenēšana pārtrauc apstrādi, tiklīdz atrod pirmo ierakstu, jo nav iespējams otrais ieraksts. Datu bāze iegūst ROWID no alfabētiskā rādītāja ievadnes un pēc tam izgūst rindu, ko norādījis ROWID.

26

Attēlā ir parādīta indeksa unikālā skenēšana. Vaicājums pieprasa rakstu, kuram produkta ID = 19, kurai ir primārās atslēgas indekss (unikāls indekss).

SELECT * FROM sh.products WHERE prod_id = 19;

--------------------------------------------------------------------------------| Id| Operation | Name |Rows|Bytes|Cost (%CPU)|Time |--------------------------------------------------------------------------------| 0| SELECT STATEMENT | | | | 1 (100)| || 1| TABLE ACCESS BY INDEX ROWID| PRODUCTS | 1 | 173 | 1 (0)| 00:00:01||* 2| INDEX UNIQUE SCAN | PRODUCTS_PK | 1 | | 0 (0)| |--------------------------------------------------------------------------------

27

Indeksa diapazona skenējumiIndeksa diapazona skenēšana ir sakārtota vērtību skenēšana. Skenēšanas diapazons var būt:

1) norobežots no abām pusēm;2) nenorobežots no vienas puses;3) nenorobežots no abām pusēm.

Optimizētājs parasti izvēlas diapazona skenēšanu selektīviem vaicājumiem.Pēc noklusējuma datu bāze saglabā indeksus augošā secībā un skenē tos tādā pašā secībā. Piemēram, vaicājums ar predikātu department_id > = 20 izmanto diapazona skenēšanu, lai atgrieztu rindas, kas sakārtotas pēc indeksa atslēgām 20, 30, 40 utt. Ja vairākām alfabētiskā rādītāja ievadnēm ir identiskas atslēgas, tad datu bāze tās atgriež augošā secībā pēc ROWID, tā ka aiz 0, AAAPvCAAFAAAAFaAAa seko 0, AAAPvCAAFAAAAFaAAg utt.Indeksa diapazona skenēšana dilstošā secībā ir identiska indeksa diapazona skenējumam, izņemot to, ka datu bāze atgriež rindas dilstošā secībā. Parasti datu bāze izmanto dilstošu skenēšanu, kad dati ir dilstošā secībā vai meklējot vērtību, kas ir mazāka par norādīto vērtību.

Indeksa diapazona skenēšanai pielietošanai, indeksa atslēgai jābūt iespējamai vairākām vērtībām. Īpaši optimizētājs izskata indeksu diapazona skenējumus šādos apstākļos:

1) nosacījumos ir norādīta viena vai vairākas indeksa galvenās kolonnas. Nosacījums norāda vienas vai vairāku izteiksmju un loģisko (Būla) operatoru kombināciju un atgriež TRUE, FALSE vai UNKNOWN vērtību. Nosacījumi ir šādi:- Departament_id =: id- Departament_id <: id- Departament_id >: id

2) AND ar iepriekšējo nosacījumu kombināciju indeksa vadošajām kolonnām, piemēram, department_id >: zems UN department_id <: augsts. Lai optimizētājs varētu apsvērt diapazona skenēšanu, šablona kolonas, piemēram KOL1 LIKE '%ASD' nedrīkst būt vadošā pozīcijā.

3) 0, 1 vai vairākas vērtības ir iespējamas indeksa atslēgai;Padoms: Ja nepieciešams kārtot datus, izmantojiet ORDER BY klauzulas un nepaļaujieties uz indeksu. Ja indekss var izpildīt ORDER BY klauzulas, tad optimizētājs izmanto šo opciju un tādējādi izvairās no kārtošanas.Optimizētājs uzskata, ka indeksa diapazona skenēšana ir dilstoša, ja indekss var izpildīt ORDER BY DESCENDING klauzulas.Ja optimizētājs izvēlas pilnu tabulas skenēšanu vai citu indeksu, var būt nepieciešams norāde, kas uzspiež šo piekļuves ceļu. INDEKSA (tbl_alias ix_name) un INDEX_DESC (tbl_alias ix_name) norādes norāda, ka optimizētājam jāizmanto konkrēts indekss.

Indeksa diapazona skenēšanas laikā DBS pāriet no saknes uz zaru.Kopumā skenēšanas algoritms ir šāds:1. Izlasiet saknes bloku.2. Lasīt tālāk zara bloku.3. Lai izgūtu visus datus, veiciet šādas darbības:

- Izlasiet lapu bloku, lai iegūtu rowid.- Lai izgūtu rindu, izlasiet tabulas bloku.

Piezīme: dažos gadījumos alfabētiskā rādītāja skenēšana nolasa indeksu bloku kopu, kārto rowids un pēc tam lasa tabulu bloku kopu.Tādējādi, lai skenētu indeksu, datu bāze pārvietojas atpakaļ vai uz priekšu caur lapu blokiem. Piemēram, skenējot ID no 20 līdz 40, tiek atrasts pirmais lapu bloks, kura zemākā atslēgas vērtība ir 20

28

vai lielāka. Skenēšana notiek horizontāli caur saistīto lapu mezglu sarakstu, līdz tā atrod vērtību, kas ir lielāka par 40, un pēc tam tiek apturēta.Šajā attēlā attēlota indeksa diapazona skenēšana, izmantojot augošo secību. Pārskats pieprasa darbiniekiem ierakstīt vērtību 20 kolonnā department_id, kurai ir neunikāls indekss. Šajā piemērā pastāv 2 indeksa ieraksti 20. nodaļai.

This example retrieves a set of values from the employees table using an index range scan.The following statement queries the records for employees in department 20 with salaries greater than 1000:SELECT * FROM employees WHERE department_id = 20AND salary > 1000;The preceding query has low cardinality (returns few rows), so the query uses the index on the department_id column. The database scans the index, fetches the records from the employees table, and then applies the salary > 1000 filter to these fetched records to generate the result.

-------------------------------------SELECT * FROM employees WHERE department_id = 20 AND salary > 1000

-------------------------------------------------------------------------------------------|Id | Operation | Name |Rows|Bytes|Cost(%CPU)| Time |-------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 2 (100)| ||*1 | TABLE ACCESS BY INDEX ROWID BATCHED| EMPLOYEES | 2 | 138 | 2 (0)|00:00:01||*2 | INDEX RANGE SCAN | EMP_DEPARTMENT_IX| 2 | | 1 (0)|00:00:01|-------------------------------------------------------------------------------------------

29

Index Range Scan Descending: ExampleThis example uses an index to retrieve rows from the employees table in sorted order.The following statement queries the records for employees in department 20 in descending order:SELECT *FROM employeesWHERE department_id < 20ORDER BY department_id DESC;This preceding query has low cardinality, so the query uses the index on the department_id column.SQL_ID 8182ndfj1ttj6, child number 0-------------------------------------SELECT * FROM employees WHERE department_id < 20 ORDER BY department_id DESC Plan hash value: 1681890450--------------------------------------------------------------------------------|Id| Operation | Name |Rows|Bytes|Cost(%CPU)|Time |--------------------------------------------------------------------------------| 0| SELECT STATEMENT | | | | 2 (100)| || 1| TABLE ACCESS BY INDEX ROWID | EMPLOYEES | 2|138| 2 (0)|00:00:01||*2| INDEX RANGE SCAN DESCENDING| EMP_DEPARTMENT_IX | 2| | 1 (0)|00:00:01|-------------------------------------------------------------------------------- Predicate Information (identified by operation id):--------------------------------------------------- 2 - access("DEPARTMENT_ID"<20)The database locates the first index leaf block that contains the highest key value that is 20 or less. The scan then proceeds horizontally to the left through the linked list of leaf nodes. The database obtains the rowid from each index entry, and then retrieves the row specified by the rowid.

30

Pilna indeksa skenēšana

Pilna indeksa skenēšanā datu bāzes sistēma nolasa visu indeksu secībā. Pilna indeksa skenēšana ir pieejama:

1) ja predikāts (WHERE klauzula) SQL priekšrakstā atsaucas uz kolonnu indeksā;

2) dažos gadījumos, kad predikāts nav norādīts. Pilna skenēšana var novērst kārtošanu, jo dati tiek sakārtoti pēc indeksa atslēgas.Pieņemsim, ka lietojumprogramma izpilda šādu vaicājumu:

select NODALAS_ID, UZV, ALGAfrom DARBINIEKIwhere ALGA > 5000order by NODALAS_ID, UZV;

Šajā piemērā NODALAS_ID, UZV un ALGA ir salikta indeksa atslēga. DBS veic pilnu indeksa skenēšanu, lasot to sakārtotā secībā (sakārtots pēc nodaļas ID un uzvārda) un filtrējot algas atribūtu. Šādi datu bāze skenē datu kopu, kas ir mazāka par darbinieku tabulu, kurā ir vairāk kolonnu nekā vaicājumā, un izvairās no datu kārtošanas.

31

Piemērs izmanto indeksa pilnu skenēšanu, lai apmierinātu vaicājumu ar ORDER BY klauzulu. Vaicājums pieprasa nodaļu ID un nosaukumu nodaļas ID secībā:

select NODALAS_ID, NODALAS_NOSfrom NODALASorder by NODALAS_ID;

DBS nolasa saknes bloku un pēc tam navigē uz leju pa indeksa kreiso pusi (vai pa labi, ja veic dilstošu pilnu skenēšanu), līdz tā sasniedz lapu bloku.Kad tiek sasniegts lapu bloks, skenēšana notiek pa indeksa apakšu, pa vienam blokam, sakārtotā secībā. DBS izmanto viena bloka ievad/izvades, nevis multibloku ievad/izvades. Attēls ilustrē indeksa pilnu skenēšanu.

Izpildes plāns parāda, ka optimizētājs izvēlējās indeksa pilnu skenēšanu:

--------------------------------------------------------------------------------|Id | Operation | Name |Rows|Bytes|Cost(%CPU)|Time |--------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 2 (100)| || 1 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 27 | 432 | 2 (0)| 00:00:01 || 2 | INDEX FULL SCAN | DEPT_ID_PK | 27 | | 1 (0)| 00:00:01 |--------------------------------------------------------------------------------

32

Ātrā pilna indeksa skenēšana (fast full index scan)

Ātra pilna indeksa skenēšana ir:1) pilna indeksa skenēšana;2) datu bāzes sistēma piekļūst datiem pašā indeksā neizmantojot datu

tabulu;3) datu bāze lasa indeksa blokus bez īpašas kārtības.

Indeksa ātrā pilnā skenēšana lasa indeksa blokus nesakārtotā secībā, kā tie pastāv diskā. Šī skenēšana neizmanto indeksu, lai ātrāk iegūtu datus no tabulas, bet lasa indeksu tabulas vietā, būtībā izmantojot pašu indeksu kā tabulu.Ātra pilna indeksa skenēšana ir alternatīva pilnai tabulas skenēšanai, ja ir izpildīti abi šie nosacījumi:

1) indeksā ir jābūt visām vaicājumam nepieciešamajām kolonnām;2) rinda, kas satur visas nulles, nedrīkst parādīties vaicājuma rezultātu

kopā. Lai garantētu šo rezultātu, vismaz vienā indeksa kolonā jābūt:- ierobežojumam NOT NULL; - kādai kolonnai (indeksā) lietots predikāts, kas neļauj vaicājuma

rezultātu kopā uzskatīt par NULL.

Pieņemsim, ka lietojumprogramma izdod šādu vaicājumu, kas neietver ORDER BY klauzulu:

select UZV, ALGAfrom DARBINIEKI;

Kolonnai last_name ir ierobežojums Null. Ja uzvārds un alga ir salikta atslēga alfabētiskajā rādītājā, ātrā pilnajā alfabētiskajā attēlā var lasīt alfabētiskā rādītāja ievadnes, lai iegūtu pieprasīto informāciju:

Baida, 2900, rowidAtkinson, 2800, rowidZlotkey, 10500, rowidAustin, 7200, rowidBaer, 10000, rowidAustin, 4800, rowid

33

Optimizētājs izvēlas šo skenējumu, kad vaicājums indeksā piekļūst vajadzīgajiem atribūtiem. Atšķirībā no pilnas skenēšanas ātrā skenēšana nevar veikt kārtošanas darbību, jo tā nelasa indeksa rādītāju secībā.INDEX_FFS (tabulas_nosaukums indeksa_nosaukums) ieteikums (hint) norāda, ka vēlams ātrā pilna indeksa skenēšanu.

DBS izmanto multiblock I/O, lai nolasītu saknes bloku un visus lapu un zaru blokus. DBS ignorē zarus un saknes blokus un lasa lapu bloku alfabētiskos ierakstus.Šajos piemēros optimizētāja mājiena rezultātā tiek izmantota ātra pilna indeksa skenēšana.Šāds priekšraksts pieprasa nodaļu ID un nosaukumu nodaļas ID secībā:

SELECT /*+ INDEX_FFS(departments dept_id_pk) */ COUNT(*)FROM departments;

--------------------------------------------------------------------------| Id | Operation | Name | Rows |Cost (%CPU)| Time |--------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | 2 (100)| || 1 | SORT AGGREGATE | | 1 | | || 2 | INDEX FAST FULL SCAN| DEPT_ID_PK | 27 | 2 (0)| 00:00:01 |--------------------------------------------------------------------------

34

create table STUDENTI_FFS(UZV varchar2(20),VAR varchar2(20),S_NUM number,KURSSnumber,DZIM varchar2(10),NUM_F number);

begininsert into STUDENTI_FFS values('Koks', 'Jūlijs', 1001, 5, 'vīrietis', 1);insert into STUDENTI_FFS values('Lapa', 'Liene', 1002, 4, 'sieviete', 2);insert into STUDENTI_FFS values('Grasis', 'Indulis', 1003, 3, 'vīrietis', 1);insert into STUDENTI_FFS values('Egle', 'Rasma', 1004, 3, 'sieviete', 2);insert into STUDENTI_FFS values('Strauts', 'Varis', 1005, 5, 'vīrietis', 3);insert into STUDENTI_FFS values('Sakne', 'Juris', 1006, 2, 'vīrietis', 1);insert into STUDENTI_FFS values('Zars', 'Inese', 1007, 2, 'sieviete', 2);insert into STUDENTI_FFS values('Zirnis', 'Atis', 1008, 1, 'vīrietis', 3);insert into STUDENTI_FFS values('Avots', 'Anita', 1009, 2, 'sieviete', 3);insert into STUDENTI_FFS values('Apse', 'Alnis', 1010, 1, 'vīrietis', 1);end;

select COUNT(*)from STUDENTI_FFS;

create index IND_FFS on STUDENTI_FFS(S_NUM);

SELECT /*+ INDEX_FFS(STUDENTI_FFS IND_FFS) */ COUNT(*)FROM STUDENTI_FFS;

35

36

Indeksa skenēšana ar izlaišanu (skip scans)

Indeksa skenēšana ar izlaišanu notiek, ja saliktā indeksa sākotnējā kolonna ir “izlaista” vai nav norādīta vaicājumā.Bieži vien skenēšana indeksu blokos ar izlaišanu ir ātrāk nekā skenēt tabulas blokus un ātrāk nekā veikt pilna indeksa skenējumus.Optimizētājs uzskata, ka jārealizē skenēšana ar izlaišanu, ja ir izpildīti šādi kritēriji:

1) kompozīta indeksa galvenā kolonna vaicājuma predikātā nav norādīta. Piemēram, vaicājumu predikāts neattiecas uz cust_gender kolonnu, bet saliktā indeksa atslēga ir (cust_gender, cust_email).

2) kombinētā indeksa galvenajā kolonnā ir mazāk atšķirīgu vērtību, bet indeksa pārējā atslēgas daļā ir daudz atšķirīgu vērtību.

Piemēram, ja saliktā indeksa atslēga ir (cust_gender, cust_email), tad cust_gender kolonnai ir tikai divas atšķirīgas vērtības, bet cust_email ir tūkstošiem.Tiek realizēta indekss skenēšana izlaižot, loģiski sadalot salikto indeksu mazākos apakšindeksos.Atšķirīgo vērtību skaits indeksa galvenajās kolonnās nosaka loģisko apakšindeksu skaitu. Jo mazāks skaits, jo mazāk loģisko apakšindeksu ir jāizveido optimizētājam, un jo efektīvāka kļūst skenēšana. Skenēšana nolasa katru loģisko indeksu atsevišķi, bet “izlaiž” indeksa blokus, kas neatbilst filtra nosacījumam nevadošajā kolonnā.

This example uses an index skip scan to satisfy a query of the customers table.The customers table contains a column cust_gender whose values are either M or F. You create a composite index on the columns (cust_gender, cust_email) as follows:CREATE INDEX cust_gender_email_ix ON sh.customers (cust_gender, cust_email);Conceptually, a portion of the index might look as follows, with the gender value of F or M as the leading edge of the index.F,Wolf@company.example.com,rowidF,Wolsey@company.example.com,rowidF,Wood@company.example.com,rowidF,Woodman@company.example.com,rowidF,Yang@company.example.com,rowidF,Zimmerman@company.example.com,rowidM,Abbassi@company.example.com,rowidM,Abbey@company.example.com,rowidYou run the following query for a customer in the sh.customers table:

37

SELECT * FROM sh.customers WHERE cust_email = 'Abbey@company.example.com';The database can use a skip scan of the customers_gender_email index even though cust_gender is not specified in the WHERE clause. In the sample index, the leading column cust_gender has two possible values: F and M. The database logically splits the index into two. One subindex has the key F, with entries in the following form:F,Wolf@company.example.com,rowidF,Wolsey@company.example.com,rowidF,Wood@company.example.com,rowidF,Woodman@company.example.com,rowidF,Yang@company.example.com,rowidF,Zimmerman@company.example.com,rowidThe second subindex has the key M, with entries in the following form:M,Abbassi@company.example.com,rowidM,Abbey@company.example.com,rowidWhen searching for the record for the customer whose email is Abbey@company.com, the database searches the subindex with the leading value F first, and then searches the subindex with the leading value M. Conceptually, the database processes the query as follows:( SELECT * FROM sh.customers WHERE cust_gender = 'F' AND cust_email = 'Abbey@company.com' )UNION ALL( SELECT * FROM sh.customers WHERE cust_gender = 'M' AND cust_email = 'Abbey@company.com' )The plan for the query is as follows:SQL_ID d7a6xurcnx2dj, child number 0-------------------------------------SELECT * FROM sh.customers WHERE cust_email = 'Abbey@company.example.com'

-----------------------------------------------------------------------------------------|Id| Operation | Name |Rows|Bytes|Cost(%CPU)|Time|-----------------------------------------------------------------------------------------| 0|SELECT STATEMENT | | | |10(100)| || 1| TABLE ACCESS BY INDEX ROWID BATCHED| CUSTOMERS |33|6237| 10(0)|00:00:01||*2| INDEX SKIP SCAN | CUST_GENDER_EMAIL_IX |33| | 4(0)|00:00:01|----------------------------------------------------------------------------------------- Index Skip ScanAn index skip scan uses logical subindexes of a composite index. The database "skips" through a single index as if it were searching separate indexes. Skip scanning is beneficial if there are few distinct values in the leading column of a composite index and many distinct values in the nonleading key of the index. The database may choose an index skip scan when the leading column of the composite index is not specified in a query predicate. Example 3-3 Skip Scan of a Composite IndexAssume that you run the following query for a customer in the sh.customers table: SELECT * FROM sh.customers WHERE cust_email = 'Abbey@company.example.com';

38

The customers table has a column cust_gender whose values are either M or F. Assume that a composite index exists on the columns (cust_gender, cust_email). The following example shows a portion of the index entries: F,Wolf@company.example.com,rowidF,Wolsey@company.example.com,rowidF,Wood@company.example.com,rowidF,Woodman@company.example.com,rowidF,Yang@company.example.com,rowidF,Zimmerman@company.example.com,rowidM,Abbassi@company.example.com,rowidM,Abbey@company.example.com,rowidThe database can use a skip scan of this index even though cust_gender is not specified in the WHERE clause. In a skip scan, the number of logical subindexes is determined by the number of distinct values in the leading column. In the preceding example, the leading column has two possible values. The database logically splits the index into one subindex with the key F and a second subindex with the key M. When searching for the record for the customer whose email is Abbey@company.example.com, the database searches the subindex with the value F first and then searches the subindex with the value M. Conceptually, the database processes the query as follows: SELECT * FROM sh.customers WHERE cust_gender = 'F' AND cust_email = 'Abbey@company.example.com'UNION ALLSELECT * FROM sh.customers WHERE cust_gender = 'M' AND cust_email = 'Abbey@company.example.com';

39

Indeksa savienojuma skenējumi (index join scans)

Indeksa savienojuma skenēšana ir vairāku indeksu jaukts savienojums, kas kopā atgriež visas vaicājuma pieprasītās kolonnas. DBS nav nepieciešams piekļūt tabulai, jo visi dati tiek izgūti no indeksiem.Dažos gadījumos visrentablākā iespēja ir izvairīties no nepieciešamās piekļuves tabulām.Optimizētājs izmanto indeksa savienojumu šādos gadījumos:

1) vairāku indeksu heš-savienojums izgūst visus vaicājuma pieprasītos datus, nepieprasot piekļuvi tabulai;

2) rindu izgūšana no tabulas ir ar lielāku laika ietilpību nekā indeksu lasīšana, neveicot rindu izgūšanu no tabulas. Indeksa savienojums bieži ir dārgs. Piemēram, skenējot divus indeksus un pievienojot tos, bieži vien ir lētāk izvēlēties selektīvāko indeksu un pēc tam apstrādāt tabulu.

Indeksa savienojumu var norādīt, izmantojot ieteikumu INDEX_JOIN (tabulas nosaukums).

Indeksa savienojums ietver vairāku indeksu skenēšanu un pēc tam no šiem skenējumiem iegūto rowids heš-savienojuma izmantošanu, lai atgrieztu rindas.Indeksa pievienošanas skenēšanā vienmēr tiek novērsta piekļuve tabulai. Piemēram, divu indeksu pievienošanas process vienā tabulā ir šāds:1. Skenējiet pirmo indeksu, lai izgūtu rowids.2. Lai izgūtu rowids, skenējiet otro indeksu.3. Lai iegūtu rindas, veiciet jaukšanas savienojumu ar ROWID.

The following statement queries the last name and email for employees whose last name begins with A, specifying an index join:SELECT /*+ INDEX_JOIN(employees) */ last_name, emailFROM employeesWHERE last_name like 'A%';Separate indexes exist on the (last_name,first_name) and email columns. Part of the emp_name_ix index might look as follows:Banda,Amit,AAAVgdAALAAAABSABDBates,Elizabeth,AAAVgdAALAAAABSABIBell,Sarah,AAAVgdAALAAAABSABc

40

Bernstein,David,AAAVgdAALAAAABSAAzBissot,Laura,AAAVgdAALAAAABSAAdBloom,Harrison,AAAVgdAALAAAABSABFBull,Alexis,AAAVgdAALAAAABSABVThe first part of the emp_email_uk index might look as follows:ABANDA,AAAVgdAALAAAABSABDABULL,AAAVgdAALAAAABSABVACABRIO,AAAVgdAALAAAABSABXAERRAZUR,AAAVgdAALAAAABSAAvAFRIPP,AAAVgdAALAAAABSAAVAHUNOLD,AAAVgdAALAAAABSAADAHUTTON,AAAVgdAALAAAABSABLExample 8-4 retrieves the plan using the DBMS_XPLAN.DISPLAY_CURSOR function. The database retrieves all rowids in the emp_email_uk index, and then retrieves rowids in emp_name_ix for last names that begin with A. The database uses a hash join to search both sets of rowids for matches. For example, rowid AAAVgdAALAAAABSABD occurs in both sets of rowids, so the database probes the employees table for the record corresponding to this rowid.Example 8-4 Index Join ScanSQL_ID d2djchyc9hmrz, child number 0-------------------------------------SELECT /*+ INDEX_JOIN(employees) */ last_name, email FROM employeesWHERE last_name like 'A%'

Plan hash value: 3719800892-------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |-------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 3 (100)| ||* 1 | VIEW | index$_join$_001 | 3 | 48 | 3 (34)| 00:00:01 ||* 2 | HASH JOIN | | | | | ||* 3 | INDEX RANGE SCAN | EMP_NAME_IX | 3 | 48 | 1 (0)| 00:00:01 || 4 | INDEX FAST FULL SCAN| EMP_EMAIL_UK | 3 | 48 | 1 (0)| 00:00:01 |-------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):--------------------------------------------------- 1 - filter("LAST_NAME" LIKE 'A%') 2 - access(ROWID=ROWID) 3 - access("LAST_NAME" LIKE 'A%')

41

Index Clustering Factor

The index clustering factor measures row order in relation to an indexed value such as employee last name. As the degree of order increases, the clustering factor decreases. The clustering factor is useful as a rough measure of the number of I/Os required to read an entire table using an index: If the clustering factor is high, then Oracle Database performs a relatively high number of I/Os during a large index range scan. The index entries point to random table blocks, so the database may have to read and reread the same blocks over and over again to retrieve the data pointed to by the index. If the clustering factor is low, then Oracle Database performs a relatively low number of I/Os during a large index range scan. The index keys in a range tend to point to the same data block, so the database does not have to read and reread the same blocks over and over.The clustering factor is relevant for index scans because it can show: Whether the database will use an index for large range scans The degree of table organization in relation to the index key Whether you should consider using an index-organized table, partitioning, or table cluster if rows must be ordered by the index keyExample 3-4 Clustering FactorAssume that the employees table fits into two data blocks. Table 3-3 depicts the rows in the two data blocks (the ellipses indicate data that is not shown). Table 3-3 Contents of Two Data Blocks in the Employees TableData Block 1 Data Block 2

100 Steven King SKING ...156 Janette King JKING ...115 Alexander Khoo AKHOO ......116 Shelli Baida SBAIDA ...204 Hermann Baer HBAER ...105 David Austin DAUSTIN ...130 Mozhe Atkinson MATKINSO ...166 Sundar Ande SANDE ...174 Ellen Abel EABEL ...

149 Eleni Zlotkey EZLOTKEY ...200 Jennifer Whalen JWHALEN ......137 Renske Ladwig RLADWIG ...173 Sundita Kumar SKUMAR ...101 Neena Kochar NKOCHHAR ...

Rows are stored in the blocks in order of last name (shown in bold). For example, the bottom row in data block 1 describes Abel, the next row up describes Ande, and so on alphabetically until the top row in block 1 for Steven King. The bottom row in block 2 describes Kochar, the next row up describes Kumar, and so on alphabetically until the last row in the block for Zlotkey.Assume that an index exists on the last name column. Each name entry corresponds to a rowid. Conceptually, the index entries would look as follows:Abel,block1row1Ande,block1row2Atkinson,block1row3Austin,block1row4Baer,block1row5..

42

.Assume that a separate index exists on the employee ID column. Conceptually, the index entries might look as follows, with employee IDs distributed in almost random locations throughout the two blocks:100,block1row50101,block2row1102,block1row9103,block2row19104,block2row39105,block1row4...The following statement queries the ALL_INDEXES view for the clustering factor for these two indexes: SQL> SELECT INDEX_NAME, CLUSTERING_FACTOR 2 FROM ALL_INDEXES 3 WHERE INDEX_NAME IN ('EMP_NAME_IX','EMP_EMP_ID_PK'); INDEX_NAME CLUSTERING_FACTOR-------------------- -----------------EMP_EMP_ID_PK 19EMP_NAME_IX 2The clustering factor for EMP_NAME_IX is low, which means that adjacent index entries in a single leaf block tend to point to rows in the same data blocks. The clustering factor for EMP_EMP_ID_PK is high, which means that adjacent index entries in the same leaf block are much less likely to point to rows in the same data blocks.

43

Reverse Key Indexes

A reverse key index is a type of B-tree index that physically reverses the bytes of each index key while keeping the column order. For example, if the index key is 20, and if the two bytes stored for this key in hexadecimal are C1,15 in a standard B-tree index, then a reverse key index stores the bytes as 15,C1. Reversing the key solves the problem of contention for leaf blocks in the right side of a B-tree index. This problem can be especially acute in an Oracle Real Application Clusters (Oracle RAC) database in which multiple instances repeatedly modify the same block. For example, in an orders table the primary keys for orders are sequential. One instance in the cluster adds order 20, while another adds 21, with each instance writing its key to the same leaf block on the right-hand side of the index. In a reverse key index, the reversal of the byte order distributes inserts across all leaf keys in the index. For example, keys such as 20 and 21 that would have been adjacent in a standard key index are now stored far apart in separate blocks. Thus, I/O for insertions of sequential keys is more evenly distributed.Because the data in the index is not sorted by column key when it is stored, the reverse key arrangement eliminates the ability to run an index range scanning query in some cases. For example, if a user issues a query for order IDs greater than 20, then the database cannot start with the block containing this ID and proceed horizontally through the leaf blocks.

44

Ascending and Descending Indexes

In an ascending index, Oracle Database stores data in ascending order. By default, character data is ordered by the binary values contained in each byte of the value, numeric data from smallest to largest number, and date from earliest to latest value. For an example of an ascending index, consider the following SQL statement:CREATE INDEX emp_deptid_ix ON hr.employees(department_id); Oracle Database sorts the hr.employees table on the department_id column. It loads the ascending index with the department_id and corresponding rowid values in ascending order, starting with 0. When it uses the index, Oracle Database searches the sorted department_id values and uses the associated rowids to locate rows having the requested department_id value. By specifying the DESC keyword in the CREATE INDEX statement, you can create a descending index. In this case, the index stores data on a specified column or columns in descending order. If the index in Table 3-3 on the employees.department_id column were descending, then the leaf blocking containing 250 would be on the left side of the tree and block with 0 on the right. The default search through a descending index is from highest to lowest value. Descending indexes are useful when a query sorts some columns ascending and others descending. For an example, assume that you create a composite index on the last_name and department_id columns as follows: CREATE INDEX emp_name_dpt_ix ON hr.employees(last_name ASC, department_id DESC); If a user queries hr.employees for last names in ascending order (A to Z) and department IDs in descending order (high to low), then the database can use this index to retrieve the data and avoid the extra step of sorting it.

45

Overview of Bitmap Indexes

In a bitmap index, the database stores a bitmap for each index key. In a conventional B-tree index, one index entry points to a single row. In a bitmap index, each index key stores pointers to multiple rows. Bitmap indexes are primarily designed for data warehousing or environments in which queries reference many columns in an ad hoc fashion. Situations that may call for a bitmap index include: The indexed columns have low cardinality, that is, the number of distinct values is small compared to the number of table rows. The indexed table is either read-only or not subject to significant modification by DML statements.For a data warehouse example, the sh.customers table has a cust_gender column with only two possible values: M and F. Suppose that queries for the number of customers of a particular gender are common. In this case, the customers.cust_gender column would be a candidate for a bitmap index. Each bit in the bitmap corresponds to a possible rowid. If the bit is set, then the row with the corresponding rowid contains the key value. A mapping function converts the bit position to an actual rowid, so the bitmap index provides the same functionality as a B-tree index although it uses a different internal representation.If the indexed column in a single row is updated, then the database locks the index key entry (for example, M or F) and not the individual bit mapped to the updated row. Because a key points to many rows, DML on indexed data typically locks all of these rows. For this reason, bitmap indexes are not appropriate for many OLTP applications. See Also: Oracle Database SQL Tuning Guide to learn how to use bitmap indexes for performance Oracle Database Data Warehousing Guide to learn how to use bitmap indexes in a data warehouse Example: Bitmap Indexes on a Single TableIn this example, some columns of sh.customers table are candidates for a bitmap index. Consider the following query:SQL> SELECT cust_id, cust_last_name, cust_marital_status, cust_gender 2 FROM sh.customers 3 WHERE ROWNUM < 8 ORDER BY cust_id; CUST_ID CUST_LAST_ CUST_MAR C---------- ---------- -------- - 1 Kessel M 2 Koch F 3 Emmerson M 4 Hardy M 5 Gowen M 6 Charles single F 7 Ingram single F 7 rows selected.The cust_marital_status and cust_gender columns have low cardinality, whereas cust_id and cust_last_name do not. Thus, bitmap indexes may be appropriate on cust_marital_status and cust_gender. A bitmap index is probably not useful for the other columns. Instead, a unique B-tree index on these columns would likely provide the most efficient representation and retrieval. Table 3-4 illustrates the bitmap index for the cust_gender column output shown in the preceding example. It consists of two separate bitmaps, one for each gender.

46

Table 3-4 Sample Bitmap for One ColumnValue Row 1 Row 2 Row 3 Row 4 Row 5 Row 6 Row 7

M 1 0 1 1 1 0 0

F 0 1 0 0 0 1 1A mapping function converts each bit in the bitmap to a rowid of the customers table. Each bit value depends on the values of the corresponding row in the table. For example, the bitmap for the M value contains a 1 as its first bit because the gender is M in the first row of the customers table. The bitmap cust_gender='M' has a 0 for the bits in rows 2, 6, and 7 because these rows do not contain M as their value. Note:Bitmap indexes can include keys that consist entirely of null values, unlike B-tree indexes. Indexing nulls can be useful for some SQL statements, such as queries with the aggregate function COUNT. An analyst investigating demographic trends of the customers may ask, "How many of our female customers are single or divorced?" This question corresponds to the following SQL query:SELECT COUNT(*) FROM customers WHERE cust_gender = 'F' AND cust_marital_status IN ('single', 'divorced'); Bitmap indexes can process this query efficiently by counting the number of 1 values in the resulting bitmap, as illustrated in Table 3-5. To identify the customers who satisfy the criteria, Oracle Database can use the resulting bitmap to access the table. Table 3-5 Sample Bitmap for Two ColumnsValue Row 1 Row 2 Row 3 Row 4 Row 5 Row 6 Row 7

M 1 0 1 1 1 0 0

F 0 1 0 0 0 1 1

single 0 0 0 0 0 1 1

divorced 0 0 0 0 0 0 0

single or divorced, and F

0 0 0 0 0 1 1

Bitmap indexing efficiently merges indexes that correspond to several conditions in a WHERE clause. Rows that satisfy some, but not all, conditions are filtered out before the table itself is accessed. This technique improves response time, often dramatically.

47

Bitmap Join IndexesA bitmap join index is a bitmap index for the join of two or more tables. For each value in a table column, the index stores the rowid of the corresponding row in the indexed table. In contrast, a standard bitmap index is created on a single table.A bitmap join index is an efficient means of reducing the volume of data that must be joined by performing restrictions in advance. For an example of when a bitmap join index would be useful, assume that users often query the number of employees with a particular job type. A typical query might look as follows:SELECT COUNT(*) FROM employees, jobs WHERE employees.job_id = jobs.job_id AND jobs.job_title = 'Accountant';The preceding query would typically use an index on jobs.job_title to retrieve the rows for Accountant and then the job ID, and an index on employees.job_id to find the matching rows. To retrieve the data from the index itself rather than from a scan of the tables, you could create a bitmap join index as follows: CREATE BITMAP INDEX employees_bm_idx ON employees (jobs.job_title) FROM employees, jobsWHERE employees.job_id = jobs.job_id;As illustrated in the following figure, the index key is jobs.job_title and the indexed table is employees. Figure 3-2 Bitmap Join Index

Description of "Figure 3-2 Bitmap Join Index"Conceptually, employees_bm_idx is an index of the jobs.title column in the SQL query shown in the following query (sample output included). The job_title key in the index points to rows in the employees

48

table. A query of the number of accountants can use the index to avoid accessing the employees and jobs tables because the index itself contains the requested information. SELECT jobs.job_title AS "jobs.job_title", employees.rowid AS "employees.rowid"FROM employees, jobsWHERE employees.job_id = jobs.job_idORDER BY job_title; jobs.job_title employees.rowid----------------------------------- ------------------Accountant AAAQNKAAFAAAABSAALAccountant AAAQNKAAFAAAABSAANAccountant AAAQNKAAFAAAABSAAMAccountant AAAQNKAAFAAAABSAAJAccountant AAAQNKAAFAAAABSAAKAccounting Manager AAAQNKAAFAAAABTAAHAdministration Assistant AAAQNKAAFAAAABTAACAdministration Vice President AAAQNKAAFAAAABSAACAdministration Vice President AAAQNKAAFAAAABSAAB...In a data warehouse, the join condition is an equijoin (it uses the equality operator) between the primary key columns of the dimension tables and the foreign key columns in the fact table. Bitmap join indexes are sometimes much more efficient in storage than materialized join views, an alternative for materializing joins in advance.

49

Overview of Function-Based IndexesA function-based index computes the value of a function or expression involving one or more columns and stores it in an index. A function-based index can be either a B-tree or a bitmap index. The indexed function can be an arithmetic expression or an expression that contains a SQL function, user-defined PL/SQL function, package function, or C callout. For example, a function could add the values in two columns.Uses of Function-Based Indexes Function-based indexes are efficient for evaluating statements that contain functions in their WHERE clauses. The database only uses the function-based index when the function is included in a query. When the database processes INSERT and UPDATE statements, however, it must still evaluate the function to process the statement. Example 3-7 Index Based on Arithmetic ExpressionFor example, suppose you create the following function-based index:CREATE INDEX emp_total_sal_idx ON employees (12 * salary * commission_pct, salary, commission_pct);The database can use the preceding index when processing queries such as the following (partial sample output included):SELECT employee_id, last_name, first_name, 12*salary*commission_pct AS "ANNUAL SAL"FROM employeesWHERE (12 * salary * commission_pct) < 30000ORDER BY "ANNUAL SAL" DESC;

EMPLOYEE_ID LAST_NAME FIRST_NAME ANNUAL SAL----------- ------------------------- -------------------- ---------- 159 Smith Lindsey 28800 151 Bernstein David 28500 152 Hall Peter 27000 160 Doran Louise 27000 175 Hutton Alyssa 26400 149 Zlotkey Eleni 25200 169 Bloom Harrison 24000Example 3-8 Index Based on an UPPER FunctionFunction-based indexes defined on the SQL functions UPPER(column_name) or LOWER(column_name) facilitate case-insensitive searches. For example, suppose that the first_name column in employees contains mixed-case characters. You create the following function-based index on the hr.employees table: CREATE INDEX emp_fname_uppercase_idx ON employees ( UPPER(first_name) ); The emp_fname_uppercase_idx index can facilitate queries such as the following: SELECT * FROM employeesWHERE UPPER(first_name) = 'AUDREY';Example 3-9 Indexing Specific Rows in a TableA function-based index is also useful for indexing only specific rows in a table. For example, the cust_valid column in the sh.customers table has either I or A as a value. To index only the A rows, you could write a function that returns a null value for any rows other than the A rows. You could create the index as follows: CREATE INDEX cust_valid_idxON customers ( CASE cust_valid WHEN 'A' THEN 'A' END );See Also:

50

Oracle Database Globalization Support Guide for information about linguistic indexes Oracle Database SQL Language Reference to learn more about SQL functions Optimization with Function-Based IndexesFor queries with expressions in a WHERE clause, the optimizer can use an index range scan on a function-based index. The range scan access path is especially beneficial when the predicate is highly selective, that is, when it chooses relatively few rows. In Example 3-7, if an index is built on the expression 12*salary*commission_pct, then the optimizer can use an index range scan. A virtual column is also useful for speeding access to data derived from expressions. For example, you could define virtual column annual_sal as 12*salary*commission_pct and create a function-based index on annual_sal. The optimizer performs expression matching by parsing the expression in a SQL statement and then comparing the expression trees of the statement and the function-based index. This comparison is case-insensitive and ignores blank spaces.

51

Overview of Application Domain IndexesAn application domain index is a customized index specific to an application. Extensive indexing can: Accommodate indexes on customized, complex data types such as documents, spatial data, images, and video clips (see "Unstructured Data") Make use of specialized indexing techniquesYou can encapsulate application-specific index management routines as an indextype schema object, and then define a domain index on table columns or attributes of an object type. Extensible indexing can efficiently process application-specific operators.The application software, called the cartridge, controls the structure and content of a domain index. The database interacts with the application to build, maintain, and search the domain index. The index structure itself can be stored in the database as an index-organized table or externally as a file.