Zarządzanie obiektami bazy danych Oracle11g

Zarządzanie obiektami bazy danych Oracle11g Wstęp Obiekty to struktury przechowujące, porządkujące lub operujące na danych takie jak: Tabele Więzy integralności Indeksy Widoki Sekwencje Procedury Linki bazodanowe itp. Do operowania na obiektach służą polecenia DDL (Data Definiotion Language), a do operacji na danych DML (Data Manipulation Language) do których należą między innymi polecenia Insert, Update, Delete, Merge. Tabele Tabele to podstawowe obiekty w bazie danych przechowujące dane w kolumach i wierszach. Do tworzenia tabel służy polecenie CREATE TABLE. W poleceniu tworzącym tabele można od razu zdefiniować: więzy integralności wskazać przestrzeń tabel stworzyć tabele na podstawie zapytania SQL tabele tymczasową Strona: 1 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 7

Oto przykłady poleceń tworzących tabele: CREATE TABLE EMPLOYEES ( ID NUMBER(6) PRIMARY KEY, NAME VARCHAR2(50) NOT NULL, PESEL VARCHAR2(11), HIRE_DATE DATE NOT NULL, SALARY NUMBER (6,2), MANAGER_ID NUMBER(6), SEX CHAR(1) ) TABLESPACE USERS; Wraz z więzami integralności takimi jak PRIMARY KEY czy UNIQUE baza danych tworzy powiązane z nimi indeksy unikalne w celu wymuszenia unikalności wartości tych kolumn. Tabele użytkownika można odczytać w perspektywie USER_TABLES. Administrator bazy danych może odczytać tabele innych użytkowników w perspektywie DBA_TABLES. Kolumny tabel można odczytać odpowiednio: dla użytkownika w USER_TAB_COLUMNS, dla administratora perspektywie DBA_TAB_COLUMNS Tabele tymczasowe Tabela tymczasowa daje użytkownikowi możliwość przechowywania danych na czas trwania transakcji lub sesji. Po zakończeniu transakcji lub sesji dane są automatycznie usuwane. Operacje DML wykonywane na tabelach tymczasowych nie generują zmian w redo logach ponieważ nie ma potrzeby odtwarzania danych po ewentualnej awarii systemu. Zmiany na danych w tabelach tymczasowych nie generują również zmian w segmentach UNDO ponieważ nie ma potrzeby przywracania starych wartości w przypadku wycofania transakcji. Tak więc operacje DML na tabelach tymczasowych są szybsze niż w przypadku normalnych tabel. Tabele tymczasowe są często używane w procedurach PL/SQL do gromadzenia i wykonywania przetwarzania danych. Tabele tymczasowe tworzone są zawsze w tymczasowej przestrzeni tabel. Tabele tymczasowe tworzy się poleceniem: CREATE GLOBAL TEMPORARY TABLE TEMP_TABLE ( ID NUMBER(6) NAME VARCHAR2(200) ) ON COMMIT PRESERVE ROWS; Strona: 2 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 7

Więzy integralności Więzy integralności to mechanizmy służące zapewnieniu spójności danych. Należą do nich: PRIMARY KEY klucz główny UNIQUE - unikalność FOREIGN KEY klucz obcy NOT NULL zawsze jakoś wartość CHECK sprawdzanie warunków Więzy integralności mogą być zakładane wraz z poleceniem tworzenia tabeli lub później za pomocą polecenia ALTER TABLE ADD CONSTRAINT. ALTER TABLE EMPLOYEES ADD CONSTRAINT MGR_FK FOREIGN KEY (MANAGER_ID) REFERENCES EMPLOYEES(ID); Więzy integralności NOT NULL realizowane są w bazie danych Oracle jako więzy typu CHECK np: ALTER TABLE EMPLOYEES ADD CONSTRAINT NAME_NOT_NULL CHECK (NAME IS NOT NULL); Więzy integralności mogą być sprawdzane natychmiast (IMMEDIATE) po wykonaniu polecenia DML lub sprawdzenie może zostać opóźnione (DEFERRED) do momentu zatwierdzania transakcji. ALTER TABLE EMPLOYEES ADD CONSTRAINT EMP_CHECK_SAL CHECK (SALARY>0) INITIALLY DEFERRED DEFERRABLE; ALTER TABLE EMPLOYEES ADD CONSTRAINT EMP_UNQ_PESEL UNIQUE (PESEL); Domyślnym trybem zakładania więzów integralności jest sprawdzanie natychmiastowe więc w przykładzie powyżej EMP_UNQ_PESEL będzie sprawdzany natychmiast po wykonaniu polecenia DML, a EMP_CHECK_SAL dopiero w momencie zatwierdzania transakcji. Tryb pracy więzów integralności można zmienić poleceniem ALTER TABLE MODIFY CONSTRAINIT np: alter table employees modify constraint emp_check_sal initially immediate; Dodatkowo, więzy integralności mogą być w jednym z czterech stanów: DISABLE NOVALIDATE tryb sprawdzania jest wyłączony czyli ani istniejące dane w tabeli ani nowe nie są sprawdzane. DISABLE VALIDATE istniejące dane w tabeli zostają sprawdzone, ale nowe dane nie są przyjmowane. W tym trybie nie da się wykonywać operacji DML na tabeli ENABLE NOVALIDATE istniejące dane w tabeli nie są sprawdzane, ale nowe przychodzące tak. ENABLE VALIDATE domyślny stan pracy kiedy zarówno istniejące jak i nowe dane są sprawdzane. Strona: 3 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 7

Zmiany stanu pracy dokonuje się również poleceniem ALTER TABLE MODIFY CONSTRAINT np: ALTER TABLE EMPLOYEES MODIFY CONSTRAINT EMP_UNQ_PESEL DISABLE NOVALIDATE; ALTER TABLE EMPLOYEES MODIFY CONSTRAINT EMP_UNQ_PESEL DISABLE VALIDATE; ALTER TABLE EMPLOYEES MODIFY CONSTRAINT EMP_UNQ_PESEL ENABLE NOVALIDATE; ALTER TABLE EMPLOYEES MODIFY CONSTRAINT EMP_UNQ_PESEL ENABLE VALIDATE; Transakcje W bazie Oracle nie ma specjalnych instrukcji sterujących, które rozpoczynają nową transakcję. Każde polecenie DML czyli Insert, Update, Delete lub Merge wykonane po ostatnim poleceniu COMMIT lub ROLLBACK rozpoczyna niejawnie nową transakcję. Transakcja to atomowy zestaw instrukcji DML, które albo wszystkie wykonają się poprawnie i mogą zostać zatwierdzone poleceniem COMMIT, albo w przypadku wystąpienia błędu przy któreś operacji wszystkie pozostałe zostaną wycofane poleceniem ROLLBACK. INSERT INTO EMPLOYEES VALUES (1, JAN, 78060903083, SYSDATE, 5000); INSERT INTO EMPLOYEES VALUES (2, KAROL, 78060903084, SYSDATE, 6000); INSERT INTO EMPLOYEES VALUES (3, TOMASZ, 78060903085, SYSDATE, 3000); COMMIT; Dopóki transakcja nie zostanie zatwierdzona inne sesje nie widzą zmian wprowadzanych przez użytkownika. Dzięki temu zapewniona jest izolacja transakcji między sesjami. Baza danych zapewnia współbieżność operacji to znaczy, że wiele sesji może wykonywać operacje DML na tej samej tabeli pod warunkiem, że nie zmieniają tych samych rekordów. Podczas operacji DML zakładane są blokady na wierszach, które podlegają modyfikacji, a także na samej tabeli, aby podczas trwania transakcji inna sesja nie mogła zmodyfikować struktury tabeli lub jej usunąć. Transakcja 1 Użytkownik 1 Transakcja 2 Użytkownik 2 UPDATE EMPLOYEES SET SALARY = 2000 UPDATE EMPLOYEES SET SALARY = 2000 WHERE ID=100; WHERE ID=100; Operacja zawieszona bo transakcja nr 1 blokuje wiersz o id=100. COMMIT; Operacja UPDATE wykonuje sie dopiero kiedy transakcja nr 1 wykona zatwierdzanie lub wycofanie transakcji czyli COMMIT lub ROLLBACK. Strona: 4 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 7

Inny przykład: Transakcja 1 Użytkownik 1 Transakcja 2 Użytkownik 2 UPDATE EMPLOYEES SET SALARY = 2000 ALTER TABLE EMPLOYYES ADD (COL1 WHERE ID=100; NUMBER); Operacja wstrzymana do momentu zatwierdzenia lub wycofania transakcji 1. COMMIT; Dopiero po wykonaniu operacji COMMIT w transakcji 1 wykona się dodanie kolumny w tabeli EMPLOYEES. Czasami zdarza się, że dwie transakcje będą próbować aktualizować te same rekordy, ale w odwrotnej kolejności i może dojść do zakleszczenia (DEADLOCK). Na przykład: Transakcja 1 Użytkownik 1 Transakcja 2 Użytkownik 2 UPDATE EMPLOYEES SET SALARY = 2000 UPDATE EMPLOYEES SET SALARY = 3000 WHERE ID=100; WHERE ID=200; UPDATE EMPLOYEES SET SALARY = 3000 UPDATE EMPLOYEES SET SALARY = 2000 WHERE ID=200; WHERE ID=100; ORA-00060: DEADLOCK DETECTED WHILE WAITING FOR RESOURCE Zakleszczenia czyli DEADLOCK są wykrywane i rozwiązywane przez samą bazę danych, a więc użytkownik nie musi się tym przejmować. W momencie zablokowania transakcji istniejącą na tabeli blokadą założoną przez inną transakcję, takie oczekiwanie może być bardzo długie bo nie mamy wpływu na operacje wykonywane w innej sesji. Stąd czasami jest potrzeba zabicia blokującej transakcji. Najpierw należy sprawdzić, która sesja blokuje a następnie wykonać polecenie ALTER SYSTEM KILL SESSION np: Transakcja 1 Użytkownik 1 Transakcja 2 Użytkownik 2 Transakcja 3 Użytkownik SYS UPDATE EMPLOYEES SET SALARY = 2000 WHERE ID=100; UPDATE EMPLOYEES SET SALARY = 2000 WHERE ID=100; Operacja wstrzymana do momentu zatwierdzenia lub wycofania transakcji 1. Transakcja przez długi czas nie zatwierdza ani nie wycofuje Użytkownik 2 zgłasza problem administratorowi SYS SELECT SID, SERIAL#, USERNAME FROM V$SESSION WHERE SID IN Strona: 5 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 7

(SELECT BLOCKING_SESSION FROM V$SESSION) Nastąpiło rozłączenie i wycofanie całej transakcji 1. Wstrzymana operacja wykonuje się natychmiast po zabiciu sesji użytkownika 1 SID SERIAL# USERNAME 9 5 MIKE ALTER SYSTEM KILL SESSION 9,5 IMMEDIATE; Ćwiczenia Ćwiczenie nr 1 Tabele i więzy integralności Wszystkie polecenia wykonać w SQLPLUS z zachowaniem nazw obiektów 1. Utworzyć użytkownika HR i nadać mu role CONNECT i RESOURCE 2. Jako użytkownik HR utworzyć tabele EMPLOYEES z następującym zestawem kolumn: a. employee_id NUMBER(6) b. first_name VARCHAR2(20) c. last_name VARCHAR2(25) d. email VARCHAR2(25) e. salary NUMBER(8,2) f. manager_id NUMBER(6) 3. Dodać do tabeli EMPLOYEES następujące więzy integralności: a. Klucz główny na kolumnie employee_id b. Unikalność na kolumnach email oraz c. Klucz obcy odroczony (deferred) na kolumnie manager_id odnoszący się do tej samej tabeli i kolumny employee_id d. NOT NULL na kolumnach first_name i last_name e. CHECK na kolumnie salary z warunkiem salary > 0 4. Dodać do tabeli EMPLOYEES kilka wierszy i sprawdzić jak zachowują się więzy integralności sprawdzane natychmiast (IMMEDIATE) oraz te odroczone (DEFERRED). Które więzy integralności sprawdzane są w trakcie zatwierdzania transakcji, a które zaraz po wykonaniu polecenia DML? Czy w momencie naruszenia któregoś z więzów integralności wycofywane są wszystkie dotychczas dodane wiersze czy tylko ten błędny? 5. Przełączyć klucz obcy na tabeli EMPLOYEES w tryb DISABLE VALIDATE 6. Wprowadzić kilka nowych wierszy do tabeli EMPLOYEES. Czy się udało? Jeśli nie to dlaczego? 7. Przełączyć klucz obcy na tabeli EMPLOYEES w tryb DISABLE NOVALIDATE 8. Wprowadzić kilka nowych wierszy do tabeli EMPLOYEES z błędną wartością kolumny manager_id. Czy sie udało? Strona: 6 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 7

9. Przełączyć klucz obcy na tabeli EMPLOYEES w tryb ENABLE NOVALIDATE 10. Wprowadzić kilka nowych wierszy do tabeli EMPLOYEES z błędną wartością kolumny manager_id. Czy tym razem się udało? 11. Przełączyć klucz obcy na tabeli EMPLOYEES w tryb ENABLE VALIDATE. Czy udało się przełączyć klucz obcy w ten tryb? Jeśli nie to zastanowić się co jest przyczyną i rozwiązać problem. Ćwiczenie 2 Tabele tymczasowe 1. Jako użytkownik HR utworzyć tabelę tymczasową EMPLOYEES_TEMP z taką samą strukturą kolumn jak w tabeli EMPLOYEES z usuwaniem wierszy przy zakończeniu sesji. 2. Załadować wiersze z tabeli EMPLOYEES do tabeli EMPLOYEES_TEMP 3. Sprawdzić czy po zakończeniu transakcji wiersze wciąż są w tabeli tymczasowej 4. W drugim terminalu SQLPLUS zalogować się jako ten sam użytkownik HR i sprawdzić zawartość tabeli EMPLOYEES_TEMP. Dlaczego nie ma żadnych wierszy mimo, że przed chwilą ładowane były z innego terminala? 5. Ćwiczenie 3 Transakcje 1. Otworzyć dwa terminale SQLPLUS i zalogować się jako ten sam użytkownik HR 2. W sesji pierwszej spróbować wykonać UPDATE na jakimś konkretnym wierszu nie zatwierdzając transakcji, a w drugiej spróbować usunąć ten sam wiersz. Wiersze najlepiej identyfikować po kluczu głównym. Co się dzieje w drugiej transakcji, czy usunięcie udało się wykonać od razu? 3. W sesji pierwszej zatwierdzić transakcję czyli operację UPDATE. Co się stało w drugiej sesji? 4. Powtórzyć punkt nr 2 tyle, że w drugiej sesji wykonać operację dodania nowej kolumny do tabeli. Czy dodanie nowej kolumny do tabeli jest blokowane przez UPDATE pojedynczego wiersza? Jeśli tak to dlaczego? 5. Powtórzyć punkt nr 2, z tą jednak różnicą polegającą na otworzeniu trzeciego terminala i podłączenia się do bazy jako SYS. Sprawdzić blokujące transakcje i jako zabić tę sesję która blokuje. Co się stanie w sesji oczekującej? 6. W dwóch sesjach doprowadzić do zakleszczenia (deadlock) transakcji. Czy baza sama umie poradzić sobie z taką sytuacją? Strona: 7 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 7

Rozwiązania Zarządzanie obiektami bazy danych Oracle 11g Ćwiczenie 1 1. Utworzyć użytkownika HR i nadać mu role CONNECT i RESOURCE a. CREATE USER HR IDENTIFIED BY HR; b. GRANT CONNECT, RESOURCE TO HR; 2. Jako użytkownik HR utworzyć tabele EMPLOYEES CREATE TABLE EMPLOYEES ( EMPLOYEE_ID NUMBER(6), FIRST_NAME VARCHAR2(20), LAST_NAME VARCHAR2(25), EMAIL VARCHAR2(25), SALARY NUMBER(8,2), MANAGER_ID NUMBER(6) ) ; 3. Dodać do tabeli EMPLOYEES następujące więzy integralności: a. Klucz główny na kolumnie employee_id i. ALTER TABLE EMPLOYEES ADD CONSTRAINT EMP_PK PRIMARY KEY (EMPLOYEE_ID); b. Unikalność na kolumnach email i. ALTER TABLE EMPLOYEES ADD CONSTRAINT EMP_UNIQUE_EMAIL UNIQUE (EMAIL); c. Klucz obcy odroczony (deferred) na kolumnie manager_id odnoszący się do tej samej tabeli i kolumny employee_id i. ALTER TABLE EMPLOYEES ADD CONSTRAINT EMP_MANAGER_FK FOREIGN KEY (MANAGER_ID) REFERENCES EMPLOYEES (EMPLOYEE_ID) INITIALLY DEFERRED DEFERRABLE; d. NOT NULL na kolumnach first_name i last_name ALTER TABLE EMPLOYEES ADD CONSTRAINT F_NAME_NN CHECK (FIRST_NAME IS NOT NULL); ALTER TABLE EMPLOYEES ADD CONSTRAINT L_NAME_NN CHECK (LAST_NAME IS NOT NULL); e. CHECK na kolumnie salary z warunkiem salary > 0 i. ALTER TABLE EMPLOYEES ADD CONSTRAINT SAL_POSITIVE CHECK (SALARY > 0); 4. Dodać do tabeli EMPLOYEES kilka wierszy i sprawdzić jak zachowują się więzy integralności sprawdzane natychmiast (IMMEDIATE) oraz te odroczone (DEFERRED). Które więzy integralności Strona: 8 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 7

sprawdzane są w trakcie zatwierdzania transakcji, a które zaraz po wykonaniu polecenia DML? Czy w momencie naruszenia któregoś z więzów integralności wycofywane są wszystkie dotychczas dodane wiersze czy tylko ten błędny? a. INSERT INTO EMPLOYEES VALUES( 1000, 'STEVEN 0', 'KING 0', 'SKING0@COMPANY.COM',24000, NULL); b. INSERT INTO EMPLOYEES VALUES( 1000, 'STEVEN 0', 'KING 0', 'SKING0@COMPANY.COM',24000, NULL ); c. INSERT INTO EMPLOYEES VALUES( 1001, 'STEVEN 1', 'KING 1', 'SKING1@COMPANY.COM', 24010, 2000); d. COMMIT; e. Więzy natychmiastowe sa sprawdzane zaraz po wykonaniu polecenia DML. Jeśli wynik jest negatywny tylko ta pojedyncza operacja zostaje wycofana. Pozostałe operacje w transakcji są nadal aktualne. f. Więzy odroczone są sprawdzane dopiero w momencie zatwierdzania transakcji. Jeśli wynik jest negatywny na choć jednym wierszu to cała transakcja jest wycofywana. 5. Przełączyć klucz obcy na tabeli EMPLOYEES w tryb DISABLE VALIDATE a. ALTER TABLE EMPLOYEES MODIFY CONSTRAINT EMP_MANAGER_FK DISABLE VALIDATE; 6. Wprowadzić kilka nowych wierszy do tabeli EMPLOYEES. Czy się udało? Jeśli nie to dlaczego? a. INSERT INTO EMPLOYEES VALUES( 1004, 'STEVEN 4', 'KING 4', 'SKING4@COMPANY.COM',24040, NULL ); b. ORA-25128: WSTAWIANIE/AKTUALIZACJA/USUWANIE W TABELI Z WIĘZAMI (HR.EMP_MANAGER_FK) JEST WYŁĄCZONE I SPRAWDZONE 7. Przełączyć klucz obcy na tabeli EMPLOYEES w tryb DISABLE NOVALIDATE a. ALTER TABLE EMPLOYEES MODIFY CONSTRAINT EMP_MANAGER_FK DISABLE NOVALIDATE; 8. Wprowadzić kilka nowych wierszy do tabeli EMPLOYEES z nieistniejącym identyfikatorem do kolumny manager_id a. INSERT INTO EMPLOYEES VALUES( 1005, 'STEVEN 5', 'KING 5', 'SKING5@COMPANY.COM', 24050, -1); b. INSERT INTO EMPLOYEES VALUES( 1006, 'STEVEN 6', 'KING 6', 'SKING6@COMPANY.COM', 24060, -2); c. COMMIT; 9. Przełączyć klucz obcy na tabeli EMPLOYEES w tryb ENABLE NOVALIDATE a. ALTER TABLE EMPLOYEES MODIFY CONSTRAINT EMP_MANAGER_FK ENABLE NOVALIDATE; 10. Wprowadzić kilka nowych wierszy do tabeli EMPLOYEES. Czy tym razem klucy obcz jest weryfikowany? Comment [m1]: Błędna wartość. Ten sam klucz co w operacji powyżej. Sprawdzam walidację klucza głównego Comment [m2]: Błędna wartość. Ta sama wartość jak kolumnie powyżej. Sprawdzam walidację unikalności Comment [m3]: Błędna wartość klucza obcego. Sprawdzam jak zachowuje się walidacja odroczona. Comment [m4]: Błędna wartość klucza obcego Comment [m5]: Błędna wartość klucza obcego A. INSERT INTO EMPLOYEES VALUES( 1007, 'STEVEN 7', 'KING 7', 'SKING7@COMPANY.COM',24070, 1006 ); Strona: 9 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 7

