Oracle vs SQL Server - prvi dio

Details
Category: Baze podataka
Hits: 441

Instances, Databases & Tablespaces

Moda najvanija razlika izmedju Oracle-a i SQL Servera na nivou arhitekture je u shvatanju pojmova Instance i
Database.

Instanca u SQL Serveru je pojam koji oznaava samostalni aplikativni servis koji u sebe ukljuuje fajlove operativnog
sistema, memorijske strukture, pozadinske procese i informacije iz registry-a. Instanca je u SQL Serveru pretstavljena
servisom u Windows-u i moe se nalaziti u 2 statusa: Running ili Stopped. Kada je u statusu running, instanca
zauzima dio serverske memorije i povezuje nekoliko pozadinskih procesa.

U sreditu zbivanja instance SQL Servera su njene databases baze podataka. SQL Server database je repozitorij
podataka i programskog koda koji upravlja tim podacima. Ukoliko instanca ne radi, bazama podataka unutar instance
se ne moe pristupiti.

Postoje dva tipa SQL Server baza podataka: system databases i user databases. Kada se SQL Server instanca prvi
put instalira, kreira se 5 sistemskih baza podataka: master, model, msdb, tempdb i resource. Ukoliko postoji vie od
jedne SQL Server instance koja je na raunaru u statusu running, svaka instanca e imati svoj predefinisani skup
sistemskih baza podataka. Instanca se ne moe startovati ukoliko fali ili je oteena bilo koja od sistemskih baza
podataka izuzev baze msdb. Korisnike baze podataka, sa druge strane su kreirane od strane DBA i developer-a
kada je instanca ve instalirana i sistemske baze podataka startovane. Ovo korisnike baze podataka su baze u
kojima se uvaju poslovni podaci u skladu sa idejama korisnika o njihovoj upotrebi i organizaciji podataka.

Dakle, ukratko, SQL Server instance e uvjek ukljuivati bazu podataka (ak i ako je to samo jedna sistemska baza
podataka) a baza podataka e biti uvjek povezana sa jednom (i samo jednom) instancom.

Na fizikom nivou, SQL Server baza podataka je pretstavljena skupom fajlova unutar operativnog sistema koji postoje
na diskovima serverskog raunara. Postoji 2 tipa fajlova za SQL Server bazu podataka: data file i transaction log
file. U najosnovnijoj konfiguraciji baza podataka mora imati po jedan data file i transaction log file. Data file je glavni
repozitorijum sa informacijama u SQL Server bazi podataka. Transaction log file, sa druge strane snima izmjene koje
su se desile nad podacima. Ovaj fajl je potreban SQL Serveru u sluaju izvravanja sistemskog recovery-a. I data i log
file e uvjek pripadati nekoj konkretnoj bazi podataka - ne postoji mogunost da dvije baze podataka dijele isti data ili
log file. Ukoliko je baza podataka velika, moe da sadri nekoliko data fajlova. Vie data fajlova u jednoj bazi podataka
se mogu logiki grupisati u strukture poznate pod imenom filegroups.

Kod Oracle-a je stvar donekle obrnuta. Kada se Oracle pokrene,on radi kao i SQL Server u smislu da je dio memorije
server raunara alociran za njegove operacije. Ovaj memorijski prostor je poznat kao System Global Area (SGA) i
podjeljen je na nekoliko tano definisanih struktura. Pored memorijskog prostora, prilikom pokretanja Oracle-a, takodje
se pokree i odredjeni broj pozadinskih (background) procesa. Njihov osnovni zadatak je komunikacija sa SGA. Ovo
dvoje zajedno memorijski prostor i pozadinski procesi formiraju Oracle instance. Uoite da u ovom momentu Oracle
baza podataka jo nije u igri. U stvari, Oracle instanca moe da radi savreno ak i bez OnLine baze podataka ili baze
podataka kojoj bi se moglo na neki nain pristupiti. Prilikom instalacije Oracle, postoji opcija da instalirate samo softver
a da bazu podataka kreirate kasnije.

Baza podataka u Oracle je kolekcija fajlova operativnog sistema. Za razliku od SQL Servera, Oracle baza podataka ne
pretstavlja logiko grupisanje objekata. Umjesto toga, postoji samo jedna baza, zajedniki pojam za skup fajlova na
disku koji primarno sadre podatke.

Fajlovi koji formiraju Oracle bazu podataka se mogu klasifikovati u 3 tipa: data file, redo log file i control file. Data
files su fajlovi gdje su smjeteni podaci. Moe postojati bilo koliki broj data fajlova u Oracle bazi podataka. Redo log
files su neta poput SQL Server transaction logova u smislu da se u njih upisuju sve promjene na bazi podataka i
koriste se za system recovery. Control files su posebna vrsta fajlova male veliine koji sadre bitne informacije o
konfiguraciji Orace baze podataka. Bez Control file, instanca nee moi da otvori bazu podataka.
 Pored data, redo log i control files, baza podataka e takodje sadrati parameter file (konfiguracioni parametri za
SGA), password file (accounti i paswordi za administratore baze) i opcionalno, archive log files (arhivirani podaci iz
redo log fajlova).

Kada startuje Oracle sistem, prvo se kreira instanca u memoriji. Instanca se povezuje sa bazom podataka koja postoji
na diskovima a na kraju se baza podataka otvara za koritenje od strane krajnjih korisnika. Kada je sistem shut
down, instanca je izbrisana iz memorije: sve memorijske strukture i procesi su ispranjeni ali baza podataka i dalje
postoji na diskovima, mada u statusu closed. Kao to je reeno ranije, mogue je imati Oracle instancu koja je
podignuta a da baza podataka nije open ovo je kljuna razlika u odnosu na SQL Server gdje se instanca ne moe
startovati ukoliko nisu prvo startovane njene sistemske baze podataka. Sa druge strane, ba kao i kod SQL Servera,
nemogue je da se poveete na Oracle bazu podataka ukoliko instanca baze nije podignuta - startovana.

Generalno govorei, relacija izmedju Oracle instance i njegovih baza podataka je 1:1. Instanca ima uz sebe vezanu
samo jednu bazu podataka. Baza podataka, sa druge strane, moe imati jednu ili vie instanci sa kojima je vezana.
Standalone Oracle instalacija je primjer jedne instance koja je povezana sa jednom bazom podataka. Oracle
instalacija konfigurisana kao RAC (Real Application Cluster) e imati vie instanci koje e se izvravati na vie
raunara a sve one e biti povezane sa jednom bazom na djeljenom (shared) disk sistemu.

