1. Oracle вважається однією з найбільш надійних і популярних систем управління базами даних. Що чекає...
2. Механізм Logical Standby
3. механізм FlashBack
4. Підтримка XML, дуалізм XML / SQL
5. підтримка OLAP
6. Механізм Oracle Streams
7. Удосконалення засобів управління і настройки
8. Інші вдосконалення

Oracle вважається однією з найбільш надійних і популярних систем управління базами даних. Що чекає користувачів в вийшла відносно недавно версії Oracle 9.2?

У СУБД Oracle 9i Release 2 створені нові та вдосконалені існуючі раніше механізми забезпечення надійності і масштабованості (Real Application Cluster, Logical Standby, FlashBack). Включена підтримка XML. У сервер Oracle інтегровані засоби підтримки оперативної аналітичної обробки і видобутку даних. З'явився механізм Oracle Streams. Удосконалено засоби управління, самонастроювання і настройки. Нарешті, передбачена підтримка архітектури IA-64.

Надійність і масштабованість

Real Application Cluster

Досягненням Oracle 9i в області забезпечення високої надійності і масштабованості були кошти підтримки кластеризації. Компонент RAC дозволяє підвищити надійність (при виході з ладу одного з вузлів система продовжує функціонувати), збільшує масштабованість (користувачі однієї бази даних і одного додатка «розмазуються» по всіх вузлах кластера), дозволяє поступово нарощувати потужність системи, не зупиняючи її роботу. При створенні Oracle 9.2 розробники оптимізували потік інформації, переданої між вузлами кластера, використовували механізм бітових масок для управління простором усередині сегмента і т.д.

Для спрощення установки, настройки і супроводу кластера створений компонент RACGUARD2, який в ряді випадків автоматизує адміністрування кластера. Даний компонент дозволяє: встановлювати кластер на декілька вузлів так само, як встановлюється сервер Oracle на один вузол; працювати з кластером як в цілому, так і з його окремими вузлами; об'єднувати вузли в логічні робочі групи, визначаючи, що дана група виконує тільки операції вибірки або працює тільки з конкретними додатками; спрощує перемикання вузлів кластера. Раніше при створенні на кластері бази даних необхідно було розміщувати файли баз даних на так званих «сирих пристроях» (raw device), що вимагало більш високої кваліфікації адміністратора і ускладнювало виконання операцій копіювання / відновлення. В Oracle 9.2 компонент Oracle Cluster File System (кластерна файлова система) дозволяє зберігати і програмне забезпечення Oracle і файли бази даних кластера в звичайній файлової системи; використання «сирих пристроїв» більш не є обов'язковим, хоча вони і прискорюють роботу з файлами бази даних. Велика частина розширень операційної системи, необхідних для роботи кластера, поставляється Oracle і встановлюється у вигляді Oracle Portable Clusterware, що також спрощує створення кластера.

Механізм Logical Standby

На жаль, в більшості випадків вузли кластера знаходяться в межах однієї будівлі, тому при знищенні або тривалому знеструмленні будівлі все вузли RAC виходять з ладу, а тому продовжити роботу системи стає неможливим. На цей випадок у Oracle рекомендують використовувати механізм резервної (standby) бази даних, ідея якого полягає в тому, що копія експлуатаційної бази знаходиться на великій відстані від основного обчислювального центру і постійно «доганяє» основну базу даних.

До сих пір СУБД Oracle дозволяла реалізувати режим Standby фізично: резервна база даних повинна була бути повною копією основний, в ній не можна було створювати додаткові об'єкти, індекси і т.д. Фізичну резервну базу даних можна було тимчасово переводити в режим читання, щоб, скажімо, надрукувати звіти, але на цей час її відновлення припинялося, не можна було оптимізувати операції читання. Причина цього обмеження полягала в тому, що зміни від експлуатаційної бази даних передавалися в резервний центр і там застосовувалися на фізичному рівні (швидка пряма запис в базу). В Oracle 9.2 реалізований механізм Logical Standby. Його відмінність від фізичного полягає в тому, що передаються до резервного центр зміни попередньо перетворюються в оператори SQL, причому процес відновлення не блокує роботу бази даних в режимі читання інших користувачів. Тепер допоміжна база виступає не тільки в ролі резервної бази даних, але на ній можна одночасно з відновленням формувати звіти, вирішувати аналітичні завдання і т.д. Якщо для підвищення ефективності виконання цих завдань треба створити додаткові індекси, матеріалізовані уявлення і т.д., то в логічній резервної базі даних можна зробити і це.

механізм FlashBack

