Транзакции
This presentation is the property of its rightful owner.
Sponsored Links
1 / 37

Транзакции PowerPoint PPT Presentation


  • 150 Views
  • Uploaded on
  • Presentation posted in: General

Транзакции. Гл.ас. Д-р Даниела Гоцева http://dgoceva.info. Паралелизмът ползва транзакции. Целта на ‘concurrent’ DBMS е да позволи на много потребители едновременно да достъпят БД без да си влияят един на друг.

Download Presentation

Транзакции

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


4105972

Транзакции

Гл.ас. Д-р Даниела Гоцева

http://dgoceva.info

БД-лекции


4105972

Паралелизмът ползва транзакции

  • Целта на ‘concurrent’ DBMS е да позволи на много потребители едновременно да достъпят БД без да си влияят един на друг.

  • Един проблем с множество потребители ползващи СУБД се крие във възможността >=2 потребители да се опитат да променят данни в БД едновременно. Ако този вид действия не се контролира внимателно, БД ще стане несъгласувана.

  • За да се контролира достъпът до данните, се нуждаем от концепция, която ще ни позволи да капсулираме достъпът на БД. Тази капсулация се нарича транзакция (‘Transaction’).

БД-лекции


4105972

Транзакции

  • Transaction (ACID)

    • Порция логическа дейност с възможност за възстановяване (unit of logical work and recovery)

    • Атомарна /atomicity/ (for integrity)

    • Запазване на плътността /consistency preservation/

    • Изолация /isolation/

    • Продължителност /durability/

  • Съществува в SQL

  • Някои приложения изискват вложени или дълги транзакции

БД-лекции


4105972

Транзакции (2)

  • След като се изпълнят действията в транзакция, са възможни два изхода:

    • Commit – всички промени, направени по време на транзакцията от нея се записват трайно в БД.

    • Abort – всички промени, направени по време на транзакцията от нея не се записват в БД. Като резултат се получава, че транзакцията изобщо не е стартирана.

БД-лекции


Transaction schedules

TransactionSchedules

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

    • READ(a) – четене на атрибут или данна на име ‘а’.

    • WRITE(a) – запис на атрибут или данна на име ‘а’.

    • WRITE(a[x]) – запис на данна или атрибут на име ‘а’, където ‘х’ се записва в ‘а’.

    • tn (т.е. t1,t2,t10) – показва времето на възникване на събитие. Времевите единици не са важни, но tn винаги възниква преди tn+1.

БД-лекции


Transaction schedules 2

TransactionSchedules (2)

  • Дадена е транзакция A, която зарежда в банкова сметка стойност X (първоначално 20) и добавя 10 лева към нея. Планът на тази транзакция има вида:

БД-лекции


Transaction schedules 3

TransactionSchedules (3)

  • Нека по същото време когато работи trans A runs, се стартира и trans B.

  • Транзакция B увеличава всички сметки с 10%. Каква ще бъде стойността на X: 32 или 33?

  • X е 22! В зависимост от преплитането, X може да бъде 32, 33, 30. Нека класифицираме грешните сценарии.

БД-лекции


Lost update scenario

Lost Update scenario

  • Актуализацията на транзакция A се загубва в t4, защото транзакция B я припокрива. B пропуска актуализацията на A в t4, защото взема стойността на R в t2.

БД-лекции


Uncommitted dependency

UncommittedDependency

  • Transaction A може да чете или записва R, който се актуализира от друга транзакция, която се прекратява.

БД-лекции


Inconsistency scenario

InconsistencyScenario

БД-лекции


4105972

Сериализация

  • Планът показва реално изпълнение на >=2 конкурентни транзакции.

  • Планът на 2 транзакции T1 и T2 е сериализируем (‘serializable’), тогава и само тогава. Когато изпълнението му има същия ефект, както при T1;T2 или T2;T1.

БД-лекции


Precedence graph

Граф на старшинство(Precedence Graph)

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

  • Планът се сериализируем, тогава и само тогава, когато няма цикли в графа.

БД-лекции


4105972

Построяване на графа на старшинство

  • За да построим един граф на старшинство:

  • Създаваме възел за всяка транзакция в плана

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

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

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

БД-лекции


4105972

Пример 1

  • Даден е план:

БД-лекции


4105972

Пример 2

  • Даден е план:

БД-лекции


4105972

Паралелизми (конкурентност)

Гл.ас. Д-р Даниела Гоцева

http://dgoceva.info

