August 2003 Nr 19, Årgang 4 ISSN 1600-5147 Pris: kr. 300,00 ex moms www.oracleekspert.dk

August 2003 Nr 19, Årgang 4 ISSN 1600-5147 Pris: kr. 300,00 ex moms www.oracleekspert.dk #19 OUGDK 23 OUGDK Stormøde Næste møde: 3. september kl 15:00 hos Oracle Danmark DBA SIG Næste møde er endnu ikke fastlagt. DesWeb SIG Næste møde: 20. august kl. 13:00 hos Oracle Danmark Developer SIG Næste møde er endnu ikke fastlagt. Data warehouse SIG Næste møde er endnu ikke fastlagt. NYHEDER 13 Oracle fastholder opkøb af PS Oracle vokser hurtigst i Europa Collaboration Suite release 2 US Army chef bliver Oracle SVP Jeffrey Henley åbner NASDAQ Oracle og Yahoo PeopleSoft afviser opkøb Oracle kåret for bedste support Oracle regnskab for Q4 OTN har nu 3 mill medlemmer TRE ÅR - OG EN MASSE VIDEN 2 Marc de Oliveira AUTOMATISK DB ACCOUNT MANAGEMENT?4 Martin Jensen Denne artikel beskriver hvorledes det er muligt at lade ens database(r) arve de relevante accounts og rettigheder fra et bruger-repository. THE PATCH IS THE PITCH 2 6 Mogens Nørgaard Denne artikelserie (det kan jeg vel kalde den, nu hvor jeg skriver den anden udgave i serien) handler om patching og opgraderinger. Jeg har ikke modtaget forslag til andre eller bedre overskrifter, så sådan bliver det. ODTUG-KONFERENCEN I MIAMI BEACH11 Marc de Oliveira I år vendte konferencen tilbage til sine vante omgivelser på et mindre strandhotel med plads til 3000 gæster. Det var tredie gang i ODTUGs historie, at konferencen, hvis stifter er inkarneret vestkystmand, blev afholdt på østkysten. ORACLE KERNEN OG IO? 14 Jørgen Quaade En database's primære opgave er at sikre ens data mod alverdens ulykker. I computere kan det normalt kun gøres ved at skrive alt ned på diskene. Kun der, er ens data så nogenlunde sikret. I denne artikel vil vi se nærmere på den helt overordnede arkitektur af databasen og se på hvordan Oracle instansen bruger diskene. GROANS FRA MOGENS 17 BENTES BØGER 22 Core MySQL a serious developer s guide Ian Fisher+Sue Harper holder indlæg til OUGDK DesWeb SIG møde den 20. august kl 13:00

Leder TRE ÅR - OG EN MASSE VIDEN Marc de Oliveira I dette nummer af OracleEkspert fejres bladets tre års fødselsdag. Derfor vil du kunne finde en fødselsdagsgave på midtersiderne. Det er spillet OracleEkspert Certified Professional, der går ud på at blive OECP-certificeret ved at tage fem OracleEkspert-eksaminer og nå hjem inden de udløber. Denne udgave af OracleEkspert Certified Professional spillet indeholder 50 OECP-spørgsmål fordelt på ti OECP eksamenskort. Der vil i fremtiden løbende inkluderes flere OECP eksamenskort i bladet, for at gøre spillet mere varieret. Til det formål opfordres også du til at indsende forslag til gode OECP-spørgsmål til OECP@OracleEkspert.dk. Men ikke nok med det. Sommervarmen er steget os til hovedet, og vi har derfor også besluttet at opgradere alle abonnementer til vores bedste abonnementtype (OracleEkspert medlemskab) uden meromkostning, uanset hvilken abonnementtype man havde i forvejen. Dvs at alle, der læser dette har adgang til at hente PDF-udgaver af dette og alle tidligere numre af OracleEkspert. For at få adgang til disse, skal man gå til www.oracleekspert.dk og klikke på linket Medlemmer. Man kan komme ind med brugernavnet OEmedlem kombineret med det kodeord, som står nederst på denne side (i det blå felt). De bekymrede, der er glade for den trykte udgave, kan slappe helt af, da vi desuden udvider værdien af OracleEkspert medlemskabet, ved at man nu også får et trykt OracleEkspert blad tilsendt. Og som om det ikke var nok, så sætter vi også abonnementsprisen ned med DKK 200! Grunden til at dette kan lade sig gøre, er at vi samtidig forsimpler administrationen ved at nedlægge de andre abonnementtyper. Dvs, at når de nuværende abonnementer udløber vil man ikke længere kunne vælge mellem Trykt Blad, Elektronisk Blad eller Medlemskab. Herefter vil alle abonnenter have et OracleEkspert Medlemskab, hvor man både får et trykt blad og adgang til alle tidligere numre i PDF-format med mulighed for gratis selv at printe flere blade til alle medarbejdere i ens virksomhed. Dem som gerne vil have mere end eet blad, kan købe tillægsabonnementer for kun DKK 400 pr år. Vi håber, at I vil finde jer til rette med denne nye abonnementform. Den er en vigtig forudsætning for bladets fortsatte eksistens. Grunden til at to nye sponsorer, for nogle måneder, besluttede at støtte Oracle- Ekspert var ikke for at kunne tjene penge på at gøre det (bladet har kørt med underskud siden sin fødsel i august 2000). Nej, grunden var, at de mente, at der var brug for et uafhængigt forum for danskere, der arbejder med Oracle. Fordi viden er vigtig. Ikke bare viden, der kan læses i manualer, men også viden om hvordan andre gør, viden om hvilke politiske vinde, der blæser i Oracle-miljøet osv. ODTUG er netop en sådan stemme i det internationale Oracle-miljø, der formidler mange slags relevant viden blandt Oracle-brugere samtidig med at de holder sig i tæt kontakt med Oracle i et forsøg på også at få tilgodeset brugernes behov, når Oracle tager strategiske beslutninger. OracleEkspert er et nedskalleret forsøg på at skabe den samme slags viden specifikt blandt danskere. Viden, som ifølge ODTUGs missionserklæring, skal gøre deres medlemmer til ledere i deres organisationer. I denne uge var der i USA premiere på filmen Masked and Anonymous med Bob Dylan i hovedrollen. Rygterne siger, at det også er Dylan, der har skrevet manuskriptet under pseudonymet Rene Fontaine. Selv om man ikke kan have ham mistænkt for at interessere sig meget for Oracle, så når han, i rollen som Jack Fate, alligevel at sige disse poetiske ord om behovet for viden: Sometimes it's not enough to know what things mean. Sometimes we have to know what things don't mean as well. - Jack Fate (Bob Dylan) Oplag:....................150 kopier Udgives af:..................pythia Information.......................Kongensvej 3..................2000 Frederiksberg...........................Danmark Telefon:....................26279991 Fax:.......................26199991 Email:.........Info@OracleEkspert.dk Web:..........www.OracleEkspert.dk Ansvarshavende redaktør:......................marc de Oliveira...............Marc@OracleEkspert.dk Betalinger....................Lasse Christensen.............Faktura@OracleEkspert.dk Groans fra Mogens:....................Mogens Nørgaard............Mogens@OracleEkspert.dk Bentes 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): - Medlemskab (inkl blad)...dkk 1600,00 - Pr ekstra blad............dkk 400,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å vores hjemmeside. bdsacdmaa

Du er nu blevet opgraderet til det nye OracleEkspert-medlemskab i resten af abonnementsperioden (læs lederen på side 2 om hvordan du får adgang til de elektroniske udgaver af OracleEkspert) Det nye Medlemskab koster kun 1600 kr pr år (tidl. 1800 kr)... og det består af: OracleEkspert i PDF-format Adgang til alle tidligere numre Bladet er tilgængeligt samtidig med det går i trykken I kan selv udskrive og distribuere bladet til alle medarbejdere i virksomheden PLUS (nyt ift tidligere medlemskab) et trykt eksemplar af OracleEkspert i farver