Ряд збоїв в роботі додатків не пов'язаний з надійністю роботи устаткування або програмного забезпечення, а викликаний помилками користувачів. Для боротьби з подібними збоями в СУБД Oracle передбачений механізм FlashBack, що дозволяє користувачеві, зіпсувати свої дані, попросити стан цих даних на момент часу в минулому (до псування), після чого незіпсовані дані можна зберегти, порівняти їх з новим станом даних і т.д . В Oracle 9.1 для цього треба було спочатку виконати процедуру, що переводять весь сеанс користувача в минуле, потім отримати старе стан даних, а потім знову повернути весь сеанс в даний стан. В Oracle 9.2 користувач може вказувати, що дані йому потрібні на якийсь момент часу в минулому прямо в SQL-запиті Select, що значною мірою знижує.

Підтримка XML, дуалізм XML / SQL

Сервер Oracle тепер підтримує не тільки реляционную, об'єктну, багатовимірну модель даних, але і XML. У версії 9.1 великі обсяги XML-даних можна було помістити в вигляді XML-файлів в LOB-полях як єдиний шматок тексту. Інакше вміст XML-файла розбиралася і «розкидати» по реляційним таблицями, а при запиті знову збиралося в файл. У версії 9.2 підтримуються XML-схеми і можна зберігати XML-дані ще й у вигляді власне XML-об'єктів: таблиць з типом XMLType і колонок типу XMLType.

У новій версії реляційні і XML-дані співіснують в одній універсальної моделі. З XML-даними можна працювати за допомогою мов SQL та Java, а з реляційними - через XML-інтерфейси, наприклад, через XPath. Оскільки з SQL можна працювати з XML-даними і їх частинами, то тепер легко побудувати, наприклад, звичайний індекс з реквізиту, що міститься в XML-файлах і швидко знаходити потрібні файли. Можна побудувати реляционное уявлення (View), колонками якого будуть реквізити XML-файлів і далі працювати з цією виставою звичайними «реляційними» засобами. Припустимо, що в деякому додатку запит на товари приходить від замовника у вигляді повідомлень, що містять XML-текст. Можна написати запит, одночасно працює з реляційними даними, чергами повідомлень, XML-даними, просторовими даними, контекстом ( Мал. 1 ).

І навпаки, створивши над реляційними або об'єктними таблицями бази даних уявлення XMLType View, можна працювати з цими даними через XML-інтерфейс. В Oracle 9.2 підтримуються стандарти доступу SQLX, Xpath, DOM, JavaBeans і JNDI.

підтримка OLAP

Реляційна модель зручна для представлення даних в інформаційно-керуючих системах, однак для аналітичних систем більш підходить багатовимірна модель, де дані представлені в вигляді багатовимірних кубів, які можна легко обертати, отримувати зрізи, агрегувати інформацію і т. Д. Для створення OLAP-додатків в Oracle раніше використовувався програмний продукт Express Server - СУБД з багатовимірної моделлю. Дані з оперативних реляційних систем доводилося перевантажувати або підкачувати в Express Server, який не забезпечував такого ж рівня надійності, масштабування, захисту, як реляційний сервер Oracle. Тому в версію 9.2 інтегрована можливість і функціональність Express Server. Тепер сервер Oracle 9i підтримує і багатовимірну модель даних, що дозволяє користувачеві проектувати багатовимірні куби і вирішувати, як вони будуть зберігатися в Oracle 9i - в реляційних таблицях або в так званих аналітичних просторах (LOB-поля). Забезпечується можливість перенесення даних з бази Express Server в Oracle 9i. Реалізовано весь набір функцій, раніше властивий Express, причому розробникам Oracle вдалося домогтися того, що швидкість виконання цих функцій була не нижче, ніж у Express Server. Крім того, метадані та дані зберігаються тепер в єдиній базі даних Oracle, а для роботи з багатовимірними кубами використовуються JavaBeans, що входять до складу інструментарію Oracle JDeveloper.

Алгоритми видобутку даних (data mining), реалізовані раніше програмним продуктом Darvin, тепер теж вбудовані в сервер Oracle 9i сервер. Розробники можуть будувати різні моделі залежності даних, а потім використовувати ці моделі для отримання рекомендацій, причому і дані, і моделі зберігаються в базі даних Oracle.

Механізм Oracle Streams

У СУБД Oracle існує багато різних варіантів передачі даних і повідомлень про події між різними серверами баз даних:

• в разі реплікації захоплюються і передаються зміни даних і виклики віддалених процедур;
• в разі роботи з чергами повідомлень (Advanced Queuing) передається інформація про появу повідомлень і самі повідомлення;
• в разі резервування бази даних передаються і застосовуються до резервної базі заархівовані журнальні файли або їх елементи;
• в разі завантаження даних в сховище даних або Operating Data Store передаються завантажуються дані.

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

