Метод дзеркальних сховищ

Для забезпечення цілісності даних в сучасних СУБД є механізм реалізації програмного RAID-масива 1-го рівня, тобто дзеркального копіювання даних.

При створенні фізичних сховищ бази даних (сховища даних і сховища транзакцій) можна створити дзеркальні сховища, які логічно розміщувати на окремому диску.

У випадку ушкодження одного з сховищ достатньо замінити пошкоджений файл на файл дзеркального сховища. Після цього база знов виконуватиме свою роботу, продовжуючи вести основне і дзеркальне сховище.

Однак в деяких аварійних ситуаціях, коли пошкоджується основне сховище, при формуванні дзеркального не встигають зафіксуватися деякі дані. Для сховища даних це означає втрату частини записів в таблицях або якесь інше пошкодження самої таблиці. При пошкодженні сховища транзакцій втрачається частина змін в таблицях, але найбільш неприємним буде те, що СУБД не зможе проініціалізувати базу через порушення цілісності лога транзакцій. Рішенням подібної проблеми є примусова ініціалізація бази з наступним очищенням лога.

Рівні ізоляції

При написанні додатків баз даних для багатьох користувачів можна обрати один з двох способів контролю за транзакціями: оптимістичне або песимістичне блокування. Оптимістичне блокування означає, що ви в коді додатку явно не збираєтеся блокувати записи, доки над ними працюєте. Замість цього ви дозволяєте СУБД самій вирішувати це питання, а самі зосереджуєтися на логіці додатку. При реалізації в додатку режима оптимістичного блокування треба бути дуже обережними, щоб не викликати уповільнення або навіть повного зупинення роботи сервера через виконання зайвих блокувань. Песимістичне блокування означає, що механізм блокування буде явно визначений в коді додатку.

Розрізняють також блокування сторінки, таблиці і екстенту.

Блокування сторінки відбувається у випадку, коли користувач звертається до кількох рядків одніієї сторінки даних. В результаті блокується набагато більший об’єм даних, ніж при звертанні до одного рядка.

Блокування таблиці відбувається у випадку, коли користувач робить запит на оновлення таблиці, не включивши в нього директиву WHERE. Крім того такий тип блокування відбувається, коли кількість заблокованих сторінок даних перебільшує деякий попередньо встановлений поріг.

Блокування екстента відбувається, коли для відповіді на запит користувача СУБД потрібно створити новий екстент бази даних, який складається з певної кількості сторінок даних.

До рядків, сторінок, таблиць бази даних можна застосовувати такі типи блокування, як розділяєме блокування, монопольне та оновлюєме. Перше блокування дозволяє іншому процесу виконувати блокування одного й того ж рядка або сторінки, а друге – ні. Монопольне блокування – це щось середнє між розділяємим блокуванням і монопольним. На рівні бази даних є блокування, які використовуються для модифікації бази даних.

Заблокувати чи розблокувати дані під час виконання запиту в базу даних. Один з методів полягає в встановленні рівня ізоляції транзакції.

У випадку одночасної роботи кількох користувачів з однією таблицею час доступу до таблиці визначається довжиною транзакції, рівнем ізоляції і тим, хто раніше звернеться. Довжина транзакції – кількість передаваємих-повертаємих даних. Наприклад, SELECT sat FROM table (в таблиці біля 1 мільйона записів) буде надто довгою транзакцією, яка заблокує на достатньо тривалий проміжок часу доступ до даної таблиці для користувачів з рівнем ізоляції, який не більший за рівень ізоляції того, хто зробив запит.

Рівень ізоляції означає ступінь приорітетності обробки в системі, він визначає, наскільки захищена інформація бази даних, з якою працюють в даний момент, від інших користувачів і від тих, хто виконує запити на ці дані до сервера. Існує декілька рівнів ізоляції.

В MS SQL Server pівні ізоляції транзакцій встановлюютья на весь час роботи з базою даних. Якщо рівні ізоляції змінюють для деякої частини додатка, то наприкінці роботи слід повернутися до стандартної установки, щоб не впливати негативно на інші частини додатка.

Розглянемо рівні ізоляції.

Найнижчому рівню ізоляції відповідає так званий метод Read Uncommited виконання операцій (його ще називають dirty read – “брудне читання”). При виконанні запиту на даному рівні ізоляції ні для яких даних не виконується блокування. Крім того, при цьому не діють блокування, встановлені іншими користувачами. Запит вибирає абсолютно всі дані, навіть ті, які в процесі іншого запиту були вже видалені. Наприклад, якщо якийсь користувач видалив цілу таблицю, але ще не виконав транзакцію, то інший користувач ще зможе прочитати дані з цієї таблиці, не отримавши ніяких повідомлень про помилку.

Зауважимо, що рівень ізоляції Read Uncommited не рекомендується використовувати в додатках, для яких важлива цілісність даних, оскільки ніхто не може гарантувати, що дані, з якими працюють, не змінилися і як і раніше знаходяться в базі даних. Як правило, цей рівень застосовують лише в процедурах (наприклад, створення звітів для таблиць), дані для яких, за статистикою, не змінюються звичайними транзакціями, спрямованими до сервера.

Стандартним методом виконання операцій є Read Commited. Він не дозволяє повертати з бази дані, які є “брудними“ або неоновленими. На даному рівні ізоляції система виконує розділяєме блокування для всіх сторінок, які приймають участь в транзакції. Але можливі ситуації, коли інший користувач паралельно виконує видалення чи вставку даних, завершує або відмінює виконання транзакції. В результаті можна отримати деякі сторінки даних, які будуть містити недійсні чи тимчасові значення.

Якщо для користувача дуже важливо, щоб на результати запиту не впливали інші користувачі, які паралельно з першим виконують деяку транзакцію, то йому обов’язково слід використовувати рівень ізоляції Repeatable Read. Цей рівень явно блокує дані, захищаючи їх від інших користувачів. Саме тому він гарантує, що на дані, з якими працює один користувач, не впливатимуть транзакції, виконані іншими під час роботи конкретної транзакції. При застосуванні Repeatable Read знижується кількість різних користувачів, які одночасно можуть звертатися до даних, не впливаючи на роботу один одного (зменшується ступінь паралелізму бази даних).

Нарешті, останній рівень ізоляції – Serializable. Цей метод підтримує всі обмеження, характерні рівню Repeatable Read. Одночасно з цим він попереджує читання фіктивних (тобто вже не існуючих) даних.