У дома Аудио Видео Въведение в IBM DB2. Отхвърлени DB2 LUW функции. Обявяване на добавки за контрол на данните

Въведение в IBM DB2. Отхвърлени DB2 LUW функции. Обявяване на добавки за контрол на данните

DB2(на руски се произнася „диби два“, често се среща и паус от английски „диби ту“) - семейство софтуерни продуктипо управление на информацията в IBM.

Най-често, когато се говори за DB2, те имат предвид системата за управление на релационни бази данни DB2 Universal Database (DB2 UDB), разработена и пусната от IBM.

Понякога се вижда изписването „DB/2“, но това изписване е неправилно: в нотацията на IBM числото в знаменателя на дроб означава платформата, а „/2“ означава продукта за операционната система OS/2 (или серията компютри PS/2). Например, версията на DB2 за OS/2 беше обозначена като "DB2/2".

Реализации

DB2 СУБД понастоящем се предлага на следните платформи:

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

В миналото бяха издавани версии на DB2 сървър на база данни за OS/2, UnixWare, PTX.

Клиентите на DB2 DBMS, в допълнение към изброените платформи, са пуснати или са били пуснати в различни версии също за SINIX, IRIX, класически Mac OS и за MS-DOS, както и в мобилна версия DB2 навсякъдеза 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 бета). Безплатна версияима ограничения за използване на не повече от един двуядрен процесор и 2 GB за работа на СУБД оперативна памет(общият брой процесори и памет в системата може да бъде всякакъв, но ресурсите извън посочените ограничения няма да бъдат използвани от СУБД).

История

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 датира от началото на 70-те години на миналия век, когато д-р Е. Ф. Код, който е работил за IBM, разработва теорията за релационните бази данни и публикува модел за манипулиране на данни през юни 1970 г. За да приложи този модел, той разработи език за релационни бази данни и го нарече Алфа. IBM избра да възложи по-нататъшното развитие на група програмисти извън контрола на д-р Код. Нарушавайки някои принципи на релационния модел, те го внедриха като „структуриран“. английски езикзаявки”, съкратено като SEQUEL. Тъй като SEQUEL вече беше регистрирана търговска марка, името беше съкратено до SQL - "Structured Query Language" и остана така до днес.

По този начин исторически DB2 еволюира от DB2 за MVS (на който DB2 за z/OS е потомък) и неговия сестра SQL/DS за VM (на който DB2 Server за VSE & VM е потомък). Впоследствие друг екип за разработка в IBM имплементира сървъра OS/2 EE Database Manager, който по-късно еволюира в DB2 v2 за OS/2, AIX и след това Windows, а след това в DB2 UDB (неговият наследник е DB2 за Linux, UNIX и Windows) . Друг екип завърши интегрирането на DB2 архитектурата с вградената база данни AS/400 (потомък - DB2 for i). IBM постепенно върви към интегриране на всички тези клонове.

Особености

Отличителните черти на DB2 включват диалекта SQL език, който определя, с редки изключения, чисто декларативното значение на езиковите конструкции и мощен многофазов оптимизатор, който изгражда ефективен план за изпълнение на заявка въз основа на тези декларативни конструкции. За разлика от други SQL диалекти, DB2 SQL диалектът практически няма съвети за оптимизатора, слабо е развит (и за дълго времекато цяло липсваше) език за съхранена процедура и по този начин всичко е насочено към поддържане на декларативен стил на писане на заявки. В същото време езикът DB2 SQL е изчислително пълен, т.е. той потенциално ви позволява да дефинирате всякакви изчислими съответствия между изходните данни и резултата в декларативна форма. Това се постига, наред с други неща, чрез използването на таблични изрази, рекурсия и други усъвършенствани механизми за манипулиране на данни.

Поради фокуса на IBM върху релационното развитие и позицията на фирмата в компютърната индустрия, DB2 SQL диалектът има значително влияние върху ANSI/ISO SQL стандартите.

Съхранените процедури не се използват много широко в DB2 и традиционно конвенционалните езици за програмиране на високо ниво (C, Java, PL/I, Cobol и т.н.) се използват за писане на запомнени процедури, което позволява на програмиста лесно да форматира един и същ код или като част от приложението, или като съхранена процедура, в зависимост от това дали е по-подходящо да се изпълни на клиента или на сървъра. DB2 понастоящем също така прилага SQL процедурно разширение за запомнени процедури, в съответствие със стандарта ANSI SQL/PSM.

Оптимизаторът на DB2 широко използва статистически данни за разпространение на таблици (ако процесът на събиране на данни е извършен от DBA), така че една и съща SQL заявка може да бъде преведена в напълно различни планове за изпълнение в зависимост от статистическите характеристики на данните, които обработва.

Тъй като исторически DB2 се е развила от многопотребителски системи на мейнфрейми, много внимание в архитектурата на DB2 се отделя на проблемите на сигурността и разпределението на ролите на специалистите, поддържащи DB2. По-специално, за разлика от много други СУБД, DB2 има отделни роли за администратора на СУБД (отговорен за конфигурирането софтуерни компоненти DB2 и тяхното оптимално изпълнение в компютърна система) и администратор на база данни (отговорен за управлението на данни в определена база данни).

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

Като част от концепцията за повишаване на нивото на интеграция на средствата за защита в компютърна система, DB2 няма свои собствени средства за удостоверяване на потребителите, интегриране с инструменти на операционната система или специализирани сървъри за защита. В рамките на DB2 само потребители, удостоверени от системата, са оторизирани.

DB2 е единствената релационна СУБД с общо предназначение, която има реализации на хардуерно/софтуерно ниво (IBM i система; поддръжката на DB2 също е внедрена на IBM System z мейнфрейм хардуер).

Съвременните версии на DB2 предоставят подобрена поддръжка за използване на XML данни, включително операции върху отделни елементи на XML документи.

Обработка на грешка

Полезна характеристика на DB2 SQL Server е способността му да обработва грешки. За тази цел се използва структурата SQLCA. SQL комуникационна зона- 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
Zikopoulos P.K., Baklarz J., deRus D., Мелник R.B. DB2 Версия 8: Официалното ръководство = DB2 Версия 8: Официалното ръководство. - М.: КУДИЦ-ОБРАЗ, 2004. - 400 с. - ISBN 5-9579-0031-1
Смирнов С. Н.Работа с IBM DB2: Урок. - М.: Хелиос, 2001. - 304 с. - ISBN 5-85438-007-2 (препоръчва се от университетите на UMO в региона информационна сигурносткато учебно помагало по специалностите "Интегрирана информационна сигурност на автоматизирани системи" и "Компютърна сигурност")
Сюзън Висер, Бил Уонг.Научете се на DB2 Universal Database за 21 дни = Sams Teach Yourself на DB2 Universal Database за 21 дни. - 2-ро изд. - М.: Уилямс, 2004. - 528 с. - ISBN 0-672-32582-9
Хук Дж., Харбус Р., Сноу Д.Универсалното ръководство за DB2 за Windows NT®. - New Jersey: Prentice Hall PTR, 1999. - P. 504. - ISBN 0-13-099723-4

Фондация Уикимедия. 2010 г.

Вижте какво е "IBM DB2" в други речници:

IBM DB2- Разработчик(и) IBM Първоначално издание 1983 (1983) ... Wikipedia

IBM DB2- DB2 е търговска релационна система за управление на банка данни (RDBMS) на фирмата IBM, създадена от System R и основана на E. F. Codd от IBM Research от Jahr 1970 zurückgeht. Inhaltsverzeichnis 1 Eigenschaften 1.1… … Deutsch Wikipedia

IBM DB2- Développeur IBM Dernière версия ... Wikipedia en Français

IBM DB2 Commonstore- DB2 CommonStore Archiving софтуер, произведен от IBM за управление на имейл съобщения или SAP ERP данни. Част от портфолиото на IBM Information Management, което се основава на платформата за база данни DB2. DB2 CommonStore е един от няколкото продукта, които са... ... Wikipedia

