Нові можливості Oracle 9i реліз 2 (Oracle 9.2), Інші СУБД, Бази даних, статті

Навесні 2002 року компанія Oracle випустила новий реліз своєї СУБД – Oracle 9i Release 2 (Oracle 9.2). У цьому релізі були виправлені деякі помилки, виявлені в релізі 1, підвищився швидкодію і ефективність роботи СУБД. З’явилося багато нових можливостей, найцікавішими з яких є такі:



Розглянемо їх докладніше.


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


REAL APPLICATION CLUSTERS


Найбільшим досягненням Oracle 9i в галузі забезпечення високої надійності і масштабованості було створення засобів підтримки реальних кластерів – компонента Real Application Cluster (RAC). Нагадаємо, що RAC дозволяє підвищити надійність системи (при виході з ладу одного з вузлів, система продовжує функціонувати), збільшує масштабованість системи (користувачі однієї БД і одного додатка “розмазуються” по всіх вузлах кластера), дозволяє поступово нарощувати потужність системи, не зупиняючи її роботу (підключати “на льоту” нові вузли).


При створенні релізу 2 була значно підвищена ефективність роботи RAC. Розробники не тільки оптимізували роботу опції Real Application Cluster, а й проаналізували вузькі місця сервера, що працює в кластерному режимі. Багато елементів СУБД були переписані за результатами цього аналізу для того, щоб в кластерному режимі Oracle працював більш швидко і надійно. Так, наприклад, був оптимізований потік інформації, переданої між вузлами кластера, використаний механізм бітових масок для управління простором усередині сегмента і т. д.


Для спрощення установки, настройки і супроводу кластера створена компонента RACGUARD2, Яка значно спрощує, а іноді й автоматизує адміністрування кластера, спрощує перемикання вузлів кластера. Раніше при створенні на кластері бази даних необхідно було розміщувати файли БД на так званих “сирих пристроях” (Raw devices). Це ускладнювало адміністрування RAC, вимагало більш високої кваліфікації адміністратора бази даних, ускладнювало виконання операцій копіювання / відновлення БД. У релізі 2 адміністратор БД може використовувати кластерну файлову систему Oracle Cluster File System і зберігати програмне забезпечення Oracle і файли кластерізірованной БД в звичайній файловій системі. Велика частина розширень операційної системи, необхідних для роботи кластера, розроблені безпосередньо в корпорації Oracle. Ці розширення поставляються Oracle і встановлюються у вигляді так званого Oracle Portable Clusterware, що також спрощує створення кластера. З’явилася можливість об’єднувати вузли кластера в логічні робочі групи і пов’язувати додатки з цими робочими групами. Тим самим можна регламентувати, з якими вузлами кластера працюватиме конкретний додаток.


LOGICAL STANDBY


На жаль, зазвичай вузли кластера знаходяться недалеко один від одного, як правило, в одній будівлі. Тому при знищенні або тривалому знеструмленні будівлі RAC не може забезпечити продовження роботи системи, так як всі його вузли виходять з ладу одночасно. На випадок таких катастрофічних збоїв Oracle рекомендує використовувати механізм резервної (standby) БД. Ідея полягає в тому, що копія експлуатаційної БД знаходиться на великому видаленні від основного обчислювального центру і постійно “наздоганяє” основну виробничу БД. Тобто всі зміни основної БД архівуються і передаються в резервний центр, а там автоматично застосовуються до резервної БД. У разі виходу з ладу основний БД, резервна БД переводиться з режиму відновлення в режим експлуатації, і додатки дуже швидко можуть продовжити свою роботу, причому (при певних режимах) без втрати даних.


До недавнього часу Oracle міг підтримувати тільки фізичний standby режим. В цьому випадку резервна БД повинна була бути повною копією основний БД, в ній не можна створювати додаткові об’єкти, індекси і так далі. Фізичну standby-базу можна тимчасово переводити в режим читання, щоб надрукувати, наприклад, звіти, але на цей час її відновлення зупинялося, та й оптимізувати операції читання було не можна. Причина була в тому, що зміни, проведені у виробничій БД, передавалися до резервного центр і там застосовувалися на фізичному рівні (швидка пряма запис в БД).


У релізі 2 Oracle реалізував логічний standby-механізм. Відмінність від фізичного standby полягає в тому, що передаються до резервного центр зміни не застосовуються до standby-базі на фізичному рівні, а попередньо перетворюються Oracle в SQL-оператори, тобто процес відновлення standby-бази не блокує роботу інших користувачів з цієї БД в режимі читання. Тепер ця база виступає не тільки в ролі резервної БД, але на ній можна одночасно з відновленням друкувати звіти, вирішувати аналітичні завдання і так далі. Якщо для підвищення ефективності виконання цих завдань треба створити додаткові індекси, матеріалізовані уявлення та інше, то в логічній standby-базі це зробити можна.


