Zwiększanie wydajności Oracle WebDB część 1

Opracowanie to przeznaczone jest dla developerów wykorzystujących narzędzia Oracle oraz dla administratorów odpowiedzialnych za tworzenie i eksploatację aplikacji opartych o WebDB, czyli dla osób odpowiedzialnych za wydajność i jakość aplikacji Webowych.
Omówione to zostały:


  • Architektura i kluczowe elementy WebDB’s

  • Konfiguracja i strojenie aplikacji tworzonych w WebDB oraz stron Webowych w celu uzyskania maksimum wydajności

  • Strojenie aplikacji poprzez zmianę parametrów bazy i listenera

  • Sposoby przechodzenia z architektury dwuwarstwowej do trójwarstwowej

Do kogo adresowane jest to opracowanie?
Do wszystkich którzy próbowali już swoich sił w trudnej sztuce strojenia aplikacji, bez względu na efekty jakie uzyskali oraz dla tych, którzy nigdy tego nie robili i chcieliby dowiedzieć się na czym to polega w środowisku Webowym.

Architekura

WebDB składa się z trzech składników:


  • bazy danych zawierającej schematy WebDB

  • listenera

  • browsera

Wszystkie elementy aplikacji serwowanych przez WebDB składowane są w bazie danych. Dla zwiększenia wydajności możliwe jest umieszczenie listenera na oddzielnym komputerze tak, aby obciążenia żądaniami użytkowników nie przenosiły się bezpośrednio na szybkość wykonywania zapytań do bazy.
W takim przypadku połączenie pomiędzy komputerem pracującym jako listener WebDB i komputerem na którym pracuje baza danych odbywa się za pośrednictwem SQL*Net. Ilustracja poniżej przedstawia „klasyczną” architekturę w której listener i baza danych pracują na tej samej maszynie.

Architektura WebDB

Bazodanowe schematy niezbędne
do uruchomienia WebDB zakładane są podczas instalacji produktu.

Zawierają one wszystkie struktury przechowujące cały kod tego produktu. Kolejne schematy tworzone są podczas tworzenia nowych stron lub nowych aplikacji. Do głównego schematu aplikacji tworzone są dodatkowo automatycznie dwa schematy dodatkowe o nazwach uzupełnionych o końcówki _ADMIN i _PUBLIC. Dla przykładu jeśli stworzymy schemat o nazwie NOWY, automatycznie utworzone zostaną schematy NOWY_ADMIN i NOWY_PUBLIC:

  • NOWY jest właścicielem wszystkich obiektów aplikacji.

  • NOWY_ADMIN ma przywileje administratora do wszystkich obiektów schematu NOWY.

  • NOWY_PUBLIC ma jedynie prawo od odczytu i wykonywania tych obiektów.

Każda kolejna strona webowa stworzona w WebDB przechowywana będzie w tablicy WWV_MODULES$.

Instalacja

Instalacja WebDB jest stosunkowo prosta, choć niektóre parametry należy określić przed rozpoczęciem instalacji.

Przed rozpoczęciem instalacji należy upewnić się czy baza danych w której zamierzasz umieścić schematy WebDB ma parametr MAX_ROLES_ENABLED ustawiony na wartość co najmniej 25 ponieważ podczas instalacji kreowane będą nowe role bazodanowe. Jeśli parametr ten będzie ustawiony niepoprawnie, po instalacji nie będzie można zalogować się do bazy jako użytkownik SYS.
Podczas instalacji WebDB na NT upewnić należy się także, czy parametr rejestru windowsa LOCAL wskazuje na właściwą bazę danych. Sukces instalacji zależy również od poprawnego zdefiniowania aliasu TNS.

Wszystkie te problemy omijają użytkowników UNIXa, którzy przed instalacją poprawnie ustawią parametry środowiska.

Jeśli instalacja WebDB zakończyła się sukcesem jesteśmy gotowi do stworzenia pierwszej strony.
Pusta strona zajmuje około 15MB przestrzeni bazodanowej z czego około 11MB znajduje się w przestrzeni SYSTEM. Wynika to z tego, że każda strona zawiera dużą liczbę pakietów PL/SQLa będących obiektami schematu, który wybierzemy jako właściciela strony.
Próba stworzenia nowej strony w bazie o niewystarczającej ilości wolnego miejsca spowoduje zawieszenie się procesu kreacji. Dobrym pomysłem jest więc ustawienie na plikach przestrzeni SYSTEM parametru AUTOEXTEND ON.

Fizyczna lokalizacja

Wszystkie strony WebDB odwołują się do tabeli WWV_DOCUMENT. Tam właśnie przechowywane są informacje o wszystkich obrazach i polach umieszczonych na stronie. Wszystkie obiekty binarne wchodzące w skład strony przechowywane są kolumnie typu LONG RAW. Z tego właśnie powodu tabela ta przybierać może duże rozmiary dla przykładu 195 wierszy w tabeli WWV_DOCUMENT zajmować może w 71MB przestrzeni dyskowej.

W świetle tych informacji sensowne jest umieszczenie tabeli WWV_DOCUMENT w oddzielnej przestrzeni tabel. Aby to uczynić musimy:

  • Będąc zalogowanym jako właściciel schematu wyeksportować tabelę WWV_DOCUMENT.

  • Skasować tabele z bazy
    WWV_DOCUMENT.

  • Utworzyć ponownie strukturę tabeli
    wykorzystując polecenie podane
    poniżej (< YOUR_TBS> zastąpić
    należy odpowiednią nazwą
    przestrzeni tabel).


    CREATE TABLE WWV_DOCUMENT (

    NAME VARCHAR2 (64) NOT NULL,

    MIME_TYPE VARCHAR2 (48),

    DOC_SIZE NUMBER,

    CONTENT LONG RAW,

    CONSTRAINT WWV_DOCUMENT_PK

    PRIMARY KEY (NAME)

    USING INDEX PCTFREE 10

    STORAGE (INITIAL 10240 NEXT

    10240 PCTINCREASE 0)

    TABLESPACE TOOLS)

    TABLESPACE <YOUR_TBS>

    STORAGE (INITIAL 10240 NEXT 10240

    PCTINCREASE 0);

    /


    Jeśli tabela WWV_DOCUMENT osiągać będzie naprawdę duże rozmiary celowe będzie zastosowanie mechanizmów takich jak partycjonowanie czy indeksowanie. Następnymi krokami podnoszącymi szybkość wykonywania zapytań może być przeniesienie do oddzielnej przestrzeni tabel indeksów założonych na tabelach schematu WebDB. Służyć temu może polecenie:



    alter index <INDEX_NAME> rebuild tablespace <YOUR_INDEX_TBS>;



    Możesz po prostu wykreować instrukcję ALTER wykonując poniższą instrukcję, będąc zalogowanym jako właściciel schematu.



    Select 'alter '||index_name||'
    rebuild tablespace YOUR_INX_TBS;'

    from user indexes;

Strategia Rollback segmentów

Rollback segmenty jak wiadomo zapewniają spójność danych odczytywanych z bazy i zapewniają możliwość wykonania polecenia ROLLBACK. Rollback segmenty tworzone są wewnątrz bazy danych najczęściej w specjalnie na ten cel przeznaczonej przestrzeni tabel. Nieprawidłowa struktura segmentów wycofania powoduje zwiększenie liczby odczytów z dysku. Podobnie niekorzystny wpływ dla wydajności aplikacji ma zbyt mała liczba segmentów wycofania.
W dużych bazach danych preferowane jest umieszczanie segmentów wycofania w oddzielnej przestrzeni tabel, której pliki znajdują się na oddzielnym fizycznie dysku. Biorąc pod uwagę bazodanową aktywność aplikacji WebDB będziemy mieli do czynienia głównie z operacjami typu create/update/delete. Oczywiście najmniejsze obciążenie dla bazy występować będzie w przypadku gdy użytkownicy aplikacji będą jedynie przeglądać jej strony.
Mając to na uwadze rekomendowane jest stworzenie dużej ilości małych Rollback Segmentów z precyzyjnie określonymi parametrami INITIAL, NEXT i OPTIMAL. Na przykład:

Create rollback segment <seg_name>
tablespace <your_rbs_tbs>
storage (initial 10K next 10K optimal 20K)

