техніку логічного резервування. Якщо у фізичній резервної базі з журнальних даних вибирається інформація про зміни, внесені безпосередньо у файли даних - на фізичному рівні, то в логічній резервної базі реконструюються команди SQL, за допомогою яких ці зміни були внесені (команди, які видавали користувачі при операціях з робочою базою ). Відновивши потік команд, можна повторно ввести їх вже в резервну базу. Зміни вносяться не на фізичному рівні, а на логічному - на рівні таблиць. При цьому фізична структура файлів резервної бази може відрізнятися від тієї, що існує в робочій базі. Достатньо лише, щоб існували об'єкти з тими ж іменами, які є в робочій базі.
Видавати команди SQL, відновлені з журналів, можна з бази, відкритої для роботи користувачів. Необхідно тільки подбати про те, щоб користувачі не конфліктували з процесами, що вносять зміни. Найпростіше рішення - не давати можливості користувачам, що працюють з резервною базою, міняти в ній дані. Таким чином, користувачі можуть працювати з логічною резервною базою в режимі читання.
Використовуючи логічні резервні бази даних, потрібно мати на увазі особливості їх роботи. Відновлення команд SQL і внесення змін до бази вимагають додаткових процесорних ресурсів. Ці процеси деяким чином повторюють всі транзакції, що пройшли на робочій базі. Щоб прискорити внесення змін, на резервній базі створюється пул процесів, які вносять зміни. Він називається Log Apply Services і складається з процесів LSPn - координаторів та PX (parallel execution), які відновлюють команди SQL і вносять зміни. Ці процеси не відновлюють команд, які не змінюють дані (наприклад, SELECT), так як в журнал змін вони не записуються. Зазвичай саме команди SELECT створюють основне навантаження на процесор комп'ютера з основною базою.
Друга особливість роботи логічної резервної бази в тому, що по журналах складно відновити логічні команди, які вносили зміни в основну базу. Для того, щоб резервна база могла це робити, потрібно, щоб в журнал змін додавалася додаткова інформація. Для команд, що змінюють дані в таблицях (INSERT, UPDATE, DELETE, MERGE), потрібно зберігати значення первинного або унікального ключа. Через це обсяг журнальної інформації зростає. Якщо у основної бази канали записи у файли журналів завантажені, продуктивність її знизиться. Логічна резервна база може використовуватися, якщо обсяги змін основної бази невеликі або якщо перемикання користувачів, які не вносять зміни, на роботу з резервною базою зможе розвантажити основну базу.
Технологія відновлення SQL-команд з журналу змін лягла в основу Oracle Streams, нової технології переміщення змін між базами (реплікації). Зміни можна вносити тільки в частину таблиць, а резервна база слабо пов'язана з основною. Можна налаштувати реплікацію змін, зроблених в основній базі, в будь-які інші. Ця ідея була реалізована починаючи з версії 9i як альтернатива існуючим раніше методам реплікації. Перевага Oracle Streams в тому, що навантаження на основну базу даних істотно нижче, ніж при реплікації іншими методами, які доступні в базах Oracle. В архітектурі Oracle Streams передбачена можливість вибирати інформацію з журналів як основної бази, так і будь-який інший. Вибірка даних з основної бази має ту перевагу, що не потрібно передавати великі обсяги журнальної інформації на віддалені комп'ютери, завантажуючи мережу.
У нові...
