Pohranjene procedure Pohranjena je procedura (engl. Stored Procedure) upit koji se čuva u bazi na serveru i nije ugrađena u kod koji se instalira na klijentskom računalu.Zbog čega je dobro čuvati upite u bazi na serveru?

*smanjeni promet mrežom - mala količina koda, otklanjanje uskih grla*puno brže izvođenje - nije potrebno prevođenje, u memoriji postoji plan izvršavanja *jednostavnije upravljanje bazom podataka - centralizacija upita, potrebno je mijenjati upite samo na serveru, a ne na svim klijentima

Prednosti korištenja pohranjenih procedura u odnosu na programe pohranjene lokalno na klijentu:*Dopuštaju modularno programiranje;*Brže se izvršavaju;*Mogu značajno smanjiti promet na mreži;*Mogu se koristiti kao zaštitni mehanizam.

Upotreba pohranjenih proceduraDva načina programiranja:*Programi pohranjeni lokalno i aplikacije koje šalju naredbe SQL serveru i same obrađuju rezultate;*Programi pohranjeni na SQL serveru kao pohranjene procedure i aplikacije koje izvršavaju procedure i same obrađuju često puno manje rezultata

Rad s procedurama Pohranjena se procedura sastoji od dva primarna dijela: specifikacije imena procedure i njenih parametara, te tijela procedure.

Kursori Operacije se u relacijskoj bazi podataka odvijaju nad n torkama.‐ Grupa n torki koja je rezultat SELECT naredbe sastoji se od ‐svih n torki koje zadovoljavaju uvjet u WHERE dijelu naredbe.‐ Aplikacije, posebice one interaktivne, ne mogu uvijek efikasno raditi s cijelom grupom n torki kao jednom jedinicom.‐ Takvim je aplikacijama potreban mehanizam kojim bi mogli odjednom raditi s jednom n torkom ili manjim brojem n torki.‐ ‐ Kursori su dodatak koji to omogućuje.Kursori omogućuju

*Pozicioniranje na željenu n torku;‐*Dohvaćanje jedne ili više n torki iz trenutne pozicije djelatnog skupa;‐*Promjenu podataka nad n torkama koje su na trenutnoj poziciji;‐*Izvedbu procedura i okidača koji rade nad pojedinim n torkama.‐

Rad s kursorom Generalno se može reći kako se rad s kursorom sastoji od:*Povezivanja kursora s djelatnom n torkom i definiranja njegovih karakteristika (kao npr npr. mogu li se n torke u ‐ ‐ kursoru ažurirati);*Izvršavanja naredbe kako bi se popunio kursor;*Dohvaćanja n torki iz kursora koje se žele vidjeti. Taj postupak nazivamo dohvat (fetch). Izvršavanje niza dohvata ‐ bilo unaprijed ili unazad naziva se scrolling.*Opcionalno, može se izvršiti operacija ažuriranja ili brisanja n torke na trenutnoj poziciji kursora‐

Deklariranje kursora i povezivanje s djelatnim skupomINSENSITIVE – ažuriranja nad temeljnim n torkama (u originalnim tablicama) koje grade kursor nisu vidljive u kursoru, ‐

također, nije moguće ažuriranje pomoću kursoraSCROLL – moguće su sve opcije dohvata n torki (FIRST, LAST, PRIOR, NEXT,RELATIVE, ABSOLUTE), ako opcija nije navedena ‐

moguće je samo NEXTAko je navedeno OF column_name [,...n], moguće je ažurirati samo navedene atribute. Ako je UPDATE naveden bez liste atributa moguće je ažurirati sve atribute.Otvaranje kursora i dohvat n torke‐Kursor se nakon deklariranja mora otvoriti. Naredba OPEN ime_kursora otvara kursor i popunjava ga podacima definiranim u select_naredbi DECLARE bloka. Ako je kursor deklariran s INSENSITIVE opcijom naredba OPEN rezultira stvaranjem privremene tablice. Uz pomoć FETCH naredbe dohvaćamo podatke iz kursora.Kursor za ažuriranje Kako ažurirati ili obrisati točno određenu n torku na kojoj se nalazi kursor? Kada se uz pomoć kursora želi vršiti ažuriranje ili ‐brisanje potrebno je definirati WHERE CURRENT OF ime_kursora u WHERE dijelu UPDATE ILI DELETE naredbe.Zatvaranje i dealociranje kursoraNaredbom CLOSE ime ime_kursora zatvaramo kursor i otpuštamo djelatni skup. Svaki otvoreni kursor je nužno zatvoriti. Nije dozvoljeno zatvoriti kursor koji nije trenutno otvoren. Naredbom DEALLOCATE ime_kursora brišemo vezu između kursora i njegova imena. Također, brišu se i scroll locks.

Okidači (Triggers)Okidači su posebna vrsta pohranjenih procedura definiranih da se izvršavaju automatski kada se nad tablicom ili pogledom izvrši UPDATE, INSERT ili DELETE naredba. Aktivirajući događaji: UPDATE, INSERT, DELETEOkidači se koriste:

*Implementaciju specifičnih pravila “Buisiness rules”, *OČUVANJE integriteta

OKIDAČI se izvodne nakon što se izvrši POKRETAČKI DOGAĐAJ. Ako pokretački događaj završi greškom okidač se NE IZVRŠAVA. OKIDAČI mogu izvršavati upite nad drugim tablicama. OKIDAČI i POKRETAČKI DOGAĐAJI tretiraju se kao JEDNA TRANSAKCIJA. Moguće je opozvati transakciju iz okidača. Ako server detektira pogrešku (npr. Nedovoljno mjesta na disku) CIJELA SE TRANSAKCIJA AUTOMATSKI OPOZIVA. Dozvoljeno je ugnježđivanje okidača. Ako jedan okidač mijenja tablicu koja ima svoje okidače dolazi do ugnježđivanja okidača u trenutku kada se aktivira taj drugi okidač. Ako dođe do beskonačne petlje ugnježđivanja okidača, okidači se terminiraju kada se dosegne već predefinirani broj ugnježđivanja. Ako dođe do neobrađene iznimke unutar ugnježđivanja, cijela operacija promatra se kao TRANSAKCIJA, pa se opozivaju sve učinjene izmjene. Nikada ne dolazi do rekurzivnog pozivanja OKIDAČA * Za INSERT i UPDATE stvara se privremena tablica INSERTED. U njoj se nalazi izmijenjena ili unesena n-torke. To je kopija n-torke koja je unesena u originalnu tablicu.* Za trigere koji se aktiviraju na operaciju DELETE stvara se tablica DELETED koja sadrži obrisane n- torke.AFTER Okidač se izvršava nakon što se izvrši okidajući događaj. Ako okidajući događaj prijavi završi s greškom (npr. narušavanje ograničenja ili sintaksna pogreška) okidač se ne izvršava. AFTER okidači mogu biti definirani samo za tablice (ne i za poglede). Moguće je definirati više AFTER okidača za svaki okidajući događaj (INSERT, UPDATE ili DELETE). Ako postoji više AFTER okidača moguće je pomoću sp_settriggerorder definirati koji se AFTER okidač pokreće prvi, a koji zadnji. Svi ostali AFTER okidači okidaju prema ne definiranom redoslijedu koji je nemoguće kontrolirati. AFTER je default u SQL Server 2000. INSTEAD OFOkidač se izvršava umjesto okidajućeg događaja. INSTEAD OF okidači mogu biti definirani i za tablice i za poglede. Moguće je definirati samo jedan INSTEAD OF okidač za svaki okidajući događaj (INSERT, UPDATE i DELETE). INSTEAD OF okidači mogu se koristiti za poboljšane provjere integriteta nad vrijednostima podatka koji su pribavljeni INSERT ili UPDATE naredbama. INSTEAD OF okidači omogućuju definiranje akcija kojima se pogledi koji inače ne podržavaju ažuriranje, mogu ažurirati.Ograničenja okidačaOkidač se stvara samo u trenutnoj bazi, ali može koristiti objekte izvan trenutne baze INSTEAD OF DELETE/UPDATE okidači se ne mogu definirati nad tablicom koja ima definiran strani ključ s akcijom cascade on DELETE/UPDATE U okidačima nisu dozvoljene ove operacije: ALTER DATABASE, CREATE DATABASE, DISK INIT, DISK RESIZE, DROP DATABASE, LOAD DATABASE, LOAD LOG, RECONFIGURE, RESTORE DATABASE, RESTORE LOG

