#34 ORACLEEKSPERT P ODCAST 2 P ROBLEMER MED DET OBJEKTORIENTEREDE P ARADIGME 4

Transkript

1 Februar 2006 Nr 34, Årgang 7 ISSN Pris: kr. 300,00 ex moms L IVE 23 Oracle 10g R2 skalering med AMD Opteron, 64-bit Windows og RAC Dato: 27. februar 2006 Oracle 10g R2 skalering med AMD Opteron, 64-bit Windows og RAC Dato: 1. marts 2006 Besøg af Amir Kahana fra Symantec om I3 (tidl Veritas) Dato: 14. marts 2006 Kursus: Avanceret Systemanalyse Tidspunkt: marts 2006 DesWeb SIG-møde om Raptor Evaluering Dato: 26. april 2006 Kursus: Objektorienteret Analyse Dato: maj 2006 Optimising Oracle Performance by Design med Jonathan Lewis Tidspunkt: maj 2006 N YHEDER 12 Norsk Politi vælger Oracle Oracle opkøber Sleepycat Software Oracle opkøber Hotsib AB Oracle vil opkøbe open-source firmaer Oracle fyrer 1000 medarbejdere Oracle vinder sag om "brugte" licenser Larry Ellison advaret om at nedsætte personligt forbrug Siebel-aktionærer accepterer opkøb Gartner kritiserer Oracle-sikkerhed Oracle Fusion holder tidsplan #34 Questioning Solutions Since 2OOO ORACLEEKSPERT P ODCAST 2 Af Marc de Oliveira P ROBLEMER MED DET OBJEKTORIENTEREDE P ARADIGME 4 Af Marc de Oliveira Iløbet af de seneste fem år er der blevet produceret en lang række udviklingsmetoder, som udspringer af det objektorienterede paradigme, som feks Xtreme Programming, Scrum og andre tiltag under Agile-fanen. SPØRGEJØRGEN ET 10 Af Mogens Nørgaard Hvad vi synes udviklere skal vide... Eller: Det er altid applikationen versus Alle performance-problemer starter i Design-fasen. F LERE MV PÅ SAMME BASIS-TABEL 16 Af Martin Jensen Denne artikel søger at beskrive nogle af fællerne ved denne type snapshot -anvendelse af Materialized Views. Alle eksempler er afviklet på en Oracle kerne version M ENINGSMÅLINGEN 19 Af Marc de Oliveira N ØRGÅRD S N EWS 20 Af Mogens Nørgaard MENINGSMÅLINGEN - ER DU ENIG? Podcasting er et godt medie til Oracle-stof Stem på - Du kan vinde et OracleEkspert-krus

2 LEDER Af Marc de Oliveira ORACLEEKSPERT PODCAST De fleste læsere af OracleEkspert er nok klar over, at bladet lige siden sin fødsel i august 2000 har haft en meget dårlig økonomi. Økonomien har tit været et emne her i lederspalten, og talrige mere eller mindre fantasifulde forsøg på at tiltrække flere abonnenter har været at finde mange steder. Mange velmenende læsere har ofte foreslået at bladet reducerede sine omkostninger ved at følge med tiden og afvikle den trykte udgave, så vi kun producerede en elektronisk version. Andre har foreslået at underlægge sig den voksende globalisering og udvidede markedet ved at skrive på engelsk. Jeg har stædigt afvist begge dele, ikke fordi jeg er en bagstræberisk stivstikker, der ikke vil acceptere de nye tider, men fordi jeg mener, at der er en væsentlig værdi i det fysiske medie, og at selv om alle OracleEkspert-læsere kan forstå engelsk, så er kommunikation på vores modersmål meget rigere end på et tillært sprog. Det er både nemmere at udtrykke sig præcist og det er nemmere at gennemskue validiteten i andres indhold. Så selv om OracleEkspert for nogle år siden begyndte at udkomme på elektronisk form, er der pt ingen planer om at opgive disse to elementer. Men teknologiudviklingen i medieverden er ikke gået mig forbi. Jeg mener at podcasting, som i disse måneder er ved at etablere sig for alvor i Danmark, kan have stor værdi - også for Oracle-miljøet her i landet. Lad mig her lige indskyde en kort introduktion til hvad podcasting er, for dem af jer, som måske endnu ikke helt har fået det på det rene. Podcasting er i løbet af de sidste par år blevet et stort fænomen i USA. For to år siden gav en Google-søgning på ordet podcast 0 hits. I dag giver det 159 mill hits, så det lille ord har sandelig tiltrukket sig megen opmærksomhed siden det dukkede op. Som man måske kan regne ud er ordet opstået som en sammentrækning af ordene ipod (mp3-afspiller) og broadcast (radioudsendelse). Følgende er de tre vigtigste elementer i begrebet podcast: 1) Alle kan komme til orde, da produktionsomkostningerne kan gøres meget små. Alle med en computer med mikrofon og en internetforbindelse kan sidde ved deres køkkenbord og lave deres eget radioprogram i form af mp3-filer, som lægges ud på internettet til alle, som har lyst til at høre, hvad de har på hjertet. Og det gør de! Kig en gang på hvor man kan bladre i forskellige podcast om alt mellem himmel og jord. 2) For at kunne håndtere disse mp3-filer, som ligger overalt på internettet, på en struktureret måde, har man defineret en XML-struktur, kaldet RSS-feed, som bruges til at samle alle episoder, som har med et bestemt podcast at gøre. Det svarer til alle udsendelserne i et radioprogram. RSS-feed et bruger man også til at beskrive sit podcast og dets enkelte episoder, samt at angive udgivelsesdatoer og andre relevante oplysninger, så man nemt kan finde ud af, om der er kommet nye episoder i sine ynglings podcast. 3) Med eksistensen af RSS-feeds til podcast kunne podcast-abonneringssoftware udvikles. Dette er hvad der har sikret podcastingen sin enorme udbredelse. Der findes en lang række gratis programmer, som kan hjælpe dig med at udpeje de podcast, som du holder af, og samtidig overføre nye episoder til din mp3-afspiller efterhånden som de bliver lagt ud på internettet. Dette sker automatisk, når først man har udpejet de podcast, man gerne vil følge med i, sådan at ens mp3-afspiller altid indeholder den seneste episode af de podcast man har udpejet. Et eksempel på et podcast-abonneringsprogram er itunes fra Apple, som har integreret de normalt gratis podcast med sin mp3-musik-forretning. Det er dette medie, som OracleEkspert nu er på vej ind i. Jeg mener ikke at mediet er egnet til meget tekniske emner, så det bliver ikke en erstatning for bladet, men jeg tror at podcasting er meget anvendeligt til debat og diskussioner om aktuelle Oracle-relaterede emner. Igennem den danske podcast-portal vil der derfor snart blive lanceret et podcast, hvor nogle engagerede personer hver anden måned vil diskutere, hvad der sker i Oracle-verden. Oplag: kopier Udgives af: pythia Information Kongensvej Frederiksberg Danmark Telefon: Fax: Info@OracleEkspert.dk Web: Ansvarshavende redaktør: marc de Oliveira Marc@OracleEkspert.dk SpørgeJørgen et mogens Nørgaard Mogens@OracleEkspert.dk Bentes Bamsers Bøger: Bente Rosenkrantz-Theil Bente@OracleEkspert.dk Rettigheder: PYTHIA Information ejer alle rettigheder til indholdet af OracleEkspert. Kopiering af bladet i dele eller helhed må kun ske efter skriftligt samtykke fra PYTHIA Information. PYTHIA Information forbeholder sig rettigheder til at offentliggøre og genudgive de trykte artikler, tips mv, samt at tillade bladets læsere at anvende indholdet til såvel personlige som kommercielle formål. PYTHIA Information kan ikke drages til ansvar for eventuelle fejl og mangler i Indholdet af OracleEkspert. Artikler mv stilles tilrådighed uden garanti af nogen art. Pris: Enkeltnummer DKK 300,00 1 års abonnement (6 numre): 1. abonnement dkk 1600,00 Pr ekstra blad dkk 600,00 Annoncer: Annoncer til OracleEkspert skal være PYTHIA Information i hænde senest den 15. i måneden inden bladets udgivelse. Annoncepriser kan findes på: Password: Garbo

3

4 TEKNISK ARTIKEL Af Marc de Oliveira PROBLEMER MED DET OBJEKTORIENTEREDE PARADIGME INDLEDNING I løbet af de seneste fem år er der blevet produceret en lang række udviklingsmetoder, som udspringer af det objektorienterede paradigme, som feks Xtreme Programming, Scrum og andre tiltag under Agilefanen. Jeg tror at en vigtig grund til den objektorienterede tankegangs popularitet hænger sammen med, at den er meget intuitiv og meget nem at forstå. Der er mange paralleller mellem den objektorienterede tankegang og hjernens måde at opfatte og bearbejde indtryk og viden. Men det er, i mine øjne, en misforståelse at konkludere at metoden er god fordi den er intuitiv, hvilket ellers er en nærliggende og fristende tanke. Lad mig forklare... PROBLEMERNE Netop det intuitive ved den objektorienterede tankegang kan have skylden for en del af de problemer som den medfører. Jeg vil i det følgende gennemgå en stribe problemområder, som jeg ser i den objektorienterede tankegang. PARRALLELLITET Marc de Oliveira er datalog fra Københavns Universitet. Han arbejder som IT-chef på podhead.dk, redaktør på OracleEkspert, Oracle-konsulent og -underviser, samt bestyrelsesmedlem og indlægsholder i ODTUG (Oracle Development Tools User Group). Lad os begynde med analogien omkring den menneskelige hjernes objektorienterede tankegang. Det er helt rigtigt at hjernen ikke gemmer erindringer som lange lister af information af forskellig type, som relationsdatabaser jo gør det vha tabeller. I stedet kan man godt sige at hjernen i højere grad husker individuelle objekter, hvor alle relevante egenskaber er samlet (både data og funktioner) omkring hvert element. Hjernen er dog opbygget fundamentalt forskelligt fra en computer idet alle dele af hjernen er i live hele tiden. Hvis hjernen skal bruge viden om en bestemt bil, som ens forældre havde, da man var barn, vil den del af hjernen, som rummer disse oplysninger selv reagere og gøre opmærksom på sig selv. En computer, derimod, kan have nok så meget lager og en fantastisk kraftig CPU, men den er alligevel nødt til at løbe sine data igennem på mere eller mindre sekventiel vis. Selv en multi-cpu-maskine er nødt til at dele data op i et antal lister, som skal gennemgås sekventielt. Uanset antallet af CPU er, så vil en computers data aldrig selv vågne op og sige Jeg er den røde bil, som dine forældre havde, da du var barn. Og hvad er så konsekvensen ved denne betragtning? Idet computeren arbejder sekventielt er et relationelt system mere egnet end et objektorienteret, da man her strukturerer informationerne i et format, der er optimeret til sekventielle søgninger. Et objektorienteret miljø, hvor alle objekter svæver frit i lange hægtede lister i en simuleret parallel verden, kræver alligevel klodsede sekventielle løkker, der løber listerne igennem, hvilket giver ineffektiv kode og ødelægger illusionen om parallelitet. AT STOPPE NEDARVNING Nedarvning er i mange situationer et ganske logisk og naturligt princip, men det beskriver dårligt hvordan en subklasse kan have færre egenskaber eller metoder end deres tilknyttede superklasser. Feks har en albino de samme egenskaber, som en person på nær øjen-, hår- og hudfarve. Albinoen er en særlig slags person. Dvs at Person er en superklasse til Albino, hvilket i det objektorienterede paradigme betyder at Albino nedarver alle Persons egenskaber, inklusiv øjen-, hår- og hudfarve, selv om netop disse egenskaber ikke har nogen værdi i et Albino-system (hvad det så end er... :-) ). Albino-eksemplet kan virke lidt kunstigt, men når man i IT-systemer arbejder med multiple supertyper af mere eller mindre naturlige faglige eller forretningstekniske begreber, så kommer man nemt til at definere objektklasser, der indeholder flere egenskaber end der reelt bør være. BIBLIOTEKER VS SUPERKLASSER I forlængelse af ovenstående afsnits problem angående supertyper kan man fremhæve at biblioteker netop har såvel superklassernes nedarvende egenskaber, hvor biblioteker kan nedarve funktioner fra andre biblioteker osv, samt evnen til at samle genanvendelig kode. Da der ikke er forventninger om at biblioteker skal repræsentere noget fra den virkelige verden, andet en de genanvendelige dele af et system, kan biblioteker frit struktureres og kombineres efter systemets faktiske behov uden hensyn til om de kommer til at repræsentere et virkeligt objekt eller ej. INDKAPSLING En af de helt centrale begreber i den objektorienterede verden er indkapsling. Det anses for meget vigtigt at objekters egenskaber kun kan tilgås via deres metoder, for at sikre at egenskaberne ikke misbruges af kode, som er placeret udenfor objekterne, som ejer dem. Dette princip betyder at udviklere er nødt til at producere store mængder triviel kode til udførelse af atomare opslag og opdateringer. Disse atomare metoder bliver ofte skabt helt mekanisk, sådan at alle egenskaber kan læses og opdateres, hvilket fuldstændig ophæver indkapslingens værdi. Et ikke-objektorienteret system vil således indeholde meget mindre triviel kode, hvilket gør systemets vigtige routiner mere synlige. 4 Februar 2006 OracleEkspert