DBA Teknisk Artikel AUTOMATISK DB ACCOUNT MANAGEMENT? Martin Jensen - Oracle Consulting. Martin har siden 1982 arbejdet med bl.a. Oracle s database-kerne, samt med forskellige aspekter af objektorienteret systemdesign. Flere og flere miljøer forsynes med LDAP repositories, hvor virksomhedens brugere samlet står opført med deres basale privilegier. Det er naturligvis i sig selv en forenkling, da brugerne (og deres privilegier) herfra relativt enkelt kan administreres. Vanskeligere er det at synkronisere disse informationer med de enkelte databasesystemers accounts, der jo kan have en meget forskelligartet opbygning, ligefra systemer hvor hver bruger har sin account, til moderne systemer, hvor brugernes rettigheder styres af VPD og proxi-accounts. Det er normalt ikke simpelt at ændre en applikation til at anvende VPD og proxi-accounts, så spørgsmålet er ofte, hvorledes DBA erne relativt enkelt kan hægte databasesystemer med accounts for de enkelte brugere sammen med centrale bruger repositories. Denne artikel beskriver hvorledes det er muligt at lade ens database(r) arve de relevante accounts og rettigheder fra et bruger-repository. Antag at det centrale bruger-reposity er i stand til at propagere brugerrettighedsændringer ned til databasesystemet i en tabel (lad os sige user_profile i en account user_rep). Og lad os her sige at en profil svarer til en rolle. create table dir_user_profile ( user_id Varchar2( 30 ) primary key, profile_id Varchar2( 30 )); Nu kan vi jo så etablere en trigger på denne tabel for at fange insert, update og delete, således at vi synkront kan afspejle brugerns privilegier fra det centrale system til det lokale. create or replace trigger db_access_change_tg after insert or update or delete on user_profile for each row begin declare l_exist Number; l_user_id Varchar2( 30 ); l_profile_id Varchar2( 30 ); cursor profile_lookup is select count( 1 ) from all_roles where user_name = upper( l_user_id ) and role_name = upper(l_profile_id); begin dbms_output.enable( 900000 ); if deleting or updating then l_user_id := :old.user_id; l_profile_id := :old.profile_id; if l_user_id is not null and l_profile_id is not null then open profile_lookup; fetch profile_lookup into l_exist; close profile_lookup; if l_exist > 0 then db_drop_account( l_user_id, l_profile_id ); else dbms_output.put_line( db_access_change_tg ' '(user,profile) does not exist: ' l_user_id ', ' l_profile_id ); end if; end if; end if; if inserting or updating then l_user_id := :new.user_id; l_profile_id := :new.profile_id; if l_user_id is not null and l_profile_id is not null then open profile_lookup; fetch profile_lookup into l_exist; close profile_lookup; if l_exist = 0 then db_create_account( l_user_id, l_profile_id ); else dbms_output.put_line( db_access_change_tg ' '(user,profile) already exists: ' l_user_id ', ' l_profile_id ); end if; end if; end if; end; end; Så mangler vi vel at implementere de to procedurer db_create_account og db_drop_account. Bemærk at der her anvendes definer s right, samt at procedurerne er autonome for via triggere at kunne committe i basen. Bemærk også at en række centrale accounts bør undtages for administration gennem disse procedurere (eksemplerne viser kun en håndfuld af disse). Sidst men ikke mindst kan disse procedurere jo wrappes for at skjule den egentlige implementering. create or replace procedure dw_create_account ( p_user Varchar2, p_role Varchar2 ) authid definer is sql_txt Varchar2( 400 ); pragma autonomous_transaction; begin declare l_exist Number; begin if upper( p_user ) not in ( 'APPS','DBSNMP','PERFSTAT','SYS','SYSTEM' ) then select count( 1 ) into l_exist from all_users where username = upper( p_user ); if l_exist = 0 then sql_txt := create user ' p_user ' identified by velkommen'; execute immediate sql_txt; end if; sql_txt := 'grant connect to ' p_user; execute immediate sql_txt; sql_txt := 'grant p_rule to ' p_user; execute immediate sql_txt; end if; end; end; create or replace procedure db_drop_account ( p_user Varchar2 ) authid definer is sql_txt Varchar2( 100 ); pragma autonomous_transaction; begin declare l_exist Number; begin if upper( p_user ) not in ( 'APPS','DBSNMP','PERFSTAT','SYS','SYSTEM' ) then select count( 1 ) into l_exist from all_users where username = upper( p_user ); if l_exist > 0 then sql_txt:= 'drop user ' p_user ' cascade'; execute immediate sql_txt; end if; end if; end; end; 4 August 2003 OracleEkspert

Well, databasens brugeraccounts er nu synkroniseret med det centrale bruger repository. Men hvad så med de enkelte accounts passwd, der her som default bliver sat til Velkommen? Det tager vi en anden gang ved at omforme disse accounts til global user accounts. Dit firma kan blive sponsor for OracleEkspert Skriv til: Svar@OracleEkspert.dk Svar Danmarks eneste uafhê ngige Oracle-tidskrift har brug for sponsorer. Har dit firma mulighed for at pâtage sig nogle af flgende opgaver: - Salg af abonnementer - Salg af reklamer - Skaffe alsidige artikler - Nyhedsredigering - Korrektur - Evt andet... SÂ vil vi fremhê ve dit firma som sttter af dansk netvê rk og vidensudveksling gennem et permanent logo pâ bladets forside samt bannerannonce pâ bladets hjemmeside: www.oracleekspert.dk Kontakt venligst redaktionen@oracleekspert.dk eller ring til 26279991 for at diskutere mulighederne for et samarbejde med OracleEkspert. Denne rubrik er åben for alle spørgsmål, forslag og tilkendegivelser om Oracle eller Oracle- Ekspert, hvad enten de er tekniske eller mere strategiske. Indlæg kan godt være anonyme, men redaktionen skal vide, hvem der har skrevet dem. Oracle Danmark Support og Metalink tilbyder, at besvare de tekniske spørgsmål. OracleEkspert August 2003 5

DBA Teknisk Artikel THE PATCH IS THE PITCH 2 Mogens Nørgaard, Miracle A/S Denne artikelserie (det kan jeg vel kalde den, nu hvor jeg skriver den anden udgave i serien) handler om patching og opgraderinger. Jeg har ikke modtaget forslag til andre eller bedre overskrifter, så sådan bliver det. I denne artikel vil jeg komme ind på flg. emner: - Registerering af patches. Også i Apps. - Planned downtime, Oracle, SAP, Shareplex - Ting, der ikke understøttes af Data Guard - Oracle s regressionstests - Case 1: Funktionalitetstest, ingen performancetest - Case 2: Opgradering på fjerde ciffer tog fem timer - Online patches. Findes de? - Rolling upgrades - Baselines. Jeg hader baselines. - Test: Har en patch eller opgradering hjulpet? Hvorfor opgradere overhovedet? Uniras-degraderingen. - Hvad kan man gøre for at sikre større stabilitet? - Oracle s anbefalede metode til opgradering. - Skal man opgradere til 9i? Registrering af Patches Jeg lovede i sidste nummer at skrive lidt om, hvad man egentlig kan gøre for at få overblik over sine patches. Jeg håbede jo også, at én eller flere ville skrive til mig og fortælle mig om gode løsninger. Det er ikke sket. Så jeg må skrive videre efter bedste vidende. Til de store ERP-tingester (Oracle Apps, SAP, etc.) findes der utilities, som kan købes for store beløb, der kan administrere patches. Til Oracle Apps findes der vist to eller tre produkter, og brugerne af dem siger, at de er dyre, men nyttige. De kan ikke alene registrere alle disse herlige bugnumre, mv., men kan også lægge dem på mere eller mindre automatisk i rigtig rækkefølge, så man slipper for en masse manuelt arbejde. For ikke-erp-relaterede databaser er der ikke noget at gøre. Man kan kun manuelt registrere det i regneark. Der findes ingen mekanisme i de nuværende versioner af Oracle til at huske hvilke patches der er lagt på. Det ændrer sig i en senere version, og det er godt. Planned downtime, Oracle, SAP, Shareplex Jeg fik et par henvendelser fra SAP-kunder, som var irriterede over at deres systemer var nede (læs: databasen lukket) så ofte pga alle mulige og umulige SAPpatches (og sikkert også Oracle-patches). Kunne det være rigtigt? Var der ikke en ægte 25/8/370-løsning? Nej der er ikke. Jeg fik mig en snak med en gut fra Oracle Development, som har tilbragt masser af tid med at arbejde sammen med SAP i Waldorf, og hans svar var ganske kort (og karakterisk tysk): No, there s only planned downtime. Jamen, hvad pokker gør så de rigtigt, rigtigt kritiske sites, som bare er NØDT til at være åbne hele tiden, og som bare mister SÅ mange milliarder for hvert minut de er nede? Hvad gør de? They use planned downtime. Men der var med logiske standby-databaser (Data Guard) nu mulighed for at kunne.. Ja, jo, men med sådan nogle er der visse SQL-kommandoer, der ikke er supporteret, indvendte jeg. Det vidste gutten ikke. Men det er præcist de samme begrænsninger, som dem der findes med Quest s Shareplex-produkt: Hvis ikke en SQL-kommando registreres i logfilen, så bliver det meget svært at replikere den over i den anden database. Med Data Guard gør Oracle to ting, som de i mange år har frarådet folk at benytte sig af i forbindelse med Shareplex og andre tilsvarende produkter fra BMC og andre: De kigger direkte i logfilen, og de understøtter derfor ikke alle SQL-kommandoer. Sikke megen FUD (Fear, Uncertainty, Doubt) der er blevet spredt i årenes løb fra Oracle s Marketingsafdeling omkring produkter, der gjorde sådan noget. Indtil de selv gjorde det. Man kan jo lure på, om ikke Shareplex, der har gjort det her i mange år, er mere modent som produkt, end Oracle s eget, helt nye, produkt? Ting, der ikke understøttes med Data Guard Usupporterede datatyper: NCLOB LONG (RAW) BFILE ROWID UROWID user-defined datatypes nested tables object types REFs varrays Usupportede objekter: user defined tables/sequences in SYS schemai tables with unsupported datatypes tables using data segment compression IOT's Skipped SQL: alter database, session, snapshot, snapshot log create controlfile, database, database link pfile from spfile, spfile from pfile schema authorization snapshot, snapshot log table as select from a cluster table drop database link, snapshot, snapshot log explain; lock table; rename set constraints, role, transaction Oracle s regressionstests Tak til en god ven i Oracle, der påpegede, at Oracle 6 August 2003 OracleEkspert

