diplomsko delo univerzitetnega študija · na osnovi zahtev, ki jih je sektorju za informatiko...

Diplomsko delo univerzitetnega študija Organizacijska informatika

PREIZKUŠANJE ORACLOVEGA ORODJA DATA

GUARD ZA DOSEGANJE VISOKE

RAZPOLOŽLJIVOSTI IN VAROVANJE PODATKOV

Mentor: doc. dr. Borut Werber Kandidat: Marcel Milić

Somentorica: doc. dr. Alenka Brezavšček

Kranj, junij 2016

ZAHVALA Zahvaljujem se mentorju dr. Borutu Werberju in somentorici doc. dr. Alenki Brezavšček za pomoč pri zasnovi in izdelavi tega diplomskega dela. Zahvaljujem se še sodelavcem iz Agencije Republike Slovenije za javnopravne evidence in statistiko, ki so mi pomagali pri pripravi testnega okolja. Zahvala gre tudi moji ženi Idi in celotni družini, ki me je podpirala in spodbujala ves čas študija.

POVZETEK Diplomska naloga predstavlja teoretično in do neke mere tudi praktično podlago za urejanje rezervne računalniške lokacije na Agenciji Republike Slovenije za javnopravne evidence in storitve (AJPES). Glavni namen diplomske naloge je priprava vsega potrebnega za postavitev rezervne kopije podatkovne zbirke. S tem bomo zadostili dvema osnovnima zahtevama: neprekinjeno delovanje podatkovne zbirke in varovanje podatkov. Ker uporabljamo podatkovno zbirko Oracle®, bomo za to uporabili orodje Data Guard. Uporabili bomo še orodje RMAN, ki nam bo omogočilo kvalitetno izvedbo varnostne kopije in prvi prenos podatkovne zbirke na rezervno lokacijo. V prvem delu je predstavljen AJPES in njegova organiziranost ter razloženi ključni pojmi, ki se pojavljajo skozi celotno nalogo. V drugem delu smo pojasnili delovanje orodij Data Guard in RMAN. V nadaljevanju smo opisali postavitev okolja za podatkovno zbirko na rezervni lokaciji, povezava obeh zbirk (primarne in rezervne) ter zagotovitev ustreznega prenosa in varovanja podatkov. Opisan je tudi preklop med obema zbirkama, če pride do težav. Na koncu smo rezultate testa povzeli z analizo SWOT in navedli ključne dejavnike za to, da takšna lokacija zaživi tudi v praksi.

KLJUČNE BESEDE

- podatkovna zbirka Oracle - Data Guard - RMAN - neprekinjeno delovanje - varovanje podatkov

ABSTRACT This degree thesis represents theoretical and to some point also practical grounding in establishing secondary location for IT department in the Agency of the Republic of Slovenia for Public Legal Records and Related Services (Slovenian abbreviation for the Agency is AJPES and as such is used in the further text). Main purpose of this degree thesis is to prepare all that is needed for the reserve copy of the database. By doing this, we meet two basic requirements: uninterrupted operations and data safeguard. Since we use Oracle® database, we are going to use Oracle’s tool called Data Guard. Also, we are going to use a tool called RMAN which enables implementation of quality backup and first transfer of the database to the secondary location. First part presents the Agency (AJPES) and its organizational structure. It also defines key concepts that are used throughout the thesis. Second part explains database tools Data Guard and RMAN. Thesis then resumes with a description of the setting for the database on the secondary location, way of connecting both databases (primary and secondary) and way of assuring proper transfer and proper backup of the data. Switchover between both databases in case of problems is also described. At the end of the thesis we summarized testing results in the form of SWOT analysis, and we adduced key factors that have to be considered if this secondary location is about to live.

KEYWORDS

- Oracle database - Data Guard - RMAN - uninterrupted operations - data safeguard

KAZALO 1 UVOD ........................................................................................................ 1

1.1 Predstavitev problema .......................................................................... 1 1.2 Cilj diplomske naloge ........................................................................... 2 1.3 Predvideni rezultati .............................................................................. 3 1.4 Metode dela ........................................................................................ 3

2 AJPES IN NJEGOVE NALOGE ....................................................................... 4 2.1 Predstavitev agencije ........................................................................... 4 2.2 Delovne naloge agencije ....................................................................... 5 2.3 Registri ............................................................................................... 5 2.4 Uradne objave ..................................................................................... 7 2.5 Letna poročila ...................................................................................... 7 2.6 Statistike ............................................................................................. 8 2.7 Bonitetne storitve ............................................................................... 10 2.8 Evropski poslovni register .................................................................... 11

3 PODATKOVNA ZBIRKA ORACLE IN NJENA ORODJA ...................................... 12 3.1 Kratka zgodovina Oracla ...................................................................... 12 3.2 Oraclova orodja za večjo varnost in razpoložljivost podatkov .................. 12

3.2.1 Automatic Storage Management .................................................... 12 3.2.2 Oracle Restart .............................................................................. 13 3.2.3 Recovery Manager ........................................................................ 13

3.3 Data Guard ........................................................................................ 14 3.3.1 Fizični Data Guard ........................................................................ 14 3.3.2 Logični Data Guard ....................................................................... 15 3.3.3 Razlike med logično in fizično postavitvijo ....................................... 15 3.3.4 Storitve Data Guarda .................................................................... 16 3.3.5 Načini zaščite podatkov ................................................................. 18

4 OBSTOJEČE STANJE .................................................................................. 20 4.1 Trenutna rešitev ................................................................................. 20 4.2 Kritična analiza ................................................................................... 21

5 PREOBLIKOVANJE OBSTOJEČEGA SISTEMA................................................. 24 5.1 Posodobitev strojne in programske opreme ........................................... 24 5.2 Postavitev testnega okolja ................................................................... 25

5.2.1 Strežnik in operacijski sistem ......................................................... 25 5.2.2 Automatic Storage Management (ASM) .......................................... 29 5.2.3 Oracle Grid Infrastructure ............................................................. 31 5.2.4 Oracle DB .................................................................................... 37 5.2.5 Podatkovna zbirka ........................................................................ 43 5.2.6 Priprava direktorijev ..................................................................... 52 5.2.7 Priprava operacijskega sistema ter skript za administracijo, nadzor in vzdrževanje podatkovne zbirke ................................................................... 53 5.2.8 Priprava podatkovne zbirke in uvoz podatkov .................................. 53

5.3 Oracle Data Guard .............................................................................. 54 5.3.1 Priprava podatkovne zbirke ........................................................... 54 5.3.2 Priprava posrednika – Data Guard Broker ....................................... 59 5.3.3 Testiranje rešitve ......................................................................... 60

6 ZAKLJUČKI ............................................................................................... 66 6.1 Ugotovitve ......................................................................................... 66

6.2 Ocena učinkov .................................................................................... 66 6.3 Pogoji za uvedbo ................................................................................ 67 Priloge ......................................................................................................... 68 Literatura in viri ............................................................................................ 85 Kazalo slik .................................................................................................... 88 Pojmovnik .................................................................................................... 89 Kratice in akronimi ........................................................................................ 89

Univerza v Mariboru – Fakulteta za organizacijske vede Diplomsko delo univerzitetnega študija

Marcel Milić: Preizkušanje Oraclovega orodja Data Guard za doseganje visoke razpoložljivosti in varovanje podatkov

stran 1

1 UVOD 1.1 PREDSTAVITEV PROBLEMA Informacijska tehnologija (IT) že nekaj časa predstavlja tisti člen v poslovnem procesu, ki nikakor ne more umanjkati. V sodobnem poslovnem svetu brez IT ne moremo narediti skoraj ničesar, saj imamo »vse shranjeno v računalniku«, kot se radi izrazijo končni uporabniki naših storitev. Prav zato so pred službo, ki zagotavlja storitve IT, vedno novi izzivi. Eden največjih je zagotavljanje stalne dosegljivosti podatkov. Ta v splošnem zajema dvoje: 1. podatki so dostopni ves čas (24 × 7), 2. če pride do izpada strojne in/ali programske opreme, ta izpad ne sme bistveno

vplivati na razpoložljivost. Storitve morajo biti spet dostopne v najkrajšem možnem času.

V splošnem je razpoložljivost sposobnost, da sistem v poljubnem trenutku zadovoljivo deluje ali je sposoben zadovoljivega delovanja, če ga uporabljamo pri določenih pogojih. Zanesljivost pa je sposobnost, da sistem, ki ga uporabljamo pri določenih pogojih, zadovoljivo deluje določen časovni interval (Hudoklin Božič in Rozman, 2004). Načinov, kako to zagotoviti je več. Vsak proizvajalec strojne opreme ponuja svoje rešitve, ki naj bi zagotavljale učinkovito podvajanje strežnikov, diskovnih podsistemov itn. Tudi proizvajalci podatkovnih zbirk predstavljajo svoje rešitve. Naš cilj je bil najti optimalno rešitev tako na nivoju strojne opreme kot na nivoju podatkovne zbirke. Ko se odločamo o strojni opremi, nas seveda zanima tudi vzdrževalnost, sposobnost, da se sistem iz stanja nedelovanja zaradi korektivnega ali preventivnega vzdrževalnega posega povrne v stanje zadovoljivega delovanja v določenem časovnem intervalu (Hudoklin Božič in Rozman, 2004). Proizvajalci strojne opreme zato vgrajujejo komponente, ki jih je mogoče hitro zamenjati (ang. hot swap), pri tem pa strojna oprema deluje brez prekinitve. Seveda pa to pomeni, da so vse take komponente podvojene. To velja tako za strežnike (npr. napajalnik) kot diskovne podsisteme (povezava diska v RAID, kjer odpoved diska ne pomeni odpovedi celotnega podsistema). Takšno strojno opremo uporabljamo seveda tudi v Agenciji. Veliko vlogo pri zagotavljanju razpoložljivosti ima seveda varovanje podatkov. Varovanje podatkov je proces, v katerem varujemo pomembne podatke pred okvaro ali izgubo. Z izrazom varovanje podatkov opisujemo tako varnostno kopiranje podatkov kot zagotavljanje okrevanja po katastrofi (ang. disaster recovery) oziroma



stran 2

neprekinjenega poslovanja (ang. business continuity). Strategija varovanja podatkov mora zajemati upravljanje življenjskega cikla podatkov (ang. data lifecycle management), torej procesa, ki bo avtomatiziral kopiranje kritičnih podatkov na drugo lokacijo, in upravljanje življenjskega cikla informacij (ang. information lifecycle management), podrobno strategijo vrednotenja, katalogiziranja in varovanja informacijskih dobrin pred aplikacijskimi in/ali uporabniškimi napakami, virusi in škodljivim programjem, strojnimi napakami ali izpadi infrastrukture (TechTarget, Data Protection, 2016). Pri odločanju o strategiji moramo upoštevati različne dejavnike: količina podatkov, ki jo lahko izgubimo; stroški ljudi, ki ne bodo delali zaradi nedostopnosti zbirke; stroški za strojno in programsko opremo, ki je potrebna za zagotavljanje želene strategije varovanja podatkov; število ur, ki jih bo zahtevala celotna obnova podatkovne zbirke; stroški izobraževanja za človeka ali več ljudi, ki bodo sposobni obnoviti podatkovno zbirko (Theriault in drugi, 2000). Okrevanje po katastrofi na splošno zadeva natančno določene korake, ki jih je treba narediti, da bi lahko nadaljevali z delom po katastrofični naravni nesreči ali po kakšnem drugem katastrofičnem dogodku. V IT lahko takšni koraki zajemajo obnovo strežnikov s pomočjo varnostnih kopij, obnovo komunikacijskih linij ali zagotovitev omrežnih povezav, s katerimi bi lahko zadostili takojšnjim poslovnim potrebam. Neprekinjeno poslovanje pa opisuje procese in postopke, ki jih mora organizacija pripraviti, da bi zagotovila delovanje ključnih funkcij med in po katastrofičnem dogodku. Neprekinjeno poslovanje in načrt za okrevanje po katastrofi (ang. disaster recovery plan) gresta torej z roko v roki. Pa vendarle, neprekinjeno poslovanje se ukvarja tudi z obsežnejšim načrtovanjem dolgoročnejših oziroma kroničnih izzivov za uspeh organizacije. Možne težave za neprekinjeno poslovanje lahko predstavlja bolezen ali odsotnost ključnih ljudi, odpoved partnerja v nabavni verigi, katastrofične napake ali okužbe s programskimi virusi (TechTarget, DR&BC, 2016). Seveda želimo v Agenciji zagotavljati tako hitro in učinkovito okrevanje po katastrofi kot neprekinjeno poslovanje. Pri nas smo razdeljeni na dva svetova – Microsoftov (operacijski sistem, podatkovna zbirka) in Linuxov oziroma Oraclov svet. Podvojiti moramo vse dele, ki so vpeti v katero koli od naših storitev. Mi smo se lotili Linuxa in podatkovne zbirke Oracle.

1.2 CILJ DIPLOMSKE NALOGE Cilj diplomske naloge je bil pridobiti uvid v učinkovitost Oraclove rešitve, ki smo jo izbrali za postavitev rezervne lokacije. Potreba po rezervni zbirki na rezervni lokaciji je jasna. Vprašanje je bilo le, katero rešitev izbrati. Glede na to, da uporabljamo Oraclovo podatkovno zbirko, se nam je Oracle Data Guard ponujal sam po sebi, saj vsebuje vse, kar potrebujemo.



stran 3

Glavna dilema je bila, ali se lotiti reševanja problema s postavitvijo Oraclove gruče (Oracle Real Application Cluster ‒ RAC) ali postaviti Data Guard. Na koncu smo se odločili za Active Data Guard, saj pokriva težave zaradi odpovedi glavnega strežnika in/ali diskovnega podsistema, medtem ko gruča rešuje zgolj težave zaradi odpovedi strežnika in težave zaradi njegove preobremenjenosti (veliko število uporabnikov in njihovih poizvedb). Odpovedi diskovnega podsistema gruča sama po sebi ne rešuje. Zato smo pripravili testno okolje, ki nam je dalo uvid v to, kaj in koliko je treba narediti za njegovo postavitev ter kako deluje v praksi.

1.3 PREDVIDENI REZULTATI Rezultat diplomske naloge je postavljeno testno okolje, na katerem smo lahko preskusili delovanje Data Guarda in testirali različne scenarije odpovedi in obnove podatkovne zbirke.

1.4 METODE DELA Na osnovi zahtev, ki jih je Sektorju za informatiko naložilo vodstvo Agencije, smo pregledali literaturo in spletne vire, postavili testno okolje in analizirali možne scenarije. Vse Oraclove podatkovne zbirke v naši Agenciji tečejo na operacijskem sistemu Linux, tako da ta del ni bil zajet v preskušanje. Preskušanje je zajemalo namestitev Oraclovega Automatic Storage Managementa (ASM) ter podatkovne zbirke na primarni in sekundarni strežnik, uvoz podatkov iz obstoječe zbirke v primarno in namestitev Data Guarda. Nato je sledilo testiranje prenosa transakciji iz primarne v sekundarno zbirko in preklop med njima (ang. switchover). Na koncu smo namestili še procedure za zagon in zaustavitev zbirke, za varnostno kopiranje, izvoz podatkov ter vsakodnevno pošiljanje dnevniške datoteke (alert.log). V zaključku smo zapisali oceno postavljene rešitve in jo analizirali z analizo SWOT.



stran 4

2 AJPES IN NJEGOVE NALOGE

2.1 PREDSTAVITEV AGENCIJE Agencijo Republike Slovenije za javnopravne evidence in storitve (AJPES) so ustanovili julija 2002. Ustanovljena je bila na podlagi Sklepa o ustanovitvi Agencije Republike Slovenije za javnopravne evidence in storitve (Ur. List RS, št. 53/02). Naloge AJPES določa Zakon o plačilnem prometu, ki je bil sprejet 20. 6. 2002 (Ur. List RS, št. 30/02). Z delom je Agencija začela 1. 7. 2002. Od Agencije Republike Slovenije za plačilni promet (APP) je prevzela opravljanje statistično-informativnih nalog. Te zajemajo obdelovanje in objavljanje podatkov iz letnih poročil posameznih poslovnih subjektov in opravljanje različnih statističnih raziskovanj. Opravlja tudi druge za naloge, ki so pomembne za državo, predvsem vodenje različnih registrov in evidenc. Kot temeljne dejavnosti AJPES so opredeljene naslednje naloge (Zakon o plačilnem prometu): zbiranje, obdelava in objava letnih poročil pravnih oseb; statistična raziskovanja gibanja izplačanih plač, uspešnosti poslovanja pravnih oseb; vodenje registrov in evidenc podatkov o pravnih osebah; bonitetna dejavnost; izvedba večstranskega pobotanja obveznosti in terjatev. AJPES ima 13 organizacijskih enot, ki so določene v Sklepu o ustanovitvi AJPES. Sedež Centrale je v Ljubljani, izpostave pa so v: Ljubljani, Celju, Kopru, Kranju, Krškem, Mariboru, Murski Soboti, Novi Gorici, Novem mestu, Postojni, Trbovljah in Velenju. Izpostave so razdeljene v štiri velikostne razrede (Slika 1). V kateri velikostni razred bo dodeljena posamezna izpostava, je odvisno od števila vseh pravnih oseb in samostojnih podjetnikov na območju statistične regije, v kateri izpostava deluje. (AJPES, organiziranost, 2016) Takšna razvejana mreža koristi tako dajalcem podatkov kot tudi njihovim uporabnikom ‒ državi in državnim institucijam, znanstveno-raziskovalnim in drugim institucijam ter posameznim poslovnim subjektom. AJPES upravljata 5-članski Svet AJPES in direktor. Vlada Republike Slovenije imenuje tako člane Sveta AJPES kot direktorja. (AJPES, predstavitev, 2016)



stran 5

Slika 1: Mreža organizacijskih enot (vir: Ajpes, organiziranost, 2016)

2.2 DELOVNE NALOGE AGENCIJE Skladno z Zakonom o sodnem registru je AJPES pooblaščen za upravljanje podatkovne zbirke sodnega registra kot sestavnega dela Poslovnega registra Slovenije (PRS). Nekatere spremembe predpisov pa so v postopek registracije gospodarskih družb in vodenje sodnega registra vnesle nekaj sprememb. Najpomembnejše novosti so:

zaradi združitve podatkovnih zbirk sodnega registra in PRS se je vpis podatkov v oba registra združil v enoten postopek,

postopek vpisa gospodarske družbe v PRS/sodni register se izvede prek sistema e-VEM v elektronski obliki,

predlog za vpis v sodni register je mogoče vložiti na katerikoli vstopni točki VEM ali pri notarju,

vsi postopki vpisa ali spremembe podatkov v PRS/sodnem registru, ki jih gospodarske družbe izvedejo prek vstopnih točk VEM, so brezplačni,

