Opcje dostarczania Sybase eServer. Systemy zarządzania bazami danych i obsługa przechowywania informacji (IBM DB2)

System zarządzania bazami danych IBM DB2 rozpoczął swój rozwój w odległych latach 70. i obecnie zajmuje silną pozycję na korporacyjnym rynku DBMS, spełniając wysokie wymagania w zakresie wydajności, niezawodności, bezpieczeństwa i skalowalności.

Igor Bulatenko, Specjalista ds. Bezpieczeństwa Informacji, Positive Technologies

System zarządzania bazami danych IBM DB2 rozpoczął swój rozwój w odległych latach 70. i obecnie zajmuje silną pozycję na korporacyjnym rynku DBMS, spełniając wysokie wymagania w zakresie wydajności, niezawodności, bezpieczeństwa i skalowalności. W sektorze prywatnym DB2 nie zostało powszechnie przyjęte, pomimo dostępności bezpłatnej wersji IBM DB2 Express. Być może jest to powód, dla którego w Internecie nie ma wielu artykułów na temat konfigurowania i używania DB2.

Model bezpieczeństwa DB2 ma szeroki zakres funkcjonalności i pozwala chronić dane zarówno przed wpływami zewnętrznymi, jak i zróżnicować prawa dostępu dla użytkowników wewnętrznych korzystających z samego DBMS.

Jednak nieprzygotowanemu użytkownikowi trudno jest zrozumieć całą tę różnorodność od podstaw, dlatego kilka ważnych aspektów zostanie omówionych w tym artykule.

Punkt wejścia

Punkt wejścia do DB2 wygląda następująco: DBMS -> instancja (instancja), która może być powiązana z określonym portem -> określona nazwa bazy danych. Ustawienia zabezpieczeń można zmieniać zarówno w konkretnej instancji, jak i w konkretnej bazie danych.

Uwierzytelnianie

Uwierzytelnianie to podstawowy mechanizm bezpieczeństwa stosowany podczas próby połączenia z serwerem DB2. Uwierzytelnianie sprawdza, czy podane poświadczenia są poprawne. Główna cecha w DB2 jest to, że uwierzytelnianie użytkownika jest wykonywane tylko przez zewnętrzne wtyczki. Użytkownicy wewnętrzni, w przeciwieństwie do Oracle czy MS SQL Server, nie istnieją tutaj. Nawet funkcja tworzenia użytkownika dostępna w IBM Data Studio w rzeczywistości nie tworzy użytkownika, ale przypisuje uprawnienia do połączenia z bazą danych określonemu użytkownikowi.

Istnieje kilka opcji uwierzytelniania, żądana opcja jest kontrolowana przez parametr AUTHENTICATION w menedżerze bazy danych. Wartość tego parametru wpływa na to, gdzie klienci będą uwierzytelniani (po stronie serwera czy po stronie klienta) oraz czy dane będą przesyłane w postaci zaszyfrowanej (wartości kończące się na _ENCRYPT). Obsługiwane wartości tego parametru są dostępne pod adresem:

Konfigurację menedżera bazy danych można wyświetlić, wysyłając zapytanie do tabeli sysibmadm.dbmcfg, ale wymaga to dostępu do dowolnej bazy danych, co nie zawsze jest możliwe. Jeśli masz lokalny dostęp do serwera, możesz otworzyć procesor wiersz poleceń(db2 lub db2.exe w systemie Windows), połącz się z instancją i uruchom następujące komendy:

db2 => dołącz do db2inst1
db2 => pobierz konfigurację menedżera bazy danych

Domyślną wartością parametru AUTHENTICATION jest SERVER. Weryfikacja poprawności podanych poświadczeń użytkownika odbywa się po stronie serwera za pomocą system operacyjny, ale wszystkie dane są przesyłane w postaci zwykłego tekstu i mogą zostać przechwycone przez atakującego.

Zobaczmy, jak wyglądają przechwycone informacje w Wireshark.

Login i hasło przesłane z klienta są widoczne w pakiecie podczas przeglądania EBCDIC.

Przy zmianie typu uwierzytelniania na SERVER_ENCRYPT login i hasło zostaną przesłane w postaci zaszyfrowanej i sprawdzone po stronie serwera.

Wartość zmienia się w następujący sposób:

db2 => dołącz do db2inst1
db2 => aktualizacja konfiguracji menedżera bazy danych przy użyciu uwierzytelniania server_encrypt
db2 => db2 siła zatrzymania
db2 => db2start

Pakiet uwierzytelniający będzie wtedy wyglądał tak:

Jednak tekst wniosków i wynik nadal będą przekazywane w sposób jawny.

Pakiet żądania Wireshark:

Pakiet z odpowiedzią w Wireshark:

Jeśli parametr AUTHENTICATION jest ustawiony na DATA_ENCRYPT, to poświadczenia użytkownika są szyfrowane, podobnie jak informacje przesyłane między klientem a serwerem.

Wartość zmienia się w taki sam sposób jak w powyższym przykładzie:

db2 => dołącz do db2inst1
db2 => aktualizacja konfiguracji menedżera bazy danych przy użyciu uwierzytelniania data_encrypt
db2 => db2 siła zatrzymania
db2 => db2start

Następnie przesyłane dane zostaną również zaszyfrowane:

Należy również zwrócić uwagę na typ uwierzytelniania KLIENT. Przy tego rodzaju uwierzytelnianiu uważa się, że istnieje bezpieczny kanał komunikacji między klientem a serwerem, a jeśli użytkownik uzyskał dostęp do klienta, może uzyskać dostęp do serwera bez sprawdzania poprawności poświadczeń. Oznacza to, że uwierzytelnianie jako takie odbywa się po stronie klienta, weryfikacja nie jest przeprowadzana po stronie serwera. Nawet jeśli użytkownik łączący się z serwerem nie ma praw dostępu, nadal otrzymuje wszystkie uprawnienia, które są przypisane do grupy PUBLIC. Dlatego nie należy stosować tego typu uwierzytelniania, zapewni on atakującym możliwość uzyskania dostępu do serwera bez większego wysiłku.

Jeśli z jakiegoś powodu ten rodzaj uwierzytelnienia jest nagle potrzebny, musisz wziąć pod uwagę, że istnieją jeszcze dwa dodatkowe parametry, które ostatecznie wpływają na sposób sprawdzania poświadczeń użytkownika. Są to parametr trust_allclnts, za pomocą którego można określić, którzy klienci są uznawani za zaufanych, oraz parametr trust_clntauth, który określa, gdzie należy sprawdzić login i hasło, jeśli zostały przekazane podczas połączenia. Obie te opcje wpływają na uwierzytelnianie tylko wtedy, gdy opcja UWIERZYTELNIANIE jest ustawiona na KLIENT.

Jeśli się powiedzie, identyfikator użytkownika jest odwzorowywany na identyfikator DB2. Zazwyczaj identyfikator jest taki sam jak nazwa użytkownika, ale używa wielkich liter.

Upoważnienie

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

• SYSADM (uprawnienia administratora systemu);
• SYSCTRL (zezwolenie na sterowanie systemem);
• SYSMAINT (zezwolenie na utrzymanie systemu);
• SYSMON (uprawnienie do monitorowania systemu).

Te uprawnienia są ustawiane poprzez określenie grupy, do której będzie należeć użytkownik. W tym celu wykorzystywane są następujące parametry pliku dbmcfg (zgodnie z powyższymi uprawnieniami):

Nie jest łatwo uzyskać listę użytkowników, którzy są członkami grupy za pomocą narzędzi DB2, trzeba to zrobić w samym systemie operacyjnym lub przeanalizować, do jakich grup należy dany użytkownik (patrz zakładka "przydatne zapytania" dla zapytania ).

Podczas konfigurowania DB2 należy sprawdzić listę użytkowników, którym przypisano uprawnienie SYSADM. To uprawnienie umożliwia zarządzanie wszystkimi obiektami bazy danych.

Uprawnienia określonej bazy danych można wyświetlić w widoku SYSCAT.DBAUTH. Zwróć uwagę na uprawnienie CONNECTAUTH, które określa, czy użytkownik będzie miał dostęp do bazy danych, czy nie, oraz uprawnienie NOFENCEAUTH, które odpowiada za tworzenie niechronionych (niechronionych) procedur i funkcji. Takie procedury są wykonywane w przestrzeni adresowej bazy danych iw przypadku błędu mogą naruszyć integralność bazy danych i znajdujących się w niej tabel.

Przywilej

Uprawnienia procedur (funkcje, procedury i metody) można przeglądać w widoku SYSCAT.ROUTINEAUTH. Wszystko tutaj nie jest do końca trywialne, w zależności od pól SPECIFICNAME i TYPENAME uprawnienia można nadawać wszystkim podprogramom danego schematu.

Użytkownicy, grupy, role

Ponadto DB2 ma wbudowaną rolę PUBLIC. Użytkownikowi bazy danych nie trzeba nadać roli PUBLIC: nie można odebrać użytkownikowi roli PUBLIC. Gdy uprawnienie jest nadawane roli PUBLIC, uprawnienie to jest faktycznie przyznawane wszystkim użytkownikom bazy danych. Nie należy nadawać żadnych uprawnień do bazy danych roli PUBLIC. Uprawnienia do tabel i widoków należy przyznawać ze szczególną ostrożnością, tylko do przeglądania i bez możliwości zmiany przydziału (Z OPCĄ PRZYZNANIA).

Ze względu na specyfikę uwierzytelniania podczas nadawania uprawnień nie jest sprawdzana obecność użytkownika lub grupy w systemie. Dzięki temu użytkownicy uwierzytelniający mogą pojawić się w systemie bez powiązania z rzeczywistymi użytkownikami systemu. Takich użytkowników można znaleźć za pomocą następującego zapytania SQL:

Do wyszukiwania takich grup stosuje się podobne zapytanie, ale zapytanie wskazuje, że nie należy wyświetlać danych o PUBLIC:

LBAC

Automatyczne narzędzia do skanowania

Przydatne zapytania i polecenia

Pobierz ustawienia menedżera bazy danych:

lub

Zmień opcję menedżera bazy danych:

Następnie musisz ponownie uruchomić instancję:

Pobierz ustawienia bazy danych:

lub

Lista użytkowników systemu operacyjnego:

Lista grup systemów operacyjnych:

Wyświetl aktualną nazwę bazy danych:

Wpisz aktualną nazwę użytkownika:

Uzyskaj listę grup, do których należy użytkownik:

Lista wszystkich zainstalowanych DBMS:

Lista wszystkich instancji w DBMS:

Ogranicz liczbę linii wyjściowych:

IBM DB2 DBMS jest wynikiem blisko 30 lat prac badawczo-rozwojowych IBM. Najnowsza wersja tego systemu DBMS (6.x) zawiera jeden z najbardziej przemyślanych 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 tworzenia aplikacji, ponieważ istnieje narzędzie Stored Procedure Builder, które automatycznie konwertuje instrukcję SQL na odpowiednią klasę Java i włącza ją do struktury bazy danych. W DB2 6.1 interoperacyjność z innymi systemami DBMS została znacznie poprawiona dzięki umożliwieniu użycia specyfikacji Microsoft OLE DB, nowego standardu dostępu do baz danych. Kontrole administracyjne DB2, które są: Nowa wersja napisane na nowo w Javie i które można pobrać z Sieci zasługują na najwyższą pochwałę.

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. Cóż, można powiedzieć, że wraz z nową funkcjonalnością, a także zrównolegleniem i możliwością wyboru prawie każdego typu złączenia i indeksu (może z wyjątkiem indeksów rastrowych), model DB2 6.1 staje się najtańszym z systemów 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). Informix również podążając za tą koncepcją ogłosił 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 pozwolą programistom tworzyć w tym języku procedury składowane, programy użytkownika i moduły DataBlade, które Informix nazywa niestandardowymi rozszerzeniami baz 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łasne funkcje w zapytaniach, a nie polegać wyłącznie na standardowych narzędziach 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. Tabela podsumowująca przedstawia charakterystykę porównawczą dwóch najczęstszych rozwiązań na dzień dzisiejszy Baza Microsoft SQL Server 7.0 (na NT) i Oracle8i (na Unix, Linux).

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 mając na myśli 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, oprócz wymienionych platform, są lub zostały wydane w różne wersje także dla SINIX, IRIX, klasycznego Mac OS i dla MS-DOS, a także w wersja mobilna DB2 Wszędzie dla Windows CE, Palm OS, Symbian OS, Neutrino i Java Virtual Machine.

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, który używa 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 eksploracyjny i Produkt komercyjny, który obejmuje 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” używany był 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 relacyjne bazy danych danych i nazwał go Alpha. IBM zdecydował się zlecić dalszy rozwój grupie programistów pozostających poza kontrolą dr Codda. Naruszenie niektórych zasad model relacyjny, zaimplementowali go jako „Structured English Query Language”, 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ś.

W ten sposób DB2 ewoluowało 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

Cechy wyróżniające DB2 obejmują dialekt języka SQL, który definiuje, z rzadkimi wyjątkami, czysto deklaratywne znaczenie konstrukcji językowych oraz potężny wielofazowy optymalizator, który na podstawie tych deklaratywnych konstrukcji buduje efektywny plan wykonywania zapytań. W przeciwieństwie do innych dialektów SQL, dialekt DB2 SQL praktycznie nie posiada podpowiedzi optymalizacyjnych, niewielki (i od dawna) brak rozwoju języka procedur składowanych, a co za tym idzie 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ń tabelarycznych, 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 w DB2 nie są zbyt szeroko stosowane, a tradycyjnie do pisania procedur składowanych używa się konwencjonalnych języków programowania wysokiego poziomu (C, Java, PL/I, Cobol itp.), co pozwala programiście na łatwe formatowanie ten sam kod jako część aplikacji lub jako procedura składowana, w zależności od tego, czy bardziej odpowiednie jest wykonanie go na kliencie, czy 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 dotyczące dystrybucji danych w tabelach (jeśli proces zbierania był wykonywany przez administratora bazy danych), dzięki czemu to samo zapytanie SQL można przełożyć na zupełnie inne plany wykonania w zależności od charakterystyka statystyczna dane, które przetwarza.

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 bazy danych (odpowiedzialnego za konfigurowanie komponentów oprogramowania DB2 i optymalne ich uruchamianie w systemie komputerowym) 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, w przeciwieństwie do większości innych DBMS, pozwala na wdrożenie takiego modelu bezpieczeństwa, gdy uprawnienia do wykonywania określonych operacji mogą zostać nadane programom aplikacyjnym w przypadku braku takich uprawnień dla użytkownicy pracujący z tymi programami. Pozwala to w tym przypadku zagwarantować brak możliwości obejścia użytkownika pracującego z bazą danych program aplikacyjny, 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 to jedyny relacyjny 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ą cechą DB2 SQL Server jest jego zdolność do 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 łańcuch tekstowy opisujący błąd, jeśli pole SQLCODE jest mniejsze od zera.

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

• 1 element - informacja wewnętrzna;
• 2. element - zawiera wartość pola typu SERIAL wygenerowanego przez serwer dla instrukcji INSERT lub dodatkowy kod błędy;
• 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 UMO uczelni w zakresie bezpieczeństwa informacji jako podręcznik 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 jest ist ein kommerzielles relations Datenbank Management System (RDBMS) firmy IBM, która jest odpowiedzialna za zarządzanie systemem R und die 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

Przegląd kluczowych pojęć i ogólny opis architektury bazy 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.

Materiały źródłowe 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łu jest bezpłatna interpretacja oficjalnej dokumentacji 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, tworzenie kopii zapasowych i odzyskiwanie);
3. zaawansowane procedury administracyjne (przesyłanie 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ę od siebie 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 z rodziny DB2 z możliwościami systemów operacyjnych, na których działają, a także ze 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) oraz Microsoft Windows, której poświęcony jest ten artykuł i inne artykuły 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 funkcjonowania 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 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 systemu 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.

Przestarzałe funkcje DB2LUW

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 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 Produkt menedżera;
• 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 ogólnych, 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.

Czytelnikom zainteresowanym praktycznym przewodnikiem, jak zacząć korzystać z DB2, polecam zapoznanie 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 aktualne wersje oprogramowanie DB2 należy pamiętać, że niektóre funkcje w wersji 9.7 są przestarzałe i nie są obsługiwane w nowych wersjach produktu (patrz pasek boczny „Przestarzałe funkcje DB2 LUW”).

Funkcjonalność DB2 LUW

IBM DB2 wykorzystuje relacyjną architekturę DBMS klient-serwer, która jest obecnie powszechnie akceptowana, z przechowywaniem informacji na serwerze i aplikacjami klienckimi łączącymi się 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 transakcyjnego 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 powszechnych 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 formatach XML, JSON/BSON. Przy opracowywaniu 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 na Języki Java, C, C++ i COBOL.

Charakterystyczne cechy DB2 to:

• skalowalność, ograniczona jedynie dostępnymi zasobami obliczeniowymi oraz najbardziej ekonomiczne wykorzystanie zasobów obliczeniowych;
• rozbudowane wbudowane środki różnicowania i kontroli dostępu, co daje możliwość granularnego ograniczenia 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 być hostowanych niezależnie na tym samym serwerze, o ile nie ma między nimi konfliktów zasobów (w tym wystarczających zasobów obliczeniowych serwera i braku konfliktów dotyczących zasobów logicznych systemu operacyjnego: nazw sieci, numerów portów, katalogów systemu plików i tak dalej.).

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ę informacji (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 budowy serwera bazy danych pokazano na rysunku.

W wielu przypadkach serwer bazy danych DB2 zawiera jeden zainstalowana kopia DB2 z pojedynczą instancją utworzoną 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 rodzin systemów operacyjnych Unix i Linux każda instancja może mieć własne, specyficzne ustawienia zmiennych środowiskowych.

Ustawienia rejestru profilu DB2 można ustawić na poziomie systemu operacyjnego (globalnie) lub na poziomie instancji, przy czym ustawienia na poziomie instancji zastępują te 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 wyświetlić lub zmodyfikować za pomocą wiersza komend (komendy GET DBM CFG i UPDATE DBM CFG) oraz 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 tabeli i wpisy indeksu) są umieszczane na stronach.

Wybór dodatkowa przestrzeń do przechowywania danych przydzielane są 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. Przestrzeń tabel to nazwany zestaw kontenerów do przechowywania informacji umieszczonych w systemie plików serwera bazy danych.

Dla każdego obszaru tabel tworzony jest co najmniej jeden obszar 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:

• zwyczajny: używany do hostowania tabel i indeksów użytkowników;
• wielki: używany do hostowania tabel i indeksów użytkowników oraz danych dużych obiektów (LOB) oraz Dane XML. We współczesnych wersjach DB2 domyślnie używane są duże przestrzenie tabel zamiast zwykłych;
• tymczasowy: używany 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 ustawionej 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 tablicowe zarządzane przez bazę danych (DMS, Database Managed Storage) - wstępnie przydzielone pliki są używane jako kontenery przestrzeni tablicowej, 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ą funkcją automatycznego przechowywania (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 z rozmiarem strony 4 KB i rozmiarem 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 masowej do innej za pomocą polecenia 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. DB2 może tworzyć dodatkowe pliki dziennika w razie potrzeby, maksymalna liczba plików dziennika, które można utworzyć, 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 w przypadku potwierdzenia lub anulowania transakcji (na 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 dzienników transakcyjnych ma kluczowe znaczenie dla zapewnienia wydajności DBMS, zapewniony jest mechanizm do dublowania dzienników transakcyjnych w dwóch systemach plików (konfigurowanych przez parametr LOGMIRROR).

Kiedy zły wybór rozmiar i liczba plików dziennika transakcji, które nie odpowiadają poziomowi bieżącego obciążenia, mogą wystąpić sytuacje, gdy dziennik transakcji jest pełny z powodu niewystarczającej liczby dozwolonych do utworzenia plików dziennika lub braku dostępnego 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 takie długo trwająca transakcja wykonuje pojedynczą małą zmianę w bazie danych, która następnie pozostaje niezatwierdzona przez długi czas, odpowiedni plik dziennika transakcji pozostaje aktywny i nie może być ponownie użyty.

Istnieją dwa główne tryby działania rejestrowania transakcyjnego DB2: rejestrowanie cykliczne i rejestrowanie w archiwum. 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 zakłócania 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 dodatkowej przestrzeni dyskowej pliki archiwalne dziennik transakcji.

Organizacja buforowania danych

W celu zmniejszenia ilości wykonywanych operacji I/O, DB2, podobnie jak inne nowoczesne 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 programie DB2 można zdefiniować kilka różnych pul buforów (utworzonych za pomocą komendy CREATE BUFFERPOOL) z włączoną opcją wielkości strony, wielkości i 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. Zapewniony 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.

Kiedy 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, tło i zapewnia 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 masowej DB2 składa się z różnych obszarów pamięci masowej 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 utrzymują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ść kontrolowana jest przez parametr PCKCACHESZ;
• Pamięć podręczna katalogu - obszar buforowania katalogu systemowego, w którym znajdują się opisy wszystkich obiektów bazy danych, wielkość kontrolowana jest przez parametr CATALOGCACHE_SZ;
• Sterta narzędziowa - pamięć RAM do wykonywania operacji konserwacji bazy danych (w tym operacji tworzenia kopii zapasowych i przywracania), wielkość jest regulowana przez parametr UTIL_HEAP_SZ;
• Sterta bazy danych - pamięć RAM do obsługi operacji bazodanowych (m.in. bufor dziennika transakcji i 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:

• Application Global Memory - 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 używane do działania poszczególnych agentów obsługujących połączone aplikacje.

Opcjonalnie można przydzielić obszary pamięci, które są przydzielone dla sterownika DB2 do uruchomienia 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 odbiorców) w dowolnym momencie.

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

• Model współdzielonego obszaru 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 sortowania prywatnego (sortowanie prywatne) — używany, gdy parametr SHEAPTHRES jest niezerowy i nie ma skonfigurowanej współdzielonej pamięci sortowania. 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

Dostępność duża liczba różne obszary pamięci RAM i parametry rządzące ich rozmiarami mogą wymagać znacznego wysiłku przy ręcznym dostrojeniu 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 samostrojenia 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 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 baz 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 jednej z dozwolonych wartości obsługiwanego typu 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 (ciąg o zerowej długości) a wartością NULL typu string. Ta cecha wpływa na kolejność wyszukiwania (za pomocą 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.

W razie potrzeby podaj wydajna praca przy dokładnych liczbach dziesiętnych, które zawierają część ułamkową (na przykład w aplikacjach finansowych), sensowne jest użycie typu danych DECFLOAT, który łączy dokładną reprezentację wartości DECIMAL i możliwość wydajnego obliczania wartości 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 nakładają ograniczenia na kompozycję 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 jednocześnie możliwe wartości jednej lub kilku kolumn w rekordzie.

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 przy poprawianiu danych.

Ponieważ mechanizm restrykcji powoduje 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ć wykorzystana od razu, 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 jest nazywany klastrowanym (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 ściśle 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 odbywa 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. Aby ułatwić aktualizację (zastępowanie) 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 nadane imię został już utworzony).

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ą scentralizowaną lokalizację do przechowywania kodu, dzięki czemu inne aplikacje mogą korzystać z tych samych procedur składowanych. 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

Jednym z podstawowych zasobów informacyjnych SZBD jest katalog systemowy, który przechowuje i udostępnia 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 pozostałych tabel katalogu systemowego znajduje się w .

Organizacja równoległego przetwarzania transakcyjnego

Transakcje

Transakcja (lub jednostka pracy) składa się z co najmniej jednego Instrukcje SQL, które po wykonaniu są traktowane jako odrębna 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ę oświadczeniem ROLLBACK lub awaryjnym (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 pojedynczego wyciągu, który zapisuje dane, wszystkie zmiany dokonane tym wyciągiem 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). Korzystanie z punktów wycofania umożliwia aplikacji selektywne cofanie działań podjętych w ramach transakcji, co może być przydatne podczas obsługi 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, wymagana jest kontrola nad równoległym wykorzystaniem 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) — ustawiana, gdy aplikacja odczytuje dane i uniemożliwia innym aplikacjom wprowadzanie zmian w tym samym wierszu.
• Wyłączna blokada (X) — ustaw, kiedy aplikacja aktualizuje, wstawia lub usuwa wiersz.

Jeśli dwie lub więcej aplikacji musi wykonać operację na tym samym obiekcie, jedna z nich będzie musiała 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 impasu jest spowodowany nieprawidłową strukturą lub logiką aplikacji.

DB2 automatycznie wykrywa sytuacje zakleszczeń, przeprowadzając odpowiednie sprawdzenia w odstępach czasu określonych przez parametr DLCHKTIME. Gdy wykryje, że faktycznie 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 wbudowanej ochrony DB2 przed problemami wymienionymi powyżej odbywa się poprzez ustawienie używanego poziomu izolacji. Poziomy izolacji można traktować jako polityki blokujące, w których, w zależności od wybranego poziomu izolacji, można je osiągnąć różne opcje blokady 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 (Cursor Stability, CS);
• stabilność odczytu (stabilność odczytu, RS);
• powtarzane czytanie (Repeatable Read, RR).

Nieautentyczne czytanie zwany także „brudnym”. Jest to najniższy poziom izolacji, który umożliwia najwyższy stopień współbieżności. 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 przy UR operacja odczytu otrzymuje niepoprawne wartości, natomiast przy semantyce CC otrzymuje wartości aktualnie akceptowane. 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. Więc zastosowanie ten tryb Izolacja może spowodować, że aplikacja uzyska dużą liczbę blokad, a jeśli zostaną osiągnięte ustawione limity, blokady mogą zostać eskalowane z poziomu wiersza do poziomu tabeli. Jednak na poziomie izolacji stabilności odczytu 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ść. Na wiersze, 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, korzystając z poziomu izolacji Powtarzanego odczytu, może uwzględnić jawne operacje blokowania na poziomie tabeli w planie wykonania zapytania, gdy odpowiadające im zapytania wymagają skanowania wszystkich wierszy tabeli (co oznacza, że ​​każdy wiersz tabeli musi być zablokowany podczas wykonanie 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.

DB2 (wymawiane po rosyjsku "dibi two", kalka kreślarska z angielskiego "dibitu" jest również powszechna) to rodzina produktów oprogramowania do zarządzania informacjami firmy IBM. Najczęściej, odnosząc się do DB2, mają na myśli system zarządzania relacyjną bazą danych DB2 Universal Database (DB2 UDB), opracowany i wydany przez IBM.

Pomimo przychylnego nastawienia do systemu operacyjnego Linux, który jest dystrybuowany na licencji open source, IBM nie planuje jeszcze open source swojej bazy danych DB2. Zadeklarował to dyrektor centrum IBM Linux Technology Jim Vasco podczas ostatniej (kwiecień 2011) dorocznej konferencji Linux Foundation Collaboration Summit w San Francisco. Wewnątrz IBM toczy się nieustanna walka między przedstawicielami różnych działów – wyjaśnił Vasco. W niektórych przypadkach wybór systemu Linux lub Windows oznacza niższe przychody z oprogramowania, ale wyższe przychody z usług, podczas gdy w innych przypadkach mogą to być przychody ze sprzętu. Musimy szukać optymalnego rozwiązania – podsumował. Przesyłanie pakietów do Oracle z otwarte źródło, rozwijany w Sun Microsystems, stworzył pewne problemy dla IBM, powiedział Vasco. Oracle stara się przekonać klientów do wymiany sprzętu IBM na własne serwery Exadata i bazę danych Oracle. W 2011 roku dyrektor Linux Foundation Jim Zemlin spodziewa się opracowania opartych na Linuksie wyspecjalizowanych systemów o wysokiej wydajności, takich jak IBM Watson, oraz gotowych urządzeń, które wymagają minimalnej konfiguracji.

Realizacje

Obecnie oprócz komercyjnych produktów z rodziny IBM dystrybuuje również darmową dystrybucję DB2 Express-C dla Linux (x86, x86-64, POWER), Windows (x86, x86-64), Solaris (x86-64), Platformy Mac OS X. (x86-64 beta). Darmowa wersja ma ograniczenia dotyczące używania nie więcej niż jednego dwurdzeniowego procesora i 2 GB pamięci RAM dla DBMS (łączna liczba procesorów i pamięci w systemie może być dowolna, ale zasoby przekraczające określone limity nie zostaną wykorzystane przez SZBD).

2017: Ogłoszenie dodatków do kontroli danych

Db2 w chmurze

Zaktualizowane rozwiązanie Db2 on Cloud to w pełni zarządzana usługa dostępna w chmurze IBM.

Funkcje technologiczne obejmują:

• Skala dynamiczna („suwak”) do ustawiania parametrów wydajności i pamięci - jednym kliknięciem myszy możesz błyskawicznie zmienić skalę, zwiększając lub zmniejszając wydajność przetwarzania danych oraz wymaganą ilość pamięci RAM, w ten sam sposób możesz zwiększyć ilość pamięci systemu przechowywania informacji;
• Konsola internetowa - pomaga klientom szybko opanować usługę i przyspieszyć z nią pracę.

Ogólnie rzecz biorąc, Db2 on Cloud pozwala uniknąć czasochłonnego procesu negocjacji i zakupu dodatkowych zasobów obliczeniowych oraz uzupełnia IBM Db2 Hosted, wersję bazy danych hostowaną w chmurze IBM Cloud.

Db2 w Cloud Benchmark

Akcelerator DB2 Analytics

Wersje

2017: JSON i HTTP

DB2 10 to pierwsza duża aktualizacja DBMS od kilku lat: wersja systemu z/OS 10 została wydana w 2010 roku, ale ta wersja jest przeznaczona zarówno dla systemów Linux, Unix, jak i Windows.

Oba produkty zawierają nową funkcjonalność. DB2 obsługuje teraz format RDF (Resource Description Framework), a InfoSphere może współpracować z wdrożeniami Apache Hadoop. Inne ulepszenia w DB2 to m.in. szybsze tworzenie kopii zapasowych i procesy we/wy.

DB2 10 jest również bardziej elastyczny. W szczególności administratorzy DBMS otrzymali narzędzia do dystrybucji danych do przechowywania na całym obszarze różne rodzaje nośniki danych: na przykład informacje operacyjne można przechowywać na szybszych dyskach półprzewodnikowych, podczas gdy mniej wartościowe dane można przechowywać na tańszych i wolniejszych napędach taśmowych.

Nowa funkcja o nazwie podróże w czasie pozwala na wydajniejsze zarządzanie danymi czasowymi i okazała się wielkim sukcesem dla użytkowników wersji 10 for z/OS. Za jego pomocą użytkownik lub program może badać dane w kontekście czasu ich istnienia w SZBD dla zadanych okresów. Korzystanie z takich środowisk ma znaczenie dla analityki.

DB2 10 można pobrać bezpłatnie do użytku w środowisku produkcyjnym z maksymalnie dwoma rdzeniami procesora i 2 GB pamięci. Bardziej funkcjonalne wersje będą kosztować od 6180 USD, co obejmuje koszt rocznej konserwacji. Koszt InfoSphere zależy od liczby procesorów lub ilości przechowywanych danych, podstawowe wersje kosztują około 40 tysięcy dolarów za TB.

Wersja IBM DB2 10.5

Fabuła

DB2 ma długą historię i jest uważany przez niektórych za pierwszy DBMS, który używa 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 ten system miał charakter badawczy, a komercyjny produkt zawierający SQL był po raz pierwszy wydany przez Oracle w 1979 roku.

DB2 otrzymało swoją nazwę w 1982 roku wraz z pierwszym komercyjnym wydaniem maszyny wirtualnej o nazwie SQL/DS, a następnie wydaniem MVS o nazwie DB2. Przez długi czas wraz z „DB2” używany był 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 siedemdziesiątych, kiedy to dr E.F. Codd, pracujący 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 „Structured English Query Language”, 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ś.

W ten sposób DB2 ewoluowało 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). Następnie inny zespół programistów w IBM wdrożył 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

Cechy wyróżniające DB2 obejmują dialekt języka SQL, który definiuje, z rzadkimi wyjątkami, czysto deklaratywne znaczenie konstrukcji językowych oraz potężny wielofazowy optymalizator, który na podstawie tych deklaratywnych konstrukcji buduje efektywny plan wykonywania zapytań. W przeciwieństwie do innych dialektów SQL, dialekt DB2 SQL praktycznie nie posiada podpowiedzi optymalizacyjnych, niewielki (i od dawna) brak rozwoju języka procedur składowanych, a co za tym idzie 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ń tabelarycznych, 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ą zbyt szeroko stosowane w DB2 i tradycyjnie do pisania procedur składowanych używa się konwencjonalnych języków programowania wysokiego poziomu (C, Java, PL/I, COBOL itp.), co pozwala programiście na łatwe formatowanie ten sam kod jako część aplikacji lub jako procedura składowana, w zależności od tego, czy bardziej odpowiednie jest wykonanie go na kliencie, czy 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 dotyczące dystrybucji danych w tabelach (jeśli proces zbierania danych wykonywał administrator bazy danych), dzięki czemu to samo zapytanie SQL można przełożyć na zupełnie inne plany wykonania, w zależności od charakterystyki statystycznej przetwarzanych przez nią 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 bazy danych (odpowiedzialnego za konfigurowanie komponentów oprogramowania DB2 i optymalne ich uruchamianie w systemie komputerowym) 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, w przeciwieństwie do większości innych DBMS, pozwala na wdrożenie takiego modelu bezpieczeństwa, gdy uprawnienia do wykonywania określonych operacji mogą zostać nadane programom aplikacyjnym w przypadku braku takich uprawnień dla użytkownicy pracujący z tymi programami. W takim przypadku daje to możliwość zagwarantowania braku 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.