Oracle kryber til korset: Forhandler igen med Posten

Posten Norden forhandler nu med Oracle om at genoprette tilliden og kundeforholdet efter en kurre på licens-tråden.

Posten Norden og Oracle forhandler nu om at finde en aftale om licenspriser, som begge parter kan være tilfredse med. Version2 erfarer, at parterne har haft indledende sonderinger om at genskabe kundeforholdet, efter at Posten Norden havde smækket med døren i vrede over Oracles licensbetingelser.

Oracle røg ud i kulden efter at have sendt en det nyfusionerede Posten Norden AB en opkrævning på 22 millioner kroner som såkaldt 'name change fee' for de eksisterende databaseløsninger i de danske og svenske postvæsener. Det fik posten til at kigge sig om efter alternative databaseleverandører som for eksempel SAP.

Nu forhandler parterne angiveligt igen, selvom det ikke er bekræftet fra officielt hold. Om viljen fra begge lejre til at nå en løsning er stor nok, vil formentlig vise om et par uger. Her vil spændingen så muligvis også blive udløst, om hvorvidt Oracle tog imod Miracle-direktør Mogens Nørgaards råd om at diske op med øl og lagkage for at redde forholdet.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (36)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Deleted User

Forstår ikke Oracles holdning til kundepleje.

Det er kunderne man skal leve af, så sender man dem ikke bare en stor regning.

Måske det havde været bedre med en dialog først og så om nødvendigt udskrive en regning.

Jeg ville nok vælge at bruge Microsofts SQL Server i stedet for, det er også billigere og licensreglerne er til at overskue.

  • 0
  • 0
#5 Pascal d'Hermilly

Næh tak. Så skifter du bare til en anden licens-indehaver. Plus at min tiltro til Microsofts ressource-håndtering er meget lille.

Så hellere skifte til den fedeste open source database. PostgreSQL. Den er der noget ved!

Når det er sagt, så synes jeg hele sagen en fuldstændig absurd. 22 millioner kroner gebyr for en non-service!

  • 0
  • 0
#6 Deleted User

Kan godt tilslutte mig den med PostgreSQL, det gør også at man ikke skal skifte database hvis en leverandør får en hjerneblødning og opkræver urimeligt mange penge.

Men jeg vil tro de fleste virksomheder i DK er mest trygge ved at der står en virksomhed bag og at det er et "produkt" og for dem vil jeg mene at Microsofts SQL server er det bedste valg.

Klart at hvis man arbejder med Oracle og muligvis også har ofret en del på certificeringer, så syntes man jo som udgangspunkt ikke at Microsofts SQL server kan klare store databaser, men det kan den godt, bare den får de rigtige betingelser, det gælder iøvrit også for Oracles database at hvis det er en database med "kød" på så skal dr også noget "solidt jern" bageved så det spiller plus.

Nå alt det er sagt, så syntes jeg ofte at disse kommentarer er ret usaglige og at version2 er præget af at de fleste kommentatorer er open source hippier som ikke kan se andre løsninger end deres som de bedste.

Oracle folk har måske også det problem at de ser Oracle som løsningen på alt...måske derfor at databasen hedder Oracle G.

Jeg har ikke tænkt mig at deltage i flere debatter.

Kan godt forstå at Computerworld har valgt at lade være med at lade læserne kommentere indholdet.

;-Peter

  • 0
  • 0
#7 Christian W. Moesgaard

"Nå alt det er sagt, så syntes jeg ofte at disse kommentarer er ret usaglige og at version2 er præget af at de fleste kommentatorer er open source hippier som ikke kan se andre løsninger end deres som de bedste."

Hvordan kan du skrive sådan noget og kalde vores holdninger usmagelige i samme afsnit?

Nogle OpenSource-produkter ER faktisk de bedste (eller meget nær toppen) eks. MySQL, Firefox, OpenOffice, Google Earth osv.

At man godt kan lide et OpenSource produkt gør ikke en til en OpenSource hippie, hvilket du tilsyneladende synes?

  • 0
  • 0