Transakcije Savjeti za upotrebu: TRANSAKCIJE TROSE HRPU RESURSA!!! Unutar transakcije se ne smije čekati intervencija korisnika podaci bi mogli biti predugo zaključani za upotrebu. Ne započinjati transakcije zbog jednog SQL upita. Unutar jedne transakcije mijenjati što manju količinu podataka. Transakciju započinjati tek kada je korisnik spreman ažurirati podatke, a ne dok ih pretražuje. Transakcije trebaju biti što kraćeSvojstva transakcija Transakcije imaju 4 svojstva (ACID):

Atomicity (Atomarnost) transakcija je jedinstvena jedinica posla (atom)‐ nakon što transakcija završi ili su ‐obavljene sve operacije ili niti jedna

Consistency (Konzistentnost) transakcija bazu mora ostaviti j u konzistentno stanju ako neka operacija ‐ ‐naruši neka od pravila ili ograničenja u bazi, transakcija se ne može potvrditi

Durability (Trajnost) transakcija kada se jednom potvrdi mora ostati trajno u bazi ako se računalo pokvari, ‐ ‐rezultati potvrđene transakcije su vidljivi kada se računalo ponovo pokrene

Isolation (Izolacija) jedna transakcija ne vidi prijelazno stanje drugih transakcija ako se na nepromijenjenim‐ ‐ podacima izvedu sve transakcije jednakim redoslijedom efekt uvijek mora biti jednak

COMMIT TRANSACTION: COMMIT TRANS[ACTION] [ime_transakcije | @varijabla_za_ime]Potvrđivanje transakcije. Sve izmjene unutar transakcije se upisuju u bazu. COMMIT se odnosi na posljednju započetu transakciju u bloku. Ime transakcije služi samo za olakšano čitanje koda i nema ulogu za potvrđivanje transakcije. ROLLBACK TRANSACTION: ROLLBACK TRANS[ACTION] [ime_transakcije | @varijabla_za_ime_transakcije | ime_potvrđene_točke | @varijabla_za_ime_potvrđene_točke]Poništavanje transakcije. Sve izmjene unutar transakcije nemaju učinka – kao da se transakcija nije niti dogodila. ROLLBACK se odnosi na posljednju započetu transakciju u bloku, na posljednji BEGIN TRANSACTION. Potvrđena točka služi ako se želi poništiti samo dio transakcijeSAVE TRANSACTION: SAVE TRANS[ACTION] {ime_potvrđene_točke | @varijabla_za_ime_potvrđene_točke}omogućuje potvrđivanje dijela transakcije pa je moguće i poništiti dio transakcije. Ime potvrđene točke je nužno i služi kao ‐referenca za naredni COMMIT ili ROLLBACK TRANSACTION. Korisnik može postaviti potvrđenu točku (savepoint) ili marker unutar transakcije. Potvrđena točka definira mjesto na koje se transakcija može vratiti ako je transakcija uvjetno prekinuta. Ako je transakcija vraćena (rolled back) na potvrđenu točku mora se završiti do kraja njeno izvođenje, tj. mora se dogoditi COMMIT TRANSACTION naredba ili se mora cijela transakcija opozvati sa ROLLBACK TRANSACTIONKorištenje transakcija Transakcije se mogu ugnježđivati

