piątek, 9 października 2009

Resource Manager

Ostatnio wpadła mi do rąk książka przygotuwująca do OCP :

Bob Bryla "Administration II Exam Guide"

W rozdziale przedstawiającym użycie Resource Manager, znajduje się przykład stworzenie dość prostego planu przydziału zasobów. Tworzone są dwie grupy konsumenckie, przydzielani pewni użytkownicy bazy danych. Do planu dodawane są trzy "dyrektywy" : jak między te grupy przydzielić procesor oraz jaki maksymalny stopień równoległości transakcje przez nich inicjalizowane mogą posiadać.

Script w wesji dla konsoli sh znajduje się poniżej:

#!/bin/sh

ORACLE_HOME=/oracle
ORACLE_SID=ORCL;

sqlplus / as sysdba <

EXECUTE DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
EXECUTE DBMS_RESOURCE_MANAGER.CREATE_PLAN( PLAN => 'DEVELOPERS', -
COMMENT => 'Plan developerski');

EXECUTE DBMS_RESOURCE_MANAGER.SET_INITIAL_CONSUMER_GROUP('DEV_USER','ONLINE_DEVELOPERS');
EXECUTE DBMS_RESOURCE_MANAGER.SET_INITIAL_CONSUMER_GROUP -('BATCH_USER','BATCH_DEVELOPERS');

EXECUTE DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE( PLAN=>'DEVELOPERS', -
GROUP_OR_SUBPLAN => 'ONLINE_DEVELOPERS', -
COMMENT =>'Przydzial zasobów dla aktywnych developerów', -
CPU_P1 => 80, -
CPU_P2 => 0, -
PARALLEL_DEGREE_LIMIT_P1 => 10);

EXECUTE DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE( PLAN=>'DEVELOPERS', -
GROUP_OR_SUBPLAN => 'BATCH_DEVELOPERS', -
COMMENT =>'Przydzial zasobów dla batchowych developerów', -
CPU_P1 => 20, -
CPU_P2 => 0, -
PARALLEL_DEGREE_LIMIT_P1=>5);

EXECUTE DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE( PLAN=>'DEVELOPERS', -
GROUP_OR_SUBPLAN => 'OTHER_GROUPS', -
COMMENT =>'Przydzial zasobów dla pozostałych', -
CPU_P1 => 0, -
CPU_P2 => 100, -
PARALLEL_DEGREE_LIMIT_P1=>5);

BEGIN
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
EXCEPTION
WHEN OTHERS THEN
DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
END;
/

EOF



Kod ten działa (!). Idąc dalej, aktywując go poleceniem

ALTER SYSTEM SET resource_manager_plan='DEVELOPERS' scope=memory;

nie zauważamy żadnych problemów. Ale gdy połączy się użytkownik BATCH_USER lub DEV_USER zauważmy, że UWAGA !!! obaj są przypisani do grup OTHER_GROUPS !!!

A więc w czym tkwi problem ?

Otóż, autora zapomniał dodać uprawnienia użytkownikom do przełączenia do ich grup !

Przed instrukcją EXECUTE DBMS_RESOURCE_MANAGER.SET_INITIAL_CONSUMER_GROUP('DEV_USER','ONLINE_DEVELOPERS') należy dodać oto taki kawałek kodu PL/SQL:



EXECUTE DBMS_RESOURCE_MANAGER_PRIVS.
GRANT_SWITCH_CONSUMER_GROUP( GRANTEE_NAME => 'DEV_USER', CONSUMER_GROUP => 'ONLINE_DEVELOPERS',GRANT_OPTION=>FALSE);

EXECUTE DBMS_RESOURCE_MANAGER_PRIVS.
GRANT_SWITCH_CONSUMER_GROUP( GRANTEE_NAME => 'BATCH_USER', CONSUMER_GROUP => 'BATCH_DEVELOPERS',GRANT_OPTION=>FALSE);

BEGIN
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
EXCEPTION
WHEN OTHERS THEN
DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
END;
/


Być może autor zapomniał o tym nieświadomie. Jednakże zanim stwierdzimy, że kod z książek poświęcony technologią ORACLE jest poprawny, sprawdźmy to.

sobota, 25 lipca 2009

ORA-3136

Po podniesieniu wersji bazy z wersji wczesniejszej niż 10.2.0.1 do wersji 10.2.0.1
można zauważyć sporo wpisów w pliku alert.log postaci:

WARNING: inbound connection timed out (ORA-3136)

Jak podaje dokumentacja przyczyn może być wiele, chociaż jedna wydaje się najbardziej prawdopodobna. W ustawieniach listenera oraz protokoł SQL*Net istnieją dwa parametry:

SQLNET.INBOUND_CONNECT_TIME ( w pliku sqlnet.ora )
INBOUND_CONNECT_TIMEOUT_LISTENER ( w pliku listener.ora )

Co one oznaczają:

SQLNET.INBOUND_CONNECT_TIME - czas w sekundach, w których użytkownik musi poprawnie się zidentyfikować w bazie danych. Należy zwrócić uwagę, że nie polega to tylko i wyłącznie na odczytaniu zaszyfrowanego hasła z perspektyw systemowych, deszyfrowaniu go i porównaniu z prowadzonym. W bazie danych wykonywnych jest szereg zapytań i zmian w sesji użytkownika. Wartosć zero 0, że czas ten jest nieskończony.

INBOUND_CONNECT_TIMEOUT_LISTENER - czas w sekundach, w których użytkownik musie się zidentyfikować i wykonać poprawne połączenie do bazy danych. Podobnie, wartosć 0 oznacza, że czas ten jest nieskończony.

W wersjach wczesniejszych oba parametry są domyslnie ustawione na 0.
W wersji 10.2 i pozniejszych domyslne wartosći tych parametrów wynoszą 60.

Jeżeli ta wartosć nie jest wystarczająca to należy ją zwiększyć,np.:


SQLNET.INBOUND_CONNECT_TIMEOUT = 200 (w sqlnet.ora)
INBOUND_CONNECT_TIMEOUT_LISTENER = 200 (w listener.ora)


Inne możliwe przyczyny:
- przeciążenie serwera ( za mała wartosć SHARED POOL ? )
- problemy z siecią ( tutaj jest konieczna konsultacja z administratorami sieciowymi)

Można też spróbować włączyć sledzenie protokołu SQL*NET ( trace ). Należy zrobić to w sqlnet.ora. Przykład włączenia trace'a:


TRACE_LEVEL_CLIENT=admin
TRACE_LEVEL_SERVER=admin
TRACE_UNIQUE_CLIENT=on
TRACE_DIRECTORY_SERVER=$ORACLE_HOME/trace
TRACE_DIRECTORY_SERVER=$ORACLE_HOME/trace
TRACE_TIMESTAMP_CLIENT=on
TRACE_TIMESTAMP_SERVER=on


Jedna uwaga: Pliki sledzenia szybko przyjmują duże rozmiary ( rzędu MB ). Dlatego zaleca się zebranie ich pewnej liczby a następnie wyłączenia sledzenia.

Przydatna dokumentacja ( numery dokumentów w Oracle Metalink):

345197.1
465043.1
730066.1

piątek, 24 lipca 2009

O grafach w Oracle Spatial słów kilka

Zazwyczaj grafy i związane z nimi implementacja struktur danych i algorytmów kojarzy się nam zazwyczaj z warstwą aplikacyjną systemu. Systemowy bazodanowe obecnie umożliwiają przechowywanie tych struktur w postaci relacyjnej. Związane jest z rozwojem systemów GIS ( Geography Information Systems ) , czyli polskie SIP. Chciałbym omówić jak jest to robione w Oracle 10g database.

Obiekty do analizy (Java)

NODES

LINKS

PATHS

PLINKS

SDO_NET




Cała architektura może być podzielona na dwa zasadnicze segmenty. Pierwszy segment to część bazodanowa. Cała informacja przechowywana jest w tabelach. Na rysunku przedstawiono cztery tabele opisujące sieć. Zasadniczo wymagane są dwie : Nodes oraz Links. Pozostałe tabele umożliwiają przechowywanie analiz przeprowadzanych na sieci – w najprostszym przypadku wyliczone ścieżki.

Drugi segment to część analityczna. Sieć zostaje załadowana do aplikacji -> obszar Network. Jeżeli chcemy przeprowadzić jakieś operacje na sieci dotyczące , np. wyszukiwania najbliższych sąsiadów danego wierzchołka musimy wywołać statyczne funkcje klasy NetworkManager. W przypadku modyfikowania struktury sieci (dodawanie, usuwanie i modyfikacja jej elementów) posługujemy się funkcjami klasy NetworkFactory.



Do przeprowadzania analiz w sieci można użyć dwóch interfejsów programistycznych: Javy lub PL/SLQ’a. Z racji tego, że większość analiz jest przeprowadzanych w warstwie aplikacyjnej, właściwsze będzie omówienie możliwości interfejsu programistycznego z poziom Javy.

Interfejs programistyczny został podzielony ze względu na funkcjonalność na dwie części:

- obliczenia i analizy na istniejącej sieci -> klasa NetworkManager

Znajdowanie najkrótszej ścieżki między dwoma obiektami(wierzchołkami) w sieci ( wersje używają algorytmu Dijkstry lub algorytmu A* ).

Znajdowanie najbliższych sąsiadów dla danego wierzchołka. Działa podobnie jak operator przestrzenny SDO_NN, z tą różnicą że drogę możemy pokonywać tylko po krawędziach sieci. Znajdowanie wierzchołków znajdujących się w określonej odległości od wierzchołka startowego
Rozwiązanie problemu komiwojażera, czyli znalezienie optymalnej ścieżki przy zadanej liście wierzchołków, które należy odwiedzić Obliczanie Minimalnego Drzewa Rozpinającego ( ang. Minimum Cost Spaning Tree) dla sieci