PROJEKT NADGRADNJE BAZE PODATKOV ORACLE · Kranj, maj 2009 . ZAHVALA ... ki je iz leta 2007. Baza...

UNIVERZA V MARIBORU FAKULTETA ZA ORGANIZACIJSKE VEDE

Diplomsko delo visokošolskega strokovnega študija

Smer: Informatika v organizaciji in managementu

PROJEKT NADGRADNJE BAZE PODATKOV ORACLE

Mentor: izr. prof. dr. Robert Leskovar Kandidat: Miran Presečnik

Kranj, maj 2009

ZAHVALA Zahvaljujem se mentorju prof. dr. Robertu Leskovarju za pomoč in svetovanje pri pisanju diplomske naloge. Za svetovanje se zahvaljujem gospodu Gorazdu Vidmarju, analitiku v tehnični podpori Oracle Slovenija. Zahvaljujem se tudi svoji družini za razumevanje in podporo pri študiju.

NASLOV Projekt nadgradnje baze podatkov Oracle POVZETEK Naloga obravnava projekt nadgradnje baze podatkov Oracle verzije 7 v verzijo 8i. Podana je primerjava lastnosti obeh verzij baze. Opisano je podjetje SPL d.d. ter naloge skrbnika sistema in skrbnika baze podatkov. Projekt nadgradnje je bil zapleten zaradi napak na nosilcu podatkov. Posledica tega je bila, da ni bilo mogoče izvoziti vseh podatkov. Po uvozu podatkov v Oracle8i so bili manjkajoči podatki obnovljeni s pomočjo programiranja. Nameščeni so bili potrebni popravki na strani strežnika in odjemalca. Projekt nadgradnje je omogočil povezljivost z novejšimi orodji, prehod na grafični uporabniški vmesnik in zagotovil večjo varnost poslovnih podatkov. KLJUČNE BESEDE

• nadgradnja • informacijska tehnologija • okvarjeni podatkovni bloki • SUBP • Oracle

TITLE The upgrade project of Oracle database ABSTRACT This diploma thesis describes the development project in which Oracle database version 7 is upgraded to version 8i. These two versions are compared according to major functions. The company SPL d.d., in which the project took place is briefly described as well as the system administrator's and database administrator's tasks. The upgrade project was complex due to lost data in corrupted blocks – the consequence was incomplete export of database. After import of valid data in Oracle 8i the missing one were restored through programming procedures. Critical patches were installed on server and client sides. The upgrade project enabled the compatibility with up-to-date database tools, the usage of graphical user interface and assured better security of business data. KEYWORDS

• upgrade • informational technology • corrupted data blocks • DBMS • Oracle

KAZALO 1 Uvod..................................................................................................................... 1 2 Metodologija dela ............................................................................................. 4

2.1 Definicija problema................................................................................... 4 2.2 Definicija ciljev ........................................................................................... 6 2.3 Predvidene metode dela in uporabljena orodja................................. 7

3 Predstavitev okolja............................................................................................. 8

3.1 Zgodovina in dejavnost podjetja SPL d.d. ............................................. 8 3.2 Sektor informatike.................................................................................... 10

4 Primerjava lastnosti Oracle7 in Oracle8i ....................................................... 11

4.1 Opis obstoječega sistema...................................................................... 11 4.2 Nove funkcije Oracle8 in Oracle8i........................................................ 12

5 Projekt nadgradnje produkcijske baze Oracle............................................ 15

5.1 Planiranje nadgradnje............................................................................ 15 5.2 Priprave..................................................................................................... 16

5.2.1 Dela potrebna na baznem strežniku.................................................... 16 5.2.2 Dela potrebna na strežniku za odjemalce.......................................... 16 5.2.3 Priprava in analiza baze podatkov ...................................................... 17 5.2.4 Priprava operacijskega sistema............................................................ 17

5.3. Nadgradnja (ponesrečen poizkus) ............................................................ 21 5.3.1 Težave....................................................................................................... 21 5.3.2 Sanacija težav......................................................................................... 29

5.4. Nadgradnja................................................................................................... 31 5.4.1 Postopek namestitve Oracle8i na OpenVMS operacijski sistem...... 31 5.4.2 Postopki po nadgradnji strežnika.......................................................... 35 5.4.3 Predpriprava za import - kreiranje objektov ....................................... 39 5.4.4 Prenos (import) podatkov...................................................................... 40 5.4.5 Kreiranje indeksov na tabelah .............................................................. 41 5.4.6 Odpravljanje zadnjih težav.................................................................... 41 5.4.7 Nadgradnja strežnika za odjemalce.................................................... 43

6 Zaključek............................................................................................................ 45 7 Viri in literatura .................................................................................................. 46

Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija

Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 1

1 Uvod

Sistem za upravljanje baz podatkov (SUBP) oz. Database Management System (DBMS) je programska oprema za upravljanje baze podatkov. SUBP lahko upravlja različne modele baz podatkov kot so hierarhični, mrežni, relacijski in objektni. Najpogosteje se danes uporablja relacijski model. Glavne funkcije SUBP so organizacija, shranjevanje, upravljanje in zagotavljanje podatkov. Zahteve aplikacij za dostop do podatkov se do baze podatkov prenašajo preko SUBP. Zasnova in kreiranje baze podatkov je delo skrbnika baze podatkov (DBA) in sistemskega administratorja. Večina produkcijskih SUBP teče na strežnikih, ki so namenjeni le delovanju SUBP in s tem povezane programske opreme. Ti strežniki so večinoma večprocesorski, z veliko sistemskega pomnilnika in zmogljivimi RAID (Redundand Array of Inexpesive Disks) diskovnimi podsistemi, ki zagotavljajo hitre dostope do podatkov in veliko zanesljivost delovanja. Relacijski podatkovni model sestoji iz množice tabel. Vsaka tabela je sestavljena iz čelne vrstice (relacijska shema) in podatkovnih vrstic (relacija). Vsaka relacija oz. tabela v relacijski bazi mora ustrezati določenim pravilom, da jo lahko imenujemo relacija:

• vrstni red vrstic v tabeli je nepomemben • vrstice se morajo razlikovati med seboj v vrednosti vsaj enega atributa

(ne smeta obstajati enaki vrstici) • vsaka vrstica tabele ima lahko le eno vrednost za vsak atribut

Osnovna koncepta relacijskega podatkovnega modela sta domena in relacija. Relacija je definirana nad množico domen. Domene so množice, njihovi elementi pa so vrednosti, predstavljive v obliki podatkov. Vir: Mohorič Tomaž, Podatkovne baze, (1990).



Matematično je relacija podmnožica kartezijskega produkta množice domen in to skoraj natančno ustreza definiciji tabele (Slika 1).

nDDDR ×××⊆ ...

21

Maja 23 Peter 16

Slika 1: Relacija kot kartezijski produkt dveh domen (Ime X Starost)

Največja prednost relacijskega modela je, da podpira strukturiran povpraševalni jezik SQL (Structured Query Language), ki ima veliko izrazno moč. Leta 1970 je E.F.Codd, angleški znanstvenik, takrat zaposlen v firmi IBM, s člankom "A Relational Model of Data for Large Shared Data Banks" postavil temelje za razvoj SQL standarda. Prvo verzijo SQL je razvila firma IBM v letu 1970, imenoval se je SEQUEL. Namenjen je bil lastnemu produktu System R. Ta produkt je bil osnova za Oracle RDBMS, danes eno najuspešnih relacijskih SUBP. Standard SQL je formalno objavil ANSI inštitut (American National Standards Institute) leta 1986. Od tedaj so nastale naslednje verzije (Tabela 1): leto standard komentar 1986 SQL-86 prva objava (ANSI) 1989 SQL-89 manjši popravki 1992 SQL-92 (SQL2) pomembna revizija 1999 SQL:1999 (SQL3) uvedba rekurzivnih poizvedb, prožilci, podpora

proceduralnim izrazom.. 2003 SQL:2003 uvedba XML, ekranske funkcije, auto-generirani stolpci.. 2006 SQL:2006 določen način kako naj SQL deluje z XML, XQuery, .. 2008 SQL:2008 uvedba instead of trigerjev, dodan truncate ukaz,..

