ZASTOSOWANIE PROCEDUR, FUNKCJI I PAKIETÓW

ZASTOSOWANIE PROCEDUR, FUNKCJI I PAKIETÓW Położenie podprogramów Jak wiemy, podprogramy i pakiety jako bloki nazwane, mogą być składowane w słowniku danych. Podprogram najpierw tworzy się za pomocą polecenia CREATE OR REPLACE, a następnie wywołuje z innego bloku PL/SQL. Podprogram może być również definiowany w sekcji deklaracji bloku i wtedy jest nazywany podprogramem lokalnym. Pakiety muszą być zapisane w słowniku danych i nie mogą być lokalne. Podprogramy składowane oraz słownik danych Podprogram utworzony za pomocą polecenia CREATE OR REPLACE jest składowany w bazie danych. Obiekty te składowane są w skompilowanej formie zwanej p-kodem. Skompilowana forma podprogramu p-kod uwzględnia wszystkie odwołania, a sam kod źródłowy jest przekształcony w postać, którą można łatwo odczytać przez mechanizm PL/SQL. Po wywołaniu podprogramu następuje odczytanie p-kodu z dysku (o ile to jest konieczne) i jego wykonanie. Po odczytaniu z dysku p-kod jest zapisywany we współużytkowanym, globalnym obszarze systemowym (SGA), gdzie jeżeli jest taka potrzeba może z niego korzystać wielu użytkowników. Podobnie jak wszystkie elementy wchodzące w skład puli współużytkowanej, p-kod jest usuwany z pamięci na podstawie algorytmu LRU (najmniej używana część). P-kod posiada cechy kodu obiektowego, generowanego przez inne kompilatory języków trzeciej generacji lub kodu bajtowego w języku Java, który może być odczytywany przez system wykonawczy języka Java (Java Runtime System). Ponieważ p-kod zawiera odwołania obiektowe w wykonywanym podprogramie (jest to właściwość wczesnego wiązania), a zatem wykonanie p-kodu nie zajmuje zbyt dużej ilości zasobów. Informacje dotyczące podprogramu są dostępne za pośrednictwem perspektyw słownika danych. Perspektywa user_objects zawiera komunikaty na temat wszystkich obiektów należących do bieżącego użytkownika, również składowanych podprogramów. Informacje te zawierają dane dotyczące czasu utworzenia obiektu, jego ostatniej modyfikacji, typu obiektu oraz poprawności obiektu. Perspektywa user_source zawiera oryginalny kod źródłowy obiektu. Perspektywa user_errors zawiera informacje dotyczące błedów kompilacji. Rozważmy następującą prostą procedurę: CREATE OR REPLACE PROCEDURE prosta AS z_zmienna NUMBER; z_zmienna:=5; END prosta; Po utworzeniu tej procedury perspektywa user_objects oznacza ją jako prawidłową, a perspektywa user_source zawiera jej kod źródłowy. perspektywa user_errors nie zawiera żadnych wierszy, ponieważ procedura prosta została skompilowana z powodzeniem. SELECT object_name, object_type, status FROM user_objects WHERE object_name = prosta ; OBJECT_NAME OBJECT_TYPE STATUS PROSTA PROCEDURE VALID 1

SELECT text FROM user_source WHERE object_name = prosta ORDER BY line; TEXT CREATE OR REPLACE PROCEDURE prosta AS z_zmienna NUMBER; z_zmienna:=5; END prosta; SELECT line, position, text FROM user_errors WHERE name = prosta ORDER BY sequence; no rows selected Jeżeli jednak zmodyfikuje się kod procedury prosta tak, aby wystąpił błąd kompilacji (np. brak średnika) CREATE OR REPLACE PROCEDURE prosta AS z_zmienna NUMBER; z_zmienna:=5 END prosta; i nastąpi sprawdzenie tego samego układu perspektyw słownika danych, to wynikiem takiego działania będą następujące SELECT object_name, object_type, status FROM user_objects WHERE object_name = prosta ; OBJECT_NAME OBJECT_TYPE STATUS PROSTA PROCEDURE INVALID SELECT text FROM user_source WHERE object_name = prosta ORDER BY line; TEXT CREATE OR REPLACE PROCEDURE prosta AS z_zmienna NUMBER; z_zmienna:=5 END prosta; 2

SELECT line, position, text FROM user_errors WHERE name = prosta ORDER BY sequence; LINE POSITION TEXT 5 1 BŁĄD w linii 5: ORA-06550: linia 5, kolumna 1: PLS-00103: Napotkano symbol "END" gdy oczekiwano jednego z następujących: * & = - + ; < / > at in is mod not rem <an exponent (**)> <> or!= or ~= >= <= <> and or like between Symbol ";" zostało podstawione za "END" w celu kontynuacji. Nieprawidłowy podprogram składowany jest w dalszym ciągu przechowywany w bazie danych. Mimo to, jego pomyślne wywołanie jest niemożliwe do chwili poprawienia błędów. Wywołanie nieprawidłowej procedury powoduje zwrócenie błędu PLS-905. Kompilacja kodu macierzystego P-kod podobnie jak kody bajtowe w języku Java jest interpretowany i wykonywany przez mechanizm PL/SQL. Takie działanie zapewnia przenośność kodu, umożliwiając uruchomienie tego samego kodu PL/SQL w różnych bazach danych, a nawet na różnych platformach. Ponieważ jednak p-kod jest interpretowany, nie jest on tak szybki jak kod skompilowany do postaci macierzystej systemu operacyjnego. W systemie Oracle9i wprowadzono możliwość wyboru kompilacji kodu PL/SQL do postaci macierzystej. Podprogramy lokalne Rozważmy poniższy kod programu języka PL/SQL, w którego sekcji deklaracji znajduje się program lokalny: SQL> DECLARE 2 CURSOR k_wszyscypracownicy IS 3 SELECT nazwisko, imie 4 FROM pracownyicy; 5 z_pelnedane VARCHAR2(50); 6 FUNCTION FunPelneDane(p_Nazwisko VARCHAR2(30), 7 p_imie VARCHAR2(20)) 8 RETURN VARCHAR2 IS 9 10 RETURN p_nazwisko p_imie; 11 END FunPelneDane; 12 13 FOR z_rekordpracownik IN k_wszyscypracownicy LOOP 14 z_pelnedane:=funpelnedane(z_rekordpracownik.nazwisko, z_rekordpracownik.imie); 15 DBMS_OUTPUT.PUT_LINE(z_PelneDane); 16 END LOOP; 17 END; 18 / Funkcja FunPelneDane jest deklarowana w sekcji deklaracji bloku. Nazwa funkcji jest identyfikatorem PL/SQL i w związku z tym podlega tym samym regułom zakresu i widoczności, co inne identyfikatory PL/SQL. Szczególnie istotne jest to, że nazwa tej funkcji pozostaje widoczna tylko w bloku, w którym jest deklarowana. Jej zakres sięga od miejsca deklaracji do końca danego bloku. Nie można wywołać funkcji FunPelneDane z żadnego innego bloku, ponieważ funkcja ta nie będzie widoczna. 3

