1 / 37

Транзакции

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

airell
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Транзакции Гл.ас. Д-р Даниела Гоцева http://dgoceva.info БД-лекции

  2. Паралелизмът ползва транзакции • Целта на ‘concurrent’ DBMS е да позволи на много потребители едновременно да достъпят БД без да си влияят един на друг. • Един проблем с множество потребители ползващи СУБД се крие във възможността >=2 потребители да се опитат да променят данни в БД едновременно. Ако този вид действия не се контролира внимателно, БД ще стане несъгласувана. • За да се контролира достъпът до данните, се нуждаем от концепция, която ще ни позволи да капсулираме достъпът на БД. Тази капсулация се нарича транзакция (‘Transaction’). БД-лекции

  3. Транзакции • Transaction (ACID) • Порция логическа дейност с възможност за възстановяване (unit of logical work and recovery) • Атомарна /atomicity/ (for integrity) • Запазване на плътността /consistency preservation/ • Изолация /isolation/ • Продължителност /durability/ • Съществува в SQL • Някои приложения изискват вложени или дълги транзакции БД-лекции

  4. Транзакции (2) • След като се изпълнят действията в транзакция, са възможни два изхода: • Commit – всички промени, направени по време на транзакцията от нея се записват трайно в БД. • Abort – всички промени, направени по време на транзакцията от нея не се записват в БД. Като резултат се получава, че транзакцията изобщо не е стартирана. БД-лекции

  5. TransactionSchedules • Планът на транзакцията е таблично представяне на това, как се изпълнява транзакцията във времето. Това е полезно, когато се проверяват сценарии на проблеми. В диаграмите се използват множество номенклатури: • READ(a) – четене на атрибут или данна на име ‘а’. • WRITE(a) – запис на атрибут или данна на име ‘а’. • WRITE(a[x]) – запис на данна или атрибут на име ‘а’, където ‘х’ се записва в ‘а’. • tn (т.е. t1,t2,t10) – показва времето на възникване на събитие. Времевите единици не са важни, но tn винаги възниква преди tn+1. БД-лекции

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

  7. TransactionSchedules (3) • Нека по същото време когато работи trans A runs, се стартира и trans B. • Транзакция B увеличава всички сметки с 10%. Каква ще бъде стойността на X: 32 или 33? • X е 22! В зависимост от преплитането, X може да бъде 32, 33, 30. Нека класифицираме грешните сценарии. БД-лекции

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

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

  10. InconsistencyScenario БД-лекции

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

  12. Граф на старшинство(Precedence Graph) • За да разберем как план на дадена транзакция се сериализира, създаваме граф на старшинство. Това е граф, във възлите на който се намират имената на транзакциите, а дъгите са атрибутите, обект на колизии. • Планът се сериализируем, тогава и само тогава, когато няма цикли в графа. БД-лекции

  13. Построяване на графа на старшинство • За да построим един граф на старшинство: • Създаваме възел за всяка транзакция в плана • Там, където транзакция A пише в атрибут, който се чете от транзакция B, се чертае линия от В към А. • Там, където транзакция A пише в атрибут, в който пише и транзакция B, се чертае линия от В към А. • Там, където транзакция A чете от атрибут, в който пише транзакция B, се чертае линия от В към А. БД-лекции

  14. Пример 1 • Даден е план: БД-лекции

  15. Пример 2 • Даден е план: БД-лекции

  16. Паралелизми (конкурентност) Гл.ас. Д-р Даниела Гоцева http://dgoceva.info БД-лекции

  17. Заключване(Locking) Как да сериализираме плана? • Заключване на четенето /read (shareable) lock/ • Заключване на записа /write (exclusive) lock/ • Груба структура • По-лесна обработка • По-малко паралелизми • Фина структура • Повече обработка • По-висока степен на паралелизъм БД-лекции

  18. Заключване (2) • Много системи използват заключването за контрол на конкурентността. Когато транзакция се нуждае от сигурност, че даден обект не се променя по неправомерен начин, тя заключва обекта. • Транзакция срещаща read lock може да чете обекта, но не и да го променя. • >1 транзакции могат да ползват read lock за един и същи обект (shared lock). • Обикновено само една транзакция може да ползва write lock върху обект (exclusive write lock). • Върху плана на транзакциите, отбелязваме с ‘S’ shared lock и с ‘X’ - exclusive write lock. БД-лекции

  19. Locking – UncommittedDependency • Заключването решава зависимостта при неприключена транзакция БД-лекции

  20. Deadlock(мъртва хватка) • Мъртва хватка се получава при заключване, когато всички зависещи дна от друга транзакции са в състояние WAIT завинаги. БД-лекции

  21. Deadlock (2) • Сценарий `lost update’ води до deadlock. Същото се получава и при`inconsistency’ scenario. БД-лекции

  22. Обработка на мъртва хватка • Заобикаляне на Deadlock • В ОС се ползва стратегия “предявяване на изисквания” • Не е ефективно в средите за БД. • Откриване на Deadlock • Когато lock изисква изчакване или при проверки през определен период. • Ако транзакцията е блокирана от друга, се проверява дали втората транзакция не е блокирана от първата директно или индиректно през друга транзакция. БД-лекции

  23. Deadlock Resolution • Ако за множество транзакции се счита, че е в мъртва хватка: • Избира се жертва (т.е. транзакцията с най-малко време на живот) • Изпълнява се rollback на транзакцията-жертва и се рестартира. • Операцията rollback прекратява транзакцията, като премахва всички промени и освобождава всички нейни заключвания. • Съобщение се предава към жертвата и в зависимост от системата транзакцията може да се стартира автоматично или не. БД-лекции

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

  25. Двуфазно заключване (2) The two-phase locking protocol: • Преди каквито и да било действия с даден елемент, транзакцията трябва да изисква поне shared lock над него. По този начин нито един елемент не може да се достъпи без коректно заключване. • След отключване транзакцията може никога да не поиска нови заключвания. Наименованието на двете фази на заключващия протокол са ‘lock-acquisition phase’ и ‘lock-release phase’. БД-лекции

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

  27. Timestamping rules • Следните правила се проверяват, когато транзакция T се опитва да промени данни. Ако правилото показва ABORT, то транзакцията T се rollback и прекратява (и може би рестартира). • Ако T се опитва да чете данни, които са записани от по-ранна транзакция, то ABORT T. • Ако T се опитва да пише данни, които са били четени или записвани от по-ранна транзакция, то ABORT T. • Ако транзакцията T се прекратява, то всички останали транзакции, които четат данните, записани от Т, също се прекратяват. В добавка, другите прекратени транзакции могат да предизвикат по-нататъшно прекратяване на други транзакции. Този процес се нарича ‘cascading rollback’. БД-лекции

  28. Сигурност Гл.ас. Д-р Даниела Гоцева http://dgoceva.info БД-лекции

  29. Сигурност Сигурността на БД предизвиква защита срещу: • Неоторизиран достъп • Промяна на структурите • Унищожаване Защитата е директна срещу два класа потребители • Спира потребителите без достъп до БД. • Спира потребителите с достъп до БД, които изпълняват действия извън техните правомощия. БД-лекции

  30. Сигурност (2) Съществуват множество аспекти на защитата • Правни, социални и етични аспекти • Физически контрол • Линия на поведение • Операционни проблеми • Hardware controls • Защита на ниво ОС • Защита на ниво БД БД-лекции

  31. Нива на сигурност в СУБД • Данните в БД, подлежащи на защита, могат да бъдат групирани в следните нива: • Цялата БД • Множество релации • Отделна релация • Множество tuples в релаци я • Отделен tuple • Множество атрибути на всички tuples • Атрибут на конкретен tuple. БД-лекции

  32. Нива на защита в СУБД Криптиране на данните: • Често е трудно да се спрат потребителите да копират БД от едно място на друго. По-лесно е да се направи копирането безсмислено чрез криптиране на данните. Това означава, че данните са нечетими, докато не се знае секретния код. Криптираните данни в комбинация със секретния ключ са необходими за да се ползва СУБД. Следи от проверката: • Ако някой проникне в СУБД е полезно да се намери до какъв достъп или актуализации на структурите е стигнал. Следите от проверката (Audit Trails) могат да се установят избирателно, за да се намали дисковото пространство, което се ползва, да идентифицира слабите места в системата и да хване неправомерните потребители. БД-лекции

  33. Потребителско ниво на сигурност в SQL • Всеки потребител има набор от права върху списък от обекти. • Различните потребители може да имат различни права на достъп върху един и същи обект. • За да се контролират нивата на правата на достъп, потребителите могат • Права на достъп върху таблица • Права на достъп върху view. Посредством изгледи, правата на достъп могат да контролират хоризонтално и вертикално подмножества в таблица и върху динамично генерирани данни от други таблици. БД-лекции

  34. Йерархия на имената В СУБД има два слоя на именоване на релациите. • СУБД е съвкупност от ‘databases’. Администраторът на БД има права да създава и изтрива БД, и да раздава права на потребителите за БД. • Всяка БД има плоско пространство на имената. Потребителите със съответните права могат да създават таблици и изгледи в БД. Тъй като пространството на имената е плоско, всички имена на таблици трябва да са уникални в БД. СУБД подпомага потребителите да наблюдават: • Имената на таблици и изгледи се съпровождат от името на потребителя, който ги е създал. • database login name се използва често като username. БД-лекции

  35. Йерархия на имената (2) • Като пример, нека е дадена таблица ‘hello’, създадена от потребител jbloggs. • Името на таблицата е jbloggs.hello • Потребителят jbloggs може да достъпи таблица посредством име ‘hello’ • Другите потребители трябва да ползват пълното име на таблицата, за да я достъпят • Потребителят jbloggs може да контролира кой има достъп до таблицата посредством командата GRANT. • Ако DBA създаде таблица и я направи с достъп PUBLIC, то всички потребители ще достъпят таблицата с просто име. БД-лекции

  36. Команда GRANT • GRANT се ползва да задава привилегии на потребителите: GRANT привилегии ON име_таблица TO { кого ... } [ WITH GRANT OPTION ] • Възможни привилегии: • SELECT – потребителят може да извлича данни • UPDATE – потребителят може да модифицира съществуващи данни • DELETE – потребителят може да изтрива данни • INSERT – потребителят може да добавя нови данни • REFERENCES – потребителят може да прави референции към таблици БД-лекции

  37. Команда GRANT (2) • Опцията WITH GRANT OPTION разрешава на определения потребител да раздава права на потребителите върху таблицата. • Това е добър начин да се разреши на другите потребители да се грижат за разрешение за редица таблици, т.е. да позволяват на мениджъра да управлява достъпа до таблиците. • ‘кого’ не трябва да бъде username или множество от usernames. Трябва да се зададе PUBLIC, което означава, че привилегиите са дадени на всички. GRANT SELECT ON сп_потребители TO PUBLIC; БД-лекции

More Related