docSystem zarzadzania bazami danych IBM DB2
download 
Reklamacja Transkrypt
System zarzadzania bazami danych IBM DB2
Transakcje Transakcja: ciag ˛ zawierajacy ˛ 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 wystapienia ˛ bł˛edu gdziekolwiek w systemie (np. przerwa w zasilaniu) lub w samej transakcji. Reguła ACID opisuje, jakie cechy powinna mieć transakcja: I Niepodzielna (Atomic) I Spójna (Consistent) I Odizolowana (Isolated) I Trwała (Durable) DB2 zamiast nazwy "transakcja" używa poj˛ecia "jednostka pracy" (unit of work). Na wykładzie b˛edziemy tradycyjnie używali poj˛ecia transakcji. DB2 zamiast nazwy "transakcja" używa poj˛ecia "jednostka pracy" (unit of work). Na wykładzie b˛edziemy tradycyjnie używali poj˛ecia transakcji. W DB2 transakcja jest rozpoczynana niejawnie, w momencie wykonania pierwszego polecenia SQL. Transakcja jest zatwierdzana i kończy si˛e w chwili wykonania instrukcji COMMIT. Wówczas wszystkie modyfikacje danych zostaja˛ zapisane w bazie. Uwaga. Edytory SQL maja˛ cz˛esto ustawiona˛ domyślnie opcj˛e autocommit. Transakcje w takim wypadku zatwiedzane sa˛ 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 ja˛ zastosować jeśli si˛e np. pomylimy. Ta instrukcja nie zadziała, jeśli wcześniej wykonamy COMMIT. Transakcja w takim wypadku została już zakończona. I Dowolna transakcja w bazie danych powinna być odizolowana od wszystkich pozostałych transakcji, które sa˛ wykonywane w tym samym czasie. I W idealnej sytuacji każda transakcja zachowuje si˛e tak, jakby posiadała wyłaczny ˛ dost˛ep do bazy danych. I Niestety, realia zwiazane ˛ z wymaganiem osiagni˛ ˛ ecia dobrej wydajności wymuszaja˛ poszukiwanie kompromisów (pomi˛edzy izolowaniem transakcji a wydajnościa˛ bazy). Dane zatwierdzone (committed) i niezatwierdzone (uncommitted) Dane zatwierdzone (committed data) charakteryzuja˛ si˛e tym, że I sa˛ spójne w bazie danych; I zostały zatwierdzone za pomoca˛ polecenia COMMIT (wydanego w sposób jawny lub nie); I zatwierdzone zmiany moga˛ zostać wycofane (usuni˛ ete) jedynie za pomoca kolejnego polecenia (lub kilku poleceń) SQL, w nowej transakcji; I sa˛ widoczne i dost˛ epne dla wszystkich użytkowników i aplikacji. Dane niezatwierdzone (uncommitted data) charakteryzuja˛ si˛e tym, że I moga˛ nie być spójne w bazie danych; I sa to zmiany, które zostały wprowadzone w bieżacej ˛ transakcji, zanim zostało wydane polecenie COMMIT; I moga˛ zostać wycofane za pomoca kolejnego polecenia ROLLBACK; I nie sa˛ widoczne ani dost˛ epne dla innych użytkowników i aplikacji (od tej zasady sa˛ wyjatki). Współbieżność w DB2 W sytuacji, gdy wielu użytkowników (aplikacji) jednocześnie uzyskuje dost˛ep do tych samych zasobów, mówimy o współbieżnym dost˛epie. Jeżeli w danym momencie dost˛ep do danych uzyskuje wiele transakcji, może to prowadzić do niepożadanych ˛ zjawisk, wśród których wyróżniamy: I Utracone aktualizacje (Lost Update); I Brudny odczyt (Uncommitted Read); I Odczyty nie dajace ˛ si˛e powtórzyć (Non-repeatable Read); I Odczyty widmo (Phantom Read). Wynika stad ˛ konieczność kontroli nad stopniem współbieżności danych, aby zachować I odpowiednia˛ stabilność danych; I nie tracac ˛ wymaganej wydajności. Niepożadane ˛ zjawiska zwiazane ˛ z problemem współbieżnego dost˛epu: I Utracone aktualizacje (Lost Update) - zachodzi gdy dwie transakcje odczytuja˛ te same dane i obie próbuja˛ je zmodyfikować, co skutkuje utrata˛ zmian wprowadzonych przez jedna˛ z nich, np. transakcja nr 1 i transakcja nr 2 odczytuja˛ ten sam wiersz danych i obliczaja˛ nowe wartości danych, na podstawie tego, jakie wartości aktualnie si˛e w tym wierszu znajduja; ˛ transakcja nr 1 aktualizuje wiersz za pomoca˛ wyliczonej wartości, nast˛epnie to samo robi transakcja nr 2; zmiana wprowadzona przez transakcj˛e nr 1 jest utracona. Niepożadane ˛ zjawiska zwiazane ˛ z problemem współbieżnego dost˛epu: I Utracone aktualizacje (Lost Update) - zachodzi gdy dwie transakcje odczytuja˛ te same dane i obie próbuja˛ je zmodyfikować, co skutkuje utrata˛ zmian wprowadzonych przez jedna˛ z nich, np. transakcja nr 1 i transakcja nr 2 odczytuja˛ ten sam wiersz danych i obliczaja˛ nowe wartości danych, na podstawie tego, jakie wartości aktualnie si˛e w tym wierszu znajduja; ˛ transakcja nr 1 aktualizuje wiersz za pomoca˛ wyliczonej wartości, nast˛epnie to samo robi transakcja nr 2; zmiana wprowadzona przez transakcj˛e nr 1 jest utracona. I Brudny odczyt (Uncommitted Read) - ma miejsce wtedy, gdy pewne instrukcje SQL wewnatrz ˛ jednej transakcji odczytuja˛ dane, które zostały zmienione przez inna˛ transakcj˛e, ale nie zatwierdzone jeszcze poleceniem COMMIT; jeżeli pierwsza transakcja zostanie wycofana poleceniem ROLLBACK, druga transakcja odczytała dane, które nigdy tak naprawd˛e nie były zapisane w bazie. I Odczyty nie dajace ˛ si˛e powtórzyć (Non-repeatable Read) zachodzi wtedy, gdy transakcja odczytuje zbiór danych, nast˛epnie czyta dane ponownie i okazuje si˛e, że dane nie sa˛ 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, że takiego wiersza nie ma (został usuni˛ety). I Odczyty nie dajace ˛ si˛e powtórzyć (Non-repeatable Read) zachodzi wtedy, gdy transakcja odczytuje zbiór danych, nast˛epnie czyta dane ponownie i okazuje si˛e, że dane nie sa˛ 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, że takiego wiersza nie ma (został usuni˛ety). I Odczyty widmo (Phantom Read) - zachodzi, gdy wiersz danych spełnia kryteria wyszukiwania, ale nie zostaje poczatkowo ˛ znaleziony; np. transakcja nr 1 wybiera zbiór wierszy spełniajacych ˛ pewne kryterium, transakcja nr 2 dodaje nowy wiersz, spełniajacy ˛ to kryterium; nast˛epnie transakcja nr 1 ponownie wywołuje zapytanie, które teraz zwraca inny zbiór wierszy, niż poprzednio (nowy wiersz dodany przez transakcj˛e nr 2 zostanie uwzgl˛edniony). Poziomy izolacji transakcji BD2 rozwiazuje ˛ problem współbieżności za pomoca˛ poziomów izolacji transakcji i mechanizmu blokad. Na żadnym z poziomów izolacji DB2 nie wystapi ˛ zjawisko utraconych aktualizacji (Lost Update). Każdy zmieniany lub wstawiany rekord jest automatycznie blokowany. Poziom izolacji transakcji określa, jak dane sa˛ 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: I Repeatable Read (RR) I Read Stability (RS) I Cursor Stability (CS) I Uncommitted Read (UR) Poziomy izolacji Repeatable Read (RR) - najwyższy poziom izolacji. Nie dopuszcza żadnego z opisanych wcześniej niepożadanych ˛ 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 najmniejsza˛ współbieżność dost˛epu 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. Poziomy izolacji Read Stability (RS) - kolejny poziom izolacji. Nie wystapi ˛ brudny odczyt (Uncommitted Read) ani odczyty nie dajace ˛ si˛e powtórzyć (Non-repeatable Read). Może pojawić si˛e odczyt widmo (Phantom Read). Blokada jest nakładana tylko na wybierane lub modyfikowane wiersze, a nie na cała˛ tabel˛e. Zalecany, gdy wymagany jest współbieżny dost˛ep do danych; zwracany zbiór wierszy musi pozostać stabilny w czasie całej transakcji; moga˛ pojawić si˛e nowe wiersze (jeżeli zostały wstawione wiersze spełniajace ˛ kryterium wyboru). Poziomy izolacji Cursor Stability (CS) - domyślny poziom izolacji dla transakcji. Nie może pojawić si˛e zjawisko brudnego odczytu. Może zajść odczyt widmo lub odczyty nie dajace ˛ si˛e powtórzyć. Blokada jest nakładana tylko na aktualnie odczytywany wiersz. Używany, aby zmaksymalizować współbieżność dost˛epu do danych, ale uniemożliwić odczytanie niezatwierdzonych danych (uncommitted read). Poziomy izolacji Cursor Stability (CS) - domyślny poziom izolacji dla transakcji. Nie może pojawić si˛e zjawisko brudnego odczytu. Może zajść odczyt widmo lub odczyty nie dajace ˛ si˛e powtórzyć. Blokada jest nakładana tylko na aktualnie odczytywany wiersz. Używany, aby zmaksymalizować współbieżność dost˛epu 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 dajace ˛ si˛e powtórzyć. Blokada dotyczy tylko zmienianych wierszy. Transakcja na tym poziomie izolacji może odczytywać zmiany danych wprowadzone przez inne transakcje, zanim zostana˛ one zatwierdzone poleceniem COMMIT. Zapewnia maksymalna˛ współbieżność. Używany, gdy: zadajemy tylko zapytania SELECT; dopuszczalny jest odczyt niezatwierdzonych danych. 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˛ebiorstwa. Typowe problemy: I awaria systemu I awaria zasilania I uszkodzenie transakcji I użytkownicy moga˛ przypadkowo uszkodzić baz˛e I awaria dysku I serwer bazy może zostać uszkodzony w wyniku pożaru, powodzi lub innej katastrofy. DB2 udost˛epnia narz˛edzia tworzenia kopii zapasowych (backup) i odzyskiwania danych (recovery), aby zapewnić danym bezpieczeństwo. 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 sa˛ rejestrowane w (pliku) dziennika transakcji, w poniższych sytuacjach: I Bufor dziennika jest pełny I Liczba zatwierdzeń osiagn ˛ ała ˛ wartość MINCOMMIT I Upłyn˛eła jedna sekunda. Statusy dzienników: I aktywne dzienniki informacje o transakcjach, które nie zostały jeszcze zatwierdzone ani wycofane; I dzienniki archiwalne dost˛epne online logi zakończonych transakcji, w aktywnym katalogu dzienników I dzienniki archiwalne dost˛epne offline logi zakończonych transakcji, przechowywane oddzielnie, cz˛esto na innym nośniku Metody archiwizacji dziennika Circular Logging I podstawowe pliki dziennika sa˛ używane do zapisania wszystkich transakcji; wykorzystywane ponownie, gdy transakcje zostaja˛ zakończone; I dodatkowe pliki dziennika sa˛ alokowane w razie potrzeby, gdy nie jest dost˛epny kolejny podstawowy plik dziennika (transakcje nadal sa˛ aktywne); I jeżeli zarówno podstawowe jak i dodatkowe pliki dziennika sa˛ pełne i nie moga˛ być ponownie wykorzystane, wyst˛epuje bład ˛ zapełnienia dziennika i jest zwracany komunikat o bł˛edzie SQL0964C; I dozwolone sa˛ tylko pełne, offlinowe backupy bazy danych; I nie ma możliwości odtworzenia danych z dzienników (mechanizm roll-forward nie jest dost˛epny). Metody archiwizacji dziennika Archival Logging I określane za pomoca˛ parametru konfiguracyjnego bazy LOGARCHMETH1; I wszystkie pliki dziennika sa˛ przechowywane, aby umożliwić odtwarzanie danych z dzienników i backupy w trybie online; I dzienniki moga˛ być opcjonalnie archiwizowane do innej lokalizacji (archiwum,) gdy nie sa˛ już aktywne, aby uniknać ˛ zapełnienia katalogu dziennika. Tworzenia kopii zapasowych Backup bazy danych: kopia bazy albo przestrzeni tablicowej; zawiera I dane użytkowników; I katalogi systemowe DB2; I wszystkie pliki kontrolne, np. pliki puli buforów, przestrzeni tablicowych, pliki konfiguracyjne bazy. Dwa tryby wykonywania backupów: I Offline Backup I I I w trakcie wykonywania kopii nie może być żadnego innego połaczenia ˛ z baza; ˛ jedyna możliwość wykonania kopii, jeżeli używamy metody archiwizacji dzienników circular logging. Online Backup I I I inne procesy lub aplikacje moga˛ mieć dost˛ep do bazy danych; dane sa˛ dostepne dla użytkowników podczas wykonywania backupu; wymaga aktywnej opcji archival logging. 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 Kopia zapasowa bazy danych - konwecja nadawania nazwy pliku: SAMPLE.0.DB2INST.NODE0000.CATN0000.20100314131259.001 Alias bazy typ backupu instancja w˛ezeł w˛ezeł katalogu data i czas numer kolejny. Typ backupu: 0 = pełna kopia; 3 = kopia przestrzeni tablicowej. Kopia zapasowa przestrzeni tablicowej DB2 daje możliwość tworzenia kopii wybranych przestrzeni tablicowych. Mechanizm tworzenia kopii na poziomie przestrzenie tablicowych: I pozwala użytkownikom na stworzenie kopii tylko cz˛eści bazy; I kilka przestrzeni tablicowych może być wybranych jednocześnie; I tylko, jeżeli baza używa metody archival logging; I dost˛epny jako backup w trybie online i offline; I 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 Kopie przyrostowe bazy Zamiast tworzyć pełna˛ kopi˛e bazy, można tworzyć tylko kopi˛e tych danych, które zostały zmienione od czasu wykonania ostatniego pełnego backupu. W DB2 sa˛ dost˛epne dwa typy backupów przyrostowych: I backup przyrostowy (inaczej skumulowany) - kopia zapasowa wszystkich danych bazy, które zmieniły si˛e od momentu wykonania ostatniego, pomyślnego pełnego backupu bazy. I backup przyrostowy typu delta - kopia zapasowa wszystkich danych bazy, które zmieniły si˛e od momentu wykonania ostatniego, pomyślnego (pełnego, przyrostowego lub delta) backupu bazy. I parametr konfiguracyjny bazy TRACKMOD musi być ustawiony na ON; I pozwala na wykonywanie backupu bazy lub przestrzeni tablicowej; I metoda odpowiednia dla dużych baz, w których wyst˛ epuje znaczna oszcz˛edność miejsca przy tworzeniu kopii tylko tych danych, które zostały ostatnio zmienione. Tryby odzyskiwania bazy danych I odzyskiwanie po awarii lub restarcie chroni baz˛e przed utrata˛ spójności danych (np. w przypadku utraty zasilania); I odzyskiwanie wersji bazy danych odzyskuje zrzut bazy; I odtwarzanie zmian (roll forward) rozszerza możliwości odzyskiwania wersji bazy danych, poprzez połaczenie ˛ odzyskiwania danych z kopii zapasowej z odtwarzaniem danych z plików dziennika. Narz˛edzie przywracania w DB2 jest uzupełnieniem mechanizmu tworzenia kopii zapasowych. Pozwala przywrócić baz˛e danych lub przestrzeń tablicowa˛ na podstawie utworzonego wcześniej backupu. Parametr TAKEN AT pozwala określić, który z dost˛epnych plików zawierajacych ˛ 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.CATN0000. 20140418131210.001 instrukcja odzyskiwania danych z tego backupu: RESTORE DATABASE dbalias FROM <db_path> TAKEN AT 20140418131210 Po odzyskaniu danych baza może być w trybie roll forward pending (dzieje si˛e tak, gdy odtwarzamy dane z kopii przestrzeni tablicowej, mamy aktywna˛ metod˛e archiwizacji dziennika archival logging). Można teraz wykonać operacj˛e 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 druga˛ opcj˛e, zmiany wprowadzone po podanym momencie w czasie nie zostana˛ uwzgl˛ednienione. Odtwarzanie danych do końca dzienników i wyjście z trybu roll forward pending: ROLLFORWARD DATABASE sample TO END OF LOGS AND COMPLETE; Narz˛edzia do przenoszenia danych Narz˛edzia do przenoszenia danych umożliwiaja: ˛ I przenoszenie danych pomi˛edzy tymi samymi bazami, I różnymi bazami, I na tej samej lub innej platformie sprz˛etowej. Narz˛edzia do przenoszenia danych: EXPORT IMPORT LOAD wraz z komenda˛ SET INTEGRITY Mechanizm przenoszenia danych Mamy dwie bazy danych: A i B. Używajac ˛ narz˛edzia EXPORT możemy wyeksportować tabel˛e do pliku, który ma jeden z poniższych formatów: DEL = Delimited ASCII, IXF = Integrated Exchange Format Po wyeksportowaniu danych do pliku, narz˛edzie 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˛edzie LOAD, a nast˛epnie wydanie polecenia SET INTEGRITY. Formaty plików Narz˛edzie EXPORT pozwala wyeksportować tabel˛e do pliku. Możliwe formaty: Pliki tekstowe: • DEL = Delimited ASCII Moga˛ być otwarte i przegladane ˛ 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˛e bezpośrednio z pliku IXF (to nie jest możliwe w przypadku innych formatów). Narz˛edzie EXPORT Narz˛edzie 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> Narz˛edzie EXPORT Narz˛edzie 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 Narz˛edzie EXPORT Narz˛edzie 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ślajac ˛ znak pojedynczego cudzysłowu jako znak ograniczajacy ˛ dane tekstowe, średnik jako separator kolumny, przecinek jako separator miejsc dziesi˛etnych: export to staff.del of del modified by chardel" coldel; decpt, select * from staff Narz˛edzie EXPORT Narz˛edzie 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˛epu do pliku wynikowego, zostanie on zapisany w bieżacym ˛ katalogu. Jeżeli plik o takiej nazwie już istnieje, zostanie nadpisany. Narz˛edzie IMPORT Narz˛edzie 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 sa˛ wszystkie wyzwalacze i sprawdzane sa˛ wi˛ezy integralności. Może zostać wykorzystane do odtworzenia tabeli, dodania danych do istniejacej ˛ tabeli lub stworzenia nowej tabeli z danymi. Składnia polecenia: IMPORT FROM <file-name> OF <file-type> <import-mode> INTO <table-name> Narz˛edzie IMPORT Narz˛edzie 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 sa˛ wszystkie wyzwalacze i sprawdzane sa˛ wi˛ezy integralności. Może zostać wykorzystane do odtworzenia tabeli, dodania danych do istniejacej ˛ 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 Opcje narz˛edzia IMPORT Możliwe tryby (opcje) wywołania narz˛edzia IMPORT: I INSERT: dodaje dane do tabeli, bez zmiany istniejacych ˛ danych; I INSERT_UPDATE: dodaje nowe wiersze do tabeli lub modyfikuje już istniejace ˛ dane (dopasowuje wiersze na podstawie wartości klucza głównego); I REPLACE: usuwa wszystkie wiersze istniejace ˛ w tabeli, wstawia dane z pliku, nie zmienia tabeli ani definicji indeksów, I REPLACE_CREATE: działa tak samo jak REPLACE, jeżeli tabela istnieje, jeżeli tabela nie istnieje, tworzy tabel˛e i definiuje dla niej indeksy oraz wstawia dane (opcja dost˛epna tylko dla importu z plików IXF; oznaczona jako niezalecana); I CREATE: tworzy tabel˛e oraz wstawia do niej dane (tylko z plików IXF; oznaczona jako niezalecana); jeżeli eksport danych był z tabeli DB2, także tworzone sa˛ indeksy. Import z pliku tekstowego ASC Dane w pliku ASC sa˛ 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): Importujac ˛ dane z pliku ASC trzeba określić poczatkow ˛ a˛ i końcowa˛ pozycj˛e dla danych odpowiadajacych ˛ poszczególnym kolumnom wynikowej tabeli (opcja METHOD L ). Import z pliku tekstowego ASC Import danych z pliku EMP_DATA.ASC (poczatkow ˛ a˛ i końcowa˛ pozycj˛e dla danych odpowiadajacych ˛ 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 Import z pliku tekstowego DEL W pliku tekstowym zapisanym w formacie DEL, poszczególne dane sa˛ oddzielone separatorami (domyślny separator to przecinek), np. plik w którym zapisane sa˛ trzy wiersze danych o czterech kolumnach: "Smith, Bob",77,4973,15.46 "Jones, Bill",23,12345,16.34 "Williams, Sam",47,452,193.78 Import danych z pliku DEL do tabeli staff (nowe wiersze zostaja˛ dołaczone ˛ do istniejacych): ˛ 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) Import z pliku IXF Plik w formacie IXF zawiera nie tylko dane, ale rownież definicj˛e tabeli w postaci instrukcji DDL. Można odtworzyć tabel˛e 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 > 139990 ORDER BY EMP_ID Importujemy tworzac ˛ nowa˛ tabel˛e: IMPORT FROM TOP_EARNERS.IXF OF IXF CREATE INTO TOP_EMPLOYEES Narz˛edzie LOAD Narz˛edzie LOAD jest szybsza˛ niż IMPORT metoda˛ na załadowanie danych z pliku do tabeli. LOAD omija interakcj˛e z silnikiem DB2, wi˛ec wyzwalacze nie sa˛ aktywowane, nie sa˛ używane pule buforów, a wi˛ezy integralności sa˛ sprawdzane w osobnym kroku. LOAD jest szybszy niż IMPORT, gdyż działa na niższym poziomie, operujac ˛ bezpośrednio na stronach danych. Wyrożniamy 3 fazy ładowania danych: LOAD, BUILD i DELETE. Przykład: załadowanie danych z pliku IXF do tabeli employee_copy z opcja˛ REPLACE: LOAD FROM employee.ixf OF IXF REPLACE INTO employee_copy Po wykonaniu powyzszego polecenia przestrzeń tablicowa, w której znajduje si˛e tabela, zmienia status na CHECK PENDING. Nast˛epnie musimy wykonać polecenie SET INTEGRITY, aby sprawdzić integralność danych: SET INTEGRITY FOR employee_copy ALL IMMEDIATE UNCHECKED Narz˛edzie db2move Narz˛edzia EXPORT, IMPORT i LOAD moga˛ operować w danym momencie tylko na jednej tabeli. Zamiast przygotowywać dla każdej tabeli osobny skrypt, można wykorzystać narz˛edzie db2move, które zrobi to za nas. Wykorzystuje ono wyłacznie ˛ pliki typu IXF. Nazwy plików, do których sa˛ eksportowane (a potem importowane) tabele sa˛ generowane automatycznie. Przykład: eksport i import danych znajdujacych ˛ si˛e w bazie danych SAMPLE: db2move sample export db2move sample import Narz˛edzie db2look Narz˛edzia db2look możemy użyć do uzyskania pliku skryptowego, zawierajacego ˛ struktur˛e 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˛e danych z serwera DB2 działajacego ˛ na systemie Linux na serwer działajacy ˛ na systemie Windows, uruchamiamy narz˛edzie db2look na serwerze Linux, otrzymujac ˛ struktur˛e bazy przechowywana˛ w pliku skryptowym. Uruchamiamy ten skrypt na systemie Windows, otrzymujac ˛ struktur˛e bazy danych. Teraz na systemie Linux uruchamiamy narz˛edzie db2move z opcja˛ export. Nast˛epnie kopiujemy otrzymane pliki na serwer DB2 działajacy ˛ na systemie Windows i uruchamiamy narz˛edzie db2move z opcja˛ import lub load. Po wykonaniu tych czynności otrzymamy pełna˛ kopi˛e bazy danych na nowej platformie. Narz˛edzie db2look Składnia polecenia: db2look <database-name> <option> Wybrane opcje: Opcja -e -u creator -z schema -t table-name -o file-name -x Opis generuje komendy DDL dla obiektów bazy (m.in. tabele, widoki, indeksy, wyzwalacze, sekwencje, funkcje, procedury, ograniczenia (klucze główne, obce, check)). generuje DDL tylko dla obiektów utworzonych przez użytkownika o podanym ID. generuje DDL tylko dla obiektów z danego schematu. tylko wybrana tabela (lub tabele). zapisuje wynik w podanym pliku. generuje instrukcje DCL (GRANT i REVOKE). db2look -d SAMPLE -z student -e -o sample.ddl Zadania konserwacyjne Aby baza danych była dobrze utrzymana, potrzeba przeprowadzać czynności konserwacyjne. Głównym kierunkiem w DB2 jest automatyzacja wi˛ekszości z tych zadań. Zarówno DB2 Express-C, jak i wszystkie inne aktualne wydania DB2 zawieraja˛ możliwości automatyzujace ˛ te czynności. REORG, RUNSTATS oraz REBIND to trzy główne zadania konserwacyjne DB2: Zadania konserwacyjne Aby baza danych była dobrze utrzymana, potrzeba przeprowadzać czynności konserwacyjne. Głównym kierunkiem w DB2 jest automatyzacja wi˛ekszości z tych zadań. Zarówno DB2 Express-C, jak i wszystkie inne aktualne wydania DB2 zawieraja˛ możliwości automatyzujace ˛ 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. Zadania konserwacyjne Aby baza danych była dobrze utrzymana, potrzeba przeprowadzać czynności konserwacyjne. Głównym kierunkiem w DB2 jest automatyzacja wi˛ekszości z tych zadań. Zarówno DB2 Express-C, jak i wszystkie inne aktualne wydania DB2 zawieraja˛ możliwości automatyzujace ˛ te czynności. REORG, RUNSTATS oraz REBIND to trzy główne zadania konserwacyjne DB2: Wraz z upływem czasu tabele w bazie danych ulegaja˛ modyfikacji (w wyniku działania komend UPDATE, INSERT, DELETE). Należy wtedy wykonać cały cykl konserwacyjny, rozpoczynajac ˛ od REORG. Polecenie REORG Wykonywanie operacji INSERT, UPDATE, DELETE sprawia, że wraz z upływem czasu dane sa˛ porozrzucane po różnych stronach bazy danych. Komenda REORG odzyskuje niewykorzystane miejsca w pami˛eci oraz reorganizuje dane w taki sposób, aby zwracanie wyników było bardziej efektywne. Najwi˛ekszy zysk płynie ze stosowania komendy REORG na cz˛esto 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˛ep do bazy danych. Tryb on-line pozwala na dost˛ep do bazy, ale wymaga wi˛ekszej ilości zasobów systemowych (dobry w przypadku mniejszych tabel). Składnia: REORG TABLE <tablename> Przykład: reorganizacja tabeli: REORG TABLE employee reorganizacja indeksów: REORG INDEXES ALL FOR TABLE employee Przed komenda˛ REORG można użyć REORGCHK w celu sprawdzenia, czy tabela lub indeks wymaga reorganizacji. reorgchk update statistics on table employee Polecenie RUNSTATS Optymalizator DB2 znajduje najbardziej efektywne ścieżki dost˛epu, 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 zawieraja˛ statystki o ilości kolumn i wierszy w tabelach oraz ile i jakiego typu indeksy sa˛ dost˛epne dla określonej tabeli. Statystyki nie sa˛ aktualizowane dynamicznie. Takie ustawienie jest domyślne, ponieważ ciagła ˛ aktualizacja statystyk wraz z każda˛ operacja˛ przeprowadzana˛ na bazie danych może negatywnie wpłynać ˛ 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 sa˛ aktualne, DB2 wybierze najlepsza˛ drog˛e dost˛epu do danych. Cz˛estotliwość przeprowadzania aktualizacji statystyk jest zależna od tego, jak cz˛esto modyfikowane sa˛ dane w tabeli. Składnia: RUNSTATS ON TABLE <schema.tablename> Przykład: RUNSTATS ON TABLE myschema.employee BIND/REBIND Po pomyślnym wykonaniu komendy RUNSTATS, nie wszystkie zapytania użyja˛ najnowszych statystyk: Plany dost˛epu statycznego SQL-a sa˛ określane w momencie wykonania komendy BIND, wi˛ec nie zawsze statystyki używane w danym momencie sa˛ tymi najbardziej aktualnymi. Polecenie db2rbind: do ponownego wiazania ˛ wszystkich istniejacych ˛ pakietów z najbardziej aktualnymi statystykami. Składnia: db2rbind database_alias -l <logfile> Przykład: Aby ponownie zwiazać ˛ paczki bazy danych sample i zapisać dziennik do pliku mylog.txt należy użyć polecenia: db2rbind sample -l mylog.txt Sposoby konserwacji I Konserwacja r˛eczna Administrator przeprowadza wszystkie czynności konserwacyjne r˛ecznie wtedy, gdy istnieje taka potrzeba. I Stworzenie skryptów do przeprowadzania konserwacji Można stworzyć skrypty zawierajace ˛ komendy konserwacyjne oraz zaplanować ich regularne uruchamianie. I Konserwacja automatyczna DB2 może automatycznie dbać o konserwacj˛e bazy danych (REORG, RUNSTATS, BACKUP). Konserwacja automatyczna Konserwacja automatyczna składa si˛e z nast˛epujacych ˛ 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˛edzy godzina˛ 2:00 a 4:00 jest najmniejsze, to ten okres b˛edzie dobrym oknem konserwacyjnym.) 2. Istnieja˛ 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 sa˛ one potrzebne i tylko w trakcie okna konserwacyjnego.
