DB2(w języku rosyjskim wymawia się „dibi two”, powszechna jest również kalka z angielskiego „dibi tu”) - rodzina produkty oprogramowania w zarządzaniu informacją w IBM.

Najczęściej mówiąc o DB2 mają na myśli system zarządzania relacyjnymi bazami danych DB2 Universal Database (DB2 UDB), opracowany i wydany przez IBM.

Czasami pojawia się pisownia „DB/2”, ale ta pisownia jest niepoprawna: w notacji IBM liczba w mianowniku ułamka oznacza platformę, a „/2” oznacza produkt dla systemu operacyjnego OS/2 (lub serii komputerów PS/2). Na przykład wersja DB2 for OS/2 została oznaczona jako „DB2/2”.

Realizacje

DB2 DBMS jest obecnie dostępny na następujących platformach:

• DB2 dla Linux, UNIX i Windows v9 dla platform AIX, HP-UX, Linux, Solaris, Windows i beta dla platformy Mac OS X
• DB2 dla systemu z/OS v9 dla platform z/OS i OS/390
• Serwer DB2 dla VSE i VM v7 dla platform z/VM i z/VSE
• DB2 dla i dla platformy IBM i (zintegrowane z systemem na poziomie sprzętu i oprogramowania)

W przeszłości wydano wersje serwera bazy danych DB2 dla OS/2, UnixWare, PTX.

Klienci DB2 DBMS, poza wymienionymi platformami, są wydawane lub zostały wydane w różnych wersjach również dla SINIX, IRIX, klasycznego Mac OS i MS-DOS, a także w wersja mobilna DB2 w każdym miejscu dla Windows CE, Palm OS, Symbian OS, Neutrino i maszyna wirtualna Jawa.

Obecnie oprócz komercyjnych produktów z rodziny IBM dystrybuuje również bezpłatną dystrybucję DB2 Express-C dla platform Linux (x86, x86-64, POWER), Windows (x86, x86-64), Solaris (x86-64), Mac OS X (x86-64 beta). Darmowa wersja ma ograniczenia w stosowaniu nie więcej niż jednego dwurdzeniowego procesora i 2 GB do działania SZBD pamięć o dostępie swobodnym(całkowita liczba procesorów i pamięci w systemie może być dowolna, ale zasoby przekraczające określone limity nie będą wykorzystywane przez SZBD).

Fabuła

DB2 ma długą historię i jest uważany przez niektórych za pierwszy DBMS wykorzystujący SQL.

Od 1975 do 1982 prototyp DB2 był rozwijany w IBM pod nazwą System Relational lub System R. Język SQL został po raz pierwszy zaimplementowany w IBM System R, ale system ten miał charakter badawczy, a produkt komercyjny, w tym SQL, został po raz pierwszy wydany przez Oracle w 1979 roku.

DB2 otrzymało swoją nazwę w 1982 roku wraz z pierwszym komercyjnym wydaniem dla SQL/DS, a następnie dla MVS o nazwie DB2. Przez długi czas wraz z „DB2” był używany wariant „Database 2”, również znak towarowy firmy IBM. Najwyraźniej miał to być drugi flagowy IBM DBMS po starym hierarchicznym IMS DBMS.

Rozwój DB2 sięga wczesnych lat 70-tych, kiedy to dr E.F. Codd, który pracował dla IBM, opracował teorię relacyjnych baz danych i opublikował model manipulacji danymi w czerwcu 1970 roku. Aby wdrożyć ten model, opracował język relacyjnych baz danych i nazwał go Alpha. IBM zdecydował się zlecić dalszy rozwój grupie programistów pozostających poza kontrolą dr Codda. Naruszając niektóre zasady modelu relacyjnego, zaimplementowali go jako „ustrukturyzowany język angielskiżądania”, w skrócie SEQUEL. Ponieważ SEQUEL był już zarejestrowanym znakiem towarowym, nazwa została skrócona do SQL - "Structured Query Language" i taka jest do dziś.

Tak więc, historycznie, DB2 ewoluował z DB2 for MVS (którego potomkiem jest DB2 for z/OS) i jego siostrzanego SQL/DS for VM (którego potomkiem jest DB2 Server for VSE i VM). Później inny zespół programistów w IBM zaimplementował serwer OS/2 EE Database Manager, który później przekształcił się w DB2 v2 dla OS/2, AIX, a następnie Windows, a następnie w DB2 UDB (jego potomkiem jest DB2 dla Linux, UNIX i Windows ). Inny zespół zakończył integrację architektury DB2 z wbudowaną bazą danych AS/400 (potomek - DB2 for i). IBM stopniowo zmierza w kierunku integracji wszystkich tych oddziałów.

Osobliwości

Cechami wyróżniającymi DB2 są dialekt Język SQL, który określa, z rzadkimi wyjątkami, czysto deklaratywne znaczenie konstrukcji językowych oraz zaawansowany wielofazowy optymalizator, który tworzy efektywny plan wykonywania zapytań na podstawie tych deklaratywnych konstrukcji. W przeciwieństwie do innych dialektów SQL, dialekt DB2 SQL praktycznie nie zawiera wskazówek dla optymalizatora, jest słabo rozwinięty (i przez długi czas był ogólnie nieobecny) językiem procedur składowanych, a zatem wszystko ma na celu zachowanie deklaratywnego stylu pisania zapytań. Jednocześnie język DB2 SQL jest kompletny obliczeniowo, to znaczy potencjalnie pozwala zdefiniować wszelkie obliczalne zależności między danymi źródłowymi a wynikiem w formie deklaratywnej. Osiąga się to między innymi dzięki wykorzystaniu wyrażeń tabelowych, rekurencji i innych zaawansowanych mechanizmów manipulacji danymi.

Ze względu na koncentrację IBM na rozwoju relacji i pozycję firmy w branży komputerowej, dialekt DB2 SQL ma znaczący wpływ na standardy ANSI/ISO SQL.

Procedury składowane nie są powszechnie stosowane w DB2 z tradycyjnymi językami programowania używanymi do pisania procedur składowanych. wysoki poziom(C, Java, PL/I, Cobol itp.), pozwala to programiście na łatwe sformatowanie tego samego kodu jako części aplikacji lub jako procedury składowanej, w zależności od tego, czy bardziej odpowiednie jest wykonanie go na kliencie lub na serwerze . DB2 obecnie implementuje również rozszerzenie proceduralne SQL dla procedur składowanych, zgodnie ze standardem ANSI SQL/PSM.

Optymalizator DB2 w dużym stopniu wykorzystuje statystyki dystrybucji tabel (jeśli proces zbierania danych został wykonany przez administratora danych), więc to samo zapytanie SQL może zostać przełożone na zupełnie inne plany wykonania w zależności od charakterystyki statystycznej przetwarzanych danych.

Ponieważ historycznie DB2 ewoluowało od systemów wieloużytkownikowych na komputerach mainframe, wiele uwagi w architekturze DB2 poświęca się kwestiom bezpieczeństwa i dystrybucji ról specjalistów zajmujących się DB2. W szczególności, w przeciwieństwie do wielu innych DBMS, DB2 ma oddzielne role dla administratora DBMS (odpowiedzialnego za konfigurację komponenty oprogramowania DB2 i ich optymalne wykonanie w system komputerowy) oraz administratora bazy danych (odpowiedzialnego za zarządzanie danymi w określonej bazie danych).

Wykorzystanie, w razie potrzeby, statycznego SQL w programach oraz koncepcji pakietów pozwala, w przeciwieństwie do większości innych DBMS, na wdrożenie takiego modelu bezpieczeństwa, gdy uprawnienia do wykonywania określonych operacji mogą być nadane programom aplikacyjnym w przypadku braku takich uprawnień dla użytkowników pracujących z tymi programami. W takim przypadku pozwala to zagwarantować brak możliwości pracy użytkownika z bazą danych z pominięciem programu użytkowego, jeśli użytkownik ma tylko uprawnienia do uruchamiania programu, a nie do samodzielnej manipulacji danymi.

W ramach koncepcji zwiększenia poziomu integracji narzędzi bezpieczeństwa w systemie komputerowym DB2 nie posiada własnych możliwości uwierzytelniania użytkowników, integracji z narzędziami systemu operacyjnego czy wyspecjalizowanymi serwerami bezpieczeństwa. W DB2 autoryzowani są tylko użytkownicy uwierzytelnieni przez system.

DB2 jest jedynym relacyjnym DBMS ogólnego przeznaczenia, który ma implementacje na poziomie sprzętu/oprogramowania (system IBM i; obsługa DB2 jest również zaimplementowana na sprzęcie typu mainframe IBM System z).

Nowoczesne wersje DB2 zapewniają rozszerzoną obsługę korzystania z danych XML, w tym operacje na poszczególnych elementach dokumentów XML.

Błąd przetwarzania

Przydatną funkcją DB2 SQL Server jest możliwość obsługi błędów. Służy do tego struktura SQLCA. Obszar komunikacji SQL- obszar łącza SQL), który zwraca informacje o błędach do aplikacji po każdym wykonaniu instrukcji SQL.

Pola struktury SQLCODE i ich wartości

Główna, ale nie zawsze użyteczna diagnostyka błędów zawarta jest w terenie SQLCODE(typ danych - liczba całkowita) wewnątrz bloku SQLCA. Może przyjmować następujące wartości:

• 0 oznacza sukces.
• Liczba dodatnia oznacza sukces z co najmniej jednym ostrzeżeniem. Na przykład +100 oznacza, że ​​nie znaleziono żadnych kolumn.
• Liczba ujemna oznacza awarię z błędem. Na przykład -911 oznacza wykryty wygasły interwał oczekiwania na blokadę (lub zakleszczenie) wyzwalający sekwencyjne wycofywanie.

SQLERRM(typ danych - ciąg 71 znaków). Zawiera Ciąg tekstowy z opisem błędu, jeśli pole SQLCODE jest mniejsze od zera.

SQLERRD(typ danych - tablica, 6 liczb całkowitych). Opisuje wynik wykonania ostatniej instrukcji SQL:

• 1 element - informacje wewnętrzne;
• 2. element - zawiera wartość pola typu SERIAL wygenerowaną przez serwer dla instrukcji INSERT lub dodatkowy kod błędu;
• 3. element - równa liczbie przetworzonych rekordów;
• 4 element - przybliżony koszt wykonania tego operatora;
• 5 element - przesunięcie błędu w rekordzie tekstowym instrukcji SQL;
• 6. element - informacje wewnętrzne.

Uwagi

Spinki do mankietów

• Strona programu w serwisie IBM
• DB2 na developerWorks — artykuły i szkolenia dotyczące DB2
• PlanetDB2 - Blogi DB2

Literatura

• Data K. Przewodnik po relacyjnym DBMS DB2. - M.: Finanse i statystyka, 1988. - 320 s. - ISBN 5-279-00063-9
• Zikopoulos P.K., Baklarz J., deRus D., Melnik R.B. DB2 w wersji 8: Oficjalny przewodnik = DB2 w wersji 8: Oficjalny przewodnik. - M.: KUDITS-OBRAZ, 2004. - 400 s. - ISBN 5-9579-0031-1
• Smirnov S.N. Praca z IBM DB2: samouczek. - M.: Helios, 2001. - 304 s. - ISBN 5-85438-007-2 (rekomendowany przez uczelnie UMO w regionie) bezpieczeństwo informacji jako pomoc dydaktyczna w specjalnościach „Zintegrowane Bezpieczeństwo Informacji Systemów Zautomatyzowanych” oraz „Bezpieczeństwo Komputerowe”)
• Susan Visser, Bill Wong. Naucz się DB2 Universal Database w 21 dni = Sams Naucz się DB2 Universal Database w 21 dni. - wyd. 2 - M.: Williams, 2004. - 528 s. - ISBN 0-672-32582-9
• Hook J., Harbus R., Snow D. Uniwersalny przewodnik po DB2 dla Windows NT®. - New Jersey: Prentice Hall PTR, 1999. - P. 504. - ISBN 0-13-099723-4

Fundacja Wikimedia. 2010 .

Zobacz, co „IBM DB2” znajduje się w innych słownikach:

IBM DB2- Developer (y) IBM Pierwsze wydanie 1983 (1983) ... Wikipedia

IBM DB2- DB2 ist ein kommerzielles relations Datenbank Management System (RDBMS) przez firmę IBM, która jest odpowiedzialna za zarządzanie systemem R i Grundlagen von E.F. Codd vom IBM Research z Jahr 1970 zurückgeht. Inhaltsverzeichnis 1 Eigenschaften 1.1… … Deutsch Wikipedia

IBM DB2- Développeur IBM Dernière wersja ... Wikipedia en Français

IBM DB2 Commonstore- Oprogramowanie DB2 CommonStore Archiving firmy IBM do zarządzania wiadomościami e-mail lub danymi SAP ERP. Część oferty IBM Information Management, która opiera się na platformie bazodanowej DB2. DB2 CommonStore jest jednym z kilku produktów, które są… … Wikipedia

W pracy przez jakiś czas miałem do czynienia z IBM DB2 DBMS. Dlatego Ponieważ system jest komercyjny, w Internecie nie ma zbyt wielu informacji w języku rosyjskim, więc postanowiłem opisać niektóre funkcje tego DBMS.

Punkt wejścia

Zacznijmy od punktu wejścia w DBMS. Na serwerze SQL punkt końcowy to instancja, w której oczywiście mogą istnieć osobne bazy danych, ale konfiguracja i model bezpieczeństwa są takie same dla całej instancji. W DB2 punkt wejścia wygląda tak - instancja (odpowiadająca określonemu portowi) - baza danych. Jednocześnie istnieje konfiguracja dla całej instancji i osobnej bazy danych.

Konfigurację instancji można wyświetlić za pomocą komendy db2:

Konfiguracja menedżera bazy danych

Typ węzła = Enterprise Server Edition z klientami lokalnymi i zdalnymi

Poziom wydania konfiguracji menedżera bazy danych = 0x0b00

Szybkość procesora (milisekunda/instrukcja) (CPUSPEED) = 2,912790e-07
Przepustowość komunikacji (MB/s) (COMM_BANDWIDTH) = 1.000000e+02

Maksymalna liczba jednocześnie aktywnych baz danych (NUMDB) = 8
Obsługa systemu sfederowanych baz danych (Sfederowanych) = TAK
Nazwa monitora procesora transakcji (TP_MON_NAME) =

Domyślne konto obciążenia zwrotnego (DFT_ACCOUNT_STR) =

Ścieżka instalacji Java Development Kit (JDK_PATH) = /home/db2inst1/sqllib/java/jdk32

Poziom przechwytywania błędów diagnostycznych (DIAGLEVEL) = 3
Poziom powiadomień (POZIOM POWIADOMIENIA) = 3
Ścieżka katalogu danych diagnostycznych (DIAGPATH) = /home/db2inst1/sqllib/db2dump

Domyślne przełączniki monitora bazy danych
Pula buforów (DFT_MON_BUFPOOL) = WYŁ

Gdzie zostaną określone parametry, ich znaczenie i dekodowanie. Możliwa jest również wersja skrócona:

zdobądź dbm cfg

Lub z zapytaniem:

Wybierz nazwę, wartość z sysibmadm.dbmcfg

Z ważne parametry możesz zauważyć:

• typ uwierzytelniania (AUTHENTICATION)
• domyślna ścieżka do tworzenia nowych baz danych (DFTDBPATH)
• wykrywanie serwerów sieciowych (DISCOVER)

Możesz wyświetlić ustawienia dla określonej bazy danych w następujący sposób:

połącz się z próbką(przykład - nazwa bazy danych)

pobierz konfigurację menedżera bazy danych

Lub z mniej więcej tym samym żądaniem co poprzednio:

wybierz nazwę, wartość z sysibmadm.dbcfg

Uwierzytelnianie

Dużą różnicą między DB2 a innymi DBMS jest model uwierzytelniania. Nie ma użytkowników wewnętrznych, takich jak SQL Server czy MySQL. Wszelkie uwierzytelnianie odbywa się za pomocą zewnętrznych w stosunku do DBMS (wtyczek ładowanych dynamicznie) – za pomocą systemu operacyjnego lub wtyczek zewnętrznych (Kerberos, GSS API). Typ uwierzytelniania jest ustawiany w parametrze AUTHENTICATION konfiguracji menedżera bazy danych. Domyślnie ustawiona jest wartość SERVER - nazwa użytkownika i hasło przekazywane są w postaci zwykłego tekstu, a poprawność tej pary jest sprawdzana przez system operacyjny. Jeżeli nazwa użytkownika i hasło są poprawne, to sprawdzane jest uprawnienie CONNECT dla użytkownika lub grup, do których jest członkiem (w tym specjalnej grupy PUBLIC, która obejmuje wszystkich uprawnionych użytkowników). Te uprawnienia można wyświetlić w tabeli SYSCAT.DBAUTH:

wybierz GRANTEE z SYSCAT.DBAUTH, gdzie CONNECTAUTH = "Y"

Dużym błędem konfiguracyjnym jest uwzględnienie typu uwierzytelniania KLIENT. W takim przypadku DB2 ufa uwierzytelnianiu łączącemu się klientowi, a jeśli PUBLIC ma uprawnienie CONNECT, każdy użytkownik może połączyć się z bazą danych i mieć dostęp do wszystkich danych, które posiada PUBLIC. Nazwa użytkownika jest pobierana z systemu operacyjnego. Oznacza to, że jeśli łączymy się przez Data Studio jako użytkownik Administrator, to wszystkie uprawnienia, które ten użytkownik. I w tym przypadku nie ma różnicy, z którego komputera uzyskano dostęp. Ten typ Zaleca się, aby uwierzytelnianie było włączone tylko wtedy, gdy istnieje bezpieczny kanał między serwerem a klientem, a inni klienci nie będą mogli połączyć się z DBMS.

Upoważnienie

Uprawnienia na poziomie instancji są zapisywane w konfiguracji menedżera bazy danych. Są to następujące przywileje:

• SYSADM
• SYSCTRL
• KONSERWACJA SYSTEMU
• SYSMON

Te uprawnienia są ustawiane poprzez określenie grupy, do której użytkownik wejdzie. W dbmcfg są to odpowiednio opcje SYSADM_GROUP , SYSCTRL_GROUP , SYSMAINT_GROUP i SYSMON_GROUP .

Następnie są uprawnienia specyficzne dla bazy danych. Są to uprawnienia, takie jak dostęp do bazy danych (CONNECTAUTH), tworzenie tabel (CREATETABAUTH), tworzenie procedur (EXTERNALROUTINEAUTH) i tak dalej. Te uprawnienia można wyświetlić w widoku SYSCAT.DBAUTH

I wreszcie uprawnienia dostępu do określonych danych - tabel, podprogramów i tak dalej. Wszystko tutaj jest dość banalne, ale z pewnymi osobliwościami.

Uprawnienia dostępu do tabeli można wyświetlić w widoku SYSCAT.TABAUTH. Typ nadanego uprawnienia jest przechowywany w osobnych kolumnach, w zależności od samego uprawnienia (SELECTAUTH, DELETEAUTH itp.). Nadając uprawnienie za pomocą polecenia GRANT dla uprawnień REFERENCES i UPDATE można również określić nazwy kolumn, na które dane uprawnienia zostaną rozszerzone. W takim przypadku informacje na ten temat można wyświetlić w widoku SYSCAT.COLAUTH

Uprawnienia do procedur (funkcji, procedur i metod) można przeglądać w SYSCAT.ROUTINEAUTH . Nie wszystko jest tu trywialne, w zależności od pól SPECIFICNAME i TYPENAME uprawnienia można nadawać wszystkim podprogramom danego schematu.

Jeśli czytelnikom spodoba się ten artykuł, jestem gotów porozmawiać o ochronie danych w DB2 za pomocą kontroli dostępu opartej na etykietach

Przegląd podstawowych pojęć i ogólny opis Architektury baz danych IBM DB2 dla platform Linux, Unix i Windows

Seria treści:

Ta treść jest częścią serii # artykułów: Przegląd 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=

Czekajcie na nowe artykuły z tej serii.

Surowy materiał i dane kontaktowe

Specjalne podziękowania dla Marka Barinshteina za poświęcenie czasu na korektę materiału artykułów, dbałość o szczegóły i cenne komentarze.

Główną częścią materiału artykułów jest dowolna interpretacja oficjalna dokumentacja db2. Przedstawione informacje zostały zrestrukturyzowane i przeformułowane, aby były zwięzłe i jednocześnie jak najbardziej przejrzyste. Odniesienia do źródeł użytych we wszystkich przypadkach znajdują się w tekście artykułów oraz w sekcji „Zasoby”.

W ramach cyklu artykułów planowany jest przegląd następujących zagadnień:

1. (artykuł, który aktualnie czytasz)
2. (instalacja, konfiguracja, diagnostyka, utworzyć kopię zapasową i regeneracja)
3. zaawansowane procedury administracyjne (przekazywanie informacji, optymalizacja wydajności, zarządzanie priorytetami realizacji);
4. narzędzia do budowy analitycznych hurtowni danych;
5. technologie analizy w pamięci — DB2 BLU;
6. masowo równoległe przetwarzanie danych analitycznych za pomocą DB2 DPF (Database Partitioning Feature);
7. rozproszone bazy danych (konfiguracje przełączania awaryjnego, replikacja danych i federacyjny dostęp do danych);
8. Możliwości klastrowania DB2 pureScale zapewniające odporność na błędy i skalowalność.

Artykuły z serii będą publikowane w miarę przygotowywania odpowiednich materiałów.

Rodzina produktów DB2

Nazwa "DB2" jest używana przez IBM dla całej rodziny produktów, które różnią się między sobą zarówno składem platform sprzętowych i programowych, na których są używane, jak i funkcjonalnością, architekturą i cechami technologicznymi. Różnice te wynikają ze ścisłej integracji większości produktów rodziny DB2 z: system operacyjny w których funkcjonują, a także specyfikę tych systemów operacyjnych.

Rodzina produktów DB2 obejmuje obecnie:

• DB2 dla Linux, Unix i Windows lub DB2 LUW - DBMS dla systemów Linux (RedHat, SuSE, Ubuntu), UNIX (AIX, HP-UX, Solaris) i Microsoft Windows, który jest tematem tego artykułu i innych artykułów z tej serii;
• DB2 dla systemu z/OS- DBMS dla systemu operacyjnego z/OS używanego na komputerach mainframe IBM System z;
• Serwer DB2 dla VSE i VM- DBMS do obsługi z/VM i z/VSE używany na komputerach mainframe IBM System z;
• DB2 dla i- DBMS dla systemu operacyjnego System i używanego na platformie IBM Power.

Każdy z wymienionych DBMS jest architektonicznie dostosowany do najbardziej wydajnego działania w odpowiednich systemach operacyjnych i zawiera swój własny zestaw narzędzi i narzędzi administracyjnych.

Terminologia używana w dokumentacji różnych systemów DBMS z rodziny DB2 nie jest jednolita, a te same terminy mogą mieć różne znaczenia dla różnych wariantów DB2: na przykład terminy „baza danych” i „przestrzeń tabel” mają różne znaczenia dla DB2 LUW i DB2 dla z/OS, ze względu na różnice architektoniczne między tymi typami DBMS.

Dlatego podczas pracy z zasobami informacyjnymi dedykowanymi dla DB2 konieczne jest wyraźne rozróżnienie, który z produktów z rodziny jest omawiany, aby uniknąć zamieszania i ewentualnych błędów.

Nieaktualne funkcje DB2 LUW

W takiej czy innej formie DB2 LUW istnieje na rynku od 1989 roku (rok wydania OS/2 1.10 Extended Edition, który zawierał komponent Database Manager - czyli relacyjny DBMS, który był podstawą DB2 LUW).

Podczas długiego rozwoju produktu niektóre pierwotnie opracowane funkcje zostały ponownie przemyślane i zastąpione inną implementacją lub całkowicie wyłączone z produktu ze względu na ich brak potrzeby. Dlatego podczas pracy z materiałami przygotowanymi dla starszych wersji DB2 (na przykład wersja 9.7) należy pamiętać, że niektóre funkcje opisane w tych materiałach mogą zostać zastąpione w nowszych wersjach DB2 (na przykład 10.5 i 11.1). Szczegółowe informacje o przestarzałych i zastąpionych funkcjach znajdują się w .

Najważniejsze zmiany dla administratorów i programistów to:

• zastąpienie przestarzałych graficznych narzędzi do zarządzania „Control Center”, „Task Center” i szeregu innych funkcjami bezpłatnego pakietu IBM Data Studio, a także funkcjami narzędzi zawartych w bezpłatnej edycji IBM Data Server Manager produkt;
• wycofanie Serwera administracyjnego DB2 (DAS), który był wymagany w przypadku starszych narzędzi administracyjnych;
• zastąpienie narzędzi zarządzania obciążeniem DB2 Governor i Query Patroller funkcją DB2 Workload Manager (DB2 WLM).

Cel przygotowania tej serii artykułów

Głównym celem napisania serii artykułów przeglądowych na temat IBM DB2 jest uzupełnienie braku materiałów na ten temat w języku rosyjskim. Rzeczywiście, pomimo dostępności tłumaczeń znacznej części dokumentacji na język rosyjski i dostępnych książek na temat DB2, nadal brakuje dostępnych informacji przeglądowych, które pozwoliłyby zainteresowanym czytelnikom zorientować się w funkcjach DB2, wbudowanych pod względem funkcjonalności i administracji.

Jednak intencją autora nie jest przygotowanie przeglądu wszystkich produktów z rodziny DB2 (patrz pasek boczny „Rodzina produktów DB2”), zamiast tego planowane jest skupienie się na wariancie DB2 dla systemów Linux, Unix i Systemy operacyjne Windows - tj. na produkcie DB2 LUW.

Czytelnicy zainteresowani praktyczny przewodnik aby rozpocząć pracę z DB2, polecam zapoznać się z swobodnie rozpowszechnianą książką „”, przetłumaczoną na język rosyjski. Ta książka zawiera wiele przykładów typowych operacji oprogramowania DB2, co ułatwia rozpoczęcie pracy zarówno z opisaną w niej wersją DB2 9.7, jak iz nowszymi wersjami DB2 (10.5 i 11.1). Podczas pracy z aktualnymi wersjami oprogramowanie DB2 należy pamiętać, że niektóre funkcje w wersji 9.7 są nieaktualne i nie są obsługiwane w nowych wersjach produktu (patrz pasek boczny „Nieaktualne funkcje DB2 LUW”).

Funkcjonalność DB2 LUW

IBM DB2 używa obecnie akceptowanego architektura klient-serwer relacyjny DBMS, z przechowywaniem informacji na serwerze i łączeniem aplikacji klienckich z bazami danych lokalnie lub przez sieć.

Aby zapewnić współbieżny dostęp do danych z aplikacji równoległych, DB2 używa mechanizmu transakcji opartego na blokowaniu i rejestrowaniu transakcji, aby zapewnić standardowe gwarancje ACID (atomowość, spójność, izolacja, trwałość). Mechanizm ten przeszedł długą drogę ewolucji, aby zapewnić maksymalną wydajność, niezawodność i zminimalizować opóźnienia w wykonywaniu aplikacji.

DB2 zapewnia obsługę wszystkich popularnych standardów branżowych dotyczących dostępu do danych aplikacji, w tym języka standardowego Zapytania SQL, interfejsy ODBC i JDBC, praca z typowymi formatami tabel tekstowych itp. Ponadto DB2 zawiera zaawansowane możliwości przechowywania i pracy z częściowo ustrukturyzowanymi danymi w formaty XML, JSON/BSON. W przypadku tworzenia procedur zapisanych w bazie DB2 zapewnia obsługę różnych języków proceduralnych, w tym:

• standard dla języka DB2 SQL PL,
• język SQL/PL używany w DBMS Oracle,
• możliwość tworzenia „zewnętrznych” procedur składowanych w językach Java, C, C++ i COBOL.

Charakterystyczne cechy DB2 to:

• skalowalność, ograniczona jedynie dostępnymi zasobami obliczeniowymi oraz najbardziej ekonomiczne wykorzystanie zasobów obliczeniowych;
• potężne wbudowane środki różnicowania i kontroli dostępu, które zapewniają możliwość granularnego ograniczania dostępu do informacji w kontekście obiektów (tabele, widoki), a także wdrożenie modelu obowiązkowej kontroli dostępu;
• zaawansowany zintegrowany system tworzenia kopii zapasowych i odzyskiwania danych;
• dostępność pełnego zestawu technologii do budowy „klasycznych” hurtowni danych analitycznych (podział tabel na sekcje, zmaterializowane widoki, optymalizacja buforowania danych i skanowania tabel i indeksów, „wewnętrzna” równoległość w realizacji złożonych zapytań itp.);
• obsługa tworzenia konfiguracji masowo równoległego przetwarzania danych analitycznych (MPP) z wielu serwerów połączonych siecią komunikacyjną w oparciu o opcję DB2 Database Partitioning Feature (DB2 DPF);
• maksymalna odporność na błędy i niemal liniowe skalowanie konfiguracji klastrowych DB2 pureScale z danymi przechowywanymi na dyskach współużytkowanych;
• Technologia DB2 BLU implementująca obsługę nowoczesnej analityki „kolumnowej” w pamięci bez konieczności ręcznej optymalizacji struktury bazy danych.

Aby ułatwić migrację aplikacji z innych typów DBMS (głównie bazy danych Oracle), DB2 udostępnia zaawansowane narzędzia zgodności, w tym obsługę niezbędnych typów danych, procedur zapisanych w bazie i standardowych widoków systemowych.

Istnieje kilka edycji produktu DB2 LUW, połączonych jednym zestawem podstawowych funkcji i różniących się między sobą ograniczeniami wykorzystywanych zasobów obliczeniowych oraz obsługą zaawansowanych funkcjonalności. Wersja DB2 Express-C, która jest dostępna bezpłatnie, może być używana do oceny produktów, nauki, a nawet małych wdrożeń produkcyjnych. Funkcjonalność i ograniczenia zasobów różnych edycji DB2 LUW są szczegółowo opisane w artykule "".

Struktura serwera bazy danych

Serwer bazy danych DB2 to komputer, na którym zainstalowano oprogramowanie serwera DB2 (silnik DB2) i który udostępnia usługi zarządzania informacjami strukturalnymi.

Dostęp do usług DB2 przez aplikacje zapewnia oprogramowanie klienckie DB2 (IBM Data Server Driver Package), które komunikuje się z serwerem DB2 zgodnie z obsługiwanymi metodami połączenia aplikacji (w tym ODBC, JDBC, OLE DB, ADO, CLI i innymi) . W większości przypadków wymagane oprogramowanie klienckie jest instalowane z serwerem DB2, umożliwiając aplikacjom hostowanym bezpośrednio na serwerze bazy danych łączenie się z serwerem DB2.

Serwer bazy danych DB2 może obsługiwać wiele kopii oprogramowania DB2 z różnymi wersjami oprogramowania i katalogami instalacyjnymi. Wiele kopii oprogramowania DB2 może znajdować się niezależnie na tym samym serwerze, o ile nie występują między nimi konflikty zasobów (w tym wystarczające zasoby obliczeniowe serwera i brak konfliktów dotyczących zasobów logicznych systemu operacyjnego: nazw sieci, numerów portów, katalogów systemu plików itp. wł.).

Bezpośrednie udostępnianie usług DBMS zapewnia komponent menedżera bazy danych DB2 (DB2 DBM). Każda kopia może mieć wiele instancji menedżera bazy danych DB2 lub, w skrócie, instancji DB2. Instancja to niezależne środowisko, w którym można tworzyć bazy danych i uruchamiać aplikacje. Każda instancja DB2 ma własną konfigurację i zapewnia dostęp do określonego zestawu baz danych. Instancje DB2 są niezależne w tym sensie, że wykonywanie operacji na jednej instancji nie wpływa na inne, z wyjątkiem ograniczeń zasobów wynikających z uruchamiania wielu instancji na tym samym serwerze fizycznym lub wirtualnym.

Uruchamianie i zatrzymywanie usług DB2 odbywa się na poziomie instancji, tj. każda instancja DB2 może być uruchomiona lub zatrzymana. Parametry instancji DB2 mogą określać jej limity zasobów (na przykład pod względem wykorzystania pamięci). Zasoby instancji DB2 są używane do obsługi baz danych istniejących w instancji.

Baza danych to zbiór obiektów tworzących pojedynczą tablicę informacyjną (tabele, widoki, indeksy itp.). Bazy danych są niezależnymi jednostkami i w związku z tym zazwyczaj nie współużytkują obiektów z innymi bazami danych (wyjątkiem mogą być konfiguracje rozproszonych baz danych, które używają mechanizmów federacyjnych dostępu do danych).

Schematyczny przykład struktury serwera bazy danych pokazano na rysunku.

W wielu przypadkach serwer bazy danych DB2 zawiera pojedynczą instalację DB2 z jedną utworzoną instancją obsługującą pojedynczą bazę danych. W tej konfiguracji wszystkie zasoby serwera bazy danych są używane do uruchamiania pojedynczej bazy danych DB2.

Obsługa żądań z podłączonych aplikacji po stronie serwera bazy danych jest wykonywana przez tzw. agentów DB2. Dla każdej połączonej aplikacji w instancji DB2 uruchamiany jest agent koordynujący (podstawowy), który w razie potrzeby może uruchomić kilka dodatkowych (pomocniczych) agentów. Z technicznego punktu widzenia każdy agent jest oddzielnym wątkiem wykonania lub (w przypadku starszych wersji DB2) oddzielnym procesem systemu operacyjnego, z powiązanymi zasobami potrzebnymi do jego uruchomienia.

Opcje konfiguracji DB2

Konfigurację serwera DB2 można ustawić na czterech różnych poziomach:

• Zmienne środowiska;
• rejestr profili DB2;
• plik konfiguracyjny menedżera bazy danych (DBM CFG);
• plik konfiguracyjny bazy danych (DB CFG).

Zmienne środowiskowe są ustawiane na poziomie systemu operacyjnego serwera oraz za pomocą systemu operacyjnego. W przypadku systemu operacyjnego Windows te zmienne są w rzeczywistości globalne dla serwera, w przypadku systemów operacyjnych z rodzin Unix i Linux ich specyficzne ustawienia zmiennych środowiskowych można ustawić dla każdej instancji.

Ustawienia rejestru profilu DB2 można ustawić na poziomie systemu operacyjnego (globalnie) lub na poziomie instancji, przy czym ustawienia na poziomie instancji zastępują ustawienia ustawione na poziomie systemu operacyjnego. Przeglądanie i ustawianie wartości rejestru profilu DB2 odbywa się za pomocą komendy db2set.

Opcje pliku konfiguracyjnego menedżera bazy danych są definiowane na poziomie instancji, natomiast opcje konfiguracyjne bazy danych są definiowane na poziomie bazy danych.

Wiele parametrów jest dynamicznych, tj. wprowadzone zmiany zaczynają obowiązywać natychmiast; istnieją jednak ustawienia, które wymagają zatrzymania i uruchomienia instancji w celu zmiany. Można to zrobić w wierszu komend za pomocą komend db2stop i db2start. Wszystkie aplikacje muszą zostać zamknięte przed zatrzymaniem instancji. Aby wymusić zatrzymanie instancji, można użyć komendy db2stop force.

Plik konfiguracyjny menedżera bazy danych zawiera ustawienia, które wpływają na instancję i wszystkie zawarte w niej bazy danych. Plik konfiguracyjny menedżera bazy danych można przeglądać lub modyfikować za pomocą wiersz poleceń(za pomocą poleceń GET DBM CFG i UPDATE DBM CFG), a także narzędzi IBM Data Studio.

Plik konfiguracyjny bazy danych zawiera opcje, które wpływają na konkretną bazę danych. Plik konfiguracyjny bazy danych można wyświetlić lub zmodyfikować za pomocą wiersza komend (komendy GET DB CFG i UPDATE DB CFG) oraz programu IBM Data Studio.

Szczegółowy opis obsługiwanych , jak również znajduje się w oficjalnej dokumentacji DB2.

Organizacja przechowywania danych

Najmniejszą fizyczną jednostką pamięci w DB2 jest strona. Dozwolone rozmiary stron to 4K, 8K, 16K i 32K. Informacje o obiektach bazy danych (takie jak wpisy w tabelach i wpisy indeksu) są umieszczane na stronach.

Przydział dodatkowej przestrzeni do przechowywania danych jest przydzielany przez grupy stron, które nazywane są zakres. Wykonywanie dodatkowych operacji alokacji miejsca na poziomie zakresu poprawia wydajność wstawiania i aktualizowania rekordów.

Przechowywanie informacji w bazach danych DB2 jest zorganizowane w obiekty zwane przestrzenie tabel. Obszar tabel to nazwany zestaw kontenerów do przechowywania informacji umieszczonych w systemie plików serwera bazy danych.

Dla każdego obszaru tabel tworzony jest jeden lub więcej obszarów tabel. pojemniki(pliki lub katalogi w systemie plików) do przechowywania informacji, a także ustawić rozmiar strony i obszar do buforowania danych (pula buforów, patrz poniżej), a także szereg innych parametrów.

Istnieją następujące typy przestrzeni tabel:

• zwykły: używany do hostowania tabel i indeksów użytkowników;
• wielki: Służy do hostowania tabel i indeksów użytkowników, a także danych dużych obiektów (LOB) i danych XML. We współczesnych wersjach DB2 domyślnie używane są duże przestrzenie tabel zamiast zwykłych;
• tymczasowy: służy do przechowywania tymczasowych informacji podczas wykonywania zapytań (systemowych tymczasowych obszarów tabel) i tabel tymczasowych zdefiniowanych przez aplikacje (tymczasowe obszary tabel użytkownika).

Typ obszaru tabel jest określany podczas jego tworzenia i nie można go zmienić, chyba że przez usunięcie i ponowne utworzenie obszaru tabel.

Przestrzenie tabel można również klasyfikować według typu kontrolki ustawionego podczas tworzenia obszaru tabel:

• przestrzenie tabel zarządzane przez system (SMS, System Managed Storage) - katalogi są używane jako kontenery przestrzeni tabel, pliki danych są tworzone w celu umieszczania obiektów pamięci masowej w katalogach. Miejsce nie jest wstępnie przydzielane, pliki rosną dynamicznie. Po zdefiniowaniu kontenery są ustalane w momencie ich tworzenia;
• przestrzenie tabel zarządzane przez bazę danych (DMS, Database Managed Storage) - wstępnie przydzielone pliki są używane jako kontenery przestrzeni tabel, kontenery można dodawać, usuwać lub zmieniać;
• automatycznie zarządzane przestrzenie tabel (automatyczne przechowywanie) - automatyczne wykrywanie typu i lokalizacji kontenera w zależności od typu przestrzeni tabel (DMS dla zwykłych i dużych przestrzeni tabel, SMS dla tymczasowych przestrzeni tabel). Konkretne definicje kontenerów nie są określone podczas tworzenia obszaru tabel, niezbędne kontenery są tworzone automatycznie. Rozwój istniejących kontenerów i dodawanie nowych kontenerów jest całkowicie kontrolowany przez DB2.

Aby włączyć automatyczne zarządzanie obszarami tabel, musisz najpierw utworzyć bazę danych z włączoną automatyczną pamięcią (co jest ustawieniem domyślnym) i powiązać z nią zestaw ścieżek pamięci.

Domyślnie DB2 zapisuje sekwencyjnie do ekstentów, „rozbierając” między kontenerami. Na przykład, jeśli masz obszar tabel o rozmiarze strony 4 KB i rozmiarze ekstentu 8 stron i używasz 3 bezpośrednich kontenerów w obszarze tabel DMS, oznacza to, że 32 KB danych (4 KB x 8 stron w ekstent = 32 KB) zostanie zapisany na jednej płycie przed rozpoczęciem nagrywania do następnej.

Począwszy od DB2 w wersji 10.1 wprowadzono nową koncepcję upraszczającą zarządzanie pamięcią masową danych − grupa magazynowa(grupa magazynowa). Grupa pamięci masowej to nazwana kolekcja ścieżek w systemie plików serwera DBMS, której można używać do przechowywania danych. Skład grup pamięci masowej w bazie danych zazwyczaj definiuje zestaw typów urządzeń pamięci masowej dostępnych do przechowywania informacji. Podczas tworzenia bazy danych domyślna grupa magazynów jest zawsze automatycznie tworzona w bazie danych.

Każdy automatycznie zarządzany obszar tabel jest powiązany z jedną z utworzonych grup pamięci, co określa fizyczne położenie danych przechowywanych w odpowiednich obszarach tabel. Obszar tabel można przenieść z jednej grupy pamięci do innej za pomocą komendy ALTER TABLESPACE ... USING STOGROUP ... .

Rejestrowanie transakcji

IBM DB2 LUW, podobnie jak większość innych nowoczesnych relacyjnych systemów DBMS, które zapewniają gwarancje ACID, używa dziennika transakcji jako jednego z podstawowych mechanizmów egzekwowania tych wymagań.

Operacje modyfikacji danych wykonywane przez DB2 są rejestrowane w dzienniku transakcji jako seria wpisów dziennika. Każda baza danych posiada własny dziennik transakcji, który jest sekwencją plików na dysku. Wielkość pojedynczego pliku określa parametr LOGFILSIZ, liczbę początkowo utworzonych plików określa parametr LOGPRIMARY. W razie potrzeby DB2 może utworzyć dodatkowe pliki log, maksymalna liczba tworzonych plików jest kontrolowana przez parametr LOGSECOND.

Informacje są zapisywane w dzienniku transakcji za pomocą specjalnego bufora w pamięci RAM. Zawartość bufora jest opróżniana na dysk (do plików dziennika transakcyjnego) w miarę zapełniania się bufora, a także po potwierdzeniu lub anulowaniu transakcji (przez polecenie aplikacji lub po nieprawidłowym zamknięciu połączenia z aplikacją).

Plik dziennika transakcji, który jest wymagany do odzyskania danych po awarii, nazywany jest aktywnym plikiem dziennika. Aktywne pliki dziennika transakcji muszą być zawsze dostępne dla menedżera bazy danych DB2. Ponieważ dostępność plików dziennika transakcji ma kluczowe znaczenie dla zapewnienia wydajności DBMS, przewidziano mechanizm do dublowania dzienników transakcji na dwóch systemy plików(konfigurowalne za pomocą parametru LOGMIRROR).

W przypadku wybrania złego rozmiaru i liczby plików dziennika transakcji, które nie odpowiadają poziomowi aktualnego obciążenia, mogą wystąpić sytuacje przepełnienia dziennika transakcji z powodu niewystarczającej liczby plików dziennika dopuszczonych do utworzenia lub braku do dyspozycji miejsca na dysku. W zależności od ustawień bazy danych (patrz parametr BLK_LOG_DSK_FUL) do aplikacji może zostać zwrócony odpowiedni komunikat o błędzie lub przetwarzanie może zostać wstrzymane do czasu rozwiązania sytuacji przez administratora.

Również sytuacje przepełnienia dziennika transakcji mogą wystąpić w przypadku długotrwałych transakcji, które wykonują operacje modyfikacji danych. Nawet jeśli taka długotrwała transakcja powoduje pojedynczą, niewielką zmianę w bazie danych, która następnie pozostaje niezatwierdzona przez długi czas, odpowiedni plik dziennika transakcji pozostaje aktywny i nie można go ponownie wykorzystać.

Istnieją dwa główne tryby działania rejestrowania transakcyjnego DB2: rejestrowanie cykliczne i rejestrowanie archiwalne. W trybie rejestrowania cyklicznego DB2 cyklicznie przegląda wygenerowany zestaw plików dzienników transakcyjnych. W trybie rejestrowania archiwum DB2 opcjonalnie kopiuje pliki dziennika transakcji do archiwum przy użyciu metod określonych przez parametry LOGARCHMETH1 i LOGARCHMETH2.

Tryb rejestrowania cyklicznego zapewnia przywrócenie integralności bazy danych w przypadku awarii serwera DBMS. Tworzenie kopii zapasowej takiej bazy danych jest możliwe dopiero po wyłączeniu wszystkich aplikacji (czyli z zawieszeniem dostępu użytkownika). Odzyskiwanie danych z utworzyć kopię zapasową możliwe tylko przy doprowadzeniu bazy danych do stanu z chwili wykonania kopii zapasowej.

Tryb rejestrowania archiwum zapewnia również przywrócenie integralności bazy danych w przypadku awarii serwera DBMS. Dodatkowo można wykonać kopię zapasową bazy danych bez przerywania dostępu użytkowników i uwzględnić w kopii aktywne pliki dziennika (niezbędne do przywrócenia integralności danych). Uzupełnieniem przywracania danych z kopii zapasowej może być zastosowanie zmian wprowadzonych w bazie danych od momentu wykonania kopii zapasowej i doprowadzenie bazy do stanu w wybranym momencie w przeszłości (ale nie wcześniej niż w momencie wykonania kopii zapasowej).

Tryb rejestrowania archiwum wymaga dodatkowych zasobów do wykonywania operacji archiwizacji, w tym zwiększonej liczby operacji we/wy i dodatkowego miejsca na dysku do przechowywania zarchiwizowanych plików dzienników transakcyjnych.

Organizacja buforowania danych

Aby zmniejszyć ilość wykonywanych operacji we/wy, DB2, podobnie jak inne współczesne relacyjne DBMS, buforuje odczyty i zapisy wykonywane w przestrzeniach tabel. Buforowanie odbywa się za pomocą obszarów pamięci RAM zwanych pulami buforów. W DB2 można zdefiniować kilka różnych pul buforów (utworzonych za pomocą komendy CREATE BUFFERPOOL) z włączonymi parametrami wielkości i wielkości strony oraz automatycznej kontroli wielkości. Każdy obszar tabel jest odwzorowany na określoną pulę buforów, a pojedyncza pula buforów może być współużytkowana przez wiele obszarów tabel.

Podczas wykonywania operacji odczytu najpierw wyszukuje żądaną stronę z danymi w puli buforów. Jeśli wymagana strona zostanie znaleziona, dane są odczytywane z puli buforów, w przeciwnym razie strona jest ładowana z dysku do puli buforów. Dostępny jest mechanizm asynchronicznego wstępnego pobierania stron do puli buforów w przypadku wykrycia liniowego (przewidywalnego) charakteru dostępu do stron. Mechanizm prefetchingu w wielu przypadkach skraca czas oczekiwania na operacje odczytu niezbędnych danych z dysku poprzez wykonywanie odczytów w trybie asynchronicznym.

Gdy wykonywana jest operacja zapisu, dostrajanie strony jest wykonywane bezpośrednio w puli buforów. W takim przypadku strona nie jest zapisywana na dysku w trybie synchronicznym, a bezpieczeństwo danych zapewnia mechanizm logowania transakcyjnego. Zmienione strony obszaru tabel są zapisywane na dysku asynchronicznie, w tle i zapewniają rozsądną minimalizację ilości pracy, która może być wymagana do przywrócenia stanu bazy danych, gdy jest ona nienormalnie (nieprawidłowo) zamknięta. Prawidłowe zamknięcie bazy danych (na przykład podczas regularnego wyłączania serwera DBMS) zapewnia, że ​​wszystkie zmodyfikowane strony wszystkich pul buforów zostaną zapisane na dysku.

Wykorzystanie pamięci RAM

Model pamięci DB2 składa się z różne obszary pamięć na poziomie instancji DB2, bazy danych, aplikacji i agenta.

Szczegółowy opis obszarów pamięci masowej DB2 znajduje się poniżej krótki opis spotkania z różnych dziedzin.

Lista głównych obszarów pamięci masowej DB2 jest pokazana na poniższym rysunku (pierwotnie zaczerpnięta z ).

Całkowita pamięć używana przez instancję DBMS obejmuje:

• Monitor Heap - obszar pamięci do monitorowania operacji i stanu, wielkość jest regulowana przez parametr MON_HEAP_SZ;
• FCM Buffers - obszar pamięci do interakcji między agentem koordynującym i jego podagentami, a także do zapewnienia interakcji wewnętrznych w partycjonowanych bazach danych;
• Bufor audytu to obszar pamięci, w którym zapisy audytu są umieszczane przed opróżnieniem do dziennika audytu.

Na poziomie bazy danych zwyczajowo rozróżnia się:

• globalny obszar bazy danych, często określany jako obszar „pamięci wydajności”, który obejmuje różne obszary pamięci podręcznej i obszar blokowania;
• obszar danych aplikacji, często nazywany „pamięcią funkcjonalną”, który obejmuje różne obszary pamięci roboczej agentów obsługujących połączenia z bazą danych.

Globalny obszar bazy danych składa się z następujących głównych komponentów:

• Pule buforowe - pule buforowe, tj. obszary do buforowania danych obszaru tabel;
• Lista blokad - obszar do przechowywania informacji o blokadach, których wielkość jest kontrolowana przez parametr LOCKLIST;
• Pamięć podręczna pakietów - obszar buforowania planów wykonania zapytań, wielkość jest regulowana parametrem PCKCACHESZ;
• Pamięć podręczna katalogu - obszar buforowania katalogu systemowego, w którym znajdują się opisy wszystkich obiektów bazy danych, wielkość jest regulowana parametrem CATALOGCACHE_SZ;
• Sterta narzędziowa - pamięć RAM do wykonywania operacji konserwacji bazy danych (w tym operacji tworzenia kopii zapasowych i przywracania), wielkość jest regulowana parametrem UTIL_HEAP_SZ;
• Sterta bazy danych - pamięć RAM do obsługi operacji bazodanowych (m.in. bufor dziennika transakcji oraz pamięć podręczna przyspieszająca dostęp do katalogu systemowego, a także bufor audytu na poziomie bazy danych), wielkość regulowana jest parametrem DBHEAP.

Całkowity rozmiar obszaru globalnej bazy danych jest ograniczony przez ustawienie DATABASE_MEMORY.

Obszar danych aplikacji obejmuje:

• Pamięć globalna aplikacji - wspólne obszary pamięci współdzielone podczas przetwarzania żądań aplikacji, maksymalna ilość jest regulowana przez parametr APPL_MEMORY;
• Pamięć prywatna agenta - prywatne obszary pamięci wykorzystywane do działania poszczególnych agentów obsługujących połączone aplikacje.

Opcjonalnie można przydzielić obszary pamięci, które są przydzielone do uruchamiania sterownika DB2 po stronie aplikacji. W przypadku aplikacji lokalnych (tych, które używają IPC zamiast dostępu do sieci do łączenia się z menedżerem bazy danych), ustawione ustawienia DB2 kontrolują ilość przydzielanej pamięci RAM (głównie ustawienie ASLHEAPSZ).

Zarządzanie pamięcią RAM podczas wykonywania operacji sortowania

Wiele typów operacji DBMS wymaga sortowania danych, dlatego szczególną uwagę zwraca się na zarządzanie pamięcią RAM wykorzystywaną do sortowania.

Jeśli niemożliwe jest przydzielenie obszaru sortowania w całości w pamięci RAM, dane do sortowania są umieszczane w systemowej tymczasowej przestrzeni tabel. Wydajność zapytań wymagających tak dużych operacji sortowania może ulec znacznemu pogorszeniu.

Parametry sterujące przydzielaniem pamięci RAM do sortowania:

• SORTHEAP - limit pamięci dla operacji sortowania;
• SHEAPTHRES - limit rozmiaru prywatnej pamięci agenta przydzielonej do operacji sortowania;
• SHEAPTHRES_SHR - limit całkowitej ilości pamięci RAM, która może być użyta do wykonania operacji sortowania (łącznie przez wszystkich konsumentów) w danym momencie.

DB2 obsługuje trzy podstawowe modele zarządzania pamięcią sortowania:

• Model współdzielonego sortowania (shared sort) – stosowany domyślnie, implikuje ustawienie parametru SHEAPTHRES na 0. Przydział pamięci RAM do sortowania odbywa się z globalnego obszaru bazy danych.
• Model obszaru sortowania prywatnego (sortowanie prywatne) - stosowany, gdy parametr SHEAPTHRES jest niezerowy i nie jest skonfigurowany pamięć współdzielona sortowanie. Przydział pamięci RAM do sortowania odbywa się z obszaru danych aplikacji (dokładniej z obszarów prywatnych należących do agentów).
• Hybrydowy model sortowania (sortowanie hybrydowe) - stosowany, gdy parametr SHEAPTHRES jest niezerowy i istnieje skonfigurowana współdzielona pamięć sortowania. Operacje wymagające użycia współdzielonej pamięci sortowania wykonywane są z alokacją pamięci w globalnym obszarze bazy danych, pozostałe operacje sortowania wykonywane są z alokacją pamięci w prywatnych obszarach agentów.

Używanie pamięci współdzielonej (globalnej) do wykonywania operacji sortowania zapewnia szereg ważnych korzyści:

• bardziej elastyczne zarządzanie pamięcią RAM podczas wykonywania zapytań, pozwalające na zwiększenie efektywności wykorzystania pamięci RAM;
• możliwość zastosowania równoległej wersji algorytmu sortowania dzięki równoczesnemu dostępowi do obszaru pamięci sortowania agenta koordynującego i jego pod-agentów DB2.

Jedno z następujących ustawień może służyć do włączenia korzystania z pamięci współdzielonej podczas wykonywania operacji sortowania:

• ogólny model obszaru sortowania włącza się ustawiając parametr SHEAPTHRES na 0;
• równoległość wykonywania operacji umożliwia ustawienie parametru INTRA_PARALLEL na TAK;
• zmienna DB2_WORKLOAD jest ustawiona na ANALYTICS;
• opcja DB2 Connection Concentrator jest włączona (zwykle używana podczas uzyskiwania dostępu do baz danych DB2 for z/OS i DB2 for i, zobacz opis tej opcji w ).

Automatyczne zarządzanie alokacją pamięci

Obecność dużej liczby różnych obszarów pamięci RAM i parametrów regulujących ich wielkość może wymagać znacznego wysiłku w celu ręcznego dostrojenia serwera DB2. Dlatego, począwszy od wersji 9, IBM DB2 obsługuje automatyczne zarządzanie dystrybucją pamięci RAM między różnymi obszarami za pomocą menedżera samodostrajania pamięci (STMM, Self-Tuning Memory Manager).

Gdy ładowanie początkowe jest włączone, STMM dynamicznie przydziela dostępne zasoby pamięci konsumentom pamięci w bazie danych. STMM reaguje na zmiany w charakterystyce obciążenia, dostosowując wartości parametrów konfiguracji pamięci i rozmiar pul buforów w celu optymalizacji wydajności. Aby włączyć STMM, należy ustawić parametr konfiguracyjny bazy danych SELF_TUNING_MEM na ON.

Automatyczne zarządzanie alokacją pamięci jest przeprowadzane dla tych obszarów pamięci, dla których zostało to wyraźnie dozwolone. Podczas ustawiania wartości parametru konfiguracyjnego za pomocą komend UPDATE DBM CFG i UPDATE DB CFG, aby użyć STMM, słowo kluczowe AUTOMATIC jest podawane po wartości parametru. Wartość liczbowa parametru określonego w tym przypadku jest używana jako wartość początkowa, a następnie STMM okresowo dostosowuje wartości, biorąc pod uwagę bieżące obciążenie, redystrybuując pamięć RAM między różnymi konsumentami.

Automatyczne zarządzanie STMM jest obsługiwane dla następujących opcji:

• INSTANCE_MEMORY to całkowita ilość pamięci RAM w instancji DB2;
• DATABASE_MEMORY - globalne obszary bazy danych;
• DBHEAP - obszar do obsługi operacji bazodanowych;
• LOCKLIST – zakres przechowywania danych o blokadach;
• MAXLOCKS - procent pamięci zajmowanej przez blokady jednej aplikacji do przełączenia na eskalację blokady;
• PCKCACHESZ - obszar buforowania planów wykonania zapytań;
• SHEAPTHRES_SHR - ogólny obszar sortowania;
• SORTHEAP - sortuj wielkość obszaru dla jednej operacji;
• APPL_MEMORY - obszar pamięci funkcjonalnej;
• APPLHEAPSZ - limit pamięci prywatnej używany przez jednego agenta;
• STMTHEAP - ograniczenie wielkości obszaru wykorzystywanego przez kompilator zapytań SQL i XQuery (na zapytanie);
• STAT_HEAP_SZ to maksymalna ilość pamięci RAM przydzielonej do budowania statystyk przez narzędzie RUNSTATS i przydzielonej z obszaru pamięci funkcjonalnej.

Rodzaje obiektów bazy danych

Ta sekcja zawiera przegląd typów obiektów bazy danych DB2. Pełną listę typów obiektów bazy danych DB2 oraz szczegółowe informacje na temat każdego typu obiektu można znaleźć w dokumentacji DB2:

Schemat

Schematy to przestrzenie nazw służące do gromadzenia obiektów bazy danych. Schematy są używane głównie do:

• wskazanie własności obiektów lub linków do aplikacji;
• logiczne grupowanie powiązanych obiektów.

Wszystkie obiekty bazy danych DB2 (z wyjątkiem ogólnych synonimów) mają w pełni kwalifikowane dwuczęściowe nazwy; schemat jest pierwszą częścią takiej nazwy:<имя_схемы>.<имя_объекта>

W pełni kwalifikowana nazwa obiektu musi być unikatowa. Jeśli łączysz się z bazą danych i tworzysz obiekt lub uzyskujesz do niego dostęp bez określania schematu, DB2 użyje identyfikatora użytkownika, który nawiązał połączenie z bazą danych jako nazwy schematu. Możesz również użyć instrukcji SET SCHEMA, aby ustawić schemat dla bieżącej sesji.

Tworzenie schematu można wykonać jawnie, wywołując instrukcję CREATE SCHEMA, lub niejawnie przy pierwszej próbie utworzenia obiektu bez określania nazwy schematu. W tym drugim przypadku, aby pomyślnie utworzyć schemat, użytkownik musi otrzymać uprawnienie IMPLICIT_SCHEMA.

Synonimy można tworzyć dla większości rodzajów obiektów bazy danych, umożliwiając odwoływanie się do oryginalnych obiektów pod inną nazwą (być może umieszczane w innym schemacie). Synonimy tworzy się za pomocą instrukcji CREATE SYNONYM / CREATE ALIAS. Obsługuje również pracę z publicznymi synonimami, które nie są powiązane z określonym schematem. Dostęp do publicznych synonimów odbywa się bez określania schematu, niezależnie od ustalonego aktualnego schematu sesji. Synonimy publiczne tworzy się za pomocą polecenia CREATE PUBLIC SYNONYM / CREATE PUBLIC ALIAS.

stoły

Tabela to zbiór powiązanych danych uporządkowanych logicznie w kolumnach i wierszach.

Każdy wiersz tabeli składa się z tego samego zestawu nazwanych kolumn. Podczas tworzenia tabeli każdej kolumnie przypisywany jest typ danych, który ogranicza dopuszczalne wartości kolumn w wierszach tabeli (rekordy bazy danych) i określa semantykę możliwych operacji na odpowiednich wartościach (w tym porównywanie, sortowanie, operacje obliczeniowe).

Tabela jest tworzona za pomocą polecenia CREATE TABLE i usuwana za pomocą polecenia DROP TABLE. Obsługiwana jest zmiana opisu tabeli za pomocą polecenia ALTER TABLE, w tym dodawanie i usuwanie kolumn, zmiana typów danych kolumn. Po wykonaniu niektórych operacji zmiany opisu tabeli, konieczne jest jej zreorganizowanie (restrukturyzacja fizycznej pamięci tabeli w celu optymalnego dostępu do niej) za pomocą komendy REORG.

Na poniższym rysunku przedstawiono klasyfikację wbudowanych typów danych DB2, których można użyć do zdefiniowania kolumn tabeli.

Oprócz jednego z dozwolone wartości obsługiwany typ danych, wartości kolumn mogą być puste, tj. pusta (NULL) wartość. Możliwość przechowywania przez kolumnę wartości null jest określana podczas tworzenia tabeli.

Większość typów danych wymienionych na rysunku ma bezpośredni odpowiednik w innych nowoczesnych relacyjnych DBMS i są one szczegółowo opisane w dokumentacji DB2. Poniżej znajduje się krótki opis funkcji typu danych, które są specyficzne dla DB2 lub które mogą być trudne w użyciu.

Podczas pracy z danymi łańcuchowymi, w przeciwieństwie do niektórych innych typów DBMS, DB2 rozróżnia między pustym łańcuchem (łańcuch o zerowej długości) a wartością NULL typu string. Ta funkcja wpływa na kolejność wyszukiwania (używanie predykatu równości zamiast wyrażenia IS NULL) i skład dozwolonych wartości kolumn (jeśli wartości NULL są zabronione, w kolumnie można przechowywać pusty ciąg).

Wartości łańcuchowe typów GRAPHIC, VARGRAPHIC i DBCLOB różnią się od innych typów łańcuchów tym, że są zawsze przechowywane w kodowaniu UTF-16. Podczas uzyskiwania dostępu do odpowiednich kolumn ze strony aplikacji klienckiej, DBMS zapewnia konwersję danych do kodowania używanego przez aplikację kliencką.

Kolumny typu DATE (data) domyślnie nie zawierają znaczników czasu. W trybie zgodności z bazą danych Oracle DB2 dodatkowo obsługuje przechowywanie atrybutów czasu (godziny, minuty, sekundy) w kolumnach DATE.

Jeśli potrzebujesz wydajnie pracować z dokładnymi liczbami dziesiętnymi, które zawierają część ułamkową (na przykład w aplikacjach finansowych), wskazane jest użycie typu danych DECFLOAT, który łączy dokładną reprezentację wartości DECIMAL i możliwość sprawnego obliczania wartości typu FLOAT.

Typ danych BLOB umożliwia przechowywanie nieustrukturyzowanych informacji binarnych (takich jak obrazy lub dokumenty biurowe) w bazie danych. Wartości BLOB mogą być przechowywane razem z innymi polami rekordów (jeśli ich rozmiar pozwala na wystarczająco zwarte) lub osobno, w specjalnym obiekcie pamięci. W tym drugim przypadku wpis zawiera odwołanie do przechowywanej wartości BLOB zamiast samej wartości. W podobny sposób zorganizowane jest przechowywanie wartości typów CLOB i DBCLOB.

Typ danych XML zapewnia przechowywanie w polach tabeli ustrukturyzowanych, hierarchicznych dokumentów XML. W przypadku przechowywanych dokumentów XML obsługiwane są operacje dostępu do atrybutów (bez konieczności analizowania dokumentu XML podczas uzyskiwania dostępu), indeksowanie poszczególnych atrybutów i inne funkcje.

Oprócz wbudowanych typów danych DB2 obsługuje typy danych zdefiniowane przez użytkownika, które są definiowane na podstawie typów wbudowanych. Praca z typami danych zdefiniowanymi przez użytkownika jest opisana w dokumentacji DB2.

Podczas tworzenia tabeli możliwe jest określenie reguł automatycznego wypełniania ich wartości dla kolumn. Szczególnym przypadkiem kolumn autouzupełniania są kolumny tożsamości, które są kolumnami liczbowymi, które automatycznie generują unikatową wartość liczbową dla każdego wstawionego wiersza. Automatyczne napełnianie może odbywać się w jednym z dwóch trybów:

• GENEROWANE ZAWSZE — wartość jest zawsze ustawiana przez serwer DB2 i nie może być jawnie ustawiona przez aplikację;
• GENERATED BY DEFAULT - wartość jest ustawiana przez serwer DB2, jeśli aplikacja nie określiła jawnej wartości przypisania podczas wstawiania rekordu.

Również na poziomie tabeli można zdefiniować ograniczenia, które ustalają ograniczenia dotyczące kompozycji wartości atrybutów. Obsługiwane są następujące rodzaje ograniczeń:

• klucz podstawowy (PRIMARY KEY) - ograniczenie unikatowości zbioru kolumn, wykorzystywane głównie do wyszukiwania pojedynczego rekordu, w tabeli może być tylko jeden klucz podstawowy;
• ograniczenie unikatowości (UNIQUE) – dodatkowe ograniczenie unikalności zbioru kolumn;
• klucz obcy (FOREIGN KEY) – odwołanie w postaci zestawu wartości kolumn wskazujące na kombinację kolumn innej tabeli, dla której zdefiniowany jest klucz obcy lub ograniczenie unikatowe;
• check (CHECK) - warunek logiczny, który ogranicza możliwa wartość co najmniej jedna kolumna w poście.

Mechanizm ograniczeń implementuje środki automatycznej kontroli i zapewnienia integralności bazy danych, w tym referencyjnej integralności danych (kontrola obecności w tabeli „rodzicielskiej” rekordów, do których odwołuje się klucze obce rekordów tabel „podrzędnych”). Właściwe stosowanie ograniczeń pozwala zagwarantować formalną poprawność wypełnienia bazy oraz w pewnym stopniu uchronić się przed błędami aplikacji i użytkowników podczas poprawiania danych.

Ponieważ mechanizm restrykcji stwarza dodatkowe obciążenie obliczeniowe przy wprowadzaniu i aktualizowaniu danych, w niektórych przypadkach celowo rezygnuje się z jego stosowania, nakładając odpowiedzialność za prawidłowe utrzymanie bazy danych na aplikacji. Jednocześnie DB2 używa opisów ograniczeń integralności do określenia relacji między tabelami i wybrania najbardziej wydajnego planu wykonywania zapytań.

Stoły tymczasowe

Do przechowywania tymczasowych danych aplikacji DB2 udostępnia mechanizm tabel tymczasowych, który zapewnia pełną funkcjonalność pracy z danymi tabelarycznymi, ale w kontekście bieżącej sesji użytkownika.

Dostęp do tabel tymczasowych znacznie poprawia wydajność, minimalizując lub eliminując konflikty dostępu do katalogu systemowego oraz eliminując blokowanie wierszy, rejestrowanie (opcjonalnie, w zależności od trybu tworzenia tabeli) i sprawdzanie uprawnień.

Tabele tymczasowe obsługują również indeksy, co oznacza, że ​​w tabeli tymczasowej można utworzyć dowolny indeks standardowy. Można również zbierać statystyki dotyczące takich tabel (za pomocą komendy RUNSTATS), aby uzyskać informacje potrzebne optymalizatorowi zapytań.

Tabele tymczasowe znajdują się w tymczasowym obszarze tabel użytkownika, który należy zdefiniować przed ich utworzeniem.

W DB2 istnieją dwie główne odmiany tabel tymczasowych:

• zadeklarowane tabele tymczasowe (DGTT - Declared Global Temporary Tables);
• stworzył globalne tabele tymczasowe (CGTT - Created Global Temporary Tables).

Zadeklarowane tabele tymczasowe to tabele w pamięci używane przez aplikację i automatycznie usuwane po jej zakończeniu. Dostęp do takich tabel może uzyskać tylko aplikacja, która je utworzyła, i nie są one przechowywane w żadnej z tabel katalogu systemowego DB2.

Każda zadeklarowana tabela tymczasowa ma schemat SESSION; schemat ten należy określić, odwołując się do niego. Identyfikator użytkownika używany do deklarowania tabel tymczasowych będzie miał pełne uprawnienia do tych tabel. Każda aplikacja, która deklaruje tabelę tymczasową, będzie miała własną kopię tej tabeli.

Chociaż DGTT umożliwiają zadeklarowanie tabeli tymczasowej, definicja takiej tabeli nie może być współużytkowana przez połączenia lub sesje. Za każdym razem, gdy rozpoczynasz sesję, musisz wydać instrukcję DECLARE GLOBAL TEMPORARY TABLE.

W przypadku korzystania z generowanych globalnych tabel tymczasowych (CGTT) definicja tabeli tymczasowej musi zostać utworzona tylko raz, ponieważ jest przechowywana w katalogu systemowym DB2. Oznacza to, że inne połączenia mogą używać definicji tabeli zamiast tworzyć ją ponownie.

Chociaż struktura tabeli CGTT może być użyta natychmiast, dane z różnych połączeń są od siebie niezależne i znikają po zamknięciu połączenia.

Indeksy

Indeks to uporządkowany zestaw kluczy, z których każdy wskazuje na wiersz tabeli. Indeksy wymuszają unikalność wierszy (czyli implementują ograniczenia unikatowe omówione w poprzedniej sekcji) i poprawiają wydajność. Poniżej opisano niektóre cechy, które można zdefiniować dla indeksów:

• indeksy mogą być budowane w porządku rosnącym lub malejącym wartości kolumn;
• klucze indeksu mogą być unikalne lub nieunikalne;
• indeksy mogą być budowane na kilku kolumnach (takie indeksy nazywane są połączonymi);
• jeśli dane indeksu i tabeli są zgrupowane w tej samej sekwencji indeksów, taki indeks nazywa się klastrowym (INDEKS CLUSTERED).

Tworzenie indeksu zapewnia instrukcja CREATE INDEX, usuwanie przez instrukcję DROP INDEX. Podczas tworzenia indeksu określa się jego typ (unikalny/nieunikalny) oraz skład kolumn do budowy indeksu.

DB2 udostępnia narzędzia, które zapewniają automatyczny wybór indeksów w celu optymalizacji wykonywania zapytań. Najwygodniejszy sposób pracy z tymi narzędziami jest zorganizowany w IBM Data Studio.

Sekwencje

Chociaż obiekty sekwencji są niezależne od tabel, działają podobnie do kolumn tożsamości i zapewniają generowanie unikatowych sekwencji liczbowych. Różnica między sekwencjami a kolumnami tożsamości polega na tym, że kolumny tożsamości generują unikatowe liczby dokładnie w określonej kolumnie tabeli, podczas gdy obiekty sekwencji mogą służyć do generowania sekwencyjnych wartości liczbowych, których logika jest określana przez aplikację.

Tworzenie sekwencji zapewnia komenda CREATE SEQUENCE, dostęp do kolejnych i aktualnie odebranych wartości uzyskuje się za pomocą operatorów NEXT VALUE FOR i PREVIOUS VALUE FOR. W celu zapewnienia zgodności z bazą danych Oracle obsługiwana jest również składnia dostępu do wartości sekwencji za pośrednictwem pseudokolumn „NEXTVAL” i „CURRVAL”.

Reprezentacja

Widok to wyświetlanie danych w tabelach. Dane dla widoków nie są przechowywane oddzielnie, są pobierane podczas uruchamiania widoku. Obsługiwane są widoki zagnieżdżone, tj. widoki utworzone z innych widoków.

Widoki są tworzone za pomocą polecenia UTWÓRZ WIDOK i usuwane za pomocą polecenia UPUŚĆ WIDOK. W celu ułatwienia aktualizacji (zastępowania) widoków udostępniono składnię CREATE OR REPLACE VIEW, która umożliwia utworzenie nowego widoku (jeśli jeszcze nie istnieje) lub zastąpienie istniejącego widoku nową definicją (jeśli widok z podana nazwa została już utworzona).

wyzwalacze

Wyzwalacz to obiekt, który automatycznie wykonuje operację na tabeli lub widoku. Określona akcja na obiekcie, dla którego zdefiniowano wyzwalacz, powoduje uruchomienie wyzwalacza. Zazwyczaj wyzwalacz nie jest uważany za obiekt aplikacji; w związku z tym wyzwalacze są zwykle tworzone nie przez programistów, ale przez administratorów baz danych.

Procedury i funkcje składowane

Procedury składowane to obiekty bazy danych zawierające instrukcje SQL i logikę biznesową. Przechowywanie części logiki aplikacji w bazie danych poprawia wydajność, zmniejszając ruch między aplikacją a bazą danych. Ponadto procedury składowane zapewniają centralną lokalizację do przechowywania kod programu i odpowiednio inne aplikacje mogą używać tych samych procedur przechowywanych. Instrukcja CALL służy do wywoływania procedury składowanej.

Funkcje zdefiniowane przez użytkownika (UDF) to obiekty bazy danych, które umożliwiają użytkownikom rozszerzenie języka SQL o własną logikę. Funkcja zawsze zwraca wartość lub wartości, zwykle w wyniku logiki biznesowej zawartej w funkcji. Aby wywołać funkcję, użyj jej jako części instrukcji SQL lub z instrukcją VALUES.

W DB2 procedury składowane i funkcje zdefiniowane przez użytkownika można tworzyć w kilku językach programowania, w tym PL/SQL, SQL PL, Java, C, C++, COBOL.

Katalog systemowy

Jeden z podstawowych zasoby informacji DBMS to katalog systemowy przechowujący i udostępniający informacje o strukturze bazy danych, w tym:

• opis tabel, kolumn i indeksów;
• opis i tekst widoków, wyzwalaczy i procedur składowanych;
• informacje o przestrzeniach tabel i kontenerach do przechowywania danych;
• ustanowione uprawnienia dostępu do obiektów bazy danych;
• inne metainformacje bazy danych.

Dostęp do katalogu systemowego jest wymagany w przypadku wielu zadań, w tym automatyzacji zadań związanych z administrowaniem i konserwacją bazy danych, tworzeniem aplikacji i nie tylko.

Najczęściej używane tabele (tak naprawdę widoki) będące częścią katalogu systemowego to:

• SYSCAT.SCHEMAS - opis schematów baz danych;
• SYSCAT.TABLES - opis tabel bazy danych;
• SYSCAT.COLUMNS – opis kolumn tabeli;
• SYSCAT.INDEXES - opis indeksów.

Szczegółowy opis i skład kolumn dla powyższych i innych tabel katalogu systemowego znajduje się w .

Organizacja równoległego przetwarzania transakcyjnego

Transakcje

Transakcja (lub jednostka pracy) składa się z co najmniej jednej instrukcji SQL, która podczas wykonywania jest traktowana jako oddzielna jednostka; innymi słowy, niepowodzenie jednej instrukcji transakcji powoduje niepowodzenie całej transakcji, a wszystkie instrukcje wykonane do momentu niepowodzenia zostaną wycofane.

Transakcja kończy się oświadczeniem COMMIT. Transakcja może również zakończyć się instrukcją ROLLBACK lub nieprawidłowym (nienormalnym) zamknięciem aplikacji, po czym wszystkie zmiany wprowadzone przez aplikację do bazy danych zostaną anulowane. Rozpoczęciem transakcji jest pierwsza instrukcja wykonana po otwarciu połączenia aplikacji z bazą danych lub po zakończeniu poprzedniej transakcji. Każde połączenie aplikacji z bazą danych może mieć co najwyżej jedną aktywną transakcję.

Jak wspomniano wcześniej, zmiany w bazie danych są rejestrowane w dzienniku transakcyjnym. Aby zapewnić, że zmiany wprowadzone przez cofniętą transakcję można „wycofać”, granice transakcji są również rejestrowane w dzienniku transakcji. Jednocześnie transakcje, które wykonują tylko operacje odczytu danych, nie są zapisywane w dzienniku transakcji. Informacja o rozpoczęciu transakcji umieszczana jest w logu transakcji przed rozpoczęciem realizacji pierwszego (dla danej transakcji) zestawienia zapisu danych.

W przypadku błędu w wykonaniu pojedynczej instrukcji, która zapisuje dane, wszystkie zmiany wprowadzone przez tę instrukcję są cofane przy użyciu danych z dziennika transakcji. Aplikacja po otrzymaniu komunikatu diagnostycznego o odmowie wykonania wyciągu może anulować całą transakcję (wyciągiem ROLLBACK) lub wykonać inne akcje z bazą danych i w efekcie zatwierdzić wprowadzone zmiany (wyrażeniem COMMIT ).

Aplikacja może zdefiniować dodatkowe punkty wycofania w ramach transakcji (za pomocą instrukcji SAVEPOINT) oraz cofnąć zmiany dokonane po utworzeniu punktu wycofania (za pomocą instrukcji ROLLBACK TO). Użycie punktów wycofania pozwala aplikacji na selektywne cofanie działań podjętych w ramach transakcji, co może być przydatne w obsłudze błędów integralności danych i innych scenariuszy.

Zamki

Użycie równoległe oznacza, że ​​wielu użytkowników może jednocześnie pracować na tych samych obiektach bazy danych. Dostęp do danych musi być odpowiednio skoordynowany, aby zapewnić integralność i spójność danych.

Aby uzyskać spójne wyniki transakcji równoległych, konieczne jest kontrolowanie równoległego wykorzystania współdzielonych zasobów. Taka kontrola opiera się na wykorzystaniu zamków.

Koncepcje blokowania i współbieżności są ze sobą ściśle powiązane. Blokada tymczasowo uniemożliwia aplikacjom wykonywanie innych operacji do czasu zakończenia bieżącej operacji. Im bardziej aktywne jest blokowanie w systemie, tym mniej możliwości współbieżności pozostaje. Z drugiej strony, im rzadziej stosowana jest blokada w systemie, tym więcej możliwości współbieżności.

Blokada jest uzyskiwana automatycznie w celu utrzymania transakcji i jest zwalniana, gdy taka transakcja zostanie przerwana (przy użyciu polecenia COMMIT lub ROLLBACK). Zamki można umieszczać na stołach lub rzędach.

Istnieją dwa główne rodzaje blokowania:

• Blokada współdzielona (S) — jest ustawiana, gdy aplikacja odczytuje dane i uniemożliwia innym aplikacjom wprowadzanie zmian w tym samym wierszu.
• Wyłączna blokada (X) — ustaw, gdy aplikacja aktualizuje, wstawia lub usuwa wiersz.

Jeśli dwa i więcej aplikacji trzeba wykonać operację na tym samym obiekcie, jeden z nich będzie musiał poczekać na uzyskanie wymaganej blokady. Domyślnie aplikacja będzie czekać w nieskończoność. Limit czasu blokady aplikacji jest kontrolowany przez parametr konfiguracyjny bazy danych LOCKTIMEOUT. Domyślna wartość tego parametru to -1 (nieskończone oczekiwanie).

Możesz użyć zmiennej sesji CURRENT LOCK TIMEOUT, aby ustawić limit czasu blokady dla określonego połączenia. Domyślnie ta zmienna jest ustawiona na LOCKTIMEOUT. Aby zmienić tę wartość, można użyć instrukcji SET LOCK TIMEOUT.

W przypadku, gdy dwie (lub więcej) aplikacje podłączone do tej samej bazy danych czekają w nieskończoność na zasoby ze względu na nieprawidłową sekwencję dostępu do tych zasobów, następuje sytuacja zakleszczenia. Limit czasu nie może wygasnąć, ponieważ każda aplikacja przechowuje zasób, którego potrzebuje druga aplikacja. We wszystkich przypadkach problem zakleszczenia wynika z nieprawidłowej struktury lub logiki aplikacji.

DB2 automatycznie wykrywa sytuacje zakleszczeń, przeprowadzając odpowiednie sprawdzenia w odstępach czasu określonych przez parametr DLCHKTIME. Gdy wykryje, że rzeczywiście wystąpiło zakleszczenie, DB2 użyje wewnętrznego algorytmu do określenia, która z dwóch transakcji powinna zostać wycofana, a która powinna być kontynuowana.

Poziomy izolacji

Szczegółowa analiza problemów, które mogą wystąpić w przypadku braku kontroli współbieżności, znajduje się w dokumentacji DB2, a także w literaturze dotyczącej teorii funkcjonowania relacyjnego DBMS. Możliwe rodzaje problemów to:

• utracona aktualizacja (jeśli jeden blok danych zostanie jednocześnie zmieniony przez różne transakcje, jedna ze zmian zostanie utracona);
• nierzetelny odczyt (odczyt danych dodanych lub zmienionych przez transakcję, które nie zostaną następnie potwierdzone);
• odczyt jednorazowy (przy ponownym odczycie w ramach tej samej transakcji, poprzednio odczytane dane są zmieniane);
• odczyt fantomowy (te same selekcje w jednej transakcji dają różne zestawy wierszy ze względu na dodawanie, usuwanie lub zmianę wierszy przez inne transakcje).

Kontrola po stronie aplikacji wbudowanych zabezpieczeń DB2 przed problemami wymienionymi powyżej odbywa się poprzez ustawienie poziomu izolacji, który ma być używany. Poziomy izolacji można traktować jako zasady blokowania, w których, w zależności od wybranego poziomu izolacji, można osiągnąć różne sposoby blokowania bazy danych przez aplikację. Poziom izolacji wymagany przez aplikację można ustawić na poziomie sesji oraz na poziomie pojedynczego zapytania lub podżądania, które jest wykonywane.

DB2 zapewnia następujące poziomy ochrony izolacji danych:

• zawodny odczyt (Uncommitted Read, UR);
• stabilność kursora (stabilność kursora, CS);
• stabilność odczytu (Read Stability, RS);
• powtarzane czytanie (Repeatable Read, RR).

Nieautentyczne czytanie zwany także „brudnym”. To najniższy poziom izolacji, który pozwala najwyższy stopień zastosowanie równoległe. Wiersze nie są blokowane podczas operacji odczytu, z wyjątkiem sytuacji, gdy inna aplikacja próbuje usunąć lub zmodyfikować tabelę; operacje aktualizacji są wykonywane w taki sam sposób, jak w przypadku korzystania z następnego poziomu izolacji, poziomu stabilności kursora.

Użycie poziomu izolacji Bad Read zapobiega następującym problemom:

• utracona aktualizacja.

Stabilność kursora to domyślny poziom izolacji. Zapewnia minimalny stopień blokowania. Ten poziom izolacji blokuje „bieżący” wiersz kursora. Jeśli linia jest tylko do odczytu, blokada jest utrzymywana do momentu przejścia do Nowa linia lub zakończenie operacji. Jeśli wiersz zostanie zaktualizowany, blokada jest utrzymywana do czasu zakończenia operacji.

Korzystanie z poziomu izolacji stabilności kursora zapobiega następującym problemom:

• utracona aktualizacja;
• nieprawidłowy odczyt.

Przed wersją DB2 9.7, gdy używany był poziom izolacji Cursor Stability, wykonanie zapisu (operacja UPDATE) zamykało dostęp do odczytu (operacja SELECT) do tego samego wiersza. Podstawą logiczną było to, że ponieważ operacja zapisu wprowadza zmiany w wierszu, odczyt powinien czekać na zakończenie aktualizacji, aby uzyskać ostateczną zatwierdzoną wartość.

DB2 9.7 domyślnie stosuje inne podejście do poziomu izolacji stabilności kursora dla nowych baz danych. To nowe podejście jest realizowane przy użyciu semantyki „aktualnie zatwierdzone” (CC). W przypadku korzystania z semantyki CC operacja zapisu nie zamyka dostępu do tego samego wiersza dla operacji odczytu. Wcześniej takie podejście było możliwe przy użyciu poziomu izolacji UR; różnica w stosunku do obecnego podejścia polega na tym, że w przypadku UR operacja odczytu otrzymuje nieprawidłowe wartości, podczas gdy w przypadku semantyki CC otrzymuje aktualnie akceptowane wartości. Aktualnie zatwierdzone wartości to wartości, które zostały zatwierdzone przed rozpoczęciem operacji zapisu.

Stabilność czytania zapewnia blokadę wszystkich wierszy otrzymanych przez aplikację. W przypadku danego zapytania wszystkie wiersze pasujące do zestawu wyników są blokowane. Zatem użycie tego trybu izolacji może spowodować, że aplikacja nabędzie dużą liczbę blokad, a po osiągnięciu ustalonych limitów eskaluje blokady z poziomu wiersza na poziom tabeli. Jednak na poziomie izolacji Read Stability optymalizator zapytań DB2 nie uzyskuje jawnie blokad na poziomie tabeli w planie wykonywania wykonywanych zapytań, nawet jeśli zestaw wyników zawiera większość rekordów w tabeli.

Użycie poziomu izolacji Read Stability zapobiega następującym problemom:

• utracona aktualizacja;
• nieprawidłowy odczyt;
• nie powtarzające się czytanie.

Powtarzające się czytanie to najwyższy poziom izolacji. Zapewnia najwyższy stopień blokowania i najmniejszą współbieżność. W wierszach, które są przetwarzane w celu zbudowania zestawu wyników, umieszczana jest blokada; innymi słowy, nawet wiersze, które nie trafiają do pakietu wyników końcowych, mogą zostać zablokowane. Inne aplikacje nie mogą aktualizować, usuwać ani wstawiać wierszy, które będą miały wpływ na zestaw wyników, dopóki trwająca operacja nie zostanie zakończona. Wielokrotne czytanie zapewnia, że ​​to samo zapytanie, tworzone przez aplikację wielokrotnie w ramach jednej operacji, za każdym razem daje te same wyniki.

Optymalizator zapytań DB2 w przypadku korzystania z poziomu izolacji Powtarzany odczyt może uwzględniać w planie wykonania zapytania operacje jawne ustawianie blokad na poziomie tabeli, gdy odpowiednie zapytania wymagają skanowania wszystkich wierszy tabeli (co oznacza konieczność blokowania każdego wiersza tabeli podczas wykonywania zapytania).

Korzystanie z poziomu izolacji Read Stability zapobiega wszystkim możliwe problemy konkurencyjny dostęp, ale jednocześnie ewentualna równoległość wykonywania operacji jest maksymalnie ograniczona.

Wniosek

W tym artykule dokonano przeglądu głównych funkcjonalność IBM DB2 LUW DBMS, struktura serwera bazy danych, ustawienia konfiguracyjne i organizacja przechowywania danych. Ponadto brane są pod uwagę podstawowe zasady serwera DB2, obsługiwane typy obiektów bazy danych oraz organizacja równoległego przetwarzania transakcyjnego DB2.

W pracy przez jakiś czas miałem do czynienia z IBM DB2 DBMS. Dlatego Ponieważ system jest komercyjny, w Internecie nie ma zbyt wielu informacji w języku rosyjskim, więc postanowiłem opisać niektóre funkcje tego DBMS.

Punkt wejścia

Zacznijmy od punktu wejścia w DBMS. W SQL SERVER punktem końcowym jest instancja, która oczywiście może mieć osobne bazy danych, ale konfiguracja i model bezpieczeństwa jest taki sam dla całej instancji. W DB2 punkt wejścia wygląda tak - instancja (odpowiadająca określonemu portowi) - baza danych. Jednocześnie istnieje konfiguracja dla całej instancji i osobnej bazy danych.

Konfigurację instancji można wyświetlić za pomocą komendy db2:

Konfiguracja menedżera bazy danych

Typ węzła = Enterprise Server Edition z klientami lokalnymi i zdalnymi

Poziom wydania konfiguracji menedżera bazy danych = 0x0b00

Szybkość procesora (milisekunda/instrukcja) (CPUSPEED) = 2,912790e-07
Przepustowość komunikacji (MB/s) (COMM_BANDWIDTH) = 1.000000e+02

Maksymalna liczba jednocześnie aktywnych baz danych (NUMDB) = 8
Obsługa systemu sfederowanych baz danych (Sfederowanych) = TAK
Nazwa monitora procesora transakcji (TP_MON_NAME) =

Domyślne konto obciążenia zwrotnego (DFT_ACCOUNT_STR) =

Ścieżka instalacji Java Development Kit (JDK_PATH) = /home/db2inst1/sqllib/java/jdk32

Poziom przechwytywania błędów diagnostycznych (DIAGLEVEL) = 3
Poziom powiadomień (POZIOM POWIADOMIENIA) = 3
Ścieżka katalogu danych diagnostycznych (DIAGPATH) = /home/db2inst1/sqllib/db2dump

Domyślne przełączniki monitora bazy danych
Pula buforów (DFT_MON_BUFPOOL) = WYŁ

Gdzie zostaną określone parametry, ich znaczenie i dekodowanie. Możliwa jest również wersja skrócona:

zdobądź dbm cfg

Lub z zapytaniem:

Wybierz nazwę, wartość z sysibmadm.dbmcfg

Ważne parametry to:

• typ uwierzytelniania (AUTHENTICATION)
• domyślna ścieżka do tworzenia nowych baz danych (DFTDBPATH)
• wykrywanie serwerów sieciowych (DISCOVER)

Możesz wyświetlić ustawienia dla określonej bazy danych w następujący sposób:

połącz się z próbką(przykład - nazwa bazy danych)

pobierz konfigurację menedżera bazy danych

Lub z mniej więcej tym samym żądaniem co poprzednio:

wybierz nazwę, wartość z sysibmadm.dbcfg

Uwierzytelnianie

Dużą różnicą między DB2 a innymi DBMS jest model uwierzytelniania. Nie ma użytkowników wewnętrznych, takich jak SQL Server czy MySQL. Wszelkie uwierzytelnianie odbywa się za pomocą zewnętrznych w stosunku do DBMS (wtyczek ładowanych dynamicznie) – za pomocą systemu operacyjnego lub wtyczek zewnętrznych (Kerberos, GSS API). Typ uwierzytelniania jest ustawiany w parametrze AUTHENTICATION konfiguracji menedżera bazy danych. Domyślnie ustawiona jest wartość SERVER - nazwa użytkownika i hasło przekazywane są w postaci zwykłego tekstu, a poprawność tej pary jest sprawdzana przez system operacyjny. Jeżeli nazwa użytkownika i hasło są poprawne, to sprawdzane jest uprawnienie CONNECT dla użytkownika lub grup, do których jest członkiem (w tym specjalnej grupy PUBLIC, która obejmuje wszystkich uprawnionych użytkowników). Te uprawnienia można wyświetlić w tabeli SYSCAT.DBAUTH:

wybierz GRANTEE z SYSCAT.DBAUTH, gdzie CONNECTAUTH = "Y"

Dużym błędem konfiguracyjnym jest uwzględnienie typu uwierzytelniania KLIENT. W takim przypadku DB2 ufa uwierzytelnianiu łączącemu się klientowi, a jeśli PUBLIC ma uprawnienie CONNECT, każdy użytkownik może połączyć się z bazą danych i mieć dostęp do wszystkich danych, które posiada PUBLIC. Nazwa użytkownika jest pobierana z systemu operacyjnego. Oznacza to, że jeśli połączymy się za pośrednictwem Data Studio jako użytkownik Administrator, wszystkie uprawnienia, które posiada ten użytkownik, zostaną nadane. I w tym przypadku nie ma różnicy, z którego komputera uzyskano dostęp. Zaleca się, aby ten typ uwierzytelniania był włączony tylko wtedy, gdy istnieje bezpieczny kanał między serwerem a klientem, a inni klienci nie będą mogli połączyć się z DBMS.

Upoważnienie

Uprawnienia na poziomie instancji są zapisywane w konfiguracji menedżera bazy danych. Są to następujące przywileje:

• SYSADM
• SYSCTRL
• KONSERWACJA SYSTEMU
• SYSMON

Te uprawnienia są ustawiane poprzez określenie grupy, do której użytkownik wejdzie. W dbmcfg są to odpowiednio opcje SYSADM_GROUP , SYSCTRL_GROUP , SYSMAINT_GROUP i SYSMON_GROUP .

Następnie są uprawnienia specyficzne dla bazy danych. Są to uprawnienia, takie jak dostęp do bazy danych (CONNECTAUTH), tworzenie tabel (CREATETABAUTH), tworzenie procedur (EXTERNALROUTINEAUTH) i tak dalej. Te uprawnienia można wyświetlić w widoku SYSCAT.DBAUTH

I wreszcie uprawnienia dostępu do określonych danych - tabel, podprogramów i tak dalej. Wszystko tutaj jest dość banalne, ale z pewnymi osobliwościami.

Uprawnienia dostępu do tabeli można wyświetlić w widoku SYSCAT.TABAUTH. Typ nadanego uprawnienia jest przechowywany w osobnych kolumnach, w zależności od samego uprawnienia (SELECTAUTH, DELETEAUTH itp.). Nadając uprawnienie za pomocą polecenia GRANT dla uprawnień REFERENCES i UPDATE można również określić nazwy kolumn, na które dane uprawnienia zostaną rozszerzone. W takim przypadku informacje na ten temat można wyświetlić w widoku SYSCAT.COLAUTH

Uprawnienia do procedur (funkcji, procedur i metod) można przeglądać w SYSCAT.ROUTINEAUTH . Nie wszystko jest tu trywialne, w zależności od pól SPECIFICNAME i TYPENAME uprawnienia można nadawać wszystkim podprogramom danego schematu.

Jeśli czytelnikom spodoba się ten artykuł, jestem gotów porozmawiać o ochronie danych w DB2 za pomocą kontroli dostępu opartej na etykietach

Relacyjna baza danych to zestaw relacji, których nazwy są zgodne z nazwami schematów relacji w schemacie bazy danych. Dziś wiadomo duża liczba różne serwery baz danych SQL. Skupmy się na następujących czterech wiodących serwerach DBMS - Oracle8i, IBM DB2, Microsoft SQL Server i Informix - i porównaj je w działaniu na każdym z głównych etapów funkcjonowania.

Wyrocznia8i. Pakiet Oracle8i, wyposażony w najbardziej zaawansowany zestaw funkcji do pracy z językiem Java i dostępu do danych przez Internet, system optymalizacji dostępu współbieżnego. Jedyną wadą tego DBMS jest złożoność administracji, jednak wszystkie koszty jego wdrożenia i rozwoju zwrócą się później przy sprawnej i niezawodnej pracy. (złożoność i wysoki koszt są dyskusyjne). Wśród głównych właściwości Oracle DBMS należy zwrócić uwagę na: Najwyższa niezawodność. Możliwość partycjonowania dużych baz danych na sekcje (partycja dużej bazy danych), co pozwala efektywnie zarządzać gigantycznymi gigabajtowymi bazami danych; Dostępność uniwersalnych środków ochrony informacji; Skuteczne metody maksymalny wzrost szybkość przetwarzania żądania; Indeksowanie bitmap; Wolne tabele (w innych DBMS wszystkie tabele są wypełniane natychmiast po utworzeniu); Równoległość operacji w zapytaniu. Dostępność szerokiej gamy narzędzi programistycznych, monitorujących i administracyjnych. Orientacja na technologie internetowe Rozwiązania, które nie są gorsze od rozwiązań Oracle, można znaleźć tylko w DB2 firmy IBM. Zorientowanie na technologie internetowe to główna dewiza nowoczesnych produktów Oracle. Na uwagę zasługuje pakiet interMedia, który zapewnia przetwarzanie danych w formatach multimedialnych, oraz Jserver, wbudowane narzędzie do pracy z językiem Java, które łączy możliwości języka Java z możliwościami relacyjnych baz danych. Enterprise JavaBeans to elementy, z których składają się aplikacje internetowe Java. Oracle wyznaje zasadę, że wszystkimi krytycznymi funkcjami należy zarządzać z jedno centrum dlatego proponowany moduł interMedia udostępnia użytkownikom najbardziej zaawansowane funkcje do pracy z obiektami multimedialnymi: Bardzo zaawansowane narzędzia do obróbki klipów audio; Obrazy nieruchome; Klipy wideo; Dane geograficzne (z całym zestawem funkcji związanych z określaniem lokalizacji zawartych w module Lokalizator). Oracle8i implementuje obecnie najlepsze narzędzia do obiektowego projektowania baz danych, w tym struktury tabelaryczne, które umożliwiają dziedziczenie właściwości i metod innych obiektów tabelarycznych baz danych, co pozwoli uniknąć błędów podczas budowania bazy danych i ułatwi ich utrzymanie. Należy również zauważyć, że opracowany przez Oracle system optymalizacji współbieżności multiwersjonowania jest jedną z najważniejszych cech architektury Oracle (funkcja ta jest dostępna tylko w InterBase DBMS firmy InterBase firmy Inprise). Ta funkcja pozwala wyeliminować sytuację, w której jeden użytkownik musi czekać, aż drugi zakończy zmiany zawartości baz danych (czyli brak blokad odczytu w Oracle). Ta funkcja umożliwia Oracle8i wykonywanie większej liczby transakcji na sekundę na użytkownika niż jakakolwiek inna baza danych. Pod względem wydajności podczas pracy w środowisku WEB pod LINUX, Oracle zajmuje zaszczytne drugie miejsce po DBMS MySQL, znacznie przewyższając wszystkie inne DBMS pod względem niezawodności i bezpieczeństwa.

DBMS Microsoft SQL Server Najważniejszymi cechami tego DBMS są: łatwość administracji, możliwość połączenia z siecią WWW, szybkość i funkcjonalność mechanizmu serwera DBMS, dostępność narzędzi zdalny dostęp, Zestaw narzędzi administracyjnych DBMS zawiera cały zestaw specjalnych kreatorów i narzędzi do automatycznego ustawiania parametrów konfiguracyjnych. Ponadto ta baza danych jest wyposażona w doskonałe narzędzia do replikacji, które umożliwiają synchronizację danych komputera z informacjami z bazy danych i odwrotnie. Zawarty w pakiecie serwer OLAP umożliwia zapisywanie i analizę wszystkich danych dostępnych dla użytkownika. W zasadzie ten DBMS jest nowoczesną, w pełni funkcjonalną bazą danych, która jest idealna dla małych i średnich organizacji. Należy zauważyć, że SQL Server ustępuje innym rozważanym DBMS w dwóch ważnych wskaźnikach: programowalności i sposobie działania. Przy tworzeniu klienckich aplikacji bazodanowych opartych na Javie, HTML często pojawia się problem niewystarczającego oprogramowania SQL Server i korzystanie z tego DBMS będzie trudniejsze niż z systemów DB2, Informix, Oracle czy Sybase. Globalny trend XXI wieku stał się niemal powszechnym przejściem na platformę LINUX, a SQL Server funkcjonuje tylko w Środowisko Windows. Dlatego korzystanie z SQL Server jest wskazane tylko wtedy, gdy standard ODBC jest używany wyłącznie do dostępu do zawartości bazy danych, w przeciwnym razie lepiej jest użyć innego DBMS.

IBM DB2 IBM DB2 DBMS jest wynikiem prawie 30 lat rozwoju i Praca badawcza przez IBM. Najnowsza wersja tego systemu DBMS (6.x) zawiera jeden z najbardziej rozbudowanych zestawów narzędzi do zarządzania i optymalizacji oraz silnik bazy danych, który może rozwinąć się z laptopa z systemem Windows 95 do całego klastra komputerów mainframe S/390 z systemem OS/390. Pakiet DB2 jest dostępny w dwóch edycjach: DB2 Workgroup i DB2 Enterprise Edition. Ten DBMS implementuje wszystkie innowacyjne technologie silnika bazy danych znane z poprzednich wersji DB2, takie jak równoległe przetwarzanie zapytań, pełny zestaw narzędzi do replikacji, tabele podsumowań zapytań w celu poprawy wydajności bazy danych, funkcje projektowania baz danych zorientowanych obiektowo oraz funkcje języka Java. Dodatkowo system DB2 wyposażony jest w kompletny zestaw rozszerzeń multimedialnych, które pozwalają zapisywać i manipulować fragmentami tekstu, dźwięku i wideo, obrazami i danymi geograficznymi. Można powiedzieć, że pod względem skalowalności technologia klastrowania baz danych opracowana przez specjalistów IBM nie ma sobie równych. Rozszerzenia te znacznie ułatwiają proces tworzenia aplikacji internetowych, a także programów zawierających obrazy fotograficzne i obszerne raporty tekstowe. System DB2 jest również dość konkurencyjny jako platforma do tworzenia aplikacji, ponieważ istnieje narzędzie do tworzenia procedur zapisanych w bazie, które automatycznie konwertuje Instrukcja SQL do odpowiedniej klasy Java i dołączenie jej do struktury bazy danych. W DB2 6.1 interoperacyjność z innymi systemami DBMS została znacznie poprawiona przez umożliwienie użycia specyfikacji Microsoft OLE DB, nowego standardu dostępu do bazy danych. Kontrole administracyjne DB2, które są Nowa wersja napisane na nowo w Javie i dostępne do pobrania z Sieci zasługują na najwyższe uznanie. Główne wady tego DBMS to względna złożoność administracji oraz brak (jeszcze) implementacji dla popularnych systemów operacyjnych dla serwerów, takich jak LINUX. W tym DBMS, dzięki Index Smart-Guide, można przeprowadzić strojenie, tworząc optymalne indeksy dla danej liczby dostępów, która charakteryzuje typowe obciążenie bazy danych. DB2 to jedyny pakiet pozwalający na generowanie tabel przestawnych, co znacznie poprawia wydajność DBMS jako hurtowni danych. Tabela przestawna to tymczasowy obszar roboczy używany przez bazę danych do przechowywania odpowiedzi na często zadawane zapytania. Model DB2 6.1 staje się najbardziej opłacalnym systemem o wysokiej wydajności. Narzędzia administracyjne tego DBMS są dość odpowiednie do poziomu rozwiązywanych zadań, dodatkowo daje wyjątkowo szerokie możliwości pracy z danymi multimedialnymi i programowania (czego wyraźnie brakuje w Microsoft SQL Server).

DBMS firmy Informix. Ostatnio nastąpiło przejście od relacyjnych DBMS do zorientowanych obiektowo (co wyraźnie widać na przykładzie Oracle). Firma Informix również podążając za tą koncepcją ogłosiła nowe rozwiązanie Centaur DBMS oparte na relacyjnej bazie danych Informix Dynamic Server 7.3 i obiektowo-relacyjnej bazie danych Informix Universal Data Option oraz łączące wysoką wydajność Dynamic Server podczas pracy z danymi z uniwersalnością i funkcjami multimedialnymi Universal Opcja danych. Ta implementacja przeznaczona jest do rozwoju systemów internetowych. Oczekuje się, że ten DBMS będzie miał elastyczne środowisko programistyczne ze skalowalnością dostosowaną do intensywnych obciążeń charakterystycznych dla Internetu oraz narzędzia do pracy z nowymi typami danych, które stały się wszechobecne wraz z rozwojem sieci. Zaimplementowane w nowym systemie narzędzia Java umożliwią programistom tworzenie procedur składowanych, programów użytkownika i komponentów DataBlades w tym języku, co wywołuje Informix

niestandardowe rozszerzenia bazy danych. Z punktu widzenia klientów Informix będzie to duży krok naprzód, ponieważ do tej pory pracując z DataBlades mogli używać tylko C i SPL, wewnętrznego języka Informix do pisania procedur składowanych. Dodatkowo pakiet Centaur będzie wyposażony we wbudowaną obsługę obiektów ActiveX. Umożliwi to np. tworzenie procedur składowanych w bazie danych w języku Visual Basic; wymaga to jednak działania pakietu Centaur w środowisku Windows NT. Centaur będzie dodatkiem do Informix Dynamic Server i będzie pracował z tradycyjnym formatem bazy danych dla tego pakietu, dzięki czemu użytkownicy będą mieli do dyspozycji wszystkie stare funkcje, a aktualizacja systemu do nowej wersji nie będzie bardzo trudna. Ponadto pakiet Centaur zachowa wszystkie możliwości projektowania i programowania, które uczyniły system Informix Universal Server wyjątkowym osiągnięciem inżynieryjnym. Nowy system będzie wyposażony w udogodnienia do projektowania obiektowego baz danych, tworzenia specjalistycznych tabel i programów indeksujących; pozwoli użytkownikom osadzić własną funkcjonalność w zapytaniach, a nie polegać wyłącznie na standardowe środki SQL. Wnioski. Po rozważeniu głównych cech architektur do budowy AIS, serwerowych systemów operacyjnych i DBMS, w przyszłości jako architekturę AIS wybierzemy architekturę Internetu/Intranetu, jako system operacyjny serwera Linux, jako DBMS Oracle 8i.

2) Klauzula SQL SELECT. Wbudowane funkcje.

SELECT kolumna FROM tabela WHERE kolumna LIKE wzór

SELECT * FROM Informacje o sklepie GDZIE nazwa_sklepu LIKE "% AN%";

SELECT nazwa_kolumny FROM nazwa_tabeli GDZIE nazwa_kolumny POMIĘDZY wartością1 ORAZ wartość2

SELECT * FROM Osoby GDZIE Nazwisko BETWEEN "Hansen" I "Pettersen";

SELECT * FROM Osoby GDZIE Nazwisko NIE POMIĘDZY „Hansen” A „Pettersen”;

SELECT Firma, NumerZamówienia FROM Zamówienia ORDER BY( sortowanie ) Firma;

SELECT Firma, OrderNumber FROM Orders ORDER BY Firma, OrderNumber;

SELECT Firma, Numer Zamówienia FROM Zamówienia ORDER BY Firma DESC( Odwrotna kolejność ) ;

SELECT Firma, Numer Zamówienia FROM Zamówienia ORDER BY Firma DESC , Numer Zamówienia ASC( prawo . zamówienie ) ;

SELECT * FROM Osoby WHERE Imię="Tove" AND LastName="Svendson";

SELECT * FROM Osoby WHERE imię="Tove" OR nazwisko="Svendson" ;

SELECT * FROM Osoby WHERE (Imię="Tove" OR Imię="Stephen") AND Nazwisko="Svendson" ;

SELECT nazwa_sklepu FROM Informacje_sklepu WHERE Sprzedaż > 1000 OR (Sprzedaż< 500 AND Sales > 275);

FunkcjeWYBIERZfunkcjonować( kolumna) Zstół AVG - średnia wartość w kolumnie; LICZYĆ - liczba wartości w kolumnie; MAX - najbardziej bardzo ważne w kolumnie; MIN - najmniejsza wartość w kolumnie; SUMA - suma wartości według kolumny

Przykłady: WYBIERZ AVG(Wiek) OD Osób; WYBIERZ LICZYĆ(nazwa_sklepu) Z informacji_sklepu; WYBIERZ LICZYĆ(ODRĘBNY nazwa_sklepu) Z Informacje_sklepu; WYBIERZ MAX(Wiek) OD Osób WYBIERZ SUMA(Sprzedaż) OD Sklep_Informacje;

3) Serializacja transakcji, konflikty operacji. Metody serializacji transakcji. Uchwyty synchronizacji, szczegółowe uchwyty synchronizacji. Metody serializacji transakcji. Przechwytywanie synchronizacji predykatów. Serializacja na podstawie znaczników czasu.

Aby osiągnąć izolację transakcji, SZBD musi używać metod regulujących wspólne wykonywanie transakcji. Plan (metoda) wykonania zbioru transakcji nazywa się seryjny jeżeli wynik wspólnej realizacji transakcji jest równoznaczny z wynikiem pewnej sekwencyjnej realizacji tych samych transakcji. Serializacja transakcji- jest to mechanizm ich realizacji według jakiegoś planu seryjnego. Zapewnienie takiego mechanizmu jest główną funkcją komponentu DBMS odpowiedzialnego za zarządzanie transakcjami. System obsługujący serializację transakcji zapewnia rzeczywistą izolację użytkowników. Głównym problemem implementacyjnym jest wybór metody serializacji zestawu transakcji, która nie ogranicza nadmiernie ich równoległości. Banalnym rozwiązaniem, które przychodzi na myśl, jest tak naprawdę sekwencyjna realizacja transakcji. Są jednak sytuacje, w których możliwe jest wykonanie zestawień różnych transakcji w dowolnej kolejności z zachowaniem szeregowości. Przykłady obejmują transakcje tylko do odczytu, a także transakcje, które nie powodują konfliktu na obiektach bazy danych. Pomiędzy transakcjami mogą występować następujące typy konfliktów: W-W - transakcja 2 próbuje zmodyfikować obiekt zmodyfikowany przez transakcję 1, która się nie zakończyła; R-W - transakcja 2 próbuje zmodyfikować obiekt odczytany przez transakcję 1, która się nie zakończyła; W-R — transakcja 2 próbuje odczytać obiekt zmodyfikowany przez transakcję 1, która nie została zakończona. Praktyki serializacji transakcji są oparte na tych konfliktach.

Istnieć dwa podstawowe podejścia do serializacji transakcji - w oparciu o synchronizację przechwyconych obiektów bazy danych oraz wykorzystanie znaczników czasu. Istotą obu podejść jest wykrywanie konfliktów transakcyjnych i ich eliminowanie. Najpopularniejszym podejściem w scentralizowanych DBMS (w tym systemów opartych na architekturze „klient-serwer”) jest podejście oparte na przestrzeganie dwufazowego protokołu przechwytywania synchronizacji obiekty bazy danych. Ogólnie rzecz biorąc, protokół polega na tym, że przed wykonaniem jakiejkolwiek operacji w transakcji T na obiekcie bazy danych r, w imieniu transakcji T, żądane jest przechwycenie synchronizacji obiektu r w odpowiednim trybie (w zależności od typu operacji). Główne tryby przechwytywania synchronizacji to: tryb wspólny - S (Shared), co oznacza wspólne przechwytywanie obiektu i wymagane do wykonania operacji odczytu obiektu; tryb ekskluzywny - X (eXclusive), oznaczający wyłączne przechwytywanie obiektu i wymagane do wykonywania operacji wstawiania, usuwania i modyfikacji. Szczegółowe przechwytywanie synchronizacji - podejście, które Przechwytywanie synchronizacji można odpytywać o obiekty różne poziomy: pliki, relacje i krotki. Wymagany poziom obiektu jest określany przez wykonywaną operację (na przykład, aby wykonać operację usuwania na relacji, cała relacja musi być obiektem przechwytywania synchronizacji, ale aby wykonać operację usuwania krotki, ta krotka). Obiekt na dowolnym poziomie można uchwycić w trybie S lub X. Przechwytywanie synchronizacji predykatów- nie jest to przechwytywanie obiektów, ale warunków (predykatów), które te obiekty spełniają Alternatywna metoda serializacji transakcji, która sprawdza się w warunkach rzadkich konfliktów transakcji i nie wymaga budowy grafu oczekiwania na transakcję. oparte na za pomocą sygnatur czasowych. Główna idea metody (których jest wiele odmian) jest następująca: jeśli transakcja T1 rozpoczęła się przed transakcją T2, to system zapewnia taki tryb realizacji, jakby T1 został całkowicie zrealizowany przed rozpoczęciem T2.

W tym celu każdej transakcji T przypisywany jest znacznik czasu t odpowiadający czasowi rozpoczęcia T. Podczas wykonywania operacji na obiekcie r, transakcja T oznacza go swoim znacznikiem czasu oraz typem operacji (odczyt lub zmiana). Przed wykonaniem operacji na obiekcie r, transakcja T1 wykonuje następujące akcje: Sprawdza, czy transakcja T, która oznaczyła ten obiekt, zakończyła się. Jeżeli T się zakończyło, T1 zaznacza obiekt r i wykonuje jego operację. Jeżeli transakcja T nie została zakończona, to T1 sprawdza, czy operacje są sprzeczne. Jeżeli operacje nie są sprzeczne, znacznik czasu z niższą wartością pozostaje lub jest dołączony do obiektu r, a transakcja T1 wykonuje swoją operację. Jeśli operacje T1 i T są w konflikcie, to jeśli t(T) > t(T1) (czyli transakcja T jest młodsza niż T), T jest wycofywany i T1 jest kontynuowany. Jeśli t(T)< t(T1) (T "старше" T1), то T1 получает новую временную метку и начинается заново. К недостаткам метода временных меток относятся потенциально более частые откаты транзакций, чем в случае использования синхронизационных захватов. Это связано с тем, что конфликтность транзакций определяется более грубо. Кроме того, в распределенных системах не очень просто вырабатывать глобальные временные метки с отношением полного порядка.