Інформатика Сибіру

1. RAC
2. RAT
3. Active Data Guard
4. Total Recall
5. In Memory Database Cache
6. Automatic Storage Management
7. Порівняння Oracle Database 10g-11g і Microsoft SQL Server 2005-2008
8. Порівняння Oracle Database 10g-11g і IBM DB2 UDB 8-9
9. Порівняння Oracle Database 10g-11g і MySQL 4-5

Ключові переваги СУБД Oracle 11g:

Oracle - лідер серед постачальників вбудованих СУБД

Провідна аналітична фірма IDC в ​​своєму огляді «Постачальники вбудованих СУБД в 2007» назвала компанію Oracle провідним постачальником з часткою ринку в 26,3%. IDC визначає вбудовані СУБД як ті, які продані незалежним постачальникам програмного або апаратного забезпечення і потім використовуються як компоненти всередині більших програмних або апаратних продуктів, що розробляються компанією-партнером.

Ці технології є унікальними, реалізованими тільки в СУБД Oracle.

RAC

Технологія Real Application Cluster, що з'явилася в 9-й версії СУБД Oracle, дозволяє об'єднувати сервера, які обслуговують СУБД в одну <велику базу даних>, що дозволяє досягти двох ключових цілей:

1. Підвищення продуктивності системи в цілому шляхом додавання в кластер нового обладнання, без заміни обладнання на більш потужне. Продуктивність системи підвищується пропорційно потужності підключеного вузла. Наслідком є ​​збереження інвестицій в обладнання, часто досить суттєвих.
2. Підвищення відмовостійкості СУБД: при виході з ладу або плановому відключенні одного з серверів, що входять в кластер, СУБД повністю зберігає свою працездатність.

Схожі технології реалізовані в Microsoft SQL Server 2008, але є одна істотна відмінність: Microsoft Application Cluster дозволяє підвищити відмовостійкість системи в цілому, але без впливу на продуктивність.

Таким чином, використання RAC дозволяє значно підвищити продуктивність системи, яка дійшла до свого <фізичного стелі>, зі збереженням коштів, витрачених на це обладнання, і підвищити відмовостійкість системи. Як наслідок - надійність і економія.

RAT

Технологія Real Application Testing дозволяє значно знизити витрати на проведення планових змін в конфігурації існуючого програмного або апаратного забезпечення.

Суть технології RAT полягає у відтворенні навантаження на тестовій базі даних в точній відповідності з навантаженням на робочому сервері.

Active Data Guard

Ця технологія дозволяє створити резервний сервер основної бази даних із застосуванням всіх змін, зроблених на основному сервері. Виходить система, де працюють як мінімум два сервера: основний і резервний. У разі виходу з ладу або планової зупинки основного сервера в роботу автоматично вступає резервний сервер, і всі користувачі автоматично перемикаються і продовжують роботу на резервному сервері. Технологія проста в реалізації та налагодженню і не вимагає великих витрат на розгортання і обладнання. Фізично резервний сервер може знаходитися в іншому приміщенні, будівлі або навіть місті. Все, що потрібно, - це звичайне мережеве з'єднання між двома серверами.

Можна використовувати кілька резервних серверів для одного робочого сервера.

Які переваги надає використання цієї технології?

• По-перше, очевидне - надійність. Живучість і відмовостійкість бази даних підвищується на порядок.
• По-друге, розвантаження робочого сервера від резервного копіювання, яке можна виконувати на standby (резервному) сервері, і розвантаження від звітів та інших операцій <тільки на читання>, які також можна виконувати на резервному сервері.
• По-третє, планове виключення резервного сервера, наприклад, для оновлень, не зачепить роботу користувачів.

Схожі технології реалізовані і в DB2 і в MS SQL Server, але Oracle Data Guard вигідно відрізняється простотою реалізації і можливістю використовувати резервний сервер в роботі і резервне копіювання, а також підтримкою різних режимів синхронізації основного і резервного сервера: синхронний, асинхронний, відкладений.

Total Recall

Суттю технології Total Recall є можливість розвантаження бази даних від інформації застарілої, але яку необхідно зберігати за вимогами бізнесу або контролюючих органів із збереженням звичайного доступу до цієї інформації.

Використання Total Recall дозволяє розвантажити таблиці бази даних від накопиченої і рідко використовується інформації. Але зберігається можливість виконати звичайний SQL запит і отримати таку інформацію на будь-який момент в минулому, тобто не потрібно вносити якісь зміни в існуючу програму, що працює з базою. Крім цього, Total Recall забезпечує незмінність історичної інформації і захист від її підробки.

Схожих або подібну технологію в інших СУБД поки не реалізовано.

In Memory Database Cache

Унікальна технологія In Memory Database Cache реалізована на базі існуючої бази даних Oracle TimesTen in memory database. Ця СУБД за рахунок ряду застосовуваних унікальних рішень дозволяє збільшити швидкість обробки транзакцій і видачі запитів більш ніж на порядок (тобто в 10 разів), ніж звичайна СУБД Oracle Database. Ця СУБД орієнтована на зберігання і обробку даних тільки в оперативній пам'яті сервера.

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

Automatic Storage Management

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

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

Аналогічних рішень в інших СУБД поки не запропоновано. Разом з тим, важко заперечувати вигоди по продуктивності і спрощення (а значить підвищенню надійності) адміністрування СУБД, що використовує ASM.

На сьогоднішній день існують як пропрієтарні, так вільно використовуються системи управління базами даних, наприклад, такі як:

• IBM DB2 UDB
• Microsoft SQL Server
• MySQL
• PostgreeDB
• FireBird

Кожна система має свої особливості, переваги і недоліки і свою ціну.

СУБД Oracle є найстарішою СУБД, перша версія з'явилася в 1979 році. З тих пір Oracle розвивався, ставав швидше, надійніше і зручніше для розробника і користувача. Фактично, конкуруючі СУБД повторюють той шлях, який пройшов у своєму розвитку Oracle, і реалізують у себе технології, реалізовані в Oracle Database з річним і більше відставанням і з різним успіхом. Як вже було зазначено, на сьогоднішній день Oracle володіє як мінімум 4-ма унікальними технологіями, що забезпечують конкурентну перевагу цій СУБД. Про те, що Oracle Database є визнаним лідером в цій галузі виробництва ПО, свідчить той факт, що за підсумками 2007 року Oracle Database належить 47% світового ринку систем управління базами даних.

Якими ж саме перевагами забезпечений цей факт?

Деякі з технологій, реалізованих в Oracle Database, мають аналоги в інших СУБД, наприклад, MS SQL Server, але практично у всіх порівняннях аналогій, Oracle надає більш широкий і зручний функціонал в даній області.

Порівняння Oracle Database 10g-11g і Microsoft SQL Server 2005-2008

версійність режим

Суть цієї технології полягає в забезпеченні узгодженого читання даних. Тобто, уявімо ситуацію: о 10:00 користувач А починає читання даних з таблиці. О 10:05 він прочитає тільки половину даних, які зберігаються в таблиці. О 10:03 користувач В змінює дані цієї таблиці від середини і до кінця. Які дані повинен отримати користувач А, коли він дійде до кінця таблиці? Очевидно, що він повинен отримати ту картину, яка була на момент початку роботи його запиту, тобто без урахування змін, які вніс користувач В. Це необхідно для захисту транзакцій від неузгоджених змін даних, які могли бути викликані іншою, конкурентної, транзакцією, і забезпечує ізоляцію транзакцій. Версійність режим з'явився вперше в версії SQL Server 2005 і практично повністю копіює реалізацію в Oracle, яка з'явилася 83-му році в 3-й версії. Але є одна суттєва відмінність: в MS SQL Server версії рядків зберігаються в tempdb, в той час як в Oracle Database - в окремій структурі сегментів відкоту (в Oracle для окремих транзакцій можна створювати окремі сегменти відкату). Tempdb часто стає головним болем адміністратора MS SQL Server і без версійності, проблеми i / o в tempdb на msdn присвячена не одна нота, тому що там крім тимчасових таблиць і табличних змінних зберігаються сортування і курсори. Додавання в tempdb ще і версій рядків робить і без того перевантажений tempdb вузьким місцем в системі.

Наступне важлива відмінність в тому, що сегменти відкату Oracle Database захищені від безрозмірного зростання і місце простору відкоту використовується циклічно (розмір і їх кількість може здаватися адміністратором). При неправильному розмірі сегментів дуже довга транзакція може отримати помилку ORA-01555 snapshot too old, в результаті чого відкотиться лише одна транзакція, в той час як в MS SQL Server зростання tempdb не обмежений, в результаті одна <невдала> транзакція може просто переповнити tempdb і зупинити роботу всіх користувачів (є job, яким можна якось спробувати зреагувати). В Oracle Database, на відміну від MS SQL Server, зберігаються не версії рядків, а блоки даних, що дозволяє накладати версійність універсально на будь-які об'єкти, плюс оптимізувати операції введення-виведення. Наприклад, при необхідності робити клон блоку в пам'яті, який вже позначений на скидання (на жорсткий диск), і не чекати, поки блок дочекається своєї черги і виявиться на диску.

Версійність механізм дозволяє в Oracle Database робити ретроспективні (flashback) запити і стежити за станом таблиць в минулому, чого немає в SQL Server.

Розмір блоку

Блок бази даних - це найменша одиниця інформації, яку СУБД читає або записує на жорсткий диск або в оперативну пам'ять. Наприклад, щоб прочитати одну рядок з таблиці, яка займає 200 байт, потрібно прочитати з пам'яті або жорсткого диска блок цілком, розмір якого становить, наприклад, 8000 байт і потім витягти з прочитаного блоку потрібний рядок. Очевидно, що в цьому випадку 7800 байт були прочитані даремно. Зворотна ситуація, коли потрібно прочитати всі рядки таблиці, СУБД буде змушена прочитати тим більше блоків, чим більше рядків і більше розмір одного рядка. Вигідно було б прочитати 1 блок розміром, наприклад, 32 кілобайт, ніж читати 4 блоки розміром по 8 кілобайт. Однією з пріоритетних завдань по налаштуванню продуктивності є мінімізація кількості логічних читань (прочитаних блоків), і в Oracle Database адміністратор має безліч механізмів для вирішення цього завдання.

Крім того, в Oracle Database реалізований механізм управління заповненням простору блоку (pct_free, pct_used), що дозволяє ефективно налаштовувати СУБД для вирішення того чи іншого завдання.

У SQL Server розмір блоку (page size) дорівнює 8 кілобайт і не може бути змінений, що сильно обмежує можливість настройки системи, особливо DSS систем (сховища даних). В Oracle Database розмір блоку задається під час створення бази даних, і, більш того, для кожного табличного простору може бути заданий свій розмір блоку, наприклад, для табличних просторів з маленькими, часто мінливими таблицями - менший розмір, для табличних просторів з великими, рідко змінюються таблицями, що містять великий обсяг даних - більший розмір, що істотно може вплинути на продуктивність системи в цілому.

індекси

В Oracle Database підтримуються різні типи індексів, які не реалізовані в MS SQL Server, наприклад: B-tree cluster indexes, Hash cluster indexes, Reverse key indexes, Bitmap indexes, Bitmap join indexes. Кожен з типів індексів може забезпечити істотний приріст продуктивності в тій чи іншій ситуації.

Тип індексу

Oracle Database

MS SQL Server

B-tree

Так

Так

Function-based

Так

Так

Bitmap

Так

немає

Reverse

Так

немає

Використання Bitmap index дозволяє значно прискорити вибір по полях з низькою селективністю, тобто невеликою кількістю розрізняються значень в поле. Використання такого типу індексу - один із шляхів вирішення проблеми продуктивності в системах сховищ даних.

Використання Reverse index дозволяє зменшити конкуренцію за блоки БД при вставці в поле монотонно наростаючих значень: наприклад, номерів документів або унікального ключа. Це ще один інструмент адміністратора бази даних по підвищенню продуктивності системи без збільшення потужності обладнання.

Indexed views та Оracle materialized views