Pitanje je, gdje se vri logiko grupisanje baznih objekata unutar Oracle-a? U SQL Server-u, ovo logiko grupisanje je
realizovano unutar same baze podataka. Kod Oracle-a je to realizovano kroz mehanizam koji se zove tablespaces.
Oracle tablespace-ovi su logike strukture koje u sebi grupiu tabele, view-ove, indekse i druga bazne objekte. Npr.
vaa produkciona Oracle baza podataka moe imati jedan tablespace rezervisan za HR aplikaciju a drugi tablespace
za aplikaciju osnovna sredstva. Svaki tablespace je fiziki predstavljen sa jednim ili vie data fajlova na disku koji
formiraju dio baze podataka. Baza podataka je logiki napravljena od odredjenog broja tablespace-ova a tablespace-
ovi su fiziki sainjeni od odredjenog broja (jednog ili vie) data fajlova. Dakle, Oracle-ov ekvivalenat (uslovno
govorei samo na nivou apstrakcije modela) za SQL Server database je tablespace.

Poto su ovo slini mehanizmi u svojoj funkcionalnosti, proces kreiranja baze podataka u SQL Serveru je slian
procesu kreiranja tablepace-a u Oracle-u. Bilo da kreirate bazu podataka (SQL Server) bilo da kreirate tablespace
(Oracle), DBA mora prvo da specificira ime tog objekta. DBA u nastavku vri dodjelu jednog ili vie data file-ova bazi
podataka odnosno tablespace-u. Na kraju, definie se inicijalna veliina fajlova i mehanizmi za promjenu veliine tih
fajlova kada se napune podacima.

Slino kao to SQL Server korisnike baze podataka mogu biti offline i read-only, tako mogu biti i Oracle korisniki
tablespace-ovi. I upravo kao to jedan ili vie data fajlova u SQL Server korisnikim bazama podataka mogu biti read-
only, jedan ili vie data fajlova kod Oracle korisnikih tablespace-ova mogu biti postavljeni kao offline.

Ipak, baza podataka i tablespaces se razlikuju jedno od drugog u nekim stvarima:

- Kod SQL Servera, data files mogu logiki biti grupisani u filegroups. Oracle tablespaces nemaju taj koncept.

- Kod SQL Server baza podataka, svaka baza podataka ima svoj vlastiti transakcijski log a svojstva log fajla moraju biti
specificirana tokom specificiranja kreiranja baza podataka. Za Oracle, transakcije za cijelu bazu podataka (a to
znaii za sve tablespace-ove) se snimaju u jedan redo log. Posljedica ovoga je da ne postoji mogunost da se kreira
individualni log za tablespaces.

Za SQL Server, baza podataka moe biti kreirana sa opcijom simple recovery mode. Simple recovery mode znai da
baza podataka nema aktivan mehanizam za praenje izmjena podataka (sve log informacije se briu iz log fajla
odmah poslije izvrenja checkpointa). Oracle ima kod sebe slian mehanizam ali nije mogue da se ovaj
mehanizam implementira na pojedinanom tablespace-u ve na cjeloj Oracle bazi.
Oracle vs SQL Server - Drugi dio
Details
Category: Baze podataka
Hits: 203

StartUp i ShutDown

StartUp i ShutDown su operacije nad bazama podataka koje su razliito implementirane kod Microsoft SQL Servera u
odnosu na Oracle RDBMS. Kod SQL Servera, ulazi u registry bazi, trace flag-ovi i system configuration vrijednosti
imaju kljunu ulogu u nainu realizacije startup-a baze podataka. Pored nekih drugih stvari, tokom procesa startovanja
baze se vri punjenje DLL-ova, kreiraju se memorijske strukture, otvaraju se portovi za listener, startuje se baza
podataka i izvrava se (opciono) recovery baze podataka. Postupak ima odstupanja samo ukoliko se trai praenje
error log-ova. Uobiajeno, DBA bi trebao startovati SQL service ili iz Control Panela > Services applet (za SQL Server
2000 i stariji), ili iz Configuration Managera (za SQL Server 2005 ili noviji). Moemo imati odreeni stepen kontrole u
vezi naina na koji se vri startovanje SQL Servera ukoliko komandu sqlservr.exe izvrimo iz command prompt-a u
single user mode-u koristei m switch. U mogunosti smo i da odaberemo startovanje serverskog procesa sa
minimalnom konfiguracijom koristei f switch.

Kod Oracle-a, startup se odvija u 3 odvojene i veoma precizno definisane faze. Moemo sve ove tri faze izvriti
odjednom jednom komandom ili moemo pozivati svaku pojedinanu fazu posebnom komandom u izvrenje u
zavisnosti od toga u kojoj se trenutnoj fazi podizanja baza podataka nalazi.

Da bi automatski i do kraja startovali Oracle, DBA treba samo da izda jednu komandu iz SQL*Plus-a ili nekog drugog
slinog query alata: STARTUP. U ovom sluaju, proces startovanja Oracle baze podataka e proi automatski kroz
sve tri faze i to.

Prvo e proitati Oracle parametar file, kreirati memorijske strukture i pozadinske procese. Ova faza rezultira
time da je DB instance kreirana ali baza podataka jo nije otvorena.

U sljedeoj fazi se vri tzv mounted baze podataka. Ako je izvreno mount-ovanje baze, to znai da je Oracle
otvorio control file i proitao njegov sadraj kako bi odredio lokaciju DB fizikih fajlova.

U treoj i finalnoj fazi, DB je opened. Ukoliko je prethodno Oracle sputanje baze podataka prolo
neregularno i ukoliko podaci u fajlovima baze podataka nisu sinhronizovani, prije nego to se Oracle poslednji
put ugasio, u treoj fazi podizanja Oracle-a se izvrava recovery operacija. Ova operacija podrazumjeva da
e se na nekompletnim transakcijama vriti rolled back a na kompletnim transakcijama e se vriti rolled
forward podataka. Na kraju ove faze, database files su sinhronizovani i raspoloivi za pristup od strane
korisnika.

Kod Oracle-a smo u mogunosti startovati svaku od prethodno specificiranih faza nezavisno to je jako zgodno u
sluaju da imamo problema prilikom pokretanja baze podataka.

Izdajui narednu komandu vrimo samo kreiranje instance:

STARTUP NOMOUNT;

U narednoj komandi, dajemo instrukciju Oracle-u da izvri punjenje control file-a:

ALTER DATABASE MOUNT;

Jednom, kada je baza podataka mounted, moemo izvriti otvaranje baze izdajui komandu:

ALTER DATABASE OPEN;

Ova tri koraka su ekvivalentna pokretanju SQL servera iz komandnog prompta sa ukljuenim trace flag-om i sa
ukljuenim nekim od switches-eva.
Kada je rije o sputanju baze podataka i kada elimo da normalno zaustavimo SQL Server, u mogunosti smo da to
uradimo iz Windows Control Panela - Services applet (mada se preferira metod koji ukljuuje Configuration Manager).
Zaustavljanje servisa prouzrokuje da se uradi update data file-ova i njihovih zaglavlja u odnosu na stanje memorijskih
struktura. Vri se zatvaranje log entry-a u memoriji i prenoenje njihovog sadraja u log file-ove na disku. Na kraju se
vri i gaenje svih konekcija. U mogunosti smo kod SQL servera da izdamo komandu SHUTDOWN iz Query
Analyzer ili iz Management Studio-a. Jedna od opcija prilikom izdavanja ove komande je da se komanda za sputanje
baze moe izdati sa opcijom WITH NOWAIT. Kada se upotrebi ova opcija, SQL Server zaustavlja svoj rad a da
prethodno ne vri nikakva sinhronizovanja podataka u svojim fajlovima. Ovo ima za posljedicu da se prilikom novog
pokretanja SQL Servera izvrava rollback transakcija koje su bile nekompletne.

Sasvim oekivano, sputanje Oracle baze podataka se moe takoe izvriti izdavanjem jedne komande i ukoliko
pretpostavljate da je to komanda SHUTDOWN, u pravu ste. Ipak, Oracle-ova SHUTDOWN komanda se moe izvriti
sa 4 razliite opcije.

Ukoliko izvrimo komandu SHUTDOWN ABORT, onda je situacija slina kao kod SQL serverove komande
SHUTDOWN WITH NOWAIT. Ovo je ekvivalentno situaciji da se server iskljuio iskljuenjem strujnog
napajanja. Oracle-u u ovom sluaju nije data mogunost da izvri bilo kakvu sinhronizaciju podataka. Fiziki
fajlovi nisu aurirani; logovi nisu ispranjeni niti je njihov sadraj prenesen na diskove.

Izvravanje SHUTDOWN IMMEDAITE e imati za rezultat da Oracle zatvara sve postojee konekcije koje
nisu dio bilo kakve aktivne transakcije i odbija bilo koji novi zahtjev za novim transakcijama. Postojee aktivne
konekcije sa aktivnim transakcijama e takoe biti zatvorene sa rolled back opcijom. Poslije ovako
realizovanih aktivnosti, baza podataka e biti sputena.

Ukoliko elite da sve postojee aktivne transakcije kod Oraclea regularno zavre svoj rad prije nego se izvri
sputanje baze podataka, moemo izdati komandu SHUTDOWN TRANSACTIONAL. Ova komanda je slina
prethodnoj komandi SHUTDOWN IMMEDIATE, ali uz opciju da se sesijama dozvoljava da regularno
kompletiraju svoje aktivne transakcije prije nego se te sesije iskljue.

Shutdown komanda koju DBA najee izvrava je SHUTDOWN NORMAL. Ova komanda takodje ima za
posljedicu da se odbijaju svi zahtjevi za novim transakcijama. Ipak, Oracle izvrava shut down samo kada se
izvri zatvaranje svih korisnikih konekcija i kada korisnici urade logged off. Za razliku od drugih shutdown
metoda, kod ovog metoda Oracle ne forsira terminiranje sesija.
Sigurnost baze podataka

Jedna od oiglednih razlika izmedju SQL Servera i Oracle-a na nivou sigurnosti je da je kod SQL Servera pristup bazi
podataka dvofazni proces. Na nivou instance, server odrava listu korisnikih naloga koji se nazivaju logins. Logins
su nalozi kojima su data prava da se poveu na instancu baze podataka. Ipak, da bi pristupio konkretnoj bazi
podataka koja je vlasnitvo konkretne instance, login nalog treba da se mapira na korisniki nalog unutar baze
podataka. SQL Server login moe biti ili lokalni Windows login ili nalog iz aktivnog direktorijuma ili sertifikovani klju.
Nalog moe biti i neto to je potpuno nezavisno od windows-a: DBA administrator moe kreirati nalog koji posjeduje
svoju vlastitu autentifikaciju preko username/password-a unutar SQL Servera. U varijanti kada se koristi windows-ov
nalog, odnosno nalog koji se vezuje za AD Windowsa govorimo o trusted tipu nalogu. Ukoliko koristimo nalog
kreiran unutar SQL Servera, govorimo o non-trusted tipu nalogu.

Za Oracle, ne postoji koncept trusted i non trusted naloga. Nalog obinog korisnika se kreira samo jednom i na
jednom mjestu u bazi podataka. Za razliku od SQL Servera, Oracle ne vri mapiranje naloga iz operativnog sistema
u naloge baze podataka.

Kada se instalira SQL Server, kreira se poseban non-trusted nalog pod imenom sa (akronim za System administrator).
sa je ugraeni DBA nalog koji je vlasnik svake baze podataka koja se kreira na instanci. On ima potpunu kontrolu nad
serverom: sa moe da kreira, mjenja i brie logins-e i baze, mijenja sistemsku konfiguraciju, sputa instancu i
dodjeljuje drugim korisnicima DBA privilegije.

Osim sa naloga, svaka baza podataka e takoe imati i dbo ili database owner nalog. Ovaj nalog e biti mapiran na
nivou servera kao glavni korisnik owner koji je kreirao bazu podataka. Database owner ima sve privilegije unutar
svoje baze podataka ali nema nikakvih prava izvan konkretne baze podataka.

Ako razmatramo Oracle, kada se kreira Oracle baza podataka, moe biti kreirano desetak naloga sa system nivoom
privilegija. Po defaultu, svi ovi nalozi e imati statuse expired i locked osim 4 (dakle, samo 4 e biti aktivna). etiri
specijalna korisnika naloga su sys, system, sysman i dbsnmp. sys nalog je ekvivalentan SQL Server-verovom
nalogu sa. Korisnik sys je vlasnik data dictionary-a (Oracle-ov data dictionary je kreiran u sys emi). Korisnik system
ima pristup svim objektima u bazi podataka.

Pored naloga, SQL Server takoe ima unaprijed predefinisano nekoliko fiksnih serverskih rola. Ove fiksne role su
poput Windows groupa - mogu da sadre jedan ili vie login-a. Svaka rola ima unaprijed definisani set privilegija. Svi
lanovi role (korisnici, logins koje kasnije dodjeljujemo ovim rolama) na taj nain imaju isti nivo prava nad serverom.
Serverska rola sa najveim nivoom privilegija je sysadmin koja ima isti nivo privilegija kao i dba nalog. Kod SQL
Server-a rola ne moe da sadri druge role ne mogu se prenositi prava iz jedne role u drugu. Na nivou svake od
baza podataka unutar instance takodje postoje role unutar kojih se mogu dodjeljivati privilegije koje vae za konkretnu
bazu podataka. Ove role se kasnije dodjeljuju korisnicima user-ima koji se kreiraju na nivou baze unutar SQL Server
instance

Kod Oracle-a takodje sreemo pojam role. Za Oracle, najvii nivo privilegije se dodjeljuje dba roli. Oracle ima
poseban tip privilegija sysdba i sysoper. Kod Oraclea korisnik kojem budu dodjeljene sysdba ili sysoper privilegije
moe izvravati administrativne operacije (kao to su sputanje i podizanje baze podataka npr). Oracle dozvoljava da
se rolama dodjeljuju (prenose) prava iz drugih rola rola moe da sadri rolu. Na ovaj nain se moe formirati itava
hijerarhija rola.

Kao to je reeno ranije, SQL Server login moe biti ili trusted (Windows nalog) ili non-trusted. To znai da SQL Server
korisnik moe biti provjeravan preko 2 tipa autentifikacije: trusted ili non-trusted. Kada se koristi trusted ili Windows
autentifikacija, SQL Server e se ponaati kao da je korisnik koji se prijavljuje na bazu ve provjeren od strane
Windows operativnog sistema. Ukoliko korisnik ima validan nalog u AD ili na lokalnom Windows Serveru, SQL Server
nee od tog korisnika traiti da se autentifikuje ponovo kroz username / password prilikom povezivanja na SQL Server
bazu podataka. Kod non-trusted metoda authentifikacije, SQL Server e zahtjevati od korisnika da unese username i
password. SQL Server e tada uporediti uneene podatke za username/password sa svojim vlastitim podacima u
svojoj internoj listi korisnika.

Kod Oracle-a, korisnik moe biti autentifikovan na 3 razliita naina:

Data Dictionary

Password File

Operativni sistem (ovo je razliito od SQL Server trusted connection methoda autentifikacije)
Meu pobrojanim nainima, data dictionary metod je najei metod za autentifikaciju korisnika na Oracle bazu
podataka. Ostala 2 metoda se koriste kada baza podataka nije raspoloiva ili kada se ne izvrava instanca baze
podataka. Kada se obini korisnik pokuava povezati na Oracle bazu podataka koja je ve otvorena, njegovi
autentifikacioni podaci se provjerava u odnosu na informacije koje se uvaju u data dictionary Oracle baze podataka.
Mada ovaj metod radi dobro za obine korisnike, DBA i sistem administratori koji imaju potrebu da kreiraju, otovre,
startuju ili spuste bazu ne mogu biti verifikovani kroz ovakav metod autentifikacije. Ovo je zato to Oracle instanca
moe da radi a da pri tome baza podataka nije podignuta ili ak nije ni kreirana. DBA e biti jedini korisnik koji moe
kreirati ili otvoriti bazu podataka iz instance. Poto u tom trenutku nije aktivan data dictionary za autentifikaciju, Oracle
ima potrebu za nekim oblikom eksterne autentifikacije korisnika. Ovaj oblik eksterne autentifikacije moe biti
realizovan kroz password file ili kroz operativni sistem na kojem hostuje Oracle instanca.

Password file sadrii parove username / password za naloge kojima su dodjeljene sysdba ili sysoper privilegije.
Kada se Oracle korisnik konektuje na bazu podataka sa nekom od ove dvije privilegije, on moe startovati, monitrati,
otvoriti, zatvoriti, demontirati, spustiti ili promjeniti strukturu baze podataka.

Ukoliko je korisnik direktno prijavljen na server na kojem hostuje Oracle instanca, tada takav korisnik moe koristiti i
autentifikaciju operativnog sistema. Sa validacijom na nivou operativnog sistema, Oracle provjerava da li korisnik koji
pokuava da se prijavi lan grupe unutar operativnog sistema koja je vlasnik Oracle softvera.Na windows serveru, to
je lokalna windows grupa ora_dba, za Unix sisteme, to je tipino dba grupa. Ukoliko je taj korisnik lan privilegovane
grupe, nije potrebno da se prijavljuje sa posebnim username i password.

Da bi pojasnili kako ovo funkcionie, razmotrimo 2 primjera.

U komandi u nastavku, sys korisnik pokuava da se sa privilegijama sysdba povee na bazu dbname koristei
password file authentication

CONNECT sys/password@DBNAME AS SYSDBA;

U komandi u narednom primjeru, korisnik se direktno povezuje sa servera na kojem hostuje Oracle. Poto je taj
korisnik ve validovan na nivou operativnog sistema i njegov nalog je lan grupe operativnog sistemakoja je vlasnik
Oracle instalacije, takvom korisniku nije potrebna dodatna provjera u vidu posebnog username i password. Umjesto
toga, on unosi samo simbol /.

CONNECT / AS SYSDBA;

Treba ukazati i na razliku u tretiranju eme baze podataka izmeu ova dva RDBMS-a. Kod Oracle-a, prilikom kreiranja
korisnika na bazi podataka se kreira schema koja je u potpunosti vezana za njega. Izmedju korisnika i scheme je 1:1
odnos. Schema pretstavlja skup svih objekata baze podataka kojima korisnik moe na neki nain pristupati (select,
insert, update, delete, execute, modify).

Kod SQL servera je stvar drugaija. emu kreira neki korisnik (tipino admin) i definie skup tabela, procedura,
funkcija, view-ova i ostalih baznih objekata sa odredjenim skupom privilegija nad svakim od tih objekata. U narednoj
iteraciji se definiu korisnici ili role koji pripadaju konkretnoj emi. Sa ovakvog stanovita je interesantno rjeenje da se
aplikativni moduli definiu na nivou eme a onda da se korisnicima dodjele prava rada nad tako definisanom emom.
Oracle vs SQL Server -Cetvrti dio
Details
Category: Baze podataka
Hits: 237

Error Log vs Alert Log