kun foretager regressionstests på de første tre cifre. På de to sidste laves der en hurtig funktionalitetstest. Det er jo forståeligt nok ellers ville patches aldrig komme ud. Men i Case 2 nedenfor gik det galt på fjerde ciffer, og det kan det da sagtens i andre tilfælde. Nu ved I det. Case 1: Funktionalitetstest, ingen performancetest Jeg nævnte kort i sidste nummer af bladet, at en kunde havde brugt et meget stort beløb på at sikre sig, at deres applikationer kunne fungere efter en portning til en anden hardwareplatform. Det kunne de også. Og initielt gik det rigtigt godt med at flytte det hele over det skulle i øvrigt over på et system, der kørte andre ting samtidig. Men pludselig ramte de ind i en rapport, der ikke kunne køre færdig, en masse kompliceret halløj og problemer i 2-3 uger, masser af itars, og alt det vi elsker at hade. Hvordan kunne de have forberedt sig bedre? Hvis Oracle ikke kan lave interoperabilitets-tests deres produkter imellem hvorfor tror man så, at man kan teste, hvordan alle mulige forskellige kombinationer af SQL er vil interagere? Lad mig uddybe, hvad jeg mener: Når en SQL bliver udført kan den enten køre uhindret og lave IO eller CPU eller den kan vente på en ressource, der er optaget af en anden SQL. Den bedste situation er selvfølgelig, at den tid SQL en tager, mest går med CPU og IO, og ikke særligt meget med at vente. Men lige pludselig er den der jo. Det kan være en lås enqueue der tages af én proces og skal bruges af en anden. Det kan oftere (i Oracle) være latches, der blokerer i kortere eller længere tid for andre processer. Latches er låse, der serialiserer adgang til resourcer (ja, der er shared latches i 9i, hvilket hjælper på det, men det er kun nogle få latches, og kun i bestemte situationer). Så hvordan skulle man kunne teste, om det pludselig vil gå galt? Brugsmønstret ændrer sig jo hele tiden, og der gøres meget ud af fra leverandørernes side, at man skal have et dynamisk miljø, der hurtigt kan tilpasses skiftende omstændigheder. Skiftende omstændigheder, nye forretningsregler, ændret brugsmønster det betyder altsammen nye SQL er. Man kan da ikke teste for den slags ting i sit miljø på en måde, der bare nærmer sig noget realistisk. Husk det næste gang Oracle Support eller en smart konsulent siger Det burde jo have været testet før det blev sat i produktion!. Spørg fjolset, hvordan præcist han vil foreslå at man tester før man sætter nye SQL er i produktion? Hvordan Oracle (eller en anden leverandør) gør det? Hvor mange brugere, der skal simuleres? Bliv ved med at spørge venligt og interesseret. Spørg eventuelt, hvor leverandøren har dokumenteret en god måde at gøre det på? Case 2: Opgradering på fjerde ciffer tog fem timer Kunden skulle opgradere fra 9.2.0.1.0 til 9.2.0.3.0, og alt gik efter planen. Alle steps kørte som beskrevet, alt virkede, og der var ingen ventetid mellem de enkelte steps i proceduren. Der var ikke andre på maskinen, så den kørte deruda. Der var ingen fejl undervejs. Men det tog fem timer. Det bør en patch på fjerde ciffer jo ikke gøre, men i dette tilfælde gjorde den. Og når man lægger en patch på Oracle er basen jo lukket. Det skal den være. Hvorfor er der ikke flere kunder, der møder op i det lokale leverandørkontor med en høtyv og et reb? Jeg tror det skyldes, at de fleste laver disse opgraderinger midt om natten, og så er det bare DBA en, SysAdmin en og andre stakler, der bemærker det. Jo, det kan være, at batchjobbene er forsinkede næste morgen, osv. Men det går jo hurtigt over. Denne kunde regnede med, at det kun ville tage ganske kort tid, så de valgte at gøre det en morgen ved 8-tiden, og så var de ikke oppe før ved 13-14-tiden. Hvad skulle de have gjort? Er de fjolser? De kunne have arbejdet midt om natten, som vi efterhånden har vænnet os til. Det koster godt nok en masse penge, en masse kræfter og har den ulempe, at der ikke er så mange andre man kan ringe til, hvis noget går galt. De kunne teste det på et tilsvarende system. Men er det en garanti? Hvad kræves der efterhånden for at have et realistisk testsystem? Jeg aner det ikke. Jeg kender ikke nogen, der har det. Er de fjolser? Nej, tværtimod. De har vel netop gjort noget, som man må forvente de skal være fuldt ud i stand til at gøre med et professionelt IT-system i den dyre klasse. Synes jeg. Online patches. Findes de? Hvis en patch vil berøre SGA en eller Data Dictionary en, så kan den ikke lægges på online. Hvis den ikke berører nogle af disse to ting, så kan den godt, og Oracle har i ganske få tilfælde dokumenteret, at en patch kunne lægges på i online-miljøet. Men der kræves nogle helt andre mekanismer, hvis Oracle skal blive et ligeså professionelt produkt på dette område som f.eks. Rdb, DB2 m.fl. Én af de ting, der faktisk mangler i Oracle s source kode, er et transaktionsbegreb. For at kunne rulle en patch tilbage, eller gøre andre underlige ting, bør man have indbyggede begin/end transaction i koden. Det har man ikke af alle mulige gode grunde. Jeg røber ikke for meget ved at sige, at der heller ikke i den nærmeste fremtid kommer noget, der bare minder om online patch-muligheder i Oracle. Orv, hvor det blev et kæmpeproblem for Oracle Support, da de skulle til at bruge Oracle s egne Appsmoduler og opdagede, at de skulle være nede hele tiden. Faktisk blev supporterne dybt overraskede, og forlangte, at man kunne lægge patches på online, da de sgu da var nødt til at være oppe hele tiden. Det kan de stadig ikke. Det kan resten af Verden heller ikke. Hverken med Apps, SAP eller andre. Jeg synes det er utroligt, at man finder sig i det, betaler masser af penge for, at dyre folk skal gå rundt uden for arbejdstid og lægge patches på, og derefter være OracleEkspert August 2003 7

