Szb pytania



Pobieranie 0.78 Mb.
Strona13/13
Data29.10.2017
Rozmiar0.78 Mb.
1   ...   5   6   7   8   9   10   11   12   13

75. Zasada WAL.


Zmiana danych na stronie i informacja o zatwierdzeniu są najpierw zapisywane do dziennika powtórzeń przechowywanego na innym nośniku danych (dysku) niż pliki z danymi. Jest to zasada nazywana najpierw-zapis-do-dziennika w skrócie WAL – ang. write-ahead logging.

Transakcja kończy się wtedy, gdy wszystkie rekordy dziennika powtórzeń dotyczące jej akcji zostaną przepisane z pamięci wewnętrznej na dysk a nie wtedy gdy dane zmienione przez transakcję zostaną zapisane na dysk.

Dane zmienione przez transakcję nie muszą zostać zapisane na dysk w chwili kończenia transakcji (COMMIT/ROLLBACK) ale mogą zostać zapisane:

przed jej zakończeniem (mówi się wtedy o zjawisku kradzieży ramek, ang. stealing frames);

albo później, po jej zakończeniu (mówi się wtedy o strategii nie używania siły, ang. no force)

– nie ma to znaczenia dla operacji COMMIT, ROLLBACK i możliwości odtworzenia danych w przypadku awarii. Po zapisie do dziennika powtórzeń nawet awaria serwera lub dysku z danymi nie spowoduje utraty danych bo można je odtworzyć (własność trwałości).


76. Rezerwowa baza danych (standby)


Rezerwowa baza danych jest to dodatkowa instalacja bazy danych na osobnym komputerze utrzymywana stale w specjalnym trybie standby – z ciągle dokonywanym odtwarzaniem w oparciu o kopie zarchiwizowanego dziennika powtórzeń generowane przez główną, operacyjną bazę danych.

W przypadku awarii dysku lub katastrofy w rodzaju ataku terrorystycznego, trzęsienia ziemi, pożaru czy kradzieży, rezerwowa bazy danych przechodzi z trybu standby w tryb read write i przejmuje obowiązki głównej bazy danych.

Rezerwowa baza danych znajduje się zwykle w fizycznie oddalonym węźle, do którego stale są przesyłane kolejne części zarchiwizowanego dziennika powtórzeń.

Rezerwowej bazy danych można używać do raportowania – przechodząc w tryb read only  – napływające pozycje zarchiwizowanego dziennika powtórzeń utrzymywane są w kolejce, dopóki nie wrócimy do trybu standby. Po przejściu bazy danych w tryb read write nie jest już możliwy jej powrót do trybu standby.

Zamiast rezerwowej bazy danych alternatywę stanowią:


  1. użycie repliki bazy danych (będzie o nich mowa w wykładzie 13);

  2. użycie zwierciadlanego odbicia bazy danych - dokładnej jej kopii, która w każdej chwili może przejąć jej funkcje.

77. Discretionary access control - swobodna kontrola dostępu.


Oparte na uprawnieniach do wykonywania operacji na obiektach bazy danych. Właściciel obiektu ma pełne prawa do obiektu. Może część tych praw przekazać innym, wybranym przez siebie użytkownikom.

GRANT privileges ON object TO user [WITH GRANT OPTION]

REVOKE uprawnienie, ... ON nazwa_obiektu  FROM użytkownik, ...

REVOKE: Gdy uprawnienie zostanie odjęte od X, zostaje również odjęte od wszystkich użytkowników którzy dostali je wyłącznie od X.

SZBD buduje graf autoryzacji, w którym węzłami są użytkownicy a krawędzie opisują wykonaną instrukcję GRANT.