o predlogu za vpis v sodni register odloči sodišče, vpis v PRS se objavi hkrati z vpisom v sodni register, sklep o vpisu v sodni register prejme gospodarska družba v papirni ali

elektronski obliki (v varni poštni predal).

2.3 REGISTRI

V Agenciji vodimo kar nekaj registrov. Najpomembnejši je vsekakor Poslovni register Slovenije (PRS). To je osrednja zbirka podatkov o vseh poslovnih subjektih s sedežem na območju RS, ki opravljajo pridobitno ali nepridobitno dejavnost, o njihovih delih in o podružnicah tujih podjetij (AJPES, registri, 2016).

http://zakonodaja.gov.si/rpsi/r00/predpis_ZAKO320.html



stran 6

Del zbirke PRS je tudi Evidenca digitalnih potrdil (EDP) zakonitih zastopnikov poslovnih subjektov. Register transakcijskih računov (RTR) je enotna zbirka podatkov o transakcijskih računih in o njihovih imetnikih. Register neposestnih zastavnih pravic in zarubljenih premičnin (RZPP) je register premičnin, ki so neposestno zastavljene oziroma zarubljene. Register fizičnih oseb, ki opravljajo dejavnost proizvodnje električne energije (REZ) – vanj se vpišejo osebe, ki želijo v pravnem položaju zasebnika opravljati dejavnost proizvodnje električne energije, dejavnost pa opravljajo le z eno proizvodno napravo na obnovljive vire energije ali za soproizvodnjo z visokim izkoristkom z nazivno močjo do 50 kW. Fizične osebe, ki dejavnost proizvodnje električne energije opravljajo v pravnem položaju samostojnega podjetnika posameznika ali nosilca dopolnilne dejavnosti na kmetiji, se ne vpisujejo v REZ. Register menic, protestiranih zaradi neplačila (RPM), je enotni javni register. Vanj vpisujejo notarji v skladu z zakonom, ki ureja menico, podatke o napravljenih protestih menic zaradi neplačila, če so menice izdali gospodarski subjekti. V skladu z Zakonom o preprečevanju zamud pri plačilih AJPES upravlja ta register od 16. 6. 2011 dalje. Register protestiranih menic omogoča preverjanje, ali gospodarski subjekt kot dolžnik izpolnjuje svoje obveznosti, ki izvirajo iz izdanih menic. S tem registrom torej AJPES povečuje varnost poslovnega okolja. AJPES uporabnikom spletnega portala zagotavlja brezplačen vpogled v javne podatke o napravljenih protestih menic zaradi neplačila prek aplikacije eRPM. Uporabniki lahko na podlagi vnosa iskalnih pogojev pridobijo podatke o datumu napravljenega protesta, višini obveznosti dolžnikov, morebitnih delnih poplačilih menične obveznosti itn. Vpisnik prostovoljskih organizacij (RP) je AJPES vzpostavil na podlagi Zakona o prostovoljstvu. Vanj vpisuje ter opravlja spremembe, izbrise in ponovno priglasitev prostovoljskih organizacij. Agencija vodi tudi Register zavezancev za informacije javnega značaja (RZIJZ). Osnova zanj je Zakon od dostopu do informacij javnega značaja. Seznam posameznikov, ki opravljajo osebno dopolnilno delo (SODD) je še en register, ki ga vodi Agencija na podlagi 13. člena Zakona o preprečevanju dela in zaposlovanja na črno (ZPDZC-1) in Pravilnika o osebnem dopolnilnem delu.



stran 7

2.4 URADNE OBJAVE Uradne objave so naslednje področje, ki ga pokriva Agencija (AJPES, uradne objave, 2016). Gre za objave:

v postopkih vpisov v poslovni in sodni register, v postopkih zaradi insolventnosti, po Zakonu o gospodarskih družbah in po Zakonu o finančnih zavarovanjih.

2.5 LETNA POROČILA AJPES zbira in objavlja tudi letna poročila različnih organizacij – gospodarskih, prostovoljskih, političnih ipd. (AJPES, letna poročila, 2016).

Družbe in zadruge Gospodarske družbe in zadruge predložijo podatke za državno statistiko (do konca marca za preteklo koledarsko leto) ter za javno objavo. Rok za predložitev konsolidiranih in revidiranih letnih poročil za javno objavo je osem mesecev po koncu poslovnega leta, za nerevidirana letna poročila pa tri mesece po koncu poslovnega leta.

Podjetniki Samostojni podjetniki (razen samostojnih podjetnikov, ki so obdavčeni na podlagi ugotovljenega dobička z upoštevanjem normiranih odhodkov) predložijo podatke za državno statistiko in za javno objavo do konca marca za preteklo koledarsko leto.

Pravne osebe javnega prava Pravne osebe javnega prava (določeni in drugi uporabniki enotnega kontnega načrta) predložijo podatke za državno statistiko in za zagotovitev javnosti do konca februarja za preteklo koledarsko leto. Uporabniki državnega in občinskih proračunov do konca marca oziroma do konca aprila predložijo še premoženjsko bilanco.

Društva Društva in zveze društev (vključno z društvi s statusom invalidske organizacije) predložijo podatke za državno statistiko in za zagotovitev javnosti do konca marca za preteklo koledarsko leto. Izjema so društva, ki so zavezana k reviziji; ta morajo revidirana letna poročila za zagotovitev javnosti predložiti v osmih mesecih po koncu koledarskega leta.

Nepridobitne organizacije Nepridobitne organizacije (pravne osebe zasebnega prava [ustanove, politične stranke, sindikati itn.]) morajo predložiti podatke za državno statistiko in za zagotovitev javnosti do konca februarja za preteklo koledarsko leto.



stran 8

Prostovoljske organizacije Prostovoljske organizacije, ki so vpisane v vpisnik prostovoljskih organizacij, istočasno s podatki iz letnega poročila za namen državne statistike pripravijo poročilo o prostovoljstvu, na enotno predpisanem obrazcu.

Poročila o kampanjah Organizatorji volilnih in referendumskih kampanj najpozneje v 15 dneh po zaprtju posebnega transakcijskega računa predložijo poročilo o financiranju volilne oz. referendumske kampanje za namene javne objave in revizije.

2.6 STATISTIKE Agencija zbira in objavlja statistiko na različnih področjih, zanimivih za širšo javnost (AJPES, statistike, 2016).

Plače Pravne osebe zasebnega sektorja ob vsakokratnem izplačilu plač predložijo AJPES zbirne podatke o izplačanih plačah in o številu zaposlenih, ki so prejeli plačo. Podatke predložijo prek spletnega portala. Podatki o posamezni pravni osebi niso javni, AJPES pa mesečno objavlja zbirne podatke.

Plače v javnem sektorju Neposredni in posredni uporabniki državnega in občinskih proračunov mesečno posredujejo AJPES podatke o izplačanih plačah funkcionarjev in javnih uslužbencev prek Informacijskega sistema za posredovanje in analizo podatkov o plačah v javnem sektorju (ISPAP). Z vpogledom v ta sistem se zagotavlja tudi javnost podatkov o plačah za zaposlene, za katere določila kolektivnih pogodb ne veljajo.

Statistika finančnih računov Določene nefinančne in finančne družbe ter institucionalne enote centralne in lokalne ravni države trimesečno poročajo o stanjih finančnih sredstev in obveznostih na finančnih računih ter o transakcijah in vrednostnih spremembah v finančnih sredstvih in obveznostih. Podatki so namenjeni za finančne račune Banke Slovenije.

Četrtletno poročanje Gospodarske družbe, zadruge in podružnice tujih podjetij, ki imajo več kot 49 zaposlenih in vzorec družb, zadrug in podružnic tujih podjetij z 49 in manj zaposlenimi poročajo podatke iz bilance stanja, izkaza poslovnega izida, podatke o investicijah v osnovna sredstva in druge podatke o poslovanju.

Statistike plačilnega prometa Ponudniki plačilnih storitev AJPES mesečno ali dnevno poročajo o prometu na računih poslovnih subjektov in o njihovih neporavnanih obveznostih.



stran 9

Druge statistike Izbrane statistične enote sporočajo podatke za statistična raziskovanja, ki jih AJPES kot pooblaščeni izvajalec opravlja v sodelovanju s Statističnim uradom RS.

o Dividende Statistični urad Republike Slovenije (SURS) letno opravi raziskovanje o izplačanih dividendah. Z raziskovanjem se zbirajo podatki o izplačanih dividendah po sektorjih prejemnikov dividend in so uporabljeni za statistične namene pri sestavi nefinančnih sektorskih računov v SURS. Statistično raziskovanje je predpisano z letnim programom statističnih raziskovanj.

o Stroški dela in struktura delovnega časa Statistični urad Republike Slovenije (SURS) in AJPES sta v maju 2013 prvič opravila statistično raziskavo o stroških dela in o strukturi delovnega časa (za leto 2012) na skupnem vprašalniku. Predhodno je SURS skupaj z AJPES v letu 2009 opravil štiriletno raziskavo o stroških dela. Namen raziskave na skupnem vprašalniku je racionalno opravljanje dejavnosti državne statistike in zmanjšanje stroškov tako za dajalce podatkov (obveznike poročanja) kakor tudi za državo ter ob tem zagotoviti potrebne podatke za SURS. Statistična raziskava o stroških dela je zasnovana na podlagi usklajenega raziskovanja o stroških dela, ki ga vsake štiri leta opravijo države članice Evropske unije z namenom spremljanja stanja in strukture stroškov dela po različnih karakteristikah poslovnih subjektov. S statističnim raziskovanjem o strukturi delovnega časa se zbirajo strukturni podatki o delovnem času, ki pa so potrebni tudi za izboljšanje kakovosti drugih raziskovanj na podlagi uredb Evropske unije (za kratkoročni statistični kazalnik o opravljenih delovnih urah, za indeks stroškov dela in za podatke nacionalnih računov). Raziskovanji sta predpisani z letnim programom statističnih raziskovanj.

o Struktura plače Statistični urad Republike Slovenije (SURS) opravi vsake štiri leta raziskavo o strukturi plače. Poslovni subjekti (oziroma njihove enote v sestavi), izbrani v vzorec, poročajo podatke o plačah in drugih prejemkih za mesec oktober (kot reprezentativni mesec) in podatke o plačah in drugih prejemkih za celotno leto. Raziskava je usklajena s poenotenim raziskovanjem o strukturi plače (Structure of Earnings Survey), ki ga vsake štiri leta opravijo države članice Evropske unije. Prilagojena je zahtevam uredb Evropskega sveta in Evropske komisije, hkrati pa so v njej upoštevane lastnosti slovenskega trga dela. Namen raziskave je za slovenske načrtovalce politike plač in zaposlovanja pridobiti mednarodno primerljive podatke



stran 10

o strukturi plače na slovenskem trgu dela in prikazati vpliv posameznih plačnih komponent na njeno višino. Statistično raziskovanje je predpisano z letnim programom statističnih raziskovanj.

o Struktura vmesne potrošnje in prihodkov Statistični urad Republike Slovenije (SURS) vsake štiri leta oz. v večletnih presledkih opravi raziskavo o strukturi vmesne potrošnje in prihodkov. Poslovni subjekti, vključeni v vzorec, poročajo podatke o vrstah stroškov in vrstah prihodkov v različnih dejavnostih slovenskega gospodarstva. Podatki iz raziskovanja se uporabljajo za sestavljanje tabel po dejavnostih (tabel ponudbe in porabe, vhodno-izhodnih tabel), ki so redna obveznost SURS, določena v zakonodaji EU, in sestavni del ocenjevanja agregatov nacionalnih računov. Statistično raziskovanje je predpisano z letnim programom statističnih raziskovanj.

o Poslovne storitve Statistični urad Republike Slovenije (SURS) letno opravlja raziskovanje o poslovnih storitvah, da bi zagotovil mednarodno primerljive podatke v skladu z evropskimi standardi o strukturni statistiki podjetij in za analizo delovanja gospodarstva v sektorju poslovnih storitev ter delovanja domačega in skupnega evropskega trga na področju poslovnih storitev. Poslovni subjekti poročajo podatke o prihodkih od prodaje, razčlenjenih po proizvodih oziroma storitvah in po sedežu strank, za izbrane storitvene dejavnosti. Statistično raziskovanje je predpisano z letnim programom statističnih raziskovanj.

2.7 BONITETNE STORITVE AJPES se ukvarja tudi s tržno dejavnostjo, in sicer z bonitetnimi storitvami (AJPES, bonitete, 2016). Fizične ali pravne osebe lahko določene informacije, vezane na boniteto poslovnega subjekta, dobijo brezplačno, določene (bolj detajlne informacije) pa so plačljive. V okviru teh storitev AJPES opravlja tudi pobot. Zato smo skupaj s poslovnimi partnerji razvili vrsto aplikacij, ki uporabnikom omogočajo hiter dostop do podatkov, nekateri pa tudi prevzemajo podatke od nas (dnevno, tedensko, mesečno) v datoteki XML. Spletna boniteta eS.BON

Vsebina eS.BON

splošni podatki o poslovnem subjektu (podjetju, zadrugi ali samostojnem podjetniku v Sloveniji),



stran 11

bonitetna ocena SB, ki je določena z modelom S.BON AJPES1 na podlagi letnega poročila za zadnje leto ter vse medletne spremembe modelske ocene s pojasnili razlogov za spremembe. Ta ocena kaže na zmožnost poslovnega subjekta za poravnavo svojih obveznosti v obdobju 12 mesecev po datumu izdelave računovodskih izkazov,

podatki o kratkoročni plačilni disciplini (blokade),

revizorjevo mnenje,

dejavniki tveganja poslovnega subjekta (dobičkonosnost in denarni tok, zadolženost, likvidnost, aktivnost, produktivnost) in primerjava z vsemi istovrstnimi poslovnimi subjekti,

podatki in kazalniki poslovanja za zadnjih pet let,

podatki in kazalniki za dejavnost, v katero subjekt sodi, in mesto v dejavnosti,

prejemki in izdatki v tekočem letu,

dostop do podatkov in besedil Sodnega registra,

dostop do objavljenih poslovnih poročil (revidirana, konsolidirana).

Namen eS.BON

za preverjanje sposobnosti poravnavanja obveznosti poslovnega partnerja,

za preverjanje kreditne sposobnosti,

za predstavitev poslovanja poslovnim partnerjem in drugim.

Poleg aplikacije eS.BON imajo uporabniki na voljo še druge bonitetne aplikacije, ki so zelo pomembne za varno poslovanje naših gospodarskih družb in samostojnih podjetnikov. Število insolventnih dogodkov se namreč iz leta v leto povečuje. Še višja je rast prisilnih in prostovoljnih prisilnih poravnav, ki raste s stopnjo, višjo od 100 %.

2.8 EVROPSKI POSLOVNI REGISTER

Evropski poslovni register (European Business Register – v nadaljevanju: EBR) je informacijski sistem, preko katerega države članice zagotavljajo podatke in nekatere storitve iz svojih nacionalnih poslovnih registrov. Trenutno je v sistem EBR vključenih 24 evropskih držav, vendar se mreža nenehno širi. Preko informacijskega sistema EBR je vsakomur na enostaven in hiter način omogočen dostop do podatkov in informacij o poslovnih subjektih iz evropskih držav članic EBR, prav tako pa tudi do nekaterih dokumentov, povezanih s poslovanjem poslovnih subjektov. (AJPES, EBR, 2016)

AJPES preko informacijske mreže EBR nudi tudi podatke o slovenskih poslovnih subjektih.

1 Model S.BON AJPES – bonitetna ocena po pravilih Basel II, je opisan v dokumentu, ki ga

najdete na spletni strani: http://www.ajpes.si/doc/Bonitete/S.BON/AJPES_S.BON-

opis_metodologije-2014.pdf.

http://www.ajpes.si/Bonitetne_storitve/S.BON_AJPES/Bonitetna_lestvica/Splosno?id=1625



stran 12

3 PODATKOVNA ZBIRKA ORACLE IN NJENA ORODJA

3.1 KRATKA ZGODOVINA ORACLA Oracle Corporation ima že več kot 30-letno zgodovino na področju relacijskih podatkovnih zbirk. Ustanovili so ga leta 1977. Letos pa mineva 30 let, odkar se je podjetje leta 1986 odprlo in odšlo na borzo. Že leta 1983 so poslali na trg prvo komercialno različico svoje podatkovne zbirke. Takratna verzija 3, ki so jo napisali v programskem jeziku C, je delovala na vseh mogočih okoljih. Oracle je prišel v Slovenijo že leta 1986, ko so podpisali pogodbo z Nuklearno elektrarno Krško, leta 1987 pa so dobili prvega slovenskega partnerja – podjetje Kopa. Oracle se je in se še ukvarja tudi z razvojem programerskih orodij (Oracle Forms & Reports, Oracle Designer) in celovitih poslovnih rešitev. Ponuja tudi celotne rešitve od strojne opreme (Exadata), operacijskega sistema (Unbreakable Linux [Red Hat]), do podatkovne zbirke. (Oracle, Corporate History, 2016)

3.2 ORACLOVA ORODJA ZA VEČJO VARNOST IN RAZPOLOŽLJIVOST PODATKOV

Sem spada več orodij. Eno od njih je seveda tudi Data Guard, vendar bomo njega opisali v posebnem delu. Real Application Cluster (RAC) ne bomo opisovali, saj pri nas ne pride v poštev, poleg tega pa spada v posebno kategorijo orodij.

3.2.1 Automatic Storage Management ASM je za Oraclovo zbirko hkrati sistem za upravljanje z diski in datotečni sistem, ki podpira tako gručo (ang. cluster) kot posamezno podatkovno zbirko. ASM shranjuje podatke v diskovne skupine (ang. disk group). Gre za nekakšne zbirke diskov, ki jih ASM upravlja kot enote. Znotraj diskovne skupine ASM pripravi datotečni vmesnik za podatkovne datoteke. Vsebino datoteke orodje enakomerno razporedi po diskovnem sistemu, tako da so dostopni časi do podatkov enakomerni. Diske lahko dodajamo in umikamo iz skupine, medtem ko zbirka še vedno deluje. Oracle ASM samodejno prerazporedi vsebino datoteke in s tem omogoči brezprekinitveno delovanje podatkovne zbirke. (Vengurlekar in drugi, 2008, stran xxiv-xxv) Prehod z običajnega datotečnega sistema (NTFS, ext*, XFS itn.) omogoča enostavno orodje v Oracle Enterprise Managerju. ASM poleg tega uporablja še eno Oraclovo funkcionalnost – Oracle Managed Files (OMF), ki poenostavlja upravljanje datotek podatkovne zbirke. OMF samodejno



stran 13