Компонента управління фізичної та логічної standby-базою – DATA GUARD полегшує, а часто і автоматизує створення standby-бази, її адміністрування, конфігурування, переклад standby-бази в режим виробничої БД і навпаки.


FLASHBACK


Ряд збоїв в роботі програм пов’язаний не з надійністю роботи устаткування або програмного забезпечення, а викликаний помилками користувачів. Для боротьби з цими збоями Oracle запропонував механізм FlashBack, Який дозволяє користувачеві, який зіпсував свої дані, запитати стан цих даних на якийсь момент часу в минулому (до їх спотворення або втрати). Після цього можна зберегти незіпсовані дані, порівняти їх з новим станом даних. Проте в релізі 1 для цього треба було спочатку виконати процедуру, що переводить весь сеанс користувача в минуле, потім отримати старе стан даних, а потім повернути весь сеанс в сьогодення.


У релізі 2 користувач може вказувати, що дані йому потрібні на якийсь момент часу в минулому, прямо в SQL-запиті select . Це сильно спрощує роботу і не вимагає перекладу сеансу в минуле і назад.


Підтримка XML в БД і XML / SQL-дуалізм


Другим найбільшим досягненням Oracle є створення XML-бази даних. Тепер сервер Oracle підтримує не тільки реляційну, об’єктну і багатовимірну моделі даних, але і XML. Раніше ми могли зберігати великі обсяги XML-даних в БД двома способами: або вони зберігалися у вигляді XML-файлів в LOB-полях як єдині текстові ділянки, або вміст XML-файла розбиралася, розкидав по реляційних таблиць, а при запиті цього XML-документа знову збиралося у файл.


Тепер Oracle підтримує XML-схеми, що дозволяє зберігати XML-дані ще й у вигляді XML-об’єктів (таблиць з типом XMLType і колонок типу XMLType). При цьому Oracle реалізує нові високоефективні способи зберігання цих даних та засоби швидкого доступу до XML-даними та їх частин. Користувач може використовувати всі переваги Oracle – надійність, швидкодію, масштабованість, захист даних, транзакционную обробку, … і для XML-даних.


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


Запит:


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


Крім зберігання XML-даних у вигляді атрибутів об’єктів, Oracle 9i дозволяє створити XML-репозиторій і зберігати бібліотеки XML-документів. При цьому можна задавати ієрархію папок документів, контролювати версії документів, організувати додатковий контроль доступу до файлів і папок на основі ACL (списків контролю доступу).


Підтримка OLAP і Data Mining в сервері БД


Реляційна модель дуже зручна для представлення даних в інформаційно-керуючих системах. Однак, для аналітичних систем зручніша багатовимірна модель даних, де дані представлені у вигляді багатовимірних кубів, які можна легко обертати, отримувати зрізи, агрегувати інформацію і так далі. Для створення OLAP-систем Oracle раніше використовував продукт Express Server, який був СУБД з багатовимірної моделлю. Дані з оперативних реляційних систем доводилося перевантажувати або підкачувати в Express Server. Express Server не забезпечував такий же рівень надійності, масштабування, захисту, як реляційний сервер Oracle. Тому Oracle почав вбудовувати можливості і функціональність Express Server в звичайний сервер Oracle.


У релізі 2 ці можливості реалізовані повністю. Тепер сервер Oracle 9i підтримує і багатовимірну модель даних. Ви можете проектувати багатовимірні куби і вирішувати, як вони будуть зберігатися в Oracle 9i (В реляційних таблицях або в LOB-полях – workspace). В Oracle 9i реалізований весь набір функцій, властивий раніше Express, а також деякі додаткові функції. Реалізовано ефективніші способи зберігання, а швидкість обробки часто перевищує швидкість Express Server. Крім того, метадані і дані зберігаються в єдиній БД Oracle, використовуючи всі переваги СУБД Oracle 9i (Надійність, захист, масштабованість, єдине управління, єдине копіювання / відновлення і так далі). Для роботи з спроектованими багатовимірними кубами використовуються JavaBeans, що входять до складу Oracle JDeveloper.
Алгоритми Data Mining, реалізовані раніше продуктом Darvin, тепер теж вбудовані в сервер Oracle 9i. Використовуючи API, розробники можуть будувати різні моделі залежності даних, а потім використовувати ці моделі для отримання рекомендацій у своїх додатках. І дані, і моделі зберігаються в БД Oracle. У релізі 2 була додана підтримка таких методів побудови моделі, як дерева рішень та кластеризація, реалізовані функції вибору найкращої моделі, визначення важливості атрибутів.


Oracle Streams


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



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


Oracle Streams складається з трьох елементів:



Захоплення даних відбувається автоматично з журнальних файлів. Захоплюються лише ті дані і події, які необхідні для виконання конкретних замовлених дій. Захоплені дані і події перетворюються в єдиний універсальний формат зберігання і поміщаються в область зберігання (Stage). При приміщенні в цю область вони можуть перетворюватися, модифікуватися і так далі. Крім того, існує API, що дозволяє поміщати дані в область зберігання програмами завантаження даних, користувальницьким додаткам або програмами, що працюють з чужими СУБД.


Далі потоки змін йдуть за вказаними маршрутами (через кілька серверів), і ті вузли, які підписані на ці зміни, беруть їх з потоку і застосовують до своїх БД, реалізуючи реплікацію, або прийом повідомлень, або відновлення standby-бази. Оскільки захоплення змін йде з журналів, знижується навантаження на вихідну БД і не потрібно прямий доступ і права на нього для цієї БД. Завдяки Oracle Streams можна реалізувати обмін неточними копіями і підмножинами об’єктів (вони перетворюються при передачі). Вихідна і цільові СУБД можуть мати різні версії і працювати на різних платформах.


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


З кожною новою версією сервера Oracle удосконалюються засоби управління і настройки СУБД – Oracle Enterprise Manager (OEM). Крім того, все більше і більше проблем з налаштування вирішується автоматично (Самонастройка) або за допомогою програм – порадників (Wizards). Новий реліз Oracle 9i не став винятком. Крім того, OEM релізу 2 підтримує всі нові можливості релізів 1 і 2 Oracle 9i.


Багато ресурси СУБД взаємозалежні. Наприклад, щоб прискорити роботу сервера, доводиться виділяти більше оперативної пам’яті, щоб зменшити час відновлення БД доводиться жертвувати швидкодією. Бажано ці “жертви” знизити і оптимізувати. Для цього в OEM релізу 1 були введені порадники, що показують діаграми залежності ресурсів для буферного кешу і для UNDO-області. Дивлячись на ці діаграми, адміністратор міг швидко зрозуміти, на скільки треба збільшити / зменшити розмір області і що це йому дає з точки зору ефективності використання ресурсів. У релізі 2 додані такі ж кошти для оптимізації розміру розділяється області пам’яті (shared pool), області виконання SQL-операторів (SQL Executive Memory) і мінімального часу відновлення після збою (Mean Time To Recovery). Тепер адміністратор легко зможе зрозуміти, наскільки зросте інтенсивність введення / виводу і знизиться швидкість роботи системи при конкретному завданні мінімально допустимого часу відновлення БД. Крім того, ці діаграми дозволяють проводити аналіз типу “що буде, якщо”, то є моделювати ситуацію заздалегідь.


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


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


Інші можливості


Останнім часом великий інтерес викликають комп’ютери з архітектурою IA64 на базі процесора Itanium. Багато збираються використовувати Oracle на цих комп’ютерах. Версія Oracle 9i реліз 2 буде працювати на Itanium комп’ютерах з 64 розрядної ОС Linux, HP UX і Windows. Зараз доступна версія 9.0 для розробників (Developer Release), а в кінці року з’явиться промисловий реліз Oracle 9i R2 (9.2) для архітектури IA64.


У релізі 2 виконана підтримка Java 1.3.1, Unicode 3.1. Розвиваються мови програмування Java і PL / SQL. Введена підтримка скроліруемого курсора для мов С и С + +. Реалізовано багато змін для прискорення процедур оновлення (upgrade) додатків (швидке завантаження PL / SQL-коду, перейменування стовпців і обмежень цілісності, відстеження повторного завантаження незміненого PL / SQL-коду і так далі). Розвивається List Partitioning. Тепер можна використовувати змішаний Range / List Partitioning і задати для List Partitioning секцію за замовчуванням (default), куди будуть потрапляти всі записи зі значеннями, відсутніми в списку List Partitioning. Реалізована можливість паралельного виконання DML-операцій для таблиць, нерозділених на секції.


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


Висновок


Oracle 9i реліз 2 вже кілька місяців успішно використовується користувачами Oracle. Більшість нових можливостей, описаних в цій статті, є унікальними і не тільки не реалізовані в основних конкурентів Oracle (IBM, Microsoft), але навіть і не плануються в майбутніх версіях їх СУБД. Це відноситься і до RAC, і до ефективної підтримки XML, і до Oracle Streams і … Таким чином, можна констатувати, що з випуском Oracle 9i реліз 2 компанія Oracle забезпечила ще більш високий рівень надійності, швидкодії, захищеності та ефективності роботи користувальницьких додатків.


Oracle 9.2 є фінальним релізом Oracle 9i. Тому ми рекомендуємо всім користувачам СУБД Oracle поступово переходити на використання цього релізу. Зараз компанія Oracle працює над створенням Oracle10i і нової версії Enterprise Manager (OEM 4), Яка дозволить моніторити і налаштовувати не окремі компоненти, а всю прикладну систему.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*