Właściciel może określić zakres dostępu do swoich danych w bazie danych poprzez perspektywę. Zarządzanie uprawnieniami i użytkownikami jest wspomagane przez role (SQL'99), które odzwierciadlają sposób funkcjonowania organizacji. W trakcie działania aplikacji baz danych role można dynamicznie włączać i wyłączać:

   SET ROLE operator;

Użytkownik aplikacji ma na stałe tylko uprawnienie CONNECT.


78. Mandatory access control - obowiązkowa kontrola dostępu.


Oprócz swobodnej kontroli dostępu: dodatkowo oparte na przypisaniu klas ochrony do poszczególnych obiektów w bazie danych i do użytkowników (lub programów). Przez porównanie klasy obiektu i klasy użytkownika system podejmuje decyzję czy użytkownik może wykonać określoną operację na obiekcie.

Zapobiegają użyciu koni trojańskich dostępu do chronionych danych w rodzaju:



  1. Uczeń tworzy tabelę MojaTabela i daje do niej uprawnienia wykładowcy. (Wykładowca nie jest tego świadomy.)

  2. Uczeń modyfikuje kod programu klienckiego (który znajduje się poza kontrolą SZBD) wstawiając zapisywanie danych z tabeli wykładowcy DziennikLekcyjny do tabeli MojaTabela.

  3. Przy każdym użyciu programu przez wykładowcę dane zostają zapisane do tabeli studenta MojaTabela.

Model Bell-LaPadula

  • Obiekty (e.g., tabele, perspektywy, wiersze)

  • Podmioty (e.g., użytkownicy, programy użytkownikow)

  • Klasy ochrony class(P), class(O):
         Top secret (TS), secret (S), confidential (C), unclassified (U): TS > S> C > U

  • Każdy obiekt i każdy podmiot maja przypisane klasy ochrony.

 

(Simple Security Property) Podmiot P może odczytać obiekt O gdy class(P) >= class(O)

(*-Property) Podmiot P może zapisać obiekt O gdy class(P) <= class(O)
 

Rozwiązanie problemu konia trojańskiego polega na zapewnieniu, że informacje nie płyną od wyższej klasy ochrony do niższej.

1. Wykładowca ma klasę S, program wykładowcy i tabela wykładowcy DziennikLekcyjny mają klasę S.

2. Uczeń ma klasę C, tabela ucznia, MojaTabela, ma tę samą klasę co uczeń, czyli C.

4. Zatem program wykladowcy (S) nie moze wykonac zapisu do tabeli ucznia (C) bo S>C.

 
Klasy ochrony mogą być używane na różnych poziomach granulacji bazy danych, również na poziomie wierszy. W zależności od posiadanej klasy ochrony użytkownik może widzieć inny zbiór wierszy przy SELECT.


79. Perspektywy jako narzędzie kontroli dostępu.


Perspektywa to wirtualna tabela, okreslona przez zapytanie (SELECT)..

Perspektywy sa obiektami, jakie udostepnia sie konkretnym grupom uztkownikow.Okreslaja one widok zaprojektowany dla tej grupy.Stanowia m.in. element ochrony przezd niepowolanym lub nieprawidlowym dostepm do danych. Np. kazdy uzytkownik bd ma dostep tylko do danych dotyczacych tylko swojej dzialanosci w firmie – poprzez perspektywne kontroluje sie jego dostep do danych.


Składnia:

CREATE [ FORCE | NOFORCE ] VIEW nazwa AS

SELECT ...

[ WITH CHECK OPTION [ CONSTRAINT nazwa_wiezu ] ]

[ WITH READ ONLY ];

NOFORCE


Powoduje, że nie sprawdza się istnienia tabel, z których korzysta pespektywa.

FORCE


Wręcz przeciwnie. Opcja domyślna.

WITH CHECK OPTION

Wymusza sprawdzenie czy istrukcje DML na perspektywie nie powodują sfalsyfikowania warunku WHERE pespektywy. Jeśli falsyfikują operacja DML jest odrzucana. To są więzy spójności jak każde inne i można mu nadać im nazwę poprzez CONSTRAINT.

WITH READ ONLY

Powoduje, że poprzez tę perspektywę nie można zmieniać danych.

80. Role jako narzędzie kontroli dostępu.


Role w bazie danych są jak wirtualny użytkownik, któremu można przypisać pewien zakres uprawnień dostępu do bazy danych. Role można przydzielać dowolnej liczbie użytkowników, a każdy użytkownik może pełnić wiele ról. Kiedy roli w bazie danych przypisuje sie pewne uprawnienia, a następnie przydziela się te role użytkownikowi, to dysponuje on wszystkimi prawami przypisanymi tej roli. Jest to łatwiejsze od kontrolowania uprawnień poszczególnych użytkowników.
CREATE ROLE rola;

Przykład:

CREATE ROLE szef;

GRANT create table to szef; -- nadanie roli prawa

GRANT szef to józio, kazio; -- nadanie użytkownikowi roli
Są pewne role predefiniowane:

PUBLIC


Wszyscy.

DBA


Administrator bazy danych) ma prawo do:

CREATE USER

Pozwala na tworzenie nowych użytkowników.

 DROP USER

Pozwala na usuwanie użytkowników.

DROP ANY TABLE

Pozwala na usuwanie tabel z dowolnego schematu.

 BACKUP ANY TABLE

Pozwala na wykonywanie kopii zapasowej tabel z dowolnego schematu za pomocą narzędzia do eksportu.

81. Fragmentacja i replikacja danych.


