IV.Защита на данните 1.Възстановяване

IV.Защита на данните

1.Възстановяване

Основен принцип, върху който се гради възстановяването е излишеството на информация.

1.1.Транзакции

Пример: да допуснем, че факултетът по право се разделя на два отделни факултета и 20 служителя се местят във новия факултет. Ще трябва да добавим нов запис в таблицата FACULTY за новия факултет и да актуализираме броя служители на стария.

INSERT INTO FACULTY(NAME, YEAR_ESTABLISHED, EMPLOYEE_NUMBER)

VALUES(‘Нов факултет по право’, 2004, 20);
UPDATE FACULTY

SET EMPLOYEE_NUMBER = EMPLOYEE_NUMBER - 20

WHERE NAME = ‘Факултет по право’
IF @@ERROR <> 0

ROLLBACK TRANSACTION;

ELSE

COMMIT TRANSACTION;

• 
  това, което изглежда като атомарна операция Раздели факултета на два... в действителност включва две операции (INSERT, UPDATE);
  
• 
  БД не е консистентна между двете операции. 20 служители са преминали в новия факултет, а не са отписани от стария;
  
• 
  една логическа операция (транзакция) не е необходима, ако се извършва единична операция. Т.е. когато директно се преминава от едно консистентно състояние в друго консистентно състояние;
  
• 
  при обработка на транзакции - при промени, при които възникват грешки, те се анулират преди транзакцията да достигне естествения си край;
  
• 
  следователно, една транзакция се изпълнява изцяло или се анулира напълно.
  

1.2.Оператори

• 
  BEGIN TRANSACTION – поставя начало на транзакция;
  
• 
  COMMIT TRANSACTION - сигнализира за успешен край на транзакцията, при което TM прави всички промени постоянни. Това е допустимо, понеже се знае, че БД се намира в ново консистентно състояние;
  
• 
  ROLLBACK TRANSACTION - сигнализира за неуспешен край на транзакцията. TM знае, че БД се намира в неконсистентно състояние. Всички промени, направени междувременно, се анулират. Така БД се връща в изходното консистентно състояние.
  

1.3.Реализация на транзакциите

• 
  СУБД води журнал (log) за всички детайли на извършващите се промени върху лента или дисково устройство. Също така и за стойностите преди и след промените;
  
• 
  при анулиране системата търси съответната входна точка в журнала и възстановява предишното състояние;
  
• 
  СУБД трябва също така да гарантира, че отделните оператори са атомарни. Например, при грешка по време на INSERT - системата не променя БД.
  

1.4.Типична структура на програма, използваща транзакции

1-ва транзакция


...

инициализиране BEGIN COMMIT

на програмата TRANSACTION
2-ра транзакция (canceled)

... ...

BEGIN ROLLBACK

TRANSACTION

3-та транзакция

...

BEGIN COMMIT завършване

TRANSACTION на програмата

1.5.Свойства на транзакциите

• 
  атомарност (атомичност) - транзакциите се разглеждат като неразложими;
  
• 
  консистентност (съгласуваност) - трансформират БД от едно консистентно състояние в ново консистентно състояние;
  
• 
  изолираност - отделните транзакции са изолирани една от друга;
  
• 
  трайност - щом като една транзакция веднъж успее, направените от нея промени се запазват, дори ако има последващ срив в системата.
  

2.Конкурентност

Възстановяването и конкурентността са тясно свързани и са част от общата тема за обработка на транзакциите.

Конкурентност: СУБД обикновено разрешава едновременен достъп на повече транзакции към едни и същи данни.

В СУБД съществува concurrency control mechanism за осигуряване, че конкурентните транзакции няма да си пречат взаимно.

2.1.Проблеми на конкурентността

Всеки механизъм за контрол на конкурентността трябва да отчита следните възможни проблеми:

• 
  загуба на промяна (lost update);
  
• 
  незавършена зависимост (uncommitted dependency);
  
• 
  неконсистентен анализ (inconsistent analysis);
  
• 
  четене на редове-фантоми.
  

2.1.1.Загуба на промяна

Загуба на промяна възниква когато две или повече транзакции избират един и същ ред и после го актуализират, като се ръководят от първоначално прочетената стойност. Никоя транзакция няма представа за съществуването на другите транзакции. Последната направена актуализация припокрива промените, направени от другите транзакции и по този начин се получава загуба на промяна.
Транзакция А Време Транзакция

RETRIEVE p t₁

t₂ RETRIEVE p