ustvari datoteke na izbrani lokaciji, jih poimenuje in sprosti prostor, če podatkovno ali katero drugo datoteko pobrišemo. Funkcionalnost Oracle ADVM (ASM Dynamic Volume Manager) pa omogoča združevanje posameznih diskov v diskovne skupine. Z njimi večamo diskovni prostor za podatkovno zbirko in omogočamo varovanje, saj lahko diskovne skupine organiziramo v RAID (0 [ni varovanja], 1, 1+0, 0+1, 5, 6). (Vengurlekar in drugi, 2008, stran 23-6; ASM RAID, 2016)

3.2.2 Oracle Restart Oracle Restart lahko uporabljamo samo na samostojnem strežniku (ang. standalone server). Če imamo gručo (ang. cluster), Oracle Restart ne pride v poštev. (Oracle Restart, 2016) Ta funkcionalnost poveča razpoložljivost Oraclove podatkovne zbirke, ker poskrbi za:

samodejen zagon vseh Oraclovih komponent, podatkovne zbirke, programa za poslušanje (Oracle Net Listener), storitev podatkovne zbirke in Oracle ASM-a, če pride do odpovedi strojne ali programske opreme,

pravilen vrstni red zaganjanja vseh komponent, če moramo ponovno zagnati strežnik, na katerem teče podatkovna zbirka in

reden pregled stanja Oraclovih komponent ter za čisto zaustavitev in ponoven zagon komponente, pri kateri ugotovi kakšno nepravilnost.

3.2.3 Recovery Manager

Recovery Manager ali RMAN je Oracle najprej razvil kot orodje, ki omogoča hitro kopiranje in vračanje podatkov, če pride do kakšne težave. Po začetnih težavah v verziji 8i, ko ga skoraj noben od administratorjev ni hotel uporabljati, je to postalo orodje, ki ne omogoča zgolj varnostnega kopiranja in vračanja podatkov, ampak tudi kloniranje zbirke, pregled zbirke na nivoju podatkovnega bloka in odpravo tovrstnih težav, odpravo težav na nivoju tabelnega prostora (ang. tablespace), vračanje parametrske in/ali kontrolne datoteke itn. Oraclova podatkovna zbirka lahko teče v dveh načinih – arhivskem (ang. archive log mode) in nearhivskem (ang. nonarchive log mode). Če zbirka teče v arhivskem načinu, potem lahko ob težavah vrnemo zbirko v stanje, v katerem je bila tik pred izpadom. Do sekunde natančno. Zbirka v arhivskem načinu lahko dela v režimu 24/7, saj lahko delamo varnostno kopijo, medtem ko zbirka normalno deluje (t. i. vroče varnostno kopiranje, ang. hot backup). Če hočemo uporabljati Data Guard, je to obvezen način delovanja. Oracle to omogoča z arhiviranjem zapisov iz obnovitvene datoteke (ang. redo log file). Na eno ali več lokacij, ki jo določimo ob kreiranju zbirke ali kasneje, zbirka (log writer – LGWR) prepiše obnovitveno datoteko v arhiv. Tja se zapišejo vse potrjene transakcije. RMAN pa je orodje, ki omogoča kopiranje zbirke in arhivov, nam



stran 14

omogoča nadzor nad kopijami, kopirane arhivske datoteke pobriše z diska, da ne zasedajo prostora, in seveda poskrbi za restavriranje podatkov, če pride do težav. Dodatno orodje, ki skrbi za diagnostiko podatkovne zbirke pa je Automatic Diagnostic Repository (ADR). (DB Backup and Recovery, 2016)

3.3 DATA GUARD Data Guard je Oraclova rešitev za varovanje podatkovne zbirke, če pride do odpovedi primarnega strežnika (strojna oprema ali operacijski sistem) ali diskovnega podsistema. V tem primeru aktiviramo podatkovno zbirko na sekundarnem strežniku, ki bo prevzela vse ali vsaj večino uporabnikov. Koliko bo teh uporabnikov, je odvisno od odločitve vodstva pri načrtovanju sekundarnega strežnika. Običajno je konfiguracija sekundarnega strežnika nekoliko šibkejša. Oracle je takšno rešitev vpeljal že pri verziji 8i, le da jo je takrat poimenoval enostavno »Standby database« – podatkovna zbirka v pripravljenosti. Takrat je to bila aktivno-pasivna povezava, z Data Guardom pa je možna tudi povezava aktivno-aktivno, seveda z določenimi omejitvami na sekundarni podatkovni zbirki. Podatkovna zbirka v pripravljenosti je kopija primarne zbirke, ki je z njo transakcijsko usklajena. Z varnostno kopijo primarne zbirke podatkov lahko ustvarimo do devet podatkovnih zbirk, ki bodo v pripravljenosti, in jih vključimo v konfiguracijo Data Guarda. Ko je zbirka ustvarjena, Data Guard samodejno vzdržuje vsako od čakajočih zbirk, tako da prenaša podatke iz obnovitvenega dnevnika (ang. redo log) primarne zbirke in jih zapiše v čakajočo zbirko (ali več njih). To počne preko arhivov. (Jesse in drugi, 2011) Tako kot primarna zbirka je lahko tudi zbirka v pripravljenosti samostojna ali pa je del gruče Oraclovih podatkovnih zbirk (Oracle Real Application Cluster). Oracle Data Guard je sestavljen iz ene primarne zbirke in do devet zbirk v pripravljenosti. Zbirke so lahko geografsko razpršene, vse pa so vpete v Oraclovo omrežje (Oracle Net) in preko njega povezane med seboj. (Jesse in drugi, stran 284-5, 2011; Kessling, 2008) Podatkovna zbirka v pripravljenosti je lahko bodisi fizična bodisi logična. (Data Guard Concepts and Administration 12c, 2016; Jesse in drugi, 2011; Kessling, 2008)

3.3.1 Fizični Data Guard Zagotavlja identično fizično kopijo primarne zbirke podatkov; njena diskovna struktura je identična primarni podatkovni zbirki na ravni bloka. Podatkovne sheme, tudi indeksi, so enake. Fizična zbirka v stanju pripravljenosti je sinhronizirana s primarno podatkovno zbirko, tako da prenesemo podatke iz njenega obnovitvenega dnevnika v zbirko v pripravljenosti, nato pa jih tam ponovno zapišemo (ang. Redo Apply).



stran 15

Fizično zbirko podatkov v pripravljenosti lahko v omejenem obsegu uporabimo tudi v druge poslovne namene in ne zgolj za okrevanje po katastrofi. (Data Guard Concepts and Administration 12c, 2016; Jesse in drugi, 2011)

3.3.2 Logični Data Guard Vsebuje iste logične informacije kot produkcijska podatkovna zbirka, vendar pa sta lahko fizična organiziranost in podatkovna struktura drugačni. Logično zbirko v pripravljenosti sinhroniziramo s primarno zbirko podatkov z izvedbo poizvedovalnih (SQL) stavkov (ang. SQL Apply), ki jih ustrezen mehanizem pretvori iz obnovitvenega dnevnika na primarni zbirki, nato pa jih izvede še na podatkovni zbirki v pripravljenosti. Logično zbirko v pripravljenosti lahko uporabimo tudi v druge poslovne namene in ne zgolj za okrevanje po katastrofi. Uporabniki lahko dostopajo do logične zbirke, da po njej kadar koli poizvedujejo oziroma izdelujejo poročila. Z logično zbirko v pripravljenosti lahko tudi nadgradimo Oraclovo programsko opremo ali namestimo popravke skoraj brez izpada. Logično zbirko v pripravljenosti lahko tako hkrati uporabljamo za zaščito podatkov, izdelavo poročil ali nadgradnjo. (Data Guard Concepts and Administration 12c, 2016; Jesse in drugi, 2011) Osnovne razlike med fizično in logično postavitvijo:

Fizična zbirka v pripravljenosti je identična kopija primarne podatkovne zbirke.

Arhivirane obnovitvene datoteke (Redo Log) primarna zbirka samodejno prenaša v sekundarno zbirko, ki ves čas teče v obnovitvenem (ang. recovery) načinu. Sekundarna zbirka takoj uveljavi vse spremembe, ki so zapisane v teh datotekah.

3.3.3 Razlike med logično in fizično postavitvijo

Logična zbirka v pripravljenosti ni identična kopija primarne zbirke – lahko vsebuje drugačne sheme od tistih v izvorni zbirki.

Logična zbirka z orodjem LogMiner pretvarja zapise iz obnovitvene datoteke v prvotne ukaze DML (insert, update, delete). Ti ukazi se prenesejo in izvedejo v sekundarni zbirki.

Logična sekundarna zbirka je lahko odprta samo za poizvedovanje (ang. read only), uporabniške tabele pa so lahko na voljo tudi za ažuriranje.

V sekundarni zbirki imamo lahko dodatne materializirane poglede in indekse za hitrejši dostop do podatkov.

Prednosti fizične podatkovne zbirke v pripravljenosti:

Imamo identično kopijo primarne zbirke. Okrevanje po katastrofi in visoka razpoložljivost.

Visoka raven zaščite podatkov. Manjša obremenitev primarne zbirke. Večja zmogljivost.



stran 16

Prednosti logične podatkovne zbirke v pripravljenosti:

Hkratna raba primarne in sekundarne zbirke pri poizvedovanju, izdelavi poročil in povzetkov.

Učinkovita raba strojne opreme na sekundarni strani. Manjša obremenitev primarne zbirke. Nekaterih podatkovnih tipov na sekundarni zbirki ne moremo uporabljati.

(Kessling, 2008; Jesse in drugi, 2011)

3.3.4 Storitve Data Guarda Prenos obnovitvenih podatkov

Nadzor avtomatiziranega prenosa podatkov iz produkcijske zbirke na eno ali več arhivskih destinacij. Data Guard nadzoruje tudi možne vrzeli, ki bi lahko nastale zaradi padca omrežnih povezav. Če do tega pride, Data Guard poskrbi za prenos manjkajočih arhivskih datotek s primarne strani na sekundarno. Skrbi tudi za striktno uveljavitev varnostnih načinov. Samodejno nadzoruje in ugotavlja možne napake v obnovitvenih podatkih. Gre lahko za manjkajočo arhivsko datoteko ali napako znotraj prenesene datoteke. Data Guard v takem primeru od primarne zbirke zahteva ponovno pošiljanje manjkajoče ali okvarjene arhivske datoteke. Če imamo več zbirk v pripravljenosti, pa lahko arhivsko datoteko dobi tudi od njih.

Aplikacija arhivskih datotek Apliciranje obnovitvenih podatkov v sekundarni zbirki in njena sinhronizacija s primarno zbirko (Slika 2). Podatke lahko prenesemo v sekundarno zbirko z arhivskimi datotekami, asinhrono, ali pa sinhrono, v realnem času, kjer se vsi ukazi DML izvedejo na obeh zbirkah hkrati (Slika 3). Na primarni zbirki transakcija ni potrjena, dokler sekundarna zbirka ne potrdi uspešnega zaključka.



stran 17

Slika 2: Prenos podatkov pri fizični izvedbi DG (vir: Oracle, Log apply, 2016)

Slika 3: Prenos podatkov pri logični izvedbi DG (vir: Oracle, Log apply, 2016)

Sprememba vloge

Oraclova zbirka lahko deluje kot primarna ali kot zbirka v pripravljenosti (ang. standby). Z Data Guardom lahko spreminjamo to vlogo, in sicer z akcijo nadzorovanega preklopa (ang. switchover) ali nadomestnega delovanja (ang. failover). Pri nadzorovanem preklopu gre za zamenjavo vlog med primarno in sekundarno zbirko. Takšen preklop zagotavlja, da ne bomo izgubili nobenega podatka. Običajno ga uporabljamo pri vzdrževanju primarne zbirke ali primarnega strežnika, npr. pri nameščanju popravkov, bodisi na zbirki bodisi na operacijskem sistemu. Pri tem preklopu enostavno



stran 18

zamenjamo vlogo obeh zbirk, primarna postane sekundarna in obratno. Prehod poteka gladko in pri njem ni treba rekonstruirati nobene od podatkovnih zbirk. Nadomestno delovanje aktiviramo, ko je primarna zbirka nedosegljiva. To naredimo zgolj in samo takrat, ko gre za pogubno napako na primarni zbirki, z nadomestnim delovanjem pa primarno zbirko preselimo na sekundarno. Skrbnik podatkovne zbirke lahko nastavi Data Guard, tako da ne pride do izgube podatkov. Prenos vloge iz sekundarne v primarno zbirko lahko skrbnih uredi z nekaj ukazi SQL. Lahko pa uporabimo orodje Data Guard Broker, ki preklop poenostavi oziroma ga celo avtomatizira. To lahko naredimo preko Oracle Enterprise Managerja ali vmesnika DGMGRL (Data Guard command-line interface).

3.3.5 Načini zaščite podatkov

Ko vodstvo podjetja določa pogoje za delovanje Data Guarda, mora tudi jasno povedati in ovrednotiti možen izpad podatkovne zbirke. V nekaterih primerih si izgube podatkov ne more privoščiti, v drugih primerih pa je razpoložljivost podatkovne zbirke morda pomembnejša od izgube podatkov. Nekateri programi zahtevajo največjo zmogljivost podatkovne zbirke in manjša izguba podatkov ne pomeni težave za delovanje programa. Zato Data Guard omogoča tri različne načine varovanja podatkov. (Data Guard Concepts and Administration 12c, 2016; Jesse in drugi, 2011, strani 310-13) Maksimalna zaščita. Ta način delovanja zagotavlja, da v primeru odpovedi primarne zbirke, ne bo izgubljen noben podatek. Za zagotavljanje takšne ravni zaščite mora biti vsak podatek, ki naj bi ga obnovili, hkrati zapisan tako v obnovitveno datoteko v primarni zbirki kot v obnovitveno datoteko v sekundarni zbirki (vsaj v eni, če jih imamo več). Potem šele velja transakcija za potrjeno (ang. commited). Da ne bi izgubili nobenega podatka, bo primarna zbirka začela s postopkom zaustavljanja, če pride do napake pri pisanju v obnovitveno datoteko sekundarne zbirke ali vsaj ene od njih, če jih imamo več. Maksimalna razpoložljivost. Takšna zaščita zagotavlja najvišjo raven zaščite podatkov, ki je še možna, ne da bi pri tem ogrozili razpoložljivost primarne zbirke. Podobno kot pri maksimalni zaščiti, tudi tukaj transakcija ne bo potrjena, dokler obnovitveni zapis te transakcije ne bo zapisan v obnovitveno datoteko primarne in sekundarne zbirke (ali vsaj ene od njih, če jih imamo več). Vendarle, če zapisovanje v sekundarno zbirko ne uspe, primarna zbirka ne bo začela z zaustavljanjem, tako kot se to zgodi pri maksimalni zaščiti. Namesto tega primarna zbirka še naprej deluje s polno zmogljivostjo, dokler napake ne odpravimo in razrešimo vse vrzeli, ki so nastale v obnovitvenih podatkih. Ko so vse vrzeli odpravljene, začne primarna zbirka samodejno spet delati v načinu maksimalne razpoložljivosti.



stran 19

Pri odpovedi primarne zbirke zagotavlja ta način ničelno izgubo podatkov, vendar zgolj, če kakšna druga napaka ne prepreči, da bi obnovitveni podatki prišli iz primarne v vsaj eno od sekundarnih zbirk (npr. hkratna odpoved primarnega strežnika in omrežja). Maksimalna zmogljivost. Ta način zaščite (privzet) zagotavlja najvišjo raven zaščite podatkov, ki je možna, ne da bi pri tem vplivali na zmogljivost primarne zbirke podatkov. To omogoča zapisovanje obnovitvenega zapisa, takoj ko je transakcija potrjena, v obnovitveno datoteko na primarni zbirki podatkov. Ta isti zapis se seveda zapiše tudi vsaj v eno sekundarno zbirko. Vendar pa je zapisovanje asinhrono glede na transakcije, ki tvorijo obnovitvene zapise. Kadar uporabljamo omrežne povezave z zadostno prepustnostjo, zagotavlja ta raven zaščito, kakršno dobimo pri maksimalni razpoložljivosti z minimalnim vplivom na zmogljivost primarne zbirke. Maksimalna zaščita in maksimalna zmogljivost zahtevata, da so obnovitvene datoteke za sekundarno zbirko konfigurirane za vsaj eno od sekundarnih zbirk.



stran 20

4 OBSTOJEČE STANJE 4.1 TRENUTNA REŠITEV Trenutno imamo na Oraclovem sistemu štiri produkcijske podatkovne zbirke. Poslovni register (PRS), skupaj z dodatnim registrom transakcijskih računov (RTR) in registrom prostovoljcev (RP) – PPRS, statistiko – PSTAT in finance – PFRS2 ter arhivsko zbirko – ARHIV, v kateri hranimo arhivske podatke za statistiko za obdobje 10 let (nekatera področja tudi več). Vse podatkovne zbirke razen arhivske imajo seveda tudi svojo razvojno in testno različico. Določene podatkovne zbirke pa so na Microsoftovem okolju – SQL Server 2014. Podatkovne zbirke so seveda med seboj povezane, saj podatke prenašamo z replikacijo iz podatkovnih zbirk na Oraclu v zbirke na SQL Serverju. Strežniki, na katerih imamo nameščene Oraclove podatkovne zbirke, tečejo na Oracle Virtual Machine (OVM). Gre za virtualizacijo, ki temelji na hipernadzoniku Xen. OVM omogoča živo migracijo strežnikov in podatkovnega podsistema, zagotavlja visoko razpoložljivost, omogoča razdeljevanje virov (ang. Distributed Resource Scheduler [DRS]) in upravljanje napajanja (ang. Distributed Power Management [DPM]). Prav tako omogoča pretvorbo fizičnega strežnika v virtualnega (ang. Physical-to-Virtual [P2V]) in virtualnega strežnika v nov virtualni strežnik (ang. Virtual-to-Virtual [V2V]). (OVM, 2016) OVM zagotavlja popolno kompatibilnost z Oraclovo podatkovno zbirko in z drugimi Oraclovimi izdelki. Poleg tega je (vsaj za zdaj) to edina virtualizacija, kjer Oracle pri licenciranju po številu procesorjev upošteva dejansko število procesorjev oziroma število jeder. Operacijski sistem je Oracle Linux. Gre za Oraclovo distribucijo Red Hat Enterprise Linux (RHEL). Linux je Oraclovo razvojno okolje. Prva verzija je zmeraj na voljo za Linux, prav tako vsi popravki. Zelo pomembna je tudi Linuxova skupnost, ki poleg Oracla nudi pomoč in podporo uporabnikom na Oraclovih straneh (Oracle Technology Network [OTN]). Verzija zbirke, ki jo uporabljamo, je 11.2.0.4. To je zadnja verzija, ki je bila na voljo, ko smo nameščali sedanje produkcijsko okolje. Fizično varovanje zagotavljamo z dnevnim kopiranjem podatkov (vroče kopiranje) na disk (RMAN), od tam pa na trak. Tako imamo na disku pripravljeno kopijo podatkovne zbirke prejšnjega dne. Istočasno so vse produkcijske zbirke v arhivskem načinu, torej lahko z vračanjem podatkov iz varnostne kopije in obnovitvenih

