Transakcja: ciąg zawierający jedno lub wiele poleceń SQL, zgrupowanych razem jako jedna logiczna jednostka działań, której nie

Transkrypt

1 Transakcje Transakcja: ciąg zawierający jedno lub wiele poleceń SQL, zgrupowanych razem jako jedna logiczna jednostka działań, której nie można podzielić. Logiczna jednostka działań to zbiór logicznych zmian w bazie danych, które należy albo wprowadzić wszystkie albo nie wprowadzać żadnej. Mechanizm transakcji zapewnia pozostawanie bazy w spójnym (poprawnym) stanie pomimo wystąpienia błędu gdziekolwiek w systemie (np. przerwa w zasilaniu) lub w samej transakcji. Reguła ACID opisuje, jakie cechy powinna mieć transakcja: Niepodzielna (Atomic) Spójna (Consistent) Odizolowana (Isolated) Trwała (Durable)

2 DB2 zamiast nazwy "transakcja" używa pojęcia "jednostka pracy" (unit of work). Na wykładzie będziemy tradycyjnie używali pojęcia transakcji.

3 DB2 zamiast nazwy "transakcja" używa pojęcia "jednostka pracy" (unit of work). Na wykładzie będziemy tradycyjnie używali pojęcia transakcji. W DB2 transakcja jest rozpoczynana niejawnie, w momencie wykonania pierwszego polecenia SQL. Transakcja jest zatwierdzana i kończy się w chwili wykonania instrukcji COMMIT. Wówczas wszystkie modyfikacje danych zostają zapisane w bazie. Uwaga. Edytory SQL mają często ustawioną domyślnie opcję autocommit. Transakcje w takim wypadku zatwiedzane są bez wykonania przez nas instrukcji COMMIT, tylko automatycznie po wykonaniu każdej instrukcji SQL. Instrukcja ROLLBACK wycofuje wszystkie modyfikacje danych w ramach jednej transakcji. Możemy ją zastosować jeśli się np. pomylimy. Ta instrukcja nie zadziała, jeśli wcześniej wykonamy COMMIT. Transakcja w takim wypadku została już zakończona.

4 Dowolna transakcja w bazie danych powinna być odizolowana od wszystkich pozostałych transakcji, które są wykonywane w tym samym czasie. W idealnej sytuacji każda transakcja zachowuje się tak, jakby posiadała wyłączny dostęp do bazy danych. Niestety, realia związane z wymaganiem osiągnięcia dobrej wydajności wymuszają poszukiwanie kompromisów (pomiędzy izolowaniem transakcji a wydajnością bazy).

5 Dane zatwierdzone (committed) i niezatwierdzone (uncommitted) Dane zatwierdzone (committed data) charakteryzują się tym, że są spójne w bazie danych; zostały zatwierdzone za pomocą polecenia COMMIT (wydanego w sposób jawny lub nie); zatwierdzone zmiany mogą zostać wycofane (usunięte) jedynie za pomoca kolejnego polecenia (lub kilku poleceń) SQL, w nowej transakcji; są widoczne i dostępne dla wszystkich użytkowników i aplikacji. Dane niezatwierdzone (uncommitted data) charakteryzują się tym, że mogą nie być spójne w bazie danych; sa to zmiany, które zostały wprowadzone w bieżącej transakcji, zanim zostało wydane polecenie COMMIT; mogą zostać wycofane za pomoca kolejnego polecenia ROLLBACK; nie są widoczne ani dostępne dla innych użytkowników i aplikacji (od tej zasady są wyjatki).

6 Współbieżność w DB2 W sytuacji, gdy wielu użytkowników (aplikacji) jednocześnie uzyskuje dostęp do tych samych zasobów, mówimy o współbieżnym dostępie. Jeżeli w danym momencie dostęp do danych uzyskuje wiele transakcji, może to prowadzić do niepożądanych zjawisk, wśród których wyróżniamy: Utracone aktualizacje (Lost Update); Brudny odczyt (Uncommitted Read); Odczyty nie dające się powtórzyć (Non-repeatable Read); Odczyty widmo (Phantom Read). Wynika stąd konieczność kontroli nad stopniem współbieżności danych, aby zachować odpowiednią stabilność danych; nie tracąc wymaganej wydajności.

7 Niepożądane zjawiska związane z problemem współbieżnego dostępu: Utracone aktualizacje (Lost Update) - zachodzi gdy dwie transakcje odczytują te same dane i obie próbują je zmodyfikować, co skutkuje utratą zmian wprowadzonych przez jedną z nich, np. transakcja nr 1 i transakcja nr 2 odczytują ten sam wiersz danych i obliczają nowe wartości danych, na podstawie tego, jakie wartości aktualnie się w tym wierszu znajdują; transakcja nr 1 aktualizuje wiersz za pomocą wyliczonej wartości, następnie to samo robi transakcja nr 2; zmiana wprowadzona przez transakcję nr 1 jest utracona.

8 Niepożądane zjawiska związane z problemem współbieżnego dostępu: Utracone aktualizacje (Lost Update) - zachodzi gdy dwie transakcje odczytują te same dane i obie próbują je zmodyfikować, co skutkuje utratą zmian wprowadzonych przez jedną z nich, np. transakcja nr 1 i transakcja nr 2 odczytują ten sam wiersz danych i obliczają nowe wartości danych, na podstawie tego, jakie wartości aktualnie się w tym wierszu znajdują; transakcja nr 1 aktualizuje wiersz za pomocą wyliczonej wartości, następnie to samo robi transakcja nr 2; zmiana wprowadzona przez transakcję nr 1 jest utracona. Brudny odczyt (Uncommitted Read) - ma miejsce wtedy, gdy pewne instrukcje SQL wewnątrz jednej transakcji odczytują dane, które zostały zmienione przez inną transakcję, ale nie zatwierdzone jeszcze poleceniem COMMIT; jeżeli pierwsza transakcja zostanie wycofana poleceniem ROLLBACK, druga transakcja odczytała dane, które nigdy tak naprawdę nie były zapisane w bazie.

9 Odczyty nie dające się powtórzyć (Non-repeatable Read) - zachodzi wtedy, gdy transakcja odczytuje zbiór danych, następnie czyta dane ponownie i okazuje się, że dane nie są identyczne, np. transakcja nr 1 odczytuje wiersz danych, potem transakcja nr 2 zmienia albo usuwa ten wiersz i zatwierdza zmiany COMMIT; kiedy transakcja nr 1 ponownie odczytuje ten sam wiersz, otrzymuje inne dane (jeżeli wiersz został zmodyfikowany) lub okazuje się, że takiego wiersza nie ma (został usunięty).

10 Odczyty nie dające się powtórzyć (Non-repeatable Read) - zachodzi wtedy, gdy transakcja odczytuje zbiór danych, następnie czyta dane ponownie i okazuje się, że dane nie są identyczne, np. transakcja nr 1 odczytuje wiersz danych, potem transakcja nr 2 zmienia albo usuwa ten wiersz i zatwierdza zmiany COMMIT; kiedy transakcja nr 1 ponownie odczytuje ten sam wiersz, otrzymuje inne dane (jeżeli wiersz został zmodyfikowany) lub okazuje się, że takiego wiersza nie ma (został usunięty). Odczyty widmo (Phantom Read) - zachodzi, gdy wiersz danych spełnia kryteria wyszukiwania, ale nie zostaje początkowo znaleziony; np. transakcja nr 1 wybiera zbiór wierszy spełniających pewne kryterium, transakcja nr 2 dodaje nowy wiersz, spełniający to kryterium; następnie transakcja nr 1 ponownie wywołuje zapytanie, które teraz zwraca inny zbiór wierszy, niż poprzednio (nowy wiersz dodany przez transakcję nr 2 zostanie uwzględniony).

11 Poziomy izolacji transakcji BD2 rozwiązuje problem współbieżności za pomocą poziomów izolacji transakcji i mechanizmu blokad. Na żadnym z poziomów izolacji DB2 nie wystąpi zjawisko utraconych aktualizacji (Lost Update). Każdy zmieniany lub wstawiany rekord jest automatycznie blokowany. Poziom izolacji transakcji określa, jak dane są oddzielone od innych wspóbieżnych transakcji oraz jakie blokady zostały na nie nałożone. Ma znaczenie w trakcie trwania danej transakcji. Wyróżniamy cztery poziomy izolacji: Repeatable Read (RR) Read Stability (RS) Cursor Stability (CS) Uncommitted Read (UR)

12 Poziomy izolacji Repeatable Read (RR) - najwyższy poziom izolacji. Nie dopuszcza żadnego z opisanych wcześniej niepożądanych zjawisk. Blokowana jest cała tabela lub widok, wykorzystywany w zapytaniu (dokładniej: blokowany jest cały zbiór rekordów, które były odczytane, aby stworzyć wynik zapytania, a nie tylko te rekordy, które rzeczywiście zostały przez zapytanie zwrócone). Zapewnia najmniejszą współbieżność dostępu do danych. RR jest najmniej korzystny z punktu widzenia wydajności. Zalecany, gdy stabilność danych jest istotniejsza od wydajności, a zmiany w zwracanym przez zapytanie wyniku niedopuszczalne.

13 Poziomy izolacji Read Stability (RS) - kolejny poziom izolacji. Nie wystąpi brudny odczyt (Uncommitted Read) ani odczyty nie dające się powtórzyć (Non-repeatable Read). Może pojawić się odczyt widmo (Phantom Read). Blokada jest nakładana tylko na wybierane lub modyfikowane wiersze, a nie na całą tabelę. Zalecany, gdy wymagany jest współbieżny dostęp do danych; zwracany zbiór wierszy musi pozostać stabilny w czasie całej transakcji; mogą pojawić się nowe wiersze (jeżeli zostały wstawione wiersze spełniające kryterium wyboru).

14 Poziomy izolacji Cursor Stability (CS) - domyślny poziom izolacji dla transakcji. Nie może pojawić się zjawisko brudnego odczytu. Może zajść odczyt widmo lub odczyty nie dające się powtórzyć. Blokada jest nakładana tylko na aktualnie odczytywany wiersz. Używany, aby zmaksymalizować współbieżność dostępu do danych, ale uniemożliwić odczytanie niezatwierdzonych danych (uncommitted read).

15 Poziomy izolacji Cursor Stability (CS) - domyślny poziom izolacji dla transakcji. Nie może pojawić się zjawisko brudnego odczytu. Może zajść odczyt widmo lub odczyty nie dające się powtórzyć. Blokada jest nakładana tylko na aktualnie odczytywany wiersz. Używany, aby zmaksymalizować współbieżność dostępu do danych, ale uniemożliwić odczytanie niezatwierdzonych danych (uncommitted read). Uncommitted Read (UR) - najniższy poziom izolacji. Może zajść brudny odczyt, odczyt widmo lub odczyty nie dające się powtórzyć. Blokada dotyczy tylko zmienianych wierszy. Transakcja na tym poziomie izolacji może odczytywać zmiany danych wprowadzone przez inne transakcje, zanim zostaną one zatwierdzone poleceniem COMMIT. Zapewnia maksymalną współbieżność. Używany, gdy: zadajemy tylko zapytania SELECT; dopuszczalny jest odczyt niezatwierdzonych danych.

16 Dlaczego kopia zapasowa? Dlaczego warto tworzyć kopie zapasowe danych? Tworzenie kopii zapasowych danych jest istotne dla firm: Utracenie informacji może spowodować poważny kryzys lub gorzej, doprowadzić do upadłości przedsiębiorstwa. Typowe problemy: awaria systemu awaria zasilania uszkodzenie transakcji użytkownicy mogą przypadkowo uszkodzić bazę awaria dysku serwer bazy może zostać uszkodzony w wyniku pożaru, powodzi lub innej katastrofy. DB2 udostępnia narzędzia tworzenia kopii zapasowych (backup) i odzyskiwania danych (recovery), aby zapewnić danym bezpieczeństwo.

17 Mechanizm dzienników transakcji Zadanie dzienników (logów) transakcji: Śledzenie zmian wprowadzonych do obiektów bazy danych i ich danych. Podczas procesu odzyskiwania DB2 analizuje dzienniki i decyduje, które zmiany należy wprowadzić, a które odrzucić. Transakcje w buforze dziennika są rejestrowane w (pliku) dziennika transakcji, w poniższych sytuacjach: Bufor dziennika jest pełny Liczba zatwierdzeń osiągnąła wartość MINCOMMIT Upłynęła jedna sekunda.

18 Statusy dzienników: aktywne dzienniki informacje o transakcjach, które nie zostały jeszcze zatwierdzone ani wycofane; dzienniki archiwalne dostępne online logi zakończonych transakcji, w aktywnym katalogu dzienników dzienniki archiwalne dostępne offline logi zakończonych transakcji, przechowywane oddzielnie, często na innym nośniku

19 Metody archiwizacji dziennika Circular Logging podstawowe pliki dziennika są używane do zapisania wszystkich transakcji; wykorzystywane ponownie, gdy transakcje zostają zakończone; dodatkowe pliki dziennika są alokowane w razie potrzeby, gdy nie jest dostępny kolejny podstawowy plik dziennika (transakcje nadal są aktywne); jeżeli zarówno podstawowe jak i dodatkowe pliki dziennika są pełne i nie mogą być ponownie wykorzystane, występuje błąd zapełnienia dziennika i jest zwracany komunikat o błędzie SQL0964C; dozwolone są tylko pełne, offlinowe backupy bazy danych; nie ma możliwości odtworzenia danych z dzienników (mechanizm roll-forward nie jest dostępny).

20 Metody archiwizacji dziennika Archival Logging określane za pomocą parametru konfiguracyjnego bazy LOGARCHMETH1; wszystkie pliki dziennika są przechowywane, aby umożliwić odtwarzanie danych z dzienników i backupy w trybie online; dzienniki mogą być opcjonalnie archiwizowane do innej lokalizacji (archiwum,) gdy nie są już aktywne, aby uniknąć zapełnienia katalogu dziennika.

21 Tworzenia kopii zapasowych Backup bazy danych: kopia bazy albo przestrzeni tablicowej; zawiera dane użytkowników; katalogi systemowe DB2; wszystkie pliki kontrolne, np. pliki puli buforów, przestrzeni tablicowych, pliki konfiguracyjne bazy. Dwa tryby wykonywania backupów: Offline Backup w trakcie wykonywania kopii nie może być żadnego innego połączenia z bazą; jedyna możliwość wykonania kopii, jeżeli używamy metody archiwizacji dzienników circular logging. Online Backup inne procesy lub aplikacje mogą mieć dostęp do bazy danych; dane są dostepne dla użytkowników podczas wykonywania backupu; wymaga aktywnej opcji archival logging.

22 Instrukcja tworzenia backupów: składnia: db2 backup database <db_name> <online> to <dest_path> online backup: db2 backup database mydb online to c:/db2inst1/backups offline backup: db2 backup database mydb to c:/db2inst1/backups

23 Kopia zapasowa bazy danych - konwecja nadawania nazwy pliku: SAMPLE.0.DB2INST.NODE0000.CATN Alias bazy typ backupu instancja węzeł węzeł katalogu data i czas numer kolejny. Typ backupu: 0 = pełna kopia; 3 = kopia przestrzeni tablicowej.

24 Kopia zapasowa przestrzeni tablicowej DB2 daje możliwość tworzenia kopii wybranych przestrzeni tablicowych. Mechanizm tworzenia kopii na poziomie przestrzenie tablicowych: pozwala użytkownikom na stworzenie kopii tylko części bazy; kilka przestrzeni tablicowych może być wybranych jednocześnie; tylko, jeżeli baza używa metody archival logging; dostępny jako backup w trybie online i offline; przestrzeń tablicowa może zostać odzyskana z pełnego backupu bazy danych lub z backupu danej przestrzeni tablicowej. Tworzenie backupu przestrzeni tablicowej (używamy słowa kluczowego TABLESPACE): db2 backup database mydb1 TABLESPACE (TBSP1) ONLINE to c:/db2inst1/backup

25 Kopie przyrostowe bazy Zamiast tworzyć pełną kopię bazy, można tworzyć tylko kopię tych danych, które zostały zmienione od czasu wykonania ostatniego pełnego backupu. W DB2 są dostępne dwa typy backupów przyrostowych: backup przyrostowy (inaczej skumulowany) - kopia zapasowa wszystkich danych bazy, które zmieniły się od momentu wykonania ostatniego, pomyślnego pełnego backupu bazy. backup przyrostowy typu delta - kopia zapasowa wszystkich danych bazy, które zmieniły się od momentu wykonania ostatniego, pomyślnego (pełnego, przyrostowego lub delta) backupu bazy. parametr konfiguracyjny bazy TRACKMOD musi być ustawiony na ON; pozwala na wykonywanie backupu bazy lub przestrzeni tablicowej; metoda odpowiednia dla dużych baz, w których występuje znaczna oszczędność miejsca przy tworzeniu kopii tylko tych danych, które zostały ostatnio zmienione.

26 Tryby odzyskiwania bazy danych odzyskiwanie po awarii lub restarcie chroni bazę przed utratą spójności danych (np. w przypadku utraty zasilania); odzyskiwanie wersji bazy danych odzyskuje zrzut bazy; odtwarzanie zmian (roll forward) rozszerza możliwości odzyskiwania wersji bazy danych, poprzez połączenie odzyskiwania danych z kopii zapasowej z odtwarzaniem danych z plików dziennika.

27 Narzędzie przywracania w DB2 jest uzupełnieniem mechanizmu tworzenia kopii zapasowych. Pozwala przywrócić bazę danych lub przestrzeń tablicową na podstawie utworzonego wcześniej backupu. Parametr TAKEN AT pozwala określić, który z dostępnych plików zawierających kopie danej bazy należy wybrać do odzyskiwania danych - określa znacznik czasu wykonania kopii (który jest wyświetlany po pomyślnym wykonaniu backupu). Przykład: plik kopii bazy: SAMPLE.0.DB2INST.NODE0000.CATN instrukcja odzyskiwania danych z tego backupu: RESTORE DATABASE dbalias FROM <db_path> TAKEN AT

28 Po odzyskaniu danych baza może być w trybie roll forward pending (dzieje się tak, gdy odtwarzamy dane z kopii przestrzeni tablicowej, mamy aktywną metodę archiwizacji dziennika archival logging). Można teraz wykonać operację odtwarzania danych z plików dziennika (roll forward), która pozwala na odtworzenie zmian, które zostały wprowadzone po wykonaniu backupu. Można odtworzyć dane do końca dzienników lub do momentu w czasie. Jeżeli wybierzemy drugą opcję, zmiany wprowadzone po podanym momencie w czasie nie zostaną uwzględnienione. Odtwarzanie danych do końca dzienników i wyjście z trybu roll forward pending: ROLLFORWARD DATABASE sample TO END OF LOGS AND COMPLETE;

29 Narzędzia do przenoszenia danych Narzędzia do przenoszenia danych umożliwiają: przenoszenie danych pomiędzy tymi samymi bazami, różnymi bazami, na tej samej lub innej platformie sprzętowej. Narzędzia do przenoszenia danych: EXPORT IMPORT LOAD wraz z komendą SET INTEGRITY

30 Mechanizm przenoszenia danych Mamy dwie bazy danych: A i B. Używając narzędzia EXPORT możemy wyeksportować tabelę do pliku, który ma jeden z poniższych formatów: DEL = Delimited ASCII, IXF = Integrated Exchange Format Po wyeksportowaniu danych do pliku, narzędzie IMPORT służy do ponownego zaimportowania tych danych do tabeli. Tabela musi istnieć w przypadku formatu: DEL, a nie jest to konieczne dla IXF. Innym sposobem na załadowanie danych jest narzędzie LOAD, a następnie wydanie polecenia SET INTEGRITY.

31 Formaty plików Narzędzie EXPORT pozwala wyeksportować tabelę do pliku. Możliwe formaty: Pliki tekstowe: DEL = Delimited ASCII Mogą być otwarte i przeglądane w dowolnym edytorze tekstowym. IXF = Integrated Exchange Format Przenosi nie tylko dane, ale rownież definicje obiektów w postaci instrukcji DDL. Wygodne, gdy potrzebujemy odtworzyć tabelę bezpośrednio z pliku IXF (to nie jest możliwe w przypadku innych formatów).

32 Narzędzie EXPORT Narzędzie EXPORT jest wykorzystywane do eksportowania danych z tabeli do jednego z wcześniej podanych typów plików. Faktycznie przetwarzane jest tylko zapytanie SQL SELECT. Składnia polecenia: EXPORT TO <file-name> OF <file-type> <select-statement>

33 Narzędzie EXPORT Narzędzie EXPORT jest wykorzystywane do eksportowania danych z tabeli do jednego z wcześniej podanych typów plików. Faktycznie przetwarzane jest tylko zapytanie SQL SELECT. Składnia polecenia: EXPORT TO <file-name> OF <file-type> <select-statement> Przykład: Eksport do pliku employee.ixf, w formacie IXF, 10 wierszy z tabeli employee: EXPORT TO employee.ixf OF IXF SELECT * FROM employee FETCH FIRST 10 ROWS ONLY

34 Narzędzie EXPORT Narzędzie EXPORT jest wykorzystywane do eksportowania danych z tabeli do jednego z wcześniej podanych typów plików. Faktycznie przetwarzane jest tylko zapytanie SQL SELECT. Składnia polecenia: EXPORT TO <file-name> OF <file-type> <select-statement> Przykład: Eksport do pliku staff.del, w formacie DEL, wszystkich wierszy z tabeli STAFF, określając znak pojedynczego cudzysłowu jako znak ograniczający dane tekstowe, średnik jako separator kolumny, przecinek jako separator miejsc dziesiętnych: export to staff.del of del modified by chardel" coldel; decpt, select * from staff

35 Narzędzie EXPORT Narzędzie EXPORT jest wykorzystywane do eksportowania danych z tabeli do jednego z wcześniej podanych typów plików. Faktycznie przetwarzane jest tylko zapytanie SQL SELECT. Składnia polecenia: EXPORT TO <file-name> OF <file-type> <select-statement> Uwaga. Jeżeli nie podamy pełnej ścieżki dostępu do pliku wynikowego, zostanie on zapisany w bieżącym katalogu. Jeżeli plik o takiej nazwie już istnieje, zostanie nadpisany.

36 Narzędzie IMPORT Narzędzie IMPORT używane jest do importowania danych z pliku do tabel. W rzeczywistości podczas operacji wykonywane jest polecenie SQL INSERT. Podczas operacji IMPORT aktywowane są wszystkie wyzwalacze i sprawdzane są więzy integralności. Może zostać wykorzystane do odtworzenia tabeli, dodania danych do istniejącej tabeli lub stworzenia nowej tabeli z danymi. Składnia polecenia: IMPORT FROM <file-name> OF <file-type> <import-mode> INTO <table-name>

37 Narzędzie IMPORT Narzędzie IMPORT używane jest do importowania danych z pliku do tabel. W rzeczywistości podczas operacji wykonywane jest polecenie SQL INSERT. Podczas operacji IMPORT aktywowane są wszystkie wyzwalacze i sprawdzane są więzy integralności. Może zostać wykorzystane do odtworzenia tabeli, dodania danych do istniejącej tabeli lub stworzenia nowej tabeli z danymi. Składnia polecenia: IMPORT FROM <file-name> OF <file-type> <import-mode> INTO <table-name> Przykład: Import z pliku employee.ixf, w formacie IXF, do tabeli employee_copy (opcja REPLACE - zawartość tabeli zostanie nadpisana): IMPORT FROM employee.ixf OF IXF REPLACE INTO employee_copy

38 Opcje narzędzia IMPORT Możliwe tryby (opcje) wywołania narzędzia IMPORT: INSERT: dodaje dane do tabeli, bez zmiany istniejących danych; INSERT_UPDATE: dodaje nowe wiersze do tabeli lub modyfikuje już istniejące dane (dopasowuje wiersze na podstawie wartości klucza głównego); REPLACE: usuwa wszystkie wiersze istniejące w tabeli, wstawia dane z pliku, nie zmienia tabeli ani definicji indeksów, REPLACE_CREATE: działa tak samo jak REPLACE, jeżeli tabela istnieje, jeżeli tabela nie istnieje, tworzy tabelę i definiuje dla niej indeksy oraz wstawia dane (opcja dostępna tylko dla importu z plików IXF; oznaczona jako niezalecana); CREATE: tworzy tabelę oraz wstawia do niej dane (tylko z plików IXF; oznaczona jako niezalecana); jeżeli eksport danych był z tabeli DB2, także tworzone są indeksy.

39 Import z pliku tekstowego ASC Dane w pliku ASC są zorganizowane w postaci kolumn, umieszczonych na odpowiednich pozycjach w pliku. W takim pliku nie ma separatorów danych. Dla przykładu, pierwszych 10 wierszy tabeli employee zostało wyeksportowanych do pliku ASC (cztery pola z danymi (EMP_ID, DATE_OF_BIRTH, SALARY i EMP_NAME) zostały wyróżnione kolorami): Importując dane z pliku ASC trzeba określić początkową i końcową pozycję dla danych odpowiadających poszczególnym kolumnom wynikowej tabeli (opcja METHOD L ).

40 Import z pliku tekstowego ASC Import danych z pliku EMP_DATA.ASC (początkową i końcową pozycję dla danych odpowiadających poszczególnym kolumnom wynikowej tabeli określamy w opcji METHOD L ): IMPORT FROM EMP_DATA.ASC OF ASC METHOD L (1 7, 8 17, 18 23, 24 34) INSERT INTO NEW_EMP

41 Import z pliku tekstowego DEL W pliku tekstowym zapisanym w formacie DEL, poszczególne dane są oddzielone separatorami (domyślny separator to przecinek), np. plik w którym zapisane są trzy wiersze danych o czterech kolumnach: "Smith, Bob",77,4973,15.46 "Jones, Bill",23,12345,16.34 "Williams, Sam",47,452, Import danych z pliku DEL do tabeli staff (nowe wiersze zostają dołączone do istniejących): IMPORT FROM staff.del OF DEL METHOD P(1, 3, 4) INSERT INTO staff(name, phone, bonus) Jeżeli w zapisanym pliku użyto innych opcji, niż domyślne, np. separator kolumny to średnik, należy użyć opcji modified, np. IMPORT FROM staff.del OF DEL MODIFIED BY coldel; METHOD P(1, 3, 4) INSERT INTO staff(name, phone, bonus)

42 Import z pliku IXF Plik w formacie IXF zawiera nie tylko dane, ale rownież definicję tabeli w postaci instrukcji DDL. Można odtworzyć tabelę bezpośrednio z pliku IXF. Przykład: eksportujemy pewne dane z tabeli employee do pliku IXF: EXPORT TO TOP_EARNERS.IXF OF IXF SELECT EMP_ID, EMP_NAME, DATE_OF_BIRTH, SALARY FROM EMP WHERE SALARY > ORDER BY EMP_ID Importujemy tworząc nową tabelę: IMPORT FROM TOP_EARNERS.IXF OF IXF CREATE INTO TOP_EMPLOYEES

43 Narzędzie LOAD Narzędzie LOAD jest szybszą niż IMPORT metodą na załadowanie danych z pliku do tabeli. LOAD omija interakcję z silnikiem DB2, więc wyzwalacze nie są aktywowane, nie są używane pule buforów, a więzy integralności są sprawdzane w osobnym kroku. LOAD jest szybszy niż IMPORT, gdyż działa na niższym poziomie, operując bezpośrednio na stronach danych. Wyrożniamy 3 fazy ładowania danych: LOAD, BUILD i DELETE.

44 Przykład: załadowanie danych z pliku IXF do tabeli employee_copy z opcją REPLACE: LOAD FROM employee.ixf OF IXF REPLACE INTO employee_copy Po wykonaniu powyzszego polecenia przestrzeń tablicowa, w której znajduje się tabela, zmienia status na CHECK PENDING. Następnie musimy wykonać polecenie SET INTEGRITY, aby sprawdzić integralność danych: SET INTEGRITY FOR employee_copy ALL IMMEDIATE UNCHECKED

45 Narzędzie db2move Narzędzia EXPORT, IMPORT i LOAD mogą operować w danym momencie tylko na jednej tabeli. Zamiast przygotowywać dla każdej tabeli osobny skrypt, można wykorzystać narzędzie db2move, które zrobi to za nas. Wykorzystuje ono wyłącznie pliki typu IXF. Nazwy plików, do których są eksportowane (a potem importowane) tabele są generowane automatycznie. Przykład: eksport i import danych znajdujących się w bazie danych SAMPLE: db2move sample export db2move sample import

46 Narzędzie db2look Narzędzia db2look możemy użyć do uzyskania pliku skryptowego, zawierającego strukturę DDL bazy, statystyki bazy danych i opcje przestrzeni tablicowych. Plik ten można poźniej wykorzystać do odtworzenia bazy danych na innym systemie. Na przykład, jeśli chcemy sklonować bazę danych z serwera DB2 działającego na systemie Linux na serwer działający na systemie Windows, uruchamiamy narzędzie db2look na serwerze Linux, otrzymując strukturę bazy przechowywaną w pliku skryptowym. Uruchamiamy ten skrypt na systemie Windows, otrzymując strukturę bazy danych. Teraz na systemie Linux uruchamiamy narzędzie db2move z opcją export. Następnie kopiujemy otrzymane pliki na serwer DB2 działający na systemie Windows i uruchamiamy narzędzie db2move z opcją import lub load. Po wykonaniu tych czynności otrzymamy pełną kopię bazy danych na nowej platformie.

47 Narzędzie db2look Składnia polecenia: db2look <database-name> <option> Wybrane opcje: Opcja Opis -e generuje komendy DDL dla obiektów bazy (m.in. tabele, widoki, indeksy, wyzwalacze, sekwencje, funkcje, procedury, ograniczenia (klucze główne, obce, check)). -u creator generuje DDL tylko dla obiektów utworzonych przez użytkownika o podanym ID. -z schema generuje DDL tylko dla obiektów z danego schematu. -t table-name tylko wybrana tabela (lub tabele). -o file-name zapisuje wynik w podanym pliku. -x generuje instrukcje DCL (GRANT i REVOKE). db2look -d SAMPLE -z student -e -o sample.ddl

48 Zadania konserwacyjne Aby baza danych była dobrze utrzymana, potrzeba przeprowadzać czynności konserwacyjne. Głównym kierunkiem w DB2 jest automatyzacja większości z tych zadań. Zarówno DB2 Express-C, jak i wszystkie inne aktualne wydania DB2 zawierają możliwości automatyzujące te czynności. REORG, RUNSTATS oraz REBIND to trzy główne zadania konserwacyjne DB2:

49 Zadania konserwacyjne Aby baza danych była dobrze utrzymana, potrzeba przeprowadzać czynności konserwacyjne. Głównym kierunkiem w DB2 jest automatyzacja większości z tych zadań. Zarówno DB2 Express-C, jak i wszystkie inne aktualne wydania DB2 zawierają możliwości automatyzujące te czynności. REORG, RUNSTATS oraz REBIND to trzy główne zadania konserwacyjne DB2: Konserwacja bazy danych jest wykonywana w sposób cykliczny. Jeżeli wykonana zostanie komenda REORG, zalecane jest, aby również wywołać RUNSTATS, a potem REBIND.

50 Zadania konserwacyjne Aby baza danych była dobrze utrzymana, potrzeba przeprowadzać czynności konserwacyjne. Głównym kierunkiem w DB2 jest automatyzacja większości z tych zadań. Zarówno DB2 Express-C, jak i wszystkie inne aktualne wydania DB2 zawierają możliwości automatyzujące te czynności. REORG, RUNSTATS oraz REBIND to trzy główne zadania konserwacyjne DB2: Wraz z upływem czasu tabele w bazie danych ulegają modyfikacji (w wyniku działania komend UPDATE, INSERT, DELETE). Należy wtedy wykonać cały cykl konserwacyjny, rozpoczynając od REORG.

51 Polecenie REORG Wykonywanie operacji INSERT, UPDATE, DELETE sprawia, że wraz z upływem czasu dane są porozrzucane po różnych stronach bazy danych. Komenda REORG odzyskuje niewykorzystane miejsca w pamięci oraz reorganizuje dane w taki sposób, aby zwracanie wyników było bardziej efektywne. Największy zysk płynie ze stosowania komendy REORG na często modyfikowanych tabelach. REORG można również stosować do reorganizacji indeksow. Reorganizacja może być w trybie online, lub off-line. Stosowanie REORG w trybie off-line jest bardziej efektywne, ale nie pozwala na dostęp do bazy danych. Tryb on-line pozwala na dostęp do bazy, ale wymaga większej ilości zasobów systemowych (dobry w przypadku mniejszych tabel).

52 Składnia: REORG TABLE <tablename> Przykład: reorganizacja tabeli: REORG TABLE employee reorganizacja indeksów: REORG INDEXES ALL FOR TABLE employee Przed komendą REORG można użyć REORGCHK w celu sprawdzenia, czy tabela lub indeks wymaga reorganizacji. reorgchk update statistics on table employee

53 Polecenie RUNSTATS Optymalizator DB2 znajduje najbardziej efektywne ścieżki dostępu, aby zlokalizować i wydobyć dane. Optymalizator DB2 to zorientowany na koszty system, który poprzez użycie statystyk obiektów bazodanowych, przechowywanych w tabelach słownika systemowego, maksymalizuje wydajność bazy danych. Na przykład, tabele te zawierają statystki o ilości kolumn i wierszy w tabelach oraz ile i jakiego typu indeksy są dostępne dla określonej tabeli. Statystyki nie są aktualizowane dynamicznie. Takie ustawienie jest domyślne, ponieważ ciągła aktualizacja statystyk wraz z każdą operacją przeprowadzaną na bazie danych może negatywnie wpłynąć na jej wydajność. Zamiast tego do aktualizacji statystyk w DB2 dostarczona została komenda RUNSTATS. Statystyki bazy danych powinny być jak najbardziej aktualne. Jeżeli statystyki bazy danych są aktualne, DB2 wybierze najlepszą drogę dostępu do danych. Częstotliwość przeprowadzania aktualizacji statystyk jest zależna od tego, jak często modyfikowane są dane w tabeli.

54 Składnia: RUNSTATS ON TABLE <schema.tablename> Przykład: RUNSTATS ON TABLE myschema.employee

55 BIND/REBIND Po pomyślnym wykonaniu komendy RUNSTATS, nie wszystkie zapytania użyją najnowszych statystyk: Plany dostępu statycznego SQL-a są określane w momencie wykonania komendy BIND, więc nie zawsze statystyki używane w danym momencie są tymi najbardziej aktualnymi. Polecenie db2rbind: do ponownego wiązania wszystkich istniejących pakietów z najbardziej aktualnymi statystykami. Składnia: db2rbind database_alias -l <logfile> Przykład: Aby ponownie związać paczki bazy danych sample i zapisać dziennik do pliku mylog.txt należy użyć polecenia: db2rbind sample -l mylog.txt

56 Sposoby konserwacji Konserwacja ręczna Administrator przeprowadza wszystkie czynności konserwacyjne ręcznie wtedy, gdy istnieje taka potrzeba. Stworzenie skryptów do przeprowadzania konserwacji Można stworzyć skrypty zawierające komendy konserwacyjne oraz zaplanować ich regularne uruchamianie. Konserwacja automatyczna DB2 może automatycznie dbać o konserwację bazy danych (REORG, RUNSTATS, BACKUP).

57 Konserwacja automatyczna Konserwacja automatyczna składa się z następujących elementów: 1. Użytkownik definiuje okno konserwacyjne, czyli okres, w którym wykonywanie zadań nie zakłóci funkcjonowania systemu w dużym stopniu. (Na przykład, gdy wykorzystanie systemu w niedziele między godziną 2:00 a 4:00 jest najmniejsze, to ten okres będzie dobrym oknem konserwacyjnym.) 2. Istnieją dwa okna konserwacyjne: jedno dla operacji w trybie on-line oraz drugie dla trybu off-line. 3. DB2 automatycznie przeprowadzi operacje konserwacyjne tylko wtedy, gdy są one potrzebne i tylko w trakcie okna konserwacyjnego.