UPDATE p t₃

t₄ UPDATE p

Нека p e един запис. Транзакция А губи една промяна в t₄ както следва:

• 
  в t₁ A го намира;
  
• 
  в t₂ същия запис намира B;
  
• 
  в t₃ A променя p (на базата на стойностите в t₁);
  
• 
  в t₄ B променя p (на базата на стойностите в t₂, които са същите както в t₁);
  
• 
  в t₄ промените на A са загубени, защото записът е възстановен от B.
  

2.1.2.Незавършена зависимост – четене на непотвърдени данни

Незавършена зависимост възниква в случай, когато втора транзакция избира конкретен ред, който в момента се актуализира от друга транзакция. Втората транзакция чете променени данни, които все още не са потвърдени и промените могат да бъдат отхвърлени от транзакцията, която ги извършва. Така втората транзакция, която чете реда, става зависима от променените, но непотвърдени данни, които е прочела.
Транзакция А Време Транзакция


t₁ UPDATE p



RETRIEVE p t₂

t₃ ROLLBACK

Транзакция А става зависима от незавършената промяна в t₂.

Транзакция А Време Транзакция


t₁ UPDATE p

UPDATE p t2

t₃ ROLLBACK

Транзакция А променя незавършената промяна в t₂ и губи промяната в t₃.

2.1.3.Неконсистентен анализ - четене без повторяемост

Неконсистентен анализ възниква, когато втората транзакция осъществява достъп до един и същ ред няколко пъти и всеки път чете различни данни. Ситуацията е подобна на непотвърдената зависимост по това, че друга транзакция променя в същия момент данните, които се четат от първата. Но в този случай четените данни са били потвърдени от променилата ги транзакция.
ACC 1 ACC 2 ACC 3

40

50

30


Транзакция А Време Транзакция


RETRIEVE acc1: t₁

SUM = 40

RETRIEVE acc2: t₂

SUM = 90

t₃ RETRIEVE acc3

t₄ UPDATE acc3:

30 -> 20

t₅ RETRIEVE acc1

t₆ UPDATE acc1:

40 -> 50
t₇ COMMIT

RETRIEVE acc3: t₈

SUM = 110

• 
  транзакция А образува баланса на сметките;
  
• 
  транзакция В прехвърля 10 от сметка 3 към сметка 1;
  
• 
  резултатът, получен от А е 110 (явно некоректен) - увеличението на сметка 1 с 10 се губи.
  

2.1.4.Четене на редове-фантоми

Четене на фантоми възниква, когато едно вмъкване или изтриване се изпълнява спрямо ред, който принадлежи на блок от редове, четен от една транзакция. Първото четене на блока от редове може да покаже ред, който вече не съществува при второто или следващи прочитания вследствие на изтриването му от друга транзакция. По същия начин при вмъкване на ред от друга транзакция второто или следващите четения на транзакцията ще покаже ред, който не е съществувал при първоначалното четене.

2.2.Блокиране (locking)

Проблемите могат да бъдат решени чрез една техника на механизма за контрол на конкурентността, наречена блокиране.

Основна идея: когато една транзакция изисква увереност, че един обект няма да бъде променен по някакъв непредвидим начин, тя блокира този обект.

Механизъм на блокировка:

1. Предполагаме, че системата поддържа два вида блокировка:

• 
  извънредна (exclusive locks - X locks);
  
• 
  разделяема (shared locks - S locks).
  

X - write locks;

S - read locks.

2. Ако транзакция А постави X - lock върху един запис p, тогава всяка заявка за някакъв вид блокировка от друга транзакция B върху p се анулира;

3. Ако транзакция А постави S - lock върху един запис p, тогава:

• 
  искане от B за X-lock върху p се анулира;
  
• 
  искане от B за S-lock върху p се допуска.
  

Тези правила могат да се обобщят посредством матрица за съвместимост за p:

	X	S	-
X	N	N	Y
S	N	Y	Y
-	Y	Y	Y

Data access protocol:

• 
  една транзакция А, която иска да търси p трябва първо да постави S-lock;
  
• 
  една транзакция А, която иска да променя p трябва първо да постави X lock;
  
• 
  ако транзакция В иска блокировка, която не се позволява заради конфликт, тогава тя преминава в състояние на изчакване;
  
• 
  блокировките са в сила до края на транзакцията (COMMIT или ROLLBACK).
  

2.3.Решение на проблемите

2.3.1.Загуба на промяна

Транзакция А Време Транзакция