‐ BEGIN TRANSACTION se može zadati prije nego se prethodna transakcija potvrdi ili poništi Unutrašnja se transakcija mora potvrditi ili poništiti prije vanjske‐ ‐ ROLLBACK unutrašnje transakcije poništava samo unutrašnju transakciju ‐ COMMIT unutrašnje transakcije potvrđuje samo unutrašnju transakciju Ako vanjska transakcija napravi ‐ ROLLBACK sve izmjene u unutrašnjim transakcijama se poništavaju

Korisne sistemske funkcije

@@TRANCOUNT - broj ugniježđenih transakcija koje su trenutno započete. ako nema započetih transakcija iznos je 0@@ERROR - vraća 0 ako prethodni iskaz nije prouzrokovao grešku u suprotnom ima vrijednost rednog broja posljednje greške

Problemi paralelnog pristupaIzgubljeni ili uništeni podaci. Javlja se kad 2 ili više transakcija u isto vrijeme ažuriraju istu n-torku, ali na osnovi originalne n-torke → zadnje ažuriranje ostaje trajno. Zadnje ažurirana n-torka se samo pojavljuje kao nova n-torka dok se ostale promjene gubeOčekivani problemi višekorisničkog rada na bazi: “nekonzistentni podaci” (nonrepeatable read) Jedna transakcija mijenja n-torku. Druga transakcija čita tu n-torku.

Druga transakcija svaki put pročita drugačije podatke. S obzirom da se radi o transakciji nužno je osigurati RJESENJE: konzistentnost podataka za kratko vrijeme izvršavanja transakcije

“prljavo čitanje” (dirty read) Jedna transakcija mijenja podatke. Druga čita te iste podatke. Kod prve transakcija je npr. došlo do pogreške kod upisa te prva transakcija još nije poslala trenutne izmijene, a druga transakcija je pročitala podatke koji uopće neće biti rezultat prve transakcije. RJESENJE: dok jedna transakcija mijenja podatke, druge transakcije ne smiju čitati te podatke sve dok ta transakcija ne potvrdi promjenu

“fantomske n-torke ” (phantom reads) Pojavljuju se kada neka transakcija upisuje ili briše n-torke dok ih druga transakcija za to vrijeme čita. Transakcija koja čita podatke pročita i one n-torke koje npr. prva transakcija upravo briše. Ako u trenutku pregleda tablice jedne transakcije, druga transakcija unosi podatke, prva će “vidjeti” n-torke koje još ne postoje u bazi podatakaRJESENJE: niti jedna transakcija ne smije unositi nove podatke u bazu dok ostale transakcije nisu završile raditi s originlnom bazom podataka

Vrste zastojaNepotpuni zastoj transakcija 2 može čekati zauvijek, iako je imala priliku zaključati podatak A

RJEŠENJE: “first come first served”Potpuni zastoj svaki proces čeka od drugog da ovaj otpusti ključ. Oba procesa ne mogu ništa raditi, ne može se napraviti nitirollback niti završiti transakciju. ako se dogodi: javlja se greška 1205; barem jedna transakcija se mora prekinuti; poništavaju se svi njeni efekti.

Transakcija 1 Transakcija 1zaključaj A zaključaj Bzaključaj B zaključaj A

RJESENJE: transakcija zatraži odjednom sve ključeve – zaključa sve ili ništa. zahtjeva se da transakcije zaključavaju podatke u nekom određenom poretku

Rješavanje problema paralelnog pristupaPostoji automatsko zaključavanje, a samim time i rješavanje problema, ali korisnik može sam definirati kakvo će se zaključavanje postaviti u bazi: postavljanjem određene granulacije

Određuje se veličina objekta koji će biti zaključan baza podataka – DATABASE - kada se treba zaključati veliki broj n-torki u vrlo velikom broju relacija tablica –TABLE- zaključava se cijela tablica, uključujući sve podatke i sve indekse redak – RID - row ID - ako se zaključava ograničen broj n-torki (redaka) memorijska stranica – PAGE- ako se zaključava ograničen broj n-torki za koje se može pretpostaviti da su

