poniedziałek, 2 lipca 2012

Ustawienia sieciowe



Mechanizm Oracle Net umożliwia nam rozłożenie obciążenia związanego z aplikacjami bazodanowymi. Odpowiada za komunikację między klientem, a serwerem. Dzięki Oracle Net możliwa jest również konfiguracja serwer-serwer, gdzie każdy serwer obsługuje aplikację klienta, a także dysponuje możliwością połączenia się z innymi serwerami sieciowymi.


Deskryptory połączeń


Nazwy serwera i instancji są identyfikowane przy pomocy deskryptora połączeń. Określa on sposób komunikowania , nazwę serwera i nazwę usługi instancji używaną w czasie przetwarzania zapytania.

Ogólny format deskryptora wygląda w następujący sposób:

(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=HQ
(PORT=1521))
(CONNECT DATA=
SERVICE_NAME=XE)))

W tym deskryptorze zastosowaliśmy protokół TCP/IP, serwer o nazwie HQ i jego port 1521 (zarejestrowany numer używany przez Oracle dla mechanizmu Oracle Net), który powinien obsługiwać połączenie, a także zdefiniowaliśmy połączenie z instancją XE serwera HQ.


Nazwy usług sieciowych

Aby użytkownicy nie musieli wprowadzać deskryptora połączeń każdorazowo, możemy zdefiniować nazwy usług (lub aliasy), które odwołują się do deskryptorów. Nazwy usług znajdują się w pliku TNSNAMES.ORA. Ten plik powinien znajdować się na każdym serwerze bazodanowym, który jest w sieci (każdy klient i serwer powinien mieć kopię tego pliku).




Użytkownik, który chce się połączyć z instancją XE serwera localhost, może skorzystać z nazwy usługi XE.

SQLPLUS HR/HR@XE
Procesy nasłuchujące

Każdy serwer bazodanowy, który znajduje się w sieci musi posiadać plik LISTENER.ORA. Plik ten zawiera w sobie nazwy i adresy procesów nasłuchujących, a także wyszczególnia instancje, obsługiwane przez te procesy. Procesy nasłuchujące obsługują żądania połączeń pochodzące z klientów Oracle Net.


Przykładowa sekcja pliku LISTENER.ORA:



gdzie:

LISTENER – to nazwa procesu nasłuchującego
DESCRIPTION – pełni rolę kontenera adresów protokołów procesu nasłuchującego
ADDRESS – określa pojedynczy adres protokołu procesu nasłuchującego
PROTOCOL – nazwa protokołu służącego do łączenia z instancją
HOST – nazwa serwera
PORT – port służący do połączeń z instancją

Dodatkowo widzimy klauzulę

DEFAULT_SERVICE_LISTENER = (XE)

która to informuje nas, z którą instancją połączymy się domyślnie, łącząc się z serwerem na którym zdefiniowany jest powyższy plik LISTENER.ORA.








Eksport i import




Oracle mamy dwa programy do tego celu EXP – do eksportowania danych, oraz IMP – do ich importowania. Przy
ich użyciu możemy eksportować i importować :
- całą bazę
- wybrany schemat
- wybrane tabele


Eksport całej bazy danych


Kod:

EXP USERID=system/tajne_haslo FILE='c:\kopia_bazy\calosc.dat'
LOG='c:\kopia_bazy\calosc.log' FULL=Y

To, co następuje po userid to nazwa użytkownika łamana przez hasło. W tym wypadku musimy to zrobić jako system, ponieważ jako zwykły użytkownik nie mamy dostępu do całej bazy (a całą chcemy eksportować). Po file podajemy nazwę pliku do którego zostanie wrzucona zawartość bazy. Plik stworzy się sam, ale struktura katalogów musi zostać przez nas uprzednio stworzona. Po log podajemy plik do którego mają być zrzucane logi. Podawanie tego nie jest obowiązkowe. Opcja Full=y nakazuje eksport całej bazy. Jeśli jej nie podamy, musimy wyeksportować schemat, albo tabelę, ale i tak musimy określić które.

Eksport całego schematu

Kod:

EXP USERID=hr/hr FILE='c:\kopia_bazy\schemat.dat' LOG='c:\kopia_bazy\schemat.log' OWNER=HR

Parametry userid, file, log oznaczą to samo co poprzednio. Eksportujemy jako user hr swój własny schemat. Oczywiście możemy eksportować również schematy innych userów, ale musimy do tego być zalogowany jako user system (albo user który jest ownerem schematu). Poza tym zamiast "full=y" pojawiło się "owner=hr", co oznacza że wyeksportowany ma zostać cały schemat usera hr.

Możemy zrobić również eksport schematu na innym komputerze. Dodajemy wtedy „@adres_ip” w userid:


EXP USERID@adres_ip=hr/hr FILE='c:\kopia_bazy\schemat.dat' LOG='c:\kopia_bazy\schemat.log'
OWNER=HR




Eksport wybranych tabel

Możemy chcieć też zrobić sobie kopię zapasową tylko kilku tabel. Do tego celu w miejsce wcześniejszego full=y
czy owner=hr wpisujemy np. tables=employees, departments :

EXP USERID=hr/hr FILE='c:\kopia_bazy\schemat.dat' LOG='c:\kopia_bazy\schemat.log'
TABLES=employees, departments

Import danych

Kiedy wykonamy eksport bazy mamy możliwość przywrócenia jej z powrotem, lub przeniesienia/skopiowania jej
na inny serwer. Do tego użyjemy programu IMP.

Import całej bazy

Kod:

IMP USERID=system/tajne_haslo FILE='c:\kopia_bazy\calosc.dat' LOG='c:\kopia_bazy\calosc.log' FULL=Y
DESTROY=Y

Parametr userid - oznacza to samo co w exp, kiedy importujemy całość bazy musimy być zalogowani jako user system. File to plik z wcześniejszego eksportu danych, log tak jak wcześniej. Full=y ponieważ importujemy całość, destroy=y oznacza, że jeśli istnieje już obiekt w bazie o takiej nazwie to zostanie skasowany i nadpisany. Jeśli tego nie dodamy, to w takiej sytuacji będziemy dostawali zapytanie czy chcemy wprowadzić zmiany (możemy zamiast tego dodać ignore=y, wtedy nie będzie nadpisywał i kasował zmian).

Import schematu


Importować możemy zawartość schematu nie tylko z powrotem do schematu usera z którego zostały dane
wyciągnięte, ale też możemy je wstawić innemu userowi. Dlatego przy imporcie nie ma już 'owner=hr', ale za to
jest 'touser=hr' określający do schematu jakiego usera mają dane zostać wrzucone, oraz 'fromuser=hr' czyli
schemat jakiego usera może być wciągnięty (bo jeżeli importujemy jakiś schemat z eksportu całej bazy, mamy tam
bardzo wiele schematów i musimy któryś wybrać).


IMP USERID=hr/hr FILE='c:\kopia_bazy\schemat.dat' fromuser=hr touser=hr destroy=y


Możemy tutaj też dodać LOG='c:\kopia_bazy\schemat.log' jak przy eksporcie, ale nie jest to konieczne.


Import poszczególnych tabel


Podobnie jak przy imporcie schematu wprowadzamy fromuser i touser - w tym względzie działa to tak samo.
Wybieramy też tabele które chcemy zaimportować.


Kod:


IMP USERID=hr/hr FILE='c:\kopia_bazy\tabele.dat' FROMUSER=hr TOUSER=hr TABLES=EMPLOYEES


!! Musimy uważać z importem, bo Oracle nadpisuje tabele importowane bez żadnej informacji.



RMAN - Kopie zapasowe w Oracle. Backup i odtwarzanie



Podstawowe informacje i wstępna konfiguracja


Backupy możemy wykonywać na dwa sposoby:
- wyłączając bazę i kopiując fizyczne pliki (tzw. zimny backup)
- wykorzystując RMANa i zrobić backup bez wyłączania bazy (hot backup)


Aby wykonać hot backup należy ustawić bazę w tryb ARCHIVELOG. Po tym zabiegu pliki
dzienników powtórzeń przed nadpisaniem zostaną zarchiwizowane. Dzięki temu mamy pewność że
nie zostaną wyczyszczone w trakcie backupu. Wykonujemy to w następujący sposób:

- Logujemy się SQL*Plusem jako SYS do bazy.
- Robimy SHUTDOWN IMMEDIATE; (tylko ten jeden raz jest to konieczne).
- Uruchamiamy bazę w trybie MOUNT (poleceniem STARTUP MOUNT).
- Wywołujemy polecenie ALTER DATABASE ARCHIVELOG;
- otwieramy bazę dla użytkowników poleceniem ALTER DATABASE OPEN;

Ten krok można pominąć ale ta konfiguracja pozwoli nam na wybór innego niż domyślne miejsce
składowania plików backupu. Oracle zawiera w sobie Flash Recovery Area. To przestrzeń
zawierająca backupy, służąca do ich przywracania. Jest ona zarządzana przez silnik bazy danych, a
nie system operacyjny. W niej właśnie będą składowane nasze backupy. Sprawdzamy aktualne
położenie FRA:

SELECT * FROM v$recovery_file_dest;






Jeśli chcemy zmienić dostępną dla FRA przestrzeń dyskową stosujemy komendę:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 100G;

Parametr ten ustawia ile miejsca na dysku mogą maksymalnie zajmować backupy oraz archivelogi.

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='c:\FRA';

Parametr ten ustawia gdzie na dysku mają znajdować się backupy.

Po ustaleniu w/w parametrów, warto sprawdzić, czy wszystko zostało przez nas poprawnie
ustawione. Wybieramy więc komendy:


SELECT * FROM v$parameter WHERE NAME='db_recovery_file_dest';



SELECT * FROM v$parameter WHERE NAME='db_recovery_file_dest_size';








Włączamy konsolę command line a następnie wpisujemy RMAN.


Podłączenie do bazy

Przede wszystkim po włączeniu RMANa, musimy podłączyć się do bazy danych. Robi się to
wpisując komendę:

CONNECT TARGET
lub
CONNECT TARGET /
lub
CONNECT TARGET nazwabazy



Pełny backup


W celu wykonania pełnego backupu bazy danych wywołujemy komendę:


BACKUP DATABASE;


Jako że to jest pełny backup, trwa on dosyć długo. Należy cierpliwie poczekać na pojawienie się
komunikatu RMANa. Nasz backup pojawi się w zdefiniowanym przez nas Flash Recovery Area.

Jeśli chcemy by nasz backup znalazł się w innym niż domyślne miejscu wpisujemy komendę:


BACKUP DATABASE FORMAT 'c:\rman\calabaza%u.bck';


Tag %u to unikalny numer generowany m.in. na podstawie daty i godziny utworzenia, dzięki
czemu każdy plik kopii zapasowej będzie miał unikalny numer.

Formatów tych jest kilka i można je wplatać w nazwę pliku. Przedstawiam te podstawowe:


%s – numer backupu
%d – nazwa bazy danych
%D – dzień
%M – miesiąc
%Y – rok
%u – wartość unikalna wyliczona na podstawie wszystkich w.w opcji


Taki backup obejmuje dane oraz plik kontrolny. Jeśli chcemy wykonać backup razem z plikami
zarchiwizowanymi dziennika powtórzeń, to wywołujemy komendę:


BACKUP DATABASE PLUS ARCHIVELOG;

Backup skompresowany


Pliki backupów zajmują sporo miejsca. Warto więc by były kompresowane. Jest możliwość
kompresowania przy użyciu RMANa. RMAN stosuje algorytm podobny do tego używanego przez
program archiwizujący ZIP.


Zamiast BACKUP DATABASE; wpisujemy:


BACKUP AS COMPRESSED BACKUPSET DATABASE FORMAT
'c:\FRA\full_compressed%u';


lub przykładowo z plikami (zarchiwizowanymi) dziennika powtórzeń:


BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG FORMAT
'c:\FRA\full_compressed%u';


Taką kompresję można stosować też przy backupach tablespace'ów oraz backupach przyrostowych
i kumulatywnych. Co prawda kopia zapasowa jeśli jest kompresowana wykonywana jest dużo
dłużej, ale zajmuje w efekcie mniej miejsca.