RETRIEVE p (S-lock) t₁



t₂ RETRIEVE p (S-lock)

UPDATE p (X-lock) t₃

wait

wait

wait t₄ UPDATE p (X-lock)

wait

• 
  няма загуба, но в t₄ възниква deadlock ситуация;
  
• 
  в t₃ не може X-lock, понеже съществува S-lock от другата транзакция – възниква нов проблем.
  

2.3.2.Незавършена зависимост

Транзакция А Време Транзакция


t₁ UPDATE p (X-lock)



RETRIEVE p (S-lock) t₂

wait

wait

wait t₃ ROLLBACK (освобождава X)

RETRIEVE p (осъществява се)


При неконсистентния анализ също се стига до deadlock ситуация.

2.4.Deadlock

Блокировките решават трите проблема, но същевременно те създават нови.

Deadlock: ситуация, в която две или повече транзакции са едновременно в състояние на изчакване, като при това всяка от тях може да продължи едва когато другата първа предприеме определено действие.

Ако се появи такава ситуация, желателно е самата система да я открие и да я прекъсне.

Откриване на deadlock-ситуация означава откриване на цикъл в т.н. wait-for graph, който показва кой за какво чака.

Решение на deadlock-ситуация:

• 
  една от транзакциите се извежда от ситуацията с ROLLBACK, като същевременно се анулира нейната блокировка;
  
• 
  ако това не реши проблема, тогава се извежда втора транзакция и т.н. до решаване на проблема.
  

Практически не всички системи поддържат такива механизми. Те са свързани със загуба на много време.

2.5.Нива на изолация

Когато заключването се използва като механизъм за контрол на конкурентността, то разрешава възникналите при едновременната работа проблеми. Тази възможност осигурява всяка транзакция да се изпълнява при пълна изолация от останалите, работещи в същия момент.

Възможността за сериализация (serializability) се постига чрез изпълнение на група едновременни транзакции така, че да се постигне същото състояние на базата данни, каквото би се получило, ако групата транзакции се изпълнява последователно.

2.6.Нива на изолация при SQL-92

Въпреки, че сериализирането е важно за транзакциите, за да се гарантира, че данните в базата данни винаги са коректни, повечето транзакции не изискват винаги пълна изолация.

Нивото, на което една транзакция е готова да приема непотвърдени данни, се нарича ниво на изолация (isolation level).

Нивото на изолация представлява степента, до която една транзакция трябва да бъде изолирана от другите транзакции. По-ниското ниво увеличава възможностите за едновременна работа, но за сметка на коректността на данните. И обратно, по-високо ниво на изолация гарантира за коректност на данните, но може да се отрази отрицателно на едновременната работа.

Стандартът SQL-92 дефинира следните нива на изолация:

• 
  Непотвърдено четене (read uncommitted) – най-ниското ниво, на което транзакциите са изолирани само дотолкова, че да не могат да четат физически повредени данни;
  
• 
  Потвърдено четене (read committed);
  
• 
  Повторяемо четене;
  
• 
  Сериализируемо (serializable) – най-високото ниво, на което транзакциите са напълно изолирани една от друга.
  

Ако транзакциите се изпълняват на сериализируемо ниво на изолация всички едновременни припокриващи се транзакции са гарантирано сериализируеми.

Следната таблица илюстрира поведението при различните нива на изолация.

Ниво на изолация	Незавършена зависимост	Неконсистентен анализ	Четене на фантоми
Непотвърдено четене	Да	Да	Да
Потвърдено четене	Не	Да	Да
Повторяемо четене	Не	Не	Да
Сериализируемо	Не	Не	Не

Каталог: sites -> default -> files
files -> Образец №3 справка-декларация
files -> Р е п у б л и к а б ъ л г а р и я
files -> Отчет за разкопките на праисторическото селище в района на вуз до Стара Загора. Аор през 1981 г. ХХVІІ нац конф по археология в Михайловград, 1982
files -> Медии и преход възникване и развитие на централните всекидневници в българия след 1989 година
files -> Окръжен съд – смолян помагало на съдебния заседател
files -> Семинар на тема „Техники за управление на делата" 18 19 юни 2010 г. Хисар, Хотел „Аугуста спа" Приложение
files -> Чинция Бруно Елица Ненчева Директор Изпълнителен директор иче софия бкдмп приложения: програма
files -> 1. По пътя към паметник „1300 години България

Изтегляне 1.28 Mb.

Сподели с приятели: