Spis treści. Administracja bazami danych Oracle I-v1.2. A.Klusiewicz, M.Bieniek

Transkrypt

1 Spis treści Podstawowe pojęcia...3 Baza danych...3 RDBMS...3 SQL...3 Architektura...5 Instancja i SGA...5 Sesje i transakcje...6 Mechanizm blokowania danych...6 Użytkownicy i schematy...7 Obiekty bazy danych...8 Globalny obszar pamięci SGA...10 Obszar pamięci PGA...12 Struktura fizyczna bazy...13 Użytkownik HR i jego schemat...16 Podstawowe narzędzia...18 SQL*Plus...18 Podstawowe opcje SQL*Plus...23 Ćwiczenia...24 SQL DEVELOPER...25 Obiekty bazodanowe...29 Tabele...29 Więzy integralności...33 Widoki...36 Sekwencje...39 Linki bazodanowe...44 Ćwiczenia Stwórz tabelkę kluczem głównym, jedną kolumną z unikalnymi wartościami oraz jedną do której zawsze...46 FLASHBACK...47 Parametr UNDO_RETENTION...47 AS OF TIMESTAMP...48 FLASHBACK TABLE...50 Ćwiczenia...52 UŻYTKOWNICY I UPRAWNIENIA...53 Tworzenie użytkownika...53 Nadawanie uprawnień użytkownikowi...53 ODBIERANIE UPRAWNIEŃ UŻYTKOWNIKOWI...54 USUWANIE UŻYTKOWNIKA...54 NADAWANIE ROLI UŻYTKOWNIKOM...55 TWORZENIE WŁASNYCH ROLI...56 SPRAWDZANIE PRZYZNANYCH ROLI I UPRAWNIEŃ ROLI...57 Ćwiczenia...58 PROFILE...59 Podstawowe informacje o profilach...59 Profil DEFAULT...60 Tworzenie profili...62 Zmiana profilu...64 Usuwanie profilu /108

2 Ćwiczenia...67 Audyt monitorowanie użytkowników i działań na obiektach...68 Włączanie opcji AUDIT...68 Śledzenie użytkownika...69 Śledzenie działań na obiekcie...72 Wyłączenie opcji AUDIT...74 Ćwiczenia...75 Rozłączanie sesji użytkowników...76 Ćwiczenia...77 Włączanie i wyłączanie instancji...78 Tryby uruchomieniowe instancji...78 Ćwiczenia...80 RMAN - Kopie zapasowe w Oracle...81 Podstawowe informacje i wstępna konfiguracja...81 Pełny backup...84 Backup skompresowany...85 Backup przyrostowy i kumulatywny...86 Backup przyrostowy...86 Backup kumulatywny...87 Szybki backup przyrostowy...87 Backup pliku kontrolnego...89 Odtwarzanie przy użyciu RMAN...91 Przywracanie bazy z pełnego backupu...91 Przywracanie bazy do określonego punktu w czasie...92 Walidacja bazy i backupów...93 Zarządzanie backupami...94 Przywracamy tablespace systemowy...96 Przywracanie pliku kontrolnego...97 Ćwiczenia...98 Export i import danych...99 Eksport całej bazy danych...99 Eksport całego schematu...99 Eksport wybranych tabel Import danych Import całej bazy Import schematu Import poszczególnych tabel Ćwiczenia Oracle Net /108

3 Podstawowe pojęcia Baza danych to zbiór danych zapisanych w ściśle określony sposób w strukturach odpowiadających założonemu modelowi danych. W potocznym ujęciu obejmuje dane oraz komputerowy program wyspecjalizowany do gromadzenia i przetwarzania tych danych. Baza danych jest złożona z różnych elementów. Najważniejszymi z nich jest rekord podzielony na kilka pól, w których są przechowywane informacje poszczególnych kategorii. Na przykład w książce adresowej każdy rekord to zbiór informacji na temat jednej osoby. Składa się on z kilku pól przechowujących takie informacje, jak: imię, nazwisko, adres, numer telefonu itp. W każdym polu zapisywane są dane oddzielonej kategorii. RDBMS Relational Database Management System (RDBMS, dosłownie system zarządzania relacyjną bazą danych) to zestaw programów służących do korzystania z bazy danych opartej na modelu relacyjnym. SQL strukturalny język zapytań używany do tworzenia, modyfikowania baz danych oraz do umieszczania i pobierania danych z baz danych. Język SQL jest językiem deklaratywnym. Decyzję o sposobie przechowywania i pobrania danych pozostawia się systemowi zarządzania bazą danych (DBMS).Użycie SQL, zgodnie z jego nazwą, polega na zadawaniu zapytań do bazy danych. Zapytania można zaliczyć do jednego z trzech głównych podzbiorów: SQL DML (ang. Data Manipulation Language język manipulacji danymi ), SQL DDL (ang. Data Definition Language język definicji danych ), SQL DCL (ang. Data Control Language język kontroli nad danymi ). DML DML (Data Manipulation Language) służy do wykonywania operacji na danych do ich umieszczania w bazie, kasowania, przeglądania, zmiany. Najważniejsze polecenia z tego zbioru to: SELECT pobranie danych z bazy, INSERT umieszczenie danych w bazie, UPDATE zmiana danych, DELETE usunięcie danych z bazy. 3/108

4 DDL Dzięki DDL (Data Definition Language) można operować na strukturach, w których dane są przechowywane czyli np. dodawać, zmieniać i kasować tabele lub bazy. Najważniejsze polecenia tej grupy to: CREATE (np. CREATE TABLE, CREATE DATABASE, ) utworzenie struktury (bazy, tabeli, indeksu itp.), DROP (np. DROP TABLE, DROP DATABASE, ) usunięcie struktury, ALTER (np. ALTER TABLE ADD COLUMN ) zmiana struktury (dodanie kolumny do tabeli, zmiana typu danych w kolumnie tabeli). DCL DCL (Data Control Language) ma zastosowanie do nadawania uprawnień do obiektów bazodanowych. Najważniejsze polecenia w tej grupie to: GRANT (np. GRANT ALL PRIVILEGES ON EMPLOYEES TO PIOTR WITH GRANT OPTION) przyznanie wszystkich praw do tabeli EMPLOYEES użytkownikowi PIOTR z opcją pozwalającą mu nadawać prawa do tej tabeli. REVOKE odebranie użytkownikowi wszystkich praw do tabeli, które zostały przyznane poleceniem GRANT. DENY. 4/108

5 Architektura Instancja i SGA Baza danych przechowuje dane w plikach na dysku twardym i umożliwia dostęp do tych plików za pośrednictwem systemu operacyjnego. Aby umożliwić efektywne operowanie danymi, Oracle używa pamięci współdzielonej, dostępnej dla wszystkich użytkowników bazy danych, nazywanej Globalnym Obszarem Współdzielonym (SGA System Global Area). Instancja Oracle to właśnie wymienione wyżej uruchomione procesy tła oraz alokowany globalny obszar współdzielony SGA. Użytkownik podłączając się do bazy danych, nie pobiera danych bezpośrednio z pliku bazy danych. Polecenie języka SQL wystosowane przez użytkownika trafia do odpowiedniego bufora w strukturze SGA, a następnie, po jego przetworzeniu i zanalizowaniu pobierane są bloki z pliku danych do obszaru SGA. Dopiero stąd informacja przekierowana zostaje do użytkownika. W przypadku, kiedy dane, do których odwołuje się użytkownik znajdują się już w obszarze SGA, pomijana jest faza pobierania danych z pliku i od razu informacja zwracana jest użytkownikowi. Relacyjna baza danych Oracle posługuje się standardowym językiem zapytań SQL, oraz posiada wbudowany wewnętrzny język tworzenia procedur składowanych PL/SQL. Od wersji 8i jako języka tworzenia procedur składowanych w bazach danych Oracle można używać również języka Java. 5/108

6 Sesje i transakcje Architektura klient serwer bazy danych Oracle zapewnia wielu użytkownikom równoczesny dostęp do tej samej bazy. Operacje odczytu tych samych danych przez wielu użytkowników równocześnie nie powodują konfliktów ani niespójności. Inaczej rzecz się ma w przypadku modyfikacji tych samych danych. Wówczas mogłyby wystąpić niespójności. W celu zachowania spójności danych w czasie równoczesnej próby ich modyfikacji wprowadzono mechanizm transakcji, jako jednostki, w ramach, której użytkownicy wykonują swoje operacje w bazie danych. W sytuacjach konfliktowych system zarządzania bazą danych (DBMS) szereguje operacje różnych transakcji w taki sposób, aby nie powstały niespójności danych. Moment podłączenia się użytkownika do bazy danych jest jednocześnie początkiem sesji danego użytkownika. Trwa ona aż do momentu zakończenia pracy z bazą danych. Równolegle jeden użytkownik może mieć otwartych więcej niż jedną sesję. W ramach jednej sesji użytkownik może realizować jedną lub więcej transakcji, jedna po drugiej. Transakcja jest jednostką interakcji użytkownika z bazą danych i składa się z pojedynczych operacji realizowanych w bazie danych. Użytkownik realizuje swoje transakcje albo przez polecenia języka SQL, które kierowane są bezpośrednio do systemu zarządzania bazą danych (DBMS), albo pośrednio przy użyciu wcześniej przygotowanych aplikacji bazy danych, odwołujących się do DBMS. Mechanizm blokowania danych Transakcje wykonujące operacje odczytu nie wpływają na siebie wzajemnie, ich działania nie kolidują ze sobą. Problem pojawia się w przypadku operacji zmieniających jednocześnie te same dane w bazie. Jeśli dwóch użytkowników zmienia jednocześnie dwa różne obiekty w bazie danych, nie wywołuje to konfliktu. Jeśli natomiast te dwie operacje dotyczyć będą tego samego obiektu, powstaje sytuacja konfliktowa. Aby uniknąć zakleszczeń będących efektem takich sytuacji Oracle opracował złożony mechanizm zakładania blokad na obiekty. W przypadku kiedy rozpocznie się transakcja pierwszego użytkownika, drugi użytkownik może odczytywać dane właśnie modyfikowane przez pierwszego, ale nie może ich zmieniać do czasu zakończenia transakcji pierwszego użytkownika. Polecenie drugiego użytkownika zostanie skolejkowane jako oczekujące na wykonanie. 6/108

7 Użytkownicy i schematy Kiedy użytkownik bazy danych tworzy obiekt, jednocześnie staje się jego właścicielem. Obiekty te tworzone są w tak zwanym schemacie użytkownika, czyli logicznej przestrzeni bazy danych. Schemat użytkownika jest tworzony automatycznie podczas definiowania użytkownika i posiada on unikalną nazwę, która jest identyczna z nazwą użytkownika. Nazwa schematu wykorzystywana jest do wskazania obiektów bazy danych stanowiących własność danego użytkownika. Odwołanie do obiektu znajdującego się w innym schemacie umożliwia następująca składnia: NAZWA_UŻYTKOWNIKA.NAZWA_OBIEKTU Nazwy obiektów muszą być unikalne w obrębie schematu. Dwóch użytkowników może posiadać obiekt o tej samej nazwie w swoich schematach, natomiast różnie będą się do nich odwoływać. Jeśli użytkownik Kowalski oraz Nowak mają w swoich schematach obiekty o nazwie Towary mogą się do nich odwoływać (przy założeniu że mają do tego uprawnienia) dodając nazwę użytkownika kolegi przed nazwą obiektu. Użytkownik Kowalski odnosząc się do swojego obiektu wywołuje go: TOWARY Jeśli zechce odnieść się do obiektu kolegi: NOWAK.TOWARY 7/108

8 Obiekty bazy danych W bazie danych Oracle istnieje wiele różnych obiektów zarówno do przechowywania samych danych, jak i pełniących funkcje wspomagające zarządzaniem tymi danymi. Wszystkie obiekty tworzone są przez użytkowników bazy danych. Użytkownik musi mieć jednak przypisane uprawnienie tworzenia danego rodzaju obiektu. W systemie Oracle można zdefiniować np. takie obiekty: Tabele służą do przechowywania danych. Indeksy są strukturami danych zwiększającymi prędkość wykonywania operacji na tabeli. Tabele tymczasowe Służą do przechowywania danych potrzebnych na czas jednej transakcji lub jednej sesji oraz do wspomagania zarządzania tymi danymi: Widoki to logiczna struktura, wirtualna tabela wyliczana w locie, określona przez zapytanie SQL, umożliwia dostęp do podzbioru kolumn i wierszy tabeli lub tabel. Sekwencje Sekwencja to obiekt bazy danych generujący kolejne liczby. Sekwencje są stosowane przede wszystkim do tworzenia kolejnych wartości sztucznych kluczy podstawowych. Wyzwalacz jest to procedura wykonywana automatycznie jako reakcja na pewne zdarzenia w tabeli bazy danych. Tabela Tabela to nieuporządkowany zbiór rekordów, informacji tego samego typu. Pole to pojedynczy niepodzielny element informacji, zawierający: Nazwę identyfikującą pole, Typ określający zbiór wartości, które to pole może przyjąć, Wartość będącą informacją zapisaną w polu. Rekord - uporządkowany zbiór różnych pól. Kolumna - zbiór pól tego samego rodzaju z zakresu wszystkich rekordów Globalny obszar pamięci SGA SGA (System Global Area) jest buforem pamięci alokowanym podczas startu instancji. Przechowuje informacje współdzielone przez różne procesy bazy danych. M.in przechowuje: 8/108

9 Kopie danych z dysku (w buforze danych znajdującym się w SGA) Bufor dziennika powtórzeń Plany wykonania zapytań SQL... Ogólnie ujmując wszystko to co jest potrzebne bazie danych do działania i musi być pod ręką (w pamięci dostępnej dla serwera). 9/108

10 Generalnie SGA dzieli się na kilka części. Bufor danych - dane do których sięgamy zapytaniem, nie zawsze muszą być czytane z dysku. Jeśli ktoś wcześniej sięgał do danych których nie było w tym buforze, dane te musiały zostać odczytane z dysku a następnie wrzucone do bufora danych. Dzięki temu kiedy następna osoba zażąda tych samych danych, nie będzie już konieczności odczytywania ich z dysku, ponieważ będą one dostępne w buforze danych. Czas operacji odczytu z pamięci jest nieporównywalnie krótszy od czasu operacji odczytu z dysku. Działa to też w drugą stronę. Zmieniane czy dodawane dane nie od razu pakowane są na dysk, są zmieniane najpierw w buforze danych, dzięki czemu są one szybciej dostępne. Oczywiście w pewnym momencie zapisuje je na dysk specjalny proces (DBWR).Wiadomo że nie wszystkie dane mogą tu być przechowywane choćby ze względu na pojemność takiego bufora. Dane zapisywane są na dysku w trzech przypadkach. Cyklicznie,domyślenie co 3 sekundy (DBWR) zapisuje dane na dysku. Jeżeli bufor się przepełni, usuwane są dane najdawniej wykorzystywane. Jeżeli jakieś dane znajdujące się już w buforze zostaną wykorzystane ponownie, trafiają na początek listy. O to dba nam proces serwera. Takie działanie nazywa algorytmem LRU (Last Recently Used). Dane zapisywane są na dysku również gdy kończy się miejsc w plikach dziennika powtórzeń i dane muszą zostać w nich wyczyszczone. DBWR sprawdza czy są jeszcze jakieś dane do zapisania na dysku,jeśli są to je zapisuje,a następnie czyszczone są pliki dziennika powtórzeń. Bufor dziennika powtórzeń - wszystkie zmiany danych są rejestrowane. Dzięki temu, nawet jeśli zmienione dane nie zostały jeszcze trwale zapisane na dysk, jesteśmy w stanie je odtworzyć. Istnieją specjalne pliki dziennika powtórzeń w których zapisywane są wszelkie zmiany, jednak informacja zanim tam trafi, trafia do bufora dziennika powtórzeń. Bufor biblioteczny - jeśli zadamy jakieś zapytanie SQL do instancji, owo zapytanie musi najpierw zostać sprawdzone pod kątem składniowym, również czy mamy odpowiednie uprawnienia do odczytu/zapisu konkretnych danych. Oracle musi też wymyślić jak wykonać dane polecenie tak by zostało ono zakończone jak najszybciej. W tym celu wymyśla kilka planów wykonania zapytania, a następnie wybiera najbardziej optymalny. Gdyby Oracle za każdym razem miał wykonywać te same operacje dla tych samych zapytań byłaby to strata czasu. Dlatego wykonuje je za pierwszym 10/108

11 razem, a następnie wrzuca właśnie do bufora bibliotecznego. Dzięki temu jeśli inny użytkownik wykona to samo zapytanie, Oracle sięgnie sobie do bufora bibliotecznego w którym już ma opracowany plan wykonania zapytania, sprawdzone czy zapytanie jest poprawne składniowo i nie musi tego wszystkiego wykonywać od początku. Bufor słownika - w Oracle funkcjonują specjalne słowniki w których zapisane jest jakie w bazie znajdują się obiekty, jakie są pomiędzy nimi zależności i kto ma do nich uprawnienia. Do tych danych trzeba sięgać często, właściwie to przy każdym zapytaniu. Dlatego słowniki te są ładowane do pamięci, dzięki czemu jest do nich szybszy dostęp. Ponadto w SGA znajdują się jeszcze inne bufory: JAVA_POOL - czyli bufor służący do przechowywania kodu Java. W Oracle możemy przechowywać poza danymi również klasy Javy które w trakcie wykonania potrzebują pewnej przestrzeni pamięci - do tego służy właśnie bufor JAVA_POOL. LARGE_POOL - Opcjonalny bufor który jest wykorzystywany przy okazji dużych operacji dyskowych np. backupu danych. STREAMS_POOL - specjalny bufor wykorzystywany przy replikacji bazy danych. Bufor danych domyślnie ma jedną część - DEFAULT. W razie potrzeby możemy jeszcze go podzielić na część KEEP, RECYCLE, oraz nk BUFFER. Bufor KEEP -służy do przechowywania obiektów które chcemy trwale przechowywać w pamięci, w taki sposób by nie zostały "wypchnięte" przez nowe bloki danych. Przykładowo jeśli jakaś tabela jest wykorzystywana często, chcemy by zawsze był do niej szybki dostęp. W takim wypadku musimy stworzyć taki bufor i określić że ta tabela ma byc przechowywana w nim. Bufor RECYCLE - do tego bufora możemy załadować obiekty z których korzystamy sporadycznie i nie chcemy by zajmowały nam cenne miejsce w buforze DEFAULT. Tu również musimy włączyć korzystanie z tego bufora i określić że dany obiekt ma być przechowywany właśnie w nim. Bufor nk- Bufor do przechowywania obiektów o niestandardowej wielkości bloków. Nie będziemy się tym tutaj zajmować. Obszar pamięci PGA Ponieważ procesy serwera aby wykonać dla nas jakieś czynności też potrzebują pewnej ilości pamięci, alokowany jest dla każdego z nich obszar PGA. To specjalny wydzielony kawałek pamięci w którym proces serwera może : Sortować dane Trzymać informacje o sesji użytkownika Przechowywać informacje o zmiennych, tablicach, kursorach, danych przetwarzanych przez proces. 11/108

12 Oczywiście w momencie zakończenia sesji użytkownika bufor ten nie jest już potrzebny i alokowana dla niego pamięć jest zwalniana. Struktura fizyczna bazy Plik Spifile- Jest to plik parametrów startowych. Zawiera informacje o tym ile miejsca może alokować instancja,ile miejsca przypada na SGA,PGA i poszczególne bufory a także inne parametry m.in. ilość jednoczesnych sesji itp.. Spfile jest podpinany w chwili gdy instancja przechodzi do trybu nomount. W pliku spfile znajdują się m.in. lokalizacje pliku alert_log,pliku kontrolnego oraz przestrzeni przeznaczonej na kopie zapasowe. Informacja o położeniu pliku kontrolnego (lub kilku możemy mieć ich więcej) jest niezbędna do prześcia instancji do trybu MOUNT, kiedy to pliki kontrolne są podpinane. Parametry zapisywane w pliku spfile możemy modyfikować na dwa sposoby. Pierwszym z nich jest użycie komendy alter system. 12/108

13 alter system set parametr=wartosc scope=memory; Zmiana parametru do restartu bazy. Zmiania parametru będzie dotyczyła wyłącznie aktualnie uruchomionej instancji, po restarcie zostanie wczytana wartość ustawiona na stałe. alter system set parametr=wartosc scope=spfile; Zmiana parametru od restartu bazy. Wykonanie komendy z parametrem scope=spfile sprawi, że zmiana parametru zostanie uwzględniona jedynie w pliku spfile. Ponieważ ten plik jest czytany przy starcie systemu, zmiana będzie obowiązywać od kolejnego uruchomienia instancji. alter system set parametr=wartosc scope=both; Zmiana parametru dla bieżącego uruchomienia i po restarcie. alter system set parametr=wartosc; bez zakończenia domyślnie scope=both. Drugim sposobem zmiany parametrów jest utworzenie pliku Pfile na podstawie Spfile i wykonanie ręcznej modyfikacji w tym pliku.po zmodyfikowaniu Pfile,uruchamiamy instancję z jego użyciem w celu sprawdzenia czy baza będzie wstanie całkowicie podnieść się z korzystając z nowych parametrów. Jeśli baza uruchomiła się prawidłowo tworzymy Spfile na podstawie Pfile. 13/108

14 Plik kontrolny-przechowuje bardzo istotne informacje na temat bazy danych, między innymi położenie plików danych, DBID bazy, czy ostatni SCN. W domyślnej konfiguracji plik ten spełnia też rolę repozytorium kopii zapasowych (informacji o ich położeniu i zawartości, nie zawiera samych backupów : ) ). W wersji Express Edition mamy jeden plik kontrolny, w wersjach Stantard i Enterprise dwa, choć oba domyślnie znajdują się na tym samym dysku. Oba są lustrzanymi kopiami siebie. Ponieważ pliki te są tak newralgiczne, warto w przypadku wersji XE dokonać duplikacji pliku kontrolnego, a w przypadku Standard i Enterprise zadbać o to, aby pliki te były umieszczone na różnych dyskach. Plik alert log -zawiera najważniejsze informacje o tym co się dzieję w bazie,komunikaty o stanie,błędach,uszkodzeniach. Zapisywane w nim są wszystkie polecenia administratora alter database i alter system.jeśli chcemy poznać jego położenie na dysku uzywamy komendy show parameter background_dump_dest. W katalogu którego adres zostanie zwrócony po wykonaniu tego polecenia, powinien znajdować się plik o nazwie alert_sid.log.w miejscu SID powinien znaleźć się SID naszej bazy. Przykładowo alert log bazy CRM będzie nazywał się alert_crm.log. Pliki dziennika powtórzeń- pliki w których zapisywane są informację na temat wszystkich zmian w bazie. Każda baza musi posiadać przynajmniej dwa pliki dziennika powtórzeń,ponieważ działają one naprzemiennie. Po zapełnieniu się jednego z plików,kolejny wpisy umieszczane są w drugim. Zarchiwizowane pliki dziennika powtórzeń-według ustawień domyślnych pliki dziennika powtórzeń są nadpisywane po ich zapełnieniu, a poprzednia zawartość ulega utraceniu. Mamy jednak możliwość zachowania informacji o zmianach korzystając z trybu archivelog. W trybie tym przed wyczyszczeniem plików dziennika powtórzeń tworzone są ich kopie czyli archivelogi które składowane są wraz z backupami. Domyślnie baza znajduje się w trybie noarchivelog (czyli archivelogi nie są wytwarzane). Archivelogi są potrzebne jeśli zechcemy wykonywać gorące 14/108

15 backupy. Są też niezbędne jeśli zechcemy odtwarzać bazę do chwili tuż przed awarią. Jest to możliwe, ponieważ archivelogi zawierają historię tego co się działo w bazie. W przypadku awarii odtwarzanie przebiega w taki sposób, że najpierw odtwarzany jest stan plików danych z backupu, a następnie doczytywane są zmiany od momentu zrobienia backupu do chwili tuż przed awarią z archivelogów. Aby przejść do trybu archivelog w pierwszej kolejności kładziemy bazę. Następnie podnosimy bazę do trybu mount w którym możemy włączyć wytwarzanie się archivelogów korzystając z komendy alter database archivelog. Na końcu wracamy do trybu open. Pliki danych-pliki w których przechowywane są wszystkie dane umieszczone w bazie. Jeden plik danych może być przypisany tylko do jednego tablespace, ale na jeden tablespace może składać się wiele plików. Pliki danych mogą automatycznie zwiększać swój rozmiar gdy zabraknie w nich miejsc,jeśli administrator przy tworzeniu skorzysta z komendy autoextend. Użytkownik HR i jego schemat Użytkownik HR Oracle poczynając od wersji 10g wzwyż posiada predefiniowanego użytkownika HR. Służy on do celów testowych, posiada kilka tabel z przykładowymi danymi. Aby móc zacząć z niego korzystać, musimy z poziomu użytkownika SYS odblokować go poprzez system zarządzania bazą APEX. Jeśli tego nie zrobimy, Oracle będzie odrzucać połączenia do bazy danych. W tym celu wchodzimy poprzez przeglądarkę na adres i logujemy się jako użytkownik SYS z hasłem ustawionym przy instalacji. Przechodzimy do Administration->Database Users->Manage Users 15/108

16 Wybieramy użytkownika HR a następnie zmieniamy pole Account Status z Locked na Unlocked. Ustawiamy również hasło dla odblokowywanego użytkownika. Teraz możemy się wylogować z konta użytkownika SYS, a następnie zalogować jako HR. Przechodzimy do Objects gdzie możemy przejrzeć dostępne dla tego użytkownika tabele. 16/108

17 System APEX jest dostępny od razu po instalacji bazy Oracle w wersji Express. Jeśli po wejściu w adres nic się nie wyświetla, lub widnieje informacja o błędzie, najlepiej sprawdzić ustawienia zapory internetowej. Być może będziemy zmuszeni dodać port 8080 do wyjątków. Istnieje alternatywna metoda odblokowania użytkownika HR. Możemy z poziomu dowolnego klienta podłączyć się do bazy jako SYS i wykonać następujące polecenie: ALTER USER HR IDENTIFIED BY HR ACCOUNT UNLOCK; Poleceniem tym odblokujemy schemat użytkownika HR, oraz nadamy mu hasło HR. Schemat użytkownika HR Przykładowe dane użytkownika HR są informacjami o firmie, jej oddziałach i pracownikach. Tabela departments zawiera dane o działach firmy. Tabela locations zawiera dane o położeniach w których mogą znajdować się działy. Tabela countries zawiera informacje o krajach w których znajdują się poszczególne lokalizacje działów. Tabela regions zawiera dane o regionach całego świata w których znajdują się kraje. Tabela jobs zawiera informacje o stanowiskach które zajmują pracownicy firmy oraz przypisanych do nich minimalnych i maksymalnych płac. Tabela employees zawiera informacje o pracownikach firmy. Tabela job_history zawiera informacje jacy pracownicy w jakim okresie zajmowali jakie stanowiska. Podstawowe narzędzia 17/108

18 SQL*Plus Językiem który umożliwia zarządzanie bazą danych jest język SQL (Structured Query Language). Wszystkie narzędzia dostępne na rynku służące do graficznego zarządzania bazą i umożliwiające wyklikanie zapytania są jedynie nakładką na ten język. SQL*Plus jest podstawowym narzędziem Oracle służącym do komunikacji z bazą danych. Umożliwia wykonywanie zapytań do bazy i wyświetlanie wyników. Poza obsługą poleceń SQL, SQL*Plus posiada też zestaw własnych komend służących do konfiguracji programu oraz nawiązywania połączeń z bazami. Aby uruchomić SQL*Plus wybieramy jego nazwę z menu start lub wpisując w konsoli: sqlplus lub sqlplus nazwa_uzytkownika/haslo@sidbazy SQL*Plus jest instalowany podczas instalacji Oracle Database. Mimo że jest programem konsolowym i subiektywnie postrzegając - mało wygodnym, warto się z nim zapoznać. Jednym z zasadniczych powodów jest fakt, że przy jego użyciu możemy sterować pracą instancji oraz zarządzać danymi i obiektami bazodanowymi, również na serwerach które pozbawione są środowiska graficznego. Serwery produkcyjne rzadko kiedy udostępniają port 1521 (czyli domyślny port nasłuchu listenera), a często ten port jest blokowany na poziomie bramki sieciowej. Mamy wówczas jedynie SSH i naszym jedynym narzędziem staje się właśnie SQL*Plus. Podstawowe polecenia SQL*PLUS CONNECT polecenie nawiązuje połączenie ze wskazaną bazą danych. Niezbędne do rozpoczęcia pracy z bazą danych. Bez nawiązania połączenia z bazą danych nie możemy wykonywać na niej żadnych operacji. Składnia polecenia connect jest następująca: connect nazwa_użytkownika/hasło@nazwa_bazy_wg_deskryptora Ciąg który następuje po to nazwa połączenia wg pliku tnsnames.ora. Możemy również podłączyć się do instancji podając adres ip serwera oraz SID bazy. Przykład: connect hr/test@ /xe 18/108

19 Aby zalogować się na użytkownika HR, po wcześniejszym odblokowaniu go, podajemy następującą ścieżkę: connect krótszą formą polecenia connect jest polecenie conn : conn hr/hasło_które_ustawiliśmy@localhost; Korzystając z SQL*Plusa możemy również podać dane autoryzacyjne przy uruchamianiu programu: sqlplus hr/hr@localhost; Możemy łączyć się przy pomocy SQL*Plusa za pośrednictwem listenera lub bezpośrednio, nawet do wyłączonej instancji. Pomijamy w takim np.: sqlplus hr/hr Warunkiem połączenia się jest w takim przypadku uruchamianie SQL*Plusa z konsoli hosta na którym zainstalowana jest baza lub poprzez SSH. Zaletą jest możliwość połączenia się nawet do wyłączonej instancji (tylko jako SYS). Łącząc się jako SYS musimy pamiętać o dodaniu frazy as sysdba: sqlplus sys/haslo as sysdba lub sqlplus sys/haslo@ /xe as sysdba DISCONNECT Polecenie zamyka sesję nawiązaną przy pomocy connect, nie powoduje wyjścia z programu. 19/108

20 EXIT Polecenie kończy sesję, okno programu zostaje zamknięte. DESC To polecenie pozwala na uzyskanie opisu wybranego obiektu bazy Uruchamia polecenia określone w pliku wskazanym jako parametr polecenia. Np. jeśli na partycji 20/108

21 c:\ naszego dysku stworzymy plik test.sql w którym umieścimy zapytanie o treści: select * from jobs; Uruchamiamy odnosząc się do stworzonego wcześniej skryptu, czego efektem będzie taki oto ekran: SPOOL przy pomocy tej komendy jesteśmy w stanie zapisać do pliku tekstowego wszystkie wykonywane 21/108

22 polecenia oraz wyniki ich działań. Wszystkie te dane będą pozostawać wyłącznie w pamięci operacyjnej i nie będą widoczne w pliku aż do czasu wykonania polecenia spool off, kończącego zapis. Poniżej konsola wraz z plikiem efekty.txt do którego zostały zapisane komendy wraz z wynikami. Proszę zwrócić uwagę że zostały zapisane działania w konsoli wykonane dopiero po wydaniu komendy spool. SPOOL OFF Kończy zapis do pliku, zatrzymuje komendę spool. Podstawowe opcje SQL*Plus Opcje SQL*Plusa ustawiamy przy pomocy polecenia SET: 22/108

23 SET nazwa_opcji wartość Na przykład: autocommit {on off } Zmienna modyfikuje ustawienie automatycznego zatwierdzenia wykonania poleceń lub po wykonaniu serii instrukcji (Domyślnie on). Commit jest poleceniem służącym do zatwierdzania zmian w danych, wprowadzonych w obrębie sesji. Polecenie to może być wydawane jawnie lub niejawnie tj. możemy wyłączyć autocommit i zatwierdzać samodzielnie poprzez wydanie komendy commit; lub ustawić automatyczne zatwierdzanie. Jeśli nie zatwierdzimy zmian danych, zmiany będą dotyczyć tylko naszej sesji i nie będą widoczne dla innych użytkowników. echo {on off} decyduje, czy polecenia wysyłane na serwer są powtórnie wyświetlane w wyniku wykonania się polecenia. (Domyślnie on) linesize n zmienna określa jak długa ma być linia w buforze ekranowym SQL*Plusa. (Domyślnie 80) pagesize n określa rozmiar strony w wierszach. (Domyślnie 24) serveroutput {on off} określa, czy komunikaty wypisywane podczas działania podprogramów PL/SQL mają być wyświetlane na konsoli SQL*Plusa. Domyślnie ustawiony jest brak wyświetlania. (Domyślnie off) 23/108

24 Ćwiczenia 1. Podłącz się jako użytkownik hr do lokalnej bazy. 2. Uruchom zapisywanie tego co się dzieje na ekranie do pliku. 3. Wyświetl strukturę tabeli departments. 4. Zatrzymaj zapisywanie do pliku i sprawdź co zawiera plik. 5. Stwórz plik który zawiera polecenie opisania tabeli. 6. Wykonaj polecenie z pliku. 7. Rozłącz się z bazą bez zamykania okna programu. SQL DEVELOPER 24/108

25 Graficzną alternatywą dla SQL Plusa jest SQL Developer. Możemy z niego korzystać pod warunkiem, że możemy się połączyć z serwerem Oracle poprzez sieć (mamy port nasłuchu otwarty) lub jeżeli łączymy się bezpośrednio z maszyny na której zainstalowany jest serwer. Jest to program bezpłatny rozpowszechniany przez firmę Oracle. Musimy go jednak zainstalować oddzielnie, nie jest dostarczany wraz z bazą danych. TWORZENIE, TESTOWANIE I ZAPISYWANIE NOWEGO POŁĄCZENIA 25/108

26 26/108

27 Aby utworzyć nowe połączenie klikamy zielony krzyżyk znajdujący się w lewym górnym rogu na zakładce Connections. W poniższym oknie wprowadzamy: Connection Name - własna nazwa połączenia Username - nazwa użytkownika z którego uprawnieniami chcemy połączyć się do bazy danych. Password hasło w.w. Użytkownika. Save Password zaznaczamy jeśli chcemy aby hasło zostało zapamiętane w programie. Jeśli tego nie zaznaczymy, przy każdym łączeniu się z bazą będzie trzeba to hasło wpisać. Hostname host na którym znajduje się serwer Oracle. Jeśli łączymy się do bazy znajdującej się na tym samym komputerze, wpisujemy localhost Port port sieciowy pod którym nasłuchuje serwer bazy danych. Domyślny to 1521 SID sid bazy, dla naszych potrzeb będzie to zawsze XE. Jeśli pracujesz na innej wersji Oracle niż Express Edition zapytaj swojego administratora o sid bazy. Jeśli autoryzujemy się jako użytkownik SYS, musimy dodatkowo zmienić ustawienie Role z Default na SYSDBA. Prawidłowość wprowadzonych danych możemy sprawdzić naciskając przycisk Test. W lewym dolnym rogu okna zostanie wypisany status połączenia: Success jeśli dane umożliwiają autoryzację, lub Failure z przyczyną jeśli nie można zrealizować połączenia. Połączenie możemy zapisać klikając SAVE, oraz połączyć się klikając CONNECT. DRZEWO OBIEKTÓW 27/108

28 Po uruchomieniu nowego połączenia możemy w zakładce Connections kliknąć w symbol plusika znajdujący się przy nazwie połączenia. Pojawi nam się okno edycji oraz lista obiektów bazy danych pogrupowana w kategorie. Rozwijając kolejne gałęzie możemy przeglądać listy obiektów, struktury, a nawet zawartość tabeli (po dwukrotnym kliknięciu symbolu danego obiektu). Klikając prawym przyciskiem na nazwę połączenia, a następnie z menu wybierając Open SQL Worksheet uruchomimy kolejny edytor kodu. Klikając View - > DBMS Output uruchomi nam się 28/108

29 konsola na której wyświetlane będą przez nas komunikaty wywoływane w podprogramach PL/SQL.& Aby konsola wyświetlała komunikaty z aktywnego połączenia musimy kliknąć zielony krzyżyk w jej lewym górnym rogu a następnie wybrać połączenie które nas interesuje: URUCHAMIANIE PODPROGRAMÓW W EDYTORZE Po napisaniu programu w edytorze możemy go uruchomić naciskając przycisk run wyglądający jak Play w magnetofonach. Jeśli w edytorze mamy kilka podprogramów, zostaną wykonane wszystkie. Jeśli chcemy uruchomić tylko jeden, zaznaczamy go i klikamy run lub kombinację klawiszy CTRL + ENTER 29/108

30 Obiekty bazodanowe Tabele Tworzenie tabeli Tworząc tabelę podajemy pola jakie ta tabela ma posiadać, rodzaj danych przechowywanych przez te pola oraz własności tabeli: Podczas tworzenia możemy nakładać wszystkie constrainty takie jak primary key czy foreign key. Możemy również ustawić dodawanie wartości domyślnej w przypadku nie wprowadzenia wartości żadnej dla danego pola podczas uzupełniania tabeli. Odbywa się to przy pomocy klauzuli DEFAULT. 30/108

31 Tworzenie tabeli na podstawie zapytania Tabelę możemy stworzyć również na podstawie zapytania. Stworzona w ten sposób tabela będzie zawierała wszystkie dane które zostaną nam zwrócone jako wynik zapytania. Jeśli chcemy aby została stworzona tylko struktura, możemy po klauzuli WHERE dodać jakiś warunek który nigdy nie może zajść. Usuwanie tabeli Aby usunąć tabelę korzystamy z polecenia drop: 31/108

32 Zmiana nazwy tabeli Aby zmienić nazwę tabeli stosujemy polecenie RENAME: Dodawanie kolumn Do dodawania kolumn do tabeli wykorzystujemy ALTER TABLE. Możemy wykorzystywać wszystkie parametry jakie stosujemy podczas tworzenia tabeli (parametry dla kolumny). Usuwanie kolumn Do usuwania kolumn wykorzystujemy DROP COLUMN: 32/108

33 Zmiana własności kolumn Aby zmienić typ kolumny stosujemy polecenie MODIFY. Typ kolumny zmienić możemy, o ile dane zawarte w tej kolumnie mogą zostać przekonwertowane do nowego typu. Np. możemy zmienić długość kolumny, możemy zmienić typ liczbowy w typ tekstowy, ale nie możemy zmienić typu tekstowego w liczbowy jeśli dane zawarte w kolumnie liczbowej nie są wartościami numerycznymi. Więzy integralności Dzięki więzom integralności nie można tak zmodyfikować danych by straciły on spójność. Są zbiorem zasad nałożonych na tabele w bazie danych. Primary Key 33/108

34 Zapewnia unikalność wartości w kolumnie. Najczęściej zakładany jest na kolumnę która przechowuje dane jednoznacznie określające pojedynczy wiersz. W tabeli może być tylko jeden klucz główny. Zapewnia nie występowanie wartości NULL w kolumnie na którą jest nałożony. Unique Zapewnia unikalność wartości w kolumnie, jednak w przeciwieństwie do PRIMARY KEY takich kluczy może być więcej niż jeden, oraz umożliwia występowanie wartości NULL. NOT NULL Zapobiega wstawianiu wartości NULL do kolumny. Check Zapewnia że wartość wstawiana do kolumny spełnia wymagany warunek logiczny. Nie można w nim wykorzystywać odwołań do innych tabel, funkcji agregujących, SYSDATE. Foreign key Jest to klucz obcy. Służy do definiowania relacji pomiędzy tabelami. Zapewnia że rekord w tabeli podrzędnej zawsze będzie miał swojego odpowiednika w tabeli nadrzędnej. Klucz obcy musi się odwoływać do kolumny (kolumn) w tabeli nadrzędnej, na których założony jest UNIQUE lub klucz główny. Zakładanie konstraintów Więzy możemy zakładać na dwa sposoby. Przy tworzeniu tabeli, oraz nakładając je na już istniejącą tabelę. Poniżej przykład zakładania więzów już przy tworzeniu tabeli: 34/108

35 Przykład zakładania konstrainów na istniejącej tabeli: Wyjątek od reguły stanowi NOT NULL. Własność NULL/NOT NULL ustawiamy poprzez zmiane stanu: Włączanie i wyłączanie konstraintów Constrainty możemy włączyć lub wyłączyć. Możliwość ta staje się przydatna gdy chcemy wykonać czynność którą uniemożliwiłby nam założony constraint. Przykładowo zdejmujemy klucz obcy (FOREIGN KEY) z tabeli jeśli uzupełniamy ją danymi które nie mają swoich odpowiedników w tabeli nadrzędnej. 35/108

36 Możemy po wykonaniu zaplanowanych czynności włączyć constraint, pod warunkiem że jego warunek zostanie spełniony (np. uzupełnimy wpisy w tabeli nadrzędnej w przypadku FOREIGN KEY). Możemy również włączyć constraint bez walidacji istniejących danych. Constraint będzie w takim wypadku obowiązywał tylko dla danych wprowadzonych później: Usuwanie konstraintów Aby zdjąć z tabeli constraint musimy skorzystać z polecenia drop podając nazwę klucza. Poniżej usuwam wszystkie constrainty z tabeli piłkarze. Widoki Jeśli często wykonujemy jakiej zapytanie do bazy danych, np. z użyciem wielu tabel lub po prostu długie, możemy zdefiniować widok. Korzystanie z niego będzie o wiele wygodniejsze. Możemy pobierać z niego dane jak ze zwykłej tabeli. Nagle długie zapytanie z wieloma parametrami do którego często trzeba coś dodawać możemy zamienić w mniej więcej coś takiego: SELECT * FROM NAZWA_WIDOKU Widoki są strukturami całkowicie dynamicznymi, tzn. zapytanie, które je definiuje w momencie definicji jest tylko sprawdzane pod względem poprawności składniowej i semantycznej, natomiast nie jest wykonywane. Zapytanie to jest wykonywane w momencie odwoływania się do widoku. Widoki mają też zastosowanie w przypadku nadawania uprawnień. Możemy chcieć udostępnić użytkownikowi tylko część danych, lub część kolumn z tabeli. W takim wypadku tworzymy widok 36/108

37 o zadanych właściwościach, a użytkownikowi zezwalamy na dostęp do widoku a nie tabeli. Tworzenie widoków CREATE [OR REPLACE] [FORCE] VIEW NAZWA_WIDOKU AS TREŚĆ_ZAPYTANIA [ WITH READ ONLY] [WITH CHECK OPTION] Aby stworzyć widok, należy mieć uprawnienia do wszystkich obiektów do których odnosi się widok. OR REPLACE Dzięki tej klauzuli w przypadku gdyby widok o takiej nazwie już istniał zostanie nadpisany przez właśnie tworzony. FORCE Wymusza stworzenie widoku nawet jeśli zapytanie będące podstawą widoku jest niepoprawne (np. odnosi się do tabeli która jeszcze nie istnieje). WITH READ ONLY W niektórych przypadkach można stosować instrukcje DML (np. INSERT) na widokach, ta instrukcja nawet jeśli formalnie byłoby to możliwe, uniemożliwia to. WITH CHECK OPTION Ta opcja sprawia, że w przypadku (jeśli to możliwe dla danego widoku) nie można wrzucić danych albo zmienić ich w taki sposób że nie będą widoczne w tym widoku. Wykonywanie operacji DML na widokach W przypadku zapytań, widoki funkcjonują tak jak tabele. W zależności od operacji DML widoki dotyczą różne właściwości. W żadnym z poniższych wypadków nie możemy wykonać operacji jeśli 37/108

38 widok został stworzony z klauzulą WITH READ ONLY. Update Widok nie może być oparty na wielu tabelach Nie może zawierać klauzuli DISTINCT Nie może zawierać GROUP BY ani funkcji grupowych Nie może zawierać skorelowanych zapytań Wyrażeń w kolumnie Delete Widok nie może być oparty na wielu tabelach Nie może zawierać klauzuli DISTINCT Nie może zawierać GROUP BY ani funkcji grupowych Nie może zawierać skorelowanych zapytań Insert Widok nie może być oparty na wielu tabelach Nie może zawierać klauzuli DISTINCT Nie może zawierać GROUP BY ani funkcji grupowych Nie może zawierać skorelowanych zapytań Wyrażeń w kolumnie Tabela, na której oparty jest widok zawiera kolumnę NOT NULL bez wartości domyślnej i kolumna ta nie jest odwzorowana w widoku. Jeżeli widok zostanie utworzony z klauzulą WITH CHECK OPTION, to nie będzie można wstawić do niego żadnego wiersza, który nie byłby później widoczny w tym widoku. 38/108

39 Usuwanie widoków DROP VIEW NAZWA_WIDOKU; Sekwencje Tworzenie sekwencji Sekwencja jest obiektem podającym kolejne wartości wg ustalonych kryteriów. Sekwencje stosujemy często w celu tworzenia kluczy głównych tabel. Po co przy wstawianiu kolejnych wierszy podawać ręcznie kolejny numerek po którym dany wiersz będziemy identyfikować? Łatwo się przy tym pomylić i wstawić numer który już istnieje, a poza tym wiąże się to z dość uciążliwym sprawdzaniem ostatniego numerka. Niech zrobi to za nas automat! 39/108

40 Na podstawie wyżej przytoczonego przykładu: create sequence Po tym następuje podanie nazwy sekwencji. W nazwie sekwencji nie może być spacji. Minvalue Wartość minimalna jaką może przybrać sekwencja. Maxvalue Wartość maksymalna jaką może przybrać sekwencja. Start with Określa wartość od jakiej ma się rozpoczynać sekwencja. Increment by Określa wartość o jaką ma się zmieniać aktualny stan sekwencji po każdym pobraniu danych. Jako parametr tego polecenia możemy również podać liczbę ujemną. Wartość sekwencji będzie wtedy maleć. Cycle / nocycle Parametr ten określa czy sekwencja może się przekręcić (jak licznik przebiegu w samochodzie) i rozpocząć naliczanie od początku. Cache / nocache 40/108

41 klauzula CACHE włącza wykonywanie pre-alokacji numerów sekwencji i przechowywanie ich w pamięci, co skutkuje zwiększeniem szybkości generacji kolejnych liczb. Klauzula NOCACHE wyłącza tę możliwość. Domyślnie przyjmowane jest CACHE 20. Wartość podana w CACHE musi być mniejsza niż MAXVALUE - MINVALUE Order / noorder Klauzula ORDER gwarantuje, że kolejne liczby będą generowane w porządku jakim otrzymane zostały przez system polecenia ich generacji. Klauzula NOORDER wyłączą tę własność. Pobieranie wartości z sekwencji Do pobierania danych z sekwencji, wykorzystywane są dwie pseudokolumny currval i nextval. Nextval Służy do pobierania następnej wartości z sekwencji. Currval Służy do pobierania aktualnej wartości sekwencji. Przed wykorzystaniem currval należy wykonać przynajmniej raz nextval na danej sekwencji. W przypadku braku takiej inicjacji, zarówno currval jak i nextval będą miały tą samą wartość odpowiadającą parametrowi start with dla danej 41/108

42 sekwencji. Pobierać wartości z sekwencji możemy na dwa sposoby. Wykorzystywać do tego select na tabeli (np. dual) lub w instrukcjach DML. O tym drugim sposobie będziemy mówić nieco później. Poniżej przytaczam przykłady pobrania wartości currval i nextval oraz różnice pomiędzy nimi. wykorzystanie sekwencji w instrukcjach DML Dodając dane do tabeli często zachodzi konieczność wygenerowania dla każdego wpisu unikalnego id dla każdego wiersza. Zdarza się że jest to wymagane z powodu założenia na danej tabeli klucza głównego. W takiej sytuacji najwygodniej jest skorzystać z sekwencji. Sekwencje mogą produkować tylko wartości liczbowe. Usuwanie sekwencji Aby usunąć stworzoną sekwencję należy wykorzystać polecenie drop o następującej konstrukcji: DROP SEQUENCE nazwa_sekwencji; tak jak poniżej: 42/108

43 Modyfikacja sekwencji Aby zmienić lub nadać jakiś parametr istniejącej sekwencji stosujemy konstrukcję: ALTER SEQUENCE NAZWA_SEKWENCJI NAZWA PARAMETRU {WARTOŚĆ}; Nie możemy tylko zmienić parametru START WITH co widać wraz z przykładami prawidłowego zastosowania ALTER SEQUENCE na poniższym obrazku: Indeksy Indeksy pozwalają zdecydowanie przyspieszyć wyszukiwanie wierszy w tabelach. W przypadku braku indeksu znalezienie wiersza spełniającego pewien warunek wymagałoby przejrzenia wiersz po wierszu całej tabeli. W przypadku dużych i bardzo dużych tabel, takie wyszukiwanie mogłoby trwać bardzo długo. W związku z drzewiastą konstrukcją indeksu można szybko znaleźć położenie poszukiwanych wierszy. Sprawia to że wyszukiwanie trwa zawsze krótko. Tworzenie indeksu Ogólna konstrukcja polecenia tworzącego indeks: 43/108

44 CREATE INDEX NAZWA_INDEKSU ON NAZWA_TABELI (KOLUMNA); Indeksy możemy zakładać na więcej niż jednej kolumnie. Wystarczy dodać je po przecinku. Indeksy warto zakładać na tych kolumnach które często występują w zapytaniach jako warunek w filtracji wierszy lub kolumna po której grupujemy. Indeksy przyspieszają pobieranie danych, ale spowalniają ich dodawanie/zmianę. Wynika to z tego, że informacje o nowych danych muszą zostać dodane nie tylko do tabeli ale również do indeksu. Usuwanie indeksu DROP INDEX NAZWA_INDEKSU; Linki bazodanowe Linki bazodanowe są odwołaniami do innej bazy danych, mogącej znajdować się nawet na odległym (fizycznie) serwerze. Upraszczają pracę na wielu bazach danych, ponieważ możemy korzystać z innych baz w podobny sposób jak ze schematów innych użytkowników. Poniżej widzimy sposób tworzenia linka bazodanowego. CREATE DATABASE LINK NAZWA_LINKU CONNECT TO NAZWA_UZYTKOWNIKA IDENTIFIED BY HASLO USING ALIAS_BAZY Przykładowe zastosowanie:& 44/108

45 45/108

46 46/108

47 47/108

48 Jak widać stworzyliśmy link bazodanowy odnoszący się do bazy danych określonej w pliku tnsnames.ora jako XE. Plik ten zawiera szczegółowe dane dotyczące połączenia 'xe'. Dzięki wpisowi w tym pliku system wie do jakiej bazy danych się odwoływać. Możemy również podać adres IP innego serwera Oracle, tak jak to widać na poniższej ilustracji: 48/108

49 Zdalny serwer Oracle na podstawie danych autoryzacyjnych przekieruje nas do właściwego schematu. Od momentu stworzenia linka bazodanowego możemy korzystać z obiektów w zdalnej bazie danych tak jak z lokalnych, musimy jedynie po nazwie obiektu znajdującego się w tej bazie. Ćwiczenia 1. Stwórz tabelkę kluczem głównym, jedną kolumną z unikalnymi wartościami oraz jedną do której zawsze trzeba będzie wprowadzać dane 49/108

50 2. Stwórz widok który umożliwi wyświetlanie pracowników (tab. employees) z departamentu o podanej nazwie (tab. departments) 3. Stwórz widok który umożliwi dodawanie wierszy do tabelki regions 4. Stwórz link bazodanowy do schematu użytkownika hr kolegi. Sprawdź czy są jakieś różnice pomiędzy Twoją a jego tabelką employees 5. Stwórz tabelę Miasta zawierającą: id, nazwę miasta, klucz obcy do tabeli regions 6. Załóż klucz główny na pole id tabeli Miasta. 7. Załóż klucz unikalny na pole z nazwą miasta. 8. Dodaj do tabeli Miasta pole dzielnica 9. Załóż indeks na pole dzielnica 10.Stwórz sekwencję która rozpoczyna się od 1, o wartości maksymalnej 9999 postępującą o Stwórz sekwencję która rozpoczyna się od 9999, o wartości minimalnej 1 postępującą o Sprawdź wartość sekwencji nie zmieniając jej wartości. FLASHBACK Parametr UNDO_RETENTION Jeśli zdarzyło nam się przy jakimś update i chcielibyśmy cofnąć zmiany, co powinniśmy zrobić? Jeśli nie mamy włączonego autocommita to żaden problem zrobić ROLLBACK. Co jednak jeśli zacommitowaliśmy sami, albo mieliśmy włączonego autocommita i dopiero po kilku innych 50/108

51 zmianach odkryliśmy pomyłkę? Dzięki opcji flashback nie zawsze jest konieczne odzyskiwanie danych z backupu. Odpowiada za to tablespace undo. To jak długo stare dane mają pozostawać dostępne określa parametr undo_retention ustawiony domyślnie na 15 minut. Aby poznać wartość parametru undo_retention(wartość podawana w sekundach) musimy zajrzeć do słownika v$parameter. Wywołujemy zatem komendę: SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME='UNDO_RETENTION'; Wartość tę możemy modyfikować używając komendy: ALTER SYSTEM SET UNDO_RETENTION=wartość_w_sekundach SCOPE=SPFILE; Po zmianie parametru undo_retention możemy sprawdzić czy parametr jest zmieniony. Jako, że wpisaliśmy scope=spfile; musimy zamknąć i ponownie otworzyć bazę danych. AS OF TIMESTAMP Zróbmy sobie kopię tabeli employees: 51/108

52 Spójrzmy na zegarek. To jest czas kiedy z tabelą jest jeszcze wszystko w porządku. Poczekajmy parę chwil, żeby czas chociaż o minutę zmienił. Teraz popełniamy pomyłkę zmieńmy wysokość wynagrodzenia pracowników (kolumna salary) zapominając dodać warunek where lub po prostu skasujmy zawartość tabeli. Nie kasujmy danych przy użyciu komendy truncate, ponieważ tak skasowanych danych nie uda nam się odzyskać. Poczekajmy parę chwil. Określmy dokładnie czas kiedy tabela znajdowała się jeszcze w prawidłowej postaci. Aby zobaczyć jak wyglądała tabela o określonym czasie posługujemy się funkcją to_timestamp: 52/108

53 SELECT * FROM WYPADEK as of timestamp (to_timestamp( '12:38: ','hh24:mi:ss yyyy-mm-dd') ); Dodanie klauzuli as of timestamp spowodowało wyświetlenie całej zawartości tabeli WYPADEK takiej jaka była we wskazanym czasie. Funkcja to_timestamp zwraca nam dane typu timestamp z tekstu. Drugi parametr to wzorzec. Przyjmuje takie same znaczniki jak funkcja to_date. Przyjmuje datę w postaci tekstu, zamienia wg. wzorca na format daty. Jeśli chcesz dodać dodatkowe warunki do zapytania, where dodawaj zawsze po ciągu związanym z flashbackiem: SELECT * FROM WYPADEK as of timestamp to_timestamp('12:38: ','hh24:mi:ss yyyy-mmdd') where department_id=60; Bardzo wygodną możliwość porównywania starej i nowej zawartości tabeli umożliwiają nam operatory zbiorowe takie jak INTERSECT czy MINUS Możemy teraz przenieść sobie te dane do jakiejś innej tabeli: CREATE TABLE WYPADEK2 AS SELECT * FROM WYPADEK WHERE 1=2; INSERT INTO WYPADEK2 SELECT * FROM WYPADEK as of timestamp ( to_timestamp('12:38: ','hh24:mi:ss yyyy-mm-dd') ); FLASHBACK TABLE Aby wykorzystać mechanizm flashback do przywrócenia tabeli do stanu z określonego czasu, wykorzystujemy komendę flashback table: 53/108

54 FLASHBACK TABLE EMPLOYEES TO TIMESTAMP TO_TIMESTAMP(' :00:03','dd-mm-yyyy hh24:mi:ss'); Taka możliwość dostępna jest niestety tylko w najbardziej rozbudowanej i jednocześnie najdroższej wersji RDBMS Oracle tj. Enterprise. Istnieje również możliwość przywrócenia skasowanej tabeli. Jeśli przypadkowo usuniemy tabelę poleceniem: DROP TABLE nazwa_tabeli; Możemy zajrzeć do 'śmietnika' naszej bazy. Jest on opróżniany z danej tabeli po czasie, który upłynie między usunięciem tabeli a wartością UNDO_RETENTION: SELECT * FROM USER_RECYCLEBIN; * jeśli jesteśmy zalogowani jako sys, zostaną nam wyświetlone tabele usunięte przez wszystkich użytkowników. Wpisujemy komendę: SELECT * FROM DBA_RECYCLEBIN; W celu przywrócenia usuniętej tabeli wprowadzamy komendę: FLASHBACK TABLE nazwa_tabeli TO BEFORE DROP; 54/108

55 Ćwiczenia 1. Ustaw parametr undo_retention w taki sposób by przechowywane były informacje o zmianach 55/108

56 przez półtorej godziny. 2. Stwórz nową tabelę. Dodaj do niej dane. Odczekaj kilka chwil i wprowadź zmiany. Sprawdź jaka była zawartość tabeli przed zmianami. 3. Skasuj nowo stworzoną tabelę. Odzyskaj ją. 56/108

57 UŻYTKOWNICY I UPRAWNIENIA Tworzenie użytkownika W celu stworzenia użytkownika dla bazy ORACLE musimy zalogować się do niej jako sys, a następnie wydać polecenie, które nadaję nowemu użytkownikowi nazwę, oraz hasło do logowania: CREATE USER nazwa_użytkownika IDENTIFIED BY hasło; Nadawanie uprawnień użytkownikowi Następną czynnością jest nadanie nowo stworzonemu użytkownikowi nadanie odpowiednich uprawnień. Poniżej widzimy przykładowe uprawnienia: CREATE TABLE - umożliwia tworzenie tabel CREATE SESSION - umożliwia łączenie się z bazą CREATE VIEW - umożliwia tworzenie widoku CREATE USER - umożliwia tworzenie nowych użytkowników DROP USER - umożliwia usuwanie użytkowników SELECT umożliwia przeglądanie tabeli UPDATE - umożliwia zmianę wartości w tabeli INSERT - umożliwia dodawanie nowych wierszy w tabeli DELETE - umożliwia usuwanie wierszy w tabeli Aby nadać użytkowi uprawnienia wpisujemy: GRANT uprawnienie TO nazwa_uzytkownika; Zmiana hasła W celu zmiany hasła dla użytkownika wywołujemy następującą komendę: ALTER USER nazwa_użytkownika identified by nowe_hasło; 57/108

58 ODBIERANIE UPRAWNIEŃ UŻYTKOWNIKOWI Aby odebrać użytkownikowi uprawnienia należy wpisać komendę: REVOKE uprawnienie FROM nazwa_uzytkownika; USUWANIE UŻYTKOWNIKA Aby usunąć użytkownika wprowadzamy komendę: DROP USER nazwa_uzytkownika; to usuwanie jest możliwe do wykonania, kiedy użytkownik nie posiada w swoim schemacie żadnych obiektów. DROP USER nazwa_uzytkownika CASCADE; ten sposób usuwamy wszystkie obiekty dodane/stworzone przez konkretnego użytkownika 58/108

59 NADAWANIE ROLI UŻYTKOWNIKOM Nadając użytkownikowi role, nadajemy mu pewien zbiór uprawnień zawartych w danej roli. Najważniejsze role to: DBA - rola jaką ma użytkownik system. Posiada wszystkie podstawowe uprawnienia niezbędne do administrowania bazą danych. CONNECT, RESOURCE- te dwie role zazwyczaj nadajemy użytkownikom zaraz po ich stworzeniu. Pozwalają na łączenie się z bazą danych (CONNECT), oraz tworzenie obiektów w obrębie swojego schematu. PUBLIC - Ta rola nadawana jest domyślnie każdemu użytkownikowi przez system. Nadając jakieś uprawnienie tej roli otrzymają ją wszyscy. GRANT CONNECT, RESOURCE TO nazwa_uzytkownika; 59/108

60 TWORZENIE WŁASNYCH ROLI Poza predefiniowanymi rolami mogą istnieć również role stworzone przez nas samych (lub innych użytkowników). Rolę tworzymy poleceniem: CREATE ROLE nazwa_roli; rolę usuwamy komendą: DROP ROLE nazwa_roli; Dzięki temu zabiegowi użytkownik nie będzie mógł korzystać z uprawnień z nią związanych zanim nie poda do niej hasła. W roli mogą znajdować się zarówno polecenia obiektowe jak i systemowe. Do roli mogą należeć inne role. Uprawnienia nadajemy roli poleceniem: GRANT uprawnienie TO nazwa_roli; Np. GRANT CREATE TABLE TO nazwa_roli; 60/108

61 SPRAWDZANIE PRZYZNANYCH ROLI I UPRAWNIEŃ ROLI Aby sprawdzić jakie role zostały nam przypisane możemy zajrzeć do słownika user_role_privs: SELECT * FROM USER_ROLE_PRIVS; Jako użytkownik SYS możesz też sprawdzić jakie role zostały nadane wszystkim użytkownikom: SELECT * FROM DBA_ROLE_PRIVS; Oczywiście możemy też na tym widoku wykonywać normalne selecty, więc bez problemu sprawdzimy jakie role zostały przypisane wybranemu użytkownikowi. Możemy też sprawdzić jakie uprawnienia systemowe zostały przypisane roli: SELECT * FROM ROLE_SYS_PRIVS; W tym widoku zobaczymy jednak tylko uprawnienia systemowe. Aby zobaczyć uprawnienia obiektowe, zaglądamy do słownika ROLE_TAB_PRIVS SELECT * FROM ROLE_TAB_PRIVS; ODBIERANIE ROLI UŻYTKOWNIKOM Aby odebrać rolę użytkownikowi wywołujemy komendę: REVOKE nazwa roli FROM nazwa_uzytkownika; 61/108

62 Ćwiczenia 1. Stwórz rolę o nazwie ksiegowa oraz drugą o nazwie uber_ksiegowa. 2. Dodaj do roli role connect i resource. 3. Do roli ksiegowa dodaj uprawnienia do czytania tabeli employees w schemacie hr. Do roli uber_ksiegowa dodaj rolę ksiegowa oraz dodatkowo uprawnienia do zmiany i kasowania zawartości tej tabeli. 62/108

63 PROFILE Podstawowe informacje o profilach Aby włączyć możliwość modyfikowania przez nas profili musimy zacząć od wydania polecenia: ALTER SYSTEM SET RESOURCE_LIMIT=TRUE; Reguły dotyczące systemu: SESSIONS_PER_USER liczba określająca maksymalną ilość sesji użytkownika, CPU_PER_CALL liczba (setnych sekund) określająca maksymalny czas CPU przydzielony sesji, CONNECT_TIME określa maksymalną długość sesji użytkownika, czas ten wyrażony jest w minutach, IDLE_TIME maksymalny czas bezczynności wyrażony w minutach, (jeżeli użytkownik czeka "bezczynnie" na wykonanie długiego zapytania to czas ten nie wlicza się do IDLE_TIME), LOGICAL_READS_PER_SESSION maksymalna ilość bloków (znajdujących się w pamięci RAM i na dysku twardym) jaka może być wykorzystana na potrzeby jednego zapytania (gdzie zapytanie dzieli się na parsowanie, wykonanie, zwrócenie wyników), LOGICAL_READS_PER_CALL maksymalna ilość bloków potrzeban na jedno zapytanie (gdzie zapytanie dzieli się na parsowanie, wykonanie, zwrócenie wyników), PRIVATE_SGA maksymalna liczba pamięci (w bajtach) jaką sesja może wykorzystać z ang. shared pool z SGA (ang. System Globar Area), można dodać przedrostek K lub M aby liczbę tą wyrazić w kilo lub megabajtach, Reguły dotyczące haseł: FAILED_LOGIN_ATTEMPTS maksymalna ilość nieudanych prób zalogowania, po jej przekroczeniu konto zostanie zablokowane, PASSWORD_LIFE_TIME maksymalny czas życia hasła, po jego upływie zalogowanie jest niemożliwe dopóki hasło nie zostanie zmienione, 63/108

64 PASSWORD_REUSE_TIME czas w dniach po którym hasło może być powtórnie wykorzystane, (przy zmianie hasła), PASSWORD_REUSE_MAX minimalna ilość zmian haseł po którym hasło może być powtórnie wykorzystane, po przypisaniu tej opcji dowolnej liczby, opcji PASSWORD_REUSE_TIME należy przypisać wartość unlimited, PASSWORD_LOCK_TIME liczba dni po jakich konto zostanie odblokowane, po maksymalnej liczbie nieudanych zalogowań, PASSWORD_GRACE_TIME maksymalny czas życia hasła, w dniach, PASSWORD_VERIFY_FUNCTION skrypt weryfikujący poprawność hasła, co ciekawe można tu umieścić każdy program napisany w języku PL/SQL, a to daje ogromne możliwości weryfikacji. Przykładowe scenariusze użytkownik może się zalogować tylko od godziny 8 16, lub jeżeli login użytkownika jest inny niż Bartek to zwróć losowy wyjątek i przerwij sesje ; Profil DEFAULT Każda baza ma profil o nazwie DEFAULT jest on domyślnie powiązany z każdym użytkownikiem. Każdy kolejny profil dziedziczy z profilu DEFAULT. Np. jeżeli nowy profil nie ma zdefiniowanego parametru IDLE_TIME, to przyjmuje wartość UNLIMITED z profilu DEFAULT. Profil DEFAULT każdej regule przypisuje wartość UNLIMITED, co oznacza parametr niezdefiniowany, czyli barak ograniczeń. Profil DEFAULT jest domyślnie przydzielany każdemu użytkownikowi. Polecenie zwracające listę profilów zainstalowanych w bazie danych Oracle wygląda następująco: SELECT * FROM DBA_PROFILES; 64/108

65 \ 65/108

66 Tworzenie profili Profil może być utworzony, powiązany z użytkownikiem, jak i odebrany użytkownikowi w dowolnej chwili. Zmienione lub nowe profile obowiązują od chwili nawiązania nowej sesji. Przykładowa komenda tworząca nowy profil o nazwie profil1 wygląda następująco: CREATE PROFILE profil1 LIMIT SESSIONS_PER_USER 3 FAILED_LOGIN_ATTEMPTS 3 IDLE_TIME 30; 66/108

67 Po stworzeniu profilu można go powiązać z użytkownikiem, a będzie on obowiązywać po rozpoczęciu nowej sesji. Użytkownik w danej chwili może mieć przypisany tylko jeden profil. Każdy kolejny nadpisuje poprzedni. Poniżej przedstawiono komendę, która przypisuje profil użytkownikowi: ALTER USER <użytkownik> PROFILE <nazwa_profilu>; 67/108

68 Zmiana profilu Chcąc zmienić profil o nazwie prof1, można posłużyć się komendą: ALTER PROFILE prof1 LIMIT IDDLE_TIME 20; Zmienia ona maksymalny czas bezczynności użytkownika na 20 minut. Zmiana będzie obowiązywać po nawiązaniu nowej sesji przez użytkownika. 68/108

69 Usuwanie profilu Profil można usunąć (pod warunkiem, że nie jest powiązany z użytkownikiem), za pomocą komendy: DROP PROFILE <nazwa_profilu>; Chcąc usunąć profil powiązany z użytkownikiem należy dodać opcję CASCADE: DROP PROFILE <nazwa_profilu> CASCADE; 69/108

70 Po odebraniu użytkownikowi profilu, np. przez jego usunięcie, automatycznie przydzielony mu zostaje profil DEFAULT, który zacznie obowiązywać po ustanowieniu nowej sesji. Profilu DEFAULT nie można usunąć. 70/108

71 Ćwiczenia 1. Stwórz profil o nazwie agent. Umożliw mu najwyżej 3 niepoprawne logowania. Po trzech nieudanych próbach konto użytkownika ma zostać zablokowane. 2. Do profilu agent dodaj takie ustawienia by użytkownik musiał zmieniać hasło co tydzień. 3. Zwiąż z w.w profilem 2 nowo stworzonych użytkowników. 4. Zmień parametr idle_time dla w.w profilu i zaobserwuj co się stanie z sesjami użytkowników. 71/108

72 Audyt monitorowanie użytkowników i działań na obiektach Włączanie opcji AUDIT Opcja monitoringu tego typu jest domyślnie wyłączona w Oracle. Musimy więc ją ustawić, a następnie zrestartować bazę. Logujemy się jako SYS, a następnie wydajemy polecenie : ALTER SYSTEM SET AUDIT_TRAIL=TRUE SCOPE=SPFILE; *Aby widzieć dokładnie wprowadzane przez użytkownika komendy SQL (również nieudane próby tj. np. brak uprawnień do obiektu), musimy zmodyfikować powyższe poleceni tak, aby zamiast TRUE było DB,EXTENDED: ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE; Następnie jako SYS należy wykonać SHUTDOWN IMMEDIATE (trzeba pamiętać, że ta opcja zerwie wszystkie sesje i wycofa transakcje). Logujemy się jako SYS do wyłączonej (!) bazy. Aby móc to zrobić korzystamy z SQL*Plusa i logujemy się bez Co za tym idzie, należy to zrobić z komputera na którym zainstalowana jest baza Oracle. Jeśli wyłączyliśmy bazę z SQL*Plusa, to nie ma potrzeby ponownego logowania do bazy. Włączamy ją poleceniem STARTUP. Teraz opcja audytu jest już włączoną. Możemy się upewnić wywołując komendę: SELECT * FROM V$PARAMETER WHERE NAME LIKE %audit_trail ; 72/108

73 Śledzenie użytkownika Po włączeniu opcji audytu możemy włączyć opcję śledzenia konkretnego użytkownika. Opcja AUDIT ALL dla użytkownika powoduje obserwację jego działań takich jak tworzenie linków bazodanowych, synonimów, tabel słowem operacji DDL. AUDIT ALL BY UZYTKOWNIK; Możemy wybrać tylko niektóre działania użytkownika, które chcemy monitorować. Do tego celu używamy komendy: AUDIT SELECT table, insert table, delete table, update table BY uzytkownik BY ACCESS; 73/108

74 Opcja BY ACCESS powoduje zachowanie informacji o działaniu użytkownika nawet jeśli już w ramach danej sesji wykonał instrukcję tego samego typu (np. więcej niż 1 raz wykonał SELECT na jakiejś tabeli). Przeciwieństwem dla tej opcji jest BY SESSION, ale wtedy dany tym działania jest rejestrowany tylko raz. Aby rozpocząć śledzenie danego użytkownika wymagane jest aby wylogował się (możemy również wymusić jego rozłączenie) i ponownie zalogował do bazy. Aby przejrzeć wyniki śledzenia należy zalogować się do użytkownika SYS. Następnie wybrać tabelę DBA_AUDIT_TRAIL. Zadając do niej odpowiednie zapytanie, jesteśmy w stanie prześledzić działalność konkretnego użytkownika. SELECT username, extended_timestamp, owner, obj_name, action_name FROM dba_audit_trail WHERE USERNAME LIKE 'PRZYKLADOWY' and owner not like 'SYS' ORDER BY timestamp; Warunek AND OWNER NOT LIKE 'SYS' wprowadzamy aby nie wyświetlać zmian w tabelach systemowych, które wykonują się w związku z działalnością użytkownika SYS. Warunek ORDER BY timestamp wyświetla wydarzenia według czasu ich wystąpienia. 74/108

75 Możemy też wyświetlić informacje na temat działań związanych z obiektami których właścicielem (twórcą) jest wybrany użytkownik: SELECT username, extended_timestamp, owner, obj_name, action_name FROM dba_audit_trail WHERE owner LIKE 'PRZYKLADOWY' ORDER BY timestamp; Wyświetlone zostało tylko kilka kolumn, bo tylko te nas w danym momencie interesują. W kolumnie USERNAME jest informacja kto wykonał dane działanie, w kolumnie OWNER na czyim obiekcie (tutaj akurat nasz user zmieniał dane we własnym obiekcie). OBJ_NAME zawiera informacje o nazwie obiektu na którym zostały wykonane działania a ACTION_NAME trzyma info o tym jaki typ działań został przez usera wykonany. 75/108

76 Śledzenie działań na obiekcie W tym punkcie będziemy śledzić kto zmienia zawartość konkretnego obiektu, niezależnie od tego który to użytkownik. Z poziomu SYSa należy wykonać: AUDIT DELETE, INSERT, UPDATE ON nazwa_uzytkownika.nazwa_tabeli BY ACCESS; Polecenie to włączy obserwację tabeli produkty w schemacie użytkownika uzytkownik. Obserwowane będzie jedynie kasowanie, uzupełnianie oraz zmiana danych w tej tabeli. Możesz oczywiście wymienić takie aktywności, które nas interesują (np. select). 76/108

77 Należy zmodyfikować nasze wcześniejsze zapytanie. W tym przypadku zmieniamy warunek WHERE. Wyświetlamy informacje o działaniach tylko te, które mają w nazwie obiektu PRODUKTY a więc nazwę tabeli, która nas interesuje. Dla wszelkiej pewności możemy dodać jeszcze warunek dla kolumny OWNER, by mieć pewność, że chodzi o tabelę konkretnego użytkownika. Tabela o takiej samej nazwie może występować przecież w kilku schematach. SELECT username, extended_timestamp, owner, obj_name, action_name FROM dba_audit_trail WHERE obj_name LIKE 'PRODUKTY' ORDER BY timestamp; 77/108

78 Wyłączenie opcji AUDIT Opcja monitoringu AUDIT dodaje wiersze do tabeli w której zapisuje informacje o działaniach obserwowanych użytkowników, lub działaniach na obserwowanych tabelach. W momencie gdy na obserwowanych tabelach, lub przez obserwowanych użytkowników wykonywana jest duża ilość operacji, tabela zaczyna zajmować coraz więcej miejsca. Wynikiem tego może być szybkie zapełnienie powierzchni na dysku przeznaczonej na bazę danych. Po wykonaniu interesujących nas czynności audytowych, opcję tę należy wyłączyć. Aby to zrobić wywołujemy polecenie analogiczne do tego, które włącza opcję AUDIT z tym wyjątkiem, że zastępujemy słowo TRUE, słowem FALSE: ALTER SYSTEM SET AUDIT_TRAIL=FALSE SCOPE=SPFILE; 78/108

79 Ćwiczenia 1. Włącz audit tak, by obserwować wszystkie operacje na danych i obiektach użytkownika HR. 2. Stwórz nowego użytkownika, nadaj mu takie uprawnienia by mógł wykonywać INSERT, DELETE, UPDATE, SELECT na tabeli employees w schemacie użytkownika HR. 3. Poproś osobę obok, by zalogowała się na nowo stworzonego użytkownika i wykonała kilka operacji na tabeli employees. Określ jakich komend SQL użyła. 4. Napisz komendę SQL, która wyświetli wszystkie adresy ip/nazwy hostów z których kiedykolwiek logował się użytkownik HR. 79/108

80 Rozłączanie sesji użytkowników Jako administrator mamy możliwość rozłączenia użytkownika na kilka sposobów. Jedne są bardziej grzeczne, Inne trochę mniej: Aby rozłączyć użytkownika potrzebujemy 2 wartości, które uzyskamy wywołując polecenie: SELECT SID,SERIAL# FROM v$session WHERE USERNAME='nazwa_uzytkownika'; Znając te wartości jesteśmy w stanie rozłączyć użytkownika. Oto różne sposoby: ALTER SYSTEM KILL SESSION 'sid,serial#'; w naszym przypadku w miejsce sid i serial# wprowadzamy wartości 37 oraz 14. Spowoduje natychmiastowe rozłączenie sesji użytkownika wyświetlając mu informację, że jego sesja została przerwana przez administratora ( your session has been killed ). Wszystkie wprowadzone przez niego, niezapisane działania, których nie zatwierdził, zostaną automatycznie cofnięte (ROLLBACK). ALTER SYSTEM DISCONNECT SESSION '37,14' IMMEDIATE; - spowoduje rozłączenie sesji użytkownika. Przy próbie wykonania działania wyświetlony zostanie monit o utraceniu połączenia z bazą. Wszystkie niewprowadzone zmiany zostają automatycznie cofnięte (ROLLBACK). ALTER SYSTEM DISCONNECT '37,14' POST_TRANSACTION; - spowoduje rozłączenie użytkownika po zatwierdzeniu przez niego zmian (COMMIT) lub cofnięciu ich (ROLLBACK). Jeśli użytkownik nie ma żadnych niezatwierdzonych działań w transakcji (np. wykonywał tylko SELECTy) jego sesja zostanie natychmiast zerwana. 80/108

81 Ćwiczenia 1. Nawiąż 3 sesje jako użytkownik HR, a następnie rozłącz je trzema znanymi Ci metodami. 2. Sprawdź czy można zerwać sesję SYSa. 81/108

82 Włączanie i wyłączanie instancji Tryby uruchomieniowe instancji Istnieje kilka sposobów włączania instancji: STARTUP lub STARTUP OPEN włącza bazę danych do pełnowartościowego trybu. STARTUP NOMOUNT umożliwia włączenie bazy do poziomu załadowania m.in. SPFILE, czy SGA. W tym trybie przywracamy plik kontrolny (CONTROLFILE) oraz duplifikujemy bazę danych (docelowa musi być w trybie nomount). STARTUP MOUNT umożliwia włączenie bazy do poziomu załadowania m.in. plików danych, plików dzienników powtórzeń, czy pliku kontrolnego. W tym trybie mamy możliwość przywrócenia bazy danych z backupu. ALTER DATBASE MOUNT komenda do wprowadzenia bazy danych do trybu MOUNT z trybu 82/108

83 NOMOUNT (pamiętajmy, że nie możemy otworzyć bazy bezpośrednio z trybu NOMOUNT). ALTER DATABASE OPEN służy do otworzenia bazy z trybu MOUNT (jeśli mamy tryb NOMOUNT komenda ta nie zadziała, musimy najpierw przejść do trybu MOUNT). Wyłączanie bazy ORACLE Jako administrator bazy danych mamy możliwość wyłączenia instancji na kilka sposobów: SHUTDOWN IMMEDIATE - przerywa wszystkie aktywne sesje, po czym wycofuje wszystkie niezapisane transakcje. SHUTDOWN NORMAL - powoduje zamknięcie bazy danych po zakończeniu wszystkich sesji użytkowników. SHUTDOWN TRANSACTIONAL powoduje zamknięcie bazy danych, po zakończeniu wszystkich aktywnych transakcji, nie pozwalając przy tym na zalogowanie do bazy nowych użytkowników. SHUTDOWN ABORT powoduje natychmiastowe zamknięcie bazy danych (stosujemy ją tylko wtedy, gdy nie możemy zamknąć bazy używając SHUTDOWN IMMEDIATE, a musimy ją zamknąć natychmiast, na przykład w przypadku jakiejś awarii). 83/108

84 Ćwiczenia 1. Wyłącz instancję. 2. Uruchom instancję w trybie nomount. 3. Otwórz instancję. 4. Uruchom instancję w trybie mount. 84/108

85 RMAN - Kopie zapasowe w Oracle Podstawowe informacje i wstępna konfiguracja Backupy możemy wykonywać na dwa sposoby: - wyłączając bazę i kopiując fizyczne pliki (tzw. zimny backup) - wykorzystując RMANa i zrobić backup bez wyłączania bazy (hot backup) Aby wykonać hot backup należy ustawić bazę w tryb ARCHIVELOG. Po tym zabiegu pliki dzienników powtórzeń przed nadpisaniem zostaną zarchiwizowane. Dzięki temu mamy pewność że nie zostaną wyczyszczone w trakcie backupu. Wykonujemy to w następujący sposób: - Logujemy się SQL*Plusem jako SYS do bazy. - Robimy SHUTDOWN IMMEDIATE; (tylko ten jeden raz jest to konieczne). - Uruchamiamy bazę w trybie MOUNT (poleceniem STARTUP MOUNT). - Wywołujemy polecenie ALTER DATABASE ARCHIVELOG; - otwieramy bazę dla użytkowników poleceniem ALTER DATABASE OPEN; Ten krok można pominąć ale ta konfiguracja pozwoli nam na wybór innego niż domyślne miejsce składowania plików backupu. Oracle zawiera w sobie Flash Recovery Area. To przestrzeń zawierająca backupy, służąca do ich przywracania. Jest ona zarządzana przez silnik bazy danych, a nie system operacyjny. W niej właśnie będą składowane nasze backupy. Sprawdzamy aktualne położenie FRA: SELECT * FROM v$recovery_file_dest; Jeśli chcemy zmienić dostępną dla FRA przestrzeń dyskową stosujemy komendę: ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 100G; Parametr ten ustawia ile miejsca na dysku mogą maksymalnie zajmować backupy oraz archivelogi. 85/108

86 ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='c:\FRA'; Parametr ten ustawia gdzie na dysku mają znajdować się backupy. Po ustaleniu w/w parametrów, warto sprawdzić, czy wszystko zostało przez nas poprawnie ustawione. Wybieramy więc komendy: SELECT * FROM v$parameter WHERE NAME='db_recovery_file_dest'; SELECT * FROM v$parameter WHERE NAME='db_recovery_file_dest_size'; Włączamy konsolę command line a następnie wpisujemy RMAN. Podłączenie do bazy Przede wszystkim po włączeniu RMANa, musimy podłączyć się do bazy danych. Robi się to wpisując komendę: CONNECT TARGET lub CONNECT TARGET / lub CONNECT TARGET nazwabazy 86/108

87 87/108

88 Pełny backup W celu wykonania pełnego backupu bazy danych wywołujemy komendę: BACKUP DATABASE; Jako że to jest pełny backup, trwa on dosyć długo. Należy cierpliwie poczekać na pojawienie się komunikatu RMANa. Nasz backup pojawi się w zdefiniowanym przez nas Flash Recovery Area. Jeśli chcemy by nasz backup znalazł się w innym niż domyślne miejscu wpisujemy komendę: BACKUP DATABASE FORMAT 'c:\rman\calabaza%u.bck'; Tag %u to unikalny numer generowany m.in. na podstawie daty i godziny utworzenia, dzięki czemu każdy plik kopii zapasowej będzie miał unikalny numer. Formatów tych jest kilka i można je wplatać w nazwę pliku. Przedstawiam te podstawowe: %s numer backupu %d nazwa bazy danych %D dzień %M miesiąc %Y rok %u wartość unikalna wyliczona na podstawie wszystkich w.w opcji Taki backup obejmuje dane oraz plik kontrolny. Jeśli chcemy wykonać backup razem z plikami zarchiwizowanymi dziennika powtórzeń, to wywołujemy komendę: BACKUP DATABASE PLUS ARCHIVELOG; 88/108

89 Backup skompresowany Pliki backupów zajmują sporo miejsca. Warto więc by były kompresowane. Jest możliwość kompresowania przy użyciu RMANa. RMAN stosuje algorytm podobny do tego używanego przez program archiwizujący ZIP. Zamiast BACKUP DATABASE; wpisujemy: BACKUP AS COMPRESSED BACKUPSET DATABASE FORMAT 'c:\fra\full_compressed%u'; lub przykładowo z plikami (zarchiwizowanymi) dziennika powtórzeń: BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG FORMAT 'c:\fra\full_compressed%u'; Taką kompresję można stosować też przy backupach tablespace'ów oraz backupach przyrostowych i kumulatywnych. Co prawda kopia zapasowa jeśli jest kompresowana wykonywana jest dużo dłużej, ale zajmuje w efekcie mniej miejsca. 89/108

90 Backup przyrostowy i kumulatywny Nie zawsze musimy chcieć wykonywać pełną kopię zapasową. Z resztą po co nam za każdym razem całość jeśli można pełny backup zrobić raz, a później wykorzystywać zajmujące znacznie mniej miejsca kopie przyrostowe. Definicje: Kopia pełna - czyli kopia wszystkich plików danych oraz pliku kontrolnego Kopia przyrostowa - czyli kopia tylko tych bloków danych które uległy zmianie od ostatniego pełnego lub przyrostowego backupu. Kopia kumulatywna - kopia wszystkich bloków danych które uległy zmianie od ostatniego pełnego (!!! już nie ostatniego przyrostowego) backupu. Backup przyrostowy Od wersji 10g Oracle obsługuje dwa poziomy kopii przyrostowej 0 i 1. Kopia przyrostowa poziomu 0 fizycznie nie różni się niczym od pełnego backupu, z tą różnicą że na jej podstawie możemy wykonywać normalne kopie przyrostowe (poziom 1). Tak więc przynajmniej raz musimy wykonać komendę: BACKUP INCREMENTAL LEVEL 0 DATABASE FORMAT 'c:\fra\przyrostowa_0_%u'; aby następnie móc wykonywać : BACKUP INCREMENTAL LEVEL 1 DATABASE FORMAT 'c:\fra\przyrostowa_1_%u'; Komenda z level 1, jest to już normalna kopia przyrostowa. 90/108

91 Backup kumulatywny Aby wykonać backup kumulatywny wywołujemy komendę: BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE; Warto dość często wykonywać kopie przyrostowe, a raz na jakiś czas (np. tydzień) kopię kumulatywną. Dzięki temu będziemy mogli później pozbyć się kopii przyrostowych, a co za tym idzie, mieć mniejszą ilość plików do przechowywania. Ten tag możemy łączyć z innymi poznanymi wcześniej, np.: BACKUP INCREMENTAL LEVEL 1 FORMAT 'c:\fra\inc_comp%u' AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG; Szybki backup przyrostowy Normalnie backup przyrostowy realizowany jest tak, że ostatni backup z danymi porównywany jest blok po bloku. Zamiast tego, można zrobić tak by Oracle tworzyło sobie listę zmienionych bloków. W takim wypadku backup przebiegał będzie znacznie szybciej. Niestety ta opcja jest dostępna tylko w wersjach Standard i Enterprise. Najpierw sprawdźmy czy już ta opcja nie jest włączona: SELECT * FROM v$parameter WHERE NAME='db_create_file_dest'; Jeśli pole value będziemy mieli puste, to znaczy że nie było to wcześniej ustawiane. Tworzymy katalog w którym taka lista będzie przechowywana, a następnie wpisujemy: ALTER SYSTEM SET db_create_file_dest='c:\fra\fib'; oraz włączamy tą opcję: ALTER DATABASE ENABLE BLOCK CHANGE TRACKING; 91/108

92 Backup tablespace'ów RMANem możemy wykonywać również backupy tablespace'ów, plików danych, pliku parametrów, pliku kontrolnego. Najpierw sprawdźmy jakie mamy tablespace'y: SELECT * FROM DBA_TABLESPACES; Komenda do backupu wybranego tablespace'a: BACKUP TABLESPACE USERS FORMAT 'c:\fra\users%u'; Klauzula format jest oczywiście nieobowiązkowa. Możemy też chcieć zapisać kilka tablespace'ów, wtedy rozdzielamy ich nazwy przecinkami: BACKUP TABLESPACE USERS, SYSTEM FORMAT 'c:\fra\users_system%u'; albo zechcieć je dodatkowo skompresować: BACKUP AS COMPRESSED BACKUPSTE TABLESPACE USERS FORMAT 'c:\fra\users_compressed%u'; lub zrobić nie dość że skompresowaną to jeszcze przyrostową (oszczędzamy miejsce - dyski kiedyś się kończą).: BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1 FORMAT 'c:\fra\users_comp_przyr%u' TABLESPACE USERS; 92/108

93 Backup pliku parametrów Komenda (format jest opcjonalny): BACKUP SPFILE FORMAT 'c:\fra\spfile%u'; Backup pliku kontrolnego Warto abyśmy wykonywali osobną kopię pliku kontrolnego. Dlaczego? Ponieważ informacje o backupach przechowywane są właśnie w nim. Co prawda w pełnych backupach jest też kopia pliku kontrolnego, ale nie będziemy w stanie przywrócić backupu, jeśli plik kontrolny ulegnie uszkodzeniu. W takim przypadku dużo łatwiej odzyskać najpierw plik kontrolny a później resztę. Aby wykonać taki backup wpisujemy: BACKUP CURRENT CONTROLFILE FORMAT 'c:\fra\controlfile%u'; Taką kopię pliku kontrolnego (zwłaszcza że nie zajmuje wiele miejsca) warto mieć jak najświeższą. Dbanie o to by tak było możemy zlecić silnikowi bazy: CONFIGURE CONTROLFILE AUTOBACKUP ON; Od tej pory jeśli nastąpi jakakolwiek zmiana wpływająca na plik kontrolny, ten zostanie automatycznie zbackupowany po zmianach. Możemy teraz chcieć by RMAN backupował nam plik kontrolny w inne miejsce niż domyślne. Wywołujemy komendę: CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'd:\fra\plikkontrolny%u'; 93/108