Podprogramy lokalne jako część podprogramów składowanych Podprogramy lokalne można również deklarować w sekcji deklaracji podprogramu składowanego. W takim przypadku funkcję lokalną FunPelneDane można wywoływać jedynie wewnątrz procedury składowanej ProcSklad, w której została ona zadeklarowana, ponieważ wyznacza ona granice zakresu: CREATE OR REPALCE PROCEDURE ProcSklad /*Deklaracje lokalnego kursora, zmiennych oraz funkcji */ CURSOR k_wszyscypracownicy IS SELECT nazwisko, imie FROM pracownicy; z_pelnedane VARCHAR2(50); /*Funkcja, która zwraca połączenie nazwiska i imienia */ FUNCTION FunPelneDane(p_Nazwisko VARCHAR2(30), p_imie VARCHAR2(20)) RETURN VARCHAR2 IS RETURN p_nazwisko p_imie; END FunPelneDane; -- Początek głównego bloku FOR z_rekordpracownik IN k_wszystkiepracownicy LOOP z_pelnedane:=funpelnedane(z_rekordpracownik.nazwisko, z_rekordpracownik.imie); DBMS_OUTPUT.PUT_LINE(z_PelneDane); END LOOP; END ProcSklad; Jeżeli wykona się powyższą procedurę składowaną, to uzyskany wynik będzie taki sam jak w przypadku poprzedniego bloku anonimowego. Położenie podprogramów lokalnych Wszystkie podprogramy lokalne należy deklarować w końcowej części sekcji deklaracji. Gdyby przeniesiono deklarację funkcji FunPelneDane ponad deklarację kursora k_wszyscypracownicy, tak jak zostało to pokazane w poniższej sesji programu SQL*Plus, otrzymano by błąd kompilacji: SQL> DECLARE 2 /*Funkcja, która zwraca połączenie nazwiska i imienia */ 3 FUNCTION FunPelneDane(p_Nazwisko VARCHAR2(30), 4 p_imie VARCHAR2(20)) 5 RETURN VARCHAR2 IS 6 7 RETURN p_nazwisko p_imie; 8 END FunPelneDane; 9 CURSOR k_wszyscypracownicy IS 10 SELECT nazwisko, imie 11 FROM pracownyicy; 12 z_pelnedane VARCHAR2(50); 13 14 -- Początek głównego bloku 15 16 FOR z_rekordpracownik IN k_wszyscypracownicy LOOP 17 z_pelnedane:=funpelnedane(z_rekordpracownik.nazwisko, z_rekordpracownik.imie); 18 DBMS_OUTPUT.PUT_LINE(z_PelneDane); 4

19 END LOOP; 20 END; 21 / CURSOR k_wszyscypracownicy IS * ERROR at line 9: ORA-06550: line 9, column 3; PLS-00103: Napotkano symbol CURSOR tam, gdzie spodziewano się jednego z poniższych: begin function package pragma procedure form Deklaracje wyprzedzające Nazwy podprogramów lokalnych PL/SQL są identyfikatorami, a zatem muszą być zadeklarowane zanim nastąpi odwołanie do nich. Zwykle nie powinno to stanowić problemu. Jednak w przypadku podprogramów, które odwołują się wzajemnie, powoduje to pewne trudności, np.: SQL> DECLARE 2 z_warttymcz BINARY_INTEGER:=5; 3 -- Procedura lokalna A, która wywołuje procedurę lokalną B 4 PROCEDURE A(p_Licznik IN OUT BINARY_INTEGER) IS 5 6 DBMS_OUTPUT.PUT_LINE( A( p_licznik ) ); 7 IF p_licznik > 0 THEN 8 B(p_Licznik); 9 p_licznik:=p_licznik 1; 10 END IF; 11 END A; 12 13 -- Procedura lokalna B, która wywołuje procedurę lokalną A 14 PROCEDURE B(p_Licznik IN OUT BINARY_INTEGER) IS 15 16 DBMS_OUTPUT.PUT_LINE( B( p_licznik ) ); 17 IF p_licznik > 0 THEN 18 p_licznik:=p_licznik 1; 19 A(p_Licznik); 20 END IF; 21 END B; 22 -- Część główna programu 23 24 B(z_WartTymcz); 25 END; 26 / BŁĄD w linii 1: ORA-06550: linia 8, kolumna 7; PLS-00201: identyfikator B musi być zadeklarowany ORA-06550: linia 8, kolumna 7; PL/SQL: Polecenie odrzucone Jak dowodzi powyższa sesja programu SQL*Plus, pomyślna kompilacja powyższego przykładowego fragmentu kodu jest niemożliwa. Procedura A wywołuje procedurę B, a zatem procedura B musi być zadeklarowana przed procedurą A. Tylko wtedy odwołanie do procedury B mogłoby być wykonane. Jednak procedura B wywołuje procedurę A, a więc procedura A musi być zadeklarowana przed procedurą B, tak aby odwołanie do procedury A mogło być wykonane. Powyższe warunki nie mogą być spełnione jednocześnie. W 5

