Juni 2003 • Nr 18, Årgang 4 • ISSN 1600-5147 • Pris: kr. 125,00 ex moms • www.OracleEkspert.dk

OUGDK 23OUGDK Stormøde

Næste møde: 18. juni kl 15:00 hosOracle Danmark

DBA SIGNæste møde er endnu ikke fastlagt.

DesWeb SIGNæste møde: 20. august kl. 13:00hos Oracle Danmark

Developer SIGNæste møde er endnu ikke fastlagt.

Data warehouse SIGNæste møde er endnu ikke fastlagt.

#18

NYHEDER 11Ny direktør for Oracle DanmarkOracle9iAS til Windows 2003IDC: Oracle bedst med Spacial

STADIG UAFHÆNGIG? 2Marc de Oliveira

THE PATCH IS THE PITCH 1 4Mogens NørgaardDen her artikel (eller serie af artikler, hvis der er interesse for det) handler ompatching og opgraderinger. Jeg modtager gerne forslag til en bedre over-skrift – hvad med The Patch Society? De Hurtige Løsningers Samfund?

HVORDAN KØRER DU ’CHANGEMANAGEMENT’ PÅ DINE DATABASER? 9Martin JensenMan har måske et produktionssystem, samt et antal udviklings- og testsys-temer. Indimellem er der så behov for at finde forskellene mellem syste-merne og måske at oprette databaseobjekter i en database nøjagtigt som deeksisterer i en anden.

EN PRAKTISK INDGANG TIL HIGH AVAILABILITY 312Jørgen QuaadeHermed sidste del af artiklen om high availability. I denne del bliver RAC ogData Guard gennemgået og sammenlignet. Der vil blive set på forskelligekonfigurationer og anvendelser af de to teknologier, ligesom styrker ogsvagheder ved forskellige konfigurationer vil blive gennemgået.

GROANS FRA MOGENS 17

BENTES BØGER 22Data Modeling for Everyone Oracle 9i DBA Handbook

OUGDK DesWeb SIG møde

den 4. juni kl 13:00

STADIG UAFHÆNGIG?Marc de OliveiraSom det kan ses af forsiden har OracleEkspert nu påbegyndt et tætsamarbejde med to selskaber, der har besluttet at yde en ekstra-ordinær indsats for at støtte op om, at Danmark fortsat kan have etuafhængigt Oracle-tidsskrift af høj kvalitet.Miracle A/S har allerede igennem det sidste år haft en aftale medOracleEkspert omkring Mogens Nørgaards "Groans". De er nu blevetegentlig sponsor for bladet, idet de, udover klummen, har påtaget sigat håndtere faktureringsarbejdet samt initiativer til at udbrede kendska-bet til OracleEkspert.De fleste husker nok, at DBVision i sin tid lagde lokaler til Oracle-Ekspert-konferencen i 2001. De har også taget skridtet fuldt ud og ernu blevet sponsor, ved at de har påtaget sig ansvaret for forsendelsenaf bladet til abonenterne. Samtidig har Bente Rosenkrantz-Theil påtag-et sig ansvaret for en ny sektion med anmeldelser af Oracle-relateredebøger, som præsenteres for første gang i dette nummer. DBVision Apsvil desuden sikre sig at deres kursister får kendskab til bladet.Den støtte som Miracle A/S og DBVision Aps på denne måde yder ermeget vigtig for, at vi kan have det uafhængige forum for erfaringsud-veksling mellem erfarne Oracle-folk i Danmark, som det OracleEkspertrepræsenterer.Som tak for indsatsen tilbyder OracleEkspert sponsorerne en lille pladspå bladets forside, en helsidesannonce i hvert nummer, samt en ban-ner på www.OracleEkspert.dk. Hvis dette kunne friste andre virk-somheder, så er der stadig mulighed for at en tredie sponsor kan støttebladet og på den måde vise sit engagement i det tekniske Oracle-miljøi Danmark.Men betyder denne sammenblanding af økonomiske interesser atOracleEkspert mister sin uafhængighed? Svaret skulle meget gernevære ”Nej”, og det er vigtigt at få præciseret. OracleEkspert bliver ikkesponsorernes forlængede arm, fordi de får en helsides annonce i hvertnummer. Annoncer kan alle købe sig til, uanset om de er sponsorereller ej. Sponsorerne bliver profileret med et logo på forsiden, somfremhæver virksomhederne som aktive støtter af OracleEkspert, ogdermed erfaringsudvekslingen i det danske Oracle-miljø, men det giverdem ikke øget indflydelse på bladets redaktionelle indhold. Detteforhold bør alle - inklusiv sponsorerne - kunne se, er til alles fordel. HvisOracleEkspert blev styret af sponsorerne, ville bladet hurtigt miste tro-værdighed blandt læserne, og det ville i sidste ende gå ud over annon-cernes værdi.Det er derfor ikke muligt for sponsorer eller andre at påtvinge bladetspecifikke synspunkter, ej heller at forhindre specifikke indlæg i at blivebragt i bladet. Der må ikke herske tvivl om at OracleEksperts formidlingikke er myntet på at fremme eller nedgøre bestemte produkter, virk-somheder eller personer. Alle har lige muligheder for at få deres syns-punkter præsenteret, under forudsætning af at disse lever op til bladetskrav om uafhængighed og seriøsitet.Sponsorernes rolle er uvurderlig for OracleEksperts muligheder for atoverleve. Dels pga deres aktive hjælp med praktiske opgaver til driftenaf bladet, og ikke mindst ved at OracleEkspert bliver et bedre blad enddet ville være uden sektionerne ”Groans fra Mogens” og ”BentesBøger”. Forhåbentlig vil deres støtte også hjælpe til at udbrede kend-skabet til bladet.Det er måske at tage munden for fuld, at hævde at OracleEkspert ermedvirkende årsag til at danske Oracle-folk er dygtigere og mere ind-flydelsesrige end de er det i andre lande, men det er et faktum atDanmark igen i år har det største antal tilmeldte deltagere til ODTUG-konferencen i Miami blandt landene udenfor Nordamerika (foreløbigopgørelse fra den 29. maj). Hvad enten OracleEkspert kan tildeles et ansvar for dette eller ej, såskal man endelig ikke undervurdere betydningen af et medie somdette, der giver sine læsere opdateret information om teknologi, littera-tur, begivenheder og politik fra Oracle-verden, samt muligheden for atlæserne selv kan udtrykke sig overfor en bred skare af erfarne folk.

Oplag: . . . . . . . . . . . . . . . . . . . .150 kopier

Udgives af: . . . . . . . . . . . . . . . . . .PYTHIA Information . . . . . . . . . . . . . . . . . . . . . . .Kongensvej 3 . . . . . . . . . . . . . . . . . .2000 Frederiksberg . . . . . . . . . . . . . . . . . . . . . . . . . . .Danmark

Telefon: . . . . . . . . . . . . . . . . . . . .26279991Fax: . . . . . . . . . . . . . . . . . . . . . . .26199991Email: . . . . . . . . .Info@OracleEkspert.dkWeb: . . . . . . . . . .www.OracleEkspert.dk

Ansvarshavende redaktør: . . . . . . . . . . . . . . . . . . . . . .Marc de Oliveira . . . . . . . . . . . . . . .Marc@OracleEkspert.dkGroans fra Mogens: . . . . . . . . . . . . . . . . . . . .Mogens Nørgaard . . . . . . . . . . . .Mogens@OracleEkspert.dk

Bentes Bøger . . . . . . . . . . . . . . .Bente Rosenkrantz-Theil . . . . . . . . . . . . . .Bente@OracleEkspert.dk

Rettigheder:PYTHIA Information ejer alle rettigheder tilindholdet af OracleEkspert. Kopiering af bladet i dele eller helhed måkun ske efter skriftligt samtykke fra PYTHIAInformation.PYTHIA Information forbeholder sig ret-tigheder til at offentliggøre og genudgive detrykte artikler, tips mv, samt at tillade bladetslæsere at anvende indholdet til såvel per-sonlige som kommercielle formål.PYTHIA Information kan ikke drages tilansvar for eventuelle fejl og mangler iIndholdet af OracleEkspert. Artikler mvstilles tilrådighed uden garanti af nogen art.

Pris:Enkeltnummer . . . . . . . . . . . . .DKK 125,001 års abonnement:- Blad . . . . . . . . . . . . . . . . . . . .DKK 600,00- Elektronisk . . . . . . . . . . . . .DKK 1200,00- Medlemskab . . . . . . . . . . . .DKK 1800,00

Rabatordninger kan findes på vores hjem-meside.

Annoncer:Annoncer til OracleEkspert nr 19 skal værePYTHIA Information i hænde senest den19. juli 2003. Annoncepriser kan findes på vores hjem-meside.

Leder

Ingen sourcekode

If you can go to only one conference this year, ODTUG 2003 is the one to attend.

Here is what participants say:îîAAss uussuuaall,, II nneevveerr lleefftt aa ssiinnggllee sseessssiioonn wwiisshhiinngg ffoorr mmoorree ddeettaaiillssóóeeaacchh sseessssiioonn wwaass ccrraammmmeedd ffuullll ooff vvaalluuaabbllee iinnffoorrmmaattiioonn..îî

îîTThhiiss iiss tthhee bbeesstt ccoonnffeerreennccee rreeggaarrddiinngg pprreesseennttaattiioonnss,, aatttteennddeeeess,, iinnffoorrmmaattiioonn..îîîîII wwaass mmoosstt iimmpprreesssseedd wwiitthh tthhee llaarrggee nnuummbbeerr ooff iinntteerrnnaattiioonnaall aatttteennddeeeess..îî

îîII aamm eexxcciitteedd ttoo ggeett bbaacckk ttoo wwoorrkk aanndd uussee mmyy nneeww iiddeeaass..îî

This conference has it all!June 21, Saturday (preconference)

Business Rules Symposium 8:00 am - 5:30 pm June 22, Sunday

Vendor Presentations 9:00 am - 12:00 noon Tool Topics - 3-hhour, in-ddepth seminars 2:00 pm - 5:00 pmWelcome Reception 6:30 pm - 8:30 pm

June 23 - 26 Monday - Thursday (Thursday half day)More than 120 Technical PresentationsOracle Presentations and Product UpdatesODTUG UniversityAsk the Experts PanelsRoundtable Lunch Bunch DiscussionsVendor Table-TTop ExhibitsVolleyball TournamentBeach PartyNetworking, Networking, Networking

2003 TopicsAApppplliiccaattiioonn DDeevveellooppmmeennttWWeebb TTeecchhnnoollooggiieessBBuussiinneessss RRuulleess // AAnnaallyyssiissBBuussiinneessss IInntteelllliiggeenncceeOOrraaccllee SSeerrvveerr-BBaasseedd DDeevveellooppmmeennttOOrraaccllee EE-BBuussiinneessss SSuuiittee

Registration Rates:MMeemmbbeerr:: uuss 11009955$$ NNoonnmmeemmbbeerr:: uuss 11119955$$FFoorr hhootteell rreesseerrvvaattiioonnss,, ccaallll ++11 ((887777)) 556633-99776622

To register, visit www.odtug.com or call +1 (910) 452-77444

www.odtug.com

4 OracleEkspertJuni 2003

Teknisk Artikel

DBA

Nå, den overskrift var vist ikke særlig god. Den gamlesandhed ”The batch is the bitch” var jo meget morsom,men har ikke meget med dette emne at gøre. Den her artikel (eller serie af artikler, hvis der er inter-esse for det) handler om patching og opgraderinger.Jeg modtager gerne forslag til en bedre overskrift –hvad med The Patch Society? De Hurtige LøsningersSamfund?Jeg har planlagt bl.a. at diskutere følgende emner iartiklerne:

- Patches, patchsets, opgraderinger generelt- Oracle’s anbefalede metode til patching og

opgradering- Fordele ved patching - Ulemper ved patching- Og hvad man kan gøre ved det- Fordele ved opgradering- Ulemper ved opgradering- Og hvad man kan gøre ved det- Rolling upgrades - Online patching - Registrering af patches