smještene na fizički bliskim pozicijama. veličina: 8KB stranica s podacima ili indeksima EXTENT- grupa od 8 memorijskih stranica indeks – KEY npr. za čuvanje “mjesta” za ključ čiji je zapis obrisan; u slučaju poništavanja transakcije koristi se

implicitno od strane SUBP postavljanjem određene vrste zaključavanja

1. ključ za čitanje – SHARED (S) LOCK transakcija T zaključa objekt za čitanje bilo koja druga transakcija ga također može zaključati zaČitanje. niti jedna druga transakcija ga ne može zaključati za pisanje. odmah nakon što je podatak koji je zaključan za čitanje pročitan, ključ za čitanje se otpušta. trajnost ključa ovisi o primijenjenom nivou izolacije → na zaključavanje za čitanje utječe nivo izolacije

2. ključ za pisanje/izmjenu – EXCLUSIVE (X) LOCK transakcija T zaključa objekt za pisanje. niti jedna druga transakcija ga ne može zaključati dok ga T ne otključa. svaka operacija izmjene postavlja ključ za pisanje!!! postavlja se neovisno o postavljenom nivou izolacijei uklanja

Transakcija 1 Transakcija 2 Transakcija 3zaključaj A … …

… zaključaj A …otkljucaj A zaključaj A

…

se tek po završetku transakcije da ne bi došlo do postavljanja prevelikog broja ključeva za pisanje/izmjenu ne treba koristiti prefinu granulaciju zaključavanja. treba koristiti što kraće transakcije da bi se spriječilo nepotrebno ograničavanje konkurentnosti. naredbe: UPDATE, INSERT, DELETE

3. unapredivi ključ – UPDATE (U) LOCK ažuriranje pročitane n-torke postavlja ovaj ključ. izražava namjeru izmjene na početku se postavlja ključ za čitanje bilo koja druga transakcija može postaviti ključ za čitanje niti jedna druga transakcija ne može postaviti ključ za pisanje. prije izmjene ključ se unaprjeđuje u ključ za pisanje omogućuje SUBP-u da predviđa buduće akcije ovisi o nivou izolacije; postavlja se čak i kad je nivo izolacije UNCOMMITTED

postavljanjem izolacijskog nivoa Određuje način pristupa podacima u višekorisničkom okruženju. I zolira pojedine transakcije jedne od drugih. Niži nivo izolacije povećava konkurentnost i smanjuje “ispravnost” podataka. povišenjem nivoa izolacije osigurava se “ispravnost” podataka smanjuje se mogućnost štetne interferencije paralelno izvođenih programa i smanjuje se konkurentnost

SET TRANSACTION ISOLATION LEVEL { READ COMMITTED | READ UNCOMMITTED | REPEATABLE READ | SERIALIZABLE } 1. prljavo čitanje – READ UNCOMMITTED najniži nivo izolacije. moguće pročitati “prljave” ili nepotvrđene n-torke.

osigurava samo da se ne mogu čitati fizički oštećeni podaci. čitaju se svi traženi podaci bez zaključavanja i bez provjere da li su možda zaključani → pojava sablasnih ntorki. operacije ažuriranja zaključavaju podatke prilikom izmjena. KORISTI SE: u slučajevima: kad se pristupa “statičkim” podacima, kad samo jedan program koristi bazu podataka, kad se ne zahtijeva apsolutna preciznost podataka.

2. čitanje potvrđenih n-torki – COMMITTED READ SQL Server default nivo izolacije. ne čita “prljave” n-torke. mogu se javiti fantomske n-torke ili nekonzistentni podaci. proces koji čita provjerava da li je trenutno traženi podatak zaključan za pisanje → n-torka se neće moći pročitati. podaci se ne zaključavaju. ne utječe na izmjene jer se svaki podatak zaključava prilikom izmjena. podatak koji je pročitan već u sljedećem trenutku može biti izmijenjen ili obrisan. KORISTI SE: samo ukoliko se n-torke koje se čitaju koriste kao nezavisne jedinice, tj. pročitana vrijednost se neće koristiti kao referentna u daljnjim operacijama

