Rozdział 13: Architektura systemu Oracle

Prezentacja na temat: "Rozdział 13: Architektura systemu Oracle"— Zapis prezentacji:

1 Rozdział 13: Architektura systemu Oracle
(c) 2000, Instytut Informatyki Politechniki Poznańskiej

2 Warstwy instalacji Oracle’a
Warstwy instalacji Oracla Aplikacje Narzędzia Oracla Aplikacje SQL, PL/SQL Narzędzia Oracla Server Oracla System Operacyjny SQL, PL/SQL Dane Server Oracle’a System Operacyjny Warstwy te odpowiadają za przepływ informacji pomiędzy użytkownikiem a bazą danych Oracle. Brak bezpośredniego dostępu do danych Server jest uruchamiany na płaszczyźnie systemu operacyjnego i jest od niego w duzym stopniu zależny. Ponad 80 platform. Identyczny widok od strony użytkownika. Server jest sercem napisanym w jezyku C, i to zapewnia przenaszalnosc. Obsluguje wszelkie operacje na bazie danych tzn: zapis, odczyt, aktualzację. Zapewnia równoległy dostęp, spójność itp. Narzędzia: Oracle Forms, Oracle Reports, Oracle Graphics, Oracle Book. Dane (c) 2000, Instytut Informatyki Politechniki Poznańskiej

3 Architektura systemu Oracle
SQL SQL procesy usługowe (serwery) SQL Globalny Obszar Systemowy instancja bazy danych procesy systemowe dane (c) 2000, Instytut Informatyki Politechniki Poznańskiej

4 Instancja bazy danych Globalny Obszar Systemowy procesy systemowe
instancja bazy danych - zbiór procesów (ang. process, task, job, program) oraz obszar pamięci współdzielonej zwanej Globalnym Obszarem Systemowym (ang. System Global Area - SGA) obsługujący jedną bazę danych Globalny Obszar Systemowy Instancja Oracla jest to grupa buforów wykorzystywana do obsługi bazy o nazwie Obszar Globalny Systemu oraz szereg procesów drugoplanowych, które działając asynchroniczne wykonują wszelkie czynności związane z obsługą bazy i jej użytkowników. Zwykle dla jednej bazy podniesiona jest jedna instancja. Możliwe jest jednak otwarcie wielu instancji na danych jednej bazy przy użyciu opcji Servera Równoległego (Parallel Server Option). procesy systemowe (c) 2000, Instytut Informatyki Politechniki Poznańskiej

5 Rodzaje organizacji instancji
organizacja typu single-process Aplikacja serwer Oracle Globalny Obszar Systemowy (c) 2000, Instytut Informatyki Politechniki Poznańskiej

6 Rodzaje organizacji instancji (cd.)
organizacja typu multiple-processes SQL SQL procesy usługowe (serwery) SQL Globalny Obszar Systemowy Procesy drugoplanowe Liczba procesów drugoplanowych pracujących w Instancji Oracle’a zależna jest od ustawienia parametrów bazy. Istanieje jednak grupa procesów nezbędnych do pracy bazy. Do procesów tych zaliczamy: DBWR - Data Base Writer - proces zapisujący dane wprowadzane przez użytkowników do bazy z buforów SGA do plików dyskowych; LGWR - Log Writer - proces zapisujący pliki dziennika powtórzeń, czyli historię wszystkich operacji na bazie; PMON - Process Monitor - monitor procesów trzymających pieczę nad zasobami bazy wykorzystywanymi przez użytkowników bazy; SMON - System Monitor - monitor systemu utrzymujący porządek w SGA; Ponadto w Instancji Oracla pracować mogą procesy drugoplanowe odpowiadające za: archiwizację plików dziennika powtórzeń - ARCH odtwarzanie rozproszone bazy - RECO blokowanie rozproszone danych w bazie - LCKn replikacje danych SNPn rownoległy zapis do bazy Dbnn pracę servera wielokanałowego Dnn - DISPATCHERS i Snn - SERVERS realizację punktów kontrolnych CKPT - CHECK POINT SMON PMON CKPT LGWR DBWR ARCH (c) 2000, Instytut Informatyki Politechniki Poznańskiej

7 Struktura bazy danych Oracle’a Pliki dziennika powtórzeń
procesy drugoplanowe (systemowe) Obszar Globalny Systemu Baza danych fizyczne składa się z czterech rodzajów plików (wyżej). W serverach Oracla zwykle znajdują się one w ORAWIN\DBS. Są to zwykle pliki o rozszerzeniu .ORA lub .DBS Database Files. Pliki bazy danych to miejsce, gdzie fizyczne przechowywane są dane zapisane w bazie. Ich wielkość decyduje o pojemności bazy. Przestrzeń przez nie zajmowana jest w bazie logicznie pogrupowana na przestrzenie tablic. Łączna wielkość wszystkich plików bazy nie może być mniejsza niż 5MB. Redo Log Files. Zawierają dane o bazie służące do awaryjnego odtwarzania danych bazy. Każda baza posiada co najmniej dwa pliki dziennika powtórzeń. Mirroring - dla zwiększenia bezpieczeństwa. Control Files. Są to małe pliki binarne zawierające informacje o fizycznej strukturze bazy. Zapisane są tu między innymi nazwy wszystkich plików stanowiących bazę wraz z pełną ścieżką dostępu, nazwa bazy danych i daty ostatnich zapisów dokonywanych w plikach bazy. Mają on duże znaczenia dlatego przechowywane są w kilku kopiach na różnych fizyczne dyskach. Parameter Files. Zawierają zbiór parametrów startowych bazy. Informacje te czytane są podczas startu bazy i zawierają między innymi wielkość obszaru SGA, nazwę bazy danych. Plik startowy Oracle’a nosi zwykle nazwę INIT.ORA i znajduje się w katalogu ORAWIN\RDBMS71\ Pliki dziennika powtórzeń Pliki bazy danych Pliki kontrolne Pliki startowe (c) 2000, Instytut Informatyki Politechniki Poznańskiej

8 Procesy usługowe (serwery)
procesy usługowe - realizują żądania użytkowników, wykonując: analizę składniową, optymalizację i wykonanie zleceń SQL, odczyt niezbędnych bloków z dysku do buforów, pielęgnują listy: LRU i zmodyfikowanych bloków proces usługowy bufor danych SGA SQL lista LRU lista zmodyfikowanych blokow dane (c) 2000, Instytut Informatyki Politechniki Poznańskiej

9 lista zmodyfikowanych
Sekretarz Bazy Danych zadania Sekretarza Bazy Danych (ang. Database Writer-DBWR): zapis zmodyfikowanych bloków z buforów na dysk, bufor danych SGA lista LRU t Jest to proces odpowiedzialny za zapis na dysku wszystkich zmian wprowadzanych przez użytkownika do bazy. Przenosi on dane z buforów bazy danych (Database Buffer Cache) zawartych w SGA do fizycznych plików dyskowych bazy (Database Files). Fizyczny zapis danych na dysku odbywa się. gdy Data Base Writer: nie znajduje w SGA odpowiedniej liczby wolnych buforów potrzebnych do bieżącej pracy bazy; upłynął odpowiednio długi okres bez zapisów (ma to miejsce przy małej aktywności bazy); w bazie wykonuje się tzw. CHECKPOINT - czyli punkt kontrolny i baza wymusza zapis wszystkich istotnych informacji z obszaru SGA do plików dyskowych. Proces ten zmniejsza liczbę fizycznych zapisów na dysku, co przyspiesza pracę i czyni ją bardziej płynną. Nie dla kazdego uzytkownika, tylko raz na jakiś czas dla wszystkich. Istnieją platformy systemowe pozwalające na uruchomienie wielu procesów DBWR w jednej instancji Oracle’a. Jeden proces obsługuje wtedy zapis na jednym dysku. lista zmodyfikowanych blokow DBWR dane (c) 2000, Instytut Informatyki Politechniki Poznańskiej