#8 \n \r

At man godt kan lide et OpenSource produkt gør ikke en til en OpenSource hippie, hvilket du tilsyneladende synes?

Man skal være en meget blind høne for ikke at se at version2 er et tilholdssted for rigtig mange IT-pedeller der har en forkærlighed for åbenkode løsninger.

  • 0
  • 0
#10 \n \r

Version2 er glatbarberet for teknisk indhold så reelt er det mindet imod et IT-pedel publikum og måske ikke så meget udviklere.

Der er meget politik - propaganda i mange af de artikler version2 vælger at bringe. Igen det skal man ikke havde gået i nogen særlig rød skole for at kunne se.

  • 0
  • 0
#11 Claus Nielsen

v2 community er som de fleste af denne type forums fyldt med kommentarer fra snævertsynede typer som tror at deres erfaringer fra deres hobby projekter direkte kan overføres til enhver situation i den virkelige verden. Det er også korrekt at opensource hippierne hyppigt gør sig uheldigt bemærket, men personligt finder jeg også interessante kommentarer og nye vinkler.

Nå men tilbage til sagen: Posten har udtrykt at de har 2 alternativer til Oracle: DB2 SAP DB (MaxDB som tilsyneladende er opensource)

Et konverteringsprojekt vil efter min vurdering nok også koste et tocifret antal mio og formodenligt er der stadigt en masse legacy applikationer som ikke er konverteret til SAP. Det mindst smertefulde for Posten vil nok derfor være at lade sig afpresse for et par mio. Det bliver interessant at høre om Oracle DK er istand til at fremsætte et fornuftigt tilbud. Det kan godt være at Posten selv syntes at de er en Enterprise kunde men jeg tror at Oracle US betragter dem som en SME. Hvis du ikke er på fortune 500 bliver du generelt pisset ned af nakken af amerikanerne.

@Peter Vi kan godt være enig om at MSSQL næsten kan det samme som Oracle idag og specielt med SAP applikationen. Når Posten ikke nævner det som et alternativ antager jeg at det er fordi der ikke findes Wintel servere som er kraftige nok.

@Pascal Postgres er ikke certificeret med SAP og har også ry for ikke at kunne håndtere store datamængder.

  • 0
  • 0
#12 Deleted User

Hej Peter et al -

Jeg giver meget gerne en omgang chokoladekage og Rochefort 10 (en belgisk øl på 11.3%) en eftermiddag eller aften, hvor I måtte have lyst til at smage det.

Det er meget overraskende.

Der er også andre øl, der egner sig til kager, men det kan vi jo tage hen ad vejen :-).

Søndag den 31. januar om eftermiddagen var en mulighed...

mvh.

Mogens

  • 0
  • 0
#13 Gert Agerholm

Davor Olik:

Man skal være en meget blind høne for ikke at se at version2 er et tilholdssted for rigtig mange IT-pedeller der har en forkærlighed for åbenkode løsninger.

Kom venligst med dokumentation for at Open Source ikke kan bruges i professionelle løsninger.

Eller hvad med f.eks.

ODF redder region Midtjylland fra problemer med Microsoft Office

http://www.version2.dk/artikel/13491-odf-redder-region-midtjylland-fra-p...

Devoteam: Microsoft Office giver ikke mere produktive medarbejdere

http://www.version2.dk/artikel/13473-devoteam-microsoft-office-giver-ikk...

  • 0
  • 0
#14 Claus Nielsen

@Gert

Du bekræfter på smukkeste måde at v2 er fyldt af folk i meget små sko.

Det er forhåbenligt kun de mest indskrænkede som ikke tror at open source kan/bliver integreres i professionelle løsninger. Min påstand er at store virksomheder har de største benefits af open source. En af mine kunder har 15.000 webservere med Apache og Linux. Det koster dem 5 fuldtidsresourcer som udover at lave lidt kerneudvikling vedligeholder deres custom software stack. Men sådanne gode eksempler betyder ikke at alle problemer kan og bør løses med Open Source.

  • 0
  • 0