5 BRUGERGRÆNSEFLADEINDKAPSLING Objektorienterede folk fremhæver ofte brugergrænsefladeindkapsling som en fordel, idet systemet derved kan fastholde sin brugergrænsflade selv om den underliggende objektmodel ændrer sig. På den måde behøver slutbrugere ikke at blive konfronteret med ændringer, som opstår i systemets indre dele. Dette argument betyder dog samtidigt, at der i objektorienterede systemer er en tendens til at udskyde implementeringen af nødvendige ændringer i systemet. Med en hensigt om at hjælpe brugerne ved at holde fast i deres billede af verden, selv om virkeligheden ændrer sig, gør man sig skyldig i at skabe en falsk illusion om virkeligheden, som kan give følgende to problemer: 1) Brugerønsker, som er logiske i den model som brugerne kender til, kan være meningsløse i den virkelige virkelighed. Dette misforhold mellem de to modeller kan gøre kommunikationen svær mellem brugere og udviklere. 2) Misforholdet mellem de to modeller betyder også at udviklere kan blive tvunget til at implementere funktionalitet, der konflikter med den underliggende (skjulte) objektmodel. Sådanne implementeringer kan være med til at skabe et ustabilt system, som til sidst ikke kan rettes op, men i stedet nødvendiggør en fuldstændig nyudvikling af systemet. Ved i stedet løbende at sikre at brugergrænsefladen afspejler den underliggende datamodel, vil hver ændring godt nok være dyrere at implementere (da brugergrænsefladen også skal opdateres), men man får samtidig de bedste vilkår for kommunikationen mellem brugere og udviklere, og en forbedret sandsynlighed for at nye brugerønsker vil være meningsfulde i forhold til systemet, og at man derfor også på lang sigt fortsat kan tilpasse systemet til de hele tiden skiftende behov. KONTROLOBJEKTER Kontrolobjekter er objekter, som objektorienterede udviklere er nødt til at skabe for at systemet skal hænge sammen. Det er objekter, der ikke rigtig svarer til noget ude i den virkelige verden, men som er nødvendige for at kunne implementere den ønskede funktionalitet. Man bruger også kontrolobjekter til at håndtere kompleks funktionalitet, der involverer data fra flere objekter på en sådan måde, at man ikke kan udpege den rigtige ejer af koden. Jeg synes at tilstedeværelsen af et begreb som kontrolobjekter signalerer at det objektorienterede paradigme egentlig ikke er egnet til løsning af komplekse opgaver. I ekstreme tilfælde vil al vigtig kode være placeret i kunstige kontrolobjekter, mens de virkelige objekter kun indeholder trivielle opslag og opdateringer. MODSTANDSDYGTIGHED OVERFOR ÆNDRINGER En vigtig faktor, når man vælger metode og model, omhandler det resulterende systems modstandsdygtighed overfor fremtidige ændringer. Hvor problematisk vil det efterfølgende blive at implementere ændringer i systemet? Dette afhænger selvfølgelig af mange faktorer, men jeg vil gerne fremhæve en enkelt faktor, som jeg mener i høj grad afspejler forskellen på objektorienterede modeller og ER-modeller. Den objektorienterede metode ligger vægt på at brugernes billede af verden bliver repræsenteret i objektmodellen, sådan at de nemt kan genkende deres eget billede af verden (virksomheden), når de ser det færdige system. Dette lyder umiddelbart, som en oplagt og positiv tilgang til systemudvikling, og den er i høj grad forskellig fra den tidligere strukturerede udvikling, hvor man (godt nok på baggrund af interviews med brugere) forsøger at analysere sig frem til den objektive sandhed om virksomheden. I den strukturerede udvikling kan man sagtens ende med en model, som er meget anderledes end den model, som brugerne opfatter, som deres virkelighed. Det er i denne situation analytikerens opgave at forklare brugerne, hvorfor modellen ser ud som den gør. Dette kan ofte være en svær opgave, som kan virke frustrerende på mange brugere. I den objektorienterede verden skal analytikeren/- udvikleren ikke forsøge at ændre brugerens billede, men blot spørge sig ind til brugerens (subjektive) billede af virkeligheden, og danne modellen ud fra det. Isoleret set betyder denne principforskel mellem de to tilgange, at den strukturerede metode må resultere i systemer med en mere stabil model, da den er resultatet af en søgning efter den objektivt set bedste afspejlning af virksomheden - uanset at den måtte være i konflikt med visse brugeres syn. Den objektorienterede model, derimod, er mere sårbar overfor hvem der er blevet spurgt, hvad nye medarbejderes holdning måtte være, samt risikoen for at nye problemområder eller opgavetyper får brugerne til at ændre holdning til, hvordan de ser virksomheden. SØMLØSE FASEOVERGANGE Det fremhæves tit som en fordel at UML-modeller kan bruges til såvel logiske som fysiske objektmodeller, mens man i den relationelle verden anvender to forskellige syntakser til den logiske datamodel (ER-diagrammer) og den fysiske datamodel (Data-diagrammer). Fordelen ved at have en sømløs faseovergang er at det mindsker risikoen for at miste information mellem de to faser. Men dette har også en pris. Når man anvender samme syntaks i flere faser vil denne nødvendigvis være mere kompleks, og dermed sværere at forstå, end en syntaks, som er rettet mod en bestemt fase i udviklingsforløbet. Selv om man i det objektorienterede paradigme bruger UMLs objektmodeller både i analysefasen og i designfasen, så er det alligevel to forskellige diagrammer, som bruges i de to faser, da ting som feks kontrolobjekter normalt ikke giver mening i analysefasen. Det betyder at problemerne omkring synkronisering af objektmodellerne er meget lig dem, som man har i den relationelle verden. Tilbage står, at ER-diagrammerne har en simplere syntaks end UML-diagrammerne, og derfor er nemmere at forstå for ikke-tekniske deltagere i udviklingsprojektet (brugere, kunder, chefer etc). Dette er en styrke i analysefasen, hvor den primære kommunika- OracleEkspert Februar

6 tion netop sker med disse folk. SPORBARHED Objektmodeller i UML baseres typisk på XML-filer, mens ER-modeller mv fra den strukturerede udvikling gemmes i en relationel databasestruktur (i hvert fald når det gælder de avancerede værktøjer). Der er væsentlig bedre muligheder for at følge og sammenholde enkeltdele, som ligger i en relationsdatabase end hvis de er gemt i en eller flere XML-filer. USE CASE Her følger nogle forskellige betragtninger om anvendeligheden af Use Case til systemudvikling. Use Case - input Use Case handler om at beskrive interaktionen mellem bruger og system, uden stillingtagen til hvordan systemet egentlig opererer. Når man har fokus på at beskrive brugernes vision af interaktionen mellem sig selv og systemet, fjerner man samtidig fokus fra at opdage helt nye og bedre måder at eksekvere virksomhedens aktiviteter. Det er meget typisk, at brugere, der står overfor at skulle beskrive krav til et nyt system, blot beskriver det gamle system eller overfører de manuelle arbejdsgange direkte. I bund og grund handler denne forskel om at man i objektorienteret analyse opfatter brugeren som den, der kender virksomheden bedst, mens man i struktureret analyse hævder at systemanalytikeren er den rette til at gennemskue hvordan en given opgave løses bedst. I struktureret analyse er målet at finde den samlet set bedste model til at løse virksomhedens opgaver uden fokus på at systemet skal afspejle brugernes forventninger. Den bedste model må nødvendigvis komme fra analytikeren, der har sat sig ind i alle dele af systemet, og har hørt alle brugernes holdninger til projektet. Brugerne vil ofte have specifikke interesser inden for deres arbejdsområder, der kan konflikte med det overordnede mål med systemet. Feks kan det ofte være nødvendigt at gøre en eller flere af delprocesserne mere besværlige for at den samlede løsning kan blive mere effektiv. Det er et velkendt problem at man ved at optimere alle delprocesser ikke nødvendigvis kommer frem til den samlet set mest effektive løsning. Det betyder, at der efter en struktureret analyse typisk vil være et større behov for at forklare modellen overfor brugerne end efter en objektorienteret analyse, hvor man jo har modelleret brugernes billede af virkeligheden. Use Case - Komplethed En anden fundamental forskel på objektorienteret og struktureret analyse er at man i den objektorienterede verden arbejder bottom-up, mens man i den strukturerede verden arbejder top-down. Når man arbejder bottom-up, så bliver det samlede resultat lig med summen af alle delprodukterne. Dvs at systemet defineres ved hver brugers beskrivelse af sine delprocesser. At disse til sammen faktisk løser virksomhedens opgaver, skyldes at man har skabt en delprocess for hver opgave, som virksomheden har haft behov for at løse. Men selv om en bottom-up tilgang godt kan løse alle virksomhedens opgaver, så vil den sjældent løse dem på den samlet set bedste måde, da den er en samling af delløsninger i stedet for at være implementationen af en overordnet plan for løsningen af virksomhedens mål. En anden konsekvens ved bottom-up er at det er svært at sikre, at løsningen bliver komplet. Da man ikke arbejder med en overordnet plan over, hvad der skal gøres, så kan en hvilken som helst samling delmål udgøre det færdige system. Modsat kan man med top-down nemt identificere manglende delmål, da disse bevirker at de overordnede mål ikke kan nås. Endnu et problem med bottom-up er at du ikke får identificeret overflødige delmål. Det er netop et af de vigtige formål ved en struktureret analyse, at fjerne alle processer, som ikke hjælper til at løse virksomhedens overordnede mål. Da bottom-up definerer det overordnede mål som summen af delmålene, vil denne metode ikke kunne identificere overflødige processer. Use Case - Skærmlayout Indenfor objektorienteret analyse bruger man desuden Use Case til at definere skærmlayout så tidligt som muligt, for at sikre at det færdige system kommer til at se ud som brugerne forventer. Dette finder jeg problematisk af to grunde: 1) Som tidligere nævnt finder jeg det problematisk at lade de enkelte brugere styre systemudviklingen i så høj grad, som man lægger op til i den objektorienterede analyse, da brugerne ikke nødvendigvis har kendskab til detaljerne omkring, hvad der går forud, og hvad der følger efter deres egen arbejdsproces. Derfor vil de ofte være fokuseret på at optimere deres egne processer uden interesse for om det samlet set giver den bedste løsning. I struktureret analyse fokuserer man på at trække oplysninger ud af brugerne om hvilke problemer, systemet skal hjælpe dem med, helt uden at bede om forslag til hvordan de skal løses - og slet ikke til hvordan skærmbillederne skal se ud. 2) Hvis man tidligt i forløbet begynder at visualisere løsningen, så kan man risikere at skabe modstand blandt brugerne, hvis en god ide til optimering af een process, kommer til at bevirke at en anden process ikke bliver lige så elegant, som det blev aftalt ifm Use Case beskrivelserne. OBJEKTSTATUS Såvel struktureret udvikling som objektorienteret udvikling opererer med status-værdier for hhv entiteter og objekter. Statusværdierne skal beskrive hvert elements position i sit livsforløb. Feks kan et Udlån på et bibliotek have status Igangværende, mens en bog er udlånt, og være Afleveret, når bogen er returneret. I det objektorienterede paradigme er det dog et krav at hvert objekt med en livscyklus har en sådan statusattribut. Umiddelbart lyder det som et fornuftigt krav, der sikrer en ensartet håndtering af objekternes livscyklus, og et krav, som tilegner hvert objekt en selvstændig status uafhængigt af alle andre objekter. Men det kan nemt komme til at resultere i redundans, og dermed inkonsistens i datamodellen. 6 Februar 2006 OracleEkspert