Backup przyrostowy i kumulatywny


Nie zawsze musimy chcieć wykonywać pełną kopię zapasową. Z resztą po co nam za każdym
razem całość jeśli można pełny backup zrobić raz, a później wykorzystywać zajmujące znacznie
mniej miejsca kopie przyrostowe.


Definicje:

Kopia pełna - czyli kopia wszystkich plików danych oraz pliku kontrolnego
Kopia przyrostowa - czyli kopia tylko tych bloków danych które uległy zmianie od ostatniego
pełnego lub przyrostowego backupu.
Kopia kumulatywna - kopia wszystkich bloków danych które uległy zmianie od ostatniego
pełnego (!!! już nie ostatniego przyrostowego) backupu.


Backup przyrostowy


Od wersji 10g Oracle obsługuje dwa poziomy kopii przyrostowej 0 i 1. Kopia przyrostowa poziomu
0 fizycznie nie różni się niczym od pełnego backupu, z tą różnicą że na jej podstawie możemy
wykonywać normalne kopie przyrostowe (poziom 1). Tak więc przynajmniej raz musimy wykonać
komendę:


BACKUP INCREMENTAL LEVEL 0 DATABASE FORMAT 'c:\FRA\przyrostowa_0_%u';


aby następnie móc wykonywać :


BACKUP INCREMENTAL LEVEL 1 DATABASE FORMAT 'c:\FRA\przyrostowa_1_%u';


Komenda z level 1, jest to już normalna kopia przyrostowa.


Backup kumulatywny


Aby wykonać backup kumulatywny wywołujemy komendę:


BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;


Warto dość często wykonywać kopie przyrostowe, a raz na jakiś czas (np. tydzień) kopię
kumulatywną. Dzięki temu będziemy mogli później pozbyć się kopii przyrostowych, a co za tym
idzie, mieć mniejszą ilość plików do przechowywania.


Ten tag możemy łączyć z innymi poznanymi wcześniej, np.:


BACKUP INCREMENTAL LEVEL 1 FORMAT 'c:\FRA\inc_comp%u' AS COMPRESSED
BACKUPSET DATABASE PLUS ARCHIVELOG;



Szybki backup przyrostowy


Normalnie backup przyrostowy realizowany jest tak, że ostatni backup z danymi porównywany jest
blok po bloku. Zamiast tego, można zrobić tak by Oracle tworzyło sobie listę zmienionych bloków.
W takim wypadku backup przebiegał będzie znacznie szybciej. Niestety ta opcja jest dostępna tylko
w wersjach Standard i Enterprise.

Najpierw sprawdźmy czy już ta opcja nie jest włączona:

SELECT * FROM v$parameter WHERE NAME='db_create_file_dest';

Jeśli pole value będziemy mieli puste, to znaczy że nie było to wcześniej ustawiane.
Tworzymy katalog w którym taka lista będzie przechowywana, a następnie wpisujemy:

ALTER SYSTEM SET db_create_file_dest='c:\FRA\fib';

oraz włączamy tą opcję:

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;



Backup tablespace'ów


RMANem możemy wykonywać również backupy tablespace'ów, plików danych, pliku parametrów, pliku kontrolnego.

Najpierw sprawdźmy jakie mamy tablespace'y:

SELECT * FROM DBA_TABLESPACES;

Komenda do backupu wybranego tablespace'a:

BACKUP TABLESPACE USERS FORMAT 'c:\FRA\users%u';

Klauzula format jest oczywiście nieobowiązkowa. Możemy też chcieć zapisać kilka tablespace'ów,
wtedy rozdzielamy ich nazwy przecinkami:

BACKUP TABLESPACE USERS, SYSTEM FORMAT 'c:\FRA\users_system%u';

albo zechcieć je dodatkowo skompresować:

BACKUP AS COMPRESSED BACKUPSTE TABLESPACE USERS FORMAT
'c:\FRA\users_compressed%u';

lub zrobić nie dość że skompresowaną to jeszcze przyrostową (oszczędzamy miejsce - dyski kiedyś
się kończą).:

BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1 FORMAT
'c:\FRA\users_comp_przyr%u' TABLESPACE USERS;