celu rozwiązania tego problemu można zastosować deklarację wyprzedzającą. Jest to po prostu nazwa procedury wraz z jej parametrami formalnymi. Deklaracje wyprzedzające pozwalają na istnienie procedur ze wzajemnymi odwołaniami. Wykorzystuje się je także w nagłówkach pakietów. Poniższy przykład kodu programu jest ilustracją tej techniki: SQL> DECLARE 2 z_warttymcz BINARY_INTEGER:=5; 3 -- Deklaracja wyprzedzajaca procedury B 4 PROCEDURE B(p_Licznik IN OUT BINARY_INTEGER); 5 -- Procedura lokalna A, która wywołuje procedurę lokalną B 6 PROCEDURE A(p_Licznik IN OUT BINARY_INTEGER) IS 7 8 DBMS_OUTPUT.PUT_LINE( A( p_licznik ) ); 9 IF p_licznik > 0 THEN 10 B(p_Licznik); 11 p_licznik:=p_licznik 1; 12 END IF; 13 END A; 14 15 -- Procedura lokalna B, która wywołuje procedurę lokalną A 16 PROCEDURE B(p_Licznik IN OUT BINARY_INTEGER) IS 17 18 DBMS_OUTPUT.PUT_LINE( B( p_licznik ) ); 19 IF p_licznik > 0 THEN 20 p_licznik:=p_licznik 1; 21 A(p_Licznik); 22 END IF; 23 END B; 24 -- Część główna programu 25 26 B(z_WartTymcz); 27 END; 28 / Oto wynik działania powyższego programu: B(5) A(4) B(4) A(3) B(3) A(2) B(2) A(1) B(1) A(0) Przeciążanie podprogramów lokalnych Okazuje się, że istnieje możliwość przeciążania podprogramów zadeklarowanych wewnątrz pakietów. Dotyczy to także podprogramów lokalnych, co ilustruje poniższy przykład: DECLARE -- Dwie przeciążone procedury lokalne PROCEDURE ProcLOkalna(p_Parametr1 IN NUMBER) IS 6

DBMS_OUTPUT.PUT_LINE( Wewnątrz wersji1., p_parametr1 = p_parametr1); END ProcLokalna; PROCEDURE ProcLOkalna(p_Parametr1 IN VARCHAR2) IS DBMS_OUTPUT.PUT_LINE( Wewnątrz wersji2., p_parametr1 = p_parametr1); END ProcLokalna; -- Wywołanie wersji 1. ProcLokalna(12345); -- oraz wersji 2. ProcLokalna( abcde ); END; Podprogramy składowane a podprogramy lokalne Podprogramy składowane i podprogramy lokalne zachowują się w odmienny sposób i mają różne właściwości. Bardziej korzystnym jest chyba stosowanie podprogramów składowanych, chociażby z takiego powodu, iż w przypadku opracowywania użytecznego podprogramu, jest wielce prawdopodobnym, iż pojawi się potrzeba wywołania go z różnych bloków. W tym celu podprogram musi być składowany w bazie danych. Zwykle należy również uwzględnić korzyści wynikające z rozmiaru i złożoności danego obiektu. Natomiast jako podprogramy lokalne należy jak najbardziej deklarować jedynie te procedury i funkcje, które posiadają bardzo niewielkie rozmiary i są wywoływane z jednej, specyficznej sesji programu (bloku zawierającego dany podprogram). Takie podprogramy lokalne zazwyczaj wykorzystuje się w celu uniknięcia powtarzania kodu w ramach pojedynczego bloku, wówczas przypominają one makra w języku C. Tabela. Porównanie podprogramów składowanych z podprogramami lokalnymi. Podprogram składowany Składowany w bazie danych w formie skompilowanego p-kodu. Po wywołaniu procedury podprogram nie musi podlegać kompilacji Może być wywołany z każdego bloku podanego przez użytkownika, który posiada uprawnienia EXECUTE dla tego podprogramu Przez oddzielenie kodu podprogramu od bloku wywołującego blok wywołujący jest krótszy i łatwiejszy w zrozumieniu. W razie potrzeby podprogram i blok wywołujący mogą być obsługiwane osobno. Skompilowany p-kod może być osadzony w obszarze wspólnym za pomocą procedury pakietowej DBMS_SHARED_POOL.KEEP. Takie postępowanie może prowadzić do poprawy wydajności aplikacji Niezależne podprogramy składowane nie mogą być przeciążane, natomiast w ramach określonego pakietu można przeciążać podprogramy wchodzące w skład pakietu Podprogram lokalny Podprogram lokalny jest skompilowany jako część bloku, w którym się znajduje. Jeżeli blok jest anonimowy i wykonywany wielokrotnie, podprogram musi być kompilowany za każdym razem. Może być wywołany tylko z bloku zawierającego dany podprogram. Podprogram i blok wywołujący stanowią jeden element, co może prowadzić do pomyłek. Po dokonaniu zmian w bloku wywołującym, w ramach kompilacji bloku wywołującego, trzeba także skompilować podprogram. Podprogramy lokalne nie mogą zostać osadzone w obszarze wspólnym. Podprogramy lokalne można przeciążać w obrębie tego samego bloku. 7