#15 Per Erik Rønne

Pascal d'Hermilly foreslår at man skifter til PostgreSQL.

Det forstår jeg ikke. Jeg har nemlig selv erfaring fra såvel Oracle som PostgreSQL, og når jeg har forsøgt med et view til en simpel adressedatabase til sidstnævnte med kun 1500 indgange, med fire tabeller [indgange, numre {telefon, mail, etc], adresser og post {nummer og distrikt}] kan det tilsyneladende tage timer at få svar på en simpel forespørgsel.

Til sammenligning er Oracle klar »med det samme« på væsentlig større databaser, med mange flere tabeller og med væsentligt mere komplekse views.

  • 0
  • 0
#16 Anonym

Flere timer....Postgre har jeg ikke personlig erfaring med men MySQL har jeg stor erfaring med og kan ikke forestille mig Postgre skulle være specielt meget dårligere. Så nu provokeres jeg mens jeg små griner lidt, lyder som om der er nogen som ikke forstår at skrive syntax...eller også har der været en fejl andet steds f.eks. data strukturen. - søgning i 1500 records og 4 tabeller kan aldrig tage så lang tid uanset valg af DB.

Har selv erfaring fra informix, mySQL og MSSQL. Af de 3, foretrækker jeg mySQL, primært fordi min tankegang omkring syntax er meget lig den som anvendes i mySQL - hvilket jo nok for den enkelte er den vigtigste parmeter, og grunden til at vi alle syntes at vores foretrukne DB preformer bedst

alt i alt tror jeg vi alle kan blive enige om at netop den DB som vi selv foretrækker er den bedste...ellers har vi jo valgt forkert.

valg af bedste DB for Posten afhænger derfor i høj grad af ekspertisen hos dem som udvilker deres applikationer.

  • 0
  • 0
#17 Per Erik Rønne

Tjae, da jeg på et tidspunkt satte mig ind i mySQL havde den slet ikke views, og jeg kunne da sagtens forestille mig at det var fordi det ville køre for langsomt.

PostgreSQL kører vel også udmærket når man holder sig fra views, som man bare bruger stærkt når man accesser den fra en linieorienteret grænseflade à la Oracles SQL*Plus.

  • 0
  • 0
#18 Deleted User

Det er svært at diskutere tilfældet uden konkret kode, men under alle omstændigheder er det ikke noget vi kan bruge til at vurdere Postgre ud fra, hvis vi skal kigge på hastighed må vi gå ud fra eksempler hvor der er kodet nogenlunde optimalt imod databasen. Om det så er let at skrive den kode er et andet spørgsmål.

  • 0
  • 0
#19 Deleted User

Det er stort set dét de laver. For alt det andet som de kan (og som er fantastisk) bruger folk slet ikke mere.

De bruger databaserne som datadumps fordi de har fået undervisning af folk (uden indsigt) på læreanstalterne, som sniksnakker om at databaser skal være 'agnostiske', hvilket - for tænkende mennesker - betyder, at man overhovedet ikke skal bruge deres fede, indbyggede features i portabilitetens hellige navn - men alligevel ender med at lave applikationer, der er afhængige af den konkret anvendte database.

Derfor har I jo alle ret: Alle databaser kan bruges til alt. Det er bare et spørgsmål om ikke at bruge dem. Og den udfordring klarer nutidens unge programmører helt fint. De er glade for at få lov til at opfinde den dybe tallerken, den flade tallerken, sidetallerknen, og ikke mindst kniv, gaffel og ske igen og igen og igen.

Alt det man kan proppe ned i en RDBMS, såsom regler, kode, sikkerhed m.m.m. gør alting nemmere i det lange løb og er præcist det diverse fjollehoveder har prædiket man skal lade være med i de sidste 10-15 år. Efter devisen: Man skal altid foreslå det modsatte af det folk gør nu. Ellers virker man ikke seriøs.

MySQL i sig selv er vel ikke noget - jeg går ud fra, at I taler om InnoDB? Thi Heikko kender jeg, og han gik decideret efter at lave en Oracle-klon. Og det gik jo godt på mange områder, bl.a. fordi det var ret let for ham at lave en road-map for, hvad den skulle kunne :-).

PostGreSQL har vi (Miracle) selv brugt som front til et system for et telefonselskab, hvor vi replikerede data fra en Oracle-database ud til PostGreSQL-databasen og pumpede data tilbage som batchjobs, således at de slap for en urimelig licens-afgift. Det virker fint, nu på fjerde år. Den ser ud til at være fremragende.

SQL Server er jo lavet af langhårede, bitre, gamle mænd, der for nogles vedkommende har været med til at skrive de oprindelige UNIX'er, så mon ikke det er et mindst lige så professionelt produkt som alle andre databaser?

Jeg tror alle problemer kan løses med al teknologi, bare der er nok dygtige folk til stede, som får lov til at arbejde istedet for at lave Kontrol- Og Rapporterings-Fræs aka KORF (TM).

Men jeg kan hver dag græmmes over, hvor meget tant og fjas der går for sig i kode-kamrene istedet for at man bare lytter en lille bitte smule til folk med erfaringer eller gode idéer, der måske går imod den seneste mode på universiteterne eller i management-konsulent-biksene.

Mvh.

Mogens

  • 0
  • 0
#22 Michael Mortensen

Mogens, hvad mener du når du skriver, at folk ikke bruger de "smarte" features i en database?

Nu er jeg selv tilhænger af MS-SQL, og her designer jeg med henblik på OLTP, altså en normaliseret database, og hvis behovet opstår, så "kloner" vi nogle af dataene over i en OLAP model for øget performance (groft sagt).

En af de andre gutter herinde skriver, at det tog flere timer at procesere 1500 rækker; det kan kun ske hvis mere eller mindre hele tabellen er låst af andre forespørglser, men det virker urealistisk.

Det er muligt jeg giver dig et kald en dag - ellers ser jeg frem til et open-event på din Miracle side ;-)

  • 0
  • 0
#23 Deleted User

Sidst jeg var på et universitet handlede det om at skrive så komplicerede SQL sætninger som muligt. Eller i hvert fald at udføre opgaver som er mere komplekse end hvad der er behageligt at prøve på at skrive i et "one-liner-sprog", uden hensyntagen til kørselstidsbetragtninger. Jeg ved ikke om det var der du ville hen?

  • 0
  • 0
#24 Deleted User

Hej Michael,

Jeg er jo ikke Indehaveren Af Sandheden (IAS - TM), men i 90'erne brugte vi virkelig meget tid og energi på at putte logik og kode ned i databasen. Det viste sig nemlig, at alt hvad vi kunne proppe derned (stored procedures, stored functions, sikkerhedsting, og logik og regler) var SÅ nemt at a) portere til næste version og b) superhurtigt og skalerbart.

Min gode ven Toon K har lavet en fremragende blog om det: http://thehelsinkideclaration.blogspot.com/ og han har vitterligt noget at have det i: Han har lavet det hollandske bookhuis (bookhouse), der svarer til Amazon, med sine principper.

Nu med hensyn til en open event-ting hos os: Det har vi faktisk holdt en del af. Jeg er en meget stor tilhænger af det, og mine gutter (alle sammen ordblinde autister, som man kunne formode) er også, så vi er klar.

Glæder mig til at høre fra dig.

mvh.

Mogens

  • 0
  • 0
#25 Deleted User

Hej Jacob,

Det med komplicerede SQL-sætninger har to ansigter: Det kan være fordi man gerne vil gøre jer lige så dygtige til at lave uforståelig kode som de der tools man køber nu om dage - eller det kan være fordi man ville lære jer rent faktisk at fatte SQL's store styrke, hvilket de fleste ikke gider idag.