Backup pliku parametrów

Komenda (format jest opcjonalny):

BACKUP SPFILE FORMAT 'c:\FRA\spfile%u';


Backup pliku kontrolnego


Warto abyśmy wykonywali osobną kopię pliku kontrolnego. Dlaczego? Ponieważ informacje o
backupach przechowywane są właśnie w nim. Co prawda w pełnych backupach jest też kopia pliku
kontrolnego, ale nie będziemy w stanie przywrócić backupu, jeśli plik kontrolny ulegnie
uszkodzeniu. W takim przypadku dużo łatwiej odzyskać najpierw plik kontrolny a później resztę.
Aby wykonać taki backup wpisujemy:


BACKUP CURRENT CONTROLFILE FORMAT 'c:\FRA\controlfile%u';


Taką kopię pliku kontrolnego (zwłaszcza że nie zajmuje wiele miejsca) warto mieć jak najświeższą.
Dbanie o to by tak było możemy zlecić silnikowi bazy:


CONFIGURE CONTROLFILE AUTOBACKUP ON;


Od tej pory jeśli nastąpi jakakolwiek zmiana wpływająca na plik kontrolny, ten zostanie
automatycznie zbackupowany po zmianach. Możemy teraz chcieć by RMAN backupował nam plik
kontrolny w inne miejsce niż domyślne. Wywołujemy komendę:


CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'd:\FRA\plikkontrolny%u';

Kopia zapasowa plików zarchiwizowanych dziennika powtórzeń

SELECT * FROM v$datafile;


BACKUP AS COPY DATAFILE 'c:\app\administrator\oradata\orcl\users01.dbf' FORMAT
'c:\FRA\users.dbf';


Komenda ta kopiuje wszystkie bloki, zajęte oraz puste. Jeśli więc będziemy mięli określony
tablespace o wyznaczonej z góry sporej wielkości, backup zajmie niepotrzebnie bardzo dużo
miejsca.

Odtwarzanie przy użyciu RMAN

Aby rozpocząć przywracanie interesujących nas rzeczy z backupu, włączamy konsolę command
line a następnie wpisujemy RMAN.

Przede wszystkim po włączeniu RMANa, musimy podłączyć się do bazy danych (tak jak w
przypadku tworzenia plików backupu). Wpisujemy zatem komendę:

CONNECT TARGET
lub
CONNECT TARGET /
lub
CONNECT TARGET nazwabazy


Możemy przywrócić teraz to, co wcześniej zbackupowaliśmy (bazę, tablespace'y, plik kontrolny,
czy pliki zarchiwizowanych dzienników powtórzeń).


Przywracanie bazy z pełnego backupu
Zaczniemy od przywrócenia pełnej bazy z naszego backupu. Aby to zrobić musimy najpierw
wyłączyć bazę, a następnie włączyć ją w tryb mount (możemy to zrobić wprowadzając listę
komend):



RUN{
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN;
}




RMAN sam sprawdzi który backup jest tym ostatnim, bez względu na to, czy robiliśmy pełny
backup, inkrementalny, czy też kumulatywny. Również sam załaduje odpowiedni controlfile i
archivelogi.



Przywracanie bazy do określonego punktu w czasie

Możemy przywrócić bazę do określonego punktu w czasie, w tym celu wyłączamy, a następnie
uruchamiamy bazę do trybu mount:

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

Podajemy do którego momentu chcemy przywrócić bazę:

run{
set until time ”to_timestamp('12:00:00 01-09-2011','hh24-mi-ss dd-mm-yyyy')”;
restore database;
recover database;
}



Następnie uruchamiamy bazę, resetując archivelogi:


ALTER DATABASE OPEN RESETLOGS;


Walidacja bazy i backupów

W celu sprawdzenia poprawności plików bazy danych wywołujemy komendę:

BACKUP VALIDATE DATABASE;

możemy również wykonać walidacje dla bazy, wraz z archivelogami:

BACKUP VALIDATE DATABASE PLUS ARCHIVELOG;

Co ważne, podając tę komendę nie wykonujemy backupu!

Aby sprawdzić poprawność ostatnio wykonanego backupu wprowadzamy:

RESTORE DATABASE VALIDATE;

aby sprawdzić poprawność pliku backupu wraz z archivelogami:

RESTORE ARCHIVELOG ALL VALIDATE;




Zarządzanie backupami



Chcąc sprawdzić nasze backupy możemy je wylistować wpisując komendę:


LIST BACKUP;





Warto czasem sprawdzić, czy pliki do których odnosi się backup wciąż są obecne na dysku. Aby to
zrobić wywołujemy:


CROSSCHECK BACKUP;






Jeśli powyższe zapytanie wykaże nam błąd (różne od found to be 'AVALIABLE'), możemy wtedy usunąć niepotrzebne pliki backupu używając komendy:


DELETE EXPIRED BACKUP;


Możemy również wykasować nieaktualne, niepotrzebne już backupy np. przestarzałe:


DELETE OBSOLETE;

Aby ustawić politykę backupów, tzn. kiedy pliki backupów będą uważane przez RMANa za przestarzałe musimy zmodyfikować parametr RETENTION POLICY. Mamy możliwość ustawienia ilości backupów, które mają być uważane za aktualne, bądź czas, podawany w dniach.

Ustawienie dla ilości dni przez jakie backupy będą uważane za „ważne” ustawiamy poleceniem:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

Powyższym poleceniem ustawimy, iż RMAN będzie uważał za przestarzałe pliki backupów stworzone później niż 3 dni wstecz.

Ustawienie dla ilości przetrzymywanych backupów ustawiamy wywołując polecenie:

CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

Tym poleceniem ustawiamy, iż RMAN będzie uważał za aktualne 3 ostatnie pliki backupów.

Po wylistowaniu backupów (LIST BACKUP) zobaczymy jaki numer odpowiada konkretnemu
plikowi backupu. Znając ten numer, możemy usunąć konkretny backup posługując się właśnie tym
numerem:

DELETE BACKUPSET 69;


Przywracanie tablespaceów



Aby odtworzyć tablespace musimy odłączyć go od bazy przy pomocy komendy OFFLINE. W tym
wypadku również możemy posłużyć listą komend:

RUN{
SQL 'ALTER TABLESPACE USERS OFFLINE';
RESTORE TABLESPACE USER;
RECOVER TABLESPACE USERS;
SQL 'ALTER TABLESPACE USERS ONLINE';
}







Przywracamy tablespace systemowy


Tutaj również możemy posłużyć się listą komend. Jako, że jest to tablespace systemowy, jesteśmy
zmuszeni zamknąć bazę danych i wprowadzić ją w tryb MOUNT:


RUN{
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
RESTORE TABLESPACE SYSTEM, SYSAUX;
RECOVER TABLESPACE SYSTEM, SYSAUX;
ALTER DATABASE OPEN;
}



Przywracanie pliku kontrolnego

Plik kontrolny przywracamy dodając na końcu komend dodatek RESETLOGS:

RUN{
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;
RESTORE CONTROLFILE FROM AUTOBACKUP ;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
}



















Włączanie i wyłączanie instancji



Tryby uruchomieniowe instancji



Istnieje kilka sposobów włączania instancji:



STARTUP – lub STARTUP OPEN włącza bazę danych do pełnowartościowego trybu.



STARTUP NOMOUNT – umożliwia włączenie bazy do poziomu załadowania m.in. SPFILE, czy SGA. W tym trybie przywracamy plik kontrolny (CONTROLFILE) oraz duplifikujemy bazę danych (docelowa musi być w trybie nomount).


STARTUP MOUNT – umożliwia włączenie bazy do poziomu załadowania m.in. plików danych, plików dzienników powtórzeń, czy pliku kontrolnego. W tym trybie mamy możliwość przywrócenia bazy danych z backupu.


ALTER DATBASE MOUNT – komenda do wprowadzenia bazy danych do trybu MOUNT z trybu NOMOUNT (pamiętajmy, że nie możemy otworzyć bazy bezpośrednio z trybu NOMOUNT).



ALTER DATABASE OPEN – służy do otworzenia bazy z trybu MOUNT (jeśli mamy tryb NOMOUNT komenda ta nie zadziała, musimy najpierw przejść do trybu MOUNT).
Wyłączanie bazy ORACLE


