VISIE juni 2003 • Jaargang 8 • Nummer 1 • h 7,50
Vernieuwde OGh website met Oracle Portal
VISIE
Voorwoord
Colofon
Geachte lezer,
Redactie: H. Gerritse (hoofdredacteur) R. Buitenhuis L. Jellema Redactie-adres: Oracle Gebruikersclub Holland Utrechtseweg 48c 3704 HE Zeist Postbus 701 3700 AS Zeist Realisatie: Donath Druk & Prepress bv Tel.: 030 - 69 22 887 Fax: 030 - 69 181 34 E-mail:
[email protected] Organisatie: A.J. van der Weijden BMO bv E-mail:
[email protected] OGh-secretariaat/ advertentie-exploitatie: Utrechtseweg 48c 3704 HE Zeist A.J. van der Weijden Tel.: 030 - 699 70 65 Fax: 030 - 696 23 78 E-mail:
[email protected] Website: www.oracle-usergroup.nl
Met veel genoegen presenteren we hierbij het voorjaars/zomer nummer van OGh Visie van jaargang 8. Belangrijk punt in dit verenigingsjaar is de realisatie van onze nieuwe website www.ogh.nl die vanaf deze zomer onder Oracle Portal gaat draaien inclusief een closed usergroup deel. Elders in dit blad een preview! Ook nu is er weer met enthousiasme aan gewerkt om een gevarieerd aanbod van artikelen en informatie te realiseren. We wensen u veel leesplezier. John Stewart Voorzitter Oracle Gebruikersclub Holland
Inhoud Polynorm deelt kennis en informatie via Oracle9iAS Portal
4
Vernieuwde OGh website op basis van Oracle Portal
7
Van siekwul naar biepul
8
J2EE versus .NET
9
Gebruikersbijeenkomsten/congres Werving sprekers/onderwerpen Th. Koster Conclusion Communication E-mail:
[email protected]
Oracle Collaboration Suite gepresenteerd tijdens seminar
13
Oracle 9iAS Release 2: een korte kennismaking
15
Bestuur OGh Voorzitter J. Stewart Itude Consulting BV Telefoon: 030 699 70 20 E-mail:
[email protected]
Uitslaande brand bewijst waarde calamiteitenplan
17
Op zoek naar verstandelijk vermogen in de cost-based optimizer
18
OGh-jaarcongres ‘Oracle Portal’ op dinsdag 7 oktober
23
Secretaris Th. Rinsema Oracle Nederland bv Telefoon: 030 699 98 13 E-mail:
[email protected] Penningmeester G.G. Timmerman Amis Services bv Telefoon: 030 - 601 60 00 E-mail:
[email protected] Overige Bestuursleden R. Buitenhuis Speedit Amsterdam bv Telefoon: 020 - 630 46 00 E-mail:
[email protected] D.J. Dral Min. v. Landbouw, Natuurbeheer en Visserij Telefoon: 0317 - 476 723 E-mail:
[email protected] Oplage: 9000
In het tweede gedeelte van de avond zal Theo Koster een forumdiscussie met de sprekers leiden. Hierin zal uitgebreid de stand van zaken in de markt voor Java worden bediscussieerd: de praktijk van migratie van PL/SQL naar Java.De uitspraken en ervaringen van de sprekers van het eerste gedeelte zullen tijdens deze forumdiscussie tegenover elkaar worden gezet. Uiteraard is iedereen in de zaal van harte welkom deel te nemen aan de discussie. Kortom, wilt u verschillende visies horen over de migratie van Forms naar Java? Kom dan naar de OGh-themabijeenkomst op 3 juli 2003 (toegang alleen voor leden) Schrijf u in via www.oracle-usergroup.nl. Deelname is gratis. ■
VISIE
Copyright 2003 OGh
Op 3 juli organiseert de OGh een heel speciale themabijeenkomst. Tijdens deze avond gaan we nogmaals in op een onderwerp dat vele leden na aan het hart ligt. Deze avond organiseert de OGh namelijk een forumdiscussie over de voor- en nadelen van de migratie van Oracle Forms naar Java. Samen met bekende namen uit de Oracle-wereld kijken we deze avond vanuit meerdere optieken naar deze migratie. Hans Bos zal de discussie op gang brengen met een ‘statement of direction’ over de toekomst van Forms binnen Oracle. Hiermee verwachten we de andere genodigden te prikkelen. Vervolgens zal Ton van Kooten JHeadstart demonstreren en zal er een gebruikerscase worden gepresenteerd met als titel ‘De migratie van PL/SQL naar Java’.
OG
OGh Visie is een uitgave van Oracle Gebruikersclub Holland en wordt verzonden aan al haar leden. U kun t zich aanmelden via de website www.oracle-usergroup.nl of d.m.v het inschrijfformulier achterin OGh Visie en u ontvangt dan automatisch OGh Visie. Ook voor losse (gratis) abonnementen kunt u zich aanmelden via de website.
OGh-themabijeenkomst op donderdag 3 juli Forumdiscussie Forms & Java
3
Knowledge management intranet portal MyPolynorm geoutsourced bij Oracle in VS
Polynorm deelt kennis en informatie via Oracle9iAS Portal olynorm, fabrikant van carrosseriedelen voor de automobielindustrie, heeft een knowledge management portal opgezet om de medewerkers van de verschillende bedrijfsonderdelen en vestigingen wereldwijd in staat te stellen met elkaar samen te werken en kennis en informatie te delen. De intranet portal, die de naam MyPolynorm heeft meegekregen, is gebouwd met Oracle9iAS Portal Release 2, de nieuwste versie van Oracle’s portal product. Polynorm heeft hierbij gekozen voor de ‘Outsourced@Oracle’ oplossing, waarbij de centrale knowledge database en de servers bij Oracle Technologie Outsourcing in Redwood Shores staan. Ook het beheer en onderhoud van de MyPolynorm portal wordt vanuit de VS gedaan.
P
“Binnen Polynorm is er vanwege het werkmaatschappijen grensoverschrijdende karakter van veel projecten en activiteiten een groeiende behoefte om kennis en informatie met elkaar te delen”, vertelt Paul Eltink, Project Manager ICT bij Polynorm en programmamanager voor het project MyPolynorm. “De tools die daarvoor tot de beschikking stonden voldeden niet echt meer. Ook is Polynorm vorig jaar overgenomen door het Oostenrijkse concern voestalpine, en ook daar zijn zusterbedrijven waar we graag mee willen olynorm is gespecialiseerd in het ontwikkelen en produceren van carrosseriedelen voor de automobielindustrie. De materialen die hierbij worden gebruikt zijn verschillende soorten staal, aluminium en vezelversterkte kunststoffen. Naast de productie van complexe ‘klasse A’ buitendelen produceert en ontwikkelt Polynorm ook persgereedschappen voor de automobielindustrie. Polynorm ondersteunt, als directe toeleverancier, de automobielproducenten in alle fasen van het ontwikkelings- en productieproces met haar kennis en kunde op het gebied van projectmanagement, design, engineering, ontwikkeling en productie. Met meer dan 2600 werknemers en 6 productie- en ontwikkelingscentra is Polynorm als globale onderneming ook lokaal aanwezig. Er zijn productie- en ontwikkelingscentra in Nederland, Duitsland, Engeland, de Verenigde Staten en Brazilië. Sinds 1 januari 2002 maakt Polynorm deel uit van het Oostenrijkse concern voestalpine - division motion.
OG
VISIE
P
4
samenwerken. De contacten lopen op dit moment voornamelijk via email, waarbij Microsoft Exchange wordt gebruikt voor document management. Het gevolg is dat alle e-mail servers zo langzamerhand vol beginnen te lopen. We willen uiteindelijk naar één centraal platform, waarop we met elkaar informatie en kennis kunnen delen.” Hosten “In mei vorig jaar is het besluit genomen om te kiezen voor Oracle Portal om hiermee een collaboration platform op te zetten om onze bedrijven met elkaar te laten samenwerken en kennis en informatie te delen”, aldus Paul Eltink. “Tevens zijn als een parallel proces delen van het Corporate netwerk naar IP/VPN gemigreerd. Dit IP/VPN netwerk maakt gebruik van de nieuwste MPLS technologie (Multiple Protocol Label Switching) waarmee we heel effectief gebruik maken van ‘shared services’. Daarnaast is er het streven om in bepaalde gebieden de informatie binnen de onderneming zoveel mogelijk te laten komen in een database op één centrale plek. Met name door de lagere TCO (Total Cost of Ownership) is er gekozen voor het hosten in het @Oracle model.” Zwarte pieten “Een belangrijke reden om dit in handen te geven van één partij was dat we willen voorkomen dat verschillende partijen gaan ‘zwarte pieten’ zodra er ergens problemen optreden”, stelt Paul Eltink. “We hebben gekozen voor Oracle Consulting als outsourcing partner, omdat die als enige voldoende ervaring
heeft met dit nog ‘verse’ product Oracle9i Application Server Portal Release 2. Onze servers staan bij Oracle in Redwood Shores en de support wordt ook vanuit de VS gedaan. We hebben ook Amerikaanse DBA’s, wat overigens zowel voor- als nadelen heeft. Het voordeel is dat ze vanwege het tijdsverschil kunnen werken aan het systeem, terwijl het bij ons nacht is. Nadeel is dat ze voor ons ‘s ochtends en een deel van de middag niet bereikbaar zijn. Vandaar dat we nu om een Europese DBA hebben gevraagd die ons overdag kan ondersteunen. Via de tool MetaLink worden de technical issues beheerd. De issues worden aangemeld - Technical Assistance Request en de Oracle DBA’s gaan daar vervolgens mee aan de slag. Op zich werkt dit systeem prima, hoewel het soms tamelijk lang duurt voordat een probleem wordt opgelost.” Waarom is de keuze juist op het portal product van Oracle gevallen? Paul Eltink: “We hebben ook gekeken naar andere portal-achtige knowledge management producten, maar Oracle biedt toch het meest geavanceerde product en is marktleider wat betreft portal technologie. Overigens was Polynorm zelf geen Oracle gebruiker. Ons moederbedrijf is dat wel en maakt ook gebruik van Oracle Portal. De website voestalpine.com is ook gebaseerd op Oracle Portal, maar dan de oude versie die draait onder Oracle8i. Het feit dat het moederbedrijf kennis heeft van de Oracle portal technologie en die ook gebruikt voor de eigen intranetten, was voor ons een belangrijk argu-
ment om zelf ook voor Oracle te kiezen.” Bij de start van het project is gebruik gemaakt van de portal start-up service die Oracle Consulting biedt. “Dat is een kant-enklaar servicepakket, waarin een aantal standaard features zit om snel tot een werkende portal te komen”, legt Paul Eltink uit. “Vooraf hebben we een aantal interne sessies gehouden met eindgebruikers. Doel was om te komen tot een basisstructuur van het portaal: hoe moet het gestructureerd worden, hoe ga je het inrichten, welke pagina’s moeten erin komen, wat voor categorieën, perspectieven etc.. De content zijn we op dit moment aan het opbouwen. Het betekent ook dat je moet hebben nagedacht over hoe je de content gaat managen - op paginagroep niveau, op paginaniveau. Ook moet je content managers en - eigenaren aanwijzen. Het bedenken van die concepten kost gewoon tijd.” Haarlemmerolie “Met dit proces zijn we vorig jaar rond de zomer bezig geweest, en het heeft tot eind van het jaar geduurd om dat te laten uitkristalliseren. Want het opzetten van een taxonomie - want dat is het eigenlijk, een informatiestructuur - is behoorlijk complex. Het is daarbij ook behoorlijk lastig om zo’n concept als knowledge management portal over te brengen aan de mensen. Sommigen denken dat het een soort Haarlemmerolie is en dat ze met de portal ook interne business processen – workflow - kunnen gaan automatiseren, maar daar is het natuurlijk niet voor bedoeld.”
Succesfactor In totaal telt Polynorm zo’n 1000-1100 beeldschermwerkplekken die allemaal aansluiting krijgen op de portal. Paul Eltink acht het “niet onwaarschijnlijk” dat ook de zusterbedrijven van Polynorm van de portal gebruik gaan maken, waarmee het aantal gebruikers fors zal toenemen. “We zijn gebruikersgroepen aan het maken, en die zijn ook weer gekoppeld aan pagina’s. We proberen om zoveel mogelijk informatie van het portal ‘public’ te maken, dus toegankelijk voor alle Polynorm medewerkers die op MyPolynorm kunnen komen. Pagina’s die vertrouwelijke informatie bevatten zijn alleen maar toegankelijk voor bepaalde groepen medewerkers.” Een belangrijke succesfactor van de portal is volgens Paul Eltink content. “Er moet voldoende interessante content zijn om gebruikers te trekken. Als verlengstuk van content geldt dat net zozeer voor functionaliteit. Er moeten ook de nodige interessante functionaliteiten in zitten, die het werk gemakkelijker maken, waardoor de gebruikers naar de portal toe gaan. We hebben geprobeerd zoveel mogelijk best practices toe te passen op deze site en zullen dat de komende tijd nog verder ontwikkelen.”■
De homepage van MyPolynorm portal.
VISIE
Stap voor stap “Vanaf januari van dit jaar zijn we
Custom-built portlets Nu het implementatietraject is afgerond en de MyPolynorm portal steeds verder gestalte gaat krijgen, toont Paul Eltink zich zeer tevreden over het product Oracle portal zelf en het concept dat er achter zit. “Dit product is beduidend beter dan voorgaande versies, er zitten veel nieuwe features bij. Het feit dat de Oracle database de drijvende kracht achter het portal product is en alle content in één database is opgeslagen, maakt het heel erg krachtig en uitzonderlijk schaalbaar. In theorie kun je er alles mee, is het een zeer flexibel product, maar in de praktijk loop ik wel degelijk nog tegen problemen aan.” Als voorbeeld noemt Paul Eltink een aantal standaard functionaliteiten, zoals portlets, die in de praktijk niet optimaal bleken te functioneren. “Voor een aantal van die portlets, zoals de customer search portlet, de standaard-menu portlet en de page path portlet hebben we nieuwe, custom-built portlets laten maken. Dat heeft veel van de implementatietijd in beslag genomen.” Hij tekent daarbij aan dat dit soort problemen ook bij soortgelijke producten van andere leveranciers voorkomen. “Het concept van de portal is nu eenmaal relatief nieuw en dus nog lang niet zo sterk uitontwikkeld als andere ICT-technologieën die al veel langer bestaan. Wij
zien dan ook nog steeds grote voordelen van dit Oracle product, waarmee we one single instance hebben, één centrale plek waar wij kennis en informatie delen.”
OG
Als belangrijkste doelstellingen van de MyPolynorm portal vat Paul Eltink samen: “Het delen van kennis (marketinginformatie, klanten/concurrentie-analyses en nieuws, automotive nieuws, model life cycle), het delen van (management) informatie (rapporten, prognoses, verkoopstatistieken) en het opbouwen van historische bedrijfsinformatie, zoals projecthistorie, geleerde lessen en expertisegebieden.”
de knowledge management portal stap voor stap aan het uitrollen. In eerste instantie zijn we gestart met het publiceren van marketinginformatie, plus een gedeelte algemene bedrijfsinformatie van onze afdeling Corporate Communications. Op dit moment zijn de sales afdeling, corporate engineering en ook de IT-afdeling bezig een eigen knowledge database op te bouwen. Uitgangspunt is om iedere business unit een plek te bieden op dit portaal. Ook zijn we nu project workspaces aan het inrichten, zodat collega’s in een virtuele projectomgeving met elkaar kunnen samenwerken. Het zal dan ook nog de nodige tijd duren voordat de knowledge database volledig is ingericht, maar de basis is gelegd.”
5
Oracle en Java experts bij uitstek! Dit willen wij graag aan u tonen door middel van onze migratie quickscan en ons J2EE Seminar op 25 juni a.s.
Migratie Quickscan Oracle stopt eind 2004 met de ondersteuning van de client/server ontwikkel- en productieomgeving. Migratie naar de webomgeving Oracle 9i Forms ligt voor de hand, maar wat betekent dit voor u? Om u snel een goed advies te kunnen geven, bieden wij de migratie quickscan aan. Binnen één dag heeft u een advies over het migratietraject van uw applicatie(s). Hierbij maken wij gebruik van checklists en scantools die wij in de loop der jaren hebben ontwikkeld. IT-eye (voorheen Redwood Services) heeft immers al 10 jaar ervaring op migratiegebied.
O R A C L E - D I E N S T E N ,
J2EE Seminar 25 juni 2003 Dit is de datum van het jaarlijkse IT-eye seminar in hotel Figi te Zeist. Tijdens dit middagseminar zullen wij de open standaard J2EE belichten vanuit drie invalshoeken: de gebruiker, de softwareleverancier en de IT-organisatie. In samenwerking met Oracle kunnen wij u gratis deelname aanbieden.
> IT-eye Waterveste 3 3992 DB Houten Nederland T F E I
+31 (0)30 635 45 99 +31 (0)30 635 45 90
[email protected] www.it-eye.nl
Meer informatie over de migratie quickscan vindt u op onze internetsite www.it-eye.nl. Hier kunt u zich tevens inschrijven voor ons seminar.
M I G R A T I E ,
O U T S O U R C I N G
E N
J A V A / J 2 E E
Closed User Group met forum alleen toegankelijk voor leden
Vernieuwde OGh website op basis van Oracle Portal Door Dick Dral n de komende maanden zal de nieuwe website van de OGh operationeel worden. Aanleiding van de vernieuwing was de wens van het bestuur om de website meer interactief te maken. Bovendien wilden we onze website laten draaien met Oracle producten. Grootste verandering is de introductie van een Closed User Group, een gedeelte van de site dat alleen voor leden toegankelijk is. Belangrijkste functionaliteit hierbinnen is het forum, waarop de OGh leden met elkaar kunnen communiceren. Verder komt de OGh Visie in PDF-vorm beschikbaar op de site.
I
Doordat de site is gerealiseerd in Oracle Portal, kan deze beter worden onderhouden door het secretariaat, dat via een webbrowser content kan plaatsen en het overige beheer kan uitvoeren. Dit artikel beschrijft de functionaliteit van de nieuwe site en biedt waar dat interessant is voor Oracle gebruikers ook een kijkje onder de motorkap.
Forum De belangrijkste vernieuwing voor de bezoekers is het forum. Dit is alleen beschikbaar voor OGh leden en biedt de mogelijkheid om met andere leden te communiceren. We willen hiermee tegemoet komen aan de behoefte aan communicatie tussen de leden onderling. Het is echter niet de bedoeling, dat op het forum commerciële activiteiten worden ontplooid, het is alleen bedoeld voor informatie-uitwisseling over Oracle en Oracle producten. Het is mogelijk om vragen te stellen, maar u kunt er natuurlijk ook interessante bevindingen delen. Om toegang te krijgen tot het forum moet worden ingelogd op de Closed User Group. De contactpersoon voor het OGh lidmaatschap krijgt een toegangsnaam plus wachtwoord opgestuurd. Met deze toegang kunnen andere medewerkers worden geautoriseerd. Voor de realisatie van dit forum is gebruik gemaakt van een forum portlet, die van het Oracle Portal Development Center is gedownload. Deze portlet is op een aantal punten
Nieuwe URL Niet alleen de website is vernieuwd, maar er is ook een nieuwe URL! Wie in het verleden www.ogh.nl bezocht kwam uit bij de onderwijsgroep Haaglanden. Doordat de onderwijsgroep van naam veranderde, hadden zij ogh.nl niet meer nodig en waren zij bereid deze domeinnaam aan de OGh over te dragen. Layout De layout is zoveel mogelijk identiek aan de bestaande website gehouden. De site komt wel strakker over, onder andere doordat de consistentie wordt ondersteund via Portal Pages en Cascading Style Sheets. De CSS-stijlen worden automatisch doorgevoerd in de invulformulieren.
VISIE
Beheer Het beheer heeft de nodige aandacht gehad bij het realiseren van deze site. Veel van de processen van het secretariaat lopen tegenwoordig grotendeels via de website. Denk maar aan het aanmelden voor evenementen, het verwerken van adreswijzigingen en veranderingen van lidmaatschappen. De juiste implementatie van deze processen maakte een aanzienlijk deel uit van de realisatie-inspanningen. Speciale onderdelen zijn het versturen van bevestigingen van deelname via e-mail en het exporteren van lijsten in de vorm van Excel bestanden. In de volgende OGh visie zal verder worden ingegaan op de techniek om dit voor elkaar te krijgen. ■
OG
Beeld van forum op de vernieuwde website tijdens de testfase.
aangepast. Zo is een aparte moderator rol gecreëerd, waarmee de inhoud van de items indien nodig kan worden aangepast. Verder wordt de auteur afgeleid van de inlognaam van de gebruiker, dat was een zelf in te vullen e-mailadres in de originele portlet.
7
Column Column
Rick van der Lans
Van siekwul naar biepul
et begon allemaal met SOAP, WSDL en UDDI. Drie standaarden die de basis vormen voor het integreren van applicaties met webservices. In zeer korte tijd zijn deze drie wereldwijd geaccepteerd en door vele leveranciers geïmplementeerd.
H
Maar als het hier bij zou blijven, dan zou het allemaal de moeite niet waard geweest zijn. Dan hadden we vergelijkbare mogelijkheden kunnen realiseren door CORBA of J2EE uit te breiden. Het gaat ook niet echt om deze drie standaarden. Zij vormen slechts het fundament. Het fundament voor de taal BPEL4WS (Business Process Execution Language for Web Services). Deze afkorting dient uitgesproken te worden als biepul of bèpul. De meningen hierover zijn nog verdeeld.
OG
VISIE
BPEL4WS is een XML-taal waarmee de choreografie van webservices gespecificeerd kan worden. Ofwel, het is een taal voor business process management. Maar het toekennen van labels helpt waarschijnlijk niet bij de begripsbepaling. Laten we daarom een voorbeeld geven.
8
Stel dat we een webservice met een SOAP-interface op ons SAP R/3systeem geplaatst hebben, een SOAP-webservice op een stored procedure in de Oracle database en één op een met VisualBasic gebouwde applicatie. Met deze drie webservices willen we een simpel bedrijfsproces implementeren. Door het aanroepen van de eerstgenoemde webservice, kunnen we een bepaalde factuur ophalen. Vervolgens roepen we de VisualBasic applicatie
aan die controleert of de factuur betaald kan worden. Er wordt waarschijnlijk gekeken naar de cashflow-situatie, naar de datum van de factuur en het belang van de toeleverancier. Is alles in orde, dan wordt de identificatie van de factuur samen met alle detailgegevens in de Oracle database opgeslagen en van daaruit wordt de betaling gerealiseerd. Met BPEL4WS kunnen we dit proces formeel specificeren. Welke webservice moet eerst aangeroepen worden, hoe moet vervolgens het antwoord doorgegeven worden aan de tweede, en tenslotte, hoe dient het geheel afgesloten te worden? Tevens kan gespecificeerd worden wat er moet gebeuren als er iets fout gaat. Stel dat de aanroep van de derde webservice niet correct verloopt, moet het dan nog een keer geprobeerd worden, of moet het gehele verhaal afgebroken worden? En uiteraard kent BPEL4WS constructies om de karakteristieken voor transactiebeheer weer te geven. Eigenlijk is het een taal om vanuit verscheidene webservices één webservice te construeren, zonder te hoeven teruggrijpen op low-level programmeertalen, zoals Java, C# of VisualBasic. Deze gecomponeerde webservice kan gestart worden door haar met haar eigen SOAPinterface aan te roepen. Een taal is leuk, maar er zijn ook tools nodig die deze taal kunnen interpreteren en verwerken. Dergelijke tools worden soms wel choreografie engines genoemd. Uiteraard bestaat vergelijkbare functionaliteit al in diverse zogenaamde EAI-tools (Enterprise Application Integration). Alleen ondersteunen deze tools allemaal hun eigen, proprietary
choreografietaal. Het speciale aan BPEL4WS is dat ze niet proprietary is, maar gestandaardiseerd zal gaan worden. De taal is initieel ontworpen door IBM en Microsoft. Ze hebben haar afgeleid van hun reeds beschikbare choreografietalen; WSFL van IBM en XLang van Microsoft. Recentelijk is deze taal als voorstel ingediend bij de Oasis-organisatie om er een echte standaard van te maken. Wat doet Oracle met BPEL4WS? Momenteel is er nog geen implementatie. Maar dat zal heus wel veranderen. Oracle heeft altijd de belangrijke trends gevolgd op het gebied van softwareontwikkeling. Ooit is Oracle begonnen als leverancier van een SQL-databaseserver. Daarna kwamen de rapportage- en ontwikkeltools. Toen de markt begon met CASE-tools, werd Case*Designer geïntroduceerd. En ook de markt van Java applicatieservers is Oracle ingesprongen. De verwachting is dus dat Oracle ook de stap naar choreografieengines zal maken. IBM en Microsoft, de grote rivalen, en wat kleinere leveranciers, zoals Collaxa, Italio, OpenStorm, hebben hun eerste implementaties van BPEL4WS reeds beschikbaar. Gegeven haar positie in de markt en gegeven haar historie zal Oracle niet achter blijven. Wie had ooit gedacht dat, toen Oracle opgericht werd, ze ooit nog eens naast siekwul iets met biepul zou doen? Rick F. van der Lans is onafhankelijk adviseur, auteur en docent gespecialiseerd in databasetechnologie en softwareontwikkeling. ■
J2EE versus .NET Door Gert Jan Timmerman
De vergelijking tussen het Microsoft .Net platform en het J2EE platform stond centraal tijdens de druk bezochte OGh themabijeenkomst eind maart. Gert Jan Timmerman van Info Support gaf tijdens de bijeenkomst uitleg over de achterliggende ‘designfilosofie’, de technische verschillen en overeenkomsten en de architectuur van beide platformen. Voor OGh Visie heeft Gert Jan Timmerman de belangrijkste feiten en conclusies op een rij gezet.
net- of intranetapplicatie en omdat deze zich beter leent voor integratie van verschillende applicaties. Platform Om een multi-tier-applicatie te kunnen bouwen en gebruiken is een geïntegreerde set hardware en (systeem)software nodig. Zo’n geïntegreerde set noemen we een platform. Een platform bestaat (o.a.) uit hardware, operating system, database server, application server, webserver, transaction processing monitor, message queuing software, directory services, database-connectivity software en een wire-protocol. Er zijn op dit moment twee toonaangevende platformen beschikbaar waarmee multi-tier-applicaties gebouwd kunnen worden: Java 2 Enterprise Edition (J2EE) en Microsoft .NET. Beide platformen lijken in veel opzichten op elkaar, maar er zijn natuurlijk ook verschillen. Om meer zicht te krijgen op zowel overeenkomsten als verschillen zullen we beide platformen aan een nauwkeuriger inspectie onderwerpen.
Kern van het J2EE-platform is de taal Java. Deze taal is ooit gedefinieerd door Sun (1995) en werd oorspronkelijk vooral gebruikt om zogenaamde applets te schrijven (dynamische visuele componenten van webpagina’s). Een Java-programma wordt door de compiler niet naar machinecode gecompileerd, maar naar een tussentaal (bytecode). Deze bytecode wordt vervolgens geïnterpreteerd door een Virtual Machine. Omdat er voor verschillende processoren Virtual Machines bestaan die allemaal dezelfde bytecode uitvoeren, is een gecompileerd Java-programma processoronafhankelijk. Om een betere performance te verkrijgen maken sommige Virtual Machines gebruik van een Just-In-Time-compiler (JITcompiler), maar dit is niet verplicht. Omdat bytecode een getypeerde taal is, kunnen er runtime nog allerlei type-controles uitgevoerd worden, waardoor de kans op fouten verminderd wordt. Daarnaast wordt bytecode, voordat ze uitgevoerd wordt, eerst door de Virtual Machine geverifieerd, waarmee wordt vastgesteld of de bytecode aan een aantal strakke regels voldoet. De Virtual Machine is ook verantwoordelijk voor het opruimen van het geheugen dat niet meer gebruikt wordt (Garbage Collection). Hoe vaak en wanneer deze opruimactie plaatsvindt, bepaalt de Virtual Machine zelf. Dankzij de J2SE, een grote classlibrary die in bytecode beschikbaar is en een standaard interface met het operating system vormt, is een Java-applicatie niet alleen processoronafhankelijk, maar ook onafhankelijk van het operating system. ➤
VISIE
J2EE Java 2 Enterprise Edition is een set API’s en services, waarvan de specificaties opgesteld worden door Sun Microsystems, in samenwerking met een brede groep geïnteresseerden (waaronder ook veel commerciële partijen), het Java Community Process (JCP). Er is een groot aantal leveranciers die op basis van deze specificaties producten hebben gebouwd en deze producten op de markt brengen, zoals IBM, BEA, Oracle, JBoss en natuurlijk Sun Microsystems zelf. Daarmee is J2EE een multi-vendor platform. Sinds 1999 bestaat er ook een certificeringtraject, dat tot doel heeft J2EE implementaties die zich netjes aan de specificaties houden als “J2EE Compliant” te markeren. Om een J2EE-applicatie te kunnen bouwen heeft men ook Java 2
Standard Edition (J2SE) en een Java Runtime Environment (JRE) nodig. Deze producten worden door dezelfde leveranciers geleverd.
OG
Historie In de jaren ’60 en ’70 van de vorige eeuw waren applicaties meestal ‘monolithisch’, dat wil zeggen dat de gehele applicatie, van user interface tot aan het wegschrijven van gegevens naar tape of naar schijf, één geheel was. Met de opkomst van de relationele database (jaren ’70 en ’80) en de daarbij behorende vraagtaal SQL veranderde dit langzamerhand en kwamen de clientserver applicaties steeds meer in zwang. Deze applicaties werden ook wel aangeduid als ‘2-tier’applicaties. Hierbij werd de user interface en de daarbij behorende logica in een aparte applicatie gebouwd, de zogenaamde client-applicatie, terwijl de gegevens (data) en de gegevensgebonden regels en toepassingen in een server-applicatie terecht- kwamen. De bedrijfslogica (business rules) werd verdeeld over de client- en server-applicatie. Sinds een jaar of tien, tegelijkertijd met de opkomst van internet, komen er steeds meer 3-tier(of multi-tier-)applicaties, waarbij de presentatielogica (user interface) in een zogenaamde thin client zit, de business rules in de middle-tier en de data en data-gerelateerde logica in de server. Deze architectuur wordt steeds vaker toegepast omdat deze beter past bij een inter-
Onafhankelijke vergelijking tussen de twee toonaangevende multi-tier-applicatieplatformen
9
OG
VISIE
Microsoft .NET De basis van .NET is de Common Language Runtime (CLR) die, in de vorm van een DLL, door een proces geladen en geactiveerd wordt. Deze CLR is verantwoordelijk voor een groot deel van de functionaliteit van .NET, zoals: het laden, JIT-compileren en uitvoeren van assemblies (gecompileerde .NET programma’s), het verifiëren van code, het opruimen van het geheugen (Garbage Collection), het uitvoeren van security-checks, het afhandelen van exceptions en het organiseren van interactie met traditionele DLL’s (unmanaged code). Wanneer een programma dat in een .NET-taal geschreven is, gecompileerd wordt, wordt het naar Intermediate Language (IL) vertaald. Dit is een tussentaal die redelijk vergelijkbaar is met Java-bytecode. Dankzij het Common Type System (CTS), dat een soort gemeenschappelijke basis vormt van alle .NET-talen, kunnen onderdelen van applicaties die in verschillende talen geschreven worden, toch naadloos met elkaar samenwerken en zelfs tot één assembly gecompileerd worden. Microsoft zelf heeft vijf verschillende talen uitgebracht (C#, Visual Basic .NET, J#, JScript en Managed Extensions for C++) en andere organisaties in totaal meer dan twintig. De meeste talen zijn wel enigszins aangepast om aan de regels van het CTS te voldoen. De enige talen waarvoor dat niet geldt zijn C# (dit is een nieuwe taal die speciaal voor .NET is ontworpen) en J#, een variant op Java. Het .NET Framework bevat een class-library die de services van het onderliggende operating system in een object-georiënteerde vorm aan de programmeur beschikbaar stelt. Ook hierbij geldt dat één en dezelfde class-library vanuit verschillende talen gebruikt kan worden.
10
Overeenkomsten en verschillen J2EE en .NET hebben veel overeenkomsten. De belangrijkste overeenkomst is de architectuur van de applicaties die ermee gebouwd kunnen worden: multi-tier applicaties, met web- en Windows-clients,
componenten die in een application server gehost worden en een relationele database op de achtergrond. Ook de services die de application server aanbiedt, lijken sprekend op elkaar: role-based security, transaction-demarcation, Just-In-Time-Activation, synchronisatie, connectionpooling en object-pooling. Ook de manier waarop deze services samenwerken met de componenten, via interceptie en een contextobject, vertoont sterke overeenkomsten. Andere overeenkomsten zijn de rol van de Virtual Machine of CLR, de tussentaal (bytecode, IL), de Garbage Collection en de metadata die bij de gecompileerde classes opgeslagen wordt. Natuurlijk zijn er ook belangrijke verschillen: In J2EE is er een onderscheid tussen session-beans en entity-beans: session-beans bevatten de toepassingsgerelateerde logica, entity-beans representeren entiteiten in de relationele database. De application server verzorgt de volledige communicatie met de database om de entity-beans in te laden of weg te schrijven (Container Managed Persistence) en om de relaties tussen verschillende entity-beans consistent te houden (Container Managed Relations). COM+, de application server voor .NET-componenten, kent geen entity-beans en dus ook geen CMP en CMR. Het belangrijkste verschil tussen .NET en J2EE is de afhankelijkheid van leverancier, operating system en hardware. J2EE is operatingsystem-, hardware- en leverancieronafhankelijk, terwijl .NET leverancier-, operating system- en hardwareafhankelijk is. Voordeel van de onafhankelijkheid van J2EE is dat de partij die een applicatie bouwt zich daarmee niet afhankelijk maakt van een bepaalde leverancier. Ook wisselen van leverancier of van operating system is een stuk eenvoudiger. Voordeel van de leverancierafhankelijkheid van .NET is dat operating system, application server en de CLR sterk geïntegreerd zijn en dus ook naadloos samenwerken. Ook financieel is het meestal aantrekkelijker om alle producten van dezelfde leverancier te betrekken. Daarentegen biedt de multi-
vendor-strategie van J2EE de mogelijkheid om voor elk afzonderlijk platformonderdeel de beste prijskwaliteitverhouding te zoeken en eventueel ook open source producten (zoals JBoss) bij die vergelijking te betrekken. Een ander belangrijk verschil is de taalafhankelijkheid. In J2EE wordt alleen de taal Java ondersteund, alle J2EE applicaties moeten dus volledig in Java geschreven worden. .NET kent daarentegen een groot aantal talen die, dankzij het CTS, naadloos met elkaar samenwerken en integreren. In de praktijk zijn er weliswaar slechts twee talen, C# en Visual Basic .NET, die breed toegepast worden. Belangrijker echter dan het aantal ondersteunde talen, is de mogelijkheid om, afhankelijk van kennis, ervaring en voorkeur van de programmeurs en afhankelijk van de te bouwen toepassing, die taal te kiezen die gegeven de omstandigheden het meest geschikt is. Open standaards Ook de manier waarop de verschillende partijen omgaan met het ontwikkelen van nieuwe versies, de invloed die buitenstaanders daarop kunnen hebben en het eigendomsrecht op de specificaties verschilt hemelsbreed: Sun is de partij die de taal Java gedefinieerd heeft en is de enige eigenaar van de specificaties van de taal Java, de Virtual Machine en alle J2SE en J2EE specificaties. Sun heeft een community-model gecreëerd, Java Community Process (JCP), waarin allerlei organisaties invloed kunnen uitoefenen op de nieuwe ontwikkelingen rondom J2SE en J2EE, maar Sun controleert de besluitvorming en Sun blijft de eigenaar van alles wat het JCP oplevert. Noch de taal Java, noch de definitie van de Virtual Machine, noch de J2SE- en J2EE-specificaties zijn bij een onafhankelijke standaardisatiecommissie ondergebracht. Microsoft gaat precies omgekeerd te werk: niemand anders dan Microsoft heeft formeel invloed op de nieuwe ontwikkelingen in .NET, er is geen community die in een gezamenlijk proces de nieuwe specificaties opstelt. Daarentegen heeft
Microsoft zowel de taal C# als de Common Language Infrastructure (CLI), met daarin de taal IL, als standaard gedeponeerd bij zowel de ECMA (Europese standaardisatiecommissie) als het ISO (internationale standaardisatiecommissie), waarmee Microsoft dus afstand doet van de eigendomsrechten daarop. Opvallend is dus dat in de ene situatie (J2EE) het hele proces om te komen tot nieuwe ontwikkelingen zeer open is, maar de eigendomsstructuur zeer gesloten, terwijl in de andere situatie (.NET) het hele proces zeer gesloten is, maar de eigendomsstructuur zeer open. Het geheel wordt nog merkwaardiger door het feit dat juist het platform dat zich onderscheidt door leverancieronafhankelijkheid, namelijk J2EE, volledig eigendom is van één van die leveranciers, terwijl het platform dat volledig leverancierafhankelijk is, namelijk .NET, zich onderscheidt door open standaarden en een onafhankelijke eigenaar. Een probleem dat inherent is aan elke multi-vendor oplossing en waar J2EE dus ook mee te maken heeft, is de spanning tussen de mogelijkheid voor verschillende leveranciers om onderling te concurreren binnen dezelfde specificaties en aan de andere kant de behoefte om specificaties zoveel mogelijk dicht te timmeren. Hoe meer speelruimte er is voor leveranciers om onderling te concurreren, des te lastiger is het om een applicatie die ontwikkeld is met de software van de ene leverancier, te porten naar de omgeving van een andere leverancier. Langzamerhand zien we dat de J2EE-specificaties steeds minder speelruimte overlaten voor leveranciers en dat applicaties dus steeds beter portable worden.
Figuur 1. Source: gGartner Major Vendor Web Services Platform Influence Magic Quadrant Challengers
Ability to Execute
BEA Systems
Oracle
Leaders
Microsoft IBM
Sun Microsystems
Hewlett Packard As of October 2002 Niche Players
Visionaries
Completeness of Vision
Ook een belangrijke rol speelt natuurlijk de kennis en ervaring die men al in huis heeft en eventuele bestaande relaties en contracten met leveranciers. Technische verschillen tussen J2EE en .NET zijn er wel, maar zijn niet zo indrukwekkend dat op basis daarvan een verantwoorde keuze gemaakt kan worden. Beide omgevingen zijn volwassen genoeg om robuuste, schaalbare enterpriseapplicaties te bouwen. Conclusie Voor het bouwen van multi-tierapplicaties zijn er op dit moment twee platformen beschikbaar, namelijk J2EE en .NET. Deze platformen lijken op een groot aantal onderdelen sterk op elkaar. Uiteraard zijn er ook verschillen, maar die bevinden zich voor een groot deel op een technisch detail-niveau. De belangrijkste verschillen zijn dat J2EE operating-system- en leverancieronafhankelijk is, terwijl .NET alleen op Windows draait en alleen door Microsoft geleverd wordt. Een tweede verschil is dat .NET programmeertaal-onafhankelijk is, terwijl men in J2EE aan de taal Java gebonden is. De technische mogelijkheden van beide platformen zijn vrijwel gelijk, dus een keuze tussen deze twee zal eerder gebaseerd zijn op een keuze voor het operating system of voor een leverancier dan op technische verschillen. ■ Gert Jan Timmerman is Hoofd Kenniscentrum bij Info Support
VISIE
Keuze Uiteindelijk moet er natuurlijk een keuze gemaakt worden tussen J2EE en .NET, wanneer er een applicatie ontwikkeld moet worden. De scope van zo’n keuze zal meestal breder zijn dan die ene applicatie, omdat het niet voor de hand ligt om voor de ene applicatie J2EE te kiezen en voor de volgende .NET of andersom. Grote organisaties zullen er wellicht niet aan ontkomen om beide platformen in huis te halen, omdat het vaak niet opportuun is om organisatiebreed een keuze voor één platform te maken. Minder grote organisaties zullen wel moeten kiezen omdat het ondersteunen en onderhouden van twee platformen veel te duur is.
Het belangrijkste criterium is vaak de afhankelijkheid van leverancier en operating system. Is men bereid te kiezen voor één operating system en één leverancier dan wegen de voordelen van een perfecte integratie tussen operating system, application server en webserver met de bijbehorende financiële consequenties misschien wel op tegen de nadelen van beperkte migratiemogelijkheden en zal dus de keuze voor .NET voor de hand liggen. Is men niet bereid zich voor langere tijd aan het Windows operating system en aan Microsoft te verbinden, dan is J2EE de meest logische keuze.
OG
Webservices Webservices zijn diensten die via internettechnologie beschikbaar gesteld worden. Dat betekent dat men een dienst kan aanvragen door een verzoek te sturen naar een URL en vervolgens een antwoord terug krijgt. Het protocol dat hiervoor gebruikt wordt is SOAP (Simple Object Access Protocol), een W3C
standaard. Webservices zijn de meest eenvoudige manier om applicatie-integratie over verschillende platformen te verwezenlijken, een ideale manier dus om J2EE en .NET applicaties met elkaar te laten communiceren. .NET is het eerste platform dat webservices ondersteunt: Microsoft heeft ook een belangrijke bijdrage geleverd aan het ontwikkelen van de ondersteunende protocollen. J2EE ondersteunt webservices vanaf versie 1.4, die op dit moment in de bètafase is. Individuele leveranciers, zoals IBM, ondersteunen ook op dit moment al webservices, maar dit geldt dus nog niet voor alle J2EE leveranciers. IBM is ook één van de partijen die veel energie gestoken hebben in het ontwikkelen van de protocollen die aan webservices ten grondslag liggen. Het ‘magic-quadrant’ van Gartner (figuur 1) laat zien dat Microsoft en IBM op het gebied van webservices toonaangevend zijn.
11
Kees Boers is Oracle-consultant bij The DOC, oftewel: The Dutch Oracle Company. Zijn specialiteit: energie- en nutsbedrijven. Kees mag zich gezien zijn ervaring met recht ‘specialist in de energiebranche’ noemen. En dat hij af en toe iets verder moet gaan om tot de kern van de zaak door te dringen, vindt hij geen probleem. Bijvoorbeeld een kijkje nemen op de Maasvlakte, om zelf te zien hoe groene stroom kan worden opgewekt. En dat vliegeren, dat wil hij trouwens ook graag nog eens leren.
Automatisering is mensenwerk! Dus als u ook op zoek bent naar een betrokken consultant in Oracle diensten, maak dan snel een afspraak met The DOC. Naam: Kees Boers Oracle-consultant The DOC Leeftijd: 39 jaar Ervaring: Designer 1, 2 en 6, Developer, Headstart, GSK, CDM, SDW, RAD, enzovoort. Specialiteit: o.a. CRM-applicaties, datawarehousing, coaching Statement: De klant niet je eigen kennis en oplossingen opdringen, maar de klant door deskundig advies de ruimte geven zijn eigen weg te bepalen.
The DOC Dorpsstraat 142 Postbus 295 Nederland
3991 BZ Houten 3990 GB Houten
Tel.: +31 (0)30 635 82 66 Fax: +31 (0)30 635 82 65
[email protected] www.thedoc.nl
The DOC. Perfection in Oracle services The DOC biedt klantgerichte IT-oplossingen met Oracle tools en applicaties. Perfection in Oracle services, dat is waar The DOC voor staat. Onze activiteiten lopen uiteen van vooronderzoek, ontwerp (functioneel en technisch) en ontwikkeling met de nieuwste Oracle technieken, tot opleidingen, beheer en onderhoud. Wij werken voor diverse klanten in verschillende branches: multinationals, pensioenfondsen, verzekeringsmaatschappijen, overheid, stichtingen en verenigingen.
The DOC Zuid-Nederland Roermondseweg 7, 6004 AN Weert Tel.: +31 (0)495-549230, Fax: +31 (0)495-550756
Oracle is een geregistreerd handelsmerk van Oracle Corporation.
Mark Jarvis
Oracle Collaboration Suite gepresenteerd tijdens seminar ‘Ik mail veilig of ik mail niet’
Centrale oplossing voor samenwerking en communicatie e jongste loot aan de Oracle softwarestam heet Oracle Collaboration Suite. Met deze geïntegreerde suite van e-mail-, agenda- en bestandsbeheertoepassingen mengt Oracle zich nadrukkelijk in de strijd op de markt voor collaboration software, waar Microsoft (Exchange) en IBM (Lotus Notes) nu nog de dienst uitmaken. Oracle profileert de Collaboration Suite als de “eerste vierde-generatie suite voor samenwerking en communicatie”. De Collaboration Suite werd in Nederland gepresenteerd door Mark Jarvis, Senior Vice President Chief Marketing Officer Oracle Corporation, tijdens het seminar ‘Ik mail veilig of ik mail niet’. In een overvolle conferentiezaal in Artis gaf Jarvis aan de hand van een demonstratie inzicht in de werking en de mogelijkheden van de Oracle Collaboration Suite.
D
Het belangrijkste verkoopargument voor de Oracle Collaboration Suite is kostenbesparing. Volgens Jarvis bedragen de huidige jaarlijkse kosten voor ‘collaboration (e-mail, voicemail, bestandsuitwisseling) voor een gemiddeld bedrijf meer dan 775 dollar per medewerker. Door gebruik te maken van de geïntegreerde software van Oracle, waarbij alle informatie en functionaliteit in een centrale database is opgeslagen, is het mogelijk om tot 80 procent op die kosten te besparen. Die besparingen hebben dan voornamelijk betrekking op de infrastructuur en de beheerkosten. In plaats van vele verschillende, verspreid opgestelde messaging en file servers biedt Oracle Collaboration Suite een centrale oplossing, waarin alle applicaties in één systeem zijn ondergebracht.
Productiviteit Behalve kostenbesparing zorgt Oracle Collaboration Suite volgens Mark Jarvis ook voor een verhoogde productiviteit, onder meer doordat de downtime van e-mail sterk wordt gereduceerd. Ook het ophalen van bestanden, het maken van afspraken en het opzoeken van informatie vergt aanzienlijk minder tijd. Oracle Collaboration Suite beschikt over een eigen e-mail module, maar ondersteunt ook alle bekende e-mail clients, zoals Microsoft Outlook, Netscape Messenger, Lotus Notes. Gebruikers kunnen dus hun met hun eigen e-mail programma en user interface blijven werken. De Oracle software suite maakt daarnaast ook toegang via het web, draadloos en via spraak mogelijk, zodat gebruikers hun email en agenda vanaf elke plek en op elk tijdstip kunnen benaderen.
Beveiliging Doordat alle berichten, bestanden en andere data zijn ondergebracht centraal – en eenmalig - zijn opgeslagen, is het veel eenvoudiger om het verspreiden van virussen te voorkomen en veiligheidsmaatregelen te treffen, benadrukte Jarvis. “Alle bestanden in de database zijn met 64-bit des-encryptie beveiligd. De Oracle database voorziet in gebruikersidentificatie en toegangscontrole, zodat het systeem beschermd is tegen ongeoorloofde toegang. Op een e-mail server kan iedereen alle mail lezen, bij ons kan dat niet.” Virussen kunnen door de centrale architectuur van de Collobaration Suite snel worden gedetecteerd en verwijderd. Verdachte berichten of attachments kunnen direct en snel worden verwijderd of geïsoleerd voor verder onderzoek. Oracle zelf heeft op die manier 1,5 miljoen e-mails die waren besmet met het Party Photo virus, in 15 minuten tijd gewist, vertelde Mike Jarvis. Uitbesteden Voor de implementatie van de Oracle Collaboration Suite zijn twee opties. Bij een standaard implementatie beheert en onderhoudt de klant het systeem en verzorgt zelf de upgrades. Wanneer voor een outsourced implementatie wordt gekozen neemt Oracle – of een Oracle partner – het beheer en onderhoud van het systeem en de upgrades voor zijn rekening. Tijdens het seminar presenteerden verschillende Oracle Collaboration Suite Partners zich in een kleine informatiemarkt in het Artis conferentiecentrum. Naast Oracle Consulting bieden ook de partners dienstverlening aan op het gebied van de implementatie van de Suite en migratie van bestaande messaging en collaboration omgevingen. ■
VISIE
Co-browsing Mark Jarvis demonstreerde die spraakgestuurde toepassing door per telefoon een database in de Verenigde Staten te benaderen en te vragen een bestand door te faxen naar een faxapparaat dat op het podium in Artis stond opgesteld. Nadat hij zich had aangemeld en geïdentificeerd via het intoetsen een pinen identificatiecode, vroeg de Suite wat Jarvis wilde: zijn e-mail lezen of laten voorlezen, zijn voicemail beluisteren of zijn bestanden inzien. Al pratend kwam het tot de opdracht om een testdocument naar Amsterdam te sturen, hetgeen ook gebeurde. Naast de modules E-
mail, Voicemail & Fax, Calendar, Files, Search en Wireless & Voice Access heeft de Collobaration Suite ook een iMeeting module, waarmee meerdere mensen gelijktijdig over dezelfde website kunnen surfen (cobrowsing). Ook telefoneren en vergaderen via het web is mogelijk.
OG
Kostenbesparing bij Oracle Jarvis onderbouwde die cijfers aan de hand van de besparingen die Oracle zelf heeft gerealiseerd. In drie jaar tijd zijn de kosten voor e-mail met 35 miljoen dollar gereduceerd, door het aantal e-mail servers in de organisatie terug te brengen van 97 naar 2 clusters.
In plaats van 65 ‘administrators’ zijn er nu nog maar 13 medewerkers nodig voor het beheer. De kosten voor voicemail zijn teruggebracht van 320 dollar per medewerker naar 23 dollar, wat in drie jaar tijd een besparing van 13,5 miljoen opleverde. Het aantal file servers ging van 1.000 naar 1, waarvoor nog maar 1 beheerder nodig is in plaats van voorheen 33. Resultaat: een besparing op de filemanagement kosten van 18 miljoen dollar in drie jaar. Ook op de kosten voor mobiele toegang is flink bespaard, zo’n 27 miljoen dollar, waardoor de totale besparing uitkwam op 93 miljoen dollar, vertelde Jarvis.
13
automatisering Mediaan/abs bv frankenlaan 5 • postbus 8006 • 6401 VA heerlen telefoon: +31 (045) 571 83 55 fax: +31 (045) 574 04 77 e-mail:
[email protected]
Bruggen slaan tussen business en informatietechnologie Projecten
Mediaan ontwerpt, bouwt en onderhoudt informatiesystemen in een
Beheer
Oracle-omgeving, zowel client/server als web enabled. Meer dan 20 jaar Oracle-ervaring heeft niet alleen een grondige kennis opgeleverd van het Rdbms, Designer en Developer, maar heeft eveneens een
Coördinatie
goede basis gelegd voor al weer 5 jaar applicatieontwikkeling voor het web. We leveren hoge kwaliteit door onze op CDM gebaseerde aanpak. Dit hebben we vele malen bewezen met de ontwikkeling en het onderhoud
Planmatig
van omvangrijke en complexe administratieve, financiële en logistieke toepassingen.
Servicegericht
Wilt u meer weten? Bel met John Coumans of Jos Wulms, tel 045-571 83 55.
In partnership
www.mediaan.nl
Oracle partner
Systemen ontwerpen, bouwen, onderhouden
Oracle9iAS Release 2
Oracle9iAS Release 2: een korte kennismaking Door André Jochems e laatste release van Oracle’s Internet Application Server is al weer een tijdje beschikbaar. De totale suite bestaat inmiddels uit erg veel onderdelen en is behalve fors uitgebreid ook aanzienlijk complexer geworden in vergelijking met voorgaande releases. Hoog tijd dus om Oracle’s Application Server eens wat nader te bekijken.
D
Omdat de totale suite flink groter is geworden zou het een te uitgebreid verhaal worden om alle onderdelen te bespreken. Derhalve heb ik er voor gekozen de belangrijkste onderdelen er eens kort uit te lichten en de voornaamste verschillen met release 1 aan te stippen. De grootste van de verschillen met release 1 zorgt gelijk ook voor één van de belangrijkste onderdelen. Oracle heeft er namelijk voor gekozen om de nieuwe architectuur op te bouwen rondom een centrale, op een Oracle9i database gebaseerde, management/infrastructuur node. Naast deze infrastructuur node kunnen zogenaamde mid-tier nodes worden ingericht die gebruikt worden voor toepassingen als bijvoorbeeld een OC4J server of een Forms server. Naast deze opsplitsing kijken we naar LDAP/SSO en de toekomst van Oracle Identity Management, Oracle’s J2EE compliant OC4J server, deployment van Java applicaties naar een iAS en de Enterprise Manager Website.
Metadata Repository De infrastructuur node is gebouwd rondom een Oracle9i database die gebruikt wordt als centrale repository. Alle gegevens van de applicatieservers die aan een infrastructuur zijn verbonden worden erin opgeslagen. Daarnaast dient de Metadata Repository voor de opslag van de schema’s voor onder meer de SSO en Oracle Internet Directory server en Portal. De database voor de Metadata Repository is er mede de oorzaak van dat een infrastructuur iAS een krachtige server nodig heeft met veel geheugen. Om een installatie te kunnen uitvoeren is 512 MB de minimale vereiste en voor een productieomgeving is 1,5 tot 2 Gb geen overbodige luxe; het motto lijkt dan ook hoe meer, hoe beter. De mid-tier servers kunnen het, afhankelijk van hun toepassing, af met beetje minder geheugen aangezien de infrastructuur node een deel van de overhead heeft overgenomen. Aangezien de Metadata Repository database nog niet in een RAC configuratie kan worden geïnstalleerd, wordt daarmee wel gelijk de achilleshiel van de nieuwe opzet blootgelegd. Als de Metadata Repository crasht zullen daarmee ook alle componenten die hun data erin hebben opgeslagen niet meer werken. Oracle heeft dit onderkend en de optie voor een RAC configuratie zal in een toekomstige release worden toegevoegd.
Single Sign-On server De SSO server is nu een op zichzelf staand en centraal product geworden. De SSO server draagt zorg voor authenticatie en autorisatie van users en slaat al zijn gegevens op in de Oracle Internet Directory. De SSO server kan gebruikt worden voor Web PL/SQL en Java applicaties maar ook voor bijvoorbeeld de Forms Server of andere externe webapplicaties. In de laatste gevallen moet er voor elke user een profiel voor de externe applicatie aangemaakt worden waarin de connect informatie voor die database of applicatie vastligt. De SSO server logt dan in voor de user met de voor hem opgeslagen credentials. De SSO server zelf is gebaseerd op een Apache module genaamd mod_osso en heeft ook zijn eigen schema’s in de Metadata Repository voor applicatielogica en data. Oracle Identity Management voor Windows Vanwege de steeds verdere integratie van systemen, platformen en applicaties besteedt Oracle veel aandacht aan Identity Management op Enterprise niveau. Temeer ➤
VISIE
Oracle Internet Directory Oracle Internet Directory, ook wel OID genoemd, is Oracle’s implementatie van een versie 3 compliant
LDAP directory server, die een industriestandaard is. De OID wordt gebruikt voor het opslaan van gegevens over gebruikers, applicaties en organisaties. Binnen de Oracle iAS architectuur wordt ook de configuratie-informatie van de applicatieserver opgeslagen in de OID. De OID bestaat uit een monitor en een aantal deamons die de connecties afhandelen; de monitor herstart automatisch processen indien die onverhoopt stoppen. De informatie in OID kan ook uitgewisseld of gesynchroniseerd worden met informatie in andere LDAP directories zoals bijvoorbeeld iPlanet Directory of Microsoft Active Directory.
OG
De infrastructuur node De infrastructuur node is een centrale plaats voor iAS management, configuratie informatie en dataopslag voor Applicatie Server installaties. Alhoewel sommige producten ook stand-alone geïnstalleerd kunnen worden is het aan te bevelen om de gehele architectuur te bouwen rond Oracle’s infrastructuur node.
Als men producten zoals Single Sign-On server wil gebruiken is het verplicht om een infrastructuurinstallatie te gebruiken. De infrastructuur node bestaat uit een aantal onderdelen.
15
Oracle9iAS Release 2
VISIE
OG 16
omdat ook steeds meer externe gebruikers en processen moeten worden geïntegreerd in interne systemen. Door Identity Management te centraliseren en globaal SSO te implementeren kunnen veel kosten bespaard worden. Binnen het OID integratie platform bestaan twee belangrijke onderdelen om de integratie te bereiken. Bij ‘Provisioning’ kan men PL/SQL code aanroepen die acties uitvoeren als een deelnemer in de directory gewijzigd of verwijderd wordt. Zo kan men bijvoorbeeld voor Portal met API’s rechten ontnemen van een user. Bij ‘Synchronization’ wordt de OID gekoppeld aan een externe directory zoals Active Directory en zullen de twee synchroniseren bij wijzigingen. Voor de nabije toekomst heeft Oracle een aantal uitbreidingen gepland voor OID en Windows zoals ‘Directory Connectors’ en Plug-Ins. De connector is een compleet geheel dat de afhandeling van de synchronisatie afhandelt. Plugins kunnen bijvoorbeeld gebruikt worden voor de propagatie van het updaten van wachtwoorden. Door de zogenaamde touwtjes aan elkaar te knopen zal een complete centralisatie van user authenticatie en autorisatie plaats kunnen vinden. De benodigde onderdelen om Active Directory met OID te integreren staan ingepland voor release 9.0.4. Oracle9iAS Containers for J2EE (OC4J) Waar in release 1 de Apache JServ nog een belangrijke rol speelde wordt nu aanbevolen om OC4J te gebruiken als omgeving voor het deployen van servlets. OC4J zijn in Java geschreven J2EE containers die draaien op de Java Virtual Machine die aanwezig is in de standaard Java Development Kit. OC4J is gebaseerd op de Orion server van Ironflare Corporation, één van de meest bekende J2EE containers. Oracle heeft deze technologie in licentie genomen en gebruikt voor OC4J. De server is volledig J2EE compliant en voldoet daarmee aan alle standaarden. Applicaties die dus gebouwd zijn voor bijvoorbeeld de Tomcat server van Apache kunnen zonder problemen op een OC4J server geïnstalleerd worden en vice versa.
Binnen een iAS installatie kan men naar wens OC4J instances aanmaken die apart en onafhankelijk van elkaar draaien met elk zijn eigen configuratie. Binnen de infrastructuur wordt eigenlijk maar één OC4J instance echt gebruikt en dat is voor de Delegated Administration Service (DAS) applicatie. Deze Java applicatie is voor het administreren en beheren van SSO users en groepen die opgeslagen liggen in de eerder beschreven OID server. Java applicatie deployment Als een applicatie eenmaal gebouwd is, bijvoorbeeld met JDeveloper, kunnen die vrij eenvoudig uitgezet worden op een stand-alone OC4J instance, of in één keer naar een compleet cluster. Voor het uitzetten van applicaties naar een Oracle iAS maakt Oracle gebruik van Distributed Configuration Management (DCM). Dit uitzetten kan via de Enterprise Manager Website (waarover verderop meer), de command line prompt op de applicatieserver of direct vanuit JDeveloper. Het uitzetten wordt niet gedaan voor de afzonderlijke onderdelen maar alles wordt samengepakt in één archief. Binnen de J2EE standaarden is vastgelegd hoe de componenten moeten worden samengepakt en dit gebeurt in een EAR (Enterprise ARchive) bestand. Alle applicatie settings, data sources en paden kunnen via de Enterprise Manager Website geconfigureerd worden. Enterprise Manager Website Waar binnen release 1 bijna alle configuratie stappen uitgevoerd moesten worden door middel van het direct bewerken van configuratiebestanden op het filesysteem van de iAS, kan nu het grootste deel van de configuratie gedaan worden vanuit een webinterface. De door Oracle geschreven EM website applicatie kan gebruikt worden om OC4J instances te creëren en te configureren. Men kan de complete HTTP server configuratie aanpassen zoals bijvoorbeeld het toevoegen van virtuele servers of het wijzigen van poortnummers. Tijdens de installatie van een mid-tier applicatieserver kan men die koppelen
aan een infrastructuur node. Vanuit de EM website kan men snel en makkelijk alle nodes beheren en configureren. De groep van applicatieserver nodes die bij een bepaalde infrastructuur horen noemt men een ‘Farm’. Indien binnen een farm een aantal nodes samengevoegd worden dan wordt dit een ‘Cluster’ genoemd. Als men een Java EAR file naar een cluster overzet wordt het betreffende archive automatisch naar alle nodes gestuurd en hoeft men dus niet handmatig elke node in het cluster te updaten. Daarnaast geeft de EM website uitgebreide informatie over node resources, zoals geheugen en processoren en het gebruik daarvan.
Conclusies Oracle’s Application Server is een bijzonder compleet product. Met het groeien van de totale suite is ook de complexiteit sterk toegenomen. Er is weer een groot aantal afkortingen, termen en methodes en technieken bijgekomen en dan hebben we het nog niet eens gehad over Portal, Forms Server, Reports Server, Discoverer en de rest van de beschikbare onderdelen binnen iAS. Waar het beheer van iAS release 1 er nog dikwijls bij werd gedaan door een DBA of een ontwikkelaar is nu met release 2 een dedicated iAS Administrator voor grotere implementaties geen overbodige luxe meer. Oracle heeft dit ook ingezien en daarvoor de ‘Oracle 9iAS Web Administrator Certified Associate’ certificering in het leven geroepen. Zoals altijd zorgen een aantal nieuwe onderdelen ook voor veel problemen en bugs, maar daarentegen zijn bestaande producten die ook reeds in release 1 zaten er veel op vooruit gegaan en stabieler geworden. Oracle toont met de nieuwste release in ieder geval een groot commitment om een grote speler in de applicatieserver markt te blijven. ■ André Jochems is Oracle Consultant bij Itude Technology BV
Brand in rekencentrum Universiteit Twente belicht in OGh themabijeenkomst
Uitslaande brand bewijst waarde calamiteitenplan rand in het rekencentrum. De nachtmerrie van elke ICTmanager. Op 20 november 2002 werd die nachtmerrie werkelijkheid: in het rekencentrum van de Universiteit Twente woedt een grote uitslaande brand, waarbij het computernetwerk en een deel van de faculteit Bestuurskunde in vlammen opgaan. Op de campus ligt een van de snelste netwerken van Europa. De universiteit zet het calamiteitenbestrijdingsplan in werking en werkt met man en macht om de ICT-infrastructuur weer in de lucht te krijgen. Tijdens een themabijeenkomst van de OGh deden twee stafmedewerkers van de Universiteit Twente verslag van hun ervaringen tijdens en na de brand en de manier waarop de ICT-calamiteitenbestrijding in de praktijk succesvol is aangepakt.
B
In de dagen die volgen na de 22ste november wordt de volle omvang van de ramp zichtbaar, vertelde Erik Nijboer, ICT stafmedewerker bij het CIV en lid van het brand-calamiteitenteam van de Universiteit Twente. De totale schade die de brand heeft aangericht, loopt in de tientallen miljoenen euro’s. De schade aan de ICT-infrastructuur wordt geraamd op vijf miljoen euro. Bij de brand zijn de centrale computerruimte, een PC-zaal voor studenten, de PCwinkel en enkele helpdesk-ruimtes onherstelbaar beschadigd. Daags na de brand is het Surfnet-knooppunt alweer in de lucht. Dit knooppunt verbindt de UT via een 10 gigabitaansluiting met het internet. Binnen tweeëneenhalve dag is ook het interne UT-netwerk weer in bedrijf. Al met al heeft de Universiteit Twente zijn ICT-infrastructuur snel weer op orde.
In zijn presentatie ging Erik Nijboer in op de situatie voor de brand, de hectische periode tijdens en vlak na de brand en de wijze lessen die zijn geleerd van deze ramp. De brand heeft in ieder geval aangetoond dat de tweede ICT-ruimte die op dat moment in aanbouw was, dringend noodzakelijk is om zo de risico’s te spreiden. Het bewaren van back-up tapes in een ander gebouw bleek achteraf een goede zaak. Een ander belangrijk punt dat bij de evaluatie naar voren is gekomen is dat er voor de beheerders werkplekken in een ander gebouw moeten zijn. Ook de back-up procedure is aangescherpt, omdat gebleken is dat gebruikersgroepen van een test een productieomgeving maakten zonder dat te melden, waardoor er geen adequate back-up was. Disaster recovery databaseomgevingen Ry Gemser, behandelde vervolgens in zijn presentatie de disaster recovery voor de databaseomgevingen van de Universiteit Twente. Hij is werkzaam als coördinator computersysteem-/applicatieserver-beheer bij ITBE - Telecommunicatie & Systemen, de centrale dienst die is gericht op ondersteuning van de ICT - infrastructuur. De afdeling
beheert circa honderd servers, draaiend onder Windows (NT/2000), Unix (HPUX, Digital/Unix) en Linux. De UT beschikte voor de brand over een centrale back-up infrastructuur en een back-upvoorziening voor de Oracle databaseomgevingen. Vier van de databases waren 24-uurs databases, waarvan dagelijks een online back-up werd gemaakt. Tevens werd een ‘cold’-back-up gemaakt van de niet 24-uurs databases. Voor de online back-up draaide de Oracle database in archive log mode. De logs werden gedurende de dag een aantal keren (om de 2 uur) naar tape geschreven. Na de laatste back-up om circa 23.00 uur werden ze van schijf verwijderd. Elk weekend werd een export gemaakt van alle omgevingen. Na de brand zijn de opbouw-/herstelacties van de databaseomgevingen in gang gezet met de beschikbare back-ups die overgezet zijn naar andere computersystemen van de Universiteit en leensystemen van huisleverancier HP. Roy Gemser gaf vervolgens een summiere opsomming van de problemen die men is tegengekomen en welke lessen daaruit getrokken zijn. De brand is in ieder geval aanleiding geweest om een betere back-up procedure op te zetten voor de nieuwe situatie, die onder meer voorziet in het eerder/sneller zeker stellen van de back-up data en verbeterde controles. Ook wordt meer aandacht besteed aan configuration management en het actueel en volledig houden van documentatie, zoals handleidingen, beschrijvingen van configuraties, implementaties, afzonderlijk ingestelde parameters. Ook Roy Gemser benadrukte de noodzaak om de risico’s te spreiden, onder ander door een tweede ICT-ruimte en redundante systemen en netwerkcomponenten. ■
17
Op zoek naar verstandelijk vermogen in de cost-based optimizer Tim Gorman, Evergreen Database Technologies, Inc.
T
ien jaar na de introductie ervan is de cost-based optimizer (CBO) nog steeds een bron van frustratie en teleurstelling. De CBO werd voor het eerst in Oracle7 versie 7.0 toegepast met de belofte dat de performance van queries op magische wijze zou verbeteren. Maar in plaats daarvan lijkt de CBO gericht te zijn op zelfvernietiging door uitvoeringsplannen te selecteren die de performance alleen maar verslechterden. Wanneer de CBO, blijkbaar puur toevallig, wel een zinnig uitvoeringsplan selecteerde, bleef het daar echter niet bij. De CBO werd berucht vanwege zijn onverwachte overschakeling van een goed naar een slecht plan.
Een gevolg is dat de meerderheid van de ontwerpers hun uiterste best doen om de vertrouwde rule-based optimizer (RBO) te handhaven, al is het alleen maar vanwege de voorspelbaarheid en stabiliteit ervan. Het enige voordeel dat de CBO lijkt te hebben, is dat het alle handige nieuwe functies ondersteunt die Oracle vanaf versie 7.1 heeft geïntroduceerd. Het komt er in feite op neer dat men het gebruik van de CBO op de koop toeneemt om de nieuwe functies te kunnen gebruiken. Daarnaast blijft de conventionele wijsheid gelden dat je beter met de RBO kan blijven werken.
OG
VISIE
Enorm verbeterd En hoewel de situatie rond de CBO in Oracle8 v8.0 langzaam aan een heel stuk beter is geworden en in Oracle8i zelfs enorm is verbeterd, blijft deze wijdverspreide mening van kracht. De waarheid is dat de CBO prima functioneert in Oracle8, en met name in Oracle8i. Dit is natuurlijk nogal een boude uitspraak, maar ik wil hier graag van de gelegenheid gebruik maken om u ervan te overtuigen dat ik geen verkoper voor Oracle Corporation ben, en ook ben ik niet (volledig) getikt. Eventueel afwijkend functioneren dat u hebt gemerkt of waarover u hebt gehoord, is eerder te wijten aan verkeerd gebruik (d.w.z. slechte input of configuratie) dan aan juist gebruik.
18
Om een lang verhaal kort te maken… OK, om te voorkomen dat u dit gehele artikel moet lezen zal ik een lang verhaal kort maken en de belangrijkste aanbevelingen meteen aan het begin van het artikel onthullen. In Oracle8 v8.0 werden twee nieuwe initialisatieparameters beschikbaar gemaakt, maar ze werden niet gedocumenteerd. Deze werden uiteindelijk bij de release van Oracle8i in de handleiding Oracle8i Server Reference uiteen gezet: • OPTIMIZER_INDEX_CACHING Deze initialisatieparameter vertegenwoordigt een procentwaarde, variërend in waarde tussen 0 en 99. De standaardwaarde 0 laat de CBO weten dat 0% databaseblokken, die
door middel van geïndexeerde toegang werden geopend, in de Buffer Cache van de Oracle SGA gevonden kunnen worden. Dit houdt in dat alle indexinvoeren per logical read van de Buffer Cache een physical read van het I/O-subsysteem vereisen. Dit staat ook wel bekend als een succespercentage van 0% op de Buffer Cache. Deze parameter is alleen van toepassing op de berekeningen van de CBO van invoer op blokken in een index, niet voor de blokken in de tabel die aan de index gerelateerd zijn. • OPTIMIZER_INDEX_COST_ADJ Deze initialisatieparameter is ook een procentwaarde, variërend in bereik van 1 tot 10.000, en vertegenwoordigt een vergelijking tussen de relatieve kosten van physical I/O-verzoeken voor geïndexeerde invoer en volledige tabelscans. De standaardwaarde 100 geeft de cost-based optimizer aan dat geïndexeerde invoer 100% kost (d.w.z. evenveel kost) als de invoer van een VOLLEDIGE tabelscan. In de praktijk blijkt dat de standaardwaarde voor beide parameters verkeerd is. Ik zal deze bewering verderop in dit artikel bewijzen. We gaan er voorlopig even van uit dat OPTIMIZER_INDEX_CACHING ingesteld dient te worden op 90 en OPTIMIZER_INDEX_COST_ADJ op een waarde die voor de meeste online transaction processing (OLTP) systemen geldt. Voor datawarehousing- of andere decision-support systemen (DSS) is het veiliger deze parameter in te stellen op 50. Aan het einde van dit artikel wordt een manier beschreven waarop dit nauwkeuriger kan worden berekend. Dus dat is dat! Probeer het eens uit. Neem een voorheen onverbeterlijke SQL-statement, verwijder alle statements die er met moeite op zijn geplakt, stel deze twee parameters met ALTER SESSION SET in en voer een EXPLAIN PLAN uit. …De rest van het verhaal… Hebt u er ook zo’n hekel aan wanneer iemand in het wilde weg, zonder enig bewijs beweringen doet? Maar zo gaat het toch met de meeste beweringen? Ten eerste wil ik het verhaal vanaf het begin vertellen, te beginnen met de RBO en hoe deze werkt. Vervolgens wil ik overgaan naar de CBO en uitleggen hoe deze werkt (en het verschil aantonen). Ik wil aantonen op welke wijze de twee parameters, die hierboven zijn genoemd, een spectaculaire invloed hebben op het functioneren van de CBO. Deze parameters, die als een ongedocumenteerde, latere overweging aan Oracle8 v8.0 zijn toegevoegd, hebben dezelfde invloed op de kostenberekeningen van de CBO als aftrekposten bij uw bruto inkomen op uw verschuldigde netto inkomstenbelasting. Zo werkt de rule-based optimizer Maar laten we bij het begin beginnen.
De rule-based optimizer (RBO) maakt slechts van een kleine hoeveelheid informatie gebruik bij de bepaling van een uitvoeringsplan voor een SQL-statement: • De tekst van deze SQL-statement • Basisinformatie aangaande de objecten in de SQL-statement, zoals de tabellen, clusters en weergaven in de FROM clause en het gegevenstype van de kolommen waaraan in de andere clauses wordt gerefereerd • Basisinformatie aangaande indexen die zijn verbonden met de tabellen waaraan in de SQL-statement wordt gerefereerd • Informatie over de data is uitsluitend beschikbaar voor de lokale database. Indien u refereert aan een database op afstand, wordt de informatie over de data op afstand voor de RBO niet beschikbaar gemaakt Teneinde het uitvoeringsplan te bepalen, dient de RBO eerst de WHERE clause van de statement te bepalen, waarbij elke predikaat voor evaluatie wordt afgescheiden, te beginnen bij het einde van de statement. De RBO past op elke statement een puntentotaal toe door gebruik te maken van de vijftien toegangspaden die overeenkomstig hun vermeende waarde worden geordend: 1 Een enkele rij op ROWID 2 Een enkele rij op cluster koppeling 3 Een enkele rij op gemengde clustertoets met unieke toets 4 Een enkele rij op unieke index 5 Cluster koppeling 6 Gemengde clustertoets 7 Geïndexeerde clustertoets 8 Samengestelde toets 9 Enkele kolom niet-unieke index 10 Zoekopdracht naar gebonden bereik op geïndexeerde kolommen 11 Zoekopdracht naar ongebonden bereik op geïndexeerde kolommen 12 Koppeling sorteren-samenvoegen 13 MAX of MIN van geïndexeerde kolommen 14 ORDENEN OP op geïndexeerde kolommen 15 Volledige tabelscan
Oracle heeft de RBO niet voor niets opgegeven: het moest wel gebeuren. Een optimizer die meer informatie gebruikt voor de kenmerken en organisatie van gegevens is de enige haalbare richting voor de lange termijn. Helaas duurde het bijna 7 lange jaren na de introductie van de cost-based optimizer voordat met recht gezegd kon worden dat deze klaar was voor productiesystemen. Zo werkt de Cost-Based Optimizer De CBO is een wiskundige processor. Het maakt gebruik van formules om de kosten van een SQL-statement te berekenen. De CBO onderzoekt alle mogelijke toegangspaden, waarbij hij gebruik maakt van de informatie die voor de RBO beschikbaar is plus informatie over de gegevens (zoals het aantal rijen, de grootte van tabellen en indexen, de verdeling van gegevens over kolommen, enz.). Vervolgens berekent hij het aantal logical I/O’s voor elk mogelijk toegangspad, waarna hij eenvoudigweg de goedkoopste selecteert. Let wel dat de RBO lineaire, stapsgewijze beslissingen neemt. Hij neemt een beslissing waarna hij deze beslissing gebruikt als basis om de volgende beslissing te overwegen. Tijdens dit proces neemt hij, al naar gelang eerdere beslissingen, een steeds geringer aantal mogelijkheden in overweging. Op deze wijze bepaalt de kwaliteit van de oorspronkelijke beslissingen de kwaliteit van de daaropvolgende keuzemogelijkheden. Schaken Vergelijk deze methode nu eens met een spelletje schaken. Zo speel ik namelijk schaak – net zoals de RBO. Maar ik kan slechts de volgende zet plannen en niet twee, drie of tien verschillende zetten vooruit bedenken voor één mogelijke variatie, laat staan voor meerdere variaties. Ik win ook niet zo vaak. In tegenstelling tot de RBO bepaalt de CBO de kosten van alle mogelijke uitvoerplannen. Net zoals de RBO werkt de CBO in stappen. Hij begint bij alle mogelijke toegangspaden en berekent dan vanaf dat beginpunt de daaropvolgende koppelingen of toegangspaden. Elke stap in de uitvoer wordt op deze wijze berekend. Hij probeert alle mogelijke variaties van het toegangspad uit tot aan de limiet die door de initialisatieparameter OPTIMIZER_MAX_PERMUTATIONS standaard is ingesteld met een waarde van 80.000. Dat zijn een heleboel variaties om in overweging te nemen en de CBO neemt vaak honderdduizenden variaties in minder dan een seconde in overweging. Opmerking - Indien u hier uw twijfels over hebt: er bestaat een volggebeurtenis voor ‘CBO trace dump’(gebeurtenis 10053) die op mijn website (http://www.EvDBT.com/library.htm) aan de onderzijde van die webpagina staat gedocumenteerd. Met deze gebeurtenis kunt u alle overwegingen die door de CBO zijn genomen, in een ‘.trc’ volgbestand in de directory USER_DUMP_DEST op de databaseserver dumpen.
VISIE
Denk nog eens aan schaken. De CBO lijkt wel een beetje op een schaakmeester die in staat is om alle mogelijke zetten, ➤
OG
Iedereen die ooit tijd heeft gestoken in het tunen van SQLstatements, weet dat volledige tabelscans niet eensluidend slecht zijn, zoals de waardering 15 uit 15 doet suggereren. Er is een aantal situaties waarin een volledige tabelscan veel beter is dan toegang via een index. De aanwezigheid van een index betekent niet altijd dat dit de beste toegangsmethode is, ook al is dat in de RBO gecodeerd. Dus hieruit blijkt uit ervaring meteen al dat een systeem bestaande uit een vaste volgorde van regels, gedoemd is problemen te veroorzaken. Let hierbij bovendien op de overheersing in gebruik van tabelclusters, zowel geïndexeerd als gemengd. Het is in feite zo dat van de eerste zeven regels in de lijst er vijf betrekking hebben op clusters. In de tien jaar dat Oracle toepassingen heeft ontworpen, heb ik persoonlijk maar twee of drie keer kunnen profiteren van tabelclusters en alleen als onderdeel van een eigenlijke productietoepassing. Telkens wanneer ik het gebruik ervan in overweging nam, bleken de nadelen ervan zwaarder te wegen dan de voordelen. Hoe vaak hebt u tijdens uw loopbaan gebruikt gemaakt van clusters? Dus het is meteen duidelijk dat slechts tien van de in totaal
vijftien regels relevant zijn voor normale toepassingen. Slechts tien. Dat is geen ruime keuze voor een gecompliceerd geheel als SQL-implementatie in Oracle8.
19
alsmede de daaropvolgende zetten, in overweging te nemen, zodat deze tot een besluit kan komen over de volgende zet met het grootst mogelijke voordeel. Wat kan er mis gaan? Zo werkt de CBO dus. Hij berekent de kosten van alle mogelijke variaties van de uitvoer van een SQL-statement en selecteert eenvoudig de laagste. Dat is allemaal heel duidelijk en logisch. Wat kan daar nu aan mis gaan? Met een wiskundige processor kunnen er ten minste twee dingen mis gaan: • Hij kan slechte gegevens als input ontvangen (bijvoorbeeld het oude probleem ‘garbage in – garbage out’ ) • Belangrijke factoren ontbreken in één of meer formules of zijn foutief Tijdens de gehele levenscyclus van Oracle7 kwamen beide problemen voor. De opdracht ANALYZE in Oracle7 had volop fouten waardoor de CBO over slechte statistieken als invoer beschikte. In Oracle8 zijn veel van de fouten in de opdracht ANALYZE opgelost, zodat problemen met betrekking tot slechte invoer niet meer voorkomen. De procedure DBMS_STATS in Oracle8i biedt zelfs betere statistieken dan de opdracht ANALYZE zoals wordt aangetoond door verscheidene ‘bugs’ die in het ondersteuningssysteem MetaLink (http://metalink.oracle.com/) zijn gerapporteerd. Door bij tabellen gebruik te maken van DBMS_STATS in samenwerking met de nieuwe Oracle8i-functie MONITORING, wordt de taak van het verzamelen van geldige en bruikbare CBO-statistieken betrouwbaar en gemakkelijk. Dus dan is dat probleem ook opgelost. Wat we nu nog overhouden zijn enkele subtiele correcties met betrekking tot de formules die de CBO gebruikt om kosten te berekenen. Wat betekent ‘kosten’ precies? De kosten die door de CBO worden berekend, bestaan voornamelijk uit physical I/O. De feitelijke formule wordt gedocumenteerd als
Teneinde te begrijpen hoe gecompliceerd dit kan zijn, kijken we nog even snel naar het begrip I/O in Oracle. Een overzicht van de regels voor de I/O in Oracle In Oracle hebben bewerkingen geen toegang tot rijen, maar toegang tot databaseblokken die rijen bevatten. Bovendien zoekt Oracle niet naar blokken op schijf, het verwacht deze opgeslagen in het gedeelde geheugen, in de Buffer Cache van het System Global Area (SGA) te kunnen vinden. Lezingen van blok buffers in de Buffer Cache worden logical reads genoemd. Er zijn in feite twee belangrijke soorten logical reads: consistent gets en db block gets (ook wel genaamd current gets). Consistent gets zijn blokken die uit een specifieke versie of ‘point-in-time’ opgehaald worden, meestal op verzoek van SELECT-statements. Db block gets of current gets daarentegen zijn blokken die uit de meest recente of huidige ‘point-in-time’ worden opgehaald, meestal met de bedoeling iets te wijzigen, zoals een INSERT-, UPDATE- of DELETE-statement. Een verdere differentiatie tussen de twee soorten logical reads is voor het vervolg van dit artikel niet van belang en we hebben het hier maar even terloops vermeld. Als u naar statistieken in V$SYSSTAT of V$SESSTAT gaat kijken, vindt u geen statistieken die ‘logical reads’ worden genoemd; in plaats daarvan vindt u ‘consistent gets’ en ‘db block gets’. U voegt die twee gewoon samen. Het is duidelijk dat indien de ware database zich niet in het gedeelde geheugen maar op de vaste schijf bevindt, die buffers in de Buffer Cache op de een of andere manier gevuld moeten worden! In het algemeen gebeurt dit wanneer een Oracle-serverprocedure de Buffer Cache controleert op een specifiek databaseblok (oftewel een logical read). Indien het databaseblok zich in de buffer bevindt, gaat alles goed en blijft de procedure haar taak uitvoeren. Maar als het databaseblok zich niet in een buffer in de Buffer Cache bevindt, zal de serverprocedure, die de logical read heeft uitgevoerd, zelf een verzoek (oftewel een physical read) aan het I/O sub-systeem indienen om de buffers te vullen. Daarna gaat de procedure vrolijk verder.
IO + CPU/1000 + NetIO*1.5
OG
VISIE
In deze formule vertegenwoordigt ‘IO’ physical I/O-verzoeken, ‘CPU’ logical I/O-verzoeken en ‘Net I/O’ logical I/Overzoeken aan/van een database op afstand over een databasekoppeling. Dit impliceert dat physical I/O-verzoeken het duurste onderdeel vormen en dat deze het merendeel van de kosten voor hun rekening nemen. Gedistribueerde databasebewerkingen zijn ook nogal kostbaar, maar in de context van dit artikel zullen we ons voornamelijk bezig houden met bewerkingen binnen een enkele plaatselijke database.
20
Wat is het verschil tussen logical I/O en physical I/O? Logical I/O zijn verzoeken voor databaseblokken die in de Buffer Cache van de Oracle SGA zijn opgeslagen. Physical I/O zijn verzoeken van Oracle aan het onderliggende I/O-subsysteem voor blokken die niet in de Buffer Cache zijn opgeslagen. De CBO probeert het aantal physical I/O-verzoeken voor alle mogelijke uitvoerplannen voor een SQL-statement te berekenen en selecteert het plan met het laagste aantal.
Wat gebeurt er wanneer een serverprocedure een logical read uitvoert voor een blok dat zich niet in de Buffer Cache bevindt, dit ontdekt en vervolgens een physical read uitvoert, en een andere serverprocedure wil een logical read uitvoeren voordat de eerste procedure de physical read heeft afgerond? Kunnen beide procedures physical reads uitvoeren? Het antwoord is ‘nee’ . Zodra de eerste procedure ontdekt dat het gewenste databaseblok zich niet in de Buffer Cache bevindt, wijst deze een buffer aan het blok toe voordat de physical read wordt uitgevoerd. Vervolgens wordt die buffer ‘vergrendeld’ en een physical I/O-verzoek ingediend. Als nu de tweede procedure een logical read wil uitvoeren terwijl de buffer vergrendeld is, wordt door deze tweede procedure een wachtrij-gebeurtenis, oftewel een ‘buffer busy wait’ genoteerd en wacht deze totdat het blok weer beschikbaar is. Het is tenslotte niet nodig om meer I/O te veroorzaken dan echt nodig. WERKEN AAN DE ‘SCHAKEL VAN DE CACHE BUFFER’ De Buffer Cache is een cache vol met buffers die door het algoritme least recently used (LRU) wordt beheerd. Door dit
algoritme te gebruiken, worden buffers die het meest worden opgevraagd, aan het most recently used (MRU) einde van een koppelingslijst geplaatst. Nieuwe read-blokken worden in de cache gelezen en aan het MRU-einde van de lijst geplaatst. Wanneer logical reads op buffers uitgevoerd worden, worden deze weer aan het MRU-einde van de lijst geplaatst. Wordt een blok niet opgevraagd, dan verschuift deze langzaam naar het LRU-einde van de lijst. Wanneer deze tenslotte het einde van de lijst bereikt, wordt de buffer ervan door een nieuw read-blok overschreven. Anders gezegd, het blok valt uiteindelijk van het LRU-einde van de lijst af.
scan de inhoud van de Buffer Cache volledig laten verdwijnen.
Twee soorten I/O Oracle kent twee soorten read I/O op gegevensbestanden: • ‘Reads’ op een enkelvoudig blok, willekeurige invoer, meestal met betrekking tot geïndexeerde invoer (tijdens dit I/O-verzoek wordt een wachtrij-gebeurtenis db file sequential read genoteerd) • ‘Reads’ op meervoudige blokken, gevolg-invoer, meestal met betrekking tot de invoer van een VOLLEDIGE tabelscan (tijdens deze I/O-verzoeken wordt een wachtrijgebeurtenis db file scattered read genoteerd), maar kan tevens betrekking hebben op sorteer- en parallel-zoekopdrachten (tijdens deze I/O-verzoeken wordt een wachtrijgebeurtenis direct path read genoteerd)
CACHED I/O IN ORACLE Daarom werd in Oracle7 versie 7.0 een aantal veranderingen geïntroduceerd teneinde dit cache flushing effect te voorkomen. In feite werden de wijzigingen, die we nu gaan beschrijven, eerst in Oracle versie 6.0 geïmplementeerd, maar laten we voor het gemak maar beginnen bij Oracle7 versie 7.0… Ten eerste werden ‘meervoudige-blokken gevolg I/O’ , het handelsmerk van een VOLLEDIGE tabel-scan, totaal anders gehanteerd wat het LRU-algoritme betreft. Wanneer blokken tijdens een VOLLEDIGE tabel-scan in de Buffer Cache werden gelezen, werden deze aan het LRU-einde (en niet het MRU-einde) van de LRU-schakel geplaatst. ‘Enkelvoudigeblok reads’ voor geïndexeerde scans bleven ongewijzigd en werden aan het MRU-einde van de LRU-schakel geplaatst. Maar blokken van een VOLLEDIGE tabel-scan werden vrijwel onmiddellijk overschreven, tenzij deze bijna direct werden ingevoerd (zodat deze naar het MRU-einde van de schakel werden verplaatst). En waarom ook niet? Als je erover nadenkt, komen logical reads tijdens een VOLLEDIGE tabel-scan zelden de gewenste blokken in de Buffer Cache tegen. De oorzaak hiervan is zuiver en alleen het volume. Daarom worden VOLLEDIGE tabel-scans gekenmerkt door het hoge aantal physical reads. Maar hoe vaak worden blokken die door een VOLLEDIGE tabel-scan zijn gelezen, opnieuw ingevoerd? Het eenvoudige antwoord is in de meeste gevallen: zelden. De ontwerpers van Oracle7 hebben dit feit onderkend zodat blokken die tijdens een VOLLEDIGE tabel-scan zijn gelezen, bijna direct worden overschreven, met als gevolg dat tegelijkertijd de effectiviteit van de Buffer Cache als een ware cache behouden blijft.
Laten we maar bij het begin beginnen.
SAMENVATTING VAN DE KENMERKEN VAN
OPMERKING - Bij Oracle8i zijn de regels voor dit LRUalgoritme drastisch gewijzigd. Een nieuw ‘mid-point insertion’ algoritme wordt gebruikt om te proberen ‘latch manipulation’ tot een minimum te beperken bij het toevoegen van blokken aan en verwijderen van blokken van een lijst, vooral wanneer ‘hot’ blokken naar het MRU-einde van een lijst worden verplaatst. Ik heb hier nu geen verdere informatie over; misschien in een volgende update van dit artikel.
HET EENVOUDIGE ‘CACHE I/O’ ALGORITME EN DE’ FLUSH’ -INVLOED DAARVAN
VISIE
De berekening van ‘logical I/O’ in vergelijking met ‘physical I/O’ De bedoeling van de cost-based optimizer is om kosten te berekenen, wat ongeveer neerkomt op physical I/O. Dat is niet zo gemakkelijk als het klinkt. Het berekenen van logical reads is veel gemakkelijker en dat is feitelijk wat de CBO doet. Gezien de informatie over de grootte van tabellen en indexen, het aantal rijen in tabellen, het aantal onderscheiden toetsen in indexen, het aantal niveaus in een B*-Tree index, het gemiddeld aantal blokken in een tabel voor een bepaalde gegevenswaarde, het gemiddelde aantal index leaf koppelingen voor een bepaalde gegevenswaarde, gezien de kennis over de wijze waarop de vier methoden van tabelkoppelingen werken, gezien de informatie van ➤
OG
De regels voor beide soorten I/O kunnen vrij eenvoudig zijn. Wanneer een procedure een databaseblok opvraagt, controleert deze eerst de Buffer Cache. Indien het blok zich in de Buffer Cache bevindt, wordt het gebruikt en ‘verplaatst’ naar het MRU (most recently used) einde van de LRU (least recently used) schakel. Indien het blok zich niet in de Buffer Cache bevindt, wordt het van gegevensbestanden op schijf gelezen, in een buffer in de Buffer Cache gezet en wordt het aan het MRU-einde van de LRU-schakel ‘geplaatst’. Maar in deze eenvoudige formule schuilt een groot probleem. Wat gebeurt er als we deze formule toepassen en de gehele inhoud – elke rij in elk databaseblok – van een tabel scannen die groter is dan de gehele Buffer Cache? Met andere woorden, als we een VOLLEDIGE tabel-scan van een grote tabel uitvoeren? Dan is het onvermijdelijk dat elk nieuw gelezen databaseblok aan het MRU-einde van de LRU-schakel wordt geplaatst, terwijl blokken die een tijdje eerder gelezen zijn, onverbiddellijk naar het LRU-einde van de LRU-schakel worden verschoven en tenslotte uit de Buffer Cache verdwijnen en overschreven worden. Net als een stoomwals zou een VOLLEDIGE tabel-
I/O IN ORACLE Samengevat worden VOLLEDIGE tabel-scans in het algemeen gekenmerkt door het feit dat bijna elke logical read resulteert in een physical read en dat is volkomen normaal. VOLLEDIGE tabel-scans hebben meestal een Buffer Cache succespercentage van 20% of minder (vaak slechts 1% of 5%). Dit betekent dat slechts een klein aantal logical reads wordt omgezet in overeenkomstige physical reads. Geïndexeerde scans daarentegen worden gekenmerkt door een zeer hoog Buffer Cache succespercentage van 95% of hoger.
21
histogrammen over de selectiviteit (of het ontbreken daarvan) van kolomwaarden, gezien de kennis over de wijze waarop verschillende typen B*-Tree en bitmapindexbewerkingen werken, gezien al deze zaken, kunnen de formules die in de CBO zijn opgenomen (en die Oracle met niemand wil delen) snel en nauwkeurig bepalen hoeveel logical reads te verwachten zijn voor elk handjevol, dozijn, honderdtal of duizendtal mogelijke uitvoeringsplannen voor elke SQL-statement. De CBO berekent voor al deze uitvoeringsplannen logical reads, probeert deze om te zetten in physical reads (oftewel kosten) en selecteert vervolgens de laagste waarde. Maar hoe maakt de CBO de sprong van total logical reads naar total physical reads? Bij VOLLEDIGE tabel-scans is dat relatief gemakkelijk! Hij neemt het totaalaantal logical reads (d.w.z. het aantal blokken in de tabel), gedeeld door de waarde van de parameter DB_FILE_MULTIBLOCK_READ_COUNT en ziedaar we hebben physical reads. Aangezien VOLLEDIGE tabel-scans zich onderscheiden door een zeer laag (bijna niet aanwezige) Buffer Cache succespercentage, is dit meestal een geldige formule. Bij geïndexeerde scans, die altijd een hogere cache-waarde scoren, dient deze formule enigszins aangepast te worden. Geïndexeerde scans zijn lezingen van enkelvoudige blokken, dus hoeven we hier met DB_FILE_MULTIBLOCK_ READ_COUNT geen aanpassing aan te brengen. In plaats daarvan is vanaf Oracle8, versie 8.0, een nieuwe parameter OPTIMIZER_INDEX_CACHING geïntroduceerd die hulp biedt bij de aanpassing van logical naar physical I/O. Dit gaat als volgt in zijn werk: CALCULATED-LOGICAL-READS * (1 – (OPTIMIZER_INDEX_CACHING / 100)) = CALCULATED-PHYSICAL-READS
= COST
OG
VISIE
Maar deze parameter heeft een standaardinstelling van nul. Als je de waarde ‘0’ in een formule plaatst, worden logical reads stuk voor stuk in physical reads omgezet, net zoals bij VOLLEDIGE tabel-scans. De standaardwaarde maakt de formule waardeloos. Zo werkt deze dus niet! Ik vind het prettig de parameter OPTIMIZER_ INDEX_ CACHING op 90 in te stellen, hetgeen inhoudt dat 90% van alle logical reads van geïndexeerde scans in de Buffer Cache gevonden kunnen worden. Bij de meeste toepassingen ligt deze waarde waarschijnlijk meer bij 95%, 98% of zelfs 100%. Maar 90% is een goede, voorzichtige waarde om te gebruiken. Begin daar maar mee en u zult een opmerkelijk verschil zien in de selecties die de CBO maakt.
22
Nu moet u mij niet zomaar op mijn woord geloven. Zelf uitproberen! Ga voor uzelf met deze statements experimenteren en verifieer of ze kloppen! U kunt de parameter wijzigen met ALTER SESSION SET OPTIMIZER_INDEX_CACHING = 90. Het bereik van waarden ligt tussen 0 (de standaardwaarde) en 99. Begin met een waarde van 90 en probeer daarna verschillende waarden uit. Bij een waarde-instelling van 99 constateer ik vreemd gedrag, maar probeer het zelf ook eens uit. Voer deze opdracht uit met een EXPLAIN PLAN op een specifiek problematische
zoekopdracht, nadat u de hints, die u met zoveel moeite hebt toegevoegd, hebt verwijderd. De kans is groot dat de CBO het juiste plan selecteert. Indien u van mening bent dat dat meestal bij testvoorwaarden gebeurt, kunt u de initialisatieparameter in het bestand ‘init.ora’ instellen en kijken wat er met de algehele systeemprestaties gebeurt wanneer de instelling globaal wordt ingesteld. Aanpassing voor verschillende typen I/O Maar dit is nog niet alles! De CBO wil ook graag de relatieve kosten van geïndexeerde invoer in vergelijking met VOLLEDIGE tabel-scans weten. De parameter OPTIMIZER_INDEX_ COST_ADJ vertegenwoordigt deze vergelijking. De standaardwaarde 100 betekent voor de CBO dat geïndexeerde invoer ongeveer dezelfde tijd in beslag neemt als een VOLLEDIGE tabel-scan invoer. De CBO gebruikt de waarde van deze parameter om zelfs nog een andere verbetering van berekende kosten voor geïndexeerde scans uit te voeren: PREVIOUS-COST * (OPTIMIZER_INDEX_COST_ADJ / 100) = FINAL-COST
Zoals u duidelijk kunt zien, maakt de standaardwaarde de formule ongeldig, net zoals de standaardwaarde van OPTIMIZER_INDEX_CACHING. Gelukkig kunnen we gemakkelijk een geldige waarde voor OPTIMIZER_INDEX_COST_ADJ ophalen uit de Oracledatabase zelf. Het antwoord is te vinden in de weergave V$SYSTEM_EVENT in de kolom AVERAGE_WAIT. Dit is nog een voorbeeld van de niet te berekenen waarde van de instelling TIMED_STATISTICS in TRUE, zodat de weergave Session Wait (waarvan V$SYSTEM_EVENT er één is) wordt gevuld met tijdsduurinformatie. Nadat de database lang genoeg op normale wijze heeft gedraaid (bijvoorbeeld een paar uur lang), kunt u de volgende zoekopdracht uitvoeren: SELECT
EVENT, AVERAGE_WAIT
FROM V$SYSTEM_EVENT WHERE
EVENT LIKE ‘db file s%’;
Met deze zoekopdracht wordt informatie over de twee I/Owachtrij-gebeurtenissen db file scattered reads (oftewel VOLLEDIGE tabel-scans) en db file sequential reads (oftewel geïndexeerde scans) opgehaald. De kolom AVERAGE_WAIT bevat de gemiddelde tijdsduur van deze gebeurtenissen, weergegeven in 1/100ste van een seconde: EVENT
AVERAGE_WAITS
========================= ============== db file sequential reads
.33178629
db file scattered reads
2.190087
In dit voorbeeld is de tijdsduur van I/O-verzoeken voor een geïndexeerde scan maar 15% van de tijdsduur van I/O-verzoeken voor een VOLLEDIGE tabel-scan. U stelt OPTIMIZER_INDEX_COST_ADJ dus in op 15.
OGh-jaarcongres ‘Oracle Portal’ op dinsdag 7 oktober 2003 in Figi Zeist Samenvatting Er zijn nog andere parameters die van invloed zijn op de CBO, maar die vallen buiten het bereik van dit atikel. Eén ervan is hier wel vermeld: DB_FILE_ MULTIBLOCK_ READ_COUNT. Vraag: welke invloed heeft een zeer hoge waarde voor DB_FILE_MULTIBLOCK_READ_COUNT op de CBO? Is een hoge waarde altijd goed? Wat zijn de mogelijke voordelen (en nadelen) van een lage waarde wat gedragsbeïnvloeding van de CBO betreft? Het op het verkeerde spoor brengen van de CBO door deze parameter te hoog in te stellen, is één van de meest gangbare redenen voor de slechte beslissingen die de CBO neemt na de transformatie van RBO. Er bestaat duidelijk bewijs dat de procedure DBMS_STATS (geïntroduceerd in Oracle8i) statistieken in tabellen, indexen en kolommen veel beter kan berekenen dan de opdracht ANALYZE, die, naar men zegt, snel verouderd zal zijn. U hoeft mij niet op mijn woord te geloven; zoek in MetaLink naar het sleutelwoord ‘dbms_stats’ , zorg ervoor dat u een ‘geavanceerde’ zoekopdracht uitvoert en de invoer van de ‘bug database’ opneemt. Verschillende zaken die in MetaLink zijn vastgelegd in vergelijking met de procedure DBMS_STATS zijn vervolgens opgelost als ‘bugs’ in vergelijking met de opdracht ANALYZE , die als basis voor de vergelijking werd gebruikt. Maar het gevolg van het begrip voor en de juiste instelling van deze twee parameters zet de wereld op zijn kop. Probeer het maar. Ik hoop dat u inziet dat er in feite nog hoop is voor de CBO. De CBO is intelligent en wordt beter, sneller en slimmer met de kracht van een stroomversnelling
Het thema van het OGh-jaarcongres 2003 is bekend! Op 7 oktober is ‘Oracle Portal’ het centrale thema. ‘Portal’ is vandaag de dag een van de leidende thema’s binnen de Oracle-wereld, een ‘hot topic’ zelfs. Het gebruik van portals is weliswaar nog niet wijdverspreid, maar het is wel een kernonderwerp van de toekomst. De mogelijkheden van databasegestuurde internetportals zijn legio en ze staan boven aan de agenda van vele Oracle-gebruikers. Vanuit het thema ‘Oracle Portal’ zullen ook koppelingen worden gelegd met onder andere Linux en Open Source. Het thema zal vanuit meerdere invalshoeken worden belicht. Met name de praktijkervaring zal een prominente rol spelen: aan de hand van gebruikerscases presenteren gebruikers hun ervaringen met Oracle Portal. Ze vertellen hoe het werken met Oracle Portal in de realiteit verloopt. Aan de andere kant presenteren topsprekers uit de Oracle-wereld hun visie op Oracle Portal. Bereidt u zich voor op een interessante discussie tussen deze partijen. Het programma is opgehangen aan het portalfunctionality-model van Oracle. De dag is opgedeeld in drie streams. De stream ‘Portal Platform’ gaat in op databases en infrastructuur, de stream ‘Portal Ontwikkeling’ gaat dieper in op applicatiebouw en de stream ‘Portal in gebruik’ gaat met name in op de businesstoepassingen van de portal. In alle streams zullen zoveel mogelijk gebruikers aan het woord zijn. Meer informatie over het volledige programma verschijnt binnenkort op de website. Het congres is toegankelijk voor OGh-leden en externen! ■
Ook u kunt lid worden van de OGh en ontvangt automatisch OGh Visie d.m.v. onderstaand aanmeldingsformulier. Niet leden kunnen zich gratis abonneren via de website www.oracle-usergroup.nl
Dankbetuigingen De schrijver wil bij deze de onderstaande experts bedanken voor hun ruimhartig gegeven vakkundige advies, voor de correctie van fouten, voor verduidelijking waar nodig en voor aanwijzingen bij dwalingen. In alfabetische volgorde: Jonathan Lewis (JLComputerConsultancy-VK - http://www.jlcomp.demon.co.uk/) Jeff Maresh (Maresh Consulting, Inc., Conifer, CO - VS - http://www.EvDBT.com/) Cary Millsap (Hotsos Enterprises, Ltd., Southlake, TX - VS - http://www.Hotsos.com/) Mogens Norgaard (Miracle A/S, - Denemarken - http://www.MiracleAS.dk/) Craig Shallahamer(OraPub, Inc., Lake Oswego, OR - VS - http://www.OraPub.com/) Eventuele fouten of vergissingen die zich in dit artikel voordoen, zijn uitsluitend die van de schrijver.
Kopieer, vul in en fax naar OGh secretariaat 030 - 696 23 78 of meld je aan via www.oracle-usergroup.nl Naam organisatie ................................................................................................................................ Postadres
..................................................................................................................................................
Postcode/plaats ...................................................................................................................................... Contactpersoon ....................................................................................................................................
Over de schrijver
Telefoonnummer .................................................................................................................................. Datum ................................................................................ Interesse lidmaatschap? ja/nee ❑ A 1 verzendadres/3 personen toegang/contributie h 200,❑ B 3 verzendadressen/3 personen toegang/contributie h 340,❑ C 6 verzendadressen/6 personen toegang/contributie h 450,Geen interesse lidmaatschap, wel interesse (gratis) OGh Visie ja/nee
OG
OGh leden ontvangen 15% korting op specials van Oracle University via
VISIE
Tim Gorman is al bijna 20 jaar werkzaam in de informatietechnologie, voornamelijk als ‘C’ -programmeur en ontwerper. Hij is vanaf 1990 als applicatieontwerper bij Oracle RDBMS werkzaam en vanaf een donkere, stormachtige nacht in 1993 als databasebeheerder van Oracle. Hij is hoofdadviseur bij Evergreen Database Technologies, Inc. (http://www.EvDBT.com), een advies- en opleidingsbureau voor op Oracle gebaseerde technologie, gevestigd in Evergreen in Colorado. Tim Gorman is, in willekeurige volgorde, gespecialiseerd in databasebeheer, afstemming van prestaties, geavanceerde probleemoplossingen, backup, herstel, het maken van grappen en snowboarding. ■
www.oracle.com/nl/education/specials
23
Dé applicatieserver met business intelligence Business Intelligence
Applicatie integratie
Content management
Oracle9i Application Server Web services
Portal
Wireless
Java J2EE
Alle middelware geïntegreerd in één applicatieserver.
oracle.com of bel 0800-0827
Copyright © 2003 Oracle. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates.