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
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). Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 1
Matematično je relacija podmnožica kartezijskega produkta množice domen in to skoraj natančno ustreza definiciji tabele (Slika 1). R D D... 1 2 D n Maja 23 Peter 16 Maja 23 Maja 16 Peter 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) Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 2
Glavni predstavniki relacijske tehnologije v Microsoft, Sybase, Teradata in ostali. svetu so danes Oracle, IBM, 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. Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 3
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 Č芚Žž. Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 4
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 = <jezik>_<teritorij>.<odjemalčev znakovni nabor> 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 Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 5
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 Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 6
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 Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 7
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, stanovanjskoposlovnih 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 Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 8
Na sliki 4 je prikazan organigram družbe SPL d.d. Slika 4: Organigram SPL d.d. (Vir: SPL d.d., 2009) Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 9
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 Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 10
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 dvoprocesorskem 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. Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 11
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) Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 12
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. Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 13
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 Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 14
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. Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 15
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. Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 16
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: Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 17
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: <ime_labele_diska> 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:<ime_save_set>.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:<ime_save_set>.sav/save Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 18
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. Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 19
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 Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 20
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... Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 21
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. Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 22
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. Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 23
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) Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 24
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) Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 25
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 <ime_tabele> 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 <ime_tabele>; ali z eksportom objekta (exp utility): $ exp un/pw table=<ime_tabele> file=<ime_datoteke> Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 26
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: Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 27
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 => '<ime_sheme>', object_name => '<ime_tabele>', 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('<schema>','<tabela>'); Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 28
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" Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 29
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. Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 30
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:<ime_save_set>.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: Miran Presečnik: Projekt nadgradnje baze podatkov Oracle 31