Kontrola paralelnog pristupa

ZAŠTITA BAZE PODATAKA

Problem rezervacije avionskih karata

Avionske karte za let 345 se prodaju na 2 mjesta,

preko mreže.

Još su ostale 3 karte.

Na dva mjesta prodavači u isto vrijeme dobiju

narudžbu:

Jedna narudžba za tri

Druga narudžba za dvije karte

Prodavači vide da još postoje 3 neprodane karte i

oba prodaju karte, iako ne postoji 5 karata.

u avionu postoje samo 3 mjesta.

Problem rezervacije avionskih karata

Tijek prodaje: I jedan i drugi prodavač su vidijeli da su 3 mjesta slobodna

Prvi je prodao 3, a drugi 2 karte

Onaj koji je prodao 2 karte je zadnji promijenio podatke i zapisao da je ostala još jedna karta

Posljedica Nakon što oba prodavača prodaju

jedan 2, a drugi 3 karte

nedostaju 2 karte, tj. dva puta su prodana ista mjesta

u bazi je zapisano da je ostala još 1 neprodana karta

Problem se može riješiti tako da prvo jedan prodavač proda karte

a zatim i drugi, na osnovu novih podataka dobivenih od prvog prodavača (0 karata ostalo).

Kontrola paralelnog pristupa

U višekorisničkom radu više programa može

istovremeno pristupiti istim podacima.

Potrebno je spriječiti da:

dva ili više korisnika programa istovremeno mijenjaju isti

podatak

neki programi pregledavaju podatak dok ga neki drugi

program mijenja.

Problemi paralelnog pristupa

Izgubljeni ili uništeni podaci

Javlja se kad 2 ili više transakcija u isto vrijeme

ažuriraju istu n-torku, ali na osnovi originalne n-torke →

zadnje ažuriranje ostaje trajno

Zadnje ažurirana n-torka se samo pojavljuje kao nova n-

torka

dok se ostale promjene gube

primjer problema rezervacije avionskih karata

Problem čitanja i mijenjanja

Jedan administrator čita podatke dva puta.

Između ta dva uzastopna čitanja, drugi administrator

mijenja podatke.

Prvi administrator u dva uzastopna čitanja dobije dva

različita podatke, koji bi trebali biti isti.

Problem se može riješiti

prvi administrator može čitati podatke samo nakon što

drugi završi izmjene na bazi i signalizira završetak

izmjena

Problemi višekorisničkog rada

Očekivani problemi višekorisničkog rada na bazi:

“nekonzistentni podaci” (nonrepeatable read)

Transakcija T1 može pročitati podatke koje će transakcija T2 promijeniti, dva uzastopna čitanja neće dati iste rezultate

“prljavo čitanje” (dirty read)

Transakcija T1 može pročitati podatke koje je netom promijenila transakcija T2 koja može završiti s dva ishoda

COMMIT

ROLLBACK

“fantomske n-torke ” (phantom reads)

Npr.

Transakcija T1 je prilikom izvršavanja naredbe SELECT…WHERE… pročitala je određene n-torke, transakcija T2 je dodala još jedan redak nakon tog čitanja, taj redak pojavit će se kao fantomska n-torka

“nekonzistentni podaci“

(nonrepeatable read)

Jedna transakcija mijenja n-torku

Druga transakcija čita tu n-torku

Druga transakcija svaki put pročita drugačije podatke

S obzirom da se radi o transakciji nužno je osigurati

konzistentnost podataka za kratko vrijeme

izvršavanja transakcije

“prljavo čitanje”

(dirty read)

Jedna transakcija mijenja podatke

Druga čita te iste podatke

Kod prve transakcija je npr. došlo do pogreške kod

upisa te prva transakcija još nije poslala trenutne

izmijene

druga transakcija je pročitala podatke koji uopće

neće biti rezultat prve transakcije

Problem se može riješiti

dok jedna transakcija mijenja podatke, druge transakcije ne

smiju čitati te podatke sve dok ta transakcija ne potvrdi

promjenu

“fantomske” n-torke

(phantom reads)

Pojavljuju se kada neka transakcija upisuje ili briše n-torke dok ih druga transakcija za to vrijeme čita.