Which one is it?

Mvh.

Mogens

  • 0
  • 0
#28 Per Erik Rønne

Michael Mortensen skrev:

=

En af de andre gutter herinde skriver, at det tog flere timer at procesere 1500 rækker; det kan kun ske hvis mere eller mindre hele tabellen er låst af andre forespørglser, men det virker urealistisk.

Det var mig der skrev det, men du har misforstået det noget.

For det første var der ikke andre forspørgsler i gang, da databasen kørte på en maskine, som kun jeg havde adgang til [faktisk en Synology netværksharddisk der kørte Linux].

For det andet bestod tabellen ikke af 1500 rækker. Det drejede sig om en database med fire tabeller: indgange [med 1500 rækker], adresser [detail i forhold til indgange], numre [telefon, mail, detail i forhold til indgange] og post [master i forhold til adresser, som indeholdt postnumre men ikke postdistrikter].

Denne ganske lille kontaktdatabase skabte jeg et view til, så den virtuelt fremstod som én tabel. Og det var den der tog så lang tid at søge på, at jeg helt opgave bruge PostgreSQL. Jeg brugte en kommandolinie-grænseflade svarende til Oracles SQL*Plus.

Jeg har lavet noget tilsvarende på væsentligt større databaser i Oracle, og aldrig stødt ind i noget tilsvarende, selv ikke da jeg under mit speciale brugte en Apollo med Oracle installeret. Der var der dog problemer i begyndelsen, inden den fik sin RAM fordoblet fra 2 til 4 MB - ja, det er tyve år siden.

Så der hvor det nok går galt for PostgreSQL er nok i implementeringen af views. »Virtuelle tabeller«.

  • 0
  • 0
#29 Deleted User

Uden en trace af kørslen er det umuligt at sige noget om performance på dit joinview.

I en tidligere version af Oracle kørte en af mine gutter engang en direct load test på sin hjemme-PC (med én langsom disk) der bankede 18.000 Call Data Records ind i basen per sekund sustained over et godt stykke tid.

Så snart han lagde et index på primær-kolonnen faldt det til 150 CDR'er per sekund.

Et view er blot et select, intet andet. Dictionary'en gemmer kun dette select samt lidt metadata om ejerskab, etc. Så det er selve dette select, der ikke performer, hvilket antyder, at der skal ændres i enten selve formuleringen af selectet eller indexeringen eller summeringer.

Indexering: Enten skal der tilføjes index(er), der mangler i f.eks. join-kolonner, eller også skal brugen af index(er) undertrykkes (det er nogle gange bedre at scanne end at læse hver række via et index).

Summering/aggregering bruges også (via forskellige mekanismer) til at pre-bearbejde data, så man sparer arbejde.

Oracle har bestemt nogle rimeligt seje ting i sin optimizer nu om dage, som kan lave meget snedige ting i.f.m. joins, f.eks. ved at bruge hashing-algoritmer til at tælle antallet af distinte værdier (fremfor at læse og sortere dem og bruge masser af memory på dét), men simple ting som dette eksempel burde nok i virkeligheden næsten køre hurtigere på de "små" (kodebase-mæssigt) databaser qua deres kortere code-path :-).

mvh.

Mogens

  • 0
  • 0
#31 Deleted User

Ganske enig. PostGreSQL er rigtig god, og den er i mine øjne også væsentligt bedre end MySQL. Men det blev MySQL, der kom ind på læreanstalterne, og så kan lærerne, selv på de højere anstalter, ikke finde ud af andet, når de skal undervise.

Og det er ærgeligt, for hvis man skal køre Open Source kan jeg ikke se noget som helst hos MySQL der er bedre end PostGreSQL - men her vil jeg til gengæld meget gerne korrigeres, så jeg håber nogen vil fortælle om nogle fede features i MySQL, som ikke findes i PostGreSQL...