7 I ovenstående eksempel om udlån findes også et Bog -objekt, som kan have en pris, et eksemplarnummer osv. Bogen har også en livscyklus, som inkluderer status som På hylde, Udlånt, Til reperation, Kasseret osv. Bog -objektet kan tildeles status Udlånt mange gange i sit livsforløb, mens et nyt Udlån -objekt oprettes ved hvert udlån af en bog. Udlån -objektet registrerer hvilken bog, som blev udlånt, hvem låneren var, hvornår bogen blev udlånt og hvornår den blev afleveret igen. Det er således et helt andet objekt end Bog -objektet. I det tilfælde hvor Udlån -objektet sættes til Igangværende, når en bog bliver udlånt skal Bog - objektet samtidig have sin status ændret til Udlånt. Disse to værdier repræsenterer den samme situation i den virkelige verden, men ved at registrere det to steder, skabes den tekniske mulighed for at: eller Bog = På hylde og Udlån = Igangværende Bog = Udlånt og Udlån = Afleveret Hvilket ikke giver mening. Hvordan kan bogen være på hylden, mens den er udlånt? ANALOGI MED LEGO-KLODSER Det fremføres ofte som argument for at udføre objektorienteret udvikling, at de udviklede objekter efterfølgende kan genbruges i andre sammenhænge, som Lego-klodser, så man slipper for at skulle genopfinde hjulet. Men denne analogi har et fundamentalt problem. Hvis man virkelig skulle se på et komplekst objekt som var det en Lego-klods, så er der i hvert fald ikke tale om de gode gamle murstensagtige klodser med otte felter, som vi husker fra vores barndom, og som nemt kan passe ind næsten hvor som helst. I stedet vil det svare til en enorm og uhyre kompleks klods, som forsøger at tage højde for alle de sammenhænge, som den evt kunne blive anvendt i. Alternativet er at nøjes med at kode den nødvendige funktionalitet så simpelt som overhovedet muligt. Dette vil dels forøge kodens stabilitet, men også forsimple muligheden for at lave fremtidige ændringer, når det bliver nødvendigt, da det er nemmere at vedligeholde en simpel rutine end en kompleks en. KONKLUSSION Selv om jeg her har fremhævet mange problemområder relateret til det objektorienterede paradigme, så er det ikke min hensigt at afvise paradigmet. Der kan være mange grunde til at det, trods disse problemområder, alligevel kan være en god ide at bruge objektorienterede metoder. Min konklussion sigter derfor i to retninger: 1) Hvis du arbejder i et objektorienteret miljø, så vil kendskab til de problemområder, som jeg her har nævnt, kunne hjælpe dig til at styre bedre gennem dine projekter. 2) Hvis du ikke arbejder i et objektorienteret miljø, så vil mine betragtninger kunne bruges til at give dig et balanceret syn på fordele og ulemper ved de to tilgange til systemudvikling, når du står overfor beslutningen om eventuelt at skifte paradigme. God fornøjelse! Alle kommentarer er selvfølgelig velkomne - både hvis du er enig eller uenig. Skriv til mig på Marc@PythiaInformation.com. Udnytter I Designer optimalt? Få udført et 1-dags eftersyn af jeres anvendelse af Designer. Eftersynet konkluderes med en statusrapport med forslag til bedre udnyttelse af Designers muligheder. Følgende områder vil blive analyseret: - Metode - Konsistens - Genbrug - Preferencer - Automatik - Dokumentation - Sikkerhed - Workarea management - Ingen over Pris for et 1-dags Designer-eftersyn, inkl statusrapport: DKK Ring til eller læs mere på af siden ved Ingen - OracleEkspert Februar

8 ORACLE ekspert Indlægsholdere: - Frist: 27. marts - Tilmelding: Konferencen: - Tekniske indlæg - Ekspertpaneler - Netværk - Fuld forplejning Tidspunkt: august Kl 9:00-16:00 Deltagere: Inden 15. april: - Alm pris: Abonnenter: Efter 15. april: - Alm pris: Abonnenter: Sted: - I København... Detaljer følger senere Hvis du har noget på hjertet, så har du her muligheden for at præsentere det for dine danske databasekollegaer. Send et forslag til et indlæg via kontaktsiden på: inden den 27. marts. Alle indlægsholdere får betalt deres konferencedeltagelse, 20 point på deres OE Certificeringskonto (+10 point for artiklen), en amerikansk sølvdollar (2006) samt chancen for at vinde årets OracleEkspert-pris.

9 2006 Hvor bliver det i år? Send dit forslag inden 15. marts til: Redaktionen@OracleEkspert.dk Alle forslag deltager i lodtrækning om 1000 kr i rabat på konferenceregistreringen 2005 Søpavillonen 2004 Trekroner