klar til at tilkalde dyre eksperter midt om natten, hvis noget går galt, eller noget forandrer sig i systemet. Rolling upgrades Rolling upgrades typisk i et cluster med RAC kørende bliver supporteret i fremtiden af Oracle. Det er jeg ikke i tvivl om. Det starter med, at man tillader minor forskelle i versionerne måske ude på fjerde/femte ciffer. Digital har haft rolling upgrades siden de introducerede VMS-clustre. Det her er noget, der godt kan lade sig gøre. MVS-miljøet har det. UNIX-miljøerne har det. Andre databaser har det selv SQL Server er ved at kunne det på en ret snedig måde. Hvordan kan man seriøst tale om 25/8/370, når man hele tiden skal lukke sin database ned? Det hænger da ikke sammen. Baselines jeg hader baselines Hvad kan man gøre? Mange indenfor og udenfor Oracle snakker om baselines. Må jeg være fri! Hvad Pokker er en baseline? En linie noder spillet af en basguitarist? Nå, men mere seriøst: Baselines baserer sig enten på målinger af et system eller målinger af bestemte forretningsfunktioner. Som regel er det system-wide. Men kan man bruge system-målinger? Nej. Kun målinger af applikationer, og det lyder sgu lidt hult, når man får at vide, at man bare skal have baselines. Baselines for systemer findes ikke. Baselines for applikationer findes måske (så har man ret få applikationer, eller de er statiske, eller man har uanede økonomiske resourcer), men som regel er det meget svært at have baselines for sine applikationer bl.a. fordi man jo ligesom godt kan lide at have dynamiske miljøer. Hvis man har dynamiske miljøer kommer der rutinemæssigt nye SQL er til. Enhver ny SQL er potentielt destabiliserende for nogle andre SQL er (Cary s gode eksempel med ting, der bare kører, og ting, der blokerer for hinanden). Hvad kan man gøre? Man kan følge Oracle s anbefalede metode, eller man kan prøve noget smart. Hvorfor siger jeg det? Fordi Oracle s anbefalede metode kort sagt går ud på at følge disse trin: Tag en fuld backup af dit testsystem før du lægger ny software på. Lav en testpatching/opgradering på dit testsystem Test om patchen virker eller om dine applikationer fungerer efter opgraderingen Luk dit produktionssystem Tag en backup (eller tag en online-backup, hvis Oracle siger god for det! normalt vil de anbefale en offline backup, så man kan komme tilbage til et punkt før f.eks. Data Dictionary en blev opdateret) Læg den nye software på produktionssystemet Tag evt en ny backup (det kommer lidt an på, hvor man læser om det, om dette trin anbefales eller ej) Test, om det virker Åbn en Det tager jo tid, det her. Ikke så sært, at mange DBA er/sysadmin s efterhånden længes efter en mere effektiv metode. Ofte springer man selvfølgelig test-systemet over. Man prøver at samle adskillige patches til en stor patch-fest. Man prøver masser af ting. Det synes nærmest håbløst at gøre dette på den rigtige måde. Det synes håbløst at planlægge sig ud af alle muligheder. Alternativet til forudsigelighed er et højt beredskab! Jeg har ikke opskriften på noget rigtigt smart man kan gøre, men det forekommer mig, at det der destabiliserer et system er når en eksekveringsplan for et SQL ændrer sig. Eller når noget bestemt SQL bliver udført mere end normalt. Med MirPlan (gratis, udviklet af Peter Gram m.fl. skriv, hvis I er interesserede) kan man f.eks. en gang i døgnet generere en plan for de vigtigste SQL er (de hyppigste og de tungeste), hashe eksekveringsplanens tekst og sammenligne hast-tallet med hash-tallet fra dagen før. Man kan på samme måde bruge MirPlan til at checke planer før og efter patches og opgraderinger. Det giver én mulighed for at reagere hurtigt, hvis man får at vide, at en plan har ændret sig. Det kan være til det bedre. Det kan være til det dårligere. Men den har ændret sig. Med MirPlan har Gram sat det op, så man får en mail, hvis der sker noget. I Statspack til 9i gemmer Oracle også hash-udtrykket for en SQL, og da man kan gemme Statspack-halløj i et repository, så er det således nemt at se, om noget ændrer sig ved hjælp af en lille trigger eller et job, der kører en gang imellem. Stored Outlines duer ikke, da man jo netop er interesseret i at få udnyttet nye/bedre eksekveringsplaner, og det kan man ikke med Stored Outlines fastfrysning af planen. En monitorering af SQL ernes eksekveringsplaner er det nærmest jeg har kunnet komme en rimelig løsning på problemet om, hvordan man har et meget højere beredskab uden at skulle være enormt bange hver gang man opgraderer eller patcher sit system. 8 August 2003 OracleEkspert

NOTE! ODTUG members save USD 100 of the ODTUG conference registration

ODTUG-KONFERENCEN 2003 I MIAMI BEACH Marc de Oliveira er medlem af ODTUGs bestyrelse og er koordinator for ODTUGs Designer Tools Corner. Han er system analytiker hos NNE, medforfatter til bogen Oracle8 Developer s Guide, forhandler af DesignAssist og redaktør af OracleEkspert. Marc@deOliveira.dk. Back to the beach ODTUG gabte nok over mere end de kunne tygge, da de sidste år placerede konferencen på måske Las Vegas største hotel, Caesars Palace, hvor de 800 deltagere kun udgjorde en ubetydelig del af hotellets gæster. I år vendte konferencen tilbage til sine vante omgivelser på et mindre strandhotel med plads til 3000 gæster. Det var tredie gang i ODTUGs historie, at konferencen, hvis stifter er inkarneret vestkystmand, blev afholdt på østkysten. Dansk rekorddeltagelse Danmark havde den højeste deltagelse blandt lande udenfor Nordamerika. Deltagerne var fordelt på følgende måde: USA 452 (inkl en dansker) Canada 55 Danmark 9 Schweiz 7 (inkl en dansker) England 6 Brazilien 5 Holland 5 3 deltagere: Saudiarabien, Sverige og Tyskland 2 deltagere: Argentina (en talte flydende dansk), Australien, Belgien, Bolivia og Norge 1 deltager Afrika, Bulgarien, Cayman Isl., Mexico, Peru og Østrig Så vi var en lille gruppe på 12 dansktalende deltagere, der holdt lidt sammen og udvekslede synspunkter og erfaringer under konferencen. Det var ikke helt de 30 danske deltagere vi havde i Ft. Lauderdale for et par år siden, men når man tager de svære tider i betragtning, så må man sige, at der var et ganske godt fremmøde fra Danmark. Mange vil sikkert huske Svend-Erik Jensen, der i sin tid sad i Oracle support i Vejle. Han sidder nu i Orlando og er leder af Oracle Support USA. Han havde en del synspunkter, som ikke helt falder i tråd med hvad Mogens Nørgaard får sagt i sine Groans. Indholdet Med over 100 sessioner i otte parallelle spor var det ikke noget problem at finde interessante emner at lytte til. Oracle-værktøjer Blandt højdepunkterne kan nævnes Bill Dwights indlæg om Development Tools Vision & Strategy, hvor han forklarede at JDeveloper vil blive gjort til et modeldrevent udviklingsværktøj, der skal kunne modellere abstrakte elementer som Use Cases og Applikationer. Sue Harper afslørede i sit indlæg Designer 9.0.4 and the future at nogle af de nye ting, de overvejer at udvide Designer med er mulighed for generering af View API er (til opdaterbare views) og CDM RuleFrame. De dynamiske prompter til WSG-moduler er allerede implementeret til snarlig frigivelse. Designer 6i vil blive supporteret frem til den 31. december 2004. David Brown og Ian Fisher fortalte om et nyt lag oven på SCM, som skal hjælpe udviklere med Build and Release management, som også vil kunne bruges til at bygge.jar-pakker til ebusiness Suite patches. Systemet vil blandt andet også kunne bruges til Bug/Issue tracking og Task and project management. Systemet er rettet mod JDeveloper og kan ikke umiddelbart integreres med Designer, da det er filbaseret. Det er netop dette system, som vi har fået Ian Fisher til at komme til Ballerup og fortælle om den 20. august (tilmelding sker hos jesper.n.larsen@oracle.com - det er gratis). Duncan Mills holdt en meget interessant præsentation om pakken WebUtil, som han har udviklet til WebForms. WebUtil-pakken indeholder en stribe kommandoer, som man tidligere kunne udføre på client/server, men som ikke længere er mulige, når man kører WebForms. Det drejer sig blandt andet om: - læsning og skrivning af filer på klientmaskinerne - overførsel af filer mellem klientmaskiner og servermaskiner - overførsel af oplysninger om klientmaskinen (OS, browsertype, brugernavn mv) - host-kald til opstart af programmer, der ligger på klientmaskinerne Business Rules Som det er blevet tradition er hele søndagen inden ODTUG-konferencen dedikeret til the Business Rules Symposium, hvor en lang række forretningsregelinteresserede holder indlæg. Paul Dorsey, David Wendelken, Bonnie O Neil mv holdt en stribe inspirerende indlæg om Business Rules, som nu lader til at være blevet anvendelige i praksis. Dulcians Business Rules Information Management system (BRIM) lader til at være meget ret modent. Emnerne for den næste version er optimering af evalueringer o lign, så de regner med at have fået styr på grundfunktionaliteten. Også CaseTechs Business Rules Approach ser meget overbevisende ud i sin enkle opbygning omkring at lokalisere og definere forretningsregler i et centralt beliggende point of definition. Bonnie O Neil nævnte, at man skulle holde øje med værktøjet ESI, som lod til at blive et interessant BRværktøj. Tools Teknisk Artikel OracleEkspert August 2003 11

