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

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