10 SPØRGEJØRGEN ET Af Mogens Nørgaard HVAD VI SYNES UDVIKLERE SKAL VIDE... Eller: Det er altid applikationen versus Alle performance-problemer starter i Design-fasen. Det er egentlig ganske utroligt så mange af os i Oracle-communitiet i Danmark (og resten af Verden), der går rundt og skyder skylden på alle de andre. Som regel er DBA-typerne dog værre end udviklertyperne. Det er jo helt utroligt så meget grin vi har gjort med udviklerne gennem tiderne. Som om vi var bedre eller klogere end dem. Brugerne er dumme, udviklerne er dumme, producenterne er dumme, cheferne er dumme, og så er der heldigvis os database-centriske typer, der holder sammen på universets bestanddele. Det gør vi nok ikke, men det kan være, at vi ved mere om, hvordan en database virker, mens udviklerne ved % mere end os om, hvordan en applikation skal se ud, og hvad brugerne rent faktisk har brug for. Tag nu SAP. Deres holdning er, at det ALTID er applikationen, eller at man kan bruge KIWI (Kill It With Iron). Det tror pokker, når alle kolonner er af typen CHAR og de har et mellemlag, der oversætter denne CHAR til NUMBER, DATE eller noget andet. Alt sammen i den hellige database-portabilitets navn. Det er jo lige til at flytte over på SQL Server, så. Og det må man jo give dem ret i. Det kan de altså. Danfoss transition fra Oracle til SQL Server var måske ikke nem eller billig, men den virkede. Måske takket være laveste fællesnævner-filosofien :-). Virker den måde at tænke på? Mjah. Kan det bringes til at virke? Joeh. Kan vi lide det? Njah. Jeg opdeler problemer i følgende kategorier: - Performance - Tilgængelighed - Funktionalitet - Sikkerhed - Politik Når vi database-typer taler om de elendige, de arme, de dumme, de blinde og de forhutlede udviklere tænker vi vel normalt på performance-problemer a la dem, der kan opstå i en SAP-lignende situation. Så lad os overveje, hvad vi synes udviklerne skal vide om performance. De skal vide, at det er tiden, der betyder noget. Det ved de i øvrigt ofte bedre end database-typerne gør, for de har levet med slutbrugernes reaktioner på en mere direkte facon. De skal vide, at hvis noget går for langsomt kan man ikke altid købe mere isenkram. Der er situationer, hvor selv meget dyrt udstyr ville slide sig forgæves ihjel. De skal kunne lave en ordentlig trace (helst level 8 eller 12) i stedet for alt det der sludder med diverse tools, der alligevel ikke kan vise, hvor tiden går hen. Øhm, men vi skal på den anden side også lade dem få adgang til trace-data, dvs. sætte en enkelt udokumenteret parameter... Eller bruge Torben Holms Trace File Repository. De skal forstå at en database laver IO og serialiserer, og at for meget af begge dele ikke er godt. De skal vide, at batch-ting kan lamme en CPU uanset hvor kraftig den er, og at blandingen af batch og online er farlig, nu på femte tiår. De skal vide, at alle performance-problemer opstår i design-fasen (sagt af Dave Ensor for mange år siden). De skal acceptere, at det som regel er i applikationen der skal rettes (det siger alle DBA erne jo også). Øh, vent lige lidt. Det kan jo ikke på samme tid være ALTID database-designet og ALTID applikationen, der er skyld i performance-problemerne, kan det? Hey, RedaktørMarc du er sådan en Designer-nørd og lettere flippet udvikler-kaj hvad siger du til det? Hvor er det, at problemerne opstår i dit liv (altså den del, der har med Oracle at gøre)? Hej MiracleMogens. Oppe fra udviklerstalden oplever jeg følgende: Dygtige udviklere kan godt lave et godt design, og generelt koder de forholdsvis effektiv kode (ift hvad der i den aktuelle uge anses for at være effektiv kode!). Her opstår dog et par udfordringer: 1) Koden lever så længe, at noget, der kørte fint pludselig kan blive ineffektivt. Feks når der installeres en ny version af databasen, der skiftes fra regelbaseret til kostbaseret, etc. 2) Udviklerne har også en interesse i at koden er forholdsvis nem at læse og vedligeholde. Dette kan resultere i at man som udvikler i visse situationer ikke nødvendigvis vælger den mest effektive SQL. 3) Udviklere tilstræber som udgangspunkt at deres kode genbruges så meget som muligt. I den forbindelse er man fokuseret på at funktionaliteten vil fungere efter hensigten uanset hvilken sammenhæng koden anvendes i. Når man skriver koden, er man kun opmærksom på de anvendelsesmåder, som systemet aktuelt skal bruge den i. Når koden efterfølgende bilver kaldt i helt nye sammenhænge, kan det vise sig, at den ikke er effektiv i den nye kontekst. Dette vil normalt ikke blive opdaget før der opstår en performance-krise. Min pointe er at selv om ineffektiv kode i 90% af tilfældene er skyld i systemers performance-problemer, så behøver det ikke at skyldes, at udvikleren er et fjols. Når problemerne så opstår ude hos brugerne, kan det ofte give anledning til en del mudderkastning mellem udviklere og DBA ere indtil kilden til problemet er identificeret. Jeg ser det optimale samarbejde mellem udviklere og DBA ere, i en rollefordeling, hvor DBA erne via trace mv får identificeret de databasekald, som giver problemer, mens udviklerne påtager sig opgaven med at få rettet koden, så den ikke længere skaber de samme problemer. Og så skal erfaringerne omkring årsag og løsning selvfølgelig kommunikeres ud til hele IT-organisationen, så problemet kan undgås fremover. I forhold til de forventinger til udviklere du her har 10 Februar 2006 OracleEkspert

11 angivet, vil jeg mene at du nok vil få svært ved at få en udvikler til at arbejde intensivt med trace og databaseparametre. Dette er typisk noget en udvikler vil forvente at DBA erne lige kan gøre - også selv om det viser sig, at problemet kom fra udviklernes kode. Tilbage til de HELT uskyldige DBA er: Det er jo ikke deres skyld. Det er alle de andres. Det er jo enten designet eller applikationen. I m only the piano player. Her kunne man måske forestille sig, at der var lidt større viden om, hvordan man egentlig tolker det meget database-centriske output fra tracefilerne og tkprof og Hotsos profileren og hvad har vi. Dér burde vi jo være bedre til at oversætte alle de underlige ord og betegnelser, så udviklerne kunne forstå dem. Ved vi nu også alle sammen de ting, jeg nævnte før? Og hvis de ved dem, kan og vil de så videreformidle det til de stakkels udviklere? Jeg synes ofte ikke det er tilfældet. Jeg ved ikke hvorfor. Yo, Marc hvad er dit indtryk fra dine mange år i store bikse, hvor du har skullet holde DBA- og System Admin-typerne ud? Er de dygtige? Er de flinke? Som nævnt ovenfor, så forventer jeg som udvikler at DBA erne smider alt hvad de har i hænderne og starter alle deres uforståelige hokus-pokus analyseværktøjer op for at identificere, hvad der er kilden til problemet :-) - selv om der er 90% chance for at problemet skyldes en udvikler. Og her oplever jeg ofte netop det, som du nævner. DBA erne ved, at det ikke er dem, som har gjort noget forkert, og læner sig derfor tilbage med en kommentar om at det er en af vores egne SQL er, der er problemet, og at vi må gå op og køre en trace for at finde ud af, hvad vi har gjort forkert. Det ville være dejligt, hvis dialogen mellen udviklere og DBA ere kunne være mere imødekommende. Jeg er bange for at vi i mange år har levet i en opdelt verden, hvor dialogen med DBA ernes serverrums-ghetto har været alt for dårlig. Det kan være, at vi har brug for en SQL ens Muhammed-tegninger-krise, for at få sparket en dialog i gang! :-) Den bedste mand til at lave interfacet mellem DBA ere og udviklere er Tom Kyte. Hans bøger er en perfekt blanding af de to verdener, og hans website AskTom er fyldt med spørgsmål i den retning. Alle disse pæne ord om Tom Kyte siger jeg bare fordi han har givet mig et FEDT batteri, som man kan have ved siden af sig når man flyver lange flyveture. Det rækker til otte timers brug, er rimeligt fladt og lille, og vejer ikke alverden. Så jeg sidder i Lufthansa LH-446 fra Frankfurt til Denver og skriver dette på vej til Rocky Mountain Oracle User Group Training Days (RMOUG TD), og har adgang til internettet og alt det fede. Jeg sidder i solskin i 10 km højde, og jeg kan se ud over det hele, og jeg synes ikke det bliver bedre med hensyn til applikations-design og udformning. Sådan har det måske egenlig været i 42 år. Sådan er det nok også i de næste 42 år. Vi DBA-Kaj er får da ikke lavet udviklerne om, ligeså lidt som de får lavet os om. Det er to forskellige verdener, og når vi ikke har kunnet merge dem endnu, så kommer vi nok heller ikke til det. Skal vi så blive ved med at være frustrerede dag ud og dag ind, fordi vi synes de andre er nogle fjollehoveder?!? Jeg synes vi alle sammen bare skulle acceptere, at sådan er det nu engang, og at der er masser af arbejde til alle i mange år endnu. Så kan vi sænke blodtrykket og hygge os sammen og drikke øl. Hvad så, Marc var det dét jeg skulle sige til læserne? Jeg er enig i at vi skal acceptere, at der er tale om to verdener, som man ikke skal forsøge at merge. Men der er generelt et stort behov for at få koordineret samarbejdet. Disse to verdener bør ikke leve så isoleret fra hinanden, som de ofte gør.... og du har helt sikkert ret i at mere øl kan være en vigtig faktor, når forholdene skal forbedres! Nå, men her til slut får I lige et citat fra OakTable-medlemmet Jeff Needham, som jeg lige har modtaget som reaktion på at han og jeg har diskuteret alt muligt i Denver i de seneste par dage: "An alternative definition of Oracle: An aggregator of dynamic, non-linear resource consumption." - Jeff Needham OracleEkspert Februar