Parametr OPTIMAL musi być ustawiony na wartość co najmniej równą sumie dwóch extentów. Tabela zamieszczona poniżej przedstawia proponowane ilości segmentów wycofania przy założeniu, że akceptowalna liczba transakcji na jeden segment wynosi 4.

Liczba
jednoczesnych transakcji
Zalecana
liczba Rollback Segment'ów
n < 16 4
16 <= n <
32
8
32 <= n n/4

Jeśli chcesz ustalić, ile segmentów wycofania, potrzebujemy należy będąc zalogowanym jako SYSTEM wykonać następujące zapytanie:


  1. select a. name, b. extents, b. rssize, b. xacts, b. waits, b. gets,
  2. optsize, status
  3. from v$rollname a, v$rollstat b
  4. * where a. usn = b. usn

NAME EXTENTS RSSIZE XACTS WAITS GETS OPTSIZE STATUS
------------- ------------- ------------- ------------- ------------- ------------- ------------- -------------
SYSTEM 2 100352 0 0 1652 102400 ONLINE
RO1 2 264192 0 2 34769 262144 ONLINE
RO2 2 264192 0 1 34964 262144 ONLINE
R03 2 264192 0 0 34721 262144 ONLINE
RO4 2 264192 0 1 34552 262144 ONLINE

Ważnymi kolumnami tej odpowiedzi są XACTS (Active Transactions) i WAITS. Podczas pracy aplikacji WebDB monitoringiem objąć należy parametr XACTS. Jeśli jego wartość regularnie przekracza wartość 1 lub parametr WAITS przekracza wartość 0 oznacza to konieczność zwiększenia liczby Segmentów ponieważ zmniejsza to prawdopodobieństwo występowania kolizji pomiędzy transakcjami.

Pamięć - ważny zasób

Ponieważ aplikacje WebDb zależą od współpracy z bazą danych, bardzo szybko okazuje się że pamięć serwera bazy jest jednym z najważniejszych zasobów. Strojenie zasobów pamięci serwera bazy jest bardzo szeroką dziedziną i nie czas tu i miejsce aby rozpisywać się na ten temat w szczegółach. Skoncentrujemy się więc na kilku najważniejszych parametrach. W bazach danych Oracle bardzo ważna rolę odgrywają parametry

DB_BLOCK_BUFFERS,
DB_BLOCK_SIZE,
SHARED_POOL_SIZE
i SORT_AREA_SIZE.

Aby sprawdzić jakie wartości przybierają te parametry w naszej bazie należy wykonać zapytanie:


  1. select name, value

  2. from v$parameter

  3. *where name in ('db_block_buffers', 'db_block_size', 'shared_pool_size', 'sort_area_size')

NAME VAUE
------------------------- -------------------------
shared_pool_size 13107200
db_block_buffers 3200
db_block_size 2048
sort_area_size 131072

DB_BLOCK_BUFFERS jest tu kluczowym parametrem. Podczas wykonywania procedur PL/SQLa wywoływanych przez aplikacje WebDB, to właśnie ten obszar pamięci wykorzystywany jest jako obszar roboczy. Jeśli parametr ten przyjmuje wartość zbyt małą zadanie to będzie miało zbyt mały obszar roboczy, przewymiarowanie tego parametru powoduje natomiast swappowanie pamięci, które może unieruchomić system operacyjny maszyny.
Fizyczny rozmiar zaalokowanej pamięci obliczyć można mnożąc db_block_buffers * db_block_size.
W naszym przypadku będzie to 3200*2048 = ((6553600/1024) /1024) = 6.25MB.
Generalną zasadą jest ustalanie wielkości tego obszaru pamięci na poziomie 25% ogólnego rozmiaru SGA.

Aby sprawdzić aktualne rozmiary SGA wykorzystujemy polecenie SHOW SGA.
SVRMGR> show sga

Total System Global Area 23002384
Fixed Size     48400
Variable Size     16326656
Database Buffers     6553600
Redo Buffers     73728

Po przeliczeniu mamy :

Całkowity rozmiar
System Global Area

23,002,384

% rozmiaru całkowitego

Fixed Size 48,400 0,21%
Variable Size 16,326,656 70,98%
Database Buffers 6,553,600 28,49%
Redo Buffers 73,728 0,32%

