Архівації двох головних баз даних — інформаційних сховищ і каталогів — приділяється велика увага як основним елементам надійного збереження інформації та забезпечення відмовостійкості системи.
Існують різні типи архівації та відновлення даних з архіву, виконання яких залежить від програмних продуктів, налаштованих на виконання тих чи інших типів архівації. Наприклад, програма резервного копіювання NT Backup може виконувати архівацію п’яти типів, які ми розглянемо далі.
1. Звичайна архівація (Normal). У разі вибору цього типу архівуються всі вибрані файли незалежно від стану їхніх архівних бітів. Архівні біти всіх заархівованих файлів скидаються.
2. Копіювальна архівація (Copy). Архівуються всі вибрані файли незалежно від стану архівних бітів. Архівні біти всіх заархівованих файлів залишаються в попередньому стані.
3. Додаткова архівація (Incremental). Архівуються всі файли зі встановленим бітом архівації. Як і за звичайної архівації, архівні біти всіх заархівованих файлів скидаються.
4. Диференційована (Differential). У цьому разі архівуються всі файли з установленим бітом архівації. Архівні біти всіх заархівованих файлів залишаються в попередньому стані.
5. Щоденна архівація (Daily). Архівуються всі файли, що зазнали зміни в день архівації. Архівні біти всіх заархівованих файлів залишаються в попередньому стані.
Загальна стратегія архівації полягає в тому, що необхідно щодня проводити звичайну архівацію і додаткову або диференційовану. Оскільки в разі диференційованої архівації стан архівного біта не змінюється, у кожну диференціальну архівацію включаються дедалі нові файли, а також файли, що змінилися з останньої звичайної архівації. Щоб поновити стан сервера в разі диференційованої архівації, необхідно відновити лише останній звичайний і останній диференційний архіви. Тому більшість адміністраторів БД віддають перевагу диференційованій архівації, а не додатковій.
Якщо замість диференційованої архівації використовується додаткова, то для поновлення сервера необхідно відновити останній звичайний архів, а потім послідовно відновити всі додаткові архіви з часу останньої звичайної архівації. Це не лише додає роботи, а й підвищує ймовірність помилок навіть у разі незначного порушення послідовності додаткових архівів.
Хоча диференційовані архіви займають більше місця на магнітному носії (наприклад, магнітній стрічці), бо вони щодня зберігають великий обсяг інформації, витрати на носій значно менші порівняно з витратами часу на поновлення сервера в разі додаткової архівації, не кажучи вже про можливі помилки, спричинені додатковою архівацією.
Архівні магнітні носії зберігають у вогнестійких сейфах або за межами обчислювального центру. Крім того, необхідно розробити план архівації компонентів сервера БД.
Сучасні сервери баз даних автоматично підтримують копію свого каталогу на кожному сервері вузла. Відповідний процес називається реплікацією каталогів (directory replication). Розглянемо цей процес на прикладі Exchange Server.
У процесі копіювання каталогу сервери Exchange вузла звертаються один до одного й переконуються в актуальності їхніх каталогів. Якщо сервер визначає,
що його копія каталогу не синхронізована з іншими, він оновлює її за допомогою одного або кількох серверів вузла. Тому під час відновлення сервера не так важливо, чи містить архів найсвіжішу копію каталогу. Після того, як відновлення буде завершене, інші сервери вузла швидко поновлять відновлений каталог у процесі реплікації.
Практика роботи зі сховищами даних доводить, що звичайна архівація каталогів на всіх серверах здійснюється раз на тиждень у вихідні дні, а диференційована архівація каталогу на всіх серверах здійснюється щодня в робочі дні тижня. У річному архіві зберігають магнітний носій, як правило, останнього тижня місяця.
Зауважимо, що в серверах БД для підвищення мовостійкості системи використовують журнали транзакцій. Усі зміни в каталозі сервера, а також в особистих і загальних інформаційних сховищах попередньо записуються у файли, які називаються журналами транзакцій (transaction log files). Для каталога та інформаційного сховища використовують різні набори журналів транзакцій.
Попередньо служба каталогу або інформаційного сховища записує дані з пам’яті в журнал транзакцій, а потім у саму базу даних. Запис у базу даних потребує виконання багатьох допоміжних операцій, зокрема й індексування. Для запису в журнал трансакцій такі операції не потрібні, тому дані швидко переносяться з пам’яті в журнал. Це зменшує ймовірність втрат трансакцій у разі аварійних ситуацій на сервері. У випадку збою за журналами трансакцій можна швидко поновити поточний стан бази.
Під час використання утиліти Backup для архівації каталогу або інформаційного сховища, розміщених на Microsoft Exchange Server, допускається використання будь-яких типів архівації, окрім щоденної. За звичайної архівації створюються резервні копії баз даних і пов’язаних з ними журналів трансакцій, а після завершення архівації Backup вилучає заархівовані файли журналів.
Під час виконання додаткової архівації каталогу або інформаційного сховища архівують лише журнали трансакцій.
Техніка архівації за допомогою сучасних інструментальних засобів серверів доволі проста. Наприклад, для вибору об’єктів для архівації за умов Microsoft Exchange Server необхідно перейти на праву панель вікна, на якій можна їх вибрати.
Під час першого відкриття вікна Microsoft Exchange на правій панелі виводиться ім’я вашого вузла (або вузлів) Exchange. Для відкриття вузла необхідно двічі клацнути мишкою на його імені. Тепер на панелі з’являться імена серверів (чи сервера) вузла. Після того, як ви двічі клацнете на сервері, що вас цікавить, на правій панелі з’являться два значки, що відповідають каталогу (Directоry) та інформаційному сховищу (Information Store) цього сервера. Вам надається можливість заархівувати каталог чи інформаційне сховище (або і те, і інше). Із заархівованого сховища можна відновити будь-який сегмент (особистий і загальний) чи обидва одразу.
По завершенні архівації інформаційного сховища Backup починає перевірку всіх архівних наборів (якщо у вікні налаштування встановлено прапорець Verify
After Backup), а після успішного її завершення Backup робить відповідне повідомлення.
Після натискання кнопки ОК у діалоговому вікні Verity Status архівація закінчується.
Для відновлення сервера за допомогою архівної копії необхідно спочатку повідомити утиліті Backup, що саме потрібно витягти з архіву, а після цього вказати, яким чином має виконуватися відновлення. Після того, як ви повідомили Backup, що саме необхідно відновити, треба натиснути кнопку Restore в лівому верхньому куті вікна Backup. На екрані з’явиться діалогове вікно Restore Information для відновлення каталогу та інформаційного сховища.
РЕЗЮМЕ Ідею сховищ даних запропонував Б. Інмон (Bill Inmon) 1992 року у своїй книзі «Building the Data Warehouse», присвячений займався проблемам організації корпоративних баз даних. Б. Інмон дав класичне визначення сховища даних (Data Warehouse — DW), схарактеризувавши його як предметно-орієнтований, інтегрований, незмінний набір даних що підтримує хронологію, та організований для цілей управління
Під корпоративним сховищем даних будемо розуміти оптимально організовану базу даних корпорації, що забезпечує максимально швидкий доступ до інформації, необхідної для управління корпорацією.
Вітрина даних. Вітрина даних (Data Mart) за вихідним призначенням — це набір тематично пов’язаних баз даних, що містять інформацію, яка стосується до окремих сфер діяльності корпорації. Вітрина даних — це спрощений варіант сховища тематично об’єднаних даних. Вона максимально наближена до кінцевого користувача і може містити тематично зорієнтовані агрегатні дані. Вітрина даних значно менша за обсягом, ніж корпоративне сховище даних, для її реалізації не потрібна потужна обчислювальна техніка.
Глобальне сховище даних. Останнім часом дедалі популярнішою стає ідея об’єднати концепції сховища даних і вітрини даних в одній реалізації та використовувати сховище даних як єдине джерело інтегрованих даних для всіх вітрин даних. Тоді можна буде створити трирівневу архітектуру системи.
На першому рівні реалізуватиме корпоративне сховище даних на базі однієї з розвинених сучасних реляційних СУБД. Це сховище інтегрованих, переважно деталізованих даних. Реляційні СУБД забезпечать ефективне збереження й управління даними дуже великого обсягу, але вони недостатньою мірою відповідають проблемам OLAP-систем, зокрема через вимогу багатовимірного подання даних.
На другому рівні підтримуватимуться вітрини даних на основі багатовимірної системи управління базами даних (прикладом такої системи є OracleExpress Server). Такі СУБД майже ідеально підходять для розроблення OLAP-систем, але поки що не дозволяють зберігати величезні обсяги даних (граничний розмір багатовимірної бази даних становить 40 Гбайт). Утім коли йдеться про вітрини даних, це непотрібно. Крім того, вітрина даних не обов’язково має бути цілком сформована. Вона може містити посилання на сховище даних і добирати звідти інформацію мірою надходження запитів, і хоча це дещо збільшує час відгуку, але знімає проблему обмеженого обсягу багатовимірної бази даних.
На третьому рівні перебуватимуть клієнтські робочі місця кінцевих користувачів із засобами оперативного аналізу даних.
Корпоративне сховище даних може функціонувати у трьох архітектурах — реляційній (ROLAP), багатовимірній (MOLAP) і гібридній, або змішаній (HOLAP).
Функціями адміністрування є наповнення й обслуговування інформаційних сховищ.
Наповнення інформаційних сховищ має кілька етапів: екстракції, трансформації, завантаження.
ТЕРМІНИ І ПОНЯТТЯ
Корпоративне сховище даних.
Вітрина даних.
Глобальне сховище даних.
Система управління базами даних (СУБД). Інтегрованість даних. OLAP-технологія.
Реляційне сховище (ROLAP).
Багатовимірне сховище (MOLAP).
Гібридне сховище (HOLAP).
Екстракція даних.
Трансформація даних.
Завантаження даних.
Метадані.
ЗАПИТАННЯ ДЛЯ ПЕРЕВІРКИ ЗНАНЬ
Хто вперше запропонував теорію сховища даних?
Розкрити поняття: предметна орієнтація, БД, інтегрованість даних, інваріантність у часі, стабільність даних, мінімізація збитковості у БД.
Розкрийте поняття бази даних і вітрини даних.
Дайте пояснення архітектур сховищ даних ROLAP, MOLAP, HOLAP.
Що Ви розумієте під адмініструванням сховищ даних?
Дайте пояснення поняття метадані.
ЗАВДАННЯ ДЛЯ ІНДИВІДУАЛЬНОЇ РОБОТИ
Спроектуйте структуру глобального сховища даних у вигляді схеми.
Спроектуйте структуру корпоративного сховища даних і дайте пояснення руху інформації у сховищі.
Дайте порівняльну характеристику ROLAP, MOLAP, HOLAP архітектур сховищ даних.