12 NYHEDER Norsk Politi vælger Oracle Norsk politi har indgået aftale om køb af software og databaselicenser for 10 mill fra Oracle Norge Oracle opkøber Sleepycat Software Oracle har opkøbt det californiske Sleepycat Software, som sælger udviklingsværktøjer til opensource-databaser. Deres hovedprodukt er Berkley DB. Oracle har ikke sagt, hvad opkøbet har kostet Oracle opkøber Hotsib AB Oracle har opkøbt svenske Hotsib AB, som sælger SIP/J2EE application servere til store bredbånd og 3G/IMS netværk. Oracle har ikke oplyst prisen Oracle vil opkøbe open-source firmaer Oracle er interesseret i at at opkøbe mindst tre open-source firmaer: 1) JBoss, der producerer middleware, 2) Zend, der har udviklet web-udviklingssproget PHP, og 3) Sleepycat Software, der udvikler software til open-source databaser Oracle fyrer 1000 medarbejdere Som følge af opkøbet af Siebel, vil Oracle fyre 1000 medarbejdere, for at fjerne overflødige stillinger. Siebel havde 4700 medarbejdere, da de blev overtaget af Oracle Oracle vinder sag om "brugte" licenser Oracle vandt sagen mod selskabet usedsoft GmbH ved en tysk domstol. Oracle hævdede at usedsoft GmbH krænkede Oracles licenser ved at handle med "brugte" licenser Larry Ellison advaret om at nedsætte personligt forbrug I perioden blev Larry Ellison talrige gange advaret om at nedsætte sit personlige forbrug, af sin personlige financielle rådgiver Phillip Simon. Offentliggjorte s afslører at Phillip Simon advarede at Larry Ellison kunne løbe ind i en financiel krise i 2002, hvis han ikke fik betalt af på sin personlige gæld på USD 1 mia, fik begrænset sit personlige forbrug på hundreder af millioner dollars og fik spredt sin investering i Oracle-aktier. Larry Ellison brugte på det tidspunkt USD 20 mill om året, brugte USD 25 mill på en villa i Japan, USD 80 mill (over tre år) på America's Cup og USD 194 mill (over tre år) på en ny yacht Siebel-aktionærer opkøb accepterer Siebels aktionærer stemte for Oracles overtagelse af deres selskab, så nu bør opkøbet af Siebel for USD 5,85 mia snart kunne afsluttes Gartner kritiserer Oracle-sikkerhed På baggrund af Oracles seneste security patch har Gartner meldt ud at de ikke længere kan opfatte Oracle som en sikker platform. Oracle-kunder anbefales at skynde sig med at sikre deres Oraclesystemer med eksterne firewalls og adgangskontrol. Patchen indeholdt lukninger af 82 sikkerhedshuller, hvilket Gartner anser for at være alt for mange, da man ikke kan regne med at alle kunder kan følge med i de kvartalsopgraderinger, som Oracle sender ud. Desuden patches kun de supporterede versioner af Oracles produkter Oracle Fusion holder tidsplan Charles Phillips udtalte på et pressemøde i San Francisco at Oracles Fusion-planer holder tidsplanen. En komplet Fusion Application Suite skulle se dagens lys i Februar 2006 OracleEkspert

13

14

15

16 TEKNISK ARTIKEL Af Martin Jensen FLERE MV PÅ SAMME BASIS-TABEL INDLEDNING Før Materialized Views i Oracle8i blev kaldt Materialized Views hed de Snapshots, hvilket man sjovt nok fortsat kan se i 10g i en gammeldags export-fil. Disse objekter kan bl.a. anvendes til at implementere en form for replikation af en table (basis) til en eller flere snapshots på andre databaser normalt kaldet poor-man-replication i modsætning til egentlig master-to-master-replikation. Denne artikel søger at beskrive nogle af fællerne ved denne type snapshot -anvendelse af Materialized Views. Alle eksempler er afviklet på en Oracle kerne version Lad os starte med at sætte et test-system op. På min database opretter vi en master tabel, som skal være vores basis tabel for 2 delvise kopier af denne tabel, simuleret på hver sin database. Master tabellen er her en opskalering af vores gode gamle emp tabel med en faktor , så den kommer til at rumme 1,4 milioner rækker. create table Master_tab ( empno number not null, sal number not null, job varchar2(12) not null, deptno number not null, hiredate date not null)) ; insert /*+APPEND */ into master_tab ( empno, sal, job, deptno, hiredate) select empno+t.column_value* empno, sal, job, deptno, hiredate+mod( t.column_value, 1000 ) hiredate from scott.emp, table( system.counter( 1, ) ) t; commit; create unique index master_pk on Master_tab( empno )) compute statistics; alter table Master_tab add constraint master_pk primary key ( empno ); execute DBMS_STATS.GATHER_TABLE_STATS( null, MASTER_TAB, - estimate_percent => 100, - method_opt => FOR ALL INDEXED COLUMNS size 254 ); Lad os lige checke fordelingen af rækker på de forskellige departments. Og bemærk i denne forbindelse at vi jo ikke kan forvente at få listen sorteret, med mindre vi med en order by anmoder om det. Det er i øvrigt en af overraskelserne ved 10gR2, for her leverer group by ikke længere automatisk en sortering implicit hver gang! select deptno, count(*) from master_tab group by deptno order by deptno; Oracle Consulting. Martin har siden 1982 arbejdet med bl.a. Oracle s databasekerne, samt med forskellige aspekter af systemdesign og itarkitektur. implicit er tabellens primærnøgle, der refererer til basis tabellen. create materialized view log on master_tab with sequence, ( deptno ) including new values; Nu har jeg ikke så mange databaser på min PC, så jeg opretter 2 database links tilbage til den samme database, med navnene laptop_link_1 og laptop_- link_2, for at simulere at 2 forskellige databaser skal have 2 lidt forskellige materialized views fra master_tab tabellen: create public database link laptop_link_1 connect to system identified by <passwd> using O101 ; create public database link laptop_link_2 connect to system identified by <passwd> using O101 ; Lad os så fra laptop_1 oprette et materialized view (local_tab_laptop_1), der skal rumme alle rækker fra master tabellen fra department 20. Bemærk at dette kanoniske materialized view arver primær-nøgle definitionen fra master tabellen. create materialized view local_tab_laptop_1 build immediate refresh fast on demand as select empno, sal, job, deptno, hiredate from master_tab@laptop_link_1 where deptno = 20; execute DBMS_STATS.GATHER_TABLE_STATS( null, - LOCAL_TAB_LAPTOP_1, estimate_percent => 100, - method_opt => FOR ALL INDEXED COLUMNS size 254 ); select deptno, count(*) from local_tab_laptop_1 group by deptno order by deptno; DEPTNO COUNT(*) Så er det god latin at spørge database kernen om den også synes at vores materialized view virkeligt er fastrefreshable det ses således: execute dbms_mview.explain_mview( LOCAL_TAB_LAPTOP_1 ); select capability_name, possible, related_text, msgtxt from MV_CAPABILITIES_TABLE where mvname = LOCAL_TAB_LAPTOP_1 order by statement_id; Lad os på samme måde fra laptop 2, oprette et tilsvarende materialize view, denne gang med rækker fra vores master tabel fra department 10: create materialized view local_tab_laptop_2 build immediate refresh fast on demand as select empno, sal, job, deptno, hiredate from master_tab@laptop_link_2 where deptno = 10; execute DBMS_STATS.GATHER_TABLE_STATS( null, - LOCAL_TAB_LAPTOP_2, estimate_percent => 100, - method_opt => FOR ALL INDEXED COLUMNS size 254 ); DEPTNO COUNT(*) Nu skal tabellen master_tab jo danne rammen for vores materialized views, som skal være fast-refreshable, så vi opretter en materielized-view-log på tabellen master_tab for at give Oracle kernen et sted at samle alle ændringer op. Bemærk at sequence er anvendt for at refresh mekanismen kan holde styr på DML rækkerfølgen. Including new values er anvendt for at lade en updatering gemme både de gamle og nye værdier i materialized-view-loggen; samt at det select deptno, count(*) from local_tab_laptop_2 group by deptno order by deptno; DEPTNO COUNT(*) Nu kan vi jo på master basen indsætte rækker i master_tab tabeller her rækker: 16 Februar 2006 OracleEkspert

17 insert into master_tab (empno,sal,job,deptno,hiredate) select empno+t.column_value* empno, sal, job, deptno, hiredate+mod( t.column_value,1000 ) hiredate from scott.emp, table( system.counter(100001,1000) ) t; commit; select deptno, count(*) from master_tab group by deptno order by deptno; DEPTNO COUNT(*) Hvis man nu ser efter i materialized-view-log tabellen ( MLOG$_MASTER_TAB ), finder man netop rækker med en type I for insert. Så når vi nu fra laptop 1 foretager en fast-refresh, skal de 5000 nye rækker fra department 20 kopieres over; og tilsvarende skal en fast-refresh fra laptop 2 flytte de 3000 rækker over fra department 10: execute dbms_mview.refresh( LOCAL_TAB_LAPTOP_1, F ); select deptno, count(*) from local_tab_laptop_1 group by deptno order by deptno; DEPTNO COUNT(*) execute dbms_mview.refresh( LOCAL_TAB_LAPTOP_2, F ); select deptno, count(*) from local_tab_laptop_2 group by deptno order by deptno; DEPTNO COUNT(*) Bemærk nu at vores materialized-view-log nu igen er tom, for nu har alle vores registrerede materialized views, der er baseret på master_tab tabellen (to styks) anvendt alle informationer fra loggen. Nu ændrer vi rækker i master_tab tabellen og flytter alle managers fra department 20 til 10 herved kommer der rækker i materialized-viewloggen, fordi vi har anmodet om både at få de gamle og nye værdier: update master_tab set deptno = 10 where (deptno = 20) and (job = MANAGER ); commit; execute dbms_mview.refresh( LOCAL_TAB_LAPTOP_1, F ); select deptno, count(*) from local_tab_laptop_1 group by deptno order by deptno; DEPTNO COUNT(*) execute dbms_mview.refresh( LOCAL_TAB_LAPTOP_2, F ); select deptno, count(*) from local_tab_laptop_2 group by deptno order by deptno; DEPTNO COUNT(*) Det er jo godt nok, men hvad nu hvis der ikke kun er 2 forskellige laptops der skal have en relevant kopi af master databasen, men måske 10 eller 50? Og hvad nu hvis en af disse laptop s glemmer at foretage sin refresh? Ja så vil database kernen på master systemet jo ikke kunne fjerne nogen af de mange rækker i materialize-view-loggen! Men hvordan kan DBA en på master databasen så finde ud af hvilke materialized views på andre databaser der er afhængige af en konkret master-tabel, samt hvilke materialized views der eventuelt mangler at blive refreshed? Ved at se nærmere på følgende noter fra Metalink ( og ), kan følgende select give svaret: select (select owner. mview_site from DBA_REGISTERED_MVIEWS where mview_id = mv.snapid) MV, mv.snaptime last_refreshed, count(*), min(mlog.sequence$$), max(mlog.sequence$$), min(mlog.snaptime$$), max(mlog.snaptime$$) from mlog$_master_tab mlog, SYS.SLOG$ mv where mlog.snaptime$$ > mv.snaptime and mv.master = MASTER_TAB group by mv.snapid, mv.snaptime order by mv.snapid, mv.snaptime; Og når så de sidste materialized views er blevet refreshet, er det sikkert relevant at skrumpe tabellen bag vores materialized-view-log, således at High-Water- Mark igen kommer ned og sikrer at full table-scans til refresh ikke skal læse mange tomme blokke. Hertil anvendes shrink på Oracle10g eller alter table move online samt index rebuild på Oracle9i. select count(*) from MLOG$_MASTER_TAB; COUNT(*) select deptno, count(*) from master_tab group by deptno order by deptno; DEPTNO COUNT(*) Så når de to materialized views nu refreshes skal de rigtige rækker henholdsvis fjernes og indsættes i de lokale tabeller, for a matche ændringerne i master tabellen; og først derefter kan rækkerne i materializeview-loggen fjernes: OracleEkspert Februar

18 Køb den komplette Oraclerne-samling på 16 sider med alle de strips, som har været trykt i OracleEkspert siden bladet udkom i august Tegningerne er alle lavet af Jesper Dyjak. Pris: 60 kr. Bestilling:salg@OracleEkspert.dk

