Blog programisty w Oracle PL/SQL

Jest to blog eksperymentatora programisty w PL/SQL dla Oracle. Wszystkie kody tutaj zamieszczone mogą być dowolnie wykorzystywane i zmieniane. A jeśli Ktoś z Gości znajdzie błąd, będę niezwykle wdzięczny...
Zapisz

Szukaj na tym blogu

czwartek, 17 lutego 2011

Prosta namiastka mutexu na bazie dla funkcjonalności PL/SQL

CEL:
Chcemy, aby na bazie , dla pewnej grupy funkcjonalności  PL/SQL była uruchomiona w danej chwili co najwyżej jedna instancja przetwarzania…

Propozycja rozwiązania:
  Wykorzystamy pakiet  SYS.DBMS_APPLICATION_INFO ( ma GRANT EXECUTE TO PUBLIC), tabelę TBL_MUTEX , w której będziemy zapisywać parametryzację orazpakiet PCKG_MUTEX

Wymagane uprawnienia:
CREATE TABLE, CREATE PROCEDURE,  odczyt z perspektywy systemowej v$session

Elementy DDL:
Szczegóły implementacyjne:
CREATE TABLE TBL_MUTEX
(
  PROCESS_NAME         VARCHAR2(32 CHAR)        NOT NULL,
  DESCRIPTION          VARCHAR2(50 CHAR)  NOT NULL,
  F_EXCLUSIVE_RUNNING  VARCHAR2(1 CHAR)    DEFAULT 'Y'  NOT NULL
);

CREATE UNIQUE INDEX IDX_MUTEX ON TBL_MUTEX
(PROCESS_NAME);


ALTER TABLE TBL_MUTEX ADD (
  CHECK ("F_EXCLUSIVE_RUNNING" IN('Y','N')),
  CONSTRAINT PK_MUTEX
 PRIMARY KEY
 (PROCESS_NAME));


----------------- PAKIET ---------


CREATE OR REPLACE PACKAGE PCKG_MUTEX IS
 PROCEDURE PDB_SetMutex(pc_MutexName VARCHAR2);
 PROCEDURE PDB_ClearMutex;
 FUNCTION  FDB_IsMutexUsed(pc_MutexName VARCHAR2) RETURN NUMBER;
 FUNCTION  FDB_GetMutexInfo(pc_MutexName VARCHAR2)  RETURN VARCHAR2;


  PRAGMA RESTRICT_REFERENCES (FDB_IsMutexUsed, WNDS, RNPS);
  PRAGMA RESTRICT_REFERENCES (FDB_GetMutexInfo, WNDS, RNPS);
END;
/
CREATE OR REPLACE PACKAGE BODY PCKG_MUTEX IS

CURSOR C_Mutex(pc_MutexName VARCHAR2, pn_CheckSID NUMBER) IS
SELECT
         'Na komputerze ' || TRIM(s.terminal) || ' użytkownik '||
         TRIM(s.osuser) || ' zalogowany do Oracle jako ' || s.username ||' korzysta z aplikacji ' ||
          LTRIM(RTRIM(s.module)) AS Line
FROM v$session s
   WHERE
      (s.username IS NOT NULL)
     AND (NVL (s.osuser, '!!!!!!!!') NOT IN ( 'SYSTEM', 'SYS'))
     AND (s.TYPE <> 'BACKGROUND')
     AND ((SID <> sys_context('userenv','sessionid') AND pn_CheckSID >0)
        OR pn_CheckSID =0 )
     AND s.module  =
     ( SELECT process_name FROM TBL_MUTEX WHERE F_EXCLUSIVE_running = 'Y' AND process_name = pc_MutexName
     )
;
----------------------------------
 FUNCTION  FDB_IsMutexUsed(pc_MutexName VARCHAR2) RETURN NUMBER
 IS
  BEGIN
   FOR EL IN C_Mutex(pc_MutexName, 1)
     LOOP
        RETURN 1;
     END LOOP;
    RETURN 0;
  END;
PROCEDURE PDB_SetMutex(pc_MutexName VARCHAR2)
 IS
  BEGIN
    IF   FDB_IsMutexUsed(pc_MutexName) =1 THEN
     RAISE_APPLICATION_ERROR(-20100, FDB_GetMutexInfo(pc_MutexName) );
    END IF;
    DBMS_APPLICATION_INFO.SET_MODULE(pc_MutexName, NULL);
  END;
----------------------------------
 PROCEDURE PDB_ClearMutex
  IS
  BEGIN
    DBMS_APPLICATION_INFO.SET_MODULE( NULL, NULL);
  END;

 FUNCTION  FDB_GetMutexInfo(pc_MutexName VARCHAR2)  RETURN VARCHAR2
 IS
  BEGIN
   FOR EL IN C_Mutex(pc_MutexName,0)
     LOOP
       RETURN EL.LINE;
     END LOOP;
    RETURN NULL;
  END;
END;
/

środa, 12 stycznia 2011

Semantyka bajtowa i znakowa a poprawność kodu

Jest to temat szeroki... Należy zacząć od tego, że problem zależy od

  • ustawień bazy - jeśli parametr NLS_LENGTH_SEMANTICS ma na poziomie bazy wartość CHAR, i nie jest przesłaniany w sesjach, to problem nie występuje, jeśli ma wartość BYTE to jest to źródło wielu dokuczliwych kłopotów, występujących przy masowym przetwarzaniu lub sporadycznie przy ręcznym procesowaniu
  • definicji tabel - należy definiować kolumny literałów w tabelach jako NAZWISKO VARCHAR2(50 CHAR), a nie NAZWISKO VARCHAR2(50 ) lub o zgrozo NAZWISKO VARCHAR2(50 BYTE). Niektóre narzędzia CASE nie są świadome tego problemu
  •  definicji zmiennych znakowych w kodzie - przy definicji zmiennych należy w sposób jawny ( tylko spacja i cztery dodatkowe litery CHAR) deklarować semantykę znakową