10 Sekretarz Dziennika Powtórzeń
Zadania Sekratarza Dziennika Powtórzeń (ang. Log Writer-LGWR) zapis danych z bufora dziennika do pliku, zapis rekordu zakończenia transakcji, realizacja punktu kontrolnego (ang. checkpoint). SGA LGWR bufor dziennika powtórzeń Zadaniem Log Writer’a jest zapisywanie buforów dziennika powtórzeń (Redo Log Buffer) znajdujących się w SGA na dysku do plików dziennika powtórzeń (Redo Log Files). Proces ten uaktywnia się, gdy: następuje potwierdzenie transakcji (COMMIT); bufory dziennika w SGA są zapełnione w jednej trzeciej; DBWR czyści bufory bazy danych; w bazie wykonywany jest CHECKPOINT; upłynął odpowiednio długi okres bez zapisów; baza przygotowuje się do przeprowadzenia transakcji rozproszonej. W instancji Oracle’a może istnieć tylko jeden proces LGWR. W praktyce proces ten zapewnia zapis na dysku wszysktkich ostatnio dokonanych zmian w bazie. Okres czasu objęty tym zapisem zależy od aktywności bazy i wielkości zadeklarowanych na dysku plików dziennika powtórzeń.Im większe pliki i mniejsza aktywność bazy, tym dłuższa historia pracy bazy zostaje zapamiętana na dysku. plik dziennika powtórzeń (c) 2000, Instytut Informatyki Politechniki Poznańskiej

11 Proces Punktu Kontrolnego
Proces Punktu Kontrolnego (ang. Checkpointer - CKPT) może przejąć zadanie realizacji punktu kontrolnego, normalnie wykonywanego przez LGWR bufor danych SGA CKPT plik kontrolny 12 DBWR plik dziennika powtórzeń 12 12 dane (c) 2000, Instytut Informatyki Politechniki Poznańskiej

12 Monitor Systemu Monitor Systemu (ang. System Monitor - SMON) odpowiedzialny jest za „porządki”, do jego obawiązków należy: odtwarzanie systemu po awarii w czasie uruchamiania instancji, usuwanie niepotrzebnych segementów tymczasowych, aktualizowanie pliku kontrolnego bazy, scalanie wolnych rozszerzeń (ang. extent) w ramach segmentu (c) 2000, Instytut Informatyki Politechniki Poznańskiej

13 Monitor Procesów Monitor Procesów (ang. Process Monitor - PMON) zajmuje się odtwarzaniem procesów usługowych, które uległy awarii; odpowiedzialny jest za: usuwanie nienormalnie zakończonych połączeń, wycofywanie nie zatwierdzonych transakcji, czyszczenie buforów, zwalnianie zajętych zasobów (np.: blokady, zatrzaski itp. założonych przez zatwierdzone procesy), wykrywanie wewnętrznych zakleszczeń pomiędzy blokadami zakładanymi na dane bazy i automatyczne wycofywanie transakcji Na bazie danych może jednocześnie pracować wielu użytkowników. Często zdarza się więc, że kilu użytkowników sięga jednocześnie po te same dane. Nie jest to problem gdy wszyscy użytkownicy chcą jedynie oglądać ten sam fragment bazy. Kłopoty zaczynają się wtedy gdy kilku użytkowników jednocześnie chce modyfikować ten sam wiersz. Aby baza zachowała spójność, a użytkownicy nie prześcigali się w modyfikacji tych samych fragmentów danych, istnieje system blokad (LOCK) zapwniających, że w danej chwili tylko jeden użytkownik bazy może modyfikować wybrany przez siebie wiersz. Pozostali użytkownicy muszą czekać na zakończenie tej operacji Process Monitor zajmuje się właśnie odzyskiwaniem zasobów bazy zwolnionych przez użytkowników. Zarówno PMON, jak i SMON dziełają asynchronicznie i nie można ich aktywności wymusić zewnętrznie. Nie można też wpływać na ich pracę przez zmianę parametrów pliku startowego bazy. Ani użytkownik, ani jej administrator nie wiedzą, kiedy te procesy są aktywne, a kiedy nie. (c) 2000, Instytut Informatyki Politechniki Poznańskiej

14 Archiwizator bufor dziennika powtórzeń
Archiwizator (ang. Archiver-ARCH) dokonuje archiwizacji online plików dziennika powtórzeń LGWR ARCH bufor dziennika powtórzeń plik dziennika powtórzeń zarchiwizowany dziennik powtórzeń (c) 2000, Instytut Informatyki Politechniki Poznańskiej

15 Organizacja pamięci operacyjnej
przeznaczenie - przechowywanie: kodu wykonywanych programów, procesów, informacji o bieżących sesjach użytkowników, danych niezbędnych do wykonania programu (np.: stan wykonywanego zapytania), informacji współdzielonych przez różne procesy (np.: blokady), buforowanych danych. (c) 2000, Instytut Informatyki Politechniki Poznańskiej