19 ER DU ENIG? Påstanden som blev fremlagt i OracleEkspert nr 33 lød: Oracle-brugergrupperne spiller en vigtig rolle Opinion: 4.25 (på en skala fra 1-5, hvor 1 betyder helt uenig og 5 betyder helt enig ) OE34 Vinder: Stig Robertsen, NNIT A/S Sponsor søges Hvis dit selskab er interesseret i at blive sponsor, ring Jeg bestyrer denne lille sektion, hvor jeg i hvert nummer af OracleEkspert diskuterer et emne, som Ialle gerne må give mig jeres mening om ved at afgive jeres stemme på (under menupunktet Meningsmålingen). Der uddeles en præmie for en af de mest interessante kommentarer. Ideer til spørgsmål, som det kunne være spændende at høre andres mening om er velkomne til Marc@OracleEkspert.dk. Deltagelsen i månedens meningsmåling bekræfter, hvad vi der har med den danske Oracle-brugergruppe at gøre også oplever. Der er alt for få engagerede personer, men dem, som interesserer sig for brugergruppen finder den meget vigtig. Lad mig derfor indledningsvis opfordre alle til straks at tilmelde sig den danske Oracle-brugergruppe på og evt gå aktivt ind og skabe nogle aktiviteter. Oracle Danmark er meget imødekommende med at stille medarbejdere og lokaler tilrådighed, når det er nødvendigt. Hvis du har med udvikling at gøre kunne du også vælge at tilmelde dig maillisten for web og modelbaseret udvikling ved at sende en mail uden indhold til: desweb-subscribe@pythiainformation.com. Sidste møde handlede om XE-databasen og HTMLDB (som nu hedder Oracle Application Express). De bedste brugergrupper kan formidle Oracle-erfaringer på en helt anden troværdig måde end Oracle selv samt konsulent- og uddannelseshuse, som skal drive en forretning. Hvis brugergrupperne formår at holde sig uafhængige af Oracle, vinder de meget troværdighed. Brugergrupper som UKOUG, IOUG og AOUG har svært ved at skille sig ud fra Oracle, mens ODTUG fremstår som en af de mest uafhængige brugergrupper. Stig Robertsen fra NNIT A/S fremhæver måske de største værdier ved brugergrupperne: Brugergrupperne er rimeligt uafhængige af Oracle, objektive og kritiske. Han mener også, at de i visse tilfælde kan fungere som pressionsgruppe overfor Oracle. Henrik Verup fra Sigma Business Intellingence A/S er dog også opmærksom på brugergruppernes aquiles-hæl: Brugergrupper er en god ide og de kunne spille en rolle! Men bruges de ikke, dør de. Han mener at decideret markedsføring kan være nødvendig: Brugergruppe skal helst køres og styres af brugerne selv [...] Som konsulent møder jeg mange kunder der end ikke aner, at der findes brugergrupper, [...] Måske brugergrupperne skulle "investere" i lidt reklame? Søger man f.eks. på er der sørgeligt lidt at hente (læs ingenting). På.com kan man se fine (men forældede) lister. Af Marc de Oliveira MENINGSMÅLINGEN Påstanden til meningsmålingen i OracleEkspert nummer 35 lyder: Podcasting et godt medie til Oracle-stof Podcasting er på vej frem overalt. Feks er DR for tiden nok de mest aggressive podcastere i Danmark. Men er mediet også egnet til Oracle-stof? Kan man formidle teknisk stof uden brug af visuelle medier? Eller findes der andet Oraclestof, som det ville være relevant at formidle vha podcast? Skynd dig ind at stemme på Du kan vinde et OracleEkspert-krus OracleEkspert vil gerne have DIN ARTIKEL i bladet! Læs mere på OracleEkspert Februar

20 NØRGÅRD S NEWS Af Mogens Nørgaard LEX DE HAAN, RIP Welcome to the 13th OakTable column in Oracle Scene. I ll talk a bit about Lex de Haan, who died on February 1st, then some about batch/online vs. Oracle pricing models, and finally about Revolutionary IT (RIT). Many of you probably know by now that Lex has moved to /dev/null, aged 51. His presentation at the UKOUG conference in Birmingham was, although he was in great pain, really good, and ex-oracle Development people like Tuomas Pystynen who have studied NULL and 3-valued logic, walked away having learned things again from Lex. He worked for Oracle Education for many years, and started up the Technical Seminar business alone, which is why we ended up working so closely together, and why I visited many countries and taught many classes in the last half of the 90 s. Founding a company called Natural Join in 2004, he reminded us again about his incredible sense of humour. Much more can be read about his life and accomplishments on various blogs and on net. I m writing this a few days before his funeral, and I m pretty sure Lex planned some surprises for his friends there, too. He certainly left us with a riddle, which his oldest daughter and my wife figured out independently of each other: In his last 24 hours with his family he mentioned a number of times, meaning 1st of February, But why did he point it out several times? Well, because he was famous for his knowledge about 3-valued logic (true, false, unknown), and because we always joked about 42 being the answer to Life, the Universe and Everything. 3 times 42 equals 126. He was not very happy with the treatment he got at the hospital, and after having visited him a couple of times I can t really blame him. So when a Dutch magazine had a front page shouting You re Fired (in English), Lex promptly arranged for a picture to be taken where he s sitting in bed, holding the magazine up, and where the machine that regulates his various drips shows 042 on the readout. So I wouldn t be surprised one bit if there is more from him to come. Here s to a very dear friend, a fantastic colleague, an inspiring teacher and a brilliant craftsman, who created the MOTs (Mini OakTables) and OakTable bottle openers. His Oracle SQL book will be maintained and updated by Torben Holm of Miracle. The book he was working on, titled Applied Mathematics for Database Professionals (AM4DP) will be finished by Lex friend Toon and others, and from the reviews done by Cary Millsap and others of Lex opening chapters (and my own reading of them), I know that this book will also be a Very Good Book to Read. BATCH/ONLINE AND ORACLE PRICING MODELS There are situations where you need more CPU s and there are situations where you need more powerful CPU s. For instance, if you re running 42 concurrent batch jobs, it won t help you to upgrade your two warm Xeon s or Itanics to two cool Opteron s. The Magic of 2, as Cary Millsap called his article about the number of concurrent batch jobs, is a bit old, and not quite complete. Therefore, he had prepared some new and much more complete materials on this topic for his recent three-day master class in Copenhagen. If your CPU s are not very busy and you re running more than two batch jobs per CPU, then your real problem is that the jobs are IO-bound, which nobody wants. Interestingly enough, Cary had a table showing number of CPU s versus how busy they should be at most, based on queueing theory algorithms from the Danish guy Erlang. One-CPU-systems should at most be around 50% busy, while the number slowly increased to 80-something percent when we approached CPU systems or bigger. If you have too many concurrent batch jobs running on a system, you can do three things (which I ve talked about before): - Increase number of CPU s (or cores, to be more precise) - Lower concurrency (job queue management) - M2M (Money-to-Miracle i.e. let tuning experts turn all batch jobs into very fast non-batch jobs) in many cases Oracle s license prices could make the third option attractive, but some interesting things have happened recently, including the new per-core pricing models, which does away with Oracle s old idea of one core being equal to one CPU - for a few platforms. A core counts as: 0.75 CPU on Unix 0.50 CPU on Linux and Windows 0.25 CPU on the new 8-way Sun UltraSparc T1 CPU So even if UltraSparc in general is Old School, for some BI/DW environments this T1 could make sense in order to get more, albeit slower, cores/cpu s than having relatively fewer of the lightning fast Opteron s. The pricing seems attractive in itself. Two cores are of course not as fast as two single-core CPU s, but it still might do the trick on massively batched environments. It s worth a benchmark, I d say. Currently, by the way, there s also a special offer out from Sun about free bundling of Oracle Enterprise Edition licenses if you buy Sun Fire IV/IV+, no matter the number of CPU s in there, before a certain date, and all that. The CPU s in themselves are also currently half price, so Sun is really trying to a) clean the shelves and/or b) get back in the ring. Still, it just might make sense. Apple-to-apple benchmarks done by some lower-half weenies of the Oak Table have established that one dual-core Opteron equals approximately 10 UltraSparc (single-core) CPU s in terms of raw CPU power. 20 Februar 2006 OracleEkspert