Zagadnienia dotyczące podprogramów składowanych i pakietów Składowanie podprogramów i pakietów jako obiektów słownika bazy danych posiada określone zalety. Na przykład dzięki temu mogą one być oddzielone pomiędzy użytkownikami bazy danych. Wiąże się z tym kilka zagadnień: zależności pomiędzy obiektami składowanymi, obsługa stanu pakietu oraz uprawnienia konieczne do uruchomienia podprogramów składowanych i pakietów. Zależności pomiędzy podprogramami Podczas przeprowadzania procesu kompilacji procedury lub funkcji wszystkie obiekty Oracle, do których odwołania zawarto w treści procedury (funkcji), są zapisywane w słowniku danych. Procedura jest zależna od tych obiektów. Jak wiemy, podprogram, dla którego wystąpiły błędy kompilacji, jest oznaczany w słowniku danych jako nieprawidłowy (invalid). Podprogram składowany może również stać się nieprawidłowy w razie wykonania operacji DDL na jednym z obiektów, od których podprogram ten jest zależny Przykład. Rozważmy funkcję PrawieBrak postaci: CREATE OR REPLACE FUNCTION PrawieBrak(p_id produkty.id%type) RETURN BOOLEAN IS z_id produkty.id%type; z_stanmagazyn produkty.stan_magazyn%type; z_wartoscfunkcji BOOLEAN; z_stanmin CONSTANT NUMER:=100; -- Uzyskanie bieżącej liczby produktów wycofanych i wszystkich produktów dla pożądanej kategorii SELECT id, stan_magazyn INTO z_id, z_stanmagazyn FROM produkty WHERE id = p_id; -- Zwrócenie wartości TRUE, jeżeli liczba produktów w magazynie jest niższa -- od założonej minimalnej liczby produktów lub FALSE w przeciwnym przypadku. IF z_stanmagazyn < z_stanmin THEN z_wartoscfunkcji:=true; ELSE z_wartoscfunkcji:=false; END IF; RETURN z_wartoscfunkcji; END PrawieBrak; Funkcja ta wykonuje zapytania do tabeli produkty i jest zależna tylko od jednego obiektu tabeli produkty. Zależności (oznaczone strzałką) funkcji PrawieBrak zostały przedstawione na poniższym rysunku: produkty PrawieBrak Funkcja PrawieBrak zależy bezpośrednio od tabeli produkty 8

Można teraz utworzyć procedurę wywołującą funkcję PrawieBrak i wstawiającą wyniki do tabeli tabdzienzam. Procedura ta nosi nazwę DzienneZam i wybiera w poszczególnych kategoriach produkty wymagające uzupełnienia w magazynie i zapisuje do tabeli tabdzienzam: CREATE OR REPLACE PROCEDURE DzienneZam AS CURSOR k_produkty IS SELECT id, nazwa FROM produkty; FOR z_rekordprodukt IN k_produkt LOOP /* Zapisanie w tabeli tabdzienzam wszystkich produktów w poszczególnych kategoriach których stan magazynu wymaga uzupełnienia */ IF PrawieBrak(z_RekordProdukt.id) THEN INSERT INTO tabdzienzam(kol_komunikat) VALUES ( Produkt o id z_rekordprodukt.id i nazwie z_rekord.nazwa wymaga uzupełnienia! ); END IF; END LOOP; END DzienneZam; Występujące zależności dla tej procedury przedstawiono na poniższym rysunku: Funkcja PrawieBrak zależy bezpośrednio od tabeli produkty produkty PrawieBrak Procedura DzienneZam zależy bezpośrednio od tabeli tabdzienzam oraz od funkcji PrawieBark oraz pośrednio od tabeli kategorie tabdzienzam DzienneZam Rysunek. Zależności dla procedury DzienneZam Występujące zależności dla tej procedury przedstawiono strzałkami. Procedura DzienneZam zależy zarówno od funkcji PrawieBrak, jak i od tabeli tabdzienzam. Są to zależności bezpośrednie, ponieważ procedura DzienneZam odwołuje się bezpośrednio do funkcji PrawieBrak oraz do tabeli tabdzienzam. Funkcja PrawieBrak zależy bezpośrednio od tabeli produkty, a zatem procedura DzienneZam jest pośrednio zależna od tabeli produkty. W razie wykonania operacji DDL dla tabeli produkty wszystkie obiekty, które zależą od tabeli produkty (bezpośrednio lub pośrednio), stają się nieprawidłowe. Np. jeśli do tabeli produkty dodamy nowe pole 9