Der er altid noget der ændrer sig – hvad gør man veddet?

Oracle versioner ogpatches/opgraderingerVi, der til dagligt har med Oracle at gøre, er lidt underli-ge i andres øjne. Vi taler rutinemæssigt om en opgra-dering fra 9.2.0.1.0 til 9.2.0.3.0 eller om 8.1.7.4 vs8.1.6.2.Oracle har gennem årene gjort lidt på marketingsfron-ten for at få de fem-cifrede koder til at se lidt nemmereud, men selvom 8.1 blev til 8i, så hedder det stadig8.1.x.y.z når man taler om ”rigtige” versioner. Det har faktisk reelt betydet, at vi nu også skal holderede på, at:

- 8i Release 1 = 8.1.5, - 8i Release 2 = 8.1.6 og - 8i Release 3 = 8.1.7,

dvs. vi skal i hovedet vide at - 1 = 5, - 2 = 6 og - 3 = 7.

Det kræver vist et andet talsystem end 10-tals systemetat nå frem til sådanne resultater ☺.9.0 og 9.2 hedder tilsammen 9i, men kaldes også hhv9iR1 og 9iR2, dvs her er 0 = 1 og 2 = 2. Ingen 9.1, omend 9.0 nogle gange kaldes 9.1. Her synes der dog atvære tal, der er ganske tæt på hinanden.Rygterne om, at 10i skal hedde DB2003 er jo ogsåværd at hæfte sig ved.Vi skal i øvrigt også kende til begrebet Final Release,som er et magisk begreb vi alle stræber efter, for det måda være stabilt, for pokker! Final releases: 6.0.36, 7.0.16, 7.1.6 (7.1.5 i VMS),7.2.3, 7.3.4, 8.1.7…. åh, hvor vi længes efter dem. De

omtales med større respekt end noget så latterligt som7.0.15, 7.1.3, 7.2.2, 7.3.3.6 eller 8.1.6.2, ikke? For sletikke at tale om 8.0, som vi bare – ligesom – sprangover… omend 8.0.5 og 8.0.6 (final release) skam sta-dig kan ses visse steder. Sjovt nok var både 8.0 og 9.0 den type releases, der påforhånd var dømt til ikke at blive brugt idet 8.1 og 9.2praktisk talt var på gaden før deres .0 slægtninge.Halleluja.Med iAS’en bliver der frit talt om iAS Release 1, 2 og…. 4. Det er fordi de hedder 9.0.1, 9.0.2 og… 9.0.4. Herer det altså ude på tredje ciffer man navngiver Release-nummeret. Det ser ud til, at 3’eren får et meget kort liv.Ligesom databasens version 9.0 eller 8.0.4 eller 8.1.5eller…At iAS’en i dag har 50 hovedkomponenter og 250 sub-komponenter, der hver især har fulde versionsnumregør det ikke nemmere.Det forklarer i øvrigt alt sammen, hvorfor supporterebrugere en stor del af deres tid på at kigge på – og vur-dere – bugs, patches, patchsets, mv. for at finde ud af,om det kan afhjælpe kundens problem. Det er ikkenoget der kan læres – det kræver bare års og års erfa-ring. En kunde, der kun kigger på sådan noget påMetalink en del af sin tid bliver aldrig i stand til at vur-dere denne jungle af versioner tilstrækkeligt.Det er faktisk ikke så underligt, at vores normalitetsop-fattelse er forskellig fra andre IT-nørders…Der er ikke noget system i det.Man kan prøve at lave sine egne undersystemer: Nåren databaseversion ændrer sig på fjerde eller femte cif-fer er det en patch – ellers er det en upgrade. Men denholder kun i 8i. Med 9i skilles det – synes vi – mellemtredje og fjerde ciffer. Men noget officielt system, dergælder for alle releases og produkter kan jeg og minegutter ikke komme på.

Hvad er et patch?En patch er en lap. Det lyder som noget, der normaltikke skal anvendes, hvis man kan undgå det - og det erganske rigtigt. Det er noget skidt pr definition. En patcher aldrig ordentligt testet igennem, den indfører ekstrakode (større codepath i fagjargon), og er derfor en risi-kofaktor – en potentielt destabiliserende dims, der put-tes ind i systemet.Vi har alle oplevet, at en patch løste et problem. Vi har også alle oplevet, at en patch ikke løste et pro-blem. Og så har de fleste af os også oplevet denne vidun-derlige gyldne mellemvej, hvor en patch løste (eller ej)et problem, og til gengæld indførte nye problemer (col-lateral damage) andre steder i systemet.En hvilken som helst patch eller opgradering er enpotentielt destabiliserende faktor, der introduceres idit system. Vi ved det jo godt. Der er bare for mange lag i teknologistakken, og ingenkan gennemskue dem, så nu om dage siger vi barebevidstløst ja til alle de forslag Microsoft kommer medomkring patches, der automatisk lægges på vore

THE PATCH IS THE PITCH 1Mogens Nørgaard er teknisk direktør i Miracle A/S. mno@miracleas.dk

4

maskiner. - Vi aner ikke, hvilke fixes der lægges på. - Vi aner ikke, hvilke huller der lappes. - Vi aner ikke, hvilke andre dele af koden der påvir-

kes negativt. - Vi aner ikke, hvor meget langsommere vores

system bliver af det. - Vi aner ikke, om der introduceres spionskrammel,

der fortæller alt om os og vores brug af maskinentil Microsoft, NSA, eller EU’s anti-konkurrenceråd(dvs til franskmændene ☺).

Vi skuffes hver gang, men glem-mer hvorforAlligevel bliver vi ved med at drømme om den næstepatch, den næste release – og at blive rige, smukke ogberømte. Hver eneste gang vi patcher eller opgradererbliver vi skuffet.Man fristes til at sige, at på trods af navnet er det ikkealtid en befrielse med en ny release ☺.Der findes mennesker i vores miljø der kan reciterepatchnumre som vi andre engang (før mobiltelefoner-ne) kunne recitere telefonnumre. For at nasse lidt påGaja’s berømte begreb om tuning, så lider disse men-nesker af Compulsive Patching and Upgrade Disorder(CPUD).De drømmer – ligesom alle andre – om Det TekniskeFix. De bliver skuffet hver gang, men er ligeglade, og kon-kluderer aldrig på det. De kontakter sgu da bare leverandøren (som også haren del Det Tekniske Fix-erede personer ansat) for atfortælle, at den patch ikke hjalp på problemet. Og starter så en ny runde, hvor begge parter ivrigt lederefter en patch eller release, der vil løse problemet.

Jeg vil have en patch!Folk i COE (Center Of Expertise), i DDR (Detection,Diagnosis, Repair), og i BDE (hvad det så end står for)i Oracle Support fortæller mig, at folk ofte ringer ind medet problem og fra starten åbner samtalen med ordene:”Jeg har brug for en patch…”.Man har en klippetro på, at der må findes et hurtigt fix.Vi har hverken maven til at leve med permanent smer-te/ulemple eller tålmodigheden til at undersøge, om viselv kunne gøre noget ved det. Det skal fixes af et vid-undermiddel. Viagra eller Voltaren ordner forskelligeformer for hovedproblemer. Det må også kunne ladesig gøre med IT-systemer.Hvorfor lærer vi ikke af det? Hvorfor siger vi ikke bare nej? Fordi nogle få patches eller releases faktisk hjælper pånogle få problemer. Og fordi hele industrien er bygget op om en evig jagt påden næste feature, den næste fix, den næste opgradering. Det er i blodet på os. Det er fedt.

De større tals lov9.2.0.1 må være bedre end 8.1.7.4. Det er da klart.Tallet er jo større! Og selvfølgelig er 8.1.7.4 bedre end7.3.4.5. Det er indlysende.Morsomt, ikke? Solaris 8 (som vel egentlig hedder 2.8)

må da være bedre end Solaris 2.6, ikke?It depends.Hvis alt arbejde alligevel laves i Java-klasser eller iWeblogic/iAS/Websphere-lagene, så kan databasenda passende bare køre videre så længe det skal være.Der findes selvfølgelig modeksempler: En kunde havdeet hårdt krav fra udviklerne om at få adgang til visseobjekt-features i 9.0. Så man opgraderede fra 8.1 til 9.0og fik masser af problemer. Man iTAR’ede, man patchede, man rockede og manrullede. Systemet blev mere og mere ustabilt. Supporterne i Oracle og DBA’erne hos kunden konklu-derede derfor til sidst, at der kun var én vej frem:Opgradering til 9.2 (som også ville have nogle ekstranye features, der lød rigtigt gode). Så man opgradere-de. Nu begyndte problemerne for alvor. Ikke hvor man tro-ede, men helt andre steder.Det endte med en større omgang iTAR’ing, patching,og månedsvis af arbejde med at stabilisere systemet. Og man kan så i øvrigt bare konstatere, at udviklerne ivirkeligheden ikke syntes de fik særligt meget ud afobjekthalløjet i forhold til nogle problemer de fik i denanledning – så man bruger det ikke i dag.De større tals lov er svær at rive sig løs fra. DOS 3.1 varjo bedre end DOS 2.11, ikke?Men er Windows NT version XP bedre end WindowsNT version 2000? Det synes de fleste, fordi det sersmartere ud, og fordi en bestemt lille dims virker bedreeller ikke var der før. Men har man brug for det? Kunnede fleste af os klare os med Windows 95? Ja, selvføl-gelig.Kan man klare sig med 7.3.4 af Oracle? Med 8.1.7? Ja,selvfølgelig. Det har man jo ligesom gjort i lang tid.

Den stabile stak og det robustesystemJeg hørte engang om et energiselskab, der anskaffedesig noget hardware, en OS, en Oracle og noget Forms-halløj, og fik lavet en løsning på det. Når så det hele var gennemtestet og fundet stabilt, såopsagde de alle vedligeholdelses- og opdaterings-aftaler med leverandørerne, satte systemet ind etsted, hvor det skulle køre i fem år – og så virkede detellers bare i de fem år.Når de fire af de fem år var gået begyndte de at over-veje den næste løsning, som selvfølgelig skulle køre påen nyere version af al ting, måske endda på en helt nyplatform. Se, det er en stabil teknologistak.Men hvordan kan man ellers vide, om man har etrobust system (og dermed en stabil teknologistak)?Det kan man ikke med 100% sikkerhed. Men man kankomme tæt på.Her er min til lejligheden opfundne benhårde definiti-on på et robust system:”Hvis et system har kørt stabilt gennem længeretid, så kan det betegnes som værende ”robust”præcist så længe man ikke skifter en eneste kom-ponent i teknologistakken.”

5OracleEkspert Juni 2003

Hvis man så meget som lægger en patch på ODBC-dri-veren eller en sikkerhedspatch på iAS’en kan manbegynde forfra. At teste systemet efter pålæggelsen af en patch er ipraksis ikke muligt. Vi bilder os det muligvis ind, vi skri-ver måske nogle fine papirer om det – men i praksiskan vi ikke teste hele systemet for både funktionalitet ogperformance. En stor, og meget professionelt planlagt, omlægning afen database hos en dansk kunde for nyligt var bundetsammen med omfattende tests foretaget af et firmahyret til lejligheden. Det kostede 7-cifrede beløb, menfunktionaliteten var gennemtestet ved overgangen. Enperformance/stress-test blev ikke gennemført, menville have kostet et lignende beløb. Det er der ikkemange virksomheder, der kan klare.Det skriver jeg lidt mere om i en kommende artikel.

Testprocedurer for patches ogreleasesOracle (og de fleste leverandører) laver regressions-tests af nye releases. Det betyder, at en række ting ogsager, som før har givet problemer, bliver testet modden nye release.Når vi taler om patches, så er der næsten aldrig foreta-get regressionstests – det tager al for lang tid (op til 14dage eller mere), og nytter ikke noget, når en patch skalud i en fart. Patches testes for, om de fixer et bestemt problemman har fundet. Afledte virkninger vil ofte ikke kunneses eller mærkes under denne test – hvilket jo er fairnok, når man tænker over det.En patch er altså en risiko for alle parter (mest kunden,selvfølgelig). Man har ikke mere en stabil teknologistak.Man har ikke mere et robust system. Det har man først,når den nye teknologistak har kørt uden problemer i etgodt stykke tid igen.Og det er i den forbindelse faktisk ligegyldigt om der ersket en ændring på første eller fjerde ciffer i versions-nummeret – problemerne kan opstå uanset om det eren major eller minor patch, om det er en hoved-relea-se, eller hvad har vi.Der foretages ikke – hos Oracle i hvert fald – hold fast:interoperabilitetstests. Det er tests, hvor man tester omforskellige produkter arbejder sammen. De fleste pro-dukter testes naturligvis mod databasen, men f.eks. de50 hovedkomponenter i iAS’en testes ikke mod hinan-den. Det ville også blive helt uoverskueligt.Så der er tre slags test: Patch-test, regressionstestog interoperabilitetstest.

Afrulning af en patchHvordan kører man en patch tilbage, hvis den entenikke virker eller gør tingene værre eller påvirker andredele af systemet så meget, så man hellere ville væreforuden?Det kan man ikke.I Rdb (jeg kender ikke så meget til andre databasersom DB2, SQL Server, Informix, Sybase, etc) kan mansige rollback til en bestemt patch. Det kan man ikke i Oracle, og sikkert heller ikke i de fle-ste andre systemer. Jeg er heller ikke sikker på, at man

kommer til det før i version 42i (som muligvis kommertil at hedde MySQLOracle42i – rygterne er lidt modstri-dende på det punkt).Hvad gør man så? Jah, så må man gå tilbage til en tid-ligere version, dvs. lægge en backup ind og starte opsom det så ud før man lagde patchen på.Så man bør altså tage en fuld backup (formentlig enoffline-backup – mere om det i en senere artikel) førman lægger en patch på. Så bør man teste om patchen virker. Så må man enten tage en dyb indånding og ladebrugerne komme på systemet og bede for, at der ikkeer afledte virkninger i andre dele af systemet – ellergennem-gennem-gennemteste hele systemet vedhjælp af de test-procedurer, som alligevel aldrig kanafspejle den virkelige verden.Hvis testprocedurer til stadighed skulle afspejleden virkelige verden ville de blive så prohibitivt dyre,at det ville sætte spørgsmålstegn ved, hvorvidt manskulle nøjes med 10% af virksomhedens samledeomsætning til formålet – eller skulle bruge de påkræve-de 20% for at få det hele ordentligt på plads ☺.Det er her man altid som leverandør kan sætte sig oppå den høje hest og hævde, at problemerne må skyl-des, at kunden ikke har testet ordentligt. Ja, og det kanman selvfølgelig også hævde som kunde, når leve-randøren har fejl, mangler eller uhensigtsmæssighederi sin kode.I den virkelige verden er der begrænsede ressour-cer til rådighed, og drømmeløsninger findes ikke.Der er kodekarle, der ligesom alle andre mennesker(med undtagelse af tekniske direktører) begår fejl, ikkehar tid til at teste nok, og skal have noget ud af døren isidste øjeblik. Det gælder hos leverandørerne og hosforbrugerne.

Hvilke patches er lagt på mitsystem?Hvordan finder man ud af, hvilke patches, der er lagt pået Oracle-system?Det kan man ikke.Så må man låne. Man kan være heldig, at en DBAeller System Managerhar holdt øje med, hvilke patches og patchsets, der erlagt på i tidens løb. Nogle samvittighedsfuldeDBA’ere eller SysMan’er registrerer den slags i et reg-neark, men det er de færreste.Nogle gange kan man finde spredte henvisninger iinit.ora eller andre steder til bug-numre og medfølgen-de patches, som er lagt på.Men alt i alt findes der ikke en mekanisme i Oracletil registrering af patches.Jeg glemmer aldrig en Apps-kunde, som jeg mødtemidt i halvfemserne i Oracle, og som havde lagt 400patches på sit produktionssystem i løbet af et halvt år.Det samme hørte jeg igen fra en kunde sidste år, somhavde købt et avanceret Oracle E-Business Suite-pro-dukt – her var det så bare på et par måneder.Når ting bliver mere komplicerede, og når der kom-mer stadig flere komponenter til i produkterne, så kom-mer der også flere bugs. Det burde – ud fra matemati-ske betragtninger – faktisk være en eksponentiel funk-

6 OracleEkspertJunil 2003

tion, fordi ting afhænger af hinanden. Jeg ved ikke, omdet er tilfældet.Man har patch-management software til Apps, somkan købes for dyre penge – vidste I det?Definitionen på en patch er flydende, men hvis manopgraderer til nyeste version af Oracle Apps (11.5.xeller sådan noget) er der noget i retning af 50.000 (halv-tredstusinde) SQL’er, der skal køres for at lave nyeindexer eller nye definitioner eller lave opgraderinger af

data, og så videre, og så videre.Skræmmende? Jeps.

Hvad kan man gøre?Det vil jeg skrive om i næste artikel. Forhåbentligt gårder så lang tid før næste nummer af OracleEkspert atjeg når at høre om en løsning på alle disse udfordringer☺.

7OracleEkspert Juni 2003

9OracleEkspert Juni 2003

Teknisk Artikel

DBA

Man har måske et produktionssystem, samt et antaludviklings- og testsystemer. Indimellem er der såbehov for at finde forskellene mellem systemerne ogmåske at oprette databaseobjekter i en databasenøjagtigt som de eksisterer i en anden. Denne artikel fortæller hvorledes man med relativtenkle midler klarer dette.Egentligt kunne man jo bare starte Oracle EnterpriseManager (OEM) og anvende den pack der hedder’Change Manager’ (CM). Denne del skal anvende etEnterprise Manager Repository Skema. Når dette erpå plads, er det relativt enkelt at etablere såkaldte’base lines’, hvor udvalgte databaseobjekter beskrivesaf CM, således at man rimeligt enkelt kan sammen-ligne strukturerne fra en database med en anden, ellerfinde ud af hvilke ændringer ens database har væretudsat for siden sidst. Nogle af disse forskelle kan såvælges ud og påføres den ene eller anden database.Men hvad nu hvis man af den ene eller anden grundikke kan eller vil anvende OEM, er man så selv hen-vist til møjsommeligt at trække al nødvendig informa-tion ud af et relativt komplekst data dictionary?Nej. Faktisk er det muligt at bede databasen selvberette om hvorledes strukturerne af objekterne er; ogdet oven i købet på en form der umiddelbart kananvendes til at oprette dem igen (måske i en andendatabase), eller måske for at generere online doku-mentation af basens objekter og sammenhænge.Hvis vi nu gerne ville vide hvorledes emp tabellen varoprettet, burde vi jo mindst kigge nærmere iuser_tables, user_tab_columns, user_constraints,osv.. Man man kunne jo naturligvis også anvendedbms_metadata pakken.

selectdbms_metadata.get_ddl('TABLE','EMP')

from dual;

Her er resultatet følgende, der kunne anvendes direk-te til at oprette samme objekt et andet sted:

CREATE TABLE "SYSTEM"."EMP"( "EMPNO" NUMBER(4,0),

"ENAME" VARCHAR2(10),"JOB" VARCHAR2(9),"MGR" NUMBER(4,0),"HIREDATE" DATE,"SAL" NUMBER(7,2),"COMM" NUMBER(7,2),"DEPTNO" NUMBER(2,0) )

PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGINGSTORAGE

(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)

TABLESPACE "SYSTEM"

Eller hvis man foretrækker de samme informationerpå XML format, for eventuelt at kunne levere en onlinedokumentation:

selectdbms_metadata.get_xml('TABLE','EMP')

from dual;

Og hvis vi nu havde følgende index på tabellen: cre-ate index inx_emp on emp(job) så kunne man fådenne struktur ud på to måder. Først den direkte:

selectdbms_metadata.get_ddl('INDEX','INX_EMP')

from dual;

CREATE INDEX "SYSTEM"."INX_EMP" ON "SYSTEM"."EMP" ("JOB")

PCTFREE 10 INITRANS 2 MAXTRANS 255STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0FREELISTS 1 FREELIST GROUPS 1BUFFER_POOL DEFAULT)

TABLESPACE "SYSTEM"

Eller ved at anmode om alle indexes på emp tabellen:

selectdbms_metadata.get_dependent_ddl('INDEX',

'EMP') from dual;

Så at få en liste over alle databaseobjekterne i ensskema burde ikke være vanskeligt, er det ikke bare atfinde alle objekter fra user_objects, og så føre disseinformationer ind som argumenter til dbms_metada-ta.get_ddl?

selectdbms_metadata.get_ddl(object_type,

object_name)from user_objectsorder by object_type, object_name;

Den går desværre ikke, da get_ddl funktionen ikkekan klare alle objekter, og f.eks er der ingen grund tilat bede om ddl for ’PACKAGE BODY’, for den kom-mer med ved bare at bede om ’PACKAGE’.Endvidere kan funktionen endnu ikke klare domainindexes. Så en mere brugbar select, kunne sesåledes ud:

selectdbms_metadata.get_ddl( object_type,

object_name )from user_objectswhereobject_type not in ('INDEX PARTITION','JAVA CLASS','JAVA SOURCE','LOB','MATERIALIZED VIEW','PACKAGE BODY','QUEUE','TABLE PARTITION', 'INDEX') or(object_type = 'INDEX' and(select index_type from user_indexeswhere index_name = object_name) not in

('FUNCTION-BASED DOMAIN' ) )order by object_type, object_name;

Samt at få oplyst hvilke systemprivilegier der pt. ergrantet til dette skema:

HVORDAN KØRER DU ’CHANGE MANAGEMENT’PÅ DINE DATABASER?Af Martin Jensen - Oracle Consulting. Martin har siden 1982 arbejdet medbl.a. Oracle’s databasekerne, samt med forskellige aspekter af objektori-enteret systemdesign.

10 OracleEkspertJuni 2003

selectdbms_metadata.get_granted_ddl(

'SYSTEM_GRANT', 'SCOTT' ) from dual;GRANT RESUMABLE TO "SCOTT"GRANT UNLIMITED TABLESPACE TO "SCOTT"

Så nu er det ikke vanskeligt eksempelvis hver mor-gen med cron, at køre et job, der skriver alle ske-maets objektdefinitioner ud i en fil, således at manhurtigt med diff kan se om der er strukturelleændringer siden sidst.

DATE=`date +"%Y%m%d"`LOG=$LOG_DIR/${DATE}ddl.log; export LOGsqlplus $USER_PASS @get_ddl.sql>$LOG 2>&1

Hvis det ikke er godt nok at trække dette ud hver mor-gen, kunne man jo også skrive en DDL-trigger til atfange at nogen var ved at oprette, ændre eller ned-lægge et databaseobjekt – og så fyre et kald af tildbms_metadata.get_ddl, for at gemme den struktu-relle del. Alternativt kan logminer også anvendes til atfange DDL-sætninger, men den tilbyder ikke at holdestyr på de interne afhængigheder objekterne imellem.For nogle år siden oplevede en stor kunde, at etunique index, der beskyttede en tabel af betalingerfra at have dubletter, var blevet fjernet. Sikkert fordien person troede at han arbejde på test-systemet;men det var produktion. Det ville have væretvæsentligt billigere for denne kunde at have haft styrpå hvilke ændringer deres system var ude for!Måske ønsker man ikke at få alle detaljer med påden genererede DDL-sætning? Det kan jo være atman i sammenligningsøjemed finder informationerom tabellens placering i tablespace irelevant. I det til-fælde kan man bede dbms_metadata om at udeladedenne information.

begindbms_metadata.set_transform_param(

dbms_metadata.session_transform,'STORAGE', false );end;/

select dbms_metadata.get_ddl( 'TABLE',table_name )from user_tables where table_name like'EMP%';

CREATE TABLE "SYSTEM"."EMP"( "EMPNO" NUMBER(4,0),

"ENAME" VARCHAR2(10),"JOB" VARCHAR2(9),"MGR" NUMBER(4,0),"HIREDATE" DATE,"SAL" NUMBER(7,2),"COMM" NUMBER(7,2),"DEPTNO" NUMBER(2,0)

) PCTFREE 10 PCTUSED 40 INITRANS 1MAXTRANS 255 NOCOMPRESS LOGGING

TABLESPACE "SYSTEM"

begindbms_metadata.set_transform_param(

dbms_metadata.session_transform,’DEFAULT’);

end;/

Der er faktisk ingen undskyldning for ikke at håndtere’change management control’ af databaseobjekternei de forskellige database. Enten anvendes OEM medCM pack, eller også denne mere hjemmegjortemodel.

SKRIV EN ARTIKEL

Vi betaler dig 700 kr pr side for artikler, somtrykkes i OracleEkspert (400 kr pr side forengelsksprogede artikler). Du kan også komme til at vinde OracleEkspert-prisen, som i december-nummeret uddeles tilforfatteren af årets bedste artikel.Deadline for artikler til OracleEkspert nr 19(august 2003) er fredag den 18. juli 2003. Har du lavet noget genialt, som kunne have in-teresse for andre Oracle-udviklere, ledere, plan-læggere mv, eller har du bare nogle guldkorn,som andre kunne få glæde af, så skriv en artikeltil OracleEkspert.

Sådan gør du:Aflever et oplæg på ca 200 ord via vores hjem-meside:

www.OracleEkspert.dkunder sektionen ”Din Mening”.Når oplæget er godkendt af redaktionen, kandu skrive selve artiklen.Der ligger en MS Word template på hjemmesi-den.Artiklen skal også godkendes af redaktionen.Dette sker ud fra kriterier om seriøsitet, relevansog teknisk niveau.Artiklerne skal henvende sig til erfarne Oracle-folk, og emnet skal på en eller anden måde værerelateret til Oracle.Den normale størrelse af en artikel er 3-6 sider.Hvis din artikel falder udenfor denne størrelse,bør du gøre os opmærksom på det, inden du be-gynder at skrive den.

Præsentationsartikler:Hvis emnet er et værktøj eller en service, somdu selv udbyder karakteriseres artiklen som enpræsentationsartikel. Disse koster 1000 kr perside, da de egentlig er en slags reklame (dvs atvi ikke betaler for artiklerne).Der gælder samme krav til seriøsitet og kvalitetift præsentationsartikler som for tekniske artik-ler.

11OracleEkspert

14. maj 2003Ny direktør for Oracle DanmarkStig Jørgensen (tidligere administr-erende direktør for Oracle i Tjek-kiet) overtager den 1. juni direktør-posten for Oracle Danmark efterPeter Perregaard, som i stedet bliv-er Vice President for TechnologySolutions i Europa.

24. april 2003Oracle9iAS til Windows 2003Oracle annoncerede i dag denkommende udgave af Oracle9iAS,som vil være optimeret ift Windows2003.Denne version vil bygge bromellem J2EE og .NET og dervedgøre arbejdet nemmere for syste-mudviklere

10. april 2003IDC: Oracle bedst med SpacialInternational Data Coorporation(IDC) har i en rapport erklæret atOracle er klart førende indenforGeospacial databaseteknologi.Ifølge rapporten har Oracle 80-90% af markedet indenfor SpacialInformation Management (SIM).

Nyheder

Juni 2003

Freelance-konsulent?

Indryk en 1/4 sides annonce

for kun DKK 800

Kontakt:

info@OracleEkspert.dk

12 OracleEkspertJuni 2003

EN PRAKTISK INDGANG TIL HIGH AVAILABILITY, 3Jørgen Quaade er ansat i Oracle Danmark som konsulent. Han har specialeindenfor Data Guard, RAC og andre teknikker til high availability

Hermed sidste del af artiklen om high availability. Idenne del bliver RAC og Data Guard gennemgået ogsammenlignet. Der vil blive set på forskellige konfigu-rationer og anvendelser af de to teknologier, ligesomstyrker og svagheder ved forskellige konfigurationervil blive gennemgåetI de to foregående artikler har vi set på high availabil-ity generelt, vigtige spørgsmål man bør stille om highavailability, og vi har set på hvordan RAC og DataGuard opfylder forskellige krav til high availability. Idenne artikel går vi lidt tættere på RAC og Data Guardog ser på hvordan de rent faktisk virker, og hvilkenindflydelse det har på henholdsvis hvor lang tid dettager at lave en fail-over og om systemerne er beskyt-tede mod data tab eller ej.RAC tillader to eller flere systemer at tilgå den sammedatabase. Hvis et eller flere systemer fejler, vil deoverlevende systemer fortsætte med at servicerebrugerne. For det meste er alle systemerne anbragt idet samme rum. De kan også være anbragt f.eks. etpar hundrede meter fra hinanden, for at give en visbeskyttelse mod tab af et helt computerrum eller enbygning. Altså en slags begrænset disaster recovery.Data Guard gør det muligt for en primær database atholde en eller flere sekundære standby databaseropdaterede, og klar til at blive brugt hvis den primæredatabase skulle fejle. For det meste er der adskilligekilometer, nogle gange hundredvis af kilometerimellem systemerne, og man er dermed beskyttetmod selv meget omfangsrige begivenheder somnaturkatastrofer eller lignende.Lad os nu kigge på de to teknologier med oven-nævnte forskelligheder i baghovedet.

RACRAC er den løsning der giver den kortest mulige fail-over tid. RAC tillader heller ikke datatab. Til gengældkræver RAC mere af de systemer den kører på.Et RAC system består af en eller flere uafhængigecomputere kaldet noder. Hver node har sine egneCPU’er, RAM og ofte også et par interne diske hvoroperativsystemet ligger. Hver enkelt node er et kom-plet og uafhængigt system. Mellem noderne er der ethøjhastighedsnetværk kaldet en interconnect og dertil

kommer et eksternt disksystem med et antal diskesom alle noder har adgang til. Det er vigtigt atbemærke at alle noder har lige adgang til de eksternediske som holder selve databasen.En typisk 2-node RAC konfiguration ser altså ud somi figur 1.

Når flere noder har adgang til databasen samtidigt,bliver det nødvendigt at sikre at alle skrivninger tildisken bliver gjort i den rigtige rækkefølge, sådan aten node ikke overskriver en anden nodes ændringer.Denne opgave varetages af Oracles DLM (DistributedLock Manager). DLM’en er indbygget i Oracle serverprocessen.For at Oracle serverprocessen kan bruge intercon-necten til at kommunikere med de andre noder, skalmaskinleverandøren levere et interface til systemet.Dette interface kaldes i Oracles terminologi for encluster manager. Oracle leverer selv cluster managersoftware til Linux og Windows.Hver node i et RAC cluster kører altså et operativsy-stem, cluster manager softwaren og en fuld version afOracle softwaren. RAC adskiller sig fra den ældre Oracle Parallel Serverved at kunne sende blokke over interconnecten. Detteer mange gange, ofte bogstaveligt talt 100 gange hur-tigere, end at sende blokke over disken som dengamle Oracle Parallel server gjorde. Denne nyeteknologi kaldes Cache Fusion. RAC henter meget afsin styrke fra netop Cache Fusion.

Cache Fusion Cache Fusion bruger DLM’en og cluster managerentil at synkronisere de individuelle Oracle instanser ogdermed få de enkelte Oracle instansers cache til atfremstå som én cache, deraf navnet Cache Fusion.Det virker sådan, at når en node har brug for en data-blok vil den først gå til DLM’en for at bede om den.DLM’en ved hvilke blokke der er i hvilke instanser, oghvis den er i en anden instans, vil DLM’en i samarbej-de med DLM’en på den anden node sørge for atblokken bliver sendt over interconnecten i stedet forover disken.Eftersom det ofte tager mindre end et par millisekun-der at sende en blok over interconnecten og vi for detmeste måler vores svartider i flere sekunder, kan mangentage denne proces mange gange indenfor enenkelt transaktion før det mærkes på ens svartider.Før Oracle udviklede Cache Fusion måtte man sendeblokkene over disken. Dette er forholdsvist langsomt,ofte fra 100 til 450 millisekunder, og vil hurtigt vise sigi svartiderne.Så kan man naturligvis spørge hvorfor i alverdenOracle ikke udviklede Cache Fusion for længe siden,og dermed undgik alle de performance problemersom skulle løses ved omhyggelig tuning af OracleParallel Server? Svaret er ganske enkelt at indtil fornogle ganske få år siden var hurtige og pålideligeinterconnects ikke noget man bare havde. De fandteskun i lukkede systemer som mainframes og megetstore Unix systemer, og var meget, meget dyre.

Figur 1: Typisk 2-node RAC konfiguration

OracleInstans

OracleInstans

Interconnect

Diske

OracleInstans

OracleInstans

Interconnect

Diske

Teknisk Artikel

DBA

Indenfor de sidste fire år er relativt billige intercon-nects baserede på åbne standarder blevet vidt tilgæn-gelige og dermed er markedet for RAC løsningerblevet mange gange større.

RAC og Fail-overNår en eller flere noder går ned vil de overlevendenoder overtage processeringen for de fejlede noder.Under en fail-over vil der være en kort periode hvor enaf de overlevende instanser laver recovery for deneller de fejlede instanser. I denne periode vil adgan-gen til databasen være stoppet, uden at brugerne afden grund bliver afkoblet databasen. Denne periodeer kendt som brown-out perioden. Brugerne er for-bundet til databasen, men kan endnu ikke lave noget.Længden af brown-out perioden bestemmes af hvormange blokke der skal laves recovery på, altså hvormange blokke der var ændret i den instans der er gåetned. Dette er en funktion af mange ting, f.eks. antalletaf data blokke i instansens cache, hvor mangetransaktioner der bliver foretaget, størrelsen på redologgene og hvor ofte der laves redo log skift. For atbegrænse denne brown-out periode har Oracle laveten parameter til Oracle instansen der begrænser fail-over tiden. Parameteren skal sættes af Oracledatabase administratoren, og sættes til et givet antalsekunder. Jo færre sekunder man sætter denneparameter til, desto mere kræver det af ens diske. Deter nemlig sådan at Oracle vil bruge statistikker omhvor lang tid det tager at skrive ud til diskene til atbegrænse det antal blokke der skal laves recovery påi tilfælde af et nedbrud. Det betyder at ændredeblokke vil blive skrevet ud til diskene oftere og dermedkan det resultere i flere disk IO’er. I praksis sættesdenne parameter gerne til et antal minutter for atspare på antallet af disk IO’er. Eftersom at RAC system er bygget op om kun éndatabase, er der ikke givet mulighed for data tabselvom en eller flere noder skulle fejle. Det betyder såogså, at skulle der opstå en fejl i selve databasen,f.eks. at en data fil mistes, eller noget lignende, såpåvirker det alle noder på en gang. Når en fejl i enkomponent påvirker hele systemet kaldes det, megetnaturligt og i mangel af et bedre udtryk på dansk, foret single-point-of-failure. I et RAC system erdatabasen et single-point-of-failure. Som vi skal sesenere, er der ikke noget single-point-of-failure i etData Guard system.

Forskellige Typer af KonfigurationerNår det overvejes at anskaffe RAC diskuteres detmeget ofte hvilken konfiguration man skal satse på:Skal der være nogle få store noder i systemet ellerskal man satse på mange små noder? Ofte diskuteresder også om man skal sprede brugerne over allenoder, eller fritage enkelte noder så de kun bruges nåren node er fejlet.

Mange små eller få Store?Store noder, dvs. ofte store Unix systemer medmange CPU’er, kommer for det meste med bedreværktøjer til overvågning, administration og fejlfinding.Mange komponenter er dublerede, og der er oftemuligheder for at udskifte fejlede komponenter menssystemet kører. Tilgængeligheden af de enkelte noderer ofte også meget højere end ved små noder.En stor del af udgiften ved et computersystem består

i prisen for at køre systemet. Den daglige vedlige-holdelse og administration er ofte den post der overen årrække bliver den største udgift. Det er derforvigtigt at have gode værktøjer til denne opgave.I almindelighed regnes det for lettere at administrerenogle få store systemer end mange små.Til gengæld er store systemer ofte også mange gangedyrere end små systemer. Der kan let være en faktor5 i forskel på prisen for f.eks. 2 store systemer i forholdtil 4-8 små systemer. Små noder er altså langt billigere end store noder.Generelt har de en lavere tilgængelighed end de storenoder, men til gengæld påvirker det færre brugere nåren lille node fejler end når en stor node fejler. Flerenoder betyder mere administration, og ofte er værktø-jerne ikke så avancerede som på de store noder.En af de helt store fordele ved små noder er at mankan modellere sin tilgængelighed i flere trin. Når manvælger at bruge flere små noder, kan man vælge omman vil have en eller flere ekstra noder til at overtagearbejdet fra noder som fejler. De betyder at man kanmindske den mængde hardware der er afsat til at givetilgængelighed. Et eksempel: Hvis man skal bruge 8CPU’er til sin opgave og man kun har 2 noder, skalder være 8 CPU’er i hver node for at man kan væresikker på at man har nok CPU kraft hvis den ene nodefejler. Har man derimod 4 små noder med 2 CPU’er ihver kan man vælge kun at have f.eks. en eller toekstra noder med 2 CPU’er hver. Det vil sige, at medde store noder skal man i alt bruge 16 CPU’er mensman med de små noder kan vælge om man vil bruge10 eller flere CPU’er. Man kan altså vælge flere grad-er af tilgængelighed. Hvis flere noder fejler på en gangog man kun har valgt at have en ekstra node har mannaturligvis en risiko for at man ikke kan servicere allesine brugere. Det er dog ret usandsynligt at flere sys-temer skulle fejle på samme tid uafhængigt af hinan-den.Oracle har ikke nogen begrænsninger med hensyn tilantallet af noder i en RAC konfiguration. Man kunne iprincippet sætte hundredvis af noder sammen i etRAC system hvis man ønskede det. Man skal dogvære opmærksom på at nogle maskinleverandørersætter en grænse for hvor mange maskiner de vilsætte i en RAC konfiguration. Indtil nu er alle kendtekommercielle RAC konfigurationer lavet med 8 ellerfærre noder.

Bruge Alle Noder Eller Dedikere NogleNoder til Fail-overNår man diskuterer om man vil sprede brugerne overalle noder på en gang, og således have flere CPU’ertil rådighed end hvis man afsætter nogle bestemtenoder til kun at blive brugt i fejl situationer, er det vigtigtat forstå præcis hvad kravene til systemet er. Hvisman bruger RAC til at skaffe sig high availability, erman nødt til at have en vis mængde ekstra hardwarefor at være sikker på at man kan servicere alle sinebrugere hvis en node fejler.Hvis brugerne er fordelt på alle noderne i systemet,inklusive de noder der er tillagt for at sikre tilgænge-ligheden, bliver det vigtigt at overvåge belastningenpå noderne i systemet for at sikre at der altid erkapacitet nok i systemet til at håndtere alle brugereselvom en eller flere noder skulle fejle. Det er ikke triv-ielt at måle belastningen på et system eller en enkeltnode. Der er en stor risiko for at man overser en vigtig

13OracleEkspert Juni 2003

14 OracleEkspertJuni 2003

ressource i systemet og dermed kan der opstå over-belastning i systemet.Når et computer system bliver overbelastet, kan svar-tiderne ændre sig radikalt. Hvis man bliver ved at øgebelastningen på et computersystem, altså sende flereog flere transaktioner til det, vil man opleve, at ved etbestemt punkt vokser svartiderne eksponentielt. (Sefigur 2).

Dette er en funktion af hvordan computersystemerfungerer helt generelt og har ikke noget at gøre medhvordan RAC fungerer. Når et computersystem bliveroverbelastet stiger den tid det bruger på at admin-istrere systemets ressourcer eksponentielt. Det bety-der, at alt efter hvor man er på kurven i figur 2, så kanen lille forøgelse af antallet af transaktioner resultere ien væsentlig forøgelse af svartiden, op til et punkthvor systemet er så langsomt at det må betragtessom ubrugeligt.Hvis man skal garantere en bestemt svartid, kan detvære en lettere løsning at konfigurere et system meden eller flere noder som kun bliver brugt når en andennode er nede.Man bør også overveje mulighederne for at teste sitsystem. Det er god praksis at sikre sig at man medjævne mellemrum laver en ”brandøvelse” altså tageret eller flere systemer ned for at sikre sig at man kankøre videre.

Data Guard Data Guard kan konfigureres til forskellige niveauer afbeskyttelse. På det højeste niveau kan Data Guardgarantere at der ikke mistes data. På det lavesteniveau af beskyttelse kan Data Guard konfigureres tilen hvilken som helst mængde data man kan tåle atmiste. Fail-over tiderne er langt højere end på RACkonfigurationer. Ofte accepteres f.eks. time lange fail-over tider. Data Guard kræver normalt manuel ind-griben for at lave en fail-over, hvilket i sig selv betyderat fail-over tiden vil blive længere.En typisk Data Guard konfiguration består af etprimært system og et standby system. Systemerne erfuldstændigt adskilt, og kræver kun at der er etnetværk mellem dem. (Se figur 3).Modsat en RAC konfiguration, behøver der ikke atvære et højhastigheds netværk mellem systemerne.Data Guard fungerer ved at kopiere redo loggen fradet primære system over til standby systemet ogderefter lægge ændringerne ind i standby databasen.På denne måde holdes standby databasen opdateret,om end med en vis forsinkelse. Database administra-

toren kan selv bestemme hvor stor denne forsinkelseskal være.Redo loggen i en Oracle database indeholder alle deændringer som er blevet foretaget på databasen. AlleOracle databaser har minimum 2 redo logs som umid-delbart kan bruges, kaldet online redo logs. Når enonline redo log er fuld, begynder Oracle databasen atskrive til den næste online redo log. Den fyldte redo

log arkiveres ved at indholdet kopieres til enarchived redo log. Når det er sket kan onlineredo loggen genbruges.

Data Tab Eller Ej?I en typisk Data Guard konfiguration bliverredo loggen overført til standby systemet efterden er blevet arkiveret. Det betyder at mankan miste alle de data der måtte være i onlineredo loggen og de archived redo logs somendnu ikke er blevet overført til standby sys-temet.For at minimere data tabet kan men konfig-urere sin database med mindre redo logs,eller ganske enkelt skifte redo logs oftere. Derer flere parametre i Oracle til at styre netop

dette.Data Guard kan også konfigureres til ikke at tillade tabaf data. Den proces som skriver ændringerne ned ionline redo loggen, logwriteren, kan konfigureres til atsikre at når der bliver skrevet i online redo loggen, bliv-er ændringer også skrevet i en særlig log på standbysystemet. Ingen transaktioner får lov at afslutte førændringerne er i sikkerhed på standby maskinen. Detbetyder at alle transaktioner på det primære systemnu også vil inkludere den tid det tager at overføretransaktions data til standby systemet. Svartidernebliver altså længere. Det betyder også at hvis netvær-ket går ned, eller standby systemet går ned, så kandet primære system ikke længere fungere. Så måman altså slå Data Guard fra, og når nettet eller stand-by systemet er oppe igen må man så slå Data Guardtil igen.

Data Guards Krav til NetværketData Guards performance er afhængig af netværket.Hvis netværket mellem den primære og standbydatabasen ikke kan transportere data omtrent ligesåhurtigt som de bliver skabt på den primære databasevil konfigurationen ikke fungere. Langsomt mensikkert vil der ophobe sig flere og flere archived redologs på det primære system, og standby databasen vilkomme længere og længere bagefter den primæredatabase. Når Data Guard er konfigureret til detlaveste niveau af beskyttelse kræver det at nettet er

Figur 2: Svartid som en funktion af antal transaktioner

Svartid

Transaktioner

Svartid

Transaktioner

Figur 3: En typisk Data Guard konfiguration

PrimærtSystem

StandbySystem

netværkPrimærtSystem

StandbySystem

PrimærtSystem

StandbySystem

netværk

godt til at transportere en stor fil over nettet nu og da.Hvis Data Guard er konfigureret til det højeste niveauaf beskyttelse kræver det at nettet er godt til at trans-portere små mængder af data meget ofte.At transportere en stor fil hurtigt over et netværkkræver at netværket har en stor båndbredde.Båndbredde er blevet væsentligt billigere, tænk barepå ADSL, og kan fås næsten alle steder. Det er altsåen let og billig løsning.At transportere mange små bidder af data meget oftekræver at nettet har en meget kort turn-around tid,dvs. når data er modtaget i den ene ende skal nettetkunne vende rundt og give besked til afsenderen atdata er modtaget. Turn-around tiden kaldes også net-tets ”latency”, som vel bedst kan oversættes til”forsinkelse”. Forsinkelsen bestemmes dels af densoftware der er blevet brugt og dels af den netværkshardware der er brugt. En hvilken som helst hardwaredevice på nettet, en router, repeater eller andet, vilbidrage til en øget forsinkelse på netværket.Forsinkelsen påvirkes også af den geografiske afs-tand. Det tager længere tid at sende data frem ogtilbage mellem f.eks. Europa og USA end det tager atsende data nogle få kilometer. I et ideelt netværk villedata bevæge sig med lysets hastighed. Men selv medlysets hastighed vil det tage omkring et halvt sekundat rejse til USA og tilbage igen. Der skal bruges flere ture frem og tilbage mellem detprimære og standby systemet når man skal sikre sigat data er sikkert modtaget, og dermed vil nettetsforsinkelse bidrage til at svartiderne bliver længere.Netværk med lille forsinkelse er langt dyrere en net-værk med stor forsinkelse, og det er ikke altid sikkertat de kan skaffes der hvor man skal bruge dem.

Switch-over Og Fail-overMed Data Guard skelner man mellem en switch-overog en fail-over.En switch-over er når man har lukket det primære sys-tem forsigtigt ned, uden at miste nogle transaktioner,og sikret at alle data er overført til standby systemetog at standby systemet ikke er bragt online før alledata er lagt ned i standby databasen. Med andre order man sikker på at inden man åbner standbydatabasen for brugere er de to databaser helt synkro-niserede. Når standby databasen så er online, errollerne byttet om, og den tidligere primære databasekan nu fungere som standby database. Når standbysystemet er online, vil det begynde at gemme transak-tionerne til det primære system sådan, at når dettidligere primære system igen kommer online vil detblive synkroniseret med standby systemet. Under etswitch-over er databaserne en kort tid fuldstændigens, men lige så snart at brugerne igen kan udføretransaktioner er databaserne forskellige igen.Synkronisering af databaserne kræver manuel ind-griben og altså også at der en kort periode hvorbrugerne ikke kan opdatere databasen. En switch-over styres af en database administrator som giverdatabaserne forskellige kommandoer for at forberededem på at skifte roller. En switch-over kan bruges til atteste at standby database fungerer som den skal ogf.eks. i forbindelse med mindre vedligeholdelsesopgaver som kræver at det primære system skaltages ned.En fail-over sker når det primære system fejler. De

data som ikke er overført og heller ikke kan overføresefter at fejlen er sket tabes naturligvis. Når standbysystemet er aktiveret, er det primære system ende-gyldigt tabt og skulle det komme tilbage er det nød-vendigt at genskabe den primære database fra grun-den. Hvis man i en fail-over situation på en eller andenmåde har fået alle data overført på trods af fejlen ogdet primære system kommer op igen, kan detprimære system genbruges uden at man skal gensk-abe databasen fra grunden. Normalt skal man dogregne med at skulle genskabe det primære system fragrunden.

Fysisk Og Logisk Standby DatabaseData Guard kommer med to forskellige typer af standbydatabaser, den fysiske standby og den logiske standby.I den fysiske standby bliver redo loggen kopieret oglagt ind i databasen i binært format. I en fysisk stand-by lægges redo loggen på blok for blok, ganske somdet sker ved en normal recovery af databasen. I denlogiske standby bliver redo loggen godt nok kopieret tilstandby systemet i binært format, men derefter bliverden behandlet og lavet om til SQL sætninger somudføres som almindelige SQL sætninger mod stand-by databasen.Under normale forhold kan standby systemet brugestil processering. Der er dog forskel på hvad man kangøre med en fysisk og en logisk standby.En fysisk standby kan kun bruges til læsninger. Når enfysisk standby bruges til læsning kan man ikke sam-tidig lægge redo på. Det betyder at standby systemkommer længere og længere bagud efter det primæresystem. Skulle det primære system fejle skal alle deakkumulerede redo logs lægges på standbydatabasen før den kan åbnes for almindelig pro-cessering. Det betyder, at der kan gå lang tid førstandby databasen er klar til at servicere brugerne.En logisk standby kan bruges til alt. Man kan bådelæse og skrive i den. Eftersom dette faktisk kunneødelægge den logiske standby, man kunne jo f.eks.droppe en tabel, regner man ikke den logiske standbyfor en rigtig high availability løsning. Det er mere enslags rapport server hvor man kan køre alle muligejobs man ikke vil køre på sin primære database. NårOracle sætter en logisk standby op foreslås det nor-malt at sætte en fysisk standby op på den sammeserver for at give high availability.

Blandede RAC Og Data GuardKonfigurationerRAC og Data Guard kan sagtens sættes sammen iden samme konfiguration. Man kan f.eks. have etRAC system som sin primære database og så brugeData Guard til at sende sine redo logs til et standbysystem som både kan være et almindeligt enkelt nodesystem eller et RAC system.Man kan konfigurere op til 9 standby systemer afforskellig slags, med frit valg mellem om de skal væreRAC eller ej. Det er dog vigtigt at gøre sig klart at joflere systemer man sætter op jo mere administrationskal der laves.Uanset hvilken konfiguration man vælger er det vigtigtat man overvejer hvordan man kan teste sit system. Ivores branche er et system der ikke er testet, et sys-tem der ikke virker.

15OracleEkspert Juni 2003

17OracleEkspert Juni 2003

Små og store nyhederNy administrerende direktør forOracle Danmark14/5 om formiddagen blev det meddelt internet iOracle Danmark, at Peter Perregaard skal have et jobi den europæiske organisation. Det er lidt uklart, hvadhans nye job er, men det har muligvis noget med ini-tiativer for øget salg af databasen at gøre.Hans afløser hedder Stig Jørgensen. Stig var adm.dir.for Informix Danmark, og blev hentet til Oracle i ’99,nogenlunde samtidig med at vi fik fisket Martin Jensenud derfra – og flere andre gode folk såsom Severin,Martin ABC Hansen, mv. Det må have været rimeligthårdt for Informix Danmark dengang, og det er jo ikkegået specielt godt for dem siden.Stig blev partner-direktør, og var en god mand. Han er– så vidt jeg kunne bedømme dengang – både dygtig,flink og venlig - og flittig. Han blev sendt til Prag for at køre den TjekkiskeOracle-organisation, og meningen var hele tiden, athan skulle hjem og overtage Danmark når Perregaardskulle videre i systemet. Forskellige internationale hændelser gjorde, at det toglængere tid end de to forventede.Der er nok af udfordringer at tage fat på for Stig, bådei forhold til kunderne, produkterne, organisationen,medarbejderne og partnerne. Og så har jeg en meget personlig hilsen til Stig: Da jegi sin tid blev fyret som chef for Premium var Stig(blandt andre) oppe hos Perregaard (som var udenskyld i hændelsen) og forsvare mig. Sådan nogetglemmer man ikke. Tak for det, Stig (og I andre) ☺.Stig må også nødvendigvis have tilegnet sig smag forgodt øl i sine fire år i Prag. Det i sig selv er jo en fan-tastisk anbefaling. Aldrig mere standardøl fraCarlsberg, når vi er på besøg hos Oracle – fra nu af

vil vi have original Budavar og Urquell!Min meddirektør Lasse og jeg vil naturligvis invitereStig til at blive medlem af bestyrelsen for MiracleBreweries.

42-års festen2/5 var en god dag. Først havde vi 60-70 deltagere tildet faglige (First Friday), hvor omkring 20 foredrag omalt fra ølbrygning over PostgreSQL og SQL Server tilhardcore Oracle-emner blev afleveret i den sædvanli-ge opløftede stemning og under megen dåseklinken.Vi havde bl.a. besøg af David Ruthven (chef for DDRi Support i UK), Mark Fulford (EMEA director for ToolsSupport), James Morle, Lex de Haan, Carel-JanEngels, James Morle – og alle deres koner, så detblev til nogle livlige dage og diskussioner.Også en højtstående medarbejder fra MySQL ABhavde taget turen til arrangementet. Ham kommer vitil at se mere til.Det var også fadøl fra Thisted Bryghus samt mangeandre gode øl fra Tyskland og Danmark.Endnu engang en varm tak til Alex Høffner, som fore-slog First Friday-ideen i sin tid.Mens jeg er ved det: Også en varm tak til MartinRoth, som foreslog at vi skulle hedde Miracle. Kl 18 startede selve festen med at der blev serveretIsbjørn som velkomstdrink. Den består af 2/3 cham-pagne og 1/3 vodka, som man ikke kan smage.Kapow! Bortset fra en enkelt jyde, der indtog drinken,besøgte toilettet og derpå sov i 2-3 timer før han giktilbage til festen, så virkede den ellers helt efter hen-sigten. Ballet var i gang med det samme.150 gæster talte vi til selve festen, og de gik til den. Enengelsk deltager fortalte mig forleden, at det varmeget længe siden han havde været med til en fest,hvor selv enkelte af damerne ikke kunne holde styr påderes ben.

Kære læser! Velkommen til syvende udgave af min klumme. Formålet med klummen er at informere om Oracle-ver-denen, give råd og tips, fortælle om arrangementer, mv. Alt sammen selvfølgelig tilsat private meninger,rene gætterier, usubstantierede rygter og ikke mindst løse formodninger J.Snakke-emnerne denne gang: Ny administrerende direktør for Oracle DanmarkRAC og HA (Det er ikke for at gøre forskel - i næste klumme taler vi om RAC og Bandidos :))Hvad er et robust system? Hvad er en stabil teknologistak?Specials fra Oracle University & Miracle A/S…Oracle dør (forhåbentligt ikke)Portal = Menu?The Support Economy. Teknik-emner: Opgradering til 9i?LMT, auto eller uniform?RBO og 10i

Venlig hilsen,Mogens Nørgaard

Groans Fra Mogens

18 OracleEkspertJuni 2003

Vivi, der til dagligt står for Oracle’s kantine, og allehendes søde hjælpere, gjorde det fantastisk godt, ogalle var glade for at se gamle bekendte også i køkke-net, osv. Så gik det løs med Danmarks eneste DBA-certificere-de diskjockey Steen Bartholdy fra DI. Manden, derspiller luftguitar stående på sine højttalere. Og derblev danset så det ville noget. Endnu engang var alledamerne meget tilfredse med denne del af arrange-mentet.Hemmeligheden er selvfølgelig en stærk velkomst-drink på tom mave og så ellers fuld tryk på musikken.Jeg vil aldrig røbe, hvem der har lært mig det. Hun vedselv, hvem hun er.Ved midnatstid dukkede fire kampklædte betjente op,og da jeg spurgte dem, om jeg kunne hjælpe dem fikjeg at vide, at de ledte efter ”en støjende ungdoms-fest”. Tak for smigren, sagde jeg – gennemsnitsalde-ren her er nok ca 42. De grinte og kørte til Smørum,hvor en ungdomsinstitution var gået amok.Så begyndte vi at pakke sammen ved 1-tiden, var udeved 2-tiden og drak øl på Kratvej til ved 4-tiden.Og sikke nogle gaver jeg fik. Mine gode venner Ole ogPia har f.eks. givet mig et aggregat (de har købt detvia internettet, så det er selvfølgelig ikke ankommetendnu), der gør det muligt for mig at lave en dildo-afs-tøbning af min egen <censur>. Ole var så venlig atfortælle alle de tilstedeværende om denne gave viamikrofonen – han mente også, at der for mit vedkom-mende var materiale nok til tre afstøbninger.Jeg fik også en hånddreven oplader til mobiltelefonenaf Lex de Haan. Den er jo praktisk at have med sigrundt omkring. Og giver fin motion.Derudover 59 flasker god vin, 10 flasker whisky og 8flasker forskelligt (champagne, gin, etc.).Jürgen Kuhn har selv lavet et aggregat, der kan opta-ge flere forskellige hilsener alt efter hvem der ringer tilmig på min mobilos. Det er et fantastisk apparat, somovenikøbet er malet i camouflage-mønster. Tak!Eller hvad med Chokolade og nougat body paint?Genialt! Rigtigt mange tak!Jeg bør også for god ordens skyld nævne, at jeg fikhøns. Så nu har vi igen høns på Kratvej. Og en hane,som dog nok forlader os snart. Hanner er ikke rigtigtbrugbare til noget, og de spiser en masse. Det gælderogså i hønseverdenen.

RAC og HAJeg har et problem, som jeg vil formulere ganske kort:Jeg kan ikke se nogen som helst mulig kombina-tion af RAC og Data Guard, der giver fuld 24/7/365eller 25/8/370, som Michael Möller helt brilliant harkaldt det – idet han mener, at det er ligeså realistisk ☺.Med andre ord: Jeg kan ikke se nogen mulig kombi-nation af RAC og Data Guard, der gør det muligt atopgradere eller patche mens kunderne stadig haradgang til systemet, dvs at man opnår de elskede 3,4 eller 5 9-taller i sin oppetid.Min påstand er, at kunderne, hosting-firmaerne, leve-randørerne og andre definerer sig ud af det ved atdefinere oppetid som alt muligt andet end planlagt oguplanlagt vedligeholdelse ☺☺.Når man skal patche eller opgradere RAC er der jogodt nok to eller flere instanser og to eller flere noder.

Men kun én database, og det er jo den man pat-cher/opgraderer.Så kunne man jo anskaffe sig en kopi af databasen,f.eks. vha Data Guard. Men Data Guard kræver altså,at man kører nøjagtigt samme version af Oracle (nedtil patch-niveau) på begge installationer.Så man er altså nødt til hive begge databaserne nedfor at patche og opgradere dem.Jeg HAR checket med folk helt inde i OracleDevelopment, og det ser ud til, at jeg har ret i minteori.Med de flotte powerpoint-slides ser det ud til, at manjagter de få minutter om året, hvor man er nede pgainstance-failure, men ignorerer de mange timer maner nede pga patching og opgradering….Hvad gør man så?Jeg kan se tre muligheder, men der er nok flere (jeghører gerne om dem):

- Enten lever man med det.- Eller man opgraderer aldrig.- Eller man anvender tredje-parts produkter.