БД-лекции


Locking

Заключване(Locking)

Как да сериализираме плана?

  • Заключване на четенето /read (shareable) lock/

  • Заключване на записа /write (exclusive) lock/

  • Груба структура

    • По-лесна обработка

    • По-малко паралелизми

  • Фина структура

    • Повече обработка

    • По-висока степен на паралелизъм

БД-лекции


4105972

Заключване (2)

  • Много системи използват заключването за контрол на конкурентността. Когато транзакция се нуждае от сигурност, че даден обект не се променя по неправомерен начин, тя заключва обекта.

  • Транзакция срещаща read lock може да чете обекта, но не и да го променя.

  • >1 транзакции могат да ползват read lock за един и същи обект (shared lock).

  • Обикновено само една транзакция може да ползва write lock върху обект (exclusive write lock).

  • Върху плана на транзакциите, отбелязваме с ‘S’ shared lock и с ‘X’ - exclusive write lock.

БД-лекции


Locking uncommitted dependency

Locking – UncommittedDependency

  • Заключването решава зависимостта при неприключена транзакция

БД-лекции


Deadlock

Deadlock(мъртва хватка)

  • Мъртва хватка се получава при заключване, когато всички зависещи дна от друга транзакции са в състояние WAIT завинаги.

БД-лекции


Deadlock 2

Deadlock (2)

  • Сценарий `lost update’ води до deadlock. Същото се получава и при`inconsistency’ scenario.

БД-лекции


4105972

Обработка на мъртва хватка

  • Заобикаляне на Deadlock

    • В ОС се ползва стратегия “предявяване на изисквания”

    • Не е ефективно в средите за БД.

  • Откриване на Deadlock

    • Когато lock изисква изчакване или при проверки през определен период.

    • Ако транзакцията е блокирана от друга, се проверява дали втората транзакция не е блокирана от първата директно или индиректно през друга транзакция.

БД-лекции


Deadlock resolution

Deadlock Resolution

  • Ако за множество транзакции се счита, че е в мъртва хватка:

  • Избира се жертва (т.е. транзакцията с най-малко време на живот)

  • Изпълнява се rollback на транзакцията-жертва и се рестартира.

    • Операцията rollback прекратява транзакцията, като премахва всички промени и освобождава всички нейни заключвания.

    • Съобщение се предава към жертвата и в зависимост от системата транзакцията може да се стартира автоматично или не.

БД-лекции


4105972

Двуфазно заключване

  • Заключването не гарантира сериализируемост. Ако една транзакция освобождава заключвания преди да приключи и може да заключва на по-късен етап повече или същото количество данни, предимствата на заключването се губят.

  • Ако всички транзакции спазват ‘two-phase locking protocol’, то всички възможни междинни действия са гарантирано сериализируеми.

БД-лекции


4105972

Двуфазно заключване (2)

The two-phase locking protocol:

  • Преди каквито и да било действия с даден елемент, транзакцията трябва да изисква поне shared lock над него. По този начин нито един елемент не може да се достъпи без коректно заключване.

  • След отключване транзакцията може никога да не поиска нови заключвания.

    Наименованието на двете фази на заключващия протокол са ‘lock-acquisition phase’ и ‘lock-release phase’.

БД-лекции


4105972

Други методи за запазване на плътността на БД

  • Двуфазното заключване не е единствения начин за запазване на плътността на БД. Друг метод, използван в някои СУБД е маркиране на време (timestamping). С него няма заключване за предпазване на транзакциите да виждат незаписаните промени и всички физически актуализации се отлагат в момента на запис(commit time).

  • Заключването синхронизира изпълнението на множество транзакции като последователно във времето.

  • Маркирането на време синхронизира изпълнението, така че да е еквивалентно на даден последователен ред – реда на маркерите.

БД-лекции


Timestamping rules

Timestamping rules

  • Следните правила се проверяват, когато транзакция T се опитва да промени данни. Ако правилото показва ABORT, то транзакцията T се rollback и прекратява (и може би рестартира).

    • Ако T се опитва да чете данни, които са записани от по-ранна транзакция, то ABORT T.

    • Ако T се опитва да пише данни, които са били четени или записвани от по-ранна транзакция, то ABORT T.

  • Ако транзакцията T се прекратява, то всички останали транзакции, които четат данните, записани от Т, също се прекратяват. В добавка, другите прекратени транзакции могат да предизвикат по-нататъшно прекратяване на други транзакции. Този процес се нарича ‘cascading rollback’.