W rozproszonej bazie danych występuje rozłożenie danych do węzłów sieci poprzez ich fragmentację (podział) lub replikację - do różnych konfiguracji sprzętowych i programistycznych na ogół rozmieszczonych w różnych (geograficznie) miejscach organizacji.
Fragment danych stanowi pewien podzbiór wszystkich danych całej bazy danych przechowywany w jednym węźle sieci.
Replika danych stanowi kopię całości lub jakiejś części danych przechowywanych w innym miejscu niż oryginał.
Są dwa typy fragmentacji: pionowa i pozioma:
Fragment poziomy stanowi podzbiór wierszy w tabeli, np. dane z jednego rejonu kraju.
Fragment pionowy stanowi podzbiór kolumn w tabeli, np. identyfikator, data urodzenia i zarobki pracowników.
Fragmentację pionową wykonuje się przez wykonanie rzutu na podzbiór kolumn zawierający w sobie klucz główny. Odtworzenie oryginalnej tabeli polega na zastosowaniu złączenia w oparciu o wartości klucza głównego.
Fragmentację poziomą uzyskuje się przez zastosowanie operacji selekcji. Odtworzenie oryginalnej tabeli polega na zastosowaniu operacji sumy UNION.


Operacja 

Fragmentacja pozioma

Fragmentacja pionowa

rozkład

selekcja

rzut

złożenie

suma

złączenie

82. Metoda Semijoins.


Metoda ta jest używana do wykonywania rozproszonego złączenia.

Załóżmy, że tabela Dept jest dostępna w Warszawie a Emp jest dostępna w Krakowie.


SELECT E.Ename, d.Dname

FROM Emp E INNER JOIN Dept D ON E.Deptno=D.Deptno

WHERE E.Job='MANAGER' AND d.Loc='Warszawa'
Metoda półzłączeń


  1. W Warszawie, dokonaj projekcji tabeli Dept na kolumny złączenia i prześlij wynik do Krakowa. Można skorzystać z selekcji d.Loc='Warszawa' ograniczającej zbiór wierszy.




  1. W Krakowie, dokonaj złączenia projekcji tabeli Dept z tabelą Emp. Wynik nazywa się redukcją tabeli Emp względem Dept. Prześlij redukcję tabeli Emp do Warszawy. Można skorzystać z selekcji E.Job='MANAGER' ograniczającej zbiór wierszy.




  1. W Warszawie, dokonaj ostatecznego złączenia tabeli Dept z redukcją tabeli Emp.




  • Idea metody półzłączeń: koszt przesłania całej tabeli zastępujemy kosztem obliczenia i przesłania kolejno projekcji i redukcji.

83. Dwu-fazowe zatwierdzanie (2PC).


  1. Koordynator wysyła do wszystkich węzłów komunikat prepare.

  2. Węzły podejmują lokalnie decyzję o gotowości do zatwierdzenia prepare lub konieczności wycofania transakcji abort i zapisują w swoim dzienniku odpowiednio albo rekord prepare albo rekord abort i następnie wysyłają do koordynatora odpowiednio komunikat albo yes albo no.

  3. Gdy koordynator uzyska jednomyślną odpowiedź yes, zapisuje do swojego dziennika rekord commit i wysyła do wszystkich węzłów komunikat commit. W przeciwnym przypadku zapisuje do swojego dziennika rekord abort i wysyła do wszystkich węzłów komunikat abort.

  4. Węzły zapisują w swoim dzienniku odpowiednio rekord abort/commit albo end, kończą transakcję usuwając informację o niej z bufora bazy danych w pamięci RAM. a następnie wysyłają do koordynatora komunikat ack.

  5. Po otrzymaniu wszystkich potwierdzeń ack koordynator zapisuje do swojego dziennika rekord end i kończy transakcję usuwając informację o niej z buforu bazy danych w pamięci RAM.

Komentarz na temat protokołu 2PC



  1. Dwufazowość - dwie rundy komunikacji: pierwsza - głosowanie; druga - kończenie. Obie są inicjowane przez koordynatora.

  2. Koordynator w fazie głosowania, gdy nie ma odpowiedzi z jednego z węzłów, może zadecydować o wycofaniu (abort) całej transakcji - jest zwykle określone ograniczenie czasowe oczekiwania na odpowiedź.

  3. Każdy węzeł przed lub w czasie fazy głosowania może zadecydować o wycofaniu (abort) transakcji - również wtedy gdy nie może się połączyć z koordynatorem.

  4. Każdy komunikat odzwierciedla decyzję nadawcy; aby mieć pewność odporności na awarie, decyzja jest najpierw zapisywana do dziennika transakcji (logu).

84. Dwu-fazowe zatwierdzanie (2PC) z domyślnym wycofaniem.


To co w poprzednim +
W przypadku podjęcia decyzji o wycofaniu zarówno koordynator jak i węzeł lokalny od razu dokonują wycofania transakcji. Brak transakcji w pamięci RAM oznacza, że została ona wycofana.

85. Realizacja rozproszonej bazy danych w Oracle.


Przede wszystkim Oracle dostarcza oprogramowanie sieciowe Oracle Net umożliwiające komunikację między bazami danych Oracle oraz obsługę transakcji rozproszonych działających na więcej niż jednej bazie danych – w tym zatwierdzanie takich transakcji i ich wycofywanie.
Z punktu widzenia projektanta rozproszonej bazy danych najważniejsze są dwa nowe rodzaje obiektów tworzonych w lokalnej bazie danych, za pomocą których uzyskuje się dostęp do obiektów w odległych bazach danych. W ten sposób ze zbioru lokalnych baz danych można utworzyć rozproszoną bazę danych. Obiekty te to:
1. Powiązanie z bazą danych (ang. database link) – jest to zapisana w bazie danych ścieżka sieciowa do odległej bazy danych.
CREATE DATABASE LINK baza

CONNECT TO scott IDENTIFIED BY tiger

USING 'elektron';
SELECT *

FROM Emp@baza;


2. Migawka, perspektywa zmaterializowana (ang. snapshot, materialized view) – lokalna kopia (replika) danych znajdujących się w jednej lub więcej odległych bazach danych. Migawka ma charakter perspektywy odświeżanej co określony przedział czasu (może więc nie zawierać danych w pełni aktualnych!).
CREATE SNAPSHOT Wszyscy_prac
REFRESH NEXT Sysdate+1
AS SELECT * FROM Emp@warszawa
   UNION
   SELECT * FROM Emp@krakow
   UNION
   SELECT * FROM Emp@gdansk;
SELECT *

FROM Wszyscy_prac

WHERE Job = 'MANAGER';

86. Rozwiązania problemu integracji danych.


W zastosowaniach baz danych coraz częściej pojawia się problem integracji danych pochodzących z różnych źródeł danych - w szczególności z baz danych.

Powiązane dane istnieją w różnych miejscach i może zaistnieć potrzeba jednoczesnego ich użycia przez jedną aplikację.

Bazy danych mogą się różnić:


  • modelem (np. relacyjny, obiektowo-relacyjny, hierarchiczny, XML, pliki MS Excel),

  • schematem (np. znormalizowany, nieznormalizowany),

  • terminologią (np. czy konsultanci firmy są pracownikami, czy emerytowani pracownicy są pracownikami),

  • konwencjami (np. stopnie Celsjusza lub Fahrenheita; mile lub kilometry).

Przykład

Dwie szkoły wyższe chcą się połączyć. Każda z nich ma swoją osobną bazę danych. Władze nowej szkoły wyższej chcą mieć zintegrowany widok na całość.



Dwa podejścia do integracji

Hurtownia danych. Skopiuj dane źródłowe do centralnej bazy danych dokonując ich transformacji do wspólnego schematu. Hurtownie danych są tematem osobnego wykładu.

Sprowadzanie danych i ich transformacja jest dokonywane raz na pewien czas – np. raz na dzień.





 

Mediator. Utwórz perspektywę wszystkich źródeł danych, tak jakby były zintegrowane.

Wyznaczaj wynik zapytania do perspektywy przez jego tłumaczenie do źródeł danych a następnie tam wykonuj zapytanie.

87. Organizacja przechowywania danych w bazie danych Oracle.


Przestrzenie tabel

Obiekty w bazie danych Oracle są podzielone na logiczne jednostki przechowywania danych na dysku nazywane przestrzeniami tabel. Przestrzeń tabel to struktura pośrednia między strukturą logiczną (tabelami, indeksami) a fizyczną (plikami danych).


Każda baza danych Oracle zawiera jedną,  "systemową" przestrzeń tabel o nazwie SYSTEM. Ta przestrzeń tabel zawiera słownik danych (w postaci tabel i perspektyw), definicje wszystkich składowanych procedur i pakietów, a także wszystkich wyzwalaczy bazy danych.
Struktura przestrzeni tabel

Podstawową jednostką fizyczną zapisu danych jest blok danych (strona). Jego rozmiar jest ustalany przy tworzeniu bazy danych i musi być wielokrotnością rozmiaru bloku systemu operacyjnego.



Ekstent jest określoną liczbą położonych obok siebie na dysku bloków danych – uzyskiwanych do zapisu danych w wyniku jednej alokacji i przeznaczonych do zapisu określonego typu informacji.