В Oracle Database, починаючи з 9-ї версії реалізований механізм матеріалізованих уявлень, який є одним з ключових моментів, що забезпечують функціонування сховищ даних, OLAP і DataMining. Суть цієї технології полягає в зберіганні результатів складних і дуже складних SQL запитів, які формують будь-якої звіт, або частина звіту у вигляді спеціальних таблиць - матеріалізованих уявлень. Це дозволяє не витрачати час кожен раз при виконанні таких запитів на вибірку та аналіз даних, а вибирати готові результати їх матеріалізованого уявлення, що дуже істотно дозволяє прискорити роботу звітних систем і систем пошуку даних. В MS SQL Server аналогічна технологія з'явилася тільки з версії 2005 і має довгий список обмежень на побудову матеріалізованих уявлень, так, наприклад уявлення не повинно містити наступного списку операторів: ANY, NOT ANY, OPENROWSET, OPENQUERY, arithmetic on imprecise (float, real) values , OPENXML, COMPUTE, COMPUTE BY, ORDER BY, CONVERT producing an imprecise result, OUTER join, COUNT (*) reference to a base table with a disabled clustered index, GROUP BY ALL reference to a table or function in a different database, Derived table (subquery in FROM list) reference to another view, DISTINCT, ROWSET function, EXISTS, NOT EXISTS, self-join expressions on aggregate results (eg SUM (x) + SUM (x)), STDEV, STDEVP, VAR, VARP, AVG, full-text predicates (CONTAINS, FREETEXT, CONTAINSTABLE, FREETEXTT ABLE), Subquery, imprecise constants (eg 2.34e5), SUM on nullable expressions, inline or table-valued functions, table hints (eg NOLOCK), MIN, MAX, text, ntext, image, filestream, or XML columns, non- deterministic expressions, UNION. Як бачите, список більш ніж представницький. В Oracle Database обмежень істотно менше. Крім того, традиційно, в Oracle є і розширення цієї технології: автоматична перезапис SQL запитів, якщо існує відповідне матеріалізоване уявлення, яких немає в інших СУБД. Це розширення дозволяє працювати з матеріалізовані уявленнями без модифікації вихідного коду програми, яка працює з цією базою даних. Важко переоцінити значимість цієї можливості для адміністраторів бази даних і кінцевих користувачів.

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

Список істотних відмінностей на рівні функціонування бази даних можна продовжувати ще довго, наприклад можливість використання і зберігання готових планів виконання SQL запитів і т.п. Звичайно, ці відмінності затребувані не завжди, і для того, щоб правильно скористатися перевагами Oracle Database потрібна певна кваліфікація. Але в критичних ситуаціях і для підвищення продуктивності бази даних в кожному конкретному випадку ці переваги можуть стати і фактично стають незаперечною конкурентною перевагою, що забезпечує приріст продуктивності не вирішенням <в лоб> - закупівлею більш потужного, а значить і більш дорого обладнання, а шляхом тонкої настройки СУБД для кожного конкретного випадку. Oracle залишає своєму замовнику вибір: або інтелектуальна настройка і самонастройка бази даних, або перехід на більш потужне обладнання або створення кластера серверів. Конкуруючі СУБД, незважаючи на красивий і зручний інтерфейс адміністратора бази даних, фактично не пропонують адекватних засобів настройки СУБД і залишають єдиний шлях підвищення продуктивності для всіх випадків: підвищення потужності обладнання.

Навіщо витрачати гроші на нове обладнання, якщо є можливість <вичавити> максимум з існуючого?

Також Oracle Database залишається однією з найбільш зручних для розробки СУБД.

Например, в Oracle Database давно існує потужній Внутрішній Процедурний мову: PL / SQL, Який дозволяє розробляті Тригер, збережені процедури І ФУНКЦІЇ будь-якої складності. Ключовими особливостями є наявність блоків try / catch (безпечне виконання коди), яке з'явилося тільки в 2005-й версії MS SQL Server, наявність пакетів (програмних структур, які об'єднують типи, змінні, функції і процедури в одну підпрограму), наявність необмеженої рекурсії ( MS SQL Server вкладеність рекурсії обмежена 32 рівнями).

Суттєвою особливістю Oracle Database, не реалізованою в MS SQL Server, є наявність перевірки взаємозв'язку різних об'єктів бази даних. Так, наприклад, при модифікації таблиці в базі даних Oracle (зміна типу поля, видалення поля і т.п.), процедури, тригери і функції, в яких були звернення до цієї таблиці, будуть позначені як інвалідні і не будуть виконуватися без втручання адміністратора . Це дозволяє виключити виконання явно помилкових дій в процедурах (наприклад, звернення до неіснуючого полю) і функціях. В MS SQL Server процедура буде виконуватися, поки не буде виконано виклик до вже не існуючого полю в таблиці, після чого процедура аварійно завершить свою роботу.

Також в Oracle PL / SQL є підтримка об'єктно-орієнтованих типів, підтримка масивів і вкладених таблиць.

В Oracle Database, на відміну від MS SQL Server давно є підтримка всіх видів тригерів: <до>, <після>, <замість> виконання. В MS SQL Server 2005 немає типу <до> (на підключення користувача до бази).