Panel-sessioner Konferencen har også en række paneldiskussioner af typen Ask The Experts eller Ask Oracle. Her kan man spørge om hvad som helst inden for sessionernes emner. Med ikke mindre end fem Oracle VP ere og en lang række Product Managers er der gode muligheder for at få konfronteret Oracle med de ting man går og bander over hjemme på kontoret. Jeg ville elske, at høre Mogens Nørgaard rulle sig ud til en af disse sessioner! :-) Lunch Bunch Det er nu også blevet en fast tradition med frokostmøder et par af dagene. Her kan man tilmelde sig et emne som feks Metode, Forms, JDeveloper, eller Designer, hvorefter hver gruppe deltagere henvises til et område, hvor man kan diskutere det valgte emne, mens man spiser frokost. I år var der omkring ti Lunch Bunch grupper. Beach Party Og så må vi ikke glemme det legendariske Beach Party med blandt andet Beach Volley, kajak turnering og torvtrækkeri. På billederne ses: 1) Vice President for Portals and Hosted Tools, Marco Tilli, i Volley finalekampen. 2) Et par representanter for det danske kajak-hold (Søren og Rune), der venter, mens ODTUG bestyrrelsesmedlem, Jeff Canclini, og Michael Snyder fra CaseTech ser til at startopstillingen vælges på retfærdig vis. 3) Vice President for Application Development Tools and ilearning, Bill Dwight, og Steven Davelaar (udvikleren af HeadStart-pakken) ror sejren hjem til deres hold. I baggrunden ses Lauri Boyd (har også været med til at udvikle HeadStart) på vej ud til bøjen. Ses vi til næste år? Husk at hvis du får godkendt et indlæg, skal du ikke betale konferencetilmeldingen på usd 1000. [Der er flere billeder på vores hjemmeside] 12 August 2003 OracleEkspert

8. august 2003 Oracle fastholder opkøb af PS Oracle fastholder sit tilbud om opkøb af PeopleSoft-aktier til USD 19.50. Tilbudet er nu udvidet til den 19. september 2003. Talsmand for Oracle Jim Finn har udtalt: We remain fully committed to aquiring PeopleSoft. 28. juli 2003 Oracle vokser hurtigst i Europa IDC har kåret Oracle som den hurtigst voksende leverandør af applikationsservere i Vesteuropa. Med en vækst på 15.7% i 2002 er Oracle ved at nærme sig konkurrenterne IBM og BEA. Oracles markedsandel i Vesteuropa er nu 17.9%. Peter Perregaard har udtalt at verden nu er ved at opdage, at Oracle leverer markedets bedste og mest komplette middleware-option. 25. juli 2003 Collaboration Suite release 2 Oracle har frigivet release 2 af sin Collaboration Suite. Denne udgave har forsimplet og forbedret mulighederne for webkonferencer ifm planlægning, notifikation og initialisering af web-konferencer. Det er nu muligt for deltagere at review e og editere i dokumenter samtidigt, samt at anvende et fælles Whiteboard til at demonstrere ideer mv. 21. juli 2002 US Army chef bliver Oracle SVP Lt. General Joseph Kellogg Jr. bliver Senior Vice President for Homeland Security Solutions, som tager sig af IT til amrekas forsvar. 16. juli 2003 Jeffrey Henley åbner NASDAQ Jeff Henley deltager i åbningen af NASDAQ-børsen i New York kl 9:30 på NASDAQ Marketsite (4 Times Square - 43rd and Broadway). 15. juli 2003 Oracle og Yahoo Oracle og Yahoo har annonceret et samarbejde, hvor Yahoos brugere vil få adgang til over 100 nyhedsapplikationer (portlets) via en Oracle9i Application Server. 20. juni 2003 PeopleSoft afviser opkøb Samtlige medlemmer af PeopleSofts bestyrelse fraråder aktinærer at tage imode Oracles tilbud om opkøb for USD 19.50 pr aktie, og hævder at det ikke vil være til aktionærernes fordel. 19. juni 2003 Oracle kåret for bedste support The American Business Award kårer Oracle med en Stevie Award som bedste supportorganisation for god online kundeservice og support. 12. juni 2003 Oracle regnskab for Q4 Oracle annoncerer at de i 4. kvartal har tjent USD 0.16 pr aktie. Sidste år var indtjeningen USD 0.12 pr aktie. Overskudet er steget med 31% til USD 858 mill. Sidste år var overskudet for 4. kvartal på USD 656 mill. For hele 2003 regnskabsåret er overskudet steget med 4% til USD 2.31 mia eller USD 0.43 pr aktie. I 2002 var overskudet USD 2.22 mia svarende til USD 0.39 pr aktie. 11. juni 2003 OTN har nu 3 mill medlemmer Oracle annoncerede i dag, at de nu har mere end 3 mill medlemmer af Oracle Technology Network. http://otn.oracle.com Nyheder OracleEkspert August 2003 13

ORACLE KERNEN OG IO? Af: Jørgen Quaade En database's primære opgave er at sikre ens data mod alverdens ulykker. I computere kan det normalt kun gøres ved at skrive alt ned på diskene. Kun der, er ens data så nogenlunde sikret. I denne artikel vil vi se nærmere på den helt overordnede arkitektur af databasen og se på hvordan Oracle instansen bruger diskene. Først et par definitioner: Databasen består af datafiler, redo logs, kontrolfiler og alt, hvad der ellers ligger på diskene. Redo loggen er der hvor alle ændringer af databasen opbevares. Kontrolfiler indeholder information om hvilke datafiler der i systemet mm. I denne artikel er det en gennemgående antagelse, at der bruges mange diske, sådan at de forskellige filer ligger på et antal forskellige diske. Det er også sådan de fleste systemer ser ud. Instansen består af de processer og memory strukturer som Oracle bruger til at tilgå datafiler mm. IO står for intput/output og er bare en hurtig måde at sige læsning og skrivning til diskene. Hvis man skal have en database til at performe, er det vigtigt, at man såvidt muligt undgår at skrive til diskene. Grunden er ganske enkelt, at mens det tager nanosekunder at tilgå memory, tager det millisekunder at tilgå diskene. Det er med andre ord én million gange hurtigere at få fat i noget som er i memory. Så selv om det primære formål med en database er at sikre sine data ved at skrive dem ned på diskene, er det altså af stor vigtighed, at man skriver så effektivt og så lidt som muligt ned på diskene. Alt i Oracle's arkitektur og design er rettet mod at skrive så lidt som muligt men altid nok til, at det ikke er muligt at miste data, så databasen bliver inkonsistent. Derfor koncentrerer denne artikel sig også om IO og hvordan det håndteres af Oracle. Oracle Instansen er bygget op omkring et delt memory areal kaldet System Global Area (SGA). SGA'ets primære funktion er at fungere som en buffer. Alt hvad der bliver læst ind fra diskene bliver lagt i SGA'et og kan tilgås af alle processer i instansen. Groft sagt ser Oracle's arkitektur således ud: På tegningen står de små "r" og "w" for read and write, og "S" skal betyde Server processer. Server processerne har ansvaret for at servicere kald til databasen. Det er dem der læser data enten fra bufferen, hvis de allerede er der, ellers fra disk. Men de læser kun. De skriver aldrig. Alle skrivninger foregår i bufferen. Der kan være ligeså mange server processer, man har lyst til, dog normalt højst én per bruger. Ofte vil man dog vælge en model, hvor flere brugere deler den samme server proces. Server processerne læser fra alle datafilerne. DBWR, database skrive processen, skriver blokke fra bufferen til disk. Når server processerne har opdateret en blok, og den del af bufferen skal genbruges, er det op til DBWR at skrive den ud. DBWR skanner løbende bufferen for blokke til at skrive ud. Skulle det være nødvendigt, kan man starte op til 20 DBWR processer, som så alle vil hjælpe til med at skrive blokke til diskene. Det er dog sjældent man har brug for mere end én DBWR. Det skyldes især, at de fleste operativsystemer har en mekanisme kaldet asynkron IO, som giver samme funktionalitet som at starte mange DBWR processer op. DBWR vil typisk skrive til mange forskellige filer. LGWR, logwriteren, er den proces, som har ansvaret for at skrive ændringer ned i redo loggen, FØR ændringerne er accepterede. Først når redo loggen har sikret de nødvendige data til at genskabe en konsistent database ved at skrive ændringer ned på disken, får server processen besked på, at ændringerne er gennemført. På denne måde sikrer man, at man altid kan vende tilbage til et kendt og konsistent billede af databasen, selv hvis systemet pludselig fejler. Når en transaktion committes, vil de ændringer, der er blevet foretaget, blive skrevet ned i redo loggen. LGWR skriver altid kun i den aktive online redo log. Når den aktive log er fyldt, går LGWR videre til den næste redo log og gør den aktiv. Der kan kun være en LGWR. ARCH, archive log processen, har ansvaret for at arkivere fyldte online redo logs. Det gør den ganske simpelt ved at kopiere indholdet et andet sted hen, og markere loggen som arkiveret, så LGWR ved at den nu kan genbruge indholdet. Man kan starte op til 10 processer til at arkivere online redo logfiles. Der er også andre processer, som varetager forskellige andre opgaver, f.eks. overvågning af alle processer i systemet, men for klarhedens skyld har jeg kun taget de vigtigste med. Når man kigger helt overordnet på denne arkitektur bliver det klart, at flaskehalsen i dette system (når det gælder IO) er logwriteren. Server processerne er mange og læser fra mange diske. Der kan være op til 20 DBWR processer, som skriver til mange filer. Der kan være op til 10 ARCH processer, som dog skriver til den samme fil. Men der kan kun være én LGWR som skriver til én fil. Alt andet lige vil logwriteren altid være den der har den hårdeste belastning. Den har kun en proces og en fil at gøre godt med, modsat alle de andre, som enten har flere processer eller flere filer at gøre godt med. Derfor vil man også se, at når man har et veltunet system, så bliver performance begrænset af, hvor hurtigt man kan skrive til redo loggen. Det er altså klart at IO er et væsentligt problem for moderne systemer, og derfor er der da også alle mulige forskellige tekniske tiltag man kan gøre for at forbedre performance af ens IO, f.eks. med disk caches og hurtigere diske. Asynkron IO er også en mulighed. Det er en ret udbredt teknik, så i næste artikel vil jeg prøve at forklare hvordan asynkron IO virker. 14 August 2003 OracleEkspert

SKRIV EN ARTIKEL Vi betaler dig 700 kr pr side for artikler, som trykkes i OracleEkspert (400 kr pr side for engelsksprogede artikler). Du kan også komme til at vinde OracleEkspertprisen, som i december-nummeret uddeles til forfatteren af årets bedste artikel. Deadline for artikler til OracleEkspert er den 15. i måneden inden bladet udkommer. Har du lavet noget genialt, som kunne have interesse for andre Oracle-udviklere, ledere, planlæggere mv, eller har du bare nogle guldkorn, som andre kunne få glæde af, så skriv en artikel til OracleEkspert. Sådan gør du: Aflever et oplæg på ca 200 ord via vores hjemmeside: www.oracleekspert.dk under sektionen Din Mening. Når oplæget er godkendt af redaktionen, kan du skrive selve artiklen. Der ligger en MS Word template på hjemmesiden. Artiklen skal også godkendes af redaktionen. Dette sker ud fra kriterier om seriøsitet, relevans og teknisk niveau. Artiklerne skal henvende sig til erfarne Oraclefolk, og emnet skal på en eller anden måde være relateret 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 begynder at skrive den. Præsentationsartikler: Hvis emnet er et værktøj eller en service, som du selv udbyder karakteriseres artiklen som en præsentationsartikel. Disse koster 1000 kr per side, da de egentlig er en slags reklame (dvs at vi ikke betaler for artiklerne). Der gælder samme krav til seriøsitet og kvalitet ift præsentationsartikler som for tekniske artikler. OracleEkspert August 2003 15

Kære læser! Velkommen til ottende udgave af min klumme. Formålet med klummen er at informere om Oracle-verdenen, give råd og tips, diskutere aktuelle emner, fortælle om arrangementer, mv. Alt sammen selvfølgelig tilsat private meninger, rene gætterier, usubstantierede rygter og ikke mindst løse formodninger. Snakke-emnerne denne gang: It doesn t matter 10i 10G Mark Jarvis, Jeremy Burton, m.fl. Peoplesoft, JD Edwards Hvis et instans går ned ofte, så er der noget galt med din HW. Hvis det går ned sjældent behøver du nok ikke RAC. BAARF, PIP, Gaja og The Musical 6000 flere ansat i Oracle Indien? Teknik-emner: YODA CTU TAM af Martin Berg James fix 9.2 og NLS 32/64 bit Hash It doesn t matter Det her var overskriften på en artikel i Harvard Business Review for nyligt. Jeg troede først det var en artikel om, at livet var meningsløst, men forfatteren mente faktisk, at IT-branchen ikke betyder noget. Det er jo ikke specielt opmuntrende at skulle høre på, når vi nu er vant til at høre, at vi er åh så vigtige for firmaets ve og vel. De undersøgelser, der lå til grund for artiklen, viste sjovt nok, at virksomheder, der investerede rigtigt massivt i IT fik forværret deres konkurrenceevne. Ikke dermed sagt, at firmaer, der slet ikke investerede i IT, nødvendigvis fik forbedret deres. Store dele af vores branche lever af at sælge drømme. Drømmen om det firfarvede lagkagediagram, der giver direktørerne et pludseligt og blændende indblik, og sætter dem i stand til at feje konkurrenterne af banen. Drømmen om mødet i det flotte mødelokale, hvor powerpointen med de mange farver får en af direktørerne til at tage brillerne af og dingle dem i hånden, mens en power-klædt kvinde fortæller ham, at han kan erobre verden ved hjælp af et søjlediagram. Drømmen om de fem kloge mennesker, der mødes i en lufthavn, og pludselig forstår, hvordan Verden hænger sammen, mens de skynder sig af sted med deres rullekufferter. De har alle meget hvide tænder. Drømmen om indsigt, magt, fred og det, man automatisk kan få ud af det. Det får selv kloge, forstandige mænd til at investere enorme beløb i ERM, CRM, CSM, CSC, IBM, og alle sådan nogle forkortelser. ERP-projekter er ofte grumme eksempler. Jeg har personligt svært ved at pege på et ERP-projekt, der har været en virkelig succes. Jeg kan sagtens nævne virksomheder, der f.eks. har implementeret HR-modulet i Apps og fået det til at virke. Men den store, krombelagte løsning, der omfatter hele virksomheden, og stort set alt, hvad den laver, går som regel rigtigt galt. Det er muligt, at der er tale om så store beløb i investering, at der på forhånd Fanden Gale Mig er dømt succe. Det kan man se med Forsvarets vanvittige demars-projekt, der internt kaldes demanda. Alt går galt i dette projekt, som plejer at gå galt, og selv en Forsvarschef har måttet forlade jobbet på grund af projektet. Men det er en succes, meddeler Forsvaret. Det er da morsomt, at demars skal skaffe et enestående overblik over, hvor alle undertrøjer, snørebånd, sneplove og kanonrør befinder sig når det, der betyder noget er, hvor Fanden den kampvogn er henne i Bosnien eller den sneplov i Irak. Drømmen om det totale over- og indblik lever selvfølgelig stærkest hos organisationer som Forsvaret, men alligevel En klog fyr, som jeg har kendt i mange år og som har været med til adskillige ERP-projekter, mente, at ERP-projekter egentlig er dømt til at mislykkes qua deres natur. Man starter med store foranalyser, workshops, og alt det andet fancy halløj, der har til formål at afdække, hvad man egentlig laver i virksomheden og hvordan man laver det. Det skal så mappes over i et program, der oprindeligt er udviklet enten til Volkswagen i Tyskland (og derfor kræver, at man opretter Factories i sin implementering) eller er udviklet til et verdensomspændende softwareudviklingsfirma i Californien. Det tager normalt to år for den første fase, og i de to år øver man ofte vold på virksomheden, fordi alle Groans Fra Mogens OracleEkspert August 2003 17

