1

Saša Tadić, dipl ing računarske tehnike web site: http://sasatadic.net46.net/Crvanj e-mail:sasatadict@yahoo.com Podgorica

Instances, Databases & Tablespaces

Možda najvažnija razlika izmedju Oracle-a i SQL Servera na nivou arhitekture je u shvatanju pojmova Instance i Database.

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

U središtu 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 može 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 više od jedne SQL Server instance koja je na računaru u statusu running, svaka instanca će imati svoj predefinisani skup sistemskih baza podataka. Instanca se ne može startovati ukoliko fali ili je oštećena bilo koja od sistemskih baza podataka izuzev baze msdb. Korisničke baze podataka, sa druge strane su kreirane od strane DBA i developer-a kada je instanca već instalirana i sistemske baze podataka startovane. Ovo korisničke 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 uključivati 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 fizičkom nivou, SQL Server baza podataka je pretstavljena skupom fajlova unutar operativnog sistema koji postoje na diskovima serverskog računara. 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 slučaju izvršavanja sistemskog recovery-a. I data i log file će uvjek pripadati nekoj konkretnoj bazi podataka - ne postoji mogućnost da dvije baze podataka dijele isti data ili log file. Ukoliko je baza podataka velika, može da sadrži nekoliko data fajlova. Više data fajlova u jednoj bazi podataka se mogu logički 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 računara alociran za njegove operacije. Ovaj memorijski prostor je poznat kao System Global Area (SGA) i podjeljen je na nekoliko tačno definisanih struktura. Pored memorijskog prostora, prilikom pokretanja Oracle-a, takodje se pokreće i odredjeni broj pozadinskih (background) procesa. Njihov osnovni zadatak je komunikacija sa SGA. Ovo dvoje zajedno – memorijski prostor i pozadinski procesi formiraju Oracle instance. Uočite da u ovom momentu Oracle baza podataka još nije u igri. U stvari, Oracle instanca može da radi savršeno čak i bez OnLine baze podataka ili baze podataka kojoj bi se moglo na neki način 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 logičko grupisanje objekata. Umjesto toga, postoji samo jedna baza, zajednički pojam za skup fajlova na disku koji primarno sadrže 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 smješteni podaci. Može postojati bilo koliki broj data fajlova u Oracle bazi podataka. Redo log files su nešta 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

2

veličine koji sadrže bitne informacije o konfiguraciji Orace baze podataka. Bez Control file, instanca neće moći da otvori bazu podataka.

Pored data, redo log i control files, baza podataka će takodje sadržati 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 korištenje od strane krajnjih korisnika. Kada je sistem “shut down”, instanca je izbrisana iz memorije: sve memorijske strukture i procesi su ispražnjeni ali baza podataka i dalje postoji na diskovima, mada u statusu “closed”. Kao što je rečeno ranije, moguće je imati Oracle instancu koja je podignuta a da baza podataka nije “open” – ovo je ključna razlika u odnosu na SQL Server gdje se instanca ne može startovati ukoliko nisu prvo startovane njene sistemske baze podataka. Sa druge strane, baš kao i kod SQL Servera, nemoguće je da se povežete na Oracle bazu podataka ukoliko instanca baze nije podignuta - startovana.

Generalno govoreći, 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, može imati jednu ili više 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 više instanci koje će se izvršavati na više računara a sve one će biti povezane sa jednom bazom na djeljenom (shared) disk sistemu.

Pitanje je, gdje se vrši logičko grupisanje baznih objekata unutar Oracle-a? U SQL Server-u, ovo logičko grupisanje je realizovano unutar same baze podataka. Kod Oracle-a je to realizovano kroz mehanizam koji se zove tablespaces. Oracle tablespace-ovi su logičke strukture koje u sebi grupišu tabele, view-ove, indekse i druga bazne objekte. Npr. vaša produkciona Oracle baza podataka može imati jedan tablespace rezervisan za HR aplikaciju a drugi tablespace za aplikaciju osnovna sredstva. Svaki tablespace je fizički predstavljen sa jednim ili više data fajlova na disku koji formiraju dio baze podataka. Baza podataka je logički napravljena od odredjenog broja tablespace-ova a tablespace-ovi su fizički sačinjeni od odredjenog broja (jednog ili više) data fajlova. Dakle, Oracle-ov ekvivalenat (uslovno govoreći – samo na nivou apstrakcije modela) za SQL Server database je tablespace.

Pošto su ovo slični mehanizmi u svojoj funkcionalnosti, proces kreiranja baze podataka u SQL Serveru je sličan 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 vrši dodjelu jednog ili više data file-ova bazi podataka odnosno tablespace-u. Na kraju, definiše se inicijalna veličina fajlova i mehanizmi za promjenu veličine tih fajlova kada se napune podacima.

Slično kao što SQL Server korisničke baze podataka mogu biti offline i read-only, tako mogu biti i Oracle korisnički tablespace-ovi. I upravo kao što jedan ili više data fajlova u SQL Server korisničkim bazama podataka mogu biti read-only, jedan ili više data fajlova kod Oracle korisničkih 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 logički 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 značii za sve tablespace-ove) se snimaju u jedan redo log. Posljedica ovoga je da ne postoji mogućnost da se kreira individualni log za tablespaces.

- Za SQL Server, baza podataka može biti kreirana sa opcijom simple recovery mode. Simple recovery mode znači da baza podataka nema aktivan mehanizam za praćenje izmjena podataka (sve log informacije se brišu iz log fajla odmah poslije izvršenja checkpointa). Oracle ima kod sebe sličan mehanizam – ali nije moguće da se ovaj mehanizam implementira na pojedinačnom tablespace-u već na cjeloj Oracle bazi.

3

StartUp i ShutDown

StartUp i ShutDown su operacije nad bazama podataka koje su različito implementirane kod Microsoft SQL Serverau odnosu na Oracle RDBMS. Kod SQL Servera, ulazi u registry bazi, trace flag-ovii system configuration vrijednosti imaju ključnu ulogu u načinu realizacije startup-a baze podataka. Pored nekih drugih stvari, tokom procesa startovanja baze se vrši punjenje DLL-ova, kreiraju se memorijske strukture, otvaraju se portovi za listener, startuje se baza podataka i izvršava se (opciono) recovery baze podataka. Postupak ima odstupanja samo ukoliko se traži praćenje error log-ova. Uobičajeno, 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). Možemo imati određeni stepen kontrole u vezi načina na koji se vrši startovanje SQL Servera ukoliko komandu sqlservr.exe izvršimo iz command prompt-au single user mode-ukoristeći –m switch. U mogućnosti smo i da odaberemo startovanje serverskog procesa sa minimalnom konfiguracijom koristeći –f switch.

Kod Oracle-a, startup se odvija u 3 odvojene i veoma precizno definisane faze. Možemo sve ove tri faze izvršiti odjednom jednom komandom ili možemo pozivati svaku pojedinačnu fazu posebnom komandom u izvršenje 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 sličnog query alata: STARTUP. U ovom slučaju, proces startovanja Oracle baze podataka će proći automatski kroz sve tri faze i to.

- Prvo će pročitati 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 sljedećoj fazi se vrši tzv mounted baze podataka. Ako je izvršeno mount-ovanje baze, to znači da je Oracle otvorio control file i pročitao njegov sadržaj kako bi odredio lokaciju DB fizičkih fajlova.

- U trećoj i finalnoj fazi, DB je opened. Ukoliko je prethodno Oracle spuštanje baze podataka prošlo neregularno i ukoliko podaci u fajlovima baze podataka nisu sinhronizovani, prije nego što se Oracle poslednji put “ugasio”, u trećoj fazi podizanja Oracle-a se izvršava recovery operacija. Ova operacija podrazumjeva da će se na nekompletnim transakcijama vršiti rolled back a na kompletnim transakcijama će se vršiti rolled forward podataka. Na kraju ove faze, database files su sinhronizovani i raspoloživi za pristup od strane korisnika.

Kod Oracle-a smo u mogućnosti startovati svaku od prethodno specificiranih faza nezavisno što je jako zgodno u slučaju da imamo problema prilikom pokretanja baze podataka.