Segment jest zbiorem ekstentów alokowanych dla jednego obiektu bazy danych. Każda tabela i każdy indeks mają swój segment, w którym są zapisywane ich dane. System dynamicznie przydziela miejsce na dysku, gdy bieżące ekstenty w segmencie zostaną wypełnione. System automatycznie dodaje nowy ekstent do istniejącego segmentu. Ekstenty w ramach segmentu nie muszą być położone obok siebie na dysku.

88. Rodzaje procesów w bazie danych Oracle.


Są dwa typy procesów: procesy użytkowników i procesy systemu. W systemie klient/serwer procesy użytkowników i systemu są wykonywane na oddzielnych komputerach.


Proces użytkownika (klienta) jest tworzony i utrzymywany do wykonania kodu programu aplikacyjnego (np. programu napisanego w języku Pro*C) lub narzędzia Oracle (np. Oracle Enterprise Manager). Proces użytkownika zarządza także komunikacją z procesami serwera. Procesy użytkowników komunikują się z procesami serwera za pomocą specjalnego interfejsu Oracle, którym jest program sieciowy Oracle Net.


Procesy systemu – są wywoływane przez inne procesy w celu wykonania funkcji na rzecz wywołujących je procesów. Są dwóch rodzajów: procesy serwera (usługowe, ang. server processes) i procesy tła (drugoplanowe, ang. background processes).

Procesy serwera (usługowe) – są tworzone przez system do obsługi zleceń od zgłaszających się przez sieć procesów użytkowników. Na przykład, jeśli użytkownik zgłasza zapotrzebowanie na dane, których nie ma w danej chwili w buforze bazy danych w SGA, realizujący to żądanie proces serwera odczytuje właściwe bloki danych z dysku i zapisuje je w SGA.

Proces serwera może zostać skonfigurowany na dwa sposoby albo jako proces dedykowany przeznaczony do obsługi żądania jednego procesu użytkownika albo jako proces współdzielony pobierający kolejne zgłoszenia do wykonania z kolejki zleceń.



Procesy tła (drugoplanowe) są to stałe procesy tworzone przez Oracle dla każdej instancji przeznaczone do wykonywania rutynowych zadań systemu zarządzania bazą danych. Procesy tła działając "w tle" wykonują asynchronicznie operacje wejścia/wyjścia i monitorują inne procesy Oracle dostarczając zwiększonego poziomu równoległego wykonywania operacji i w ten sposób zwiększając wydajność systemu.

89. Podsumowanie dostrajania bazy danych Oracle


Poprawienie parametrów działania bazy danych w Oracle można uzyskać przede wszystkim poprzez:

1. przygotowanie poprawnego schematu bazy danych (z ewentualną, świadomie przeprowadzoną denormalizacją w uzasadnionych przypadkach);

2. poprawną ogólną organizację poziomu fizycznego: klastry, indeksy, rozłożenie plików do różnych stacji dyskowych, zastosowanie architektury wieloprocesorowej;

3. ustalenie odpowiednich parametrów zapisu w przestrzeniach tabel (pomocą może być instrukcja ANALYZE);

4. ustalenie odpowiednich parametrów zapisu rekordów w blokach takich, jak PCTFREE i PCTUSED;

5. ustalenie odpowiednich parametrów alokacji ekstentów do segmentów takich, jak parametry klauzuli STORAGE;

6. dobranie odpowiednich wartości parametrów inicjalizacyjnych instancji;

7. dobranie odpowiednich instrukcji SQL poprzez:

o analizę planu wykonywania przez system instrukcji SQL (jest możliwe zamieszczanie wskazówek dla optymalizatora),

o oglądanie zawartości Współdzielonego Obszaru SQL i standaryzację zapisu instrukcji;

8. wybór odpowiedniego poziomu izolacji realizacji transakcji (np. czy ma być zapewniana własność szeregowalności czy nie).

90. Monitorowanie użycia bazy danych


Instrukcja

AUDIT rodzaj_operacji, ... ;

powoduje włączenie śledzenia operacji wykonywanych przez użytkowników bazy danych. Dla każdej operacji ORACLE tworzy rekord kontrolny zawierający:

• użytkownika wykonującego operację,

• typ operacji,

• obiekt, którego dotyczy operacja,

• datę i godzinę operacji.

Na przykład:



AUDIT UPDATE TABLE, DELETE TABLE;

AUDIT SELECT ON Scott.Emp;

Pobieranie 0.78 Mb.

Share with your friends:
1   ...   5   6   7   8   9   10   11   12   13




©operacji.org 2020
wyślij wiadomość

    Strona główna