94 Kopia zapasowa plików zarchiwizowanych dziennika powtórzeń SELECT * FROM v$datafile; BACKUP AS COPY DATAFILE 'c:\app\administrator\oradata\orcl\users01.dbf' FORMAT 'c:\fra\users.dbf'; Komenda ta kopiuje wszystkie bloki, zajęte oraz puste. Jeśli więc będziemy mięli określony tablespace o wyznaczonej z góry sporej wielkości, backup zajmie niepotrzebnie bardzo dużo miejsca. 94/108

95 Odtwarzanie przy użyciu RMAN Aby rozpocząć przywracanie interesujących nas rzeczy z backupu, włączamy konsolę command line a następnie wpisujemy RMAN. Przede wszystkim po włączeniu RMANa, musimy podłączyć się do bazy danych (tak jak w przypadku tworzenia plików backupu). Wpisujemy zatem komendę: CONNECT TARGET lub CONNECT TARGET / lub CONNECT TARGET nazwabazy Możemy przywrócić teraz to, co wcześniej zbackupowaliśmy (bazę, tablespace'y, plik kontrolny, czy pliki zarchiwizowanych dzienników powtórzeń). Przywracanie bazy z pełnego backupu Zaczniemy od przywrócenia pełnej bazy z naszego backupu. Aby to zrobić musimy najpierw wyłączyć bazę, a następnie włączyć ją w tryb mount (możemy to zrobić wprowadzając listę komend): RUN{ SHUTDOWN IMMEDIATE; STARTUP MOUNT; RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN; } RMAN sam sprawdzi który backup jest tym ostatnim, bez względu na to, czy robiliśmy pełny backup, inkrementalny, czy też kumulatywny. Również sam załaduje odpowiedni controlfile i archivelogi. 95/108

96 Przywracanie bazy do określonego punktu w czasie Możemy przywrócić bazę do określonego punktu w czasie, w tym celu wyłączamy, a następnie uruchamiamy bazę do trybu mount: SHUTDOWN IMMEDIATE; STARTUP MOUNT; Podajemy do którego momentu chcemy przywrócić bazę: run{ set until time to_timestamp('12:00: ','hh24-mi-ss dd-mm-yyyy') ; restore database; recover database; } Następnie uruchamiamy bazę, resetując archivelogi: ALTER DATABASE OPEN RESETLOGS; 96/108

97 Walidacja bazy i backupów W celu sprawdzenia poprawności plików bazy danych wywołujemy komendę: BACKUP VALIDATE DATABASE; możemy również wykonać walidacje dla bazy, wraz z archivelogami: BACKUP VALIDATE DATABASE PLUS ARCHIVELOG; Co ważne, podając tę komendę nie wykonujemy backupu! Aby sprawdzić poprawność ostatnio wykonanego backupu wprowadzamy: RESTORE DATABASE VALIDATE; aby sprawdzić poprawność pliku backupu wraz z archivelogami: RESTORE ARCHIVELOG ALL VALIDATE; 97/108

98 Zarządzanie backupami Chcąc sprawdzić nasze backupy możemy je wylistować wpisując komendę: LIST BACKUP; 98/108

99 Warto czasem sprawdzić, czy pliki do których odnosi się backup wciąż są obecne na dysku. Aby to zrobić wywołujemy: CROSSCHECK BACKUP; Jeśli powyższe zapytanie wykaże nam błąd (różne od found to be 'AVALIABLE'), możemy wtedy usunąć niepotrzebne pliki backupu używając komendy: DELETE EXPIRED BACKUP; Możemy również wykasować nieaktualne, niepotrzebne już backupy np. przestarzałe: DELETE OBSOLETE; Aby ustawić politykę backupów, tzn. kiedy pliki backupów będą uważane przez RMANa za przestarzałe musimy zmodyfikować parametr RETENTION POLICY. Mamy możliwość ustawienia ilości backupów, które mają być uważane za aktualne, bądź czas, podawany w dniach. Ustawienie dla ilości dni przez jakie backupy będą uważane za ważne ustawiamy poleceniem: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS; Powyższym poleceniem ustawimy, iż RMAN będzie uważał za przestarzałe pliki backupów stworzone później niż 3 dni wstecz. Ustawienie dla ilości przetrzymywanych backupów ustawiamy wywołując polecenie: CONFIGURE RETENTION POLICY TO REDUNDANCY 3; Tym poleceniem ustawiamy, iż RMAN będzie uważał za aktualne 3 ostatnie pliki backupów. Po wylistowaniu backupów (LIST BACKUP) zobaczymy jaki numer odpowiada konkretnemu plikowi backupu. Znając ten numer, możemy usunąć konkretny backup posługując się właśnie tym numerem: DELETE BACKUPSET 69; 99/108

100 Przywracanie tablespaceów Aby odtworzyć tablespace musimy odłączyć go od bazy przy pomocy komendy OFFLINE. W tym wypadku również możemy posłużyć listą komend: RUN{ SQL 'ALTER TABLESPACE USERS OFFLINE'; RESTORE TABLESPACE USER; RECOVER TABLESPACE USERS; SQL 'ALTER TABLESPACE USERS ONLINE'; } Przywracamy tablespace systemowy Tutaj również możemy posłużyć się listą komend. Jako, że jest to tablespace systemowy, jesteśmy zmuszeni zamknąć bazę danych i wprowadzić ją w tryb MOUNT: RUN{ SHUTDOWN IMMEDIATE; STARTUP MOUNT; RESTORE TABLESPACE SYSTEM, SYSAUX; RECOVER TABLESPACE SYSTEM, SYSAUX; ALTER DATABASE OPEN; } 100/108

101 Przywracanie pliku kontrolnego Plik kontrolny przywracamy dodając na końcu komend dodatek RESETLOGS: RUN{ SHUTDOWN IMMEDIATE; STARTUP NOMOUNT; RESTORE CONTROLFILE FROM AUTOBACKUP ; ALTER DATABASE MOUNT; RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; } 101/108

102 Ćwiczenia 1. Wykonaj backup pełny skompresowany z archivelogami który może być podstawą do backupów przyrostowych. 2. Wykonaj dwa backupy przyrostowe i jeden kumulatywny wszystkie skompresowane wraz z archivelogami. 3. Pozbądź się niepotrzebnych backupów. 4. Odtwórz tablespace SYSTEM. 5. Odtwórz całą bazę danych do aktualnego momentu. 6. Odtwórz bazę danych do stanu sprzed 3 godzin. 7. Poproś trenera o uszkodzenie bazy danych. Sprawdź jakiego rodzaju jest to uszkodzenie i przywróć instancję do działania. 102/108

103 Export i import danych Oracle mamy dwa programy do tego celu EXP do eksportowania danych, oraz IMP do ich importowania. Przy ich użyciu możemy eksportować i importować : - całą bazę - wybrany schemat - wybrane tabele Eksport całej bazy danych Kod: EXP USERID=system/tajne_haslo FILE='c:\kopia_bazy\calosc.dat' LOG='c:\kopia_bazy\calosc.log' FULL=Y To, co następuje po userid to nazwa użytkownika łamana przez hasło. W tym wypadku musimy to zrobić jako system, ponieważ jako zwykły użytkownik nie mamy dostępu do całej bazy (a całą chcemy eksportować). Po file podajemy nazwę pliku do którego zostanie wrzucona zawartość bazy. Plik stworzy się sam, ale struktura katalogów musi zostać przez nas uprzednio stworzona. Po log podajemy plik do którego mają być zrzucane logi. Podawanie tego nie jest obowiązkowe. Opcja Full=y nakazuje eksport całej bazy. Jeśli jej nie podamy, musimy wyeksportować schemat, albo tabelę, ale i tak musimy określić które. Eksport całego schematu Kod: EXP USERID=hr/hr FILE='c:\kopia_bazy\schemat.dat' LOG='c:\kopia_bazy\schemat.log' OWNER=HR Parametry userid, file, log oznaczą to samo co poprzednio. Eksportujemy jako user hr swój własny schemat. Oczywiście możemy eksportować również schematy innych userów, ale musimy do tego być zalogowany jako user system (albo user który jest ownerem schematu). Poza tym zamiast "full=y" pojawiło się "owner=hr", co oznacza że wyeksportowany ma zostać cały schemat usera hr. Możemy zrobić również eksport schematu na innym komputerze. Dodajemy w userid: EXP USERID@adres_ip=hr/hr FILE='c:\kopia_bazy\schemat.dat' LOG='c:\kopia_bazy\schemat.log' OWNER=HR 103/108

104 Eksport wybranych tabel Możemy chcieć też zrobić sobie kopię zapasową tylko kilku tabel. Do tego celu w miejsce wcześniejszego full=y czy owner=hr wpisujemy np. tables=employees, departments : EXP USERID=hr/hr FILE='c:\kopia_bazy\schemat.dat' LOG='c:\kopia_bazy\schemat.log' TABLES=employees, departments Import danych Kiedy wykonamy eksport bazy mamy możliwość przywrócenia jej z powrotem, lub przeniesienia/skopiowania jej na inny serwer. Do tego użyjemy programu IMP. Import całej bazy Kod: IMP USERID=system/tajne_haslo FILE='c:\kopia_bazy\calosc.dat' LOG='c:\kopia_bazy\calosc.log' FULL=Y DESTROY=Y Parametr userid - oznacza to samo co w exp, kiedy importujemy całość bazy musimy być zalogowani jako user system. File to plik z wcześniejszego eksportu danych, log tak jak wcześniej. Full=y ponieważ importujemy całość, destroy=y oznacza, że jeśli istnieje już obiekt w bazie o takiej nazwie to zostanie skasowany i nadpisany. Jeśli tego nie dodamy, to w takiej sytuacji będziemy dostawali zapytanie czy chcemy wprowadzić zmiany (możemy zamiast tego dodać ignore=y, wtedy nie będzie nadpisywał i kasował zmian). 104/108

105 Import schematu Importować możemy zawartość schematu nie tylko z powrotem do schematu usera z którego zostały dane wyciągnięte, ale też możemy je wstawić innemu userowi. Dlatego przy imporcie nie ma już 'owner=hr', ale za to jest 'touser=hr' określający do schematu jakiego usera mają dane zostać wrzucone, oraz 'fromuser=hr' czyli schemat jakiego usera może być wciągnięty (bo jeżeli importujemy jakiś schemat z eksportu całej bazy, mamy tam bardzo wiele schematów i musimy któryś wybrać). IMP USERID=hr/hr FILE='c:\kopia_bazy\schemat.dat' fromuser=hr touser=hr destroy=y Możemy tutaj też dodać LOG='c:\kopia_bazy\schemat.log' jak przy eksporcie, ale nie jest to konieczne. Import poszczególnych tabel Podobnie jak przy imporcie schematu wprowadzamy fromuser i touser - w tym względzie działa to tak samo. Wybieramy też tabele które chcemy zaimportować. Kod: IMP USERID=hr/hr FILE='c:\kopia_bazy\tabele.dat' FROMUSER=hr TOUSER=hr TABLES=EMPLOYEES!! Musimy uważać z importem, bo Oracle nadpisuje tabele importowane bez żadnej informacji. 105/108

106 Ćwiczenia 1. Stwórz nowego użytkownika 2. Poproś kolegę by zaimportował do jego schematu wszystkie tabele użytkownika hr ze swojej bazy danych 106/108

107 Oracle Net Mechanizm Oracle Net umożliwia nam rozłożenie obciążenia związanego z aplikacjami bazodanowymi. Odpowiada za komunikację między klientem, a serwerem. Dzięki Oracle Net możliwa jest również konfiguracja serwer-serwer, gdzie każdy serwer obsługuje aplikację klienta, a także dysponuje możliwością połączenia się z innymi serwerami sieciowymi. Deskryptory połączeń Nazwy serwera i instancji są identyfikowane przy pomocy deskryptora połączeń. Określa on sposób komunikowania, nazwę serwera i nazwę usługi instancji używaną w czasie przetwarzania zapytania. Ogólny format deskryptora wygląda w następujący sposób: (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=HQ (PORT=1521)) (CONNECT DATA= SERVICE_NAME=XE))) W tym deskryptorze zastosowaliśmy protokół TCP/IP, serwer o nazwie HQ i jego port 1521 (zarejestrowany numer używany przez Oracle dla mechanizmu Oracle Net), który powinien obsługiwać połączenie, a także zdefiniowaliśmy połączenie z instancją XE serwera HQ. Nazwy usług sieciowych Aby użytkownicy nie musieli wprowadzać deskryptora połączeń każdorazowo, możemy zdefiniować nazwy usług (lub aliasy), które odwołują się do deskryptorów. Nazwy usług znajdują się w pliku TNSNAMES.ORA. Ten plik powinien znajdować się na każdym serwerze bazodanowym, który jest w sieci (każdy klient i serwer powinien mieć kopię tego pliku). 107/108