Lever med det: Dvs man har regelmæssige vedlige-holdelses-vinduer, hvor man gør det nødvendige. Detvirker fint for planlagte patches og opgraderinger, menduer ikke for nødsituationer (f.eks. security-patches).Opgraderer aldrig: Se, det er jo en mulighed. Så harman måske endda et robust system, en stabil tekno-logistak (se min artikel om dette andetsteds i bladet).Men i den virkelige verden kan det ikke lade sig gøreret mange steder. Nye krav fra forretningen, sikker-hedshuller, opgraderinger af andre dele af stakken –alt sammen er ting, der meget nemt fører til patchingeller opgradering.Anvender tredje-parts produkter: Her er jeg på gyn-gende grund. Anjo Kolk siger, at der findes Veritas-produkter, derkan hjælpe vha noget han kalder StorageCheckpoints eller sådan. Quest siger, de kan det med Shareplex. Jeg har ikke selv set eksempler på det, men hvis detvirker er det da værd at overveje, hvis man virkeligjagter de der 42 9-taller. Den ekstra omkostning for atsikre ekstra 5 minutters oppetid kunne imidlertid visesig at være ganske høj… her er et citat fra en storamerikansk virksomhed, som skrev til mig for nyligtpga mint ”You Probably Don’t Need RAC”-foredrag påHotsos Symposiet i Dallas i januar:“What our decision came down to was the"unplanned" downtime. Historically, we have had atmost one unplanned downtime per year on our serv-er that we wanted to RAC. We already have HACMP(AIX) running pretty well, and we test it during ourserver maintenance weekends. The last time that wehad an "unplanned downtime" (actually, I crashed theserver), HACMP had taken over and had the systemup in less than 5 minutes, before our sysadmin hadeven been paged. Therefore, just the extra Oracleand RAC licenses would be 300K+22% annually =$140K / year (4 years) for an extra 5 minutes ofavailability. That is a tough sell.”Jeg lader emnet ligge her for nu, men det er sgu’ såinteressant, at jeg nok vender tilbage. Jeg er i særde-leshed meget interesseret i at høre, hvilke løsnin-

19OracleEkspert Juni 2003

ger, der reelt kan adressere, at det er databasen,der patches/opgraderes, og som derfor skal værenede mens man gør det.

Specials fra Oracle University &Miracle A/S…og DBAftenVi har afholdt et par Specials på skrivende tidspunkt:En HA-dag med Carel-Jan Engels og diverseOracle/Miracle-folk og en SQL Logic-dag med Lex deHaan. Folk har været godt tilfredse, og i næste uge(uge 21) har Jonathan tre dage, hvor der er fin tilslut-ning.Og vi fortsætter det gode samarbejde. Både i form af flere tekniske seminarer (dem burde Ihøre mere om enten fra Miracle A/S eller via Oracle’skursuskatalog). Og i skikkelse af DBAftenskole, som vi altså er nødt tilat have tilbage. Det går ikke uden. Det var Lars Dohn, som dengang stod for OracleDanmarks interne systemer, der kom på ideen. Underen god firmafest forelagde jeg ideen for en dame medstor indflydelse på tingene (som sad på mine knæ pådet tidspunkt) - og så gik det jo ellers deruda’. MedDBAften-skolen, altså.I år har vi de fem første runder hos Oracle Dan-mark og den sidste (sjette) på Brydegården iMåløv, hvor vi slutter af med stilfærdig chili con carneog helt roligt øl til vi ikke gider mere.Bag disse Specials ligger en udvikling, som ses over-alt i branchen: Folk tager ikke mere de relativt langestandardkurser, men foretrækker målrettede kurser.Det kan være stærkt fokuserede emner som f.eks.materialized views, eller det kan være emner, der errelevante for netop den kunde. I begge tilfælde duerstandardkurserne ikke, og folk har i øvrigt sjældenttiden/tålmodigheden/pengene til dem.Begrebet hedder – YUK! – Just-In-Time Training(Jitt’ers?), og jeg HADER det udtryk. Men det hedderdet altså.Det hænger selvfølgelig sammen med, at databasener blevet noget, der bare skal køre henne i hjørnet, ogDBA’en skal tage sig af den og en masse andre ting –men ikke med udgangspunkt i 42 dages standardkur-sus. Jeg synes det er al ære værd, at Oracle Education iDanmark gør noget ved denne trend i stedet forbare at sætte sig med hænderne i skødet og kigge påudviklingen. Indtil videre er det noget, der varierer meget fra land tilland. I Holland har de ni Specials i maj måned alene,og har en laaang forhistorie med sådanne dage. Iandre lande ser det bestemt ikke sådan ud – endnu.

Oracle dør (forhåbentligt ikke)Jeg får jævnligt reaktioner fra Oracle-folk, der synes,at ”nu er du fan’me gået over stregen”, både meddet ene og det andet emne. Jeg bliver virkelig tæsketfor at sige, at Oracle (og andre i branchen) risikerer atdø, hvis de ikke fornyer deres forretning. At IDG siger det samme har ikke noget med sagen atgøre – jeg skal i hvert fald ikke gøre det. Det er jo kæt-teri.Jo jeg skal. Og det skal andre også, hvis de synes det.

Der er to typer partnere/kunder på markedet: Kategori I: Dem, der smiler venligt/falskt til Oracle ogsiger, at alt er godt, mens de for fuld fart forbereder sigpå at satse på andre områder – de gider bare ikke bal-laden, der automatisk opstår når man kritiserer elleradvarer Oracle.Kategori II: Dem, der råber op og prøver at fortælle,at der er noget galt.Gæt, hvilken kategori I finder Oracle’s virkelige fansog venner i? Gæt, hvilken kategori Oracle kritisererhårdest og gør mest grin med? Hvor heldigt, at det ersamme kategori, ikke? ☺.Jeg har prøvet flere gange at forklare Oracle-folk, atjeg (og f.eks. Miracle-folkene) præcist råber op fordivi er bekymrede, og fordi vi synes vi ser nogle ting,som Oracle selv ikke ser ud til at have set endnu. Ellermuligvis har set, men ikke kan gøre noget ved. Vi vilnetop gerne have, at Oracle overlever.Når folk forlader Oracle og starter i Miracle (eller etandet firma) går der lige et stykke tid, og så kommerde som regel og siger, at de kan se, Oracle gør diteller dat forkert. Men de kan ikke se det mens de er iOracle. Det er da højst forståeligt – men det berettigerikke til at gå efter de, der prøver at råbe vagt i gevær.Det er et resultat af den der herlige Oracle-ånd (somvirkelig er dejlig at opleve som ansat), der desværreogså foreskriver, at:

- Folk uden for Oracle er dummere end folk inden-for, og

- Når folk forlader Oracle bliver de på få sekunderpludseligt dummere end Oracle-ansatte.

Hvis man som u(den)forstående kan fortælle enOracle-tekniker noget han ikke lige vidste, så kan manvære meget sikker på, at han føler sig kaldet til atnævne enten 1) en situation, hvor han ikke syntesman selv var godt nok eller 2) et eller andet faktumman ikke vidste. Den der ”Hold kæft, det er sgu’ da godt set”, eller ”Detvar sgu’ da interessant” er der langt imellem i den eneretning, kunne man sige. Så kan man altså holde alle de ”Lyt til kunden”-møder og seancer og kick-offs man har lyst til. Detender altid lige præcist der, hvor man skal respektere,at kunden/partneren faktisk kunne vide noget, somOracle ikke ved.Det rædselsfulde er, at når jeg snakker om Oracle’sstrategier og deres plads i IT-samfundet, så er der rig-tigt mange, der er ligeglade eller som synes Oraclevælger forkerte strategier. Men de siger det ikke tilOracle – hvorfor dog risikere balladen og kritikken?Når Oracle forstår, at det er deres venner, der prøverat fortælle dem noget – mens dem, der bare nikker ogsmiler er ligeglade – så kan genopfindelsen afOracle begynde. Ikke før.Oracle holder sin overskudsgrad pt ved at spareudgifter, ikke ved at tjene flere penge. Med andre ord:Der fyres. Det er fint nok – det skal man jo gøre indimellem, og det kan ikke undgås, når markedet tagerde ture op og ned som det gør. Men det kan man ikkeblive ved med.De to mest profitable indkomst-områder for Oracle haraltid været databasen og Support. De to områder erunder pres af vidt forskellige årsager. Databasen erblevet en commodity, og det betyder pris-pres.

20 OracleEkspertJuni 2003

Support er en procentdel af databasens pris, så dengår også ned målt i dollars. Og Support er blevetdårlig, så folk gider ikke betale for den.Andre indkomstområder har ikke tilstrækkelig over-skudsgrad til at kunne opveje disse ting. iAS’en kunnemåske blive det, hvis den slår igennem. Apps kræverfor mange resourcer og er under ekstremt pres fraSAP og Microsoft m.fl. Collaboration Suiten? Tjah – ideen er god, men hvormange vil satse deres email-system på andre endMicrosoft i dag? Hosting er i så stærk konkurrence med trebogstavs-partnerne (CSC, IBM, EDS, etc.), at jeg ikke menerOracle kommer ret langt med det.En af de muligheder der tales om, som Oracle kunnegøre for at det hele bliver sjovt igen, er at slå sig sam-men med en anden leverandør. Jeg kan ikke lige ptse så mange muligheder:Microsoft? Næppe. Bill og Larry er for forskellige. IBM? Forhåbentligt ikke – så ender Oracle ligesomInformix – det er kun kunderne IBM er ude efter. Dell? Næh, de er PC-folk, der prøver andre områder.Det ville være ligesom med Digital og Compaq. HP? Det er en mulighed: De har forskellige platforme,de har ingen database-produkter, de er vant til atarbejede med teknologi både som hardware og soft-ware – og Larry og Carly kan rigtigt godt sammen.Men så længe Larry sidder med 22% af aktierne ellerderomkring er det ligesom svært at få nogen til at sigedet unævnlige. Hvem ville synes det var sjovt atdeles om magten med Larry?Undskyld. Vi elsker Oracle – det har været voresliv i mange år. Så lyt dog og forstå, at vi er jeresvenner.

Portal = Menu?Det her er en opfordring: Er der ikke én eller anden,der kan forklare mig, hvad forskellen er på enhovedmenu og en portal? Folk taler om portaler migher og portaler mig der, men hver gang jeg kigger påden – hver gang jeg ”går ind på en portal” – kan jegikke se andet end nogle punkter man kan vælge lige-som i en menu.Hvad er forskellen?

The Support Economy. En veninde købte ADSL fra TDC til sit hjem. Detvirkede ikke. Ringede til TDC, som mente det måttevære netkortet.Fik et nummer til HP, som har lavet PC’en.Nummeret virkede ikke. Fik så 5-6 mobilnumre fraTDC. Samtlige var sat på voicemail og nu flere ugersenere har hun ikke hørt fra en eneste af dem.Så mente TDC, at hun burde ringe til Boston til etfirma derovre. Efter mange engelske fagspørgsmålmåtte hun give op.Til sidst ringede hun til mig. Morten Egan tog deruden aften mod at blive lovet aftensmad. TDC prøvedeat få ham til at mene, at det var netkortet. Da han såligesom kunne fortælle om sin ipconfig kommandomv. så mente TDC pludseligt, at det kunne værederes router, så de ville sende en ny med det samme.

Masser af mennesker har samme typer oplevelser.De er faktisk blevet beskrevet i en ny bog af enHarvard-professor ved navn Shoshana Zuboff. Hunhar sammen med sin mand James Maxmin (sikke etefternavn) skrevet en bog med titlen ”The SupportEconomy”.De mener, at den næste bølge indenfor kapitalismenbliver at hjælpe folk i stedet for at lade dem hænge itelefonkøer i timer mens de lytter til beskeden om, atdette opkald er meget, meget vigtigt for dem.Bogen argumenterer for, at der er et kæmpehul mel-lem leverandørerne og forbrugerne. Og det er enforretningsmulighed.Ja, det er det - hvis forbrugerne vil betale for det.Virksomheder kan være nødt til at betale for det for atsikre noget så simpelt som at kunne ringe til et num-mer når noget er galt, eller de bare gerne vil spørgeom noget – og det måske endda haster, eller de bareikke har så meget tid på hånden lige nu.Det er ligesom lægesystemet herhjemme: Vibetaler for det via skatten. Nogle vil mene, at vi betalerrigeligt. Vi får bare ikke rigtigt den service ud af det,som vi ønsker. Hvis vi vil have hurtig og rigtig godhjælp ender vi næsten altid med at betale ekstra fordet, bare for at få løst problemet.

Opgradering til 9i?Oracle 8i bliver officielt desupporteret 31/12-2003.Med mindre man er Apps-kunde, for så er det først31/12-2004. Mange kører stadig 7.3 eller 8.1, og harikke brug for nye features i 9i.Skal man så opgradere til 9i? Næh, det behøverman ikke, med mindre man regner med at rende ind ien bug, som aldrig er set før. Ellers kan man roligtkøre videre med en usupporteret version.Hvorfor skulle man dog opgradere og dermed endnuengang opleve at noget ændrer sig i systemet – udenat man havde brug for diverse features i 9i?Oracle vil kunne supportere 8i-opkald i lang tid endnu,så tag det roligt. Vent evt. til Final Release af 9i er ble-vet annonceret.Der er masser af tid, og der er mange issues, så hvor-for ikke vente til 10i (tii) er kommet ud og 9i er blevetadopteret af mange kunder? Som det er i dag er dermeget få, der har brug for 9i’s features (der sker jo hel-ler ikke de helt store udviklinger mht store projekter fortiden.

LMT: Auto-allocate eller uniformsize?Locally Managed Tablespaces er alle enige om atbruge. Der er meget få issues med dem (se evt.Connor McDonald’s artikel om det påwww.OakTable.net). Men de kan bruges på tomåder: Auto-allocate eller uniform size.Og her skilles OakTable-folket lidt mht præferencer. ITom Kyte’s kommende bog, som jeg har æren af atvære en af 42 reviewers på, taler han (også om detteemne) efter devisen: ”Well, jeg var skeptisk i begyn-delsen, men nu synes jeg det er helt fantastisk, og allebør bare bruge det uden undtagelse.” Det hygger vi os lidt med. Tom siger, at jeg er god tilat få ham til at skærpe sine synspunkter ☺. Specielthader han når jeg siger, at PL/SQL er databasernes

21OracleEkspert

Cobol, og at han ligeså godt kan indstille sig på en vir-kelighed med Java og .Net. Nu er Tom jo ikke ligefrem den dummeste mand jeghar mødt til dato. Han er faktisk både flink, lyttende –og skræmmende vidende og dygtig, så vi har noglerigtigt gode debatter i forumet, og når vi mødes.Men essensen i diskussionen er, at auto-allocatebenytter sig af forskellige extent-størrelser i sammetablespace, mens uniform benytter sig af én. Jeg(og Jonathan Lewis og nogle andre) synes jo, at manskal holde sig til én extent-størrelse, og at auto-allo-cate blot er en avanceret tilbagevenden til gamle tidermed fragmenterede tablespaces. Formålet med auto-allocate er udelukkende at beg-rænse antallet af extents per objekt/segment. Men da antallet af extents i LMT’er kun er noget manbeskæftiger sig med, hvis man 1) ikke er korrekt infor-meret eller 2) hvis man er et æstetisk menneske, derelsker skønheden og enkelheden (eller avanceredemønstre) – så kan det da være ligegyldigt med det derauto-allocate, synes jeg.Så hvorfor ikke benytte sig af uniform size, som sikrermod fragmentering?Tom Kyte argumenterer for auto-allocate, fordi man såikke skal tænke nærmere over tingene mere, ogdet er selvfølgelig også til dels rigtigt når man taler omsystemer, der ikke bliver passet. Auto-allocate ogauto-extenting tilsammen gør jo, at systemet kanoverleve mange ting og sager.Alligevel vil de fleste af os gamle, fortabte Oracle-bru-gere nok foretrække forudsigeligheden og kontrol-len i vores kære databaser.

RBO og 10iIngen ved officielt, hvad 10i kommer til at indeholde(jeg gør heller ikke), men Beta-programmet gårigang nu, og det ser ud til, at jeg, Cary Millsap og flereandre OakTable-medlemmer bliver en del af det –forat få en ”OakTable”-effekt.Og så får jeg antagelig også adgang til programmetfordi jeg skal til at redigere/koordinere en bog med tit-len ”Tales from the OakTable”, hvor forskelligeOakies fortæller historier fra det virkelige liv.En af de ting, der trods alt er blevet annonceret alle-rede, er de-supporten af den regel-baserede opti-mizer. Men læs lige igen, hvad der står i annoncerin-gen:“The RBO is Oracle's legacy optimizer originatingfrom Oracle Version 6 and earlier. The RBO is beingdesupported in Oracle10i. The RBO will still exist inOracle10i, but will be an unsupported feature andwill be removed in a future release. No codechanges will be made to the RBO code and no bugfixes will be provided. The RBO was superseded inOracle7 by the CBO and has continued to be avail-able for backwards compatibility. Oracle Oracle10i willsupport only one optimizer, and all applications run-ning on that release should use that optimizer. “Den findes altså stadig i 10i. Hvad de færreste måskeved, er at RBO’en er blevet forbedret løbende gen-nem version 7 og 8, så den kender til nye former forsegmenter, etc. Jeg har altid troet, at den sidst blevudviklet på i version 7.0, men Steve Adams lærte mignoget andet.

Det ser ud til, at det er denne udvikling, der nu stop-pes. For selve supporten af RBO har i lang tid væretefter opskriften: P1-bugs ville blive fixet (men dem erder jo ikke så mange tilbage af efter så mange årsbrug), mens den ikke bliver forbedret.Jeg tror personligt, at 10i bliver annonceret ved OracleWorld i San Francisco i september.

Dit firma kanblive sponsor for

OracleEkspert

Danmarks eneste uaf-

hÊ ngige Oracle-tidskrift

har brug for sponsorer.

Har dit firma mulighed

for at pÂtage sig nogle af

f�lgende opgaver:

- Bladtryk

- Salg af abonnementer

- Salg af reklamer

- Skaffe alsidige artikler

- Nyhedsredigering

- Korrektur

- Evt andet...

SÂvil vi fremhÊ ve dit

firma som st�tter af dansk

netvÊ rk og vidensud-

veksling gennem et per-

manent logo p bladets

forside samt banneran-

nonce p bladets hjemme-

side:

www.oracleekspert.dk

Kontakt venligst redak-

tionen@oracleekspert.dk

eller ring til 26279991 for

at diskutere mulighederne

for et samarbejde med

OracleEkspert.

Juni 2003

Data Modeling for Everyone Forfatter: Sharon AllenAntal sider: 501ISBN: 1-904347-00-2Bogen handler kort beskrevet om følgende:

• Relationel datamodellering• Den relationelle teori• Analyseniveauer• Hvor hører modeller henne i projekter• Logiske modeller• Overførsel fra logisk til fysisk model• Dimensionel datamodellering• Meta datamodellering

Bogen kan læses med forskelligt formål, er man nyb-egynder indenfor datamodellering gennemgår deførste kapitler grundigt den relationelle teori, normalis-ering samt hvordan man opbygger E/R modeller.Sharon Allen anvender Oracle som eksempel-database, og Erwin fra CA som datamodeller-ingsværktøj, og kender man til disse to i forvejen, gørdet bogen endnu bedre, men det er absolut ikke enforudsætning.Da jeg læste bogen ville jeg gerne vide lidt mere omDimensionel datamodellering og Star Schemaer, ogdet beskriver hun også på en let tilgængelig måde.Noget jeg også har nydt under læsningen er hendeseksempler, hun har mange modeller over computer-spilsystemer, og det er en dejlig forandring, man kanblive lidt træt af ansatte, firmaer, fakturaer – de megettypiske modeller.På en binær skala fra 000 til 111 er karakteren:

Oracle 9i DBA HandbookForfatter: Kevin Loney og Marlene TheriaultAntal sider: 953ISBN: 1-07-219374-3Bogen handler kort beskrevet om følgende:

• Arkitetur• Konfiguration af hardware og den fysiske

database• Drift af databasen• Pladsovervågning• Transaktionsstyring• Tuning• Statspack• Netværk• Sikkerhed• Backup og Recovery• Oracle Net• 9ias

Bogen giver et godt overblik over hvad en Oracledatabase er, ikke kun i Oracle 9i, den har hele tidenbeskrivelser af, hvad man f.eks. gjorde i Oracle 7.3.4,samt hvad man kan gøre i efterfølgende versioner.Det gør bogen meget rar at læse og anvende, hvisman arbejder i et miljø med mange forskellige ver-sioner af Oracle, da det kan være lidt svært at bevareoverblikket over, hvad det nu er man kan i hvilke ver-sioner.Hvis man som jeg er lidt gammeldags og indimellemforetrækker at læse en bog, fremfor at sidde og bladrepå web’en, i PDF filer o.s.v., så giver denne bog engod og rimelig grundig gennemgang af Oracle i demange versioner, og der er emner man kan havebehov for at læse mere om, men tag den med påaltanen, i toget o.s.v., og suppler med elektroniskinformation om de emner man gerne vil meget mere idybden med.Bogen gennemgår også de fleste relevante komman-doer, og det nu dejligt lige at kunne slå op, hvis manikke lige kan huske syntaksen.Bogen er henvendt til alle, den hedder DBAHandbook, men det skal ikke tages bogstaveligt, enOracle udvikler får også et godt udbytte af at læseden.På en binær skala fra 000 til 111 er karakteren:

22 OracleEkspertJuni 2003

Bentes Bøger

Kære læser,I denne rubrik vil du kunne læse min mening omforskellige Oracle-relaterede bøger, jeg har læst.Du er velkommen til at kommentere mine vur-deringer i en mail til Bente@OracleEkspert.dk.Du er også meget velkommen til at indsende dineegne boganmeldelser.

Venlig hilsenBente Rosenkrantz-Theil

1 0 1

1 0 0

23OracleEkspert

Oracle User Group Denmark er en selvstyrende gruppe for Oracle-brugere. Det er for tiden gratis at være medlem,dog skal man have en Oracle-databaselicens for at kunne blive medlem. Gruppen består af en bestyrelse og et antal Special Interest Groups, som afholder møder i Oracle Danmarks lokaler iBallerup. Indkaldelse til møderne sker via brugergruppens mailliste og via brugergruppens web-side (www.oug.dk).SIG’erne har også individuelle maillister, som man kan tilmelde sig via www.OracleEkspert.dk.

OUGDK StormødeKoordinator: Mogens Nørgaard, mno@MiracleAS.dkNæste møde: 18. juni kl 15:00 hos Oracle Danmark

• iAS' Infrastrukturdatabase.

DBA SIGKoordinator: Jean-Marc Pedersen Gruppen har en mailliste, som alle kan tilmelde sig via www.OracleEkspert.dkNæste møde er endnu ikke fastlagt.

DesWeb SIGKoordinator: Marc de Oliveira, Marc@deOliveira.dk. Forslag til mødeemner modtages meget gerne. Gruppen har en mailliste, som alle kan tilmelde sig via www.OracleEkspert.dkNæste møde: 20. august kl. 13:00 hos Oracle DanmarkEmner for næste møde:

• Managing Oracle-Based Development—A New Configuration, Bug, and Process Management Product from Oracle- Ian Fisher

Developer SIGKoordinator: Lone Aalekjær, loaal@wmdata.comNæste møde er endnu ikke fastlagt.

Data warehouse SIGKoordinator: Erik Haar, erh@lundbeck.comGruppen har en mailliste, som alle kan tilmelde sig via www.OracleEkspert.dkNæste møde er endnu ikke fastlagt.

Husk at tilmelde dig til møderne hos Martin.Wittenkamp@Oracle.com (ellers får vi for få kager/vand!!)

OUGDK

Deadline for artikler til

OracleEkspert nr 1918. juli 2003

www.OracleEkspert.dk

Juni 2003

Tidligere pris: Ny pris:Grundpriser:

Hel side i farver: 5000.- 2000.-Halv side i farver: 2500.- 1200.-Kvart side i farver: 1250.- 800.-

Specialsider:Forside: Grundpris + 200% 100%Bagside: Grundpris + 60% 50%Side 2 og 3: Grundpris + 40% 25%

Præsentationsartikler (pr side): 2000.- 1000.-

Vedlagt materiale (max 20g): 2500.- 2000.-

Ved samtidig køb af tre annoncer i sammestørrelse og placering gives 25% rabat

Yderligere information:info@OracleEkspert.dk

eller 26279991

Dette er det bedste tidspunkt atannoncere i OracleEkspert