Oktober 2002 Nr 14, Årgang 3 ISSN 1600-5147 Pris: kr. 125,00 ex moms www.oracleekspert.dk #14 OUGDK 23 OUGDK Stormøde Næste møde er endnu ikke fastlagt. DBA SIG Næste møde er endnu ikke fastlagt. Designer SIG Næste møde: 2. oktober 2002 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. Web SIG Næste møde er endnu ikke fastlagt. NYHEDER 13 DATABASEN SOM MEDSPILLER I TEST 4 Christian Bastlund Denne artikel handler om, hvordan man kan lave en paralleltest af et gammelt system, hvor de centrale batchprogrammer er omskrevet til PL/SQL, og man skal sikre, at funktionaliteten er bevaret. Det nævnes også, hvordan konceptet kan bruges i andre situationer. Det brede sigte er at fortælle, hvordan man bygger en database op, så den bruges aktivt i udviklingen til at støtte test. FGAC, FGA OG MV? 9 Martin Jensen Fine Grained Access Control (FGAC) er grundfaciliteten bag Oracle s Virtual Private Database (VPD) koncept. Materialized views er Oracle performance booster i forbindelse med tuning af agregerede forespørgsler i datavarehus-agtige sammenhænge. Og Fine Grained Audit (FGA) er (i Oracle9i EE) Oracle s nye mulighed for at auditere selects mod følsomme områder i databasen. Hvordan er det nu disse 3 faciliteter arbejder med hinanden? GROANS FRA MOGENS 14 Emnerne denne gang: Opfølgning på sidste nummer. Gang i den for nogen. Fest for de Fyrede (eller: Hvordan der er pludselig at være udenfor Firewall en). OakTable på Oracle World i San Francisco. Fødselsdag. Sys.dual. Break/Reset-events. Pga_Aggregate_Target. Audit af remote connections. To batchjobs per cpu også med Oracle PX. Fremragende artikel om 10053. File/block to object mapping på en ny måde. Orange Danmark køber RAC Larry Ellison træder tilbage Oracle og Intel annoncerer Bio-Key Oracles Q1 regnskab Oracle TPC-C verdensrekord 2 Oracle TPC-C verdensrekord 1 Oracle valgt som bedste database Vil din virksomhed være Sponsor? Hvis I har mulighed for at hjælpe med feks at korrekturlæse, trykke, kuvertere eller udsende OracleEkspert, så kvitterer vi feks med gratis annonceplads samt firma-logo på forsiden af bladet. Send tilbud til Redaktionen@OracleEkspert.dk eller ring 26279991
Leder VOTE FOR MARC DE OLIVEIRA Marc de Oliveira, ansvarshavende redaktør. Ja, jeg kan godt se, at overskriften virker lidt selvoptaget, men drastiske mål kræver drastiske midler. Mere om det lidt længere nede. Dette nummer udkommer i en lidt reduceret størrelse grundet manglende artikler. Vi vil derfor indtrængende opfordre vores læsere til at fatte pennen og fortælle os om hvordan I klarede uoverskuelige forhindringer, eller evt om små fif, der kan gøre hverdagen som Oracle-DBA er/udvikler/leder lidt nemmere. Brug gerne MS Word template en, som ligger på vores hjemmeside. Din ydmyge redaktør har, efter i juni måned at være blevet valgt som Designer koordinator for ODTUG, opstillet sit kandidatur til valget af ODTUG Board of Directors. Med en plads i Board of Directors vil jeg have endog meget gode kort på hånden til at fremføre Oracle-udvikleres - og i særdeleshed dette blads læseres - meninger, og påvirke Oracles holdninger til deres udviklingsværktøjer. En af mine højeste prioriteter som medlem af ODTUG Board of Directors vil være at få deres Enhancement Request system til Designer, Discoverer, Forms, JDeveloper, PLSQL, Portal, Reports, Warehouse Builder etc til at fungere igen. Ingen af de indkomne ønsker er blevet behandlet af hverken ODTUG Enhancement Request kommiteen eller Oracle siden september sidste år. Der er fire pladser i ODTUG Board of Directors og seks nominerede. Tre af de seks nominerede er så kendte i miljøet, at de må regnes for at være selvskrevne til at blive valgt ind. Det efterlader reelt de sidste tre nominerede som kandidater til een plads. Derfor henstiller jeg her til at OracleEkspert-læsere, som måtte være medlem af ODTUG (eller påtænker at blive det), benytter sig af deres ret til at stemme til valget af ODTUG Board of Directors. Jeg håber selvfølgelig, at I alle vil kunne se værdien i at få en dansk repræsentant i ledelsen af ODTUG. Til læsere, der ikke er sikre på om de skal melde sig ind i ODTUG, kan jeg fortælle at medlemskabet, som koster USD 125 pr år, giver USD 100 rabat til ODTUG konferencen, som næste gang afholdes i Miami. Desuden giver medlemskabet adgang til pre-release udgaver af Oracles værktøjer, hundredevis af gode artikler, samt ODTUGs on-line Enhancement Request service. De seks nomineredes kampagneerklæringer og biografiske oplysninger kan læses på www.odtug.com. Til slut vil vi endnu en gang gerne efterlyse personer eller virksomheder, som er interesseret i at påtage sig et ansvar for bladet. Som bladets økonomi ser ud, kan der kun blive tale om aflønning i form af enten en dejlig pakke med økologiske varer (til enkeltpersoner) eller gratis annonceplads i forbindelse med hver udgivelse (til selskaber). Alle sponsorer vil kunne få deres firma repræsenteret med feks logo på bladets forside. Hvis du eller dit firma er interesseret i at påtage sig een eller flere af følgende opgaver, så send en mail til Redaktionen@Oracle- Ekspert.dk og fortæl lidt om dig selv, og hvad du/i kan tilbyde at hjælpe med. Indsamling af Oracle-nyheder Håndtering af OUGDK-stof Skrivning af Oracle-relaterede boganmeldelser Salg af abonnementer og/eller annoncer Kuvertering og afsendelse af blade Korrekturlæsning Andre ideer, der kan gøre OracleEkspert til et bedre blad, er selvfølgelig også velkomne. Oplag:................250 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 Groans fra Mogens:................Mogens Nørgaard...............mno@MiracleAS.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 125,00 1 års abonnement: - Blad................DKK 600,00 - Elektronisk..........DKK 1200,00 - Medlemskab........DKK 1800,00 Rabatordninger kan findes på vores hjemmeside. Annoncer: Annoncer til OracleEkspert nr 15 skal være PYTHIA Information i hænde senest den 15. november 2002. Annoncepriser kan findes på vores hjemmeside. Password: squared
Undgå at jeres medarbejdere skal stå i kø på fordelingslister for at læse OracleEkspert Vælg et Medlemskab til dit firma For 1800 kr pr år får I: OracleEkspert i PDF-format Adgang til alle tidligere numre I modtager bladet samtidig med at det går i trykken (op til en uge før andre abonnenter) I kan selv udskrive og distribuere bladet til alle medarbejdere i virksomheden
Metode Teknisk Artikel DATABASEN SOM MEDSPILLER I TEST Christian Bastlund er ansat i CSC Consulting Group i Herlev som konsulent, og har arbejdet som konsulent i Danmark og England. Uddannet Datalog fra Københavns Universitet med bifag i Informationspsykologi. Udover at arbejde med systemudvikling og Oracle er hovedinteressen menneske-maskin samspil og formidling Indledning Har du nogensinde prøvet at teste nogle store, uoverskuelige batchprogrammer? Har du prøvet det, når de var skrevet i en række sprog, som du ikke er særlig god til, og hvor dokumentationen er uklar eller mangler helt? Og hvor du ikke har særlig gode muligheder for at få at vide, hvad programmerne egentlig skal gøre? Hvor det du har, er et gammelt system, som har kørt i mange, mange år, og som skal fornys. Denne artikel handler om, hvordan man kan lave en paralleltest af et gammelt system, hvor de centrale batchprogrammer er omskrevet til PL/SQL, og man skal sikre, at funktionaliteten er bevaret. Det nævnes også, hvordan konceptet kan bruges i andre situationer. Det brede sigte er at fortælle, hvordan man bygger en database op, så den bruges aktivt i udviklingen til at støtte test. Situationen Udgangspunktet er et gammelt system med en Oracle 6 database og en række batchprogrammer, som er centrale for systemet. Disse programmer har kørt i årevis, og alle der ved noget om dem, er for længst over alle bjerge. Opgaven er, at opgradere databasen til Oracle 8i. Det er også besluttet at omskrive programmerne til ét sprog, nemlig PL/SQL, fordi man mener det vil være lettere at vedligeholde, og der er færre bindinger til andre produkter og operativsystemer (i dette tilfælde Unix). De gamle programmer er Unix shell-scripts, hvor der anvendes en lang, lang række mere eller mindre obskure features, hvoraf en del afhænger af den bestemte version af operativsystemet, hvor der er masser af parametre, der er blevet sat rundt omkring på mange forskellige måder og som popper op hid og did, og hvor programmerne kalder andre programmer i nærmest én uendelighed. Der bruges også Oracle Sqlplus, som udfører operationer på databasen, og der kaldes meget store C programmer, som arbejder på databasen ved hjælp af indlejret SQL. Jeg vil hævde, at selv en erfaren shell-programmør, som også har godt kendskab til C og SQL, kan have vanskeligt ved at overskue det hele. Heldigvis er der ikke store krav til ændring af funktionalitet, og de ændringer, der ønskes, er velbeskrevne. I den ny database er tabelstrukturen i det væsentlige uændret, og der er ikke indført nævneværdig ny funktionalitet. Så det er nemt. Samme database! Der er lavet konverteringsprogrammer. De er ret simple. De gamle batchprogrammer er møjsommeligt omskrevet til PL/SQL og implementeret som pakker på den ny database. Det kan faktisk lade sig gøre, uden at kende sprogene særlig godt eller vide, hvad de egentlig foretager sig. Men selv hvis man er ekspert, vil der være berettiget tvivl om, hvorvidt mapningen mellem det gamle og det ny er helt korrekt. Så det er svært. Samme programmer? Øvelsen består altså i at konstatere, om de nye programmer på den nye database foretager de samme ændringer, som de gamle programmer i den gamle database. Konceptet For at teste at funktionaliteten er uændret, er der en periode med paralleltest. Det gamle system kører som produktion, også med sædvanlig batchafvikling. Data hentes fra produktion og læses ind i det nye system, hvor testen foregår. Paralleltesten forhindrer ikke andre udviklingsaktiviteter og andre tests, idet datasæt til test af batch er isoleret fra det egentlige system. Paralleltesten tester én batchafvikling af gangen. Hver batchafvikling har egne sæt data. En batchafvikling består typisk af et antal programmer. Paralleltest Universet er opbygget som følger: Før og efter hver batchafvikling på det gamle system er der indsat en (automatisk) Oracle eksport af data. Eksportfilen med data før afvikling hedder GL1.dmp, data efter afvikling GL2.dmp. Det viser, hvad den gamle batchafvikling har lavet af ændringer. Den nye database har et antal logiske inddelinger. Man kan tænke på det som en lagkage med seks skiver, herunder fire skemaer til før og efter data for batch. Et skema er en Oracle bruger, der ejer tabeller. De seks skiver i lagkagen er: BASIS. Selve Oracle. Det er Oracle bruger SY- STEM og SYS. Der er dataområder til system (tablespace SYSTEM) og temporær lagring (tablespace TEMP) og forskellige andre ting. Alt dette findes i ethvert Oracle system. Pointen er, at de andre skiver er fælles om at bruge alt det her, og der ikke er grund til at oprette flere databaser, som hver især dublerer BASIS. Det fylder nemlig en del. MAIN. Dette skema er det egentlige skema i det nye system. Den bruges ikke i paralleltest. GL1. Dette skema er data fra det gamle system før batch. De hentes fra eksportfil GL1.dmp. GL2. Dette skema er data fra det gamle system efter batch. De hentes fra eksportfil GL2.dmp. NY1. Dette skema er data fra GL1 efter konverteringsprogrammerne har behandlet dem. Det er med andre ord de gamle data i det nye miljø før 4 Oktober 2002 OracleEkspert
batch. Helt unødvendige tabeller kan udgå. NY2. Dette skema starter med at være identisk med NY1. Den nye batchafvikling køres på NY2. Så er NY2 data efter batch med de nye programmer. Sammenhængen er altså: GL1 data gammel batchafvikling kører GL2 data og NY1 data (konverteret fra GL1) nyudviklet batchafvikling kører NY2 data Grundstenen i konceptet er, at NY2 og GL2 skal være ens. Hvis de er ens, er det en mere eller mindre god indikation på, at omskrivningen af programmerne er rigtig. Hvis NY2 og GL2 ikke er ens, er der fejl (med forbehold for tidsangivelser, som kan være lovlige undtagelser). Selvfølgelig er det en god ide at gentage testen mange gange på forskellige data og tænke over, om data er dækkende for alle situationer. Ulemper ved konceptet: Det kræver plads. Det kræver programmer for at kopiere data. Men de er nemme at lave. Det kræver konverteringsprogrammer tidligt i udviklingsforløbet. Men de skal laves under alle omstændigheder, og det er en god ide at lave konverteringer tidligt i et projekt. Det kræver kalendertid, dvs. at testene ikke kan foregå hurtigere end produktionssystemets cyklus. Tidsstempling og tidslogik kan være et væsentligt problem. Det kræver lidt projektstyring og en anelse disciplin at indføre. Det kan kræve adgangsret, viden og kompetencer, udviklerne ikke har. Det kan være problematisk at skedulere forløbet, hvis der er mange batchafviklinger. Det kan være vanskeligt at vurdere, om de anvendte datasæt afslører alle slags fejl. Nogle folk kan have svært ved at følge med i, hvad der foregår. Fordele ved konceptet: Testdatasæt er stabile. De bliver ikke overskrevet eller ændret uden varsel. Testdatasæt kan sammenlignes på kryds og på tværs. Det gør man for at undersøge fejl og for at forstå, hvad der foregår. Man kan arbejde på datasættene i fred og ro. Man er ikke afhængig af eller underlagt produktionsmiljøets forretningsgange, efter man har fået fat i de data, man skal have. Processen er let at automatisere. Processen er let at gentage. Der er muligt at forklare folk, hvad der foregår, hvis man er opmærksom på formidling. Sammenligninger Man skal undersøge, om data i NY2 og GL2 er ens. Det kan man kalde horizontal sammenligning. Det er ret nemt i SQL. Man skal undersøge alle tabeller. Her er et eksempel med en tabel, der har fire felter: select count(*) from ny1.person; select count(*) from ny2.person; select count(*) from ny1.person,ny2.person where and ; ny1.cpr = ny2.cpr ny1.cpr ny1.fornavn ny1.mellemnavn ny1.efternavn = ny2.cpr ny2.fornavn ny2.mellemnavn ny2.efternavn Alle tre antal skal være det samme. Bemærk at felterne konkateneres til en streng i stedet for at lave mange AND betingelser. Alle felterne er med i strengen, også nøglen. Det er fordi det er hurtigere og nemmere at lave (man kan endda generere strengen automatisk, hvis man er god til Oracles Data Dictionary), bare tag alle felterne med, og man behøver ikke tænke på nøgler hele tiden, kun når man laver join-betingelsen, det er derfor mere sikkert. Konkatenering til streng kan også bruges til at undgå OR konstruktionen og dens paranteser. Hvis der er fejl, kan man lave undersøgelser og finde rækker, der er forskellige, og rækker, der er i den ene udgave, men ikke i den anden. Teknikker for sammenligning er beskrevet i Bodil Feldingers artikel Tabel-sammenligninger m. SQL i Oracle Ekspert # 11, april 2002. Til sammenligninger kan man overveje at anvende andre produkter. Unix diff kommandoen viser forskelle mellem to filer. Det foregår ved at spoole indholdet af hver udgave af tabellen til fil og foretage diff, for eksempel diff persontab.ny1 persontab.ny2 OracleEkspert Oktober 2002 5
(man kan lave en lille forskel i hver fil, for eksempel en titel, bare for at se, at det er udført). Jeg synes, diff - outputtet er lidt svært at læse, hvis der er mange forskelle, men andre vil måske synes, det er rigtig godt. DOS har en kommando fc, men den er ikke særlig anvendelig. Produktet Windows Commander har en ret god sammenligningsfunktion. Men man kan også holde sig til SQL. Uanset om der er fejl eller ej, kan man få mere at vide om, hvad batchafviklingen laver, ved at sammenligne tabeller i NY1 og NY2 og/eller GL1 og GL2. Det kan man kalde vertikal sammenligning. Det kan være nyttigt, hvis man skal lave dokumentation, der beskriver programmerne. Vertikal sammenligning kan også bruges til at vurdere, om datasættet indeholder de relevante typer data og i hvor høj grad alle situationer er testet. Husk at spørge brugerne, ofte har de en meget god føling med, hvad man skal gå efter og passe på. Selv hvis der er nye krav til funktionalitet omkring batch, kan ovenstående teknikker bruges, hvis den ny funktionalitet er velbeskrevet, og det skulle den da meget gerne være. Så skal det sikres, at de ændringer, man finder, svarer til hvad der forventes. Import af data og pladsbesparelse Eksportfil dannes i det gamle system og importeres i den nye database. Import opretter tabeller, hvis de ikke findes i forvejen. De oprettes og arver de pladsparametre, de har i den gamle base. Det er ikke altid godt. Vi vil have, at det fylder så lidt som muligt. Tricket er at oprette tabellerne i forvejen og at de er defineret, så de fylder så lidt som muligt, når importen fylder dem op med data. Det kan være rimelig svært at gennemskue, hvor meget plads data i en tabel reelt optager. Data i tabeller ligger fysisk i extents. Der er første extent (initial extent) og efterfølgende (next extent). Problemet er, at store extents ikke nødvendigvis er fyldt helt op, og så ser det ud som, at data fylder mere, end det reelt gør, og der bliver brugt mere plads end nødvendigt. I det konkrete tilfælde var der forbrugt 333 Mb i den gamle database, og efter import fyldte det samme data 197 Mb i GL1. En nem måde at gøre det på er følgende: På det dataområde (tablespace), hvor tabellerne skal ligge, defineres størrelse på extents til at være så små som mulig. Antallet af extents sættes til uendelig. alter tablespace PTEST_DATA default storage (initial 16k next 8k pctincrease 0 minextents 1 maxextents unlimited); (Man kan forinden sikre sig, at de små størrelser er tilladt: alter tablespace PTEST_DATA minimum extent 0k; ) I den konkrete situation er serverens blokstørrelse 8 kilobyte, så det er minimum. Initial extent skal have en ekstra blok, det er til noget headerinformation, derfor bliver den 16k. Når data fyldes på, så er det ret nemt at se, hvor meget plads data optager. Eksempelvis fylder 379 extents 1*16 kb + 378*8 kb = 3056 kb. Mange vil mene, at det er meget vigtigt, at al data lægges i initial extent, fordi det skulle betyde meget for performance. Det er en myte, og det sagde Ken Jacobs ved OracleWorld 2002 konferencen i København i juni. Han er Doctor DBA der, populært sagt, har lavet Oracle databasen de sidste mange år. Jeg ved ikke, om han snakkede om nyere Oracle versioner, eller om det altid har været sådan. Hvis man enormt gerne vil have, at al data ligger i initial extent, kan man første gang bruge de små extents og tilrette tabellernes initial extent efterfølgende. Tabellerne oprettes selvfølgelig fra et script med CREATE TABLE. Man lader være med at angive pladsparametre, og så anvendes tablespacets default værdier. Oprettelse, nedlæggelse, tilretning i øvrigt Tabeller oprettes i skema NY1 og NY2 ved hjælp af scripts. NY1 skal have konverterede data fra GL1. NY2 kan initialiseres fra NY1 med CREATE TABLE <tabelnavn> AS SELECT * FROM ny1.<tabelnavn>. Samme princip med små extents som default kan bruges. Tabellerne behøver ikke have alle de index, som de har i MAIN, det fylder, og plads kan som sagt være et problem. Man kan overveje, om man vil anvende constraints og primærnøgler, man kan godt klare sig uden. Skemaer droppes, når hele paralleltesten er overstået, undtagen GL1 til den endelige konvertering. Det frigør pladsen, for de er jo temmelig store, da de hver indeholder det komplette datasæt. Batchprogrammerne ligger som procedurer i pakker. Det må ikke være de pakker, som ejes af MAIN! Pakkerne skal oprettes som kopier, der er ejet af NY2 for at sikre, at det er de rigtige tabeller, der refereres. NY2 må slet ikke have rettigheder til andre skemaers tabeller. Man skal være opmærksom på SYSDATE og tidsproblematik i det hele taget. Det skal man overveje, før man kommer for godt i gang. Procedurerne kan indeholde SYSDATE, som skrives i tabeller eller påvirker programlogikken. Man kan erstatte forekomster af SYSDATE med en variabel, der initialiseres på en fiks måde (man skal huske at deaktivere sådan noget i de versioner, der går i produktion). Måske er tid et meget lille problem, måske et meget stort. Der er mange måder at komme rundt om det på. Generelt at sætte tiden til det samme, som da afviklingen startede i produktion (men tager afviklingen præcis lige så lang tid næppe). Se bort fra tidsdata i sammenligningerne. Si tidsfelter fra ved at lave views, hvor de er væk, og foretag sammenligninger på disse views. Der en mange muligheder. Sekvenser (sequences) skal man også være opmærksom på. De skal initialiseres, så de har samme værdi som i GL1. Teoretisk set kan de blive forskellige i NY2 versus GL2, hvis de er blevet talt op i produktion af andre processer. Hvis det er et problem, må man tage højde for det analogt med tidsproblematikken. 6 Oktober 2002 OracleEkspert
Trinvis forfining af rettigheder Hvis man ønsker at vide helt præcist, hvilke tabeller og andre objekter, batchafviklingen anvender, kan man gøre det på en temmelig simpel måde ved at modificere konceptet en lille smule. Det er et alternativ til at nærlæse en hel masse kode, som kan være svær at gennemskue. Man opretter en ny runbruger for den pågældende batchafvikling, i stedet for at køre på bruger NY2 som angivet ovenfor. Den ny bruger kan kaldes NY2RUN_JOB_A, NY2RUN_JOB_B osv., én for hver batchafvikling. I starten skal brugeren ikke have nogen rettigheder overhovedet fra NY2. Tricket er, at man ikke opretter pakker på NY2. I stedet kompileres pakker på den ny bruger. Man starter med en pakke. Kompileringen vil fejle, og give fejlbesked om andre pakker og tabeller, sekvenser og lignende, som den mangler. Tabeller (og andre objekter, der ikke er pakker), der fejler, gøres kendt overfor NY2. Hos runbrugeren laver man et synonym til objektet i NY2. I NY2 tildeler man rettigheder (SELECT, INSERT, UPDATE, DELETE) til den ny bruger. Rettighederne kan man finde ved at kigge i kode og prøve sig frem. Det er sjældent særlig svært. Vær restriktiv og tildel kun de rettigheder, som skal være der. Pakker, der mangler, kompilerer man også på runbrugeren, og det giver så anledning til flere objekter, der skal gøres kendt. Til sidst har man gnavet sig gennem det hele og alle nødvendige objekter er defineret hos runbrugeren. Hermed har man en oversigt over, hvilke objekter og tilhørende rettigheder, batchafviklingen kræver. De ses fra runbrugeren ved: select table_name,privilege from user_tab_privs order by 1,2; Udvidelse af begrebet Ideen om at eksportere data fra produktion og importere til test i særlige skemaer kan selvfølgelig bruges i andre sammenhænge. I det ovenstående er der entydigt fokuseret på batchafvikling, og normal manuel test er henvist til MAIN. Men man kan godt lave paralleltest med dobbeltindtastning, hvor brugerne sidder med en stak blanketter, de skal taste ind. Først eksporterer man fra produktion for at lave GL1. Så taster brugerne oplysningerne ind. Så eksporteres der til GL2. GL1 konverteres til NY1. Brugerne taster igen, de samme oplysninger i NY2. Det er næsten kun fantasien (og plads), der sætter grænser for, hvad man kan gøre og hvor mange skemaer, man har, og hvorfor man gør, som man gør. Hvis du skal have frisket dine Forms-billeder op OracleEkspert Oktober 2002 7
Fax eller send kuponen til: Pythia Information Kongensvej 3 2000 Frederiksberg Fax: 26199991 Eller bestil via vores hjemmeside: ABONNEMENT Ja tak, jeg ønsker: http://www.oracleekspert.dk Eller e-mail nedenstående oplysninger til: salg@oracleekspert.dk OracleEkspert nr 1 - DKK 125,00 pr stk...dkk OracleEkspert nr 2 - DKK 125,00 pr stk...dkk OracleEkspert nr 3 - DKK 125,00 pr stk...dkk OracleEkspert nr 4 - DKK 125,00 pr stk...dkk OracleEkspert nr 5 - DKK 125,00 pr stk...dkk OracleEkspert nr 6 - DKK 125,00 pr stk...dkk OracleEkspert nr 7 - DKK 125,00 pr stk...dkk OracleEkspert nr 8 - DKK 125,00 pr stk...dkk OracleEkspert nr 9 - DKK 125,00 pr stk...dkk OracleEkspert nr 10 - DKK 125,00 pr stk...dkk OracleEkspert nr 11 - DKK 125,00 pr stk...dkk OracleEkspert nr 12 - DKK 125,00 pr stk...dkk OracleEkspert 2000 - DKK 300,00 pr stk (3 numre)...dkk OracleEkspert 2001 - DKK 600,00 pr stk (6 numre)...dkk OracleEkspert 2002 - DKK 600,00 pr stk (6 numre)...dkk 1 års abonnement (6 numre) - DKK 600,00 pr stk...dkk Jeg vil gerne begynde abonnementet med OracleEkspert nr: - 40% ved samtidig køb af minimum 5 ens blade eller abonnementer...dkk - 45% ved samtidig køb af minimum 10 ens blade eller abonnementer...dkk - 50% ved samtidig køb af minimum 20 ens blade eller abonnementer...dkk - 60% ved samtidig køb af minimum 50 ens blade eller abonnementer...dkk Bemærk: Når abonnementerne købes med mængderabat bliver alle blade sendt i én samlet forsendelse. Det er altså ikke muligt at få bladene sendt til individuelle modtagere. Pris i alt Firma:...DKK Priserne er excl moms. Navn: Adresse: Postnr/By: Land: E-mail: Refereret af: Adresse: Postnr/By: Ved hver tegning af minimum 1 års abonnement på OracleEkspert sender vi et stk signeret kvalitetskopi af Oraclerne til den læser, som har refereret den nye abonnent til os. Kopien er trykt på kraftigt papir. Den er nummereret og signeret med rød tush. En OracleEkspert-læser er en person med eget abonnement eller en person ansat i et firma, som har tegnet abonnement på OracleEkspert. Man kan ikke referere et abonnement til sig selv. Som referencegave ønskes en signeret kopi af Oraclerne fra OracleEkspert: Nr 1 Det er fordi de ikke kan li fremmednøgler... [ ] Nr 2 Det er jo også vores Designer mand... [ ] Nr 3 Har du prøvet at skifte din Where-clause ud med en Santa clause?... [ ] Nr 4 Pro*C... [ ] Nr 5 No more table space...[ ] Nr 6 Komme i Forms...[ ] Nr 7 Rodeo...[ ] Nr 8 Joins...[ ] Nr 9 Triggere...[ ] Nr 10 6i...[ ] Nr 11 KageForms...[ ] Nr 12 Vi har flyttet CASE-strukturen ind i kernen...[ ] Nr 13 Så skulle du bare have set de 1999 der kom før...[ ]
FGAC, FGA OG MV? Af Martin Jensen - Oracle Consulting. Martin har siden 1982 arbejdet med bl.a. Oracle s database-kerne, samt med forskellige aspekter af objektorienteret systemdesign. Fine Grained Access Control (FGAC) er grundfaciliteten bag Oracle s Virtual Private Database (VPD) koncept. Materialized views er Oracle performance booster i forbindelse med tuning af agregerede forespørgsler i datavarehus-agtige sammenhænge. Og Fine Grained Audit (FGA) er (i Oracle9i EE) Oracle s nye mulighed for at auditere selects mod følsomme områder i databasen. Hvordan er det nu disse 3 faciliteter arbejder med hinanden? Antag at man haver en velvoksen tabel (bigemp), hvorpå der er defineret både FGA og FGAC politikker. Antag også at der på denne tabel er defineret et Materialiseret view (bigmv1), hvor kolonnerne der anvendes af FGAC politikken er bevaret. Hvis man nu sender select-sætninger mod tabellen vil politikkerne naturligvis virke, men hvad nu hvis en select-sætning netop genkendes af optimizeren som en der kan omdirigeres mod det materialiserede view, vil de to politikker så fortsat virke? Jamen lad os prøve. Først opretter vi lige en af de nye pipelined funktioner, der kan returnere et data-sæt: create or replace type t1_rec_typ as table of Number; create or replace function counter( start_no Number, offset Number ) return t1_rec_typ pipelined is begin for i in start_no.. start_no+offset-1 loop pipe row( i ); end loop; return; end; Så anvender vi den til at oprette tabellen bigemp der får 1.400.000 rækker, hvorefter vi opretter et materialiseret view (bigmv1) hvor attributten deptno er med: create table bigemp as select * from emp, table( counter( 1,100000 )); create materialized view bigmv1 build immediate refresh complete enable query rewrite select deptno, sum( sal ) sum_sal, count( * ) cnt from bigemp group by deptno; vi let kan se hvilke der anvendes: declare begin dbms_fga.add_policy( object_schema => 'system', object_name => 'bigemp', policy_name => 'bigemp_use', audit_condition => '1=1'); end; declare begin dbms_fga.add_policy ( object_schema => 'system', object_name => 'bigmv1', policy_name => 'bigmv1_use', audit_condition => '1=1'); end; alter session set query_rewrite_enabled = true; alter session set query_rewrite_integrity = stale_tolerated; Lad os så lige prøve om disse politikker virker: select count( * ) from bigemp; select * from dba_fga_audit_trail order by scn; Jo her blev politikken bigemp-use anvendt. select * from bigmv1; DEPTNO SUM_SAL CNT ---------- ---------- ---------- 10 875000000 300000 20 1087500000 500000 30 940000000 600000 select * rom dba_fga_audit_trail order by scn; Og her blev politikken bigmv1_use anvendt som den skulle. Men lad os så prøve med en select som bør kunne omdirigeres: set autotrace on select deptno, sum( sal ) sum_sal, count( * ) cnt from bigemp group by deptno; DBA Teknisk Artikel execute dbms_stats.gather_table_stats ( system, bigemp ); execute dbms_stats.gather_table_stats ( system, bigmv1 ); Planen bekræfter at select-sætningen blev omdirigeret fra bigemp til bigmv1. Lad os så oprette en FGA politik på de to tabeller, så OracleEkspert Oktober 2002 9
select * from dba_fga_audit_trail order by scn; Men her det er fortsat FGA politikken bigemp-use der anvendes! Lad os så prøve at krydre med lidt FGAC. Først skal vi have et context element, samt en pakke, der f.eks. binder dname og SALES sammen: create context bigemp using sec_ctx; create or replace package sec_ctx as procedure set_emp_id; end; create or replace package body sec_ctx as procedure set_emp_id is begin dbms_session.set_context ( 'bigemp', 'dname', 'SALES' ); end; end; Så skal vi have en pakke med en funktion, der kan returnere den dynamiske where-clause, vi automatisk vil have databasekernen til at sætte på alle sætninger mod udvalgte tabeller: create or replace package reg_security as function reg_sec ( d1 Varchar2, d2 Varchar2 ) return Varchar2; pragma restrict_references( reg_sec, wnds ); end; begin dbms_rls.add_policy ( 'system', 'bigemp', 'reg_policy', 'system', 'reg_security.reg_sec', 'select' ); end; execute system.sec_ctx.set_emp_id; Lad os så prøve igen med vores agregering mod bigemp: select deptno, sum( sal ) sum_sal, count( * ) cnt from bigemp group by deptno; DEPTNO SUM_SAL CNT ---------- ---------- ---------- 30 940000000 600000 Se execution plan på figur 1. Jamen det virkede jo fint. Vi fik kun informationer fra department 30, og sætningen blev omdirigeret til bigmv1. Øvelsen har også antydet at mekanismen omkring materialised view redirect ligger længere inde i kernen end aktivering af FGA og FGAC politikker. create or replace package body reg_security as function reg_sec ( d1 Varchar2, d2 Varchar2 ) return Varchar2 is begin return( 'deptno in ' '(select deptno from scott.dept ' 'where dname = ' 'sys_context( ''bigemp'',''dname'' ))' ); end; end; Lad os så oprette en FGAC politik med denne procedure på tabellen bigemp, samt sætte context så vi fra nu af kun ser SALES : Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1Bytes=30) 1 0 FILTER 2 1 HASH JOIN (Cost=3 Card=1 Bytes=30) 3 2 TABLE ACCESS (FULL) OF 'DEPT' (Cost=1 Card=1 Bytes=22) 4 2 TABLE ACCESS (FULL) OF 'BIGMV1' (Cost=1 Card=3 Bytes=24) select * from dba_fga_audit_trail order by scn; Figur 1. Execution Plan 10 Oktober 2002 OracleEkspert
Kryds&Tværs 1 7 10 12 17 27 31 D 1 1 1 1 1 6 1 1 2 3 4 5 13 0 8 1 9 S S S 9 9 A 9 19 27 H 20 H P 21 C A T 22 D L H 23 26 24 T I M E 25 I T E R A T E S 27 N I 1 8 1 1 36 3 3 3 O R 4 X M L 1 35 C O R U P T 1 38 3 41 R O M 9 I I 40 O O O O M 42 E 42 43 34 44 45 42 W E B S E R V I C E 42 R 42 34 4 46 N A I O U G 48 C 7 I R C U S 3 7 0 W I G O R A N D D U A A P N E 12 1 A 4 R O L L E D 16 D O C O P E N H A G E N 28 E L 3 2 D X T 34 P 29 U P 30 43 49 N N N 43 43 43 Q 43 P 43 43 43 E U L A S V E G A S R 15 R D A W Vertical: 0: VP of Oracle Development Tools 1: Organizational Revue 2: Most used Web Server 3: Don t start 4: SQL keyword 5: Product Manager of Designer 6: It was joined to the others 8: Operator 9: Let go 12: Running 13: It is not really NULL 15: Without it in the world Oracle would not exist 19: Operating system 20: Location of next ODTUG conference 21: One 22: Catch 23: Software 25: 150 26: Holyday 27: If you have too much work you can... 28: Oracle CEO 29: Unix flavour 30: Candy 31: Operator 35: Organization 36: Programming method 38: Evil 40: Cooperating countries 41: Interface 43: Catalog for executable files 44: Communication technology 45: Enterprise Resource Palnning Horisontal: 7: Pascal keyword 8: A starting point 9: Two of the same 10: An argument for the <PRE> tag 11: He is in a fixed position 13: For unexpected value 14: It was not folded 16: Make something 17: The largest super computer of the universe 18: Location of Oracle World Conference 20: Hardware company 21: New communication type 24: Important parameter when optimizing code 25: A loop 28: MS Windows version 29: Above 30: Oracle data type 31: A very small table 32: The ODTUG Conference was held here 33: Operator 34: A Language 35: You don t want to see your data like this 37: Memory 39: Two of the same 40: Four of the same 42: According to Microsoft this will solve all problems 46: Not applicable 47: An Oracle user group 48: Entertainment 49: Three of the same Løsning for Kryds & Tværs fra OracleEkspert nr 13 Vindere: (der var desværre ingen besvarelser) 12 Oktober 2002 OracleEkspert
24. september 2002 Orange Danmark køber RAC Orange har købt en 9i RAC-løsning baseret på HP servere til at håndtere alle deres self service applikationer for alle deres webkunder. 20. september 2002 Larry Ellison træder tilbage Larry Ellison har valgt at træde tilbage fra Appels Board of Directors, hvor han har siddet i de sidste fem år. Han begrunder sin fratræden med at han ikke har tid til at deltage nok i de faste møder. I stedet har han tilbudt at rådgive Steve Jobs og resten af Appels ledelse på uformel basis, hvilket Steve Jobs har udtrykt glæde for. 18. september 2002 Oracle og Intel annoncerer Bio-Key BIO-key internaltional annoncerede i dag at de vil præsentere en ny INS biometrisk teknologi til at håndtere immigranter, der ankommer i og forlader USA, samt til håndtering af adgangsrettigheder for medarbejdere. BIO-keys WEB-key system, som kan identificere personer via fingeraftryk er baseret på Intel Itanium processorer og Oracle9i RAC og Oracle9i Application Server. Denne integrerede løsning giver hurtig, skalerbar og pålidelig identification, som vil kunne eliminere behovet for passwords i Oracles systemer. Denne teknologi vil på sigt kunne eliminere faren for identitetstyveri. 17. september 2002 Oracles Q1 regnskab Oracle annoncerede en omsætning på USD 2 mia og et overskud på USD 386 mill (USD 0,07 pr aktie). Sidste år tjente Oracle USD 511 mill i første kvartal (USD 0.09 pr aktie). Samtidig er Oracles andel af databaser i virksomhedssystemer steget med 12%, mens Microsofts andel kun er steget med 4%. IBMs andel er faldet med 27%. 16. september 2002 Oracle TPC-C verdensrekord 2 Oracle har lavet en ny TPC-C 32- processor Benchmark verdensrekord på Linux med en Oracle 9i release 2 database og Real Application Clusters (RAC). Opstillingen nåede 138362 tpmc og en pris på USD 17.21 pr tpmc på et cluster på otte noder med Intel pentium III Xeon procesorer og Red Hat Linux Advanced Server. Med samme mængde RAM pr CPU ydede Oracle/Linux 14% mere end det bedste resultat på en Microsoft SQL Server 2000. Oracle er hermed førende på TPC- C 32-processor cluster på både Linux og Windows 2000. 26. august 2002 Oracle TPC-C verdensrekord 1 Oracle9i release 2 på en HP Superdome server slog TPC-C Benchmark rekorden på en enkeltserver med resultatet 423414 tpmc. Det er 2.5 gange mere end Microsoft SQL Servers bedste TPC-C (165218 tpmc) og 27% billigere pr tpmc. Oracle besider nu otte af top ti bedste målinger på TPC-C single server Benchmarken. 26. juli 2002 Oracle valgt som bedste database InfoWorld magazines årlige Readers Choice Award 2002 valgte Oracle9i som den bedste database af 43% af bladets 5200 læsere. Nyheder OracleEkspert Oktober 2002 13
Groans Fra Mogens Kære læser! Velkommen til den tredje udgave af min klumme. Formålet med klummen er at informere om Oracleverdenen, give råd og tips, fortælle om arrangementer, mv. Alt sammen selvfølgelig tilsat private meninger, rene gætterier, usubstantierede rygter og ikke mindst løse formodninger. Egentlig skulle denne udgave have været rigtig, rigtig teknik-tung, men så skete der jo lige et par småting, som alligevel var for interessante til at ignorere Emnerne denne gang: Opfølgning på sidste nummer. Gang i den for nogen. Fest for de Fyrede (eller: Hvordan der er pludselig at være udenfor Firewall en). OakTable på Oracle World i San Francisco. Fødselsdag. Sys.dual. Break/Reset-events. Pga_Aggregate_Target. Audit af remote connections. To batchjobs per cpu også med Oracle PX. Fremragende artikel om 10053. File/block to object mapping på en ny måde. I næste nummer: Support igen-igen. Og andet. Venlig hilsen, Mogens Nørgaard Små og store nyheder Oracle Danmark har startet et projekt, der skal give øget fokus på kunden. Sælgere og supportere vil sammen (i nogle arbejdsgrupper) kontakte de store/vigtige kunder og se, hvad de kan gøre for dem. Supporterne er blevet assignet nogle bestemte kunder, som de så skal følge tæt. Det vanskeliggøres i nogen grad af det faktum, at mange supportkald tages af udenlandske supportere. Men det er et godt initiativ. Gang i den for nogen Jeg ved ikke, hvad der sker og hvorfor men i Miracle kan vi i hvert fald mærke en ordentlig optur. Når jeg taler med folk fra andre konsulentvirksomheder siger de, at det stadig er hårdt, og at de ikke kan mærke nogen rigtig bedring endnu. Omvendt kan de heller ikke mærke, at det bliver værre. Men vi har haft det forrygende det sidste stykke tid. Vores regnskabsår (slut 30/6) havde overskud, juli gav overskud (det er ellers svært i en løntung biks) og august har været vores bedste måned nogensinde. Det er ikke fordi vi ikke kan lide, at det er sådan vi forstår bare ikke hvorfor det pludselig går så vældigt godt for nogen og ikke for andre (specielt de store). Jeg ved, at et firma som Platon (ca. 40 mand, fortrinsvis Business Intelligence) har meget gang i den. Henrik fra Component Software fortæller også, at de har haft fantastisk travlt de seneste måneder. Det må være tid til nogle spekulationer. For mig ser det ikke ud som om der startes en hel masse nye projekter op et faktum, der også reflekteres i softwaresalget, som stadig er hårdt ramt. Men en række projekter, som har været bevilget, og som så har været i dvale pga sommerferie og de festlige begivenheder generelt i det sidste års tid, skal nu startes op og gerne fuldføres på rekordtid. Og pludselig har man brug for nogen, der kan levere i en fart. Det ser ud som om drømmen om GUS Great Unifying System opgives i denne tid til fordel for løsninger, der kan løse problemer her og nu. Med andre ord: Ledelsen i virksomhederne accepterer (igen) øer i deres systemer bare de kan få løst nogle problemer. Det giver tilsyneladende lidt luft til dygtige teknikere og håndværkere lige nu. Hvorimod jeg tror, at forandringskonsulenter og den slags skal indstille sig på, at det nok ikke bliver i år der kommer rigtig gang i den igen. Gartner Group sagde i efteråret sidste år, at der først ville komme et opsving i 3. kvartal 2003. Måske får de ret hvis de gør er jeg imponeret. En af mine gode venner har i mange år anvendt en anden indikator: Når salget af erhvervsbilletter hos et bestemt rejsebureau stiger med et par procent, så går der et par måneder og så er der gang i den. Hvis den teori er rigtig, så sker der gode ting måske først i Pharma-branchen i slutningen af oktober i år. Hvis min gode ven får ret så bliver jeg endnu mere imponeret. Hold jer fra telebranchen generelt (eller vær bare lidt omhyggelige med jeres fakturering) lidt endnu. Telco-crashet er minimum 10 gange større end dotcom-crashet hvad angår værditab, og vi har ikke set de fulde konsekvenser herhjemme endnu. Både Orange og Telia har tabt en milliard om året i nogle år. En masse mindre firmaer har bare ikke noget kundegrundlag. Der må ske en konsolidering før eller senere. Der ansættes lidt folk hist og pist, men det er ikke meget. Headhunterne rapporterer dog om stigende interesse specielt lige nu i gode Apps-folk med f.eks. AR-erfaring (Arfaring?). Mange af vennerne, der lavede Mercedes-løsningen (det er Peter Grams udtryk, tror jeg), dvs. gik selvstændigt og scorede kassen under dotcom- og telco-boomene, er krøbet i ly vha fastansættelser hos deres faste kunder og i de store konsulentbikse eller har det skidt. En gammel regel, som vi har lært af erfarne folk som Ole Frejlev, er at når det går allerbedst skal man være allermest aktiv med at sælge sig selv til næste opgave. Mange tog det helt afslappet med de tilbud de fik i foråret, fordi de var i arbejde. Det var så pludselig ikke, og sommeren har vist været både lang og varm for mange. Men summa-summarum: Det er tid til svag optimisme. Der er altid projekter, der skal gennemføres. Der er altid infrastruktur, der skal forbedres. Dygtige folk vil der altid være brug for. Men GUS er nok død for nuværende. Ingen 14 Oktober 2002 OracleEkspert
bestyrelser kan overskue at gå hele organisationen igennem, hvilket man jo er nødt til, hvis man skal lave den store, forkromede ERP-løsning. Fest for de Fyrede (eller: Udenfor Firewall en) For nogle uger siden fyrede Oracle i alt 26 medarbejdere, heraf 19 fra Consulting og 6 fra Salg. Det skete i to omgange, idet tre af de 19 fra Consulting lige skulle komme hjem fra sommerferie. Som HR-chef Anette Landberg udtrykte det: Vi fyrer ikke via Postvæsenet. Det var også nødvendigt ud fra et økonomisk synspunkt. 42 (det er jo et godt tal og Svaret) i snit har været på bænken i Consulting i de sidste par måneder. Ud af ca. 130. Det kan ingen organisation holde til i længden, og tilpasningen burde formentlig have fundet sted for et godt stykke tid siden. Oracle gør diverse tiltag for at få de fyrede placeret hos partnere m.fl. og har fået en del henvendelser på den måde. Godt initiativ. Flere af de fyrede har allerede jobs og flere skal til samtaler snart. Det skyldes tror jeg to ting: Man har et godt ry (hvis man ikke har gjort sig altfor dårligt kendt) når man kommer fra Oracle og det er i vid udstrækning meget kvalificerede folk, der er blevet fyret. Det sidste punkt vender jeg lige tilbage til senere. Dagen efter den første (store) fyringsrunde sad jeg i haven på Kratvej med et par nuværende og en netop fyret Oracle-medarbejder(e). Her opstod ideen så om at holde en WTFF Whisky Til Forretten Fest for de fyrede. Så kunne WTFF for en gang skyld stå for Whisky til de Fyrede Fest. Og hvilken bedre dato at gøre det på, end fredag den 13.? Det ville tillige være en mulighed for de fyrede for at mødes og vende begivenhederne sammen. Som sagt så gjort. De fyrede og nuværende og tidligere Oracle-medarbejdere og andre gode venner fra miljøet, inkl. Headhuntere, blev inviteret til min hjemmelavede chili con carne og øl, der enten stammede fra Thy Bryghus eller var i tyske rend-migi-svend-auken dåser. Og selvfølgelig whisky til forretten (som vi sprang over). Der kom lidt over 80 gæster den fredag i haven på Kratvej, og de sidste gik ved 4-tiden. Det blev spist ca. 40 kg chili con carne (ud af de 60 jeg havde lavet) og 50 hvidløgsflutes, drukket en masse øl, tømt fem flasker whisky og endda danset lidt på terrassen til Thomas Helmig s Stupid Man og andre klassikere. Der blev snakket. Ikke om Microsoft. Ikke om IBM. Ikke om Nyrup eller Afghanistan eller Iraq eller parforholdets (for IT-folk temmeligt permanente) krise. Så er der vel kun eet emne tilbage. Uden for Firewall en Fælles for de fyrede var at de havde fået et nyt syn på Oracle, nu da de pludselig stod uden for Firewall en. Det er et fænomen, som jeg naturligvis selv følte for fuld udblæsning efter 10 år i firmaet, så det er da skægt, at andre også har det på den måde. Lad mig prøve at beskrive det lidt provokerende (surprise!). Når man befinder sig indenfor Firewall en, dvs. er ansat hos Oracle, er verden udenfor generelt befolket af folk, der ikke ved lige så meget som én selv. Og Oracle er vejen, lyset og sandheden. Der er generelt en rigtig god firmaånd i Oracle og omvendt æder firmaet sig også ind på én og stjæler meget af den tid og energi man har. Når man en dag befinder sig udenfor Firewall en (frivilligt eller ej) får man tit et mindre chok når man opdager, hvordan man ser på Oracle udefra. Det var det, der efter få dage var gået op for flere af de fyrede. Hvordan ser man så på Oracle udefra (igen sat på spidsen, naturligvis, men også pakket lidt ind)? Hovedsaligt kan opfattelserne (rigtige eller forkerte) grupperes i to påstande: Oracle er vanskelige at gøre forretning med. Som partner skal man passe meget på med at bringe Oracle ind på projekter. Er Oracle vanskelige at gøre forretning med? Nej og Ja. Ingen tvivl om, at Oracle meget gerne vil sælge licenser og service-ydelser lige nu. Consulting har slækket på en del krav de havde i de glade dotcomog telco-boom-dage (såsom at de kun ville være med, hvis de havde projektansvaret). Sælgerne ved godt, at priserne på markedet for konsulenter og software er under pres, omend Consulting har svært ved at håndtere det faktum lige nu pga globale prispolitikker og enorme krav om lønsomhed (margin). Men det er og har altid været vanskeligt, hvis man skulle lave noget med Oracle, der involverede flere afdelinger. Her er man som kunde meget afhængig af at kunne finde en sponsor eller tovholder indenfor Firewall en, der holder fast i og løber rundt og koordinerer. Det kan være en meget vanskelig opgave pga. de forskellige Lines of Business (LOB er) og deres individuelle mål og interesser. Skal man som partner passe på med at bringe Oracle ind på projekter? Nej og Ja. På projekter, der f.eks. involverer kompliceret brug af ERP-moduler eller helt nye produkter (som Portal 2.0) kan det være en simpel nødvendighed at have Oracle-folk ombord både for at kunne få den nyeste viden og for at sikre, at evt. bugs kan få den fornødne attention hos Oracle (det hjælper med andre ord, hvis Oracle-ansatte fortæller om den businessimpact en fejl eller mangel har for Oracle s forretning og for kundens). Omvendt træder arrogancen (alle uden for Firewall en ved mindre end vi gør) nogle gange frem, når der er Oracle-folk på projekter til stor irritation for de partnere, der bragte dem ind. Og der skal ikke mange sådanne hændelser til før Oracle får et dårligt ry. Det er en branche med megen (og effektiv) kommunikation. Så er der det helt selvstændige problem med Oracle, der går udenom partnerne og direkte til kunderne. Men det har vi jo talt om i en tidligere klumme. De velkvalificerede Jeg lovede at vende tilbage til det lidt underlige faktum, at mange af de fyrede konsulenter faktisk både var i arbejde og havde rigtigt gode kvalifika- OracleEkspert Oktober 2002 15
tioner. Det er jo meget imponerende CV er flere af dem kan fremvise og pæne anmeldelser fra kollegerne. Flere af dem var tillige fuldt fakturerende. Et gyldent øjeblik ved WTFF var da en konsulent dukkede op og pænt præsentere sig for de andre fyrede. De kendte ikke vedkommende! Det viste sig at være fordi vedkommende havde været i fuldt arbejde hos en kunde under hele sin ansættelsestid hos Oracle, og derfor ikke havde været ude i Oraclebygningen særligt meget. Men hvorfor blev de så fyret? Udover, at der selvfølgelig kan være helt legitime grunde vi andre ikke kender til eller kan se (samarbejdsproblemer eller hvad ved jeg), så var den gængse opfattelse blandt fyrede og iagttagere, at fyringerne afspejler en drejning af Consulting henimod Apps. Det var relativt få Apps-folk og relativt mange teknik-folk, der blev fyret. Et pænt stort Apps-projekt er da også på vej (det er underskrevet og burde give en del arbejde til Appskonsulenterne hos Oracle), men om det er nok til at Consulting får rettet op på skuden er uklart for mig. Mange af de fyrede bliver nu en del af det store Oracle-netværk som findes uden for firewall en. Jeg hjælper gerne med formidling af kontakter. OakTable på Oracle World i San Francisco. Sør me om ikke vores stand på Oracle World i København var så stor en succes at Oracle Marketing i USA har foræret os en stand med det hele (og endda noget større end den vi havde i København), hvis vi gider flyve derover og optræde i dagene 11-14. november i år. Det gider vi godt. Det bliver mig, Lasse, Gram og en overraskelse, der tager derover. Cary har fået afslag på sit indlæg til konferencen, så han vil også gerne sidde på standen. Der dukker nok også nogle andre OakTable-medlemmer op, skal I se. Vi har en ny (og endnu mere vanvittig) ide til et laptop RAC-cluster, og vi regner også med at køre The Challenge som sædvanlig. Hvis I har andre ideer, der kan bruges, giver vi en Challenge-trøje som tak. Det vil koste enten to måneder med skib eller to millioner kroner at få fragtet mit egetræsbord derover, så det har vi droppet (primært pga. tiden, forstår I). Vi må prøve at finde et godt egetræsbord i området hos venner og bekendte. Fødselsdag Husk, at Miracle A/S fylder to år fredag d. 1/11 (det er da en dato man kan huske), og at vi som sædvanligt vil have Farlig Fredag om eftermiddagen efterfulgt af mad, drikke og musik (og måske lidt underholdning?) hele aftenen i Pederstrup i Ballerup Kommune. Som vanligt finder vi nok også ud af overnatningsmuligheder for jyder og andre gode mennesker. Tegn allerede nu en tysk øldåse i kalenderen den dag. Tekniske noter fra OakTable Det må være på tide med lidt tekniske noter og hints. På vores interne OakTable-mailingliste foregår der nogle interessante diskussioner, hvoraf nogle af dem vil blive omtalt her. Vi har iøvrigt OakTable-websiden under omdannelse til et lidt venligere format med nogle muligheder også for andre end OakTable-medlemmerne, og skal ved Database Forum i Middelfart (en uge fra denne skrivende stund) tale om, hvordan ideen med OakTable kan bruges til fælles glæde for vennerne ude i Oracle-verdenen. Sys.dual. Der er en note i 9iR2 s release notes (for Windows det står ikke i Linux-udgaven?) om at opdateringer af sys.dual ikke er en god ide heller ikke med SELECT FOR UPDATE. Det anbefales af bruge dbms_lock i stedet til concurrency control. Det skyldes, at dual allerede nu behandles specielt i Oracle-koden og endnu mere specielt i kommende releases. Bl.a. er det ikke mere muligt at have mere end én række i denne traditionstunge og meget succesfulde tabel. Tak til Gram for heads-up en. Break/Reset-events. Joakim Treugut (svensker bosat i New Zealand og medlem af OakTable bemærk det tabel-navn han bruger nedenfor) har kastet et interessant lys over denne event, som jeg i hvertfald ikke har anet noget om. Jeg giver ordet til Joakim fra en mail: You will get a SQL*Net break/reset to client (with parameter1, break?, set to break) when something happens that stops the "normal flow". For example, you select from a table that doesn't exist or you don't have priviliges to read. You encounter an error (like inserting duplicate keys). Here I select from a table that doesn't exist: PARSE ERROR #3:len=20 dep=0 uid=5 oct=3 lid=5 tim=2350578000 err=942 select * from kalle WAIT #3: nam='sql*net break/reset to client' ela= 203 p1=1111838976 p2=1 p3=0 WAIT #3: nam='sql*net break/reset to client' ela= 194 p1=1111838976 p2=0 p3=0 WAIT #3: nam='sql*net message to client' ela= 12 p1=1111838976 p2=1 p3=0 WAIT #3: nam='sql*net message from client' ela= 6582942 p1=1111838976 p2=1 p3=0 So first I get a BREAK and then I get a RESET (check p2). Here I insert a key that already exist 16 Oktober 2002 OracleEkspert
PARSING IN CURSOR #3 len=47 dep=0 uid=5 oct=2 lid=5 tim=2397484000 hv=1466643880 ad='785587ec' insert into scott.dept values(10,'hej','d' ) END OF STMT PARSE #3:c=1468750,e=2125000,p=4,cr=54,cu=0, mis=1, r=0,dep=0,og=4,tim=2397484000 WAIT #3: nam='db file sequential read' ela= 18346 p1=1 p2=61312 p3=1 WAIT #3: nam='db file sequential read' ela= 4311 p1=1 p2=61313 p3=1 WAIT #3: nam='db file sequential read' ela= 2766 p1=1 p2=61316 p3=1 EXEC #3:c=234375,e=469000,p=8,cr=9,cu=8, mis=0,r=0,dep=0,og=4,tim=2398031000 ERROR #3:err=1 tim=239804 WAIT #3: nam='log file sync' ela= 343 p1=59 p2=0 p3=0 WAIT #3: nam='sql*net break/reset to client' ela= 197 p1=1111838976 p2=1 p3=0 WAIT #3: nam='sql*net break/reset to client' ela= 203 p1=1111838976 p2=0 p3=0 WAIT #3: nam='sql*net message to client' ela= 11 p1=1111838976 p2=1 p3=0 WAIT #3: nam='sql*net message from client' ela= 6203813 p1=1111838976 p2=1 p3=0 ===================== So I guess that these two messages are the server's way to sync the communication with the client when an error is raised. If your client is using 9i, you can check in v$sysstat "parse count (failures)" to see if they try to parse statements where columns/tables are unknown. "parse count(failures)" does NOT increase if you send SQL with invalid syntax - it looks like only semantic errors makes it increase. Pga_Aggregate_Target. Denne parameter har to anvendelser. Igen cut/pastet fra en OakTable-udveksling mellem Tim Gorman, Jonathan Lewis, og andre: PGA_AGGREGATE_TARGET has 2 effects: To batchjobs per cpu også med Oracle PX. Specielt med denne her nye Parallel_Automatic_Tuning (PAT) parameter og de nye, såkaldte Server Groups, er der opstået nye muligheder for at lægge systemet ned. Husk at læse Cary s artikel (findes stadig på Hotsos) om, at man skal have to batchjobs per cpu (max to, som Martin Jensen altid har sagt), og det gælder altså også PX-agtige miljøer. En Degree of Parallelism (DOP) på 2 per cpu skal altså overholdes, med mindre man vil have rigtigt sjove performance-udsving på sit system. Fremragende artikel om 10053. Der er en meget, meget god artikel af Wolfgang Breitling om event 10053, der kan fortælle dig, hvad optimizeren (CBO en) overvejede og hvordan den nåede frem til sin konklusion. Artiklen er faktisk så god, så Cary straks inviterede forfatteren til at holde indlæg på Hosos Symposiet i februar i Dallas. Den er på forsiden hos www.hotsos.com. File/block to object mapping på en ny måde. Standardmåden at mappe fil/blok-numre til et objekt i Oracle på er for langsom med LMT (Locally Managed Tablespaces). Men der er en ny måde (som måske ikke virker specielt godt i 8i, men i hvert fald gør i 9i) som Anjo påpegede for et stykke tid siden: Man kan bruge V$SESSION.ROW_WAIT_OBJ# - i hvert fald for db file sequential read, db file scattered read og buffer busy wait. 1/ it enables the new realfree PGA memory allocator. This new memory allocator allows us, mainly on UNIX platforms, to really free PGA memory back to the OS. This is not possible if the regular malloc()/free() calls are made. 2/ it enables automatic sizing of workareas, assuming that WORKAREA_SIZE_POLICY is AUTO for the session. Setting WORKAREA_SIZE_POLICY to MANUAL only disables the second effect but you still use realfree of memory. This one is potentially causing more swap space to be reserved (issue only for HP, has been fixed on 9iR2.1). In other words, Jonathan's problem is coming from 1/ and setting WORKAREA_SIZE_POLICY has no effect on this. Audit af remote connections. Hvordan kan man lave audit af remote connections? Efter lidt debat kom man frem til to mulige måder: Comment-feltet i Audit_Trail (når man har slået Audit til). Når man connecter kommer der en entry (hidden transaction), der kan ses I x$ktcxb. En logon-trigger kunne måske checke dette? OracleEkspert Oktober 2002 17
Svar Skriv til: Svar@OracleEkspert.dk 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 nr 14 (oktober 2001) er fredag den 13. september 2002. Har du lavet noget genialt, som kunne have interesse for andre Oracle-udviklere, ledere, planlæggere mv, 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 Når oplæget er godkendt af redaktionen, kan du skrive selve artiklen. Du kan hente en template på vores hjemmeside. 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. Emnet skal blot 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. 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. Tips: Tips, triks, hints og gode råd som trykkes i OracleEkspert, belønnes med et stort hjerte af økologisk marcipan og chokolade. Hvis du feks har fundet ud af hvordan man kan omgå en irriterende bug i et af Oracles værktøjer, hvis du har lavet en fix Select-sætning, der kan vise noget interessant om databasen, eller hvis du har opdaget en fix procedure eller funktion i databasen, så gå ind på: og beskriv det. www.oracleekspert.dk 18 Oktober 2002 OracleEkspert
Deadline for artikler til OracleEkspert nr 15 15. november 2002 Læs mere på www.oracleekspert.dk Oracle User Group Denmark er en selvstyrende gruppe for Oracle-brugere. Det er for tiden gratis at være medlem, dog skal man have en Oracle-databaselicens for at kunne blive medlem. Gruppen består af en bestyrelse og et antal Special Interest Groups, som afholder møder i Oracle Danmarks lokaler i Ballerup. Indkaldelse til møderne sker via brugergruppens mailliste og via brugergruppens web-side (www.oug.dk). OUGDK Stormøde Koordinator: Lone Aalekjær, loaal@wmdata.com Næste møde er endnu ikke fastlagt. DBA SIG Koordinator: Jean-Marc Pedersen Næste møde er endnu ikke fastlagt. Designer SIG Koordinator: Marc de Oliveira, Marc@deOliveira.dk. Forslag til mødeemner modtages meget gerne. Næste møde: 2. oktober 2002 kl. 13:00 hos Oracle Danmark Emner for næste møde: Tips og tricks til Forms Generatoren Tips og tricks til WSG Generatoren OUGDK Developer SIG Koordinator: Lone Aalekjær, loaal@wmdata.com Næste møde er endnu ikke fastlagt. Data warehouse SIG Koordinator: Erik Haar, erh@lundbeck.com Næste møde er endnu ikke fastlagt. Web SIG Koordinator: Måske Benjamin Lund, blf@bellcom.dk (dette er ikke bekræftet endnu) Næste møde er endnu ikke fastlagt. Husk at tilmelde dig til møderne hos Christian.Graversen@Oracle.com (ellers får vi for få kager/vand!!) OracleEkspert Oktober 2002 19