Izdajući narednu komandu vršimo samo kreiranje instance:

STARTUP NOMOUNT;

U narednoj komandi, dajemo instrukciju Oracle-uda izvrši punjenje control file-a:

ALTER DATABASE MOUNT;

Jednom, kada je baza podataka “mounted”, možemo izvršiti otvaranje baze izdajući komandu:

ALTER DATABASE OPEN;

Ova tri koraka su ekvivalentna pokretanju SQL servera iz komandnog prompta sa uključenim trace flag-om i sa uključenim nekim od switches-eva.

Kada je riječ o spuštanju baze podataka i kada želimo da normalno zaustavimo SQL Server, u mogućnosti smo da to uradimo iz Windows Control Panela - Services applet (mada se preferira metod koji uključuje Configuration Manager). Zaustavljanje servisa prouzrokuje da se uradi update data file-ova i njihovih zaglavlja u odnosu na stanje memorijskih struktura. Vrši se zatvaranje log entry-a u memoriji i prenošenje njihovog sadržaja u log file-ove na disku. Na kraju se vrši i gašenje svih konekcija. U mogućnosti 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 spuštanje baze može izdati sa opcijom WITH NOWAIT. Kada se upotrebi ova opcija, SQL Server zaustavlja svoj rad a da prethodno ne vrši nikakva

4

sinhronizovanja podataka u svojim fajlovima. Ovo ima za posljedicu da se prilikom novog pokretanja SQL Servera izvršava rollback transakcija koje su bile nekompletne.

Sasvim očekivano, spuštanje Oracle baze podataka se može takođe izvršiti izdavanjem jedne komande i ukoliko pretpostavljate da je to komanda SHUTDOWN, u pravu ste. Ipak, Oracle-ova SHUTDOWN komanda se može izvršiti sa 4 različite opcije.

Ukoliko izvršimo komandu SHUTDOWN ABORT, onda je situacija slična kao kod SQL serverove komande SHUTDOWN WITH NOWAIT. Ovo je ekvivalentno situaciji da se server isključio isključenjem strujnog napajanja. Oracle-uu ovom slučaju nije data mogućnost da izvrši bilo kakvu sinhronizaciju podataka. Fizički fajlovi nisu ažurirani; logovi nisu ispražnjeni niti je njihov sadržaj prenesen na diskove.

Izvršavanje SHUTDOWN IMMEDAITE će imati za rezultat da Oracle zatvara sve postojeće konekcije koje nisu dio bilo kakve aktivne transakcije i odbija bilo koji novi zahtjev za novim transakcijama. Postojeće aktivne konekcije sa aktivnim transakcijama će takođe biti zatvorene sa rolled back opcijom. Poslije ovako realizovanih aktivnosti, baza podataka će biti spuštena.

Ukoliko želite da sve postojeće aktivne transakcije kod Oraclea regularno završe svoj rad prije nego se izvrši spuštanje baze podataka, možemo izdati komandu SHUTDOWN TRANSACTIONAL. Ova komanda je slična prethodnoj komandi SHUTDOWN IMMEDIATE, ali uz opciju da se sesijama dozvoljava da regularno kompletiraju svoje aktivne transakcije prije nego se te sesije isključe.

Shutdown komandakoju DBA najčešće izvršava je SHUTDOWN NORMAL. Ova komanda takodje ima za posljedicu da se odbijaju svi zahtjevi za novim transakcijama. Ipak, Oracle izvršava shut down samo kada se izvrši zatvaranje svih korisničkih konekcija i kada korisnici urade logged off. Za razliku od drugih shutdown metoda, kod ovog metoda Oracle ne forsira terminiranje sesija.

5

Sigurnost baze podataka

Jedna od očiglednih 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 održava listu korisničkih naloga koji se nazivaju logins. Logins su nalozi kojima su data prava da se povežu na instancu baze podataka. Ipak, da bi pristupio konkretnoj bazi podataka koja je vlasništvo konkretne instance, login nalog treba da se mapira na korisnički nalog unutar baze podataka. SQL Server login može biti ili lokalni Windows login ili nalog iz aktivnog direktorijuma ili sertifikovani ključ. Nalog može biti i nešto što je potpuno nezavisno od windows-a: DBA administrator može 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 običnog korisnika se kreira samo jednom i na jednom mjestu – u bazi podataka. Za razliku od SQL Servera, Oracle ne vrši 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 ugrađeni DBA nalog koji je vlasnik svake baze podataka koja se kreira na instanci. On ima potpunu kontrolu nad serverom: sa može da kreira, mjenja i briše logins-e i baze, mijenja sistemsku konfiguraciju, spušta instancu i dodjeljuje drugim korisnicima DBA privilegije.

Osim sa naloga, svaka baza podataka će takođe 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, može 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 korisnička 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 takođe ima unaprijed predefinisano nekoliko fiksnih serverskih rola. Ove fiksne role su poput Windows groupa - mogu da sadrže jedan ili više login-a. Svaka rola ima unaprijed definisani set privilegija. Svi članovi role (korisnici, logins koje kasnije dodjeljujemo ovim rolama) na taj način imaju isti nivo prava nad serverom.Serverska rola sa najvećim nivoom privilegija je sysadmin koja ima isti nivo privilegija kao i dba nalog. Kod SQL Server-a rola ne može da sadrži 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 važe 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 srećemo pojam role. Za Oracle, najviši nivo privilegije se dodjeljuje dba roli. Oracle ima poseban tip privilegija sysdba i sysoper. Kod Oraclea korisnik kojem budu dodjeljene sysdba ili sysoper privilegije može izvršavati administrativne operacije (kao što su spuštanje i podizanje baze podataka npr). Oracle dozvoljava da se rolama dodjeljuju (prenose) prava iz drugih rola – rola može da sadrži rolu. Na ovaj način se može formirati čitava hijerarhija rola.

Kao što je rečeno ranije, SQL Server login može biti ili trusted (Windows nalog) ili non-trusted. To znači da SQL Server korisnik može biti provjeravan preko 2 tipa autentifikacije: trusted ili non-trusted. Kada se koristi trusted ili Windows autentifikacija, SQL Server će se ponašati 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 neće od tog korisnika tražiti 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 unešene podatke za username/password sa svojim vlastitim podacima u svojoj internoj listi korisnika.

Kod Oracle-a, korisnik može biti autentifikovan na 3 različita načina:

- Data Dictionary

6

- Password File - Operativni sistem (ovo je različito od SQL Server trusted connection methoda autentifikacije)

Među pobrojanim načinima, data dictionary metod je najčešći metod za autentifikaciju korisnika na Oracle bazu podataka. Ostala 2 metoda se koriste kada baza podataka nije raspoloživa ili kada se ne izvršava instanca baze podataka. Kada se obični korisnik pokušava 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 obične 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 može da radi a da pri tome baza podataka nije podignuta ili čak nije ni kreirana. DBA će biti jedini korisnik koji može kreirati ili otvoriti bazu podataka iz instance. Pošto u tom trenutku nije aktivan data dictionary za autentifikaciju, Oracle ima potrebu za nekim oblikom eksterne autentifikacije korisnika. Ovaj oblik eksterne autentifikacije može biti realizovan kroz password file ili kroz operativni sistem na kojem hostuje Oracle instanca.

Password file sadržii 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 može 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 može koristiti i autentifikaciju operativnog sistema. Sa validacijom na nivou operativnog sistema, Oracle provjerava da li korisnik koji pokušava 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 tipično dba grupa. Ukoliko je taj korisnik član privilegovane grupe, nije potrebno da se prijavljuje sa posebnim username i password.

Da bi pojasnili kako ovo funkcioniše, razmotrimo 2 primjera.

U komandi u nastavku, sys korisnik pokušava da se sa privilegijama sysdba poveže na bazu dbname koristeći password file authentication

CONNECT sys/password@DBNAME AS SYSDBA;

U komandi u narednom primjeru, korisnik se direktno povezuje sa servera na kojem hostuje Oracle. Pošto je taj korisnik već validovan na nivou operativnog sistema i njegov nalog je član grupe operativnog sistema koja 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 između 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 može na neki način pristupati (select, insert, update, delete, execute, modify).