På AUC (det hedder vist bare AU nu) havde de i mange år et databasecenter (det har de måske stadig), hvor man støttede dem fra Oracles side (jeg og Martin Jensen og sådan nogle var deroppe ind imellem, og de fik software at lege med, etc.), så derfor lærte en masse folk deroppe om Oracle.

Det er vigtigere end man tror, det med at få sneget software ind på læreanstalterne.

Mvh.

Mogens

  • 0
  • 0
#32 Deleted User

For nu lige at være sikker på at vi ikke snakker mere forbi hinanden end højest nødvendigt. Selvfølgelig er det ikke enhver nested query som slår ydelsen ihjel. Brugt rigtigt er det et fint nok værktøj, det har blot potentiale til at tvinge databasen ud i en umanerlig stor omgang "tjek alle kombinationer".

Men jeg kan forstå at jeg nu er tvunget til øl og kage d. 31. :-)

  • 0
  • 0
#33 Deleted User

Spot on, jacob. Alle access-veje kan være gode eller dårlige, afhængig af vejret og CO2-udslippet og måske endda datamængder og -fordeling :-).

Det viser sig, at en af de store fejlkilder i Oracles optimizer - at den til tider valgte underligt pga en forkert værdi for NDV (Number of Distinct Values - m.a.o. kardinaliteten) - skyldtes en forkert måde at tælle på, og det er så blevet rettet i version 11g.

Det viser for mig at se IKKE, at Oracles optimizer-team (under ledelse af Håkån, som har lagt navn til hakan-faktoren i optimizere) er dumme eller dårlige, men at det er ret komplekst at lave den slags ting.

Jeg glæder mig til at servere chokoladekage og Rochefort 10 for dig (og andre, der måtte være interesserede) den 31....

Mvh.

Mogens

  • 0
  • 0
#35 Jesper Krogh

Hej Mogens.

Oracle har bestemt nogle rimeligt seje ting i sin optimizer nu om dage, som kan lave meget snedige ting i.f.m. joins, f.eks. ved at bruge hashing-algoritmer til at tælle antallet af distinte værdier (fremfor at læse og sortere dem og bruge masser af memory på dét), men simple ting som dette eksempel burde nok i virkeligheden næsten køre hurtigere på de "små" (kodebase-mæssigt) databaser qua deres kortere code-path :-).

Postgresql har skam også Hash-aggregates. Og for dem der gerne vil migrere fra Oracle, så leverer EnterpriseDB http://www.enterprisedb.com/ et en masse oracle compatibillitet: http://www.enterprisedb.com/solutions/tech_case.do ovenpå.

Der er selvfølgeligt en masse Oracle kan og er bedre til, men det er ikke den komplette liste af ting databasen kan gøre for en man skal kigge efter, men den komplette liste af ting som ens applikation har brug for (og vil få brug for i nær fremtid).

  • 0
  • 0
#36 Deleted User

Hej Jesper,

Tak for infoen.

Jeg kan godt se, hvad du mener med at kigge efter den komplette liste af ting, som ens applikation har brug for og får brug for i den nære fremtid - men det er en total umulighed af en utopisk vision du dér stiller op.

Den slags hensigtserklæringer ender altid med, at man fokuserer på et par enkelte ting og så ellers siger 'lad os komme videre' og så indretter kodekarlene sig efter den valgte database (eller fil-løsning) :-).

Og eftersom man ikke lærer noget som helst idag på læreanstalterne om, hvad en RDBMS egentlig formår, men til gengæld lærer at kode 'database-agnostisk Java', så er det jo alligevel bare en datadump og ikke en database folk bruger i de systemer der laves for tiden.

Og så er cirklen sluttet :-). Det synes jeg naturligvis er meget ærgeligt både fordi databaser og deres muligheder er og bliver min store kærlighed, og for det andet fordi kodningen bliver mere og mere ineffektiv, fordi man ikke udnytter mulighederne i de forskellige RDBMS'er.

Mvh.

Mogens

  • 0
  • 0
Log ind eller Opret konto for at kommentere