Transakcija koja čita podatke pročita i one n-torke koje npr. prva transakcija upravo briše.

Ako u trenutku pregleda tablice jedne transakcije, druga transakcija unosi podatke, prva će “vidjeti” n-torke koje još ne postoje u bazi podataka

Problem se može riješiti niti jedna transakcija ne smije unositi nove podatke u

bazu dok ostale transakcije nisu završile raditi s originlnom bazom podataka

ZASTOJI

Vrte zastoja:

Nepotpuni zastoj

Potpuni zastoj

Nepotpuni zastoj

Transakcija 1 Transakcija 2 Transakcija 3

zaključaj A … …

… zaključaj A …

otključaj A zaključaj A

…

transakcija 2 može čekati zauvijek

iako je imala priliku zaključati podatak A

rješenje: “first come first served”,

tko je došao prvi, prvi se i posluži

Potpuni zastoj

svaki proces čeka od drugog da ovaj otpusti ključ

oba procesa ne mogu ništa raditi, ne može se napraviti

niti rollback

niti završiti transakciju

Transakcija 1 Transakcija 2 zaključaj A zaključaj B

zaključaj B zaključaj A

preporuka: transakcija zatraži odjednom sve ključeve – zaključa sve ili

ništa

zahtjeva se da transakcije zaključavaju podatke u nekom određenom poretku

ako se dogodi: javlja se greška 1205;

barem jedna transakcija se mora prekinuti; poništavaju se svi njeni efekti

SQL SERVER –Error 1205 : FIX Transaction (Process ID) was deadlocked on resources with another process and has been chosen as the deadlock victim. Return the transaction

Potpuni zastoj

Zaključavanje

Transakcija može zaključati podatke čime sprječava

druge transakcije da pristupe podatku dok ga dotična

transakcija ne otključa

Podaci koji su se mijenjali tijekom transakcije ostaju

zaključani do kraja transakcije

Locking manager

zaključava zapise i presuđuje u slučajevima kad postoji

više zahtjeva za zaključavanje istog podatka

Serijalizacija

SUBP treba u što većoj mjeri omogućiti paralelno

izvođenje

efekt transakcija koje se obavljaju paralelno mora biti

isti kao da su se obavljale jedna iza druge

(serijalizacija)

ako se zaključa previše objekata drugi procesi

bespotrebno čekaju na otključavanje → smanjuje se

konkurentnost, usporava se rad

ako se ne postave svi potrebni ključevi moguća je

pojava nekonzistentnih podataka

Protokol dvofaznog zaključavanja

serijalizacija je moguća ako sve transakcije poštuju protokol:

faza pribavljanja ključa

prije obavljanja operacije nad objektom transakcija mora za taj objekt zatražiti ključ

faza otpuštanja ključeva

nakon otpuštanja ključa transakcija ne smije više zatražiti nikakav ključ

najčešće je to samo jedna operacija (COMMIT ili ROLLBACK)

Rješavanje problema paralelnog

pristupa

Postoji automatsko zaključavanje, a samim time i

rješavanje problema, ali korisnik može sam definirati

kakvo će se zaključavanje postaviti u bazi:

postavljanjem određene granulacije

postavljanjem određene vrste zaključavanja

postavljanjem izolacijskog nivoa

postavljanjem vremenski ograničenih

zaključavanja

Granulacija zaključavanja

određuje se veličina objekta koji će biti zaključan

baza podataka – DATABASE kada se treba zaključati veliki broj n-torki u vrlo velikom broju

relacija

tablica – TABLE zaključava se cijela tablica, uključujući sve podatke i sve

indekse

redak – RID

row ID

ako se zaključava ograničen broj n-torki (redaka)

Granulacija zaključavanja

memorijska stranica – PAGE

ako se zaključava ograničen broj n-torki za koje se može

pretpostaviti da su smještene na fizički bliskim pozicijama

veličina: 8KB stranica s podacima ili indeksima

EXTENT

grupa od 8 memorijskih stranica

indeks – KEY

npr. za čuvanje “mjesta” za ključ čiji je zapis obrisan; u slučaju

poništavanja transakcije

koristi se implicitno od strane SUBP

Vrste zaključavanja

SHARED (S) LOCK

1. ključ za čitanje – SHARED (S) LOCK