2 S črko P na začetku imena baze označujemo produkcijo.



stran 21

podatkov iz arhivskih datotek, obnovimo podatkovno zbirko do trenutka, ko bi ta odpovedala (ang. point-in-time recovery). Arhivske datoteke ravno tako kopiramo. Ker se lahko ob izrednih obdelavah zgodi, da se jih veliko nabere, smo uredili še posebno kopiranje samo arhivskih datotek. Po uspešnem kopiranju RMAN samodejno pobriše odvečne arhivske datoteke in sprosti zasedeni prostor. Logično varovanje zagotovljamo z dnevnim izvozom celotne podatkovne zbirke na disk (Oracle Data Pump). Hkrati s tem delamo tudi izvoz vseh objektov v obliki DDL, kar nam omogoča obnovo posameznega objekta brez uvoza. To pride v poštev seveda samo pri objektih, kot so paketi, procedure, prožilci ipd. Osnovni podatki o trenutnem okolju: Strojna oprema Gruča enoprocesorskih strežnikov HP DL380 G8 Diskovno polje IBM Storwize v7000 Virtualizacija Oracle VM 3.2 Operacijski sistem Oracle Linux Server release 6.5 Verzija podatkovne zbirke Oracle database 11.2.0.4 Fizično kopiranje RMAN – enkrat dnevno od ponedeljka do petka,

arhivske datoteke vsak dan; kopiranje na disk, od tam na trak

Logično kopiranje Export Data Pump – enkrat dnevno od ponedeljka do petka

4.2 KRITIČNA ANALIZA Trenutno stanje je z vidika zmogljivosti celotnega sistema načeloma zadovoljivo. Odzivnost podatkovne zbirke je zadovoljiva in redko kdaj se zgodi, da se uporabniki pritožujejo zaradi slabega odzivnega časa. Če se to zgodi, je razlog običajno v slabo napisanem poizvedovalnem stavku in z Oraclovim orodjem za uglaševanje poizvedovalnih stavkov, ki je del podatkovne zbirke, običajno najdemo rešitev. To je lahko nov indeks, popravljen indeks, popravljen izvajalni načrt (ang. execution plan) ali osvežitev statistike na tabelah in indeksih. Težavo predstavlja možna odpoved produkcijskega strežnika ali diskovnega podsistema zaradi napake na strojni opremi, ali pa odpoved zaradi napake operacijskega sistema. Če pride do odpovedi celotnega diskovnega podsistema, potem seveda obstane celotna produkcija. Napaka na enem disku ne predstavlja težave, saj je možna hitra zamenjava okvarjenega diska (ang. hot swap). Pri odpovedi celotnega podsistema pa je seveda treba počakati na njegovo popravilo ali zamenjavo.



stran 22

Po podatkih proizvajalca je povprečni čas med okvarama (MTBF) večji od 500.000 ur, z oceno, da lahko ta čas tudi preseže milijon ur.3 Letna stopnja napak (annualized failure rate [AFR] – verjetnost napake naprave ali njene komponente v enem letu delovanja) tako pri tem diskovnem podsistemu znaša 1,8 % (verjetnost, da pride do odpovedi v enem letu je 1,8-odstotna).4 Od tretjega do šestega leta delovanja pa ta verjetnost zraste na 6 do 8 odstotkov. Seveda ne govorimo o odpovedi celotnega podsistema, ampak njegovih komponent, ki pa vseeno povzročijo njegov izpad. (Sorewize V7000, 2016) Seveda določene odpovedi povzročijo samo nedosegljivost podatkovne zbirke, druge pa lahko povzročijo tudi okvaro podatkov. Tak primer je okvara strojne programske opreme (ang. firmware) ali hkratna odpoved diskov v enem diskovnem polju (ang. disk array) ali celotnega diskovnega polja. V takem primeru zastoja ne povzroča samo čas popravila okvarjenega podsistema, ampak seveda tudi čas, ki ga porabimo za restavriranje podatkovne zbirke. Na srečo naše zbirke niso prav velike. Podatkovni del produkcijske zbirke PRS zdaj zaseda približno 130 GB. Pa vendar bi ob večjih težavah uporabniki ostali brez podatkov ves dan. Uporabniki pa niso samo naši referenti, ampak tudi sodišča, notarji in tisti, ki preko spletnega vmesnika dostopajo do točke eVEM. V najboljšem primeru bi podatkovno zbirko lahko obnovili iz varnostne kopije na disku. Če pa gre za popolno odpoved diskovnega sistema, pa obnova zbirke ne zajema le podatkov, ampak tudi namestitev operacijskega in datotečnega sistema (ASM), namestitev Oraclove programske opreme ter kreiranje in obnova nove zbirke. Ker imamo varnostne kopije tudi na traku, to pomeni tudi porabo časa za vračanje varnostne kopije podatkovne zbirke s traku na disk. Vse to pa bi nam zagotovo vzelo več kot le nekaj ur. Podatki verjetno ne bi bilo dostopni vsaj dva delovna dneva. Tudi Oracle VM na žalost ne izpolnjuje vseh naših pričakovanj. Delovanje gruče je včasih nestabilno. Težave se pojavijo pri vsaki nadgradnji. Včasih se zatakne tudi pri živi migraciji (ang. live migration). Navidezni strežniki sicer delujejo še naprej, vendar jih OVM ne prenese z enega strežnika na drugega. Dodatno neprijetnost povzroča tudi dejstvo, da OVM sicer omogoča kloniranje strežnika, ne omogoča pa izdelave trenutnega posnetka (ang. snapshot). Ta funkcionalnost je zelo uporabna, sploh pri namestitvah novega strežnika, pri nadgradnjah in podobnih spremembah, ko lahko izdelava trenutnega posnetka pride prav, če se pri nameščanju kaj zalomi. Kloniranje strežnika je zelo zamudno

3 Vir: www.ibm.com/midmarket/it/it/att/pdf/GFL03080USEN.pdf 4

𝐴𝐹𝑅 =8760 [ℎ]

𝑀𝑇𝐵𝐹 [ℎ]× 100 Vir (formula): https://en.wikipedia.org/wiki/Annualized_failure_rate



stran 23

opravilo, ki lahko traja tudi kakšno uro, odvisno od velikosti strežnika, izdelava trenutnega posnetka pa vzame nekaj sekund ne glede na to, koliko je strežnik velik. Javanski vmesnik OVM je počasen in mestoma neroden. Počasnost je sicer pričakovana lastnost javanskih aplikacij, vendar pa vseeno moti. Zaradi težav z OVM in njegovo občasno nestabilnostjo ugotavljamo, da nam prestavlja kritično točko odpovedi (ang. single point of failure). Če odpove OVM, to pomeni zastoj na vseh produkcijskih zbirkah.



stran 24

5 PREOBLIKOVANJE OBSTOJEČEGA SISTEMA 5.1 POSODOBITEV STROJNE IN PROGRAMSKE OPREME Strojno opremo smo se odločili posodobiti: Strojna oprema Gruča dvoprocesorskih HP DL380 G8 Diskovno polje IBM Storwize v7000 Virtualizacija Microsoft Hyper-V Sever 2012 Operacijski sistem (test) Oracle Linux Server release 6.5

(produkcija) Oracle Linux Server release 7.2 Verzija podatkovne zbirke Oracle database 12.1.0.2 Delujoča kopija Data Guard Fizično kopiranje RMAN – enkrat dnevno od ponedeljka do petka,

arhivske datoteke vsak dan; kopiranje na disk, od tam na trak

Ker postavitev rezervnega centra zahteva dodatno strojno opremo, smo se seveda odločili kupiti nove strežnike za primarno stran. Diskovno polje ostaja isto. Zaradi nezadovoljstva z Oracle Virtual Machine (OVM) smo se odločili, da bomo novo okolje postavili na Microsoft Hyper-V Sever 2012. Glede na to, da smo se odločili kupiti Oraclove imenske licence (ang. named license), smo na neki način neodvisni od Oraclovega licenciranja. Hyper-V je hibriden hipernazdornik, ki je ena od funkcij Microsoftovega strežnika. Microsoft ga je prvič predstavil pri Windows Server 2008 in od takrat naprej je del operacijskega sistema. V osnovi je Microsoftov Hyper-V Server samostojna in okleščena verzija strežnika Windows, kjer je Microsoft odstranil vse, kar ni bistveno za virtualizacijo, njene storitve in grafični vmesnik (GUI). Ker je brez nepotrebnih okraskov, je tudi vzdrževanje lažje in hitrejše, pa tudi manj občutljiv je, saj manj komponent pomeni tudi manj nameščanja popravkov. (Microsoft, Hyper-V, 2016; Veeam, Hyper-V, 2016) Slika 4 v grobem prikazuje zgradbo Hyper-V. Hyper-V 2012 nam daje vse tisto, kar potrebujemo pri virtualizaciji. Najpomembnejša funkcija je zagotovo izdelava trenutnega posnetka, kar nam omogoča bistveno hitrejše nameščanje popravkov, saj ne izgubljamo časa z dolgotrajno izdelavo varnostne kopije.



stran 25

Slika 4: Zgradba Microsoft Hyper-V 2012 (vir: Veeam, Hyper-V, 2016)

Na testni strežnik smo se odločili namestiti Linux 6.5, saj je verzija 7.x šele dobro izšla. Glede na to, da v administracijo operacijskega sistema prinaša kar nekaj novosti, smo se odločili, da se ne bomo lovili z novitetami. Vendar pa bosta testna in produkcijska zbirka (TPRS in PPRS) zagotovo na verziji 7.2 (trenutno zadnja verzija). Pozitivne spremembe na tej verziji so vendarle takšne, da odtehtajo dodatno delo in učenje. Predvsem to velja za usklajenost operacijskega sistema s Hyper-V, ki se pozna predvsem v tem, da ni treba več nameščati posebnih gonilnikov in dodatno urejati sistemskih nastavitev.

5.2 POSTAVITEV TESTNEGA OKOLJA

5.2.1 Strežnik in operacijski sistem Najprej smo pripravili oba strežnika. Ker gre za testno okolje, smo zadostili več ali manj minimalnim zahtevam za namestitev Oraclove podatkovne zbirke (Slika 5). Poimenovali smo ju OraLinux in OraLinux2. Zapisano v nadaljevanju velja seveda za oba strežnika, čeprav je pisano v ednini.



stran 26

Slika 5: Konfiguracija strežnika na Hyper-V. Strežniku smo dodelili 4 GB delovnega pomnilnika, en procesor in dva diska (OraLinuxSys in OraLinuxASM). Prvi disk (/dev/sda) je velik 100 GB. Razdelili smo ga na dve particiji: boot (zagonska particija) in podatkovno particijo, ki je razdeljena na tri logične skupine (ang. logical group): swap (izmenjalna datoteka), logična skupina za operacijski sistem (root) in Oraclove izvršljive datoteke ter particija za varnostno kopijo, izvozne datoteke, skripte in podobno (orafiles). Zagonski particiji smo dodelili 1 GB prostora, preostalih 99 GB pa smo razdelili: izmenjalna datoteka 4 GB, sistemu in Oraclu 70 GB, preostalih 25 GB pa je namenjenih našim datotekam. Priklopna točka (ang. mount point) za ta disk je /orafiles. Drugi disk (/dev/sdb) je velik 25 GB in je v celoti namenjen Oraclu. Nanj smo namestili ASM, ki deluje kot nekakšen Oraclov interni datotečni sistem. Operacijski sistem ta disk zažene, vendar pa ga ne upravlja, kar se vidi, če diskovje pregledamo z ukazom »df«. Na spodnjih slikah (Slika 6, Slika 7 in Slika 8) vidimo grafično predstavljena diska sda in sdb. Slika 8 pokaže, da disk sdb za operacijski sistem sploh ni priklopljen, saj priklopne točke (ang. mount point) sploh ne vidi – zapisano je »Unmounted«.



stran 27

Vidimo tudi, da operacijski sistem ne vidi diska sdb kot del sistema in ga ne upravlja (Slika 9). To dela Oracle preko Automatic Storage Managementa (ASM).

Slika 6: Grafična predstavitev prvega diska (sda).

Slika 7: Zagonska particija (boot).



stran 28

Slika 8: Drugi disk (sdb), v celoti namenjen podatkovni zbirki, z nameščenim ASM.

Slika 9: Pregled diskov, na katerem ni drugega diska (sdb).

Po ureditvi diskovja smo namestili operacijski sistem Linux 6.5. V namestitev je vključeno grafično okolje (KDE), X-Windows (vse Oraclove namestitve tečejo preko grafičnega vmesnika), oracle-rdbms-server-11gR2-preinstall (naredi uporabnika oracle, skupino oinstall, uredi nekatere sistemske parametre), oracleasmlib (knjižnica za ASM) in kmod-oracleasm (modul jedra [ang. kernel module]). Vse te module je seveda možno namestiti tudi kasneje, ko je namestitev operacijskega sistema končana (yum install), vendar je tako hitreje.

Ko je nameščanje operacijskega sistema končano sledi konfiguriranje sistema in nameščanje in konfiguriranje protokolov in nekaterih orodij:

konfiguriranje omrežja – določanje naslova IP, omrežne maske, prehoda, strežnika DNS, požarnega zidu (iptables), posrednika (ang. proxy),



stran 29

konfiguriranje programa yum, s katerim prenašamo in nameščamo nova orodja oziroma nadgrajujemo operacijski sistem in že nameščeno programsko opremo,

konfiguriranje NTP (Network Time Protocol), ki poskrbi za točen čas na strežniku,

namestitev in konfiguracija SFTP (Secure FTP), namestitev in konfiguracija VNCServer, namestitev nekaterih orodij (tree, uncompress, banner, LVM, rlwrap).

Potem, ko je vse nameščeno, sledi ponovni zagon strežnika, da vidimo, ali je vse prav urejeno. Prav je tudi omeniti, da je treba določena orodja namestiti tudi na delovno postajo. Gre predvsem za:

VNC Viewer za delo preko Linuxovega grafičnega vmesnika, WinSCP za prenašanje datotek preko protokola SFTP (Secure FTP),

MobaXterm za delo z X-Windows.

5.2.2 Automatic Storage Management (ASM) Po ponovnem zagonu računalnika sledi namestitev Automatic Storage Managementa in njegova konfiguracija. Nameščamo ga z administratorskim uporabnikom (root) in orodjem oracleasm. Ker smo ASM namestili že med nameščanjem operacijskega sistema, knjižnice in drugih modulov za ASM ni treba več nameščati. Sicer bi to delali s programom yum (Yelowdog Updater, Modified), ki je na Red Hat Linuxu glavno orodje za nameščanje in nadgradnjo programskih paketov. Vsi programski paketi so spravljeni v uradnem Red Hatovem repozitoriju – za vsako verzijo Linuxa posebej. S tem Oracle zagotavlja, da so vsi popravki preizkušeni, tako da ne pride do neprijetnih presenečenj. (Red Hat, Yum, 2016) Najprej je treba pripraviti datoteko, v kateri navedemo pot do repozitorija. Vendar je v našem primeru to naredil že namestitveni program. Sicer moramo urediti datoteko

/etc/yum.conf.

Ročno bi tako morali namestiti: yum install kmod-oracleasm

yum install oracleasm-support

yum install oracleasmlib

Seveda bi morali predhodno narediti uporabnika oracle in skupino oinstall, urediti mape itn.



stran 30

[root@oralinux:~]$ fdisk /dev/sdb

...

Device Boot Start End Blocks Id System

ni podatkov o disku

...

Hex code (type L to list codes): 8e

Changed system type of partition 1 to 8e (Linux LVM)

Command (m for help): p

...


/dev/sdb1 1 3263 26210016 8e Linux LVM

Ker je vse to že urejeno, najprej pripravimo disk – particijo in datotečni sistem. Priloga 1 vsebuje podrobnejši izpis. Ko je disk pripravljen, moramo konfigurirati še ASMLib (gonilnik za ASM). Priloga 2 vsebuje podrobnejši izpis. Ko je gonilnik nameščen in ASM konfiguriran, sledi še kreiranje in urejanje diska. Diskovno skupino (ang. disk group) smo poimenovali DATA1. Običajno naredimo dve diskovni skupini: ASMCRS in DATA1. Prvo uporabimo za ASM, v katero Oracle namesti vse objekte, vezane na svoje delovanje, diskovna skupina DATA1 pa je namenjena objektom v podatkovni zbirki za vse podatkovne zbirke na določenem strežniku. Glede na to, da gre za testni strežnik, ki ga po opravljenem testu ne bomo več uporabljali, smo bili mnenja, da takšna delitev ni smiselna, saj ne vpliva na končne rezultate testa.

[root@oralinux:~]$ /etc/init.d/oracleasm configure

Configuring the Oracle ASM library driver.

...

[root@oralinux:~]$ /etc/init.d/oracleasm enable



...


[root@oralinux:~]$ /etc/init.d/oracleasm createdisk DATA1

/dev/sdb1

Creating Oracle ASM disk "DATA1" [OK]

[root@oralinux:~]$ /etc/init.d/oracleasm querydisk /dev/sdb1

Device "/dev/sdb1" is marked an ASM disk with the label "DATA1"

[root@oralinux:~]$ /etc/init.d/oracleasm listdisks

DATA1

[root@oralinux:~]$ /etc/init.d/oracleasm querydisk data1

Disk "DATA1" is a valid ASM disk



stran 31

5.2.3 Oracle Grid Infrastructure Če hočemo uporabljati Oracle ASM ali Oracle Restart, moramo najprej namestiti ustrezno infrastrukturo, ki jo Oracle imenuje Grid Infrastructure. Oracle Grid Infrastrucure (v nadaljevanju samo Grid) je Oraclova programska oprema, ki na samostojnem strežniku zagotavlja sistemsko podporo Oraclovi podatkovni zbirki, vključno z upravljanjem diskovja, datotečnega sistema in samodejnega zaganjanja. Grid, ki ga namestimo na samostojni strežnik, zajema obe funkcionalnosti – tako Oracle ASM kot Oracle Restart. Pri Oraclu so ju združili v enotno programsko opremo, ki jo namestimo na skupen osnovni (ang. home) direktorij za Oracle Grid Infrastructure. Grid moramo namestiti preden začnemo z nameščanjem Oraclove podatkovne zbirke. Najprej moramo ustvariti uporabnika posebej za Grid. Uporabnik oracle je namreč namenjen samo podatkovni zbirki. Izpis je v Priloga 3, zaradi prostora pa smo v