b. INSERT INTO EMPLOYEES VALUES( 1008, 'STEVEN 8', 'KING 8', 'SKING8@COMPANY.COM',24080, 1007 ); c. COMMIT; d. Tym razem klucz obcy jest walidowany poprawnie. 11. Przełączyć klucz obcy na tabeli EMPLOYEES w tryb ENABLE VALIDATE. Czy udało się przełączyć klucz główny w ten tryb? Jeśli nie to zastanowić się co jest przyczyną i rozwiązać problem. a. ALTER TABLE EMPLOYEES MODIFY CONSTRAINT EMP_MANAGER_FK ENABLE VALIDATE; b. Może się nie udać bo w tabeli są błędne wiersze nieodpowiadające. Nalezy usunąć błędne wiersze lub je zaktualizowć. Ćwiczenie 2 Tabele tymczasowe 1. Jako użytkownik HR utworzyć tabelę tymczasową EMPLOYEES_TEMP z taką samą strukturą kolumn jak w tabeli EMPLOYEES z usuwaniem wierszy przy zakończeniu sesji. a. CREATE GLOBAL TEMPORARY TABLE EMPLOYEES_TEMP ON COMMIT PRESERVE ROWS AS SELECT * FROM EMPLOYEES WHERE 1=2; 2. Załadować wiersze z tabeli EMPLOYEES do tabeli EMPLOYEES_TEMP a. INSERT INTO EMPLOYEES_TEMP (SELECT * FROM EMPLOYEES); b. COMMIT; 3. Sprawdzić czy po zakończeniu transakcji wiersze wciąż są w tabeli tymczasowej a. SELECT * FROM EMPLOYEES_TEMP; b. wiersze wciąż są w tabeli tymczasowej 4. W drugim terminalu SQLPLUS zalogować się jako ten sam użytkownik HR i sprawdzić zawartość tabeli EMPLOYEES_TEMP. Dlaczego nie ma żadnych wierszy mimo, że przed chwilą ładowane były z innego terminala? a. Nie widać bo wiersze w tabelach tymczasowych są dostępne tylko w tej sesji które je wprowadziła. Ćwiczenie 3 Transakcje Operacje wymagane do zrobienia tego ćwiczenia nie wymagają podawania rozwiązania ponieważ głównie bazują na prostych instrukcjach UPDATE. Strona: 10 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 7