Ustawmy sobie parametr na poziomie sesji
ALTER SESSION SET NLS_LENGTH_SEMANTICS = BYTE
i wykonajmy poniższy blok
DECLARE 
   vc_zmienna VARCHAR(3  );
BEGIN
   vc_zmienna :='ość';
END;
otrzymamy wyjątek::
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at line 4
bo

 SELECT vsize('ość') FROM dual
zwraca 7 (funkcja vsize zwraca wielkość zmiennej w bajtach)..
Okazuje się, że w przypadku ustawień mojej bazy polskie ogonki kodowane są na 3 bajtach, na innych bazach z innymi ustawieniami NLS może to być inna wartość..
Dopiero kiedy poprawimy   wartość wielkość zmiennej vc_zmienna na wartość zwracaną przez funkcję vsize, blok zadziała poprawnie..
Powyższy blok zadziała poprawnie, jeśli parametr NLS_LENGTH_SEMANTICS będzie mieć wartość CHAR po wykonaniu instrukcji
ALTER SESSION SET NLS_LENGTH_SEMANTICS = CHAR
Poprawmy blok

DECLARE 
   vc_zmienna VARCHAR(3 CHAR );
BEGIN
   vc_zmienna :='ość';
END;
Powyższy bok zawsze zadziała poprawnie na bazach o różnch ustawieniach i tak też należy kodować..
Opisywany problem jest szczególnie dokuczliwy przy przenoszeniu danych pomiędzy bazami o różnych ustawieniach semantyki oraz dystrybucji kodu po różnych firmach.. Często pierwszym ratunkiem jest bezmyślne zwiększanie wielkości pól, aż dana funkcjonalność dobrze zadziała

sobota, 8 stycznia 2011

Czy to Java czy C - porównanie wydajności procedur zewnętrznych w Windows

Całość eksperymentów przeprowadziłem na Oracle 11g 64 bit zainstalowanym na Windows 7.
Napisałem niezwykle prostą funkcję w C

int _stdcall sum(int x , int y)
{
return x+y;
}

Korzystając z kompilatora Microsoft Visual C++ opakowałem powyższą w bibliotekę DLL  na platformę x64( 32 bitowe biblioteki nie współdziałają z Oracle 64 bit), wygenerowałem plik test_dll.dll.
Kilka chwil zajęło zmuszenie listenera do współpracy, ale  przy odrobinie dobrych chęci nie jest to trudne. Natępnie podłączyłem zewnętrzny kod:
CREATE OR REPLACE LIBRARY MyC_LIB 
  AS 'D:\Projects\CPP\test_dll\Release\test_dll.dll';

CREATE OR REPLACE FUNCTION test_CSUM
(x BINARY_INTEGER, y BINARY_INTEGER
RETURN BINARY_INTEGER
AS LANGUAGE C
LIBRARY MyC_LIB
NAME "sum";

Następnie wykonałem zapytanie:
 
SELECT SUM(TEST_CSUM(2,1)) /3 FROM ALL_TAB_COLS
 Wynik z zapytania zwraca liczę rekordów z view: wynik 90451 rekordów został otrzymany w czasie 30 sekund. Wychodzi około 3 tysięcy wywołań rekordów na sekundę ..
Pokombinujmy, jeśli do definicji funkcji dodamy modyfikator DETERMINISTIC , to czas wykonania spadnie do 1s. Ale:
  • funkcje deterministyczne to szczególny przypadek i dosyć rzadki w przyrodzie
  • funkcje deterministyczne warto stosować, jeśli zbiór parametrów wejściowych jest niewielki, dla obliczeń numerycznych dla co najwyżej kilkunastotysięcznego zbioru parametrów wejściowych
  •  Oracle w przypadku zewnętrznych procedur nie zwróci nam uwagi, że wynik funkcji zależy od daty lub generatora liczb losowych
Mogłoby się wydawać, że natywne niskopoziomowe biblioteki DLL powinny być niezwykle szybkie, a jednak nie nadają się do wykorzystania w przypadku zapytań obrabiających  duże zbiory danych...

Wykonajmy analogiczny eksperyment z Java...
public class SumTest {
 public static int sum (int a, int b)
{
    return a+b;
    }
} 

Załadujmy klasę:
loadjava -thin -user  user/pwd@test d:\PLSQL\SumTest.java 
Dla Oracle 64 bit dla Windows loadjava działa tylko w wersji thin..

Kompilujemy pakiet i mapujemy funkcję

alter java class user."SumTest" compile;

CREATE OR REPLACE FUNCTION user.test_jsum
(a NUMBER, b Number)
RETURN NUMBER
AS
LANGUAGE JAVA
NAME 'SumTest.sum
(int, int) return int';


I sprawdzenie

SELECT SUM(TEST_JSUM(2,1)) /3 FROM ALL_TAB_COLS
Wynik  90451 rekordów pojawił się po 5 sekundach.. Jest pięć razy szybciej około 18 tysięcy rekordów na sekundę.. Dla niewielkich zbiorów danych można ścierpieć...
 Podsumowując: do przetwarzanie  masowego wielkich zbiorów danych funkcje zewnętrzne się nie nadają..  Najlepiej sprawdzają się w rzadkich i nieczęsto stosowanych przypadkach