SQL Server u svom fajl sistemu odrava jedan fajl - tekui log za snimanje informacija o uspjenosti izvrenja
odreenog skupa operacija nad bazom podataka. Ovaj log ukljuuje informacije u vezi sa dogaajima koji su nastali
prilikom pokretanja baze podataka, prilikom izvrenja recovery-a, zatim dogaaje koji su u vezi sa korisnikim
aktivnostima, izvrenjem backup-a, aktivnostima koje uzrokuju promjenu konfiguracije baze podataka, dogaaje koji
se odnose na nekorektno prijavljivanje na bazu podataka, razne vrste greaka i upozorenja itd. Svaki put kada se
startuje SQL Server kreira se i novi log file. Ovaj log file je poznat kao SQL Server Error Log.

Error log je primarni izvor podataka za DBA prilikom otkrivanja uzroka nastanka raznih incidenata na bazi podataka.
Po defaultu SQL Server uva posljednjih 6 error logova a kada se napuni posljednji esti log, sljedei kandidat za
upis novih podataka o radu sistema postaje u tom trenutku najstariji error log file. Ovo po defaultu ponaanje se
moe promjeniti. SQL Server se moe konfigurisati da uva unaprijed definisani broj fajlova za error logove. Tekui
error log nosi ime ERRORLOG (bez ikakve druge dodatne ekstenzije) dok se error log koji je stariji od tekueg
imenuje kao ERRORLOG.1, onaj koji je jo stariji dobija ime ERRORLOG.2 itd.

Oracle-ov ekvivalenat za SQL Server Error Log se zove Alert Log file. Alert Log sadri informacije o podizanju i
sputanju baze podataka, oporavku instance, izmjenama konfiguracije, internim grekama u bazi podataka,
vrijednostima inicijalnih parametara itd.

Za razliku od SQL Server error loga, Oracle alert log ne vri kreiranje novog file-a svaki put kada se uradi restart
instance. U stvari, Oracle odrava samo jedan Alert Log file koji moe rasti neogranieno a u mjeri u kojoj se
informacije pohranjuju u njega.. Alert Log e uvjek imati ime koje se formira u obliku alert_<instance>.log gdje je
<instance> Oracle-ovo ime instance. Poput DBA kod SQL Servera, Oracle DBA koriste Alert Log kako bi provjerili
postojanje potencijalnih problema u radu baze podataka.
I SQL Server error log i Oracle alert log su obini ASCII tekst fajlovi koji se mogu otvoriti u bilo kojem tekst editoru.
SQL Server Management Studio obezbjeuje pregled error log-ova kroz Windows interfejs. Oracle-ov Enterprise
Manager Database Control obezbejuje pregled alert logova, takoe kroz web interface.

Lokacija SQL Server error log-a je uslovljena definicijom u registry-u. Po defaultu lokacija je ispod LOG direktorijuma
SQL Server instalacionog foldera. Kada je rije o Oracle-u, lokacija alert log-a je odredjena inicijalizacionim
parametrom koji ima naziv BACKGROUND_DUMP_DEST a njegova najea definicija je bdump folder ispod
$ORACLE_HOME direktorijuma.

Start-up i Configuration parametri

Kada se SQL Server instalira, takoe se kreira i odredjeni broj Windows registry kljueva. Ovi registry kljuevi
specificiraju razliite vrijednosti za razne parametre koji su potrebni SQL Serveru za njegov rad. Npr. jedan od registry
kljueva definie lokaciju za error log file, drugi registry klju bi trebao da sadri lokaciju za default backup folder itd.
SQL Server koristi vrijednosti ovih registry kljueva za svoje operacije. SQLSERVR.EXE moe da ima, pored ovih
kljueva i odreeni broj inicijalnih parametara koji su povezani sa exe komandom, ukljuujui i trace flags. Ovi, tzv
add-on parametri bi trebali da kontroliu na koji nain bi trebala instanca da se ponaa kada se pokrene. Pored
inicijalnih parametara i vrijednosti u registry kljuevima, SQL Server ima i veliki broj internih konfiguracionih
parametara koji se koriste za fino podeavanje instance. Primjer jednog od takvih parametara je max server memory
kojim se specificira maksimalna veliina memorije koja se moe odvojiti za instancu. Server konfiguracioni parametri
se smjetaju u sistemske meta-tabele kojima se kasnije preko odgovarajuih SELECT upita moe pristupiti (naravno,
ukoliko je konkretnom korisniku dozvoljeno da pristupi tim tabelama)

Izmjena SQL Server konfiguracionih parametara se moe uraditi na nekoliko naina:

Korienjem sp_configure sistemske bazne procedure

Korienjem server properties dijalog box-a iz Management Studio ili Enterprise Manager-a

Koristei razliite dodatne alate: facets (SQL 2008) ili Surface Area Configuration tool (SQL 2005)

Kod Oracle-a, konfiguracioni parametri se dobijaju iz dva fajla operativnog sistema koji su neophodni za startovanje
instance i za otvaranje baze podataka. Prvi fajl je initialisation parameter file a drugi je control file. Inicijalizacioni
parametar fajl sadri parametrizovane vrijednosti koji diktiraju na koji nain e biti kreirana instanca. Da podsjetimo,
Oracle instance je sainjena od memorijskih struktura i pozadinskih procesa. Pored ostalih stvari, parametar fajl sadri
vrijednosti koje kazuju Oracle-u koliko mnogo memorije da odvoji za instancu, koliko mnogo korisnikih procesa se
moe povezati na instancu konkurentno, koje baze podataka su povezane sa konkretnom instancom. Kako Oracle
ita ovaj file tako formira elemente memorije na osnovu njegovog sadraja.

Parametar fajl moe biti ili obini ASCII tekst fajl ili binarni fajl. Statiki parametar fajl se zove pfile i ima ime na
operativnom sistemu u obliku init<SID>.ora gdje je SID - System Identifier instance. Binarni parametar fajl, ili spfile,
imenuje se po ablonu spfile<SID>.ora. Jedna znaajna razlika izmeu tekst-orjentisanog pfile i binarnog spfile je ta
da kada se koristi pfile, Oracle ita njega samo jednom prilikom podizanje instance. Bilo kakva budua promjena u
parametar fajlu e biti implementirana na bazi podataka tek poslije njenog restarta. Kod spfile-a, Oracle moe
promjeniti sadraj i definiciju baze ak i kada instanca radi. Oracle 11g verzija baze podataka, npr ima vie od 250
inicijalizacionih parametara koji se mogu individualno setovati. Sreom, DBA nemaju potrebu da specificiraju
vrijednost za svaki od ovih 250 parametara. Konfiguracija 10-tak parametara je sasvim dovoljna za funkcionisanje
instance. Mnogi od ovih parametara se definiu u fazi instalacije RDBMS-a. Promjena inicijalizacionih parametara se
moe izvriti ili runo ili iz Oracle- ovog alata Enterprise Manager Database Control. U manuelnom reimu rada,
koristei komandu ALTER SYSTEM smo u mogunosti da izmjenimo sadraj spfile. Ukoliko koristimo pfile, DBA
moe izvriti izmjenu sadraja fajla koristei bilo koji text editor.