БД-лекции


4105972

Сигурност

Гл.ас. Д-р Даниела Гоцева

http://dgoceva.info

БД-лекции


4105972

Сигурност

Сигурността на БД предизвиква защита срещу:

  • Неоторизиран достъп

  • Промяна на структурите

  • Унищожаване

    Защитата е директна срещу два класа потребители

  • Спира потребителите без достъп до БД.

  • Спира потребителите с достъп до БД, които изпълняват действия извън техните правомощия.

БД-лекции


4105972

Сигурност (2)

Съществуват множество аспекти на защитата

  • Правни, социални и етични аспекти

  • Физически контрол

  • Линия на поведение

  • Операционни проблеми

  • Hardware controls

  • Защита на ниво ОС

  • Защита на ниво БД

БД-лекции


4105972

Нива на сигурност в СУБД

  • Данните в БД, подлежащи на защита, могат да бъдат групирани в следните нива:

    • Цялата БД

    • Множество релации

    • Отделна релация

    • Множество tuples в релация

    • Отделен tuple

    • Множество атрибути на всички tuples

    • Атрибут на конкретен tuple.

БД-лекции


4105972

Нива на защита в СУБД

Криптиране на данните:

  • Често е трудно да се спрат потребителите да копират БД от едно място на друго. По-лесно е да се направи копирането безсмислено чрез криптиране на данните. Това означава, че данните са нечетими, докато не се знае секретния код. Криптираните данни в комбинация със секретния ключ са необходими за да се ползва СУБД.

    Следи от проверката:

  • Ако някой проникне в СУБД е полезно да се намери до какъв достъп или актуализации на структурите е стигнал. Следите от проверката (Audit Trails) могат да се установят избирателно, за да се намали дисковото пространство, което се ползва, да идентифицира слабите места в системата и да хване неправомерните потребители.

БД-лекции


4105972

Потребителско ниво на сигурност в SQL

  • Всеки потребител има набор от права върху списък от обекти.

  • Различните потребители може да имат различни права на достъп върху един и същи обект.

  • За да се контролират нивата на правата на достъп, потребителите могат

    • Права на достъп върху таблица

    • Права на достъп върху view. Посредством изгледи, правата на достъп могат да контролират хоризонтално и вертикално подмножества в таблица и върху динамично генерирани данни от други таблици.

БД-лекции


4105972

Йерархия на имената

В СУБД има два слоя на именоване на релациите.

  • СУБД е съвкупност от ‘databases’. Администраторът на БД има права да създава и изтрива БД, и да раздава права на потребителите за БД.

  • Всяка БД има плоско пространство на имената. Потребителите със съответните права могат да създават таблици и изгледи в БД. Тъй като пространството на имената е плоско, всички имена на таблици трябва да са уникални в БД. СУБД подпомага потребителите да наблюдават:

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

    • database login name се използва често като username.

БД-лекции


4105972

Йерархия на имената (2)

  • Като пример, нека е дадена таблица ‘hello’, създадена от потребител jbloggs.

    • Името на таблицата е jbloggs.hello

    • Потребителят jbloggs може да достъпи таблица посредством име ‘hello’

    • Другите потребители трябва да ползват пълното име на таблицата, за да я достъпят

  • Потребителят jbloggs може да контролира кой има достъп до таблицата посредством командата GRANT.

  • Ако DBA създаде таблица и я направи с достъп PUBLIC, то всички потребители ще достъпят таблицата с просто име.

БД-лекции


Grant

Команда GRANT

  • GRANT се ползва да задава привилегии на потребителите:

    GRANT привилегии ON име_таблица

    TO { кого ... }

    [ WITH GRANT OPTION ]

  • Възможни привилегии:

    • SELECT – потребителят може да извлича данни

    • UPDATE – потребителят може да модифицира съществуващи данни

    • DELETE – потребителят може да изтрива данни

    • INSERT – потребителят може да добавя нови данни

    • REFERENCES – потребителят може да прави референции към таблици

БД-лекции


Grant 2

Команда GRANT (2)

  • Опцията WITH GRANT OPTION разрешава на определения потребител да раздава права на потребителите върху таблицата.

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

  • ‘кого’ не трябва да бъде username или множество от usernames. Трябва да се зададе PUBLIC, което означава, че привилегиите са дадени на всички.

    GRANT SELECT ON сп_потребители TO PUBLIC;

БД-лекции


  • Login