ændringer i forretningsmodeller, etc. skal godkendes af en magtfuldt råd, der næsten hver gang kan fortælle ledelsen eller initiativtageren, at det vil fordyre projektet voldsomt. Så man lader ofte være. Bemærk, at ændring i forretningsmodeller ofte dækker over det kendte begreb god ide. Det er noget, der gør ondt, det her. Ligegyldigt hvad man ønsker at foretage sig i virksomheden skal man nu først tænke på det nye system i stedet for på ideerne. I har garanteret selv været ude for det masser af gange: Man forelægger en god ide, eller fortæller, at nu gør konkurrenterne altså sådan og sådan og så får flere af mødedeltagerne det der fjerne blik, mens de prøver at forestille sig, hvad der kan gøres ved systemet for at opnå dette eller hint. De prøver ikke mere at forestille sig, hvad ideen kunne gøre for firmaet. Af én eller anden grund er det noget, der skaber frustration i alle lag af virksomheden. Når man så efter to år har fået implementeret systemet, så det nogenlunde afspejler Verden, som den så ud for to år siden, så er alle meget forpustede, og ingen kan rigtigt genkende hverken de firfarvede, flotte diagrammer (som regel kræver det en special-tilretning og en helt speciel printer, som sekretæren ikke kan bruge til andet) eller de flotte, nemme skærmbilleder, som man havde set i demoerne. Så er man klar til Fase 2, thi der er nu så mange nødvendige forandringer ophobet, at man tror det er løgn, og de skal altså implementeres, og det kræver en ny bevilling og et nyt projekt, komplet med scope og de andre dyre ord. Faserne herefter bliver som regel meget mere kaotiske, idet man desperat prøver at tilpasse systemet til en Verden, der forandrer sig hele tiden. Det er på dette tidspunkt det nok går op for de fleste, at de bare har fået sig endnu et stort system i virksomheden, og at det er godt og skidt sammenlignet med det eller de systemet det afløste. Man opdager, at der er en masse tilretninger i systemet, som selvfølgelig kun kan forstås af præcist de konsulenter, der har lavet dem. Det er derfor, det ikke kaldes Standardsystemer mere. Det kaldes Standard- Ramme-systemer, fordi de alligevel ender med at være enormt non-standard-systemer. Og så er man ved at være klar til næste runde, hvor man begynder at drømme om et system, der kan opfylde ens hedeste drømme om indsigt Sådanne projekter koster i øvrigt altid mindst én ITchef og en projektleder stillingen. Nogle gange koster det ledelsen, direktionen (men de er som regel gode til at dække deres røv), eller måske endog virksomheden livet. Der er eksempler på det alt sammen. Så prøv at forestille jer en virksomhed, der har købt hele drømmeteknologistakken, og tror at de skal forandres til en e-business eller hvad det nu hedder nu om dage. De får altså brugt nogle penge og noget tid. IT doesn t matter. Det skal bare virke i nødvendigt omfang. Vores drømmeverden kommer ikke tilbage, selvom folk med penge i klemme i diverse investeringssammenslutninger bliver ved med at forudsige det snarlige opsving. Oracle-nyheder Der var tre interessante nyheder i de forløbne uger fra Oracle: Marketingsledelsen har forladt Oracle. 10i skal hedde 10G. Peoplesoft købte JD Edwards. Det var ikke kun Mark Jarvis (Chief Marketing Officer), der forlod Oracle. Det gjorde Jeremy Burton (Senior Vice President for Product Marketing) også. Og Rene Bonvanie, der også havde en ledende stilling i Marketing. Det her sker ligefør launchen af Oracle s næste database-version, og det var nok ikke noget, Larry havde planlagt. Sådan noget sker aldrig tilfældigt. Mark Jarvis var meget hurtig til at udsende en rigtig Marketing-mail til den mailingliste, der omfatter tidligere Oracle-ansatte (i USA hedder den Oracle Alumni, i UK hedder den LAOS Life After Oracle Society). Her skrev han, at han bare trængte til at tænke på sig selv, at han i de sidste 14 år aldrig havde været væk fra e- mail i mere end 24 timer, etc., etc. Snøft. Her er en del af hans mail: There were obvious outside factors - the economic climate and the fact that tech is no longer the "cool" industry, but those factors were less important. Yeah, right. Lad os se, hvad han skal lave i sit næste job. Det burde give et hint. Nå, men så har Oracle ladet sive, at de vil kalde 10i for 10G. G et står for Grid, og skal indprente i folk, at Oracle og Grid-computing hører uløseligt sammen. Oracle og Grid betyder RAC. Indtil der sker noget fuldstændigt vanvittigt nyt med Oracle, så er et Grid noget Oracle ser som et enormt stort cluster, og så kan RAC køre ovenpå det. Jeg ville ønske jeg kunne huske, hvad de der selvtænkende eller selvlærende netværk hed, som var så hotte for nogle år siden. Her fik et par danske forskere både skrevet en bog, nogle millioner fra staten, og deres navn nævnt i flere artikler i Computer World. Der var også noget med, at det blev brugt af Danske Slagterier til at styre svinekroppene rundt i et slagteri. Siden har man ikke hørt så meget til det. Forleden kunne man så læse, at et virtuelt center for Grid-computing havde fået et antal millioner af staten. Vi bliver ved med at tro på Det Tekniske Fix. Peoplesoft købte JD Edwards. Det gør det vanskeligere for Oracle at købe Peoplesoft, og det kommer heller ikke til at ske. Hele Peoplesofts kultur er fokuseret på Microsoft i størst muligt omfang, og så er Oracle ikke den man drømmer om at være partner med. Ligesom med SAP, så vælger mange Peoplesoft-kunder at køre løsningerne på Oracle. Det sker, fordi Oracle er den bedste database, fordi kunderne kan se, at de fleste andre kunder kører på det, osv. Men det sker til trods for leverandøren. SAP og Peoplesoft gør meget ud af at forholde sig neutrale på databaseområdet, men de ville rigtigt gerne tilbyde et alternativ til Oracle, fordi Oracle samtidig er en konkurrent på ERP/CRM-markedet. JD Edwards har vi nogle erfaringer med fra et par kunder. Deres tekniske vejledning til opsætning på Oracle er noget af det morsomste vi har set. F.eks. foreslår de, at man sætter _spin_count til antal diske gange disses hastighed. Hvis man har 5 styks 10K- 18 August 2003 OracleEkspert

diske, så skal parameteren sættes til 50.000. De mener naturligvis også, at timed_statistics skal sættes til false. Til gengæld har de så mange indexer gerne med de samme start- og slut-kolonner at man tror, det er løgn. Det er ikke en køn ERP-løsning på det tekniske plan. Det kan til gengæld godt være, at kunderne er glade for systemet. IT doesn t always matter på det tekniske plan Men hvor var det dog et genialt marketing-scoop for Larry at komme med det opkøbstilbud. Det satte Oracle på forsiden af aviserne, og gjorde koncernen synlig på en sjov og ny måde. Lige, hvad man trængte til. Da så samtidig Gartner og andre gik ud og anbefalede, at man ikke købte Peoplesoft og JD Edwards mens det her halløj stod på, så var det noget, der ramte Peoplesoft rigtigt hårdt. Salget stoppede simpelthen. Gode gamle Gartner. Var det fjerde kvartal 2003 eller tredje kvartal 2004 de forudsagde ville blive starten på det fornyede opsving? Det bliver spændende at se. I øvrigt offentliggjorde Oracle også, at de ville ansætte 6000 flere i Indien. Hvis nogen behøvede flere beviser på, at de store selskaber ikke mere kan få konsulentforretningerne til at hænge sammen økonomisk i de rige lande, så kom det her. Alle de andre store vil gøre det samme. Men. Indere er dygtige, arbejdssomme og billige. Og så er de altså heller ikke mere fantastiske end det. Man kan da lige så lidt tage 1000 highschool graduates i Florida og kalde dem et Oracle-support center som hyre 6000 mennesker i Indien og kalde dem Oracle Services. Der er mange problemer forbundet med at arbejde med billig arbejdskraft fra fattige lande nogle gange kaldet The Bombay Solution. Så er det ligemeget, om det er indere, kinesere, eller hvad det er. Men hvis man mener man kan spare penge, så vil man bruge dem. Uanset hvad fagforeningerne finder på af dårlige undskyldninger. Gid de ville holde sig udenfor denne diskussion, så vi ikke ender som den nye tids typografer. BAARF, PIP, Gaja & The Musical James Morle og jeg har stiftet The BAARF Party. BAARF står for Battle Against Any Raid-F. F står både for Free, Four, Five og Fix, dvs RAID-3, -4, -5 og 6. Med andre ord: Alle RAID-implementationer, der benytter sig af Parity. Parity Is Pain (PIP) er et af vore slogans. Ideen opstod en aften efter et par øl i omegnen af Birmingham før et stort UKOUG-møde i deres UNIX- SIG. Vi var bare så trætte af at skulle fortælle om og om igen, hvorfor RAID-F er noget skrammel, så James foreslog at vi holdt op med at diskutere det. Enough is enough. Når vi har sagt det samme i 15 år, skrevet det samme i 15 år, og hørt på det samme sludder i 15 år, må det være på tide at stoppe, sænke blodtrykket, og sige: Enten er I med os, eller også er I ikke. Vi gider ikke snakke mere om det. I kan læse mere på Miracle s hjemmeside - eller direkte på www.baarf.com - og I kan også bare sende mig en mail om, at I gerne vil være partimedlem så får I et medlemsnummer og bliver inviteret til BAARF Party conventions. Det flotte BAARF-logo, som James har lavet, er I velkomne til at stjæle og anvende andre steder. Cary Millsap er æresmedlem sammen med Jared Still, som i mange år har haft en anti-raid-5 kasket på sit kontor. Den rigtigt store nyhed omkring BAARF er, at vi på Database Forum opfører en musical om emnet. Jeps, vi har skrevet BAARF. The Musical med Gaja Vahatneyhatneyhatney i hovedrollen (spillet af Gaja himself) som en stakkels, forvirret IT-konsulent, der både møder FEVER (Five Evil Vendor s Eternal Rotherhood) og BAARF-partiets medlemmer på sin quest (høhø) for at finde svaret. Musicalen bliver opført efter Dave Ensor s tale ved Galla-middagen, og inkluderer nye tekster til meget kendte sange, The OakTable Choir, et særligt lydafskærmet område for folk, der vil spille luftguitar, og en masse fællesang. YODA Martin Berg og jeg satte os ned en dag i Oracle s kantine og fik et par gode ideer. Der kom tre nyttige ting ud af det: En undervisnings-special, som blev kørt af Martin Berg, Johannes Djernes og jeg. Og YODA og CTU. YODA står for YAPP Overblik, Diagnose, Analyse. Vi havde selv forestillet os, at det skulle hedde YAPP ODA, men så foreslog Jonathan Lewis at det skulle være YODA ligesom i Star Wars. Jeg synes bare det er fedt, at det lyder som det gode, gamle danske Joda på bredt jysk. YAPP-delen kender I alle. ODA-delen skal beskrive, hvad man kan bruge YAPP til på forskellige niveauer, nemlig system-, session/job- og SQL-niveau. På System-niveau, hvor man bruger v$system_event og v$sysstat manuelt eller i forbindelse med Statspack, bstat/estat, etc. kan man højst bruge data til at få et overblik. Og det er vel at mærke, hvis vi skal sige det pænt. Hvad vi egentlig mener er, at det ikke kan bruges til noget som helst. System-level målinger er ubrugelige, fordi de viser summeringer, og summeringer kan aldrig sige noget om detaljer. Tak for denne indsigt til Cary Millsap og hans nye papir om Oracle Operational Timing. Han er sgu go. Men vi skulle jo finde på noget (også fordi vi selv har prædiket brugen af system-level målinger i mange år), så vi fandt på det pæne ord Overview eller Overblik. Man kan selvfølgelig også bruge det til at imponere chefer eller andre, der ikke ved, at det bare er fremvisning af ikke-konklusive tal. Nå, men på session/job-niveau kan man lave en fornuftige Diagnose af problemet. Det kan se vha 10046- traces, logon/logoff-triggere der anvender v$session_event og v$sesstat, etc. OracleEkspert August 2003 19