ALTER TABLE produkty ADD ( rodzaj_produktu VARCHAR2(15)); -- określa rodzaj produktu: sypki, płyn, itp. to po takiej operacji funkcja PrawieBrak oraz procedura DzienneZam staną się nieprawidłowe, ponieważ są zależne od tabeli produkty. Po wykonaniu powyższej operacji DDL otrzymamy następujący stan: SQL> SELECT object_name, object_type, status 2 FROM user_objects 3 WHERE object_name IN ( PrawieBrak, DzienneZam ); OBJECT_NAME OBJECT_TYPE STATUS DzienneZam PROCEDURE INVALID PrawieBrak FUNCTION INVALID Automatyczna, ponowna kompilacja W przypadku utraty poprawności zależnego obiektu mechanizm PL/SQL wykona próbę automatycznej, ponownej kompilacji tego obiektu w momencie kolejnego odwołania. Ponieważ ani procedura DzienneZam, ani funkcja PrawieBrak nie odwołują się do nowej kolumny w tabeli produkty, proces ponownej kompilacji powiedzie się. Ilustruje to poniższa sesja programu SQL*Plus. SQL> EXEC DzienneZam; PL/SQL procedure successfully completed. SQL> SELECT object_name, object_type, status 4 FROM user_objects 5 WHERE object_name IN ( PrawieBrak, DzienneZam ); OBJECT_NAME OBJECT_TYPE STATUS DzienneZam PROCEDURE VALID PrawieBrak FUNCTION VALID Pakiety a zależności Jak wiemy z naszych rozważań, podprogramy składowane mogą utracić ważność w przypadku modyfikacji obiektów od nich zależnych. Dla pakietów sytuacja jest odmienna. Rozważmy pakiet PakietPracowniczy, który był rozważany podczas omawiania pakietów: CREATE OR REPLACE PACKAGE BODY PakietPracowniczy AS -- Przydzielenie pracownika do odpowiedniej grupy wynagrodzeń. PROCEDURE DodajPracownika (p_pracownikid IN pracownicy.id%type, p_grupa IN grupy.grupa%type, p_stawkagodz IN grupy.stawka%type); INSERT INTO grupy_pracownikow (pracownik_id, grupa, stawka) VALUES(p_PracownikId, p_grupa, p_stawkagodz); END DodajPracownika; -- Usunięcie pracownika z danej grupy wynagrodzeń. PROCEDURE UsunPracownika (p_pracownikid IN pracownicy.id%type, p_grupa IN grupy.grupa%type, 10

p_stawkagodz IN grupy.stawka%type); DELETE FROM grupy_pracownikow WHERE pracownik_id = p_pracownikid AND grupa = p_grupa; -- Srawdzenie, czy operacja DELETE powiodła się. Jeśli nie znaleziono wierszy do usunięcia zgłoszenie --.błędu IF SQL%NOTFOUND THEN RAISE w_pracownikniewprowadzony; END IF; END UsunPracownika; -- Zwraca tabelę PL/SQL zawierającą dane pracownikow przypisanych do danej grupy uposażeń TYPE t_tabelaidpracownikow IS TABLE OF pracownicy%type INDEX BY BINARY_INTEGER; -- Zwraca tabelę PL/SQL zawierającą pracowników znajdujących się w określonej grupie wynagrodzeń. PROCEDURE WynagrPracownika (p_grupa IN grupy.grupa%type, p_stawkagodz IN grupy.stawka%type, p_ids OUT t_tabelaidpracownikow, p_liczbaprac IN OUT BINARY_INTEGER) IS z_pracownikid grupy_pracownicy.pracownik_id%type; -- Lokalny kursor w celu pobrania pracowników i ich grup uposażeń CURSOR k_grupapracownikow IS SELECT pracownik_id FROM grupy_pracownicy WHERE grupa = p_grupa; /* Parametr p_liczbaprac będzie indeksem tabeli. Rozpoczyna się od 0 i będzie zwiększany o 1 za każdym * wykonaniem pętli pobierania. Przy zakończeniu wykonywania pętli będzie zawierać liczbę pobranych * wierszy, a zatem liczbę wierszy zwracanych w parametrze p_ids */ p_liczbaprac := 0; OPEN k_grupapracownikow; LOOP FETCH k_grupapracownikow INTO z_pracownikid; EXIT WHEN k_grupapracownikow%notfound; p_liczbaprac := p_liczbaprac + 1; p_ids(p_liczbaprac):= z_pracownikid; END LOOP; END WynagrPracownika; END PakietPracowniczy; 11

PakietPracowniczy (nagłówek) PakietPracowniczy (treść) Treść pakietu PakietPracowniczy zależy od tabeli grupy_pracownikow, nagłówek nie grupy_pracownikow Treść pakietu PakietPracowniczy zależy od nagłówka, natomiast nagłówek nie zależy od treści. Rysunek. Zależności pakietu PakietPracowniczy Treść pakietu zależy od tabeli grupy_pracownikow oraz nagłówka pakietu. Nagłówek pakietu nie zależy jednak od treści pakietu czy też od tabeli grupy_pracownikow. Na tym właśnie polega jedna z zalet pakietów można modyfikować treść pakietu bez koniecznośći modyfikacji nagłówka. Z tego powodu nie ma potrzeby ponownej kompilacji obiektów, które zależą od nagłówka, ponieważ nigdy nie utracą one ważności. W przypadku modyfikacji nagłówka, treść automatycznie traci ważność (ponieważ treść zależy od nagłówka). Istnieją przypadki, w których treść pakietu powoduje konieczność modyfikacji nagłówka. Na przykład, jeśli wystąpi potrzeba modyfikacji argumentów procedury, to należy zmodyfikować zarówno nagłówek, jak i treść, aby deklaracje były zgodne. Nagłówka nie trzeba modyfikować przy modyfikacji implementacji treści procedury bez naruszania deklaracji. Sposoby określania utraty ważności Jak wynika to z wcześniejszych rozważań, w momencie modyfikacji obiektu, tracą ważność obiekty, które od niego zależą. Jeżeli wszystkie te obiekty znajdują się w tej samej bazie danych, to zależne tracą ważność z chwilą modyfikacji obiektu bazowego. Może to stać się szybko, ponieważ słownik danych śledzi zależności. Załóżmy, że zostały utworzone dwie procedury: P1 oraz P2, za pomocą poniższego programu w języku PL/SQL. CREATE OR REPLACE PROCEDURE P2 AS DBMS_OUTPUT.PUT_LINE( Wnetrze procedury P2! ); END P2; / CREATE OR REPLACE PROCEDURE P1 AS DBMS_OUTPUT.PUT_LINE( Wnętrze procedury P1! ); P2; END P1; / Procedura P1 zależy od procedury P2, co oznacza, że ponowna kompilacja procedury P2 spowoduje utratę ważności procedury P1. Fakt ten został zilustrowany w poniższej sesji programu SQL*Plus: 12