На работа трябваше известно време да се справям с IBM DB2 DBMS. защото Тъй като системата е комерсиална, в интернет няма много информация на руски, затова реших да опиша някои от характеристиките на тази СУБД.

Входна точка

Да започнем с входната точка в СУБД. В SQL SERVER крайна точкае инстанция, в която, разбира се, може да има отделни бази данни, но конфигурацията и моделът на защита са еднакви за цялата инстанция. В DB2 входната точка изглежда така - екземпляр (който съответства на определен порт) - база данни. В същото време има конфигурация за целия екземпляр и за отделна база данни.

Можете да видите конфигурацията на екземпляра или чрез командата db2:

Конфигурация на мениджър на база данни

Тип възел = Enterprise Server Edition с локални и отдалечени клиенти

Ниво на версия на конфигурацията на мениджъра на база данни = 0x0b00

Скорост на процесора (милисекунда/инструкция) (CPUSPEED) = 2.912790e-07
Комуникационна честотна лента (MB/sec) (COMM_BANDWIDTH) = 1,000000e+02

Максимален брой едновременно активни бази данни (NUMDB) = 8
Поддръжка на обединена система от бази данни (FEDERATED) = ДА
Име на монитора на процесора за транзакции (TP_MON_NAME) =

Акаунт за обратно плащане по подразбиране (DFT_ACCOUNT_STR) =

Инсталационен път на Java Development Kit (JDK_PATH) = /home/db2inst1/sqllib/java/jdk32

Ниво на улавяне на диагностични грешки (DIAGLEVEL) = 3
Ниво на уведомяване (NOTIFYLEVEL) = 3
Път на директорията с диагностични данни (DIAGPATH) = /home/db2inst1/sqllib/db2dump

Превключватели за монитор на база данни по подразбиране
Буферен пул (DFT_MON_BUFPOOL) = ИЗКЛ

Къде ще бъдат посочени параметрите, тяхното значение и декодиране. Възможна е и съкратена версия:

вземете dbm cfg

Или със запитване:

Изберете име, стойност от sysibmadm.dbmcfg

от важни параметриможете да отбележите:

тип удостоверяване (AUTHENTICATION)
път по подразбиране за създаване на нови бази данни (DFTDBPATH)
откриване на мрежов сървър (DISCOVER)

Можете да видите настройките за конкретна база данни по следния начин:

свържете се с проба(образец - име на база данни)

вземете конфигурация на мениджъра на бази данни

Или с приблизително същото искане като преди:

изберете име, стойност от sysibmadm.dbcfg

Удостоверяване

Голямата разлика между DB2 и другите СУБД е моделът на удостоверяване. Няма вътрешни потребители като в SQL Server или MySQL. Цялата автентификация се извършва чрез средства, външни за СУБД (динамично зареждащи се добавки) - посредством операционната система или външни добавки (Kerberos, GSS API). Типът удостоверяване се задава в параметъра AUTHENTICATION на конфигурацията на мениджъра на базата данни. По подразбиране е зададена стойността SERVER - потребителското име и паролата се предават в чист текст и тази двойка се проверява за коректност от операционната система. Ако потребителското име и паролата са правилни, тогава привилегията CONNECT се проверява за потребителя или групите, в които той членува (включително специалната PUBLIC група, която включва всички оторизирани потребители). Тези привилегии могат да се видят в таблицата SYSCAT.DBAUTH:

изберете GRANTEE от SYSCAT.DBAUTH, където CONNECTAUTH = "Y"

Голяма грешка в конфигурацията е включването на типа удостоверяване CLIENT.В този случай DB2 се доверява на свързващия клиент да извърши удостоверяване и ако PUBLIC има привилегията CONNECT, тогава всеки потребител ще може да се свърже към базата данни и да получи достъп до всички данни, които PUBLIC има. Потребителското име се взема от операционната система. Тоест, ако се свържем чрез Data Studio като потребител на администратор, тогава всички привилегии, които този потребител. И в този случай няма разлика от кой компютър е направен достъпът. Този видавтентификацията се препоръчва да се активира само когато има защитен канал между сървъра и клиента и други клиенти няма да могат да се свързват към СУБД.

Упълномощаване

Привилегиите на ниво екземпляр са записани в конфигурацията на мениджъра на базата данни. Това са следните привилегии:

SYSADM
SYSCTRL
SYSMAINT
SYSMON

Тези привилегии се задават чрез посочване на групата, в която ще влезе потребителят. В dbmcfg това са съответно опциите SYSADM_GROUP, SYSCTRL_GROUP, SYSMAINT_GROUP и SYSMON_GROUP.

След това има привилегии, специфични за базата данни. Това са привилегии като достъп до база данни (CONNECTAUTH), създаване на таблица (CREATETABAUTH), създаване на рутина (EXTERNALROUTINEAUTH) и т.н. Тези привилегии могат да се видят в изгледа SYSCAT.DBAUTH

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

Привилегиите за достъп до таблица могат да се видят в изгледа SYSCAT.TABAUTH. Типът на предоставената привилегия се съхранява в отделни колони, в зависимост от самата привилегия (SELECTAUTH, DELETEAUTH и т.н.). Когато предоставяте привилегия с помощта на командата GRANT за привилегиите REFERENCES и UPDATE, можете също да посочите имената на колоните, към които ще бъдат разширени дадените привилегии. В този случай информацията за това може да се види в изгледа SYSCAT.COLAUTH

Привилегиите за съчетания (функции, процедури и методи) могат да се видят в SYSCAT.ROUTINEAUTH. Тук не всичко е тривиално, в зависимост от полетата SPECIFICNAME и TYPENAME могат да се предоставят привилегии на всички подпрограми на дадена схема.

Ако статията хареса на читателите, тогава съм готов да говоря за защита на данните в DB2 с помощта на контрол на достъпа, базиран на етикети

Преглед на основните понятия и общо описаниеАрхитектури на бази данни 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=ru&cc=RU&en=utf&hpp=

Очаквайте нови статии от тази серия.

Сурови материалии информация за контакт

Специални благодарности на Марк Баринштейн за отделеното време за корекция на материала на статиите, вниманието към детайла и ценните коментари.

Основната част от материала на статиите е свободна интерпретация официална документация db2. Представената информация е преструктурирана и преформулирана, за да бъде кратка и в същото време възможно най-ясна. Препратките към използваните източници във всички случаи са дадени в текста на статиите и в раздел „Ресурси“.

Като част от поредица от статии се планира да се разгледат следните въпроси:

(статията, която четете в момента)
(инсталация, конфигурация, диагностика, архивиранеи възстановяване)
усъвършенствани административни процедури (прехвърляне на информация, оптимизиране на производителността, управление на приоритетите на изпълнение);
инструменти за изграждане на аналитични хранилища за данни;
технологии за анализ в паметта - DB2 BLU;
масивна паралелна аналитична обработка на данни с DB2 DPF (функция за разделяне на база данни);
разпределени бази данни (конфигурации при отказ, репликация на данни и обединен достъп до данни);
Възможности за клъстериране на DB2 pureScale за толерантност към грешки и мащабируемост.

Статиите от поредицата ще бъдат публикувани при подготовката на съответните материали.

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

Името "DB2" се използва от IBM за цяло семейство продукти, които се различават един от друг както по състава на хардуерните и софтуерните платформи, на които се използват, така и по функционалност, архитектура и технологични характеристики. Тези разлики се дължат на тясната интеграция на повечето продукти от семейството на DB2 операционна системав които функционират, както и спецификата на тези операционни системи.

Семейството DB2 продукти в момента включва:

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

Всяка от изброените СУБД е архитектурно адаптирана за най-ефективно функциониране в съответните операционни системи и включва собствен специфичен набор от инструменти и инструменти за администриране.

Терминологията, използвана в документацията за различните СУБД от семейството на DB2, не е еднаква и едни и същи термини могат да имат различни значения за различните варианти на DB2: например термините "база данни" и "пространство за таблици" имат различни значения за DB2 LUW и DB2 за 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 административния сървър (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,
езикът SQL/PL, използван в СУБД на Oracle,
възможността за разработване на "външни" съхранени процедури в Java, C, C++ и COBOL.

Отличителни характеристики на DB2 са:

мащабируемост, ограничена само от наличните изчислителни ресурси и най-икономичното използване на изчислителните ресурси;
мощни вградени средства за диференциране и контрол на достъпа, които осигуряват възможност за гранулирано ограничаване на достъпа до информация в контекста на обекти (таблици, изгледи), както и прилагане на модел на задължителен контрол на достъпа;
усъвършенствана интегрирана система за архивиране и възстановяване на данни;
наличие на пълен набор от технологии за изграждане на "класически" аналитични хранилища за данни (разделяне на таблици на секции, материализирани изгледи, оптимизиране на кеширане на данни и сканиране на таблици и индекси, "вътрешен" паралелизъм при изпълнение на сложни заявки и др.);
поддръжка за изграждане на масивна паралелна аналитична обработка на данни (MPP) конфигурации от множество сървъри, свързани чрез комуникационна мрежа, базирана на DB2 Database Partitioning Feature (DB2 DPF);
максимална устойчивост на грешки и почти линейно мащабиране на DB2 pureScale клъстерни конфигурации, с данни, съхранявани на споделени дискове;
DB2 BLU технология, която реализира поддръжка за модерни анализи на "колони" в паметта без използване на ръчна оптимизация на структурата на базата данни.

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

Има няколко издания на продукта DB2 LUW, обединени от един набор от основни функции и различаващи се един от друг по наличието на ограничения върху използваните изчислителни ресурси и поддръжката на разширена функционалност. Изданието DB2 Express-C, което се предлага безплатно, може да се използва за оценка на продукти, обучение и дори малки производствени внедрявания. Функционалността и ограниченията на ресурсите на различните издания на DB2 LUW са описани подробно в статията "".

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

DB2 сървър на база данни е компютър, на който е инсталиран DB2 сървърен софтуер (DB2 двигател) и който предоставя услуги за управление на структурирана информация.

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

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

Директното предоставяне на СУБД услуги се осигурява от компонента DB2 мениджър на база данни (DB2 DBM). Всяко копие може да има множество екземпляри на DB2 мениджъра на бази данни, или по-накратко, DB2 екземпляри. Екземплярът е независима среда, в която могат да се създават бази данни и да се изпълняват приложения. Всеки екземпляр на DB2 има своя собствена конфигурация и осигурява достъп до определен набор от бази данни. DB2 екземплярите са независими в смисъл, че изпълнението на операции на един екземпляр не засяга други, с изключение на ограниченията на ресурсите, наложени от изпълнението на множество екземпляри на същия физически или виртуален сървър.

Стартирането и спирането на DB2 услуги се извършва на ниво потребителски модел, т.е. всеки екземпляр на DB2 може да бъде в работещо или спряно състояние. Параметрите на DB2 потребителски модел могат да дефинират неговите ограничения на ресурсите (например по отношение на използването на паметта). Ресурсите на DB2 потребителски модел се използват за поддържане на базите данни, които съществуват в потребителския модел.

Базата данни е колекция от обекти, които съставляват един информационен масив (таблици, изгледи, индекси и т.н.). Базите данни са независими единици и, съответно, обикновено не споделят обекти с други бази данни (изключение могат да бъдат конфигурации на разпределени бази данни, които използват механизми за обединяване на достъп до данни).

Схематичен пример на структурата на сървъра на база данни е показан на фигурата.

В много случаи сървърът на DB2 база данни съдържа една единствена DB2 инсталация с единичен създаден потребителски модел, обслужващ една единствена база данни. С тази конфигурация всички ресурси на сървъра на база данни се използват за изпълнение на единична DB2 база данни.

Обслужването на заявки от свързани приложения от страната на сървъра на базата данни се извършва от така наречените DB2 агенти. За всяко свързано приложение в рамките на DB2 потребителски модел се стартира координиращ (основен) агент, който може да стартира няколко допълнителни (спомагателни) агента, ако е необходимо. Технически, всеки агент е отделна нишка за изпълнение или (за по-стари версии на DB2) отделен процес на операционната система, със свързани ресурси, необходими за неговото изпълнение.

Опции за конфигурация на DB2

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

Променливи на средата;
регистър на DB2 профили;
конфигурационен файл на мениджър на база данни (DBM CFG);
конфигурационен файл на база данни (DB CFG).

Променливите на средата се задават на ниво сървърна операционна система и посредством операционната система. За Windows OS тези променливи всъщност са глобални за сървъра, за семействата на Unix и Linux OS всеки екземпляр може да има свои собствени специфични настройки на променливата на средата.

Настройките на системния регистър на 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 е страница. Позволените размери на страницата са 4K, 8K, 16K и 32K. Информацията за обект на база данни (като записи в таблици и записи в индекс) се поставя на страници.

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

Съхранението на информация в DB2 бази данни е организирано в обекти, наречени таблични пространства. Табличното пространство е именуван набор от контейнери за съхраняване на информация, поставена във файловата система на сървър на база данни.

Едно или повече таблични пространства се създават за всяко таблично пространство. контейнери(файлове или директории във файловата система), за да съхранявате информация, както и да зададете размера на страницата и областта за кеширане на данни (буферен пул, вижте по-долу), както и редица други параметри.

Има следните типове таблични пространства:

обикновени: използва се за хостване на потребителски таблици и индекси;
голям: Използва се за хостване на потребителски таблици и индекси, както и големи обектни (LOB) данни и XML данни. В съвременните версии на DB2 големите таблични пространства се използват по подразбиране вместо обикновените;
временно: използва се за съхраняване на временна информация при изпълнение на заявки (системни временни таблични пространства) и временни таблици, дефинирани от приложения (потребителски временни таблични пространства).

Типът на пространството за таблици се посочва при създаването му и не може да се променя освен чрез изтриване и повторно създаване на пространството за таблици.

Пространствата за таблици могат също да бъдат класифицирани по типа контрола, който е зададен, когато пространството за таблици е създадено:

таблични пространства, управлявани от системата (SMS, System Managed Storage) - директориите се използват като контейнери за таблични пространства, създават се файлове с данни за поставяне на обекти за съхранение в директории. Мястото не е предварително разпределено, файловете нарастват динамично. Когато са дефинирани, контейнерите са фиксирани в момента на тяхното създаване;
пространства за таблици, управлявани от база данни (DMS, Database Managed Storage) - предварително разпределените файлове се използват като контейнери за пространство за таблици, контейнерите могат да се добавят, изтриват или променят;
автоматично управлявани таблични пространства (автоматично съхранение) - автоматично откриване на типа и местоположението на контейнера в зависимост от типа таблично пространство (DMS за обикновени и големи таблични пространства, SMS за временни таблични пространства). Конкретни дефиниции на контейнери не са посочени при създаване на таблично пространство, необходимите контейнери се създават автоматично. Разрастването на съществуващите контейнери и добавянето на нови контейнери се контролират изцяло от DB2.

За да разрешите автоматичното управление на пространството за таблици, първо трябва да създадете база данни с активирано автоматично съхранение (което е по подразбиране) и да свържете набор от пътища за съхранение към нея.

По подразбиране DB2 записва последователно в екстенти, като "отстранява" между контейнерите. Например, ако имате пространство за таблици с размер на страницата 4 KB и размер на екстента 8 страници и използвате 3 непосредствени контейнера в пространство за таблици DMS, това означава, че 32 KB данни (4 KB x 8 страници в екстент = 32 KB) ще бъде записан на един диск, преди да започне записът на следващия.

Започвайки с DB2 Версия 10.1, беше въведена нова концепция за опростяване на управлението на съхранението на данни - група за съхранение(група за съхранение). Групата за съхранение е наименована колекция от пътища във файловата система на DBMS сървъра, която може да се използва за съхраняване на данни. Съставът на групите за съхранение в база данни обикновено определя набора от видове устройства за съхранение, налични за съхраняване на информация. Когато се създава база данни, винаги автоматично се създава група за съхранение по подразбиране в базата данни.

Всяко автоматично управлявано пространство за таблици е свързано с една от създадените групи за съхранение, което определя физическото местоположение на данните, съхранявани в съответните пространства за таблици. Възможно е да преместите таблично пространство от една група за съхранение в друга с помощта на командата ALTER TABLESPACE ... USING STOGROUP ....

Регистриране на транзакции

IBM DB2 LUW, подобно на повечето други модерни релационни СУБД, които предоставят гаранции за ACID, използва регистъра на транзакциите като един от основните механизми за налагане на тези изисквания.

Операциите за модифициране на данни, извършвани от DB2, се записват в журнала на транзакциите като поредица от записи в журнала. Всяка база данни поддържа свой собствен регистър на транзакциите, който представлява последователност от файлове на диска. Размерът на един файл се определя от параметъра LOGFILSIZ, броят на първоначално създадените файлове се определя от параметъра LOGPRIMARY. Ако е необходимо, DB2 може да създаде допълнителни файлове log, максималният брой създадени файлове се контролира от параметъра LOGSECOND.

Информацията се записва в регистъра на транзакциите с помощта на специален буфер в RAM. Съдържанието на буфера се изхвърля на диск (към транзакционни регистрационни файлове), когато буферът се запълва, както и когато транзакциите се потвърждават или анулират (по команда на приложението или при необичайно затваряне на връзката с приложението).

Регистрационният файл на транзакциите, който е необходим за възстановяване на данни след срив, се нарича активен лог файл. Активните регистрационни файлове на транзакции трябва да са достъпни за DB2 мениджъра на базата данни по всяко време. Тъй като наличието на регистрационни файлове за транзакции е от решаващо значение за осигуряване на производителността на СУБД, е осигурен механизъм за отразяване на регистрационните файлове на транзакции в две файлови системи(може да се конфигурира с параметъра LOGMIRROR).

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

Също така, ситуации на препълване на регистъра на транзакциите могат да възникнат, когато има дълготрайни транзакции, които извършват операции за модифициране на данни. Дори ако такава продължителна транзакция направи една единствена малка промяна в базата данни, която след това остава необвързана за дълго време, съответният регистрационен файл на транзакция остава активен и не може да се използва повторно.

Има два основни режима на работа за регистриране на транзакции в DB2: кръгово регистриране и архивно регистриране. В режим на кръгово регистриране DB2 преминава през генерирания набор от транзакционни журнални файлове. В архивен режим на регистриране, DB2 по избор копира регистрационни файлове на транзакции в архива, като използва методите, посочени от параметрите LOGARCHMETH1 и LOGARCHMETH2.

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

Режимът на регистриране на архив също така гарантира, че целостта на базата данни се възстановява, ако сървърът на СУБД се срине. Освен това можете да архивирате базата данни, без да прекъсвате достъпа на потребителите, и да включите активни регистрационни файлове (необходими за възстановяване на целостта на данните) в архива. Възстановяването на данни от резервно копие може да бъде допълнено чрез прилагане на промените, направени в базата данни след създаването на архива, и привеждане на базата данни в състояние в избран момент от миналото (но не по-рано от момента, в който е направено архивирането).

Режимът на архивно регистриране изисква допълнителни ресурси за извършване на операции по архивиране, включително увеличен I/O и допълнително дисково пространство за съхраняване на архивирани транзакционни регистрационни файлове.

Организация на кеширане на данни

За да се намали обемът на извършваните входно-изходни операции, DB2, подобно на други съвременни релационни СУБД, кешира четения и записи, извършвани върху пространства за таблици. Кеширането се извършва с помощта на области от RAM, наречени буферни пулове. Няколко различни буферни пула (създадени от командата CREATE BUFFERPOOL) могат да бъдат дефинирани в DB2, с разрешен размер на страницата, размер и автоматичен контрол на размера. Всяко пространство за таблици е картографирано към конкретен буферен пул и един буферен пул може да бъде споделен между множество пространства за таблици.

Когато извършва операция за четене, първо търси желаната страница с данни в буферния пул. Ако бъде намерена необходима страница, данните се четат от буферния пул, в противен случай страницата се зарежда от диска в буферния пул. Осигурен е механизъм за асинхронно предварително извличане на страници в буферния пул, когато бъде открит линеен (предсказуем) характер на достъпа до страницата. Механизмът за предварително извличане в много случаи намалява времето за изчакване за операции за четене на необходимите данни от диска, като извършва четене в асинхронен режим.

Когато се извърши операция за запис, настройката на страницата се извършва директно в буферния пул. В този случай страницата не се записва на диска в синхронен режим и безопасността на данните се осигурява от механизма за регистриране на транзакциите. Страниците с променено пространство за таблици се записват на диск асинхронно, във фонов режим и осигуряват разумно минимизиране на количеството работа, което може да е необходимо за възстановяване на състоянието на базата данни, когато тя е необичайно (неправилно) затворена. Правилното затваряне на базата данни (например по време на редовно изключване на DBMS сървъра) гарантира, че всички модифицирани страници на всички буферни пулове се записват на диск.

Използване на RAM

Моделът памет DB2 се състои от различни областипамет на ниво DB2 потребителски модел, база данни, приложение и агент.

За подробно описание на областите за съхранение на DB2 вижте по-долу Кратко описаниеназначения от различни области.

Списък на основните области за съхранение на DB2 е показан на фигурата по-долу (първоначално взета от ).

Общата памет, използвана от екземпляра на СУБД, включва:

Monitor Heap - област на паметта за наблюдение на операциите и състоянието, размерът се регулира от параметъра MON_HEAP_SZ;
FCM буфери - област на паметта за взаимодействие между координиращия агент и неговите субагенти, както и за осигуряване на вътрешни взаимодействия в разделени бази данни;
Буферът за одит е област от паметта, където се поставят записите за одит, преди да бъдат изчистени в журнала за одит.

На ниво база данни е обичайно да се прави разлика между:

глобална област на база данни, често наричана област "памет за производителност", която включва различни области за кеширане и зона за заключване;
област с данни на приложението, често наричана "функционална памет", която включва различните области на работната памет на агентите, обслужващи връзките към базата данни.

Областта на глобалната база данни се състои от следните основни компоненти:

Buffer pools - буферни пулове, т.е. зони за кеширане на данни от таблични пространства;
Списък за заключване - област за съхраняване на информация за заключения, чийто размер се контролира от параметъра LOCKLIST;
Кеш на пакети - област за кеширане на планове за изпълнение на заявки, размерът се регулира от параметъра PCKCACHESZ;
Кеш на каталога - област за кеширане на системния каталог, която включва описания на всички обекти на база данни, размерът се регулира от параметъра CATALOGCACHE_SZ;
Utility heap - RAM за извършване на операции по поддръжка на база данни (включително операции за архивиране и възстановяване), размерът се регулира от параметъра UTIL_HEAP_SZ;
Купчина на базата данни - RAM за обслужване на операции с база данни (включително буфер на журнала на транзакциите и кеш за ускоряване на достъпа до системния каталог, както и буфер за одит на ниво база данни), размерът се регулира от параметъра DBHEAP.

Общият размер на областта на глобалната база данни е ограничен от настройката DATABASE_MEMORY.

Областта с данни на приложението включва:

Глобална памет на приложението - общи области на паметта, споделени при обработка на заявки за приложения, максималният размер се регулира от параметъра APPL_MEMORY;
Agent Private Memory - лични области на паметта, използвани за работата на отделни агенти, обслужващи свързани приложения.

По желание можете да разпределите области от паметта, които са разпределени за DB2 драйвера, за да работят от страната на приложението. За локални приложения (тези, които използват IPC вместо мрежов достъп за свързване към мениджъра на базата данни), DB2 настройките, които задавате, контролират колко RAM се разпределя (основно настройката ASLHEAPSZ).

Управление на RAM при извършване на операции за сортиране

Много видове СУБД операции изискват сортиране на данни, така че на управлението на RAM, използвана за сортиране, се обръща специално внимание.

Ако е невъзможно да се разпредели областта за сортиране изцяло в RAM, данните за сортиране се поставят във временното таблично пространство на системата. Производителността на заявки, които изискват такива големи операции за сортиране, може да бъде значително влошена.

Параметри, които контролират разпределението на RAM за сортиране:

SORTHEAP - ограничение на паметта за операция за сортиране;
SHEAPTHRES - ограничение на размера на частната памет на агента, разпределена за операцията за сортиране;
SHEAPTHRES_SHR - ограничението за количеството обща RAM, която може да се използва за извършване на операции за сортиране (общо от всички потребители) във всеки даден момент.

DB2 поддържа три основни модела за управление на паметта за сортиране:

Споделен модел за сортиране (споделено сортиране) – използва се по подразбиране, предполага настройка на параметъра SHEAPTHRES на 0. Разпределението на RAM за сортиране се извършва от глобалната област на базата данни.
Модел на област за частно сортиране (частно сортиране) - използва се, когато стойността на параметъра SHEAPTHRES е различна от нула и няма конфигуриран споделена паметсортиране. Разпределението на RAM за сортиране се извършва от областта с данни на приложението (по-точно от частни области, принадлежащи на агенти).
Хибриден модел на сортиране (хибридно сортиране) - използва се, когато параметърът SHEAPTHRES е различен от нула и има конфигурирана споделена памет за сортиране. Операциите, които изискват използването на споделена памет за сортиране, се извършват с разпределение на памет в глобалната област на базата данни, други операции за сортиране се извършват с разпределение на памет в частни области на агенти.

Използването на споделена (глобална) памет за извършване на операции за сортиране предоставя редица важни предимства:

по-гъвкаво управление на RAM при изпълнение на заявки, което ви позволява да увеличите ефективността на използването на RAM;
възможността за използване на паралелна версия на алгоритъма за сортиране поради едновременния достъп до областта на паметта за сортиране на координиращия агент и неговите подчинени DB2 подагенти.

Една от следните настройки може да се използва, за да се разреши използването на споделена памет при извършване на операции за сортиране:

общият модел на областта за сортиране се активира чрез задаване на параметъра SHEAPTHRES на 0;
паралелността на изпълнението на операциите се разрешава чрез настройка на параметъра INTRA_PARALLEL на YES;
променливата DB2_WORKLOAD е зададена на ANALYTICS;
функцията DB2 Connection Concentrator е активирана (обикновено се използва при достъп до DB2 за z/OS и DB2 за i бази данни, вижте описанието на тази характеристика в ).

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

Наличието на голям брой различни области на RAM и параметри, които регулират техния размер, може да изисква значителни усилия за ръчна настройка на DB2 сървър. Следователно, започвайки с версия 9, IBM DB2 поддържа автоматично управление на разпределението на RAM между различни области, използвайки самонастройващ се мениджър на паметта (STMM, Self-Tuning Memory Manager).

Когато стартирането е активирано, STMM динамично разпределя наличните ресурси на паметта към потребителите на памет в базата данни. STMM реагира на промените в характеристиките на работното натоварване, като коригира стойностите на параметрите на конфигурацията на паметта и размера на буферните пулове, за да оптимизира производителността. За да активирате STMM, трябва да зададете конфигурационния параметър на базата данни SELF_TUNING_MEM на ON.

Автоматичното управление на разпределението на паметта се извършва за тези области на паметта, за които е изрично разрешено. Когато задавате стойност на конфигурационен параметър с командите UPDATE DBM CFG и UPDATE DB CFG, за да използвате STMM, ключовата дума AUTOMATIC се посочва след стойността на параметъра. Числената стойност на параметъра, посочена в този случай, се използва като първоначална стойност, след което STMM периодично коригира стойностите, като взема предвид текущото натоварване, преразпределяйки RAM между различни потребители.

Автоматичното управление на STMM се поддържа за следните опции:

INSTANCE_MEMORY е общото количество RAM в DB2 потребителския модел;
DATABASE_MEMORY - глобални области на база данни;
DBHEAP - област за обслужване на операции с бази данни;
LOCKLIST – обхват за съхраняване на данни за ключалки;
MAXLOCKS - процентът на паметта, заета от заключвания на едно приложение за превключване към ескалация на заключването;
PCKCACHESZ - кешираща област за планове за изпълнение на заявки;
SHEAPTHRES_SHR - обща област за сортиране;
SORTHEAP - размер на областта за сортиране за една операция;
APPL_MEMORY - област на функционалната памет;
APPLHEAPSZ - частно ограничение на паметта, използвано от един агент;
STMTHEAP - ограничение на размера на областта, използвана от компилатора на SQL и XQuery заявки (на заявка);
STAT_HEAP_SZ е максималното количество RAM, разпределено за изграждане на статистика от помощната програма 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 кодиране. При достъп до съответните колони от страна на клиентското приложение, СУБД осигурява преобразуване на данните в кодирането, използвано от клиентското приложение.

Колоните от тип ДАТА (дата) не съдържат времеви клейма по подразбиране. В режим на съвместимост с Oracle Database DB2 допълнително поддържа съхраняване на атрибути за време (часове, минути, секунди) в колони ДАТА.

Ако трябва да работите ефективно с точни десетични числа, които включват дробна част (например във финансови приложения), препоръчително е да използвате типа данни DECFLOAT, който съчетава точното представяне на DECIMAL стойности и способността за ефективно изчисляване стойности от типа FLOAT.

Типът данни BLOB предоставя възможност за съхраняване на неструктурирана двоична информация (като изображения или офис документи) в база данни. BLOB стойностите могат да се съхраняват заедно с други полета за запис (ако размерът им позволява да бъдат достатъчно компактни) или отделно, в специален обект за съхранение. В последния случай записът съдържа препратка към съхранената BLOB стойност вместо самата стойност. Съхранението на стойности от типове CLOB и DBCLOB е организирано по подобен начин.

Типът данни XML осигурява съхранение в полета на таблица на структурирани йерархични XML документи. За съхранени XML документи се поддържат операции за достъп до атрибути (без необходимост от парсване на XML документа при достъп), индексиране на отделни атрибути и други функции.

В допълнение към вградените типове данни, DB2 поддържа дефинирани от потребителя типове данни, които се дефинират на базата на вградени типове. Работата с потребителски дефинирани типове данни е описана в DB2 документацията.

При създаване на таблица е възможно да се зададат правила за автоматично попълване на техните стойности за колони. Специален случай на колони за автоматично довършване са колоните за идентичност, които са цифрови колони, които автоматично генерират уникална цифрова стойност за всеки вмъкнат ред. Автоматичното пълнене може да се извърши в един от двата режима:

ГЕНЕРИРАН ВИНАГИ - Стойността винаги се задава от DB2 сървъра и не може да бъде изрично зададена от приложението;
ГЕНЕРИРАН ПО ПОДРАЗБИРАНЕ - Стойността се задава от 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 може да се използва веднага, данните от различни връзки са независими една от друга и изчезват, когато връзката се затвори.

Индекси

Индексът е подреден набор от ключове, всеки от които сочи към ред от таблица. Индексите налагат уникалността на реда (тоест прилагат уникалните ограничения, обсъдени в предишния раздел) и подобряват производителността. По-долу са описани някои от характеристиките, които могат да бъдат дефинирани за индекси:

индексите могат да бъдат построени във възходящ или низходящ ред на стойностите на колоните;
индексните ключове могат да бъдат уникални или неуникални;
индексите могат да бъдат изградени върху няколко колони (такива индекси се наричат комбинирани);
ако данните от индекс и таблица са групирани в една и съща последователност от индекси, такъв индекс се нарича групиран (КЛУСТЕРИРАН ИНДЕКС).

Създаването на индекс се осигурява от оператора 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) са обекти на база данни, които позволяват на потребителите да разширят 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, когато се използваше ниво на изолация на Cursor Stability, извършването на запис (операция UPDATE) затваряше достъп за четене (операция SELECT) до същия ред. Логичната основа беше, че тъй като операцията за запис прави промени в реда, четенето трябва да изчака завършването на актуализациите, за да получи крайната ангажирана стойност.

DB2 9.7 по подразбиране използва различен подход към нивото на изолация на стабилността на курсора за нови бази данни. Този нов подход се прилага с помощта на семантиката на "текущо ангажирани" (CC). Когато се използва CC семантика, операция за запис не затваря достъпа до същия ред за операция за четене. Преди това този подход беше възможен с помощта на нивото на изолация на UR; разликата с настоящия подход е, че при UR операцията за четене получава невалидни стойности, докато при CC семантиката получава стойностите, приети в момента. Текущо ангажираните стойности са стойностите, които са били ангажирани преди началото на операцията за запис.

Стабилност при четенеосигурява заключване на всички редове, получени от приложението. За дадената заявка всички редове, които съответстват на набора от резултати, се блокират. По този начин използването на този режим на изолация може да доведе до получаване на голям брой заключвания от приложението и, ако зададените ограничения бъдат достигнати, ескалиране на заключванията от ниво ред към ниво таблица. Въпреки това, на изолираното ниво на стабилност при четене, оптимизаторът на DB2 заявки не придобива изрично заключвания на ниво таблица в плана за изпълнение на заявките, които изпълнява, дори ако наборът от резултати съдържа повечето от записите в таблицата.

Използването на нивото на изолация на стабилност при четене предотвратява следните проблеми:

загубена актуализация;
неправилно четене;
неповтарящо се четене.

Повторно четенее най-високото ниво на изолация. Той осигурява най-висока степен на заключване и най-малко количество едновременност. Поставя се ключалка върху редовете, които се обработват за изграждане на набора от резултати; с други думи, дори редове, които не влизат в окончателния пакет с резултати, могат да бъдат блокирани. Други приложения не могат да актуализират, изтриват или вмъкват редове, които ще повлияят на набора от резултати, докато операцията, която е в ход, не приключи. Многократното четене гарантира, че една и съща заявка, създадена от приложението многократно в една операция, дава едни и същи резултати всеки път.

Оптимизаторът на заявки на DB2, когато използва нивото на изолация на повторено четене, може да включи в плана за изпълнение на заявките изрични операциизадаване на ключалки на ниво таблица, когато съответните заявки включват сканиране на всички редове на таблицата (което означава необходимост от заключване на всеки ред на таблицата по време на изпълнение на заявката).

Използването на нивото на изолация за стабилност при четене предотвратява всички възможни проблемиконкурентен достъп, но в същото време възможният паралелизъм на изпълнението на операциите е максимално ограничен.

Заключение

В тази статия бяха разгледани основната функционалност на IBM DB2 LUW СУБД, структурата на сървъра на базата данни, конфигурационните настройки и организацията на съхранение на данни. Освен това се разглеждат основните принципи на DB2 сървъра, поддържаните типове обекти на бази данни и организацията на паралелна DB2 транзакционна обработка.

Входна точка

Да започнем с входната точка в СУБД. В SQL SERVER крайната точка е екземпляр, който, разбира се, може да има отделни бази данни, но моделът на конфигурация и сигурност е един и същ за целия екземпляр. В DB2 входната точка изглежда така - екземпляр (който съответства на определен порт) - база данни. В същото време има конфигурация за целия екземпляр и за отделна база данни.

Можете да видите конфигурацията на екземпляра или чрез командата db2:

Конфигурация на мениджър на база данни

Тип възел = Enterprise Server Edition с локални и отдалечени клиенти

Ниво на версия на конфигурацията на мениджъра на база данни = 0x0b00

Акаунт за обратно плащане по подразбиране (DFT_ACCOUNT_STR) =

Инсталационен път на Java Development Kit (JDK_PATH) = /home/db2inst1/sqllib/java/jdk32

Превключватели за монитор на база данни по подразбиране
Буферен пул (DFT_MON_BUFPOOL) = ИЗКЛ

Къде ще бъдат посочени параметрите, тяхното значение и декодиране. Възможна е и съкратена версия:

вземете dbm cfg

Или със запитване:

Изберете име, стойност от sysibmadm.dbmcfg

Важните параметри включват:

тип удостоверяване (AUTHENTICATION)
път по подразбиране за създаване на нови бази данни (DFTDBPATH)
откриване на мрежов сървър (DISCOVER)

Можете да видите настройките за конкретна база данни по следния начин:

свържете се с проба(образец - име на база данни)

вземете конфигурация на мениджъра на бази данни

Или с приблизително същото искане като преди:

изберете име, стойност от sysibmadm.dbcfg

Удостоверяване

изберете GRANTEE от SYSCAT.DBAUTH, където CONNECTAUTH = "Y"

Голяма грешка в конфигурацията е включването на типа удостоверяване CLIENT.В този случай DB2 се доверява на свързващия клиент да извърши удостоверяване и ако PUBLIC има привилегията CONNECT, тогава всеки потребител ще може да се свърже към базата данни и да получи достъп до всички данни, които PUBLIC има. Потребителското име се взема от операционната система. Тоест, ако се свържем чрез Data Studio като потребител на администратор, тогава всички привилегии, които този потребител има, ще бъдат предоставени. И в този случай няма разлика от кой компютър е направен достъпът. Този тип удостоверяване се препоръчва да се активира само когато има защитен канал между сървъра и клиента и други клиенти няма да могат да се свържат към СУБД.

Упълномощаване

SYSADM
SYSCTRL
SYSMAINT
SYSMON

Релационна база данни е набор от релации, чиито имена съвпадат с имената на схемата на релацията в схемата на базата данни. Днес са известни голям брой различни SQL сървъри за бази данни. Нека се съсредоточим върху следните четири водещи сървърни СУБД - Oracle8i, IBM DB2, Microsoft SQLСървър и Informix - и ги сравнете в действие на всеки от основните етапи на функциониране.

Oracle8i. Пакет Oracle8i, надарен с най-модерния набор от функции за работа с езика Java и достъп до данни през Интернет, система за оптимизиране на паралелен достъп. Единственият недостатък на тази СУБД е сложността на администрирането, но всички разходи за нейното внедряване и развитие по-късно ще се изплатят с ефективна и надеждна работа. (сложността и високата цена са спорни). Сред основните свойства на СУБД Oracle трябва да се отбележи следното: Най-висока надеждност. Възможност за разделяне на големи бази данни на секции (дял на голяма база данни), което прави възможно ефективното управление на гигантски бази данни от гигабайти; Наличие на универсални средства за защита на информацията; Ефективни методи максимално увеличениескорост на обработка на заявката; Растерно индексиране; Безплатни таблици (в други СУБД всички таблици се попълват веднага след създаването); Паралелизиране на операциите в заявка. Наличие на широка гама от инструменти за разработка, мониторинг и администриране. Фокус върху Интернет технологиите Решения, които не отстъпват на разработката на Oracle, могат да бъдат намерени само в DB2 на IBM. Ориентацията към интернет технологиите е основното мото на съвременните продукти на Oracle. В това отношение могат да се отбележат пакетът interMedia, който осигурява обработка на данни в мултимедийни формати, и Jserver, вграден инструмент за работа с езика Java, който съчетава възможностите на езика Java с възможностите на релационните бази данни. Enterprise JavaBeans са градивните елементи, които изграждат Java интернет приложенията. Oracle се придържа към принципа, че всички важни функции трябва да се управляват от един център, така че предложеният interMedia модул предоставя на потребителите най-модерните функции за работа с мултимедийни обекти: Много напреднали инструменти за обработка на аудио клипове; Неподвижни изображения; Видео клип; Географски данни (с цял набор от функции, свързани с определяне на местоположението, включени в модула Locator). Oracle8i имплементира най-добрите съвременни инструменти за обектно-ориентирано проектиране на база данни, включително таблични структури, които позволяват наследяване на свойства и методи на други обекти на таблична база данни, което ще избегне грешки при изграждане на база данни и ще улесни поддръжката им. Трябва също да се отбележи, че разработената от Oracle система за многоверсионна паралелна оптимизация е една от най-важните характеристики на архитектурата на Oracle (тази функция е достъпна само в СУБД InterBase от InterBase от Inprise). Тази функцияви позволява да елиминирате ситуацията, когато единият потребител трябва да изчака, докато другият завърши промените в съдържанието на базите данни (тоест в Oracle няма ключалки за четене). Тази функция позволява на Oracle8i да изпълнява повече транзакции в секунда на потребител, отколкото всяка друга база данни. По производителност при работа в WEB среда под LINUX Oracle заема почетното второ място след СУБД MySQL, като същевременно значително надминава всички други СУБД по отношение на надеждност и сигурност.

СУБД Microsoft SQL Server Най-важните характеристики на тази СУБД са: лекота на администриране, възможност за свързване към мрежата, скорост и функционалност на сървърния механизъм на СУБД, наличие на инструменти отдалечен достъп, Административният инструментариум на СУБД включва набор от специални съветници и инструменти за автоматично задаване на конфигурационни параметри. Освен това тази база данни е оборудвана с отлични инструменти за репликация, които ви позволяват да синхронизирате компютърни данни с информация от базата данни и обратно. OLAP сървърът, включен в пакета, позволява да се записват и анализират всички данни, достъпни за потребителя. По принцип тази СУБД е модерна пълнофункционална база данни, която е идеална за малки и средни организации. Трябва да се отбележи, че SQL Server е по-нисък от другите разглеждани СУБД по два важни показателя: програмируемост и средства за работа. При разработването на клиентски приложения за бази данни, базирани на Java, HTML, често възниква проблемът с недостатъчния софтуер на SQL Server и ще бъде по-трудно да се използва тази СУБД, отколкото системите DB2, Informix, Oracle или Sybase. Глобалната тенденция през 21 век се превърна в почти универсален преход към платформата LINUX, а SQL Server работи само в среда на Windows. Следователно използването на SQL Server е препоръчително само ако стандартът ODBC се използва изключително за достъп до съдържанието на базата данни, в противен случай е по-добре да се използва друга СУБД.

IBM DB2 IBM DB2 DBMS е резултат от почти 30 години разработка и изследователска работаот IBM. Най-новата версия на тази СУБД (6.x) разполага с един от най-сложните набори от инструменти за управление и оптимизация и двигател на база данни, който може да се развие от лаптоп с Windows 95 до цял клъстер от мейнфрейми S/390, работещи с OS/390. DB2 пакетът се предлага в две издания: DB2 Workgroup и DB2 Enterprise Edition. Тази СУБД внедрява всички иновативни технологии за двигател на бази данни, познати от предишни версии на DB2, като паралелна обработка на заявки, пълен набор от инструменти за репликация, обобщени таблици на заявки за подобряване на производителността на базата данни, обектно-ориентирани функции за проектиране на база данни и характеристики на езика Java. В допълнение системата DB2 е оборудвана с пълен набор от мултимедийни разширения, които ви позволяват да записвате и манипулирате текстови, звукови и видео фрагменти, изображения и географски данни. Можем да кажем, че по отношение на мащабируемостта технологията за клъстериране на бази данни, разработена от специалисти на IBM, няма аналози. Тези разширения значително улесняват процеса на разработване на приложения за уеб, както и програми, съдържащи фотографски изображения и обемни текстови отчети. Системата DB2 също е доста конкурентна като платформа за разработка на приложения, тъй като има инструмент за създател на съхранени процедури, който автоматично преобразува SQL оператора в подходящия Java клас и го включва в структурата на базата данни. В DB2 6.1 оперативната съвместимост с други СУБД е значително подобрена, като се позволява използването на OLE DB спецификацията на Microsoft, нов стандарт за достъп до база данни. DB2 административни контроли, които са нова версияпренаписани на Java и могат да бъдат получени от мрежата, заслужават най-висока оценка. Основните недостатъци на тази СУБД са относителната сложност на администрирането и липсата (все още) на реализации за популярни сървърни операционни системи, като LINUX. В тази СУБД, благодарение на Index Smart-Guide, е възможно да се извърши настройка, формиране на оптимални индекси за даден брой достъпи, което характеризира типичното натоварване на базата данни. DB2 е единственият пакет, който ви позволява да генерирате обобщени таблици, което значително подобрява ефективността на СУБД като хранилища за данни. PivotTable е временно работно пространство, използвано от базата данни за съхраняване на отговори на често задавани запитвания. Моделът DB2 6.1 се очертава като най-рентабилната система с висока производителност. Административните инструменти на тази СУБД са доста подходящи за нивото на решаваните задачи, освен това предоставя изключително широки възможности за работа с мултимедийни данни и за програмиране (което явно липсва в Microsoft SQL Server).

СУБД от Informix. Напоследък се наблюдава преход от релационни СУБД към обектно-ориентирани (което ясно се вижда в примера на Oracle). Informix също след тази концепция обяви ново решение Centaur DBMS, базирано на релационната база данни Informix Dynamic Server 7.3 и обектно-релационната база данни Informix Universal Data Option и комбинирайки високата производителност на Dynamic Server при работа с данни с универсалност и мултимедийни функции на Universal Опция за данни. Тази реализация е предназначена за разработване на интернет системи. Очаква се тази СУБД да има гъвкава среда за разработка с мащабируемост, която да отговаря на интензивните работни натоварвания, характерни за Интернет, и инструменти за работа с нови типове данни, които станаха повсеместни с развитието на Мрежата. Java инструментите, внедрени в новата система, ще позволят на разработчиците да създават съхранени процедури, потребителски програми и DataBlades компоненти на този език, който Informix нарича

персонализирани разширения на бази данни. От гледна точка на клиентите на Inforix, това е голяма крачка напред, защото досега, когато работят с DataBlades, те можеха да използват само C и SPL, вътрешния език на Informix за писане на съхранени процедури. Освен това пакетът Centaur ще бъде оборудван с вградено управление на ActiveX обекти. Това ще направи възможно например създаването на съхранени процедури за база данни на езика Visual Basic; това обаче изисква пакетът Centaur да работи в среда на Windows NT. Centaur ще бъде добавка към Informix Dynamic Server и ще работи с традиционния формат на базата данни за този пакет, така че потребителите ще имат всички стари функции на свое разположение и надграждането на системата до новата версия няма да бъде много трудно. В допълнение, пакетът Centaur ще запази всички възможности за проектиране и програмиране, които превърнаха системата Informix Universal Server в изключително инженерно постижение. Новата система ще разполага със средства за обектно-ориентирано проектиране на база данни, създаване на специализирани таблици и програми за индексиране; това ще позволи на потребителите да вграждат свои собствени функции в заявки и да не разчитат единствено на стандартни средства SQL. Изводи. След като разгледахме основните характеристики на архитектурите за изграждане на AIS, сървърни операционни системи и СУБД, в бъдеще като архитектура на AIS ще изберем архитектурата на Интернет / Интранет, като операционна система Linux сървър, като СУБД Oracle 8i.

2) Клауза SQL SELECT. Вградени функции.

SELECT колона FROM таблица WHERE колона LIKE шаблон

SELECT * FROM Store_Information WHERE store_name LIKE "%AN% ‘;

ИЗБЕРЕТЕ име на колона ОТ име на таблица WHERE име_на_колона МЕЖДУ стойност1 И стойност2

SELECT * FROM Persons WHERE LastName BETWEEN "Hansen" AND "Pettersen";

SELECT * FROM Persons WHERE LastName NOT BETWEIN "Hansen" AND "Pettersen";

ИЗБЕРЕТЕ компания, Номер на поръчка ОТ Поръчки ПОРЪЧАЙТЕ ПО(сортиране ) Компания;

ИЗБЕРЕТЕ компания, номер на поръчка ОТ поръчки ORDER BY компания, номер на поръчка;

ИЗБЕРЕТЕ Компания, Номер на поръчка ОТ Поръчки ORDER BY Компания DESC(обратен ред);

ИЗБЕРЕТЕ компания, номер на поръчка ОТ поръчки ORDER BY компания DESC , номер на поръчка ASC(прав . поръчка ) ;

SELECT * FROM Persons WHERE FirstName="Tove" AND LastName="Svendson";

SELECT * FROM Лица WHERE firstname="Tove" OR lastname="Svendson" ;

SELECT * FROM Persons WHERE (FirstName="Tove" ИЛИ FirstName="Stephen") И LastName="Svendson" ;

ИЗБЕРЕТЕ store_name FROM Store_Information WHERE Продажби > 1000 ИЛИ (Продажби< 500 AND Sales > 275);

ФункцииИЗБЕРЕТЕфункция( колона) ОТмасаСР - средна стойност в колоната;БРОЯ - брой стойности в колона; MAX - най-много голямо значениев колона; MIN - най-малката стойност в колоната; SUM - сума от стойности по колона

Примери: ИЗБЕРЕТЕ СР(Възраст) ОТ Лица; ИЗБЕРЕТЕ БРОЯ(име_на_магазин) ОТ Информация_на_магазин; ИЗБЕРЕТЕ БРОЯ(РАЗЛИЧЕН store_name) FROM Store_Information; ИЗБЕРЕТЕ МАКС(Възраст) ОТ Лица ИЗБЕРЕТЕ SUM(Продажби) FROM Store_Information;

3) Сериализация на транзакции, конфликти на операции. Методи за сериализиране на транзакции. Дръжки за синхронизиране, дръжки за синхронизиране на гранули. Методи за сериализиране на транзакции. Улавяне на предикатна синхронизация. Сериализиране на базата на времеви отпечатъци.

За да постигне изолация на транзакциите, СУБД трябва да използва методи за регулиране на съвместното изпълнение на транзакциите. Планът (методът) за изпълнение на набор от транзакции се нарича сериенако резултатът от съвместното изпълнение на транзакции е еквивалентен на резултата от някакво последователно изпълнение на същите транзакции. Сериализация на транзакция- това е механизъм за изпълнението им по някакъв сериен план. Осигуряването на такъв механизъм е основната функция на компонента на СУБД, отговорен за управлението на транзакциите. Система, която поддържа сериализация на транзакции, осигурява реална изолация на потребителя. Основният проблем при внедряването е изборът на метод за сериализиране на набор от транзакции, който не ограничава прекалено паралелизма им. Едно тривиално решение, което идва на ум, е наистина последователно изпълнение на транзакции. Но има ситуации, в които е възможно да се изпълнят отчети за различни транзакции в произволен ред, като се запази серийността. Примерите включват транзакции само за четене, както и транзакции, които не са в конфликт с обекти на база данни. Между транзакциите могат да съществуват следните видове конфликти: W-W - транзакция 2 се опитва да модифицира обект, модифициран от транзакция 1, който не е приключил; R-W - транзакция 2 се опитва да модифицира обект, прочетен от транзакция 1, който не е приключил; W-R – Транзакция 2 се опитва да прочете обект, модифициран от транзакция 1, която не е приключила.Практиките за сериализиране на транзакция се основават на тези конфликти.

Съществуват два основни подходадо сериализиране на транзакции - базирано на синхронизиране на улавяне на обекти от база данни и на използване на времеви отпечатъци. Същността на двата подхода е да се открият транзакционни конфликти и да се елиминират. Най-често срещаният подход в централизираните СУБД (включително системи, базирани на архитектурата "клиент-сървър") е подходът, базиран на спазване на двуфазния протокол за синхронизиране на заснеманиятаобекти на база данни. Най-общо казано, протоколът е, че преди извършване на каквато и да е операция в транзакция T върху обекта на базата данни r, от името на транзакция T, се изисква синхронизиращо улавяне на обект r в съответния режим (в зависимост от типа операция). Основните режими на синхронизиране на записите са: съвместен режим - S (Shared), което означава споделено заснемане на обект и е необходимо за извършване на операция за четене на обект; ексклузивен режим - X (eXclusive), което означава изключително улавяне на обекта и се изисква за извършване на операции по вмъкване, премахване и модифициране. Гранулирано улавяне на синхронизация - подход, койтомогат да бъдат заявени синхронизирани заснемания на обекти от различни нива: файлове, релации и кортежи. Изискваното ниво на обект се определя от изпълняваната операция (например, за да се изпълни операция за изтриване на релация, цялата релация трябва да бъде обектът за улавяне на синхронизация, но за да се изпълни операция за изтриване на кортеж, този кортеж). Обект от всяко ниво може да бъде заснет в режим S или X. Улавяне на предикатна синхронизация- това не е прихващане на обекти, а условията (предикатите), на които тези обекти отговарят.Алтернативен метод за сериализиране на транзакции, който работи добре в условия на редки конфликти на транзакции и не изисква изграждането на графика на изчакване на транзакция. базиран на използване на времеви отпечатъци.Основната идея на метода (който има много разновидности) е следната: ако транзакция T1 е започнала преди транзакция T2, тогава системата гарантира, че режимът на изпълнение е така, сякаш T1 е бил напълно изпълнен преди началото на T2.

За да направите това, на всяка транзакция T се присвоява времева маркировка t, съответстваща на началния час T. Когато извършва операция върху обект r, транзакция T я маркира със своята времева маркировка и типа на операцията (четене или промяна). Преди да извърши операция върху обект r, транзакция T1 извършва следните действия: Проверява дали транзакцията T, маркирала този обект, е приключила. Ако T е приключило, T1 маркира обекта r и изпълнява неговата операция. Ако транзакцията T не е завършена, тогава T1 проверява дали операциите са в конфликт. Ако операциите не са в конфликт, времето с по-ниска стойност остава или е прикрепено към обекта r и транзакцията T1 изпълнява своята операция. Ако операциите T1 и T са в конфликт, тогава ако t(T) > t(T1) (т.е. транзакцията T е по-млада от T), T се връща назад и T1 продължава. Ако t(T)< t(T1) (T "старше" T1), то T1 получает новую временную метку и начинается заново. К недостаткам метода временных меток относятся потенциально более частые откаты транзакций, чем в случае использования синхронизационных захватов. Это связано с тем, что конфликтность транзакций определяется более грубо. Кроме того, в распределенных системах не очень просто вырабатывать глобальные временные метки с отношением полного порядка.

Само за комплекса. Програми. Желязо. Интернет. Windows

Въведение в IBM DB2. Отхвърлени DB2 LUW функции. Обявяване на добавки за контрол на данните

Реализации

История

Особености

Обработка на грешка

Полета на структурата на SQLCODE и техните стойности

Бележки

Връзки

Литература

Вижте какво е "IBM DB2" в други речници:

Входна точка

Удостоверяване

Упълномощаване

Серия съдържание:

Това съдържание е част # от серия # статии: Общ преглед на DB2 LUW

Сурови материалии информация за контакт

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

Отхвърлени DB2 LUW функции

Целта на подготовката на тази поредица от статии

DB2 LUW функционалност

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

Опции за конфигурация на DB2

Организация на съхранението на данни

Регистриране на транзакции

Организация на кеширане на данни

Използване на RAM

Управление на RAM при извършване на операции за сортиране

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

Видове обекти на бази данни

Схема

маси

Временни маси

Индекси

Последователности

Представителство

задейства

Съхранени процедури и функции

Системна директория

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

Транзакции

Брави

Нива на изолация

Заключение

Входна точка

Удостоверяване

Упълномощаване