Jako administrator bazy danych mamy możliwość wyłączenia instancji na kilka sposobów:


SHUTDOWN IMMEDIATE - przerywa wszystkie aktywne sesje, po czym wycofuje wszystkie niezapisane transakcje.


SHUTDOWN NORMAL - powoduje zamknięcie bazy danych po zakończeniu wszystkich sesji użytkowników.


SHUTDOWN TRANSACTIONAL – powoduje zamknięcie bazy danych, po zakończeniu wszystkich aktywnych transakcji, nie pozwalając przy tym na zalogowanie do bazy nowych użytkowników.


SHUTDOWN ABORT powoduje natychmiastowe zamknięcie bazy danych (stosujemy ją tylko wtedy, gdy nie możemy zamknąć bazy używając SHUTDOWN IMMEDIATE, a musimy ją zamknąć natychmiast, na przykład w przypadku jakiejś awarii).








Rozłączanie sesji


Rozłączanie sesji użytkowników

Jako administrator mamy możliwość rozłączenia użytkownika na kilka sposobów. Jedne są bardziej „grzeczne”,
Inne trochę mniej:

Aby rozłączyć użytkownika potrzebujemy 2 wartości, które uzyskamy wywołując polecenie:

SELECT SID,SERIAL# FROM v$session WHERE USERNAME='nazwa_uzytkownika';




Znając te wartości jesteśmy w stanie rozłączyć użytkownika. Oto różne sposoby:


ALTER SYSTEM KILL SESSION 'sid,serial#';

w naszym przypadku w miejsce sid i serial# wprowadzamy wartości 37 oraz 14. Spowoduje natychmiastowe rozłączenie sesji użytkownika wyświetlając mu informację, że jego sesja została przerwana przez administratora („your session has been killed”). Wszystkie wprowadzone przez niego, niezapisane działania, których nie zatwierdził, zostaną automatycznie cofnięte (ROLLBACK).


ALTER SYSTEM DISCONNECT SESSION '37,14' IMMEDIATE; - spowoduje rozłączenie sesji użytkownika. Przy próbie wykonania działania wyświetlony zostanie monit o utraceniu połączenia z bazą. Wszystkie niewprowadzone zmiany zostają automatycznie cofnięte (ROLLBACK).



ALTER SYSTEM DISCONNECT '37,14' POST_TRANSACTION; - spowoduje rozłączenie użytkownika po zatwierdzeniu przez niego zmian (COMMIT) lub cofnięciu ich (ROLLBACK). Jeśli użytkownik nie ma żadnych niezatwierdzonych działań w transakcji (np. wykonywał tylko SELECTy) jego sesja zostanie natychmiast zerwana.






Audyt – monitorowanie użytkowników i działań na obiektach





Włączanie opcji AUDIT


Opcja monitoringu tego typu jest domyślnie wyłączona w Oracle. Musimy więc ją ustawić, a następnie zrestartować bazę. Logujemy się jako SYS, a następnie wydajemy polecenie :


ALTER SYSTEM SET AUDIT_TRAIL=TRUE SCOPE=SPFILE;





*Aby widzieć dokładnie wprowadzane przez użytkownika komendy SQL (również nieudane próby tj. np. brak uprawnień do obiektu), musimy zmodyfikować powyższe poleceni tak, aby zamiast TRUE było DB,EXTENDED:



ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE;



Następnie jako SYS należy wykonać SHUTDOWN IMMEDIATE (trzeba pamiętać, że ta opcja zerwie wszystkie sesje i wycofa transakcje). Logujemy się jako SYS do wyłączonej (!) bazy. Aby móc to zrobić korzystamy z SQL*Plusa i logujemy się bez podawania „@adres_ip”. Co za tym idzie, należy to zrobić z komputera na którym zainstalowana jest baza Oracle. Jeśli wyłączyliśmy bazę z SQL*Plusa, to nie ma potrzeby ponownego logowania do bazy. Włączamy ją poleceniem STARTUP.

Teraz opcja audytu jest już włączoną.
Możemy się upewnić wywołując komendę:SELECT * FROM V$PARAMETER WHERE NAME LIKE ‘%audit_trail’;


Śledzenie użytkownika

Po włączeniu opcji audytu możemy włączyć opcję śledzenia konkretnego użytkownika. Opcja
AUDIT ALL dla użytkownika powoduje obserwację jego działań takich jak tworzenie linków bazodanowych, synonimów, tabel – słowem operacji DDL.
AUDIT ALL BY UZYTKOWNIK;





Możemy wybrać tylko niektóre działania użytkownika, które chcemy monitorować. Do tego celu używamy komendy:


AUDIT SELECT table, insert table, delete table, update table BY uzytkownik BY ACCESS;



Opcja BY ACCESS powoduje zachowanie informacji o działaniu użytkownika nawet jeśli już w ramach danej sesji wykonał instrukcję tego samego typu (np. więcej niż 1 raz wykonał SELECT na jakiejś tabeli). Przeciwieństwem dla tej opcji jest BY SESSION, ale wtedy dany tym działania jest rejestrowany tylko raz.

Aby rozpocząć śledzenie danego użytkownika wymagane jest aby wylogował się (możemy również wymusić jego rozłączenie) i ponownie zalogował do bazy.



Aby przejrzeć wyniki śledzenia należy zalogować się do użytkownika SYS. Następnie wybrać tabelę DBA_AUDIT_TRAIL. Zadając do niej odpowiednie zapytanie, jesteśmy w stanie prześledzić działalność konkretnego użytkownika.



SELECT username,
extended_timestamp,
owner,
obj_name,
action_name
FROM dba_audit_trail
WHERE USERNAME LIKE 'PRZYKLADOWY'
and owner not like 'SYS'
ORDER BY timestamp;




Warunek AND OWNER NOT LIKE 'SYS' wprowadzamy aby nie wyświetlać zmian w tabelach systemowych, które wykonują się w związku z działalnością użytkownika SYS. Warunek ORDER BY timestamp wyświetla wydarzenia według czasu ich wystąpienia.


Możemy też wyświetlić informacje na temat działań związanych z obiektami których właścicielem (twórcą) jest wybrany użytkownik:


SELECT username,
extended_timestamp,
owner,
obj_name,
action_name
FROM dba_audit_trail
WHERE owner LIKE 'PRZYKLADOWY'
ORDER BY timestamp;




Wyświetlone zostało tylko kilka kolumn, bo tylko te nas w danym momencie interesują. W kolumnie USERNAME jest informacja kto wykonał dane działanie, w kolumnie OWNER na czyim obiekcie (tutaj akurat nasz user zmieniał dane we własnym obiekcie). OBJ_NAME zawiera informacje o nazwie obiektu na którym zostały wykonane działania a ACTION_NAME trzyma info o tym jaki typ działań został przez usera wykonany.


Śledzenie działań na obiekcie


W tym punkcie będziemy śledzić kto zmienia zawartość konkretnego obiektu, niezależnie od tego który to użytkownik.


Z poziomu SYSa należy wykonać:


AUDIT DELETE, INSERT, UPDATE ON nazwa_uzytkownika.nazwa_tabeli BY ACCESS;



Polecenie to włączy obserwację tabeli produkty w schemacie użytkownika uzytkownik. Obserwowane będzie jedynie kasowanie, uzupełnianie oraz zmiana danych w tej tabeli. Możesz oczywiście wymienić takie aktywności, które nas interesują (np. select).
Należy zmodyfikować nasze wcześniejsze zapytanie. W tym przypadku zmieniamy warunek WHERE. Wyświetlamy informacje o działaniach tylko te, które mają w nazwie obiektu ‘PRODUKTY’ a więc nazwę tabeli, która nas interesuje. Dla wszelkiej pewności możemy dodać jeszcze warunek dla kolumny OWNER, by mieć pewność, że chodzi o tabelę konkretnego użytkownika. Tabela o takiej samej nazwie może występować przecież w kilku schematach.

SELECT username,
extended_timestamp,
owner,
obj_name,
action_name
FROM dba_audit_trail
WHERE obj_name LIKE 'PRODUKTY'
ORDER BY timestamp;