Put down that Oracle database patch: It could cost $23,000 per CPU Oracle has released "the most comprehensive patch set" ever for its database software – but its users should be aware of potentially wallet-busting features in the batch. Version 12.1.0.2 of the database came out on Tuesday and brought with it a range of new features, including Oracle's hotly anticipated "in memory" tech. The …
INMEMORY_QUERY doesn't enable the feature. It allows sessions to use the feature if it is enabled, to enable the feature the parameter INMEMORY_SIZE is used to assign memory to the column store this defaults to 0 (disabled) and requires a restart to set, so not quite as on by default as it seems.
When software licences are this expensive, it's almost a valid expectation that the feature should require some form of enabling licence key to switch it on when necessary.
A Simple email, or even via the online portals of Oracle should allow a sysadmin or DBA to generate a test code that lasts for 14 days, (you should supply the system details it will be used on as well)
Then Oracle can follow that up with the Software Asset management team of the client (or whoever normally settles the Oracle invoices and bills) to confirm the full code will be released and they can expect payment.
Both vendor, and client/ customer have a duty of care to ensure there are suitable, and adequate measures in place to ensure a licence breach does not take place.
Oracle, by not putting such checks and balances in place could be viewed as wilfully and deliberately allowing such breaches to take place so that post usage fees can be generated at a later date.
Last I saw, This was similar to how VMWARE managed licences and nodes within a VMWARE farm.
Even Microsofts licencing portal allows visibility of all the features that your company have licenced and how many are currently in use (approximately)
But none of Oracle's tech products have license keys (not sure about the apps side). The onus has always been on the customer to make sure what they are licensed for and what is actually deployed.
In this case, however, I think a line has been crossed.
I'd be willing to wager that the growth in revenue from 'add ons' comes not from willing customers but from the disgusting practices that oracle employ in the innocent sounding 'license audit'. I got scalped in the last financial year despite running (what we considered to be) very strict adherence to the rules.
Funnily enough they got us on a couple of options that we had never used or installed (but were 'on by default') and their utterly ludicrous definition of what constitutes virtualization in their twisted world.
Bitter ? You betcha ! Their ploys are deliberate and unethical. Although oddly they have helped me rigidly define my future IT strategy. My only real goal in my professional life is to do all I can to reduce payments and installation of oracle products.... :-)
Caveat Emptor people. Nasty nasty organization...
> When software licences are this expensive, it's almost a valid expectation that the feature should require some form of enabling licence key to switch it on when necessary.
...or the people managing multimillion dollar systems and software have half a clue and keep on top of this stuff. This isn't amateur hour.
Mandatory license managers just cause trouble. That's another layer of complexity that important high value mission critical systems don't need.
"setting you back at least $23,000 per Oracle SPARC processor it's installed on, we've heard"
Based on the price list here:
http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf
it's $23,000 per Processor. But most SPARC processors use a factor of 0.5, so it'll only be $11,500...
http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf
>it's $23,000 per Processor. But most SPARC processors use a factor of 0.5, so it'll only be $11,500...
Oh well then that changes everything. 11 grand is nothing (besides a fairly nice used car). What saves most people that use Oracle is you said SPARC. Careful dead platform stumbling by.
No news here: Even Standard Edition One users can run Enterprise features. A curious DBA can run a Backupset with 'medium' or 'high' compression on command line or via OEM, and then Oracle comes along a year later and demand licenses for Enterprise Edition and Advanced Compression. Which would account for $47.500 + $11.500 = $59.000 per Processor license. It's simply a sales strategy. This is one out of probably hundred examples we have run into.
What really strikes me is the word choosing:"....Oracle chooses to carry out a license fee audit". It IS all about money and not about compliance. Unprepared folks will indeed pay unnecessarily.
Yes, it still matters quite a lot. While SSDs are faster than spinning rust drives, RAM still blows it away by an order of magnitude at least.
These read speed figures for media are rather general
Cheap USB2 Flash Drive: 5mb/sec
7200 RPM SATA HDD: 120mb/sec
SSD: 550mb/sec
DDR3 RAM: 12,500mb/sec
So from that you can see how much faster your database would run with your tabled cached in RAM.
That being said, at $28k per core I don't give two shits how fast my database runs, you shouldn't have to pay that much for what should be a basic feature of any database
If you're large enough to justify using Oracle, you would hardly care. In fact, you'd probably pay it for the option to move that much faster.
If you're not large enough to justify using Oracle, STOP USING ORACLE.
I don't particularly care what companies this huge charge for databases sold on this scale. If you're even CAPABLE of paying that much money for one piece of software running on one processor, you're big enough to know what to do about it and hire experts to manage it and the time is critical. Everyone else can just jumble along on "normal" business databases quite happily.
Seriously, I'm not even sure at what kind of scale I'd need to start thinking to myself "Hmmm... Oracle might be what I need here". Possibly government-sized? I don't know. Certainly not 99.999% of the IT that's out there in the world.
Back in Oracle version 7 (last version that I used), if the SGA (Shared Global Area) was larger than the database (plenty of RAM and small database) then once a table had been read in it would never be evicted from RAM so it was possible to run the whole database from RAM - the only I/Os were writes from database updates. Given Oracle's exorbitant pricing , if the database can be held in memory this way then this might be the better option (assuming that for some reason you are locked into Oracle).
Does the Oracle DB know what is "RAM" only by the SGA size? If so, does it know memory being presented as an in-memory fielsystem by tools such as memFS or tmpFS is actually memory or does it think it is "disk"? If so, could you get round the memory tax by creating a memory filesystem, thus getting the speed of RAM without the added licenses? You would need lots of memory to ensure the memory filesystem didn't eat too much shared memory, but RAM is cheaper than Oracle licenses......
Actually if the option is installed it doesn't mean it's in use. The whole article is based on having the INMEMORY_QUERY parameter enabled but this only shows proof of installation. The most important part is having the parameter INMEMORY_SIZE = 0 (default value) as this makes the whole difference and shows proof of non usage.
Haven't used Oracle since a RAC fiasco involving cache coherency (or more accurately, incoherency). But IIRC:
- you can tune the SGA to trade memory usage for disk I/O, so that your frequently-hit tables stay in memory. How is that different from this IN_MEMORY option? Is it just a more aggressive hint to the DB that My Particular Table gets first dibs, as opposed to letting the SGA manager decide?
- you could pull tricks outside of Oracle, such as using mmapped files. I suppose that's only useful if your special table is in a file by itself and/or your DB files fit in RAM?
Can someone explain?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