Kod SQL servera je stvar drugačija. Šemu kreira neki korisnik (tipično admin) i definiše skup tabela, procedura, funkcija, view-ova i ostalih baznih objekata sa odredjenim skupom privilegija nad svakim od tih objekata. U narednoj iteraciji se definišu korisnici ili role koji pripadaju konkretnoj šemi. Sa ovakvog stanovišta je interesantno rješenje da se aplikativni moduli definišu na nivou šeme a onda da se korisnicima dodjele prava rada nad tako definisanom šemom.

7

Error Log vs Alert Log

SQL Server u svom fajl sistemu održava jedan fajl - tekući log za snimanje informacija o uspješnosti izvršenja određenog skupa operacija nad bazom podataka. Ovaj log uključuje informacije u vezi sa događajima koji su nastali prilikom pokretanja baze podataka, prilikom izvršenja recovery-a, zatim događaje koji su u vezi sa korisničkim aktivnostima, izvršenjem backup-a, aktivnostima koje uzrokuju promjenu konfiguracije baze podataka, događaje koji se odnose na nekorektno prijavljivanje na bazu podataka, razne vrste grešaka 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, sljedeći kandidat za upis novih podataka o radu sistema postaje u tom trenutku najstariji error log file. Ovo “po defaultu” ponašanje se može promjeniti. SQL Server se može konfigurisati da čuva unaprijed definisani broj fajlova za error logove. Tekući error log nosi ime ERRORLOG (bez ikakve druge dodatne ekstenzije) dok se error log koji je stariji od tekućeg 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 sadrži informacije o podizanju i spuštanju baze podataka, oporavku instance, izmjenama konfiguracije, internim greškama u bazi podataka, vrijednostima inicijalnih parametara itd.

Za razliku od SQL Server error loga, Oracle alert log ne vrši kreiranje novog file-a svaki put kada se uradi restart instance. U stvari, Oracle održava samo jedan Alert Log file koji može rasti neograničeno 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.

8

I SQL Server error log i Oracle alert log su obični ASCII tekst fajlovi koji se mogu otvoriti u bilo kojem tekst editoru. SQL Server Management Studio obezbjeđuje pregled error log-ova kroz Windows interfejs. Oracle-ov Enterprise Manager Database Control obezbejđuje pregled alert logova, takođe 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 najčešća definicija je bdump folder ispod $ORACLE_HOME direktorijuma.

Start-up i Configuration parametri

Kada se SQL Server instalira, takođe se kreira i odredjeni broj Windows registry ključeva. Ovi registry ključevi specificiraju različite vrijednosti za razne parametre koji su potrebni SQL Serveru za njegov rad. Npr. jedan od registry ključeva definiše lokaciju za error log file, drugi registry ključ bi trebao da sadrži lokaciju za default backup folder itd. SQL Server koristi vrijednosti ovih registry ključeva za svoje operacije. SQLSERVR.EXE može da ima, pored ovih ključeva i određeni broj inicijalnih parametara koji su povezani sa exe komandom, uključujući i trace flags. Ovi, tzv add-on parametri bi trebali da kontrolišu na koji način bi trebala instanca da se ponaša kada se pokrene. Pored inicijalnih parametara i vrijednosti u registry ključevima, SQL Server ima i veliki broj internih konfiguracionih parametara koji se koriste za fino podešavanje instance. Primjer jednog od takvih parametara je “max server memory” kojim se specificira maksimalna veličina memorije koja se može odvojiti za instancu. Server konfiguracioni parametri se smještaju u sistemske meta-tabele kojima se kasnije preko odgovarajućih SELECT upita može pristupiti (naravno, ukoliko je konkretnom korisniku dozvoljeno da pristupi tim tabelama)

Izmjena SQL Server konfiguracionih parametara se može uraditi na nekoliko načina:

Korišćenjem sp_configure sistemske bazne procedure

Korišćenjem “server properties” dijalog box-a iz Management Studio ili Enterprise Manager-a

Koristeći različite 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 sadrži parametrizovane vrijednosti koji diktiraju na koji način će biti kreirana instanca. Da podsjetimo, Oracle instance je sačinjena od memorijskih struktura i pozadinskih procesa. Pored ostalih stvari, parametar fajl sadrži vrijednosti koje kazuju Oracle-u koliko mnogo memorije da odvoji za instancu, koliko mnogo korisničkih procesa se može povezati na instancu konkurentno, koje baze podataka su povezane sa konkretnom instancom. Kako Oracle čita ovaj file tako formira elemente memorije na osnovu njegovog sadržaja.

9

Parametar fajl može biti ili obični ASCII tekst fajl ili binarni fajl. Statički parametar fajl se zove pfile i ima ime na operativnom sistemu u obliku init<SID>.ora gdje je SID -System Identifierinstance. Binarni parametar fajl, ili spfile, imenuje se po šablonu spfile<SID>.ora. Jedna značajna razlika između tekst-orjentisanog pfile i binarnog spfile je ta da kada se koristi pfile, Oracle čita njega samo jednom – prilikom podizanje instance. Bilo kakva buduća promjena u parametar fajlu će biti implementirana na bazi podataka tek poslije njenog restarta. Kod spfile-a, Oracle može promjeniti sadržaj i definiciju baze čak i kada instancaradi. Oracle 11g verzija baze podataka, npr ima više od 250 inicijalizacionih parametara koji se mogu individualno setovati. Srećom, 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 definišu u fazi instalacije RDBMS-a. Promjena inicijalizacionih parametara se može izvršiti ili ručno ili iz Oracle- ovog alata Enterprise Manager Database Control. U manuelnom režimu rada, koristeći komandu ALTER SYSTEM smo u mogućnosti da izmjenimo sadržaj spfile. Ukoliko koristimo pfile, DBA može izvršiti izmjenu sadržaja fajla koristeći bilo koji text editor.

Control file je drugi fajl koji Oracle čita pošto je izvršio startovanje instance. I lokacija control file je specificirana kao jedan od parametara u parametar fajlu. Control file je mali binarni fajl koji sadrži kritične informacije za funkcionisanje baze podataka, uključujući 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 moguće startovati bazu podataka ukoliko ne postoji korektan control file. Zbog ovako značajne uloge koju control file ima u Oracle arhitekturi, preporučuje 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 slučaj sa spfile-om, Oracle konstantno vrši ažuriranje sadržaja i control fajla dok je baza podataka otvorena. Ukoliko postoje višestruke kopije control fajlova, svaki od control fajlova se ažuriraju u isto vreijeme sa istim informacijama.

Na kraju, poseban tip fajlova koji se takođe koristi od strane Oracle-a je i password file. Ovaj fajl sadrži parove usernames / passwords za one korisničke naloge kojima je dodjeljena privilegija da podižu i spuštaju bazu podataka.

10

Transactional Consistency i Point-in-time Recovery

Microsoft SQL Server i Oracle imaju ugradjen mehanizam za zaštitu korisničkih transakcija. Ideja koja se nalazi iza “transactional consistency” je da se promjene koje se izvrše 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 periodično 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 izvršene nad podacima u bazi podataka. Sadržaj ovog buffera se upisuje u odvojeni – nezavisni fajl baze podataka na disku. Pošto imamo dva nezavisna bafera sa podacima (buffer keš i log buffer keš) postoje i 2 odvojena pozadinska procesa koji upisuju sadržaje ovih bufera u fizičke fajlove na disku. Log buffer keš se mnogo češće upisuje na disk nego buffer keš. To je zato što je operacija koja izvršava prenos log buffera mnogo brža – log file je obični sekvencijalni fajl kod koga se na njegov kraj dodaju novi slogovi sa podacima o promjenama na tabelama u redosljedu u kojem su se promjene dešavale (uočiti da je prepis iz buffer keša u fajl sa stvarnim podacima mnogo sporiji jer se za taj prepis uvjek mora prvo naći tačna pozicija u fajlu, tačna tabela i slog na koji se upisivanje odnosi i zbog toga se ovaj upis mnogo ređe izvršava)

Ukoliko korisnik uspješno komituje transakciju, promjene će postojati u buffer cache-u ali promjene iz buffer cache-a neće biti odmah upisane u data fajlove na diskovima. Promjene će se snimiti i u sekvencijalni log buffer. Sadržaj log buffer-a će biti prenešen na log file na disku prije nego što korisnik dobije signal od RDBMS-a da je uspješno 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 sadrži 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 identične: ukoliko server “neočekivano padne”, database server će pretražiti sadržaj log fajla poslije restarta baze podataka. Ukoliko server u log fajlu pronadje komitovane transakcije koje nisu prenešene u fajl sa podacima, on će izvršiti izmjene na podacima u data fajlu na disku tako da će se izmjene jednom učinjene 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 održava po jedan transaction log za svaku od svojih baza na hostu. Database transaction log može imati jedan ili više 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 fizičke data fajlove i logičke tablespace-ove kojima on upravlja. Oracle-ovi redo logovi se kreiraju kao set fajlova koji prihvataju promjene koje se načine u svim tablespace-ovima. Svaka Oracle baza podataka mora da ima najmanje 2 redo log file-a za svoje operacije. Može postojati više od 2 redo log file-a, ali su 2 minimum.

Jedna očigledna razlika izmedju SQL Server transaction logova i Oracle redo logova je da SQL Server transaction log fajlovi nisu grupisani ninakoji logičan način. Redo log fajlovi kod Oracle-a su dodjeljeni dvema ili većem broju redo log grupa. Svaka Oracle baza podataka mora imati najmanje 2 redo log grupe a svaka grupa mora imati jedan ili više 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 upiše u redo log grupu, svaki member fajl groupe se update-uje u isto vrijeme. Postojanje više od jednog fajla u redo log fajl grupi obezbjedjuje zaštitu od eventualnog oštećenja 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 sljedeću grupu i tako redom. Ako je baza u NoArchiveLog modu, kada se napune sve redo grupe (bez obzira da li ih ima 2 ili više), Oracle će isprazniti prvu redo log grupu u lancu i početi 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, korisnička(e) transakcija(e) će biti zaustavljene dok se redolog buffer ne isprazni. Pražnjenje podataka iz Redo log buffer-a se najčešće vrši automatski (mada se može insistirati i na ručnom prenosu). Konfiguracionim parametrima na nivou baze se može promjeniti način izvršenja ove operacije.

11

SQL Server transakcioni log baze podataka se takodje puni u sekvenciajlnom redu. Log se ne briše automatski osim ako baza podataka ne radi u tzv simple recovery modu ili ukoliko se ne uradi backup transaction loga. Ukoliko logički transaction log za bazu podataka postane pun i ukoliko se log fajl za koji je logički transakcioni log vezan toliko velik da se više ne može povećavati, baza podataka postaje neraspoloživa za bilo kakvu korisničku aktivnost. Ako se izvrši backup transakcijskih logova, SQL Server će dozvoliti da se preko backup-ovanih ulaza u log fajl uradi novi upis novih transakcija.

Sljedeći detalj koji treba da primjetimo jeste da se SQL Serverov transaction log fajl može konfigurisati na način da se povećava automatski kada postoji potreba za većim prostorom u njemu. Oracleov redo log fajl se kreira sa predefinisanom veličinom i ona se ne povećava automatski osim ako se ta veličina kasnije ručno ne promjeni..

Sa stanovišta raspoloživosti podataka, obadvije platforme omogućuju point-in-time recovery. Ukoliko se želi, ova osobina može biti isključena. Kada je SQL Server baza podataka konfigurisana da radi u point-in-time recovery modu, kaže 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 može biti i u simple recovery mode u kom slučaju slogovi u transaction logu ostaju dok se ne izvrši checkpoint. Checkpoint snima modifikovane podatke iz buffer keša i log keša 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 brišu poslije izvršenog 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 greška (fizička ili logička) 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 omogućava da vratimo stanje baze podataka u bilo koji momenat vremena u prošlosti. Treba imati u vidu da ova funkcionalnost radi samo ako je baza podataka u full recovery mode.

Oracle ima sličan koncept. Oracle baza podataka može biti u ARCHIVELOG ili NOARCHIVELOG modu. Kada radi u NOARCHIVELOG modu, sadržaj prve redo log grupe se ponovo koristi za upis čim se poslednja log grupa u lancu napuni. Pošto se sadržaj redo log grupa ne arhivira u ovom režimu rada, sistem se neće moći vratiti na stanje u nekoj vremenskoj tački u prošlosti 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 više archive procesa će raditi u pozadini. Arhiv procesi vrše backup sadržaja redo log grupa kada one postanu pune i pohranjuju ih u odvojene fajlove na disk podsistemu. Ove sačuvane kopije redo log grupa su poznate pod imenom archived log. Jednom kada se log grupa arhivira, može se ponovo koristiti za upis podataka. Ako pokušamo naći paralelu, arhiving

12

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 pošto 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 – ručno kao scheduled job, dok kod Oracle-a archiver proces automatski vodi računa o backup-u kada se baza podataka jednom konfiguriše za tu namjenu.

Konačno, ekvivalencija izmedju ovih platformi može biti uočena takodje i u terminologiji recovery time. Kao što je napomenuto ranije, kada se startuje DB engine, cjeli proces će ići kroz redo i undo fazu. Ukupno vrijeme provedeno u uvim dvijema fazama je poznato kao recovery interval. Očigledno je da će DBA želiti da recovery interval bude što je moguće manji. Kod SQL Servera, DBA može konfigurisati ovaj interval izvršavajući 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 premašuje ovaj interval. Recovery interval se specificira u minutama.

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

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

13

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 sadrže meta podatke o logičkim i fizičkim 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, većina objekata sistemskog nivoa je smješteno 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 određeni 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 onemogućen direktan pristup ili modifikovanje njihovog sadržaja 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 vrše upite nad ovim skupom podataka. U Oracle terminologiji ovi view-ovi se nazivaju data dictionary views.

Definicije kataloških view-ova se čuvaju u SQL Server resource bazi podataka. Ovi sistemski view-ovi pripadaju posebnoj šemi koja se naziva sys schema i može im se pristupiti iz svake baze podataka. Npr. da bi izlistali sve baze podataka koje imamo na SQL Server instanci, DBA može izvršiti 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 može koristiti bez ograničenja:

SELECT * FROM sys.objects

Kod Oracle-a, data dictionary je u vlasništvu SYS korisnika. Za razliku od SQL Server-a, svaki data dictionary view može postojati u tri različita oblika i svaki od ovih oblika će davati različit skup informacija. Dictionary view-ovi su zbog toga podjeljeni u tri različita 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. Obični korisnik nema prava pristupa DBA_ view-ovima.

Npr, dva upita koja su ispisana u nastavku daju kao rezultat različite 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.

14

Dynamic Views

Pored data dictionary view-ova, Oracle posjeduje i odredjeni skup view-ova koji se nazivaju Dynamic Performance Views koji omogućavaju uvid u stanje memorijskih struktura instance i u sadržaj 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 vraćaju 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 može pristupiti data dictionary view-ovima samo kada je baza podataka otvorena za normalno korištenje. Dynamic performance view-ovima se može pristupiti čim se instanca pokrene, dakle i prije nego što se pokrenu baze podataka. Nekim od dynamic performance view-ova se može pristupiti samo ako je baza podataka u statusu “mounted”.

Ovi view-ovi se često nazivaju V$ views zato što im ime počinje 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

Sljedeći upit će prikazati informacije koje se odnose na stanje tekuće sesije:

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

Kod SQL Server 2005, Dynamic Management Views ili DMV obezbjeđuju veliki broj informacija o stanju memorije instance. Kao i kod Oracle-a dynamic performance views, DMV za svoj rad u pozadini nemaju konkretne fizičke tabele. Ovi view-ovi se formiraju svaki put od početka kada se izvrši resetovanje servera ili instance. DMV-ovi pripadaju sys šemi i imaju ime koje počinje sa prefiksom “dm_”. U primjeru koji je dat u nastavku dobijamo podatke o tekućim sesijama na SQL Server instanci:

SELECT * FROM sys.dm_exec_requests