Sprawdzenie, czy obie procedury są ważne SQL> SELECT object_name, object_type, status 2 FROM user_objects 3 WHERE object_name IN ( P1, P2 ); OBJECT_NAME OBJECT_TYPE STATUS P1 PROCEDURE VALID P2 PROCEDURE VALID Ponowna kompilacja procedury P2, powoduje natychmiastową utratę ważności procedury P1. SQL> ALTER PROCEDURE P2 COMPILE; Procedure altered. Ponowne sformułowanie zapytania w celu sprawdzenia, czy obie procedury są ważne SQL> SELECT object_name, object_type, status 2 FROM user_objects 3 WHERE object_name IN ( P1, P2 ); OBJECT_NAME OBJECT_TYPE STATUS P1 PROCEDURE INVALID P2 PROCEDURE VALID CREATE OR REPLACE PROCEDURE P1 AS DBMS_OUTPUT.PUT_LINE ( Wnetrze procedury P1! ); P2; END P1; CREATE OR REPLACE PROCEDURE P2 AS DBMS_OUTPUT.PUT_LINE ( Wnetrze procedury P2! ); END P2; Mechanizm PL/SQL Rysunek. Procedury P1 I P2 w tej samej bazie danych Można również rozpatrzyć przypadek, kiedy procedury P1 i P2 znajdują się w różnych bazach danych, a procedura P1 wywołuje procedurę P2 poprzez łącze do bazy danych. Sytuację tą ilustruje poniższy rysunek. CREATE OR REPLACE PROCEDURE P1 AS DBMS_OUTPUT.PUT_LINE ( Wnetrze procedury P1! ); P2; END P1; Mechanizm PL/SQL1 CREATE OR REPLACE PROCEDURE P2 AS DBMS_OUTPUT.PUT_LINE ( Wnetrze procedury P2! ); END P2; Mechanizm PL/SQL2 Procedury P1 i P2 w różnych bazach danych W tym przypadku ponowna kompilacja procedury P2 nie powoduje natychmiastowej utraty ważności procedury P1. Ilustruje to poniższa sesja programu SQL*Plus: 13

SQL> /* Utworzenie łącza do bazy danych wskazującego na bazę bieżącą SQL> CREATE DATABASE LINK petla_zwrotna 2 USING ciag_polaczenia ; Database link created. SQL> -- modyfikacja procedury P1 tak, aby wywoływała procedurę P2 przez łącze. SQL> CREATE OR REPLACE PROCEDURE P1 AS 2 3 DBMS_OUTPUT.PUT_LINE( Wnętrze procedury P1! ); 4 P2@petla_zwrotna; 5 END P1; 6 / Procedure created. Sprawdzenie, czy obie procedury są ważne SQL> SELECT object_name, object_type, status 4 FROM user_objects 5 WHERE object_name IN ( P1, P2 ); OBJECT_NAME OBJECT_TYPE STATUS P1 PROCEDURE VALID P2 PROCEDURE VALID Teraz po ponownym skompilowaniu procedury P2, procedura P1 nie utraci ważności natychmiast. SQL> ALTER PROCEDURE P2 COMPILE; Procedure altered. Ponowne sformułowanie zapytania w celu sprawdzenia, czy obie procedury są ważne SQL> SELECT object_name, object_type, status 4 FROM user_objects 5 WHERE object_name IN ( P1, P2 ); OBJECT_NAME OBJECT_TYPE STATUS P1 PROCEDURE VALID P2 PROCEDURE VALID UWAGA: W powyższym przykładzie łącze do bazy danych właściwie jest pętlą zwrotną, wskazującą na te samą bazę danych. Jednak zaobserwowane działanie jest takie samo jak gdyby procedury P1 oraz P2 znajdowały się w oddzielnych bazach danych. Zastosowanie pętli zwrotnej umożliwia uzyskanie informacji na temat statusu procedur P1 oraz P2 w pojedynczej instrukcji SELECT. Jak z powyższego wynika, w przypadku odległej bazy danych zagadnienie dotyczące utraty ważności jest diametralnie inne. Wynika to z faktu, iż słownik danych nie śledzi zdalnych zależności, w związku z tym unieważnienie wszystkich zależnych obiektów, które w momencie unieważnienia mogłyby nawet być niedostępne, byłoby zbyt kosztowne. Zamiast tego, ważność zdalnych obiektów jest sprawdzana w czasie wykonywania. W momencie wywołania procedury P1 jest formułowane zapytanie do zdalnego słownika danych w celu sprawdzenia statusu procedury P2 (jeżeli zdalna baza danych jest niedostępna, to zgłaszany jest błąd). Następnie procedury P1 i P2 są porównywane, aby sprawdzić, czy konieczna jest ponowna kompilacja procedury P1. Istnieją dwie różne metody porównywania: model datownika i model sygnatury. 14

Stan pakietów w czasie wykonywania W czasie tworzenia egzemplarza pakietu po raz pierwszy, kod pakietu jest odczytywany z dysku na obszar wspólny (shared pool). Jednak stan wykonywania pakietu w szczególności zmienne pakietu oraz kursory są przechowywane w pamięci sesji. Oznacza to, że każda sesja posiada swoją własną kopię stanu wykonywania. jest on inicjowany w momencie tworzenia egzemplarza pakietu i utrzymywany do chwili zamknięcia sesji, nawet jeśli stan pakietu w obszarze wspólnym zdezaktualizuje się. Jak wiemy z rozważań dotyczących analizy budowy pakietów, zmienne zadeklarowane w nagłówku pakietu mają zasięg globalny. Są one widoczne dla każdego bloku PL/SQL posiadającego uprawnienia EXECUTE w stosunku do pakietu. Ponieważ stan pakietu jest utrzymywany do zakończenia sesji, to zmienne w nagłówku pakietu mogą być wykorzystywane jako zmienne globalne. Ilustruje to poniższy przykład: 15

CREATE OR REPLACE PACKAGE TrwaloscPakietu AS -- Typ służący do zapisania tablicy identyfikatorów klientów TYPE t_tabelaklientow IS TABLE OF klienci.kod_klienta%type INDEX BY BINARY_INTEGER; -- Maksymalna liczba wierszy, która będzie zwrócona za każdym razem z_maksliczbawierszy NUMBER:=5; -- Procedura zwraca do z_maksliczbawierszy kodów klientów PROCEDURE ListaKlientow(p_TabelaKlienci OUT t_tabelaklientow, p_liczbawierszy OUT NUMBER); END TrwaloscPakietu; CREATE OR REPLACE PACKAGE BODY TrwaloscPakietu AS -- Zapytanie do tabeli klienci. Ponieważ dla treści pakietu ma ono globalny zasięg, pozostanie aktywne poza -- wywołaniem z bazy danych. CURSOR k_klienci IS SELECT kod_klienta FROM klienci ORDER BY nazwa_firmy; PROCEDURE ListaKlientow(p_TabelaKlienci OUT t_tabelaklientow, p_liczbawierszy OUT NUMBER) AS z_wykonano BOOLEAN:=FALSE; z_liczbawierszy NUMBER:=1; IF NOT k_klienci%isopen THEN OPEN k_klienci END IF; -- Kursor jest już otwarty, zatem można pobrać wiersze w liczbie do z_maksliczbawierszy WHILE NOT z_wykonano LOOP FETCH k_klienci INTO p_tabelaklienci(z_liczbawierszy); IF k_klienci%notfound THEN -- Brak więcej danych, zatem można zakończyć proces pobierania. CLOSE k_klienci; z_wykonano:=true; ELSE z_liczbawierszy:= z_liczbawierszy+1; IF z_liczbawierszy > z_maksliczbawierszy THEN z_wykonano:=true; END IF; END IF; END LOOP; -- Zwrócenie rzeczywistej liczby pobranych wierszy. p_liczbawierszy:=z_liczbawierszy 1; END ListaKlientow; END TrwaloscPakietu; Procedura TrwaloscPakietu.ListaKlientow pobiera dane z kursora k_klienci. Ponieważ kursor ten został zadeklarowany na poziomie pakietu (a nie wewnątrz procedury ListaKlientow), będzie utrzymywany po wywołaniu procedury ListaKlientow. Procedurę TrwaloscPakietu.ListaKlientow można wywołać za pomocą następującego bloku PL/SQL: 16

DECLARE z_tabelaklientow TrwaloscPakietu.t_TabelaKlientow; z_liczba_wierszy NUMBER:=TrwaloscPakietu.z_MaksLiczbaWierszy; z_nazwafirmy klienci.nazwa_firmy%type; TrwaloscPakietu.ListaKlientow(z_TabelaKlientow, z_liczba_wierszy); DBMS_OUTPUT.PUT_LINE( Pobrano z_liczba_wierszy wierszy: ); FOR z_licznik IN 1.. z_liczba_wierszy LOOP SELECT nazwa_firmy INTO z_nazwafirmy FROM klienci WHERE kod_klienta = z_tabelaklientow(z_licznik); DBMS_OUTPUT.PUT_LINE(z_licznik. z_nazwafirmy); END LOOP; END; Wynik trzykrotnego wykonania powyższego bloku jest następujący: SQL>@plikiPLSQL\wywolajklienci.sql; Fetched 5 rows; Agrico Adamczyk Zenon Batimex Krakus Pamex PL/SQL procedure successfully completed. SQL>@plikiPLSQL\wywolajklienci.sql; Fetched 5 rows; Centrex KBX Krawczyk Marian Luciński Zbigniew Ratex PL/SQL procedure successfully completed. SQL>@plikiPLSQL\wywolajklienci.sql; Fetched 2 rows; Fabia Korab PL/SQL procedure successfully completed. Pakiety przeznaczone do seryjnego wykorzystania W języku PL/SQL można oznaczyć pakiet do wykorzystania seryjnego. Stan wykonania pakietu do wykorzystania seryjnego będzie utrzymywany tylko dla każdego wywołania bazy danych, a nie dla całej sesji. Pakiety tego typu deklaruje się za pomocą instrukcji o następującej składni: PRAGMA SERIALY_REUSABLE; 17

Instrukcję tę umieszcza się w nagłówku pakietu (można ją także powtórzyć w treści pakietu). Jeżeli zmodyfikuje się pakiet TrwaloscPakietu i uwzględni tę instrukcję, to wynik działania zmieni się. Zmodyfikowana wersja pakietu TrwaloscPakietu jest wtedy nastepująca: CREATE OR REPLACE PACKAGE TrwaloscPakietu AS PRAGMA SERIALLY_REUSABLE; -- Typ służący do zapisania tablicy identyfikatorów klientów TYPE t_tabelaklientow IS TABLE OF klienci.kod_klienta%type INDEX BY BINARY_INTEGER; -- Maksymalna liczba wierszy, która będzie zwrócona za każdym razem z_maksliczbawierszy NUMBER:=5; -- Procedura zwraca do z_maksliczbawierszy kodów klientów PROCEDURE ListaKlientow(p_TabelaKlienci OUT t_tabelaklientow, p_liczbawierszy OUT NUMBER); END TrwaloscPakietu; / CREATE OR REPLACE PACKAGE BODY TrwaloscPakietu AS PRAGMA SERIALLY_REUSABLE; -- Zapytanie do tabeli klienci. Mimo, iż jest ono globalne w stosunku do treści pakietu, będzie zresetowane -- po każdym odwołaniu do bazy danych, ponieważ pakiet ten został teraz oznaczony do seryjnego -- wykorzystania. CURSOR k_klienci IS SELECT kod_klienta FROM klienci ORDER BY nazwa_firmy; PROCEDURE ListaKlientow(p_TabelaKlienci OUT t_tabelaklientow, p_liczbawierszy OUT NUMBER) AS z_wykonano BOOLEAN:=FALSE; z_liczbawierszy NUMBER:=1; IF NOT k_klienci%isopen THEN OPEN k_klienci END IF; -- Kursor jest już otwarty, zatem można pobrać wiersze w liczbie do z_maksliczbawierszy WHILE NOT z_wykonano LOOP FETCH k_klienci INTO p_tabelaklienci(z_liczbawierszy); IF k_klienci%notfound THEN -- Brak więcej danych, zatem można zakończyć proces pobierania. CLOSE k_klienci; z_wykonano:=true; ELSE z_liczbawierszy:= z_liczbawierszy+1; IF z_liczbawierszy > z_maksliczbawierszy THEN z_wykonano:=true; END IF; END IF; END LOOP; -- Zwrócenie rzeczywistej liczby pobranych wierszy. p_liczbawierszy:=z_liczbawierszy 1; END ListaKlientow; END TrwaloscPakietu; 18

Wywołanie procedury ListaKlientow do seryjnego wykorzystania będzie teraz postaci: SQL>@plikiPLSQL\wywolajklienci.sql; Fetched 5 rows; Agrico Adamczyk Zenon Batimex Krakus Pamex PL/SQL procedure successfully completed. SQL>@plikiPLSQL\wywolajklienci.sql; Fetched 5 rows; Agrico Adamczyk Zenon Batimex Krakus Pamex PL/SQL procedure successfully completed. SQL>@plikiPLSQL\wywolajklienci.sql; Fetched 5 rows; Agrico Adamczyk Zenon Batimex Krakus Pamex PL/SQL procedure successfully completed. Należy zwrócić uwagę na różnice pomiędzy obiema wersjami. Ta, która nie jest przeznaczona do seryjnego wykorzystania, utrzyma swój stan dla różnych odwołań do bazy danych, podczas gdy stan (a zatem także wynik działania) wersji do seryjnego wykorzystania jest zerowany za każdym wywołaniem. Różnice pomiędzy wersjami pakietów zestawiono w poniższej tabeli. Zastosowanie pakietów wykorzystywanych seryjnie oszczędza pamięć, ale stan pakietów jest zerowany za każdym razem. Pakiety oznaczone do seryjnego wykorzystywania Stan wykonania jest przechowywany w pamięci wspólnej i zwalniany po każdym odwołaniu do bazy danych. Maksymalny rozmiar wykorzystywanej pamięci jest proporcjonalny do liczby użytkowników korzystających z pakietu w tym samym czasie. Pakiety, których nie można wykorzystywać seryjnie Stan wykonania jest przechowywany w pamięci procesów i pozostaje tam na czas trwania sesji z bazą danych. Maksymalny rozmiar wykorzystywanej pamięci jest proporcjonalny do liczby zarejestrowanych użytkowników w danym czasie, która zwykle jest znacznie większa od liczby użytkowników korzystających z pakietu. Zależności stanu wykonania pakietu Oprócz zależności pomiędzy obiektami składowymi mogą także istnieć zależności pomiędzy stanem pakietu a blokami anonimowymi. Rozważmy następujący pakiet: 19

CREATE OR REPLACE PACKAGE ProstyPakiet AS z_zmiennaglobalna NUMBER:=1; PROCEDURE UaktualnijZg; END ProstyPakiet; / CREATE OR REPLACE PACKAGE BODY ProstyPakiet AS PROCEDURE UaktualnijZg AS z_zmiennaglobalna:=5; END UaktualnijZg; END ProstyPakiet; / Pakiet ProstyPakiet zawiera zmienną globalną ZmiennaGlobalna. Można założyć, że utworzono pakiet ProstyPakiet w jednej sesji z bazą danych. Następnie w innej sesji wywołano procedurę ProstyPakiet.UaktualnijZg w sposób zaprezentowany poniżej: ProstyPakiet.UaktualnijZg; END; Teraz w sesji pierwotnej ponownie zostanie utworzony pakiet ProstyPakiet, poprzez ponowne uruchomienie powyższego skryptu tworzącego. Na koniec, ponownie zostanie uruchomiony blok anonimowy w sesji 2. W takiej sytuacji powstaną następujące wyniki: * BŁĄD w linii 1: ORA-04068: istniejący stan pakietów został odrzucony ORA-04061: istniejący stan package "UZYTK.PROSTYPAKIET" nie został unieważniony ORA-04065: nie wykonano, zmieniono lub usunięto package "UZYTK.PROSTYPAKIET" ORA-06508: PL/SQL: Nie można znaleźć wywoływanej jednostki programu. ORA-06512: przy linia 2 Wykres zależności dla powyższej sytuacji jest następujący: anonimowy blok ProstyPakiet z_zmiennaglobalna UaktualnijZg Anonimowy blok zależy od pakietu ProstyPakiet i zawiera kopię zmiennej z_zmiennaglobalna fazy wykonania Rysunek. Globalne zależności pakietu Blok anonimowy zależy od pakietu ProstyPakiet w takim samym sensie jak wcześniej. Jest to zależność fazy kompilacji - w tym sensie, że jest określana podczas pierwszej kompilacji anonimowego bloku. Jest to jednak także zależność fazy wykonania od zmiennej pakietu, ponieważ każda sesja posiada swoje własne kopie zmiennych pakietu. A zatem w momencie ponownej kompilacji pakietu ProstyPakiet są wykonywane działania wynikające z zależności fazy wykonania, czyli unieważnienie bloku i zgłoszenie błędu ORA-04068. 20