Навігація
Головна
 
Головна arrow Інформатика arrow Бази даних
< Попередня   ЗМІСТ   Наступна >

Захист даних, відновлення РБД

Тут мова йде про захист даних в БД і додатків, що запитують дані.

Для захисту адміністратор РБД (АРБД) присвоює пропуску [11] для всіх зареєстрованих в РБД користувачів і дає їм дозволу на виконання конкретних операцій з конкретними даними. Найпростіше це можна виконати, як в СУРБД Oracle, з використанням мови SQL.

У такому випадку, як і в централізованій БД, виділяють режими заборони та дозволи. До заборонам ставляться пароль, ідентифікатор користувача. Вони дозволяють отримати доступ до РБД в цілому.

Окремі частини РБД можуть мати свій захист. Для цього АРБД визначає повноваження (GRANT): перелік операцій, які користувач може виконувати з відповідними елементами даних.

Повноваження можуть ставитися до об'єктів або системі в цілому. Повноваження для окремих об'єктів ("внутрішність таблиці") надають для якої-небудь таблиці конкретним користувачам можливість виконання операцій (INSERT, UPDATE, DELETE). Системні повноваження стосуються всієї БД: створення, зміна структури, видалення будь табличній області, опитування будь-якої таблиці (CREATE, ALTER, DROP, SELECT).

Як і в централізованій БД, перераховані повноваження можуть бути скасовані (REVOKE).

Для цілей захисту АРБД може створювати (використовувати) паролі.

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

Якщо РБД забезпечує цілісні, несуперечливі дані, говорять про її коректному стані (коректності).

Відновлення (управління відновленням) пов'язане з приведенням системи в коректне стан після (апаратного) збою. Будь-який конкретний метод відновлення реагує на певний відмова РБД.

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

Система відновлення вирішує дві групи завдань:

  • 1) при незначній несправності - відкат у виконанні поточної транзакції;
  • 2) при істотних відмовах - мінімізація роботи з відновлення РБД.

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

Копіювання змін можливе після закриття БД. Однак для РБД з інтенсивними оновленнями копіювання (архівацію) слід проводити в процесі роботи РБД.

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

Процедура відновлення проводиться наступним чином.

  • 1. Усувається апаратний збій.
  • 2. Відновлюються зіпсовані файли даних шляхом копіювання архівних копій і груп реєстрації транзакцій.
  • 3. Запускається процес відновлення:
    • а) із застосуванням транзакцій (застосування до архівних копіям зіпсованих даних необхідних груп журналу транзакцій);
    • б) з відміною незавершених транзакцій, які залишилися після відновлення із застосуванням транзакцій.

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

Вивчимо докладніше процес відмови.

Можливо виділити наступні основні стану вузла: справний, несправний (застопорилися, некерований), відновлюваний.

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

Некерований вузол поводиться непередбачувано і може видавати дивні повідомлення, проте через деякий час теж почне відновлюватися.

Обговоримо два можливі випадки роботи вузлів в надійної мережі: без дублювання і з дублюванням даних.

При відсутності дублювання не розглядаються некеровані вузли (вузли з втратою управління).

Звичайно одна транзакція при віддаленому виклику (див. Рис. 12.4) ділиться на серію субтранзакцій. При відкат однієї з них здійснюється відкат транзакції в цілому: фактично система повертається в точку фіксації. При цьому невиконані транзакції або субтранзакціі і після усунення апаратного збою виконуються знову. Відзначимо, що в даному випадку до усунення названого збою відновити роботу РБД фактично неможливо.

Резонно зауважити, що відкат всій транзакції не завжди потрібен. Можливий інший спосіб: перервати тільки відкат субтранзакцію, яка вживає фіксоване число спроб нового виконання. Тільки якщо всі вони закінчаться невдачею, здійснюється відкат всій транзакції. Правда, тут можливий перезапуск виконаних транзакцій (каскадний повернення). Для його усунення, очевидно, потрібен (рис. 12.4) інформаційний обмін (повторні повідомлення) між транзакціями, т. Е. Ускладнюється процедура

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

При дублюванні даних (різні копії зберігаються в різних вузлах) при застопорилися вузлі з'являється можливість роботи транзакцій навіть тоді, коли деякі вузли знаходяться в непрацездатному стані.

Може бути часткове і повне (в кожному вузлі знаходиться повна копія РБД) дублювання.

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

Достоїнствами методу основний копії є єдина послідовність коригування БД і зменшення ймовірності тупика.

У разі читання у всіх доступних вузлах і використання активних вузлів формується і вводиться список U записів про активні вузлах, а основний вузол використовується для відновлення. "Основна" транзакція при оновленні повинна запитувати обстановку для запису і коригування даних у всіх вузлах списку U, включаючи основний. Вдасться уникнути деяких конфліктів (читання-запис, запис-запис). При наявності відмов і відновлень список U змінюється основним вузлом і може виникнути ускладнення.

Приклад 12.1. Нехай транзакція Т формує запит на блокування читання у вузлі 1, а потім цей вузол відмовляє. Коли основний вузол видаляє вузол 1 з U, решта транзакції втрачають можливість запитувати блокування для запису у вузлі 1 і конфлікт Т і наступних транзакцій може виявитися невиділений.

Приклад 12.2. Нехай вузол 2 відновився. Він запитує інформацію про пропущені транзакціях. Основний вузол передає дані по транзакціях Т1, ..., Тn і додає вузол 2 в список U. Однак транзакція Тn + 1, що знаходиться в стані фіксації, має старий список і не буде записувати у вузол 2.

Таким чином, треба ретельно продумувати порядок роботи, бажано з використанням часових діаграм.

Схема відновлення при втраті управління

Рис. 12.7. Схема відновлення при втраті управління:

t1 - відмова; t2 - виявлення відмови; t, - початок відновлення; t4 - кінець відновлення

Можливі й інші методи:

  • 1) вибір нового основного вузла при відмові колишнього, при цьому колишній вузол повинен бути відновлюваним, а новий - "бачити" обстановку, що склалася в колишньому вузлі. Доступ спрощується, але ускладнюється відновлення;
  • 2) голосування по більшості: якщо відмовлять всі вузли фрагмента, треба почекати відновлення мажоритарної групи.

Схема відновлення одного з вузлів показана на рис. 12.7.

Нехай у момент t1 відмовив вузол 2 і його БД зруйнувалася. Якщо вузол 2 цієї статті не буде виправлений до моменту часу t5, то відмова вузлів 1 або 2 призведе до серйозного збою. Вузол 2 виявляє свою відмову до моменту t, і починає відновлюватися, використовуючи "знімки" інших вузлів. На інтервалі t3 - t4 справні вузли повинні продовжувати виконання транзакцій, які повинен запам'ятовувати вузол 2 (і обробляти після моменту t4). З моменту t4 вузол 2 приєднується до решти і система може витримати друга відмова.

 
Якщо Ви помітили помилку в тексті позначте слово та натисніть Shift + Enter
< Попередня   ЗМІСТ   Наступна >
 
Дисципліни
Агропромисловість
Аудит та Бухоблік
Банківська справа
БЖД
Географія
Документознавство
Екологія
Економіка
Етика та Естетика
Журналістика
Інвестування
Інформатика
Історія
Культурологія
Література
Логіка
Логістика
Маркетинг
Медицина
Нерухомість
Менеджмент
Педагогіка
Політологія
Політекономія
Право
Природознавство
Психологія
Релігієзнавство
Риторика
Соціологія
Статистика
Техніка
Страхова справа
Товарознавство
Туризм
Філософія
Фінанси
Пошук