3. mogućnost ponovnog čitanja – REPEATABLE READ mogu se javiti fantomske n-torke. dohvat n-torke iz djelatnog skupa uzrokuje zaključavanje za čitanje ogovarajuće n-torke u bazi podataka dohvatom nove n-torke prethodna se oključava. ako je kod izmjene podataka (UPDATE CURSOR) na trenutnu n-torku postavljen unapredivi ključ, zapisi/stranice na kojima je došlo do izmjena ostaju zaključane do kraja transakcije. ako se pri dohvatu ne koristi transakcija ključ se otpušta odmah nakon što je n-torka pročitana. KORISTI SE: ako je potrebno osigurati da dohvaćena vrijednost ne bude promijenjena za vrijeme “obrade” dohvaćene n-torke. u slučajevima kada se dohvaćena n-torka koristi kao referentna vrijednost u daljnjim operacijama s podacima

4. SERIALIZABLE (ISOLATED) najviši nivo izolacije. transakcije su potpuno izolirane jedna od druge. dohvat n-torke iz djelatnog skupa uzrokuje zaključavanje za čitanje odgovarajuće n-torke u bazi podataka. dohvatom nove n-torke prethodna ostaje zaključana. kod ponovnog dohvata istog djelatnog skupa unutar iste transakcije. prethodno zaključane n-torke i dalje su zaključane → zapisi/stranice ostaju zaključane do kraja transakcije. KORISTI SE: ukoliko je potrebno osigurati da niti jedna n-torka ne bude promijenjena do završetka transakcije. u slučaju da se više dohvaćenih n-torki koristi kao referentna vrijednost u daljnjim operacijama s podacima

postavljanjem vremenski ograničenih zaključavanja Ako dođe do zastoja, SQL Server poništava jednu od blokiranih transakcija, i to onu kojoj vrijeme čekanja nije određenoSET LOCK_TIMEOUT max_vrijeme_čekanja - naredba kojom se definira koliko je maksimalno vrijeme koje jednatransakcija čeka na zaključani objekt. kada transakcija čeka duže od ovog maksimalnog vremena automatski seponištava i javlja se pogreška 1222 "Lock request time-out period exceeded", ako nije postavljeno, @@LOCK_TIMEOUT vraća -1 → čekaj zauvijek@@LOCK_TIMEOUT - funkcija koja vraća vrijeme čekanja na objekt koji je zaključan. vrijeme u milisekundama. na početku spajanja na bazu vraća -1

Zaštita od neovlaštenog pristupa bazama podatakaSigurnost pristupa bazama podataka- Korisnici moraju biti ovlašteni za izvršavanje određene akcije- Unaprijed moraju biti definirana pravila tj. Ovlasti pravila se pohranjuju u rječnik podataka. SUBP nadgleda i osigurava poštivanje pravilaDodjeljivanja ovlasti korisnicima

MANDATNI PRISTUP DODJELJIVANJA OVLASTI KORISNICIMA: svaki objekt ima oznaku razine ovlasti, svaki korisnik dobije oznaku razine ovlasti, objekt je dostupan samo onim korisnicima koji imaju odgovarajuću razinu ovlasti

DISKRECIJSKI PRISTUP DODJELJIVANJA OVLASTI KORISNICIMA: korisnik ima različita prava pristupa nad različitim objektima, različiti korisnici imaju različita prava nad istim objektima, najčešće se koristi

Pravo pristupa baziDBO (database owner – vlasnik baze ) može dati ili oduzeti nekom korisniku dozvolu nad bazom i objektima u bazi to je isključivo njegovo pravo. Nakon “dodavanja” novog korisnika DBO može definirati dozvole novog korisnika nad ovom bazomnaredbama:

GRANT – daje dozvole korisniku. GRANT je naredba kojom administrator (DBA - DataBase Administrator) ili vlasnik (DBO - DataBase Owner) ostalim korisnicima dozvoljava rad s objektima u određenoj bazi podataka izvršavanje određene Transact-SQL naredbe

REVOKE – uklanja korisniku prije dodijeljene dozvole. naredba REVOKE uklanja odbijenu dozvolu nekog korisnika i sada korisnik kroz grupu može naslijediti tu dozvolu

DENY – negira dodijeljene dozvole. Onemogućuje određenog korisnika da nasljeđivanjem kroz grupu ili ulogu dobije dozvolu. “poništava” GRANT naredbu. onemogućavanje dozvole kreiranja objekata

Pogled (view) Virtualne tablice (view – pogled) se formiraju kao posebna organizacijska jedinica u bazi podataka. nema svoje indekse. nema datoteke s podacima. pristupa im se kao i običnim tablicama

WITH CHECK OPTION dodatna ograničenja. provjerava da li se unosom ili ažuriranjem podataka u pogledu narušavaju ograničenja određena u WHERE dijelu definicije pogleda

DROP VIEW view_name - uklanjanje pogleda

Obnova baze podataka u slučaju razrušenjaMehanizmi obnove - Mehanizmi koji omogućavaju obnovu u slučaju razrušenja. Obnova je moguća ako : U sustavu postoji dovoljno redundantnih informacija koje nisu ugrožene arhivske kopije (backups)

baze podataka - arhivska kopija baze podataka sadrži duplikat podataka koji se nalaze u bazi u trenutku kada je napravljena. Izrada arhivske kopije baze podataka je operacija koja se automatski izvršava u zadanim intervalima. Moguće je obnoviti bazu u jednom koraku. postupak obnove prepisuje postojeću bazu ili je kreira ako ona ne postoji. obnovljena baza odgovara stanju baze u trenutku kada je napravljena arhivska kopija, ali bez nepotvrđenih transakcija. napravljen je ROLLBACK nepotvrđenih transakcija kada je baza obnovljena. Arhivska kopija baze podataka zauzima više prostora za pohranu od arhivskih kopija dnevnika transakcija ili diferencijalnih arhivskih kopija potrebno je više vremena kako bi se izradile tipično se kreiraju manje frekventno od diferencijalnih arhivskih kopija i kopija dnevnika transakcija

dnevnika transakcija - Arhivska kopija dnevnika transakcija omogućuje obnovu baze u točno određenom trenutku npr. prije unosa neželjenih podataka ili u trenutak pogreške

diferencijalne arhivske kopije – Diferencijalna arhivska kopija sadrži samo podatke koji su promijenjeni od zadnje potpune arhivske kopije. moguće je češće praviti diferencijalne kopije jer su manje i brže od potpunih arhivskih kopija naravno češće pravljenje arhivskih kopija smanjuje vjerojatnost gubitka podataka. Diferencijalnih arhivskih kopija koriste se kada se mali postotak podataka u bazi promijenjen od prošle arhivske kopije baze i kada se isti podaci često mijenjaju. Postupak obnove pomoću diferencijalne arhivske kopije izvod se na način: restaurira se zadnja potpuna arhivska kopija, restaurira se posljednja diferencijalna arhivska kopija ili primijeniti i sve arhivske kopije dnevnika transakcija nastale nakon diferencijalne kopije

rezervne kopije grupe datoteka dnevnici transakcija Baza podataka u Microsoft SQL Server ima najmanje jednu datoteku za podatke i jednu za dnevnik