В MS SQL Server 2005 діалект оновився: з'явився оператор WITH і аналітичні функції. В Oracle Database аналогічний функціонал з'явився ще в 8-й версії, аналітичні функції різноманітніші, крім цього в Oracle Database підтримуються оператори MERGE INTO, model та регулярні вирази в SQL. Використання регулярних виразів в різних частинах SQL запиту з'явилося з 10-ї версії Oracle Database і є істотною підмогою розробнику при програмуванні аналітичних SQL запитів.

Процедури і функції, написані на PL / SQL, можна компілювати в нативну для операційної системи бібліотеку, наприклад, DLL. Це дозволяє працювати такої функції, як частини СУБД Oracle Database, написаної на С ++, без етапу інтерпретації та розбору, що дозволяє значно прискорити роботу такої процедури.

В Oracle Database підтримуються автономні транзакції в PL / SQL блоках, а також виконання SQL запитів <з тексту>, так, як це робиться в додатку на с ++, наприклад.

на сайті www.oracle.com давно знаходяться у вільному доступі компоненти ODP.NET, які дозволяють зручно і ефективно працювати з СУБД Oracle з середовища MS Visual Studio. Для інших засобів розробки (Borland Delphi, C ++ Builder і інших) реалізовано безліч компонент і інструментів доступу і роботи з Oracle Database, як безкоштовних, так і комерційних.

продуктивність

Продуктивність, поряд з надійністю, - основний критерій вибору Oracle Database як системи управління базами даних. Існують синтетичні тести продуктивності, такі, наприклад, як TPC ( www.tpc.org ). У тесті TPC-С, який перевірять продуктивність СУБД в OLTP системі, Oracle Database займає одну з лідируючих позицій.

На синтетичних тестах і в реальній роботі дуже часто люблять показувати результати тестування MySQL або MS SQL Server, в яких при невеликому обсязі даних та спеціалізованої навантаженні продуктивність цих СУБД значно перевершує продуктивність Oracle Database або, наприклад, IBM DB2 UDB, тобто продуктів, які вважаються СУБД <промислового рівня>. Це означає, що ці СУБД здатні обробляти фактично необмежений обсяг даних і число працюючих користувачів. Звичайно, в самих в цих словах уже закладена <інформаційна міна>, оскільки неможливо осягнути неосяжне. Під словами <необмежений> слід розуміти, що саме ці дві СУБД є лідерами по збереженому обсягом даних і працюючим користувачам, при цьому зберігаючи весь свій різнобічний функціонал. Крім того, якщо уважно подивитися на синтетичні тести, то можна помітити той факт, що продуктивність Oracle Database практично не змінюється, а то і збільшується при зростанні оброблюваного обсягу даних. Саме це властивість відрізняє промислову систему від настільної або системи робочих груп. Проводячи аналогії в автомобільній техніці, можна сказати, що нікому в голову не прийде порівнювати швидкісні характеристики легкового автомобіля і вантажівки. Порожній легковий автомобіль здатний їхати зі швидкістю 160 км / год, а порожній вантажівка - 80 км / ч. Якщо на легковий автомобіль навантажити 200 кг вантажу, він буде їхати зі швидкістю 120 км / год, а вантажний - 80. Якщо навантажити 600 кг вантажу, то легковий буде їхати зі швидкістю 60 км / с, а вантажний 80 км / год. І, якщо навантажити тонну вантажу, то швидкість руху легкового автомобіля дорівнюватиме 0 км / год, а вантажного - як і раніше 80. У цьому - суть промислового сервера баз даних: стійкість до навантаження. Втім, це не заважає СУБД Oracle лідирувати в тестах і ставити світові рекорди продуктивності.

масштабованість

На відміну від MS SQL Server, Oracle Database працює на більшості відомих платформ і операційних систем: Windows (в тому числі не серверні версії), Unix, Linux, MacOS. Це суттєва перевага Oracle Database. Перевага полягає не тільки в тому, що зараз Oracle залишає замовнику вибір операційної системи та апаратної платформи, але і в тому, що в корпорації існує досвід і культура розробки саме кроссплатформенних систем, отже, при появі нової операційної системи, більш потужною і ефективною, можна бути впевненим, що під цю операційну систему або платформу з'явиться версія Oracle Database.

У разі, якщо СУБД базується тільки на одній операційній системі, то замовник повністю залежить не тільки від виробника власне СУБД, але і від виробника операційної системи. Залежність ця тим більше посилюється, якщо виробник і СУБД і ОС - один і той же.

вартість обслуговування

Існують різні дослідження на цю тему. Наприклад, в дослідженнях, опублікованих на сайті Microsoft, як двічі два доводиться, що обслуговування SQL Server коштує набагато дешевше і вимагає менше зусиль з боку адміністратора. На сайті Oracle опубліковані Проте солідні і змістовні дослідження , В яких точно також незаперечно доводиться факт нижчою вартістю обслуговування саме Oracle Database. Причому обидва дослідження проводяться незалежними компаніями. Виходячи з нашого особистого досвіду, можна сказати, що адміністрування SQL Server здійснюється з дійсно зручною і логічно-простий середовища SQL Server Management Studio. В Oracle Database також існує зручна і проста Виконавча всіх адміністративних дій: Enterprise manager. Починаючи з 10-ї версії, EM має web-інтерфейс. Слід зазначити, що з Oracle EM можна управляти не тільки одиничним екземпляром бази даних, але і кластером і мережею GRID-серверів.

У 10-й, і в 11-й версії Oracle Database поліпшені і доповнені функції самоадміністрірованія і самодіагностики сервера. У 10-й версії з'явилася функції автоматичного збору статистики, аналізу та видачі рекомендацій. Відстеження різних показників, з видачею повідомлення при досягненні порогових або критичних величин.

Аналізатор SQL запитів дозволяє вибрати і налаштовувати найбільш <важкі> SQL запити, причому передбачений варіант, в якому адміністратор просто вибирає проблемний SQL запит, переглядає і застосовує рекомендації SQL Tuning Advisor, все це відбувається в консолі EM. В MS SQL Server виконання аналогічного завдання виконується ручним способом, на порядок довше, ніж в Oracle Database, за винятком налаштування індексів.

Використання з'явилася в 10-й версії технології Flashback table дозволяє значно спростити відновлення після призначених для користувача помилок. Більше не потрібно відновлення з резервної копії, досить вибрати віддалений об'єкт і відновити його з <кошика>. Слід зазначити, що в MS SQL Server також можливе виконання аналогічної операції, але вимагає значно більше часу: потрібне відновлення з резервної копії, вибір точки відновлення і накат втрачених транзакцій вручну. Теж саме стосується і відновлення після помилкової транзакції. В Oracle Database це робиться як через консоль EM, так і вручну, SQL операторами, причому потрібно просто вибрати момент в минулому, на який потрібно відновлення. В MS SQL Server відновлення також проводиться з резервної копії з подальшим ручним накатом журналів.

Таким чином, Oracle Database надає користувачеві три варіанти:

1. повна самодіагностика і самонастройка, яка вдосконалюється від версії до версії, узагальнюючи і базуючись на досвіді тисяч адміністраторів по всьому і світу і математичних моделях;
2. потужну і зручну консоль адміністратора, яка потребує установки будь-якого додатково ПО на комп'ютер адміністратора, і, отже, доступну з будь-якого комп'ютера в мережі, в тому числі по мережі Інтернет, якщо це необхідно;
3. тонкі засоби діагностики і настройки, що залишилися з минулих версій і дозволяють адміністратору в повній мері застосувати свої знання в області налаштування продуктивності.

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

Порівняння Oracle Database 10g-11g і IBM DB2 UDB 8-9

IBM DB2 UDB і Oracle Database мають неофіційний статус баз даних «промислового» рівня. Ці дві СУБД багато в чому схожі, але є й відмінності, що впливають на ефективність і стабільність СУБД. У таблиці наведено деякі відмінності в роботі внутрішніх механізмів цих СУБД.

властівість

Oracle

DB2

Concurrency Model

Multi-version read consistency
Non-Escalating row-level locking

No
Locks escalate

Clustered configurations

Transparent scalability with Real Application Clusters

Rigid data partitioning required with DB2 EEE

Indexing capabilities

Wide variety of indexing schemes

Only B-Tree and dynamic bitmap indexes

Partitioning options

Range, hash, list and composite partitioning
Local and global indexes

Only hash partitioning
Only local indexes

Additional data warehousing capabilities

MERGE
Multi-table INSERT

Not supported
Not supported

Intelligent advisories

Index, Summary, Memory, MTTR

Index advisory only

Self-tuning capabilities

Self-tuning memory, free space, and I / O management

No equivalent or limitedcapabilities

У першому рядку порівнюється механізм блокувань і забезпечення цілісності читання. Більш детально в таблиці:

Oracle9i

DB2

Multi-version read consistency

Not available

No read locks

Requires read locks to avoid dirty reads

No dirty reads

Dirty reads if not using read locks

Non-escalating row-level locking

Locks escalate

Readers do not block writers

Readers block writers

Writers do not block readers

Writers block readers

No deadlocks under load

Deadlocks can be a serious problem under load

У другому рядку - робота в кластері, Oracle RAC і IBM EEE:

Oracle RAC

DB2 EEE

No two-phase commit required

Requires two-phase commit

Data cached in multiple nodes

IPC for every cross-partition access

Single probe for data

Multiple partition probes

Uniform load distribution

Load skew likely

Більш детально з підтримуваним типах індексів:

Тип індексу

Oracle

DB2

Reverse Key Indexes

так

Function-based Indexes

так

Partial

Dynamic Bitmap Indexes

так

так

Stored Compressed Bitmap Indexes

так

Bitmap Join Indexes

так

Index-organized Tables

так

В Oracle Database більше підтримуваних варіантів партіціонірованія:

вид партіціонірованія

Oracle

DB2

Range partitioning

так

List partitioning

так

Hash partitioning

так

так

Composite partitioning

так

Local index

так

так

Global partitioned index

так

Global non-partitioned index

так

Порівняння Oracle Database 10g-11g і MySQL 4-5

Зрозуміло, і ми віддаємо собі в цьому звіт, порівнювати MySQL і Oracle Database - це все одно, що порівнювати велосипед і вантажівка Камаз. За своїм призначенням та функціонального наповнення ці СУБД непорівнянні. Якщо коротко, основна відмінність цих СУБД в тому, що MySQL призначений для вирішення вузького кола завдань, зважаючи на свою функціональну неповноцінність, в той час як Oracle Database не має обмежень в застосуванні - від простої бази даних, яка обслуговує сайт або невелику компанію, до величезних і потужних сховищ даних з вбудованими рішеннями завдань класу OLAP або DataMinig, що зберігають будь-які дані: від простих таблиць до документів, відео-файлів, геоінформаційних даних і т. п.

Тому зупинимося лише на кількох, найбільш часто обговорюваних, моментах.

1. MySQL - безкоштовне рішення. На сьогоднішній день це дійсно так. Крім того, у Oracle також є безкоштовна редакція СУБД Oracle Database. Це редакція eXpress Edition (XE). Вона доступна для скачування на сайті www.oracle.com , Абсолютна безкоштовна для використання в бізнесі і має версії під Windows і Linux. Замовникам, які вибирають MySQL саме з огляду на його безкоштовності, слід подумати про те, що рано чи пізно функціонал MySQL перестане задовольняти зростаючі потреби бізнесу, і тоді доведеться переходити на одну з комерційних СУБД, що пропонують більш повний функціонал. Процес міграції на іншу СУБД - це завжди питання часу і грошей. Чи не краще зараз використовувати безкоштовну редакцію Oracle Database, щоб в майбутньому максимально спростити і полегшити процес переходу на більш потужну редакцію цієї ж СУБД?
2. MySQL - найпродуктивніша СУБД. Дійсно, якщо поглянути на тести на www.tpc.org , Наприклад, на синтетичний read-only benchmark з доступом даних по первинному ключу, то ми побачимо, що MySQL займає лідируючі позиції. Доступ по первинному ключу зазвичай дуже швидкий, так що тест показує максимальну пікову продуктивність, яку СУБД може видати. Вся таблиця поміщається в оперативній пам'яті, I / O активність відсутня, результат обмежений лише процесорами. Звичайно, в такому тесті переможцем повинен стати інтерфейс до текстового файлу, але його чомусь не порівнювали, порівняли Oracle і MySQL. Цікаво те, що навіть на такому тесті різниця виявилася незначною. А ось якщо поглянути на інші тести, що вимірюють роботу СУБД в сукупності різних режимів, то картина дещо зміниться. У реальному житті при використанні СУБД в роботі, яка передбачає одночасно різні за характером навантаження на СУБД, продуктивність MySQL залишає бажати кращого. Висока продуктивність MySQL на вузькому колі завдань - прямий наслідок її функціональної простоти. Зворотною стороною такої продуктивності є вузькість застосування цієї СУБД.