Control file je drugi fajl koji Oracle ita poto je izvrio startovanje instance. I lokacija control file je specificirana kao
jedan od parametara u parametar fajlu. Control file je mali binarni fajl koji sadri kritine informacije za funkcionisanje
baze podataka, ukljuujui imena i lokacije data file-ova i redo log file-ova, tablespace informacije i informacije o
uradjenim checkpoint-ima. Oracle koristi informacije iz control fajla da locira data fajlove i da ih otvori kako bi bili na
raspolaganju za upotrebu od strane korisnika. Nije mogue startovati bazu podataka ukoliko ne postoji korektan
control file. Zbog ovako znaajne uloge koju control file ima u Oracle arhitekturi, preporuuje se da korisnici rade sa
nekoliko kopija control file-a. Podaci o svim control file-ovima se nalaze u parametar fajlu. Isto kao to je sluaj sa
spfile-om, Oracle konstantno vri auriranje sadraja i control fajla dok je baza podataka otvorena. Ukoliko postoje
viestruke kopije control fajlova, svaki od control fajlova se auriraju u isto vreijeme sa istim informacijama.

Na kraju, poseban tip fajlova koji se takoe koristi od strane Oracle-a je i password file. Ovaj fajl sadri parove
usernames / passwords za one korisnike naloge kojima je dodjeljena privilegija da podiu i sputaju bazu podataka.
 Hits: 255

Transactional Consistency i Point-in-time Recovery

Microsoft SQL Server i Oracle imaju ugradjen mehanizam za zatitu korisnikih transakcija. Ideja koja se nalazi iza
transactional consistency je da se promjene koje se izvre nad podacima ne upisuju odmah u fajlove na disku
operativnog sistema. Umjesto toga, izmjene se upisuju u operativnu memoriju servera u dio koji se naziva buffer
cache. Iz buffer cache-a se podaci periodino prenose u fajl na disku u kojem su konkretni podaci za konkretne tabele
baze podataka. Pored buffer cache-a, u memoriji servera postoji jo jedan buffer. To je log buffer i on je vezan za
uvanje promjena nad podacima koje urade korisnici. Log buffer se koristi za kontinualno i sekvencijalno zapisivanje
svih izmjena koje su izvrene nad podacima u bazi podataka. Sadraj ovog buffera se upisuje u odvojeni nezavisni
fajl baze podataka na disku. Poto imamo dva nezavisna bafera sa podacima (buffer ke i log buffer ke) postoje i 2
odvojena pozadinska procesa koji upisuju sadraje ovih bufera u fizike fajlove na disku. Log buffer ke se mnogo
ee upisuje na disk nego buffer ke. To je zato to je operacija koja izvrava prenos log buffera mnogo bra log
file je obini sekvencijalni fajl kod koga se na njegov kraj dodaju novi slogovi sa podacima o promjenama na tabelama
u redosljedu u kojem su se promjene deavale (uoiti da je prepis iz buffer kea u fajl sa stvarnim podacima mnogo
sporiji jer se za taj prepis uvjek mora prvo nai tana pozicija u fajlu, tana tabela i slog na koji se upisivanje odnosi i
zbog toga se ovaj upis mnogo ree izvrava)

Ukoliko korisnik uspjeno komituje transakciju, promjene e postojati u buffer cache-u ali promjene iz buffer cache-a
nee biti odmah upisane u data fajlove na diskovima. Promjene e se snimiti i u sekvencijalni log buffer. Sadraj log
buffer-a e biti preneen na log file na disku prije nego to korisnik dobije signal od RDBMS-a da je uspjeno uradjen
commit njegove operacije.

SQL Server ovaj log fajl naziva Transaction Log. Kod Oracle-a se ovaj log naziva Redo Log. U SQL Server
terminologiji, prostor u memoriji koji sadri izmjene nad podacima je poznat pod imenom Log Buffer. Oracle za tu
namjenu koristi termin Redo Buffer. Bez obzira na razliku u imenovanju, funkcije log fajlova su identine: ukoliko
server neoekivano padne, database server e pretraiti sadraj log fajla poslije restarta baze podataka. Ukoliko
server u log fajlu pronadje komitovane transakcije koje nisu preneene u fajl sa podacima, on e izvriti izmjene na
podacima u data fajlu na disku tako da e se izmjene jednom uinjene od strane korisnika prije pada sistema
reflektovati u bazi podataka poslije njenog restarta. Ukoliko server prilikom restarta u log fajlu pronadje transakcije
koje su nekompletne ili transakcije nad kojima je uradjen roll back, server e uraditi roll back i na podacima u data
fajlovima. Prva faza obrade se naziva redo faza a druga je poznata pod nazivom undo.

SQL Server odrava po jedan transaction log za svaku od svojih baza na hostu. Database transaction log moe imati
jedan ili vie transakcionih log fajlova koji su mu dodjeljeni. Transactioni log fajlovi se kreiraju u vrijeme kreiranja baze
podataka a dodatni fajlovi se mogu kreirati kasnije. Kod Oracle-a, koncept baze podataka obuhvata sve fizike data
fajlove i logike tablespace-ove kojima on upravlja. Oracle-ovi redo logovi se kreiraju kao set fajlova koji prihvataju
promjene koje se naine u svim tablespace-ovima. Svaka Oracle baza podataka mora da ima najmanje 2 redo log
file-a za svoje operacije. Moe postojati vie od 2 redo log file-a, ali su 2 minimum.

Jedna oigledna razlika izmedju SQL Server transaction logova i Oracle redo logova je da SQL Server transaction log
fajlovi nisu grupisani ninakoji logian nain. Redo log fajlovi kod Oracle-a su dodjeljeni dvema ili veem broju redo log
grupa. Svaka Oracle baza podataka mora imati najmanje 2 redo log grupe a svaka grupa mora imati jedan ili vie
redo logova. Log fajlovi u svakoj grupi se nazivaju lanovima (members) grupe.