transakcija. Podaci i dnevnik transakcija se nikada ne miješaju (nalaze se u različitim datotekama). Pojedine datoteke koristi samo jedna baza podataka. Nikada dnevnik transakcija ne smije biti na istom disku kao i podaci. SQL Server koristi dnevnik transakcija kako bi restaurirao transakcije. Dnevnik transakcija je slijedni zapis svih izmjena koje su izvedena u bazi zajedno s transakcijama koje su obavile te izmjene. U dnevnik transakcija upisuje se početak svake transakcije, izmjene nad podacima i dovoljno informacija kako bi ih se moglo poništiti efekt transakcija. Dnevnik transakcija neprestano raste sukladno izvršenju svake nove transakcije jer se u dnevnik bilježe sve operacije vezane za transakcije. Dnevnik transakcija bilježi i COMMIT ili ROLLBACK svake transakcije To omogućava SQL Serveru ili da ponovo obavi (roll forward) ili da poništi (roll back) svaku transakciju. Arhivska kopija dnevnika transakcija omogućuje obnovu baze u točno određenom trenutku npr. prije unosa neželjenih podataka ili u trenutak pogreške. Transakcija se ponovo obavlja ako se primijeni dnevnik transakcija. Na kraju ovog postupka baza je u jednakom stanju u kakvom je i bila kada je napravljena arhivska kopija dnevnika transakcija. Poništavanja se obavlja obrnutim redoslijedom od onog kojim su originalno operacije obavljene. Kontrolna točka SQL Servera predstavlja točku u kojoj postupak oporavka mora ponovno obaviti transakcije. kontrolna točka osigurava da se svi zapisi dnevnika transakcija i stranica (page) upisuju na disk. U slučaju razrušenja, tijekom postupka oporavka s obzirom da su sve promijene prije kontrolne točke sigurno na disku transakcija se smije ponovno obaviti samo ako nije poznato da li su se sve promijene upisale na disk

zrcaljenje (mirroring) - Zrcaljenje se koristi ne samo za zaštitu ako su veliki zahtjevi za dostupnošću originalni se podaci nalaze i na zrcalnom području. Svaka se promjena evidentira i u originalnom i u zrcalnom području. Ukoliko dođe do kvara na originalnom području rad se nastavlja na zrcalnom području počinje postupak popravljanja oštećenog područja. Zrcaljenje se može ostvariti upotrebom replikacije podataka (“mirroring” od strane DBMS-a). Korištenje RAID diskova (redundant array of independent disks ) zrcaljenje se vrši korištenjem sklopovlja

Jednostavni model obnoveUpotrebom jednostavnog modela obnove baza se može oporaviti do točke zadnje arhivske kopije. međutim nije moguće restaurirati bazu do trenutka razrušenja ili u određeni trenutak. Strategija arhiviranja za jednostavni model oporavka sastoji se od: arhivskih kopija baze (potpune) diferencijalnih arhivskih kopija (opcionalno). Za oporavak u slučaju oštećenja medija: restaurira se zadnja potpuna arhivska kopija baze, ako postoji diferencijalna arhivska kopija, restaurira se posljednja. Sve izmjene nakon zadnje arhivske kopije (potpune ili diferencijalne) su izgubljene

Potpuni model obnovePotpuni model oporavka koristi

arhivske kopije baze i arhivske kopije dnevnika transakcija

Potpuna zaštitu od kvara medija ako je jedna ili više datoteka s podacima oštećena, moguće je restaurirati sve potvrđene transakcije poništavaju se transakcije koje nisu uspješno završile izvođenje moguć je oporavak do trenutka kvara ili do određenog trenutka

Strategija arhiviranja za potpuni model obnove sastoji se od: arhivskih kopija baze (potpunih) diferencijalnih kopija (opcionalno) arhivskih kopija dnevnika transakcija

Za oporavak u slučaju oštećenja medija pravi se arhivska kopija trenutno aktivnog dnevnika transakcija restaurira se zadnja potpuna arhivska kopija baze podataka ako postoji diferencijalna arhivska kopija restaurira se posljednja restaurira se svaka arhivska kopija dnevnika transakcija nastala nakon potpune ili diferencijalne arhivske kopija u

jednakom redoslijedu kojim su stvarane primjenjuje se zadnja arhivska kopija dnevnika (napravljena na početku procedure) i oporavlja se baza