СУБД INFORMIX. Адміністрування і безпека
Безпека
У серверах баз даних фірми INFORMIX можна обмежити або зовсім заборонити користувачам доступ до даних. Доступ можна обмежити на наступних чотирьох рівнях:
1. У випадку, якщо БД зберігається у файлах операційної системи, обмеженням доступу можна керувати за допомогою засобів ОС. Однак цей рівень недоступний при використанні сервера INFORMIX-OnLine. Це ядро само керує власним дисковим простором і правила операційної системи тут не застосовні.
2. Можна використовувати оператори GRANT і REVOKE, щоб надати або заборонити доступ до БД або окремим таблиць, а також дозволяти або забороняти проводити користувачами окремих операцій над БД.
3. Можна використовувати оператор CREATE VIEW для створення що обмежує або оновити подання. Обмеження можуть бути горизонтальними (виключають деякі рядки) або вертикальними (виключають деякі стовпці) або одночасно вертикальними і горизонтальними.
4. Допускається використання оператора GRANT спільно з оператором CREATE VIEW для досягнення більш повного контролю над частинами таблиці та даними, які користувач може змінювати.
Безпека на рівні файлів
Ядра баз даних INFORMIX (за винятком INFORMIX-OnLine) зберігають бази даних у файлах операційної системи. Файли зібрані в каталозі, який представляє базу даних в цілому. Можна заборонити доступ до бази даних, заборонивши доступ до каталогу бази даних засобами операційної системи.
Надання привілеїв
Дозвіл на використання бази даних називається привілеєм. Наприклад, дозвіл на використання бази даних взагалі називається привілеєм CONNECT, тоді як дозвіл на додавання рядків до таблиці називається привілеєм INSERT. Можна керувати доступом до бази даних, надаючи привілеї користувачам або скасовуючи їх.
Привілеї діляться на дві групи: одна група привілеїв стосується бази даних в цілому, інша - окремих таблиць.
Привілеї бази даних
Три рівні привілеї бази даних забезпечують загальні засоби управління тим, хто має доступ до бази даних.
привілею CONNECT
Привілеєм самого нижнього рівня є привілей CONNECT, яка надає користувачеві базові можливості запитувати і оновлювати таблиці. Користувач з цим привілеєм може проводити такі операції:
Виконувати оператори SELECT, INSERT, UPDATE і DELETE при наявності необхідних привілеїв рівня таблиці;
Створювати подання за умови, що йому дозволено виконувати таблиці, на яких грунтуються подання;
Створювати тимчасові таблиці та індекси на них. Для цього користувач повинен мати привілеєм CONNECT. Зазвичай, якщо БД не містить конфіденційної інформації, відразу після створення бази даних виконується операція GRANT CONNECT TO PUBLIC.
привілею RESOURCE
Дана привілей надає ті ж можливості, що і привілей CONNECT, крім того, користувач з привілеєм RESOURCE може виконувати наступні операції:
Змінювати визначення існуючих таблиць шляхом видалення або додавання певних стовпців, індексів;
Створювати нові постійні таблиці та індекси до них.
привілею адміністратора баз даних
На вищому рівні з трьох рівнів привілеїв бази даних знаходяться привілеї адміністратора бази даних (АБД). Творець бази даних автоматично стає її адміністратором. Користувач цього рівня доступу може здійснювати наступне:
Вставляти, видаляти або змінювати рядки в будь-якій з таблиць системного каталогу за винятком systables;
Видаляти або змінювати будь-який об'єкт незалежно від того, кому він належить;
Створювати, таблиці, індекси і представлення, які будуть належати іншим користувачам;
Надавати привілеї бази даних, включаючи привілей АБД.
Привілеї користувачів і інші загальнодоступні привілеї
Привілеї надаються окремим користувачам за їхніми іменами, або всім користувачам - під ім'ям PUBLIC. Всі привілеї, надані під ім'ям PUBLIC, діють як привілеї за замовчуванням. Перш, ніж виконати оператор, ядро бази даних визначає, чи має користувач необхідними привілеями. Спочатку ядро шукає привілеї, надані саме даному користувачеві. Якщо необхідні привілеї виявлені, то вони надаються даному користувачеві. Якщо ж користувачеві такі привілеї не надані, то сервер шукає їх серед загальнодоступних. Якщо такі знайдені, то ядро використовує їх. Таким чином, можна встановити мінімальний рівень привілеїв для користувачів, надавши привілеї PUBLIC. У конкретних випадках ці привілеї можуть бути перекриті шляхом надання користувачеві більш сильних привілеїв.
Якщо привілей CONNECT не робиться загальнодоступною, то доступ до бази даних зможуть отримати лише ті користувачі, які мають цей рівень привілеїв.
Права володіння
База даних, так само, як і кожна таблиця, подання або індекс та синонім цієї бази має свого власника. Зазвичай власником БД є той, хто його створив, хоча адміністратор бази даних може створювати об'єкти, які стають належать іншим користувачам. Власник об'єкта має на нього всі права і може змінити або видалити об'єкт без якихось додаткових привілеїв. Привілеї потрібні тільки для користувачів, які не є власниками об'єкта.
Привілеї рівня таблиці
Існує шість привілеїв рівня таблиці, що дозволяють передати користувачам, які не є власниками таблиці, привілеї власника. Чотири з них - SELECT, INSERT, UPDATE і DELETE - керують доступом до вмісту таблиці. Привілей INDEX керує створенням індексу. Привілей ALTER визначає можливість змінювати визначення таблиці. У ANSI-сумісних базах даних привілеї на таблицю відразу після її створення має тільки власник. В інших базах даних ядро в процесі створення таблиці автоматично робить все табличні привілеї, за винятком привілеї ALTER, загальнодоступними. Це означає, що тільки що створена таблиця може бути доступна користувачеві, який має привілей CONNECT. Якщо це небажано, то після створення таблиці її власник повинен скасувати всі привілеї, надані PUBLIC у зв'язку з цією таблицею.
привілею доступу
Чотири привілеї керують тим, як користувач може звертатися до таблиці. Власник таблиці може надавати чи не надавати, незалежно одна від одної, наступні привілеї:
привілею SELECT дозволяє робити вибірку, у тому числі в тимчасові таблиці;
привілею INSERT дозволяє додавати в таблицю нові рядки;
привілею UPDATE дозволяє змінювати існуючі рядка;
привілею DELETE дозволяє видаляти рядки.
привілею SELECT необхідна для вибірки вмісту таблиці, однак цей привілей не є необхідною для володіння іншими привілеями. Користувач може мати привілеї INSERT або UPDATE, не маючи при цьому привілеї SELECT.
Привілеї INDEX і ALTER
привілею INDEX дозволяє створювати і змінювати індекси в таблицях. Цей привілей, так само, як і привілеї SELECT, INSERT, UPDATE, DELETE, стає загальнодоступною після створення таблиці. Можна надати привілей INDEX всім користувачам, але зможуть користуватися нею тільки ті користувачі, хто має привілей RESOURCE рівня бази даних. Таким чином, хоча привілей INDEX надається автоматично (крім ANSI-сумістити баз даних), користувачі, що володіють тільки привілеєм рівня бази даних CONNECT не зможуть скористатися привілеєм INDEX. Це має сенс, коли індексні файли займають багато місця на диску.
привілею ALTER дозволяє користувачеві використовувати оператор ALTER TABLE, включаючи можливість додавати або видаляти стовпці і т.д. Слід надавати дану привілей тільки тим користувачам, які добре розуміють модель бази даних і достатньо кваліфіковані, щоб використовувати цей привілей дуже акуратно.
Привілеї рівня стовпця
Можна деталізувати привілеї SELECT та UPDATE іменами певних стовпців. Це дозволить більш тонко розмежувати доступ користувачів до таблиці: можна дозволяти користувачеві бачити або оновлювати тільки певні стовпці.
Наприклад:
CREATE TABLE emp_data
(
emp_num integer,
emp_name char (20),
hired date,
id-code char (10),
salary decimal (4,2)
)
Оскільки таблиця містить конфіденційні дані, то відразу після її створення слід виконати оператор REVOKE, який забороняє доступ до даних:
REVOKE ALL ON emp_data FROM PUBLIC
Для окремих співробітників відділу кадрів і менеджерів виконується оператор типу:
GRANT SELECT ON emp_data TO andrew_p, michael_d
Таким чином, деяким користувачам дозволено бачити всі стовпці.
У загальних рисах синтаксична запис правил безпеки доступу до даних виглядає наступним чином:
GRANT спісок_прівілегій_через_запятую [(спісок_атрібутов через_запятую)]
ON вираз TO спісок_пользователей_через_запятую
Для менеджерів, які повинні вводити деякі відомості про службовців, необхідно виконати оператор типу:
GRANT SELECT, UPDATE, INSERT, DELETE (salary, hired) ON emp_data TO alex_v, nataly_d
Цей оператор дозволяє отримати доступ до даних про зарплату та дату прийому на роботу службовців. Для деяких користувачів з відділу кадрів, які повинні складати технічні дані про співробітників, потрібно виконати оператор типу:
GRANT SELECT, UPDATE, INSERT, DELETE (emp_num, emp_name, id-code) ON emp_data TO nataly_d
Привілеї в системному каталозі
Привілеї реєструються в таблицях системного каталогу. Кожен користувач, що володіє привілеєм CONNECT, може запросити інформацію з таблиць системного каталогу, щоб визначити, які й кому надано привілеї.
Привілеї бази даних реєструється в таблиці sysusers, в який первинним ключем є ідентифікатор користувача, а в іншому стовпці знаходиться символ C (CONNECT), R (RESOURCE) або D (DBA), що позначає рівень привілеїв. Загальнодоступні привілеї відображені під іменем користувача public (у нижньому регістрі).
Привілеї рівня таблиці знаходяться в таблиці systabauth, в якій використовується складовою первинний ключ, що включає номер таблиці, ідентифікатор користувача, який надав привілеї на таблицю та ідентифікатор користувача, що отримав їх. У стовпці tabauth привілеї закодовані у вигляді шестібуквенного списку таким чином (дефіс позначає не надану привілей):
s - SELECT
u - UPDATE
- - * привілей на стовпчики
i - INSERT
d - DELETE
x - INDEX
a - ALTER
r - REFERENCES (звернення до заданої таблиці в обмеженнях цілісності)
Таким чином, повний комплект привілеїв виглядає як su-idxar.
Наприклад, набір-u ------ каже, що користувач має тільки привілеєм UPDATE.
Якщо у третій позиції присутній зірочка, то це означає, що для цієї таблиці і користувача існують ще якісь привілеї рівня стовпця. Конкретні привілеї реєструються в таблиці syscolauth. Її первинний ключ складається з номера таблиці, ідентифікатора користувача, який надав привілеї, що отримав привілеї, і номера стовпця. Єдиний атрибут - двобуквений список, що показує тип привілеї: s-,-u або su.
Привілеї та подання
При створенні подання ядро БД перевіряє привілеї користувача на відповідні таблиці та подання. При використанні ж уявлень перевіряються тільки привілеї на саме уявлення.
Привілеї при створенні подання
При створенні подання ядро БД перевіряє наявність у користувача всіх привілеїв, необхідних для виконання оператора SELECT у визначенні подання. Якщо таких привілеїв немає, подання не створюється. Ця перевірка не дозволяє користувачеві дістати несанкціонований доступ до таблиці шляхом створення подання для неї й звернення до подання. Після створення подання ядро БД надає його творцеві і власникові, як мінімум, привілей SELECT для цього подання. Воно не стає автоматично загальнодоступною, як це відбувається з таблицею. Ядро БД визначає визначення подання і з'ясовує, чи є воно обновлюваним. Якщо так, то творець подання отримує привілеї INSERT, DELETE і UPDATE для цього подання за наявності цих привілеїв на породжує таблиці або поданні. Іншими словами, якщо створюється вистава є обновлюваним, то ядро БД копіює привілеї INSERT, DELETE і UPDATE творця подання і надає їх йому на новому поданні. Якщо для породжує таблиці творець подання має в своєму розпорядженні тільки привілеєм INSERT, то він отримає на подання тільки цей привілей і т.д. Ця перевірка не дозволяє користувачам отримати будь-які привілеї крім тих, які у нього вже є.
Оскільки для подання не можна виконувати оператори ALTER TABLE і CREATE INDEX, привілеї і ALTER INDEX ніколи не розповсюджуються на подання.
Привілеї при використанні подання
При спробі використати представлення, ядро БД перевіряє лише ті привілеї, які відносяться лише до самого поданням. Воно не перевіряє права на доступ до визначальних його таблиць. Привілеї творця уявлення вже відзначалися раніше. Для інших користувачів привілеї визначаються творцем або тим, у кого є привілей WITH GRANT OPTION. Це означає, що можна створити таблицю і скасувати її загальнодоступність. Потім можна надати обмежені права на доступ до таблиці через уявлення.
Нижче наводиться синтаксис оператора GRANT:
GRANT спісок_прівілегій_через_запятую ON об'єкт
TO спісок_пользователей_через_запятую [WITH GRANT OPTION]
Директива WITH GRANT OPTION наділяє зазначених користувачів особливими повноваженнями - правом надання повноважень іншим користувачам. Це означає, що для роботи з цим об'єктом вони можуть наділяти повноваженнями інших користувачів.
Роботу з уявленнями можна продемонструвати на прикладах з таблицею emp_data:
CREATE TABLE emp_data
(
emp_num integer,
emp_name char (20),
hired date,
id-code char (10),
salary decimal (4,2)
)
Нехай після створення таблиці був виконаний наступний оператор:
REVOKE ALL ON emp_data FROM PUBLIC
Тепер створимо кілька вистав для різних категорій користувачів. Для тих, хто може мати доступ з читання з неконфіденційні стовпців, створимо таке уявлення:
CREATE VIEW emp_data AS
SELECT emp_num, emp_name FROM emp_data
Користувачі, що одержали привілей SELECT для даного подання, можуть бачити деякі дані без можливості відновлення. Для працівників відділу кадрів створимо таке уявлення:
CREATE VIEW enter_data AS
SELECT emp_num, emp_name, id-code, salary FROM emp_data
Цим користувачам необхідно надати привілеї INSERT і UPDATE для цього подання. Так як творець таблиці та подання має привілеї на вставку як для таблиці так і для представлення, можна надати привілеї INSERT і UPDATE на представлення навіть тим користувачам, у яких немає такої привілеї:
GRANT SELECT, INSERT, UPDATE ON enter_data TO olga_s, helena_m
Для деяких користувачів, які можуть вводити або змінювати деякі дані про співробітників, створимо ще одне подання:
CREATE VIEW enter_upd AS
SELECT emp_num, emp_name, id-code FROM emp_data
Це подання відрізняється від попереднього тим, що в останньому не показуються дані про зарплату співробітників. Нарешті, нехай менеджерам необхідний доступ з читання і редагування всіх даних про працівників фірми:
CREATE VIEW all_data AS
SELECT * FROM emp_data
Тепер можна дати менеджерам всі привілеї:
GRANT SELECT, UPDATE, INSERT, DELETE ON emp_data TO alex_v
Адміністрування сервера INFORMIX-OnLine
Впровадження в інформаційну систему сервера INFORMIX-OnLine Dynamic Server вимагає вирішення багатьох питань, які впливають на продуктивність системи в цілому. Необхідно вирішити питання, де будуть зберігатися дані, як до них буде здійснюватися доступ, як захистити дані. OnLine Server дозволяє налаштувати систему на оптимальну продуктивність. Для цього необхідно розуміти архітектуру сервера і вимог, що виникають під час експлуатації сервера.
Організація зберігання даних
Сервер INFORMIX-OnLine може зберігати дані на диску двома способами. Перший спосіб - це зберігання даних у файловій системі ОС. Другий спосіб - зберігання даних на "сиром" дискового простору. В останньому випадку сервер INFORMIX-OnLine сам керує вводом-висновком даних.
Одиниці зберігання даних
Сервер INFORMIX-OnLine використовує наступні фізичні одиниці зберігання інформації: chunk, page, blobpage, extent .
Логічні одиниці зберігання даних пов'язані з управлінням БД. До логічним одиниць відносяться: dbspace, blobspace, database, table, tblspace .
На додаток до цього існують такі одиниці зберігання інформації про фізичну і логічної цілісності даних: logical log, physical log, reserved pages.
Фрагмент диска chunk - це макси?? альна фізична одиниця зберігання інформації сервером INFORMIX-OnLine. Фрагмент може бути файлом операційної системи або спеціальним пристроєм символьним системи. У першому випадку дані розміщуються в звичайному файлі і записом на диск управляє ОС. У цьому випадку INFORMIX-OnLine не гарантує, що записані дані реально потраплять на диск, тому що дані можуть бути поміщені в дискову кеш-пам'ять ОС. У другому випадку сервер гарантує, що ті дані, які повинні бути записані на диск, будуть записані. Крім цього, помітно вища продуктивність системи вводу-виводу. Однак не кожна операційна система дозволяє організувати chunk на "сиром" диску. INFORMIX-OnLine підтримує розмір chunk до 2 GB. Максимальна кількість chunk'ов - 2048.
Сторінка page - це одиниця інформації, якою сервер INFORMIX-OnLine обмінюється з пристроєм зберігання даних для доступу до БД. Розмір сторінки варіюється. Звичайно це 2 або 4 КБ. Фрагмент диска містить певну кількість сторінок. Сторінка не може виходити за межі chunk'а.
Blobpage - одиниця дискового простору, якою INFORMIX-OnLine маніпулює для зберігання даних типу BYTE і TEXT. Розмір blobpage задається адміністратором і може варіюватися.
Коли створюється таблиця, INFORMIX-OnLine виділяє фіксоване число сторінок для зберігання даних. Коли виділений простір вичерпується, сервер виділяє додаткове місце. Фізична одиниця даних, що використовується для цих цілей, називається extent . При створенні таблиці задаються initial extent size і next extent size . Перший - початковий обсяг під таблицю (в кілобайтах). Другий - величина приросту обсягу таблиці в кілобайтах.
Extent завжди зберігається в межах одного chunk'а і не може перекривати його межі. У випадку, коли INFORMIX-OnLine не може виділити достатньо простору в поточному фрагменті, він шукає його в іншому фрагменті.
Базовою логічною одиницею зберігання інформації сервером INFORMIX-OnLine є простір БД (dbspace). Простір БД відображає фізичний простір на логічне простір зберігання даних. Зазвичай одному dbspace відповідає один chunk, хоча одному dbspace може відповідати кілька фрагментів.
дзеркала
дзеркала дозволяє резервувати фрагмент диска точно такого ж розміру фрагментом. Запис у первинний chunk породжує запис до резервного chunk. У разі збою первинного фрагмента сервер INFORMIX-OnLine перемикається на резервний автоматично, при цьому робота користувача не переривається.
Технологія резервування дозволяє адміністратору відновлювати дані в первинному фрагменті паралельно з роботою користувача з вторинним фрагментом.
За можливість віддзеркалення доведеться платити додатковим дисковим простором.
У випадку, коли незеркалірованний chunk виходить з ладу, INFORMIX-OnLine не може дістатися до даних з нього і буде повертати помилку при зверненні до цього фрагменту. Якщо з ладу вийшов незеркалірованний фрагмент, який зберігає logical log, physical log або root dbspace, сервер негайно переходить в режим off-line, тобто припиняє роботу.
Сервер робить запис в обидва фрагменти паралельно і читає з обох різні частини (split read) для мінімізації часу введення-виведення.
Коли створюється віддзеркалювати chunk, INFORMIX-OnLine копіює дані з первинного у вторинний. Такий процес називається відновленням (recovery). Віддзеркалення починає працювати відразу після завершення процесу відновлення.
Фізичний і логічний протоколи роботи
Фізичний протокол (physical log)
Ведення фізичного протоколу є процес збереження сторінок, який INFORMIX-OnLine збирається змінювати, але до того, як будуть внесені реальні зміни в сторінки. Іншими словами, сервер перед модифікацією сторінок в пам'яті скидає їх копії в буфер фізичного протоколу в пам'яті.
Фізичний протокол - це безліч послідовних сторінок, де INFORMIX-OnLine зберігає незмінені сторінки ( before-image ). Це потрібно для швидкого відновлення після "падіння" сервера.
Сервер маніпулює before-image в буфері фізичного протоколу до тих пір, поки один з очищувачів сторінок не запише його на жорсткий диск.
Не потрапляють до протоколу blob-сторінки з blopspace, тому що в іншому випадку може статися переповнення фізичного протоколу.
Під час ініціалізації сервер розміщує файли логічного та фізичного протоколів у кореневому просторі БД root dbspace. Через критичності фізичного протоколу для роботи INFORMIX-OnLine рекомендується віддзеркалювати dbspace, в якому зберігається цей протокол.
Сервер виконує фізичний протокол за шість кроків:
Читає сторінки даних в буфер.
Копіює незмінені сторінки в буфер фізичного протоколу.
Відображає зміни в буфері сторінки після того, як додаток змінює дані.
Зберігає буфер фізичного протоколу власне у фізичному протоколі на диск.
Зберігає буфер сторінки на диск.
При спрацьовуванні контрольної точки (checkpoint) скидає буфер фізичного протоколу на диск і потім очищає фізичний протокол.
Логічний протокол (logical log)
Сервер INFORMIX-OnLine зберігає історію змін до БД і сервер з моменту створення останнього архіву та збереження записів протоколу. Сервер зберігає записи протоколу в логічному протоколі, з якого створюються файли логічного протоколу. Цей протокол називається логічним з тієї причини, що в ньому зберігаються одиниці роботи, пов'язані з логічними операціями роботи сервера БД на противагу фізичним операціях сервера.
Всі БД, керовані одним сервером INFORMIX-OnLine, зберігають свій протокол в одному і тому ж логічному протоколі сервера.
Файли логічного протоколу не є файлами операційної системи. Це частина дискового простору, керованого INFORMIX-OnLine. Кожен файл логічного протоколу - це окремий простір на диску.
При даної активності системи, чим менше буде віддано під файл логічного протоколу, тим швидше це місце буде заповнено, і більша ймовірність того, що активність користувача буде заблоковано під час архівування логічного протоколу та спрацювання контрольної точки.
Архівування файлу логічного протоколу
Коли файл логічного протоколу заповнений, його необхідно помістити його в архів. Процес архівування може "заморозити" процес обробки транзакцій, які працюють з даними з того ж диску, що й файл логічного протоколу. Тому рекомендується вибирати час малої активності користувачів для архівування файлу протоколу.
Контрольні точки
Як мінімум одна контрольна точка повинна бути записана в логічний протокол. Якщо необхідно звільнити файл, що містить останню контрольну точку, то треба записати нову контрольну точку в поточний файл логічного протоколу. Відповідно, чим частіше архівується файл логічного протоколу і чим частіше він звільняється, тим частіше трапляються контрольні точки. Оскільки контрольна точка блокує роботу користувачів, то це негативно позначається на продуктивності.
Загальний розмір логічного протоколу є твір кількості файлів протоколу на їх розмір:
Мінімальний розмір файлу логічного протоколу - 200 KB.
Максимальний розмір не обмежений, але слід мати на увазі, що якщо архівація відбувається на повільний Стример, то краще робити розмір файлу невеликим.
Чим менше розмір файлу, тим менше інформації може бути втрачено, тому що є вірогідність втратити останній не збережений файл логічного протоколу при виході диска з ладу.
Завжди необхідно мати мінімум 3 файла логічного протоколу.
Необхідно завжди мати достатню кількість файлів логічного протоколу для того, щоб завжди мати можливість переключитися на новий файл і не допустити переповнення цих файлів.
При ініціалізації дискового простору INFORMIX-OnLine розміщує файли логічного проколу в кореневому просторі БД (root dbspace). Файли логічного протоколу містять критично важливу інформацію і повинні бути зазеркаліровани для забезпечення максимальної надійності даних.
Кожен файл має свій унікальний ідентифікатор. Послідовність номерів починається з 1 для першого файлу логічного протоколу, заповненого після ініціалізації дискового простору. При заповненні поточного файлу сервер перемикається на наступний і присвоює йому номер на 1 більше, ніж попередній.
Актуальне дисковий простір, виділений для кожного файлу логічного протоколу, має ідентифікаційний номер logid. Наприклад, якщо ви настроїти 6 логічного протоколу, то ці файли мають номери від 1 до 6. Після того, як ці файли архівовані і звільнені, INFORMIX-OnLine повторно використовує дисковий простір для файлів логічного протоколу, однак сервер буде нумерувати унікальним ідентифікатором, якої дорівнює попереднього плюс одиниця.
Файли логічного протоколу мають один з наступних статусів:
Added (A) Файл протоколу має статус доданий , коли цей файл тільки що доданий. Він не буде доступний для використання до тих пір, поки не буде створено архів нульового рівня кореневого простору БД.
Free (F) Файл логічного протоколу вільний , коли він доступний для використання. Цей файл був звільнений після архівування, всі транзакції усередині файлу протоколу були завершені і останній запис контрольної точки знаходиться в наступному по порядку протоколі.
Used (U) Файл логічного протоколу задіяний , коли він потрібен сервером для відновлення (відкинути транзакцій або шукати останнього запису контрольної точки).
Backed-up (B) Файл протоколу має статус заархівований після того, як цей файл був справді заархівований.
Current (C) Файл протоколу має статус поточний , коли сервер заповнює його протоколом.
Last (L) Файл має статус останній , коли він містить саму останню запис контрольної точки. Цей файл не може бути звільнений до тих пір, поки сервер не запише нову контрольну точку в інший файл логічного протоколу.
Якщо INFORMIX-OnLine намагається перейти на наступний по порядку файл логічного протоколу, який ще не звільнений, то вся робота припиняється. Це відбувається навіть в тому випадку, коли один з файлів протоколу вільний. Сервер не може використовувати випадковий за номером файл. Робота зупиняється для захисту даних у файлі протоколу. Файл логічного протоколу може бути зайнятий з наступних причин:
Файл логічного протоколу не заархівований.
Файл містить відкриту транзакцію.
Довга транзакція - це така транзакція, яка починається в одному файлі логічного протоколу і не фіксується, коли INFORMIX-OnLine потребує повторного використання того ж файлу протоколу. Тобто довга транзакція перекриває більше простору, ніж виділено всього під логічний протокол.
Оскільки сервер не може звільнити файл логічного протоколу до тих пір, поки всі записи не будуть асоційовані з закритими транзакціями, довга транзакція заважає звільнити перший файл протоколу і робить його недоступним для використання.
Для запобігання такій ситуації потрібно врахувати наступне:
Перевірити, чи не заповнюється чи файл логічного протоколу занадто швидко.
Перевірити, не залишається чи транзакція занадто довго відкритою.
Встановити кордон, після досягнення якої INFORMIX-OnLine автоматично зверне обробку довгою транзакції.
Архівація даних
Система відновлення INFORMIX-OnLine дозволяє архівувати дані та відновлювати їх у разі псування.
Пристрій системи відновлення даних
Архів - це копія всіх або частини даних, якими управляє сервер, тобто це копія одного або більше dbspace і будь-яких допоміжних даних, які можуть знадобитися для відновлення.
Архів логічного протоколу - це копія файлів логічного протоколу на диску або стрічці, які заповнені й готові до архівування.
Відновлення - це процес відновлення даних INFORMIX-OnLine, зокрема, просторів БД з архіву та архівних файлів логічного протоколу.
Фізичне та логічне відновлення
Відновлення даних необхідно проводити в два етапи. Перший етап - фізичне відновлення, другий - логічне відновлення. Фізичне відновлення - процес відновлення сторінок просторів БД з архіву. Логічне відновлення використовує архівовані логічний протокол для "накату" транзакцій у відновлених просторах БД.
Система відновлення INFORMIX-OnLine
INFORMIX-OnLine надає дві системи відновлення даних: ON-Archive і ontype . Вони дозволяють зробити наступне:
Архівувати дані INFORMIX-OnLine;
Архівувати файли логічного протоколу;
Робити додатковий архівування файлів логічного протоколу;
Відновлювати дані з архіву;
На додаток до цього On-Archive дозволяє наступне:
Планування і відстеження архівів;
Безліч засобів захисту та доступу до On-Archive ;
Можливість паралельно працювати з декількома стрічковими пристроями;
Працювати без безпосередньої участі людини.
Збереження сторінок і логічного протоколу в архіві
Все, чим керує INFORMIX-OnLine може бути заархівовані за винятком наступного:
Сторінки dbspace, виділені для сервера, але не прив'язані до якогось фрагменту tblspace;
Конфігураційні файли не архівуються;
Сторінки з дзеркальних фрагментів не архівуються, якщо доступний первинний фрагмент;
Blob'и в blobspace, що зберігаються на оптичному носії;
Рівні архіву
Немає сенсу щоразу архівувати всі дані INFORMIX-OnLine. Підтримуються три типи додаткового архівування:
Level-0 - архівуються всі сторінки;
Level-1 - архівуються всі зміни з моменту останнього архіву нульового рівня;
Level-2 - архівуються всі зміни з моменту останнього архіву першого рівня.
Архівування логічного протоколу
Якщо було ініційовано протоколювання БД, то INFORMIX-OnLine записує транзакції, що відбулися між процедурами архівування, в логічний протокол, який складається з певного числа файлів логічного протоколу на диск. Сервер потребує як у запису нових даних в протокол, так і в читанні протоколу для відновлення транзакцій. Для того, щоб файли логічного протоколу не закінчилися, необхідно архівувати заповнені файли логічного протоколу.
Якщо ж протоколювання не використовувати, тим не менше, все одно необхідно архівувати файли логічного протоколу. У цьому випадку протокол містить інформацію про створення та видалення фрагментів диска і про запис контрольної точки. Ця інформація потрібна для "теплого" відновлення БД навіть у тому випадку, коли БД не записуються.
Автоматичне і безперервне архівування
Якщо необхідно архівувати файли логічного протоколу відразу після їх заповнення, то потрібно запустити автоматичне архівування. У цьому режимі архівуються всі файли логічного протоколу, готові до архівування і процес зупиняється на поточному файлі.
Також можна запустити безперервне архівування. Тоді сервер автоматично архівує файл логічного протоколу відразу щодо його заповнення.
При автоматичному архівуванні немає необхідності пам'ятати про створення резервної копії файлу, але потрібно пам'ятати, що на пристрої архівування завжди має бути вільне місце.
Режими відновлення даних
У процесі відновлення INFORMIX-OnLine відтворює дані, які стали недоступними в результаті апаратного або програмного збою. У будь-якому з трьох наведених нижче випадках необхідне відновлення даних:
Помилка в програмі запортіла дані в БД;
Необхідно перенести дані на інший комп'ютер.
Процес відновлення ділиться на фази фізичного та логічного відновлення:
При фізичному відновленні з архіву відновлюються сторінки dbspace і blobspace;
При логічному відновлення проводиться відновлення транзакцій.
Вибір типу фізичного відновлення
Якщо необхідно відновити дані після збою, в результаті якого сервер перейшов у режим off-line, то необхідно відновити всі дані, керовані сервером. Такий тип відновлення називається повним відновленням системи. Якщо збій не призвів до останову системи, то можна вибірково відновлювати вибіркові dbspace або blobspace.
При переході INFORMIX-OnLine в режим off-line через збій диска критичні дані dbspace будуть пошкоджені. До критичним dbspace відносяться:
root dbspace;
містить фізичний протокол dbspace;
містить файли логічного протоколу dbspace.
Відновлення критичних dbspace необхідно проводити в "холодному" режимі.
Вибіркове відновлення dbspace ил?? blobspace
Якщо після збою INFORMIX-OnLine не перейшов у стан off-line, то пошкодження dbspace не є критичними. Якщо збій трапився у фрагменті диска dbspace, який розміщується на декількох фрагментах, то всі активні транзакції у цьому dbspace повинні бути перервані перед відновленням. Можна запустити операцію відновлення до завершення транзакцій. Тоді процес відновлення буде чекати, поки сервер не завершить перевірку того, що всі транзакції, активні в момент збою, були завершені.
"Холодний" режим відновлення
Як показано на рис. 1, відновлення всіх dbspace і blobspace (повне відновлення системи) можна зробити за допомогою однієї фізичної і одного логічного відновлення.
INFORMIX-OnLine знаходиться в режимі off-line на початку процесу відновлення, але потім, після відновлення резервних сторінок, сервер переходить в режим відновлення. З цього моменту сервер знаходиться в даному режимі до тих пір, поки не буде завершено логічне відновлення.
"Теплий" режим відновлення
В даному режимі можна відновлювати некритичні dbspace і blobspace при роботі INFORMIX-OnLine в режимі on-line або quiescent. "Теплий" режим складається з одного або декількох фізичних відновлень, логічного архівування і відновлення.
При "теплом" відновленні заархівовані файли логічного протоколу "програються" для відновлення транзакцій у відновлених dbspace (рис. 2).
Змішаний режим відновлення
Змішаний режим відновлення складається з холодного відновлення, за яким слідує тепле відновлення. Деякі dbspace і blobspace відновлюються в холодному режимі (INFORMIX-OnLine знаходиться в режимі off-line). Такий режим відновлення звичайно застосовується, коли потрібно повне відновлення системи, але в ході його потрібно частковий доступ до деяких таблиць. У цьому випадку виконується холодне відновлення критичних dbspace і dbspace, які містять важливу інформацію.
Експорт-імпорт даних
Міграція даних, тобто перенесення бази даних або її частин може знадобитися з наступних причин:
Для перенесення розробленої системи замовнику;
Для переносу на іншу апаратну платформу;
Для поширення користувачам;
Для перенесення даних між INFORMIX-SE і INFORMIX-OnLine.
Методи міграції даних, що використовуються в INFORMIX-OnLine
Сервер INFORMIX-OnLine наступні методи для перенесення даних з однієї БД в іншу:
утилітами onunload і onload ;
утилітами dbexport і dbimport ;
виразами LOAD і UNLOAD;
Утилітою dbload .
Утиліти onunload і onload взаємопов'язані, тобто для того, щоб завантажити дані за допомогою onload , їх необхідно попередньо вивантажити за допомогою onunload . Аналогічно, для роботи dbimport потрібні файли, підготовлені dbexport . Утиліта dbload і вираз LOAD можуть завантажувати дані з будь-якого файлу, якщо він відповідає певним вимогам за форматом.
Утиліта dbschema за схемою БД створює файл з виразами на SQL, який можна використовувати потім для створення таблиць з аналогічною структурою.
Використання утиліт onunload і onload
Ці дві утиліти в