Jak widać parametry używanej przez nas bazy danych są ustawione do pracy z aplikacjami typu OLTP i WebDB. Jeśli chcemy jeszcze coś ulepszyć możemy ustawić parametr DB_FILE_MULTIBLOCK_READ_COUNT na wartość 32 co powinno zrekompensować niewielki rozmiar bloku pamięci (2KB).

Podczas eksploatacji aplikacji istotną rolę dla wydajności ma określenie, jaki procent zapytań do bazy znajduje odpowiedzi w cachu pamięci a ile wymaga odwołań do dysku. Aby to sprawdzić zadajemy bazie pytanie o wskaźnik trafień w dane z cacha.:


  1. select (1- (sum (decode (name, 'Physical reads', value, 0)) /

  2. (sum (decode (name, 'db block gets', value, 0)) +

  3. sum (decode (name, 'consistent gets', value, 0)))))

  4. *100 "DB Block Buffers Hit Ratio"

  5. * from v$sysstat

DB Block Buffers Hit Ratio
-------------------------
97.1411

SHARED_POOL_SIZE jest obszarem pamięci zaalokowanym do przechowywania danych ze słownika bazy oraz współdzielonych zapytań SQLa. Obszar ten wykorzystywany jest kilkakrotnie podczas wykonywania zapytania. Wskaźnikiem optymalnego ustawienia rozmiaru tego obszaru jest uzyskanie współczynnika DB Data Dict Cache Hit Rate na poziomie 95%. Pamiętać jednak należy że wskaźnik ten przyjmuje wiarygodne wielkości dopiero po pewnym czasie pracy bazy.

Parametr ten określi zapytanie:


  1. select ( (1- (sum (getmisses) /

    (sum (gets) + sum (getmisses))))

    * 100) "Data Dict Cache Hit Rate"

  2. from v$rowcache

  3. * where gets + getmisses <> 0

Data Dict Cache Hit Rate
-------------------------
99,369167

Z czysto fizycznego punktu widzenia parametr SHARED_POOL_SIZE istotny jest o tyle, że jego zbyt niska wartość może spowodować niepoprawne zakończenie instalacji WebDB.

Jeśli spotka nas właśnie taka przykra niespodzianka, musimy usunąć ręcznie użytkownika WEBDB poleceniem
DROP USER WEBDB CASCADE.

Konfiguracja listenera

Po szczęśliwym zakończeniu instalacji Oracle WebDB, czeka nas konfiguracja listenera oraz PL/SQL Gateway. Ustawienia Listenera dotyczyć mogą mapowania katalogów, typów MIME oraz adresów URL stron domowych WebDB.

Plik konfiguracyjny zawierający wszystkie te informacje nosi nazwę wdbsvr. cfg i zlokalizowany jest w katalogu [ORACLE_HOME][WEBDB]listenercfg.

Ustawienia WebDB PL/SQL Gateway zawierają możliwość zdefiniowania Database Access Descriptor (DAD) dla każdej instancji bazy danych wykorzystywanej przez aplikacje WebDB.

Plik parametrów PL/SQL Gateway nosi nazwę wdbsrv. app.
Aby dokonać konfiguracji Listener lub PL/SQL Gateway należy wybrać odpowiedni link na stronie domowej WebDB. Można też tego dokonać wybierając bezpośrednio odpowiedni adres


http://servername:port/admin_/listener.htm

lub

http://servername:port/admin_/gateway.htm

Możliwe jest skonfigurowanie w ramach WebDB wielu wirtualnych serwerów oraz wielu instancji listenera pracujących na tej samej maszynie. Najprostszym sposobem uruchomienia wielu instancji listenera jest użycie linii komend. Poniższy przykład ilustruje uruchomienie dwóch instancji listenera połączonych z adresami www.oracle.com i web.oracle.com:

wdblsnr-console www.oracle.com 80 start

wdblsnr-console web.oracle.com 80 start

Obie instancje listenera pracować będą z tymi samymi ustawieniami ponieważ uruchomione zostały z tą samą wartością zmiennej środowiskowej WV_GATEWAY_CFG która wskazuje na umiejscowienie pliku konfiguracyjnego.