• transakcija T zaključa objekt za čitanje

• bilo koja druga transakcija ga također može zaključati za čitanje

• niti jedna druga transakcija ga ne može zaključati za pisanje

• odmah nakon što je podatak koji je zaključan za čitanje pročitan, ključ za čitanje se otpušta

• trajnost ključa ovisi o primijenjenom nivou izolacije → na zaključavanje za čitanje utječe nivo izolacije

Vrste zaključavanja

EXCLUSIVE (X) LOCK

2. ključ za pisanje/izmjenu – EXCLUSIVE (X) LOCK • transakcija T zaključa objekt za pisanje • niti jedna druga transakcija ga ne može zaključati

dok ga T ne otključa • svaka operacija izmjene postavlja ključ za

pisanje!!! • postavlja se neovisno o postavljenom nivou

izolacije • uklanja se tek po završetku transakcije • da ne bi došlo do postavljanja prevelikog broja

ključeva za pisanje/izmjenu ne treba koristiti prefinu granulaciju zaključavanja

• treba koristiti što kraće transakcije da bi se spriječilo nepotrebno ograničavanje konkurentnosti

• naredbe: UPDATE, INSERT, DELETE

Vrste zaključavanja

UPDATE (U) LOCK

3. unapredivi ključ – UPDATE (U) LOCK • ažuriranje pročitane n-torke postavlja ovaj ključ

• izražava namjeru izmjene

• na početku se postavlja ključ za čitanje

bilo koja druga transakcija može postaviti ključ za čitanje

niti jedna druga transakcija ne može postaviti ključ za pisanje

• prije izmjene ključ se unaprjeđuje u ključ za pisanje

• omogućuje SUBP-u da predviđa buduće akcije

• ovisi o nivou izolacije; postavlja se čak i kad je nivo izolacije UNCOMMITTED

Razina izolacije

određuje način pristupa podacima u višekorisničkom okruženju

izolira pojedine transakcije jedne od drugih

niži nivo izolacije povećava konkurentnost smanjuje “ispravnost” podataka

povišenjem nivoa izolacije osigurava se “ispravnost” podataka smanjuje se mogućnost štetne interferencije paralelno

izvođenih programa smanjuje se konkurentnost

SET TRANSACTION ISOLATION LEVEL

{ READ COMMITTED

| READ UNCOMMITTED

| REPEATABLE READ

| SERIALIZABLE

} samo jedna od opcija može biti postavljena

Razina izolacije

Prljavo čitanje

READ UNCOMMITTED

1. prljavo čitanje – READ UNCOMMITTED • najniži nivo izolacije

• moguće pročitati “prljave” ili nepotvrđene n-torke

• osigurava samo da se ne mogu čitati fizički oštećeni podaci

• čitaju se svi traženi podaci bez zaključavanja i bez provjere da li su možda zaključani → pojava sablasnih n-torki

• operacije ažuriranja zaključavaju podatke prilikom izmjena

• koristi se u slučajevima:

kad se pristupa “statičkim” podacima

kad samo jedan program koristi bazu podataka

kad se ne zahtijeva apsolutna preciznost podataka

Čitanje potvrđenih n-torki

COMMITTED READ

2. čitanje potvrđenih n-torki – COMMITTED READ • SQL Server default nivo izolacije

• ne čita “prljave” n-torke

• mogu se javiti fantomske n-torke ili nekonzistentni podaci

• proces koji čita provjerava da li je trenutno traženi podatak zaključan za pisanje → n-torka se neće moći pročitati

• podaci se ne zaključavaju

• ne utječe na izmjene jer se svaki podatak zaključava prilikom izmjena

• podatak koji je pročitan već u sljedećem trenutku može biti izmijenjen ili obrisan

• koristi se samo ukoliko se n-torke koje se čitaju koriste kao nezavisne jedinice, tj. pročitana vrijednost se neće koristiti kao referentna u daljnjim operacijama

Mogućnost ponovnog čitanja –

REPEATABLE READ

3. mogućnost ponovnog čitanja – REPEATABLE READ

• mogu se javiti fantomske n-torke

• dohvat n-torke iz djelatnog skupa uzrokuje zaključavanje za čitanje ogovarajuće n-torke u bazi podataka

