СУБД 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

Ці дві утиліти вивантажують і завантажують дані з БД або її частини сторінками. Тому на використання цих утиліт накладаються деякі обмеження.

При перенесенні даних між комп'ютерами необхідно:

Переконатися, що розмір сторінки та подання чисел має бути однаковим на обох системах.

Запустити утиліту oncheck для перевірки цілісності бази даних.

Запустити утиліту onunload.

Якщо потрібно, перенести носій з вивантаженими даними на іншу систему.

Запустити утиліту onload.

Встановити бажаний статус протоколювання нової БД.

Створити архів нульового рівня нової БД.

При перенесенні таблиць між комп'ютерами за допомогою onunload і onload необхідно виконати наступні кроки:

Упевнитися, що розмір сторінок і подання чисел однаково на обох системах.

Запустити утиліту oncheck для перевірки цілісності бази даних.

Запустити утиліту onunload.

Якщо потрібно, перенести носій з вивантаженими даними на іншу систему.

Вимкнути протоколювання

Запустити утиліту onload.

Створити архів нульового рівня модифікованої БД.

Включити протоколювання, якщо потрібно.

Створити необхідні синоніми та права доступу до даної таблиці.

Вибір між onunload, dbimport і LOAD

При неможливості використання утиліт onunload і onload, необхідно зробити вибір між dbload, dbimport і LOAD. Кожен з цих способів дозволяє модифікувати схему БД.

Утиліта dbimport завантажує БД цілком і нею необхідно скористатися в тому випадку, коли немає можливості використовувати onload. Для завантаження таблиць використовуйте вираз LOAD або утиліту dbload.

При використанні утиліти dbload (або вирази LOAD) потрібно завантажувати дані у вже існуючу таблицю. Якщо таблиці не існує, то її потрібно створити, наприклад, за допомогою SQL-вирази CREATE можна створити таблицю, подання або синонім.

Модифікація схеми БД

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

Права доступу;

Власника об'єкта (таблиця, індекс, подання);

Режим блокування;

Розміри початкового і наступних extent'ов.

Dbspace, де зберігаються таблиці.

Використання виразів UNLOAD і LOAD

Вираз UNLOAD дозволяє записувати рядки, витягнуті вираженням SELECT у ASCII-файл. Вираз UNLOAD створює файл у відповідність з установками в оточенні користувальницького додатка.

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

Використання утиліти dbload

Дана утиліта, використовуючи команди в командному файлі dbload, може форматувати вхідні дані перед тим, як вставляти їх у вказану таблицю. На додаток до цього опції командного рядка dbload дають такі можливості:

Перевірити синтаксис виразів командного файлу;

Відкладати блокування таблиці під час вставки даних;

Ігнорувати певне число рядків з початку вхідного файлу;

Пропускати некоректні рядки;

Переривати завантаження після певної кількості знайдених некоректних рядків.

Утиліта dbload може брати на вході кілька файлів і вставляти їх вміст в задані таблиці, створені з файлу схеми БД.

Використання утиліт dbexport і dbimport

Утиліти dbexport і dbimport маніпулюють тільки базами даних цілком. Для використання цих утиліт потрібно бути підключеним до сервера БД як користувач informix або мати права системного адміністратора.

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

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

Режими роботи сервера INFORMIX-OnLine

Сервер має декілька режимів роботи:

off-line

quiescent

on-line

read-only

recovery

shutdown

У режимі off-line сервер не запущений.

У режимі quiescent виконуються адміністративні процедури. Для цього припиняється вся робота з базою даних. Тільки користувачі informix і root можуть виконувати адміністративні процедури за допомогою ON-Monitor або утиліт командного рядка. У цьому режимі не можна підключитися до сервера, проте можна дізнатися його поточний стан.

У режимі on-line користувачі можуть приєднуватися до своїх баз даних і виконувати запити. У цей час адміністратор може змінювати певні налаштування в файлі ONCONFIG.

Режим read-only додатки можуть тільки запитувати дані з сервера, але не можуть їх оновлювати.

Режим recovery є перехідним. У цьому режимі сервер знаходиться при переході з режиму off-line в режим quiescent. Швидке відновлення виконується в цьому режимі.

Режим shutdown також є перехідним. Він може виникнути при переході з режиму on-line (або quiescent) у режим off-line.

Засоби діагностики сервера INFORMIX-OnLine

Системна БД sysmaster

INFORMIX-OnLine Dynamic Server створює і підтримує БД sysmaster. Ця база даних містить інформацію про самому сервері. Sysmaster складається з наступних таблиць:

Таблиці SMI

Таблиці інтерфейсу системного моніторингу (SMI) містять інформацію про стан сервера INFORMIX-OnLine. Можна звертатися до цих таблицями для визначення "вузьких місць" в обробці інформації, визначення використання ресурсів, відстеження активності сесій або сервера БД, і т.п.

Таблиці каталогу ON-Archive

Ці таблиці містять інформацію про запити, наборах томів, наборів збереження.

INFORMIX-OnLine створює БД sysmaster автоматично при ініціалізації дискового простору. Не можна видалити цю БД або таблиці в ній, а також не можна змінити стан протоколювання БД.

Можна, як користувач informix, створювати збережені процедури і тригери в цій БД. Але INFORMIX-OnLine не буде виконувати створені користувачем у sysmaster тригери.

Опис таблиць SMI

Інтерфейс системного моніторингу складається з певної кількості таблиць і псевдотабліц, які автоматично підтримуються INFORMIX-OnLine і не скидаються на диск під час роботи.

Таблиці SMI містять наступну інформацію:

Аудітінг

Звернення до дисків

Інформація про користувачів

Статус протоколювання баз даних

Таблиці

Chunk'і

Введення-виведення chunk'ов

Простору БД

Блокування

Extent'и

Системна інформація

Будь-який користувач може запитувати інформацію з будь-якої таблиці sysmaster за винятком таблиць sysadinfo і sysaudit. Останні дві таблиці може переглядати тільки користувач informix.

Тригери по зміні в SMI-таблицях ніколи не виконуються, тому що INFORMIX-OnLine виробляє зміни в SMI-таблицях не за допомогою SQL-виразів.

Нижче наведено список використовуваних SMI-таблиць:

Витяг діагностичної інформації про роботу сервера

Для витягання інформації з таблиць SMI використовується утиліта onstat. Нижче наведені деякі можливі опції цієї утиліти: