Discussie Intel en Oracle over dual-core licenties gaat door

Intel probeert Oracle nog steeds over te halen om zijn licentiebeleid met betrekking tot dual-coreprocessors te hierzien. De databasegigant, die met de recente miljardenfusie PeopleSoft en J.D. Edwards heeft ingelijfd, heeft besloten om klanten voor iedere core apart te laten betalen. Intel pleit er daarentegen juist voor om licenties per complete processor te verkopen. De chipbakker wordt daarbij gesteund door HP, zijn grootste partner op het gebied van high-end Itanium-servers. Later dit jaar zal de eerste dual-core Itanium verschijnen in de vorm van Montecito, gevolgd door varianten met vier of nog meer cores in de jaren daarna. Hetzelfde verhaal geldt voor Xeons. De hardwarebedrijven vrezen dat softwarekosten van Oracle de pan uit zullen rijzen als het vasthoudt aan zijn huidige beleid. Het tegenargument is dat er juist minder processors nodig zullen zijn voor dezelfde prestaties, zodat klanten die per core betalen netto nog steeds even duur uit zijn.

Een nieuw argument dat Intel en HP in de strijd gooien is dat van virtualisatie. Als servers op processorniveau verdeeld kunnen worden in meerdere partities en er zelfs software gedraaid kan worden op virtuele cores wordt het te verwarrend om per core licenties te verkopen. Volgens HP is het dan ook een kwestie van tijd voor Oracle zijn standpunt moet gaan herzien. Ondertussen zijn andere softwarebedrijven wel - of in ieder geval deels - overtuigd door de lobby van Intel. Microsoft zal zijn producten per processor verkopen, en BEA rekent voor de tweede core slechts een kwart van het bedrag dat normaal voor een tweede processor betaald moet worden.

De Montecito-core

Ook bij bedrijven die alleen in processors denken wil men echter meer flexibiliteit loskrijgen. In de high-end wereld is het namelijk niet ongebruikelijk om bijvoorbeeld bij een klant die 16 processors nodig heeft een server met 32 processors neer te zetten, waarvan de helft gewoon niet gebruikt wordt. Zodra er later extra capaciteit nodig is zal deze praktisch direct beschikbaar zijn, en pas vanaf dat moment hoeft er voor de in eerste instantie overtollige hardware betaald te worden. Met virtualisatie en meerdere cores per processor worden dit soort verkoopconstructies makkelijker en dus waarschijnlijk ook populairder om te gebruiken. De softwarelicenties zijn vaak echter niet flexibel genoeg om met deze scenarios om te gaan. Het bedrijf uit het voorbeeld zou vanaf dag één al voor 32 processors software moeten betalen, en van dat 'ouderwetse' idee willen Intel en HP dus ook af.

Reacties (46)

[TheekAzzaBreek]

Hier heeft HP het beste argument dunkt me. Als we straks met virtuele cores gaan draaien, is zo'n licencing schema niet meer vol te houden.

Maar verder: als 2 cores net zo snel zouden zijn als 2 cpu's, waarom zou dat dan goedkoper moeten? Als ze niet even snel zullen zijn, wat ik verwacht, ligt een korting wel voor de hand, maar voor niks? Iemand die me dat kan uitleggen?

[Vorlon]

Mja, moet iemand met een 2x zo snelle cpu dan ook 2x zo veel betalen? Dat is namelijk nu niet zo.

Het is nu vaak goedkoper om een nieuwe server met single proc te kopen dan om de oude met een 2e cpu uit te rusten. (compaq/hp en consorten verkopen de dual capable servers meestal met 1 cpu.)

[PuzzleSolver]

Waarschijnlijk heeft meer geheugen en een snellere Harddisk configuratie in de meeste gevallen meer invloed op een databaseserver dan een tweede processor.

Ik vind de gedachtegang om meer te moeten betallen voor software omdat er meer processoren in de machine zit waar het op draait is typisch weer zo'n meetbaar management verkoop instrument. Vanuit een technisch oogpunt slaat het nl. helemaal nergens op, want dan zou je moeten betalen voor de prestaties van het systeem als geheel (oftewel betalen voor een benchmark score?)

[TheekAzzaBreek]

Er zit toch wel logica achter: voor licht gebruik betaal je minder dan voor zwaar enterprise level werk. Zonder dat zou Oracle te duur zijn voor veel wat kleinere toepassingen.

Vroegah had Oracle licenses per seat, of per named user. Dat was helemaal een ellende, zou je ieder jaar je license moeten herzien. Dan liever iets simpels en -relatief- stabiels als het aantal cpu's.

@vorlon: Oracle draait in de praktijk eigenlijk alleen op multi cpu servers. Als je het met een cpuutje af kan, kan je waarschijnlijk ook wel met een lichtere database af.

[Zwartoog]

Mja, moet iemand met een 2x zo snelle cpu dan ook 2x zo veel betalen? Dat is namelijk nu niet zo.

Ben ik de enige die hier een goede meetlat in ziet, dat je betaalt naar de prestatie die je systeem kan leveren? Dan maakt het niet uit welke configuratie je systeem heeft.

Uiteraard moeten de prijzen wel jaarlijks aangepast worden aan de dan geldende CPU kracht.

[Verwijderd]

Die hele licenties per processor in onzin. Er wordt vanuit gegaan dat die machine alleen maar gebruikt gaat worden door het pakket waar de licentie per processor voor is aangeschaft, maar er draait nog meer op een machine dan alleen die app.

Stel je hebt voor de database een 4 cpu machine nodig en voor het pakket ook een 4 cpu machine. Laat je ze beide op een machine draaien dan heb je dus een 8 cpu machine nodig, gevolg tweemaal zoveel kosten tegen dezelfde performance.

[tjbrink]

In enterprise apps vaak niet de bedoeling.

Voorbeeld: PeopleTools 8.4x omgeving
Daar heb je een db-server nodig, een app-server en een web-server. Die app-server moet veel cpu-power hebben, die db-server cpu-power + veel geheugen + snelle disk-io.

Dan zou je dus een dure 8-way machine neer zetten met snelle disk-io etc. terwijl je het niet nodig hebt. Dan neem je juist 1x een 4-way db-server (met snelle disks etc.) en daarnaast app-servers (en web-servers). Dit omdat de oplossing van alles op 1 machine plaatsen er voor zorgt dat de performance niet optimaal is. (de verschillende soorten applicaties horen niet bij elkaar op 1 machine).

[Verwijderd]

Of nog eerlijker:

Betalen per aantal execution units.
Of per aantal mips
...

not dus... beetje onzin dit hele verhaal

[Schapie]

Als je meerdere core's op een proc kan maken wordt de benodigde ruimte kleiner. Dus kost het minder ruimte.
En het ligt natuurlijk aan welke programma's je draait of twee core's sneller zijn dan een want de meeste spellen zijn bijv. singlethreaded maar database's enzovoort zijn heel vaak mutithreaded (Kunnen ze iig aan).

[Verwijderd]

Duidelijk geval van de klok gehoord maar niet weten waar de klepel hangt.

[DP Kunst]

ik vind het onzin dat je meer moet gaan betalen omdat je een processor extra erin hebt zitten. het is toch allemaal hetzelfde systeem. ik vind dit net zoiets als dat je strax dubbel moet betalen voor een spel omdat je 2 beeldschermen aan je pc hebt hangen of omdat je er 2 videokaarten in hebt ziten. je betaald dan voor de prestaties en niet voor het programma, wat je toch eigenlijk koopt.

[curry684]

ik vind het onzin dat je meer moet gaan betalen omdat je een processor extra erin hebt zitten. het is toch allemaal hetzelfde systeem. ik vind dit net zoiets als dat je strax dubbel moet betalen voor een spel omdat je 2 beeldschermen aan je pc hebt hangen of omdat je er 2 videokaarten in hebt ziten. je betaald dan voor de prestaties en niet voor het programma, wat je toch eigenlijk koopt.

En exact waarom vergelijk je nu spellen met databases? In het bedrijfsleven is het heel normaal om licenties per CPU af te sluiten, omdat dat direct invloed heeft op het aantal licenties dat je koopt. Jij gaat nooit 2 of 4 licenties van hetzelfde spel kopen omdat het 1 enkele gebruiker blijft dienen, terwijl die databaseserver met 4 CPU's wel bijv. 10000 klanten kan bedienen ipv 2500 met 1 CPU. Vandaar dat dit licentiemodel bestaat, en vandaar dat iedere vergelijking met spellen scheef gaat.

[demonite]

Jup, maar als ik mijn oude server ( bv 2x xeon P3 1.5 gHz ) upgrade ( naar bv een 2x xeon ht p4 3.6 ghz ) bereik ik ook meer gebruikers. En ik heb nogsteeds genoeg aan mijn 2x cpu licentie.

Het is misschien niet onredelijk om de licentie af te laten hangen van de performance van je server, maar wel als dat alleen maar op basis van het aantal cpu's gaat. Beetje vreemd vind ik dat wel.

[Verwijderd]

Hoe zit dat eigenlijk met hyperthreading onder zowel Windows als Linux? Onder linux is een hyperthread processor ook in bijna alle opzichten een 2e processor. Weet iemand hier hoe dat zit qua oracle licenties?

[Verwijderd]

Oracle rekent elke multicore als een tweede processor. Hyperthreading wordt gewoon als 1 processor gezien. Deze houding gaat ze volgens mij veel marktaandeel aan Microsoft kosten die multicores gewoon als 1 processor rekent.

[nAFutro]

Oracle zou dit alleen vol kunnen houden als Microsoft deze methode ook teopast op hen SQL server.
En hou kan Microosoft nu goed ontwikkelaars en klanten lokken? goedekope licenties als je vergelijkt mat Oracle, Dus hanteren ze in Redmond per fysieke processor.

[Modalen]

Met alle respect voor SQL server... er zijn weinig grote bedrijven die bedrijfskritische toepassingen hebben draaien op deze server. Juist deze bedrijven kiezen vaak voor Oracle, en dit zijn ook niet de bedrijven die kijken op een paar duizend euro meer of minder. Dus volgens mij hoeft Oracle zich wat dit betreft helemaal niets aan te trekken van wat MS doet.

[curry684]

Met alle respect voor SQL server... er zijn weinig grote bedrijven die bedrijfskritische toepassingen hebben draaien op deze server.

Dat zal ik m'n collegae bij Philips eens uitleggen die alle datawarehouses, saleshistory en alles in SQL Server hebben zitten

[Verwijderd]

Oops.. Zal ik inderdaad maar ff doen.. Hebben ze toevallig ook replicatie aanstaan? Zo ja, zou ik ze nu direct nog even bellen

[Gabberhead]

Ahum?

Dan mag jij me toch eens uitleggen waarom er Oracle toepassingen bij Phillips draaien met datawarehouses en saleshistory

Ik weet niet precies hoever in de organisatie het doorwerkt, maar collega's van me hebben oa bij Pillips Lighting een Forms applicatie gebouwd (als klein voorbeeldje).

[raptorix]

Als je proffesioneel met beide database servers gewerkt hebt, weet je dat SQL Server echt niet onder doet voor Oracle, Oracle wil mensen graag doen geloven dat hun database de enige stabiele is, dat was misschien in de vorige eeuw zo maar tegenwoordig gaat dat niet meer op.
Het punt dat bedrijven graag op Oracle blijven draaien is met name te danken aan het feit dat men erg conservatief denkt over migraties van databases, dat is op zich logisch maar het zegt dus niets over de database op zich.

[Verwijderd]

Het nadeel van sql server is dat het op windows draait.
Heeft dus niet met conservatisme te maken.

[curry684]

En hou kan Microosoft nu goed ontwikkelaars en klanten lokken? goedekope licenties als je vergelijkt mat Oracle, Dus hanteren ze in Redmond per fysieke processor.

Ook zonder dat verschil is SQL Server al een paar keer goedkoper dan Oracle hoor

Oracle haalt z'n klandizie met name uit z'n naam, z'n naam en z'n naam, niet uit de bewezen superioriteit van het product: SQL Server is in de praktijk sneller en veel gebruikersvriendelijker.

[TinusH777]

Hier wat cijfers over de kosten (ex kortingen):
10 g Standard edition one:
* $149/named user OF
* $4995 / CPU
Enterprise edition:
* $40.000 / CPU
* OF $800/named user

In vergelijking met MS-SQL Server:
Enterprise edition:
* $19.999 / CPU
* OF $6382/server + $146/user
Standard edition:
* $4781 / CPU
* OF $667/server + $146/user

[DeArmeStudent]

\\\\\\\"In de high-end wereld is het namelijk niet ongebruikelijk om bijvoorbeeld bij een klant die 16 processors nodig heeft een server met 32 processors neer te zetten, waarvan de helft gewoon niet gebruikt wordt. Zodra er later extra capaciteit nodig is zal deze praktisch direct beschikbaar zijn, en pas vanaf dat moment hoeft er voor de in eerste instantie overtollige hardware betaald te worden.\\\\\\\"

Dus na een jaar of 2 (wanneer die high-end processoren niet meer de snelste van de markt zijn) zal je als klant dan dus alsnog de dure prijs van 2 jaar geleden moeten betalen voor die extra capaciteit, die bestaat uit 2 jaar oude processoren...
Niet verstandig, als je het mij vraagt...

[Database freak]

De backup en recovery opties van SQLserver zijn een drama. 99 van de 100 keer is het een FULL restore. niet erg voor een database van 20Mb maar bij 1500Gb
Daartegenover staat dat het voor kleine databases (bijv, Websites) vaak handiger is om SQLserver te kiezen.

Gek er zijn diverse klanten van MS die TB grote DB's op MSSQL draaien.
Ik heb van Oracle DBA's gehoord dat Oracle's restore en roll forward met de transaction log weer problemen opleverde. Als dit werkelijk een probleem is bij MS SQL, dan zou dit pas bij 300GB en groter databases spelen. Daaronder kan je met een snel storage systeem redelijk snel een full restore doen.
In SQL Server 2005 worden trouwens de backup-mogelijkheden sterk verbeterd.

Ik gebruik MSSQL voor DWH en zie het enorme gebruikers gemak voor dit platform waardoor je heel snel BI oplossingen realiseerd. Heel wat anders dan bij Oracle waar ik enkel al 2 dagen aan het puzzelen was hoe het te installeren en de diverse tools te gebruiken. Best gooed voor een TB groot platform waar je een hoop specialisten voor kan in huren maar voor 300GB en kleiner lijkt mij MSSQL de betere keus.

[Verwijderd]

Als we het nu toch over web databasejes hebben...

Kijk hier maar eens...
http://www.ensembl.org/Docs/computation/
waarom zou dat toch op MySQL draaien?

[FrankNStein]

Het tegenargument is dat er juist minder processors nodig zullen zijn voor dezelfde prestaties, zodat klanten die per core betalen netto nog steeds even duur uit zijn.

]
Dus als je 1 core dubbel zo snel maakt, dan zou je zeker ook opeens een dubbel zo dure licentie moeten nemen. Want dat is waar dit argument feitelijk op neerkomt.
2x zoveel rekenkracht -> 2x zoveel licentiekosten
Lijkt me een beedje kromme beredenatie

edit:
laatmaar, dubbelpost, Vorlon was me voor

[Luxx]

In theorie is het natuurlijk "prefect" dat je het gebruik van de software betaalt. In dat geval moet je dus betalen nav de prestaties van een Systeem. In het verleden waren het aantal cores hiervoor een redelijke indicatie. Met dual core oplossingen wordt dat natuurlijk lastig. Voor Oracle is het zaak zo 'eerlijk' mogelijk geld van hun klanten af te troggellen. Door dit per core te rekenen (maar het bedrag per core relatief laag te houden) is het misschien wel eerlijker?

[pjottum]

Tegenwoordig slaat het licentiebeleid van Oracle sowieso nergens meer op; in de huidige high-end server omgevingen kan je realtime processors aan en uitschakelen: hoezo betalen per cpu? Als Oracle komt meten (en dat komen ze) dan schakel je er maar eentje aan, zodra ze weer wegzijn ga je weer fijn op je normale performance verder....

[Modalen]

er zijn ook genoeg softwarepakketten waarbij je een licentie voor een beperkt aantal gebruikers kunt afsluiten. En goh, je kunt met dezelfde licentiecode ook meer gebruikers met de software laten werken dan waarvoor je betaald hebt!

Weet je hoe dat heeft? Fraude. En dat is strafbaar.

[Verwijderd]

Wat een rare constructie, waarom niet gewoon licenties per client?

[Verwijderd]

Eerst de thread doorlezen daar wordt dit 100 keer in uitgelegd.

Persoonlijk vind ik het per core betalen ook te ver gaan, dat heeft wel erg veel met performance te maken, en dan zou je het ook echt meteen recht moeten trekken en alle cpu op snelheid beoordelen en er een tarief aan vast binden.

Dit houd alleen maar de vooruitgang van de cpu ontwikkeling op.

Enkel vind ik dat de verkeerde mensen deze oorlog vechten, ik vind dat de eindgebruikers zich als een blok tegen alle dual core bubble betalen licenties moeten verzetten.