[ Pobierz całość w formacie PDF ]
Informacje o aktualnej architekturze pracy instancji można uzyskać na kilka sposobów.
Pierwszy z nich wymaga doÅ‚Ä…czenia si¹ do bazy danych z poziomu SQL*Plus jako
użytkownik z uprawnieniami DBA. Nast¹ pnie należy wydać polecenie
. Jeżeli nie skonfigurowano instancji w architekturze współdzielonych
procesów usÅ‚ugowych, wówczas wartość parametru inicjujÄ…cego b¹ dzie
pusta, jak przedstawiono w poniższym listingu. Parametry i
przyjmują w takim przypadku wartości domyślne.
W drugim sposobie wykorzystywane jest polecenie , jak podano
poniżej. W poniższym listingu znajduje si¹ przykÅ‚adowy opis czterech ekspedytorów
o nazwach D000, D001, D002, D003. Pierwszy z nich obsługuje 2 połączenia ("D000"
ustalono:2). Kolejne 2 połączenia są obsługiwane przez procesy dedykowane ("DEDI-
CATED" ustanowiono:2).
Rozdział 3. f& Procesy Oracle komunikacji sieciowej 67
W systemach Unix wydanie polecenia (np. ) umożliwia wyświetlenie proce-
sów systemowych. Instancja w architekturze współdzielonych procesów usługowych
b¹ dzie posiadaÅ‚a procesy ekspedytorów o nazwach ora_dxxx_SID.
Kolejnym zródłem informacji na temat architektury współdzielonych procesów usługo-
wych sÄ… dynamiczne tabele systemowe, m.in. V$DISPATCHER i V$SHARED_SERVER
por. [O9Ref]. Pierwsza z nich udost¹ pnia nazwy i parametry ekspedytorów, a druga
nazwy i parametry współdzielonych procesów usługowych. Przykładowe zapyta-
nie do V$DISPATCHER i jego wynik przedstawiono poniżej.
Atrybut name oznacza nazw¹ ekspedytora, network przechowuje parametry wyspecy-
fikowane w omówionej wcześniej sekcji , status przechowuje aktualny stan
pracy ekspedytora. status może przyjąć m.in. jednÄ… z nast¹ pujÄ…cych wartoÅ›ci: WAIT
ekspedytor oczekuje na żądanie połączenia, SEND ekspedytor wysyła wiadomość,
RECEIVE ekspedytor otrzymuje żądanie, CONNECT nawiązywane jest połą-
czenie z aplikacją użytkownika, DISCONNECT połączenie jest przerywane. Wartość
atrybutu CONF_INDX określa numer parametru inicjującego , który posłu-
żył do utworzenia ekspedytora. Ekspedytor utworzony na podstawie wartości pierw-
szego w kolejności parametru otrzymuje wartość równą 0, ekspedytor utworzony na
podstawie drugiego parametru otrzymuje wartość 1 itp. Powyższy wynik otrzymano
dla parametrów określonych w sposób przedstawiony poniżej.
68 Oracle. Projektowanie rozproszonych baz danych
ZarzÄ…dzanie parametrami
pracy instancji w architekturze
współdzielonych procesów usługowych
W czasie pracy instancji bazy danych można dynamicznie modyfikować liczb¹ dzia-
łających współdzielonych procesów usługowych i ekspedytorów. Służy do tego celu
polecenie . Przykładowo w Oracle9i za pomocą poniższego polecenia
aktualna liczba procesów usługowych ustalana jest na . We wcześniejszych wersjach
systemu należy zastąpić przez .
Liczb¹ i parametry pracy ekspedytorów modyfikuje si¹ w Oracle9i poleceniem:
We wcześniejszych wersjach systemu należy zastąpić przez .
Przykładowo, poniższe polecenie dodaje do systemu jeden ekspedytor o indeksie 3.
Dodany ekspedytor pojawia si¹ w systemie i jest widoczny za pomocÄ… V$DISPATCHER.
Rozdział 3. f& Procesy Oracle komunikacji sieciowej 69
Kolejne przykÅ‚adowe polecenie umożliwia usuni¹ cie ekspedytora o indeksie 3. Po jego
wykonaniu ekspedytor zostanie fizycznie usuni¹ ty z systemu z pewnym opóznieniem.
Wybór typu procesu usługowego
Jeżeli instancja pracuje w trybie współdzielonych procesów usługowych, wówczas
przez aplikacj¹ może zostać wskazane, czy do jej obsÅ‚ugi ma być wykorzystany dedy-
kowany proces usÅ‚ugowy, czy współdzielony. Wyboru tego dokonuje si¹ , konfiguru-
jąc plik tnsnames.ora. Opisany wcześniej parametr z wartością DEDICATE
lub SHARED steruje wyborem procesu usługowego. Poprzez wprowadzenie do pliku
tnsnames.ora dwóch różnych nazw usÅ‚ug, wskazujÄ…cych na t¹ samÄ… baz¹ danych, lecz
z różną wartością parametru , może być dokonany wybór procesu obsługujące-
go aplikacj¹ wÅ‚aÅ›nie przez wskazanie odpowiedniej usÅ‚ugi. PrzykÅ‚adowy fragment pliku
tnsnames.ora zawierajÄ…cy takÄ… konfiguracj¹ przedstawiono poniżej.
Jeżeli w pliku sqlnet.ora zostanie umieszczony parametr ,
wówczas dla wszystkich poÅ‚Ä…czeÅ„ aplikacji b¹ dÄ… alokowane procesy dedykowane, nawet
jeśli w definicji usługi parametr przyjmuje wartość SHARED. Brak parametru
lub wpis powoduje alokowanie pro-
cesów usługowych zgodnie z konfiguracją instancji i wartością parametru .
70 Oracle. Projektowanie rozproszonych baz danych
Wykrywanie nieaktywnych połączeń
Raz nawiÄ…zane poÅ‚Ä…czenie mi¹ dzy procesem usÅ‚ugowym a aplikacjÄ… wykorzystuje
zasoby systemowe. W przypadku zerwania połączenia z aplikacją, np. na skutek braku
połączenia sieciowego, awarii komputera użytkownika lub aplikacji, proces ją obsłu-
gujÄ…cy staje si¹ nieaktywny (ang. dead) i powinien zostać usuni¹ ty z systemu. Cz¹ sto
w przypadku tego typu awarii dane w bazie sÄ… blokowane przez transakcj¹ użytkow-
nika. Usuni¹ cie nieaktywnego procesu powoduje wycofanie transakcji i zwolnienie
wszystkich wykorzystywanych przez niÄ… blokad.
Proces testowania aktywności aplikacji użytkownika (ang. dead connection detection)
jest realizowany przez Oracle Net. Oprogramowanie to wysyła pakiety testowe za pomo-
cÄ… każdego z poÅ‚Ä…czeÅ„. Cz¹ stotliwość próbkowania jest okreÅ›lona parametrem kon-
figuracyjnym pliku sqlnet.ora. Jego wartość podaje si¹ w minutach.
Przykładowo, wpis oznacza próbkowanie co 10 minut. Jest to
wartość zalecana w dokumentacji Oracle [O9NAG]. W domyślnej konfiguracji plik
sqlnet.ora nie zawiera parametru , a wi¹ c nieaktywne poÅ‚Ä…czenia
nie sÄ… wykrywane.
[ Pobierz całość w formacie PDF ]