Oracle upisuje redo ulaze iz svog log buffer-a u jednom trenutku u jednu redo grupu. Kada se redo ulaz upie u redo
log grupu, svaki member fajl groupe se update-uje u isto vrijeme. Postojanje vie od jednog fajla u redo log fajl grupi
obezbjedjuje zatitu od eventualnog oteenja fajla u grupi i naziva se multiplexing. Kada se log grupa napuni sa
redo slogovima, Oracle e startovati upis logova u narednu redo grupu. Ovaj postupak se naziva log switching.
Jednom, kada se grupa napuni, upis e se prosljediti na sljedeu grupu i tako redom. Ako je baza u NoArchiveLog
modu, kada se napune sve redo grupe (bez obzira da li ih ima 2 ili vie), Oracle e isprazniti prvu redo log grupu u
lancu i poeti ponovo upis u nju. Ukoliko Oracle baza radi u tzv Archive log modu i ukoliko su napunjeni svi ulazi u
redo log bufferima, a pri tom iz redo log buffera koji je naredni za upis izmjenjenih podataka na disk podaci nisu
preneseni na redo log fajl na disku, korisnika(e) transakcija(e) e biti zaustavljene dok se redolog buffer ne isprazni.
Pranjenje podataka iz Redo log buffer-a se najee vri automatski (mada se moe insistirati i na runom prenosu).
Konfiguracionim parametrima na nivou baze se moe promjeniti nain izvrenja ove operacije.
SQL Server transakcioni log baze podataka se takodje puni u sekvenciajlnom redu. Log se ne brie automatski osim
ako baza podataka ne radi u tzv simple recovery modu ili ukoliko se ne uradi backup transaction loga. Ukoliko logiki
transaction log za bazu podataka postane pun i ukoliko se log fajl za koji je logiki transakcioni log vezan toliko velik
da se vie ne moe poveavati, baza podataka postaje neraspoloiva za bilo kakvu korisniku aktivnost. Ako se izvri
backup transakcijskih logova, SQL Server e dozvoliti da se preko backup-ovanih ulaza u log fajl uradi novi upis novih
transakcija.

Sljedei detalj koji treba da primjetimo jeste da se SQL Serverov transaction log fajl moe konfigurisati na nain da se
poveava automatski kada postoji potreba za veim prostorom u njemu. Oracleov redo log fajl se kreira sa
predefinisanom veliinom i ona se ne poveava automatski osim ako se ta veliina kasnije runo ne promjeni..

Sa stanovita raspoloivosti podataka, obadvije platforme omoguuju point-in-time recovery. Ukoliko se eli, ova
osobina moe biti iskljuena. Kada je SQL Server baza podataka konfigurisana da radi u point-in-time recovery modu,
kae se da je ona u full recovery mode-u. Svaka modifikacija podataka u bazi podataka se evidentira u tranasction
log-u nezavisno od toga koji se recovery moda primjenjuje za bazu podataka. Ovi log slogovi ostaju u fajlu dok se ne
uradi transaction log backup. Baza podataka moe biti i u simple recovery mode u kom sluaju slogovi u
transaction logu ostaju dok se ne izvri checkpoint. Checkpoint snima modifikovane podatke iz buffer kea i log kea
u data fajlove i log fajlove na disku. Ukoliko baza podataka radi u tzv. simple recovery modu, svi slogovi u transaction
logu prije najstarije otvorene transakcije se briu poslije izvrenog checkpoint-a. Ovo se radi zato to SQL Server zna
da su sve komitovane transakcije prije najstarije otvorene transakcije ve bile upisane u fajl sa podacima.

Ukoliko se desi greka (fizika ili logika) u bazi podataka, prvo se treba restaurirati njen poslednji full backup a zatim
se trebaju primjeniti svi backup-ovani tranasakcioni logovi koji su uradjeni poslije poslednjeg full backupa baze
podataka. Ovo svojstvo nam omoguava da vratimo stanje baze podataka u bilo koji momenat vremena u prolosti.
Treba imati u vidu da ova funkcionalnost radi samo ako je baza podataka u full recovery mode.

Oracle ima slian koncept. Oracle baza podataka moe biti u ARCHIVELOG ili NOARCHIVELOG modu. Kada radi u
NOARCHIVELOG modu, sadraj prve redo log grupe se ponovo koristi za upis im se poslednja log grupa u lancu
napuni. Potoo se sadraj redo log grupa ne arhivira u ovom reimu rada, sistem se nee moi vratiti na stanje u
nekoj vremenskoj taki u prolosti koja je izbrisana u redolog-u. Funkcionalno, ovo je ekvivalentno SQL Serveru koji je
u simple recovery modu.

Ako Oracle baza podataka radi u ARCHIVELOG modu, jedan ili vie archive procesa e raditi u pozadini. Arhiv
procesi vre backup sadraja redo log grupa kada one postanu pune i pohranjuju ih u odvojene fajlove na disk
podsistemu. Ove sauvane kopije redo log grupa su poznate pod imenom archived log. Jednom kada se log grupa
arhivira, moe se ponovo koristiti za upis podataka. Ako pokuamo nai paralelu, arhiving kod Oracle redo log grupa
je funkcionalno ekvivalentno SQL Server transaction log backup-u a ARCHIVELOG mod je ekvivalentan full recovery
modu.

Za Oracle, kao i za SQL Server, archivirani logovi se mogu primjeniti na bazu podataka tek poto se uradi restore
nekog full backup-a. Razlika izmedju ova dva sistema za upravljanje bazama podataka je da kod SQL Servera,
transaction log backup task treba biti postavljen manuelno runo kao scheduled job, dok kod Oracle-a archiver
proces automatski vodi rauna o backup-u kada se baza podataka jednom konfigurie za tu namjenu.
Konano, ekvivalencija izmedju ovih platformi moe biti uoena takodje i u terminologiji recovery time. Kao to je
napomenuto ranije, kada se startuje DB engine, cjeli proces e ii kroz redo i undo fazu. Ukupno vrijeme provedeno u
uvim dvijema fazama je poznato kao recovery interval. Oigledno je da e DBA eliti da recovery interval bude to je
mogue manji. Kod SQL Servera, DBA moe konfigurisati ovaj interval izvravajui komande date u nastavku:

sp_configure show advanced option, 1

reconfigure
sp_configure recovery interval, <time-in-minutes>
reconfigure

Ova komanda modifikuje sistemske konfiguracione parametre. Kada se postavi recovery interval, SQL Server e
upodobiti frekvenciju svog checkpoint procesa na svakoj od baza podataka tako da vrijeme provedeno tokom
recovering-a svake od baza podataka ne premauje ovaj interval. Recovery interval se specificira u minutama.

