Zarządzanie bezpieczeństwem w SZBD Oracle

Instalacja, architektura
i struktura SZBD Oracle
numer wersji konserwacji bazy danych
główny numer wersji Bazy Danych
Oracle Database Server 11..2.0 .1 .0
numer wersji Serwera Aplikacji
numer wersji charakterystyczny dla Komponentu
numer wersji charakterystyczny dla Platformy Sprzętowej
Instalacja
Uruchomić z podanej lokalizacji plik
setup.exe
Zainstalować serwer bazy danych,
realizując krok po kroku podpowiedzi
systemu …
SZBD Oracle
Serwer
Baza danych
Struktura logiczna
Struktura fizyczna
Instancja
Instancja
Instancja jest to fragment pamięci wyodrębniony
z pamięci komputera pracującego jako serwer
Oracle
Znajduje się w niej grupa buforów (tzw. Obszar
Globalny Systemu – SGA) wykorzystywana do
obsługi bazy oraz szereg procesów
drugoplanowych (programów rezydujących w
pamięci operacyjnej komputera pracującego
jako serwer Oracle’a), wykonujących wszystkie
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
pracujących na danych jednej bazy przy użyciu
opcji Serwera Równoległego.
Architektura systemu Oracle 11g
Architektura systemu - ogólnie
instancja
DBWR
LGWR
PMON
SMON
RECO
ARCHn
CKPT
DBnn
SNPnn
Procesy drugoplanowe
Obszar SGA
Procesy
użytkownika
Obszar dzielony
Bufory
bazy danych
Procesy
usługowe
Bufory
dziennika powtórzeń
Pliki dziennika powtórzeń
Pliki kontrolne
Pliki bazy danych
Baza danych
Procesy drugoplanowe
Liczba procesów drugoplanowych pracujących w instancji Oracle’a
jest zależna od ustawienia parametrów bazy. Istnieje jednak grupa
procesów niezbędnych do pracy bazy:

DBWR (ang. Database Writer) – proces zapisujący dane
wprowadzane przez użytkowników do bazy z buforów SGA do
plików dyskowych.

LGWR (ang. Log Writer) – proces zapisujący dane z buforów
dziennika powtórzeń do plików dziennika powtórzeń.

PMON (ang. Process Monitor) – monitor procesów trzymający
pieczę nad zasobami bazy wykorzystywanymi przez
użytkowników bazy. Proces ten odzyskuje zasoby zwolnione
przez użytkownika, wycofuje niepotwierdzone transakcje, czyści
nienormalnie zakończone połączenia, wykrywa zakleszczenia.

SMON (ang. System Monitor) – monitor systemu, utrzymujący
porządek w SGA. Proces ten obsługuje plik kontrolny, odzyskuje
przestrzeń po segmentach tymczasowych, wykonuje
automatyczne odtwarzanie instancji.
Zadania DBWR
Zapis zmodyfikowanych bloków z buforów na
dysk, gdy:
 zostanie zgłoszony punkt kontrolny,
 upłynęły 3 sekundy od ostatniego zapisu,
 brakuje miejsca w buforze danych
Zadania LGWR
Zapis zmodyfikowanych bloków
z buforów na
dysk, gdy:
 zostaje zgłoszony punkt kontrolny,
 następuje zatwierdzenie transakcji,
 bufor jest w 1/3 zapełniony,
 upłynęły 3 sekundy od ostatniego zapisu,
 DBWR chce zapisać na dysk zawartość bufora.
Zadania CKPT


inicjowanie punktu kontrolnego,
uaktualnianie nagłówków plików danych i plików
kontrolnych informacjami dotyczącymi punktu
kontrolnego
Punkt kontrolny jest systemowym zdarzeniem bazy
danych, dzięki któremu dane z buforów pamięci SGA są
zapisywane na dysk – następuje synchronizacja
zawartości SGA z bazą danych
Punkt kontrolny
Jest inicjowany, gdy:
następuje przełączenie grupy plików dziennika
powtórzeń,
upłynął czas określony parametrem
LOG_CHECKPOINT_TIMEOUT
proces LGWR zapisał do pliku dziennika powtórzeń
liczbę bloków bufora dziennika powtórzeń określoną
parametrem LOG_CHECKPOINT_INTERVAL
następuje zamknięcie instancji w trybie NORMAL lub
IMMEDIATE
Zadania SMON



odtwarzanie systemu po awarii w czasie
uruchamiania instancji,
czyszczenie segmentów tymczasowych,
scalanie
wolnych
obszarów
w
ramach
segmentów.
Zadania PMON



odtwarzanie procesów usługowych, które uległy
awarii,
czyszczenie buforów,
zwalnianie zajętych zasobów (blokady, zatrzaski,
…).
Procesy
procesy użytkowników
procesy Oracle
procesy
serwera
są tworzone po to, aby wykonać
program aplikacji lub narzędzia
Oracle
procesy
drugoplanowe
są wywoływane przez inne procesy
żeby wykonać funkcje na rzecz
procesu wywołującego
Struktura fizyczna bazy danych
Każda baza danych w SZBD ORACLE składa się
z synchronizowanego zestawu:
plików danych,
plików dziennika powtórzeń,
plików kontrolnych
pliku startowego o nazwie np.: INIT.ORA.
Pliki danych
Pliki danych to miejsce, gdzie fizycznie
przechowywane są dane zapisane w bazie.
Przestrzeń dyskowa zajmowana przez pliki bazy
danych jest logicznie podzielona w bazie na
przestrzenie tabel.
Pliki dziennika powtórzeń (1)
Pliki dziennika powtórzeń przechowują informacje
o wszystkich zmianach zachodzących w bazie danych (co zostało
zmienione w wierszu, co zostało zapisane w segmencie wycofania, czy
transakcja została potwierdzona, czy był realizowany punkt kontrolny, czy
jest transakcja rozproszona,...) i są wykorzystywane tylko podczas
odtwarzania.
Zapis do plików dziennika powtórzeń dokonywany jest przez proces
drugoplanowy LGWR, który przenosi dane z buforów dziennika
powtórzeń do plików dyskowych.
Pliki dziennika stosuje się, w celu odtworzenia transakcji zatwierdzonych
w momencie awarii.
Pliki dziennika mogą składać się z plików aktualnych (online) i plików
zarchiwizowanych (offline).
Baza Oracle musi składać się z synchronizowanego zestawu plików
danych, dziennika i kontrolnych
Każdy plik dziennika powtórzeń posiada swój numer sekwencyjny.
Pliki dziennika powtórzeń
(2)
Synchronizacja między plikami danych bazuje na aktualnym numerze
sekwencyjnym pliku dziennika powtórzeń.
SZBD Oracle przechowuje informację o bieżącym pliku dziennika
powtórzeń (jego numer sekwencyjny) w każdym pliku kontrolnym
pracującym z bazą, w każdym pliku danych oraz w plikach dziennika
powtórzeń należących do bazy danych.
Numer sekwencyjny jest przechowywany w pierwszym bloku pliku
danych (bloku nagłówka). Często dla zwiększenia niezawodności pracy
bazy wszystkie pliki dziennika powtórzeń powielane są na fizycznie
różnych dyskach tworząc tzw. grupy plików dziennika powtórzeń.
Gdy grupa plików dziennika powtórzeń jest zapełniona, następuje
przełączenie na następną grupę, numer sekwencyjny wzrasta o jeden.
Numery sekwencyjne zawarte w plikach danych są uaktualniane przez
proces LGWR podczas punktu kontrolnego.
Pliki kontrolne
Pliki kontrolne to małe pliki binarne zawierające
informacje o fizycznej strukturze bazy danych:



nazwy wszystkich plików tworzących bazę danych wraz
ze ścieżką dostępu,
nazwę bazy danych,
czy daty ostatnich zapisów dokonywanych w plikach
bazy.
Przy montowaniu bazy na podstawie informacji
zawartych w pliku startowym serwer Oracle’a
odszukuje i otwiera pliki kontrolne, z których
wczytywane są informacje o pozostałych plikach
tworzących bazę danych.
Dla zapewnienia bezpieczeństwa bazy danych pliki
kontrolne są zwykle powielane w kilku kopiach na
różnych fizycznie dyskach.
Plik startowy (inicjalizacyjny)
Plik inicjalizacyjny umożliwia:
optymalizację wydajności przez dostosowanie
struktury pamięci (np. liczba buforów danych
w pamięci),
ustawienie wartości domyślnych dla całej bazy w
momencie tworzenia,
ustawienie limitów bazy (np. max ilość
użytkowników bazy),
wyspecyfikowanie plików bazy.
Parametry ustawiane
Parametry, które powinny być określone:
DB_NAME - identyfikator bazy danych
CONTROL_FILES - nazwy plików kontrolnych (min. 2)
INIT_SQL_FILES
- nazwy skryptów SQL-a do wykonania w
czasie tworzenia
bazy danych (zawsze sql.bsq; przydałoby się też: catalog.sql tworzy perspektywy słownika oraz catproc.sql - tworzy obiekty
niezbędne do opcji proceduralnej)
LOG_ARCHIVE_DEST
- lokalizacja archiwizowanych plików
dziennika powtórzeń
LOG_ARCHIVE_FORMAT - format nazwy archiwizowanych
plików dziennika
powtórzeń
USER_DUMP_DEST
- lokalizacja plików śladowych
procesów użytkownika
BACKGROUND_DUMP_DEST
- lokalizacja plików śladowych
procesów drugoplanowych
Parametry najczęściej
modyfikowane
AUDIT_TRAIL
- włączenie/wyłączenie obserwacji bazy danych
DB_BLOCK_BUFFERS
- liczba bloków buforów bazy danych w SGA
DB_BLOCK_SIZE - rozmiar w [B] bloku Oracle’a; rozmiar bloku nie może być zmieniony po
utworzeniu bazy
DML_LOCKS
- max. liczba blokad DML
IFILE - nazwa dodatkowego pliku z parametrami
LOG_BUFFER
- rozmiar w [B] buforów dziennika w SGA
LOG_ARCHIVE_START
- włączenie/wyłączenie automatyczne archiwizacji dziennika
w trybie ARCHIVELOG
LOG_CHECKPOINT_INTERVAL
- max. liczba bloków zapisanych do pliku dziennika
mdzy pkt. kontrolnymi
LOG_CHECKPOINT_TIMEOUT
- max odstęp w [sek] mdzy pkt. kontrolnymi
MAX_DUMP_FILE_SIZE
- max. rozmiar w [blokach systemu oper.] pliku śladowego
OPEN_CURSORS
- max liczba kursorów otwartych przez użytkownika
PROCESSES
- max liczba procesów w SO jednocześnie podłączonych do bazy danych (z
drugoplanowymi_
ROLLBACK_SEGMENTS
- nazwy segmentów wycofania, aktywnych w danej instancji
SHARED_POOL_SIZE
- rozmiar obszaru dzielonego SQL (w blokach Oracle’a) (nie
powinna być zmniejszana poniżej 3500000 [B] bo zawiesi się wykonanie skryptu catproc.sql)
SQL_TRACE
- włączenie/wyłączenie tworzenia plików śladowych dla procesów użytkownika
TIMED_STATISTICS
- włączenie/wyłączenie pomiaru czasu operacji dla plików
śladowych i monitora
CHECKPOINT_PROCESSES - włączenie/wyłączenie procesu CKPT
DB_FILES
- max liczba otwartych plików danych
LOG_FILES
- max liczba otwartych plików dziennika powtórzeń
Struktura logiczna
bloki,
segmenty,
obszary,
przestrzenie tabel.
Bloki danych
Blok danych jest najmniejszą jednostką
wejścia/wyjścia, używaną przez bazę danych.
Pojedynczy blok logiczny odpowiada jednemu
lub większej liczbie bloków systemu
operacyjnego
zwykle, rozmiar bloku Oracle’owego jest zależny
od rozmiaru bloku systemu operacyjnego.
Obszary (extenty)
Obszar (ang. extent) jest zbiorem kolejnych bloków
zaalokowanych przez segment.
Pierwszy obszar zwany jest obszarem inicjalnym (ang.
initial), natomiast następne – przyrostowymi (ang.
incremental).
Oracle uważa bloki z następującymi po sobie numerami
identyfikacyjnymi jako ciągłe, chociaż nie oznacza to, że
są one ciągłe na dysku. Obiekt alokuje nowy obszar
tylko wtedy, gdy aktualnie zaalokowane są użyte. Częsta
dealokacja obszarów może doprowadzić do fragmentacji
wolnej przestrzeni w plikach danych.
Segmenty
Segment jest zbiorem jednego lub więcej obszarów, w których zawarte
są dane określonego typu logicznej struktury pamięci w przestrzeni
tabel.
Typy segmentów: danych, indeksu, tymczasowy, wycofania[1],
otwarcia.
Każdy segment w bazie jest tworzony z co najmniej jednym obszarem
dla danych., jednakże segment wycofania zawsze ma co najmniej dwa
obszary.
Segmenty mogą powodować fragmentację wolnej przestrzeni (segment
słownika danych nie powoduje fragmentacji, segmenty danych
powodują niewielką fragmentację, segmenty wycofania powodują
średnią fragmentację, segmenty tymczasowe powodują wysoką
fragmentację).
[1] Jest to zbiór obszarów, w których znajdują się dane modyfikowane.
Służy do zapewnienia możliwości wycofania transakcji (każda
transakcja jest przypisana do jednego segmentu wycofania), spójności
czytania i do odtwarzania.
Przestrzenie tabel
Przestrzeń tabel jest logicznym obszarem, w którym
baza przechowuje zapisane w niej dane. Każda
przestrzeń składa się z jednego lub więcej plików
systemu operacyjnego, które dla serwera Oracle’a
tworzą integralną całość.
Użytkownik bazy nie ma wpływu na rozmieszczenie
danych w plikach przestrzeni tablic, natomiast może
jawnie wyrazić w poleceniu tworzenia obiektu
(CREATE), w której przestrzeni obiekt ma powstać.
Pojedynczy obiekt nie może zostać umiejscowiony w
kilku przestrzeniach tabel.
Obiekty umiejscowione w danej przestrzeni nigdy nie
mogą zaalokować obszarów poza nią.
Plik danych w przestrzeniach tabel
Plik
danych
nr 1
Plik
danych
nr 2
Tablica
Indeks
Przestrzeń tablic
nr 2
Plik danych nr
3
Tablica
Tablica
Indeks
nie jest możliwe stworzenie
obiektu bazy, znajdującego się
w kilku przestrzeniach tabel
wyjątek: partycjonowanie
Indeks
użytkownik nie ma wpływu na
rozmieszczenie danych w plikach
Przestrzeń SYSTEM
W momencie tworzenia bazy danych
automatycznie tworzona jest przestrzeń
SYSTEM, zawierająca m.in.:
słownik danych,
definicje wyzwalaczy bazy,
definicje procedur wbudowanych,
segment wycofania SYSTEM,
ale zalecane jest (w zastosowaniach
produkcyjnych) podzielenie bazy Oracle’a na
kilka (wiele) przestrzeni.
Dlaczego kilka przestrzeni?
oddzielenie danych użytkowników od danych słownika
oddzielenie danych jednej aplikacji od drugiej
zachowanie różnych zbiorów danych przestrzeni tabel
na różnych dyskach
oddzielenie danych użytkowników od danych segmentu
wycofania (zabezpieczenie od całkowitej utraty danych
w przypadku zepsucia się pojedynczego dysku)
chwilowe zabronienie dostępu do danych zawartych
w przestrzeni
zreorganizowanie plików zaalokowanych w pamięci
Powiązanie segmentów
z obszarami
Segment
112K
obsz
ar
28 k
obsza
r
84 k
bloki bazy
danych
plik
wiele fizycznych
bloków
zaalokowanych w
dysk jest udostępniany
pliku przestrzeni
przez pliki
Tworzenie bazy danych
Organizacja danych w przestrzenie tabel
Zaprojektowanie struktury bazy tak, aby zapobiec
fragmentacji i brakowi zasobów
Przygotowanie systemu operacyjnego (ustawienie
zmiennej ORACLE_SID)
Przygotowanie pliku startowego
Start instancji
Wykonanie komendy CREATE DATABASE
Zapewnienie bezpieczeństwa bazy poprzez utworzenie
wielokrotnych plików dziennika i powielenie pliku
kontrolnego
Utworzenie tablic i perspektyw słownika danych
Tryby otwarcia bazy danych
STARTUP
OPEN
wystartowała instancja
został otwarty plik kontrolny, pliki danych
i pliki dziennika
MOUNT
STARTUP MOUNT
wystartowała instancja
został otwarty plik kontrolny
NOMOUNT
STARTUP NOMOUNT
wystartowała instancja
SHUTDOWN
Ustawienie zmiennej
środowiskowej
ORACLE_SID,
Podłączenie do bazy jako
użytkownik INTERNAL (na
poziomie Systemu
Operacyjnego następuje
weryfikacja),
Wydanie polecenia startu
bazy (STARTUP) z
ewentualnymi
parametrami.
Tryby zamykania bazy danych
Normal – z oczekiwaniem na zakończenie
wszystkich sesji użytkowników,
Transactional – z oczekiwaniem na zakończenie
wszystkich transakcji użytkowników,
Immediate – z wycofaniem wszystkich
aktywnych transakcji
Abort – z natychmiastowym zakończeniem
wszystkich procesów instancji i zwolnieniem
SGA
Słownik bazy danych
Słownik jest to szereg tablic dostępnych dla
użytkowników tylko do czytania, zawierających
opis stanu bazy danych.
Tablice słownika powstają w czasie tworzenia
bazy danych (do ich zakładania służy skrypt
SQL.BSD)
i są niemodyfikowalne przez cały czas życia bazy.
Słownik bazy danych
Istnieją 3 grupy perspektyw, ułatwiających korzystanie
ze słownika:



USER - perspektywy dostępne dla wszystkich użytkowników
bazy; zawierają informacje o obiektach będących jego
własnością
ALL - perspektywy dostępne dla wszystkich użytkowników bazy;
zawierają informacje o obiektach będących jego własnością oraz
obiektach, do których użytkownik ten ma nadane obiektowe
prawa bazodanowe
DBA - perspektywy dostępne dla użytkownika o statusie DBA;
zawierają informacje o wszystkich obiektach
Opisy wszystkich perspektyw słownika znajdują się
w tablicy DICTIONARY
Perspektywy słownika danych
Perspektywy z informacją o przestrzeniach tabel:








DBA_/USER_EXTENTS
DBA_/USER_SEGMENTS
DBA_/USER_FREE_SPACE (tu: również możliwość
zaobserwowania fragmentacji)
DBA_/USER_TABLESPACES
DBA_USERS
DBA_DATA_FILES
DBA_TS_QUOTAS
V$DATAFILE
Perspektywy z informacją o obiektach schematu


ALL_/USER_TABLES
ALL_/USER_TABCOLUMNS
Zarządzanie
bezpieczeństwem
w SZBD Oracle, archiwizacja
i odtwarzanie bazy danych
Dwie kategorie ochrony SZBD
Ochrona systemu:






weryfikacja nazwy
użytkownika i hasła
określenie czy użytkownik
ma możliwość połączenia
się z bazą danych
(autoryzacja)
przydzielanie miejsca na
dysku dla obiektów
użytkownika
określenie ograniczeń na
zasoby dla użytkownika
określenie jakie operacje
systemowe użytkownik
może wykonywać
możliwość monitorowania
bazy danych
Ochrona danych:



określenie jacy użytkownicy
mają prawo dostępu do
określonych schematów
obiektów
określenie jakie typy
operacji są dozwolone
określonym użytkownikom
wybranie operacji, które
będą monitorowane dla
każdego schematu obiektów
Sposób funkcjonowania SZBD ORACLE jest zgodny z
modelem Dyskrecjonalnej (uznaniowej) kontroli dostępu
(Discretionary Access Control – DAC)
Ograniczanie dostępu do informacji oparte
na uprawnieniach
Odpowiednie uprawnienia muszą być
związane z użytkownikiem, by miał dostęp
do obiektu
Uprzywilejowany użytkownik może
przekazywać innym użytkownikom
uprawnienia zgodnie z własnym uznaniem
Sposoby utrzymywania
bezpieczeństwa bazy danych
Użytkownicy bazy danych
Schematy
Uprawnienia (przywileje)
Role
Ograniczenia pamięci (quota)
Profile
Obserwacja
Część I
Tworzenie użytkowników – definiowanie
schematu bezpieczeństwa
Kontrola dostępu do bazy poprzez modyfikowanie,
usuwanie i monitorowanie użytkowników
tworzenie użytkowników i przypisywanie im
haseł
autoryzowanie użytkowników do podłączenia się
do bazy
ograniczanie dostępnej przestrzeni dyskowej dla
każdego użytkownika
Użytkownik a jego schemat
Każda baza danych w SZBD ORACLE ma zdefiniowaną
listę nazw użytkowników
Z każdym użytkownikiem związany jest schemat o tej
samej nazwie (tworzony, gdy tworzony użytkownik)
Wszystkie obiekty użytkownika są logicznymi strukturami i
znajdują się w schemacie użytkownika (który jest logiczną
kolekcją obiektów użytkownika)
po podłączeniu się do bazy użytkownik ma dostęp do
wszystkich obiektów zawartych w jego schemacie
Każdy użytkownik ma domenę ochrony (a security domain)
- zbiór właściwości, które określają:



akcje (przywileje i role) dostępne dla użytkownika
ograniczenia zasobów przestrzeni tabel
ograniczenia zasobów systemowych
dostęp do bazy i jej obiektów jest kontrolowany poprzez
przywileje nadane każdemu schematowi
Obszary kontroli dostępu
• Ograniczenia dla dostępnych przestrzeni tabel
• Domyślna przestrzeń tabel
• Tymczasowa przestrzeń tabel
• Informacje o uwiarygodnieniu
• Ograniczenia zasobów systemowych
• Przywileje i role
Mechanizmy ochrony dostępu do zasobów bazy
i systemu związane z użytkownikiem
Domyślna przestrzeń tabel (TABLESPACE
DEFAULT)
Tymczasowa przestrzeń tabel (TEMPORARY
TABLESPACE)
ograniczenia zasobów w przestrzeni tablic
(TABLESPACE QUOTA)
ograniczenia zasobów systemowych (SYSTEM
RESOURCE LIMIT)
Kontrola praw dostępu - uwiarygodnienie
poprzez system operacyjny
poprzez bazę Oracle
Użytkownicy sys i system
SYS - właściciel słownika danych
SYS - hasło po instalacji
„CHANGE_ON_INSTALL”
SYSTEM - pierwszy administrator bazy, który
ma wszystkie prawa do zarządzania bazą
danych
SYSTEM - hasło po instalacji „MANAGER”
Tworzenie użytkowników
Polecenie CREATE USER:
CREATE USER user
IDENTIFIED BY password
EXTERNALLY
DEFAULT TABLESPACE tablespace
TEMPORARY TABLESPACE tablespace
PROFILE profile
QUOTA integer ON tablespace (np.: dla kilku
przestrzeni)
UNLIMITED
PASSWORD EXPIRE
ACCOUNT LOCK | UNLOCK
Przykład
CREATE USER student
IDENTIFIED BY stud_haslo
DEFAULT TABLESPACE stud_grup
TEMPORARY TABLESPACE stud_temp
PROFILE default
QUOTA 150M ON stud_grup
Zmiana definicji użytkownika
Polecenie ALTER USER:
ALTER USER user
IDENTIFIED BY password
EXTERNALLY
DEFAULT TABLESPACE tablespace
TEMPORARY TABLESPACE tablespace
PROFILE profile
QUOTA integer ON tablespace
PASSWORD EXPIRE
ACCOUNT LOCK | UNLOCK
DEFAULT ROLE ALL | NONE
EXCEPT nazwa_roli
Przykład
ALTER USER student
IDENTIFIED BY studhaslo
DEFAULT TABLESPACE prac_ts
TEMPORARY TABLESPACE temp_ts
PROFILE default
QUOTA
260M ON prac_ts
DEFAULT ROLE all
EXCEPT pracownicy
Usunięcie użytkownika
Polecenie DROP USER:
DROP USER user
CASCADE
Użytkownik aktualnie podłączony do bazy nie może
być usunięty.
Monitorowanie użytkowników
Słownik bazy danych zawiera informacje o:
wszystkich użytkownikach bazy danych
domyślnych przestrzeniach tabel, klasterów,
indeksów dla każdego użytkownika
przestrzeniach używanych dla obiektów
tymczasowych
ograniczeniach przestrzeni
Potrzebne perspektywy słownika danych:
USER_USERS, ALL_USER, DBA_USER,
USER_TS_QUOTAS, DBA_TS_QUOTAS
Zadania DBA związane z obsługą użytkowników
zarządzanie bezpieczeństwem bazy danych
tworzenie, modyfikacja, monitorowanie i
usuwanie użytkowników
przerywanie sesji użytkowników w razie
konieczności
Część II
Uprawnienia i role – nadawanie, odbieranie,
efekt kaskady, jak go uniknąć
Przywileje i role
Przywileje bazodanowe - prawa do
wykonywania określonych operacji na
bazie przez uprawnionych przywilejem
Przywileje dzielimy na:
obiektowe
systemowe
Przywileje systemowe
Pozwalają na wykonywanie określonych czynności na
bazie danych i typach obiektów bazy (tabelach,
sekwencjach, klasterach)
Typy przywilejów:



we własnym schemacie (create table)
na wszystkich obiektach w dowolnym schemacie (update
any table)
w systemie (create session)
Informacje o przywilejach systemowych:
Dba_sys_privs, user_sys_privs, role_sys_privs,
session_privs
Przykłady przywilejów systemowych
(perspektywa System_privilege_map)
ALTER DATABASE - pozwala użytkownikowi na modyfikację
struktury bazy,
CREATE PROCEDURE - pozwala użytkownikowi na tworzenie
w obrębie swojego schematu procedur, funkcji i pakietów
zapisywanych w bazie,
CREATE ROLE - umożliwia użytkownikowi tworzenie ról
bazodanowych,
CREATE SESSION - przywilej ten pozwala użytkownikowi bazy
na otwarcie sesji, czyli połączenie z bazą,
CREATE TABLE - umożliwia użytkownikowi bazy utworzenie
tablicy w obrębie własnego schematu,
UPDATE ANY TABLE - umożliwia użytkownikowi zmianę
zawartości wierszy każdej tablicy w dowolnym schemacie bazy,
ALTER TABLESPACE - zezwala użytkownikowi bazy na
dodawanie nowych plików przestrzenie już istniejące,
CREATE USER - umożliwia tworzenie definicji nowych
użytkowników bazy.
Przywileje obiektowe
Pozwalają na wykonywanie określonych czynności
na konkretnych obiektach bazy (tabeli,
perspektywie, sekwencji, procedurze wbudowanej)
Przykład:
SELECT TABLE adm.pracownik
Użytkownik ma wszystkie przywileje obiektowe na
obiektach własnego schematu.
Przywileje obiektowe nadawane są użytkownikom
bazy, którzy nie są właścicielami obiektu.
Przykłady przywilejów obiektowych
ALTER - ALTER obiekt (tabela lub sekwencja),
CREATE TRIGGER ON obiekt (tylko dla tabel),
DELETE - DELETE FROM obiekt (tabela lub perspektywa),
TRUNCATE obiekt (tylko tabela),
EXECUTE - EXECUTE obiekt (procedura lub funkcja),
INSERT - INSERT INTO obiekt (tabela lub perspektywa),
SELECT - SELECT .....FROM obiekt (tabela, perspektywa lub
replikacja),
UPDATE - UPDATE obiekt (tabela lub perspektywa).
Pełną listę można uzyskać wykonując zapytanie do perspektywy
słownika danych TABLE_PRIVILEGE_MAP.
Nadawanie i odbieranie przywilejów systemowych
Polecenie GRANT:
GRANT system_priv TO user
role
role
PUBLIC
WITH ADMIN OPTION
Polecenie REVOKE:
REVOKE system_priv FROM user
role
role
PUBLIC
Przykład
GRANT CREATE SESSION , CREATE TABLE
TO STUDENT
WITH ADMIN OPTION;
REVOKE SELECT ANY TABLE, CREATE USER
FROM STUDENT
WITH ADMIN OPTION;
Nadawanie i odbieranie przywilejów
obiektowych
Polecenie GRANT:
GRANT list of object_priv
(column1, column2)
ON
object
TO
user
schema role
role
PUBLIC
WITH GRANT OPTION
Polecenie REVOKE:
REVOKE object_priv ON
object
schema
FROM user
role
CASCADE CONSTRAINTS
PUBLIC
Przykład
Nadawanie uprawnień:
GRANT select, update, insert
ON adm.pracownik TO student;
Odbieranie uprawnień:
REVOKE delete, update
ON adm.dochody FROM student;
Role a przywileje
U1
U2
U3
P1
P2
P3
UŻYTKOWNICY
P4 PRZYWILEJE
N*M operacji nadania przywileju
U1
U2
U3
R
P1
P2
UŻYTKOWNICY
ROLE
P3
N+M operacji
P4 PRZYWILEJE
Role - cechy
mogą składać się zarówno z przywilejów
obiektowych jak i systemowych
nie należą do żadnego użytkownika i schematu
mogą być nadane dowolnemu użytkownikowi lub
roli z wyjątkiem siebie
mogą być włączone lub wyłączone dla każdego
użytkownika
mogą wymagać autoryzacji (hasła) do włączania
mogą być sterowane z poziomu systemu
operacyjnego
Zalety używania ról
Ograniczenie liczby wymienianych uprawnień



nadawanie i odbieranie wielu przywilejów jednym
poleceniem
nadawanie roli nowemu użytkownikowi bez pamiętania
wszystkich niezbędnych przywilejów
uproszczenie zarządzania przywilejami w systemach z
wieloma użytkownikami, wieloma tabelami
Dynamiczna obsługa uprawnień


zmienianie przywilejów roli, gdy zmieniają się obowiązki
zmienianie przywilejów wielu użytkownikom zmieniając
jedną rolę
Wybiórcze udostępnianie uprawnień


włączanie i wyłączanie ról, by włączyć i wyłączyć przywileje
tymczasowo
aplikacja może przeglądać słownik danych i włączać lub
wyłączać role w razie potrzeby
Dodatkowe korzyści


zarządzanie przywilejami baz kaskadowych odbierań
przywilejów
możliwość użycia systemu zabezpieczeń systemu
operacyjnego przy zabezpieczaniu bazy danych
Wydajność

mniej indywidualnych przywilejów do sprawdzania i
kodowania w aplikacji
Tworzenie i modyfikacja roli
Polecenie CREATE ROLE
CREATE ROLE role
NOT IDENTIFIED
IDENTIFIED BY password
EXTERNALLY
Polecenie ALTER ROLE
ALTER ROLE role
NOT IDENTIFIED
IDENTIFIED BY password
EXTERNALLY
Przykłady
CREATE ROLE pierwsza;
CREATE ROLE druga IDENTIFIED BY xxzz;
CREATE ROLE trzecia IDENTIFIED
EXTERNALLY;
Nadawanie, odbieranie i usuwanie ról
Nadawanie uprawnień roli – polecenie GRANT:
GRANT create synonym, create table
TO manager
Nadawanie ról - polecenie GRANT:
GRANT role TO user
Odbieranie ról - polecenie REVOKE:
REVOKE role FROM user
Usuwanie ról - polecenie DROP ROLE:
DROP ROLE role
Występowanie efektu kaskady
przywileje obiektowe
with grant option
ADM
with grant option
PRAC
STUD
Użytkownik ADM odbiera uprawnienie użytkownikowi PRAC lub usuwa użytkownika
Efekt:
KASKADY – ani użytkownik ADM ani STUD nie mają już tego prawa
przywileje systemowe i role
with admin option
ADM
with admin option
PRAC
STUD
Użytkownik ADM odbiera uprawnienie użytkownikowi PRAC lub usuwa użytkownika
Efekt:
BRAK KASKADY – użytkownik STUD posiada nadal te uprawnienia
Role OSOPER i OSDBA
OSOPER - pozwala użytkownikowi na wykonanie
STARTUP, SHUTDOWN, ALTER DATABASE
OPEN/MOUNT, ALTER DATABASE BACKUP
CONTROLFILE, ALTER TABLESPACE BEGIN/END
BACKUP, ARCHIVE LOG, RECOVER. Rola ta
zawiera także - przywilej RESTRICTED SESSION
OSDBA - zawiera wszystkie przywileje systemowe
z opcją WITH ADMIN OPTION i rolę OSOPER. Tylko
ta rola pozwala na wykonanie CREATE DATABASE
i odtwarzanie „do czasu” (time-based recovery)
Zadania administratora
Nadawanie użytkownikom praw do
wykonania określonych operacji
zezwalanie i zabranianie dostępu do danych
i możliwości ich zmieniania
zezwalanie i zabranianie możliwości
wykonania funkcji systemowych i zmian
struktury bazy danych
nadawanie przywilejów użytkownikom i rolom
nadawanie przywileju wszystkim
użytkownikom (PUBLIC)
Część III
Profile i ograniczenia na zasoby systemowe
Profile i limity zasobów
Każdy użytkownik jest połączony z jakimś profilem,
który określa ograniczenia do korzystania
z różnych zasobów systemu dostępnych dla
danego użytkownika.
Zasoby
Zasoby systemowe:
 liczba równoległych sesji użytkownika,
 czas CPU
na poziomie sesji użytkownika,
na poziomie pojedynczego wywołania podczas
wykonania zdania SQL,

operacje we/wy
na poziomie sesji użytkownika,
na poziomie pojedynczego wywołania podczas
wykonania zdania SQL,


czas spoczynku (idle time)
czas podłączenia
Profile stosowane są w celu:
Ograniczenia ilości zasobów systemowych dostępnych dla
użytkownika,
Uniemożliwienia użytkownikom operacji zbyt mocno
obciążających zasoby,
Uproszczenia zarządzania zasobami,
Przypisania indywidualnych lub domyślnych limitów
użytkownikom,
Specyfikacji ograniczenia zasobów dla grupy użytkowników,
Zarządzania zasobami w dużych, złożonych systemach
Ograniczenia użycia zasobów na poziomie sesji lub odwołania
(call),
Odłączenia po odpowiednio długim czasie oczekiwania w sesji,
Wylogowania użytkowników jeśli nie pracują (idle).
Zasoby kontrolowane na poziomie sesji lub na
poziomie wywołania
Na poziomie sesji:
CPU_PER_SESSION,
SESSIONS_PER_USER,
CONNECT_TIME,
IDLE_TIME,
LOGICAL_READS_PER
_SESSION,
PRIVATE_SGA
Na poziomie
wywołania:
CPU_PER_CALL
LOGICAL_READS
_PER_CALL
Tworzenie profilu
Polecenie: CREATE PROFILE
CREATE PROFILE profil LIMIT
SESSION_PER_USER
integer
UNLIMITED
DEFAULT
CPU_PER_SESSION
CPU_PER_CALL
CONNECT_TIME
IDLE_TIME
LOGICAL_READS_PER_CALL
LOGICAL_READS_PER_SESSION
COMPOSITE_LIMIT
PRIVATE_SGA
integer
w K lub M
UNLIMITED
DEFAULT
Do tworzenia profilów potrzebny jest przywilej CREATE PROFILE
Zmiana profilu
Polecenie: ALTER PROFILE
ALTER PROFILE profil LIMIT
SESSION_PER_USER
integer
UNLIMITED
DEFAULT
CPU_PER_SESSION
CPU_PER_CALL
CONNECT_TIME
IDLE_TIME
LOGICAL_READS_PER_CALL
LOGICAL_READS_PER_SESSION
COMPOSITE_LIMIT
PRIVATE_SGA
integer
w M lub
UNLIMITED
DEFAULT
Do zmiany definicji profilu potrzebny jest przywilej ALTER PROFILE
Parametry profilu związane z
kontrolą podłączania się do BD (1)
Failed_login_attempts – określa dozwoloną liczbę
nieudanych prób podłączenia się do, po jej przekroczeniu
następuje automatyczne zablokowanie konta użytkownika
na czas określony parametrem password_lock_time
Password_life_time – czas ważności hasła (w dniach); po
jego przekroczeniu haslo musi zostać zmienione
Password_reuse_time – okres czasu, jaki musi upłynąć, by
użytkownik mógł ponownie użyć poprzednie hasło (wtedy
parametr Password_reuse_max przyjmuje wartość
UNLIMITED)
Password_reuse_max – liczba zmian hasła, po
przekroczeniu której użytkownik będzie mógł ponownie
wybrać używane kiedyś hasło (wtedy parametr
Password_reuse_time przyjmuje wartość UNLIMITED)
Parametry profilu związane z
kontrolą podłączania się do BD (2)
Password_lock_time – liczba dni, na jaka
zostanie zablokowane konto użytkownika po
przekroczeniu liczby nieudanych prób
podłączenia się (określonej parametrem
failed_login_attempts)
Password_grace_time – liczba dni przez jakie
hasło będzie jeszcze ważne, po przekroczeniu
czasu jego obowiązywania (określonego
parametrem password_life_time)
Password_verify_function – nazwa funkcji
weryfikacji hasła
Uwaga! Zarządzanie hasłami jest uaktywniane przez wykonanie (jako SYS)
skryptu utlpwdmg.sql.
Przykłady:
CREATE PROFILE pracownik LIMIT
SESSION_PER_USER 4
CPU_PER_CALL UNLIMITED
IDLE_TIME 40;
ALTER PROFILE pracownik LIMIT
SESSION_PER_USER 3
CPU_PER_SESSION 20000
IDLE_TIME 20
LOGICAL_READS_PER_CALL 1500;
Określenie ograniczenia dostępu do zasobów
Dla każdego profilu należy określić
odpowiednie ograniczenia, tzn.: pogrupować
użytkowników, określić ograniczenia dla każdej
grupy.
Aby określić odpowiednie ograniczenia
zasobów trzeba zebrać informacje archiwalne o
użytkowaniu zasobów (o czasie połączenia,
odczytach fizycznych i logicznych).
Profil domyślny (Default)
Istnieje w każdej bazie danych,
Jeżeli użytkownikowi nie nadamy profilu to
ma on profil domyślny,
Dotyczy wszystkich zasobów nie ujętych
w ograniczeniach innych profili,
Początkowo nie ma ograniczeń na zasoby,
Może być zmieniany, tak aby żaden
użytkownik nie miał nieograniczonego
dostępu do zasobów.
Przydzielanie profili (w momencie tworzenia lub
zmiany definicji użytkownika)
Polecenie CREATE USER
CREATE USER asystent IDENTIFIED BY asyst89
DEFAULT TABLESPACE asyst1
TEMPORARY TABLESPACE temp
PROFILE pracownik;
Polecenie ALTER USER
ALTER USER doktor
PROFILE pracownik;
Skutki przydzielania profilu nie są widoczne w bieżącej sesji,
aby przydzielić profil należy mieć przywilej ALTER USER,
profile mogą być przydzielane tylko użytkownikom.
Przykład:
Polecenie: ALTER SYSTEM
ALTER SYSTEM
SET RESOURCE_LIMIT = TRUE
FALSE
Do użycia tej komendy potrzebny jest przywilej ALTER
SYSTEM.
Usuwanie profili
Polecenie: DROP PROFILE
DROP PROFILE profile
CASCADE
profile - nazwa usuwanego profilu
CASCADE - automatyczne przypisanie profilu
DEFAULT użytkownikom związanym z tym profilem
Przykład
DROP PROFILE pracownik CASCADE;
Oglądanie ustawienia profilu
W celu obejrzenia ustawienia profilu należy
skorzystać z perspektyw słownika danych:
 DBA_USERS,
 USER_RESOURCE_LIMITS,
 DBA_PROFILES,
 RESOURCE_COST
Archiwizacja i
odtwarzanie bazy
danych
Część 1
Dlaczego odtwarzanie jest
potrzebne?
W każdej bazie danych istnieje możliwość
wystąpienia awarii
Jeśli wystąpi awaria należy bazę danych
odtworzyć
Podstawowym celem po wystąpieniu
awarii jest przywrócenie efektów działania
wszystkich zatwierdzonych transakcji i jak
najszybszy powrót do normalnej pracy
Typy awarii
Nie wymagające interwencji administratora
Błąd zdania SQL
Awaria procesu
użytkownika
Uszkodzenie instancji
Wymagające interwencji administratora
Błąd użytkownika
Awaria nośnika
Uszkodzenie
instancji
Struktury potrzebne do odtwarzania
Kopie zapasowe bazy danych
Pliki dzienników powtórzeń
Pliki kontrolne
Rekordy wycofania (w przestrzeni
wycofania UNDO)
Pliki bazy danych
Każda baza danych w SZBD ORACLE składa się
z synchronizowanego zestawu: plików danych,
plików dziennika powtórzeń, plików kontrolnych
oraz pliku startowego o nazwie np.: INIT.ORA.
Pliki bazy danych to miejsce, gdzie fizycznie
przechowywane są dane zapisane w bazie.
Przestrzeń dyskowa zajmowana przez pliki bazy
danych jest logicznie podzielona w bazie na
przestrzenie tabel.
Plik startowy jest czytany podczas startu instancji
i zawiera zbiór parametrów startowych, np.:
położenie plików kontrolnych, nazwę bazy danych
itd.
Cykliczne zapisywanie plików
dziennika przez proces LGWR
Zwielokrotnione pliki dziennika powtórzeń
W celu podniesienia bezpieczeństwa Oracle zezwala na
zwielokrotnienie plików dziennika powtórzeń, tworząc tzw. grupy
plików dziennika powtórzeń.
W tej sytuacji proces LGWR równolegle zapisuje te same
informacje do kilku plików dziennika (tworzących jedną grupę).
Pliki kontrolne
Pliki kontrolne to małe pliki binarne zawierające
informacje o fizycznej strukturze bazy danych:



nazwy wszystkich plików tworzących bazę danych wraz
ze ścieżką dostępu,
nazwę bazy danych,
czy daty ostatnich zapisów dokonywanych w plikach
bazy.
Przy montowaniu bazy na podstawie informacji
zawartych w pliku startowym serwer Oracle’a
odszukuje i otwiera pliki kontrolne, z których
wczytywane są informacje o pozostałych plikach
tworzących bazę danych.
Dla zapewnienia bezpieczeństwa bazy danych pliki
kontrolne są zwykle powielane w kilku kopiach na
różnych fizycznie dyskach.
Tryby pracy bazy danych
Tryb Noarchivelog
Tryb Archivelog
Praca bazy w trybie NOARCHIVELOG
Domyślny tryb pracy bazy danych
W tym trybie pliki dziennika powtórzeń używane są
w sposób cykliczny, dane archiwalne są zamazywane przez
bieżąco wpisywane informacje (archiwizowanie plików dziennika
jest zablokowane)
W przypadku awarii można odtworzyć tylko te transakcje,
o których informacje nie zostały jeszcze nadpisane.
Plik dziennika może być użyty ponownie natychmiast
po przejściu punktu kontrolnego. Gdy plik dziennika powtórzeń
jest powtórnie zapisany, odtwarzanie danych jest możliwe tylko
do momentu wykonania ostatniej pełnej kopii.
Tryb ten chroni bazę przed uszkodzeniem instancji,
ale nie zabezpiecza przed awarią nośnika.
Tryb NOARCHIVELOG pozwala na wykonywanie kopii plików
bazy tylko na zamkniętej bazie danych.
Praca bazy w trybie ARCHIVELOG (1)
W tym trybie włączona jest archiwizacja plików
dziennika powtórzeń
Archiwizacja plików dziennika powtórzeń polega na
wykonywaniu kopii ostatnio używanego pliku
dziennika po każdym przełączeniu plików.
Operację kopiowania zapisanych dzienników
powtórzeń wykonuje proces drugoplanowy ARCH.
Zapełniony plik dziennika jest kopiowany
w miejsce wskazane parametrem pliku startowego
LOG_ARCHIVE_DEST
W ten sposób na dysku pozostają kopie wszystkich
zapełnionych plików dziennika powtórzeń, zawierające
wszystkie dane o zmianach wprowadzonych w bazie.
Praca bazy w trybie ARCHIVELOG
(2)
Archiwizacja plików dziennika powtórzeń umożliwia
odtworzenie zasobów bazy zarówno w przypadku
awarii nośnika jak i awarii instancji Oracle’a.
Tryb ARCHIVELOG pozwala na wykonywanie kopii
plików bazy bez konieczności przerywania jej pracy.
Za każdym razem, gdy plik dziennika jest ponownie
użyty, zostaje mu przypisany nowy numer
sekwencyjny (najwyższy).
Przy dużej zmienności danych w bazie kopie plików
dziennika powtórzeń mogą osiągać na dysku duże
rozmiary, należy więc obserwować przyrost, aby nie
dopuścić do przepełnienia dysków serwera.
Praca plików dziennika powtórzeń w trybie
ARCHIVELOG
Zmiana trybu archiwizacji
Użytkownik musi mieć nadany przywilej ALTER SYSTEM, by móc zmieniać tryb
pracy bazy lub być zalogowany jako SYSDBA. Po zmianie trybu pracy bazy powinny
być wykonane kopie wszystkich plików bazy danych.
1. Zamknięcie bazy danych: SHUTDOWN
2. Wykonanie kopii bazy danych
3. Edycja pliku z parametrami: włączenie archiwizacji oraz podanie miejsca,
w którym będą składowane zarchiwizowane pliki dziennika powtórzeń
4. Start i montowanie instancji, bez otwierania bazy danych:
STARTUP MOUNT
5. Zmiana trybu archiwizacji bazy danych oraz otwarcie dla normalnej pracy:
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
6. Zamknięcie bazy danych:
SHUTDOWN IMMEDIATE
7. Wykonanie kopii zapasowej bazy danych
Zmiana trybu pracy bazy danych, zmienia zawartość pliku kontrolnego,
dlatego po zmianie trybu pracy należy wykonać kopię wszystkich plików
bazy danych i plików kontrolnych.
Konfiguracja parametrów archiwizacji
LOG_ARCHIVE_START:
LOG_ARCHIVE_START = TRUE/FALSE
LOG_ARCHIVE_MAX_PROCESSES = n – określa
początkową liczbę procesów archiwizujących ARCn,
uruchamianych podczas startu instancji (domyslnie n = 2):
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=3
Można wskazać miejsce składowania zarchiwizowanych
plików dziennika powtórzeń:
LOG_ARCHIVE_DEST_n dla zwielokrotnionych miejsc
LOG_ARCHIVE_DEST dla pojedynczej lokalizacji
LOG_ARCHIVE_FORMAT
LOG_ARCHIVE_FORMAT=%t_%s_%r.dbf
Automatyczne przełączenie dziennika powtórzeń:
ALTER SYSTEM SWITCH LOGFILE
Wyświetlanie informacji o zarchiwizowanych
plikach dziennika powtórzeń (1)
SQL> ARCHIVE LOG LIST
Database log mode
Mode automatic archival
Archive destination
Oldest online log sequence
Next log sequence to archive
Current log sequence
Archive
Enabled
D:\oracle\oradata\IDDB2\archive
11160
11163
11163
Baza danych pracuje w trybie ARCHIVELOG
Automatyczna archiwizacja jest dostępna
Miejsce składowania zarchiwizowanych plików dziennika powtórzeń
D:\oracle\oradata\IDDB2\archive
Numer najstarszego wypełnionego pliku dziennika powtórzeń - 11160
Następny numer przeznaczony do archiwizacji to 11163
Bieżący dziennik powtórzeń ma numer sekwencyjny 11163
Rekordy wycofania (UNDO)
Rekordy wycofania są przechowywane
w przestrzeni wycofania (UNDO).
Podczas odtwarzania bazy danych Oracle aplikuje
wszystkie zmiany wykonane w bazie zapisane
w plikach dziennika powtórzeń (rolling forward)
a następnie na podstawie informacji zapisanych
w rekordach wycofania wycofuje wszystkie
niezatwierdzone transakcje (rolling back).
We wcześniejszych wersjach informacje
o niezatwierdzonych transakcjach, przechowywane
były w segmentach wycofania.
Spójna i niespójna kopia bazy danych
Spójna kopia bazy danych zawiera pliki o tym
samym systemowym numerze zmiany (SCN),
wykonywana po czystym zamknięciu bazy
danych.
Spójna kopia to kopia, której wszystkie pliki
danych (read/write) oraz plik kontrolny pochodzą z
tej samej chwili czasowej.
Spójna kopia po odzyskaniu nie wymaga
dodatkowego odtwarzania.
Niespójna kopia bazy danych to kopia jednego lub
kilku plików danych wykonywana, gdy baza
danych była otwarta lub zamknięta z opcją
ABORT (wymaga po odzyskaniu odtwarzania
z archiwalnych plików dziennika powtórzeń).
Typy kopii zapasowych
Kopie
Fizyczna
Pełna
Logiczna (Export)
Częściowa
Gorąca Zimna Gorąca Zimna
Pełna kopia bazy danych
Pełna kopia bazy danych zawiera kopie
wszystkich plików danych i pliku kontrolnego.
Najczęściej wykonywany typ kopii zapasowej.
Pełna kopia bazy danych może być
wykonywana zarówno w trybie ARCHIVELOG
jak i NOARCHIVELOG.
Pełna kopia zapasowa może być spójna jak
i niespójna.
Częściowa kopia bazy
Jest kopią wybranej części bazy danych
Przykłady kopii częściowych:



Kopia wybranej przestrzeni tabel
Kopia pliku kontrolnego
Kopia wybranego pliku z danymi
Kopie częściowe są stosowane, gdy baza
pracuje w trybie ARCHIVELOG
Kopia przestrzeni tabel
Kopia wszystkich plików danych wchodzących
w skład kopiowanej przestrzeni tabel
Jeśli przestrzeń tabel users składa się z trzech
plików danych, kopia musi także zawierać te trzy
pliki.
Archiwizowana przestrzeń tabel może być
włączona (online) lub wyłączona (offline).
Kopia przestrzeni tabel jest poprawna w sytuacji,
gdy baza danych pracuje w trybie
ARCHIVELOG.
Kopia pliku danych
Kopia pojedynczego pliku danych
Wykonywana zwykle, gdy baza danych
pracuje w trybie ARCHIVELOG.
Kopia ta jest poprawna, gdy baza pracuje
w trybie NOARCHIVELOG w przypadku,
gdy:


Wszystkie pliki danych przestrzeni są
archiwizowane
Pliki danych są w trybie read only lub offlinenormal.
Kopia pliku kontrolnego
Tworzenie kopii pliku kontrolnego jest bardzo ważnym
elementem archiwizacji i odtwarzania bazy danych.
Bez pliku kontrolnego nie można zamontować ani otworzyć
bazy danych.
Można skonfigurować RMAN, by kopia pliku kontrolnego
była wykonywana automatycznie:
CONFIGURE CONTROLFILE AUTOBACKUP
Można ręcznie tworzyć kopie pliku kontrolnego:



W narzędziu RMAN polecenie
BACKUP CURRENT CONTROLFILE
tworzy binarną kopię pliku kontrolnego.
W narzędziach SQL polecenie
ALTER DATABASE BACKUP CONTROLFILE
tworzy binarną kopię pliku kontrolnego.
Polecenie SQL
ALTER DATABASE BACKUP CONTROLFILE TO TRACE
tworzy skrypt SQL, który może być wykorzystany do utworzenia
nowego pliku kontrolnego.
Planowanie tworzenia kopii bazy danych (1)
1.
2.
Zdefiniowanie strategii archiwizacji i odtwarzania przed
utworzeniem bazy danych,
Wybranie odpowiedniego trybu pracy bazy danych.
Odpowiedzenie sobie na następujące pytania:



3.
4.
Czy można pozwolić sobie na utratę danych w przypadku awarii
nośnika?
Czy baza danych musi stale pracować?
Czy procesy drugoplanowe ARC(n) powinny pracować
automatycznie czy nie?
Należy mieć zwielokrotnione pliki dzienników powtórzeń
i plików kontrolnych, w celu wyeliminowania awarii,
w przypadku utraty jednego z nich
Należy zdefiniować częstotliwość tworzenia kopii
zapasowych.
Planowanie tworzenia kopii bazy danych
(2)
5. Należy wykonywać właściwe kopie
bezpieczeństwa zarówno przed jak i po
zmianie struktury bazy danych,
6. Powinno się częściej wykonywać kopie
przestrzeni tabel, w których dane często się
zmieniają,
7. Należy zdefiniować jak długo będzie się
trzymać kopie,
8. Powinno się posiadać jedną lub dwie kopie
poprzedzające ostatnią kopię,
9. Należy także wykonywać eksport danych.
Wyświetlanie plików bazy danych
Lista plików danych
SQL> SELECT NAME FROM V$DATAFILE;
Lista przestrzeni tabel wraz z powiązanymi z nimi plikami danych
SELECT t.NAME „Tablespace", f.NAME "Datafile"
FROM V$TABLESPACE t, V$DATAFILE f
WHERE t.TS# = f.TS#
ORDER BY t.NAME;
Nazwy plików dziennika powtórzeń
SQL> SELECT MEMBER FROM V$LOGFILE;
Nazwy plików kontrolnych
SQL> SELECT NAME FROM V$CONTROLFILE;
Informacje o plikach danych wchodzących w skład archiwizowanej przestrzeni tabel
SELECT t.name "TB_NAME", d.file# "DF#",
d.name "DF_NAME", b.status
FROM V$DATAFILE d, V$TABLESPACE t, V$BACKUP b
WHERE d.TS#=t.TS# AND b.FILE#=d.FILE#
AND b.STATUS='ACTIVE'
TB_NAME
DF#
------------- -----------TOOLS
7
USERS
8
DF_NAME
-----------------------------/oracle/oradata/trgt/tools01.dbf
/oracle/oradata/trgt/users01.dbf
STATUS
------ACTIVE
ACTIVE
Pełna „zimna” systemowa kopia (kroki)
W skład kopii bazy powinny wejść następujące grupy plików:




pliki danych,
pliki dziennika powtórzeń,
pliki kontrolne,
plik z parametrami
Baza danych pracuje w trybie NOARCHIVELOG
Kroki tworzenia zimnej systemowej kopii danych:




utworzenie aktualnej listy wszystkich plików do skopiowania:
nazwy plików danych bazy można uzyskać w wyniku zapytania:
SELECT FILE_NAME FROM DBA_DATA_FILES;
nazwy plików dziennika powtórzeń można uzyskać w wyniku
zapytania:
SELECT member FROM v$logfile;
a wyświetlenie nazwy plików kontrolnych, wykorzystując polecenie:
SHOW PARAMETER control_files;
zamknięcie instancji poleceniem SHUTDOWN,
skopiowanie wszystkich plików danych, plików dziennika powtórzeń
i plików kontrolnych przy użyciu odpowiedniego polecenia systemu
operacyjnego,
wystartowanie instancji poleceniem STARTUP.
Zalety i wady pełnej zimnej kopii
systemowej
Zalety
prosta i łatwa do
wykonania,
wymaga niewielkiego
udziału administratora,
pewna
Wady
Wymaga zamknięcia
bazy danych (jest
niedostępna dla
użytkowników)
Tworzenie kopii wyłączonych przestrzeni tabel
i plików danych (1)
Kopia przestrzeni tabel lub plików danych, gdy te mogą być
wyłączone
Użytkownik musi należeć do grupy DBA i systemowy
przywilej MANAGE TABLESPACE, by móc włączać
i wyłączać przestrzenie tabel.
Nie można wyłaczyć systemowej przestrzeni tabel
i przestrzeni, która zawiera aktywny segment wycofania.
Pliki danych należące do przestrzeni tabel:
SELECT TABLESPACE_NAME, FILE_NAME FROM
SYS.DBA_DATA_FILES
WHERE TABLESPACE_NAME = 'USERS';
TABLESPACE_NAME
---------------USERS
FILE_NAME
-------------------------------/oracle/oradata/trgt/users01.dbf
Tworzenie kopii wyłączonych przestrzeni tabel
i plików danych (2)
Wyłącz archiwizowaną przestrzeń tabel:
SQL> ALTER TABLESPACE users OFFLINE NORMAL;
Wykonaj kopię plików danych wyłączonej przestrzeni tabel
(używając odpowiednich poleceń systemu operacyjnego)
Włącz zarchiwizowaną przestrzeń tabel:
ALTER TABLESPACE users ONLINE;
Zarchiwizuj bieżące pliki dziennika powtórzeń (potrzebne
do odtworzenia kopii)
ALTER SYSTEM ARCHIVE LOG CURRENT;
Tworzenie kopii włączonych przestrzeni tabel
i plików danych
Można wykonywać kopie wszystkich lub tylko wybranych
plików danych włączonej przestrzeni tabel na otwartej bazie
danych. Baza danych musi wtedy pracować w trybie
ARCHIVELOG. Sposób wykonywania kopii jest inny, gdy
włączona przestrzeń tabel jest w trybie read/write, a inny gdy
w trybie read-only.
READ/WRITE
Należy zidentyfikować wszystkie pliki należące do
archiwizowanej przestrzeni tabel, stosując perspektywę
słownika bazy danych DBA_DATA_FILES.
Zaznaczyć, że przestrzeń tabel będzie archiwizowana:
SQL> ALTER TABLESPACE users BEGIN BACKUP;
W czasie tego typu archiwizacji wszystkie pliki należące do
archiwizowanej przestrzeni tabel mogą być modyfikowane. Dlatego należy
ustawić przestrzeń tabel w tryb archiwizowania (backup mode), który
zatrzymuje modyfikację nagłówków plików archiwizowanej przestrzeni
tabel (blokuje zmianę numeru sekwencyjnego dziennika powtórzeń).
Tworzenie kopii włączonych przestrzeni tabel
i plików danych (2)
Skopiowanie wybranych plików archiwizowanej przestrzeni
tabel, używając poleceń systemu operacyjnego
Wyprowadzenie przestrzeni tabel z trybu archiwizowania
SQL> ALTER TABLESPACE users END BACKUP;
by przywrócić normalną obsługę plików podczas punktów
kontrolnych
Nagłówki plików należących do archiwizowanej przestrzeni
tabel zostaną uaktualnione po kolejnym przełączeniu pliku
dziennika.
Kroki te mogą zostać wykonywane dla wszystkich
przestrzeni tabel bazy danych.
Archiwizacja bieżących plików dziennika powtórzeń
(potrzebnych do odtworzenia kopii)
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
Równoległa archiwizacja włączonych
przestrzeni tabel
Można równolegle przygotować kopię włączonych przestrzeni
tabel i ustawić ich tryb na archiwizowanie. W tym celu należy:
Ustawić wszystkie archiwizowane przestrzenie tabel na tryb
archiwizacji:
SQL> ALTER TABLESPACE users BEGIN BACKUP;
SQL> ALTER TABLESPACE tools BEGIN BACKUP;
Jeśli archiwizowane będą wszystkie przestrzenie bazy danych:
SQL> ALTER DATABASE BEGIN BACKUP;
Zarchiwizować wszystkie włączone przestrzenie
Zamknąć tryb archiwizacji, każdej z przestrzeni tabel:
SQL> ALTER TABLESPACE users END BACKUP;
SQL> ALTER TABLESPACE tools END BACKUP;
Lub wszystkich od razu:
SQL> ALTER DATABASE END BACKUP;
Zarchiwizować bieżące pliki dziennika powtórzeń (potrzebne
do odtworzenia kopii)
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
Pełna „gorąca” systemowa kopia
Kopia systemowa z archiwizacją umożliwia odtworzenie stanu bazy do
czasu tuż przed wystąpieniem awarii.
Wymaga jednak dużej ilości wolnej przestrzeni dyskowej potrzebnej do
składowania zarchiwizowanych plików dziennika powtórzeń i może
nieznacznie spowodować spowolnienie pracy.
Aby wykonać zrzut gorący całej bazy danych, należy zmienić tryb pracy
każdej przestrzeni tabel. Nie powinno się wykonywać kopii wszystkich
przestrzeni tablic jednocześnie.
“gorący backup” bazy wykonuje się wydając sekwencję poleceń kolejno
dla wszystkich przestrzeni tablic bazy:



przygotowanie przestrzeni tablic do kopiowania poleceniem:
ALTER TABLESPACE nazwa_przestrzeni_tabel BEGIN
BACKUP;
Powyższa akcja zawiesza zmiany numeru sekwencyjnego w plikach
należących do kopiowanej przestrzeni. Numery sekwencyjne w plikach kopii
zabezpieczającej mogą różnić się od siebie, jeżeli przestrzenie tablic zrzucane
były jedna po drugiej,
skopiowanie plików tworzących przestrzeń tabel na poziomie systemu
operacyjnego,
koniec kopiowania komendą:
ALTER TABLESPACE nazwa_przestrzeni_tablic END
BACKUP;
Powyższa akcja umożliwia uaktualnienie nagłówków plików należących do
kopiowanej przestrzeni przy następnym przełączeniu.
Kopia przestrzeni tabel pracujących
w trybie Read-Only (kroki)
Stosując perspektywę słownika danych DBA_TABLESPACES można
określić które przestrzenie są w trybie read-only:
SELECT TABLESPACE_NAME, STATUS
FROM DBA_TABLESPACES WHERE STATUS = 'READ ONLY';
Przed rozpoczęciem tworzenia kopii stosując perspektywę
DBA_DATA_FILES można uzyskać informacje o plikach wchodzących
w skład przestrzeni tabel.
SELECT TABLESPACE_NAME, FILE_NAME
FROM SYS.DBA_DATA_FILES
WHERE TABLESPACE_NAME = 'HISTORY';
TABLESPACE_NAME
----------------HISTORY
HISTORY
FILE_NAME
----------------------------------/oracle/oradata/trgt/history01.dbf
/oracle/oradata/trgt/history02.dbf
Kopiowanie plików włączonej przestrzeni w trybie read-only (stosując
polecenia systemu operacyjnego), nie trzeba wyłączać przestrzeni ani
zmieniać trybu na backup mode, gdyż dane są chronione przed zapisem.
Dodatkowo można wyeksportować dane przestrzeni tabel, a następnie
w przypadku awarii nośnika lub błędu użytkownika można szybko
odtworzyć dane importując je.
Kopia pliku kontrolnego
Kopia pliku kontrolnego w postaci pliku binarnego
Kopia pliku kontrolnego w postaci skryptu SQL
tworzącego nowy plik kontrolny
Informacje zawarte w pliku kontrolnym są niezbędne
podczas startu instancji, zawierają informacje o strukturze
bazy danych jest więc konieczne posiadanie aktualnej
wersji pliku kontrolnego (po każdej zmianie konfiguracji
bazy należy wykonać kopie pliku kontrolnego).
By wykonać kopię pliku kontrolnego należy posiadać
przywilej ALTER DATABASE .
Kopia binarna pliku kontrolnego
Podstawowym sposobem tworzenia kopii pliku kontrolnego jest
zastosowanie polecenia SQL tworzącego binarne archiwum tego
pliku.
Kopia binarna jest korzystniejsza niż skrypt SQL, gdyż (jeśli
zastosuje się narzędzie RMAN to zawiera także informacje
dodatkowe jak: historie zarchiwizowanych plików dziennika
powtórzeń, informacje, które przestrzenie są offline, jakie są zakresy
offline, zbiory archiwum i kopie.
Tworzenie kopii pliku kontrolnego po modyfikacji struktury
bazy danych:

Wprowadź zmiany w strukturze, np..: tworząc nową przestrzeń
tabel:
CREATE TABLESPACE tbs_1 DATAFILE 'file_1.f'
SIZE 10M;

Wykonaj binarną kopię pliku kontrolnego, podając nazwę pliku
wyjściowego:
ALTER DATABASE BACKUP CONTROLFILE TO
'/disk1/backup/cf.bak' REUSE;
Dodaj opcję REUSE by utworzyć nowy plik kontrolny,
nadpisując istniejący.
Skrypt tworzący plik kontrolny
Opcja TRACE polecenia ALTER DATABASE
BACKUP CONTROLFILE pozwala na
zarządzanie
i odtwarzanie pliku kontrolnego, poprzez
wygenerowanie skryptu SQL, tworzącego nowy
plik kontrolny.
Polecenia w skrypcie SQL pozwalają na:



uruchomienie bazy danych,
zrekonstruowanie pliku kontrolnego,
odtworzenie i otwarcie bazy danych.
W celu otrzymania skryptu, który automatycznie
odtworzy plik kontrolny, należy wykonać
następujące polecenie::
ALTER DATABASE BACKUP CONTROLFILE TO
TRACE;
Tworzenie logicznych kopii danych przy
użyciu narzędzi eksportu Oracle’a
Narzędzia eksportu i importu przenoszą dane z i do bazy danych.
Narzędzia eksportu zapisują eksportowane obiekty bazy danych do
pliku systemu operacyjnego, w odpowiednim dla Oracle’a formacie.
Narzędzia importu mogą czytać pliki powstałe w wyniku wykonania
eksportu i odtwarzać wyeksportowane obiekty.
W Oracle istnieją dwa rodzaje narzędzi importu i eksportu: oryginalne
Import i Export (znane z poprzednich wersji) oraz Data Pump Import
i Export (od wersji Oracle Database Release 10g).
Zalety eksportu:






zachowuje definicje tabel lub dane w określonym momencie czasu,
zachowuje definicje tabel (z danymi lub bez), umożliwiając załadowanie ich
do bazy w terminie późniejszym,
umożliwia przeniesienie danych z jednego serwera na drugi (w połączeniu
z programem Imp),
przenosi dane pomiędzy różnymi wersjami Oracle’a,
zapewnia ochronę przed błędem aplikacji, pozwalając odtworzyć tabelę lub
zestaw tabel do momentu eksportu bez konieczności wycofywania zmian
w całej bazie,
reorganizuje tabelę, eliminując łączenie (chaining) i fragmentację.
Export – logiczna kopia bazy danych
Tryby eksportu:



tryb tabel (table) - eksport podanych tabel (własnych),
tryb użytkowników (user) - eksport wszystkich obiektów danego
użytkownika (tabele, przywileje, indeksy),
tryb pełnej bazy (full database ) - eksport wszystkich obiektów bazy.
Tylko użytkownicy posiadający przywilej EXP_FULL_DATABASE
mogą wykonać pełny eksport bazy, natomiast wszyscy pozostali
użytkownicy mogą wykonywać eksport w trybie tabel i użytkowników.
W celu skrócenia czasu wykonywania eksportu należy wykonywać
jeden z trzech typów:



FULL - pełny eksport (wszystkie tabele i dane),
INCREMENTIAL - eksport przyrostowy (tylko obiekty, które zmieniły się od
ostatniego eksportu dowolnego typu),
CUMULATIVE - eksport kumulacyjny (wszystkie obiekty, które się zmieniły
od ostatniego eksportu kumulacyjnego lub pełnego).
We wszystkich typach eksportu eksportowane są całe tabele, a nie
tylko zmienione rekordy.
Skrypt catexp.sql tworzy tabele SYS.INCEEXP, SYS.INCFIL,
SYS.INCVID, w których umieszczane są informacje o eksportach
przyrostowych.
Utrzymywanie informacji o bieżących
i zarchiwizowanych plikach bazy
danych
Jednym z ważnych aspektów zarządzania
archiwizacją i odtwarzaniem jest przechowywanie
informacji o bieżących plikach bazy danych oraz
kopiach tych plików. Powinno się przechowywać
informacje o położeniu:





Plików danych i plików kontrolnych
Aktywnych i zarchiwizowanych plików dziennika
powtórzeń)
Pliku z parametrami
Plików haseł
itd.
Informacje o położeniu plików z danymi, plików
kontrolnych i aktywnych plików dziennika
powtórzeń
Skrypt wyświetla położenie plików
kontrolnych, plików z danymi i aktywnych
plików dziennika powtórzeń:
SELECT NAME FROM V$DATAFILE
UNION ALL SELECT MEMBER
FROM V$LOGFILE
UNION ALL
SELECT NAME FROM V$CONTROLFILE;
Informacje o położeniu zarchiwizowanych
plików dziennika powtórzeń
Wyświetlenie informacji o położeniu zarchiwizowanych plików
dziennika powtórzeń :
SELECT NAME, VALUE FROM V$PARAMETER
WHERE NAME LIKE log_archive_dest%
AND VALUE IS NOT NULL;
NAME
------------------log_archive_dest_1
log_archive_dest_state_1
VALUE
---------------------------------LOCATION=/oracle/work/arc_dest/arc
enable
Określenie formatu nazwy zarchiwizowanych plików dziennika
powtórzeń:
SHOW PARAMETER LOG_ARCHIVE_FORMAT
Lista wszystkich zarchiwizowanych plików dziennika powtórzeń,
o których informacje są zawarte w pliku kontrolnym:
SELECT NAME FROM V$ARCHIVED_LOG;
Narzędzie DBVERIFY
DBVERIFY program jest zewnętrznym
interpreterem poleceń, który umożliwia
sprawdzenie integralności fizycznej struktury
wyłączonych (OFFLINE) plików.
Jest stosowane w celu sprawdzenia
poprawności ręcznie wykonanej kopii pliku
danych przed jej odtworzeniem.
Nazwa i lokalizacja tego narzędzie zależy od
systemu operacyjnego.
Archiwizacja i
odtwarzanie bazy
danych
Część 2
Archiwizacja, odzyskiwanie, odtwarzanie
Archiwizacja – to tworzenie archiwum (kopii) bazy
danych (plików z danymi, pliku kontrolnego i
zarchiwizowanych plików dziennika powtórzeń).
Odzyskiwanie bazy danych z kopii zapasowej – to
przekopiowanie fizycznych plików tworzących bazę
z kopii do miejsc, w których się znajdują podczas
normalnej pracy bazy danych.
Odtwarzanie bazy danych – to proces
modyfikowania plików bazy danych odzyskanych
z kopii poprzez wprowadzanie zmian zapisanych
w plikach dziennika powtórzeń i wycofywania zmian
zapisanych w przestrzeni wycofania (UNDO).
Odtwarzanie bazy w wyniku
wystąpienia awarii wymaga:
Określenia jakie struktury danych zostały uszkodzone
i które wymagają odtwarzania
Zastosowania odpowiednich kroków odtwarzania
Ponownego startu bazy danych
Upewnienia się, że prace nie zostały utracone oraz,
że w bazie danych nie znajdują się niepoprawne
dane.
Podstawowym zadaniem jest powrót do normalnej
pracy tak szybko jak to tylko możliwe.
Sposoby odtwarzania
Oracle oferuje kilka sposobów strategii odtwarzania:
Odtwarzanie z powodu systemowej, programowej lub
sprzętowej awarii.
Automatyczne odtwarzanie instancji bazy danych
podczas startu bazy danych.
Odtwarzanie poszczególnych wyłączonych przestrzeni
tabel lub plików, podczas, gdy pozostała część bazy
danych pracuje.
Niepełne odtwarzanie do punktu w czasie lub
przerwania, by odtworzyć bazę danych w stanie
spójnym.
Narzędzia Export i Import dla logicznej archiwizacji
i odtwarzania bazy danych.
Cache Recovery (Rolling Forward)
Aktywny dziennik powtórzeń jest zbiorem plików systemu
operacyjnego, w których są zapisywane wszystkie zmiany
wykonywane na bloku danych, zawierającym dane, indeks itd.,
zarówno te zatwierdzone jak i niezatwierdzone.
Pierwszym krokiem odtwarzania po awarii instancji lub nośnika
jest odtwarzanie w przód (cache recovery lub rolling forward),
czyli ładowanie wszystkich zmian z dziennika powtórzeń.
Odtwarzanie w przód zwykle aplikuje zmiany z aktywnych
plików dziennika powtórzeń (odtwarzanie instancji lub
odtwarzanie po awarii nośnika), może także aplikować zmiany
z archiwizowanych plików dziennika powtórzeń (tylko
w przypadku odtwarzania po awarii nośnika).
Po odtwarzaniu w przód bloki danych zawierają wszystkie
zatwierdzone zmiany. Mogą także zawierać niezatwierdzone
zmiany, które zostały zapisane do pliku danych przed awarią
lub zapisane tylko w pliku dziennika powtórzeń i wprowadzone
podczas odtwarzania w przód.
Transaction Recovery (Rolling Back)
Oracle można uruchomić w dwóch trybach wycofania:
automatycznym lub ręcznym.
W ręcznym trybie, należy utworzyć segment wycofania i zarządzać
nim, tak by zapisywane w nim były zmiany, które powinny zostać
wycofane.
W automatycznym trybie wycofania można utworzyć jedną lub
więcej przestrzeni wycofania. Utworzona przestrzeń zawiera
segmenty wycofania (undo segments) podobne do tradycyjnych
segmentów wycofania.
Bloki wycofania (w segmentach wycofania lub przestrzeniach
UNDO) zapisują akcje bazy danych, które powinny być wycofane.
W procesie odtwarzania bazy danych bloki wycofania wycofują
efekty niezatwierdzonych transakcji, które zostały wprowadzone
w fazie odtwarzania w przód.
Po fazie odtwarzania w przód wszystkie zmiany, które nie zostały
zatwierdzone muszą być wycofane. Oracle aplikuje bloki UNDO, by
wycofać niezatwierdzone zmiany. Taki proces nazywany jest
odtwarzaniem w tył (rolling back lub transaction recovery).
Podstawowe etapy odtwarzania:
Rolling Forward i Rolling Back
Odtwarzania po awarii nośnika
Awaria nośnika występuje wtedy, gdy uszkodzony
zostanie plik, jego fragment lub dysk. Nie można
nic odczytać ani zapisać.
Odtwarzanie po awarii nośnika może mieć rożne
formy, zależne od trybu archiwizacji w którym baza
pracuje.
Jeśli w procesie odtwarzania korzystamy z kopii
zapasowej i ładujemy zarchiwizowane pliki
dziennika powtórzeń taki typ odtwarzania
nazywany jest media recovery.
Block media recovery to bardziej specjalizowana
operacja w której używa się w sytuacji, gdy tylko
kilka bloków w jednym lub kilku plikach jest
uszkodzonych.
Media Recovery (przykład)
Odtwarzanie, gdy baza pracuje w trybie
NOARCHIVELOG
Jeśli baza danych pracuje w trybie
NOARCHIEVLOG aktywne pliki dziennika są
ponownie zapisywane, ich archiwizacja jest
zablokowana. Odtwarzanie po awarii nośnika
sprowadza się do zwykłego odzyskania
plików z ostatniej pełnej kopii zapasowej.
Wszystkie prace realizowane po wykonaniu
pełnej kopii są utracone i muszą być
wykonane powtórnie, po odzyskaniu
uszkodzonych plików.
Kroki stosowane przy odtwarzaniu
z ostatniej kopii zapasowej w trybie
NOARCHIVELOG (1)
1. Jeśli baza jest otwarta – należy ją
zamknąć:
SHUTDOWN ABORT
2. Jeśli problem sprzętowy, będący przyczyną
awarii został usunięty, pliki z kopii mogą
zostać odzyskane w oryginalnej ich
lokalizacji.
Kroki stosowane przy odtwarzaniu
z ostatniej kopii zapasowej w trybie
NOARCHIVELOG (2)
Jeśli awarii nie da się usunąć, należy odzyskać pliki do
alternatywnej lokalizacji. W tej sytuacji należy:





Odzyskać wszystkie pliki z ostatniej pełnej kopii – wszystkie pliki z
danymi i pliki kontrolne, nie tylko uszkodzone pliki. To gwarantuje, że
wszystkie pliki będą zsynchronizowane do jednego punktu w czasie,
Jeśli to konieczne, wyedytować odzyskany plik z parametrami, by
podać w nim nową lokalizację plików kontrolnych,
Wystartować instancję i zamontować bazę danych, ale nie otwierać:
STARUP MOUNT
Wykonać kroki konieczne do zmiany lokalizacji plików z danymi
ALTER DATABASE CREATE DATAFILE
‘c:/oracle/users01.dbf’ as ‘d:/oracle/users01.dbf’,
powtórzyć dla plików dziennika
Wykonać polecenie
ALTER DATABASE OPEN RESETLOGS
które otworzy bazę danych i ustawi numer sekwencyjny bieżącego
pliku dziennika powtórzeń na 1.
Odtwarzanie po awarii instancji
Odtwarzanie instancji jest wykonywane, gdy instancja
ulegnie uszkodzeniu, np. gdy została niespodziewanie
zamknięta (wyłączenie prądu, awaria procesu
drugoplanowego) lub zamknięta poleceniem
SHUTDOWN ABORT lub otwarta STARTUP FORCE,
Odtwarzanie instancji pozwala przywrócić bazę do
spójnego stanu transakcyjnego istniejącego tuż przed
awarią.
Jeśli awaria instancji nastąpi w trakcie wykonywania
kopii zapasowej na otwartej bazie danych, będzie
wymagane takie odtwarzanie jak przy awarii nośnika
We wszystkich pozostałych przypadkach ORACLE
automatycznie wykona odtwarzanie instancji podczas
restartu bazy danych.
Odtwarzanie po awarii instancji lub
systemu (1)
Celem odtwarzania po awarii systemu lub instancji jest
odzyskanie zmian w bloku danych zapisanych
w pamięci cache zamkniętej instancji i zamknięcie wątku
dziennika powtórzeń, który pozostał otwarty.
Przy odtwarzanie po awarii instancji lub systemu stosuje się
tylko aktywne pliki dziennika powtórzeń
i bieżące aktywne pliki danych. ORACLE odtwarza także wątki
dzienników powtórzeń zamkniętych instancji.
Odtwarzanie po awarii systemu lub instancji obejmuje dwie
różne operacje:


odtwarzanie w przód (rolling forward) bieżących aktywnych plików
danych przez zaaplikowanie im zarówno potwierdzonych jak
i niepotwierdzonych transakcji, zawartych w aktywnych plikach
dziennika powtórzeń,
Odtwarzanie w tył (rolling back) – wycofywanie zmian wykonanych
w ramach niezatwierdzonych transakcji, do ich oryginalnego stanu
Odtwarzanie po awarii nośnika –
baza w trybie Archivelog
Podczas odtwarzania po awarii
nośnika w celu odtworzenia plików
danych ładowane są archiwizowane
pliki dziennika powtórzeń.
Typy odtwarzania po awarii
nośnika
Pełne odtwarzanie


minimalizuje nakład pracy,
odtwarza stan do chwili tuż przed awarią,
Niepełne odtwarzanie

odtwarza stan bazy do pewnej chwili przed
awarią.
Odtwarzanie wszystkich transakcji
po awarii nośnika
Odtworzenie wszystkich transakcji po awarii jest możliwe,
gdy baza danych pracuje w trybie ARCHIVELOG.
Pliki danych ściągnięte z kopii zabezpieczającej mają
numery sekwencyjne, zawarte w nagłówkach, niezgodne z
numerem zawartym w pliku kontrolnym. Na tej podstawie
SZBD Oracle określa, że jest potrzebne odtwarzanie.
Zarchiwizowane pliki dziennika powtórzeń pozwalają na
odtworzenie wszystkich zatwierdzonych transakcji
w momencie awarii.
Odtwarzanie rozpocznie się od najstarszego numeru
sekwencyjnego odkrytego w nagłówkach plików, ważne jest,
by ściągnąć kopie tylko plików danych, a nie pliku
kontrolnego.
W przeciwnym razie zaistnieje niezgodność numerów
sekwencyjnych.
Odtwarzanie wszystkich transakcji
po awarii nośnika (2)
Użycie kopii zabezpieczającej pliku kontrolnego
jest dopuszczalne, w momencie gdy wszystkie
aktywne pliki kontrolne zostały zniszczone lub gdy
plik kontrolny ma być dopasowany do starej kopii
bazy danych.
Jeżeli najstarszy numer sekwencyjny znajdujący
się w nagłówku pewnego pliku danych jest zgodny
z numerem aktywnego pliku dziennika,
odtwarzanie dokona się automatycznie.
Bazę danych można odtwarzać do stanu przed
awarią lub do określonego punktu w czasie przed
awarią.
Rodzaje pełnego odtwarzania po
awarii nośnika
Pełne odtwarzanie przy zamkniętej bazie
danych
Otwarta baza danych – wyłączone
odtwarzane przestrzenie tabel (odtwarzanie
częściowe)
Otwarta baza danych – wyłączona przestrzeń
tabel – odtwarzanie indywidualnego pliku
danych (odtwarzanie częściowe)
Pełne odtwarzanie bazy danych
z zastosowaniem kopii pliku kontrolnego
Pełne odtwarzanie przy zamkniętej
bazie danych
Pełne odtwarzanie wszystkich lub pojedynczych
uszkodzonych plików danych jest wykonywane,
gdy baza danych jest zamontowana, ale nie
otwarta i tak uszkodzona, że nie jest możliwa jej
normalna praca ani otwarcie dla użytkowników.
Ten typ odtwarzania jest stosowany
w następujących sytuacjach:


Baza danych nie musi być otwarta
Uszkodzone pliki zawierają dane wchodzące w skład
systemowej przestrzeni tabel lub przestrzeni
zawierającej aktywne segmenty wycofania lub
przestrzeni UNDO
Kroki jakie muszą być
wykonane
Zamknięcie bazy danych
SHUTDOWN ABORT
Odtworzenie z najświeższej kopii zapasowej
Uruchomienie bazy danych w trybie montowania


Connect …. as SYSDBA;
Startup mount pfile = ‘…….’;
Odtworzenie bazy danych

Recover database;
Otwarcie bazy danych

Alter database open;
Przykład
Przed odtwarzaniem:
Plik kontrolny
Log #27
Plik danych 01
Log #15
Plik danych 02
Log #18
Po odtwarzaniu:
Plik kontrolny
Log #27
Plik danych 01
Log #27
Plik danych 02
Log #27
Należy użyć bieżącego pliku kontrolnego i plików danych
z najświeższej kopii zapasowej
Pełne odtwarzanie wyłączonych
przestrzeni tabel (1)
Pełne odtwarzanie jest wykonywane, gdy baza
danych musi być otwarta; nieuszkodzone
przestrzenie tabel są włączone i dostępne dla
użytkowników, podczas gdy uszkodzona przestrzeń
tabel jest wyłączona i wszystkie pliki wchodzące
w jej skład muszą być odtworzone w całości.
Odtwarzanie wyłączonej przestrzeni tabel jest
stosowane gdy:


Nieuszkodzone przestrzenie tabel muszą być dostępne
dla normalnej pracy,
Pliki uszkodzone w wyniku awarii nie zawierają danych,
wchodzących w skład systemowej przestrzeni tabel,
przestrzeni zawierającej aktywne segmenty wycofania lub
przestrzeni UNDO.
Pełne odtwarzanie wyłączonych
przestrzeni tabel (2)
W celu wykonania pełnego odtwarzania jednej
lub kilku przestrzeni tabel należy:



Jeśli baza jest otwarta, ustawić tryb pracy
przestrzeni tabel lub pliku na OFFLINE
ALTER TABLESPACE OFFLINE;
Odzyskać z kopii zapasowej pliki, które należy
odtworzyć
Zaaplikować aktywne lub zarchiwizowane pliki
dziennika powtórzeń, lub jedne i drugie
RECOVER TABLESPACE <LIST OF TABLESPACES>
Otwarta baza – wyłączona przestrzeń tabel
– odtwarzanie pojedynczego pliku danych (1)
Baza danych jest otwarta;
nieuszkodzone przestrzenie tabel są włączone
i dostępne dla użytkowników, podczas gdy
uszkodzona przestrzeń tabel jest wyłączona
i uszkodzony plik wchodzący w jej skład musi być
odtworzony
Odtwarzanie indywidualnego pliku danych stosuje
się gdy:


Nieuszkodzone przestrzenie tabel muszą być dostępne
dla normalnej pracy
Plik uszkodzony w wyniku awarii nie zawiera danych,
wchodzących w skład systemowej przestrzeni tabel,
przestrzeni zawierającej aktywne segmenty wycofania lub
przestrzeni UNDO
Otwarta baza – wyłączona przestrzeń tabel
– odtwarzanie pojedynczego pliku danych (2)
W celu wykonania pełnego odtwarzania jednej lub
kilku przestrzeni tabel należy:



Jeśli baza jest otwarta, ustawić tryb pracy przestrzeni
tabel lub pliku na OFFLINE
ALTER TABLESPACE OFFLINE;
Odzyskać z kopii zapasowej plik, który należy odtworzyć
Zaaplikować aktywne lub zarchiwizowane pliki dziennika
powtórzeń, lub jedne i drugie
RECOVER DATAFILE <LIST OF FILES>
Zapytanie wyświetla numery plików wymagających
odtwarzania:
SELECT file#, online, error
FROM v$recover_file;
Odtwarzanie bloków danych po
awarii nośnika
Odtwarzanie bloków danych po awarii nośnika jest
techniką odzyskiwania i odtwarzania
indywidualnych bloków danych podczas, gdy
wszystkie pliki bazy danych są włączone
i dostępne użytkownikom.
Jeśli uszkodzenie jest ograniczone do kilku
bloków, należących do kilku plików bazy danych,
wtedy odtwarzanie bloków danych jest
korzystniejsze niż odtwarzanie całych plików
danych.
Ten typ odtwarzania jest możliwy przy
zastosowaniu narzędzia RMAN.
Pełne odtwarzanie z zastosowaniem
kopii pliku kontrolnego
Kopii pliku kontrolnego należy użyć, jeśli bieżący
stan bazy danych jest inny od żądanego.
Gdy w wyniku awarii nośnika zostaną uszkodzone
pliki kontrolne, baza danych będzie pracować
normalnie do czasu, gdy proces drugoplanowy
będzie potrzebował dostępu do pliku kontrolnego.
W tym momencie baza danych i instancja zostaną
automatycznie zamknięte.
Do odtworzenia bazy będą wymagane wszystkie
pliki danych, pliki dziennika i kontrolne utworzone
podczas wykonywania ostatniej kopii.
Utrata jednego ze zwielokrotnionych
plików kontrolnych
1. Zamknięcie bazy danych:
SHUTDOWN lub SHUTDOWN ABORT
2. Naprawienie awarii, która uszkodziła nośnik.
3. Skopiowanie dobrego pliku w miejsce
uszkodzonego,
4. Edycja pliku z parametrami - usunięcie nazwy
uszkodzonego pliku kontrolnego i wpisanie w to
miejsce nazwy dobrego pliku z kopii,
5. Ponowne wystartowanie instancji. Zamontowanie
i otwarcie bazy danych.
Startup pfile = …
Utrata wszystkich kopii pliku
kontrolnego
Nowy plik kontrolny należy tworzyć w sytuacji, gdy:


wszystkie pliki kontrolne zostały zniszczone i nie ma kopii
zabezpieczającej, ale wszystkie aktywne pliki dziennika
powtórzeń są nieuszkodzone,
gdy chce się zmienić nazwę bazy danych lub gdy trzeba
zmienić ustawienie bazy danych.
Zastosować polecenie CREATE CONTROLFILE
z opcją noresetlogs
Następnie wykonać polecenie
RECOVER DATABASE
Kroki jakie należy wykonać w celu
utworzenia nowego pliku kontrolnego
Zamknięcie bazy danych
SHUTDOWN ABORT
Wykonanie pełnego zrzutu bazy danych
Wystartowanie instancji:
STARTUP NOMOUNT
Utworzenie nowego pliku kontrolnego:
CREATE CONTROLFILE;
(najlepiej edytować skrypt, powstały w wyniku wykonania
ALTER DATABASE BACKUP CONTRLFILE TO TRACE)
montowanie, odtwarzanie bazy danych i otwarcie bazy
danych:
STARTUP MOUNT
RECOVER DATABASE
ALTER DATABASE OPEN
Odtwarzanie pliku dziennika
powtórzeń
Jeśli awaria nośnika uszkodzi włączony
(online) plik dziennika powtórzeń bazy
danych procedura odtwarzania będzie
zależna od konfiguracji plików dziennika
powtórzeń (zwielokrotnione lub
niezwielokrotnione), typu awarii
(przejściowa czy stała), i typu
uszkodzonego przez awarię pliku dziennika
(bieżący, aktywny, archiwizowany lub
nieaktywny).
Utrata pliku dziennika powtórzeń
W przypadku, gdy zostanie uszkodzony aktywny plik
dziennika, Oracle zatrzyma się z komunikatem systemu
operacyjnego o błędzie. Jeśli pliki dziennika miały lustrzane
kopie (mirrored), należy usunąć uszkodzone kopie
i odtworzyć dziennik z lustrzanej kopii.
Jeśli uszkodzony zostanie jeden plik z grupy (pliki
dziennika są zwielokrotnione) i choć jeden plik z grupy jest
nieuszkodzony, Oracle pozwoli bazie danych dalej
normalnie pracować, nie przerywając – korzystając
z pozostałych członków grupy.
W sytuacji gdy uszkodzona zostanie aktywna grupa plików
dziennika powtórzeń, należy zastosować niepełne
odtwarzanie do punktu w czasie lub do przerwania,
następnie otworzyć bazę danych z opcją RESETLOGS.
Niepełne odtwarzanie (1)
Niepełne odtwarzanie powoduje odtworzenie bazy
danych do stanu nie będącego stanem bieżącym
bazy.
W tym typie odtwarzanie nie ładujemy wszystkich
wpisów z plików dziennika powtórzeń.
Najczęściej stosuje się niepełne odtwarzanie, gdy:




Awarii zniszczy jeden lub wszystkie aktywne pliki
dziennika powtórzeń
Użytkownik zniszczy pewne dane (usunie ważną tabelę)
Nie można przeprowadzić niepełnego odtwarzania, bo
uszkodzone zostały zarchiwizowane pliki dziennika
powtórzeń
Uszkodzony został bieżący plik kontrolny i należy użyć
kopii pliku.
Niepełne odtwarzanie (2)
Startując bazę pierwszy raz po odtwarzaniu
niepełnym należy podać, czy trzeba liczyć od nowa
numer sekwencyjny dziennika, gdyż inicjalizację
numeru pliku dziennika należy wymusić, gdy do
odtwarzania użyta była kopia pliku kontrolnego lub
gdy odtwarzanie było niepełne (opcja
RESETLOGS).
Sprawdzenie, czy odtwarzanie było pełne czy też
nie jest możliwe za pomocą informacji zawartych
w pliku komunikatów (alter file).
Po otwarciu bazy z opcją RESETLOGS należy
zamknąć bazę i wykonać pełny zrzut bazy. Opcja ta
ustawia bieżący numer sekwencyjny na 0 i 1, wobec
tego nowe, archiwizowane pliki dziennika będą
Opcje niepełnego odtwarzania
do punktu w czasie (Time-based recovery) –
odtwarzanie zostanie przerwane po osiągnięciu
stanu bazy z podanego punktu czasowego,
do przerwania (Cancel-based recovery) –
odtwarzanie będzie przerwane przez użytkownika
do określonej zmiany (Change-based recovery) –
odtwarzanie będzie przerwane po odtworzeniu
zmiany o podanym numerze zatwierdzenia SCN
(system change number),
do numeru sekwencyjnego (Log sequence
recovery) – odtwarzanie do podanego numeru
sekwencyjnego dziennika powtórzeń
Odtwarzanie do punktu w czasie (1)
Stosowane w sytuacjach, gdy administrator chce odtworzyć bazę danych do pewnego
punktu czasowego z przeszłości (np. zna punkt czasowy, wystąpienia awarii).
Ten typ odtwarzania może być użyteczny w następujących sytuacjach:
Użytkownik przypadkowo usunął tabelę i czas błędu
jest w przybliżeniu znany– administrator bazy może
natychmiast zamknąć bazę
i odtworzyć jej stan do podanego punktu
w czasie, tuż przed awarią,
pojedynczy (nie wielokrotny) plik dziennika powtórzeń
został zniszczony i w przybliżeniu znany jest czas tego
zdarzenia,
istnieje konieczność wycofania bazy do stanu przed
niepożądanymi zmianami.
Odtwarzanie do punktu w czasie (2)
DATABASE
RECOVER TABLESPACE
nazwa
DATAFILE
nazwa
UNTIL TIME ‘….’
USING BACKUP CONTROLFILE;
przestrzeni tabel
pliku
Przykład:
RECOVER DATABASE UNTIL TIME ‘15-APR-10:15:45:00’;
Odtwarzanie do przerwania (1)
W niektórych sytuacjach niepełne
odtwarzanie musi być przerwane przez
administratora:


zatrzymuje odtwarzanie w żądanym momencie,
zatrzymuje odtwarzanie po załadowaniu
wybranego pliku dziennika powtórzeń.
Stosowane jest, jeśli jedna lub więcej grup
plików dziennika powtórzeń nie jest
dostępna.
Odtwarzanie do przerwania (2)
DATABASE
RECOVER TABLESPACE
nazwa
DATAFILE
nazwa
UNTIL CANCEL
USING BACKUP CONTROLFILE;
Przykład:
przestrzeni tabel
pliku
RECOVER DATABASE UNTIL CANCEL;
Odtwarzanie do zmiany i numeru
sekwencyjnego dziennika
Odtwarzanie do zmiany – punkt końcowy
odtwarzania wyznaczany jest przez podany
numer zmiany SCN (system change number)
SCN jest zapamiętywany w plikach dziennika
w momencie zatwierdzenia transakcji
Odtwarzanie od numeru sekwencyjnego punktem końcowym jest podany numer
sekwencyjny dziennika powtórzeń.
Etapy niepełnego odtwarzania
zamknięcie bazy danych
shutdown lub shutdown abort
2. wykonanie pełnego zrzutu bazy danych
3. Usunięcie awarii
4. Utworzenie nowego pliku kontrolnego (jeśli trzeba)
5. wgranie kopii plików danych,
6. wgranie niezbędnych zarchiwizowanych plików dziennika
(jeśli trzeba),
7. podłączenie się do bazy jako SYSDBA
8. wystartowanie instancji i zamontowanie bazy
Startup mount
9. Niepełne odtworzenie bazy danych
Recover database ….
10. Otwarcie bazy danych
Alter database open
1.
Odtwarzanie bazy z plików
eksportu
Odtworzenie uszkodzonej bazy polega na wykonaniu importu zasobów
bazy z plików eksportu do wcześniej przygotowanej struktury fizycznej.
Obejmuje ono odtworzenie przestrzeni tablic i użytkowników bazy
danych.
Do pustego szkieletu bazy można zaimportować wykonany wcześniej
pełny eksport bazy i uzupełnić go o najbardziej aktualne informacje
zawarte na przykład w eksportach typu INCREMENTAL lub
CUMULATIVE.
Kolejność wykonywania importu:




tworzone są nowe tabele,
importowane dane,
tworzone indeksy,
importowane są wyzwalacze i na nowych tabelach włączane są więzy
integralności.
Jeżeli eksport i import mają być użyte jako metoda zabezpieczająca,
należy wykonać następujące kroki podczas odtwarzania:



zamknąć bazę,
utworzyć nową bazę z nowymi plikami danych,
jeśli baza zawiera wiele przestrzeni tabel, utworzyć i włączyć (online) drugi
(oprócz SYSTEM) segment wycofania, zaimportować ostatni plik eksportu.