Варіанти постачання Sybase eaServer. Системи управління базами даних та підтримки інформаційних сховищ (IBM DB2)

Система управління базами даних IBM DB2 починає свій розвиток у далеких 70-х роках і зараз займає міцне становище на ринку корпоративних СУБД, відповідаючи високим вимогам до продуктивності, надійності, безпеки та масштабованості.

Ігор Булатенко, фахівець з інформаційної безпеки, Positive Technologies

Система управління базами даних IBM DB2 починає свій розвиток у далеких 70-х роках і зараз займає міцне становище на ринку корпоративних СУБД, відповідаючи високим вимогам до продуктивності, надійності, безпеки та масштабованості. У приватному секторі система DB2 не набула широкого поширення, незважаючи на наявність безкоштовної версії IBM DB2 Express. Можливо, саме через це в Інтернеті не так багато статей щодо настроювання та використання DB2.

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

Однак непідготовленому користувачеві складно з нуля розібратися в цьому різноманітті, тому деякі важливі аспекти будуть розглянуті в даній статті.

Точка входу

Точка входу в DB2 виглядає так: СУБД -> екземпляр (instance), який може бути прив'язаний до певного порту -> ім'я конкретної бази даних. Налаштування безпеки можуть бути змінені як у конкретному екземплярі, так і у конкретній базі даних.

Аутентифікація

Аутентифікація - це першочерговий механізм безпеки, який застосовується при спробі з'єднатися з сервером DB2. При аутентифікації перевіряється коректність облікових даних, що надаються. Головною особливістюу DB2 є те, що автентифікація користувачів провадиться тільки зовнішніми плагінами. Внутрішніх користувачів, на відміну Oracle або MS SQL Server, тут немає. Навіть функція створення користувача, яка є в IBM Data Studio, насправді не створює користувача, а призначає вказаному користувачеві привілей на з'єднання з базою даних.

Існує кілька варіантів аутентифікації, потрібний варіант регулюється параметром AUTHENTICATION менеджер бази даних. Значення даного параметра впливає на те, де буде здійснюватись автентифікація клієнтів (на стороні сервера або на стороні клієнта) і чи будуть дані передаватися у зашифрованому вигляді (значення із закінченням _ENCRYPT). Ці параметри, що підтримуються, доступні за наступною адресою:

Переглянути конфігурацію менеджера бази даних можна за допомогою запиту до таблиці sysibmadm.dbmcfg, але для цього потрібно мати доступ до будь-якої бази даних, що не завжди можливо. Якщо у вас є локальний доступ до сервера, можна відкрити процесор командного рядка(db2 або db2.exe у Windows), з'єднатися з екземпляром і виконати такі команди:

DB2 => attach to db2inst1
db2 => get database manager configuration

Стандартним значенням для AUTHENTICATION є SERVER. Перевірка правильності наданих облікових даних користувача проводиться на стороні сервера засобами операційної системиАле всі дані при цьому передаються у відкритому вигляді і можуть бути перехоплені зловмисником.

Розглянемо, як виглядає перехоплена інформація в Wireshark.

Надіслані від клієнта логін та пароль видно в пакеті під час перегляду EBCDIC.

При зміні типу автентифікації на SERVER_ENCRYPT логін та пароль будуть передаватися вже у зашифрованому вигляді та перевірятись на стороні сервера.

Значення змінюється так:

DB2 => attach to db2inst1
db2 => update database manager configuration using authentication server_encrypt
db2 => db2stop force
db2 => db2start

Пакет аутентифікації буде виглядати так:

Проте текст запитів і результат все одно передаватиметься у відкритому вигляді.

Пакет із запитом в Wireshark:

Пакет з відповіддю у Wireshark:

Якщо для параметра AUTHENTICATION налаштовано значення DATA_ENCRYPT, шифруються облікові дані користувача, а також інформація, що передається між клієнтом та сервером.

Значення змінюється аналогічно до розглянутого вище прикладу:

DB2 => attach to db2inst1
db2 => update database manager configuration using authentication data_encrypt
db2 => db2stop force
db2 => db2start

Після цього дані також будуть шифруватися:

Також потрібно звернути увагу на тип аутентифікації CLIENT. При цьому типі аутентифікації вважається, що між клієнтом і сервером існує захищений канал зв'язку, і якщо користувач отримав доступ до клієнта, він може отримати доступ до сервера без перевірки правильності облікових даних. Тобто автентифікація як така відбувається за клієнта, перевірки за сервера не проводиться. Навіть якщо користувач, який з'єднується з сервером, не має права на доступ, він все одно отримує всі привілеї, призначені групі PUBLIC. Тому не варто використовувати такий тип аутентифікації, це надасть зловмисникам можливість без особливих зусиль отримати доступ до сервера.

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

У разі успішної аутентифікації ID користувача співвідноситься з ідентифікатором DB2. Зазвичай ідентифікатор збігається з ім'ям користувача, але використовується символи верхнього регістру.

Авторизація

Повноваження рівня конкретного екземпляра прописуються зміни менеджера БД. Йдеться про такі повноваження:

• SYSADM (повноваження адміністратора системи);
• SYSCTRL (повноваження управління системою);
• SYSMAINT (повноваження обслуговування системи);
• SYSMON (повноваження на моніторинг системи).

Задаються ці привілеї за допомогою вказівки тієї групи, в яку входитиме користувач. Для цього використовуються наступні параметри файлу dbmcfg (відповідно до зазначених вище повноважень):

Легко отримати список користувачів, які входять до групи, засобами DB2 не можна, потрібно робити це в самій операційній системі або аналізувати, до яких груп входить конкретний користувач (запит див. на вкладці "корисні запити").

При налаштуванні DB2 необхідно перевірити список користувачів, яким призначено повноваження SYSADM. Це повноваження дозволяє керувати всіма об'єктами бази даних.

Повноваження конкретної бази можна переглянути у поданні SYSCAT.DBAUTH. Зверніть увагу на привілей CONNECTAUTH, який визначає, буде у користувача доступ до БД чи ні, та привілей NOFENCEAUTH, який відповідає за створення неізольованих (not fenced) процедур та функцій. Такі процедури виконуються в адресному просторі бази даних і, у разі помилки, можуть порушити цілісність бази даних та таблиць у ній.

Привілеї

Привілеї підпрограм (функцій, процедур та методів) можна переглянути у поданні SYSCAT.ROUTINEAUTH. Тут все не зовсім тривіально, залежно від полів SPECIFICNAME та TYPENAME привілеї можуть бути видані на всі підпрограми заданої схеми.

Користувачі, групи, ролі

Також, у DB2 існує вбудована роль PUBLIC. Користувачеві бази даних немає необхідності надавати роль PUBLIC: відкликати у користувача роль PUBLIC неможливо. Коли привілей надається ролі PUBLIC, фактично відбувається надання привілею всім користувачам бази даних. Не слід видавати будь-які повноваження бази даних ролі PUBLIC. Привілеї на таблиці та уявлення варто видавати з крайньою обережністю, тільки перегляд і без можливості перепризначення (WITH GRANT OPTION).

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

Для пошуку подібних груп використовується аналогічний запит, але при цьому в запиті вказується, що дані про PUBLIC не потрібно виводити:

LBAC

Автоматичні засоби сканування

Корисні запити та команди

Отримати налаштування менеджера бази даних:

або

Змінити параметр менеджера бази даних:

Після цього необхідний перезапуск екземпляра:

Отримати налаштування бази даних:

або

Список користувачів операційної системи:

Список груп операційної системи:

Вивести поточне ім'я бази даних:

Ввести поточне ім'я користувача:

Отримати список груп, до яких входить користувач:

Список усіх встановлених СУБД:

Список усіх примірників у СУБД:

Обмежити кількість рядків, що виводяться:

СУБД IBM DB2 – результат майже 30-х дослідно-конструкторських та дослідницьких робіт фірми IBM. Останню на сьогодні версію даної СУБД (6.х) відрізняє один з найбільш продуманих наборів засобів управління та оптимізації та механізм БД, що допускає нарощування від портативного ПК з Windows 95 до цілого кластеру великих ЕОМ S/390, що працюють під керуванням OS/390.

Пакет DB2 випускається у двох редакціях: DB2 Workgroup та DB2 Enterprise Edition. У даній СУБД реалізовані всі відомі за попередніми версіями DB2 новаторські технології механізму БД, такі як розпаралелювання обробки запиту, повний набір засобів тиражування, зведені таблиці запитів для підвищення продуктивності БД, можливості об'єктно-орієнтованого конструювання баз даних та засоби мови Java. До цього слід додати, що система DB2 оснащена порожнім набором мультимедіа-розширень, що дозволяють зберігати текст, звук та відео-фрагменти, зображення та географічні дані та маніпулювати ними. Можна казати, що з можливостям масштабування розроблена фахівцями IBM технологія кластеризації баз даних немає аналогів. Ці розширення істотно полегшують процес розробки додатків для Web, а також програм, що містять фотозображення та об'ємні текстові звіти. Система DB2 цілком конкурентоспроможна і в якості платформи для розробки додатків, оскільки існує засіб Stored Procedure Builder - автоматично перетворює оператор SQL у відповідний клас Java і включає його в структуру бази даних. У версії DB2 6.1 значно покращено функціональну сумісність з іншими СУБД: пакет дозволяє використовувати розроблену Microsoft специфікацію OLE DB, новий стандарт доступу до баз даних. Кошти адміністративного управління СУБД DB2, які в нової версіїпереписані на Java і можуть бути отримані з Web, заслуговують на найвищу оцінку.

Основними недоліками даної СУБД є відносна складність адміністрування та відсутність (поки що) реалізацій під популярні серверні ОС, наприклад LINUX.

У цій СУБД завдяки Index Smart-Guide можна здійснювати налаштування, формуючи оптимальні індекси для заданої кількості звернень, що характеризує типове навантаження на БД. DB2- єдиний пакет дозволяє генерувати зведені таблиці, що значно ефективність роботи СУБД як сховищ даних. Зведена таблиця - це тимчасова робоча область, використовувана базою даних для зберігання відповідей на запити, що часто надходять. Ну що ж, можна сказати, що оснащена новими функціональними можливостями, а також засобами розпаралелювання та можливостями вибору практично будь-якого типу з'єднання та індексів (крім хіба що растрових індексів), модель DB2 6.1 перетворюється на найдешевшу з високопродуктивних систем. Кошти адміністративного управління цієї СУБД цілком відповідають рівню розв'язуваних завдань, крім того, вона надає виключно широкі можливості для роботи з мультимедіа-даними та програмування (чого явно бракує системі Microsoft SQL Server).

СУБД від Informix

Останнім часом намітився перехід від реляційних СУБД до об'єктно-орієнтованих (що очевидно простежується з прикладу Oracle). Informix також за даною концепцією анонсувала нове рішення СУБД Centaur, що базується на реляційній БД Informix Dynamic Server 7.3 і об'єктно-реляційній БД Informix Universal Data Option і поєднує в собі високу швидкодію Dynamic Server при роботі з даними з універсальністю та мультимедіа функціями Univers. Ця реалізація призначена для розробки інтернет-систем. Імовірно дана СУБД матиме гнучке середовище розробки, що має нарощуваність, що відповідає характерним для Інтернету інтенсивним навантаженням, і засобами роботи з новими типами даних, які з розвитком Web стали використовуватися повсюдно. Реалізовані в новій системі засоби Java дозволять розробникам створювати цією мовою збережені процедури, програми та компоненти DataBlades, які в Informix називають замовними розширеннями бази даних.

З погляду клієнтів Inforix, це стане великим кроком уперед, оскільки до цього часу при роботі з DataBlades вони могли користуватися тільки мовою Сі та SPL, внутрішньою мовою фірми Informix для написання процедур, що зберігаються. Крім того, пакет Centaur буде оснащений вбудованими засобами обробки об'єктів ActiveX. Це дозволить, наприклад, створювати збережені процедури БД мовою Visual Basic; правда, для цього потрібно, щоб пакет Centaur виконувався серед Windows NT.

Centaur буде надбудовою Informix Dynamic Server і працювати з традиційним для цього пакета форматом БД, так що в розпорядженні користувачів залишаться всі колишні функції, а модернізація системи до рівня нової версії не буде пов'язана з великими труднощами. Крім того, у пакеті Centaur будуть збережені всі можливості конструювання та програмування, завдяки яким система Informix Universal Server визнана визначним технічним досягненням. Нова система буде оснащена засобами об'єктно-орієнтованого конструювання баз даних, створення спеціалізованих таблиць та програм індексування; до її складу увійде дозволить користувачам вбудовувати у запити власні функції та не покладатися виключно на стандартні засоби SQL.

Висновки.

Розглянувши основні характеристики архітектур побудови АІС, серверних операційних систем та СУБД надалі як архітектуру АІС ми виберемо архітектуру інтернет/інтранет, як серверну ОС Linux, як СУБД Oracle 8i. У зведеній таблиці представлені порівняльні характеристики двох найбільш поширених на сьогодні рішень на базі Microsoft SQL Server 7.0 (NT) і Oracle8i (UNIX, Linux).

DB2(В російській мові вимовляється «Дібі два», також поширена калька з англійської «Дібіт») - сімейство програмних продуктівв галузі управління інформацією компанії IBM.

Найчастіше, посилаючись на DB2, мають на увазі реляційну систему управління базами даних DB2 Universal Database (DB2 UDB), яку розробляє і випускає компанія IBM.

Іноді зустрічається написання "DB/2", але таке написання неправильне: в системі позначень IBM число в знаменнику дробу означає платформу і "/2" означає продукт для операційної системи OS/2 (або серії комп'ютерів PS/2). Наприклад, версія DB2 для OS/2 позначалася "DB2/2".

Реалізації

В даний час СУБД DB2 представлена ​​версіями на наступних платформах:

• DB2 for Linux, UNIX та Windows v9для платформ AIX, HP-UX, Linux, Solaris, Windows та бета-версія для платформ Mac OS X
• DB2 for z/OS v9для платформ z/OS та OS/390
• DB2 Server for VSE & VM v7для платформ z/VM та z/VSE
• DB2 for iдля платформи IBM i (вбудована у систему на апаратно-програмному рівні)

У минулому випускалися версії сервера СУБД DB2 для OS/2, UnixWare, PTX.

Клієнти СУБД DB2, крім перерахованих платформ, випускаються або випускалися в різних версіяхтакож для SINIX, IRIX, класичної Mac OS і для MS-DOS, а також в мобільної версії DB2 Everyplaceдля Windows CE, Palm OS, Symbian OS, Neutrino та віртуальної машини Java.

В даний час, крім комерційних продуктів сімейства, IBM розповсюджує також безкоштовний дистрибутив DB2 Express-Cдля платформ Linux (x86, x86-64, Power), Windows (x86, x86-64), Solaris (x86-64), Mac OS X (x86-64 beta). Безкоштовна версіямає обмеження на використання для роботи СУБД не більше одного двоядерного процесора та 2 Гбайт оперативної пам'яті(загальна кількість процесорів і п'яти в системі може бути будь-яким, але ресурси понад зазначені обмеження не будуть використовуватися СУБД).

Історія

DB2 має довгу історію і, як дехто вважає, стала першою СУБД, що використовує SQL .

З 1975 по 1982 прототип DB2 розроблявся в IBM під назвою System Relational, або System R . Мова SQL вперше була реалізована саме в IBM System R, але ця система мала дослідницький характер, а комерційний продукт, що включає SQL, першою випустила компанія Oracle у 1979 році.

СУБД DB2 отримала свою назву в 1982 році, коли був випущений перший комерційний реліз під назвою SQL/DS, а потім реліз для MVS під назвою DB2. Довгий час поруч із «DB2» використовувався варіант «Database 2», також є торговою маркою IBM. Очевидно, мало на увазі, що це друга флагманська СКБД IBM після старої ієрархічної СКБД IMS.

Розвиток DB2 сягає корінням на початок 1970-х, коли доктор Е. Ф. Кодд, який працював на IBM, розробив теорію реляційних баз даних і в червні 1970 опублікував модель маніпуляції даними. Для втілення цієї моделі він розробив мову реляційних базданих і назвав його Alpha. IBM віддала перевагу передати подальшу розробку групі програмістів, непідконтрольній доктору Кодду. Порушивши деякі принципи реляційної моделі, Вони реалізували її як «структуровану англійську мову запитів», скорочено SEQUEL. Оскільки SEQUEL було вже зареєстрованою торговою маркою, назву скоротили до SQL – «структуровану мову запитів», і такою вона залишилася й досі.

Таким чином, історично СУБД DB2 виникла з продуктів DB2 для MVS (нащадком якого є DB2 for z/OS) та спорідненого до нього SQL/DS для VM (нащадок - DB2 Server for VSE & VM). Надалі іншим колективом розробників в IBM був реалізований сервер OS/2 EE Database Manager, який згодом еволюціонував у DB2 v2 для OS/2, AIX і потім Windows, а потім у DB2 UDB (його нащадок - DB2 for Linux, UNIX and Windows). Ще одним колективом була виконана інтеграція архітектури DB2 із вбудованою базою даних AS/400 (нащадок - DB2 for i). IBM поступово рухається шляхом інтеграції всіх цих гілок.

Особливості

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

Завдяки пріоритету IBM у розвитку реляційної теорії та позиціям фірми в комп'ютерній галузі, діалект DB2 SQL значно впливає на стандарти SQL ANSI / ISO .

Збережені процедури в DB2 не дуже широко застосовуються, при цьому традиційно для написання процедур, що зберігаються, використовуються звичайні мови програмування високого рівня (Сі, Java, PL/I, Кобол і т.д.), це дозволяє програмісту легко оформляти один і той же код або як частина програми, або як процедуру, що зберігається, залежно від того, на клієнті або на сервері його доцільніше виконувати. В даний час у DB2 також реалізовано процедурне розширення SQL для збережених процедур відповідно до стандарту ANSI SQL/PSM.

Оптимізатор DB2 широко використовує статистику розподілу даних у таблицях (якщо процес її збору був виконаний адміністратором бази даних), тому один і той же запит мовою SQL може бути відтрансльований в різні плани виконання в залежності від статистичних характеристикданих, що він обробляє.

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

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

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

DB2 є єдиною реляційною СУБД загального призначення, що має реалізації на апаратно-програмному рівні (система IBM i; також в обладнанні мейнфреймів IBM System z реалізуються засоби підтримки DB2).

Сучасні версії DB2 забезпечують розширену підтримку використання даних у форматі XML, зокрема операції з окремими елементами документів XML.

Обробка помилок

Корисною особливістю SQL-сервера DB2 є можливість обробки помилок. З цією метою використовується структура SQLCA (англ. SQL Communications Area- область зв'язку SQL), що повертає інформацію про помилку прикладної програми після кожного виконання SQL-вираження.

Поля структури SQLCODE та їх значення

Основна, але не завжди корисна діагностика помилки міститься в полі SQLCODE(Тип даних - ціле число) всередині SQLCA блоку. Вона може приймати такі значення:

• 0 означає успішне виконання.
• Позитивне число означає успішне виконання з одним або більше попереджень. Наприклад, +100 означає, що не знайдено стовпчиків.
• Негативне число означає невдачу з помилкою. Наприклад, −911 означає виявлений інтервал очікування блокування (або мертве блокування), що запускає послідовний відкат.

SQLERRM(Тип даних - рядок з 71 символу). Містить текстовий рядок з описом помилки, якщо поле SQLCODE менше нуля.

SQLERRD(Тип даних - масив , 6 цілих чисел). Описує результат виконання останнього оператора SQL:

• 1 елемент – внутрішня інформація;
• 2 елемент - містить згенероване сервером значення поля типу SERIAL для оператора INSERT, або додатковий кодпомилки;
• 3 елемент - дорівнює кількості оброблених записів;
• 4 елемент – приблизна вартість виконання даного оператора;
• 5 елемент - усунення помилки в текстовому записі оператора SQL;
• 6 елемент – внутрішня інформація.

Примітки

Посилання

• Сторінка програми на сайті IBM
• DB2 на developerWorks - статті та тренінги про DB2
• PlanetDB2 - блоги про DB2

Література

• Дейт До.Посібник з реляційної СУБД DB2. - М: Фінанси та статистика, 1988. - 320 с. - ISBN 5-279-00063-9
• Зікопулос П. К., Бакларц Дж., де Рус Д., Мельник Р. Б. DB2 версії 8: офіційний посібник = DB2 Version 8: The Official Guide. – М.: КУДИЦЬ-ОБРАЗ, 2004. – 400 с. - ISBN 5-9579-0031-1
• Смірнов С. Н.Працюємо з IBM DB2: Навчальний посібник. - М: Геліос, 2001. - 304 с. - ISBN 5-85438-007-2 (рекомендовано УМО вузів у галузі інформаційної безпеки як навчальний посібник за спеціальностями «Комплексне забезпечення інформаційної безпеки автоматизованих систем» та «Комп'ютерна безпека»)
• Сьюзен Віссер, Білл Вонг.Освій самостійно DB2 Universal Database за 21 день = Sams Teach Yourself DB2 Universal Database in 21 Days. - 2-ге вид. - М: Вільямс, 2004. - 528 с. - ISBN 0-672-32582-9
• Hook J., Harbus R., Snow D. Universal Guide для DB2 для Windows NT®. - New Jersey: Prentice Hall PTR, 1999. - P. 504. - ISBN 0-13-099723-4

Wikimedia Foundation. 2010 .

Дивитись що таке "IBM DB2" в інших словниках:

IBM DB2- Developer(s) IBM Initial release 1983 (1983) ... Wikipedia

IBM DB2- DB2 is ein kommerzielles relationales Datenbank Management System (RDBMS) der Firma IBM, використовується в 1970-1970г. Inhaltsverzeichnis 1 Eigenschaften 1.1… … Deutsch Wikipedia

IBM DB2- Développeur IBM Dernière version … Wikipédia en Français

IBM DB2- DB2 CommonStore Archiving software виробляється за допомогою IBM для управління електронною поштою або SAP ERP data. Part of the IBM Information Management portfolio which builds upon the DB2 database platform. DB2 CommonStore is one of several products which are… … Wikipedia

Огляд основних понять та загальний опис архітектури СУБД IBM DB2 для платформ Linux, Unix та Windows

Серія контенту:

Цей контент є частиною # із серії # статей: Огляд DB2 LUW

http://www.?q=%D0%9E%D0%B1%D0%B7%D0%BE%D1%80+DB2+LUW&co=ru&lo=ru&ibm-submit.x=11&ibm-submit.y=13&sn= mh&lang=ua&cc=UA&en=utf&hpp=

Слідкуйте за виходом нових статей цієї серії.

Вихідні матеріали та контактна інформація

Окрема подяка Марку Барінштейну за приділений час на вичитування матеріалу статей, увагу до деталей та цінні зауваження.

Основна частина матеріалу статей є вільною інтерпретацією офіційної документації DB2. Подана інформація була реструктурована та переформульована для стисненого та водночас максимально зрозумілого викладу. Посилання на використані джерела завжди представлені в тексті статей і в розділі «Ресурси».

В рамках серії статей планується оглядово висвітлити такі питання:

1. (Стаття, яку ви зараз читаєте);
2. (установка, налаштування, діагностика, резервне копіювання та відновлення);
3. розширені процедури адміністрування (перенесення інформації, оптимізація продуктивності, управління пріоритетами виконання);
4. засоби для побудови аналітичних сховищ даних;
5. технології in-memory аналітики – DB2 BLU;
6. масивно-паралельна аналітична обробка даних із DB2 DPF (Database Partitioning Feature);
7. розподілені бази даних (відмовостійкі конфігурації, реплікація даних та федеративний доступ до даних);
8. Можливості кластерної конфігурації DB2 pureScale для забезпечення відмовостійкості та масштабованості.

Статті серії публікуватимуться у міру підготовки відповідних матеріалів.

Сімейство продуктів DB2

Ім'я "DB2" використовується компанією IBM для цілого сімейства продуктів, що відрізняються один від одного як складом програмно-апаратних платформ, на яких вони застосовуються, так і функціоналом, архітектурою та технологічними особливостями. Ці відмінності обумовлені тісною інтеграцією більшості продуктів сімейства DB2 з можливостями операційних систем, у яких вони функціонують, а також специфікою цих операційних систем.

До сімейства продуктів DB2 на даний момент входять:

• DB2 for Linux, Unix та Windows, або DB2 LUW - СУБД для систем з операційною системою Linux (RedHat, SuSE, Ubuntu), UNIX (AIX, HP-UX, Solaris) та Microsoft Windows, якій і присвячена ця стаття та інші статті цієї серії;
• DB2 for z/OS- СУБД для операційної системи z/OS, що використовується на мейнфреймах IBM System z;
• DB2 Server for VSE & VM- СУБД для операційних z/VM та z/VSE, що використовуються на мейнфреймах IBM System z;
• DB2 for i- СУБД для операційної системи System i, що застосовується на платформі IBM Power.

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

Термінологія, що використовується в документації на різні СУБД сімейства DB2, не є уніфікованою, причому ті самі терміни для різних варіантів DB2 можуть використовуватися в різних значеннях: наприклад, терміни «база даних» та «табличний простір» мають різні значення для DB2 LUW і DB2 for z/OS, що з архітектурними відмінностями між цими видами СУБД.

Таким чином, при роботі з інформаційними ресурсами, присвяченими DB2, необхідно чітко розрізняти, про який із продуктів сімейства йдеться, для виключення плутанини та можливих помилок.

Застарілі функції DB2 LUW

У тому чи іншому вигляді продукт DB2 LUW присутній на ринку з 1989 року (рік виходу операційної системи OS/2 1.10 Extended Edition, що включала до свого складу компонент Database Manager - тобто реляційну СУБД, що стала основою для DB2 LUW).

У результаті тривалого розвитку товару деякі спочатку розроблені функцій були переосмислені і замінені іншою реалізацією, або цілком виключені з товару через відсутність у яких потреби. Тому при роботі з матеріалами, підготовленими для старих версій DB2 (наприклад, для версії 9.7), необхідно враховувати, що частина описаних у цих матеріалах функцій може бути замінена у новіших версіях DB2 (наприклад, 10.5 і 11.1). Детальна інформація про виключені та замінені функції наведена в .

Найбільш помітні для адміністраторів та розробників зміни включають:

• заміну застарілих графічних інструментів керування «Центр керування», «Центр завдань» та ряду інших на функції пакету IBM Data Studio, що безкоштовно розповсюджується, а також на функції засобів, що входять до безкоштовної редакції продукту IBM Data Server Manager;
• припинення використання сервера адміністрування DB2 (DB2 Administration Server, DAS), який був необхідний для роботи застарілих інструментів адміністрування;
• заміну інструментів DB2 Governor та Query Patroller для керування робочими навантаженнями на функціонал DB2 Workload Manager (DB2 WLM).

Мета підготовки даної серії статей

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

При цьому автором не ставиться завдання підготовки оглядового опису всіх продуктів сімейства DB2 (див. врізку «Родина продуктів DB2»), натомість планується зосередити зусилля на варіанті DB2 для операційних систем Linux, Unix та Windows – тобто. на продукті DB2 LUW.

Читачам, зацікавленим у практичному посібнику з початку роботи з DB2, рекомендую звернутися до вільно розповсюджуваної книги « », перекладеної російською мовою. У цій книзі наведено безліч прикладів типових операцій з програмним забезпеченням DB2, що дозволяє легко приступити до роботи як з описаною в книзі версією DB2 9.7, так і з новими версіями DB2 (10.5 і 11.1). При роботі з актуальними версіями програмного забезпечення DB2 слід враховувати, що частина функціоналу версії 9.7 оголошена застарілою і не підтримується в нових версіях продукту (див. врізку "Застарілі функції DB2 LUW").

Функціональні можливості DB2 LUW

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

Для забезпечення конкурентного доступу до даних з боку паралельно виконуваних додатків у DB2 використовується транзакційний механізм, заснований на застосуванні блокувань та ведення журналу транзакцій, що забезпечує надання стандартних гарантій ACID (Атомарність, Узгодженість, Ізольованість, Довговічність). Цей механізм пройшов довгий шлях еволюції для забезпечення максимальної продуктивності, надійності та мінімізації затримок виконання додатків.

У DB2 реалізована підтримка всіх поширених промислових стандартів доступу додатків до даних, включаючи стандартну мову запитів SQL, інтерфейси ODBC та JDBC, роботу з типовими текстовими табличними форматами тощо. Крім того, DB2 включає в себе розвинені можливості зберігання та роботи з напівструктурованими даними у форматах XML, JSON/BSON. Для розробки процедур, що зберігаються в DB2 реалізована підтримка безлічі процедурних мов, включаючи:

• стандартна для DB2 мова SQL PL,
• використовується в СУБД корпорації Oracle мова SQL/PL,
• можливість розробки «зовнішніх» процедур, що зберігаються на мовах Java, C, C++ та COBOL.

Відмінними рисами DB2 є:

• масштабованість, обмежена лише доступними обчислювальними ресурсами, та максимально економічне використання обчислювальних ресурсів;
• потужні вбудовані засоби розмежування та контролю доступу, що надає можливості гранулярного обмеження доступу до інформації в розрізі об'єктів (таблиць, уявлень), а також модель мандатного розмежування доступу, що реалізує;
• розвинена інтегрована система резервного копіювання та відновлення даних;
• наявність повного набору технологій для побудови «класичних» аналітичних сховищ даних (розподіл таблиць на розділи, матеріалізовані уявлення, оптимізації кешування даних та сканування таблиць та індексів, «внутрішній» паралелізм виконання складних запитів тощо);
• підтримка побудови конфігурацій масивно-паралельної аналітичної обробки даних (MPP) з безлічі серверів, з'єднаних через комунікаційну мережу, на базі DB2 Database Partitioning Feature (DB2 DPF);
• максимальна стійкість до відмов та практично лінійне масштабування кластерних конфігурацій DB2 pureScale, із зберіганням даних на загальних дисках;
• технологія DB2 BLU, що реалізує підтримку сучасної in-memory "поколонкової" аналітики без використання ручної оптимізації структури баз даних.

Для полегшення міграції програм з інших типів СУБД (насамперед Oracle Database) в DB2 передбачені розвинені засоби забезпечення сумісності, включаючи підтримку необхідних типів даних, збережених процедур, і стандартних системних уявлень.

Існує кілька редакцій продукту DB2 LUW, що об'єднуються єдиним набором базових функцій і відрізняються один від одного наявністю обмежень щодо обчислювальних ресурсів і підтримки розширеного функціоналу. Для ознайомлення з продуктом, вивчення і навіть розгортання невеликих виробничих конфігурацій можна використовувати редакцію DB2 Express-C, доступну безкоштовно. Функціональні можливості та ресурсні обмеження різноманітних редакцій DB2 LUW детально викладені у статті «».

Структура сервера баз даних

Під сервером баз даних DB2 розуміється комп'ютер, де встановлено програмне забезпечення сервера DB2 (DB2 engine) і який забезпечує надання сервісів з управління структурованою інформацією.

Доступ до сервісів DB2 з боку програм забезпечується клієнтським програмним забезпеченням DB2 (IBM Data Server Driver Package), що забезпечує взаємодію з сервером DB2 відповідно до підтримуваних методів підключення додатків (включаючи ODBC, JDBC, OLE DB, ADO, CLI та інші методи). У більшості випадків разом із сервером DB2 встановлюється і необхідне клієнтське програмне забезпечення, що забезпечує можливість підключення до сервера DB2 додатків, які безпосередньо розміщуються на сервері баз даних.

На сервері баз даних DB2 може розміщуватися кілька копій програмного забезпечення DB2, що відрізняються один від одного версіями програмного забезпечення та каталогами інсталяції. Декілька копій програмного забезпечення DB2 можуть розміщуватися на одному сервері незалежно один від одного за умови відсутності конфліктів ресурсів між ними (включаючи достатність обчислювальних ресурсів сервера та відсутність конфліктів за логічні ресурси операційної системи: імена мережі, номери портів, каталоги файлової системи тощо). ).

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

Запуск та зупинення сервісів DB2 виконується лише на рівні екземпляра, тобто. кожен екземпляр DB2 може бути у запущеному чи зупиненому стані. Параметри екземпляра DB2 можуть визначати його обмеження (наприклад, в частині використання оперативної пам'яті). Ресурси екземпляра DB2 використовуються для обслуговування існуючих екземплярів баз даних.

База даних – це сукупність об'єктів, що становлять єдиний інформаційний масив (таблиць, уявлень, індексів тощо). Бази даних є незалежними одиницями і, зазвичай, зазвичай використовують об'єкти разом з іншими базами даних (виняток можуть бути розподілені зміни баз даних, використовують механізми федералізації доступу до даних).

Схематично приклад структури сервера баз даних представлений малюнку.

У багатьох випадках сервер баз даних DB2 містить єдину встановлену копію DB2 з єдиним створеним екземпляром, який обслуговує єдину базу даних. За такої конфігурації всі ресурси сервера баз даних використовуються для функціонування однієї бази даних DB2.

Обслуговування запитів підключених програм на стороні сервера баз даних виконується так званими агентами DB2. Для кожного підключеного додатка в рамках екземпляра DB2 запускається координуючий (основний) агент, який за необхідності може запускати кілька додаткових (допоміжних) агентів. Технічно кожен агент є окремим потіком виконання або (для старих версій DB2) окремим процесом операційної системи, з асоційованими ресурсами, необхідними для його роботи.

Параметри конфігурації DB2

Конфігурація сервера DB2 може бути задана на чотирьох різних рівнях:

• змінні середовища;
• реєстр профілю DB2;
• файл конфігурації менеджера баз даних (DBM CFG);
• Файл конфігурації бази даних (DB CFG).

Змінні середовища задаються лише на рівні операційної системи сервера та засобами операційної системи. Для ОС Windows ці змінні фактично є глобальними для сервера, для ОС сімейств Unix і Linux кожного екземпляра можуть бути встановлені свої специфічні налаштування змінних середовища.

Параметри реєстру профілю DB2 можуть бути задані на рівні операційної системи (глобально) або на рівні екземпляра, при цьому налаштування на рівні екземпляра перевизначають значення, визначені лише на рівні ОС. Перегляд та встановлення параметрів реєстру профілю DB2 виконується за допомогою команди db2set.

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

Багато параметрів є динамічними, тобто внесені зміни відразу набувають чинності; однак є параметри, для зміни яких необхідно зупинити та знову запустити екземпляр. Це можна зробити в командному рядку за допомогою команд db2stop та db2start. Перед зупинкою екземпляра всі програми повинні вимкнутися. Для примусової зупинки екземпляра можна скористатися командою db2stop force.

Файл конфігурації менеджера баз даних включає параметри, що впливають на екземпляр та всі бази даних, що містяться в ньому. Файл конфігурації менеджера бази даних можна переглянути або змінити за допомогою командного рядка (командами GET DBM CFG та UPDATE DBM CFG), а також засобами IBM Data Studio.

Файл конфігурації бази даних включає параметри, що впливають певну базу даних. Файл конфігурації бази даних можна переглянути або змінити за допомогою командного рядка (командами GET DB CFG та UPDATE DB CFG), а також засобами IBM Data Studio.

Детальний опис підтримуваних, а також наведено в офіційній документації DB2.

Організація зберігання даних

Найменшою одиницею зберігання даних у DB2 фізично є сторінка. Допустимі розміри сторінок: 4 Кбайт, 8 Кбайт, 16 Кбайт та 32 Кбайт. Інформація об'єктів бази даних (наприклад, записи таблиць та елементи індексів) розміщуються на сторінках.

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

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

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

Існують такі види табличних просторів:

• звичайні: використовуються для розміщення таблиць та індексів;
• великі: використовуються для розміщення таблиць та індексів, а також даних великих об'єктів (LOB) і даних XML. У сучасних версіях DB2 великі табличні простори використовуються за замовчуванням замість звичайних;
• тимчасові: використовуються для розміщення тимчасової інформації при виконанні запитів (системні тимчасові табличні простори) і тимчасових таблиць, визначених програмами (часові тимчасові табличні простори).

Вигляд табличного простору вказується при його створенні і не може бути змінений інакше як видаленням і повторним створенням табличного простору.

Табличні простори можна класифікувати за типом управління, що встановлюється при створенні табличного простору:

• Табличні простори під управлінням системи (SMS, System Managed Storage) - як контейнери табличного простору використовуються каталоги, для розміщення об'єктів зберігання в каталогах здійснюється створення файлів з даними. Простір не розподіляється заздалегідь, файли збільшуються динамічно. При визначенні контейнери фіксуються на момент створення;
• табличні простори під управлінням бази даних (DMS, Database Managed Storage) - як контейнери табличного простору використовуються попередньо розподілені файли, контейнери можна додавати, видаляти або міняти;
• автоматично керовані табличні простори (automatic storage) – автоматичне визначення типу та розміщення контейнера залежно від виду табличного простору (DMS для звичайних та великих табличних просторів, SMS для тимчасових табличних просторів). Конкретні визначення контейнерів під час створення табличного простору не задаються, необхідні контейнери створюються автоматично. Збільшення наявних і додавання нових контейнерів повністю управляє DB2.

Щоб дозволити застосування автоматичного управління табличними просторами, для початку потрібно створити базу даних з увімкненим автоматичним сховищем (використовується за замовчуванням) і прив'язати до неї набір шляхів зберігання даних.

За замовчуванням DB2 виконує послідовний запис екстентів з «розшаруванням» між контейнерами. Наприклад, якщо є табличний простір з розміром сторінки 4 КБ та розміром екстенту 8 сторінок, і використовується 3 безпосередні контейнери в табличному просторі типу DMS, це означає, що 32 КБ даних (4 КБ x 8 сторінок в екстенті = 32 КБ) буде записано на один диск, перш ніж почнеться запис на наступний.

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

Кожне автоматично кероване табличний простір асоціюються з однією з створених груп зберігання даних, що визначається фізичне розміщення даних, що зберігаються у відповідних табличних просторах. Існує можливість перемістити табличний простір з однієї групи зберігання до іншої за допомогою команди ALTER TABLESPACE … USING STOGROUP … .

Ведення журналу транзакцій

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

Операції DB2, що виконуються, зміни даних фіксуються в транзакційному журналі у вигляді послідовності записів журналу. Для кожної бази даних ведеться власний транзакційний журнал, що є послідовністю файлів на диску. Розмір одиничного файлу визначається параметром LOGFILSIZ, кількість створюваних файлів визначається параметром LOGPRIMARY. При необхідності DB2 може створити додаткові файли журналу, максимальна кількість файлів, що створюються, регулюється параметром LOGSECOND.

Запис інформації у транзакційний журнал ведеться з використанням спеціального буфера в оперативній пам'яті. Скидання вмісту буфера на диск (у файли транзакційного журналу) здійснюється в міру заповнення буфера, а також підтвердження та скасування транзакцій (за командою програми або за фактом позаштатного закриття з'єднання з додатком).

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

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

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

Існує два основних режими роботи з транзакційним журналом DB2: циклічне журналування та архівне журналування. У режимі циклічного журналювання DB2 циклічно використовує створений набір файлів транзакційного журналу. У режимі архівного журналування DB2 додатково копіює файли транзакційного журналу в архів за допомогою методів, визначених параметрами LOGARCHMETH1 та LOGARCHMETH2.

Режим циклічного журналювання забезпечує відновлення цілісності бази даних під час краху сервера СУБД. Резервне копіювання такої бази даних можливе лише після відключення всіх програм (тобто з призупиненням доступу користувачів). Відновлення даних із резервної копіїможливе лише з приведенням бази даних у стан на момент зняття резервної копії.

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

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

Організація кешування даних

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

При виконанні операції читання спочатку проводиться пошук потрібної сторінки з даними буферному пулі. При виявленні необхідної сторінки читання даних виконується з буферного пулу, інакше проводиться завантаження сторінки з диска буферний пул. Передбачено механізм асинхронної передвиборки сторінок у буферний пул у разі виявлення лінійного (передбачуваного) характеру звернень до сторінок. Механізм передвиборки у багатьох випадках дозволяє знизити час очікування операцій зчитування потрібних даних з диска за рахунок виконання читання в асинхронному режимі.

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

Використання оперативної пам'яті

Модель пам'яті DB2 складається з різних областей пам'яті на рівні екземпляра DB2, бази даних, програми та агента.

Детальний опис областей пам'яті DB2 наведено в , нижче представлено короткий описпризначення різних областей.

Перелік основних областей пам'яті DB2 наведено на малюнку нижче (спочатку взятий з ).

Загальна пам'ять, що використовується екземпляром СУБД, включає:

• Monitor Heap – область пам'яті для моніторингу операцій та стану, розмір регулюється параметром MON_HEAP_SZ;
• FCM Buffers – область пам'яті для взаємодії між координуючим агентом та його субагентами, а також для забезпечення внутрішніх взаємодій у багатороздільних базах даних;
• Audit Buffer – область пам'яті, у якій розміщуються записи аудиту перед скиданням до журналу аудиту.

На рівні бази даних прийнято розрізняти:

• глобальну область бази даних, часто звану "Областю продуктивності" ("Performance memory"), що включає різні області кешування та область ведення блокувань;
• область даних додатків, що часто називається «Функціональною областю» («Functional memory») і включає різні робочі області пам'яті агентів, що обслуговують підключення до бази даних.

Глобальна область бази даних складається з таких основних компонентів:

• Buffer pools – буферні пули, тобто. області для кешування даних табличних просторів;
• Lock list – область зберігання інформації про блокування, розмір якої регулюється параметром LOCKLIST;
• Package cache – область кешування планів виконання запитів, розмір регулюється параметром PCKCACHESZ;
• Catalog cache – область для кешування системного каталогу, що включає описи всіх об'єктів бази даних, розмір регулюється параметром CATALOGCACHE_SZ;
• Utility heap – оперативна пам'ять виконання операцій обслуговування бази даних (включаючи операції резервного копіювання і відновлення), розмір регулюється параметром UTIL_HEAP_SZ;
• Database heap – оперативна пам'ять обслуговування операцій бази даних (включаючи буфер транзакційного журналу і кеш для прискорення доступу до системного каталогу, і навіть буфер аудиту лише на рівні бази даних), розмір регулюється параметром DBHEAP.

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

Область даних додатків включає:

• Application Global Memory – спільні області пам'яті, що спільно використовуються при обробці запитів додатків, максимальний обсяг регулюється параметром APPL_MEMORY;
• Agent Private Memory – приватні області пам'яті, які використовуються для функціонування окремих агентів, які обслуговують підключені програми.

Додатково можна виділити області пам'яті для драйвера DB2 на стороні програми. Для локальних додатків (що використовують протокол міжпроцесної взаємодії, а не мережевий доступ для підключення до менеджера баз даних) встановлені параметри DB2 регулюють обсяг оперативної пам'яті, що виділяється (переважно параметр ASLHEAPSZ).

Управління оперативною пам'яттю під час операцій сортування

При виконанні багатьох видів операцій СУБД потрібно здійснити сортування даних, тому управління оперативною пам'яттю, що використовується для сортування, приділяється особлива увага.

У разі неможливості розміщення області сортування повністю в оперативній пам'яті, дані для сортування розміщуються в системному часовому табличному просторі. Продуктивність запитів, які потребують таких об'ємних операцій сортування, може бути значно знижена.

Параметри, що керують виділенням оперативної пам'яті для сортування:

• SORTHEAP – граничний розмір пам'яті для операції сортування;
• SHEAPTHRES – граничний розмір приватної області пам'яті агента, виділеної для операції сортування;
• SHEAPTHRES_SHR – граничний обсяг загальної оперативної пам'яті, яка може бути використана для виконання операцій сортування (сумарно всіма споживачами) у кожний момент часу.

У DB2 підтримується три основні моделі керування пам'яттю сортування:

• Модель загальної області сортування (shared sort) – використовується за замовчуванням, передбачає встановлення параметра SHEAPTHRES значення 0. Виділення оперативної пам'яті для сортування здійснюється з глобальної області бази даних.
• Модель приватної області сортування (private sort) – використовується за ненульового значення параметра SHEAPTHRES і відсутності настроєної загальної пам'яті сортування. Виділення оперативної пам'яті для сортування здійснюється з області даних додатків (точніше, приватних областей, що належать агентам).
• Гібридна модель сортування (hybrid sort) – використовується при ненульовому значенні параметра SHEAPTHRES та наявності налаштованої загальної пам'яті сортування. Операції, що вимагають використання загальної пам'яті сортування, виконуються з виділенням пам'яті у глобальній області бази даних, інші операції сортування виконуються з виділенням пам'яті у приватних областях агентів.

Використання загальної (глобальної) пам'яті для виконання операцій сортування надає низку важливих переваг:

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

Для увімкнення можливості використання спільної пам'яті при виконанні операцій сортування може використовуватися одна з таких установок:

• активована модель загальної області сортування шляхом встановлення параметра SHEAPTHRES значення 0;
• активовано паралелізм виконання операцій шляхом встановлення параметра INTRA_PARALLEL значення YES;
• змінна DB2_WORKLOAD встановлена ​​на значення ANALYTICS;
• активовано функцію DB2 Connection Concentrator (зазвичай використовується при організації доступу до баз даних DB2 for z/OS та DB2 for i, див. опис цієї функції в ).

Автоматичне керування розподілом пам'яті

Наявність великої кількостірізних областей оперативної пам'яті та параметрів, що регулюють їх обсяг, може вимагати значних зусиль для ручного настроювання сервера DB2. Тому, починаючи з версії 9, IBM DB2 підтримує автоматичне управління розподілом оперативної пам'яті між різними областями з використанням менеджера пам'яті, що самоналаштовується (STMM, Self-Tuning Memory Manager).

Якщо функцію самоналаштування увімкнено, STMM динамічно розподіляє доступні ресурси пам'яті між споживачами оперативної пам'яті в базі даних. STMM реагує на зміни параметрів робочого навантаження, регулюючи значення параметрів конфігурування пам'яті та розмір буферних пулів для оптимізації продуктивності. Щоб увімкнути STMM, необхідно встановити для параметра конфігурації бази даних SELF_TUNING_MEM значення ON.

Автоматичне управління розподілом пам'яті ведеться тим областей пам'яті, котрим воно було явно дозволено. При установці значення параметра конфігурації командами UPDATE DBM CFG та UPDATE DB CFG для використання STMM після значення параметра вказується ключове слово AUTOMATIC. Вказане при цьому числове значення параметра використовується як початкове, далі STMM здійснює періодичне коригування значень з урахуванням поточного навантаження, перерозподіляючи оперативну пам'ять між різними споживачами.

Автоматичне керування засобами STMM підтримується для таких параметрів:

• INSTANCE_MEMORY – сумарний обсяг оперативної пам'яті екземпляра DB2;
• DATABASE_MEMORY – глобальні області бази даних;
• DBHEAP – область обслуговування операцій бази даних;
• LOCKLIST - область ведення даних про блокування;
• MAXLOCKS – відсоток заняття пам'яті блокуванням однієї програми для переходу до ескалації блокувань;
• PCKCACHESZ – область кешування планів виконання запитів;
• SHEAPTHRES_SHR – загальна область сортування;
• SORTHEAP – розмір області сортування однієї операції;
• APPL_MEMORY - Область функціональної пам'яті;
• APPLHEAPSZ – граничний обсяг приватної пам'яті, використовуваний одним агентом;
• STMTHEAP – обмеження розмір області, використовуваної компілятором SQL і XQuery запитів (на один запит);
• STAT_HEAP_SZ – максимальний обсяг оперативної пам'яті, що виділяється для побудови статистик утилітою RUNSTATS та виділяється з функціональної області пам'яті.

Види об'єктів баз даних

Цей розділ містить огляд видів об'єктів баз даних DB2. Повний перелік видів об'єктів баз даних DB2 та детальну інформацію щодо кожного виду об'єктів наведено в документації DB2:

Схеми

Схеми – це простір імен для збирання об'єктів бази даних. Схеми переважно використовуються для:

• забезпечення індикації монопольного використання об'єктів чи зв'язків із додатком;
• логічного угруповання пов'язаних об'єктів

Усі об'єкти бази даних DB2 (крім загальних синонімів) мають повністю класифіковані імена, які з двох частин; схема є першою частиною такого імені:<имя_схемы>.<имя_объекта>

Повністю класифіковане ім'я об'єкта має бути унікальним. Якщо підключитися до бази даних і створити або звернутися до об'єкта, не вказавши схему, DB2 використовуватиме ідентифікатор користувача, за допомогою якого встановлено підключення до бази даних, як ім'я схеми. Щоб встановити схему для поточного сеансу роботи, можна також скористатися оператором SET SCHEMA.

Створення схеми може бути виконано явно шляхом виклику оператора CREATE SCHEMA або неявно, при першій спробі створення об'єкта без вказівки імені схеми. В останньому випадку для успішного створення схеми користувачеві має надати повноваження IMPLICIT_SCHEMA .

Для більшості видів об'єктів бази даних можуть бути створені синоніми, що дозволяють звертатися до вихідних об'єктів через інше ім'я (можливо розміщене в іншій схемі). Створення синонімів здійснюється оператором CREATE SYNONYM/CREATE ALIAS. Також підтримується робота з громадськими синонімами, які не прив'язані до конкретної схеми. Звернення до публічних синонімів здійснюється без зазначення схеми незалежно від встановленої поточної схеми сеансу роботи. Створення публічних синонімів здійснюється командою CREATE PUBLIC SYNONYM/CREATE PUBLIC ALIAS.

Таблиці

Таблиця - це збори пов'язаних даних, логічно впорядкованих у стовпцях та рядках.

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

Створення таблиці здійснюється командою CREATE TABLE, видалення - командою DROP TABLE. Підтримується зміна опису таблиці командою ALTER TABLE, включаючи додавання та видалення колонок, зміна типів даних колонок. Після виконання деяких операцій зміни опису таблиці необхідно виконати її реорганізацію (реструктурувати фізичне зберігання таблиці для оптимального доступу до неї) за допомогою REORG .

Класифікація вбудованих типів даних DB2, які можуть бути використані для визначення колонок таблиці, наведено на малюнку нижче.

Крім одного з допустимих значень підтримуваного типу даних, значення колонок можуть набувати незаповнене, тобто. пусте (NULL) значення. Можливість колонки зберігати порожні значення визначається при створенні таблиці.

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

При роботі з рядковими даними, на відміну від інших типів СУБД, DB2 розрізняє порожній рядок (рядок нульової довжини) і NULL-значення рядкового типу. Ця особливістьвпливає на порядок пошуку (використання предикату рівності замість виразу IS NULL) та склад допустимих значень колонок (при забороні зберігання NULL-значень у колонці може бути збережений порожній рядок).

Строкові значення типів GRAPHIC, VARGRAPHIC та DBCLOB відрізняються від інших рядкових типів тим, що завжди зберігаються у кодуванні UTF-16. При зверненні до відповідних колонок з боку клієнтської програми СУБД забезпечує перетворення даних до кодування, використовуваного клієнтським додатком.

Колонки типу DATE за замовчуванням не містять позначки часу. У режимі сумісності з СУБД Oracle Database, DB2 додатково підтримується зберігання атрибутів часу (години, хвилини, секунди) в колонках DATE.

За необхідності забезпечити ефективну роботуз точними десятковими числами, що включають дробову частину (наприклад, у фінансових додатках), доцільно використання типу даних DECFLOAT, який комбінує точне представлення значень типу DECIMAL та можливості ефективних обчислень над значеннями типу FLOAT.

Тип даних BLOB забезпечує можливість збереження у базі даних неструктурованої двійкової інформації (наприклад, зображень чи документів офісних форматів). Значення типу BLOB можуть зберігатися разом з іншими полями запису (якщо їх розмір дозволяє їх розмістити досить компактно), або окремо, у спеціальному об'єкті зберігання. В останньому випадку запис містить посилання на BLOB-значення, що зберігається, замість самого значення. Аналогічним чином організовано зберігання значень типів CLOB та DBCLOB.

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

На додаток до вбудованих типів даних, DB2 підтримує роботу з типами даних, визначеними на основі вбудованих типів. Робота з типами даних користувача описана в документації DB2.

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

• GENERATED ALWAYS – значення завжди встановлюється сервером DB2 і може бути явно встановлено додатком;
• GENERATED BY DEFAULT – значення встановлюється сервером DB2 у тому випадку, якщо програма не вказала явно привласнене значення при вставці запису.

Також на рівні таблиці можуть бути визначені обмеження, що задають обмеження до складу значень атрибутів. Підтримуються такі види обмежень:

• первинний ключ (PRIMARY KEY) – обмеження унікальності на набір колонок, переважно використовуваних для пошуку одиничного запису, у таблиці може бути лише один первинний ключ;
• обмеження унікальності (UNIQUE) – додаткове обмеження унікальності на набір колонок;
• зовнішній ключ (FOREIGN KEY) – посилання у вигляді набору значень колонок, що вказує на комбінацію колонок іншої таблиці, на яку визначено зовнішній ключ або обмеження унікальності;
• перевірка (CHECK) – логічна умова, що обмежує можливі значення однієї або кількох колонок у записі.

Механізм обмежень реалізує засоби автоматичного контролю та забезпечення цілісності бази даних, включаючи цілісність посилань даних (контроль наявності в «батьківській» таблиці записів, на які посилаються через зовнішні ключі запису «дочірніх» таблиць). Грамотне використання обмежень дозволяє гарантувати формальну коректність заповнення бази даних та певною мірою захиститися від помилок додатків та користувачів при коригуванні даних.

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

Тимчасові таблиці

Для зберігання тимчасових даних додатків у DB2 передбачений механізм тимчасових таблиць, що надає повний набір функцій роботи з табличними даними, але в контексті поточної сесії користувача.

Доступ до тимчасових таблиць значно підвищує продуктивність, оскільки мінімізуються або зовсім не виникають конфлікти доступу до системного каталогу, а також не використовується блокування рядків, ведення журналу (не обов'язково залежить від режиму створення таблиці) і перевірка повноважень.

Тимчасові таблиці також підтримують індекси, тобто до часової таблиці можна створити будь-який стандартний індекс. Для таких таблиць також можна виконати збір статистик (командою RUNSTATS) для отримання інформації, необхідної оптимізатору запитів.

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

У DB2 існує два основні різновиди тимчасових таблиць:

• оголошені часові таблиці (DGTT – Declared Global Temporary Tables);
• створені глобальні часові таблиці (CGTT – Created Global Temporary Tables).

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

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

Хоча DGTT дає змогу оголосити тимчасову таблицю, визначення такої таблиці не можна спільно використовувати у різних підключеннях або сеансах. Під час запуску кожного сеансу необхідно виконувати оператор DECLARE GLOBAL TEMPORARY TABLE.

При використанні створених глобальних тимчасових таблиць (CGTT) визначення тимчасової таблиці потрібно створити лише один раз, оскільки воно зберігається у системному каталозі DB2. Це означає, що інші підключення можуть скористатися визначенням таблиці, а не створювати його знову.

Хоча структуру таблиці CGTT можна використовувати одночасно, дані різних підключень не залежать друг від друга і зникають після закриття підключення.

Індекси

Індекс - це впорядкований набір ключів, кожен із яких свідчить про рядок таблиці. Індекси забезпечують унікальність рядків (тобто реалізують обмеження унікальності, розглянуті у попередньому розділі) та підвищують продуктивність. Нижче описано деякі характеристики, які можна визначити для індексів:

• індекси можуть будуватися за зростанням або за зменшенням значень колонок;
• ключі індексів можуть бути унікальними чи неунікальними;
• індекси можуть будуватися за кількома стовпцями (такі індекси називають комбінованими);
• якщо індексні та табличні дані згруповані в однаковій послідовності індексу, такий індекс називається згрупованим (CLUSTERED INDEX).

Створення індексів забезпечується оператором CREATE INDEX, видалення – оператором DROP INDEX. При створенні індексу вказується його тип (унікальний/неунікальний) та склад колонок для побудови індексу.

У DB2 передбачені інструменти, що забезпечують автоматизований вибір індексів для оптимізації виконання запитів. Найбільш зручно роботу з цими інструментами організовано IBM Data Studio.

Послідовності

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

Створення послідовностей забезпечується командою CREATE SEQUENCE, звернення до чергового та поточного отриманого значення здійснюється за допомогою операторів NEXT VALUE FOR та PREVIOUS VALUE FOR. Для сумісності з СУБД Oracle Database також підтримується синтаксис звернення до значень послідовності через псевдо-колонки NEXTVAL і CURRVAL.

Уявлення

Подання – це відображення даних у таблицях. Дані уявлень не зберігаються окремо, вони відбираються під час запуску уявлення. Підтримуються вкладені уявлення, т. е. уявлення, створені з урахуванням інших уявлень.

Створення уявлень здійснюється командою CREATE VIEW, видалення - командою DROP VIEW. Для полегшення оновлення (заміни) уявлень передбачено синтаксис CREATE OR REPLACE VIEW , який забезпечує створення нового уявлення (якщо його ще не існує) або заміну існуючого уявлення на нове визначення (якщо уявлення з вказаним ім'ямвже було раніше створено.

Тригери

Тригер - це об'єкт, який автоматично виконує операцію з таблицею або уявленням. Певна дія з об'єктом, для якого визначено тригер, викликає запуск тригера. Зазвичай тригер не вважається об'єктом програми; відповідно, зазвичай тригери створюються не розробниками, а адміністраторами бази даних.

Збережені процедури та функції

Процедури, що зберігаються, - це об'єкти бази даних, що містять оператори SQL і бізнес-логіку. Зберігання частини логіки програми у базі даних підвищує продуктивність, оскільки скорочується обсяг трафіку між програмою та базою даних. Крім того, процедури, що зберігаються, надають централізоване місце для зберігання програмного коду, і, відповідно, інші програми можуть скористатися тими ж збереженими процедурами. Для виклику процедури, що зберігається, використовується оператор CALL.

Функції користувача (UDF, User Defined Functions) – це об'єкти бази даних, що дозволяє користувачам розширити мову SQL власною логікою. Функція завжди повертає значення або значення, зазвичай, як результат включеної у функцію бізнес-логіки. Щоб викликати функцію, використовуйте її у складі оператора SQL або оператора VALUES.

У DB2 збережені процедури та функції користувача можна розробляти кількома мовами програмування, серед яких PL/SQL, SQL PL, Java, C, C++, COBOL.

Системний каталог

Одним із базових інформаційних ресурсів СУБД є системний каталог, що зберігає та надає доступ до інформації про структуру бази даних, включаючи:

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

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

Найчастіше використовуються такі таблиці (насправді, уявлення), що входять до складу системного каталогу:

• SYSCAT.SCHEMAS – опис схем бази даних;
• SYSCAT.TABLES - Опис таблиць бази даних;
• SYSCAT.COLUMNS – опис колонок таблиць;
• SYSCAT.INDEXES – опис індексів.

Детальний опис та склад колонок для перелічених вище та інших таблиць системного каталогу наведено в .

Організація паралельної транзакційної обробки

Транзакції

Транзакція (або одиниця роботи) складається з одного чи кількох операторів SQL, що при виконанні розглядаються як окрема одиниця; іншими словами, збій одного оператора транзакції призводить до збою цілої транзакції, при цьому всі оператори, виконані до моменту збою, відкочуються.

Транзакція закінчується оператором COMMIT. Транзакція також може закінчитися оператором ROLLBACK або аварійним (нештатним) вимкненням програми, після якого всі внесені програмою зміни до бази даних будуть скасовані. Початком транзакції є перший виконаний оператор після відкриття з'єднання програми з базою даних або після завершення попередньої транзакції. Кожне з'єднання з базою даних може мати не більше однієї активної транзакції.

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

У разі помилки виконання одиничного оператора, який здійснює запис даних, усі зміни, внесені даним оператором, скасовуються з використанням даних транзакційного журналу. Програма, отримавши діагностичне повідомлення про відмову у виконанні оператора, може скасувати всю транзакцію (оператором ROLLBACK) або виконати якісь інші дії з базою даних і, у результаті, підтвердити внесені зміни (оператором COMMIT).

Програма може визначати додаткові точки відкату в рамках транзакції (за допомогою оператора SAVEPOINT) та скасовувати зміни, виконані після створеної точки відкату (за допомогою оператора ROLLBACK TO). Використання точок відкату дозволяє додатку вибірково скасовувати виконані в рамках транзакції дії, що може бути корисним при обробці помилок контролю цілісності даних та в інших сценаріях.

Блокування

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

Для отримання узгоджених результатів паралельно виконуваних транзакцій потрібен контроль паралельного використання загальних ресурсів. Такий контроль ґрунтується на застосуванні блокувань.

Концепції блокування та паралельного використання тісно взаємопов'язані. Блокування тимчасово забороняє програмам виконувати інші операції до завершення поточної операції. Чим активніше в системі застосовується блокування, тим менше можливостей паралельного використання. З іншого боку, що рідше блокування застосовується у системі, то більше з'являється можливостей паралельного використання.

Блокування спрацьовує автоматично при необхідності для підтримки транзакції і вимикається після переривання такої транзакції (за допомогою команди COMMIT або ROLLBACK). Блокування може встановлюватись на таблиці або рядки.

Існує два основних типи блокування:

• Загальне блокування (S) - встановлюється, коли програма зчитує дані і не допускає внесення змін до того ж рядка іншими програмами.
• Ексклюзивне блокування (X) – встановлюється, коли програма оновлює, вставляє або видаляє рядок.

Якщо двом і більше програмам необхідно виконати операцію з тим самим об'єктом, одному з них доведеться почекати, щоб встановити необхідне блокування. За замовчуванням, програма чекатиме нескінченно довго. Часом очікування блокування програмою керує параметр конфігурації бази даних LOCKTIMEOUT. За замовчуванням цей параметр має значення -1 (нескінченне очікування).

Для встановлення часу очікування блокування у певному підключенні можна використовувати сесійну змінну CURRENT LOCK TIMEOUT. За промовчанням для цієї змінної встановлено значення LOCKTIMEOUT. Щоб змінити це значення, можна скористатись оператором SET LOCK TIMEOUT.

У випадку, коли дві програми (або більше), підключені до однієї бази даних, нескінченно довго чекають на ресурси внаслідок неправильної послідовності звернення до цих ресурсів, виникає ситуація взаємоблокування. Період очікування не може закінчитися, оскільки кожна програма містить ресурс, необхідний іншому застосунку. У всіх випадках проблема взаємоблокування пов'язана з неправильною структурою чи логікою додатків.

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

Рівні ізоляції

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

• втрачене оновлення (при одночасному зміні одного блоку даних різними транзакціями, одна зі змін втрачається);
• недостовірне читання (читання даних, доданих або змінених транзакцією, яка згодом не підтвердиться);
• неповторне читання (при повторному читанні в рамках однієї транзакції, раніше прочитані дані виявляються зміненими);
• фантомне читання (одні й самі вибірки в одній транзакції дають різні безлічі рядків через додавання, видалення чи зміни рядків іншими транзакціями).

Управління з боку програм вбудованими в DB2 механізмами захисту від перелічених вище проблем здійснюється за допомогою установки використовуваного рівня ізоляції. Рівні ізоляції можна як політики блокування, у яких, залежно від обраного рівня ізоляції, можна досягти різних варіантівблокування бази даних додатком. Необхідний додатком рівень ізоляції може бути встановлений на рівні сеансу і на рівні окремого запиту або підзапиту.

DB2 надає такі рівні захисту для ізоляції даних:

• недостовірне читання (Uncommitted Read, UR);
• стабільність курсору (Cursor Stability, CS);
• стабільність читання (Read Stability, RS);
• повторюване читання (Repeatable Read, RR).

Недостовірне читаннятакож називають "брудним". Це найнижчий рівень ізоляції, який припускає найвищий ступінь паралельного використання. При операціях читання рядки не блокуються, крім випадків, коли інший додаток намагається видалити або змінити таблицю; операції оновлення виконуються так само, як при використанні наступного рівня ізоляції – рівня «Стабільність курсору».

При використанні рівня ізоляції «Недостовірне читання» запобігають наступним проблемам:

• втрачене оновлення.

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

При використанні рівня ізоляції «Стабільність курсору» запобігають наступним проблемам:

• втрачене оновлення;
• недостовірне читання.

До виходу DB2 9.7, при використанні рівня ізоляції "Стабільність курсору" виконання запису (операція UPDATE) закривало для читання (операція SELECT) доступ до того ж рядка. Логічною основою служило те, що оскільки операція запису вносить у рядок зміни, читання слід дочекатися завершення оновлень, щоб отримати остаточне зафіксоване значення.

DB2 9.7 за замовчуванням використовується інший підхід до рівня ізоляції «Стабільність курсору» для нових баз даних. Цей новий підхід реалізований за допомогою "прийнятої на даний момент" (currently committed, CC) семантики. При використанні CC-семантики операція запису не закриває доступ до того ж рядка для операції читання. Раніше такий підхід був можливий при використанні рівня ізоляції UR; різниця з поточним підходом полягає в тому, що при UR операція читання набуває недостовірних значень, а при CC-семантиці - значення, прийняті на поточний момент. Прийняті на даний момент значення - це значення, зафіксовані на початок операції запису.

Стабільність читаннязабезпечує блокування всіх рядків, одержуваних програмою. Для заданого запиту блокуються всі рядки, які відповідають набору результатів. Таким чином, використання даного режимуізоляції може призвести до захоплення додатком великої кількості блокувань, та, у разі досягнення встановлених обмежень, до ескалації блокувань з рівня рядків на рівень таблиць. Тим не менш, на рівні ізоляції «Стабільність читання» оптимізатор запитів DB2 не включає план виконання запитів операцій з явного захоплення блокувань на рівні таблиць, навіть якщо в набір результатів потрапляє більша частина записів таблиці.

При використанні рівня ізоляції «Стабільність читання» запобігають наступним проблемам:

• втрачене оновлення;
• недостовірне читання;
• неповторне читання.

Читання, що повторюється– це найвищий рівень ізоляції. Він надає найвищий ступінь блокування та найменше можливостей паралельного використання. Блокування встановлюється на рядки, що обробляються для побудови набору результатів; інакше кажучи, можуть блокуватися навіть рядки, які потраплять у кінцевий пакет результатів. Інші програми не можуть оновлювати, видаляти або вставляти рядки, які вплинуть на набір результатів, доки операція не буде завершена. Читання, що повторюється, гарантує, що один і той же запит, створений додатком кілька разів за одну операцію, щоразу виводитиме однакові результати.

Оптимізатор запитів DB2 під час використання рівня ізоляції «Повторюване читання» може включати в план виконання запитів явні операції встановлення блокувань на рівні таблиць у випадку, коли відповідні запити передбачають сканування всіх рядків таблиці (що означає необхідність заблокувати кожен рядок таблиці під час виконання запиту).

При використанні рівня ізоляції «Стабільність читання» запобігає всім можливі проблемиконкурентного доступу, але одночасно максимально обмежується можливий паралелізм виконання операцій.

Висновок

У цій статті були розглянуті основні функціональні можливостіСУБД IBM DB2 LUW, структура сервера баз даних, настроювання конфігурації та організація зберігання даних. Крім того, розглянуто основні принципи функціонування сервера DB2, види об'єктів баз даних, що підтримуються, і організація паралельної транзакційної обробки DB2.

DB2 (російською мовою вимовляється «Дібі два», також поширена калька з англійського «Дібіт») - сімейство програмних продуктів в області управління інформацією компанії IBM. Найчастіше, посилаючись на DB2, мають на увазі реляційну систему управління базами даних DB2 Universal Database (DB2 UDB), що розробляється та випускається компанією IBM.

Незважаючи на доброзичливе ставлення до операційної системи Linux, яка поширюється під ліцензією з відкритим вихідним кодом, корпорація IBM поки не планує відкривати коди СУБД DB2. Про це заявив директор центру IBM Linux Technology Джим Васко на щорічній конференції Linux Foundation Collaboration Summit, що відбулася (квітень 2011 року) у Сан-Франциско. Всередині IBM триває постійна боротьба між представниками різних підрозділів, пояснив Васко. В одних випадках вибір на користь Linux або Windows означає зниження доходів від продажів програмного забезпечення, але зростання доходів від послуг, а в інших випадках може йти про доходи від продажу обладнання. Доводиться шукати оптимальне рішення, наголосив він. Перехід під контроль Oracle пакетів з відкритим кодом, що розроблялися в Sun Microsystems, створив певні проблеми для IBM, повідомив Васко. Oracle намагається переконати клієнтів обміняти обладнання IBM на її власні сервери Exadata та СУБД Oracle. У 2011 році директор Linux Foundation Джим Землін очікує розвитку на базі Linux спеціалізованих високопродуктивних систем на зразок IBM Watson і готових пристроїв, що потребують мінімального налаштування.

Реалізації

В даний час, крім комерційних продуктів сімейства, IBM розповсюджує також безкоштовний дистрибутив DB2 Express-C для платформ Linux (x86, x86-64, POWER), Windows (x86, x86-64), Solaris (x86-64), Mac OS X (X86-64 beta). Безкоштовна версія має обмеження використання для роботи СУБД не більше одного двоядерного процесора і 2 Гбайт оперативної пам'яті (загальна кількість процесорів і пам'яті в системі може бути будь-яким, але ресурси понад зазначені обмеження не будуть використовуватися СУБД).

2017: Анонс доповнень для контролю над даними

Db2 on Cloud

Оновлене рішення Db2 on Cloud є повністю керованим сервісом, доступним у IBM Cloud.

Серед характеристик технології:

• Динамічна шкала («слайдер») для встановлення параметрів продуктивності та об'єму пам'яті - за допомогою кліка мишкою можна миттєво змінювати масштаб, збільшуючи або зменшуючи продуктивність обробки даних та необхідний обсяг оперативної пам'яті, таким же способом можна збільшити обсяг пам'яті системи зберігання інформації;
• Веб-консоль – допомагає замовникам швидше освоїти сервіс та прискорити роботу з ним.

Загалом рішення Db2 on Cloud дозволяє уникнути трудомісткого процесу узгодження та закупівлі додаткових обчислювальних ресурсів та доповнює IBM Db2 Hosted, версію бази даних, розміщену в IBM Cloud.

Db2 on Cloud Benchmark

DB2 Analytics Accelerator

Версії

2017: JSON та HTAP

DB2 10 є першим суттєвим оновленням СУБД за останні кілька років: 10-та версія системи для z/OS, щоправда, вийшла в 2010 році, але цей реліз призначений для одночасно Linux, Unix і Windows систем.

Обидва продукти містять новий функціонал. DB2 тепер підтримує формат RDF (Resource Description Framework), а InfoSphere може взаємодіяти з розгортаннями Apache Hadoop. Серед інших покращень у DB2, зокрема, можна відзначити прискорення процесів резервного копіювання та введення-виводу.

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

Нова функція під назвою time travel дозволяє більш ефективно управляти тимчасовими даними, у користувачів 10-ї версії для z/OS вона мала великий успіх. З її допомогою користувач або програма можуть вивчати дані в контексті часу існування в СУБД за заданими періодами. Використання таких середовищ є актуальним для аналітики.

DB2 10 може бути завантажена безкоштовно для використання у промисловому оточенні на не більше ніж двох процесорних ядрах та 2Гб пам'яті. Більш функціональні версії обійдуться у суму, починаючи від $6180, куди входить і вартість річного обслуговування. Вартість InfoSphere базується на кількості процесорів або об'ємі даних, базові версії обійдуться близько $40 тис за Тб.

IBM DB2 10.5 версія

Історія

DB2 має довгу історію і, як дехто вважає, стала першою СУБД, що використовує SQL.

З 1975 по 1982 рік прототип DB2 розроблявся в IBM під назвою System Relational, або System R. Мова SQL вперше була реалізована саме в IBM System R, але ця система мала дослідницький характер, а комерційний продукт, що включає SQL, першою випустила компанія Oracle в 1979 року.

СУБД DB2 отримала свою назву в 1982, коли був випущений перший комерційний реліз для VM під назвою SQL/DS, а потім реліз для MVS під назвою DB2. Довгий час поряд з «DB2» використовувався варіант «Database 2», що також є торговою маркою IBM. Очевидно, мало на увазі, що це друга флагманська СКБД IBM після старої ієрархічної СКБД IMS.

Розвиток DB2 сягає корінням на початок 1970-х, коли доктор Е. Ф. Кодд, який працював на IBM, розробив теорію реляційних баз даних і в червні 1970 опублікував модель маніпуляції даними. Для цієї моделі він розробив мову реляційних баз даних і назвав його Alpha. IBM віддала перевагу передати подальшу розробку групі програмістів, непідконтрольній доктору Кодду. Порушивши деякі принципи реляційної моделі, вони реалізували її як «структуровану англійську мову запитів», скорочено SEQUEL. Оскільки SEQUEL було вже зареєстрованою торговою маркою, назву скоротили до SQL – «структуровану мову запитів», і такою вона залишилася й досі.

Таким чином, історично СУБД DB2 виникла з продуктів DB2 для MVS (нащадком якого є DB2 for z/OS) та спорідненого до нього SQL/DS для VM (нащадок - DB2 Server for VSE & VM). Надалі іншим колективом розробників в IBM був реалізований сервер OS/2 EE Database Manager, який згодом еволюціонував у DB2 v2 для OS/2, AIX і потім Windows, а потім у DB2 UDB (його нащадок - DB2 for Linux, UNIX and Windows). Ще одним колективом була виконана інтеграція архітектури DB2 із вбудованою базою даних AS/400 (нащадок - DB2 for i). IBM поступово рухається шляхом інтеграції всіх цих гілок.

Особливості

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

Завдяки пріоритету IBM у розвитку реляційної теорії та позиціям фірми в комп'ютерній галузі, діалект DB2 SQL значно впливає на стандарти SQL ANSI/ISO.

Зберігані процедури в DB2 не дуже широко застосовуються, при цьому традиційно для написання процедур використовуються звичайні мови програмування високого рівня (Сі, Java, PL/I, Кобол і т.д.), це дозволяє програмісту легко оформляти один і той же код або як частина програми, або як процедуру, що зберігається, залежно від того, на клієнті або на сервері його доцільніше виконувати. В даний час у DB2 також реалізовано процедурне розширення SQL для збережених процедур відповідно до стандарту ANSI SQL/PSM.

Оптимізатор DB2 широко використовує статистику розподілу даних у таблицях (якщо процес її збору був виконаний адміністратором бази даних), тому один і той же запит мовою SQL може бути відтрансльований в різні плани виконання залежно від статистичних характеристик даних, які він обробляє.

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

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

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

DB2 є єдиною реляційною СУБД загального призначення, що має реалізації на апаратно-програмному рівні (система IBM i; також в обладнанні мейнфреймів IBM System z реалізуються засоби підтримки DB2).

Сучасні версії DB2 забезпечують розширену підтримку використання даних у форматі XML, зокрема операції з окремими елементами документів XML.