Tabela 1: verzije SQL standarda (Vir: http://en.wikipedia.org/wiki/SQL)

Maja 23 Maja 16 Peter 23 Peter 16

⊆



Glavni predstavniki relacijske tehnologije v svetu so danes Oracle, IBM, Microsoft, Sybase, Teradata in ostali.

proizvajalci SUBP

tržni delež v letu 2006

Oracle 47,1% IBM 21,1%

Microsoft 17,4% Ostali 14,4%

Tabela 2: tržni delež največjih proizvajalcev relacisjkih baz v letu 2006

Vir: Gartner Dataquest (2007)

Iz tabele 2 je razvidno, da ima korporacija Oracle skoraj polovico tržnega deleža med proizvajalci relacijskih baz. Prva verzija Oracle SUBP je nastala leta 1979, ostale pa so sledile v letih do današnje verzije 11g, ki je iz leta 2007. Baza Oracle7 je prišla na trg leta 1992, Oracle8i pa leta 1999. Obe bazi sta precej zastareli, predvsem pa Oracle7 ne omogoča povezljivosti z višjimi verzijami.



2 Metodologija dela 2.1 Definicija problema Vodstvo podjetja SPL d.d. je zahtevalo rešitve, ki bi omogočale povezovanje z zunanjimi partnerji in zunanjimi izvajalci, ki so uporabljali novejše tehnologije. Uvajal se je projekt za spremljanje dokumentov z orodjem za procesno modeliranje, ki za svoje delovanje potrebuje Oracle bazo verzije vsaj 9i. Ekipa ITja je vedno težje zagotavljala zahtevano varnosti podatkov. Vseh teh zahtev ni bilo več mogoče izpolnjevati z obstoječo bazo Oracle7, ki smo jo uporabljali v produkcijskem sistemu. Težave prehoda na grafično okolje V planu je bil prehod na grafično okolje, vendar je tak prehod zelo kompleksen. Predvsem bi povzročala težave menjava znakovnega nabora (character set) v bazi in pa usklajevanje znakovnih naborov med strežnikom in odjemalci. Standardi za kodiranje SLO znakov (Vir: Rožman Sergej, Abakus plus, 2005): - JUS I.B1.002 – ISO 646–YU (sinonimi: SLOSCII, YU ASCII, YUSCII) - IBM CP852 (sinonimi: DOS 852, Latin 2) - MS–CP1250 (sinonimi: windows 1250, MS latin II) - ISO 8859–2 (ISO 8859–16 / ISO latin 10 ?) (sinonimi: ISO latin 2) - UNICODE – ISO 10646 (različice: UTF–8, UCS–2, UTF–16, ...)

Oracle v Sloveniji uporablja naslednje standarde: - YUG7ASCII JUS I.B1.002 - EE8PC852 IBM CP852 - EE8MSWIN1250 MS1250 - EE8ISO8859P2 ISO 8859-2 - UTF8, AL32UTF8, AL16UTF16 UNICODE - EBCDIC variante

Baza podatkov v SPL d.d. je kreirana v EE8ISO8859P2 (ISO 8859-2) naboru, vendar so podatki v bazi zapisani v starem, US7ASCII načinu. To pomeni, da v bazi ni pravih šumnikov, ampak se le-ti prikazujejo na odjemalcu s pomočjo posebnega fonta, ki znake

^~[{@` prikazuje kot ČčŠšŽž.



Pomanjkljivosti take nastavitve so:

• podpora le za en nabor (ni pretvarjanj) • podpora le za določene odjemalce • razvrščanje (sortiranje) ne deluje pravilno

Oracle priporoča uporabo UNICODE nabora znakov, UTF-8 za Evropo (Tabela 3)

UTF-16 (fiksna dolžina) UTF-8 (variabilna dolžina)

ASCII znaki 8 bitni običajni znaki 16 bitni evropski znaki 16 bitni posebni znaki 32 bitni posebni znaki 32 bitni

Tabela 3: UNICODE (Vir: http://utf8.com, http://unicode.org)

Nekaj pomislekov proti uporabi UTF-8 nabora znakov:

• uporaba UTL_FILE paketa (package), ki se uporablja za branje in pisanje datotek na strežniku (potrebne bi bile aplikativne predelave)

• uporaba starih verzij odjemalca, starejših od 6i • podatki zasedejo več prostora • obdelave zahtevajo več procesiranja

Za uskladitev nastavitev odjemalca in strežnika Oracle uporablja spremenljivko NLS_LANG, ki je sestavljena: NLS_LANG = _.

V MS Windows, se spremenljivka nastavi v sistemskem registru (slika 2):

Slika 2: Nastavitev spremenljivke NLS_LANG v sistemskem registru MS Windows XP Pro

v OpenVMS kot logično ime:

$ define NLS_LANG "SLOVENIAN_SLOVENIA.EE8ISO8859P2",

v Linuxu pa s spremenljivko (environment variable):

# export NLS_LANG=slovenian_slovenia.ee8iso8859p2



V okolju Oracle znakovne pretvorbe potekajo sprotno na transportni poti (OracleNet), običajno na strani odjemalca, včasih pa na strani strežnika - od Oracle8i dalje. (Vir: Oracle Metalink note 158577.1, 2003). Do pretvorb znakov ne prihaja, kadar je na odjemalcu in na strežniku (v bazi podatkov) uporabljen enak nabor znakov, sicer pa se pretvorba izvede na predstavitvenem sloju ISO OSI modela (Slika 3).

Slika 3: ISO OSI Model - potek pretvorbe znakov (Vir: Rožman Sergej, Abakus plus, 2005)

Težava nastane, ker imajo različni odjemalci različne standarde. Pretvorba znakovnega nabora YUG7ASCII v MSWIN1250 ali celo v UTF-8 bi zahtevala menjavo vseh starejših tiskalnikov, ki ne podpirajo teh znakovnih naborov. Na začetku bi bilo potrebno vzdrževati oba sistema hkrati, kar bi povzročilo dodatne težave. 2.2 Definicija ciljev Za cilj smo si zadali nadgraditi obstoječo bazo podatkov Oracle7, da bi omogočala:

• povezljivost z drugimi, novejšimi viri podatkov • povezljivost z novejšimi orodji • prehod na grafični odjemalec (iz znakovnega) • več funkcionalnosti in optimizacijo • hkratni dostop do podatkov z obema odjemalcema • stabilnost delovanja in večjo varnost podatkov



Realizacija teh ciljev bi omogočala podjetju SPL d.d. nemoteno poslovanje, povezovanje z zunanjimi partnerji in izvajalci ter razvoj z novejšimi, grafičnimi orodji. 2.3 Predvidene metode dela in uporabljena orodja Za namen nadgradnje baze podatkov Oracle so bile predvidene naslednje metode dela :

• študij potrebne literature o obeh verzijah baz z namenom dobrega poznavanja značilnosti obeh verzij

• analiza podatkovne baze z vidika osnovnih objektov kot so tabele, indeksi, rollback segmenti, njihovih lastnosti kot so velikost, razdrobljenosti (fragmentacija) in njihovih povezav

• projektni management potreben za učinkovito delo skupine, porazdelitev nalog, koordinacijo in sinhronizacijo

• sistemski inženiring za obvladovanje poslovnih in tehničnih zahtev ter tveganj pri prehodu na višjo verzijo

pri tem so bila uporabljena naslednja orodja:

• orodja, ki so del Oracle SUBP sistema: - SQL*Plus strukturirani poizvedovalni jezik - PL/SQL proceduralni jezik in lastne pomožne ukazne datoteke - Oracle DBA studio za pregled in kontrolo objektov - UTLBSTAT/UTLESTAT (Oracle7) in STATSPACK (Oracle8i) - za analizo baze med delovanjem, - za ugotavljanje I/O obremenjenosti posameznih tablespace, datafile in s tem neposredno zasedenost posameznih diskov, - ugotavljanje časovno kritičnih dogodkov na bazi - iskanje queryjev, ki najbolj obremenjujejo vire (resource)

• orodja operacijskega sistema OpenVMS: - $ "monitor" SYSTEM, IO, CPU, MEMORY za ugotavljanje obremenjenosti sistema in zasedenosti sistemskih virov - $ "analyze" RMS za preverjanje parametrov datotečnega sistema

• ostala orodja: - Quest TOAD for Oracle, orodje za razvoj in administracijo baze



3 Predstavitev okolja 3.1 Zgodovina in dejavnost podjetja SPL d.d. Družba SPL Ljubljana d.d., poslovanje z nepremičninami in inženiring ima svoje korenine v letu 1965, ko sta bili ustanovljeni podjetji DOM in FOND kot organizaciji posebnega družbenega pomena. Obe podjetji sta se združili v organizacijo STANINVEST, ki je zaposlovala več kot 1000 ljudi, ki so opravljali storitve za celotno področje stanovanjske dejavnosti: upravljanje stanovanjskih stavb, poslovnih stavb, stanovanjsko-poslovnih stavb, dejavnost obratovanja stanovanjskih in poslovnih stavb, projektiranje in izgradnja stanovanj ter vsa zaključna dela v gradbeništvu. Med leti 1978-1984 se je podjetje STANINVEST reorganiziralo. Del temeljnih dejavnosti se je preoblikovalo v samostojna podjetja. Leta 1984 je Stanovanjsko podjetje Ljubljana, ki je predhodnik družbe SPL d.d., ohranilo dejavnost upravljanja, vzdrževanja ter zaključnih del v gradbeništvu. V letu 1996 se je Stanovanjsko podjetje Ljubljana preoblikovalo v delniško družbo SPL Ljubljana d.d., poslovanje z nepremičninami in inženiring. V istem letu je družba pridobila certifikat kakovosti ISO 9001 za področje upravljanja nepremičnin, leta 2004 pa še ISO 9001:2000, ki predstavlja certifikat za celotno poslovanje z nepremičninami ter kodeks dobrih poslovnih običajev. Posebna pozornost je bila usmerjena v raziskave in razvoj na področju informacijske tehnologije za potrebe celotnega poslovanja družbe. V letu 2005 se je dejavnost podjetja razširila z odprtjem novih poslovnih enot v Domžalah in Kočevju. Spletna stran www.spl.si je bila prenovljena in nadgrajena z novimi vsebinami, uveden pa je bil tudi spletni portal www.mojupravnik.si in klicni center, kar je pripomoglo k izboljšanju komunikacije s strankami. Danes ima podjetje SPL d.d. preko 130 zaposlenih, ki svoje delo opravljajo s pomočjo osebnih računalnikov v povezavi z večjimi strežniškimi sistemi. Osnovni strežniški sistem je Windows 2003 Server, ki teče na več strežnikih, povezanih v aktivni imenik (Active Directory). Razvit ima lasten informacijski sistem, ki temelji na bazi podatkov Oracle. Glavne storitve družbe SPL d.d. so:

• upravljanje nepremičnin • vzdrževanje nepremičnin • čiščenje in urejanje skupnih prostorov, okolice • vpis v zemljiško knjigo • posredovanje nepremičnin - pri prometu z nepremičninami • upravljanje rezervnega sklada



Na sliki 4 je prikazan organigram družbe SPL d.d.

Slika 4: Organigram SPL d.d. (Vir: SPL d.d., 2009)



3.2 Sektor informatike V sektorju informatike je zaposlenih 8 delavcev. Med najpomembnejšimi sta skrbnik sistema in skrbnik baze podatkov. Glavne naloge skrbnika sistema so:

• ocenjevanje primernosti uvajanja novih tehnologij in nove programske

opreme • skrb za nemoteno in optimalno delovanje aplikacijskih in baznih

strežnikov • namestitve programske opreme • dodeljevanje pravic uporabnikom in upravljanje z računi

(identifikacija, avtentikacija, avtorizacija) • ocena primernosti nakupov posamezne strojne opreme • določanje varnostne politike skupaj z vodstvom

Glavne naloge skrbnika baze podatkov so: (Viri: Thomas B. Cox: Oracle DBA Checklist, The Strategic DBA, 2000)

o Dnevne naloge:

• preverja delovanje vseh baznih instanc • ugotavlja obstoj morebitnih novih zapisov v alert-log datotekah • preverja uspešnost shranjevanja podatkov (backup, export) • preverja uspešnost arhiviranja podatkov na tračno enoto • preverja razpoložljive vire (resources) za nemoteno delovanje

o Tedenske naloge:

• preverja objekte, ki niso kreirani v skladu s politiko kreiranja

objektov • ugotavlja kršitve varnostne politike • preverja morebitne napake v SQL*Net log datotekah

o Mesečne naloge:

• ugotavlja prekomerno rast posameznih objektov (tabel, indeksov) • ugotavlja možnosti izboljšanja nastavitev delovanja (tuning

opportunities) • preverja aktivnost baznih datotek (I/O contention) • preverja razdrobljenost (fragmentacijo) objektov • ugotavlja možnosti za nastanek ozkih grl (CPU, memory, network

contention) • izvaja uglaševanje in vzdrževanje



4 Primerjava lastnosti Oracle7 in Oracle8i 4.1 Opis obstoječega sistema Bazni strežnik V času izvajanja nadgradnje je produkcijska baza Oracle7 tekla na dvo-procesorskem strežniku HP AlphaServer ES40, s 6GB sistemskega pomnilnika (RAM), na operacijskem sistemu OpenVMS verzije 7.2-1H3. Diskovni podsistem je sestavljalo diskovno polje RAID Compaq HSZ70, s 24 SCSI diski konfigurirani v RAID 1+0, mirror stripe postavitvi in 128 MB hitrega cache predpomnilnika. Krmilnik deluje v multibus-failover (dual redundand) postavitvi. S tako postavitvijo smo dosegli, da imajo tako diski kot tudi krmilnik (controller) vzpostavljeno zrcaljenje in bi v primeru okvare ene komponente delo nemoteno opravljala druga. Odjemalec Do baze podatkov uporabniki dostopajo preko strežnika odjemalcev, AlphaServer AS1000 z operacijskim sistemom OpenVMS 6.2-1H3, na znakovni (character-based) način, s pomočjo Oracle orodij Sql*Menu, Sql*Forms in SQL*Reports. Za terminalsko emulacijo se uporablja program Reflection terminal emulation za OpenVMS firme Attachmate in se izvaja na osebnem računalniku posameznega uporabnika. Program dostopa do strežnika preko telnet protokola. Zavedamo se, da telnet ni dovolj varen protokol, vendar Pathworks 6.0D (TCP/IP Services for OpenVMS) ne podpira varnejšega protokola SSH. Poleg tega pa je protokol telnet uporabljen le v lokalnem omrežju (LAN), za točno določen namen. RDBMS Pred nadgradnjo je na baznem strežniku delovala baza Oracle Server RDBMS 7.3.4. To je zadnja pod-verzija verzije 7. Baza je delovala zelo stabilno, zanesljivo in zadovoljivo glede zmogljivosti. V tabeli 4 so prikazane glavne omejitve Oracle7 v premerjavi z Oracle8i.

postavka vrsta omejitve omejitev Oracle7 omejitev Oracle8i database files per database 1022 65533

database file size maximum 16 mil. oracle blocks limited by max O/S size MAXEXTENTS parameter

maximum

derived from DB_BLOCK_SIZE param

O/S dependent

derived from DB_BLOCK_SIZE param

unlimited columns max per table 254 1000 columns max per index 16 32 CHAR maximum 255 characters 2000 bytes

VARCHAR2 maximum 2000 characters 4000 bytes users and roles maximum 65525 2.147.483.638 (~2M)

Tabela 4: Glavne omejitve baze Oracle7 v primerjavi z Oracle8i.



4.2 Nove funkcije Oracle8 in Oracle8i Z verzijama baze Oracle8 in Oracle8i je Oracle uvedel precej novosti in izboljšal delovanje obstoječih funkcij. Novosti je veliko, zato bomo omenili le nekatere: o Integrated Distributed Lock Manager (IDLM)

V bazi Oracle8 je eksterni Distributed Lock Manager, ki je v Oracle7 deloval na nivoju O/S, zamenjal Integrated Distributed Lock Manager, ki zagotavlja izboljšane mehanizme zaklepanja na nivoju baze. IDLM s pridom uporablja Oracle Parallel Server.

o JAVA v bazi

Java kot standardni jezik interneta je opcijsko vključena v bazo. Java v Oracle8i vsebuje:

• Oracle JServer - java virtual machine • Oracle JServer Accelerator - native compiler za hitrejše

delovanje • Programmatic interfaces - JDBC gonilniki in SQLJ • razvojna orodja, kot ločeni produkti

o NET8 (Slika 5)

NET8 je Oracle mehanizem za povezavo z mrežnimi komunikacijskimi protokoli. Namenjen je predvsem povezavi Oracle strežnika z odjemalskimi programi na drugih računalnikih. NET8 je izboljšana verzija SQL*Neta in omogoča podporo:

• API (Application Programming Interface) • internetnim brskalnikom z vgrajeno Javo • mrežnim servisom (network services) kot sta naming and

security

Slika 5: Net8 - povezava odjemalec-strežnik (Vir: Oracle8i, Administrator's Guide, 2000)



o Localy Managed Tablespace do verzije Oracle8i je bil lahko "tablespace" upravljan le preko repozitorija (dictionary managed). To pomeni, da Oracle upravlja "tablespace" z uporabo "data dictionary". Uvedba Localy Managed Tablespace pa pomeni, da Oracle posamezen "tablespace" upravlja lokalno. Namesto, da bi se podatki o podaljških (extent) v posameznem "tablespace" zbirali enotno v sistemskem "tablespace" (dictionary managed), se ti podatki zbirajo lokalno - vsak "localy managerd tablespace" ima svojo bitno mapo (bitmap), v kateri hrani podatke o podaljških. Prednosti takega upravljanja podatkovnih področij so:

• hitrejše zasedanje in sproščanje (allocate, deallocate) prostora • povečana zmogljivost delovanja • ta funkcija omogoča kreiranje standby (read only) baze • zasedanje (alokacija) prostora je poenostavljena (omogoča autoallocate space) • funkcija združevanja (coalesce) prostih podaljškov postane nepotrebna

o Transportable Tablespace

možnost prenosa posameznega "tablespace" med različnimi bazami

o Indexed organized table (IOT)

Index organized table je Oracle podatkovna struktura, ki omogoča izbolšano zmogljivost in nadgradljivost. Dejanski podatki v "indexed organized" tabeli so shranjeni v B-tree indeks strukturi, razvrščeni po primarnem ključu tabele tako, da pisanje, ažuriranje in brisanje vrstic zahteva le ažuriranje indeksa.

o Temporary table

omogočeno je kreiranje začasnih tabel, ki se s prenehanjem transakcije same pobrišejo

o Particionirane tabele in indeksi (Partitioned Tables in Indexes)

Uvedba particioniranih tabel in indeksov veliko pripomore k obvladovanju velikih objektov. Kreiranje particije na tebeli pomeni, da lahko npr. z orodjem SQL dostopamo do posameznega dela tabele (particije) ne da bi pri tem brali vso tabelo. Particioniranje je posebno uporabno v podatkovnih skladiščih (data warehouse), kjer se obdeluje velike količine časovno urejenih podatkov.



o Drop column on table omogočeno brisanje ene ali več posameznih stolpcev tabele

o Podpora za SQL3 standard (SQL:1999)

o NLS Euro symbol - v bazi 8i je podprt Euro simbol

o Standby database (Slika 6)

še ena velika novost v verziji 8i. Standby baza je kopija primarne baze z namenom, da zagotovi disaster-recovery (ponovna vzpostavitev primarne baze v primeru uničenja baze)

Slika 6: Postavitev standby baze (Vir: Oracle8i, Technical report, 1999)

o STATSPACK

STATSPACK je zelo močno orodje za zbiranje sistemske statistike in kreiranje poročil o delovanju baze. Nadomešča zastarelo orodje UTLBSTAT/UTLESTAT iz Oracle7.

Poleg tega je Oracle8i prinesel še veliko drugih izboljšav:

• izboljšave pri Backup in Recovery (Tablespace point in time recovery, incremental backups)

• izboljšane splošne zmogljivosti baze • izboljšana varnost na nivoju uporabnikov (user security) • SQL, PL/SQL : večja učinkovitost uporabe procesorja, pomnilnika



5 Projekt nadgradnje produkcijske baze Oracle 5.1 Planiranje nadgradnje Glede na to, da je bil plan dela relativno nezahteven, smo ga definirali kar v preglednici (Slika 7). Poleg samih planiranih aktivnosti in datumov, smo definirali še zadolžene za posamezno akcijo.

Slika 7: Plan dela za nadgradnjo baze Oracle7 na Oracle8i

Da bi čim manj motili delovni proces smo se odločili, da izvedemo nadgradnjo v dela prostih dneh.



5.2 Priprave 5.2.1 Dela potrebna na baznem strežniku 1. preveriti/poiskati morebitne potrebne popravke (patch) za operacijski sistem OpenVMS 2. preveriti/poiskati morebitne potrebne popravke za bazo Oracle 8i 3. pripraviti proceduro za morebitno obnovitev (restore) diskov na katerih so bazne datoteke 4. varnostna kopija baze podatkov pri ustavljeni bazi (cold backup) - 2x 5. export baze podatkov - 2x 6. analiza parametrov stare baze - določitev optimalnega DB Block size - velikost SGA, buffer cache, log-buffer, log-filesize - dictionary / localy managed system tablespace - ime nove baze/instance - prevajanje neveljavnih objektov (compile invalid objects) - analiza števila objektov po shemah 7. namestitev nove baze - verzija 8.1 8. namestitev končnih popravkov na novi bazi - verzija 8.1.7.4 9. prenos (import) podatkov v novo bazo 10. vzpostavitev mrežnih povezav v bazi - networking 5.2.2 Dela potrebna na strežniku za odjemalce Pred nadgradnjo baze:

1. izvoz (unload) aplikacij iz SQL*Menu 2. izvoz (unload) poročil (reports) iz SQL*Report

Po nadgradnji baze:

1. kreiranje SQL*Menu okolja 2. uvoz aplikacij v SQL*Menu 3. namestitev popravka za SQL*Forms 4. kreiranje SQL*Reports okolja 5. uvoz poročil v SQL*Reports 6. testiranje delovanja aplikacij, poročil, izpisov,..

Ko smo analizirali potreben čas za te akcije smo ugotovili, da verjetno ne bo dovolj časa v enem koncu tedna - velikost eksporta baze podatkov je bila približno 100GB. Zato smo se odločili, da prvi konec tedna pripravimo operacijski sistem in okolje na baznem strežniku, naslednji konec tedna pa začnemo z nadgradnjo.



Dela smo planirali tako, da naj bi bilo kadarkoli možno obnoviti prvotno stanje, če bi se karkoli zalomilo. Plan smo pregledali in ocenili vsi sodelujoči pri projektu. 5.2.3 Priprava in analiza baze podatkov Potrebno je bilo pregledati in shraniti nastavitve parametrov baze, npr.:

• DB_BLOCK_SIZE - velikost bloka • DB_BLOCK_BUFFERS - število blokov (delovni pomnilnik baze) • SHARED_POOL_SIZE - velikost shared pool (Oracle library cache) • SORT_AREA_SIZE - velikost področja za razvrščanje (sort) • ROLLBACK_SEGMENTS - rollback segmenti • CONTROL_FILES - kontrolne datoteke

Izdelati je bilo potrebno razne ukazne datoteke za:

• kreiranje baznih objektov • export, import podatkov • kreiranje tablespace, datafile • kreiranje glavne sheme, ki je lastnik vseh objektov aplikacije • kreiranje uporabnikov, privilegijev

Preveriti in zabeležiti je bilo potrebno čase za posamezne akcije, ki so bile planirane, da je bilo možno čimbolj natančno časovno planirati. 5.2.4 Priprava operacijskega sistema Standalone backup sistemskega diska Na sistemskem disku so nenehno odprte (zasedene) datoteke zaradi delovanja operacijskega sistema, zato tega diska med delovanjem ni možno odklopiti (offline) in s tem zagotoviti konsistenten backup. Potrebno je zagnati strežnik (boot) iz ne-sistemskega diska, ki ima nameščen minimalni "boot software" ali iz namestitvenega OpenVMS CDROMa.

1. iz alternativnega diska za ta postopek je potrebno predhodno namestiti na ta disk minimalni "boot-kit". To storimo z zagonom sistemske procedure (uporabnik za zagon potrebuje sistemske privilegije): $ @sys$system:axpvms$pcsi_install_min DKC100:



V tem primeru se bo na disku DKC100 namestila dodatna imeniška struktura in programi, ki bodo omogočali kasnejše nalaganje sistema iz tega diska: >>> BOOT -flag E,0 DKC100 dvig strežnika iz alternativnega

diska (DKC100)

Dvig strežnika v tem načinu ne omogoča interaktivnega dela, prijavo drugih uporabnikov, ampak le kontrolo nad sistemom. Potrebno je paziti pri ukazih, ker je prijava na strežnik brez identifikacije z vsemi privilegiji. Po uspešnem dvigu sistema s tega diska dobimo na konzolni enoti strežnika ukazno kazalko (prompt) $$$ in lahko izvedemo varnostno kopijo (backup) sistemskega diska, ki je sedaj v vlogi navadnega diska. Disk in tračno enoto je potrebno najprej priključiti (mount), tako kot vse druge enote: $$$ mount DKB0: priključitev diska $$$ mount/for MKD300: priključitev tračne enote

in zatem lahko poženemo "standalone backup" sistemskega diska na tračno enoto: $$$ back/image/rewind DKB0: MKD300:.sav/save

2. iz namestitvenega CDROMa postopek zagona strežnika iz CDROMa je podoben zagonu z alternativnega diska, le da tu za vhodno enoto navedemo CD enoto: >>> BOOT -flag E,0 DKA500 dvig strežnika z CD enote Po dvigu sistema se na konzolni enoti izpiše več možnosti: 1) Upgrade, install or reconfigure OpenVMS Alpha version 6.2-1H2 2) Display products and patches that this procedure can install 3) …. .... 7) Execute DCL commands and procedures 8) Shut down this system

Tu se odločimo za možnost 7, ker bomo izvajali DCL (Digital Command Language) ukaze: $$$ back/image/rewind DKB0: MKD300:.sav/save



Po uspešni izvedbi ukaza backup, je potrebo še izključiti (dismount) sistemski disk in tračno enoto: $$$ dismount DKB0: $$$ dismount MKD300:

in ponovno zagnati (reboot) strežnik z ukazom: $$$ @sys$system:shutdown (izklop strežnika zagnanega iz diska)

ali z ukazom: $$$ logout (vrnirev v menu)

ki nas vrne v izbirni menu, kjer izberemo možnost: 8) Shut down this system

(izklop strežnika zagnanega iz CDROMa)

Namestitev popravkov (patch) za OpenVMS Po planu smo začeli z nameščanjem popravkov za OpenVMS na baznem strežniku, potrebnih za nadgradnjo baze - Patches (ECOs) Required for Oracle RDBMS. Pred tem je bilo potrebno narediti varnostno kopijo sistemskega diska (standalone backup) na tračno enoto - SDLT. Vsi popravki se nameščajo na sistemski disk in v primeru neuspelega nameščanja operacisjki sistem ne bi deloval. Na Oracle MetaLinku (Oracle baza znanja - sistem 24x7 tehnične podpore) smo našli potrebne popravke za kombinacijo verzije operacijskega sistema in verzije baze Oracle 8i ter jih prenesli na bazni strežnik. Potrebno je bilo namestiti naslednje skupine popravkov: VMS721_SYS-V1200 TCPIPALP_E03A50 VMS721_LIBRTL-V0400 VMS_RMS-V0500 VMS721_ACRTL-0400

Vsaka taka skupina vsebuje več dejanskih popravkov, ki jih je potrebno namestiti.



Na primer skupina VMS721_SYS-V1200 vsebuje naslednje popravke: DEC-AXPVMS-VMS721_PCSI-V0100--4 DEC-AXPVMS-VMS721_UPDATE-V0300--4 DEC-AXPVMS-VMS721_LAN-V0300--4 DEC-AXPVMS-VMS721_AUDSRV-V0200--4 DEC-AXPVMS-VMS721_CLIUTL-V0300--4 DEC-AXPVMS-VMS721_MOUNT96-V0300--4 DEC-AXPVMS-VMS721_SYS-V1200--4 DEC-AXPVMS-VMS721_FIBRE_SCSI-V0600--4 DEC-AXPVMS-VMS721_LAN-V0300--4 DEC-AXPVMS-VMS721_MOUNT96-V0300--4 DEC-AXPVMS-VMS721_AUDSRV-V0200--4 DEC-AXPVMS-VMS721_CLIUTL-V0300--4 DEC-AXPVMS-VMS721_SYSLOA-V0200--4

Popravke na OpenVMS smo namestil s "POLYCENTER Software Installation utility". Potrebno je razpakirati (self extract) vsako skupino popravkov tako, da se razpakira vsak popravek na svoj pod-imenik. Namestitev se zažene iz ukazne vrstice z ukazom: $ product install * (znak * namesto imena popravka) In za prvi popravek iz skupine VMS721_SYS-V1200 je postopek: $ product install * The following product has been selected: DEC AXPVMS VMS721_PCSI V1.0 Patch (maintenance update) Do you want to continue? [YES] Configuration phase starting ... You will be asked to choose options, if any, for each selected product and for any products that may be installed to satisfy software dependency requirements. DEC AXPVMS VMS721_PCSI V1.0: OpenVMS V7.2-1 PCSI V1.0 * This product does not have any configuration options. Execution phase starting ... The following product will be installed to destination: DEC AXPVMS VMS721_PCSI V1.0 DISK$OPENVMS:[VMS$COMMON.] Portion done: 0%...10%...30%...50%...90%...100% The following product has been installed: DEC AXPVMS VMS721_PCSI V1.0 Patch (maintenance update) DEC AXPVMS VMS721_PCSI V1.0: OpenVMS V7.2-1 PCSI V1.0 VMS721_PCSI-V0100 Release notes available



Release notes for the VMS721_PCSI V1.0 kit are available in the SYS$HELP: directory.

Installing this patch kit requires a reboot. Compaq strongly recommends that you reboot your system immediately after installation of this kit. The images in this kit will not fully take effect until the system is rebooted.

Ta postopek je treba ponoviti za vsak popravek posebej, kar je precej zamudno še posebej, ker nekateri popravki zahtevajo ponovni zagon sistema pred namestitvijo naslednjega popravka. Potrebno je biti pozoren na morebitna obvestila o napakah ali neuspelih namestitvah. Iz petih skupin je bilo potrebno namestiti 17 popravkov in kar nekajkrat ponovno zagnati sistem. Postopek nameščanja popravkov je potekal 6 ur. 5.3. Nadgradnja (ponesrečen poizkus) 5.3.1 Težave Naslednji konec tedna smo začeli z nadgradnjo baze Oracle7. Že na začetku smo naleteli na težavo - zataknilo se je pri zaustavitvi baze. Pri ukazu: SQL> shutdown immediate

je baza "obvisela" iz neznanega razloga. Kasnejša analiza je pokazala, da bi to lahko bila to posledica neskladja novih popravkov operacijskega sistema s staro verzijo baze, možen pa je bil tudi kakšen drug razlog. Za zaustavitev je bil potreben ukaz: SQL> shutdown abort

Potem smo pognali export baze na trak. Naslednje jutro smo, po pregledovanju log datotek ugotovil, da ni šlo vse kot bi moralo. V log datoteki smo našli zapise: EXP-00008: ORACLE error 1578 encountered ORA-01578: ORACLE data block corrupted (file # 39, block # 683857) ORA-01110: data file 39: 'DISK$DATA04:[ORACLE.SPLPROD]SPLDATA17.DBS' . . exporting table PROTI_POSTAVKE_DOBAVITELJI 1338349 rows exported . . exporting table PROTI_POSTAVKE_KUPCI EXP-00014: error on row 4813826 of table PROTI_POSTAVKE_KUPCI EXP-00008: ORACLE error 1578 encountered ORA-01578: ORACLE data block corrupted (file # 39, block # 647753) ORA-01110: data file 39: 'DISK$DATA04:[ORACLE.SPLPROD]SPLDATA17.DBS' . . exporting table PROTI_POSTAVKE_TERJATVE EXP-00014: error on row 45001634 of table PROTI_POSTAVKE_TERJATVE .....



Za test smo poskusili prešteti zapise v eni od okvarjenih tabel: SQL> select count(*) from proti_knjizbe_kupci; ERROR: ORA-01578: ORACLE data block corrupted (file # 39, block # 683857) ORA-01110: data file 39: 'DISK$DATA04:[ORACLE.SPLPROD]SPLDATA17.DBS'

Ugotovili smo, da je bilo 7 tabel, ki so imele okvarjene (corrupted) bloke. Da je bil položaj še slabši, so te tabele med največjimi v bazi. Shutdown database Oracle bazo lahko ustavimo (shutdown) na več načinov:

1) SQL> shutdown

to je navaden, privzeti način ustavljanja baze. Tak način ustavljanja se v resnici le malokrat uporablja, ker v tem primeru Oracle počaka na vse uporabnike, da končajo z delom na bazi in potem prepiše vse spremenjene podatke iz pomnilnika na diske. Taka zaustavitev je znana kot "clean shutdown". Večinoma taka zaustavitev niti ni izvedljiva, ker se je lahko na primer nek uporabnik pozabil odjaviti iz baze in bi tako morali čakati, da se vrne.

2) SQL> shutdown immediate

se uporablja najpogosteje. Ta ukaz prepreči vse nadaljnje prijave v bazo, izvede rollback vseh nepotrjenih (uncommitted) transakcij in šele nato izvede zaustavitev. V procesu zaustavljanja bo Oracle prav tako prepisal vse spremenjene podatke iz pomnilnika na diske.

3) SQL> shutdown abort

če se zgodi, da ukaz shutdown immediate ne zaustavi baze, je treba uporabiti ukaz shutdown abort, ki je zelo "trd" način ustavljanja baze (database hard crash). V tem primeru Oracle zaustavi svoje procese (background processes), odstrani deljene pomnilniške segmente (shared memory segments) in zaustavi Oracle instanco. Nepotrjene transakcije ostanejo nedotaknjene v redolog datotekah četudi podatki, ki so bili spremenjeni v teh transakcijah še niso bili zapisani na diske. Ob ponovnem zagonu baze se izvede obnovitveni postopek (instance recovery) in se transakcije zaključijo s pomočjo podatkov v redolog datotekah. Oracle ne svetuje zaustavljanja baze na način shutdown abort v produkcijskem okolju.



Logična struktura baze Tablespace (podatkovno področje)

Baza je razdeljena na logične enote imenovane tablespace, ki združujejo med sabo povezane logične strukture, objekte. Večinoma so v takem podatkovnem področju združeni objekti, ki nastanejo v sklopu ene aplikacije, zaradi lažjega upravljanja. Vsaka baza je logično razdeljena v enega ali več podatkovnih področij.

Data blocks (podatkovni bloki)

Na najnižjem nivoju Oracle shranjuje podatke v podatkovne bloke. Velikost enega podatkovnega bloka je določeno število bajtov (bytes) fizičnega prostora na disku in je definirana z inicializacijskim parametrom db_block_size.

Zgradba podatkovnega bloka (Slika 8)

Slika 8: Zgradba podatkovnega bloka (Vir: Oracle Database Concepts, 2002)

Zgradba podatkovnega bloka je podobna, ne glede na vrsto bloka (data, index,..): Header

vsebuje splošne informacije o bloku, kot na primer naslov (block address) in vrsto bloka.



Table Directory vsebuje informacije o tabeli, ki ji pripadajo vrstice (raws) v tem podatkovnem bloku

Row Directory

vsebuje informacije o dejanskih vrsticah v bloku - naslovi vrstic v podatkovnem področju vrstic (raw data area)

Free Space

dodeljen prostor za vstavljanje novih vrstic ali ažuriranje vrstic, ki potrebujejo dodaten prostor

Raw Data

vsebuje podatke (data ali index)

Extent (Podaljšek), (Slika 9)

Extent je določeno število strnjenih (contiguous) podatkovnih blokov, ki nastane pri enem dodeljevanju (allocate), novega prostora za podatke.

Slika 9: Database Blocks, Extents, Segments (Vir: Oracle Database Concepts, 2002)



Segment Segment je množica podaljškov (extent) združenih v določeno logično strukturo. V Oracle bazi obstajajo naslednje vrste segmentov:

• Data - za podatke shranjene v tabelah • Index - za shranjevanje indeksnih podaljškov • Temporary - segmenti za začasne potrebe baze

(npr. v primeru sortiranja podatkov) • Rollback - za zagotavljanje konsistence branja podatkov,

za razveljavljanje (rollback) nepotrjenih (uncommited) transakcij in za obnovitev baze v primeru nepravilne zaustavitve.

Okvarjeni bloki (Corrupted Blocks) Okvarjeni podatkovni blok je blok, katerega zgradbo Oracle ne prepozna kot lastno ali katerega vsebina ni konsistentna na nivoju notranje strukture. Največkrat pride do okvare bloka zaradi okvare strojne opreme ali zaradi napak operacijskega sistema. Oracle SUBP identificira okvaro kot:

• logična okvara - logically (software) corrupt • okvara medija - media corrupt

V primeru logične okvare bloka, Oracle označi ta blok kot "corrupt block", na nivoju baze pa se zabeleži kot interna napaka (internal error). V primeru okvare medija zgradba bloka ni več pravilna, informacija prebrana iz takega bloka pa je nesmiselna. Zaznava in odprava okvarjenih blokov Oracle SUBP ima več orodij za zaznavo in odpravo okvarjenih blokov (Tabela 5).

orodje zazna vrsto okvare

odpravi okvaro

DBVERIFY fizično NE ANALYZE logično NE DB_BLOCK_CHECKING logično NE DB_BLOCK_CHECSUM fizično NE exp fizično NE DBMS_REPAIR logično DA block media recovery nobene DA

Tabela 5: orodja za zaznavo in odpravo okvarjenih blokov (Vir: Oracle, 2006)



DBVERIFY DBVERIFY je zunanje orodje (external command-line utility), ki preveri fizično integriteto podatkovne strukture baznih datotek, ko baza deluje (online) in kadar je ustavljena (offline). Na OpenVMS operacijskem sistemu deluje le v offline načinu. Orodje je zelo uporabno tudi za preverjanje integritete backup datotek pred morebitno obnovitvijo (restore). Na OpenVMS operacijskem sistemu poženemo DBVERIFY: $ dbv file=dev:[directory]db_file_name.dbf blocksize=4096

Če ne vemo kolikšna je velikosti bloka, lahko le-to preverimo: SQL> show parameter db_block_size; NAME TYPE VALUE ------------------------------------ ------- ---------------- db_block_size integer 4096

Orodje DBVERIFY ima tudi nekaj omejitev:

• ne zazna problemov neujemanja med podatki in indeksi. To lahko zaznamo z ukazom ANALYZE TABLE

• ne preverja redo log in control datotek • preverja le blok posamezno in ne kot del obstoječega objekta

Ukaz ANALYZE Ukaz ANALYZE se uporablja za preverjanje strukture tabel, tabelnih razdelkov (particij) in indeksov ter indeksnih razdelkov. Za preverjanje objekta je potrebno, da je objekt v lokalni shemi ali pa je potrebno imeti dodatni privilegij - ANALYZE ANY privilege. Možnost CASCADE pri ukazu ANALYZE preverja objekt in vse, z njim povezane, objekte. Ukaz ANALYZE se požene iz SQL*Plus orodja: SQL> analyze table validate structure cascade;

Obstoj okvarjenih blokov v baznem objektu je načeloma možno ugotavljati z vsakim orodjem, ki omogoča "full table scan" tega objekta - npr. s SQL*Plus orodjem: SQL> select * from ;

ali z eksportom objekta (exp utility): $ exp un/pw table= file=



DB_BLOCK_CHECKING (preverjanje v realnem času) Z nastavitvijo inicializacijskega parametra DB_BLOCK_CHECKING na vrednost TRUE dosežemo, da Oracle preverja konsistenco vseh blokov pred branjem in tako lahko prepreči potencialno okvaro podatkovnih struktur. Ta postopek preverjanja blokov povzroči v povprečju od 1% do 10% dodatne obremenitve, odvisno od celotne obremenitve sistema (workload). V primeru, da je dodatna obremenitev sprejemljiva iz vidika celotne zmogljivosti sistema, se priporoča, da je vrednost parametra nastavljena na TRUE (privzeta vrednost je FALSE). DB_BLOCK_CHECKSUM (preverjanje v realnem času) Oracle omogoča še dodaten mehanizem za preprečevanje okvare podatkovnih blokov. V primeru, da je vrednost inicializacijskega parametra DB_BLOCK_CHECKSUM nastavljena na TRUE, Oracle DBWn proces (Database Writer Process) izračuna kontrolno vsoto (checksum) in jo zapiše v cache header vsakega bloka, preden ga zapiše na disk. Kontrolna vsota se izračuna na podlagi vseh bajtov shranjenih v bloku. Pri kasnejšem branju tega bloka se ponovno izračuna kontrolna vsota in se primerja s kontrolno vsoto, ki je zapisana v bloku. S preverjanjem kontrolne vsote lahko Oracle zazna okvarjene bloke, ki nastanejo na diskih ali diskovnih podsistemih, kar prinese le 1% do 2% dodatne obremenitve sistema. Zaradi varnosti podatkov in majhne dodatne obremenitve sistema, Oracle priporoča nastavitev parametra DB_BLOCK_CHECKSUM na vrednost TRUE. EXP Orodje za eksport EXP zazna okvarjene bloke in zapiše podatke o okvarjenem bloku v log datoteko. Na primer:

ORA-01578: ORACLE data block corrupted (file # 39, block # 683857) ORA-01110: data file 39: 'DISK$DATA04:[ORACLE.SPLPROD]SPLDATA17.DBS'

DBMS_REPAIR paket (package) DBMS_REPAIR PL/SQL paket je eden od paketov, ki so del Oracle SUBP. Ta paket se lahko uporabi za zaznavo okvarjenega bloka ali odpravo okvare bloka. Paket vsebuje več procedur, odvisno od verzije Oracle SUBP. Za zaznavo okvarjenih blokov lahko uporabimo CHECK_OBJECT proceduro. Najprej je potrebno kreirati "repair" tabelo, kamor Oracle zapiše podatke o okvarjenih blokih:



BEGIN DBMS_REPAIR.ADMIN_TABLES ( table_name => 'REPAIR_TABLE', table_type => DBMS_REPAIR.REPAIR_TABLE, action => DBMS_REPAIR.CREATE_ACTION, tablespace => 'USERS'); END;

nato preverimo okvarjene bloke v objektu IME_TABELE : DECLARE stev_okvarjenih_blokov INT; BEGIN stev_okvarjenih_blokov:=0; DBMS_REPAIR.CHECK_OBJECT ( schema_name => '', object_name => '', repair_table_name => 'REPAIR_TABLE', corrupt_count => stev_okvarjenih_blokov); END;

Podatki o okvarjenih blokih v tabeli IME_TABELE in napotki za odpravo okvare se zapišejo v tabelo "REPAIR_TABLE". Procedura FIX_CORRUPT_BLOCKS omogoča odpravo okvarjenih blokov, kolikor je mogoče v sklopu paketa DBMS_REPAIR, za ostale okvare pa se uporabi procedura SKIP_CORRUPT_BLOCKS, ki omogoča uporabo objekta kljub okvarjenim blokom. Velikokrat ni možno odpraviti okvare bloka, zato je potrebno zagotoviti obnovo okvarjenega bloka. Če smo ugotovili napako na primer: ORA-01578: ORACLE data block corrupted (file # 37, block # 10)

je potrebno najprej poiskati objekt, ki vsebuje ta okvarjen blok: SQL> SELECT segment_name, segment_type, relative_fno FROM dba_extents WHERE file_id = 37 AND 10 BETWEEN block_id AND block_id + blocks - 1; SEGMENT_NAME SEGMENT_TYPE RELATIVE_FNO ------------------ ------------- ------------ TERJATVE TABLE 37

Ko ugotovimo ime objekta in vrsto objekta (v tem primeru "TERJATVE" in "TABLE"), je treba določiti najprimernejši način obnove. V primeru baze Oracle8i in višje, lahko to tabelo označimo za corrupted: SQL> execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('','');



in jo prepišemo v novo tabelo, na primer: SQL> create table NOVE_TERJATVE as select * from TERJATVE;

V starejših verzijah od 8i to ne deluje in je potrebno na nivoju seje (session) napisati ukaz: SQL> alter session set events '10231 TRACE NAME CONTEXT FOREVER, LEVEL 10';

nato pa lahko prepišemo okvarjeno tabelo. Export te tabele pa še vedno ne bi uspel, ker ukaz alter session velja le za trenutno sejo. Export okvarjene tabele pa bi lahko izvedli v primeru, da bi ta event nastavili na nivoju instance. V datoteko INIT.ORA bi morali vpisati: event = "10231 trace name context forever, level 10"

in ponovno dvigniti bazo. Manjkajoče vrstice tabele lahko povrnemo s pomočjo arhiva (export) ali pa jih, če je to mogoče, ponovno kreiramo s pomočjo poznavanja aplikacije. V primeru okvarjenega bloka v indeksu, je tak indeks najbolje ponovno kreirati. 5.3.2 Sanacija težav O situaciji so bili seznanjeni vsi sodelavci iz ITja in za nasvet smo prosili analitika v tehnični podpori Oracle Slovenija. Po daljši analizi nastalega položaja smo ocenili, da z nadgradnjo baze tokrat ne bo nič in da bo potrebno veliko znanja in sreče, da bomo do ponedeljka spravili bazo v stanje pred poskusom nadgradnje. Kar nekaj ur smo potrebovali, da smo izdelali potreben scenarij za reševanje problema. Ugotovili smo, da v obstoječi bazi ne bo možno obnoviti vsebine pokvarjenih blokov. Ideja je bila, da bi prepisali vsebino tabel brez okvarjenih blokov. S pomočjo nasvetov analitika iz Oracle Slovenija smo uspeli postaviti bazo v način delovanja, ko je možno pri branju cele tabele (full table scan - npr. export) preskočiti okvarjene bloke. V datoteko INIT.ORA, v kateri so shranjeni začetni parametri za zagon baze, smo vpisali: event="10231 trace name context forever, level 10"



To pomeni, da bo baza pri ponovnem zagonu, pri branju celotne tabele, preskočila okvarjene bloke (skip software and media corrupted blocks when performing full table scans). Na ta način smo lahko izvedli export okvarjenih tabel na trak: $ exp un/pw - buffer=131072 - recordlength=8192 - file=mkc400:CORR_060225.DMP - compress=N - statistics=NONE - tables=(PROTI_KNJIZBE_KUPCI,PROTI_POSTAVKE_KUPCI,

PROTI_POSTAVKE_TERJATVE,SALDAKONTI_KUPCI,SALDAKONTI_KUPCI_LOG, STROSEK_ODJ_MESTO,TERJATEV_ODJ_MESTO)

Zatem smo pobrisali okvarjene tabele iz baze: $ sqlplus un/pw - SQL> drop table PROTI_KNJIZBE_KUPCI; SQL> drop table ...

Po brisanju tabel pa je sledil prenos (import) teh tabel iz traku nazaj v bazo: $ imp un/pw - buffer=131072 - file=mkc400:CORR_060225.DMP - tables=(PROTI_POSTAVKE_KUPCI,PROTI_POSTAVKE_TERJATVE,

SALDAKONTI_KUPCI,SALDAKONTI_KUPCI_LOG, STROSEK_ODJ_MESTO,TERJATEV_ODJ_MESTO) -

ignore=Y - indexes=N - commit=Y

Tako smo dobili v bazi tabele, ki niso imele več okvarjenih blokov, vendar je ostal problem kako obnoviti manjkajoče bloke. Ugotovili smo, da obstaja v ostalih baznih tabelah dovolj podatkov, da bo programerski del ekipe ITja lahko kreiral manjkajoče vrstice tabel s pomočjo poznavanja vsebine poslovanja. To jim je z veliko truda uspelo kasneje, v naslednjih dneh. Ker ni bilo možno preveriti take količine podatkov v času, ki je bil na razpolago, smo imeli prvi delovni dan bazo odprto le za vpogled.



5.4. Nadgradnja

Da se ne bi težave pri naslednjem poizkusu nadgradnje ponovile smo naredili sledeče:

• vzpostavili smo stanje operacijskega sistema na stanje pred namestitvijo popravkov (obnovitev sistemskega diska - restore stand-alone backup sistema iz traku):

$$$ back/image/rewind MKD300:.sav/save DKB0:

• po nasvetu analitika iz Oracle Slovenija smo uvedli dodatni varnostni mehanizem - v datoteko INIT.ORA smo dodatno vpisali:

db_block_checking = TRUE db_block_checksum = TRUE

S tem smo zagotovili dodatno preverjanje vseh baznih blokov. Zaradi uvedbe teh parametrov baza sicer deluje nekoliko počasneje, vendar izguba hitrosti ni velika v primerjavi z večjo varnostjo delovanja. Konec naslednjega tedna smo ponovno začeli z nadgradnjo baze. Tokrat smo, da bi se izognili težavam, namenili celotnemu postopku en dan več in zraven vključili tudi nadgradnjo operacijskega sistema strežnika. Plan nadgradnje je bil enak kot pri prvem poizkusu. 5.4.1 Postopek namestitve Oracle8i na OpenVMS operacijski sistem Tokrat je postopek stekel brez težav. Po namestitvi popravkov na OpenVMS, varnostni kopiji sistema, exportu in varnostni kopiji baze, smo začeli z namestitvijo baze. Na nobenem strežniku ni bil nameščen grafični vmesnik za OpenVMS (X-Windows), zato smo namestili novo verzijo Oracle RDBMS kar preko znakovnega "character-based" vmesnika - verzija 8i je zadnja, pri kateri je taka namestitev še možna.

• najprej smo kreirali ORA_ROOT imenik in začasni imenik na nekem drugem disku

• na začasni imenik smo skopirali datoteke - save_sets (OpenVMS backup struktura) iz namestitvenih CD medijev

• razpakirali smo "začetni" save_set - BOOT.BCK:

$ BACK/LOG disk$arhiv:[temp]BOOT.BCK/save - _$ ORA_ROOT:[000000]/by_owner=parent

• zatem smo pognali OpenVMS proceduro ORACLEINS na

ORA_ROOTDIR:



Software Installation and Upgrade Menu ______________________________________ 1. Select Licensed Products to Load 2. Select Build Configuration Options 3. Load and Build Selected Licensed Products 4. Build Selected Licensed Products Warning: You may not be licensed for all products listed Enter a number or (E)XIT to return to the Main Menu: 1

tu smo izbrali komponente, ki jih bomo namestil: Select Licensed Products to Load for Installation or Upgrade ____________________________________________________________ Product Name Status Product Name Status 1. APACHE 14. OWM 2. CTX 15. PQOPT 3. DBJAVA - load 16. PROGINT - load 4. DDBOPT - load 17. PSOPT 5. DPOPT 18. RDBMS - load 6. JAVAVM - load 19. SDOPT 7. NETCONFIG - load 20. SQLJ - load 8. NLS - load 21. SQLPLUS - load 9. OBJOPT - load 22. SVRMGR - load 10. OEMAGENT - load 23. UTIL - load 11. ORDIM 12. ORDTS 13. ORDVIR Enter (A)LL to select all products. Enter (E)XIT to exit this menu with selected products. Enter (Q)UIT to quit this menu with no action. Enter the number of the product that you want to load:

Pri tem meniju označimo vse tiste produkte, ki jih želimo namestiti.

Nato se vrnemo v prejšnji meni in izberemo opcijo:

3. Load and Build Selected Licensed Products ..

Ko se load procedura konča, se razpakirajo še ostali save_seti. %BACKUP-S-CREATED, created ORA_ROOT:[UTIL]TLEMUS.MSB;1 %BACKUP-S-CREATED, created ORA_ROOT:[UTIL]UTIL.CTL;1 %BACKUP-S-CREATED, created ORA_ROOT:[UTIL]UTIL.DEF;1 %BACKUP-S-CREATED, created ORA_ROOT:[UTIL]UTILUSER.COM;1 12 products have been successfully loaded. The products you requested have been loaded. You have the following options: 1. Build the Oracle products loaded. 2. Return to the Software Installation and Upgrade Menu (to choose new configuration values or to load additional products from another tape or directory). Enter the number of the option you want [2]:



Vrnemo se v osnovni meni: 11 products have been successfully loaded. The products you requested have been loaded. You have the following options: 1. Build the Oracle products loaded. 2. Return to the Software Installation and Upgrade Menu (to choose new configuration values or to load additional products from another tape or directory). Enter the number of the option you want [2]: 2 Software Installation and Upgrade Menu ______________________________________ 1. Select Licensed Products to Load 2. Select Build Configuration Options 3. Load and Build Selected Licensed Products 4. Build Selected Licensed Products Warning: You may not be licensed for all products listed Enter a number or (E)XIT to return to the Main Menu: 2

potem smo izbrali možnost 18 (RDBMS) in popravili privzete vrednosti za particioniranje in Javo: 7. Include Data Partitioning option? [Y/N] Y 9. Include Java Aurora external option? [Y/N] Y

Zatem zgradimo (build) licencirane produkte: Software Installation and Upgrade Menu ______________________________________ 1. Select Licensed Products to Load 2. Select Build Configuration Options 3. Load and Build Selected Licensed Products 4. Build Selected Licensed Products Warning: You may not be licensed for all products listed Enter a number or (E)XIT to return to the Main Menu: 4 - Creating list of products to (re)build. - Running ORA_NETCONFIG_BLD.COM. - Creating ORA_NETCONFIG:NTCONTAB.MAR (32-bit version) - Creating ORA_NETCONFIG:NTCONTAB.MAR (64-bit version) - Creating NAUTAB (32-bit version) - Creating NAUTAB (64-bit version) - Linking BEQLSNR.EXE - Linking LSNRCTL.EXE - Linking TNSLSNR.EXE - Linking TNSLSNR_64.EXE ....



- Running ORA_RDBMS_BLD.COM. - Linking shared ORACLE client image - 64 bit - Building ORACLE Server with the following configuration parameters RDBMS image : ORACLE Root directory : DISK$ORACLE:[ORACLE] Parallel Server option : N Distributed database option : N Context option : N Object option : Y Spatial Data option : N Accessible by : SYSTEM Data Partitioning option : Y Java Aurora external option : N -- Ta možnost mora imeti vrednost Y, -- da se v bazi namesti JAVA - Linking ORACLE Server - (oracle) - Moving demo files to ORA_RDBMS_DEMO directory. - Moving admin files to ORA_RDBMS_ADMIN directory. - Moving java files to ORA_RDBMS_JLIB directory. - Linking MIG.EXE - Linking EXP.EXE - Linking IMP.EXE - Linking SQLLDR.EXE - Linking RMAN.EXE - Linking SBTTEST.EXE ... 11 products have been successfully built.

v tem delu smo definirali še ostale parametre, pomembne za namestitev: RDBMSDB Configuration Options Option Current Value 1. System or Group Installation? [S/G] S 2. Root directory for database administration ORA_ROOT:[000000] directory (ORA_DB)? 3. Initial database file for SYSTEM Tablespace? DISK$ORACLE:[ORACLE.PROD]SYST.. 4. Initial size of SYSTEM Tablespace? 1000M 5. Log File 1? DISK$ORACLE:[ORACLE.PROD]LOGM.. 6. Log File 1 Size? 100M 7. Log File 2? DISK$ORACLE:[ORACLE.PROD]LOGM.. 8. Log File 2 Size? 100M 9. Control File 1 Name? DISK$ORACLE:[ORACLE.PROD]CONT.. 10. Control File 2 Name? DISK$OPENVMS:[ORACLE.PROD]CON.. 11. Value for MAXDATAFILES (1..999999999)? 512 12. Value for MAXLOGFILES (2..254)? 32 13. Value for MAXINSTANCES (1..63)? 16 14. Value for MAXLOGMEMBERS (1..5)? 4 15. Value for MAXLOGHISTORY (0..5000)? 1600 16. Value for CHARACTER SET? EE8ISO8859P2 *ISO 8859-2 oz.Latin-2 Enter (A)LL to select all options. Enter (E)XIT to exit this menu with selected options. Enter (Q)UIT to quit this menu with no action. Enter the number of the option that you want to change: E Continuing will initialize your database. Do you want to continue (Y/N)? [Y]

Preden se potrdi ta korak je nujno, iz druge seje, popraviti nekaj parametrov v inicializacjski datoteki init.ora, ki se jih kasneje ne da popravit - recimo DB_BLOCK_SIZE, ki določa velikost baznega bloka - npr. na 8KB (privzeta vrednost je 2KB)



Now creating the initial data file, control files, and log files of your database... Database startup/create in progress - please wait... Now running catalog - please wait... Creating a database can take a significant amount of elapsed time. You can monitor the progress by checking the size of the log file. Due to options chosen, the log file may be over 26000 blocks in size. Looking for fatal errors in log file: %SEARCH-I-NOMATCHES, no strings matched

Zadnje sporočilo pomeni, da pri namestitvi ni bilo napak. 5.4.2 Postopki po nadgradnji strežnika Ko se namestitev konča, Java v bazi še ni nameščena, zato je potrebno pognati namestitveno proceduro INITJVM na imeniku ora_root:[javavm.install], iz Oracle sheme SYS ali SYSTEM. Pred tem je potrebno preveriti, če je dovolj prostora v sistemskem prostoru (system tablespace). Namestitev Jave potrebuje vsaj 85MB prostora v bazi. Če ni vsaj 100MB prostega prostora v sistemskem prostoru, ga je treba povečati. Velikost prostega prostora preverimo: SQL> select sum(bytes)/1024/1024 "Prosto (MB)" from dba_free_space where tablespace_name = 'SYSTEM'; Prosto (MB) ----------- 216,8125

Število javanskih objektov v bazi preverimo s poizvedbo: SQL> select count(*) from dba_objects where object_type like '%JAVA%'; COUNT(*) ---------- 6784

Po preverjanju števila javanskih objektov je potrebno še:

• preveriti in popraviti mrežne nastavitve. Oracle teče na strežniku kot odjemalec-strežnik (client-server) aplikacija in je dostop do baze vedno v načinu odjemalec-strežnik, tudi če do baze dostopamo kar na strežniku, kjer je nameščena baza.

• nastaviti je potrebno datoteko TNSNAMES.ORA. Ta omogoča, da se definirajo servisi baze podatkov:



SPLPROD = # net service name .. (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (Host = 193.193.193.10) (Port = 1526) ) (ADDRESS = (PROTOCOL = TCP) (Host = 193.193.193.10) (Port = 1521) ) ) (CONNECT_DATA = (SID = PROD) ) ) SPLPROD = # net service name .. (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (Host = 193.193.193.10) (Port = 1521) ....

• potrebno je zagotoviti, da Oracle mrežni protokol SQL*NET teče

pravilno Pripravljena konfiguracijska datoteka SQLNET.ORA:

automatic_ipc = OFF trace_level_client = OFF trace_directory_client = disk$oracle:[oracle.network.trace] trace_file_client = client names.directory_path = TNSNAMES

• nastaviti in zagnati je potrebno Listener proces. Ta proces omogoča

odjemalcem povezave z bazo.

Pripravljena datoteka LISTENER.ORA:

LST01 = (ADDRESS_LIST = (ADDRESS= (PROTOCOL=IPC) (KEY= ORA_01) ) (ADDRESS= (PROTOCOL=IPC) (KEY= V8174_1) ) (ADDRESS = (PROTOCOL = TCP) (Host = 193.193.193.10) (Port = 1526) ) ) STARTUP_WAIT_TIME_LST01 = 0 CONNECT_TIMEOUT_LST01 = 10 TRACE_LEVEL_LST01 = off trace_directory_lst01=disk$oracle:[oracle.network.trace]



trace_file_listener=lst01 # USE_DEDICATED_SERVER = ON SID_LIST_LST01 = (SID_LIST = (SID_DESC = (SID_NAME = PROD) #instanca 1 (PROGRAM = disk$oracle:[oracle.network.admin]orasrv_v2_ PRO.com) (TIMEOUT = 0) ) (SID_DESC = (SID_NAME = PROD) #instanca 2 (PROGRAM = disk$oracle:[oracle.network.admin]orasrv_v2_ PRO.com) (TIMEOUT = 0) ) )

• Določimo optimalno velikost SGA, buffer cache, log buffer, logfile ..

db_file_multiblock_read_count = 32 # št. blokov pri full-table scan branju db_block_buffers = 352236 # velikost buffer-cache shared_pool_size = 200000000 # velikost shared-pool predpomnilnika java_pool_size = 20971520 # velikost pomnilnika za Javo log_buffer = 2097152 # velikost redo-log buffer

• Ponovno preverimo in prevedemo neveljavne objekte (recompile invalid objects) z ukazi: SQL> select object_name, object_type from dba_objects where status != 'VALID';

SQL> select 'alter ' || object_type || ' '|| object_name || ' compile;' from user_objects where object_type 'PACKAGE BODY' and status = 'INVALID' union select 'alter package ' || object_name || ' compile body;' from user_objects where object_type = 'PACKAGE BODY' and status = 'INVALID';

V tej fazi smo imeli delujočo bazo Oracle osnovne verzije 8.1.7.0.0. Naš cilj pa je bil Oracle verzije 8.1.7.4.0, zato je bilo za dvig verzije potrebno namestiti: Oracle 8i Data Server Patch Set for HP OpenVMS Alpha Po priporočilih Oracle smo izvedli varnostno kopijo dosedanje namestitve. Zatem je bilo potrebno kreirati nov imenik: $ create/dir ORA_ROOT:[PATCHSET]

in s protokolom FTP prenesti (binarno) paket ter ga razpakirati: $ unzip p2376472_8174_AXP.zip

Potrebno je bilo ustaviti vse instance in zaustaviti bazo, SQL> shutdown immediate



odstraniti vse nameščene programe (deinstall installed images), $ remoracle

in ustaviti listener proces $ lsnrctl stop

Zatem smo pognali "patch installer" $ @install_patc.com 81740 $ oracleins (rebuild all products)

Pred nadaljnjimi procedurami za izgradnjo baznega kataloga in baznih procedur je nujno onemogočiti sistemske prožilce (disabling system triggers): Da bi to storili smo v inicializacijsko datoteko INIT.ORA vpisali parameter: _SYSTEM_TRIG_ENABLED=FALSE

Zatem smo iz imenika ORA_ROOT:[RDBMS.ADMIN], iz SQL*Plus orodja pognali naslednje ukazne datoteke: catalog.sql, catproc.sql, catrep.sql

Da bi ponovno omogočili sistemske prožilce smo brisali vrstico _SYSTEM_TRIG_ENABLED=FALSE iz INIT.ORA datoteke in ponovno dvignili bazo. Ostalo je še prevajanje vseh neveljavnih PL/SQL paketov (packages): $ sqlplus /nolog SQL> connect / as sysdba -- prijava v shemo SYS SQL> @ora_root:[rdbms.admin]utlrp.sql

Po končanih postopkih je nameščena verzija baze 8.1.7.4.0 : SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production PL/SQL Release 8.1.7.4.0 - Production CORE 8.1.7.0.0 Production TNS for VMS: Version 8.1.7.4.0 - Production NLSRTL Version 3.4.1.0.0 - Production



Namestitev popravka "Critical Patch Update" (#4751906) Ta popravek naj bi odpravljal vse, do takrat znane napake v bazi (bugs). Pred namestitvijo je potrebno preveriti in zagotoviti:

• da so ustavljeni vsi Oracle procesi • da je vzpostavljeno Oracle okolje (OpenVMS logična imena

ORA_ROOT, ORA_SID..) • da je kreiran podimenik [PATCHES], kamor se kopira "patch datoteka"

(p4751906_8174_AXP.zip) • da se razpakira "patch datoteka" Iz imenika ORA_ROOT:[PATCHES.PATCH4867451_BASEBUG4751906] se požene ukazna datoteka:

$ @install_patch

Izvajanje ukazne datoteke se je končalo brez napak. 5.4.3 Predpriprava za import - kreiranje objektov Po končanem nameščanju tega popravka smo kreirali še vse potrebne bazne objekte, kot so dodatni tablespace za uporabniške tabele, indekse, začasne strukture (temp) in rollback segmente. Za večino teh objektov smo si pripravili ukazne datoteke (scripts) že iz prejšnje verzije baze tako, da je postopek tekel lažje in hitreje. S pomočjo takih ukaznih datotek smo vnaprej kreirali 15 največjih tabel, da smo lahko pripravil prazen prostor za prenos (import) podatkov: CREATE TABLE TERJATEV_ODJ_MESTO ( ODJEMNO_MESTO NUMBER(7) NOT NULL, ID_STROSKA NUMBER(8) NOT NULL, PARTNER NUMBER(6) NOT NULL, ID_TERJATVE NUMBER(8), SALDO_TERJATVE NUMBER(15,2), ZNESEK NUMBER(15,2) NOT NULL, STATUS VARCHAR2(1), STATUS_PRENOSA VARCHAR2(1), DATUM_TERJATVE DATE, DATUM_VALUTE DATE, NACIN_PLACILA VARCHAR2(2), OBCINA NUMBER(4), TIP_DOKUMENTA VARCHAR2(1), POSTAVKA NUMBER(5), VRSTA_DOKUMENTA NUMBER(2), STATUS_IZPISA NUMBER(1), IZTERLJIVOST VARCHAR2(1), OBRESTI VARCHAR2(1), DATUM_OD DATE, DATUM_DO DATE, ... )



TABLESPACE SPLDATA PCTUSED 40 PCTFREE 10 INITRANS 1 MAXTRANS 255 STORAGE ( INITIAL 1000M -- začetna velikost tabele NEXT 1000M -- velikost naslednjega extenta MINEXTENTS 10 -- začetno število extentov MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 ) NOCACHE NOPARALLEL; Alter table TERJATEV_ODJ_MESTO storage (next 50M);

To tabelo smo kreirali prazno, veliko 10GB, vsak njen naslednji podaljšek (extent), ko bo 10GB polnih, pa bo velik 50 MB. 5.4.4 Prenos (import) podatkov Sedaj je bila baza pripravljena za prenos podatkov. Zato smo pripravili ukazno datoteko na nivoju operacijskega sistema: $ mount/media=compact/cache=tape_data - /blocksize=40960/recordsize=40960 MKC400: EXP16 $ on warning then continue $ on error then goto err $!----- $ imp un/pw - ! import podatkov buffer=262144 - file=MKC400:FULL_060316.DMP - fromuser=SHEMA_NAME - touser=SHEMA_NAME - ignore=Y - indexes=N - ! indekse bom kreiral kasneje commit=Y $KONEC: $ dism/nounl MKC400: $ exit

Po končanem importu podatkov smo preveril, da ni bilo napak. Tokrat je vse potekalo brez težav. Rezultat prenosa (import) podatkov v bazo Oracle8i je razviden iz tabele 6.

št. kreiranih tabel v 8i

skupno št. vrstic

skupna velikost

1.595 467.317.433 102 GB

Tabela 6: rezultat prenosa podatkov v bazo Oracle8i



5.4.5 Kreiranje indeksov na tabelah Zatem smo pognali ukazno datoteko za kreiranje indeksov na teh tabelah. Tudi tu smo najprej kreirali največje indekse na svoj način z namenom, da bi se kreirali optimalno, s čim manj podaljški (extent). Z vnaprejšnjim kreiranjem teh indeksov smo preprečili, da bi Oracle kreiral indekse s privzetimi vrednostmi "storage" parametrov. Zaradi hitrejšega kreiranja indeksov smo povečali parameter seje SORT_AREA_SIZE na 50MB - privzeta vrednost v produkcijski postavitvi baze je bila 2MB. alter session set sort_area_size = 52428800;

-- CREATE INDEX STROSEK_ODJ_MESTO01 ON STROSEK_ODJ_MESTO (ODJEMNO_MESTO, DATUM_OD, TIP_STROSKA, STATUS) TABLESPACE SPLIDX PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE ( INITIAL 1800M -- začetna velikost segmenta NEXT 20M -- velikost naslednjega podaljška MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 );

Zadnja faza na strežniku se je končala 4. dan zjutraj 5.4.6 Odpravljanje zadnjih težav EXPORT deluje počasi Po prvem arhiviranju baze smo ugotovili, da procedura za export sedaj teče bistveno počasneje - namesto običajne 3 ure, sedaj niti 9 ur ni bilo dovolj, da bi export končal. Čas exporta baze je bil nesprejemljiv, zato smo na Oracle Metalinku vztrajno iskali možne rešitve za težavo. Ugotovili smo, da glavni popravek Oracle Critical Patch Update #4751906 ni vseboval popravka za to napako (bug): EXPORT VERY SLOW UNDER 8.1.7 COMPARED 8.0.5.1 AND EARLIER

Odprava te napake je vsebovana v popravku #2655014, zato je sledila še namestitev tega popravka (patch #2655014).



Popravek se namesti na bazni strežnik: $ unzip p1642582_8174_AXP.zip $ set def [.patch2655014_basebug1642582] $ @install_patch 2655014

Po namestitvi smo s pomočjo procedure ORACLEINS povezali (link) še produkta RDBMS in UTIL. Manjkajoči zapisi v okvarjenih tabelah Narejene so bile kontrole zapisov na osnovi logičnih povezav. Zapisi v eni tabeli so v soodvisnosti od podatkov v drugih tabelah. Znesek računa v eni tabeli je na primer vedno enak seštevku razdeljenega računa v drugi tabeli. V primeru, da se znesek ne ujema in so bili računi razdeljeni pomeni, da nekaj zapisov manjka. V tem primeru smo do prvotnega stanja prišli z brisanjem delitve računa in ponovno delitvijo. Določene poizvedbe delujejo prepočasi Zaradi sprememb v delovanju Oraclovega optimizatorja v verziji Oracle8i, je nekaj poizvedb sedaj delovalo prepočasi. Ugotovljeno je bilo, da se je optimizator, predvsem pri kompleksnejših poizvedbah, odločil za drugačen vrstni red uporabe indeksov. Nekaj teh problemov smo rešili z uvedbo Oracle namigov (hint) - dodatnih namigov optimizatorju, nekaj pa s predelavo poizvedb. Primer Oracle hint za uporabo indeksa terjatev_odj_mesto03: select /*+ index (t terjatev_odj_mesto03) */

distinct id_terjatve,rajon,partner,nacin_placila, . . .



5.4.7 Nadgradnja strežnika za odjemalce Na strežniku za odjemalce smo izvedli naslednje postopke: SQL*Forms: Ena glavnih sprememb pri prehodu iz Oracle7 na Oracle8i je sprememba "pseudokolone" rowid, s katero Oracle dostopa do podatkov v tabeli. Da se prepreči napaka "INVALID ROWID AFTER AN INSERT THROUGH ORACLE FORMS" je treba namestiti popravek, ki zamenja eno od sistemskih knjižnic za SQL*Forms. Postopek namestitve popravka Alpha_#435593:

1. vključitev modula v RDBMS objektno knjižnico:

$ copy upicto.obj ora_util:*.*/log $ set default ora_util: $ library/ext=upicto/output=upicto.obj_sav ora_util:kusr.olb $ library/replace ora_util:kusr.olb upicto.obj

2. relink RDBMS s proceduro ORACLEINS SQL*Menu: Najprej je bilo potrebno kreirati vse objekte (tabele, indekse) za okolje SQL*Menu. Pognali smo naslednje Oracle ukazne datoteke: SQL> @ora_sqlmenu50:MENUDROP -- pobrišem stare tabele SQL> set compatibility V6 -- nujno ! SQL> @ora_sqlmenu50:MENUTABS -- kreiram nove interne tabele SQL> @ora_sqlmenu50:MENUIDXS -- kreiram indekse na te tabele SQL> @ora_sqlmenu50:MENUGRTS -- dodelim privilegije za uporabo teh tabel SQL> @ora_sqlmenu50:MENUGRP SQL> @ora_sqlmenu50:MENUVWS

"Compatibility" je nujno nastaviti na V6 - v nasprotnem primeru bi se tabele, ki jih interno uporablja orodje SQL*Menu kreirale z napačnimi opisi polj (na primer CHAR namesto VARCHAR). Po uspešnem kreiranju SQL*Menu okolja, smo naložili in prelinkali aplikacije, ki smo jih izvozili pred nadgradnjo. SQL*Report: Namestiti je bilo potrebno interne tabele tega orodja. Po naših izkušnjah je najbolje namestiti tabele centralno (Centrally Installed tables), za dostop do teh tabel pa dodeliti dovoljenja za uporabo (grants) posameznim uporabnikom. Lahko pa se tabele namestijo tudi lokalno, v shemo posameznega uporabnika, vendar je tako namestitev težje vzdrževati. Obe vrsti namestitve nista možni hkrati.



Postopek kreiranja internih tabel in dodelitve dovoljenj za uporabo objektov orodja SQL*Report: SQL> @ora_root:[sqlreportwriter.bin]srw_pup -- le za OpenVMS SQL> @ora_root:[sqlreportwriter.bin]srw_cmdn -- le za OpenVMS SQL> @ora_root:[sqlreportwriter.bin]srw_prac -- kreiram product

access tabele

SQL> @ora_root:[sqlreportwriter.bin]srw_icen -- centralne tabele, views, synonyms, ..

SQL> @ora_root:[sqlreportwriter.bin]srw_grnt -- dodeljevanje privilegijev uporabnikom za delo z objekti

Vse te ukazne datoteke je treba pognati kot sistemski uporabnik (SYSTEM user) v SQL*Plus orodju. Zatem smo uvozili vsa poročila (reports), ki smo jih predhodno shranili z "dumprep" ukazom: $ loadrep file= userid=un/pw



6 Zaključek Nadgradnja produkcijske baze se pred dejansko izvedbo ni zdela tako kompleksna, kot se je kasneje izkazalo. Projekt je bil dobro načrtovan in zastavljen z upoštevanjem možnosti, da kakšen del plana odpove. V primeru odpovedi so bili pripravljeni rezervni postopki. Med nadgradnjo baze je prišlo do okvare podatkov, kar nam je vzelo veliko časa. Bazo smo uspeli vrniti v prvotno stanje zaradi dobrega poznavanja delovanja aplikacije in same baze. Pri reševanju nastalega problema smo ugotovili, da bi imeli veliko manj in predvsem lažje delo, če bi bila aplikacija napisana tako, da bi omogočala ponavljanje poslovnih dogodkov. Poslovni dogodek predstavlja sklop atomskih transakcij (vsi deli transakcije se izvedejo v celoti ali pa se ne izvede noben del) na Oracle RDBMS nivoju. To bi omogočalo, v poslovnem smislu, vrniti bazo v konsistentno stanje v katerikoli čas v preteklosti. Aplikacija bi morala poslovne dogodke beležiti v lastni dnevnik. Tako bi lahko, v primeru okvare podatkov, s pregledom dnevnika lažje obnovili manjkajoče podatke. Seveda pa to pomeni velik poseg v apliakcijo. Verjetno bi z analizo ugotovili, da bi bilo potrebno večino aplikacije napisati na novo. V projekt nadgradnje je bilo vloženih skupaj 331 ur dela (Tabela 7).

osebe št. oseb št. ur / osebo št. ur skupaj samostojni programer - analitik 4 62 248 svetovalec iz Oracle Slovenija 1 19 19 uporabniki + analitik IT 5 3 15 sistemski analitik / administrator baze 1 49 49

skupaj 11 133 331

Tabela 7: število vloženih ur dela v projekt nadgradnje

Z nadgradnjo na Oracle8i je ostal nerešen še problem zunanjega izvajalca, ki je za svojo aplikacijo zahteval bazo Oracle, verzijo vsaj 9i. Po analizi smo ugotovili, da bo njihova baza relativno majhna in transakcijsko manj zahtevna. Zato smo se odločili, da namestimo dodatno bazo Oracle9i na Windows 2003 strežnik, ki bo povezana s produkcijsko bazo preko baznih povezav (database links).


Miran Presečnik: Projekt nadgradnje baze po

PROJEKT NADGRADNJE BAZE PODATKOV ORACLE · Kranj, maj 2009 . ZAHVALA ... ki je iz leta 2007. Baza...

Documents

Transcript of PROJEKT NADGRADNJE BAZE PODATKOV ORACLE · Kranj, maj 2009 . ZAHVALA ... ki je iz leta 2007. Baza...