W WindowsNT Listener WebDB zarządzany jest przez panel sterowania usług który odczytuje wartość zmiennej WV_GATEWAY_CFG. Aby uniezależnić się od tego mechanizmu i umożliwić zindywidualizowanie konfiguracji wielu instancji listenera, możemy wykorzystać skrypt ustawiający różne lokalizacje plików konfiguracyjnych. Oto przykład takiego skryptu startującego dwa listenery:



SET WV_GATEWAY_CFG=D: orant

listenercfgwdbsvr. app

start wdblsnr-console www.oracle.com 80 start

SET WV_GATEWAY_CFG=D: orant

listenercfgwdbsvr2. app

start wdblsnr-console web.oracle.com 80 start

Skrypt taki można uruchamiać podczas startu Windows umieszczając w jego rejestrze następujący zapis:



HKEY_LOCAL_MACHINESOFTWARE
MicrosoftWindowsCurrentVersionRun

Możliwe jest również ręczne startowanie i zatrzymywanie procesów listenera wykorzystując linię komend. Jest to w zasadzie nieuniknione w przypadku podnoszenia większej liczby instancji listenera.

Aby uruchomić lub zatrzymać instancję listenera w Windows NT wydać należy następujące polecenie:


wdblsnr-console host port start

wdblsnr-console host port stop

Aby uruchomić lub zatrzymać instancję listenera WebDB na Solarisie polecenia te mają następującą postać:


wdbstart host port start

wdbstart host port stop

Ustawienia konfiguracyjne takie jak LD_LIBRARY_PATH, WV_GATEWAY permanentnie zmienić można edytując plik wdbstart.

Pełną kontrolę nad parametrami listenerów i WebDB gateway daje edycja plików konfiguracyjnych wdbsvr. app i wdbsvr. cfg, które znaleźć można w następujących katalogach:

Plik Windows NT UNIX
Oracle WebDB Listener    
wdbsvr.app %ORACLE_HOME%listenercfg $ORACLE_HOME/WEBDB/LISTENER/CFG
Oracle PL/SQL Gateway    
wdbsvr.cfg C:ORACLE_HOMElistenercfg $ORACLE_HOME/WEBDB/LISTENER/CFG

  • Aby uaktywnić ustawienie
    upewnij się czy nie poprzedza
    go znak średnika. Średnik na
    początku linii oznacza linię
    komentarza.

  • Pliki konfiguracyjne zorganizowane
    są w sekcje oznaczone nawiasami kwadratowymi [ ].

Wybrane parametry LISTENERA

[WVGATEWAY]

Oznacza początek i koniec sekcji
WebDB gateway.

TimingsTable

Nie używany

DefaultDAD

Określa ścieżkę wskazującą na stronę domową WebDB. Jest to parametr szczególnie ważny dla stron
generowanych dynamicznie
przez procedury PL/SQLa.
Wartość domyślna parametru
to WebDB

Administrators

Pozwala określać użytkowników
którzy będą mieli dostęp do stron
administracyjnych WebDB
(gateway. htm, listener. htm).
domyślną wartością jest tu dostęp
dla wszystkich (all). Aby ograniczyć
dostęp do list jednoznacznie
zidentyfikowanych użytkowników
należy wpisać ich nazwy oddzielając je przecinkami.

Na przykład:

administrators = user1, user2

AdminPath

Lokalizacja katalogu zawierającego pliki konfiguracyjne WebDB
gateway.
Wartość domyślna parametru to
/admin_/

[DAD_WebDB]

Oznacza początek i koniec sekcji
definiującej Database Access
Descriptor (DAD)
Wartość domyślna parametru to
WebDB

password

Dotyczy hasła konta w bazie danych Oracle. Domyślnie podczas instalacji hasło to ustawione jest na wartość
ăWebDBÓ ale można zmienić ją
pisząc nową wartość w tym właśnie parametrze.
Pamiętać należy że w bazie
powinien istnieć użytkownik
o nazwie utworzonej przez
połączenie nazwy DAD i końcówki _PUBLIC. Umożliwi to dostęp do
stron WebDB bez jawnego
logowania się do bazy.

Username

Dotyczy hasła konta w bazie danych
Oracle. Domyślnie podczas instalacji
nazwa użytkownika ustawiana jest
na wartość ăWebDBÓ ale można
zmienić jej pisząc jego nową wartość
w tym właśnie parametrze.
Wartość domyślna parametru
to WebDB