Oracle Streams складається з трьох елементів: захоплення подій і даних (capture); складування їх у єдиний упорядкований за часом інформаційний потік в єдиному форматі (stage); транспортування і застосування змін до цільових баз даних (apply). Захоплення даних відбувається автоматично з журнальних файлів, причому захоплюються тільки ті дані і події, які необхідні для виконання конкретних замовлених дій. Захоплені дані і події перетворюються в єдиний універсальний формат зберігання і поміщаються в область зберігання. При перенесенні в цю область дані можуть перетворюватися, модифікуватися і т.д. Крім того, існує програмний інтерфейс, що дозволяє програмам завантаження даних, призначеним для користувача додатків або програмами, які працюють з чужими СУБД, поміщати дані в область зберігання. Для цього досить викликати відповідну процедуру і передати їй дані, а вона вже перетворює їх в потрібний формат, структурує відповідно до правил Oracle Streams і покладе в область зберігання. Далі потоки змін йдуть за вказаними маршрутами (через кілька серверів) і ті вузли, які підписані на ці зміни, беруть їх з потоку і застосовують до своїх баз даних, реалізуючи реплікацію або отриманню повідомлень, відновлення резервної бази даних. Оскільки захоплення змін виконується з журналів, знижується навантаження на вихідну базу і не потрібно прямого доступу і права на нього. Завдяки Oracle Streams можна реалізувати обмін неточними копіями і підмножинами об'єктів (вони перетворюються при передачі). Вихідна і цільові бази даних можуть мати різні версії і працювати на різних платформах.

Удосконалення засобів управління і настройки

З кожною новою версією сервера Oracle відбувається вдосконалення засобів управління і настройки СУБД, зосереджених в компоненті Oracle Enterprise Manager (OEM). Крім того, все більше проблем з налаштування вирішується автоматично або за допомогою програм-«порадників» (Wizard). Версія 9.2 не стала винятком.

Багато ресурси СУБД взаємозалежні, наприклад, щоб прискорити роботу сервера, доводиться виділяти більше оперативної пам'яті, а щоб зменшити час відновлення бази даних доводиться жертвувати швидкодією і т.д. Для зменшення цих «жертв» у версії 9.1 в OEM з'явилися «порадники», що показували діаграми залежності ресурсів для буферного кешу і для UNDO-області. Дивлячись на ці діаграми, адміністратор міг зрозуміти, як треба збільшити / зменшити розмір області, і що це дає з точки зору ефективності використання ресурсів. У версії 9.2 додані аналогічні засоби для оптимізації розміру розділяється області пам'яті (Shared Pool), області виконання SQL-операторів і мінімального часу відновлення після збою (Mean Time To Recovery). Тепер адміністратор зможе зрозуміти, наскільки зросте інтенсивність введення / виведення і знизиться швидкість роботи системи при конкретному завданні мінімально допустимого часу відновлення бази даних. Крім того, ці діаграми дозволяють проводити аналіз типу «що буде, якщо», моделюючи ситуацію заздалегідь.

Сервер Oracle тепер збирає інформацію про інтенсивність використання об'єктів бази даних. Діаграми типу Top Object (наприклад, Top SQL) в OEM дозволять побачити, які таблиці, індекси, секції використовувалися найбільш інтенсивно або були предметом «суперечки» за ресурси. Аналіз цієї інформації дозволить збільшити продуктивність системи.

Останнім часом в більшості компаній використовуються RAID-масиви. Тому дуже часто було складно зрозуміти, на якому фізичному пристрої реально розміщений файл бази даних Oracle. Тому в OEM з'явилася можливість перегляду топології введення / виведення - відображення зв'язку між файлами Oracle і логічними і фізичними пристроями зберігання.

Інші вдосконалення

СУБД Oracle 9i Release 2 буде працювати на комп'ютерах на платформі Itanium з 64-розрядними варіантами операційних систем Linux, HP-UX та Windows.

У версії 9.2 реалізована підтримка Java 1.3.1 і Unicode 3.1, розвивається синтаксис мов програмування Java і PL / SQL, підтримується скролліруемий курсор для програм на Сі і Сі ++. У новій версії реалізовані процедури прискорення модернізації додатків: швидке завантаження коду PL / SQL; перейменування колонок і обмежень цілісності; відстеження повторного завантаження незміненого коду PL / SQL і т.д. Розвивається механізм List Partitioning; з'явилася можливість використовувати змішаний Range / List Partitioning, а також задати для List Partitioning секцію за замовчуванням, куди будуть потрапляти всі записи зі значеннями, що не присутніми в списку List Partitioning.

Марк Рівкін ( [email protected] ) - керівник групи консультантів по серверним технологіям компанії Oracle (Москва).