5 ms·

> At that point, they are probably looking (the very least) substantial per-core fees for the esoteric Oracle Enterprise features that they are using in product

by rodgerd 11y ago

> At that point, they are probably looking (the very least) substantial per-core fees for the esoteric Oracle Enterprise features that they are using in production. Nope, this is Oracle with their "you can only virtualise on our virt stack, or you have to pay for the whole farm if a single vCPU is on" trick. Except their licensing model is even more absurd than that - if you have cores switched off at the BIOS, they still count for licensing in Oracle land. The substance of the article is quite correct: Oracle is using customer-hostile tactics to pump their numbers, so investors don't realise how badly their non-core activities are actually doing.

jpollock 11y ago
They do that with their own stack too (or at least they did). To avoid costs, you have to set up the VM such that it is locked to certain cores, and then that avoids the virtualisation portion of the license issues. Oracle's always had very flexible, very hard to understand licensing. I know I never understood it. Pricing per-core,per-feature? Ugh. Then they make it really easy to add new features without knowing how much it costs. Double Ugh. We had a developer add a feature that cost us $100k/core just to process some XML. We quickly replaced it. We had a customer drop their Oracle license fees by 90% by locking their Oracle processes to specific cores (from 20 cores to 2). Personally, I've never liked Oracle. Whenever I interact with them, it hasn't been fun (and I worked for them for a couple of years). Although, Oracle's Cloud Licensing doc is clear about the requirements saying that every vcore is a core. [1] [1] http://www.oracle.com/us/corporate/pricing/cloud-licensing-070579.pdf http://www.oracle.com/us/corporate/pricing/cloud-licensing-0...
- DrStalker 11y ago
  Have you ever tried to buy a server with only a single core for licensing reasons? It's impossible with modern hardware, the best we were able to do was a double core/single CPU system to run some oracle bits to talk to other oracle stuff. This server processed around half a dozen tiny xml files a day and buying a dedicated physical server saved a few hundred thousand over any other option we could figure out.
  - rodgerd 11y ago
    The best option is usually another DBMS stack if you can support it. DB2 does support much saner licensing, for example.
    - hydrogen18 11y ago
      Your advice is spot-on, but you have to remember that many times the software being ran was written by someone who has long since moved on. Even if the source code is readily available, no one may be around to handle to porting it to another RDBMS. Admittedly, this is where much maligned dependency injection frameworks can be useful. I have "upgraded" a large number of old Java software packages by simply placing a newer version of the library's jar on the classpath.
    - marcosdumay 11y ago
      Well, if we are comparing licenses, Postgres has an unbeatable licensing, and a much better Oracle compatibility tools.
  - walshemj 11y ago
    You did not consider using a simple Open source system to do this or are you unlucky and work for a corporate where its Oracle everywhere?
- rodgerd 11y ago
  > They do that with their own stack too (or at least they did). Nope. If you buy Oracle's virt stacks (either RHEV-with-the-serial-numbers-filed-off-and-using-XEN or Solaris), they happily let you sub-capacity license. It's been that way for at least four or five years now. > To avoid costs, you have to set up the VM such that it is locked to certain cores, and then that avoids the virtualisation portion of the license issues. Under current licensing, that's a no, unless it's running in an Oracle branded VM, or zVM. No pinning or soft partitioning are recognised otherwise.
- gaius 11y ago
  You might be bemused to learn that there are consulting companies selling the service of figuring out your Oracle licenses for you http://www.version1.com/Enterprise-Solutions/Software-License-Optimisation http://www.version1.com/Enterprise-Solutions/Software-Licens...
  - cafard 11y ago
    I was interested, but not surprised.
tomjen3 11y ago
The more I read stories like that, the more I wonder why companies use Oracle at all. Is it really just cover your ass, institutional inertial and people who don't know better?
- raverbashing 11y ago
  This but also their salesman playing golf with the CTO in a fancy hotel
- pionar 11y ago
  Ok, let's take a hypothetical (though, VERY close to what I've seen). You're a SAAS company. Not a startup, a medium-size company that's been around for 20+ years. Your core software is close to 15 years old. It's 2.5 million lines of code (not that hard to do with "enterprise" software). You have somewhere around 75 TB of data in probably 500 individual customer databases (multi-tenancy was not thought of in 2002 when your core software was developed). This software expects Oracle to be the backend. You can either: 1. Sink time and money into engineering time to evaluate, choose, and implement a new DBMS, and pay for consultants, licenses (if you choose a proprietary one), hardware (you'll need some, because you'll have that weird in-between time as you're migrating your customers' data). You'll have to properly train your DBA's and developers (and ops people) on the new DBMS ($$). You then have to write proper ETL scripts, schedule downtime with your customers (who have nearly 24/7 operations and transactions), make the switch, hope everything went well, then repeat that for your other 499 customers. - or - 2. You can continue to pay Oracle, because you've got that in your budget every year, and it's not worth the hassle.
- gaius 11y ago
  Because if you use it for what it's for, Oracle is very, very good. 10 years ahead of the competition, easily and remember there is no "cheap" or "expensive" in business, only worth the money, or not. But if you are just some schmuck developer who needs "a database" and you settle on Oracle and don't use all of its clever features because you've hidden it behind SQLAlchemy or Hibernate in an attempt to be database-agnostic, well then you're going to get taken to the cleaners, but it's your own fault.
threeseed 11y ago
Let's be clear here. This is NOT just an Oracle tactic. I've dealt with a lot of "enterprise" vendors who have the same policy. It will be amazing to see what happens if Xeon Phi processors become widespread.

by rodgerd 11y ago

jpollock 11y ago

They do that with their own stack too (or at least they did). To avoid costs, you have to set up the VM such that it is locked to certain cores, and then that avoids the virtualisation portion of the license issues. Oracle's always had very flexible, very hard to understand licensing. I know I never understood it. Pricing per-core,per-feature? Ugh. Then they make it really easy to add new features without knowing how much it costs. Double Ugh. We had a developer add a feature that cost us $100k/core just to process some XML. We quickly replaced it. We had a customer drop their Oracle license fees by 90% by locking their Oracle processes to specific cores (from 20 cores to 2). Personally, I've never liked Oracle. Whenever I interact with them, it hasn't been fun (and I worked for them for a couple of years). Although, Oracle's Cloud Licensing doc is clear about the requirements saying that every vcore is a core. [1] [1] http://www.oracle.com/us/corporate/pricing/cloud-licensing-070579.pdf http://www.oracle.com/us/corporate/pricing/cloud-licensing-0...

DrStalker 11y ago
Have you ever tried to buy a server with only a single core for licensing reasons? It's impossible with modern hardware, the best we were able to do was a double core/single CPU system to run some oracle bits to talk to other oracle stuff. This server processed around half a dozen tiny xml files a day and buying a dedicated physical server saved a few hundred thousand over any other option we could figure out.
- rodgerd 11y ago
  The best option is usually another DBMS stack if you can support it. DB2 does support much saner licensing, for example.
  - hydrogen18 11y ago
    Your advice is spot-on, but you have to remember that many times the software being ran was written by someone who has long since moved on. Even if the source code is readily available, no one may be around to handle to porting it to another RDBMS. Admittedly, this is where much maligned dependency injection frameworks can be useful. I have "upgraded" a large number of old Java software packages by simply placing a newer version of the library's jar on the classpath.
  - marcosdumay 11y ago
    Well, if we are comparing licenses, Postgres has an unbeatable licensing, and a much better Oracle compatibility tools.
- walshemj 11y ago
  You did not consider using a simple Open source system to do this or are you unlucky and work for a corporate where its Oracle everywhere?
rodgerd 11y ago
> They do that with their own stack too (or at least they did). Nope. If you buy Oracle's virt stacks (either RHEV-with-the-serial-numbers-filed-off-and-using-XEN or Solaris), they happily let you sub-capacity license. It's been that way for at least four or five years now. > To avoid costs, you have to set up the VM such that it is locked to certain cores, and then that avoids the virtualisation portion of the license issues. Under current licensing, that's a no, unless it's running in an Oracle branded VM, or zVM. No pinning or soft partitioning are recognised otherwise.
gaius 11y ago
You might be bemused to learn that there are consulting companies selling the service of figuring out your Oracle licenses for you http://www.version1.com/Enterprise-Solutions/Software-License-Optimisation http://www.version1.com/Enterprise-Solutions/Software-Licens...
- cafard 11y ago
  I was interested, but not surprised.

tomjen3 11y ago

The more I read stories like that, the more I wonder why companies use Oracle at all. Is it really just cover your ass, institutional inertial and people who don't know better?

raverbashing 11y ago
This but also their salesman playing golf with the CTO in a fancy hotel
pionar 11y ago
Ok, let's take a hypothetical (though, VERY close to what I've seen). You're a SAAS company. Not a startup, a medium-size company that's been around for 20+ years. Your core software is close to 15 years old. It's 2.5 million lines of code (not that hard to do with "enterprise" software). You have somewhere around 75 TB of data in probably 500 individual customer databases (multi-tenancy was not thought of in 2002 when your core software was developed). This software expects Oracle to be the backend. You can either: 1. Sink time and money into engineering time to evaluate, choose, and implement a new DBMS, and pay for consultants, licenses (if you choose a proprietary one), hardware (you'll need some, because you'll have that weird in-between time as you're migrating your customers' data). You'll have to properly train your DBA's and developers (and ops people) on the new DBMS ($$). You then have to write proper ETL scripts, schedule downtime with your customers (who have nearly 24/7 operations and transactions), make the switch, hope everything went well, then repeat that for your other 499 customers. - or - 2. You can continue to pay Oracle, because you've got that in your budget every year, and it's not worth the hassle.
gaius 11y ago
Because if you use it for what it's for, Oracle is very, very good. 10 years ahead of the competition, easily and remember there is no "cheap" or "expensive" in business, only worth the money, or not. But if you are just some schmuck developer who needs "a database" and you settle on Oracle and don't use all of its clever features because you've hidden it behind SQLAlchemy or Hibernate in an attempt to be database-agnostic, well then you're going to get taken to the cleaners, but it's your own fault.

threeseed 11y ago

Let's be clear here. This is NOT just an Oracle tactic. I've dealt with a lot of "enterprise" vendors who have the same policy. It will be amazing to see what happens if Xeon Phi processors become widespread.