Materia艂y szkoleniowe
Administracja serwerem Oracle
Spis tre艣ci
Konwencje typograficzne
Konwencje typograficzne
Aby u艂atwi膰 wyszukiwanie w聽materia艂ach szkoleniowych wa偶niejszych informacji oraz聽poszczeg贸lnych element贸w, zastosowano ikony o聽nast臋puj膮cym znaczeniu:
—聽ikona „Wskaz贸wka”; sygnalizuje fragment opisuj膮cy u艂atwienia wykonania czynno艣ci lub „skr贸t” pozwalaj膮cy wykona膰 j膮 szybciej i聽sprawniej;
—聽ikona „Uwaga”; sygnalizuje informacje wa偶ne dla聽prawid艂owego wykonania czynno艣ci;
—聽ikona „膯wiczenia”; rozpoczyna zestaw 膰wicze艅;
Wprowadzenie
Cele Kursu
Po zako艅czeniu tego kursu powiniene艣 potrafi膰:
Opisa膰 architektur臋 serwera Oracle.
Uruchomi膰 i zamkn膮膰 baz臋 danych.
Utworzy膰 kompletn膮 baz臋 danych.
Opisa膰 operacje dost臋pu i aktualizacji danych.
Opisa膰 zasady wsp贸艂bie偶no艣ci transakcji i sp贸jno艣ci odczytu.
Dopasowa膰 baz臋 danych przez zmienianie parametr贸w inicjalizacji.
Zarz膮dza膰 struktur膮 bazy danych przez przestrzenie tabel.
Zarz膮dza膰 przydzia艂em przestrzeni i wzrostem segment贸w bazy danych.
Zarz膮dza膰 przestrzeni膮 bazy danych przez tabele, indeksy, klastry indeksowe i klastry haszuj膮ce.
Zarz膮dza膰 segmentami wycofania i segmentami tymczasowymi.
Zapewnia膰 integralno艣膰 danych.
Tworzy膰, monitorowa膰 oraz usuwa膰 u偶ytkownik贸w.
Kontrolowa膰 zasoby systemowe u偶ytkownik贸w bazy danych.
Przydziela膰, monitorowa膰 i kontrolowa膰 uprawnienia w bazie danych.
Wykonywa膰 zadania zwi膮zane z obs艂ug膮 j臋zyk贸w narodowych (NLS)
Opisa膰, w艂膮czy膰 i wy艂膮czy膰 艣ledzenie.
Opisa膰 zaawansowan膮 architektur臋 serwera.
Opisa膰 procedury bazy danych i opcje dodatkowe.
Zarz膮dza膰 baz膮 danych u偶ywaj膮c narz臋dzia Serwer Manager.
Obowi膮zki Administratora Bazy Danych
System baz danych Oracle mo偶e by膰 ca艂kiem du偶y i obs艂ugiwa膰 wielu u偶ytkownik贸w.
Cz臋sto wi臋c niezb臋dne jest aby jedna osoba lub grupa ludzi by艂a odpowiedzialna za zarz膮dzanie systemem bazy danych. T膮 osob膮 jest administrator bazy danych (DBA).
Obowi膮zki DBA
Pierwsza instalacja i instalowanie nowych wersji serwera Oracle i narz臋dzi aplikacyjnych.
Utworzenie podstawowych struktur bazy danych i podstawowych obiekt贸w.
Przydzia艂 przestrzeni systemowej i planowanie przysz艂ych wymaga艅 przestrzeni systemu bazy danych.
Modyfikowanie struktury bazy danych.
Zak艂adanie u偶ytkownik贸w.
Kontrolowanie i monitorowanie dost臋pu u偶ytkownik贸w do bazy danych.
Archiwizacja i odtwarzanie bazy danych.
Zak艂adanie u偶ytkownik贸w.
Kontrolowanie i monitorowanie dost臋pu u偶ytkownik贸w do bazy danych.
Archiwizacja i odtwarzanie bazy danych.
Zapewnienie bezpiecze艅stwa systemu.
Monitorowanie i optymalizacja efektywno艣ci bazy danych.
W niekt贸rych systemach baz danych mo偶e by膰 wielu r贸偶nych DBA o r贸偶nych zadaniach.
Na przyk艂ad inni DBA mog膮 by膰 odpowiedzialni za tworzenie u偶ytkownik贸w, monitorowanie u偶ytkownik贸w, monitorowanie zasob贸w systemu i zapewnienie bezpiecze艅stwa bazy danych.
W przeciwie艅stwie do obowi膮zk贸w DBA, projektant aplikacji w bazie danych mo偶e by膰 odpowiedzialny za projektowanie i implementacj臋 aplikacji bazodanowych, projektowanie obiekt贸w bazy danych oraz strojenie aplikacji.
I.聽Przegl膮d architektury Oracle
Cele
W tej lekcji przedstawiamy architektur臋 serwera Oracle, w szczeg贸lno艣ci struktury fizyczne, struktury pami臋ci i procesy t艂a.
Po zako艅czeniu tej lekcji powiniene艣 potrafi膰:
Rozpoznawa膰 sk艂adniki architektury Oracle.
Okre艣li膰 przeznaczenie ka偶dego z typ贸w sk艂adnik贸w.
Przegl膮d
Aby efektywnie zarz膮dza膰 baz膮 danych, administrator bazy danych (DBA od. ang. DataBase Administrator) powinien dok艂adnie zna膰 i rozumie膰 architektur臋 serwera ORACLE.
DBA musi rozumie膰 nast臋puj膮ce elementy:
Procesy.
Struktury pami臋ci.
Pliki.
Globalny Obszar Systemowy (SGA)
Przy ka偶dym starcie serwera w cz臋艣ci pami臋ci operacyjnej rezerwowana jest na Globalny Obszar Systemowy (SGA od ang. System Global Area). Jest to grupa dzielonych struktur pami臋ci zawieraj膮ca informacje kontrolne pojedynczego systemu bazy danych Oracle.
SGA powinien by膰 alokowany w pami臋ci rezydentnej (nie stronicowej, nie wirtualnej).
Je艣li pod艂膮czonych do bazy jest wielu u偶ytkownik贸w, dane w SGA s膮 „dzielone” przez wszystkich u偶ytkownik贸w.
SGA mo偶na tak偶e t艂umaczy膰 jako „Shared Global Area” - dzielony obszar globalny.
SGA nie powinien zajmowa膰 wi臋cej ni偶 50% dost臋pnej pami臋ci operacyjnej.
Obszar Dzielony
Obszar dzielony jest fragmentem SGA zawieraj膮cym mi臋dzy innymi takie konstrukcje jak dzielone obszary SQL i bufor s艂ownika danych.
Obszary Dzielone SQL
Ka偶dy z obszar贸w dzielonych AQL (shared SQL area) zawiera informacje u偶ywane przy wykonaniu pojedynczego polecenia SQL. Procesy wykonuj膮ce identyczne polecenia SQL u偶ywaj膮 tej samej informacji.
Polecenie SQL umiejscawiane jest w dzielonym obszarze SQL za pomoc膮 algorytmu haszowania zastosowanego do tego polecenia. St膮d te偶 tylko absolutnie identyczne polecenia mog膮 by膰 skierowane w ten sam obszar pami臋ci.
Obszary dzielone SQL bywaj膮 te偶 nazywane buforem bibliotecznym (library cache).
Bufor S艂ownika Danych
S艂ownik danych (data dictionary) jest zbiorem tabel i perspektyw bazy danych zawieraj膮cych informacje o bazie danych, jej strukturach i u偶ytkownikach. W艣r贸d danych przechowywanych w s艂owniku danych znajduj膮 si臋:
Nazwy wszystkich tabel i perspektyw bazy danych,
Nazwy i typy danych kolumn tabel bazy danych,
Uprawnienia wszystkich u偶ytkownik贸w Oracle.
Bufor s艂ownika bazy danych nazywany jest czasem buforem wierszowym (row cache).
Zawarto艣膰 Obszaru Dzielonego
Tekst polecenia SQL lub PL/SQL,
Analiza sk艂adniowa polecenia SQL lub PL/SQL,
Plan wykonania polece艅 SQL i PL/SQL,
Bufor s艂ownika danych zawieraj膮cy wiersze s艂ownika danych.
Bufor Bazy Danych
Bufor bazy danych zawiera kopie blok贸w danych odczytanych z dysku. Wszyscy u偶ytkownicy pod艂膮czeni aktualnie do systemu korzystaj膮 ze wsp贸lnego bufora bazy danych.
Dost臋p do Danych
cache miss (brak w buforze)
Przy pierwszym dost臋pie procesu u偶ytkownika do wskazanego fragmentu danych, proces ten, zanim uzyska do niego dost臋p, musi przepisa膰 dane z dysku do bufora.
cache hit (trafienie w bufor)
Je艣li proces 偶膮da dost臋pu do danych, kt贸re ju偶 znajduj膮 si臋 w buforze, mo偶e odczytywa膰 dane bezpo艣rednio z pami臋ci operacyjnej.
Dost臋p do danych przy trafieniach w bufor jest szybszy ni偶 przy sytuacji brak贸w w buforze. Poniewa偶 rozmiar bufora jest ograniczony, nie wszystkie dane z dysku mieszcz膮 si臋 w buforze. Kiedy bufor jest pe艂en, kolejne braki w buforze powoduj膮, 偶e Oracle zapisuj膮 dane z bufora na dysk w celu zwolnienia miejsca dla nowych danych. Wtedy kolejne odwo艂ania do przeniesionych na dysk danych powoduj膮 sytuacj臋 braku w buforze.
Bufor Dziennika Powt贸rze艅
Bufor dziennika powt贸rze艅 (redo log buffer) to bufor cykliczny zawieraj膮cy informacje o zmianach dokonanych w bazie danych. Dziennik powt贸rze艅:
Rejestruje wszystkie zmiany dokonane w bazie danych.
Odtwarza zmiany dokonane w bazie danych i segmentach wycofania podczas odtwarzania bazy .
Mo偶e by膰 pomini臋ty przez u偶ycie s艂owa kluczowego UNRECOVERABLE (nieodtwarzalne) w poleceniach CREATE TABLE i CREATE INDEX.
Mo偶e by膰 pomini臋ty przez 艂adowanie danych z pomoc膮 Oracle Loader.
Procesy T艂a
W celu maksymalizacji efektywno艣ci wykonania i umo偶liwienia pracy wielu u偶ytkownikom, system Oracle u偶ywa specjalnych proces贸w Oracle zwanych procesami drugoplanowymi lub procesami t艂a.
System Oracle, w zale偶no艣ci od konfiguracji, mo偶e sk艂ada膰 si臋 z wielu proces贸w t艂a. Oto ich nazwy:
Database Writer (DBWR) - sekretarz bazy danych,
Log Writer (LGWR) - sekretarz dziennika powt贸rze艅,
Checkpoint (CKPT) - menad偶er punkt贸w kontrolnych,
System Monitor (SMON) - monitor systemu,
Proces Monitor (PMON) - monitor proces贸w,
Archiver (ARCH) - archiwizator,
Recoverer (RECO) - odtwarzacz,
Lock (LCKn) - kontroler blokad,
Snapshot Refresh (SNPn) - od艣wie偶acz migawek,
Shared Serwer (Snnn) - serwer dzielony,
Dispatcher (Dnnn) - proces rozdzielaj膮cy (dyspozytor),
Parallel Query (Pnnn) - kontroler zapyta艅 r贸wnoleg艂ych.
Procesy PMON i SMON
Procesy PMON i SMON zwalniaj膮 zasoby bazy danych nie u偶ywane ju偶 przez u偶ytkownika.
PMON
Porz膮dkuje systemy po awaryjnym przerwaniu pod艂膮czenia,
Wycofuje niezatwierdzone transakcje,
Zwalnia blokady na艂o偶one przez przerwany proces,
Zwalnia zasoby SGA zaj臋te przez przerwany proces,
Uruchamia ponownie przerwane procesy serwera dzielonego i dyspozytora.
SMON
Wykonuje automatyczne odtwarzanie instalacji,
Zwalnia obszar zaj臋ty przez nieu偶ywane ju偶 segmenty tymczasowe,
艁膮czy obszary wolnej przestrzeni plik贸w danych w sp贸jny obszar.
Cztery Obowi膮zkowe Procesy
Procesy PMON, SMON, DBWR i LGWR s膮 niezb臋dnymi dla dzia艂ania instalacji procesami. Pozosta艂e procesy s膮 opcjonalne.
Procesy PMON, SMON, DBWR i LGWR nie mog膮 by膰 konfigurowane przez parametry inicjalizacji.
Je艣li kt贸rykolwiek z tych czterech proces贸w zostanie przerwany, nast臋puje awaria instancji i trzeba uruchomi膰 j膮 ponownie.
Procesy u偶ytkownika
Proces u偶ytkownika jest tworzony kiedy u偶ytkownik uruchamia program aplikacji.
Proces u偶ytkownika
Uruchamia narz臋dzie / aplikacj臋, jest postrzegany jako klient. Przyk艂adem mo偶e by膰 Serwer Manager, Oracle Forms, lub program w Pro*C.
Przekazuje polecenia SQL do procesu serwera i odbiera wyniki.
Procesy Serwer贸w
Przed uzyskaniem dost臋pu do danych, dane musz膮 by膰 umieszczone w buforze danych.
Dokonuje tego proces serwera. W celu wykonania polecenia SQL proces serwera u偶ywa pami臋ci dzielonej w SGA.
Zadania Procesu Serwera
Analiza i wykonanie polece艅 SQL,
Odczyt blok贸w danych z dysku do dzielonych bufor贸w danych w SGA,
Zwr贸cenie wynik贸w polece艅 SQL do procesu u偶ytkownika.
Proces serwera analizuje, wykonuje i sprowadza dane dla ka偶dej aplikacji u偶ytkownika.
Zadanie |
Opis |
Analiza (parse) |
Sprawdzanie poprawno艣ci sk艂adni, uprawnie艅, identyfikacja obiekt贸w i optymalizacja (budowa drzewa analizy). Podczas analizy u偶ywane s膮 obszary dzielone SQL, st膮d te偶 procesy mog膮 u偶ywa膰 wsp贸lnych drzew analizy. |
Wykonanie (execute) |
Realizacja dzia艂a艅 z drzewa analizy na danych, fizyczny odczyt i zmiana danych, wed艂ug potrzeb. |
Sprowadzanie (fetch) |
Przekazuje dane wynikowe polecenia SELECT |
Uwaga: Istniej膮 te偶 inne mo偶liwe konfiguracje dotycz膮ce serwer贸w, jednak nie b臋d膮 one omawiane podczas lekcji.
Instancja Oracle
Instancj臋 Oracle stanowi kombinacja SGA i proces贸w t艂a bazy danych. Kiedy instancja jest uruchamiana, przydzielane s膮 bufory pami臋ci SGA i startuj膮 procesy t艂a.
Nale偶y odr贸偶ni膰 poj臋cia „baza danych Oracle” i „instancja Oracle”. M贸wimy, 偶e „instancja jest uruchomiona” (pami臋膰 jest przydzielona, procesy t艂a uruchomione), za艣 baza danych (plik danych) „jest zamontowana” w instalacji.
Procesy serwera i procesy u偶ytkownika nie zawieraj膮 si臋 w definicji instancji Oracle.
Baza Danych Oracle
Baza danych Oracle sk艂ada si臋 z jednego lub wielu plik贸w kontrolnych (control file), plik贸w danych (datafile) i plik贸w dziennika powt贸rze艅 (redo log files) wyspecyfikowanych w pliku kontrolnym.
Struktura fizyczna |
Definicja |
Plik danych (datafile)
|
Zawiera wszystkie dane bazy danych. Struktury logiczne, takie jak tabele, indeksy, przechowywane s膮 fizycznie w plikach danych. |
Pliki dziennika powt贸rze艅 (redo log files) |
Przechowuj膮 zapis wszystkich zmian dokonanych w bazie danych w celu ewentualnego odtwarzania. |
Pliki kontrolne (control files) |
Ka偶dy z nich zawiera opis struktury fizycznej i statusu bazy danych. |
Pliki Dziennika Powt贸rze艅
Pliki dziennika powt贸rze艅 (redo log files) zawieraj膮 zapis wszystkich zmian dokonanych w bazie danych u偶ywany podczas odtwarzania danych. Je艣li pliki dziennika powt贸rze艅 s膮 zwielokrotnione, ta sama informacja dziennika powt贸rze艅 zapisywana jest jednocze艣nie do plik贸w dziennika powt贸rze艅.
Pliki Dziennika Powt贸rze艅
Pliki dziennika powt贸rze艅 zapisywane s膮 w spos贸b cykliczny.
Musz膮 istnie膰 co najmniej dwie grupy plik贸w dziennika powt贸rze艅.
Pliki dziennika powt贸rze艅 powinny by膰 przechowywane na najszybszym i najmniej obci膮偶onym operacjami wej艣cia/wyj艣cia urz膮dzeniu. Urz膮dzenia RAID nie s膮 zalecane.
Zwielokrotnione Pliki Dziennika Powt贸rze艅
Zalecana konfiguracja plik贸w dziennika powt贸rze艅 to przynajmniej po dwa elementy (redo log member) w ka偶dej grupie, a ka偶dy element na innym dysku.
Zwielokrotnione pliki powt贸rze艅 dziennika zabezpieczaj膮 przed utrat膮 dziennika powt贸rze艅.
Wszystkie elementy grupy plik贸w dziennika powt贸rze艅 zawieraj膮 te same informacje i maj膮 identyczny rozmiar.
Elementy grupy s膮 aktualizowane jednocze艣nie.
Ka偶da grupa powinna zawiera膰 tak膮 sam膮 liczb臋 element贸w.Przyk艂ad: Zwielokrotnione Pliki Dziennika Powt贸rze艅
Dysk A i B reprezentuj膮 r贸偶ne dyski na tej samej maszynie. Ka偶dy element grupy musi by膰 tego samego rozmiaru. Ka偶dy element grupy powinien by膰 przechowywany na innym dysku aby lepiej zabezpieczy膰 si臋 przed awari膮. Ka偶dy element grupy zapisywany jest w tym samym czasie.
Domy艣lna instalacja tworzy dwie grupy dziennik贸w powt贸rze艅 z jednym elementem w ka偶dej grupie i domy艣lnym rozmiarem 500 KB. Cz臋sto warto doda膰 wi臋cej element贸w na innych dyskach, a tak偶e zwi臋kszy膰 rozmiar plik贸w dziennika.
Pliki Kontrolne
Plik kontrolny (control file) to niewielki plik binarny opisuj膮cy struktur臋 bazy danych.
W艂asno艣ci Pliku Kontrolnego
Identyfikuje wszystkie niezb臋dne pliki danych i pliki dziennika,
W pliku kontrolnym zapami臋tana jest nazwa bazy danych,
Plik kontrolny jest niezb臋dny do zamontowania, otwarcia i u偶ywania bazy danych,
Plik kontrolny przechowuje informacj臋 synchronizuj膮c膮, potrzebn膮 przy odtwarzaniu,
Zalecana konfiguracja to minimum dwa pliki kontrolne przechowywane na r贸偶nych dyskach,
Parametr CONTROL_FILES identyfikuje pliki kontrolne.
Plik kontrolny musi by膰 dost臋pny do zapisu dla serwera Oracle podczas otwierania bazy danych.
Domy艣lna nazwa pliku kontrolnego jest zale偶na od systemu operacyjnego.
Plik Parametr贸w
Plik parametr贸w definiuje instancj臋. Aby uruchomi膰 instancj臋, Oracle musi odczyta膰 plik parametr贸w init<SID>ora. Plik parametr贸w jest plikiem tekstowym zawieraj膮cym list臋 parametr贸w konfiguracyjnych instancji. Ustawiaj膮c te parametry na okre艣lone warto艣ci zarz膮dzamy przydzia艂em pami臋ci i ustawieniem proces贸w instancji Oracle. Plik parametr贸w decyduje mi臋dzy innymi:
Ile pami臋ci ma by膰 przeznaczonej na struktury pami臋ci w SGA,
Co robi膰 z zape艂nieniami w trakcie pracy plikami dziennika powt贸rze艅,
Jakie s膮 nazwy i po艂o偶enie plik贸w kontrolnych bazy danych.
Rozmiar SGA
Parametr |
Definicja |
SHARED_POOL_SIZE |
Rozmiar pami臋ci (w bajtach) przeznaczonej na obszar dzielony polece艅 SQL i PL/SQL. |
DB_BLOCK_SIZE |
Rozmiar pojedynczego bloku (w bajtach), a tym samym bufora bloku w bazie danych. |
DB_BLOCK_BUFFERS |
Liczba utworzonych w SGA bufor贸w bazy danych, z kt贸rych ka偶dy ma rozmiar DB_BLOCK_SIZE. (Ca艂kowita wielko艣膰 bufor贸w bazy danych w SGA to iloczyn DB_BLOCK_SIZE i DB_BLOCK_BUFFERS) |
LOG_BUFFER |
Liczba bajt贸w przeznaczonych na bufor dziennika powt贸rze艅 |
Pliki 艢ladu i Plik Ostrze偶e艅
Po wyst膮pieniu b艂臋du w czasie dzia艂ania instancji Oracle do pliku ostrze偶e艅 (alert file) zapisywany jest komunikat . Je偶eli b艂膮d zosta艂 wykryty przez serwer lub proces t艂a, ta informacja zapisywana jest w odpowiednim pliku 艣ladu (trace file).
Plik Ostrze偶e艅
Plik ostrze偶e艅 (alert file) bazy danych to chronologiczny zapis komunikat贸w i b艂臋d贸w, w艣r贸d kt贸rych znajdowa膰 si臋 mog膮:
B艂臋dy wewn臋trzne (ORA-600), b艂臋dy zniszczenia bloku (ORA-1578), b艂臋dy zakleszczenia (ORA-60).
Dzia艂ania administracyjne (DDL) i polecenia sterowania serwerem (STARTUP, SHUTDOWN, ARCHIVE LOG i RECOVER).
Wszystkie inne ni偶 domy艣lne warto艣ci parametr贸w inicjalizacji z chwili startu instancji.
Oracle stosuje plik ostrze偶e艅 zamiast wy艣wietlania takich komunikat贸w na konsoli operatora.
Plik ostrze偶e艅 jest umieszczany w miejscu okre艣lonym przez parametr BACKGROUND_DUMP_DEST.
Wa偶ne jest, aby regularnie (codziennie) sprawdza膰 plik ostrze偶e艅, aby wykry膰 problem, zanim sytuacja stanie si臋 powa偶na, dop贸ki dysponujemy poprawn膮 kopi膮 zapasow膮 bazy (akcja b臋dzie zale偶na od natury problemu)
Pliki 艢ladu
Po wykryciu przez serwer lub proces t艂a b艂臋du wewn臋trznego, informacja jest zapisywana na odpowiedni plik 艣ladu. Pliki 艣ladu umieszczone s膮 tam, gdzie wskazuje parametr BACKGROUND_DUMP_DEST je艣li jest to komunikat procesu t艂a lub tam, gdzie wskazuje parametr USER_DUMP_DEST, je艣li komunikat zapisywany jest przez proces serwera.
Parametr SQL_TRACE
Zapis 艣ladu mo偶e by膰 w艂膮czony i wy艂膮czony parametrem inicjalizacji SQL_TRACE. Jego warto艣膰 to TRUE lub FALSE.
Mo偶na te偶 w艂膮czy膰 zapis do pliku 艣ladu tylko dla bie偶膮cej sesji wykonuj膮c polecenie:
SQL<ALTER SESSION SET sql_trace = TRUE
Podsumowanie
DBA powinien pami臋ta膰, 偶e:
Globalny Obszar systemowy (SGA) to grupa nast臋puj膮cych dzielonych struktur w pami臋ci:
Obszar dzielony (shared pool),
Bufory bazy danych (database buffer cache)
Bufor dziennika powt贸rze艅 (redo log buffer)
Procesy t艂a wykonuj膮 asynchroniczne r贸偶ne zadania dla wszystkich u偶ytkownik贸w bazy danych.
Do przetwarzania polece艅 SQL procesy serwer贸w u偶ywaj膮 pami臋ci dzielonej.
Procesy u偶ytkownika uruchamiaj膮 narz臋dzie lub aplikacj臋 i przekazuj膮 przetwarzanie polece艅 SQL procesom serwer贸w.
Instancja Oracle sk艂ada si臋 z SGA oraz proces贸w t艂a
Baza danych Oracle sk艂ada si臋 ze wszystkich plik贸w danych, plik贸w dziennika powt贸rze艅 i plik贸w kontrolnych.
Pliki dziennika powt贸rze艅 zapisuj膮 wszystkie zmiany dokonane w bazie danych i s膮 u偶ywane przy odtwarzaniu.
Plik kontrolny opisuje struktur臋 bazy danych i jest niezb臋dny do montowania i otwierania bazy danych.
Plik parametr贸w jest u偶ywany do ustawienia rozmiar贸w SGA i zlokalizowania plik贸w kontrolnych w trakcie uruchamiania instancji Oracle.
Plik ostrze偶e艅 bazy danych jest chronologicznym rejestrem komunikat贸w i b艂臋d贸w.
II.聽Uruchamianie i zamykanie instancji
Cele
W tej lekcji om贸wimy kroki, jakie musi wykona膰 DBA przy uruchamianiu i zamykaniu instancji Oracle w odpowiednim trybie, w艂a艣ciwym dla r贸偶nych sytuacji.
Po przerobieniu tej lekcji powiniene艣 potrafi膰:
Wybra膰 metod臋 identyfikacji.
Uruchomi膰 instancj臋 w odpowiednim trybie.
Zamkn膮膰 instancj臋 w odpowiednim trybie.
Zmieni膰 tryb bazy danych.
Ograniczy膰 pod艂膮czenia do bazy.
Metody Identyfikacji
W zale偶no艣ci od tego, czy DBA jest administratorem lokalnym bazy danych (na tym samym komputerze, gdzie znajduje si臋 baza danych), czy te偶 DBA administruje wieloma r贸偶nymi bazami danych z pojedynczego odleg艂ego komputera, mo偶emy wybra膰 pomi臋dzy identyfikacj膮 przez system operacyjny lub identyfikacj膮 administrator贸w przez pliki hase艂.
Identyfikacja przez System Operacyjny
Ustaw identyfikacj臋 u偶ytkownika w systemie operacyjnym.
Ustaw REMOTE_LOGIN_PASSWORDFILE=NONE
Pod艂膮czenie przez polecenie CONNECT / AS sysdba.
Identyfikacja przez Plik Hase艂
Utw贸rz plik hase艂 narz臋dziem ORAPWD
Ustaw REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE.
Nadaj uprawnienia sysoper lub sysdba administratorom w bazie danych (polecenie GRANT).
Pod艂膮czenie przez polecenie CONNECT u偶ytkownik AS sysdba lub sysoper.
Uruchamianie Instancji
Przy uruchamianiu instancji trzeba poda膰 stan w jakim ma znale藕膰 si臋 baza danych.
Stany Uruchomienia
Stan Uruchomienia |
Opis |
NOMOUNT |
U偶ywany przy tworzeniu bazy danych. |
MOUNT |
U偶ywany przy modyfikowaniu struktury plik贸w i zmianach znacznik贸w w pliku kontrolnym. |
OPEN |
Udost臋pnia baz臋 danych wszystkim u偶ytkownikom. |
|
|
Procedura Uruchamiania
Wystartowanie instancji.
Zamontowanie bazy danych.
Otwarcie bazy danych.
Na diagramie stan SHUTDOWN reprezentuje punkt startowy polecenia STARTUP.
Stan NOMOUNT, MOUNT i OPEN wzajemnie si臋 wykluczaj膮, tj. baza mo偶e by膰 w danym momencie tylko w jednym z tych stan贸w. Aby przej艣膰 za stanu SHUTDOWN do otwartej bazy danych, nale偶y wykona膰 polecenie STARTUP.
Po wykonaniu STARTUP NOMOUNT nast臋puje wystartowanie instancji.
Po wykonaniu STARTUP MOUNT nast臋puje wystartowanie instancji i otwarcie pliku kontrolnego. Baza danych mo偶e by膰 zamontowana lecz nie otwarta np. dla zmiany istniej膮cej struktury plik贸w. Przyk艂adem zmiany struktury plik贸w mo偶e by膰 zmiana nazwy pliku dziennika lub pliku danych, albo te偶 rozpocz臋cia odtwarzania.
Po wykonaniu STARTUP OPEN nast臋puje wystartowanie instancji, otwarcie pliku kontrolnego, a nast臋pnie otwarcie wszystkich plik贸w wyspecyfikowanych w pliku kontrolnym.
Aby otworzy膰 baz臋 danych po poleceniu STARTUP MOUNT wykonujemy polecenie ALTER DATABASE OPEN. Wtedy baza danych jest dost臋pna dla wszystkich u偶ytkownik贸w.
Uwaga: Polecenie STARTUP mo偶na wykona膰 dla danej instancji tylko raz.
Kroki Serwera
Uruchomienie instancji powoduje, 偶e serwer Oracle:
Odczytuje parametry z pliku init<SID>.ora.
Przydziela pami臋膰 na SGA.
Uruchamia procesy t艂a.
Otwiera pliki 艣ladu i plik ostrze偶e艅.
Nazwa bazy danych musi by膰 podana w parametrze DB_NAME w pliku init<SID>.ora lub w poleceniu STARTUP.
Tryby Uruchomienia
Opcja NOMOUNT nie jest zwykle podawana w poleceniu STARTUP jako, 偶e jest ona u偶ywana jedynie dla wystartowania instancji, kt贸ra ma utworzy膰 baz臋 danych.
Opcja MOUNT jest u偶ywana, gdy musimy wykona膰 odtwarzanie, lub konieczne jest wykonanie pewnych akcji zwi膮zanych z plikami danych lub plikami dziennika.
W przewa偶aj膮cej liczbie przypadk贸w u偶ywana jest opcja OPEN pozwalaj膮ca wszystkim na u偶ywanie bazy danych.
Opcje Montowania
Opcje PARALLEL u偶ywamy tylko je艣li wiele instancji jednoczenie ma mie膰 dost臋p do bazy danych. W przeciwnym razie u偶ywamy (domy艣lnej) opcji EXCLUSIVE. Opcja SHARED jest synonimem opcji PARALLEL. Opcja RETRY jest dost臋pna tylko dla instancji pracuj膮cych w trybie PARALLEL.
Opcje Uruchamiania
Opcja FORCE jest u偶ywana do ponownego uruchomienia ju偶 dzia艂aj膮cej instancji. Nie nale偶y u偶ywa膰 tej opcji je艣li da si臋 zamkn膮膰 baz臋 poleceniem SHUTDOWN. Po wykonaniu polecenia STARTUP FORCE baza wymaga odtwarzania.
Opcja RESTRICT s艂u偶y do zablokowania mo偶liwo艣ci pod艂膮czenia si臋 do bazy zwyk艂ym u偶ytkownikom.
Elementy SGA
Pewna cz臋艣膰 przestrzeni o sta艂ym rozmiarze jest zarezerwowana na og贸lne informacje bazy danych i instancji. Nie s膮 tzn. przechowywane 偶adne dane u偶ytkownik贸w.
Cz臋艣膰 o zmiennym rozmiarze przeznaczona na obszar dzielony, obszary sortowania i聽inne dane zwi膮zane z danymi u偶ytkownika.
Sk艂adnia:
gdzie:
baza danych okre艣la nazw臋 bazy danych
OPEN udost臋pnia baz臋 danych u偶ytkownikom
MOUNT montuje baz臋 danych na potrzeb臋 pewnych czynno艣ci DBA, nie udost臋pnia bazy u偶ytkownikom
NOMOUNT tworzy SGA i uruchamia procesy t艂a, nie udost臋pnia bazy danych u偶ytkownikom
EXCLUSIVE pozwala jedynie bie偶膮cej instancji na dost臋p do bazy danych
PARALLEL pozwala na dost臋p do bazy danych wielu instancji (uruchamia Serwer R贸wnoleg艂y Oracle).
SHARED inny termin na PARALLEL
RETRY wskazuje, aby instancja r贸wnoleg艂a usi艂owa艂a si臋 ponownie uruchamia膰 w pi臋ciosekundowych odst臋pach.
PFILE=parfile pozwala na u偶ycie innego ni偶 domy艣lny pliku parametr贸w dla ustalenia konfiguracji instancji
FORCE przed wykonaniem normalnego uruchomienia przerywa dzia艂aj膮c膮 instancj臋
RESTRICT udost臋pnia baz臋 danych tylko u偶ytkownikom posiadaj膮cym uprawnienie RESTRICTED SESSION
RECOVER po uruchomieniu bazy rozpoczyna odtwarzanie po awarii no艣nik贸w.
Przyk艂ad
Start instancji bazy danych ORCL z u偶yciem pliku parametr贸w initORCL.ora. Wykonujemy polecenie:
SVRMGR > STARTUP NOMOUNT PFILE=initORCL.ora. |
Montowanie Bazy Danych
Aktywacja Plik贸w Kontrolnych
Podczas montowania bazy danych:
Wyspecyfikowane w pliku parametr贸w pliki kontrolne zostaj膮 odnalezione i otwarte.
Pliki kontrolne s膮 odczytywane w celu znalezienia nazw i status贸w plik贸w danych i plik贸w dziennika powt贸rze艅.
Zamontowa膰 baz臋 danych mo偶na te偶 poleceniem ALTER DATABASE
Sk艂adnia:
gdzie:
baza danych nazwa bazy, kt贸ra ma by膰 zmieniona.
MOUNT montuje baz臋 danych na potrzeby pewnych czynno艣ci DBA, nie udost臋pnia bazy u偶ytkownikom
EXCLUSIVE pozwala jedynie bie偶膮cej instancji na dost臋p do bazy
PARALLEL pozwala na dost臋p do bazy danych wielu instancji (uruchamia Serwer R贸wnoleg艂y Oracle).
OPEN udost臋pnia baz臋 danych u偶ytkownikom
Uruchomianie Odtwarzania
Baza danych musi by膰 zamontowana, lecz nie otwarta w celu
W艂膮czenia lub wy艂膮czenia archiwizacji dziennik贸w umo偶liwiaj膮cych odtwarzanie no艣nik贸w (prze艂膮czenie pomi臋dzy trybami ARCHIVELOG i NOARCHIVELOG).
Wykonania pe艂nego odtwarzania no艣nik贸w (odbudowanie pe艂nej bazy z kopii zapasowej)
Wykonania niepe艂nego odtwarzania bazy danych.
Opcja RESETLOGS jest omawiana na kursie Archiwizacja i Odtwarzanie. Powinna by膰 stosowana bardzo ostro偶nie.
Opcje MOUNT i OPEN s膮 dost臋pne w menu narz臋dzia Instance Manager oraz w Server Manager w trybie linii polece艅.
Otwieranie Bazy Danych
Otwieramy baz臋 danych w celu umo偶liwienia normalnej pracy u偶ytkownikom.
Przyk艂ad
Otwieranie zamontowanej uprzednio bazy danych.
SVRMGR> ALTER DATABASE OPEN; Statement processed. |
Argumentu RESTRICTED SESSION u偶ywamy w celu udost臋pnienia bazy danych tylko u偶ytkownikom DBA.
Je艣li kt贸rykolwiek plik danych lub plik dziennika powt贸rze艅 jest niedost臋pny lub nie mo偶e by膰 otwarty, serwer Oracle zwraca b艂膮d i nie otwiera bazy danych.
Sesje Zastrze偶one
Stan bazy danych mo偶e by膰 zmieniony tak, aby w przysz艂e pod艂膮czenia mieli prawo wykonywa膰 inni u偶ytkownicy maj膮cy prawo do otwierania sesji zastrze偶onych (uprawnienie RESTRICTED SESSION). S艂u偶y do tego polecenie ALTER SYSTEM.
Sk艂adnia:
gdzie:
ENABLE RESTRICTED pozwala na wykonywanie pod艂膮cze艅 tylko u偶ytkownik贸w z uprawnieniami RESTRICTED SESSION
DISABLE RESTRICTED pozwala na pod艂膮czenie si臋 wszystkim u偶ytkownikom
Zamykanie bazy danych
Po zamkni臋ciu bazy danych i zatrzymaniu instancji baza danych jest niedost臋pna dla u偶ytkownik贸w.
Sk艂adnia:
gdzie:
NORMAL oczekuje a偶 wszyscy pod艂膮czeni u偶ytkownicy normalnie zako艅cz膮 swoje sesje.
TRANSACTIONAL oczekuje, a偶 wszyscy u偶ytkownicy zako艅cz膮 swoje transakcje, roz艂膮cza u偶ytkownik贸w po zako艅czeniu transakcji
IMMEDIATE ko艅czy bie偶膮co wykonywane polecenie SQL i wycofuje nie zatwierdzone transakcje.
ABORT najszybsze mo偶liwe zako艅czenie. Nie czeka na zako艅czenie operacji ani na od艂膮czenie u偶ytkownik贸w. Nie wycofuje nie zatwierdzonych transakcji.
Zamkni臋cie Normalne (shutdown normal)
Nie pozwala na nowe pod艂膮czenia. Serwer Oracle odwleka zamkni臋cie bazy a偶 do od艂膮czenia si臋 wszystkich u偶ytkownik贸w. Nast臋pne uruchomienie nie wymaga odtwarzania instancji. NORMAL jest domy艣lnym trybem zamykania.
Zamkni臋cie Transakcyjne (shutdown transactional)
Bie偶膮ce polecenie SQL klient贸w nie s膮 ko艅czone. Wszystkie nie zatwierdzone transakcje kontynuuj膮 prac臋. Po zako艅czeniu transakcji sesje u偶ytkownik贸w s膮 ko艅czone. Polecenie SHUTDOWN TRANSACTIONAL zamyka i demontuje baz臋 danych i zatrzymuje instancj臋. Baza danych jest sp贸jna, nast臋pne uruchomienie nie wymaga odtworzenia instancji.
Zamkni臋cie Natychmiastowe (shutdown immediate)
Bie偶膮ce polecenie SQL klient贸w nie s膮 ko艅czone. Wszystkie nie zatwierdzone transakcje s膮 wycofywane. Serwer Oracle nie czeka na od艂膮czenie si臋 wszystkich pod艂膮czonych do bazy danych u偶ytkownik贸w. Polecenie SHUTDOWN IMMEDIATE zamyka i demontuje baz臋 danych i zatrzymuje instancj臋. Baza danych jest sp贸jna, nast臋pne uruchomienie nie wymaga odtworzenia instancji.
Zamkni臋cie Awaryjne (shutdown abort)
Przerywa bie偶膮co wykonywane przez serwer Oracle polecenia SQL klient贸w. Nie zatwierdzone transakcje nie s膮 wycofywane. Serwer Oracle nie czeka na od艂膮czenie si臋 pod艂膮czonych do bazy danych u偶ytkownik贸w. SHUTDOWN ABORT nie zamyka ani nie demontuje bazy danych, zatrzymuje jedynie instancj臋. Nast臋pne uruchamianie wymaga odtwarzania instancji (co odbywa si臋 automatycznie).
Zamykamy baz臋 danych w celu zrobienia kopii zapasowej wszystkich struktur fizycznych offline z poziomu systemu operacyjnego lub w celu modyfikacji parametr贸w inicjalizacji.
Aby sprawdzi膰, czy s膮 jacy艣 u偶ytkownicy pod艂膮czeni do bazy ogl膮damy perspektyw臋 V$SESSION.
Przyk艂ady
Zamkni臋cie bazy danych pozwalaj膮ce u偶ytkownikom zako艅czy膰 ich sesje.
SVRMGR> CONNECT / AS SYSDBA Connected SVRMGR> SHUTDOWN NORMAL Database closed Database dismounted Oracle instance shut down |
Zamkni臋cie bazy danych zamontowanej, ale nie otwartej.
SVRMGR> CONNECT / AS SYSDBA Connected SVRMGR> SHUTDOWN NORMAL ORA-01109 : database not open Database dismounted ORACLE instance shut down |
Zamkni臋cie bazy danych w stanie NOMOUNT
SVRMGR> CONNECT / AS SYSDBA Connected SVRMGR> SHUTDOWN NORMAL ORA-01507 : database not mounted ORACLE instance shut down |
Podsumowanie
Aby baza danych by艂a dost臋pna dla u偶ytkownik贸w, nale偶y wystartowa膰 (uruchomi膰) instancj臋.
Procedura Uruchamiania
Wywo艂aj narz臋dzie Oracle Enterprise Manager lub Server Manager.
Pod艂膮cz si臋 jako administrator (polecenie CONNECT u偶ytkownik AS sysdba)
Uruchom baz臋 danych (polecenie STARTUP)
Start instancji.
Zamontowanie bazy danych.
Otwarcie bazy danych
Po zamkni臋ciu instancji baza danych jest niedost臋pna dla u偶ytkownik贸w.
Procedura Zamykania
Wywo艂aj narz臋dzie Oracle Enterprise Manager lub Server Manager.
Pod艂膮cz si臋 jako administrator (polecenie CONNECT u偶ytkownik AS sysdba)
Zamknij instancj臋 (polecenie SHUTDOWN).
Poleceniami ALTER SYSTEM ENABLE/DISABLE RESTRICTED SESSION ograniczamy dost臋p jedynie dla u偶ytkownik贸w DBA lub te偶 pozwalamy na pod艂膮czenie wszystkim u偶ytkownikom.
Zadania
Pod艂膮cz si臋 do bazy jako internal
Zamontuj baz臋
Obejrzyj perspektyw臋 V$SGA
Obejrzyj perspektyw臋 DBA_USERS
Otw贸rz baz臋
Zamknij baz臋 w trybie IMMEDIATE
Otw贸rz baz臋 poleceniem STARTUP OPEN
Zobacz, czy teraz da si臋 obejrze膰 perspektyw臋 DBA_USERS
Zablokuj dost臋p dla u偶ytkownik贸w
Spr贸buj zalogowa膰 si臋 jako DEMO/DEMO
Zamknij baz臋 w trybie TRANSACTIONAL
W Instance Managerze zamontuj baz臋 i otw贸rz, a nast臋pnie zamknij w trybie IMMEDIATE
III.聽Tworzenie bazy danych
Cele
W tej lekcji om贸wimy kroki jakie musi podj膮膰 DBA przy tworzeniu nowej bazy danych Oracle.
Po przerobieniu tej lekcji powiniene艣 potrafi膰:
Om贸wi膰 zwi膮zek mi臋dzy logicznym diagramem encji i zwi膮zk贸w a zwi膮zanymi z nimi obiektami bazy danych.
Utworzy膰 baz臋 danych.
Zbudowa膰 s艂ownik danych.
Przegl膮d
Tworzenie bazy danych to pierwszy krok w organizowaniu i zarz膮dzaniu systemu baz danych.
Zadania Zwi膮zane z Tworzeniem Bazy Danych
Organizacja zawarto艣ci bazy danych poprzez przestrzenie tabel.
Zaprojektowanie struktury bazy danych optymalizuj膮cej efektywno艣膰 i minimalizuj膮cej fragmentacj臋.
Przygotowanie 艣rodowiska systemu operacyjnego do tworzenia bazy danych.
Edycja pliku parametr贸w.
Wystartowanie instancji.
Wykonanie polecenia CREATE DATABASE.
Zapewnienie bezpiecze艅stwa bazy danych przez zwielokrotnienie plik贸w dziennika powt贸rze艅 i plik贸w kontrolnych.
Utworzenie pliku hase艂.
Zdefiniowanie tabel i perspektyw s艂ownika danych do zarz膮dzania baz膮 danych.
Planowanie Przestrzeni Tabel
Baza danych Oracle jest podzielona na mniejsze logiczne cz臋艣ci nazywane przestrzeniami tabel.
Przestrzenie Tabel (tablespace)
Ka偶da przestrze艅 tabel sk艂ada si臋 z jednego lub wielu plik贸w systemu operacyjnego.
Przestrzenie tabel mog膮 by膰 w艂膮czane (prze艂膮czane w stan online) w czasie pracy bazy.
Z wyj膮tkiem przestrzeni tabel SYSTEM, przestrzenie tabel mog膮 by膰 wy艂膮czane (prze艂膮czane w stan offline) bez przerywania pracy bazy danych.
Ka偶dy obiekt znajduje si臋 w pojedynczej przestrzeni tabel.
Przestrze艅 tabel zawieraj膮ca aktywny segment wycofania nie mo偶e by膰 wy艂膮czona.
Przestrze艅 tabel SYSTEM jest zawarta w ka偶dej instancji serwera Oracle. Jako uzupe艂nienie przestrzeni tabel SYSTEM zaleca si臋 zbudowanie dodatkowych przestrzeni tabel:
Przestrze艅 tabel |
Opis |
TEMP |
Zawiera segmenty tymczasowe u偶ywane np. przy sortowaniu |
RBS |
Zawiera dodatkowe segmenty wycofania. (Nie mo偶na utworzy膰 przestrzeni tabel o nazwie rollback poniewa偶 s艂owo ROLLBACK jest s艂owem kluczowym). |
TOOLS |
Przeznaczona na tabele u偶ywane przez narz臋dzia serwera Oracle. |
APPLI_DATA |
Zawiera dane produkcyjne, u偶ywane przez aplikacje. Mo偶e istnie膰 wiele przestrzeni tabel dla danych produkcyjnych, co b臋dzie omawiane w dalszej cz臋艣ci lekcji. |
APPLI_INDEX |
Przeznaczona na indeksy zwi膮zane z danymi produkcyjnymi z przestrzeni tabel APPLI_DATA. Mo偶e istnie膰 wiele indeksowych przestrzeni tabel |
Charakterystyka Danych
Przed zaprojektowaniem struktury przestrzeni tabel w bazie danych nale偶y rozwa偶y膰 w艂asno艣ci przechowywanych danych.
Pozwoli to na:
Minimalizacj臋 fragmentacji.
Zmniejszenie efektu rywalizacji o dysk.
Oddzielenie segment贸w.
Na niekt贸rych platformach program instalacyjny Oracle utworzy pewn膮 liczb臋 predefiniowanych przestrzeni tabel.
Minimalizacja Fragmentacji
W celu minimalizacji fragmentacji oddzielamy grupy obiekt贸w z r贸偶n膮 charakterystyk膮 fragmentacji umieszczaj膮c je w innych przestrzeniach tabel.
Typ Segmentu |
Charakterystyka fragmentacji |
Segmenty s艂ownika danych |
Brak sk艂onno艣ci do fragmentacji, nigdy nie dziel膮 wolnej przestrzeni. |
Segmenty danych aplikacji |
Ma艂a sk艂onno艣膰 do fragmentacji, poniewa偶 tabele maj膮 okre艣lon膮 przestrze艅 zgodn膮 z wymaganiami projektu. |
Pomocnicze segmenty aplikacyjne |
艢rednia sk艂onno艣膰 do fragmentacji. |
Segmenty wycofania |
艢rednia sk艂onno艣膰 do fragmentacji |
Segmenty tymczasowe |
艢rednia sk艂onno艣膰 do fragmentacji |
Oddzielanie Segment贸w
Rozdzielanie grupy segment贸w reprezentuj膮ce obiekty z inn膮 charakterystyk膮 operacyjn膮 umieszczaj膮c je w r贸偶nych przestrzeniach tabel.
Kiedy Oddziela膰 Grupy
Oddzielamy grupy:
Segment贸w o r贸偶nych wymaganiach archiwizacji.
Segment贸w o innych wymaganiach dotycz膮cych dost臋pu.
Segment贸w o innej cz臋sto艣ci ich u偶ywania.
Segmenty o r贸偶nych wymaganiach przestrzeni.
Korzy艣ci z Oddzielania Grup
Archiwizacja i odtwarzanie.
Archiwizacja i odtwarzanie jest prostsza kiedy dane zwi膮zane z okre艣lon膮 aplikacj膮 s膮 oddzielone od danych aplikacji.
Archiwizacja jest szybsza je艣li dotyczy przestrzeni tabel tylko do odczytu.
Planowanie rozmiar贸w.
Szacowanie i pomiar przyrostu danych w projekcie jest prostsze je艣li dane zwi膮zane z okre艣lonym projektem s膮 oddzielone od danych innego projektu.
Bezpiecze艅stwo
Zapewnienie bezpiecze艅stwa jest prostsze w implementacji je艣li manipulacja uprawnieniami do bazy danych u偶ytkownik贸w dotyczy grup obiekt贸w.
Usuwanie
Archiwizacja lub usuwanie danych zwi膮zanych z zako艅czonym projektem jest 艂atwiejsze je艣li dane projektu przechowywane s膮 niezale偶nie od danych innych projekt贸w.
Umiejscowienie Plik贸w Bazy Danych
Zabezpieczamy baz臋 danych maksymalizuj膮c jednocze艣nie pojemno艣膰 i wydajno艣膰.
Umiejscowienie Plik贸w Bazy Danych
Zachowuj przynajmniej dwie aktywne kopie pliku kontrolnego bazy danych na przynajmniej dw贸ch urz膮dzeniach fizycznych.
U偶ywaj zwielokrotnionych plik贸w dziennika powt贸rze艅 umieszczaj膮c elementy grupy na r贸偶nych dyskach.
Umieszczaj przestrzenie tabel, kt贸rych dane mog膮 powodowa膰 rywalizacj臋 o dysk na r贸偶nych fizycznych dyskach (stripping).
Tworzenie Bazy Danych
W celu utworzenia bazy danych Oracle podajemy nast臋puj膮ce kroki:
Wybierz unikaln膮 nazw臋 instancji, rozmiar bloku, zestaw znak贸w bazy danych, maksymaln膮 liczb臋 plik贸w dziennika.
Przygotuj plik parametr贸w (init<SID>.ora.).
Ustaw odpowiednie zmienne systemu operacyjnego.
Uruchom Serwer Manager w trybie linii polece艅 i pod艂膮cz si臋 jako sysdba.
Wystartuj instancj臋 (STARTUP NOMOUNT)
Utw贸rz baz臋 danych
Powy偶sze kroki wykonywane s膮 zwykle przez skrypt instalacyjny. Nast臋pnie DBA powinien zainstalowa膰 s艂ownik danych, perspektywy importu/eksportu i dodatkowe opcje swojej licencji.
Wyb贸r Nazwy Instancji
Musimy wybra膰 unikaln膮 nazw臋 dla instancji. Na pewnych platformach, takich jak UNIX, nazwa instancji jest zawarta w nazwie pliku parametr贸w.
Przyk艂ad
Wy艣wietli膰 pliki parametr贸w w katalogu dbs.
% ls $ORACLE_HOME/dbs/init*.ora |
/home/oraclev7/dbs/init.ora /home/oraclev7/dbs/initEDUC7.ora /home/oraclev7/dbs/initDBA01.ora |
Domy艣lnie nazwa pliku parametr贸w instancji o nazwie TEST w systemie UNIX to initTEST.ora umieszczona w katalogu $ORACLE_HOME/dbs.
Konkretna metoda sprawdzenia jakie instancje s膮 uruchomione w systemie zale偶y od systemu operacyjnego.
W systemie UNIX wy艣wietlamy wszystkie procesy wprowadzaj膮c nast臋puj膮ce polecenie:
ps -ef lub ps -ax |
W ten spos贸b wy艣wietlamy uruchomione procesy drugoplanowe wszystkich instancji bazy danych Oracle. Nazwa instancji b臋dzie zawiera膰 si臋 w nazwie jej proces贸w drugoplanowych.
Przygotowanie Pliku Parametr贸w
Plik parametr贸w, nazywany zwykle plikiem init<SID>.ora to plik tekstowy, kt贸ry mo偶emy dopasowa膰 do swoich potrzeb u偶ywaj膮c standardowego edytora systemu operacyjnego.
Plik parametr贸w jest odczytywany tylko w momencie startu instancji. Je艣li zosta艂 zmieniony, aby zmiany odnios艂y skutek trzeba zamkn膮膰 i ponownie uruchomi膰 instancj臋.
Powody Modyfikowania Pliku Parametr贸w
Parametry w pliku init<SID>.ora maj膮 istotny wp艂yw na efektywno艣膰 bazy danych, lub te偶 musz膮 zosta膰 dopasowane do wymaga艅 produkcyjnych bazy danych:
Rozmiary sk艂adnik贸w Globalnego Obszaru Systemowego (SGA).
Warto艣ci domy艣lne dla bazy danych i instancji.
Ograniczenia bazy danych.
Definicja (istotna tylko przy tworzeniu) r贸偶nych cech fizycznych bazy danych, takich jak rozmiar bloku bazy danych.
Specyfikacja plik贸w kontrolnych, archiwizowanych plik贸w dziennika i plik贸w 艣ledzenia.
Optymalizacja efektywno艣ci przez dopasowanie rozmiar贸w struktur pami臋ci.
Definicja r贸偶nych parametr贸w funkcjonalnych.
Cechy pliku parametr贸w:
Warto艣ci parametr贸w mog膮 by膰 liczbami ca艂kowitymi, napisami lub warto艣ciami logicznymi.
Linie komentarzy rozpoczynaj膮 si臋 od symbolu #.
Wi臋kszo艣膰 parametr贸w posiada warto艣ci domy艣lne.
Edycja Pliku Parametr贸w
Podczas przygotowywania nowej bazy danych powinni艣my okre艣li膰 ustawienia pewnych parametr贸w. Warto艣ci innych mog膮 pozosta膰 domy艣lne.
Parametry Kt贸re Powinny By膰 Ustawione
Parametr |
Opis |
DB_NAME |
Maksymalnie o艣mioznakowy identyfikator bazy danych. Jedyny parametr obowi膮zkowy podczas tworzenia nowe bazy danych. |
CONTROL_FILES |
Nazwy plik贸w kontrolnych |
DB_BLOCK_SIZE |
Rozmiar (w bajtach) bloku danych bazy danych Oracle. Domy艣lnie 2048 |
SHARED_POOL_SIZE |
Rozmiar (w bajtach) obszaru dzielonego. Domy艣lnie 3500000 |
BACKGROUND_DUMP_DEST |
Miejsce tworzenia plik贸w 艣ladu proces贸w t艂a. |
USER_DUMP_DEST |
Miejsce tworzenia plik贸w 艣ladu u偶ytkownik贸w. |
DB_BLOCK_BUFFERS |
Liczba blok贸w buforowych w SGA. Domy艣lnie 32 |
Wskaz贸wki Ustawienia Parametr贸w Init<SID>.ora
Zawsze podaj co najmniej dwie nazwy plik贸w kontrolnych w pliku parametr贸w, umieszczone, je艣li to mo偶liwe, na r贸偶nych dyskach.
Je艣li jest ustawione DB_NAME, warto艣膰 musi by膰 zgodna z nazw膮 bazy danych zapisan膮 w plikach kontrolnych.
Najcz臋艣ciej Modyfikowane Parametry
Parametr |
Opis |
AUDIT_TRAIL |
W艂膮cza lub wy艂膮cza zapis do dziennika obserwacji |
IFILE |
Nazwa innego pliku parametr贸w jaki ma by膰 u偶yty przy starcie. |
LOG_BUFFER |
Liczba bajt贸w zarezerwowana na bufor dziennika powt贸rze艅 w SGA. |
LOG_ARCHIVE_START |
W艂膮cza lub wy艂膮cza automatyczn膮 archiwizacj臋 dziennika je艣li baza jest w trybie ARCHIVELOG. |
LOG_ARCHIVE_FORMAT |
Domy艣lny format archiwizowanych plik贸w dziennika |
LOG_ARCHIVE_DEST |
Miejsce archiwizowania plik贸w dziennika powt贸rze艅 |
LOG_CHECKPOINT_INTERVAL |
Ustawienie cz臋stotliwo艣ci punkt贸w kontrolnych |
LOG_CHECKPOINT_TIMEOUT |
Okresowe wykonywanie punkt贸w kontrolnych |
MAX_DUMP_FILE_SIZE
|
Maksymalny rozmiar (wyra偶ony w blokach systemu operacyjnego) plik贸w 艣ladu. |
OPEN_CURSORS |
Maksymalna liczba kursor贸w otwieranych jednocze艣nie przez u偶ytkownika. |
PROCESSES |
Maksymalna liczba proces贸w systemu operacyjnego pod艂膮czonych jednocze艣nie do tej instancji. |
ROLLBACK_SEGMENTS |
Nazwy segment贸w wycofania utworzonych dla tej instancji. |
SQL_TRACE |
W艂膮cza lub wy艂膮cza narz臋dzie 艣ledzenia SQL dla wszystkich sesji u偶ytkownika. |
TIMED_STATISTICS |
W艂膮cza lub wy艂膮cza pomiar czas贸w w 艣ladach i w ekranach Performance Monitora. |
Uwaga: Wszystkie te parametry s膮 opcjonalne. Je艣li kt贸ry艣 z nich nie ma przypisanej warto艣ci, stosowana jest warto艣膰 domy艣lna.
Przyk艂ad:
db_name=ORCL
# db_files = 1024 # INITIAL
# db_files = 80 # SMALL
db_files = 400 # MEDIUM
# db_files = 1000 # LARGE
control_files = (E:\database\ctl1orcl.ora, E:\database\ctl2orcl.ora)
db_file_multiblock_read_count = 8 # INITIAL
# db_file_multiblock_read_count = 8 # SMALL
# db_file_multiblock_read_count = 16 # MEDIUM
# db_file_multiblock_read_count = 32 # LARGE
db_block_buffers = 200 # INITIAL
# db_block_buffers = 100 # SMALL
# db_block_buffers = 550 # MEDIUM
# db_block_buffers = 3200 # LARGE
#shared_pool_size = 10000000 # INITIAL
shared_pool_size = 2530000 # SMALL
# shared_pool_size = 5000000 # MEDIUM
# shared_pool_size = 9000000 # LARGE
log_checkpoint_interval = 10000
processes = 59 # INITIAL
# processes = 50 # SMALL
# processes = 100 # MEDIUM
# processes = 200 # LARGE
log_buffer = 8192 # INITIAL
# log_buffer = 8192 # SMALL
# log_buffer = 32768 # MEDIUM
# log_buffer = 163840 # LARGE
audit_trail = true # if you want auditing
timed_statistics = true # if you want timed statistics
max_dump_file_size = 10240 # limit trace file size to 5 Meg each
# log_archive_start = true
# log_archive_dest = e:\kurs\database\db1
# log_archive_format = "%%ORACLE_SID%%T%TS%S.ARC"
# rollback_segments = (name1, name2)
background_dump_dest=E:\database\trace
user_dump_dest=E:\database\trace
db_block_size = 2048
remote_login_passwordfile = exclusive
Ustawienie Identyfikatora Systemowego
Identyfikator systemowy SID (od ang. System IDentifier) to zmienna 艣rodowiska u偶ywana przez serwer Oracle do okre艣lenia instancji, do jakiej u偶ytkownik si臋 pod艂膮cza.
Ustawienie Zmiennej
Przed wystartowaniem instancji sprawdzamy poprawno艣膰 ustawienia SID. Je艣li SID nie jest ustawiony poprawnie, nale偶y tego dokona膰 u偶ywaj膮c odpowiedniego polecenia systemu operacyjnego.
Przyk艂ady
Ustawienia warto艣ci ORACLE_SID na TEST pod systemem UNIX i nast臋pnie sprawdzanie warto艣ci.
$ ORACLE_SID=TEST;export ORACLE_SID $ echo $ORACLE_SID TEST |
Warto艣膰 SID mo偶e mie膰 do 8 znak贸w w UNIXie, do 4 znak贸w w Windows NT.
Zmieniaj膮c warto艣膰 identyfikatora systemowego mo偶emy pod艂膮czy膰 si臋 do r贸偶nych baz danych.
Uuchomienie Instancji
Instancj臋 uruchamiamy u偶ywaj膮c polecenia STARTUP, tak jak pokazano poni偶ej.
Przyk艂ad
Wystartowanie instancji w trybie NOMOUNT.
SVRMGR> STARTUP NOMOUNT |
Uruchamianie Instancji
Klauzula PFILE=init<SID>.ora mo偶e by膰 niezb臋dna w poleceniu STARTUP je偶eli plik parametr贸w nie znajduje si臋 w domy艣lnym miejscu.
Zostan膮 uruchomione cztery procesy t艂a: DBWR, LGWR, SMON oraz PMON.
Tworzenie Bazy Danych
Baza danych Oracle sk艂ada si臋 z plik贸w danych przechowuj膮cych tabele i indeksy, plik贸w dziennika powt贸rze艅 stanowi膮cych cz臋艣膰 systemu odtwarzania serwera Oracle oraz plik贸w kontrolnych zawieraj膮cych informacje niezb臋dne do uruchomienia i obs艂ugi bazy danych.
Sk艂adnia:
gdzie:
baza danych nazwa danych jaka ma by膰 tworzona.
spec.pliku specyfikacja pliku danych lub dziennika w formacie: nazwa [SIZE n] [K lub M] [REUSE]
CONTROLFILE REUSE 偶膮da ewentualnego zamazania istniej膮cego pliku kontrolnego wyspecyfikowanego w pliku parametr贸w.
LOGFILE GROUP okre艣la nazwy plik贸w dziennika jakie maj膮 by膰 u偶ywane i grup臋 do kt贸rej nale偶膮.
MAXLOGFILES jest maksymaln膮 liczb膮 plik贸w dziennika tworzonych w bazie danych.
MAXLOGMEMBERS jest maksymaln膮 liczb膮 element贸w w grupie plik贸w dziennika powt贸rze艅.
MAXLOGHISTORY jest maksymaln膮 liczb膮 archiw贸w dziennika powt贸rze艅 w automatycznym odtwarzaniu no艣nik贸w w Oracle Parallel Serwer.
DATAFILE spec. pliku okre艣la pliki danych jakie maj膮 by膰 u偶yte.
MAXDATAFILES jest maksymaln膮 liczb膮 plik贸w danych tworzonych w bazie danych.
MAXINSTANCES maksymalna liczba instancji jakie jednocze艣nie mog膮 zamontowa膰 i otworzy膰 baz臋 danych.
ARCHIVELOG 偶膮da, aby pliki dziennika powt贸rze艅 by艂y przed ich powt贸rnym u偶yciem archiwizowane.
NOARCHIVELOG stwierdza, 偶e dzienniki powt贸rze艅 mog膮 by膰 ponownie zapisywane przed archiwizacj膮 ich zawarto艣ci.
EXCLUSIVE po utworzeniu montuje baz臋 danych w trybie wy艂膮cznym.
CHARACTERSET zestaw znak贸w u偶ywanych w bazie do przechowywania danych.
Je偶eli w specyfikacji pliku podano opcj臋 REUSE, plik taki musi ju偶 istnie膰. W przeciwnym przypadku konieczna jest opcja SIZE, a podany plik istnie膰 nie mo偶e.
Przyk艂ady
Utworzenie bazy danych o nazwie TEST z jednym plikiem danych o nazwie system.dbf i rozmiarze 10 MB, a tak偶e dwoma plikami dziennika o nazwie log1a.rdo oraz log2a.rdo, ka偶da rozmiaru 500 KB. Zestaw znak贸w pozostanie domy艣lny, czyli US7ASCII.
SVRMGR>聽CREATE DATABASE test 聽聽 聽聽聽2>聽DATAFILE `/u02/Oracle/DBA1/system.dbf' SIZE 10M 聽聽聽3>聽LOGFILE 聽聽聽4> GROUP 1 `/u01/Oracle/DBA1/log1a.rdo' SIZE 500K, 聽聽聽5> GROUP 2 `/u01/Oracle/DBA1/log1a.rdo' SIZE 500K; |
Utworzenie bazy danych z 8-bitowym zestawem znak贸w i zwielokrotnionymi dziennikami powt贸rze艅.
SVRMGR>聽CREATE DATABASE test 聽聽聽2>聽DATAFILE `/u02/Oracle/DBA1/system.dbf' SIZE 10M 聽聽聽3>聽LOGFILE GROUP 1 聽聽聽4> (`/u01/Oracle/DBA1/log1a.rdo', 聽聽聽5> `/u02/Oracle/DBA1/log1a.rdo') SIZE 500K, 聽聽聽6> GROUP 2 (`/u01/Oracle/DBA1/log1a.rdo', 聽聽聽聽聽聽聽聽聽聽聽聽聽7>聽`/u02/Oracle/DBA1/log1a.rdo') SIZE 500K 聽聽聽聽聽聽聽聽聽聽聽聽聽8>聽CHARACTER SET WE8ISO8859P1;
|
Wskaz贸wki :
Je艣li nie wyspecyfikowano pe艂nych nazw dziennika pliki b臋d膮 utworzone w katalogu domy艣lnym systemu.
Polecenie CREATE DATABASE mo偶e trwa pewien czas z powodu zada艅 jakie wykonuje w tle.
Dodawanie Pliku Kontrolnego
Plik kontrolny jest odczytywany w chwili uruchamiania bazy danych. Je艣li nie zostanie znaleziony, uruchomienie si臋 nie powiedzie. Zapewniamy, 偶e przynajmniej dwa pliki kontrolne opisuj膮 nasz膮 baz臋 danych wykonuj膮c nast臋puj膮ce kroki:
Procedura Dodawania Pliku Kontrolnego
1. Zamknij baz臋 danych.
2. Skopiuj istniej膮cy plik kontrolny w nowe miejsce.
3. Zmodyfikuj plik parametr贸w tak, aby zawiera艂 nazw臋 nowej kopii.
4. Uruchom baz臋 danych ze zmodyfikowanym plikiem parametr贸w.
Powy偶sze kroki zak艂adaj膮, 偶e istnieje tylko jeden plik kontrolny. S膮 one zb臋dne, je艣li od razu utworzymy baz臋 danych ze zwielokrotnionymi plikami kontrolnymi. Nale偶y tak偶e zapewni膰, aby serwer Oracle mia艂 prawa odczytu i zapisu do nowoutworzonego pliku kontrolnego.
Przyk艂ad (unix)
SVRMGR> SHUTDOWN SVRMGR> HOST ed init.ora CONTROL_FILES=(path/file1, path/file2) SVRMGR>聽CONNECT / AS SYSDBA SVRMGR>聽STARTUP PFILE=init.file |
Je艣li plik kontrolny zostanie uszkodzony, to trzeba go stworzy膰 na nowo poleceniem CREATE CONTROLFILE (przy otwartej instancji i niezamontowanej bazie danych).
Dodawanie Elementu Dziennika Powt贸rze艅
Pliki dziennika powt贸rze艅 nie musz膮 by膰 punktem krytycznym dla bezpiecze艅stwa bazy danych Oracle. Unikamy tego problemu przez zapewnienie, aby ka偶da grupa plik贸w dziennika mia艂a wi臋cej ni偶 jeden element.
Mo偶emy doda膰 element do grupy dziennika powt贸rze艅 poleceniem ALTER DATABASE.
Sk艂adnia:
gdzie:
baza danych nazwa bazy jaka jest zmieniana
plik nazwa pliku w systemie operacyjnym
GROUP number numer grupy plik贸w dziennika, gdzie ma by膰 dodany element
Je偶eli u偶yjemy opcji REUSE, wskazany plik musi istnie膰, w przeciwnym przypadku zostanie on utworzony w takim rozmiarze, jak inne elementy jego grupy.
W celu sprawdzenia bie偶膮cego stanu plik贸w dziennika sprawdzamy perspektyw臋 s艂ownika danych V$LOG. W V$LOGFILE ogl膮damy pe艂ne nazwy plik贸w dziennika powt贸rze艅. Z艂膮czenie V$LOG i V$LOGFILE pozwoli na obejrzenie jednocze艣nie pe艂nej nazwy i statusu.
Przyk艂ad
Modyfikacja bazy danych TEST polegaj膮ca na dodaniu pliku dziennika o nazwie log1b.rdo do grupy 1 oraz weryfikacja efekt贸w.
SVRMGR>聽ALTER DATABASE test 2>聽ADD LOGFILE MEMBER `/u02/Oracle/ DBA01/log1b.rdo' 3>聽TO GROUP 1; |
SQL>聽SELECT * FROM v$logfile; |
GROUP # STATUS MEMBER -------- -------- --------------------------------------- 1 /u01/Oracle/ DBA01/1og1a.rdo 2 /u01/Oracle/ DBA01/1og2a.rdo 1 /u02/Oracle/ DBA01/1og1b.rdo |
Uwaga: Po dodaniu nowego elementu do plik贸w dziennika perspektywa V$LOGFILE mo偶e pokazywa膰, 偶e STATUS pewnych plik贸w jest niepoprawny (INVALID), co oznacza 偶e nie zosta艂y one jeszcze zapisane przez LGWR. To jest normalny efekt, pliki stan膮 si臋 poprawne jak tylko instancja zacznie ich u偶ywa膰.
Aby instancja u偶y艂a nowo dodane pliki dziennika powt贸rze艅 nale偶y wymusi膰 prze艂膮czenie grup dziennika poleceniem ALTER SYSTEM SWITCH LOGFILE.
Zmiana Rozmiaru Element贸w Grupy Dziennika Powt贸rze艅
Nie ma bezpo艣redniego sposobu na zmian臋 element贸w grupy dziennika powt贸rze艅. Zamiast tego nale偶y utworzy膰 nowe grupy o innym rozmiarze po czym usun膮膰 stare grupy.
Tworzenie Pliku Hase艂
Je艣li zdecydujemy si臋 na u偶ywanie pliku hase艂 do identyfikacji u偶ytkownik贸w pe艂ni膮cych funkcje administracyjne, musimy dokona膰 nast臋puj膮cych czynno艣ci:
Tworzenie Pliku Hase艂
Utw贸rz plik hase艂 u偶ywaj膮c narz臋dzia ORAPWD:
ORAPWD FILE=orapwdSID PASSWORD=secret ENTRIES=30
Plik hase艂 zostanie utworzony w katalogu $ORACLE_HOME/dbs./Ustaw warto艣膰 parametru inicjalizacji REMOTE_LOGIN_PASSWORDFILE na EXCLUSIVE.
Pod艂膮cz si臋 jako SYDBA i uruchom ponownie baz臋 danych, aby odczyta艂a nowe ustawienie parametru REMOTE_LOGIN_PASSWORDFILE.
Nadaj uprawnienia SYSDBA lub SYSOPER administratorom bazy danych.
GRANT SYSDBA TO administrator.Je艣li chcesz administrowa膰 baz膮 danych z oddalonej maszyny klienta, za pomoc膮 FTP prze艣lij tam initSID.ora.
Aby teraz administrowa膰 baz膮 danych nale偶y uruchomi膰 Server Manager na maszynie klienta i pod艂膮czy膰 si臋 jako SYSDBA.
Jacy u偶ytkownicy maj膮 przyznane uprawnienia systemowe SYSDBA i SYSOPER mo偶emy sprawdzi膰 wykonuj膮c zapytanie na perspektywie bazy danych V$PWFILE_USERS.
S艂ownik Danych
Jedn膮 z najwa偶niejszych cz臋艣ci danych Oracle jest s艂ownik danych. S艂ownik danych to zestaw tabel i perspektyw u偶ywanych tylko do odczytu w celu uzyskania informacji o bazie danych. S艂ownik bazy danych jest tworzony przez plik polece艅 sql.bsq.
Zawarto艣膰 S艂ownika Danych
Nazwy u偶ytkownik贸w serwera Oracle.
Informacja o uprawnieniach i rolach nadanych ka偶demu u偶ytkownikowi.
Nazwy i definicje obiekt贸w w schematach.
Warunki integralno艣ci.
Przydzia艂 pami臋ci obiektom bazy danych.
Og贸lna struktura bazy danych.
Informacje kontroli i 艣ledzenia.
Pami臋tane procedury i wyzwalacze bazy danych.
Tworzenie Dodatkowych Perspektyw S艂ownika Danych
Niekt贸re spo艣r贸d plik贸w rozkazowych SQL (inaczej skrypt贸w) Oracle wykonuj膮 pewne funkcje na s艂owniku danych i powinny by膰 uruchomione podczas lub po utworzeniu bazy danych.
Skrypty Uruchamiane Po Utworzeniu Bazy Danych
Skrypt |
Zadanie |
catalog.sql |
Tworzenie cz臋sto u偶ywanych perspektyw s艂ownika danych
|
Catproc.sql |
Uruchomienie wszystkich skrypt贸w wymaganych do u偶ywania PL/SQL po stronie serwera. |
U偶ytkownicy S艂ownika Danych
S艂ownik bazy danych jest centralnym 藕r贸d艂em informacji dla serwera Oracle i u偶ytkownik贸w bazy danych.
U偶ytkownicy S艂ownika Danych
Administratorzy bazy danych
U偶ytkownicy bazy danych
Aplikacje
Serwer Oracle
Nigdy nie u偶ywa si臋 polece艅 DML, takich jak INSERT, UPDATE, czy DELETE do bezpo艣redniej modyfikacji tabel bazowych s艂ownika danych. S艂ownik jest modyfikowany niejawnie przez polecenia DDL. Sprawdzamy zawarto艣膰 s艂ownika danych przez wykonywanie zapyta艅 na odpowiednich tabelach i perspektywach.
U偶ytkownicy S艂ownika Danych
Kategorie S艂ownika Danych
S艂ownik danych sk艂ada si臋 z zestawu tabel bazowych i ze zwi膮zanych z nimi perspektyw, kt贸re mog膮 by膰 podzielone na nast臋puj膮ce kategorie:
Kategoria |
Opis |
USER_xxx |
Perspektywy dost臋pne dla ka偶dego u偶ytkownika dostarczaj膮ce informacji o jego w艂asnych obie. |
ALL_xxx |
Perspektywy dost臋pne dla ka偶dego u偶ytkownika dostarczaj膮ce informacji o wszystkich obiektach do kt贸rych ten u偶ytkownik ma dost臋p. |
DBA_xxx |
Perspektywy dost臋pne tylko dla DBA, dostarczaj膮ce informacji o definicjach wszystkich obiekt贸w w bazie danych. |
zgodne z ANSI |
Synonimy takie jak MYPRIVS czy ACCESSIBLE_TABLES utworzone dla zachowania zgodno艣ci z ANSI. |
Cechy S艂ownika Danych
Wszystkie tabele i perspektywy s艂ownika danych nale偶膮 do u偶ytkownik贸w sys.
Dla perspektyw ALL_xxx i USER_xxx s膮 utworzone publiczne synonimy.
Przyrostki nazw s膮 zgodne mi臋dzy trzema pierwszymi kategoriami perspektyw serwera Oracle.
Perspektywy USER_xxx nie maj膮 kolumny OWNER (w艂a艣ciciel)
Wiele perspektyw DBA_xxx nie ma odpowiednika w perspektywach USER_xxx
i ALL_xxx.
Nazwy wszystkich perspektyw s艂ownika danych mo偶emy uzyska膰 z perspektywy DICTIONARY.
Przegl膮danie Perspektyw S艂ownika Danych
Przyk艂ady
Wy艣wietlanie informacji DBA o kontach w serwerze Oracle z u偶yciem definicji kolumn takich jak w poprzednim przyk艂adzie.
SQL> SELECT username, user_id, password, default_tablespace, temporary_tablespace FROM dba_users |
USERNAME USER_ID PASSWORD DEFAULT_TABLESPACE TEMPORARY_TABLESPACE
------------- ----- ------------------ ------------------ -----------------------
SYS 0 15C146A39C91814D SYSTEM SYSTEM
TUTORIAL15 115 565CD49962C3CCCA USER_DATA TEMPORARY_DATA
TUTORIAL16 116 5B61BB5091C4FDBB USER_DATA TEMPORARY_DATA
SYSTEM 5 87C4ECFB800A8C3D USER_DATA TEMPORARY_DATA
CTXSYS 22 EXTERNAL USER_DATA USER_DATA
DEMO 21 EXTERNAL USER_DATA TEMPORARY_DATA
SCOTT 20 F894844C34402B67 USER_DATA TEMPORARY_DATA
ZOLNIERZ 28 9546719E1D5CBD6B USER_DATA TEMPORARY_DATA
REP 46 EA472EF9486DC053 REPOSITORY_DATA TEMPORARY_DATA
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Identyfikacja wszystkich segment贸w wycofania i ich statusu.
SQL>SELECT segment_name, status FROM dba_rollback_segs |
SEGMENT_NAME STATUS
------------------------------ ----------------
SYSTEM ONLINE
RB1 ONLINE
RB2 ONLINE
RB3 ONLINE
RB4 ONLINE
RB5 ONLINE
RB6 ONLINE
RB7 ONLINE
RB8 OFFLINE
RB9 OFFLINE
RB10 OFFLINE
RB11 OFFLINE
RB12 OFFLINE
Wy艣wietlanie informacji o definicjach przestrzeni tabel.
SQL> SELECT TABLESPACE_NAME, INITIAL_EXTENT, NEXT_EXTENT, STATUS, CONTENTS FROM dba_tablespaces |
TABLESPACE_NAME INITIAL_EX NEXT_EXTEN STATUS CONTENTS
------------------------------ ---------- ---------- --------- ---------
SYSTEM 10240 10240 ONLINE PERMANENT
USER_DATA 10240 10240 ONLINE PERMANENT
ROLLBACK_DATA 10240 10240 ONLINE PERMANENT
TEMPORARY_DATA 10240 10240 ONLINE PERMANENT
REPOSITORY_DATA 10240 10240 ONLINE PERMANENT
INDEX_DATA 10240 10240 ONLINE PERMANENT
Wy艣wietlanie nazw plik贸w danych nale偶膮cych do naszej bazy danych.
SQL> SELECT file_name, file_id, tablespace_name, bytes, blocks, status FROM dba_data_files; |
FILE_NAME FILE_ID TABLESPACE_NAME BYTES BLOCKS STATUS
----------------------------- --- ----------------- ---------- ------ ---------
D:\ORANT\DATABASE\USR1ORCL.ORA 2 USER_DATA 115343360 56320 AVAILABLE
D:\ORANT\DATABASE\RBS1ORCL.ORA 3 ROLLBACK_DATA 36700160 17920 AVAILABLE
D:\ORANT\DATABASE\TMP1ORCL.ORA 4 TEMPORARY_DATA 17825792 8704 AVAILABLE
D:\ORANT\DATABASE\SYS1ORCL.ORA 1 SYSTEM 167772160 81920 AVAILABLE
D:\ORANT\DATABASE\REPORCL.ORA 5 REPOSITORY_DATA 2097152 1024 AVAILABLE
D:\ORANT\DATABASE\IND1ORCL.ORA 6 INDEX_DATA 55267328 26986 AVAILABLE
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Wy艣wietlanie informacji o nieu偶ywanych obszarach w bazie danych.
SQL> SELECT * FROM dba_free_space; |
TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS
------------------------------ ---------- ---------- ---------- ----------
SYSTEM 1 75101 40960 20
SYSTEM 1 49111 61440 30
SYSTEM 1 77666 8714240 4255
SYSTEM 1 70531 40960 20
USER_DATA 2 19822 204800 100
USER_DATA 2 5392 112640 55
USER_DATA 2 10632 112640 55
USER_DATA 2 31913 81920 40
ROLLBACK_DATA 3 16186 3553280 1735
TEMPORARY_DATA 4 1861 14016512 6844
REPOSITORY_DATA 5 312 30720 15
INDEX_DATA 6 26964 47104 23
Podsumowanie
Baz臋 danych tworzymy w 8 krokach:
Zaprojektowanie struktury bazy danych optymalizuj膮cej efektywno艣膰 i minimalizuj膮cej fragmentacj臋.
Przygotowanie 艣rodowiska systemu operacyjnego do tworzenia bazy danych.
Utworzenie pliku parametr贸w.
Wystartowanie instancji.
Wykonanie polecenia CREATE DATABASE.
Zapewnienie bezpiecze艅stwa bazy danych przez zwielokrotnienie plik贸w dziennika powt贸rze艅 i plik贸w kontrolnych.
Utworzenie pliku hase艂.
Zdefiniowanie tabel i perspektyw s艂ownika danych do zarz膮dzania baz膮 danych.
Zadania
Obejrzyj perspektyw臋 V$CONTROLFILE i sprawd藕, ile masz plik贸w kontrolnych
Dodaj nowy plik kontrolny (ctl2adm#.ora) i sprawd藕, czy jest u偶ywany
Napisz polecenia dodaj膮ce do ka偶dej grupy po jednym pliku dziennika powt贸rze艅聽(e:\kurs\database\db#\lg3adm#.ora i聽e:\kurs\database\db#\lg4adm#.ora) i spraw, by obydwa nowe pliki zosta艂y u偶yte
Utw贸rz nowego u偶ytkownika ADMIN/ADMIN poleceniem CREATE USER ADMIN IDENTIFIED BY ADMIN i nadaj mu uprawnienia SYSDBA i SYSOPER poleceniem GRANT SYSDBA, SYSOPER TO ADMIN. Co si臋 sta艂o?
Zmie艅 ustawienia w pliku parametr贸w tak, aby mo偶na by艂o nada膰 u偶ytkownikowi ADMIN uprawnienie SYSDBA i SYSOPER i zrestartuj baz臋. Spr贸buj ponownie nada膰 uprawnienia.
Sprawd藕 perspektyw臋 V$PWFILE_USERS, aby sprawdzi膰 czy nadanie praw si臋 powiod艂o
Obejrzyj perspektyw臋 DICTIONARY
Obejrzyj perspektyw臋 DBA_TABLESPACES, DBA_DATA_FILES i DBA_FREE_SPACE. O czym 艣wiadczy wynik zapytania na DBA_FREE_SPACE?
IV.聽Wybieranie i aktualizacja danych
Cele
W tej lekcji wyja艣niamy procesy zachodz膮ce przy wybieraniu i aktualizacji danych oraz szczeg贸艂owy przebieg operacji SQL.
Po przerobieniu tej lekcji powiniene艣 potrafi膰:
Wyja艣ni膰 kroki przetwarzania polecenia SQL.
Rozpozna膰 korzy艣ci z obszaru dzielonego SQL Oracle.
Rozpozna膰 funkcje i zawarto艣膰 bufor贸w bazy danych.
Opisa膰 spos贸b w jaki serwer pobiera dane do bufor贸w bazy danych.
Rozpozna膰 zadanie procesu sekretarza bazy danych (DBWR).
Rozpozna膰 zdarzenia jakie powoduj膮 aktywacj臋 sekretarza bazy danych.
Przegl膮d
Ta lekcja wyja艣nia jak jest przetwarzane w pami臋ci polecenie SQL i w jaki spos贸b dokonuje si臋 modyfikacji danych.
Polecenie SQL s膮 przetwarzane przez proces serwera.
Identyczne polecenia SQL korzystaj膮 ze wsp贸lnego obszaru SQL.
Bufory bazy danych przechowuj膮 wcze艣niejszy obraz zmodyfikowanych danych w blokach wycofania a p贸藕niejszy obraz zmodyfikowanych danych w blokach danych.
Sekretarz bazy danych (DBWR) zapisuje wszystkie zmienione bufory na dysk.
Bufory Bazy Danych
Kiedy u偶ytkownik 偶膮da dost臋pu do danych proces serwera sprawdza w buforach bazy danych, czy nie ma tam ju偶 odpowiednich danych.
Bloki Danych
Je艣li brak danych w buforach, proces serwera odczytuje odpowiednie bloki z pliku danych i umieszcza je w buforach bazy danych, z kt贸rych ka偶dy ma rozmiar taki jak rozmiar bloku danych Oracle (DB_BLOCK_SIZE).
Je艣li u偶ytkownik zmodyfikuje otrzymane dane, zmiany pojawiaj膮 si臋 w blokach danych w buforach. Nowa wersja danych nazywana jest obrazem p贸藕niejszym (after image), poniewa偶 jest obrazem danych po dokonaniu zmian.
Bloki Wycofania
Oracle zachowuje oryginaln膮 wersj臋 danych w bloku wycofania. Ta wersja danych nazywana jest obrazem wcze艣niejszym (before image), poniewa偶 zawiera zachowane dane sprzed dokonania zmian przez u偶ytkownika. Je艣li u偶ytkownik zmieni swoj膮 decyzj臋 przed zatwierdzeniem zmiany w bazie danych, transakcja mo偶e by膰 wycofana dzi臋ki informacji zachowanej w bloku wycofania.
Bufor Dziennika Powt贸rze艅
Podczas przetwarzania transakcji, proces serwera zapisuje obraz wcze艣niejszy i obraz p贸藕niejszy w buforze dziennika powt贸rze艅. Ta informacja u偶ywana jest przy odtwarzaniu.
Kolejka (Lista LRU)
Bufory bazy danych zorganizowane s膮 w dw贸ch listach: lista brudna (dirty list) oraz kolejka (LRU od Last Recently Used). Lista brudna zawiera zmienione bufory, kt贸re nie zosta艂y zapisane na dysk.
Zawarto艣膰 Listy LRU
Typ bufora |
Opis |
Wolne bufory (free buffers) |
Bufory, kt贸re nie by艂y zmodyfikowane i s膮 gotowe do u偶ycia |
Bufory zaczepione (pinned buffers) |
Bufory obecnie u偶ywane. |
Bufory brudne (dirty buffers) |
Bufory zmodyfikowane, kt贸re trzeba zapisa膰 na dysk. |
Kiedy proces u偶ywa bufora, przenosi go na pocz膮tek (do ostatnio u偶ywanych) listy LRU. Brudne bufory stopniowo przesuwaj膮 si臋 na koniec (do najp贸藕niej u偶ywanych) listy LRU.
呕膮dania U偶ytkownik贸w
Wszystkie polecenia SQL przetwarzane s膮 przez proces serwera, kt贸ry otrzymuje 偶膮dania wprost od procesu u偶ytkownika. Proces serwera stosuje trzy g艂贸wne fazy przetwarzania: analiza (parse), wykonanie (execute) i sprowadzanie (fetch).
Proces serwera
Kiedy proces serwera musi odczyta膰 blok danych z dysku do bufora bazy danych to:
Przegl膮da list臋 LRU.
Poszukuje wolnego bufora.
Przesuwa brudne bufory do brudnej listy.
Proces serwera przerywa poszukiwania kiedy znajduje wolny bufor lub kiedy przejrzy okre艣lon膮 liczb臋 bufor贸w bez natrafienia na wolny.
Konfiguracja PGA
Obszar Globalny Programu (PGA od Program Global Area) to obszar pami臋ci zawieraj膮cy dane i informacje kontrolne pojedynczego u偶ytkownika lub procesu serwera. PGA jest rezerwowane przez serwer Oracle, kiedy proces u偶ytkownika pod艂膮cza si臋 do bazy danych Oracle i jest otwierana sesja.
Charakterystyka PGA
Obszar stosu (stack space) to pami臋膰 zarezerwowana na przechowanie zmiennych i tablic sesji.
Dane sesji u偶ytkownika (user session data) to dodatkowa pami臋膰 dla sesji u偶ytkownika.
PGA jest zapisywalny i nie jest dzielony.
Przetwarzanie Polecenia SQL
Analiza (parsing) to jeden z krok贸w przetwarzania polecenia SQL. Podczas wykonywania polecenia SQL Oracle wykonuje:
Analiz臋 (Parse)
Wykonanie (Execute)
Sprowadzanie (Fetch)
Analiza
Sprawdza sk艂adni臋 oraz poprawno艣膰 semantyczn膮.
Przegl膮da s艂ownik danych w celu rozpoznania obiekt贸w, uprawnie艅 i znalezienia najefektywniejszej 艣cie偶ki wyszukiwania (nazywanej drzewem analizy lub planem wykonania - parse tree lub execution plan).
Rezerwuje prywatne obszary SQL dla polecenia.
Drzewo analizy jest przechowywane w obszarze dzielonym. Wiele proces贸w serwera mo偶e korzysta膰 z tego samego drzewa analizy.
Serwer Oracle wykorzystuje pewn膮 przestrze艅 pami臋ci zwan膮 kursorem do zapisu informacji o statusie ka偶dego polecenia.
Wykonanie
Zastosowanie metod z drzewa analizy do bufor贸w danych.
Wykonanie fizycznych lub logicznych odczyt贸w i logicznych zapis贸w.
Sprawdzenie warunk贸w integralno艣ci.
Modyfikacja danych, je艣li zachodzi taka potrzeba.
Sprowadzanie
Pobiera wiersze danych dla polece艅 SELECT
Obszary Dzielone SQL
Oracle automatycznie zauwa偶a kiedy aplikacja wysy艂a do bazy danych identyczne polecenia SQL. Je偶eli wykonywane s膮 dwa identyczne polecenia, obszar SQL w kt贸rym wykonywane jest pierwsze z nich jest te偶 wykorzystywany przez drugie.
St膮d te偶, zamiast u偶ywa膰 wielu obszar贸w SQL dla identycznych polece艅 SQL, istnieje tylko jeden obszar SQL dla identycznych polece艅 SQL.
Identyczne Polecenia SQL
Polecenia SQL s膮 uwa偶ane za identyczne je偶eli:
Ich zapis jest absolutnie identyczny, z dok艂adno艣ci膮 do ma艂ych i wielkich liter, separator贸w itp.
Odwo艂uj膮 si臋 do samych obiekt贸w.
Typy i nazwy zmiennych s膮 identyczne.
Operacja SELECT
Operacja SELECT wymaga aby blok danych u偶ywany w kryteriach wyszukiwania znajdowa艂 si臋 w buforze bazy danych.
Operacja SELECT
Je艣li blok znajduje si臋 w pami臋ci wykonuje odczyt logiczny.
Je艣li bloku nie ma w pomi臋ci, wykonuje odczyt fizyczny.
Bloki nag艂贸wk贸w obiekt贸w umieszczone w buforach bazy danych nie s膮 umieszczane na tym i nast臋pnych diagramach, jako 偶e nie s膮 chwilowo dla nas istotne.
Kiedy to mo偶liwe (to znaczy przy pe艂nym przegl膮daniu tabel), serwer Oracle dokonuje odczyt贸w wieloblokowych (multiblock reads) do pomi臋ci.
Operacja UPDATE
Wszystkie operacje UPDATE wymagaj膮 segmentu wycofania do zapewnienia sp贸jno艣ci odczytu, mo偶liwo艣ci odtwarzania i wycofania.
Operacja Update
艢ci膮ga bloki danych do bufor贸w bazy danych.
艢ci膮ga bloki wycofania do bufor贸w bazy danych.
Nak艂ada blokady wy艂膮czne na wiersze przeznaczone do modyfikacji.
Dokonuje zapis贸w w buforze dziennika powt贸rze艅 identyfikuj膮cych obraz wcze艣niejszy.
Zapami臋tuje dane wycofania w buforze bloku segmentu wycofania.
Dokonuje zmian w buforze bloku danych.
Dokonuje zapis贸w w buforze dziennika powt贸rze艅 identyfikuj膮cych obraz p贸藕niejszy.
W艂asno艣ci Operacji UPDATE
Segment wycofania jest obiektem u偶ywanym do zapami臋tywania danych wycofania.
Serwer Oracle wszystkim odczytuj膮cym dane dostarcza sp贸jnego obrazu danych.
Operacja SELECT nazywana jest cz臋sto operacj膮 ODCZYTU. Odczytuj膮cy nie powoduj膮 blokowania zapisuj膮cych, zapisuj膮cy nie blokuj膮 odczytuj膮cych. Serwer Oracle osi膮ga ten efekt dzi臋ki zastosowaniu segment贸w wycofania.
Proces Sekretarza Bazy Danych (DBWR)
DBWR zarz膮dza buforami bazy danych w ten spos贸b, aby procesy serwera zawsze mog艂y znale藕膰 wolne bufory.
Proces DBWR
Zapisuje wszystkie zmodyfikowane bufory do plik贸w danych.
U偶ywa algorytmu LRU, aby ostatnio u偶ywane bloki pozostawa艂y w pami臋ci.
Optymalizuje I/O dzi臋ki op贸藕nianiu zapis贸w.
DBWR zapisuje brudne bufory na dysku kiedy:
Brudna lista osi膮gnie limit d艂ugo艣ci.
Proces przeszuka wskazan膮 liczb臋 bufor贸w na li艣cie LRU bez znalezienia wolnego bufora.
Wyst膮pi time-out procesu DBWR
Wyst膮pi punkt kontrolny.
Podsumowanie
Podczas odczytywania i modyfikacji danych:
Wszystkie polecenia SQL s膮 przetwarzane przez proces serwera, kt贸ry otrzymuje 偶膮dania bezpo艣rednio od procesu u偶ytkownika.
Kroki przetwarzania polecenia SQL to analiza, wykonanie i sprawdzanie.
Identyczne polecenia SQL wykorzystuj膮 ten sam obszar dzielony SQL.
Odczytywane oraz niezatwierdzone zmodyfikowane dane przechowywane s膮 w blokach danych blokach wycofania w buforach bazy danych w pami臋ci.
Bloki wycofania przechowuj膮 obraz wcze艣niejszy modyfikowanych danych u偶ywany podczas odtwarzania.
Podstawowym zadaniem DBWR jest zapis wszystkich zmienionych bufor贸w do pliku danych.
V.聽Zapewnianie sp贸jno艣ci i聽wsp贸艂bie偶no艣ci transakcji
Cele
Ta lekcja wyja艣nia zasady rejestrowania danych i obs艂ugi wsp贸艂bie偶nego dost臋pu do danych z zachowaniem sp贸jno艣ci odczytu na poziomie polecenia.
Po przerobieniu tej lekcji powiniene艣:
Rozpoznawa膰 rol臋 Sekretarza dziennika (LGWR) w rejestrowaniu zatwierdzonych transakcji w plikach dziennika powt贸rze艅.
Identyfikowa膰 sk艂adniki i przeznaczenie dziennika powt贸rze艅.
Rozumie膰 cel punkt贸w kontrolnych.
Rozumie膰 jak Oracle zarz膮dza wsp贸艂bie偶nym dost臋pem do danych i sp贸jno艣ci膮 odczytu na poziomie polecenia.
Przegl膮d
W bazie danych Oracle dane s膮 zawsze najpierw tworzone i modyfikowane w pami臋ci a nast臋pnie zapisywane na trwa艂e w plikach danych.
Poniewa偶 u偶ytkownicy tworz膮 i aktualizuj膮 dane w buforach bazy danych, Sekretarz Bazy Danych, proces DBWR, okresowo zapisuje zmienione bloki w bezpieczne miejsce do pliku danych. DBWR dokonuje zapis贸w cz臋sto, ale nie za ka偶dym razem, kiedy u偶ytkownik zatwierdza transakcj臋. St膮d te偶, dane zatwierdzone przez u偶ytkownika mog膮 pozostawa膰 w buforach bazy danych, gdzie s膮 nara偶one na awari臋 instancji, co powoduje utrat臋 zapis贸w znajduj膮cych si臋 w pami臋ci.
Mechanizm zabezpieczenia danych w buforach bazy danych stanowi膮 pliki dziennika powt贸rze艅. Pliki dziennika powt贸rze艅 przechowuj膮 wszystkie zmiany dokonane na danych buforach bazy danych.
Transakcje: Przegl膮d
Serwer Oracle traktuje sekwencj臋 polece艅 SQL jako pojedyncz膮 logiczn膮 jednostk臋 pracy, nazywan膮 transakcj膮.
Kiedy Zaczyna si臋 Transakcja?
Na pocz膮tku sesji.
Na ko艅cu poprzedniej transakcji.
Kiedy Ko艅czy si臋 Transakcja?
Zatwierdzenie transakcji
Wydano polecenie COMMIT
Polecenie SQL spowodowa艂o niejawne zatwierdzenie.
Poprawne wyj艣cie z programu u偶ytkownika z od艂膮czeniem od serwera Oracle.
Przerwanie transakcji
Wydano polecenie ROLLBACK
Zako艅czenie na 偶膮danie u偶ytkownika
Awaryjne wyj艣cie z programu u偶ytkownika bez od艂膮czenia si臋 od serwera Oracle.
Awaria procesora.
Awaria dysku.
Zako艅czenie transakcji mo偶e by膰 jawne, wymuszone przez polecenia COMMIT lub ROLLBACK albo niejawne, spowodowane przez inn膮 operacj臋. W艣r贸d polece艅 SQL, kt贸re powoduj膮 zatwierdzenie znajduj膮 si臋 polecenia DDL (Data Definition Language) takie jak CREATE, ALTER czy DROP oraz polecenia DCL (Data Control Language) takie jak GRANT czy REVOKE.
Transakcje w Pami臋ci
W bazie danych Oracle dane s膮 zawsze najpierw tworzone i modyfikowane w pami臋ci a nast臋pnie zapisywane na trwa艂e w plikach danych.
Poniewa偶 u偶ytkownicy tworz膮 i aktualizuj膮 dane w buforach bazy danych, Sekretarz Bazy Danych, proces DBWR, okresowo zapisuje zmienione bloki w bezpieczne miejsce do pliku danych. DBWR dokonuje zapis贸w cz臋sto, ale nie za ka偶dym razem, kiedy u偶ytkownik zatwierdza transakcj臋. St膮d te偶, dane zatwierdzone przez u偶ytkownika mog膮 pozostawa膰 w buforach bazy danych, gdzie s膮 nara偶one na awari臋 instancji, co powoduje utrat臋 zapis贸w znajduj膮cych si臋 w pami臋ci.
Dziennik Transakcji
Serwer Oracle zapisuje wszystkie dokonane w bazie danych zmiany w buforze dziennika powt贸rze艅. Jeden z proces贸w t艂a Sekretarz Dziennika (LGWR od Log Writer) zapisuje informacje z bufora dziennika powt贸rze艅 na dysk. Inny proces t艂a, Archiwizator (ARCH) mo偶e by膰 uruchomiony do archiwizowania informacji dziennika powt贸rze艅.
Rejestracja prowadzona jest w celu umo偶liwienia odtwarzania.
Dziennik powt贸rze艅 zapisuje zmiany dokonane przez transakcj臋.
Bufor dziennika powt贸rze艅 jest buforem cyklicznym (okr臋偶nym) zawieraj膮cym informacj臋 o zmianach dokonanych w bazie danych.
Bufor Dziennika Powt贸rze艅
Zapisuje wszystkie zmiany dokonane w bazie danych.
Kiedy wymagane jest odtwarzanie, potrafi zrekonstruowa膰 zmiany dokonane w bazie danych i zapisy w segmentach wycofania.
Mo偶e zosta膰 pomini臋ty przez u偶ycie s艂owa kluczowego UNRECOVERABLE w poleceniach CREATE TABLE oraz CREATE INDEX.
Mo偶e pozosta膰 pomini臋ty przez narz臋dzie 艂adowania danych Oracle (Oracle Loader).
Zadania Plik贸w Dziennika Powt贸rze艅
Mechanizm ochrony danych w buforach bazy danych to pliki dziennika powt贸rze艅.
Zawieraj膮 one zapis wszystkich zmian dokonanych w danych buforach bazy danych.
Je偶eli nast膮pi awaria instancji, pliki dziennika powt贸rze艅 s膮 wykorzystywane do odtworzenia zmodyfikowanych danych, jakie znajdowa艂y si臋 w pami臋ci. Te pliki u偶ywane s膮 tylko do tego celu.
Proces Sekretarza Dziennika (LGWR)
Proces Sekretarza Dziennika (LGWR od Log Writer) zapisuje bufor dziennika powt贸rze艅 na dysk.
LGWR zapisuje pozycje z bufora dziennika powt贸rze艅 do plik贸w dziennika powt贸rze艅 kiedy:
Wyst膮pi zdarzenie zatwierdzenia transakcji.
Bufor dziennika powt贸rze艅 zostanie zape艂niony w jednej trzeciej.
DBWR zako艅czy oczyszczanie bufor贸w blok贸w przy punkcie kontrolnym.
Wyst膮pi time-out procesu LGWR.
W艂asno艣ci Procesu LGWR
W instancji zawsze istnieje dok艂adnie jeden sekretarz dziennika.
Potwierdzenie dokonania zatwierdzenia nie jest wysy艂ane zanim transakcja nie zostanie zapisana w pliku dziennika powt贸rze艅.
Zatwierdzania wykonywane przez u偶ytkownik贸w mog膮 zapisa膰 pozycje dziennika innych u偶ytkownik贸w zanim sami postanowi膮 to wymusi膰 dokonuj膮c zatwierdzenia. W ten spos贸b uzyskuje si臋 艣redni膮 poni偶ej jednej operacji I/O na zatwierdzenie.
Podczas d艂ugotrwa艂ych transakcji obszar bufora dziennika powt贸rze艅 mo偶e wype艂ni膰 si臋 bardziej ni偶 w jednej trzeciej zanim LGWR dokona zapisu do pliku dziennika powt贸rze艅.
Zatwierdzenia w Bazie Danych
Przez zatwierdzanie transakcji dokonane zmiany staj膮 si臋 trwa艂e.
Operacja COMMIT
U偶ytkownik wysy艂a COMMIT.
LGWR zapisuje bufor dziennika powt贸rze艅 do bie偶膮cej grupy dziennika.
U偶ytkownik otrzymuje komunikat, 偶e transakcja zosta艂a zatwierdzona.
Blokady zasob贸w dotycz膮ce blok贸w danych i blok贸w wycofania s膮 zdejmowane.
DBWR ewentualnie zapisze bloki bazy danych na dysk (w tym tak偶e bloki segment贸w wycofania i bloki indeks贸w).
W艂asno艣ci COMMIT
LGWR zapisuje na trwa艂e transakcje pozwalaj膮c DBWR na op贸藕nienie zapis贸w co z kolei pozwala na zredukowanie czasu I/O wymaganego na fizyczny zapis zmodyfikowanych w pami臋ci bufor贸w blok贸w bazy danych.
Zapisy dziennika powt贸rze艅 zawieraj膮ce zmienione bajty i informacj臋 identyfikuj膮c膮 s膮 kr贸tkie.
Zatwierdzenia w bazie danych zapisuj膮 w pojedynczej operacji pozycje dziennika powt贸rze艅 z wielu transakcji 偶膮daj膮cych zatwierdzenia w tym samym czasie.
Je偶eli nie wyst膮pi przepe艂nienie bufora dziennika powt贸rze艅, wymagany jest tylko jeden synchroniczny zapis na transakcj臋 (艣rednio mo偶e by膰 nawet mniej).
Rozmiar transakcji nie ma wp艂ywu na czas oczekiwania na wykonanie bie偶膮cego polecenia COMMIT.
Zapis, je偶eli to mo偶liwe, jest wieloblokowy.
Prze艂膮czanie Dziennika, Numer Sekwencyjny Dziennika
Prze艂膮czanie Dziennika (Log Switches)
Prze艂膮czenie dziennika nast臋puje kiedy LGWR ko艅czy zapisywa膰 jedn膮 grup臋 dziennika powt贸rze艅 i rozpoczyna zapisy w drugiej.
Prze艂膮czenie dziennika ma miejsce gdy LGWR zape艂ni艂 jedn膮 grup臋 plik贸w dziennika.
Przy prze艂膮czeniu dziennika, bie偶膮cej grupie dziennika powt贸rze艅 zostaje przypisany numer sekwencyjny dziennika (log sequence number) identyfikuj膮cy informacj臋 zapisan膮 w tej grupie dziennika powt贸rze艅 i u偶ywany p贸藕niej do synchronizacji.
Prze艂膮czenie dziennika mo偶e by膰 wymuszone przez DBA poleceniem ALTER SYSTEM SWITCH LOGFILE.
Przy prze艂膮czeniu dziennika automatycznie pojawia si臋 punkt kontrolny.
Przetwarzanie mo偶e trwa膰 dop贸ki dost臋pny jest przynajmniej jeden z element贸w grupy. Po stwierdzeniu zniszczenia lub braku dost臋pu do elementu, do pliku 艣ladu LGWR i do pliku alert贸w wpisywany jest komunikat.
Numer Sekwencyjny Dziennika (Log Sequence Number)
Ka偶dy plik dziennika powt贸rze艅 jest jednoznacznie identyfikowany przez jego numer sekwencyjny dziennika.
Podczas odtwarzania Oracle stosuje odpowiednie pliki dziennika powt贸rze艅 wed艂ug wzrastaj膮cego numeru sekwencyjnego dziennika.
Bie偶膮cy numer sekwencyjny dziennika jest zapisany w pliku kontrolnym.
Punkty Kontrolne (Checkpoints)
Podczas punktu kontrolnego DBWR zapisuje wszystkie brudne bufory z bufor贸w bazy danych na dysk, przez co gwarantuje, 偶e wszystkie zmodyfikowane od czasu ostatniego punktu kontrolnego bloki danych b臋d膮 zapisane na dysku.
Kiedy Pojawia si臋 Punkt Kontrolny?
Przy ka偶dym prze艂膮czeniu dziennika (obowi膮zkowo).
Po okre艣lonej liczbie sekund od ostatniego punktu kontrolnego (parametr LOG_CHECKPOINT_TIMEOUT)
Kiedy okre艣lona liczba blok贸w dziennika powt贸rze艅 zostanie zapisana na dysk od ostatniego punktu kontrolnego (parametr LOG_CHECPOINT_INTERVAL).
Przy zamykaniu instancji (chyba, 偶e z opcj膮 ABORT).
Je偶eli jest wymuszony przez DBA (ALTER SYSTEM CHECKPOINT).
Kiedy wy艂膮czana (prze艂膮czana w stan offine) jest przestrze艅 tabel a przynajmniej jeden z jej plik贸w jest w stanie online.
Synchronizacja
Przy ka偶dym punkcie kontrolnym modyfikowany jest numer sekwencyjny punktu kontrolnego w nag艂贸wkach ka偶dego z plik贸w bazy danych i w pliku kontrolnym.
Plik kontrolny w chwili uruchomienia instancji sprawdza czy wszystkie pliki maj膮 ten sam numer sekwencyjny punktu kontrolnego.
Parametr LOG_CHECKPOINT_TIMEOUT okre艣la odst臋p czasu mi臋dzy kolejnymi punktami kontrolnymi.
Parametr LOG_CHECKPOINT_INTERVAL okre艣la liczb臋 nowozapisanych blok贸w pliku dziennika powt贸rze艅, jaka powoduje inicjalizacj臋 punktu kontrolnego.
Proces Punkt贸w Kontrolnych (CKPT)
Punkty kontrolne bazy danych zapewniaj膮, 偶e wszystkie zmodyfikowane bufory bazy danych zostan膮 zapisane do plik贸w bazy danych. Pliki bazy danych s膮 oznaczone jako pochodz膮ce z bie偶膮cej chwili, punkt kontrolny odnotowany jest w pliku kontrolnym.
Punkty Kontrolne
DBA mo偶e wymusi膰 punkt kontrolny poleceniem ALTER SYSTEM CHECKPOINT.
Proces CKPT
Proces punkt贸w kontrolnych jest uruchamiany przez ustawienie parametru CHECKPOINT_PROCESS = TRUE. Warto艣ci膮 domy艣ln膮 jest FALSE.
Je艣li jest uruchomiony, proces ten przejmuje zadania LGWR dotycz膮ce modyfikacji plik贸w w momencie punktu kontrolnego.
Po zako艅czeniu punktu kontrolnego aktualizowane s膮 nag艂贸wki plik贸w danych.
Cz臋stsze punkty kontrolne zmniejszaj膮 czas potrzebny na odtwarzanie w przypadku awarii instancji, ale mog膮 zmniejsza膰 efektywno艣膰.
Proces CKPT poprawia efektywno艣膰 baz danych posiadaj膮cych wiele plik贸w danych.
Proces Archiwizatora (ARCH)
Proces Archiwizatora (ARCH) kopiuje na bie偶膮co pliki dziennika powt贸rze艅 na wskazane urz膮dzenie za ka偶dym razem kiedy LGWR prze艂膮cza si臋 na inn膮 grup臋.
Proces Archiwizatora
Kopiuje pliki dziennika powt贸rze艅 na ta艣m臋 lub dysk dla zapewnienia mo偶liwo艣ci odtwarzania po awarii no艣nika.
Aktywowany tylko po wyst膮pieniu prze艂膮czenia dziennika.
Jest opcjonalny, potrzebny tylko w trybie ARCHIVELOG.
Mo偶e zapisywa膰 na ta艣m臋 lub na dysk.
Sp贸jno艣膰 Odczytu
W czasie przetwarzania polecenia serwera Oracle pos艂uguje si臋 sp贸jnym obrazem danych tabeli z chwili rozpocz臋cia polecenia.
Zasada sp贸jno艣ci odczytu stanowi, 偶e dane jakie ogl膮da lub zmienia u偶ytkownik musz膮 pozostawa膰 niezmienione dop贸ki u偶ytkownik nie zako艅czy ich przetwarzania.
Niezatwierdzone zmiany powinny by膰 widoczne tylko dla u偶ytkownika, kt贸ry dokona艂 zmian. U偶ytkownik wykonuj膮cy zapytanie powinien widzie膰 tylko dane zatwierdzone przed rozpocz臋ciem zapytania (domy艣lnie) lub zatwierdzone przed rozpocz臋ciem transakcji (wymuszane poleceniem SET TRANSACTION READ ONLY).
Przyk艂ad Wykorzystania Modu艂u Sp贸jno艣ci Odczytu
Model sp贸jno艣ci odczytu wykorzystywany przy podzapytaniach skorelowanych.
SQL> SELECT first_name, dept_id, salary 聽聽聽聽聽2>聽FROM s_emp 聽聽聽聽聽3>聽WHERE salary>(SELECT AVG (salary) FROM s_emp 4>聽WHERE b.dept_id = a.dept_id; |
Serwer gwarantuje, 偶e w trakcie przetwarzania powy偶szego zapytania widoczne b臋d膮 te same warto艣ci, nawet je艣li inny u偶ytkownik zatwierdzi jednocze艣nie zmiany w S_EMP.
Serwer Oracle zwr贸ci zatwierdzone dane lub zmiany dokonane wcze艣niej przez bie偶膮cego u偶ytkownika, jak to ilustruje nast臋puj膮cy przyk艂ad:
Czas |
U偶ytkownik A |
U偶ytkownik B |
0 |
UPDATE_emp.... |
|
1 |
|
SELECT...FROM s_emp b |
2 |
COMMIT |
|
3 |
|
SELECT...FROM s_emp a |
Model Blokowania
Serwer Oracle pozwala na wsp贸艂bie偶ny dost臋p do danych zapewniaj膮c integralno艣膰 danych przez blokady danych i s艂ownika danych.
Model Blokowania
Odczytuj膮cy nie blokuj膮 zapisuj膮cych.
Zapisuj膮cy nie blokuj膮 odczytuj膮cych.
Sp贸jno艣膰 odczytu jest zapewniona przez u偶ycie zapis贸w w segmentach wycofania.
Zapewnione jest blokowanie na poziomie wiersza (domy艣lnie) a tak偶e na poziomie tabel.
Blokowanie jest automatyczne, mo偶e te偶 by膰 wymuszane jawnie.
Mo偶na jawnie za偶膮da膰 blokad dzielonych i blokad wy艂膮czonych.
Blokowanie na poziomie wiersza jest dost臋pne dla ka偶dego wiersza w bazie danych.
Serwer Oracle nigdy nie zwi臋ksza poziomu blokady (na przyk艂ad z poziomu wiersza do poziomu strony czy tabeli).
Podsumowanie
DBA powinien rozumie膰 zasady dzia艂ania bufora dziennika powt贸rze艅, procesu Sekretarza Dziennika i Archiwizatora:
Serwer Oracle zapisuje wszystkie dokonane w bazie danych zmiany do bufora dziennika powt贸rze艅.
Pliki dziennika powt贸rze艅 u偶ywane s膮 do odtwarzania w strukturach pami臋ci zmodyfikowanych danych po awarii instancji.
LGWR zapisuje pozycje dziennika powt贸rze艅 na dysk.
Punkty kontrolne zapewniaj膮, 偶e wszystkie zmodyfikowane bufory bazy danych zostan膮 zapisane do plik贸w bazy danych.
Proces ARCH kopiuje na bie偶膮co pliki dziennika powt贸rze艅 na wskazane urz膮dzenie pami臋ci masowej przy ka偶dym prze艂膮czeniu si臋 LGWR na now膮 grup臋 dziennika powt贸rze艅.
Odczytuj膮cy nie blokuj膮 zapisuj膮cych.
Zapisuj膮cy nie blokuj膮 odczytuj膮cych.
VI.聽Zarz膮dzanie struktur膮 bazy danych
Cele
Tematem tej lekcji s膮 informacje o dopasowaniu bazy danych
Po przerobieniu tej lekcji powiniene艣 by膰 w stanie:
Wyja艣ni膰 zasady przydzia艂u przestrzeni w bazie danych.
Dopasowa膰 struktur臋 bazy danych.
Przygotowa膰 potrzebne przestrzenie tabel.
Opisa膰 r贸偶ne typy segment贸w.
Przegl膮d
Serwer Oracle przydziela przestrze艅 bazy danych dla wszystkich danych w bazie.
Definicje Obiekt贸w
Termin |
Definicja |
Baza danych |
Logiczny zbi贸r danych dzielonych sk艂adowanych w przestrzeniach tabel. |
Plik |
Fizyczny plik danych nale偶膮cy do okre艣lonej przestrzeni tabel. |
Przestrze艅 Tabel |
Logiczny sk艂ad na fizycznie zgrupowane dane. |
Segment |
Zbi贸r jednego lub wielu ekstent贸w zawieraj膮cych wszystkie dane okre艣lonego obiektu w ramach przestrzeni tabel. |
Ekstent |
Zbi贸r sp贸jnych (s膮siednich) blok贸w w pliku danych. |
Blok |
Wielokrotno艣膰 fizycznych blok贸w pliku zarezerwowana w istniej膮cym pliku danych. |
Przydzia艂 Przestrzeni
Przestrze艅 jest zarezerwowana podczas tworzenia obiektu i p贸藕niej, kiedy obiekt ro艣nie.
Przestrze艅 jest przydzielana w sp贸jnych ci膮gach blok贸w bazy danych nazywanych ekstentami.
Obiekty bazy danych wykorzystuj膮ce przestrze艅 przechowywane s膮 w pojedynczej przestrzeni tabel przez ca艂y czas swojego istnienia.
Pliki danych nale偶膮 do pojedynczej przestrzeni tabel.
Struktura Logiczna Bazy Danych
Rozpatruj膮c baz臋 danych z logicznej perspektywy 艂atwiej mo偶na zrozumie膰 zasady przydzia艂u przestrzeni serwera Oracle.
Baza danych Oracle dzieli si臋 logicznie na osobne przestrzenie tabel.
Przestrze艅 tabel SYSTEM jest konieczna do pracy bazy danych.
Przestrzenie tabel zawieraj膮 segmenty bazy danych.
Przestrzenie Tabel
Baza danych Oracle dzieli si臋 na mniejsze logiczne fragmenty przestrzeni nazywane przestrzeniami tabel (ang. TABLESPACEs).
Przestrzenie Tabel
Ka偶da przestrze艅 tabel sk艂ada si臋 z jednego lub wielu plik贸w systemu operacyjnego.
Przestrzenie tabel mog膮 by膰 w艂膮czane w trakcie pracy bazy danych.
Przestrzenie tabel (z wyj膮tkiem przestrzeni tabel SYSTEM i przestrzeni tabel zawieraj膮cych aktywny segment wycofania) mog膮 by膰 wy艂膮czane bez przerywania pracy bazy danych.
Status przestrzeni tabel mo偶e by膰 prze艂膮czany pomi臋dzy tylko-do-odczytu i odczyt-zapis.
Obiekty utworzone w przestrzeni tabel nigdy nie mog膮 rezerwowa膰 przestrzeni spoza ich oryginalnej przestrzeni tabel.
Zastosowanie Przestrzeni Tabel
Kontrola przydzia艂u przestrzeni i ograniczenia ilo艣ciowe przestrzeni dla u偶ytkownik贸w.
Kontrola dost臋pu do danych przez indywidualne w艂膮czenia/wy艂膮czenie przestrzeni tabel.
Rozproszenie sk艂adowania danych na urz膮dzenia w celu poprawienia efektywno艣ci I/O i minimalizacji rywalizacji o pojedynczy dysk.
Wykonywanie operacji cz臋艣ciowej archiwizacji i cz臋艣ciowego odtwarzania.
Utrzymywanie wielkich ilo艣ci danych statycznych na urz膮dzeniach tylko-do-odczytu.
Baza danych sk艂ada si臋 z co najmniej jednej przestrzeni tabel SYSTEM. Dodatkowe przestrzenie tabel dodaje si臋 w celu zwi臋kszenia mo偶liwo艣ci kontroli i d艂ugoterminowej obs艂ugi.
Og贸lnie, serwer Oracle rozr贸偶nia dwa typy przestrzeni tabel sk艂adaj膮ce si臋 na baz臋 danych: przestrze艅 systemowa i przestrzenie niesystemowe.
Przestrze艅 tabel SYSTEM
Wymagana do uruchomienia ka偶dej bazy danych.
Zawiera informacje s艂ownika danych, definicje pami臋tanych procedur, pakiet贸w i wyzwalaczy bazy danych.
Zawiera segment wycofania SYSTEM.
Mo偶e, cho膰 nie powinna, zawiera膰 dane u偶ytkownik贸w.
Niesystemowe Przestrzenie Tabel
Pozwalaj膮 na bardziej elastyczn膮 administracj臋 baz膮 danych.
Zawieraj膮 segmenty wycofania, segmenty tymczasowe, dane aplikacji, dane indeks贸w i聽przestrze艅 u偶ytkownik贸w.
Przestrze艅 tabel dla segment贸w wycofania
Jest niesystemow膮 przestrzeni膮 tabel o specjalnym przeznaczeniu.
Je艣li zawiera u偶ywany na bie偶膮co segment wycofania (status in-use),nie mo偶e by膰 wy艂膮czona ani te偶 prze艂膮czona w tryb tylko-do-odczytu. Musi by膰 odtwarzana tak jak przestrze艅 tabel SYSTEM, to znaczy przy wy艂膮czonej w celu odtworzenia ca艂ej bazie danych.
Fizyczna Struktura Bazy Danych
Ca艂kowita wielko艣膰 fizycznej przestrzeni rezerwowanej dla obiekt贸w bazy danych Oracle zale偶y od rozmiaru plik贸w systemu operacyjnego utworzonych na potrzeby ka偶dej przestrzeni tabel.
Opis
Ka偶da logiczna przestrze艅 tabel fizycznie zbudowana jest z jednego lub wielu plik贸w systemu operacyjnego.
Ka偶dy segment (np. segment danych) mo偶e by膰 roz艂o偶ony na wielu plikach, pod warunkiem, 偶e pliki te nale偶膮 do tej samej przestrzeni tabel.
Tworzenie Przestrzeni Tabel
Przestrze艅 tabel mo偶emy utworzy膰 za pomoc膮 polecenia CREATE TABLESPACE.
Sk艂adnia:
gdzie:
przestrze艅_tabel to nazwa przestrzeni tabel jaka ma by膰 utworzona.
spec_pliku jest nazw膮 pliku danych.
Nazwa pliku jest nazw膮 pliku danych.
SIZE okre艣la rozmiar pliku w bajtach (mo偶na te偶 u偶y膰 jednostek K lub M).
REUSE pozwala aby serwer Oracle wykorzysta艂 istniej膮cy plik.
DATAFILE specyfikuje plik lub pliki danych z jakich ma si臋 sk艂ada膰 przestrze艅 tabel.
DEFAULT STORAGE okre艣la domy艣lne parametry zarz膮dzania przestrzeni膮 dla wszystkich obiekt贸w tworzonych w tej przestrzeni tabel.
ONLINE sprawia, 偶e przestrze艅 tabel jest dost臋pna u偶ytkownikom posiadaj膮cym do niej uprawnienia niezw艂ocznie po utworzeniu.
OFFLINE sprawia, 偶e przestrze艅 tabel nie jest dost臋pna natychmiast po utworzeniu.
PERMANENT wskazuje, 偶e przestrze艅 tabel b臋dzie u偶ywana do przechowywania trwa艂ych obiekt贸w. Tak te偶 jest domy艣lnie.
TEMPORARY wskazuje, 偶e przestrze艅 tabel b臋dzie u偶ywana do przechowywania obiekt贸w tymczasowych. Na przyk艂ad segment贸w u偶ywanych przez niejawne sortowanie przy realizacji klauzuli ORDER BY.
Wskaz贸wki
Je艣li pominiemy opcje ONLINE oraz OFFLINE, serwer Oracle domy艣lnie utworzy przestrze艅 tabel w艂膮czon膮. Perspektywa s艂ownika danych DBA_TABLESPACES wskazuje status ka偶dej przestrzeni tabel.
Je偶eli w specyfikacji pliku u偶yjemy REUSE, plik taki musi ju偶 istnie膰. W przeciwnym przypadku wymagana jest opcja SIZE, a plik istnie膰 nie mo偶e.
Sk艂adnia DEFAULT STORAGE:
gdzie:
INITIAL okre艣la rozmiar (w bajtach) pierwszego ekstentu rezerwowanego dla obiektu.
NEXT okre艣la rozmiar (w bajtach) nast臋pnego ekstentu rezerwowanego dla obiektu.
MINEXTENTS okre艣la ca艂kowit膮 liczb臋 ekstent贸w przydzielan膮 podczas tworzenia obiektu.
MAXEXTENTS okre艣la ca艂kowit膮 liczb臋 ekstent贸w (wliczaj膮c te偶 pierwszy), jaka mo偶e by膰 przydzielona dla obiektu.
PCTINCREASE okre艣la procent o kt贸ry ka偶dy nast臋pny (po drugim) ekstent b臋dzie wi臋kszy w stosunku do poprzedniego.
Wskaz贸wki:
Warto艣ci INITIAL i NEXT s膮 zaokr膮glane do nast臋pnej wielokrotno艣ci rozmiaru bloku danych (wskazywanego przez parametr inicjalizacji DB_BLOCK_SIZE).
Pierwszy blok ekstentu INITIAL jest traktowany jako blok nag艂贸wka segmentu.
Przyk艂ad
Tworzenie przestrzeni tabel RBS z pojedynczym plikiem o nazwie rbs01.dbf i rozmiarze 3MB. Przestrze艅 tabel ma by膰 natychmiast gotowa do u偶ycia.
SQL>CREATE TABLESPACE rbs 2>聽DATAFILE `/u01/Oracle/D/rbs 01.dbf ' SIZE 3M 聽聽聽聽聽3>聽DEFAULT STORAGE (INITIAL 50K NEXT 50K 聽聽聽聽聽4>聽MINEXTENTS 10 MAXEXTENTS 121 聽聽聽聽聽5>聽PCTINCREASE 0) ; |
PCTINCREASE ma domy艣ln膮 warto艣膰 50, lecz zwykle zmieniamy j膮 na 0 dla lepszej kontroli wzrostu segmentu.
Modyfikacja Przestrzeni Tabel
Przestrze艅 tabel modyfikujemy, aby zmieni膰 jej domy艣lne parametry zarz膮dzania przestrzeni膮, w celu jej wy艂膮czenia lub wy艂膮czenia, dodania kolejnych plik贸w danych, zmiany nazwy istniej膮cych plik贸w danych, prze艂膮czania trybu mi臋dzy odczyt-zapis oraz tylko-do-odczytu, lub te偶 w celu wykonania kopii zapasowej.
Dokonujemy tego za pomoc膮 polecenia ALTER TABLESPACE.
Sk艂adnia:
gdzie:
przestrze艅_tabel okre艣la nazw臋 przestrzeni tabel jaka ma by膰 zmieniona.
ADD DATAFILE dodaje wyspecyfikowany plik do przestrzeni tabel.
RENAME DATAFILE zmienia nazw臋 jednego lub wielu plik贸w przestrzeni tabel.
DEFAULT STORAGE okre艣la nowe domy艣lne parametry zarz膮dzania przestrzeni膮 dla obiekt贸w tworzonych nast臋pnie w przestrzeni tabel
ONLINE w艂膮cza przestrze艅 tabel (status online)
OFFLINE wy艂膮cza przestrze艅 tabel (status offline).
NORMAL wykonuje punkt kontrolny na wszystkich plikach danych przestrzeni tabel.
TEMPORARY wykonuje punkt kontrolny jedynie na w艂膮czonych plikach danych przestrzeni tabel.
IMMEDIATE nie upewnia si臋, 偶e pliki danych s膮 dost臋pne i nie wykonuje punktu kontrolnego.
BEGIN BACKUP przygotowuje przestrze艅 tabel do archiwizacji online.
END BACKUP przywraca normalny status przestrzeni tabel.
READ WRITE pozwala na tworzenie, modyfikacje i usuni臋cia obiekt贸w
READ ONLY zapobiega zmianom.
Usuwanie Przestrzeni Tabel
Kiedy przestrze艅 tabel i jej zawarto艣膰 nie jest ju偶 potrzebna, mo偶emy usun膮膰 j膮 z bazy danych pos艂uguj膮c poleceniem DROP TABLESPACE.
Sk艂adnia:
gdzie:
przestrze艅_tabel okre艣la nazw臋 usuwanej przestrzeni tabel.
INCLUDING CONTENTS usuwa ca艂膮 zawarto艣膰 przestrzeni tabel.
CASCADE CONSTRAINTS usuwa wszystkie referencyjne warunki integralno艣ci z tabel spoza usuwanej przestrzeni, kt贸re odnosz膮 si臋 do kluczy g艂贸wnych lub unikalnych tabel z usuwanej przestrzeni.
Usuwanie Przestrzeni Tabel
Przestrze艅 tabel w kt贸rej ci膮gle znajduj膮 si臋 dane mo偶e by膰 usuni臋ta tylko z opcj膮 INCLUDING CONTENTS.
Kiedy przestrze艅 tabel zostanie usuni臋ta, jej danych nie ma ju偶 w bazie danych.
Podczas usuwania przestrzeni tabel likwidowane s膮 jedynie wska藕niki do plik贸w w pliku kontrolnym bazy danych. Jednak pliki bazy danych ci膮gle istniej膮 i musz膮 by膰 jawnie usuni臋te z poziomu systemu operacyjnego.
Przestrze艅 tabel, podobnie jak jej segmenty, mo偶e by膰 usuni臋ta nawet je艣li jest w trybie tylko-do-odczytu. Jest to spowodowane tym, 偶e polecenie DROP modyfikuje jedynie s艂ownik danych (kt贸ry musi by膰 w trybie odczyt-zapis) a nie fizyczne pliki z kt贸rych sk艂ada si臋 przestrze艅 tabel.
Tymczasowe Przestrzenie Tabel
Wszystkie operacje sortowania wykonywane w instancji u偶ywaj膮 wsp贸lnego segmentu sortowania (sort segment) z tymczasowej przestrzeni tabel.
Segment tymczasowy:
Nie mo偶e zawiera膰 偶adnego trwa艂ego obiektu.
Jest zarz膮dzany przez DBA.
Aby wskaza膰, czy przestrze艅 tabel jest tymczasowa, u偶ywamy polecenia CREATE TABLESPACE lub ALTER TABLESPACE z odpowiedni膮 opcj膮.
Sk艂adnia
gdzie:
PERNAMENT wskazuje, 偶e przestrze艅 tabel b臋dzie u偶ywana do przechowywania obiekt贸w trwa艂ych. Jest to opcja domy艣lna.
TEMPORARY wskazuje, 偶e przestrze艅 tabel b臋dzie u偶ywana jedynie do przechowywania obiekt贸w tymczasowych, na przyk艂ad segment贸w u偶ywanych przy przetwarzaniu klauzuli ORDER BY.
Uwaga: Przydzia艂 i zwolnienie przestrzeni w segmencie sortowania tymczasowej przestrzeni tabel mo偶emy obserwowa膰 w perspektywie V$SORT_SEGMENTS.
Zmiana Rozmiaru Plik贸w Danych
Rozmiar pliku danych mo偶e zmieniany automatycznie je艣li u偶yjemy opcji AUTOEXTEND lub r臋cznie za pomoc膮 polecenia ALTER DATABASE.
Automatyczna zmiana Plik贸w Danych
Polecenie AUTOEXTEND w艂膮cza lub wy艂膮cza automatyczne rozszerzanie plik贸w danych. Opcj臋 automatycznego rozszerzania pliku mo偶emy poda膰 przy specyfikacji plik贸w聽nast臋puj膮cych poleceniach SQL.
CREATE DATABASE
ALTER DATABASE
CREATE TABLESPACE
ALTER TABLESPACE
Sk艂adnia Opcji Autoextend
Sk艂adnia:
gdzie:
OFF wy艂膮cz automatyczne rozszerzanie plik贸w danych. NEXT i MAXSIZE s膮 ustawione na zero. Warto艣ci te musz膮 by膰 ponownie podane w kolejnych poleceniach ALTER TABLESPACE AUTOEXTEND.
ON w艂膮cza automatyczne rozszerzanie plik贸w danych.
NEXT przestrze艅 dysku przydzielana do pliku kiedy potrzeba wi臋cej ekstent贸w.
MAXSIZE maksymalna przestrze艅 dysku dopuszczalna dla tego pliku danych.
UNLIMITED znosi limity przydzia艂u przestrzeni dysku dla pliku danych.
Przyk艂ady
Dodanie nowego pliku do przestrzeni tabel USERS.
SVRMGR>聽ALTER TABLESPACE users 2>聽ADD DATAFILE `users02' SIZE 1OM 3>聽AUTOEXTEND ON 4>聽NEXT 521K 5>聽MAXSIZE 250M; |
W艂膮czenie automatycznego rozszerzenia istniej膮cego pliku danych za pomoc膮 polecenia ALTER DATABASE.
SVRMGR>聽ALTER DATABASE DATAFILE `users 02' 2>聽AUTOEXTEND ON NEXT 1M MAXSIZE 100M; |
R臋czna Zmiana Rozmiaru Plik贸w Danych
Zwi臋kszamy lub zmniejszamy rozmiar pliku danych jawnie za pomoc膮 polecenia ALTER DATABASE.
Poniewa偶 mo偶emy zmieni膰 rozmiar pliku danych, mo偶emy doda膰 wi臋cej przestrzeni w bazie danych bez tworzenia dodatkowych plik贸w. Mo偶emy tak偶e poprawi膰 b艂臋dy szacowania wymaga艅 przestrzeni 偶膮daj膮c zwolnienia nieu偶ywanej przestrzeni bazy danych.
Przyk艂ad
Zmiana rozmiaru pliku users02.
SVRMGR> ALTER DATABASE DATAFILE `users02' 2> RESIZE 100M; |
Parametr COMPATIBLE musi by膰 ustawiony na wersj臋 7.2.0 lub wy偶sz膮.
Przestrzenie Tabel Tylko-Do-Odczytu
Zanim DBA prze艂膮czy przestrze艅 tabel w stan tylko-do-odczytu, musz膮 by膰 spe艂nione nast臋puj膮ce warunki (dobrze jest w tym celu uruchomi膰 instancj臋 w trybie restricted):
Przestrze艅 tabel musi by膰 w艂膮czona (online).
Nie mo偶e by膰 aktywnych transakcji.
Przestrze艅 tabel nie mo偶e zawiera膰 aktywnego segmentu wycofania.
Przestrze艅 tabel nie mo偶e aktualnie podlega膰 archiwizacji online.
Zaleca si臋 usuni臋cie segment贸w wycofania przed prze艂膮czeniem przestrzeni tabel na tylko-do-odczytu. Z tego te偶 powodu przestrze艅 tabel SYSTEM nigdy nie mo偶e sta膰 si臋 przestrzeni膮 tabel tylko-do-odczytu.
Przyk艂ady
Zmiana przestrzeni tabel na tylko-do-odczytu za pomoc膮 polecenia ALTER TABLESPACE.
SQL> ALTER TABLESPACE user_tablespace READ ONLY |
Zmiana przestrzeni tabel na odczyt-zapis za pomoc膮 polecenia ALTER TABLESPACE.
SQL> ALTER TABLESPACE user_tablespace READ WRITE; |
Aby przestrze艅 tabel przywr贸ci膰 w stan odczyt_zapis, wszystkie pliki danych przestrzeni tabel musz膮 by膰 online. W tym calu mo偶na pos艂u偶y膰 si臋 opcj膮 DATAFILE ONLINE polecenia ALTER DATABASE. Bie偶膮cy status plik贸w danych sprawdzamy w perspektywie V$DATAFILE lub DBA_DATA_FILES.
Zasady Zarz膮dzania Przestrzeniami Tabel
Istniej膮 trzy zasady zarz膮dzania przestrzeniami tabel.
U偶ywanie Wielu Przestrzeni Tabel
U偶ycie wielu przestrzeni tabel pozwala na wi臋ksz膮 elastyczno艣膰 w wykonywaniu operacji na bazie danych.
Oddzielaj dane u偶ytkownik贸w od danych s艂ownika danych.
Oddzielaj dane r贸偶nych aplikacji.
Umieszczaj r贸偶ne pliki przestrzeni tabel na oddzielnych urz膮dzeniach dyskowych aby zredukowa膰 rywalizacj臋 o I/O.
Oddzielaj segmenty wycofania od segment贸w danych chroni膮c si臋 przed utrat膮 danych przez awari臋 pojedynczego dysku.
Wy艂膮czaj poszczeg贸lne przestrzenie tabel pozostawiaj膮c inne w艂膮czone.
Zarezerwuj przestrzenie tabel w zale偶no艣ci od typu u偶ycia danych, uwzgl臋dniaj膮c np. wysok膮 cz臋stotliwo艣膰 modyfikacji, dane tylko do odczytu czy przestrze艅 na segmenty tymczasowe.
Archiwizuj poszczeg贸lne przestrzenie tabel.
Okre艣laj Parametry Zarz膮dzania Przestrzeni膮 w Przestrzeniach Tabel
Okre艣l domy艣lne parametry zarz膮dzania przestrzeni膮 dla obiekt贸w tworzonych w przestrzeni tabel.
Ustaw domy艣lne parametry zarz膮dzania przestrzeni膮 w przestrzeni tabel na podstawie szacunk贸w dotycz膮cych rozmiaru typowego obiektu tworzonego w przestrzeni tabel.
Przypisz U偶ytkownikom Ograniczenia Przestrzeni
Przydzielaj ograniczenia wykorzystania przestrzeni tabel u偶ytkownikom wed艂ug potrzeb.
Segmenty
Segment to zbi贸r jednego lub wielu ekstent贸w zawieraj膮cych wszystkie dane okre艣lonego typu nale偶膮cego do struktur logicznych przechowywanych
Typ Segmentu |
Definicja |
Segment wycofania (rollback segment) |
Zbi贸r ekstent贸w zawieraj膮cy dane wycofania u偶ywane do wycofania, sp贸jno艣ci odczytu lub odtwarzania. |
Segment danych (data segment) |
Zbi贸r ekstent贸w zawieraj膮cy ca艂o艣膰 danych tabeli lub klastra. |
Segment indeksu (index segment) |
Zbi贸r ekstent贸w zawieraj膮cy ca艂o艣膰 danych okre艣lonego indeksu. |
Segment tymczasowy (temporary segment) |
Zbi贸r ekstent贸w zawieraj膮cy dane nale偶膮ce do obiektu tymczasowego. |
Segment Cache (cache segment) |
Ekstent zawieraj膮cy definicje s艂ownikowe tabel s艂ownikowych, 艂adowanych podczas otwierania bazy danych. Nie wymaga 偶adnej obs艂ugi przez administratora bazy danych. |
Co To Jest Segment ?
Segment to logiczna struktura, jaka mo偶e by膰 utworzona, zajmuje wtedy przestrze艅, mo偶e si臋 rozrasta膰. Segmenty czasem nazywane s膮 po prostu obiektami bazy danych.
Segmenty nie mog膮 by膰 podzielone na wiele przestrzeni tabel.
Ekstent to zbi贸r sp贸jnych (s膮siednich) blok贸w bazy danych.
Do zarz膮dzania przestrzeni膮 segment贸w tymczasowych zawsze u偶ywane s膮 domy艣lne ustawienia parametr贸w w przestrzeni tabel - nie mog膮 one by膰 ustawione dla obiektu tymczasowego jawnie.
Segmenty Wycofania
Segment wycofania (rollback segment) to fragment bazy danych sprzed wykonania modyfikacji przez transakcj臋, pozwalaj膮cy na wycofanie zmian.
Transakcja (transaction) jest jednostk膮 operacji na bazie danych powoduj膮c膮 zmiany i blokady wierszy. Ka偶da transakcja ma przydzielony unikalny identyfikator i dok艂adnie jeden segment wycofania. Segment wycofania jest obiektem cyklicznym, w kt贸rym ka偶da transakcja dokonuje wielu zapis贸w. Transakcja mo偶e u偶ywa膰 nast臋pnego ekstentu, je偶eli brak w nim aktywnych zapis贸w.
Je艣li nast臋pny ekstent, jaki ma by膰 u偶yty posiada aktywne zapisy, do segmentu wycofania zostanie dodany nowy ekstent o ile nie osi膮gni臋to jeszcze maksymalnej liczby ekstent贸w.
Charakterystyka Segment贸w Wycofania
Pozwalaj膮 na wycofanie ca艂ej transakcji lub w przypadku pomy艂ki operatora, do wskazanego punktu zachowania.
Umo偶liwiaj膮 sp贸jno艣膰 odczytu.
Wykorzystywane przy odtwarzaniu bazy danych.
Mog膮 zawiera膰 dane podlegaj膮ce zmianom pochodz膮ce z dowolnej przestrzeni tabel (z wyj膮tkiem segmentu wycofania SYSTEM).
Mog膮 zawiera膰 zmiany wielu transakcji.
W przestrzeni tabel SYSTEM zawsze istnieje segment wycofania o nazwie SYSTEM.
Je偶eli u偶ywamy wielu przestrzeni tabel, konieczny jest przynajmniej jeszcze jeden segment wycofania.
Segment Danych i Indeks贸w
Segmenty danych (data segments) zawieraj膮 dane wstawiane do tabel. Segmenty indeks贸w (index segments) zawieraj膮 indeksy, struktury s艂u偶膮ce do poprawiania efektywno艣ci wyszukiwania danych.
Cechy Segment贸w
Typ Segmentu |
Funkcja |
Tabela |
Zawiera wiersze pojedynczej tabeli. |
Klaster indeksowy |
Zawiera wiersze jednej lub wielu tabel zgrupowane wed艂ug warto艣ci wskazanej kolumny tabeli. |
Klaster haszuj膮cy |
Zawiera wiersze tabeli rozmieszczone za pomoc膮 algorytmu haszowania. |
Indeks |
Zawiera indeksy utworzone na jednej lub wielu kolumnach tabeli. S艂u偶膮 do zwi臋kszenia efektywno艣ci wyszukiwania danych. |
Co To S膮 Klastry?
Klaster to struktura przestrzeni danych. Ka偶dy klaster zawiera jedn膮 lub wiele tabel.
Klastry haszowane tak偶e mog膮 zawiera膰 wi臋cej ni偶 jedn膮 tabel臋, ale s膮 to rzadkie przypadki.
Tabele z klastra u偶ywane s膮 przez u偶ytkownika w ten sam spos贸b co zwyk艂e tabele.
Segmenty Tymczasowe
Segmenty tymczasowe (temporary segments) dostarczaj膮 przestrzeni potrzebnej serwerowi przy sortowaniu danych.
Charakterystyka Segment贸w Tymczasowych
Segmenty tymczasowe s膮:
Tworzone automatycznie przez serwer Oracle przy wykonywaniu z艂o偶onych operacji takich jak z艂膮czenia, grupowanie sortowanie, tworzenie indeks贸w i innych operacji wymagaj膮cych sortowania.
Tworzone w przestrzeni tabel je艣li brak miejsca w pami臋ci wewn臋trznej.
Przypisane do transakcji.
Zwalniane na ko艅cu transakcji (przez SMON).
Nie chronione przez dziennik powt贸rze艅, poniewa偶 nie s膮 konieczne dla zachowania sp贸jno艣ci danych.
Segmenty Tymczasowe w Nietymczasowej Przestrzeni Tabel
Ka偶da przestrze艅 tabel mo偶e zawiera膰 segmenty tymczasowe.
Przydzia艂 przestrzeni jest okre艣lony przez klauzul臋 DEFAULT STORAGE przestrzeni tabel segmentu.
Dynamiczny wzrost tabel tymczasowych mo偶e powodowa膰 fragmentacj臋.
DBA mo偶e zdecydowa膰 kt贸ra przestrze艅 tabel jest u偶ywany przez ka偶dego u偶ytkownika do przechowywania segment贸w tymczasowych, st膮d te偶 mo偶liwe jest utworzenie specjalnej przestrzeni tabel na segmenty tymczasowe.
Poniewa偶 przydzia艂 i zwalnianie segment贸w tymczasowych odbywa si臋 cz臋sto, warto utworzy膰 specjaln膮 przestrze艅 tabel na segmenty tymczasowe, co jest mo偶liwe od wersji 7.3.
Segment Bootstrap
Segment bootstrap zawiera definicje struktury tabel s艂ownika danych. Jest 艂adowany podczas otwierania bazy danych.
Segment bootstrap jest:
Cz臋sto nazywany segmentem cache.
Niedost臋pny dla u偶ytkownik贸w.
Utworzony w przestrzeni tabel SYSTEM i nale偶y do u偶ytkownika sys.
Nie wymaga 偶adnych akcji ze strony DBA.
Podsumowanie
Dopasowujemy baz臋 danych przez
Zaprojektowanie logicznej i fizycznej i fizycznej struktury
Tworzenie dodatkowych, niesystemowych przestrzeni tabel.
Tworzenie segment贸w wycofania.
Tworzenie segment贸w indeks贸w.
Tworzenie segment贸w tymczasowych.
Zadania
Utw贸rz przestrze艅 tabel USER_DATA o parametrach: plik danych e:\kurs\database\db#\usradm#.ora o rozmiarze 1M, ekstent inicjalny 10K, ekstent nast臋pny 10K, pctincrease 0, automatyczne zwi臋kszanie rozmiaru pliku bazy danych, w trybie offline.
Obejrzyj perspektyw臋 DBA_TABLESPACES, zwr贸膰 uwag臋 na status stworzonej przestrzeni tabel
Prze艂膮cz przestrze艅 USER_DATA w tryb online i obejrzyj to na perspektywie DBA_TABLESPACES
Dodaj plik o wielko艣ci 1MB do przestrzeni USER_DATA, obejrzyj to na perspektywie DBA_DATA_FILES i sprawd藕, kt贸re pliki danych maj膮 ustawion膮 opcj臋 AUTOEXTEND
Zmie艅 ustawienia w bazie tak, aby przestrze艅 SYSTEM mog艂a si臋 rozszerza膰 o 1M za ka偶dym razem, gdy zajdzie taka potrzeba i sprawd藕 czy si臋 uda艂o
Utw贸rz tymczasow膮 przestrze艅 tabel TEMPORARY_DATA na pliku o rozmiarze 1M i nazwie e:\kurs\database\db#\tmpadm#.ora z domy艣lnymi parametrami i聽聽sprawd藕 poprawno艣膰 utworzenia przestrzeni
Zmie艅 rozmiar pliku dla przestrzeni TEMPORARY_DATA na 2MB, sprawd藕, czy si臋 uda艂o
VII.聽Zarz膮dzanie przydzia艂em przestrzeni
Cele
W tej lekcji omawiamy jak efektywnie zarz膮dza膰 i kontrolowa膰 przydzia艂 przestrzeni w bazie danych.
Po przerobieniu tej lekcji powiniene艣 potrafi膰:
Przydziela膰 ekstenty obiektom bazy danych.
Wyja艣ni膰 parametry zarz膮dzania przydzia艂em przestrzeni bazy danych.
Kontrolowa膰 zu偶ycie przestrzeni.
Wykorzystywa膰 parametry u偶ywania przestrzeni.
Wy艣wietli膰 informacje o przestrzeni bazy danych.
Przegl膮d
Serwer Oracle przydziela przestrze艅 bazy danych wszystkim danym w bazie.
Termin |
Definicja |
Baza danych |
Logiczny zbi贸r dzielonych danych przechowywanych w przestrzeniach tabel. |
Plik |
Fizyczny plik danych nale偶膮cy do pojedynczej przestrzeni tabel. |
Przestrze艅 tabel |
Logiczne repozytorium fizycznie zgrupowanych danych. |
Segment |
Zbi贸r z艂o偶ony z jednego lub z wielu ekstent贸w zawieraj膮cy wszystkie dane okre艣lonej struktury przechowywania w聽przestrzeni tabel. |
Ekstent |
Zbi贸r sp贸jnych (s膮siednich) blok贸w bazy danych w pliku danych. |
Blok |
Wielokrotno艣膰 fizycznych blok贸w istniej膮cego pliku danych. |
Parametry Zarz膮dzania Przestrzeni膮
INITIAL
NEXT
MAXEXTENTS
MINEXTENTS
PCTINCREASE
OPTIMAL
FREELISTS
FREELISTS
Parametry Wykorzystania Przestrzeni Bloku
PCTFREE
PCTUSED
INITRANS
MAXTRANS
Ekstenty
Extent to ci膮g艂a sekwencja blok贸w danych. Ekstenty s膮 przydzielane obiektom bazy danych w miar臋 ich wzrostu.
Ekstenty s膮 przydzielane kiedy:
Segment jest tworzony (INITIAL EXTENT).
Segment ro艣nie (NEXT EXTENT).
Tabela lub klaser jest modyfikowana w celu przydzia艂u ekstent贸w.
Ekstenty s膮 zwalniane kiedy:
Segment lub klaster jest usuwany.
Segment lub klaster jest obcinany (polecenie TRUNCATE).
Segment jest wi臋kszy ni偶 zadeklarowany rozmiar optymalny a zawiera wolne ekstenty (dotyczy tylko segment贸w wycofania).
Charakterystyka Ekstent贸w
Ka偶dy segment w bazie danych jest z艂o偶one z co najmniej jednego ekstentu w kt贸rym przechowuje dane.
Pierwszy ekstent nazywa si臋 ekstentem inicjalnym (initial extent).
Nast臋pne ekstenty s膮 nazywane ekstentami przyrostowymi (incremental extent).
Obiekt zarezerwuje nast臋pny ekstent je偶eli wszystkie jego dotychczasowe ekstenty s膮 ju偶 zape艂nione.
Cz臋ste zwalnianie ekstent贸w mo偶e prowadzi膰 do fragmentacji przestrzeni tabel.
Inicjalny ekstent jest zarezerwowany na zapas fragmentem przestrzeni bazy danych. Kiedy ekstent inicjalny zostanie zape艂niony, rezerwowany jest nast臋pny.
Dla serwera Oracle bloki z kolejnymi identyfikatorami stanowi膮 bloki sp贸jne (s膮siednie). Niekoniecznie musz膮 to by膰 bloki s膮siaduj膮ce ze sob膮 na dysku mimo, 偶e podczas tworzenia pliku serwer Oracle pr贸buje alokowa膰 ci膮g艂e obszary dysku.
Kontrola Przydzia艂u Ekstent贸w
Mo偶emy wp艂ywa膰 na przydzia艂 ekstent贸w segmentom. Ustawiamy parametry przydzia艂u przestrzeni poszczeg贸lnym obiektom oraz domy艣lne parametry przestrzeni tabel.
Parametry Zarz膮dzania Przestrzeni膮
INITIAL
NEXT
MAXEXTENTS
MINEXTENTS
PCTINCREASE
OPTIMAL
FREELISTS
FREELIST GROUPS
Ustawiamy parametry zarz膮dzania przestrzeni膮 dla:
Tabeli
Klastr贸w
Indeks贸w
Segment贸w wycofania
Przestrzeni tabel (ustawienie warto艣ci domy艣lnych)
Zasady Pierwsze艅stwa
Ka偶dy parametr zarz膮dzania przestrzeni膮 okre艣lony na poziomie obiektu przes艂ania odpowiedni膮 opcj臋 zdefiniowan膮 na poziomie przestrzeni tabel.
Je艣li parametr zarz膮dzania przestrzeni膮 nie jest podany jawnie na poziomie obiektu, stosuj膮 si臋 warto艣ci parametr贸w z poziomu przestrzeni tabel.
Je艣li parametry zarz膮dzania przestrzeni膮 nie s膮 jawnie podane na poziomie przestrzeni tabel, serwer Oracle stosuje domy艣lne warto艣ci systemowe.
Je艣li parametry zarz膮dzania przestrzenia zostan膮 zmodyfikowane, zmiany stosuj膮 si臋 tylko do nowoprzydzielanych ekstent贸w.
Opcja OPTIMAL mo偶e by膰 specyfikowana tylko dla segment贸w wycofania.
Parametry FREELISTS oraz FREELIST GROUPS nie mog膮 by膰 specyfikowane jako domy艣lne dla przestrzeni tabel.
Parametr |
Opis |
INITIAL |
Rozmiar w bajtach pierwszego ekstentu przydzielanego dla segmentu. Warto艣膰 domy艣lna to odpowiednik pi臋ciu blok贸w danych. |
NEXT |
Rozmiar w bajtach nast臋pnego ekstentu przydzielanego dla segmentu. Warto艣膰 domy艣lna to odpowiednik pi臋ciu blok贸w danych. |
MAXEXTENTS |
Okre艣la ca艂kowit膮 liczb臋 ekstent贸w (wliczaj膮c pierwszy) jak膮 Oracle ma prawo przydzieli膰 obiektowi. Warto艣膰 minimalna to 1. Warto艣膰 domy艣lna zale偶y od wybranego rozmiaru bloku i od Systemu operacyjnego. |
UNLIMITED |
Okre艣la, 偶e ekstenty maj膮 by膰 automatycznie dodawane w miar臋 potrzeb. Nie powinno si臋 u偶ywa膰 tej opcji w przypadku segment贸w wycofania ani tabel s艂ownikowych. |
MINEXTENTS |
Ca艂kowita liczba ekstent贸w rezerwowana podczas tworzenia segmentu. Warto艣膰 domy艣lna to pojedynczy ekstent, z wyj膮tkiem segment贸w wycofania, gdzie niezb臋dne s膮 dwa. |
PCTINCREASE |
Procent o jaki ro艣nie ka偶dy kolejny ekstent w stosunku do poprzedniego. Domy艣lnie to 50 procent, z wyj膮tkiem segment贸w wycofania, kt贸re nie u偶ywaj膮 tego parametru. |
OPTIMAL |
Okre艣la optymalny rozmiar segmentu wycofania w bajtach. Warto艣ci膮 domy艣lna jest null. |
FREELISTS |
Liczba list wolnych blok贸w stosowanych przy wstawianiu do tabeli. Domy艣lnie jest jedna. |
FREELIST GROUPS |
Liczba oddzielnych grup list wolnych blok贸w u偶ywanych przez oddzielne instancje w konfiguracji Parallel Serwer. Domy艣lna jest jedna. |
Uwaga: Podanie MINEXTENTS pozwala na zarezerwowanie du偶ej przestrzeni ju偶 podczas tworzenia segmentu.
Parametry przydzia艂u przestrzeni zmieniamy przez ustawienie wszystkich parametr贸w przydzia艂u przestrzeni w przestrzeni tabel.
Efekty Zmiany NEXT
Nast臋pny ekstent przyrostowy ma rozmiar NEXT. Kolejne ekstenty rosn膮 jak zwykle, stosuj膮c parametr PCTINCREASE.
Efekty Zmiany PCTINCREASE
Warto艣膰 NEXT jest obliczana z u偶yciem nast臋puj膮cego wzoru:
NEXT = NEXT * (1 + nowe PCTINCREASE/100)
zaokr膮glone do nast臋pnego bloku Oracle.
Efekty Jednoczesnej Zmiany NEXT oraz PCTINCREASE
Nast臋pny ekstent ma przypisan膮 now膮 warto艣膰 NEXT. Od tej pory warto艣膰 NEXT b臋dzie obliczana na podstawie PCTINCREASE zwyk艂膮 metod膮.
Zmiana warto艣ci domy艣lnych w przestrzeni tabel stosuje si臋 tylko do nowotworzonych obiekt贸w w tej przestrzeni tabel.
Parametry INITIAL oraz MINEXTENTS nie mog膮 by膰 modyfikowane.
Przy okre艣laniu parametr贸w zarz膮dzania przestrzeni膮 kierujemy si臋 zasad膮 maksymalnego wykorzystania sp贸jnej wolnej przestrzeni i ochron膮 wolnego miejsca przestrzeni tabel przed fragmentacj膮.
Fragmentacja wolnej przestrzeni mo偶e spowodowa膰 zmniejszenie efektywno艣ci.
Fragmentacj臋 ograniczamy przez:
Dopasowanie ekstentu INITIAL do wielko艣ci segmentu.
W艂a艣ciwe ustawienie PCTINCREASE zwi臋kszaj膮ce wielko艣膰 ekstent贸w przyrostowych.
Bloki Bazy Danych
Bloki bazy danych serwera Oracle s膮 najmniejsz膮 jednostk膮 przestrzeni u偶ywan膮 w bazie danych.
W艂asno艣ci Blok贸w Bazy Danych
Bloki Bazy Danych odpowiadaj膮 jednemu lub wielu fizycznym blokom dyskowym.
Rozmiar jest definiowany przy tworzeniu bazy danych przez parametr DB_BLOCK_SIZE i jest identyczny dla wszystkich plik贸w danych.
DB_BLOCK_SIZE tak偶e okre艣la rozmiar ka偶dego bufora bazy danych w SGA.
Bloki bazy danych s膮 tak偶e nazywane blokami logicznymi lub blokami serwera Oracle.
Kiedy ju偶 baza danych Oracle zostanie utworzona, parametr DB_BLOCK_SIZE nie mo偶e ju偶 by膰 zmieniony.
Rozmiar bloku bazy danych w serwerze Oracle to zwykle 2 KB, 4 KB, lub 8 KB. Warto艣膰 domy艣lna zale偶y od systemu operacyjnego.
Zaleca si臋 aby rozmiar blok serwera Oracle by艂 r贸wny lub by艂 wielokrotno艣ci膮 rozmiaru bloku w systemie operacyjnym.
Na pewnych platformach rozmiar bloku mo偶e by膰 bardzo du偶y (np. 32 KB). Opcja ta nazywana jest Big Oracle Blocks.
Wszystkie operacje I/O s膮 wykonywane na bloku lub serii blok贸w. Blokady serwera Oracle zak艂adane s膮 jednak nie na poziomie blok贸w, lecz wierszy.
Format bloku serwera Oracle jest podobny niezale偶nie od tego, czy blok zawiera dane tabeli, indeksu czy klasera.
Cz臋艣ci Bloku Bazy Danych
Fragment Bloku |
Opis |
Nag艂贸wek (header) |
Zawiera og贸lne informacje o bloku takie jak adres bloku, typ segmentu. |
S艂ownik tabel (table directory) |
Zawiera informacje o tabelach w przypadku tabel w klaserze. |
S艂ownik wierszy (row directory) |
Zawiera informacje o wierszach zawartych w bloku Wymagany narzut to dwa bajty na ka偶dy wiersz. |
Wolne miejsce (free space) |
Sk艂ada si臋 z bajt贸w blok贸w nadal dost臋pnych na wstawienia lub aktualizacj臋 wierszy lub te偶 na dodatkowe informacje o transakcjach. |
Wiersze danych (row data) |
Przechowuje dane tabeli lub indeksu. |
Wolna przestrze艅 w blokach danych tabeli, klastra lub indeksu mo偶e r贸wnie偶 zawiera膰 zapisy transakcji. Zapis transakcji w bloku jest wymagany dla ka偶dej transakcji u偶ywaj膮cej jednego lub wielu wierszy z tego bloku. Zapisy transakcji, konieczne dla blokad na poziomie wierszy, umieszczane s膮 w wolnej przestrzeni bloku.
Kontrola Wykorzystania Przestrzeni
Wykorzystanie przestrzeni przez operacj臋 wstawienia, modyfikacji i usuwania wierszy w bloku bazy danych kontrolujemy przez ustawienie odpowiednich warto艣ci parametr贸w kontroli wykorzystania przestrzeni.
Parametry Wykorzystania Przestrzeni
Parametry PCTFREE oraz PCTUSED pozwalaj膮 na kontrolowanie wykorzystania wolnej przestrzeni w operacjach wstawiania i modyfikacji wierszy w bloku bazy danych. Ka偶dy z tych parametr贸w mo偶e by膰 zdefiniowany dla tabeli, klastra i migawki w poleceniach CREATE i ALTER. PCTFREE mo偶e by膰 tak偶e definiowany dla indeks贸w.
Suma PCTFREE i PCTUSED musi by膰 mniejsza lub r贸wna 100.
Parametr |
Definicja |
PCTFREE |
Okre艣la procent przestrzeni ka偶dego bloku danych zarezerwowany na przysz艂e modyfikacje wierszy tabeli. Warto艣ci膮 domy艣ln膮 PCTFREE jest 10 procent. |
PCTUSED |
Okre艣la minimalny procent u偶ytej przestrzeni jaki jest obliczany przez Oracle dla ka偶dego bloku tabeli. Blok staje si臋 kandyduj膮cym |
INITRANS |
Okre艣la na liczb臋 zapis贸w transakcji rezerwowanych inicjalnie w nag艂贸wku bloku. |
MAXTRANS |
Okre艣la maksymaln膮 liczb臋 transakcji jakie mog膮 odwo艂ywa膰 si臋 jednocze艣nie do pojedynczego bloku. |
Zarezerwowany (pozostawiamy wolny) fragment przestrzeni bloku na przysz艂e modyfikacje umieszczonych ju偶 w bloku wierszy ustawiamy za pomoc膮 parametru PCTFREE.
PCTFREE
PCTFREE definiuje procent dost臋pnej przestrzeni bloku zarezerwowany na mo偶liwe modyfikacje wierszy zawartych w tym bloku. Domy艣lnie jest to 10 procent.
Po osi膮gni臋ciu PCTFREE, blok jest uznawany za pe艂ny i nie jest dost臋pny dla operacji wstawiania nowych wierszy.
Parametr PCTFREE mo偶e by膰 r贸wnie偶 okre艣lany przy tworzeniu lub modyfikacji indeks贸w.
Wolna przestrze艅 jest zape艂niona przez wstawienia nowych wierszy, rozrost istniej膮cych wierszy i rozrost nag艂贸wka bloku danych.
Blok jest usuwany z listy wolnych kiedy rozmiar wolnej przestrzeni spadnie poni偶ej granicy PCTFREE.
PCTFREE wyspecyfikowane dla indeksu rezerwuje miejsce zar贸wno dla modyfikacji jak i wstawiania pozycji. Wtedy wolna przestrze艅 jest obliczana jako procent od DB_BLOCK_SIZE minus rozmiar nag艂贸wka.
Procent wolnej przestrzeni w blokach danych mo偶emy obliczy膰 u偶ywaj膮c nast臋puj膮cego wzoru:
PCTFREE聽=
* 100
Uwaga: Zjawiska migracji wierszy i wierszy w 艂a艅cuchu nadal mog膮 mie膰 miejsce, nawet je艣li obliczymy PCTFREE stosuj膮c powy偶szy wz贸r.
Parametr PCTUSED ustawiamy aby kontrolowa膰 moment, kiedy blok b臋dzie brany pod uwag臋 podczas wstawiania nowych wierszy. Nowe wiersze b臋d膮 wstawiane do bloku dop贸ki blok znajduje si臋 na li艣cie wolnych. Blok jest usuwany z listy wolnych po osi膮gni臋ciu granicy PCTFREE i pozostaje poza ni膮 dop贸ki jest wype艂niony bardziej ni偶 PCTUSED.
PCTUSED
PCTUSED jest granic膮 decyduj膮c膮 kiedy blok staje si臋 dost臋pny dla wstawienia nowych wierszy.
Kiedy procent u偶ytej przestrzeni bloku spada poni偶ej PCTUSED, albo w wyniku usuwania wierszy, albo w wyniku modyfikacji redukuj膮cych rozmiar kolumn, blok ponownie jest dost臋pny dla wstawienia nowych wierszy.
Domy艣ln膮 warto艣ci膮 systemow膮 dla PCTUSED jest 40.
Serwer Oracle dodaje blok do listy wolnych kiedy stwierdzi, 偶e u偶ywana przestrze艅 bloku spad艂a poni偶ej granicy PCTUSED. Lista wolnych to lista wska藕nik贸w do blok贸w, kt贸re mog膮 by膰 wykorzystywane przy wstawianiu nowych wierszy. Bloki s膮 dodawane i usuwane z listy wolnych kiedy u偶ywana przestrze艅 odpowiednio spada poni偶ej PCTUSED i wzrasta powy偶ej PCTFREE.
Przez parametry PCTFREE i PCTUSED mo偶emy poprawi膰 efektywno艣膰 i wykorzystanie przestrzeni.
Ma艂a Warto艣膰 Parametru PCTFREE
Pozwala na pe艂niejsze zape艂nienie blok贸w operacjami wstawienia.
Mo偶e zmieni膰 dane w mniejszej liczbie blok贸w.
Mo偶e zwi臋kszy膰 koszty przetwarzania je艣li serwer Oracle cz臋sto dokonuje reorganizacji blok贸w.
Mo偶e spowodowa膰 migracj臋 wierszy.
Du偶a Warto艣膰 Parametru PCTFREE
Rezerwuje wi臋cej przestrzeni dla przysz艂ych modyfikacji.
Mo偶e wymaga膰 wi臋kszej liczby blok贸w na przechowanie danych.
Obni偶a koszty przetwarzania poniewa偶 bloki rzadziej wymagaj膮 reorganizacji.
Zmniejsza efekt wierszy w 艂a艅cuchach (chained rows).
Ma艂a Warto艣膰 PCTUSED
Zmniejsza koszty przetwarzania, poniewa偶 bloki rzadziej s膮 uznawane za wolne.
Zwi臋ksza nieu偶ywan膮 przestrze艅.
Du偶a Warto艣膰 PCTUSED
Zwi臋ksza koszty przetwarzania, poniewa偶 bloki cz臋艣ciej s膮 uznawane za wolne.
Poprawia wykorzystanie przestrzeni.
Kiedy procent wolnej przestrzeni w bloku danych osi膮ga PCTFREE, 偶aden nowy wiersz nie mo偶e by膰 wstawiony do bloku dop贸ki procent wykorzystanej przestrzeni nie spadnie poni偶ej ustawienia PCTUSED. St膮d, je艣li warto艣膰 PCTUSED jest niska, blok nie b臋dzie rejestrowany jako wolny zbyt cz臋sto i koszt przenoszenia bloku na list臋 wolnych jest zredukowany. Z聽drugiej strony, je艣li PCTUSED jest wysokie, blok b臋dzie postrzegany jako wolny du偶o cz臋艣ciej i koszt przetwarzania wzro艣nie.
Kompromisem wykorzystania przestrzeni i efektywno艣ci I/O jest suma PCTFREE i聽PCTFREE r贸偶na od 100 o procent dost臋pnej przestrzeni bloku jak膮 zajmuje przeci臋tnie jeden wiersz. Na przyk艂ad dla bloku o rozmiarze 2048 po odj臋ciu 100 bajt贸w narzutu pozostaje 1948 bajt贸w dost臋pnych dla danych. Je艣li przeci臋tny wiersz zajmuje 195 bajt贸w, czyli 10% z 1948, suma PCTUSED i PCTFREE powinna wynosi膰 90%.
Liczb臋 aktywnych transakcji operuj膮cych na tym samym bloku okre艣lamy przez parametry INITRANS i MAXTRANS.
INITRANS
INITRANS to inicjalna liczba zapis贸w wsp贸艂bie偶nych transakcji rezerwowana w ka偶dym nag艂贸wku bloku podczas tworzenia bloku (domy艣lnie 1, minimalnie 1, maksymalnie 255). Ka偶dy zapis transakcji zajmuje oko艂o 23 bajt贸w (jest to zale偶ne od systemu operacyjnego).
MAXTRANS
MAXTRANS to maksymalna liczba wsp贸艂bie偶nych transakcji dopuszczalna na bloku (maksymalnie 255).
Domy艣lna warto艣膰 MAXTRANS jest zale偶na od systemu od systemu operacyjnego, ale zwykle wynosi 255.
Ka偶da transakcja zajmuje oko艂o 23 bajt贸w przestrzeni bloku. Je艣li brak wolnej przestrzeni bloku, transakcja jest zawieszona w oczekiwaniu na dost臋p do bloku.
艁a艅cuchy i Migracja
Aby unikn膮膰 pogorszenia si臋 efektywno艣ci monitorujemy zjawiska wierszy w 艂a艅cuchach (row chaining) i migracj臋 wierszy (migration).
艁a艅cuchy (Chaining)
Wiersz, kt贸ry nie mie艣ci si臋 w pojedynczym bloku zajmuje 艂a艅cuch z艂o偶ony z wielu blok贸w.
Pocz膮tkowy odcinek wiersza pozostaje w bloku w kt贸rym wiersz by艂 umieszczony inicjalnie.
Wszystkie dodatkowe cz臋艣ci umieszczone s膮 w do艂膮czonym do 艂a艅cucha bloku.
Migracja (Migration)
Wiersz migruj膮cy jest przeniesiony w ca艂o艣ci z oryginalnego bloku do bloku do艂膮czonego do 艂a艅cucha. Jednak nag艂贸wek wiersza pozostaje w bloku, gdzie wiersz zosta艂 utworzony pocz膮tkowo.
Wiersz migruje kiedy modyfikacja wymaga wi臋cej miejsca ni偶 jest aktualnie dost臋pne w bloku.
Odpowiednio du偶a warto艣膰 PCTFREE pozwala na unikni臋cie efektu migracji wierszy.
Ko艅cowe kolumny NULL (czyli te z ko艅ca wiersza) nie s膮 przechowywane je艣li zosta艂y dodane do struktury tabeli poleceniem ALTER TABLE.
Parametry PCTFREE i PCTUSED optymalizuj膮 wykorzystanie przestrzeni w blokach danych.
Zwi臋kszaj膮c parametr PCTFREE redukujemy zjawisko migracji wierszy.
艁a艅cuchy i Migracja Wierszy
艁a艅cuch pojawia si臋 je艣li wiersze tabeli s膮 d艂ugie. Wtedy dane z wielkiego wiersza tabeli nie mog膮 zmie艣ci膰 si臋 w pojedynczym bloku. Dane wiersza s膮 przechowywane w 艂a艅cuchu blok贸w danych.
Migracja wyst臋puje kiedy wiersz w bloku danych jest modyfikowany tak, 偶e jego d艂ugo艣膰 przekracza wielko艣膰 wolnej przestrzeni w bloku. Wtedy dane tego wiersza s膮 przenoszone do nowego bloku danych (o ile ca艂y wiersz mo偶e zmieni膰 si臋 w nowym bloku).
Wp艂yw na Efektywno艣膰
Efektywno艣膰 I/O spada przy odczycie wierszy w 艂a艅cuchach lub wierszy przeniesionych.
Serwer Oracle musi przejrze膰 wi臋cej ni偶 jeden blok danych aby wyszuka膰 informacje z takiego wiersza.
Usuwanie Migracji Wierszy
Sprawd藕 wyst臋powanie w obiektach wierszy w 艂a艅cuchach lub przeniesionych za pomoc膮 polecenia ANALYZE.
Zmie艅 PCTFREE dla obiekt贸w z takimi wierszami.
Wykonaj export, usu艅 obiekt i zaimportuj go ponownie.
Identyfikujemy wyst臋powanie wierszy w 艂a艅cuchach i wierszy przeniesionych za pomoc膮 polecenia ANALYZE. Polecenie ANALYZE dokonuje analizy wskazanej tabeli.
Sk艂adnia:
U偶ycie Polecenia ANALYZE
Polecenie ANALYZE zapami臋tuje identyfikatory wierszy (rowid) i inne informacje w tabeli CHAINED_ROWS w Twoim schemacie. Identyfikatory wierszy reprezentuj膮 blok pocz膮tkowy zar贸wno wierszy w 艂a艅cuchach jak i przeniesionych.
Przez podanie polecenia
ANALYZE TABLE tabela1 LIST CHAINED ROWS INTO tabela2
mo偶emy spowodowa膰 zapisanie informacji w tabeli o nazwie innej ni偶 CHAINED_ROWS.
Do utworzenia tabeli CHAINED_ROWS mo偶na u偶y膰 skryptu SQL serwera Oracle o nazwie UTLCHAIN.SQL, (ewentualnie po modyfikacji kopii pliku w celu zmiany nazwy tabeli).
Wy艣wietlanie Informacji o Ekstentach i Segmentach
Aby obejrze膰 ile ekstent贸w zosta艂o przydzielonych i jak wiele istnieje segment贸w piszemy zapytania oparte na perspektywach s艂ownika danych.
Perspektywy S艂ownika Danych
USER/DBA_EXTENTS
USER/DBA_FREE_SPACE
USER/DBA_SEGMENTS
DBA_TABLESPACES
DBA_DATA_FILES
Przyk艂ady
Lista wszystkich kolumn perspektywy DBA_TABLESPACES.
SQL>聽DESCRIBE dba_tablespaces |
Nazwa kolumny Warto艣膰 Typ
------------------------------ -------- ----
TABLESPACE_NAME NOT NULL VARCHAR2(30)
INITIAL_EXTENT NOT NULL NUMBER
NEXT_EXTENT NOT NULL NUMBER
MIN_EXTENTS NOT NULL NUMBER
MAX_EXTENTS NOT NULL NUMBER
PCT_INCREASE NOT NULL NUMBER
STATUS NOT NULL VARCHAR2(9)
CONTENTS NOT NULL VARCHAR2(9)
Lista nazw i status贸w wszystkich przestrzeni tabel.
SQL> SELECT tablespace_name, status, contents 2> FROM dba_tablespaces; |
TABLESPACE_NAME STATUS CONTENTS
------------------------------ --------- ---------
SYSTEM ONLINE PERMANENT
USER_DATA ONLINE PERMANENT
ROLLBACK_DATA ONLINE PERMANENT
TEMPORARY_DATA ONLINE PERMANENT
REPOSITORY_DATA ONLINE PERMANENT
INDEX_DATA ONLINE PERMANENT
Lista kolumn w DBA_DATA_FILES
SQL>聽DESCRIBE dba_data_files |
Nazwa kolumny Warto艣膰 Typ
------------------------------ -------- ----
FILE_NAME VARCHAR2(513)
FILE_ID NOT NULL NUMBER
TABLESPACE_NAME NOT NULL VARCHAR2(30)
BYTES NOT NULL NUMBER
BLOCKS NOT NULL NUMBER
STATUS NOT NULL VARCHAR2(9)
AUTOEXTENSIBLE VARCHAR2(3)
MAXBYTES NOT NULL NUMBER
MAXBLOCKS NUMBER
INCREMENT_BY NUMBER
Lista og贸lnych informacji o plikach danych nale偶膮cych do poszczeg贸lnych przestrzeni tabel.
SQL> SELECT file_name, file_id, tablespace_name, bytes 2> FROM dba_data_files; |
FILE_NAME FILE_ID TABLESPACE_NAME BYTES
------------------------------- -------- -------------------------- ------------
D:\ORANT\DATABASE\USR1ORCL.ORA 2 USER_DATA 115343360
D:\ORANT\DATABASE\RBS1ORCL.ORA 3 ROLLBACK_DATA 36700160
D:\ORANT\DATABASE\TMP1ORCL.ORA 4 TEMPORARY_DATA 7825792
D:\ORANT\DATABASE\SYS1ORCL.ORA 1 SYSTEM 167772160
D:\ORANT\DATABASE\REPORCL.ORA 5 REPOSITORY_DATA 2097152
D:\ORANT\DATABASE\IND1ORCL.ORA 6 INDEX_DATA 55267328
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Wy艣wietlanie obszar贸w w wolnej przestrzeni w poszczeg贸lnych przestrzeniach tabel.
SQL> SELECT * 2> FROM dba_free_space 3> ORDER BY file_id, block_id: |
TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_F
--------------------------- ---------- ---------- ---------- --------- ----------
SYSTEM 1 1213 10240 5 1
SYSTEM 1 48896 204800 100 1
SYSTEM 1 49111 61440 30 1
SYSTEM 1 69136 30720 15 1
SYSTEM 1 69251 92160 45 1
SYSTEM 1 70531 40960 20 1
USER_DATA 2 4417 51200 25 2
USER_DATA 2 5392 112640 55 2
USER_DATA 2 29848 81920 40 2
USER_DATA 2 38984 61440 30 2
USER_DATA 2 55872 30720 15 2
USER_DATA 2 56127 327680 160 2
ROLLBACK_DATA 3 16186 3553280 1735 3
TEMPORARY_DATA 4 1861 14016512 6844 4
REPOSITORY_DATA 5 312 30720 15 5
REPOSITORY_DATA 5 632 163840 80 5
INDEX_DATA 6 26964 47104 23 6
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Ta sama informacja o wolnej przestrzeni z wykorzystaniem nazw plik贸w zamiast ich identyfikator贸w.
SQL> SELECT free.tablespace_name, bloc_id, free.bytes, 2> free.blocks, df.file_name 3> FROM dba_free_space free, dba_data files df 4> WHERE free. File_id = df.file_id 5> ORDER BY 1 , 2; |
TABLESPACE_NAME BLOCK_ID BYTES BLOCKS FILE_NAME
---------------- -------- ---------- -------- -----------------------------------
INDEX_DATA 26964 47104 23 D:\ORANT\DATABASE\IND1ORCL.ORA
REPOSITORY_DATA 312 30720 15 D:\ORANT\DATABASE\REPORCL.ORA
REPOSITORY_DATA 632 163840 80 D:\ORANT\DATABASE\REPORCL.ORA
ROLLBACK_DATA 16186 3553280 1735 D:\ORANT\DATABASE\RBS1ORCL.ORA
SYSTEM 1213 10240 5 D:\ORANT\DATABASE\SYS1ORCL.ORA
SYSTEM 48896 204800 100 D:\ORANT\DATABASE\SYS1ORCL.ORA
SYSTEM 49111 61440 30 D:\ORANT\DATABASE\SYS1ORCL.ORA
SYSTEM 69136 30720 15 D:\ORANT\DATABASE\SYS1ORCL.ORA
SYSTEM 69251 92160 45 D:\ORANT\DATABASE\SYS1ORCL.ORA
SYSTEM 70531 40960 20 D:\ORANT\DATABASE\SYS1ORCL.ORA
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Lista kolumn w DBA_SEGMENTS
SQL> DESCRIBE dba_segments |
Nazwa kolumny Warto艣膰 Typ
------------------------------ -------- ----
OWNER VARCHAR2(30)
SEGMENT_NAME VARCHAR2(81)
PARTITION_NAME VARCHAR2(30)
SEGMENT_TYPE VARCHAR2(17)
TABLESPACE_NAME VARCHAR2(30)
HEADER_FILE NUMBER
HEADER_BLOCK NUMBER
BYTES NUMBER
BLOCKS NUMBER
EXTENTS NUMBER
INITIAL_EXTENT NUMBER
NEXT_EXTENT NUMBER
MIN_EXTENTS NUMBER
MAX_EXTENTS NUMBER
PCT_INCREASE NUMBER
FREELISTS NUMBER
FREELIST_GROUPS NUMBER
Og贸lna informacja o wszystkich segmentach w bazie danych.
SQL> SELECT owner, segment_name, extents, max_extents 2> FROM dba_segments 3> ORDER BY owner, segment_name; |
OWNER SEGMENT_NAME EXTENTS MAX_EXTENT
--------- ------------------------ ---------- ----------
SYS ACCESS$ 9 2147483645
SYS AQ$_QUEUE_STATISTICS 1 121
SYS AUD$ 1 121
SYS AUDIT$ 1 121
SYS AUDIT_ACTIONS 1 121
...
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Informacja podsumowuj膮ca grupy segment贸w w poszczeg贸lnych przestrzeniach tabel.
SQL> SELECT TABLESPACE_NAME, COUNT (*) AS SEGMENTS, 2> sum (bytes) AS BYTES 3> FROM dba_segments 4> GROUP BY tablespace_name; |
TABLESPACE_NAME SEGMENTS BYTES
------------------------------ ---------- ----------
INDEX_DATA 320 55218176
REPOSITORY_DATA 158 1900544
ROLLBACK_DATA 16 33144832
SYSTEM 235 158472192
TEMPORARY_DATA 80 3807232
USER_DATA 2899 113655808
Lista kolumn w DBA_EXTENTS.
SQL> DESCRIBE dba_extents |
Nazwa kolumny Warto艣膰 Typ
------------------------------ -------- ----
OWNER VARCHAR2(30)
SEGMENT_NAME VARCHAR2(81)
PARTITION_NAME VARCHAR2(30)
SEGMENT_TYPE VARCHAR2(17)
TABLESPACE_NAME VARCHAR2(30)
EXTENT_ID NOT NULL NUMBER
FILE_ID NOT NULL NUMBER
BLOCK_ID NOT NULL NUMBER
BYTES NOT NULL NUMBER
BLOCKS NOT NULL NUMBER
Informacja o ekstentach przydzielonych w bazie danych.
SQL>SELECT * FROM dba_extents; |
OWNER SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID BLOCK_ID BYTES BLOCKS
------ ------------- ------------ --------------- --------- -------- ----- ------
SYS FILE$ TABLE SYSTEM 0 162 10240 5
SYS UNDO$ TABLE SYSTEM 0 157 10240 5
SYS BOOTSTRAP$ TABLE SYSTEM 0 352 51200 25
SYS CON$ TABLE SYSTEM 5 47711 61440 30
SYS CON$ TABLE SYSTEM 6 48751 92160 45
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Zwalnianie Niewykorzystanej Przestrzeni
Czasami zdarza si臋, 偶e zarezerwujemy przestrze艅 dla segmentu, a potem stwierdzimy, 偶e nie jest ona u偶ywana. Warto wtedy zwolni膰 nieu偶ywan膮 przestrze艅, aby mo偶na by艂o udost臋pni膰 j膮 innym segmentom.
Maksymaln膮 w ca艂ej historii segmentu wielko艣膰 wykorzystanej przestrzeni wskazuje tzw. znacznik wysokiej wody (high water mark). Nawet po usuni臋ciu wierszy znacznik ten nie jest przesuwany.
Przestrze艅 poni偶ej znacznika wysokiej wody nie mo偶e by膰 zwolniona.
Znacznik wysokiej wody mo偶e by膰 znaleziony za pomoc膮 procedury pakietowej DBMS_SPACE.UNUSED_SPACE.
Je艣li segment jest ca艂kowicie pusty, przestrze艅 mo偶e by膰 zwolniona za pomoc膮 polecenia TRUNCATE DROP STORAGE.
Do zwalniania niewykorzystanej pami臋ci s艂u偶y polecenie ALTER TABLE.
Sk艂adnia:
SQL> ALTER TABLE big_emp DEALLOCATE UNUSED; |
Uwaga: Po zwolnieniu przestrzeni znacznik wysokiej wody pozostaje niezmieniony.
Je偶eli nie chcemy zwolni膰 ca艂ej nieu偶ywanej przestrzeni u偶ywamy klauzuli KEEP (zachowaj)
Efekt zwolnienia przestrzeni mo偶emy sprawdzi膰 w perspektywie DBA_FREE_SPACE; kluczami do odpowiednich tabel s膮 EXTENT_ID, FILE_ID oraz BLOCK_ID.
艁膮czenie Wolnej Przestrzeni
Przydzia艂 przestrzeni dla segment贸w umieszczonych w przestrzeniach tabel odbywa si臋 za pomoc膮 ekstent贸w zbudowanych z ci膮g艂ych sekwencji blok贸w danych, Je艣li pewien wolny obszar przestrzeni jest fragmentowany, podzielony na kilka mniejszych obszar贸w, wolne obszary przestrze艅 tabel mog膮 by膰 z艂膮czone (coalesced). Jest to domy艣lnie wykonywane przez proces monitora systemu (SMON), ale mo偶e by膰 tak偶e spowodowane wykonaniem polecenia ALTER TABLESPACE z klauzul膮 COALESCE.
Przyk艂ad
SVRMGR> ALTER TABLESPACE users COALESCE; |
Statystyki o ekstentach jakie mog膮 by膰 z艂膮czone w przestrzeni tabel mo偶emy obejrze膰 w perspektywie DBA_FREE_SPACE_COALESCED. Zapytania na tej perspektywie pozwalaj膮 stwierdzi膰 czy obszary przestrzeni tabel wymagaj膮 艂膮czenia.
Po ka偶dych o艣miu z艂膮czeniach transakcja 艂膮cz膮ca zatwierdza zmiany i inne transakcje mog膮 wtedy dokonywa膰 rezerwacji lub zwalniania przestrzeni. Oznacz to, 偶e by膰 mo偶e trzeba b臋dzie wykona膰 polecenie ALTER TABLESPACE wielokrotnie. Sprawdzaj perspektyw臋 DBA_FREE_SPACE_COALESCED.
Walidacja Struktur
Walidacja sprawdza integralno艣膰 struktur indeks贸w, tabel i klastr贸w.
Walidacja Indeks贸w
Serwer Oracle sprawdza integralno艣膰 ka偶dego bloku danych i sprawdza czy blok nie jest zniszczony.
Serwer Oracle nie sprawdza, czy ka偶dy wiersz tabeli ma odpowiadaj膮c膮 pozycj臋 w indeksie ani czy ka偶da pozycja indeksu wskazuje na pewien wiersz w tabeli.
Walidacja Tabel
Serwer Oracle sprawdza integralno艣膰 ka偶dego bloku danych.
Je偶eli u偶yto opcji CASCADE sprawdzana jest te偶 struktura wszystkich indeks贸w tabeli i odpowiednio艣膰 mi臋dzy tabel膮 a jej indeksami.
Walidacja Klastr贸w
Serwer Oracle sprawdza integralno艣膰 ka偶dego wiersza w klaserze.
Serwer Oracle dokonuje walidacji struktur wszystkich tabel klastra.
U偶ycie opcji CASCADE powoduje walidacj臋 struktur wszystkich indeks贸w tabel klastra, w tym indeksu klastra.
Je偶eli zosta艂a u偶yta opcja CASCADE w celu sprawdzenia odpowiednio艣ci indeks贸w, sprawdzane jest czy:
Ka偶da warto艣膰 indeksowanej kolumny tabeli pasuje do odpowiedniej warto艣ci kolumny w pozycji indeksu. Odpowiadaj膮ca pozycja indeksu musi ponadto identyfikowa膰 wiersz tabeli przez poprawny identyfikator wiersza rowid.
Ka偶da pozycja w indeksie identyfikuje pewien wiersz w tabeli. Warto艣膰 indeksowanej kolumny w pozycji indeksu musi odpowiada膰 warto艣ci ze wskazywanego wiersza.
Sk艂adnia
gdzie:
indeks jest nazw膮 indeksu jaki ma by膰 analizowany. Je艣li pomini臋to schemat, serwer Oracle zak艂ada istnienie indeksu w bie偶膮cym schemacie.
tabela jest nazw膮 tabeli jaka ma by膰 analizowana. Je艣li pomini臋to schemat, serwer Oracle zak艂ada istnienie tabeli w bie偶膮cym schemacie.
klaster jest nazw膮 klastra jaki ma by膰 analizowany. Je艣li pomini臋to schemat, serwer Oracle zak艂ada istnienie klastra w bie偶膮cym schemacie.
VALIDATE STRUCTURE powoduje walidacj臋 struktury analizowanego obiektu. Je偶eli u偶yjemy tej opcji dla klastra, serwer Oracle automatycznie dokona walidacji wszystkich tabel z klastra.
CASCADE powoduje walidacj臋 struktury zwi膮zanych z tabel膮 lub klastrem indeks贸w.
Je艣li serwer Oracle dokona pomy艣lnej walidacji struktury, zwraca komunikat potwierdzaj膮cy walidacj臋. Je艣li zauwa偶ono zniszczenie struktury obiektu, zwracany jest b艂膮d. W takim przypadku nale偶y usun膮膰 i ponownie utworzy膰 obiekt. Po u偶yciu polecenia ANALYZE...VALIDATE STRUCTURE do analizy obiektu tabela INDEX_STATS b臋dzie zawiera膰 zapis informacji statystycznej.
Przyk艂ady
Walidacja struktury indeksu PARTS_INDEX.
SQL> ANALYZE INDEX parts_index 2> VALIDATE STRUCTURE; |
Walidacja struktury klastra ORDER_CUST, wszystkich jego tabel i indeks贸w, w tym indeksu klastra.
SQL> ANALYZE CLUSTER order_cust 2> VALIDATESTRUCTURE 3> CASCADE; |
Monitorowanie Wykorzystania Przestrzeni
Powinni艣my kontrolowa膰 wykorzystanie przestrzeni przez segmenty, zw艂aszcza je艣li s膮 one modyfikowane.
Monitorujemy 艣redni膮 efektywno艣膰 wykorzystania przestrzeni przez segment przez wykonywanie nast臋puj膮cych krok贸w.
Monitorowanie Wykorzystania Przestrzeni
Analiza obiektu za pomoc膮 polecenia ANALYZE.
Zanotowanie procentowego wykorzystania przestrzeni.
Wykonujemy kroki 1 i 2 w regularnych odst臋pach czasu i por贸wnujemy wyniki. Je艣li wykorzystywana przez obiekt przestrze艅 maleje poni偶ej jego przeci臋tnej, mo偶emy wyeksportowa膰, usun膮膰 i zaimportowa膰 ten obiekt.
Indeksy kontrolujemy przez wykonanie polecenia ANALYZE lub wykonuj膮c zapytania wprost na perspektywach s艂ownika danych odnosz膮cych si臋 do indeks贸w. Indeksy mog膮 by膰 usuwane i tworzone ponownie.
Wszystkie ekstenty pozostaj膮 zarezerwowane a偶 do czasu obci臋cia lub usuni臋cia segmentu.
Monitorujemy wykorzystanie przestrzeni przez indeks za pomoc膮 polecenia ANALYZE STRUCTURE i przegl膮dania tabeli INDEX_STATS.
Podsumowanie
Serwer Oracle przydziela przestrze艅 bazy danych wszystkim danym w bazie.
Termin
|
Definicja |
Baza danych |
Logiczny zbi贸r dzielonych danych przechowywanych w przestrzeniach tabel.
|
Plik |
Fizyczny plik danych nale偶膮cy do pojedynczej przestrzeni tabel.
|
Przestrze艅 tabel |
Logiczne repozytorium fizycznie zgrupowanych danych.
|
Segment |
Zbi贸r z艂o偶ony z jednego lub z wielu ekstent贸w zawieraj膮cy wszystkie dane okre艣lonej struktury przechowywanej w przestrzeni tabel.
|
Ekstent |
Zbi贸r sp贸jnych (s膮siednich) blok贸w bazy danych w pliku danych.
|
Blok |
Wielokrotno艣膰 fizycznych blok贸w istniej膮cego pliku danych. |
Parametry Zarz膮dzania Przestrzeni膮
INITIAL
NEXT
MAXEXTENTS
MINEXTENTS
PCTINCREASE
OPTIMAL
FREELISTS
Parametry Wykorzystania Przestrzeni Bloku
PCTFREE
PCTUSED
INITRANS
MAXTRANS
Zadania
Napisz zapytanie na DBA_SEGMENTS, kt贸re wypisze nazw臋 segmentu, jego bajty, bloki i liczb臋 dopuszczalnych dodatkowych ekstent贸w
Napisz zapytanie na DBA_FREE_SPACE, kt贸re znajdzie ilo艣膰 wolnej przestrzeni w ka偶dej z przestrzeni
VIII.聽Zarz膮dzanie segmentami wycofania
Cele
W tej lekcji nauczymy si臋 zarz膮dza膰 segmentami wycofania Oracle, w tym tez wp艂ywa膰 na ich rozmiar.
Po przerobieniu tej lekcji powiniene艣 potrafi膰:
Opisa膰 i zarz膮dza膰 funkcjami segment贸w wycofania.
Tworzy膰 segmenty wycofania o w艂a艣ciwym rozmiarze.
Opisa膰 kompromisy mi臋dzy wykorzystaniem pami臋ci a efektywno艣ci膮.
Okre艣li膰 liczb臋 segment贸w wycofania.
Przegl膮d
Segment wycofania to zbi贸r ekstent贸w zawieraj膮cych danie wycofania wykorzystywane przy wycofaniu transakcji, zapewnianiu sp贸jno艣ci odczytu i odtwarzaniu bazy danych.
U偶ycie wielu segment贸w wycofania.
Wyb贸r pomi臋dzy publicznymi i prywatnymi segmentami wycofania.
W艂a艣ciwe ustawienie rozmiaru segmentu wycofania.
Monitorowanie segmentu wycofania w narz臋dziu Serwer Manager.
Ustawienie optymalnej liczby ekstent贸w dla ka偶dego segmentu wycofania.
Segmenty Wycofania
Segment wycofania (rollback segment) to fragment bazy danych przeznaczony na zapis danych sprzed zmodyfikowania ich przez transakcj臋, co pozwala na wycofanie zmian w pewnych warunkach.
Transakcja (transaction) jest jednostk膮 operacji na bazie danych powoduj膮c膮 zmiany i blokady wierszy. Ka偶da transakcja ma przydzielony unikalny identyfikator i dok艂adnie jeden segment wycofania. Segment wycofania jest obiektem cyklicznym, w kt贸rym ka偶da transakcja dokonuje wielu zapis贸w. Transakcja mo偶e u偶ywa膰 nast臋pnego ekstentu, je偶eli brak w nim aktywnych zapis贸w.
Je艣li nast臋pny ekstent, jaki ma by膰 u偶yty posiada aktywne zapisy, do segmentu wycofania zostanie dodany nowy ekstent o ile nie osi膮gni臋to jeszcze maksymalnej liczby ekstent贸w.
Charakterystyka Segment贸w Wycofania
Pozwalaj膮 na wycofanie ca艂ej transakcji lub, w przypadku pomy艂ki operatora, do wskazanego punktu zachowania.
Umo偶liwiaj膮 sp贸jno艣膰 odczytu.
Wykorzystywane przy odtwarzaniu bazy danych.
Mog膮 zawiera膰 dane podlegaj膮ce zmianom pochodz膮ce z dowolnej przestrzeni tabel (z wyj膮tkiem segmentu wycofania SYSTEM).
Mog膮 zawiera膰 zmiany wielu transakcji.
W przestrzeni tabel SYSTEM zawsze istnieje segment wycofania o nazwie SYSTEM.
Je偶eli u偶ywamy wielu przestrzeni tabel, konieczny jest przynajmniej jeszcze jeden segment wycofania.
Zapisy w segmentach wycofania u偶ywane przy wycofaniu, sp贸jno艣ci odczytu i odtwarzaniu, dokonywane s膮 w spos贸b cykliczny.
W艂asno艣ci Segment贸w Wycofania
Sk艂adaj膮 si臋 z wielu zapis贸w wycofania wielu transakcji.
Przechowuj膮 informacj臋 o bloku tak膮 jak ID pliku i bloku oraz dane takie jakie by艂y przed modyfikacj膮.
Mog膮 rosn膮膰 z powodu wielkich lub d艂ugotrwa艂ych transakcji.
Mog膮 by膰 przypisane do transakcji automatycznie lub jawnie.
Mo偶na wymusi膰 ich zmniejszenie wykonuj膮c polecenie ALTER ROLLBACK SEGMENT <rbs> SHRINK TO <rozmiar>.
Je偶eli si臋 zwi臋ksz膮, zmniejszenie do OPTIMAL jest automatyczne.
Serwer Oracle wymaga istnienia w艂膮czonego (online) segmentu wycofania o nazwie SYSTEM podczas otwierania bazy danych.
Segment wycofania SYSTEM jest zak艂adany podczas tworzenia bazy danych.
Kiedy transakcja wymaga kontynuacji zapis贸w informacji wycofania w nast臋pnym ekstencie segmentu wycofania, serwer Oracle por贸wnuje bie偶膮cy rozmiar segmentu wycofania z rozmiarem optymalnym segmentu. Je艣li segment wycofania jest wi臋kszy ni偶 jego rozmiar optymalny a ekstent nast臋puj膮cy bezpo艣rednio za w艂a艣nie zape艂nionym jest nieaktywny, serwer Oracle zwalnia nieaktywne ekstenty segmentu wycofania dop贸ki ca艂kowity rozmiar segmentu wycofania nie jest r贸wny lub najbli偶szy nie mniejszy jego rozmiarowi optymalnemu.
Transakcja mo偶e za偶膮da膰 przydzielenia wskazanego segmentu wycofania poleceniem SET TRANSACTION USE ROLLBACK SEGMENT.
Dla segment贸w wycofania nie mo偶na ustawi膰 parametru PCTINCREASE.
W艂a艣ciwa warto艣膰 OPTIMAL mo偶e by膰 znaleziona przez monitorowanie V$ROLLSTAT, lub przez wykorzystanie monitora wycofa艅 z narz臋dzia Serwer Manager/GUI.
Okre艣lamy charakterystyki wykorzystania przestrzeni przez segmenty wycofania.
Parametry Wykorzystania Przestrzeni Segment贸w Wycofania
INITIAL
NEXT
MINEXTENTS
MAXEXTENTS
OPTIMAL
Optymalne Parametry
Parametr OPTIMAL okre艣la optymalny rozmiar (w bajtach) segmentu wycofania.
Serwer Oracle zwalnia ekstenty kiedy rozmiar segmentu wycofania jest wi臋kszy ni偶 OPTIMAL.
Parametr OPTIMAL nie mo偶e by膰 mniejszy ni偶 suma bajt贸w pierwszych MINEXTENTS ekstent贸w, najlepiej r贸wny tej sumie.
Dla segment贸w wycofania nie podaje si臋 parametru PCTINCREASE, jest on zawsze r贸wny zero.
Parametr MINEXTENTS musi by膰 przynajmniej r贸wny dwa, poniewa偶 ekstenty segmentu wycofania s膮 wykorzystywane w porz膮dku cyklicznym.
Dla segmentu wycofania parametr MAXEXTENTS nie powinien by膰 nigdy ustawiany na UNLIMITED, poniewa偶 mo偶e to spowodowa膰 utrat臋 nad nim kontroli i zarezerwowanie przez segment wycofania ca艂ej dost臋pnej przestrzeni dysku.
Istniej膮 trzy typy segment贸w wycofania.
Typ |
Funkcja |
Prywatny (private) |
Aby by艂 rozpoznany przez system musi by膰 uwzgl臋dniony w warto艣ci parametru ROLLBACK_SEGMENTS w pliku parametr贸w
|
Publiczny (public) |
Tworzy pul臋 segment贸w wycofania, kt贸re mog膮 by膰 przydzielone i wykorzystywane w ka偶dej instancji 偶膮daj膮cej dodatkowego segmentu wycofania. U偶yteczne tylko w 艣rodowisku Parallel Serwer, ale wtedy te偶 zwykle lepiej wykorzystywa膰 prywatne segmenty wycofania.
|
Op贸藕niony (deferred) |
Tworzony kiedy przestrze艅 tabel jest wy艂膮czona (offline) tak, 偶e transakcje nie mog膮 by膰 wycofane natychmiast. Tworzony zawsze w przestrzeni tabel SYSTEM. |
Zasady
Tylko segmenty wycofania publiczne i prywatne s膮 tworzone przez DBA.
Prawo do tworzenia segment贸w wycofania maj膮 u偶ytkownicy Oracle z uprawnieniami systemowymi CREATE ROLLBACK SEGMENT.
Przydzia艂 publicznych segment贸w wycofania odbywa si臋 na podstawie obliczenia TRANSACTIONS/ TRASACTIONS_PER_ROLLBACK_SEGMENT, kt贸re okre艣la liczb臋 segment贸w wycofania pobieranych z puli publicznej.
Publiczne segmenty wycofania s膮 czasem u偶ywane przez Oracle Parallel Serwer, ale nie s膮 wymagane przez konfiguracj臋. Zwykle preferowane s膮 prywatne segmenty wycofania.
Tworzenie Segmentu Wycofania
Mo偶emy stworzy膰 segment wycofania u偶ywaj膮c polecenie CREATE ROLLBACK SEGMENT.
Sk艂adnia:
gdzie:
segment_wycofania jest nazw膮 tworzonego segmentu wycofania.
PUBLIC okre艣la, 偶e segment wycofania nale偶y do puli publicznej.
przestrze艅_tabel specyfikuje nazw臋 przestrzeni tabel gdzie ma by膰 utworzony segment wycofania.
klauzula_przestrzeni okre艣la zasady przydzielania przestrzeni segmentowi wycofania.
OPTIMAL specyfikuje optymalny rozmiar w bajtach segmentu wycofania. Opcja OPTIMAL nale偶y do klauzuli przestrzeni.
Minimaln膮 warto艣ci膮 MINEXTENTS dla segment贸w wycofania jest 2. Mo偶na jeszcze zwi臋kszy膰 warto艣膰 MINEXTENTS przy tworzeniu segmentu wycofania np. kiedy przestrze艅 bazy danych jest pofragmentowana a chcemy zagwarantowa膰 wystarczaj膮c膮 ilo艣膰 przestrzeni do przechowania wszystkich danych tabeli. W segmentach wycofania PCTINCREASE jest zawsze zero i nie mo偶e by膰 podawany.
Przyk艂ad
Utworzenie segmentu o nazwie RBS01 w przestrzeni tabel RBS przez polecenie CREATE ROLLBACK SEGMENT. Weryfikacja poprawno艣ci utworzenia segmentu wycofania w s艂owniku danych.
SQL> CREATE ROLLBACK SEGMENT rbs01 2> TABLESPACE rbs 3> STORAGE (INITIAL 10K NEXT 10K 4> MINEXTENTS 20 MAXEXTENTS 121 5> OPTIMAL 200K); |
SQL> SELECT * FROM dba_rollback_segs; |
SEGMENT_NAME OWNER TABLESPACE_NAME SEGMENT_ID FILE_ID STATUS --------------------- ------ ------------------- ---------- ---------- ----------SYSTEM SYS SYSTEM 0 1 ONLINE
RBS01 PUBLIC RBS 2 3 OFFLINE
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Modyfikacja Segmentu Wycofania
Prze艂膮czamy segment wycofania w tryb offline aby usun膮膰 ten segment lub przestrze艅 tabel, kt贸ra go zawiera.
Prze艂膮czenie segmentu wycofania na online udost臋pnia segment transakcjom.
Wy艂膮czamy i w艂膮czamy segmenty wycofania poleceniem ALTER ROLLBACK SEGMENT.
Sk艂adnia:
gdzie:
segment_wycofania to nazwa zmienianego segmentu wycofania.
ONLINE prze艂膮cza segmenty wycofania na online.
OFFLINE prze艂膮cza segmenty wycofania na offline.
SHRINK usi艂uje zmniejszy膰 segment wycofania do podanego lub optymalnego rozmiaru.
Prze艂膮czenie segmentu wycofania na online:
Natychmiast udost臋pnia segment wycofania transakcjom.
Zmienia status na ONLINE.
Pozwala na u偶ycie segmentu wycofania.
Prze艂膮czenie segmentu wycofania na offline:
Je艣li zawiera aktywne transakcje, zapobiega u偶ywaniu segmentu przez przysz艂e transakcje.
Je艣li nie ma aktywnej transakcji, prze艂膮cza segment wycofania na offline.
Ustawia status na OFFLINE.
Pozwala na usuni臋cie segmentu wycofania o ile status faktycznie zmieni艂 si臋 na OFFLINE.
Ustawienia MAXEXTENTS na liczb臋 nieco mniejsz膮 ni偶 absolutne maksimum pozwala DBA na obs艂ug臋 sytuacji kiedy segment wycofania jest bliski osi膮gni臋cia maksymalnego rozmiaru.
Przyk艂ad
Udost臋pnienie segmentu wycofania RBS01, utworzonego w poprzednim przyk艂adzie i weryfikacja statusu ONLINE w s艂owniku danych.
SQL>聽SELECT segment_name, status 2> FROM dba_rollback_segs; |
SEGMENT_NAME STATUS
------------------------------ ----------------
SYSTEM ONLINE
RBS01 OFFLINE
RBS02 ONLINE
RBS03 ONLINE
SQL> ALTER ROLLBACK SEGMENT rbs01 ONLINE; |
SEGMENT_NAME STATUS
------------------------------ ----------------
SYSTEM ONLINE
RBS01 ONLINE
RBS02 ONLINE
RBS03 ONLINE
Zasady U偶ywania Segment贸w Wycofania
Dopasowujemy segment wycofania do poziomu aktywno艣ci i liczby transakcji zapisuj膮cych do segmentu wycofania przez ustawianie parametr贸w klauzuli przestrzeni (w tym parametru OPTIMAL) podczas tworzenia i strojenia segment贸w wycofania.
Rywalizacja o Segmenty Wycofania
Ka偶da transakcja jest przypisana do pewnego segmentu wycofania.
Istnieje tylko sko艅czona liczba miejsc na zapis transakcji w nag艂贸wku segmentu wycofania.
Transakcje dla kt贸rych zabrak艂o miejsca w nag艂贸wku zostan膮 zako艅czone.
Im wi臋cej jest u偶ytkownik贸w, tym wi臋cej potrzeba segment贸w wycofania.
Przyk艂ad
SELECT n. Name, round (100 * s. waits/ s.gets) ”%Count” FROM v$rollname n, v$rollstat s WHERE n.usn = s. usn; |
Je艣li uzyskana warto艣膰 jest wi臋ksza ni偶 1%, potrzeba wi臋kszej ilo艣ci segment贸w wycofania. Mo偶na rozwa偶y膰 te偶 wykorzystanie polecenia SET TRASACTION USE ROLLBACK SEGMENT.
W poleceniach ALTER ROLLBACK SEGMENT oraz CREATE ROLLBACK SEGMENT definiujemy optymalny rozmiar w bajtach dla ka偶dego segmentu wycofania.
Cechy Dynamicznego Przydzia艂u ekstent贸w
Segment wycofania mo偶e mie膰 zdefiniowany rozmiar optymalny. Rozmiar optymalny (w bajtach) definiujemy podczas tworzenia lub modyfikacji segmentu.
Segment wycofania jest automatycznie zmniejszany do rozmiaru optymalnego kiedy spada liczba aktywnych transakcji.
Zasady Okre艣lania Parametru OPTIMAL
Segmenty wycofania dla d艂ugotrwa艂ych transakcji powinny mie膰 du偶y rozmiar OPTIMAL, aby unikn膮膰 kosztownego przydzielania i zwalniania ekstent贸w.
Dla d艂ugotrwa艂ych zapyta艅 nale偶y zapewni膰, aby segmenty wycofania u偶ywane w transakcjach modyfikuj膮cych dane mia艂y odpowiednio du偶y rozmiar OPTIMAL. Inaczej otrzymamy b艂膮d „snapshot too old” (ORA-01555).
Segmenty wycofania u偶ywane w kr贸tkich transakcjach i zapytaniach powinny mie膰 niewielki rozmiar OPTIMAL dla poprawienia buforowania segmentu wycofania.
Usuwanie Segmentu Wycofania
Segmenty wycofania cz臋sto s膮 usuwane z powodu powodowanej przez nie fragmentacji dysku lub poniewa偶 s膮 przenoszone do innej przestrzeni tabel. Segment wycofania usuwany za pomoc膮 polecenia DROP ROLLBACK SEGMENT.
Sk艂adnia:
gdzie:
segment_wycofania jest nazw膮 usuwanego segmentu.
Usuwa膰 mo偶na tylko segmenty wycofania znajduj膮ce si臋 w stanie OFFLINE.
Podsumowanie
Segment wycofania to zbi贸r ekstent贸w zawieraj膮cych dane wycofania wykorzystywane przy wycofaniu transakcji, zapewnieniu sp贸jno艣ci odczytu i odtwarzaniu bazy danych.
U偶ycie wielu segment贸w wycofania.
Wyb贸r pomi臋dzy publicznymi i prywatnymi segmentami wycofania.
W艂a艣ciwe ustawienie rozmiaru segmentu wycofania.
Monitorowanie segmentu wycofania w narz臋dziu Serwera Manager.
Ustawienie optymalnej liczby ekstent贸w dla ka偶dego segmentu wycofania.
Zadania
Utw贸rz tabel臋 TEST w przestrzeni tabel USER_DATA (skrypt s:\create_test.sql)
Dodaj wiersz do tabeli TEST poleceniem INSERT INTO TEST VALUES ('TEST'). Co si臋 sta艂o?
Utw贸rz przestrze艅 tabel RBS na pliku e:\kurs\database\db#\rbsadm#.ora o rozmiarze 1MB, ekstencie inicjalnym 20K, ekstencie nast臋pnym 20K, minimaln膮 ilo艣ci膮 ekstent贸w r贸wn膮 2, pctincrease 0
Utw贸rz publiczny segment wycofania RBS01 w przestrzeni tabel RBS
Obejrzyj perspektyw臋 DBA_ROLLBACK_SEGS, jaki status na utworzony segment wycofania?
Prze艂膮cz segment wycofania RBS01 w tryb online
Spr贸buj ponownie doda膰 wiersz do tabeli TEST
Sprawd藕 perspektyw臋 v$rollstat
Z drugiej sesji spr贸buj prze艂膮czy膰 segment RBS01 w stan offline. Sprawd藕 w perspektywie DBA_ROLLBACK_SEGS i v$rollstat, jaki teraz jest stan tego segmentu wycofania. Spr贸buj usun膮膰 segment RBS01.
Zatwierd藕 transakcj臋 i spr贸buj ponownie usun膮膰 segment RBS01. Czy teraz si臋 uda艂o?
Utw贸rz publiczny segment wycofania RBS02 z maksymaln膮 liczb膮 ekstent贸w r贸wn膮 3.
Prze艂膮cz segment RBS02 w tryb online.
Dodaj do tabeli TEST 10 wierszy, gdzie name ma d艂ugo艣膰 30 znak贸w: INSERT INTO TEST VALUES ('XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX');
W przestrzeni tabel USER_DATA utw贸rz tabel臋 TT jako kopi臋 tabeli TEST poleceniem CREATE TABLE TT AS SELECT * FROM TEST;
Powtarzaj polecenie "INSERT INTO TT SELECT * FROM TT" a偶 do uzyskania b艂臋du. Jaki to b艂膮d ?
Zatwierd藕 transakcje i sprawd藕 ile jest wierszy w tabeli TT poleceniem SELECT COUNT(*) FROM TT. Dlaczego?
Spr贸buj usun膮膰 wszystkie wiersze z tabeli TT poleceniem DELETE FROM TT. Co si臋 sta艂o?
Zmie艅 w segmencie RBS02 maksymaln膮 liczb臋 ekstent贸w na 100 i ponownie spr贸buj usun膮膰 wiersze z tabeli TT Spr贸buj zatwierdzi膰 transakcj臋
Spr贸buj zmieni膰 w segmencie RBS02 maxextents na 2 . Co si臋 sta艂o?
Zmie艅 w segmencie RBS02 maksymalna ilo艣膰 ekstent贸w na 300.
Usu艅 tabel臋 TT
Obetnij tabel臋 TEST poleceniem TRUNCATE TABLE TEST
W sesji nr 1 wstaw wiersz do tabeli TEST,
W sesji nr 2 prze艂膮cz przestrze艅 tabel USER_DATA w tryb offline.
W sesji nr 2 obejrzyj perspektyw臋 DBA_SEGMENTS i znajd藕 op贸藕niony segment wycofania
W sesji nr 2 w艂膮cz przestrze艅 tabel USER_DATA
W sesji nr 1 zatwierd藕 transakcj臋
W sesji nr 2 zobacz ile wierszy na tabela TEST
Usu艅 tabel臋 TEST
IX.聽Obs艂uga segment贸w tabel i indeks贸w
Cele
Lekcja ta wyja艣nia, w jaki spos贸b obs艂ugiwa膰 w Oracle segmenty tabel i indeks贸w, r贸wnie偶 jak dobiera膰 ich rozmiary.
Na ko艅cu tej sekcji powiniene艣 potrafi膰
Tworzy膰 tabele i indeksy odpowiednich rozmiar贸w.
Rozumie膰 kompromisy zwi膮zane z zaj臋to艣ci膮 miejsca i wydajno艣ci膮.
Przegl膮da膰 wykorzystanie przestrzeni w bazie.
Przegl膮d
Segmenty zawieraj膮 ca艂o艣膰 danych dla specyficznej struktury wewn膮trz przestrzeni tabel. Segment sk艂ada si臋 z jednego lub wielu obszar贸w (extent)
W艂asno艣ci segmentu
Typ segmentu
|
Opis |
Data |
Zawiera dane |
Index |
Dostarcza efektywnej struktury do lokalizacji w tabeli specyficznych wierszy. |
Tabele
Segment danych dla tabeli zawiera wiersze tablicy. Dane tabel przechowywane s膮 w segmentach danych.
W艂asno艣ci tabel
Przechowuj膮 dane u偶ytkownika.
Przechowuj膮 dane systemowe (s艂ownik danych).
Tworzone poleceniem CREATE TABLE.
Blok nag艂贸wka zawiera list臋 wolnych blok贸w (free list) i informacje o ekstentach.
Mog膮 by膰 utworzone na podstawie innych tabel oraz do przetwarzania r贸wnoleg艂ego (CREATE TABLE AS SELECT).
Mog膮 by膰 tworzone w trybie UNRECOVERABLE (CREATE TABLE AS SELECT)
Przyk艂ad: Polecenie CREATE TABLE
Utworzenie tabeli ORDERS i podanie parametr贸w przechowywania danych (storage parameters) w tabeli.
SQL> CREATE TABLE orders ( 2> orderid NUMBER (3) NOT NULL, 3> orderdate DATE, 4> shipdate DATE, 5> client VARCHAR2 (3) NOT NULL, 6> amount_due NUMBER (10,2), 7> amount_paid NUMBER (10,2)) 8> PCTFREE 5 PCTUSED 65 9> STORAGE ( 10> INITIAL 5M 11> NEXT 5M 12> PCTINCREASE 0 13> MINEXTENTS 2 14> MAXEXTENTS 50) 15> TABLESPACE users; |
Uwaga: Parametry steruj膮ce z wykorzystaniem przestrzeni nie s膮 cz臋艣ci膮 klauzuli przestrzeni.
Dane z tabel przechowywane s膮 jako wiersze. Wiersz jest kombinacj膮 warto艣ci, kt贸r膮 czytamy zwykle poziomo i kt贸ra zawiera unikatow膮 kombinacj臋 informacji opisuj膮c膮 relacje pomi臋dzy kawa艂kami podobnych danych.
W艂asno艣ci wierszy
Nie ma limitu wierszy dla tabeli.
Wiersz nie b臋d膮cy w klastrze, zawarty w ca艂o艣ci w jednym bloku, posiada co najmniej 3- bajtowy nag艂贸wek.
Wiersze mog膮 rozci膮ga膰 si臋 na wiele blok贸w, oznacza to tworzenie 艂a艅cucha (chained rows).
Wiersze przechowywane s膮 w spos贸b ci膮g艂y w formacie zmiennej lub sta艂ej (dla kolumn typu CHAR i DATE) d艂ugo艣ci.
Warto艣ci kolumn przechowywane s膮 obok siebie.
Rozmiar kolumny wskazuje na liczb臋 bajt贸w potrzebnych do przechowywania warto艣ci kolumny. Potrzeba 1 bajtu (nag艂贸wka) przy przechowywaniu do 250 bajt贸w lub te偶 3 bajt贸w dla kolumn d艂u偶szych ni偶 250.
D艂ugo艣膰 kolumny r贸wna 0 oznacza null.
Uwaga: Ka偶dy wiersz u偶ywa dw贸ch bajt贸w w katalogu wierszy w nag艂贸wku bloku danych.
Alokowanie przestrzeni dla tabeli
Dobrze utworzone tabele utworz膮 wydajniejsz膮 baz臋 danych.
Parametry klauzuli przestrzeni
Je艣li to mo偶liwe, nale偶y przechowywa膰 tabel臋 w jednym obszarze (extent).
Je艣li tabela bardzo ro艣nie nale偶y ustawi膰 du偶膮 warto艣膰 PCTINCREASE.
Je艣li nie jest dost臋pna jedna du偶a wolna przestrze艅 na dane, mo偶na utworzy膰 wiele ma艂ych ekstent贸w za pomoc膮 odpowiedniego ustawienia MINEXTENTS.
Parametry wykorzystywania przestrzeni (Space Utilization Parameters)
Je艣li wiersze nie b臋d膮 mocno modyfikowane, ustawiamy niskie PCTFREE.
Je艣li dla tabeli b臋dzie du偶o operacji wstawienia i usuwania, ustawiamy niskie PCTUSED.
PCTFREE plus PCTUSED nie mog膮 przekroczy膰 100 %.
Tworzenie tabel
Sk艂adnia:
gdzie:
schemat oznacza w艂a艣cicieli tabel
tabela jest nazw膮 tabeli
kolumna jest nazw膮 kolumny
typ_kulumny jest typem danych w kolumnie
PCTFREE jest ilo艣ci膮 miejsca zarezerwowan膮 w blokach (jako procent ca艂ego dost臋pnego - nie licz膮c nag艂贸wka bloku - miejsca w bloku) dla wierszy, kt贸re powi臋ksz膮 si臋.
PCTUSED okre艣la limit wykorzystanego miejsca dla bloku (po jak zape艂ni si臋 do PCTFREE) zanim stanie si臋 on dost臋pny dla wstawienia wierszy.
INITRANS okre艣la liczb臋 pozycji przygotowanych dla transakcji nag艂贸wku bloku. Domy艣lnie 255.
MAXTRANS limit pozycji transakcji, jakie mog膮 by膰 zaalokowane dla ka偶dego bloku. Domy艣lnie 255.
TABLESPACE okre艣la przestrze艅 tabel, w kt贸rej ma by膰 tabela
STORAGE okre艣la klauzul臋 przestrzeni, kt贸ra determinuje w jaki spos贸b tablicy b臋d膮 przydzielane ekstenty.
RECOVERABLE okre艣la, 偶e utworzenie tabeli ma zosta膰 odnotowane w dzienniku powt贸rze艅. Domy艣lnie.
UNRECOVERABLE okre艣la, 偶e utworzenie tabeli nie mo偶e by膰 odnotowane w dzienniku powt贸rze艅.
CLUSTER okre艣la, 偶e tabela jest cz臋艣ci膮 klastra.
PARALLEL okre艣la charakterystyk臋 dost臋pu r贸wnoleg艂ego do tabeli. Patrz opisy DEGREE i INSTANCES.
DEGREE Liczba ca艂kowita specyfikuj膮ca domy艣lny stopie艅 paralelizmu dla tabeli; domy艣lnie jest to obliczane przy uwzgl臋dnieniu przypuszczalnego rozmiaru tabeli i warto艣ci parametru inicjalizuj膮cego.
ENABLE w艂膮cza warunek integralno艣ci.
DISABLE wy艂膮cza warunek integralno艣ci.
AS podzapytanie wstawia do tabeli wiersze b臋d膮ce wynikiem podzapytania.
CACHE okre艣la, i偶 bloki tej tabeli s膮 po wczytaniu podczas wykonywania pe艂nego przej艣cia przez tabel臋 (full table scan)umieszczane jako te ostatnio u偶yte w li艣cie LRU obs艂uguj膮cej bufory danych.
NOCACHE okre艣la, i偶 bloki wczytane przy przegl膮daniu ca艂ej tabeli (full table scan) nie s膮 umieszczane jako ostatnio u偶yte na li艣cie LRU obs艂uguj膮cej bufory danych.
Sk艂adnia klauzula_przestrzeni:
gdzie:
INITIAL jest rozmiarem pierwszego ekstentu w bajtach.
NEXT jest rozmiarem nast臋pnego ekstentu w bajtach.
MINEXTENTS jest liczb膮 ekstent贸w tworzonych od razu.
MAXEXTENTS jest liczb膮 mo偶liwych do zaalokowania ekstent贸w
PCTINCREASE jest wsp贸艂czynnikiem o jaki powi臋kszany jest ka偶dy nast臋pnie przydzielany ekstent.
FREELISTS jest liczb膮 list wolnych blok贸w.
FREELIST GROUPS jest liczb膮 grup list wolnych blok贸w dla instancji Serwera R贸wnoleg艂ego.
Modyfikacja tabel
Do modyfikacji definicja tabeli u偶ywa si臋 polecenia ALTER TABLE.
Sk艂adnia:
gdzie:
ALLOCATE EXTENT r臋cznie dodaje nowy ekstent.
SIZE jest rozmiarem nowego ekstentu w bajtach.
DATAFILE jest nazw膮 pliku danych w przestrzeni tabel.
INSTANCE jest nr instancji w 艣rodowisku bazy danych MPP.
DEALLOCATE UNUSED jawnie zwalnia niewykorzystan膮 przestrze艅 na ko艅cu tabeli i udost臋pnia j膮 dla innych segment贸w.
KEEP okre艣la liczb臋 bajt贸w powy偶ej znacznika wysokiej wody (high water mark), jaka ma pozosta膰 w tabeli po dealokacji.
ENABLE enable_clause w艂膮cza sprawdzanie pojedynczego constrainta lub wszystkich wyzwalaczy powi膮zanych z tabel膮.
ENABLE TABLE LOCK pozwala na blokady DML i DDL na tabeli w 艣rodowisku serwera r贸wnoleg艂ego.
DISABLE disable-clause wy艂膮cza sprawdzanie pojedynczego constrainta lub wszystkich wyzwalaczy powi膮zanych z tabel膮.
DISABLE TABLE LOCK uniemo偶liwia blokady DML i DDL na tabeli w 艣rodowisku Serwera R贸wnoleg艂ego.
Polecenia ALTER TABLE mo偶na u偶y膰 do kontroli alokacji przestrzeni dla przysz艂ych blok贸w.
Przyk艂ady
SQL> ALTER TABLE reserwe 2> STORAGE(MAXEXTENTS 121 3> PCTINCREASE100); Table created |
SQL> ALTER TABLE too_small 2> ALLOCATE EXTENT 3> (SIZE 200K 4> DATAFILE `/u02/Oracle/test/user1 . dbs'); Table altered |
Istniej膮ce bloki i obszary nie s膮 przez polecenie ALTER zmienione.
Rozmiar obszaru NEXT - jaki ma by膰 przydzielony w nast臋puj膮cej kolejno艣ci, obliczany na podstawie rozmiaru ostatniego zaalokowania obszaru i PCTINCREASE, nie zmienia si臋, gdy ekstent zostanie dodany r臋cznie za pomoc膮 opcji ALLOCATE EXTENT.
Usuwanie tabel
Tabel臋 i jej zawarto艣膰 usuwa si臋 poleceniem DROP TABLE.
Sk艂adnia
gdzie:
schemat jest schematem zawieraj膮cym tabel臋. Je艣li pominie si臋 schemat Serwer Oracle zak艂ada, i偶 chodzi o schemat wydaj膮cego polecenie.
tabela jest nazw膮 tabeli, kt贸ra ma by膰 usuni臋ta.
CASCADE CONSTRAITS usuwa wszystkie wi臋zy integralno艣ci, jakie odnosz膮 si臋 kluczy Primery i unique w usuwanej tabeli. Je艣li pominie si臋 t膮 opcj臋, a istnieje taki klucz obcy, Serwer Oracle zwr贸ci b艂膮d i nie usunie tabeli.
Segmenty Indeks贸w
Je艣li na tabeli zostanie utworzony indeks, je艣li dla niego tworzony segment indeksowy (index segment). Segment taki jest fizycznie oddzielony od segment贸w danych tabeli czy klastra.
Charakterystyka drzewa B*Tree
Wywa偶one drzewa pozwalaj膮 na szybk膮 lokalizacj臋 warto艣ci kluczy.
Adres ROWID (hexadecymalny) daje bezpo艣redni dost臋p do wiersza w tabeli.
Zapytania odnosz膮ce si臋 tylko do poindeksowanych kolumn mog膮 zosta膰 rozwi膮zane wewn膮trz indeksu (bez odwo艂ywania si臋 do tabeli).
Przeszukiwanie indeksu (index search) jest alternatyw膮 dla przejrzenia ca艂ej tabeli (full table scan); mog膮 one oszcz臋dzi膰 operacji We/Wy na dysku.
Automatycznie wykorzystywane i utrzymywane przez Serwer Oracle Server.
W艂asno艣ci segmentu indeksu
Niezale偶ny od tabeli czy klastra
Ka偶dy indeks mo偶e mie膰 swoje w艂asne parametry i przestrze艅 tabel.
Indeksy s膮 zwykle mniejsze ni偶 poindeksowane tabele.
Mog膮 by膰 tworzone r贸wnolegle.
Mog膮 by膰 tworzone z opcj膮 UNRECOVERABLE.
Powinny by膰 dla optymalizacji przechowywane w osobnej przestrzeni tabel.
Mog膮 by膰 albo typu unique albo non-unique.
Mog膮 by膰 albo proste (jedna kolumna), albo z艂o偶one (znane r贸wnie偶 jako skonkatenowane).
Przyk艂ad
Utworzenie indeksu na tabeli EMP.
SQL> CREATE INDEX emp_ename /*Index name*/ 2> ON emp(ename) /*Table and column name*/ 3> STORAGE (INITIAL 500K NEXT 500K PCTINCREASE 0) 4> TABLESPACE user_data; Index created |
Indeksy bitmapowe
Indeksy bitmapowe s膮 atrakcyjn膮 alternatyw膮 dla normalnych indeks贸w typu B*-Tree w sytuacji, gdy:
Tabele s膮 bardzo du偶e (miliony wierszy).
Tabele maj膮 nisk膮 kardynalno艣膰 - tj. kolumn臋, w kt贸rej liczba r贸偶nych warto艣ci jest ma艂a (np. p艂e膰, wiek, stan cywilny, kod pocztowy).
Zapytania maj膮 indeksy bitmapowe na wszystkich kolumnach zwykle u偶ywanych w klauzulach WHERE.
Zapytania maj膮 klauzule WHERE z warunkami spe艂nianymi przez tysi膮ce wierszy.
Koncepcja indeks贸w bitmapowych
Mapa bitowa dla ka偶dej warto艣ci
Kolumna = REGION
|
||
`cast' |
`central' |
`west' |
1 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
1 |
0 |
0 |
1 |
0 |
1 |
0 |
0 |
1 |
0 |
Efektywna kombinacja bitmap贸w korzystaj膮ca z operacji logicznych (AND,OR itd.).
Znaczna redukcja zu偶ycia miejsca w por贸wnaniu z innymi technikami indeksowania.
Dramatyczne zyski wydajno艣ci dla niekt贸rych zapyta艅.
Kiedy korzysta膰 z indeks贸w bitmapowych
Indeksy bitmapowe powinny znale藕膰 zastosowanie w nast臋puj膮cych sytuacjach:
W zapytaniach zawieraj膮cych:
Kolumny z nisk膮 kardynalno艣ci膮
Kombinacj臋 wielu warunk贸w WHERE
Ka偶dy produkt daje du偶膮 liczb臋 wierszy
Jest to alternatywa dla indeks贸w skonkatenowanych daj膮ca
Lepsze wykorzystanie przestrzeni
Bez zale偶no艣ci od kolejno艣ci kolumn
Je艣li dzia艂ania polegaj膮 g艂贸wnie na odczycie danych, a ma艂o jest modyfikacji
Indeksy bitmapowe s膮 bardzo kosztowne przy modyfikacjach
Indeksy bitmapowe nie s膮 dost臋pne przed wersj膮 7.3.3.
Indeksy typu unique
Indeks贸w typu unique mo偶na u偶y膰 by zapewni膰, i偶 w tabeli nie b臋dzie dw贸ch wierszy z tymi samymi warto艣ciami w kolumnach, na kt贸rych zbudowany jest indeks.
Nie ma duplikat贸w warto艣ci
Unikatowo艣膰 kolumny nale偶y zapewni raczej za pomoc膮 constrainta UNIQUE, a nie indeksu typu unique. Taka niepowtarzalno艣膰 jest koncepcj膮 stricte logiczn膮 i powinna by膰 uj臋ta przy definicji tabeli.
Indeksy typu unique s膮 tworzone automatycznie dla ka偶dego klucza g艂贸wnego i klucza unique.
Indeksy typu Non-Unique
Indeksy typu Non-unique pozwalaj膮 na powtarzanie warto艣ci w indeksowanej kolumnie.
Indeksy skonkatenowane
Indeksy z艂o偶one lub skonkatenowane tworzone s膮 na wielu kolumnach tabeli.
Charakterystyka
Kolumny w indeksach z艂o偶onych nie musz膮 by膰 w tej samej kolejno艣ci co kolumny w tabeli, nie musz膮 to by膰 te偶 kolumny s膮siednie.
Maksymaln膮 liczb膮 kolumn tworz膮c膮 klucz indeksu z艂o偶onego jest 16. Jednak prawdziwe maksimum zale偶y od rozmiaru bloku danych. Ca艂kowity rozmiar klucza indeksu w bajtach nie mo偶e przekroczy膰 po艂owy zdefiniowanego bloku danych.
Tworzenie indeks贸w
Indeksy tworzy si臋 poleceniem CREATE INDEX.
gdzie:
UNIQUE okre艣la, czy warto艣膰 w indeksowanej kolumnie ma by膰 unikatowa.
BITMAP okre艣la, 偶e ma zosta膰 utworzony indeks bitmapowy.
schemat jest schematem, kt贸re ma zawiera膰 indeks lub tabel臋.
indeks jest nazw膮 tworzonego indeksu.
tabela jest nazwa tabeli, na kt贸rej zbudowany ma by膰 indeks.
kolumna jest nazw膮 kolumny w tabeli. Maksymalnie mo偶na poda膰 16 kolumn.
ASC/DESC s膮 obs艂ugiwane ze wzgl臋du na kompatybilno艣膰 ze sk艂adni膮 DB2, jednak indeksy tworzone s膮 zawsze z porz膮dkiem rosn膮cym.
CLUSTER okre艣la klaster, dla kt贸rego ma zosta膰 zbudowany indeks.
INITRANS okre艣la liczb臋 pozycji dla transakcji przygotowanych w nag艂贸wkach blok贸w danych segmentu. Domy艣lnie 2.Ka偶da pozycja dla transakcji zajmuje 23 bajty.
MAXTRANS ogranicza liczb臋 transakcji, kt贸re mog膮 mie膰 r贸wnoczesny dost臋p do bloku. Domy艣lnie 255.
TABLESPACE okre艣la przestrze艅 tabel, w kt贸rej ma zosta膰 umieszczony indeks.
STORAGE patrz sk艂adnia klauzuli przestrzeni.
PCTFREE jest ilo艣ci膮 miejsca (w procentach) rezerwowanego na dodatkowe pozycje indeksu.
NOSORT m贸wi Serwerowi Oracle, 偶e wiersze tabeli zosta艂y posortowane w porz膮dku rosn膮cym.
RECOVERABLE okre艣la, i偶 utworzenie indeksu zostanie odnotowane w dzienniku powt贸rze艅. Domy艣lnie tak si臋 w艂a艣nie dzieje.
UNRECOVERABLE okre艣la, i偶 utworzenie indeksu nie ma by膰 odnotowane w dzienniku powt贸rze艅.
PARALLEL okre艣la, 偶e indeks ma by膰 tworzony r贸wnolegle.
Sk艂adnia klauzuli przestrzeni:
gdzie:
INITIAL okre艣la rozmiar pierwszego ekstentu segmentu.
NEXT okre艣la rozmiar drugiego ekstentu segmentu.
MINEXTENTS okre艣la liczb臋 ekstent贸w, jakie maj膮 zosta膰 zaalokowane w czasie tworzenia indeksu.
MAXEXTENTS okre艣la maksymaln膮 liczb臋 ekstent贸w.
PCTINCREASE okre艣la w procentach o ile kolejny ekstent ma by膰 wi臋kszy od poprzedniego.
FREELISTS okre艣la liczb臋 list wolnych blok贸w dla ka偶dej grupy takich list. Domy艣lnie 1.
FREELIST GROUPS okre艣la liczb臋 list wolnych blok贸w dla indeksu. Domy艣lnie 1.
Przyk艂ady
Poni偶sze przyk艂ady u偶ywaj膮 domy艣lnej przestrzeni tabel tw贸rcy indeks贸w. Korzystaj膮 one r贸wnie偶 z domy艣lnych parametr贸w klauzuli przestrzeni dla tej przestrzeni tabel - zak艂adaj膮c, 偶e tabela nie ma wierszy.
SQL> CREATE INDEX ind_emp_empno ON EMP (EMPNO) |
Ni偶ej parametry klauzuli przestrzeni podane s膮 jawnie.
SQL> CREATE INDEX ind_emp_empno ON EMP(EMPNO) 2> TABLESPACE user 3> STORAGE (INITIAL 500K NEXT 500K PCTINCREASE 75); |
Indeks skonkatenowany oparty na dw贸ch kolumnach tabeli PARTS. Jest on przechowywany w osobnej przestrzeni tabel przeznaczonej na wszystkie indeksy w bazie.
SQL> CREATE INDEX ind_parts ON PARTS (set_no, part_no) 2> TABLESPACE tbs_ind 3> STORAGE (INITIAL 1M NEXT 1M PCTINCREASE 0) PCTFREE 0; |
Wskaz贸wki:
Najpierw nale偶y utworzy膰 tabel臋 a nast臋pnie j膮 indeksowa膰.
Je艣li kolumna zawiera warto艣ci posortowane w porz膮dku rosn膮cym, nale偶y poda膰 opcj臋 NOSORT. W ten spos贸b pomini臋ta zostanie przy tworzeniu indeksu faza sortowania.
Przy sortowaniu warto艣ci indeksu Serwer Oracle korzysta z segment贸w tymczasowych i przestrzeni do sortowania okre艣lonej parametrem inicjalizacyjnym SORT_AREA_SIZE.
Indeksy mog膮 by膰 tworzone jako UNRECOVERABLE, tak i偶 nie jest generowana informacja dla segment贸w wycofania i dziennika powt贸rze艅. Do momentu zrobienia kopii zapasowej, nie b臋dzie mo偶liwe odtworzenie takich indeks贸w.
Obs艂uga indeks贸w
Gdy poprawiana jest poindeksowana tabela, poprawiony lub utrzymany musi zosta膰 r贸wnie偶 indeks.
Kompromis wydajno艣ci
Przy korzystaniu z indeks贸w wywa偶amy wydajno艣膰 pomi臋dzy
Pr臋dko艣ci膮 pobierania danych z tabeli.
Pr臋dko艣ci膮 modyfikowania tabeli.
Kiedy do tabeli wstawia si臋 wiersz lub gdy wiersze s膮 z niej usuwane, powi膮zane z ni膮 indeksy r贸wnie偶 musz膮 zosta膰 poprawione. Im wi臋cej indeks贸w zbudowanych na tabeli, tym wi臋kszy b臋dzie narzut. Dlatego, je艣li tabela u偶ywana jest g艂贸wnie do odczytu, istnienie wielu indeks贸w mo偶e pom贸c. Jednak je艣li tabela jest cz臋sto modyfikowana, lepiej mie膰 na niej mniej indeks贸w.
Indeksy pomagaj膮, gdy modyfikuje si臋 stosunkowo niewiele wierszy. Je艣li wykonywane jest wiele wstawie艅 i usuni臋膰, lepiej mie膰 mniej indeks贸w.
Indeksy s膮 tworzone w domy艣lnej przestrzeni tabel, lecz przy ich budowaniu mo偶na poda膰 inn膮 przestrze艅. Umieszczenie indeks贸w i tabel, na kt贸rych s膮 one budowane w r贸偶nych przestrzeniach tabel - najlepiej na r贸偶nych urz膮dzeniach - poprawia wydajno艣膰, poniewa偶 umo偶liwia r贸wnoleg艂y dost臋p do nich.
Kiedy indeks zostanie utworzony, segment zawieraj膮cy go jest tworzony automatycznie w podanej lub domy艣lnej przestrzeni tabel.
Parametry klauzuli przestrzeni dla indeks贸w
INITIAL
NEXT
MAXEXTENTS
MINEXTENTS
PCTINCREASE
Lepiej jest przechowywa膰 indeksy w mniejszej liczbie wi臋kszych obszar贸w, ni偶 w wielu ma艂ych ekstentach, poniewa偶 wtedy informacje w indeksie s膮 z wi臋kszym prawdopodobie艅stwem roz艂o偶one r贸wnomiernie i w spos贸b ci膮g艂y.
Je艣li tabela istnieje w czasie tworzenia indeksu, wszystkie bloki indeksu zostaj膮 zape艂niane do warto艣ci PCTFREE. Gdy do tabeli zostanie dodany nowy wiersz, odpowiadaj膮cy mu zapis w indeksie musi zosta膰 umieszczony w odpowiednim bloku (indeksu).
Warto艣膰 PCTFREE
Powinno by膰 du偶e, je艣li do poindeksowanej tabeli b臋dzie wstawianych wiele wierszy.
Powinno by膰 ma艂e, je艣li do poindeksowanej tabeli nie b臋dzie wstawianych zbyt wiele wierszy.
Je艣li PCTFREE zostanie ustawione ze zbyt ma艂ym zapasem i nowego zapisu zabraknie miejsca w blokach indeksu, blok indeksu zostaje rozbity na wiele blok贸w
Je艣li PCTFREE jest zbyt du偶e, w blokach indeksu b臋dzie du偶o zmarnowanego miejsca.
Warto艣膰 INITRANS i MAXTRANS
Warto艣膰 dla INITRANS i MAXTRANS zale偶膮 od rozmiaru zapis贸w w indeksie i liczby r贸wnoczesnych transakcji, jakie b臋d膮 korzysta艂y z indeksu.
Niskie warto艣ci INITRANS i MAXTRANS
Warto艣ci dla INITRANS i MAXTRANS mog膮 by膰 niskie je艣li
Zapisy w indeksie s膮 du偶ego rozmiaru.
Ma艂o u偶ytkownik贸w b臋dzie r贸wnocze艣nie korzysta艂o z poindeksowanej tabeli, a wi臋c i z indeksu.
Je艣li wielu u偶ytkownik贸w wyda polecenie, kt贸re korzysta z indeksu, wi臋ksza warto艣膰 INITRANS zapewni, 偶e b臋dzie dosy膰 miejsca na przeprowadzenie transakcji i wyeliminuje narzut potrzeby na tworzenie nowych pozycji dla transakcji. Wi臋ksze MAXTRANS zapewni, i偶 u偶ytkownicy nie b臋d膮 musieli oczekiwa膰 na zwolnienie si臋 miejsca potrzebnego transakcji.
Je艣li parametry klauzuli przestrzeni nie zostan膮 podane jawnie, przyjmowane s膮 domy艣lne warto艣ci dla docelowej przestrzeni tabel.
Monitorowanie Indeks贸w
Je艣li warto艣ci kluczy s膮 cz臋sto modyfikowane, dobrze jest kontrolowa膰 wykorzystanie przestrzeni indeksu.
Monitorowanie 艣redniej efektywno艣ci wykorzystania przestrzeni indeksu mo偶na osi膮gn膮膰 powtarzaj膮c nast臋puj膮ce kroki:
Procedura monitorowania indeks贸w
Przeanalizuj indeks.
Zanotuj procent zaj臋tej przestrzeni.
Wykonuj kroki 1 i 2 regularnie, por贸wnaj wyniki. Je艣li wykorzystanie przestrzeni w indeksie spadnie poni偶ej 艣redniej, powiniene艣 skondensowa膰 przestrze艅 indeksu poprzez usuni臋cie i ponowne utworzenie.
W celu przeanalizowania indeksu, skorzystaj z polecenia ANALYZE i bezpo艣rednio sprawd藕 zawarto艣膰 perspektyw s艂ownika danych dotycz膮cych indeks贸w.
Wszystkie obszary pozostaj膮 zarezerwowane, a偶 do usuni臋cia indeksu.
Indeks mo偶e zosta膰 usuni臋ty jawnie b膮d藕 niejawnie poprzez usuni臋cie tabeli.
Obci臋cie tabeli obcina r贸wnie偶 jej indeksy.
Po pierwsze, korzystamy z polecenia ANALYZE.
Sk艂adnia:
gdzie:
indeks identyfikuje indeks do przeanalizowania. Je艣li pominie si臋 schemat Serwer Oracle zak艂ada, i偶 indeks jest w schemacie aktualnego u偶ytkownika.
VALIDATE STRUCTURE sprawdza struktur臋 indeksu, generuje statystyki do perspektywy INDEX_STATS.
Przyk艂ad
SQL> ANALYZE INDEX tab_index VALIDATE STRUCTURE; Index analyzed. |
Zauwa偶amy procent zu偶ytej przestrzeni. W tym celu wykonujemy zapytania na perspektywach s艂ownika danych.
Przyklad
Po przeanalizowaniu indeksu TAB_INDEX, dane dotycz膮ce jego wykorzystania przestrzeni pojawiaj膮 si臋 w perspektywie INDEX_STATS.
SQL> SELECT btree_space, used_space, pct_used 2> FROM index_stats 3> WHERE name = `TAB_INDEX'; |
BTREE_SPACE USED_SPACE PCT_USED
-------------------- ---------------------- --------------
1891 196 11
Wskaz贸wki:
BTREE_SPACE jest to przestrze艅 zarezerwowana dla indeksu. USED_SPACE jest to przestrze艅 wykorzystana.
PCT_USED nie jest tym samym co parametr PCTUSED u偶yty przy tworzeniu tabeli - jest to obliczana statystyka. Parametr ten jest nielegalny przy tworzeniu indeksu. PCT_USED jest procentem przydzielonej przestrzeni, kt贸ra jest u偶ywana.
Statystyki dost臋pne s膮 r贸wnie偶 poprzez perspektywy USER_INDEXES i聽USER_IND_COLUMNS.
Modyfikacja indeks贸w
Parametry klauzuli przestrzeni dla indeksu oraz jego parametry dla transakcji mo偶na zmieni膰 poleceniem ALTER INDEX.
Sk艂adnia:
gdzie:
schemat jest nazw膮 schematu, do kt贸rego nale偶y indeks. Domy艣lnie - schemat aktualnego u偶ytkownika.
PCFREE zmienia warto艣膰 PCTFREE.
INITRANS/MAXTRANS ustawia nowe warto艣ci tych parametr贸w
STORAGE ustawia nowe warto艣ci parametr贸w klauzuli przestrzeni.
ALLOCATE EXTENT jawnie alokuje nast臋pny ekstent dla indeksu.
SIZE okre艣la rozmiar ekstentu w bajtach.
DATAFILE okre艣la jeden z plik贸w danych przestrzeni tabel indeksu jako ten, gdzie ma zosta膰 umieszczony nowy ekstent.
INSTANCE czyni nowy ekstent dost臋pnym dla podanej instancji. Parametr ten wykorzystuje si臋 jedynie w Serwer Oracle dzia艂aj膮cych w trybie r贸wnoleg艂ym z opcj膮 Serwera R贸wnoleg艂ego.
Za pomoc膮 polecenia ALTER INDEX, mo偶na zwolni膰 niewykorzystan膮 przestrze艅 (DEALLOCATE UNUSED) lub szybko przebudowa膰 indeks (REBUILD).
Sk艂adnia cd.:
gdzie:
DEALLOCATE UNUSED wymusza zwolnienie nie wykorzystanej przestrzeni i pozwala na jej wykorzystanie w innych segmentach.
KEEP okre艣la liczb臋 bajt贸w powy偶ej znacznika wysokiej wody (high water mark), jakie maja pozosta膰 w indeksie po dealokacji.
REBUILD tworzy nowy indeks korzystaj膮c ze starego.
PARALLEL do zbudowania nowego indeksu ma zosta膰 u偶yte numer r贸wnoleg艂ych proces贸w.
NOPARALLEL do tworzenia nowego indeksu nie maj膮 by膰 wykorzystane procesy r贸wnoleg艂e. Jest to zachowanie domy艣lne.
RECOVERABLE okre艣la, 偶e tworzenie indeksu zostanie odnotowane w dzienniku powt贸rze艅. Jest to zachowanie domy艣lne.
UNRECOVERABLE okre艣la, 偶e tworzenie indeksu nie ma by膰 odnotowane w dzienniku powt贸rze艅.
TABLESPACE okre艣la przestrze艅 tabel, gdzie indeks ma zosta膰 ponownie zbudowany.
Przyk艂ady
Zmiana warto艣ci MAXTRANS na 5.
SQL>ALTER INDEX ind_emp_empno 2> MAXTRANS 5; Index ALTERed |
Nowe ekstenty nie b臋d膮 wi臋ksze od swych poprzednik贸w.
SQL> ALTER INDEX ind_emp_empno 2> STORAGE (PCTINCREASE 0); Index ALTERed |
Zmiany w INITRANS odnosz膮 si臋 jedynie do kolejnych blok贸w.
Zmiany w MAXTRANS odnosz膮 si臋 do wszystkich blok贸w.
Zmiany w parametrach klauzuli przestrzeni odnosz膮 si臋 do kolejnych ekstent贸w.
Ponowne tworzenie indeksu
Mo偶liwe jest ponowne utworzenie indeksu przy wykorzystaniu istniej膮cego indeksu jako 藕r贸d艂a danych. Tworzenie indeksu w ten spos贸b pozwala na zmian臋 charakterystyki przechowywania indeksu, przeniesienie go do innej przestrzeni tabel. Mo偶na r贸wnie偶 w ten spos贸b usun膮膰 fragmentacj臋. Faktycznie, w por贸wnaniu z usuni臋ciem i ponownym utworzeniem indeksu za pomoc膮 polecenia CREATE INDEX taki spos贸b tworzenia indeksu jest wydajniejszy.
Usuwanie indeksu
Indeks usuwa si臋 poleceniem DROP INDEX. Indeks nale偶y usun膮膰 gdy
Nie jest on d艂u偶ej potrzebny.
Indeks sta艂 si臋 niepoprawny i przed ponownym zbudowaniem musi zosta膰 usuni臋ty.
Chcemy przenie艣膰 indeks do innej przestrzeni tabel.
B臋d膮 wykonywane du偶e operacje DML dotycz膮ce tabeli.
Sk艂adnia:
Przyk艂ad
Usuni臋cie indeksu IND_PARTS.
SQL> DROP INDEX ind_parts; Index dropped. |
Kiedy usuwa si臋 tabel臋, zbudowane na niej indeksy s膮 r贸wnie偶 usuwane.
Podsumowanie
Segmenty zawieraj膮 wszystkie dane specyficznej struktury wewn膮trz przestrzeni tabel. Segment sk艂ada si臋 z jednego lub wi臋cej ekstent贸w.
W艂asno艣ci segmentu
Typ segmentu |
Opis
|
Data |
Zawiera dane |
Index |
Dostarcza efektywnej drogi wyszukiwania wierszy w tabeli. |
Zadania
Utw贸rz przestrze艅 tabel INDEX_DATA o rozmiarze 1MB z pctincrease = 0
Po艂膮cz si臋 jako DEMO, skopiuj do katalogu z:\sql skrypt s:\create_tables.sql, zmodyfikuj go tak aby tabele EMP i DEPT zosta艂y utworzone z nast臋puj膮cymi parametrami: ekstent inicjalny 6K, nast臋pny 6K, pctincrease=0, pctfree=10 pctused=70, pocz膮tkowo 2 ekstenty, maksymalnie 30, w przestrzeni tabel USER_DATA i uruchom skrypt ;
Po艂膮czony jako DEMO utw贸rz indeks non-unique EMP_JOB na tabeli EMP oparty na kolumnie job w przestrzeni tabel INDEX_DATA
Po艂膮czony jako DEMO wykonaj polecenie ANALYZE, aby zebra膰 dane o wykorzystaniu przestrzeni przez indeks EMP_JOB ;
Po艂膮czony jako DEMO obejrzyj odpowiednie perspektywy i okre艣l jak wiele miejsca zajmuje indeks EMP_JOB. Jakie inne indeksy s膮 utworzone w schemacie DEMO? Sk膮d si臋 tam wzi臋艂y?
Po艂膮czony jako DEMO dodaj do tabeli EMP dane wykonuj膮c skrypt s:\more_emp.sql
Po艂膮czony jako DEMO usu艅 i utw贸rz na nowo indeks EMP_JOB, zbierz statystyk臋 i okre艣l miejsce jakie zajmuje indeks. Co si臋 sta艂o?
Po艂膮czony jako DEMO usu艅 indeks
Po艂膮czony jako DEMO skopiuj skrypt s:\create_tables.sql do katalogu z:\sql, zmodyfikuj go tak, by utworzy艂 tabel臋 EMP z parametrami initial=2K, next=2K, pctincrease=0, PCTUSED=80, PCTFREE=10 i uruchom go, a nast臋pnie uruchom skrypt s:\more_emp.sql
Po艂膮czony jako DEMO zmodyfikuj skrypt z:\sql\create_tables.sql tak, by utworzy艂 tabel臋 EMP1 z parametrami initial=2K, next=2K, pctincrease=0, PCTUSED=50, PCTFREE=40 i uruchom go, a nast臋pnie skopiuj skrypt s:\more_emp do z:\sql i zmodyfikuj go tak, by dodawa艂 wiersze do tabeli EMP1
Sprawd藕 wielko艣膰 segment贸w tabel EMP i EMP1. Czy tabele utworzone w 膰wiczeniu 67 r贸偶ni膮 si臋 wielko艣ci膮 od tabel utworzonych w 膰wiczeniu 68?
Usu艅 tabele EMP, DEPT, EMP1, DEPT1
W bazie potrzebna jest tabela, w kt贸rej b臋d膮 przechowywane dane statyczne i kt贸ra b臋dzie bardzo cz臋sto przegl膮dana. W celu roz艂o偶enia operacji I/O na kilka urz膮dze艅 utworzymy t臋 tabel臋 w przestrzeni tabel roz艂o偶onej na trzech dyskach
Pod艂膮czony jako sysdba utw贸rz przestrze艅 tabel STRIPE roz艂o偶on膮 na trzech plikach, ka偶dy po 110K o nast臋puj膮cych nazwach e:\kurs\database\db#\s1adm#.ora, e:\kurs\database\db#\s2adm#.ora, e:\kurs\database\db#\s3adm#.ora i upewnij si臋, czy jest w艂膮czona
Jaka jest w tym momencie ilo艣膰 wolnego miejsca w przestrzeni tabel STRIPE?
W przestrzeni tabel STRIPE utw贸rz tabel臋 BUSY z pojedynczym pierwszym ekstentem o rozmiarze 300K. Co si臋 sta艂o?
W przestrzeni tabel STRIPE utw贸rz tabel臋 BUSY, tak aby tabela powsta艂a i ilo艣膰 miejsca zarezerwowana na pocz膮tku wynosi艂a 300K ;
Ile zosta艂o wolnego miejsca w przestrzeni tabel SPRIPE?
Usu艅 przestrze艅 tabel STRIPE.
Obejrzyj perspektyw臋 DBA_FREE_SPACE? Sk膮d wzi臋艂o si臋 tyle ekstent贸w?
Sprawd藕 stopie艅 pofragmentowania przestrzeni tabel w perspektywie DBA_FREE_SPACE_COALESCE. Kt贸re przestrzenie tabel trzeba zdefragmetowa膰?
Wykonaj defragmentacj臋 wszystkich przestrzeni tabel, kt贸re tego wymagaj膮, a nast臋pnie sprawd藕 ponownie perspektyw臋 DBA_FREE_SPACE_COALESCE.
X.聽Obs艂uga klastr贸w
Cele
W tej lekcji b臋dziemy omawia膰 zarz膮dzanie segmentami klastrowymi Oracle, w tym sposoby okre艣lania rozmiaru klastr贸w i klastr贸w haszuj膮cych.
Po przerobieniu tej lekcji powiniene艣 by膰 w stanie:
Opisa膰 zalety i wady stosowania klastr贸w.
Utworzy膰 klaster.
Opisa膰 metod臋 haszowania.
Utworzy膰 klaster haszuj膮cy.
Ta lekcja zawiera materia艂 specyficzny dla pewnych konfiguracji lub implementacji Oracle. Instruktor mo偶e ograniczy膰 omawianie tego tematu w zale偶no艣ci od potrzeb s艂uchaczy. Pe艂ny tekst, 膰wiczenia i rozwi膮zania mog膮 by膰 wykorzystane w samodzielnej nauce.
Przegl膮d
Segmenty danych zawieraj膮 dane wstawiane do tabel.
Cechy Segmentu Danych
Typy Segmentu Danych
|
Funkcja |
Klaster indeksowy (index cluster) |
Zawiera wiersze jednej lub wielu tabel pogrupowane fizycznie na podstawie warto艣ci pewnej kolumny tabeli.
|
Klaster haszuj膮cy (hash cluster) |
Zawiera wiersze pewnej tabeli pogrupowane fizycznie przez zastosowanie algorytmu haszowania. |
Klastry definiuj膮 struktur臋 przechowywania. Ka偶dy klaster zawiera jedn膮 lub wiele definicji tabel.
Klastry haszuj膮ce mog膮 zawiera膰 wi臋cej ni偶 jedn膮 tabel臋, ale s膮 to rzadkie przypadki.
Tabele w klastrze s膮 wykorzystywane przez u偶ytkownik贸w w ten sam spos贸b co tabele samodzielne.
Klastry Indeksowe
Utworzenie klastra (cluster) to opcjonalna metoda przechowywania tabel, kt贸ra mo偶e poprawi膰 wydajno艣膰 I/O i zmniejszy膰 narzut wykorzystania przestrzeni. Klucz klastra (cluster key) stanowi膮 kolumny wsp贸lne dla sklastrowanych tabel. Indeks klastra (cluster index) jest indeksem utworzonym na kluczowych kolumnach klastra.
Tabele w klastrze:
Maj膮 wsp贸lne kolumny.
Cz臋sto u偶ywane razem.
Przechowywane w tych samych blokach danych.
Zalety u偶ycia klastr贸w
Zredukowane operacje dyskowe I/O, poniewa偶 powi膮zane ze sob膮 wiersze s膮 przechowywane w tych samych blokach danych.
Poprawione czasy dost臋pu przy z艂膮czeniach sklastrowanych tabel.
Zredukowana przestrze艅 indeks贸w - zw艂aszcza kiedy klucz klastra ma wiele powtarzaj膮cych si臋 warto艣ci - poniewa偶 klucz klastra przechowywany jest w indeksie tylko raz.
Teoretycznie maksymalna liczba kolumn klucza klastra wynosi 16. Praktycznie zale偶y ona od rozmiaru bloku danych, poniewa偶 rozmiar warto艣ci klucza klastra nie mo偶e przekracza膰 jednej trzeciej rozmiaru bloku danych.
Klastry mog膮 zwi臋kszy膰 efektywno艣膰 zapyta艅, ale mog膮 zmniejszy膰 efektywno艣膰 operacji wstawiania, modyfikacji i usuwania oraz pe艂nego przegl膮dania tabeli.
Przechowywanie tabeli w klastrze wymaga wi臋kszej liczby blok贸w danych w por贸wnaniu do tabeli samodzielnej, poniewa偶 bloki danych w klastrze s膮 dzielone. Je艣li w klastrze jest tylko jedna tabela, ten narzut jest jednak nieznaczny. St膮d w艂a艣nie potencjalne zmniejszanie efektywno艣ci polece艅 DML. Og贸lnie, czasami nie warto przechowywa膰 w klastrze bardzo cz臋sto aktualizowanej tabeli.
Aplikacje u偶ywaj膮 tabel sklastrowanych automatycznie. Istnienie klastr贸w jest niewidoczne dla u偶ytkownik贸w i aplikacji.
Je艣li sklastrowanych jest wiele tabel, pe艂ny przegl膮d tabeli staje si臋 wolniejszy, poniewa偶 musz膮 by膰 przegl膮dane wszystkie rekordy wszystkich tabel. Klaster z pojedyncz膮 tabel膮 nie ma tej wady.
Zarz膮dzanie Klastrami
Pewne tabele dobrze nadaj膮 si臋 do klastrowania.
Tabele Kandyduj膮ce do Klastra
Przede wszystkim przeszukiwane, rzadko aktualizowane.
Zawieraj膮ce powtarzaj膮ce si臋 warto艣ci w kolumnie.
Tabele cz臋sto 艂膮czone.
Kluczem klastra jest kolumna lub grupa kolumn wsp贸lna dla klastrowanych tabel. Ka偶da tabela w klastrze musi mie膰 kolumn臋 lub kolumny o typie i rozmiarze pasuj膮cym do klucza klastra.
Klucz Klastra
Dobrymi kluczami klastra s膮 kolumny:
Zawieraj膮ce szeroki zakres warto艣ci.
U偶ywane do z艂膮cze艅 wielu tabel.
Mniej odpowiednimi kolumnami dla klucza klastra s膮 kolumny:
Z niewieloma r贸偶nymi warto艣ciami.
Cz臋sto aktualizowane.
Zasady
Klucz klastra nie mo偶e zawiera膰 kolumn LONG oraz LONG RAW.
Og贸lnie, kryteria wyboru dobrego klucza klastra s膮 takie jak kryteria wyboru kolumn do indeksu.
Poniewa偶 warto艣膰 klucza klastra w wierszu mo偶e by膰 zmieniana, zmiana ta oznacza, 偶e wiersz musi by膰 przeniesiony. Poniewa偶 wiersze o tej samej warto艣ci klucza klastra s膮 przechowywane razem, zmiana warto艣ci klucza klastra w wierszu mo偶e przenie艣膰 wiersz do innego bloku danych. St膮d te偶 kolumny cz臋sto aktualizowane nie s膮 dobrym wyborem dla klucza klastra.
Je艣li istnieje wiele wierszy dla ka偶dej warto艣ci klucza klastra, wiersze te b臋d膮 przechowywane w blokach w 艂a艅cuchu. Nie nale偶y na przyk艂ad u偶ywa膰 jako klucza klastrowego kolumny oznaczaj膮cej p艂e膰, poniewa偶 w du偶ej organizacji ta warto艣膰 nie b臋dzie wprowadza艂a wystarczaj膮cego rozr贸偶nienia.
Je艣li jest za ma艂o wierszy z ka偶d膮 warto艣ci膮 klucza klastra, przestrze艅 blok贸w danych b臋dzie marnowana. Aby tego unikn膮膰 ustawiamy parametr SIZE na ma艂膮 warto艣膰.
Indeks klastra (cluster index) to indeks utworzony dla klastra zdefiniowany na kolumnach jego klucza.
Indeks klastra
U偶ywany do szybkiego znalezienia warto艣ci klucza klastra.
Wskazuje bezpo艣rednio na blok danych zawieraj膮cy warto艣膰 klucza klastra.
Pozwala na dost臋p do wiersza w minimalnie dw贸ch operacjach I/O.
Indeks klastra r贸偶ni si臋 od indeksu tabeli tym, 偶e:
Klucze puste (null) s膮 zarejestrowane w indeksie klastra.
Dost臋p do danych z klastra odbywa si臋 tylko przez indeks klastra.
Indeks klastra musi by膰 utworzony przed wstawianiem danych.
Zawiera tylko zapis na klucz.
Zasady
Tworzymy indeks klastra po utworzeniu klastra.
Indeks klastra nie mo偶e by膰 unikalny, ani zawiera膰 kolumn typu LONG ani LONG RAW.
Zarz膮dzanie Klastrami
Klaster i jego indeks mog膮 by膰 przechowywane w r贸偶nych przestrzeniach tabel.
Klaster i jego indeks powinny by膰 tworzone w oddzielnych przestrzeniach tabel i na r贸偶nych urz膮dzeniach fizycznych tak, aby dane tabel i indeksu mog艂y by膰 jednocze艣nie dost臋pne przy minimalnej rywalizacji o dysk.
Bloki danych klastra maj膮 taki sam format jak niesklastrowane bloki danych z wyj膮tkiem dodatkowych danych na s艂ownik tabel.
Przydzia艂 i u偶ycie przestrzeni przez dane klastra kontrolujemy za pomoc膮 parametr贸w wykorzystania przestrzeni.
Parametry Przestrzeni
INITRANS
MAXTRANS
PCTUSED
PCTFREE
SIZE
INITIAL
NEXT
MAXEXTENTS
MINEXTENTS
PCTINCREASE
Parametry przestrzeni PCTFREE oraz PCTUSED stosuj膮 si臋 do ca艂ego klastra (a nie do poszczeg贸lnych tabel).
Parametr SIZE wyznacza maksymaln膮 liczb臋 warto艣ci klucza klastra, kt贸re mog膮 by膰 przechowywane w pojedynczym bloku danych.
Parametr SIZE:
Jest argumentem opcjonalnym.
Okre艣la przybli偶on膮 liczb臋 bajt贸w potrzebn膮 na przechowywanie przeci臋tnego klucza klastra i wszystkich zwi膮zanych z nim wierszy.
Wyznacza liczb臋 kluczy klastra przechowywanych w pojedynczym bloku.
Domy艣lnie serwer Oracle przechowuje jeden klucz klastra i zwi膮zane z nim wiersze w jednym bloku danych.
Mimo, 偶e parametr SIZE wyznacza maksymaln膮 liczb臋 kluczy klastra przechowywanych w pojedynczym bloku, w bloku mo偶e by膰 mniej kluczy klastrowych. Na przyk艂ad je艣li z jednym z kluczy zwi膮zanych jest wiele wierszy, w bloku mo偶e by膰 przechowywane tylko jeden klucz klastra.
Przy wyborze warto艣ci parametru wykorzystania przestrzeni SIZE powinni艣my rozwa偶y膰 dwa warunki:
Je艣li parametr wykorzystania pami臋ci SIZE b臋dzie zbyt du偶y, marnujemy przestrze艅 (zbyt ma艂o kluczy przechowywanych w bloku klastra).
Je艣li parametr wykorzystania pami臋ci SIZE b臋dzie za ma艂y, wtedy rekordy z t膮 sam膮 warto艣ci膮 klucza przechowywane b臋d膮 w r贸偶nych blokach klastra (przy pr贸bie wstawienia do bloku klastra nie mieszcz膮cych si臋 rekord贸w).
Tworzenie klastra
Do tworzenia klastra s艂u偶y polecenie CREATE CLUSTER.
Sk艂adnia:
gdzie:
schemat schemat, kt贸ry ma zawiera膰 klaster. Domy艣lnie schemat bie偶膮cego u偶ytkownika.
klaster jest nazwa klastra.
SIZE okre艣la rozmiar przestrzeni (w bajtach, kilobajtach lub megabajtach) na umieszczenie wszystkich wierszy z okre艣lon膮 warto艣ci膮 klucza.
INDEX tworzy klaster indeksowy.
Uwaga: Inne opcje by艂y ju偶 omawiane.
Po utworzeniu klastra, mog膮 w nim by膰 tworzone tabele. Jednak偶e zanim zostan膮 wstawione wiersze do sklastrowanych tabel, trzeba utworzy膰 indeks klastra. U偶ycie klastr贸w nie pozbawia nas mo偶liwo艣ci stosowania dodatkowych indeks贸w na tabelach w klastrze - mog膮 one by膰 tworzone i usuwane w zwyk艂y spos贸b.
Tworzenie Indeksu Klastra
Najpierw tworzymy klaster a nast臋pnie indeks klastra.
Do tworzenia indeksu klastra zbudowanego na klucze klastra s艂u偶y polecenie CREATE INDEX.
Sk艂adnia:
gdzie:
schemat to schemat gdzie ma by膰 indeks.
indeks to nazwa tworzonego indeksu.
klaster okre艣la klaster, na kt贸rym tworzony jest indeks.
Przy tworzeniu indeksu klastra stosujemy te same zasady co dla zwyk艂ych indeks贸w.
Przyk艂ady
Utworzenie klastra o nazwie CLUSTER_T1_T2 z kolumn膮 DEPTNO stanowi膮c膮 klucz klastra. Klaster ma by膰 umieszczony w przestrzeni tabel TBS_DATA. Na przechowanie grupy wierszy ma by膰 przeznaczone 400 bajt贸w, pierwszy ekstent ma mie膰 30 KB.
SQL> CREATECLUSTER cluster_T1_T2 (dept NUMBER (3)) 2> SIZE 400 3> TABLESPACE tbs_data 4> STORAGE (INITIAL 30K); |
SQL>CREATE INDEX i_clu_T1_T2 2> ON CLUSTER cluster_T1_T2 3> TABLESPACE tbs_index; |
SQL> CREATE TABLE T1 (name VARCHAR2 (20), hire_date DATE, 2>聽deptno NUMBER (3)) 3> CLUSTER cluster_T1_T2 (deptno);
SQL>CREATE TABLE T2 (deptno NUMBER (3), 2> deptname VARCHAR2 (15)) 3> CLUSTER cluster_T1_T2 (deptno); |
Modyfikowanie Klastra
Do modyfikacji klastra s艂u偶y polecenie ALTER CLUSTER.
W klastrze mo偶na zmodyfikowa膰
Parametry zarz膮dzania przestrzeni膮.
Parametry wykorzystania przestrzeni bloku danych (PCTFREE i PCTUSED).
艢redni rozmiar klucza klastra (SIZE).
Ustawienia zapis贸w transakcji (INITRANS i MAXTRANS).
Sk艂adnia:
gdzie:
schemat jest schematem zawieraj膮cym klaster. Domy艣lnie schemat bie偶膮cego u偶ytkownika.
klaster to nazwa modyfikowanego klastra
SIZE okre艣la nowy rozmiar.
ALLOCATE EXTENT jest rozmiarem (KB lub MB) dodawanego ekstentu.
SIZE domy艣lnie u偶ywane s膮 parametry zarz膮dzania przestrzeni膮 klastra
DATAFILE jest jednym z plik贸w danych nale偶膮cych do przestrzeni tabel klastra. Je艣li nie jest podany, wyboru dokona serwer Oracle.
INSTANCE jest u偶ywane w trybie r贸wnoleg艂ym do okre艣lenia numeru instancji, kt贸ra ma u偶ywa膰 klastra. Domy艣ln膮 warto艣ci膮 jest ALL (wszystkie).
Opcje PCTUSED, PCTFREE, INITRANS, MAXTRANS i klauzula_przestrzeni zmieniaj膮 warto艣ci parametr贸w bloku i ekstentu.
Nowe warto艣ci dla parametr贸w PCTFREE, PCTUSED i SIZE stosuj膮 si臋 do wszystkich blok贸w danych klastra (w tym ju偶 istniej膮cych, jak i nowo przydzielanych). Jednak bloki utworzone wcze艣niej nie s膮 reorganizowane natychmiast. Zmiany nast臋puj膮 w miar臋 potrzeby. Parametry zarz膮dzania przestrzeni膮 INITIAL i MINEXTENTS nie mog膮 by膰 zmieniane.
Zmiany INITRANS stosuj膮 si臋 tylko do nowo dodawanych blok贸w danych. Zmiany MAXTRANS dotycz膮 wszystkich blok贸w.
Przyk艂ady
Zmieni膰 w klastrach CLU1, CLU2, CLU3 parametry wykorzystania przestrzeni i wykorzystania bloku.
SQL> ALTER CLUSTER clu1 2> STORAGE (NEXT 200K PCTINCREASE 33); |
SQL>ALTER CLUSTER clu2 2> SIZE 512; |
SQL> ALTER CLUSTER clu3 2> PCTFREE 40 PCTUSED 10; |
Sklastrowane tabele mog膮 by膰 modyfikowane poleceniem ALTER TABLE. Jednak polecenia modyfikacji parametr贸w wykorzystania przestrzeni blok贸w, zapis贸w transakcji i zarz膮dzania przestrzeni膮 s膮 ignorowane. Trzeba je zmienia膰 na poziomie klastra.
Usuwanie Klastra
Kiedy klaster nie jest potrzebny, mo偶na go usun膮膰poleceniem DROP CLUSTER.
Kiedy klaster jest usuwany:
Usuwane s膮 tak偶e wszystkie jego tabele.
Usuwany jest indeks klastra.
Wszystkie ekstenty s膮 zwalniane.
Sk艂adnia:
gdzie:
schemat to schemat zawieraj膮cy usuwany klaster. Domy艣lnie schemat bie偶膮cego u偶ytkownika.
klaster to nazwa usuwanego klastra.
INCLUDING TABLES powoduje usuni臋cie tabel nale偶膮cych do klastra. Je艣li nie jest podane a, nie wszystkie tabele z klastra zosta艂y usuni臋te, operacja si臋 nie powiedzie i spowoduje b艂膮d.
CASCADE CONSTRAINTS usuwa wszystkie zwi膮zane referencyjne warunki integralno艣ci. Je艣li nie jest podane istnienie takich warunk贸w spowoduje b艂膮d.
Przyk艂ad
Usuni臋cie klastra CLU1 i wszystkich jego tabel.
SQL> DROP CLUSTER clu1 2> INCLUDING TABLES; |
lub
SQL> DROP TABLE T1; SQL> DROP TABLE T2; SQL> DROP CLUSTER T1_T2; |
Poszczeg贸lne tabele mog膮 by膰 usuwane z klastra poleceniem DROP TABLE. Podczas usuwania pojedynczej tabeli:
Klaster, inne tabele oraz indeks pozostaje nie zmieniony.
Klaster powinien by膰 utworzony ponownie w celu zmniejszenia fragmentacji.
Monitorujemy lub usuwamy indeks klastra jak inne indeksy.
Mo偶emy usuwa膰 indeks klastra aby zmieni膰 parametry wykorzystania przestrzeni lub po艂o偶enie indeksu klastra. Jednak musimy odtworzy膰 indeks klastra aby mie膰 dost臋p do danych w tabelach klastra.
Zalety i Wady Klastr贸w Indeksowych
Klastry indeksowe umo偶liwiaj膮 szybszy dost臋p do wielu rekord贸w o tej samej warto艣ci klucza klastra.
Szybsze s膮 operacje wybierania, aktualizacji i usuwania.
Pojedyncza operacja wstawiania jest nieco wolniejsza ni偶 w przypadku tabeli samodzielnej.
艁adowanie danych do tabeli jest znacznie wolniejsze.
Dla ka偶dego rekordu musi by膰 odczytywany indeks klastra w celu odszukania bloku w kt贸rym powinien by膰 wstawiony wiersz.
Nie jest mo偶liwe 艂adowanie danych do tabel w klastrze bez utworzonego indeksu (st膮d indeks klastra musi by膰 aktualizowany przy wstawieniu ka偶dej nowej warto艣ci klucza).
Indeks klastra musi by膰 cz臋艣ciej modyfikowany, wi臋c generowanych jest wi臋cej informacji wycofania i dziennika powt贸rze艅.
Bloki mog膮 nie mie艣ci膰 si臋 w SGA i wtedy musz膮 by膰 odczytywane wielokrotnie.
Klastry indeksowe b臋d膮 prawdopodobnie potrzebowa艂y wi臋cej przestrzeni ni偶 zwyk艂a tabela je艣li liczba i/lub rozmiar rekord贸w z tym samym kluczem klastra s膮 bardzo zmienne.
Klastry indeksowe potencjalnie oszcz臋dzaj膮 przestrze艅 na indeksy (je艣li klaster indeksowy mo偶e zast膮pi膰 indeksowanie).
Klastry indeksowe potencjalnie mog膮 zaoszcz臋dzi膰 nieco przestrzeni je艣li klucz klastra jest stosunkowo du偶y.
艁adowanie 艣cie偶k膮 bezpo艣redni膮 nie jest mo偶liwe.
Haszowanie
Haszowanie (hashing) to inny spos贸b przechowywania danych tabeli poprawiaj膮cy efektywno艣膰 wyszukiwania danych.
Typowe Zastosowania Haszowania
Stosowanie funkcji haszuj膮cej do kolumn tabeli.
Przechowywanie wierszy zgodnie z wynikami funkcji haszuj膮cej.
Zmniejszenie 艣redniej liczby operacji
Haszowania u偶ywamy kiedy
Rozmiar tabel nie jest bardzo zmienny.
Pierwszorz臋dnym zadaniem jest optymalizacja zapyta艅.
Kryteriami zapyta艅 jest zawsze r贸wno艣膰 dotycz膮ca haszowanych kolumn.
Klucz haszowania jest dobrze roz艂o偶ony.
Uwaga: Aby zastosowa膰 haszowanie, tabela musi by膰 sklastrowana. Przed utworzeniem tabeli u偶ywaj膮cej algorytmu haszowania musi by膰 utworzony klaster haszuj膮cy.
Funkcja Haszuj膮ca
Funkcja haszuj膮ca (hash function) jest funkcj膮, kt贸ra zastosowana na kluczu klastra zwraca warto艣膰 haszuj膮c膮.
Funkcja haszuj膮ca:
Mo偶e by膰 stosowana do jednej kolumny lub klucza z艂o偶onego.
Powinna powodowa膰 optymalne roz艂o偶enie wierszy na warto艣ci haszuj膮ce.
Pr贸buje zminimalizowa膰 liczb臋 niepo偶膮danych kolizji.
Mo偶e by膰 zdefiniowana przez u偶ytkownika.
Kolizje maj膮 miejsce kiedy dwie warto艣ci klucza klastra daj膮 w wyniku identyczn膮 warto艣膰 haszuj膮c膮. U偶ytkownik mo偶e wskaza膰 kolumn臋 spe艂niaj膮c膮 takie kryteria, kt贸ra ma by膰 u偶ywana jako funkcja haszuj膮ca. Rozwa偶ania dotycz膮ce opcji HASH IS (haszem jest) znajduj膮 si臋 w dalszej cz臋艣ci tego rozdzia艂u.
Tworzenie Klastra Haszuj膮cego
Do tworzenia klastra haszuj膮cego s艂u偶y polecenie CREATE CLUSTER.
Sk艂adnia:
Uwaga: To nie jest pe艂na sk艂adnia polecenia.
gdzie:
schemat jest nazw膮 schematu tworzonego klastra. Domy艣lnie schemat bie偶膮cego u偶ytkownika.
klaster to nazwa tworzonego klastra.
SIZE okre艣la rozmiar przestrzeni (w bajtach) na przechowanie wszystkich wierszy z t膮 sam膮 warto艣ci膮 klucza haszuj膮cego. Domy艣lnie jeden blok.
HASHKEYS okre艣la, 偶e ma by膰 utworzony klaster haszuj膮cy (domy艣lnie zosta艂by utworzony klaster indeksowy). Pozwala tak偶e na ustawienie liczby warto艣ci haszuj膮cych. Je艣li podana liczba nie jest liczb膮 pierwsz膮, serwer Oracle wybiera nast臋pn膮 wi臋ksz膮 liczb臋 pierwsz膮.
HASH IS specyfikuje kolumn臋 dostarczaj膮c膮 warto艣ci haszuj膮cych. Zast臋puj膮 one WYNIKI funkcji haszuj膮cej. Podana kolumna musi by膰 jedyn膮 kolumn膮 klucza klastra i zawiera膰 tylko liczby naturalne).
Uwaga: Inne opcje by艂y omawiane wcze艣niej. Liczba warto艣ci haszuj膮cych klucza haszuj膮cego jest ustalona w momencie jego tworzenia.
Ustawienie Liczby Warto艣ci Haszuj膮cych
Wykorzystujemy parametr HASHKEYS polecenia CREATE CLUSTER.
Serwer Oracle zwi臋ksza warto艣膰 HASHKEYS do najbli偶szej liczby pierwszej. Je艣li na przyk艂ad HASHKEYS podamy 100, funkcja haszuj膮ca b臋dzie generowa膰 101 warto艣ci haszuj膮cych (od 0 do 100).
Minimalna warto艣膰 HASHKEYS to 2.
Warto艣膰 HASHKEYS podawana przy tworzeniu klastra haszuj膮cego wyznacza prawdopodobie艅stwo, 偶e dwa klucze klastra b臋d膮 mia艂y t臋 sam膮 warto艣膰 haszuj膮c膮 (wyst膮pi kolizja). Je艣li wyst臋puje wiele kolizji, musi by膰 zwi臋kszony rozmiar klucza haszuj膮cego i wtedy mniej kluczy mie艣ci si臋 w pojedynczym bloku danych. Minimalizacja liczby kolizji jest istotna, poniewa偶 na przechowywanie wierszy z koliduj膮cymi warto艣ciami klucza klastra mog膮 by膰 niezb臋dne bloki nadmiarowe. Zak艂adaj膮c r贸wnomierny rozk艂ad funkcji haszuj膮cej, je艣li HASHKEYS jest n, dane maj膮 szanse spowodowania kolizji 1/n.
Liczb臋 kluczy haszuj膮cych przypisanych do pojedynczego bloku danych okre艣lamy za pomoc膮 parametru SIZE. Parametr SIZE powinien by膰 ustawiony na 艣redni rozmiar przestrzeni potrzebnej na przechowanie wszystkich wierszy z danym kluczem haszuj膮cym.
Ustawienie Liczby Kluczy Haszuj膮cych na Blok Danych
Je艣li klaster haszuj膮cy zawiera pojedyncz膮 tabel臋 i tylko jeden wiersz przypada na warto艣膰 klucza, ustawiamy parametr SIZE na 艣redni rozmiar wiersza w tabeli. Je艣li wi臋cej ni偶 jeden wiersz przypada na warto艣膰 klucza, mno偶ymy t臋 liczb臋 przez liczb臋 wierszy na warto艣膰 klucza.
Je艣li klaster haszuj膮cy zawiera wiele tabel, SIZE powinien by膰 ustawiony na 艣redni rozmiar przestrzeni wymaganej na przechowanie wszystkich wierszy zwi膮zanych z typow膮 warto艣ci膮 haszuj膮c膮.
Przeszacowanie warto艣ci SIZE zwi臋ksza rozmiar niewykorzystanej przestrzeni w klastrze.
Warto艣ci parametr贸w HASHKEYS i SIZE maj膮 wp艂yw na umieszczenie danych w blokach klastra haszuj膮cego.
Bloki Klastra Haszuj膮cego
Przy ma艂ym 艣rednim rozmiarze klucza haszuj膮cego do pojedynczego bloku danych mo偶e by膰 przypisanych wiele warto艣ci klucza haszuj膮cego.
Przy du偶ym 艣rednim rozmiarze klucza haszuj膮cego niewielka liczba warto艣ci zmie艣ci si臋 w ka偶dym bloku danych.
Cz臋ste kolizje mog膮 spowodowa膰 tworzenie blok贸w nadmiarowych.
Kiedy nowy wiersz jest zbyt du偶y i nie mie艣ci si臋 w oryginalnym bloku danych, tworzony jest blok nadmiarowy, co powoduje zwi臋kszenie liczby operacji I/O przy wybieraniu tych danych.
Przyk艂ad
Tworzenie klastra haszuj膮cego EMP_H_CLU na kolumnie JOB w przestrzeni tabel TS_USERS. Zak艂adamy rozmiar bloku 2K i rozmiar przestrzeni danych w bloku 1800 bajt贸w. Zak艂adamy te偶, 偶e SIZE zosta艂 oszacowany na 500 bajt贸w, a istnieje 40 stanowisk (warto艣ci haszuj膮cych).
SQL> CREATE CLUSTER emp_h_clu (JOB VARCHAR2 (9)) 2> TABLESPACE ts_users 3> SIZE 500 4> HASHKEYS 40; Cluster created |
Serwer Oracle w ka偶dym bloku b臋dzie przechowywa艂 po 3 klucze haszuj膮ce. Ca艂kowita liczba kluczy haszuj膮cych b臋dzie 41 (nast臋pna liczba pierwsza wi臋ksza ni偶 40).
Serwer Oracle oblicza liczb臋 kluczy haszuj膮cych na blok przez podzielenie dost臋pnej przestrzeni przez warto艣膰 SIZE i zaokr膮glenie wyniku w d贸艂. Serwer Oracle od razu rezerwuje odpowiedni膮 liczb臋 blok贸w na wszystkie klucze haszuj膮ce. W tym przyk艂adzie s膮 3 klucze na blok, jest 41 kluczy, tak wi臋c pocz膮tkowo klaster b臋dzie zawiera艂 14 blok贸w. Innymi s艂owy serwer Oracle uwa偶a, 偶e w klastrze haszuj膮cym istnieje 14 blok贸w danych, nawet je艣li tabela nie wymaga 14 blok贸w przestrzeni.
Parametr HASH IS
Przez parametr HASH IS wskazujemy kolumn臋, kt贸rej warto艣ci maj膮 by膰 u偶ywane jako warto艣ci haszuj膮ce.
Kolumna HASH IS
Musi by膰 jedyn膮 kolumn膮 klucz klastra.
Klucz klastra musi sk艂ada膰 si臋 z pojedynczej kolumny typu NUMBER.
Klucz klastra musi zawiera膰 tylko liczby naturalne.
Mo偶e zawiera膰 funkcj臋 haszuj膮c膮 definiowan膮 przez u偶ytkownika (Oracle wersja 7.2 i聽p贸藕niejsze).
Je艣li te warunki nie s膮 spe艂nione, u偶ywana jest wewn臋trzna funkcja haszuj膮ca lub funkcja haszuj膮ca zdefiniowana przez u偶ytkownika.
Przyk艂ady
Utworzenie klastra haszuj膮cego EMP_RAISE w przestrzeni tabel TS_USERS. Jako funkcj臋 haszuj膮c膮 wykorzystujemy kolumn臋 EMPLOYEE_NUMBER. Specyfikujemy 1000 warto艣ci haszuj膮cych. Przeznaczamy 55 bajt贸w na przechowanie wierszy z t膮 sam膮 warto艣ci膮 haszuj膮c膮.
SQL>CREATE CLUSTER emp_raise (employee_number NUMBER (4)) 2> TABLESPACE ts_users 3> HASHKEYS 1000 4> HASH IS employee_number 5> SIZE 55; Cluster created. |
Utworzenie tabeli COMPENSATION w klastrze EMP_RAISE.
SQL> CREATE TABLE compensation 2> (empno NUMBER (4), ename VARCHAR2 (10), 3> sal NUMBER (10, 2), comm NUMBER (9,0)) 4> CLUSTER emp_raise (empno); Table created. |
Uwaga: W tym przyk艂adzie parametr SIZE jest mniejszy ni偶 w poprzednim. Mo偶emy za艂o偶y膰, 偶e EMPNO (numer pracownika) jest unikalny i 偶e b臋dzie prawdopodobnie tylko jeden wiersz przypadaj膮cy na ka偶d膮 warto艣膰 haszuj膮c膮. Jest to prawdopodobne kiedy podana kolumna zawiera unikalne, r贸wno roz艂o偶one warto艣ci, a warto艣膰 HASHKEYS podamy wystarczaj膮co du偶膮, aby przewy偶szy艂a oczekiwan膮 liczb臋 warto艣ci w kolumnie. Istnieje wi臋ksze prawdopodobie艅stwo kolizji, kiedy jest wi臋cej r贸偶nych warto艣ci ni偶 HASHKEYS lub je艣li w warto艣ciach kolumny s膮 przerwy (czyli warto艣ci kolumny nie s膮 r贸wno roz艂o偶one).
Funkcja Haszuj膮ca Definiowana przez U偶ytkownika
Przyk艂ad
Utworzenie klastra haszuj膮cego zawieraj膮cego informacje o pracownikach, gdzie kluczem klastra jest kod zbudowany na podstawie okre艣lonej przez u偶ytkownika kombinacji danych o miejscu zamieszkania.
HASH IS MOD((home_area_code+ home_prefix+ home_suffix),101) |
Modyfikacja Klastra Haszuj膮cego
Do modyfikacji klastra haszuj膮cego s艂u偶y polecenie ALTER CLUSTER.
Sk艂adnia:
gdzie:
schemat jest nazw膮 schematu klastra.
klaster jest nazw膮 modyfikowanego klastra
STORAGE okre艣la nowe warto艣ci dla rozszerzania klastra (MINEXTENS i INITIAL nie mog膮 by膰 zmienione).
ALLOCATE EXTENT okre艣la SIZE, DATAFILE i INSTANCE u偶ywane przy nowym, jawnie rezerwowanym ekstencie.
Parametry PCTUSED, PCTFREE i INITRANS dotycz膮 tylko nowych blok贸w.
W klastrze haszuj膮cym modyfikujemy parametry zarz膮dzania przestrzeni膮, wykorzystania przestrzeni blok贸w danych i ustawienia zapis贸w transakcji.
Przyk艂ad
Modyfikacja klastra haszuj膮cego EMP_RAISE w celu zmiany pewnych parametr贸w zarz膮dzania przestrzeni膮.
SQL>ALTER CLUSTER emp_raise 2> STORAGE (NEXT 400K PCTINCREASE 0 MAXEXTENTS 5); Cluster altered |
Parametry SIZE, HASHKEYS i HASH IS nie mog膮 by膰 zmieniane poleceniem ALTER CLUSTER.
W celu modyfikacji SIZE, HASHKEYS lub HASH IS konieczne jest ponowne utworzenie klastra i ponowne za艂adowanie danych.
Dodatkowe ekstenty klastra haszuj膮cego potrzebne s膮 tylko na bloki nadmiarowe.
Usuwanie Klastra Haszuj膮cego
Do usuwania klastr贸w haszuj膮cych s艂u偶y polecenie DROP CLUSTER.
Sk艂adnia:
gdzie:
schemat to schemat zawieraj膮cy usuwany klaster.
klaster to nazwa usuwanego klastra
INCLUDING TABLES powoduje usuniecie tabel nale偶膮cych do klastra. Je艣li nie jest podane a nie wszystkie tabele z klastra zosta艂y usuni臋te, operacja si臋 nie powiedzie i spowoduje b艂膮d.
CASCADE CONSTRAINTS usuwa wszystkie zwi膮zane referencyjne warunki integralno艣ci.
Przyk艂ad
Usuwanie klastra haszuj膮cego EMP_RAISE razem z jego tabelami.
SQL> DROP CLUSTER emp_raise 2> INCLUDING TABLES; Cluster dropped |
Poszczeg贸lne tabele mog膮 by膰 usuwane, bez usuwania klastra poleceniem DROP TABLE.
Kiedy klaster haszuj膮cy jest usuwany, zwalniane s膮 wszystkie jego ekstenty.
Zalety i Wady Klastr贸w Haszuj膮cych
Klastry haszuj膮ce dostarczaj膮 bardzo szybkiej metody dost臋pu do pojedynczego rekordu (poniewa偶 nie jest potrzebny odczyt 偶adnego indeksu).
Klastry haszuj膮ce dostarczaj膮 bardzo szybkiej metody dost臋pu do wielu rekord贸w o tej samej warto艣ci klucza klastra.
Szybsze s膮 operacje wybierania, aktualizacji i wyszukiwania.
Pojedyncze wstawianie nie jest wolniejsze ni偶 w przypadku zwyk艂ej tabeli.
艁adowanie danych do tabeli jest nieco wolniejsze.
Bloki mog膮 nie mie艣ci膰 si臋 w SGA i b臋d膮 musia艂y by膰 odczytywane wielokrotnie.
Przestrze艅 musi by膰 zarezerwowana inicjalnie, co sprawia, 偶e klastry haszuj膮ce maj膮 zastosowanie tylko gdy liczba rekord贸w bardzo nie wzrasta.
Pe艂ny przegl膮d tabeli wymaga przejrzenia wszystkich przydzielonych blok贸w nawet je艣li nie zawieraj膮 one wierszy.
Klastry haszuj膮ce s膮 u偶ywane tylko do kryteri贸w poszukiwa艅 z r贸wno艣ci膮 (kolumna = sta艂a).
Istnieje potencjalne ryzyko przepe艂nienia je艣li funkcja haszuj膮ca nie rozk艂ada r贸wnomiernie danych.
Klastry haszuj膮ce wymagaj膮 zwykle wi臋cej przestrzeni ni偶 zwyk艂a tabela je艣li liczba i/lub rozmiar rekord贸w z tym samym kluczem klastra jest bardzo zmienna.
Klastry haszuj膮ce potencjalnie oszcz臋dzaj膮 miejsce na indeks (je艣li klaster haszuj膮cy mo偶e zast膮pi膰 indeks).
Niemo偶liwe jest 艂adowanie do tabeli 艣cie偶k膮 bezpo艣redni膮.
Podsumowanie
Segmenty danych zawieraj膮 dane wstawiane do tabel.
Cechy Segmentu Danych
Typ Segmentu Danych |
Funkcja |
Klaster indeksowy (index cluster) |
Zawiera wiersze jednej lub wielu tabel pogrupowane fizycznie na podstawie warto艣ci pewnej kolumny tabeli.
|
Klaster haszujacy (hash cluster) |
Zawiera wiersze pewnej tabeli pogrupowane fizycznie przez zastosowanie algorytmu haszowania. |
Klastry definiuj膮 struktur臋 przechowywania. Ka偶dy klaster zawiera jedn膮 lub wiele definicji tabel.
Klastry haszuj膮ce mog膮 zawiera膰 wi臋cej ni偶 jedn膮 tabel臋 ale s膮 to rzadkie przypadki.
Tabele w klastrze s膮 wykorzystywane przez u偶ytkownik贸w w ten sam spos贸b co tabele samodzielne.
Zadania
Utw贸rz przestrze艅 QUERY_DATA na pliku e:\kurs\database\db#\qradm#.ora o rozmiarze 100K i parametrach initial 5K, next 5K, pctincrease 0, inne parametry domy艣lne
Pod艂膮cz si臋 jako DEMO i utw贸rz tabel臋 o nazwie S_EMP w przestrzeni tabel QUERY_DATA z nast臋puj膮cymi kolumnami:
ID NUMBER(6)
FIRST_NAME VARCHAR2(20)
LAST_NAME VARCHAR2(25)
DEPTNO NUMBER(3)
B臋d膮c pod艂膮czony jako DEMO utw贸rz klaster haszuj膮cy o nazwie EMP_HCLUSTER na 100 warto艣ci kluczy opartych na kolumnie LAST_NAME tabeli S_EMP. Ka偶dy klucz klastra ma mie膰 rozmiar 100 bajt贸w. Wykorzystaj przestrze艅 tabel QUERY_DATA
B臋d膮c pod艂膮czony jako DEMO w klastrze EMP_HCLUSTER utw贸rz tabel臋 H_EMP z takim kolumnami jak tabela S_EMP.
B臋d膮c pod艂膮czony jako DEMO utw贸rz klaster indeksowy o nazwie DEPT_EMP_ICLUSTER. Kolumna klucza klastra powinna by膰 typu NUMBER(3). Pozostaw warto艣ci domy艣lne wszystkich parametr贸w opr贸cz nast臋pujacych:
TABLESPACE QUERY_DATA
SIZE 600
INITIAL EXTENT 6000
B臋d膮c pod艂膮czony jako DEMO utw贸rz indeks klastra DEPT_EMP_ICLUSTER w przestrzeni tabel QUERY_DATA z domy艣lnymi pozosta艂ymi parametrami.
B臋d膮c pod艂膮czony jako DEMO skopiuj tabel臋 S_EMP do klastra DEPT_EMP_ICLUSTER u偶ywaj膮c klomny deptno tej tabeli jako kolumny klucza klastra. Kopi臋 tabeli nazwij I_EMP.
B臋d膮c pod艂aczony jako DEMO utw贸rz tabel臋 I_DEPT w klastrze DEPT_EMP_ICLUSTER. Tabela I_DEPT powinna mie膰 nast臋puj膮ce kolumny:
ID NUMBER(3)
NAME VARCHAR(15)
Do klucza klastra uzyj odpowiedniej kolumny.
B臋d膮c pod艂膮czony jako DEMO w perspektywie USER_SEGMENTS obejrzyj ile przestrzeni zajmuje ka偶dy obiekt w przestrzeni tabel QUERY_DATA.
XI.聽Obs艂uga wi臋z贸w integralno艣ci
Cele
Lekcja ta wyja艣nia, w jaki spos贸b utrzymywa膰 sp贸jno艣膰 danych i deklaratywne wi臋zy integralno艣ci.
Po przerobieniu tej lekcji powiniene艣 potrafi膰:
Wyja艣ni膰 znaczenie deklaratywnych wi臋z贸w integralno艣ci i sp贸jno艣ci danych.
Opisa膰 typy wi臋z贸w integralno艣ci i ich wykorzystanie.
Definiowa膰 r贸偶ne wi臋zy.
Zna膰 kwestie blokowania dotycz膮ce wi臋z贸w kluczy g艂贸wnych i obcych.
Bada膰 naruszenia wi臋z贸w poprzez tabel臋 wyj膮tk贸w (exception table).
Korzysta膰 z perspektyw s艂ownika danych do przegl膮dania wi臋z贸w.
Przegl膮d
Charakterystyk臋 danych w tabeli definiujemy za pomoc膮 wi臋z贸w integralno艣ci.
Wi臋zy integralno艣ci
Not Null
Unique
Check
Klucz g艂贸wny (Primary key)
Klucz obcy (Foreign key)
Wi臋zy definiuje si臋 przy:
Tworzeniu tabel.
Modyfikacji tabel.
Wi臋zy mog膮 by膰:
W艂膮czane.
Wy艂膮czane.
Usuwane.
Naruszenia wi臋z贸w mog膮 by膰 zapisywane w tabeli wyj膮tk贸w (exceptions table).
S艂ownik danych zawiera wiele pomocnych informacji o wi臋zach.
Sp贸jno艣膰 danych i wi臋zy integralno艣ci
Integralno艣膰 danych gwarantuje, 偶e dane w bazie spe艂niaj膮 predefiniowany zastaw wi臋z贸w lub regu艂 biznesowych. Kiedy tylko to mo偶liwe nale偶y korzysta膰 z deklaratywnych wi臋z贸w integralno艣ci.
Deklaratywne wi臋zy integralno艣ci
Dozwalaj膮 lub nie na warto艣ci puste (null values).
Zapewniaj膮 w kolumnach warto艣ci unikatowe.
Zapewniaj膮 warto艣ci identyfikuj膮ce ka偶dy wiersz tabeli.
Zapewniaj膮, 偶e kolumny odwo艂uj膮ce si臋/zale偶ne zawieraj膮 poprawne warto艣ci z tabel, do kt贸rych si臋 odwo艂uj膮.
Zalety deklaratywne wi臋z贸w integralno艣ci
Poprawiona wydajno艣膰.
艁atwo艣膰 deklaracji.
Regu艂y zcentralizowane.
艁atwo艣膰 modyfikacji.
Natychmiastowa informacja zwrotna dla u偶ytkownika.
Elastyczno艣膰 (w艂膮czanie/wy艂膮cznie).
Pe艂na dokumentacja w s艂owniku danych.
Wady deklaratywnych wi臋z贸w integralno艣ci
Jest do艣膰 trudno otrzyma膰 przegl膮d u偶ytkownik贸w, przestrzeni tabel, baz danych.
W niekt贸rych przypadkach do wymuszenia sp贸jno艣ci danych korzysta si臋 z wyzwalaczy.
Przyk艂ad
Z艂o偶one regu艂y biznesowe mog膮 zosta膰 wymuszone za pomoc膮 wyzwalaczy. Poni偶ej mamy kontrol臋 zmian pensji.
CREATE TRIGGER increase_chk BEFORE UPDATE OF salary ON s_emp FOR EACH ROW WHEN (NEW.salary <OLD.salary OR NEW.salary>1.1* OLD.salary) BEGIN Raise_application_error(-20502, `May not decrease salary. Increase must be<10 % `); END; |
Typy wi臋z贸w
Za pomoc膮 wi臋z贸w integralno艣ci mo偶na wymusi膰 kilka typ贸w sp贸jno艣ci danych.
Typy wi臋z贸w integralno艣ci
Not null
Unique
Check
Klucz G艂贸wny (Primary key).
Klucz obcy (Foreign key).
Definiowanie Wi臋z贸w
Wi臋zy mo偶na deklarowa膰 w momencie tworzenia tabeli. Korzysta si臋 wtedy z polecenia CREATE TABLE i dodaje w nim definicje wi臋z贸w.
Sk艂adnia:
gdzie:
schemat jest w艂a艣cicielem tabeli.
tabela jest nazw膮 tabeli.
kolumna okre艣la nazw臋 kolumny w tabeli.
typ_kolumny jest typem danych kolumn
DEFAULT okre艣la warto艣膰 jaka ma by膰 wstawiona do kolumny je艣li zostanie ona pomini臋ta w poleceniu INSERT.
column_constraint definiuje wi臋z integralno艣ci jako cz臋艣膰 definicji kolumny.
table_constraint definiuje wi臋z integralno艣ci jako cz臋艣膰 definicji tabeli.
Wi臋zy mog膮 zosta膰 zdefiniowane albo przy kolumnie - inline albo jako cz臋艣膰 definicji tabeli - out-of-line. Wi臋zy przy kolumnach wprowadzaj膮 regu艂y dotycz膮ce tylko tej kolumny, przy kt贸rej s膮 definiowane. Wi臋z przy kolumnie jest specyfikowany jako fragment definicji kolumny.
Sk艂adnia:
Column_constraint::=
gdzie:
CONSTRAINT identyfikuje wi臋z za pomoc膮 nazwy constraint. Nazwa jest przechowywana w bazie.
NULL okre艣la, 偶e dla kolumny dopuszczalne s膮 warto艣ci null. Ustawienie domy艣lne.
NOT NULL oznacza, 偶e w kolumnach nie mo偶e by膰 warto艣ci null.
UNIQUE definiuje kolumn臋 lub kombinacj臋 kolumn jako nie powtarzalne (unique).
PRIMARY KEY definiuje kolumn臋 lub kombinacj臋 kolumn jako klucz tabeli.
FOREIGN KEY definiuje kolumn臋 lub kombinacj臋 kolumn jako klucz obcy.
REFERENCES identyfikuje klucz g艂贸wny lub unique, kt贸ry jest wskazywany przez klucz obcy.
ON DELETE CASCADE specyfikuje, i偶 Serwer Oracle utrzymuje sp贸jno艣膰 referencyjn膮 poprzez automatyczne usuwanie wierszy z zale偶nymi warto艣ciami klucza obcego gdy usuwana jest warto艣膰 z klucza g艂贸wnego lub unique.
CHECK definiuje warunek, kt贸ry musi by膰 spe艂niony dla ka偶dego wiersza.
USING INDEX okre艣la parametry indeksu, jakiego Serwer Oracle u偶ywa do wymuszenia klucza g艂贸wnego lub klucza unique. Nazwa indeksu jest taka sama jak nazwa constraintu.
NOSORT oznacza, 偶e wiersze s膮 posortowane w porz膮dku rosn膮cym i Oracle nie musi ich sortowa膰 przy tworzeniu indeksu.
DISABLE wy艂膮cza wi臋z integralno艣ci. Je艣li wi臋z integralno艣ci jest wy艂膮czony, Serwer Oracle nie wymusza go.
Wi臋zy out-of-line s膮 cz臋艣ci膮 definicji tabeli i mog膮 definiowa膰 regu艂y dla dowolnych kolumn tabeli. Wi臋z taki specyfikowany jest po wyspecyfikowaniu wszystkich kolumn tabeli.
Sk艂adnia:
Table_constraint::=
gdzie:
CONSTRAINT identyfikuje wi臋z za pomoc膮 nazwy constraint. Nazwa jest przechowywana w bazie.
NULL okre艣la, 偶e dla kolumny dopuszczalne s膮 warto艣ci null. Ustawienie domy艣lne.
NOT NULL oznacza, 偶e w kolumnach nie mo偶e by膰 warto艣ci null.
UNIQUE definiuje kolumn臋 lub kombinacj臋 kolumn jako nie powtarzalne (unique).
PRIMARY KEY definiuje kolumn臋 lub kombinacj臋 kolumn jako klucz tabeli.
FOREIGN KEY definiuje kolumn臋 lub kombinacj臋 kolumn jako klucz obcy.
REFERENCES identyfikuje klucz g艂贸wny lub unique, kt贸ry jest wskazywany przez klucz obcy.
ON DELETE CASCADE specyfikuje, i偶 Serwer Oracle utrzymuje sp贸jno艣膰 referencyjn膮 poprzez automatyczne usuwanie wierszy z zale偶nymi warto艣ciami klucza obcego gdy usuwana jest warto艣膰 z klucza g艂贸wnego lub unique.
CHECK definiuje warunek, kt贸ry musi by膰 spe艂niony dla ka偶dego wiersza.
USING INDEX okre艣la parametry indeksu, jakiego Serwer Oracle u偶ywa do wymuszenia klucza g艂贸wnego lub klucza unique. Nazwa indeksu jest taka sama jak nazwa constraintu.
NOSORT oznacza, 偶e wiersze s膮 posortowane w porz膮dku rosn膮cym i Oracle nie musi ich sortowa膰 przy tworzeniu indeksu.
DISABLE wy艂膮cza wi臋z integralno艣ci. Je艣li wi臋z integralno艣ci jest wy艂膮czony, Serwer Oracle nie wymusza go.
Wi臋zy inline (przy kolumnie) i wi臋zy out-of-line (na poziomie tabeli) s膮 funkcjonalnie takie same. Jednak, do definicji z艂o偶onych kluczy (zostan膮 om贸wione w nast臋pnej sekcji) konieczne jest u偶ycie wi臋z贸w na poziomie tabeli.
Wi臋zy mog膮 by膰 w momencie deklaracji nazwane.
Nazwy wi臋z贸w
Nazwy wi臋z贸w nie mog膮 dla danego u偶ytkownika powtarza膰 si臋.
Nazwy wi臋z贸w powinny by膰 podawane za pomoc膮 opcjonalnej klauzuli CONSTRAINT przy ich tworzeniu.
Nazwa constrainta pojawia si臋 w komunikacie o jego naruszeniu.
Nazwa constrainta s艂u偶y jako dokumentacja w s艂owniku danych.
Nazwy upraszczaj膮 wy艂膮czanie, w艂膮czanie i usuwanie wi臋z贸w.
Je艣li nazwa constrainta nie zostanie wyspecyfikowana, Serwer Oracle przypisuje mu niepowtarzaln膮 nazw臋 w formacie: SYS_C00n. Sugerowanym formatem nazw dla wi臋z贸w jest: NAZWATABELI_TYPWI臉ZU_NAZWAKOLUMNY.
Dla przyk艂adu, wi臋z klucza g艂贸wnego na kolumnie EMPNO w tabeli EMP mo偶e otrzyma膰 nazw臋 EMP_PK_EMPNO.
Wi臋zy Not Null
Wi臋zy NOT NULL u偶ywa si臋 gdy kolumna musi zawiera膰 warto艣ci. Wi臋z NOT NULL zapewnia, i偶 wstawienia i modyfikacje tej kolumny musz膮 podawa膰 warto艣膰.
Przyk艂ad
Wymuszenie constrainta NOT NULL dla kolumny ACCOUNT w tabeli LOANS.
SQL>CREATE TABLE loans ( 2> Account NUMBER (6,0) CONSTRAINT loans_nn_account 3>聽NOT NULL, . . .) ; Table created. |
Wi臋zy NOT NULL powinny by膰 definiowane dla kolumn, kt贸re absolutnie wymagaj膮 podawania przez ca艂y czas warto艣ci (np. kolumny klucza obcego obowi膮zkowego zwi膮zku).
Ka偶de polecenie, kt贸re pr贸buje umie艣ci膰 w podanej kolumnie NULL'a jest wycofywane a b艂膮d wymazywany.
NOT NULL mo偶e zosta膰 przet艂umaczony na CHECK (column_name IS NOT NULL).
Wi臋zy Unique
Wi臋zy integralno艣ci unique zapewniaj膮, i偶 ma w tabeli dw贸ch wierszy posiadaj膮cych duplikaty warto艣ci w wyspecyfikowanych kolumnach lub zbiorze kolumn.
Przyk艂ad
Tworzenie tabeli LOANS. Definicja constraint贸w not null i unique dla kolumny LOAN_NUMBER.
SQL>CREATE TABLE loans( 2> . . . , 3> loan_number NUMBER (6,0) CONSTRAINT loan_nn_loanno 4> NOT NULL 5> CONSTRAINT loan_uk_loanno 6> UNIQUE 7> USING INDEX TABLESPACE 8> indexes_ts 9> STORAGE (INITIAL500K 10> NEXT 100K), . . .); Table created. |
W celu wymuszenia klucza unique tworzony jest automatycznie indeks.
Nazwa indeksu jest taka jak nazwa constrainta.
Wi臋zy Check
Za pomoc膮 wi臋z贸w check zapewniamy, 偶e dla ka偶dego wiersza tabeli spe艂niony (lub nieokre艣lony) jest warunek na艂o偶ony na kolumn臋 lub zbi贸r kolumn.
Przyk艂ad
Tworzenie tabeli LOANS i definicja constrainta check na kolumnie LOAN_TYPE.
SQL>CREATE TABLE loans( 2>聽. . . , 3>聽loan_type VARCHAR2 (8) CONSTRAINT loans_ck_ltype 4> CHECK (loan_type IN (`PERS', `HOME', `AUTO')), 5>聽. . .); Table created. |
Jedna kolumna mo偶e mie膰 wiele wi臋z贸w typu check. Nie ma limitu liczby wi臋z贸w check dla kolumny.
Wi臋zy klucz g艂贸wnego
Za pomoc膮 klucza g艂贸wnego definiuje si臋 kolumn臋 lub zbi贸r kolumn, kt贸rych warto艣ci jednoznacznie identyfikuj膮 ka偶dy wiersz tabeli. Tabela mo偶e mie膰 tylko jeden klucz g艂贸wny.
Przyk艂ad
Definicja klucza g艂贸wnego na kolumnie ACCOUNT w tabeli LOANS.
SQL>CREATE TABLE loans ( 2>聽account NUMBER (6,0) CONSTRAINT loans_pk_account 3> 聽PRIMARY KEY, 4>聽. . .); Table created. |
Przyk艂ad
Definicja z艂o偶onego klucza g艂贸wnego na kolumnach ACCOUNT i LOAN_NUMBER w tabeli LOANS.
SQL>CREATETABLE loans (account NUMBER (6,0), 2>聽 loan_number NUMBER (6,0), 3>聽. . . , 4>聽CONSTRAINT loans_PK_acctloan 5> PRIMARY KEY(account,聽Loan_number), 6>聽. . .); Table created. |
Wi臋zy klucza obcego
Za pomoc膮 klucza obcego zapewniamy, i偶 warto艣ci z kolumn klucza istniej膮 we wcze艣niej zdefiniowanym kluczu g艂贸wnym lub kluczu unique w innej lub tej samej tabeli.
Przyk艂ad
Tworzenie tabel z powi膮zanymi ze sob膮 wi臋zami: jednym kluczem g艂贸wnym i jednym wskazuj膮cym na niego kluczem obcym.
SQL> CREATE TABLE s_emp( 2> Id NUMBER(7) 3> CONSTRAINT s_dept_pk_id PRIMARY KEY, . . .); Table created. |
SQL> CREATE TABLE s_emp ( 2> . . . , 3> dept_id NUMBER (7) 4> CONSTRAINT s_emp_fk_dept_id REFERENCES s_dept (id)); Table created. |
Przyk艂ad
Wstawienie wiersza z poprawn膮 warto艣ci膮 DEPT_ID. Wiersz zostanie wstawiony, poniewa偶 warto艣膰 ta jest w kluczu g艂贸wnym.
SQL> INSERT INTO s_emp VALUES (26, . . . 10); Row inserted. |
Wstawienie wiersza z niepoprawnym DEPT_ID. Wiersz nie zostanie wstawiony, poniewa偶 warto艣ci takiej nie ma w kluczu g艂贸wnym.
SQL> insert INTO s_emp VALUES (26, . . , 80) ; * ERROR at line 1; ORA-02291: integrity constraint (S_EMP_FK_DEPT_ID) violated - parent key not found |
W kluczu obcym samo-odwo艂uj膮cym si臋, klucz obcy wskazuje na klucz g艂贸wny lub klucz unique tej samej tabeli.
Wiersze wskazywane przez klucz obcy domy艣lnie nie mog膮 by膰 modyfikowane ani usuwane.
Kaskadowe usuwanie ustawia si臋 opcj膮 DELETE CASCADE.
Przyk艂ad
Usuni臋cie wszystkich zatrudnionych w departamencie 10 zar贸wno z tabeli S_EMP jak i departamentu 10 z S_DEPT.
SQL> CREATE TABLE s_emp (. . . 2> dept_id NUMBER(7) CONSTRAINT s_emp_fk_dept_id 3> REFERENCES s_dept ON DELETE CASCADE 4> . . .); Table created. |
SQL> DELETE FROM s_dept 聽聽聽聽聽2> WHERE id =10 ; 1 row deleted |
Komunikat „n rows deleted” (usuni臋to n wierszy) bierze pod uwag臋 jedynie wiersze z g艂贸wnej tabeli.
Jest kilka regu艂 dotycz膮cych blokowania, kt贸re odnosz膮 si臋 do kluczy obcych.
Bez indeksu na kluczu obcym
INSERT do tabeli nadrz臋dnej nie wymaga blokady w tabeli podrz臋dnej.
DELETE lub UPDATE na tabeli nadrz臋dnej powoduje zablokowanie tabeli podrz臋dnej.
Blokada dzielona na tabeli podrz臋dnej jest wymagana do momentu zatwierdzenia transakcji wykonuj膮cej modyfikacj臋 lub usuni臋cie z tabeli nadrz臋dnej, co oznacza, 偶e nie s膮 dopuszczane modyfikacje tabeli podrz臋dnej. Blokada dzielona dopuszcza jedynie odczyty.
INSERT, DELETE lub UPDATE na tabeli podrz臋dnej nie wymaga 偶adnych blokad na tabeli nadrz臋dnej.
Indeksy na kluczu obcym
DELETE lub UPDATE na tabeli nadrz臋dnej nie zak艂ada blokady na tabeli podrz臋dnej je艣li na jej kluczu obcym istnieje indeks.
Dlatego, na tabeli podrz臋dnej mo偶e by膰 wykonywane dowolne polecenie DML w艂膮czaj膮c w to wstawienia, usuni臋cia, modyfikacje i zapytania.
Je艣li tabela podrz臋dna ma ustawion膮 opcj臋 ON DELETE CASCADE, usuni臋cia z tabeli nadrz臋dnej mog膮 oznacza膰 kaskadowe usuni臋cia z tabeli podrz臋dnej. W takim przypadku regu艂y oczekiwania i blokowania s膮 identyczne jak przy normalnym usuwaniu z tabeli podrz臋dnej.
Wi臋zy z kluczami z艂o偶onymi
Klucz z艂o偶ony tworzony jest z kilku kolumn. Kluczami z艂o偶onymi mog膮 by膰 klucze g艂贸wne, klucze obce i wi臋zy unique.
Spos贸b reakcji na null w z艂o偶onym kluczu obcym
Zabezpiecza sp贸jno艣膰 referencyjn膮 dla kompletu niepustych warto艣ci kolumn.
Zgadza si臋 ze standardami ANSI/ISO.
Przyk艂ad
Tworzenie tabeli ze z艂o偶onym kluczem obcym i constraintem CHECK zapobiegaj膮cym cz臋艣ciowo pustym kombinacjom warto艣ci klucza.
CREATE TABLE master ( A NUMBER(4), B NUMBER(4), CONSTRAINT master_pk_ab PRIMARY KEY (a,b));
CREATE TABLE detail ( A NUMBER(4), B NUMBER(4), C NUMBER(4), CONSTRAINT detail_fk_ab FOREIGN KEY (a,b) REFERENCES master |
Dodawanie wi臋z贸w
Deklaracja wi臋z贸w przy modyfikacji (ALTER) tabeli.
Sk艂adnia:
Pzyk艂ady
Zmiana tabeli S_EMP polegaj膮ca na dodaniu klucza g艂贸wnego na kolumnie ID i constraintu check na kolumnie SALARY.
ALTER TABLE s_emp ADD (CONSTRAINT s_emp_pk_id PRIMARY KEY (id), CONSTRAINT s_emp_ck_salary CHECK (salary>500)); |
Zmiana tabeli S_EMP polegaj膮ca na dodaniu klucza obcego na kolumnie MANAGER_ID - wskazuj膮cego na klucz g艂贸wny S_EMP.
ALTER TABLE s_emp ADD (CONSTRAINT s_emp_fk_manager_id FOREIGN KEY (manager_id) REFERENCES s_emp); |
Polecenie ALTER TABLE mo偶e s艂u偶y膰 do dodawania kolumn i wi臋z贸w ju偶 po utworzeniu tabeli. Polecenie ALTER TABLE mo偶e jedynie zmieni膰 wi臋z NOT NULL na istniej膮cej kolumnie. Polecenie ALTER TABLE jest r贸wnie偶 u偶ywane do usuwania wi臋z贸w integralno艣ci.
W艂膮czanie i wy艂膮czanie wi臋z贸w
Sprawdzanie wi臋z贸w integralno艣ci mo偶e by膰 w艂膮czane i wy艂膮czane
Wy艂膮czanie sprawdzania wi臋z贸w
Wy艂膮czony wi臋z nie jest wymuszany.
Dla wy艂膮czonych wi臋z贸w usuwane s膮 powi膮zane z nimi indeksu.
Wi臋zy mo偶na wy艂膮czy膰 gdy 艂adowanych b臋dzie du偶o danych, wykonywane b臋d膮 operacje wsadowe lub w czasie importowania lub eksportowania tabeli.
Przy wy艂膮czonych wi臋zach pr臋dko艣膰 艂adowania wzrasta.
W艂膮czanie sprawdzania wi臋z贸w
Gdy wi臋z jest w艂膮czony, oznacza to, 偶e jego spe艂nianie przez tabel臋 jest wymuszane.
Przy w艂膮czaniu constrainta tworzone s膮 powi膮zane z nim indeksy.
Gdy w艂膮cza si臋 wi臋z integralno艣ci, w tabeli sprawdzana jest zgodno艣膰 z nim wszystkich wierszy.
Do momentu zako艅czenia sprawdzenia tabela jest zablokowana.
Naruszenia wi臋z贸w s膮 raportowane.
Przy w艂膮czaniu constrainta, je艣li jakie艣 wiersze naruszaj膮 go, polecenia nie udaje si臋 i constraint pozostaje wy艂膮czony.
Domy艣lnie, w momencie utworzenia wi臋zy s膮 w艂膮czone.
Wy艂膮czanie wi臋z贸w
Wi臋zy wy艂膮cza si臋 poleceniem ALTER TABLE.
Sk艂adnia:
gdzie:
schemat jest schematem zawieraj膮cym tabel臋. Je艣li pominie si臋 schemat, to Serwer Oracle zak艂ada, i偶 tabela jest w schemacie aktualnego u偶ytkownika.
tabela jest nazw膮 tabeli, kt贸ra ma by膰 zmieniona.
DISABLE wy艂膮cza jeden wi臋z integralno艣ci.
UNIQUE wy艂膮cza wi臋z unique zdefiniowany na podanych kolumnach lub kolumnie.
PRIMARY KEY wy艂膮cza klucz g艂贸wny tabeli.
CONSTRAINT wy艂膮cza wi臋z integralno艣ci o nazwie constraint
CASCADE wy艂膮cza wi臋zy integralno艣ci zale偶ne od podanego constrainta. Aby wy艂膮czy膰 klucz g艂贸wny lub wi臋z unique, na kt贸ry wskazuje jaki艣 klucz obcy, podanie tej opcji jest konieczne.
Przyk艂ady
Zapytanie na DBA_CONSTRAINTS wy艣wietla informacje o wi臋zach dla tabel utworzonych przez u偶ytkownika system. Sortowanie po nazwie constrainta zapewnia zebranie razem constraint贸w dla jednej tabeli.
SQL> SELECT constraint_name, constraint_type, 2>聽table_name, status 3>聽FROM dba_constraints 4>聽WHERE owner = `SYSTEM' 5>聽AND table_name IN (` S_EMP', ` S_DEPT') 6>聽ORDER BY constraint_name; |
CONSTRAINT_NAME C TABLE_NAME STATUS
------------------------------ - ------------------------------ --------
S_DEPT_ID_NN C S_DEPT ENABLED
S_DEPT_ID_PK P S_DEPT ENABLED
S_DEPT_NAME_NN C S_DEPT ENABLED
S_DEPT_NAME_REGION_ID_UK U S_DEPT ENABLED
S_DEPT_REGION_ID_FK R S_DEPT ENABLED
S_EMP_COMMISSION_PCT_CK C S_EMP ENABLED
S_EMP_DEPT_ID_FK R S_EMP ENABLED
S_EMP_ID_NN C S_EMP ENABLED
S_EMP_ID_PK P S_EMP ENABLED
S_EMP_LAST_NAME_NN C S_EMP ENABLED
S_EMP_MANAGER_ID_FK R S_EMP ENABLED
S_EMP_TITLE_FK R S_EMP ENABLED
S_EMP_USERID_UK U S_EMP ENABLED
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Zapytanie na DBA_CONS_COLUMNS wy艣wietla kolumny, na kt贸rych zdefiniowane s膮 wi臋zy.
SQL> SELECT constraint_name, table_name, column_name 2> FROM dba_cons_columns 3> WHERE owner = `SYSTEM' 4> AND table_name IN (`S_EMP' , `S_DEPT') 5> ORDER BY constraint_name; |
CONSTRAINT_NAME TABLE_NAME COLUMN_NAME POSITION
------------------------------ ---------------------- -------------- ----------
S_DEPT_ID_NN S_DEPT ID
S_DEPT_ID_PK S_DEPT ID 1
S_DEPT_NAME_NN S_DEPT NAME S_DEPT_NAME_REGION_ID_UK S_DEPT NAME 1
S_DEPT_NAME_REGION_ID_UK S_DEPT REGION_ID 2
S_DEPT_REGION_ID_FK S_DEPT REGION_ID 1
S_EMP_DEPT_ID_FK S_EMP DEPT_ID 1
S_EMP_ID_NN S_EMP ID S_EMP_ID_PK S_EMP ID 1
S_EMP_LAST_NAME_NN S_EMP LAST_NAME
S_EMP_MANAGER_ID_FK S_EMP MANAGER_ID 1
S_EMP_TITLE_FK S_EMP TITLE 1
S_EMP_USERID_UK S_EMP USERID 1
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Pr贸ba wy艂膮czenia klucza g艂贸wnego na kolumnie ID w tabeli S_DEPT.
SQL> ALTER TABLE s_dept 2>聽DISABLE CONSTRAINT s_dept_id_pk; alter table s_dept * ERROR at line 1: ORA-02297: cannot disable constraint (SYSTEM.S_DEPT_ID_PK) - dependencies exists |
Wy艂膮czenie klucza g艂贸wnego z opcj膮 CASCADE. Zapytanie na DBA_CONSTRAINTS sprawdza, jakie wi臋zy zosta艂y wy艂膮czone.
SQL> ALTER TABLE s_dept 2>聽DISABLE CONSTRAINT s_dept_id_pk CASCADE; Table altered |
SQL> SELECT constraint_name, constraint_type, 2>聽table_name, status 3>聽FROM dba_constraints 4>聽WHERE owner = `SYSTEM' 5>聽AND table_name IN (` S_EMP', ` S_DEPT') 6>聽ORDER BY constraint_name; |
CONSTRAINT_NAME C TABLE_NAME STATUS
------------------------------ - ------------------------------ --------
S_DEPT_ID_PK P S_DEPT DISABLED
S_DEPT_NAME_NN C S_DEPT ENABLED
…
S_EMP_DEPT_ID_FK R S_EMP DISABLED
…
S_EMP_USERID_UK U S_EMP ENABLED
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
W艂膮czanie wi臋z贸w
Wi臋zy integralno艣ci w艂膮cza si臋 poleceniem ALTER TABLE.
Sk艂adnia:
gdzie:
schemat jest schematem zawieraj膮cym tabel臋.
tabela jest nazw膮 zmienianej tabeli.
ENABLE w艂膮cza pojedynczy wi臋z integralno艣ci.
UNIQUE w艂膮cza wi臋z unique zdefiniowany na podanej kolumnie lub kombinacji kolumn.
PRIMARY KEY w艂膮cza klucz g艂贸wny tabeli.
CONTRAINT w艂膮cza wi臋z integralno艣ci o nazwie constraint.
USING INDEX okre艣la parametry dla indeksu tworzonego przez Serwer Oracle dla wymuszenia unikatowo艣ci klucza unique lub klucza g艂贸wnego.
EXCEPTIONS INTO identyfikuje nazw臋 istniej膮cej tabeli wyj膮tk贸w, do kt贸rej ma trafi膰 informacja o naruszaj膮cych w艂膮czany wi臋z wierszach tabeli.
Przyk艂ady
W艂膮czanie klucza unique na kolumnie USERID w tabeli S_EMP.
SQL> ALTER TABLE s_emp 2>聽ENABLE CONSTRAINT s_emp_userid_uk 3>聽EXCEPTIONS INTO exceptions; |
W艂膮czenie klucza g艂贸wnego na kolumnie ID w tabeli S_DEPT i umieszczenie indeksu w przestrzeni tabel USER_IDX.
SQL>ALTER TABLE s_dept ENABLE CONSTRAINT s_dept_id_pk 2>聽USING INDEX TABLESPACE user_idx 3>聽EXCEPTIONS INTO exceptions; |
Obs艂uga wyj膮tk贸w
Wyj膮tki zg艂aszane przy w艂膮czaniu wi臋z贸w integralno艣ci obs艂uguje si臋 za pomoc膮 tabeli wyj膮tk贸w (exception table).
Przyk艂ady
Zapytanie na DBA_CONSTRAINS i DBA_CONS_COLUMNS wy艣wietla wi臋zy zadeklarowane na tabelach u偶ytkownika system.
SQL>SELECT a.constraint_name, constraint_type, 2>聽a.table_name, column_name, r_constraint_name, status 3>聽FROM dba_constraints a, dba_cons_columns b 4>聽WHERE a.table_name = `S_EMP' AND a.owner = `SYSTEM' 5>聽AND a.constraint_name = b. constraint_name; |
CONSTRAINT_NAME C TABLE_NAME COLUMN_NAME R_CONSTRAINT_NAME STATUS
------------------------ - ----------- -------------- ------------------ --------
…
S_EMP_ID_PK P S_EMP ID ENABLED
S_EMP_USERID_UK U S_EMP USERID ENABLED
S_EMP_COMMISSION_PCT_CK C S_EMP COMMISSION_PCT ENABLED
S_EMP_MANAGER_ID_FK R S_EMP MANAGER_ID S_EMP_ID_PK ENABLED
S_EMP_DEPT_ID_FK R S_EMP DEPT_ID S_DEPT_ID_PK ENABLED
S_EMP_TITLE_FK R S_EMP TITLE S_TITLE_TITLE_PK ENABLED
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Wy艂膮czenie constrainta S_DEPT_ID_FK.
SQL>ALTER s_dept DISABLE CONSTRAINS s_dept_id_fk; Table altered |
Modyfikacja wiersza w tabeli S_EMP tak aby warto艣膰 na kolumnie DEPT_ID by艂a niepoprawna.
SQL>UPDATE s_emp SET dept_id=100 WHERE id = 1; 1 row update |
Pr贸ba w艂膮czenia klucza obcego z opcj膮 umieszczaj膮c膮 wyj膮tki w tabeli EXCEPTIONS.
SQL>ALTER TABLE S_EMP 2>聽ENABLE CONSTRAINT s_emp_dept_id_pk 3>聽EXCEPTIONS INTO exceptions; ALTER table s_emp constraint s_emp_dept_id_fk * ERROR at line 1: ORA-02298: cannot enable (SYSTEM.S_EMP_DEPT_ID_FK)- parents key not found |
Zapytania na tabeli EXCEPTIONS i tabeli SQL_EMP wy艣wietlaj膮ce b臋d膮ce w konflikcie wiersze w tabeli S_EMP.
SQL>SELECT * FROM exceptions; |
ROW_ID OWNER TABLE_NAME CONSTRAINT
-------------------------- ----------- -------------- ---------------------------
00000099.0000.0004 SYSTEM S_EMP S_EMP_DEPT_ID_FK
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
SQL>SELECT rowid, id, dept_id 2>聽FROM s_emp 3>聽WHERE rowid IN (SELECT row_id FROM exceptions); |
ROWID ID DEPT_ID
-------------------------- ----------- --------------
00000099.0000.0004 1 100
Je艣li liczba wyj膮tk贸w zacznie narasta膰, nale偶y porozumie膰 si臋 z tw贸rc膮 aplikacji administratorem danych w celu poprawienia danych naruszaj膮cych wi臋zy.
Przed w艂膮czeniem wi臋z贸w dobrze jest usun膮膰 wiersze (delete) lub obci膮膰 (truncate) tabel臋 wyj膮tk贸w.
Usuwanie wi臋z贸w
Wi臋zy usuwa si臋 poleceniem ALTER TABLE.
Sk艂adnia:
Perspektywy s艂ownika danych dla wi臋z贸w
Informacje o wi臋zach mo偶na obejrze膰 w s艂owniku danych.
Perspektywy s艂ownika danych dla wi臋z贸w
Perspektywa
|
Opis |
ALL_CONSTRAINTS |
Definicje wi臋z贸w na dost臋pnych tabelach
|
ALL_CONS_COLUMNS |
Informacje o kolumnach w dost臋pnych definicjach wi臋z贸w. |
USER_CONSTRAINTS |
Definicje wi臋z贸w na tabelach u偶ytkownika.
|
USER_CONS_COLUMNS |
Informacje o kolumnach w definicjach wi臋z贸w w tabelach u偶ytkownika.
|
DBA_CONSTRAINTS |
Definicje wi臋z贸w dla wszystkich tabel.
|
DBA_CONS_COLUMNS |
Informacje o wszystkich kolumnach z definicjami wi臋z贸w integralno艣ci. |
Przyk艂ady
Wybranie z DBA_CONSTRAINTS wszystkich wi臋z贸w na tabelach u偶tkownika system uporz膮dkowane wed艂ug nazw constraint贸w.
SQL> SELECT constraint_name, constraint_type, 2>聽table_name, r_constraint_name, status 3> FROM dba_constraints 4>聽WHERE owner = `SYSTEM” 5>ORDER BY constraint_name; |
CONSTRAINT_NAME C TABLE_NAME R_CONSTRAINT_NAME STATUS
------------------------------ - -------------- --------------------- --------
CUSTID_ZERO C CUSTOMER ENABLED
CUSTOMER_PRIMARY_KEY P CUSTOMER ENABLED
DEPNO_PK P DEPTS ENABLED
DEPT_PRIMARY_KEY P DEPT ENABLED
DZIAL_PK P DZIALY ENABLED
EMP_FOREIGN_KEY R EMP DEPT_PRIMARY_KEY ENABLED
EMP_PRIMARY_KEY P EMP ENABLED
EMP_SELF_KEY R EMP EMP_PRIMARY_KEY ENABLED
ITEM_FOREIGN_KEY R ITEM ORD_PRIMARY_KEY ENABLED
ITEM_PRIMARY_KEY P ITEM ENABLED
ORD_FOREIGN_KEY R ORD CUSTOMER_PRIMARY_KEY ENABLED
ORD_PRIMARY_KEY P ORD ENABLED
PRAC_DZIAL_FK R PRACOWNICY DZIAL_PK ENABLED
PRAC_PK P PRACOWNICY ENABLED
PRODUCT_PRIMARY_KEY P PRODUCT ENABLED
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Wybranie z DBA_CONS_COLUMNS wszystkich kolumn, na kt贸rych system zadeklarowa艂 wi臋zy integralno艣ci, uporz膮dkowane wed艂ug nazw wi臋z贸w.
SQL>SELECT constraint_name, table_name,column_name 2>聽FROM dba_cons_columns 3>聽WHERE owner = `SYSTEM' 4>聽ORDER BY constraint_name; |
CONSTRAINT_NAME TABLE_NAME COLUMN_NAME
------------------------------ ------------------------------ -------------------
EMP_FOREIGN_KEY EMP DEPTNO
EMP_PRIMARY_KEY EMP EMPNO
EMP_SELF_KEY EMP MGR
ITEM_FOREIGN_KEY ITEM ORDID
ITEM_PRIMARY_KEY ITEM ORDID
ITEM_PRIMARY_KEY ITEM ITEMID
ORD_FOREIGN_KEY ORD CUSTID
ORD_PRIMARY_KEY ORD ORDID
PRODUCT_PRIMARY_KEY PRODUCT PRODID
S_CUSTOMER_CREDIT_RATING_CK S_CUSTOMER CREDIT_RATING
S_CUSTOMER_ID_NN S_CUSTOMER ID
S_CUSTOMER_ID_PK S_CUSTOMER ID
S_CUSTOMER_NAME_NN S_CUSTOMER NAME
S_CUSTOMER_REGION_ID_FK S_CUSTOMER REGION_ID
S_DEPT_ID_NN S_DEPT ID
S_DEPT_ID_PK S_DEPT ID
S_DEPT_NAME_NN S_DEPT NAME
S_DEPT_NAME_REGION_ID_UK S_DEPT NAME
S_DEPT_NAME_REGION_ID_UK S_DEPT REGION_ID
S_DEPT_REGION_ID_FK S_DEPT REGION_ID
S_EMP_COMMISSION_PCT_CK S_EMP COMMISSION_PCT
S_EMP_DEPT_ID_FK S_EMP DEPT_ID
S_EMP_ID_NN S_EMP ID
S_EMP_ID_PK S_EMP ID
S_EMP_LAST_NAME_NN S_EMP LAST_NAME
S_EMP_MANAGER_ID_FK S_EMP MANAGER_ID
S_EMP_TITLE_FK S_EMP TITLE
S_EMP_USERID_UK S_EMP USERID
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Podsumowanie
Do zapewnienia sp贸jno艣ci danych nale偶y wykorzysta膰 wi臋zy integralno艣ci.
Zalety deklarowanych wi臋z贸w integralno艣ci
艁atwe w deklaracji
Regu艂y zcentralizowane
艁atwe do modyfikacji
Natychmiastowa informacja dla u偶ytkownika
Elastyczne (w艂膮czane/wy艂膮czane
Poprawiona wydajno艣膰
Udokumentowane w s艂owniku danych
Typy wi臋z贸w integralno艣ci
Not null
Unique
Check
Klucz g艂贸wny (Primary key)
Klucz obcy (Foreign key)
Wi臋zy wy艂膮cza si臋 gdy
B臋dzie 艂adowana du偶a ilo艣膰 danych.
Wykonywane s膮 operacje wsadowe.
Importuje si臋 jedn膮 tabel臋 naraz.
Do obs艂ugi b艂臋d贸w wi臋z贸w integralno艣ci nale偶y korzysta膰 z tabel wyj膮tk贸w.
XII.聽Obs艂uga u偶ytkownik贸w bazy danych
Cele
Lekcja ta wyja艣nia w jaki spos贸b obs艂ugiwa膰 u偶ytkownik贸w bazy danych.
Na ko艅cu tej sekcji powiniene艣 potrafi膰
Tworzy膰 u偶ytkownik贸w bazy danych.
Modyfikowa膰 i usuwa膰 istniej膮cych u偶ytkownik贸w.
Monitorowa膰 informacje o istniej膮cych w bazie u偶ytkownikach.
Ko艅czy膰 sesje u偶ytkownik贸w.
Przegl膮d
Dost臋p do bazy danych Oracle kontrolujemy tworz膮c, modyfikuj膮c, usuwaj膮c i monitoruj膮c u偶ytkownik贸w.
Kontrolowanie dost臋pu i wykorzystania bazy danych
Tworzenie u偶ytkownik贸w i hase艂.
Autoryzacja u偶ytkownika do pod艂膮czenia si臋 do bazy danych.
Obs艂uga bezpiecze艅stwa bazy: u偶ytkownicy
Bezpiecze艅stwem bazy danych zarz膮dzamy tworz膮c u偶ytkownik贸w i odpowiadaj膮ce im schematy.
Ka偶da baza danych Oracle posiada list臋 u偶ytkownik贸w, identyfikowan膮 poprzez nazwy u偶ytkownik贸w.
Nazwa u偶ytkownika jest
Wymagana do dost臋pu do bazy.
Obs艂ugiwana przez ka偶d膮 aplikacj臋 bazodanow膮.
Zdefiniowana w bazie danych.
Kiedy u偶ytkownik bazy danych zostanie utworzony, tworzony jest r贸wnie偶 odpowiadaj膮cy mu schemat - o tej samej nazwie.
Weryfikacja w bazie Oracle
Has艂o zostaje nadane ka偶demu u偶ytkownikowi i mo偶e by膰 przez niego zmienione.
Serwer Oracle przechowuje nazwy u偶ytkownik贸w i zakodowane has艂a.
Autentyczno艣膰 u偶ytkownika jest sprawdzana przez Serwer Oracle w momencie pr贸by pod艂膮czenia si臋 do bazy.
U偶ytkownicy mog膮 te偶 by膰 weryfikowani przez system operacyjny.
Specyfikacja autentyfikacji |
Opis |
Domy艣lna przestrze艅 tabel |
Okre艣la gdzie budowa膰 obiekty, gdy nie zostanie podana przestrze艅 tabel w poleceniach CREATE TABLE, CREATE INDEX, CREATE CLUSTER. |
Przestrze艅 tymczasowa |
Dostarcza przestrzeni poleceniem SQL, kt贸re wymagaj膮 przestrzeni na dysku do podsumowania czy te偶 posortowania danych. |
Kwoty na przestrzeniach tabel |
Okre艣lenie maksymalnego rozmiaru przestrzeni, jaki u偶ytkownik mo偶e u偶y膰 w przestrzeni tabel (kwota 0 oznacza, 偶e dana przestrze艅 tabel jest niedost臋pna). |
Limity zasob贸w systemowych |
Zawieraj膮 czas CPU, liczb臋 odczyt贸w logicznych, liczb臋 r贸wnoleg艂ych sesji u偶ytkownika i czas bezczynno艣ci dla sesji; ograniczenia te podawane s膮 poprzez profile. |
Tworzenie u偶ytkownika
U偶ytkownika mo偶na utworzy膰 poleceniem CREATE USER
Sk艂adnia:
gdzie:
u偶ytkownik to nazwa u偶ytkownika, kt贸ry jest tworzony.
has艂o okre艣la has艂o
EXTERNALLY oznacza weryfikacj臋 dost臋pu u偶ytkownika poprzez system operacyjny.
DEFAULT TABLESPACE specyfikuje domy艣ln膮 przestrze艅 tabel dla u偶ytkownika.
TEMPORARY TABLESPACE specyfikuje tymczasow膮 przestrze艅 tabel dla segment贸w tymczasowych.
QUOTA pozwala u偶ytkownikowi na rezerwowanie miejsca w przestrzeni tabel, numer specyfikuje kwot臋 w K lub M.
UNLIMITED pozwala u偶ytkownikowi na rezerwowanie miejsca w wymienionej przestrzeni tabel bez ogranicze艅.
PROFILE profil przypisuje u偶ytkownikowi wymieniony profil.
Aby u偶ytkownik by艂 weryfikowany przez system operacyjny nale偶y ustawi膰 identyfikacj臋 u偶ytkownika na EXTERNALLY, ustawi膰 parametr OS_AUTHENT_PREFIX w pliku parametr贸w i zrestartowa膰 instancj臋.
Parametr ten okre艣la jaki prefiks zostanie dodany do nazwy u偶ytkownika systemu operacyjnego. Przyk艂adowo, je艣li u偶ytkownik systemu operacyjnego nazwa si臋 BRIAN, a parametr OS_AUTHENT_PREFIX ustawimy na warto艣膰 `XYZ' to w bazie Oracle powinien istnie膰 u偶ytkownik XYZBRIAN.
Aby mo偶na by艂o korzysta膰 z identyfikacji u偶ytkownika przez system operacyjny na odleg艂ych maszynach nale偶y ponadto ustawi膰 parametr REMOTE_OS_AUTHENT na warto艣膰 TRUE.
REMOTE_OS_AUTHENT=TRUE
Domy艣lnie parametr REMOTE_OS_AUTHENT ma warto艣膰 FALSE.
Przyk艂ad
U偶ycie polecenia CREATE USER do utworzenia u偶ytkownika pat z has艂em figgty9bokty. Domy艣lna przestrze艅 tabel to USERS, z kwot膮 15 MB. Przestrze艅 tymczasowa to TEMP. Dodatkowo przyznana jest kwota 10 MB na przestrzeni tabel USER_DATA
SQL> CREATE USER pat 2>聽IDENTIFIED BY figgty9bokty 3>聽DEFAULT TABLESPACE users 4>聽TEMPORARY TABLESPACE temp 5>聽QUOTA 15M ON users QUOTA 10M ON user_data; |
Dwie nazwy u偶ytkownik贸w s膮 w bazie danych Oracle zastrze偶one: sys i system.
Domy艣lnie u偶ytkownik nie posiada kwoty na 偶adnej przestrzeni tabel w bazie danych.
Kwoty nadaje si臋 u偶ytkownikowi by zapobiec zbyt du偶emu zu偶yciu przez obiekty u偶ytkownika miejsca w przestrzeni tabel.
Lista czynno艣ci przy tworzeniu u偶ytkownik贸w
Przy tworzeniu u偶ytkownik贸w bazy danych dobrze jest post臋powa膰 wed艂ug poni偶szych wytycznych.
Rejestrowanie u偶ytkownik贸w
Przypisz u偶ytkownikowi nazw臋 konta i has艂o.
Przypisz u偶ytkownikowi domy艣ln膮 przestrze艅 tabel do tworzenia obiekt贸w.
Przyznaj przestrze艅 tymczasow膮 dla tabel tymczasowych u偶ytkownika.
Zidentyfikuj przestrzenie tabel, w kt贸rych u偶ytkownik b臋dzie potrzebowa艂 przechowywa膰 obiekty.
Zdecyduj o kwocie dla ka偶dej przestrzeni tabel lub nadaj u偶ytkownikowi nie limitowan膮 ilo艣膰 miejsca.
Po rejestracji poinformuj u偶ytkownika o:
Nazwie konta i ha艣le.
Przypisanych przestrzeniach tabel i kwotach.
W jaki spos贸b pod艂膮czy膰 si臋 do Serwera Oracle.
W jaki spos贸b zmieni膰 has艂o.
Modyfikacja u偶ytkownika
Zmiana opcji powi膮zanych z u偶ytkownikiem oznacza modyfikacj臋 ustawie艅 bezpiecze艅stwa dla istniej膮cego w bazie u偶ytkownika.
Opcje zmieniane poleceniem ALTER USER
Has艂o
Modyfikacje nie wp艂ywaj膮 na aktualne sesje, jedynie na kolejne po艂膮czenia z baz膮. U偶ytkownicy mog膮 zmieni膰 swoje w艂asne has艂a. Weryfikacja w systemie operacyjnym bazuje na mechanizmach systemu operacyjnego wykorzystywanych przez Serwer Oracle.
Weryfikacja w systemie operacyjnym.
Domy艣lna przestrze艅 tabel
Tymczasowa przestrze艅 tabel
Kwoty dla przestrzeni tabel
Zmiana kwoty dla przestrzeni tabel powi臋ksza lub redukuje miejsce dost臋pu dla u偶ytkownika. Zmiana kwoty na 0 odbiera ca艂kowicie dost臋p do przestrzeni tabel.
Profil. Profile s膮 modyfikowane je艣li DBA zdecyduje o zmianie ogranicze艅 na艂o偶onych na zasoby systemowe.
Domy艣lne role. Role powinny zosta膰 ponownie przyznane je艣li np. u偶ytkownik zmienia departament i potrzebuje nowych uprawnie艅 do tabel wykorzystywanych w nowym departamencie.
U偶ytkownika mo偶na zmodyfikowa膰 poleceniem ALTER USER.
Sk艂adnia:
gdzie:
u偶ytkownik identyfikuje nazw臋 u偶ytkownika, kt贸ry ma zosta膰 zmieniony
has艂o okre艣la has艂o.
EXTERNALLY ustawia weryfikacj臋 u偶ytkownika poprzez system operacyjny
DEFAULT TABLESPACE okre艣la domy艣ln膮 przestrze艅 tabel dla obiekt贸w u偶ytkownika
TEMPORARY TABLESPACE okre艣la przestrze艅 tabel dla segment贸w tymczasowych
PROFILE zmienia profil u偶ytkownika na profile
QUOTA pozwala u偶ytkownikowi na rezerwowanie miejsca w przestrzeni tabel
numer okre艣la kwot臋 w K lub M
UNLIMITED pozwala u偶ytkownikowi na alokacj臋 miejsca w przestrzeni tabel bez 偶adnych ogranicze艅.
DEFAULT ROLE ustanawia domy艣lne role dla u偶ytkownika.
Do u偶ycia polecenia ALTER USER wymagane jest uprawnienie systemowe ALTER USER.
Przyk艂ad
Modyfikacja u偶ytkownika Hanne. Zmiana kwoty na bez limitu dla domy艣lnej przestrzeni tabel USER_DATA.
SQL>聽ALTER USER hanne 2>聽QUOTA UNLIMITED ON user_data; |
Jedynie opcje podane w poleceniu ALTER USER zostaj膮 zmienione; wszystkie inne wcze艣niejsze ustawienia obowi膮zuj膮 nadal.
Po przypisaniu u偶ytkownikowi kwoty 0, obiekty nale偶膮ce do niego pozostaj膮 w przestrzeni tabel, nie mog膮 tylko rezerwowa膰 nowego miejsca.
Usuwanie u偶ytkownika
U偶ytkownik贸w usuwa si臋 poleceniem DROP USER.
Sk艂adnia:
gdzie:
u偶ytkownik u偶ytkownik do usuni臋cia.
CASCADE usuwa wszystkie obiekty ze schematu u偶ytkownika. Opcja ta musi zosta膰 podana je艣li schemat u偶ytkownika zawiera jakie艣 obiekty.
Kiedy u偶ytkownik jest usuwany z opcj膮 CASCADE, jego nazwa i powi膮zany z nim schemat zostaj膮 usuni臋te ze s艂ownika danych, a wszystkie obiekty zawarte w schemacie u偶ytkownika s膮 natychmiast usuwane.
Nie mo偶na usun膮膰 u偶ytkownika aktualnie pod艂膮czonego do bazy danych.
Do u偶ycia polecenia DROP USER wymagane jest posiadanie uprawnienia systemowego DROP USER.
Przyk艂ad
Usuni臋cie u偶ytkownika hanne z wybraniem opcji usuwaj膮cej wszystkie obiekty nale偶膮ce do hanne.
SQL> DROP USER hanne CASCADE; |
Monitorowanie u偶ytkownik贸w
Informacje o u偶ytkownikach i profilach mo偶na znale藕膰 w s艂owniku danych, w kt贸rym zawarte s膮 dane wszystkich u偶ytkownik贸w.
S艂ownik danych zawiera informacje o:
Wszystkich u偶ytkownikach bazy danych.
Domy艣lnych przestrzeniach tabel dla tabel, klastr贸w i indeks贸w ka偶dego u偶ytkownika.
Przestrzeni tabel u偶ywanej do tworzenia segment贸w tymczasowych.
Kwotach.
Pomocne perspektywy s艂ownika danych
ALL_USERS |
wszyscy zarejestrowani u偶ytkownicy |
USER_USERS |
u偶ytkownik, kt贸ry pyta |
DBA_TS_QUOTAS |
kwoty wszystkich u偶ytkownik贸w |
USER_TS_QUOTAS |
kwoty zalogowanego u偶ytkownika |
Monitorowanie bazy danych przez perspektywy s艂ownika danych umo偶liwia zobaczenie jakie informacje s膮 sk艂adowane w bazie. S艂ownik danych bazy Oracle jest zbiorem tabel i perspektyw, kt贸re u偶ywane s膮 jedynie do odczytu, jako 藕r贸d艂o informacji o bazie.
Perspektywy s艂ownika danych zawieraj膮 aktualn膮 informacj臋 o u偶ytkownikach i ich obiektach. DBA powinien zna膰 perspektywy omawiane w tej sekcji by m贸c monitorowa膰 u偶ytkownik贸w i ich kwoty.
Przyk艂ad
Wy艣wietlanie informacji o aktualnym u偶ytkowniku z perspektywy s艂ownika danych USER_USERS.
SQL> SELECT USERNAME, USER_ID, DEFAULT_TABLESPACE, TEMPORARY_TABLESPACE, CREATED FROM user_users; |
USERNAME USER_ID DEFAULT_TABLESPACE TEMPORARY_TABLESPACE CREATED
-------------- ---------- ---------------------- ------------------------ -------
SYS 0 SYSTEM SYSTEM 97/06/14
gdzie:
USERNAME nazwa u偶ytkownika
USER_ID nr ID u偶ytkownika
DEFAULT_TABLESPACE domy艣lna przestrze艅 tabel dla u偶ytkownika
TEMPORARY_TABLESPACE przestrze艅 tabel dla segment贸w tymczasowych
CREATED data utworzenia u偶ytkownika
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Informacje o wszystkich u偶ytkownikach bazy danych znajduj膮 si臋 w perspektywie DBA_USERS
SQL> SELECT USERNAME, USER_ID, PASSWORD, , PROFILE 2>聽 FROM dba_users; |
USERNAME USER_ID PASSWORD PROFILE
------------------------------ ---------- ------------------------------ --------
SYS 0 15C146A39C91814D DEFAULT
TUTORIAL15 115 565CD49962C3CCCA DEFAULT
TUTORIAL16 116 5B61BB5091C4FDBB DEFAULT
SYSTEM 5 87C4ECFB800A8C3D DEFAULT
CTXSYS 22 EXTERNAL DEFAULT
DEMO 21 EXTERNAL DEFAULT
SCOTT 20 F894844C34402B67 DEFAULT
gdzie:
USERNAME nazwa u偶ytkownika
USER_ID nr ID u偶ytkownika
PASSWORD zakodowane has艂o
PROFILE nazwa profilu z ograniczeniami zasob贸w przydzielonych u偶ytkownikowi
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Informacje o kwotach aktualnego u偶ytkownika znajduj膮 si臋 w perspektywie s艂ownika danych USER_TS_QUOTAS.
SQL> SELECT * FROM user_ts_quotas; |
TABLESPACE_NAME BYTES MAX_BYTES BLOCKS MAX_BLOCKS
------------------------------ ---------- ---------- ---------- ----------
TOOLS 51200 -1 25 -1
TEMP 0 10485760 0 5120
gdzie:
TABLESPACE_NAME nazwa przestrzeni tabel
BYTES ilo艣膰 bajt贸w u偶ytych przez u偶ytkownik贸w
MAX_BYTES kwota u偶ytkownika w bajtach lub podana jako UNLIMITED
BLOCKS ilo艣膰 blok贸w u偶ytych przez u偶ytkownika
MAX_BLOCKS kwota u偶ytkownika podana w blokach lub jako UNLIMITED
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Warto艣膰 - 1 reprezentuje kwot臋 nieograniczon膮.
Informacje o kwotach wszystkich u偶ytkownik贸w znajduj膮 si臋 w perspektywie s艂ownika danych DBA_TS_QUOTAS.
SQL>SELECT * FROM dba_ts_quotas; |
TABLESPACE_NAME USERNAME BYTES MAX_BYTES BLOCKS MAX_BLOCKS
------------------- ---------- ---------- ---------- ---------- ----------
TOOLS SCOTT 51200 -1 25 -1
TEMP SCOTT 0 10485760 0 5120
TOOLS PAT 0 -1 0 -1
TEMP PAT 0 10485760 0 5120
gdzie:
TABLESPACE_NAME nazwa przestrzeni tabel
USERNAME u偶ytkownik, kt贸rego dotyczy kwota
BYTES ilo艣膰 bajt贸w u偶ytych przez u偶ytkownika
MAX_BYTES kwota dla u偶ytkownika w bajtach lub - 1 dla UNLIMITED
BLOCKS liczba blok贸w u偶ytych przez u偶ytkownika
MAX_BLOCKS kwota u偶ytkownika w blokach lub -1 dla UNLIMITED
Uwaga: Format powy偶szego wydruku zosta艂 poprawiony.
Zabijanie sesji u偶ytkownika
Je艣li jest to potrzebne, mo偶liwe jest zako艅czenie sesji u偶ytkownika pod艂膮czonego do bazy danych.
Zabicie sesji u偶ytkownika
Uniemo偶liwia u偶ytkownikowi wykonanie dalszych polece艅 w bazie.
Zwalnia zablokowane zasoby.
Wy艣wietli u偶ytkownikowi komunikat.
Wymaga uprawnienia ALTER SYSTEM.
Sesj臋 u偶ytkownika nale偶y zabija膰 gdy
U偶ytkownik przetrzymuje zasoby pilnie potrzebne innemu u偶ytkownikowi.
DBA musi zamkn膮膰 baz臋 danych.
Jako alternatyw臋 dla zabijania sesji u偶ytkownik贸w przy zamykaniu bazy danych mo偶na wykorzysta膰 opcj臋 IMMEDIATE.
Sesj臋 u偶ytkownika ko艅czy si臋 wydaj膮c polecenie ALTER SYSTEM.
Sk艂adnia:
gdzie:
KILL SESSION zabija sesj臋
Numer 1 okre艣la nr sesji u偶ytkownika (SESSION ID)
Numer 2 okre艣la nr seryjny u偶ytkownika
Polecenie ALTER SYSTEM KILL SESSION
Wycofuje aktualn膮 transakcj臋 u偶ytkownika.
Zwalnia wszystkie aktualnie posiadane przez u偶ytkownika blokady na tabelach i wierszach.
Zwalnia wszystkie zasoby zarezerwowane dla u偶ytkownika.
Je艣li sesja u偶ytkownika oczekuje na zako艅czenie jakiego艣 dzia艂ania, kt贸re powinno zosta膰 doko艅czone, np. oczekuje na odpowied藕 z odleg艂ej bazy danych czy wycofuje transakcj臋, Serwer Oracle czeka, a偶 dzia艂ania to zako艅czy si臋.
Nr identyfikacyjny sesji i nr seryjny sesji u偶ytkownika mo偶e odszuka膰 w perspektywie V$SESSION.
Przyk艂ad
Wykonanie krok贸w potrzebnych do zabicia sesji u偶ytkownika scott.
SQL> SELECT sid, serial#, USERNAME 2> FROM v$session; |
SID SERIAL# USERNAME
---------- ---------- ------------------------------
...
8 103 SCOTT
...
SQL> ALTER SYSTEM 2> KILL SESSION `8,103'; |
Podsumowanie
Nale偶y ostro偶nie monitorowa膰 dost臋p u偶ytkownik贸w do bazy danych i utrzymywa膰 kontrol臋 nad procesami u偶ytkownik贸w.
Monitorowanie
Obs艂uga bezpiecze艅stwa w bazie danych.
Tworzenie, modyfikacja, monitorowanie i usuwanie u偶ytkownik贸w.
W razie potrzeby - zabijanie sesji u偶ytkownik贸w.
Zadania
utw贸rz u偶ytkownika "adm#" identyfikowanego przez has艂o "adm#" na domy艣lnej przestrzeni tabel USER_DATA i tymczasowej TEMPORARY_DATA, nadaj mu kwot臋 50K na przestrzeni USER_DATA i聽nadaj mu rol臋 CONNECT
b臋d膮c po艂膮czony jako adm# wypisz kwoty przyznane u偶ytkownikowi adm#
napisz polecenie SQL wypisuj膮ce wszystkich u偶ytkownik贸w bazy danych, a nast臋pnie wszystkich pod艂膮czonych aktualnie do bazy
pod艂膮cz si臋 jako adm#, a nast臋pnie z konta sysdba zabij sesj臋 adm#
zmie艅 spos贸b autoryzacji pod艂膮czenia do bazy u偶ytkownika adm# na zewn臋trzne, ustaw odpowiednie parametry w pliku parametr贸w, zrestartuj baz臋 i spr贸buj pod艂膮czy膰 si臋 do bazy w SQL Worksheet podaj膮c przy logowaniu tylko alias bazy.
XIII.聽Kontrola u偶ycia zasob贸w systemowych
Cele
Lekcja ta opisuje w jaki spos贸b kontrolowa膰 u偶ycie zasob贸w systemowych.
Na ko艅cu tej sekcji powiniene艣 potrafi膰
Obs艂ugiwa膰 profile u偶ytkownik贸w.
Rozumie膰 i kontrolowa膰 wykorzystanie zasob贸w przez Oracle.
Tworzy膰 i przypisywa膰 u偶ytkownikom profile w celu limitowania zasob贸w Oracle.
Obs艂ugiwa膰 profile tworzone dla system.
Przegl膮d
Profile wykorzystuje si臋 do kontroli u偶ytkowania zasob贸w systemowych.
Zasoby systemowe
Czas procesora (CPU)
Operacje We/Wy
Czas bezczynno艣ci
Czas trwania sesji
Zaj臋ta pami臋膰 (prywatny obszar SQL/tylko dla MTS - serwera wielokana艂owego)
R贸wnoczesne sesje
Profile
Profile mog膮 by膰 tworzone, modyfikowane i usuwanie.
Wymuszanie limit贸w mo偶e by膰 w艂膮czane i wy艂膮czane.
Limity mog膮 zosta膰 podane osobno lub te偶 mog膮 utworzy膰 limit z艂o偶ony (composite limit).
Definiowanie profili
Limity profili mog膮 by膰 wymuszone na poziomie sesji, poziomie wywo艂ania lub obu poziomach r贸wnocze艣nie. Limity z poziomu sesji wymuszane s膮 dla ka偶dego po艂膮czenia.
Kiedy przekroczony zostanie limit na poziomie sesji
Aktualne polecenie jest wycofane.
Wszystkie poprzednie polecenia pozostaj膮 nienaruszone.
Dozwolone jest COMMIT, ROLLBACK lub zako艅czenie sesji.
W sesji tej nie mo偶na ju偶 pracowa膰.
Limity na poziomie wywo艂ania wymuszone s膮 dla ka偶dego wywo艂ania realizowanego w czasie wykonywania polece艅 SQL.
Kiedy przekroczony zostanie limit na poziomie wywo艂ania
Przetwarzanie polecenia jest zatrzymywane.
Polecenie zostaje wycofane.
Wszystkie poprzednie polecenia pozostaj膮 nienaruszone.
U偶ytkownik zachowuje otwart膮 sesj臋.
Profile
Przy wykorzystaniu profili mo偶na kontrolowa膰 zasoby systemowe.
Profile
Nazwane zbiory limit贸w dla zasob贸w.
Przypisane u偶ytkownikom.
Mog膮 by膰 w艂膮czane i wy艂膮czane (dla ca艂ego systemu).
Upraszczaj膮 zarz膮dzanie zasobami.
U偶yteczne w systemach z wieloma u偶ytkownikami lub gdy wymagaj膮 tego regu艂y pracy w firmie.
Wykorzystanie profil贸w
Zabronienie u偶ytkownikom wykonywania pewnych operacji zajmuj膮cych du偶o zasob贸w.
Zapewnienie, by u偶ytkownicy musieli od艂膮czy膰 si臋 od bazy, gdy nie pracuj膮 przez d艂u偶szy czas.
Grupowe limity zasob贸w dla podobnych u偶ytkownik贸w.
艁atwe przydzielanie limit贸w zasob贸w u偶ytkownik.
Obs艂uga u偶ycia zasob贸w w du偶ym, skomplikowanym systemie bazodanowym z wieloma u偶ytkownikami.
Wymuszanie limit贸w systemowych w艂膮cza si臋 i wy艂膮cza za pomoc膮 parametru inicjalizacyjnego RESOURCE_LIMIT lub poleceniem ALTER SYSTEM.
Parametr inicjalizacyjny RESOURCE_LIMIT
Aby w艂膮czy膰 lub wy艂膮czy膰 wymuszanie limit贸w nale偶y zmieni膰 warto艣膰 tego parametru w pliku startowym i zrestartowa膰 instancj臋.
Warto艣膰 TRUE w艂膮cza dzia艂anie profili.
Warto艣膰 FALSE (domy艣lna) wy艂膮cza wymuszanie limit贸w.
Z parametru tego korzystamy, by w艂膮czy膰 sprawdzanie limit贸w gdy mo偶liwe jest zamkni臋cie bazy.
Polecenie ALTER SYSTEM
W celu w艂膮czenia lub wy艂膮czenia wymuszania limit贸w systemowych dla instytucji korzysta si臋 z polecenia ALTER SYSTEM
Ustawienie podane poleceniem ALTER SYSTEM obowi膮zuje do wydania kolejnego takiego polecenia b膮d藕 do zamkni臋cia bazy danych.
Z polecenia tego korzystamy, gdy nie jest mo偶liwe wy艂膮czenie bazy danych.
Z polecenia ALTER SYSTEM nale偶y korzysta膰 gdy baza nie mo偶e zosta膰 zamkni臋ta lub gdy zmiana jest tymczasowa.
Sk艂adnia:
Przyk艂ad
W艂膮czenie wymuszania limit贸w zasob贸w dla instancji.
SQL> ALTER SYSTEM SET RESOURCE_LIMIT = TRUE; |
Uwaga: Do wydania tego polecenia wymagane jest posiadanie przywileju systemowego ALTER SYSTEM.
Zasoby kontrolowane na poziomie sesji
Zas贸b |
Opis
|
CPU_PER_SESSION |
Czas CPU w setnych sekundach. |
SESSIONS_PER_USER |
Liczba r贸wnoczesnych sesji dozwolonych dla ka偶dego u偶ytkownika |
CONNECT_TIME |
Czas trwania sesji w minutach. |
IDLE_TIME |
Okres bezczynno艣ci w minutach. |
LOGICAL_READS_PER_SESSION |
Liczba blok贸w danych (odczyt贸w logicznych i fizycznych). |
PRIVATE_SGA |
Prywatny obszar w SGA, mierzony w bajtach (tylko dla MTS). |
Zasoby kontrolowane na poziomie wywo艂ania
Zas贸b |
Opis
|
CPU_PER_CALL |
Czas CPU dla wywo艂ania, mierzony w setnych sekundy. |
LOGICAL_READS |
Liczba blok贸w danych. |
Wskaz贸wki:
IDLE_TIME jest obliczany jedynie dla procesu serwera. Nie bierze on pod uwag臋 czasu pracy aplikacji.
Limit IDLE_TIME nie jest zak艂贸cany przez d艂ugo dzia艂aj膮ce zapytania i inne operacje.
LOGICAL_READS_PER_SESSION jest limitem og贸lnej liczby odczyt贸w zar贸wno z pami臋ci jak i z dysku. U偶ywany jest do powstrzymywania polece艅 powoduj膮cych du偶o operacji I/O przed zaw艂aszczeniem pami臋ci lub dysku.
PRIVATE_SGA ma znaczenie jedynie przy wykorzystaniu architektury serwera wielokana艂owego i mo偶e by膰 podany w M lub K.
Tworzenie profilu
Profile tworzymy poleceniem CREATE PROFILE
Do utworzenia profilu potrzebne jest uprawnienie systemowe CREATE PROFILE. Serwer Oracle automatycznie tworzy profil DEFAULT w momencie tworzenia bazy danych.
Sk艂adnia:
gdzie:
COMPOSITE_LIMIT oznacza ca艂kowity koszt zasob贸w dla sesji wyra偶ony w jednostkach obs艂ugi.
UNLIMITED oznacza, 偶e u偶ytkownik, kt贸remu przypisano profil mo偶e korzysta膰 z podanego zasobu bez ogranicze艅.
DEFAULT oznacza, 偶e profil ten ma odziedziczy膰 ograniczenie dla podanego zasobu z profilu DEFAULT.
Przyk艂ad
Tworzenie profilu o nazwie developer_profile z maksymalnie pi臋cioma r贸wnoczesnymi sesjami, nie limitowanym czasem CPU dla wywo艂ania i maksymalnym czasem bezczynno艣ci 60 minut.
SQL>CREATE PROFILE developer_profile LIMIT 2> SESSIONS_PER_USER 5 3> CPU_PER_CALL UNLIMITED 4> IDLE _TIME 60 ; |
Password Complexity Verification (od wersji 8.0).
Sprawdza czy has艂o posiada nast臋puj膮ce cechy:
jest przynajmniej czteroznakowe.
nie jest takie samo jak nazwa u偶ytkownika.
zawiera przynajmniej jeden znak alfanumeryczny, jedna cyfra i jeden znak przystankowy
nie jest jednym z wewn臋trznej listy cz臋sto u偶ywanych s艂贸w
r贸偶ni si臋 od poprzedniego has艂a na przynajmniej 3 pozycjach
Skrypt UTLPWDMG SQL - tworzy funkcj臋 weryfikuj膮c膮 verify_function
Zmiana profilu
Zmian臋 profilu przeprowadzamy poleceniem ALTER PROFILE
Sk艂adnia:
gdzie:
COMPOSITE_LIMIT oznacza ca艂kowity koszt zasob贸w dla sesji wyra偶ony w jednostkach obs艂ugi.
UNLIMITED oznacza, 偶e u偶ytkownik, kt贸remu przypisano profil mo偶e korzysta膰 z podanego zasobu bez ogranicze艅.
DEFAULT oznacza, 偶e profil ten ma odziedziczy膰 ograniczenie dla podanego zasobu z profilu DEFAULT.
Wskaz贸wki:
Zmiany profilu nie dotycz膮 aktualnej sesji. Zmiany obowi膮zuj膮 dopiero od kolejnych sesji.
Do zbierania informacji historycznych o limitach CONNECT_TIME, LOGICAL_READS_PER_SESSION oraz LOGICAL_READS_PER_CALL nale偶y korzysta膰 z polecenia AUDIT SESSION.
Uwaga: Do modyfikacji profilu wymagane jest uprawnienie systemowe ALTER PROFILE.
Przyk艂ad
Zmiana limit贸w w profilu developer_profile i ustawienie liczby sesji r贸wnoczesnych na dwie, 30000 setnych sekundy czasu CPU na sesj臋, maksymalnego czasu bezczynno艣ci na 30 minut, a odczyt贸w logicznych dla wywo艂ania na 1000.
SQL >ALTER PROFILE developer_profile LIMIT 2> SESSIONS_PER_USER 2 3>聽CPU_PER_SESSION 300000 4>聽IDLE_TIME 30 5>聽LOGICAL_READS_PER_CALL 1000; |
Okre艣lenie profilu domy艣lnego (DEFAULT)
Ka偶da baza danych ma sw贸j profil domy艣lny nazwany default.
Profil Default
U偶ytkownicy, kt贸rym nie przypisano 偶adnego profilu posiadaj膮 profil default.
Wszystkie nie wyspecyfikowane limity dla ka偶dego z profili dziedzicz膮 ograniczenie z profilu default.
Pocz膮tkowo, wszystkie limity ustawione s膮 na bez ogranicze艅.
Profil default mo偶e by膰 zmieniany, tak 偶e u偶ytkownicy b臋d膮 mieli ustawione domy艣lnie pewne ograniczenia zasob贸w.
W celu zapobie偶enia nielimitowanemu wykorzystaniu zasob贸w, nale偶y zmieni膰 profil default.
Przyk艂ad
Zmiana profilu default poleceniem ALTER PROFILE. Ustawienie r贸wnoczesnych sesji na maksymalnie pi臋膰 po艂膮cze艅 36 sekund czasu CPU dla wywo艂ania i 30 minut czasu bezczynno艣ci.
SQL>聽ALTER PROFILE default LIMIT 2>聽SESSIONS_PER_USER 5 3>聽CPU_PER_CALL 3600 4>聽IDLE_TIME 30; |
Przypisywanie profil贸w
Profil mo偶na przypisa膰 przy tworzeniu b膮d藕 modyfikacji u偶ytkownika. Ka偶dy u偶ytkownik mo偶e mie膰 w danym momencie przypisany tylko jeden profil.
Przyk艂ad
Utworzenie u偶ytkownika Hanne z has艂em Rue - przy u偶yciu polecenia CREATE USER.
Przypisanie mu profilu developer_profile.
SQL> CREATE USER Hanne IDENTIFIED BY Rue 2> DEFAULT TABLESPACE user_data 3> TEMPORARY TABLESPACE temp 4> PROFILE developer_profile; |
Przypisanie profilu istniej膮cemu u偶ytkownikowi odbywa si臋 poleceniem ALTER USER.
Charakterystyka profil贸w
Przypisanie profilu nie zmienia aktualnych sesji.
Do przypisania profilu potrzebny jest przywilej ALTER USER.
Profile mog膮 by膰 przypisywane jedynie u偶ytkownikom, a nie rolom i innym profilom.
Je艣li przy tworzeniu u偶ytkownika nie poda si臋 profilu, automatycznie ma on przydzielanych profil default.
Przyk艂ad
Zmiana u偶ytkownika beri i przypisanie mu profilu developer_profile.
SQL> ALTER USER bert PROFILE developer_profile; |
Limity z艂o偶one
Za pomoc膮 limitu z艂o偶onego mo偶liwe jest kontrolowanie kombinacji u偶ycia zasob贸w systemowych.
Limit z艂o偶ony
Jest sum膮 wa偶on膮 czterech limit贸w: CPU_PER_SESSION, CONNECT_TIME, PRIVATE_SGA i LOGICAL_READS_PER_SESSION
Mo偶e by膰 u偶yty razem z jawnymi limitami dla zasob贸w zdefiniowanymi w tym samym profilu
Daje dodatkow膮 elastyczno艣膰 przy limitowaniu zasob贸w
Korzysta z sumy u偶ytych w czasie sesji zasob贸w
Zasoby wchodz膮ce w sk艂ad limitu z艂o偶onego mog膮 posiada膰 swoje wagi.
Koszty zasob贸w
Wykorzystywane jako wagi dla CPU_PER_SESSION, CONNECT_TIME, PRIVATE_SGA I LOGICAL_READS_PER_SESSION
Maj膮 zastosowanie jedynie do limitu z艂o偶onego
Nie dotycz膮 jawnych ustawie艅 limit贸w dla zasob贸w
Tak jest w wypadku limit贸w ustawianych jawnie, mo偶na zbiera膰 informacje historyczne o typowym u偶ytkowniku by okre艣li膰 wykorzystanie limitu z艂o偶onego
Pierwszy przekroczony limit (z艂o偶ony lub jawny) zatrzyma dzia艂anie sesji.
Usuwanie profilu
Profil usuwamy poleceniem DROP PROFILE
Sk艂adnia:
gdzie:
profil jest nazw膮 profilu do usuni臋cia.
CASCADE odbiera profil u偶ytkownikom, kt贸rzy go posiadali. Serwer Oracle automatycznie przypisze wszystkim takim u偶ytkownikom profil DEFAULT. Opcj臋 t臋 nale偶y poda膰 przy usuwaniu profili, kt贸re s膮 ju偶 komu艣 przydzielone.
Do usuni臋cia profilu potrzebny jest przywilej systemowy DROP PROFILE
Profilu DEFAULT nie da si臋 usun膮膰.
Zmiana polegaj膮ca na usuni臋ciu profilu odbija si臋 na nast臋pnych sesjach, ale nie na sesjach w艂a艣nie trwaj膮cych.
Przyk艂ad
Usuni臋cie profilu developer_profile i odebrania go u偶ytkownikom, kt贸rym by艂 przypisany.
SQL> DROP PROFILE developer_profile CASCADE; |
Przegl膮danie informacji o profilach
W celu obejrzenia informacji o profilach u偶ywamy perspektyw s艂ownika danych.
Perspektywy s艂ownika danych powi膮zane z profilami
|
|
|
|
|
|
|
|
Przyk艂ad
SQL>SELECT username, profile FROM dba_users; |
USERNAME PROFILE
------------------------------ ------------------------------
SYS DEFAULT
SYSTEM DEFAULT
DEMO DEFAULT
SCOTT DEFAULT
PAT 聽DEVELOPER_PROFILE
HANNE 聽DEVELOPER_PROFILE
SQL>SELECT * FROM profiles; |
Aby zmieni膰 wag臋 zasobu wydajemy polecenie ALTER RESOURCE COST.
Podsumowanie
Profile wykorzystywane s膮 do przypisywania i obs艂ugi limit贸w zasob贸w systemowych.
Odpowiednie ograniczenia dla zasob贸w mo偶na okre艣li膰 korzystaj膮c z:
Obserwacji w Oracle.
Monitora w Server Managerze.
Limity zasob贸w
SESSIONS_PER_USER
CPU_PER_SESSION
CPU_PER_CALL
CONNECT_TIME
IDLE_TIME
LOGICAL_READS_PER_SESSION
LOGICAL_READS_PER_CALL
PRIVATE_SGA
COMPOSITE_LIMIT
Przegl膮danie informacji o profilach
DBA_USERS
USER_RESOURCE_LIMITS
DBA_PROFILES
RESOURCE_COST
Zadania
Utw贸rz profil TEMP_PROFILE z czasem bezczynno艣ci =1
W艂膮cz wymuszanie limit贸w dla instancji
Stw贸rz u偶ytkownika ZYGMUNT/ZYGMUNT z profilem TEMP_PROFILE i nadaj mu prawo do pod艂膮czenia
Sprawd藕, czy po 1 minucie od pod艂膮czenia bez wykonywania operacji SQL u偶ytkownik ZYGMUNT zostanie roz艂膮czony, aby to sprawdzi膰 obejrzyj perspektyw臋 V$SESSION
Zmie艅 ustawienie SESSIONS_PER_USER na 1 dla TEMP_PROFILE i sprawd藕, co si臋 stanie przy pr贸bie drugiego pod艂膮czenia jako u偶ytkownik ZYGMUNT
Usu艅 profil TEMP_PROFILE i u偶ytkownika ZYGMUNT
XIV.聽Zarz膮dzanie dost臋pem do bazy danych
Cele
W lekcji tej zobaczymy jak obs艂ugiwa膰 w bazie danych uprawnienia.
Na ko艅cu tej lekcji powiniene艣 potrafi膰
Definiowa膰 uprawnienia bazodanowe.
Nadawa膰 i kontrolowa膰 uprawnienia systemowe.
Nadawa膰 i kontrolowa膰 uprawnienia obiektowe.
Przegl膮d
U偶ytkownikom mo偶na nada膰 uprawnienia dost臋pu do bazy i do obiekt贸w w tej bazie, mo偶na r贸wnie偶 nada膰 im specjalne uprawnienia systemowe.
Kontrola DBA nad uprawnieniami oznacza
Udost臋pnianie u偶ytkownikowi praw do wykonywania danego typu operacji.
Umo偶liwianie i ograniczanie dost臋pu i modyfikacji danych.
Umo偶liwianie i ograniczenie wykonywania funkcji systemowych i zmian struktur bazy danych.
Nadawanie uprawnie艅 pojedynczym u偶ytkownikom i rolom.
Nadawanie praw wszystkim u偶ytkownikom (PUBLIC).
Typ przywileju |
Opis
|
SYSTEMOWY |
Ka偶de uprawnienie systemowe pozwala u偶ytkownikowi na wykonanie pewnej operacji (lub te偶 klasy operacji) w bazie.
|
OBIEKTOWY |
Ka偶de uprawnienie obiektowe pozwala u偶ytkownikowi na wykonanie pewnej akcji na podanej tabeli, perspektywie, sekwencji, procedurze, funkcji lub pakiecie. |
Uprawnienia mo偶na kontrolowa膰 przy pomocy r贸l, kt贸re formuj膮 nazwan膮 grup臋 powi膮zanych uprawnie艅.
Do w艂asno艣ci r贸l nale偶y
Redukcja nadawania uprawnie艅.
Dynamiczne zarz膮dzanie uprawnieniami.
Selektywny dost臋p do uprawnie艅.
„艢wiadome” aplikacje (aplikacje, kt贸re same ustawiaj膮 swoje uprawnienia, za pomoc膮 r贸l, do kt贸rych hase艂 u偶ytkownik mo偶e nie zna膰).
Uprawnienia systemowe
U偶ytkownik nabiera praw do wykonania operacji lub klas operacji w bazie danych poprzez otrzymanie uprawnie艅 systemowych. Uprawnienie systemowe jest prawem do wykonania polecenia pewnego typu.
Typy uprawnie艅 systemowych
We w艂asnym schemacie
Uprawnienie tworzenia tabel we w艂asnym schemacie
Uprawnienie tworzenia sekwencji we w艂asnym schemacie
Dla wszystkich obiekt贸w pewnego typu
Uprawnienie tworzenia tabel w dowolnym schemacie
Uprawnienie modyfikacji wierszy w dowolnej tabeli czy perspektywie w dowolnym schemacie
W stosunku do systemu lub u偶ytkownika
Uprawnienie tworzenia u偶ytkownika
Uprawnienie tworzenia sesji (pod艂膮czenia si臋 do bazy danych)
Uprawnienia systemowe nie s膮 ograniczone do jednego obiektu czy struktury w schemacie. S膮 one specyficzne dla pewnej operacji lub klasy operacji na typie obiekt贸w czy struktur.
Dla przyk艂adu, uprawnienie systemowe SELECT ANY TABLE pozwala u偶ytkownikowi na formu艂owanie zapyta艅 do dowolnej tabeli w bazie danych. Uprawnienie obiektowe pozwoli u偶ytkownikowi na dost臋p do specyficznej tabeli, takiej jak SCOTT.EMP.
Istnieje 80 r贸偶nych uprawnie艅 systemowych. Ka偶de uprawnienie systemowe pozwala u偶ytkownikowi na wykonanie pewnej operacji lub klasy operacji w bazie.
Nadawanie uprawnie艅 systemowych
Uprawnienia systemowe mo偶na nadawa膰 i odbiera膰 u偶ytkownikom i rolom za pomoc膮 polecenia GRANT
Rola to nazwana grupa powi膮zanych uprawnie艅, kt贸r膮 mo偶na nadawa膰 u偶ytkownikom lub innym rolom.
Sk艂adnia:
gdzie:
rola jest nazw膮 przyznawanej roli
PUBLIC nadaje uprawnienie systemowe lub rol臋 wszystkim u偶ytkownikom.
WITH ADMIN OPTION pozwala uprawnianemu na przekazywanie przywileju systemowego lub roli dale, innym u偶ytkownikom lub rolom. Je艣li nadaje si臋 rol臋 z opcj膮 ADMIN OPTION, uprawniony mo偶e r贸wnie偶 tak膮 rol臋 zmodyfikowa膰 lub usun膮膰.
Aby nada膰 komu艣 uprawnienie, trzeba posiada膰 je WITH ADMIN OPTION.
Uprawniony mo偶e przekaza膰 uprawnienie dalej, r贸wnie偶 WITH ADMIN OPTION.
Uprawnienia WITH ADMIN OPTION nie s膮 hierarchiczne. Odebranie przywileju nadanego WITH ADMIN OPTION nie powoduje kaskadowego odbierania uprawnie艅.
Specjalne uprawnienia systemowe, SYSDBA I SYSOPER, u偶ywane w po艂膮czeniu z plikami hase艂 dla nie zabezpieczanych po艂膮cze艅, wymagaj膮 specjalnej obs艂ugi. Nie mo偶na nada膰 ich w formie WITH ADMIN OPTION i nie mo偶na nada膰 ich rolom.
Wy艣wietlanie uprawnie艅 systemowych
Nadane uprawnienia systemowe mo偶na znale藕膰 w perspektywie DBA_SYS_PRIVS.
Przyk艂ad
Wy艣wietlanie wszystkich uprawnie艅 systemowych nadanych rolom oraz u偶ytkownikom DBA_SYS_PRIVS.
SQL>SELECT * from DBA_SYS_PRIVS; |
GRANTEE PRIVILEGE ADM
------------------------------ ---------------------------------------- ---
ANIA UNLIMITED TABLESPACE NO
CONNECT ALTER SESSION NO
CONNECT CREATE CLUSTER NO
CONNECT CREATE DATABASE LINK NO
CONNECT CREATE SEQUENCE NO
CONNECT CREATE SESSION NO
CONNECT CREATE SYNONYM NO
CONNECT CREATE TABLE NO
CONNECT CREATE VIEW NO
DBA ALTER ANY CLUSTER YES
DBA ALTER ANY INDEX YES
DBA ALTER ANY LIBRARY YES
DBA ALTER ANY PROCEDURE YES
DBA ALTER ANY ROLE YES
DBA ALTER ANY SEQUENCE YES
DBA ALTER ANY SNAPSHOT YES
DBA ALTER ANY TABLE YES
DBA ALTER ANY TRIGGER YES
DBA ALTER ANY TYPE YES
DBA ALTER DATABASE YES
DBA ALTER PROFILE YES
DBA ALTER RESOURCE COST YES
DBA ALTER ROLLBACK SEGMENT YES
DBA ALTER SESSION YES
DBA ALTER SYSTEM YES
DBA ALTER TABLESPACE YES
DBA ALTER USER YES
DBA ANALYZE ANY YES
DBA AUDIT ANY YES
DBA AUDIT SYSTEM YES
DBA BACKUP ANY TABLE YES
…
Odbieranie uprawnie艅 systemowych
Uprawnienia systemowe mo偶na za pomoc膮 polecenia REVOKE.
Sk艂adnia:
gdzie:
przywilej_systemowy jest uprawnieniem, kt贸ry ma zosta膰 odebrane
rola jest rol膮, kt贸ra ma zosta膰 odebrana.
FROM identyfikuje u偶ytkownik贸w i role, kt贸rym maj膮 zosta膰 odebrane wymienione uprawnienia.
PUBLIC odbiera uprawnienia systemowe i role nadane wszystkim u偶ytkownikom.
Odbieranie uprawnie艅 systemowych WITH ADMIN OPTION
Podanie „WITH ADMIN OPTION” w momencie odbierania przywileju u偶ytkownikowi nie jest potrzebne. Je艣li opcja ta by艂a nadana, zostanie teraz odebrana.
Przyk艂ad
Odebranie scott'owi uprawnie艅 modyfikacji i usuwania u偶ytkownik贸w.
SQL> REVOKE ALTER USER, DROP USER FROM scott; |
Nadawanie uprawnie艅 obiektowych
Nadaj膮c uprawnienie obiektowe, mo偶na pozwoli膰 u偶ytkownikom na wykonanie pewnej akcji na wyspecyfikowanej tabeli, perspektywie, sekwencji lub procedurze. Typy uprawnie艅 obiektowych r贸偶ni膮 si臋 dla r贸偶nych obiekt贸w.
R贸偶ne uprawnienia obiektowe pozwalaj膮 na korzystanie z odpowiednich polece艅 SQL.
Polecenia SQL dozwalane przez uprawnienia obiektowe
Uprawnienie obiektowe |
Dozwolone polecenie SQL |
SELECT
|
SELECT FROM object (tabela, perspektywa lub snapshot), polecenia SQL korzystaj膮ce z sekwencji
|
UPDATE |
UPDATE object (tabela lub perspektywa)
|
INSERT |
INSERT INTO object (tabela lub perspektywa)
|
ALTER |
ALTER object (tabela lub sekwencja), CREATE TRIGGER ON object (tylko tabele)
|
DELETE |
DELETE FROM object (tabela lub perspektywa), TRUNCATE object (tylko tabele)
|
EXECUTE |
EXECUTE object (procedura lub funkcja), Odwo艂ywanie si臋 do publicznych zmiennych pakietowych
|
INDEX |
CREATE INDEX ON object (tylko tabele)
|
REFERENCES |
Polecenie CREATE lub ALTER TABLE definiuj膮ce klucz obcy FOREIGN KEY na obiekcie (tylko tabele) |
Uprawnienia obiektowe mo偶na nadawa膰 poleceniem GRANT.
Sk艂adnia:
gdzie:
przywilej_obiektowy jest nadawanym uprawnieniem obiektowym
kolumna okre艣la kolumn臋 tabeli lub perspektywy, dla kt贸rej nadawane s膮 prawa. Kolumny podaje si臋 tylko dla uprawnie艅 INSERT, REFERENCES i UPDATE. Je艣li kolumny nie zostan膮 podane, uprawnienie dotyczy wszystkich kolumn tabeli czy perspektywy.
ALL oznacza wszystkie uprawnienia obiektowe.
ON identyfikuje obiekt, kt贸rego dotyczy nadawane uprawnienie. Je艣li nie poda si臋 schematu, Serwer Oracle zak艂ada, 偶e chodzi o schemat aktualny.
TO identyfikuje u偶ytkownik贸w lub role, kt贸rym nadawane s膮 uprawnienia.
PUBLIC nadanie uprawnie艅 do obiektu wszystkim u偶ytkownikom.
WITH GRANT OPTION pozwala uprawnionemu na przekazanie praw innym u偶ytkownikom lub rolom. GRANT OPTION nie mo偶e zosta膰 nadana roli.
Przyk艂ady
Nadanie u偶ytkownikom hanne i ernie uprawnie艅 do przegl膮dania tabeli S_EMP.
SQL> GRANT SELECT ON s_emp TO hanne, ernie; |
Uprawnienie hanne'ego do przegl膮dania tabeli S_EMP z warto艣ciami dla kolumn ID, LAST_NAME, FIRST_NAME i DEPT_ID; do modyfikowania kolumny FIRST_NAME w tabeli S_EMP.
SQL> GRANT SELECT
2>聽 INSERT (ID, LAST_NAME, FIRST_NAME, DEPT_ID),
3> UPDATE (FIRST_NAME)
4> ON s_emp TO hanne;
Wskaz贸wki:
Aby艣my mogli nada膰 komu艣 uprawnienia do obiektu, obiekt ten musi by膰 nasz膮 w艂asno艣ci膮 (by膰 w naszym schemacie) lub te偶 musimy posiada膰 do niego uprawnienia nadane WITH GRANT OPTION.
W艂a艣ciciel obiektu mo偶e przekaza膰 uprawnienia do niego ka偶demu innemu u偶ytkownikowi czy roli.
W艂a艣ciciel obiektu automatycznie posiada do niego wszystkie prawa.
Nadawanie uprawnie艅 WITH GRANT OPTION
Uprawnienie nadane WITH GRANT OPTION mo偶e zosta膰 przez obdarowanego przekazany dalej innym u偶ytkownikom lub rolom.
SQL> GRANT SELECT ON s_emp TO hanne, ernie 2> WITH GRANT OPTION; |
Wskaz贸wki:
Je艣li polecenie GRANT zawiera klauzul臋 WITH GRANT OPTION, uprawniony mo偶e przekaza膰 uprawnienie obiektowe dalej, dla innych u偶ytkownik贸w.
Uprawnienia obiektowe nadane WITH GRANT OPTION s膮 odbierane w momencie ich odebrania temu, kto je nam nada艂.
Uprawnienie WITH GRANT OPTION nie mo偶e zosta膰 nadane roli.
Wy艣wietlanie uprawnie艅 obiektowych
Uprawnienia obiektowe nadane w systemie mo偶na wyszuka膰 w s艂owniku danych.
Perspektywy z uprawnieniami obiektowymi
Dost臋pne dla DBA |
Opis |
DBA_TAB_PRIVS |
Wszystkie uprawnienia obiektowe w bazie. |
DBA_COL_PRIVS |
Wszystkie uprawnienia w bazie dotycz膮ce kolumn |
Perspektywy uprawnie艅 obiektowych dost臋pne u偶ytkownikom |
Opis |
USER_TAB_PRIVS |
Uprawnienia obiektowe, dla kt贸rych u偶ytkownik jest w艂a艣cicielem, nadaj膮cym lub uprawnionym. |
USER_TAB_PRIVS_MADE |
Wszystkie uprawnienia na obiektach b臋d膮cych w艂asno艣ci膮 u偶ytkownika. |
USER_TAB_PRIVS_RECD |
Uprawnienia, dla kt贸rych u偶ytkownik jest uprawnionym. |
USER_COL_PRIVS |
Uprawnienia obiektowe na kolumnach, dla kt贸rych u偶ytkownik jest w艂a艣cicielem, nadaj膮cym lub uprawnionym |
USER_TAB_PRIVS_MADE |
Wszystkie uprawnienia udzielone na kolumnach obiekt贸w, kt贸rych w艂a艣cicielem jest u偶ytkownik. |
USER_TAB_PRIVS_RECD |
Uprawnienia na kolumnach, dla kt贸rych u偶ytkownik jest uprawnionym. |
ALL_TAB_PRIVS |
Uprawnienia obiektowe, dla kt贸rych uprawnionym jest u偶ytkownik lub PUBLIC. |
ALL_TAB_PRIVS_MADE |
Uprawnienia u偶ytkownika i uprawnienia na obiektach u偶ytkownika. |
ALL_TAB_PRIVS_RECD |
Uprawnienia obiektowe, dla kt贸rych uprawnionym jest u偶ytkownik lub PUBLIC. |
TABLE_PRIVILEGES |
Uprawnienia na obiektach, dla kt贸rych u偶ytkownik jest nadaj膮cym, uprawnionym lub w艂a艣cicielem oraz te, dla kt贸rych uprawnionym jest PUBLIC. |
ALL_COL_PRIVS |
Uprawnienia obiektowe na kolumnach, dla kt贸rych uprawnionym jest u偶ytkownik lub PUBLIC. |
ALL_COL_PRIVS_MADE |
Uprawnienia na kolumnach, dla kt贸rych u偶ytkownik jest w艂a艣cicielem lub nadaj膮cym. |
ALL_COL_PRIVS_RECD |
Uprawnienia obiektowe na kolumnach, dla kt贸rych uprawnionym jest u偶ytkownik lub PUBLIC. |
COLUMN_PRIVILEGES |
Uprawnienia na kolumnach, dla kt贸rych u偶ytkownik jest nadaj膮cym, uprawnionym lub w艂a艣cicielem oraz te, dla kt贸rych uprawnionym jest PUBLIC. |
Odbieranie uprawnie艅 obiektowych
Uprawnienia obiektowe odbiera si臋 (revoke) poleceniem REVOKE.
Sk艂adnia:
gdzie:
przywilej_obiektowy jest uprawnieniem obiektowym, kt贸ry ma by膰 odebrany.
ON identyfikuje obiekt, do kt贸rego odbierane s膮 uprawnienia.
FROM identyfikuje u偶ytkownik贸w i role, kt贸rym cofane s膮 uprawnienia.
PUBLIC odebranie praw nadanych wszystkim u偶ytkownikom.
CASCADE CONSTRAINTS usuwa wszystkie wi臋zy sp贸jno艣ci referencyjnej zdefiniowane przy wykorzystaniu cofanego przywileju REFERENCES. Opcja ma znaczenie tylko przy cofaniu praw REFERENCES i je艣li kto艣 z tego prawa w mi臋dzyczasie korzysta艂, musi zosta膰 podana, by uprawnienia zosta艂y cofni臋te.
Uwaga: Nadaj膮cy mog膮 odebra膰 uprawnienia jedynie tym, kt贸rym je nadali.
Odbieranie uprawnie艅 nadanych WITH GRANT OPTION
Cofni臋cie przywileju obiektowego poci膮ga za sob膮 efekt kaskady, kt贸ry powinien zosta膰 zbadany przed wykonaniem polecenia REVOKE.
Za艂贸偶my, 偶e u偶ytkownik A nada艂 u偶ytkownikowi B uprawnienie WITH GRANT OPTION, kt贸ry z kolei przekaza艂 je u偶ytkownikowi C. Je艣li u偶ytkownik A cofnie uprawnienie u偶ytkownikowi B, to przywilej straci r贸wnie偶 C.
U偶ytkownik B nie ma mo偶liwo艣ci odebrania praw u偶ytkownikowi A, a u偶ytkownik C nie b臋dzie m贸g艂 odebra膰 przywileju ani u偶ytkownikowi A, ani B.
Podsumowanie
U偶ytkownikom mo偶na nada膰 uprawnienia dost臋pu do bazy i do obiekt贸w w tej bazie, mo偶na r贸wnie偶 nada膰 im specjalne uprawnienia systemowe.
Kontrola uprawnie艅 przez DBA
Udost臋pnianie u偶ytkownikom praw do wykonywania danego typu operacji.
Umo偶liwianie i ograniczenie dost臋pu i modyfikacji danych.
Umo偶liwianie i ograniczanie wykonywania funkcji systemowych i zmian struktur bazy danych.
Uprawnienia systemowe
Kontrola dost臋pu i wykorzystania bazy na poziomie systemu.
Uprawnienia obiektowe
Kontrola dost臋pu i wykorzystania bazy danych na poziomie obiekt贸w.
Zadania
Stw贸rz u偶ytkownika ZYGMUNT/ZYGMUNT z domy艣ln膮 przestrzeni膮 tabel USER_DATA, tymczasow膮 TEMPORARY_DATA i nadaj mu prawo pod艂膮czenia do bazy i tworzenia tabel oraz kwot臋 100K na USER_DATA
Stw贸rz u偶ytkownika WACEK/WACEK i z domy艣ln膮 przestrzenia tabel USER_DATA, tymczasow膮 TEMPORARY_DATA, kwot膮 100K na przestrzeni USER_DATA i nadaj mu prawo pod艂膮czenia do bazy i tworzenia tabel
Pod艂膮cz si臋 do bazy jako ZYGMUNT i obejrzyj perspektywy SESSION_PRIVS i USER_SYS_PRIVS
Jako Zygmunt wykonaj skrypt s:\create_tables.sql tworz膮cy tabele EMP i DEPT i wype艂niaj膮cy je danymi
Sprawd藕 w s艂owniku danych czy tabele zosta艂y utworzone
Pod艂膮cz si臋 do bazy jako sysdba i spr贸buj nada膰 u偶ytkownikowi WACEK prawo SELECT do tabeli EMP w schemacie ZYGMUNT
Spr贸buj wykona膰 powy偶sze b臋d膮c pod艂膮czony jako ZYGMUNT
Sprawd藕 w perspektywie USER_TAB_PRIVS czy nadanie si臋 powiod艂o
B臋d膮c pod艂膮czony jako ZYGMUNT nadaj u偶ytkownikowi WACEK prawo modyfikacji kolumn JOB i聽HIREDATE w tabeli EMP i prawo przegl膮dania tabeli EMP
Pod艂膮cz si臋 jako WACEK i sprawd藕 USER_TAB_PRIVS i USER_COL_PRIVS
B臋d膮c pod艂膮czonym jako WACEK zmie艅 stanowisko CLERK na URZEDNIK w tabeli EMP u偶ytkownika ZYGMUNT
Wycofaj zmian臋
XV.聽Obs艂uga r贸l
Cele
Lekcja ta wyja艣nia w jaki spos贸b obs艂ugiwa膰 w bazie danych role.
Na ko艅cu tej sekcji powiniene艣 potrafi膰
Tworzy膰 i kontrolowa膰 role.
Role
Role maj膮 upro艣ci膰 zarz膮dzanie uprawnieniami. Role s膮 nazwanymi grupami powi膮zanych uprawnie艅, kt贸re mog膮 by膰 nadane u偶ytkownikom lub innym rolom.
Charakterystyka roli
Mo偶e sk艂ada膰 si臋 z uprawnie艅 zar贸wno systemowych jak i obiektowych.
Nie jest niczyj膮 w艂asno艣ci膮; nie nale偶y do 偶adnego schematu
Mo偶e by膰 nadana ka偶demu u偶ytkownikowi lub roli, poza sob膮 sam膮 (nawet po艣rednio).
Mo偶e by膰 dla ka偶dego autoryzowanego u偶ytkownika w艂膮czana i wy艂膮czana
Przy w艂膮czaniu mo偶e wymaga膰 podania has艂a.
Opisy r贸l przechowywane s膮 w s艂owniku danych.
Rola A nie mo偶e zosta膰 nadana roli B je艣li rola B mia艂a wcze艣niej nadan膮 rol臋 A.
Dla roli mo偶e by膰 zdefiniowane has艂o, a u偶ytkownicy mog膮 mie膰 j膮 nadan膮, lecz nie zna膰 jej has艂a. Has艂o b臋dzie zakodowane w aplikacji tak, i偶 u偶ytkownik mo偶e korzysta膰 z roli jedynie poprzez aplikacj臋.
Korzy艣ci z r贸l
Mniej nadawania uprawnie艅
Mo偶na nada膰 lub odebra膰 wiele uprawnie艅 za pomoc膮 jednego polecenia.
Mo偶na nada膰 rol臋 nowym u偶ytkownikom; nie jest wtedy wymagane pami臋tanie potrzebnych indywidualnych uprawnie艅.
Upraszcza obs艂ug臋 uprawnie艅 systemowych z wieloma u偶ytkownikami, tabelami lub i jednym i drugim.
Dynamiczna obs艂uga uprawnie艅
Mo偶na zmieni膰 uprawnienia roli, gdy zmienia si臋 zakres odpowiedzialno艣ci.
Zmieniaj膮c jedn膮 rol臋, mo偶na zmieni膰 uprawnienia wielu u偶ytkownik贸w.
Selektywny dost臋p do uprawnie艅
Mo偶na w艂膮cza膰 i wy艂膮cza膰 role by tymczasowo uaktywnia膰 i dezaktywowa膰 uprawnienia.
Odpowiednie, „艣wiadome” aplikacje mog膮 sprawdza膰 w s艂owniku danych i w艂膮cza膰 oraz wy艂膮cza膰 role wedle potrzeb.
Korzy艣ci dodatkowe
Obs艂uga uprawnie艅 bez kaskadowego odbierania uprawnie艅.
Wykorzystanie pakiet贸w do bezpiecze艅stwa z systemu operacyjnego przy zabezpieczeniu bazy danych.
Efektywno艣膰
Mniej indywidualnych uprawnie艅 do sprawdzenia i utrzymania w kodzie.
Tworzenie roli
Tworzenie roli poleceniem CREATE ROLE.
Sk艂adnia:
gdzie:
rola jest nazw膮 tworzonej roli
NOT IDENTIFIED wskazuje, 偶e u偶ytkownicy, kt贸rym rola zostanie nadana nie b臋d膮 weryfikowani przez Serwer Oracle przy jej w艂膮czaniu.
IDENTIFIED wskazuje, 偶e u偶ytkownicy, kt贸rym rola zostanie nadana musz膮 zosta膰 przy jej w艂膮czeniu zweryfikowani przez Serwer Oracle.
has艂o wskazuje, 偶e przy w艂膮czaniu roli u偶ytkownik musi poda膰 has艂o.
EXTERNALLY Serwer Oracle b臋dzie do weryfikacji u偶ytkownik贸w korzystaj膮cych z tej roli u偶ywa艂 narz臋dzi systemu operacyjnego.
Po utworzeniu roli nale偶y nada膰 jej uprawnienia poleceniem GRANT, a j膮 sam膮 nada膰 u偶ytkownikom r贸wnie偶 poleceniem GRANT.
Do tworzenia r贸l potrzebne jest posiadanie uprawnienia CREATE ROLE.
Modyfikowanie roli
Modyfikuj膮c rol臋 mo偶na zmieni膰 typ autoryzacji potrzebny, by j膮 w艂膮czy膰.
Sk艂adnia:
gdzie:
rola jest nazw膮 tworzonej roli
NOT IDENTIFIED wskazuje, 偶e u偶ytkownicy, kt贸rym rola zostanie nadana nie b臋d膮 weryfikowani przez Serwer Oracle przy jej w艂膮czaniu.
IDENTYFIED wskazuje, 偶e u偶ytkownicy, kt贸rym rola zostanie nadana musz膮 zosta膰 przy jej w艂膮czeniu zweryfikowani przez Serwer Oracle.
has艂o wskazuje, 偶e przy w艂膮czaniu roli u偶ytkownik musi poda膰 has艂o.
EXTERNALLY Serwer Oracle b臋dzie do weryfikacji u偶ytkownik贸w korzystaj膮cych z tej roli u偶ywa艂 narz臋dzi systemu operacyjnego.
W艂膮czanie i wy艂膮czanie r贸l
Role w艂膮cza si臋 lub wy艂膮cza by udost臋pni膰 lub ograniczy膰 u偶ytkownikom pewne uprawnienia.
W艂膮czenie i wy艂膮czenie
DBA mo偶e okre艣li膰, kt贸re role mog膮 by膰 w艂膮czane dla u偶ytkownik贸w w momencie pod艂膮czenia si臋 do bazy.
Uprawnienia nadane wy艂膮czonej roli nie s膮 dla u偶ytkownika dost臋pne.
DBA mo偶e za偶膮da膰 has艂a lub autoryzacji w systemie operacyjnym.
SET ROLE w艂膮cza jedynie wyspecyfikowane role, a wy艂膮cza wszystkie wcze艣niej udost臋pnione.
Rola mo偶e zosta膰 w艂膮czona z
J臋zyka trzeciej generacji (PRO*C)
SQL*Plus'a i Server Manager'a.
PL/SQL'a (przy u偶yciu polece艅 z bibliotek).
Role w艂膮cza si臋 poleceniem SET ROLE.
Sk艂adnia:
gdzie:
rola jest rol膮, jaka ma by膰 w bie偶膮cej sesji w艂膮czona. Wszystkie nie wymienione role zostaj膮 wy艂膮czone.
has艂o jest has艂em dla roli. Je艣li rola posiada has艂o, musi ono zosta膰 tu podane.
ALL w艂膮cza wszystkie role nadane u偶ytkownikowi, pr贸cz tych wymienionych w klauzuli EXCEPT. Role wymienione w klauzuli EXCEPT musz膮 by膰 rolami nadanymi bezpo艣rednio; nie wolno podawa膰 tam r贸l otrzymywanych poprzez inne role. Nie mo偶na r贸wnie偶 skorzysta膰 z tej opcji do w艂膮czenia tych r贸l nadanych bezpo艣rednio, kt贸re maj膮 has艂a. Je艣li w li艣cie r贸l w klauzuli EXCEPT wyst膮pi rola nadana zar贸wno bezpo艣rednio jak i poprzez inn膮 rol臋, rola taka zostanie w艂膮czona w momencie w艂膮czenia roli, kt贸rej zosta艂a nadana.
NONE wy艂膮cza wszystkie role.
Opcja ALL dzia艂a jedynie wtedy, gdy wszystkie role albo nie maj膮 hase艂 (nie s膮 autoryzowane), albo s膮 autoryzowane zewn臋trznie (externally - w systemie operacyjnym).
Przy opcji ALL, nie ma mo偶liwo艣ci podania hase艂. Dlatego role te musz膮 albo nie mie膰 hase艂, albo by膰 autoryzowane zewn臋trznie (externally).
Polecenie SET ROLE wy艂膮cza wszystkie inne role u偶ytkownika.
Ustalanie r贸l domy艣lnych
Role domy艣lne dla danego u偶ytkownika ustala si臋 poleceniem ALTER USER.
Sk艂adnia:
gdzie:
u偶ytkownik to u偶ytkownik, kt贸ry ma by膰 zmieniony.
DEFAULT ROLE ustawia domy艣lne role u偶ytkownika. Serwer Oracle w艂膮cza domy艣lnie role w momencie otwierania przez u偶ytkownika sesji. Domy艣lnie, wszystkie role nadane u偶ytkownikowi s膮 jego rolami domy艣lnymi.
ALL czyni wszystkie role nadane u偶ytkownikowi rolami domy艣lnymi, z wy艂膮czeniem tych, kt贸re zostan膮 wymienione w klauzuli EXCEPT.
NONE 偶adna z r贸l nadanych u偶ytkownikowi nie jest jego rol膮 domy艣ln膮.
Polecenie ustanawia role, kt贸re b臋d膮 w艂膮czane automatycznie przy pod艂膮czaniu si臋 przez u偶ytkownika do bazy (nie jest potrzebne has艂o).
Je艣li dla u偶ytkownika nie s膮 podane 偶adne role domy艣lne, to przy pod艂膮czeniu si臋 przez u偶ytkownika do bazy (nie jest potrzebne has艂o).
Rola domy艣lna jest w艂膮czana automatycznie przy pod艂膮czaniu si臋 do bazy (nie jest potrzebne has艂o).
Role domy艣lne mo偶na wyspecyfikowa膰 r贸wnie偶 w poleceniu CREATE USER.
Uwaga: Aby rol臋 uczyni膰 rol膮 domy艣ln膮 u偶ytkownika musi by膰 ona wcze艣niej nadana u偶ytkownikowi poleceniem GRANT.
Wy艣wietlanie informacji o rolach
W celu wy艣wietlania u偶ytkownik贸w i nadanych im r贸l oraz nadanych rolom uprawnie艅, nale偶y skorzysta膰 z nast臋puj膮cych perspektyw s艂ownika danych.
Perspektywa
|
Opis |
ROLEE_SYS_PRIVS |
Informacje o uprawnieniach systemowych nadanych rolom. |
ROLE_TAB_PRIVS |
Informacje o uprawnieniach obiektowych nadanych rolom. |
ROLE_ROLE_PRIVS |
Informacje o rolach nadanych innym rolom. |
SESSION_ROLES |
Role, kt贸re s膮 w sesji aktualnie w艂膮czone. |
USER_ROLE_PRIVS |
Role nadane u偶ytkownikowi. |
DBA_SYS_PRIVS |
Opis uprawnie艅 systemowych nadanych rolom i u偶ytkownikom. |
DBA_ROLES |
Wszystkie istniej膮ce w bazie role. |
Role OSOPER i OSDBA
Dwie specjalne role, OSOPER i OSDBA, wykorzystywane s膮 do kontrolowania operacji bazodanowych gdy s艂ownik danych jest niedost臋pny (innymi s艂owy, gdy baza jest zamkni臋ta), specjalnie - do ochrony u偶ycia s艂owa kluczowego INTERNAL.
Role OSOPER i OSDBA pozwalaj膮 na dwa poziomy wykorzystania s艂owa kluczowego INTERNAL.
Rola
|
Opis |
OSOPER |
Pozwala u偶ytkownikowi na wykonanie STARTUP, SHUTDOWN, ALTER DATABASE OPEN/MOUNT, ALTER DATABASE BACKUP CONTROLFILE, ALTER TABLESPACE BEGIN/END BACKUP, ARCHIVE LOG AND RECOVER; rola OSOPER zawiera r贸wnie偶 uprawnienie RESTRICTED SESSION.
|
OSDBA |
Zawiera wszystkie uprawnienia systemowe z opcj膮 administracji nimi (WITH ADMIN OPTION) oraz rol臋 OSOPER; jedynie rola OSDBA pozwala na wykonanie polecenia CREATE DATABASE i wykonanie odtwarzacza do punktu w czasie. |
Role SYSOPER i SYSDBA
Oracle mo偶e dokona膰 weryfikacji u偶ytkownik贸w pr贸buj膮cych pod艂膮czy膰 si臋 do bazy danych korzystaj膮c z informacji umieszczonej w bazie danych lub w pliku z has艂ami, do kt贸rych u偶ytkownicy musz膮 zosta膰 przypisani.
Dwie specjalne role, SYSOPER i SYSDBA, zawieraj膮 uprawnienia pozwalaj膮ce administratorom bazy na wykonanie nast臋puj膮cych akcji.
Rola
|
Opis |
SYSOPER |
Pozwala u偶ytkownikom na wykonanie STARTUP, SHUTDOWN, ALTER DATABASE OPEN/MOUNT, ALTER DATABASE BACKUP CONTROLFILE, ALTER TABLESPACE BEGIN/END BACKUP, ARCHIVE LOG AND RECOVER; rola SYSOPER zawiera r贸wnie偶 uprawnienie RESTRICTED SESSION. |
SYSDBA |
Zawiera wszystkie uprawnienia systemowe z opcj膮 administracji nimi (WITH ADMIN OPTION) oraz rol臋 SYSOPER; jedynie rola SYSDBA pozwala na wykonanie polecenia CREATE DATABASE i wykonanie odtwarzania do punktu w czasie |
Podsumowanie
Nadanie u偶ytkownikom uprawnie艅 dost臋pu do bazy i do obiekt贸w w bazie oraz udost臋pnienie im pewnych uprawnie艅 systemowych.
Kontrola DBA nad przywilejami .
Dostarczenie u偶ytkownikowi praw do wykonania pewnego typu operacji.
Umo偶liwienie i ograniczenie dost臋pu i zmian w danych.
Umo偶liwienie i ograniczenie mo偶liwo艣ci wykonania funkcji systemowych i zmian struktury bazy danych.
Nadanie praw pojedynczym u偶ytkownikom i rolom.
Nadanie praw wszystkim u偶ytkownikom (PUBLIC).
W艂asno艣ci roli
Mniej nadawania uprawnie艅.
Dynamiczna obs艂uga uprawnie艅.
Selektywna dost臋pno艣膰 uprawnie艅.
„艢wiadome” aplikacje.
Nazwana grupa powi膮zanych uprawnie艅.
Zadania
Pod艂膮cz si臋 jako sysdba, stw贸rz u偶ytkownika CEZARY/CEZARY, przypisz mu domy艣ln膮 przestrze艅 USER_DATA, tymczasow膮 przestrze艅 TEMPORARY_DATA, nadaj mu prawo pod艂膮czenia si臋 do bazy stw贸rz rol臋 SECURITY_ROLE
Nadaj roli SECURITY_ROLE wszystkie prawa potrzebne do zarz膮dzania uprawnieniami i uprawnienie do przegl膮dania wszystkich tabel (w Security Managerze)
Nadaj rol臋 SECURITY_ROLE u偶ytkownikowi CEZARY
Obejrzyj zapisy dotycz膮ce roli SECURITY_ROLE w perspektywach DBA_ROLE_PRIVS , DBA_ROLES, DBA_SYS_PRIVS ROLE_ROLE_PRIVS i ROLE_SYS_PRIVS
Pod艂膮cz si臋 jako CEZARY i obejrzyj perspektywy SESSION_ROLES, SESSION_PRIVS
Jako CEZARY utw贸rz rol臋 DEV_USER i nadaj jej prawa do tworzenia tabel, perspektyw, klastr贸w, sekwencji i synonim贸w (w Security Managerze)
Jako CEZARY nadaj rol臋 SECURITY_ROLE u偶ytkownikowi ZYGMUNT
Pod艂膮cz si臋 ZYGMUNT obejrzyj perspektywy USER_ROLE_PRIVS, USER_SYS_PRIVS
B臋d膮c pod艂膮czonym jako CEZARY utw贸rz rol臋 END_USER
B臋d膮c pod艂膮czonym jako ZYGMUNT nadaj roli END_USER prawa SELECT, UPDATE i INSERT na tabeli EMP
B臋d膮c pod艂膮czonym jako CEZARY nadaj te rol臋 u偶ytkownikowi WACEK
B臋d膮c pod艂膮czonym jako ZYGMUNT odbierz u偶ytkownikowi WACEK uprawnienie SELECT na tabeli EMP
Pod艂膮cz si臋 jako WACEK i sprawd藕, 偶e dzi臋ki roli END_USER u偶ytkownik
WACEK mo偶e nadal wykonywa膰 zapytania na ZYGMUNT.EMP
XVI.聽Obserwacja bazy danych
Cele
Lekcja ta wyja艣nia w jaki spos贸b korzysta膰 z obserwacji bazy danych do zbierania statystyk z dzia艂ania bazy oraz jak przegl膮da膰 i utrzymywa膰 wyniki obserwacji.
Na ko艅cu tej sekcji powiniene艣 potrafi膰
Okre艣li膰, kiedy obserwacja jest potrzebna.
艢ledzi膰 dost臋p do obiekt贸w bazy danych na poziomie polece艅 i systemu.
Monitorowa膰 opcje obserwacji w s艂owniku danych.
Przegl膮da膰 i utrzymywa膰 wyniki obserwacji.
Lekcja opcjonalna
Lekcja ta zawiera materia艂, kt贸ry jest specyficzny dla niekt贸rych instalacji i konfiguracji Oracle
Instruktor mo偶e dokona膰 wyboru materia艂u w zale偶no艣ci od potrzeb uczestnik贸w. Ca艂o艣膰 tekstu, 膰wicze艅 i rozwi膮za艅 zosta艂a tu zamieszczona do ewentualnego samodzielnego przestudiowania.
Przegl膮d
Monitorowanie i zapis wybranych akcji u偶ytkownik bazy danych przy pomocy obserwacji bazy.
Obserwacja (Auditing)
Badanie podejrzanych dzia艂a艅
Monitorowanie dzia艂ania bazy danych.
Zbieranie danych o dzia艂aniach w bazie.
Operacje obserwacji
Obserwacja polece艅 (Statement auditing).
Obserwacja uprawnie艅 (Privilege auditing).
Obserwacja obiekt贸w (Object auditing).
Zapis obserwacji (Audit Trail)
Ca艂a informacja gromadzona przez obserwacje bazy jest sk艂adowana w dzienniku obserwacji (audit trail).
Dziennik obserwacji jest wype艂niany, gdy w艂膮czone s膮 opcje obserwacji.
Rekomendacje obserwacji
Przy dobieraniu strategii obserwacji nale偶y rozwa偶y膰 nast臋puj膮ce wskazania.
Generalnie przy obserwacji
Nale偶y okre艣li膰 cel obserwacji.
Nale偶y obserwowa膰 konserwatywnie.
Podczas obserwacji zwi膮zanej z podejrzanymi dzia艂aniami w bazie danych nale偶y
Obserwowa膰 generalnie w celu okre艣lenia jakie konkretnie akcje wymagaj膮 g艂臋bszego zbadania a nast臋pnie obserwowa膰 jedynie te akcje.
Zabezpieczy膰 dziennik obserwacji.
Podczas obserwacji w celu gromadzenia informacji historycznych o dzia艂aniu bazy danych nale偶y
Obserwowa膰 tylko istotne z naszego punktu widzenia dzia艂ania.
Archiwizowa膰 i czy艣ci膰 dziennik obserwacji.
W艂膮czanie obserwacji
Chocia偶 polecenia AUDIT i NOAUDIT mog膮 by膰 u偶yte w dowolnej chwili, zapis do dziennika obserwacji b臋dzie odbywa膰 si臋 jedynie, gdy DBA ustawi parametr inicjalizacji AUDIT_TRAIL w pliku startowym.
Sk艂adnia:
AUDIT_TRAIL = warto艣膰 |
gdzie warto艣膰 mo偶e by膰 jedn膮 z nast臋puj膮cych opcji:
DB w艂膮cza obserwacj臋 bazy i kieruje wszystkie zapisy do dziennika obserwacji (sys.aud$).
OS w艂膮cza obserwacj臋 bazy i kieruje wszystkie zapisy do dziennika obserwacji w systemie operacyjnym (je艣li system operacyjny dopuszcza to).
NONE wy艂膮cza obserwacj臋 (jest to warto艣膰 domy艣lna).
Po zmianie parametru inicjalizacyjnego AUDIT_TRAIL, instancja musi zosta膰 zatrzymana i wystartowana ponownie, by nowa warto艣膰 zacz臋艂a obowi膮zywa膰.
Je艣li obserwacja nie jest potrzebna, nale偶y uruchomi膰 skrypt catnoaud.sql. kt贸ry usunie tablice i perspektywy s艂ownika danych u偶ywane do obserwacji. Je艣li nast臋pnie obserwacja b臋dzie potrzebna, uruchomienie skryptu cataudit.sql zainstaluje ponownie potrzebne tablice i perspektywy s艂ownika danych.
Miejsce gdzie znajduj膮 si臋 skrypty cataudit.sql i catnoaudit.sql zale偶y od systemu operacyjnego.
Zdarzenia zawsze obserwowane
Niezale偶nie od tego czy obserwacja bazy danych jest w艂膮czona, czy nie, Serwer Oracle zawsze zapisuje pewne akcje:
Start instancji
Zapisywana jest informacja o u偶ytkowniku w systemie operacyjnym, kt贸ry startuje instancj臋, identyfikatorze terminala, znacznik daty i czasu oraz czy obserwacja bazy danych zosta艂a w艂膮czona czy wy艂膮czona.
Zamkni臋cie instancji
Zapisywana jest informacja o u偶ytkowniku w systemie operacyjnym, kt贸ry zamyka instancj臋, identyfikatorze terminala, znacznik daty i czasu.
Pod艂膮czenie si臋 do bazy danych z uprawnieniami administracyjnymi
Zapisywana jest informacja o u偶ytkowniku w systemie operacyjnym, kt贸ry pod艂膮cza si臋 do Oracle jako sysoper lub sysdba - w celu sprawdzenia kont u偶ytkownik贸w (w systemie operacyjnym) posiadaj膮cych uprawnienia administracyjne.
Ogniskowanie obserwacji
Po w艂膮czeniu obserwacji, b臋dziemy chcieli zogniskowa膰 jak si臋 tylko da. Dzi臋ki temu zminimalizowana zostanie ilo艣膰 informacji zapisywanej do dziennika. Je艣li obserwacja jest zbyt og贸lna, dziennik obserwacji mo偶e bardzo szybko zape艂ni膰 si臋 nie istotnymi informacjami.
Dla ka偶dej obserwacji nale偶y ogranicza膰 zakres poprzez:
Obserwowanie wykona艅 specyficznych polece艅 SQL zako艅czonych sukcesem lub pora偶k膮.
Zbieranie informacji dla sesji (BY SESSION) lub do wywo艂ania (BY ACCESS).
Obserwacja polece艅 i uprawnie艅
Obserwacja tego typu dotyczy dzia艂a艅 wszystkich u偶ytkownik贸w bazy lub tylko dzia艂a艅 pewnej listy u偶ytkownik贸w.
Obserwacja obiekt贸w
Wybi贸rcza obserwacja dzia艂a艅 dotycz膮cych jedynie podanych obiekt贸w.
Opcje obserwacji obiekt贸w s膮 zawsze ustawiane dla wszystkich u偶ytkownik贸w bazy.
Nie mo偶na ustawi膰 ich jedynie dla pewnej listy u偶ytkownik贸w.
Obserwacja nie jest realizowana dla po艂膮cze艅 CONNECT INTERNAL i dla po艂膮cze艅 jako u偶ytkownik sys.
Uwaga: Opcje obserwacji polece艅 i uprawnie艅 podane w poleceniu AUDIT odnosz膮 si臋 do nast臋puj膮cych sesji, a nie do sesji bie偶膮cych.
Do wykonania polece艅 AUDIT i NOAUDIT wymagane jest posiadanie przywileju AUDIT SYSTEM.
Je艣li pominie si臋 klauzul臋 WHENEVER, Serwer Oracle b臋dzie obserwowa艂 zar贸wno udane jak i nie udane pr贸by.
Kiedy obserwuje si臋 dzia艂ania nieudane, zapis obserwacji nie jest generowany dla polece艅 niepoprawnych (np. z b艂臋dem sk艂adniowym).
Obserwowanie polece艅
Mo偶liwe jest wybi贸rcze obserwowanie powi膮zanych grup polece艅, kt贸re mieszcz膮 si臋 w dw贸ch kategoriach.
Kategorie obserwowanych polece艅
Obserwacja polece艅 DDL odnosz膮cych si臋 do pewnego typu struktur bazy danych lub obiekt贸w.
Obserwacja polece艅 SELECT i DML odnosz膮cych si臋 do pewnego typu struktur bazy danych lub obiekt贸w.
Wskaz贸wki:
Polecenia SQL wewn膮trz blok贸w PL/SQL s膮 obserwowane osobno w czasie wykonywania bloku.
Instancja b臋dzie obserwowa艂a polecenia bezpo艣rednio powi膮zane z u偶ytkownikami - nie b臋d膮 mog艂y by膰 obserwowane akcje w bazie odleg艂ej.
Do zapami臋tania warto艣ci zmiennej w tabeli nale偶y wykorzysta膰 wyzwalacz.
Wykonanie polecenia zako艅czone niepowodzeniem mo偶e by膰 obserwowane, je艣li niepowodzenie nast膮pi艂o z powodu braku autoryzacji lub odwo艂ania si臋 do nieistniej膮cego obiektu.
Wykonanie polecenia zako艅czone niepowodzeniem nie jest obserwowane je艣li samo polecenie SQL by艂o niepoprawne.
Specyfikowanie obserwacji polece艅
Obserwacje polece艅 i jej opcje specyfikuje si臋 poleceniem AUDIT
Sk艂adnia:
gdzie:
polecenie okre艣la polecenia SQL, kt贸rych obserwacja ma mie膰 miejsce.
BY u偶ytkownik okre艣la, i偶 tylko polecenia SQL wydane przez podanego u偶ytkownika maj膮 by膰 obserwowane. Je艣li klauzula ta zostanie pomini臋ta, Serwer Oracle b臋dzie obserwowa艂 wszystkich u偶ytkownik贸w.
BY SESSION powoduje, i偶 Serwer Oracle b臋dzie generowa艂 do dziennika tylko jeden rekord dla danego obiektu bazy danych na ka偶d膮 sesj臋, niezale偶nie od tego ile polece艅 SQL tego samego typu zostanie wydanych.
BY ACCESS powoduje, i偶 Serwer Oracle b臋dzie generowa艂 do dziennika zapis za ka偶dym razem, gdy obserwowane polecenie zostanie wykonane. Je艣li podamy opcje obserwacji polece艅 lub uprawnie艅 dotycz膮cych J臋zyka Definicji Danych (DDL), Oracle b臋dzie wykonywa艂 obserwacj臋 dla wywo艂a艅, niezale偶nie od tego jakie by艂o zlecenie. Dla polece艅 z poza grupy DDL domy艣lna jest klauzula BY SESSION.
WHENEVER SUCCESSFUL okre艣la, i偶 obserwacja ma si臋 odbywa膰 jedynie dla poprawnie zako艅czonych polece艅 SQL.
NOT okre艣la, i偶 obserwacja ma si臋 odbywa膰 jedynie dla polece艅 SQL zako艅czonych niepowodzeniem.
Przyk艂ad
Obserwacja polece艅 CREATE/ALTER/DROP USER, zako艅czonych sukcesem lub nie, dla wywo艂ania (by access) w celu wykrycia modyfikacji atrybut贸w u偶ytkownika.
SQL> AUDIT user BY ACCESS |
W艂膮czenie obserwacje polece艅 przy u偶yciu skr贸tu CONNECT - w celu rejestrowania wszystkich po艂膮cze艅 do bazy danych.
SQL> AUDIT connect |
Zapytanie na DBA_STMT_AUDIT_OPTS.
SQL> SELECT user_name, audit_option, success, failure 2> FROM dba_stmt_audit_opts; |
USER_NAME AUDIT_OPTION SUCCESS FAILURE
------------------ ---------------------------- ---------- ----------
USER BY ACCESS BY ACCESS
CREATE SESSION BY ACCESS BY ACCESS
Wszystkie opcje obserwacji polece艅 s膮 podane w perspektywie STMT_AUDIT_OPTION_MAP
Obserwowanie uprawnie艅
Za pomoc膮 obserwacji uprawnie艅 mo偶liwa jest selektywna obserwacja polece艅 wydanych przez uprawnionych do ich wykonania. Obserwacja uprawnie艅 mo偶e by膰 szeroka i obejmowa膰 wszystkich u偶ytkownik贸w bazy danych lub te偶 zogniskowana na wybranych u偶ytkownikach. Obserwacja uprawnie艅 jest sk艂adniowo i funkcjonalnie bardzo podobna do obserwacji polece艅. Powinna by膰 bardzo wybi贸rcza, minimalizuj膮ca ilo艣膰 informacji zapisywanej do dziennika obserwacji.
Obserwacja uprawnie艅
Mo偶liwa jest obserwacja ka偶dego z uprawnie艅 systemowych.
Istnieje ponad 80 r贸偶nych uprawnie艅 systemowych, kt贸re mog膮 by膰 obserwowane.
Specyfikowanie obserwacji uprawnie艅
Sk艂adnia
gdzie:
przywilej_systemowy okre艣la przywilej systemowy kt贸rego wykorzystanie b臋dzie obserwowane.
BY u偶ytkownik okre艣la, i偶 tylko polecenie SQL wydane przez podanego u偶ytkownika maj膮 by膰 obserwowane. Je艣li klauzula ta zostanie pomini臋ta Serwer Oracle b臋dzie obserwowa艂 wszystkich u偶ytkownik贸w.
BY SESSION powoduje, i偶 Serwer Oracle b臋dzie generowa艂 do dziennika tylko jeden rekord na ka偶d膮 sesj臋, niezale偶nie od tego ile polece艅 SQL tego samego typu zostanie wydanych.
BY ACCESS powoduje, i偶 Serwer Oracle b臋dzie generowa艂 do dziennika zapis za ka偶dym razem, gdy obserwowane polecenie zostanie wykonane. Je艣li podamy opcj臋 obserwacji polece艅 lub uprawnie艅 dotycz膮cych J臋zyka Definicji (DDL). Oracle b臋dzie wykonywa艂 obserwacj臋 dla wywo艂a艅, niezale偶nie od tego jakie by艂o zlecenie. Dla polece艅 spoza grupy DDL domy艣lna jest klauzula BY SESSION.
WHENEVER SUCCESSFUL okre艣la, i偶 obserwacja ma si臋 odbywa膰 jedynie dla poprawnie zako艅czonych polece艅 SQL.
NOT okre艣la, i偶 obserwacja ma si臋 odbywa膰 jedynie dla polece艅 SQL zako艅czonych niepowodzeniem.
Przyk艂ady
Obserwacje pr贸b scotta, udanych i nieudanych, tworzenia tabel i indeks贸w we w艂asnym schemacie.
SQL> AUDIT create table BY scott BY ACCESS; |
Obserwacja zako艅czonych powodzeniem pr贸b zmiany (ALTER) tabel, procedur, funkcji lub pakiet贸w dokonywanych przez scotta w dowolnym schemacie.
SQL> AUDIT alter any table, alter any procedure 2>聽BY scott BY ACCESS 3>聽WHENEVER SUCCESSFUL; |
Zapytanie na DBA_PRIV_AUDIT_OPIS.
SQL> SELECT * FROM dba_priv_audit_opts; |
USER_NAME PRIVILEGE SUCCESS FAILURE
------------------ ---------------------------- ---------- ----------
SCOTT CREATE TABLE BY ACCESS BY ACCESS
SCOTT ALTER ANY TABLE BY ACCESS NOT SET
SCOTT ALTER ANY PROCEDURE BY ACCESS NOT SET
Obserwowanie obiekt贸w
Do selektywnej obserwacji polece艅 wykonywanych na podanych obiektach danego schematu korzystamy z obserwacji obiekt贸w. Obserwacja obiekt贸w b臋dzie rejestrowa艂a wszystkie polecenia DML i zapytania dla ka偶dego obiektu dowolnego schematu, a dodatkowo wykonywane na tym obiekcie polecenia GRANT i REVOKE.
Obserwowane obiekty
Tabele
Perspektywy
Sekwencje
Pakiety
Pojedyncze procedury sk艂adowane w bazie
Pojedyncze funkcje sk艂adowane w bazie
Procedury w pakietach nie mog膮 by膰 obserwowane osobno.
Poniewa偶 perspektywy i procedury mog膮 odwo艂ywa膰 si臋 do innych obiekt贸w w bazie, efektem korzystania z nich mo偶e by膰 pojawienie si臋 kilku zapis贸w z obserwacji.
Opcje obserwacji obiekt贸w s膮 zawsze ustawiane dla wszystkich u偶ytkownik贸w bazy danych. Nie ma mo偶liwo艣ci ustawienia ich dla podanej listy u偶ytkownik贸w.
Opcje obserwacji obiekt贸w
Opcja pakietu/obiektu |
Tabela |
Perspektywa |
Sekwencja |
Snapshot |
Procedura |
ALTER |
X |
|
X |
|
|
AUDIT |
X |
X |
X |
|
X |
COMMENT |
X |
X |
|
|
|
DELETE |
X |
X |
|
|
|
EXECUTE |
|
|
|
|
X |
GRANT |
X |
X |
X |
|
X |
INDEX |
X |
|
|
|
|
INSERT |
X |
X |
|
|
|
LOCK |
X |
X |
|
|
|
RENAME |
X |
X |
|
|
X |
SELECT |
X |
X |
X |
X |
|
UPDATE |
X |
X |
|
|
|
Specyfikowanie obserwacji obiekt贸w
Obserwacj臋 obiekt贸w i jej opcje specyfikuje si臋 poleceniem AUDIT
Sk艂adnia:
gdzie:
akcja_na_obiekcie okre艣la konkretn膮 operacj臋 do obserwowania.
obiekt okre艣la obserwowany obiekt. Obiektem tym mo偶e by膰 jedna lub wi臋c tabel, perspektyw, sekwencji, procedur, pakiet贸w, funkcji lub „migawek”. Je艣li pomini臋ty zostanie schemat, Serwer Oracle przyjmie, i偶 chodzi o schemat aktualnego u偶ytkownika.
DEFAULT okre艣la, 偶e opcje obserwacji b臋d膮 przyjmowane domy艣lnie dla wszystkich tworzonych w przysz艂o艣ci obiekt贸w.
BY SESSION powoduje, i偶 Serwer Oracle b臋dzie generowa艂 do dziennika tylko jeden rekord na ka偶d膮 sesj臋, niezale偶nie od tego ile polece艅 SQL tego samego typu zostanie wydanych.
BY ACCESS powoduje, i偶 Serwer Oracle b臋dzie generowa艂 do dziennika zapis za ka偶dym razem, gdy obserwowane polecenie zastanie wykonane. Domy艣ln膮 klauzul膮 jest BY SESSION.
WHENEVER SUCCESSFUL okre艣la, i偶 obserwacja ma si臋 odbywa膰 jedynie dla poprawnie zako艅czonych polece艅 SQL.
NOT okre艣la, i偶 obserwacja ma si臋 odbywa膰 jedynie dla polece艅 SQL zako艅czonych niepowodzeniem.
Obiekt musi nale偶e膰 do schematu wydaj膮cego polecenie lub wydaj膮cy to polecenie musi posiada膰 przywilej AUDIT ANY.
Jako opcja obserwacji obiekt贸w mo偶e by膰 u偶yty skr贸t ALL. ALL oznacza obserwacj臋 wszystkich opcji maj膮cych dla danego typu obiektu sens.
Przyk艂ady
W艂膮czenie obserwacji EXECUTE dla procedury CHANGE_PRICE, jeden raz dla ka偶dej sesji.
SQL> AUDIT EXECUTE ON change_price BY SESSION; |
W艂膮czenie obserwacji DELETE na tabeli EMP, dla ka偶dej pr贸by wykonania polecenia.
SQL> AUDIT DELETE ON emp BY ACCESS; |
W艂膮czenie obserwacji GRANT na tabeli EMP. Zapis pr贸b zako艅czonych powodzeniem.
SQL> AUDIT GRANT ON emp BY SESSION WHENEVER SUCCESSFUL; |
Opcje te s膮 u偶ywane g艂贸wnie do obserwacji dzia艂a艅 podejrzanych i nieuprawnionych.
Zapytanie na USER_OBJ_AUDIT_OPTS pokazuje jakie opcje obserwacji zosta艂y ustawione.
SQL> SELECT * FROM user_obj_audit_opts; |
OBJECT_NAME TYPE ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE CRE REA WRI
------------- ---------- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
CUSTOMER TABLE -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/-
DEPT TABLE -/- -/- -/- A/A S/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/-
EMP TABLE -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/-
CHANGE_PRICE PROCEDURE -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- S/S
…
W艂膮czenie obserwacji wszystkich polece艅 dotycz膮cych tabeli DEPT.
SQL>AUDIT ALL ON dept |
Wy艣wietlenie wyniku polecenia z USER_OBJ_AUDIT_OPTS.
SQL> SELECT * FROM user_obj_audit_opts 2>聽WHERE object_name = `DEPT' |
OBJECT_NAME TYPE ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE CRE REA WRI
------------- ---------- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
DEPT TABLE S/S S/S S/S S/S S/S S/S S/S S/S S/S S/S S/S S/S -/- -/- S/S S/S
Za pomoc膮 klauzuli DEFAULT mog膮 by膰 definiowane domy艣lne opcje obserwacji obiekt贸w maj膮ce obowi膮zywa膰 dla nowo tworzonych obiekt贸w.
Domy艣lne opcje obserwacji obiekt贸w
Ustawia si臋 je przy wykorzystaniu s艂owa kluczowego DEFAULT.
Opcje te przypisywane ka偶demu z nowo utworzonych obiekt贸w.
Mo偶liwa jest zmiana opcji obserwacji za pomoc膮 jawnego ich ustawienia dla danego obiektu.
Ka偶da zmiana w opcjach domy艣lnych obowi膮zuje dla obiekt贸w, kt贸re b臋d膮 dopiero tworzone i nie jest odzwierciedlana w ustawieniach opcji dla 偶adnego ju偶 z istniej膮cych obiekt贸w.
Do ustawienia domy艣lnych opcji obserwacji potrzebne jest uprawnienie systemowe AUDIT SYSTEM.
Przyk艂ad
W艂膮czenie opcji obserwacji obiekt贸w ALTER, SELECT i RENAME dla wszystkich jeszcze nie utworzonych obiekt贸w.
SQL>AUDIT alter, select, rename ON default; |
W poprzednim przyk艂adzie
Je艣li utworzy si臋 now膮 tabel臋, to b臋d膮 dla niej obserwowane opcje ALTER, SELECT i RENAME.
Je艣li utworzona zostanie perspektywa, to b臋d膮 dla niej obserwowane opcje SELECT i RENAME.
Je艣li zostanie utworzona sekwencja, to b臋d膮 dla niej obserwowane opcja SELECT.
Je艣li zostanie utworzona procedura, funkcja lub pakiet, to b臋dzie dla nich obserwowana opcja RENAME.
Wy艂膮czanie obserwacji uprawnie艅 i polece艅
Obserwacj臋 uprawnie艅 i polece艅 oraz ich opcje wy艂膮cza si臋 poleceniem NOAUDIT.
Sk艂adnia:
gdzie:
polecenie specyfikuje polecenie, kt贸re nie ma by膰 d艂u偶ej obserwowane.
przywilej_systemowy specyfikuje przywilej systemowy, kt贸rego wykorzystanie nie ma by膰 d艂u偶ej obserwowane.
BY u偶ytkownik zatrzymuje obserwacj臋 polece艅 SQL podanych u偶ytkownik贸w (w ich nast臋pnych sesjach). Je艣li klauzula ta zostanie pomini臋ta, Serwer Oracle zaprzestaje obserwacji wszystkich u偶ytkownik贸w.
WHENEVER SUCCESSFUL zatrzymuje obserwacj臋 operacji zako艅czonych sukcesem
NOT zatrzymuje obserwacj臋 polece艅, kt贸rych wynikiem by艂 b艂膮d.
Do wykonywania tego polecenia potrzebne jest posiadanie przywileju AUDIT SYSTEM.
Przyk艂ad
Wy艂膮czenie obserwacji scotta dotycz膮cej wszystkich jego pr贸b (udanych i nie) tworzenia tabel i indeks贸w w swoim schemacie.
SQL> NOAUDIT create table BY scott; |
Wy艂膮czenie obserwacji udanych pr贸b tworzenia tabel, procedur, funkcji i pakiet贸w podejmowanych przez scotta w dowolnym schemacie.
SQL> NOAUDIT alter any table, alter any procedure 2>聽BY scott 3>聽WHENERVER SUCCESSFUL; |
Wy艂膮czanie obserwacji obiekt贸w
Obserwacj臋 obiekt贸w wy艂膮cza si臋 wersj膮 polecenia NOAUDIT.
Sk艂adnia:
gdzie:
akcja_na_obiekcie okre艣la, jakie typy obserwacji maj膮 zosta膰 zatrzymane.
ON poprzedza nazw臋 obiektu, dla kt贸rego zaprzestajemy obserwacji. Je艣li pomini臋ty zostanie schemat, Serwer Oracle b臋dzie zak艂ada艂, i偶 chodzi o obiekt aktualnego u偶ytkownika.
WHENEVER SUCCESSFUL zatrzymuje obserwacj臋 dzia艂a艅 zako艅czonych sukcesem.
NOT zatrzymuje obserwacj臋 dzia艂a艅, dla kt贸rych Serwer Oracle zwr贸ci艂 b艂膮d.
Obiekt, dla kt贸rego obserwacj臋 chcemy zatrzyma膰 musi nale偶e膰 do naszego w艂asnego schematu lub te偶 musimy posiada膰 przywilej systemowy AUDIT ANY.
Przyk艂ad
Wy艂膮czenie obserwacji EXECUTE dla procedury CHANGE_PRICE.
SQL> NOAUDIT execute ON change_price; |
Wy艂膮czenie obserwacji DELETE na tabeli EMP.
SQL> NOAUDIT delete ON emp; |
Wy艂膮czenie obserwacji GRANT na tabeli EMP, z opcj膮 WHENEVER SUCCESSFUL.
SQL> NOAUDIT grant ON emp 2> WHENEVER SUCCESSFUL; |
Polecenie NOAUDIT usuwa wszystkie znajduj膮ce si臋 w s艂owniku danych zapisy dotycz膮ce obserwacji tego obiektu.
Dziennik obserwacji
Dziennik obserwacji zawiera zapisy generowane przez obserwacj臋 polece艅, uprawnie艅 i obiekt贸w. Dziennik ten stanowi tabela s艂ownika danych SYS.AUD$.
Ka偶dy wiersz w dzienniku obserwacji zawiera informacje o:
U偶ytkowniku, kt贸ry wykona艂 polecenie.
Kodzie akcji (numerycznym), kt贸ry identyfikuje typ polecenia i wykorzystanie uprawnie艅.
Obiektach, do kt贸rych polecenie odwo艂ywa艂o si臋.
Czas i dat臋 wydania polecenia.
Zapisy obserwacji dokonywane s膮 w czasie fazy wykonywania (execute phase) polecenia.
Wskaz贸wki:
Obserwacja jest niezale偶na od transakcji. Nawet je艣li transakcja zostanie wycofana, zapisy z obserwacji pozostaj膮.
Obserwacja w trybie „BY ACCESS” zapisuje rekord do dziennika obserwacji za ka偶dym razem, gdy podana akcja zostanie podj臋ta.
Obserwacja w trybie „BY SESSION” (czas pomi臋dzy pod艂膮czeniem si臋 i od艂膮czeniem) zapisuje do dziennika obserwacji tylko jeden rekord dotycz膮cy operacji na danym obiekcie w czasie jednej sesji.
Monitorowanie dziennika obserwacji
Nale偶y monitorowa膰 rozmiar i rozrost dziennika obserwacji w celu oszcz臋dzenia miejsca na dysku i zapewnienia kontynuacji dzia艂ania bazy danych. Kiedy dziennik zostanie zape艂niony, nowe zapisy nie mog膮 by膰 do niego wstawiane i obserwowane polecenia b臋d膮 zwraca艂y b艂臋dy.
Dziennik obserwacji ro艣nie zale偶nie od:
Ilo艣ci obserwowanych opcji.
Cz臋sto艣ci wykonywania obserwowanych polece艅.
Maksymalny rozmiar dziennika jest definiowany w momencie tworzenia bazy danych. Plik wykonywany przy tworzeniu bazy, sqlbsq, zawiera polecenie CREATE dla tabeli AUD$.
Je艣li dziennik przepe艂ni si臋, nie mo偶na wstawi膰 wi臋cej zapis贸w z obserwacji i obserwowane polecenia nie b臋d膮 mog艂y by膰 wykonywane. Wszystkim pr贸buj膮cym wykona膰 te polecenia b臋d膮 zg艂aszane b艂臋dy. Zanim polecenia te b臋d膮 mog艂y by膰 wykonywane, konieczne jest wtedy zwolnienie miejsca w dzienniku obserwacji.
Nale偶y upewni膰 si臋, i偶 dziennik obserwacji nie ro艣nie zbyt gwa艂townie.
Kontrolowanie rozrostu dziennika obserwacji
W艂膮czanie obserwacji jedynie wtedy, gdy jest to potrzebne.
Selektywne w艂膮czanie opcji do obserwowania.
艢cis艂a kontrola obserwacji obiekt贸w.
Ograniczenie obserwacji obiekt贸w
Niech jedynie „Security Administrator” posiada prawa do obserwowania obiekt贸w.
Niech „Security Administrator” posiada wszystkie obiekty schematu.
Niech wszystkie obiekty znajduj膮 si臋 w schematach, dla kt贸rych nie ma aktualnych u偶ytkownik贸w (np. u偶ytkownicy ci nie posiadaj膮 przywileju CREATE SESSION).
Aby obserwowa膰 obiekt, trzeba albo by膰 jego w艂a艣cicielem, albo posiada膰 przywilej AUDIT ANY. Dlatego, w celu zapewnienia, 偶e „Security Administrator” jest jedynym u偶ytkownikiem, kt贸ry mo偶e obserwowa膰 obiekty, nale偶y przestrzega膰 dw贸ch zasad:
Jedynie „Security Administrator” posiada przywilej AUDIT ANY.
呕aden inny u偶ytkownik nie posiada swoich w艂asnych obiekt贸w.
Obs艂uga dziennika obserwacji
Obs艂uga dziennika obserwacji, polega g艂贸wnie na periodycznym usuwaniu zapis贸w obserwacji i zerowaniu dziennika.
Zapisy z dziennika nale偶y usuwa膰 poprzez
Usuni臋cie wszystkich rekord贸w.
Usuni臋cie wybranych rekord贸w.
Archiwizacj臋 rekord贸w obserwacji do innej tabeli.
Archiwizacj臋 zapis贸w obserwacji w systemie operacyjnym.
Przyk艂ad
Usuni臋cie z dziennika obserwacji wszystkich rekord贸w.
SQL> TRUNCATE TABLE sys.aud$; |
Usuni臋cie z dziennika wszystkich rekord贸w sprzed trzech miesi臋cy.
SQL> DELETE FROM sys.aud$ 2>聽WHERE TIMESTAMP< SYSDATE-90; |
Archiwizacja zapis贸w obserwacji do pliku w systemie operacyjnym. Korzystamy z narz臋dzia Export w trybie tabel. Nale偶y pami臋ta膰, 偶e nast膮pi eksport ca艂ej tabeli. W najprostszej wersji, polecenie poni偶sze wyeksportuje tabel臋 AUD$ do pliku expdat.dmp.
EXP USERID = sys/password TABLES = (AUD$) FILE = expdat.dmp |
Narz臋dzia Export nie zmieni w 偶aden spos贸b tabeli SYS.AUD$, a wi臋c nadal nale偶y obci膮膰 dziennik powt贸rze艅.
Je艣li w dzienniku jest wiele nieu偶ywanych ekstent贸w, nale偶y obci膮膰 go (truncate) aby je zwolni膰.
Skopiuj rekordy, kt贸re maj膮 zosta膰 zachowane do tabeli tymczasowej lub wyeksportuj dziennik na plik.
Pod艂膮cz si臋 do bazy jako plik.
Obetnij SYS>AUD$ u偶ywaj膮c polecenia TRUNCATE.
Za艂aduj rekordy zarchiwizowane w kroku 1.
Kopi臋 dziennika nale偶y robi膰 jedynie gdy istniej膮 zapisy, kt贸re trzeba zachowa膰; w przeciwnym przypadku mo偶na omin膮膰 kroki 1 i 4.
SYS.AUD$ jest jednym z niewielu obiekt贸w nale偶膮cych do sys'a, kt贸re mog膮 by膰 modyfikowane bezpo艣rednio.
Rekordy z dziennika obserwacji mog膮 by膰 usuni臋te przez u偶ytkownika sys lub innego posiadaj膮cego prawo DELETE ANY TABLE.
Je艣li obserwowane s膮 po艂膮czenia do bazy danych i dziennik przepe艂ni si臋, u偶ytkownicy czekaj膮 nie mog膮c pod艂膮czy膰 si臋. Wtedy administrator musi pod艂膮czy膰 si臋 jako sys (pod艂膮czenia jako sys nie s膮 obserwowane) i zrobi膰 miejsce w dzienniku.
Je艣li dziennik obserwacji jest przepe艂niony, obserwowane polecenia nie mog膮 by膰 wykonywane, poniewa偶 nie mo偶e zosta膰 zapisana informacja z obserwacji
Ograniczenia pami臋ci (Storage Limitations)
Je艣li zape艂ni si臋 przestrze艅 tabel, Serwer Oracle nie mo偶e zaalokowa膰 nast臋pnego ekstentu 偶膮danego rozmiaru. Administrator musi powi臋kszy膰 przestrze艅 tabel poprzez dodanie nowego pliku.
Je艣li dziennik obserwacji dojdzie do maksymalnej dozwolonej liczby ekstent贸w, administrator musi ponownie utworzy膰 tabele podaj膮c wi臋kszy limit ekstent贸w.
Przy obserwacji podejrzanych dzia艂a艅, administrator powinien chroni膰 integralno艣膰 dziennika obserwacji.
Przyk艂ad
Obserwacja dziennika obserwacji.
SQL>聽AUDIT insert, update, delete 2>聽ON sys.aud$ 3>聽BY ACCESS; |
W celu ochrony dziennika obserwacji przed nieuprawnionymi usuni臋ciami zapis贸w, jedynie administrator powinien dysponowa膰 uprawnieniem systemowym DELETE ANY TABLE.
Wy艣wietlanie informacji o obserwacji
Predefiniowane perspektywy na dzienniku obserwacji tworzone s膮 przez skrypt cataudit.sql.
Aby usun膮膰 wszystkie te perspektywy ze s艂ownika danych, nale偶y uruchomi膰 skrypt catnoaud.sql.
Informacje z obserwacji mo偶na wy艣wietli膰 korzystaj膮c z predefiniowanych perspektyw dziennika obserwacji.
Predefiniowane perspektywy dziennika obserwacji
Perspektywy dziennika obserwacji |
Kr贸tki opis
|
STMT_AUDIT_OPTION_MAP |
Mapowanie nr opcji obserwacji i jej nazwy. |
AUDIT_ACTIONS |
Mapowanie nr akcji i jej nazwy. |
ALL_DEF_AUDIT_OPTS |
Domy艣lne opcje obserwacji. |
DBA_STMT_AUDIT_OPTS |
Opcje obserwacji systemu (polece艅). |
DBA_PRIV_AUDIT_OPTS |
Opcje obserwacji uprawnie艅. |
DBA_OBJ_AUDIT_OPTS |
Opcje obserwacji obiekt贸w. |
USER_OBJ_AUDIT_OPTS |
Opcje obserwacji obiekt贸w. |
DBA_AUDIT_TRAIL |
Wszystkie zapisy obserwacji. |
USER_AUDIT_TRAIL |
Zapisy obserwacji dla danego u偶ytkownika. |
DBA_AUDIT_SESSION |
Wszystkie zapisy o pocz膮tkach i ko艅cach sesji. |
USER_AUDIT_SESSION |
Pocz膮tki i ko艅ce sesji u偶ytkownika. |
DBA_AUDIT_STATEMENT |
Wszystkie zapisy dotycz膮ce obserwacji dla opcji DBA. |
USER_AUDIT_STSTEMENT |
Jak wy偶ej, lecz dla aktualnego u偶ytkownika. |
DBA_AUDIT_OBJECT |
Wszystkie zapisy dotycz膮ce obiekt贸w. |
USER_AUDIT_OBJECT |
Jak wy偶ej, lecz dotycz膮ce obiekt贸w aktualnego u偶ytkownika. |
DBA_AUDIT_EXISTS |
Wszystkie zapisy dla EXISTS/NOT EXISTS. |
Przyk艂ad
Obserwacja usuwania wierszy dla konkretnej tabeli.
SQL> CONNECT system/password; SQL> AUDIT delete ON scott.emp BY SESSION WHENEVER SUCCESSFUL; SQL> CONNECT adams/wood; SQL> DELETE scott.emp WHERE empno = 1111; SQL> CONNECT scott/tiger SQL> DELETE emp WHERE empno = 1112; SQL> CONNECT system/password SQL> DELETE scott.emp WHERE empno = 1113; |
Wydruk z dziennika obserwacji dotycz膮cy poprzednich polece艅 mog艂yby wygl膮da膰 nast臋puj膮co:
SQL> SELECT username, 2> TO_CHAR (timestamp, `DD-MON-YY') 3> owner, obj_name, action_name, 4> returncode, priv_used 5> FROM sys . dba_audit_trail 6> WHERE action_name = `DELETE'; |
USERNAME TIMESTAMP OWNER OBJ_NAME ACTION_NAME RETURNCODE PRIV_USED
-------- ------------ ------ --------- ----------- ---------- -----------
ADAMS 15-SEP-92 SCOTT EMP DELETE 0 DELETE
SCOTT 15-SEP-92 SCOTT EMP DELETE 0
SYSTEM 15-SEP-92 SCOTT EMP DELETE 0 DELETE ANY TABLE
Poniewa偶 scott jest w艂a艣cicielem obiektu, nie potrzebuje on specjalnych uprawnie艅 do wykonania polecenia DELETE. Jednak system skorzysta艂 z przywileju DELETE ANY TABLE, a adam z przywileju DELETE.
Podsumowanie
Rejestracja dzia艂a艅 w bazie danych za pomoc膮 obserwacji.
Typy Obserwacji
Polecenie (Statement).
Uprawnienie (Privilege).
Obiekty (Object).
Wykorzystanie obserwacji
Badanie podejrzanych dzia艂a艅.
Monitorowanie dzia艂a艅 w bazie danych.
Zbieranie danych o dzia艂aniach w bazie danych.
Dziennik obserwacji
Wykorzystanie perspektyw s艂ownika danych przy dost臋pie do dziennika
Monitorowanie rozmiaru dziennika
Periodyczne usuwanie rekord贸w i obcinanie dziennika
Zadania
W艂膮cz opcje obserwacji, kt贸re pozwol膮 sprawdzi膰, 偶e kto pr贸buje pod艂膮czy膰 si臋 do bazy (zar贸wno udane jak i nieudane pr贸by)
Jakie perspektywy nale偶y obejrze膰, aby sprawdzi膰, czy zosta艂y ustawione poprawne opcje?
Spr贸buj pod艂膮czy膰 si臋 do bazy jako WACEK/PIOTREK
Pod艂膮cz si臋 do bazy jako WACEK/WACEK
Pod艂膮cz si臋 jako sysdba i sprawd藕 wyniki obserwacji w perspektywie DBA_AUDIT_TRAIL. Gdzie mo偶na zobaczy膰, kt贸re pr贸by zako艅czy艂y si臋 niepowodzeniem?
Ustaw odpowiednie opcje obserwacji, aby monitorowa膰 wszystkie udane modyfikacje tabeli EMP u偶ytkownika ZYGMUNT
Pod艂膮cz si臋 jako WACEK i zmodyfikuj tabel臋 EMP w schemacie ZYGMUNTA, obejrzyj zapisy w dzienniku informacji
U偶ytkownik WACEK cz臋sto tworzy, modyfikuje struktur臋 i usuwa tabele. Jak monitorowa膰 to, co robi u偶ytkownik WACEK? W艂膮cz odpowiednie opcje obserwacji, tak aby ka偶de wydane polecenie powodowa艂o wpis w dzienniku obserwacji.
Pod艂膮cz si臋 jako WACEK i uruchom skrypt s:\wacekddl.sql, aby wykona膰 kilka polece艅 DDL.
B臋d膮c pod艂膮czonym jako sysdba przejrzyj dziennik obserwacji, aby zobaczy膰, co zosta艂o zaobserwowane.
Wy艂膮cz opcje obserwacji i sprawd藕 poprawno艣膰 wy艂膮czenia ogl膮daj膮c odpowiednie perspektywy
XVII.聽Obs艂uga j臋zyk贸w narodowych
Cele
Lekcja ta zawiera r贸偶ne koncepcje i terminologi臋 zwi膮zan膮 z obs艂ug膮 j臋zyk贸w narodowych - National Language Support (NLS).
Po przerobieniu tej lekcji powiniene艣 potrafi膰
Przedyskutowa膰 w艂asno艣ci National Language Support (NLS).
Wyspecyfikowa膰 domy艣ln膮 charakterystyk臋 instancji.
Zdefiniowa膰 specyficzna charakterystyk臋 NLS dla u偶ytkownika.
Zmieni膰 charakterystyk臋 NLS w czasie sesji.
Opisa膰 w jaki spos贸b korzysta膰 z funkcji NLS w poleceniach SQL.
Opisa膰 w jaki spos贸b u偶ywa膰 parametr贸w NLS, jak r贸wnie偶 masek format贸w NLS w funkcjach NLS i innych funkcjach SQL.
Lekcja opcjonalna
Lekcja ta zawiera materia艂, kt贸ry jest specyficzny dla niekt贸rych instalacji i konfiguracji Oracle.
Instruktor mo偶e dokona膰 wyboru materia艂u w zale偶no艣ci od potrzeb uczestnik贸w. Ca艂o艣膰 tekstu, 膰wicze艅 i rozwi膮za艅 zosta艂a tu zamieszczona do ewentualnego samodzielnego przestudiowania.
Przegl膮d
Parametry National Language Support (NLS) pozwalaj膮 Oracle na obs艂ug臋 danych w wielu zestawach narodowych znak贸w czy stron kodowych (schemat贸w kodowania znak贸w). NLS pozwala instancji na interakcj臋 z u偶ytkownikiem w jego w艂asnym j臋zyku.
NLS nie t艂umaczy s艂贸w w bazie danych. Pozwala natomiast aplikacjom na konwersj臋 schemat贸w kodowania znak贸w i pozwala Oracle na wy艣wietlanie komunikat贸w w wyspecyfikowanym j臋zyku, w艂膮czaj膮c w to daty i inne dane w okre艣lonych formatkach.
Wykorzystanie National Language Support
Obs艂uga ORACLE w j臋zyku narodowym, przy wykorzystaniu narodowych konwencji.
Projektowanie aplikacji do dzia艂ania w j臋zykach i konwencjach.
Okre艣lanie domy艣lnego zachowania NLS dla instancji
Parametry inicjalizacji NLS.
Zmiany domy艣lnego zachowania NLS dla u偶ytkownika
Zmienna 艣rodowiskowa NLS.
Zmiany zachowania NLS w czasie sesji
Polecenie ALTER SESSION.
Parametry NLS.
Funkcje SQL i NLS
Maski format贸w NLS.
Funkcje NLS.
Korzystanie z parametr贸w NLS w funkcjach NLS i innych funkcjach SQL.
W艂asno艣ci NLS
Aplikacje projektowane z NLS mog膮 obs艂ugiwa膰 wiele schemat贸w kodowania znak贸w, j臋zyk贸w, format贸w dat i liczb jak r贸wnie偶 konwencji sortowania i u偶ycia wielkich i ma艂ych liter.
Schematy kodowania znak贸w w jednym bajcie (Single-byte character schemes) u偶ywane s膮 dla j臋zyk贸w europejskich (dla przyk艂ady francuski, niemiecki, islandzki, hiszpa艅ski, portugalski, grecki, czeski, s艂owacki, rosyjski i arabski) i j臋zyk贸w ameryka艅skich (np. ameryka艅ski, kanadyjski francuski, meksyka艅ski hiszpa艅ski czy brazylijski portugalski).
Obs艂uga j臋zyk贸w narodowych (National Language Support)
NLS obs艂uguje zar贸wno jedno- jak i wielo- bajtowe schematy kodowanie znak贸w.
Komunikaty ORACLE wy艣wietlane s膮 w wielu j臋zykach.
Nazwy dni i miesi臋cy r贸wnie偶 przetwarzane s膮 w wielu j臋zykach.
Daty, liczby i waluty formatowane s膮 z wykorzystaniem konwencji j臋zyka i terytorium.
Sortowanie danych znakowych, konwersje wielkich i ma艂ych liter wykonywane s膮 zgodnie z konwencjami danych alfabet贸w.
Zachowanie charakterystyczne dla j臋zyka i terytorium mo偶e by膰 definiowane na poziomie instancji, u偶ytkownik贸w i sesji.
Charakterystyki domy艣lne mog膮 zosta膰 zmienione dla ka偶dego u偶ytkownika.
Charakterystyki te mog膮 zosta膰 zmodyfikowane w czasie sesji w funkcjach.
Konwersja pomi臋dzy klientami a serwerami korzystaj膮cymi z innych schemat贸w kodowania znak贸w jest transparentna.
Schematy kodowania znak贸w
Schematy kodowania znak贸w okre艣laj膮 kody numeryczne odpowiadaj膮ce literom, kt贸re komputer lub terminal mo偶e wy艣wietli膰 i otrzyma膰.
Schematy kodowania znak贸w u偶ywane s膮 do interpretowania danych - jako maj膮ce znaczenie symbole z terminala do komputera. Dla przyk艂adu, znak zostaje wprowadzony na klawiaturze, terminal przek艂ada go na liczb臋, kt贸ra z kolei zostaje wys艂ana do komputera. W przeciwnym kierunku, liczba reprezentuj膮ca znak zostaje otrzymana przez terminal z komputera. Terminal dokonuje konwersji liczby w liter臋, kt贸ra zostaje wy艣wietlona na ekranie. Schemat kodowania znak贸w terminala okre艣la wi臋c, jaki kod reprezentuje jego liter臋.
Przyk艂ady schemat贸w jednobajtowych
Ameryka艅ski, ASCH 7-bitowy (US7ASCH)
Zachodnioeuropejski, ISO 8859-1 (WE81SO8859PI)
Strona kodowa EBCDIC 500, 8-bitowa, zachodnioeuropejska (WE*EBCDIC500)
Zachodnioeuropejski, DEC 8-bitowy (WE8DEC)
Jednobajtowe schematy kodowania mog膮 zosta膰 podzielone na schematy siedmio- i o艣miobitowe. Schematy siedmiobitowe mog膮 definiowa膰 do 128 znak贸w i normalnie obs艂uguj膮 jeden j臋zyk. Schematy o艣miobitowe definiuj膮 do 256 znak贸w i mog膮 obs艂ugiwa膰 kilka j臋zyk贸w.
Przyk艂ady schemat贸w wielobajtowych
Rozszerzony kod japo艅ski dla UNIXa (JEUC)
Chi艅ski GB2312-80 (CGB2312-80)
Komputery, drukarki i terminale korzystaj膮 w celu obs艂ugi alfabet贸w narodowych z wielu r贸偶nych schemat贸w kodowania znak贸w. Schematy te bazuj膮 albo na kodzie ASCH, albo na kodzie EBCDIC. S膮 r贸wnie偶 standardy ANSI i ISO, lecz producenci, nawet ze Wsp贸lnoty Europejskiej (EU), posiadaj膮 swoje w艂asne „standardy”.
Niekt贸re schematy kodowania znak贸w korzystaj膮 ze sta艂ej liczby bajt贸w dla ka偶dego znaku (np. jeden bajt, dwa bajty, cztery bajty). Jednak inne schematy (nazywane schematami „z przesuwaniem”- shift-in/shift-out) u偶ywaj膮 do reprezentacji ka偶dego znaku innej liczby bajt贸w. Kod kontrolny shift-out, przes艂any do urz膮dzenia, wskazuje, i偶 nast臋pne bajty maj膮 by膰 traktowane jako znaki dwubajtowe, a偶 do przes艂ania kodu steruj膮cego shift-in.
Parametry i zmienne 艣rodowiskowe NLS
Je艣li dla wersji 7.2 lub p贸藕niejszych nie jest ustawiona w 艣rodowisku unixowym zmienna 艣rodowiskowa ORA_NLS to mo偶liwe jest utworzenie bazy danych jedynie z domy艣lnym zestawem znak贸w US7ASCH. ORA_NLS powinno (pod UNIXem) zosta膰 ustawione w nast臋puj膮cy spos贸b:
$ORACLE_HOME/ocomon/nls/admin/data
Je艣li w 艣rodowisku nie jest ustawiona zmienna NLS_CHARACTERSET (lub NLS_LANG), a baza danych zosta艂a utworzona z zestawem znak贸w innym ni偶 US7ASCH, nie b臋dzie mo偶liwe wystartowanie bazy - zostanie zg艂oszony b艂膮d ORA_12701.
W wersjach 7.2 i p贸藕niejszych, wszystkie parametry NLS z initSID.ora dost臋pne s膮 r贸wnie偶 jako zmienne 艣rodowiskowe, co pozwala na okre艣lonej indywidualnej charakterystyki NLS dla ka偶dego klienta bez korzystania z aplikacji z poleceniem ALTER SESSION.
Okre艣lenie zachowania charakterystycznego dla j臋zyka
Zachowanie charakterystyczne dla danego j臋zyka okre艣la si臋 za pomoc膮 podawanego w pliku startowym parametru inicjalizacyjnego NLS_LANGUAGE.
NLS_LANGUAGE specyfikuje
J臋zyk u偶ywany dla komunikat贸w Oracle.
J臋zyk u偶ywany do nazw dni i miesi臋cy oraz ich skr贸t贸w.
Symbole u偶ywane w danym j臋zyku w miejsce a.m, p.m, a.d i b.c (przed po艂udniem, po po艂udniu, nasza era, przed nasz膮 er膮).
Symbol waluty ISO.
Sk艂adnia:
NLS_LANGUAGE=j臋zyk
Obs艂ugiwane j臋zyki r贸偶ni膮 si臋 w zale偶no艣ci od systemu operacyjnego.
Zachowanie charakterystyczne dla danego j臋zyka okre艣la si臋 za pomoc膮 podawanego w pliku startowym parametru inicjalizacyjnego NLS_TERRITORY.
NLS_TERRITORY specyfikuje
Domy艣lny format daty.
Znak oddzielaj膮cy cz臋艣膰 u艂amkow膮 liczby oraz separator grupowy.
Lokalny symbol waluty.
Pocz膮tkowy dzie艅 tygodnia.
Sk艂adnia:
NLS_TERRITORY=terytorium
Je艣li nazwa terytorium zawiera spacj臋, jak np. The Netherlands, nazwa ta powinna zosta膰 uj臋ta w cudzys艂贸w (”THE NETHRTLANDS”).
Okre艣lenie zachowania NLS dla u偶ytkownik贸w
Zmian臋 domy艣lnego zachowania NLS dla pojedynczego u偶ytkownika umo偶liwia zmienna 艣rodowiskowa NLS_LANG. Warto艣膰 NLS_LANG przes艂ania warto艣ci parametr贸w inicjalizacyjnych NLS.
Ka偶dy ze sk艂adnik贸w kontroluje cz臋艣膰 w艂asno艣ci NLS.
Sk艂adnia:
NLS_LANG = j臋zyk_terytorium.schemat_kodowania_znak贸w
gdzie:
j臋zyk przes艂ania warto艣ci NLS_LANGUAGE i kontroluje te same w艂asno艣ci co NLS_LANGUAGE.
terytorium przes艂ania warto艣膰 NLS_TERRITORY i kontroluje te same w艂asno艣ci co NLS_TERRITORY.
schemat_kodowania_znak贸w okre艣la schemat kodowania znak贸w u偶ywany przez aplikacj臋 klienck膮 (normalnie - ten sam co schemat terminala u偶ytkownika).
NLS_LANG definiuje schemat kodowania znak贸w terminalu klienta, R贸偶ni u偶ytkownicy mog膮 korzysta膰 z r贸偶nych schemat贸w. Dane przesy艂ane mi臋dzy klientem a serwerem s膮 automatycznie konwertowane pomi臋dzy dwoma schematami kodowania. Schemat kodowania u偶ywany w bazie danych powinien by膰 nadzbiorem lub ekwiwalentem wszystkich schemat贸w klienckich. Konwersja jest transparentna dla aplikacji klienckich.
Zerowanie schematu kodowania znak贸w za pomoc膮 NLS_LANG powinno by膰 dokonywane jedynie w 艣rodowisku klient-serwer.
W systemie Windows NT zmienn膮 NLS_LANG ustawiamy w rejestrach:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\NLS_LANG = POLISH_POLAND.EE8MSWIN1250
Wy艣wietlanie charakterystyki NLS
Przegl膮danie aktualnych warto艣ci parametr贸w NLS
V$NLS_PARAMETERS
Kolumna |
Opis
|
NLS_DATE_FORMAT |
Jawnie definiuje nowy format daty. Warto艣膰 `fmt' musi by膰 zgodna z modelem formatu daty. |
NLS_DATE_LANGUAGE |
Jawnie zmienia j臋zyk dla nazw dni i miesi臋cy oraz skr贸ty i warto艣ci tekst贸w dla innych element贸w formatu daty. |
NLS_NUMERIC_CHARACTERS |
Jawnie okre艣la nowy separator dziesi臋tny i grupowy. |
NLS_ISO_CURRENCY |
Jawnie okre艣la terytorium, kt贸rego znak i waluty ISO powinien by膰 u偶ywany. |
NLS_CURRENCY |
Jawnie specyfikuje nowy lokalny symbol waluty |
NLS_SORT |
Zmienia lingwistyczn膮 sekwencj臋 sortowania u偶ywan膮 przez Oracle do sortowania tekst贸w. Warto艣膰 ta musi to by膰 albo `BINARY' b膮d藕 nazwa lingwistycznej sekwencji sortowania. |
Przyk艂ad
Wy艣wietlanie aktualnych ustawie艅 parametr贸w NLS.
SQL> SELECT * FROM v$nls_parameters |
PARAMETER VALUE
---------------------------------------------------------------- ----------------
NLS_LANGUAGE POLISH
NLS_TERRITORY POLAND
NLS_CURRENCY z艂
NLS_ISO_CURRENCY POLAND
NLS_NUMERIC_CHARACTERS ,
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT YY/MM/DD
NLS_DATE_LANGUAGE POLISH
NLS_CHARACTERSET EE8MSWIN1250
NLS_SORT POLISH
Zmiana indywidualnej charakterystyki NLS
Zmiana indywidualnej charakterystyki NLS dla sesji.
Przyk艂ady
Rozwa偶amy nast臋puj膮c膮 tabel臋 LETTERS.
SQL> SELECT * FROM letters ORDER BY letter; |
LETTER
---------------------------------------
ca
cha
cla
cz
la
lla
lx
ma
Zmiana sortowania dla aktualnej sesji na sekwencj臋 hiszpa艅sk膮.
SQL> ALTER SESSION SET nls_sort = `xspanish'; |
Polecenie wy艣wietlania posortowanej zawarto艣ci LETTERS.
SQL> SELECT * FROM letters ORDER BY letter; |
LETTER
---------------------------------------
ca
cla
cz
cha
la
lx
lla
ma
Okre艣lenie j臋zyka dla nazw dni tygodnia i miesi臋cy zwracanych przez funkcj臋 TO_CHAR i TO_DATE odbywa si臋 za pomoc膮 parametru NLS_DATE_LANGUAGE. Mo偶na poda膰 wszystkie j臋zyki, jakie mog膮 by膰 warto艣ci膮 parametru NLS_LANGUAGE.
Sk艂adnia:
NLS_DATA_LAGUAGE = j臋zyk |
Przyk艂ad
Ustawienie parametr贸w j臋zykowych funkcji TO_CHAR i TO_DATE na francuski a nast臋pnie na du艅ski.
SQL> ALTER SESSION SET NLS_DATE_LANGUAGE = french; |
SQL>聽SELECT TO_CHAR (sysdate, `Day:Dd Month yyyy') 2> ANNIVERSAIRE FROM dual; |
ANNIVERSAIRE
---------------------------------------
Samedi :21 Mai 1993
SQL>ALTER SESSION SET nls_data_language = danish; |
SQL> SELECT TO_CHAR (sysdate, `Day;Dd Month yyyy') 2> FRDSELSDAG FROM dual; |
FRDSELSDAG
---------------------------------------
Torsdag :4 maj 1993
Separator dziesi臋tny i grupowy okre艣la si臋 za pomoc膮 parametru NLS_NUMERIC_CHARACTERS. Oba symbole musz膮 by膰 r贸偶nymi, jednobajtowymi znakami.
Sk艂adnia:
NLS_NUMERIC_CHARACTERS = 'separator_dziesi臋tny separator_grupowy' |
Przyk艂ad
Ustawienie separatora dziesi臋tnego na ”,” a separatora grupowego na ” .”
SQL> ALTER SESSION 2> SET nls_numeric_characters = `,.' |
Zauwa偶amy u偶ycie w poleceniu SELECT apostrof贸w.
SQL> SELECT 3 * `1,5' FROM DUAL |
3* `1,5'
-----------------
4,5
Liczby zawieraj膮ce przecinek jako separator dziesi臋tny wymagaj膮 ” ”. Bez cudzys艂ow贸w nie by艂o by mo偶liwe rozr贸偶nianie pomi臋dzy liczb膮 zawieraj膮c膮 cz臋艣膰 dziesi臋tn膮 a list膮 dw贸ch liczb.
Liczby z separatorem tysi臋cy przechowywane jako napis musz膮 by膰 do formatu numerycznego konwertowane za pomoc膮 funkcji TO_NUMBER z odpowiedni膮 mask膮 formatu.
Okre艣lenie tekstu zwracanego przez mask臋 formatu liczbowego C, symbol waluty ISO odbywa si臋 za pomoc膮 parametru NLS_ISO_CURRENCY. Do specyfikacji symbolu ISO korzysta si臋 z odpowiadaj膮cej mu nazwy terytorium.
Sk艂adnia:
NLS_ISO_CURRENCY = terytorium |
Przyk艂ad
Ustawienie symbolu waluty ISO na Francj臋 .
SQL> ALTER SESSION SET nls_iso_currency = FRANCE; |
Przy takim terytorium polecenie SELECT
SQL>SELECT TO_CHAR (750, `C999') „TOTAL” FROM dual; |
zwraca
TOTAL
----------------
FRF750
Okre艣lenie typu sortowania liter odbywa si臋 za pomoc膮 NLS_SORT.
Sk艂adnia:
NLS_SORT=BINARY | nazwa |
BINARY specyfikuje sortowanie binarne, oparte na schemacie kodowania znak贸w (name okre艣la specyficzn膮 sekwencj臋 sortowania).
Przyk艂ady
Ustawienie sekwencji sortowania na sortowanie binarne.
SQL>ALTER SESSION SET nls_sort = binary; |
SQL>SELECT * FROM animals ORDER BY animal; |
ANIMAL
----------------
camel
lion
llama
lynx
Ustawienie sekwencji sortowania na alfabet hiszpa艅ski.
SQL> ALTER SESSION SET nls_sort = xspanish; |
SQL>SELECT * FROM animals ORDER BY animal; |
ANIMAL
----------------
camel
lion
lynx
llama
Elementy masek format贸w NLS
Zosta艂o zdefiniowanych kilka nowych element贸w masek formatu. Niekt贸re z nich zosta艂y zdefiniowane jako elementy masek formatu NLS.
Elementy numerycznych masek formatu
„D” dla separatora dziesi臋tnego
„G” dla separatora grupowego (tysi臋cy)
„L” dla lokalnego symbolu waluty
„C” dla lokalnego symbolu waluty ISO
Elementy masek formatu dla dat
„RM, rm” dla miesi臋cy drukowanych jako cyfry rzymskie
„IW” dla nr tygodnia ISO
„IYYY, IYY. IY i I” dla roku ISO
Przyk艂ad
Wynik poni偶szego zapytania wykonanego przy NLS_TERRITORY ustawionym na Francj臋 dnia pierwszego stycznia 1993
SQL> SELECTTO_CHAR (SYSDATE, `DD MM YY') ”TODAY” , 2> TO_CHAR (SYSDATE, `DD RM YY') ”TODAY”, 3>聽TO_CHAR (SYSDATE, `YYYY IW') ”TODAY”, 4>聽TO_CHAR 12345.67, `99G999D99') ”12345.67” 5>聽FROM dual; |
TODAY TODAY TODAY 12345.67
---------- ---------- ---------- ---------
01 01 93 1 I 93 1992 53 12.345,67
Niezale偶nie od tego jakie s膮 standardowe konwencje dla nr tygodnia na wybranym terytorium, nr tygodni Oracle nie s膮 domy艣lnie ustawiane na nr tygodni ISO.
Funkcje NLS
Z NLS mog膮 by膰 u偶ywane niekt贸re z funkcji SQL.
Konwersja liter
Konwersja liter na wielkie lub ma艂e przy uwzgl臋dnieniu narodowych schemat贸w kodowania znak贸w odbywa si臋 za pomoc膮 zmodyfikowanych funkcji SQL.
NLS_UPPER
NLS_LOWER
NLS_INITCAP
Pobranie aktualnego ustawienia j臋zyka
Pobranie aktualnego ustawienia j臋zyka, terytorium i schematu kodowania znak贸w.
USERENV (`language')
Por贸wnanie napis贸w
NLS_SORT
Konwersja schemat贸w kodowania danych
Konwersja danych z jednego schematu kodowania znak贸w do innego.
CONVERT
Korzystanie z parametr贸w NLS w funkcjach
Podanie parametr贸w NLS w funkcjach SQL, kt贸rych zachowanie zale偶y od konwencji NLS.
Funkcje SQL przyjmuj膮ce parametry NLS
TO_CHAR
TO_DATE
TO_NUMBER
NLS_UPPER
NLS_LOWER
NLS_INITCAP
NLS_SORT
Jawne podanie opcjonalnych parametr贸w NLS dla tych funkcji pozwala na obliczenie funkcji niezale偶nie od ustawie艅 NLS dla sesji.
Przyk艂ady
TO_CHAR ('13.000,00', `99G999D99', `NLS_NUMERIC_CHARACTERS = `'.,''') |
TO_CHAR (12345, `L099G999' `NLS_NUMERIC CHARACTERS=',.', `NLS_CURRENCY='DFL') |
Podsumowanie
Obs艂uga j臋zyk贸w narodowych (National Language Support)
Obs艂uga jedni- i wielobajtowych schemat贸w kodowania znak贸w.
Elastyczne specyfikowanie konwencji j臋zyka i terytorium.
Formaty dat, liczb i walut.
Sortowanie liter wed艂ug konwencji lokalnych alfabet贸w.
Transparentna konwersja danych.
Okre艣lanie zachowania domy艣lnego dla NLS
ORA_NLS.
Parametry NLS w init.ora.
Zmienne 艣rodowiskowe NLS.
Ustawienie NLS z pomoc膮 ALTER SESSION.
Parametry NLS w funkcjach SQL.
Zadania
Obejrzyj wszystkie prawid艂owe warto艣ci ustawie艅 NLS
Pod艂膮cz si臋 jako WACEK, sprawd藕 ustawienia NLS dla sesji
B臋d膮c pod艂膮czonym jako WACEK zmie艅 symbol waluty na 'PLN', format daty na 'DD-MM-YY' i sprawd藕, czy zmiany zosta艂y dokonane i wy艣wietl dat臋 systemow膮
B臋d膮c pod艂膮czonym jako WACEK ustaw j臋zyk daty na turecki, a nast臋pnie sprawd藕 czy data systemowa (przy pomocy funkcji TO_CHAR) jest wy艣wietlana w nowym j臋zyku
Materia艂y szkoleniowe —Administracja baz膮 danych Oracle
Strona 336 z 337
Strona 335 z 337
Wyszukiwarka
Podobne podstrony:
Kurs Oracle Reports
kurs oracle podstawy sql 4FTEY3ZEMDW5YMC7JVMVHLV3IJIVX2DSWAXXO3Y
Kurs Php & Mysql, Informatyka, 鈼 PHP, MySQL, ORACLE
Pages from Kurs Oracle transakcje
KURS ETYKI
Choroba hemolityczna p odu na kurs
zapotrzebowanie ustroju na skladniki odzywcze 12 01 2009 kurs dla pielegniarek (2)
kurs
wady postawy kurs
ostre bia艂aczki 24 11 2008 (kurs)
AT kurs analityka gie艂dowego 3
Piel臋gniarki kurs wersja 6 V 01
Kurs 03 Dynamika
Kurs anemia2012
Stany zagro墓慕enia 墓慕ycia piel脛鈩niarki kurs[1]
wi臋cej podobnych podstron