Oracle-ov ekvivalenat za recovery interval je Mean Time To Recover (MTTR). Ovaj parametar se moe setovati
mjenjajui Oracleov inicijalni parametar FAST_START_MTTR_TARGET. Ovaj parametar moe biti postavljen za tzv
fine-tune checkpoint frequency. Njegova vrijednost odredjuje koliko mnogo sekundi e Oracle provesti u database
recovery poslije pada servera. Parameter moe biti postavljen koristei komandu poput sljedee:

ALTER SYSTEM SET FAST_START_MTTR_TARGET=<number_of_seconds> SCOPE=spfile;

Oracle vs SQL Server - sesti dio
Details
Category: Baze podataka
Hits: 188

System Metadata
Oracle i Microsoft SQL Server baze podataka imaju veliki broj tabela i drugih objekata kao to su pogledi, funkcije,
bazne procedure koji se automatski kreiraju kada se instalira softver za upravljanje bazom podataka i kada se kreira
baza podataka. Ove tabele na sistemskom nivou sadre metapodatke o logikim i fizikim atributima o instanci i o
bazama podataka koje se hostuju preko njih. U Oracle terminologiji skup ovih tabela se naziva data dictionary dok su
u SQL Server terminologiji ove tabele poznate pod imenom system tables.

U SQL Serveru verzija 2005 ili novijoj, veina objekata sistemskog nivoa je smjeteno u resource bazu podataka a
manji dio se nalazi i u master bazi podataka. Kod Oracle-a, tabele data dictionary-a se nalaze u tablespace-ovima
SYSTEM i u SYSAUX svake od baza podataka. Od SQL Server verzije 2005, direktan pristup sistemskim tabelama
baze podataka je zabranjen. Umjetsto toga, formiran je odreeni skup view-ova koji su poznati pod nazivom
catalogue views. Njihova namjena je da obezbjede jedinstven interface prema sistemskim meta podacima. Kod
Oracle-a su tabele koje pripadaju data dictionary kriptovane ime je onemoguen direktan pristup ili modifikovanje
njihovog sadraja od strane korisnika. Kao i kod SQL Servera, i kod Oracle-a je kreiran skup view-ova preko kojih je
dozvoljeno da DBA i developeri vre upite nad ovim skupom podataka. U Oracle terminologiji ovi view-ovi se nazivaju
data dictionary views.

Definicije katalokih view-ova se uvaju u SQL Server resource bazi podataka. Ovi sistemski view-ovi pripadaju
posebnoj emi koja se naziva sys schema i moe im se pristupiti iz svake baze podataka. Npr. da bi izlistali sve baze
podataka koje imamo na SQL Server instanci, DBA moe izvriti naredni upit iz bilo koje baze podataka:

SELECT * FROM sys.databases

Za listu svih objekata koji postoje u bilo kojoj bazi podataka treba koristiti sys.objects katalog view. I on se moe
koristiti bez ogranienja:

SELECT * FROM sys.objects

Kod Oracle-a, data dictionary je u vlasnitvu SYS korisnika. Za razliku od SQL Server-a, svaki data dictionary view
moe postojati u tri razliita oblika i svaki od ovih oblika e davati razliit skup informacija. Dictionary view-ovi su zbog
toga podjeljeni u tri razliita tipa. Prefiksi u imenu view-a e indicirati koji tip informacija treba biti prezentovan
korisniku:

View-ovi sa prefiksom USER_ e dozvoliti korisnicima da pregledaju informacije o db objektima koje su oni
sami krirali.

View-ovi sa prefiksom ALL_ e dozvoliti korisnicima da pregledaju informacije o db objektima koje su oni
sami krirali i o objektima kod kojih je dozvoljeno da im konkretni korisnik pristupa.

DBA_ view-ovi su view-ovi za administratore baze podataka. Ovi view-ovi prikazuju kompletan set informacija
o svim objektima u bazi podataka. Obini korisnik nema prava pristupa DBA_ view-ovima.

Npr, dva upita koja su ispisana u nastavku daju kao rezultat razliite skupove podataka:

SELECT TABLE_NAME, TABLESPACE_NAME FROM USER_TABLES;

SELECT TABLE_NAME, TABLESPACE_NAME FROM DBA_TABLES;

Prvi upit e vratiti listu tabela koje je kreirao korisnik koji je pokrenuo ovaj upit dok e drugi upit vratiti skup svih tabela
koje postoje u bazi podataka.

Dynamic Views
Pored data dictionary view-ova, Oracle posjeduje i odredjeni skup view-ova koji se nazivaju Dynamic Performance
Views koji omoguavaju uvid u stanje memorijskih struktura instance i u sadraj kontrolnog fajla baze podataka.
Dynamic performance view-ovi se razlikuju od data dictionary view-ova po tome to oni iza sebe nemaju nikakvu
fiksnu tabelu u bazi podataka. Umjesto toga, oni vraaju informacije u realnom vremenu o stanju memorije na
serverima u kojoj se nalazi instanca. Ovi podaci se kumuliraju od trenutka kada se instanca pokrene, dogradjuju se
tokom ivotnog vijeka instance i nestaju iz sistema kada se instanca ugasi ili kada se instanca restartuje. Druga
razlika u odnosu na data dictionary view-ove je da DBA moe pristupiti data dictionary view-ovima samo kada je baza
podataka otvorena za normalno koritenje. Dynamic performance view-ovima se moe pristupiti im se instanca
pokrene, dakle i prije nego to se pokrenu baze podataka. Nekim od dynamic performance view-ova se moe
pristupiti samo ako je baza podataka u statusu mounted.

Ovi view-ovi se esto nazivaju V$ views zato to im ime poinje prefiksom V$. Kao primjer, upit koji je dat u nastavku
prikazuje inicijalne parmetre koji se koriste od strane Oracle instance:

SELECT NAME, DESCRIPTION, VALUE FROM v$system_parameter

Sljedei upit e prikazati informacije koje se odnose na stanje tekue sesije:

SELECT USERNAME, COMMAND, SCHEMANAME, OSUSER, MACHINE FROM V$SESSION

Kod SQL Server 2005, Dynamic Management Views ili DMV obezbjeuju veliki broj informacija o stanju memorije
instance. Kao i kod Oracle-a dynamic performance views, DMV za svoj rad u pozadini nemaju konkretne fizike
tabele. Ovi view-ovi se formiraju svaki put od poetka kada se izvri resetovanje servera ili instance. DMV-ovi
pripadaju sys emi i imaju ime koje poinje sa prefiksom dm_. U primjeru koji je dat u nastavku dobijamo podatke o
tekuim sesijama na SQL Server instanci:

SELECT * FROM sys.dm_exec_requests