Conmax

Maksymalna dopuszczalna liczb
a połączeń listenera.


Parametry WebDB GATEWAY


[SERVER]

Oznacza początek i koniec
sekcji Servera.

HomePage

Dotyczy domyślnej strony domowej
WebDB. Parametrem tym możemy
zmienić domyślną nazwę strony
domowej. Ustawienie to nadpisuje
wartość default_page z pliku
konfiguracji WebDB gateway
wdbsvr. app.

DefaultMimeType

Wyświetla jaki typ MIME użyty jest przez Listener w przypadku gdy
żądanie URL nie definiuje typu
MIME.
Wartość domyślna parametru
to application/octet-stream

LoggingLevel

Określa jak wiele informacji na temat
logowania przechwytywanych jest przez pliki logów znajdujące się w katalogu listenera. Informacje te stanowić mogą nieocenione źródło wiedzy przy debagowaniu aplikacji lub wykonywaniu analiz.
Parametr te może przybierać nastę pujące wartości:
NONE, STANDARD, TEST, ETEST, EXTENDED, ERROR, DEBUG,
EDEBUG
Wartość domyślna parametru to: EXTENDED

MaxCGIThreads

Wartość domyślna parametru to 5

MaxFileThreads

Określa liczbę wątków serwujących
pliki statyczne z file-systemu.
Wartość domyślna parametru to 5

MaxDispatcherThreads

Określa liczbę wątków
rozdzielających żądania HTTP.
Zwykle zwiększenie tego parametru podnosi wydajność systemu, ale jest on zależny od ograniczeń
nakładanych przez system
operacyjny.
Wartość domyślna parametru to 7

MaxQueueSize

Żądania połączenia przychodzące
od klientów kolejkowane są do
wartości ămaximum queue sizeÓ.
Parametr MaxQueueSize określa
maksymalną długość kolejki
połączeń oczekujących.
Jeśli kolejka połączeń oczekujących
się przepełni, użytkownik otrzymuje komunikat o błędzie ăConnection RefusedÓ.
Wartość domyślna parametru to 64

ReceiveTimeOut

Parametr ten określa liczbę sekund
jaką listener będzie czekał na
otrzymanie danych z sieci przed
wyświetleniem komunikatu
o błędzie. Wartość tego parametru
powinna być określana na
podstawie parametrów sieci.
Jeśli sieć z której korzysta listener
jest powolna parametr ten
powinien zbyć powiększony aby
zwiększyć szanse na odebranie niezbędnych danych.
Wartość domyślna parametru to 60 (sekund)

OnlyClient

Parametr ten ogranicza dostęp
do listenera WebDB. Może on
określać konkretne adresy IP,
i tylko te adresy IP będą
obsługiwane.
Na przykład ustawienie wartości:
OnlyClient =
Ograniczy dostęp do listenera
tylko do komputera o adresie 180.25.84.254

[DirMaps]

Oznacza początek i koniec sekcji
mapowania katalogów.
Dla Windows NT
domyślne ustawienia to:

C: Oraclewdbwebdbimages /images/

dla UNIXa domyślna parametru to:

[ORACLE_HOME]/webdb/images/ /images/

[CGIDirMaps]

Oznacza początek i koniec sekcji
mapowania katalogu CGI.

[MIMETypes]

Oznacza początek i koniec sekcji
definiowania typów MIME.
Każda z linii tej sekcji reprezentuje
jeden z typów plików i rozszerzeń
plików rozpoznawanych
przez WebDB.

Najważniejszymi parametrami przedstawionego powyżej zestawienia są:
MaxFileThreads, MaxCGIThreads, MaxDispatcherThreads, reuse i connmax. Parametry te powinny być zmieniane w zależności od przewidywanego obciążenia listenera.
Parametr LoggingLevel może być zmniejszony nawet do poziomy NONE.
Dla uzyskania większej wydajności należy zakomentarzować znakiem średnika linię
"debugModules" w pliku wdbsvr. app. Parametr ten wykorzystywany jest podczas procesu debagowania i powoduje generowanie ogromnej ilości
danych w plikach logów.

Na podstawie mądrości Internetu

Jadwiga Gnybek