16 Organizacja pamięci operacyjnej (cd.)
obszar kodu oprogramowania, Globalny Obszar Systemowy (SGA): bufor danych (ang. Database Buffer Cache), bufor dziennika (ang. Redo Log Buffer), współdzielony zbiornik (ang. Shared Pool), Globalny Obszar Programu (ang. Program Global Area), obszar sortowania (ang. Sort Area) (c) 2000, Instytut Informatyki Politechniki Poznańskiej

17 Organizacja pamięci operacyjnej (cd.)
obszar kodu oprogramowania aplikacja obszar kodu oprogramowania serwer PGA SA SGA bufor danych bufor dziennika powtórzeń współdzielony zbiornik obszar kodu oprogramowania procesy systemowe PGA (c) 2000, Instytut Informatyki Politechniki Poznańskiej

18 Organizacja pamięci operacyjnej (cd.)
obszar kodu oprogramowania - fragment pamięci operacyjnej do przechowywania i wykonywania programów; jest tylko do odczytu; na pewnych platformach może być współdzielony między różne procesy, SGA - współdzielony obszar pamięci operacyjnej zawierający dane i informacje sterujące dla jednej instancji: bufor danych - fragment SGA służący do buforowania danych użytkowych, zarządzany algorytmem LRU, wielkość określana przez DB_BLOCK_BUFFERS [Blk], bufor dziennika powtórzeń - obszar SGA o organizacji pętli służący do buforowania zapisu do dziennika powtórzeń, wielkość określana przez LOG_BUFFER [B] (domyślnie: 4*DB_BLOCK_SIZE), (c) 2000, Instytut Informatyki Politechniki Poznańskiej

19 Organizacja pamięci operacyjnej (cd.)
współdzielony zbiornik, wielkość określana przez SHARED_POOL_SIZE, składa się z: współdzielonego obszaru zleceń SQL - zawiera elementy identycznych zleceń SQL (drzewo analizy składniowej, plan wykonania itp.) PGA PGA prywatny obszar zleceń SQL prywatny obszar zleceń SQL współdzielony obszar zleceń SQL współdzielony zbiornik (c) 2000, Instytut Informatyki Politechniki Poznańskiej

20 Organizacja pamięci operacyjnej (cd.)
bufor słownika bazy danych (ang. Data Dictionary Cache), Globalny Obszar Programu - fragment pamięci zawierający dane i informacje sterujące pojedynczym procesem, obejmuje: stos - zmienne, tablice sesji itp., informacje o sesji użytkownika, prywatny obszar zleceń SQL - zmienne i parametry zleceń SQL, obszar sortowania - fragment pamięci niezbędny do sortowania danych, wielkość określana przez SORT_AREA_SIZE [B] (c) 2000, Instytut Informatyki Politechniki Poznańskiej

21 Otwieranie bazy danych
OPEN startup [open] alter database open MOUNT startup mount alter database mount startup nomount NOMOUNT (c) 2000, Instytut Informatyki Politechniki Poznańskiej

22 Otwieranie bazy danych (cd.)
tryb nomount - używany do tworzenia bazy danych, plików kontrolnych itp., powoduje: uruchmienie instancji, otwarcie pliku z parametrami i plików śladowych, tryb mount - używany do reorganizacji bazy danych (np.: zmiany nazwy pliku) oraz odtwarzania po awarii, powoduje: otwarcie plików kontrolnych i przyłączenie plików z danymi oraz plików dziennika powtórzeń, tryb open - udostępnia bazę danych użytkownikom do normalnej pracy, powoduje: otwarcie plików danymi oraz plików dziennika powtórzeń, odtwarzanie po ewentualnej awarii, (c) 2000, Instytut Informatyki Politechniki Poznańskiej

23 Zamykanie bazy danych OPEN alter database close MOUNT
alter database dismount NOMOUNT shutdown (c) 2000, Instytut Informatyki Politechniki Poznańskiej

24 Zamykanie bazy danych tryb normal - z oczekiwaniem na zakończenie wszystkich sesji użytkowników, SVRMGR> shutdown [normal] tryb immediate - z wycofaniem wszystkich aktywnych transakcji, SVRMGR> shutdown immediate tryb abort - z natychmiastowym zakończeniem wszystkich procesów instancji i zwolnieniem pamięci SGA SVRMGR> shutdown abort (c) 2000, Instytut Informatyki Politechniki Poznańskiej