Og den dybere Analyse af de enkelte SQL-statements er også særdeles nyttig. I kan få YODA-dokumentet tilsendt fra mig, hvis I er interesserede. CTU Martin Berg og jeg har længe snakket om at kontrollere online-batch og batch generelt, fordi man ikke kan køre mere end to af dem (faktisk ca 1.8 for at være helt nøjagtig) pr CPU uden at skabe kø. Tre simple ting blev så kombineret den dag i kantinen, og Martin kom med det geniale navn CTU, der står for Counting The Uncountable eller Controlling The Uncontrollable. De tre simple ting er disse: IBM s definition på et batchjob er, at det er et job, der bruger mere end 10 CPU-sekunder. Gode, gamle Audit Session kan vise hvilke jobs, der gør det (Counting The Uncountable). Oracle9i s Ressource Manager kan re-dirigere jobs, der overskrider 10 CPU-sekunder til en kø, hvor concurrency kan styres (Controlling The Uncontrollable). Vi har prøvet det på et par kunder, og Peter Sørensen fra Miracle A/S har lavet lidt regnearkshalløj ovenpå AUD$, så man kan se batch-concurrency i sit system. I kan bare skrive til mig eller til Peter (pso@miracleas.dk) for at få det. Ressource Manager er ikke helt tosset til formålet. De første 10 CPU-sekunder er IKKE tabt man får bare jobbet sat i batchkøen og får det afviklet med 1, 2 eller flere samtidige jobs kørende. Så er det ligegyldigt om jobbet kom fra batchkøen eller fra Frk Petersen, der startede en rapport ved et tryk på F5. Simpelt, ikke? Nogle burde bygge et flot, grafisk værktøj op, der gør det her, plus måske laver et par rapporter, sender et par mails og andre unødvendige, men flotte ting. TAM (af) Martin Berg ThrowAway Metoden (TAM), som Martin Berg opfandt og beskrev over 50-60 sider mens der stadig var noget, der hed Premium, er fortsat aldeles genial og samtidig den eneste metode, der korrekt og systematisk gør én i stand til at tune SQL. Hvis man ikke benytter TAM, så benytter man sig af gætværk (dvs. erfaring, uvidenhed hos dem omkring sig, og andre tricks). Jeg ved da godt, at Johannes Djernæs, Martin Berg, Alex Høffner, og sådan nogle kan lægge hænderne over et langt SQL-udprint og påpege, hvor det går galt, men det er de færreste der kan det, og de herrer bliver nogle ordentlige flaskehalse, hvis nationen som sådan skal anvende deres magiske evner. Den største naturtalent jeg har set på det felt er i øvrigt den tidligere Premium-mand Henrik Tengberg. Han er nærmest autistisk med det. Han aner heller ikke selv, hvad der sker i knolden på ham, når han ser et stykke SQL, men det er ret utroligt. Jeg tror han sidder i Force-institutterne eller sådan et sted nu. Måske forårsaget af, at jeg sendte ham til et koldt sted nord for Stockholm i et halvt år. Sundsvall er navnet. Der er skrevet sange om ensomheden i Sundsvall, og det kan man godt forstå. Det rangerer fuldt på højde med CV Jørgensens gamle sang, som efter min bedste erindring lyder noget a la dette: Der er ingenting der swinger Som Bjerringbro by night Hele hovedgaden emmer Af jyske karle fit for fight Man kan også anskaffe sig diverse magiske værktøjer, men de kigger sgu bare på eksekveringsplanen og siger Hov, her er et full table scan, uha uha og den slags ting, og det er jo noget sludder. Så længe de ikke kigger på, hvor arbejde bliver smidt væk (dvs. benytter sig af Martins metode) laver de (også) gætværk og imponator-tricks. Nå, tilbage til det vigtige: Få fat på Martin Bergs papir om TAM. Få det læst. Skriv til Martin, hvis I har spørgsmål. Han er go. James Fix Jeg tror jeg har beskrevet det tidligere, men nu får I den lige igen. Bug 2425312. Patches fås til 8.1.7.4 og 9.2. Permanent fixet i 10i. Med denne rettelse kan I se PL/SQL-timings i 10046-tracefilerne, så den ofte store klump tid (Cary Millsap kalder den un-accounted for time), der ikke kan forklares, bliver noget mindre. 9i og NLS Here we go again. Der kan opstå mystiske installationsproblemer med 9i, hvis man ikke har sat NLS korrekt. Det gik ud over én af mine gamle venner, som først efter en længere samtale med Peter Gram fik løst problemet. Det er altså smukt, at NLS-problemet fortsat kan forekomme, selv i vore dage, under installationer. 32/64-bit Der er vældig gang i reklametrommerne rundt omkring hvad angår 64bit. Anjo Kolk holder et indlæg om det på Database Forum, men jeg kan da røbe følgende dybe hemmeligheder og storslåede sandheder: Når der skal flyttes 64 bits rundt i stedet for 32, så skal der flyttes dobbelt så meget. Det er ikke hurtigere. Det er langsommere. Hvis man gør busserne, togene, metroen og CPU erne hurtigere, så er det muligt, at man netto tror man kører hurtigere på sin 64bit-computer. Hvis man har brug for at adressere enormt meget memory (f.eks. for at få en meget stor buffer cache hit ratio ), så er man nødt til at benytte sig af 64bit. Men det er jo noget, der rykker: Det er Det Tekniske Fix og Loven om Større Tal i skøn forening. Hash-algoritme To ting: Hash-algoritmer og single table in hash cluster. Prøv at søge på bob jenkins perfect hash på Google, og I finder ud af, hvordan Oracle s hash-algoritme virker. Det er da meget sjovt at vide. Den bliver modificeret i næste release, fordi der faktisk godt kan forekomme to forskellige statements med samme hash- 20 August 2003 OracleEkspert