njem izpustili pozivnik ([root@oralinux:~]$).

Sledi nameščanje programske opreme, ki ga naredimo kot uporabnik grid. Vse namestitvene datoteke smo dali na direktorij /orainstall in jih tam razpakirali. Datoteke za grid so na /orainstall/grid. Pri tem določimo vse potrebne parametre: jezik (NLS), parametre diskovne skupine, določimo gesla, skupino za administratorja, operaterja in DBA itn. Pri določanju parametrov diskovne skupine lahko izberemo tudi način varovanja podatkov (redundanco). Glede na to, da imamo tovrstno varovanje urejeno na nivoju diskovnega podsistema, smo izbrali možnost »External«. Diskovno skupino znotraj ASM smo poimenovali DATA. Na spodnjih slikah (Slika 10 do Slika 20) je prikazano nameščanje Grida.

su - grid

cd /orainstall/grid

./runInstall



stran 32

Slika 10: Nameščanje Grida za samostojni strežnik

Slika 11: Grid - določanje parametrov NLS Program nam ponudi disk, ki smo ga ustvarili – DATA1, skupino pa poimenuje DATA (Slika 12).



stran 33

Določanje diskovne skupine – tukaj sicer za Grid določimo skupino ASMCRS, tokrat pa smo se odločili za eno skupino.

Slika 12: Grid - izbira diskovne skupine in določanje njenih prametrov

Slika 13: Grid - postavljanje gesel za sistemski račun



stran 34

Slika 14: Grid - določanje uporabniških skupin

Slika 15: Grid - določanje lokacije za programsko opremo (ORACLE_HOME)



stran 35

Slika 16: Grid - lokacija za oraInventory (dnevniške datoteke, začasne datoteke ...)

Slika 17: Grid - možnost zagona predpripravljenih skript



stran 36

Slika 18: Grid - zadnji pregled pred dokončno namestitvijo

Slika 19: Grid - nameščanje programske opreme



stran 37

Slika 20: Grid - čisto na koncu je treba zagnati še dva sistemska skripta Prvi skript uredi pravice za uporabnika grid, drugi pa postavi sistemske spremenljivke za Oracle Grid, uredi sistemske datoteke, postavi CRS (Cluster Ready Services) in namesti Oracle Restart. Podrobnejši opis je del priloge Priloga 4. S tem je nameščanje Oracle Automatic Storage Managementa končano.

5.2.4 Oracle DB Potem, ko smo namestili ASM, sledi nameščanje programske opreme, nato pa še ustvarjanje podatkovne zbirke. Nameščamo z uporabnikom oracle. Spodaj (Slika 21 do Slika 30) so prikazani koraki pri nameščanju podatkovne zbirke. [oracle@oralinux:/orainstall/database]$ ./runInstaller

Starting Oracle Universal Installer...

Checking Temp space: must be greater than 500 MB. Actual 55190 MB

Passed

Checking swap space: must be greater than 150 MB. Actual 7140 MB Passed

Checking monitor: must be configured to display at least 256 colors.

Actual 16777216 Passed



stran 38

Slika 21: DB - začetek nameščanja Oraclovega programja

Slika 22: DB - nameščamo samo program brez podatkovne zbirke



stran 39

Slika 23: DB - nameščamo samostojni strežnik

Slika 24: DB - urejanje NLS - dodajanje slovenščine.



stran 40

Slika 25: DB - nameščamo verzijo za večja podjetja (EE).

Slika 26: DB - določanje osnovnega direktorija (ORACLE_HOME)



stran 41

Slika 27: DB - določanje skupin z upravljavskimi pravicami

Slika 28: DB - pregled vseh sistemskih parametrov



stran 42

Slika 29: DB - pregled vseh sistemskih parametrov (2. del)

Slika 30: DB - pregled globalnih nastavitev pred končno namestitvijo



stran 43

Ko je namestitev končana, poženemo še sistemski skript root.sh, ki uredi sistemske spremenljivke.

5.2.5 Podatkovna zbirka Na koncu sledi še namestitev obeh podatkovnih zbirk, primarne in sekundarne. Pred namestitvijo smo morali urediti dve datoteki, ki urejata delo zbirke z omrežjem. To sta datoteki tnsnames.ora in listener.ora. Ko smo namestili Grid, smo z njim namestili tudi program za poslušanje (poslušalec, ang. listener). Vendar mora imeti podatkovna zbirka, ki dela v Data Guardu, svojega poslušalca. V datoteki tnsnames.ora pa uredimo povezave do različnih podatkovnih zbirk. Obe datoteki sta na lokaciji $ORACLE_HOME/network/admin. Najprej smo uredili datoteko listener.ora. Ker poslušalec na Gridu posluša na vratih 1521, smo poslušalca na zbirki usmerili na vrata 1522. Ime primarne podatkovne zbirke je DG1 (DG – Data Guard), sekundarna bo DG2. Poslušalca smo na obeh strežnikih poimenovali LISTENER_DG zaradi lažjega upravljanja. V datoteki listener.ora smo še določili poseben dostop DG1_DGMGRL oziroma DG2_DGMGRL za dostop posrednika, Data Guard Brokerja, do podatkovnih zbirk. Nato smo uredili še datoteko tnsnames.ora, v kateri so zapisani povezovalni nizi (ang. connect string) za dostop do posamezne zbirke. V prilogi Priloga 5 sta izpisani datoteki listener.ora in tnsnames.ora, ki odrejata delo poslušalca, in prikazan njegov zagon. Ko sta poslušalca zagnana, preverimo še dosegljivost obeh podatkovnih zbirk. To naredimo z ukazom tnsping.

$ tnsping dg1

...

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST =

oralinux.ajpes.si)(PORT = 1522)) (CONNECT_DATA = (SERVER = DEDICATED)

(SERVICE_NAME = DG1) (UR = A)))

OK (50 msec)

$ tnsping dg2

...