• dohvatom nove n-torke prethodna se oključava

• ako je kod izmjene podataka (UPDATE CURSOR) na trenutnu n-torku postavljen unapredivi ključ, zapisi/stranice na kojima je došlo do izmjena ostaju zaključane do kraja transakcije

• ako se pri dohvatu ne koristi transakcija ključ se otpušta odmah nakon što je n-torka pročitana

Mogućnost ponovnog čitanja –

REPEATABLE READ

koristi se

ako je potrebno osigurati da dohvaćena

vrijednost ne bude promijenjena za vrijeme

“obrade” dohvaćene n-torke

u slučajevima kada se dohvaćena n-torka

koristi kao referentna vrijednost u daljnjim

operacijama s podacima

Serijalizacija

SERIALIZABLE (ISOLATED)

4. SERIALIZABLE (ISOLATED)

• najviši nivo izolacije

• transakcije su potpuno izolirane jedna od druge

• dohvat n-torke iz djelatnog skupa uzrokuje zaključavanje za čitanje odgovarajuće n-torke u bazi podataka

• dohvatom nove n-torke prethodna ostaje zaključana

• kod ponovnog dohvata istog djelatnog skupa unutar iste transakcije

• prethodno zaključane n-torke i dalje su zaključane → zapisi/stranice ostaju zaključane do kraja transakcije

Serijalizacija

SERIALIZABLE (ISOLATED)

koristi se:

ukoliko je potrebno osigurati da niti jedna n-

torka ne bude promijenjena do završetka

transakcije

u slučaju da se više dohvaćenih n-torki koristi

kao referentna vrijednost u daljnjim

operacijama s podacima

Vrijeme zaključavanja

ako dođe do zastoja, SQL Server poništava jednu od blokiranih transakcija, i to onu kojoj vrijeme čekanja nije određeno

SET LOCK_TIMEOUT max_vrijeme_čekanja naredba kojom se definira koliko je maksimalno vrijeme koje jedna

transakcija čeka na zaključani objekt

kada transakcija čeka duže od ovog maksimalnog vremena automatski se poništava i javlja se pogreška 1222 "Lock request time-out period exceeded"

ako nije postavljeno, @@LOCK_TIMEOUT vraća -1 → čekaj zauvijek

@@LOCK_TIMEOUT funkcija koja vraća vrijeme čekanja na objekt koji je zaključan

vrijeme u milisekundama

na početku spajanja na bazu vraća -1

Vrijeme zaključavanja

Primjer 1: nije postavljeno maximalno vrijeme SELECT @@LOCK_TIMEOUT -1

Primjer 2: maksimalno vrijeme postavljeno na 1800 ms SET LOCK_TIMEOUT 1800 SELECT @@LOCK_TIMEOUT 1800

Transakcija 1

BEGIN

INSERT INTO osoba

VALUES(4, 'Pero', 'Perić')

…

ROLLBACK TRANSACTION

SELECT * FROM osoba

Transakcija 2

SET TRANSACTION ISOLATION

LEVEL READ UNCOMMITTED

SELECT * FROM osoba

…

SELECT * FROM osoba

Primjer

1 Ivo Ivić

2 Maro Marić

3 Ana Anić

4 Pero Perić

Primjer

T1

SET TRANSACTION ISOLATION

LEVEL SERIALIZABILE

BEGIN

SELECT * FROM osoba

WHERE mbr=1

…

T2

SET TRANSACTION ISOLATION

LEVEL SERIALIZABILE

BEGIN

SELECT * FROM osoba

WHERE mbr=1

UPDATE osoba

SET ime= 'Ive'

WHERE mbr=1

OK !

KljuČ !

Primjer

T1

SET TRANSACTION ISOLATION

LEVEL READ UNCOMMITTED

BEGIN

UPDATE osoba

SET ime= 'Ive'

WHERE mbr=1

T2

SET TRANSACTION ISOLATION

LEVEL READ COMMITTED

BEGIN

SELECT * FROM osoba

WHERE mbr=1

END

SET TRANSACTION ISOLATION

LEVEL READ UNCOMMITTED

BEGIN

SELECT * FROM osoba

WHERE mbr=1

OK !