oralinux2.ajpes.si)(PORT = 1522)) (CONNECT_DATA = (SERVER = DEDICATED)


OK (40 msec)

Ko sta datoteki urejeni in poslušalec dela, lahko začnemo z ustvarjanjem podatkovne zbirke.



stran 44

To bomo naredili z Oraclovim orodjem dbca (Database Configuration Assistant). Na spodnjih slikah (Slika 31 do Slika 45) so prikazani koraki pri ustvarjanju podatkovne zbirke.

[oracle@oralinux:/]$ cd $ORACLE_HOME/bin

[oracle@oralinux:/u01/app/oracle/product/12.1.0.2/bin]$ ./dbca

Slika 31: DG - začetek ustvarjanja zbirke

Slika 32: DG - izberemo napredni način



stran 45

Slika 33: DG - izberemo predlogo

Slika 34: DG - določimo ime zbirke (DG1)



stran 46

Enterprise Manager je grafični vmesnik za nadzor in konfiguriranje podatkovne zbirke. Lahko ga namestimo tudi kasneje (Slika 35).

Slika 35: DG - orodje dbca uredi namestitev Enterprise Managerja (EM) za našo zbirko

Slika 36: DG - določitev skupnega gesla za administratorske sheme



stran 47

Izberemo poslušalca, ki smo ga že definirali in zagnali (Slika 37).

Slika 37: DG - izbira poslušalca

Vsi podatki bodo shranjeni na ASM (+DATA).

Slika 38: DG - določanje lokacij za objekte podatkovne zbirke (ASM)



stran 48

Slika 39: DG - možnost namestitve vzročnih shem (npr. SCOTT)

V desetem koraku (Slika 40 do Slika 43) določimo osnovne parametre: skupni pomnilniški prostor (System Global Area [SGA]) in pomnilniški prostor za uporabniški proces (Process Global Area [PGA]) ter največje število procesov na zbirki.

Slika 40: DG – določanje inicializacijskih parametrov (pomnilnik)



stran 49

Slika 41: DG – določanje inicializacijskih parametrov (velikost bloka, število procesov)

Na koncu določimo še kodno tabelo (UTF8), jezik in državo.

Slika 42: DG – določanje inicializacijskih parametrov (NLS - kodna tabela, jezik, država)



stran 50

Ustvarjanje zbirke se začne s pripravo skript in predloge. Oboje lahko uporabimo za pripravo nove zbirke, kar nam omogoči hitrejše delo in enotne parametre.

Slika 43: DG – pred zaključkom zbirka ustvari še skripte in predlogo Ustvarjanje podatkovne zbirke zajema pripravo datotek za zbirko, ustvarjanje ustrezne direktorijske strukture in zagonskih datotek ter zagon instance. Na koncu Oracle pripravi vse potrebno za samodejni zagon oziroma ugašanje baze – Oracle Restart (Slika 44 in Slika 45).



stran 51

Slika 44: DG – začetek ustvarjanja zbirke

Slika 45: DG – zaključek ustvarjanja zbirke



stran 52

Na koncu še pogledamo Oraclove procese ( Slika 46).

Slika 46: Oraclovi procesi – podatkovna zbirka, poslušalec, povezava z ASM

S tem je ustvarjanje primarne podatkovne zbirke zaključeno.

Na enak način smo uredili tudi drugi strežnik, ki smo ga poimenovali oralinux2. Ko sta bili obe zbirki (DG1 in DG2) pripravljeni, smo lahko začeli s konfiguriranjem Data Guarda.

5.2.6 Priprava direktorijev

Najprej smo morali urediti še direktorijsko strukturo za varnostno kopiranje, izvozne datoteke, skripta, obdelave.

Ta struktura je standardizirana: /orafiles/+ASM;

/orafiles/scripts/db_name; /orafiles/scripts/db_name/RMAN;

/orafiles/scripts/db_name/expdp; /orafiles/expdp/db_name;

/orafiles/scripts/logs;

/orafiles/obdelave/db_name;



stran 53

/orafiles/backup/db_name.

5.2.7 Priprava operacijskega sistema ter skript za administracijo, nadzor in vzdrževanje podatkovne zbirke

Po namestitvi podatkovne zbirke smo morali najprej urediti nekaj skript na nivoju operacijskega sistema:

/home/oracle/.bash_profile /etc/oratab /etc/inittab

/etc/init.d/oracle-rdbms /etc/security/limits.conf /etc/sysctl.conf

Poleg tega pa smo uredili tudi skripte za administracijo, nadzor in vzdrževanje zbirke. To so skripte za dviganje in spuščanje podatkovne zbirke, za varnostno kopiranje zbirke in arhivskih datotek (RMAN), za izvoz podatkov (Data Pump – expdp) itn. Urediti smo morali tudi nastavitve za varnostno kopiranje zbirke v programu RMAN.

5.2.8 Priprava podatkovne zbirke in uvoz podatkov Nameščeno primarno podatkovno zbirko smo morali pripraviti za uvoz podatkov. Naprej smo naredili vse tabelne prostore, ki so spodaj izpisani poudarjeno. Tablespace Status Total MB Datafile name

---------------------- --------- ---------- ----------------------------------------

AUDTBS ONLINE 16 +DATA/DG1/datafile/audtbs01.dbf

CRPDATA ONLINE 128 +DATA/DG1/datafile/crpdata01.dbf

CRPIDX ONLINE 96 +DATA/DG1/datafile/crpidx01.dbf

LDELDATA ONLINE 512 +DATA/DG1/datafile/ldeldata01.dbf

LDELIDX ONLINE 512 +DATA/DG1/datafile/ldelidx01.dbf

RPDATA ONLINE 64 +DATA/DG1/datafile/rpdata01.dbf

RPIDX ONLINE 16 +DATA/DG1/datafile/rpidx01.dbf

SERVISDATA ONLINE 512 +DATA/DG1/datafile/servisdata01.dbf

SYSAUX ONLINE 780 +DATA/DG1/DATAFILE/sysaux.264.913409255

SYSTEM ONLINE 790 +DATA/DG1/DATAFILE/system.525.913409411

TEMP ONLINE 87 +DATA/DG1/TEMPFILE/temp.523.913409649

UNDOTBS1 ONLINE 155 +DATA/DG1/DATAFILE/undotbs1.268.913409579

USERS ONLINE 5 +DATA/DG1/DATAFILE/users.524.913409577

VEMGD ONLINE 128 +DATA/DG1/datafile/vemgd01.dbf

VEMIDX ONLINE 128 +DATA/DG1/datafile/vemidx01.dbf

----------

Skupaj: 3929

Pripraviti smo morali vloge (ang. roles), uporabniške profile in ročno prenesti nekaj sistemskih procedur, ki smo jih naredili sami. Pomagali smo si z Dellovim orodjem Toad (prej Quest). Nato smo uredili še sezname za kontrolo dostopa (ang. Access Control List – ACL) za elektronsko pošto, za dostop preko protokola HTTP (internetne aplikacije) in za paket UTL_INADDR (Internet Address Package), ki omogoča internetno naslavljanje.



stran 54

V zbirki, ki uporablja Unicode (AL32UTF8), moramo pred uvozom podatkov obvezno nastaviti še parameter NLS_LENGTH_SEMANTICS. Ta parameter ima lahko vrednost »char« ali »byte«. Zadnja je privzeta. V tem primeru vsak znak zasede točno en bajt, kar pa pri posebnih znakih (recimo črkah neameriške abecede) povzroči težave, saj vsi zasedejo dva bajta (še bolj posebni znaki tudi tri ali štiri). Zato moramo obvezno ta parameter nastaviti na »char«, ko zbirka sama zasede toliko prostora, kot ga znak pač potrebuje. To smo naredili z ukazom:

alter system set NLS_LENGTH_SEMANTICS=char scope=both;

V tako pripravljeno primarno zbirko smo uvozili vse uporabniške sheme in podatke iz obstoječe razvojne zbirke (RPRS) z Oraclovim orodjem Data Pump (impdp). Uvoz zajema seveda tudi vse drugo – poglede, materializirane poglede, pakete, procedure, sekvence, sinonime, pravice, posle, povezave med podatkovnimi zbirkami (ang. database link) itn.

5.3 ORACLE DATA GUARD

5.3.1 Priprava podatkovne zbirke Pripravo Oracle Data Guarda bomo v nadaljevanju prikazali kar na praktičnem primeru. Delamo na primarni zbirki. Najprej pregledamo število obnovitvenih datotek. Oracle namreč zaradi varnosti priporoča, da ima vsaka skupina po tri obnovitvene datoteke. SELECT SUBSTR (v1.group#, 1, 3) GRP,

SUBSTR (MEMBER, 1, 20) MEMBER,

v1.archived ARCHIVED,

SUBSTR (v1.status, 1, 9) STATUS,

sequence#,

(BYTES / 1024) / 1024 MB

FROM v$log v1, v$logfile v2

WHERE v1.group# = v2.group#

ORDER BY v1.group#;

GRP MEMBER ARC STATUS SEQUENCE# MB

------------ ------------------------- --- ---------- ---------- ----------

1 +DATA/DG1/ONLINELOG/ NO INACTIVE 13 50




3 +DATA/DG1/ONLINELOG/ NO CURRENT 15 50


Ker imamo v vsaki skupini po dve datoteki, vsaki dodamo še eno. ALTER DATABASE ADD LOGFILE MEMBER '+DATA' TO GROUP 1;

ALTER DATABASE ADD LOGFILE MEMBER '+DATA' TO GROUP 2;

ALTER DATABASE ADD LOGFILE MEMBER '+DATA' TO GROUP 3;

ALTER SYSTEM SWITCH LOGFILE;



stran 55

GRP MEMBER ARC STATUS SEQUENCE# MB

------------ ------------------------- --- ---------- ---------- ----------







3 +DATA/DG1/ONLINELOG/ NO ACTIVE 15 50



Nato postavimo podatkovno zbirko v arhivski način. SQL> SELECT log_mode FROM v$database;

LOG_MODE

------------------------------------------------

NOARCHIVELOG

SQL> SHUTDOWN IMMEDIATE;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> STARTUP MOUNT EXCLUSIVE;

ORACLE instance started.

...

Database mounted.

SQL> ALTER DATABASE ARCHIVELOG;

Database altered.

SQL> ALTER DATABASE OPEN;

Database altered.

SQL> SELECT log_mode FROM v$database;

LOG_MODE

------------------------------------------------

ARCHIVELOG

SQL> ALTER DATABASE FORCE LOGGING;

Preverimo nastavitve.

SQL> select name, log_mode, open_mode, force_logging from v$database;

NAME LOG_MODE OPEN_MODE FOR

--------- ------------ -------------------- ---

DG1 ARCHIVELOG READ WRITE YES

Sledi nastavljanje parametrov podatkovne zbirke, potrebnih za delovanje Data Guarda. Gre za nastavitve, ki urejajo zapisovanje arhivskih datotek, določajo primarno vlogo zbirki DG1, nastavljajo asinhrono kopiranje arhivskih datotek na sekundarno lokacijo, omogočajo Data Guard Broker – proces, ki skrbi za samodejen prenos in nadzor nad obema zbirkama itn.



stran 56

alter system set log_archive_dest_1='LOCATION=+DATA/DG1/ARCHIVELOG/

VALID_FOR=(ALL_LOGFILES,ALL_ROLES)' scope=both;

alter system set log_archive_dest_2='service=DG2

valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=DG2 LGWR ASYNC

REOPEN=10' scope=both;

alter system set log_archive_dest_state_1='enable' scope=both;

alter system set log_archive_dest_state_2='enable' scope=both;

alter system set FAL_SERVER='DG2' scope=both;

alter system set FAL_CLIENT='DG1' scope=both;

alter system set dg_broker_start =TRUE scope=both;

alter system set standby_file_management='auto' scope=both;

alter system set log_archive_config ='DG_CONFIG=(DG1,DG2)' scope=both;

alter system set processes=900 scope=spfile;

alter system set sessions=995 scope=spfile;

alter system set remote_login_passwordfile=EXCLUSIVE scope=spfile;

alter system set DB_LOST_WRITE_PROTECT=TYPICAL scope=both;

alter system set local_listener=LISTENER_DG scope=both sid='*';

Ko smo nastavili vse parametre, na primarni strani zbirko spustimo in jo ponovno dvignemo. SQL> shutdown immediate

Database closed.



SQL> startup mount


...

Database mounted.

SQL> alter database open;

Database altered.

Preselimo se na rezervni strežnik in tam najprej nastavimo vse spremenljivke okolja. export ORACLE_HOME=/u01/app/oracle/product/12.1.0.2

export TNS_ADMIN=$ORACLE_HOME/network/admin

export PATH=$ORACLE_HOME/bin:$PATH

export ORACLE_SID=DG2

Nato pripravimo geselsko datoteko (ang. password file). Pri tem moramo paziti, da je sistemsko geslo na obeh zbirkah enako. orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=*** entries=5 force=y

Preverimo, ali strežnik posluša obe podatkovni zbirki.



stran 57

$ tnsping dg1

...



oralinux.ajpes.si)(PORT = 1522)) (CONNECT_DATA = (SERVER = DEDICATED)


OK (10 msec)

$ tnsping dg2

...



oralinux2.ajpes.si)(PORT = 1522)) (CONNECT_DATA = (SERVER = DEDICATED)


OK (40 msec)

Na zbirki preverimo in uredimo spremenljivko local_listener. SYS@DG2> show parameter local_listener

NAME TYPE VALUE

------------------------------------ ----------- ---------------------------

local_listener string LISTENER_DG2

SYS@DG2> alter system set local_listener=LISTENER_DG scope=both;

System altered.

Nato preverimo še nastavitev za parametrsko datoteko. Ta ne sme biti na ASM, ampak na lokalnem disku. SYS@DG2> show parameter pfile

NAME TYPE VALUE

------------------------------------ ----------- ---------------------------

spfile string +DATA/DG2/spfiledg2.ora

Ker je parametrska datoteka na ASM, jo moramo prestaviti na disk. Najprej naredimo na disku novo datoteko initDG2.ora, iz nje pa binarno datoteko spfileDG2.ora. Podatkovno zbirko spustimo, na gridu pobrišemo datoteko, ki je na ASM, in zbirko ponovno zaženemo. Celoten postopek je opisan v prilogi Priloga 6. Sekundarno podatkovno zbirko spustimo in jo zaženemo v stanju »nomount« (startup nomount). SYS@DG2> shutdown immediate

Database closed.



SYS@DG2> startup nomount


...

SYS@DG2> exit

Zdaj lahko začnemo s kloniranjem primarne zbirke in ustvarjanjem Data Guarda.



stran 58

Vse delamo na rezervnem strežniku. Delamo z RMAN-om in uporabnikom sys, ki ima na zbirki vse pravice. V prilogi Priloga 7 je celoten izpis kloniranja, v nadaljevanju so samo najpomembnejši deli. rman target=sys/*****@DG1 auxiliary=sys/*****@DG2

RMAN> duplicate target database to DG2 from active database nofilenamecheck;

RMAN najprej prenese in uredi kontrolno datoteko ter jo pripravi za sekundarno podatkovno zbirko. To pomeni nastavitev vseh parametrov za zbirko DG2 in priprava za prenos podatkovnih datotek. Ko je to narejeno, sledi prenos (kopiranje) primarne podatkovne zbirke in njena obnova na sekundarni strani – kot sekundarna podatkovna zbirka. Ko je urejena fizična struktura, sledi še obnova podatkov iz arhivskih datotek.

Starting restore at 08.10.15

sql statement: alter system archive log current

Starting recover at 08.10.15

starting media recovery

database opened

Finished Duplicate Db at 08.10.15

Po uspešnem kloniranju dodamo na obeh straneh, primarni in sekundarni, dodatne arhivske loge, namenjene zbirki v pripravljenosti. Kot vidimo na spodnji sliki (Slika 47) gre za prenos podatkov neposredno iz obnovitvene datoteke na primarni zbirki v obnovitveno datoteko na oddaljeni lokaciji. Podatki iz arhivske obnovitvene datoteke pa se prenašajo tako v arhivsko kot v obnovitveno datoteko. S tem Oracle poskrbi, da ne prihaja do vrzeli, če bi prenos odpovedal zaradi kakšne težave (npr. omrežje). Dodatne obnovitvene datoteke naredimo na obeh straneh, če pride do preklopa in se vloga podatkovnih zbirk zamenja. (Slika 47)

Slika 47: Prenos arhivov v dodatno (standby) datoteko (Vir: Oracle, Standby redo)



stran 59

Najprej naredimo obnovitvene datoteke na primarni zbirki. Celoten postopek je opisan v prilogi Priloga 8. alter database add standby logfile '+DATA/DG1/archivelog/srl1.log' size 50M;

alter database add standby logfile '+DATA/DG1/archivelog/srl2.log' size 50M;



Nato naredimo to isto še na sekundarni zbirki. alter database add standby logfile '+DATA/DG2/archivelog/srl1.log' size 50M;




Nato sekundarno zbirko postavimo v stanje pripravljenosti (ang. standby). SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Database altered.

SQL> SELECT database_role FROM v$database;

DATABASE_ROLE

----------------------------------------------------------------

PHYSICAL STANDBY

Končamo z obnovo sekundarne zbirke. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Database altered.

5.3.2 Priprava posrednika – Data Guard Broker

Naloga posrednika (Data Guard Broker) je logično povezati primarno zbirko s podatkovno zbirko v pripravljenosti (oziroma z več njimi, če jih imamo) v posredniško konfiguracijo, ki posredniku omogoča upravljanje in nadzor nad vsemi zbirkami in jih s tem povezuje v celoto. Konfiguracijo posrednika lahko upravljamo preko grafičnega orodja Oracle Enterprise Manager (OEM) ali preko vmesnika z ukazno vrstico (Data Guard command-line interface – DGMGRL). Konfiguracija posrednika je podrobneje prikazana v prilogi Priloga 9. dgmgrl /

DGMGRL> create configuration 'DG1Config' as

primary database is 'DG1'

connect identifier is DG1;

Pri konfiguriranju pride do napake, ker do prenosa arhivskih datotek še ni prišlo. Oracle je ponudil rešitev na svoji strani za podporo: Create Configuration Failing with ORA-16698 (Doc ID 1582179.1). Z njo smo svojo težavo rešili tudi mi. Izpeljali smo jo na obeh zbirkah.



stran 60

SQL> alter system set log_archive_dest_2='' scope=both sid='*';

Nadaljujemo v DGMGRL. DGMGRL> add database 'DG2' as connect identifier is DG2;

DGMGRL> enable configuration

5.3.3 Testiranje rešitve Ko smo uredili vse potrebno, smo morali seveda rešitev testirati. Testirali smo prenos transakcij, ali se zares vse, kar naredimo na primarni zbirki, prenese tudi na rezervno. Najprej smo naredili testnega uporabnika. CREATE USER DGTEST

IDENTIFIED BY <password>

DEFAULT TABLESPACE USERS

TEMPORARY TABLESPACE TEMP

PROFILE DEFAULT

ACCOUNT UNLOCK;

-- 1 Role for DGTEST

GRANT CONNECT TO DGTEST;

ALTER USER DGTEST DEFAULT ROLE ALL;

-- 10 System Privileges for DGTEST

GRANT ALTER SESSION TO DGTEST;

GRANT ALTER USER TO DGTEST;

GRANT CREATE PROCEDURE TO DGTEST;

GRANT CREATE SESSION TO DGTEST;

GRANT CREATE SYNONYM TO DGTEST;

GRANT CREATE TABLE TO DGTEST;

GRANT CREATE TRIGGER TO DGTEST;

GRANT CREATE TYPE TO DGTEST;

GRANT CREATE VIEW TO DGTEST;

GRANT DEBUG ANY PROCEDURE TO DGTEST;

-- 3 Tablespace Quotas for DGTEST

ALTER USER DGTEST QUOTA UNLIMITED ON USERS;

ALTER USER DGTEST QUOTA UNLIMITED ON VEMGD;

ALTER USER DGTEST QUOTA UNLIMITED ON VEMIDX;

Ko v zbirki pogledamo uporabnika, vidimo, da je narejen. Isto velja za rezervno zbirko. SYS@DG1> select username from dba_users where username like 'DG%';

USERNAME

----------------------------------------------------------------------

DGTEST

SYS@DG2> select username from dba_users where username like 'DG%';

USERNAME

----------------------------------------------------------------------

DGTEST



stran 61

Nato smo naredili tabelo t1 z dvema poljema. Tabelo je Data Guard preselil tudi na rezervno zbirko. DGTEST@DG1> create table t1 (a1 varchar2 (15), a2 number);

Table created.

SYS@DG1> select table_name from dba_tables where owner='DGTEST';

TABLE_NAME

---------------------------------------------------------------------------

T1

SYS@DG2> select table_name from dba_tables where owner='DGTEST';

TABLE_NAME

---------------------------------------------------------------------------

T1

Nato smo v tabelo zapisali dve vrstici. Ti dve vrstici sta se zapisali tudi na rezervno zbirko. SYS@DG1> insert into dgtest.t1 values ('TEST1',1);

1 row created.

SYS@DG1> insert into dgtest.t1 values ('TEST2',2);

1 row created.

SYS@DG1> commit;

Commit complete.

SYS@DG1> select * from dgtest.t1;

A1 A2

--------------- ----------

TEST1 1

TEST2 2


A1 A2

--------------------- ----------

TEST1 1

TEST2 2

Ugotovili smo, da Data Guard korektno prenaša vse spremembe iz primarne zbirke v sekundarno, tako tiste na ravni DDL kot tiste na ravni DML. Nato smo testirali še preklop med zbirkama (ang. switchover). DGMGRL> switchover to 'DG2';

Performing switchover NOW, please wait...

Operation requires a connection to instance "DG2" on database "DG2"



stran 62

Connecting to instance "DG2"...

Connected as SYSDBA.

New primary database "DG2" is opening...

Operation requires startup of instance "DG1" on database "DG1"

Starting instance "DG1"...


Database mounted.

Switchover succeeded, new primary is "DG2"

DGMGRL> show configuration;

Configuration - DG1Config

Protection Mode: MaxPerformance

Databases:

DG2 - Primary database

DG1 - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

Nato smo na novi primarni zbirki naredili nov vpis v zbirko t1 in pogledali prenos na novo rezervno zbirko. SYS@DG2> insert into dgtest.t1 values ('TEST3-DG2',3);

1 row created.

SYS@DG2> commit;

Commit complete.


A1 A2

---------------------------------------- ----------

TEST1 1

TEST2 2

TEST3-DG2 3


A1 A2

---------------------------------------- ----------

TEST1 1

TEST2 2

TEST3-DG2 3



stran 63

V prilogi Priloga 10 je celoten izpis nastavitev obeh instanc po preklopu.

DGMGRL> show database verbose 'DG1';

Database - DG1

Role: PHYSICAL STANDBY

Intended State: APPLY-ON

...

Database Status:

SUCCESS


Database - DG2

Role: PRIMARY

Intended State: TRANSPORT-ON

...

Database Status:

SUCCESS

Še pregled možnih neskladij v obeh zbirkah. DGMGRL> show database 'DG2' InconsistentProperties;

INCONSISTENT PROPERTIES

INSTANCE_NAME PROPERTY_NAME MEMORY_VALUE

SPFILE_VALUE BROKER_VALUE

DGMGRL> show database 'DG1' InconsistentProperties;




Neskladij v podatkovnih zbirkah ni. Na koncu testa smo podatkovni zbirki povrnili v začetno stanje. DGMGRL> switchover to 'DG1';

Performing switchover NOW, please wait...

Operation requires a connection to instance "DG1" on database "DG1"

Connecting to instance "DG1"...


New primary database "DG1" is opening...

Operation requires startup of instance "DG2" on database "DG2"

Starting instance "DG2"...


Database mounted.

Switchover succeeded, new primary is "DG1"




Databases:





stran 64



SUCCESS

Na koncu smo testirali še nadomestni način delovanja (ang. failover). Delali smo na sekundarni zbirki, ob predpostavki, da je primarna zbirka popolnoma odpovedala. DGMGRL> connect sys@dg2

Password:


DGMGRL> failover to 'DG2'

Performing failover NOW, please wait...

Failover succeeded, new primary is "DG2"




Databases:


DG1 - Physical standby database (disabled)

ORA-16661: the standby database needs to be reinstated



SUCCESS

Preklop med zbirkama je torej uspel. Glede na to, da je možnost »Fast-Start Failover« ves čas onemogočena, takšen preklop pomeni prekinitev kakršne koli sinhronizacije med primarno in sekundarno zbirko. Zato je treba po odpravi napake na primarnem strežniku oziroma zbirki, nekdanjo primarno zbirko obnoviti (ang. restore). DGMGRL> reinstate database 'DG1';

Reinstating database "DG1", please wait...

Error: ORA-16827: Flashback Database is disabled

Failed.

Reinstatement of database "DG1" failed

Zgornji poskus ponovne vzpostavitve nekdanje primarne zbirke je odpovedal. Če bi hoteli to narediti brez težav, bi morali omogočiti možnost »Fast-Start Failover«. DGMGRL> show database 'DG2' InconsistentProperties;




DGMGRL> show database 'DG1' InconsistentProperties;

Error: ORA-16548: database not enabled

Podatkovni zbirki sta nekonsistentni, saj zbirka DG1 sploh ni na voljo. Spodaj pa vidimo, da zbirka ni več v statusu »needs to be reinstated« (potrebna ponovna vzpostavitev), ampak je v statusu »needs to be re-created« (potrebna obnova).



stran 65




Databases:


DG1 - Physical standby database (disabled)

ORA-16795: the standby database needs to be re-created



SUCCESS

Tukaj smo testiranje prekinili, saj so se vse funkcionalnosti Oracle Data Guarda delovale zadovoljivo.



stran 66

6 ZAKLJUČKI 6.1 UGOTOVITVE Nobenega dvoma ni, da lahko podjetje s postavitvijo Oracle Data Guarda popolnoma zadosti potrebam po večji razpoložljivosti svojih podatkovnih zbirk. Čas preklopa je minimalen, tako da uporabniki tega skorajda ne občutijo. Najpomembneje pa je, da zaradi kopiranja obnovitvenih in arhivskih datotek ne pride do izgube podatkov. Dodana vrednost predlagane rešitve je v zanesljivem in v dobršni meri avtomatiziranem nadzoru delovanja baze in preklopa, če pride do napake. Tako je možnost za človeško napako izrazito zmanjšana. Predlagana rešitev je še posebej uporabna v podjetjih, ki hranijo veliko množino podatkov, recimo trgovska, farmacevtska, telekomunikacijska ipd. Pri takih podjetjih že kratek izpad podatkovne baze pomeni veliko finančno škodo. Ne samo zato, ker se do neke mere zaustavijo vsi ali skoraj vsi proizvodni procesi, ampak tudi zato, ker večina podjetij posluje tudi preko spleta. In če podatki tam niso dosegljivi, to lahko pomeni trajno izgubo stranke.

6.2 OCENA UČINKOV Učinke novega sistema smo analizirali z analizo SWOT (PSPN). Prednosti:

zagotavlja največjo možno razpoložljivost sistema,

delo administratorja je pri prehodu s primarne zbirke na sekundarno bodisi pri preklopu bodisi pri nadomestnem delovanju zmanjšano na najmanjšo možno mero,

z uporabo dodatnih obnovitvenih datotek (ang. standby redo log) je nevarnost izgube podatkov zmanjšana na najmanjšo možno mero,

možnost uporabe zbirke v pripravljenosti za naloge, ki zahtevajo veliko sistemskih virov,

Data Guard podpira raznovrstne konfiguracije, saj ni nujno, da sta primarni sistem in sistem v pripravljenosti identična (različni procesorji, različni operacijski sistemi, različna bitnost operacijskih sistemov).

Slabosti:

če pride na podatkovni povezavi med primarno in sekundarno zbirko do prenaročnine (ang. oversubscription), se obnovitvene datoteke ne prenašajo v kronološkem vrstnem redu, kar povzroči velike vrzeli, tako da podatkovna zbirka v pripravljenosti ni istovetna s primarno zbirko,

verzija Oraclove programske opreme mora biti na primarni in sekundarni strani ista,



stran 67

Oracle Data Guard lahko uporabljamo le, če namestimo podatkovno zbirko za podjetja (Oracle Database Enterprise Edition),

uporaba Oracle Data Guarda pomeni nakup dodatnih licenc, priprava in ureditev rezervnega centra, ki zajema prostor (lasten ali najem),

opremo rezervnega centra (klima, omrežne naprave), dodatni strežniki in dodaten diskovni podsistem.

Priložnosti:

preizkušeno rešitev lahko uporabimo na vseh ključnih podatkovnih zbirkah, proaktivno odzivanje ob zaznavanju možnih težav, doseganje cilja – dostopnost podatkov 24/7.

Nevarnosti:

na začetku lahko premalo izkušenj povzroči daljši odzivni čas človeka, kadrovska nedohranjenost – to področje zaradi svoje obsežnosti zahteva več

ljudi, ki se lahko pokrivajo.

6.3 POGOJI ZA UVEDBO Uvedba takšne rešitve zahteva predvsem podporo vodstva. To mora takšno odločitev podpreti tudi finančno in odobriti potrebna sredstva tako za strojno opremo kot za dodatne licence za podatkovno zbirko. S tehničnega vidika potrebujemo rezervni center. V njem moramo namestiti dodatno strojno opremo, ki ustreza zahtevam (strežniki, diskovni podsistem). Dodatni strežniki in diskovni podsistem so seveda tudi odjemalci na brezprekinitvenem napajanju (UPS), kar je tudi potrebno upoštevati. S finančnega vidika moramo upoštevati sredstva za nakup novih strežnikov, diskovnega podsistema ali nadgradnjo obstoječe opreme. Oracle zahteva licenciranje tako primarne kot sekundarne podatkovne zbirke. Znano pa je, da Oraclove licence niso poceni, zato potrebujemo ljudi, ki bodo znali izpogajati primerno ceno. S kadrovskega vidika potrebujemo ljudi, ki že obvladujejo administriranje Oraclove podatkovne zbirke. Dodatnega izobraževanja za Oracle Data Guard ne potrebujemo. Delo na testnem okolju nam je prepričljivo pokazalo, da je rešitev zelo učinkovita in da zagotovo pripomore k večji razpoložljivosti in varnosti podatkov.



stran 68

PRILOGE Priloga 1: Priprava diska [root@oralinux:~]$ fdisk /dev/sdb

...


Disk /dev/sdb: 26.8 GB, 26843545600 bytes

255 heads, 63 sectors/track, 3263 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x000329a7


Command (m for help): n

Command action

e extended

p primary partition (1-4)

p

Partition number (1-4): 1

First cylinder (1-3263, default 1):

Using default value 1

Last cylinder, +cylinders or +size{K,M,G} (1-3263, default 3263):

Using default value 3263x

Command (m for help): t

Selected partition 1

Hex code (type L to list codes): 8e

Changed system type of partition 1 to 8e (Linux LVM)


Disk /dev/sdb: 26.8 GB, 26843545600 bytes

255 heads, 63 sectors/track, 3263 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x000329a7


/dev/sdb1 1 3263 26210016 8e Linux LVM

Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table.

Syncing disks.

Priloga 2: Konfiguracija Oracle ASM [root@oralinux:~]$ oracleasm help

Usage: oracleasm [--exec-path=<exec_path>] <command> [ <args> ]

oracleasm --exec-path

oracleasm -h

oracleasm -V



stran 69

The basic oracleasm commands are:

configure Configure the Oracle Linux ASMLib driver

init Load and initialize the ASMLib driver

exit Stop the ASMLib driver

scandisks Scan the system for Oracle ASMLib disks

status Display the status of the Oracle ASMLib driver

listdisks List known Oracle ASMLib disks

querydisk Determine if a disk belongs to Oracle ASMlib

createdisk Allocate a device for Oracle ASMLib use

deletedisk Return a device to the operating system

renamedisk Change the label of an Oracle ASMlib disk

update-driver Download the latest ASMLib driver

[root@oralinux:~]$



This will configure the on-boot properties of the Oracle ASM library

driver. The following questions will determine whether the driver is

loaded on boot and what permissions it will have. The current values

will be shown in brackets ('[]'). Hitting without typing an

answer will keep that current value. Ctrl-C will abort.

Default user to own the driver interface []: oracle

Default group to own the driver interface []: dba

Start Oracle ASM library driver on boot (y/n) [n]: y

Fix permissions of Oracle ASM disks on boot (y/n) [y]: y

Writing Oracle ASM library driver configuration [OK]

Creating /dev/oracleasm mount point [OK]

Loading module "oracleasm" [OK]

Mounting ASMlib driver filesystem [OK]

Scanning system for ASM disks [OK]

[root@oralinux:~]$


Writing Oracle ASM library driver configuration [OK]

Loading module "oracleasm" [OK]

Mounting ASMlib driver filesystem [OK]

Scanning system for ASM disks [OK]

Priloga 3: Ustvarjanje uporabnika grid in priprava direktorijske strukture /usr/sbin/useradd -u 54322 -g oinstall -G dba grid

mkdir -p /u01/app/grid

mkdir -p /u01/app/oracle

chown grid:oinstall /u01/app/grid

chown oracle:oinstall /u01/app/oracle

chmod -R 775 /u01/

chown -R grid:oinstall /u01

/usr/sbin/groupadd -g 54324 oper

/usr/sbin/groupadd -g 54331 asmadmin

/usr/sbin/groupadd -g 54332 asmdba

/usr/sbin/groupadd -g 54333 asmoper

usermod -G dba,oper,asmadmin,asmdba oracle

usermod -G dba,asmadmin,asmdba,asmoper grid

passwd grid

********



stran 70

Priloga 4: Dokončanje namestitve Oracle Grida [root@oralinux:~]$ /u01/app/oraInventory/orainstRoot.sh

Changing permissions of /u01/app/oraInventory.

Adding read,write permissions for group.

Removing read,write,execute permissions for world.

Changing groupname of /u01/app/oraInventory to oinstall.

The execution of the script is complete.

[root@oralinux:~]$

[root@oralinux:~]$ /u01/app/grid/product/12.1.0/grid/root.sh

Performing root user operation.

The following environment variables are set as:

ORACLE_OWNER= grid

ORACLE_HOME= /u01/app/grid/product/12.1.0/grid

Enter the full pathname of the local bin directory: [/usr/local/bin]:

The contents of "dbhome" have not changed. No need to overwrite.

The contents of "oraenv" have not changed. No need to overwrite.

The contents of "coraenv" have not changed. No need to overwrite.

Creating /etc/oratab file...

Entries will be added to the /etc/oratab file as needed by

Database Configuration Assistant when a database is created

Finished running generic part of root script.

Now product-specific root actions will be performed.

Using configuration parameter file:

/u01/app/grid/product/12.1.0/grid/crs/install/crsconfig_params

LOCAL ADD MODE

Creating OCR keys for user 'grid', privgrp 'oinstall'..

Operation successful.

LOCAL ONLY MODE

Successfully accumulated necessary OCR keys.

Creating OCR keys for user 'root', privgrp 'root'..

Operation successful.

CRS-4664: Node oralinux successfully pinned.

2015/09/22 12:19:42 CLSRSC-330: Adding Clusterware entries to file 'oracle-

ohasd.conf'

oralinux 2015/09/22 12:20:03

/u01/app/grid/product/12.1.0/grid/cdata/oralinux/backup_20150922_122003.olr

0

CRS-2791: Starting shutdown of Oracle High Availability Services-managed

resources on 'oralinux'

CRS-2673: Attempting to stop 'ora.evmd' on 'oralinux'

CRS-2677: Stop of 'ora.evmd' on 'oralinux' succeeded

CRS-2793: Shutdown of Oracle High Availability Services-managed resources on

'oralinux' has completed

CRS-4133: Oracle High Availability Services has been stopped.

CRS-4123: Oracle High Availability Services has been started.

2015/09/22 12:24:15 CLSRSC-327: Successfully configured Oracle Restart for a

standalone server

Za konec lahko še pregledamo procese, v potrditev, da je vse kot je treba. [root@oralinux:~]$ ps -ef

UID PID PPID C STIME TTY TIME CMD

grid 2933 1 0 2015 ? 1-07:25:41

/u01/app/grid/product/12.1.0/grid/bin/oraagent.bin



stran 71

grid 2948 1 0 2015 ? 15:58:46

/u01/app/grid/product/12.1.0/grid/bin/evmd.bin

grid 2952 1 0 2015 ? 00:06:31

/u01/app/grid/product/12.1.0/grid/bin/tnslsnr LISTENER -no_crs_notify -

inherit

grid 2971 2948 0 2015 ? 15:51:40

/u01/app/grid/product/12.1.0/grid/bin/evmlogger.bin -o

/u01/app/grid/product/12.1.0/grid/log/[HOSTNAME]/evmd/evmlogger.info -l

/u01/a

grid 2978 1 0 2015 ? 17:23:14

/u01/app/grid/product/12.1.0/grid/bin/cssdagent

grid 3003 1 0 2015 ? 16:35:53

/u01/app/grid/product/12.1.0/grid/bin/ocssd.bin

grid 3035 1 0 2015 ? 00:24:01 asm_pmon_+ASM

grid 3037 1 0 2015 ? 01:17:01 asm_psp0_+ASM

grid 3041 1 2 2015 ? 6-00:55:10 asm_vktm_+ASM

grid 3045 1 54 2015 ? 133-11:20:01 asm_gen0_+ASM

grid 3047 1 0 2015 ? 00:09:09 asm_mman_+ASM

grid 3051 1 0 2015 ? 00:16:51 asm_diag_+ASM

grid 3053 1 0 2015 ? 02:10:33 asm_dia0_+ASM

grid 3055 1 0 2015 ? 00:09:08 asm_dbw0_+ASM

grid 3057 1 0 2015 ? 00:09:30 asm_lgwr_+ASM

grid 3059 1 0 2015 ? 00:18:01 asm_ckpt_+ASM

grid 3061 1 0 2015 ? 00:07:50 asm_smon_+ASM

grid 3063 1 0 2015 ? 00:09:55 asm_lreg_+ASM

grid 3065 1 0 2015 ? 00:08:05 asm_pxmn_+ASM

grid 3067 1 0 2015 ? 00:28:41 asm_rbal_+ASM

grid 3069 1 0 2015 ? 01:04:05 asm_gmon_+ASM

grid 3071 1 0 2015 ? 00:24:59 asm_mmon_+ASM

grid 3073 1 0 2015 ? 00:49:29 asm_mmnl_+ASM

grid 3086 1 0 2015 ? 00:00:35 oracle+ASM

(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

grid 3123 1 0 2015 ? 00:05:58 asm_asmb_+ASM

grid 3125 1 0 2015 ? 00:21:12 oracle+ASM_asmb_+asm

(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

Priloga 5: Mrežne nastavitve za SQL*Net (listener.ora in tnsnames.ora) in zagon poslušalca

$ cd $ORACLE_HOME/network/admin

$ cat listener.ora

# listener.ora Network Configuration File:

/u01/app/oracle/product/12.1.0.2/network/admin/listener.ora

# Generated by Oracle configuration tools.

LISTENER_DG =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = oralinux.ajpes.si)(PORT = 1522))

(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1522))

)

)

SID_LIST_LISTENER_DG=

(SID_LIST=

(SID_DESC=

(GLOBAL_DBNAME=DG1)

(ORACLE_HOME=/u01/app/oracle/product/12.1.0.2)



stran 72

(SID_NAME=DG1))

(SID_DESC=

(GLOBAL_DBNAME=DG1_DGMGRL)


(SID_NAME=DG1))

(SID_DESC=

(SID_NAME=plsextproc)


(PROGRAM=extproc)))

ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON

VALID_NODE_CHECKING_REGISTRATION_LISTENER=SUBNET

#### Sledi zagon poslušalca.

$ lsnrctl start listener_dg

...

Starting /u01/app/oracle/product/12.1.0.2/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 12.1.0.1.0 - Production

System parameter file is


Log messages written to

/u01/app/oracle/diag/tnslsnr/oralinux/listener_dg/alert/log.xml

Listening on:

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oralinux.ajpes.si)(PORT=1522)))

Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1522)))

Connecting to

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oralinux.ajpes.si)(PORT=1522)))

STATUS of the LISTENER

------------------------

Alias listener_dg

Version TNSLSNR for Linux: Version 12.1.0.1.0 – Production

Start Date 01-JUN-2016 19:50:54

Uptime 0 days 0 hr. 0 min. 0 sec

Trace Level off

Security ON: Local OS Authentication

SNMP OFF

Listener Parameter File


Listener Log File

/u01/app/oracle/diag/tnslsnr/oralinux/listener_dg/alert/log.xml

Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oralinux.ajpes.si)(PORT=1522)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1522)))

Services Summary...

Service "DG1" has 1 instance(s).

Instance "DG1", status UNKNOWN, has 1 handler(s) for this service...

Service "DG1_DGMGRL" has 1 instance(s).

Instance "DG1", status UNKNOWN, has 1 handler(s) for this service...

Service "plsextproc" has 1 instance(s).

Instance "plsextproc", status UNKNOWN, has 1 handler(s) for this

service...

The command completed successfully

$ cat tnsnames.ora

# tnsnames.ora Network Configuration File:

/u01/app/oracle/product/12.1.0.2/network/admin/tnsnames.ora

# Generated by Oracle configuration tools.

LISTENER_DG =




stran 73

DG2 =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = oralinux2.ajpes.si)(PORT = 1522))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = DG2)

(UR = A)

)

)

DG1 =

(DESCRIPTION =


(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = DG1)

(UR = A)

)

)

Priloga 6: Prenos parametrske datoteke z ASM na disk. SYS@DG2> create pfile from spfile;

File created.

SYS@DG2> create spfile='/u01/app/oracle/product/12.1.0.2/dbs/spfileDG2.ora'

2 from pfile='/u01/app/oracle/product/12.1.0.2/dbs/initDG2.ora';

File created.

SYS@DG2> shutdown immediate

Database closed.



SYS@DG2> exit

[oracle@oralinux2:/u01/app/oracle/product/12.1.0.2/dbs]$ ll initDG2.ora

spfileDG2.ora

-rw-r----- 1 oracle oinstall 1.1K Jun 3 13:58 initDG2.ora

-rw-r----- 1 oracle asmadmin 3.5K Jun 3 14:17 spfileDG2.ora

[oracle@oralinux2:/u01/app/oracle/product/12.1.0.2/dbs]$ su - grid

Password: ******

You are logged in as: grid

[grid@oralinux2:~]$ asmcmd

ASMCMD [+] > cd data

ASMCMD [+data] > cd DG2

ASMCMD [+data/DG2] > ls

ARCHIVELOG/

CONTROLFILE/

DATAFILE/

ONLINELOG/

PARAMETERFILE/

TEMPFILE/

spfileDG2.ora

ASMCMD [+data/DG2] > rm spfileDG2.ora

ASMCMD [+data/DG2] > ls

ARCHIVELOG/



stran 74

CONTROLFILE/

DATAFILE/

ONLINELOG/

TEMPFILE/

ASMCMD [+data/DG2] > exit

[grid@oralinux2:~]$ exit

logout

[oracle@oralinux2:/u01/app/oracle/product/12.1.0.2/dbs]$ sdba

SQL*Plus: Release 12.1.0.1.0 Production on Pet Jun 3 14:16:42 2016

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Connected to an idle instance.

SYS@DG2> startup


...

Database mounted.

Database opened.

SYS@DG2> show parameter spfile

NAME TYPE VALUE

------------------- ----------- ------------------------------

spfile string /u01/app/oracle/product/12.1.0

.2/dbs/spfileDG2.ora

Priloga 7: Kloniranje sekundarne podatkovne zbirke (DG2)

rman target=sys/*****@DG1 auxiliary=sys/*****@DG2

Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights

reserved.

connected to target database: DG1 (DBID=1873847937)

connected to auxiliary database: DG2 (not mounted)

RMAN> duplicate target database to DG2 from active database nofilenamecheck;

Starting Duplicate Db at 08.10.15

using target database control file instead of recovery catalog

allocated channel: ORA_AUX_DISK_1

channel ORA_AUX_DISK_1: SID=25 device type=DISK

current log archived

contents of Memory Script:

{

sql clone "alter system set control_files =

''+DATA/DG2/CONTROLFILE/current.262.892563251'',

''+DATA/DG2/CONTROLFILE/current.284.892563251'' comment=

''Set by RMAN'' scope=spfile";

sql clone "alter system set db_name =

''DG1'' comment=

''Modified by RMAN duplicate'' scope=spfile";

sql clone "alter system set db_unique_name =

''DG2'' comment=

''Modified by RMAN duplicate'' scope=spfile";

shutdown clone immediate;

startup clone force nomount

restore clone from service 'DG1' primary controlfile;



stran 75

alter clone database mount;

}

executing Memory Script

sql statement: alter system set control_files =

''+DATA/DG2/CONTROLFILE/current.262.892563251'',

''+DATA/DG2/CONTROLFILE/current.284.892563251'' comment= ''Set by RMAN''

scope=spfile

sql statement: alter system set db_name = ''DG1'' comment= ''Modified by

RMAN duplicate'' scope=spfile

sql statement: alter system set db_unique_name = ''DG2'' comment=

''Modified by RMAN duplicate'' scope=spfile

Oracle instance shut down

Oracle instance started

Total System Global Area 1169149952 bytes

Fixed Size 2287624 bytes

Variable Size 637536248 bytes

Database Buffers 520093696 bytes

Redo Buffers 9232384 bytes


allocated channel: ORA_AUX_DISK_1

channel ORA_AUX_DISK_1: SID=26 device type=DISK

channel ORA_AUX_DISK_1: starting datafile backup set restore

channel ORA_AUX_DISK_1: using network backup set from service DG1

channel ORA_AUX_DISK_1: restoring control file

channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:04

output file name=+DATA/DG2/CONTROLFILE/current.262.892563251

output file name=+DATA/DG2/CONTROLFILE/current.284.892563251

Finished restore at 08.10.15

database mounted

RMAN-05529: WARNING: DB_FILE_NAME_CONVERT resulted in invalid ASM names;

names changed to disk group only.


{

set newname for datafile 1 to

"+DATA";


"+DATA/DG2/DATAFILE/audtbs01.dbf";


"+DATA";


"+DATA";


"+DATA/DG2/DATAFILE/vemgd01.dbf";


"+DATA";


"+DATA/DG2/DATAFILE/vemidx01.dbf";

restore

from service 'DG1' clone database

;

sql 'alter system archive log current';



stran 76

}


executing command: SET NEWNAME








using channel ORA_AUX_DISK_1



channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_AUX_DISK_1: restoring datafile 00001 to +DATA





channel ORA_AUX_DISK_1: restoring datafile 00002 to

+DATA/DG2/DATAFILE/audtbs01.dbf
















+DATA/DG2/DATAFILE/vemgd01.dbf











+DATA/DG2/DATAFILE/vemidx01.dbf



sql statement: alter system archive log current

current log archived



stran 77


{

restore clone force from service 'DG1'

archivelog from scn 1869985;

switch clone datafile all;

}




channel ORA_AUX_DISK_1: starting archived log restore to default destination


channel ORA_AUX_DISK_1: restoring archived log

archived log thread=1 sequence=13


channel ORA_AUX_DISK_1: starting archived log restore to default destination


channel ORA_AUX_DISK_1: restoring archived log

archived log thread=1 sequence=14



datafile 1 switched to datafile copy

input datafile copy RECID=8 STAMP=892563317 file

name=+DATA/DG2/DATAFILE/system.280.892563277



name=+DATA/DG2/DATAFILE/audtbs01.dbf



name=+DATA/DG2/DATAFILE/sysaux.282.892563295



name=+DATA/DG2/DATAFILE/undotbs1.285.892563309



name=+DATA/DG2/DATAFILE/vemgd01.dbf



name=+DATA/DG2/DATAFILE/users.286.892563311



name=+DATA/DG2/DATAFILE/vemidx01.dbf


{

set until scn 1870198;

recover

clone database

delete archivelog

;

}


executing command: SET until clause

Starting recover at 08.10.15


starting media recovery



stran 78

archived log for thread 1 with sequence 13 is already on disk as file

+DATA/dg2/archivelog/1_13_892480324.dbf

archived log for thread 1 with sequence 14 is already on disk as file

+DATA/dg2/archivelog/1_14_892480324.dbf

archived log file name=+DATA/dg2/archivelog/1_13_892480324.dbf thread=1

sequence=13

archived log file name=+DATA/dg2/archivelog/1_14_892480324.dbf thread=1

sequence=14

media recovery complete, elapsed time: 00:00:00

Finished recover at 08.10.15








{

sql clone "alter system set db_name =

''DG2'' comment=

''Reset to original value by RMAN'' scope=spfile";

sql clone "alter system reset db_unique_name scope=spfile";

}


sql statement: alter system set db_name = ''DG2'' comment= ''Reset to

original value by RMAN'' scope=spfile

sql statement: alter system reset db_unique_name scope=spfile







sql statement: CREATE CONTROLFILE REUSE SET DATABASE "DG2" RESETLOGS

ARCHIVELOG

MAXLOGFILES 16

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 8

MAXLOGHISTORY 292

LOGFILE

GROUP 1 ( '+DATA', '+DATA' ) SIZE 50 M REUSE,

GROUP 2 ( '+DATA', '+DATA' ) SIZE 50 M REUSE,

GROUP 3 ( '+DATA', '+DATA' ) SIZE 50 M REUSE

DATAFILE

'+DATA/DG2/DATAFILE/system.280.892563277'

CHARACTER SET AL32UTF8


{

set newname for tempfile 1 to

"+DATA";

switch clone tempfile all;



stran 79

catalog clone datafilecopy "+DATA/DG2/DATAFILE/audtbs01.dbf",

"+DATA/DG2/DATAFILE/sysaux.282.892563295",

"+DATA/DG2/DATAFILE/undotbs1.285.892563309",

"+DATA/DG2/DATAFILE/vemgd01.dbf",

"+DATA/DG2/DATAFILE/users.286.892563311",

"+DATA/DG2/DATAFILE/vemidx01.dbf";

switch clone datafile all;

}



renamed tempfile 1 to +DATA in control file

cataloged datafile copy

datafile copy file name=+DATA/DG2/DATAFILE/audtbs01.dbf RECID=1

STAMP=892563341


datafile copy file name=+DATA/DG2/DATAFILE/sysaux.282.892563295 RECID=2

STAMP=892563341


datafile copy file name=+DATA/DG2/DATAFILE/undotbs1.285.892563309 RECID=3

STAMP=892563341


datafile copy file name=+DATA/DG2/DATAFILE/vemgd01.dbf RECID=4

STAMP=892563341


datafile copy file name=+DATA/DG2/DATAFILE/users.286.892563311 RECID=5

STAMP=892563341


datafile copy file name=+DATA/DG2/DATAFILE/vemidx01.dbf RECID=6

STAMP=892563341



name=+DATA/DG2/DATAFILE/audtbs01.dbf



name=+DATA/DG2/DATAFILE/sysaux.282.892563295



name=+DATA/DG2/DATAFILE/undotbs1.285.892563309



name=+DATA/DG2/DATAFILE/vemgd01.dbf



name=+DATA/DG2/DATAFILE/users.286.892563311



name=+DATA/DG2/DATAFILE/vemidx01.dbf

Reenabling controlfile options for auxiliary database

Executing: alter database force logging


{

Alter clone database open resetlogs;

}


database opened

Finished Duplicate Db at 08.10.15



stran 80

Priloga 8: Dodatne obnovitvene datoteke na obeh zbirkah

Primarna zbirka DG1:

SQL> alter database add standby logfile '+DATA/DG1/archivelog/srl1.log' size

50M;

Database altered.


50M;

Database altered.


50M;

Database altered.


50M;

Database altered.

Sekundarna zbirka DG2:





Database altered.

SQL>

Database altered.

SQL>

Database altered.

SQL>

Database altered.

Priloga 9: Nastavitev posrednika (DG Broker) dgmgrl /

DGMGRL> create configuration 'DG1Config' as

primary database is 'DG1'

> connect identifier is DG1;

Configuration "DG1Config" created with primary database "DG1"

DGMGRL> add database 'DG2' as connect identifier is DG2;

Error: ORA-16698: LOG_ARCHIVE_DEST_n parameter set for object to be added

Rešitev napake:

SQL> alter system set log_archive_dest_2='' scope=both sid='*';

System altered.



stran 81

SQL> show parameter log_archive_dest_2

NAME TYPE VALUE

-------------------- --------- ---------

log_archive_dest_2 string

Nadaljevanje: DGMGRL> connect sys

Password:

Connected as SYSDG.




Databases:




DISABLED

DGMGRL> add database 'DG2' as connect identifier is DG2;

Database "DG2" added

DGMGRL> show configuration



Databases:





DISABLED

DGMGRL> enable configuration

Enabled.

DGMGRL> show configuration



Databases:





SUCCESS

DGMGRL> show database 'DG1'



stran 82

Database - DG1

Role: PRIMARY


Instance(s):

DG1

Database Status:

SUCCESS

DGMGRL> show database 'DG2'

Database - DG2



Transport Lag: 0 seconds (computed 0 seconds ago)

Apply Lag: 0 seconds (computed 0 seconds ago)

Apply Rate: 8.93 MByte/s

Real Time Query: OFF

Instance(s):

DG2

Database Status:

SUCCESS

Priloga 10: Pregled obeh instanc preko ukazne vrstice posrednika (DG Broker) DGMGRL> show database verbose 'DG1';

Database - DG1



Transport Lag: 0 seconds (computed 0 seconds ago)

Apply Lag: 0 seconds (computed 0 seconds ago)

Apply Rate: 460.00 KByte/s

Real Time Query: OFF

Instance(s):

DG1

Properties:

DGConnectIdentifier = 'dg1'

ObserverConnectIdentifier = ''

LogXptMode = 'ASYNC'

RedoRoutes = ''

DelayMins = '0'

Binding = 'optional'

MaxFailure = '0'

MaxConnections = '1'

ReopenSecs = '300'

NetTimeout = '30'

RedoCompression = 'DISABLE'

LogShipping = 'ON'

PreferredApplyInstance = ''

ApplyInstanceTimeout = '0'

ApplyLagThreshold = '0'

TransportLagThreshold = '0'

TransportDisconnectedThreshold = '30'



stran 83

ApplyParallel = 'AUTO'

StandbyFileManagement = 'auto'

ArchiveLagTarget = '0'

LogArchiveMaxProcesses = '4'

LogArchiveMinSucceedDest = '1'

DbFileNameConvert = ''

LogFileNameConvert = ''

FastStartFailoverTarget = ''

InconsistentProperties = '(monitor)'

InconsistentLogXptProps = '(monitor)'

SendQEntries = '(monitor)'

LogXptStatus = '(monitor)'

RecvQEntries = '(monitor)'

StaticConnectIdentifier =

'(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oralinux.ajpes.si)(PORT=1522))(CO

NNECT_DATA=(SERVICE_NAME=DG1_DGMGRL)(INSTANCE_NAME=DG1)(SERVER=DEDICATED)))'

StandbyArchiveLocation = '+DATA/dg1/archivelog/'

AlternateLocation = ''

LogArchiveTrace = '0'

LogArchiveFormat = '%t_%s_%r.dbf'

TopWaitEvents = '(monitor)'

Database Status:

SUCCESS


Database - DG2

Role: PRIMARY


Instance(s):

DG2

Properties:

DGConnectIdentifier = 'dg2'

ObserverConnectIdentifier = ''

LogXptMode = 'ASYNC'

RedoRoutes = ''

DelayMins = '0'

Binding = 'optional'

MaxFailure = '0'

MaxConnections = '1'

ReopenSecs = '300'

NetTimeout = '30'

RedoCompression = 'DISABLE'

LogShipping = 'ON'

PreferredApplyInstance = ''

ApplyInstanceTimeout = '0'

ApplyLagThreshold = '0'

TransportLagThreshold = '0'

TransportDisconnectedThreshold = '30'

ApplyParallel = 'AUTO'

StandbyFileManagement = 'AUTO'

ArchiveLagTarget = '0'

LogArchiveMaxProcesses = '5'

LogArchiveMinSucceedDest = '1'

DbFileNameConvert = '/DG1/, /DG2/'

LogFileNameConvert = '/DG1, /DG2'

FastStartFailoverTarget = ''

InconsistentProperties = '(monitor)'

InconsistentLogXptProps = '(monitor)'



stran 84

SendQEntries = '(monitor)'

LogXptStatus = '(monitor)'

RecvQEntries = '(monitor)'

StaticConnectIdentifier =

'(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oralinux2.ajpes.si)(PORT=1522))(C

ONNECT_DATA=(SERVICE_NAME=DG2_DGMGRL)(INSTANCE_NAME=DG2)(SERVER=DEDICATED)))

'

StandbyArchiveLocation = '+DATA/dg2/archivelog/'

AlternateLocation = ''

LogArchiveTrace = '0'

LogArchiveFormat = '%t_%s_%r.dbf'

TopWaitEvents = '(monitor)'

Database Status:

SUCCESS



stran 85

LITERATURA IN VIRI Knjige:

1. Hudoklin Božič A., Rozman V. (2004) Zanesljivost in razpoložljivost sistemov človek – stroj

2. Jesse S., Burton B., Vongray B. (2011) Oracle Database 11g Release 2 High Availability, Oracle Press

3. Kessling D. K. (2008) Oracle Database 11g: Data Guard Administration, Student Guide, Oracle

4. Theriault M., Carmichael R., Viscusi J. (2000) Oracle DBA 101 5. Vengurlekar N., Vallath M., Long R. (2008) Oracle Automatic Storage

Management, Oracle Press

Spletne strani: 1. AJPES, bonitete

http://www.ajpes.si/Bonitetne_storitve, (2. 3. 2016)

2. AJPES, EBR http://www.ajpes.si/Evropski_poslovni_register/Splosno, (2. 3. 2016)

3. AJPES, letna poročila http://www.ajpes.si/Letna_porocila, (20. 4. 2016)

4. AJPES, organiziranost http://www.ajpes.si/O_AJPES/Organiziranost, (2. 3. 2016)

5. AJPES, predstavitev, http://www.ajpes.si, (2. 3. 2016)

6. AJPES, registri, http://www.ajpes.si/Registri, (1. 4. 2016)

7. AJPES, statistike http://www.ajpes.si/Statistike, (2. 3. 2016)

8. AJPES, uradne objave, http://www.ajpes.si/Uradne_objave, (2. 3. 2016)

9. IBM, Sorewize V7000, www.ibm.com/midmarket/it/it/att/pdf/GFL03080USEN.pdf, (20. 4. 2016)

10. Microsoft, Hyper-V, http://download.microsoft.com/download/5/7/8/578E035F-A1A8-4774-B404-317A7ABCF751/Competitive-Advantages-of-Hyper-V-Server-2012-over-VMware-vSphere-Hypervisor.pdf, (20. 4. 2016)

http://www.ajpes.si/Bonitetne_storitve

http://www.ajpes.si/Evropski_poslovni_register/Splosno

http://www.ajpes.si/Letna_porocila

http://www.ajpes.si/

http://www.ajpes.si/Registri

http://www.ajpes.si/Statistike

http://www.ajpes.si/Uradne_objave

http://download.microsoft.com/download/5/7/8/578E035F-A1A8-4774-B404-317A7ABCF751/Competitive-Advantages-of-Hyper-V-Server-2012-over-VMware-vSphere-Hypervisor.pdf





stran 86

11. Oracle Linux Blog, Linux Pre-Install, https://blogs.oracle.com/linux/entry/oracle_rdbms_server_11gr2_pre, (10. 5. 2016)

12. Oracle Technology Network, Oracle ASMLib, http://www.oracle.com/technetwork/topics/linux/asmlib/index-101839.html, (10. 5. 2016)

13. Oracle, Corporate History, http://www.oracle.com/us/corporate/profit/p27anniv-timeline-151918.pdf, (27. 3. 2016)

14. Oracle, Data Guard Concepts and Administration 12c, https://docs.oracle.com/database/121/SBYDB/title.htm, (20. 5. 2016)

15. Oracle, DB Backup and Recovery, https://docs.oracle.com/database/121/BRADV/toc.htm

(20. 5. 2016)

16. Oracle, Grid Infrastructure, https://docs.oracle.com/cd/E18248_01/doc/install.112/e16763/oraclerestart.htm, (3. 5. 2016)

17. Oracle, Log apply, https://docs.oracle.com/cd/B19306_01/server.102/b14239/concepts.htm#i1033870, (2. 6. 2016)

18. Oracle, Oracle ASM Concepts, https://docs.oracle.com/cd/E11882_01/server.112/e18951/asmcon.htm#OSTMG03620, (10. 5. 2016)

19. Oracle, Oracle Data Guard Broker, https://docs.oracle.com/cd/B28359_01/server.111/b28295/concepts.htm (1. 6. 2016)

20. Oracle, Oracle Restart, https://docs.oracle.com/cd/E18283_01/server.112/e17120/restart001.htm, (11. 5. 2016)

21. Oracle, OVM, http://www.oracle.com/us/technologies/virtualization/ovm-server-for-x86-459312.pdf, (20. 4. 2016)

22. Oracle, Standby redo, https://docs.oracle.com/cd/B19306_01/server.102/b14239/log_transport.htm#i1182869, (2. 6. 2016)

23. Oracle-base, ASM RAID, https://oracle-base.com/articles/misc/oracle-and-raid, (9. 5. 2016)

24. Red Hat, Oracleasm, https://rhn.redhat.com/errata/RHEA-2013-0554.html, (10. 5. 2016)

https://blogs.oracle.com/linux/entry/oracle_rdbms_server_11gr2_pre

http://www.oracle.com/technetwork/topics/linux/asmlib/index-101839.html

http://www.oracle.com/us/corporate/profit/p27anniv-timeline-151918.pdf

https://docs.oracle.com/database/121/SBYDB/title.htm

https://docs.oracle.com/database/121/BRADV/toc.htm

https://docs.oracle.com/cd/E18248_01/doc/install.112/e16763/oraclerestart.htm

https://docs.oracle.com/cd/E18248_01/doc/install.112/e16763/oraclerestart.htm

https://docs.oracle.com/cd/B19306_01/server.102/b14239/concepts.htm#i1033870

https://docs.oracle.com/cd/B19306_01/server.102/b14239/concepts.htm#i1033870

https://docs.oracle.com/cd/E11882_01/server.112/e18951/asmcon.htm#OSTMG03620

https://docs.oracle.com/cd/E11882_01/server.112/e18951/asmcon.htm#OSTMG03620

https://docs.oracle.com/cd/B28359_01/server.111/b28295/concepts.htm

https://docs.oracle.com/cd/E18283_01/server.112/e17120/restart001.htm

https://oracle-base.com/articles/misc/oracle-and-raid

https://rhn.redhat.com/errata/RHEA-2013-0554.html



stran 87

25. Red Hat, Yum https://access.redhat.com/solutions/9934, (10. 5. 2016)

26. TechTarget, Data Protection http://searchstorage.techtarget.com/definition/data-protection (20. 4. 2016)

27. TechTarget, DR&BC http://searchstorage.techtarget.com/definition/Business-Continuity-and-Disaster-Recovery-BCDR (20. 4. 2016)

28. Veeam, Hyper-V, https://hyperv.veeam.com/blog/what-is-hyper-v-technology/, (24. 5. 2016)

https://access.redhat.com/solutions/9934

http://searchstorage.techtarget.com/definition/data-protection

http://searchstorage.techtarget.com/definition/Business-Continuity-and-Disaster-Recovery-BCDR

http://searchstorage.techtarget.com/definition/Business-Continuity-and-Disaster-Recovery-BCDR

https://hyperv.veeam.com/blog/what-is-hyper-v-technology/



stran 88

KAZALO SLIK Slika 1: Mreža organizacijskih enot ..................................................................... 5 Slika 2: Prenos podatkov pri fizični izvedbi DG .................................................... 17 Slika 3: Prenos podatkov pri logični izvedbi DG ................................................... 17 Slika 4: Zgradba Microsoft Hyper-V 2012 ........................................................... 25 Slika 5: Konfiguracija strežnika na Hyper-V. ....................................................... 26 Slika 6: Grafična predstavitev prvega diska (sda). ............................................... 27 Slika 7: Zagonska particija (boot). ..................................................................... 27 Slika 8: Drugi disk (sdb), v celoti namenjen podatkovni zbirki, z nameščenim ASM.28 Slika 9: Pregled diskov, na katerem ni drugega diska (sdb).................................. 28 Slika 10: Nameščanje Grida za samostojni strežnik ............................................. 32 Slika 11: Grid - določanje parametrov NLS ......................................................... 32 Slika 12: Grid - izbira diskovne skupine in določanje njenih prametrov .................. 33 Slika 13: Grid - postavljanje gesel za sistemski račun .......................................... 33 Slika 14: Grid - določanje uporabniških skupin .................................................... 34 Slika 15: Grid - določanje lokacije za programsko opremo (ORACLE_HOME) ......... 34 Slika 16: Grid - lokacija za oraInventory (dnevniške datoteke, začasne datoteke ...) ...................................................................................................................... 35 Slika 17: Grid - možnost zagona predpripravljenih skript...................................... 35 Slika 18: Grid - zadnji pregled pred dokončno namestitvijo .................................. 36 Slika 19: Grid - nameščanje programske opreme ................................................ 36 Slika 20: Grid - čisto na koncu je treba zagnati še dva sistemska skripta ............... 37 Slika 21: DB - začetek nameščanja Oraclovega programja ................................... 38 Slika 22: DB - nameščamo samo program brez podatkovne zbirke ....................... 38 Slika 23: DB - nameščamo samostojni strežnik ................................................... 39 Slika 24: DB - urejanje NLS - dodajanje slovenščine. ........................................... 39 Slika 25: DB - nameščamo verzijo za večja podjetja (EE). .................................... 40 Slika 26: DB - določanje osnovnega direktorija (ORACLE_HOME) ......................... 40 Slika 27: DB - določanje skupin z upravljavskimi pravicami .................................. 41 Slika 28: DB - pregled vseh sistemskih parametrov ............................................. 41 Slika 29: DB - pregled vseh sistemskih parametrov (2. del).................................. 42 Slika 30: DB - pregled globalnih nastavitev pred končno namestitvijo ................... 42 Slika 31: DG - začetek ustvarjanja zbirke ........................................................... 44 Slika 32: DG - izberemo napredni način ............................................................. 44 Slika 33: DG - izberemo predlogo ...................................................................... 45 Slika 34: DG - določimo ime zbirke (DG1) .......................................................... 45 Slika 35: DG - orodje dbca uredi namestitev Enterprise Managerja (EM) za našo zbirko ............................................................................................................. 46 Slika 36: DG - določitev skupnega gesla za administratorske sheme ..................... 46 Slika 37: DG - izbira poslušalca ......................................................................... 47 Slika 38: DG - določanje lokacij za objekte podatkovne zbirke (ASM) .................... 47 Slika 39: DG - možnost namestitve vzročnih shem (npr. SCOTT) .......................... 48 Slika 40: DG – določanje inicializacijskih parametrov (pomnilnik) .......................... 48 Slika 41: DG – določanje inicializacijskih parametrov (velikost bloka, število procesov) ........................................................................................................ 49



stran 89

Slika 42: DG – določanje inicializacijskih parametrov (NLS - kodna tabela, jezik, država) ........................................................................................................... 49 Slika 43: DG – pred zaključkom zbirka ustvari še skripte in predlogo .................... 50 Slika 44: DG – začetek ustvarjanja zbirke ........................................................... 51 Slika 45: DG – zaključek ustvarjanja zbirke......................................................... 51 Slika 46: Oraclovi procesi – podatkovna zbirka, poslušalec, povezava z ASM ......... 52 Slika 47: Prenos arhivov v dodatno (standby) datoteko ....................................... 58

POJMOVNIK Oracle Home: osnovi direktorij, v katerega namestimo Oraclovo programsko

opremo. Nanj je vezana tudi sistemska spremenljivka ORACLE_HOME.

KRATICE IN AKRONIMI GUI: Graphical User Interface: grafični uporabniški vmesnik NLS: National Language Support: privzet jezik baze; glede na to nastavitev, bo

baza izpisovala datum (dneve v tednu, mesece), določala izpis valute, določala vrstni red za razvrščanje po abecedi, postavljala decimalno piko ali vejico ipd.

diplomsko delo univerzitetnega študija · na osnovi zahtev, ki jih je sektorju za informatiko...

Documents